Re: [OpenSIPS-Users] OpenSIPS : no 407 retransmission

2022-05-03 Thread Yannick LE COENT

Hello Daniel,

This is not what I looking for.
My OpenSIPS instance is working as a relay between the softphone and 
another proxy (proxy#2 in the call).

So it does not handle authentication.

Alice   OpenSIPS  Proxy#2
   | INVITE |    |
|--->| INVITE |
   |  100 Tring |--->|
|<---|    407 |
|    |<---|
|    | ACK    |
|    |--->|
|    407 |    |
   | X<-|    |
   |  (no retrans.) |    |

When the 407 is lost between OpenSIPS and Alice, it is not retransmitted 
by OpenSIPS.


I would like to force retransmission.

Thanks,
Yannick

Le 03/05/2022 à 15:16, Daniel Zanutti a écrit :

Generate in Stateful -> www_challenge or proxy_challenge?
https://opensips.org/html/docs/modules/3.2.x/auth.html

Is this what you are looking for?


On Tue, May 3, 2022 at 3:50 AM Yannick LE COENT 
 wrote:


Hello all,

Could you tell if there is a way to enable 407 in stateful mode ?

Thanks,
Yannick

Le 30/04/2022 à 18:14, Yannick LE COENT a écrit :

Hello Ben,

Thanks for your answer.

This problem occurs when OpenSIPS is not in charge of
authenticating the INVITE request, but this is done downstream.
I've sent this question to know if somebody has already solved
this kind of problem.

Best regards,
Yannick

Le 30/04/2022 à 16:15, Ben Newlin a écrit :


I see. Apologies, I misunderstood the problem scenario.

Ben Newlin

*From: *Users 
 on behalf of Yannick
LE COENT 

*Date: *Saturday, April 30, 2022 at 5:46 AM
*To: *OpenSIPS users mailling list 

*Subject: *Re: [OpenSIPS-Users] OpenSIPS : no 407 retransmission

*EXTERNAL EMAIL - Please use caution with links and attachments *



Hello Ben,

The 407 is sent upstream, but when it is lost, it is not
retransmitted by OpenSIPS.
I do not have this problem with other negative status codes
(e.g. 486).

This is clearly explained in
https://opensips.org/pub/opensips/1.8.6/src/ChangeLog

2012-03-21 18:36:58 Bogdan-Andrei Iancu, 
 * [8811] :

 TM will no longer do retransmission for the 407/401 replies
(if no ACK is received) for both local or proxied replies.

According to RFC 3261, retransmitting 407s/401s is probably
a bad idea:

 26.3.2.4 DoS Protection

At the moment, my only solution is to use forward() instead of
t_relay() in order to use the stateless mode.

Yannick


Yannick,

  


The default behavior of OpenSIPS is to relay any received responses 
back upstream. If it is not doing that it would have to be because you are 
stopping it in the script. Take a look at the documentation for failure_route 
[1] which explains this. Check your own failure_route in your script; you must 
be doing something there that is telling OpenSIPS not to relay the 401/407 back 
upstream.

  


[1]https://www.opensips.org/Documentation/Script-Routes-2-4#toc3

  


Ben Newlin

  


From: Users  
  on behalf of Yannick LE 
COENT  

Date: Friday, April 29, 2022 at 6:44 PM

To:users@lists.opensips.org


Subject: [OpenSIPS-Users] OpenSIPS : no 407 retransmission

EXTERNAL EMAIL - Please use caution with links and attachments

  


Hello,

  


I'm using OpenSIPS as a proxy in front of another proxy. The 2nd proxy

is in charge of authenticating the request.

  


This is the callflow:

  


Alice   OpenSIPS  Proxy#2

    | INVITE |    |

    |--->| INVITE |

    |  100 Tring |--->|

    |<---|    407 |

    |    |<---|

    |    | ACK    |

    |    |--->|

    |    407 |    |

    | X<-|    |

    |    |    |

  


Since OpenSIPS does not retransmit 401/407, the call setup gets stuck.

  


What can I do ?

If I set auto_100trying=1, that works, but this increases the number of

INVITE retransmissions since 180Ringing are not received instantly.

  


Do you have any suggestion ?

  


Thanks,

Yannick



Re: [OpenSIPS-Users] OpenSIPS : no 407 retransmission

2022-05-03 Thread Daniel Zanutti
Generate in Stateful -> www_challenge or proxy_challenge?
https://opensips.org/html/docs/modules/3.2.x/auth.html

Is this what you are looking for?


On Tue, May 3, 2022 at 3:50 AM Yannick LE COENT 
wrote:

> Hello all,
>
> Could you tell if there is a way to enable 407 in stateful mode ?
>
> Thanks,
> Yannick
>
> Le 30/04/2022 à 18:14, Yannick LE COENT a écrit :
>
> Hello Ben,
>
> Thanks for your answer.
>
> This problem occurs when OpenSIPS is not in charge of authenticating the
> INVITE request, but this is done downstream.
> I've sent this question to know if somebody has already solved this kind
> of problem.
>
> Best regards,
> Yannick
>
> Le 30/04/2022 à 16:15, Ben Newlin a écrit :
>
> I see. Apologies, I misunderstood the problem scenario.
>
>
>
> Ben Newlin
>
>
>
> *From: *Users 
>  on behalf of Yannick LE COENT
>  
> *Date: *Saturday, April 30, 2022 at 5:46 AM
> *To: *OpenSIPS users mailling list 
> 
> *Subject: *Re: [OpenSIPS-Users] OpenSIPS : no 407 retransmission
>
> *EXTERNAL EMAIL - Please use caution with links and attachments *
>
>
> --
>
> Hello Ben,
>
> The 407 is sent upstream, but when it is lost, it is not retransmitted by
> OpenSIPS.
> I do not have this problem with other negative status codes (e.g. 486).
>
> This is clearly explained in
> https://opensips.org/pub/opensips/1.8.6/src/ChangeLog
>
> 2012-03-21 18:36:58  Bogdan-Andrei Iancu, 
> * [8811] :
>
> TM will no longer do retransmission for the 407/401 replies (if no ACK
> is received) for both local or proxied replies.
>
> According to RFC 3261, retransmitting 407s/401s is probably a bad idea:
>
> 26.3.2.4 DoS Protection
>
> At the moment, my only solution is to use forward() instead of t_relay()
> in order to use the stateless mode.
>
> Yannick
>
>
> Yannick,
>
>
>
> The default behavior of OpenSIPS is to relay any received responses back 
> upstream. If it is not doing that it would have to be because you are 
> stopping it in the script. Take a look at the documentation for failure_route 
> [1] which explains this. Check your own failure_route in your script; you 
> must be doing something there that is telling OpenSIPS not to relay the 
> 401/407 back upstream.
>
>
>
> [1] https://www.opensips.org/Documentation/Script-Routes-2-4#toc3
>
>
>
> Ben Newlin
>
>
>
> From: Users  
>  on behalf of Yannick LE COENT 
>  
>
> Date: Friday, April 29, 2022 at 6:44 PM
>
> To: users@lists.opensips.org  
> 
>
> Subject: [OpenSIPS-Users] OpenSIPS : no 407 retransmission
>
> EXTERNAL EMAIL - Please use caution with links and attachments
>
>
>
> Hello,
>
>
>
> I'm using OpenSIPS as a proxy in front of another proxy. The 2nd proxy
>
> is in charge of authenticating the request.
>
>
>
> This is the callflow:
>
>
>
> Alice   OpenSIPS  Proxy#2
>
>| INVITE ||
>
>|--->| INVITE |
>
>|  100 Tring |--->|
>
>|<---|407 |
>
>||<---|
>
>|| ACK|
>
>||--->|
>
>|407 ||
>
>| X<-||
>
>|||
>
>
>
> Since OpenSIPS does not retransmit 401/407, the call setup gets stuck.
>
>
>
> What can I do ?
>
> If I set auto_100trying=1, that works, but this increases the number of
>
> INVITE retransmissions since 180Ringing are not received instantly.
>
>
>
> Do you have any suggestion ?
>
>
>
> Thanks,
>
> Yannick
>
>
> ___
> Users mailing 
> listUsers@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
> ___
> Users mailing 
> listUsers@lists.opensips.orghttp://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 Bootcamp training 2022

2022-05-03 Thread Bogdan-Andrei Iancu


Tick, tack, only 3 weeks left to the training, first come, first served, 
seats are limited.


https://opensips.org/training/OpenSIPS_eBootcamp_2022/

Best regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
  https://www.opensips-solutions.com
OpenSIPS eBootcamp 23rd May - 3rd June 2022
  https://opensips.org/training/OpenSIPS_eBootcamp_2022/

On 3/30/22 10:52 AM, Bogdan-Andrei Iancu wrote:




23rd May - 03rd June 2022,


online, worldwide



*Study smarter, not harder!
*

Take advantage of the *OpenSIPS Bootcamp* 
 and improve 
your OpenSIPS skills - an in-cloud training, a ten days, 4 hours per 
day (40 hours) intensive and practical training, covering 
installation, configuration and administration on OpenSIPS.


All the knowledge transferred to the students will be strongly backed 
up by practice sessions where you will get hands-on experience in 
handling OpenSIPS. The training is structured to be offer 50% / 50% 
between the theoretical and practical sessions.


Check Syllabus 



*Early Birds open*

The Early Bird 10% discount is available for registrations before 
/*11th of April 2022*/, so do not miss the opportunity. The number of 
seats is limited, so be sure and book a seat now. Keep in mind that a 
10% group discount is also available - grab your work mate and start 
learning more OpenSIPS together .

.

Register Now 



*Certified training saves time and money*

OpenSIPS mistakes are easily avoided if you get proper training! 
Companies that use OpenSIPS waste time and money when they don't have 
a trained engineer on staff. Searching on Google, waiting on IRC, even 
the latency in mailing list replies takes it's toll over time. Take 
this rare opportunity to train your employees with the project members 
themselves.



Any questions? do not hesitate to contact us 
!



You received this email as part of your relationship with the OpenSIPS 
Project.
If you do not want to receive any more news, please email to 
unsubscribe .



--
   Bogdan-Andrei Iancu
   OpenSIPS Founder and Developer
   http://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] Problem with fix_nated_contact

2022-05-03 Thread Bogdan-Andrei Iancu


Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
  https://www.opensips-solutions.com
OpenSIPS eBootcamp 23rd May - 3rd June 2022
  https://opensips.org/training/OpenSIPS_eBootcamp_2022/

On 5/3/22 12:04 PM, Yury Kirsanov wrote:

Hi Bogdan,
Thanks for clarification, I'll try to monitor this and analyze it further!

In regards to 'it simply replace the host:port part of the contact 
with the src IP and port from network level' for example if request is 
coming from 172.16.22.4:5060  and Contact is 
set to 'sip:172.167.22.4:5060 ', would 
fix_nated_contact() just replace Contact with the same values?

Yes, correct.

As it doesn't have any 'received' parameter to replace this Contact 
with? Thanks!
$avp(received) it is an output of the fix_nated_register() function, not 
an input.


On Tue, May 3, 2022 at 6:55 PM Bogdan-Andrei Iancu 
mailto:bog...@opensips.org>> wrote:


See inline

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   https://www.opensips-solutions.com  
OpenSIPS eBootcamp 23rd May - 3rd June 2022
   https://opensips.org/training/OpenSIPS_eBootcamp_2022/  


On 5/3/22 11:40 AM, Yury Kirsanov wrote:

Hi Bogdan,
Will fix_nated_register() overwrite results of a fix_nated_contact()?

no, use either one, either the other, but not both in the same
time - see the docs for the nathelper module for details.


Second question - for 'OPTIONS' where Contact is available -
should fix_nated_contact() replace it with the correct one?

yes, if you relay the OPTIONS

Where exactly does this function take the value to replace
Contact with - from '$avp(received)' param?

no, it is taken from the network level, the src IP and port.

So it won't do anything if, for example, OPTIONS packet comes
from my LAN Asterisk server and reaches the OpenSIPS LAN interface?

the fix_nated_xxxX() does not do any testing, it simply replace
the host:port part of the contact with the src IP and port from
network level.

Even though nat_uac_test(7) would confirm a RFC1918 private
address fix_nated_contact() can't do much in this case, is that
correct?

Thanks a lot for your help!

Best regards,
Yury.

On Tue, May 3, 2022 at 6:25 PM Bogdan-Andrei Iancu
mailto:bog...@opensips.org>> wrote:

Hi Yury,

For a REGISTER you should use the fix_nated_register() function.

Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   https://www.opensips-solutions.com  

OpenSIPS eBootcamp 23rd May - 3rd June 2022
   https://opensips.org/training/OpenSIPS_eBootcamp_2022/  


On 5/2/22 8:07 PM, Yury Kirsanov wrote:

Hi Bogdan,
No, nothing in OpenSIPS logs, unfortunately.

Here's another log, I'm doing 'fix_nated_register' in this
case at the REGISTER route and doing 'fix_nated_contact()'
at the very beginning of my script, just for the testing
purpose.

May  3 03:00:48 [REGISTER]  [123456->123456] Forwarding
REGISTER from sip:123...@domain.com:5060
, requested Expries: 60
to main registrar at sip:172.16.4.22:5060
 (84327f479c5d50e1634422f72a0b7619)
May  3 03:00:48 [REPLY] [123456->123456] REGISTER 401
Unauthorized FROM 172.16.4.22:5060 
(84327f479c5d50e1634422f72a0b7619)
May  3 03:00:48 [REGISTER]  [123456->123456] Request from
1XX.1XX.1XX.1XX:8001, domain domain.com 
(84327f479c5d50e1634422f72a0b7619)
May  3 03:00:48 [REGISTER]  [123456->123456] Forwarding
REGISTER from sip:123...@domain.com:5060
, requested Expries: 60
to main registrar at sip:172.16.4.22:5060
 (84327f479c5d50e1634422f72a0b7619)
May  3 03:00:48 [REPLY] [123456->123456] REGISTER 200 OK
FROM 172.16.4.22:5060 
(84327f479c5d50e1634422f72a0b7619)
May  3 03:00:48 [REGREPLY]  [123456->123456] Reply from
172.16.4.22:5060 , code is 200 -
OK, saving contact (84327f479c5d50e1634422f72a0b7619)
May  3 03:00:48 [EVENT] Inserting contact
sip:123456@192.168.1.36:8001

(569f6c324981335e0b33daf8fc88ed77)
May  3 03:00:51 [OPTIONS]       OPTIONS request from
172.16.4.22:5060  to
sip:123456@172.16.4.254:5060
, fu is
sip:123456@1XX.1XX.1XX.1XX
May  3 03:00:51 

Re: [OpenSIPS-Users] Problem with fix_nated_contact

2022-05-03 Thread Yury Kirsanov
Hi Bogdan,
Thanks for clarification, I'll try to monitor this and analyze it further!

In regards to 'it simply replace the host:port part of the contact with the
src IP and port from network level' for example if request is coming from
172.16.22.4:5060 and Contact is set to 'sip:172.167.22.4:5060', would
fix_nated_contact() just replace Contact with the same values? As it
doesn't have any 'received' parameter to replace this Contact with? Thanks!

On Tue, May 3, 2022 at 6:55 PM Bogdan-Andrei Iancu 
wrote:

> See inline
>
> Bogdan-Andrei Iancu
>
> OpenSIPS Founder and Developer
>   https://www.opensips-solutions.com
> OpenSIPS eBootcamp 23rd May - 3rd June 2022
>   https://opensips.org/training/OpenSIPS_eBootcamp_2022/
>
> On 5/3/22 11:40 AM, Yury Kirsanov wrote:
>
> Hi Bogdan,
> Will fix_nated_register() overwrite results of a fix_nated_contact()?
>
> no, use either one, either the other, but not both in the same time - see
> the docs for the nathelper module for details.
>
>
> Second question - for 'OPTIONS' where Contact is available - should
> fix_nated_contact() replace it with the correct one?
>
> yes, if you relay the OPTIONS
>
> Where exactly does this function take the value to replace Contact with -
> from '$avp(received)' param?
>
> no, it is taken from the network level, the src IP and port.
>
> So it won't do anything if, for example, OPTIONS packet comes from my LAN
> Asterisk server and reaches the OpenSIPS LAN interface?
>
> the fix_nated_xxxX() does not do any testing, it simply replace the
> host:port part of the contact with the src IP and port from network level.
>
> Even though nat_uac_test(7) would confirm a RFC1918 private
> address fix_nated_contact() can't do much in this case, is that correct?
>
> Thanks a lot for your help!
>
> Best regards,
> Yury.
>
> On Tue, May 3, 2022 at 6:25 PM Bogdan-Andrei Iancu 
> wrote:
>
>> Hi Yury,
>>
>> For a REGISTER you should use the fix_nated_register() function.
>>
>> Regards,
>>
>> Bogdan-Andrei Iancu
>>
>> OpenSIPS Founder and Developer
>>   https://www.opensips-solutions.com
>> OpenSIPS eBootcamp 23rd May - 3rd June 2022
>>   https://opensips.org/training/OpenSIPS_eBootcamp_2022/
>>
>> On 5/2/22 8:07 PM, Yury Kirsanov wrote:
>>
>> Hi Bogdan,
>> No, nothing in OpenSIPS logs, unfortunately.
>>
>> Here's another log, I'm doing 'fix_nated_register' in this case at the
>> REGISTER route and doing 'fix_nated_contact()' at the very beginning of my
>> script, just for the testing purpose.
>>
>> May  3 03:00:48 [REGISTER]  [123456->123456] Forwarding REGISTER from
>> sip:123...@domain.com:5060, requested Expries: 60 to main registrar at
>> sip:172.16.4.22:5060 (84327f479c5d50e1634422f72a0b7619)
>> May  3 03:00:48 [REPLY] [123456->123456] REGISTER 401
>> Unauthorized FROM 172.16.4.22:5060 (84327f479c5d50e1634422f72a0b7619)
>> May  3 03:00:48 [REGISTER]  [123456->123456] Request from
>> 1XX.1XX.1XX.1XX:8001, domain domain.com
>> (84327f479c5d50e1634422f72a0b7619)
>> May  3 03:00:48 [REGISTER]  [123456->123456] Forwarding REGISTER from
>> sip:123...@domain.com:5060, requested Expries: 60 to main registrar at
>> sip:172.16.4.22:5060 (84327f479c5d50e1634422f72a0b7619)
>> May  3 03:00:48 [REPLY] [123456->123456] REGISTER 200 OK FROM
>> 172.16.4.22:5060 (84327f479c5d50e1634422f72a0b7619)
>> May  3 03:00:48 [REGREPLY]  [123456->123456] Reply from
>> 172.16.4.22:5060, code is 200 - OK, saving contact
>> (84327f479c5d50e1634422f72a0b7619)
>> May  3 03:00:48 [EVENT] Inserting contact sip:123456@192.168.1.36:8001
>> (569f6c324981335e0b33daf8fc88ed77)
>> May  3 03:00:51 [OPTIONS]   OPTIONS request from 172.16.4.22:5060 to
>> sip:123456@172.16.4.254:5060, fu is sip:123456@1XX.1XX.1XX.1XX
>> May  3 03:00:51 [OPTIONS]   [123456->123456] SIP device
>> sip:123456@172.16.4.254 found, relaying to sip:1XX.1XX.1XX.1XX:8001
>> (76f4319976c85e45b2ff916581912550)
>>
>> No errors in OpenSIPS logs. Here's output of 'opensips-cli -x mi fifo
>> ul_dump':
>>
>> "AORs": [
>> {
>> "AOR": "123456",
>> "Contacts": [
>> {
>> "Contact": "sip:123456@192.168.1.36:8001",
>> "ContactID": "3713509073413807284",
>> "Expires": 47,
>> "Q": "",
>> "Callid": "6_3941098626",
>> "Cseq": 2,
>> "User-agent": "Yealink SIP-T46G 28.83.0.120",
>> "Received": "sip:1XX.1XX.1XX.1XX:8001",
>> "State": "CS_SYNC",
>> "Flags": 0,
>> "Cflags": "",
>> "Socket": "udp:1XX.1XX.1XX.1XX:5060",
>> "Methods": 16383
>> }
>> ]
>> }
>>
>> Thanks and best regards,
>> Yury.
>>

Re: [OpenSIPS-Users] Problem with fix_nated_contact

2022-05-03 Thread Bogdan-Andrei Iancu

See inline

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
  https://www.opensips-solutions.com
OpenSIPS eBootcamp 23rd May - 3rd June 2022
  https://opensips.org/training/OpenSIPS_eBootcamp_2022/

On 5/3/22 11:40 AM, Yury Kirsanov wrote:

Hi Bogdan,
Will fix_nated_register() overwrite results of a fix_nated_contact()?
no, use either one, either the other, but not both in the same time - 
see the docs for the nathelper module for details.


Second question - for 'OPTIONS' where Contact is available - should 
fix_nated_contact() replace it with the correct one?

yes, if you relay the OPTIONS
Where exactly does this function take the value to replace Contact 
with - from '$avp(received)' param?

no, it is taken from the network level, the src IP and port.
So it won't do anything if, for example, OPTIONS packet comes from my 
LAN Asterisk server and reaches the OpenSIPS LAN interface?
the fix_nated_xxxX() does not do any testing, it simply replace the 
host:port part of the contact with the src IP and port from network level.
Even though nat_uac_test(7) would confirm a RFC1918 private 
address fix_nated_contact() can't do much in this case, is that correct?


Thanks a lot for your help!

Best regards,
Yury.

On Tue, May 3, 2022 at 6:25 PM Bogdan-Andrei Iancu 
mailto:bog...@opensips.org>> wrote:


Hi Yury,

For a REGISTER you should use the fix_nated_register() function.

Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   https://www.opensips-solutions.com  
OpenSIPS eBootcamp 23rd May - 3rd June 2022
   https://opensips.org/training/OpenSIPS_eBootcamp_2022/  


On 5/2/22 8:07 PM, Yury Kirsanov wrote:

Hi Bogdan,
No, nothing in OpenSIPS logs, unfortunately.

Here's another log, I'm doing 'fix_nated_register' in this case
at the REGISTER route and doing 'fix_nated_contact()' at the very
beginning of my script, just for the testing purpose.

May  3 03:00:48 [REGISTER]      [123456->123456] Forwarding
REGISTER from sip:123...@domain.com:5060
, requested Expries: 60 to
main registrar at sip:172.16.4.22:5060 
(84327f479c5d50e1634422f72a0b7619)
May  3 03:00:48 [REPLY]         [123456->123456] REGISTER 401
Unauthorized FROM 172.16.4.22:5060 
(84327f479c5d50e1634422f72a0b7619)
May  3 03:00:48 [REGISTER]      [123456->123456] Request from
1XX.1XX.1XX.1XX:8001, domain domain.com 
(84327f479c5d50e1634422f72a0b7619)
May  3 03:00:48 [REGISTER]      [123456->123456] Forwarding
REGISTER from sip:123...@domain.com:5060
, requested Expries: 60 to
main registrar at sip:172.16.4.22:5060 
(84327f479c5d50e1634422f72a0b7619)
May  3 03:00:48 [REPLY]         [123456->123456] REGISTER 200 OK
FROM 172.16.4.22:5060 
(84327f479c5d50e1634422f72a0b7619)
May  3 03:00:48 [REGREPLY]      [123456->123456] Reply from
172.16.4.22:5060 , code is 200 - OK,
saving contact (84327f479c5d50e1634422f72a0b7619)
May  3 03:00:48 [EVENT] Inserting contact
sip:123456@192.168.1.36:8001

(569f6c324981335e0b33daf8fc88ed77)
May  3 03:00:51 [OPTIONS]       OPTIONS request from
172.16.4.22:5060  to
sip:123456@172.16.4.254:5060
, fu is
sip:123456@1XX.1XX.1XX.1XX
May  3 03:00:51 [OPTIONS]       [123456->123456] SIP device
sip:123456@172.16.4.254  found,
relaying to sip:1XX.1XX.1XX.1XX:8001
(76f4319976c85e45b2ff916581912550)

No errors in OpenSIPS logs. Here's output of 'opensips-cli -x mi
fifo ul_dump':

            "AORs": [
                {
                    "AOR": "123456",
                    "Contacts": [
                        {
                            "Contact":
"sip:123456@192.168.1.36:8001 ",
                            "ContactID": "3713509073413807284",
                            "Expires": 47,
                            "Q": "",
                            "Callid": "6_3941098626",
                            "Cseq": 2,
                            "User-agent": "Yealink SIP-T46G
28.83.0.120",
                            "Received": "sip:1XX.1XX.1XX.1XX:8001",
                            "State": "CS_SYNC",
                            "Flags": 0,
                            "Cflags": "",
                            "Socket": "udp:1XX.1XX.1XX.1XX:5060",
                            "Methods": 16383
                        }
                    ]
                }


Re: [OpenSIPS-Users] Problem with fix_nated_contact

2022-05-03 Thread Yury Kirsanov
Hi Bogdan,
Will fix_nated_register() overwrite results of a fix_nated_contact()?

Second question - for 'OPTIONS' where Contact is available - should
fix_nated_contact() replace it with the correct one? Where exactly does
this function take the value to replace Contact with - from
'$avp(received)' param? So it won't do anything if, for example, OPTIONS
packet comes from my LAN Asterisk server and reaches the OpenSIPS LAN
interface? Even though nat_uac_test(7) would confirm a RFC1918 private
address fix_nated_contact() can't do much in this case, is that correct?

Thanks a lot for your help!

Best regards,
Yury.

On Tue, May 3, 2022 at 6:25 PM Bogdan-Andrei Iancu 
wrote:

> Hi Yury,
>
> For a REGISTER you should use the fix_nated_register() function.
>
> Regards,
>
> Bogdan-Andrei Iancu
>
> OpenSIPS Founder and Developer
>   https://www.opensips-solutions.com
> OpenSIPS eBootcamp 23rd May - 3rd June 2022
>   https://opensips.org/training/OpenSIPS_eBootcamp_2022/
>
> On 5/2/22 8:07 PM, Yury Kirsanov wrote:
>
> Hi Bogdan,
> No, nothing in OpenSIPS logs, unfortunately.
>
> Here's another log, I'm doing 'fix_nated_register' in this case at the
> REGISTER route and doing 'fix_nated_contact()' at the very beginning of my
> script, just for the testing purpose.
>
> May  3 03:00:48 [REGISTER]  [123456->123456] Forwarding REGISTER from
> sip:123...@domain.com:5060, requested Expries: 60 to main registrar at
> sip:172.16.4.22:5060 (84327f479c5d50e1634422f72a0b7619)
> May  3 03:00:48 [REPLY] [123456->123456] REGISTER 401 Unauthorized
> FROM 172.16.4.22:5060 (84327f479c5d50e1634422f72a0b7619)
> May  3 03:00:48 [REGISTER]  [123456->123456] Request from
> 1XX.1XX.1XX.1XX:8001, domain domain.com (84327f479c5d50e1634422f72a0b7619)
> May  3 03:00:48 [REGISTER]  [123456->123456] Forwarding REGISTER from
> sip:123...@domain.com:5060, requested Expries: 60 to main registrar at
> sip:172.16.4.22:5060 (84327f479c5d50e1634422f72a0b7619)
> May  3 03:00:48 [REPLY] [123456->123456] REGISTER 200 OK FROM
> 172.16.4.22:5060 (84327f479c5d50e1634422f72a0b7619)
> May  3 03:00:48 [REGREPLY]  [123456->123456] Reply from
> 172.16.4.22:5060, code is 200 - OK, saving contact
> (84327f479c5d50e1634422f72a0b7619)
> May  3 03:00:48 [EVENT] Inserting contact sip:123456@192.168.1.36:8001
> (569f6c324981335e0b33daf8fc88ed77)
> May  3 03:00:51 [OPTIONS]   OPTIONS request from 172.16.4.22:5060 to
> sip:123456@172.16.4.254:5060, fu is sip:123456@1XX.1XX.1XX.1XX
> May  3 03:00:51 [OPTIONS]   [123456->123456] SIP device
> sip:123456@172.16.4.254 found, relaying to sip:1XX.1XX.1XX.1XX:8001
> (76f4319976c85e45b2ff916581912550)
>
> No errors in OpenSIPS logs. Here's output of 'opensips-cli -x mi fifo
> ul_dump':
>
> "AORs": [
> {
> "AOR": "123456",
> "Contacts": [
> {
> "Contact": "sip:123456@192.168.1.36:8001",
> "ContactID": "3713509073413807284",
> "Expires": 47,
> "Q": "",
> "Callid": "6_3941098626",
> "Cseq": 2,
> "User-agent": "Yealink SIP-T46G 28.83.0.120",
> "Received": "sip:1XX.1XX.1XX.1XX:8001",
> "State": "CS_SYNC",
> "Flags": 0,
> "Cflags": "",
> "Socket": "udp:1XX.1XX.1XX.1XX:5060",
> "Methods": 16383
> }
> ]
> }
>
> Thanks and best regards,
> Yury.
>
> On Tue, May 3, 2022 at 12:29 AM Bogdan-Andrei Iancu 
> wrote:
>
>> Hi,
>>
>> Are there any errors when the "fixing" is done? The presence of a param
>> should not impact here.
>>
>> Regards,
>> Bogdan
>>
>> Bogdan-Andrei Iancu
>>
>> OpenSIPS Founder and Developer
>>   https://www.opensips-solutions.com
>> OpenSIPS eBootcamp 23rd May - 3rd June 2022
>>   https://opensips.org/training/OpenSIPS_eBootcamp_2022/
>>
>> On 4/29/22 1:43 PM, Yury Kirsanov wrote:
>>
>> Hi,
>> I'm using OpenSIPS 3.2.4 and recently run into following issue:
>>
>> Imagine simplest proxy setup - OpenSIPS just accepts new packet, for
>> example INVITE, changes destination using 'sethostport()' and then
>> issues 't_relay()' to forward the packet. Let's ignore replies and so on.
>>
>> If I'm doing a 'fix_nated_contact()' before sending this packet I'm
>> expecting Contact: field to be replaced with a source IP:port as per
>> manual. And this works if the Contact is in simple form like '
>> sip:777@192.168.29.106:65033'.
>>
>> But if following Contact comes in OpenSIPS doesn't change it leaving
>> private IP in the contact:
>>
>> 'Contact: sip:777@192.168.29.106:65033;rinstance=2f59b175103f1088'
>>
>> Can you please let me know why is that happening? Thanks!
>>
>> Best 

Re: [OpenSIPS-Users] Problem with fix_nated_contact

2022-05-03 Thread Bogdan-Andrei Iancu

Hi Yury,

For a REGISTER you should use the fix_nated_register() function.

Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
  https://www.opensips-solutions.com
OpenSIPS eBootcamp 23rd May - 3rd June 2022
  https://opensips.org/training/OpenSIPS_eBootcamp_2022/

On 5/2/22 8:07 PM, Yury Kirsanov wrote:

Hi Bogdan,
No, nothing in OpenSIPS logs, unfortunately.

Here's another log, I'm doing 'fix_nated_register' in this case at the 
REGISTER route and doing 'fix_nated_contact()' at the very 
beginning of my script, just for the testing purpose.


May  3 03:00:48 [REGISTER]      [123456->123456] Forwarding REGISTER 
from sip:123...@domain.com:5060 , 
requested Expries: 60 to main registrar at sip:172.16.4.22:5060 
 (84327f479c5d50e1634422f72a0b7619)
May  3 03:00:48 [REPLY]         [123456->123456] REGISTER 401 
Unauthorized FROM 172.16.4.22:5060  
(84327f479c5d50e1634422f72a0b7619)
May  3 03:00:48 [REGISTER]      [123456->123456] Request from 
1XX.1XX.1XX.1XX:8001, domain domain.com  
(84327f479c5d50e1634422f72a0b7619)
May  3 03:00:48 [REGISTER]      [123456->123456] Forwarding REGISTER 
from sip:123...@domain.com:5060 , 
requested Expries: 60 to main registrar at sip:172.16.4.22:5060 
 (84327f479c5d50e1634422f72a0b7619)
May  3 03:00:48 [REPLY]         [123456->123456] REGISTER 200 OK FROM 
172.16.4.22:5060  
(84327f479c5d50e1634422f72a0b7619)
May  3 03:00:48 [REGREPLY]      [123456->123456] Reply from 
172.16.4.22:5060 , code is 200 - OK, saving 
contact (84327f479c5d50e1634422f72a0b7619)
May  3 03:00:48 [EVENT] Inserting contact sip:123456@192.168.1.36:8001 
 (569f6c324981335e0b33daf8fc88ed77)
May  3 03:00:51 [OPTIONS]       OPTIONS request from 172.16.4.22:5060 
 to sip:123456@172.16.4.254:5060 
, fu is sip:123456@1XX.1XX.1XX.1XX
May  3 03:00:51 [OPTIONS]       [123456->123456] SIP device 
sip:123456@172.16.4.254  found, 
relaying to sip:1XX.1XX.1XX.1XX:8001 (76f4319976c85e45b2ff916581912550)


No errors in OpenSIPS logs. Here's output of 'opensips-cli -x mi fifo 
ul_dump':


            "AORs": [
                {
                    "AOR": "123456",
                    "Contacts": [
                        {
                            "Contact": "sip:123456@192.168.1.36:8001 
",

                            "ContactID": "3713509073413807284",
                            "Expires": 47,
                            "Q": "",
                            "Callid": "6_3941098626",
                            "Cseq": 2,
                            "User-agent": "Yealink SIP-T46G 28.83.0.120",
                            "Received": "sip:1XX.1XX.1XX.1XX:8001",
                            "State": "CS_SYNC",
                            "Flags": 0,
                            "Cflags": "",
                            "Socket": "udp:1XX.1XX.1XX.1XX:5060",
                            "Methods": 16383
                        }
                    ]
                }

Thanks and best regards,
Yury.

On Tue, May 3, 2022 at 12:29 AM Bogdan-Andrei Iancu 
mailto:bog...@opensips.org>> wrote:


Hi,

Are there any errors when the "fixing" is done? The presence of a
param should not impact here.

Regards,
Bogdan

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   https://www.opensips-solutions.com  
OpenSIPS eBootcamp 23rd May - 3rd June 2022
   https://opensips.org/training/OpenSIPS_eBootcamp_2022/  


On 4/29/22 1:43 PM, Yury Kirsanov wrote:

Hi,
I'm using OpenSIPS 3.2.4 and recently run into following issue:

Imagine simplest proxy setup - OpenSIPS just accepts new packet,
for example INVITE, changes destination using 'sethostport()'
and then issues 't_relay()' to forward the packet. Let's ignore
replies and so on.

If I'm doing a 'fix_nated_contact()' before sending this packet
I'm expecting Contact: field to be replaced with a source IP:port
as per manual. And this works if the Contact is in simple form
like 'sip:777@192.168.29.106:65033
'.

But if following Contact comes in OpenSIPS doesn't change it
leaving private IP in the contact:

'Contact:
sip:777@192.168.29.106:65033;rinstance=2f59b175103f1088'

Can you please let me know why is that happening? Thanks!

Best regards,
Yury.

___
Users mailing list
Users@lists.opensips.org  

Re: [OpenSIPS-Users] OpenSIPS : no 407 retransmission

2022-05-03 Thread Yannick LE COENT

Hello all,

Could you tell if there is a way to enable 407 in stateful mode ?

Thanks,
Yannick

Le 30/04/2022 à 18:14, Yannick LE COENT a écrit :

Hello Ben,

Thanks for your answer.

This problem occurs when OpenSIPS is not in charge of authenticating 
the INVITE request, but this is done downstream.
I've sent this question to know if somebody has already solved this 
kind of problem.


Best regards,
Yannick

Le 30/04/2022 à 16:15, Ben Newlin a écrit :


I see. Apologies, I misunderstood the problem scenario.

Ben Newlin

*From: *Users  on behalf of Yannick 
LE COENT 

*Date: *Saturday, April 30, 2022 at 5:46 AM
*To: *OpenSIPS users mailling list 
*Subject: *Re: [OpenSIPS-Users] OpenSIPS : no 407 retransmission

*EXTERNAL EMAIL - Please use caution with links and attachments *



Hello Ben,

The 407 is sent upstream, but when it is lost, it is not 
retransmitted by OpenSIPS.

I do not have this problem with other negative status codes (e.g. 486).

This is clearly explained in 
https://opensips.org/pub/opensips/1.8.6/src/ChangeLog


2012-03-21 18:36:58  Bogdan-Andrei Iancu, 
    * [8811] :

    TM will no longer do retransmission for the 407/401 replies
(if no ACK is received) for both local or proxied replies.

According to RFC 3261, retransmitting 407s/401s is probably a bad
idea:

 26.3.2.4 DoS Protection

At the moment, my only solution is to use forward() instead of 
t_relay() in order to use the stateless mode.


Yannick


Yannick,

The default behavior of OpenSIPS is to relay any received responses back 
upstream. If it is not doing that it would have to be because you are stopping 
it in the script. Take a look at the documentation for failure_route [1] which 
explains this. Check your own failure_route in your script; you must be doing 
something there that is telling OpenSIPS not to relay the 401/407 back upstream.

[1]https://www.opensips.org/Documentation/Script-Routes-2-4#toc3

Ben Newlin

From: Users  
  on behalf of Yannick LE 
COENT  

Date: Friday, April 29, 2022 at 6:44 PM

To:users@lists.opensips.org


Subject: [OpenSIPS-Users] OpenSIPS : no 407 retransmission

EXTERNAL EMAIL - Please use caution with links and attachments

Hello,

I'm using OpenSIPS as a proxy in front of another proxy. The 2nd proxy

is in charge of authenticating the request.

This is the callflow:

Alice   OpenSIPS  Proxy#2

    | INVITE |    |

    |--->| INVITE |

    |  100 Tring |--->|

    |<---|    407 |

    |    |<---|

    |    | ACK    |

    |    |--->|

    |    407 |    |

    | X<-|    |

    |    |    |

Since OpenSIPS does not retransmit 401/407, the call setup gets stuck.

What can I do ?

If I set auto_100trying=1, that works, but this increases the number of

INVITE retransmissions since 180Ringing are not received instantly.

Do you have any suggestion ?

Thanks,

Yannick


___
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