i also tried by removing single quotes from received value:

Path: sip:192.98.102.10;transport=tcp;lr;received=sip:192.98.102.10:58222%3Btransport%3Dtcp

since they are not serving any purpose, but that didn't help either.

-- juha

Andrew Pogrebennyk writes:

I don't see why you think that ; and = should be escaped.

rfc3327 chapter 4 says:

The syntax for Path is defined as follows:

Path = "Path" HCOLON path-value *( COMMA path-value )

path-value = name-addr *( SEMI rr-param )

because path-value starts with name-addr and my interpretation is that since there are <>s around this path header body:

Path: sip:192.98.102.10;transport=tcp;lr;received='sip:192.98.102.10:58156%3Btransport%3Dtcp'

solely consists of name-addr and does not include any rr-params. sip uri included in name-addr in turn cannot have ; and = in its param values.

it turned out that save error had nothing to do with syntax of path header, but was due to a bug that i fixed.

-- juha

2013/4/9 Juha Heinanen jh@tutpro.com:

because path-value starts with name-addr and my interpretation is that since there are <>s around this path header body:

Path: sip:192.98.102.10;transport=tcp;lr;received='sip:192.98.102.10:58156%3Btransport%3Dtcp'

solely consists of name-addr and does not include any rr-params. sip uri included in name-addr in turn cannot have ; and = in its param values.

In the above Path there is NO header params but JUST URI params (header params would be placed after the ">"). And indeed the above usage is INCORRECT. This is what happens when parsing a Route or Path header as the above:

Path: sip:192.98.102.10;transport=tcp;lr;received='sip:192.98.102.10:58156%3Btransport%3Dtcp'

Parsing result:

- display name: null - schema: sip - user: null - host: "192.98.102.10" (ipv4) - port: null - params: { "transport"=>"tcp'", "lr"=>null, "received"=>"'sip:192.98.102.10:58156", "transport"=> "tcp'" }

Do you see it? the above Path is BNF valid but 100% unexpected as there are the following URI params/values (now without double quotes):

transport : tcp lr : received : 'sip:192.98.102.10:58156 <-- note the initial ' !!! transport : tcp' <-- note the final ' !!!!

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.

Regards.

-- Iñaki Baz Castillo ibc@aliax.net

2013/4/9 Richard Fuchs rfuchs@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@aliax.net

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@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@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@aliax.net

---

SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

below is patch that fixes receiced param value. i have not tested if kamalio that gets such a value is able to unescape the escaped chars. if not, that is a bug too.

-- juha

