<div><span style="font-size: 14px;">Wanted to touch base on this.</span>
</div><div><span style="font-size: 14px;"><br></span></div><div><span style="font-size: 14px;">What was happening, is that when we deleted (/playbacks/{id}/delete) the audio on the channel, the call would continue forward and hangup.</span></div><div><span style="font-size: 14px;"><br></span></div><div><span style="font-size: 14px;">This is actually expected behavior, as we had "queued up" the /continue for after the audio file was done playing.</span></div><div><span style="font-size: 14px;"><br></span></div><div><span style="font-size: 14px;">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.</span></div><div><span style="font-size: 14px;"><br></span></div><div><span style="font-size: 14px;">You can also use the operation=restart, but we have a string of audio files we need to play, so that would not work.</span></div><div><span style="font-size: 14px;"><br></span></div><div><span style="font-size: 14px;">To give an overview, as soon as the Stasis app is invoked, we call:</span></div><div><span style="font-size: 14px;"><br></span></div><div><span style="font-size: 14px;">/ari/channels/{id}/play file=audioA</span></div><div><span style="font-size: 14px;">/ari/channels/{id}/play file=audioB</span></div><div><span style="font-size: 14px;">/ari/channels/{id}/play file=audioC</span></div><div><span style="font-size: 14px;">/ari/channels/{id}/continue</span></div><div><span style="font-size: 14px;"><br></span></div><div><span style="font-size: 14px;">When we receive the DTMF event, we were doing an /ari/playbacks/{id}/delete which was sending us straight to /continue (expected result).</span></div><div><span style="font-size: 14px;"><br></span></div><div><span style="font-size: 14px;">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.</span></div>
<div><div><br></div><div>-- </div><div>KB<br></div><div><br></div></div>
<p style="color: #A0A0A8;">On Tuesday, August 5, 2014 at 4:58 PM, Krandon wrote:</p>
<blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;">
<span><div><div>
<div><span style="color: rgb(160, 160, 168); ">On Tuesday, August 5, 2014 at 9:38 AM, Matthew Jordan wrote:</span></div><blockquote type="cite"><div>
<span><div><div><div dir="ltr"><br><div><br><br><div>On Fri, Aug 1, 2014 at 10:16 AM, Krandon <span dir="ltr"><<a href="mailto:krandon.bruse@gmail.com" target="_blank">krandon.bruse@gmail.com</a>></span> wrote:<br><blockquote type="cite"><div><div>
<div>
<div><span style="color:rgb(160,160,168)">On Friday, August 1, 2014 at 10:01 AM, Joshua Colp wrote:</span></div></div><blockquote type="cite"><div>
<span><div><div><div>Krandon wrote:</div><blockquote type="cite"><div><div>Just to reignite this whole thread. We've had great success with Stasis</div><div>so far. We have implemented a (imho better) AMD using TALK_DETECT and</div>
<div>the ARI events. When using this, it seems like calling /play multiple</div><div>times will just queue up the audio files. This is probably the best use</div><div>case and most common implementation. However, if half-way through our</div>
<div>third audio file we realize that we've been speaking to a machine this</div><div>whole time and we want to start for the beginning - we thought we would</div><div>use DELETE /playbacks/{playbackId}. If we do that, however, and then</div>
<div>subsequently try to play audio on the channel (even though the call is</div><div>still connected and in the Stasis app) we get a Channel not found. Is</div><div>this the intended use or even a good use?</div></div></blockquote><div><br></div><div>Stopping a playback, or multiple playbacks in sequence, like that </div><div>shouldn't result in you being unable to do things on the channel. Do you </div><div>have the output of what you are invoking and the log from Asterisk? It </div>
<div>may be a bug.</div><div><br></div></div></div></span></div></blockquote></div><div><div> -- Executing [amdme@default:1] Answer("SIP/flowroute-00000012", "") in new stack</div><div> -- Executing [amdme@default:2] Set("SIP/flowroute-00000012", "TALK_DETECT(set)=1000") in new stack</div>
<div> -- Executing [amdme@default:3] Monitor("SIP/flowroute-00000012", "wav,recordme") in new stack</div><div> -- Executing [amdme@default:4] Stasis("SIP/flowroute-00000012", "vb") in new stack</div>
<div> -- <SIP/flowroute-00000012> Playing '178.ulaw' (language 'en')</div><div> > SIP/flowroute-00000012 is now talking</div><div> > SIP/flowroute-00000012 is now silent</div><div>
[Aug 1 10:44:20] NOTICE[7444][C-00000030]: res_stasis_playback.c:245 playback_final_update: 2565557733.refMondwandway: Playback stopped for sound:178</div><div>[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</div>
<div> -- Executing [amdme@default:5] Hangup("SIP/flowroute-00000012", "") in new stack</div><div><br></div></div><div><div><span style="font-size:14px">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)</span></div>
<span><font color="#888888"><div><br></div></font></span><br></div></div></blockquote></div><br></div><div>Maybe I misunderstood what you just said, but are you using the channel ID in the DELETE /playbacks/{playbackId} operation?<br>
<br></div><div>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.<br clear="all">
</div><div><br></div></div></div></div></span></div></blockquote><div><span style="font-size: 14px; ">Hey Matt,</span></div><div><span style="font-size: 14px; "><br></span></div><div><span style="font-size: 14px; ">For simplification, we used the channel ID as the playback ID. We figured calling DELETE on /playbacks/{playbackID is the same as channel ID}</span></div><div><span style="font-size: 14px; "><br></span></div><div><span style="font-size: 14px; ">We even then just hardcoded 1234 as the playback ID. When we try to delete it, it hangs up the call.</span></div><div><div><br></div><div><span style="font-size: 14px;">We have had decent success with TALK_DETECT thus far as well.</span></div><div><br></div><div>-- </div></div><div>KB </div><blockquote type="cite"><div><span><div><div><div dir="ltr"><div>-- <br><div dir="ltr"><div>Matthew Jordan<br></div><div>Digium, Inc. | Engineering Manager</div><div>445 Jan Davis Drive NW - Huntsville, AL 35806 - USA</div><div>Check us out at: <a href="http://digium.com" target="_blank">http://digium.com</a> & <a href="http://asterisk.org" target="_blank">http://asterisk.org</a></div>
</div>
</div></div>
</div><div><div>_______________________________________________</div><div>asterisk-app-dev mailing list</div><div><a href="mailto:asterisk-app-dev@lists.digium.com">asterisk-app-dev@lists.digium.com</a></div><div><a href="http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev">http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev</a></div></div></div></span>
</div></blockquote><div>
<br>
</div>
</div></div></span>
</blockquote>
<div>
<br>
</div>