December 2017 - sr-users

[Serusers] Digest Authentication with Tenor DX
by Ashutosh Kumar 29 Apr '25

29 Apr '25

Hi, Does someone have any idea/experience with Quintum DX radius server's support for digest mode authentication. The Access-Request packets sent by SER are getting an error back. Guide. Regards, Ashutosh Kumar Chetu, Inc. Ph : 1(305) 402 6724 - Witin US Ph : 91 120 5323340 - Outside US Fax:1 (305) 832 5987 For more information, please visit http://www.chetu.com

2 1

Re: [SR-Users] t_drop_replies not working with t_suspend in failure route
by Huber Andreas 03 Sep '21

03 Sep '21

Hi, We’re still using kamailio 4.4 but we’ll be migrating to 5.0 soon. Cool so it will be fixed when we migrate ! Thanks, Andreas From: sr-users [mailto:sr-users-bounces@lists.kamailio.org] On Behalf Of Federico Cabiddu Sent: vendredi 12 mai 2017 11:56 To: Kamailio (SER) - Users Mailing List Subject: Re: [SR-Users] t_drop_replies not working with t_suspend in failure route Hi, which version are you using? A similar case had been reported some months ago and it should be fixed in 5.0. Regards, Federico On Fri, May 12, 2017 at 11:44 AM, Huber Andreas <andreas.huber(a)nagra.com<mailto:andreas.huber@nagra.com>> wrote: Hello, We have a use case where we suspend a transaction in a failure_route to give UEs that might be woken by a push notification more time to REGISTER and join the INVITE. We’d like to drop the previous branches in this case. I tried using t_drop_replies() but it has no effect. The doc states that t_drop_replies() is only working if a new branch is added. And from my understanding t_suspend() adds a new branch. But is it possible that t_drop_replies() cannot be used with t_suspend()? Or am I missing something? Kind Regards, Andreas _______________________________________________ Kamailio (SER) - Users Mailing List sr-users(a)lists.kamailio.org<mailto:sr-users@lists.kamailio.org> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

2 1

need help with RTPProxy in bridged mode
by Grant Bagdasarian 04 Apr '20

04 Apr '20

Hello, I'm using RTPproxy for the first time in bridged mode and I can't get kamailio/rtpproxy to rewrite the c parameter to the correct public ip address of kamailio. The setup is as following: Carrier ------[fiber]------ Kamailio ---------[lan]--------- Freeswitch Kamailio is listening on two interfaces: 1) Private: 172.0.0.1 2) Public: 192.168.0.1 (since we have a dedicated fiber with our carrier, this is its public address) Freeswitch is listening on: 1) 172.0.0.2 Carrier is on: 1) 10.0.0.1 I've started an rtpproxy instance on the Kamailio box using: rtpproxy -s udp:127.0.0.1:7721 -u rtpproxy rtpproxy -p /var/run/rtpproxy/rtpproxy.pid -l 192.168.0.1 172.0.0.1 I've played around with rtpproxy_manage() and the various flags (ie, ei), but I can't get kamailio to set the correct public IP when the 200 OK has to be sent back to the carrier. It always sets it to its private address, instead of its public address. I'm using Kamailio 4.2 with sippy/rtpproxy 2.0. Could someone please point me into the right direction? Thanks! Grant

4 8

rtpproxy does not response, disable it
by Zodiac 03 Jan '20

03 Jan '20

Dear friends, I am working on a program on Kamailio and rtpengine proxy. I am wondering whether can I set Kamailio and rtpengine daemon on different physical machines. For example, I set Kamailio on a machine with IP address:10.109.247.80, and launch rtpengine daemon on another machine with interface parameter as 10.109.247.90 and ng port 7723. I set parameter in Kamailio.cfg with modparam(“rtpengine”, “rtpengine_sock”, “udp:10.109.247.90:7723”). Unfortunately I got debug message like this: ERROR: rtpengine [rtpengine.c:1710]: send_rtpp_command(): can't send command to a RTP proxy ERROR: rtpengine [rtpengine.c:1746]: send_rtpp_command(): proxy <udp:10.109.247.90:7723> does not respond, disable it ERROR: rtpengine [rtpengine.c:1616]: rtpp_test(): proxy did not respond to ping And, I also tried to set Kamailio and rtpengine daemon in a same machine,and use modparam(“rtpengine”, “rtpengine_sock”, “udp:localhost:7723”). And Kamailio can work functionally under this situation. rtpengine daemon can receive ping message from Kamailio and rtpengine daemon can work as suspected. So for the later case, is it supposed that Kamailio be in the same machine with same localhost address? Otherwise, what’s the reason for my ERROR? ------------------------------------ 北京邮电大学网络技术研究院网络与交换技术国家重点实验室田军 +86 18810315790 mozillafire(a)bupt.edu.cn ------------------------------------

5 10

tcp Free fragment not found
by Diego Nadares 04 Oct '18

04 Oct '18

Hi guys! We have four a scripts that sends dlg.list command to kamailio through xmlrpc. They are not executed simultaneously. Sometimes, we are getting the following errors: fm_search_defrag(): fm_search_defrag(0x7f212c25a000, 5273984); Free fragment not found!2017-05-26T13:54:20.438736-03:00 drwsip02 /usr/local/sbin/kamailio[19833]: ERROR: <core> [mem/f_malloc.c:498]: fm_malloc(): fm_malloc(0x7f212c25a000, 5273984) called from core: tcp_main.c: tcpconn_new(957), module: core; Free fragment not found!2017-05-26T13:54:20.439101-03:00 drwsip02 /usr/local/sbin/kamailio[19833]: ERROR: <core> [tcp_main.c:959]: tcpconn_new(): mem. allocation failure2017-05-26T13:54:20.439344-03:00 drwsip02 /usr/local/sbin/kamailio[19833]: ERROR: <core> [tcp_main.c:3985]: handle_new_connect(): tcpconn_new failed, closing socket I all ready increased this two variables: tcp_conn_wq_max=30000000 tcp_rd_buf_size=5273226 How can I see how much memory xmlrpc is using? Any advice will be appreciated. Thanks in advance! Diego

2 2

Kamctl Stats Update
by Noah Mehl 07 Aug '18

07 Aug '18

Hey all, I was wondering if the kamctl stats output could be updated to provide a bit more parseable JSON? For instance: # kamctl stats shmem | jq . { "jsonrpc": "2.0", "result": [ "shmem:fragments = 18", "shmem:free_size = 467187808", "shmem:max_used_size = 69694104", "shmem:real_used_size = 69683104", "shmem:total_size = 536870912", "shmem:used_size = 41048984" ], "id": 4300 } I would hope would be more like this: { "jsonrpc":"2.0", "result":[ { "shmem":[ { "fragments":18, "free_size":467187808, "max_used_size":69694104, "real_used_size":69683104, "total_size":536870912, "used_size":41048984 } ] } ], "id":4300 } I apologize in advanced because I don’t have the skillset to contribute such a feature. Thanks! ~Noah

5 8

No cdr after Kamailio 5.0.4 and 5.2 dev restart
by Kordován Szabolcs 27 Jul '18

27 Jul '18

Hi All, In March there was a discus about this issue. We tested the new 5.2 dev and 5.0.4 version of Kamailio and we experience that If we restart Kamailio during the call the cdr won't be stored in table acc_cdrs but the data will be inserted to table acc and data will be deleted from table dialog and dialog_vars. Did I omit the fix for it? Thanks for your help. Best regards, Szabolcs

2 3

Kamailio Behind TCP Load Balancer
by Colin Morelli 04 Jun '18

04 Jun '18

Hey all, I'm looking to put Kamailio behind a TCP load balancer that is SIP-unaware. My application is deployed in AWS and I'm tying to place Kamailio behind an ELB. For the most part, everything is fine. For my specific implementation I'm disabling UDP as a signaling transport and using only TLS. This enables me to not have to worry about a SIP-aware LB at the edge because replies to an incoming request will be sent over the existing established TCP socket (avoiding any crazy routing requirements). However - this poses an issue with source addresses. Does Kamailio support anything like the proxy protocol ( http://www.haproxy.org/download/1.5/doc/proxy-protocol.txt) for getting TCP stream information from a load balancer? Do I need to go back to exposing it directly to the world so that I can get source addresses? Thanks, Colin

3 4

Kamailio Websocket Questions
by Nagorny, Dimitry 17 Apr '18

17 Apr '18

Hi List, two questions regarding Kamailio Websockets: 1. How do I send INVITE request TO the listening Websocket? I usually used for UDP/TCP/TLS these format, but somehow this is not working for Websocket because it gets in an endless loop: if ($rU=~"^(\+|00|0)?[1-9][0-9]{4,20}$") { $ru = "sip:" + $rU + "@" + $sel(cfg_get.pstn.gw_ip) + ";user=phone;transport=udp"; force_send_socket(udp:MY_EXTERN_IP:MY_EXTERN_PORT); rtpengine_offer("internal trust-address RTP AVP"); route(RELAY); exit; } 2. Why do I get these errors every time my Websocket Client is registering, but it still works and DB is inserted with registered location: ERROR: <core> [parser/parse_fline.c:257]: parse_first_line(): parse_first_line: bad message (offset: 22) ERROR: <core> [parser/msg_parser.c:690]: parse_msg(): ERROR: parse_msg: message=<HTTP/1.1 101 Switching Protocols#015#012Sia: SIP/2.0/TCP 10.250.5.17:51283#015#012Sec-WebSocket-Protocol: sip#015#012Upgrade: websocket#015#012Connection: upgrade#015#012Sec-WebSocket-Accept: 6uLXlD/aBrzu/j3PYP3DWO7rvLE=#015#012Server: kamailio (4.3.5 (x86_64/linux))#015#012Content-Length: 0#015#012#015#012> I am using Kamailio 4.3.5 + CentOS 7.2. I appreciate every help I can get. Best Regards Dimitry Nagorny Trainee

3 4

Re: [SR-Users] How to determine correct port to set in record-route header
by Pranathi Venkatayogi 30 Mar '18

30 Mar '18

