- sr-users - kamailio.org

two Kamailio instances suddenly stopped handling packets
by Sebastian Damm 15 Jan '18

15 Jan '18

Hi, this morning, two Kamailio servers suddenly stopped working after having worked without a problem for months. Both are running 5.0.2 on Debian Jessie. Those systems only analyze mirrored traffic and write some information to a RabbitMQ. I tried restarting, but after a few seconds they get stuck the same way as before. Then I attached a gdb to some of the UDP listeners, and they all look pretty much the same. ===========8< process 1 ================= (gdb) bt #0 0x00007f404ca435b9 in syscall () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x00007f4049f41260 in futex_get (lock=0x7f4041bccd00) at ../../core/parser/../mem/../futexlock.h:108 #2 0x00007f4049f477d7 in cfg_lock_helper (lkey=0x7fff3c048650, mode=0) at cfgutils.c:667 #3 0x00007f4049f481ed in w_cfg_lock_wrapper (msg=0x7f404ba17f18, key=0x7f404ba15488, mode=0) at cfgutils.c:712 #4 0x00007f4049f4823c in w_cfg_lock (msg=0x7f404ba17f18, key=0x7f404ba15488 "\210a\241K@\177", s2=0x0) at cfgutils.c:717 #5 0x000000000045cd85 in do_action (h=0x7fff3c049410, a=0x7f404b9d5170, msg=0x7f404ba17f18) at core/action.c:1060 #6 0x0000000000469afa in run_actions (h=0x7fff3c049410, a=0x7f404b9d5170, msg=0x7f404ba17f18) at core/action.c:1552 #7 0x000000000045958d in do_action (h=0x7fff3c049410, a=0x7f404b9ce558, msg=0x7f404ba17f18) at core/action.c:678 #8 0x0000000000469afa in run_actions (h=0x7fff3c049410, a=0x7f404b9cdf70, msg=0x7f404ba17f18) at core/action.c:1552 #9 0x000000000046a2bd in run_top_route (a=0x7f404b9cdf70, msg=0x7f404ba17f18, c=0x0) at core/action.c:1641 #10 0x0000000000580033 in receive_msg ( buf=0xa393f9 <buf+121> "REGISTER sip:domain SIP/2.0\r\nVia: SIP/2.0/UDP 1.2.3.4;branch=z9hG4bKfc98.c762d7151f110c7eb71fc7d4e0648f1f.0\r\nVia: SIP/2.0/UDP 192.168.0.3:5060 ;rport=38020;received=62.30.8.128;branch=z9hG4"..., len=799, rcv_info=0x7fff3c049810) at core/receive.c:264 #11 0x00007f40483efcdf in parsing_hepv3_message (buf=0xa39380 <buf> "HEP3\003\230", len=920) at hep.c:499 #12 0x00007f40483ee264 in hepv3_received (buf=0xa39380 <buf> "HEP3\003\230", len=920, ri=0x7fff3c049a50) at hep.c:231 #13 0x00007f40483ec9cb in hep_msg_received (data=0x7fff3c049a30) at hep.c:85 #14 0x000000000049e4e1 in sr_event_exec (type=7, data=0x7fff3c049a30) at core/events.c:263 #15 0x000000000048731a in udp_rcv_loop () at core/udp_server.c:466 #16 0x0000000000422d08 in main_loop () at main.c:1623 #17 0x000000000042a408 in main (argc=13, argv=0x7fff3c049ef8) at main.c:2643 (gdb) quit ===========8< process 1 ================= ===========8< process 2 ================= (gdb) bt #0 0x00007f404ca435b9 in syscall () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x00007f4049f41260 in futex_get (lock=0x7f4041bccd00) at ../../core/parser/../mem/../futexlock.h:108 #2 0x00007f4049f477d7 in cfg_lock_helper (lkey=0x7fff3c048650, mode=0) at cfgutils.c:667 #3 0x00007f4049f481ed in w_cfg_lock_wrapper (msg=0x7f404ba17f18, key=0x7f404ba15488, mode=0) at cfgutils.c:712 #4 0x00007f4049f4823c in w_cfg_lock (msg=0x7f404ba17f18, key=0x7f404ba15488 "\210a\241K@\177", s2=0x0) at cfgutils.c:717 #5 0x000000000045cd85 in do_action (h=0x7fff3c049600, a=0x7f404b9d5170, msg=0x7f404ba17f18) at core/action.c:1060 #6 0x0000000000469afa in run_actions (h=0x7fff3c049600, a=0x7f404b9d5170, msg=0x7f404ba17f18) at core/action.c:1552 #7 0x000000000045958d in do_action (h=0x7fff3c049600, a=0x7f404b9cf920, msg=0x7f404ba17f18) at core/action.c:678 #8 0x0000000000469afa in run_actions (h=0x7fff3c049600, a=0x7f404b9ce9c0, msg=0x7f404ba17f18) at core/action.c:1552 #9 0x000000000046a2bd in run_top_route (a=0x7f404b9ce9c0, msg=0x7f404ba17f18, c=0x7fff3c049600) at core/action.c:1641 #10 0x0000000000580a69 in receive_msg ( buf=0xa393f9 <buf+121> "SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP 172.20.40.8;branch=z9hG4bKa69c.5cca5a54c4d270c515eeb4bbb5e0bb44.0\r\nVia: SIP/2.0/UDP 2.3.4.5:5060\r\nContact: <sip:1234567@9.8.7.6:59669;transport=UDP>\r\nTo: "..., len=506, rcv_info=0x7fff3c049810) at core/receive.c:327 #11 0x00007f40483efcdf in parsing_hepv3_message (buf=0xa39380 <buf> "HEP3\002s", len=627) at hep.c:499 #12 0x00007f40483ee264 in hepv3_received (buf=0xa39380 <buf> "HEP3\002s", len=627, ri=0x7fff3c049a50) at hep.c:231 #13 0x00007f40483ec9cb in hep_msg_received (data=0x7fff3c049a30) at hep.c:85 #14 0x000000000049e4e1 in sr_event_exec (type=7, data=0x7fff3c049a30) at core/events.c:263 #15 0x000000000048731a in udp_rcv_loop () at core/udp_server.c:466 #16 0x0000000000422d08 in main_loop () at main.c:1623 #17 0x000000000042a408 in main (argc=13, argv=0x7fff3c049ef8) at main.c:2643 (gdb) quit ===========8< process 2 ================= Looks to me as if Kamailio gets stuck trying to get a lock for this packet. The config file when handling those packets looks like this: request_route { route(initialize_variables); route(foo); } onreply_route { route(initialize_variables); route(foo); } route[initialize_variables] { $vn(bar) = $null; $vn(baz) = $null; $vn(barbaz) = $null; $vn(foobar) = $null; } route[foo] { lock("$ci"); xlog("L_DBG", "Obtained lock, calling lua...\n"); if(!lua_run("handle_packet")) { xlog("L_ERR", "SCRIPT: failed to execute lua function!\n"); } if ($vn(bar) != $null) { route(mediaIpToRedis); } if ($vn(baz) != $null) { route(channelInfoToRedis); } if ($vn(barbaz) != $null) { route(sendToQueue); } xlog("L_DBG", "All finished, releasing lock...\n"); unlock("$ci"); xlog("L_DBG", "Released lock...\n"); # update stats if ($vn(foobar) != $null) { update_stat("$vn(foobar)", "+1"); } drop; exit; } Is there any race condition I am missing? Until this morning, it ran without problems and only every 2 minutes or so, 4 packets were sent to the RabbitMQ. So the system throws away nearly 100% of the traffic (which is around 20 Mbit). In the log file, there are no errors at all, no aborted lua scripts or whatsoever. Does anybody have a hint for me? Thanks in advance. Regards Sebastian

3 5

New Install Homer, No call data stored in DB
by Trent 15 Jan '18

15 Jan '18

Hello. I installed Homer a couple of days ago on new Debian 8 minimal install with HEP configured on Asterisk 14 on another machine. I installed Homer with the quick install script available on Git Hub. As the subject line states, no information is being stored in the daily database tables being created. I have confirmed with tcpdump, the Asterisk 14 machine is sending out data on port 9060. On the Homer side, Kamailio is confirmed listening on port 9060, and tcpdump confirms it is receiving that Asterisk 14 SIP data to port 9060. When starting up Kamailio: In /var/log/messages this is all which is listed (even during calls): Jan 12 11:31:06 Qbox-Homer homer[5815]: INFO: <core> [main.c:810]: sig_usr(): signal 15 received Jan 12 11:31:06 Qbox-Homer homer[5813]: INFO: <core> [main.c:810]: sig_usr(): signal 15 received Jan 12 11:31:06 Qbox-Homer homer[5811]: INFO: <core> [main.c:810]: sig_usr(): signal 15 received Jan 12 11:31:06 Qbox-Homer homer[5801]: INFO: <core> [sctp_core.c:53]: sctp_core_destroy(): SCTP API not initialized Jan 12 11:31:07 Qbox-Homer kamailio: INFO: <core> [sctp_core.c:75]: sctp_core_check_support(): SCTP API not enabled - if you want to use it, load sctp module Jan 12 11:31:07 Qbox-Homer kamailio: WARNING: <core> [socket_info.c:1303]: fix_hostname(): could not rev. resolve 0.0.0.0 Jan 12 11:31:07 Qbox-Homer kamailio: INFO: <core> [tcp_main.c:4665]: init_tcp(): using epoll_lt as the io watch method (auto detected) Jan 12 11:31:07 Qbox-Homer homer[20228]: INFO: sipcapture [sipcapture.c:437]: parse_table_names(): INFO: table name:sip_capture Jan 12 11:31:08 Qbox-Homer homer[20228]: INFO: <core> [udp_server.c:150]: probe_max_receive_buffer(): SO_RCVBUF is initially 212992 Jan 12 11:31:08 Qbox-Homer homer[20228]: INFO: <core> [udp_server.c:200]: probe_max_receive_buffer(): SO_RCVBUF is finally 425984 And here is Kamailio starting at debug level 2 in /var/log/syslog Jan 12 11:44:29 Qbox-Homer systemd[1]: Starting Kamailio (OpenSER) - the Open Source SIP Server... Jan 12 11:44:29 Qbox-Homer kamailio: INFO: <core> [sctp_core.c:75]: sctp_core_check_support(): SCTP API not enabled - if you want to use it, load sctp module Jan 12 11:44:29 Qbox-Homer kamailio: WARNING: <core> [socket_info.c:1303]: fix_hostname(): could not rev. resolve 0.0.0.0 Jan 12 11:44:29 Qbox-Homer kamailio: INFO: <core> [tcp_main.c:4665]: init_tcp(): using epoll_lt as the io watch method (auto detected) Jan 12 11:44:29 Qbox-Homer kamailio[23757]: Listening on Jan 12 11:44:29 Qbox-Homer kamailio[23757]: udp: 0.0.0.0:9060 Jan 12 11:44:29 Qbox-Homer kamailio[23757]: Aliases: Jan 12 11:44:29 Qbox-Homer homer[23759]: INFO: sipcapture [sipcapture.c:437]: parse_table_names(): INFO: table name:sip_capture Jan 12 11:44:29 Qbox-Homer homer[23759]: INFO: <core> [udp_server.c:150]: probe_max_receive_buffer(): SO_RCVBUF is initially 212992 Jan 12 11:44:29 Qbox-Homer homer[23759]: INFO: <core> [udp_server.c:200]: probe_max_receive_buffer(): SO_RCVBUF is finally 425984 Jan 12 11:44:29 Qbox-Homer systemd[1]: Started Kamailio (OpenSER) - the Open Source SIP Server. No more messages appear during, or after a call is terminated. Any more suggestions? Thanks!

3 7

check auth_check return code
by David Villasmil 15 Jan '18

15 Jan '18

Is this possible? I'm trying with: if (auth_check("$fd", "subscriber", "1")==-2) { log something } i'm trying to find out if the username actually exists in the db, but the password provided was wrong... Regards, David Villasmil email: david.villasmil.work(a)gmail.com phone: +34669448337 ᐧ

2 1

send_data keeps connection open
by voipspace voipspace 15 Jan '18

15 Jan '18

Hi I tried send_data it transmits the data however the socket connect remains open. Is it possibe to just send. I dont want the other end to need to close the connect or reply. thanks

2 1

kamailio 4.4.1 DROUTING module memory leak ?
by Uri Shacked 14 Jan '18

14 Jan '18

Hi, I have some kind of memory growth (leak?). kamailio 4.4.1. started with 64M for shmem, had a crash after 5 days of traffic. increased shmem to 128, but still memory grows everyday. when traffic load decrease, the memory growth stops but memory stays on the same level. when traffic increase again,used memory continue to grows again. I started kamailio now with the "-x qm" option to debug shmem. every half hour i dump the status of it. there are several modules that the memory size is increasing (some of them are obvious). but, one is very strange.... DROUTING I am using drouting module for each call on my kamailio. the DB tables are very small, and there is no reloads. only one time used in my script : .. ... subst_user('/(.*)/$avp(xxx)/'); if(!do_routing("$avp(yyyy)")){ xlog...somthing; return(-1) } .. .... the shmem that is rapidly growing and does not make sense is: "from drouting: dr_time.c: ac_get_maxval(219)" seems that when i used mem_join =1, the growth was smaller, but still significant. now i use mem_join = 0, it seems rapidly increasing... I have more information from the logs, will send it if necessary (it is just a lot...) any ideas ? cheers, Uri

2 9

how to check $ua
by David Villasmil 14 Jan '18

14 Jan '18

I'm trying to verify the auth username begins with, i.e. "32", but i'm using in AUTH route: if( !($au=~"32") ){ do something } and that's not working, and i don't get why? Regards, David Villasmil email: david.villasmil.work(a)gmail.com phone: +34669448337 ᐧ

3 2

T_precheck_trans
by Abdelmuhaimen Seaudi 12 Jan '18

12 Jan '18

Hi. In the below part from kamailio.cfg, why didn't we just exit if t_precheck_trans returns true ? Why did we run t_check_trans, although there might be another process already running the other t_check_trans ? # handle retransmissions if (!is_method("ACK")) { if(t_precheck_trans()) { t_check_trans(); exit; } t_check_trans(); }

2 1

Free size of shared memory falls to near zero during the load testing
by Andrey Deykunov 12 Jan '18

12 Jan '18

Hi, We use kamailio as a router in our PBX server. The test below causes significant decreasing of free shared memory and many "out of memory" errors in kamailio log: Preconditions: kamailio server with 256Mb of shared memory allocated. Test actions: run two load testing scripts at the same time: 1) 10000 register operations; 2) 20000 calls (about 300 per sec); Results: 1) memory consumption in peak values: - shmem.free_size: 1.8Mb - core: 120Mb: - build_req_buf_from_sip_req: 12.5Mb - msg_lump_cloner: 23.6Mb - sip_msg_shm_clone: 84Mb - tm module: 118Mb 2) shmem.free_size parameter back to normal after the test, so it could be concluded that we don't have any memory leaks. Is it normal behavior or it's possible to do something to increase performance? PS: the same behaviour occurs for various values of shared memory defined at the start of kamailio server (128Mb, 256Mb, 512Mb etc.). Thank you, Andrey

3 5

Re: [SR-Users] app_lua sr.sqlops.query exit status
by Daniel-Constantin Mierla 11 Jan '18

11 Jan '18

