Bala wrote:
Contact:sip:p65549t0000000m112562c591000000@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@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@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>"
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