Any help? From: Pranathi Venkatayogi Sent: Monday, January 23, 2017 2:35 PM To: 'Kamailio (SER) - Users Mailing List' <sr-users(a)lists.sip-router.org> Subject: How to determine correct port to set in record-route header Hi, I am using Kamailio behind NAT, unable to figure how to make it put “public ip” in Record-route header, I am manually inserting the hard-coded header myself as below. However now I am having trouble choosing the right port number in all scenarios. $var(dstPort) = 5061; if (dst_port==5060) { $var(dstPort) = 5060; } insert_hf("Record-Route: <sip:MY_PUBLICIP_ADDR:$var(dstPort);transport=tls;lr;nat=yes>\r\n", "Record-Route"); In one scenario I see the conflicting port numbers in “via” header vs “Record route”. The ACK is being set to port 5060 based on Record route header and is not being received by the callee. 2017-01-23 14:52:49.970233 [blink.exe 2780]: SENDING: Packet 11, +0:00:36.411867 10.0.27.108:58217 -(SIP over TLS)-> 172.31.211.31:5061 SIP/2.0 180 Ringing Via: SIP/2.0/TLS 63.149.103.72:5061;received=172.31.211.31;branch=z9hG4bK4799.7067bd2a48063748a4c353fa408eaefa.0 Via: SIP/2.0/UDP 10.0.16.52;rport=5060;branch=z9hG4bK4799.935a27c6ef5ad112225964cbe7c1be44.0;i=2 Via: SIP/2.0/TLS 10.11.200.12:51793;rport=51793;received=10.11.200.12;branch=z9hG4bKPj49f6aeca3f9b4155ab4c5304b544aa4d;alias Record-Route: <sip:63.149.103.72:5060;transport=tls;lr;nat=yes> Record-Route: <sip:10.0.16.52:5061;transport=tls;lr;nat=yes> Call-ID: 09ce10efa6a946bf9445ccc21857393e From: "cust1" <sip:cust1@devtranslation.sms-test.cyracom.com>;tag=95082caabecc42548c2fec5ccd29e5de To: <sip:spanish@translation.sms-test.cyracom.com>;tag=ec365cc8489b48a7bc5725d21b7d97a1 CSeq: 17422 INVITE Server: Blink 3.0.0 (Windows) Contact: <sip:20745891@10.0.27.108:58216;transport=tls> Allow: SUBSCRIBE, NOTIFY, PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, MESSAGE, REFER Content-Length: 0 Questions: 1. How can I let in-built record-route function automatically choose “public ip” so I can get rid of my manual insertion altogether. 2. If no option, what is the right way to choose the port on which packet is being received, so it is same as what is on “VIA”. 3. Any other pointers to improve the logic here?

3 3

authenticating to mongodb fails
by hdssdsdsdsfsdf hdssdsdsdsfsdf 21 Mar '18

21 Mar '18

When I connect using mongo, the credentials work: $ mongo kamailio -u "kam" -p "kam" MongoDB shell version v3.4.9 connecting to: mongodb://127.0.0.1:27017/kamailio MongoDB server version: 3.4.9 > db.subscriber.find() { "_id" : ObjectI ... But when I use the following DBURL in kamailio.cfg, kamailio fails to even login to mongo: #!define DBURL "mongodb://kam:kam@localhost/kamailio" If I disable mongodb authentication, kamailio starts up just fine again. Any idea what's going wrong here?

3 10

Need useful graphics ideas
by Karsten Horsmann 16 Mar '18

16 Mar '18

Hello List, I thought about some kind of Kamailio stats source (like registered users, calls active and some other things) to collect them into influx dB and draw them with grafana. How do you solved that? Timer based routes or statsd or whatever? Kind regards Karsten Horsmann

5 10

is_audio_on_hold() doesn't support rfc3264
by Julia Boudniatsky 13 Feb '18

13 Feb '18

FYI, After some tests found, that function "*is_audio_on_hold()*" (textops) *supports only rfc 254*3, where "hold" is indicated by setting the "c" destination addresses for the media streams to zero (0.0.0.0). The newest *rfc3264*, where "hold" is indicated by a=sendonly/inactive, *is not supported*. Kamailio version 4.4.6. Best regards, Julia

4 8

rtjson + uac + event - OK, ACK and BYE display name not updated
by Diego Nadares 30 Jan '18

30 Jan '18

