We have a client application that is utilizing Websocket connections with ARI to listen for events and control the call flow. There is a certain limitation on the client side that sometimes causes Websockets to close unexpectedly, i.e. with a code of 1006 and message “WebSocket disconnected without sending Close frame”.
I believe this is causing some TCP ports on the asterisk side to get stuck in a CLOSE-WAIT state and they are never cleaned up due to a lack of graceful Websocket connection shut down.
Is this a known issue? I haven’t been able to find anything regarding this, so any pointers would be helpful. Otherwise, we’re just looking to handle this in the best way possible and would appreciate any guidance while we look for solutions to address the root issue, i.e. the client side restriction.
Asterisk Version: 21.4.3.
Happy to provide any additional info!
Thank you!
The asterisk server side is the one ending up with a bunch of ports stuck in the CLOSE-WAIT state, and the client application is the one where the websocket abruptly disconnects sometimes, which I believe is causing the CLOSE-WAIT ports on the asterisk server due to a lack of graceful disconnect. Hmm, what makes you say that the side with the CLOSE-WAITs (asterisk server in this case) is at fault?
Thanks for your thoughts David, helped me go back and figure out the root issue. The root issue was not with inbound WS connections, but with outbound WS connections, related to the module “app_audiofork”. Basically it wasn’t disposing closed websockets properly, thus causing connections to get stuck and eventually the server would run out of available ports. We pushed out a patch and were able to resolve it!