July 2012 - sr-users - kamailio.org

Problem with t_relay() and VPN tunnel
by Carlos Ruiz Diaz 24 Jun '17

24 Jun '17

Hi, I have two SIP servers, *A* and *B*, connected each other though a OPENVPN tunnel. The server *B* needs to t_relay() every SIP message containing the method MESSAGE to the server *A* but these messages never reach destination. I have tested the tunnel connectivity and works fine. I wrote a Perl script (located in *B*) that sends SIP MESSAGES to Kamailio (located in *A*) trying to figure out what is happening but these messages are received by *A* and processed correctly but when *B* does the same from Kamailio, it is never received. Here is the route part of kamailio.cfg in *B*: Observation: ($rU == "1004") result is *true* * if(is_method("MESSAGE")) { if($rU == "1004") { xlog("L_INFO","En 1004"); rewritehost("10.8.0.1"); if (!t_relay()) xlog("L_INFO","MIO Error en t_relay"); t_reply("200", "Ok"); xlog("L_INFO","MIO despues rewrite"); exit; } .....* The perl script that WORKS: *$msg = 'MESSAGE sip:1004@192.168.1.2:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.2 From: "2002" <sip:2002@192.168.1.2 <sip%3A2002(a)192.168.1.2>>;tag=1837944796 To: <sip:1004@192.168.1.2 <sip%3A1004(a)192.168.1.2>> Call-ID: 19722852989(a)192.168.1.2 CSeq: 15773 MESSAGE Contact: <sip:2002@**PublicIP-protected**:5060> Max-Forwards: 29 User-Agent: DBL Content-Type: text/plain Content-Length: 34 +595981[protected] hello from kamailio '; use IO::Socket; my $sock = IO::Socket::INET->new( Proto=>'udp', PeerHost=>'192.168.2.102', PeerPort=>'5060'); print "Sending msg $msg\n"; $sock->send($msg) or die "error sending $!\n"; *Please help! Thanks in advance. Carlos.

3 3

[Kamailio-Users] HA+DRBD setup
by Siddhardha Garige 09 Jul '15

09 Jul '15

Hello all, Just wondering if anyone know any tutorial on setting up HA+DRBD solution for kamailio. Especially creating partitions, DRBD devices and mount points. Thanks in advance, -Sid "May the light be with you." ______________________________________________ Siddhardha Garige www.luminepixels.com

11 24

Re: [Kamailio-Users] /usr/local/sbin/kamdbctl create error
by vivi 01 Nov '14

01 Nov '14

Hi all.. I have solve the problem . Cheers, vivi From: vivi [mailto:vivi.hilton@gmail.com] Sent: Saturday, June 06, 2009 11:29 PM To: 'users(a)lists.kamailio.org' Subject: /usr/local/sbin/kamdbctl create error Hi all I have specify the wanted db type (DBENGINE=MYSQL) in the /usr/local/etc/kamailio/kamctlrc then I using "/usr/local/sbin/kamdbctl create" to create MySQL database, but I got this error: ERROR: database engine not specified, please setup one in the config script root@acer:/usr/local/src/kamailio-1.5.0/sip-server# vim /usr/local/etc/kamailio/kamctlrc root@acer:/usr/local/src/kamailio-1.5.0/sip-server# /usr/local/sbin/kamdbctl create MySQL password for root: INFO: test server charset ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. /usr/local/lib/kamailio/kamctl/kamdbctl.mysql: line 112: [: =: unary operator expected INFO: creating database openser ... ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) ERROR: Creating core database and grant privileges failed! Cheers, vivi

2 1

kamailioi is not relaying BYE message to UAC
by Arif Hossain 06 Dec '13

06 Dec '13

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

5 6

EOF Error in pass_fd
by Ricardo Martinez 20 Nov '13

20 Nov '13

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.-

4 7

[Kamailio-Users] Error in Running kamailio !!
by Dinesh gautam 25 Jul '13

25 Jul '13

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

6 15

File kamailio_fifo is removed...
by Bruno Bresciani 12 Mar '13

12 Mar '13

Hi, Kamailio is running fine, but when I try run again by command line without killing the previous, the kamailio_fifo is removed and functions fifo in kamctl doen't work anymore. Why when I try running kamailio when already exist one, it remove de file kamailio_fifo? I can't find the part of source code that file kamailio_fifo is removed... Someone knows? Best Regards

2 2

Wrong ACK packet sent from Cisco gw
by Nawfel Oujdi 07 Mar '13

07 Mar '13

Hello! I m facing the same strange behaviour with my AS5300 voice gateway. When the gw is connected directly to PBX everythings works well but when i put a sip proxy forwarding calls between gw and PBX all the calls hangs up after 5 sec (+or -). Looking into the trace sip i realize that gw send a wrong ACK in reply of INVITE , then sip proxy discard it and PBX hangs the call cause he never receive the ACK. ACK sip:79.125.120.12:5060;lr=on;did=ce.3716ea02 SIP/2.0 Via: SIP/2.0/UDP cisco_gw:5060;x-route-tag="cid:Orange@cisco_gw" From: <sip:911873699@cisco_gw>;tag=65FB8-B18 Route: <sip:911111500@PBX:5060> To: <sip:911111500@sip_proxy>;tag=as7f388e3f Date: Mon, 17 Jan 2011 09:26:36 GMT Call-ID: B6F61A2E-215211E0-802BD462-C4432B89@cisco_gw To work fine , the content of Route header should be in ACK header and viceversa. I tried to compare between the sip trace of a wrong call and a good one (using other cisco gw AS5350 who works well with sip proxy in the same escenario) and i realize that the only difference is the INVITE of wrong case doesn' t send branch number in the via header. INVITE sip:911111500@sip_proxy:5060 SIP/2.0 Via: SIP/2.0/UDP cisco_gw:5060;x-route-tag="cid:Orange@cisco_gw" From: <sip:911873699@cisco_gw>;tag=65FB8-B18 To: <sip:911111500@sip_proxy> i m using c5300-is-mz.123-26.bin ios version. Anybody understand what is happening in there?? is there any solution?? i ll send more information if it s requested. Thanks in advance. Nawfel Oujdi here is the result of ngrep: U 2011/01/13 15:14:43.791514 cisco_gw:51703 -> sip_server:5060 INVITE sip:911111500@sip_server:5060 SIP/2.0. Via: SIP/2.0/UDP cisco_gw:5060;x-route-tag="cid:Orange@cisco_gw". From: <sip:911873699@cisco_gw>;tag=4F226C8-2DC. To: <sip:911111500@sip_server>. Date: Thu, 13 Jan 2011 14:14:43 GMT. Call-ID: 4D776A24-1E5611E0-9B81F289-1B94787@cisco_gw. Supported: timer,100rel. Min-SE: 1800. Cisco-Guid: 1295951687-508957152-2608788105-28919687. User-Agent: Cisco-SIPGateway/IOS-12.x. Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO. CSeq: 101 INVITE. Max-Forwards: 6. Remote-Party-ID: <sip:911873699@cisco_gw >;party=calling;screen=yes;privacy=off. Timestamp: 1294928083. Contact: <sip:911873699@cisco_gw:5060>. Expires: 180. Allow-Events: telephone-event. Content-Type: application/sdp. Content-Length: 270. . v=0. o=CiscoSystemsSIP-GW-UserAgent 8894 2421 IN IP4 cisco_gw. s=SIP Call. c=IN IP4 cisco_gw. t=0 0. m=audio 16924 RTP/AVP 18 101. c=IN IP4 cisco_gw. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=no. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=ptime:20. U 2011/01/13 15:14:43.791893 sip_server:5060 -> cisco_gw:5060 SIP/2.0 100 Giving a try. Via: SIP/2.0/UDP cisco_gw:5060;x-route-tag="cid:Orange@cisco_gw". From: <sip:911873699@cisco_gw>;tag=4F226C8-2DC. To: <sip:911111500@sip_server>. Call-ID: 4D776A24-1E5611E0-9B81F289-1B94787@cisco_gw. CSeq: 101 INVITE. Server: OpenSIPS (1.6.3-notls (i386/linux)). Content-Length: 0. . U 2011/01/13 15:14:43.791957 sip_server:5060 -> asterisk_server:5060 INVITE sip:911111500@sip_server:5060 SIP/2.0. Record-Route: <sip:sip_server;lr=on;did=015.864b8107>. Via: SIP/2.0/UDP sip_server;branch=z9hG4bK3e35.3ed9b366.0. Via: SIP/2.0/UDP cisco_gw:5060;x-route-tag="cid:Orange@cisco_gw". From: <sip:911873699@cisco_gw>;tag=4F226C8-2DC. To: <sip:911111500@sip_server>. Date: Thu, 13 Jan 2011 14:14:43 GMT. Call-ID: 4D776A24-1E5611E0-9B81F289-1B94787@cisco_gw. Supported: timer,100rel. Min-SE: 1800. Cisco-Guid: 1295951687-508957152-2608788105-28919687. User-Agent: Cisco-SIPGateway/IOS-12.x. Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO. CSeq: 101 INVITE. Max-Forwards: 5. Remote-Party-ID: <sip:911873699@cisco_gw >;party=calling;screen=yes;privacy=off. Timestamp: 1294928083. Contact: <sip:911873699@cisco_gw:5060>. Expires: 180. Allow-Events: telephone-event. Content-Type: application/sdp. Content-Length: 270. . v=0. o=CiscoSystemsSIP-GW-UserAgent 8894 2421 IN IP4 cisco_gw. s=SIP Call. c=IN IP4 cisco_gw. t=0 0. m=audio 16924 RTP/AVP 18 101. c=IN IP4 cisco_gw. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=no. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=ptime:20. U 2011/01/13 15:14:43.792775 asterisk_server:5060 -> sip_server:5060 SIP/2.0 100 Trying. Via: SIP/2.0/UDP sip_server;branch=z9hG4bK3e35.3ed9b366.0;received=sip_server. Via: SIP/2.0/UDP cisco_gw:5060;x-route-tag="cid:Orange@cisco_gw". Record-Route: <sip:sip_server;lr=on;did=015.864b8107>. From: <sip:911873699@cisco_gw>;tag=4F226C8-2DC. To: <sip:911111500@sip_server>. Call-ID: 4D776A24-1E5611E0-9B81F289-1B94787@cisco_gw. CSeq: 101 INVITE. Server: Asterisk PBX 1.6.2.13. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO. Supported: replaces, timer. Require: timer. Session-Expires: 1800;refresher=uas. Contact: <sip:911111500@asterisk_server>. Content-Length: 0. . U 2011/01/13 15:14:43.793770 asterisk_server:5060 -> sip_server:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP sip_server;branch=z9hG4bK3e35.3ed9b366.0;received=sip_server. Via: SIP/2.0/UDP cisco_gw:5060;x-route-tag="cid:Orange@cisco_gw". Record-Route: <sip:sip_server;lr=on;did=015.864b8107>. From: <sip:911873699@cisco_gw>;tag=4F226C8-2DC. To: <sip:911111500@sip_server>;tag=as19e8a82f. Call-ID: 4D776A24-1E5611E0-9B81F289-1B94787@cisco_gw. CSeq: 101 INVITE. Server: Asterisk PBX 1.6.2.13. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO. Supported: replaces, timer. Require: timer. Session-Expires: 1800;refresher=uas. Contact: <sip:911111500@asterisk_server>. Content-Type: application/sdp. Content-Length: 260. . v=0. o=root 1750021131 1750021131 IN IP4 asterisk_server. s=Asterisk PBX 1.6.2.13. c=IN IP4 asterisk_server. t=0 0. m=audio 10798 RTP/AVP 18 101. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=no. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=ptime:20. a=sendrecv. U 2011/01/13 15:14:43.794688 sip_server:5060 -> cisco_gw:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP cisco_gw:5060;x-route-tag="cid:Orange@cisco_gw". Record-Route: <sip:sip_server;lr=on;did=015.864b8107>. From: <sip:911873699@cisco_gw>;tag=4F226C8-2DC. To: <sip:911111500@sip_server>;tag=as19e8a82f. Call-ID: 4D776A24-1E5611E0-9B81F289-1B94787@cisco_gw. CSeq: 101 INVITE. Server: Asterisk PBX 1.6.2.13. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO. Supported: replaces, timer. Require: timer. Session-Expires: 1800;refresher=uas. Contact: <sip:911111500@asterisk_server>. Content-Type: application/sdp. Content-Length: 316. . v=0. o=root 1750021131 1750021131 IN IP4 79.125.41.121. s=Asterisk PBX 1.6.2.13. c=IN IP4 79.125.41.121. t=0 0. m=audio 10798 RTP/AVP 18 101. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=no. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=ptime:20. a=sendrecv. a=oldmediaip:asterisk_server. a=oldmediaip:asterisk_server. U 2011/01/13 15:14:43.856520 cisco_gw:57947 -> sip_server:5060 ACK sip:sip_server:5060;lr=on;did=015.864b8107 SIP/2.0. Via: SIP/2.0/UDP cisco_gw:5060;x-route-tag="cid:Orange@cisco_gw". From: <sip:911873699@cisco_gw>;tag=4F226C8-2DC. To: <sip:911111500@sip_server>;tag=as19e8a82f. Date: Thu, 13 Jan 2011 14:14:43 GMT. Call-ID: 4D776A24-1E5611E0-9B81F289-1B94787@cisco_gw. Route: <sip:911111500@asterisk_server:5060>. Max-Forwards: 6. Content-Length: 0. CSeq: 101 ACK. . U 2011/01/13 15:14:43.993417 asterisk_server:5060 -> sip_server:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP sip_server;branch=z9hG4bK3e35.3ed9b366.0;received=sip_server. Via: SIP/2.0/UDP cisco_gw:5060;x-route-tag="cid:Orange@cisco_gw". Record-Route: <sip:sip_server;lr=on;did=015.864b8107>. From: <sip:911873699@cisco_gw>;tag=4F226C8-2DC. To: <sip:911111500@sip_server>;tag=as19e8a82f. Call-ID: 4D776A24-1E5611E0-9B81F289-1B94787@cisco_gw. CSeq: 101 INVITE. Server: Asterisk PBX 1.6.2.13. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO. Supported: replaces, timer. Require: timer. Session-Expires: 1800;refresher=uas. Contact: <sip:911111500@asterisk_server>. Content-Type: application/sdp. Content-Length: 260. . v=0. o=root 1750021131 1750021131 IN IP4 asterisk_server. s=Asterisk PBX 1.6.2.13. c=IN IP4 asterisk_server. t=0 0. m=audio 10798 RTP/AVP 18 101. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=no. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=ptime:20. a=sendrecv. U 2011/01/13 15:14:43.993613 sip_server:5060 -> cisco_gw:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP cisco_gw:5060;x-route-tag="cid:Orange@cisco_gw". Record-Route: <sip:sip_server;lr=on;did=015.864b8107>. From: <sip:911873699@cisco_gw>;tag=4F226C8-2DC. To: <sip:911111500@sip_server>;tag=as19e8a82f. Call-ID: 4D776A24-1E5611E0-9B81F289-1B94787@cisco_gw. CSeq: 101 INVITE. Server: Asterisk PBX 1.6.2.13. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO. Supported: replaces, timer. Require: timer. Session-Expires: 1800;refresher=uas. Contact: <sip:911111500@asterisk_server>. Content-Type: application/sdp. Content-Length: 316. . v=0. o=root 1750021131 1750021131 IN IP4 79.125.41.121. s=Asterisk PBX 1.6.2.13. c=IN IP4 79.125.41.121. t=0 0. m=audio 10798 RTP/AVP 18 101. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=no. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=ptime:20. a=sendrecv. a=oldmediaip:asterisk_server. a=oldmediaip:asterisk_server. U 2011/01/13 15:14:44.038774 cisco_gw:57947 -> sip_server:5060 ACK sip:sip_server:5060;lr=on;did=015.864b8107 SIP/2.0. Via: SIP/2.0/UDP cisco_gw:5060;x-route-tag="cid:Orange@cisco_gw". From: <sip:911873699@cisco_gw>;tag=4F226C8-2DC. To: <sip:911111500@sip_server>;tag=as19e8a82f. Date: Thu, 13 Jan 2011 14:14:43 GMT. Call-ID: 4D776A24-1E5611E0-9B81F289-1B94787@cisco_gw. Route: <sip:911111500@asterisk_server:5060>. Max-Forwards: 6. Content-Length: 0. CSeq: 101 ACK. . U 2011/01/13 15:14:44.193431 asterisk_server:5060 -> sip_server:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP sip_server;branch=z9hG4bK3e35.3ed9b366.0;received=sip_server. Via: SIP/2.0/UDP cisco_gw:5060;x-route-tag="cid:Orange@cisco_gw". Record-Route: <sip:sip_server;lr=on;did=015.864b8107>. From: <sip:911873699@cisco_gw>;tag=4F226C8-2DC. To: <sip:911111500@sip_server>;tag=as19e8a82f. Call-ID: 4D776A24-1E5611E0-9B81F289-1B94787@cisco_gw. CSeq: 101 INVITE. Server: Asterisk PBX 1.6.2.13. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO. Supported: replaces, timer. Require: timer. Session-Expires: 1800;refresher=uas. Contact: <sip:911111500@asterisk_server>. Content-Type: application/sdp. Content-Length: 260. . v=0. o=root 1750021131 1750021131 IN IP4 asterisk_server. s=Asterisk PBX 1.6.2.13. c=IN IP4 asterisk_server. t=0 0. m=audio 10798 RTP/AVP 18 101. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=no. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=ptime:20. a=sendrecv. -- ------------------------------ Aviso legal: Este mensaje electrónico está dirigido únicamente a la(s) dirección(es) indicadas anteriormente; el carácter confidencial, personal e intransferible del mismo está protegido legalmente. Cualquier revelación, uso o reenvío no autorizado, completo o en parte, está prohibido. Si ha recibido este mensaje por equivocación, notifíquelo inmediatamente a la persona que lo ha enviado y borre el mensaje original junto con sus ficheros anexos sin leerlo ni grabarlo, total o parcialmente.

2 1

Kamailio 1.5 and Asterisk 1.8 issue (Protocol Error, Unspecified)
by Rowie 24 Feb '13

24 Feb '13

Hi, We are having an issue where a phone (snom in particular) cannot make a call through Asterisk. It just hangup and does not allow the call to go through. I am including a a sip trace on this thread to show what is happening within the call. Please see below: Received from udp:10.1.10.80:5060 at 26/10/2011 10:22:41:476 (490 bytes): SIP/2.0 481 Call/Transaction Does Not Exist Via: SIP/2.0/UDP 10.30.0.64:5060;received=10.30.0.64;branch=z9hG4bK-wowp1kmdy4rl;rport=5060 From: "Virgil Menendez" <sip:91421@ser.gowireless.net>;tag=6wkdms1r20 To: <sip:9513261429@ser.gowireless.net;user=phone>;tag=as0b87218f Call-ID: 3c26755bf15c-9iq08xqqblo6 CSeq: 4 INVITE Server: Asterisk PBX 1.8.7.1 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH Supported: replaces, timer Content-Length: 0 -------------------------------------------------------------------------------- Sent to udp:10.1.10.80:5060 at 26/10/2011 10:22:41:481 (387 bytes): ACK sip:vm9513261429@10.1.10.83:5060 SIP/2.0 v: SIP/2.0/UDP 10.30.0.64:5060;branch=z9hG4bK-wowp1kmdy4rl;rport Route: <sip:10.1.10.80;lr=on> f: "Virgil Menendez" <sip:91421@ser.gowireless.net>;tag=6wkdms1r20 t: <sip:9513261429@ser.gowireless.net;user=phone>;tag=as0b87218f i: 3c26755bf15c-9iq08xqqblo6 CSeq: 4 ACK Max-Forwards: 70 m: <sip:91421@10.30.0.64:5060>;reg-id=1 l: 0 -------------------------------------------------------------------------------- Received from udp:10.1.10.80:5060 at 26/10/2011 10:22:42:130 (868 bytes): SIP/2.0 200 OK Via: SIP/2.0/UDP 10.30.0.64:5060;received=10.30.0.64;branch=z9hG4bK-5evtiw6dm0po;rport=5060 Record-Route: <sip:10.1.10.80;lr=on> From: "Virgil Menendez" <sip:91421@ser.gowireless.net>;tag=qi3i8ze6z8 To: <sip:9513261429@ser.gowireless.net;user=phone>;tag=as3f8c0f96 Call-ID: 3c2676547a8d-2t5yi6jok1sv CSeq: 2 INVITE Server: Asterisk PBX 1.8.7.1 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH Supported: replaces, timer Session-Expires: 1800;refresher=uas Contact: <sip:9513261429@10.1.10.83:5060> Content-Type: application/sdp Content-Length: 256 v=0 o=root 1355451627 1355451627 IN IP4 10.1.10.83 s=Asterisk PBX 1.8.7.1 c=IN IP4 10.1.10.83 t=0 0 m=audio 16094 RTP/AVP 0 8 101 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 a=sendrecv -------------------------------------------------------------------------------- Sent to udp:10.1.10.80:5060 at 26/10/2011 10:22:42:132 (385 bytes): ACK sip:9513261429@10.1.10.83:5060 SIP/2.0 v: SIP/2.0/UDP 10.30.0.64:5060;branch=z9hG4bK-wszafb7cbzpw;rport Route: <sip:10.1.10.80;lr=on> f: "Virgil Menendez" <sip:91421@ser.gowireless.net>;tag=qi3i8ze6z8 t: <sip:9513261429@ser.gowireless.net;user=phone>;tag=as3f8c0f96 i: 3c2676547a8d-2t5yi6jok1sv CSeq: 2 ACK Max-Forwards: 70 m: <sip:91421@10.30.0.64:5060>;reg-id=1 l: 0 -------------------------------------------------------------------------------- Received from udp:10.1.10.80:5060 at 26/10/2011 10:22:42:232 (503 bytes): BYE sip:91421@10.30.0.64:5060 SIP/2.0 Via: SIP/2.0/UDP 10.1.10.80;branch=z9hG4bKe723.bf70c1f4.0 Via: SIP/2.0/UDP 10.1.10.83:5060;branch=z9hG4bK69f53cf1 Max-Forwards: 69 From: <sip:9513261429@ser.gowireless.net;user=phone>;tag=as3f8c0f96 To: "Virgil Menendez" <sip:91421@ser.gowireless.net>;tag=qi3i8ze6z8 Call-ID: 3c2676547a8d-2t5yi6jok1sv CSeq: 102 BYE User-Agent: Asterisk PBX 1.8.7.1 X-Asterisk-HangupCause: Protocol error, unspecified X-Asterisk-HangupCauseCode: 111 Content-Length: 0 -- View this message in context: http://old.nabble.com/Kamailio-1.5-and-Asterisk-1.8-issue-%28Protocol-Error… Sent from the OpenSER Users Mailing List mailing list archive at Nabble.com.

4 3

Core fm_realloc function
by Bruno Bresciani 08 Jan '13

08 Jan '13

Hi all, I observed two at 0x08173bf0 in fm_realloc (qm=0xb5f7d000, p=0xb61f0bc0, size=0) at mem/f_malloc.c:536. I don't know exactly what may be caused this core because the debug of kamailio is disabled, but looking at backtrace (gdb) and source code I could notice a relationship with TLS connection establishment (handshake). Other important fact is that core was generated by the kamalio itself with signal 6 (abort) because it can't find the pointer to memory realloc. I'd like to know if someone already observed this issue and if my analyse above is correct? Bellow is backtrace full with gdb: Core was generated by `/home2/local/kamailio/sbin/kamailio -P /var/run/kamailio.pid'. Program terminated with signal 6, Aborted. #0 0x00f30402 in __kernel_vsyscall () (gdb) (gdb) (gdb) (gdb) (gdb) bt full #0 0x00f30402 in __kernel_vsyscall () No symbol table info available. #1 0x009fec10 in raise () from /lib/libc.so.6 No symbol table info available. #2 0x00a00521 in abort () from /lib/libc.so.6 No symbol table info available. #3 0x08173bf0 in fm_realloc (qm=0xb5f7d000, p=0xb61f0bc0, size=0) at mem/f_malloc.c:536 f = (struct fm_frag *) 0xb61f0bb8 pf = <value optimized out> orig_size = 18 L=ÃbÂ¬Ã2n = (struct fm_frag *) 0xb61f0bd2 ptr = <value optimized out> hash = 23548 #4 0x0051a87f in ser_realloc (ptr=0xb61f0bc0, size=32) at ../../mem/shm_mem.h:266 No locals. #5 0x00460295 in OPENSSL_cleanse () from /lib/libcrypto.so.6 No symbol table info available. #6 0x004609f7 in CRYPTO_realloc () from /lib/libcrypto.so.6 No symbol table info available. #7 0x003efb22 in sk_insert () from /lib/libcrypto.so.6 No symbol table info available. #8 0x003efbaa in sk_push () from /lib/libcrypto.so.6 No symbol table info available. #9 0x007c2ac3 in ssl_bytes_to_cipher_list () from /lib/libssl.so.6 No symbol table info available. #10 0x007aa9f3 in ssl3_get_client_hello () from /lib/libssl.so.6 No symbol table info available. #11 0x007ab815 in ssl3_accept () from /lib/libssl.so.6 No symbol table info available. #12 0x007c1c3a in SSL_accept () from /lib/libssl.so.6 No symbol table info available. #13 0x005278e3 in tls_accept (c=0xb621af88, error=0xbf91dfc8) at tls_server.c:346 ret = <value optimized out> ssl = (SSL *) 0xb61c1878 cert = <value optimized out> tls_c = (struct tls_extra_data *) 0xb6208e58 tls_log = <value optimized out> #14 0x0052da8e in tls_read_f (c=0xb621af88, flags=0xbf91e200) at tls_server.c:1028 r = (struct tcp_req *) 0xb621affc bytes_free = 4095 bytes_read = 70 read_size = 4095 ssl_error = 0 ssl_read = 0 ssl = (SSL *) 0xb61c1878 rd_buf = "\026\003\001\000A\001\000\000=\003\001OÃ¿\vÂ¡ywP\fkÃDÃ 0/\000\a\000\005\001\000ÃÃÃÃ¯000\000\026\0009\0008\0005\000\026\000\023\000\n\0003\0002\00 202i<Ã¤<Ã¥Ã¾\031Ã¬234Â \237Ãª030Y){lÑ¶"...06Ã'Ãr9Ã¬Ã«Â¸{[Â©\t\205\037\036Ã¿HPH5Âµ\t(Ã©32Ã027Ã¦Ã²036Â¾\"\rÔ¤YÃ215uÂº\027)Ã¶000Ã±215\vÃÃ Ã©Ea\023xÃ©J\206T\204CÃ wr_buf = "\027\003\001\003Â wÂ²'\016Ñ¼Ã033ÃLÃ021Ã)Ã\220hnLÂ¦\020XÃª\236\200\tIhÃÂ¸Sf\234Ã\rÃ ?Â¯Â¼\024FÃ\200Âª/\2264RÃaÃÂ¤IpXÂ»Â¨Ã035Ã¤Qh\211Ã026Ã½4ÃU+\asrÂ£/`Â¤OÃ»1AÊ¹qUÜ¿Â·vÂ±Ã¼\205"... rd = {buf = 0xbf90dfa4 "\026\003\001", pos = 70, used = 70, size = 65536} wr = { buf = 0xbf8fdfa4 "\027\003\001\003Â wÂ²'\016Ñ¼Ã033ÃLÃ021Ã)Ã\220hnLÂ¦\020XÃª\236\200\tIhÃÂ¸Sf\234Ã\rÃ ?Â¯Â¼\024FÃ\200Âª/\2264RÃaÃÂ¤IpXÂ»Â¨Ã035Ã¤Qh\211Ã026Ã½4ÃU+\asrÂ£/`Â¤OÃ»1AÊ¹qUÜ¿Â·vÂ±Ã¼\205"..., pos = 0, used = 0, size = 65536} tls_c = (struct tls_extra_data *) 0xb6208e58 enc_rd_buf = (struct tls_rd_buf *) 0x0 n = 0 flush_flags = <value optimized out> err_src = 0x541a83 "TLS read:" x = <value optimized out> #15 0x08158ade in tcp_read_headers (c=0xb621af88, read_flags=0xbf91e200) at tcp_read.c:406 bytes = -1 remaining = <value optimized out> p = <value optimized out> r = (struct tcp_req *) 0xb621affc #16 0x08158fd4 in tcp_read_req (con=0xb621af88, bytes_read=0xbf91e204, read_flags=0xbf91e200) at tcp_read.c:871 bytes = <value optimized out> total_bytes = 0 resp = <value optimized out> size = <value optimized out> req = (struct tcp_req *) 0xb621affc dst = {send_sock = 0x1, to = {s = {sa_family = 57540, sa_data = "\221Â¿\020\000\000\000\000\000\000\000\020\000\000"}, sin = {sin_family = 57540, sin_port = 49041, sin_addr = {s_addr = 16}, sin_zero = "\000\000\000\000\020\000\000"}, sin6 = {sin6_family = 57540, sin6_port = 49041, sin6_flowinfo = 16, sin6_addr = {in6_u = {u6_addr8 = "\000\000\000\000\020\000\000\000\001\000\000\000\001\000\000", u6_addr16 = {0, 0, 16, 0, 1, 0, 1, 0}, u6_addr32 = {0, 16, 1, 1}}}, sin6_scope_id = 12}}, id = -1080958468, proto = 4 '\004', send_flags = {f = 0 '\0', blst_imask = 0 '\0'}} c = 10 '\n' #17 0x08159a0f in handle_io (fm=0x83296b0, events=1, idx=-1) at tcp_read.c:1150 ret = 4 n = 4 read_flags = 1 con = (struct tcp_connection *) 0xb621af88 s = 12 resp = <value optimized out> t = <value optimized out> #18 0x0815d653 in tcp_receive_loop (unix_sock=35) at io_wait.h:1091 No locals. ---Type <return> to continue, or q <return> to quit--- #19 0x0812885b in tcp_init_children () at tcp_main.c:4819 r = 3 reader_fd_1 = 35 pid = <value optimized out> si = <value optimized out> #20 0x080ad412 in main_loop () at main.c:1632 i = 4 pid = <value optimized out> si = (struct socket_info *) 0x0 si_desc = "udp receiver child=3 sock=192.168.166.31:5060 \000\221Â¿\002\000\000\000/\200\220\000\001\000\000\000\000\000H\000Â¨Ã¤21Â¿\001\000\000\000Â°Â¶Ã¨026Â¶\000\000\000\000\000ÃÂµ\030s2\b\002\000\000\000Ã¢f\b\000ÃÂµ\001\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000Ã¿Ã¿Ã¿Ã¿Â¸Ã¤21Â¿" #21 0x080afbe7 in main (argc=3, argv=dwarf2_read_address: Corrupted DWARF expression. ) at main.c:2398 cfg_stream = (FILE *) 0x8a2d008 c = <value optimized out> r = 0 tmp = 0xbf91e674 "\212Ã¾\221Â¿\233Ã¾\221Â¿Â°Ã¾\221Â¿Â»Ã¾\221Â¿Ã\221Â¿Ã¹1Â¿\020Ã¿\221Â¿DÃ¿\221Â¿LÃ¿\221Â¿WÃ¿\221Â¿]Ã¿\221Â¿oÃ¿\221Â¿{Ã¿\221Â¿\202Ã¿\221 tmp_len = 10492229 port = 136192361 proto = -1080957480 ret = <value optimized out> seed = 21782655 rfd = 4 debug_save = <value optimized out> debug_flag = 0 dont_fork_cnt = 0 n_lst = <value optimized out> p = <value optimized out> Best Regards

4 24

[Kamailio-Users] BYE message not relayed to caller
by Vikram Ragukumar 04 Dec '12

04 Dec '12

Hello, My setup includes a cellphone that uses Wi-Fi to hookup to the internet with IP 192.168.1.101. Cellphone app, tries to register with VOIPSwitch through an outbound proxy server(Kamailio + rtpproxy), which rewrites SDP to force rtp through an rtpproxy. I can make a call from the cellphone to a PSTN number. When the PSTN endpoint hangs up, VOIPSwitch relays a BYE message to the proxy that looks like : No. Time Source Destination Protocol Info 27 18.383929 IPaddr_VoipSwitch IPaddr_proxy SIP Request: BYE sip:1234@IPaddr_VoipSwitch Frame 27 (420 bytes on wire, 420 bytes captured) Ethernet II, Src: Unispher_40:b5:39 (00:90:1a:40:b5:39), Dst: Supermic_bd:b9:bc (00:30:48:bd:b9:bc) Internet Protocol, Src: IPaddr_VoipSwitch , Dst: IPaddr_proxy User Datagram Protocol, Src Port: sip (5060), Dst Port: 7160 (7160) Session Initiation Protocol Request-Line: BYE sip:1234@IPaddr_VoipSwitch SIP/2.0 Method: BYE [Resent Packet: False] Message Header Route: <sip:IPaddr_proxy:7160;lr=on;nat=yes> CSeq: 1 BYE Via: SIP/2.0/UDP IPaddr_VoipSwitch:5060; branch=z9hG4bk180242100434182912333954 From: sip:5678@IPaddr_VoipSwitch;tag=18024210041929123187506289 Call-ID: LUOyIDm-ecy36NcUfj5G3v1lM6g5snkM To: "1234" <sip:1234@IPaddr_VoipSwitch>;tag=9XHJmiuf58vTrF7.vwflEK-G63JVPQSi Content-Length: 0 The request URI in the above message is the IP address of VOIPSwitch itself, which causes the proxy to forward the BYE message back to VOIPSwitch. The cellphone never receives the BYE message and consequently never hangs up. Any suggestions on how i can get around this problem ? Thanks and Regards, Vikram.

3 9

is kamilio support RFC5626 now ?
by mike 16 Oct '12

16 Oct '12

dear kamilio developers : i read the kamilio 3.3.0' s new features , it say it support outbound , and i have place to handle reg-id and sip.instance . so , i wonder if the kamilio3.3.0 support RFC5626 now，so that the kamilio can be used as a edge proxy . i ask why because i can't find where kamilio add flow-token and path for the register request. thanks

5 8

kamailio core at qm_status
by Jijo 01 Oct '12

01 Oct '12

Hi All, I'm observing a core intermittently at "qm_status (qm=0x786cd000) at mem/q_malloc.c:763" for kamailio version 3.1.0 looking at the backtrace this is occurring while doing a tcp buffer overrun. Please have a look and let me know if anyone observed this issue or how can we debug it. Please find the backtrace and kamailio version osbprod-V2R0:~ # /usr/sbin/kamailio -V version: kamailio 3.1.0 (i386/linux) 21a375 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, PKG_SIZE 15MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: 21a375 compiled on 12:38:44 Apr 26 2012 with gcc 4.5.0 #0 qm_status (qm=0x786cd000) at mem/q_malloc.c:763 #1 0x0819c0f3 in qm_debug_frag (qm=0x786cd000, f=<value optimized out>) at mem/q_malloc.c:167 #2 0x0819c352 in qm_free (qm=0x786cd000, p=0x7a6cb6ac, file=0x821cce2 "<core>: tcp_main.c", func=0x822285f "wbufq_run", line=880) at mem/q_malloc.c:457 #3 0x0815f686 in wbufq_run (tcpconn=0x7a1a7548, ev=4, fd_i=-1) at tcp_main.c:880 #4 handle_tcpconn_ev (tcpconn=0x7a1a7548, ev=4, fd_i=-1) at tcp_main.c:4141 #5 0x08169bf2 in io_wait_loop_epoll () at io_wait.h:1092 #6 tcp_main_loop () at tcp_main.c:4606 #7 0x080b0404 in main_loop () at main.c:1655 #8 0x080b1f84 in main (argc=9, argv=0xbfb4c9f4) at main.c:2446 (gdb) l 758 LOG_(DEFAULT_FACILITY, memlog, "qm_status: ", 759 "dumping free list stats :\n"); 760 for(h=0,i=0;h<QM_HASH_SIZE;h++){ 761 unused=0; 762 for (f=qm->free_hash[h].head.u.nxt_free,j=0; 763 f!=&(qm->free_hash[h].head); f=f->u.nxt_free, i++, j++){ 764 if (!FRAG_WAS_USED(f)){ 765 unused++; 766 #ifdef DBG_QM_MALLOC 767 LOG_(DEFAULT_FACILITY, memlog, "qm_status: ",

4 7

[Kamailio-Users] AudioCodes + Kamailio : Problem in SIP Message Headers
by Samuel Muller 26 Sep '12

26 Sep '12

Hello all, I recently add a classical Audiocodes Mediant 2000 with 2x 8E1, the purpose is to have several interconnections with PSTN. I configured it like this : Audiocodes registers as a gateway to the Kamailio, using a dedicated port (5062). Registration seems to be OK, and the pstn gw uses OPTIONS method to ping the proxy. I can attack the Audiocodes with a SIP phone behind Kamailio, no pbm. But the audiocodes returns some errors about SIP headers sent by Kamailio : ( sip_stack)(44732 ) AcSIPParser: Problem in SIP Message Headers [Time: 12:30:26] ( sip_stack)(44733 ) !! [ERROR] AcSIPParser: Parse Error. Unexpected symbol '0' in scheme. ALPHA expected Here you have the example of an INVITE from a SIP phone to the PSTN : ** audiocodes debug ** 4d:12h:30m:26s ( lgr_flow)(44730 ) ---- Incoming SIP Message from 77.246.81.132:5060 ---- INVITE sip:0323719001@77.246.81.136:5062;transport=udp SIP/2.0 Record-Route: <sip:77.246.81.132;lr=on;ftag=71078b346a20fb3eo0;nat=yes> Via: SIP/2.0/UDP 77.246.81.132;branch=z9hG4bKdace.1ab1d59.0 Via: SIP/2.0/UDP 192.168.0.113:5060;rport=15170;received=77.246.81.162;branch=z9hG4bK-b432f96 From: "Sam" <sip:0123451010@sip.720.fr <sip%3A0123451010(a)sip.720.fr>>;tag=71078b346a20fb3eo0 To: <sip:0323719001@sip.720.fr <sip%3A0323719001(a)sip.720.fr>> Call-ID: 944d8aec-27503ee6(a)192.168.0.113 CSeq: 102 INVITE Max-Forwards: 49 Contact: "Sam" <sip:0123451010@77.246.81.162:15170> Expires: 240 User-Agent: Linksys/SPA941-5.1.8 Content-Length: 281 Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER Supported: 100rel, replaces Content-Type: application/sdp P-Asserted-Identity: <0123451010> Remote-Party-ID: <0123451010>;party=caller;privacy=none;screen=yes v=0 o=- 26933860 26933860 IN IP4 192.168.0.113 s=- c=IN IP4 77.246.81.133 t=0 0 m=audio 35038 RTP/AVP 18 0 8 101 a=rtpmap:18 G729a/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:30 a=sendrecv a=nortpproxy:yes ( sip_stack)(44732 ) AcSIPParser: Problem in SIP Message Headers [Time: 12:30:26] ( sip_stack)(44733 ) !! [ERROR] AcSIPParser: Parse Error. Unexpected symbol '0' in scheme. ALPHA expected ( sip_stack)(44734 ) !! [ERROR] Message type: INVITE [Time: 12:30:26] ( sip_stack)(44735 ) !! [ERROR] Source header: [Time: 12:30:26] ( sip_stack)(44736 ) !! [ERROR] Line: 17. Column: 23 [Time: 12:30:26] The outgoing INVITE from Kamailio is exactly the same received by the AudioCodes. When I searched over Google, I just found 2 answers about Asterisk / Audiocodes unsolved problem, but no more informations. I supposed that the problem is as indicated : " s=- " where source is empty in place of "NULL" / "0" or something like this ... Someone can confirm or already met the problem ? Many thanks all :) .Sam.

