sr-users January 2025

sr-users@lists.kamailio.org

10 participants
5 discussions

by Sergey Safarov

If TCP children are busy, Please correct me if I am wrong if the remote IP is not responding via TCP protocol, this leads to a timeout and this child is busy. If many remote endpoints are not reachable via TCP this can lead to the case when half or more children are by timeout operations. I think required to monitor how many children are busy. Is it possible to get such info using kamcmd utility, statistics module, or xprom module. Sergey

1 hour, 2 minutes

record_route() adding wrong sips URI when transport is missing (defaulting to UDP)

by Benoit Panizzon

Hi Gang A quick search via google did not reveal any useful hits. Kamailio 5.7.6 CPE (TLS) => SBC (UDP) => Registrar (UDP) => Core CPE uses a sips contact URI to register, no transport attribute! sips:315996608@172.29.255.11:5061 SBC uses Path functionality. Situation: Call to CPE I see the registrar adding this Record-Route: Record-Route: <sips:registrar-ip;lr;ftag=6159862378> The SBC is adding a r2=on Record-Route to indicate the change between UDP and TLS. The Route-Set received by the CPE then is: INVITE sips:315996608@172.29.255.11:5061 SIP/2.0 Record-Route: <sips:sbc-ip:5061;transport=tls;r2=on;lr;ftag=6159862378> Record-Route: <sips:sbc-ip;r2=on;lr;ftag=6159862378> Record-Route: <sips:registrar-ip;lr;ftag=6159862378> Record-Route: <sip:core-ip;lr;ftag=6159862378> 180 Ringing req 100rel is making it back as the Via header look right. But when the remote side is sending a PRACK, is has to follow the Routeset which if I am not mistaking, is not making it back because because the CORE does not know how to send this via TLS to the Registrar. Core logging: prepare_new_uac(): can't fwd to af 2, proto 3 (no corresponding listening socket) IMHO already the 2nd Record-Route added by the Registrar should not contain a sips: URI but a sip: URI (reflecting the transport attribute not being present, defaulting to UDP) Is this a known issue? Mit freundlichen Grüssen -Benoît Panizzon- -- I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch ______________________________________________________

11 hours, 33 minutes

FOSDEM VoIP Dinner

by Torrey Searle

Hello all, As in previous years, I'm organising the VoIP dinner for FOSDEM (1 Feb @ 19:00) However unlike previous years (since the restaurant got upset about splitting the bill 30 ways). I will ask everyone to order their meal and pay in advance. (and I will pay the bill to the restaurant with my card) If you are wanting to attend the dinner please fill out the following form and follow the instructions for payment. https://form.jotform.com/250012543310033 Contact details are also in the form if you want to reach out to me with any further questions. Kind regards Torrey

15 hours, 3 minutes

Guidance Required for Kamailio Load Balancer Behavior in Attended Transfer Scenarios

by Kotappa Gandudi

Dear Kamailio Team, I hope this email finds you well. I am currently working on a project where Kamailio is being utilized as a load balancer to distribute calls across multiple FreeSWITCH instances. I am using the round-robin technique for load distribution, and it is working perfectly for regular call scenarios. However, I am encountering an issue when handling attended transfer calls. Specifically, for a normal call, Kamailio assigns one FreeSWITCH instance, but during the attended transfer call, it assigns another FreeSWITCH instance. This behavior disrupts the continuity of the call handling. My requirement is for Kamailio to use the same FreeSWITCH instance for the entire call, including any attended transfers. I believe maintaining the same FreeSWITCH instance for the entire call flow would ensure consistency and avoid potential issues. Could you please guide me on how to configure Kamailio to achieve this behavior? I would greatly appreciate any suggestions, configurations, or modules that can help resolve this issue. Thank you for your time and assistance. Looking forward to your response. Best regards, Kotappa Y Gandudi

17 hours, 24 minutes

ims_diameter_server not freeing shared memory

by marpett365＠gmail.com