I have master (which should be more or less like latest 5.1) running with app_lua, but on debian 9.0. From backtrace, no obvious issue. Wondering if you can get a stripped down version of you config with as less loaded modules as possible and minimal routing blocks that expose the issue, so I can try it here. Try to load only the app_lua and the modules it binds to and see if crashes ... if not, it could be a side effect from other place. Cheers, Daniel On 10.01.18 12:44, jenus(a)cyberchaos.nl wrote: > Daniel, > > (gdb) frame 5 > #5 0x00007fd3b2684870 in lua_sr_kemi_register_libs (L=0xeffdb0) at > app_lua_sr.c:1973 > 1973 app_lua_sr.c: No such file or directory. > (gdb) list > 1968 in app_lua_sr.c > (gdb) info locals > _sr_crt_KSRMethods = 0xf0cf80 > emods = 0xa59a00 <_sr_kemi_modules> > emods_size = 37 > i = 3 > k = 35 > n = 346 > mname = > "KSR.uac_redirect\000\000\000\000\000\000\000\000\256\240B\262\323\177\000\000й\360\000\000\000\000\000\004\000\000\000\323\177\000\000 > ˏ\262\323\177\000\000\000\362\066\000\234\324\302Ͱ\375\357", '\000' > <repeats 21 times>, > "\065\246C\262\323\177\000\000@\265\225\356\376\177\000\000\000\000\000\000\377\377\377\377\000\000\000\000\000\000\000\000\177\241m\262\323\177\000" > __FUNCTION__ = "lua_sr_kemi_register_libs" > > (gdb) frame 6 > #6 0x00007fd3b26cf107 in lua_sr_openlibs (L=0xeffdb0) at > app_lua_api.c:185 > 185 app_lua_api.c: No such file or directory. > (gdb) list > 180 in app_lua_api.c > (gdb) info locals > No locals. > > > Jan > > > Daniel-Constantin Mierla schreef op 2018-01-10 12:40: >> Now the backtrace is different, gram the output for info locals in frame >> 5 and 6. >> >> Cheers, >> Daniel >> >> >> On 10.01.18 11:26, jenus(a)cyberchaos.nl wrote: >>> I have overwritten the core file b y accident. I did a new backtrace: >>> >>> (gdb) backtrace >>> #0 0x00007fd3b24365a0 in ?? () from >>> /usr/lib/x86_64-linux-gnu/liblua5.1.so.0 >>> #1 0x00007fd3b2437b62 in ?? () from >>> /usr/lib/x86_64-linux-gnu/liblua5.1.so.0 >>> #2 0x00007fd3b242a040 in lua_settable () from >>> /usr/lib/x86_64-linux-gnu/liblua5.1.so.0 >>> #3 0x00007fd3b243a412 in luaL_findtable () from >>> /usr/lib/x86_64-linux-gnu/liblua5.1.so.0 >>> #4 0x00007fd3b243a581 in luaL_openlib () from >>> /usr/lib/x86_64-linux-gnu/liblua5.1.so.0 >>> #5 0x00007fd3b2684870 in lua_sr_kemi_register_libs (L=0xeffdb0) at >>> app_lua_sr.c:1973 >>> #6 0x00007fd3b26cf107 in lua_sr_openlibs (L=0xeffdb0) at >>> app_lua_api.c:185 >>> #7 0x00007fd3b26cf7c1 in lua_sr_init_probe () at app_lua_api.c:225 >>> #8 0x00007fd3b265b97d in child_init (rank=-127) at app_lua_mod.c:197 >>> #9 0x0000000000549944 in init_mod_child (m=0x7fd3bc82cc70, rank=-127) >>> at core/sr_module.c:938 >>> #10 0x0000000000549c72 in init_child (rank=-127) at >>> core/sr_module.c:964 >>> #11 0x0000000000422c1c in main_loop () at main.c:1576 >>> #12 0x000000000042aab9 in main (argc=3, argv=0x7ffeee95b548) at >>> main.c:2646 >>> >>> (gdb) frame 7 >>> #7 0x00007fd3b26cf7c1 in lua_sr_init_probe () at app_lua_api.c:225 >>> 225 app_lua_api.c: No such file or directory. >>> (gdb) list >>> 220 in app_lua_api.c >>> (gdb) info locals >>> L = 0xeffdb0 >>> txt = 0x7fd3bd00dce7 <__fprintf+135> "H\201\304", <incomplete sequence >>> \330> >>> li = 0x0 >>> sbuf = {st_dev = 0, st_ino = 206158430256, st_nlink = 140732901208248, >>> st_mode = 4002787296, st_uid = 32766, st_gid = 4002787464, __pad0 = >>> 14, st_rdev = 140728898420739, st_size = 0, >>> st_blksize = 30795, st_blocks = 7970120, st_atim = {tv_sec = >>> 7929944, tv_nsec = 0}, st_mtim = {tv_sec = 0, tv_nsec = >>> 140732901208128}, st_ctim = {tv_sec = 140547210663782, >>> tv_nsec = 7938688}, __glibc_reserved = {-541165879423, >>> 140732901208240, 5544260}} >>> __FUNCTION__ = "lua_sr_init_probe" >>> >>> I assume that in this case i need to do a "frame 7". >>> >>> >>> Jan >>> >>> Daniel-Constantin Mierla schreef op 2018-01-10 11:18: >>>> Few more things to grab from core file with gdb -- take the output for >>>> the next commands: >>>> >>>> frame 16 >>>> >>>> list >>>> >>>> info locals >>>> >>>> Cheers, >>>> Daniel >>>> >>>> >>>> On 10.01.18 11:08, jenus(a)cyberchaos.nl wrote: >>>>> Daniel, >>>>> >>>>> Here are the app_lua settings: >>>>> >>>>> # ----- app_lua params ----- >>>>> modparam("app_lua", "load", "/etc/kamailio/kamailio_functions.lua") >>>>> modparam("app_lua", "register", "sqlops") >>>>> modparam("app_lua", "register", "siputils") >>>>> modparam("app_lua", "register", "xhttp") >>>>> >>>>> >>>>> Jan >>>>> >>>>> >>>>> Daniel-Constantin Mierla schreef op 2018-01-10 11:03: >>>>>> Can you give here the parameters you set for app_lua module? >>>>>> >>>>>> Cheers, >>>>>> Daniel >>>>>> >>>>>> >>>>>> On 09.01.18 22:27, jenus(a)cyberchaos.nl wrote: >>>>>>> Daniel, >>>>>>> >>>>>>> Here is the backtrace. >>>>>>> >>>>>>> (gdb) backtrace >>>>>>> #0 0x00007fe41140e067 in __GI_raise (sig=sig@entry=6) at >>>>>>> ../nptl/sysdeps/unix/sysv/linux/raise.c:56 >>>>>>> #1 0x00007fe41140f448 in __GI_abort () at abort.c:89 >>>>>>> #2 0x00007fe41144c1b4 in __libc_message >>>>>>> (do_abort=do_abort@entry=1, >>>>>>> fmt=fmt@entry=0x7fe411541210 "*** Error in `%s': %s: 0x%s >>>>>>> ***\n") at >>>>>>> ../sysdeps/posix/libc_fatal.c:175 >>>>>>> #3 0x00007fe41145198e in malloc_printerr (action=1, >>>>>>> str=0x7fe41153d42a "realloc(): invalid next size", ptr=<optimized >>>>>>> out>) at malloc.c:4996 >>>>>>> #4 0x00007fe41145476b in _int_realloc (av=av@entry=0x7fe41177e620 >>>>>>> <main_arena>, oldp=oldp@entry=0x21789c0, oldsize=oldsize@entry=736, >>>>>>> nb=nb@entry=1552) at malloc.c:4234 >>>>>>> #5 0x00007fe411455769 in __GI___libc_realloc (oldmem=0x21789d0, >>>>>>> bytes=1536) at malloc.c:3029 >>>>>>> #6 0x00007fe40c460cae in ?? () from >>>>>>> /usr/lib/x86_64-linux-gnu/liblua5.1.so.0 >>>>>>> #7 0x00007fe40c45c9aa in ?? () from >>>>>>> /usr/lib/x86_64-linux-gnu/liblua5.1.so.0 >>>>>>> #8 0x00007fe40c46166d in ?? () from >>>>>>> /usr/lib/x86_64-linux-gnu/liblua5.1.so.0 >>>>>>> #9 0x00007fe40c4640b3 in ?? () from >>>>>>> /usr/lib/x86_64-linux-gnu/liblua5.1.so.0 >>>>>>> #10 0x00007fe40c45ccd1 in ?? () from >>>>>>> /usr/lib/x86_64-linux-gnu/liblua5.1.so.0 >>>>>>> #11 0x00007fe40c45c92e in ?? () from >>>>>>> /usr/lib/x86_64-linux-gnu/liblua5.1.so.0 >>>>>>> #12 0x00007fe40c45d7bb in ?? () from >>>>>>> /usr/lib/x86_64-linux-gnu/liblua5.1.so.0 >>>>>>> #13 0x00007fe40c45d8c2 in ?? () from >>>>>>> /usr/lib/x86_64-linux-gnu/liblua5.1.so.0 >>>>>>> #14 0x00007fe40c459528 in lua_load () from >>>>>>> /usr/lib/x86_64-linux-gnu/liblua5.1.so.0 >>>>>>> #15 0x00007fe40c469d8c in luaL_loadbuffer () from >>>>>>> /usr/lib/x86_64-linux-gnu/liblua5.1.so.0 >>>>>>> #16 0x00007fe40c6fe7d7 in lua_sr_init_probe () at app_lua_api.c:228 >>>>>>> #17 0x00007fe40c68a97d in child_init (rank=-127) at >>>>>>> app_lua_mod.c:197 >>>>>>> #18 0x0000000000549944 in init_mod_child (m=0x7fe410c3b998, >>>>>>> rank=-127) >>>>>>> at core/sr_module.c:938 >>>>>>> #19 0x0000000000549662 in init_mod_child (m=0x7fe410c3bec0, >>>>>>> rank=-127) >>>>>>> at core/sr_module.c:935 >>>>>>> #20 0x0000000000549662 in init_mod_child (m=0x7fe410c3c708, >>>>>>> rank=-127) >>>>>>> at core/sr_module.c:935 >>>>>>> #21 0x0000000000549662 in init_mod_child (m=0x7fe410c3cd78, >>>>>>> rank=-127) >>>>>>> at core/sr_module.c:935 >>>>>>> #22 0x0000000000549662 in init_mod_child (m=0x7fe410c3d360, >>>>>>> rank=-127) >>>>>>> at core/sr_module.c:935 >>>>>>> #23 0x0000000000549662 in init_mod_child (m=0x7fe410c3e1e8, >>>>>>> rank=-127) >>>>>>> at core/sr_module.c:935 >>>>>>> #24 0x0000000000549662 in init_mod_child (m=0x7fe410c3e938, >>>>>>> rank=-127) >>>>>>> at core/sr_module.c:935 >>>>>>> #25 0x0000000000549662 in init_mod_child (m=0x7fe410c3f4c8, >>>>>>> rank=-127) >>>>>>> at core/sr_module.c:935 >>>>>>> #26 0x0000000000549662 in init_mod_child (m=0x7fe410c3fca0, >>>>>>> rank=-127) >>>>>>> at core/sr_module.c:935 >>>>>>> #27 0x0000000000549662 in init_mod_child (m=0x7fe410c40118, >>>>>>> rank=-127) >>>>>>> at core/sr_module.c:935 >>>>>>> #28 0x0000000000549662 in init_mod_child (m=0x7fe410c40780, >>>>>>> rank=-127) >>>>>>> at core/sr_module.c:935 >>>>>>> #29 0x0000000000549662 in init_mod_child (m=0x7fe410c422f8, >>>>>>> rank=-127) >>>>>>> at core/sr_module.c:935 >>>>>>> #30 0x0000000000549662 in init_mod_child (m=0x7fe410c42968, >>>>>>> rank=-127) >>>>>>> at core/sr_module.c:935 >>>>>>> #31 0x0000000000549662 in init_mod_child (m=0x7fe410c42e50, >>>>>>> rank=-127) >>>>>>> at core/sr_module.c:935 >>>>>>> #32 0x0000000000549662 in init_mod_child (m=0x7fe410c43b48, >>>>>>> rank=-127) >>>>>>> at core/sr_module.c:935 >>>>>>> #33 0x0000000000549662 in init_mod_child (m=0x7fe410c43f20, >>>>>>> rank=-127) >>>>>>> at core/sr_module.c:935 >>>>>>> #34 0x0000000000549662 in init_mod_child (m=0x7fe410c446e0, >>>>>>> rank=-127) >>>>>>> at core/sr_module.c:935 >>>>>>> #35 0x0000000000549662 in init_mod_child (m=0x7fe410c44bd0, >>>>>>> rank=-127) >>>>>>> at core/sr_module.c:935 >>>>>>> #36 0x0000000000549662 in init_mod_child (m=0x7fe410c44ec8, >>>>>>> rank=-127) >>>>>>> at core/sr_module.c:935 >>>>>>> #37 0x0000000000549662 in init_mod_child (m=0x7fe410c45378, >>>>>>> rank=-127) >>>>>>> at core/sr_module.c:935 >>>>>>> #38 0x0000000000549662 in init_mod_child (m=0x7fe410c458f0, >>>>>>> rank=-127) >>>>>>> at core/sr_module.c:935 >>>>>>> #39 0x0000000000549662 in init_mod_child (m=0x7fe410c45e48, >>>>>>> rank=-127) >>>>>>> at core/sr_module.c:935 >>>>>>> #40 0x0000000000549662 in init_mod_child (m=0x7fe410c464e8, >>>>>>> rank=-127) >>>>>>> at core/sr_module.c:935 >>>>>>> #41 0x0000000000549662 in init_mod_child (m=0x7fe410c47278, >>>>>>> rank=-127) >>>>>>> at core/sr_module.c:935 >>>>>>> #42 0x0000000000549662 in init_mod_child (m=0x7fe410c476f0, >>>>>>> rank=-127) >>>>>>> at core/sr_module.c:935 >>>>>>> #43 0x0000000000549662 in init_mod_child (m=0x7fe410c47b68, >>>>>>> rank=-127) >>>>>>> at core/sr_module.c:935 >>>>>>> #44 0x0000000000549c72 in init_child (rank=-127) at >>>>>>> core/sr_module.c:964 >>>>>>> #45 0x0000000000422c1c in main_loop () at main.c:1576 >>>>>>> #46 0x000000000042aab9 in main (argc=3, argv=0x7ffe17f0e788) at >>>>>>> main.c:2646 >>>>>>> >>>>>>> >>>>>>> Jan >>>>>>> >>>>>>> Daniel-Constantin Mierla schreef op 2018-01-09 22:21: >>>>>>>> Can you install the debug symbols for kamailio as well? There >>>>>>>> should be >>>>>>>> a kamailio-dbg package or so ... >>>>>>>> >>>>>>>> Then take again the backtrace, it should provide more >>>>>>>> information -- >>>>>>>> file and line for each frame, ... >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Daniel >>>>>>>> >>>>>>>> >>>>>>>> On 09.01.18 21:21, jenus(a)cyberchaos.nl wrote: >>>>>>>>> Daniel, >>>>>>>>> >>>>>>>>> Just upgraded to 5.1 but kamailio now generates a core file. I'm >>>>>>>>> running debian 8.10. It seems to crash on liblua5.1.so.0 : >>>>>>>>> >>>>>>>>> Using host libthread_db library >>>>>>>>> "/lib/x86_64-linux-gnu/libthread_db.so.1". >>>>>>>>> Core was generated by `kamailio -m 1500'. >>>>>>>>> Program terminated with signal SIGSEGV, Segmentation fault. >>>>>>>>> #0 0x00007f30c17f25a0 in ?? () from >>>>>>>>> /usr/lib/x86_64-linux-gnu/liblua5.1.so.0 >>>>>>>>> (gdb) backtrace >>>>>>>>> #0 0x00007f30c17f25a0 in ?? () from >>>>>>>>> /usr/lib/x86_64-linux-gnu/liblua5.1.so.0 >>>>>>>>> #1 0x00007f30c17f3b62 in ?? () from >>>>>>>>> /usr/lib/x86_64-linux-gnu/liblua5.1.so.0 >>>>>>>>> #2 0x00007f30c17e6040 in lua_settable () from >>>>>>>>> /usr/lib/x86_64-linux-gnu/liblua5.1.so.0 >>>>>>>>> #3 0x00007f30c17f6412 in luaL_findtable () from >>>>>>>>> /usr/lib/x86_64-linux-gnu/liblua5.1.so.0 >>>>>>>>> #4 0x00007f30c17f6581 in luaL_openlib () from >>>>>>>>> /usr/lib/x86_64-linux-gnu/liblua5.1.so.0 >>>>>>>>> #5 0x00007f30c1a40870 in lua_sr_kemi_register_libs () from >>>>>>>>> /usr/lib/x86_64-linux-gnu/kamailio/modules/app_lua.so >>>>>>>>> #6 0x00007f30c1a8b107 in lua_sr_openlibs () from >>>>>>>>> /usr/lib/x86_64-linux-gnu/kamailio/modules/app_lua.so >>>>>>>>> #7 0x00007f30c1a8b7c1 in lua_sr_init_probe () from >>>>>>>>> /usr/lib/x86_64-linux-gnu/kamailio/modules/app_lua.so >>>>>>>>> #8 0x00007f30c1a1797d in ?? () from >>>>>>>>> /usr/lib/x86_64-linux-gnu/kamailio/modules/app_lua.so >>>>>>>>> #9 0x0000000000549944 in ?? () >>>>>>>>> #10 0x0000000000549c72 in init_child () >>>>>>>>> #11 0x0000000000421498 in main_loop () >>>>>>>>> #12 0x000000000042aab9 in main () >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Jan >>>>>>>>> >>>>>>>>> jenus(a)cyberchaos.nl schreef op 2018-01-09 20:53: >>>>>>>>>> Daniel, >>>>>>>>>> >>>>>>>>>> Currently running kamailio 5.0.5. >>>>>>>>>> >>>>>>>>>> Jan >>>>>>>>>> >>>>>>>>>> Daniel-Constantin Mierla schreef op 2018-01-09 13:27: >>>>>>>>>>> Hello, >>>>>>>>>>> >>>>>>>>>>> what version of kamailio are you using? >>>>>>>>>>> >>>>>>>>>>> Cheers, >>>>>>>>>>> Daniel >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 07.01.18 22:14, jenus(a)cyberchaos.nl wrote: >>>>>>>>>>>> Hello, >>>>>>>>>>>> >>>>>>>>>>>> I'm doing some tests with a lua script and app_lua. I'm using >>>>>>>>>>>> sr.sqlops.query to insert records into the database but would >>>>>>>>>>>> like to >>>>>>>>>>>> test the exit status of the sql query. In kamailio i can do: >>>>>>>>>>>> >>>>>>>>>>>> if(!sql_query("kamailio", "INSERT INTO subscriber ...")) >>>>>>>>>>>> >>>>>>>>>>>> Is there some kind of exit status for the lua function >>>>>>>>>>>> sr.sqlops.query >>>>>>>>>>>> in order to do the same check in lua? In other words, is it >>>>>>>>>>>> possible >>>>>>>>>>>> to check if a sql query was successful in lua? The result >>>>>>>>>>>> seems >>>>>>>>>>>> to be >>>>>>>>>>>> nill in all cases for a INSERT in lua using sr.sqlops.query. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> >>>>>>>>>>>> Jan Hazenberg >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Kamailio (SER) - Users Mailing List >>>>>>>>>>>> sr-users(a)lists.kamailio.org >>>>>>>>>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Kamailio (SER) - Users Mailing List >>>>>>>>>> sr-users(a)lists.kamailio.org >>>>>>>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >>>>>>>>> >>>>>>> >>>>> >>> > -- Daniel-Constantin Mierla www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - March 5-7, 2018, Berlin - www.asipto.com Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com