*** path.c Fri Mar 29 19:14:46 2013 --- /usr/src/sip-router/modules/path/path.c Wed Apr 10 08:09:43 2013 *************** *** 145,171 **** if (param == PATH_PARAM_RECEIVED) { /* TODO: agranig: optimize this one! */ src_ip = ip_addr2a(&_m->rcv.src_ip); ! rcv_addr.s = pkg_malloc(6 + IP_ADDR_MAX_STR_SIZE + 22); /* 'sip:<ip>:<port>;transport=sctp'\0 */ if(!rcv_addr.s) { LM_ERR("no pkg memory left for receive-address\n"); goto out3; } switch (_m->rcv.proto) { case PROTO_UDP: ! rcv_addr.len = snprintf(rcv_addr.s, 6 + IP_ADDR_MAX_STR_SIZE + 6, "'sip:%s:%u'", src_ip, _m->rcv.src_port); break; case PROTO_TCP: ! rcv_addr.len = snprintf(rcv_addr.s, 6 + IP_ADDR_MAX_STR_SIZE + 20, "'sip:%s:%u;transport=tcp'", src_ip, _m->rcv.src_port); break; case PROTO_TLS: ! rcv_addr.len = snprintf(rcv_addr.s, 6 + IP_ADDR_MAX_STR_SIZE + 20, "'sip:%s:%u;transport=tls'", src_ip, _m->rcv.src_port); break; case PROTO_SCTP: ! rcv_addr.len = snprintf(rcv_addr.s, 6 + IP_ADDR_MAX_STR_SIZE + 21, "'sip:%s:%u;transport=sctp'", src_ip, _m->rcv.src_port); break; case PROTO_WS: case PROTO_WSS: ! rcv_addr.len = snprintf(rcv_addr.s, 6 + IP_ADDR_MAX_STR_SIZE + 19, "'sip:%s:%u;transport=ws'", src_ip, _m->rcv.src_port); break; }

--- 145,171 ---- if (param == PATH_PARAM_RECEIVED) { /* TODO: agranig: optimize this one! */ src_ip = ip_addr2a(&_m->rcv.src_ip); ! rcv_addr.s = pkg_malloc(6 + IP_ADDR_MAX_STR_SIZE + 24); /* sip:<ip>:<port>%3Btransport%3Dsctp\0 */ if(!rcv_addr.s) { LM_ERR("no pkg memory left for receive-address\n"); goto out3; } switch (_m->rcv.proto) { case PROTO_UDP: ! rcv_addr.len = snprintf(rcv_addr.s, 6 + IP_ADDR_MAX_STR_SIZE + 4, "sip:%s:%u", src_ip, _m->rcv.src_port); break; case PROTO_TCP: ! rcv_addr.len = snprintf(rcv_addr.s, 6 + IP_ADDR_MAX_STR_SIZE + 22, "sip:%s:%u%%3Btransport%%3Dtcp", src_ip, _m->rcv.src_port); break; case PROTO_TLS: ! rcv_addr.len = snprintf(rcv_addr.s, 6 + IP_ADDR_MAX_STR_SIZE + 22, "sip:%s:%u%%3Btransport%%3Dtls", src_ip, _m->rcv.src_port); break; case PROTO_SCTP: ! rcv_addr.len = snprintf(rcv_addr.s, 6 + IP_ADDR_MAX_STR_SIZE + 23, "sip:%s:%u%%3Btransport%%3Dsctp", src_ip, _m->rcv.src_port); break; case PROTO_WS: case PROTO_WSS: ! rcv_addr.len = snprintf(rcv_addr.s, 6 + IP_ADDR_MAX_STR_SIZE + 21, "sip:%s:%u%%3Btransport%%3Dws", src_ip, _m->rcv.src_port); break; }

BTW not sure if your patch does it but I strongly suggest removing the useless and wrong single quotes around the received value (once such a value is properly hex-escaped it becomes a valid URI param value). Please remember that single quote is NOT a valid delimitator AT ALL for a SIP URI parameter value.

Regards.

2013/4/10 Iñaki Baz Castillo ibc@aliax.net:

Juha, could you please paste here how the Path above looks with your change?

Thanks a lot.

2013/4/10 Juha Heinanen jh@tutpro.com:

...

below is patch that fixes receiced param value. i have not tested if kamalio that gets such a value is able to unescape the escaped chars. if not, that is a bug too.

-- juha

*** path.c Fri Mar 29 19:14:46 2013 --- /usr/src/sip-router/modules/path/path.c Wed Apr 10 08:09:43 2013

---

*** 145,171 **** if (param == PATH_PARAM_RECEIVED) { /* TODO: agranig: optimize this one! */ src_ip = ip_addr2a(&_m->rcv.src_ip); ! rcv_addr.s = pkg_malloc(6 + IP_ADDR_MAX_STR_SIZE + 22); /* 'sip:<ip>:<port>;transport=sctp'\0 */ if(!rcv_addr.s) { LM_ERR("no pkg memory left for receive-address\n"); goto out3; } switch (_m->rcv.proto) { case PROTO_UDP: ! rcv_addr.len = snprintf(rcv_addr.s, 6 + IP_ADDR_MAX_STR_SIZE + 6, "'sip:%s:%u'", src_ip, _m->rcv.src_port); break; case PROTO_TCP: ! rcv_addr.len = snprintf(rcv_addr.s, 6 + IP_ADDR_MAX_STR_SIZE + 20, "'sip:%s:%u;transport=tcp'", src_ip, _m->rcv.src_port); break; case PROTO_TLS: ! rcv_addr.len = snprintf(rcv_addr.s, 6 + IP_ADDR_MAX_STR_SIZE + 20, "'sip:%s:%u;transport=tls'", src_ip, _m->rcv.src_port); break; case PROTO_SCTP: ! rcv_addr.len = snprintf(rcv_addr.s, 6 + IP_ADDR_MAX_STR_SIZE + 21, "'sip:%s:%u;transport=sctp'", src_ip, _m->rcv.src_port); break; case PROTO_WS: case PROTO_WSS: ! rcv_addr.len = snprintf(rcv_addr.s, 6 + IP_ADDR_MAX_STR_SIZE + 19, "'sip:%s:%u;transport=ws'", src_ip, _m->rcv.src_port); break; }

--- 145,171 ---- if (param == PATH_PARAM_RECEIVED) { /* TODO: agranig: optimize this one! */ src_ip = ip_addr2a(&_m->rcv.src_ip); ! rcv_addr.s = pkg_malloc(6 + IP_ADDR_MAX_STR_SIZE + 24); /* sip:<ip>:<port>%3Btransport%3Dsctp\0 */ if(!rcv_addr.s) { LM_ERR("no pkg memory left for receive-address\n"); goto out3; } switch (_m->rcv.proto) { case PROTO_UDP: ! rcv_addr.len = snprintf(rcv_addr.s, 6 + IP_ADDR_MAX_STR_SIZE + 4, "sip:%s:%u", src_ip, _m->rcv.src_port); break; case PROTO_TCP: ! rcv_addr.len = snprintf(rcv_addr.s, 6 + IP_ADDR_MAX_STR_SIZE + 22, "sip:%s:%u%%3Btransport%%3Dtcp", src_ip, _m->rcv.src_port); break; case PROTO_TLS: ! rcv_addr.len = snprintf(rcv_addr.s, 6 + IP_ADDR_MAX_STR_SIZE + 22, "sip:%s:%u%%3Btransport%%3Dtls", src_ip, _m->rcv.src_port); break; case PROTO_SCTP: ! rcv_addr.len = snprintf(rcv_addr.s, 6 + IP_ADDR_MAX_STR_SIZE + 23, "sip:%s:%u%%3Btransport%%3Dsctp", src_ip, _m->rcv.src_port); break; case PROTO_WS: case PROTO_WSS: ! rcv_addr.len = snprintf(rcv_addr.s, 6 + IP_ADDR_MAX_STR_SIZE + 21, "sip:%s:%u%%3Btransport%%3Dws", src_ip, _m->rcv.src_port); break; }

---

SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

-- Iñaki Baz Castillo ibc@aliax.net

2013/4/10 Juha Heinanen jh@tutpro.com:

here is an example:

Path: sip:192.98.102.10:5070;transport=tcp;lr;received=sip:192.98.102.11:35449%3Btransport%3Dtcp.

Perfect.

as you see, single quotes are gone, because they don't serve any purpose after escape.

Not exactly, I want to insist on this: Single quotes did not server any purpose previously because using single quotes to delimit an URI param value is 100% wrong. As said in a previous mail, a perfect SIP parser would parse the initial wrong Path as follows (just info about URI params):

transport : tcp lr : (no value) received : 'sip:192.98.102.10:58156 <-- note the initial ' !!! transport : tcp' <-- note the final ' !!!!

So the single quote means nothing. There could be zero or N single quotes within or around an URI param value.

-- Iñaki Baz Castillo ibc@aliax.net

Juha Heinanen writes:

i tested and even when url path field contains escaped chars. however, i started to get these to syslog every 20 seconds

Apr 10 12:17:08 wheezy1 /usr/sbin/sip-proxy[3900]: ERROR: nathelper [nathelper.c:2018]: can't parse contact uri

most likely due to nat pinging. i haven't checked yet where they come from. contact field of the ua does not have any escaped chars in it.

i added the uri to the error message and got:

nathelper [nathelper.c:2019]: can't parse contact uri 'sip:192.98.102.11:35453%3Btransport%3Dtcp'

single quotes are from my LM_ERR below, i.e., they are not in the uri itself. the uri in question is received uri and the call in nathelper.c is this:

if (parse_uri(c.s, c.len, &curi) < 0) { LM_ERR("can't parse contact uri '%.*s'\n", c.len, c.s);

so there clearly is a bug in parse_uri function. it cannot handle escaped chars.

when i have time, i'll add tracker issue about it.

-- juha

José Luis Millán writes:

That is a wrong formed URI but a right formed URI parameter. The right URI format for the above is:

sip:192.98.102.11:35453;transport=tcp

While the right format for the same info when it is used as an URI parameter is:

sip:192.98.102.11:35453%3Btransport%3Dtcp

you are correct. i'll take a look if received param value could be easily unescaped when it is stored in usrloc.

-- juha

Of course I assume that modules dont implement unescaping uris encoded as URI param value. That needs to be coded.

Anyhow, why is the received stuff required at all? IMHO it is time for dropping custom/proprietary hacks and use rfc 5626 Outbound instead. Otherwise we must live with hacks in lot of places of the code and modules.

-- Iñaki Baz Castillo ibc@aliax.net El 10/04/2013 11:31, "Juha Heinanen" jh@tutpro.com escribió:

Juha Heinanen writes:

...

i tested and even when url path field contains escaped chars. however, i started to get these to syslog every 20 seconds

Apr 10 12:17:08 wheezy1 /usr/sbin/sip-proxy[3900]: ERROR: nathelper

[nathelper.c:2018]: can't parse contact uri

...

most likely due to nat pinging. i haven't checked yet where they come from. contact field of the ua does not have any escaped chars in it.

i added the uri to the error message and got:

nathelper [nathelper.c:2019]: can't parse contact uri 'sip:192.98.102.11:35453%3Btransport%3Dtcp'

single quotes are from my LM_ERR below, i.e., they are not in the uri itself. the uri in question is received uri and the call in nathelper.c is this:

                    if (parse_uri(c.s, c.len, &curi) < 0) {
                        LM_ERR("can't parse contact uri '%.*s'\n",
                               c.len, c.s);

so there clearly is a bug in parse_uri function. it cannot handle escaped chars.

when i have time, i'll add tracker issue about it.

-- juha

---

SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

You can use the force_outbound option in the outbound module to make path and rr add flow-tokens even when the client isn't doing outbound.

Regards,

Peter

On 10/04/13 11:44, Juha Heinanen wrote:

Iñaki Baz Castillo writes:

...

Anyhow, why is the received stuff required at all? IMHO it is time for dropping custom/proprietary hacks and use rfc 5626 Outbound instead. Otherwise we must live with hacks in lot of places of the code and modules.

unfortunately it will take years before most sip clients implement outbound.

-- juha

---

SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Single server outbound is on my todo list. I have put the details of what is needed here: http://www.kamailio.org/wiki/devel/completing_outbound

Don't know if or when I'll get time to do it though.

Regards,

Peter

On 10/04/13 11:54, Juha Heinanen wrote:

Peter Dunkley writes:

...

You can use the force_outbound option in the outbound module to make path and rr add flow-tokens even when the client isn't doing outbound.

thank for info. it may not work though, if registrar and edge proxy are combined. in my current test, i have two proxies/registrars each serving serving as edge proxy for the other. when ua registers with p1, p1 can force outbound when it forwards register to p2, but it cannot add those when it processes the register itself.

perhaps there could be an option to take path and rr flow tokens from pseudo vars instead of the headers?

-- juha

---

SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Olle E. Johansson writes:

Can't you add and forward to yourself again? I do crazy stuff like that in many places. Just loop around to force a new transaction with new headers.

Just an idea. Maybe totally stupid.

could be done, but it adds complexity and overhead. there is enough time before 4.1 is out to get this properly solved.

-- juha

2013/4/10 Juha Heinanen jh@tutpro.com:

Olle E. Johansson writes:

...

Can't you add and forward to yourself again? I do crazy stuff like that in many places. Just loop around to force a new transaction with new headers.

Just an idea. Maybe totally stupid.

could be done, but it adds complexity and overhead. there is enough time before 4.1 is out to get this properly solved.

And hopefully received stuff is removed forever.

So now in the above scenario the registrar sends an initial INVITE to Kamailio with a top Route like:

Route: sip:192.98.102.10:5070;transport=tcp;lr;received=sip:192.98.102.11:35449%3Btransport%3Dtcp

and Kamailio must decode the received param, parse the URI and forward the request to it. This is a annoying loose-routing mechanism XDDD

Please, RFC 5626 is the solution for NAT.

-- Iñaki Baz Castillo ibc@aliax.net

There is no need at all for clients to be Outbound aware. The proxy can force it in the same way current "alias" / "contact mangling" / "received stuff" is used.

-- Iñaki Baz Castillo ibc@aliax.net El 10/04/2013 12:44, "Juha Heinanen" jh@tutpro.com escribió:

Iñaki Baz Castillo writes:

...

Anyhow, why is the received stuff required at all? IMHO it is time for dropping custom/proprietary hacks and use rfc 5626 Outbound instead. Otherwise we must live with hacks in lot of places of the code and modules.

unfortunately it will take years before most sip clients implement outbound.

-- juha

---

SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

10 apr 2013 kl. 14:53 skrev Klaus Darilion klaus.mailinglists@pernau.at:

On 10.04.2013 12:58, Iñaki Baz Castillo wrote:

...

There is no need at all for clients to be Outbound aware. The proxy can force it in the same way current "alias" / "contact mangling" / "received stuff" is used.

Who does keep-alive when outbound is used? If it is the client, then there still must be some tweaks in the server as the non-outbound client will not send keep-alive.

Outbound puts all the client connection management burden upon the client.

/O

When using a non-outbound client like Jitsi you can keep-alive by getting it to re-REGISTER, OPTIONS ping, or '\r\n' frequently.

IMHO that is far better solution than having the server run timers and generate keep-alives.

Regards,

Peter

On 10/04/13 13:53, Klaus Darilion wrote:

Who does keep-alive when outbound is used? If it is the client, then there still must be some tweaks in the server as the non-outbound client will not send keep-alive.

regards klaus

Remember that Outbound also works for UDP. In that case:

a) The Outbound Flow Token (the URI username in the Record-Route) must encode the public source IP:port of the request, and the Outbound proxy must be capable of encoding and decoding it for routing the request to the client (OverSIP does it).

b) The client should keepalive via STUN PING requests.

Anyhow, nothing prevents Kamailio to mantain the keepalive by sending OPTIONS or whatever, as currently it does when using other NAT-fix custom mechanisms.

Regards.

2013/4/10 Peter Dunkley peter.dunkley@crocodile-rcs.com:

When using a non-outbound client like Jitsi you can keep-alive by getting it to re-REGISTER, OPTIONS ping, or '\r\n' frequently.

IMHO that is far better solution than having the server run timers and generate keep-alives.

Regards,

Peter

On 10/04/13 13:53, Klaus Darilion wrote:

...

Who does keep-alive when outbound is used? If it is the client, then there still must be some tweaks in the server as the non-outbound client will not send keep-alive.

regards klaus

---

SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Thanks for the bug-fix as the parsing should always work, but I am having difficulty understanding the configuration in use here.

This particular parsing problem only occurs when outbound is enabled in registrar and you have a received parameter to the Path: header. However, when using outbound I would not expect there to be a received parameter on the Path: header as the outbound flow-token does the same job.

Regards,

Peter

i find and fixed the bug that caused parsing of path uri to fail when save() was called.

it still holds true that the path uri generated by add_path_received() is syntactically bogus. if the receiver is not kamailio, parsing of path uri would thus most likely fail.

what should be done about it? does kamailio support escaped chars in uri param values?

-- juha

---

SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users