[asterisk-app-dev] ChannelLeftBridge vs StasisEnd

[Matthew Jordan]

On Tue, Apr 19, 2016 at 8:21 AM, Nitesh Bansal <nitesh.bansal at gmail.com>
wrote:

> Thanks people for your valuable suggestion.
> In my case, I’m developing a basic conferencing service, so for my
> asterisk server, I shouldn't have any channels outside the bridge.
> But I think it will be still useful to listen to StasisEnd if something
> happens to a channel before it could be added to the bridge.
>
>
The events have different semantic meanings, and do have a well defined
ordering.

ChannelLeftBridge implies that a channel has left that bridge, but has no
other meaning. A channel can leave a bridge for a lot of reasons - what it
does tell you is that the path of communication between that channel and
any other channel in that bridge has terminated. Whether or not that is
useful for your application depends on whether or not you have an
application level concern at that level.

StasisEnd implies that the channel has left your application's control.
Again, a channel can leave your application's control for a lot of reasons:
 - It was hung up
 - It was transferred out of your application by a channel driver
 - You released the channel out of the application via the /continue
operation
Once you see a StasisEnd event, you know that you cannot continue to
manipulate the channel.

Unlike AMI, where the events received are at a system level, events
received in an ARI application are, by default, constrained to the events
that occur to those telephony objects that are within your application's
domain. An overview of the event model is explained on the wiki [1]. You
can always expand the events that your application sees in one of two ways:
(1) By using the applications resource and explicitly subscribing to
resources within Asterisk [2]
(2) By subscribing your application to all resources within Asterisk - even
those not under its control - when the websocket connection is initially
established [3]

ARI does have a Hangup event - ChannelDestroyed [4] - however, you will
rarely see it. This is because the ordering of these three events is well
defined and ordered, and in the case of a hangup would be:
(1) ChannelLeftBridge
(2) StasisEnd
(3) ChannelDestroyed

However, when the StasisEnd event is fired, that is the signal to your
application that it no longer has control of the channel resource. As a
result, ARI removes the implicit subscription it made to the channel, which
means your application will not receive the ChannelDestroyed event for that
channel resource. You *would* see it if you had created an explicit
subscription to that channel (which persists beyond the lifetime of that
channel in the application) or if your application had subscribed for all
events in Asterisk.

Hope this clears up some of the subscription model/events -

Matt


[1]
https://wiki.asterisk.org/wiki/display/AST/Introduction+to+ARI+and+Channels#IntroductiontoARIandChannels-ChannelsinaStasisApplication
[2]
https://wiki.asterisk.org/wiki/display/AST/Asterisk+13+Applications+REST+API#Asterisk13ApplicationsRESTAPI-subscribe
[3]
https://wiki.asterisk.org/wiki/display/AST/Asterisk+13+Events+REST+API#Asterisk13EventsRESTAPI-eventWebsocket
[4]
https://wiki.asterisk.org/wiki/display/AST/Asterisk+13+REST+Data+Models#Asterisk13RESTDataModels-ChannelDestroyed

-- 
Matthew Jordan
Digium, Inc. | Director of Technology
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-app-dev/attachments/20160429/55cdacd6/attachment.html>