On Tuesday, August 5, 2014 at 9:38 AM, Matthew Jordan wrote:
On Fri, Aug 1, 2014 at 10:16 AM, Krandon <krandon.bruse@xxxxxxxxx> 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 Stasisso far. We have implemented a (imho better) AMD using TALK_DETECT andthe ARI events. When using this, it seems like calling /play multipletimes will just queue up the audio files. This is probably the best usecase and most common implementation. However, if half-way through ourthird audio file we realize that we've been speaking to a machine thiswhole time and we want to start for the beginning - we thought we woulduse DELETE /playbacks/{playbackId}. If we do that, however, and thensubsequently try to play audio on the channel (even though the call isstill connected and in the Stasis app) we get a Channel not found. Isthis the intended use or even a good use?Stopping a playback, or multiple playbacks in sequence, like thatshouldn't result in you being unable to do things on the channel. Do youhave the output of what you are invoking and the log from Asterisk? Itmay be a bug.-- Executing [amdme@default:1] Answer("SIP/flowroute-00000012", "") in new stack-- Executing [amdme@default:2] Set("SIP/flowroute-00000012", "TALK_DETECT(set)=1000") in new stack-- Executing [amdme@default:3] Monitor("SIP/flowroute-00000012", "wav,recordme") in new stack-- Executing [amdme@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@default:5] Hangup("SIP/flowroute-00000012", "") in new stackThis 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 JordanDigium, Inc. | Engineering Manager445 Jan Davis Drive NW - Huntsville, AL 35806 - USACheck us out at: http://digium.com & http://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
