Skip to Content.
Sympa Menu

isn-discuss - Re: [isn-discuss] Re: Interesting uses for isn

Subject: Discussion List for Freenum/ITAD Subscriber Number (ISN) Project

List archive

Re: [isn-discuss] Re: Interesting uses for isn

Chronological Thread 
  • From: John Todd <>
  • To:
  • Subject: Re: [isn-discuss] Re: Interesting uses for isn
  • Date: Thu, 29 Nov 2007 17:36:55 -0800

Ben -
I like this idea, but I have three areas of concern:

1) It is complex enough to not be well-understood by most administrators in this space. It's difficult enough to get many sites to understand how the subscriber portion maps to an extension on their pre-existing platform, much less creating a requirement to have a totally new program requirement set that forces them to create aliases for each username and then maps that somewhere else. This more-or-less forces an administrator to create an alias table, which I can say from direct experience will not happen in >98% of the sites that ever get connected.

2) If standardized, it would quickly lead to number space conflict between a 'standard' method and the local method. Let's say for "" that the SHA-derived extension (which is obtainable externally) would be "12345". Then let's say I had a local extension here on my PBX that was 12345. Which "wins"?

3) The first X digits of an SHA are not guaranteed to be unique, so that would lead to possible conflict.

I do, however, really like the TXT record for a domain which points to the ITAD for that domain - that's a great idea. Once you have the ITAD that is associated with a domain, then you can look up the "searchdirectory" URL which then allows the user portion of the email address to be looked up and the correct subscriber number returned.

I would probably use something other than a new zone trick to identify this data. How about coming up with some record that is tied to the domain in question, using DNS-SD?


At 3:46 PM -0800 2007/11/29, Ben Teitelbaum wrote:
ISN, as originally conceived, was to be an interim solution on the road to a glorious future of fully alphanumeric SIP URIs (where "interim" might be a decade or two).

Here's a nutty idea: make it possible to derive an ISN from a known email address.

How would this work?

1) Add a number format TXT record (as suggested below) for each ITAD;

2) Agree on a hash-based numbering convention (e.g. user "bob" would have a local number that's the first 5 digits of the base-10 SHA1 of "bob");

3) Add an ITAD TXT record for each domain.

Given an email address (e.g. "<mailto:>"), an ISN for Bob could be derived like this (Perl-esque pseudo code follows):

1) $itad = `dig +short TXT <>`;

2) $prefix = `dig +short TXT <> o.$`;

3) $isn = substr(hex2decimal(sha1("bob")), 0, $prefix) . '*' . $itad;

It would then be possible to write a number of email->ISN resolvers--on web pages, integrated in devices, etc.

What do folks think? Does this make sense? Would it be useful? Anyone interested in trying it out?

-- ben

On 11/29/07, John Todd <

I agree with Peter that a "white pages" is needed. There is actually
someone working on this right now, with an AJAX directory structure
that will take partial or fully qualified substrings and present a
reasonable directory reply. Hopefully we'll be able to make this
into a small widget that can be embedded easily into other pages.

At 4:01 PM -0500 2007/11/29, John R Covert wrote:

Well, of course it was intended for inter- not just intra-company
communications, including international.

And I agree that making it useful has been a bit of a problem.
We have people whose gateways not yet fully installed or are very
experimental and thus not very reliable. We also have the problem
that it's not clear what format to dial for the extension -- do you
dial 3, 4, 5 digits for an extension, or the full local or national
or even international number? No standards exist, and maybe they
shouldn't be required.

The intention was that extensions were completely open to the local
administrator for (almost) as many or as few (=>1) digits as they
wished. This is because currently there are no standards within PBX
systems as far as digit length dialing, and it seems unnecessary to
enforce some type of localized digit length. If your current phone
system uses 5 digit dialing, then instead of coming up with a new
plan, why not just use that 5 digit dialing pattern? If you don't
use internal extensions but instead use fully-qualified E.164
numbers, then feel free to use that as well though of course that is
a bit unwieldy.

>I'd propose two things:
>1. a standard TXT entry in each ITAD's <> entry which
> points to a web directory of some sort giving information.

Already there, almost. :-)

This isn't widely publicized yet, but there are meta-data in the DNS
records already for each ITAD. For instance, this is the meta-data
for my ITAD (256):

o IN TXT "Hyjynx Technology Systems, Inc."
street IN TXT "14625 Baltimore Avenue, PMB 170"
localityName IN TXT "Laurel"
stateOrProvince IN TXT "MD"
postalCode IN TXT "20707"
friendlyCountryName IN TXT "United States"
tz IN TXT "UTC-0800"
friendlyTimezone IN TXT "US/Pacific"
lang IN TXT "en"
friendlyLanguage IN TXT "English"
email IN TXT


So you get this on a dig:

[root@public asterisk]# dig +short TXT <>
"Hyjynx Technology Systems, Inc."

We currently have a field that can be edited by the administrator of
each ITAD called "Directory URL", and we also have a larger free-form
field called "Number format". Both of these could easily be
integrated in the same way as TXT records. Please take a look at
your ITAD settings page on the <> site for these fields.

Any suggestions as to what the identifier should be called? I
suspect it will be difficult, if not impossible, to make a machine
readable version of "Number format" since REGEXPs are overkill and
frankly nobody will update them, given my experience with everything
else in the database.

2. the standard that the "0" extension always gets you to some
sort of informational message about what to dial, or to an
IVR of some sort, or to a human attendant.

A "Best Common Practices" set of extensions is indeed something that
has been mentioned in the past. Much like "postmaster", "webmaster",
etc. have from RFC2142 (<>
However, it is highly advised to avoid region-specific assumptions.
RFC2142 is biased towards English, which is a significant downside to
that RFC, IMO. We have the luxury of being numeric-only, but I'd
hate to specify a set of numeric defaults that are region-biased.
For instance, "411" is not the number for directory assistance in
many nations.

What is the set of desirable extensions to have as suggested (but not
mandatory) destinations? I agree that "0" is an obvious
directory/receptionist/IVR destination. What others?


#2 is already the case at my ITAD, at MIT's, at NPR's, at Octothorp,
and probably at many others.

But of course, there's no way to enforce any such thing.


-- ben

Archive powered by MHonArc 2.6.16.

Top of Page