ARI Bridge Events - ChannelLeftBridge not received for Local channel


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.

Any ideas?

They will still produce events, including ChannelLeftBridge. Please provide the output of “ari set debug on” showing it not behaving as such.

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
10:47:02.783 udp0xffff5c087060 Remote RTCP address switched to predicted address

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

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.

[1] Getting a Backtrace - Asterisk Documentation

Sorry web socket… I’ve edited my response.

I’ll take a look. Odd because according to this page for res_ari the write timeout is just 100 ms.

I’ll continue to debug…

Thanks for all your help. I found the root cause.

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…