[asterisk-app-dev] WebSocket Stasis Control Best Practice

[Krandon]

Wanted to touch base on this. 

What was happening, is that when we deleted (/playbacks/{id}/delete) the audio on the channel, the call would continue forward and hangup.

This is actually expected behavior, as we had "queued up" the /continue for after the audio file was done playing.

To restart a string of audio files, we now simple add them to the queue by calling /play multiple times (as mentioned before) followed by a delete of the playback AFTER that. It will then delete/stop the current playback, and continue to the audio files.

You can also use the operation=restart, but we have a string of audio files we need to play, so that would not work.

To give an overview, as soon as the Stasis app is invoked, we call:

/ari/channels/{id}/play file=audioA
/ari/channels/{id}/play file=audioB
/ari/channels/{id}/play file=audioC
/ari/channels/{id}/continue

When we receive the DTMF event, we were doing an /ari/playbacks/{id}/delete which was sending us straight to /continue (expected result).

We now simply "requeue" the audio files before we delete - which gives our original use of stopping the current playback, and restarting the string of audio files. 

-- 
KB


On Tuesday, August 5, 2014 at 4:58 PM, Krandon wrote:

> On Tuesday, August 5, 2014 at 9:38 AM, Matthew Jordan wrote:
> > 
> > 
> > 
> > On Fri, Aug 1, 2014 at 10:16 AM, Krandon <krandon.bruse at gmail.com (mailto:krandon.bruse at gmail.com)> wrote:
> > > On Friday, August 1, 2014 at 10:01 AM, Joshua Colp wrote:
> > > > Krandon wrote:
> > > > > 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?
> > > > > 
> > > > 
> > > > 
> > > > Stopping a playback, or multiple playbacks in sequence, like that 
> > > > shouldn't result in you being unable to do things on the channel. Do you 
> > > > have the output of what you are invoking and the log from Asterisk? It 
> > > > may be a bug.
> > > > 
> > >     -- Executing [amdme at default:1] Answer("SIP/flowroute-00000012", "") in new stack
> > >     -- Executing [amdme at default:2] Set("SIP/flowroute-00000012", "TALK_DETECT(set)=1000") in new stack
> > >     -- Executing [amdme at default:3] Monitor("SIP/flowroute-00000012", "wav,recordme") in new stack
> > >     -- Executing [amdme at default:4] Stasis("SIP/flowroute-00000012", "vb") in new stack
> > >     -- <SIP/flowroute-00000012> Playing '178.ulaw' (language 'en')
> > >        > SIP/flowroute-00000012 is now talking
> > >        > SIP/flowroute-00000012 is now silent
> > > [Aug  1 10:44:20] NOTICE[7444][C-00000030]: res_stasis_playback.c:245 playback_final_update: 2565557733.refMondwandway: Playback stopped for sound:178
> > > [Aug  1 10:44:23] NOTICE[7444][C-00000030]: res_stasis_playback.c:245 playback_final_update: 2565557733.refMondwandway: Playback stopped for sound:silence/3
> > >     -- Executing [amdme at default:5] Hangup("SIP/flowroute-00000012", "") in new stack
> > > 
> > > This happens after we do a DELETE on /playbacks/{playbackId} (which I use the channel ID - I am going to test with a different, fixed ID) 
> > > 
> > > 
> > 
> > Maybe I misunderstood what you just said, but are you using the channel ID in the DELETE /playbacks/{playbackId} operation?
> > 
> > If so, you should be using the ID of the playback operation, not the channel ID. That playback ID should be either (a) passed back to you by the /play operation (on either the bridge or channel), or provided by you when the /play operation is invoked.
> > 
> Hey Matt,
> 
> For simplification, we used the channel ID as the playback ID. We figured calling DELETE on /playbacks/{playbackID is the same as channel ID}
> 
> We even then just hardcoded 1234 as the playback ID. When we try to delete it, it hangs up the call.
> 
> We have had decent success with TALK_DETECT thus far as well.
> 
> -- 
> KB 
> > -- 
> > Matthew Jordan
> > Digium, Inc. | Engineering Manager
> > 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
> > Check us out at: http://digium.com & http://asterisk.org
> > 
> > 
> > 
> > 
> > _______________________________________________
> > asterisk-app-dev mailing list
> > asterisk-app-dev at lists.digium.com (mailto:asterisk-app-dev at lists.digium.com)
> > http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev
> > 
> > 
> > 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-app-dev/attachments/20140826/a6d1501b/attachment.html>