2 3

Siremis Subscriber List
by Alexandre Cardoso 11 Jan '18

11 Jan '18

Hi Guys, I’m a new guy working with Kamailio and sirens, could you help on a issue that I’ve found? I just installed Kamailio and Siremis and went to the Siremis GUI. I want to add subscriber to subscriber list and I’m facing the following error: [2018-01-11 11:22:18 (GMT)] An exception occurred while executing this script: Error message: #0, Error in query:: SELECT T0.id, T0.username, T0.domain, T0.contact, T0.received, T0.path, T0.expires, T0.q, T0.callid, T0.cseq, T0.last_modified, T0.flags, T0.cflags, T0.user_agent, T0.socket, T0.methods, T0.ruid, T0.instance, T0.reg_id, T0.server_id, T0.connection_id, T0.keepalive, T0.partition FROM `location` T0 LIMIT 10. SQLSTATE[42S22]: Column not found: 1054 Unknown column 'T0.server_id' in 'field list' Script name and line number of error: : function: _run_search ( Array(2) ) @ /var/www/html/openbiz/bin/data/BizDataObj_Lite.php 243 function: fetch ( ) @ /var/www/html/openbiz/bin/easy/EasyForm.php 690 function: fetchDataSet ( ) @ /var/www/html/openbiz/bin/easy/FormRenderer.php 69 function: renderSmarty ( Object(EasyForm), "/var/www/html/siremis/modules/ser/template/grid.tpl" ) @ /var/www/html/openbiz/bin/easy/FormRenderer.php 45 function: render ( Object(EasyForm) ) @ /var/www/html/openbiz/bin/easy/EasyForm.php 1648 function: renderHTML ( ) @ /var/www/html/openbiz/bin/easy/EasyForm.php 1538 function: render ( ) @ /var/www/html/openbiz/bin/easy/ViewRenderer.php 83 function: renderSmarty ( Object(EasyView), "/var/www/html/siremis/modules/ser/template/view_tabs.tpl" ) @ /var/www/html/openbiz/bin/easy/ViewRenderer.php 40 function: render ( Object(EasyView) ) @ /var/www/html/openbiz/bin/easy/EasyView.php 274 function: _render ( ) @ /var/www/html/openbiz/bin/easy/EasyView.php 237 function: render ( ) @ /var/www/html/openbiz/bin/BizController.php 221 function: renderView ( "ser.view.SubscriberListView", "", "", Null, "" ) @ /var/www/html/openbiz/bin/BizController.php 107 function: dispatchRequest ( ) @ /var/www/html/openbiz/bin/BizController.php 32 function: include_once ( "/var/www/html/openbiz/bin/BizController.php" ) @ /var/www/html/siremis/bin/controller.php 6 function: include ( "/var/www/html/siremis/bin/controller.php" ) @ /var/www/html/siremis/bin/_forward.php 102 function: include ( "/var/www/html/siremis/bin/_forward.php" ) @ /var/www/html/siremis/index.php 3 Please ask system administrator for help… Have you faced already a similar issue? Or do you know how I can add those subscribers via command line? Thanks in advance for your help Alex

1 0

kamailio-5.0.5 active/passive pcs/cluster with rtpengine - how to fix calls after failover
by Karsten Horsmann 11 Jan '18

11 Jan '18

Hello List, and also an happy new year to everyone. I use CentOS 7.4.x with kamailio 5.0.5 and rtpengine on a pacemaker/corosync cluster in front of an internal kamailio siprouter and media-services. If i did an "pcs node standby" to failover my frontend-kamailio (udp/tcp 5060, udp/tcp 5061-tls and tcp websocket-secure) i noticed the following scenarios: 1) Plain RTP: just stocks a few seconds and flows. Everything fine. 2) SDES/RTP: silence - but REINVITE manually in my client brings audio back. Need improvement. 3) DTLS/RTP WebRTC: silence - all clients shows an active call. I know that there is NO way to recover this call - because of the temporay DTLS certificate due the rtpengine start-up. So i thought - for scenario1) i dont need anything to do. Works nice. For scenario2) i need something to "remember its SDES/RTP calls and send them an REINVITE" And for scenario3) i should just hangup all WebRTC calls - IMHO the best for that. How can i fire-up these tasks to get an "clean-up" or "reinvite" after an failover? scenario legend: 1) unencrypted call 2) TLS/SDES encrypted call 3) DTÖS WebRTC encrypted call -- Kind Regards *Karsten Horsmann*

2 8

XML-RPC htable.reload
by Martin Nyström 11 Jan '18

11 Jan '18

Hi, I am trying to use XML-RPC for issuing a htable.reload but fails to get it working properly. In this scenario I am trying to reload the htable “foobar”. My XML doc looks as follows: <?xml version="1.0"?> <methodCall> <methodName>htable.reload foobar</methodName> <params></params> </methodCall> The returned response is: <?xml version="1.0"?> <methodResponse> <fault> <value> <struct> <member> <name>faultCode</name> <value><int>500</int></value> </member> <member> <name>faultString</name> <value><string>Method Not Found</string></value> </member> </struct> </value> </fault> </methodResponse> So my question is really how I can use XML-RPC to reload a htable. I am probaly missing a field here or anything like that. kamailio 4.4.5 (x86_64/linux) Regards

1 0

Error linking contact to IMPU on SCSCF
by Rafi A. 11 Jan '18

11 Jan '18

Hi there, I need some help here to understand why the query in [usrloc_db.c:1084] is empty. This causes the linking of contact to IMPU to fail. I'm using Kamailio 5.0.4. 10(13882) DEBUG: ims_usrloc_scscf [impurecord.c:1284]: unref_subscription_unsafe(): un-reffing subscription [rafi(a)mnc001.mcc001.3gppnetwork.org] - was [3] 10(13882) DEBUG: ims_registrar_scscf [save.c:519]: update_contacts_helper(): updating the contacts for IMPU <sip:rafi@mnc001.mcc001.3gppnetwork.org> 10(13882) DEBUG: ims_registrar_scscf [save.c:137]: calc_contact_expires(): Calculated expires for contact is 600000 10(13882) DEBUG: ims_registrar_scscf [save.c:548]: update_contacts_helper(): Need to update contact: <sip:rafi@192.168.10.48:57230;transport=udp>: q_value [-1],sos: [0],expires [600000] 10(13882) DEBUG: ims_registrar_scscf [save.c:550]: update_contacts_helper(): packing contact information 10(13882) DEBUG: ims_registrar_scscf [save.c:556]: update_contacts_helper(): adding/updating contact based on prior existence 10(13882) DEBUG: ims_usrloc_scscf [impurecord.c:748]: get_scontact(): looking for contact [sip:rafi@192.168.10.48:57230;transport=udp] in slot 300 10(13882) DEBUG: ims_registrar_scscf [save.c:562]: update_contacts_helper(): inserting new contact 10(13882) DEBUG: ims_usrloc_scscf [impurecord.c:562]: insert_scontact(): INSERTing ucontact in usrloc module 10(13882) DEBUG: ims_usrloc_scscf [ucontact.c:118]: new_ucontact(): Checking param [+g.3gpp.cs-voice] 10(13882) DEBUG: ims_usrloc_scscf [ucontact.c:118]: new_ucontact(): Checking param [+g.3gpp.icsi-ref] 10(13882) DEBUG: ims_usrloc_scscf [ucontact.c:118]: new_ucontact(): Checking param [audio] 10(13882) DEBUG: ims_usrloc_scscf [ucontact.c:118]: new_ucontact(): Checking param [+g.oma.sip-im.large-message] 10(13882) DEBUG: ims_usrloc_scscf [ucontact.c:118]: new_ucontact(): Checking param [+g.3gpp.smsip] 10(13882) DEBUG: ims_usrloc_scscf [ucontact.c:118]: new_ucontact(): Checking param [language] 10(13882) DEBUG: ims_usrloc_scscf [ucontact.c:118]: new_ucontact(): Checking param [+g.oma.sip-im] 10(13882) DEBUG: ims_usrloc_scscf [ucontact.c:118]: new_ucontact(): Checking param [expires] 10(13882) DEBUG: ims_usrloc_scscf [ucontact.c:173]: new_ucontact(): generating hash based on [sip:rafi@192.168.10.48:57230;transport=udp] 10(13882) DEBUG: ims_usrloc_scscf [impurecord.c:280]: mem_insert_scontact(): Created new contact in memory with AOR: [sip:rafi@192.168.10.48:57230;transport=udp] and hash [300] 10(13882) DEBUG: ims_usrloc_scscf [usrloc_db.c:289]: db_insert_ucontact(): DB: inserting ucontact [sip:rafi@192.168.10.48:57230;transport=udp] 10(13882) DEBUG: ims_usrloc_scscf [usrloc_db.c:311]: db_insert_ucontact(): Converted params to string to insert into db: [+g.3gpp.cs-voice;+g.3gpp.icsi-ref=urn%3Aurn-7%3A3gpp-application.ims.iari.g sma-vs;audio;+g.oma.sip-im.large-message;+g.3gpp.smsip;language=en,fr;+g.oma .sip-im;expires=600000] 10(13882) DEBUG: ims_usrloc_scscf [udomain.c:843]: ref_contact_unsafe(): incrementing ref count on contact [sip:rafi@192.168.10.48:57230;transport=udp], was 1 10(13882) DEBUG: ims_usrloc_scscf [impurecord.c:1225]: link_contact_to_impu(): number of contacts for IMPU [sip:rafi@mnc001.mcc001.3gppnetwork.org] is 1 10(13882) DEBUG: ims_usrloc_scscf [usrloc_db.c:1065]: db_link_contact_to_impu(): DB: linking contact to IMPU 10(13882) DEBUG: ims_usrloc_scscf [usrloc_db.c:1084]: db_link_contact_to_impu(): QUERY IS [] and len is 0 10(13882) ERROR: db_mysql [km_dbase.c:128]: db_mysql_submit_query(): driver error on query: Query was empty (1065) 10(13882) ERROR: <core> [db_query.c:181]: db_do_raw_query(): error while submitting query 10(13882) ERROR: ims_usrloc_scscf [usrloc_db.c:1086]: db_link_contact_to_impu(): Unable to link impu-contact in DB - impu [ <sip:rafi@mnc001.mcc001.3gppnetwork.org> sip:rafi@mnc001.mcc001.3gppnetwork.org], contact [ <sip:rafi@192.168.10.48:57230;transport=udp> sip:rafi@192.168.10.48:57230;transport=udp] 10(13882) ERROR: ims_usrloc_scscf [impurecord.c:1227]: link_contact_to_impu(): Failed to update DB linking contact [ <sip:rafi@192.168.10.48:57230;transport=udp> sip:rafi@192.168.10.48:57230;transport=udp] to IMPU [ <sip:rafi@mnc001.mcc001.3gppnetwork.org> sip:rafi@mnc001.mcc001.3gppnetwork.org]...continuing but db will be out of sync! 10(13882) DEBUG: ims_usrloc_scscf [udomain.c:852]: unref_contact_unsafe(): decrementing ref count on contact [sip:rafi@192.168.10.48:57230;transport=udp], was 2 Best Regards, Rafael A.

1 0

Re: [SR-Users] TLS cipher suites
by Steve 10 Jan '18

10 Jan '18

Hello, Thank you both for your responses to my query about TLS cipher suites supported by Kamailio 4.3.4. When I used a self-signed certificate generated from an RSA key, the server selected the RSA-AES256-GCM-SHA384 cipher suite for the connection. When I used a self-signed certificate generated from an EC key, the server selected the ECDH-ECDSA-AES256-GCM-SHA384 cipher suite for the connection. This was confirmed using the OpenSSL /s_client/ command and with Wireshark. In short, I am still unable to establish an ECDHE ephemeral key exchange even though the OpenSSL version 1.0.2g on Lubuntu 16.4.3 supports it. So I must not have the correct configuration of the TLS module for Kamailio 4.3.4 or else need to generate some other kind of key/certificate. I'm using the Kamailio and TLS config files that came with the package downloads, minimally modified to enable TLS and specify the file location of the key and certificate. I googled "ephemeral key exchange" and came across a posting on Stack Exchange talking about commands such as /SSL_CTX_set_temp_ecdh_callback/ that enable ephemeral key exchange. This command is not listed as a configuration setting in the TLS module man-page so I assume it is a coding command used within the module. In any case, I'd appreciate any further suggestions. Thanks, Steve --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

2 2

Anyone successfully run Fortify on Kamailio?
by Malcolm O'Hare 10 Jan '18

10 Jan '18

I've been trying to run Fortify Static Code Analyzer on the Kamailio build but all the ways its suggested to hook the build aren't working. I'm curious if anyone has tried to run it and been successful, and if they saved / remember what they did.

1 0

usrloc rpc command ul add
by Евгений Голей 10 Jan '18

10 Jan '18

Hello! Tell me how, when using the "kamcmd ul.add location username@domain sip:contact_username@contact_ip:contact_port 0 1.0 ??? 0 0 0" command, specify parameters that are not used, for example path ? -- С уважением, Евгений Голей

2 2

Re: [SR-Users] app_lua sr.sqlops.query exit status
by Daniel-Constantin Mierla 10 Jan '18

10 Jan '18

