How to test device for rfc 3261 complience ?
Best Regards,Sakharam Thorat. > From: sip-implementors-requ...@lists.cs.columbia.edu > Subject: Sip-implementors Digest, Vol 125, Issue 1 > To: sip-implementors@lists.cs.columbia.edu > Date: Sun, 4 Aug 2013 19:24:04 -0400 > > Send Sip-implementors mailing list submissions to > sip-implementors@lists.cs.columbia.edu > > 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 > sip-implementors-requ...@lists.cs.columbia.edu > > You can reach the person managing the list at > sip-implementors-ow...@lists.cs.columbia.edu > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Sip-implementors digest..." > > > Today's Topics: > > 1. Instant messaging using sip for bb 10 (Ashish Gour) > 2. Open-IMS S-CSCF node sending wrong value in Contact header in > 200 OK of Subscribe (Mangal Singh) > 3. Want to build RCS client over a sip stack (sachin sharma) > 4. Re: Open-IMS S-CSCF node sending wrong value in Contact > header in 200 OK of Subscribe (Tarun2 Gupta) > 5. How should UAC handle a retransmit of a reliable provisional > response (Jason Harrison) > 6. Re: How should UAC handle a retransmit of a reliable > provisional response (Brett Tate) > 7. rfc4904: tgrp case sensitivity (Brett Tate) > 8. Re: rfc4904: tgrp case sensitivity (Hadriel Kaplan) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 29 Jul 2013 15:20:15 +0530 > From: Ashish Gour <gourashis...@gmail.com> > Subject: [Sip-implementors] Instant messaging using sip for bb 10 > To: sip-implementors@lists.cs.columbia.edu > Message-ID: > <CAEoHT-Z9oy96JgBrSP6voVNZEp5vX2j5Dua6N=rcef64ou8...@mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > hello, > i have made an pjsip based app for bb 10 . Now i want to implement instant > messaging for sip contacts. Please provide me any link or procedure to > that. Pjsua API can be used. What is the procedure to implement it?? > > thanks in advance.. > > Regards > Ashish Gour > > > ------------------------------ > > Message: 2 > Date: Tue, 30 Jul 2013 15:31:11 +0530 > From: Mangal Singh <mangal.si...@globallogic.com> > Subject: [Sip-implementors] Open-IMS S-CSCF node sending wrong value > in Contact header in 200 OK of Subscribe > To: sip-implementors@lists.cs.columbia.edu > Message-ID: > <cakdpdd3dkc828mwtfpgb6mp+ukhgcck1ucqgzofuzgqrf9+...@mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Hi, > > When end-point does Subscription for reg-event on S-CSCF, then in 200 OK > response S-CSCF forms Contact header having public uri of end-point. > Thus instead of sending its own address, S-CSCF sends public uri in Contact > header in 200 OK response of SUBSCRIBE. > Is this behaviour of S-CSCF right ? Shouldn't S-CSCF send it's own address > in Contact header in 200 OK ? > > Thanks and Regards, > Mangal Singh | Senior Software Engineer > GlobalLogic > P +91.120.406.2000.2559 M +91.880.012.1658 > www.globallogic.com > <http://www.globallogic.com/> > http://www.globallogic.com/email_disclaimer.txt > > > ------------------------------ > > Message: 3 > Date: Tue, 30 Jul 2013 21:43:14 +0800 (SGT) > From: sachin sharma <sachin19...@yahoo.co.in> > Subject: [Sip-implementors] Want to build RCS client over a sip stack > To: sip-implementors@lists.cs.columbia.edu > Message-ID: > <1375191794.43587.yahoomailba...@web193802.mail.sg3.yahoo.com> > Content-Type: text/plain; charset=utf-8 > > Hi All, > > I want to build an RCS 5.1 based client for commercial purpose. For this > i have thought of taking an open source sip stack as base and modify it for > RCS specific parameters. Can you suggest any open source sip stack which i > can use as a base to start with. > > Thanks & Regards > Sachin Sharma > > > > ------------------------------ > > Message: 4 > Date: Wed, 31 Jul 2013 15:03:44 +0530 > From: Tarun2 Gupta <tarun2.gu...@aricent.com> > Subject: Re: [Sip-implementors] Open-IMS S-CSCF node sending wrong > value in Contact header in 200 OK of Subscribe > To: Mangal Singh <mangal.si...@globallogic.com>, > "sip-implementors@lists.cs.columbia.edu" > <sip-implementors@lists.cs.columbia.edu> > Message-ID: > > <bd262adb17bdd74aa30500bc09b694fd0bdadb1...@gurexmb01.asian.ad.aricent.com> > > Content-Type: text/plain; charset="us-ascii" > > Hi Mangal > > As per current implementation of OpenIMS, the Contact in SUBSCRIBE 200 OK > response is formed from the RequestURI of the incoming SUBSCRIBE request. > This seems to be a bug in the implementation. You can customize the > implementation to send the correct Contact. > > Refer:- /opt/OpenIMSCore/ser_ims/modules/scscf/registrar_notify.c (functions > S_subscribe() and S_SUBSCRIBE_reply()) > > Regards > Tarun Gupta > Aricent > > > -----Original Message----- > From: Mangal Singh [mailto:mangal.si...@globallogic.com] > Sent: Tuesday, July 30, 2013 3:31 PM > To: sip-implementors@lists.cs.columbia.edu > Subject: [Sip-implementors] Open-IMS S-CSCF node sending wrong value in > Contact header in 200 OK of Subscribe > > Hi, > > When end-point does Subscription for reg-event on S-CSCF, then in 200 OK > response S-CSCF forms Contact header having public uri of end-point. > Thus instead of sending its own address, S-CSCF sends public uri in Contact > header in 200 OK response of SUBSCRIBE. > Is this behaviour of S-CSCF right ? Shouldn't S-CSCF send it's own address in > Contact header in 200 OK ? > > Thanks and Regards, > Mangal Singh | Senior Software Engineer > GlobalLogic > P +91.120.406.2000.2559 M +91.880.012.1658 www.globallogic.com > <http://www.globallogic.com/> http://www.globallogic.com/email_disclaimer.txt > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > 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: 5 > Date: Thu, 1 Aug 2013 12:21:08 +0000 > From: Jason Harrison <jason.harri...@azzu.co.uk> > Subject: [Sip-implementors] How should UAC handle a retransmit of a > reliable provisional response > To: "sip-implementors@lists.cs.columbia.edu" > <sip-implementors@lists.cs.columbia.edu> > Message-ID: > <AE8F5ABAFF902A4094E2E9538B23EC3B94E1B675@AZZ-EMAIL01.azzurri.local> > Content-Type: text/plain; charset=WINDOWS-1252 > > Hi, > > I have the following scenario intermittently: > PBX SBC Service > Provider > ---INVITE---> > <---100 Trying--- > ---INVITE---> > <---100 Trying--- > <---183 Session Progress--- > <---183 Session Progress--- > ---PRACK---> > ---PRACK---> > <---200OK--- > <---183 Session Progress--- > <---183 Session Progress--- > <---504 Server Timeout--- > ---ACK---> > > The service provider is stating they the SBC should send a PRACK for every > 183 sent, which I believe is correct however RFC3262 states "a UAC SHOULD NOT > retransmit the PRACK request when it receives a retransmission of the > provisional response being acknowledged" > > As far as I am concerned the PRACK is not being received by the Service > provider so they re-transmit the 183, which should be PRACK'd to stop > re-transmissions of the 183, but the RFC contradicts this > > What should be happening here is the SBC at fault? > > Regards > Jason > > > For more information please visit <a > href="http://www.mimecast.com";>http://www.mimecast.com<br> > This email message has been delivered safely and archived online by Mimecast. > </a> > > ------------------------------ > > Message: 6 > Date: Thu, 1 Aug 2013 16:21:26 +0000 > From: Brett Tate <br...@broadsoft.com> > Subject: Re: [Sip-implementors] How should UAC handle a retransmit of > a reliable provisional response > To: Jason Harrison <jason.harri...@azzu.co.uk>, > "sip-implementors@lists.cs.columbia.edu" > <sip-implementors@lists.cs.columbia.edu> > Message-ID: > <576A8B541C219D4E9CEB1DF8C19C7B881A05775A@MBX08.citservers.local> > Content-Type: text/plain; charset="us-ascii" > > > I have the following scenario intermittently: > > The flow was too corrupted to adequately understand what was occurring. I'll > assume that the 18x responses are truly retries (i.e. same To tag and RSeq). > I assume that the single 200 is for PRACK; however I'm not sure who you are > indicating sent it. > > Is the second PRACK a retry or being sent by the SBC? > > If PRACK sent by the SBC, does it correctly correspond to the 18x? > > If PRACK not sent by the SBC, was the PRACK received by the SBC valid? > > > > The service provider is stating they the SBC should send a PRACK for > > every 183 sent, which I believe is correct however RFC3262 states "a > > UAC SHOULD NOT retransmit the PRACK request when it receives a > > retransmission of the provisional response being acknowledged" > > Assuming that the 18x responses are truly retries, RFC 3262 indicates (as you > quoted) that the PRACK retries are independent of the 18x retries. Thus the > PRACK "SHOULD NOT" be retransmitted upon receiving a 18x retry. > > > > As far as I am concerned the PRACK is not being received by the Service > > provider so they re-transmit the 183, which should be PRACK'd to stop > > re-transmissions of the 183, but the RFC contradicts this > > As I mentioned, the flow was too corrupted to see if you were indicating that > the PRACK reached the service provider and to see who sent the 200 response > (SBC or service provider). > > The PRACK retries are independent of the 18x retries. > > > > > ------------------------------ > > Message: 7 > Date: Fri, 2 Aug 2013 14:23:17 +0000 > From: Brett Tate <br...@broadsoft.com> > Subject: [Sip-implementors] rfc4904: tgrp case sensitivity > To: "sip-implementors@lists.cs.columbia.edu" > <sip-implementors@lists.cs.columbia.edu> > Message-ID: > <576A8B541C219D4E9CEB1DF8C19C7B881A057A32@MBX08.citservers.local> > Content-Type: text/plain; charset="us-ascii" > > Hi, > > I find RFC 4904, RFC 3966, and RFC 3261 somewhat ambiguous concerning tgrp > case sensitivity. I understand the rules from uri perspective: tgrp > case-insensitive within telephone-uri, and tgrp case-sensitive within sip-uri. > > RFC 4904 section 5: > > "For equivalency purposes, two URIs containing trunk group parameters > are equivalent according to the base comparison rules of the URIs. > The base comparison rules of a tel URI are specified in Section 4 of > [4], and the base comparison rules of a sip URI are specified in > Section 19.1.4 of [3]." > > RFC 3966 section 4: > > "o URI comparisons are case-insensitive. > > All parameter names and values SHOULD use lower-case characters, as > tel URIs may be used within contexts where comparisons are case > sensitive." > > RFC 3261 section 19.1.6: > > "In general, equivalent "tel" URLs converted to SIP or SIPS URIs in > this fashion may not produce equivalent SIP or SIPS URIs. The > userinfo of SIP and SIPS URIs are compared as a case-sensitive > string. Variance in case-insensitive portions of tel URLs and > reordering of tel URL parameters does not affect tel URL equivalence, > but does affect the equivalence of SIP URIs formed from them." > > "To mitigate this problem, elements constructing telephone-subscriber > fields to place in the userinfo part of a SIP or SIPS URI SHOULD fold > any case-insensitive portion of telephone-subscriber to lower case, > and order the telephone-subscriber parameters lexically by parameter > name, excepting isdn-subaddress and post-dial, which occur first and > in that order. (All components of a tel URL except for future- > extension parameters are defined to be compared case-insensitive.)" > > However once decoded/extracted out of the sip-uri or telephone-uri, is the > tgrp value case sensitive? Since tgrp is case-insensitive within > telephone-uri's telephone-subscriber (also used by sip-uri), I assume that > the tgrp value is case-insensitive since it would be strange for the tgrp > value to be context sensitive based upon if sent within sip-uri or > telephone-uri. However, I also would not be surprised if someone said that > nobody knows except for the owner of the trunk-context. > > RFC 4904 section 5 examples intentionally or unintentionally ignored RFC 3966 > and RFC 3261 recommendation to use lower case. > > Thanks, > Brett > > This email is intended solely for the person or entity to which it is > addressed and may contain confidential and/or privileged information. If you > are not the intended recipient and have received this email in error, please > notify BroadSoft, Inc. immediately by replying to this message, and destroy > all copies of this message, along with any attachment, prior to reading, > distributing or copying it. > > > > ------------------------------ > > Message: 8 > Date: Sun, 4 Aug 2013 19:23:47 -0400 > From: Hadriel Kaplan <hadriel.kap...@oracle.com> > Subject: Re: [Sip-implementors] rfc4904: tgrp case sensitivity > To: Brett Tate <br...@broadsoft.com> > Cc: "sip-implementors@lists.cs.columbia.edu" > <sip-implementors@lists.cs.columbia.edu> > Message-ID: <3d263dab-591c-4095-b5cd-7601d0af5...@oracle.com> > Content-Type: text/plain; charset=us-ascii > > > On Aug 2, 2013, at 10:23 AM, Brett Tate <br...@broadsoft.com> wrote: > > > However once decoded/extracted out of the sip-uri or telephone-uri, is the > > tgrp value case sensitive? Since tgrp is case-insensitive within > > telephone-uri's telephone-subscriber (also used by sip-uri), I assume that > > the tgrp value is case-insensitive since it would be strange for the tgrp > > value to be context sensitive based upon if sent within sip-uri or > > telephone-uri. However, I also would not be surprised if someone said that > > nobody knows except for the owner of the trunk-context. > > I know for a fact that some devices treat it as case-sensitive for routing > purposes; and I've seen some tgrp strings that are all upper-case or even > mixed-case, although those trunk-context domains didn't use lower-case > counterparts of the same character strings to cause any confusion. My > personal belief is it should be sent all lower-case and treated on receive as > case-insensitive, as a form of "be strict on send, loose on receive", but > convincing all vendors or operators to change existing behavior is a losing > proposition.[1] > > -hadriel > [1] it's debatable if treating it as case-insensitive is a "loose on receive" > model, since it can cause problems if the sender really intended it to be > case-sensitive. > > > > > ------------------------------ > > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > End of Sip-implementors Digest, Vol 125, Issue 1 > ************************************************ _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
