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:[email protected];transport=tcp>;reg-id=1;expires=60
>
> And so would this be (except, it isn't, read on):
>
> Contact: sip:[email protected];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:[email protected];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:[email protected]: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
>
>
--
_____________________________________________________________________
-- 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
