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

2020-10-29 Thread 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

2020-10-29 Thread 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] Opensips-cp 8.3.0 HTTP/1.1 400 Bad Request..

2020-10-29 Thread Răzvan Crainea 
As I see in your logs, OpenSIPS CP uses the `json` URL path for querying 
MI, whereas the default root path is `mi`[1]. Either change the `root` 
to `json`, or modify your OpenSIPS CP boxes config to `mi`.


[1] https://opensips.org/docs/modules/3.1.x/mi_http.html#param_root

Best regards,

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

On 10/28/20 11:23 PM, Mario San Vicente wrote:

   Thanks for the answer Johan,

But i see that; the *mi_json* module has been renamed to 
*mi_http* module.  and so: failed to load module mi_json.so

https://www.opensips.org/Documentation/Migration-2-4-0-to-3-0-0

I am using opensips 3.1
I have this modules:

loadmodule "httpd.so"
modparam("httpd", "port", )
 MI_HTTP module
loadmodule "json.so"
#loadmodule "mi_json.so"
loadmodule "mi_http.so"

Any other clue?

Thank you


___
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

2020-10-29 Thread 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