[Asterisk-Users] DUNDi Not Able to HandleComplexFailoverSituations

[Douglas Garstang]

> -----Original Message-----
> From: Douglas Garstang 
> Sent: Thursday, June 15, 2006 1:23 PM
> To: 'Asterisk Users Mailing List - Non-Commercial Discussion'
> Subject: RE: [Asterisk-Users] DUNDi Not Able to
> HandleComplexFailoverSituations
> 
> 
> > -----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}/${NUMBE
> R},nopartial
> 180q => 
> global_dundi_q_pbx2,200,IAX,dundi2:${SECRET}@${IPADDR}/${NUMBE
> R},nopartial
> 180q => 
> global_dundi_q_pbx3,300,IAX,dundi3:${SECRET}@${IPADDR}/${NUMBE
> R},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}/${NUMBE
> R},nopartial
> 180q => 
> global_dundi_q_pbx3,300,IAX,dundi3:${SECRET}@${IPADDR}/${NUMBE
> R},nopartial
> 
> I really don't follow.

Ahh this reminds me too. If I am going to be getting the local system first always, then I need to be able to return ALL the Dundi paths with the DUNDILOOKUP function. It only returns one. How can I get DUNDILookup to return every single path? It'd be great if they could return the weights for each too, and then I could do my own logic.