sr-users January 2023

sr-users@lists.kamailio.org

56 participants
64 discussions

by Björn Klasen

Hi everybody, I'm just testing Kamailio 5.4.1 with dialog replication over DMQ. This seems to work very good. Dialogs are replicated without problems. When I'm restarting one node I would have expected, that all dialogs are synced again, just like in dmq_usrloc. But this does not happen. After a restart the nodes dialog-list is empty. Did I miss somethin? Is there a special parameter that I have to set? 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

3 weeks, 5 days

Increase MAX_BRANCHES_LIMIT

by Lars Jansson

Hi, I am building a configuration script where for some traffic flows parallel forking will be needed, and in this case I need to go beyond the default max limit of the max amount of branches. Apart from this specific case the traffic load that kamailio will need to handle is very low, let's say just one second here and there with up to 5 concurrent calls at most. This limit is as far as I understand set here: usr/local/src/kamailio-5.6/kamailio/src/core/config.h And the default limit is: #define MAX_BRANCHES_LIMIT 32 /*!< limit of maximum number of branches per transaction */ Here are the questions I have related to this: 1) If I increase the value of this constant in config.h, how high is it reasonable to set this value and still have a stable system? 2) If I increase MAX_BRANCHES_LIMIT beyond 32, are there also other parameters that needs to be changed for the system to be able to cope, and if so whichparameters? Regards, Lars

7 months

Is Min-SE check broken?

by harneet singh

