[SR-Users] Issue with Socket selection on Forwarding ACK message
Emmanuel BUU
emmanuel.buu at ives.fr
Sat Feb 3 00:13:42 CET 2018
Le 2018-02-02 à 23:12, Timmo Verlaan a écrit :
> Hi Emmanuel,
>
> I now understand what you're dealing with. No, we always go out over a
> different interface so a double header is always present. Although I'd
> say that enable_double_rr should always add two route headers. Even if
> both route headers are equal.
I don't think this is the correct behavior to add to identical SIP URI
in the route set.
>
> As a workaround you could add the route headers manually using some
> kamailio scripting. We did this for a while until we were able to fix
> loose route to cover our usecase (it ignored default port).
We will post a ticket and submit a patch to fix loose_route() instead.
Don't want to add some strange cases to out script which is already
quite complex.
>
> Regards,
> Timmo
Emmanuel
>
> On 2 Feb 2018 16:50, "Emmanuel BUU" <emmanuel.buu at ives.fr
> <mailto:emmanuel.buu at ives.fr>> wrote:
>
> Hi Timmo,
>
> We do have *enable_double_rr* set to 1 but the route set added by
> the proxy when record_route() on the INVITE consists in a single
> route. This is because Alice and Bob are BOTH registered with the
> alternate port 5066 on the same interfacec and using the same
> protocol (UDP). To us, this seems logical.
>
> Do you have a double route in your case even though both party are
> on the same port, same interface and both UDP? If so, could you
> send us an exemple of Route: header?
>
> Emmanuel BUU
> IVèS
>
>
> Le 2018-02-02 à 14:18, Timmo Verlaan a écrit :
>> Hi Thomas,
>>
>> We have a similar situation but we use double route headers so
>> the correct egress socket is chosen. You can enable this by
>> setting a modparam: enable_double_rr.
>> Would this be a solution for you?
>>
>> Kind regards,
>> Timmo Verlaan
>>
>> On 2 Feb 2018 13:57, "Thomas Carvello" <thomas.carvello at ives.fr
>> <mailto:thomas.carvello at ives.fr>> wrote:
>>
>> Thank you for you answer.
>>
>> We have tried to change the local port for Bob, but it doesnt
>> change anything. And the contact value in 200 OK message has
>> no influence in this case.
>>
>> In fact, we have made a further investigation regarding the
>> socket selection *and read the code. *The issue seems to be
>> located in the RR module and the loose_route() function.
>>
>> In the after_loose() function in loose.c, the function
>> set_force_socket() is called only if a DOUBLE route is
>> mentioned in the route set of the ACK message
>>
>> But when both users are using 5066 as proxy port, we get only
>> ONE route for the proxy in the route set (and to us it is
>> OK). In this case, we get a trace:
>>
>> "No next URI found"
>>
>> and the code exits. Later in the message processing, when
>> t_relay() is called, the forward_request() selects the first
>> socket defined in our configuration instead.
>>
>> At this point, we can't presume what socket we be select. We
>> believe that it is a software bug and that after_loose()
>> should force the send_socket even though we have only one
>> route in the route set. We also checked the 5.1 code and
>> there is no change in this module that would alter this behavior.
>>
>> Are we missing something?
>>
>> Thank you for you time,
>>
>> Thomas
>>
>> Le 26/01/2018 à 15:43, Евгений Голей a écrit :
>>> Hi
>>>
>>> Could it be because of Bob happend to use 5060 as local port?
>>> Yes, the port and the address in the ACK are indicated by
>>> what the value in Contact was in reply 200 Ok. Look at the
>>> message 200 Ok
>>>
>>>
>>> Четверг, 25 января 2018, 13:00 +03:00 от Thomas Carvello
>>> <thomas.carvello at ives.fr> <mailto:thomas.carvello at ives.fr>:
>>>
>>>
>>> Hello,
>>>
>>> i have an issue with my Kamailio 4.1.9 configuration.
>>>
>>> This configuration is multi-homed, we have*two network*
>>> interfaces, one on a private network and on the public
>>> Internet. Kamailio is configured to listen on port 5060
>>> and 5066 on both interfaces. We register two users Alice
>>> and Bob on the public Internet using port 5066. Both
>>> users are behind a NAT and we capture the SIP exchange
>>> on the proxy server.
>>>
>>> We have set the parameter mhomed=1
>>>
>>> When Alice calls Bob, we have
>>>
>>> Alice Proxy Bob
>>>
>>> src=5063 dst=5066
>>> INVITE ------------------>
>>>
>>> src=5066
>>> ------ INVITE ---------------> dst=5060
>>>
>>> dst=5066
>>> <------- 200 OK -------------- src=5060
>>>
>>>
>>> dst=5063
>>> <------- 200 OK --------- src=5066
>>>
>>> src=5063 dst=5066
>>> -------- ACK ----------->
>>>
>>> *src=5060 (blocked by NAT)*
>>> ------ ACK-----x dst=5060
>>>
>>>
>>> The ACK packet gets relayed with the wrong source port.
>>> Then the NAT rejects the packet and the call cannot be
>>> established.
>>>
>>> For some reason, when Bob calls Alice, the call is
>>> correctly established. Could it be because Bob happend
>>> to use 5060 as local port?
>>>
>>> Also, if we set nhomed=0 it works BUT we are not sure
>>> that multi homed is handled correctly.
>>>
>>> I was wondering if you have encounter this issue before?
>>>
>>> I have investigated the code for selection socket and
>>> what is the logic of this selection ?
>>>
>>> /*How does kamailo knows that it should choose 5066 as
>>> src port if the user is registered using port 5066
>>> instead of 5066?*
>>> /
>>>
>>> Thank you for your time.
>>>
>>> Thomas
>>>
>>>
>>>
>>> _______________________________________________
>>> Kamailio (SER) - Users Mailing List
>>> sr-users at lists.kamailio.org
>>> <mailto:sr-users at lists.kamailio.org>
>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>> <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
>>>
>>>
>>>
>>> Best
>>> Evgeniy
>>
>>
>> _______________________________________________
>> Kamailio (SER) - Users Mailing List
>> sr-users at lists.kamailio.org <mailto:sr-users at lists.kamailio.org>
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>> <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
>>
>>
>>
>> _______________________________________________
>> Kamailio (SER) - Users Mailing List
>> sr-users at lists.kamailio.org <mailto:sr-users at lists.kamailio.org>
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>> <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org <mailto:sr-users at lists.kamailio.org>
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
>
>
>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20180203/2246cf46/attachment.html>
More information about the sr-users
mailing list