2011/6/23 Andrei Pelinescu-Onciul <[email protected]>: > 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.
Ok, I understand. It would be great to have it however. In the other side, this has an unexpected advantage: It unifies both behaviours of UDP and TCP/TLS. In sync mode, if a TCP connection fails t_relay returns an error and doesn't execute on_failure_route block (I still this is a bug in the design as a TCP connection error should trigger a local 503 so on_failure_route should be called with such 503 as winning reply). Anyhow, in async mode, due to the explained limitation, a TCP connection error would generate a local timeout so on_failure_route would be called with 408 as winning reply. This allows unifying code for UDP and TCP in the script. > 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 to > epoll/kqueue/dev_poll). Thanks, I don't need it to be less than 5 seconds, neither I care it as anyway I must wait fr_timer seconds :) Thanks a lot. -- Iñaki Baz Castillo <[email protected]> _______________________________________________ sr-dev mailing list [email protected] http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
