Strict Standards: call_user_func() expects parameter 1 to be a valid callback, non-static method dokuwiki_TextFormatter::render() should not be called statically in /var/www/sip-router.kamailio.org/flyspray/includes/class.tpl.php on line 552

Strict Standards: call_user_func() expects parameter 1 to be a valid callback, non-static method dokuwiki_TextFormatter::render() should not be called statically in /var/www/sip-router.kamailio.org/flyspray/includes/class.tpl.php on line 552

Details

When using tcp_async=yes, tcp_connect_timeout has no effect at all. I set it to 3 seconds and try sending a request with RURI “sip:lalalala@91.121.79.216:7777;transport=tcp”. The server 91.121.79.216 refuses the TCP connection (REJECT action in iptables rather than DROP), try yourself:

However when my Kamailio tries to open a TCP connection with such destination, it produces a local 408 after 30 seconds (fr_timer = 30000)!

Since Kamailio should detect that the TCP connection is rejected, I expect that it should generate an inmediate local 503 for the client transaction as RFC 3261 states.

I attach a file kamailio-tcp-reject.log which shows the issue. It clearly shows that tcp connection attemp fails inmediately (due to TCP reject) but it does not terminate the client transaction and instead it takes 30 seconds until it generates local 408:

I’ve also tested sending a TCP INVITE to a host which is not reachable (1.2.3.4) so TCP timeouts occurs (after 5 seconds rather than 3 however...) but as in the other case, such TCP timeout does not terminate the client transaction and instead local 408 is generated after 30 seconds (I attach kamailio-tcp-timeout.log):

Closed by Daniel-Constantin Mierla (miconda)
Tuesday, 23 December 2014, 09:48 GMT Reason for closing: Won't implementAdditional comments about closing: Should this still be addressed, given
the timeout option, the item must be
re-opened on github issues.

Strict Standards: call_user_func() expects parameter 1 to be a valid callback, non-static method dokuwiki_TextFormatter::render() should not be called statically in /var/www/sip-router.kamailio.org/flyspray/includes/class.tpl.php on line 552

I assume what is happening:

When tcp_async=no, the worker itself open the TCP connection (which of course is bad as it gets blocked for a while) and can detect TCP failures or timeouts.

When tcp_async=yes, the worker just sends the message to some TCP process and inmediately returns so can handle other TCP requests. Then it just expects a SIP response associated to the client transaction from the transactiin layer, and it’s not aware of TCP rejection or timeouts.

If I’m not wrong in the above, could the tcp_async=yes mode be improved so some worker is notified about TCP rejection or timeout?

Strict Standards: call_user_func() expects parameter 1 to be a valid callback, non-static method dokuwiki_TextFormatter::render() should not be called statically in /var/www/sip-router.kamailio.org/flyspray/includes/class.tpl.php on line 552

Comment by Andrei Pelinescu in the devel maillist:

Yes, it’s a known limitation. Basically when async it’s own, tm has no way of knowing that a connect() has failed and would have to rely on sip timeout.Of course these could be changed, but it would have both performance and memory usage impact and it would be very hard to integrate with tls. I would rather not do it in the near future.

The tcp_connect_timeout refers to how long the tcp connect will be attempted, but it’s not linked to tm. The value is not 100% exact, the tcp timers are executed on a best effort basis, at most at 5s intervals and at minimum 1/16 seconds, so you should expect a 5s error If it’s too much for you, change TCP_MAIN_SELECT_TIMEOUT and TCP_CHILD_SELECT_TIMEOUT in tcp_conn.h (btw. we don’t use select() anymore, the names where not updated when we switched toepoll/kqueue/dev_poll).