sr-users June 2019

sr-users@lists.kamailio.org

63 participants
92 discussions

Re-invite after RTPengine pacemaker switching?
by Жан Базаров 07 Nov '19

07 Nov '19

I need to send re-invite after pacemaker fails over on new rtpengine server. Because new rtpengine dont participate in DTLS handshake and i hear nothing, but silence. I think, may me its would be work. Do you have any idea on this issue?

3 5

kamailio as UAC and NAPTR / sendsocket question
by Karsten Horsmann 09 Aug '19

09 Aug '19

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*

4 9

100% CPU usage after NTP date update
by Benjamin Marty 07 Aug '19

07 Aug '19

Hello, I'm facing the same issue. Is there a solution for this in the meantime? Benjamin https://lists.kamailio.org/pipermail/sr-users/2015-November/090487.html

2 2

kamailio 4.4.4 fills IPv6 contact address when sending packet over IPv4
by Pali Rohár 24 Jul '19

24 Jul '19

Hi! I detected strange problem that sip.linphone.org refuse to accept presence information re-transmitted by kamailio 4.4.4 server. I debug this problem with tcpdump and I found out that problem is in kamailio which fills IPv6 address into UDP datagram and that datagram is sent via IPv4 socket to IPv4 address, to sip.linphone.org server. And sip.linphone.org server does not have IPv6 connectivity, so correctly return over IPv4 to sender just "400 Bad Contact Header" error. On my server is running kamailio 4.4.4 from Debian Stretch and I can 100% reproduce this problem against public sip.linphone.org server. My server has both IPv4 and IPv6 connectivity and kamailio is listening for both IPv4 and IPv6 connections. So why is kamailio sending IPv6 address over IPv4 and therefore makes it impossible to communicate with non-IPv6 enabled servers? Looks like a problem with choosing default/correct socket for Contact header. And how to fix this problem? Can you help me? I would like to have working interconnection with linphone servers. Just to note I'm seeing this problem only for presence information packets. Other requests, like INVITE or MESSAGE seems to work. Below is relevant tcpdump output. Some parts were replaced by {VAR}. PS: I'm not subscribed to list, so please CC my address when sending reply. Thank you! 17:22:58.121719 IP (tos 0x10, ttl 64, id 21629, offset 0, flags [none], proto UDP (17), length 1266) {MY_IPV4_ADDRESS}.5060 > 91.121.209.194.5060: [bad udp cksum 0xa099 -> 0x9825!] SIP, length: 1238 NOTIFY sip:{REMOTE_NAME}@{REMOTE_USER_IPV4_ADDRESS}:5060;registering_acc=sip_linphone_org SIP/2.0 Via: SIP/2.0/UDP {MY_IPV4_ADDRESS};branch=z9hG4bK2b55.88f93c20000000000000000000000000.0 To: <sip:{REMOTE_NAME}@sip.linphone.org>;tag=75559182 From: <sip:{MY_SIP_URI}>;tag=97d8e785fdf42bf9622a64c13c504961-2708 CSeq: 2 NOTIFY Call-ID: 26cf9d5c019af2dc3302b770887bcc2e@0:0:0:0:0:0:0:0 Route: <sip:91.121.209.194:5060;lr> Content-Length: 597 User-Agent: kamailio (4.4.4 (x86_64/linux)) Max-Forwards: 70 Event: presence Contact: <sip:{MY_IPV6_ADDRESS}:5060;transport=udp> Subscription-State: active;expires=3600 Content-Type: application/pidf+xml <?xml version="1.0" encoding="UTF-8"?> <presence xmlns="urn:ietf:params:xml:ns:pidf" xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model" xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid" entity="Pali <sip:{MY_SIP_URI}>"> <tuple id="sg89ae"> <status><basic>open</basic></status> <contact priority="0.8">Pali <sip:{MY_SIP_URI}></contact> </tuple> <tuple xmlns="urn:ietf:params:xml:ns:pidf" id="TA0C538B2"> <status> <basic>closed</basic> </status> <contact priority="1">sip:{MY_SIP_URI}</contact> <timestamp>2019-04-19T17:20:36+02:00</timestamp> </tuple> </presence> 17:22:58.151188 IP (tos 0x0, ttl 52, id 22949, offset 0, flags [none], proto UDP (17), length 373) 91.121.209.194.5060 > {MY_IPV4_ADDRESS}.5060: [udp sum ok] SIP, length: 345 SIP/2.0 400 Bad Contact Header Via: SIP/2.0/UDP {MY_IPV4_ADDRESS};branch=z9hG4bK2b55.88f93c20000000000000000000000000.0;rport=5060 From: <sip:{MY_SIP_URI}>;tag=97d8e785fdf42bf9622a64c13c504961-2708 To: <sip:{REMOTE_NAME}@sip.linphone.org>;tag=75559182 Call-ID: 26cf9d5c019af2dc3302b770887bcc2e@0:0:0:0:0:0:0:0 CSeq: 2 NOTIFY Content-Length: 0 -- Pali Rohár pali.rohar(a)gmail.com

