[Asterisk-Users] DUNDi Not Able to HandleComplexFailoverSituations

[Douglas Garstang]

> -----Original Message-----
> From: Watkins, Bradley [mailto:Bradley.Watkins at compuware.com]
> Sent: Thursday, June 15, 2006 10:36 AM
> To: Asterisk Users Mailing List - Non-Commercial Discussion
> Subject: RE: [Asterisk-Users] DUNDi Not Able to
> HandleComplexFailoverSituations
> 
> 
> Is it possible for you to explain in more detail the 
> situation involved.  I'm still thinking that what you're 
> trying to achieve can be done at least with the help of DUNDi 
> weights, but I still don't think I have a full grasp of the 
> solution you're crafting.

Bradley,

See my post titled 'ACD Distributed Scenario' made an hour or two ago. Here it is again, reposted.

We need to make sure that all queue applications run on the correct system that the user agents that own the queue application are registered to. So when a server fails and the user agents register with their secondary server (which will always be configured to be the same server for those related agents) the queue application is running on that server and routed to correctly by it's peers. Enters DUNDi: 

Working scenario:

1)      Configured 3 contexts, referenced by DUNDi, to manage which server is the primary, secondary, and tertiary server for each given queue. So:

a.       UA1, 2, and 3 register with Astbox1 as their primary server

b.       Their registration tables refer to Astbox2 as their secondary registration server and Astbox3 as their tertiary registration server

c.       Agents are logging into the queue1 via UA1, 2, and 3 

d.       Queue1's dial plan logic is in the same context on all boxes

e.       Queue1's dial plan logic is referred to via 3 different DUNDi contexts weighted according to which server is the primary, secondary, and tertiary host server for the user agents (UA1,2, and 3)

f.        So queue1, assigned the phone number of 5551212, is assigned to the Primary DUNDi context on Astbox1 with the weight of 0

g.       Then queue1 is assigned to the secondary DUNDi context on Astbox2 with the weight of 100 and to the tertiary DUNDi context on Astbox3 with the weight of 200

h.       So let's say we make a call from an User Agent on Astbox2 to 5551212

i.         When determining which server to terminate a call to 5551212 on we do a local lookup first on Astbox2 to see if the primary server for that number happens to be the server performing the routing logic... if so, we directly route the call to that queue on the local server

j.        In this case Astbox2 does not refer to queue1 in the primary DUNDi context, Astbox1 refers to queue1 in it's primary context, so we do a DUNDi lookup to find the next server we should route the call to

k.       Due to weighting, we receive the IP of Astbox1 as the first DUNDi destination and the IP of Astbox3 as a second DUNDi destination serving that queue and we route the call to the first destination IP

l.         Everything is fine... but when the primary server fails (Astbox1) and the the secondary server happens to be the box that is routing the call (Astbox2) there is a logic gap we need help addressing

2)      Logic gap we need to address

a.       UA1, 2, and 3 normally register with Astbox1 as their primary server but it  has now failed

b.       So UA1, 2, and 3 now register with Astbox2 

c.       Due to queue1's routing logic, that the agents assigned to UA1, 2, and 3 log into, residing in the same context on all boxes we are able to handle calls to that context on Astbox2 (please refer to our statement in 1.d through 1.g to re-paraphrase the queue and agent relationship)

d.       So let's say we make a call from a user agent Astbox2 to 5551212