asterisk users - Jun 2006 - DUNDi Not Able to Handle Complex FailoverSituations

Who said I was a C programmer? 

	-----Original Message----- 
	From: Terry Wilson [mailto:otherwiseguy@gmail.com] 
	Sent: Wed 6/14/2006 6:03 PM 
	To: Asterisk Users Mailing List - Non-Commercial Discussion 
	Cc: 
	Subject: Re: [Asterisk-Users] DUNDi Not Able to Handle Complex
FailoverSituations
	
	
	pbx/pbx_dundi.c in dundifunc_read().  shouldn't be too hard to have it set
some variables (i.e. DUNDI_RESULT_n) and add the the weight in a CUTable string.
Can't return multiple results in a nice manner with the result from a custom
dialplan function...  I'm working on some other projects right now, but
I'm sure the Digium folks would welcome a patch from you if you really want
it.
	
	
	On 6/14/06, Douglas Garstang <dgarstang@oneeighty.com> wrote: 

		This is driving me nuts.
		
		Why doesn't the DUNDILOOKUP function return the weight of a path to a
number? The CLI 'dundi lookup' command does. What about the mac address
and expiry period? The CLI command returns those, but the DUNDILOOKUP function
does not. Why?
		
		We absolutely need this in order to perform out routing logic.
		
		It has become quite apparent to me that DUNDi is _NOT_ suited to performing
failover applications. It is suited to situations where you want to check a
number on a series of peers before routing the call through an expensive PSTN
gateway. It is not suited to situations where you want to dynamically discover
where a number is located within a cluster of Asterisk systems.
		
		In our particular scenario, we have ACD queues. Our phones register with a
primary Asterisk box. The primary Asterisk box for company A may be different to
the primary Asterisk box for company B. In the event that a user in company B
wants to reach Company A's queue, we need to use DUNDi to perform a lookup
that returns it's company A's primary Asterisk box. However, the primary
Asterisk box may have failed, it which case the DUNDi lookup should return the
secondary Asterisk system for Company A to the dial plan routing the call. This
may have not made sense.... brain is fried after dealing with this all day.
		
		DUNDi seems to be falling really short in performing complex discovery and
failover applications like this. If the DUNDILOOKUP fuction returned a weight,
it would help a lot.
		
		Oh... also.... when you call the dundi lookup CLI command, you get multiple
results. The DUNDILOOKUP function only returns one value. How can I get _all_
DUNDi paths with DUNDILOOKUP?
		
		Doug.
		
		_______________________________________________
		--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

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.
 
Regards,
- Brad

________________________________

From: asterisk-users-bounces@lists.digium.com on behalf of Aaron Daniel
Sent: Wed 6/14/2006 9:09 PM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [Asterisk-Users] DUNDi Not Able to Handle Complex
FailoverSituations



On Wed, 14 Jun 2006, Douglas Garstang wrote:
> Why doesn't the DUNDILOOKUP function return the weight of a path to a
number? The CLI 'dundi lookup' command does. What about the mac address
and expiry period? The CLI command returns those, but the DUNDILOOKUP function
does not. Why?
Correct me if I'm wrong, but DUNDi is doing all the failover work for you.
It decides based on the weights what route is best.  If you want one route
to be higher than another, set it up that way.  That's the benefit of
using DUNDILOOKUP to handle it, no more work for you after the initial
routing.

If that doesn't work for you, program the routes directly into the
dialplan instead of using DUNDi, it seems like you'll get better results
that way.  We did that for a while until we decided to move to DUNDi.
Some people will find it more suited to their needs, some won't.


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



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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 3981 bytes
Desc: not available
Url :
http://lists.digium.com/pipermail/asterisk-users/attachments/20060615/7fa1669d/attachment.bin

> -----Original Message-----
> From: Aaron Daniel [mailto:amdtech@shsu.edu]
> Sent: Wednesday, June 14, 2006 7:10 PM
> To: Asterisk Users Mailing List - Non-Commercial Discussion
> Subject: Re: [Asterisk-Users] DUNDi Not Able to Handle Complex
> FailoverSituations
> 
> 
> On Wed, 14 Jun 2006, Douglas Garstang wrote:
> > Why doesn't the DUNDILOOKUP function return the weight of a 
> path to a number? The CLI 'dundi lookup' command does. What 
> about the mac address and expiry period? The CLI command 
> returns those, but the DUNDILOOKUP function does not. Why?
> 
> Correct me if I'm wrong, but DUNDi is doing all the failover 
> work for you. 
> It decides based on the weights what route is best.  If you 
> want one route 
> to be higher than another, set it up that way.  That's the benefit of 
> using DUNDILOOKUP to handle it, no more work for you after 
> the initial 
> routing.
DUNDi does not handle the situation of phone failover as well as static numbers
(ie queues), which is what we are trying to acheive.
> 
> If that doesn't work for you, program the routes directly into the 
> dialplan instead of using DUNDi, it seems like you'll get 
> better results 
> that way.  We did that for a while until we decided to move to DUNDi. 
> Some people will find it more suited to their needs, some won't.
There are no routes. Termination ends at the Asterisk box.

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

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.

If you can't, well lots of us on the list take contracts for
development in the Asterisk code.  Post on asterisk-biz with the
request.

Regards,
Steve