sr-users September 2020

sr-users@lists.kamailio.org

84 participants
108 discussions

SRTP-DTLS and rtpengine
by Gholamreza Sabery 12 Sep '20

12 Sep '20

Hi, I checked rtpengine's documentation, and I wonder what happens if I use SRTP-DTLS with rtpengine? My connection will be hop by hop encrypted with rtpengine, or like TURN my connection will remain end-to-end encrypted?? Thx a lot

2 2

Re: [SR-Users] xlog print sdp parameters
by Angel Elena 11 Sep '20

11 Sep '20

Ok, thanks for the info. -------------------------------- Ángel Elena Medina _o) craem(a)craem.net / \\ http://diablo.craem.net _(___V @craem_ www.linkedin.com/in/angel-elena-medina -------------------------------- Kopano Webapp. -----Original message----- From: Henning Westerholt <hw(a)skalatan.de> Sent: Friday 11th September 2020 14:03 To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org> Cc: Angel Elena <craem(a)craem.net> Subject: RE: [SR-Users] xlog print sdp parameters Hello, you can use e.g. https://www.kamailio.org/docs/modules/stable/modules/sdpops.html#idm239to print in all xlog. Have a look to the other functions to get access to certain lines. Cheers, Henning -- Henning Westerholt –https://skalatan.de/blog/ Kamailio services –https://gilawa.com From: sr-users <sr-users-bounces(a)lists.kamailio.org> On Behalf Of Angel Elena Sent: Friday, September 11, 2020 1:36 PM To: sr-users(a)lists.kamailio.org Subject: [SR-Users] xlog print sdp parameters Hi, good moorning. I have a Kamailio 4.4.7 in a debian box and I need print with xlog (if is possible) the o,c and m values from SDP headers. Is possible make a xlog() print this parameters with sdpops module or another ? Thanks -------------------------------- Ángel Elena Medina _o) craem(a)craem.net <mailto:craem@craem.net> / \\ http://diablo.craem.net <http://diablo.craem.net> _(___V @craem_ www.linkedin.com/in/angel-elena-medina <http://www.linkedin.com/in/angel-elena-medina> -------------------------------- Kopano Webapp.

1 0

REST API to initiate a call in Kamailio
by Ameed Jamous 11 Sep '20

11 Sep '20

Hello Everyone, I was wondering what’s the most recommended module by the community today to initiate calls via Kamailio using REST API. Call Flow: Application —> HTTP (Async) —> Kamailio —> B2BUA —> Callee(s). Does a reliable module for this already exist today? Thanks in advance ! Stay safe. -- [image: photo] *Ameed Jamous* Founder, TelecomsXChange +1 954 246 3356 <+1+954+246+3356> | a.jamous(a)telecomsxchange.com www.telecomsxchange.com | Skype: telecomsxchange <#SignatureSanitizer_SafeHtmlFilter_> 1800 N Bayshore Dr, Suite CU1, Miami, FL 33132

8 16

Getting memory error on kamailio v5.1.2 tm:Free fragment not found!
by M Arqum CH 11 Sep '20

11 Sep '20

Hello Users, I am facing memory-related error on my Kamailio server, using this kamailio version kamailio -v version: kamailio 5.1.2 (x86_64/linux) with -m 512 -M 32 childern=16 System Memory : 24 GB System Cores: 12 On console getting the following error : Sep 08 14:40:29 debian /usr/sbin/kamailio[99894]: ERROR: <core> [core/mem/q_malloc.c:286]: qm_find_free(): qm_find_free(0x7fdf51eb9000, 11320); Free fragment not found! Sep 08 14:40:29 debian /usr/sbin/kamailio[99894]: ERROR: <core> [core/mem/q_malloc.c:419]: qm_malloc(): qm_malloc(0x7fdf51eb9000, 11320) called from tm: h_table.c: build_cell(320), module: tm; Free fragment not found! Sep 08 14:40:29 debian /usr/sbin/kamailio[99894]: ERROR: tm [t_lookup.c:1279]: new_t(): out of mem: Sep 08 14:40:29 debian /usr/sbin/kamailio[99894]: ERROR: tm [t_lookup.c:1422]: t_newtran(): new_t failed Sep 08 14:40:29 debian /usr/sbin/kamailio[99894]: ERROR: sl [sl_funcs.c:362]: sl_reply_error(): stateless error reply used: No error (2/SL) Please guide about the possible reason of failure or its memory leakage, possible solution. Thanks -- Regards M Arqum

