Skip to Content.
Sympa Menu

isn-discuss - Re: [isn-discuss] ISN dialing, numeric alternative to * key ?

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

List archive

Re: [isn-discuss] ISN dialing, numeric alternative to * key ?

Chronological Thread 
  • From: John Todd <>
  • To:
  • Subject: Re: [isn-discuss] ISN dialing, numeric alternative to * key ?
  • Date: Wed, 29 Mar 2006 20:21:25 -0800

At 12:42 AM +0100 3/30/06, Jonathan Cohen wrote:


Hope this is a good place to post this and apologies if this a really silly question. I've got ISN dialling working fine to our Asterisk gateway and inbound/outbound calling works fine, however there's a bit of a problem....

One of our aims is to provide telephone access to areas such as Africa where a conventional fixed network is not available or is very expensive/poor quality. Internet connectivity can be rigged using WiFi etc and VoIP is a natural progression. We take existing old PBXs, telephones etc and link them together using low cost gateways or ATAs. The problem is that much of the end user equipment is only capable of pulse dialling and therefore can't dial the * symbol in the dialplans.

For the moment I've created a dialplan that assumes the last three digits of a number are the ITAD but obviously once ITADs are longer than three digits this won't scale. For example users would dial:

000 2002233 329 (or possibly 000 329 2002233 in a more conventional format)

What I can't find anywhere is a recommendation on how this should be handled, since the variable number length and potentially variable ITAD make dialling separation almost impossible.

Jonathan Cohen


Jonathan -
This actually had been discussed in the past. Ed Guy had suggested using a run-length encoding model for the numbering scheme, by having the number of ITAD digits represented as the first digit of the string, and inverting the ITAD/subscriber order. However, I argued that the ISN numbering scheme is going to be enough of a trial to get people to remember, and anything that requires thought or examination of the numbering pattern in order to dial will present insurmountable psychological barriers to adoption. Think of explaining this to someone who has not technologically literate, and you'll quickly realize that just a "*" key in the middle of the sequence is enough of a challenge. Change is difficult, and every additional element that needs to be memorized by a user will create an exponential resistance value which works against adoption (IMHO.)

At the same time, the "*" is probably necessary as a component of the digit sequence in order to prevent confusion and overlay with existing E.164 numbering. The run-length encoding method would quickly lead to written numbers that were indistinguishable from normal E.164 numbers, which is quite the opposite of what is hoped as the goal, which is to have a numeric stand-in for "email-style" addresses. ( roughly equivalent to user*ITAD)

With those factors, rotary phones were consciously considered and after quite a bit of painful thought were recognized as incompatible with the ISN system. While I believe that it is a mistake to exclude endpoints for technologically arbitrary reasons, I also think that it would be more of a mistake to create a numbering system that is confusing and will be less adopted which the other 95% of the world's population can use with a lower barrier of adoption.

As a last note: even in Africa, the use of pulse phones is rapidly dwindling, though of course at a much slower pace than had been experienced in more affluent portions of the world as far as the landline base is concerned. The flood of surplus equipment coming out of Western nations is causing quite a bit of updating, and there are even complete skips of digital phone systems directly to IP-based transport as cell phones become more dispersed.

As an even MORE last note: there is nothing to say that your local dialing plan cannot make a workable solution. I think you refer to this in your example, but let me give a more complete reference. While the ISN format I believe should be standardized in presentation AND dialing, there is no law that says you have to follow the standard. You could create a local dialplan that makes users re-format the number in a rotary-friendly way. Take these examples as my suggestions for a last-resort measure with a forward-adjusted run-length encoding of ISN digit length using zeros as length hints (since ISN subscribers nor ITADs can start with "0"):

ISN: 1234*256 turns into 000 1234 356
ISN: 2002233*329 turns into 000 2002233 329
ISN: 322*2593 turns into 0000 322 2593
ISN: 9934*10334 turns into 00000 9934 10334


Archive powered by MHonArc 2.6.16.

Top of Page