Hello
We experienced a failure on our kamailio (4.2.1+trusty), which required
a restart.
May 6 07:40:41 rtpproxy01 /usr/sbin/kamailio[5467]: ERROR: <core>
[msg_translator.c:2270]: generate_res_buf_from_sip_res(): out of mem
Afterwards we inspected all the settings to be using default, but at a
much higher level than an other older kamailio which runs much more traffic.
The big difference, is that this kamailio works with rtpengine. Does
that require more memory?
We also observed that the free memory is constantly falling on some
instances. They all started with 16MB but after 1½ day some are on 11.6
Is this normal behaviour that will find a natural level or is there
something bad going on?
We can also see that there are frags. Is that to be worried about, or is
this natural?
kamcmd pkg.stats | egrep -e 'free|frag'
free: 16362760
total_frags: 17
free: 15835176
total_frags: 232
free: 15845760
total_frags: 205
free: 15829288
total_frags: 188
free: 15847456
total_frags: 181
free: 15853024
total_frags: 183
free: 15873232
total_frags: 225
free: 15858584
total_frags: 231
free: 15834592
total_frags: 205
free: 15852520
total_frags: 132
free: 15869048
total_frags: 120
free: 15824872
total_frags: 100
free: 15828448
total_frags: 113
free: 15858216
total_frags: 109
free: 15861992
total_frags: 82
free: 15871712
total_frags: 110
free: 15813824
total_frags: 109
free: 11583736
total_frags: 121
free: 11588896
total_frags: 106
free: 11580448
total_frags: 118
free: 11586312
total_frags: 134
free: 11592840
total_frags: 159
free: 11632536
total_frags: 120
free: 11582368
total_frags: 127
free: 11660104
total_frags: 97
free: 16352192
total_frags: 14
free: 16351088
total_frags: 13
free: 16341248
total_frags: 46
free: 16351184
total_frags: 19
We use 4.2.1+trusty with these modules, is it possible that a newer
version has fixed some memory leak?
loadmodule "db_mysql.so"
loadmodule "mi_fifo.so"
loadmodule "kex.so"
loadmodule "tm.so"
loadmodule "tmx.so"
loadmodule "sl.so"
loadmodule "rr.so"
loadmodule "pv.so"
loadmodule "maxfwd.so"
loadmodule "textops.so"
loadmodule "siputils.so"
loadmodule "xlog.so"
loadmodule "sanity.so"
loadmodule "ctl.so"
loadmodule "mi_rpc.so"
loadmodule "acc.so"
loadmodule "dispatcher.so"
loadmodule "permissions.so"
loadmodule "sdpops.so"
loadmodule "rtpengine.so"
--
Med venlig hilsen / Best regards
Kjeld Flarup (Christensen) M.Sc E.E, Teknisk chef
Viptel ApS, Benslehøjvej 3, DK-7470 Karup J
Telefon: +45 46949949, Telefax: +45 46949950, http://viptel.dk
Hi all,
I'm having a scenario where I'm sending call to CISCO IAD2431. The call
establishes with 200OK from CISCO and Kamailio sends back modified ACK.
Cisco at this points gives out an error and sends 200OK again, Kamailio
replies with ACK, and this cycle goes on until the call drops.
Here is the error from CISCO:
Failed FROM/TO Request check
old_from: "Test Phone" <sip:+14432232221@192.168.1.106>;tag=as370915fc
old_to: <sip:+14444812211@sip.iamip.com:5041>;tag=9FEC572E-100F
new_from: "Test Phone" <sip:+14432232221@192.168.1.106>;tag=as370915fc
new_to: <sip:+14444812211@192.168.1.244:5041>;tag=9FE
I've
#auto_aliases=no
and,
listen=udp:44.33.22.11:5041
listen=udp:192.168.1.244:5041
Kamailio sends INVITE through the Public IP to the CISCO gw, but decides to
change the ACK header.
Any advise please.
Best Regards,
Sammy.
Hi,
I have encountered an issue with kamailio and am hoping someone on this
email distro can help:
Here's my setup and description of the issue:
I am running kamailio version 3.1.4.
I have the kamailio process bound to ports 5060, 5070, and 5090. all UDP.
I have several client devices registering to the kamailio registrar.
The issue I have encountered is this:
SIP registrations to port 5070 are fine for a period of time; by fine I
mean clients send SIP registration requests to kamailio; and kamailio
responds promptly to the request. by period of time I mean (this could be
somewhat random) that for10 hours; 12 hours; 1 hour; that kamailo has no
issue processing requests. after this random time period has elapsed,
kamailo isn't able to respond to sip registrations and other messages in
timely manner; to the point where the clients timeout and have to resend
their registration requests. at times, kamailio does respond to the
requests (with a significant delay) and at other times no response is
received by the client. the user experience is intermittent registration
delays/failures.
The same behavior is seen on port 5090.
I have not encountered the issue yet on port 5060.
During times when kamailio isn't able to respond timely to requests on a
particular port, requests to other ports are responded to timely.
for ex: if port 5070 encounters the issue; port 5060 and 5090 seem
fine. meaning, I can point my client devices to 5060 or 5090 and kamailio
processes the requests timely.
I have studied a tcp dump on the server end (kamailio side) and noticed
that the network layer shows the messages from the client to be received
timely while kamailio is encountering this issue. which indicates to me
that it probably isn't a network lag related issue.
Something at the application layer is probably causing kamailio to not
respond timely.
Furthermore the issue resolves itself after a period of time; that is,
kamailio begins to respond to messages timely on the problematic port.
I haven't had a chance yet to determine exactly how long it takes to
recover. it certainly takes some time though. at least 30 minutes; maybe
more.
I can also state that the load on the kamailio system is minimal. far
below than what the performance metrics state it can handle.
Has anyone encountered this issue where kamalio isn't responding to
registration and other requests timely on a particular port but does so
fine for other ports?
Any help on this would be appreciated.
Thanks,
Karthik
Hello there,
I'm using DMQ module to replicate an htable between several kamailio
servers, what i'm noticing is that DMQ is sending the information from one
server to another, but the htable name is not the same, for example:
The original htable name is $sht(fscache=>queue:2), this htable is
replicated to another server and the name (queue:2) will be replaced to
some random value like this:
$sht(fscache=>3c34e55ae6f9-rsf8qhhwntvw)
What happens is that the other server cannot get the data replicated,
because in script kamailio is looking for $sht(fscache=>queue:2) that is
the original name.
My kamailio version is 4.2.2, i have tested also with version 4.2.4 but I
got the same behavior.
This is an expected behavior or a bug? In case of expected behavior how I
can configure it in order to get the value replicated from one server to
another?
Thank you for your help
--
Cumprimentos
José Seabra
Hi all
Have Asterisk listening on 127.0.0.1 and aiming to route all inbound/outbound SIP via Kamailio listening on 127.0.0.1 and external interface.
Inbound calls from the SIP PROVIDER work just fine. Have NAT, rtpproxy configured for successful registration and subsequent INVITEs etc.
Experiencing some challenges with the outgoing INVITES, primarily authenticating the outbound INVITEs.
The current situation is this:
Asterisk > INVITE > Kamailio > INVITE > SIP PROVIDER
SIP PROVIDER > 407 Proxy Authenticate > Kamailio > Transaction Cancelled.
Asterisk then plays number unavailable message.
The desired situation is more like this:
Asterisk > INVITE > Kamailio > INVITE > SIP PROVIDER
SIP PROVIDER > 407 Proxy Authenticate > Kamailio > Asterisk
Asterisk > INVITE (with auth digest etc) > Kamailio > INVITE > SIP PROVIDER
An attempted solution was made by having Kamailio authenticate using the uac module. However, ideally Kamailio should be mostly transparent and Asterisk should be handling and responding to the 407 Proxy Authentication.
If there is someone in the Kamailio community that has addressed this situation before, guidance would be much appreciated.
Regards,
Darren
Hi All,
After reading the docs I got that it is possible to configure the server so
it will change the SDP so clients will send the media to the media proxy.
But, what if the clients are not behind a symmetric NAT and using ICE where
able to get their real IP:port? How can the server be aware to this and not
change the SDP?
Thanks,
Nir
Hello,
In my scenario with a Kamailio server, I have a VOIP client connecting to the server which, for some reasons, cannot calculate MD5 hashes but only SHA. In this situation, would it be possible to change the authentication algorithm by either modifying Kamailio scripts or writing an external module to do that?
As far as I know, the authentication response is calculated as follow (standard HTTP Digest authentication) :
HA1=MD5(username:realm:password)
HA2=MD5(method:digestURI)
response=MD5(HA1:nonce:HA2)
For that, I have to save ha1 and ha1b values in the DB with the SHA function directly (with a trigger for example), and then change the authentication method too.
What is the best solution to do that? Does a module already exists?
Thank you!
Frederic Mathys
System Integration & Validation
Dear,
With changes incorporate in kamalio.cfg, I am able to REGISTER 200 ok with Rx interface.
But I want to send AAR message only after receiving 200 ok at pcscf. Currently message sequences are
CER ------->
<-------CEA
AAR --------->
<------AAA
REGISTER--->
<-------401
REGISTER---->
<----200 ok
Screen shot is attached for reference.
But I want to Send AAR/AAA only after 200 ok.
Below is the Sequence
CER ------->
<-------CEA
REGISTER--->
<-------401
REGISTER---->
<----200 ok
AAR --------->
<------AAA
I using PCSCF as Diameter client and Seagull as a Diameter server.
With changes in Kamailio.cfg Richard Good on Dec 17, 2014
Updated P-CSCF example with additional Rx_AAR params<https://github.com/kamailio/kamailio/commit/b450a769cff3b5c8ea0962299f6b087…>
I am able to REGISTER but not able to send AAR/AAA after 200 ok.(Refer Attachment)
Kindly let me know any other changes required in kamailio.cfg or seagull scenario.xml or some where else.
and What changes.
Thanks in advance.
Br,
Ramjee Y.
============================================================================================================================
Disclaimer: This message and the information contained herein is proprietary and confidential and subject to the Tech Mahindra policy statement, you may review the policy at http://www.techmahindra.com/Disclaimer.html externally http://tim.techmahindra.com/tim/disclaimer.html internally within TechMahindra.
============================================================================================================================