[OpenSIPS-Users] Problem with fix_nated_contact
Yury Kirsanov
y.kirsanov at gmail.com
Tue May 3 09:04:11 UTC 2022
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 <bogdan at 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 <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
>> 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:123456 at 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:123456 at 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 at 192.168.1.36:8001
>> (569f6c324981335e0b33daf8fc88ed77)
>> May 3 03:00:51 [OPTIONS] OPTIONS request from 172.16.4.22:5060 to
>> sip:123456 at 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 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",
>> "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>
>> 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:7777777 at 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 listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20220503/725856ae/attachment.html>
More information about the Users
mailing list