[SR-Users] path uri problem

[Iñaki Baz Castillo]

As I said before, this Path header

  Path: <sip:10.59.1.195;lr;received='sip:10.59.1.241:5079;transport=tcp'>

has a URI with these params:

  - lr  :  no value
  - received  :   'sip:10.59.1.241:5079
  - transport  :  tcp'

And this is because quoting a *URI param* between single quotes is a
bug in Kamailio.

Due to this bug, FreeSwitch finds a "transport" param in the Path URI
with value tcp'  (note the single quote ' at the end of "tcp") and,
maybe, it parses it as "tcp" so chooses TCP for sending the initial
requests.

Indeed, the Route header added by FS is:

 Route: <sip:10.59.1.195;lr;received=sip:10.59.1.241:5079;transport=tcp>

Which means that it has "transport=tcp" and, of course, it tries TCP.

I insist, this is a bug in Kamailio since single quote and "=" symbols
should be escaped when present a SIP URI parameter value.

2013/4/10 Spencer Thomason <spencer at 5ninesolutions.com>:
> Although slightly off topic, I've been trying to craft a Path header that will work with FreeSWITCH.
>
> See:
> http://jira.freeswitch.org/browse/FS-4989
>
> It would be great if the Path header was compatible with what they want as well.
>
> BR,
> Spencer
>
> On Apr 9, 2013, at 4:05 PM, Iñaki Baz Castillo wrote:
>
>> 2013/4/9 Richard Fuchs <rfuchs at sipwise.com>:
>>> On 04/09/13 12:19, Iñaki Baz Castillo wrote:
>>>
>>>> So the "received" value added by Kamailio is invalid. Such a value
>>>> cannot be the value of a SIP URI parameter at all. I strongly propose
>>>> encoding it in base64 or escaping the "=" and the ";" symbols when in
>>>> a SIP URI param value as Juha suggests.
>>>
>>> Would you and everyone else agree that unconditionally encoding the
>>> param in base64 would be the preferred solution? I have some pending
>>> additions to the path module and could include that as well.
>>
>>
>> No. SIP already requires hex-(un)escaping in various places (i.e. the
>> Replaces header requires it, a URI username could require it, etc), so
>> it's expected that SIP libraries/clients/servers already include
>> hex-(un)escaping support.
>>
>> In the other side I don't remember any place in core SIP protocol in
>> which Base64 is used, neither I know wheter Kamailio has built-in code
>> for it or not (well, it's an easy addition anyhow...).
>>
>> IMHO using the SIP core mechanisms for these kinds of needs (thus
>> hex-(un)escaping) is the correct choice, but since the ;received URI
>> param is a non standard hack which just Kamailio needs and
>> understands, it can be done in any way.
>>
>> Regards.
>>
>> --
>> Iñaki Baz Castillo
>> <ibc at aliax.net>
>>
>> _______________________________________________
>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>> sr-users at lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users



-- 
Iñaki Baz Castillo
<ibc at aliax.net>