sr-users

sr-users@lists.kamailio.org

37388 discussions

UAC parameter for enabling and disabling remote registration
by Ahmed Fouad 14 Apr '22

14 Apr '22

Hi, I was wondering if this patch was ever merged to the current release(s) https://github.com/kamailio/kamailio/commit/49f354276df3cfc2cdb0f85b5a1839f… I'd like to start Kamailio with all remote registration disabled then enable based on the code logic Thanks in advance,

2 9

Roadmap to the next major release - v5.6.0
by Daniel-Constantin Mierla 14 Apr '22

14 Apr '22

Hello, it is the time to plan a bit the road to the next major release, to be versioned 5.6.0. The 5.5.0 was release about one year ago, therefore it is time to set the milestones for getting 5.6.0 out. I would propose to freeze the development on Thursday, April 14, 2020, test till mid of May or so, then release v5.6.0. There is a lot of development to existing components and a couple of new modules. If anyone wants a different time line towards 5.6.0, let's discuss and choose the one that suits most of the developers. Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda

2 3

kamailio fail to load sip-router.cfg
by bayu p 13 Apr '22

13 Apr '22

Dear Sir, Could you please help me, please to share how to load sip-router.cfg file inside running kamailio ? the file is necessary to be load during rerouting kamailio gateway. I have 2 platform kamailio , both of them are failed to load sip-router.cfg file. They are apt kamailio installation source and the second is tar.gz kamailio installation source, which reload / restart kamailio process (and installation) were failed to load sip-router.cfg file. Best Regards,

2 5

Re: [SR-Users] Kamailio IMS heavy load
by Henning Westerholt 12 Apr '22

12 Apr '22