Hi Guys, We are modifying "from" and "to" headers with rtjson module via a json struct. It works fine in INVITE, TRYING, RINGING and OK but not in the following messages. Kamailio It's changing ONLY "from" and "to" URI BUT NOT the DISPLAY NAME. I think it's the tm module but I can't figure out how to confirm this. Maybe I need to configure something else in my cfg or could it be a bug? My json struct that is handled by rtjson module response.routing = "serial"; //response.routing = "parallel"; response.routes = []; response.routes[0] = {}; response.routes[0].uri = "sip:1111111111@172.16.213.31:5060"; response.routes[0].headers = { // Headers to be modified "from": { "display": "1111111111", "uri": "sip:111111111@172.16.213.38" }, "to": { "display": "2222222222", "uri": "sip:2222222222@172.16.213.38" }, }; response.routes[0].headers.extra = {};//"X-Hdr-A: abc\r\nX-Hdr-B: bcd\r\n"; This is part of my cfg .... modparam("dialog","dlg_flag", FLD_START) modparam("uac","restore_mode","auto") modparam("uac", "restore_dlg", 1) .... # account only INVITEs if (is_method("INVITE") && !has_totag()) { setflag(FLT_ACC); # do accounting * setflag(FLD_START); # do accounting* setflag(FLT_ACCMISSED); setflag(FLT_ACCFAILED); } ..... >From source/Aleg: *From: sipp <sip:sipp@172.16.213.21:5060 <http://sip:sipp@172.16.213.21:5060>>;tag=1.* *To: sut <sip:5555555555@172.16.213.38:5060 <http://sip:5555555555@172.16.213.38:5060>>.* To dest/Bleg: *From: 1111111111 <sip:111111111@172.16.213.38 <sip%3A111111111(a)172.16.213.38>>;tag=1.* *To: 2222222222 <sip:2222222222@172.16.213.38 <sip%3A2222222222(a)172.16.213.38>>.* Incorrect display name in BYE and ACK: *From: sipp <sip:111111111@172.16.213.38 <sip%3A111111111(a)172.16.213.38>>;tag=1.* *To: sut <sip:2222222222@172.16.213.38 <sip%3A2222222222(a)172.16.213.38>>;tag=2.* interface: any filter: ( port 5060 ) and (ip or ip6) # U 2016/12/06 15:52:13.638731 172.16.213.21:5060 -> 172.16.213.38:5060 INVITE sip:5555555555@172.16.213.38:5060 SIP/2.0. Via: SIP/2.0/UDP 172.16.213.21:5060;branch=z9hG4bK-12775-1-0. *From: sipp <sip:sipp@172.16.213.21:5060 <http://sip:sipp@172.16.213.21:5060>>;tag=1.* *To: sut <sip:5555555555@172.16.213.38:5060 <http://sip:5555555555@172.16.213.38:5060>>.* Call-ID: 1-12775(a)172.16.213.21. CSeq: 1 INVITE. Contact: "SIPP" <sip:sipp@172.16.213.21:5060>. Max-Forwards: 70. Subject: Performance Test. Content-Type: multipart/mixed;boundary=uniqueBoundary. Remote-Party-ID: <sip:sipp@172.16.213.21 >:5060;party=calling;id-type=subscriber;privacy=off;screen=no>. Content-Length: 549. . --uniqueBoundary. Content-Type: application/sdp. . v=0. o=user1 53655765 2353687637 IN IP4 172.16.213.21. s=-. c=IN IP4 172.16.213.21. t=0 0. m=audio 6000 RTP/AVP 8. a=rtpmap:8 PCMA/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-11,16. . --uniqueBoundary. Content-Type: application/gtd. Content-Disposition: signal;handling=optional. . IAM,. CGN,04,y,1,y,4,1143617400. CIC,0000000573. CPC,09. CPN,02,y,1,52381660. FCI,n,n,n,n,y,n,n,u. GCI,f7140cc78a611601838a002128d7e512. NOC,0,n,1,n. PRN,q761*,AR*,oper2,1993. TMR,02. . --uniqueBoundary--. ................ # U 2016/12/06 15:52:13.734159 172.16.213.38:5060 -> 172.16.213.21:5060 SIP/2.0 100 trying -- your call is important to us. Via: SIP/2.0/UDP 172.16.213.21:5060;branch=z9hG4bK-12775-1-0. *From: sipp <sip:sipp@172.16.213.21:5060 <http://sip:sipp@172.16.213.21:5060>>;tag=1.* *To: sut <sip:5555555555@172.16.213.38:5060 <http://sip:5555555555@172.16.213.38:5060>>.* Call-ID: 1-12775(a)172.16.213.21. CSeq: 1 INVITE. Server: kamailio (4.4.4 (x86_64/linux)). Content-Length: 0. . ................ # U 2016/12/06 15:52:13.878600 172.16.213.38:5060 -> 172.16.213.31:5060 INVITE sip:1111111111@172.16.213.31:5060 SIP/2.0. Via: SIP/2.0/UDP 172.16.213.38;branch=z9hG4bKabaa.840cc83114975a34a37b7af020d37b65.1. *From: 1111111111 <sip:111111111@172.16.213.38 <sip%3A111111111(a)172.16.213.38>>;tag=1.* *To: 2222222222 <sip:2222222222@172.16.213.38 <sip%3A2222222222(a)172.16.213.38>>.* Call-ID: 1-12775(a)172.16.213.21. CSeq: 1 INVITE. Max-Forwards: 69. Subject: Performance Test. Content-Type: multipart/mixed;boundary=uniqueBoundary. Content-Length: 788. Contact: <sip:btpsh-58470879-6c61-1@172.16.213.38>. . --uniqueBoundary. Content-Type: application/sdp. . v=0. o=user1 53655765 2353687637 IN IP4 172.16.213.38. s=-. c=IN IP4 172.16.213.38. t=0 0. m=audio 40236 RTP/AVP 8. a=rtpmap:8 PCMA/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-11,16. a=sendrecv. a=rtcp:40237. a=ice-ufrag:QNCzXhUr. a=ice-pwd:Ci90BRpdZH51Hx5BaPgGMrGCeh. a=candidate:P1djl8LFNb5kexbG 1 UDP 2130706431 172.16.213.38 40236 typ host. a=candidate:P1djl8LFNb5kexbG 2 UDP 2130706430 172.16.213.38 40237 typ host. . --uniqueBoundary. Content-Type: application/gtd. Content-Disposition: signal;handling=optional. . IAM,. CGN,04,y,1,y,4,1143617400. CIC,0000000573. CPC,09. CPN,02,y,1,52381660. FCI,n,n,n,n,y,n,n,u. GCI,f7140cc78a611601838a002128d7e512. NOC,0,n,1,n. PRN,q761*,AR*,oper2,1993. TMR,02. . --uniqueBoundary--. ................ # U 2016/12/06 15:52:13.879441 172.16.213.31:5060 -> 172.16.213.38:5060 SIP/2.0 180 Ringing. Via: SIP/2.0/UDP 172.16.213.38;branch=z9hG4bKabaa.840cc83114975a34a37b7af020d37b65.1. *From: 1111111111 <sip:111111111@172.16.213.38 <sip%3A111111111(a)172.16.213.38>>;tag=1.* *To: 2222222222 <sip:2222222222@172.16.213.38 <sip%3A2222222222(a)172.16.213.38>>;tag=2.* Call-ID: 1-12775(a)172.16.213.21. CSeq: 1 INVITE. Contact: <sip:172.16.213.31:5060;transport=UDP>. Content-Type: application/sdp. Content-Length: 137. . v=0. o=user1 53655765 2353687637 IN IP4 172.16.213.31. s=-. c=IN IP4 172.16.213.31. t=0 0. m=audio 6000 RTP/AVP 0. a=rtpmap:0 PCMU/8000. ................ # U 2016/12/06 15:52:13.936565 172.16.213.38:5060 -> 172.16.213.21:5060 SIP/2.0 180 Ringing. *From: sipp <sip:sipp@172.16.213.21:5060 <http://sip:sipp@172.16.213.21:5060>>;tag=1.* *To: sut <sip:5555555555@172.16.213.38:5060 <http://sip:5555555555@172.16.213.38:5060>>;tag=2.* Call-ID: 1-12775(a)172.16.213.21. CSeq: 1 INVITE. Content-Type: application/sdp. Content-Length: 316. Via: SIP/2.0/UDP 172.16.213.21:5060;branch=z9hG4bK-12775-1-0. Contact: <sip:atpsh-58470879-6c61-2@172.16.213.38>. . v=0. o=user1 53655765 2353687637 IN IP4 172.16.213.38. s=-. c=IN IP4 172.16.213.38. t=0 0. m=audio 40248 RTP/AVP 0. a=rtpmap:0 PCMU/8000. a=sendrecv. a=rtcp:40249. a=candidate:P1djl8LFNb5kexbG 1 UDP 2130706431 172.16.213.38 40248 typ host. a=candidate:P1djl8LFNb5kexbG 2 UDP 2130706430 172.16.213.38 40249 typ host. ................ # U 2016/12/06 15:52:20.882165 172.16.213.31:5060 -> 172.16.213.38:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 172.16.213.38;branch=z9hG4bKabaa.840cc83114975a34a37b7af020d37b65.1. *From: 1111111111 <sip:111111111@172.16.213.38 <sip%3A111111111(a)172.16.213.38>>;tag=1.* *To: 2222222222 <sip:2222222222@172.16.213.38 <sip%3A2222222222(a)172.16.213.38>>;tag=2.* Call-ID: 1-12775(a)172.16.213.21. CSeq: 1 INVITE. Contact: <sip:172.16.213.31:5060;transport=UDP>. Content-Type: application/sdp. Content-Length: 213. . v=0. o=user1 53655765 2353687637 IN IP4 172.16.213.31. s=-. c=IN IP4 172.16.213.31. t=0 0. m=audio 6000 RTP/AVP 0. a=rtpmap:0 PCMU/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=ptime:20. a=sendrecv. ................ # U 2016/12/06 15:52:21.173798 172.16.213.38:5060 -> 172.16.213.21:5060 SIP/2.0 200 OK. *From: sipp <sip:sipp@172.16.213.21:5060 <http://sip:sipp@172.16.213.21:5060>>;tag=1.* *To: sut <sip:5555555555@172.16.213.38:5060 <http://sip:5555555555@172.16.213.38:5060>>;tag=2.* Call-ID: 1-12775(a)172.16.213.21. CSeq: 1 INVITE. Content-Type: application/sdp. Content-Length: 380. Via: SIP/2.0/UDP 172.16.213.21:5060;branch=z9hG4bK-12775-1-0. Contact: <sip:atpsh-58470879-6c61-2@172.16.213.38>. . v=0. o=user1 53655765 2353687637 IN IP4 172.16.213.38. s=-. c=IN IP4 172.16.213.38. t=0 0. m=audio 40248 RTP/AVP 0. a=rtpmap:0 PCMU/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=ptime:20. a=sendrecv. a=rtcp:40249. a=candidate:P1djl8LFNb5kexbG 1 UDP 2130706431 172.16.213.38 40248 typ host. a=candidate:P1djl8LFNb5kexbG 2 UDP 2130706430 172.16.213.38 40249 typ host. ................ # U 2016/12/06 15:52:21.174390 172.16.213.21:5060 -> 172.16.213.38:5060 ACK sip:atpsh-58470879-6c61-2@172.16.213.38 SIP/2.0. Via: SIP/2.0/UDP 172.16.213.21:5060;branch=z9hG4bK-12775-1-4. *From: sipp <sip:sipp@172.16.213.21:5060 <http://sip:sipp@172.16.213.21:5060>>;tag=1.* *To: sut <sip:5555555555@172.16.213.38:5060 <http://sip:5555555555@172.16.213.38:5060>>;tag=2.* Call-ID: 1-12775(a)172.16.213.21. CSeq: 1 ACK. Contact: sip:sipp@172.16.213.21:5060. Max-Forwards: 70. Subject: Performance Test. Content-Length: 0. . ................ # U 2016/12/06 15:52:21.248172 172.16.213.38:5060 -> 172.16.213.31:5060 ACK sip:172.16.213.31:5060;transport=UDP SIP/2.0. Via: SIP/2.0/UDP 172.16.213.38;branch=z9hG4bKabaa.98116b5795d4c30f52156187a72059c8.0. *From: sipp <sip:111111111@172.16.213.38 <sip%3A111111111(a)172.16.213.38>>;tag=1.* *To: sut <sip:2222222222@172.16.213.38 <sip%3A2222222222(a)172.16.213.38>>;tag=2.* Call-ID: 1-12775(a)172.16.213.21. CSeq: 1 ACK. Max-Forwards: 69. Subject: Performance Test. Content-Length: 0. Contact: <sip:btpsh-58470879-6c61-1@172.16.213.38>. . ................ # U 2016/12/06 15:52:51.178826 172.16.213.21:5060 -> 172.16.213.38:5060 BYE sip:atpsh-58470879-6c61-2@172.16.213.38 SIP/2.0. Via: SIP/2.0/UDP 172.16.213.21:5060;branch=z9hG4bK-12775-1-7. *From: sipp <sip:sipp@172.16.213.21:5060 <http://sip:sipp@172.16.213.21:5060>>;tag=1.* *To: sut <sip:5555555555@172.16.213.38:5060 <http://sip:5555555555@172.16.213.38:5060>>;tag=2.* Call-ID: 1-12775(a)172.16.213.21. CSeq: 2 BYE. Contact: sip:sipp@172.16.213.21:5060. Max-Forwards: 70. Subject: Performance Test. Content-Length: 0. . ................ # U 2016/12/06 15:52:51.468639 172.16.213.38:5060 -> 172.16.213.31:5060 BYE sip:172.16.213.31:5060;transport=UDP SIP/2.0. Via: SIP/2.0/UDP 172.16.213.38;branch=z9hG4bK7baa.3cb44935b506e759e3418501b0688b08.0. *From: sipp <sip:111111111@172.16.213.38 <sip%3A111111111(a)172.16.213.38>>;tag=1.* *To: sut <sip:2222222222@172.16.213.38 <sip%3A2222222222(a)172.16.213.38>>;tag=2.* Call-ID: 1-12775(a)172.16.213.21. CSeq: 2 BYE. Max-Forwards: 69. Subject: Performance Test. Content-Length: 0. Contact: <sip:btpsh-58470879-6c61-1@172.16.213.38>. . ................ # U 2016/12/06 15:52:51.469153 172.16.213.31:5060 -> 172.16.213.38:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 172.16.213.38;branch=z9hG4bK7baa.3cb44935b506e759e3418501b0688b08.0. *From: sipp <sip:111111111@172.16.213.38 <sip%3A111111111(a)172.16.213.38>>;tag=1.* *To: sut <sip:2222222222@172.16.213.38 <sip%3A2222222222(a)172.16.213.38>>;tag=2.* Call-ID: 1-12775(a)172.16.213.21. CSeq: 2 BYE. Contact: <sip:172.16.213.31:5060;transport=UDP>. Content-Length: 0. . ................ # U 2016/12/06 15:52:51.519423 172.16.213.38:5060 -> 172.16.213.21:5060 SIP/2.0 200 OK. *From: sipp <sip:sipp@172.16.213.21:5060 <http://sip:sipp@172.16.213.21:5060>>;tag=1.* *To: sut <sip:5555555555@172.16.213.38:5060 <http://sip:5555555555@172.16.213.38:5060>>;tag=2.* Call-ID: 1-12775(a)172.16.213.21. CSeq: 2 BYE. Content-Length: 0. Via: SIP/2.0/UDP 172.16.213.21:5060;branch=z9hG4bK-12775-1-7. Contact: <sip:atpsh-58470879-6c61-2@172.16.213.38>. . ................ exit 13 received, 0 dropped Sorry for my english. Thanks in advance! Diego.

2 7

t_relay dying ?
by Jean Cérien 09 Jan '18

09 Jan '18

Hello I am using kamailio 5.0.2, on a debian 9 system. Everything was running fine, until one of our voip provider changed his switch. Our kamailio is relaying between several voip providers and several asterisk (only the signalisation, no rtp). When we get an invite from this new switch, we select an asterisk and relay it correctly to this box. However, the OK is relayed back. But when the voip providers sends an ACK for this OK, the t_relay function does not return at all, it just dies with no action and no error. Here is the snippet from route(relay) xlog("L_INFO","route(relay) @@ $rm - Source: $si:$sp, fu:$fu, tu:$tu\n" ); $var(restrelay)=t_relay(); xlog("L_INFO","route(relay) @@ $rm - t_relay result: $var(restrelay)" ); if (!$var(restrelay)) { When processing the initial invite, I do get both INFO messages. When the ACK is processed, I only get one INFO message, and no ACK is relayed - so it seems execution dies in the t_relay What could be wrong ??? J. Details of the ACK: ACK sip:dialednumber@kamailioIP:5060 SIP/2.0 Via: SIP/2.0/UDP VOIPPROVIDERIP:5060;branch=z9hG4bKjq16fi00d85uee181ic0.1 To: <sip:kamailioIP:5060>;tag=as7f10ed48 From: <sip:sourcenumber@orange-multimedia.fr >;tag=SD8u3ob01-7dd8efde-0002-00d5-0000-0000 Call-ID: SD8u3ob01-688d41f5e2164ceeafe76f40b82b3f97-v300g00030 CSeq: 1 ACK Max-Forwards: 66 Content-Length: 0 Route: <sip:kamailioIP;lr=on;ftag=SD8u3ob01-7dd8efde-0002-00d5-0000-0000;did=a0b.49d> (should you have enough width; the diagram will look ok) VOIP PROVIDER KAMAILIO ASTERISK 21:38:54.685149 │ ──────────────────────────> │ │ ▒ +0.000451 │ 100 trying -- your call is │ │ ▒ 21:38:54.685600 │ <────────────────────────── │ │ ▒ +0.000084 │ │ INVITE (SDP) │ ▒ 21:38:54.685684 │ │ ──────────────────────────> │ ▒ +0.000831 │ │ 100 Trying │ ▒ 21:38:54.686515 │ │ <────────────────────────── │ ▒ +0.000471 │ │ 200 OK (SDP) │ ▒ 21:38:54.686986 │ │ <────────────────────────── │ ▒ +0.000394 │ 200 OK (SDP) │ │ ▒ 21:38:54.687380 │ <────────────────────────── │ │ ▒ +0.038694 │ ACK │ │ ▒ 21:38:54.726074 │ ──────────────────────────> │ │ ▒ +0.060155 │ │ 200 OK (SDP) │ ▒ 21:38:54.786229 │ │ <<<──────────────────────── │ ▒ +0.000138 │ 200 OK (SDP) │ │ ▒ 21:38:54.786367 │ <<<──────────────────────── │ │ ▒ +0.005721 │ ACK │ │

10 25

WebRTC proxy for legacy systems
by paul＠kristianpaul.org 09 Jan '18

09 Jan '18

Hi, I'm looking to use kamailio as a webrtc proxy for legacy sip system that doesnt have this capability, is there a example or blueprint i can follow to get started with this? I'm RTFMing the docs but still need a while to understand kamailio internals :-)

