<div dir="ltr"><div>Hi Liviu</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 21 Jul 2021 at 16:45, Liviu Chircu <<a href="mailto:liviu@opensips.org">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"><br>
> ERROR:core:unescape_user: invalid hex digit <37><br>
> ERROR:path:path_rr_callback: failed to unescape <br>
> received=sip:35.x.x.x:60026%%3btransport%%3dtls<br>
<br>...Which scenario of the two below would you <br>
say we are in, and with what degree of certainty?<br>
<br>
A.  OpenSIPS generates those erroneous '%%' strings right from the <br>
beginning, when building the Path headers and passing through the <br>
SUBSCRIBE or REGISTER requests.</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
B.  The Path headers are okay when generated by OpenSIPS (containing <br>
just '%3b' and '%3d'), but the issue is on the backend side, which <br>
originates ping messages with doubled '%%' strings in Route headers, <br>
which OpenSIPS is obviously having a hard time parsing/routing?<br><br></blockquote><div><br></div><div>As far as I can see, it's option A:</div><div><br></div><div>At the start of the route{} block in opensips.cfg, I write the SIP message OpenSIPS is receiving with...</div><div><br></div><div>   <b><font face="monospace" color="#38761d" size="4">xlog("$mb"); </font></b> </div><div><br></div><div>...here's what I see (entries reformatted to convert #015#012 to a newline). When the NATed TLS UAC first registers, OpenSIPS receives...</div><div><br></div><div>REGISTER sip:<a href="http://me.our-domain.com">me.our-domain.com</a>;transport=tls SIP/2.0<br>Via: SIP/2.0/TLS 192.x.x.9:49462;rport;branch=z9hG4bKPjb2bbf33dd6ad483bb7a6f169b4e01930;alias<br>Max-Forwards: 70<br>From: "1001" <<a href="mailto:sip%3A1001@me.our-domain.com">sip:1001@me.our-domain.com</a>>;tag=41310a1aa6504e6d8d03fa8f9d74cd52<br>To: "1001" <<a href="mailto:sip%3A1001@me.our-domain.com">sip:1001@me.our-domain.com</a>><br>Call-ID: cadaee22e6484dcab11ffc8f94b17aa2<br>CSeq: 43881 REGISTER<br>User-Agent: MicroSIP/3.20.6<br>Supported: outbound, path<br>Contact: "1001" <sip:1001@192.x.x.x:49462;transport=TLS;ob>;+sip.ice;reg-id=1;+sip.instance="<urn:uuid:00000000-0000-0000-0000-0000ac493192>"<br>Expires: 300<br>Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS<br>Content-Length:  0<br></div><div> </div><div>...we're using mid_registrar with AOR throttling. Because of the lumps system, to get the information to save in the mid_registrar we use... </div><div><br></div><div>    fix_nated_register();</div><div>    fix_nated_contact();</div><div>    add_path_received("$tU");</div><div><br></div><div>...and then t_relay the message back to the OpenSIPS server (192.x.x.123) to continue and store the registration using mid_registrar_save(). When it arrives - this is what OpenSIPS is receiving...</div><div><br></div><div>REGISTER sip:<a href="http://me.our-domain.com">me.our-domain.com</a>;transport=tls SIP/2.0<br>Via: SIP/2.0/TCP 192.x.x.123:5060;branch=z9hG4bK3c27.80ba0c03.0;i=1b075e53<br>Via: SIP/2.0/TLS 192.x.x.9:49462;received=31.x.x.x;rport=49462;branch=z9hG4bKPjb2bbf33dd6ad483bb7a6f169b4e01930;alias<br>Max-Forwards: 70<br>From: "1001" <<a href="mailto:sip%3A1001@me.our-domain.com">sip:1001@me.our-domain.com</a>>;tag=41310a1aa6504e6d8d03fa8f9d74cd52<br>To: "1001" <<a href="mailto:sip%3A1001@me.our-domain.com">sip:1001@me.our-domain.com</a>><br>Call-ID: cadaee22e6484dcab11ffc8f94b17aa2<br>CSeq: 43881 REGISTER<br>User-Agent: MicroSIP/3.20.6<br>Supported: outbound, path<br>Contact: "1001" <sip:1001@31.x.x.x:49462;transport=TLS;ob>;+sip.ice;reg-id=1;+sip.instance="<urn:uuid:00000000-0000-0000-0000-0000ac493192>"<br>Expires: 300<br>Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS<br>Content-Length:  0<br>Path: <sip:1001@192.x.x.123;transport=tcp;r2=on;lr><br>Path: <sip:1001@192.x.x.123:5061;transport=tls;r2=on;lr;received=sip:31.x.x.x:49462%%3btransport%%3dtls><br></div><div><br></div><div>...so it seems to be the add_path_received() that's the source of the problem</div><div><br></div><div><br></div></div></div>