sr-users May 2013

sr-users@lists.kamailio.org

95 participants
156 discussions

Kamailio stability/timing problem w.r.t. registrations?

by Sotas Development

Hi, We run Kamailio 3.2.3 (FLAVOUR=ser) on an embedded ARM platform in near- default configuration. In a duration test, we observe that at a certain moment Kamailio seems to start ignoring all (re-)register messages, and eventually expires the existing registrations. We have not been able to reproduce the issue using debug-level logging (-dddd). Info-level logging (-ddd) does reproduce the error, but does not produce any error messages. Configuration: ser-basic.cfg, with the following changes: port=5060 alias=testnet Command line: ser -m 4 -f /etc/ser/ser-basic.cfg -n3 -l udp:eth0 Load: Bursts of 8 (Re-)REGISTER messages that are repeated every 85 seconds. The specified expiration time is 120 seconds. Bursts of 9 (Re-)INVITE messages that are repeated every 45 seconds. Note: With this load it takes roughly 1 hour for the error to occur. Using a more standard 3600 second expiration time Kamailio still stalls, it just takes longer. Does anyone have any idea how to tackle this issue? Kind regards, Michiel Veldkamp

10 years, 11 months

Kamailio- Redirect message 300 with LCR reroute

by Fatima Chahrour~Vanrise Support

Dear List, I'd like to get help regarding my case. I have the following script where many thanks to Daniel has helped me in if (is_method("INVITE")) { if (!load_gws(1, $rU, $fu)) { sl_send_reply("502", "Unable To lOad GatEwAyS"); exit;} if(!next_gw()){ sl_send_reply("503", "Unable To fInD a gateWaY"); exit;} while(next_gw()){ km_append_branch(); } sl_send_reply("302","Moved Temporary"); exit; } The problem am facing is that the call is rerouting from the first gateway to the next gateway successfully when I have two gateways. BUT when I have three gateways, and the first two gateways are off, the call is not rerouted to the third gateway. It keeps hitting the seconds gateway and gives request time out at the end Why is that? Thanks in advance, F Chahrour

10 years, 11 months

kamailioi is not relaying BYE message to UAC

by Arif Hossain

