Bala, are you going to open an issue?
On Thu, Jun 8, 2017 at 7:02 AM, George Joseph <gjos...@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@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@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@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@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
