Re: [asterisk-dev] Issue with Parsing Contact Header without Brackets and with additional HeaderParameters seperated with semicolon

2017-06-08 Thread bala murugan 
Here you go george  , i have raised a issue in Jira see below


   1. Asterisk 
   2. 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  wrote:

>
> Bala, are you going to open an issue?
>
>
> On Thu, Jun 8, 2017 at 7:02 AM, 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-contac
>>> t.html#contact-params
>>>
>>> So this is valid:
>>>
>>>   Contact: ;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:p65549t000m112562c59100@10.196.0.111:5089
>>>   contact-params = ;+g.3gpp.accesstype="cellular"
>>> ;+sip.instance=""
>>>
>>
>>
>> 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

Re: [asterisk-dev] Issue with Parsing Contact Header without Brackets and with additional HeaderParameters seperated with semicolon

2017-06-08 Thread George Joseph 
Bala, are you going to open an issue?


On Thu, Jun 8, 2017 at 7:02 AM, 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-contac
>> t.html#contact-params
>>
>> So this is valid:
>>
>>   Contact: ;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:p65549t000m112562c59100@10.196.0.111:5089
>>   contact-params = ;+g.3gpp.accesstype="cellular"
>> ;+sip.instance=""
>>
>
>
> 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

Re: [asterisk-dev] Issue with Parsing Contact Header without Brackets and with additional HeaderParameters seperated with semicolon

2017-06-08 Thread George Joseph 
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: ;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:p65549t000m112562c59100@10.196.0.111:5089
>   contact-params = ;+g.3gpp.accesstype="cellular"
> ;+sip.instance=""
>


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

Re: [asterisk-dev] Issue with Parsing Contact Header without Brackets and with additional HeaderParameters seperated with semicolon

2017-06-08 Thread Walter Doekes 

Bala wrote:

Contact:sip:p65549t000m112562c59100@10.196.0.111:5089 
;+g.3gpp.accesstype="cellular";+sip.instance=""



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:p65549t000m112562c59100@10.196.0.111:5089 
;+g.3gpp.accesstype="cellular";+sip.instance="


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: ;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:p65549t000m112562c59100@10.196.0.111:5089
  contact-params = 
;+g.3gpp.accesstype="cellular";+sip.instance=""


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

Re: [asterisk-dev] Issue with Parsing Contact Header without Brackets and with additional HeaderParameters seperated with semicolon

2017-06-07 Thread George Joseph 
On Wed, Jun 7, 2017 at 5:04 PM, bala murugan  wrote:

> RFC3261 isn't exactly clear on this.  Section 20.10 implies that the
> brackets are optional if a display name isn't specified but the ABNF
> specified down in section 25.1 implies that they are required always
>
> [Bala] I can see section 20.10 mentioned as optional , but in  ABNF
> section 25.1 i couldnt find it mentioned required always
> please advise .
>

Actually I'm going to take back the "required always" bit.
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-readng 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.

So.  It's a bug.  Go ahead and file an issue at
https://issues.asterisk.org



> btw i am using chan_sip
>
>
> Ok.  We'll probably have to fix this in pjproject as well.
-- 
_
-- 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

Re: [asterisk-dev] Issue with Parsing Contact Header without Brackets and with additional HeaderParameters seperated with semicolon

2017-06-07 Thread bala murugan 
RFC3261 isn't exactly clear on this.  Section 20.10 implies that the
brackets are optional if a display name isn't specified but the ABNF
specified down in section 25.1 implies that they are required always

[Bala] I can see section 20.10 mentioned as optional , but in  ABNF section
25.1 i couldnt find it mentioned required always
please advise .

btw i am using chan_sip

On Wed, Jun 7, 2017 at 5:18 PM, George Joseph  wrote:

