sr-users May 2016

sr-users@lists.kamailio.org

86 participants
130 discussions

4.4: Kamailio crashes at start - sometimes
by Sebastian Damm 27 May '16

27 May '16

Hi, we have a machine running 16 Kamailio instances, and while upgrading to 4.4.1 (from 4.3.5), 8 of them wouldn't start. When downgrading to 4.3.5, they all start again. All of them have pretty identical configuration files, except IPs, ports and some code enabled or disabled via defines. After comparing a working and non-working configuration and adjusting setting by setting, we finally ended up with a working configuration. The difference is, that it won't start when a part of the code DOES NOT get included. If it gets included, it will start. This is the mentioned part of our main route: #!ifdef ENABLE_INV_RATELIMIT # Check for INVITE limit if (is_method("INVITE") && $au == $null && !($ua =~ "sipgate") ) { $var(invcount) = $shtcn(invcount=>%~$fU); xlog("L_INFO", "INVITE Requests from $fU in last 30 seconds: $var(invcount)\n"); if ($var(invcount) < 12) { $var(uniqcid) = $ci + $Ts + $ft; $var(tkey) = $fU + '-' + $(var(uniqcid){s.md5}{s.substr,0,10}); $sht(invcount=>$(var(tkey))) = 1; $var(uniqcid) = $null; $var(tkey) = $null; } if ($var(invcount) > 10) { if ($var(invcount) == 11 ) { xlog("L_NOTICE", "User $fU ($var(domain2use)) over ratelimit for new calls, rejecting.\n"); } # Enable this only after evaluating the impact! append_to_reply("Retry-After: 30\r\n"); sl_send_reply("503", "Call Rate Limit Exceeded"); exit; } } #!endif If we put this line at the top of the configuration file, everything works: #!define ENABLE_INV_RATELIMIT If we delete this line, startup does not work. It just sits in ps for one minute without forking, and then gets terminated. We enabled a bit of debugging, and this is apparently the error causing Kamailio to shutdown: May 25 14:50:15 kammel /usr/sbin/kamailio[24989]: DEBUG: <core> [sr_module.c:920]: init_mod_child(): rank 53: nathelper May 25 14:50:15 kammel /usr/sbin/kamailio[24987]: DEBUG: <core> [local_timer.c:61]: init_local_timer(): timer_list between 0x9f0428 and 0xa34428 May 25 14:50:15 kammel /usr/sbin/kamailio[24987]: DEBUG: <core> [io_wait.h:376]: io_watch_add(): DBG: io_watch_add(0x9f0240, 82, 1, (nil)), fd_no=0 May 25 14:50:15 kammel /usr/sbin/kamailio[24987]: ERROR: <core> [io_wait.h:459]: io_watch_add(): epoll_ctl failed: Bad file descriptor [9] May 25 14:50:15 kammel /usr/sbin/kamailio[24987]: CRITICAL: <core> [tcp_read.c:1747]: tcp_receive_loop(): failed to add tcp main socket to the fd list May 25 14:50:15 kammel /usr/sbin/kamailio[24987]: CRITICAL: <core> [tcp_read.c:1815]: tcp_receive_loop(): exiting... I have no idea, how this part of the code could lead to this error, but it is reproducable, that at least on this system setting or disabling this define fixes or breaks the startup. Does anybody have an idea, what's happening there? Best Regards, Sebastian

2 4

Multihomed kamailio - one IP for each account
by Attila Megyeri 27 May '16

27 May '16

Hi Folks, I am looking for a solution to do the following, basically an SBC-like solution. I have an internal asterisk system that should make outbound calls towards a provider, but that provider authenticates the customer based on IP address. And I have many such customers. The provider is not willing to make changes to his practice... Asterisk is bound to a single IP, so there is not much I can do. I was thinking about creating several outbound accounts for asterisk, and then a multi-homed Kamailio would do the following: If request comes from user1, Kamailio would send the request to the provider from IP1. If request comes from user2, Kamailio would send the request to the provider from IP2. And so on, for as many IPs as many customers I want to handle. Is there a more elegant way to do this? If not, how should I implement this? Thanks in advance, Attila

2 4

Kamailio Via: header issue
by Laura 27 May '16

27 May '16

