Re: [OpenSIPS-Users] interaction between fix_nated_contact(), topology_hiding() and serial forking

[Federico Edorna]

Hello! I had a similar problem some time ago, when I moved from 2.2 to 2.4
version.
In my case Opensips is acting as a "register proxy", it validates
IP/port from the outside world using permissions module and it maps to a
username/password to a UAS in the internal network. I use it for UAC's that
cannot register (or cannot have credentials) but have a public fixed IP
address, in this way I simulate a registration from the enduser and
opensips responds to the INVITE challenge using uac_auth/uac modules as a
client.

So, an INVITE arrives to opensips, then opensips relays it to internal
Registrar Server. Registrar server replies a "SIP 407 Proxy
Authentication", opensips catch it in failure_route and generates the auth
response using uac_auth().

This was working fine in version 2.2 using fix_nated_contact()
and topology_hiding(). When I moved to 2.4, the fix_nated_contact() seems
to change contact twice: in the first INVITE relayed to de Registrar Server
(that's ok!), but also when it generates the self generated authenticated
INVITE.


I searched in my old emails and I founded some debug logs in the first
INVITE (contact changed from private to public)

18:15:22.245403-03:00 DBG:dialog:dlg_update_contact: Replacing old
contact  for dialog 0x7f8ab6a8c808 on leg
018:15:22.245409-03:00 DBG:dialog:dlg_update_contact: Updated contact
to  for dialog 0x7f8ab6a8c808 on leg 0


but on the self generated INVITE, contact is changed again (from public to
private)

18:15:22.252208-03:00 /home/gc/local/regproxy/sbin/opensips[335]:
DBG:dialog:dlg_update_contact: Replacing old contact
 for dialog 0x7f8ab6a8c808 on leg
018:15:22.252212-03:00 /home/gc/local/regproxy/sbin/opensips[335]:
DBG:dialog:dlg_update_contact: Updated contact to
 for dialog 0x7f8ab6a8c808 on leg 0


Turning off topology_hiding(), solves the issue and contact is only changed
once. I tried to look into the code following the dlg_update_contact
function, what I'd noticed comparing 2.2 and 2.4 version is that in 2.2
something is saved in th_sent_contact field, so that decided me to turn
topology_hiding off as a workaround.

https://github.com/OpenSIPS/opensips/blob/2.2/modules/dialog/dlg_handlers.c#L1148-L1164
https://github.com/OpenSIPS/opensips/blob/2.4/modules/dialog/dlg_handlers.c#L1177-L1188


Hope it helps, hope I didn't make you waste time :)

Federico


On Thu, Oct 29, 2020 at 10:43 AM Jeff Pyle  wrote:

> Yes, and only when topology_hiding() is called later.  No t_newtran().
>
> How can one see the fixed Contact in the script?  I've tried xlog with
> $ct, but that always shows the original one.  I know it's being lost (or
> not) only by looking at callee_contact from dlg_list.  If I can see the
> updated one I can be more precise about where I'm losing it.
>
>
> - Jeff
>
>
>
>
> On Thu, Oct 29, 2020 at 5:45 AM Răzvan Crainea 
> wrote:
>
>> Hi, Jeff!
>>
>> So you're claiming that the updated contact is lost even if you call
>> fix_nated_contact() before topology_hiding(), but only for the second
>> branch? Are you calling t_newtran() anywhere in your script?
>>
>> Best regards,
>>
>> Răzvan Crainea
>> OpenSIPS Core Developer
>> http://www.opensips-solutions.com
>>
>> On 10/28/20 8:30 PM, Jeff Pyle wrote:
>> > Liviu,
>> >
>> > It looks like the fixed/update contact is lost only when
>> > topology_hiding() is involved.  Would you prefer a separate issue, or
>> > shall I append the issue you referenced before?
>> >
>> >
>> > - Jeff
>> >
>> >
>> > On Wed, Oct 28, 2020 at 2:15 PM Jeff Pyle > > > wrote:
>> >
>> > Hey Liviu,
>> >
>> > fix_nated_contact() before topology_hiding().  Got it.  As far as
>> > losing the fixed contact during a serial fork, I'll do more testing
>> > to localize exactly which combination of circumstances causes this
>> > to surface and open a bug report.
>> >
>> >
>> > - Jeff
>> >
>> >
>> > On Wed, Oct 28, 2020 at 1:28 PM Liviu Chircu > > > wrote:
>> >
>> > Hi!
>> >
>> > On 28.10.2020 18:49, Jeff Pyle wrote:
>> >> First, I lose the updated Contact from fix_nated_contact()
>> >> after a serial fork.  Is this expected?
>> > I would assume the `fix_nated_contact()` lump changes get backed
>> > up into shared memory, then made available during the
>> > failure_route. Anything else and IMHO it looks like a bug.
>> > Opinions welcome.
>> >>
>> >> Second, I've determined that if the Contact URI is not wrapped
>> >> in <>, that's when I get the "second attempt to change URI
>> >> Contact" error when running fix_nated_contact() in the
>> >> branch_route[]. This feels like a bug.
>> >
>> > This one is a known, documented issue.  Long story short: you
>> > should always call fix_nated_contact() _before_
>> > topology_hiding().  See this truth table for more info [1].
>> >
>> > [1]: https://github.com/OpenSIPS/opensips/issues/2172
>> 

