Module: sip-router
Branch: master
Commit: e973bbe5e7310861f77b17ce0afaf1cca35fe48a
URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=e973bbe…
Author: Juha Heinanen <jh(a)tutpro.com>
Committer: Juha Heinanen <jh(a)tutpro.com>
Date: Fri May 28 15:38:41 2010 +0300
modules/tm: new implementation of load_contacts()/next_contacts()
- Simpler implementation of load_contacts()/next_contacts() functions
based on recent changes related to Request-URI handling.
- Function next_contacts() does not anymore set any timers. Check
contact_avp and call t_set_fr() before calling t_relay() instead.
- Removed fr_timer_next module parameter, because it is not needed
anymore.
---
modules/tm/README | 255 ++++++++++++++------------------------
modules/tm/doc/functions.xml | 51 +++-----
modules/tm/doc/params.xml | 73 -----------
modules/tm/doc/tm.xml | 15 +--
modules/tm/t_serial.c | 279 ++++++++++++------------------------------
modules/tm/tm.c | 1 -
6 files changed, 190 insertions(+), 484 deletions(-)
Diff: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commitdiff;h=e97…
Hi, "sip:alice@domain.org" is registered in Kamailio. If the proxy
receives a request for "sips:alice@domain.org" and invokes
"lookup(location)" the function doesn't retrieve the registration of
alice. But it should:
RFC 5630 section 3.3:
When used as the Request-URI of a request, the SIPS scheme
signifies that each hop over which the request is forwarded, until
the request reaches the SIP entity responsible for the domain
portion of the Request-URI, must be secured with TLS; once it
reaches the domain in question it is handled in accordance with
local security and routing policy, quite possibly using TLS for
any last hop to a UAS. When used by the originator of a request
(as would be the case if they employed a SIPS URI as the address-
of-record of the target), SIPS dictates that the entire request
path to the target domain be so secured.
Note the last phrase:
When used by the originator of a request
(as would be the case if they employed a SIPS URI as the address-
of-record of the target), SIPS dictates that the entire request
path to the target domain be so secured.
This is, the entire path *until* the proxy responsible for the domain
in the RURI must be secure (TLS) but it's not required (local policy)
that the destination proxy dellivers the request to the destination
user using TLS.
So IMHO lockup(location) should not inspect the registration schema. Am I wrong?
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
i understood that module functions can now have an arbitrary number of
string, int and pseudo var arguments, where string arguments can
possibly also contain pseudo variables.
some time ago i asked an example on how this is done, but didn't get any
reply. so i'll try again. for example, allow_trusted function is
now defined like this:
{"allow_trusted", (cmd_function)allow_trusted_2, 2, fixup_pvar_pvar,
fixup_free_pvar_pvar, REQUEST_ROUTE | FAILURE_ROUTE},
how can i add a third argument to the function without needing to define
yet another fixup_pvar_pvar_something?
-- juha
Hello,
there are almost 2 months since release of Kamailio 3.1.0, so it is time
for 3.1.1 as there were several important fixes done.
I propose Thursday, next week, by that time we should sort out most of
the issues reported lately.
Other opinions?
Cheers,
Daniel
--
Daniel-Constantin Mierla
Kamailio (OpenSER) Advanced Training
Jan 24-26, 2011, Irvine, CA, USA
http://www.asipto.com
I've got a strange issue with the latest kamailio. I also had this
problem with kamailio 3.0.3 downloaded from the webpage.
I can start kamailio, but after a while (sometimes within one minuten,
sometimes after an hour),
I get the following log errors:
Oct 12 15:46:24 sp01 /sbin/kamailio[26621]: ERROR: <core> [db.c:387]:
invalid type (3) or nul (0) version columns for trusted
Oct 12 15:46:24 sp01 /sbin/kamailio[26621]: ERROR: <core> [db.c:405]:
querying version for table trusted
Oct 12 15:46:24 sp01 /sbin/kamailio[26621]: ERROR: permissions
[trusted.c:249]: error during table version check.
Oct 12 15:46:24 sp01 /sbin/kamailio[26621]: ERROR: <core>
[sr_module.c:832]: init_mod_child(): Error while initializing module
permissions (//lib/kamailio/modules_k/permissions.so)
Oct 12 15:46:24 sp01 /sbin/kamailio[26621]: ERROR: <core> [pt.c:481]:
ERROR: fork_tcp_process(): init_child failed for process 10, pid 26621,
"tcp receiver child=0"
Oct 12 15:46:24 sp01 /sbin/kamailio[26621]: ERROR: <core>
[tcp_main.c:4811]: ERROR: tcp_main: fork failed: Success
Oct 12 15:46:24 sp01 /sbin/kamailio[26625]: : <core> [pass_fd.c:103]:
ERROR: recv_all: 1st recv on 21 failed: Connection reset by peer
Oct 12 15:46:24 sp01 /sbin/kamailio[26625]: : <core> [tcp_main.c:3323]:
ERROR: handle_tcp_child: read from tcp child 0 (pid 26621, no 10)
Connection reset by peer [104]
Oct 12 15:46:24 sp01 /sbin/kamailio[26625]: : <core> [pass_fd.c:293]:
ERROR: receive_fd: EOF on 19
Oct 12 15:46:24 sp01 /sbin/kamailio[26611]: ALERT: <core> [main.c:738]:
child process 26621 exited normally, status=255
Oct 12 15:46:24 sp01 /sbin/kamailio[26611]: INFO: <core> [main.c:756]:
INFO: terminating due to SIGCHLD
Oct 12 15:46:24 sp01 /sbin/kamailio[26625]: INFO: <core> [main.c:807]:
INFO: signal 15 received
Looking at the error message, it thinks that the column type of
table_version in the table version is a string (type 3), and it should
be an int (type 1).
But in the database it really is an int.
When I run kamailio with debugging on level 5, I see that it's trying to
run the "select table_version from version where table_name='trusted'"
several times when kamailio starts (for every child thread).
And then minutes, of even an hour later, it suddenly continues with that
check, but based on a database response from another query.
This is the "select password from subscriber ....etc...".
And that column is indeed an string.
I'm using PostgreSQL 8.4 as server,
but maybe someone has seen this before, or now where I have to start
looking?
I first saw it yesterday when started to use the permissions module.
I only see this with the trusted table,
And always it uses the "select password from subscriber ... " response
when giving this error.
So is this an error in the permissions module / trusted.c file?
or something in auth_db that's not freeing the response correctly?
Strange thing is, that is sometimes happens very quick, and sometimes it
can take an half hour or hour.
I can mail the full log if anybody is interested and thinks he/she can
help me.
With kind regards,
Robert Verspuy
--
*Exa-Omicron*
Patroonsweg 10
3892 DB Zeewolde
Tel.: 088-OMICRON (66 427 66)
http://www.exa-omicron.nl