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.
On Mar 02, 2009 at 23:49, I??aki Baz Castillo ibc@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
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
On Mar 03, 2009 at 09:51, Juha Heinanen jh@tutpro.com wrote:
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.
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
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
On Mar 03, 2009 at 10:12, Juha Heinanen jh@tutpro.com wrote:
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.
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
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
2009/3/3 Juha Heinanen jh@tutpro.com:
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 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.
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).
-
Andrei Pelinescu-Onciul -
Iñaki Baz Castillo -
jh＠tutpro.com