4 10

UDP fragmentation issues
by Gerry | x164 15 Jul '19

15 Jul '19

Hi, I have setup Kamailio on Centos 7 as a proxy in front of Asterisk in the same datacenter, using the dispatcher module. I have noted that large INVITEs sent by Kamailio do not arrive at the Asterisk box. It seems the network is dropping fragmented UDP traffic. This does not happen however when I contact the Asterisk box directly from outside the datacenter. Then large INVITES are arriving are Asterisk. So the problem is either in Kamailio or in the datacenter. I have analysed the problem with ngrep and tcpdump/wireshark. In normal mode (udp4_raw=no setting) Kamailio is producing UDP packets above 1500 bytes and leaves all fragmentation to the operating system. Enabling raw udp in Kamailio and lowering the MTU in the server didnt help. I even disabled offloading of UDP fragmentation to the NIC to get to the bottom of this. However nothing helps. Only forcing TCP in the dispatcher works when having large INVITES going to Asterisk. In any case, it appears that there is no guarantee that fragmented UDP arrives at all. As far as I am aware, the recommendation is to use TCP if messages are bigger than 1400 bytes. If so, how can I force Kamailio to send messages over 1400 bytes only in TCP mode? Or is there some other way how to deal with this? Thanks for any hints. Gerry

3 3

DMQ: dmq_t_replicate()
by Lars Olsson 02 Jul '19

02 Jul '19

Hi, I am trying to replicate a REGISTER request between several nodes. When I am using dmq_t_replicate(), it ends the execution of the script. It this correct or I have missed anything? I can not find anything in the documentation of the DMQ module the says that it will end the script execution. Is it recommended to use the DMQ module or should I simply forward the request instead as described in https://medium.com/@tumalevich/kamailio-registration-replication-without-dm… Best Regards, Lars

2 3

question about reply route
by Iván Aponte 02 Jul '19

02 Jul '19

