ISN*

Frequently Asked Questions

Basic Questions

What is ISN?
ISN (ITAD Subscriber Number) is a method for inter-domain numeric SIP addressing. It allows users of next-generation communications clients to be called from devices having nothing more than a 12-button keypad for entry.
What do ISN numbers look like?

An ISN is formed by joining a domain-local subscriber number to an ITAD (Internet Telephony Administrative Domain) number, using an asterisk as the delimiter.

For example, subscriber 1234 in ITAD 256 would have ISN: 1234*256.

Aren't these numbers going to be difficult to remember?
An ISN need not be any more difficult to remember than an e.164 number, and has the advantage that the suffix is consistent across all members of an organization.
Why numbers? Aren't email-style addresses the way of the future?
ISN is meant to complement efforts like SIP.edu that are promoting the use of the email address as a one-stop communications handle. While alphanumeric SIP URIs like bob@bigu.edu offer many advantages, they are difficult (and in some cases impossible) to enter from many legacy telephones, including POTS, VoIP, and cellular phones. ISN is an interim solution, albeit for an "interim" period that may last decades.
Who is participating in the ISN trial and why should I bother?

ISN is an outgrowth of the Internet2 SIP.edu Working Group and is still in an experimental trial phase. Several large public and private universities, including MIT and UCLA, were among the first domains to implement ISN. Other domains, including service providers, commercial enterprises, and governmental entities, are coming on-line quickly. The VoIP service provider Free World Dialup has supports ISN and it is expected that other Internet Telephony Service Providers will be joining, as the barrier to entry is very low and implementing ISN obviates the need for a confusing set of escape codes to call between VoIP service providers.

Following Metcalfe's Law, the usefulness of the system will increase as a function of the square of the number of users who are reachable and using the system.

How do I get started?
The ISN Cookbook provides a step-by-step tutorial on ISN and includes recipes for both SER and Asterisk.
Who controls the "root" zone?
The root zone file is jointly maintained by John Todd, MIT, and Internet2. The root nameservers for the ISN trial are operated by Packet Clearing House
What does it cost?
ITAD numbers are allocated for free by IANA and participation in the ISN trial is also free. Each ITAD is, of course, responsible for operating its own SIP proxies and communications endpoints.
Can you recommend an inexpensive VoIP-capable platform?

If your existing PBX has the ability to take as inputs a PRI, FXO, or FXS line(s), then it is possible through inexpensive hardware and free software to create a gateway to existing TDM infrastructures for both outgoing and incoming calls. If you have an old Pentium II 400mhz or better system as a spare, it may cost as little as $20 to create a gateway platform with Asterisk that integrates a single FXO trunk into your existing PBX. PRI-capable systems can use the same (or slightly better) CPU hardware, and single-PRI cards are in the $500 range.

A set of instructions for creating a standalone TDM-to-SIP Asterisk platform are included in the ISN Cookbook.

Are ISN numbers portable?

No. ISN numbers cannot be ported across organizations because, by definition, an ISN includes an ITAD number, which is an organizational identifier. It is impossible to "transfer" an ISN number, just as it is impossible to transfer an email address between organizations.

However, it is certainly possible for forwarding to occur. Since there is an essentially "unlimited" number of subscriber identifiers, it is possible to have forwarding left in place for much longer than typically occurs when carriers temporarily forward or announce a cancelled e.164 number (forever?). This forwarding can be done with the ENUM pointers, or on the SIP proxy - that is up to the local administrator. Any organization that has explicit mappings between e.164 numbers (or suffixes of e.164 numbers) and subscriber numbers will have no more or less complexity than if ISNs were not implemented, as the portability or forwarding issue is blocked by the shortcomings of e.164.

How will ISNs be dialed?

An ISN probably will be dialed in the following manner:

<local trunk code><subscriber number>*<ITAD number>

A typical trunk code would be "012", much like an international call is "011". This prefix would be the same for all ISN numbers, and after a user dials such a trunk code (estimated) 10 times, this prefix would become second nature, just as dialing a "9" in North America is automatically assumed for many PBX systems to indicate that the call will be routed to a local PSTN trunk, or "011" for an international call. The second part of the number is the part that would have to be memorized, and is the "hard" part. This subscriber number could be one or more digits, but it is probable that most subscriber numbers will be four or five digits for most organizations. Most organizations would probably opt to keep their existing mappings in place, which would make an exactly equal overlay of the number of digits to remember. An example: Company A has no DIDs, and has ISN 13013 Penny has as her normal number: 1-503-555-2000 x223 Penny's ISN would be: 223*13013 Penny's ISN is 6 digits shorter than the full e.164 plus extension, and 2 digits shorter than the shortened e.164 address (drop the leading "1").

