kamailio as UAC and NAPTR / sendsocket question
Hi List, I try to register to Deutsche Telekom and there product Deutschland Lan siptrunk. Thats works find but i see an intressting behaviour on selecting the right outgoing interface. Kamailio is sending out with tcp the REQUEST via first private ip configured on that server (172.20.120.53). There is no listen directive for that. I forced NAPTR to use tcp or udp and i assume that kamailio got the right dns answers. On the list i read also that i can use force_send_socket to force the outgoing request. Now my idea - hey i use the $rP for the outgoing to select the right outgoing listen directive. $rP - reference to transport protocol of R-URI But to my surprise the logfile told me thats "UDP" - it sends out via TCP (thats okay). Whats an good transport selector variable from kamailio that works? event_route[tm:local-request] { if(!is_method("OPTIONS")) { xlog("L_INFO", "[tm:local-request] request [$rm] from [$fu] to [$ru] [$rP]\n"); } } INFO: <script>: [tm:local-request] request [REGISTER] from [ sip:+49XXXXXXXX@sip-trunk.telekom.de] to [sip:sip-trunk.telekom.de] [UDP] listen=tcp:2xx.xx.xx.xx:5060 listen=udp:2xx.xx.xx.xx:5060 listen=tls:2xx.xx.xx.xx:5061 advertise CFG_EXT_NAME:5061 listen=udp:172.20.120.55:5060 listen=udp:172.20.120.56:5060 listen=udp:172.20.120.57:5060 listen=udp:172.20.120.58:5060 listen=tcp:172.20.120.58:5060 use_dns_cache=on # use internal DNS cache use_dns_failover=on # depends on internal DNS cache dns_srv_loadbalancing=on dns_try_naptr=on dns_retr_time=1 # seconds before retrying a DNS request dns_retr_no=3 # number of DNS retransmissions dns_naptr_ignore_rfc=yes # ignore target NAPTR priority dns_tcp_pref=30 # TCP has second-highest priority dns_udp_pref=10 # use UDP with least priority tcp_connection_lifetime=3605 # set higher than registration expires #dont' restore modparam("uac","restore_mode","none") modparam("uac","restore_dlg",0) ## UAC REGISTER #!ifdef WITH_UAC_REGISTER modparam("uac", "reg_contact_addr", "CFG_PROD_IP") modparam("uac", "reg_timer_interval", 10) modparam("uac", "reg_retry_interval", 10) modparam("uac", "reg_db_url", DBURL) modparam("uac", "restore_mode", "none") modparam("uac", "auth_username_avp", "$avp(AVP_AUTH_USERNAME)") modparam("uac", "auth_password_avp", "$avp(AVP_AUTH_PASSWORD)") modparam("uac", "auth_realm_avp", "$avp(AVP_AUTH_REALM)") #!endif ip a l 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: ens192: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 00:50:56:b5:c1:48 brd ff:ff:ff:ff:ff:ff inet 172.20.120.53/24 brd 172.20.120.255 scope global ens192 valid_lft forever preferred_lft forever inet 2xx.xx.xx.xx/29 scope global ens192 valid_lft forever preferred_lft forever inet 172.20.120.56/24 scope global secondary ens192 valid_lft forever preferred_lft forever inet 172.20.120.57/24 scope global secondary ens192 valid_lft forever preferred_lft forever inet 172.20.120.58/24 scope global secondary ens192 valid_lft forever preferred_lft forever inet 172.20.120.55/24 brd 172.20.120.255 scope global secondary ens192 valid_lft forever preferred_lft forever inet6 fe80::250:56ff:feb5:c148/64 scope link valid_lft forever preferred_lft forever default via 172.20.120.253 dev ens192 172.20.120.0/24 dev ens192 proto kernel scope link src 172.20.120.53 2xx.xx.xx.xx/29 dev ens192 proto kernel scope link src 2xx.xx.xx.xx -- Kind Regards Mit freundlichen Grüßen *Karsten Horsmann*
Hi List, after reading the corebook in the wiki and some issue reports (1), I think it's not possible to force the outgoing ip for uac.so registration. I saw traffic with 172.20.120.53:45689 - - - > reg.sip-trunk.telekom.de So that's random highport generated traffic tcp traffic on the first interface ip. AFAIK this behavior could not change, right? (1) https://github.com/kamailio/kamailio/issues/1532 Karsten Horsmann <khorsmann@gmail.com> schrieb am Fr., 21. Juni 2019, 11:44:
Hi List,
I try to register to Deutsche Telekom and there product Deutschland Lan siptrunk.
Thats works find but i see an intressting behaviour on selecting the right outgoing interface. Kamailio is sending out with tcp the REQUEST via first private ip configured on that server (172.20.120.53). There is no listen directive for that.
I forced NAPTR to use tcp or udp and i assume that kamailio got the right dns answers.
On the list i read also that i can use force_send_socket to force the outgoing request.
Now my idea - hey i use the $rP for the outgoing to select the right outgoing listen directive. $rP - reference to transport protocol of R-URI But to my surprise the logfile told me thats "UDP" - it sends out via TCP (thats okay).
Whats an good transport selector variable from kamailio that works?
event_route[tm:local-request] { if(!is_method("OPTIONS")) { xlog("L_INFO", "[tm:local-request] request [$rm] from [$fu] to [$ru] [$rP]\n"); } }
INFO: <script>: [tm:local-request] request [REGISTER] from [ sip:+49XXXXXXXX@sip-trunk.telekom.de] to [sip:sip-trunk.telekom.de] [UDP]
listen=tcp:2xx.xx.xx.xx:5060 listen=udp:2xx.xx.xx.xx:5060 listen=tls:2xx.xx.xx.xx:5061 advertise CFG_EXT_NAME:5061
listen=udp:172.20.120.55:5060 listen=udp:172.20.120.56:5060 listen=udp:172.20.120.57:5060 listen=udp:172.20.120.58:5060 listen=tcp:172.20.120.58:5060
use_dns_cache=on # use internal DNS cache use_dns_failover=on # depends on internal DNS cache dns_srv_loadbalancing=on dns_try_naptr=on dns_retr_time=1 # seconds before retrying a DNS request dns_retr_no=3 # number of DNS retransmissions dns_naptr_ignore_rfc=yes # ignore target NAPTR priority dns_tcp_pref=30 # TCP has second-highest priority dns_udp_pref=10 # use UDP with least priority tcp_connection_lifetime=3605 # set higher than registration expires
#dont' restore modparam("uac","restore_mode","none") modparam("uac","restore_dlg",0)
## UAC REGISTER #!ifdef WITH_UAC_REGISTER modparam("uac", "reg_contact_addr", "CFG_PROD_IP") modparam("uac", "reg_timer_interval", 10) modparam("uac", "reg_retry_interval", 10) modparam("uac", "reg_db_url", DBURL) modparam("uac", "restore_mode", "none") modparam("uac", "auth_username_avp", "$avp(AVP_AUTH_USERNAME)") modparam("uac", "auth_password_avp", "$avp(AVP_AUTH_PASSWORD)") modparam("uac", "auth_realm_avp", "$avp(AVP_AUTH_REALM)") #!endif
ip a l 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: ens192: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 00:50:56:b5:c1:48 brd ff:ff:ff:ff:ff:ff inet 172.20.120.53/24 brd 172.20.120.255 scope global ens192 valid_lft forever preferred_lft forever inet 2xx.xx.xx.xx/29 scope global ens192 valid_lft forever preferred_lft forever inet 172.20.120.56/24 scope global secondary ens192 valid_lft forever preferred_lft forever inet 172.20.120.57/24 scope global secondary ens192 valid_lft forever preferred_lft forever inet 172.20.120.58/24 scope global secondary ens192 valid_lft forever preferred_lft forever inet 172.20.120.55/24 brd 172.20.120.255 scope global secondary ens192 valid_lft forever preferred_lft forever inet6 fe80::250:56ff:feb5:c148/64 scope link valid_lft forever preferred_lft forever
default via 172.20.120.253 dev ens192 172.20.120.0/24 dev ens192 proto kernel scope link src 172.20.120.53 2xx.xx.xx.xx/29 dev ens192 proto kernel scope link src 2xx.xx.xx.xx
-- Kind Regards Mit freundlichen Grüßen *Karsten Horsmann*
Hello, does it happen for both UDP and TCP? Or only for TCP is the private interface used? Normally should work no matter the transport, try to force only ip with force_send_sock("x.y.z.w"). I assume that the IP routing rules allow traffic from private IP to public addresses. Cheers, Daniel On Fri, Jun 21, 2019 at 5:49 PM Karsten Horsmann <khorsmann@gmail.com> wrote:
Hi List,
after reading the corebook in the wiki and some issue reports (1), I think it's not possible to force the outgoing ip for uac.so registration.
I saw traffic with 172.20.120.53:45689 - - - > reg.sip-trunk.telekom.de
So that's random highport generated traffic tcp traffic on the first interface ip.
AFAIK this behavior could not change, right?
(1) https://github.com/kamailio/kamailio/issues/1532
Karsten Horsmann <khorsmann@gmail.com> schrieb am Fr., 21. Juni 2019, 11:44:
Hi List,
I try to register to Deutsche Telekom and there product Deutschland Lan siptrunk.
Thats works find but i see an intressting behaviour on selecting the right outgoing interface. Kamailio is sending out with tcp the REQUEST via first private ip configured on that server (172.20.120.53). There is no listen directive for that.
I forced NAPTR to use tcp or udp and i assume that kamailio got the right dns answers.
On the list i read also that i can use force_send_socket to force the outgoing request.
Now my idea - hey i use the $rP for the outgoing to select the right outgoing listen directive. $rP - reference to transport protocol of R-URI But to my surprise the logfile told me thats "UDP" - it sends out via TCP (thats okay).
Whats an good transport selector variable from kamailio that works?
event_route[tm:local-request] { if(!is_method("OPTIONS")) { xlog("L_INFO", "[tm:local-request] request [$rm] from [$fu] to [$ru] [$rP]\n"); } }
INFO: <script>: [tm:local-request] request [REGISTER] from [ sip:+49XXXXXXXX@sip-trunk.telekom.de] to [sip:sip-trunk.telekom.de] [UDP]
listen=tcp:2xx.xx.xx.xx:5060 listen=udp:2xx.xx.xx.xx:5060 listen=tls:2xx.xx.xx.xx:5061 advertise CFG_EXT_NAME:5061
listen=udp:172.20.120.55:5060 listen=udp:172.20.120.56:5060 listen=udp:172.20.120.57:5060 listen=udp:172.20.120.58:5060 listen=tcp:172.20.120.58:5060
use_dns_cache=on # use internal DNS cache use_dns_failover=on # depends on internal DNS cache dns_srv_loadbalancing=on dns_try_naptr=on dns_retr_time=1 # seconds before retrying a DNS request dns_retr_no=3 # number of DNS retransmissions dns_naptr_ignore_rfc=yes # ignore target NAPTR priority dns_tcp_pref=30 # TCP has second-highest priority dns_udp_pref=10 # use UDP with least priority tcp_connection_lifetime=3605 # set higher than registration expires
#dont' restore modparam("uac","restore_mode","none") modparam("uac","restore_dlg",0)
## UAC REGISTER #!ifdef WITH_UAC_REGISTER modparam("uac", "reg_contact_addr", "CFG_PROD_IP") modparam("uac", "reg_timer_interval", 10) modparam("uac", "reg_retry_interval", 10) modparam("uac", "reg_db_url", DBURL) modparam("uac", "restore_mode", "none") modparam("uac", "auth_username_avp", "$avp(AVP_AUTH_USERNAME)") modparam("uac", "auth_password_avp", "$avp(AVP_AUTH_PASSWORD)") modparam("uac", "auth_realm_avp", "$avp(AVP_AUTH_REALM)") #!endif
ip a l 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: ens192: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 00:50:56:b5:c1:48 brd ff:ff:ff:ff:ff:ff inet 172.20.120.53/24 brd 172.20.120.255 scope global ens192 valid_lft forever preferred_lft forever inet 2xx.xx.xx.xx/29 scope global ens192 valid_lft forever preferred_lft forever inet 172.20.120.56/24 scope global secondary ens192 valid_lft forever preferred_lft forever inet 172.20.120.57/24 scope global secondary ens192 valid_lft forever preferred_lft forever inet 172.20.120.58/24 scope global secondary ens192 valid_lft forever preferred_lft forever inet 172.20.120.55/24 brd 172.20.120.255 scope global secondary ens192 valid_lft forever preferred_lft forever inet6 fe80::250:56ff:feb5:c148/64 scope link valid_lft forever preferred_lft forever
default via 172.20.120.253 dev ens192 172.20.120.0/24 dev ens192 proto kernel scope link src 172.20.120.53 2xx.xx.xx.xx/29 dev ens192 proto kernel scope link src 2xx.xx.xx.xx
-- Kind Regards Mit freundlichen Grüßen *Karsten Horsmann*
_______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Hello Daniel i verifed that can send tcp with that public ip (used nc for that). Hopefully the linux-networking is not the problem. I tried method $fs="212.xx.xx.xx"; and force_send_socket("212.xx.xx.xx"); Both versions (with and without transport=tcp param) but kamailio sends out via UDP. Any ideas? event_route[tm:local-request] { if(!is_method("OPTIONS")) { xlog("L_INFO", "[tm:local-request] request rm:[$rm] from fu:[$fu] to ru:[$ru] rP:[$rP] sut:[$sut] du:[$du] dP:[$dP] sas:[$sas]\n"); } if(is_method("REGISTER")) { xlog("its [$rm] [$ru] sas:[$sas]\n"); #$fs="$sas"; add_uri_param("transport=tcp"); # First try # $fs="212.xx.xx.xx"; # Second try # force_send_socket("212.xx.xx.xx"); } } tcpdump to see TCP or UDP outgoing: 212.xx.xx.xx.sip > 217.0.15.67.sip: [bad udp cksum 0xe921 -> 0x39df!] SIP, length: 459 REGISTER sip:sip-trunk.telekom.de;transport=tcp SIP/2.0 Via: SIP/2.0/UDP 212.xx.xx.xx;branch=z9hG4bKa4e7.2adf59a7000000000000000000000000.0;i=0 To: <sip:+49xxxxxx0@sip-trunk.telekom.de> From: <sip:+49xxxxxx@sip-trunk.telekom.de
;tag=4f1676d5afd8e4fcf22b77a7b449c44f-8d04 CSeq: 10 REGISTER Call-ID: 17110ff874fd4810-19875@212.xx.xx.xx Max-Forwards: 70 Content-Length: 0 User-Agent: SBC-OS Contact: <sip:49xxxxxx@xx.xx.xx.xx> Expires: 360
<script>: [tm:local-request] request rm:[REGISTER] from fu:[ sip:+49xxxxxx@sip-trunk.telekom.de] to ru:[sip:sip-trunk.telekom.de] rP:[UDP] sut:[sip:212.xx.xx.xx:5060;transport=tcp] du:[sip: reg.sip-trunk.telekom.de] dP:[UDP] sas:[tcp:212.xx.xx.xx:5060] <script>: its [REGISTER] [sip:sip-trunk.telekom.de] sas:[tcp:212.xx.xx.xx:5060] Cheers Karsten Am Mi., 26. Juni 2019 um 10:15 Uhr schrieb Daniel-Constantin Mierla < miconda@gmail.com>:
Hello,
does it happen for both UDP and TCP? Or only for TCP is the private interface used? Normally should work no matter the transport, try to force only ip with force_send_sock("x.y.z.w").
I assume that the IP routing rules allow traffic from private IP to public addresses.
Cheers, Daniel
On Fri, Jun 21, 2019 at 5:49 PM Karsten Horsmann <khorsmann@gmail.com> wrote:
Hi List,
after reading the corebook in the wiki and some issue reports (1), I think it's not possible to force the outgoing ip for uac.so registration.
I saw traffic with 172.20.120.53:45689 - - - > reg.sip-trunk.telekom.de
So that's random highport generated traffic tcp traffic on the first interface ip.
AFAIK this behavior could not change, right?
(1) https://github.com/kamailio/kamailio/issues/1532
Karsten Horsmann <khorsmann@gmail.com> schrieb am Fr., 21. Juni 2019, 11:44:
Hi List,
I try to register to Deutsche Telekom and there product Deutschland Lan siptrunk.
Thats works find but i see an intressting behaviour on selecting the right outgoing interface. Kamailio is sending out with tcp the REQUEST via first private ip configured on that server (172.20.120.53). There is no listen directive for that.
I forced NAPTR to use tcp or udp and i assume that kamailio got the right dns answers.
On the list i read also that i can use force_send_socket to force the outgoing request.
Now my idea - hey i use the $rP for the outgoing to select the right outgoing listen directive. $rP - reference to transport protocol of R-URI But to my surprise the logfile told me thats "UDP" - it sends out via TCP (thats okay).
Whats an good transport selector variable from kamailio that works?
event_route[tm:local-request] { if(!is_method("OPTIONS")) { xlog("L_INFO", "[tm:local-request] request [$rm] from [$fu] to [$ru] [$rP]\n"); } }
INFO: <script>: [tm:local-request] request [REGISTER] from [ sip:+49XXXXXXXX@sip-trunk.telekom.de] to [sip:sip-trunk.telekom.de] [UDP]
listen=tcp:2xx.xx.xx.xx:5060 listen=udp:2xx.xx.xx.xx:5060 listen=tls:2xx.xx.xx.xx:5061 advertise CFG_EXT_NAME:5061
listen=udp:172.20.120.55:5060 listen=udp:172.20.120.56:5060 listen=udp:172.20.120.57:5060 listen=udp:172.20.120.58:5060 listen=tcp:172.20.120.58:5060
use_dns_cache=on # use internal DNS cache use_dns_failover=on # depends on internal DNS cache dns_srv_loadbalancing=on dns_try_naptr=on dns_retr_time=1 # seconds before retrying a DNS request dns_retr_no=3 # number of DNS retransmissions dns_naptr_ignore_rfc=yes # ignore target NAPTR priority dns_tcp_pref=30 # TCP has second-highest priority dns_udp_pref=10 # use UDP with least priority tcp_connection_lifetime=3605 # set higher than registration expires
#dont' restore modparam("uac","restore_mode","none") modparam("uac","restore_dlg",0)
## UAC REGISTER #!ifdef WITH_UAC_REGISTER modparam("uac", "reg_contact_addr", "CFG_PROD_IP") modparam("uac", "reg_timer_interval", 10) modparam("uac", "reg_retry_interval", 10) modparam("uac", "reg_db_url", DBURL) modparam("uac", "restore_mode", "none") modparam("uac", "auth_username_avp", "$avp(AVP_AUTH_USERNAME)") modparam("uac", "auth_password_avp", "$avp(AVP_AUTH_PASSWORD)") modparam("uac", "auth_realm_avp", "$avp(AVP_AUTH_REALM)") #!endif
ip a l 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: ens192: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 00:50:56:b5:c1:48 brd ff:ff:ff:ff:ff:ff inet 172.20.120.53/24 brd 172.20.120.255 scope global ens192 valid_lft forever preferred_lft forever inet 2xx.xx.xx.xx/29 scope global ens192 valid_lft forever preferred_lft forever inet 172.20.120.56/24 scope global secondary ens192 valid_lft forever preferred_lft forever inet 172.20.120.57/24 scope global secondary ens192 valid_lft forever preferred_lft forever inet 172.20.120.58/24 scope global secondary ens192 valid_lft forever preferred_lft forever inet 172.20.120.55/24 brd 172.20.120.255 scope global secondary ens192 valid_lft forever preferred_lft forever inet6 fe80::250:56ff:feb5:c148/64 scope link valid_lft forever preferred_lft forever
default via 172.20.120.253 dev ens192 172.20.120.0/24 dev ens192 proto kernel scope link src 172.20.120.53 2xx.xx.xx.xx/29 dev ens192 proto kernel scope link src 2xx.xx.xx.xx
-- Kind Regards Mit freundlichen Grüßen *Karsten Horsmann*
_______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda _______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Mit freundlichen Grüßen *Karsten Horsmann*
Hi List, Hi Daniel, any one here that can imagine why force sendsocket generates an udp packet if the target accept only tcp? And without fs it generates an tcp packet. For uac registrations outbound? In my lab it's working without force send socket, cos the Paket is generated with the first private ip that the linux server had configured (and where the default route is reachable). Network setup is like that : Firewall (routes public ip to Kamailio via an privat IP of Kamailio box) - - > Kamailio server (in DMZ). And back of course. All other szencarios (sip traffic proxy acting) works like a charm. Thanks Kind regards Karsten Horsmann <khorsmann@gmail.com> schrieb am Mi., 26. Juni 2019, 14:50:
Hello Daniel
i verifed that can send tcp with that public ip (used nc for that). Hopefully the linux-networking is not the problem.
I tried method $fs="212.xx.xx.xx"; and force_send_socket("212.xx.xx.xx"); Both versions (with and without transport=tcp param) but kamailio sends out via UDP.
Any ideas?
event_route[tm:local-request] { if(!is_method("OPTIONS")) { xlog("L_INFO", "[tm:local-request] request rm:[$rm] from fu:[$fu] to ru:[$ru] rP:[$rP] sut:[$sut] du:[$du] dP:[$dP] sas:[$sas]\n"); } if(is_method("REGISTER")) { xlog("its [$rm] [$ru] sas:[$sas]\n");
#$fs="$sas"; add_uri_param("transport=tcp"); # First try # $fs="212.xx.xx.xx"; # Second try # force_send_socket("212.xx.xx.xx"); } }
tcpdump to see TCP or UDP outgoing:
212.xx.xx.xx.sip > 217.0.15.67.sip: [bad udp cksum 0xe921 -> 0x39df!] SIP, length: 459 REGISTER sip:sip-trunk.telekom.de;transport=tcp SIP/2.0 Via: SIP/2.0/UDP 212.xx.xx.xx;branch=z9hG4bKa4e7.2adf59a7000000000000000000000000.0;i=0 To: <sip:+49xxxxxx0@sip-trunk.telekom.de> From: <sip:+49xxxxxx@sip-trunk.telekom.de
;tag=4f1676d5afd8e4fcf22b77a7b449c44f-8d04 CSeq: 10 REGISTER Call-ID: 17110ff874fd4810-19875@212.xx.xx.xx Max-Forwards: 70 Content-Length: 0 User-Agent: SBC-OS Contact: <sip:49xxxxxx@xx.xx.xx.xx> Expires: 360
<script>: [tm:local-request] request rm:[REGISTER] from fu:[ sip:+49xxxxxx@sip-trunk.telekom.de] to ru:[sip:sip-trunk.telekom.de] rP:[UDP] sut:[sip:212.xx.xx.xx:5060;transport=tcp] du:[sip: reg.sip-trunk.telekom.de] dP:[UDP] sas:[tcp:212.xx.xx.xx:5060] <script>: its [REGISTER] [sip:sip-trunk.telekom.de] sas:[tcp:212.xx.xx.xx:5060]
Cheers Karsten
Am Mi., 26. Juni 2019 um 10:15 Uhr schrieb Daniel-Constantin Mierla < miconda@gmail.com>:
Hello,
does it happen for both UDP and TCP? Or only for TCP is the private interface used? Normally should work no matter the transport, try to force only ip with force_send_sock("x.y.z.w").
I assume that the IP routing rules allow traffic from private IP to public addresses.
Cheers, Daniel
On Fri, Jun 21, 2019 at 5:49 PM Karsten Horsmann <khorsmann@gmail.com> wrote:
Hi List,
after reading the corebook in the wiki and some issue reports (1), I think it's not possible to force the outgoing ip for uac.so registration.
I saw traffic with 172.20.120.53:45689 - - - > reg.sip-trunk.telekom.de
So that's random highport generated traffic tcp traffic on the first interface ip.
AFAIK this behavior could not change, right?
(1) https://github.com/kamailio/kamailio/issues/1532
Karsten Horsmann <khorsmann@gmail.com> schrieb am Fr., 21. Juni 2019, 11:44:
Hi List,
I try to register to Deutsche Telekom and there product Deutschland Lan siptrunk.
Thats works find but i see an intressting behaviour on selecting the right outgoing interface. Kamailio is sending out with tcp the REQUEST via first private ip configured on that server (172.20.120.53). There is no listen directive for that.
I forced NAPTR to use tcp or udp and i assume that kamailio got the right dns answers.
On the list i read also that i can use force_send_socket to force the outgoing request.
Now my idea - hey i use the $rP for the outgoing to select the right outgoing listen directive. $rP - reference to transport protocol of R-URI But to my surprise the logfile told me thats "UDP" - it sends out via TCP (thats okay).
Whats an good transport selector variable from kamailio that works?
event_route[tm:local-request] { if(!is_method("OPTIONS")) { xlog("L_INFO", "[tm:local-request] request [$rm] from [$fu] to [$ru] [$rP]\n"); } }
INFO: <script>: [tm:local-request] request [REGISTER] from [ sip:+49XXXXXXXX@sip-trunk.telekom.de] to [sip:sip-trunk.telekom.de] [UDP]
listen=tcp:2xx.xx.xx.xx:5060 listen=udp:2xx.xx.xx.xx:5060 listen=tls:2xx.xx.xx.xx:5061 advertise CFG_EXT_NAME:5061
listen=udp:172.20.120.55:5060 listen=udp:172.20.120.56:5060 listen=udp:172.20.120.57:5060 listen=udp:172.20.120.58:5060 listen=tcp:172.20.120.58:5060
use_dns_cache=on # use internal DNS cache use_dns_failover=on # depends on internal DNS cache dns_srv_loadbalancing=on dns_try_naptr=on dns_retr_time=1 # seconds before retrying a DNS request dns_retr_no=3 # number of DNS retransmissions dns_naptr_ignore_rfc=yes # ignore target NAPTR priority dns_tcp_pref=30 # TCP has second-highest priority dns_udp_pref=10 # use UDP with least priority tcp_connection_lifetime=3605 # set higher than registration expires
#dont' restore modparam("uac","restore_mode","none") modparam("uac","restore_dlg",0)
## UAC REGISTER #!ifdef WITH_UAC_REGISTER modparam("uac", "reg_contact_addr", "CFG_PROD_IP") modparam("uac", "reg_timer_interval", 10) modparam("uac", "reg_retry_interval", 10) modparam("uac", "reg_db_url", DBURL) modparam("uac", "restore_mode", "none") modparam("uac", "auth_username_avp", "$avp(AVP_AUTH_USERNAME)") modparam("uac", "auth_password_avp", "$avp(AVP_AUTH_PASSWORD)") modparam("uac", "auth_realm_avp", "$avp(AVP_AUTH_REALM)") #!endif
ip a l 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: ens192: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 00:50:56:b5:c1:48 brd ff:ff:ff:ff:ff:ff inet 172.20.120.53/24 brd 172.20.120.255 scope global ens192 valid_lft forever preferred_lft forever inet 2xx.xx.xx.xx/29 scope global ens192 valid_lft forever preferred_lft forever inet 172.20.120.56/24 scope global secondary ens192 valid_lft forever preferred_lft forever inet 172.20.120.57/24 scope global secondary ens192 valid_lft forever preferred_lft forever inet 172.20.120.58/24 scope global secondary ens192 valid_lft forever preferred_lft forever inet 172.20.120.55/24 brd 172.20.120.255 scope global secondary ens192 valid_lft forever preferred_lft forever inet6 fe80::250:56ff:feb5:c148/64 scope link valid_lft forever preferred_lft forever
default via 172.20.120.253 dev ens192 172.20.120.0/24 dev ens192 proto kernel scope link src 172.20.120.53 2xx.xx.xx.xx/29 dev ens192 proto kernel scope link src 2xx.xx.xx.xx
-- Kind Regards Mit freundlichen Grüßen *Karsten Horsmann*
_______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda _______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Mit freundlichen Grüßen *Karsten Horsmann*
On Wed, Jul 03, 2019 at 06:38:28PM +0200, Karsten Horsmann wrote:
any one here that can imagine why force sendsocket generates an udp packet if the target accept only tcp? And without fs it generates an tcp packet. For uac registrations outbound?
Reading the cookbook documentation of force_send_socket raises questions: Force to send the message from the specified socket (it _must_ be one of the sockets specified with the listen directive). If the protocol doesn't match (e.g. UDP message forced to a TCP socket) the closest socket of the same protocol is used. It relates to the listen directive, but if you are listening on a TCP port/socket you can't use that port/socket to create new outbound connections (to the best of my knowledge). You already tried $fs but without proto and port: https://www.kamailio.org/wiki/cookbooks/5.2.x/pseudovariables#fs_-_forced_so... proto is taken from $du if missing and I guess port is 5060 if missing. So if you are listening on 5060 tcp that can't be used for the outbound message, 5060 from udp is the closed match perhaps.
Actually you can force the TCP socket (e.g. sending from the same socket you are listening on) if the kernel has support for SO_REUSEPORT (linux > 3.9, FreeBSD, OSX) and you enable tcp_reuse_port in kamailio configuration ( https://www.kamailio.org/wiki/cookbooks/5.2.x/core#tcp_reuse_port). Best, Federico On Thu, Jul 4, 2019 at 10:27 AM Daniel Tryba <d.tryba@pocos.nl> wrote:
On Wed, Jul 03, 2019 at 06:38:28PM +0200, Karsten Horsmann wrote:
any one here that can imagine why force sendsocket generates an udp packet if the target accept only tcp? And without fs it generates an tcp packet. For uac registrations outbound?
Reading the cookbook documentation of force_send_socket raises questions: Force to send the message from the specified socket (it _must_ be one of the sockets specified with the listen directive). If the protocol doesn't match (e.g. UDP message forced to a TCP socket) the closest socket of the same protocol is used.
It relates to the listen directive, but if you are listening on a TCP port/socket you can't use that port/socket to create new outbound connections (to the best of my knowledge).
You already tried $fs but without proto and port:
https://www.kamailio.org/wiki/cookbooks/5.2.x/pseudovariables#fs_-_forced_so... proto is taken from $du if missing and I guess port is 5060 if missing. So if you are listening on 5060 tcp that can't be used for the outbound message, 5060 from udp is the closed match perhaps.
_______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Hi Frederico and Daniel. Today i found also the "tcp_reuse_port" documentation. Thanks Federico for the hint. With that paramenter to yes - i have still the issue that kamailio generates on force_send_socket or $fs (which is the same IMHO at the end) generates UDP. It forced the right IP but the transport is wrong. Without tcp_reuse_port it was the same stuff. I also tried a new listen param like "listen tcp:212.zz.xx.ab:8000" and point it to that direction. $fs and force_send_socket seems to be working with ip in that case. At the bottom I xlogged the du prameter. It feels like an special special corner case with naptr overwrite, uac and empty du tcp. $fs="212.zz.xx.ab" 13:07:35.839094 IP (tos 0x10, ttl 64, id 62416, offset 0, flags [none], proto UDP (17), length 472) 212.zz.xx.ab.sip > 217.0.26.67.sip: [bad udp cksum 0x9796 -> 0x68cb!] SIP, length: 444 REGISTER sip:sip-trunk.telekom.de SIP/2.0 Via: SIP/2.0/UDP 212.zz.xx.ab;branch=z9hG4bKc689.5afe94c5000000000000000000000000.0;i=0 To: <sip:+49xxxxxxxx@sip-trunk.telekom.de> From: <sip:+49xxxxxxxx@sip-trunk.telekom.de
;tag=0e37b8f111de3a41f982d1e82cae2fe3-b388 CSeq: 10 REGISTER Call-ID: 547d384144e9b23e-7166@212.zz.xx.ab Max-Forwards: 70 Content-Length: 0 User-Agent: SBC-OS Contact: <sip:49xxxxxxxx@212.zz.xx.ab> Expires: 360
Jul 4 13:10:01 siptrunk1 /usr/sbin/kamailio[9380]: INFO: <script>: [tm:local-request] request rm:[REGISTER] from fu:[ sip:+49xxxxxxxx@sip-trunk.telekom.de] to ru:[sip:sip-trunk.telekom.de] rP:[UDP] sut:[sip:212.zz.xx.ab:5060;transport=tcp] du:[sip: reg.sip-trunk.telekom.de] dP:[UDP] Jul 4 13:10:01 siptrunk1 /usr/sbin/kamailio[9380]: ERROR: <script>: its [REGISTER] [sip:sip-trunk.telekom.de] Jul 4 13:10:11 siptrunk1 /usr/sbin/kamailio[9380]: INFO: <script>: [tm:local-request] request rm:[REGISTER] from fu:[ sip:+49xxxxxxxx@sip-trunk.telekom.de] to ru:[sip:sip-trunk.telekom.de] rP:[UDP] sut:[sip:212.zz.xx.ab:5060;transport=tcp] du:[sip: reg.sip-trunk.telekom.de] dP:[UDP] Am Do., 4. Juli 2019 um 10:50 Uhr schrieb Federico Cabiddu < federico.cabiddu@gmail.com>:
Actually you can force the TCP socket (e.g. sending from the same socket you are listening on) if the kernel has support for SO_REUSEPORT (linux > 3.9, FreeBSD, OSX) and you enable tcp_reuse_port in kamailio configuration ( https://www.kamailio.org/wiki/cookbooks/5.2.x/core#tcp_reuse_port).
Best,
Federico
On Thu, Jul 4, 2019 at 10:27 AM Daniel Tryba <d.tryba@pocos.nl> wrote:
On Wed, Jul 03, 2019 at 06:38:28PM +0200, Karsten Horsmann wrote:
any one here that can imagine why force sendsocket generates an udp packet if the target accept only tcp? And without fs it generates an tcp packet. For uac registrations outbound?
Reading the cookbook documentation of force_send_socket raises questions: Force to send the message from the specified socket (it _must_ be one of the sockets specified with the listen directive). If the protocol doesn't match (e.g. UDP message forced to a TCP socket) the closest socket of the same protocol is used.
It relates to the listen directive, but if you are listening on a TCP port/socket you can't use that port/socket to create new outbound connections (to the best of my knowledge).
You already tried $fs but without proto and port:
https://www.kamailio.org/wiki/cookbooks/5.2.x/pseudovariables#fs_-_forced_so... proto is taken from $du if missing and I guess port is 5060 if missing. So if you are listening on 5060 tcp that can't be used for the outbound message, 5060 from udp is the closed match perhaps.
_______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org 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
-- Mit freundlichen Grüßen *Karsten Horsmann*
Hi Mailinglist, for my future me and anybody that had the same issue, the new uac parameter default_socket + tcp_reuse_port fixed the issue for me. https://github.com/kamailio/kamailio/commit/27b6f0aba06796f0c52e32fad809d378... Thanks to Henning. Cheers Karsten Horsmann Karsten Horsmann <khorsmann@gmail.com> schrieb am Do., 4. Juli 2019, 15:58:
Hi Frederico and Daniel.
Today i found also the "tcp_reuse_port" documentation. Thanks Federico for the hint. With that paramenter to yes - i have still the issue that kamailio generates on force_send_socket or $fs (which is the same IMHO at the end) generates UDP. It forced the right IP but the transport is wrong. Without tcp_reuse_port it was the same stuff.
I also tried a new listen param like "listen tcp:212.zz.xx.ab:8000" and point it to that direction. $fs and force_send_socket seems to be working with ip in that case. At the bottom I xlogged the du prameter.
It feels like an special special corner case with naptr overwrite, uac and empty du tcp.
$fs="212.zz.xx.ab"
13:07:35.839094 IP (tos 0x10, ttl 64, id 62416, offset 0, flags [none], proto UDP (17), length 472) 212.zz.xx.ab.sip > 217.0.26.67.sip: [bad udp cksum 0x9796 -> 0x68cb!] SIP, length: 444 REGISTER sip:sip-trunk.telekom.de SIP/2.0 Via: SIP/2.0/UDP 212.zz.xx.ab;branch=z9hG4bKc689.5afe94c5000000000000000000000000.0;i=0 To: <sip:+49xxxxxxxx@sip-trunk.telekom.de> From: <sip:+49xxxxxxxx@sip-trunk.telekom.de
;tag=0e37b8f111de3a41f982d1e82cae2fe3-b388 CSeq: 10 REGISTER Call-ID: 547d384144e9b23e-7166@212.zz.xx.ab Max-Forwards: 70 Content-Length: 0 User-Agent: SBC-OS Contact: <sip:49xxxxxxxx@212.zz.xx.ab> Expires: 360
Jul 4 13:10:01 siptrunk1 /usr/sbin/kamailio[9380]: INFO: <script>: [tm:local-request] request rm:[REGISTER] from fu:[ sip:+49xxxxxxxx@sip-trunk.telekom.de] to ru:[sip:sip-trunk.telekom.de] rP:[UDP] sut:[sip:212.zz.xx.ab:5060;transport=tcp] du:[sip: reg.sip-trunk.telekom.de] dP:[UDP] Jul 4 13:10:01 siptrunk1 /usr/sbin/kamailio[9380]: ERROR: <script>: its [REGISTER] [sip:sip-trunk.telekom.de] Jul 4 13:10:11 siptrunk1 /usr/sbin/kamailio[9380]: INFO: <script>: [tm:local-request] request rm:[REGISTER] from fu:[ sip:+49xxxxxxxx@sip-trunk.telekom.de] to ru:[sip:sip-trunk.telekom.de] rP:[UDP] sut:[sip:212.zz.xx.ab:5060;transport=tcp] du:[sip: reg.sip-trunk.telekom.de] dP:[UDP]
Am Do., 4. Juli 2019 um 10:50 Uhr schrieb Federico Cabiddu < federico.cabiddu@gmail.com>:
Actually you can force the TCP socket (e.g. sending from the same socket you are listening on) if the kernel has support for SO_REUSEPORT (linux > 3.9, FreeBSD, OSX) and you enable tcp_reuse_port in kamailio configuration ( https://www.kamailio.org/wiki/cookbooks/5.2.x/core#tcp_reuse_port).
Best,
Federico
On Thu, Jul 4, 2019 at 10:27 AM Daniel Tryba <d.tryba@pocos.nl> wrote:
On Wed, Jul 03, 2019 at 06:38:28PM +0200, Karsten Horsmann wrote:
any one here that can imagine why force sendsocket generates an udp packet if the target accept only tcp? And without fs it generates an tcp packet. For uac registrations outbound?
Reading the cookbook documentation of force_send_socket raises questions: Force to send the message from the specified socket (it _must_ be one of the sockets specified with the listen directive). If the protocol doesn't match (e.g. UDP message forced to a TCP socket) the closest socket of the same protocol is used.
It relates to the listen directive, but if you are listening on a TCP port/socket you can't use that port/socket to create new outbound connections (to the best of my knowledge).
You already tried $fs but without proto and port:
https://www.kamailio.org/wiki/cookbooks/5.2.x/pseudovariables#fs_-_forced_so... proto is taken from $du if missing and I guess port is 5060 if missing. So if you are listening on 5060 tcp that can't be used for the outbound message, 5060 from udp is the closed match perhaps.
_______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org 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
-- Mit freundlichen Grüßen *Karsten Horsmann*
On Thu, Jul 04, 2019 at 10:48:02AM +0200, Federico Cabiddu wrote:
Actually you can force the TCP socket (e.g. sending from the same socket you are listening on) if the kernel has support for SO_REUSEPORT (linux > 3.9, FreeBSD, OSX) and you enable tcp_reuse_port in kamailio configuration ( https://www.kamailio.org/wiki/cookbooks/5.2.x/core#tcp_reuse_port).
Thanks for the info. Sounds very useful.
participants (4)
-
Daniel Tryba -
Daniel-Constantin Mierla -
Federico Cabiddu -
Karsten Horsmann