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

[Jeff Pyle]

John,

Certainly.


- Jeff


On Thu, Feb 18, 2021 at 10:47 AM John Quick 
wrote:

> Jeff,
>
> Would it be okay if I included this as an interesting 'special case' to my
> recently published article?
> The article is all about fixing Contact headers - when and how to do it,
> when not to do it, etc.
>
> https://kb.smartvox.co.uk/opensips/nat-contact-and-via-fixing-in-sip-part-3/
>
> John Quick
> Smartvox Limited
>
>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

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

[John Quick]

Jeff,

Would it be okay if I included this as an interesting 'special case' to my
recently published article?
The article is all about fixing Contact headers - when and how to do it,
when not to do it, etc.
https://kb.smartvox.co.uk/opensips/nat-contact-and-via-fixing-in-sip-part-3/

John Quick
Smartvox Limited



___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

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

[Jeff Pyle]

Now that I'm finished tripping over my own mistakes, and it appears to be
working well, I'll document it in case someone else has the same
application with the same cranky CPE devices.

On the initial request, I save the caller contact before any nathelper
modules change it:

$var(ct_uri) = $(ct.fields(uri){nameaddr.uri});


After the dialog is created (by topology_hiding() in my case), I stuff this
value into the dialog:

$dlg_val(caller_private_contact) = $var(ct_uri);


In my case I have multiple registered contacts per AOR, so I have this in
the branch_route:

$bavp(callee_private_contact) = $ru;


Then, in onreply_route, I stuff the dialog value with the original contact
of the willing branch:

if (t_check_status("200")) {
$dlg_val(callee_private_contact) = $bavp(callee_private_contact);
}


At this point the dialog has the original callee and caller values.

In the section that handles sequential requests (beneath
topology_hiding_match() in my case), I have basically what Răzvan suggested:

$du = $ru;
if ($DLG_dir == "upstream") {
$ru = $dlg_val(caller_private_contact);
} else {
$ru = $dlg_val(caller_private_contact);
}


And voilà, $du preserves the routing destination while $ru contains the
original contact before NAT mangling.  Excellent.


- Jeff


On Fri, Feb 5, 2021 at 2:58 PM Jeff Pyle  wrote:

> 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 
> 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 > > > wrote:
>> >
>> > did you change the loose route part to fix route dialog ?
>> >
>> > Op di 26 jan. 2021 om 16:39 schreef 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") {
>> >

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

[Jeff Pyle]

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  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  > > wrote:
> >
> > did you change the loose route part to fix route dialog ?
> >
> > Op di 26 jan. 2021 om 16:39 schreef 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

Re: [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() 
 
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 > wrote:


did you change the loose route part to fix route dialog ?

Op di 26 jan. 2021 om 16:39 schreef Jeff Pyle mailto:j...@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?  

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

[Jeff Pyle]

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()

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

> did you change the loose route part to fix route dialog ?
>
> Op di 26 jan. 2021 om 16:39 schreef 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
>>
>> ___
>> Users mailing list
>> Users@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

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

> 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@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[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
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users