Douglas Garstang
2006-Jun-14 20:07 UTC
[Asterisk-Users] 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
Watkins, Bradley
2006-Jun-15 01:41 UTC
[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. 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
Douglas Garstang
2006-Jun-15 07:48 UTC
[Asterisk-Users] DUNDi Not Able to Handle Complex FailoverSituations
> -----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.
Douglas Garstang
2006-Jun-15 07:49 UTC
[Asterisk-Users] DUNDi Not Able to Handle Complex FailoverSituations
> -----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.
Stephen Davies
2006-Jun-15 10:40 UTC
[Asterisk-Users] DUNDi Not Able to Handle Complex FailoverSituations
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