dpkg-shlibdeps complains about lots of symbols that it cannot find, for
example:
dpkg-shlibdeps: warning: symbol core_cfg used by debian/sip-router/usr/lib/sip-router/libkmi.so.1.0 found in none of the libraries.
...
dpkg-shlibdeps: warning: symbol core_cfg used by debian/sip-router/usr/lib/sip-router/libsrdb2.so.1.0 found in none of the libraries.
...
dpkg-shlibdeps: warning: symbol mem_lock used by debian/sip-router/usr/lib/sip-router/libkcore.so.1.0 found in none of the libraries.
should i get worried about that? am i missing some libraries?
--juha
when i run
/usr/sbin/sip-router -c -d -f /etc/sip-router/sip-router.cfg
i still get lots of debug messages.
how to start sip-router so that it only prints warning and errors?
-- juha
here is one more:
return($retcode);
0(6768) : <core> [cfg.y:2921]: parse error in config file, line 2905, column 17: syntax error
0(6768) : <core> [cfg.y:2921]: parse error in config file, line 2905, column 17: ==, !=, <,>, >= or <= expected
-- juha
i got all my modules loaded. first error while processing my config was
this:
0(18354) DEBUG: <core> [sr_module.c:616]: find_param_export: parameter <onreply
_avp_mode> not found in module <tm>
0(18354) ERROR: <core> [modparam.c:143]: set_mod_param_regex: parameter <onrepl
y_avp_mode> not found in module <tm>
0(18354) : <core> [cfg.y:2921]: parse error in config file, line 407, column 37
: Can't set module parameter
migration tips doesn't tell yet, how to solve this.
-- juha
Hello,
I'd like to discuss some new functionaity for Kamailio i intend to
develop for a client.
My client need to integrate very specific transport security layer...
The layer will function over tcp and udp and will be intgreated into the
SSL framework
The client will provide a function returning SSL_METHOD * descritptor
So what i need to do is
1) Add possibility to use SSL over udp socket
2) To use a new SSL method
So my first question is: Is there any chance that such functionality
will be accepted into the main trunk of kamailio?
Thanks
Vadim
Hi, I attach a ptch for rtpproxy Debian init script which allows it being LSB
compliant.
Basically I add "--oknodo" option to all calls to "start-stop-daemon" which,
by default, is not LSB compliant.
Being LSB compliant is really useful when we want to manage a service (like
RtpProxy) using some failover system as HeartBeat, which relies on *exact*
reply code of the init scripts.
About LSB specification [1] for init scripts which I refer to:
---------------------
"For all other init-script actions, the init script shall return an exit
status of zero if the action was successful. Otherwise, the exit status
shall be non-zero, as defined below. In addition to straightforward
success, the following situations are also to be considered successful:
- Restarting a service (instead of reloading it) with the force-reload
argument
- Running start on a service already running
- Running stop on a service already stopped or not running
- Running restart on a service already stopped or not running
- Running try-restart on a service already stopped or not running"
So if I start a service that is already running I should receive 0, but
"start-stop-daemon" returns 1 (error).
The option "--oknodo" changes the behaviour to the LSB recomendations but many
services in Debian don't use this option and return 1 in the case I've
quotted. This is very problematic for me when I try to use a Debian
service init script with HeartBeat that expects to receive a 0.
-----------------------
So adding "--oknodo" to the init script, "/etc/init.d/rtpproxy start" returns
0 (no error) even if RtpProxy is already running, and "/etc/init.d/rtpproxy
stop" returns 0 (no error) even if RtpProxy is not running (as LSB mandates).
Note however that in Debian Lenny the default behaviour of "start-stop-daemon"
has changed to implement this LSB compliant behaviour by default.
This is the bug report I opened in Debian for this issue:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=426877
[1] LSB specifications about init script actions:
http://www.linux-foundation.org/spec/refspecs/LSB_3.0.0/LSB-Core-generic/LS…
Core-generic/iniscrptact.html
--
Iñaki Baz Castillo <ibc(a)aliax.net>
Hi, using multiple RtpProxy instancies would be more flexible if
set_rtp_proxy_set() allows a pseudo-variable instead of just a fixed integer.
Without this feature, it's impossible to implement real RtpProxy loadbalancing
since: how to use the same RtpProxy for an in-dialog request? Let me show an
example:
- Let's suppose we have these rtpproxies:
modparam("nathelper", "rtpproxy_sock",
"1 == udp:1.1.1.1:12221")
modparam("nathelper", "rtpproxy_sock",
"2 == udp:2.2.2.2:12221")
(note that I don't use various rtpproxies in the same set since with the, real
loadbalancing it's not possible).
- An INVITE arrives and we want to use a ramdom rtpproxy (set 1 or 2). Since
set_rtp_proxy_set() doesn't allow pv, the only way is something as computing
the from_tag or call-id and get values 0 or 1 (or 1 or 2). In the first case
we invoke set_rtp_proxy_set("1") and in the second set_rtp_proxy_set("2").
- When processing the 183/200 response we should do the same (get 1 or 2 from
the from_tag or call-id), or perhaps add a parameter in RR (rtpproxy_set=1)
and invoke the corresponding set_rtp_proxy_set() function.
- The same for every in-dialog request (re-INVITE, BYE...).
I understand that this mechanims is not really scalable since adding a new
rtpproxy requires modifications in the kamailio script (the ramdom function
which now should return 1, 2 or 3 depending on the call-id/from_tag hash or
something similar) and also adding a new "else if (XXXXX) {
set_rtp_proxy_set("3") ... }"
So, extending set_rtp_proxy_set() to allow pv would mitigate this issue:
- When the INVITE arrives a ramdom function returns 1,2,3..., we store that
value in a pv and use it into set_rtp_proxy_set().
- We also store that value in a RR param to retrieve it in replies and in-
dialog requests in order to invoke the samertpproxy set.
About various rtpproxy instances per set:
I consider there is no solution for it. If we have:
# multiple rtproxies for LB
modparam("nathelper", "rtpproxy_sock",
"udp:localhost:12221 udp:localhost:12222")
We invoke "rtpproxy_offer" and some rtpproxy has been transparently selected,
but we CANNOT know which one, so, how to reuse it in the reply and in-dialog
requests??
I remember a thread about it in which the code was inspected and some "hash
algorithm" resulted to take place to select the rtpproxy instance. However I
remember that this algorithm is not so robust as required for a real
loadbalancing system.
So, in conclusion, is there any aim in improving RtpProxy module to allow real
and robust load-balancing? What about multiple rtpproxy instances in the same
set? is it really usable?
Thanks a lot for any comment on it.
--
Iñaki Baz Castillo <ibc(a)aliax.net>
Hi, when rtpproxy is running as non root user, it gives this error for
each request (anyway it doesn't fail):
ERR:create_twinlistener: unable to set TOS to 184: Operation not permitted
I've not checked it running as root however. How could I avoid this
error? I don't see options in rtpproxy to dissable the TOS
modification.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
i'm getting lots of these:
0(13997) WARNING: <core> [usr_avp.c:882]: i: and s: avp name syntax is deprecated!
and didn't find anything about that on tips page.
where is the new avp name syntax explained?
modules_k/avpops/README still has this:
* avp_flags = type_flags [script_flags]; type_flags = 'I' |
'i' | 'S' | 's'; script_flags = 0..255
'I' or 'i' means that the type of avp name is integer (ID)
'S' or 's' means that the type of avp name is string
The type flag is mandatory.
-- juha