Hi, We have the following network architecture : UAC1------------------------->kamailio-------------------->VoipSwitch----->PSTN---------->Phone1 (Sip Client) Now UAC1 calls Phone1 and everything is ok. If UAC1 hangs up session is terminated cleanly. But if Phone1 hangs up the BYE message which comes to kamailio and goes back to VoipSwitch instead of relayed to UAC1 . So The session becomes a zombie one, And UAC1 unfortunately gets billed for a session which should be terminated. Following is the Call flow as seen from VoipSwitch : | <kamilio IP> | | | | <VoipSwitch IP> | |134.856 | INVITE SDP | |(7890) ------------------> (5060) | |134.858 | 407 Proxy Authentication Required | |(7890) <------------------ (5060) | |134.902 | ACK | | |(7890) ------------------> (5060) | |135.408 | INVITE SDP | |(7890) ------------------> (5060) | |135.414 | 100 Trying| | |(7890) <------------------ (5060) | |140.121 | 183 Session Progress SDP | |(7890) <------------------ (5060) | |140.184 | RTP (g729) | | |(61868) <------------------ (5136) | |141.295 | RTP (g729) | | |(61868) ------------------> (5136) | |153.701 | 200 OK SDP | |(7890) <------------------ (5060) | |153.713 | RTP (g729) | | |(61868) ------------------> (5136) | |154.126 | ACK | | |(7890) ------------------> (5060) | |159.988 | BYE | | |(7890) <------------------ (5060) | |160.031 | BYE | | |(7890) ------------------> (5060) | |160.478 | BYE | | |(7890) ------------------> (5060) | |161.412 | BYE | | |(7890) ------------------> (5060) | |181.952 | BYE | | |(7890) ------------------> (5060) | |185.687 | BYE | | |(7890) ------------------> (5060) | |188.018 | 408 Request Timeout | |(7890) ------------------> (5060) | Sip Traces : kamailio------>VoipSwitch I'm posting only the offending BYE msg instead of full trace , because of the mail will become difficult to read . If more traces needed, i can post it. The following BYE message is sent by VoipSwitch: BYE sip:ipphone@205.164.40.74 SIP/2.0 Route: <sip:108.166.195.189:7890;lr=on;nat=yes> CSeq: 2 BYE Via: SIP/2.0/UDP 205.164.40.74:5060 From: sip:008801673345531@205.164.40.74;tag=100528120745985872655137 Call-ID: IqBknV19AuxW0jk.8BjuE4hyx93Ws9qS To: "123456" <sip:ipphone@205.164.40.74>;tag=Zopl5lj5YiqyaSR5Le3QnfoR-G0NZAGG Content-Length: 0 Kamailio instead of relaying the message, sends a BYE message towards VoipSwitch: BYE sip:ipphone@205.164.40.74 SIP/2.0 Max-Forwards: 10 CSeq: 2 BYE Via: SIP/2.0/UDP 108.166.195.189:7890;branch=z9hG4bK4b2b.5d893e95.0 Via: SIP/2.0/UDP 205.164.40.74:5060;rport=5060 From: sip:008801673345531@205.164.40.74;tag=100528120745985872655137 Call-ID: IqBknV19AuxW0jk.8BjuE4hyx93Ws9qS To: "123456" <sip:ipphone@205.164.40.74>;tag=Zopl5lj5YiqyaSR5Le3QnfoR-G0NZAGG Content-Length: 0 When the first BYE message comes from VoipSwitch , kamailio does the following : May 20 02:25:53 VOS20-108 /usr/local/sbin/kamailio[16442]: DEBUG: <core> [receive.c:289]: receive_msg: cleaning up May 20 02:25:53 VOS20-108 /usr/local/sbin/kamailio[16442]: DEBUG: <core> [parser/sdp/sdp.c:751]: _sdp = 0x831bf10 May 20 02:25:53 VOS20-108 /usr/local/sbin/kamailio[16442]: DEBUG: <core> [parser/sdp/sdp.c:753]: sdp = 0x83043dc May 20 02:25:53 VOS20-108 /usr/local/sbin/kamailio[16442]: DEBUG: <core> [parser/sdp/sdp.c:755]: session = 0x8304504 May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [parser/msg_parser.c:630]: SIP Request: May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [parser/msg_parser.c:632]: method: <BYE> May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [parser/msg_parser.c:634]: uri: <sip:ipphone@205.164.40.74> May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [parser/msg_parser.c:636]: version: <SIP/2.0> May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [parser/msg_parser.c:167]: get_hdr_field: cseq <CSeq>: <1> <BYE> May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [parser/parse_via.c:1287]: Found param type 232, <branch> = <z9hG4bk19052612230719933454843>; state=16 May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [parser/parse_via.c:2300]: end of header reached, state=5 May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [parser/msg_parser.c:515]: parse_headers: Via found, flags=2 May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [parser/msg_parser.c:517]: parse_headers: this is the first via May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [receive.c:145]: After parse_msg... May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [receive.c:186]: preparing to run routing scripts... May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [parser/parse_to.c:174]: DEBUG: add_param: tag=arILprdVR1srJ76HHlt4BEc3XsyaWcZm May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [parser/parse_to.c:803]: end of header reached, state=29 May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [parser/msg_parser.c:187]: DEBUG: get_hdr_field: <To> [76]; uri=[sip:ipphone@205.164.40.74] May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [parser/msg_parser.c:189]: DEBUG: to body ["ipphone" <sip:ipphone@205.164.40.74>] May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [parser/msg_parser.c:201]: DEBUG: get_hdr_body : content_length=0 May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [parser/msg_parser.c:103]: found end of header May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: maxfwd [mf_funcs.c:66]: max_forwards header not found! May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [parser/parse_to.c:174]: DEBUG: add_param: tag=1905251223419334290936029 May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [parser/parse_to.c:803]: end of header reached, state=29 May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: siputils [checks.c:76]: totag found May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: rr [loose.c:85]: is_preloaded: No May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [socket_info.c:501]: grep_sock_info - checking if host==us: 13==15 && [205.164.40.74] == [108.166.195.189] May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [socket_info.c:504]: grep_sock_info - checking if port 7890 matches port 5060 May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [socket_info.c:501]: grep_sock_info - checking if host==us: 13==15 && [205.164.40.74] == [108.166.195.189] May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [socket_info.c:504]: grep_sock_info - checking if port 5060 matches port 5060 May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [forward.c:448]: check_self: host != me May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [socket_info.c:501]: grep_sock_info - checking if host==us: 15==15 && [108.166.195.189] == [108.166.195.189] May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [socket_info.c:504]: grep_sock_info - checking if port 7890 matches port 7890 May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: rr [loose.c:792]: Topmost route URI: 'sip:108.166.195.189:7890;lr=on;nat=yes' is me May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [parser/msg_parser.c:103]: found end of header May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: rr [loose.c:257]: No next Route HF found May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: rr [loose.c:811]: No next URI found May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: rr [loose.c:983]: params are <;lr=on;nat=yes> May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: siputils [checks.c:76]: totag found May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: tm [t_lookup.c:1379]: DEBUG: t_newtran: msg id=2501 , global msg id=2500 , T on entrance=0xffffffff May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: tm [t_lookup.c:528]: t_lookup_request: start searching: hash=29177, isACK=0 May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: tm [t_lookup.c:564]: DEBUG: proceeding to pre-RFC3261 transaction matching May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: tm [t_lookup.c:711]: DEBUG: t_lookup_request: no transaction found May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: tm [t_hooks.c:374]: DBG: trans=0xb61626a4, callback type 1, id 0 entered May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [msg_translator.c:204]: check_via_address(205.164.40.74, 205.164.40.74, 0) May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: tm [t_funcs.c:388]: SER: new transaction fwd'ed May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [usr_avp.c:646]: DEBUG:destroy_avp_list: destroying list (nil) May 20 02:26:04 VOS20-108 last message repeated 5 times May 20 02:26:04 VOS20-108 /usr/local/sbin/kamailio[16443]: DEBUG: <core> [receive.c:289]: receive_msg: cleaning up May 20 02:26:22 VOS20-108 /usr/local/sbin/kamailio[16445]: DEBUG: <core> [udp_server.c:486]: udp_rcv_loop: probing packet received from 180.234.62.230 38722 May 20 02:26:34 VOS20-108 /usr/local/sbin/kamailio[16450]: DEBUG: tm [t_reply.c:1134]: ->>>>>>>>> T_code=0, new_code=408 May 20 02:26:34 VOS20-108 /usr/local/sbin/kamailio[16450]: DEBUG: tm [t_reply.c:1636]: DEBUG: relay_reply: branch=0, save=0, relay=0 May 20 02:26:34 VOS20-108 /usr/local/sbin/kamailio[16450]: DEBUG: <core> [msg_translator.c:204]: check_via_address(205.164.40.74, 205.164.40.74, 0) May 20 02:26:34 VOS20-108 /usr/local/sbin/kamailio[16450]: DEBUG: <core> [mem/shm_mem.c:105]: WARNING:vqm_resize: resize(0) called May 20 02:26:34 VOS20-108 /usr/local/sbin/kamailio[16450]: DEBUG: tm [t_hooks.c:288]: DBG: trans=0xb61626a4, callback type 128, id 0 entered May 20 02:26:54 VOS20-108 /usr/local/sbin/kamailio[16451]: WARNING: <core> [timer.c:450]: WARNING: our timer runs faster then real-time (300000 ms / 4800 ticks our time .-> 299923 ms / 4798 ticks real time) OT: How do you guys maintain 80 column mails? i do not use a mail client, use gmail mailbox. -- -aft

