Summary:	ASTERISK-22677: Playbacks on bridge via ARI are not queued
Reporter:	John Bigelow (jbigelow)	Labels:
Date Opened:	2013-10-10 11:25:19	Date Closed:	2014-04-22 11:27:37
Priority:	Major	Regression?
Status:	Closed/Complete	Components:	Resources/res_ari
Versions:	SVN 12.0.0-beta1	Frequency of Occurrence	Constant
Related Issues:
Environment:	Asterisk branch 12 r400823	Attachments:	( 0) full.txt
Description:	Using ARI and playing a sound to the bridge (native RTP) and immediately playing another sound to the bridge results in both sounds playing at the same time. The second sound that is played is not queued as expected. The Asterisk full log is attached. Update - behavior when holding bridge is used: Initiate a playback and then a few seconds later initiate another playback. Overlapping sound is *not* heard like when a native RTP/softmix bridge is used. The first sound is heard on each SIP channel.However when the first playback finishes, the end of the second playback is heard. It appears that the second sound is playing while the first is playing but the second sound file is not heard until the first finishes.
Comments:	By: Paul Belanger (pabelanger) 2013-10-18 13:20:49.718-0500 I can confirm this. By: Jonathan Rose (jrose) 2014-03-18 17:18:55.657-0500 Honestly I'm surprised the second audio file even gets queued in the holding bridge.  I thought I made holding bridges only accept a single announcer channel and reject anything that comes afterwards. I guess someone must have changed that to allow multiple announcers, but to only allow one active announcer at time.  In any event, that's not a bug. That's just how holding bridges work.  They have no mixing capability, so only one channel can push audio at a time. As for the more general problem of multiple audio files being able to play... that's something I'm going to fix. I made it that way to start with on purpose, but I can certainly see how it could be problematic.  Having to listen for sounds stopping before starting up new ones is suboptimal.