Quote:
|
Originally Posted by evilbunny
I thought voxalot failed over to other providers (if you list them) if enum lookups/connections failed...
As far as I can see, everything you're telling me has to do with failure to fail over to other routes, and doesn't really require turning enum records on and off...
|
FWIW I think you are both making good points. You are quite right that "fall over" can handle some of these cases very nicely and quickly. However, I also agree with Ron that this would be a useful, if not "needed", feature.
While "fallover" is a nicer solution overall, it suffers from two important issues:
1) "Fallover" is entirely dependent upon the CLIENTs using the ENUM to call them (which the person who "owns" the ENUM record can't control). While some clients may do decent fallover, others may just fail if the call doesn't go through via the "primary" route. And since this is CLIENT software, there can be a HUGE variety in quality in "fall over".
2) And in some cases, the primary route is still present, just not desireable to use for a time. For example, you are going on vacation for a few weeks, and want to do something different with your ENUM listing during that time.
The point is, the ENUM listing is controlled by the person with the e164.org account, but the "fallback" is controlled by each and everyone calling you. So what Ron and I would prefer, is a way to more easily make "temporary" changes in our ENUM listing (the part of ENUM use we, not the people calling us, control).
Of course, we do have a "work around". Since the ENUM listing details don't require "verification" (unlike the initial adding of the telco number), we can easily just add/delete those details as needs change. So the power to do what we want, is already in e164.org's web site! However, Ron is also correct that these "changes" are often "short term (a few days, while on vacation, for example). So it can be a little bit of a PITA to have to delete the ENUM route entirely, just to enter all the details again later when, we want to again "enable" that route. Hence the request for an "enable" checkbox (by each individual route) that can be "unchecked". The idea being, the details of that route remain in the e164.org web portal, but are not "published" while the box is "unchecked". This makes "reenabling" the route a simple matter of again checking the box (vs having to enter all the route's details when you want to "enable" a previous route).
NOTE:
I think we are all aware the DNS has "caching". So there will always be a delay (often at least a few minutes, if not longer) between the time you make any update to e164.org, and the time the clients see that change. That's just a limit we all have to live with.
But that delay doesn't mean that there aren't times when people have valid reasons to make temporary (a few days or weeks) changes to their ENUM entry. Those situations happen all the time (not just with "testing", but also with trips out of town, when hardware has problems, etc.). And if you know you will be using a given ENUM route again later, it seems that a "disable" option would be more handy to the users, then the current situation (where they have to "delete the route", just to enter those details again when they want to "reenable").
However, it is true that the ability to adjust the records in this fashion is already present (by the delete and readd option). So this is really only an "ease of use" (of your web portal) issue, not a "functionality issue" (as users have a way to get the desired effect, just not a handy way).