Hi, I have run in to an issue when sending diameter requests using the ims_diameter_server module. Shared memory keeps increasing and are not being freed until restart of kamailio. This leads to all shared memory is being used and no more are able to be allocated. This only happens when the request is sent synchronously. When sent asynchronously shared memory is being freed as far as I can see. have anyone ran into this issue and found a remedy or can give some pointers how to proceed? Following functions have been used for sending requests. diameter_request([peer], appid, commandcode, message) diameter_request_async([peer], appid, commandcode, message) route[CHECK_LOCATION] { diameter_request("hss.ims.test.local", "16777217", "306", "[ " + "{ \"avpCode\":260, \"vendorId\":0, \"Flags\":64, \"list\":[ { \"avpCode\":266, \"vendorId\":0, \"Flags\":64, \"int32\":10415 }, { \"avpCode\":258, \"vendorId\":0, \"Flags\":64, \"int32\":16777217 } ] }, " + "{ \"avpCode\":277, \"vendorId\":0, \"Flags\":64, \"int32\":1 }, " + "{ \"avpCode\":283, \"vendorId\":0, \"Flags\":64, \"string\":\"ims.test.local\"}, " + "{ \"avpCode\":706, \"vendorId\":10415, \"Flags\":192, \"int32\":0 }, " + "{ \"avpCode\":700, \"vendorId\":10415, \"Flags\":192, \"list\": [ { \"avpCode\":601, \"vendorId\":10415, \"Flags\":192, \"string\":\"tel:" + $fU + "\" }]}, " + "{ \"avpCode\":707, \"vendorId\":10415, \"Flags\":192, \"int32\":0 }, " + "{ \"avpCode\":703, \"vendorId\":10415, \"Flags\":192, \"int32\":14 } ]"); xlog("L_INFO", "Sent Diameter request"); } Shared memory after restart kamcmd mod.stats cdp shm Module: cdp { save_peer_applications(779): 144 make_send_pipe(126): 320 dp_add_pid(92): 216 AAAAddRequestHandler(69): 40 cb_add(183): 8 cb_add(177): 32 cdp_sessions_init(178): 8 cdp_sessions_init(173): 8 cdp_sessions_init(165): 1024 cdp_sessions_init(157): 3072 cdp_sessions_init(149): 8 cdp_trans_init(67): 8 cdp_trans_init(60): 24 add_timer(150): 24 add_timer(145): 144 new_peer(77): 16 new_peer(75): 16 new_peer(72): 16 new_peer(69): 80 new_peer(66): 96 new_peer(60): 384 peer_manager_init(84): 8 peer_manager_init(83): 8 peer_manager_init(82): 8 peer_manager_init(79): 8 peer_manager_init(76): 16 worker_init(101): 16 worker_init(94): 128 worker_init(89): 32 worker_init(87): 32 worker_init(84): 8 worker_init(82): 48 timer_cdp_init(182): 8 timer_cdp_init(179): 16 diameter_peer_init_real(137): 8 diameter_peer_init_real(131): 16 diameter_peer_init_real(122): 16 diameter_peer_init_real(115): 8 diameter_peer_init_real(108): 8 diameter_peer_init_real(101): 8 diameter_peer_init_real(94): 8 new_routing_entry(88): 64 parse_dp_config(447): 16 parse_dp_config(348): 8 parse_dp_config(340): 16 parse_dp_config(333): 40 parse_dp_config(326): 144 quote_trim_dup(96): 456 new_dp_config(52): 184 Total: 7024 } Shared memory after 10 diameter requests Module: cdp { save_peer_applications(779): 144 AAACreateAVP(137): 5072 AAATranslateMessage(500): 1320 do_receive(600): 7392 make_send_pipe(126): 320 dp_add_pid(92): 216 AAAAddRequestHandler(69): 40 cb_add(183): 8 cb_add(177): 32 cdp_sessions_init(178): 8 cdp_sessions_init(173): 8 cdp_sessions_init(165): 1024 cdp_sessions_init(157): 3072 cdp_sessions_init(149): 8 cdp_trans_init(67): 8 cdp_trans_init(60): 24 add_timer(150): 24 add_timer(145): 144 new_peer(77): 16 new_peer(75): 16 new_peer(72): 16 new_peer(69): 80 new_peer(66): 96 new_peer(60): 384 peer_manager_init(84): 8 peer_manager_init(83): 8 peer_manager_init(82): 8 peer_manager_init(79): 8 peer_manager_init(76): 16 worker_init(101): 16 worker_init(94): 128 worker_init(89): 32 worker_init(87): 32 worker_init(84): 8 worker_init(82): 48 timer_cdp_init(182): 8 timer_cdp_init(179): 16 diameter_peer_init_real(137): 8 diameter_peer_init_real(131): 16 diameter_peer_init_real(122): 16 diameter_peer_init_real(115): 8 diameter_peer_init_real(108): 8 diameter_peer_init_real(101): 8 diameter_peer_init_real(94): 8 new_routing_entry(88): 64 parse_dp_config(447): 16 parse_dp_config(348): 8 parse_dp_config(340): 16 parse_dp_config(333): 40 parse_dp_config(326): 144 quote_trim_dup(96): 456 new_dp_config(52): 184 Total: 20808 } Shared memory after 170k requests do_receive(600): 131363752 AAATranslateMessage(500): 32326656 AAACreateAVP(137): 110067152 Total: 273764840 Br Martin

1 day, 16 hours

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 January 2025