I agree "doing nothing wrong" seems like a better verdict. :) Its implementors could have been more considerate of naive/ignorant implementations though.
-Max On Fri., Aug. 14, 2020, 9:13 a.m. Paul Kyzivat, <pkyzi...@alum.mit.edu> wrote: > On 8/14/20 10:25 AM, Maxim Sobolev wrote: > > Paul, there is no space between colon and the rest of the call-id in the > > original example provided. So UAC seems to be doing the right thing I > think. > > > > Call-ID: :VaT4082403130oFbc > > <mailto: > vat4082403130ofbcghefckco...@mscsma1.ims.mnc007.mcc748.3gppnetwork.org>... > > > > OK. If there is no space then I agree that the UAC is doing nothing wrong. > > Thanks, > Paul > > > -Max > > > > > > On Thu., Aug. 13, 2020, 8:15 a.m. Paul Kyzivat, <pkyzi...@alum.mit.edu > > <mailto:pkyzi...@alum.mit.edu>> wrote: > > > > Pravin, Gaurav, > > > > On 8/13/20 5:34 AM, Pravin Kumar wrote: > > > Hi Gaurav, > > > > > > You can refer to RFC3261 Call-ID ABNF syntax section: > > > > > > [RFC3261 - page 228] > > > > > > Call-ID = ( "Call-ID" / "i" ) HCOLON callid > > > callid = word [ "@" word ] > > > > > > [RFC3261 - page221] > > > > > > word = 1*(alphanum / "-" / "." / "!" / "%" / "*" / > > > "_" / "+" / "`" / "'" / "~" / > > > "(" / ")" / "<" / ">" / > > > ":" / "\" / DQUOTE / > > > "/" / "[" / "]" / "?" / > > > "{" / "}" ) > > > > > > If you observe here ":" is allowed in call-id irrespective to > > position. So > > > in your case UAS behaviour is not correct to remove the ":". > -pravin > > > > I agree that colon is allowed in call-id, but whitespace is not. So > it > > appears to me that the UAC has erred. > > > > Exactly what the UAS should do in this case is not defined. I would > > suggest you either: > > > > 1) reject the request with a 400 response > > 2) ignore the error and use the call-id as-is > > > > The fact that your uas ignored the colon suggests to me that its > parser > > is acting in an unjustified way. (Ad hoc parsing?) > > > > Thanks, > > Paul > > > > > On Thu, Aug 13, 2020 at 2:30 PM Gaurav Khare > > <gaurav.kh...@onmobile.com <mailto:gaurav.kh...@onmobile.com>> > > > wrote: > > > > > >> Hi, > > >> > > >> I have a specific problem relating to SIP header format. > > >> > > >> A UAC is sending Call-ID Header in INVITE as below > > >> Call-ID: : > > >> > > > vat4082403130ofbcghefckco...@mscsma1.ims.mnc007.mcc748.3gppnetwork.org > > <mailto: > vat4082403130ofbcghefckco...@mscsma1.ims.mnc007.mcc748.3gppnetwork.org> > > >> > > >> My UAS is sending 180 Ringing response as > > >> Call-ID: > > >> > > > vat4082403130ofbcghefckco...@mscsma1.ims.mnc007.mcc748.3gppnetwork.org > > <mailto: > vat4082403130ofbcghefckco...@mscsma1.ims.mnc007.mcc748.3gppnetwork.org> > > >> <mailto: > > >> > > > vat4082403130ofbcghefckco...@mscsma1.ims.mnc007.mcc748.3gppnetwork.org > > <mailto: > vat4082403130ofbcghefckco...@mscsma1.ims.mnc007.mcc748.3gppnetwork.org>> > > >> > > >> Notice the two colons in UAC request. In the response my stack > > is ignoring > > >> additional Colon(:) but the response is rejected by UAC. I am > > perplexed as > > >> to if colon(:) can be a part of Call-ID value or if two > > Colons(:) can occur > > >> sequentially delimiting Header name and value. > > >> > > >> If someone can point me to a Section of RFC, it will be very > > helpful. > > >> > > >> Thanks in advance, > > >> Gaurav Khare > > >> > > >> > > >> > > >> ________________________________ > > >> > > >> DISCLAIMER: The information in this message is confidential and > > may be > > >> legally privileged. It is intended solely for the addressee. > > Access to this > > >> message by anyone else is unauthorized. If you are not the > intended > > >> recipient, any disclosure, copying, or distribution of the > > message, or any > > >> action or omission taken by you in reliance on it, is prohibited > > and may be > > >> unlawful. Please immediately contact the sender if you have > > received this > > >> message in error. Further, this e-mail may contain viruses and > all > > >> reasonable precaution to minimize the risk arising there from is > > taken by > > >> OnMobile. OnMobile is not liable for any damage sustained by you > > as a > > >> result of any virus in this e-mail. All applicable virus checks > > should be > > >> carried out by you before opening this e-mail or any attachment > > thereto. > > >> Thank you - OnMobile Global Limited. > > >> _______________________________________________ > > >> Sip-implementors mailing list > > >> Sip-implementors@lists.cs.columbia.edu > > <mailto:Sip-implementors@lists.cs.columbia.edu> > > >> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > >> > > > > > > > > > > _______________________________________________ > > Sip-implementors mailing list > > Sip-implementors@lists.cs.columbia.edu > > <mailto:Sip-implementors@lists.cs.columbia.edu> > > https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > > _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