5 5

[Kamailio-Users] Having problems using RTPProxy to bridge internal/external networks
by Joe Hart 15 Sep '12

15 Sep '12

Hi all, For a project on which I'm currently working, I am having some problems figuring out how to correctly configure Kamailio to communicate with RTP Proxy in order to send media into and out of a network with private IP address ranges. I have a proxy set up to send the SIP traffic, and all of this is working fine. However, I'm having some trouble getting the RTP Proxy set up. Currently, when the call is connected, the offer/answer is made and RTP Proxy seems to be taking over, but I'm having trouble getting my audio to flow in both directions. Examination of the traffic coming into and out of this machine seems to indicate that the IP addresses aren't being mangled correctly. Specifically, it appears the internal IP address isn't being changed to reflect the IP address of the machine on which RTP Proxy is running, so that when the caller tries to send audio back, the IP it's given to reply to is 10.10.x.x, which obviously won't work. I have tried experimenting with specifically setting IP addresses in the rtpproxy_offer() and _answer() methods to no avail, as well as setting various flags in those methods. However, I must admit that I'm not entirely sure what's happening under the hood with these methods, or what rtpproxy is doing with that information when it gets it. Rather than continue to hack at this by trial and error, I'm hoping someone here can point me in the right direction. Any advice, example code or pep talks would be greatly appreciated. Thanks in advance, -- Joe Hart Voice Systems Integrator Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0673

