With the chan_websocket support, is there a frequency or ping setting to detect when the connection is not working

We perform the Dial websocket and the connection is established. Audio is flowing in both directions.

For reliability, we are now testing what happens when the connection between Asterisk and other end of the WebSocket drops. In SIP the SIP OPTIONS and frequency settings come into play. Are there any similar settings for the chan_websocket support?

I’m checking to see if our QA person plugged the cable back in after 5 minutes and 2 seconds and the other side closed the connection?
Or if that’s when Asterisk detected the error and closed it?

[05/13 17:48:50.836] DEBUG[1302][C-00000001] iostream.c: TLS transport or SSL error writing data: error:00000005:lib(0)::reason(5), Underlying BIO error: Connection reset by peer
[05/13 17:48:50.836] DEBUG[1302][C-00000001] res_http_websocket.c: Closing WS with 1011 because we can’t fulfill a write request
[05/13 17:48:50.836] DEBUG[1302][C-00000001] iostream.c: TLS transport or SSL error writing data: error:00000001:lib(0)::reason(1), Internal SSL error
[05/13 17:48:50.836] DEBUG[1301] chan_websocket.c: WebSocket/IS__1/0x7f7134025800: HANGUP by websocket close/error

[IS__1]
type = websocket_client
uri = wss://staging.amtelcoservices.com/mediaSessions/asterisk-audio
protocols = media
username = ourusername
password = ourpassword
connection_type = per_call_config
tls_enabled = yes
connection_timeout = 500
reconnect_attempts = 4
reconnect_interval = 500
verify_server_cert = no
verify_server_hostname = no

Dan

That’s something that the OS can do for you, as such a mechanism is built into TCP, although you may find the defaults are too large, but you can adjust them, in the OS configuration.

However, I don’t think that Asterisk will terminate a normal SIP session just because a qualify, to the same address fails, it will rely on either timing out the arrival of media, which is on a connectionless transport, or use session timers. With normal SIP, over TCP, or TLS, a new connection can be established from either side and will form part of the same session.

This topic is timely. I’m working on the websocket client now to add support for forward proxies and have also added support for sending TCP keepalives. A pull request should be up in the next few days.

The WebSocket protocol specifies a ping/pong mechanism. I presume that is what you’re implementing?

I’m implementing both PING/PONG and socket-level TCP keepalives.

Thanks George.

@DanCropp PR #1934 that provides support for keepalives is up on github. Please take a look and test if you can. Use the PR for feedback or questions to keep things consolidated.

PR #1934 has been replaced with PR #1937 which doesn’t have a dependency on curl.

Thanks @gjoseph . I built a version with the pull request. Sent it to our testers with instructions. I will let you know what they find.