Hi, I set "from_uri = out" in "lcr" table. Then I call:
$var(destination) = "out";
load_gws("$var(destination)")
or:
$var(destination) = "no-out";
load_gws("$var(destination)")
or:
$var(destination) = "no-out-lalala";
load_gws("$var(destination)")
In any case LCR matches the rules of "lcr" table with "from_uri = out" !!!
If I set:
$var(destination) = "nooooo";
load_gws("$var(destination)")
then rules are not loaded (as expected).
So it seems that load_gws(pvar) does an internal match like:
if table_from_uri =~ /PVAR_VALUE/
IMHO it should do:
if table_from_uri =~ /^PVAR_VALUE$/
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task is now closed:
FS#7 - speex, sems and mi_datagram with quotes
User who did this - Daniel-Constantin Mierla (miconda)
Reason for closing: Not a bug
Additional comments about closing: The MI command coming from sems must escape inner double-quotes. Otherwise it breaks MI cmd format, where multiline parameters are enclosed in double-quotes and followed by new line.
FYI, last sems supports SIP natively, MI communication is pretty much obsolete.
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=7
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has a new comment added:
FS#66 - In daemonize mode parent process should exit with error (-1) if main process fails to start
User who did this - marius zbihlei (marius.zbihlei)
----------
- Replaced the blocking read() with a more versatile select() that timeout after 30 s
- Formatted the patch
- Fixed a double close of the write fd of the pipe in the main process
- TODO: better handling of EINTR in case of select()
----------
One or more files have been attached.
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=66#comment80
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task is now closed:
FS#2 - Change syntax of fr_{inv}_timer_avp parameters of tm module
User who did this - Daniel-Constantin Mierla (miconda)
Reason for closing: Fixed
Additional comments about closing: TM support now $avp(name) format. The old one is still possible as alternative, subject to be removed in near future.
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=2
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
Hi, I've submitted some patches to the SR tracker in order to improve
something that I consider buggy (and for sure it is):
http://sip-router.org/tracker/index.php?do=details&task_id=66
As explained in the tracker, in daemonize mode kamailio doesn't return
the proper status code. If for example the listen address is not local
or a DB connection uses an invalid password, then the command
"kamailio" would return 0 (OK) anyway (even if it fails to start).
This occurs because all those checking (socket, DB connections...) are
performed *after* invoking daemonize() so the parent process (which
could be invoked by "/etc/init.d/kamailio start") returns 0 knowing
nothing about those errors. In fact the only checking done before
daemonizing is the config file parsing.
The patches I've upload to the tracker improve/fix it by doing the following:
- 'daemonize()' function doesn't exit the parent process, instead the
parent process gets blocked in 'main()' function reading a pipe.
- When the main process initializes the modules, sockets and so, it
writes into the pipe so the parent process exists with 0.
- If the main process fails to start then the pipe write fd is closed
with no more processes writting into it so the parent process detects
it and exists with -1 error.
I've checked it and works ok. You can try to set a wrong MySQL
password or a wrong listen address and run kamailio in daemonize mode.
Check the exit status so you will get error code rather than 0 (as
occurs without these changes).
This is strongly required when working with HeartBeat (and any other
software managing daemons) because HeartBeat relies on the init script
returned status codes.
Imagine for example that a MySQL password is changed. For any reason
HeartBeat decides to change the service to nodo-2. This is what would
happen without the proposed changes:
- HeartBeat invokes "/etc/init.d/kamailio start".
- It returns 0 even if it fails to start due to MySQL password.
- HeartBeat invokes periodically "/etc/init.d/kamailio monitor"
(similar to "status") which would return 1 (it's not running).
- Then HeartBeat tries to start it again. And of course, it receives 0 again.
- Loop...
This is, a init script return codes are *important* and current
SR/Kamailio doesn't do it well as it fails in daemonize mode.
I will use these patches in production very soon as I'm building some
platforms of Kamailio+HeartBeat and this is really required. If
somebody could review than patches it should be great.
Regards.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
if tcp uas is not reachable, sr prints ERRORs to syslog:
Apr 20 13:23:10 localhost /usr/sbin/sip-proxy[22508]: INFO: Routing first INVITE to <sip:foo@192.98.102.10:4040;transport=tcp> and <<null>>
Apr 20 13:23:10 localhost /usr/sbin/sip-proxy[22508]: ERROR: tm [../../forward.h:169]: msg_send: ERROR: tcp_send failed
Apr 20 13:23:10 localhost /usr/sbin/sip-proxy[22508]: ERROR: tm [t_fwd.c:1249]: ERROR: t_send_branch: sending request on branch 0 failed
since this is not really an error, would it be possible to downgrade the
messages to WARNINGs?
-- juha