Hello, checking CPU/I/O performance of the database during the load test would be a start. You can also monitor database access e.g. with a network debugging tools. Cheers, Henning -- Henning Westerholt – https://skalatan.de/blog/ Kamailio services – https://gilawa.com<https://gilawa.com/> From: Евгений Мастратов <dgeka25594(a)gmail.com> Sent: Tuesday, April 12, 2022 10:03 AM To: Henning Westerholt <hw(a)gilawa.com> Subject: Re: [SR-Users] Kamailio IMS heavy load Hey Henning! Thanks for the advice, I understand about logging, I will make edits and re-check. And how can I check the fact that what are the gaps when reading / writing the database? I am using MySQL. вт, 12 апр. 2022 г. в 10:52, Henning Westerholt <hw(a)gilawa.com<mailto:hw@gilawa.com>>: Hello, as mentioned, I would start by monitoring my dependencies, in particular related to I/O, like database or monitoring. Just to be sure, you are not running the tests with enabled debug log level? This would certainly cause problems. Cheers, Henning -- Henning Westerholt – https://skalatan.de/blog/ Kamailio services – https://gilawa.com<https://gilawa.com/> From: sr-users <sr-users-bounces(a)lists.kamailio.org<mailto:sr-users-bounces@lists.kamailio.org>> On Behalf Of ??????? ????????? Sent: Monday, April 11, 2022 5:23 PM To: sr-users(a)lists.kamailio.org<mailto:sr-users@lists.kamailio.org> Subject: [SR-Users] Kamailio IMS heavy load Hi! Previously, I created a ticket on github https://github.com/kamailio/kamailio/issues/3071 and tried to deal with the problem there, but they sent me here for advice. I set up Kamailio IMS , in the end everything turned out great, calls are made, and I decided to check how Kamailio copes with the load. I am creating a load using the sipp application. There is no problem with a low call generation rate, but if you raise the call generation to more than 20 calls per second, some of the calls fail. I compared the calls and saw that the ICSCF does not send a 180 Ringing message towards the S-CSCF [..] As I found out further and suggested, the problem is that some calls are cut on the S-CSCF and this is probably due to some kind of timer, but I could not figure out which one. Full logs and dump are attached to the issue on github, below is a log sample by bad dialog 0x7fc133ce61d8 ``` Apr 5 08:24:33 ims-core /usr/local/sbin/kamailio[26061]: DEBUG: ims_dialog [dlg_handlers.c:284]: dlg_iuid_sfree(): freeing dlg iuid [465:10905] (0x7fc133ce61d8) Apr 5 08:24:35 ims-core /usr/local/sbin/kamailio[26056]: DEBUG: ims_dialog [dlg_hash.c:1025]: link_dlg(): ref dlg 0x7fc133ce61d8 with 1 -> 1 Apr 5 08:24:35 ims-core /usr/local/sbin/kamailio[26056]: DEBUG: ims_dialog [dlg_cb.c:251]: run_create_callbacks(): dialog=0x7fc133ce61d8 Apr 5 08:24:35 ims-core /usr/local/sbin/kamailio[26056]: DEBUG: ims_dialog [dlg_hash.c:887]: lookup_dlg(): ref dlg 0x7fc133ce61d8 with 1 -> 2 Apr 5 08:24:35 ims-core /usr/local/sbin/kamailio[26056]: DEBUG: ims_dialog [dlg_handlers.c:789]: dlg_onreq(): dialog [0x7fc133ce61d8] added to tm callbacks Apr 5 08:24:35 ims-core /usr/local/sbin/kamailio[26056]: DEBUG: ims_dialog [dlg_hash.c:1066]: unref_dlg(): unref dlg 0x7fc133ce61d8 with 1 -> 1 Apr 5 08:24:35 ims-core /usr/local/sbin/kamailio[26056]: DEBUG: ims_dialog [dlg_hash.c:887]: lookup_dlg(): ref dlg 0x7fc133ce61d8 with 1 -> 2 Apr 5 08:24:35 ims-core /usr/local/sbin/kamailio[26056]: DEBUG: ims_dialog [dlg_hash.c:1066]: unref_dlg(): unref dlg 0x7fc133ce61d8 with 1 -> 1 Apr 5 08:24:35 ims-core /usr/local/sbin/kamailio[26059]: DEBUG: ims_dialog [dlg_hash.c:887]: lookup_dlg(): ref dlg 0x7fc133ce61d8 with 1 -> 2 Apr 5 08:24:35 ims-core /usr/local/sbin/kamailio[26059]: DEBUG: ims_dialog [dlg_hash.c:1066]: unref_dlg(): unref dlg 0x7fc133ce61d8 with 1 -> 1 Apr 5 08:24:38 ims-core /usr/local/sbin/kamailio[26056]: DEBUG: ims_dialog [dlg_hash.c:887]: lookup_dlg(): ref dlg 0x7fc133ce61d8 with 1 -> 2 Apr 5 08:24:38 ims-core /usr/local/sbin/kamailio[26056]: DEBUG: ims_dialog [dlg_hash.c:1066]: unref_dlg(): unref dlg 0x7fc133ce61d8 with 1 -> 1 Apr 5 08:24:38 ims-core /usr/local/sbin/kamailio[26056]: DEBUG: ims_dialog [dlg_hash.c:887]: lookup_dlg(): ref dlg 0x7fc133ce61d8 with 1 -> 2 Apr 5 08:24:38 ims-core /usr/local/sbin/kamailio[26056]: DEBUG: ims_dialog [dlg_hash.c:1066]: unref_dlg(): unref dlg 0x7fc133ce61d8 with 1 -> 1 Apr 5 08:24:38 ims-core /usr/local/sbin/kamailio[26056]: DEBUG: ims_dialog [dlg_hash.c:887]: lookup_dlg(): ref dlg 0x7fc133ce61d8 with 1 -> 2 Apr 5 08:24:38 ims-core /usr/local/sbin/kamailio[26056]: DEBUG: ims_dialog [dlg_hash.c:1293]: next_state_dlg(): dialog 0x7fc133ce61d8 changed from state 1 to state 6, due event 4 Apr 5 08:24:38 ims-core /usr/local/sbin/kamailio[26056]: DEBUG: ims_dialog [dlg_handlers.c:1489]: dlg_onreply(): dialog 0x7fc133ce61d8 failed (negative reply) Apr 5 08:24:38 ims-core /usr/local/sbin/kamailio[26056]: DEBUG: ims_dialog [dlg_cb.c:277]: run_dlg_callbacks(): dialog=0x7fc133ce61d8, type=4 Apr 5 08:24:38 ims-core /usr/local/sbin/kamailio[26056]: DEBUG: ims_dialog [dlg_hash.c:1066]: unref_dlg(): unref dlg 0x7fc133ce61d8 with 1 -> 1 Apr 5 08:24:38 ims-core /usr/local/sbin/kamailio[26056]: DEBUG: ims_dialog [dlg_hash.c:1066]: unref_dlg(): unref dlg 0x7fc133ce61d8 with 1 -> 0 Apr 5 08:24:38 ims-core /usr/local/sbin/kamailio[26056]: DEBUG: ims_dialog [dlg_hash.c:1066]: unref_dlg(): ref <=0 for dialog 0x7fc133ce61d8 Apr 5 08:24:38 ims-core /usr/local/sbin/kamailio[26056]: DEBUG: ims_dialog [dlg_hash.c:196]: destroy_dlg(): destroying dialog 0x7fc133ce61d8 Apr 5 08:24:38 ims-core /usr/local/sbin/kamailio[26056]: DEBUG: ims_dialog [dlg_hash.c:207]: destroy_dlg(): removed timer for dlg 0x7fc133ce61d8 [3791:1419] with clid '43-3057631(a)10.2.16.63<mailto:43-3057631@10.2.16.63>' and tags '78885556600' Apr 5 08:24:38 ims-core /usr/local/sbin/kamailio[26056]: DEBUG: ims_dialog [dlg_cb.c:277]: run_dlg_callbacks(): dialog=0x7fc133ce61d8, type=8192 ``` What could be the reasons for this behavior and how to diagnose them? I did not observe problems with MEM or CPU during the tests. I will be grateful for any advice.