3 4

Kamailio World 2018 - Call for Presentations
by Daniel-Constantin Mierla 08 Jan '18

08 Jan '18

Hello, I would like to announce that Call for Presentations at Kamailio World 2018 is now open. You can submit your proposal or see more details at: - https://www.kamailioworld.com/k06/call-for-speakers/ The 6th edition of the event takes place again in Berlin, Germany, during May 14-16, 2018. Expect over 150 participants, developers and community members as well as representatives from other popular open source VoIP projects such as Asterisk or FreeSwitch. Looking forward to meeting many of you there! Cheers, Daniel -- Daniel-Constantin Mierla www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - www.asipto.com Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com

1 1

Cnxcc doesn't update amount values in redis
by Donat Zenichev 05 Jan '18

05 Jan '18

Hi community. Have a problem with cnxcc call monitoring. __set_max_credit() allocates new call as expected: "DEBUG: cnxcc [cnxcc_mod.c:444]: __dialog_created_callback(): Flag is not set for this message. Ignoring DEBUG: cnxcc [cnxcc_mod.c:1569]: __set_max_credit(): Setting up new call for client [2], max-credit[0.100000], cost-per-sec[0.010000], initial-pulse [6], final-pulse [6], call-id[2f77fd103d0bfa28718d896876b373fe@b2b.user.agent:50600] DEBUG: cnxcc [cnxcc_mod.c:1470]: set_ctrl_flag(): Flag set! DEBUG: cnxcc [cnxcc_redis.c:313]: redis_get_int(): Got INT value: concurrent_calls=0i DEBUG: cnxcc [cnxcc_redis.c:68]: redis_get_or_create_credit_data(): credit_data with ID=[2] DOES NOT exist in the cluster, creating it... DEBUG: cnxcc [cnxcc_redis.c:92]: redis_insert_credit_data(): Inserting credit_data_t using ID [2] DEBUG: cnxcc [cnxcc_mod.c:1125]: __get_or_create_credit_data_entry(): Credit entry didn't exist. Allocated new entry [0x7f17668f6d70] DEBUG: cnxcc [cnxcc_mod.c:1255]: __alloc_new_call_by_money(): New call allocated for client [2]". So that I can see values inside redis: redis.callision.info:6389> HGETALL cnxcc:money:2 1) "concurrent_calls" 2) "0" 3) "consumed_amount" 4) "0.000000" 5) "ended_calls_consumed_amount" 6) "0.000000" 7) "max_amount" 8) "0.000000" 9) "number_of_calls" 10) "1" 11) "type" 12) "1" But cnxcc doesn't update credit amount during the call. modparam("debugger", "mod_level", "cnxcc=4") but there are no rows in kamailio log like: "DEBUG: cnxcc [cnxcc_check.c:94]: check_calls_by_money(): ec=0.000000, ca=0.600000, ca2=0.600000 DEBUG: cnxcc [cnxcc_check.c:107]: check_calls_by_money(): Client [some_client] | Ended-Calls-Credit-Spent: 0.000000 TotalCredit/MaxCredit: 0.600000/3.000000". cnxcc parameters: modparam("cnxcc", "dlg_flag", FLG_DLG) modparam("cnxcc", "redis", "addr=redis.youwillnever.find;port=6389;db=0") modparam("cnxcc", "credit_check_period", 1) function that performs credit setup: if (!cnxcc_set_max_credit("$var(setid)","$var(credit)","$var(cost_per_sec)","$var(i_pulse)","$var(f_pulse)")) { xlog("L_WARN", "----- cnxcc: $fU - Error setting up credit control - R=$ru ID=$ci\n"); sl_send_reply("402", "Payment Required"); } Why is it so? And as see, all values are set zero. Seems to be problem with redis inserts. Any ideas are highly appreciated. Thanks. -- -- BR, Donat Zenichev Wnet VoIP team Tel Ukraine: +380(44) 5-900-800 Tel USA: +164(67) 8-174-17 https://w-net.us/ <http://wnet.ua>

2 1

NOTIFY generation for REFER
by Konstantin Tumalevich 05 Jan '18

05 Jan '18

I try to build custom attended transfer logick with kamailio and asterisk. My backend can do all work (include interconnect between asterisk servers), so I need to fully handle REFER in kamailio. But I can't send back NOTIFY message with the result of a transfer. Is any way to do this logic inside kamailio or I need to write external SIP service? My route looks like: if(!route(FROM_NODE)) { if(is_method("REFER")) { xlog("L_NOTICE", "Got REFER in call ci:$ci for $(hdr(Refer-To){nameaddr.uri})"); sl_send_reply("202", "Accepted [1]"); # HERE I MAKE async request and want to send NOTIFY back exit; } } -- Skype: konstantin.tumalevich

2 1

BUG: tls [tls_server.c:1229]: tls_read_f(): SSL_ERROR_WANT_READ but data still in the rbio (0x7ffd354fcd30, 8 bytes at 461)
by Abdoul Osséni 05 Jan '18

05 Jan '18

Hello Dear, I use Kamailio 5.1.0 on Linux server: root@sip-africallshop-com:~# kamailio -V version: kamailio 5.1.0 (x86_64/linux) flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: unknown compiled with gcc 4.9.2 I have sometimes the following logs: Dec 14 19:22:16 sd-110402 /usr/local/sbin/kamailio[24197]: BUG: tls [tls_server.c:1229]: tls_read_f(): SSL_ERROR_WANT_READ but data still in the rbio (0x7ffd354fcd30, 8 bytes at 461) Dec 20 10:46:32 sd-110402 /usr/local/sbin/kamailio[24197]: BUG: tls [tls_server.c:1229]: tls_read_f(): SSL_ERROR_WANT_READ but data still in the rbio (0x7ffd354fcd30, 8 bytes at 8) Dec 22 11:02:49 sd-110402 /usr/local/sbin/kamailio[24212]: BUG: tls [tls_server.c:1229]: tls_read_f(): SSL_ERROR_WANT_READ but data still in the rbio (0x7ffd354fcd30, 8 bytes at 3357) Does anybody can explain me these logs? Thanks. Abdoul OSSENI

2 1

One way video using Kamailio, WebRTC, and Asterisk
by Wilkins, Steve 05 Jan '18

05 Jan '18

First I want to give Denys a huge shout-out for all of the help he has given me. It is wonderful that boards like this exists and people are so willing to help a newbie learn. I am on what I am hoping is my last major issue with WebRTC<=>WebRTC calls (using tryit-jssip Chrome or Firefox). I am using Kamailio 5, and Asterisk 15 (pjsip). I am making calls between two WebRTC clients - Client1, and Client2 (using tryit-jssip) Problem: If Client1 calls Client2, and Client2 'ANSWERS', I only have audio/video on Client1. Client2 gets no audio/video, but is connected. If I switch things up and call Client1 from Client2, the same thing happens (Client2 has audio/video and Client1 does not); I can only get audio/video on the calling laptop; the called laptop has no audio/video, but is connected. I see no errors in any of the logs. I am hoping that someone out there has seen this behavior before and has an idea as to the cause and possible solution. Thank you, -Steve

2 1

Is it possible to inject variables into transaction scope
by voipspace voipspace 05 Jan '18

05 Jan '18

2 1

Critical Error
by Nicolas Breuer 04 Jan '18

04 Jan '18

Hello, I got this error when passing a call. CRITICAL: dialog [dlg_hash.c:955]: log_next_state_dlg(): bogus event 5 in state 1 for dlg 0x7f7a17848bd8 [3582:11978] with clid 'ae27f53121fe6d84c6845dedcf2e2793' and tags 'f68d2151b8411946' '' Any ideas ? This is a bug ? Never seen that error before,

3 10

Kamailio fail to start with db_mongodb and ndb_mongodb modules
by Abdul Basit 04 Jan '18

04 Jan '18

