sr-dev August 2016

sr-dev@lists.kamailio.org

25 participants
197 discussions

[kamailio] [4.2.6] kamailio does not work when Recv-Q is high... (#510)
by BroWater 14 Sep '16

14 Sep '16

Steps: (1) 9 users and 1 mcu registered the server (2) All 9 users connect to the mcu through the server (3) For a while, some users showed registration fail, we found Kamailio does not respond to any further SIP message. I checked this using `netstat -apn` and it showed: ``` Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 10.100.92.42:5060 0.0.0.0:* … [View More] LISTEN 9384/kamailio tcp 0 0 10.100.92.42:5061 0.0.0.0:* LISTEN 9384/kamailio tcp 48963 0 10.100.92.42:5060 10.100.92.42:42177 ESTABLISHED 9375/kamailio tcp 29621 0 10.100.92.42:5060 10.100.92.40:34392 ESTABLISHED 9375/kamailio tcp 1617 0 10.100.92.42:43997 10.100.92.42:5062 ESTABLISHED 9375/kamailio tcp 2506 0 10.100.92.42:5060 10.100.92.68:37386 ESTABLISHED 9383/kamailio udp 0 0 127.0.0.1:50180 127.0.0.1:7722 ESTABLISHED 9384/kamailio udp 0 0 127.0.0.1:47125 127.0.0.1:7722 ESTABLISHED 9378/kamailio udp 0 0 127.0.0.1:55318 127.0.0.1:7722 ESTABLISHED 9375/kamailio udp 0 0 127.0.0.1:44595 127.0.0.1:7722 ESTABLISHED 9382/kamailio udp 0 0 127.0.0.1:41045 127.0.0.1:7722 ESTABLISHED 9383/kamailio udp 0 0 127.0.0.1:52901 127.0.0.1:7722 ESTABLISHED 9380/kamailio udp 0 0 127.0.0.1:39078 127.0.0.1:7722 ESTABLISHED 9376/kamailio udp 0 0 127.0.0.1:36548 127.0.0.1:7722 ESTABLISHED 9377/kamailio udp 0 0 127.0.0.1:55005 127.0.0.1:7722 ESTABLISHED 9374/kamailio udp 0 0 127.0.0.1:53049 127.0.0.1:7722 ESTABLISHED 9381/kamailio udp 0 0 127.0.0.1:44358 127.0.0.1:7722 ESTABLISHED 9374/kamailio udp 0 0 127.0.0.1:60253 127.0.0.1:7722 ESTABLISHED 9379/kamailio udp 0 0 10.100.92.42:5060 0.0.0.0:* 9374/kamailio udp 0 0 ::ffff:127.0.0.1:7722 :::* 9354/rtpengine raw 0 0 0.0.0.0:255 0.0.0.0:* 255 9374/kamailio ``` And I attached the gdb to the those processed which Recv-Q value were high, it showed: PID [9375] ``` #0 0x400a7450 in recvfrom () from /lib/libpthread.so.0 No symbol table info available. #1 0x00265848 in udp_rcv_loop () at udp_server.c:446 len = 472 buf = "REGISTER sip:10.100.92.42:5060 SIP/2.0\r\nVia: SIP/2.0/UDP 10.100.91.13:5060;rport;branch=z9hG4bK649620372\r\nFrom: <sip:DEMOROOM_2@10.100.92.42>;tag=658334621\r\nTo: <sip:DEMOROOM_2@10.100.92.42>\r\nCall-ID:"... tmp = 0x49fbfc "10.100.92.43" from = 0x402d5b24 fromlen = 16 ri = {src_ip = {af = 2, len = 4, u = {addrl = {224093194, 3200776404, 1935216, 1734536862}, addr32 = {224093194, 3200776404, 1935216, 1734536862}, addr16 = {25610, 3419, 63700, 48839, 34672, 29, 61086, 26466}, addr = "\nd[\r\324\370\307\276p\207\035\000\236\356bg"}}, dst_ip = {af = 2, len = 4, u = {addrl = {710697994, 0, 0, 0}, addr32 = {710697994, 0, 0, 0}, addr16 = {25610, 10844, 0, 0, 0, 0, 0, 0}, addr = "\nd\\*", '\000' <repeats 11 times>}}, src_port = 5060, dst_port = 5060, proto_reserved1 = 0, proto_reserved2 = 0, src_su = {s = {sa_family = 2, sa_data = "\023\304\nd[\r\000\000\000\000\000\000\000"}, sin = { sin_family = 2, sin_port = 50195, sin_addr = {s_addr = 224093194}, sin_zero = "\000\000\000\000\000\000\000"}, sin6 = {sin6_family = 2, sin6_port = 50195, sin6_flowinfo = 224093194, sin6_addr = {__in6_u = {__u6_addr8 = '\000' <repeats 15 times>, __u6_addr16 = {0, 0, 0, 0, 0, 0, 0, 0}, __u6_addr32 = {0, 0, 0, 0}}}, sin6_scope_id = 0}}, bind_address = 0x40261e14, proto = 1 '\001'} __FUNCTION__ = "udp_rcv_loop" #2 0x000c90a0 in main_loop () at main.c:1629 i = 0 pid = 0 si = 0x40261e14 si_desc = "udp receiver child=0 sock=10.100.92.42:5060\000\244\372\307\276\304y2A\000\000,\000\000\000X\000 \000\062@ \313'@h\t;\000\230\325&@\000\000\000\000x\021\002\000\060K1@\000\000\000\000d\372\307\276\260\275'\000\230\331\070\000X\311\070\000\030\000\000\000\000PVA\000\000\000\000\000\000\a@Lu\223A" r = 1074200576 nrprocs = 1 __FUNCTION__ = "main_loop" #3 0x000d0830 in main (argc=5, argv=0xbec7fd04) at main.c:2581 cfg_stream = 0x4b5008 c = -1 r = 0 tmp = 0x40070ac4 "P\002\006@\a" tmp_len = -1094190232 port = 1074045560 proto = -1094190164 options = 0x383880 ":f:cm:M:dVIhEeb:l:L:n:vKrRDTN:W:w:t:u:g:P:G:SQ:O:a:A:" ret = -1 seed = 3985271057 rfd = 206 debug_save = 0 debug_flag = 0 dont_fork_cnt = 0 n_lst = 0x0 p = 0x5 <Address 0x5 out of bounds> __FUNCTION__ = "main" ``` PID [9383] ``` #0 0x400a6a04 in __lll_lock_wait () from /lib/libpthread.so.0 #1 0x400a10b8 in pthread_mutex_lock () from /lib/libpthread.so.0 #2 0x002145b4 in tcpconn_do_send (fd=21, c=0x41969534, buf=0x402cbcb0 "SIP/2.0 200 Keepalive\r\nVia: SIP/2.0/TCP 10.100.92.42:5062;rport=42177;branch=z9hG4bK416855936;received=10.100.92.42\r\nFrom: <sip:10.100.92.42:42177>;tag=1996784611\r\nTo: <sip:10.100.92.42:5060>;tag=e926"..., len=340, send_flags=..., resp=0xbec7daf8, locked=0) at tcp_main.c:2520 #3 0x002130f0 in tcpconn_send_put (c=0x41969534, buf=0x402cbcb0 "SIP/2.0 200 Keepalive\r\nVia: SIP/2.0/TCP 10.100.92.42:5062;rport=42177;branch=z9hG4bK416855936;received=10.100.92.42\r\nFrom: <sip:10.100.92.42:42177>;tag=1996784611\r\nTo: <sip:10.100.92.42:5060>;tag=e926"..., len=340, send_flags=...) at tcp_main.c:2377 #4 0x002105c0 in tcp_send (dst=0xbec7e38c, from=0x0, buf=0x402cbcb0 "SIP/2.0 200 Keepalive\r\nVia: SIP/2.0/TCP 10.100.92.42:5062;rport=42177;branch=z9hG4bK416855936;received=10.100.92.42\r\nFrom: <sip:10.100.92.42:42177>;tag=1996784611\r\nTo: <sip:10.100.92.42:5060>;tag=e926"..., len=340) at tcp_main.c:2133 #5 0x40e33164 in msg_send (dst=0xbec7e38c, buf=0x402cbcb0 "SIP/2.0 200 Keepalive\r\nVia: SIP/2.0/TCP 10.100.92.42:5062;rport=42177;branch=z9hG4bK416855936;received=10.100.92.42\r\nFrom: <sip:10.100.92.42:42177>;tag=1996784611\r\nTo: <sip:10.100.92.42:5060>;tag=e926"..., len=340) at ../../forward.h:225 #6 0x40e362e8 in sl_reply_helper (msg=0x40342814, code=200, reason=0x402e1d6c "Keepalive", tag=0x0) at sl_funcs.c:224 #7 0x40e373e0 in sl_send_reply (msg=0x40342814, code=200, reason=0x402e1d6c "Keepalive") at sl_funcs.c:327 #8 0x40e2b30c in w_sl_send_reply (msg=0x40342814, p1=0x40282108 "\244\324(@\001", p2=0x40282140 "d\320(@ ") at sl.c:236 #9 0x00029b90 in do_action (h=0xbec7f110, a=0x4028cf34, msg=0x40342814) at action.c:1100 #10 0x00036ce8 in run_actions (h=0xbec7f110, a=0x4028cf34, msg=0x40342814) at action.c:1583 #11 0x00029a2c in do_action (h=0xbec7f110, a=0x4028d120, msg=0x40342814) at action.c:1079 #12 0x00036ce8 in run_actions (h=0xbec7f110, a=0x40288ed8, msg=0x40342814) at action.c:1583 #13 0x000263ac in do_action (h=0xbec7f110, a=0x40279db8, msg=0x40342814) at action.c:712 #14 0x00036ce8 in run_actions (h=0xbec7f110, a=0x4027321c, msg=0x40342814) at action.c:1583 #15 0x00037538 in run_top_route (a=0x4027321c, msg=0x40342814, c=0x0) at action.c:1669 #16 0x0013ce80 in receive_msg ( buf=0x41969714 "OPTIONS sip:10.100.92.42:5060 SIP/2.0\r\nVia: SIP/2.0/TCP 10.100.92.42:5062;rport;branch=z9hG4bK416855936\r\nFrom: <sip:10.100.92.42:42177>;tag=1996784611\r\nTo: <sip:10.100.92.42:5060>\r\nCall-ID: 2059319404"..., len=404, rcv_info=0x4196955c) at receive.c:216 #17 0x00248fbc in receive_tcp_msg ( tcpbuf=0x41969714 "OPTIONS sip:10.100.92.42:5060 SIP/2.0\r\nVia: SIP/2.0/TCP 10.100.92.42:5062;rport;branch=z9hG4bK416855936\r\nFrom: <sip:10.100.92.42:42177>;tag=1996784611\r\nTo: <sip:10.100.92.42:5060>\r\nCall-ID: 2059319404"..., len=404, rcv_info=0x4196955c, con=0x41969534) at tcp_read.c:1230 #18 0x0024c484 in tcp_read_req (con=0x41969534, bytes_read=0xbec7f714, read_flags=0xbec7f70c) at tcp_read.c:1431 #19 0x0024fdd8 in handle_io (fm=0x403321ac, events=1, idx=-1) at tcp_read.c:1655 #20 0x0023f814 in io_wait_loop_epoll (h=0x47d90c, t=2, repeat=0) at io_wait.h:1073 #21 0x00250fc8 in tcp_receive_loop (unix_sock=22) at tcp_read.c:1764 #22 0x00234674 in tcp_init_children () at tcp_main.c:4879 #23 0x000c9dec in main_loop () at main.c:1714 #24 0x000d0830 in main (argc=5, argv=0xbec7fd04) at main.c:2581 ``` In process 9375, I found it got stuck in recvfrom () (udp_server.c:446), and the code is: `len=recvfrom(bind_address->socket, buf, BUF_SIZE, 0, &from->s,&fromlen);` It seems operate using blocking mode instead of a non-blocking one, why??? Or maybe I miss a packet-check function like select() or poll()?? Thanks in advance. :) --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/510 [View Less]