1 0

Kamailio IMS heavy load
by Евгений Мастратов 12 Apr '22

12 Apr '22

Hi! Previously, I created a ticket on github https://github.com/kamailio/kamailio/issues/3071 and tried to deal with the problem there, but they sent me here for advice. I set up Kamailio IMS , in the end everything turned out great, calls are made, and I decided to check how Kamailio copes with the load. I am creating a load using the sipp application. There is no problem with a low call generation rate, but if you raise the call generation to more than 20 calls per second, some of the calls fail. I compared the calls and saw that the ICSCF does not send a 180 Ringing message towards the S-CSCF [image: image.png] [image: image.png] As I found out further and suggested, the problem is that some calls are cut on the S-CSCF and this is probably due to some kind of timer, but I could not figure out which one. Full logs and dump are attached to the issue on github, below is a log sample by bad dialog 0x7fc133ce61d8 ``` Apr 5 08:24:33 ims-core /usr/local/sbin/kamailio[26061]: DEBUG: ims_dialog [dlg_handlers.c:284]: dlg_iuid_sfree(): freeing dlg iuid [465:10905] (0x7fc133ce61d8) Apr 5 08:24:35 ims-core /usr/local/sbin/kamailio[26056]: DEBUG: ims_dialog [dlg_hash.c:1025]: link_dlg(): ref dlg 0x7fc133ce61d8 with 1 -> 1 Apr 5 08:24:35 ims-core /usr/local/sbin/kamailio[26056]: DEBUG: ims_dialog [dlg_cb.c:251]: run_create_callbacks(): dialog=0x7fc133ce61d8 Apr 5 08:24:35 ims-core /usr/local/sbin/kamailio[26056]: DEBUG: ims_dialog [dlg_hash.c:887]: lookup_dlg(): ref dlg 0x7fc133ce61d8 with 1 -> 2 Apr 5 08:24:35 ims-core /usr/local/sbin/kamailio[26056]: DEBUG: ims_dialog [dlg_handlers.c:789]: dlg_onreq(): dialog [0x7fc133ce61d8] added to tm callbacks Apr 5 08:24:35 ims-core /usr/local/sbin/kamailio[26056]: DEBUG: ims_dialog [dlg_hash.c:1066]: unref_dlg(): unref dlg 0x7fc133ce61d8 with 1 -> 1 Apr 5 08:24:35 ims-core /usr/local/sbin/kamailio[26056]: DEBUG: ims_dialog [dlg_hash.c:887]: lookup_dlg(): ref dlg 0x7fc133ce61d8 with 1 -> 2 Apr 5 08:24:35 ims-core /usr/local/sbin/kamailio[26056]: DEBUG: ims_dialog [dlg_hash.c:1066]: unref_dlg(): unref dlg 0x7fc133ce61d8 with 1 -> 1 Apr 5 08:24:35 ims-core /usr/local/sbin/kamailio[26059]: DEBUG: ims_dialog [dlg_hash.c:887]: lookup_dlg(): ref dlg 0x7fc133ce61d8 with 1 -> 2 Apr 5 08:24:35 ims-core /usr/local/sbin/kamailio[26059]: DEBUG: ims_dialog [dlg_hash.c:1066]: unref_dlg(): unref dlg 0x7fc133ce61d8 with 1 -> 1 Apr 5 08:24:38 ims-core /usr/local/sbin/kamailio[26056]: DEBUG: ims_dialog [dlg_hash.c:887]: lookup_dlg(): ref dlg 0x7fc133ce61d8 with 1 -> 2 Apr 5 08:24:38 ims-core /usr/local/sbin/kamailio[26056]: DEBUG: ims_dialog [dlg_hash.c:1066]: unref_dlg(): unref dlg 0x7fc133ce61d8 with 1 -> 1 Apr 5 08:24:38 ims-core /usr/local/sbin/kamailio[26056]: DEBUG: ims_dialog [dlg_hash.c:887]: lookup_dlg(): ref dlg 0x7fc133ce61d8 with 1 -> 2 Apr 5 08:24:38 ims-core /usr/local/sbin/kamailio[26056]: DEBUG: ims_dialog [dlg_hash.c:1066]: unref_dlg(): unref dlg 0x7fc133ce61d8 with 1 -> 1 Apr 5 08:24:38 ims-core /usr/local/sbin/kamailio[26056]: DEBUG: ims_dialog [dlg_hash.c:887]: lookup_dlg(): ref dlg 0x7fc133ce61d8 with 1 -> 2 Apr 5 08:24:38 ims-core /usr/local/sbin/kamailio[26056]: DEBUG: ims_dialog [dlg_hash.c:1293]: next_state_dlg(): dialog 0x7fc133ce61d8 changed from state 1 to state 6, due event 4 Apr 5 08:24:38 ims-core /usr/local/sbin/kamailio[26056]: DEBUG: ims_dialog [dlg_handlers.c:1489]: dlg_onreply(): dialog 0x7fc133ce61d8 failed (negative reply) Apr 5 08:24:38 ims-core /usr/local/sbin/kamailio[26056]: DEBUG: ims_dialog [dlg_cb.c:277]: run_dlg_callbacks(): dialog=0x7fc133ce61d8, type=4 Apr 5 08:24:38 ims-core /usr/local/sbin/kamailio[26056]: DEBUG: ims_dialog [dlg_hash.c:1066]: unref_dlg(): unref dlg 0x7fc133ce61d8 with 1 -> 1 Apr 5 08:24:38 ims-core /usr/local/sbin/kamailio[26056]: DEBUG: ims_dialog [dlg_hash.c:1066]: unref_dlg(): unref dlg 0x7fc133ce61d8 with 1 -> 0 Apr 5 08:24:38 ims-core /usr/local/sbin/kamailio[26056]: DEBUG: ims_dialog [dlg_hash.c:1066]: unref_dlg(): ref <=0 for dialog 0x7fc133ce61d8 Apr 5 08:24:38 ims-core /usr/local/sbin/kamailio[26056]: DEBUG: ims_dialog [dlg_hash.c:196]: destroy_dlg(): destroying dialog 0x7fc133ce61d8 Apr 5 08:24:38 ims-core /usr/local/sbin/kamailio[26056]: DEBUG: ims_dialog [dlg_hash.c:207]: destroy_dlg(): removed timer for dlg 0x7fc133ce61d8 [3791:1419] with clid '43-3057631(a)10.2.16.63' and tags '78885556600' Apr 5 08:24:38 ims-core /usr/local/sbin/kamailio[26056]: DEBUG: ims_dialog [dlg_cb.c:277]: run_dlg_callbacks(): dialog=0x7fc133ce61d8, type=8192 ``` What could be the reasons for this behavior and how to diagnose them? I did not observe problems with MEM or CPU during the tests. I will be grateful for any advice.

