my conclusion is that ; and = in received value needs to be escaped.

i escaped them, but it didn't help. path header now looks like: Path: <sip:192.98.102.10;transport=tcp;lr;received='sip:192.98.102.10:58156%3Btransport%3Dtcp'>. and i still get the same error: Apr 7 14:49:47 wheezy1 /usr/sbin/sip-proxy[8709]: ERROR: registrar [save.c:887]: Failed to parse Path: URI

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

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.

2013/4/9 Richard Fuchs &lt;rfuchs(a)sipwise.com&gt;om>: 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 &lt;ibc(a)aliax.net&gt; _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

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.

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(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

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

Juha Heinanen writes: [nathelper.c:2018]: can't parse contact uri 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(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

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

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.

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.

Peter Dunkley writes: 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(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

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

Please, RFC 5626 is the solution for NAT.

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.

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

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

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.