asterisk users - Jun 2006 - DUNDi Not Able to HandleComplexFailoverSituations

> -----Original Message-----
> From: Watkins, Bradley [mailto:Bradley.Watkins@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

Got it.  For some reason it took a looooooooong time for this to reach
the list.  I wrote it before you posted your explanation, which I am now
thinking about...

Regards,
- Brad 

-----Original Message-----
From: asterisk-users-bounces@lists.digium.com
[mailto:asterisk-users-bounces@lists.digium.com] On Behalf Of Douglas
Garstang
Sent: Thursday, June 15, 2006 2:16 PM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: RE: [Asterisk-Users] DUNDi Not Able to
HandleComplexFailoverSituations
> -----Original Message-----
> From: Watkins, Bradley [mailto:Bradley.Watkins@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

_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --

Asterisk-Users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose it
to anyone else. If you received it in error please notify us immediately and
then destroy it.

> -----Original Message-----
> From: Aaron Daniel [mailto:amdtech@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.

> -----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@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.

Thanks Aaron. I got the local lookup to work. MIGHT have fixed our problem. 
I ain't gonna poo my pants with excitement yet tho...
> -----Original Message-----
> From: Aaron Daniel [mailto:amdtech@shsu.edu]
> Sent: Thursday, June 15, 2006 1:40 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:
> > 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.
> 
> Here's an example.  We have two primary call servers, both 
> are capable of 
> handling the call volume if one fails out.  They're scm1 and scm2.
> 
> scm1 has a peer section for itself, so it shows up during 
> lookups.  scm2 
> has a peer section for itself as well.  They also have peer 
> sections for 
> each other and for the gateways:
> 
> scm1:
> [00:E0:81:25:28:D3]
> model = symmetric
> host = sgw1
> inkey = sgw1
> outkey = scm1
> include = all
> permit = all
> qualify = yes
> 
> [00:14:22:13:90:8D]
> model = symmetric
> host = scm1
> inkey = scm1
> outkey = scm1
> include = all
> permit = all
> qualify = yes
> 
> [00:14:22:13:B6:B6]
> model = symmetric
> host = scm2
> inkey = scm2
> outkey = scm1
> include = all
> permit = all
> qualify = yes
> 
> [00:13:72:4E:D7:54]
> model = symmetric
> host = sgw2
> inkey = sgw2
> outkey = scm1
> include = all
> permit = all
> qualify = yes
> 
> scm2 will be exactly the same except it has an outkey of scm2.  This 
> should fix your issue with having dundi lookup on the local machine.
> 
> I'm not gonna try to understand your ACD stuff right now, so 
> I'll just 
> figure you need DUNDi for that and give up on it :)  Too busy 
> fixing the 
> voicemail app.
> 
> -- 
> Aaron Daniel
> Computer Systems Technician
> Sam Houston State University
> amdtech@shsu.edu
> (936) 294-4198
> _______________________________________________
> --Bandwidth and Colocation provided by Easynews.com --
> 
> Asterisk-Users mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-users
>

> -----Original Message-----
> From: Michael Collins [mailto:mcollins@fcnetwork.com]
> Sent: Monday, June 26, 2006 4:34 PM
> To: Asterisk Users Mailing List - Non-Commercial Discussion
> Subject: RE: [Asterisk-Users] DUNDi Not Able to
> HandleComplexFailoverSituations
> 
> 
> > > I get annoyed Stephen when Digium goes around calling Asterisk
> > 'enterprise grade', which in my opinion it really isn't. 
> I'd consider
> > distributed ACD queues to be a requirement for an enterprise grade
> > product, but it's becoming apparent that there is no mechanism for
> > implementing this. I'm being told that DUNDi isn't the right
man for
> the
> > job.
> > 
> > I'd suggest you ask Digium for your money back.
> > 
> > Leif.
> 
> 
> Question: isn't there a bigger picture issue here?  I've seen a lot
of
> bashing going on in this thread but not very much useful dialogue.
> (Doug bashing DUNDi and Digium, other people bashing Doug for his
> "annoying" posts, etc.)  
> 
> Whether or not we like or dislike Doug's tone is, IMHO, 
> irrelevant.  How
> about we tackle the REAL questions: If DUNDi isn't the 
> answer, what is?
> Is Asterisk even capable of doing what Doug needs, namely, distributed
> ACD queues?  If so, how?  If not, why?  Is it even feasible 
> to try to do
> it?  Will it require an Asterisk add-on, or can the core be 
> modified to
> do this? (This leads to the question for the dev list...)
> 
> These questions, of course, lead to other questions: If * can be
> programmed to do distributed ACD queues, does that mean there 
> are other
> features that might benefit from a "distributed" model?  
> Etc., etc.  I'm
> just throwing out ideas because maybe one of these ideas can 
> turned into
> a killer app, just like Asterisk itself.  Just think of the advantage
> you would have if you wanted to sell Asterisk against one of the big
> boys.  How much would a fully redundant, HA Asterisk system cost
> compared to the same thing by Cisco, Avaya, Nortel, NEC...  
> You get the
> idea.  
> 
> The moral of this post: a little good-natured bashing is just 
> fine, but
> let's not lose sight of the ultimate goal, which is to keep making
> Asterisk a better product.
Michael, I haven't seen much of a response to this post of yours. That's
unfortunate. I was hoping it would spur some constructive conversation. Had you
had any response off-list?

Doug.