5 6

Re: [SR-Users] How to handle BYE in case of serial fork
by Björn Klasen 11 Sep '20

11 Sep '20

Hi Hennning, loose_route() is what we are using. But we use also dialog module for call counting etc. We did not really change the default config. This is the snippet in our config. if (has_totag()) { # sequential requests within a dialog should # take the path determined by record-routing if (loose_route()) { if (is_method("BYE")) { t_on_reply("bye_reason"); setflag(FLT_ACC); # ... even if the transaction fails But I think that is not the point. The responses 18x responses are my real problem, because they have the same did in record-route but different to-tags because of the call forwarding scenario. That leads to the BYE of the first fork. With this BYE they try to stop the call with the first to-tag. But the first fork ist already canceld. So Kamailio behaves correctly by not answering or forwarding anythin, but throwing a warning with tight dialog matching not possible. Thats because at that point Kamailio does only know about the call with the second. So when the BYE is received by Kamailio the dialog modules can find the did but not the to-tog as Kamailio only has the second one left in memory. Now the point is, is there a way to hold the first early dialog fork in memory until it is either terminatet with a CANCEL or BYE or the last fork with the corresponding did is terminatet. I have read that ims_dialog or dialog_ng in our can handle things like this, but I also can't get it to work. By the way cdr generation does also not work with dialog_ng or ims_dialog (i also made tests with kamailio 5.3.5). This is the problematic BYE Message (i deleted customer relatet infomations) BYE sip:bob@kamailio:5060 SIP/2.0 Via: SIP/2.0/UDP carrier:5060;branch=z9hG4bKh6e7ie103g9amkc8gdo0.1 Max-Forwards: 65 To: <sip:bob@kamailio>;tag=11A2CF0C-5F578E7E000376B5-AA5BD700 From: <sip:anonymous@anonymous.invalid>;tag=h7g4Esbg_h7g4Esbg_c5478d8b Call-ID: ae36c13c31b5e910(a)a.b.c.d CSeq: 1313626 BYE Privacy: user;id Content-Length: 0 Allow: ACK, BYE, CANCEL, INFO, INVITE, MESSAGE, OPTIONS, PRACK, PUBLISH, REGISTER, SUBSCRIBE, UPDATE Route: <sip:kamailio-ip:5070;r2=on;lr;ftag=h7g4Esbg_h7g4Esbg_c5478d8b;did=c4851.7b1c5> Route: <sip:sems-ip;r2=on;lr;ftag=h7g4Esbg_h7g4Esbg_c5478d8b;did=c4851.7b1c5> This one matches to the 180 of the call to callee b SIP/2.0 180 Ringing Record-Route: <sip:sems-ip;r2=on;lr;ftag=h7g4Esbg_h7g4Esbg_c5478d8b;did=c4851.7b1c5> Record-Route: <sip:kamailio-ip:5070;r2=on;lr;ftag=h7g4Esbg_h7g4Esbg_c5478d8b;did=c4851.7b1c5> Via: SIP/2.0/UDP bob@kamailiko:5060;branch=z9hG4bK1s9rar309o1uf6j41ik0.1 Call-ID: ae36c13c31b5e910(a)a.b.c.d CSeq: 1313625 INVITE To: <sip:bob@kamailio>;tag=11A2CF0C-5F578E7E000376B5-AA5BD700 From: <sip:anonymous@anonymous.invalid>;tag=h7g4Esbg_h7g4Esbg_c5478d8b Content-Length: 0 Contact: <bob-pjhq8ddet3tu9@bobdomain;transport=udp> I hope you can understand my problem a little better now. BR Björn Am 11.09.20 um 12:26 schrieb Henning Westerholt: > Hello Björn, > > I was not referring to dialog stateful routing e.g. with dialog module. I was referring to the loose_route() function in your kamailio.cfg (e.g. compare to the default cfg in github). > > Maybe you can quote the problematic BYE SIP message here. > > Cheers, > > Henning > -- Björn Klasen, Specialist TNG Stadtnetz GmbH, Network Management (VoIP) Projensdorfer Straße 324 24106 Kiel Germany T +49 431/ 530530 F +49 431/ 7097-555 mailto: bklasen(a)tng.de http://www.tng.de Register: Amtsgericht Kiel HRB 6002 KI Executive board (Geschäftsführung): Dr.-Ing. Volkmar Hausberg, Sven Schade, Carsten Tolkmit, Dr. Sven Willert Tax-Id (Steuernr.): 2029047020, VAT-Id (USt-Id): DE225201428

2 2

How to check which memory allocator kamailio is using ?
by sagar malam 11 Sep '20

11 Sep '20

Hello , Is there any way to check if the memory allocator is used by kamailio ? qmalloc,fmalloc or tlsf. -- Thanks, Sagar

2 3

xlog print sdp parameters
by Angel Elena 11 Sep '20

11 Sep '20

Hi, good moorning. I have a Kamailio 4.4.7 in a debian box and I need print with xlog (if is possible) the o,c and m values from SDP headers. Is possible make a xlog() print this parameters with sdpops module or another ? Thanks -------------------------------- Ángel Elena Medina _o) craem(a)craem.net / \\ http://diablo.craem.net _(___V @craem_ www.linkedin.com/in/angel-elena-medina -------------------------------- Kopano Webapp.

