November 2013 - sr-users

Some Help with Kamailio v4.0
by Tom Allen 30 Nov '13

30 Nov '13

I am spinning up my first instance of Kamailio and I can't seem to get it to start. I think my issue lies in the kamailio.cfg file, but I don't want to smash that entire file here, it is basically the default. I try to start and get this... root@kh1:/usr/local/etc/kamailio# /etc/init.d/kamailio debug start Starting Kamailio: loading modules under /usr/local/lib/kamailio/modules_k/:/usr/local/lib64/kamailio/modules/ Listening on udp: 127.0.0.1:5060 udp: xxx:5060 udp: 192.168.xxxx:5060 tcp: 127.0.0.1:5060 tcp: xxxx:5060 tcp: 192.168.xxx:5060 Aliases: tcp: kh1:5060 tcp: kh1.xxxx.com:5060 tcp: localhost:5060 udp: kh1:5060 udp: kh1.xxxx.com:5060 udp: localhost:5060 kamailio error, failed to start. I am running a fresh load of Debian .. Linux kh1 3.2.0-4-amd64 #1 SMP Debian 3.2.51-1 x86_64 GNU/Linux I am using a mysql backend. Nothing is in production. What else can I provide you to help me figure this out? Thank you. Respectfully, Tom Allen Virtual Technologies Group

2 3

kamailio 4.0.3 - contact header in ACK
by Adnan 29 Nov '13

29 Nov '13

