Click Here To Visit SIP Broker  

Go Back   Voxalot / SIP Broker Support Forums > ENUM.164 > e164.org Support

e164.org Support Support forum for the e164.org ENUM directory

 
 
Reply
Thread Tools Display Modes
Unread 04-05-2006, 04:25 AM   #1
Ron
 
Join Date: Feb 2006
Posts: 447
Thanks: 4
Thanked 8 Times in 8 Posts
Ron will become famous soon enough
Default ENUM ON/OFF Switch

Is there a way to briefly disable an ENUM record on e164.org without totally deleting it and then re-entering it? I frequently want to turn off an ENUM record for a short test, but I don't find a way to do so without completely deleting it. Shouldn't there be an 'Enable' check-box on an ENUM record that can be unchecked to temporarily disable it?

Ron
Ron is offline   Reply With Quote
Unread 04-06-2006, 08:54 AM   #2
evilbunny
Senior Member
 
Join Date: Feb 2006
Posts: 176
Thanks: 0
Thanked 14 Times in 10 Posts
evilbunny is on a distinguished road
Default

Wouldn't a override code be more useful, after all with enum you're at the mercy of the DNS systems and DNS caching etc...
evilbunny is offline   Reply With Quote
Unread 04-06-2006, 11:58 AM   #3
Ron
 
Join Date: Feb 2006
Posts: 447
Thanks: 4
Thanked 8 Times in 8 Posts
Ron will become famous soon enough
Default

Quote:
Originally Posted by evilbunny
Wouldn't a override code be more useful, after all with enum you're at the mercy of the DNS systems and DNS caching etc...
Could you explain in a little more detail what you have in mind?

I currently have my Verizon PSTN number listed on e164.org with a record pointing to my VoXaLot number. As you would expect, if I try to call my Verizon number from VoXaLot, I get a busy. There are times (for testing, debuging, if VoXaLot were to be down for a lengthy period, etc.) that I'd like calls to go to Verizon instead of VoXaLot. Since Sip Broker (and presumably many other services) also do ENUM lookups, I was aiming for a centralized solution.

Your thoughts would be greatly appreciated.

Ron
Ron is offline   Reply With Quote
Unread 04-07-2006, 01:04 AM   #4
evilbunny
Senior Member
 
Join Date: Feb 2006
Posts: 176
Thanks: 0
Thanked 14 Times in 10 Posts
evilbunny is on a distinguished road
Default

Quote:
Originally Posted by Ron
I currently have my Verizon PSTN number listed on e164.org with a record pointing to my VoXaLot number. As you would expect, if I try to call my Verizon number from VoXaLot, I get a busy. There are times (for testing, debuging, if VoXaLot were to be down for a lengthy period, etc.) that I'd like calls to go to Verizon instead of VoXaLot. Since Sip Broker (and presumably many other services) also do ENUM lookups, I was aiming for a centralized solution.
I misunderstood that you meant for outbound, not inbound, what people should be doing remotely is setting up fail overs. If one route is dead calls should automatically fail over to PSTN etc...

Have a look at our enumlookup samples for asterisk:

http://www.e164.org/config.php?dp=NA

These examples were updated for 1.2 branch of asterisk, and could be cleaned up further, but they show how to fail over a call to PSTN...
evilbunny is offline   Reply With Quote
Unread 04-07-2006, 02:48 AM   #5
Ron
 
Join Date: Feb 2006
Posts: 447
Thanks: 4
Thanked 8 Times in 8 Posts
Ron will become famous soon enough
Default

Apparently we're still not on the same track.

I don't use Asterisk. Currently, my main VoIP access point is VoXaLot. I have all of my outgoing providers set up here for outbound dialing and most of my incoming providers forwarded to here for inbound answering. Failover is not of concern to me at the moment.

I added my Verizon PSTN number to ENUM at e164.org thinking that I helping other VoIP users who call me avoid the expense of a PSTN call. I really like that idea. However, there are frequent times that I'd like to set that ENUM entry to 'Inactive' so that I can intentionally have the call go through Verizon. At the moment, I have to delete the entry on e164.org, perform my tests, and then go back and re-enter all the info again on e164.org. While this works, it's awfully cumbersome compared to having the ability to simply uncheck an 'Active' checkbox on the e164.org record.