Re: [OpenSIPS-Users] interaction between fix_nated_contact(), topology_hiding() and serial forking

[Jeff Pyle]

Yes, and only when topology_hiding() is called later.  No t_newtran().

How can one see the fixed Contact in the script?  I've tried xlog with $ct,
but that always shows the original one.  I know it's being lost (or not)
only by looking at callee_contact from dlg_list.  If I can see the updated
one I can be more precise about where I'm losing it.


- Jeff




On Thu, Oct 29, 2020 at 5:45 AM Răzvan Crainea  wrote:

> Hi, Jeff!
>
> So you're claiming that the updated contact is lost even if you call
> fix_nated_contact() before topology_hiding(), but only for the second
> branch? Are you calling t_newtran() anywhere in your script?
>
> Best regards,
>
> Răzvan Crainea
> OpenSIPS Core Developer
> http://www.opensips-solutions.com
>
> On 10/28/20 8:30 PM, Jeff Pyle wrote:
> > Liviu,
> >
> > It looks like the fixed/update contact is lost only when
> > topology_hiding() is involved.  Would you prefer a separate issue, or
> > shall I append the issue you referenced before?
> >
> >
> > - Jeff
> >
> >
> > On Wed, Oct 28, 2020 at 2:15 PM Jeff Pyle  > > wrote:
> >
> > Hey Liviu,
> >
> > fix_nated_contact() before topology_hiding().  Got it.  As far as
> > losing the fixed contact during a serial fork, I'll do more testing
> > to localize exactly which combination of circumstances causes this
> > to surface and open a bug report.
> >
> >
> > - Jeff
> >
> >
> > On Wed, Oct 28, 2020 at 1:28 PM Liviu Chircu  > > wrote:
> >
> > Hi!
> >
> > On 28.10.2020 18:49, Jeff Pyle wrote:
> >> First, I lose the updated Contact from fix_nated_contact()
> >> after a serial fork.  Is this expected?
> > I would assume the `fix_nated_contact()` lump changes get backed
> > up into shared memory, then made available during the
> > failure_route. Anything else and IMHO it looks like a bug.
> > Opinions welcome.
> >>
> >> Second, I've determined that if the Contact URI is not wrapped
> >> in <>, that's when I get the "second attempt to change URI
> >> Contact" error when running fix_nated_contact() in the
> >> branch_route[]. This feels like a bug.
> >
> > This one is a known, documented issue.  Long story short: you
> > should always call fix_nated_contact() _before_
> > topology_hiding().  See this truth table for more info [1].
> >
> > [1]: https://github.com/OpenSIPS/opensips/issues/2172
> >
> > --
> > Liviu Chircu
> > www.twitter.com/liviuchircu  
> |www.opensips-solutions.com  
> >
> > ___
> > 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
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] interaction between fix_nated_contact(), topology_hiding() and serial forking

[Răzvan Crainea]

Hi, Jeff!

So you're claiming that the updated contact is lost even if you call 
fix_nated_contact() before topology_hiding(), but only for the second 
branch? Are you calling t_newtran() anywhere in your script?


Best regards,

Răzvan Crainea
OpenSIPS Core Developer
http://www.opensips-solutions.com

On 10/28/20 8:30 PM, Jeff Pyle wrote:

Liviu,

It looks like the fixed/update contact is lost only when 
topology_hiding() is involved.  Would you prefer a separate issue, or 
shall I append the issue you referenced before?



- Jeff


On Wed, Oct 28, 2020 at 2:15 PM Jeff Pyle > wrote:


Hey Liviu,

fix_nated_contact() before topology_hiding().  Got it.  As far as
losing the fixed contact during a serial fork, I'll do more testing
to localize exactly which combination of circumstances causes this
to surface and open a bug report.


- Jeff


On Wed, Oct 28, 2020 at 1:28 PM Liviu Chircu mailto:li...@opensips.org>> wrote:

Hi!

On 28.10.2020 18:49, Jeff Pyle wrote:

First, I lose the updated Contact from fix_nated_contact()
after a serial fork.  Is this expected?

