sr-users February 2024

sr-users@lists.kamailio.org

49 participants
42 discussions

by djcsalvador＠gmail.com

I all, I'm looking into Kamailio as a solution to replace our current Presence Server in our IMS Network, but feeling a bit overwhelmed by the feature size and complexity of Kamailio. I have a few questions (some might be dumb), if you guys could help me I would appreciate. 1. As I only need Kamailio as a Presence Server (with XCAP and SIP Interface), is there a way to install only the necessary components and/or modules? Our security team would probably raise some questions if we need to install unused code on the network. For what I could investigate, the modules i would need are: * Presence * Presence_XML * Xcap_server * xhttp * RLS * Pua * database * sl * tm Am I missing something? 2- As refered on point 1, our server will need a xcap and sip interface. Some presence updates will come through XCAP, others from SIP Publish. My question is, whenever a presence update is made through XCAP interface, will the kamailio server trigger the necessary SIP Notify to notify all Subscribed users ? I ask this because this was a problem with our current supplier. 3 - our client is a bit "peeky" with performance. I found here (https://www.kamailio.org/wikidocs/kemi/performance-tests/5.2.x/#results) some performance tests, but for what i can see the test primary goal was to test the response time. Is there any resource on "requests per second"? Thanks in advance for all the help David Salvador

9 months, 1 week

Kamailio - handover between LTE and Wifi

by Christian Hahn

Hi all, While researching for Open Source IMS Services I’v found the presentation “What’s up with IMS & VoLTE?” at KamailioWorld 2018. There is a quote that raises a question: “Things, you shouldn’t expect (at least initially): ● Seamless handover between LTE and Wifi, as this requires some integration with the PGW of the LTE” My question is: Has the VoLTE <-> VoWiFi Handover been implemented in the meantime? BR Christian

9 months, 1 week

Trying to better understand pre-made IMS configs

by Enzo Damato

Hello. I am a new Kamailio user, and I have been following the instructions for setting up a new IMS system. So far, I have a system that is working with the default example configs, but I am am trying to figure out the best way to expand on these default configurations. Currently, from my reading, the pcscf and icscf have minimal configuration/customization beyond the basic setting required to get them working, and most of the configuration related to routing, features, and other typical telecom customization should be done in the scscf. Is this mostly correct? Additionally, is there a guide to the features that are required in order to get the IMS systems working above and beyond the minimal config to get Kamailio itself working, so that I know what it's safe to modify and what should be left alone? Thank you, Enzo Damato

9 months, 2 weeks

High CPU with DMQ on ARM64 (graviton) - Tuning values for DMQ worker_usleep

by Ben Kaufman

I encountered a behavior with DMQ using excessive CPU when running kamailio 5.8 on AWS Graviton processors (running in Docker on Amazon Linux 2023), even on an otherwise idle system. Finding the issue below pointed me towards using polling. I set the value for worker_usleep to 1000 as a test, and that seems to have resolved the CPU issue, but I have no idea of what a "good" value is for this setting, and 1000 was simply the example present in the documentation. My specific use case for DMQ is synchronizing USRLOC data for ~7,500 users, registering with expiration times of 60 - 300 seconds with 7 - 9 nodes on the DMQ bus. Any general recommendations on tuning values for this setting? https://github.com/kamailio/kamailio/issues/822 Regards, Kaufman

9 months, 2 weeks

PRACK RFC3262

by Social Boh

Does Kamailio support the SIP PRACK method? If yes, How? Regards -- --- I'm SoCIaL, MayBe

9 months, 2 weeks

Release_tcpconnection when using RTJSON routing with TLS

by kjartan.solli＠intility.no