Hi All, I am facing an issue in understanding how the min_se should be working in kamailio. As per the SST documentation, it seems like if the min_se is configured as 500, then any value of Session-Expires OR MIN-SE if lower than 500, can be responded to by a 422. However, I strangely see the reverse happening. To investigate further, I looked in to the ki_sst_check_min() code in the master, and these seems like a potential issue. Ref Code: Inside ki_sst_check_min(), there is an if condition like below: if (sst_min_se < MIN(minse, se.interval)) { However, shouldn't it be the other way around? ie if (sst_min_se > MIN(minse, se.interval)) { because we need to send 422 if the received value(in INVITE etc) is smaller than the sst configure min_se value? I also found a different documentation, at https://git.sgu.ru/oldssu/ex-opensips/blob/cb9df8d59dbb254a9d862569fd5d11f6… where the check is as below? if (sst_min_se > MIN(minse, se.interval)) { Can someone confirm if this is broken, or my understanding is incorrect? Regards, Harneet -- "Once you eliminate the impossible, whatever remains, no matter how improbable, must be the truth" - Sir Arthur Conan Doyle

10 months, 3 weeks

Performing async_http calls on stateless Loadbalancers

by Julius Flohr

Hi List, we are running several stateless SIP Loadbalancers using Kamaillio 5.1 and 5.6. Now we would like to perform an async_http request if an INVITE matches certain criteria. The request itself is performed very similar to how it's described here [1] This uses the transaction module in order to assure that the response can be mapped to the original request. However, this also means that the processing of the entire request becomes stateful which we would like to avoid. We tried to use t_release() in the callback route (in [1] this route is called "RELAY_API_RESPONSE"). However, documentation says that this is only allowed in the REQUEST_ROUTE. Is there an easy way to circumnavigate this issue? Cheers [1]: https://wazo-platform.org/blog/kamailio-routing-with-rtjson-and-http-async-… -- Julius Flohr - Voice Engineer - flohr(a)sipgate.de Telefon: +49 (0)211-63 55 55-0 Mobil: +49 (0)1579-000-0205 Telefax: +49 (0)211-63 55 55-22 sipgate GmbH - Gladbacher Str. 74 - 40219 Düsseldorf HRB Düsseldorf 39841 - Geschäftsführer: Thilo Salmon, Tim Mois Steuernummer: 106/5724/7147, Umsatzsteuer-ID: DE219349391 www.sipgate.de - www.sipgate.co.uk

11 months, 2 weeks

Re: [SR-Users] TOPOS (5.1.[23]) breaks PRACK

by Daniel Tryba

On Mon, May 07, 2018 at 04:44:14PM +0200, Daniel Tryba wrote: > Sure. Attached. Problem appears to be that the topos query can't find > callid-totag (from the response). > > I'll try the same scenario with the mysql backend to see if it behaves > different. Config works fine with mysql as topos backend. So the bug is restricted to topos-redis.

11 months, 3 weeks

Rtpengine: no audio after kernelization.

by Michel Pelletier

Hello, I am proxying all RTP through RTPEngine. Everything works fine until about 5 seconds into the call, when rtpengine enters kernelization, after which all RTP forwarding ceases. I've checked the required iptables entries, and all looks good. Here is a description of my environment: # cat os-release PRETTY_NAME="Debian GNU/Linux 11 (bullseye)" NAME="Debian GNU/Linux" VERSION_ID="11" VERSION="11 (bullseye)" VERSION_CODENAME=bullseye ID=debian HOME_URL="https://www.debian.org/" SUPPORT_URL="https://www.debian.org/support" BUG_REPORT_URL="https://bugs.debian.org/" # kamailio -v version: kamailio 5.6.2 (x86_64/linux) 54a9c1 flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: 54a9c1 compiled on 16:02:49 Dec 1 2022 with gcc 10.2.1 # rtpengine -v Version: 11.1.1.3-1~bpo11+1 Michel Pelletier

1 year

Dispatcher Incoming

by nutxase

Hi All I have setup kamailio using dispatcher to proxy registrations from the UAC to asterisk but when asterisk sends an incoming call it does not seem to keep the path header and therefore kamailio sends 404 is there anyway around this? Thanks Sent with [Proton Mail](https://proton.me/) secure email.

1 year, 1 month

Kamailio v5.6.3 Released

by Daniel-Constantin Mierla

Hello, Kamailio SIP Server v5.6.3 stable release is out. This is a maintenance release of the latest stable branch, 5.6, that includes fixes since the release of v5.6.2. There is no change to database schema or configuration language structure that you have to do on previous installations of v5.6.x. Deployments running previous v5.6.x versions are strongly recommended to be upgraded to v5.6.3. For more details about version 5.6.3 (including links and guidelines to download the tarball or from GIT repository), visit: * https://www.kamailio.org/w/2023/01/kamailio-v5-6-3-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 Kamailio World Conference - June 5-7, 2023 - www.kamailioworld.com

1 year, 1 month

enable topology hiding on one side or dynamic ip in topoh module Contact and Via Header

by Patrick Karton

Hello , im using kamailio with two interfaces external and internal. i need a way either to : * enable topoh hiding only when outgoing interface is external ( mask contact and Via ip only when ougoing interface is external * or if it is not possible to enable it only in one direction.i want to know how to configure dynamic(for example in xavp or avp) ip to put in Contact and Via when topoh is enabled. i see that the 'mask_ip' parameter of topoh module is a string. so we can not set a dynamic value here unfortunately. Thanks

1 year, 2 months

ACK on RE-Invite is send to UAC NATed Internal port instead of public port

by Angelo Sipper

Hi, My setup has: (TLS)UAC 77.1.1.1 -> (TLS)Kamailio 17.17.17.211 (UDP) -> (UDP)Kamailio 17.17.17.181 (UDP) -> Carrier(UDP) Both Kamailio are 4.3 with minor modifications on default cfg, and Topoh and TLS modules are used. I am having an issue on some outbound calls from nated UACs. On these calls our SBC sometimes receives reverse invites from the carrier side within the call. When this happens, my SBC(17.17.17.211) sends the invite to UAC and the UAC sends back 200 OK (SDP). Unfortunately my SBC(17.17.17.211) sends back the ACK not to the correct UAC public port but instead to the UAC internal port making the call to crash with several retries from my SBC to send 200 OK as ACK was never received from UAC! If you look the below traces of reverse invite past within the call, the reinvite has port private 20125 and alias the public port 2314 of UAC but the ACK bellow is send to 20125 and not to 2314 2023/01/26 09:48:30.668634 17.17.17.181:5060 -> 17.17.17.211:5060 INVITE sip:301234567890@77.1.1.1:20125;alias=77.1.1.1~2314~1 SIP/2.0 Via: SIP/2.0/UDP 17.17.17.181;branch=z9hG4bK7b5d.78276307977b5b2776919ce1f1e76d49.0 From: <sip:300987654321@sip.mydomain.com>;tag=gK0e80b4b9 To: "301234567890" <sip:301234567890@sip.mydomain.com>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 INVITE Max-Forwards: 69 Allow: INVITE,ACK,CANCEL,BYE,INFO,PRACK,UPDATE,OPTIONS Accept: application/sdp, application/isup, application/dtmf, application/dtmf-relay, multipart/mixed Supported: timer Session-Expires: 600;refresher=uas Min-SE: 90 Content-Length: 297 Content-Disposition: session; handling=required Content-Type: application/sdp Route: <sip:17.17.17.211;lr;ftag=07ece97c;vsf=AAAAAFpUAgECBwAACnAGAW5FUF4ZXUdDUUhEX1hRUC5ldQ--;vst=AAAAAAAAAAAAAAAAAAAAAABCXkYAQkdeVEJDQVtSVBRQRTYw;did=5fc.669;nat=yes> Contact: <sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181> v=0 o=Sonus_UAC 14218 13519 IN IP4 14.1.1.30 s=SIP Media Capabilities c=IN IP4 14.1.1.30 t=0 0 m=audio 18600 RTP/AVP 8 18 101 a=maxptime:20 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:18 annexb=no a=fmtp:101 0-15 a=sendrecv a=rtcp:18601 2023/01/26 09:48:30.679743 17.17.17.211:5060 -> 17.17.17.181:5060 SIP/2.0 100 trying -- your call is important to us Via: SIP/2.0/UDP 17.17.17.181;branch=z9hG4bK7b5d.78276307977b5b2776919ce1f1e76d49.0;rport=5060 From: <sip:300987654321@sip.mydomain.com>;tag=gK0e80b4b9 To: "301234567890" <sip:301234567890@sip.mydomain.com>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 INVITE Server: Supervoice Content-Length: 0 2023/01/26 09:48:30.740803 17.17.17.211:5060 -> 77.1.1.1:2314 INVITE sip:301234567890@77.1.1.1:20125 SIP/2.0 Via: SIP/2.0/UDP 17.17.17.211;branch=z9hG4bK7b5d.90b692fac0d1cc8a2ac460a67a02aec9.0 Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.78276307977b5b2776919ce1f1e76d49.0 From: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 To: "301234567890" <sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 INVITE Max-Forwards: 68 Allow: INVITE,ACK,CANCEL,BYE,INFO,PRACK,UPDATE,OPTIONS Accept: application/sdp, application/isup, application/dtmf, application/dtmf-relay, multipart/mixed Supported: timer Session-Expires: 600;refresher=uas Min-SE: 90 Content-Length: 297 Content-Disposition: session; handling=required Content-Type: application/sdp Contact: <sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181> v=0 o=Sonus_UAC 14218 13519 IN IP4 14.1.1.28 s=SIP Media Capabilities c=IN IP4 14.1.1.28 t=0 0 m=audio 13288 RTP/AVP 8 18 101 a=maxptime:20 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:18 annexb=no a=fmtp:101 0-15 a=sendrecv a=rtcp:13289 2023/01/26 09:48:30.893512 77.1.1.1:2314 -> 17.17.17.211:5060 SIP/2.0 100 Trying Via: SIP/2.0/UDP 17.17.17.211;branch=z9hG4bK7b5d.90b692fac0d1cc8a2ac460a67a02aec9.0 Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.78276307977b5b2776919ce1f1e76d49.0 To: "301234567890" <sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c From: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 INVITE Content-Length: 0 2023/01/26 09:48:31.026742 77.1.1.1:2314 -> 17.17.17.211:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 17.17.17.211;branch=z9hG4bK7b5d.90b692fac0d1cc8a2ac460a67a02aec9.0 Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.78276307977b5b2776919ce1f1e76d49.0 Require: timer Contact: <sip:301234567890@77.1.1.1:20125> To: "301234567890"<sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c From: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 INVITE Session-Expires: 600;refresher=uas Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE, UPDATE Content-Type: application/sdp Supported: replaces, timer User-Agent: 3CXPhoneSystem 18.0.6.905 (905) Content-Length: 259 v=0 o=3cxPS 792019937001472 2393157908037634 IN IP4 77.1.1.1 s=3cxPS Audio call c=IN IP4 77.1.1.1 t=0 0 m=audio 9054 RTP/AVP 8 18 101 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=sendrecv 2023/01/26 09:48:31.093656 17.17.17.211:5060 -> 17.17.17.181:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.78276307977b5b2776919ce1f1e76d49.0 Require: timer Contact: <sip:301234567890@77.1.1.1:20125> To: "301234567890" <sip:301234567890@sip.mydomain.com>;tag=07ece97c From: <sip:300987654321@sip.mydomain.com>;tag=gK0e80b4b9 Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 INVITE Session-Expires: 600;refresher=uas Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE, UPDATE Content-Type: application/sdp Supported: replaces, timer User-Agent: 3CXPhoneSystem 18.0.6.905 (905) Content-Length: 276 v=0 o=3cxPS 792019937001472 2393157908037634 IN IP4 14.1.1.28 s=3cxPS Audio call c=IN IP4 14.1.1.28 t=0 0 m=audio 13278 RTP/AVP 8 18 101 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:18 annexb=no a=sendrecv a=rtcp:13279 2023/01/26 09:48:31.254591 17.17.17.181:5060 -> 17.17.17.211:5060 ACK sip:301234567890@77.1.1.1:20125 SIP/2.0 Via: SIP/2.0/UDP 17.17.17.181;branch=z9hG4bK7b5d.48f49235d45a0f6f9efdad9d6d8224bd.0 From: <sip:300987654321@sip.mydomain.com>;tag=gK0e80b4b9 To: "301234567890" <sip:301234567890@sip.mydomain.com>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 ACK Max-Forwards: 69 Content-Length: 0 Route: <sip:17.17.17.211;lr;ftag=07ece97c;vsf=AAAAAFpUAgECBwAACnAGAW5FUF4ZXUdDUUhEX1hRUC5ldQ--;vst=AAAAAAAAAAAAAAAAAAAAAABCXkYAQkdeVEJDQVtSVBRQRTYw;did=5fc.669;nat=yes> Contact: <sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181> 2023/01/26 09:48:31.260901 17.17.17.211:5060 -> 77.1.1.1:20125 ACK sip:301234567890@77.1.1.1:20125 SIP/2.0 Via: SIP/2.0/UDP 17.17.17.211;branch=z9hG4bK7b5d.e8fb34e79623843d516ae77257014e2d.0 Via: SIP/2.0/UDP 17.17.17.181;rport=5060;branch=z9hG4bK7b5d.48f49235d45a0f6f9efdad9d6d8224bd.0 From: <sip:300987654321@17.17.17.211:5060>;tag=gK0e80b4b9 To: "301234567890" <sip:MyTrunk@77.1.1.1:20125>;tag=07ece97c Call-ID: 1q5nE37RGZ8a8ChI6rqShw.. CSeq: 29227 ACK Max-Forwards: 68 Content-Length: 0 Contact: <sip:atpsh-b5-62dfd3a3-cd5ed-1d354@17.17.17.181> Any help will be much appreciated. Thank you! Regards, Angelo

1 year, 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 January 2023