2 1

Using Kamalio as a proxy for internal servers
by Moshe Katz 11 Sep '20

11 Sep '20

Hello all, (Note: I previously posted a more detailed version of this question on StackOverflow at https://stackoverflow.com/q/63760506/829970 . This version is simplified to fit better in an email.) I have Kamailio 5.4.1 (and RTPEngine) running on an internal server with a private IP address 172.31.7.96 and One-to-one NAT to an external IP address. The external IP is 192.0.2.100. (Note: The internal IP addresses are all unedited, but the public IPs have been replaced with TEST-NET-1 and TEST-NET-2 example addresses.) I will eventually be doing transcoding with RTPEngine, but for now this is a simple SIP Proxy. Kamailio is installed on Ubuntu 18.04 using the DEB packages from dev.kamailio.org/kamailio54 and is using the stock configuration that comes with those packages, except for the following changes: #!define WITH_NAT #!define WITH_RTPENGINE #!define WITH_MYSQL #!define WITH_AUTH #!define WITH_IPAUTH listen=udp:0.0.0.0:5060 advertise 192.0.2.100:5060 #!define DBURL "mysql://kamailio:REAL_PASSWORD_HERE@127.0.0.1/kamailio" I have internal SIP servers with private IP addresses in the 172.31.7.0/24 range that I want to have send all SIP traffic through the Kamailio server. The internal servers are running a Java SIP client with the `OUTBOUND_PROXY` setting set to 172.31.7.96. The problem I have is that the SIP `200 OK` message sent by Kamailio to my SIP server has its `Record-Route` header set to the public IP address `192.0.2.100` instead of the private address `172.31.7.96`. The SIP client therefore tries to send the `ACK` message back to the public address, but it has no route to the public address so the ACK never gets sent. How can I configure Kamailio to use the public IP for external traffic but the private IP for communicating with internal machines on the same subnet? I tried setting `mhomed=1`, but the machine isn't actually multi-homed so that didn't work. I thought of adding a second listen line `listen=udp:172.31.7.96:5061` and having the internal servers talk to port 5061, but that doesn't work because Kamailio uses the 5061 definition for the external side too. I see in the docs that it is possible to name the listener lines, but I don't understand how to use those names in a way that would be relevant to my issue. Thank you very much for your help, Moshe

5 6

How to handle BYE in case of serial fork
by Björn Klasen 11 Sep '20

11 Sep '20

Hi we are using Kamailio 4.3.7 and I have a question concerning BYE handling. We have the following situation: A carrier a call to us. We are forwarding the call to the destination, but it does not pick up the call. We have call-forward active with use of tm module, so we forward the call to the new destination. The first call generates a to-tag in 180, let's call it TT1. The second call, so the c-destination also answer with 180 but with another to-tag (TT2). Both ringing are passed to the originating carrier. When the timer for the first call is timed out, Kamailio cancels the branch with a CANCEL so it does not exist any more Now the c-destination picks up the phone, and reply with 200 OK with TT2 The carrier then sends a BYE with TT1 to us, but Kamailio doesn't know anything about it, so it does not reply and the carrier sends a timeout and terminates the complete call. So the question is, how handle such a situation. Is it possible to store the first branch, or fake a OK reply to the BYE request of the carrier as for my understanding this behaviour is not against RFC. To clarify the situation here comes a call-flow diagram A Kamailio B C |---INV Bob@P1->| | | | |--INV Bob@B--->| | | |<-100----------| | |<-100----------| | | | |<-180 TT1------| | |<-180 TT1------| | | Forward after 10 seconds | |--CANCEL------>| | | |<-487----------| | | |<-200 OK-------| | | |--ACK--------->| | |<-181 TT1------| | | | |--INV Carol@C----------------->| | |<-100--------------------------| | |<-180 TT2----------------------| |<-180 TT2------| | | | |<-200 OK TT2-------------------| |<-200 OK TT2---| | | |--BYE TT1----->| | | |--BYE TT1----->| | | |--BYE TT1----->| | | |--408--------->| | | |--ACK--------->| | | | |--ACK------------------------->| | |<-BYE TT2----------------------| |<-BYE TT2------| | |--481--------->| | | |--481------------------------->| To get around the the situation with the second to-tag, we passing every call through SEMS now, because its B2B function rewrites the to-tag, so there is always only one to-tag towards the carrier A. But it's not the gold solution. I hope somebody can help me. BR, Björn -- Björn Klasen, Specialist TNG Stadtnetz GmbH, Network Management (VoIP) Projensdorfer Straße 324 24106 Kiel Germany T +49 431/ 530530 F +49 431/ 7097-555 mailto: bklasen(a)tng.de http://www.tng.de Register: Amtsgericht Kiel HRB 6002 KI Executive board (Geschäftsführung): Dr.-Ing. Volkmar Hausberg, Sven Schade, Carsten Tolkmit, Dr. Sven Willert Tax-Id (Steuernr.): 2029047020, VAT-Id (USt-Id): DE225201428

1 0

Kamailio v5.3.6 Released
by Daniel-Constantin Mierla 10 Sep '20

10 Sep '20

Hello, Kamailio SIP Server v5.3.6 stable release is out. This is a maintenance release of the latest stable branch, 5.3, that includes fixes since the release of v5.3.5. 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.6. Note that 5.3 is the second last stable branch, still officially maintained by Kamailio development team. The latest stable branch is 5.4, with v5.4.1 being release out of it. For more details about version 5.3.6 (including links and guidelines to download the tarball or from GIT repository), visit: * https://www.kamailio.org/w/2020/09/kamailio-v5-3-6-released/ RPM, Debian/Ubuntu packages will be available soon as well. 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

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 September 2020