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

[Walter Doekes]

Bala wrote:
> Contact:sip:p65549t0000000m112562c591000000 at 10.196.0.111:5089 ;+g.3gpp.accesstype="cellular";+sip.instance="<urn:gsma:imei:3561119000-996900-0>"

> Currently this is getting parsed incorrectly based on the closed brackets and we end up storing the fullcontact with incomplete URI (metnioned below) and same is sent in the BYE REQURI.

> sip:p65549t0000000m112562c591000000 at 10.196.0.111:5089 ;+g.3gpp.accesstype="cellular";+sip.instance="<urn:gsma:imei:3561119000-996900-0


On 08-06-17 02:12, George Joseph 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-contact.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>"

Hence: the wrongly stored fullcontact is too long, not too short.


Walter