2 9

[kamailio/kamailio] textops: get_body_part doesn't detect multipart headers ending (#564)
by foucse 13 Sep '16

13 Sep '16

When I use get_body_part on a multipart body, it doesn't detect properly the ending of multipart headers: For instance in: ``` --vvemeemm0wqr7ayc5h367f3v8e66mc9t Content-Type: application/sdp Content-Length: 479 v=0 o=- 3669362310 3669362310 IN IP4 192.168.2.4 [...] ``` "Content-Length: 479" is taken into get_body_part("application/sdp", "$var(sdp)"); I will try to provide more details later. --- You are receiving this because you are subscribed to this thread. Reply to this email directly … [View More]

4 7

[kamailio/kamailio] Calling jsonrpc_notification fail in failure route when fr_timer timeout (#713)
by Ian Yu-Hsun Lin 13 Sep '16

13 Sep '16

## Environment Kamailio 4.3.3 Ubuntu 14.04.1 x86_64 ## Problem I'm using `t_suspend()` and `t_continue()` for mobile push notification scenario. Before calling `t_suspend()` I set the `fr_timer` to 12 seconds and `t_on_failure()` to my custom failure route (e.g. `failure_route[MY_FAILURE_ROUTE]`). The scenario is fairly similar to [[SR-Users] Timeout after t_suspend and failure route][1], the only difference is I try to use `jsonrpc_notificaion()` to notify the user asynchronously in my … [View More]

2 5

[kamailio/kamailio] Kamailio 4.4) sipcapture_module: ERROR: parse_msg: message=<HEP3#003�> (#599)
by goseeped 12 Sep '16

