sr-users

sr-users@lists.kamailio.org

37 participants
37510 discussions

Limiting Video calls(Volte to video conversion)
by dushy 28 Aug '24

28 Aug '24

Hello All, I am trying to limiting the number of video calls (converting Volte to Vilte). To reduce traffic on the enodeb. Its like if there are 10 volte calls going on then I should be able to limit the number calls that can be converted to Vilte. I tried to write a route in kamailio_pcscf.cfg using module ims_dialog. But it doesnt work and get some errors while doing a modparam. Tried another method of counting eRAB at eNB (ENBUEID and ERABID pair with qci-2). This worked, but after sometime the extra call got established. Looks like traffic is going through qci 9 bearer. Is there any method where we can achieve this. Thanks in Advance. Regards, Dushyanth

1 0

Re: certificate verify failed (sni: unknown) integration with ms teams
by Muhammad Sohaib 27 Aug '24

27 Aug '24

Hi Batanai, After disabling #!define WITH_NAT in Kamailio, calls from the Asterisk endpoint to Microsoft Teams are functioning correctly. Both inbound and outbound calls exhibit proper two-way audio and no disconnection issues but there is no Bye when hangup from ms teams. However, I am encountering a problem with outbound calls originating from Microsoft Teams. When a call is placed from MS Teams, the recipient's phone rings as expected. Once the call is answered, Microsoft Teams disconnects the call immediately. The root of the issue seems to be that the ACK message is not being sent or received properly. As a result, Microsoft Teams does not receive the ACK, leading to an immediate call termination. Additionally, Asterisk does not receive a BYE message from Kamailio. *Summary of the Issue:* - *Inbound Calls*: From Asterisk to MS Teams work fine, with full audio and no disconnections but no BYE from ms teams. - *Outbound Calls*: From MS Teams to Asterisk result in the call being disconnected immediately after being answered due to a missing ACK, and Asterisk does not receive a BYE message. Thanks, On Tue, Aug 27, 2024 at 5:45 PM Batanai Musiiwa <batanai.musiiwa(a)etel.co.zw> wrote: > Hi @ > Muhammad. May you advise if the calls are disconnecting in either > direction? > > ; > > On Tue, Aug 27, 2024 at 11:05 AM Muhammad Sohaib via sr-users < > sr-users(a)lists.kamailio.org> wrote: > >> Hi everyone, >> >> Thank you all for your kind help with the TLS configuration. Palany's >> suggestion worked flawlessly, and now both inbound and outbound calls are >> functioning. >> >> However, I'm facing a one-way audio issue, and calls are disconnected >> after 30 seconds. I suspect this might be related to NAT. Here’s the >> current setup: >> >> *Asterisk <===> Kamailio (as SBC) <=====> MS Teams* >> >> Could this be related to my NAT configuration, or is there something else >> I should investigate? Any guidance would be greatly appreciated. >> >> Thanks again for your support! >> >> On Thu, Aug 15, 2024 at 11:02 PM palany <palany(a)advancedzim.com> wrote: >> >>> >>> >>> Hi Muhammad >>> >>> >>> >>> Can you try your tls cfg as below and make sure your certificates have >>> the right permissions. >>> >>> >>> >>> [server:default] >>> >>> method = TLSv1.2+ >>> >>> verify_certificate = no >>> >>> require_certificate = no >>> >>> private_key = /etc/letsencrypt/live/MYDOMAIN/privkey.pem >>> >>> certificate = /etc/letsencypt/live/MYDOMAIN/fullchain.pem >>> >>> >>> >>> [client:default] >>> >>> method = TLSv1.2+ >>> >>> verify_certificate = no >>> >>> require_certificate = no >>> >>> private_key = /etc/letsencrypt/live/MYDOMAIN/privkey.pem >>> >>> certificate = /etc/letsencrypt/live/MYDOMAIN/fullchain.pem >>> >>> *From:* Muhammad Sohaib via sr-users [mailto:sr-users@lists.kamailio.org] >>> >>> *Sent:* Thursday, 15 August 2024 3:46 PM >>> *To:* Kamailio (SER) - Users Mailing List >>> *Cc:* Muhammad Sohaib >>> *Subject:* [SR-Users] certificate verify failed (sni: unknown) >>> integration with ms teams >>> >>> >>> >>> Dear all, >>> >>> >>> >>> Trying to integrate Kamailio with MS Teams by following >>> https://skalatan.de/en/blog/kamailio-sbc-teams >>> >>> >>> >>> kamcmd dispatcher.list | egrep "URI|FLAGS" >>> >>> >>> URI: sip: >>> sip.pstnhub.microsoft.com;transport=tls >>> FLAGS: IP >>> URI: sip: >>> sip2.pstnhub.microsoft.com;transport=tls >>> FLAGS: IP >>> URI: sip: >>> sip3.pstnhub.microsoft.com;transport=tls >>> FLAGS: IP >>> >>> >>> >>> Kamailio Logs: >>> >>> /usr/local/sbin/kamailio[412158]: INFO: <script>: Sent out tm request: >>> OPTIONS sip:sip.pstnhub.microsoft.com;transport=tls SIP/2.0#015#012 >>> Via: SIP/2.0/TLS >>> x.x.x.x:5061;branch=z9hG4bK5dad.92de50b2000000000000000000000000.0#015#012 >>> To: <sip:sip.pstnhub.microsoft.com;transport=tls>#015#012 >>> From: <sip:test.mytest.com >>> >;tag=5d0939b82abe9b1bbf185d963b6e6c88-edeb3c71#015#012 >>> CSeq: 10 OPTIONS#015#012 >>> Call-ID: 2db6bede5631d9b6-412158(a)88.99.244.106#015#012 >>> <http://2db6bede5631d9b6-412158@88.99.244.106#015%23012> >>> Max-Forwards: 70#015#012Content-Length: 0#015#012 >>> User-Agent: kamailio (5.8.2 (x86_64/linux)) >>> >>> /usr/local/sbin/kamailio[412165]: ERROR: tls [tls_server.c:1312]: >>> tls_h_read_f(): protocol level error >>> /usr/local/sbin/kamailio[412165]: ERROR: tls [tls_util.h:49]: >>> tls_err_ret(): TLS write:error:0A000086:SSL routines::certificate verify >>> failed (sni: unknown) >>> /usr/local/sbin/kamailio[412165]: ERROR: tls [tls_server.c:1316]: >>> tls_h_read_f(): src addr: 52.114.75.24:5061 >>> /usr/local/sbin/kamailio[412165]: ERROR: tls [tls_server.c:1319]: >>> tls_h_read_f(): dst addr: x.x.x.x:0 >>> /usr/local/sbin/kamailio[412165]: ERROR: <core> [core/tcp_read.c:1524]: >>> tcp_read_req(): ERROR: tcp_read_req: error reading - c: 0x7fa74d265d40 r: >>> 0x7fa74d265e68 (-1) >>> >>> >>> tls.cfg: >>> >>> [server:default] >>> method = TLSv1.2+ >>> verify_certificate = yes >>> require_certificate = yes >>> private_key = /etc/letsencrypt/live/test.mytest.com/privkey.pem >>> certificate = /etc/letsencrypt/live/test.mytest.com/fullchain.pem >>> ca_list = /etc/letsencrypt/live/test.mytest.com/fullchain.pem >>> server_name = test.mytest.com >>> >>> [client:default] >>> method = TLSv1.2+ >>> verify_certificate = yes >>> require_certificate = yes >>> private_key = /etc/letsencrypt/live/test.mytest.com/privkey.pem >>> certificate = /etc/letsencrypt/live/test.mytest.com/fullchain.pem >>> ca_list = /etc/letsencrypt/live/test.mytest.com/fullchain.pem >>> >>> Please suggest what I am missing. >>> >>> --- >>> >>> Thanks, >>> >> >> >> -- >> Thanks, >> __________________________________________________________ >> 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: >> > -- Thanks,