Now the backtrace is different, gram the output for info locals in frame 5 and 6. Cheers, Daniel On 10.01.18 11:26, jenus(a)cyberchaos.nl wrote: > I have overwritten the core file b y accident. I did a new backtrace: > > (gdb) backtrace > #0 0x00007fd3b24365a0 in ?? () from > /usr/lib/x86_64-linux-gnu/liblua5.1.so.0 > #1 0x00007fd3b2437b62 in ?? () from > /usr/lib/x86_64-linux-gnu/liblua5.1.so.0 > #2 0x00007fd3b242a040 in lua_settable () from > /usr/lib/x86_64-linux-gnu/liblua5.1.so.0 > #3 0x00007fd3b243a412 in luaL_findtable () from > /usr/lib/x86_64-linux-gnu/liblua5.1.so.0 > #4 0x00007fd3b243a581 in luaL_openlib () from > /usr/lib/x86_64-linux-gnu/liblua5.1.so.0 > #5 0x00007fd3b2684870 in lua_sr_kemi_register_libs (L=0xeffdb0) at > app_lua_sr.c:1973 > #6 0x00007fd3b26cf107 in lua_sr_openlibs (L=0xeffdb0) at > app_lua_api.c:185 > #7 0x00007fd3b26cf7c1 in lua_sr_init_probe () at app_lua_api.c:225 > #8 0x00007fd3b265b97d in child_init (rank=-127) at app_lua_mod.c:197 > #9 0x0000000000549944 in init_mod_child (m=0x7fd3bc82cc70, rank=-127) > at core/sr_module.c:938 > #10 0x0000000000549c72 in init_child (rank=-127) at core/sr_module.c:964 > #11 0x0000000000422c1c in main_loop () at main.c:1576 > #12 0x000000000042aab9 in main (argc=3, argv=0x7ffeee95b548) at > main.c:2646 > > (gdb) frame 7 > #7 0x00007fd3b26cf7c1 in lua_sr_init_probe () at app_lua_api.c:225 > 225 app_lua_api.c: No such file or directory. > (gdb) list > 220 in app_lua_api.c > (gdb) info locals > L = 0xeffdb0 > txt = 0x7fd3bd00dce7 <__fprintf+135> "H\201\304", <incomplete sequence > \330> > li = 0x0 > sbuf = {st_dev = 0, st_ino = 206158430256, st_nlink = 140732901208248, > st_mode = 4002787296, st_uid = 32766, st_gid = 4002787464, __pad0 = > 14, st_rdev = 140728898420739, st_size = 0, > st_blksize = 30795, st_blocks = 7970120, st_atim = {tv_sec = > 7929944, tv_nsec = 0}, st_mtim = {tv_sec = 0, tv_nsec = > 140732901208128}, st_ctim = {tv_sec = 140547210663782, > tv_nsec = 7938688}, __glibc_reserved = {-541165879423, > 140732901208240, 5544260}} > __FUNCTION__ = "lua_sr_init_probe" > > I assume that in this case i need to do a "frame 7". > > > Jan > > Daniel-Constantin Mierla schreef op 2018-01-10 11:18: >> Few more things to grab from core file with gdb -- take the output for >> the next commands: >> >> frame 16 >> >> list >> >> info locals >> >> Cheers, >> Daniel >> >> >> On 10.01.18 11:08, jenus(a)cyberchaos.nl wrote: >>> Daniel, >>> >>> Here are the app_lua settings: >>> >>> # ----- app_lua params ----- >>> modparam("app_lua", "load", "/etc/kamailio/kamailio_functions.lua") >>> modparam("app_lua", "register", "sqlops") >>> modparam("app_lua", "register", "siputils") >>> modparam("app_lua", "register", "xhttp") >>> >>> >>> Jan >>> >>> >>> Daniel-Constantin Mierla schreef op 2018-01-10 11:03: >>>> Can you give here the parameters you set for app_lua module? >>>> >>>> Cheers, >>>> Daniel >>>> >>>> >>>> On 09.01.18 22:27, jenus(a)cyberchaos.nl wrote: >>>>> Daniel, >>>>> >>>>> Here is the backtrace. >>>>> >>>>> (gdb) backtrace >>>>> #0 0x00007fe41140e067 in __GI_raise (sig=sig@entry=6) at >>>>> ../nptl/sysdeps/unix/sysv/linux/raise.c:56 >>>>> #1 0x00007fe41140f448 in __GI_abort () at abort.c:89 >>>>> #2 0x00007fe41144c1b4 in __libc_message (do_abort=do_abort@entry=1, >>>>> fmt=fmt@entry=0x7fe411541210 "*** Error in `%s': %s: 0x%s ***\n") at >>>>> ../sysdeps/posix/libc_fatal.c:175 >>>>> #3 0x00007fe41145198e in malloc_printerr (action=1, >>>>> str=0x7fe41153d42a "realloc(): invalid next size", ptr=<optimized >>>>> out>) at malloc.c:4996 >>>>> #4 0x00007fe41145476b in _int_realloc (av=av@entry=0x7fe41177e620 >>>>> <main_arena>, oldp=oldp@entry=0x21789c0, oldsize=oldsize@entry=736, >>>>> nb=nb@entry=1552) at malloc.c:4234 >>>>> #5 0x00007fe411455769 in __GI___libc_realloc (oldmem=0x21789d0, >>>>> bytes=1536) at malloc.c:3029 >>>>> #6 0x00007fe40c460cae in ?? () from >>>>> /usr/lib/x86_64-linux-gnu/liblua5.1.so.0 >>>>> #7 0x00007fe40c45c9aa in ?? () from >>>>> /usr/lib/x86_64-linux-gnu/liblua5.1.so.0 >>>>> #8 0x00007fe40c46166d in ?? () from >>>>> /usr/lib/x86_64-linux-gnu/liblua5.1.so.0 >>>>> #9 0x00007fe40c4640b3 in ?? () from >>>>> /usr/lib/x86_64-linux-gnu/liblua5.1.so.0 >>>>> #10 0x00007fe40c45ccd1 in ?? () from >>>>> /usr/lib/x86_64-linux-gnu/liblua5.1.so.0 >>>>> #11 0x00007fe40c45c92e in ?? () from >>>>> /usr/lib/x86_64-linux-gnu/liblua5.1.so.0 >>>>> #12 0x00007fe40c45d7bb in ?? () from >>>>> /usr/lib/x86_64-linux-gnu/liblua5.1.so.0 >>>>> #13 0x00007fe40c45d8c2 in ?? () from >>>>> /usr/lib/x86_64-linux-gnu/liblua5.1.so.0 >>>>> #14 0x00007fe40c459528 in lua_load () from >>>>> /usr/lib/x86_64-linux-gnu/liblua5.1.so.0 >>>>> #15 0x00007fe40c469d8c in luaL_loadbuffer () from >>>>> /usr/lib/x86_64-linux-gnu/liblua5.1.so.0 >>>>> #16 0x00007fe40c6fe7d7 in lua_sr_init_probe () at app_lua_api.c:228 >>>>> #17 0x00007fe40c68a97d in child_init (rank=-127) at app_lua_mod.c:197 >>>>> #18 0x0000000000549944 in init_mod_child (m=0x7fe410c3b998, >>>>> rank=-127) >>>>> at core/sr_module.c:938 >>>>> #19 0x0000000000549662 in init_mod_child (m=0x7fe410c3bec0, >>>>> rank=-127) >>>>> at core/sr_module.c:935 >>>>> #20 0x0000000000549662 in init_mod_child (m=0x7fe410c3c708, >>>>> rank=-127) >>>>> at core/sr_module.c:935 >>>>> #21 0x0000000000549662 in init_mod_child (m=0x7fe410c3cd78, >>>>> rank=-127) >>>>> at core/sr_module.c:935 >>>>> #22 0x0000000000549662 in init_mod_child (m=0x7fe410c3d360, >>>>> rank=-127) >>>>> at core/sr_module.c:935 >>>>> #23 0x0000000000549662 in init_mod_child (m=0x7fe410c3e1e8, >>>>> rank=-127) >>>>> at core/sr_module.c:935 >>>>> #24 0x0000000000549662 in init_mod_child (m=0x7fe410c3e938, >>>>> rank=-127) >>>>> at core/sr_module.c:935 >>>>> #25 0x0000000000549662 in init_mod_child (m=0x7fe410c3f4c8, >>>>> rank=-127) >>>>> at core/sr_module.c:935 >>>>> #26 0x0000000000549662 in init_mod_child (m=0x7fe410c3fca0, >>>>> rank=-127) >>>>> at core/sr_module.c:935 >>>>> #27 0x0000000000549662 in init_mod_child (m=0x7fe410c40118, >>>>> rank=-127) >>>>> at core/sr_module.c:935 >>>>> #28 0x0000000000549662 in init_mod_child (m=0x7fe410c40780, >>>>> rank=-127) >>>>> at core/sr_module.c:935 >>>>> #29 0x0000000000549662 in init_mod_child (m=0x7fe410c422f8, >>>>> rank=-127) >>>>> at core/sr_module.c:935 >>>>> #30 0x0000000000549662 in init_mod_child (m=0x7fe410c42968, >>>>> rank=-127) >>>>> at core/sr_module.c:935 >>>>> #31 0x0000000000549662 in init_mod_child (m=0x7fe410c42e50, >>>>> rank=-127) >>>>> at core/sr_module.c:935 >>>>> #32 0x0000000000549662 in init_mod_child (m=0x7fe410c43b48, >>>>> rank=-127) >>>>> at core/sr_module.c:935 >>>>> #33 0x0000000000549662 in init_mod_child (m=0x7fe410c43f20, >>>>> rank=-127) >>>>> at core/sr_module.c:935 >>>>> #34 0x0000000000549662 in init_mod_child (m=0x7fe410c446e0, >>>>> rank=-127) >>>>> at core/sr_module.c:935 >>>>> #35 0x0000000000549662 in init_mod_child (m=0x7fe410c44bd0, >>>>> rank=-127) >>>>> at core/sr_module.c:935 >>>>> #36 0x0000000000549662 in init_mod_child (m=0x7fe410c44ec8, >>>>> rank=-127) >>>>> at core/sr_module.c:935 >>>>> #37 0x0000000000549662 in init_mod_child (m=0x7fe410c45378, >>>>> rank=-127) >>>>> at core/sr_module.c:935 >>>>> #38 0x0000000000549662 in init_mod_child (m=0x7fe410c458f0, >>>>> rank=-127) >>>>> at core/sr_module.c:935 >>>>> #39 0x0000000000549662 in init_mod_child (m=0x7fe410c45e48, >>>>> rank=-127) >>>>> at core/sr_module.c:935 >>>>> #40 0x0000000000549662 in init_mod_child (m=0x7fe410c464e8, >>>>> rank=-127) >>>>> at core/sr_module.c:935 >>>>> #41 0x0000000000549662 in init_mod_child (m=0x7fe410c47278, >>>>> rank=-127) >>>>> at core/sr_module.c:935 >>>>> #42 0x0000000000549662 in init_mod_child (m=0x7fe410c476f0, >>>>> rank=-127) >>>>> at core/sr_module.c:935 >>>>> #43 0x0000000000549662 in init_mod_child (m=0x7fe410c47b68, >>>>> rank=-127) >>>>> at core/sr_module.c:935 >>>>> #44 0x0000000000549c72 in init_child (rank=-127) at >>>>> core/sr_module.c:964 >>>>> #45 0x0000000000422c1c in main_loop () at main.c:1576 >>>>> #46 0x000000000042aab9 in main (argc=3, argv=0x7ffe17f0e788) at >>>>> main.c:2646 >>>>> >>>>> >>>>> Jan >>>>> >>>>> Daniel-Constantin Mierla schreef op 2018-01-09 22:21: >>>>>> Can you install the debug symbols for kamailio as well? There >>>>>> should be >>>>>> a kamailio-dbg package or so ... >>>>>> >>>>>> Then take again the backtrace, it should provide more information -- >>>>>> file and line for each frame, ... >>>>>> >>>>>> Cheers, >>>>>> Daniel >>>>>> >>>>>> >>>>>> On 09.01.18 21:21, jenus(a)cyberchaos.nl wrote: >>>>>>> Daniel, >>>>>>> >>>>>>> Just upgraded to 5.1 but kamailio now generates a core file. I'm >>>>>>> running debian 8.10. It seems to crash on liblua5.1.so.0 : >>>>>>> >>>>>>> Using host libthread_db library >>>>>>> "/lib/x86_64-linux-gnu/libthread_db.so.1". >>>>>>> Core was generated by `kamailio -m 1500'. >>>>>>> Program terminated with signal SIGSEGV, Segmentation fault. >>>>>>> #0 0x00007f30c17f25a0 in ?? () from >>>>>>> /usr/lib/x86_64-linux-gnu/liblua5.1.so.0 >>>>>>> (gdb) backtrace >>>>>>> #0 0x00007f30c17f25a0 in ?? () from >>>>>>> /usr/lib/x86_64-linux-gnu/liblua5.1.so.0 >>>>>>> #1 0x00007f30c17f3b62 in ?? () from >>>>>>> /usr/lib/x86_64-linux-gnu/liblua5.1.so.0 >>>>>>> #2 0x00007f30c17e6040 in lua_settable () from >>>>>>> /usr/lib/x86_64-linux-gnu/liblua5.1.so.0 >>>>>>> #3 0x00007f30c17f6412 in luaL_findtable () from >>>>>>> /usr/lib/x86_64-linux-gnu/liblua5.1.so.0 >>>>>>> #4 0x00007f30c17f6581 in luaL_openlib () from >>>>>>> /usr/lib/x86_64-linux-gnu/liblua5.1.so.0 >>>>>>> #5 0x00007f30c1a40870 in lua_sr_kemi_register_libs () from >>>>>>> /usr/lib/x86_64-linux-gnu/kamailio/modules/app_lua.so >>>>>>> #6 0x00007f30c1a8b107 in lua_sr_openlibs () from >>>>>>> /usr/lib/x86_64-linux-gnu/kamailio/modules/app_lua.so >>>>>>> #7 0x00007f30c1a8b7c1 in lua_sr_init_probe () from >>>>>>> /usr/lib/x86_64-linux-gnu/kamailio/modules/app_lua.so >>>>>>> #8 0x00007f30c1a1797d in ?? () from >>>>>>> /usr/lib/x86_64-linux-gnu/kamailio/modules/app_lua.so >>>>>>> #9 0x0000000000549944 in ?? () >>>>>>> #10 0x0000000000549c72 in init_child () >>>>>>> #11 0x0000000000421498 in main_loop () >>>>>>> #12 0x000000000042aab9 in main () >>>>>>> >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Jan >>>>>>> >>>>>>> jenus(a)cyberchaos.nl schreef op 2018-01-09 20:53: >>>>>>>> Daniel, >>>>>>>> >>>>>>>> Currently running kamailio 5.0.5. >>>>>>>> >>>>>>>> Jan >>>>>>>> >>>>>>>> Daniel-Constantin Mierla schreef op 2018-01-09 13:27: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> what version of kamailio are you using? >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> Daniel >>>>>>>>> >>>>>>>>> >>>>>>>>> On 07.01.18 22:14, jenus(a)cyberchaos.nl wrote: >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> I'm doing some tests with a lua script and app_lua. I'm using >>>>>>>>>> sr.sqlops.query to insert records into the database but would >>>>>>>>>> like to >>>>>>>>>> test the exit status of the sql query. In kamailio i can do: >>>>>>>>>> >>>>>>>>>> if(!sql_query("kamailio", "INSERT INTO subscriber ...")) >>>>>>>>>> >>>>>>>>>> Is there some kind of exit status for the lua function >>>>>>>>>> sr.sqlops.query >>>>>>>>>> in order to do the same check in lua? In other words, is it >>>>>>>>>> possible >>>>>>>>>> to check if a sql query was successful in lua? The result seems >>>>>>>>>> to be >>>>>>>>>> nill in all cases for a INSERT in lua using sr.sqlops.query. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Jan Hazenberg >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Kamailio (SER) - Users Mailing List >>>>>>>>>> sr-users(a)lists.kamailio.org >>>>>>>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Kamailio (SER) - Users Mailing List >>>>>>>> sr-users(a)lists.kamailio.org >>>>>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >>>>>>> >>>>> >>> > -- Daniel-Constantin Mierla www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - March 5-7, 2018, Berlin - www.asipto.com Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com

2 1

Re: [SR-Users] app_lua sr.sqlops.query exit status
by Daniel-Constantin Mierla 10 Jan '18

10 Jan '18