Company B has DIDs, and five digit extensions overlaying their e.164 numbers. They have ISN 7337

  • Emilio has as his normal number: 1-503-555-5432
  • Emilio's ISN would be: 55432*7337

The ISN is 2 digits shorter than the full e.164 address, and 1 digit shorter than the shortened e.164 address (drop the "1")

The length of the ITAD is a steadily (but slowly) incrementing number of digits. Slightly less than one million organizations could register before the number sequence would be above six digits. If subscriber mappings were made judiciously, four or three digits would probably serve many organizations if no e.164 overlap was desired. This means that there will be a significant period of time where the total number of digits is shorter than a North American e.164 number.

Even in the worst possible cases of subscriber and ITAD length, it is probable that the organization (ITAD) number portion of the ISN would become more "second nature" and therefore be reduced as a memorization problem. Most dialing patterns show that there are focused clusters of calls between organizations, and individuals within an organization tend to communicate with a small subset of other organizations for the bulk of calling behavior.

ITADs

How can I get an ITAD with fewer digits?

ITADs are assigned by IANA on a FCFS (First Come, First Serve) basis. This means that, begining with ITAD 256, IANA always assigns the sequentially next available number. There is no way to request a shorter number or to request a custom or vanity number.

Won't ITADs get really long as more organizations sign up?

The maximum number of ITADs is 4294967296 (2^32). It is expected that before the number of ITADs reaches one million (7 digits) that some type of registration fee system or prerequisite criteria may be in place which limits the number of possible applicants via reasonable methods of market force. The actual method for this limitation is unknown, and is worthy of extensive and careful consideration by members of the community. However, it is desirable that ITAD numbers by themselves are not used as identifiers for single individuals who otherwise would be associated with a group of similar telephony users as a function of their work or institutional association. Due to the complexity of operating a telephony platform, it is not expected that the number of ITADs would rise to anything approaching even .1% of the world's population (8 digits in the ITAD at .09% population:ITADs, assuming growth to 10B population in coming decades.) There are most likely ~100m domain names currently (rough guess) which is a function of the fact that domain names are mnemonic and meaningful in and of themselves. They may reflect a trademark, promote a product, be a placename, or have any other linguistic meaning (or even a full sentence!) ITADs on the other hand have no such allure - they are inert by themselves, and without meaning. There is no reason for individuals or companies to register more than one ITAD, as the chances of getting an ITAD with some sequence of digits that is more memorable is slim and hopefully will be more difficult as time progresses and some minimal requirements prevent trivial duplication of registration. There is no expectation of an ITAD shortage or a "run" on ITADs in the near future, though it will be desirable to limit the allocation of ITADs to aggregators of SIP subscribers to prevent premature resource expansion/dilution. Additionally, the ITAD allocation policy of incrementing digits and more-or-less random allocation (within a guessable range) makes them even less likely to be the targets of speculative registration. All of these pressures or factors contribute to a lower number of ITADs and therefore a manageable number of digits in the ITAD portion of an ISN dialing string. Realistically, it may be 5 years before the number of digits in an ITAD grows to even six digits even in optimistic adoption assumptions, based on anecdotal observations in ASN and IP address allocation growth over time. There is no driving incentive for individual end users to have an ITAD allocation, and it is anticipated that most endpoints will be members of an aggregation community much like is seen currently with email today. Unlike email which uses domain names, with ITADs there is no information that is inherently transmitted with the ITAD number itself, so vanity allocations are implicitly impossible or extremely inconvenient, thus limiting the reasons for allocations by non-aggregators.

I want an easy-to remember ITAD. How do I get one?

This is not currently possible as a request, as ITADs are assigned incrementally by IANA and digit sequences cannot be requested. It is also strongly recommended that there is no mnemonic used even if your number somehow translates into a certain alpha character sequence, as this will be confusing during any crossover period with SIP URIs for end users.

Won't people speculate on ITADs and sell them?

