sr-dev February 2016

sr-dev@lists.kamailio.org

28 participants
302 discussions

[kamailio] [4.2.6] kamailio does not work when Recv-Q is high... (#510)

by BroWater

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:* 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

7 years, 7 months

[kamailio] uac module (uac_req_send, register) doesn't do failover (#210)

by Alex

Requests send with uac module's functions like uac_req_send() and remote registrations use the TM module, but don't actually do (DNS) failover when a destination is unreachable or sends a 503. In the tm's uac.c, t_uac_prepare() function, i can already see that the dns handle is stored in a throwaway variable instead of in the transaction, but fixing the issue isn't as simple as just storing it in the transaction (print_uac_request_from_buf() needs a uas in the transaction). Due to github not supporting attachments to issues, the sample config and debug log are inline.... :( DNS entry: ``` $ host -t SRV _sip._udp.failover.test.speakup.nl _sip._udp.failover.test.speakup.nl has SRV record 10 0 1111 try1.test.speakup.nl. _sip._udp.failover.test.speakup.nl has SRV record 100 0 2222 try2.test.speakup.nl. ``` Log snippet: ```syslog Jun 15 10:00:03 rio UACFailover[18178]: INFO: <script>: Sending OPTIONS request to sip:failover.test.speakup.nl Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: tm [uac.c:249]: t_uac_prepare(): DEBUG:tm:t_uac: next_hop=<sip:failover.test.speakup.nl> Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [dns_cache.c:537]: _dns_hash_find(): (_sip._udp.failover.test.speakup.nl(34), 33), h=825 Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [resolve.c:937]: get_record(): skipping 8 NS (p=0x9ea284, end=0x9ea3e9) Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [resolve.c:952]: get_record(): parsing 9 ARs (p=0x9ea335, end=0x9ea3e9) Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [dns_cache.c:1741]: dns_get_related(): (0x7f225233eb38 (_sip._udp.failover.test.speakup.nl, 33), 33, *0x7f2257baf2b8) (0) Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [dns_cache.c:840]: dns_cache_add_unsafe(): adding _sip._udp.failover.test.speakup.nl(34) 33 (flags=0) at 825 Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [dns_cache.c:840]: dns_cache_add_unsafe(): adding try1.test.speakup.nl(20) 1 (flags=0) at 310 Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [dns_cache.c:840]: dns_cache_add_unsafe(): adding try2.test.speakup.nl(20) 1 (flags=0) at 307 Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [dns_cache.c:2336]: dns_srv_get_nxt_rr(): (0x7f225233eb38, 0, 0, 1597643831): selected 0/1 in grp. 0 (rand_w=0, rr=0x7f225233eba0 rd=0x7f225233ebb8 p=10 w=0 rsum=0) Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [dns_cache.c:537]: _dns_hash_find(): (try1.test.speakup.nl(20), 1), h=310 Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [dns_cache.c:2926]: dns_a_resolve(): (try1.test.speakup.nl, 0) returning 0 Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [dns_cache.c:3169]: dns_srv_resolve_ip(): ("_sip._udp.failover.test.speakup.nl", 0, 0), ret=0, ip=192.168.1.245 Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [dns_cache.c:3260]: dns_srv_sip_resolve(): (failover.test.speakup.nl, 0, 0), srv0, ret=0 Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: tm [uac.c:150]: dlg2hash(): DEBUG: dlg2hash: 54501 Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: tm [uac.c:351]: t_uac_prepare(): executing event_route[tm:local-request] Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [parser/msg_parser.c:606]: parse_msg(): SIP Request: Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [parser/msg_parser.c:608]: parse_msg(): method: <OPTIONS> Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [parser/msg_parser.c:610]: parse_msg(): uri: <sip:failover.test.speakup.nl> Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [parser/msg_parser.c:612]: parse_msg(): version: <SIP/2.0> Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [parser/parse_via.c:1254]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK5e4d.47adbbf5000000000000000000000000.0>; state=16 Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [parser/parse_via.c:2642]: parse_via(): end of header reached, state=5 Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [parser/msg_parser.c:496]: parse_headers(): parse_headers: Via found, flags=2 Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [parser/msg_parser.c:498]: parse_headers(): parse_headers: this is the first via Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [parser/parse_addr_spec.c:894]: parse_addr_spec(): end of header reached, state=10 Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [parser/msg_parser.c:173]: get_hdr_field(): DEBUG: get_hdr_field: <To> [22]; uri=[sip:to.example.com] Jun 15 10:00:03 rio UACFailover[18178]: [97B blob data] Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [parser/msg_parser.c:153]: get_hdr_field(): get_hdr_field: cseq <CSeq>: <10> <OPTIONS> Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: pv [pv_core.c:376]: pv_get_xto_attr(): no Tag parameter Jun 15 10:00:03 rio UACFailover[18178]: INFO: <script>: [udp:172.28.4.128:6789] [10 OPTIONS] Request (cid: 6cd531e47cc63e20-18178(a)172.28.4.128 Branch: -1 ToTag: <null> len:382) To <sip:failover.test.speakup.nl> via <sip:failover.test.speakup.nl> Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [usr_avp.c:631]: destroy_avp_list(): destroying list (nil) Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [usr_avp.c:631]: destroy_avp_list(): destroying list (nil) Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [usr_avp.c:631]: destroy_avp_list(): destroying list (nil) Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [usr_avp.c:631]: destroy_avp_list(): destroying list (nil) Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [usr_avp.c:631]: destroy_avp_list(): destroying list (nil) Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [usr_avp.c:631]: destroy_avp_list(): destroying list (nil) Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [xavp.c:446]: xavp_destroy_list(): destroying xavp list (nil) Jun 15 10:00:05 rio UACFailover[18176]: DEBUG: tm [t_reply.c:1230]: t_should_relay_response(): ->>>>>>>>> T_code=0, new_code=408 Jun 15 10:00:05 rio UACFailover[18176]: WARNING: tm [t_reply.c:957]: run_failure_handlers(): Warning: run_failure_handlers: no UAC support (1, 0) Jun 15 10:00:05 rio UACFailover[18176]: DEBUG: tm [t_reply.c:2016]: local_reply(): DEBUG: local_reply: branch=0, save=0, winner=0 Jun 15 10:00:05 rio UACFailover[18176]: DEBUG: tm [t_reply.c:2053]: local_reply(): DEBUG: local transaction completed ``` Sample config: ```python #------------------ # Flags #------------------ debug=3 memdbg=5 mem_summary=5 #fork=no # This option should not be present to enable forking but disable daemonize, also -D commandline parameter is needed log_stderror=no sip_warning=no listen=172.28.4.128 port=6789 children=2 shm_mem_size=64 log_name="UACFailover" check_via=no # (cmd. line: -v) dns=no # (cmd. line: -r) rev_dns=no # (cmd. line: -R) dns_use_search_list=no use_dns_failover=yes dns_srv_lb=yes disable_tcp=yes mpath="/usr/lib/x86_64-linux-gnu/kamailio/modules/" loadmodule "pv.so" loadmodule "tm.so" loadmodule "tmx.so" loadmodule "sl.so" loadmodule "xlog.so" loadmodule "rr.so" loadmodule "uac.so" loadmodule "rtimer.so" # ----------------------------------------------------------------- # Module settings # ----------------------------------------------------------------- modparam("pv", "varset", "server=s:LOGNAME") modparam("tm", "auto_inv_100", 0) # Time until provisional response (eg "100 Trying") is received modparam("tm", "fr_timer", 2000) # Time to await final response on INVITE per branch (eg per branch ring time) modparam("tm", "fr_inv_timer", 10000) # Time to await final response on INVITE (eg ring time) modparam("tm", "max_inv_lifetime", 20000) modparam("tm", "restart_fr_on_each_reply", 0) modparam("tm", "failure_reply_mode", 3) modparam("rtimer", "timer", "name=uac;interval=10;mode=1;") modparam("rtimer", "exec", "timer=uac;route=TIMER") route { xlog("L_NOTICE", "[$pr:$si:$sp] [$cs $rm] Request. (cid: $ci <$fu> => <$ru> len: $ml)"); drop(); } event_route[tm:local-request] { xlog("L_INFO", " [$pr:$si:$sp] [$cs $rm] Request (cid: $ci Branch: $T_branch_idx ToTag: $tt len:$ml) To <$ru> via <$du>"); } onreply_route { xlog("L_INFO", " [$pr:$si:$sp] [$cs $rm] Reply (cid: $ci Branch: $T_branch_idx Status: $rs $rr ToTag: $tt len:$ml)"); } route[TIMER] { if not $var(done) == 1 { $var(done) = 1; $uac_req(method) = "OPTIONS"; $uac_req(ruri) = "sip:failover.test.speakup.nl"; $uac_req(furi) = "sip:from.example.com"; $uac_req(turi) = "sip:to.example.com"; xlog("L_INFO", "Sending $uac_req(method) request to $uac_req(ruri)"); uac_req_send(); } } ``` --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/210

7 years, 7 months

git:master:b7c588df: tm: store last received response code before running onreply_route

by Daniel-Constantin Mierla

Module: kamailio Branch: master Commit: b7c588dff06030a82f305b210573be5bbc961cec URL: https://github.com/kamailio/kamailio/commit/b7c588dff06030a82f305b210573be5… Author: Daniel-Constantin Mierla <miconda(a)gmail.com> Committer: Daniel-Constantin Mierla <miconda(a)gmail.com> Date: 2015-09-07T15:56:45+02:00 tm: store last received response code before running onreply_route - otherwise an innapropriate cancel can happen if the current branch got before an 1xx response, and the script writer enforces another reply code with t_reply() - reported by Thomas Sevestre, GH#315 --- Modified: modules/tm/t_reply.c --- Diff: https://github.com/kamailio/kamailio/commit/b7c588dff06030a82f305b210573be5… Patch: https://github.com/kamailio/kamailio/commit/b7c588dff06030a82f305b210573be5… --- diff --git a/modules/tm/t_reply.c b/modules/tm/t_reply.c index b2e6e53..8da3205 100644 --- a/modules/tm/t_reply.c +++ b/modules/tm/t_reply.c @@ -2286,10 +2286,21 @@ int reply_received( struct sip_msg *p_msg ) backup_xavps = xavp_set_list(&t->xavps_list); #endif setbflagsval(0, uac->branch_flags); + if(msg_status>last_uac_status) { + /* current response (msg) status is higher that the last received + * on the same branch - set it temporarily so functions in onreply_route + * can access it (e.g., avoid sending CANCEL by forcing another t_relply() + * in onreply_route when a negative sip response was received) */ + uac->last_received = msg_status; + } + /* Pre- and post-script callbacks have already * been executed by the core. (Miklos) */ run_top_route(onreply_rt.rlist[onreply_route], p_msg, &ctx); + + /* restore brach last_received as before executing onreply_route */ + uac->last_received = last_uac_status; /* transfer current message context back to t */ if (t->uas.request) t->uas.request->flags=p_msg->flags; getbflagsval(0, &uac->branch_flags);

7 years, 8 months

[kamailio] Module:sca Line seize does not release after some 'bye's (#341)

by Kevin Scott Adams

I have a situation that I can't get my head around. Every so often I have a SCA seized and I need to manually release it. Here is the log of the sca and bye from the event logs. messages-20150920:Sep 18 14:35:28 sip-registrar /usr/sbin/kamailio[7608]: ERROR: sca [sca_call_info.c:1580]: sca_call_info_bye_handler(): sca_call_info_bye_handler: sip:Mindfield@kamailio.newgarllc.com dialog leg 96b9ad37-9a7fa462-15c35d3(a)192.168.1.117;1c389191866 is not active messages-20150920:Sep 18 14:35:28 sip-registrar /usr/sbin/kamailio[7610]: NOTICE: acc [acc.c:317]: acc_log_request(): ACC: transaction answered: timestamp=1442601328;method=BYE;from_tag=76C3EC1F-114D759A;to_tag=1c389191866;call_id=96b9ad37-9a7fa462-15c35d3(a)192.168.1.117;code=200;reason=OK;src_user=Mindfield;src_domain=kamailio.newgarllc.com;src_ip=192.168.1.40;dst_ouser=Mindfield;dst_user=Mindfield;dst_domain=192.168.1.117 And the kamcmd showing the seize line (in this case both are seized) sip:Mindfield@kamailio.newgarllc.com 1 active 1442601278 sip:Mindfield@192.168.1.117 sip:1030@192.168.1.40:5060 96b9ad37-9a7fa462-15c35d3(a)192.168.1.117 76C3EC1F-114D759A 1c389191866 I am running Kamailio 4.2.6. The phones are Polycom VVX 310/410 running 5.3.1. And the PSTN gateway is an Audiocodes Mediant 1000 running 6.60A.292.001. The call volume is light so I don't think there is a lot of traffic but there is about 16 phones one SCA. It is not happening all time. Could be a couple days that nothing happens and then there could be a couple days that it happens multiple times a day. I can't find a common element that would be causing this unless the 'bye' is closing the call before the SCA has a chance to do something with it. Thanks Kev --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/341

7 years, 9 months

[kamailio] SNMPstats dialog 0 afeter reboot (#424)

by igorPot

I have rebooted my kamailio machine and now the value of kamailio dialogs is always 0: KAMAILIO-MIB::kamailioCurNumDialogs.0 = Gauge32: 0 KAMAILIO-MIB::kamailioCurNumDialogsInProgress.0 = Gauge32: 0 KAMAILIO-MIB::kamailioCurNumDialogsInSetup.0 = Gauge32: 0 KAMAILIO-MIB::kamailioTotalNumFailedDialogSetups.0 = Counter32: 0 And also the status is: KAMAILIO-MIB::kamailioDialogUsageState.0 = INTEGER: idle(0) How can I change it to active(1)? I have dialog.so loaded as well as modparam("dialog", "dlg_flag", 4) and dlg_manage(). If I do 'kamctl stats dialog': # kamctl stats dialog dialog:active_dialogs = 498 dialog:early_dialogs = 57 dialog:expired_dialogs = 24 dialog:failed_dialogs = 73222 dialog:processed_dialogs = 539449 I have the same configruation of SNMPstats and kamailio in 2 other machines and it works perfectly. In this machine it worked until I rebooted the machine. I asked this question in th emailing list and I got the following response: "Must be something in how the SNMP module reads the data from the statistics counters." I don't know if this could help. Thank you. --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/424

7 years, 10 months

[kamailio] Lots of tcp_read_* errors in log, multi-transport server, lack of context in messages (#385)

by Andrey Utkin

Hi devs, The logs of our Kamailio servers are rich for such lines: ``` Oct 28 06:57:35 ip-172-31-0-139 /usr/local/sbin/kamailio[31963]: ERROR: <core> [tcp_read.c:271]: tcp_read_data(): error reading: Connection reset by peer (104) Oct 28 06:57:35 ip-172-31-0-139 /usr/local/sbin/kamailio[31963]: ERROR: <core> [tcp_read.c:1296]: tcp_read_req(): ERROR: tcp_read_req: error reading ``` The servers serve WS, WSS, UDP, TCP and TLS as connection transports. So we cannot figure what happens and if this is really a problem, but we get accused by whoever audits the servers. What could be done to make this more trackable? Or maybe these messages should be suppressed, if there's no way to track them and they don't mean any problem? --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/385

7 years, 10 months

[kamailio] MS ODBC Driver crashes kamailio on boot (#501)

by Tim Chubb

Hi im currently using freetds via unixodbc to connect to a sql azure db which is ok but suffers from various connection busy errors. I would like to use the ms odbc driver as it supports MARS (multiple active result sets) which should stop the connection busy errors, and numerous other sql server specific enhancements However despite the odbc driver working fine with the unixodbc cli tools kamailio crashes when I try and start the service. --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/501

7 years, 10 months

[kamailio] cnxcc: segmentation fault on 2 calls get terminatet - kamailio 4.3.3 (#417)

by Rick

Log: ``` Nov 25 12:01:23 sip42 kamailio[29215]: INFO: <script>: start - duration: 0 Nov 25 12:01:24 sip42 kamailio[29234]: INFO: cnxcc [cnxcc_check.c:93]: check_calls_by_money(): ec=0.000000, ca=1.000000, ca2=0.000000 Nov 25 12:01:24 sip42 kamailio[29218]: INFO: <script>: start - duration: 0 Nov 25 12:01:25 sip42 kamailio[29234]: INFO: cnxcc [cnxcc_check.c:93]: check_calls_by_money(): ec=0.000000, ca=4.000000, ca2=1.000000 Nov 25 12:01:26 sip42 kamailio[29234]: INFO: cnxcc [cnxcc_check.c:93]: check_calls_by_money(): ec=0.000000, ca=7.000000, ca2=4.000000 Nov 25 12:01:27 sip42 kamailio[29234]: INFO: cnxcc [cnxcc_check.c:93]: check_calls_by_money(): ec=0.000000, ca=9.000000, ca2=7.000000 Nov 25 12:01:28 sip42 kamailio[29234]: INFO: cnxcc [cnxcc_check.c:93]: check_calls_by_money(): ec=0.000000, ca=11.000000, ca2=9.000000 Nov 25 12:01:28 sip42 kamailio[29234]: INFO: <script>: [2JR.9RLbmcERvjSelQ5zHRdAONs1pk0V]: call killed Nov 25 12:01:28 sip42 kamailio[29234]: INFO: <script>: [73tmL4-hk3-50vnsgt19E4rPMMAqHlAG]: call killed Nov 25 12:01:28 sip42 kamailio[29234]: ERROR: cnxcc [cnxcc_mod.c:1023]: terminate_call(): Error executing dlg_end_dlg command. Return code was [404] Nov 25 12:01:28 sip42 kamailio[29246]: CRITICAL: <core> [pass_fd.c:275]: receive_fd(): EOF on 45 Nov 25 12:01:28 sip42 kamailio[29187]: ALERT: <core> [main.c:728]: handle_sigs(): child process 29234 exited by a signal 11 Nov 25 12:01:28 sip42 kamailio[29187]: ALERT: <core> [main.c:731]: handle_sigs(): core was not generated Nov 25 12:01:28 sip42 kamailio[29187]: INFO: <core> [main.c:743]: handle_sigs(): terminating due to SIGCHLD ``` Stacktrace: ``` (gdb) bt full #0 0x00007f3e25b5cfba in get_hash1_raw (s=0x0, len=0) at ../../hashes.h:109 p = 0x0 v = 4284224 h = 0 #1 0x00007f3e25b5d22d in str_hash_get (ht=0x7f3e26333580, key=0x0, len=0) at ../../str_hash.h:94 h = 32766 e = 0x301c31c78 #2 0x00007f3e25b69167 in __free_call (call=0x7f3e2646da00) at cnxcc_mod.c:910 e = 0x0 __FUNCTION__ = "__free_call" #3 0x00007f3e25b68dd5 in terminate_all_calls (credit_data=0x7f3e2646d950) at cnxcc_mod.c:899 call = 0x7f3e2646da00 tmp = 0x7f3e2646da00 __FUNCTION__ = "terminate_all_calls" #4 0x00007f3e25b5952f in check_calls_by_money (ticks=51698976, param=0x0) at cnxcc_check.c:109 credit_data = 0x7f3e2646d950 call = 0x7f3e2646da00 total_consumed_money = 11 consumption_diff = 2 h_entry = 0x7f3e2646d858 tmp = 0x7f3e26335c00 tmp_call = 0x7f3e2647d680 i = 118 __FUNCTION__ = "check_calls_by_money" #5 0x00000000005bcf1c in fork_basic_timer (child_id=-1, desc=0x7f3e25b866fd "CNXCC TB TIMER", make_sock=1, f=0x7f3e25b58200 <check_calls_by_money>, param=0x0, interval=1) at timer_proc.c:79 pid = 0 #6 0x00007f3e25b5ffce in __child_init (rank=0) at cnxcc_mod.c:383 pid = 0 __FUNCTION__ = "__child_init" #7 0x00000000005143d4 in init_mod_child (m=0x7f3e315cf8a8, rank=0) at sr_module.c:915 __FUNCTION__ = "init_mod_child" #8 0x00000000005146db in init_child (rank=0) at sr_module.c:941 No locals. #9 0x0000000000505cef in main_loop () at main.c:1654 i = 4 pid = 1327 si = 0x0 si_desc = "udp receiver child=3 sock=127.0.0.1:5060\000\061\000*>\177\000\000\240.~\264\376\177\000\000\a<\355*>\177\000\000y%p\000\000\000\000\000ȥ3&>\177\000\000\220$\361*>\177\000\000\300(l1>\177\000\000\000\371\360*>\177\000\000\003\000\000\000>\177\000\000\060.~\264\376\177\000\000xBI\000\000\000\000" nrprocs = 4 __FUNCTION__ = "main_loop" #10 0x000000000050be5a in main (argc=13, argv=0x7ffeb47e3138) at main.c:2553 cfg_stream = 0x1b9c010 c = -1 r = 0 tmp = 0x7ffeb47e4ee2 "" tmp_len = 32574 port = 846456272 proto = 0 options = 0x71cae0 ":f:cm:M:dVIhEeb:l:L:n:vKrRDTN:W:w:t:u:g:P:G:SQ:O:a:A:" ret = -1 seed = 1760074178 rfd = 4 debug_save = 0 debug_flag = 0 dont_fork_cnt = 0 n_lst = 0xf63d4e2e p = 0x7f3e3273e000 "" st = {st_dev = 15, st_ino = 9426, st_nlink = 2, st_mode = 16877, st_uid = 109, st_gid = 114, __pad0 = 0, st_rdev = 0, st_size = 40, st_blksize = 4096, st_blocks = 0, st_atim = {tv_sec = 1448451190, tv_nsec = 195999907}, st_mtim = {tv_sec = 1448451190, tv_nsec = 195999907}, st_ctim = {tv_sec = 1448451190, tv_nsec = 195999907}, __glibc_reserved = {0, 0, 0}} __FUNCTION__ = "main" ``` --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/417

7 years, 10 months

[kamailio] kamailio crash when use http_query (#468)

by situnan

1file:modules/utils/functionsc 2Problem Description：Array Overflow and View Code Label：wsong@grandstreamcn size_t write_function( void *ptr, size_t size, size_t nmemb, void *stream_ptr) { http_res_stream_t *stream = (http_res_stream_t *) stream_ptr; stream->buf = (char *) pkg_realloc(stream->buf, stream->curr_size + (size * nmemb) + 1); if (stream->buf == NULL) { LM_ERR("cannot allocate memory for stream\n"); return CURLE_WRITE_ERROR; } memcpy(&stream->buf[stream->pos], (char *) ptr, (size * nmemb)); stream->curr_size += ((size * nmemb) + 1); stream->pos += (size * nmemb); //begin modify wsong@grandstreamcn // reason:stream->buf size begin with 0 // stream->buf[stream->pos + 1] = '\0'; stream->buf[stream->pos ] = '\0'; //end modify wsong@grandstreamcn return size * nmemb; } --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/468

7 years, 11 months

[kamailio] app_perl module - "use UNIVERSAL" is a fatal error starting with Pert 5.22 (#516)

by Peter Lemenkov

At least two places in OpenSIPS where "use UNIVERSAL" is used: At least two places in Kamailio where "use UNIVERSAL" is used: modules/app_perl/lib/perl/Kamailio/LDAPUtils/LDAPConnection.pm 55:use UNIVERSAL qw( isa ); if( isa($conf ,"Kamailio::LDAPUtils::LDAPConnection") ) { modules/app_perl/lib/perl/Kamailio/VDB.pm 48:use UNIVERSAL qw ( can ); 90: if (can($pkg, $3)) { 92: } elsif (can($v, "init")) { 95: } elsif (can($v, "new")) { This should be fixed as according to this document it will throw a fatal error starting with Perl 5.22: http://search.cpan.org/~shay/perl-5.21.11/pod/perl5213delta.pod#use%C2%A0UN… --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/516

8 years

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev February 2016