I would assume the `fix_nated_contact()` lump changes get backed
up into shared memory, then made available during the
failure_route. Anything else and IMHO it looks like a bug. 
Opinions welcome.


Second, I've determined that if the Contact URI is not wrapped
in <>, that's when I get the "second attempt to change URI
Contact" error when running fix_nated_contact() in the
branch_route[]. This feels like a bug.


This one is a known, documented issue.  Long story short: you
should always call fix_nated_contact() _before_
topology_hiding().  See this truth table for more info [1].

[1]: https://github.com/OpenSIPS/opensips/issues/2172

-- 
Liviu Chircu

www.twitter.com/liviuchircu    
|www.opensips-solutions.com  

___
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] interaction between fix_nated_contact(), topology_hiding() and serial forking

[Jeff Pyle]

Liviu,

It looks like the fixed/update contact is lost only when topology_hiding()
is involved.  Would you prefer a separate issue, or shall I append the
issue you referenced before?


- Jeff


On Wed, Oct 28, 2020 at 2:15 PM Jeff Pyle  wrote:

> Hey Liviu,
>
> fix_nated_contact() before topology_hiding().  Got it.  As far as losing
> the fixed contact during a serial fork, I'll do more testing to localize
> exactly which combination of circumstances causes this to surface and open
> a bug report.
>
>
> - Jeff
>
>
> On Wed, Oct 28, 2020 at 1:28 PM Liviu Chircu  wrote:
>
>> Hi!
>>
>> On 28.10.2020 18:49, Jeff Pyle wrote:
>>
>> First, I lose the updated Contact from fix_nated_contact() after a
>> serial fork.  Is this expected?
>>
>> I would assume the `fix_nated_contact()` lump changes get backed up into
>> shared memory, then made available during the failure_route.  Anything else
>> and IMHO it looks like a bug.  Opinions welcome.
>>
>>
>> Second, I've determined that if the Contact URI is not wrapped in <>,
>> that's when I get the "second attempt to change URI Contact" error when
>> running fix_nated_contact() in the branch_route[].  This feels like a
>> bug.
>>
>> This one is a known, documented issue.  Long story short: you should
>> always call fix_nated_contact() _before_ topology_hiding().  See this truth
>> table for more info [1].
>>
>> [1]: https://github.com/OpenSIPS/opensips/issues/2172
>>
>> --
>> Liviu Chircuwww.twitter.com/liviuchircu | www.opensips-solutions.com
>>
>> ___
>> 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] interaction between fix_nated_contact(), topology_hiding() and serial forking

[Jeff Pyle]

Hey Liviu,

fix_nated_contact() before topology_hiding().  Got it.  As far as losing
the fixed contact during a serial fork, I'll do more testing to localize
exactly which combination of circumstances causes this to surface and open
a bug report.


- Jeff


On Wed, Oct 28, 2020 at 1:28 PM Liviu Chircu  wrote:

> Hi!
>
> On 28.10.2020 18:49, Jeff Pyle wrote:
>
> First, I lose the updated Contact from fix_nated_contact() after a serial
> fork.  Is this expected?
>
> I would assume the `fix_nated_contact()` lump changes get backed up into
> shared memory, then made available during the failure_route.  Anything else
> and IMHO it looks like a bug.  Opinions welcome.
>
>
> Second, I've determined that if the Contact URI is not wrapped in <>,
> that's when I get the "second attempt to change URI Contact" error when
> running fix_nated_contact() in the branch_route[].  This feels like a bug.
>
> This one is a known, documented issue.  Long story short: you should
> always call fix_nated_contact() _before_ topology_hiding().  See this truth
> table for more info [1].
>
> [1]: https://github.com/OpenSIPS/opensips/issues/2172
>
> --
> Liviu Chircuwww.twitter.com/liviuchircu | www.opensips-solutions.com
>
> ___
> 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] interaction between fix_nated_contact(), topology_hiding() and serial forking

[Liviu Chircu]

Hi!

On 28.10.2020 18:49, Jeff Pyle wrote:
First, I lose the updated Contact from fix_nated_contact() after a 
serial fork.  Is this expected?
I would assume the `fix_nated_contact()` lump changes get backed up into 
shared memory, then made available during the failure_route. Anything 
else and IMHO it looks like a bug.  Opinions welcome.


Second, I've determined that if the Contact URI is not wrapped in <>, 
that's when I get the "second attempt to change URI Contact" error 
when running fix_nated_contact() in the branch_route[]. This feels 
like a bug.


This one is a known, documented issue.  Long story short: you should 
always call fix_nated_contact() _before_ topology_hiding().  See this 
truth table for more info [1].


[1]: https://github.com/OpenSIPS/opensips/issues/2172

