[Asterisk-Users] DUNDi Not Able to Handle Complex Failover Situations

[Douglas Garstang]

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.