8 37

Suggestions for time utils
by Andreas Granig 16 Aug '12

16 Aug '12

Hi, I'd like to implement a couple of helper functions for time handling, e.g. checking day of week, day of month etc. from within the kamailio config file. What would you prefer, a new module ("timeutils" maybe?) or adding it to cfgutils (there are already time-based functions there like sleep and usleep)? The idea is to implement time based call-forwards, and an approach could be to provision various time-related values in usr_preferences table, and then check it in the config. For example, when doing call-forwards from Monday to Friday only, I could put this into usr_preferences: attribute: cf_weekday value: [1, 2, 3, 4, 5] (each entry is a separate row in usr_preferences) And in kamailio config, I'd call this: avp_db_load(...); if(is_weekday("$avp(s:cf_weekday)")) { do CF } So is_weekday would iterate over the entries in the avp list and return true if the weekday at the time of routing matches an entry in the list. A module config param could control whether to use gmtime or localtime for matching. Does this make sense? Suggestions for other approaches? I'd rather prefer to do it directly in config instead of using some external interpreter like lua, python etc. Andreas

3 17

Possible bad lcr module, after upgrade to 3.3.0 from 3.2
by Alexey Mechanoshin 13 Aug '12

13 Aug '12

Hello. After upgrade kamailio and db, lcr module bad routing if entered *any value*to from_uri column in lcr_rule table: mysql> select * from lcr_rule where id=5; +----+--------+--------+-------------------------------+-------------+---------+---------+ | id | lcr_id | prefix | from_uri | request_uri | stopper | enabled | +----+--------+--------+-------------------------------+-------------+---------+---------+ | 5 | 1 | yyyy | sip:x[xx]\d{2}@xxx.xxx.xx.xx | NULL | 0 | 1 | +----+--------+--------+-------------------------------+-------------+---------+---------+ and load_gw(...) skip this rule, in log: INFO: lcr [lcr_mod.c:1493]: skipping disabled <gw/rule> = <1/5> If remove value from 'from_ui' - rule enabled and all work. Why is turned off rule ? Linux Debian squeeze, upgraded from "deb http://deb.kamailio.org/kamailiosqueeze main" -- "В связи с отсутствием интереса общественности, конец света отменяется" (с) ? С Уважением, Механошин Алексей

