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.
- Jeff On Thu, Feb 4, 2021 at 10:04 AM Răzvan Crainea <[email protected]> wrote: > Hi, Jeff! > > The only way to achieve this is to do it manually: store the contact on > the request/replies in a dialog variable, and *after* > topology_hiding_match(), set each of them: > > $du = $ru; > if ($DLG_dir == "downstream") { > $ru = $dlg_val(caller_private_contact); > } else { > $ru = $dlg_val(callee_private_contact); > } > > Hope this helps, > > Răzvan Crainea > OpenSIPS Core Developer > http://www.opensips-solutions.com > > On 1/26/21 6:36 PM, Jeff Pyle wrote: > > Hi Johan, > > > > 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. > > > > The docs for fix_route_dialog() > > < > https://opensips.org/html/docs/modules/3.1.x/dialog.html#func_fix_route_dialog> > > > 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. > > > > 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. > > > > My questions are: > > - how to preserve the private/internal Contact info in the dialog, and > > - use it for signaling in the RURI but continue to use the > > received/public info for routing for in-dialog requests > > > > > > - Jeff > > > > On Tue, Jan 26, 2021 at 11:04 AM Johan De Clercq <[email protected] > > <mailto:[email protected]>> wrote: > > > > did you change the loose route part to fix route dialog ? > > > > Op di 26 jan. 2021 om 16:39 schreef Jeff Pyle <[email protected] > > <mailto:[email protected]>>: > > > > Hello, > > > > This is on OpenSIPS nightly 3.1.1~20210125~8bab0da7b-1. > > > > 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. > > > > This appears high in the main route and appears to do exactly > > what it should: > > > > if (has_body("application/sdp")) { > > if (nat_uac_test(14)) { > > setflag("NAT_FLAG"); > > } > > } else { > > if (nat_uac_test(6)) { > > setflag("NAT_FLAG"); > > } > > } > > > > if (isflagset("NAT_FLAG")) { > > force_rport(); > > if ($rm == "REGISTER") { > > fix_nated_register(); > > } else { > > fix_nated_contact(); > > } > > } > > > > And, for replies: > > > > onreply_route [handle_rtprelay_onreply] { > > # rtpengine and such, omitted for brevity > > if (isbflagset("NAT_BFLAG")) { > > fix_nated_contact(); > > } > > > > exit; > > } > > > > 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. > > > > 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. > > > > 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. > > > > Any direction would be appreciated! > > > > > > Regards, > > Jeff > > > > _______________________________________________ > > Users mailing list > > [email protected] <mailto:[email protected]> > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > <http://lists.opensips.org/cgi-bin/mailman/listinfo/users> > > > > _______________________________________________ > > Users mailing list > > [email protected] <mailto:[email protected]> > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > <http://lists.opensips.org/cgi-bin/mailman/listinfo/users> > > > > > > _______________________________________________ > > Users mailing list > > [email protected] > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > _______________________________________________ > Users mailing list > [email protected] > http://lists.opensips.org/cgi-bin/mailman/listinfo/users >
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
