sr-users

sr-users@lists.kamailio.org

42 participants
37518 discussions

Unquoted values from #!defenv
by Ben Kaufman 09 Dec '21

09 Dec '21

Hello all, Looking for some clarification regarding quoting and !#defenv . I understand that the example below fails because the environmental variable HOME is not quoted, thus when used in the xlog() call it fails. How is it possible to evaluate and/or use the value of the environmental variable if defined as a preprocessor variable? Looking at the documentation the reason for this directive is "It is a simplified alternative of using #!substdef with $env(NAME) in the replacement part." But #!substdef would allow setting the value inside of a quoted string, so does it really meet that requirement? I'm aware that I could use $env(HOME) rather than a preprocessor directive of HOME. I'm just trying to understand the usage of the #!defenv feature. #!KAMAILIO ## Tested in 5.5.2 loadmodule "xlog" loadmodule "pv" loadmodule "evrexec" modparam("evrexec", "exec", "name=evrexec:timer;wait=1000;workers=1;") #!defenv HOME request_route{ forward(); } event_route[evrexec:timer] { xlog("L_N", "HOME: " + HOME + "\n"); } Ben Kaufman

3 15

wireshark decode kamailio / rtpengine ng messages
by Karsten Horsmann 08 Dec '21

08 Dec '21

Hi List, maybe someone wrote a wireshark helper (didnt know the right term) to view kamailio to rtpengine communication in human form? Some hints would be great. -- Mit freundlichen Grüßen *Karsten Horsmann*

2 1

Re: [SR-Users] wireshark decode kamailio / rtpengine ng messages
by Alex Balashov 08 Dec '21

08 Dec '21

That sounds far too niche for a helper, though, then again, Wireshark has some phenomenally exotic helpers. — Sent from mobile, with due apologies for brevity and errors. > On Dec 8, 2021, at 8:14 AM, Karsten Horsmann <khorsmann(a)gmail.com> wrote: >

1 0

Kamailio v5.3.9 Released
by Daniel-Constantin Mierla 08 Dec '21

08 Dec '21

Hello, Kamailio SIP Server v5.3.9 stable release is out. This is a maintenance release of the old stable branch, 5.3, that includes fixes since the release of v5.3.8. There is no change to database schema or configuration language structure that you have to do on previous installations of v5.3.x. Deployments running previous v5.3.x versions are strongly recommended to be upgraded to v5.3.9 or even better to v5.4.x or 5.5.x series. For more details about version 5.3.9 (including links and guidelines to download the tarball or from GIT repository), visit: * https://www.kamailio.org/w/2021/12/kamailio-v5-3-9-released/ RPM, Debian/Ubuntu packages will be available soon as well. Note: the branch 5.3 is an old stable branch, v5.3.9 being the last planned release out of it, to mark the end of official maintenance. The maintained stable branches are now 5.4 and 5.5, at this time with v5.5.3 being the latest stable release. Many thanks to all contributing and using Kamailio! Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda

1 0

Re: [SR-Users] Manipulation of request-line
by Alex Balashov 08 Dec '21

08 Dec '21

That will manipulate the request URI, but not the request line. — Sent from mobile, with due apologies for brevity and errors. > On Dec 7, 2021, at 4:16 PM, Karsten Horsmann <khorsmann(a)gmail.com> wrote: >

2 1

Releasing Kamailio 5.3.9 - last in 5.3.x series
by Daniel-Constantin Mierla 08 Dec '21

08 Dec '21

Hello, it is time to mark the end of official packaging for 5.3.x releases, therefore during the next days I am going to cut the v5.3.9 release from branch 5.3, likely on Wednesday, Dec 8, 2021. In other words, if no major regression is detected shortly after this release, the v5.3.9 is going to be the last one from the 5.3 branch. It is strongly recommended to move to a series that is under active maintenance, respectively 5.5.x or 5.4.x. Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - Online Feb 21-24, 2022 (America Timezone) * https://www.asipto.com/sw/kamailio-advanced-training-online/

