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 …
[View More]get worried about that? am i missing some libraries?
--juha
[View Less]
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,…
[View More] how to solve this.
-- juha
[View Less]
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
…
[View More]will be accepted into the main trunk of kamailio?
Thanks
Vadim
[View Less]
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-…
[View More]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>
[View Less]
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.…
[View More]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>
[View Less]
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
…
[View More]The type flag is mandatory.
-- juha
[View Less]