[OpenSIPS-Users] tcp_async timeouts confusion
Liviu Chircu
liviu at opensips.org
Fri Jan 19 08:16:17 EST 2018
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 liviu at opensips.org.
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:users-bounces at lists.opensips.org] *On Behalf Of
> *Steve Brisson
> *Sent:* Thursday, January 11, 2018 11:56 AM
> *To:* OpenSIPS users mailling list <users at 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-bounces at lists.opensips.org] *On Behalf Of
> *Liviu Chircu
> *Sent:* Thursday, January 11, 2018 3:39 AM
> *To:* users at lists.opensips.org <mailto:users at 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 at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180119/acfe9724/attachment.html>
More information about the Users
mailing list