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
Hi,
whats about: http://sip-router.org/tracker/index.php?do=details&task_id=108 I think that some users are trying to register to an asterisk system. Or does somebody have a solution for that?
A new release would be nice!!!
Thanks in advance.
Best regards,
Bernhard
----- Original Message -----
From: Daniel-Constantin Mierla [mailto:miconda@gmail.com]
To: kamailio [mailto:sr-users@lists.sip-router.org], sr-dev [mailto:sr-dev@lists.sip-router.org]
Sent: Fri, 28 Jan 2011 20:15:50 +0100
Subject: [sr-dev] planning release of v3.1.2
> Hello,
>
> I think it is time to release v3.1.2, first date that comes in my mind
> is next Thursday if everyone feels it is enough time to take care of
> backporting any fix he/she did and it is not yet there. That will
> provide us a fresh release for the FOSDEM event. If not, then maybe the
> other week, Tuesday, so the participants at the Kamailio Devel training
> in Barcelona can practice on it.
>
> Soon after we should plan also a release for previous stable, branch 3.0.
>
> Anyone having other options?
>
> Thanks,
> Daniel
>
> --
> Daniel-Constantin Mierla
> http://www.asipto.com
>
>
> _______________________________________________
> sr-dev mailing list
> sr-dev(a)lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>
Hello,
I think it is time to release v3.1.2, first date that comes in my mind
is next Thursday if everyone feels it is enough time to take care of
backporting any fix he/she did and it is not yet there. That will
provide us a fresh release for the FOSDEM event. If not, then maybe the
other week, Tuesday, so the participants at the Kamailio Devel training
in Barcelona can practice on it.
Soon after we should plan also a release for previous stable, branch 3.0.
Anyone having other options?
Thanks,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com
Hi Kamailio Users,
I'm trying to use LCR module in Kamailio 3.1.1 and I', having some
problems with this function (load_gws).
I'm my kamailio.cfg , I have this route:
# SEARCH DEST
route[NUMBER] {
xlog("L_ALERT", "NUMBER IS $rU \n");
if ($rU=~"^55211020[0-9]{4}$") { # IS MY USERS
route(LDAP_NUM2USER);
} else { # NOT IS MY USER
if (!load_gws(1,$rU)) {
xlog("L_ALERT", "LOAD LOCAL GW FAILED $rU \n");
route(DSER);
return;
} else {
xlog("L_ALERT", "LOAD GW DEBUG $avp(i:709)\n");
} ;
if (!next_gw()) {
xlog("L_ALERT", "NEXT LOCAL GW FAILED\n");
sl_send_reply("503", "Service not available -
No gateways");
return;
};
setflag(29);
route(RELAY);
return;
};
};
When my call arrive to load_gws, I have this problem:
(2198) ERROR: <core> [action.c:1158]: runtime fixup failed for load_gws param 2
(2198) ERROR: <core> [action.c:1511]: run action error at:
/etc/kamailio/kamailio.cfg:472
I already saw the Kamailio Code and this error doesn't make sense.
Would somebody Help me with it?
Very thanks,
Thiago Maluf.
----------------------------------------------------------------
Thiago Maluf Resende
Tel: +55 21 9700-9113
e-mail: malufrj(a)gmail.com
Heisann,
the last couple of days, I had the pleasure of building Kamailio 3.1.1
RPMs. Now that the trauma is slowly wearing off, I have two things worth
discussing here (or so I believe).
One is that I was building for x86_64. In this system, libraries should
go into lib64 but module and library directory seem to be hardcoded to
lib/$(MAIN_NAME)/ in Makefile.defs. Did I miss the place to switch this
or should one be reconsidered?
Simply moving the whole /usr/lib/kamailio tree to /usr/lib64/kamailio
didn't quite do the trick since the path seems to be embedded in the
modules that require some of the shared libraries.
Second, there was some fun little breakage with the MySQL module.
Because of the way the module's Makefile adds -L directories to the LIBS
variable, the linker happily linked against libmysqlclient16.a but
somehow forgot to add the libraries that libmysqlclient in turn depends
on. I am not quite sure on the mechanics, but presumably libtool takes
care of this in the GNU toolchain?[0]
In any case, I didn't really want a statically linked MySQL client to
begin with. Dropping all the -Ls did that trick. That may or may not be
the proper way to do this.
I have limited the build to the modules I need or that don't depend on
anything funny (this is RHES/Centos, so all you get is Gnome and Firefox
and other things very important for servers). Given the time invested so
far, I am willing to test my newfound knowledge and give building a full
set of packages a try, unless there is dependencies particularly hard to
satisfy.
I believe Ovidiu has done the RPMs for Centos so far. Maybe we can
coordinate work on this?
Best regards,
Mar"don't you dare saying Debian"tin
[0] If the .la files are used also if you don't use the whole
automagick, then the reason possibly is that the libmysqlclient16.la
that comes with MySQL's own community RPMs is broken since it
doesn't list any dependencies. Maybe everything is fine with the MySQL
client packages that come with Centos 5. Unfortunately, they date
from the late Cambrian or so I have been given to understand.