Transitioning an ITAD to a different organization is non-trivial, and is expected to have in the future the same regulations applying to ITAD allocation as currently apply to ASN or IP allocations.

Implementing an ISN Domain

What is a good subscriber number scheme?

Using the existing extensions that exist at the entity is a good idea - why re-invent the wheel? In circumstances where DID numbers are overlaid directly on extensions (i.e.: 1-503-555-6104 is ext. 6104) then there may be concerns about future forwarding or relay, as each extension maps to an e.164 number which is "valuable" (or has cost) and which may not be desirable to map elsewhere.

If starting from scratch, a four-digit numbering scheme of the style "2XXX" (where XXX is a number incrementing from 000) may be suitable.

If you have a new or transitioning PBX system with no existing e.164 numbers, it may be a good idea to stay away from e.164 numbers for your subscriber identifiers. Each number has an associated cost (though minor) but more importantly has a temporal value. For example, if you assign e.164 numbers to students then each year there are a considerable block of numbers which are vacated or re-occupied. This means that some calls will be misdirected, and a close watch must be made of all number inventory. However, if virtual numbers are used it may be possible to simply allocate a pseudo-random number to a student and that is "their" extension forever, regardless of it's active/inactive nature or location. Inventory and correlation to telephony network elements is eliminated and becomes an internal issue only, not an internal/external audit event.

So, what about this "trunk code" issue?

Your organization may want to specify that a trunk code is dialed in front of ISN numbers, in order to allow your PBX or iPBX to identify the numbers following the trunk code as an ISN sequence. While the local dialplan may be "smart" enough to identify numbers that contain a "*" as being ISN numbers, it will not prevent problems with auto-dialing sequences such as "911" when a remote subscriber has those digits as the first digits of their subscriber number. By specifying a trunk code, it may also be easier for non-IP capable systems to forward calls to a T1 or other trunk which hands calls off to an inexpensive IP-capable device, thus allowing easier migration and integration in environments which may not support native SIP trunking.

Advanced Questions

My organization isn't very centrally-controlled. Doesn't this imply that all traffic to my ITAD has to be centrally managed?

No. The only thing that has to be centrally managed are the subscriber numbers, so that there is no numberspace collision. This is in almost (but not quite) the same fashion as email address namespace management in most organizations. The fact that a typical entity has a single ITAD means that there are no sub-zones like with DNS. The "." character in DNS allows additional sub-domains to be created, each of which may have it's own namespace which may overlap with other sub-domains. This is NOT the case with ITADs, as the organizational identifier is flat - it is a single number.

While this is certainly an issue for some organizations, it is probable that this will not be a serious issue for the following reasons:

  1. By using the DNS for ENUM-like URI resolution, it is possible to map any subscriber number to any ENUM record, and thus to any SIP server within the organization. CNAMEs or zone transfers may also be used to further push administration out to DNS servers controlled by administrators of local SIP servers in order to coordinate local subscriber mappings in a hierarchical manner.
  2. It is possible for an entity to have multiple ITADS if they are so different has to have completely different policies. It may be the case in the future that ITAD subscriptions are limited to one ITAD per incorporated (or taxable) entity, but those policy decisions are unclear at this point.
  3. Subscriber numbers can be as long as the administrator requires in order to make them unique enough that they can be delegated to local administrators if that is the overriding goal.

I don't know how to use ENUM and don't have time to mess with it on my own servers. Is there an easier way?

Yes, as long as your SIP server architecture is simple and you have few flexibility requirements. Currently, the experimental zone file is "freenum.org". For each ITAD allocated by IANA, there is an associated zone name which consists of the number (i.e.: 255.freenum.org) Typically, each ITAD/zone is then delegated to the nameservers of the ITAD owner so that the subscriber number portion of the ISN can have NAPTRs allocated by the administrator of the ITAD. If your site has a single SIP server that receives all external SIP queries and processes them internally, the it may be possible to request that a single wildcard NAPTR be installed in the top-level domain nameservers instead of an NS delegation. Something like this could point ALL requests for ENUM to your SIP server. This is an example for ITAD 255, with the SIP proxy for the entity being "sip.bigu.edu":

*.255.freenum.org. 10M IN NAPTR 100 10 "u" "E2U+SIP" "!^\\+*([^\\*]*)!sip:\\1@sip.bigu.edu!" .