Hello, I wish to use RTJSON for routing inbound calls from Kamailio to external endpoint(s), based on JSON received from my API. My rtjson setup is based on guide below, with my route(RELAY) sending Invite via t_relay(); https://wazo-platform.org/blog/kamailio-routing-with-rtjson-and-http-async-… I am including rtjson_init_routes("$var(rtjson)");, rtjson_push_routes(); & rtjson_update_branch(); in my routes. Also have defined: listen=tls:10.129.1.168:5061 advertise ${PUBLIC_IPV4}:5061 Routing from rtjson is working fine for TCP / UDP connections, however - once I try to forward an INVITE via rtjson using TLS, then the TLS connection is simply closed with Kamailio reporting "tcp_read_data(): EOF on connection". Please see logs and setup below. - tcp_reuse_port = yes, tcp_children = 8, tcp_accept_no_cl= yes & tcp_connection_lifetime=3605 - Also no success with tcp_reuse_port = no - I have HOMER setup and see here that SIP headers from the RTJSON is being used (Outbound SIP Invites is being duplicated to HOMER before connection is released) - I see no drop in traffic from my firewall As you can see from logs below, Kamailio is reusing the socket (0x7fc3ebc65060) from the exsisting connection (not new socket 0x7fc3ef70aab0). I am sending SIP Options toward the external endpoint (which is working fine), and my theory is that Kamailio is reusing the exisitng SIP OPTIONS tcp connection for the SIP INVITE and somehow close the connection when RTJSON is used (since routing without RTJSON is working fine). Any idea how to solve this? Thank you! (x.x.x.x:5061 is external endpoint) 14(43) DEBUG: rtjson [rtjson_routing.c:364]: rtjson_init_serial(): rewrite dst-uri to: [sip:x.x.x.x:5061;transport=tls] 14(43) DEBUG: rtjson [rtjson_routing.c:388]: rtjson_init_serial(): trying to set send socket to: [tls:10.129.1.168:5061] 14(43) DEBUG: <core> [core/socket_info.c:726]: grep_sock_info(): checking if host==us: 12==12 && [10.129.1.168] == [10.129.1.168] 14(43) DEBUG: <core> [core/socket_info.c:730]: grep_sock_info(): checking if port 5061 (advertise 5061) matches port 5061 ......... 14(43) DEBUG: tm [../../core/forward.h:276]: msg_send_buffer(): sending to: x.x.x.x:5061, force_socket=4, send_sock=0x7fc3ef70aab0 14(43) DEBUG: <core> [core/tcp_main.c:1741]: _tcpconn_find(): found connection by peer address (id: 9) 14(43) DEBUG: <core> [core/tcp_main.c:2627]: tcpconn_send_put(): tcp connection found (0x7fc3ebc65060), acquiring fd 14(43) DEBUG: <core> [core/tcp_main.c:2637]: tcpconn_send_put(): c=0x7fc3ebc65060, n=16 23(52) DEBUG: <core> [core/tcp_main.c:3982]: handle_ser_child(): read response= 7fc3ebc65060, 2, fd -1 from 14 (43) 14(43) DEBUG: <core> [core/tcp_main.c:2665]: tcpconn_send_put(): after receive_fd: c= 0x7fc3ebc65060 n=8 fd=20 14(43) DEBUG: <core> [core/tcp_main.c:2842]: tcpconn_do_send(): sending... 14(43) DEBUG: <core> [core/tcp_main.c:2878]: tcpconn_do_send(): after real write: c= 0x7fc3ebc65060 n=1372 fd=20 14(43) DEBUG: <core> [core/tcp_main.c:2879]: tcpconn_do_send(): buf= ......... 23(52) DEBUG: <core> [core/tcp_main.c:4671]: handle_tcpconn_ev(): sending to child, events 2001 23(52) DEBUG: <core> [core/tcp_main.c:4299]: send2child(): checking per-socket generic workers (48/19..-1828836960/21964) [tls:10.129.1.168:5061] 23(52) DEBUG: <core> [core/tcp_main.c:4326]: send2child(): WARNING: no free tcp receiver, connection passed to the least busy one (idx:0 busy:2) 23(52) DEBUG: <core> [core/tcp_main.c:4330]: send2child(): selected tcp worker idx:0 proc:19 pid:48 for activity on [tls:10.129.1.168:5061], 0x7fc3ebc65060 19(48) DEBUG: <core> [core/tcp_read.c:1782]: handle_io(): received n=8 con=0x7fc3ebc65060, fd=14 19(48) DEBUG: <core> [core/tcp_read.c:280]: tcp_read_data(): EOF on connection 0x7fc3ebc65060 (state: 0, flags: 118) - FD 14, bytes 0, rd-flags 10000 ([x.x.x.x]:5061 -> [x.x.x.x]:5061)19(48) DEBUG: <core> [core/tcp_read.c:1544]: tcp_read_req(): EOF 19(48) DEBUG: <core> [core/tcp_read.c:1702]: release_tcpconn(): releasing con 0x7fc3ebc65060, state -1, fd=14, id=9 ([x.x.x.x]:5061 -> [x.x.x.x]:5061) 19(48) DEBUG: <core> [core/tcp_read.c:1705]: release_tcpconn(): extra_data 0x7fc3ebc305b0 23(52) DEBUG: <core> [core/tcp_main.c:3744]: handle_tcp_child(): reader response= 7fc3ebc65060, -1 from 0 23(52) DEBUG: <core> [core/tcp_main.c:3668]: tcp_emit_closed_event(): TCP closed event creation triggered (reason: 0) 23(52) DEBUG: <core> [core/tcp_main.c:3676]: tcp_emit_closed_event(): no callback registering for handling TCP closed event 23(52) DEBUG: tls [tls_server.c:732]: tls_h_tcpconn_close_f(): Closing SSL connection 0x7fc3ebc305b0

