Here you go george , i have raised a issue in Jira see below
1. Asterisk <https://issues.asterisk.org/jira/browse/ASTERISK> 2. ASTERISK-27045 <https://issues.asterisk.org/jira/browse/ASTERISK-27045> Issue with Parsing Contact Header without Brackets and with additional HeaderParameters seperated with semicolon On Thu, Jun 8, 2017 at 5:05 PM, George Joseph <gjos...@digium.com> wrote: > > 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 >
-- _____________________________________________________________________ -- 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