10 years, 11 months

reload to memory is much slower and has problms after upgrade to 3.3.2 and using mem_join=1

by Uri Shacked

Hi, I am using MTREE and DIALPLAN modules to load lots of info to kamailio. (6 million rows). When kamailio was running with 3.2.1 (no mem_join=1 option), the used size was increasing but the process of loading the data was fast eanough. I upgraded to 3.3.2 and set mem_join=1. Now the loading process take about 10 time longer and sometimes stops kamailio from responding to traffic. Any ideas? Thanks, Uri

10 years, 11 months

Problem with 4.0 nightlies and IMS - sem_post undefined

by Barry Flanagan

Hi I am trying to run the Ubuntu nightlies from http://deb.kamailio.org/kamailiodev-nightly and loading the p-cscf config files. Things were working fine while I was on the 20130110 nightlies, but when I upgraded to 20130122 I get the following errors. Any have an idea why sem_post is undefined and how to fix this? 0(1980) ERROR: <core> [sr_module.c:572]: ERROR: load_module: could not open module </usr/lib64/kamailio/modules/ims_registrar_pcscf.so>: /usr/lib64/kamailio/modules/ims_registrar_pcscf.so: undefined symbol: sem_post 0(1980) ERROR: <core> [sr_module.c:572]: ERROR: load_module: could not open module </usr/lib64/kamailio/modules/cdp.so>: /usr/lib64/kamailio/modules/cdp.so: undefined symbol: sem_post 0(1980) ERROR: <core> [sr_module.c:572]: ERROR: load_module: could not open module </usr/lib64/kamailio/modules/ims_qos.so>: /usr/lib64/kamailio/modules/ims_qos.so: undefined symbol: sem_post Thanks -Barry Flanagan

