20 Jul
2017
20 Jul
'17
6:18 p.m.
Hello,
I have a kamailio proxy in front of FreeSWITCH.
Whenever FreeSWITCH initiates the dialog (e.g. sends an INVITE),
kamailio 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
Where 1.2.3.4 is the kamailio public IP and5.6.7.8 is the public IP of
the UAC behind NAT.
I have modparam("path", "use_received", 1) in my config file and to my
understanding that should be sufficient to route to the proper IP, but
kamailio keeps sending INVITEs to 192.168.1.200.
Can anyone tell me what am I missing?
Thanks!
Kind regards,
Iskren
20 Jul
20 Jul
6:20 p.m.
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
--
Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
8 p.m.
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
9:06 p.m.
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> 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(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
21 Jul
21 Jul
11: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
11:42 a.m.
Hello,
are you sure that the Route is like that? The lr parameter and received
should be between angle brakets <> along with the sip uri.
Maybe you should paste here the full REGISTER sent to sip server after
adding the path as well as the INVITE received later. You can replace
the IP addresses that are sensitive for you, but keel everything else as
it is in order to see if there is something wrong in the headers.
Btw, the To header has nothing to do with routing, the R-URI will be
also relevant in this case.
Is kamailio listening directly on a public ip?
Cheers,
Daniel
On 20.07.17 17:18, Iskren Hadzhinedev wrote:
Hello,
I have a kamailio proxy in front of FreeSWITCH.
Whenever FreeSWITCH initiates the dialog (e.g. sends an INVITE),
kamailio 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
Where 1.2.3.4 is the kamailio public IP and5.6.7.8 is the public IP of
the UAC behind NAT.
I have modparam("path", "use_received", 1) in my config file and to
my
understanding that should be sufficient to route to the proper IP, but
kamailio keeps sending INVITEs to 192.168.1.200.
Can anyone tell me what am I missing?
Thanks!
Kind regards,
Iskren
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - www.asipto.com
Kamailio World Conference - www.kamailioworld.com
1:22 p.m.
Hi Daniel,
Yes, those headers are extracted from a wireshark pcap.
Yes, kamailio is listening on a public IP address without any sort of NAT.
Here's the REGISTER sent from kamailio to FreeSWITCH, copied from a pcap
using wireshark with IPs replaced:
Session Initiation Protocol (REGISTER)
Request-Line: REGISTER sip:sip.test.com:5060 SIP/2.0
Method: REGISTER
Request-URI: sip:sip.test.com:5060
Request-URI Host Part: sip.test.com
Request-URI Host Port: 5060
[Resent Packet: False]
Message Header
Record-Route: <sip:KAMAILIO_PUBLIC_IP;lr=on;ftag=1015994109>
Via: SIP/2.0/UDP
KAMAILIO_PUBLIC_IP;branch=z9hG4bKb4a9.4cbfa8e6cdc8083ffe5ff1ea228fea26.0
Via: SIP/2.0/UDP
192.168.1.200:5063;rport=5063;received=UAC_PUBLIC_IP;branch=z9hG4bK332629336
From: <sip:1001@sip.test.com>;tag=1015994109
To: <sip:1001@sip.test.com>
Call-ID: 1821101462(a)192.168.1.200
CSeq: 1 REGISTER
Contact: <sip:1001@192.168.1.200:5063>
Allow: INVITE, INFO, PRACK, ACK, BYE, CANCEL, OPTIONS, NOTIFY,
REGISTER, SUBSCRIBE, REFER, PUBLISH, UPDATE, MESSAGE
Max-Forwards: 69
User-Agent: Yealink SIP-T42G 29.72.23.5
Expires: 3600
Allow-Events: talk,hold,conference,refer,check-sync
Content-Length: 0
Path: <sip:KAMAILIO_PUBLIC_IP;lr;received=sip:UAC_PUBLIC_IP:5063>
Path URI:
sip:KAMAILIO_PUBLIC_IP;lr;received=sip:UAC_PUBLIC_IP:5063
Path Host Part: KAMAILIO_PUBLIC_IP
Path URI parameter: lr
Path URI parameter: received=sip:UAC_PUBLIC_IP:5063
And this is the test INVITE from FreeSWITCH to kamailio:
Session Initiation Protocol (INVITE)
Request-Line: INVITE sip:1001@192.168.1.200:5063 SIP/2.0
Message Header
Via: SIP/2.0/UDP
FREESWITCH_PUBLIC_IP;rport;branch=z9hG4bK543jg8S9Ng8gm
Route: <sip:KAMAILIO_PUBLIC_IP>;lr;received=sip:UAC_PUBLIC_IP:5063
Max-Forwards: 70
From: "" <sip:0000000000@FREESWITCH_PUBLIC_IP>;tag=DyFB81r40609Q
To: <sip:1001@192.168.1.200:5063>
Call-ID: fad5ae53-e89d-1235-d8b5-00163e50ea42
CSeq: 109979488 INVITE
Contact: <sip:mod_sofia@FREESWITCH_PUBLIC_IP:5060>
User-Agent: FreeSWITCH-1.6.9-16-d574870~64bit
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO,
UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, path, replaces
Allow-Events: talk, hold, conference, presence,
as-feature-event, dialog, line-seize, call-info, sla,
include-session-description, presence.winfo, message-summary, refer
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 319
X-FS-Support: update_display,send_info
Message Body
Session Description Protocol
Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): FreeSWITCH 1500611681
1500611682 IN IP4 FREESWITCH_PUBLIC_IP
Session Name (s): FreeSWITCH
Connection Information (c): IN IP4 FREESWITCH_PUBLIC_IP
Time Description, active time (t): 0 0
Media Description, name and address (m): audio 19424
RTP/AVP 9 0 8 3 101 13
Media Attribute (a): rtpmap:9 G722/8000
Media Attribute (a): rtpmap:0 PCMU/8000
Media Attribute (a): rtpmap:8 PCMA/8000
Media Attribute (a): rtpmap:3 GSM/8000
Media Attribute (a): rtpmap:101 telephone-event/8000
Media Attribute (a): fmtp:101 0-16
Media Attribute (a): rtpmap:13 CN/8000
Media Attribute (a): ptime:20
As always, thanks for all your help!
Kind regards,
Iskren
On 21.7.2017 г. 11:42, Daniel-Constantin Mierla wrote:
Hello,
are you sure that the Route is like that? The lr parameter and
received should be between angle brakets <> along with the sip uri.
Maybe you should paste here the full REGISTER sent to sip server after
adding the path as well as the INVITE received later. You can replace
the IP addresses that are sensitive for you, but keel everything else
as it is in order to see if there is something wrong in the headers.
Btw, the To header has nothing to do with routing, the R-URI will be
also relevant in this case.
Is kamailio listening directly on a public ip?
Cheers,
Daniel
On 20.07.17 17:18, Iskren Hadzhinedev wrote:
Hello,
I have a kamailio proxy in front of FreeSWITCH.
Whenever FreeSWITCH initiates the dialog (e.g. sends an INVITE),
kamailio 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
Where 1.2.3.4 is the kamailio public IP and5.6.7.8 is the public IP
of the UAC behind NAT.
I have modparam("path", "use_received", 1) in my config file and to
my understanding that should be sufficient to route to the proper IP,
but kamailio keeps sending INVITEs to 192.168.1.200.
Can anyone tell me what am I missing?
Thanks!
Kind regards,
Iskren
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla
www.twitter.com/miconda --www.linkedin.com/in/miconda
Kamailio Advanced Training -www.asipto.com
Kamailio World Conference -www.kamailioworld.com
3:19 p.m.
Hello,
so it seems that FreeSwitch is not handling properly the Path header. As
you can see, that Path in REGISTER is:
Path: <sip:KAMAILIO_PUBLIC_IP;lr;received=sip:UAC_PUBLIC_IP:5063>
But the INVITE has the ROUTE:
Route: <sip:KAMAILIO_PUBLIC_IP>;lr;received=sip:UAC_PUBLIC_IP:5063
The closing '>' is no longer at the end, making lr and received header
parameters, instead of uri parameters.
If there is nothing easy to fix in freeswitch, you can try to:
- use add_path() instead of add_path_received()
- use set_contact_alias() instead of fix_nated_contact() and
fix_nated_register() and then when the INVITE comes from FreeSwitch use
handle_ruri_alias()
Because I encountered other sip apps that get confused by the value of
received parameter in the Path, I added in master branch an alternative:
-
https://www.kamailio.org/docs/modules/devel/modules/path.html#path.p.receiv…
But for this you need to install from git master.
Cheers,
Daniel
On 21.07.17 12:22, Iskren Hadzhinedev wrote:
Hi Daniel,
Yes, those headers are extracted from a wireshark pcap.
Yes, kamailio is listening on a public IP address without any sort of NAT.
Here's the REGISTER sent from kamailio to FreeSWITCH, copied from a
pcap using wireshark with IPs replaced:
Session Initiation Protocol (REGISTER)
Request-Line: REGISTER sip:sip.test.com:5060 SIP/2.0
Method: REGISTER
Request-URI: sip:sip.test.com:5060
Request-URI Host Part: sip.test.com
Request-URI Host Port: 5060
[Resent Packet: False]
Message Header
Record-Route: <sip:KAMAILIO_PUBLIC_IP;lr=on;ftag=1015994109>
Via: SIP/2.0/UDP
KAMAILIO_PUBLIC_IP;branch=z9hG4bKb4a9.4cbfa8e6cdc8083ffe5ff1ea228fea26.0
Via: SIP/2.0/UDP
192.168.1.200:5063;rport=5063;received=UAC_PUBLIC_IP;branch=z9hG4bK332629336
From: <sip:1001@sip.test.com>;tag=1015994109
To: <sip:1001@sip.test.com>
Call-ID: 1821101462(a)192.168.1.200
CSeq: 1 REGISTER
Contact: <sip:1001@192.168.1.200:5063>
Allow: INVITE, INFO, PRACK, ACK, BYE, CANCEL, OPTIONS, NOTIFY,
REGISTER, SUBSCRIBE, REFER, PUBLISH, UPDATE, MESSAGE
Max-Forwards: 69
User-Agent: Yealink SIP-T42G 29.72.23.5
Expires: 3600
Allow-Events: talk,hold,conference,refer,check-sync
Content-Length: 0
Path: <sip:KAMAILIO_PUBLIC_IP;lr;received=sip:UAC_PUBLIC_IP:5063>
Path URI:
sip:KAMAILIO_PUBLIC_IP;lr;received=sip:UAC_PUBLIC_IP:5063
Path Host Part: KAMAILIO_PUBLIC_IP
Path URI parameter: lr
Path URI parameter: received=sip:UAC_PUBLIC_IP:5063
And this is the test INVITE from FreeSWITCH to kamailio:
Session Initiation Protocol (INVITE)
Request-Line: INVITE sip:1001@192.168.1.200:5063 SIP/2.0
Message Header
Via: SIP/2.0/UDP
FREESWITCH_PUBLIC_IP;rport;branch=z9hG4bK543jg8S9Ng8gm
Route: <sip:KAMAILIO_PUBLIC_IP>;lr;received=sip:UAC_PUBLIC_IP:5063
Max-Forwards: 70
From: "" <sip:0000000000@FREESWITCH_PUBLIC_IP>;tag=DyFB81r40609Q
To: <sip:1001@192.168.1.200:5063>
Call-ID: fad5ae53-e89d-1235-d8b5-00163e50ea42
CSeq: 109979488 INVITE
Contact: <sip:mod_sofia@FREESWITCH_PUBLIC_IP:5060>
User-Agent: FreeSWITCH-1.6.9-16-d574870~64bit
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO,
UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, path, replaces
Allow-Events: talk, hold, conference, presence,
as-feature-event, dialog, line-seize, call-info, sla,
include-session-description, presence.winfo, message-summary, refer
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 319
X-FS-Support: update_display,send_info
Message Body
Session Description Protocol
Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): FreeSWITCH 1500611681
1500611682 IN IP4 FREESWITCH_PUBLIC_IP
Session Name (s): FreeSWITCH
Connection Information (c): IN IP4 FREESWITCH_PUBLIC_IP
Time Description, active time (t): 0 0
Media Description, name and address (m): audio 19424
RTP/AVP 9 0 8 3 101 13
Media Attribute (a): rtpmap:9 G722/8000
Media Attribute (a): rtpmap:0 PCMU/8000
Media Attribute (a): rtpmap:8 PCMA/8000
Media Attribute (a): rtpmap:3 GSM/8000
Media Attribute (a): rtpmap:101 telephone-event/8000
Media Attribute (a): fmtp:101 0-16
Media Attribute (a): rtpmap:13 CN/8000
Media Attribute (a): ptime:20
As always, thanks for all your help!
Kind regards,
Iskren
On 21.7.2017 г. 11:42, Daniel-Constantin Mierla 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
Hello,
are you sure that the Route is like that? The lr parameter and
received should be between angle brakets <> along with the sip uri.
Maybe you should paste here the full REGISTER sent to sip server
after adding the path as well as the INVITE received later. You can
replace the IP addresses that are sensitive for you, but keel
everything else as it is in order to see if there is something wrong
in the headers.
Btw, the To header has nothing to do with routing, the R-URI will be
also relevant in this case.
Is kamailio listening directly on a public ip?
Cheers,
Daniel
On 20.07.17 17:18, Iskren Hadzhinedev wrote:
Hello,
I have a kamailio proxy in front of FreeSWITCH.
Whenever FreeSWITCH initiates the dialog (e.g. sends an INVITE),
kamailio 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
Where 1.2.3.4 is the kamailio public IP and5.6.7.8 is the public IP
of the UAC behind NAT.
I have modparam("path", "use_received", 1) in my config file and to
my understanding that should be sufficient to route to the proper
IP, but kamailio keeps sending INVITEs to 192.168.1.200.
Can anyone tell me what am I missing?
Thanks!
Kind regards,
Iskren
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - www.asipto.com
Kamailio World Conference - www.kamailioworld.com
23 Jul
23 Jul
12:51 p.m.
Hi,
Thanks for all your help, much appreciated. I'll see how I get on and
will report back.
Kind regards,
Iskren
On 21.7.2017 г. 15:19, Daniel-Constantin Mierla wrote:
Hello,
so it seems that FreeSwitch is not handling properly the Path header.
As you can see, that Path in REGISTER is:
Path: <sip:KAMAILIO_PUBLIC_IP;lr;received=sip:UAC_PUBLIC_IP:5063>
But the INVITE has the ROUTE:
Route: <sip:KAMAILIO_PUBLIC_IP>;lr;received=sip:UAC_PUBLIC_IP:5063
The closing '>' is no longer at the end, making lr and received header
parameters, instead of uri parameters.
If there is nothing easy to fix in freeswitch, you can try to:
- use add_path() instead of add_path_received()
- use set_contact_alias() instead of fix_nated_contact() and
fix_nated_register() and then when the INVITE comes from FreeSwitch
use handle_ruri_alias()
Because I encountered other sip apps that get confused by the value of
received parameter in the Path, I added in master branch an alternative:
-
https://www.kamailio.org/docs/modules/devel/modules/path.html#path.p.receiv…
But for this you need to install from git master.
Cheers,
Daniel
On 21.07.17 12:22, Iskren Hadzhinedev wrote:
Hi Daniel,
Yes, those headers are extracted from a wireshark pcap.
Yes, kamailio is listening on a public IP address without any sort of
NAT.
Here's the REGISTER sent from kamailio to FreeSWITCH, copied from a
pcap using wireshark with IPs replaced:
Session Initiation Protocol (REGISTER)
Request-Line: REGISTER sip:sip.test.com:5060 SIP/2.0
Method: REGISTER
Request-URI: sip:sip.test.com:5060
Request-URI Host Part: sip.test.com
Request-URI Host Port: 5060
[Resent Packet: False]
Message Header
Record-Route: <sip:KAMAILIO_PUBLIC_IP;lr=on;ftag=1015994109>
Via: SIP/2.0/UDP
KAMAILIO_PUBLIC_IP;branch=z9hG4bKb4a9.4cbfa8e6cdc8083ffe5ff1ea228fea26.0
Via: SIP/2.0/UDP
192.168.1.200:5063;rport=5063;received=UAC_PUBLIC_IP;branch=z9hG4bK332629336
From: <sip:1001@sip.test.com>;tag=1015994109
To: <sip:1001@sip.test.com>
Call-ID: 1821101462(a)192.168.1.200
CSeq: 1 REGISTER
Contact: <sip:1001@192.168.1.200:5063>
Allow: INVITE, INFO, PRACK, ACK, BYE, CANCEL, OPTIONS,
NOTIFY, REGISTER, SUBSCRIBE, REFER, PUBLISH, UPDATE, MESSAGE
Max-Forwards: 69
User-Agent: Yealink SIP-T42G 29.72.23.5
Expires: 3600
Allow-Events: talk,hold,conference,refer,check-sync
Content-Length: 0
Path: <sip:KAMAILIO_PUBLIC_IP;lr;received=sip:UAC_PUBLIC_IP:5063>
Path URI:
sip:KAMAILIO_PUBLIC_IP;lr;received=sip:UAC_PUBLIC_IP:5063
Path Host Part: KAMAILIO_PUBLIC_IP
Path URI parameter: lr
Path URI parameter: received=sip:UAC_PUBLIC_IP:5063
And this is the test INVITE from FreeSWITCH to kamailio:
Session Initiation Protocol (INVITE)
Request-Line: INVITE sip:1001@192.168.1.200:5063 SIP/2.0
Message Header
Via: SIP/2.0/UDP
FREESWITCH_PUBLIC_IP;rport;branch=z9hG4bK543jg8S9Ng8gm
Route:
<sip:KAMAILIO_PUBLIC_IP>;lr;received=sip:UAC_PUBLIC_IP:5063
Max-Forwards: 70
From: "" <sip:0000000000@FREESWITCH_PUBLIC_IP>;tag=DyFB81r40609Q
To: <sip:1001@192.168.1.200:5063>
Call-ID: fad5ae53-e89d-1235-d8b5-00163e50ea42
CSeq: 109979488 INVITE
Contact: <sip:mod_sofia@FREESWITCH_PUBLIC_IP:5060>
User-Agent: FreeSWITCH-1.6.9-16-d574870~64bit
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO,
UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, path, replaces
Allow-Events: talk, hold, conference, presence,
as-feature-event, dialog, line-seize, call-info, sla,
include-session-description, presence.winfo, message-summary, refer
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 319
X-FS-Support: update_display,send_info
Message Body
Session Description Protocol
Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): FreeSWITCH 1500611681
1500611682 IN IP4 FREESWITCH_PUBLIC_IP
Session Name (s): FreeSWITCH
Connection Information (c): IN IP4 FREESWITCH_PUBLIC_IP
Time Description, active time (t): 0 0
Media Description, name and address (m): audio 19424
RTP/AVP 9 0 8 3 101 13
Media Attribute (a): rtpmap:9 G722/8000
Media Attribute (a): rtpmap:0 PCMU/8000
Media Attribute (a): rtpmap:8 PCMA/8000
Media Attribute (a): rtpmap:3 GSM/8000
Media Attribute (a): rtpmap:101 telephone-event/8000
Media Attribute (a): fmtp:101 0-16
Media Attribute (a): rtpmap:13 CN/8000
Media Attribute (a): ptime:20
As always, thanks for all your help!
Kind regards,
Iskren
On 21.7.2017 г. 11:42, Daniel-Constantin Mierla 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
Hello,
are you sure that the Route is like that? The lr parameter and
received should be between angle brakets <> along with the sip uri.
Maybe you should paste here the full REGISTER sent to sip server
after adding the path as well as the INVITE received later. You can
replace the IP addresses that are sensitive for you, but keel
everything else as it is in order to see if there is something wrong
in the headers.
Btw, the To header has nothing to do with routing, the R-URI will be
also relevant in this case.
Is kamailio listening directly on a public ip?
Cheers,
Daniel
On 20.07.17 17:18, Iskren Hadzhinedev wrote:
Hello,
I have a kamailio proxy in front of FreeSWITCH.
Whenever FreeSWITCH initiates the dialog (e.g. sends an INVITE),
kamailio 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
Where 1.2.3.4 is the kamailio public IP and5.6.7.8 is the public IP
of the UAC behind NAT.
I have modparam("path", "use_received", 1) in my config file and to
my understanding that should be sufficient to route to the proper
IP, but kamailio keeps sending INVITEs to 192.168.1.200.
Can anyone tell me what am I missing?
Thanks!
Kind regards,
Iskren
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla
www.twitter.com/miconda --www.linkedin.com/in/miconda
Kamailio Advanced Training -www.asipto.com
Kamailio World Conference -www.kamailioworld.com
2685
days inactive
2688
days old
8 comments
4 participants
participants (4)
-
Alex Balashov -
Daniel-Constantin Mierla -
E. Schmidbauer -
Iskren Hadzhinedev