21 Jul
2017
21 Jul
'17
4:35 a.m.
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(a)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:
--
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - www.asipto.com
Kamailio World Conference - www.kamailioworld.com
On Thu, Jul 20, 2017 at 06:18:18PM +0300,
Iskren Hadzhinedev wrote:
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)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(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users 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