[asterisk-app-dev] ARI ApplicationActivated event?

[Kevin Harwell]

On Tue, Feb 3, 2015 at 6:47 PM, Joshua Colp <jcolp at digium.com> wrote:

> Kevin Harwell wrote:
>
>> Greetings,
>>
>
> Kia ora,
>
>  I was thinking of adding a new "ApplicationActivated" event to ARI that
>> would be raised upon a websocket reconnecting and an application being
>> made active again. Currently, I am thinking it will just contain a count
>> of the number of messages that were missed while the websocket was
>> disconnected.
>>
>
> Do we provide enough access to rehydrate the application upon the case
> where messages were indeed missed?
>

I lean toward yes, but it probably is application dependent.


>
> If a new channel starts the application do we currently reject that, or do
> we accept it? If we accept it how does the newly reconnected/connected
> application know that channel is in it?
>

Upon disconnection from the websocket an application goes into the
"inactive" state. From what I can tell attempts to create new channels are
rejected. Even if that is allowed the application could retrieve a list of
channels upon reconnect.


>
> I think ultimately best practices and documentation about how to deal with
> this are equally as important as further information.
>
> Pondering a bit I can see applications wanting Asterisk to handle this in
> different ways:
>
> 1. Tell me that I'm taking over an application that is still active
>

This already happens with the 'ApplicationReplaced' event.


> 2. In case of disconnection buffer the last N messages and provide them to
> me in order when I reconnect
>

This could make sense. However, this worries me a bit in that the buffer
could potentially grow quite large (large interval between reconnect or
they don't reconnect at all). Also I lean a bit toward having the
application be responsible for choosing what information they deem
important and then issuing commands for updates as opposed to Asterisk
spamming them with a bunch of messages. On the other hand, I could see how
it would be important to know all state transitions that took place and not
just the current state.



> 3. Disconnect all channels upon application disconnection and don't accept
> new ones
>

Rejecting new ones makes sense, but disconnecting current ones seems overly
aggressive. I can't see applications wanting calls being hung up mid
conversation just because the application is disconnected for a time.


>
> Thoughts?
>
>
Hmm now that I think about it, once all refs to the app goes away it will
be destroyed. Upon reconnect it is not 'activated' but considered a new
app. If we decide to put this in, my current opinion would be to keep it
simple and just send a notification that the app was activated and whether
or not it missed any messages. Then the app can retrieve any current state
it might need to update itself with. This puts it in a position of knowing
the current state which is consistent with when the app reconnects but is
created new.

-- 

Kevin Harwell
Digium, Inc. | Software Developer
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/20150204/7cde0320/attachment.html>