Re: Moving the Asterisk Bridge from one Asterisk to another

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Fri, May 13, 2016 at 2:20 PM, Ben Merrills <b.merrills@xxxxxxxxxxxxxxxx> wrote:

Let me answer your last question first.

 

Asterisk doesn’t handle multiple Stasis applications connecting with the same name. The relationship between Asterisk and Stasis application is one to one (one web socket per application name). However, you can get round this using an ARI proxy (see below). Using an ARI proxy allows you to

1.      Have multiple instances of your application run on multiple servers

2.      Provide load balancing between application servers

3.      Failover support for your application

 

There are two implementations of an ARI proxy. The first written by me, in .NET (supports mono)can be found here https://github.com/skrusty/AsterNET-ARI-Proxy

The second is written in GoLang and can be found here: https://github.com/nvisibleinc/go-ari-proxy

 

You can read about the concepts behind ARI proxy on my blog. http://www.xdev.net/2015/09/18/distributed-applications-with-ari/

 

With regards to stopping new calls in Asterisk, you can use the stop graceful cli command to prevent new calls from being processed on that asterisk box.

 

Hope that helps a little,

 

Ben

 

From: asterisk-app-dev-bounces@xxxxxxxxxxxxxxxx [mailto:asterisk-app-dev-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Nitesh Bansal
Sent: 13 May 2016 14:56
To: Asterisk Application Development discussion <asterisk-app-dev@xxxxxxxxxxxxxxxx>
Subject: Moving the Asterisk Bridge from one Asterisk to another

 

Hello,

I'm working on an ARI based bridging application.

My concern is how to gracefully handle the failovers, upgrades.

In case of planned upgrade, 0
I can see following possibilities but I have no clue about how they
will work out?
1. Move the Bridge to the new Asterisk?

2. Bridge the old asterisk to the new asterisk, but don't forward any new

    calls to the Asterisk under upgrade. Wait for call count to drop to zero

    for Asterisk under upgrade.

 

3. Let first Asterisk run until the call count drops to zero, keep accepting calls

for the existing bridge, but forward any new Bridge request to the new Asterisk.

How does Asterisk behaving if multiple ARI clients connect with Asterisk for the same

Stasis application?

 

Any ideas/recommendations?

 


To follow on a bit with what Ben said:

If you're building a multi-Asterisk system, you'll need some middleware - like the aforementioned ARI proxies - to manage the information coming from multiple Asterisk systems. That's certainly the first step.

Once you have some middle layer managing the events coming from multiple Asterisk systems, as well as which objects (such as a Bridge or a Channel) live on which Asterisk system, the process of handling a graceful migration would look something like the following:

Given a conference on Asterisk A, consisting of Bridge 1A and multiple Channels, and given an Asterisk B instance:
* Create a new Bridge 1B on the Asterisk B instance
* Issue a redirect [1] to each channel in Bridge 1A to the Asterisk B instance. Note that the redirect command uses the same syntax as the Transfer dialplan application [2] (where the endpoint being redirected to replaces the dial string in the Transfer app). I've found it useful in the past to have a special extension 'entrance' on Asterisk instances the understand that channels entering there came from another Asterisk instance, so that they can convey that information appropriately to the listening external applications, who will have to update their channel state information.
* As each channel arrives on the Asterisk B instance, place them into the new Bridge 1B

That handles the scenario for graceful failover.

For non-graceful, Asterisk does not today have the ability to re-INVITE channels to a new Asterisk instance within the same dialog. The best your application can do is to detect the death of an Asterisk instance, build a new Bridge on a new Asterisk instance, and create new channels to the participants.

[1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+13+Channels+REST+API#Asterisk13ChannelsRESTAPI-redirect
[2] https://wiki.asterisk.org/wiki/display/AST/Asterisk+13+Application_Transfer

--
Matthew Jordan
Digium, Inc. | Director of Technology
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
_______________________________________________
asterisk-app-dev mailing list
asterisk-app-dev@xxxxxxxxxxxxxxxx
http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev

[Index of Archives]     [Asterisk SS7]     [Asterisk Announcements]     [Asterisk Users]     [PJ SIP]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Linux API]

  Powered by Linux