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

[Krandon]

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)

-- 
KB 
> 
> -- 
> Joshua Colp
> Digium, Inc. | Senior Software Developer
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - US
> Check us out at: www.digium.com (http://www.digium.com) & www.asterisk.org (http://www.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/20140801/f5b0d56c/attachment.html>