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 <spen...@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 <rfu...@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 >> <i...@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 -- Iñaki Baz Castillo <i...@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