2 1

How to submit updates for core documentation?
by Ben Kaufman 11 Apr '22

11 Apr '22

Hello, I had a small patch merged for 5.6 to add preprocessor macros #!trydefenv and #!trydefenvs. (https://github.com/kamailio/kamailio/issues/2967), but they need documentation. I believe that they should ultimately end up on this page: https://www.kamailio.org/wiki/cookbooks/devel/core. I don't see this in the /doc section of the repo. What's the process for me to submit this documentation? Ben Kaufman Sr. VoIP Engineer - BCM One +1.612.735.9309 bkaufman(a)bcmone.com<mailto:bkaufman@bcmone.com> 24 hour client support: +1.855.639.6300 [https://www.bcmone.com/files/bcmone-logo.png]<https://www.bcmone.com/> [https://www.bcmone.com/files/twitter-icon-circle.png] <https://www.facebook.com/bcmonenyc/> [https://www.bcmone.com/files/twitter-icon-circle.png] <https://twitter.com/bcm_one/> [https://www.bcmone.com/files/linkedin-icon-circle.png] <https://www.linkedin.com/company/business-communications-management/> NOTE: This e-mail and any attachments are from BCM One, Inc. and are intended solely for the use and review of the individual(s) to whom it is addressed. If you believe you received this e-mail in error, please notify the sender immediately, delete the e-mail (and any attachments) from your computer and do not copy or disclose it to anyone else.

