We’re still using kamailio 4.4 but we’ll be migrating to 5.0 soon.
Cool so it will be fixed when we migrate !
From: sr-users [mailto:email@example.com] On Behalf Of Federico Cabiddu
Sent: vendredi 12 mai 2017 11:56
To: Kamailio (SER) - Users Mailing List
Subject: Re: [SR-Users] t_drop_replies not working with t_suspend in failure route
which version are you using?
A similar case had been reported some months ago and it should be fixed in 5.0.
On Fri, May 12, 2017 at 11:44 AM, Huber Andreas <andreas.huber(a)nagra.com<mailto:firstname.lastname@example.org>> wrote:
We have a use case where we suspend a transaction in a failure_route to give UEs that might be woken by a push notification more time to REGISTER and join the INVITE.
We’d like to drop the previous branches in this case. I tried using t_drop_replies() but it has no effect.
The doc states that t_drop_replies() is only working if a new branch is added. And from my understanding t_suspend() adds a new branch.
But is it possible that t_drop_replies() cannot be used with t_suspend()? Or am I missing something?
Kamailio (SER) - Users Mailing List
When receiving an INVITE over a specific LTE carrier, I'm seeing 'c=IN IP4
192.0.0.4' in SDP, which isn't technically a RFC1918 or RFC6598 IP address
and thus nat_uac_test(8) fails.
What elegant workaround can be done to catch such specific cases?
I'm using RTPproxy for the first time in bridged mode and I can't get kamailio/rtpproxy to rewrite the c parameter to the correct public ip address of kamailio.
The setup is as following:
Carrier ------[fiber]------ Kamailio ---------[lan]--------- Freeswitch
Kamailio is listening on two interfaces:
1) Private: 184.108.40.206
2) Public: 192.168.0.1 (since we have a dedicated fiber with our carrier, this is its public address)
Freeswitch is listening on:
Carrier is on:
I've started an rtpproxy instance on the Kamailio box using:
rtpproxy -s udp:127.0.0.1:7721 -u rtpproxy rtpproxy -p /var/run/rtpproxy/rtpproxy.pid -l 192.168.0.1 220.127.116.11
I've played around with rtpproxy_manage() and the various flags (ie, ei), but I can't get kamailio to set the correct public IP when the 200 OK has to be sent back to the carrier.
It always sets it to its private address, instead of its public address.
I'm using Kamailio 4.2 with sippy/rtpproxy 2.0.
Could someone please point me into the right direction?
I am working on a program on Kamailio and rtpengine proxy. I am wondering whether can I set Kamailio and rtpengine daemon on different physical machines. For example, I set Kamailio on a machine with IP address:10.109.247.80, and launch rtpengine daemon on another machine with interface parameter as 10.109.247.90 and ng port 7723. I set parameter in Kamailio.cfg with modparam(“rtpengine”, “rtpengine_sock”, “udp:10.109.247.90:7723”).
Unfortunately I got debug message like this:
ERROR: rtpengine [rtpengine.c:1710]: send_rtpp_command(): can't send command to a RTP proxy
ERROR: rtpengine [rtpengine.c:1746]: send_rtpp_command(): proxy <udp:10.109.247.90:7723> does not respond, disable it
ERROR: rtpengine [rtpengine.c:1616]: rtpp_test(): proxy did not respond to ping
And, I also tried to set Kamailio and rtpengine daemon in a same machine,and use modparam(“rtpengine”, “rtpengine_sock”, “udp:localhost:7723”). And Kamailio can work functionally under this situation. rtpengine daemon can receive ping message from Kamailio and rtpengine daemon can work as suspected. So for the later case, is it supposed that Kamailio be in the same machine with same localhost address? Otherwise, what’s the reason for my ERROR?
I have the following issue (I think) with RTP engine. An INVITE comes in,
and rtpengine will rewrite the SDP accordingly, as configured in
kamailio.cfg. After some time a reINVITE is sent out in the opposite
direction, for session refresh purposes. As I use rtcp-mux-offer in
kamailio.cfg for this direction, RTPengine will inject the rtcp-mux
parameter, and this reINVITE is forwarded to the UAC that sent the original
However, the SDP in the reINVITE is exactly the same as the SDP in the 200
OK to the original INVITE, with the exception of the rtcp-mux parameter.
Since the SDP offered from the same end has changed, shouldn't session
version be incremented as well?
Does this sound like something that should be reported as a bug to
rtpengine? Or am I missing something here?
We have four a scripts that sends dlg.list command to kamailio through
xmlrpc. They are not executed simultaneously. Sometimes, we are getting
the following errors:
fm_search_defrag(): fm_search_defrag(0x7f212c25a000, 5273984); Free
fragment not found!2017-05-26T13:54:20.438736-03:00 drwsip02
/usr/local/sbin/kamailio: ERROR: <core> [mem/f_malloc.c:498]:
fm_malloc(): fm_malloc(0x7f212c25a000, 5273984) called from core:
tcp_main.c: tcpconn_new(957), module: core; Free fragment not
/usr/local/sbin/kamailio: ERROR: <core> [tcp_main.c:959]:
tcpconn_new(): mem. allocation failure2017-05-26T13:54:20.439344-03:00
drwsip02 /usr/local/sbin/kamailio: ERROR: <core> [tcp_main.c:3985]:
handle_new_connect(): tcpconn_new failed, closing socket
I all ready increased this two variables:
How can I see how much memory xmlrpc is using?
Any advice will be appreciated.
Thanks in advance!
I was wondering if the kamctl stats output could be updated to provide a bit more parseable JSON? For instance:
# kamctl stats shmem | jq .
"shmem:fragments = 18",
"shmem:free_size = 467187808",
"shmem:max_used_size = 69694104",
"shmem:real_used_size = 69683104",
"shmem:total_size = 536870912",
"shmem:used_size = 41048984"
I would hope would be more like this:
I apologize in advanced because I don’t have the skillset to contribute such a feature.
In March there was a discus about this issue.
We tested the new 5.2 dev and 5.0.4 version of Kamailio and we experience
that If we restart Kamailio during the call the cdr won't be stored in
table acc_cdrs but the data will be inserted to table acc and data will be
deleted from table dialog and dialog_vars.
Did I omit the fix for it?
Thanks for your help.
This might not be related to Kamailio but I thought someone would be able
to give a hand in resolving dependency during the installation of rtpengine
on Debian 8 Jessie.
It is complaining about below dependencies.
dpkg-buildpackage: source package ngcp-rtpengine
dpkg-buildpackage: source version 18.104.22.168+0~mr22.214.171.124
dpkg-buildpackage: source distribution unstable
dpkg-buildpackage: source changed by Sipwise Jenkins Builder <
dpkg-buildpackage: host architecture amd64
dpkg-source --before-build rtpengine
dpkg-source: info: using options from rtpengine/debian/source/options:
dpkg-checkbuilddeps: *Unmet build dependencies: debhelper (>= 10~)
dpkg-buildpackage: warning: build dependencies/conflicts unsatisfied;
dpkg-buildpackage: warning: (Use -d flag to override.)
I tried to install debhelper from deb but complained from dh-autoreconf and
that itself complained abount debhelpler. So, no one is being installed.
Also, If someone can help me how to resolve dependency for libbcg729-dev
Any pointer or hint or link to some installation guide would be more than
Any idea in this regards?
I understood it's structure of HI2Operations as ASN.1 IRI-HI2, I attached it.
I think i should convert SIP signalling flow to this structure for transmission.
Is it right way that i am doing?
On Thu, Apr 26, 2018 at 12:50 PM, Mojtaba <mespio(a)gmail.com> wrote:
> The declaration of details are in 3GPP TS 101-671 Annex D.5 (ASN.1
> description of IRI (HI2 interface)).
> I need a sample packet of HI2Operations for underestanding, so that
> i'll develop this HI in kamailio.
> With Regards.Mojtaba
> On Thu, Apr 26, 2018 at 11:20 AM, Daniel-Constantin Mierla
> <miconda(a)gmail.com> wrote:
>> can you provide more details or references (web links) about the operations
>> you want to do? Like what sip message comes to kamailio and what you need to
>> change to it.
>> On 25.04.18 06:00, Mojtaba wrote:
>> I need to use HI2Operations for transfering IRI-Parameters in kamailio.Dose
>> anybody have experience in this regards?
>> Kamailio (SER) - Users Mailing List
>> Daniel-Constantin Mierla
>> www.twitter.com/miconda -- www.linkedin.com/in/miconda
>> Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com
> --Mojtaba Esfandiari.S