sr-users July 2024

sr-users@lists.kamailio.org

42 participants
60 discussions

by Pyry Aaltonen

Hi, I recently updated my testing env to 5.8.1 and after that I’ve been receiving dns_cache.c warning “record not alone”. I found out that it’s been added to quite recent commit: https://github.com/kamailio/kamailio/commit/d8a35b3b6c837b36779e232b65fce61… And that’s probably the why I haven’t seen it before. As far as I know, I have no other problem with dns or anything else than the warning appearing in the logs 😊 I can’t quite get what the warning is about? Clearly refers to dns queries, and with debug I found out that maybe its somehow related to ip which has several domains to pointing it (and queried by one of those domains by this kamailio). Can it be something with the PTR-record? And this warning comes ones every hour, so probably when some ttl expires, and meanwhile the cache is ok with the situation. And as a background, I haven’t done any specific dns-configurations in my config, so settings should be pretty much in defaults. Any advice what I should fix here to get the warning disappear? -Pyry

2 months

Add a Header to CANCEL request

by sadik.oualla.mohamed＠gmail.com

Hello all, I am facing an issue with Kamailio when trying to add custom headers to CANCEL requests. My current configuration adds the "Reason" header perfectly: ``` if(!is_present_hf("Reason")){ $var(cause_request) = 31; append_hf("Reason: Q.850;cause=$var(cause_request)\r\n", "CSeq"); msg_apply_changes(); } ``` However, when I attempt to add headers like "X-Reason" or "TestHeader", they are not added: ``` if(!is_present_hf("Reason")){ $var(cause_request) = 31; append_hf("X-Reason: Q.850;cause=$var(cause_request)\r\n", "CSeq"); # or append_hf("TestHeader: Q.850;cause=$var(cause_request)\r\n", "CSeq"); msg_apply_changes(); #nothing changes in the relayed CANCEL request :-/ } ``` I've read in this discussion "https://lists.kamailio.org/mailman3/hyperkitty/list/sr-users@lists.kamailio…" that this might work if sending CANCEL in stateless mode, but I want to keep it stateful. Any suggestions on how to achieve this? Regards, Mohamed.

2 months

Changing ksr_tcp_accept_iplimit from default 1024

by Who AmI