3 11

Outbound and Registrar. No binding update
by José Luis Millán 02 Aug '12

02 Aug '12

Hi, I'm using Kamilio 3.3.0 as registrar server. I`m using an outbound proxy so 'use_path' parameter or 'registrar' module is enabled. According to RFC 5626, a re-registration from a specific combination of AoR, instance_id and reg_id must update the binding. "" If the registrar receives a re-registration for a specific combination of AOR, and instance-id and reg-id values, the registrar MUST update any information that uniquely identifies the network flow over which the request arrived if that information has changed, and SHOULD update the time the binding was last updated. "" In my installation this is not fullfilled as shown: "" AOR:: jmillan Contact:: sip:jmillan@MY_IP;transport=ws;ov-ob=a570655c14 Q= Expires:: 181 Callid:: 1hgq3khalq2rzfr Cseq:: 108 User-agent:: JsSIP 0.1.0 Path:: <sip:OUTBOUND_IP:9090;transport=tcp;lr;ovid=de0c0b9f>,<sip:a570655c14@OUTBOUND_IP :10080;transport=ws;lr;ovid=de0c0b9f;ob> State:: CS_SYNC Flags:: 0 Cflag:: 0 Socket:: tcp:KAM_IP:5060 Methods:: 783 Ruid:: uloc-50119d99-328e-1 Instance:: <urn:uuid:38dce009-ae1f-4fd1-91dc-99ed9affddc1> Reg-Id:: 1 Contact:: sip:jmillan@MY_IP;transport=ws;ov-ob=1dd97b4d51 Q= Expires:: 193 Callid:: 1hgq3khalq2rzfr Cseq:: 110 User-agent:: JsSIP 0.1.0 Path:: <sip:OUTBOUND_IP:9090;transport=tcp;lr;ovid=de0c0b9f>,<sip:1dd97b4d51@OUTBOUND_IP :10080;transport=ws;lr;ovid=de0c0b9f;ob> State:: CS_SYNC Flags:: 0 Cflag:: 0 Socket:: tcp:KAM_IP:5060 Methods:: 783 Ruid:: uloc-50119d99-3290-2 Instance:: <urn:uuid:38dce009-ae1f-4fd1-91dc-99ed9affddc1> Reg-Id:: 1 "" The scenario is such that when the client looses the connection with the Outbound Server, it reconnects and re-registers to Kamailio in order to replace registration and be able to receive in-dialog messages. Any comment is wellcome. Regards,

