Just to reignite this whole thread. We've had great success with Stasis so far. We have implemented a (imho better) AMD using TALK_DETECT and the ARI events. When using this, it seems like calling /play multiple times will just queue up the audio files. This is probably the best use case and most common implementation. However, if half-way through our third audio file we realize that we've been speaking to a machine this whole time and we want to start for the beginning - we thought we would use DELETE /playbacks/{playbackId}. If we do that, however, and then subsequently try to play audio on the channel (even though the call is still connected and in the Stasis app) we get a Channel not found. Is this the intended use or even a good use?
Thanks!
--
KB
On Wednesday, July 16, 2014 at 5:50 AM, Krandon wrote:
Will do asap - thanks Josh!--KBOn Wednesday, July 16, 2014 at 5:40 AM, Joshua Colp wrote:
Krandon wrote:Hey Matt,I have to be a bother, but is there anything I can do to help the issuemove forward? I'm sure the core dev team is busy with many other things.Is there a bug bounty we can set that may help?Feature freeze for Asterisk 13 is today so everyone has been andcontinues to be focused on getting stuff in so 13 is as awesome as itcan be. If you'd like to offer a bounty to see if you can elicit someoneelse to take a gander at that issue quicker, sure! There's a wiki pageatwhich details it.Cheers,--Joshua ColpDigium, Inc. | Senior Software Developer445 Jan Davis Drive NW - Huntsville, AL 35806 - USCheck us out at: www.digium.com & www.asterisk.org_______________________________________________asterisk-app-dev mailing list
_______________________________________________ asterisk-app-dev mailing list asterisk-app-dev@xxxxxxxxxxxxxxxx http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev
