sr-users March 2013

sr-users@lists.kamailio.org

92 participants
141 discussions

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, 4 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

10 years, 4 months

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

10 years, 4 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

10 years, 8 months

Message Waiting

by Daniel W. Graham

While I have seen other posts I have not found anything that describes my scenario. Kamailio sets in front of a group of asterisk servers which are used in a round robin dispatch group. All asterisk servers share a common database in which voicemail boxes are defined and messages are stored. I'm looking for a way to make message waiting work in this example. I have tried creating a view with basic peer information for asterisk to use for message notification, however asterisk does not 'see' these peers until a call is made to the specific user and the peer info is retrieved from the database, which can delay notifications severely rendering them useless. I also want to avoid sending a copy of the registrations to asterisk servers, as the purpose of the distributed system is to eliminate the large number of sip registrations asterisk needs to manage. I have also seen a couple of script methods that look at the voicemail directory structure for file changes and trigger an application like sipsak to generate the notifications and let kamailio relay them. From what I see, the consensus is not to go this route. In my case the script would need to look at the database level, and maybe some sort of database trigger could be used. What are others doing / what do others recommend as the best way to handle message waiting with a situation where kamailio sets in front of a voicemail server? Any input is appreciated. Dan-

10 years, 9 months

Problem with Realtime Kamailio-Asterisk integration

by aaaa aaaa

Hello, I followed the step by step guide (http://kb.asipto.com/asterisk:realtime:kamailio-3.3.x-asterisk-10.7.0-astdb) that describe the realtime integration between Kamailio and Asterisk. I have no problem with registration but when I try a call from 101 to 102 I get the followng error: [Mar 31 01:18:44] NOTICE[32330][C-00000006]: chan_sip.c:25195 handle_request_invite: Call from '101' (192.168.1.100:5060) to extension '103' rejected because extension not found in context 'DEFAULT NULL'. Kamailio and Asterisk are running in the same machine. Any idea about the cause of this problem? Best Regards, Theo

10 years, 11 months

pkg mem problems. Leaking?

by Jon Bonilla

Hi all I have two different kamailio servers running in a single machine. The first one is a sl proxy and the second one acts as stateful proxy/registrar. From time to time the stateless one goes out of pkg mem. It has 8MB (also tried with 16 in another setup). The sl proxy listens the public interface for external connections and the loopback interface for conecting to the stateful proxy. As I have seen since I installed a mem debug kamailio 3.3.2 version there 6 days ago, the internal socket children have grown on mem usage while the external ones remain more or less stable. As example one uf the external udp receivers uses less than 1MB while one of the internal ones uses almost 6MB. I'm attaching the mem dump of one of those internal udp receiver processes via "ngcp-sercmd lb cfg.set_now_int core mem_dump_pkg 25437" command. I see several tens of thousands of lines like these ones: N address=0x7fd1207383c0 frag=0x7fd120738390 size=56 used=1 alloc'd from <core>: parser/parse_param.c: parse_params(539) start check=f0f0f0f0, end check= c0c0c0c0, abcdefed I have no idea about how to continue debugging this. I'm pasting some more info regarding the process list, mem status and kamailio version/flags. Thanks sp1:~# ngcp-sercmd lb ps 25416 attendant 25429 udp receiver child=0 sock=77.77.77.77:5060 25430 udp receiver child=1 sock=77.77.77.77:5060 25431 udp receiver child=2 sock=77.77.77.77:5060 25432 udp receiver child=3 sock=77.77.77.77:5060 25433 udp receiver child=4 sock=77.77.77.77:5060 25434 udp receiver child=5 sock=77.77.77.77:5060 25435 udp receiver child=6 sock=77.77.77.77:5060 25436 udp receiver child=7 sock=77.77.77.77:5060 25437 udp receiver child=0 sock=127.0.0.1:5060 25438 udp receiver child=1 sock=127.0.0.1:5060 25439 udp receiver child=2 sock=127.0.0.1:5060 25440 udp receiver child=3 sock=127.0.0.1:5060 25441 udp receiver child=4 sock=127.0.0.1:5060 25442 udp receiver child=5 sock=127.0.0.1:5060 25443 udp receiver child=6 sock=127.0.0.1:5060 25444 udp receiver child=7 sock=127.0.0.1:5060 25445 slow timer 25446 timer 25447 ctl handler 25448 MI FIFO 25449 tcp receiver (generic) child=0 25450 tcp receiver (generic) child=1 25451 tcp receiver (generic) child=2 25452 tcp receiver (generic) child=3 25453 tcp receiver (generic) child=4 25454 tcp receiver (generic) child=5 25455 tcp receiver (generic) child=6 25456 tcp receiver (generic) child=7 25457 tcp receiver (tcp:127.0.0.1:5060) child=8 25458 tcp receiver (tcp:127.0.0.1:5060) child=9 25459 tcp main process sp1:~# ngcp-sercmd lb pkg.stats { entry: 0 pid: 25416 rank: 0 used: 901136 free: 15417544 real_used: 1359672 } { entry: 1 pid: 25429 rank: 1 used: 909360 free: 15408648 real_used: 1368568 } { entry: 2 pid: 25430 rank: 2 used: 909400 free: 15408608 real_used: 1368608 } { entry: 3 pid: 25431 rank: 3 used: 909352 free: 15408656 real_used: 1368560 } { entry: 4 pid: 25432 rank: 4 used: 909344 free: 15408664 real_used: 1368552 } { entry: 5 pid: 25433 rank: 5 used: 909392 free: 15408712 real_used: 1368504 } { entry: 6 pid: 25434 rank: 6 used: 909344 free: 15408664 real_used: 1368552 } { entry: 7 pid: 25435 rank: 7 used: 909344 free: 15408664 real_used: 1368552 } { entry: 8 pid: 25436 rank: 8 used: 909352 free: 15408656 real_used: 1368560 } { entry: 9 pid: 25437 rank: 9 used: 5884872 free: 2480784 real_used: 14296432 } { entry: 10 pid: 25438 rank: 10 used: 5935272 free: 2359728 real_used: 14417488 } { entry: 11 pid: 25439 rank: 11 used: 5971616 free: 2305912 real_used: 14471304 } { entry: 12 pid: 25440 rank: 12 used: 5821672 free: 2522672 real_used: 14254544 } { entry: 13 pid: 25441 rank: 13 used: 5945584 free: 2310056 real_used: 14467160 } { entry: 14 pid: 25442 rank: 14 used: 5868760 free: 2495264 real_used: 14281952 } { entry: 15 pid: 25443 rank: 15 used: 5903672 free: 2457952 real_used: 14319264 } { entry: 16 pid: 25444 rank: 16 used: 5899208 free: 2453872 real_used: 14323344 } { entry: 17 pid: 25445 rank: -1 used: 983944 free: 15409512 real_used: 2267696 } { entry: 18 pid: 25446 rank: -1 used: 909168 free: 15409512 real_used: 1367704 } { entry: 19 pid: 25447 rank: -2 used: 983664 free: 15407912 real_used: 2267032 } { entry: 20 pid: 0 rank: 0 used: 918424 free: 15400064 real_used: 1377152 } { entry: 21 pid: 25449 rank: 17 used: 989192 free: 15329200 real_used: 1448016 } { entry: 22 pid: 25450 rank: 18 used: 989192 free: 15329200 real_used: 1448016 } { entry: 23 pid: 25451 rank: 19 used: 989192 free: 15329200 real_used: 1448016 } { entry: 24 pid: 25452 rank: 20 used: 989192 free: 15329200 real_used: 1448016 } { entry: 25 pid: 25453 rank: 21 used: 989192 free: 15329200 real_used: 1448016 } { entry: 26 pid: 25454 rank: 22 used: 989192 free: 15329200 real_used: 1448016 } { entry: 27 pid: 25455 rank: 23 used: 989192 free: 15329200 real_used: 1448016 } { entry: 28 pid: 25456 rank: 24 used: 989192 free: 15329200 real_used: 1448016 } { entry: 29 pid: 25457 rank: 25 used: 989192 free: 15329200 real_used: 1448016 } { entry: 30 pid: 25458 rank: 26 used: 989192 free: 15329200 real_used: 1448016 } { entry: 31 pid: 25459 rank: -4 used: 983240 free: 15334096 real_used: 2266992 } sp1:~# kamailio -V version: kamailio 3.3.2 (x86_64/linux) 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: unknown compiled on 13:08:06 Oct 31 2012 with gcc 4.4.5

11 years

sip_trace unable to capture after next_branches()

by Ramaseshi reddy kolli

Hi, I am using sip_trace function after next_branches(), it is not capturing outbound SIP INVITE request can anyone please help me. Thanks Ram

11 years

db_mode 3 in usrloc module

by Morten Isaksen

Hi, I have an older installation of Kamailio (3.1.1). It is configured with modparam("usrloc", "db_mode", 2) I tried to change this to modparam("usrloc", "db_mode", 3) to not have to restart kamailio when I change the alias table directly from SQL. But then kamailio shutsdown after about one second with this error: Mar 26 20:38:55 sip-3-1 /usr/local/sbin/kamailio[11510]: ERROR: <core> [db.c:408]: invalid version 0 for table trusted found, expected 5 (check table structure and table "version") Mar 26 20:38:55 sip-3-1 /usr/local/sbin/kamailio[11510]: ERROR: permissions [trusted.c:250]: error during table version check. Mar 26 20:38:55 sip-3-1 /usr/local/sbin/kamailio[11510]: ERROR: <core> [sr_module.c:832]: init_mod_child(): Error while initializing module permissions (/usr/local/lib/kamailio/modules_k/permissions.so) Mar 26 20:38:55 sip-3-1 /usr/local/sbin/kamailio[11510]: ERROR: <core> [pt.c:481]: ERROR: fork_tcp_process(): init_child failed for process 28, pid 11510, "tcp receiver child=6" Mar 26 20:38:55 sip-3-1 /usr/local/sbin/kamailio[11510]: ERROR: <core> [tcp_main.c:4811]: ERROR: tcp_main: fork failed: Success Mar 26 20:38:55 sip-3-1 /usr/local/sbin/kamailio[11512]: : <core> [pass_fd.c:293]: ERROR: receive_fd: EOF on 44 Mar 26 20:38:55 sip-3-1 /usr/local/sbin/kamailio[11482]: ALERT: <core> [main.c:738]: child process 11510 exited normally, status=255 Mar 26 20:38:55 sip-3-1 /usr/local/sbin/kamailio[11482]: INFO: <core> [main.c:756]: INFO: terminating due to SIGCHLD I have not made any changes to the permissions/trusted module, so I suspect it is some shared database conection problem. Is it a known bug in this version? I would prefer not to upgrade the installation and hopes one of you can point me to a patch I can backport. -- Morten Isaksen

11 years

Evariste Systems to drop Kamailio market, become Acme Packet VAR

by Alex Balashov

For immediate release: ATLANTA, GA (1 April 2013)--Evariste Systems LLC, an Atlanta-based consultancy specialising in Kamailio-based VoIP infrastructure solutions for the ITSP and CLEC market, has announced that beginning in the second quarter of 2013, it will be abandoning its Kamailio-based technology portfolio to focus on its new role as a preferred VAR (Value Added Reseller) for Acme Packet (NASDAQ:APKT). "It is with a heavy heart that we abandon five years of Kamailio-oriented work and the Canonical SIP Routing Platform product derived from it," said Alex Balashov, the principal of the company. "However, the reality is that investment in open-source VoIP technology is a dead end. From a technological point of view, we have lagged very badly in meeting the needs of today's sophisticated VoIP market, and it's time to cut our losses. Asterisk, Kamailio, FreeSWITCH--all this stuff just hasn't kept up with the pace of evolution of 3GPP, ETSI, and ITU standards. We are tired of saying 'sorry, we don't support IMS or H.323' to our resultingly dwindling customer base. Does anyone actually run an all-SIP network?" Starting in early April, Evariste will begin providing value-added consultancy related to the implementation of the Acme Packet Net-Net Session Director. In Balashov's view, "the Net-Net SD is the only product capable of meeting the perimeter security, routing and peering needs of today's VoIP service delivery environment." Fred Posner, the director of Team Forrest, a Palner Group integration and consultancy operation based in the Jacksonville, Florida area, agreed: "SIP is a tiny piece of the telephony puzzle. The big boys of ClueCon [an interoperator revenue-sharing consortium] want DIAMETER-based interdomain peering policy control, H.323, MGCP, and IMS. IMS is pretty much how VoIP architecture is done now. We got out of the Asterisk business just in time, right before Mitel swallowed the PBX world. I'm glad to see Evariste is finally seeing the light, and I'm sure its shareholders are too." Posner also believes Evariste's lack of support for TDM interfaces accounted for dwindling market share. "Have you seen CSRP? It's SIP in, SIP out. Real inter-LATA haulers and application service providers use TDM and leave SIP for things like voicemail. I can't plug my DS3s into a SIP proxy, so I just don't think there was any real demand for the sort of thing they were doing." Noting Oracle's US$2.5bn acquisition of Acme Packet in early February, as well as its more recently announced buyout of Tekelec, a Siris Capital Group portfolio company, Balashov remarked: "The obvious shift to an Oracle-centric telephony paradigm was a kind of validation, if you will, of our decision to unload our dead weight and sign on to the revolution in unified communications." Sean McCord, of CyCORE Systems, an Atlanta-based software consulting house and long-time Evariste creditor, agreed that there was a natural synergy between Evariste's shift to Acme Packet and Oracle's dominance of telephony infrastructure. "Oracle is a forward-thinking telecom pioneer," McCord said. "The telephone is Oracle, and Oracle is the telephone." Balashov also noted that a tightening regulatory environment and new consumer protection rules helped hasten the decision to embrace the more professionalised Acme Packet product portfolio. John Knight, Senior Engineer at Hendersonville, NC-based Ringfree Communications, one of Evariste's oldest channel partners, said: "As one of Evariste's long-time disties, we were jittery about exposure to CALEA and the QA requirements of large call centers. We tried to make do, but at some point we just had to put the relationship on stop. I'm all in favour of open, but there's just no open-source software out there that does call recording, and that's the bottom line for us. In the end, we had to restructure some debt just to get bondholders to let us source a proprietary solution on tick." In a thematically related move, Evariste will be dropping its heavy use of the open-source PostgreSQL database manager for its rating and reporting tools. "The business case for standardising on Oracle's databases could not be clearer. With Oracle Database 11g's support of warehousing and OLTP, the real mystery is why we didn't go there sooner," said Balashov. Carlos Alvarez, a director at Televolve, a growing Phoenix-area VoIP operator, recently spearheaded a move away from Evariste's PostgreSQL- based call detail record (CDR) storage solution to one running atop Microsoft SQL Server 2008. Alvarez commented: "Evariste had a nice idea, in a cute, David-and-Goliath kind of way, but we're processing over five hundred phone calls a day now. Are we really going to store those kinds of volumes in an open-source database? Might as well just put it all in flat text files at that point. Phone service is an uptime game. You can't compromise on this stuff. What if someone needs to call 911?" Asked to summarise his expectations, Balashov said: "I hope this turns us around in a big way. We were wrong to think that nobody cared about stuff like P-CSCFs, or that you could deliver even rudimentary VoIP to the premise without the expansive feature set of a comprehensive solution like the Net-Net SBC. I can only hope the market forgives us for betting on 'SIP Express Router' and its ilk back in the day, and gives us a chance to do it right in round two." Fred Posner, of Team Forrest, added: "Besides, if you look at the Git repository, Kamailio hasn't had any code contributions in at least five years. It seems everyone's figured out this pure SIP stuff is defunct and hokey."

11 years

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