1 0

certificate verify failed (sni: unknown) integration with ms teams
by Muhammad Sohaib 27 Aug '24

27 Aug '24

Dear all, Trying to integrate Kamailio with MS Teams by following https://skalatan.de/en/blog/kamailio-sbc-teams kamcmd dispatcher.list | egrep "URI|FLAGS" URI: sip:sip.pstnhub.microsoft.com ;transport=tls FLAGS: IP URI: sip:sip2.pstnhub.microsoft.com ;transport=tls FLAGS: IP URI: sip:sip3.pstnhub.microsoft.com ;transport=tls FLAGS: IP Kamailio Logs: /usr/local/sbin/kamailio[412158]: INFO: <script>: Sent out tm request: OPTIONS sip:sip.pstnhub.microsoft.com;transport=tls SIP/2.0#015#012 Via: SIP/2.0/TLS x.x.x.x:5061;branch=z9hG4bK5dad.92de50b2000000000000000000000000.0#015#012 To: <sip:sip.pstnhub.microsoft.com;transport=tls>#015#012 From: <sip:test.mytest.com >;tag=5d0939b82abe9b1bbf185d963b6e6c88-edeb3c71#015#012 CSeq: 10 OPTIONS#015#012 Call-ID: 2db6bede5631d9b6-412158(a)88.99.244.106#015#012 Max-Forwards: 70#015#012Content-Length: 0#015#012 User-Agent: kamailio (5.8.2 (x86_64/linux)) /usr/local/sbin/kamailio[412165]: ERROR: tls [tls_server.c:1312]: tls_h_read_f(): protocol level error /usr/local/sbin/kamailio[412165]: ERROR: tls [tls_util.h:49]: tls_err_ret(): TLS write:error:0A000086:SSL routines::certificate verify failed (sni: unknown) /usr/local/sbin/kamailio[412165]: ERROR: tls [tls_server.c:1316]: tls_h_read_f(): src addr: 52.114.75.24:5061 /usr/local/sbin/kamailio[412165]: ERROR: tls [tls_server.c:1319]: tls_h_read_f(): dst addr: x.x.x.x:0 /usr/local/sbin/kamailio[412165]: ERROR: <core> [core/tcp_read.c:1524]: tcp_read_req(): ERROR: tcp_read_req: error reading - c: 0x7fa74d265d40 r: 0x7fa74d265e68 (-1) tls.cfg: [server:default] method = TLSv1.2+ verify_certificate = yes require_certificate = yes private_key = /etc/letsencrypt/live/test.mytest.com/privkey.pem certificate = /etc/letsencrypt/live/test.mytest.com/fullchain.pem ca_list = /etc/letsencrypt/live/test.mytest.com/fullchain.pem server_name = test.mytest.com [client:default] method = TLSv1.2+ verify_certificate = yes require_certificate = yes private_key = /etc/letsencrypt/live/test.mytest.com/privkey.pem certificate = /etc/letsencrypt/live/test.mytest.com/fullchain.pem ca_list = /etc/letsencrypt/live/test.mytest.com/fullchain.pem Please suggest what I am missing. --- Thanks,

