Hi Steve,
I've opened a GitHub issue for this report so we can better keep track
of it [1], and will likely be next on my priority list.I will try to
find some time to attempt to reproduce it asap. In the meanwhile, would
you be as kind as to supply some debug logs while the async TCP reads
are piling up? You may ship themto [email protected].
Best regards,
[1]: https://github.com/OpenSIPS/opensips/issues/1259
Liviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.com
On 18.01.2018 18:35, Steve Brisson wrote:
Hi, just wondering if this issue is still being considered.
Thanks,
steve
*From:*Users [mailto:[email protected]] *On Behalf Of
*Steve Brisson
*Sent:* Thursday, January 11, 2018 11:56 AM
*To:* OpenSIPS users mailling list <[email protected]>
*Subject:* Re: [OpenSIPS-Users] tcp_async timeouts confusion
TCP scenario:
Yes that is exactly correct. If I have tcp_connect_timeout=3000 and
tcp_async=1 configured then calls to the vcs fail. If I then make the
single change to disable tcp_async, calls to my vcs endpoints will work.
TLS scenario:
Thanks for the clarification, makes sense. Unfortunately the online
documentation doesn't describe the parameters and lists an incorrect
scaling factor (it's defined in milliseconds, not seconds).
steve
*From:*Users [mailto:[email protected]] *On Behalf Of
*Liviu Chircu
*Sent:* Thursday, January 11, 2018 3:39 AM
*To:* [email protected] <mailto:[email protected]>
*Subject:* Re: [OpenSIPS-Users] tcp_async timeouts confusion
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
_______________________________________________
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
