[OpenSIPS-Users] Dialogs with fix_nated_contact() have wrong RURI domain on sequential requests
Jeff Pyle
jeff at ugnd.org
Fri Feb 5 19:58:00 EST 2021
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 <razvan at opensips.org> 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 <Johan at democon.be
> > <mailto:Johan at democon.be>> wrote:
> >
> > did you change the loose route part to fix route dialog ?
> >
> > Op di 26 jan. 2021 om 16:39 schreef Jeff Pyle <jeff at ugnd.org
> > <mailto:jeff at ugnd.org>>:
> >
> > 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
> > Users at lists.opensips.org <mailto:Users at lists.opensips.org>
> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> > <http://lists.opensips.org/cgi-bin/mailman/listinfo/users>
> >
> > _______________________________________________
> > Users mailing list
> > Users at lists.opensips.org <mailto:Users at lists.opensips.org>
> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> > <http://lists.opensips.org/cgi-bin/mailman/listinfo/users>
> >
> >
> > _______________________________________________
> > Users mailing list
> > Users at lists.opensips.org
> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> >
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20210205/23114917/attachment.html>
More information about the Users
mailing list