Hello,
I am working on a BLF (Busy Lamp Field, dialog presence) integration using
Kamailio.
I am not sure how certain settings can be used on a single generic (any
phone) Kamailio instance.
*
https://www.kamailio.org/docs/modules/devel/modules/presence_dialoginfo.htm…
"If the phone does not support this, you can activate this parameter."
modparam("presence_dialoginfo", "force_single_dialog", 1)
*
https://kamailio.org/docs/modules/devel/modules/pua_dialoginfo.html#idm152
"This is a workaround for the buggy Linksys SPA962 phones. SNOM phones
work well with the default setting."
modparam("pua_dialoginfo", "caller_confirmed", 1)
How can I activate these settings only for the phones that have problems?
Do I need a different Kamailio instance for each buggy phone that appears
from a client ?
For example, a Kamailio instance with modparam("pua_dialoginfo",
"caller_confirmed", 1) for some (like Linksys SPA962) and the opposite for
all the others (like SNOM) ?
Thank you,
version: kamailio 5.5.3
Using KEMI Python
I have read several posts on this and tried several approaches but can not seem to get it to work. As it stands I am trying to add a=record:on | a=record:off | a=record:pause In the SDP because FreeSWITCH creating the INVITE isn't able to do this in the way required. When it is sent from FreeSWITCH a=record:on is send a=record
I have looked at SDPOPS, TEXTOPS and a few others but non of the offer the option to just inject and a= into the SDP body.
So as a result I tried a couple of options where the INVITE is created with a=record (unsure why FreeSWITCH wont let us just add :off etc to the end but that's another point that if anyone know would be helpful) and then using replace_body or search_append_body but the result is TEXTOPS is unable to action the request because of a SDP parse error
DEBUG: <core> [core/parser/sdp/sdp.c:599]: parse_sdp_session(): ignoring unknown type in a= line: `a=record#015#012a=ptime:20...'
Does anyone have any thoughts or tricks on this to give me a few options at ways to handle this?
Lewis
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.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda
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,
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.
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.
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
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-…>
