I’m sure that this has been answered before, but I have yet to find where. Basically, we have two asterisk servers in two geographic locations, and I want to set it up like this:
1.) Server 1 receives all incoming calls, and is main proxy for all SIP phones.
2.) Server 2 only receives calls when Server 1 is down (DTO from provider)
3.) All phones have Server 2 as backup proxy.
When server1 is unavailable, our provider will DTO to Server 2, and the incoming calls will pile up in the queue unless agents are logged in . How can I arrange for an extension to be logged in to BOTH servers’ queue when they dial *45 (or some similar code).
I was thinking of a script on Server 2 that would query Server1 periodically, or perhaps a custom context on Server 1 that would use the built-in *45 toggle for server 1 and also send a command to server 2 and do the same. Of course, this gets tricky when it comes to keeping things properly in sync and not just toggling things without checking the current state, etc.
Hopefully someone can point me in the right direction,
I started to ask this question again today and was reminded of this old thread I started that received no replies. Has nobody done this before? Perhaps a commercial module exists?
At the very least, I presume a custom context (extensions_custom.conf) could be crafted that would use the manager interface to log a suer in and out of queues on two different machines simultaneously? Or perhaps a cron job that runs a shell script that grabs the currently logged in users and makes the remote server look the same.
How are you synchronizing the servers currently? Tho I’ve not tried it, the technique described here:
should sync astDB settings along with everything else you select for the backup job.
Thanks, Lorne, for the response. I am not really looking to mirror two servers, though perhaps I should start down that road. I’m also not looking to mirror configuration settings, but rather queue logins.
For example, with one server, I can configure two queues and a user can dial *45 and be logged in or out of both queues at the same time.
What I would like to do is exactly the same thing, but the two queues are on different servers: one on Server A and one on Server B. In other words, when the user logs in to the queue on Server A, some process also logs them in to the queue on Server B. This way, if Server A or its circuit drops and causes a Trunk Group Overflow to Server B, the users will not need to log into Server B to be shown as available in the queue. Instead, if they were logged into the Server A, they will already be logged in to Server B, and Server B will send them calls as if nothing had happened.
Without this, calls will start piling up in the backup server’s queue until we notice and direct our agents to manually log into the queue on Server B.
I’m thinking that this could be doable via the dialplan, but if not, perhaps a process could run in the background, periodically querying the membership of the queue on Server A and using the manager interface to make Server B’s queue membership the same.
might get you started. But you will need to have a route between the two boxen that support multicast through all the routers between (perhaps a vpn ?)
Thanks, Dicko. Am I missing something, or will that only allow Server A to know when devices attached to server B are busy?
Our scenario involves extensions that exist on both servers (one as proxy 1, one as backup), and I need server B to know that extension 403 just logged out of the queue. Does asterisk send events for something like that?
on both servers, you should add the mwi too.
more on Google ; -)
Thanks again. I must be confused, though. My understanding is that, as stated at this link, device state is used to determine if a phone is busy or not.I could use this information to make sure that the queue does not send calls to a phone that is busy with a call from a different server, but I don’t see, even with help from my friend Google, how I could use that information to tell Server B to log that user into Queue 550.
What am I missing?
Have you tried it yet? , you should. . . the device state includes the Queue state, the MWI stanza will propagate similarly the MWI state bidirectionally.
perhaps a little google nudge (asterisk corosync queues)
Sorry to be so dense here, but that doesn’t sound at all like what I am looking for. Corosync seems massively more complicated than what I require, too.
Nothing I can find shows how I would use a device state to say “This device is logged in to queue 500, queue 501, and queue 550” or “This device is not logged in to any queues”. Everything out there seems to be aimed at “This device is busy/invalid/available, so don’t/do send a call from the queue to this device.”
Or are you suggesting that I would simply have all users logged in all the time and have users set presence (not device) states to tell the queue who should/should-not receive calls? That might work, but I doubt that any of the queue monitoring software out there would provide a good way to confirm who is and who is not available at any given time. It certainly does break with the traditional FreePBX model of login/logout/pause, unless I have missed something.
From what I am understanding, you want to replicate the device states between two servers, that is exactly what corosync/ais does for asteri.
Your extensions are arbitrarily logged into one of two presumably identically setup servers (maybe both) , that might change as vagaries of your network changes and the a registration expires, those two servers need to share their “state”, and respond identically if they can talk to each other. IF only one is receiving calls, and they are registered to that same one, all will be well, if the servers/networks are half-assed, then you are screwed, that’s what BGP and SIP proxies are for.
I have used it in the past before reliable HA replication of a deployment between many “Instances” on virtualization became feasible.
It would be the same concept as a poor-man’s syncing of the asterisk sqlite3 database (which maintains the state of the devices (and the MWI indications) ) as Lorne alluded to , it just works at a lower level and symmetrically and will fail-back elegantly and is obviously close to realtime (the old 5 nines concept you need to aspire to) .
As I say, just try it . . . IMHO it is worth the effort.
I think we’re talking about two different things. I don’t care if the servers share device states, if the user is on the phone or ringing or not registered, it doesn’t matter. I want them to share queue member/agent states (i.e.:is this agent/member logged in?).
All devices are registered to both servers, and some extensions sometimes dial *45 to log into a queue on the primary server. When they do, I want the queue on the secondary server to also log that member in. That way, when the primary server or its fiber connection craps out and the calls start coming in to the secondary server, that server knows who is logged in to the queue, NOT who is on the phone or successfully registered to server A, or anything else, just who has raised their virtual hand and said “send calls my way, I’m in the queue!”
Sorry I have been unclear.
then never mind, but it works (at least it did for me, no crickets involved , you just have to get stuck in to how asterisk works ) queues are part of the dynamic “state” of the machine and can be replicated with corosync. no *45 or anything needed that’s just how the dialplan adds that particular device state, as I said, you should try it some time, you will be surprised. But good luck otherwise.
(registration is a different thing, but to part part of a queue, the device must be “registered” on that server to take calls, as you have done already on a second button presumably, look to “realtime” asterisk for dynamic registration , but that is outside FreePBX. The asteriskdb is thread safe for read and write, but not multi-user safe for either, so watch out for copying the database over without a queue reload and decide how to handle who is the “master” at any particular time)
Any successful implementations of the “poor mans method”? Been trying to figure this one out for awhile and not having any luck.
The “poor-man’s method” is totally impractical as the implementation of Asterisk’s interface to the AstDB (sqlite3) is threadsafe but not multiuser safe, you can’t even safely read it never mind write it as the locking system is just plain selfish. (Yes I’ve tried )
We were thinking of something similar (for our warm spare), but we ended up setting up a primary and secondary Queue.
Primary Queue is everyone added as dynamic agents, and if no one is logged in it goes automatically to the secondary Queue where everyone is added as a Static Agent.
If the primary PBX fails, it’ll ring by everyone (since no one is logged in to the primary queue on the warm spare) and they know to log in again. Works perfect. They just have to press the BLF key one more time, fine with them…
Thanks for all the replies. I liked the idea of static users on the secondary, but alot of our users are home workers and if not on shift, it would be alot of unanswered calls. (Call center). Anyone know if the corosync option could be built as a module or add on of some type?
Old topic, same subject…
So I did some digging after a recent virtual meeting with some of the Sangoma team.
When doing a warm spare restore, it replicates the primary asterisk database, and I see in the warm spare DB the logged in dynamic queue members from the primary server.
[root@wstest ~]# asterisk -x"database show" | grep "Queue/PersistentMembers/5110 "
/Queue/PersistentMembers/5110 : Local/501@from-queue/n;0;0;YP Test;hint:501@ext-local;;0
However, it does now show up under “
queue show” as logged in, unless I restart asterisk.
Would anyone know of a way to “tell” asterisk to read the DB without having to restart asterisk?
A “workaround” would be to call a script that restarts asterisk in the post restore hook, but that is not very elegant. I am also planning to run a script multiple times during the day to sync that value only and I don’t feel comfortable to restart asterisk that many times. Especially when there’s a chance that the WS will be in use…
Did you ever make any headway with this? Still chasing the elusive fix…Thanks in advance.