12 Sep '16

The sipcapture module works great when you send hepv3 packets over the UDP transport however if kamailio start listening those hepv3 packtes on TCP and sending those hepv3 on TCP it will concern about it. **This is what Kamilio receives over TCP.** > T 52.10.155.177:47283 -> 172.19.8.21:9060 [AP] > HEP3.0................... > ......... > ...........[............. > W*y6... > . > ..h...... > .................OPTIONS sip:edge.rarevase.com;transport=tcp SIP/2.0. > … [View More]Via: SIP/2.0/TCP 172.19.16.130:53083;rport;branch=z9hG4bKPj66df463f-ca4b-4f98-ba17-722fe3fc4a92;alias. > From: <sip:asterisk@172.19.16.130>;tag=86ebab1d-eb4e-4986-898d-c7392b6b747b. > To: <sip:edge.rarevase.com>. > Contact: <sip:asterisk@172.19.16.130:53083;transport=TCP>. > Call-ID: ed24ab3c-4f42-4a9d-8e2d-9a3acd5b5b70. > CSeq: 3809 OPTIONS. > Max-Forwards: 70. > User-Agent: Asterisk PBX 13.8.0. > Content-Length: 0. > . > > ## > T 52.10.155.177:47283 -> 172.19.8.21:9060 [AP] > HEP3.\................... > ......... > ...................[..... > W*y6... > . > ..|...... > .................SIP/2.0 200 OK. > Via: SIP/2.0/TCP 172.19.16.130:53083;rport=53083;received=172.19.16.130;branch=z9hG4bKPj66df463f-ca4b-4f98-ba17-722fe3fc4a92;alias. > From: <sip:asterisk@172.19.16.130>;tag=86ebab1d-eb4e-4986-898d-c7392b6b747b. > To: <sip:edge.rarevase.com>;tag=24voZr. > Call-ID: ed24ab3c-4f42-4a9d-8e2d-9a3acd5b5b70. > CSeq: 3809 OPTIONS. > Max-Forwards: 70. > Content-Length: 0. > Supported: path,gruu,outbound. > Accept: */*. > Allow: INVITE,ACK,CANCEL,BYE,OPTIONS,INFO,UPDATE,SUBSCRIBE,NOTIFY,REFER,MESSAGE,REGISTER. > . > **This are the logs on the Kamailio.** `May 4 22:44:05 ip-172-19-8-21 /usr/sbin/kamailio[19285]: INFO: <core> [parser/parse_fline.c:144]: parse_first_line(): ERROR:parse_first_line: method not followed by SP May 4 22:44:05 ip-172-19-8-21 /usr/sbin/kamailio[19285]: ERROR: <core> [parser/parse_fline.c:257]: parse_first_line(): parse_first_line: bad message (offset: 0) May 4 22:44:05 ip-172-19-8-21 /usr/sbin/kamailio[19285]: DEBUG: <core> [parser/msg_parser.c:604]: parse_msg(): parse_msg: invalid message May 4 22:44:05 ip-172-19-8-21 /usr/sbin/kamailio[19285]: ERROR: <core> [parser/msg_parser.c:690]: parse_msg(): ERROR: parse_msg: message=<HEP3#003<98>> May 4 22:44:05 ip-172-19-8-21 /usr/sbin/kamailio[19285]: ERROR: <core> [receive.c:173]: receive_msg(): core parsing of SIP message failed (52.10.155.177:59607/2)` --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/599 [View Less]

4 9

[kamailio/kamailio] move kamailio/utils/misc/vim/ to a git submodule (#763)
by Marcelo D Montu 08 Sep '16

08 Sep '16

The Vim plugin is very nice, and its use isn't restricted to machines where Kamailio is installed, as the config file can be edited via network (e.g.: using netrw plugin). Currently the most common approach to retrieve a Vim plugin is to clone its GitHub repo and use some plugin manager, such as [pathogen](https://github.com/tpope/vim-pathogen). But it clearly doesn't make sense to retrieve the complete Kamailio repo only to use the vim plugin; this probably caused the creation of [duplicates]… [View More]

4 12

[kamailio/kamailio] preprocessor directives and !trydef names (#743)
by lazedo 07 Sep '16

07 Sep '16

hi, in top level kamailio config file (kamailio.cfg) i have this defined ``` #!ifdef TRAFFIC_FILTER-ROLE include_file "traffic-filter-role.cfg" #!endif ... ####### Routing Logic ######## route { ... #!ifdef TRAFFIC_FILTER-ROLE route(TRAFFIC_FILTER); #!endif ... } ``` and in "traffic-filter-role.cfg" i have ``` route[TRAFFIC_FILTER] { ... } ``` it seems that kamailio thinks that `TRAFFIC_FILTER-ROLE` and `TRAFFIC_FILTER` are the same. ``` 0(8619) : <core> [cfg.y:3368]: … [View More]

2 3

[kamailio/kamailio] Segfault when working as sipcapture node (#723)
by Sebastian Damm 07 Sep '16

07 Sep '16

We are running Kamailio 4.4.2 as a sipcapture node and every now and then it crashes. This is what the backtrace says: ``` (gdb) bt #0 get_str_fparam (dst=dst@entry=0x7ffe50aa0610, msg=msg@entry=0x7f105b8654b8, param=param@entry=0x1a) at sr_module.c:1650 #1 0x00007f1059213346 in w_report_capture (_m=0x7f105b8654b8, _table=0x7f105b8648b8 " \250q[\020\177", _corr=0x7f105b864938 "\230\237q[\020\177", _data=0x1a <Address 0x1a out of bounds>) at sipcapture.c:1040 #2 0x000000000042b618 … [View More]in do_action (h=h@entry=0x7ffe50aa3ab0, a=a@entry=0x7f105b719640, msg=msg@entry=0x7f105b8654b8) at action.c:1060 #3 0x000000000042a10a in run_actions (h=h@entry=0x7ffe50aa3ab0, a=0x7f105b718530, msg=msg@entry=0x7f105b8654b8) at action.c:1549 #4 0x000000000042bcf2 in do_action (h=h@entry=0x7ffe50aa3ab0, a=a@entry=0x7f105b71a1e8, msg=msg@entry=0x7f105b8654b8) at action.c:1049 #5 0x000000000042a10a in run_actions (h=h@entry=0x7ffe50aa3ab0, a=0x7f105b71a1e8, msg=msg@entry=0x7f105b8654b8) at action.c:1549 #6 0x000000000042bcf2 in do_action (h=h@entry=0x7ffe50aa3ab0, a=a@entry=0x7f105b71a318, msg=msg@entry=0x7f105b8654b8) at action.c:1049 #7 0x000000000042a10a in run_actions (h=h@entry=0x7ffe50aa3ab0, a=0x7f105b71a318, msg=msg@entry=0x7f105b8654b8) at action.c:1549 #8 0x000000000042bcf2 in do_action (h=h@entry=0x7ffe50aa3ab0, a=a@entry=0x7f105b71a448, msg=msg@entry=0x7f105b8654b8) at action.c:1049 #9 0x000000000042a10a in run_actions (h=h@entry=0x7ffe50aa3ab0, a=0x7f105b71a448, msg=msg@entry=0x7f105b8654b8) at action.c:1549 #10 0x000000000042bcf2 in do_action (h=h@entry=0x7ffe50aa3ab0, a=a@entry=0x7f105b71a578, msg=msg@entry=0x7f105b8654b8) at action.c:1049 #11 0x000000000042a10a in run_actions (h=h@entry=0x7ffe50aa3ab0, a=0x7f105b71a578, msg=msg@entry=0x7f105b8654b8) at action.c:1549 #12 0x000000000042bcf2 in do_action (h=h@entry=0x7ffe50aa3ab0, a=a@entry=0x7f105b719888, msg=msg@entry=0x7f105b8654b8) at action.c:1049 #13 0x000000000042a10a in run_actions (h=h@entry=0x7ffe50aa3ab0, a=0x7f105b719888, msg=msg@entry=0x7f105b8654b8) at action.c:1549 #14 0x000000000042bcf2 in do_action (h=h@entry=0x7ffe50aa3ab0, a=a@entry=0x7f105b7199b8, msg=msg@entry=0x7f105b8654b8) at action.c:1049 #15 0x000000000042a10a in run_actions (h=h@entry=0x7ffe50aa3ab0, a=0x7f105b7199b8, msg=msg@entry=0x7f105b8654b8) at action.c:1549 #16 0x000000000042bcf2 in do_action (h=h@entry=0x7ffe50aa3ab0, a=a@entry=0x7f105b719ae8, msg=msg@entry=0x7f105b8654b8) at action.c:1049 #17 0x000000000042a10a in run_actions (h=h@entry=0x7ffe50aa3ab0, a=0x7f105b719ae8, msg=msg@entry=0x7f105b8654b8) at action.c:1549 #18 0x000000000042bcf2 in do_action (h=h@entry=0x7ffe50aa3ab0, a=a@entry=0x7f105b719c18, msg=msg@entry=0x7f105b8654b8) at action.c:1049 #19 0x000000000042a10a in run_actions (h=h@entry=0x7ffe50aa3ab0, a=a@entry=0x7f105b6abc80, msg=msg@entry=0x7f105b8654b8) at action.c:1549 #20 0x00000000004375d0 in run_top_route (a=0x7f105b6abc80, msg=msg@entry=0x7f105b8654b8, c=c@entry=0x0) at action.c:1635 #21 0x0000000000504386 in receive_msg ( buf=buf@entry=0xa366b7 "PUBLISH sip:collector@109.68.96.98:5099 SIP/2.0\r\nVia: SIP/2.0/UDP 192.168.178.32:5060;branch=z9hG4bK122ceb41cd4777873\r\nRoute: <sip:proxy.live.sipgate.de:5060;lr>\r\nMax-Forwards: 70\r\nFrom: \"2362760e6\" <"..., len=<optimized out>, len@entry=728, rcv_info=rcv_info@entry=0x7ffe50aa3e80) at receive.c:240 #22 0x00007f105920ce17 in parsing_hepv3_message (buf=<optimized out>, len=<optimized out>) at hep.c:498 #23 0x00007f105920e80d in hepv3_received (buf=<optimized out>, len=<optimized out>, ri=<optimized out>) at hep.c:230 #24 0x00000000005f6e17 in udp_rcv_loop () at udp_server.c:446 #25 0x00000000004b2625 in main_loop () at main.c:1600 #26 0x0000000000427e2b in main (argc=<optimized out>, argv=<optimized out>) at main.c:2616 (gdb) ``` Does anybody see anything already? We can provide more info if needed. (And since it's the sipcapture module: @adubovikov) --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/723 [View Less]

4 22

[kamailio/kamailio] Kamailio crushes when tcp errors invalid fd -1 (#748)
by mbike2000ru 07 Sep '16

07 Sep '16

Hi Kamailio crushes with lots of such CRITICAL errors: Aug 16 15:09:48 kam-fe1 kamailio[8485]: CRITICAL: <core> [tcp_read.c:1654]: handle_io(): io_watch_del failed for 0x7f3e610a3a70 id 105 fd -1, state -1, flags 4028, main fd -1, refcnt -2117 ([178.209.103.226]:40855 -> [178 .209.103.226]:5060) Aug 16 15:09:48 kam-fe1 kamailio[8479]: CRITICAL: <core> [io_wait.h:594]: io_watch_del(): invalid fd -1, not in [0, 23) Aug 16 15:09:48 kam-fe1 kamailio[8481]: WARNING: <core> [… [View More]

2 14

[kamailio/kamailio] Permissions module RPC array issue (#747)
by kelchy 06 Sep '16

06 Sep '16

using 4.4.2 on kamctl kamcmd permissions.addressDump { table: 80 group: 5 item: { ip: 6x.x4.1x7.10 port: 50060 tag: 0 } table: 120 group: 8 item: { ip: 1x8.1x4.1x6.19 port: 50060 tag: 0 } table: 122 group: 7 item: { ip: 1x8.1x4.1x6.17 port: 50060 tag: 0 } table: 122 group: 6 item: { ip: 1x8.1x4.1x6.17 port: 50060 tag: 0 } } on jsonrpc-s { jsonrpc: '2.0', result: { table: 122, group: 6, item: { ip: '1x8.1x4.1x6.17', port: 50060, tag: '0'… [View More]

2 3

[kamailio/kamailio] 4.3 (#758)
by Kevin Scott Adams 02 Sep '16

02 Sep '16

Terminated all LM_-based statement messages with new line characters You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/758 -- Commit Summary -- * Code formatting changes. * Terminate all LM_* statement messages with a new line. -- File Changes -- M modules/sca/sca.c (567) M modules/sca/sca.h (36) M modules/sca/sca_appearance.c (2242) M modules/sca/sca_appearance.h (187) M modules/sca/sca_call_info.c (3555) … [View More]

2 8

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev August 2016