Few more things to grab from core file with gdb -- take the output for the next commands: frame 16 list info locals Cheers, Daniel On 10.01.18 11:08, jenus(a)cyberchaos.nl wrote: > Daniel, > > Here are the app_lua settings: > > # ----- app_lua params ----- > modparam("app_lua", "load", "/etc/kamailio/kamailio_functions.lua") > modparam("app_lua", "register", "sqlops") > modparam("app_lua", "register", "siputils") > modparam("app_lua", "register", "xhttp") > > > Jan > > > Daniel-Constantin Mierla schreef op 2018-01-10 11:03: >> Can you give here the parameters you set for app_lua module? >> >> Cheers, >> Daniel >> >> >> On 09.01.18 22:27, jenus(a)cyberchaos.nl wrote: >>> Daniel, >>> >>> Here is the backtrace. >>> >>> (gdb) backtrace >>> #0 0x00007fe41140e067 in __GI_raise (sig=sig@entry=6) at >>> ../nptl/sysdeps/unix/sysv/linux/raise.c:56 >>> #1 0x00007fe41140f448 in __GI_abort () at abort.c:89 >>> #2 0x00007fe41144c1b4 in __libc_message (do_abort=do_abort@entry=1, >>> fmt=fmt@entry=0x7fe411541210 "*** Error in `%s': %s: 0x%s ***\n") at >>> ../sysdeps/posix/libc_fatal.c:175 >>> #3 0x00007fe41145198e in malloc_printerr (action=1, >>> str=0x7fe41153d42a "realloc(): invalid next size", ptr=<optimized >>> out>) at malloc.c:4996 >>> #4 0x00007fe41145476b in _int_realloc (av=av@entry=0x7fe41177e620 >>> <main_arena>, oldp=oldp@entry=0x21789c0, oldsize=oldsize@entry=736, >>> nb=nb@entry=1552) at malloc.c:4234 >>> #5 0x00007fe411455769 in __GI___libc_realloc (oldmem=0x21789d0, >>> bytes=1536) at malloc.c:3029 >>> #6 0x00007fe40c460cae in ?? () from >>> /usr/lib/x86_64-linux-gnu/liblua5.1.so.0 >>> #7 0x00007fe40c45c9aa in ?? () from >>> /usr/lib/x86_64-linux-gnu/liblua5.1.so.0 >>> #8 0x00007fe40c46166d in ?? () from >>> /usr/lib/x86_64-linux-gnu/liblua5.1.so.0 >>> #9 0x00007fe40c4640b3 in ?? () from >>> /usr/lib/x86_64-linux-gnu/liblua5.1.so.0 >>> #10 0x00007fe40c45ccd1 in ?? () from >>> /usr/lib/x86_64-linux-gnu/liblua5.1.so.0 >>> #11 0x00007fe40c45c92e in ?? () from >>> /usr/lib/x86_64-linux-gnu/liblua5.1.so.0 >>> #12 0x00007fe40c45d7bb in ?? () from >>> /usr/lib/x86_64-linux-gnu/liblua5.1.so.0 >>> #13 0x00007fe40c45d8c2 in ?? () from >>> /usr/lib/x86_64-linux-gnu/liblua5.1.so.0 >>> #14 0x00007fe40c459528 in lua_load () from >>> /usr/lib/x86_64-linux-gnu/liblua5.1.so.0 >>> #15 0x00007fe40c469d8c in luaL_loadbuffer () from >>> /usr/lib/x86_64-linux-gnu/liblua5.1.so.0 >>> #16 0x00007fe40c6fe7d7 in lua_sr_init_probe () at app_lua_api.c:228 >>> #17 0x00007fe40c68a97d in child_init (rank=-127) at app_lua_mod.c:197 >>> #18 0x0000000000549944 in init_mod_child (m=0x7fe410c3b998, rank=-127) >>> at core/sr_module.c:938 >>> #19 0x0000000000549662 in init_mod_child (m=0x7fe410c3bec0, rank=-127) >>> at core/sr_module.c:935 >>> #20 0x0000000000549662 in init_mod_child (m=0x7fe410c3c708, rank=-127) >>> at core/sr_module.c:935 >>> #21 0x0000000000549662 in init_mod_child (m=0x7fe410c3cd78, rank=-127) >>> at core/sr_module.c:935 >>> #22 0x0000000000549662 in init_mod_child (m=0x7fe410c3d360, rank=-127) >>> at core/sr_module.c:935 >>> #23 0x0000000000549662 in init_mod_child (m=0x7fe410c3e1e8, rank=-127) >>> at core/sr_module.c:935 >>> #24 0x0000000000549662 in init_mod_child (m=0x7fe410c3e938, rank=-127) >>> at core/sr_module.c:935 >>> #25 0x0000000000549662 in init_mod_child (m=0x7fe410c3f4c8, rank=-127) >>> at core/sr_module.c:935 >>> #26 0x0000000000549662 in init_mod_child (m=0x7fe410c3fca0, rank=-127) >>> at core/sr_module.c:935 >>> #27 0x0000000000549662 in init_mod_child (m=0x7fe410c40118, rank=-127) >>> at core/sr_module.c:935 >>> #28 0x0000000000549662 in init_mod_child (m=0x7fe410c40780, rank=-127) >>> at core/sr_module.c:935 >>> #29 0x0000000000549662 in init_mod_child (m=0x7fe410c422f8, rank=-127) >>> at core/sr_module.c:935 >>> #30 0x0000000000549662 in init_mod_child (m=0x7fe410c42968, rank=-127) >>> at core/sr_module.c:935 >>> #31 0x0000000000549662 in init_mod_child (m=0x7fe410c42e50, rank=-127) >>> at core/sr_module.c:935 >>> #32 0x0000000000549662 in init_mod_child (m=0x7fe410c43b48, rank=-127) >>> at core/sr_module.c:935 >>> #33 0x0000000000549662 in init_mod_child (m=0x7fe410c43f20, rank=-127) >>> at core/sr_module.c:935 >>> #34 0x0000000000549662 in init_mod_child (m=0x7fe410c446e0, rank=-127) >>> at core/sr_module.c:935 >>> #35 0x0000000000549662 in init_mod_child (m=0x7fe410c44bd0, rank=-127) >>> at core/sr_module.c:935 >>> #36 0x0000000000549662 in init_mod_child (m=0x7fe410c44ec8, rank=-127) >>> at core/sr_module.c:935 >>> #37 0x0000000000549662 in init_mod_child (m=0x7fe410c45378, rank=-127) >>> at core/sr_module.c:935 >>> #38 0x0000000000549662 in init_mod_child (m=0x7fe410c458f0, rank=-127) >>> at core/sr_module.c:935 >>> #39 0x0000000000549662 in init_mod_child (m=0x7fe410c45e48, rank=-127) >>> at core/sr_module.c:935 >>> #40 0x0000000000549662 in init_mod_child (m=0x7fe410c464e8, rank=-127) >>> at core/sr_module.c:935 >>> #41 0x0000000000549662 in init_mod_child (m=0x7fe410c47278, rank=-127) >>> at core/sr_module.c:935 >>> #42 0x0000000000549662 in init_mod_child (m=0x7fe410c476f0, rank=-127) >>> at core/sr_module.c:935 >>> #43 0x0000000000549662 in init_mod_child (m=0x7fe410c47b68, rank=-127) >>> at core/sr_module.c:935 >>> #44 0x0000000000549c72 in init_child (rank=-127) at >>> core/sr_module.c:964 >>> #45 0x0000000000422c1c in main_loop () at main.c:1576 >>> #46 0x000000000042aab9 in main (argc=3, argv=0x7ffe17f0e788) at >>> main.c:2646 >>> >>> >>> Jan >>> >>> Daniel-Constantin Mierla schreef op 2018-01-09 22:21: >>>> Can you install the debug symbols for kamailio as well? There >>>> should be >>>> a kamailio-dbg package or so ... >>>> >>>> Then take again the backtrace, it should provide more information -- >>>> file and line for each frame, ... >>>> >>>> Cheers, >>>> Daniel >>>> >>>> >>>> On 09.01.18 21:21, jenus(a)cyberchaos.nl wrote: >>>>> Daniel, >>>>> >>>>> Just upgraded to 5.1 but kamailio now generates a core file. I'm >>>>> running debian 8.10. It seems to crash on liblua5.1.so.0 : >>>>> >>>>> Using host libthread_db library >>>>> "/lib/x86_64-linux-gnu/libthread_db.so.1". >>>>> Core was generated by `kamailio -m 1500'. >>>>> Program terminated with signal SIGSEGV, Segmentation fault. >>>>> #0 0x00007f30c17f25a0 in ?? () from >>>>> /usr/lib/x86_64-linux-gnu/liblua5.1.so.0 >>>>> (gdb) backtrace >>>>> #0 0x00007f30c17f25a0 in ?? () from >>>>> /usr/lib/x86_64-linux-gnu/liblua5.1.so.0 >>>>> #1 0x00007f30c17f3b62 in ?? () from >>>>> /usr/lib/x86_64-linux-gnu/liblua5.1.so.0 >>>>> #2 0x00007f30c17e6040 in lua_settable () from >>>>> /usr/lib/x86_64-linux-gnu/liblua5.1.so.0 >>>>> #3 0x00007f30c17f6412 in luaL_findtable () from >>>>> /usr/lib/x86_64-linux-gnu/liblua5.1.so.0 >>>>> #4 0x00007f30c17f6581 in luaL_openlib () from >>>>> /usr/lib/x86_64-linux-gnu/liblua5.1.so.0 >>>>> #5 0x00007f30c1a40870 in lua_sr_kemi_register_libs () from >>>>> /usr/lib/x86_64-linux-gnu/kamailio/modules/app_lua.so >>>>> #6 0x00007f30c1a8b107 in lua_sr_openlibs () from >>>>> /usr/lib/x86_64-linux-gnu/kamailio/modules/app_lua.so >>>>> #7 0x00007f30c1a8b7c1 in lua_sr_init_probe () from >>>>> /usr/lib/x86_64-linux-gnu/kamailio/modules/app_lua.so >>>>> #8 0x00007f30c1a1797d in ?? () from >>>>> /usr/lib/x86_64-linux-gnu/kamailio/modules/app_lua.so >>>>> #9 0x0000000000549944 in ?? () >>>>> #10 0x0000000000549c72 in init_child () >>>>> #11 0x0000000000421498 in main_loop () >>>>> #12 0x000000000042aab9 in main () >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Jan >>>>> >>>>> jenus(a)cyberchaos.nl schreef op 2018-01-09 20:53: >>>>>> Daniel, >>>>>> >>>>>> Currently running kamailio 5.0.5. >>>>>> >>>>>> Jan >>>>>> >>>>>> Daniel-Constantin Mierla schreef op 2018-01-09 13:27: >>>>>>> Hello, >>>>>>> >>>>>>> what version of kamailio are you using? >>>>>>> >>>>>>> Cheers, >>>>>>> Daniel >>>>>>> >>>>>>> >>>>>>> On 07.01.18 22:14, jenus(a)cyberchaos.nl wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> I'm doing some tests with a lua script and app_lua. I'm using >>>>>>>> sr.sqlops.query to insert records into the database but would >>>>>>>> like to >>>>>>>> test the exit status of the sql query. In kamailio i can do: >>>>>>>> >>>>>>>> if(!sql_query("kamailio", "INSERT INTO subscriber ...")) >>>>>>>> >>>>>>>> Is there some kind of exit status for the lua function >>>>>>>> sr.sqlops.query >>>>>>>> in order to do the same check in lua? In other words, is it >>>>>>>> possible >>>>>>>> to check if a sql query was successful in lua? The result seems >>>>>>>> to be >>>>>>>> nill in all cases for a INSERT in lua using sr.sqlops.query. >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Jan Hazenberg >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Kamailio (SER) - Users Mailing List >>>>>>>> sr-users(a)lists.kamailio.org >>>>>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Kamailio (SER) - Users Mailing List >>>>>> sr-users(a)lists.kamailio.org >>>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >>>>> >>> > -- Daniel-Constantin Mierla www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - March 5-7, 2018, Berlin - www.asipto.com Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com

2 1

Re: [SR-Users] app_lua sr.sqlops.query exit status
by Daniel-Constantin Mierla 10 Jan '18

10 Jan '18

