sr-users December 2019

sr-users@lists.kamailio.org

63 participants
78 discussions

by Arik Halperin

Hello, How can I disable: TLS_RSA_WITH_RC4_128_SHA (0x5) INSECURE128 TLS_RSA_WITH_RC4_128_MD5 (0x4) INSECURE128 What should I put in cypher_list in order to disable the above? I would also like support TLS 1.2 and TLS 1.3, but remove support for 1.0 and 1.1 Thanks, Arik Halperin

4 years, 11 months

Need support

by Srikanth Magloori

Hi Team, We are using your product Kamalio in Call Recording services. We are planning for Performance testing of our recording system. Currently we have bypassed Twilio and Kamailio. Generating Calls using SIPP directly to VOIP. So, we want calls to route through KAMAILIO -> VOIP. So performance can be bit realistic. Any help is greatly appreciated! Thanks Srikanth

4 years, 11 months

Questions about Presence

by Володимир Іванець

Hello! I'm testing Kamailio as a presence server with configuration suggested by https://kb.asipto.com/kamailio:presence:k43-blf tutorial. When I set presence module subs_db_mode setting to 0 or 2 (did not test with 1 and 3 seemed to have no problems) I was getting "DEBUG: presence [notify.c:1234]: publ_notify(): Could not find subs_dialog" message after Kamailio received some PUBLISH requests. And NOTIFY is not being generated. It appears to be a mistake. There should be an active watcher according to Expires header values of the previous SUBSCRIBE request and the response to it. I could not find how to get the list of active watchers from Kamailio memory. *Is it possible or it can be done only by adding extra debug line in get_subs_dialog function?* Also I found that after setting pua module db_mode setting to 0, Kamailio is still writing records to presentity table. And it is constantly queried "select `username`,`domain`,`etag`,`event` from `presentity` where `expires`<1576584910 AND `expires`>0 order by username" during the run time. *Is it correct behavior?* Thank a lot!

4 years, 11 months

Kamailio Product Support

by Simal Mathai

Hi Team, We are deploying Kamailio 5.3.1 on CentOS 7 for testing with a known carrier in Europe. We would like to get support for the product installation. Regards, Simal Mathai O: +1 214 242 5975 [cid:image001.png@01D13657.67E2B360]<http://www.tekvizion.com/> Please follow us on LinkedIn and Twitter [cid:image002.png@01D13657.67E2B360]<https://www.linkedin.com/company/tekvizion?trk=top_nav_home>[cid:image003.png@01D13657.67E2B360]<https://twitter.com/tekvizion>

4 years, 11 months

how to detect "failure to add branches"?

by Juha Heinanen

In route block I call t_on_failure, t_on_branch_failure, and t_on_branch. If branch route fails like this: Dec 15 08:52:19 box /usr/bin/sip-proxy[84346]: ERROR: tm [ut.h:284]: uri2dst2(): failed to resolve "foo.tutpro.com" :unresolvable A or AAAA request (-7) Dec 15 08:52:19 box /usr/bin/sip-proxy[84346]: ERROR: tm [t_fwd.c:1738]: t_forward_nonack(): failure to add branches failure_route or tm:branch-failure event_route is not executed. Is there a way to catch such a failure? -- Juha

4 years, 11 months

TLS testing (with sipp)

by Sebastian Damm

Hi, I'm trying to construct an end-to-end encrypted signalling test through our setup. I thought I could use sipp for that, as it supports TLS according to the man page. However, when I try to run it, I get this error: FI_init_ssl_context: SSL_CTX_use_certificate_file failed. I searched the web; however, all similar questions end up without answers. I tried specifying a local key and cert without success. I'd think I should not need a cert for my client, though. Has anyone ever successfully conducted an automated TLS test? I'm open to using a different tool if necessary. Thanks for all hints or examples. Regards, Sebastian -- Sebastian Damm Voice Engineer __________________________________________ sipgate GmbH Gladbacher Straße 74 | 40219 Düsseldorf

4 years, 11 months

Kamailio SIP TLS Troubleshooting

by Sudhakar Parasher

Hi Experts. Need your opinion on below part related to kamailio I am using SIP Kamailio module Version for the SIP Registrations from the Client mobile phones using Android and IOS which is Over TLSv1.2 , So in nutshell the SIP Signaling is TLS version 1.2 encrypted and Customer is requesting for the forward of the unencrypted SIP signaling messages especially the SIP Registration messages to their probe solutions without storing the SIP messages locally in the Kamailio Database Question :Would it not be possible for Kamailio imply “mirror” all the SIP messages related to all SIP REGISTER dialogs (after removing TLS for inbound messages and prior to adding TLS for outbound message) to a designated IP Address and Port? No need for local database storage. No need for encapsulation. No mirroring of other messages/dialogs. Cheers Sudhakar

4 years, 11 months

[dispatcher] freeing already freed pointer, called from core: core/xavp.c: xavp_free

by Denys Pozniak

