Re: WebSocket Stasis Control Best Practice

[Krandon <krandon.bruse@xxxxxxxxx>]

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@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 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@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 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@xxxxxxxxxxxxxxxx

http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev

_______________________________________________
asterisk-app-dev mailing list
asterisk-app-dev@xxxxxxxxxxxxxxxx
http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev