[asterisk-dev] Issue with Parsing Contact Header without Brackets and with additional HeaderParameters seperated with semicolon

[bala murugan]

Here you go george  , i have raised a issue in Jira see below


   1. Asterisk <https://issues.asterisk.org/jira/browse/ASTERISK>
   2. ASTERISK-27045
   <https://issues.asterisk.org/jira/browse/ASTERISK-27045>

Issue with Parsing Contact Header without Brackets and with additional
HeaderParameters seperated with semicolon


On Thu, Jun 8, 2017 at 5:05 PM, George Joseph <gjoseph at digium.com> wrote:

>
> Bala, are you going to open an issue?
>
>
> On Thu, Jun 8, 2017 at 7:02 AM, George Joseph <gjoseph at digium.com> wrote:
>
>>
>>
>> Here's the ABNF:
>>>>
>>>> Contact        =  ("Contact" / "m" ) HCOLON
>>>>                    ( STAR / (contact-param *(COMMA contact-param)))
>>>> contact-param  =  (name-addr / addr-spec) *(SEMI contact-params)
>>>> name-addr      =  [ display-name ] LAQUOT addr-spec RAQUOT
>>>> addr-spec      =  SIP-URI / SIPS-URI / absoluteURI
>>>> display-name   =  *(token LWS)/ quoted-string
>>>>
>>>> After re-reading I realized that "contact-param" can be EITHER  a
>>>> "name-addr" which includes the display name and DOES require the brackets
>>>> OR an "addr-spec" which doesn't include the display name and does NOT
>>>> require the brackets.
>>>>
>>>
>>> Yes, those parameters are an indious bunch, because:
>>>
>>> SIP-URI may contain ";uri-parameters" [1], while the contact-params may
>>> contain ";contact-params" [2]
>>>
>>> [1] http://www.tech-invite.com/fo-abnf/tinv-fo-abnf-sipuriup.html#idx
>>> [2] http://www.tech-invite.com/fo-abnf/tinv-fo-abnf-sip-h-contac
>>> t.html#contact-params
>>>
>>> So this is valid:
>>>
>>>   Contact: <sip:line1 at 192.0.2.2;transport=tcp>;reg-id=1;expires=60
>>>
>>> And so would this be (except, it isn't, read on):
>>>
>>>   Contact: sip:line1 at 192.0.2.2;transport=tcp;reg-id=1;expires=60
>>>
>>> In which case you wouldn't be able to separate the uri-parameters from
>>> the contact-params.
>>>
>>> Luckily, there is this in RFC3261, 20.10 "Contact":
>>>
>>>    [...] If no "<"
>>>>    and ">" are present, all parameters after the URI are header
>>>>    parameters, not URI parameters.
>>>>
>>>
>>> and
>>>
>>>    Even if the "display-name" is empty, the "name-addr" form MUST be
>>>>    used if the "addr-spec" contains a comma, semicolon, or question
>>>>    mark.
>>>>
>>>
>>> Without the transport=tcp, it would be valid:
>>>
>>>   Contact: sip:line1 at 192.0.2.2;reg-id=1;expires=60
>>>
>>>
>>> So, even though you cannot tell from just the ABNF, the mentioned
>>> Contact should be parsed as follows:
>>>
>>>   addr-spec = sip:p65549t0000000m112562c591000000 at 10.196.0.111:5089
>>>   contact-params = ;+g.3gpp.accesstype="cellular"
>>> ;+sip.instance="<urn:gsma:imei:3561119000-996900-0>"
>>>
>>
>>
>> I had to go back and forth between 20.10 and the ABNF a few times but
>> yeah, agreed.
>>
>>
>>
>>>
>>> Hence: the wrongly stored fullcontact is too long, not too short.
>>>
>>>
>>> Walter
>>>
>>>
>
>
> --
> George Joseph
> Digium, Inc. | Software Developer
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - US
> Check us out at: www.digium.com & www.asterisk.org
>
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20170608/bf8e3a66/attachment.html>