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

Reply via email to