4 19

planning release of v3.3.1
by Daniel-Constantin Mierla 02 Aug '12

02 Aug '12

Hello, I am planning to package v3.3.1 out of the latest branch 3.3 this Thursday, August 2. If you are aware of issues that are not listed on the tracker (http://sip-router.org/tracker/), add them there to see what can be sorted out before. Cheers, Daniel -- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw

1 1

cannot allocate memory & increase shared memory
by Alex Solt 01 Aug '12

01 Aug '12

Hi, We are getting "cannot allocate memory" error in the log file. I was wondering which one is the right way to increase the shared memory: 1) adding the following to /etc/openser/openserctl STARTOPTIONS="-m 128" 2) modify the following in /etc/default/openser MEMORY=1024 Thanks,AS

2 1

New Wiki Site has problems?
by Andrew Pogrebennyk 31 Jul '12

31 Jul '12

At least some links at http://www.kamailio.org/wiki/ don't work at the moment: Install Kamailio v3.3.x From GIT Upgrade Kamailio v3.1.x to v3.2.0 Upgrade Kamailio v3.2.x to v3.3.0 you are redirected to some instruction from DokuWiki Installer when trying to visit them. Could somebody please check it? Thanks. Andrew

2 1

routing based on username
by Richard Zheng 31 Jul '12

