Stasis application deactivates (WebSockets forcibly closed) on mute/unmute operations

We are running a Stasis application on a .NET server. We’re using RESTSharp to send REST Commands, and WebSockets4Net to receive WebSocket events from Asterisk. In the production version, we’re working with 30 - 60 callers at a time, and we’re moving them between bridges, and muting and unmuting in groups. Recently we’ve seen Asterisk abort the connections to the .NET server on muting and unmuting. Asterisk does not crash, but the Stasis app effectively becomes moribund. We’re muting and unmuting callers as one group, using async tasks which we marshal before any further requests are sent to ARI.

We set up a test server to get some forensic information, using SIPp to simulate 60 connections. We are finding that about 10-15 successful mute/unmute operations take place from each group, before the WebSocket and HTTP connections become moribund. I can provide a debug log file. Some salient events that we’ve picked out when we do a group mute/unmute, however, are:

  1. A large number of webocket writes (in the order of n x n, where n is the number of clients being muted/unmuted), like:
    [Apr 10 14:36:29] DEBUG[35342] taskprocessor.c: Taskprocessor ‘subm:voice_2-00000065’ cleared the high water alert.
    [Apr 10 14:36:29] DEBUG[35342] res_http_websocket.c: Writing websocket string of length 668
    [Apr 10 14:36:29] DEBUG[35342] res_http_websocket.c: Writing websocket text frame, length 668

  2. After a small number of successful mute/unmute operations, the websocket faults, and closes
    Apr 10 14:36:30] DEBUG[35342] res_http_websocket.c: Closing WS with 1011 because we can’t fulfill a write request
    [Apr 10 14:36:30] DEBUG[35342] utils.c: Timed out trying to write
    [Apr 10 14:36:30] DEBUG[35342] res_http_websocket.c: WebSocket connection from ‘xxx.xxx.xxx.xxx:18133’ forcefully closed due to fatal write error

  3. A large number of attempted writes, followed by deactivation of the Stasis application
    [Apr 10 14:36:30] DEBUG[35342] res_http_websocket.c: Writing websocket text frame, length 668
    [Apr 10 14:36:30] NOTICE[35342] ari/ari_websockets.c: Problem occurred during websocket write to <xxx.xxx.xxx.xxx>:18133, websocket closed
    [Apr 10 14:36:30] WARNING[35340] ari/ari_websockets.c: WebSocket read error: Software caused connection abort
    [Apr 10 14:36:30] VERBOSE[35340] stasis/app.c: Deactivating Stasis app ‘voice_2’

We haven’t seen anything like this with other operations (for example moving clients between bridges).

This turned out to be a timeout issue on ARI Websockets. We had to increase the timeout to 4 seconds. It would be nice to see batch channel commands in ARI…