[OpenSIPS-Users] Port changes

[Bogdan-Andrei Iancu]

Hi Schneur,

It is not 100% correct, as a sip message may come from a another SIP 
server and in this case the Contact (belong to the end point) should not 
be re-written with the IP OPenSIPS sees as source (which is the other 
SIP server).
Shortly said, you can force the re-write as time as you know that you 
are dealing with traffic from a SIP endpoint (or acting as an endpoint), 
and not from a SIP proxy.

Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   http://www.opensips-solutions.com
OpenSIPS Summit 2018
   http://www.opensips.org/events/Summit-2018Amsterdam

On 02/14/2018 01:45 PM, Schneur Rosenberg wrote:
> You're right, I noticed that the port was wrong at the first invite,
> but I didn't realize that it was fixed, I thought it left it
> untouched, I just checked again and you're correct it  did fix it.
>
> Is there any downside (besides for obvious performance reasons) to
> call fix_nated_contact() on each packet? 99% of  our customers are
> behind NAT anyway, I assume it cant hurt, I assume it uses the
> received IP and port to rewrite the contact,  so even if the correct
> IP and port was sent with the initial invite it wont do any harm, is
> my assumption correct?
>
> On Wed, Feb 14, 2018 at 11:24 AM, Bogdan-Andrei Iancu
> <bogdan at opensips.org> wrote:
>> Hi Schneur,
>>
>> I see at initial INVITE you have the same issue - the contact advertises the
>> 34063 port, but the source IP is 1090; and you do fix_nated_contact(). So,
>> based on the initial contact, you learned that the caller device is behind a
>> NAT (or with a bogus ALG). The idea is to remember this (caller requires
>> help) during the whole dialog (maybe using some dialog flags) and each time
>> you receive a request / reply from it -> do the fix_nated_contact(). This
>> will trigger the fix on the 200 OK and to get a routable URI there.
>>
>> Regards,
>>
>> Bogdan-Andrei Iancu
>>
>> OpenSIPS Founder and Developer
>>    http://www.opensips-solutions.com
>> OpenSIPS Summit 2018
>>    http://www.opensips.org/events/Summit-2018Amsterdam
>>
>> On 02/13/2018 12:16 PM, Schneur Rosenberg wrote:
>>> Bogdan its only happening when the clients SIP ALG fixes the contact,
>>> when the contact is broken I'm already using fix_nated_contact, do you
>>> think I should use fix_nated_contact even when the contact was already
>>> fixed by the SIP ALG?
>>>
>>> The clients router does not support disabling SIP ALG, I can try using
>>> a non standard port, I've sen some routers ALG ignoring the packets
>>> when sent to alternative port.
>>>
>>> On Tue, Feb 13, 2018 at 12:04 PM, Bogdan-Andrei Iancu
>>> <bogdan at opensips.org> wrote:
>>>> Hi Schneur,
>>>>
>>>> The ACK is routed back via the Route set (the Record Route headers from
>>>> the
>>>> initial Invite) and the Contact received in the final reply (in the 200
>>>> OK
>>>> in your case). This is called in-dialog routing and is exclusively based
>>>> on
>>>> Route set (RR headers + Contact).
>>>>
>>>> The rport as part of via is used only for routing back the replies for a
>>>> requests (in transaction routing) and has no impact on the in-dialog
>>>> routing.
>>>>
>>>> So, if the RURI in ACK (which should be the Contact in the received 200
>>>> OK)
>>>> is broken, maybe you should do a fix_nated_contact() for the Contact when
>>>> handling the 200 OK reply.
>>>>
>>>> Best regards,
>>>>
>>>> Bogdan-Andrei Iancu
>>>>
>>>> OpenSIPS Founder and Developer
>>>>     http://www.opensips-solutions.com
>>>> OpenSIPS Summit 2018
>>>>     http://www.opensips.org/events/Summit-2018Amsterdam
>>>>
>>>>
>>>> On 02/12/2018 05:05 PM, Schneur Rosenberg wrote:
>>>>> I have this interesting scenario, caller sends call to our OpenSIPS
>>>>> who actsd as a loadbalancer which sends the call to a gateway for
>>>>> termination and the gateway sets Session-Expires: 1800;refresher=uas,
>>>>> the caller sends call the call through port 1090 and the rport in the
>>>>> Via shows rport=1090 and so far everything is ok, but after 15 minutes
>>>>> the gateway sends a reinvite,  OpenSIPS sends it to the client and the
>>>>> client sends a OK and OpenSIPS properly sends the OK to the gateway,
>>>>> the gateway sends a ACK to OpenSIPS, but here the problem starts
>>>>> OpenSIPS sends the ACK to the port in the Contact header which is not
>>>>> the same port as the rport, the clients router does not recognize the
>>>>> packet and blocks it, the client sends multiple OK's to OpenSIPS who
>>>>> ignores it because he has already moved on, as far as OpenSIPS is
>>>>> concerned the ACK has already been sent to the next hop, and after
>>>>> approx 30 seconds the client does not receive the ACK and sends a BYE
>>>>> and the call terminates.
>>>>>
>>>>> Why is OpenSIPS changing the port to the Contact port? and what can I
>>>>> do to fix it?