Can you give here the parameters you set for app_lua module? Cheers, Daniel On 09.01.18 22:27, jenus(a)cyberchaos.nl wrote: > Daniel, > > Here is the backtrace. > > (gdb) backtrace > #0 0x00007fe41140e067 in __GI_raise (sig=sig@entry=6) at > ../nptl/sysdeps/unix/sysv/linux/raise.c:56 > #1 0x00007fe41140f448 in __GI_abort () at abort.c:89 > #2 0x00007fe41144c1b4 in __libc_message (do_abort=do_abort@entry=1, > fmt=fmt@entry=0x7fe411541210 "*** Error in `%s': %s: 0x%s ***\n") at > ../sysdeps/posix/libc_fatal.c:175 > #3 0x00007fe41145198e in malloc_printerr (action=1, > str=0x7fe41153d42a "realloc(): invalid next size", ptr=<optimized > out>) at malloc.c:4996 > #4 0x00007fe41145476b in _int_realloc (av=av@entry=0x7fe41177e620 > <main_arena>, oldp=oldp@entry=0x21789c0, oldsize=oldsize@entry=736, > nb=nb@entry=1552) at malloc.c:4234 > #5 0x00007fe411455769 in __GI___libc_realloc (oldmem=0x21789d0, > bytes=1536) at malloc.c:3029 > #6 0x00007fe40c460cae in ?? () from > /usr/lib/x86_64-linux-gnu/liblua5.1.so.0 > #7 0x00007fe40c45c9aa in ?? () from > /usr/lib/x86_64-linux-gnu/liblua5.1.so.0 > #8 0x00007fe40c46166d in ?? () from > /usr/lib/x86_64-linux-gnu/liblua5.1.so.0 > #9 0x00007fe40c4640b3 in ?? () from > /usr/lib/x86_64-linux-gnu/liblua5.1.so.0 > #10 0x00007fe40c45ccd1 in ?? () from > /usr/lib/x86_64-linux-gnu/liblua5.1.so.0 > #11 0x00007fe40c45c92e in ?? () from > /usr/lib/x86_64-linux-gnu/liblua5.1.so.0 > #12 0x00007fe40c45d7bb in ?? () from > /usr/lib/x86_64-linux-gnu/liblua5.1.so.0 > #13 0x00007fe40c45d8c2 in ?? () from > /usr/lib/x86_64-linux-gnu/liblua5.1.so.0 > #14 0x00007fe40c459528 in lua_load () from > /usr/lib/x86_64-linux-gnu/liblua5.1.so.0 > #15 0x00007fe40c469d8c in luaL_loadbuffer () from > /usr/lib/x86_64-linux-gnu/liblua5.1.so.0 > #16 0x00007fe40c6fe7d7 in lua_sr_init_probe () at app_lua_api.c:228 > #17 0x00007fe40c68a97d in child_init (rank=-127) at app_lua_mod.c:197 > #18 0x0000000000549944 in init_mod_child (m=0x7fe410c3b998, rank=-127) > at core/sr_module.c:938 > #19 0x0000000000549662 in init_mod_child (m=0x7fe410c3bec0, rank=-127) > at core/sr_module.c:935 > #20 0x0000000000549662 in init_mod_child (m=0x7fe410c3c708, rank=-127) > at core/sr_module.c:935 > #21 0x0000000000549662 in init_mod_child (m=0x7fe410c3cd78, rank=-127) > at core/sr_module.c:935 > #22 0x0000000000549662 in init_mod_child (m=0x7fe410c3d360, rank=-127) > at core/sr_module.c:935 > #23 0x0000000000549662 in init_mod_child (m=0x7fe410c3e1e8, rank=-127) > at core/sr_module.c:935 > #24 0x0000000000549662 in init_mod_child (m=0x7fe410c3e938, rank=-127) > at core/sr_module.c:935 > #25 0x0000000000549662 in init_mod_child (m=0x7fe410c3f4c8, rank=-127) > at core/sr_module.c:935 > #26 0x0000000000549662 in init_mod_child (m=0x7fe410c3fca0, rank=-127) > at core/sr_module.c:935 > #27 0x0000000000549662 in init_mod_child (m=0x7fe410c40118, rank=-127) > at core/sr_module.c:935 > #28 0x0000000000549662 in init_mod_child (m=0x7fe410c40780, rank=-127) > at core/sr_module.c:935 > #29 0x0000000000549662 in init_mod_child (m=0x7fe410c422f8, rank=-127) > at core/sr_module.c:935 > #30 0x0000000000549662 in init_mod_child (m=0x7fe410c42968, rank=-127) > at core/sr_module.c:935 > #31 0x0000000000549662 in init_mod_child (m=0x7fe410c42e50, rank=-127) > at core/sr_module.c:935 > #32 0x0000000000549662 in init_mod_child (m=0x7fe410c43b48, rank=-127) > at core/sr_module.c:935 > #33 0x0000000000549662 in init_mod_child (m=0x7fe410c43f20, rank=-127) > at core/sr_module.c:935 > #34 0x0000000000549662 in init_mod_child (m=0x7fe410c446e0, rank=-127) > at core/sr_module.c:935 > #35 0x0000000000549662 in init_mod_child (m=0x7fe410c44bd0, rank=-127) > at core/sr_module.c:935 > #36 0x0000000000549662 in init_mod_child (m=0x7fe410c44ec8, rank=-127) > at core/sr_module.c:935 > #37 0x0000000000549662 in init_mod_child (m=0x7fe410c45378, rank=-127) > at core/sr_module.c:935 > #38 0x0000000000549662 in init_mod_child (m=0x7fe410c458f0, rank=-127) > at core/sr_module.c:935 > #39 0x0000000000549662 in init_mod_child (m=0x7fe410c45e48, rank=-127) > at core/sr_module.c:935 > #40 0x0000000000549662 in init_mod_child (m=0x7fe410c464e8, rank=-127) > at core/sr_module.c:935 > #41 0x0000000000549662 in init_mod_child (m=0x7fe410c47278, rank=-127) > at core/sr_module.c:935 > #42 0x0000000000549662 in init_mod_child (m=0x7fe410c476f0, rank=-127) > at core/sr_module.c:935 > #43 0x0000000000549662 in init_mod_child (m=0x7fe410c47b68, rank=-127) > at core/sr_module.c:935 > #44 0x0000000000549c72 in init_child (rank=-127) at core/sr_module.c:964 > #45 0x0000000000422c1c in main_loop () at main.c:1576 > #46 0x000000000042aab9 in main (argc=3, argv=0x7ffe17f0e788) at > main.c:2646 > > > Jan > > Daniel-Constantin Mierla schreef op 2018-01-09 22:21: >> Can you install the debug symbols for kamailio as well? There should be >> a kamailio-dbg package or so ... >> >> Then take again the backtrace, it should provide more information -- >> file and line for each frame, ... >> >> Cheers, >> Daniel >> >> >> On 09.01.18 21:21, jenus(a)cyberchaos.nl wrote: >>> Daniel, >>> >>> Just upgraded to 5.1 but kamailio now generates a core file. I'm >>> running debian 8.10. It seems to crash on liblua5.1.so.0 : >>> >>> Using host libthread_db library >>> "/lib/x86_64-linux-gnu/libthread_db.so.1". >>> Core was generated by `kamailio -m 1500'. >>> Program terminated with signal SIGSEGV, Segmentation fault. >>> #0 0x00007f30c17f25a0 in ?? () from >>> /usr/lib/x86_64-linux-gnu/liblua5.1.so.0 >>> (gdb) backtrace >>> #0 0x00007f30c17f25a0 in ?? () from >>> /usr/lib/x86_64-linux-gnu/liblua5.1.so.0 >>> #1 0x00007f30c17f3b62 in ?? () from >>> /usr/lib/x86_64-linux-gnu/liblua5.1.so.0 >>> #2 0x00007f30c17e6040 in lua_settable () from >>> /usr/lib/x86_64-linux-gnu/liblua5.1.so.0 >>> #3 0x00007f30c17f6412 in luaL_findtable () from >>> /usr/lib/x86_64-linux-gnu/liblua5.1.so.0 >>> #4 0x00007f30c17f6581 in luaL_openlib () from >>> /usr/lib/x86_64-linux-gnu/liblua5.1.so.0 >>> #5 0x00007f30c1a40870 in lua_sr_kemi_register_libs () from >>> /usr/lib/x86_64-linux-gnu/kamailio/modules/app_lua.so >>> #6 0x00007f30c1a8b107 in lua_sr_openlibs () from >>> /usr/lib/x86_64-linux-gnu/kamailio/modules/app_lua.so >>> #7 0x00007f30c1a8b7c1 in lua_sr_init_probe () from >>> /usr/lib/x86_64-linux-gnu/kamailio/modules/app_lua.so >>> #8 0x00007f30c1a1797d in ?? () from >>> /usr/lib/x86_64-linux-gnu/kamailio/modules/app_lua.so >>> #9 0x0000000000549944 in ?? () >>> #10 0x0000000000549c72 in init_child () >>> #11 0x0000000000421498 in main_loop () >>> #12 0x000000000042aab9 in main () >>> >>> >>> >>> Thanks, >>> >>> Jan >>> >>> jenus(a)cyberchaos.nl schreef op 2018-01-09 20:53: >>>> Daniel, >>>> >>>> Currently running kamailio 5.0.5. >>>> >>>> Jan >>>> >>>> Daniel-Constantin Mierla schreef op 2018-01-09 13:27: >>>>> Hello, >>>>> >>>>> what version of kamailio are you using? >>>>> >>>>> Cheers, >>>>> Daniel >>>>> >>>>> >>>>> On 07.01.18 22:14, jenus(a)cyberchaos.nl wrote: >>>>>> Hello, >>>>>> >>>>>> I'm doing some tests with a lua script and app_lua. I'm using >>>>>> sr.sqlops.query to insert records into the database but would >>>>>> like to >>>>>> test the exit status of the sql query. In kamailio i can do: >>>>>> >>>>>> if(!sql_query("kamailio", "INSERT INTO subscriber ...")) >>>>>> >>>>>> Is there some kind of exit status for the lua function >>>>>> sr.sqlops.query >>>>>> in order to do the same check in lua? In other words, is it possible >>>>>> to check if a sql query was successful in lua? The result seems >>>>>> to be >>>>>> nill in all cases for a INSERT in lua using sr.sqlops.query. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Jan Hazenberg >>>>>> >>>>>> _______________________________________________ >>>>>> Kamailio (SER) - Users Mailing List >>>>>> sr-users(a)lists.kamailio.org >>>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >>>> >>>> >>>> _______________________________________________ >>>> Kamailio (SER) - Users Mailing List >>>> sr-users(a)lists.kamailio.org >>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >>> > -- Daniel-Constantin Mierla www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - March 5-7, 2018, Berlin - www.asipto.com Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com

2 1

Re: [SR-Users] app_lua sr.sqlops.query exit status
by Daniel-Constantin Mierla 09 Jan '18

09 Jan '18

Can you install the debug symbols for kamailio as well? There should be a kamailio-dbg package or so ... Then take again the backtrace, it should provide more information -- file and line for each frame, ... Cheers, Daniel On 09.01.18 21:21, jenus(a)cyberchaos.nl wrote: > Daniel, > > Just upgraded to 5.1 but kamailio now generates a core file. I'm > running debian 8.10. It seems to crash on liblua5.1.so.0 : > > Using host libthread_db library > "/lib/x86_64-linux-gnu/libthread_db.so.1". > Core was generated by `kamailio -m 1500'. > Program terminated with signal SIGSEGV, Segmentation fault. > #0 0x00007f30c17f25a0 in ?? () from > /usr/lib/x86_64-linux-gnu/liblua5.1.so.0 > (gdb) backtrace > #0 0x00007f30c17f25a0 in ?? () from > /usr/lib/x86_64-linux-gnu/liblua5.1.so.0 > #1 0x00007f30c17f3b62 in ?? () from > /usr/lib/x86_64-linux-gnu/liblua5.1.so.0 > #2 0x00007f30c17e6040 in lua_settable () from > /usr/lib/x86_64-linux-gnu/liblua5.1.so.0 > #3 0x00007f30c17f6412 in luaL_findtable () from > /usr/lib/x86_64-linux-gnu/liblua5.1.so.0 > #4 0x00007f30c17f6581 in luaL_openlib () from > /usr/lib/x86_64-linux-gnu/liblua5.1.so.0 > #5 0x00007f30c1a40870 in lua_sr_kemi_register_libs () from > /usr/lib/x86_64-linux-gnu/kamailio/modules/app_lua.so > #6 0x00007f30c1a8b107 in lua_sr_openlibs () from > /usr/lib/x86_64-linux-gnu/kamailio/modules/app_lua.so > #7 0x00007f30c1a8b7c1 in lua_sr_init_probe () from > /usr/lib/x86_64-linux-gnu/kamailio/modules/app_lua.so > #8 0x00007f30c1a1797d in ?? () from > /usr/lib/x86_64-linux-gnu/kamailio/modules/app_lua.so > #9 0x0000000000549944 in ?? () > #10 0x0000000000549c72 in init_child () > #11 0x0000000000421498 in main_loop () > #12 0x000000000042aab9 in main () > > > > Thanks, > > Jan > > jenus(a)cyberchaos.nl schreef op 2018-01-09 20:53: >> Daniel, >> >> Currently running kamailio 5.0.5. >> >> Jan >> >> Daniel-Constantin Mierla schreef op 2018-01-09 13:27: >>> Hello, >>> >>> what version of kamailio are you using? >>> >>> Cheers, >>> Daniel >>> >>> >>> On 07.01.18 22:14, jenus(a)cyberchaos.nl wrote: >>>> Hello, >>>> >>>> I'm doing some tests with a lua script and app_lua. I'm using >>>> sr.sqlops.query to insert records into the database but would like to >>>> test the exit status of the sql query. In kamailio i can do: >>>> >>>> if(!sql_query("kamailio", "INSERT INTO subscriber ...")) >>>> >>>> Is there some kind of exit status for the lua function sr.sqlops.query >>>> in order to do the same check in lua? In other words, is it possible >>>> to check if a sql query was successful in lua? The result seems to be >>>> nill in all cases for a INSERT in lua using sr.sqlops.query. >>>> >>>> >>>> Thanks, >>>> >>>> Jan Hazenberg >>>> >>>> _______________________________________________ >>>> Kamailio (SER) - Users Mailing List >>>> sr-users(a)lists.kamailio.org >>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >> >> >> _______________________________________________ >> Kamailio (SER) - Users Mailing List >> sr-users(a)lists.kamailio.org >> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > -- Daniel-Constantin Mierla www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - March 5-7, 2018, Berlin - www.asipto.com Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com

2 1

Re: [SR-Users] app_lua sr.sqlops.query exit status
by Daniel-Constantin Mierla 09 Jan '18

09 Jan '18

Hello, I needed to know in order to suggest use of "KSR" package or not, instead of "sr". The "sr" package likely to be obsoleted soon, as KSR has lot more exported functions and it is part of the kemi framework. See: http://kamailio.org/docs/tutorials/devel/kamailio-kemi-framework/ http://kamailio.org/docs/tutorials/devel/kamailio-kemi-framework/modules/#s… However, 5.0 doesn't have so many KSR exports as 5.1, and not sure if KSR has the sqlops exports in that version -- too late to check more in the code now... Looking at the code, sr.sqlops.query() should return -1 in case of error and 0 if ok. Cheers, Daniel On 09.01.18 20:53, jenus(a)cyberchaos.nl wrote: > Daniel, > > Currently running kamailio 5.0.5. > > Jan > > Daniel-Constantin Mierla schreef op 2018-01-09 13:27: >> Hello, >> >> what version of kamailio are you using? >> >> Cheers, >> Daniel >> >> >> On 07.01.18 22:14, jenus(a)cyberchaos.nl wrote: >>> Hello, >>> >>> I'm doing some tests with a lua script and app_lua. I'm using >>> sr.sqlops.query to insert records into the database but would like to >>> test the exit status of the sql query. In kamailio i can do: >>> >>> if(!sql_query("kamailio", "INSERT INTO subscriber ...")) >>> >>> Is there some kind of exit status for the lua function sr.sqlops.query >>> in order to do the same check in lua? In other words, is it possible >>> to check if a sql query was successful in lua? The result seems to be >>> nill in all cases for a INSERT in lua using sr.sqlops.query. >>> >>> >>> Thanks, >>> >>> Jan Hazenberg >>> >>> _______________________________________________ >>> Kamailio (SER) - Users Mailing List >>> sr-users(a)lists.kamailio.org >>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > -- Daniel-Constantin Mierla www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - March 5-7, 2018, Berlin - www.asipto.com Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com

1 0

app_lua sr.sqlops.query exit status
by jenus＠cyberchaos.nl 09 Jan '18

09 Jan '18

Hello, I'm doing some tests with a lua script and app_lua. I'm using sr.sqlops.query to insert records into the database but would like to test the exit status of the sql query. In kamailio i can do: if(!sql_query("kamailio", "INSERT INTO subscriber ...")) Is there some kind of exit status for the lua function sr.sqlops.query in order to do the same check in lua? In other words, is it possible to check if a sql query was successful in lua? The result seems to be nill in all cases for a INSERT in lua using sr.sqlops.query. Thanks, Jan Hazenberg

2 4

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 fail to start with db_mongodb and ndb_mongodb modules
by Abdul Basit 09 Jan '18

09 Jan '18

Hi Daniel & K-Team, I setup kamailio 5.0.5 from git on vanilla Debian GNU/Linux 8.3 (jessie) # kamailio -v version: kamailio 5.0.5 (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 16:53:42 Jan 5 2018 with gcc 4.9.2 Installed mongodb from debian repo # dpkg -l | grep mongodb ii mongodb 1:3.2.17-1 amd64 object/document-oriented database (metapackage) ii mongodb-clients 1:3.2.17-1 amd64 object/document-oriented database (client apps) ii mongodb-dev 1:2.4.10-5+deb8u1 amd64 object/document-oriented database (development) ii mongodb-server 1:3.2.17-1 amd64 object/document-oriented database (server package) # mongo --version MongoDB shell version: 3.2.17 Will try sometime with mongodb latest version 3.6 as well as I will get time. Installed libmongoc driver through sid repo "deb http://ftp.de.debian.org/debian sid main" # dpkg -l | grep libmongoc ii libmongoc-1.0-0 1.9.0+dfsg-1 amd64 MongoDB C client library - runtime files ii libmongoc-dev 1.9.0+dfsg-1 amd64 MongoDB C client library - dev files Kamailio compiled with # make cfg include_modules="utils app_lua json evapi db_mongodb ndb_mongodb" Created version collection in mongodb # cat /usr/local/src/kamailio/utils/kamctl/mongodb/kamailio/version-create.mongo | mongo Setup kamailio.cfg as per https://telerain.com/kamailio This time kamailio started successfully without any crash :) --------- Now its time to use mongodb for kamailio backend database. Used default kamailio configuration and defined mongodb connection as #!define DBURL "mongodb://localhost/kamailio" I enabled WITH_USRLOCDB [#!define WITH_USRLOCDB], kamailio refuse to start with errors. Jan 5 19:16:05 kmaongo kamailio: CRITICAL: <core> [core/cfg.y:3411]: yyerror_at(): parse error in config file /usr/local/etc/kamailio/kamailio.cfg, line 365, column 30-34: syntax error Jan 5 19:16:05 kmaongo kamailio: CRITICAL: <core> [core/cfg.y:3411]: yyerror_at(): parse error in config file /usr/local/etc/kamailio/kamailio.cfg, line 365, column 30-34: Invalid arguments Jan 5 19:16:05 kmaongo kamailio: CRITICAL: <core> [core/cfg.y:3414]: yyerror_at(): parse error in config file /usr/local/etc/kamailio/kamailio.cfg, line 365, column 35: Jan 5 19:16:05 kmaongo kamailio[28067]: ERROR: bad config file (3 errors) Jan 5 19:16:05 kmaongo kamailio: WARNING: <core> [core/ppcfg.c:221]: pp_ifdef_level_check(): different number of preprocessor directives: N(#!IF[N]DEF) - N(#!ENDIF) = 1 Jan 5 19:16:05 kmaongo kamailio: INFO: <core> [core/sctp_core.c:53]: sctp_core_destroy(): SCTP API not initialized Jan 5 19:16:05 kmaongo systemd[1]: kamailio.service: control process exited, code=exited status=255 [FAILJan 5 19:16:05 kmaongo systemd[1]: Failed to start Kamailio (OpenSER) - the Open Source SIP Server. Jan 5 19:16:05 kmaongo systemd[1]: Unit kamailio.service entered failed state. failed! Default userloc params in kamailio.cfg states line 365 as # ----- usrloc params ----- /* enable DB persistency for location entries */ #!ifdef WITH_USRLOCDB modparam("usrloc", "db_url", DBURL) [ << line 365 ] modparam("usrloc", "db_mode", 2) modparam("usrloc", "use_domain", MULTIDOMAIN) modparam("usrloc", "db_insert_null", 1) #!endif I created location collection as well but it didn't help. I experienced same error when I enable WITH_ACCDB or any other section that use DBURL. 1. Whats the syntax error here? 2. Is there any special configuration required to work with mongodb? 3. How can we create collections using 'kamdbctl create' ? What else should I share for resolving the issue? -- regards, abdul basit On 4 January 2018 at 12:50, Abdul Basit <basit.engg(a)gmail.com> wrote: > Hi Daniel, > > Thank you for your reply. > > I tested libmongoc with debian package available with repo. Then I moved > to compile from source. result was same. > > But i will try it again with fresh installation and will post here. > > -- > regards, > > abdul basit > > On 2 January 2018 at 16:38, Daniel-Constantin Mierla <miconda(a)gmail.com> > wrote: > >> Hello, >> >> the issue happens inside mongoc library. Have you tried with the default >> one from Debian, without compiling it from sources? >> >> Cheers, >> Daniel >> >> On 01.01.18 16:51, Abdul Basit wrote: >> >> Hi, >> >> My last email was help for admin review. >> >> Sharing logs through pastebin https://pastebin.com/6HhdYLJK >> >> Interesting part will start from line 983 where it start initializing >> ndb_mongodb. >> >> >> >> On 1 January 2018 at 20:32, Abdul Basit <basit.engg(a)gmail.com> wrote: >> >>> Hi, >>> >>> I enabled but kamailio didn't generate any dump file >>> To enable code dump followed https://www.kamailio.org/dokuw >>> iki/doku.php/troubleshooting:corefiles >>> >>> I also un-commented lines in /etc/init.d/kamailio script >>> >>> if test "$DUMP_CORE" = "yes" ; then >>> # set proper ulimit >>> ulimit -c unlimited >>> >>> # directory for the core dump files >>> COREDIR=/tmp/corefiles >>> [ -d $COREDIR ] || mkdir -p $COREDIR >>> chmod 777 $COREDIR >>> echo "$COREDIR/core.%e.sig%s.%p" > /proc/sys/kernel/core_pattern >>> fi >>> >>> >>> I think reason is that kamailio process didn't exit after crash and keep >>> on restarting. each time with new PID. >>> >>> However, debug file is attached. I hope this will help. >>> -- >>> regards, >>> >>> abdul basit >>> >>> On 29 December 2017 at 20:11, M S <shaheryarkh(a)gmail.com> wrote: >>> >>>> Hi, >>>> >>>> Enable core dump and provide backtrace of sigfault. See this for more >>>> info, >>>> >>>> https://sourceware.org/gdb/onlinedocs/gdb/Backtrace.html >>>> >>>> Thank you. >>>> >>>> On Fri, Dec 29, 2017 at 12:25 PM, Abdul Basit <basit.engg(a)gmail.com> >>>> wrote: >>>> >>>>> Adding further from https://stackoverflow.com/ques >>>>> tions/2549214/interpreting-segfault-messages >>>>> >>>>> error 6 means, fault is >>>>> >>>>> * bit 2 == 1 means kernel, 1 means user-mode >>>>> * bit 4 == 1 means fault was an instruction fetch >>>>> >>>>> >>>>> That looks like kamailio is trying to invoke for db connection where >>>>> libmongo-c don't like to be. >>>>> -- >>>>> regards, >>>>> >>>>> abdul basit >>>>> >>>>> On 29 December 2017 at 15:39, Abdul Basit <basit.engg(a)gmail.com> >>>>> wrote: >>>>> >>>>>> 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-c >>>>>> leanup >>>>>> >>>>>> 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: >>>>>> <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.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 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 3

