sr-users March 2024

sr-users@lists.kamailio.org

44 participants
45 discussions

by tom＠tomlynn.com

When I look at the debian repositories maintained by the project, there are instructions to import the public key of the repository for apt using this command: wget -O http://deb.kamailio.org/kamailiodebkey.gpg | sudo apt-key add - which results in: Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)). gpg: no valid OpenPGP data found. Is there an alternate method that can be posted in the repository that will get better results? Thank you, TL

2 months, 2 weeks

Getting the name of an already set onreply_route

by Denys Pozniak

Hello! Is it possible to find out the name of the onreply_route that was set before? Something like this: t_on_reply("MANAGE_REPLY"); ... if ( t_is_set("onreply_route") ) { get_onreply_route_name(); ... } -- BR, Denys Pozniak

3 months, 2 weeks

http_async_query on carrierfailureroute changes rd back to carrieroute primary

by Maharaja Azhagiah

Hi I am running kamailio 5.4 on debian I have carrierfailureroute configured incase of primary service provider fails. I also have Stirshaken configured to add Identity header on outbound calls. Issue is when call fail overs to carrierfailureroute, http_async_query changes $ru to the primary carrier From the debug logs, when primary carrier sends a 488 (primary carrier expects SIP TLS but my call is UDP - to test the failover scenario) 39(285) DEBUG: {1 18398 INVITE 8EmmsLqNuMRYBduMqFgX3w4JHAn4C2xn} tmx [t_var.c:561]: pv_get_tm_reply_code(): reply code is <488> 39(285) DEBUG: {1 18398 INVITE 8EmmsLqNuMRYBduMqFgX3w4JHAn4C2xn} carrierroute [cr_func.c:178]: set_next_domain_on_rule(): searching for matching routing rules39(285) INFO: {1 18398 INVITE 8EmmsLqNuMRYBduMqFgX3w4JHAn4C2xn} carrierroute [cr_func.c:197]: set_next_domain_on_rule(): next_domain is 47987 Carrier route rewrites the failover carrier 39(285) INFO: {1 18398 INVITE 8EmmsLqNuMRYBduMqFgX3w4JHAn4C2xn} carrierroute [cr_func.c:706]: cr_do_route(): uri 14371234567 was rewritten to sip:14371234567@sip.primaryprovider.com, carrier 1, domain 47987 Before http_async_query rd and ru are still the failover carrier 39(285) INFO: {1 18398 INVITE 8EmmsLqNuMRYBduMqFgX3w4JHAn4C2xn} <script>: [callid: 8EmmsLqNuMRYBduMqFgX3w4JHAn4C2xn] - [cfg:2976] - Debug testing ----- rd is sip.primaryprovider.com ----- ru is sip:14371234567@sip.primaryprovider.com 39(285) DEBUG: {1 18398 INVITE 8EmmsLqNuMRYBduMqFgX3w4JHAn4C2xn} http_async_client [async_http.c:469]: async_send_query(): transaction suspended [5261:1830449764] 39(285) DEBUG: {1 18398 INVITE 8EmmsLqNuMRYBduMqFgX3w4JHAn4C2xn} http_async_client [async_http.c:625]: async_push_query(): query sent [ https://authn-uat.ccid.neustar.biz/ccid/authn/v2/identity?apiKey=randomkey] (0x7fdcad097e60) to worker 1 However, when the route is being called after the http_async_query it changes to the primary one: 26(272) DEBUG: tm [t_lookup.c:1612]: t_lookup_ident_filter(): transaction found 26(272) DEBUG: http_async_client [async_http.c:235]: async_http_cb(): resuming transaction (5261:1830449764) 26(272) DEBUG: tm [t_lookup.c:1612]: t_lookup_ident_filter(): transaction found 26(272) INFO: <script>: [callid: 8EmmsLqNuMRYBduMqFgX3w4JHAn4C2xn] - [cfg:2995] - Debug testing ----- rd is 1.2.3.4 ----- ru is sip:14371234567@1.2.3.4:5061;transport=TLS Due to this, call keeps going to the primary and it fails if ( http_async_query(STIRSHAKEN_AS_URL, "AS_RESPONSE") == -1 ) { xlog("L_ERR ", "[cfg:$cfg(line)] Failed to connect AS service for token $fu -> $tu \n"); return; } route[AS_RESPONSE] { xlog("L_INFO", "[callid: $ci] - [cfg:$cfg(line)] - Debug testing ----- rd is $rd ----- ru is $ru\n"); if ($http_ok) { xlog("L_INFO", "[cfg:$cfg(line)] Resuming outbound call transaction for $fu -> $tu Received - $http_rb \n"); # Add identity and Date headers if (jansson_get("identity", $http_rb, "$var(identity)")) { insert_hf("Identity: $var(identity)\n", "Content-Length"); } if (jansson_get("date", $http_rb, "$var(date)")) { if ($hdr(Date) != $null){ remove_hf("Date"); } insert_hf("Date: $var(date)\n", "Identity"); } } else { xlog("L_ERR", "[cfg:$cfg(line)] Resuming outbound call transaction. Error - $http_err)\n"); } route(RELAY); exit; } Please help to understand why rd / ru changes to primary carrier. Regards, Maharaja Azhagiah

5 months, 3 weeks

Via header force change protocol to TLS?

by Anthony Alba

I have kamailio behind a TLS termination proxy so the sockets are correctly deduced to be TCP. However the clients only talk TLS to the proxy and are confused when the top Via header added by Kamailio is TCP. Is there a way for Kamailio to forcibly pretend its protocol is TLS? Like advertised_address but "advertised_protocol" instead. (With pjsip testing: it has a flag use_tls which ignores TCP from Kamailio and continues to use the persistent TLS transport to proxy. Linphone fails because it tries to honor TCP in Via and is unable to establish TCP transport). BTW I am using t_relay_to_tcp so Kamailio will return traffic to the proxy as TCP even though the contact addresses specify transport=TLS.

8 months

q_malloc.c:520 WARNINGs

by Joel Serrano

Hi, Does anyone know what this WARNING means or how to fix it? 2024-03-09T00:39:15.406674-05:00 csbc03 csbc[33024]: WARNING: {1 1 INVITE CALL-ID} <core> [core/mem/q_malloc.c:520]: qm_free(): WARNING: free(0) called from dialplan: dp_db.c: pcre2_free(206) 2024-03-09T00:39:15.406823-05:00 csbc03 csbc[33024]: WARNING: {1 1 INVITE CALL-ID} <core> [core/mem/q_malloc.c:520]: qm_free(): WARNING: free(0) called from dialplan: dp_db.c: pcre2_free(206) 2024-03-09T00:39:15.406973-05:00 csbc03 csbc[33024]: WARNING: {1 1 INVITE CALL-ID} <core> [core/mem/q_malloc.c:520]: qm_free(): WARNING: free(0) called from dialplan: dp_db.c: pcre2_free(206) 2024-03-09T00:39:15.407089-05:00 csbc03 csbc[33024]: WARNING: {1 1 INVITE CALL-ID} <core> [core/mem/q_malloc.c:520]: qm_free(): WARNING: free(0) called from dialplan: dp_db.c: pcre2_free(206) 2024-03-09T00:39:15.407178-05:00 csbc03 csbc[33024]: WARNING: {1 1 INVITE CALL-ID} <core> [core/mem/q_malloc.c:520]: qm_free(): WARNING: free(0) called from dialplan: dp_db.c: pcre2_free(206) 2024-03-09T00:39:15.407278-05:00 csbc03 csbc[33024]: WARNING: {1 1 INVITE CALL-ID} <core> [core/mem/q_malloc.c:520]: qm_free(): WARNING: free(0) called from dialplan: dp_db.c: pcre2_free(206) 2024-03-09T00:39:15.407375-05:00 csbc03 csbc[33024]: WARNING: {1 1 INVITE CALL-ID} <core> [core/mem/q_malloc.c:520]: qm_free(): WARNING: free(0) called from dialplan: dp_db.c: pcre2_free(206) It happens after running dp_translate(). These are my settings: debug=L_DBG debug=L_NOTICE memdbg=L_INFO memlog=L_INFO corelog=L_ERR mem_summary=12 log_stderror=no log_facility=LOG_LOCAL0 log_name="csbc" log_prefix="{$mt $hdr(CSeq) $ci} " mem_join=1 Any ideas? Thanks, Joel.

8 months, 1 week

low performance with no apparent reason

by Sergio Charrua

Hi all! I have been doing some performance tests with Kamailio 5.7.4 and SIPp. The infrastructure is as follows:3 VMs running on VMWare ESXi running: UAC on 10.20.0.1 with SIPP-> Kamailio on 10.20.0.5 -> UAS on 10.20.0.3 The Kamailio VM has 6 dedicated vCPU of type Intel(R) Xeon(R) Silver 4216 CPU @ 2.10GHz and, 2 NICs and 4Gb RAM and MariaDB 10.6 as DB Backend., all running on a HP G380 host with a gazillion CPUs and a googol disk space! I currently have 3 scripts: - script #1 stateful with RTJson and simulating requests to routing engine and accounting - script #2 stateful but with just a simple routing to UAS, no rules, no DB, - script #3 stateless with a forward to UAS With script #3 I can go up to 2000CPS without issues with CPU at 37%! Above that value, I get retransmissions everywhere. On both scripts #1 and #2, the limit is 330CPS max after which I get a lot of retransmissions, while CPU/Core usage on Kamailio server stays below 10%. So I do not expect this to be a CPU issue. I could not understand why such (low) results, so I followed this article found at https://www.kamailio.org/docs/openser-performance-tests/#tm-tests-c <https://www.kamailio.org/docs/openser-performance-tests/#tm-tests-c> and created exact same scenarios, with kamailio script and SIPP templates available on the article, hoping for better results. But I get the same results: between 300 and 330CPS which is far, very far from the 7000CPS found in the article! I understand that I'm using VMs and probably the tests made for the article, which is pretty old already, were made on physical servers. Still, I would not expect 95% of lower performance! Any clue what could be the issue? I suspect NICs, but.... Any tips anyone could share? Thanks in advance! *Sérgio Charrua*

9 months, 3 weeks

Releasing v5.8.1

by Daniel-Constantin Mierla

Hello, with many countries having public holidays around Catholic Easter, I am considering to release Kamailio v5.8.1 (out of branch 5.8) on Wednesday, April 3, 2024. If anyone is aware of issues not yet on the bug tracker, report them there asap in order to have a better chance to be fixed. Cheers, Daniel -- Daniel-Constantin Mierla (@ asipto.com) twitter.com/miconda -- linkedin.com/in/miconda Kamailio Consultancy, Training and Development Services -- asipto.com Kamailio World Conference, April 18-19, 2024, Berlin -- kamailioworld.com

9 months, 4 weeks

Can we discuss the internals of Kamailio's routing logic and how to customize it for specific needs?

by Inextrix Technologies Pvt Ltd

This question digs into the heart of Kamailio's functionality. It asks about: Routing Logic: How Kamailio decides where to send SIP messages (calls, registrations, etc.) based on various factors like caller ID, destination number, or custom rules. Customization: How you can modify this built-in logic to fit your specific needs. This could involve using scripting languages, manipulating SIP messages, or defining custom routing rules. The discussion would be for developers who want to unlock Kamailio's full potential and tailor it for their unique VoIP deployments. Visit us for More Info : https://inextrix.com/services/kamailio-development/

10 months

Callee details not visible in dialog

by egemen ulus

Hi, I am wondering why callee info is not visible in dialog details: Here is the case: client-1 > kamailio > two asterisks > kamailio > client-2 registration is on asterisk. dialog module is enabled and I want to see the asterisk IP that is determined by dispatcher module. I have tried to put dlg_manage function even after dispatch function, but did not help. I have also tried to update to header before dlg_manage function, it didn't help either. Any way to have asterisk IP in dialog details. It shows only this: { h_entry: 483 h_id: 8644 ref: 1 call-id: v489LdfOFD5mnlHupQHOvw.. from_uri: sip:1515@12.12.12.12;transport=UDP to_uri: sip:2222@12.12.12.12 state: 5 start_ts: 0 init_ts: xxxx end_ts: xxxx duration: xxxx timeout: 0 lifetime: 3600 dflags: 512 sflags: 0 iflags: 0 caller: { tag: d0283007 contact: sip:1515@1.1.1.1:64966;transport=UDP cseq: 1 route_set: socket: udp:172.22.10.10:5060 } callee: { tag: <null string> contact: <null string> cseq: <null string> route_set: <null string> socket: <null string> } profiles: { } variables: { } } Regards Get Outlook for Android<https://aka.ms/AAb9ysg>

10 months

[Presence] Updating route information for SIP NOTIFY when re-SUBSCRIBE

by Denys Pozniak

Hello! In my architecture, SIP SUBSCRIBE messages can reach the Kamailio Presence server in several ways. And I noticed that re-SUBSCRIBEs messages do not update the record_route field in the active_watchers table (MySQL), so subsequent SIP NOTIFY messages do not inherit it and have the routes set of the initial SIP SUBSCRIBE message. Is there any way to change this behavior? modparam("presence", "db_url", DBURL) modparam("presence", "subs_db_mode", 3) modparam("presence", "timeout_rm_subs", 0) modparam("presence", "expires_offset", 0) modparam("presence", "max_expires", 1800) modparam("presence", "db_update_period", 30) modparam("presence", "clean_period", 180) modparam("presence", "send_fast_notify", 1) modparam("presence", "pres_htable_size", 32) modparam("presence", "subs_htable_size", 32) modparam("presence", "publ_cache", 0) modparam("presence", "notifier_processes", 0) # kamailio -v version: kamailio 5.1.2 (x86_64/linux) -- BR, Denys Pozniak

10 months, 1 week

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