Hi, I am trying to setup mongo db as database engine for kamailio as described at <http://www.kamailio.org/wiki/tutorials/kamailio-and-mongodb> http://www.kamailio.org/wiki/tutorials/kamailio-and-mongodb and https://telerain.com/kamailio OS: Debian GNU/Linux 8.10 (jessie) MongoDB server version: 3.4.10 mongo-c-driver-1.9.0.tar.gz compiled with ./configure --disable-static --disable-silent-rules --enable-debug-symbols --enable-ssl=no --enable-sasl=yes --with-libbson=bundled --enable-optimizations --disable-automatic-init-and-cleanup version: kamailio 5.0.4 (x86_64/linux) flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: unknown compiled on 20:45:44 Dec 27 2017 with gcc 4.9.2 include_modules= utils app_lua db_postgres json evapi db_mongodb ndb_mongodb Kamailio is crashing with segfault as soon as it try to load libmongo-c Dec 28 04:44:14 sipserver systemd[1]: Starting Kamailio (OpenSER) - the Open Source SIP Server... Dec 28 04:44:14 sipserver kamailio: INFO: <core> [core/sctp_core.c:75]: sctp_core_check_support(): SCTP API not enabled - if you want to use it, load sctp module Dec 28 04:44:14 sipserver kamailio: INFO: <core> [core/tcp_main.c:4671]: init_tcp(): using epoll_lt as the io watch method (auto detected) Dec 28 04:44:14 sipserver kamailio[11685]: Listening on Dec 28 04:44:14 sipserver kamailio[11685]: udp: 127.0.0.1:5060 Dec 28 04:44:14 sipserver kamailio[11685]: udp: 192.168.10.20:5060 Dec 28 04:44:14 sipserver kamailio[11685]: tcp: 127.0.0.1:5060 Dec 28 04:44:14 sipserver kamailio[11685]: tcp: 192.168.10.20:5060 Dec 28 04:44:14 sipserver kamailio[11685]: Aliases: Dec 28 04:44:14 sipserver kamailio[11685]: tcp: localhost:5060 Dec 28 04:44:14 sipserver kamailio[11685]: udp: localhost:5060 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: INFO: rr [../outbound/api.h:52]: ob_load_api(): unable to import bind_ob - maybe module is not loaded Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: INFO: rr [rr_mod.c:175]: mod_init(): outbound module not available Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: INFO: <core> [core/udp_server.c:153]: probe_max_receive_buffer(): SO_RCVBUF is initially 212992 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: INFO: <core> [core/udp_server.c:203]: probe_max_receive_buffer(): SO_RCVBUF is finally 425984 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: INFO: <core> [core/udp_server.c:153]: probe_max_receive_buffer(): SO_RCVBUF is initially 212992 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: INFO: <core> [core/udp_server.c:203]: probe_max_receive_buffer(): SO_RCVBUF is finally 425984 Dec 28 04:44:14 sipserver systemd[1]: Started Kamailio (OpenSER) - the Open Source SIP Server. Dec 28 04:44:14 sipserver kernel: [53109.390171] show_signal_msg: 20 callbacks suppressed Dec 28 04:44:14 sipserver kernel: [53109.390176] kamailio[11696] segfault at 78 ip 00007f690c0e6e98 sp 00007ffcde1a4770 error 6 in libmongoc-1.0.so.0.0.0[7f690c0ca000+6e000] Dec 28 04:44:14 sipserver kernel: [53109.390753] kamailio[11694] segfault at 78 ip 00007f690c0e6e98 sp 00007ffcde1a4770 error 6 in libmongoc-1.0.so.0.0.0[7f690c0ca000+6e000] Dec 28 04:44:14 sipserver kernel: [53109.391605] kamailio[11698] segfault at 78 ip 00007f690c0e6e98 sp 00007ffcde1a4770 error 6 in libmongoc-1.0.so.0.0.0[7f690c0ca000+6e000] Dec 28 04:44:14 sipserver kernel: [53109.392073] kamailio[11701] segfault at 78 ip 00007f690c0e6e98 sp 00007ffcde1a4770 error 6 in libmongoc-1.0.so.0.0.0[7f690c0ca000+6e000] Dec 28 04:44:14 sipserver kernel: [53109.392408] kamailio[11692] segfault at 78 ip 00007f690c0e6e98 sp 00007ffcde1a4770 error 6 in libmongoc-1.0.so.0.0.0[7f690c0ca000+6e000] Dec 28 04:44:14 sipserver kernel: [53109.392497] kamailio[11700] segfault at 38 ip 00007f690c0e6e98 sp 00007ffcde1a4770 error 6 in libmongoc-1.0.so.0.0.0[7f690c0ca000+6e000] Dec 28 04:44:14 sipserver kernel: [53109.392761] kamailio[11703] segfault at 78 ip 00007f690c0e6e98 sp 00007ffcde1a4770 error 6 in libmongoc-1.0.so.0.0.0[7f690c0ca000+6e000] Dec 28 04:44:14 sipserver kernel: [53109.392825] kamailio[11697] segfault at 38 ip 00007f690c0e6e98 sp 00007ffcde1a4770 error 6 in libmongoc-1.0.so.0.0.0[7f690c0ca000+6e000] Dec 28 04:44:14 sipserver kernel: [53109.393098] kamailio[11705] segfault at 78 ip 00007f690c0e6e98 sp 00007ffcde1a4770 error 6 in libmongoc-1.0.so.0.0.0[7f690c0ca000+6e000] Dec 28 04:44:14 sipserver kernel: [53109.393147] kamailio[11699] segfault at 38 ip 00007f690c0e6e98 sp 00007ffcde1a4770 error 6 in libmongoc-1.0.so.0.0.0[7f690c0ca000+6e000] Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:743]: handle_sigs(): child process 11689 exited by a signal 11 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:746]: handle_sigs(): core was not generated Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:743]: handle_sigs(): child process 11688 exited by a signal 11 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11718]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 14 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11718]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 15 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11718]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 16 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11718]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 17 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11718]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 18 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11718]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 19 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11718]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 20 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11718]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 21 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11718]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 22 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11718]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 23 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11718]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 24 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11718]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 25 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:746]: handle_sigs(): core was not generated Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:743]: handle_sigs(): child process 11690 exited by a signal 11 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:746]: handle_sigs(): core was not generated Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:743]: handle_sigs(): child process 11691 exited by a signal 11 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:746]: handle_sigs(): core was not generated Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:743]: handle_sigs(): child process 11692 exited by a signal 11 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:746]: handle_sigs(): core was not generated Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:743]: handle_sigs(): child process 11693 exited by a signal 11 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:746]: handle_sigs(): core was not generated Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:743]: handle_sigs(): child process 11694 exited by a signal 11 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:746]: handle_sigs(): core was not generated Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:743]: handle_sigs(): child process 11695 exited by a signal 11 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:746]: handle_sigs(): core was not generated Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:743]: handle_sigs(): child process 11696 exited by a signal 11 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:746]: handle_sigs(): core was not generated Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:743]: handle_sigs(): child process 11697 exited by a signal 11 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:746]: handle_sigs(): core was not generated Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:743]: handle_sigs(): child process 11698 exited by a signal 11 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:746]: handle_sigs(): core was not generated Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:743]: handle_sigs(): child process 11699 exited by a signal 11 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:746]: handle_sigs(): core was not generated Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:743]: handle_sigs(): child process 11700 exited by a signal 11 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:746]: handle_sigs(): core was not generated Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:743]: handle_sigs(): child process 11701 exited by a signal 11 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:746]: handle_sigs(): core was not generated Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:743]: handle_sigs(): child process 11702 exited by a signal 11 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:746]: handle_sigs(): core was not generated Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:743]: handle_sigs(): child process 11703 exited by a signal 11 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:746]: handle_sigs(): core was not generated Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:743]: handle_sigs(): child process 11704 exited by a signal 11 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:746]: handle_sigs(): core was not generated Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:743]: handle_sigs(): child process 11705 exited by a signal 11 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11718]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 26 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:746]: handle_sigs(): core was not generated Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11718]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 27 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:743]: handle_sigs(): child process 11706 exited by a signal 11 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11718]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 28 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:746]: handle_sigs(): core was not generated Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11718]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 29 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:743]: handle_sigs(): child process 11707 exited by a signal 11 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11718]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 30 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:746]: handle_sigs(): core was not generated Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11718]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 31 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:743]: handle_sigs(): child process 11708 exited by a signal 11 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11718]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 32 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:746]: handle_sigs(): core was not generated Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11718]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 33 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:743]: handle_sigs(): child process 11709 exited by a signal 11 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11718]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 34 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:746]: handle_sigs(): core was not generated Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11718]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 5 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:743]: handle_sigs(): child process 11710 exited by a signal 11 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11718]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 9 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:746]: handle_sigs(): core was not generated Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11718]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 35 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:743]: handle_sigs(): child process 11711 exited by a signal 11 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11718]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 37 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:746]: handle_sigs(): core was not generated Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11718]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 39 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:743]: handle_sigs(): child process 11712 exited by a signal 11 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11718]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 41 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:746]: handle_sigs(): core was not generated Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11718]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 43 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:743]: handle_sigs(): child process 11713 exited by a signal 11 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11718]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 45 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:746]: handle_sigs(): core was not generated Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11718]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 47 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:743]: handle_sigs(): child process 11714 exited by a signal 11 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:746]: handle_sigs(): core was not generated Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:743]: handle_sigs(): child process 11715 exited by a signal 11 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:746]: handle_sigs(): core was not generated Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:743]: handle_sigs(): child process 11716 exited by a signal 11 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:746]: handle_sigs(): core was not generated Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:743]: handle_sigs(): child process 11717 exited by a signal 11 Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: ALERT: <core> [main.c:746]: handle_sigs(): core was not generated Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: INFO: <core> [main.c:768]: handle_sigs(): terminating due to SIGCHLD Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11718]: INFO: <core> [main.c:823]: sig_usr(): signal 15 received Dec 28 04:44:14 sipserver /usr/local/sbin/kamailio[11687]: INFO: <core> [core/sctp_core.c:53]: sctp_core_destroy(): SCTP API not initialized Dec 28 04:44:14 sipserver systemd[1]: kamailio.service: main process exited, code=exited, status=1/FAILURE Dec 28 04:44:14 sipserver systemd[1]: Unit kamailio.service entered failed state. As I tried googling the issue and found few issues with tls connection. I set in default kamailio.cfg but still facing the saem issue. enable_tls=no ... loadmodule "ndb_mongodb.so" modparam("ndb_mongodb", "server", "name=cgr91rc8;uri='mongodb://localhost/kamailio'") Its mongodb default installation and its accessible without any auth yet. Please suggest the way farward. -- regards, abdul basit

3 6

In failure_route after t_drop and t_relay - cancel problem
by voipspace voipspace 02 Jan '18

02 Jan '18

2 2

does kamailio ims support mrfc&mrfp？
by zhang kevin 02 Jan '18

02 Jan '18

hi, dear all, i am a start user of kamailio and have a question listed in the title. if kamailio does not support mrfc and mrfp, how kamailio play the proper ring tone to the calling party? thx! from 张勇zhangyong:kevin

2 1

error when brining up scscf in kamailio 5.1
by Abdelmuhaimen Seaudi 01 Jan '18

01 Jan '18

Hi, After configuring scscf.cfg + kamailio.cfg + scscf.xml, I cannot start scscf, as I get the below error " can't bind presence" I tried commenting out the lines loading the presence module, but it seems this is not relevant. How can I try troubleshoot this issue ? Dec 31 17:22:55 olc-dd scscf[6659]: DEBUG: <core> [core/sr_module.c:982]: init_mod(): ims_usrloc_scscf Dec 31 17:22:55 olc-dd scscf[6659]: INFO: ims_usrloc_scscf [hslot.c:69]: ul_init_locks(): locks array size 512 Dec 31 17:22:55 olc-dd scscf[6659]: INFO: ims_usrloc_scscf [contact_hslot.c:67]: init_contacts_locks(): locks array size 512 Dec 31 17:22:55 olc-dd scscf[6659]: INFO: ims_usrloc_scscf [hslot_sp.c:70]: subs_init_locks(): locks array size 512 Dec 31 17:22:55 olc-dd scscf[6659]: DEBUG: <core> [core/sr_module.c:714]: find_mod_export_record(): export of <bind_presence> not found (flags 0) Dec 31 17:22:55 olc-dd scscf[6659]: ERROR: ims_usrloc_scscf [ims_usrloc_scscf_mod.c:292]: mod_init(): can't bind presence Dec 31 17:22:55 olc-dd scscf[6659]: ERROR: <core> [core/sr_module.c:984]: init_mod(): Error while initializing module ims_usrloc_scscf (/usr/local/lib64/kamailio/modules/ims_usrloc_scscf.so) Dec 31 17:22:55 olc-dd scscf[6659]: DEBUG: debugger [debugger_api.c:1267]: dbg_destroy_mod_levels(): Destroyed _dbg_mod_table, size 32 Dec 31 17:22:55 olc-dd scscf[6659]: DEBUG: cdp_avp [cdp_avp_mod.c:224]: cdp_avp_destroy(): Destroying module cdp_avp Dec 31 17:22:55 olc-dd scscf[6659]: INFO: cdp [cdp_mod.c:257]: cdp_exit(): CDiameterPeer child stopping ... Dec 31 17:22:55 olc-dd scscf[6659]: INFO: cdp [diameter_peer.c:364]: diameter_peer_destroy(): destroy_diameter_peer(): Terminating all children... Dec 31 17:22:55 olc-dd scscf[6659]: INFO: cdp [diameter_peer.c:383]: diameter_peer_destroy(): destroy_diameter_peer(): All processes terminated. Cleaning up. Abdelmuhaimen Seaudi, CCIE # 25265 Email: aseaudi(a)gmail.com Skype: aseaudi LinkedIn: www.linkedin.com/in/aseaudi Telephone: +2012 84644 733

