Hello,
I am trying to use the rate limit module using Kamailio 1.5.2. I feel that I got it but I would
like some pointers and recommendations.
These are my settings: (this is a lab of course), I used 1 on the timer_interval because I am
generating the calls manually and wanted to see it in action quickly:
# ---- ratelimit -------
modparam("ratelimit", "timer_interval", 1)
modparam("ratelimit", "reply_code", 506)
modparam("ratelimit", "reply_reason", "Rejecting due to high load")
modparam("ratelimit", "queue", "0:INVITE")
modparam("ratelimit", "pipe", "0:TAILDROP:1")
then in the route section:
if (method=="INVITE") {
xlog("L_INFO","mylog: RL found INVITE.\n");
if (!rl_check()) {
xlog("L_INFO","mylog: RL dropped message.\n");
rl_drop();
exit;
};
xlog("L_INFO","mylog: RL found INVITE but did not drop it.\n");
};
The TAILDROP algorithm seems to work better than the RED, based on what I expected of course (with 1 sec timer interval and 1 calls/sec on the pipe).
Making manual calls one right after the other almost always triggered the protecting when there was another call on the same second.
But these lines (1.6.3. pipe) on the doc got me kind of confused:
" When specifying a limit, the unit depends on the algorithm used and
doesn't
need to be specified also (eg, for TAILDROP or RED, limit means packets/sec,
whereas with the FEEDBACK
algorithm, it means [CPU] load factor).
For these 2 lines below, does this mean that the interval =10 will be overridden by the 100 calls/sec on the TAILDROP algorithm?
modparam("ratelimit", "timer_interval", 10)
modparam("ratelimit", "pipe", "0:TAILDROP:100")
I made a quick test and with timer_interval = 10 and TAILDROP:1, it looks like the protection kicks in almost every 10 secs: (Dec 2 19:44:07 and Dec 2 19:43:57),
tail -f proxy.log | grep RL
Dec 2 19:43:53 AW-ATL-PROXY-01 ./kamailio[17450]: mylog: RL found INVITE.
Dec 2 19:43:53 AW-ATL-PROXY-01 ./kamailio[17450]: mylog: RL found INVITE but did not drop it.
Dec 2 19:43:53 AW-ATL-PROXY-01 ./kamailio[17449]: mylog: RL found INVITE.
Dec 2 19:43:53 AW-ATL-PROXY-01 ./kamailio[17449]: mylog: RL found INVITE but did not drop it.
Dec 2 19:43:53 AW-ATL-PROXY-01 ./kamailio[17450]: mylog: RL found INVITE.
Dec 2 19:43:53 AW-ATL-PROXY-01 ./kamailio[17450]: mylog: RL found INVITE but did not drop it.
Dec 2 19:43:53 AW-ATL-PROXY-01 ./kamailio[17450]: mylog: RL found INVITE.
Dec 2 19:43:53 AW-ATL-PROXY-01 ./kamailio[17450]: mylog: RL found INVITE but did not drop it.
Dec 2 19:43:54 AW-ATL-PROXY-01 ./kamailio[17450]: mylog: RL found INVITE.
Dec 2 19:43:54 AW-ATL-PROXY-01 ./kamailio[17450]: mylog: RL found INVITE but did not drop it.
Dec 2 19:43:55 AW-ATL-PROXY-01 ./kamailio[17449]: mylog: RL found INVITE.
Dec 2 19:43:55 AW-ATL-PROXY-01 ./kamailio[17449]: mylog: RL found INVITE but did not drop it.
Dec 2 19:43:56 AW-ATL-PROXY-01 ./kamailio[17449]: mylog: RL found INVITE.
Dec 2 19:43:56 AW-ATL-PROXY-01 ./kamailio[17449]: mylog: RL found INVITE but did not drop it.
Dec 2 19:43:56 AW-ATL-PROXY-01 ./kamailio[17450]: mylog: RL found INVITE.
Dec 2 19:43:56 AW-ATL-PROXY-01 ./kamailio[17450]: mylog: RL found INVITE but did not drop it.
Dec 2 19:43:56 AW-ATL-PROXY-01 ./kamailio[17449]: mylog: RL found INVITE.
Dec 2 19:43:56 AW-ATL-PROXY-01 ./kamailio[17449]: mylog: RL found INVITE but did not drop it.
Dec 2 19:43:57 AW-ATL-PROXY-01 ./kamailio[17450]: mylog: RL found INVITE.
Dec 2 19:43:57 AW-ATL-PROXY-01 ./kamailio[17450]: mylog: RL found INVITE but did not drop it.
Dec 2 19:43:57 AW-ATL-PROXY-01 ./kamailio[17449]: mylog: RL found INVITE.
Dec 2 19:43:57 AW-ATL-PROXY-01 ./kamailio[17449]: mylog: RL dropped message.
Dec 2 19:43:58 AW-ATL-PROXY-01 ./kamailio[17449]: mylog: RL found INVITE.
Dec 2 19:43:58 AW-ATL-PROXY-01 ./kamailio[17449]: mylog: RL found INVITE but did not drop it.
Dec 2 19:43:59 AW-ATL-PROXY-01 ./kamailio[17449]: mylog: RL found INVITE.
Dec 2 19:43:59 AW-ATL-PROXY-01 ./kamailio[17449]: mylog: RL found INVITE but did not drop it.
Dec 2 19:43:59 AW-ATL-PROXY-01 ./kamailio[17450]: mylog: RL found INVITE.
Dec 2 19:43:59 AW-ATL-PROXY-01 ./kamailio[17450]: mylog: RL found INVITE but did not drop it.
Dec 2 19:44:01 AW-ATL-PROXY-01 ./kamailio[17450]: mylog: RL found INVITE.
Dec 2 19:44:01 AW-ATL-PROXY-01 ./kamailio[17450]: mylog: RL found INVITE but did not drop it.
Dec 2 19:44:02 AW-ATL-PROXY-01 ./kamailio[17450]: mylog: RL found INVITE.
Dec 2 19:44:02 AW-ATL-PROXY-01 ./kamailio[17450]: mylog: RL found INVITE but did not drop it.
Dec 2 19:44:02 AW-ATL-PROXY-01 ./kamailio[17449]: mylog: RL found INVITE.
Dec 2 19:44:02 AW-ATL-PROXY-01 ./kamailio[17449]: mylog: RL found INVITE but did not drop it.
Dec 2 19:44:04 AW-ATL-PROXY-01 ./kamailio[17449]: mylog: RL found INVITE.
Dec 2 19:44:04 AW-ATL-PROXY-01 ./kamailio[17449]: mylog: RL found INVITE but did not drop it.
Dec 2 19:44:06 AW-ATL-PROXY-01 ./kamailio[17450]: mylog: RL found INVITE.
Dec 2 19:44:06 AW-ATL-PROXY-01 ./kamailio[17450]: mylog: RL found INVITE but did not drop it.
Dec 2 19:44:06 AW-ATL-PROXY-01 ./kamailio[17449]: mylog: RL found INVITE.
Dec 2 19:44:06 AW-ATL-PROXY-01 ./kamailio[17449]: mylog: RL found INVITE but did not drop it.
Dec 2 19:44:07 AW-ATL-PROXY-01 ./kamailio[17449]: mylog: RL found INVITE.
Dec 2 19:44:07 AW-ATL-PROXY-01 ./kamailio[17449]: mylog: RL found INVITE but did not drop it.
Dec 2 19:44:07 AW-ATL-PROXY-01 ./kamailio[17450]: mylog: RL found INVITE.
Dec 2 19:44:07 AW-ATL-PROXY-01 ./kamailio[17450]: mylog: RL dropped message.
Dec 2 19:44:10 AW-ATL-PROXY-01 ./kamailio[17450]: mylog: RL found INVITE.
Dec 2 19:44:10 AW-ATL-PROXY-01 ./kamailio[17450]: mylog: RL found INVITE but did not drop it.
Hi All,
kamailio 3.1.2 recognize value "transport=TLS" on contact header or only
"transport=tls"?
kamailio forwards (t_relay function) the message with UDP protocol when
value "transport=TLS" is on contact header.
Cheers
I have a couple questions as it relates to monitoring a Kamailio SIP Server.
1. Do you have an OID that we can poll via SNMP-GETs to show call completion statistics? Either the % of completion or the accepting/connecting statistics. If you do not have an OID, do you have a syslog or trap message that can be generated?
2. Do you have an OID that we can poll to get a list errors that were generated? Ex-OID for a 408 or 503. If not, is there a syslog or trap?
3. Can you recommend a way to view the MOS score - possible hardware tap on network to get MOS?
Thanks in advance
This email may contain proprietary and confidential information for the sole use of the intended recipient.
Any review, retransmission, dissemination, or other use of this information by persons or entities other than
the intended recipient is prohibited. If you are not the intended recipient, please contact the sender and
delete all copies. To the extent that opinions are expressed in this message, they are not necessarily the
opinions of Sentinel Technologies or any of its affiliates, employees, directors, officers or shareholders.
Hello,
Kamailio SIP Server v3.2.1 stable release is out.
This is a maintenance release of latest stable branch, 3.2, that
includes fixes since release of v3.2.0. There is no change to database
schema or configuration language structure that you have to do on
installations of v3.2.0. Deployments running previous v3.2.0 versions
are strongly recommended to be upgraded to v3.2.1.
For more details about version 3.2.1 (including links and hints to
download the tarball or from GIT repository), visit:
http://www.kamailio.org/w/2011/12/kamailio-v3-2-1-released/
RPM packages are currently on the build, Debian/Ubuntu packages will be
available soon as well.
Cheers,
Daniel
--
Daniel-Constantin Mierla -- http://www.asipto.com
Hello,
the plan is to start packaging of v3.2.1 after 14:00GMT. If anyone has
anything elst to commit to branch 3.2 to be in v3.2.1, please do it
before, afterwards write me an email first to synchronize and avoid git
conflicts.
Cheers,
Daniel
--
Daniel-Constantin Mierla -- http://www.asipto.com
Kamailio Advanced Training, Dec 5-8, Berlin: http://asipto.com/u/kathttp://linkedin.com/in/miconda -- http://twitter.com/miconda
Hello,
We found an issue when using nat pinger
Previously our system had 1 Kamailio as entry point and we were using
usrloc in mode 2 so:
modparam("usrloc", "db_mode",2)
modparam("usrloc", "db_url",
"mysql://openser:openserrw@<DB_IP>/openser")
On our system we like to use the pinger NAT_HELPER module to keep the
connections alive for the users of our system.
Now we're trying to configure two Kamailio K1 and K2 as entry point of the
system and having both of them active at the same time with a virtual IP as
common entry point for both.
I believe this approach requires to flush information on the usrloc
immediately because following use case can happen and needs to work:
- A registers on K1 server
- B registers on K2 server
-After 5 seg B makes an INVITE to A through K2=> we need K2 kamailio
instance to be able to locate A immediately and not wait until the first
Kamailio flushes the info to the db. (it looks to be around 20/30 seg by
default on mode 2 I think , correct so this looks to be too much time)
So to improve this we tried to change to use usrloc in mode 3 instead of
mode 2. But then we've a big issue: when enabling the pinger module for
NATted users we see it opens a new connection to the db for each OPTIONS
ping we want to send. That looks too many connections for our MySQL server
because for eg if I leave two users registered for 1 hour after some time I
start to see errors like:
13(5292) ERROR: <core> [db_query.c:130]: error while submitting query
13(5292) ERROR: usrloc [dlist.c:151]: raw_query failed
13(5292) ERROR: nathelper [nathelper.c:3459]: failed to fetch contacts
13(5292) ERROR: db_mysql [km_dbase.c:117]: driver error on query: Too many
conne
How should this problem be approached? Could this be due to wrong mysql
configuration? But anyway if for each ping done by NAT_PINGER we make a
query to the db I think this is a lot of "noise" for the db as pings happen
often!
Thanks
BR
Albert
