Hi SB, In case you might ever want to port your app to other platforms/OSs after Android, the CompactSIP stack has been ported to Android, iOS/iPhone, Linux, Windows, VxWorks and several other OS/platform interfaces, with support for embedded SIP applications as well as smartphone VoIP softphone apps.
Regards, Charlie Crowe ----- Original Message ----- From: <[email protected]> To: <[email protected]> Sent: Tuesday, May 28, 2013 9:53 AM Subject: Sip-implementors Digest, Vol 122, Issue 8 > Send Sip-implementors mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Sip-implementors digest..." > > > Today's Topics: > > 1. Re: Query regarding session timer behaviour in SIP Stack > (Paul Kyzivat) > 2. commercial SIP stack/library. (Sungbum Lim) > 3. Re: commercial SIP stack/library. (Sumit Jindal) > 4. Processing request Request-URI and To URI > (Kumarasami Parasuraman-QXVB36) > 5. Re: Processing request Request-URI and To URI (Paul Kyzivat) > 6. Re: Processing request Request-URI and To URI > (Kumarasami Parasuraman-QXVB36) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 23 May 2013 13:49:35 -0400 > From: Paul Kyzivat <[email protected]> > Subject: Re: [Sip-implementors] Query regarding session timer > behaviour in SIP Stack > To: Priya Arya <[email protected]> > Cc: "[email protected]" > <[email protected]> > Message-ID: <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 5/23/13 5:28 AM, Priya Arya wrote: >> Hi Paul, >> >> Thanks for the response. >> I have marked inline the answers to the queries. > > Then, based on what you have said, the "SIP Stack" is broken: > > - the 2nd invite (first re-invite) was incorrect because it didn't > include an S-E > > - it apparently failed to honor the S-E in received in the > response to that invite. > > I don't see anything that the "N/W" is doing wrong. > > Thanks, > Paul > >> Regards >> Priya Arya >> >> -----Original Message----- >> From: Paul Kyzivat [mailto:[email protected]] >> Sent: Tuesday, May 21, 2013 12:34 AM >> To: [email protected] >> Subject: Re: [Sip-implementors] Query regarding session timer behaviour >> in SIP Stack >> >> On 5/20/13 2:12 PM, Priya Arya wrote: >>> Hi All, >>> >>> I have certain queries about the session timer behaviour in the SIP >>> Stack. >>> The scenario is as follows : >>> >>> SIP Stack >>> N/w >>> >>> At T0s >>> >>> INVITE >>> --------------------------------------------------------------------------------> >>> (having SE=600 &Min-SE = >>> 600 ) >>> >>> 100 Trying >>> <--------------------------------------------------------------------------- >>> 180 Ringing >>> <------------------------------------------------------------------------- >>> 200 OK >>> <------------------------------------------------------------------------------- >>> (having >>> Require:timer,SE=600,refresher=uas) >>> >>> ACK >>> ----------------------------------------------------------------------------------> >>> >>> <---------------------------------Call Connected >>> ---------------------------------> >>> >>> At this point the Call is connected and the session timer is started by >>> SIP Stack when 200 OK from the Network is received by the SIP Stack. >>> After this, SIP Stack sends out a Re-INVITE with as the new offer(as the >>> version number in the o-line is incremented here). >> >> So this was a spontaneous re-INVITE, not motivated by session timer? >> (It doesn't really matter, but it will help in understanding your case.) >> >> <------- This Re-INVITE was originated by the Application running at the >> top of SIP Stack and not motivated by the session timer ------> >> >>> At T0+8s >>> >>> INVITE >>> ---------------------------------------------------------------------------> >>> (Version number in o-line of Re-INVITE SDP is >>> incremented by 1) >> >> Did this have an S-E in it? Did it have Supported:timer? Did it have a >> Min-S-E? >> >> <----- Re-INVITE message contains "Supported:timer" only and neither >> Min-S-E nor S-E in it ------> >> >> >> The RFC says: >> >> In a session refresh request sent within a dialog with an active >> session timer, the Session-Expires header field SHOULD be present. >> When present, it SHOULD be equal to the maximum of the Min-SE header >> field (recall that its default value when not present is 90 seconds) >> and the current session interval. Inclusion of the Session-Expires >> header field with this value avoids certain denial-of-service >> attacks, as documented in Section 11. As such, a UA should only >> ignore the SHOULD in unusual and singular cases where it is >> desirable >> to change the session interval mid-dialog. >> >> But it doesn't say "MUST be present". So the UAS must be prepared for >> that case. >> >>> 200 OK >>> <------------------------------------------------------------------------------- >>> (having >>> SE=19200,refresher=uas) >> >> Note that the RFC talks about session refresh requests as if they were >> somehow distinguishable from INVITEs and UPDATEs used for other purposes. >> And the UAS behavior doesn't have different rules for the first request >> and subsequent ones. In reality there is no way to distinguish, so you >> really must assume that *every* INVITE and UPDATE will either serve as a >> refresh or else will cancel the timer. >> >> So, if there was no S-E in the request, and there is none in the >> response, then it must cancel the timer. In this case the S-E in the >> response resets the timer to 19200 seconds. The UAC should realize that. >> >>> >>> ACK >>> ----------------------------------------------------------------------------------> >>> >>> At T0 + 485s >>> >>> >>> BYE >>> ----------------------------------------------------------------------------------> >>> >>> The call is terminated with BYE by the SIP Stack after 485 seconds. >> >> One question of course is why the BYE was sent. >> I guess you are assuming it has something to do with a session timer >> expiring, but do you know that? >> >> <----- After checking the logs of SIP Stack, I found that the BYE is sent >> out on the expiry of Session refresh timer and so the BYE terminates the >> call ------> >> >> >>> Here I have few doubts: >>> >>> 1) The refresher is network here in both the cases. >>> The second 200 OK response is sent for the "Re-INVITE with new >>> offer" containing the greater values of session timer than the first 200 >>> OK. >>> So, does the new value of Session-Expires=19200s in second 200Ok >>> should be considered as session refresh request by the SIP Stack ? >> >> As I explained above, every reinvite and update resets (or cancels) the >> session timer. >> >> The RFC doesn't come right out and say this, but it is implicit. >> >>> 2) Should the SIP Stack restart its session timer with the new value >>> "19200" or if the SIP Stack should restart its timer with the old value >>> "600" on receiving second 200 OK ? >> >> 19200. >> >>> 3) Here, the call is terminated with BYE after 485 seconds by the SIP >>> Stack. >>> What should be the exact time to terminate the call considering >>> the fact that SIP Stack is running the session timer with the values >>> received in 200 OK responses? >> >> The draft says: >> >> Similarly, if the side not performing refreshes does not receive a >> session refresh request before the session expiration, it SHOULD >> send >> a BYE to terminate the session, slightly before the session >> expiration. The minimum of 32 seconds and one third of the session >> interval is RECOMMENDED. >> >> That would be after 568 seconds for an S-E of 600, and 19,168 seconds for >> S-E of 19,200. If the BYE was because of an assumed expiry of the session >> timer, then I don't know where the value came from. >> >> Thanks, >> Paul >> >>> Please share the references from the RFC to support the above queries. >>> >>> Regards >>> Priya Arya >>> >>> >>> >>> >>> ====================================================================== >>> ========= Please refer to >>> http://www.aricent.com/legal/email_disclaimer.html >>> for important disclosures regarding this electronic communication. >>> ====================================================================== >>> ========= _______________________________________________ >>> Sip-implementors mailing list >>> [email protected] >>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors >>> >> >> _______________________________________________ >> Sip-implementors mailing list >> [email protected] >> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors >> >> >> >> >> =============================================================================== >> Please refer to http://www.aricent.com/legal/email_disclaimer.html >> for important disclosures regarding this electronic communication. >> =============================================================================== >> > > > > ------------------------------ > > Message: 2 > Date: Fri, 24 May 2013 13:47:35 +0800 > From: Sungbum Lim <[email protected]> > Subject: [Sip-implementors] commercial SIP stack/library. > To: [email protected] > Message-ID: > <cagseqppopjaektlysjovz8vsqxc0xto2suuue70r6mks7zr...@mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > Hello.. > > I am planning to develop an Android app. > > please suggest me a good commercial SIP stack/library. > > Thanks, > SB > > > ------------------------------ > > Message: 3 > Date: Fri, 24 May 2013 12:04:44 +0530 > From: Sumit Jindal <[email protected]> > Subject: Re: [Sip-implementors] commercial SIP stack/library. > To: Sungbum Lim <[email protected]> > Cc: "[email protected]" > <[email protected]> > Message-ID: > <CAOJNQpX88qSYEsqSLk47dOm4ZMo_obZDUX6Kcs9qUeigt=c...@mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Hi SB, > > Android has sip support. > > Please refer > http://developer.android.com/guide/topics/connectivity/sip.html > > Regards, > Sumit Jindal > > > > On Fri, May 24, 2013 at 11:17 AM, Sungbum Lim <[email protected]> wrote: > >> Hello.. >> >> I am planning to develop an Android app. >> >> please suggest me a good commercial SIP stack/library. >> >> Thanks, >> SB >> _______________________________________________ >> Sip-implementors mailing list >> [email protected] >> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors >> > > > > -- > Regards, > Sumit Jindal > > > ------------------------------ > > Message: 4 > Date: Tue, 28 May 2013 14:09:42 +0000 > From: Kumarasami Parasuraman-QXVB36 <[email protected]> > Subject: [Sip-implementors] Processing request Request-URI and To URI > To: "[email protected]" > <[email protected]> > Message-ID: > <60734fdfd399674d90bc0745902cfa9171505...@bl2prd0410mb374.namprd04.prod.outlook.com> > > Content-Type: text/plain; charset="us-ascii" > > Hi, > > Is anywhere in the RFC said Processing / generating Request, Request-URI > and To URI should be same. > > While processing request Request-URI has, sip:domain.com and To URI has, > sip:[email protected]. Is the UAS can reject the request with 403 Forbidden. > > Please clarify me. > > As per the RFC3261(Character Escaping Requirements) , User part is > optional in both Request-URI and To URI. > > 19.1.2 Character Escaping Requirements > > dialog > reg./redir. Contact/ > default Req.-URI To From Contact R-R/Route external > user -- o o o o o o > password -- o o o o o o > host -- m m m m m m > port (1) o - - o o o > user-param ip o o o o o o > method INVITE - - - - - o > maddr-param -- o - - o o o > ttl-param 1 o - - o - o > transp.-param (2) o - - o o o > lr-param -- o - - - o o > other-param -- o o o o o o > headers -- - - - o - o > > Thanks > > Regards, > Parasu > > > > ------------------------------ > > Message: 5 > Date: Tue, 28 May 2013 10:40:23 -0400 > From: Paul Kyzivat <[email protected]> > Subject: Re: [Sip-implementors] Processing request Request-URI and To > URI > To: [email protected] > Message-ID: <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 5/28/13 10:09 AM, Kumarasami Parasuraman-QXVB36 wrote: >> Hi, >> >> Is anywhere in the RFC said Processing / generating Request, Request-URI >> and To URI should be same. > > There is no requirement that they be the same. > Typically they start out the same but the R-URI changes as the request > is routed toward the destination. So it is quite normal that when the > request is received by the UAS that the two are different. > >> While processing request Request-URI has, sip:domain.com and To URI has, >> sip:[email protected]. Is the UAS can reject the request with 403 >> Forbidden. > > The UAS can return 403 if it wishes. That is indicative of a policy > decision. The policy *could* be based on the To-URI or the From-URI, > R-URI, or most anything else. (E.g., there could be a policy "we only > accept calls *to* a URI we know", or "we only accept calls *from* URIs > on a whitelist".) > > The "final" R-URI when the request reaches the UAS should identify the > UAS itself. Normally a UAS wouldn't honor a request with an R-URI that > it knows to be its own. (Though some are lax about this.) > > Typically a caller won't know the precise URI that identifies the UAS. > Instead that is typically inserted by a proxy, based on registration by > the UAS. > > Thanks, > Paul > >> Please clarify me. >> >> As per the RFC3261(Character Escaping Requirements) , User part is >> optional in both Request-URI and To URI. >> >> 19.1.2 Character Escaping Requirements >> >> dialog >> reg./redir. Contact/ >> default Req.-URI To From Contact R-R/Route external >> user -- o o o o o o >> password -- o o o o o o >> host -- m m m m m m >> port (1) o - - o o o >> user-param ip o o o o o o >> method INVITE - - - - - o >> maddr-param -- o - - o o o >> ttl-param 1 o - - o - o >> transp.-param (2) o - - o o o >> lr-param -- o - - - o o >> other-param -- o o o o o o >> headers -- - - - o - o >> >> Thanks >> >> Regards, >> Parasu >> >> _______________________________________________ >> Sip-implementors mailing list >> [email protected] >> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors >> > > > > ------------------------------ > > Message: 6 > Date: Tue, 28 May 2013 14:53:30 +0000 > From: Kumarasami Parasuraman-QXVB36 <[email protected]> > Subject: Re: [Sip-implementors] Processing request Request-URI and To > URI > To: Paul Kyzivat <[email protected]>, > "[email protected]" > <[email protected]> > Message-ID: > <60734fdfd399674d90bc0745902cfa9171505...@bl2prd0410mb374.namprd04.prod.outlook.com> > > Content-Type: text/plain; charset="us-ascii" > > Thanks paul. > > Regards, > Parasu > > -----Original Message----- > From: Paul Kyzivat [mailto:[email protected]] > Sent: Tuesday, May 28, 2013 8:10 PM > To: [email protected] > Subject: Re: [Sip-implementors] Processing request Request-URI and To URI > > On 5/28/13 10:09 AM, Kumarasami Parasuraman-QXVB36 wrote: >> Hi, >> >> Is anywhere in the RFC said Processing / generating Request, Request-URI >> and To URI should be same. > > There is no requirement that they be the same. > Typically they start out the same but the R-URI changes as the request is > routed toward the destination. So it is quite normal that when the request > is received by the UAS that the two are different. > >> While processing request Request-URI has, sip:domain.com and To URI has, >> sip:[email protected]. Is the UAS can reject the request with 403 >> Forbidden. > > The UAS can return 403 if it wishes. That is indicative of a policy > decision. The policy *could* be based on the To-URI or the From-URI, > R-URI, or most anything else. (E.g., there could be a policy "we only > accept calls *to* a URI we know", or "we only accept calls *from* URIs on > a whitelist".) > > The "final" R-URI when the request reaches the UAS should identify the UAS > itself. Normally a UAS wouldn't honor a request with an R-URI that it > knows to be its own. (Though some are lax about this.) > > Typically a caller won't know the precise URI that identifies the UAS. > Instead that is typically inserted by a proxy, based on registration by > the UAS. > > Thanks, > Paul > >> Please clarify me. >> >> As per the RFC3261(Character Escaping Requirements) , User part is >> optional in both Request-URI and To URI. >> >> 19.1.2 Character Escaping Requirements >> >> dialog >> reg./redir. Contact/ >> default Req.-URI To From Contact R-R/Route external >> user -- o o o o o o >> password -- o o o o o o >> host -- m m m m m m >> port (1) o - - o o o >> user-param ip o o o o o o >> method INVITE - - - - - o >> maddr-param -- o - - o o o >> ttl-param 1 o - - o - o >> transp.-param (2) o - - o o o >> lr-param -- o - - - o o >> other-param -- o o o o o o >> headers -- - - - o - o >> >> Thanks >> >> Regards, >> Parasu >> >> _______________________________________________ >> Sip-implementors mailing list >> [email protected] >> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors >> > > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > > > > > > > ------------------------------ > > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > End of Sip-implementors Digest, Vol 122, Issue 8 > ************************************************ > > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