1 1

error when creating scscf database in kamailio 5.1
by Abdelmuhaimen Seaudi 01 Jan '18

01 Jan '18

Hi, i am upgrading from kamailio 4.x to 5.1, and when i try to create the scscf databse, i get the below error I tried correcting this by removing the indexes, but the ims did not work properly, with lots of inconsistency in registering, and cannot make calls. what is the correct way to handle this error ? root@olc-dd:/usr/local/src/kamailio-5.1/kamailio/utils/kamctl/mysql# mysql -uroot scscf < ims_usrloc_scscf-create.sql ERROR 1071 (42000) at line 2: Specified key was too long; max key length is 767 bytes Thanks. Abdelmuhaimen Seaudi, CCIE # 25265 Email: aseaudi(a)gmail.com Skype: aseaudi LinkedIn: www.linkedin.com/in/aseaudi Telephone: +2012 84644 733

1 1

error running icscf module on kamailio 4.4
by Abdelmuhaimen Seaudi 31 Dec '17

31 Dec '17

Hi, After setting up IMS components on kamailio 4.4, i get the following error when IMS client tries to register, what is this error, how can i correct it ? 1(14194) ERROR: <core> [sr_module.c:1766]: get_int_fparam(): Unexpected param type: 1280329042 1(14194) ERROR: ims_icscf [registration.c:78]: I_perform_user_authorization_request(): no int value param passed Abdelmuhaimen Seaudi, CCIE # 25265 Email: aseaudi(a)gmail.com Skype: aseaudi LinkedIn: www.linkedin.com/in/aseaudi Telephone: +2012 84644 733

2 1

error running icscf in kamailio 4.4
by Abdelmuhaimen Seaudi 31 Dec '17

31 Dec '17

Hi, After setting up IMS components on kamailio 4.4, i get the following error when IMS client tries to register, what is this error, how can i correct it ? 1(14194) ERROR: <core> [sr_module.c:1766]: get_int_fparam(): Unexpected param type: 1280329042 1(14194) ERROR: ims_icscf [registration.c:78]: I_perform_user_authorization_request(): no int value param passed Abdelmuhaimen Seaudi, CCIE # 25265 Email: aseaudi(a)gmail.com Skype: aseaudi LinkedIn: www.linkedin.com/in/aseaudi Telephone: +2012 84644 733

1 0

Bind IP to Kamailio without restart
by Duarte Rocha 29 Dec '17

29 Dec '17

Greetings, I want to add a new IP to eht0 in my proxy and i want Kamailio to be able to listen to it without me having to restart it. I already have the "listen" parameter set to listen=udp:eth0:5060. Is there any way to reload this parameter it in runtime in order to include the new ip? Is there any alternative to this ? Thanks in advance. Cheers

2 1

PCSCF Access denied issue
by Kranti Kumar 29 Dec '17

29 Dec '17

Hi All, We are using *Kamailio IMS VM* image and we are able to run HSS(/hss.sh) successfully. But while running PCSCF (kamailio -f /usr/local/etc/kamailio/kamailio-pcscf.cfg), we are getting below errors. 0(1772) DEBUG: <core> [db.c:209]: db_bind_mod(): using db bind api for db_mysql 0(1772) DEBUG: <core> [db.c:314]: db_do_init2(): connection 0x7f208368d1b8 not found in pool 0(1772) DEBUG: db_mysql [km_my_con.c:98]: db_mysql_new_connection(): opening co nnection: mysql://xxxx:xxxx@server.net1.test/pcscf 0(1772) ERROR: db_mysql [km_my_con.c:124]: db_mysql_new_connection(): driver er ror: Access denied for user 'pcscf'@'pcscf.net1.test' (using password: YES) 0(1772) ERROR: <core> [db.c:318]: db_do_init2(): could not add connection to the pool 0(1772) ERROR: ims_usrloc_pcscf [usrloc_db.c:79]: init_db(): unable to co nnect to the database 0(1772) ERROR: ims_usrloc_pcscf [ul_mod.c:203]: mod_init(): Error initializing db connection 0(1772) ERROR: <core> [sr_module.c:962]: init_mod(): Error while initializing module ims_usrloc_pcscf (/usr/local/lib64/kamailio/modules/ims_usrloc_pcscf.so) ERROR: error while initializing modules To fix the above error, we tried below commands *mysql -u root -p GRANT ALL ON *.* TO root IDENTIFIED BY 'root'; quit* - replace bind-address in /etc/mysql/my.cnf to 0.0.0.0 But still we are getting the same issue. Could any one please help us to resolve this issue. Could any one please guide us the troubleshooting steps. Thank you so much in advance. Regards, -kranti

4 6

Trying to fail a call over after 200 OK
by iTalk IP Support Department 28 Dec '17

28 Dec '17

Hi Everyone: I would appreciate your insight regarding a problem we are trying to solve. We are using Kamailio (4.1.8) along with multiple asterisk (13 and above) clusters for various telephony features. We are using the dispatcher module to send calls to the asterisk clusters in round robin and failover algorithms. We need a solution to fail a call and hand it over to another asterisk server after Kamailio has received a 200OK from Asterisk server A. I understand the failover works before the 200OK is sent from asterisk A and calls can easily be sent to asterisk B but again the challenge here to fail the call over to another asterisk server after a 200OK is received from the first one. If this is impossible I was wondering if refer and re-direct is an option to get this done. Thanks in advance for looking at this and for your responses.

2 1

Handling redirect replies and send to new host
by voipspace voipspace 28 Dec '17

28 Dec '17

