[SR-Users] path use_received not working?

[E. Schmidbauer]

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 at 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 at 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 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/20170720/e5051203/attachment.html>