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

[Krandon]

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/20140805/2db2dda2/attachment.html>