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

[John Todd <>]

At 12:42 AM +0100 3/30/06, Jonathan Cohen wrote:
> Hi,
>
> 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:
>
> 2002233*329
> as
> 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.
>
> Rgds
> Jonathan Cohen
>
>
> 2002233*329


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

JT