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

[George Joseph]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20170608/3d865b1d/attachment.html>