[OpenSIPS-Users] Problem with fix_nated_contact

Bogdan-Andrei Iancu bogdan at opensips.org
Tue May 3 08:55:12 UTC 2022


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 
> <bogdan at opensips.org <mailto:bogdan at 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  <https://www.opensips-solutions.com>
>     OpenSIPS eBootcamp 23rd May - 3rd June 2022
>        https://opensips.org/training/OpenSIPS_eBootcamp_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:123456 at domain.com:5060
>>     <http://sip:123456@domain.com:5060>, requested Expries: 60 to
>>     main registrar at sip:172.16.4.22:5060 <http://172.16.4.22:5060>
>>     (84327f479c5d50e1634422f72a0b7619)
>>     May  3 03:00:48 [REPLY]         [123456->123456] REGISTER 401
>>     Unauthorized FROM 172.16.4.22:5060 <http://172.16.4.22:5060>
>>     (84327f479c5d50e1634422f72a0b7619)
>>     May  3 03:00:48 [REGISTER]      [123456->123456] Request from
>>     1XX.1XX.1XX.1XX:8001, domain domain.com <http://domain.com>
>>     (84327f479c5d50e1634422f72a0b7619)
>>     May  3 03:00:48 [REGISTER]      [123456->123456] Forwarding
>>     REGISTER from sip:123456 at domain.com:5060
>>     <http://sip:123456@domain.com:5060>, requested Expries: 60 to
>>     main registrar at sip:172.16.4.22:5060 <http://172.16.4.22:5060>
>>     (84327f479c5d50e1634422f72a0b7619)
>>     May  3 03:00:48 [REPLY]         [123456->123456] REGISTER 200 OK
>>     FROM 172.16.4.22:5060 <http://172.16.4.22:5060>
>>     (84327f479c5d50e1634422f72a0b7619)
>>     May  3 03:00:48 [REGREPLY]      [123456->123456] Reply from
>>     172.16.4.22:5060 <http://172.16.4.22:5060>, code is 200 - OK,
>>     saving contact (84327f479c5d50e1634422f72a0b7619)
>>     May  3 03:00:48 [EVENT] Inserting contact
>>     sip:123456 at 192.168.1.36:8001
>>     <http://sip:123456@192.168.1.36:8001>
>>     (569f6c324981335e0b33daf8fc88ed77)
>>     May  3 03:00:51 [OPTIONS]       OPTIONS request from
>>     172.16.4.22:5060 <http://172.16.4.22:5060> to
>>     sip:123456 at 172.16.4.254:5060
>>     <http://sip:123456@172.16.4.254:5060>, fu is
>>     sip:123456 at 1XX.1XX.1XX.1XX
>>     May  3 03:00:51 [OPTIONS]       [123456->123456] SIP device
>>     sip:123456 at 172.16.4.254 <mailto:sip%3A123456 at 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 at 192.168.1.36:8001 <http://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
>>     <bogdan at opensips.org <mailto:bogdan at 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  <https://www.opensips-solutions.com>
>>         OpenSIPS eBootcamp 23rd May - 3rd June 2022
>>            https://opensips.org/training/OpenSIPS_eBootcamp_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:7777777 at 192.168.29.106:65033
>>>         <http://sip:7777777@192.168.29.106:65033>'.
>>>
>>>         But if following Contact comes in OpenSIPS doesn't change it
>>>         leaving private IP in the contact:
>>>
>>>         'Contact:
>>>         sip:7777777 at 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 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>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20220503/8ad12a69/attachment-0001.html>


More information about the Users mailing list