Hi, just wondering if this issue is still being considered. Thanks, steve
From: Users [mailto:users-boun...@lists.opensips.org] On Behalf Of Steve Brisson Sent: Thursday, January 11, 2018 11:56 AM To: OpenSIPS users mailling list <users@lists.opensips.org> 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:users-boun...@lists.opensips.org] On Behalf Of Liviu Chircu Sent: Thursday, January 11, 2018 3:39 AM To: users@lists.opensips.org<mailto:users@lists.opensips.org> 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 Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