5 5

I have mo media and I must park
by Alexandru Covalschi 27 Aug '24

27 Aug '24

Hello list! Please help me understand if putting my b2bua in sensory deprivation is actually the best approach to punish it for sole reason of its existence. The background of this horror story is pretty cliche, call center needs a way to infinitely expand, so I'm building a scaling telephony core. Our main protagonist is an innocent b2bua with a very grounded backstory: step 0: receive external instruction to start a call step 1: originate step 2: park step 3: play moh until: - - a) told to pass it to other component - - b) told to hang up - - c) hang up on local timeout A simplified diagram of the call flow looks something like this (repeating names are same components): ### Signaling ### Remote Destination ^ Kamailio-external ^ Freeswitch-originator V Freeswitch- queue V Kamailio-local V Agent ### end of signaling ### ### Media ### Remote Destination ^ Rtpengine-external ^ Freeswitch-originator V Freeswitch-queue V Rtpengine- local V Agent ### end of media ### Due to specifics of the setting, re-negotiating the media and any non-essential signaling with remote destination is a very much last resort. And, as you can imagine, after step3a (pass it to other component), the character development of Freeswitch-originator service stops completely. Well, at least it is doing an honest job by playing the music on hold, which a little bit justifies its presence on the media path. But not for long. In the world of near future, pull request number 3956 is merged with the master branch, exposing the rtpengine API and leaving me no reason not to move MoH to a kernel media player. At this moment I feel a wild urge to get rid of Freeswitch-originator at all, but then I read the sources for mohq and dialog to remind myself that Kamailio is a proxy and proxies can't do this... So I fill b2bua's dialplan with 387.44 million lines of hateful comments and remind it to rcvonly every time it tries to warn the others about the grim fate. When the queue designates an agent to his call, theoretically I don't even need the second freswitch as well - if agen't media session has been established (sometimes ICE take tooo long) with Rtpengine- local, I can bridge their media sessions using publish and subscribe. I'd like to ask your opinion, list: do you see any plotholes potential issues with such deisgn? I'd honestly like to set Freeswitch to bypass-media, so it wont' waste ports and cpu for nothing at all. Are there any issues if I add body for the iniitial invite in the request_route as if it was received in there? Maybe there's a better way, overall? Any critique is welcome! Thank you -- AC