11 years

EOF Error in pass_fd

by Ricardo Martinez

Hello List. The last weekend our kamailio process crashed with this error : Jun 24 06:55:08 pxh /usr/local/sbin/kamailio[10661]: : <core> [pass_fd.c:293]: ERROR: receive_fd: EOF on 29 Jun 24 06:55:08 pxh /usr/local/sbin/kamailio[10542]: ALERT: <core> [main.c:751]: child process 10601 exited by a signal 11 Jun 24 06:55:08 pxh /usr/local/sbin/kamailio[10542]: ALERT: <core> [main.c:754]: core was generated Jun 24 06:55:08 pxh /usr/local/sbin/kamailio[10542]: INFO: <core> [main.c:766]: INFO: terminating due to SIGCHLD Can someone tell me what seems to be the problem here? We’re using : version: kamailio 3.2.2 (x86_64/linux) 98ba92-dirty flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, DBG_QM_MALLOC, 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 4MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: 98ba92 -dirty compiled on 12:45:36 Feb 2 2012 with gcc 4.4.6 And this is the bt full from gdb Core was generated by `/usr/local/sbin/kamailio -m 1024'. Program terminated with signal 11, Segmentation fault. #0 mi_profile_list (cmd_tree=<value optimized out>, param=<value optimized out>) at dlg_profile.c:789 789 if ( mi_print_dlg( rpl, ph->dlg, 0)!=0 ) Missing separate debuginfos, use: debuginfo-install filesystem-2.4.30-2.1.el6.x86_64 glibc-2.12-1.25.el6_1.3.x86_64 keyutils-libs-1.4-1.el6.x86_64 krb5-libs-1.9-9.el6_1.2.x86_64 libcom_err-1.41.12-7.el6.x86_64 libselinux-2.0.94-5.el6.x86_64 mysql-libs-5.1.52-1.el6_0.1.x86_64 nss-softokn-freebl-3.12.7-1.1.el6.x86_64 openssl-1.0.0-20.el6_2.1.x86_64 pcre-7.8-3.1.el6.x86_64 zlib-1.2.3-26.el6.x86_64 (gdb) bt full #0 mi_profile_list (cmd_tree=<value optimized out>, param=<value optimized out>) at dlg_profile.c:789 node = <value optimized out> rpl_tree = 0x20a6790 rpl = 0x20a67b0 profile = 0x7fe99a2dda00 ph = 0x0 profile_name = <value optimized out> value = <value optimized out> i = <value optimized out> #1 0x00007fe9dce287b1 in run_mi_cmd (fifo_stream=<value optimized out>) at ../../lib/kmi/mi.h:77 No locals. #2 mi_fifo_server (fifo_stream=<value optimized out>) at fifo_fnc.c:509 mi_cmd = 0x208f8f0 mi_rpl = <value optimized out> hdl = 0x0 line_len = 41 file_sep = 0x2039017 "" command = 0x7fe9dfdbdef9 "profile_list_dlgs" file = 0x7fe9dfd98d78 "/tmp/openser_receiver_27809" f = 0x2039018 reply_stream = 0x20b0980 #3 0x00007fe9dce2a640 in fifo_process (rank=<value optimized out>) at mi_fifo.c:247 fifo_stream = 0x209a0b0 #4 0x00007fe9dce2a9de in mi_child_init (rank=0) at mi_fifo.c:211 pid = <value optimized out> #5 0x00000000004dba41 in init_mod_child (m=0x7fe9dfc6ba10, rank=0) at sr_module.c:886 No locals. #6 0x00000000004db9c4 in init_mod_child (m=0x7fe9dfc6bd08, rank=0) at sr_module.c:883 No locals. #7 0x00000000004db9c4 in init_mod_child (m=0x7fe9dfc6c248, rank=0) at sr_module.c:883 No locals. #8 0x00000000004db9c4 in init_mod_child (m=0x7fe9dfc6c748, rank=0) at sr_module.c:883 No locals. #9 0x00000000004db9c4 in init_mod_child (m=0x7fe9dfc6d288, rank=0) at sr_module.c:883 No locals. #10 0x00000000004db9c4 in init_mod_child (m=0x7fe9dfc6d928, rank=0) at sr_module.c:883 No locals. #11 0x00000000004db9c4 in init_mod_child (m=0x7fe9dfc6dee0, rank=0) at sr_module.c:883 No locals. #12 0x00000000004db9c4 in init_mod_child (m=0x7fe9dfc6e1f0, rank=0) at sr_module.c:883 No locals. #13 0x00000000004db9c4 in init_mod_child (m=0x7fe9dfc6e5d0, rank=0) at sr_module.c:883 No locals. #14 0x00000000004db9c4 in init_mod_child (m=0x7fe9dfc6e830, rank=0) at sr_module.c:883 No locals. #15 0x00000000004db9c4 in init_mod_child (m=0x7fe9dfc6ebd0, rank=0) at sr_module.c:883 No locals. #16 0x00000000004db9c4 in init_mod_child (m=0x7fe9dfc6f220, rank=0) at sr_module.c:883 No locals. #17 0x00000000004db9c4 in init_mod_child (m=0x7fe9dfc6f648, rank=0) at sr_module.c:883 No locals. #18 0x00000000004db9c4 in init_mod_child (m=0x7fe9dfc6fa60, rank=0) at sr_module.c:883 No locals. #19 0x00000000004db9c4 in init_mod_child (m=0x7fe9dfc6fe40, rank=0) at sr_module.c:883 No locals. #20 0x00000000004db9c4 in init_mod_child (m=0x7fe9dfc702c0, rank=0) at sr_module.c:883 No locals. #21 0x00000000004db9c4 in init_mod_child (m=0x7fe9dfc70ae8, rank=0) at sr_module.c:883 No locals. ---Type <return> to continue, or q <return> to quit--- #22 0x00000000004db9c4 in init_mod_child (m=0x7fe9dfc70e18, rank=0) at sr_module.c:883 No locals. #23 0x00000000004db9c4 in init_mod_child (m=0x7fe9dfc71100, rank=0) at sr_module.c:883 No locals. #24 0x00000000004db9c4 in init_mod_child (m=0x7fe9dfc716c0, rank=0) at sr_module.c:883 No locals. #25 0x00000000004db9c4 in init_mod_child (m=0x7fe9dfc71df0, rank=0) at sr_module.c:883 No locals. #26 0x00000000004db9c4 in init_mod_child (m=0x7fe9dfc723c0, rank=0) at sr_module.c:883 No locals. #27 0x000000000046077d in main_loop () at main.c:1661 i = <value optimized out> pid = <value optimized out> si = 0x0 si_desc = "udp receiver child=15 sock=64.76.154.35:5060", '\000' <repeats 20 times>, "\003", '\000' <repeats 15 times>, "\030\325\a\232\351\177\000\000\001\000\000\000\002", '\000' <repeats 11 times>, "\001\000\000\000\000\000\000\000\003\000\000\000\000\000\000\000)\000\000\000\000\000\000" #28 0x0000000000461f13 in main (argc=<value optimized out>, argv=0x7fff2f2b2848) at main.c:2475 cfg_stream = <value optimized out> c = <value optimized out> r = <value optimized out> tmp = 0x7fff2f2b3f76 "" tmp_len = 0 options = 0x5a3178 ":f:cm:M:dVhEb:l:L:n:vrRDTN:W:w:t:u:g:P:G:SQ:O:a:A:" ret = -1 seed = 1850310455 rfd = <value optimized out> debug_save = <value optimized out> debug_flag = <value optimized out> dont_fork_cnt = <value optimized out> n_lst = <value optimized out> p = <value optimized out> (gdb) Regards, Ricardo.-

11 years

BUG? - Dialog module timeout BYE is not ok.

by Uri Shacked

Hi, Following this issue, and the issue "BYE dialog timeout bad syntax" from Julia. I have 2 kamailio servers. srv1 creates a dlg_timeout BYE and sends it to srv2 that forwards the BYE to the next sip server (some other server...). I can definitely see that the BYE that is being forward is malformed. The TO header info is not complete (the port section for example). When a "normal" bye is received from srv1 (not dlg_timeout) all works fine. One thing that i do in this scenario, on srv2 i use uac_replace() on the TO header. So, it is OK that the final destination is different (i do translations). I attached the BYE from both servers. Any ideas? Thanks, Uri You probably meant the To and From headers, I'm guessing. Yeah, as long as there is no display name component, URIs in headers like that don't have to go in <>s. The way Kamailio sends it is grammatically valid, per RFC 3261. The user agents are at fault for not understanding it correctly. Alex Balashov <abalashov at evaristesys.com<http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users>> wrote: >*"BYE headers"? Which headers? *>* *>*Uri Shacked <ushacked at gmail.com <http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users>> wrote: *>* *>>*Hi, *>>* *>>*I think there is a bug with the BYE that is sent to the caller and *>>*callee *>>*when dialog timeout happends. *>>* *>> *The BYE headers are sent with no "<" or ">". *>>*So, some sip singaling points decline the BYE. *>>* *>>*BR, *>>*Uri *>>* *>>* *>>*------------------------------------------------------------------------ *>>* *>>*_______________________________________________ *>>*SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing *>*list *>>*sr-users at lists.sip-router.org<http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users> *>>*http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users *>* *>*-- *>*Sent from my mobile, and thus lacking in the refinement one might *>*expect from a fully-fledged keyboard. *>* *>*Alex Balashov - Principal *>*Evariste Systems LLC *>*235 E Ponce de Leon Ave *>*Suite 106 *>*Decatur, GA 30030 *>*United States *>*Tel: +1-678-954-0670 *>*Web: http://www.evaristesys.com/, http://www.alexbalashov.com/ *>* *>*_______________________________________________ *>*SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list * >*sr-users at lists.sip-router.org<http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users> *>*http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users * -- Sent from my Nexus 10, with all the figments of autocorrect that might imply. Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 United States Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: < http://lists.sip-router.org/pipermail/sr-users/attachments/20130422/0c75272…>

11 years

rfc: accounting records time details

by Daniel-Constantin Mierla

Hello, there were old and recent discussions about the representation of time in accounting records. At this moment the acc module stores the unix timestamp as datetime value. In some countries is required to store more accuracy, beyond the seconds. Also, the datetime gives some troubles with converting back to unix timestamp, specifically with time zones and daylight saving times. I want to open a discussion that is visible for all users and devs, being something affecting probably everyone, input from anyone that is interested being relevant to select the right approach. Here are some suggestions presented so far. 1) store seconds.miliseconds as double - there is a patch (which probably needs some tunings itself) on tracker. The precision is shifted from seconds to milliseconds. Internally computed from microseconds from timeval structure. The other modules might need updates (iirc dbtext has only 2 decimals precisions for double, while miliseconds will require at least three -- could be the case for flatstore or other modules). Advantage is the computing of duration directly by subtraction of two values. 2) store seconds and microseconds as two separate values. Should be no issues with existing modules. Even more accuracy than above, no issues with other modules, but will require to use two columns (thus four values to compute the duration) Any other suggestions? Personally, at this moment, I will go with 2), but that might not meet everyone's needs. So a solution can be to make it configurable, as a bitmask of what time representation to store. Say, there will be a new parameter timestamp_mode for acc module: - bit one set - store seconds timestamp as for now (default) - bit two set - store seconds and microseconds in separate integer columns - bit three set - store seconds.miliseconds as double value in one column I could add the parameter and tune acc for bit one and two. For bit three a deeper review is needed for other modules, probably the developer that submitted to the tracker can do it. More suggestions? Pro or cons opinions? Cheers, Daniel -- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio Advanced Training, San Francisco, USA - June 24016, 2013 * http://asipto.com/u/katu *

11 years, 2 months

[Kamailio-Users] Error in Running kamailio !!

by Dinesh gautam

Dear Sir, I am using kamailio 1.5.0, having installed and configured as given on the kamailio site <http://www.kamailio.org/dokuwiki/doku.php/install:kamailio-1.5.x-from-svn> on my PC having Centos operating system. I have configured the config files kamailio.cfg, kamctlrc accordingly as given on site. when I start the kamailio using kamctl start command. it gives the error message like *[root@localhost ~]# kamctl start database engine 'MYSQL' loaded Control engine 'FIFO' loaded INFO: Starting Kamailio : ERROR: PID file /var/run/kamailio.pid does not exist -- Kamailio start failed *please* *help me out to solve this problem and suggest me where I am wrong. * *I have configured kamalio so many times it gives me the same kind of error message. * * - With Regards, Dinesh Kumar Gautam Noida, +919911838275

11 years, 3 months

How to tie Registration with Client TCP connection

by Krishna Kurapati

Hi, With TCP, there is no way Server can establish a TCP connection through client's Firewall/NAT. So, when Client connection is disconnected from the server due to Network issues, the Registration should be removed. I tried to handle this with a Event Route in tcp_read.c. However, There is not an easy way to find the Registration with TCP socket info (IP and Port of the Client). Could anyone suggest a solution? Thanks Krish Kura

11 years, 4 months

Jump to page:

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 May 2013