Efficiently Stopping All Active Playbacks on a Channel Using ARI

Asterisk Asterisk APIs
1

Hi all,

In my ARI application, I play a list of audio files sequentially or in parallel for a channel. I store the corresponding playbackIds in a HashMap<String, List<String>> (where the key is the channelId), and when I want to stop all sounds on that channel, I loop through each playbackId and call:
ari.playbacks().stop(playbackId).execute();

This works, but if there are multiple playbacks (e.g., 5+), it takes time because each stop request is sent individually. This causes a noticeable delay from the user’s perspective.

Is there a more efficient or built-in ARI method to stop all active playbacks for a given channel in one go, instead of iterating and sending multiple HTTP requests?
Or is there a recommended design pattern for this use case to make it more responsive?

2

No, there isn’t. The ARI documentation[1] is what produces the code. If you don’t see a method, it doesn’t exist.

For sequential instead of doing separate playbacks you can do a single playback with comma separated, so it’s a single call to stop it.

I don’t know how you’re doing parallel so can’t comment on that.

[1] Channels - Asterisk Documentation

3

Thanks for the clarification. I am actually playing sounds using comma-separated format (e.g., “sound1,sound2,sound3”) so it executes as a single playback. However, my scenario involves retry logic — for example, when the called party doesn’t answer and the channel gets destroyed, I invoke the same method again to retry the call. At that point, I don’t explicitly stop the previous playback (if it was still active); I just send a new comma-separated playback to the channel.

So over time, there may be multiple active playbacks. Once the other person finally answers, I loop through each stored playbackId and send a stop request for each to ensure everything gets cleaned up. So in that case there is 5 to 10 seconds delay

4

Why are you doing things that way? What are you over all trying to achieve?

5

Just to clarify the situation:

In my ARI app, when a customer calls, I play a combination of wait + busy + wait + busy sounds. If the called channel gets destroyed (e.g., no answer), I retry the call (up to 5 times), and each time I replay the same sounds.

So to the customer, it should feel like a seamless loop of waiting sounds — until someone answers.

Here’s where the issue comes in:
Before bridging on, say, the 4th retry, I try to stop any existing sounds on the customer’s channel to avoid overlap. But since I’m tracking playback IDs in a map (HashMap<String, List<String>>) and stopping each playback one-by-one using:

ari.playbacks().stop(playbackId).execute();

…it introduces a delay. This delay is noticeable, especially when multiple playbacks from previous retries are still active.

6

Why don’t you wait for the PlaybackFinished event and start the sounds again based on that?