Hi I am aiming to do the following User calls to Kamailio Switch (A) Switch (A) calls to Kamailio redirect server (B).. (B) runs script to determine route (B) sends Stateless 300 redirect reply to (A). (A) sends ACK to (B). (A) send user call to another host (extracted from header variable from redirect reply) (A) call to (B) rewritehost("x.x.x.x"); t_relay(); (A) On receipt of the 300 response I do not want this redirect to go back to the user. onreply_route { if (t_check_status("3[0-9][0-9]")) { // How do I send ACK to (B) to finish this redirect ? // Then I want a new relay to the host. How would I do it ? } }

3 2

PUBLISH modification.
by Володимир Іванець 27 Dec '17

27 Dec '17

Hello! I am trying to modify PUBLISH packet before handle_publish function execution. The best what I could think of is to make all required changes, update Destination URI to the Kamailio itself and then send it. In this case Kamailio will receive another PUBLISH packet with modified values. I was wondering someone knows cleaner way of achieving this. Thanks!

2 2

How to send "bye" to caller when callee abruptly terminates (Connection reset by peer)
by Pranathi Venkatayogi 26 Dec '17

26 Dec '17

Hi, Currently when callee abruptly closes the connection (TCP RST), Kamailio does not send “BYE” to the caller. Caller is left to believe that he is talking to the callee. What is best way to solve this? I have attempted using tcpops module to track connection RSTs and then send $dlg_bye in event_route[tcp:reset] . In the event_route, I can access only these - $conid , $Ri , $Rp , $si , $sp and $proto variable and do not know how to get to the dlg this connection belongs. Questions: How do I load the dialog associated with this conid? Is there a way to enumerate all dialogs? Thanks in advance, Pranathi.

2 2

Module dispatcher no
by Евгений Голей 26 Dec '17

26 Dec '17

Hello! Sorry for English, I know only Russian . There was a situation when it is necessary to control 1 IP address of the remote gateway from different sockets to kamailio. This is necessary to provide a backup bypass to a remote gateway through two independent Internet providers. Previously, I used the dispatcher module, but in this situation it did not help, I want to understand it the way it should or it's a bug. Here are the settings ------------(PROV-1)----------------\ / \ / (socket:udp:Y1.Y1.Y1.Y1:7060) Remote GW (sip:A1.A1.A1.A1:5060)------ (INTERNET) KAMAILIO \ (socket:udp:X1.X1.X1.X1:7060) \ / -----------(PROV-2)------------------/ kamailio.cfg ... loadmodule "dispatcher.so" ################################################################# modparam("dispatcher", "db_url", "mysql://root:@localhost/kamailio510") modparam("dispatcher", "dst_avp", "$avp(test)") modparam("dispatcher", "flags", 2) modparam("dispatcher", "ds_ping_method", "OPTIONS") modparam("dispatcher", "ds_ping_interval", 30) modparam("dispatcher", "ds_probing_threshold", 1) modparam("dispatcher", "ds_inactive_threshold", 2) modparam("dispatcher", "ds_probing_mode", 1) List gw dispatcher ]# kamcmd dispatcher.list { NRSETS: 1 RECORDS: { SET: { ID: 1 TARGETS: { DEST: { URI: sip:A1.A1.A1.A1:5060 FLAGS: AP PRIORITY: 2 ATTRS: { BODY: socket=udp:Y1.Y1.Y1.Y1:7060 DUID: MAXLOAD: 0 WEIGHT: 0 RWEIGHT: 0 SOCKET: udp:Y1.Y1.Y1.Y1:7060 } } DEST: { URI: sip:A1.A1.A1.A1:5060 FLAGS: AP PRIORITY: 1 ATTRS: { BODY: socket=udp:X1.X1.X1.X1:7060 DUID: MAXLOAD: 0 WEIGHT: 0 RWEIGHT: 0 SOCKET: udp:X1.X1.X1.X1:7060 } } } } } } Result if the remote gateway is not accessible through the network of the provider 2 (udp:X1.X1.X1.X1:7060), for the unknown reason the status of the first record, which corresponds to the provider 1 (udp:Y1.Y1.Y1.Y1:7060), changes. There are no errors with sockets, OPTIONS packages are sent and a response of 200 OK from the provider is received. 1. OPTIONS requests are sent through provider 2, but there are no answers. But the status changes for some reason at the first. # kamcmd dispatcher.list { NRSETS: 1 RECORDS: { SET: { ID: 1 TARGETS: { DEST: { URI: sip:A1.A1.A1.A1:5060 FLAGS: IP PRIORITY: 2 ATTRS: { BODY: socket=udp:Y1.Y1.Y1.Y1:7060 DUID: MAXLOAD: 0 WEIGHT: 0 RWEIGHT: 0 SOCKET: udp:Y1.Y1.Y1.Y1:7060 } } DEST: { URI: sip:A1.A1.A1.A1:5060 FLAGS: AP PRIORITY: 1 ATTRS: { BODY: socket=udp:X1.X1.X1.X1:7060 DUID: MAXLOAD: 0 WEIGHT: 0 RWEIGHT: 0 SOCKET: udp:X1.X1.X1.X1:7060 } } } } } } At testing it was found out, that камаилио does not allow to supervise a condition at use my circuit. I tried on 5.0.3 and on 5.1.0 the dispatcher works similarly. Please help with advice. Best regards Evgeniy

1 0

Multiple Kamailio Servers + Location Table
by Daniel W. Graham 26 Dec '17

26 Dec '17

When multiple Kamailio servers are using the same database with different server_id's (one active the rest standby in this test), records disappear and are no longer tracked in location database table. Some entries remain, but it never populates to the normal amount unless only one server is using the database. Anyone run into this before? Happened with 5.0 and is happening with 5.1. -dan

4 7

Dispatcher module OPTIONS and event routes: how are they handled by core?
by George Diamantopoulos 21 Dec '17

21 Dec '17

Hello all, I use the dispatcher module extensively for load balancing and fail-over. My kamailio instance is multihomed, and I use the "socket" attribute to determine which socket SIP messages should use for each dispatcher destination, as such: +----+-------+-------------------------+-------+----------+-----------------------------+ | id | setid | destination | flags | priority | attrs | +----+-------+-------------------------+-------+----------+-----------------------------+ | 1 | 0 | sip:192.168.0.1:5060 | 8 | 0 | socket=udp: 10.10.10.1:5060 | | 2 | 1 | sip:111.111.11.1:5060 | 8 | 0 | socket=udp: 44.44.44.1:5060 | | 3 | 1 | sip:222.222.22.2:5060 | 8 | 0 | socket=udp: 55.55.55.1:5060 | +----+-------+-------------------------+-------+----------+-----------------------------+ The dispatcher module uses OPTIONS to probe each destination for availability. When a destination goes down or up, the respective event-route is executed. What I need to do is to be able to "capture" the sending socket used for this probing when a destination becomes unavailable or available in the event-routes. The $fs variable is set, but unfortunately its value does not make sense. Here's an example route and the results that are printed: event_route[dispatcher:dst-down] { xlog("L_ERR", "Destination down: $rm $ru ($du) $ds $fs $Ru $T_req($fs) $T_req($Ru)\n"); } Now say destination with id = '2' goes down. This is what I get in the logs for the event_route above: ERROR: <script>: Destination down: OPTIONS sip:111.111.11.1:5060 (sip: 192.168.0.1:5060) Contact: <sip:111.111.11.1:5060> udp:10.10.10.1:5060 <null> <null> <null> The xlog PV/log mapping for the above line is the following: $rm: OPTIONS $ru: sip:111.111.11.1:5060 $du: sip:192.168.0.1:5060 $ds: Contact: <sip:111.111.11.1:5060> $Ru: udp:10.10.10.1:5060 The rest are $null. $ru and $ds are consistent with the actual destination being probed, $du and $fs are not (the are set to values corresponding to id = '1', for some reason). This log line is, of course, inaccurate. Not only does it not make sense, but also this is not consistent with messages captured on network interfaces using sngrep: Kamailio does indeed behave as it should, the OPTIONS is sent out to 111.111.11.1 from socket udp:44.44.44.1:5060. But this is not reflected in the log entry above when the event_route is executed. Now the weird part is that this OPTIONS "transaction" (which is locally generated by kamailio) has the $du PV set to the value of another destination (namely the that of id = '1'). As a result, the $fs PV is consistent with that choice for $du. I can verify with sngrep that this is not the case in reality, as the request was sent to destination id = '2' from the correct socket as indicated above. What I would like to ask is whether these "OPTIONS" used by dispatcher for probing go through the request_route processing at some point. This is the only way that would explain the $du PV being set to a false value. If yes, is there any way to prevent this from happening? I need to be able to access the $fs PV when a destination goes up or down, and I can't have any other configuration file routes interfering with that. Thanks! Best regards, George

2 4

strange --dialog in delete state is too old-- log line managing dialog hashes
by David Escartín 21 Dec '17

21 Dec '17

hello all recently we are seeing some weird messages handling with dialogs in Kamailio version 5.0 we sometimes are seeing messages like /usr/local/kamailio/sbin/kamailio[15372]: NOTICE: dialog [dlg_hash.c:249]: dlg_clean_run(): dialog in delete state is too old (0x7fa65445c850 ref 3) /usr/local/kamailio/sbin/kamailio[15372]: NOTICE: dialog [dlg_hash.c:235]: dlg_clean_run(): dialog in early state is too old (0x7fa652d57110 ref 1) we increased the debug description adding some lines to the dialog module code so we could track the calls of the calls that these messages belong to, and we could see that those messages appeared in calls just released at that moment, for example: <134>Nov 4 11:21:38 localhost /usr/local/kamailio/sbin/kamailio[4108]: INFO: mad-localhost-1 Call 97980 / Call-ID 1409565771_82382809(a)195.219.240.46: Creating dialog [8043:21772] with hash id 21772 and hash entry 8043 <134>Nov 4 11:21:38 localhost /usr/local/kamailio/sbin/kamailio[4106]: INFO: mad-localhost-1 Call 97980 / Call-ID 1409565771_82382809(a)195.219.240.46: Status 100, 6610 <134>Nov 4 11:21:39 localhost /usr/local/kamailio/sbin/kamailio[4111]: INFO: mad-localhost-1 Call 97980 / Call-ID 1409565771_82382809(a)195.219.240.46: CANCEL received in A-Leg, relaying downstream <134>Nov 4 11:21:39 localhost /usr/local/kamailio/sbin/kamailio[4112]: INFO: mad-localhost-1 Call 97980 / Call-ID 1409565771_82382809(a)195.219.240.46: Status 487, 6610 <133>Nov 4 11:21:39 localhost /usr/local/kamailio/sbin/kamailio[4139]: NOTICE: dialog [dlg_hash.c:251]: dlg_clean_run(): dialog in delete state is too old (0x7fa0c02a6870 ref 3) with callid '1409565771_82382809(a)195.219.240.46' <129>Nov 4 11:21:39 mad-proxy-inout-1 /usr/local/kamailio/sbin/kamailio[4112]: ALERT: dialog [dlg_handlers.c:1715]: dlg_run_event_route(): after event route - dialog not found [8043:21772] (1/5) (0x7fa0c02a6870) with callid '1409565771_82382809(a)195.219.240.46' we printed the dialog id and entry hash values and we can see there are no other calls creating same values in the previous hours, or using same memory allocation, or same callid, so it seems like there was some kind of strange issue with the dialog timers....¿? By the way, this is happening only few times (80-100 times) a day having many thousands of calls, so it's quite difficult for us to duplicate, we couldn't do it until now. We also tried to use the timer_procs 0 or 1 to use a different proc timer but seems the issue happens in both scenarios. The configuration change we made and seems it was done when these messages started to appear is to use dialog event_route when ended and failed to do some stuff there managing some dialog variables. Does ti make any sense that attempting to use those variables could cause these behaviour? Do you have any idea about it could be or how we can check it deeper? thanks a lot and regards david escartin

2 9

How to add new user to Kamailio using PHP shell_exec?
by Arun NV 21 Dec '17

21 Dec '17

There is a requirement to add a new user to *Kamailio* programmatically using *PHP*. I tried to add username and password to *subscriber* table manually using *SQL* queries, but it won't works because *ha1* and *ha1b* should be added to the table. I don't know how Kamailio generate *ha1* and *ha1b*. Following are the manually added entries using *kamctl* tool. mysql> select * from subscriber limit 2; +----+----------+---------------+--------------+---------------+----------------------------------+----------------------------------+------+ | id | username | domain | password | email_address | ha1 | ha1b | rpid | +----+----------+---------------+--------------+---------------+----------------------------------+----------------------------------+------+ | 9 | 1010101 | 10.101.101.10 | aswwwwwwwsdf | | a37d1785953310c206481ca1a33f16b6 | 7e981130f05a547a738d3c29031e89d0 | NULL | | 10 | 1010102 | 10.101.101.10 | 6eeeeee8a72 | | 6b574f9047206481ca1a33501d7dbdce | cd9a8b89d926f3cb1290311a8cb8a2a8 | NULL | +----+----------+---------------+--------------+---------------+----------------------------------+----------------------------------+------+ Then I tried with *shell_exec* function in *PHP* to use *kamctl* command(*kamctl add username password*). but it will prompt for *Kamailio* read-write user's password. So following command cannot add new users to Kamailio $res = shell_exec("sudo kamctl add new_username new_password); so, please suggest a way to add new user's to *Kamailio* programmatically. <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> Virus-free. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

3 2

4.4.4 CPU 100%
by Tomas Zanet 21 Dec '17

21 Dec '17

Hi all, I’ve been using Kamailio 4.4.4 for 8 months without any problems but in recent days, I’m having some issues with our server and, when it happens, it cannot get new registrations. Using top I saw a kamailio process is eating all CPU. PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1556 kamailio 20 0 1010884 27624 24520 R 98.5 1.4 150:07.59 kamailio I got backtrace attaching to Kamailio with gdb. Here is the backtrace: #0 0x00007fb996992d6d in accept () at ../sysdeps/unix/syscall-template.S:81 #1 0x00000000005f3615 in handle_new_connect (si=0x7fb9960b4fa8) at tcp_main.c:3894 #2 0x00000000005f7029 in handle_io (fm=0x7fb9961da520, ev=1, idx=-1) at tcp_main.c:4199 #3 0x00000000005c68b2 in io_wait_loop_epoll (h=0xa1fdc0 <io_h>, t=5, repeat=0) at io_wait.h:1065 #4 0x00000000005fa04a in tcp_main_loop () at tcp_main.c:4490 #5 0x00000000004b48ba in main_loop () at main.c:1712 #6 0x00000000004bad12 in main (argc=13, argv=0x7ffd14247c18) at main.c:2631 (gdb) bt At the moment I found the issue, there were 862 sip client registered correctly. Our server is configured to use only TLS and mysql as backend. /usr/local/sbin/kamailio -v version: kamailio 4.4.4 (x86_64/linux) 852c47 flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: 852c47 compiled on 15:56:18 Dec 15 2016 with gcc 4.8.4 Can anyone address me to find out why this happens? Many thanks, T. Tomas Zanet R&D Software designer tzanet(a)came.com CAME S.p.A.

2 2

Kamailio-IMS VM image issue
by Kranti Kumar 20 Dec '17

20 Dec '17

Hi, I’m trying to build a testbed using the VMware image you kindly have shared here: https://www.kamailio.org/w/2016/02/kamailio-ims-getting-started-box/ <https://clicktime.symantec.com/a/1/vpQmnO-RuJyqB1aW492eOeLkb1WD1yyoCCaN-pca…> My configuration details: HSS - 10.200.8.171 (VM1) PCSCF - 10.200.8.175 (VM2) ICSCF - 10.200.8.178 (VM3) SCSCF - 10.200.8.181 (VM4) While issuing the command ./hss.sh and kamailio -f /usr/local/etc/kamailio/kamailio-pcscf.cfg I am getting errors. Please find the attached log file for the same. "0(1786) ERROR: db_mysql [km_my_con.c:124]: db_mysql_new_connection(): driver error: Access denied for user 'pcscf'@'pcscf.net1.test' (using password: YES) 0(1786) ERROR: <core> [db.c:318]: db_do_init2(): could not add connection to the pool 0(1786) ERROR: ims_usrloc_pcscf [usrloc_db.c:79]: init_db(): unable to connect to the database 0(1786) ERROR: ims_usrloc_pcscf [ul_mod.c:203]: mod_init(): Error initializing db connection" I am doubting about my Zone files. Could you please check zone file once. Please find the attached zone files. Thank you so much in advance Regards, -kranti

3 6

PIPELIMIT - limit change after time interval change. bug?
by Juan Priotti 20 Dec '17

20 Dec '17

Hi, I'm making some tests with pipelimit module and when changing the time interval the limit gets changed in a way that it's multiplied by the time interval. For example if I use a time interval of 1 second and a limit of 20 (if (!pl_check("$si", "TAILDROP", "20"))) the module start limiting right after the traffic gets over 20 CPS. But if I change the time interval to 3 seconds, the module starts limiting the traffic right after 60 CPS. This is my configuration: # ----- pipelimit params----- modparam("pipelimit", "timer_interval", 3) modparam("pipelimit", "hash_size", 10) modparam("pipelimit", "db_url", DBURL) modparam("pipelimit", "reply_code", 503) modparam("pipelimit", "reply_reason", "Limiting") ... ... ... request_route { ... ... if(is_method("INVITE")) { $var(limit) = 20; if (!pl_check("$si", "TAILDROP", "$var(limit)")) { xlog("L_INFO", "[$ci] $si - Limiting INVITE using pipe $var(limit) req/sec\n"); pl_drop(); exit; } ..... ..... ..... } } Checking the source for pipelimit module ( https://github.com/kamailio/kamailio/blob/master/src/modules/pipelimit/pipe…) I see that for taildrop it's checking for the limit times the time_interval: case PIPE_ALGO_TAILDROP: ret = (pipe->counter <= pipe->limit * timer_interval) ? 1 : -1; break; I've made a change eliminating the time_interval (set it to 1) from that check and after that I've got the limit working OK, and the traffic gets drop right after it's over the limit (20 cps) using any time_interval. Is there some issue with the timer for the check not being updated by the module settings (timer_interval)? I'm using kamailio 4.4 and I've also tested it in kamailio 4.3 and 5.1 with same results. Thanks in advance, Juan Priotti

2 1

dmq_usrloc, usrloc:db_mode 3, and PostgreSQL
by Alex Balashov 19 Dec '17

19 Dec '17

Hi, Running bleeding-edge branch 5.1 clone here. dmq_usrloc replication works fine when using in-memory only backing for the underlying usrloc module, i.e. db_mode 0. I haven't tried mode 1 and mode 2. I use mode 3, so that contacts are immediately persisted straight to a local database. The database flavour is PostgreSQL in this case. When new contacts replicated via dmq_usrloc come in, I get this in the Kamailio log: Dec 15 19:23:35 evaristesys-testbed-2 /usr/local/sbin/kamailio[9395]: ERROR: <core> [db.c:465]: db_use_table(): invalid parameter value Dec 15 19:23:35 evaristesys-testbed-2 /usr/local/sbin/kamailio[9395]: ERROR: usrloc [udomain.c:817]: db_load_urecord_by_ruid(): failed to use table location Dec 15 19:23:35 evaristesys-testbed-2 /usr/local/sbin/kamailio[9395]: WARNING: dmq_usrloc [usrloc_sync.c:147]: delete_contact(): AOR/Contact not found Dec 15 19:23:35 evaristesys-testbed-2 /usr/local/sbin/kamailio[9395]: ERROR: <core> [db.c:465]: db_use_table(): invalid parameter value Dec 15 19:23:35 evaristesys-testbed-2 /usr/local/sbin/kamailio[9395]: ERROR: usrloc [udomain.c:817]: db_load_urecord_by_ruid(): failed to use table location Dec 15 19:23:35 evaristesys-testbed-2 /usr/local/sbin/kamailio[9395]: WARNING: dmq_usrloc [usrloc_sync.c:147]: delete_contact(): AOR/Contact not found I added some code to lib/srdb1/db.c to print the parameter name and the location being passed to db_use_table(): */ int db_use_table(db1_con_t* _h, const str* _t) { + LM_ERR("DB handle = %p\n", _h); + if (!_h || !_t || !_t->s) { - LM_ERR("invalid parameter value\n"); + LM_ERR("invalid parameter value %.*s\n", _t->len, _t->s); return -1; } And got this: Dec 15 19:23:36 evaristesys-testbed-2 /usr/local/sbin/kamailio[9395]: ERROR: <core> [db.c:462]: db_use_table(): DB handle = (nil) Dec 15 19:23:36 evaristesys-testbed-2 /usr/local/sbin/kamailio[9395]: ERROR: <core> [db.c:465]: db_use_table(): invalid parameter value location Dec 15 19:23:36 evaristesys-testbed-2 /usr/local/sbin/kamailio[9395]: ERROR: usrloc [udomain.c:631]: db_load_urecord(): failed to use table location Dec 15 19:23:36 evaristesys-testbed-2 /usr/local/sbin/kamailio[9395]: ERROR: <core> [db.c:462]: db_use_table(): DB handle = (nil) Dec 15 19:23:36 evaristesys-testbed-2 /usr/local/sbin/kamailio[9395]: ERROR: <core> [db.c:465]: db_use_table(): invalid parameter value location Dec 15 19:23:36 evaristesys-testbed-2 /usr/local/sbin/kamailio[9395]: ERROR: usrloc [ucontact.c:679]: db_insert_ucontact(): sql use_table failed Dec 15 19:23:36 evaristesys-testbed-2 /usr/local/sbin/kamailio[9395]: ERROR: usrloc [urecord.c:582]: insert_ucontact(): failed to insert in database So, it appears the DB handle being passed here is NULL is in this situation. The same AOR is present in 'ul.dump' RPC command when using db_mode 0. Please advise? :) -- Alex -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/

3 15

Kamailio v5.0.5 Released
by Daniel-Constantin Mierla 19 Dec '17

19 Dec '17

Hello, Kamailio SIP Server v5.0.5 stable release is out. This is a maintenance release of the previous stable branch, 5.0, that includes fixes since the release of v5.0.4. There is no change to database schema or configuration language structure that you have to do on previous installations of v5.0.x. Deployments running previous v5.0.x versions are strongly recommended to be upgraded to v5.0.5 or v5.1.0. For more details about version 5.0.5 (including links and guidelines to download the tarball or from GIT repository), visit: * https://www.kamailio.org/w/2017/12/kamailio-v5-0-5-released/ RPM, Debian/Ubuntu packages will be available soon as well. Note: the latest stable branch is 5.1, at this moment with its latest release v5.1.0. See more details about it at: * https://www.kamailio.org/w/kamailio-v5-1-0-release-notes/ Many thanks to all contributing and using Kamailio! Cheers, Daniel -- Daniel-Constantin Mierla www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - www.asipto.com Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com

1 0

Planning Kamailio v5.0.5
by Daniel-Constantin Mierla 19 Dec '17

19 Dec '17

Hello, I am considering to release in the near future a new version from branch 5.0, respectively v5.0.5, a candidate day being next week, on Tuesday, December 19, 2017. If you are aware of any issue in branch 5.0 which is not yet reported on github.com/kamailio/kamailio issues tracker, then do it as soon as possible to have a chance to look at it. Cheers, Daniel -- Daniel-Constantin Mierla www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - www.asipto.com Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com

1 1

Do configuration script file comes under GPL License?
by Seshu Kumar G 18 Dec '17

18 Dec '17

> > Hello Everyone, > We are using only modifying Kamailio configuration files (In IMS application), to tune to our application, without modifying any underlying software. Does configuration script files comes under GPL License? regards GS Kumar

2 1

Fwd: ACK issue TCP in NATed network
by Seshu Kumar 18 Dec '17

18 Dec '17

Hello Everyone, Can someone kindly answer my query below, i am stuck up badly. regards GS Kumar On Wed, Dec 13, 2017 at 12:47 PM, Seshu Kumar <gskumar12345(a)gmail.com> wrote: > Hello Everyone, > > We are using Kamailio IMS (version 5.0.4). We are using Jitsi for making > calls. > Our SIP clients are behind NATed network. > When clients and P-Server is configured to UDP mode, we are able to make > calls sucessfully. > When clients and P-Server is configured to TCP mode, call is not getting > through. > > From logs I found that ACK is not being sent from P-Server to Client. > > On googling i found that this is known problem. > > > Can anyone kindly clarify whether this problem is resolved? > Is there is work around. > Am i not setting any parameter properly? > Let us know if further information is needed. > > Kindly some answer, we are newbies... :) > > Regards > GS Kumar >

2 1

5.0 to 5.1 - No module matching <geoip2> found
by Daniel W. Graham 18 Dec '17

18 Dec '17

Upgraded two installs to 5.1. * Same cfg file from 5.0 * No issues with install 1 Install 2 results in: ERROR: <core> [core/modparam.c:152]: set_mod_param_regex(): No module matching <geoip2> found CRITICAL: <core> [core/cfg.y:3450]: yyerror_at(): parse error in config file /usr/local/etc/kamailio/kamailio.cfg, line 343, column 71: Can't set module parameter ERROR: <core> [core/sr_module.c:582]: load_module(): could not open module </usr/local/lib64/kamailio/modules/geoip2.so>: libmaxminddb.so.0: cannot open shared object file: No such file or directory CRITICAL: <core> [core/cfg.y:3447]: yyerror_at(): parse error in config file /usr/local/etc/kamailio/kamailio.cfg, line 122, column 12-22: failed to load module WARNING: <core> [core/ppcfg.c:221]: pp_ifdef_level_check(): different number of preprocessor directives: N(#!IF[N]DEF) - N(#!ENDIF) = 1 ls -l /usr/local/lib64/kamailio/modules/ | grep geo -rwxr-xr-x 1 root root 73800 Dec 14 12:44 geoip2.so If I copy cfg file from install 2 to install 1, no issues with install 1. Any idea what could be going wrong? - dan

3 8

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 December 2017