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

[George Joseph]

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