[OpenSIPS-Users] Problem with fix_nated_contact

Bogdan-Andrei Iancu bogdan at opensips.org
Tue May 3 09:51:59 UTC 2022


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 <http://172.16.22.4:5060> and Contact is 
> set to 'sip:172.167.22.4:5060 <http://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 
> <bogdan at opensips.org <mailto:bogdan at opensips.org>> wrote:
>
>     See inline
>
>     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/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/00412317/attachment-0001.html>


More information about the Users mailing list