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
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
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
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
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
Hello,
I propose to aim freezing the development for 5.8.x series at the end of
the 1st of February 2024 (Thursday).
New features that one wants to get in this release series have to be
pushed to git repository or pull requests made for them. Afterwards
usually follows a 4-6 weeks of testing till the first release 5.8.0.
Unfreezing will happen earlier, after the first weeks of testing when
the 5.8 branch will be created.
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
Hello all,
I'm using Kamailio as SIP redirect where I'm appending the contact header then send reply back using sl_send_reply("300","Multiple Choices").
But I'm getting "print_dset(): no r-uri or branches" as warning in the log and no packet is sent back from Kamailio to the original sender.
I'm using same Kamailio configuration in another setup and it's working correctly without facing this error.
I'm not able to detect the issue. Can you please assist?
Regards,