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....@ives.fr <mailto:emmanuel....@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.carve...@ives.fr
    <mailto:thomas.carve...@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.carve...@ives.fr> <mailto:thomas.carve...@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@lists.kamailio.org
            <mailto:sr-users@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@lists.kamailio.org <mailto:sr-users@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@lists.kamailio.org <mailto:sr-users@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@lists.kamailio.org <mailto:sr-users@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@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Reply via email to