You can ask for this "simple" configuration option to be installed in the nameservers for the root ISN zone if you don't wish to experiment with controlling ENUM yourself or you don't have nameservers at your disposal. Of course, a more complex ENUM entry can be made as well with multiple servers and URI types, but the more complex you make it the more likely it should be that you run the zone yourself on your own nameservers.

What NAPTR records should I put in place if I manage the subscribers myself?

Experiments have shown that some systems will insist on putting a "+" in front of numbers regardless of the nature of the number. Additionally, you probably want to strip off the ITAD from the ISN when re-writing the full number if it had not been done inside the originator's dialplan already (hard to determine if this will be the case or not.) The following NAPTR format will perform that type of number stripping and re-writing:

"!^\\+*([^\\*]*)!sip:\\1@sip.bigu.edu!"

This formatting would convert as follows:

From To
1234*255 1234@sip.bigu.edu
+1234*255 1234@sip.bigu.edu
+1234 1234@sip.bigu.edu
1234 1234@sip.bigu.edu

If you have experiences with this regular expression working or not working, please let us know. Additional regexp's are also appreciated as the community gets experience with creating more complete dialing rules.

Will this interfere with my use of ENUM?

ISN dialing does not collide with or prevent the use of "true" ENUM dialing.

My SIP proxies and gateways are not scriptable, and therefore cannot perform local number re-write and look up ISNs in converted DNS format. What now?

There are two ways to solve this problem: first, to use the public access Tello ENUM-to-ISN resolver/converter. Second, to use a public access Tello SIP redirector.

If your devices can support ENUM, then there is the capability of using normal ENUM to send ISN queries for re-writes by a specialized DNS resolver. Tello runs two public DNS resolvers which convert "normal" ENUM queries into ISN lookups. These resolvers pass through all other query types normally, but will intercept NAPTR records ending with the domain "e164.arpa" and will look for an ISN-style request containing an "*" character in the string. The resolver will then re-write the reply in an ISN format, perform a query, and hand back the result of that ISN query re-written to the expected format of the original request. Please see the "Tello Resolver Hints" section for details on having your IP address ranges added to Tello's public resolver/converter.

Isn't opening my SIP gateway to the public Internet a security risk?

Any exposure to the public Internet is a security risk, and must be balanced against the potential benefit and methods used to protect the organization's IT assets. The security issues surrounding SIP integration with an existing PBX are beyond the scope of this document.

I run SER - can I make or receive ISN calls?

Yes! There are modules for extending SER's ability to convert numbers from numeric to SIP URI formats. See the ISN Cookbook for details.

I run Asterisk - can I make or receive ISN calls?

Yes! There are built-in tools inside of Asterisk which convert ISN numbers into SIP URIs. See the ${ENUMLOOKUP} function call for details, which is also described in the ISN Cookbook

What does caller ID look like on these calls?

Caller ID for inbound calls on a recipient's phone should appear as "John Whorfin <whorfin@yoyodyne.com>". The outbound Caller ID (or "From:" header) should contain the SIP URI of the originating device. As ISNs are currently just a map to SIP URIs, it makes the most sense to have the return addresses be the SIP URI of the call originator. In this way, hopefully it will be the case that "full" SIP URIs become more widely used or at least recognized.

How can I tell which organizations have been assigned ITADs?

IANA keeps a list here:

http://www.iana.org/assignments/trip-parameters

There are also records stored within the DNS with (almost) the same information. TXT records are kept in a parallel zone called "info.freenum.org" and can be access by ITAD number. Currently, the records have quasi-X.500 format for company name and country associations. Other data may be added in the future. As an example:

root# dig @ns-iad.loligo.com TXT 259.info.freenum.org.
[snip]
;; ANSWER SECTION:
259.info.freenum.org. 60 IN TXT "o=Tello Corporation"
259.info.freenum.org. 60 IN TXT "c=US"
[snip]
[1]There are actually 4 more symbols on every DTMF-capable phone, which are hidden and unused in civilian phone systems. These keys are called "A,B,C and D" and create a "4th column" of dual-frequency tones on the keypad. They are outside the scope of this discussion, as these keys are only used regularly in military phone networks and almost never appear on standard phone sets.
[2]E.164 was defined by the ITU. http://comm.disa.mil/itu/r_e0.html or http://www.itu.int/search/index.asp?SearchString=e.164&SearchAction=Search&Action=Search&pagelanguage=en