sr-users

sr-users@lists.kamailio.org

28 participants
37382 discussions

Info: Registration to Kamailio World 2023 is open!
by Daniel-Constantin Mierla 21 Feb '23

21 Feb '23

Hello, a quick note to the community forums to announce that the registration for the next Kamailio World Conference (June 5-7, 2022, in Berlin, Germany) is now open! The event returns to an in-person conference format, at the same wonderful location in the city center of Berlin! More details are available at: * https://www.kamailioworld.com/k2023/registration/ Call for presentations is also open, there is already a group of very interesting submissions, we aim to publish details about them in the near future. Looking forward to meeting many of you in Berlin! 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 Kamailio Advanced Training - Online - March 27-30, 2023 - www.asipto.com

2 2

topos breaking route set on hairpin calls?
by Benoît Panizzon 20 Feb '23

20 Feb '23

Hi Having this situation while elaborating topos in lab. * Kamailio Registration Instance with topos enabled where customers are registered. * Kamailio Core Instance with Dialogue enabled and handling interconnections. Calls in transit from customer to IC work flawlessly, topos does what it should, hides and restores headers needed on the core. But I have run into an issue with customer calling another customer on same registrar instance. To generate a CDR with diaglogue and for decision where to route the calls to (registrar is kept simple and only handles registrations and locations), those calls are also routed via core. This works as long as PRACK is disabled. When PRACK is enabled and CPE B is requesting 100rel, the PRACK send from CPE A has no route set (it was removed by topos). Therefore the PRACK only makes it to the core who then does not know where to route that PRACK. It looks like topos on the REG only restores ONE Route pointing to the core (maybe because the 2nd one pointed to itself?) header when restoring them. I have attempted to spam more record_route() here and there in the config of the core and the registrar to try to force creation of route headers, but failed. Is this a known limitation of using topos? -- Mit freundlichen Grüssen -Benoît Panizzon- @ HomeOffice und normal erreichbar -- 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 ______________________________________________________

2 4

Re: OT: MS Teams source IP address ranges
by Henning Westerholt 20 Feb '23

20 Feb '23

Hi Jon, you could of course try to add some heuristic, in the end the used IPs are a smaller sub-set. But to just quote from the official docs, it seems to be pretty clear: "You need to open ports for all these IP address ranges in your firewall to allow incoming and outgoing traffic to and from the addresses for signaling." Cheers, Henning ________________________________ From: Jon Bonilla (Manwe) Sent: Monday, February 20, 2023 15:49 To: Henning Westerholt; Kamailio (SER) - Users Mailing List Subject: Re: [SR-Users] OT: MS Teams source IP address ranges El Mon, 20 Feb 2023 13:06:30 +0000 Henning Westerholt <hw(a)gilawa.com> escribió: > Hello, > > correct me if I am wrong, but the second group of addresses ("/16") is > included in the first group ("/14"), right? > > Regarding the large IP scope, this is the way Microsoft designed it, > unfortunately. There is not that much what you can do about. > > Right. Didn't check the masks. they all were 16 in my mind :) So, if I add those ranges in the permissions table my only way of avoiding spoofed calls is certificate validation? I'm already doing that and also checking the company domain and ms account email address. Just wanted to be sure that nothing "essential" was missing. -- PekePBX, the multitenant PBX solution https://pekepbx.com

1 0

sendig 4 byte udp nat pings
by Bernd Krueger-Knauber 18 Feb '23

18 Feb '23

Hi, maybe I'm stupid, but I can not find out how to send 4 byte UDP NAT packets to the sip server. loadmodule "nathelper.so" modparam("nathelper", "natping_interval", 15) modparam("nathelper|registrar", "received_avp", "$avp(s:rcv)") I'm a absolute beginner with kamailio and the page about the nathelper Module is not really helpful. At the moment no pings are sendet. But I receive 4 byte packets from the sip server. After 15 minutes my calls are cancelled because of the missing pings. Without proxy, the phone send the pings directly to the sip server and the call stays alive. When I experiment with some other nathelper settings, kamailo start results in errors. Any help would be appreciated. Best regards, Bernd

