Re: [SR-Users] path use_received not working?

Just for clarification: even if Record-Route is not necessary for REGISTER, should be harmless and should not affect routing of subsequent requests, because Record-Route is not saved in location.

Cheers, Daniel

On 20.07.17 20:06, E. Schmidbauer wrote:

don't add recordroute on the register packet that is being forwarded to FreeSWITCH add_path_received(); rtpproxy_manage("cw"); # record_route(); <- this line

On Thu, Jul 20, 2017 at 1:00 PM, Iskren Hadzhinedev <iskren.hadzhinedev@ikiji.com mailto:iskren.hadzhinedev@ikiji.com> wrote:

Hi Alex,
Don't believe so, it's a very minimal configuration; its contents
are below.
Thanks for your input!

mpath = "/usr/lib/x86_64-linux-gnu/kamailio/modules"

loadmodule "mi_fifo.so"
loadmodule "kex.so"
loadmodule "sl.so"
loadmodule "rr.so"
loadmodule "pv.so"
loadmodule "maxfwd.so"
loadmodule "textops.so"
loadmodule "siputils.so"
loadmodule "xlog.so"
loadmodule "sanity.so"
loadmodule "ctl.so"
loadmodule "cfg_rpc.so"
loadmodule "mi_rpc.so"
loadmodule "path.so"
loadmodule "dispatcher.so"
loadmodule "nathelper.so"
loadmodule "rtpproxy.so"

#!ifdef WITH_DEBUG
loadmodule "debugger.so"
#!endif

modparam("mi_fifo", "fifo_name", "/tmp/kamailio_fifo")
modparam("rr", "enable_full_lr", 1)
modparam("path", "use_received", 1)
modparam("nathelper", "received_avp", "$avp(RECEIVED)")
modparam("nathelper", "nortpproxy_str", "a=sdpmangled:yes\r\n")
modparam("rtpproxy", "rtpproxy_sock",
"unix:/var/run/rtpproxy/rtpproxy.sock")

#!ifdef WITH_DEBUG
modparam("debugger", "cfgtrace", 1)
#!endif

#----- Routing -----#


route {
    if (!sanity_check()) {
        exit;
    }

    if ( !mf_process_maxfwd_header("10") )
    {
        sl_send_reply("483","To Many Hops");
        xlog("L_NOTICE", "$si $rm $ru -- too many hops\n");
        exit;
    }


    force_rport();

    if (!ds_is_from_list("1"))
    {
        # SIP request packet client->backend

        if( !loose_route() )
        {
            if( !ds_select_dst("1", "1") )
            {
                # TODO: Handle gracefully once everything works fine
                drop();
            }
        }

        if (nat_uac_test("19")) {
            if (method=="REGISTER") {
                fix_nated_register();
            } else {
                fix_nated_contact();
            }
        }


        add_path_received();
        rtpproxy_manage("cw");
        record_route();
    }
    else
    {
        # SIP request packet backend->client
        loose_route();
        rtpproxy_manage("cw");
        record_route();
    }

    forward();
}


onreply_route {

    if(!ds_is_from_list("1"))
    {
        # SIP reply packet client->backend

        fix_nated_contact();
        rtpproxy_manage("cw");
    }
    else
    {
        # SIP reply packet backend->client
        rtpproxy_manage("cw");
    }

    return(1);
}

Kind regards,
Iskren

On 20.7.2017 г. 18:20, Alex Balashov wrote:

...

On Thu, Jul 20, 2017 at 06:18:18PM +0300, Iskren Hadzhinedev wrote:

...

doesn't use the 'received' parameter and it forwards to the RFC1918 IP
address. The initial INVITE from FreeSWITCH has the following headers:

To: <sip:1001@192.168.1.200:5063>
Route: <sip:1.2.3.4>;lr;received=sip:5.6.7.8:5063

Is there any possibility that your Kamailio config strips Route headers
from initial invites? The stock config ships this way.

-- Alex

_______________________________________________
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