I add two local channels to a mixing bridge via Asterisk’s ARI.
I receive events when channels leave via ChannelLeftBridge when they are created using the PJSIP prefix, aja endpoint=‘PJSIP/1000’. When the channels are created with endpoints from a Local context, such as endpoint=‘Local/1000@from-internal’, events aren’t received when the endpoint leaves the bridge.
I would normally not complain and just use PJSIP/…, however one of the participants in the bridge is a “Ring Group” from FreePBX.
Thanks for the prompt reply. The cause was actually that when an ARI client’s websocket exits prematurely (a crash for example) asterisk seems internally blocked for some time…
Changing the interaction to a unique app name solved it… Even when clients crash, new ones will receive events.
We moved to unregister those in such an event too in python, using an unhandled thread exit hook.
So even with a unique app name, it appears there can be instances where the web socket callback is not received immediately.
In this instance after the other channel left the bridge, it took approximately 48 seconds before the callback was received.
Do you know the mechanics of how the web socket are sent messages? It seems as if its in a single loop on the asterisk side and when one times out or is blocked, the others won’t receive timely events until that timeout expires.
–end msg–
→ Call tsx state
10:47:02.783 udp0xffff5c087060 Remote RTP address switched to 192.168.65.1:58284
10:47:02.783 udp0xffff5c087060 Remote RTCP address switched to predicted address 192.168.65.1:58285
Endpoint left bridge!
→ Remote endpoint left bridge
→ We will hang up.
Endpoint left bridge!
→ We left the call bridge 10:47:51.597 pjsua_core.c .RX 464 bytes Request msg BYE/cseq=24390 (rdata0xffff5c074818) from TCP 192.168.8.117:5060:
We don’t have web hooks. It’s a persistent websocket connection that JSON events go over. If you believe Asterisk itself is blocked, then a deadlock backtrace[1] would show where/if things are blocked.
I make a call to Call.hangup and then unregister in the call state callback for the disconnected event.
It appears when doing the hangup locally via Call.hangup, the onCallState callback will be called locally as well, so the unregistration call that we make on PJSIP_INV_STATE_DISCONNECTED is actually sent before BYE, then BYE is not sent at all.
As a solution we receive the disconnected event, then spawn a thread to process the unregistration after some arbitrary delay…