Good morning list, I need to ask you a question about a problem we are fighting on our VoIP platform based on Kamailio 4.3.5. Our platform is made by more nodes over Europe countries, and we are encountering a problem with the size of the SIP package which, exceeds the physiological limit of about 1350 bytes. The real problem is caused from Via: Header (inside the SIP packet) which is added to each element of the system for transit on the call. >From what we have analyzed, the problem is not so much due to the number of entered Via: records but, by the fact that they contain a branch parameter extremely long. Here the call flow example from CARRIER A —> Kamailio1 —> Kamailio2 —> CARRIER B Extract from SIP message sent from CARRIER A to K1 INVITE sip:999912341234@192.168.158.42 SIP/2.0. Via: SIP/2.0/UDP 192.168.220.141:5060;branch=z9hG4bK49e4301c;rport. Extract from SIP message sent from K1 to K2 INVITE sip:999912341234@192.168.127.244 SIP/2.0. Record-Route: <sip:192.168.158.42;lr;did=194.a0f1;nat=yes>. Via: SIP/2.0/UDP 192.168.158.42;branch=z9hG4bK0635.7c1e97c2d5c01ea98e8d0e7fa23a3822.0. Via: SIP/2.0/UDP 192.168.158.42;branch=z9hG4bKsr-j4IPOlV7MGQKatycM.cuOBV4OBVLMGZfWxF-W.y6Mx1LgRWIC9gIgx4fzxj7MBP7MBVAOBF4M.1jmxuqC93X3heroEWvH9vsCFN43qd4zRj4Mlyf3l1LNSQLpx4uMx3A. Extract from SIP message sent from K2 to CARRIER B INVITE sip:999912341234@192.168.65.248 SIP/2.0. Record-Route: <sip:192.168.127.244;lr;did=194.5122;nat=yes>. Via: SIP/2.0/UDP 192.168.127.244;branch=z9hG4bK0635.f843472880b380acde3a33732975fde9.0. Via: SIP/2.0/UDP 192.168.127.244;branch=z9hG4bKsr-j4IPOlV7MGQKatycW.F7MBj4OBFuzGZ4MB1LNSQLpx4uMx3AzuaVHRaYpB1JNEt736cQkBIvalaJmly6Mlj7W6Mfg.qw3leqWRMAMRKrz.rIzSPAg.pE3.Vl3.MZMBV7My**. Via: SIP/2.0/UDP 192.168.127.244;branch=z9hG4bKsr-j4IPOlV7MGQKatycW.F7MBj4OBFuzGZ4MB1JNEt736cQkBIvalaJmwWLORv4mK0Hot3w.jpam6t4kRWWOEWu.4eRWFQGKqfWauYEKwrSOKN7k.gWkxtMgue9mjMsg4IhkxaEkhrbW4uGjxpWPIg0.4eSWF47MRY1kUKfPlqlRxWvg9e5aKp6mxI6N4WS.BPlNRP4kIebWFudkR3loxtM.IWa.U0ZWUKWkxW0. Is there anyone here with the idea how to solve this problem ? Best regards

3 8

rtpproxy module question
by gmele 27 May '16

27 May '16

Hello, we are using an RTP Proxy from rtpproxy.org as media relay to establish communication between our mobile phones. Of course, we are using the kamailio rtpproxy module to modify the SDP payload and control the proxy. In our Kamailio configuration, we have 1 kamailio configured as Proxy and one kamailio configured as Registrar. So calls go through the Proxy and then to the Registrar who will update the SDP header and select an available rtp proxy. We have noticed that sometimes, the rtp udp flow between the phones isn't routed properly by the rtpproxies, ending in the communication drop (all the SIP nego is working well, and the SDP are correctly patched with the rtp proxy address and port). Analyzing the RTP proxy packets, we have found that the Kamailio registrar gives the Kamailio proxy ip address in the RTP proxy create session command, but keeps the original sdp port. command looks like this: Uc96,101 DC -PbO~Wnm <proxy_ip> <port from original sdp phone packet> PZU5OITCW;1 We are using rtpproxy_manage() without any flags. It seems to us that this ip and port are used as default forward route as long as the callee hasnt connected to the rtpproxy. *Is it correct? * If its true, Its seems to us that this cant work as we are mixing the proxy sip address with a udp port open on the phone ? *Is our analysis correct ?* Can we use some option in rtpproxy_manage to replace the proxy ip by the phone ip as seen in the via route ? Thx for your help Giovanni -- View this message in context: http://sip-router.1086192.n5.nabble.com/rtpproxy-module-question-tp148850.h… Sent from the Users mailing list archive at Nabble.com.

