2 Mar
2009
2 Mar
'09
11:49 p.m.
Hi, a current limitation in Kamailio (and AFAIK also in SER) is that TCP
childs block waiting for the connection being established or ended.
For example, if we run Kamailio with "tcp_children=8" and receive 8
"hacked"
INVITE's via UDP like:
INVITE sip:hello@non.responding.host1;transport=TCP SIP/2.0
INVITE sip:hello@non.responding.host2;transport=TCP SIP/2.0
INVITE sip:hello@non.responding.host3;transport=TCP SIP/2.0
...
INVITE sip:hello@non.responding.host2;transport=TCP SIP/2.0
then Kamailio will have all their TCP childs busy waiting for 8 outgoing TCP
connections to timeout. If a new request requires TCP it must wait for long
time until one of the TCP childs becomes available.
Of course this can be very easily hackeable by an attacker.
To improve it, a TCP child should not block waiting for the TCP connection to
end.
Perhaps I'm wrong (I will check it in a testing escenario soon). If not, is it
planned to improve it?
Thanks a lot.
--
Iñaki Baz Castillo
3 Mar
3 Mar
7:55 a.m.
New subject: [SR-Dev] Will SIP-Router handle better TCP childs avoiding blocking?
On Mar 02, 2009 at 23:49, I??aki Baz Castillo <ibc(a)aliax.net> wrote:
Hi, a current limitation in Kamailio (and AFAIK also
in SER) is that TCP
childs block waiting for the connection being established or ended.
If you set tcp_async=yes (or its obsoleted alias tcp_buf_write) in the
config it will be non-blocking. I'm still considering whether or not to
make it the default.
The only problem right now is that tls doesn't work with tcp in async
mode (it needs an important update which was postponed because of the
merger).
Andrei
8:51 a.m.
New subject: [SR-Dev] Will SIP-Router handle better TCP childs avoiding blocking?
Andrei Pelinescu-Onciul writes:
If you set tcp_async=yes (or its obsoleted alias
tcp_buf_write) in the
config it will be non-blocking. I'm still considering whether or not to
make it the default.
if it works, i think it should be default.
if tcp connection establishment fails, will failure route (if set) be
executed? in kamailio it will not, which is a BIG mess.
-- juha
8:58 a.m.
New subject: [SR-Dev] Will SIP-Router handle better TCP childs avoiding blocking?
On Mar 03, 2009 at 09:51, Juha Heinanen <jh(a)tutpro.com> wrote:
Andrei Pelinescu-Onciul writes:
No, if connect or send fails you'll have to rely on tm timeouts.
If the connect or send fails immediately (never seen in practice but
theoretically possible), it behaves like the old tcp.
BTW: I don't think that for immediate errors (like send failing in
kamailio tcp) one should call the failure route. You can always detect this
using something like if (t_relay())... and you have more control this way.
Andrei
If you set tcp_async=yes (or its obsoleted alias
tcp_buf_write) in the
config it will be non-blocking. I'm still considering whether or not to
make it the default.
if it works, i think it should be default.
if tcp connection establishment fails, will failure route (if set) be
executed? in kamailio it will not, which is a BIG mess.
9:12 a.m.
New subject: [SR-Dev] Will SIP-Router handle better TCP childs avoiding blocking?
Andrei Pelinescu-Onciul writes:
BTW: I don't think that for immediate errors (like
send failing in
kamailio tcp) one should call the failure route. You can always detect this
using something like if (t_relay())... and you have more control this
way.
andrei.
more control, but config file becomes a real mess, because the same
handling of failure needs to be done in two places. in my opinion,
t_relay failure is a failure no matter if it is caused be tcp connection
establishment failure or failure to receive a response on an established
tcp connection or on udp packet. it is really stupid if script writer
needs to care about if tcp or udp is used by t_relay and at what point
the failure occurred.
--juha
9:19 a.m.
New subject: [SR-Dev] Will SIP-Router handle better TCP childs avoiding blocking?
On Mar 03, 2009 at 10:12, Juha Heinanen <jh(a)tutpro.com> wrote:
Andrei Pelinescu-Onciul writes:
The same thing can happen for udp too, albeit only in special cases
(udp send can fail albeit very rarely, the most common case being
firewall rules on output on the local machine that use REJECT).
You don't need to care about the protocol being used. It could be as
simple as checking the return of a t_* function and calling a route().
Andrei
BTW: I don't think that for immediate errors
(like send failing in
kamailio tcp) one should call the failure route. You can always detect this
using something like if (t_relay())... and you have more control this
way.
andrei.
more control, but config file becomes a real mess, because the same
handling of failure needs to be done in two places. in my opinion,
t_relay failure is a failure no matter if it is caused be tcp connection
establishment failure or failure to receive a response on an established
tcp connection or on udp packet. it is really stupid if script writer
needs to care about if tcp or udp is used by t_relay and at what point
the failure occurred.
9:30 a.m.
New subject: [SR-Dev] Will SIP-Router handle better TCP childs avoiding blocking?
Andrei Pelinescu-Onciul writes:
The same thing can happen for udp too, albeit only in
special cases
(udp send can fail albeit very rarely, the most common case being
firewall rules on output on the local machine that use REJECT).
You don't need to care about the protocol being used. It could be as
simple as checking the return of a t_* function and calling a
route().
i have failure_route that handles failure to deliver a request to a
contact. i cannot call failure_route from a route block. a logical
conclusion of your suggestion is to abolish failure_routes completely,
just have routes.
-- juha
12:01 p.m.
New subject: [SR-Dev] Will SIP-Router handle better TCP childs avoiding blocking?
2009/3/3 Juha Heinanen <jh(a)tutpro.com>om>:
Andrei Pelinescu-Onciul writes:
A dirty workaround is having a *route* to handle the failure, and call
that *route* from failure_route or also when "tm_relay" returns error.
Obviously this is really a pain.
I agree in which it would be a homogenous behaviour.
The same thing can happen for udp too, albeit
only in special cases
(udp send can fail albeit very rarely, the most common case being
firewall rules on output on the local machine that use REJECT).
You don't need to care about the protocol being used. It could be as
simple as checking the return of a t_* function and calling a
route().
i have failure_route that handles failure to deliver a request to a
contact. i cannot call failure_route from a route block. a logical
conclusion of your suggestion is to abolish failure_routes completely,
just have routes.
Instead of that I would really prefer abolishing tm_realy return
codes, but this would require really complex and long scripts (a
failure_route for each tm_realy call).
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
5557
days inactive
5558
days old
7 comments
3 participants
participants (3)
-
Andrei Pelinescu-Onciul -
Iñaki Baz Castillo -
jh＠tutpro.com