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-…>
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.