1 1

HTTP Requests for API routing - Question on which module to use with KSR
by Emilio Panighetti 08 Dec '21

08 Dec '21

Looking into using Kamailio to route calls via an HTTP API. Basic scenario is this: INVITE comes in (no registration). And Kamailio sends an HTTP request to a server with data extracted from the INVITE. Based on the response, call KSR.setdsturi() and other actions like normalizing phone numbers, etc. (Not sure if changing Contact: headers would be a better option). For now I want to be able to make a simple call routing as a proof of concept. Planning on using Lua as a KEMI interpreter. Looking at different modules: http_client http_client_async xhttp Which module would be more appropriate? http_client_async provides a simple async method and callback, so the SIP threads can continue processing requests while the API server is preparing the response. But the call has to be parked (How is this done?) and this is also an overhead. http_client seems straightforward, but the SIP threads are tied up waiting for HTTP responses. Also looking at the KEMI documentation, the KSR function calls for HTTP_CLIENT doesn’t seem to match the config function documentation. For example, In KEMI manual: KSR.http_client.curl_connect_post() doesn’t have a corresponding in kamailio.cfg. So which would be the preferred approach? Also examples would be appreciated. Thanks in advance!

1 0

Manipulation of request-line
by Mihovil Kolaric 07 Dec '21

07 Dec '21

Hi, I have an issue with a SIP-client, that occasionally puts a blank between the version SIP/2.0 and the CRLF at the and of the request-line. (i.e. sends "ACK <uri> SIP/2.0 \r\n" instead of "ACK <uri> SIP/2.0\r\n"). Kamailio (as well as most SIP UAs) does not care about that error and successfully processes/forwards the request (also when using sanity_check()). But I also deal with a client that fails to parse that request. (Furthermore, wireshark's dissector fails to recognize such malformed messages as SIP, which makes debugging even harder). I tried to fix this issue using textops, but all functions I tried operate only on headers or message body, but do not seem to affect the request line. Is there any possibility to modify the request-line, or to replace it with a new one? Best Regards, Mihovil

2 1

Announcing public beta release of TeamsPhone - powered by Kamailio
by Sergiu Pojoga 06 Dec '21

06 Dec '21

Hello Kamailio-nians, Just to bug everyone quickly: today I'm happy to announce the public beta release of *TeamsPhone <https://teamsphone.net>*, a MS Teams <=> PBX integration solution for ITSPs, IP-PBX service providers and integrators, *powered by Kamailio*. Unlike other similar services offered as SaaS pay-per-user model, our product is oriented for ITSPs to be self-hosted and fully integrated into one's telecom network, providing an add-on service to supplement any Hosted PBX offering with seamless calling using Microsoft Teams *as-as-softphone*, or as we like to call it - TeamsPhone. Some insights about the platform: - 100% automation of MS Teams Direct Routing provisioning - multi-tenant application - API-driven - Microservices oriented architecture - RabbitMQ-powered Message Broker distribution - SIP server (you guessed it - Kamailio, of course!) Seeing how it works is worth a thousand words. A cloud *demo* instance is available at https://my.teamsphone.net for anyone to try it out, use it or abuse it. If you have questions about the product - feel free to contact me in private. Respectfully, Sergiu Pojoga Founder, teamsphone.net sergiu(a)teamsphone.net

1 0

detecting compact headers?
by Brooks Bridges 06 Dec '21

06 Dec '21

We have an internal component of our callflow that does not support compact headers (vendor says it's on the roadmap but no eta, etc) so I'm trying to find a clean way to detect if a message has compact headers and reject it. I haven't had much luck in finding a way to identify specifically if any of the headers of the message are compact however. Can anyone point me in a direction please? Thanks! Confidentiality Notice: This e-mail, and any attachment to it, contains privileged and confidential information intended only for the use of the individual(s) or entity named on the e-mail. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that reading this e-mail is strictly prohibited. If you have received this e-mail in error, please immediately return it to the sender and delete it from your system.

3 3

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