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 > >
-- _____________________________________________________________________ -- 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