9 months, 2 weeks

412 issue

by satyaprakash ch

Hi, Does the below link issue is improved in updated version of Kamailio, Or kindly anyone help on this 412 issue? Link - https://github.com/kamailio/kamailio/issues/2048 Thanks.

9 months, 2 weeks

Get the amount of open TCP connection from routing logic

by Sebastian Damm

Hello, My plan is to reject new inbound requests if there is already a certain number of open connections on one Kamailio server. I could answer with a 503 and directly close the connection forcing the client to reconnect and the loadbalancer to send traffic to a different node on the next connect. It's just a last-resort measure to prevent Kamailio from running into the configured TCP connection limit (workarounding a poorly-implemented external load balancer). Since I didn't find anything in the docs: Is there a pseudovariable containing the current number of open tcp/tls connections on this Kamailio? I can (and already do) query them via kamcmd or rpc, but can I access the variable from inside the routing script as well? Regards, Sebastian

9 months, 2 weeks

Development for v5.8.x is frozen

by Daniel-Constantin Mierla

Hello, the formal notification that the development for the next major version 5.8.0 is now frozen. The focus has to be on testing the master branch. Also, the master branch should not get commits with new features till the branch 5.8 is created, expected to happen in 2-4 weeks, a matter of how testing goes on. Meanwhile, the commits with new features in the C code can be pushed to personal branches, new pull requests can still be done, but they will be merged after branching 5.8. Can still be done commits with documentation improvements, enhancements to related tools (e.g., kamctl, kamcmd), merging exiting pull requests at this moment, exporting missing KEMI functions and completing the functionality of the new modules added for 5.8. Once the branch 5.8 is created, new features can be pushed again to master branch as usual. From that moment, the v5.8.0 should be out very soon, time used for further testing but also preparing the release of packages. If someone is not sure if a commit brings a new feature, just make a pull request and it can be discussed there on github portal or via sr-dev mailing list. A summary of what is new in upcoming 5.8 is going to be built at: * https://www.kamailio.org/wikidocs/features/new-in-5.8.x/ Upgrade guidelines will be collected at: * https://www.kamailio.org/wikidocs/install/upgrade/5.7.x-to-5.8.0/ Everyone is more than welcome to contribute to the above wiki pages, especially to the upgrade guidelines, to help everyone else during the migration process from v5.7.x to 5.8.x. Cheers, Daniel -- Daniel-Constantin Mierla (@ asipto.com) twitter.com/miconda -- linkedin.com/in/miconda Kamailio Consultancy, Training and Development Services -- asipto.com Kamailio Advanced Training, February 20-22, 2024 -- asipto.com Kamailio World Conference, April 18-19, 2024, Berlin -- kamailioworld.com

9 months, 3 weeks

MS Teams Kamailio SBC tcp timeouts

by maps＠ua.pt

Hello everyone. I have setup Kamailio as an SBC for Microsoft Teams following the link provided in the documentation https://skalatan.de/en/blog/kamailio-sbc-teams and everything was working perfectly until recently. The problem I am having is that starting a few weeks back, Kamailio starting showing the errors below. These errors appear without the need to do anything, meaning without making any sort of call, even with Kamailio sitting idle. Since the problem started I looked around and found out that the issue seems to come from the fact that sometimes the SIP Options request being sent to microsoft is not being answered. I have configured everything following the guide and I did not make any changes to Kamailio since then that might have caused this issue. I am using kamailio with docker, version 5.7.2-bullseye. Thank you very much. 31(37) ERROR: <core> [core/tcp_main.c:4675]: tcpconn_main_timeout(): connect 52.114.76.76:5061 failed (timeout) 9(15) ERROR: <core> [core/tcp_main.c:1321]: tcp_do_connect(): connect 52.114.76.76:5061 failed Cannot assign requested address 9(15) ERROR: <core> [core/tcp_main.c:1324]: tcp_do_connect(): connect 52.114.76.76:5061: (99) Cannot assign requested address 9(15) ERROR: <core> [core/tcp_main.c:1456]: tcpconn_finish_connect(): 52.114.76.76:5061: tcp_do_connect for 0x7f623d0e91a8 failed 9(15) ERROR: <core> [core/tcp_main.c:2112]: tcp_send(): 52.114.76.76:5061: tcpconn_finish_connect(0x7f623d0e91a8) failed 9(15) ERROR: tm [../../core/forward.h:292]: msg_send_buffer(): tcp_send failed 9(15) ERROR: tm [uac.c:688]: send_prepared_request_impl(): Attempt to send to precreated request failed

9 months, 3 weeks

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 February 2024