10 Apr
2013
10 Apr
'13
1:15 a.m.
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(a)sipwise.com>om>:
On 04/09/13 12:19, Iñaki Baz Castillo wrote:
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(a)aliax.net>
_______________________________________________
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 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.