enumlookup.agi slow due to non-exitent domains in lookup

Thanks. Patch files are general the best and quickest way of getting changes committed

Replying to lazytt:

Thanks. Patch files are general the best and quickest way of getting changes committed

Ah - sorry. I'm more a hacker than a developer. I guess I'll review the development FAQ/WIKI to ensure I post issues more appropriately in the future :)

Thanks.

habile: your report was just fine. Often people forget the amount of work that this (or any) project takes. Not everyone has the skills to post patches, and they are by no means mandatory. But if you can - it is defiantly appreciated and helpful.

if you want to conclusively tell me that e164.arpa and e164.info do not exist, I'll be glad to make the change. I don't keep up with e164 so am counting on others to keep me honest.

habile: btw, as an fyi on patch files, the two easiest ways to make a patch file are:

diff -ubB original_file modified_file > mypatch.diff

Or - if you keep a local pull of the svn tree on your system to download, just make the changes in the file there, and then type:

svn diff file_name > mypatch.diff

Thanks for the patch info, I will keep this in mind.

Hmmm... I'm a little bit nervous now - let me try to fully research the e164 issue before I commit to this. Right now, I know that they are not resolving and have not done for some time - just not sure how to completely verify it, Google here I come.

OK - I think I'm talking out of an orifice much better suited for other purposes here.

This is certainly an issue on my system, I don't know why the DNS lookup for arpa and info slow this down. I think it's possibly my route to those DNS servers.

My apologies for not fully researching this before submission. Still, maybe someone else will hit the same issue and can consider this as a possible bottleneck when using ENUM.

Thanks for humouring me. I'll get back to my day job (which incidentally I'm not very good at either! - just don't tell my boss).

hmmm

C:\Documents and Settings\user>nslookup
*** Can't find server name for address 192.168.1.1: Non-existent domain
*** Default servers are not available
Default Server:  UnKnown
Address:  192.168.1.1

> e164.org
Server:  UnKnown
Address:  192.168.1.1

Non-authoritative answer:
Name:    e164.org
Address:  208.70.151.161

> e164.arpa
Server:  UnKnown
Address:  192.168.1.1

*** No address (A) records available for e164.arpa
> e164.info
Server:  UnKnown
Address:  192.168.1.1

*** No address (A) records available for e164.info
>

Yeah - this is what I found but I don't know if it's valid to check it this way.

It looks to me that these domains have been hijacked by other entities but it's all a bit vague.

Sorry for the can 'o worms.

no can of worms. If the concensus is they should be removed, I'm happy to remove them. I'm just looking to the enum users to make that decision. Had anyone checked what the built in Asterisk enum application uses?

OK - what is the resolution here, do I take those out and speed up enum? I'm waiting on your feedback (or I'll close the bug:( )

For me, I need them out and I guess as the others do not seem to resolve then I would say they need to come out also.

Perhaps comment out the current just in case someone wants to add them back in at some point but I believe the default should be just e164.org. It's been difficult to qualify this properly so I can only give my experience as I see it.

Ta. C.

OK, try this: r5826

and let me know if that does it before I publish.

Replying to p_lindheimer:

OK, try this: r5826 and let me know if that does it before I publish.

Yep. Thanks.