Re: WebSocket Stasis Control Best Practice

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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?



On Wednesday, July 16, 2014 at 5:50 AM, Krandon wrote:

Will do asap - thanks Josh!


On 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 issue
move 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 and
continues to be focused on getting stuff in so 13 is as awesome as it
can be. If you'd like to offer a bounty to see if you can elicit someone
else to take a gander at that issue quicker, sure! There's a wiki page

asterisk-app-dev mailing list

asterisk-app-dev mailing list

[Index of Archives]     [Asterisk SS7]     [Asterisk Announcements]     [Asterisk Users]     [PJ SIP]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Linux API]

  Powered by Linux