sr-users

sr-users@lists.kamailio.org

42 participants
37519 discussions

OOM Errors
by Phil Lavin 20 Sep '16

20 Sep '16

Hi all, Kamailio stopped performing some functions earlier today, citing OOM errors. An excerpt from the log is below. SHM usage, at the time, looked fine. Also see below for that output. A restart of Kamailio resolved the issue. Is this SHM related or OS memory manager related? root@ua-proxy-01:~# kamctl stats shmem shmem:fragments = 910 shmem:free_size = 104131224 shmem:max_used_size = 51590800 shmem:real_used_size = 30086504 shmem:total_size = 134217728 shmem:used_size = 19558800 Sep 19 11:35:56 ua-proxy-01 /sbin/kamailio[20218]: ERROR: <core> [data_lump.c:161]: insert_new_lump_before(): out of memory Sep 19 11:40:10 ua-proxy-01 /sbin/kamailio[20218]: ERROR: <core> [msg_translator.c:2390]: build_res_buf_from_sip_req(): out of memory; needs 423 Sep 19 11:40:16 ua-proxy-01 /sbin/kamailio[20218]: ERROR: <core> [msg_translator.c:2390]: build_res_buf_from_sip_req(): out of memory; needs 453 Sep 19 11:42:46 ua-proxy-01 /sbin/kamailio[20218]: ERROR: <core> [data_lump.c:136]: insert_new_lump_after(): out of memory Sep 19 11:42:46 ua-proxy-01 /sbin/kamailio[20218]: ERROR: <core> [ut.c:163]: as_asciiz(): Out of memory Sep 19 11:42:57 ua-proxy-01 /sbin/kamailio[20218]: ERROR: <core> [ut.c:163]: as_asciiz(): Out of memory Sep 19 11:43:12 ua-proxy-01 /sbin/kamailio[20218]: ERROR: <core> [data_lump.c:361]: anchor_lump(): out of memory Sep 19 11:43:12 ua-proxy-01 /sbin/kamailio[20218]: ERROR: <core> [data_lump.c:361]: anchor_lump(): out of memory Sep 19 11:43:12 ua-proxy-01 /sbin/kamailio[20218]: ERROR: <core> [data_lump.c:306]: del_lump(): out of memory Sep 19 11:43:12 ua-proxy-01 /sbin/kamailio[20218]: ERROR: <core> [data_lump.c:306]: del_lump(): out of memory Sep 19 11:43:12 ua-proxy-01 /sbin/kamailio[20218]: ERROR: <core> [msg_translator.c:326]: received_builder(): out of memory Sep 19 11:43:12 ua-proxy-01 /sbin/kamailio[20218]: ERROR: <core> [msg_translator.c:326]: received_builder(): out of memory Sep 19 11:43:12 ua-proxy-01 /sbin/kamailio[20218]: ERROR: <core> [msg_translator.c:326]: received_builder(): out of memory Sep 19 11:43:16 ua-proxy-01 /sbin/kamailio[20218]: ERROR: <core> [data_lump.c:136]: insert_new_lump_after(): out of memory Sep 19 11:43:16 ua-proxy-01 /sbin/kamailio[20218]: ERROR: <core> [ut.c:163]: as_asciiz(): Out of memory Sep 19 11:44:18 ua-proxy-01 /sbin/kamailio[20218]: ERROR: <core> [data_lump.c:161]: insert_new_lump_before(): out of memory Sep 19 11:45:07 ua-proxy-01 /sbin/kamailio[20218]: ERROR: <core> [ut.c:163]: as_asciiz(): Out of memory Sep 19 11:45:30 ua-proxy-01 /sbin/kamailio[20218]: ERROR: acc [acc_extra.c:267]: extra2strar(): extra2strar: out of memory. Sep 19 11:45:43 ua-proxy-01 /sbin/kamailio[20218]: ERROR: <core> [data_lump.c:186]: insert_subst_lump_after(): out of memory Sep 19 11:45:52 ua-proxy-01 /sbin/kamailio[20218]: ERROR: <core> [data_lump.c:161]: insert_new_lump_before(): out of memory

2 10

Presence: Empty reginfo NOTIFY bodies
by Stefan Kohlhauser 19 Sep '16

19 Sep '16

Hey everyone! Problem: At startup the presence module for reginfos can get into a state where it is not adding bodies to reginfo NOTIFYs. Setup: We are using the pua_reginfo to let the Kamailio (4.2.6) PUBLISH the current registration state to itself. The body is correctly added to the presentity-table in the Postgres. Analysis: However, we have identified two cases where after startup the Kamailio can reach a state where he won't add bodies to the NOTIFYs. And this does not fix itself over time. We are pretty confident that the problem lies in an inconsistency between the presentity table in the DB and the hashtable of the presence module. Case 1: The entry for a URI in the DB is expired. On startup of the Kamailio the hashtable remains empty for that URI. Maybe due to another bug the pua_reginfo occasionally sends PUBLISHes with an expired "SIP-If-Match"-header. In module/presence/presentity.c::update_presentity() the DB is updated. However, the hashtable is only updated if it is a new request (i.e. no "SIP-If-Match"-header and thus new_t not set). The hash table is not filled on startup, not on the first PUBLISH as it contains a (wrong) "SIP-If-Match"-header, and not on any subsequent PUBLISH as they contain correct "SIP-If-Match"-headers. Case 2: The presentity table contains at least one expired and one non-expired reginfo entry for a URI. The Kamailio seems to send a NOTIFY with a body within about a minute (probably the default clean period of 100 secs?). But after that short interval only NOTIFYs with empty bodies are sent. To us it looks like the cleanup function (module/presence/publish.c::msg_presentity_clean()) is cleaning up the expired DB entries correctly. But despite one still valid entry in the DB the entry in the hash table gets removed as well. And it wont get filled again (see case 1). This only seems to apply to the "reg" event, the "presence" event does not seem to be affected. We are aware aware of the publ_cach parameter, but we don't know if this has any performance impact on our system. If needed we can try to provide more insight on this problem. Some help on this or a fix would be much appreciated! BR, Stefan

1 0

Kamailio P-CSCF error on INVITE
by Owais 19 Sep '16

19 Sep '16

Hi guys, Kamailio P-CSCF is unable to return true for: pcscf_is_registered("location") on INVITE and responds to the INVITE with: 403 Forbidden - You must register first with a S-CSCF Registration completes fine and I can see database with valid location entries though... Any ideas? Regards, Owais -- View this message in context: http://sip-router.1086192.n5.nabble.com/Kamailio-P-CSCF-error-on-INVITE-tp1… Sent from the Users mailing list archive at Nabble.com.

2 3

how to access reply headers
by mjbemail2000-seti＠yahoo.co.uk 19 Sep '16

19 Sep '16

Hi, I have a registered handset which replies to an INVITE message from Kamailio with a "302 Moved Temporarily" message. The reason for this is because the user has set their handset to forward the call to another telephone number. In a wireshark trace I can see the forwarded telephone number in the Contact header of the SIP message but I can't find a way to access this header via any variables. In the config file I have tried this: # Manage incoming repliesonreply_route[MANAGE_REPLY] { ... if(t_check_status("3[0-9][0-9]")) { xlog("L_INFO", "test1: $hdr(Contact)"); xlog("L_INFO", "test2: $ct"); } ... } , but in both cases the value returned is the Contact header of the original INVITE message and not the Contact shown in the "302 Moved Temporarily" reply message. How do I access the Contact header in the reply message? Regards, Mark.

2 1

Debian 4.4.3 reproducable crashes in rtpengine.so
by Daniel Tryba 19 Sep '16

19 Sep '16

With kamctl fifo nh_enable_rtpp udp:rptipaddr:7723 1 kamailio will begin to crash: Sep 19 16:00:08 sipcluster-backend2 kernel: [1658593.859081] kamailio[22992]: segfault at 4 ip 00007f5a4d44e11f sp 0000 7ffcac5293e0 error 4 in rtpengine.so[7f5a4d446000+41000] Sep 19 16:00:12 sipcluster-backend2 /usr/sbin/kamailio[22999]: CRITICAL: <core> [pass_fd.c:275]: receive_fd(): EOF on 2 8 Sep 19 16:00:12 sipcluster-backend2 /usr/sbin/kamailio[22976]: ALERT: <core> [main.c:740]: handle_sigs(): child process 22992 exited by a signal 11 Sep 19 16:00:12 sipcluster-backend2 /usr/sbin/kamailio[22976]: ALERT: <core> [main.c:743]: handle_sigs(): core was gene rated Sep 19 16:00:12 sipcluster-backend2 /usr/sbin/kamailio[22976]: INFO: <core> [main.c:755]: handle_sigs(): terminating du e to SIGCHLD Sep 19 16:00:12 sipcluster-backend2 /usr/sbin/kamailio[22978]: INFO: <core> [main.c:810]: sig_usr(): signal 15 received .... Backtrace, Program terminated with signal SIGSEGV, Segmentation fault. #0 send_rtpp_command (node=node@entry=0x7f5a522b2140, dict=dict@entry=0x7f5a644b97c8, outlen=outlen@entry=0x7ffcac5294ec) at rtpengine.c:2619 2619 rtpengine.c: No such file or directory. (gdb) thread apply all bt full Thread 1 (Thread 0x7f5a66a49700 (LWP 22992)): #0 send_rtpp_command (node=node@entry=0x7f5a522b2140, dict=dict@entry=0x7f5a644b97c8, outlen=outlen@entry=0x7ffcac5294ec) at rtpengine.c:2619 addr = {sun_family = 12616, sun_path = "A\000\000\000\000\000t\326_", '\000' <repeats 13 times>, "\240ZGMZ\177\000\000`_GMZ\177\000\000\360\224R\254\374\177\000\000\a\000\000\000\000\000\000\000\374\257DMZ\177\000\000(\230KdZ\177\000\000\214\260DMZ\177\000\000\004\000\000\000\000\000\000\000\374\257DM\001\000\000\000\360\224R\254\374\177\000\000(\230KdZ\177"} fd = <optimized out> len = 0 i = <optimized out> vcnt = 6 cp = 0x7f5a4d687dc0 <buf> "" buf = '\000' <repeats 65535 times> fds = {{fd = 223, events = 0, revents = 0}} v = 0x7f5a644b98f6 out = {s = 0x0, len = 0} __FUNCTION__ = "send_rtpp_command" #1 0x00007f5a4d44f81c in rtpp_test_ping (node=0x7f5a522b2140) at rtpengine.c:1041 bencbuf = {pieces = 0x7f5a644b97b0, free_list = 0x0, error = 0} dict = 0x7f5a644b97c8 cp = <optimized out> ret = 0 #2 0x00007f5a4d454d89 in mi_enable_rtp_proxy (cmd_tree=0x1, param=0x1) at rtpengine.c:1137 crt_node = 0x0 rtpp_list = 0x7f5a522b1f80 root = 0x16 attr = 0x0 found = 0 __FUNCTION__ = "mi_enable_rtp_proxy" #3 0x00007f5a515f071e in run_mi_cmd (cmd=<optimized out>, cmd=<optimized out>, t=<optimized out>) at ../../lib/kmi/mi.h:77 No locals. #4 mi_fifo_server (fifo_stream=0x27be8a0) at fifo_fnc.c:509 line_len = 39 file_sep = 0x0 command = 0x7f5a644a2b41 "nh_enable_rtpp" f = 0x276f838 reply_stream = 0x27c4cf0 __FUNCTION__ = "mi_fifo_server" #5 0x00007f5a515e6345 in fifo_process (rank=1) at mi_fifo.c:270 fifo_stream = 0x27be8a0 __FUNCTION__ = "fifo_process" #6 0x00007f5a515e8f1e in mi_child_init (rank=0) at mi_fifo.c:234 pid = 0 #7 0x0000000000512ba9 in init_mod_child (m=0x1, rank=1) at sr_module.c:921 __FUNCTION__ = "init_mod_child" #8 0x0000000000512ad8 in init_mod_child (m=0x1, rank=1) at sr_module.c:918 __FUNCTION__ = "init_mod_child" #9 0x0000000000512ad8 in init_mod_child (m=0x1, rank=1) at sr_module.c:918 __FUNCTION__ = "init_mod_child" #10 0x0000000000512ad8 in init_mod_child (m=0x1, rank=1) at sr_module.c:918 __FUNCTION__ = "init_mod_child" #11 0x0000000000512ad8 in init_mod_child (m=0x1, rank=1) at sr_module.c:918 __FUNCTION__ = "init_mod_child" #12 0x0000000000512ad8 in init_mod_child (m=0x1, rank=1) at sr_module.c:918 __FUNCTION__ = "init_mod_child" #13 0x0000000000512ad8 in init_mod_child (m=0x1, rank=1) at sr_module.c:918 __FUNCTION__ = "init_mod_child" #14 0x0000000000512ad8 in init_mod_child (m=0x1, rank=1) at sr_module.c:918 __FUNCTION__ = "init_mod_child" #15 0x0000000000512ad8 in init_mod_child (m=0x1, rank=1) at sr_module.c:918 __FUNCTION__ = "init_mod_child" #16 0x0000000000512ad8 in init_mod_child (m=0x1, rank=1) at sr_module.c:918 __FUNCTION__ = "init_mod_child" #17 0x0000000000512ad8 in init_mod_child (m=0x1, rank=1) at sr_module.c:918 __FUNCTION__ = "init_mod_child" #18 0x0000000000512ad8 in init_mod_child (m=0x1, rank=1) at sr_module.c:918 __FUNCTION__ = "init_mod_child" #19 0x0000000000512ad8 in init_mod_child (m=0x1, rank=1) at sr_module.c:918 __FUNCTION__ = "init_mod_child" #20 0x0000000000512ad8 in init_mod_child (m=0x1, rank=1) at sr_module.c:918 __FUNCTION__ = "init_mod_child" #21 0x0000000000512ad8 in init_mod_child (m=0x1, rank=1) at sr_module.c:918 __FUNCTION__ = "init_mod_child" #22 0x0000000000512ad8 in init_mod_child (m=0x1, rank=1) at sr_module.c:918 __FUNCTION__ = "init_mod_child" #23 0x0000000000512ad8 in init_mod_child (m=0x1, rank=1) at sr_module.c:918 __FUNCTION__ = "init_mod_child" #24 0x0000000000512ad8 in init_mod_child (m=0x1, rank=1) at sr_module.c:918 __FUNCTION__ = "init_mod_child" #25 0x0000000000512ad8 in init_mod_child (m=0x1, rank=1) at sr_module.c:918 __FUNCTION__ = "init_mod_child" #26 0x0000000000512ad8 in init_mod_child (m=0x1, rank=1) at sr_module.c:918 __FUNCTION__ = "init_mod_child" #27 0x0000000000512ad8 in init_mod_child (m=0x1, rank=1) at sr_module.c:918 __FUNCTION__ = "init_mod_child" #28 0x0000000000512ad8 in init_mod_child (m=0x1, rank=1) at sr_module.c:918 __FUNCTION__ = "init_mod_child" #29 0x0000000000512ad8 in init_mod_child (m=0x1, rank=1) at sr_module.c:918 __FUNCTION__ = "init_mod_child" #30 0x0000000000512ad8 in init_mod_child (m=0x1, rank=1) at sr_module.c:918 __FUNCTION__ = "init_mod_child" #31 0x0000000000512ad8 in init_mod_child (m=0x1, rank=1) at sr_module.c:918 __FUNCTION__ = "init_mod_child" #32 0x0000000000512ad8 in init_mod_child (m=0x1, rank=1) at sr_module.c:918 __FUNCTION__ = "init_mod_child" #33 0x0000000000512ad8 in init_mod_child (m=0x1, rank=1) at sr_module.c:918 __FUNCTION__ = "init_mod_child" #34 0x0000000000512ad8 in init_mod_child (m=0x1, rank=1) at sr_module.c:918 __FUNCTION__ = "init_mod_child" #35 0x0000000000512ad8 in init_mod_child (m=0x1, rank=1) at sr_module.c:918 __FUNCTION__ = "init_mod_child" #36 0x0000000000512ad8 in init_mod_child (m=0x1, rank=1) at sr_module.c:918 __FUNCTION__ = "init_mod_child" #37 0x0000000000512ad8 in init_mod_child (m=0x1, rank=1) at sr_module.c:918 __FUNCTION__ = "init_mod_child" #38 0x0000000000512ad8 in init_mod_child (m=0x1, rank=1) at sr_module.c:918 __FUNCTION__ = "init_mod_child" #39 0x0000000000512ad8 in init_mod_child (m=0x1, rank=1) at sr_module.c:918 __FUNCTION__ = "init_mod_child" #40 0x0000000000512ad8 in init_mod_child (m=0x1, rank=1) at sr_module.c:918 __FUNCTION__ = "init_mod_child" #41 0x0000000000512ad8 in init_mod_child (m=0x1, rank=1) at sr_module.c:918 __FUNCTION__ = "init_mod_child" #42 0x0000000000512ad8 in init_mod_child (m=0x1, rank=1) at sr_module.c:918 __FUNCTION__ = "init_mod_child" #43 0x0000000000512ad8 in init_mod_child (m=0x1, rank=1) at sr_module.c:918 __FUNCTION__ = "init_mod_child" #44 0x0000000000512ad8 in init_mod_child (m=0x1, rank=1) at sr_module.c:918 __FUNCTION__ = "init_mod_child" #45 0x0000000000510f18 in main_loop () at main.c:1696 si_desc = "udp receiver child=0 sock=127.0.0.1:5060\000\060\066\060\000\000\000\000\270\357DdZ\177\000\000\017\000\000\000\000\000\000\000n\000\000\000\000\000\000\000\255\370_\000\000\000\000\000\071\222\343p\000\000\000\000\000\071X\207\335c\334e\000\000\000\000\000\000\000\000\000\071X\207\335c\334e\210\263\246\000\000\000\000\000\005\000\000\000\000\000\000" woneinit = 1 __FUNCTION__ = "main_loop" #46 0x000000000041cefc in main (argc=3, argv=0x0) at main.c:2631 cfg_stream = 0x0 r = 0 tmp = 0x7ffcac52bee5 "" tmp_len = 0 port = 0 proto = 1722066384 ret = 0 seed = 2123298762 debug_save = 0 debug_flag = 8 dont_fork_cnt = 0 st = {st_dev = 15, st_ino = 12771, st_nlink = 2, st_mode = 16832, st_uid = 112, st_gid = 118, __pad0 = 0, st_rdev = 0, st_size = 100, st_blksize = 4096, st_blocks = 0, st_atim = {tv_sec = 1472635951, tv_nsec = 983999907}, st_mtim = {tv_sec = 1474293427, tv_nsec = 27546593}, st_ctim = {tv_sec = 1474293427, tv_nsec = 27546593}, __glibc_reserved = {0, 0, 0}} __FUNCTION__ = "main" (gdb)

1 0

yum install modules
by mjbemail2000-seti＠yahoo.co.uk 19 Sep '16

19 Sep '16

Hi, I've installed Kamailio on CentOS using yum but it's not installed the geoip2 module, amongst others. I'm I correct in saying that to install this module I'd need to install Kamailio from the source code? Regards, Mark.

1 0

tls with ubuntu 16.04
by Jayesh Nambiar 19 Sep '16

19 Sep '16

Hi, Trying kamailio with Ubuntu 16.04 and I'm getting errors as follows: ERROR: tls [tls_init.c:490]: tls_pre_init(): Unable to set the memory allocation functions The error is identical to the one mentioned here: https://bugs.launchpad.net/ubuntu/+source/kamailio/+bug/1591992 Is there a solution to this. Thanks for any response. - Jayesh

2 21

Extract param from RPID header
by Grant Bagdasarian 19 Sep '16

19 Sep '16

Hello, I'm trying to extract the privacy param from the RPID header, but without success. Could someone point me in the right direction? Remote-Party-ID: "Cullen Jennings" <sip:+3123456789@1.1.1.1>;party=calling;privacy=off;screen=no. I've tried the following ways: 1) TEXTOPSX: $var(rpid_privacy_value) = @hf_value.remote_party_id.privacy; 2) Param Transformations: a. $(hdr(Remote-Party-ID){param.value,privacy}) b. $(re{param.value,privacy}) c. 4re{param.value,privacy} I can't seem to extract the value of privacy from the RPID header. Regards, Grant

2 2

Self challenged packets
by Torsten Hantzsche 19 Sep '16

19 Sep '16

Hi, while playing with the script from http://kb.asipto.com/kamailio:presence:k43-blf and "kamailio 4.4.3 (x86_64/freebsd) 5a2195" I could not see any NOTIFY packet going out to the subscribed watcher. "tcpdump -i lo0" shows self injected PUBLISH packets challenged with "407 Proxy Authentication Required" and there they got stuck. The PUBLISH packets are sent on lo0 from my network address to the same network address (here 10.0.0.106 to 10.0.0.106). The proxy challenge is also sent from 10.0.0.106 to 10.0.0.106. An xlog entry with the variable "$Ri" in route REQUEST shows 10.0.0.106 too. Since these packets are only seen on lo0, should "$Ri" not show 127.0.0.1? After disabling the WITH_AUTH variable, the watcher is getting its NOTIFY's. Now I wonder under which circumstances this script is supposed to function correctly without changes in the AUTH route? By the way, I had the same problem with the provided script of the msilo module (http://kamailio.org/docs/modules/4.4.x/modules/msilo.html#idp42867388) which too only works if there is no "auth_challenge" in the way. Could somebody with more insight in Kamailio internals give some hints on this, please? How can it get solved in an elegant way? Thanks, Torsten

