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

[Răzvan Crainea]

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
>