cdr processing questions
by voipspace voipspace 09 Jan '18

09 Jan '18

A few question; Firstly With mod acc and acc_cdr i see the default fields logged is only start_time, end_time, duration. This is an actual entry logged. start_time, end_time, duration 1515353126, 1515353135, 9.660000 Why is the duration 9.660000? It seems wrong because it is more then the difference in time 1515353135 - 1515353126 = 9 Secondly What is a reliable way to capture and log start time, answer time, and end time. How do I get the duration info. a) start time to end time. b) answer to end time. Is there an built in variable that store this info? Thirdly dialog events listed as: event_route[dialog:start] event_route[dialog:end] event_route[dialog:failed] There does not seems to be a event for answer so then how to be notified when a dialog is answered? Regards

2 1

parsing of SIP message failed
by Suresh Talasaniya 08 Jan '18

08 Jan '18

Hi, *I consistently receive the following 3 errors (see below) over and over when a call is being collected.* ERROR: <core> [core/parser/parse_fline.c:257]: parse_first_line(): parse_first_line: bad message (offset: 22) ERROR: <core> [core/parser/msg_parser.c:671]: parse_msg(): ERROR: parse_msg: message=<HTTP/1.1 101 Switching Protocols#015#012Sia: SIP/2.0/TLS x.x.x.x:42173#015#012Sec-WebSocket-Protocol: sip#015#012Upgrade: websocket#015#012Connection: upgrade#015#012Sec-WebSocket-Accept: qrLTSNMA7oAO8YXGaUhf3Ru26X0=#015#012Content-Length: 0#015#012#015#012> Any assistance would be appreciated. Thank you. -- Regards, Suresh Talasaniya. Contact : +91-9724264776 Skype : suresh.talsaniya

2 6

OT: question about codetriage
by Daniel-Constantin Mierla 08 Jan '18

08 Jan '18

Hello, anyone here familiar with codetriage service? We got a pull request to refer to it from Kamailio readme.md file: - https://github.com/kamailio/kamailio/pull/1389 The link is to: - https://www.codetriage.com/kamailio/kamailio Which I guess is created by the one who did the pull request. The pull request comments has few references to other projects, including Rails, but as I am not familiar with the service, I thought of asking here and see if others had to deal with and what's the experience. Cheers, Daniel -- Daniel-Constantin Mierla www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - March 5-7, 2018, Berlin - www.asipto.com Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com

1 0

Error in parse json documents in kamailio with jansson module
by Mojtaba 08 Jan '18

08 Jan '18

Hello, I used ndbmongo module in kamailio, I used mongodb_find command to get some data from mongo, like this: if(mongodb_find("sermongo", "Asterisk", "user", "{ \"number\" : \"$fU\" }", "res")) { xlog("L_INFO", "Data from mongodb is \" $mongodb(res=>value) \" \n"); $var(data) = $mongodb(res=>value); } The result in syslog is like this: Jan 8 07:23:36 ubuntu14 /usr/local/sbin/kamailio[12127]: {1 2 INVITE MDRlMjRlNGVjZGY1Y2JkYjA5OGM2ZTg1ZTFjZTk0Nzg.} INFO: <script>: user Data from mongodb is " { "_id" : { "$oid" : "5916def36803fa48468b456b" }, "user_type" : "SIP", "context" : "main_routing", "deny" : "0.0.0.0/0.0.0.0", "call_record" : "no", "dtmfmode" : "rfc2833", "canreinvite" : "no", "directmedia" : "no", "host" : "dynamic", "type" : "friend", "nat" : "force_rport,comedia", "port" : "5060", "qualify" : "yes", "callgroup" : "1", "pickupgroup" : "1", "permit" : "0.0.0.0/0.0.0.0", "callcounter" : "yes", "faxdetect" : "no", "call_limit" : "", "name" : "1000", "number" : "1000", "cid_number" : "1000", "secret" : "123123", "date" : { "$date" : 1494671091612 }, "more_options" : "" } " Now i need to get just some keys like "context" from json and save them in PV, i used jansson2.10 for doing this job, like this: jansson_get("user.context", $var(jdata), "$var(context)"); but i have this error in syslog: Jan 8 07:23:36 ubuntu14 /usr/local/sbin/kamailio[12127]: {1 2 INVITE MDRlMjRlNGVjZGY1Y2JkYjA5OGM2ZTg1ZTFjZTk0Nzg.} ERROR: <core> [core/pvapi.c:903]: pv_parse_spec2(): error searching pvar "oid" Jan 8 07:23:36 ubuntu14 /usr/local/sbin/kamailio[12127]: {1 2 INVITE MDRlMjRlNGVjZGY1Y2JkYjA5OGM2ZTg1ZTFjZTk0Nzg.} ERROR: <core> [core/pvapi.c:1107]: pv_parse_spec2(): wrong char [d/100] in [$oid] at [3 (0)] Jan 8 07:23:36 ubuntu14 /usr/local/sbin/kamailio[12127]: {1 2 INVITE MDRlMjRlNGVjZGY1Y2JkYjA5OGM2ZTg1ZTFjZTk0Nzg.} ERROR: <core> [core/sr_module.c:1268]: fix_param(): bad PVE format: "{ "_id" : { "$oid" : "5916def36803fa48468b456b" }, "user_type" : "SIP", "context" : "main_routing", "deny" : "0.0.0.0/0.0.0.0", "call_record" : "no", "dtmfmode" : "rfc2833", "canreinvite" : "no", "directmedia" : "no", "host" : "dynamic", "type" : "friend", "nat" : "force_rport,comedia", "port" : "5060", "qualify" : "yes", "callgroup" : "1", "pickupgroup" : "1", "permit" : "0.0.0.0/0.0.0.0", "callcounter" : "yes", "faxdetect" : "no", "call_limit" : "", "name" : "1000", "number" : "1000", "cid_number" : "1000", "secret" : "123123", "date" : { "$date" : 1494671091612 }, "more_options" : "" }" Jan 8 07:23:36 ubuntu14 /usr/local/sbin/kamailio[12127]: {1 2 INVITE MDRlMjRlNGVjZGY1Y2JkYjA5OGM2ZTg1ZTFjZTk0Nzg.} ERROR: <core> [core/mod_fix.c:564]: fixup_spve_null(): Cannot convert function parameter 1 to spve Jan 8 07:23:36 ubuntu14 /usr/local/sbin/kamailio[12127]: {1 2 INVITE MDRlMjRlNGVjZGY1Y2JkYjA5OGM2ZTg1ZTFjZTk0Nzg.} ERROR: <core> [core/action.c:1139]: do_action(): runtime fixup failed for jansson_get param 2 Jan 8 07:23:36 ubuntu14 /usr/local/sbin/kamailio[12127]: {1 2 INVITE MDRlMjRlNGVjZGY1Y2JkYjA5OGM2ZTg1ZTFjZTk0Nzg.} ERROR: <core> [core/action.c:1518]: do_action(): run action error at: /usr/local/etc/kamailio/kamailio.cfg:990 Jan 8 07:23:36 ubuntu14 /usr/local/sbin/kamailio[12127]: {1 2 INVITE MDRlMjRlNGVjZGY1Y2JkYjA5OGM2ZTg1ZTFjZTk0Nzg.} ERROR: <script>: Send SIP message to Simotel <192.168.122.1:36854> Let me know how i could fixed this Error in regard of [$oid]? Thanks with regards. -- --Mojtaba Esfandiari.S

2 1

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 Remote User Registration
by Hildah.Ochieng＠deutschebahn.com 04 Jan '18

04 Jan '18

Dear Kamailio experts, I would like to able to register one kamailio (localuser) in another another kamailio (remoteuser) when the jitsi sip account "localuser@localdomain" is online. Using the UAC module for remote registration the uacreg table's l_username and l_domain attributes are set to refer to the local kamailio while the r_username and r_domain attributes refer to the remote kamailio. I would appreciate your advice on the missing piece of the puzzle. Following is my configuration of the "local" kamailio. The "remote" kamailio.cfg is unchanged. /etc/kamailio/kamailio.cfg loadmodule "db_text.so" loadmodule "uac.so" modparam("uac", "reg_timer_interval", 30) modparam("uac", "reg_retry_interval", 60) modparam("uac", "reg_contact_addr","xx.xx.xx.xx:5060") modparam("uac", "reg_db_table", "uacreg") modparam("uac", "reg_db_url", "text:///etc/kamailio/dbtext") /etc/kamailio/dbtext/uacreg l_uuid(string) l_username(string) l_domain(string) r_username(string) r_domain(string) realm(string) auth_username(string) auth_password(string) auth_proxy(string) expires(int) flags(int) reg_delay (int) 11111111:localuser:localdomain:remoteuser:remotedomain:remoteuser::::360:4:30 Thanks Hildah

2 1

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

TLS cipher suites
by Steve 03 Jan '18

03 Jan '18

I have a question about deploying TLSv1.2 with Kamailio 4.3.4-1 on a Lubuntu 16.4.3 desktop environment. I changed the Kamailio default /tls.cfg/ file under the section [server:default] to “method=TLSv1.2” and am using OpenSSL 1.0.2g from the Lubuntu repository. All the programs were loaded through the Synaptic Package Manager. My question is whether this version of Kamailio supports the cipher suite ECDHE-RSA-AES256-GCM-SHA384. My version of OpenSSL lists it as an option, but the highest strength cipher that the Kamailio 4.3.4 server seems to accept is RSA-AES256-GCM-SHA384. My (limited) understanding is that ECDHE is a better method of key exchange than RSA because it is ephemeral with forward secrecy. I used Wireshark to look at the connection protocols for sip clients Jitsi and Blink with the Kamailio server. Jitsi offers only four cipher choices of what I understand are considered compromised security TLS protocols and it connected with the RSA-AES128-CBC-SHA cipher. Blink offers 65 cipher choices, starting with ECDHE-RSA-AES256-GCM-SHA384. My Kamailio server accepted the 29^th offering on the list, RSA-AES256-GCM-SHA384. Unless I am missing something, Kamailio 4.3.4 doesn’t seem to support ephemeral DH key exchanges. Is there some other TLS configuration file or setting for Kamailio that can be changed to allow this? --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

3 2

Re: [SR-Users] Bind IP to Kamailio without restart
by Duarte Rocha 03 Jan '18

03 Jan '18

Greetings Alex, That's exactly what I need, thanks a lot. Cheers

2 1

Kamailio IMS Proxy Not responding
by Amar Tinawi 03 Jan '18

03 Jan '18

Dears, Good day! i was trying to implement IMS platform in separated servers, i used ubuntu server 16.04 LTS, and ng-voice repository (Kamailio 5.1) with the installation wizard and minimum Conf i also choose FHoSS as HSS bind9 as DNS When i tried to register the Proxy-CSCF is not responding to any request, even no timeout, or error massage, and of course the request is not handled to I-CSCF. The client perform 11 tries, and got no respond Previously i had success with the one image IMS vm, and tried it on separated servers (kamailio version 4.2.4) Am i missing something ? how can i start troubleshoot as there is no error massages ? Is it because i'm using ubuntu 16 instead of 14? your help is highly appreciated ! attached is my configuration files Thanks in Advance Amar

2 1

Re: [SR-Users] Happy New Year 2018!
by Angel Elena 02 Jan '18

02 Jan '18

happy new year and happy sip ;) ----------------------------------------------- Ángel Elena Medina _o) craem(a)craem.net / \ http://blog.craem.net _(___V @craem_ ----------------------------------------------- Zarafa / Zpush Mobile. -------- Mensaje original -------- De: voipspace voipspace <voipspace(a)yandex.com> Fecha: 2/1/18 20:35 (GMT+01:00) Para: miconda(a)gmail.com, "Kamailio (SER) - Users Mailing List" <sr-users(a)lists.kamailio.org>, "Kamailio (SER) - Devel Mailing List" <sr-dev(a)lists.kamailio.org>, business(a)lists.kamailio.org Asunto: Re: [SR-Users] Happy New Year 2018! Happy New Year, Every One. Hope you had great time off with family and friends. May 2018 be prosperous and happy for you all. On to bigger and greater thing in the new year. bw Kamailio is awesome! 01.01.2018, 11:09, "Daniel-Constantin Mierla" <miconda(a)gmail.com>: > A Happy And Prosperous Year 2018 to everyone using Kamailio and helping > to improve the project! > > Looking forward to meeting many of you around this world during 2018 and > collaborate online in a friendly environment! > > 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 > > _______________________________________________ > Kamailio (SER) - Users Mailing List > sr-users(a)lists.kamailio.org > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users _______________________________________________ Kamailio (SER) - Users Mailing List sr-users(a)lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

1 0

Happy New Year 2018!
by Daniel-Constantin Mierla 02 Jan '18

02 Jan '18

A Happy And Prosperous Year 2018 to everyone using Kamailio and helping to improve the project! Looking forward to meeting many of you around this world during 2018 and collaborate online in a friendly environment! 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

2 1

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

Issue with linking contact to IMPU on SCSCF
by Rafi A. 02 Jan '18

02 Jan '18

