Hi all,
during my tests for the cr module i noticed some differences in the reply
matching in sr tm and kamailio tm. My test "26" basically test the (cr)
failure_route functionality with a simple sipp scenario.
On kamailio 1.5 branch my test is successful, the 503 reply is matched against
the first INVITE and the failure_route is entered. On sip-router its not
matched, a local 408 is generated after some time. I've attached the sip trace
and the debug logs from both tests runs.
Perhaps the sip-router tm is more strict in the matching, so because of some
problem in the sipp scenario it don't match? Would be cool if somebody with
more experiences with sr tm could take a look to this. The scenario,
configuration and test is test/unit/failure_route.xml, 26.cfg and 26.sh (same
directory).
Thanks,
Henning
Hello,
I just introduced support for a new type of route in configuration file
- event_route. The prototype for it is:
event_route[groupid:eventid] {
[actions]
}
The main purpose for it is to allow modules (and core) to be able to
execute code written in configuration file when a specific event
happens, without altering the config grammar. Also, in short term, the
modules that fire events should be able to impose what type of actions
can be used in the respective event_route - now functions allowed in
request route can be used.
First module that uses this feature is htable, executing an event route
only once, when all modules were initialized. A typical use case is to
initialize some items in a hash table. Example:
modparam("htable", "htable", "a=>size=4;")
event_route[htable:mod-init] {
$sht(a=>calls-to::10.10.10.10) = 0;
$sht(a=>max-calls-to::10.10.10.10) = 100;
}
route {
if(is_method("INVITE") && !has_totag())
{
switch($rd) {
case "10.10.10.10":
lock("calls-to::10.10.10.10");
$sht(a=>calls-to::10.10.10.10) =
$sht(a=>calls-to::10.10.10.10) + 1;
unlock("calls-to::10.10.10.10");
if($sht(a=>calls-to::10.10.10.10)>$sht(a=>max-calls-to::10.10.10.10))
{
sl_send_reply("500", "To many calls to .10");
exit;
}
break;
...
}
}
}
This system will be used to get kamailio's error_route and local_route
functionalities. Other cases I have in mind now are:
- auto-expired dialog route introduced in kamailio 1.5.0 to become
event_route[dialog:auto-expired]
- call event route when a location record has expired on timer:
event_route[usrloc:auto-expired] making available via PV details of
expired contact
- rtimer module routes to become event routes
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com/
Robin Vleij writes:
> The core dump showed some stuff which I then connected to the
> following theads on the opensips list:
>
> http://lists.opensips.org/pipermail/devel/2008-December/001566.html
> Question is, was this fixed in Kamailio 1.4.4 as well? I can't find
> anything about it and since the projects are not the same anymore I'm
> not sure that we take each others fixes.
robin,
looks like this is the fix:
http://opensips.svn.sourceforge.net/viewvc/opensips/trunk/modules/tm/t_hook…
and it has not been applied to kamailio. perhaps daniel can check it.
i'll cc to sip-router folks so that they can make sure that the crash
does not occur there.
-- juha
Hello,
please find attached a patch for the nathelper module from the modules_s
directory.
It aims to fix the issue that if you call fix_nated_contact() on IPv6
addresses the fixed URI does not contain the required [] around the IPv6
IP address of the URI.
Andrei: are the helper functions in ip_addr.h do not add the [] on
purpose? I fixed this in the module directly because I assumed it could
break other things if I would fix it directly in ip_addr.h.
Who ever feels himself responsible for the nathelper module could please
review the patch and let me know if I should commit the patch.
Thanks
Nils
Index: nathelper.c
===================================================================
RCS file: /cvsroot/ser/sip_router/modules/nathelper/nathelper.c,v
retrieving revision 1.135
diff -a -u -r1.135 nathelper.c
--- nathelper.c 8 Dec 2008 11:26:49 -0000 1.135
+++ nathelper.c 20 May 2009 02:33:37 -0000
@@ -628,6 +628,9 @@
cp = ip_addr2a(&msg->rcv.src_ip);
len = c->uri.len + strlen(cp) + 6 /* :port */ - hostport.len + 1;
+ if (msg->rcv.src_ip.af == AF_INET6) {
+ len += 2; /* [...] */
+ }
buf = pkg_malloc(len);
if (buf == NULL) {
LOG(L_ERR, "ERROR: fix_nated_contact: out of memory\n");
@@ -636,8 +639,14 @@
temp[0] = hostport.s[0];
temp[1] = c->uri.s[c->uri.len];
c->uri.s[c->uri.len] = hostport.s[0] = '\0';
- len1 = snprintf(buf, len, "%s%s:%d%s", c->uri.s, cp, msg->rcv.src_port,
- hostport.s + hostport.len);
+ if (msg->rcv.src_ip.af == AF_INET6) {
+ len1 = snprintf(buf, len, "%s[%s]:%d%s", c->uri.s, cp, msg->rcv.src_port,
+ hostport.s + hostport.len);
+ }
+ else {
+ len1 = snprintf(buf, len, "%s%s:%d%s", c->uri.s, cp, msg->rcv.src_port,
+ hostport.s + hostport.len);
+ }
if (len1 < len)
len = len1;
hostport.s[0] = temp[0];