> On Tue, Jun 6, 2017 at 9:44 AM, bala murugan 
> wrote:
> > Hi ,
> >
> > Can anyone tell me if there is a know bug raised and fixed when we
> handle or
> > Parse Contact Header , if it is presented without brackets
> >
> > I get a INVITE with
> > Contact:sip:p65549t000m112562c59100@10.196.0.111:5089;+g.3gpp.
> accesstype="cellular";+sip.instance=""
> >
> > 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.
>
> RFC3261 isn't exactly clear on this.  Section 20.10 implies that the
> brackets are optional if a display name isn't specified but the ABNF
> specified down in section 25.1 implies that they are required always.
>
> Are you using chan_sip or chan_pjsip?
>
> >
> > sip:p65549t000m112562c59100@10.196.0.111:5089;+g.3gpp.
> accesstype="cellular";+sip.instance=" >
> > Let me know if this is not fixed then will go ahead and raise a bug .
> >
> > thanks,
> > Bala
> >
> > --
> > _
> > -- 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
>
>
>
> --
> 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

Re: [asterisk-dev] Issue with Parsing Contact Header without Brackets and with additional HeaderParameters seperated with semicolon

2017-06-07 Thread bala murugan 
Thanks George ,

I am using chan_sip

On Jun 7, 2017 5:19 PM, "George Joseph"  wrote:

> On Tue, Jun 6, 2017 at 9:44 AM, bala murugan 
> wrote:
> > Hi ,
> >
> > Can anyone tell me if there is a know bug raised and fixed when we
> handle or
> > Parse Contact Header , if it is presented without brackets
> >
> > I get a INVITE with
> > Contact:sip:p65549t000m112562c59100@10.196.0.111:5089;+g.3gpp.
> accesstype="cellular";+sip.instance=""
> >
> > 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.
>
> RFC3261 isn't exactly clear on this.  Section 20.10 implies that the
> brackets are optional if a display name isn't specified but the ABNF
> specified down in section 25.1 implies that they are required always.
>
> Are you using chan_sip or chan_pjsip?
>
> >
> > sip:p65549t000m112562c59100@10.196.0.111:5089;+g.3gpp.
> accesstype="cellular";+sip.instance=" >
> > Let me know if this is not fixed then will go ahead and raise a bug .
> >
> > thanks,
> > Bala
> >
> > --
> > _
> > -- 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
>
>
>
> --
> 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

Re: [asterisk-dev] Issue with Parsing Contact Header without Brackets and with additional HeaderParameters seperated with semicolon

2017-06-07 Thread George Joseph 
On Tue, Jun 6, 2017 at 9:44 AM, bala murugan  wrote:
> Hi ,
>
> Can anyone tell me if there is a know bug raised and fixed when we handle or
> Parse Contact Header , if it is presented without brackets
>
> I get a INVITE with
> Contact:sip:p65549t000m112562c59100@10.196.0.111:5089;+g.3gpp.accesstype="cellular";+sip.instance=""
>
> 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.

RFC3261 isn't exactly clear on this.  Section 20.10 implies that the
brackets are optional if a display name isn't specified but the ABNF
specified down in section 25.1 implies that they are required always.

Are you using chan_sip or chan_pjsip?

>
> sip:p65549t000m112562c59100@10.196.0.111:5089;+g.3gpp.accesstype="cellular";+sip.instance="
> Let me know if this is not fixed then will go ahead and raise a bug .
>
> thanks,
> Bala
>
> --
> _
> -- 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



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

[asterisk-dev] Issue with Parsing Contact Header without Brackets and with additional HeaderParameters seperated with semicolon

2017-06-06 Thread bala murugan 
Hi ,

Can anyone tell me if there is a know bug raised and fixed when we handle
or Parse Contact Header , if it is presented without brackets

I get a INVITE with
Contact:sip:p65549t000m112562c59100@10.196.0.111:5089
;+g.3gpp.accesstype="cellular";+sip.instance=""

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:p65549t000m112562c59100@10.196.0.111:5089
;+g.3gpp.accesstype="cellular";+sip.instance="-- 
_
-- 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