<div dir="ltr"><div>Hi Johan,</div><div><br></div>There typically isn't loose_route() in my script because there is topology_hiding_match() instead. But, I've tested without topology hiding (using loose_route for sequential requests) and there is no difference. <div><br></div><div>The docs for <a href="https://opensips.org/html/docs/modules/3.1.x/dialog.html#func_fix_route_dialog">fix_route_dialog()</a> say that it "forces an in dialog SIP message to contain the ruri, route headers and dst_uri, as specified by the internal data of the dialog it belongs to." That's not a problem here; the in-dialog request already has the same values as the internal data of the dialog it belongs to. This function looks more to prevent bad actors from doing nasty things in in-dialog requests. In my case everyone is playing by the rules.</div><div><br></div><div>The caller_contact and callee_contact from the "internal data of the dialog" (as viewed with the dlg_list MI command) contain the public/received IP and port rather than the internal/private IP and port each UA provided. That occurs because of the fix_nated_contact() function in the script prior to dialog creation. In other words, by the time the dialog is created, the internal IP:port is lost.</div><div><br></div><div>My questions are:</div><div> - how to preserve the private/internal Contact info in the dialog, and</div><div> - use it for signaling in the RURI but continue to use the received/public info for routing for in-dialog requests</div><div><br></div><div><br></div><div>- Jeff</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jan 26, 2021 at 11:04 AM Johan De Clercq <<a href="mailto:Johan@democon.be">Johan@democon.be</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"><div dir="ltr">did you change the loose route part to fix route dialog ? <br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Op di 26 jan. 2021 om 16:39 schreef Jeff Pyle <<a href="mailto:jeff@ugnd.org" target="_blank">jeff@ugnd.org</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hello,<div><br></div><div>This is on OpenSIPS nightly 3.1.1~20210125~8bab0da7b-1.</div><div><br></div><div>I have a registrar configured with basic call routing between the registered AORs. I use topology_hiding("D") to create the dialog on calls and normal stuff like has_totag() and topology_hiding_match() for sequential request handling. All this seems fine.</div><div><br></div><div>This appears high in the main route and appears to do exactly what it should:</div><div><br></div><div><font face="monospace"> if (has_body("application/sdp")) {<br> if (nat_uac_test(14)) {<br> setflag("NAT_FLAG");<br> }<br> } else {<br> if (nat_uac_test(6)) {<br> setflag("NAT_FLAG");<br> }<br> } <br> <br> if (isflagset("NAT_FLAG")) {<br> force_rport();<br> if ($rm == "REGISTER") {<br> fix_nated_register();<br> } else {<br> fix_nated_contact();<br> }<br> }</font><br></div><div><br></div><div>And, for replies:<br><br><font face="monospace">onreply_route [handle_rtprelay_onreply] {</font></div><div><font face="monospace"> # rtpengine and such, omitted for brevity<br> if (isbflagset("NAT_BFLAG")) {<br> fix_nated_contact();<br> }<br><br> exit;<br>}</font><br></div><div><br></div><div>When one client calls another, everything works fine. lookup("location") works to update $rd with the original (private) Contact provided upon registration, and $du contains the actual received source IP:port to get to the device. Excellent. The INVITE goes out accordingly, and all is well.</div><div><br></div><div>My problem occurs with sequential requests, say, re-INVITEs from on-hold events. The dialogs themselves save the received IP:port values as the caller_contact and callee_contact values (from fix_nated_contact() above), so when the requests pass through the sequential handling section of the script and topology_hiding_match() does its fixups, the request URI domain of the relayed request has the received IP:port values of the target UA rather than the private IP:port values the UA provided during the initial request that established the dialog.</div><div><br></div><div>I can't wrap my head around how to fix this. The initial requests work because lookup() has the intelligence to distinguish the UAC's Contact from the received IP:port at REGISTER-time, but I can't see how to achieve this at dialog-creation time so sequential requests have the right RURI domain. Force the caller_contact and callee_contact to the private values somehow, and manage the route_set to point to the appropriate received IP:port? I'm not sure how to configure that if it is the solution.</div><div><br></div><div>Any direction would be appreciated!</div><div><br></div><div><br></div><div>Regards,</div><div>Jeff</div><div><br></div></div>
_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a><br>
<a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
</blockquote></div>
_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a><br>
<a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
</blockquote></div>