Answers below,
On 09.01.2018 22:25, Steve Brisson wrote:
*** Using TCP ***
After the invite is sent to the vcs, tcpdump at the opensips server
showed 100, 180, and 200 OK responses from the vcs arriving and ACK'd
correctly at the opensips server. The 100 response arrived 185ms after
the invite is sent. But, I don't see these responses in the branch's
onreply_route, the global onreply_route, or in the log at DBG level.
netstat -t shows the connection with the data in the recv-q that never
reaches 0. This implies to me that opensips is not polling that
connection correctly for recv data.
If I disable tcp_async then the call is completed successfully. So in
the case that works, I have tcp_connect_timeout=3000 and tcp_async=0.
Just to confirm the scenario: So the signaling is broken with
"tcp_connect_timeout=3000 and tcp_async=1" (reply routes do not get
triggered / recv-q keeps on growing), however once you switch to
"tcp_async=0", everything is back to working?
*** Using TLS ***
Running tcpdump, I see the opensips server send a Client Hello then a
FIN packet 100ms later. The vcs responds with a Server Hello 200ms
after the Client Hello and this gets RST.
To workaround this case, I set tls_handshake_timeout=3000 and
tls_send_timeout=1000. Maybe this is the correct behavior, I'm still
not 100% sure how the tls parameters function.
This time, it's behaving as expected. Maybe there should be a diagram
somewhere with how these parameters work together. For example, each TLS
connection will roughly follow the below steps along with their
corresponding parameterized timeouts:
1. TCP connect (tcp_connect_timeout)
2. TLS connect/accept handshake (tls_handshake_timeout)
3. TLS write (tls_send_timeout)
4. TLS write (tls_send_timeout)
Liviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.com
*From:*Users [mailto:[email protected]] *On Behalf Of
*Liviu Chircu
*Sent:* Tuesday, January 9, 2018 3:20 AM
*To:* [email protected]
*Subject:* Re: [OpenSIPS-Users] tcp_async timeouts confusion
Hi, Steve!
The transport layer was heavily refactored roughly three years ago,
see [1], [2] and [3] for the relevant commits which, indeed, bumped
the default connect timeout down a lot, to a much lower value (10s ->
100ms). Although 100ms might seem unnecessary (it's async! let it
sleep as long as it wants!), keep in mind that the TLS support isn't
async at all, yet it will also make use of the same, default
"tcp_connect_timeout" - a 10s default here is quite bad for high
traffic volume TLS proxies which often need to open up lots of TCP/TLS
connections.
All in all, the "tcp_connect_timeout" should not get ignored at all.
The "tcp_async_local_connect_timeout" [4] is the first one that hits,
after which the connect waiting will be performed by a non-TCP worker,
up to "tcp_connect_timeout" milliseconds. If it doesn't behave like
this, let us know, and we'll look into it more.
Best regards,
[1]: https://github.com/OpenSIPS/opensips/commit/b343ca1c
<https://github.com/OpenSIPS/opensips/commit/b343ca1c>
[2]: https://github.com/OpenSIPS/opensips/commit/78c84620
[3]: https://github.com/OpenSIPS/opensips/commit/11aedc6
<https://github.com/OpenSIPS/opensips/commit/11aedc6>
[4]:
http://www.opensips.org/html/docs/modules/2.4.x/proto_tcp.html#idp5544000
Liviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.com
On 08.01.2018 22:38, Steve Brisson wrote:
Hi,
I've run into some issues related to tcp_async and tcp/tls
timeouts since upgrading opensips from v1.8 to v2.3.
Based on my v1.8 config, I had the tcp_connect_timeout set to 3
secs but this gets ignored in v2.3 because tcp_async is enabled by
default. As a result, calls made from a local opensips endpoint to
a remote registered endpoint (through a cisco vcs) were failing. I
then noticed that the tcp/tls timeouts were aggressively reduced
from 10-30s to 100ms by default with the tcp_async feature.
My main questions are:
- How is the tcp_async feature supposed to function if the
tcp_async_local_connect_timeout expires? The code seems to imply
that the socket gets put onto a tcp main thread and handled.
- 100ms seems pretty short as a default for these timeouts,
especially tls. Does a timeout result in the sip request getting
cancelled or is there still some processing that can occur after
because of handling on the tcp main thread.
In short, I'm a confused about what the tcp_async feature does and
how the timeouts should be set. Any explanations would be greatly
appreciated.
Thanks for your time.
steve
_______________________________________________
Users mailing list
[email protected] <mailto:[email protected]>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