2 4

reply sent
by Daniel Paape 11 Apr '22

11 Apr '22

Hello, Is there a function that can be called from a module that will return the last response code sent, regardless of whether it was a local or relayed reply? thanks, Daniel

2 1

LCR from_gw function
by Antoine DEBARRE 11 Apr '22

11 Apr '22

Hi, Kamailio 5.5.4 from deb packages I tried to use the lcr function from_gw(lcr_id[, ip_addr, proto]) I've declared several gws with different lcr_id Unfortunately from_gw doesn't work with lcr_id > 1 For example : if (from_gw(2,$si,1)) { .... } ... error message => ki_from_gw(): invalid lcr_id parameter value 2 Thanks in advance ! -- <https://app.livestorm.co/comdata-group/metaverse-what-will-cx-look-like-in-…>

2 1

Kamailio + Asterisk + Voip SIP Trunk = Incorrect IP on ACK
by Luciano Motti 09 Apr '22

09 Apr '22

Hello! I have the following architecture: - Kamailio with RTPEngine (with public access on IP *YY.YY.42.207*) - Asterisk (with no public access, internal IP *172.31.69.198*) I am using a Voip SIP (with public access on IP *54.XXX.XXX.44*) configured as a Trunk on Kamailio using UAC Module. The issue I am facing is that the SIP messages replies I get from the VOIP provider are being destined to Kamailio's public IP (YY.YY.42.207) instead of Asterisk's IP (as sent on the message). For example, this is the 200 message I sent to the VOIP provider (I clearly state that the contact is Asterisk sip:172.31.69.198:5080): 2022/04/07 14:17:19.260864 172.31.32.7:5060 -> 54.XXX.XXX.44:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 54.XXX.XXX.44:5060;rport=5060;branch=z9hG4bK90b6.f7a6b0a4.0 Record-Route: <sip:YY.YY.42.207;lr;ftag=p0BjH21gpa3rc> Call-ID: 464f21c3-3120-123b-91b2-026ef2fede4c From: "419XXXXX998" <sip:38XXXX02@172.31.32.169>;tag=p0BjH21gpa3rc To: <sip:38XXXX02@54.XXX.XXX.44>;tag=8c3bb09e-a909-4cb4-99a7-3c57aa8f946e CSeq: 50116727 INVITE Server: Asterisk PBX 18.11.0 *Contact: <sip:172.31.69.198:5080 <http://172.31.69.198:5080>>* Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER Supported: 100rel, timer, replaces, norefersub Content-Type: application/sdp Content-Length: 239 v=0 o=- 1649321756 1649321759 IN IP4 172.31.69.198 s=Asterisk c=IN IP4 172.31.69.198 t=0 0 m=audio 10010 RTP/AVP 8 101 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 a=maxptime:150 a=sendrecv But the ACK I get from them is destined to Kamailio instead of Asterisk: 2022/04/07 14:17:19.263469 54.XXX.XXX.44:5060 -> 172.31.32.7:5060 *ACK sip:YY.YY.42.207:5060 SIP/2.0* Route: <sip:YY.YY.42.207;lr;ftag=p0BjH21gpa3rc> Via: SIP/2.0/UDP 54.XXX.XXX.44:5060;branch=z9hG4bK90b6.f7a6b0a4.2 Max-Forwards: 69 From: "419XXXXX998" <sip:38XXXX02@172.31.32.169>;tag=p0BjH21gpa3rc To: <sip:38XXXX02@54.XXX.XXX.44>;tag=8c3bb09e-a909-4cb4-99a7-3c57aa8f946e Call-ID: 464f21c3-3120-123b-91b2-026ef2fede4c CSeq: 50116727 ACK Contact: <sip:voip.voip-sbc.6792.fab37901@54.XXX.XXX.44:5060> Content-Length: 0 This causes Kamailio to not know where to forward the message to... Asterisk never gets the reply. This is happening to one of the SIP Trunks I am using, with the other, everything is fine. Is there anything I can do to work around it (other than contacting the provider to fix on their end)? Thanks! ps: I have attached the full SIP messages trail to help.

2 1

Htable reload
by David Villasmil 07 Apr '22

07 Apr '22

Hello all, I’ve been trying to figure out how htable reloads happen. Does it replaces the existing one or creates a new one, populates it from the db and then renames it? The latter would be (I think) ideal, even if it uses more resources. Thanks! David -- Regards, David Villasmil email: david.villasmil.work(a)gmail.com phone: +34669448337

4 6

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