asterisk users - Jun 2006 - DUNDi Not Able to Handle ComplexFailoverSituations

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.

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 10:50 AM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: RE: [Asterisk-Users] DUNDi Not Able to Handle ComplexFailoverSituations
> -----Original Message-----
> From: Watkins, Bradley
> [mailto:asterisk-users-bounces@lists.digium.com]On Behalf Of Watkins, 
> Bradley
> Sent: Thursday, June 15, 2006 2:41 AM
> To: Asterisk Users Mailing List - Non-Commercial Discussion
> Subject: RE: [Asterisk-Users] DUNDi Not Able to Handle Complex 
> FailoverSituations
> 
> 
> Unless I'm misunderstanding what you're looking to do, Aaron has
hit
> the nail on the head here.? You need to set it up so that the 
> secondary, tertiary, etc. boxes are weighted differently.? That way, 
> you need not know or care about the weights directly within the 
> dialplan.
It isn't as simple as that. When a failure occurs, we only want to use a
DUNDi route when it's the primary for a queue.
_______________________________________________
--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 9:54 AM
> To: Asterisk Users Mailing List - Non-Commercial Discussion
> Subject: RE: [Asterisk-Users] DUNDi Not Able to Handle
> ComplexFailoverSituations
> 
> 
> On Thu, 15 Jun 2006, Douglas Garstang wrote:
> > It isn't as simple as that. When a failure occurs, we only 
> want to use a DUNDi route when it's the primary for a queue.
> 
> Then don't use DUNDi for queues, use it just for the phones.  
> Seriously, 
> you obviously know exactly which servers you want to be primary for a 
> certain queue, program it into the dialplan.  DUNDi should 
> only be used 
> for DYNAMIC extensions, i.e. phones that may or may not be 
> registered at 
> the time of the call, phones that move, phones that register with 
> different servers at different times.
> 
> If you're deadset on using DUNDi for it, set up different 
> DUNDi contexts 
> so that you can say "these queues are available here" and 
> "these queues 
> are available there".
> 
> Honestly, it seems like a waste of server time to use DUNDi 
> for something 
> that you know is going to be on a particular server 
> regardless of what 
> happens.
If we don't use DUNDi, then how are we going to get the Queue() application
to follow the pbx server, and execute on the same Asterisk box that the phones
are registered on?

Doug.

> -----Original Message-----
> From: Aaron Daniel [mailto:amdtech@shsu.edu]
> Sent: Thursday, June 15, 2006 9:57 AM
> To: Asterisk Users Mailing List - Non-Commercial Discussion
> Subject: RE: [Asterisk-Users] DUNDi Not Able to Handle
> ComplexFailoverSituations
> 
> 
> On Thu, 15 Jun 2006, Douglas Garstang wrote:
> > DUNDi does not handle the situation of phone failover as 
> well as static numbers (ie queues), which is what we are 
> trying to acheive.
> 
> I'm confused, explain the phone failover not working to me.
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.

Doug.

> -----Original Message-----
> From: Stephen Davies [mailto:stephen.l.davies@gmail.com]
> Sent: Thursday, June 15, 2006 11:41 AM
> To: Asterisk Users Mailing List - Non-Commercial Discussion
> Subject: Re: [Asterisk-Users] DUNDi Not Able to Handle
> ComplexFailoverSituations
> 
> 
> On 15/06/06, Douglas Garstang <dgarstang@oneeighty.com> wrote:
> > Who said I was a C programmer?
> 
> Speaking for myself, I just assumed that you understood that the
> behaviour of an open-source application was the result of contributed
> code.  Your message read to me like something of a demand that
> "someone" fixed it.  You are probably trying to do something
pretty
> fancy in your dialplan and that probably brings requirements that the
> original authors didn't foresee.
> 
> They are scratching their itch.  As you said, DUNDi was Mark's
> initiative to make a "open access" call routing system, rather
than to
> do with failover.
> 
> If you can hack Asterisk dialplan code, then I think if you open that
> file, take a look at other code that sets variables (search for a
> variable name you know is set, like DIALSTATUS), do some cut and paste
> and you'll discover that, guess what: you ARE a C programmer.
Actually, I'd say I'm not a C programmer. In Asterisk 1.2.7.1, in
pbx_dundi.c, function dundi_lookup_exec(), I Added this line:

pbx_builtin_setvar_helper(chan, "DUNDWEIGHT", dr[x].weight);

right below the two other lines that set the DUNDTECH and DUNDDEST variables.
When I execute my DundiLookup application in the dialplan, the Asterisk console
bombs out. I assume it's core dumping or something. I don't know why
though as I only added another line like the ones above. The DUNDTECH and
DUNDDEST variables are not being referenced anywhere else in any file.

ALSO... The DundiLookup application command has been deprecated:

Jun 15 12:44:14 WARNING[2935]: pbx_dundi.c:3872 dundi_lookup_exec: This
application has been deprecated in favor of the DUNDILOOKUP dialplan function.

In favour of the DUNDILookup function. The DUNDILookup function does NOT seem to
set the DUNDTECH and DUNDDEST variables, so it seems we have in effect gone
backwards in functionality. In any case, I guess I'll have to try and figure
out how to modify the string that DUNDILookup returns, which I'm sure will
be harder than adding a new variable to DundiLookup()

Doug.

> -----Original Message-----
> From: Douglas Garstang 
> Sent: Thursday, June 15, 2006 12:51 PM
> To: 'Asterisk Users Mailing List - Non-Commercial Discussion'
> Subject: RE: [Asterisk-Users] DUNDi Not Able to Handle
> ComplexFailoverSituations
> 
> 
> > -----Original Message-----
> > From: Stephen Davies [mailto:stephen.l.davies@gmail.com]
> > Sent: Thursday, June 15, 2006 11:41 AM
> > To: Asterisk Users Mailing List - Non-Commercial Discussion
> > Subject: Re: [Asterisk-Users] DUNDi Not Able to Handle
> > ComplexFailoverSituations
> > 
> > 
> > On 15/06/06, Douglas Garstang <dgarstang@oneeighty.com> wrote:
> > > Who said I was a C programmer?
> > 
> > Speaking for myself, I just assumed that you understood that the
> > behaviour of an open-source application was the result of 
> contributed
> > code.  Your message read to me like something of a demand that
> > "someone" fixed it.  You are probably trying to do something
pretty
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.