[Asterisk-Users] DUNDi Not Able to HandleComplexFailoverSituations

[Douglas Garstang]

> -----Original Message-----
> From: Aaron Daniel [mailto:amdtech at shsu.edu]
> Sent: Thursday, June 15, 2006 12:59 PM
> To: Asterisk Users Mailing List - Non-Commercial Discussion
> Subject: RE: [Asterisk-Users] DUNDi Not Able to
> HandleComplexFailoverSituations
> 
> 
> On Thu, 15 Jun 2006, Douglas Garstang wrote:
> > We need our queue application to follow the primary pbx 
> server for a set of phones within a company. See my 'ACD 
> Distributed Scenario' post made a little earlier for a full 
> explanation.
> 
> 
> OK, let me get this straight.
> 
> You want the phones on the SAME server to hit the queues on 
> THAT server 
> only.  Right?
Unless there's a server failure. 

 
> If that's right, then why use DUNDi for the queues, just set up an 
> extension (i.e. the queue entry point) that goes straight 
> into the queue 
> instead of using DUNDi for it, which adds more logic to 
> something VERY 
> simple.  Since the phones are registered to that server, 
> obviously they 
> will drop into the local queue and not some random one.
Have a read of the post 'Distrubuted ACD Scenario' posted earlier. It really explains it clearly, and states what the sticking point is. Also have a read of Bradley Watkins post. He seems to have a grasp of it, and doesn't see a simple solution.


> 
> You're making something dynamic that really shouldn't be 
> dynamic at all. 
> When the failover happens, the new primary server will have 
> the queue set 
> up, and anyone calling in will be calling into the queue on 
> that server.

Not necessarily. They might be calling in from a different server. We have to ensure that we lookup the correct combination of primary/secondary server for the queue, and what's actually available, and IAX the call over to THAT box to process the Queue() command.


> 
> Now, if you're calling in from another server, i.e. someone outside 
> calling in, you can then use DUNDi with weights to drop them onto the 
> right server, but that's another story.
> 
> Finally, in order for the LOCAL server's DUNDi response to 
> show up, you 
> have to add the server to dundi.conf.  So, so pbx1 has to be 
> in pbx1's 
> file, just like the other servers do.

No... this last bit doesnt. My dundi.conf has:
180q => global_dundi_q_pbx1,100,IAX,dundi1:${SECRET}@${IPADDR}/${NUMBER},nopartial
180q => global_dundi_q_pbx2,200,IAX,dundi2:${SECRET}@${IPADDR}/${NUMBER},nopartial
180q => global_dundi_q_pbx3,300,IAX,dundi3:${SECRET}@${IPADDR}/${NUMBER},nopartial

What are you suggesting I change it to? Something like this?

180q => global_dundi_q_pbx1,100,IAX,dundi1:${SECRET}@$xxx.187.142.205/${NUMBER},nopartial
180q => global_dundi_q_pbx2,200,IAX,dundi2:${SECRET}@${IPADDR}/${NUMBER},nopartial
180q => global_dundi_q_pbx3,300,IAX,dundi3:${SECRET}@${IPADDR}/${NUMBER},nopartial

I really don't follow.