1 0

How to invoke RTPengine for re-Invite 200 OK within dialog
by Shah Hussain Khattak 27 Aug '24

27 Aug '24

Hello Experts, I need your advice on the following issue if you can kindly help. I am working on a hold call flow: UA - > Kamailio (RTP Engine) - > FS initial call establishes fine, RTP engine is invoked and SDP media IP is modified correctly. Then 1. I am receiving a hold re-invite with a send-only 2. I see Kamailio is changing the media IP in the SDP (with my RTP engine IP) when it sends the Invite to my core FS server. 3. FS sends 200 OK with a=recvonly 4. Kamailio relays the message as it is to the other leg. can someone advise me, on how can I invoke rtpengine at step 4, so the SDP is sent with my media server IP in the 200 OK? --- 200 OK from FS ---- SIP/2.0 200 OK Via: SIP/2.0/UDP 13.54.01.02:5060;branch=z9hG4bKd2e8.8a573af8d927f67c1db4550676f8be88.0;i=1 Via: SIP/2.0/TCP 192.168.10.117:51280;received=218.33.01.02;rport=51280;branch=z9hG4bKPj7d1d8968830d4ed3922eec7da7cdc17c;alias Record-Route: <sip:13.54.01.02:5060;r2=on;lr=on> Record-Route: <sip:13.54.01.02;transport=tcp;r2=on;lr=on> From: <sip:0403225908@trunk.xyz.corp>;tag=6a180ffa7f824972a2c59ba47f293acb To: <sip:+61285038000@trunk.xyz.corp>;tag=DZrpcpgS1BDKF Call-ID: 4154062196634c34a2dbcb6b612bf44c CSeq: 12263 INVITE Contact: <sip:+61285038000@54.88.54.88:5060;transport=udp> User-Agent: UserAgentX/v1.0 Accept: application/sdp Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY Require: timer Supported: timer, path, replaces Session-Expires: 1800;refresher=uac Content-Type: application/sdp Content-Disposition: session Content-Length: 266 v=0 o=FreeSWITCH 1724635755 1724635757 IN IP4 54.88.54.88 s=FreeSWITCH c=IN IP4 54.88.54.88 t=0 0 m=audio 21202 RTP/AVP 8 101 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=recvonly a=ptime:20 a=rtcp:21203 IN IP4 54.88.54.88 --- 200 OK relayed towards the UA ---- 2024/08/26 17:22:39.923639 172.16.8.126:5060 -> 218.33.78.33:51280 SIP/2.0 200 OK Via: SIP/2.0/TCP 192.168.10.117:51280;received=218.33.01.02;rport=51280;branch=z9hG4bKPj7d1d8968830d4ed3922eec7da7cdc17c;alias Record-Route: <sip:13.54.01.02:5060;r2=on;lr=on> Record-Route: <sip:13.54.01.02;transport=tcp;r2=on;lr=on> From: <sip:0403225908@trunk.xyz.corp>;tag=6a180ffa7f824972a2c59ba47f293acb To: <sip:+61285038000@trunk.xyz.corp>;tag=DZrpcpgS1BDKF Call-ID: 4154062196634c34a2dbcb6b612bf44c CSeq: 12263 INVITE Contact: <sip:+61285038000@54.88.54.88:5060;transport=udp> User-Agent: UserAgentX/v1.0 Accept: application/sdp Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY Require: timer Supported: timer, path, replaces Session-Expires: 1800;refresher=uac Content-Type: application/sdp Content-Disposition: session Content-Length: 266 v=0 o=FreeSWITCH 1724635755 1724635757 IN IP4 54.88.54.88 s=FreeSWITCH c=IN IP4 54.88.54.88 t=0 0 m=audio 21202 RTP/AVP 8 101 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=recvonly a=ptime:20 a=rtcp:21203 IN IP4 54.88.54.88 my configs for within dialog route: ##### route[WITHINDLG] { append_hf("X-Test-Header: route_WITHINDLG\r\n"); if (has_totag()) { if (loose_route()) { if (is_method("BYE")) { setflag(FLT_ACC); # do accounting ... setflag(FLT_ACCFAILED); # ... even if the transaction fails } if (is_method("ACK")) { xlog("L_INFO", "Relaying ACK\n"); } if (is_method("INVITE|UPDATE")) { if (has_body("application/sdp") && search_body("m=image") && search_body("T38")) { xlog("L_INFO", "T.38 re-INVITE detected, skipping rtpengine invocation\n"); } else { xlog("L_INFO", "Non-T.38 INVITE detected, invoking rtpengine\n"); rtpengine_manage("replace-origin replace-session-connection"); } } route(RELAY); } else { if (is_method("SUBSCRIBE") && uri == myself) { route(PRESENCE); exit; } if (is_method("ACK")) { if (t_check_trans()) { t_relay(); exit; } else { exit; } } sl_send_reply("404","Not here"); } exit; } } ##### looking forward to your usual guidance. Thank you! Regards, Shah

