<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">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>