[SR-Users] Issue with Socket selection on Forwarding ACK message
Timmo Verlaan
tverlaan at gmail.com
Fri Feb 2 14:18:05 CET 2018
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> 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> <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
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>
>
> Best
> Evgeniy
>
>
>
> _______________________________________________
> 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/20180202/6c3d3913/attachment.html>
More information about the sr-users
mailing list