--
Liviu Chircu
www.twitter.com/liviuchircu | www.opensips-solutions.com

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

Re: [OpenSIPS-Users] interaction between fix_nated_contact(), topology_hiding() and serial forking

[Jeff Pyle]

It looks like I'm fighting two separate issues.  Here's what I know so far.

First, I lose the updated Contact from fix_nated_contact() after a serial
fork.  Is this expected?

Second, I've determined that if the Contact URI is not wrapped in <>,
that's when I get the "second attempt to change URI Contact" error when
running fix_nated_contact() in the branch_route[].  This feels like a bug.


- Jeff




- Jeff


On Tue, Oct 27, 2020 at 8:31 PM Jeff Pyle  wrote:

> Hello,
>
> This is on OpenSIPS 2.4.8.  Early in the script:
>
> if (nat_uac_test("34")) {   # 2, 32
> setflag(NAT_FLAG);
> fix_nated_contact();
> force_rport();
> }
>
> Later in the script I run topology_hiding("CD"), and then t_relay() an
> inbound initial INVITE upstream to another system that returns a 302 with
> Contacts.  I handle that in a failure_route[] by serializing the branches
> and relaying to them one at a time.  I don't have to go around this
> t_relay() -> failure_route[] loop much because the first Contact usually
> handles the request.
>
> The problem I notice is that the updated Contact from fix_nated_contact()
> early in the script is lost after I do the initial t_relay() to the
> redirector to get the 302.  To work around that, I've modified the script
> above to not fix_nated_contact() there, but do it in the branch_route[]
> relaying to the first Contact from the 302 and then only if NAT_FLAG is
> set.  That seems to be fine in most cases.
>
> I one case from one phone system where OpenSIPS complains:
>   ERROR:nathelper:fix_nated_contact_f: SCRIPT BUG - second attempt to
> change URI Contact
>
> This happens when I run fix_nated_contact() in the branch_route[] for the
> first and only time.  I can't duplicate it with my own traffic in the lab
> and it's maddening; it only happens with this one system that's not mine to
> play with.  I've captured the messaging and don't see anything different in
> the INVITEs coming into OpenSIPS, just some cosmetic stuff like one system
> includes :5060 on the From domain and one doesn't.  Nothing that should
> affect OpenSIPS' behavior in any of this.  It'll be very difficult to get a
> full OpenSIPS debug in this case because it's on a production system but
> there's got to be *something*.  Anyway...
>
> So, it appears I have some strange interaction between fix_nated_contact(),
> topology_hiding() and serial forking.  I mention topology_hiding()
> because it's the only thing I can think of in my scenario that would update
> the Contact outside of fix_nated_contact().
>
> I'm stumped.  Any thoughts?
>
>
> - Jeff
>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] interaction between fix_nated_contact(), topology_hiding() and serial forking

[Jeff Pyle]

Hello,

This is on OpenSIPS 2.4.8.  Early in the script:

if (nat_uac_test("34")) {   # 2, 32
setflag(NAT_FLAG);
fix_nated_contact();
force_rport();
}

Later in the script I run topology_hiding("CD"), and then t_relay() an
inbound initial INVITE upstream to another system that returns a 302 with
Contacts.  I handle that in a failure_route[] by serializing the branches
and relaying to them one at a time.  I don't have to go around this
t_relay() -> failure_route[] loop much because the first Contact usually
handles the request.

The problem I notice is that the updated Contact from fix_nated_contact()
early in the script is lost after I do the initial t_relay() to the
redirector to get the 302.  To work around that, I've modified the script
above to not fix_nated_contact() there, but do it in the branch_route[]
relaying to the first Contact from the 302 and then only if NAT_FLAG is
set.  That seems to be fine in most cases.

I one case from one phone system where OpenSIPS complains:
  ERROR:nathelper:fix_nated_contact_f: SCRIPT BUG - second attempt to
change URI Contact

This happens when I run fix_nated_contact() in the branch_route[] for the
first and only time.  I can't duplicate it with my own traffic in the lab
and it's maddening; it only happens with this one system that's not mine to
play with.  I've captured the messaging and don't see anything different in
the INVITEs coming into OpenSIPS, just some cosmetic stuff like one system
includes :5060 on the From domain and one doesn't.  Nothing that should
affect OpenSIPS' behavior in any of this.  It'll be very difficult to get a
full OpenSIPS debug in this case because it's on a production system but
there's got to be *something*.  Anyway...

So, it appears I have some strange interaction between fix_nated_contact(),
topology_hiding() and serial forking.  I mention topology_hiding() because
it's the only thing I can think of in my scenario that would update the
Contact outside of fix_nated_contact().

I'm stumped.  Any thoughts?


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