2 2

socket names for command line parameter "listen"
by Xenofon Karamanos 23 Aug '24

23 Aug '24

Hello all, I wanted to inform you about an upcoming change regarding the syntax we use for defining socket names in the listen (-l) command line argument. Current Syntax: -l udp:10.10.10.10:5060/11.11.11.11:5060 Proposed Options: 1. -l udp:10.10.10.10:5060/11.11.11.11:5060=s1 2. -l s1=udp:10.10.10.10:5060/11.11.11.11:5060 ( A draft PR about this option can be found in https://github.com/kamailio/kamailio/pull/3954) [https://opengraph.githubassets.com/69f8a4a1d2c8988372b4942f84bde95de94502d2…]<https://github.com/kamailio/kamailio/pull/3954> main: Add support for naming socket in cli by xkaraman · Pull Request #3954 · kamailio/kamailio<https://github.com/kamailio/kamailio/pull/3954> Pre-Submission Checklist Commit message has the format required by CONTRIBUTING guide Commits are split per component (core, individual modules, libs, utils, ...) Each component has a single... github.com Please note that the socket name (s1) in both options is/should be optional. The change will allow for better clarity and flexibility when defining sockets, particularly when a name needs to be assigned and match the config file style. I would appreciate your feedback on which syntax you find more intuitive or any concerns you might have with these options. Your input is important to ensure a smooth transition. Best regards, Xenofon

2 2

Kamailio cluster options
by Ali Taher 22 Aug '24

22 Aug '24

Hello all, I'm using Kamailio as SIP redirect (act as routing decision for SBC) depending mainly on sqlops and db_postgres modules, and it's working perfectly. What I need now is to have a kind of cluster of Kamailio servers for high availability purpose. What is the best option for me ? BR

2 1

push server tcp problem
by Bernd Krueger-Knauber 20 Aug '24

20 Aug '24

Hi, I implemented an apple and android push server/proxy with kamailio 5.8.1. The server/proxy is transparent. It works fine with UDP, since the registration after the push comes from the same ip and port. So t_continue works without problems. (We use the new registration as signal thet the phone is ready) If we use tcp at the client, he gets the push, wakes up and send the new registration on an other port. The SIP stack uses now an other connection. t_continue fails, because it uses the old data of the original invite acccording to the first registration. Is it possible to change the stored connection values according to the new registration data? Best regards, Bernd

2 2

low performance with udp_children and async_workers
by elhar.mohamed＠gmail.com 19 Aug '24

19 Aug '24

Hello, Based on business requirements, 35% of invites should be handled by async_workers and 65% with be handled by main children. The target is 1500cps. I'm using the following conf : children=64 async_worker=128 when doing performance tests using SIPp, I figured out the 1500cps is well supported by the conf above, but when I updated the data in database to not use anymore async workers, the cps is getting decreased and it was between 200 and 500. This a client requirements is to be able to enable/disable feature that needs to be handled by async workers. Could you please help me on this? Thanks in advance

4 12

Inbound call to webRTC failing with TCP/TLS connection (id: 0) for WebSocket could not be found
by hollis.rhonda＠gmail.com 16 Aug '24

16 Aug '24

We're seeing an issue where some webRTC clients are not receiving inbound calls. Kamailio logs show the following error: WARNING: {1 609669922 INVITE BW152025538120824-895739618(a)10.103.43.11}: <core> [core/msg_translator.c:3007]: via_builder(): TCP/TLS connection (id: 0) for WebSocket could not be found ERROR: {1 609669922 INVITE BW152025538120824-895739618(a)10.103.43.11}: <core> [core/msg_translator.c:2086]: build_req_buf_from_sip_req(): could not create Via header ERROR: {1 609669922 INVITE BW152025538120824-895739618(a)10.103.43.11}: tm [t_fwd.c:484]: prepare_new_uac(): could not build request ERROR: {1 609669922 INVITE BW152025538120824-895739618(a)10.103.43.11}: tm [t_fwd.c:1764]: t_forward_nonack(): failure to add branches DEBUG: {1 609669922 INVITE BW152025538120824-895739618(a)10.103.43.11}: tm [t_funcs.c:358]: t_relay_to(): t_forward_nonack returned error -2 (-2) DEBUG: {1 609669922 INVITE BW152025538120824-895739618(a)10.103.43.11}: tm [t_funcs.c:376]: t_relay_to(): -2 error reply generation delayed It seems to be happening after the client has been connected to Kamailio for more than 24 hours. The socket connection details look correct in the external DB and in the output of ws.dump, core.tcp_list, and ul.dump. A restart of Kamailio or a reload of the webRTC client, triggering a new websocket connection, will clear the issue. However, we haven't been able to determine exactly when and why a client ends up in this state. While a client is in this state, REGISTER requests are still handled successfully, they can make outbound calls and TCP keepalives from the client are working. I'm still working on trying to debug this with GDB so I can see what the value of send_info is in https://github.com/kamailio/kamailio/blob/master/src/core/msg_translator.c#…, but I wasn't having luck with multiple child processes running, and now my client has reloaded and is working again. I've restarted Kamailio with a single child process, so when it does start failing again, I may have better luck with GDB. Any thoughts on what might be causing clients to get into this state? Whatever additional information I can provide that might help, I'm happy to share. Thanks!

2 4

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