31 Jul '12

Hi, We are trying to follow http://kb.asipto.com/asterisk:realtime:kamailio-3.1.x-asterisk-1.6.2-astdbto setup Kamailio as front end and multiple PBXs as back end. We need to forward sip messages to the respective servers based on the contact. For example, users 101, 102 go to PBX at 1.1.1.1 and users 201, 202 go to PBX at 1.1.1.2. Where is a good place to save this info and how to route them in the config? Also we have some users with fixed IP addresses which don't use authentication. How do we route the calls based on source IP? Since we have plenty of these users, we'd like to save them in database too. Any advice is appreciated! Richard

3 2

Add Own Plug-in
by Ananth Kollipara 31 Jul '12

31 Jul '12

Hi, Can you please provide the steps to add a plug-in? Regards, Ananth

2 1

ACK not relayed
by David Notivol 31 Jul '12

31 Jul '12

In a UAC-Kamailio-UAS scenario, we've found a case where the ACK coming from uac is not relayed by our proxy to the uas. This is the log for the ACK message: Jul 27 10:04:59 theseus-test /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core> [parser/msg_parser.c:624]: SIP Request: Jul 27 10:04:59 theseus-test /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core> [parser/msg_parser.c:626]: method: <ACK> Jul 27 10:04:59 theseus-test /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core> [parser/msg_parser.c:628]: uri: <sip:59138553189@79.170.68.157> <sip:59138553189@79.170.68.157> Jul 27 10:04:59 theseus-test /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core> [parser/msg_parser.c:630]: version: <SIP/2.0> Jul 27 10:04:59 theseus-test /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core> [parser/parse_via.c:1286]: Found param type 235, <rport> = <n/a>; state=6 Jul 27 10:04:59 theseus-test /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core> [parser/parse_via.c:1286]: Found param type 232, <branch> = <z9hG4bKKc4gKXyemS9HD>; state=16 Jul 27 10:04:59 theseus-test /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core> [parser/parse_via.c:2561]: end of header reached, state=5 Jul 27 10:04:59 theseus-test /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core> [parser/msg_parser.c:511]: parse_headers: Via found, flags=2 Jul 27 10:04:59 theseus-test /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core> [parser/msg_parser.c:513]: parse_headers: this is the first via Jul 27 10:04:59 theseus-test /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core> [receive.c:149]: After parse_msg... Jul 27 10:04:59 theseus-test /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core> [receive.c:190]: preparing to run routing scripts... Jul 27 10:04:59 theseus-test /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: sl [sl_funcs.c:396]: DEBUG : sl_filter_ACK: to late to be a local ACK! Jul 27 10:04:59 theseus-test /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: maxfwd [mf_funcs.c:85]: value = 65 Jul 27 10:04:59 theseus-test /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core> [parser/parse_to.c:178]: DEBUG: add_param: tag=6ne1x6d6-CC-23 Jul 27 10:04:59 theseus-test /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core> [parser/parse_to.c:802]: end of header reached, state=29 Jul 27 10:04:59 theseus-test /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core> [parser/msg_parser.c:188]: DEBUG: get_hdr_field: <To> [52]; uri=[sip:59138553189@79.170.68.157] Jul 27 10:04:59 theseus-test /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core> [parser/msg_parser.c:190]: DEBUG: to body [ <sip:59138553189@79.170.68.157> <sip:59138553189@79.170.68.157>] Jul 27 10:04:59 theseus-test /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core> [parser/msg_parser.c:168]: get_hdr_field: cseq <CSeq>: <31362871> <ACK> Jul 27 10:04:59 theseus-test /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core> [parser/msg_parser.c:202]: DEBUG: get_hdr_body : content_length=0 Jul 27 10:04:59 theseus-test /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core> [parser/msg_parser.c:104]: found end of header Jul 27 10:04:59 theseus-test /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core> [parser/parse_to.c:178]: DEBUG: add_param: tag=0cS8trtaF196F Jul 27 10:04:59 theseus-test /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: <core> [parser/parse_to.c:802]: end of header reached, state=29 Jul 27 10:04:59 theseus-test /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: sanity [mod_sanity.c:255]: sanity checks result: 1 Jul 27 10:04:59 theseus-test /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: siputils [checks.c:106]: totag found Jul 27 10:04:59 theseus-test /usr/local/kamailio/sbin/kamailio[17358]: ERROR: <script>: ESTAMOS EN WITHIN Jul 27 10:04:59 theseus-test /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: rr [loose.c:108]: No Route headers found Jul 27 10:04:59 theseus-test /usr/local/kamailio/sbin/kamailio[17358]: DEBUG: rr [loose.c:829]: There is no Route HF Jul 27 10:04:59 theseus-test /usr/local/kamailio/sbin/kamailio[17358]: ERROR: <script>: NO LOOSE ROUTE However, in a pcap trace I clearly see the Route header: This is the Record-Route in the 200 message Record-Route: <sip:79.170.68.157;lr;ftag=330cdf48-co1022-INS033> And this is the Route header in the ACk: Route: <sip:79.170.68.157;lr;ftag=330cdf48-co1022-INS033> I haven't been able to figure out what's going on. We have plenty of traffic working in that proxy. What am I missing? Thanks in advance David.

2 8

BYE Race Condition
by Brandon Armstead 31 Jul '12

31 Jul '12

Hello, I am running into an issue where there is a race condition happening. I am looking for opinions / ideas on how to handle the following below scenario. Scenario. UAC places an outbound call -> upstream carrier. The call is disconnected on both ends at the exact same time, UAC -> sends BYE upstream Upstream Carrier -> sends BYE downstream Upstream 200 OK's the BYE UAC sends 481 back to Upstream Carrier for their generated BYE. The upstream carrier is complaining about receiving the relayed 481 responses -- so my first thought was simply to drop() these from relaying upstream. I am curious how other people are handling this? Would you suggest simply dropping the relay from being sent back upstream on the 481? Would you simply always 200 OK a downstream BYE from trusted carriers regardless of UAC response, and create separate transaction to send BYE downstream? Thank you as always. Look forward to your thoughts / suggestions / ideas. Sincerely, Brandon Armstead

2 2

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 July 2012