<div dir="ltr"><div dir="auto">Hi Liviu - thanks for getting back to me.<div dir="auto"><br></div><div dir="auto">I'm seeing errors for pinger OPTIONS and Asterisk NOTIFY SIP messages going out to the NATed TLS UAC...</div><div dir="auto"><br></div><div dir="auto">ERROR:core:unescape_user: invalid hex digit <37></div><div dir="auto">ERROR:path:path_rr_callback: failed to unescape received=sip:35.x.x.x:60026%%3btransport%%3dtls</div><div dir="auto">ERROR:core:tcp_connect_blocking_timeout: connect timed out, 99204 us elapsed out of 100000 us<br>ERROR:proto_tls:tls_sync_connect: tcp_blocking_connect failed<br>ERROR:proto_tls:proto_tls_send: connect failed<br>ERROR:tm:msg_send: send() to <a href="http://35.210.77.199:50052">35.210.77.199:50052</a> for proto tls/3 failed<br>ERROR:tm:t_forward_nonack: sending request failed<br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 21 Jul 2021, 10:56 Liviu Chircu, <<a href="mailto:liviu@opensips.org" rel="noreferrer" target="_blank">liviu@opensips.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 20.07.2021 13:26, Mark Allen wrote:<br>
> On registration add_path_received() works but the received address is <br>
> not formatted correctly. I am seeing '%%3b' instead of a semicolon, <br>
> and '%%3d' instead of an equals sign.<br>
><br>
Hi Mark,<br>
<br>
How exactly is this peculiar formatting breaking your logic?  Because <br>
the '%'-escaping logic is by design, with a similar un-escaping logic <br>
being included in the code that parses those Path headers, so the UDP <br>
<-> TLS translation using Path headers should work just fine.<br>
<br>
See this commit for full details on how the escaping logic solves <br>
multiple problems with the original approach: [1].<br>
<br>
PS: with 3 years having passed since I wrote that commit, nowadays I <br>
would look at a different way of solving the same problem, as I vaguely <br>
recall that URI param values can be enclosed in double-quotes ("), <br>
allowing us to put anything in there, without affecting the semantics of <br>
the original URI.  Just an idea that we could research/confirm/infirm <br>
should we find any non-fixable issues with the current escaping approach.<br>
<br>
[1]: <a href="https://github.com/OpenSIPS/opensips/commit/b3bf15646affe981d4b26" rel="noreferrer noreferrer noreferrer" target="_blank">https://github.com/OpenSIPS/opensips/commit/b3bf15646affe981d4b26</a><br>
<br>
Best Regards,<br>
<br>
-- <br>
Liviu Chircu<br>
<a href="http://www.twitter.com/liviuchircu" rel="noreferrer noreferrer noreferrer" target="_blank">www.twitter.com/liviuchircu</a> | <a href="http://www.opensips-solutions.com" rel="noreferrer noreferrer noreferrer" target="_blank">www.opensips-solutions.com</a><br>
OpenSIPS Summit 2021 Distributed | <a href="http://www.opensips.org/events" rel="noreferrer noreferrer noreferrer" target="_blank">www.opensips.org/events</a><br>
<br>
</blockquote></div>