[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