I am currently trying to replace a pure-Asterisk implementation of SIP messaging through Websockets, with a Kamailio-4.1.2-based implementation. However, when I try to send a message with jsSIP, Kamailio crashes:
Program terminated with signal 11, Segmentation fault. #0 0x00007f0e5cf31be3 in reg_ht_get_byuuid (uuid=0x7fff59734b00) at uac_reg.c:350 350 slot = reg_get_entry(hash, _reg_htable->htsize); Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.132.el6.x86_64 keyutils-libs-1.4-4.el6.x86_64 krb5-libs-1.10.3-10.el6_4.6.x86_64 libcom_err-1.41.12-18.el6.x86_64 libgcc-4.4.7-4.el6.x86_64 libselinux-2.0.94-5.3.el6_4.1.x86_64 libtool-ltdl-2.2.6-15.5.el6.x86_64 libunistring-0.9.3-5.el6.x86_64 libxml2-2.7.6-14.el6.x86_64 mysql-connector-odbc-5.1.5r1144-7.el6.x86_64 mysql-libs-5.1.73-3.el6_5.x86_64 nss-softokn-freebl-3.14.3-9.el6.x86_64 openssl-1.0.1e-16.el6_5.4.x86_64 unixODBC-2.2.14-12.el6_3.x86_64 zlib-1.2.3-29.el6.x86_64 (gdb) bt #0 0x00007f0e5cf31be3 in reg_ht_get_byuuid (uuid=0x7fff59734b00) at uac_reg.c:350 #1 0x00007f0e5cf36c71 in uac_reg_lookup (msg=0x7f0e6271e790, src=0x7fff59734b00, dst=0x7f0e6267c950, mode=0) at uac_reg.c:924 #2 0x00007f0e5cf2f991 in w_uac_reg_lookup (msg=0x7f0e6271e790, src=0x7f0e6267e0d0 "\a", dst=0x7f0e6267c950 "\006") at uac.c:560 #3 0x0000000000419bf6 in do_action (h=0x7fff59735690, a=0x7f0e6267f1e0, msg=0x7f0e6271e790) at action.c:1111 #4 0x0000000000422878 in run_actions (h=0x7fff59735690, a=0x7f0e6267e510, msg=0x7f0e6271e790) at action.c:1599 #5 0x0000000000417900 in do_action (h=0x7fff59735690, a=0x7f0e62664aa0, msg=0x7f0e6271e790) at action.c:715 #6 0x0000000000422878 in run_actions (h=0x7fff59735690, a=0x7f0e6265d3b8, msg=0x7f0e6271e790) at action.c:1599 #7 0x0000000000423017 in run_top_route (a=0x7f0e6265d3b8, msg=0x7f0e6271e790, c=0x0) at action.c:1685 #8 0x00000000004a5153 in receive_msg ( buf=0x7f0e570d0168 "MESSAGE sip:admin@gatitos.com SIP/2.0\r\nVia: SIP/2.0/WS ftisg2dgtaqe.invalid;branch=z9hG4bK2656184\r\nMax-Forwards: 16\r\nTo: sip:admin@gatitos.com\r\nFrom: "Alex Villacís Lasso" <sip:avillacisIM@gatitos."..., len=585, rcv_info=0x7f0e570cfe90) at receive.c:212 #9 0x00007f0e5c8e5802 in ws_frame_receive (data=0x7fff59735a40) at ws_frame.c:652 #10 0x000000000045531c in sr_event_exec (type=10, data=0x7fff59735a40) at events.c:254 #11 0x000000000052e04e in ws_process_msg ( tcpbuf=0x7f0e570d0160 "\201\376\002I\032\327\302\344MESSAGE sip:admin@gatitos.com SIP/2.0\r\nVia: SIP/2.0/WS ftisg2dgtaqe.invalid;branch=z9hG4bK2656184\r\nMax-Forwards: 16\r\nTo: sip:admin@gatitos.com\r\nFrom: "Alex Villacís Lasso" <sip:avillacisIM@"..., len=593, rcv_info=0x7f0e570cfe90, con=0x7f0e570cfe78) at tcp_read.c:1146 #12 0x000000000052e21f in receive_tcp_msg ( tcpbuf=0x7f0e570d0160 "\201\376\002I\032\327\302\344MESSAGE sip:admin@gatitos.com SIP/2.0\r\nVia: SIP/2.0/WS ftisg2dgtaqe.invalid;branch=z9hG4bK2656184\r\nMax-Forwards: 16\r\nTo: sip:admin@gatitos.com\r\nFrom: "Alex Villacís Lasso" <sip:avillacisIM@"..., len=593, rcv_info=0x7f0e570cfe90, con=0x7f0e570cfe78) at tcp_read.c:1182 #13 0x000000000052f2f3 in tcp_read_req (con=0x7f0e570cfe78, bytes_read=0x7fff59735cac, read_flags=0x7fff59735ca4) at tcp_read.c:1383 #14 0x0000000000530d27 in handle_io (fm=0x7f0e62724d30, events=1, idx=-1) at tcp_read.c:1617 #15 0x00000000005296c0 in io_wait_loop_epoll (h=0x8df220, t=2, repeat=0) at io_wait.h:1092 #16 0x0000000000531650 in tcp_receive_loop (unix_sock=53) at tcp_read.c:1728 #17 0x0000000000523c21 in tcp_init_children () at tcp_main.c:4959 #18 0x000000000046d6a3 in main_loop () at main.c:1702 #19 0x000000000047030b in main (argc=13, argv=0x7fff59736178) at main.c:2533
Is this a known bug?
El 04/04/14 16:26, Alex Villacís Lasso escribió:
For additional information, the segfault stems from dereferencing a NULL pointer at global variable '_reg_htable' declared at modules/uac/uac_reg.c , which in turn looks as if the process (or its parents before the fork()) failed to call uac_reg_init_ht() . This is confirmed by a patch to return NULL from reg_ht_get_byuuid() if _reg_htable is NULL - but this variable should not be uninitialized in the first place.
Hello,
can you share here the parameters for uac module?
Cheers, Daniel
On 09/04/14 00:23, Alex Villacís Lasso wrote:
El 09/04/14 03:11, Daniel-Constantin Mierla escribió:
Hello,
can you share here the parameters for uac module?
Currently there are no explicit parameters. All parameters are currently commented out: [root@elx3 ~]# grep uac /etc/kamailio/kamailio.cfg loadmodule "uac.so" #modparam("uac", "reg_db_url", DBASTURL) # uacreg table is actually a view in DBASTURL #modparam("uac", "reg_contact_addr", "127.0.0.1")
OK, that's the reason, the _reg_htable is initialized only when reg_db_url is set, otherwise there is no source of user profile to do registration for, and no point to do uac_reg_lookup().
I will add safety checks for this case.
Cheers, Daniel
On 09/04/14 18:30, Alex Villacís Lasso wrote:
The safety checks were pushed to master and 4.1 branches. Can you try with the latest git version and report the result?
Cheers, Daniel
On 09/04/14 18:43, Daniel-Constantin Mierla wrote:
El 09/04/14 12:36, Daniel-Constantin Mierla escribió:
The safety checks work, in the sense that the process no longer crashes. Before the crash, the websocket connection used to get disconnected after a timeout, so I am checking whether this is still the case now. Additionally I am getting these messages on the log:
Apr 9 15:42:14 elx3 /usr/sbin/kamailio[3051]: ERROR: <core> [resolve.c:1733]: sip_hostport2su(): ERROR: sip_hostport2su: could not resolve hostname: "o0f99a1p8fp7.invalid" Apr 9 15:42:14 elx3 /usr/sbin/kamailio[3051]: ERROR: tm [ut.h:337]: uri2dst2(): failed to resolve "o0f99a1p8fp7.invalid" Apr 9 15:42:14 elx3 /usr/sbin/kamailio[3051]: ERROR: tm [t_fwd.c:1773]: t_forward_nonack(): ERROR: t_forward_nonack: failure to add branches Apr 9 15:42:14 elx3 /usr/sbin/kamailio[3051]: ERROR: sl [sl_funcs.c:387]: sl_reply_error(): ERROR: sl_reply_error used: Unresolvable destination (478/SL) Apr 9 15:42:19 elx3 /usr/sbin/kamailio[3103]: ERROR: uac [uac_reg.c:363]: reg_ht_get_byuuid(): reg hash table not initialized Apr 9 15:42:19 elx3 /usr/sbin/kamailio[3103]: ERROR: uac [uac_reg.c:363]: reg_ht_get_byuuid(): reg hash table not initialized Apr 9 15:43:56 elx3 /usr/sbin/kamailio[3053]: ERROR: uac [uac_reg.c:363]: reg_ht_get_byuuid(): reg hash table not initialized Apr 9 15:43:56 elx3 /usr/sbin/kamailio[3053]: ERROR: uac [uac_reg.c:363]: reg_ht_get_byuuid(): reg hash table not initialized Apr 9 15:44:10 elx3 /usr/sbin/kamailio[3053]: ERROR: uac [uac_reg.c:363]: reg_ht_get_byuuid(): reg hash table not initialized Apr 9 15:44:10 elx3 /usr/sbin/kamailio[3053]: ERROR: uac [uac_reg.c:363]: reg_ht_get_byuuid(): reg hash table not initialized
How come nobody else using kamailio for websockets stumbled into this crash before?
The crash was not related to websocket at all, but to usage of uac_reg_lookup() when you don't set reg_db_url parameter for uac module.
So, my question is why are you using uac_reg_lookup()? Because it is useless if you dont set reg_db_url and you don't have records in uacreg database table. This function is related to the feature of kamailio to send register to another sip server with a contact address pointing back to kamailio.
To summarize on another words, the crash happened because the kamailio.cfg didn't have set the expected uac module parameters by uac_reg_lookup() function.
Cheers, Daniel
On 09/04/14 22:56, Alex Villacís Lasso wrote:
El 09/04/14 16:17, Daniel-Constantin Mierla escribió:
I was using uac_reg_lookup() without reg_db_url because it appeared to be performing the same job as a pair of uac_restore_from() and uac_restore_to(). I have made corresponding fixes in my configuration file.
However, the previously mentioned issue of abrupt disconnection persists. I get this in the logfiles:
Apr 9 17:22:23 elx3 /usr/sbin/kamailio[8573]: WARNING: websocket [ws_frame.c:868]: ws_keepalive(): forcibly closing connection
At the same time, I get the following sequence of javascript messages in the Firefox browser:
JsSIP | TRANSPORT | WebSocket disconnected (code: 1006) jssip-0.3.0.js (línea 610) JsSIP | TRANSPORT | WebSocket abrupt disconnection jssip-0.3.0.js (línea 613) JsSIP | UA | connection state set to 1 jssip-0.3.0.js (línea 5236) JsSIP | TRANSACTION | transport error occurred, deleting non-INVITE client transaction z9hG4bK3602966 jssip-0.3.0.js (línea 1839) JsSIP | EVENT EMITTER | emitting event registrationFailed jssip-0.3.0.js (línea 187)
SIP registration error: Connection Error
uf.js (línea 569)
The code in uf.js retries the connection, but eventually it times out again.
-
Alex Villacís Lasso -
Daniel-Constantin Mierla