Just out of interest: From former posts I understood that there is a
CALLERID service in US (for an extra fee, I assume) that gives both
number _and_ name of the caller...? I am aware of the fact that e.g.
EuroISDN lines can transmit alphanumeric callerid (and in fact I already
use that on an
BT == Brad Templeton [EMAIL PROTECTED] writes:
BT Hey, we could even build a system where DNS can be used to take
BT any phone number and look up data about it, not just a name, but
BT even a URI to redirect calls to for it, a source of presence info
BT and more.
BT What a great idea!
I may be
ML == Mike Lynchfield [EMAIL PROTECTED] writes:
ML With all other things said.. you might want a professional service
ML for this like targusinfo.com
ML Maintaining and running an operation like a cname web lookup thing
ML is REALLY high overhead in terms of web traffic etc
ML What happens
RL == Richard Lyman [EMAIL PROTECTED] writes:
RL TP'n to follow flow just like DNS, the 'root servers' would still
RL see the high request hits, prior to passing off to local caching
RL app.
The DNS root servers are almost only loaded by irrelevant traffic. The
root information is easily
Well caching is the way to go., bu then again most of the current solutions
have this problem.
John smit has a DID.. 514 555 1234 and closes account.. did sleeps for 3
months and new client Jane doe takes it..
Now how long should caching be ? this is a big problem ATM because some
cache for 1
ML == Mike Lynchfield [EMAIL PROTECTED] writes:
ML Well caching is the way to go., bu then again most of the current
ML solutions have this problem.
ML John smit has a DID.. 514 555 1234 and closes account.. did sleeps
ML for 3 months and new client Jane doe takes it..
ML Now how long should
Am Dienstag, den 20.02.2007, 14:54 -0500 schrieb Mike Lynchfield:
Well caching is the way to go., bu then again most of the current
solutions have this problem.
John smit has a DID.. 514 555 1234 and closes account.. did sleeps for
3 months and new client Jane doe takes it..
Now how long
RL == Richard Lyman [EMAIL PROTECTED] writes:
RL everytime you make a dns request, i agreed that it does not hit
RL the root servers, but every time you request a NON-cached one you
RL DO.
Nope. If you request foo.com and you have up to two days earlier
visited bar.com, you won't hit the root
Benny Amorsen wrote:
RL == Richard Lyman [EMAIL PROTECTED] writes:
RL everytime you make a dns request, i agreed that it does not hit
RL the root servers, but every time you request a NON-cached one you
RL DO.
Nope. If you request foo.com and you have up to two days earlier
So how does this start? I mean it wouldn't be hard to modify dns
server to use 3/3/4 format ip address... or it would need to be
3/3/3/4 for international right and someone wrote a module for
asterisk look up that way and then I took my SS7 connection and setup
a GTT gateway to a server so that
Quoting Natambu Obleton [EMAIL PROTECTED]:
So how does this start? I mean it wouldn't be hard to modify dns
server to use 3/3/4 format ip address... or it would need to be
3/3/3/4 for international right and someone wrote a module for
asterisk look up that way and then I took my SS7 connection
I would guess that registration would be by the telco for the blocks
just like with reverse dns today, so then each telco would have a
local server to manage their 'reverse' cnam lookup and the people
in charge would be NANPA, just like how ARIN is regulated today.
Although who owns the root
Am Dienstag, den 20.02.2007, 16:33 -0700 schrieb Natambu Obleton:
I would guess that registration would be by the telco for the blocks
just like with reverse dns today, so then each telco would have a
local server to manage their 'reverse' cnam lookup and the people
in charge would be
13 matches
Mail list logo
