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

[Johan De Clercq]

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

> 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
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20210126/c0d204ed/attachment-0001.html>