Hi,
I'd like to implement a couple of helper functions for time handling,
e.g. checking day of week, day of month etc. from within the kamailio
config file. What would you prefer, a new module ("timeutils" maybe?) or
adding it to cfgutils (there are already time-based functions there like
sleep and usleep)?
The idea is to implement time based call-forwards, and an approach could
be to provision various time-related values in usr_preferences table,
and then check it in the config. For example, when doing call-forwards
from Monday to Friday only, I could put this into usr_preferences:
attribute: cf_weekday
value: [1, 2, 3, 4, 5] (each entry is a separate row in usr_preferences)
And in kamailio config, I'd call this:
avp_db_load(...);
if(is_weekday("$avp(s:cf_weekday)")) { do CF }
So is_weekday would iterate over the entries in the avp list and return
true if the weekday at the time of routing matches an entry in the list.
A module config param could control whether to use gmtime or localtime
for matching.
Does this make sense? Suggestions for other approaches? I'd rather
prefer to do it directly in config instead of using some external
interpreter like lua, python etc.
Andreas
Hello,
We plan to use Kamailio as redirect server. Corresponding contact list is to
be fetched by a Lua script from DB.
The problem is about calling the required 'rewriteuri' function:
1. From lua script. both 'sr.rewriteuri()' and 'sr.modf("rewriteuri",
...)" fails to write the 'contact' field.
2. I tried an alternative way; pushing the value from lua (e.g.
sr.pv.sets("contact", "sip:...")) and got the value in the Kamailio.cfg
($var(contact)). But can't call the rewriteuri function with this variable's
value as argument. This seems to be a general problem of calling a function
from .cfg with a variable's value as parameter.
Any help much appreciated.
--
Sharif
Hello everyone,
I'm doing some TLS performance testing on Kamailio 3.2.1. Here's my setup:
kamailio -V
version: kamailio 3.2.1 (x86_64/linux) 31c991
flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, TLS_HOOKS,
USE_RAW_SOCKS, USE_STUN, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK,
SHM_MEM, SHM_MMAP, PKG_MALLOC, DBG_QM_MALLOC, USE_FUTEX,
FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR,
USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 4MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: 31c991
compiled on 19:38:03 Dec 20 2011 with gcc 4.4.6
uname -a
Linux null.null.com 2.6.32-220.el6.x86_64 #1 SMP Tue Dec 6 19:48:22
GMT 2011 x86_64 x86_64 x86_64 GNU/Linux
CentOS 6.2 on a Dell PowerEdge R610 with 24 Intel X5650 Cores at
2.67GHz and 12GB of RAM (I could use more).
Kamailio is the default config with a few changes:
- WITH_TLS defined
- TLS is using self-generated CAs/certs (essentially openvpn easy-rsa)
with 1024 bit key size
- TLS is *not* configured to verify client OR server certs by default
- I'm using TLS v1 (SSL 3.1)
- TLS cipher suites are set to any (although my simulated UAs only
offer AES 256+SHA)
- Various changes to Kamailio children (up to 256 at times) and memory
sizes (up to 2048mb and even 4096mb at times)
- One DNS based alias added
- Maximum TCP connections increased to 65000
- Kamailio is configured to only listen on tested IP (UDP, TCP, TLS
sockets active)
- Syslog has been configured to log local0 (Kamailio) asynchronously
My test rig/call generator is an Ixia Xcellon-Ultra NP load module
with IXLoad. My call scenario does the following:
- Registers two simulated user agents (100000, 200000) to Kamailio with TLS
- Places call from 100000 to 200000 via Kamailio with TLS
- Increments both user agents by 1 and continues as quickly (cps) as I
like up to a channel limit (also configurable)
- The Ixia generates a valid SDP but no RTP is generated (although
that's certainly possible at these call levels)
Two 1 gig ports on the Ixia are connected to the Broadcom NICs on
the Dell R610 via a Cisco Catalyst 4948 switch. One port on the Ixia
emulates the 100000 agents (A leg) and the other emulates the 200000
agents (B leg). Of course I can provide more information if needed.
Here are some test numbers:
With TLS at 20cps, 120 sec calls, up to a total of 2470 calls (4940
registrations) life is good. Very good - call setup time averages
23ms, the cps rate holds indefinitely, and not a single call or
registration fails over long term tests.
UDP and TCP numbers are excellent (bordering ridiculous) - usually
around 500cps with practically no reasonable upper limit on
simultaneous calls. This doesn't need any further discussion :).
The TLS numbers start falling apart pretty quickly after 20cps,
however. If I change the TLS test to 40cps, 120 sec calls, up to a
total of 4940 calls (9,880 registrations) Kamailio starts to
(seriously) struggle. The rate starts fluctuating all over the place,
call setup time averages jump to 8000ms (or more) and things just
generally get ugly. Interestingly enough all of the user agents are
able to register, the logs look fine (to my eye at this log level) and
the system (CPU, network, etc) doesn't appear to be under stress at
all.
I have a few questions:
1) Is there something obviously wrong or stupid I'm doing here?
2) Why are the TLS tests so much worse than TCP and UDP? Am I
missing something here?
Thanks (in advance) for any advice anyone might be able to offer!
--
Kristian Kielhofner
I have been trying to accomplish a couple tasks with Kamailio over the past
month with no luck. What I need is a bit of one-on-one training with
someone who knows the lay of the land. If you do this kind of consulting
and can use Skype with possibly a shared-screen terminal, please drop me an
email with your rate.
Hi,I'm using the new kamailio 3.2 which has some changes in rtpproxy module. And i'm finding it hard to implement a certain configuration. Because of our network infrastructure i have to repackage rtp streams in one direction. Now in kamailio 3.1.5 i used to do this in this way:In main routeroute[RTPPROXY]{if(is_method("BYE"){ unforce_rtp_proxy();else if(is_method("INVITE")){ force_rtp_proxy();}in onreply_route force_rtp_proxy("z160"); Now in kamailio 3.2 the force_rtp_proxy() is replaced by rtpproxy_manage(). Here the script reads like:main routeroute[NATMANAGE] {
#!ifdef WITH_NAT
if (is_request()) {
if(has_totag()) {
if(check_route_param("nat=yes")) {
setbflag(FLB_NATB);
}
}
}
if (!(isflagset(FLT_NATS) || isbflagset(FLB_NATB)))
return; rtpproxy_manage("z150"); if (is_request()) {
if (!has_totag()) {
add_rr_param(";nat=yes");
}
}
if (is_reply()) {
if(isbflagset(FLB_NATB)) {
fix_nated_contact();
}
}
#!endif
return;
onreply_routethis block is called route[NATMANAGE]. Now if i put rtpproxy_manage("z150"), it tries to repackage in both direction which i do not want. So i need to write a separate block for onreply_route instead of calling route[NATMANAGE]. So please help me to write a block for onreply_route.Thanks in advance.
With Best Regards
Ariful Hossain Tuhin
email: 1. etothepowerpi(a)gmail.com 2. etothepowerpi(a)hotmail.com 3.etothepowerpi(a)yahoo.com
skype: freeburn1986
Hi,
we are using the PUA_XMPP and PUA modules from the master branch. When
the modules are started, everything are ok, the presence events from
XMPP are sent to kamailio SIP servers (PUBLISH/SUBSCRIBE) and cached
in the hash. But when there are several thousands records in the hash
tabel, the update_pua function called in the hashT_clean gives a lot
of "No memory left" error when the hashT_clean is waked up from the
time:
ERROR: pua [send_subscribe.c]: No memory left
ERROR: pua [pua.c]: while building tm dlg_t structure
The failed call is:
td = (dlg_t*)pkg_malloc(size);
if(td == NULL)
{
LM_ERR("No memory left\n");
return NULL;
}
in dlg_t* pua_build_dlg_t(ua_pres_t* presentity) function in
send_subscribe.c. The size is about 400 and something... It's
strange.....
Is it the memory leak in the PUA module?
I also try to increase the pkg_memory from 4MB default to 16MB, but it
doesn't help.
Any Idea?
Thanks in advanced
Laura
Hi All
I have tried the below with Kamailio 3.1.0 and 3.2.1. the problem is
that Kamailio at times fails to start up for no obvious reasons, I.e.
in 10 restarts Kamailio might fail to start 3,0 or 5 times. Te debug
log "level 2 " shows the following :
27(24762) ERROR: db_mysql [km_my_con.c:109]: driver error: Can't
connect to MySQL server on 'xxxxxxxxx' (4)
27(24762) ERROR: <core> [db.c:303]: could not add connection to the
pool27(24762) ERROR: group [group.c:211]: unable to connect to the
database
27(24762) ERROR: <core> [sr_module.c:889]: init_mod_child(): Error
while initializing module group
(/usr/local/kamailio/lib/kamailio/modules_k/group.so)
27(24762) ERROR: <core> [pt.c:481]: ERROR: fork_tcp_process():
init_child failed for process 27, pid 24762, "tcp receiver child=1"
and then
30(24765) : <core> [pass_fd.c:293]: ERROR: receive_fd: EOF on 45
0(24735) ALERT: <core> [main.c:748]: child process 24762 exited
normally, status=255
0(24735) INFO: <core> [main.c:766]: INFO: terminating due to SIGCHLD
The problem happens on 4 different servers, I did try to compile more
than once, the servers are 32 Bit CentOS 5.6. The connection to the
database is monitored and there are no issues with connecting to the
DB "it works at times and times not for Kamailio so a user/pwd issue
is not likely to cause this, manual cnnect worked", config file errors
are not found.
I did also check max no of connections on MySQL server which is set to
500 on the server and only 100 cons are used. The group module uses
the same connection string as other modules which is predefined and
there are other modules that access the db before the group module and
those do not have a problem.
Please advice.
Regards
Hi,
Could you please tell me which of the three timer processes ("timer",
"slow timer" or "timer nh") is responsible for cleaning up the internal
usrloc cache?
Looks like every now and then the cleanup of the internal location cache
is starting to fail. Funny thing is that expired locations are removed
from the mysql backend, but not from the internal cache. We're running
kamailio 3.1.5, are there any known issues fixed since that version?
In the meanwhile we're trying to pin the issue down, but maybe someone
has a clue...
Andreas