2 3

Kamailio not sending reply
by Jeremy Betts 26 May '16

26 May '16

Hello, I'm having an issue where kamailio is not sending the failure reply as I would expect when receiving calls from a certain provider. Kamailio sends the 403 response on calls from other providers. The big difference I see is that the "problem" provider is using compact headers. I am trying to force the 403 response to be sent for testing purposes but I just can't get it to reply to this one provider. I've included traces and configuration excerpts below. Any help is much appreciated! Problem Call (No Reply Sent): U 63.79.178.192:5060 -> 184.171.164.100:5060 INVITE sip:+19727289377@184.171.164.100;transport=UDP;user=phone SIP/2.0. v: SIP/2.0/UDP 63.79.178.192:5060;branch=z9hG4bK9a2b97bc805e6a3b73b43e3de4150da5.1d819013. Record-Route: <sip:63.79.178.192;lr>. f: <sip:+17143258018@199.173.94.144:5060;user=phone>;tag=-45026-41c7bce-729616d4-41c7bce. t: <sip:+19727289377@63.79.178.192:5060;user=phone>. i: b03a96e8905eadc713c441c7bcef439f1124b7ca791c2679c0-0086-5719. CSeq: 1 INVITE. Allow: ACK,BYE,CANCEL,INVITE,OPTIONS,INFO,SUBSCRIBE,REFER,NOTIFY,PRACK. v: SIP/2.0/UDP SCR9:5060;maddr=199.173.94.144;branch=z9hG4bK-41c7bce-f439f11-21b78f96;received=199.173.94.144. Max-Forwards: 27. m: <sip:199.173.94.144:5060;transport=UDP>. k: 100rel, resource-priority, replaces. c: application/sdp. l: 235. P-Asserted-Identity: <sip:+17143258018@63.79.178.192;user=phone>. Privacy: none. . v=0. o=PVG 1464277233580 1464277233580 IN IP4 199.173.68.106. s=-. p=+1 6135555555. c=IN IP4 199.173.68.106. t=0 0. m=audio 55380 RTP/AVP 18 0 8 101. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=ptime:20. a=fmtp:18 annexb=no. # U 63.79.178.192:5060 -> 184.171.164.100:5060 ACK sip:+19727289377@184.171.164.100;transport=UDP;user=phone SIP/2.0. v: SIP/2.0/UDP 63.79.178.192:5060;branch=z9hG4bK9a2b97bc805e6a3b73b43e3de4150da5.1d819013. f: <sip:+17143258018@199.173.94.144:5060;user=phone>;tag=-45026-41c7bce-729616d4-41c7bce. t: <sip:+19727289377@63.79.178.192:5060;user=phone>;tag=b1eb89aa72a4b2a406f6fb21bbd3e03f.1aac. i: b03a96e8905eadc713c441c7bcef439f1124b7ca791c2679c0-0086-5719. CSeq: 1 ACK. l: 0. Max-Forwards: 27. . Successful Call (Reply Sent): # U 64.136.173.31:5060 -> 184.171.164.100:5066 INVITE sip:7146466334@184.171.164.100:5066 SIP/2.0. Via: SIP/2.0/UDP 64.136.173.31:5060;branch=z9hG4bK1sansay3408006464rdb14345. Record-Route: <sip:sansay3408006464rdb14345@64.136.173.31:5060;lr;transport=udp>. To: <sip:7146466334@184.171.164.100>. From: <sip:17143258018@64.136.173.31>;tag=sansay3408006464rdb14345. Call-ID: 1089333243-0-3123809354(a)64.136.173.226. CSeq: 1 INVITE. Contact: <sip:17143258018@64.136.173.31:5060>. Supported: timer. Session-Expires: 1800;refresher=uac. Min-SE: 90. P-Asserted-Identity: <sip:17143258018@192.168.20.76>. Privacy: none. Expires: 120. Max-Forwards: 67. Content-Type: application/sdp. Content-Length: 274. . v=0. o=Sansay-VSXi 188 1 IN IP4 64.136.173.31. s=Session Controller. c=IN IP4 69.85.185.142. t=0 0. m=audio 37970 RTP/AVP 0 18 101. a=rtpmap:0 PCMU/8000. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=no. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=sendrecv. a=ptime:20. # U 184.171.164.100:5066 -> 64.136.173.31:5060 SIP/2.0 403 DID Lookup Failed. Via: SIP/2.0/UDP 64.136.173.31:5060;branch=z9hG4bK1sansay3408006464rdb14345. To: <sip:7146466334@184.171.164.100>;tag=b1eb89aa72a4b2a406f6fb21bbd3e03f.d2ec. From: <sip:17143258018@64.136.173.31>;tag=sansay3408006464rdb14345. Call-ID: 1089333243-0-3123809354(a)64.136.173.226. CSeq: 1 INVITE. Server: x-Freevoice SIP Proxy 4.21. Content-Length: 0. . # U 64.136.173.31:5060 -> 184.171.164.100:5066 ACK sip:7146466334@184.171.164.100:5066 SIP/2.0. Via: SIP/2.0/UDP 64.136.173.31:5060;branch=z9hG4bK1sansay3408006464rdb14345. To: <sip:7146466334@184.171.164.100>;tag=b1eb89aa72a4b2a406f6fb21bbd3e03f.d2ec. From: <sip:17143258018@64.136.173.31>;tag=sansay3408006464rdb14345. Call-ID: 1089333243-0-3123809354(a)64.136.173.226. CSeq: 1 ACK. Max-Forwards: 70. Content-Length: 0. Kamailio Config: request_route { # per request initial checks route(REQINIT); # NAT detection #route(NATDETECT); # handle requests within SIP dialogs route(WITHINDLG); ### only initial requests (no To tag) # CANCEL processing if (is_method("CANCEL")) { setflag(FLT_ACCFAILED); if (t_check_trans()) t_relay(); exit; } t_check_trans(); if(is_method("INVITE")||is_method("MESSAGE")){ route(ORIGINATE); #route(FROMAST); } route[ORIGINATE] { sl_send_reply("403", "DID Lookup Failed"); exit; } Jeremy Betts <https://www.youtube.com/user/FreevoiceLLC> <https://www.youtube.com/user/FreevoiceLLC>

