Failover Active Calls

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Failover Active Calls

Colin Morelli
Hey all,

I briefly looked through the Adhersion source so I'm pretty sure I know the answer to this - but is there any mechanism in Adhearsion to failover active calls? For example, if a deployment of the Adhearsion layer happens while calls are active, is there any way to recover the calls on another server?

Given that Rayo is supposed to re-offer the call in the event that a client disappears, I would think that this could (in theory) be as easy as allowing the active_calls collection to be pluggable to a data source (by default it can be in memory, with the option to push to redis, or some other storage layer).

Anyone have thoughts or experience here?

Thanks,
Colin

--
You received this message because you are subscribed to the Google Groups "Adhearsion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Failover Active Calls

Ben Langfeld-2

On Sat, 30 Apr 2016 at 22:22 Colin Morelli <[hidden email]> wrote:
Hey all,

I briefly looked through the Adhersion source so I'm pretty sure I know the answer to this - but is there any mechanism in Adhearsion to failover active calls? For example, if a deployment of the Adhearsion layer happens while calls are active, is there any way to recover the calls on another server?

No such functionality currently exists.
 
Given that Rayo is supposed to re-offer the call in the event that a client disappears,

What makes you think that?
 
I would think that this could (in theory) be as easy as allowing the active_calls collection to be pluggable to a data source (by default it can be in memory, with the option to push to redis, or some other storage layer).

Possibly, but this gets complicated quickly. It does also require maintaining application state about the progress of the call.
 
Anyone have thoughts or experience here?

Thanks,
Colin

--
You received this message because you are subscribed to the Google Groups "Adhearsion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Adhearsion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Failover Active Calls

Ben Klang-2


Il giorno Apr 30, 2016, alle ore 10:23 PM, Ben Langfeld <[hidden email]> ha scritto:

I would think that this could (in theory) be as easy as allowing the active_calls collection to be pluggable to a data source (by default it can be in memory, with the option to push to redis, or some other storage layer).

Possibly, but this gets complicated quickly. It does also require maintaining application state about the progress of the call.


I just wanted to chime in that this is the hard part, as it would require writing your app in such a way that your application would be able to fail whatever your app was doing; it’s not just a signaling problem.  In our experience, for most people, the costs involved with designing such application-level high availability outweigh the benefits, since calls may drop for other reasons anyway.  And hopefully, your servers aren’t failing so often as to make this a big problem.

Alternatively, if you’re designing something with many complicated steps (like a long IVR), perhaps you could get part of the way there by allowing callers to call back in and resume where they left off? That way you also account for external failures, like cellular call drops.

/BAK/
-- 
Ben Klang
Principal/Technology Strategist, Mojo Lingo
+1.404.475.4841

Mojo Lingo -- Voice applications that work like magic
Twitter: @MojoLingo

--
You received this message because you are subscribed to the Google Groups "Adhearsion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

signature.asc (858 bytes) Download Attachment