Hello! The configuration below leads to a CRITICAL message in the console. Please let me know how to avoid this issue. event_route[htable:mod-init] { route(AUTORUN); ... } route[AUTORUN] { if ( ds_select("9", "4") ) { xlog("L_WARN", "[$cfg(route)] *ds_select* $xavp(_dsdst_[0]=>uri) $xavp(_dsdst_[1]=>uri) $xavp(_dsdst_[2]=>uri)\n"); } ... } dispatcher.list # group 9 9 sip:192.168.20.125:5070 9 sip:192.168.20.160:5070 9 sip:192.168.20.7:5070 9 sip:192.168.20.107:5070 9 sip:192.168.20.190:5070 0(6088) DEBUG: dispatcher [dispatch.c:2054]: ds_manage_routes(): set [9] 0(6088) DEBUG: dispatcher [dispatch.c:2158]: ds_manage_routes(): using alg [4] hash [0] 0(6088) DEBUG: dispatcher [dispatch.c:2199]: ds_manage_routes(): selected [4-9-2/0] <sip:192.168.20.190:5070> 0(6088) DEBUG: dispatcher [dispatch.c:2218]: ds_manage_routes(): using first entry [9/0] 0(6088) DEBUG: dispatcher [dispatch.c:2238]: ds_manage_routes(): using entry [9/1] 0(6088) DEBUG: dispatcher [dispatch.c:2238]: ds_manage_routes(): using entry [9/2] 0(6088) DEBUG: dispatcher [dispatch.c:2238]: ds_manage_routes(): using entry [9/3] 0(6088) DEBUG: dispatcher [dispatch.c:2272]: ds_manage_routes(): using default entry [9/4] 0(6088) DEBUG: dispatcher [dispatch.c:2016]: ds_select_dst_limit(): selected target destinations: 5 0(6088) WARNING: <script>: [AUTORUN] *ds_select* sip:192.168.20.190:5070 sip:192.168.20.107:5070 sip:192.168.20.7:5070 1(6089) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list 0x7fe5f7d4f420 1(6089) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(6089) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(6089) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(6089) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(6089) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(6089) DEBUG: <core> [core/xavp.c:495]: xavp_destroy_list(): destroying xavp list 0x7fe5f7d4faf0 1(6089) DEBUG: <core> [core/xavp.c:495]: xavp_destroy_list(): destroying xavp list (nil) 1(6089) CRITICAL: <core> [core/mem/q_malloc.c:514]: qm_free(): BUG: freeing already freed pointer (0x7fe5f7d4faf0), called from core: core/xavp.c: xavp_free(65), first free core: core/xavp.c: xavp_free(65) - ignoring 1(6089) DEBUG: <core> [core/xavp.c:495]: xavp_destroy_list(): destroying xavp list (nil) 1(6089) CRITICAL: <core> [core/mem/q_malloc.c:514]: qm_free(): BUG: freeing already freed pointer (0x7fe5f7d4f168), called from core: core/xavp.c: xavp_free(65), first free core: core/xavp.c: xavp_free(65) - ignoring 1(6089) DEBUG: <core> [core/xavp.c:495]: xavp_destroy_list(): destroying xavp list (nil) 1(6089) CRITICAL: <core> [core/mem/q_malloc.c:514]: qm_free(): BUG: freeing already freed pointer (0x7fe5f7d4f378), called from core: core/xavp.c: xavp_free(65), first free core: core/xavp.c: xavp_free(65) - ignoring 1(6089) DEBUG: <core> [core/xavp.c:495]: xavp_destroy_list(): destroying xavp list (nil) 1(6089) CRITICAL: <core> [core/mem/q_malloc.c:514]: qm_free(): BUG: freeing already freed pointer (0x7fe5f7d4f580), called from core: core/xavp.c: xavp_free(65), first free core: core/xavp.c: xavp_free(65) - ignoring 1(6089) DEBUG: <core> [core/xavp.c:495]: xavp_destroy_list(): destroying xavp list (nil) 1(6089) CRITICAL: <core> [core/mem/q_malloc.c:514]: qm_free(): BUG: freeing already freed pointer (0x7fe5f7d4f790), called from core: core/xavp.c: xavp_free(65), first free core: core/xavp.c: xavp_free(65) - ignoring 1(6089) DEBUG: <core> [core/xavp.c:495]: xavp_destroy_list(): destroying xavp list (nil) 1(6089) CRITICAL: <core> [core/mem/q_malloc.c:514]: qm_free(): BUG: freeing already freed pointer (0x7fe5f7d4f9a0), called from core: core/xavp.c: xavp_free(65), first free core: core/xavp.c: xavp_free(65) - ignoring 1(6089) DEBUG: <core> [core/receive.c:457]: receive_msg(): cleaning up ... version: kamailio 5.2.2 (x86_64/linux) flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, 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_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: unknown compiled on 19:29:40 Jun 20 2019 with gcc 4.8.5 -- BR, Denys Pozniak

4 years, 11 months

kamailio 5.2.5 wrong send socket on a mhomed proxy.

by Vitalii Aleksandrov

Hi, kamailio 5.2 branch has a commit 09ac3e47ef79dbd599b7dec5b84ae3b792f025ed cherry picked from master branch. It makes sense for master because get_send_socket2() behavior has changed and function became started and also there were some patches to propagate connection it to uac structure. 5.2 kamailio takes the first interface for TCP/TLS/WS connections and then finds existing tcp connection matched by ip:port, but when the patch is applied connection lookup fails and kamailio can't forward in-dialog messages.

4 years, 11 months

How to reduce re-INVITE time in Kamailio

by Anuran Barman

Hi, I am using Kamailio for my SIP Phone app. My main SIP client is the iOS app. Till now everything is working fine regarding the calling. But the problem is when the app is killed I am not able to pick up incoming call. The thing is, when app is killed I am sending PushKit VOIP message to my ios app to wake it up. App is waking up. But by the time app is waking up, the original INVITE message got missed up. So according to SIP protocol it will re-INVITE after some time. Currently if I keep my app open for 10-15 secs after it wakes up, I am able to get the re-INVITE and everything works fine just as it was supposed to. But waiting 10-15 sec on the app is not practical in any sense. So my question is there any way I can reduce the re-INVITE time to like 5/6 seconds so that as soon as the app open it will wait for 5/6 seconds (practical upto some extent) and it will get the call ? Or what kamailio is using as the interval time is a SIP standard and can not be changed? If possible to do so, how can I do that? Please help.

4 years, 11 months

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 December 2019