2 2

webrtc tlsv1 alert access denied
by Arsen 26 May '16

26 May '16

Hi guys! I am trying to configure kamailio with WSS. We have trusted certificate installed SIP over TCP/TLS works fine. But when I try WSS I got error: ERROR: tls [tls_util.h:42]: tls_err_ret(): TLS read:error:14094419:SSL routines:SSL3_READ_BYTES:tlsv1 alert access denied ERROR: <core> [tcp_read.c:1303]: tcp_read_req(): ERROR: tcp_read_req: error reading Before above error it was 'bad certificate', so I have imported CA in the firefox and now I get these errors.. I have tried sipml5 and tryit.jssip.net same issue with both clients, also it seems I have these errors only when I use firefox, when I use chrome it even doesn't show me an error.. Any ideas? Thanks! -- Regards, Arsen.

2 3

SRV and dialog stickiness
by Alex Balashov 26 May '16

26 May '16

Hello, Sorry if this is a tired, worn question, but I've not dealt much with Kamailio's SRV support before: If a registrant has a contact binding whose domain component is subject to an SRV lookup with load-balanced or weighted entries, how does one solve the problem of ensuring that subsequent in-dialog requests go to the same host as the initial INVITE? Does Kamailio offer some facility for doing this? Is it somehow accommodated by SIP? -- Alex -- Alex Balashov | Principal | Evariste Systems LLC 1447 Peachtree Street NE, Suite 700 Atlanta, GA 30309 United States Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/

3 5

rtpengine and SAVPF
by Ján Füri 26 May '16

26 May '16