3 3

Re: [SR-Users] help with kamailio rpm made from source
by Dmitry 18 Sep '16

18 Sep '16

Hello I tested a package http://download.opensuse.org/repositories/home:/kamailio:/v4.3.x-rpms/CentO… ( I downlowaded 4.3.6 version rpm and installed it. Kamailio restarts well. The behaviour is the same. the phone registeres without nonce. I install kamailio, kamailio-kazoo - 2 rpm зфслфпуы On Thursday, September 15, 2016 9:34 PM, Dmitry <mbike2000ru(a)yahoo.com> wrote: I made loadmodule and modparam("debugger", "cfgtrace", 1) but anyway - no logs when I register. As I understand - it's like no config file. On Thursday, September 15, 2016 6:01 PM, Daniel-Constantin Mierla <miconda(a)gmail.com> wrote: I am not familiar with kazoo configs, maybe asking on their mailing list can help you more. From Kamailio point of view, you can load debugger module and set its cfgtrace parameter to 1, then see what actions from config are executed and why is not getting to the authentication part. Cheers, Daniel On 15/09/16 14:09, Dmitry wrote: /etc/kazoo/kamailio/default.cfg - which containes all routes. 2600hz/kazoo-configs | | | | | | | | | | | 2600hz/kazoo-configs kazoo-configs - Kazoo Configuration Files for Software We Use | | | | I test on a working server (testing one) and a working config -- Daniel-Constantin Mierla http://www.asipto.com - http://www.kamailio.org http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda On Thursday, September 15, 2016 3:56 PM, Daniel-Constantin Mierla <miconda(a)gmail.com> wrote: Are you using default kamailio.cfg or another one? Cheers, Daniel On 15/09/16 12:39, Dmitry wrote: Hello I took this spec from suse. It generates no errors. When I installed from the RPM I had made - the phone register, but The phone sends a REGISTER and the KAmailio sends 200ok back to the phone (so no NONCE authorization) and no logs during it. In default.cfg I set L_DBG but no logs are generated during registering a phone. And I see no AMQP messages (I set to 1 Kazoo_enable in the SPEC file). Why there are no logs during register (I saw register in tcpdump)? On Wednesday, September 14, 2016 7:42 PM, Daniel-Constantin Mierla <miconda(a)gmail.com> wrote: Then you just need add those files in various packages inside the spec file, so they are not detected to be orphaned. Maybe you can inspire from: - https://build.opensuse.org/package/view_file/home:kamailio:v4.3.x-rpms/kama… Cheers, Daniel On 14/09/16 16:35, Dmitry wrote: 4.3.4 version is for Kazoo It is on production server currently. I need to rebuild the current RPM so as to apply patches. But first I want to get a working Kamailio and only after it I will apply the patches. I think I may take a list of modules from the production Kazoo-kamailio and rearchive the tar.gz because now the Fedora 18 rpmbuild gives a lot of files: RPM build errors: Installed (but unpackaged) file(s) found: /usr/lib64/kamailio/modules/auth_xkeys.so /usr/lib64/kamailio/modules/dmq_usrloc.so /usr/lib64/kamailio/modules/ims_charging.so /usr/lib64/kamailio/modules/jsonrpc-s.so /usr/lib64/kamailio/modules/mohqueue.so /usr/lib64/kamailio/modules/nosip.so /usr/lib64/kamailio/modules/rtjson.so /usr/lib64/kamailio/modules/rtpengine.so /usr/lib64/kamailio/modules/statsd.so /usr/lib64/kamailio/modules/tcpops.so /usr/lib64/kamailio/modules/tsilo.so /usr/share/doc/kamailio/modules/README.auth_xkeys /usr/share/doc/kamailio/modules/README.dmq_usrloc /usr/share/doc/kamailio/modules/README.ims_charging /usr/share/doc/kamailio/modules/README.ims_registrar_scscf /usr/share/doc/kamailio/modules/README.jsonrpc-s /usr/share/doc/kamailio/modules/README.mohqueue /usr/share/doc/kamailio/modules/README.nosip /usr/share/doc/kamailio/modules/README.rtjson /usr/share/doc/kamailio/modules/README.rtpengine /usr/share/doc/kamailio/modules/README.statsd /usr/share/doc/kamailio/modules/README.tcpops /usr/share/doc/kamailio/modules/README.tsilo /usr/share/snmp/mibs/KAMAILIO-MIB /usr/share/snmp/mibs/KAMAILIO-REG-MIB /usr/share/snmp/mibs/KAMAILIO-SIP-COMMON-MIB /usr/share/snmp/mibs/KAMAILIO-SIP-SERVER-MIB /usr/share/snmp/mibs/KAMAILIO-TC On Wednesday, September 14, 2016 5:05 PM, Daniel-Constantin Mierla <miconda(a)gmail.com> wrote: Hello, any reason not to use series 4.4.x? Iirc, the latest spec that got update on 4.4 are those for oracle enterprise linux, perhaps is something that you can reuse a lot for upgrading to the centos flavour. On the other hand, you can use opensuse build service if you want to build yourself, the spec from the kamailio project there is up to date and the ones for 4.3 should still be there. Anyhow, as I said, I would recommend to go with 4.4.x version. Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com - http://www.kamailio.org http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

1 1

Jump to page:

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