Hi there, I need some help here to understand why the query in [usrloc_db.c:1084] is empty. This causes the linking of contact to IMPU to fail. I'm using Kamailio 5.0.4. 10(13882) DEBUG: ims_usrloc_scscf [impurecord.c:1284]: unref_subscription_unsafe(): un-reffing subscription [rafi(a)mnc001.mcc001.3gppnetwork.org] - was [3] 10(13882) DEBUG: ims_registrar_scscf [save.c:519]: update_contacts_helper(): updating the contacts for IMPU <sip:rafi@mnc001.mcc001.3gppnetwork.org> 10(13882) DEBUG: ims_registrar_scscf [save.c:137]: calc_contact_expires(): Calculated expires for contact is 600000 10(13882) DEBUG: ims_registrar_scscf [save.c:548]: update_contacts_helper(): Need to update contact: <sip:rafi@192.168.10.48:57230;transport=udp>: q_value [-1],sos: [0],expires [600000] 10(13882) DEBUG: ims_registrar_scscf [save.c:550]: update_contacts_helper(): packing contact information 10(13882) DEBUG: ims_registrar_scscf [save.c:556]: update_contacts_helper(): adding/updating contact based on prior existence 10(13882) DEBUG: ims_usrloc_scscf [impurecord.c:748]: get_scontact(): looking for contact [sip:rafi@192.168.10.48:57230;transport=udp] in slot 300 10(13882) DEBUG: ims_registrar_scscf [save.c:562]: update_contacts_helper(): inserting new contact 10(13882) DEBUG: ims_usrloc_scscf [impurecord.c:562]: insert_scontact(): INSERTing ucontact in usrloc module 10(13882) DEBUG: ims_usrloc_scscf [ucontact.c:118]: new_ucontact(): Checking param [+g.3gpp.cs-voice] 10(13882) DEBUG: ims_usrloc_scscf [ucontact.c:118]: new_ucontact(): Checking param [+g.3gpp.icsi-ref] 10(13882) DEBUG: ims_usrloc_scscf [ucontact.c:118]: new_ucontact(): Checking param [audio] 10(13882) DEBUG: ims_usrloc_scscf [ucontact.c:118]: new_ucontact(): Checking param [+g.oma.sip-im.large-message] 10(13882) DEBUG: ims_usrloc_scscf [ucontact.c:118]: new_ucontact(): Checking param [+g.3gpp.smsip] 10(13882) DEBUG: ims_usrloc_scscf [ucontact.c:118]: new_ucontact(): Checking param [language] 10(13882) DEBUG: ims_usrloc_scscf [ucontact.c:118]: new_ucontact(): Checking param [+g.oma.sip-im] 10(13882) DEBUG: ims_usrloc_scscf [ucontact.c:118]: new_ucontact(): Checking param [expires] 10(13882) DEBUG: ims_usrloc_scscf [ucontact.c:173]: new_ucontact(): generating hash based on [sip:rafi@192.168.10.48:57230;transport=udp] 10(13882) DEBUG: ims_usrloc_scscf [impurecord.c:280]: mem_insert_scontact(): Created new contact in memory with AOR: [sip:rafi@192.168.10.48:57230;transport=udp] and hash [300] 10(13882) DEBUG: ims_usrloc_scscf [usrloc_db.c:289]: db_insert_ucontact(): DB: inserting ucontact [sip:rafi@192.168.10.48:57230;transport=udp] 10(13882) DEBUG: ims_usrloc_scscf [usrloc_db.c:311]: db_insert_ucontact(): Converted params to string to insert into db: [+g.3gpp.cs-voice;+g.3gpp.icsi-ref=urn%3Aurn-7%3A3gpp-application.ims.iari.g sma-vs;audio;+g.oma.sip-im.large-message;+g.3gpp.smsip;language=en,fr;+g.oma .sip-im;expires=600000] 10(13882) DEBUG: ims_usrloc_scscf [udomain.c:843]: ref_contact_unsafe(): incrementing ref count on contact [sip:rafi@192.168.10.48:57230;transport=udp], was 1 10(13882) DEBUG: ims_usrloc_scscf [impurecord.c:1225]: link_contact_to_impu(): number of contacts for IMPU [sip:rafi@mnc001.mcc001.3gppnetwork.org] is 1 10(13882) DEBUG: ims_usrloc_scscf [usrloc_db.c:1065]: db_link_contact_to_impu(): DB: linking contact to IMPU 10(13882) DEBUG: ims_usrloc_scscf [usrloc_db.c:1084]: db_link_contact_to_impu(): QUERY IS [] and len is 0 10(13882) ERROR: db_mysql [km_dbase.c:128]: db_mysql_submit_query(): driver error on query: Query was empty (1065) 10(13882) ERROR: <core> [db_query.c:181]: db_do_raw_query(): error while submitting query 10(13882) ERROR: ims_usrloc_scscf [usrloc_db.c:1086]: db_link_contact_to_impu(): Unable to link impu-contact in DB - impu [sip:rafi@mnc001.mcc001.3gppnetwork.org], contact [sip:rafi@192.168.10.48:57230;transport=udp] 10(13882) ERROR: ims_usrloc_scscf [impurecord.c:1227]: link_contact_to_impu(): Failed to update DB linking contact [sip:rafi@192.168.10.48:57230;transport=udp] to IMPU [sip:rafi@mnc001.mcc001.3gppnetwork.org]...continuing but db will be out of sync! 10(13882) DEBUG: ims_usrloc_scscf [udomain.c:852]: unref_contact_unsafe(): decrementing ref count on contact [sip:rafi@192.168.10.48:57230;transport=udp], was 2 Best Regards, Rafael A.

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

Issue with linking contact to IMPU
by Rafi A. 01 Jan '18

01 Jan '18

Hi there, I need some help here to understand why the query in [usrloc_db.c:1084] is empty. This causes the linking of contact to IMPU to fail. I'm using Kamailio 5.0.4. 10(13882) DEBUG: ims_usrloc_scscf [impurecord.c:1284]: unref_subscription_unsafe(): un-reffing subscription [rafi(a)mnc001.mcc001.3gppnetwork.org] - was [3] 10(13882) DEBUG: ims_registrar_scscf [save.c:519]: update_contacts_helper(): updating the contacts for IMPU <sip:rafi@mnc001.mcc001.3gppnetwork.org> 10(13882) DEBUG: ims_registrar_scscf [save.c:137]: calc_contact_expires(): Calculated expires for contact is 600000 10(13882) DEBUG: ims_registrar_scscf [save.c:548]: update_contacts_helper(): Need to update contact: <sip:rafi@192.168.10.48:57230;transport=udp>: q_value [-1],sos: [0],expires [600000] 10(13882) DEBUG: ims_registrar_scscf [save.c:550]: update_contacts_helper(): packing contact information 10(13882) DEBUG: ims_registrar_scscf [save.c:556]: update_contacts_helper(): adding/updating contact based on prior existence 10(13882) DEBUG: ims_usrloc_scscf [impurecord.c:748]: get_scontact(): looking for contact [sip:rafi@192.168.10.48:57230;transport=udp] in slot 300 10(13882) DEBUG: ims_registrar_scscf [save.c:562]: update_contacts_helper(): inserting new contact 10(13882) DEBUG: ims_usrloc_scscf [impurecord.c:562]: insert_scontact(): INSERTing ucontact in usrloc module 10(13882) DEBUG: ims_usrloc_scscf [ucontact.c:118]: new_ucontact(): Checking param [+g.3gpp.cs-voice] 10(13882) DEBUG: ims_usrloc_scscf [ucontact.c:118]: new_ucontact(): Checking param [+g.3gpp.icsi-ref] 10(13882) DEBUG: ims_usrloc_scscf [ucontact.c:118]: new_ucontact(): Checking param [audio] 10(13882) DEBUG: ims_usrloc_scscf [ucontact.c:118]: new_ucontact(): Checking param [+g.oma.sip-im.large-message] 10(13882) DEBUG: ims_usrloc_scscf [ucontact.c:118]: new_ucontact(): Checking param [+g.3gpp.smsip] 10(13882) DEBUG: ims_usrloc_scscf [ucontact.c:118]: new_ucontact(): Checking param [language] 10(13882) DEBUG: ims_usrloc_scscf [ucontact.c:118]: new_ucontact(): Checking param [+g.oma.sip-im] 10(13882) DEBUG: ims_usrloc_scscf [ucontact.c:118]: new_ucontact(): Checking param [expires] 10(13882) DEBUG: ims_usrloc_scscf [ucontact.c:173]: new_ucontact(): generating hash based on [sip:rafi@192.168.10.48:57230;transport=udp] 10(13882) DEBUG: ims_usrloc_scscf [impurecord.c:280]: mem_insert_scontact(): Created new contact in memory with AOR: [sip:rafi@192.168.10.48:57230;transport=udp] and hash [300] 10(13882) DEBUG: ims_usrloc_scscf [usrloc_db.c:289]: db_insert_ucontact(): DB: inserting ucontact [sip:rafi@192.168.10.48:57230;transport=udp] 10(13882) DEBUG: ims_usrloc_scscf [usrloc_db.c:311]: db_insert_ucontact(): Converted params to string to insert into db: [+g.3gpp.cs-voice;+g.3gpp.icsi-ref=urn%3Aurn-7%3A3gpp-application.ims.iari.g sma-vs;audio;+g.oma.sip-im.large-message;+g.3gpp.smsip;language=en,fr;+g.oma .sip-im;expires=600000] 10(13882) DEBUG: ims_usrloc_scscf [udomain.c:843]: ref_contact_unsafe(): incrementing ref count on contact [sip:rafi@192.168.10.48:57230;transport=udp], was 1 10(13882) DEBUG: ims_usrloc_scscf [impurecord.c:1225]: link_contact_to_impu(): number of contacts for IMPU [sip:rafi@mnc001.mcc001.3gppnetwork.org] is 1 10(13882) DEBUG: ims_usrloc_scscf [usrloc_db.c:1065]: db_link_contact_to_impu(): DB: linking contact to IMPU 10(13882) DEBUG: ims_usrloc_scscf [usrloc_db.c:1084]: db_link_contact_to_impu(): QUERY IS [] and len is 0 10(13882) ERROR: db_mysql [km_dbase.c:128]: db_mysql_submit_query(): driver error on query: Query was empty (1065) 10(13882) ERROR: <core> [db_query.c:181]: db_do_raw_query(): error while submitting query 10(13882) ERROR: ims_usrloc_scscf [usrloc_db.c:1086]: db_link_contact_to_impu(): Unable to link impu-contact in DB - impu [sip:rafi@mnc001.mcc001.3gppnetwork.org], contact [sip:rafi@192.168.10.48:57230;transport=udp] 10(13882) ERROR: ims_usrloc_scscf [impurecord.c:1227]: link_contact_to_impu(): Failed to update DB linking contact [sip:rafi@192.168.10.48:57230;transport=udp] to IMPU [sip:rafi@mnc001.mcc001.3gppnetwork.org]...continuing but db will be out of sync! 10(13882) DEBUG: ims_usrloc_scscf [udomain.c:852]: unref_contact_unsafe(): decrementing ref count on contact [sip:rafi@192.168.10.48:57230;transport=udp], was 2

1 0

Issue with linking contact to IMPU
by Rafi Aizenstain 01 Jan '18

01 Jan '18

Hi there, I need some help here to understand why the query in [usrloc_db.c:1084] is empty. This causes the linking of contact to IMPU to fail. I'm using Kamailio 5.0.4. 10(13882) DEBUG: ims_usrloc_scscf [impurecord.c:1284]: unref_subscription_unsafe(): un-reffing subscription [rafi(a)mnc001.mcc001.3gppnetwork.org] - was [3] 10(13882) DEBUG: ims_registrar_scscf [save.c:519]: update_contacts_helper(): updating the contacts for IMPU <sip:rafi@mnc001.mcc001.3gppnetwork.org> 10(13882) DEBUG: ims_registrar_scscf [save.c:137]: calc_contact_expires(): Calculated expires for contact is 600000 10(13882) DEBUG: ims_registrar_scscf [save.c:548]: update_contacts_helper(): Need to update contact: <sip:rafi@192.168.10.48:57230;transport=udp>: q_value [-1],sos: [0],expires [600000] 10(13882) DEBUG: ims_registrar_scscf [save.c:550]: update_contacts_helper(): packing contact information 10(13882) DEBUG: ims_registrar_scscf [save.c:556]: update_contacts_helper(): adding/updating contact based on prior existence 10(13882) DEBUG: ims_usrloc_scscf [impurecord.c:748]: get_scontact(): looking for contact [sip:rafi@192.168.10.48:57230;transport=udp] in slot 300 10(13882) DEBUG: ims_registrar_scscf [save.c:562]: update_contacts_helper(): inserting new contact 10(13882) DEBUG: ims_usrloc_scscf [impurecord.c:562]: insert_scontact(): INSERTing ucontact in usrloc module 10(13882) DEBUG: ims_usrloc_scscf [ucontact.c:118]: new_ucontact(): Checking param [+g.3gpp.cs-voice] 10(13882) DEBUG: ims_usrloc_scscf [ucontact.c:118]: new_ucontact(): Checking param [+g.3gpp.icsi-ref] 10(13882) DEBUG: ims_usrloc_scscf [ucontact.c:118]: new_ucontact(): Checking param [audio] 10(13882) DEBUG: ims_usrloc_scscf [ucontact.c:118]: new_ucontact(): Checking param [+g.oma.sip-im.large-message] 10(13882) DEBUG: ims_usrloc_scscf [ucontact.c:118]: new_ucontact(): Checking param [+g.3gpp.smsip] 10(13882) DEBUG: ims_usrloc_scscf [ucontact.c:118]: new_ucontact(): Checking param [language] 10(13882) DEBUG: ims_usrloc_scscf [ucontact.c:118]: new_ucontact(): Checking param [+g.oma.sip-im] 10(13882) DEBUG: ims_usrloc_scscf [ucontact.c:118]: new_ucontact(): Checking param [expires] 10(13882) DEBUG: ims_usrloc_scscf [ucontact.c:173]: new_ucontact(): generating hash based on [sip:rafi@192.168.10.48:57230;transport=udp] 10(13882) DEBUG: ims_usrloc_scscf [impurecord.c:280]: mem_insert_scontact(): Created new contact in memory with AOR: [sip:rafi@192.168.10.48:57230;transport=udp] and hash [300] 10(13882) DEBUG: ims_usrloc_scscf [usrloc_db.c:289]: db_insert_ucontact(): DB: inserting ucontact [sip:rafi@192.168.10.48:57230;transport=udp] 10(13882) DEBUG: ims_usrloc_scscf [usrloc_db.c:311]: db_insert_ucontact(): Converted params to string to insert into db: [+g.3gpp.cs-voice;+g.3gpp.icsi-ref=urn%3Aurn-7%3A3gpp-application.ims.iari.gsma-vs;audio;+g.oma.sip-im.large-message;+g.3gpp.smsip;language=en,fr;+g.oma.sip-im;expires=600000] 10(13882) DEBUG: ims_usrloc_scscf [udomain.c:843]: ref_contact_unsafe(): incrementing ref count on contact [sip:rafi@192.168.10.48:57230;transport=udp], was 1 10(13882) DEBUG: ims_usrloc_scscf [impurecord.c:1225]: link_contact_to_impu(): number of contacts for IMPU [sip:rafi@mnc001.mcc001.3gppnetwork.org] is 1 10(13882) DEBUG: ims_usrloc_scscf [usrloc_db.c:1065]: db_link_contact_to_impu(): DB: linking contact to IMPU 10(13882) DEBUG: ims_usrloc_scscf [usrloc_db.c:1084]: db_link_contact_to_impu(): QUERY IS [] and len is 0 10(13882) ERROR: db_mysql [km_dbase.c:128]: db_mysql_submit_query(): driver error on query: Query was empty (1065) 10(13882) ERROR: <core> [db_query.c:181]: db_do_raw_query(): error while submitting query 10(13882) ERROR: ims_usrloc_scscf [usrloc_db.c:1086]: db_link_contact_to_impu(): Unable to link impu-contact in DB - impu [sip:rafi@mnc001.mcc001.3gppnetwork.org], contact [sip:rafi@192.168.10.48:57230;transport=udp] 10(13882) ERROR: ims_usrloc_scscf [impurecord.c:1227]: link_contact_to_impu(): Failed to update DB linking contact [sip:rafi@192.168.10.48:57230;transport=udp] to IMPU [sip:rafi@mnc001.mcc001.3gppnetwork.org]...continuing but db will be out of sync! 10(13882) DEBUG: ims_usrloc_scscf [udomain.c:852]: unref_contact_unsafe(): decrementing ref count on contact [sip:rafi@192.168.10.48:57230;transport=udp], was 2 Best Regards, Rafael A.

1 0

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