[OpenSIPS-Users] Dialogs with fix_nated_contact() have wrong RURI domain on sequential requests

[Jeff Pyle]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20210126/85e5b605/attachment.html>