Re: ChannelLeftBridge vs StasisEnd

[Matthew Jordan <mjordan@xxxxxxxxxx>]

On Tue, Apr 19, 2016 at 8:21 AM, Nitesh Bansal <nitesh.bansal@xxxxxxxxx> 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

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