SIP and IPv6
On Fri, Aug 23, 2013 at 2:05 PM, < [email protected]> wrote: > 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. SIP security over UDP (DTLS ?) (Tim Ruehsen) > 2. Query regarding user=phone in SIP RURI (Suraj Singh) > 3. Re: Query regarding user=phone in SIP RURI (Brett Tate) > 4. Re: Query regarding user=phone in SIP RURI (Michael Coffee) > 5. Re: Query regarding user=phone in SIP RURI (Brett Tate) > 6. SIP and IPv6 (Olle E. Johansson) > 7. Question about proxy clustering ( SIP Learner ) > 8. Re: Sip-implementors Digest, Vol 125, Issue 1 (Sakharam Thorat) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 05 Aug 2013 13:42:55 +0200 > From: Tim Ruehsen <[email protected]> > Subject: [Sip-implementors] SIP security over UDP (DTLS ?) > To: [email protected] > Message-ID: <11982151.AYsCRL3Q4D@blitz-lx> > Content-Type: text/plain; charset="us-ascii" > > What is the status of SIP over DTLS ? > > The only paper I found is a draft and pretty old... > http://tools.ietf.org/html/draft-jennings-sip-dtls-05 > > Regards, Tim > > > ------------------------------ > > Message: 2 > Date: Tue, 13 Aug 2013 11:04:00 -0500 > From: Suraj Singh <[email protected]> > Subject: [Sip-implementors] Query regarding user=phone in SIP RURI > To: [email protected] > Message-ID: > < > cagu9vts60vlsrwlki8wem5mpz9qsimcvswwvzxnq3kit6ys...@mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Hi All, > > I have a small query regarding SIP RURI, > > If we have user=phone in SIP RURI for a Re-Invite, is it mandatory that DN > must be provided in SIP RURI? > > Below are examples of good and bad RURIs, > > *Good Initial Invite* > > Invite *Request URI: > sip:+14567891234;[email protected]:8191 > ;user=phone<sip:+12292397701;[email protected]:5060;user=phone> > * > > > *Rejected Re-Invite :* > > Invite *Request URI: sip: <sip:10.77.27.113:5060;user=phone>** > 10.97.00.102:8191; <sip:+12292397701;[email protected]:5060;user=phone>** > user=phone <sip:10.77.27.113:5060;user=phone>* > > > Thanks, > > Sam > > > ------------------------------ > > Message: 3 > Date: Wed, 14 Aug 2013 10:27:36 +0000 > From: Brett Tate <[email protected]> > Subject: Re: [Sip-implementors] Query regarding user=phone in SIP RURI > To: Suraj Singh <[email protected]>, > "[email protected]" > <[email protected]> > Message-ID: > <[email protected]> > Content-Type: text/plain; charset="us-ascii" > > > If we have user=phone in SIP RURI for a Re-Invite, > > is it mandatory that DN must be provided in SIP RURI? > > My understanding of RFC 3261 (and RFC 2543) is that user=phone indicates > that the user portion can be decoded as a telephone-subscriber. However, > RFC 3261 is too vague concerning the topic. It indicates to set user=phone > when adding telephone-subscriber without explicitly indicating that it is > the only use of user=phone. > > Thus some vendors interpret user=phone as though it doesn't imply that the > user can be decoded as a telephone-subscriber. However, I disagree with > this interpretation because it means that nothing indicates that the user > portion can be decoded as telephone-subscriber. Since "user URI parameter > exists to distinguish telephone numbers from user names that happen to look > like telephone numbers", I find it strange to include user=phone to > indicate that "anonymous" or "" are telephone numbers. > > For information, see the following thread. > > > https://lists.cs.columbia.edu/pipermail/sip-implementors/2013-February/028941.html > > Concerning mid-dialog requests, the UA has little control over the > contents of the request-uri since it is populated per received Contact or > Record-Route entry. Because of the sip-uri equality impacts within > responses or mid-dialog requests, I do not recommend the UA "fix" the > user=phone setting per their own interpretation. > > Concerning the examples that you sent, your email client is likely > corrupting them. Thus I have no comment upon them specifically. > > > > > ------------------------------ > > Message: 4 > Date: Wed, 14 Aug 2013 08:51:09 -0400 (EDT) > From: Michael Coffee <[email protected]> > Subject: Re: [Sip-implementors] Query regarding user=phone in SIP RURI > To: Brett Tate <[email protected]> > Cc: Suraj Singh <[email protected]>, > [email protected] > Message-ID: > <[email protected]> > Content-Type: text/plain; charset=utf-8 > > RFC3840 and 3841 may provide some guidance. > > > > ----- Original Message ----- > From: "Brett Tate" <[email protected]> > To: "Suraj Singh" <[email protected]>, > [email protected] > Sent: Wednesday, August 14, 2013 6:27:36 AM > Subject: Re: [Sip-implementors] Query regarding user=phone in SIP RURI > > > If we have user=phone in SIP RURI for a Re-Invite, > > is it mandatory that DN must be provided in SIP RURI? > > My understanding of RFC 3261 (and RFC 2543) is that user=phone indicates > that the user portion can be decoded as a telephone-subscriber. However, > RFC 3261 is too vague concerning the topic. It indicates to set user=phone > when adding telephone-subscriber without explicitly indicating that it is > the only use of user=phone. > > Thus some vendors interpret user=phone as though it doesn't imply that the > user can be decoded as a telephone-subscriber. However, I disagree with > this interpretation because it means that nothing indicates that the user > portion can be decoded as telephone-subscriber. Since "user URI parameter > exists to distinguish telephone numbers from user names that happen to look > like telephone numbers", I find it strange to include user=phone to > indicate that "anonymous" or "" are telephone numbers. > > For information, see the following thread. > > > https://lists.cs.columbia.edu/pipermail/sip-implementors/2013-February/028941.html > > Concerning mid-dialog requests, the UA has little control over the > contents of the request-uri since it is populated per received Contact or > Record-Route entry. Because of the sip-uri equality impacts within > responses or mid-dialog requests, I do not recommend the UA "fix" the > user=phone setting per their own interpretation. > > Concerning the examples that you sent, your email client is likely > corrupting them. Thus I have no comment upon them specifically. > > > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > ------------------------------ > > Message: 5 > Date: Wed, 14 Aug 2013 13:25:26 +0000 > From: Brett Tate <[email protected]> > Subject: Re: [Sip-implementors] Query regarding user=phone in SIP RURI > To: Michael Coffee <[email protected]>, > "[email protected]" > <[email protected]> > Message-ID: > <[email protected]> > Content-Type: text/plain; charset="utf-8" > > As far as I know, RFC 3840 and RFC 3841 do not provide any guidance > concerning the meaning of user=phone within sip-uri. > > However, the user=phone topic was raised while working on > draft-ietf-martini-gin since some wanted to allow user=phone when no > userinfo. The conclusion was to not fix the RFC 3261 user=phone ambiguity; > however RFC 6140 section 5.3 does prevent adding the user parameter when > including parameter "bnc". > > > > -----Original Message----- > > From: Michael Coffee [mailto:[email protected]] > > Sent: Wednesday, August 14, 2013 8:51 AM > > To: Brett Tate > > Cc: Suraj Singh; [email protected] > > Subject: Re: [Sip-implementors] Query regarding user=phone in SIP RURI > > > > RFC3840 and 3841 may provide some guidance. > > > > > > > > ----- Original Message ----- > > From: "Brett Tate" <[email protected]> > > To: "Suraj Singh" <[email protected]>, sip- > > [email protected] > > Sent: Wednesday, August 14, 2013 6:27:36 AM > > Subject: Re: [Sip-implementors] Query regarding user=phone in SIP RURI > > > > > If we have user=phone in SIP RURI for a Re-Invite, > > > is it mandatory that DN must be provided in SIP RURI? > > > > My understanding of RFC 3261 (and RFC 2543) is that user=phone > > indicates that the user portion can be decoded as a telephone- > > subscriber. However, RFC 3261 is too vague concerning the topic. It > > indicates to set user=phone when adding telephone-subscriber without > > explicitly indicating that it is the only use of user=phone. > > > > Thus some vendors interpret user=phone as though it doesn't imply that > > the user can be decoded as a telephone-subscriber. However, I disagree > > with this interpretation because it means that nothing indicates that > > the user portion can be decoded as telephone-subscriber. Since "user > > URI parameter exists to distinguish telephone numbers from user names > > that happen to look like telephone numbers", I find it strange to > > include user=phone to indicate that "anonymous" or "" are telephone > > numbers. > > > > For information, see the following thread. > > > > https://lists.cs.columbia.edu/pipermail/sip-implementors/2013- > > February/028941.html > > > > Concerning mid-dialog requests, the UA has little control over the > > contents of the request-uri since it is populated per received Contact > > or Record-Route entry. Because of the sip-uri equality impacts within > > responses or mid-dialog requests, I do not recommend the UA "fix" the > > user=phone setting per their own interpretation. > > > > Concerning the examples that you sent, your email client is likely > > corrupting them. Thus I have no comment upon them specifically. > > > > > ------------------------------ > > Message: 6 > Date: Mon, 19 Aug 2013 11:14:43 +0200 > From: "Olle E. Johansson" <[email protected]> > Subject: [Sip-implementors] SIP and IPv6 > To: "[email protected] > [email protected]" > <[email protected]> > Message-ID: <[email protected]> > Content-Type: text/plain; charset=us-ascii > > The SIP Forum IPv6 working group has approached a number of issues related > to IPv6 migration in SIP. > > One of the documents we have produced covers impacts on IPv4-only devices. > Even if you haven't added IPv6 support to your SIP implementation, you need > to test your software for issues. This document has been contributed to the > IETF and will hopefully > at some point become an RFC. You can read it as an IETF draft: > > http://tools.ietf.org/html/draft-klatsky-dispatch-ipv6-impact-ipv4-01 > > Feedback is always welcome! > > On our mailing list we are currently discussing Happy Eyeballs - how do we > handle connection support when both client and server is dual stack? If one > of the networks is disconnected - how do we fail over? We don't want users > to be unhappy when IPv6 is added to the SIP infrastructure. > > Join the group mailing list and participate in the discussion! Find out > more here: > http://www.sipforum.org/content/view/398/286/ > > See you on the mailing list! > > Best regards, > /Olle E. Johansson > Co-Chair of the SIP Forum IPv6 wg > > > ------------------------------ > > Message: 7 > Date: Wed, 21 Aug 2013 16:34:28 +0800 > From: " SIP Learner " <[email protected]> > Subject: [Sip-implementors] Question about proxy clustering > To: " sip-implementors " <[email protected]> > Message-ID: <[email protected]> > Content-Type: text/plain; charset="utf-8" > > Dear all, > > > the 2nd paragraph on page 4 of RFC 3263 reads "...assume that proxy 2 is > implemented as a cluster of two proxies, proxy 2.1 and proxy 2.2.". > > > Are there any standardized approach to SIP proxy clustering? If no > standard practices exist, are there any reference materials to this > respect? thanks in advance! > > > Best regards, > > > ZHANG > > ------------------------------ > > Message: 8 > Date: Fri, 23 Aug 2013 14:05:03 +0530 > From: Sakharam Thorat <[email protected]> > Subject: Re: [Sip-implementors] Sip-implementors Digest, Vol 125, > Issue 1 > To: "[email protected]" > <[email protected]> > Message-ID: <[email protected]> > Content-Type: text/plain; charset="iso-8859-1" > > How to test device for rfc 3261 complience ? > > > > Best Regards,Sakharam Thorat. > > > From: [email protected] > > Subject: Sip-implementors Digest, Vol 125, Issue 1 > > To: [email protected] > > Date: Sun, 4 Aug 2013 19:24:04 -0400 > > > > 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. 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 <[email protected]> > > Subject: [Sip-implementors] Instant messaging using sip for bb 10 > > To: [email protected] > > Message-ID: > > <CAEoHT-Z9oy96JgBrSP6voVNZEp5vX2j5Dua6N= > [email protected]> > > 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 <[email protected]> > > Subject: [Sip-implementors] Open-IMS S-CSCF node sending wrong value > > in Contact header in 200 OK of Subscribe > > To: [email protected] > > 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 <[email protected]> > > Subject: [Sip-implementors] Want to build RCS client over a sip stack > > To: [email protected] > > Message-ID: > > <[email protected]> > > 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 <[email protected]> > > Subject: Re: [Sip-implementors] Open-IMS S-CSCF node sending wrong > > value in Contact header in 200 OK of Subscribe > > To: Mangal Singh <[email protected]>, > > "[email protected]" > > <[email protected]> > > 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:[email protected]] > > Sent: Tuesday, July 30, 2013 3:31 PM > > To: [email protected] > > 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 > > [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: 5 > > Date: Thu, 1 Aug 2013 12:21:08 +0000 > > From: Jason Harrison <[email protected]> > > Subject: [Sip-implementors] How should UAC handle a retransmit of a > > reliable provisional response > > To: "[email protected]" > > <[email protected]> > > 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 <[email protected]> > > Subject: Re: [Sip-implementors] How should UAC handle a retransmit of > > a reliable provisional response > > To: Jason Harrison <[email protected]>, > > "[email protected]" > > <[email protected]> > > Message-ID: > > <[email protected]> > > 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 <[email protected]> > > Subject: [Sip-implementors] rfc4904: tgrp case sensitivity > > To: "[email protected]" > > <[email protected]> > > Message-ID: > > <[email protected]> > > 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 <[email protected]> > > Subject: Re: [Sip-implementors] rfc4904: tgrp case sensitivity > > To: Brett Tate <[email protected]> > > Cc: "[email protected]" > > <[email protected]> > > Message-ID: <[email protected]> > > Content-Type: text/plain; charset=us-ascii > > > > > > On Aug 2, 2013, at 10:23 AM, Brett Tate <[email protected]> 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 > > [email protected] > > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > > End of Sip-implementors Digest, Vol 125, Issue 1 > > ************************************************ > > > ------------------------------ > > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > End of Sip-implementors Digest, Vol 125, Issue 2 > ************************************************ > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