Ron
Ron is offline   Reply With Quote
Unread 04-07-2006, 09:43 AM   #6
evilbunny
Senior Member
 
Join Date: Feb 2006
Posts: 176
Thanks: 0
Thanked 14 Times in 10 Posts
evilbunny is on a distinguished road
Default

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...
evilbunny is offline   Reply With Quote
Unread 04-07-2006, 01:34 PM   #7
DracoFelis
 
DracoFelis's Avatar
 
Join Date: Mar 2006
Posts: 188
Thanks: 4
Thanked 64 Times in 41 Posts
DracoFelis is a jewel in the roughDracoFelis is a jewel in the rough
Default

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).
DracoFelis is offline   Reply With Quote
Unread 04-07-2006, 08:34 PM   #8
evilbunny
Senior Member
 
Join Date: Feb 2006
Posts: 176
Thanks: 0
Thanked 14 Times in 10 Posts
evilbunny is on a distinguished road
Default

http://www.e164.org/Terryexe.zip
http://www.e164.org/terry-20040608.zip

Not sure which was more up to date... System tray util that drops the TTL on the zone for your entries to 60 seconds and other neat tricks...
evilbunny is offline   Reply With Quote
Unread 04-08-2006, 01:46 AM   #9
Ron
 
Join Date: Feb 2006
Posts: 447
Thanks: 4
Thanked 8 Times in 8 Posts
Ron will become famous soon enough
Default

Let me try this one more time...

My request for a simple way (i.e. an 'Active (Yes/No)' option) to enable/disable an ENUM record entry has *absolutelty* nothing to do with failover. I know what failover is. I strongly believe anyone doing ENUM lookups should have a solid failover strategy. I fully understand the mechanics involved in implementing failover support. But I want to be perfectly clear here: The reason I started this thread has *absolutelty* nothing to do with failover.

I currently have a single ENUM record on e164.org. That ENUM record specifies a SIP URI for a PSTN telephone number. Any service (VoXaLot and Sip Broker, for example) that does ENUM lookups direct calls to that SIP URI as expected and intended.

There are many circumstances when I (typically for a short period of time) do NOT want calls to this PSTN number redirected to the specified SIP URI by *anyone*. I want the ENUM record at e164.org to effectively disappear from the e164.org database. The only way I know how to accomplish this at the moment is by actually deleting the record from e164.org. This approach certainly works. When I want it back, I simply create it again. This is somewhat cumbersome. Even worse, it appears e164.org considers this to be abusive (from the e164.org FAQ):

"Once a number is deleted, it must be re-verified. A number that is deleted and re-added repeatedly may be suspended."

It would be much simpler for users and non-abusive to e164.org if the ENUM record had an 'Active' flag associated with it that could be toggled by the owner. If the 'Active' flag is false, e164.org would simply skip over this record as if it didn't exist when it comes to normal processing operations on its database.

I fully understand the implications of DNS caching and the propogational delays involved with it. But an 'Active' flag does not change this behavior in any way compared to deleting and recreating entire ENUM records.
Ron is offline   Reply With Quote
Unread 04-08-2006, 11:38 AM   #10
evilbunny
Senior Member
 
Join Date: Feb 2006
Posts: 176
Thanks: 0
Thanked 14 Times in 10 Posts
evilbunny is on a distinguished road
Default

As DracoFelis points out you don't need to remove the number to remove the enum records associated with it.

Did you get a chance to check the links posted, the systray util will do what you are after...
evilbunny is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
e164.apra vs e164.org Same Lookup method? MarkLL e164.org Support 6 12-25-2007 08:25 AM
Questions Regarding Enum Lanh e164.org Support 4 04-07-2007 03:16 PM
ENUM routing not working jonfry Voxalot Support 1 07-25-2006 03:09 AM
ENUM Records Using DYNDNS.ORG Ron e164.org Support 10 06-10-2006 01:05 AM
Possible ENUM Lookup Problem melbournelees Voxalot Support 7 04-11-2006 08:21 AM


All times are GMT. The time now is 01:28 PM.


Powered by vBulletin® Version 3.7.2
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.