<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Feb 3, 2015 at 6:47 PM, Joshua Colp <span dir="ltr"><<a href="mailto:jcolp@digium.com" target="_blank">jcolp@digium.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Kevin Harwell wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Greetings,<br>
</blockquote>
<br>
Kia ora,<span><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I was thinking of adding a new "ApplicationActivated" event to ARI that<br>
would be raised upon a websocket reconnecting and an application being<br>
made active again. Currently, I am thinking it will just contain a count<br>
of the number of messages that were missed while the websocket was<br>
disconnected.<br>
</blockquote>
<br></span>
Do we provide enough access to rehydrate the application upon the case where messages were indeed missed?<br></blockquote><div><br></div><div>I lean toward yes, but it probably is application dependent.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
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?<br></blockquote><div><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I think ultimately best practices and documentation about how to deal with this are equally as important as further information.<br>
<br>
Pondering a bit I can see applications wanting Asterisk to handle this in different ways:<br>
<br>
1. Tell me that I'm taking over an application that is still active<br></blockquote><div><br></div><div>This already happens with the 'ApplicationReplaced' event.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
2. In case of disconnection buffer the last N messages and provide them to me in order when I reconnect<br></blockquote><div><br></div><div>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.<br><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
3. Disconnect all channels upon application disconnection and don't accept new ones<br></blockquote><div><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Thoughts?<br>
<br></blockquote><div><br>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.</div></div><br>-- <br><div><div dir="ltr"><pre style="padding:2px;border:1px solid rgb(114,99,77);background-color:rgb(238,238,238);color:rgb(0,0,0);overflow:auto">Kevin Harwell
Digium, Inc. | Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
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></pre></div></div>
</div></div>