Hi, We are migrating from our openser 1.4 to kamailio 4.0.3 and have run into a couple of issues. One of them is described below and we need to know if it is a known bug or not. Kamailio receives an INVITE from a gateway and finally responds with 200 OK. Then an ACK is generated by the gateway towards the Kamailio that some how does not get relayed to the next hop. The only special aspect here is that the ACK does not contain a Contact header. Is that something that could confuse kamailio and make it unable to relay? According to SIP RFC, a contact header in ACK is not a must have. Our case is the one where ACK is sent by the UAC after receiving a 200 OK final response. Everything else about the ACK looks OK e.g. ACK has a branch different from the the branch value in the UAC INVITE. Is it a a known bug in 4.0.3? In the configuration, we handle ACK as below: if (is_method("ACK")) { if (t_check_trans()) { t_relay(); exit; } else { exit; } Br Adnan

3 4

Dialog module columns not found in .c files
by Grant Bagdasarian 29 Nov '13

29 Nov '13

Hello, Using 4.0.4: I'm getting the following error (removed the values part of the query): 3(2931) ERROR: db_unixodbc [dbase.c:133]: db_unixodbc_submit_query(): rv=-1. Query= insert into Dialogs (HashEntry,HashID,CallID,FromURI,FromTag,ToURI,ToTag,CallerSock,CalleeSock,StartTime,State,Timeout,CallerCSeq,CalleeCSeq,CallerRouteSet,CalleeRouteSet,CallerContact,CalleeContact,SFlags,ToRouteName,req_uri,xdata,iflags ) 3(2931) ERROR: db_unixodbc [con.c:220]: db_unixodbc_extract_error(): unixodbc:SQLExecDirect=42S22:1:207:[FreeTDS][SQL Server]Invalid column name 'req_uri'. The dialog.c file infact doesn't contain the req_uri_column, x_data_column and the iflags_column in static param_export_t mod_params[],static int mod_init(void). The dlg_db_handler.c files does contain them in the beginning of the file and in static int select_entire_dialog_table(db1_res_t ** res, int fetch_num_rows). I haven't checked the other remaining files, but I think the only problem is the renaming of these columns in the kamailio script. Just wondering if anyone else has noticed this?

1 0

what could be the problem here? 500 Invalid routeset?
by Kelvin Chua 29 Nov '13

29 Nov '13

U 2013/11/28 09:06:09.411796 6X.2X1.4.1X5:5060 -> 2X8.1X1.3X.2X:5060 INVITE sip:+18X88X441X1@2X8.1X1.3X.2X SIP/2.0. Record-Route: <sip:6X.2X1.4.1X5;lr=on;ftag=gK0662d671>. Record-Route: <sip:6X.2X1.4.9X;lr=on;ftag=gK0662d671>. Accept: application/sdp. Allow: INVITE,ACK,CANCEL,BYE. Via: SIP/2.0/UDP 6X.2X1.4.1X5;branch=z9hG4bKcff3.da8920b2.0. Via: SIP/2.0/UDP 6X.2X1.4.9X;branch=z9hG4bKcff3.66c425c4.0. Via: SIP/2.0/UDP 192.168.47.68:5060;branch=z9hG4bK06Bbcfc5fb404048790. From: <sip:+18X16X620X3@192.168.47.68;isup-oli=0>;tag=gK0662d671. To: <sip:+18X88X441X1@6X.2X1.4.9X>. Call-ID: 1443253238_103264169(a)192.168.47.68. CSeq: 525 INVITE. Max-Forwards: 47. Contact: <sip:+18X16X620X3@192.168.47.68:5060>. Content-Length: 327. Content-Disposition: session; handling=required. Content-Type: application/sdp. Remote-Party-ID: <sip:+18X16X620X3@192.168.47.68:5060 >;privacy=off;screen=no. . v=0. o=Sonus_UAC 30934 15833 IN IP4 192.168.47.68. s=SIP Media Capabilities. c=IN IP4 6X.2X1.4.9X. t=0 0. m=audio 5770 RTP/AVP 0 18 96 101. a=rtpmap:0 PCMU/8000. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=no. a=rtpmap:96 iLBC/8000. a=fmtp:96 mode=30. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=sendrecv. a=maxptime:30. U 2013/11/28 09:06:09.413388 2X8.1X1.3X.2X:5060 -> 6X.2X1.4.1X5:5060 SIP/2.0 183 Session Progress. Record-Route: <sip:6X.2X1.4.1X5;lr=on;ftag=gK0662d671>. Record-Route: <sip:6X.2X1.4.9X;lr=on;ftag=gK0662d671>. Via: SIP/2.0/UDP 6X.2X1.4.1X5;branch=z9hG4bKcff3.da8920b2.0;rport=5060. Via: SIP/2.0/UDP 6X.2X1.4.9X;branch=z9hG4bKcff3.66c425c4.0. Via: SIP/2.0/UDP 192.168.47.68:5060;branch=z9hG4bK06Bbcfc5fb404048790. From: <sip:+18X16X620X3@192.168.47.68;isup-oli=0>;tag=gK0662d671. To: <sip:+18X88X441X1@6X.2X1.4.9X >;tag=bbd932f8f9dbf9743f9b7cadcbf622ac.10eb. Call-ID: 1443253238_103264169(a)192.168.47.68. CSeq: 525 INVITE. Server: kamailio (4.0.4 (x86_64/linux)). Content-Length: 0. . U 2013/11/28 09:06:09.413936 2X8.1X1.3X.2X:5060 -> 6X.2X1.4.1X5:5060 SIP/2.0 100 trying -- your call is important to us. Via: SIP/2.0/UDP 6X.2X1.4.1X5;branch=z9hG4bKcff3.da8920b2.0;rport=5060. Via: SIP/2.0/UDP 6X.2X1.4.9X;branch=z9hG4bKcff3.66c425c4.0. Via: SIP/2.0/UDP 192.168.47.68:5060;branch=z9hG4bK06Bbcfc5fb404048790. From: <sip:+18X16X620X3@192.168.47.68;isup-oli=0>;tag=gK0662d671. To: <sip:+18X88X441X1@6X.2X1.4.9X>. Call-ID: 1443253238_103264169(a)192.168.47.68. CSeq: 525 INVITE. Server: kamailio (4.0.4 (x86_64/linux)). Content-Length: 0. . U 2013/11/28 09:06:10.672460 2X8.1X1.3X.2X:5060 -> 6X.2X1.4.1X5:5060 SIP/2.0 180 Ringing. Via: SIP/2.0/UDP 6X.2X1.4.1X5;rport=5060;branch=z9hG4bKcff3.da8920b2.0. Via: SIP/2.0/UDP 6X.2X1.4.9X;branch=z9hG4bKcff3.66c425c4.0. Via: SIP/2.0/UDP 192.168.47.68:5060;branch=z9hG4bK06Bbcfc5fb404048790. Record-Route: <sip:2X8.1X1.3X.2X;lr;did=873.7d91;nat=yes>. Record-Route: <sip:6X.2X1.4.1X5;lr;ftag=gK0662d671>. Record-Route: <sip:6X.2X1.4.9X;lr;ftag=gK0662d671>. Call-ID: 1443253238_103264169(a)192.168.47.68. From: <sip:+18X16X620X3@192.168.47.68;isup-oli=0>;tag=gK0662d671. To: <sip:+18X88X441X1@6X.2X1.4.9X>;tag=3pOAt1HRTOy9Xfi4Rsbbz9gf73MsuXge. CSeq: 525 INVITE. Contact: <sip:1X5.6X.1X6.2X3:9439>. Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS. Content-Length: 0. . U 2013/11/28 09:06:12.931892 2X8.1X1.3X.2X:5060 -> 6X.2X1.4.1X5:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 6X.2X1.4.1X5;rport=5060;branch=z9hG4bKcff3.da8920b2.0. Via: SIP/2.0/UDP 6X.2X1.4.9X;branch=z9hG4bKcff3.66c425c4.0. Via: SIP/2.0/UDP 192.168.47.68:5060;branch=z9hG4bK06Bbcfc5fb404048790. Record-Route: <sip:2X8.1X1.3X.2X;lr;did=873.7d91;nat=yes>. Record-Route: <sip:6X.2X1.4.1X5;lr;ftag=gK0662d671>. Record-Route: <sip:6X.2X1.4.9X;lr;ftag=gK0662d671>. Call-ID: 1443253238_103264169(a)192.168.47.68. From: <sip:+18X16X620X3@192.168.47.68;isup-oli=0>;tag=gK0662d671. To: <sip:+18X88X441X1@6X.2X1.4.9X>;tag=3pOAt1HRTOy9Xfi4Rsbbz9gf73MsuXge. CSeq: 525 INVITE. Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS. Contact: <sip:1X5.6X.1X6.2X3:9439>. Supported: replaces, 100rel, timer, norefersub. Content-Type: application/sdp. Content-Length:238. . v=0. o=- 3594636366 3594636367 IN IP4 2X8.1X1.3X.2X. s=pjmedia. i=(o=IN IP4 10.0.193.243). c=IN IP4 1X5.6X.1X6.2X3. t=0 0. m=audio 10246 RTP/AVP 0. c=IN IP4 2X8.1X1.3X.2X. a=rtcp:10247. a=sendrecv. a=rtpmap:0 PCMU/8000. a=nortpproxy:yes. U 2013/11/28 09:06:12.960342 6X.2X1.4.1X5:5060 -> 2X8.1X1.3X.2X:5060 ACK sip:1X5.6X.1X6.2X3:9439 SIP/2.0. Record-Route: <sip:6X.2X1.4.1X5;lr=on;ftag=gK0662d671>. Record-Route: <sip:6X.2X1.4.9X;lr=on;ftag=gK0662d671>. Via: SIP/2.0/UDP 6X.2X1.4.1X5;branch=z9hG4bKcff3.da8920b2.2. Via: SIP/2.0/UDP 6X.2X1.4.9X;branch=z9hG4bKcff3.66c425c4.2. Via: SIP/2.0/UDP 192.168.47.68:5060;branch=z9hG4bK06Bbd0344f60e48a125. From: <sip:+18X16X620X3@192.168.47.68;isup-oli=0>;tag=gK0662d671. To: <sip:+18X88X441X1@6X.2X1.4.9X>;tag=3pOAt1HRTOy9Xfi4Rsbbz9gf73MsuXge. Call-ID: 1443253238_103264169(a)192.168.47.68. CSeq: 525 ACK. Max-Forwards: 68. Route: <sip:2X8.1X1.3X.2X:5060;lr;did=873.7d91;nat=yes>. Content-Length: 0. . ------------------------ call goes on a for a while --------------------------- U 2013/11/28 09:06:24.358786 2X8.1X1.3X.2X:5060 -> 6X.2X1.4.1X5:5060 BYE sip:+18X16X620X3@6X.2X1.4.1X5:5060 SIP/2.0. Via: SIP/2.0/UDP 2X8.1X1.3X.2X;branch=z9hG4bKbb1b.267a7326.0. Via: SIP/2.0/UDP 1X5.6X.1X6.2X3:9439;rport=9439;branch=z9hG4bKPj6XR.AckX-G8lRIN4ZuDvjaPB6ZnUpHUa. Max-Forwards: 16. From: <sip:+18X88X441X1@6X.2X1.4.9X>;tag=3pOAt1HRTOy9Xfi4Rsbbz9gf73MsuXge. To: <sip:+18X16X620X3@192.168.47.68;isup-oli=0>;tag=gK0662d671. Call-ID: 1443253238_103264169(a)192.168.47.68. CSeq: 5685 BYE. Route: <sip:6X.2X1.4.1X5;lr;ftag=gK0662d671>. Route: <sip:6X.2X1.4.9X;lr;ftag=gK0662d671>. User-Agent: CSipSimple_m0-16/r2330. Content-Length: 0. . U 2013/11/28 09:06:24.372741 6X.2X1.4.1X5:5060 -> 2X8.1X1.3X.2X:5060 SIP/2.0 500 Invalid routeset. Via: SIP/2.0/UDP 2X8.1X1.3X.2X;branch=z9hG4bKbb1b.267a7326.0. Via: SIP/2.0/UDP 1X5.6X.1X6.2X3:9439;rport=9439;branch=z9hG4bKPj6XR.AckX-G8lRIN4ZuDvjaPB6ZnUpHUa. From: <sip:+18188244111@6X.2X1.4.9X>;tag=3pOAt1HRTOy9Xfi4Rsbbz9gf73MsuXge. To: <sip:+18X16X620X3@192.168.47.68;isup-oli=0>;tag=gK0662d671. Call-ID: 1443253238_103264169(a)192.168.47.68. CSeq: 5685 BYE. Server: Bandwidth.com CLEC. Content-Length: 0. . Kelvin Chua

4 15

Safe Maximum for Shared Memory?
by elactrum＠jamailca.com 28 Nov '13

28 Nov '13

Hi, I have Kamailio running on a 32-bit Linux server with 4 GB of memory. Is there any performance impact on Kamailio when increasing shared memory size? Or is the only concern that other processes have sufficient memory left over? The highest recommendation I have found on the mailing list was 1 GB [1], and one user reports using 2 GB [2]. Thanks! -Andrew [1] http://lists.sip-router.org/pipermail/sr-users/2011-October/070458.html [2] http://lists.sip-router.org/pipermail/users/2008-November/020646.html

2 1

rtpproxy / sdp / problem with signalling
by Oliver Roth 28 Nov '13

28 Nov '13

Problem with signalling - RTP gets lost! Rtpproxy not working properly? I am absolutely stuck ... cause this happens in a live environement. I have the following situation A calls B over carrier 1 - number is not valid and I get back error 404 from carrier and now freeswitch should play a message saying: "number not valid". But from carrier 1 I get back an RTP stream that is useless [1] - and if the correct streams opens from freeswitch - this does not get back to A [2]. I tested with rtpproxy on Kamailio - and all the rtp streams arrive at the Kamailio - but they cannot be "connected" correctly. I guess the problem is the 183 I get back from carrier 1 - after whitch rtp is opened. Or there is a wrong sdp singallisation if the "correct" stream arrives [3]. Sorry - I cannot get a solution - but I could provide various tcpdumps and pcaps. A Kamailio Carrier 1 Freeswitch INVITE ---------------------> 100 Your call is important <--------------------- INVITE ------------------------> 100 Trying <------------------------ 183 Session Progress SDP <------------------------ 183 Session Progress SDP <------------------------ RTP <================= RTP <================= RTP =================> RTP =================> [1] 404 not found <--------------------------- ACK ----------------------------> INVITE ---------------------------------------------------------> 100 Trying <-------------------------------------------------------- 200 OK SDP <-------------------------------------------------------- [3] 200 OK SDP <--------------------------- RTP (Announcment - number not valid") [2] <=================================== ACK ----------------------------> ACK ----------------------------------------------------------> INFO ----------------------------> INFO ----------------------------------------------------------> 200 OK <-------------------------------------------------------- 200 OK <--------------------------- BYE ----------------------------> BYE ----------------------------------------------------------> 200 OK <-------------------------------------------------------- 200 OK <---------------------------

2 1

Regarding Kamailio Sip Server
by Naveen Chand 28 Nov '13

28 Nov '13

Dear Sir, well i would like to know,is there any web interface for kamailio to configure complete configuration part,database,modules and upgrades similar like Astrix server ,Kamailio Sip server is Really Rock Solid server,when i first visited your site,i saw the name called Rock Solid ,i thought it just the call like that ,but after testing it ,it satisfied my needs,that is Video calling 2 way ,in excellent manner,well i would like to is Kamailio Sip server is Peer to Peer or not,if it is Peer to Peer,i have tested it ,i removed the connectivity from Server between Clients when call established,it worked for 20 mins and after it discards the call ,so i was bit confusing that kamailio sip server is Peer to Peer or not,pls confirm me,if it is peer to Peer,pls send me the step by step instruction how to configure the Peering module ,But i request you if there is any Web interface Like Astrix it would be great to control all the elements in Kamailio Best Regards T.NAVEEN CHAND

2 1

Books
by Joli Martinez 27 Nov '13

27 Nov '13

Hello, Is there any books you would recommend reading so I can learn more on Kamailio? thanks,

2 2

Log files
by Joli Martinez 27 Nov '13

27 Nov '13

I am running Kamailio in CentOS. I ran tcpdump and noticed that we are getting attacked from IP 188.138.32.72. I have already blocked it on IPtables, but he keeps on attacking the server. If I look at "/var/log/secure" there are no SIP messages. My question is where is the log file for Kamailio and how can I prevent this type of attacks in the future. Thanks,

5 10

voice prompts / early media and kamailio
by Oliver Roth 27 Nov '13

27 Nov '13

Hi all Based on my problem reported with subject "error handling<http://sip-router.1086192.n5.nabble.com/error-handling-tp123240.html>" I have some other questions. I think it is a conceptual question - and I do not see any solution. I would like to handle Kamailio with carrierroute / carrierfailureroute module different errors. Like 404, 403, busy - or whatever sip error occurs. Some of them need to be sent to a freeswitch playing an announcement (like "this number is blocked", "no more credit", ...). So if an error occur (lets say 403) then the call is routed by carrierfailurroute to fresswitch playing message for 403. If I am listening the whole message - I get back error 403 at the end and the call is logged in missed calls as error 403 sent from the freeswitch - everything ok. If I cancel the listening by hanging up - 487 is stored in missed_calls - cause I terminated the call before getting error 403 back from freeswitch. ==> so I loose this important information How can I get back error 403 - play an announcement and make sure, it is logged as 403 in database? Thanks for helping ... Oli

3 2