Hi all!
I have been doing some performance tests with Kamailio 5.7.4 and SIPp.
The infrastructure is as follows:3 VMs running on VMWare ESXi running:
UAC on 10.20.0.1 with SIPP-> Kamailio on 10.20.0.5 -> UAS on 10.20.0.3
The Kamailio VM has 6 dedicated vCPU of type Intel(R) Xeon(R) Silver 4216
CPU @ 2.10GHz and, 2 NICs and 4Gb RAM and MariaDB 10.6 as DB Backend., all
running on a HP G380 host with a gazillion CPUs and a googol disk space!
I currently have 3 scripts:
- script #1 stateful with RTJson and simulating requests to routing engine
and accounting
- script #2 stateful but with just a simple routing to UAS, no rules, no
DB,
- script #3 stateless with a forward to UAS
With script #3 I can go up to 2000CPS without issues with CPU at 37%! Above
that value, I get retransmissions everywhere.
On both scripts #1 and #2, the limit is 330CPS max after which I get a lot
of retransmissions, while CPU/Core usage on Kamailio server stays below 10%.
So I do not expect this to be a CPU issue.
I could not understand why such (low) results, so I followed this article
found at
https://www.kamailio.org/docs/openser-performance-tests/#tm-tests-c
<https://www.kamailio.org/docs/openser-performance-tests/#tm-tests-c>
and created exact same scenarios, with kamailio script and SIPP templates
available on the article, hoping for better results.
But I get the same results: between 300 and 330CPS which is far, very far
from the 7000CPS found in the article!
I understand that I'm using VMs and probably the tests made for the
article, which is pretty old already, were made on physical servers. Still,
I would not expect 95% of lower performance!
Any clue what could be the issue? I suspect NICs, but....
Any tips anyone could share?
Thanks in advance!
*Sérgio Charrua*
Hello,
with many countries having public holidays around Catholic Easter, I am
considering to release Kamailio v5.8.1 (out of branch 5.8) on Wednesday,
April 3, 2024. If anyone is aware of issues not yet on the bug tracker,
report them there asap in order to have a better chance to be fixed.
Cheers,
Daniel
--
Daniel-Constantin Mierla (@ asipto.com)
twitter.com/miconda -- linkedin.com/in/miconda
Kamailio Consultancy, Training and Development Services -- asipto.com
Kamailio World Conference, April 18-19, 2024, Berlin -- kamailioworld.com
This question digs into the heart of Kamailio's functionality. It asks about:
Routing Logic: How Kamailio decides where to send SIP messages (calls, registrations, etc.) based on various factors like caller ID, destination number, or custom rules.
Customization: How you can modify this built-in logic to fit your specific needs. This could involve using scripting languages, manipulating SIP messages, or defining custom routing rules.
The discussion would be for developers who want to unlock Kamailio's full potential and tailor it for their unique VoIP deployments.
Visit us for More Info : https://inextrix.com/services/kamailio-development/
Hi,
I am wondering why callee info is not visible in dialog details:
Here is the case:
client-1 > kamailio > two asterisks > kamailio > client-2
registration is on asterisk.
dialog module is enabled and I want to see the asterisk IP that is determined by dispatcher module.
I have tried to put dlg_manage function even after dispatch function, but did not help.
I have also tried to update to header before dlg_manage function, it didn't help either.
Any way to have asterisk IP in dialog details.
It shows only this:
{
h_entry: 483
h_id: 8644
ref: 1
call-id: v489LdfOFD5mnlHupQHOvw..
from_uri: sip:1515@12.12.12.12;transport=UDP
to_uri: sip:2222@12.12.12.12
state: 5
start_ts: 0
init_ts: xxxx
end_ts: xxxx
duration: xxxx
timeout: 0
lifetime: 3600
dflags: 512
sflags: 0
iflags: 0
caller: {
tag: d0283007
contact: sip:1515@1.1.1.1:64966;transport=UDP
cseq: 1
route_set:
socket: udp:172.22.10.10:5060
}
callee: {
tag: <null string>
contact: <null string>
cseq: <null string>
route_set: <null string>
socket: <null string>
}
profiles: {
}
variables: {
}
}
Regards
Get Outlook for Android<https://aka.ms/AAb9ysg>
Hello!
In my architecture, SIP SUBSCRIBE messages can reach the Kamailio
Presence server in several ways.
And I noticed that re-SUBSCRIBEs messages do not update the record_route
field in the active_watchers table (MySQL), so subsequent SIP NOTIFY
messages do not inherit it and have the routes set of the initial SIP
SUBSCRIBE message.
Is there any way to change this behavior?
modparam("presence", "db_url", DBURL)
modparam("presence", "subs_db_mode", 3)
modparam("presence", "timeout_rm_subs", 0)
modparam("presence", "expires_offset", 0)
modparam("presence", "max_expires", 1800)
modparam("presence", "db_update_period", 30)
modparam("presence", "clean_period", 180)
modparam("presence", "send_fast_notify", 1)
modparam("presence", "pres_htable_size", 32)
modparam("presence", "subs_htable_size", 32)
modparam("presence", "publ_cache", 0)
modparam("presence", "notifier_processes", 0)
# kamailio -v
version: kamailio 5.1.2 (x86_64/linux)
--
BR,
Denys Pozniak
Hi,
I would like to move app_lua_sr to kamailio-archive but I would like to hear if anyone out there has a solid reason not to do it. Since we have app_lua as KEMI for a long time I think is time to retire the old remains of app_lua
Cheers
--
-----------------------------------------------------------------
| ,''`. Victor Seva |
| : :' : linuxmaniac(a)torreviejawireless.org |
| `. `' PGP: 8F19 CADC D42A 42D4 5563 730C 51A0 9B18 CF5A 5068 |
| `- Debian Developer |
-----------------------------------------------------------------
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
Hello Everyone.
I am looking for documentation to have multiple RTP Engine servers
connected with kamailio using db url and balance the load accordingly.
Thanks
I need to move a few dozen FreePBXen with some commercial modules running in individual VMs to a new data center.
I’m trying to work out a plan to move the PBXes to the new data center in a way that will be transparent to the endpoints, or at the very least with the absolute minimum of downtime.
Some of the installations are rather old, and there’s a handful of peculiarities on each, so the typical FreePBX backup/restore process hasn’t gone smoothly, at least in our tests.
My current train of thought is to put a clone the VMs in the new data center and use Kamailio to route the SIP traffic to the new servers/IPs. I’ve never used it before, so I may be barking up the wrong tree, but it /appears/ to do what I’m suggesting.
If so, I’m thinking I can install Kamailio on each VM, point it to the local asterisk/FreePBX initially, and clone the VM. Then, after the new instance is up and running, point Kamailio on the original VM to the cloned VM's asterisk, after which I can make appropriate DNS changes.
Another option would be to stand up a single Kamailio server and redirect SIP traffic destined for individual asterisk servers to it at the router.
Endpoints are mostly Yealink, and I’m not sure if they’ll feel the need to restart when the registration/SIP server’s IP changes, but a quick bounce when not in use isn’t the end of the world. I’d very much like to avoid having to send an update to each phone manually, but I can script a SIP NOTIFY if required.
Anything stupid, wrong, ignorant, or just smelly about this tactic?
Or, for that matter, any other suggestions?
Hello,
A bit generic question, does Kamailio supports CRLF keepalive per
https://www.rfc-editor.org/rfc/rfc5626#section-4.4.1 ?
It's more for tracking TCP connection states, as seems tcp_keepalive_enable
is not super reliable especially in mobile networks.
--
Best regards,
Ihor (Igor)