Hello, I have a question about record route and via headers. My scenario is the following: [asterisk] ---- [kam] -------- [trunk] 10.142.0.27 10.142.0.6 200.x.x.x I have an asterisk an a kamailio in a private ip network (10.142.0.0/24). Kamailio has the address 10.142.0.6 but is also natted 1:1 to a public ip (35.0.0.6). My problem is that when the invite are replied the asterisk replies to the external ip (35.0.0.6) instead of the internal ip (even though the kamailio replies goes through the internal network) . I tried adding a reply route to change the advertised address to no avail. any advice would be appreciated. this is my conf: LISTEN="listen=udp:0.0.0.0:5060 advertise 35.0.0.6:5060" disable_tcp=yes loadmodule "jsonrpcs.so" loadmodule "kex.so" loadmodule "corex.so" loadmodule "tm.so" loadmodule "tmx.so" loadmodule "sl.so" loadmodule "rr.so" loadmodule "pv.so" loadmodule "maxfwd.so" loadmodule "usrloc.so" loadmodule "textops.so" loadmodule "siputils.so" loadmodule "xlog.so" loadmodule "sanity.so" loadmodule "ctl.so" loadmodule "cfg_rpc.so" loadmodule "acc.so" loadmodule "counters.so" loadmodule "permissions.so" loadmodule "ipops.so" modparam("jsonrpcs", "pretty_format", 1) modparam("tm", "failure_reply_mode", 3) modparam("tm", "fr_timer", 30000) modparam("tm", "fr_inv_timer", 120000) modparam("rr", "enable_full_lr", 0) modparam("rr", "append_fromtag", 0) reply_route { xinfo("source $si"); if(!is_in_subnet($si, "10.0.0.0/8")) { set_advertised_address("10.142.0.6"); } else { xinfo("not in subnet"); } } request_route { # per request initial checks route(REQINIT); # CANCEL processing if (is_method("CANCEL")) { if (t_check_trans()) { route(RELAY); } exit; } # handle retransmissions if (!is_method("ACK")) { if(t_precheck_trans()) { t_check_trans(); exit; } t_check_trans(); } # handle requests within SIP dialogs route(WITHINDLG); ### only initial requests (no To tag) # authentication #route(AUTH); # record routing for dialog forming requests (in case they are routed) # - remove preloaded route headers remove_hf("Route"); if (is_method("INVITE|SUBSCRIBE")) { record_route(); } # dispatch requests to foreign domains route(SIPOUT); if ($rU==$null) { # request with no Username in RURI sl_send_reply("484","Address Incomplete"); exit; } } # Wrapper for relaying requests route[RELAY] { if (!t_relay()) { sl_reply_error(); } exit; } # Per SIP request initial checks route[REQINIT] { if($ua =~ "friendly-scanner|sipcli|VaxSIPUserAgent") { # silent drop for scanners - uncomment next line if want to reply # sl_send_reply("200", "OK"); exit; } if (!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); exit; } if(is_method("OPTIONS") && uri==myself && $rU==$null) { sl_send_reply("200","Keepalive"); exit; } if(!sanity_check("1511", "7")) { xlog("Malformed SIP message from $si:$sp\n"); exit; } } # Handle requests within SIP dialogs route[WITHINDLG] { if (!has_totag()) return; # sequential request withing a dialog should # take the path determined by record-routing if (loose_route()) { if ( is_method("NOTIFY") ) { record_route(); } route(RELAY); exit; } if (is_method("SUBSCRIBE") && uri == myself) { send_reply("405", "Method Not Allowed"); exit; } if ( is_method("ACK") ) { if ( t_check_trans() ) { # no loose-route, but stateful ACK; # must be an ACK after a 487 # or e.g. 404 from upstream server route(RELAY); exit; } else { # ACK without matching transaction ... ignore and discard exit; } } sl_send_reply("404","Not here"); exit; } route[SIPOUT] { if (uri==myself) return; append_hf("P-hint: outbound\r\n"); route(RELAY); exit; } -- Iván Aponte Office: +58(212)9923193 Mobile: +58(412)2774713

3 3

install mongoDB module with kamailio-cli doker image
by Gaurav Bmotra 01 Jul '19

01 Jul '19

hi i wan to install mongodb module in kamailio/kamailio-ci image pl help me thnaks -- *Regards:* Gaurav Kumar

2 3

Late offer ACKs not passing through branch_route
by Bandiera, Enrico 01 Jul '19

01 Jul '19

Hi, I'm encountering an issue when relaying late offer ACKs, before relaying I set the branch_route with t_on_branch() but kamailio never enters that route after calling t_relay I'm keeping the rtpengine module calls inside branch_routes to avoid issues when re-routing in failure routes I suppose it's something related to ACK packets but I'm not sure what the issue is. Any hints? Thanks, Enrico.

3 2

ATCF/ATGW functionality
by Maryam Baghdadi 01 Jul '19

01 Jul '19

Hello, Is it possible to add ATCF/ATGW functionality in kamailio as P-cscf ? I have IMS network with kamailio as P-cscf, icscf, scscf and FHoss . ATCF/ATGW is necessary for handovers between 2G/3G and LTE networks.

2 3

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

sr-users June 2019