Hi all, Im struggling with incoming calls to webrtc clients. I am trying to change INVITE's SDP using rtpengine from RTP/AVP or RTP/SAVP to RTP/SAVPF towards my webrtc clients. This works well. But if I send INVITE with SDP that includes RTP/AVP and RTP/SAVP as well, rtpengine creates incorrect SDP. It includes twice m=audio RTP/SAVPF and my WebRTC client does not like this INVITE and forbiddeds it by 488 Not Acceptable Here. Example of my incorrect INVITE : Content-Type: application/sdp Content-Disposition: session Content-Length: 1393 v=0 o=SBC 1464238673 1464238674 IN IP4 <MyPublicIP> s=SBC c=IN IP4 <MyPublicIP> t=0 0 m=audio 30454 RTP/SAVPF 102 9 8 0 3 18 a=rtpmap:102 SILK/8000 a=fmtp:102 useinbandfec=1; usedtx=0 a=rtpmap:9 G722/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:3 GSM/8000 a=rtpmap:18 G729/8000 a=ptime:20 a=sendrecv a=rtcp:30455 a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:5X2wgU83bIwrwkHSymjnw48SiMGa1n+eIl50yr99 a=setup:actpass a=fingerprint:sha-1 11:76:2D:2A:F7:0D:5A:23:9D:F6:0C:E7:4C:DF:1E:CB:BF:5D:76:88 a=ice-ufrag:iglHZqry a=ice-pwd:eyVXbFNoviYYlu5uuRZlnixFwQ a=candidate:cE0FGbXWIfwj6OGD 1 UDP 2130706431 <MyPublicIP> 30454 typ host a=candidate:cE0FGbXWIfwj6OGD 2 UDP 2130706430 <MyPublicIP> 30455 typ host m=audio 30484 RTP/SAVPF 102 9 8 0 3 18 a=rtpmap:102 SILK/8000 a=fmtp:102 useinbandfec=1; usedtx=0 a=rtpmap:9 G722/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:3 GSM/8000 a=rtpmap:18 G729/8000 a=ptime:20 a=sendrecv a=rtcp:30485 a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:ozDJ3G/wmaYedQbcTafbhaTIt6raIJa6ugrLUC99 a=setup:actpass a=fingerprint:sha-1 11:76:2D:2A:F7:0D:5A:23:9D:F6:0C:E7:4C:DF:1E:CB:BF:5D:76:88 a=ice-ufrag:gM1viWqu a=ice-pwd:zdS4tP1Mj4hLTe6huBWYrhtI1s a=candidate:cE0FGbXWIfwj6OGD 1 UDP 2130706431 <MyPublicIP> 30484 typ host a=candidate:cE0FGbXWIfwj6OGD 2 UDP 2130706430 <MyPublicIP> 30485 typ host My setup : incoming call -> MediaServer (freeswitch) -> SIP & Websocket proxy (Kamailio + Rtpengine) -> webRTC clients Is there anybody who could help me with this issue or explain me how to remove the second line of m=audio RTP/SAVPF ? -- Jan

1 0

Sequential calls messes up presence with pua-dialog info
by Ali Pey 25 May '16

25 May '16

Hello, We are using pua-dialoginfo and presence modules for BLF. When the first call comes in or goes out, every thing works great; however, a second call to the same key/extension (e.g a call waiting which is not answered) would turn off the key even though the original call/dialog is still active. Has anyone had experienced such problem? How can I fix this? Any constructive suggestion would be appreciated. Regards, Ali Pey

4 5

nh_reload_rtpp not available
by david 25 May '16

25 May '16

dear all i'm using kamailio 4.4.1 and i'm not seeing nh_reload_rtpp as a fifo exported function i'm trying to setup the dburl for the rtpengine sets using db_text but when i do kamctl fifo which i see all the commands of the module except the reload_rtpp nh_enable_rtpp nh_show_rtpp nh_ping_rtpp nh_show_hash_total /usr/local/kamailio/sbin/kamctl fifo nh_reload_rtpp 500 command 'nh_reload_rtpp' not available these are the config lines i have for that #!define DBURLRTP "text:///var/log/rtpengine_conf" loadmodule "db_text.so" modparam("rtpengine", "db_url", DBURLRTP) modparam("rtpengine", "table_name", "rtpproxy") and the database is like root@test:/var/log/rtpengine_conf# ls rtpproxy version root@test:/var/log/rtpengine_conf# cat version table_name(str) table_version(int) rtpproxy:1 root@test:/var/log/rtpengine_conf# cat rtpproxy set_id(int) url(str) weight(int) disable(int) 1:udp\:x.x.x.x\:x:100:0 2:udp\:x.x.x.x\:x:100:0 is there something i missed here? do i must use mysql or postgres drivers for this? (i use a test machine to old to install a driver of those with kam 4.4 maybe?) best regards david

1 1

← Newer
1
2
3
4
5
6
7
8
...
13
Older →

2026

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 May 2016