Hi Ryan,

Indeed, thetcp_no_new_conn_bflag will prevent opensips to open new TCP connections when sending out a request. The key questions is: the blocking was during a connect (trying to open a new conn) or during a write (over an existing conn). If the second case (which is likely based on the logs you posted), you should take a closer look at the write timeout settings:


Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
OpenSIPS Summit 2019

On 02/19/2019 08:50 PM, Ryan Delgrosso wrote:
So I have a situation where 100% of my endpoints are TLS behind NAT bridging to UDP in core.

I have tcp_async enabled and have set tcp_no_new_conn_bflag on packets coming from UDP side to TLS side, as well as setting it on the registered AOR's in mid-registrar.

Setting up test scenarios I always seem to hit a wall where opensips stops passing packets where it seems to be waiting for some kind of timeout.

I am also seeing these messages:

Feb 19 18:46:16 sbc2 /opt/ringrx_edge_proxy/sbin/opensips[20755]: ERROR:proto_tls:tls_write: TLS write error: Feb 19 18:46:16 sbc2 /opt/ringrx_edge_proxy/sbin/opensips[20755]: ERROR:proto_tls:tls_blocking_write: TLS failed to send data Feb 19 18:46:16 sbc2 /opt/ringrx_edge_proxy/sbin/opensips[20755]: ERROR:proto_tls:proto_tls_send: failed to send Feb 19 18:46:16 sbc2 /opt/ringrx_edge_proxy/sbin/opensips[20755]: ERROR:sl:msg_send: send() to for proto tls/3 failed

The IP is outside so its from a UDP to TCP flow. Is there another flag I need to set to prevent packets from originating new TLS sessions when none exist?

Once it gets into this state it takes 30s or so before it starts passing packets again, but it does so from a buffer it seems since i can stop my tls generator, wait 30s and the core side sipp instance will again begin receiving packets.

How can I prevent opensips from blocking like this on TLS sessions?

Users mailing list

Users mailing list

Reply via email to