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