Hi list, I hope you are all well? I am currently loadtesting some services internally and I am getting an odd error around TCP connections from the same source IP below: "/usr/sbin/kamailio[1806789]: CRITICAL: <core> [core/tcp_main.c:4459]: handle_new_connect(): hit the limit of connections per source IP (my_ip:39043) - rejecting" Its from the core the error so I was looking at the cookbooks and documentation but cannot get around this specific limit or find a configuration to tweak that fixes it. The limit only affects TCP (will affect TLS as well but I haven't got that far) and is 1024 it seems. Kamailio version is: 5.7.6 OS: Ubuntu 22.04 Things I have done so far: I have set limitNOFILE=65535 in the service file Set the tcp/tls_max_connections at 8192 (default is 2048) Increase the tcp_rd_buf_size to 16k+ The service I am using to loadtest is SIPp with flags "-t tn" for TCP multisocket as this service will have much more than 1024 concurrent TCP connections to it from a single source IP. I think I have missed something basic here as the devel and the source code references: "ksr_tcp_accept_iplimit" here at line 541: https://github.com/kamailio/kamailio/blob/master/src/main.c#L541 I cannot find a way to change this with a configuration line it seems, am I being blind or is my only option to build from source and change this? Many Thanks, John.

2 months

Weird telephone-event payload issue - need help

by Tim Bowyer

Hello Everyone, I've been grappling with this issue for some months, time to raise the white flag. Essentially I need to work out a way to configure Kamailio/RTPengine to normalise telephone-events to 101 earlier in the piece. 1. Call comes in from Carrier with INVITE w/SDP, telephone-event payload of 96. 2. INVITE sent to Asterisk with the same SDP, payload = 96 3. INVITE sent from Asterisk to Client with payload = 101 * 200 OK w/SDP from Client has payload = 101 * 200 OK w/SDP to Kamailio has payload = 96 * 200 OK w/SDP to Carrier has payload = 96 4. Asterisk (with Direct Media enabled) sends INVITE to Kamailio with payload = 96, and new media IP of Client 5. Kamailio passes this onto Carrier with media IP of RTPengine 6. 200 OK w/SDP from Carrier has payload = 96 sent to Kamailio 7. Kamailio passes this 200 OK to Asterisk, which responds with ACK and doesn't do anything further +---------+ +----------+ +---------+ +---------+ | Carrier | <----1-----> | Kamailio | <-----2----> | Asterisk| <----3------>| Client | | | | | | | | | +---------+ +----------+ +---------+ +---------+ ^ | | | | | |3| | | | | | +------5---------> +-----------+ <-----------------+------------4-----------+ | RTPengine | +-----------+ Big issue is, the Client is expecting telephone-events with a payload of 101, whereas RTPengine is passing it 96 from the Carrier. * Inbound DTMF only works at client-side if Asterisk stays in path (far from ideal). * The issue is exacerbated when calls are sent back out to the same or another carrier (forward scenario). * There's nothing I can seem to do in Asterisk to change how it handles DTMF in a direct media/re-invite setting. Any ideas? Cheers, Tim Bowyer

2 months

Kamailio Developers Meeting, Nov 19-20, 2024, in Dusseldorf

by Daniel-Constantin Mierla

Hello, Kamailio SIP Server project is organizing another meeting of its developers and community members during November 19-20, 2024 (Tue-Wed), hosted again by sipgate.de in Dusseldorf, Germany. The event is intended to facilitate the interaction between Kamailio developers and contributors in order to offer a convenient environment for working together on several topics of high interest for the project, including writing code for Kamailio and its tools, improving documentation, or discuss about future development. Everyone from the community is welcome to join, developer or user interested in helping the project. Please note we have a limited capacity of seats in the meeting room, the main policy for accepting participants being first come first server. Also, very important to be aware that this is not an event to learn how to use Kamailio. More details about the event, the venue, how to register, are available at: * https://www.kamailio.org/w/developers-meeting/ Looking forward to those two intensive hacking Kamailio days in Dusseldorf! Cheers, Daniel -- Daniel-Constantin Mierla (@ asipto.com) twitter.com/miconda -- linkedin.com/in/miconda Kamailio Consultancy, Training and Development Services -- asipto.com

2 months

how to upgrade kamailio minor release from 5.7.5 to 5.7.6

by sadik.oualla.mohamed＠gmail.com

I am currently using Kamailio version 5.7.5, which I installed from the source code. I would like to upgrade to version 5.7.6 but have been unable to find documentation specifically addressing minor upgrades between these minor releases. I have found only wikis detailing the process for upgrading for major releases (like 5.7.x to 5.8.0). Could you please point me to the documentation for my current need or share with me steps on how to perform this minor upgrade? Thank you. Cheers.

2 months

How to get the rtpengine IP used by the current call among multiple rtpengines

by mm e

modparam("rtpengine", "rtpengine_sock","udp:192.168.1.3:12221=2 udp:192.168.1.1:12222=1 udp:192.168.1.5:12221=7") When rtpengine_sock is set to multiple rtproxies mode, how to get the id or ip of the rtpengine used in the current call? There is no information returned which rtpengine

2 months

How to get the id or ip in the multiple rtproxies for LB with weights。

by mm e

2 months

Re: (no subject)

by Sergio Charrua

Hi Brett! From what I could understand, my client (a Carrier) assigns services and products to its customers identified by trunkgroups (depending on the customer and the service requested, as well as the ingress trunkgroup the call will be forwarded to a specific egress trunkgroup). . The INVITE is sent by customer to the SBC (ingress), where some kind of process (which i have no details) will decide what IP:Port to forward the messages to Kamailio with additional infos (Kamailio is listening on different NICs/IPs/Ports). Then, Kamailio will check on the (external) routing engine the route to take and forwards to the outbound endpoint. Depending on the IP:Port that Kamailio receives the call (SBC may choose one NIC or the other) the request is then received by Kamailio and verified/processed by the routing engine replying back to kamailio with the route to take, and then Kamailio forwards to the outbound endpoint (egress SBC...). It is a bit confusing, and I want to simplify things as much as possible, but apparently the old/current solution is set this way and they pretend to keep the new solution as similar as possible to the old/current solution. This is mostly due to the billing process, which is very (overly?) complex and they do not pretend to change it. IMHO, the routing engine should be much simpler but it is a much more complex process the Carrier currently has...and wishes to keep. (sorry for posting without a subject. I did, however, re-posted with corrected subject) Atenciosamente / Kind Regards / Cordialement, *Sérgio Charrua* On Fri, Jul 12, 2024 at 8:11 PM Brett Nemeroff <brett(a)voicefoxtelephony.com> wrote: > Is there a reason you have to identify the trunk group based on received > IP/Port? I've seen this as a requirement from some more antiquated systems > and it's always a pain. It's always better to use source IP or even a trunk > prefix (dialed number prefix) which isn't really secure, but works when > security isn't an issue. > > If you have to do it that way, I'd probably turn the $Ri/$Rp into some > sort of cache key like $Ri_$Rp and map it to something like a dispatcher > setid. > > There may be a more modern way to do this, but I don't think there is. > > Good luck! > -Brett > > > On Fri, Jul 12, 2024 at 1:40 PM Sergio Charrua via sr-users < > sr-users(a)lists.kamailio.org> wrote: > >> Hi all! >> >> for a project under development, one requirement is to be able to >> forward/relay the call to a specific destination depending on which IP >> Address and Port the call was received by Kamailio. >> This also means that Kamailio will be listening on multiple IP Address >> and Ports >> listen=udp:IP_1:port_1 # trunkgroup 1 >> listen=udp:IP_2:port_2 # trunkgroup 2 >> listen=udp:IP_3:port_3 # trunkgroup 3 >> >> I know the pv $Ri and $Rp can be used to identify from which IP address >> and port the message reached Kamailio and having those details, depending >> on the value, I can define some conditions that allows Kamailio to relay >> the call to different destination endpoints. >> For example: >> - calls from +32 to + 39 received on trunkgroup1 needs to go to Italy SBC >> address A.B.C.D >> - but calls from +32 to +39 received on trunkgroup2 need to go to Germany >> on SBC address 1.2.3.4 (as it is cheaper) >> >> Is there a better way of doing this without using IF/THEN/ELSE or SWITCH >> blocks and "hard code" destination SBC addresses? >> I have read the DRouting module's documentation but not sure if it could >> help and how... >> >> Any suggestions? >> >> >> >> Atenciosamente / Kind Regards / Cordialement, >> >> >> *Sérgio * >> __________________________________________________________ >> Kamailio - Users Mailing List - Non Commercial Discussions >> To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org >> Important: keep the mailing list in the recipients, do not reply only to >> the sender! >> Edit mailing list options or unsubscribe: >> > > > -- > > ======================================================== > Brett Nemeroff > Voice Fox Telephony LLC > Office: 512-670-8369 > Email: brett(a)voicefoxtelephony.com >

2 months

Change the To Header in the failure_route

by sadik.oualla.mohamed＠gmail.com

Hello, I need help with modifying the "To" header in the "failure_route[ID]{...}". Specifically, I want to add the "to tag" parameter from the previous SIP messages of the current dialog(e.g., 180 Ringing, PRACK or final responses). Here's the scenario: 1. Kamailio receives and relays the SIP messages: INVITE, 180 Ringing, PRACK, 200 OK, 486 Busy Here. 2. In my case, the 180 Ringing includes the "to tag" parameter. 3. When Kamailio receives the 486 response, it triggers "failure_route[ID]" using "t_on_failure(ID)" method. 4. I extract the SIP response code and reason from the final response of the INVITE transcation in this failure_route. 5. After processing and applying some instructions, I send a reply using "t_send_reply" with the code and reason extracted. The problem: - The failure_route[ID] holds the initial INVITE, which has no "to tag" parameter. - When I send a reply using "t_send_reply()", Kamailio generates a random "to tag" different from the previous SIP messages, which confuses my UAC. I think adding the "to tag" parameter manually might be a solution, but I'm not sure if I'm doing it correctly or if there is a better approach. I also tried using uac_replace_to() method, but it doesn't work in the failure_route[ID]. How can I make sure the reply in failure_route[ID] uses the correct "to tag" from the previous SIP messages? Are there any other possibilities to achieve this? Any assistance would be appreciated. Thank you!

2 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 July 2024