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
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
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
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> 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 https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
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:5063Is 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
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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
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@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@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
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.receive...
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@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@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
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.receive...
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@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@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
-- Daniel-Constantin Mierla www.twitter.com/miconda --www.linkedin.com/in/miconda Kamailio Advanced Training -www.asipto.com Kamailio World Conference -www.kamailioworld.com
-
Alex Balashov -
Daniel-Constantin Mierla -
E. Schmidbauer -
Iskren Hadzhinedev