3 11

enable topology hiding on one side or dynamic ip in topoh module Contact and Via Header
by Patrick Karton 17 Feb '23

17 Feb '23

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

4 8

Calling uac_replace multiple times?
by Benoît Panizzon 17 Feb '23

17 Feb '23

Hey all I have started using the uac module to be able to mirror username changes on both legs of a call. But now I found an issue: Assume this situation: Call IC => Customer IC is e164, Customer wants 'local' numbers. IC From: +41991234567 => Customer From: 0991234567 uac_replace_from("sip:" + $avp(from_local) + "@" + $(fu{uri.host})); Customer is absent, after timeout in failure_route call is dispatched to Voicemail Server, which is configured for e164 numbers: uac_replace_from("sip:" + $avp(from_e164) + "@" + $(fu{uri.host})); But then uac complains: replace_uri(): Already called uac_replace for this dialog Why isn't just the most from version kept and used? -- Mit freundlichen Grüssen -Benoît Panizzon- @ HomeOffice und normal erreichbar -- 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 ______________________________________________________

2 1

TLS version and cipher from WSS
by Michal Hajek 17 Feb '23

17 Feb '23

Hi, I can log incoming SIPS TLS version and cipher with PV $tls_version and $tls_cipher_info. How can I log these variables on incoming HTTP/WebSocket. Thanks Michal H.

2 2

Identify error in log
by Евгений Мастратов 16 Feb '23

16 Feb '23

Hello colleagues. I'm starting to use Kamailio for educational purposes, as an IMS test zone. Registration of subscribers, calls go successfully, but the following errors are constantly pouring into the log: Feb 16 14:40:46 ct-pcscf /usr/local/sbin/kamailio[2849]: ERROR: <core> [core/rvalue.c:1378]: int_intop2(): rv div by 0 Feb 16 14:40:46 ct-pcscf /usr/local/sbin/kamailio[2849]: ERROR: <core> [core/rvalue.c:1378]: int_intop2(): rv div by 0 Feb 16 14:40:46 ct-pcscf /usr/local/sbin/kamailio[2849]: ERROR: <core> [core/rvalue.c:2381]: rval_expr_eval(): rval expression evaluation failed (735,15-735,55) Feb 16 14:40:46 ct-pcscf /usr/local/sbin/kamailio[2849]: ERROR: <core> [core/rvalue.c:2381]: rval_expr_eval(): rval expression evaluation failed (735,15-735,55) Feb 16 14:40:46 ct-pcscf /usr/local/sbin/kamailio[2849]: ERROR: <core> [core/lvalue.c:386]: lval_assign(): rval expression evaluation failed (735,15-735,55) Feb 16 14:40:46 ct-pcscf /usr/local/sbin/kamailio[2849]: ERROR: <core> [core/lvalue.c:386]: lval_assign(): rval expression evaluation failed (735,15-735,55) Apparently they don’t carry anything critical, but they clog the log, natively I can’t understand the meaning of the errors. Please tell me what they mean and how to eliminate their cause? If necessary, I will provide the pcscf config.

2 1

uac reg reload frequency
by Dmytro M 16 Feb '23

16 Feb '23

When you do "kamcmd uac.reg_reload" frequently enough, you'll get an error: # kamcmd uac.reg_reload error: 500 - Failed to shift records - check log messages Logs: ERROR: uac [uac_reg.c:416]: uac_reg_ht_shift(): shifting in-memory table is not possible in less than 150 secs What is the reason behind 150 sec limitation for how frequent reloads can be done? Is it configurable in any way? Use case: Remote app needs to disable uac registration. It deletes record in DB and calls kamcmd uac.reg_reload to activate the change. With 150 sec limit it can't apply DB changes immediately. Please advise. Thanks, Dmytro

2 2

ACK on RE-Invite is send to UAC NATed Internal port instead of public port
by Angelo Sipper 15 Feb '23

15 Feb '23

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

2 5

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