ARI Playback Control Not Stopping Audio Under Load - DELETE /playbacks/{id} Ignored

[mammt]

Hi everyone,

I’m experiencing an issue with ARI playback control when the system is under moderate to heavy load (30-150 concurrent calls). I’m hoping someone can help me understand if this is expected behavior or if there’s a better approach.

Setup

1. Asterisk Version: 22.6.0
2. Using ARI via WebSocket for event handling
3. Python client with connection pooling (requests.Session)
4. Calls originate via AMI, then enter Stasis application

The Problem

When a channel is playing audio via /channels/{channel}/play and I try to stop it with DELETE /playbacks/{playback_id}, the DELETE request returns success (204) almost immediately (1-3ms), but the audio continues playing until it finishes naturally - sometimes 10+ seconds later.

This only happens under load. With 1-5 concurrent calls, stopping playback works instantly. With 30+ concurrent calls, it’s completely unreliable.

What I’ve Tried

1. Different stop methods:

   • DELETE /playbacks/{id} - doesn’t work under load

   • DELETE /channels/{channel}/play - also doesn’t work under load

   • Both return success but Asterisk seems to queue the command

2. Optimizations:

   • HTTP connection pooling with requests.Session

   • Async/threaded API calls to avoid blocking

   • Ultra-short timeouts (0.5-1s)

   • Immediate state transitions before calling API

Questions

1. Is this expected behavior when Asterisk is under load? Should DELETE requests to stop playback be queued rather than processed immediately?

2. Is there a way to make playback stop commands higher priority in ARI?

3. Should I be using a different approach entirely for DTMF-interruptible playback when handling many concurrent calls?

[jcolp]

@mammt

Both return success but Asterisk seems to queue the command

They are always queued.

You need to provide core level debugging to show what is actually going on in relation to them.