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: Thu, 30 Mar 2006 11:26:10 -0800

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

I agree, however the problem is with variable length ITAD and user numbers, without the (*) separator there's no easy way to break the two apart. Shouldn't this be the kind of thing the trial resolves?

I think it should be something that is discussed in the trial, certainly. I think that the plan is far from complete, and suggestions that fulfill the criteria would be very welcome since there are notably lacking any complete solutions for these problems other than the format that has thus far been suggested:

1) dial-able from common 12-digit keypads
2) visibly different than any form or format of E.164 numbering
3) full sequence easily memorable by users
4) easily distinguishable organization vs. subscriber elements (user memorization)
5) maps via the DNS to a NAPTR record
6) subscribers able to be mapped at an organizational level via the DNS
7) subscriber identification digits using no fixed-length dialplan (within reason)
8) IANA or other (mostly) impartial and widely-recognized numbering authority that is outside of the scope of the trial to control
9) free or virtually free numbering and resource allocation
10) open to any participant

By removing the "*" from the number sequence and changing the requirements of #1 above to read "dial-able from any 0-9 digit keypad", you have put #1 and #2 directly in conflict with each other, since it will be very difficult to distinguish between E.164 and ISN formats.

My ISN, for example, is 2203*256. If we remove the *, then 2203256 could be read as 220-3256 by a person looking at the digits, which is an E.164 subset, not to mention the difficulty of run-length encoding of the ISN which isn't even in that sequence.

With those factors, rotary phones were consciously considered and after quite a bit of painful thought were recognized as incompatible

We're not talking dial phones here. Even less that 10 years ago here in the UK we had BT exchanges that only accepted LD (loop disconnect) signalling. We're talking about (sometimes less than 10 years old) push button telephones and systems that only use LD signalling (no * or # keys). They're still regularly found here in the UK (though many can be easily switched to DTMF) and are very common across Africa and Asia. I can't find any statistics but I know from experience that in many parts of Africa LD only phones must be greater than 50% of the installed base (often being second-hand phones from the UK). In fact our biggest challenge has been adding old PABX CCUs between systems to convert from LD to DTMF to link in to a VoIP ATA etc.

confusing and will be less adopted which the other 95% of the world's population can use with a lower barrier of adoption.

The trouble is that we're excluding people based on their technical and financial status. Lets face it, here in the western world we don't really need VoIP to reduce the cost for voice calls, as (mobiles excluded) once you have a PSTN connection (usually needed for internet access anyway) you can call pretty much anywhere in Europe/America/Australia for 1p (< US$ 0.02) per min. I see the technology as an enabler. We can add new services such as video etc where these would have been cost prohibitive before and in the developing world provide low cost service where previously the only method of communication was expensive and unreliable mobile or satellite phones.

I've spent my life trying to create communications systems that are simple, reliable and low cost so I really understand what you're saying. However, surely the whole point of the ISN trial is that it's a stepping technology from what we have now to what we would like in the future? Not a means to exclude the poor or force a technology upgrade? ;-)

It is indeed a step. However, a step implies rising up a small amount and leaving behind the previous step. ISN is hopefully a step between DTMF and SIP URIs, but it may not be enough of a step to say that it is "between rotary phones and SIP URIs." So I am not sure it should say the latter. It certainly does force a technology upgrade: the ISN concept is to map to SIP URIs, which implies Internet connectivity at some point in the dialing path. The position in the dialing path that this conversion takes place is dependent on the conditions and capabilities of the local environment.

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.

See above, LD signalling is still common. You're right about the flood of surplus equipment, we're using such systems ourselves, however the life of a phone system or PBX can be long (typically 10-20 years) and even if replacement equipment is free, finding people with the experience to install it (or even re-program old systems to use DTMF if possible) can be very difficult and expensive in many locations. It's much easier (at least initially) to provide a gateway that converts the existing LD signalling to MF and feed that to an ATA.

Much of the African population (if they have phone access at all) currently only have access to mobile phones and these (even in capital cities) can be very unreliable and expensive (I spent a couple of days last month trying to get hold of my wife on her mobile in Harare - it had coverage the whole time but the trunk network was down so she could only call some other Zimbabwe mobile numbers). On a corporate and government side, yes they've actually skipped a generation of technology, but I'm talking about small businesses and home users. The people who have the least to spend and need the technology most.

So, I'm not entirely clear on the argument in the paragraph above. If "much of the African population...only have access to mobile phones" then this is not incompatible with ISN. If the small business users have as a goal the use of ISN, it would imply Internet access at some point in their infrastructure at a speed that would allow RTP communications. Is it reasonable to expect ISN dialing will be implemented in locations that are primarily rotary phones? Is there not a basic technology gap that must be crossed for even VoIP to work correctly that implies an upgrade at the infrastructure level (i.e.: Internet connectivity)?

Even if the answers above are "Yes", I'm still interested in hearing how a numbering scheme can be obtained that satisfies the other requirements. I know that myself and the others in the project have chewed on this one for a while with no obvious outcome, so additional concepts are welcome.

While the ISN format I believe should be standardized in presentation AND dialling, there is no law that says you have to follow the standard. You could create a local dialplan that makes users

As you say above though, this creates confusion. Shouldn't there be a recommended standard way to dial from phones without a * key?

I'd be happy to hear what the method might be for those cases which could be integrated into the ID. I have not come up with any that are simple.

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

Sorry the 000 in my example was my test ISN access code. The recommendation is 012 but once you add in our breakout code of 000, 000012 gets a bit long. This is another area where outside the US there may need to be some discussion or standardisation?

For example in most countries (+ = 00) (or 011 in the US). The ISN suggestion is to use 012 for ISN numbers but there's no direct equivalent of this outside the US. Typically non-US VoIP providers have been using 000 to signal a VoIP call as country code 0 is unused (ie 000 694 200 2233 would be my desk phone on the KCIP platform from most VoIP providers that use the Sipbroker codes).

OK, that's interesting. The "012" was suggested for US dialing, but "000" is just as workable outside the US. These are "suggestions" and a local administrator may choose whatever they want for ISN prefixes. I'm uncomfortable with "standards" for this, as even now each administrator chooses things on their own (I've seen dial "8" or "9" or "0" for a local trunk, and "011<E.164>", "9011<E.164?", "90011<E.164>", and "8<E.164>" and "<E.164>" for international calls on various PBXes, just in the last 4 months!)

The suggested prefix for ISN dialing for non-US destinations would be very much welcome - do you have other examples of this in practice?

I still don't see how I can tell where the users number ends and the ITAD starts, or vice-versa. Different systems will have different number lengths and it will be impossible even with just a few hundred ITADs to know the dial plan of every other system unless we register and lookup every extension in a central database - and that certainly won't work in remote areas?


That is the crux of the problem. The "*" is integral in the dialing sequence as a separator between subscriber and ITAD, both to allow the user AND the dialing system distinguish between the two. Without that symbol, the plan becomes complex. The user must be the one to somehow identify to the dialing system the difference between ITAD and subscriber. A database is insufficient, even if the overwhelmingly complex distribution problem could be overcome for at least two reasons which I won't go into detail on here (overlapping dialplans, overlapping ITAD/dialplan sequences.)

[additional message included here to create a single thread]
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

I see what you're saying here but this gives a very convoluted dialling system. I'm not even sure I'd be able to work out the correct number without a pen and paper. Also padding at the start, for a number at the end is counter-intuitive to any users with experience of the regular PSTN. Once ITADs get longer this gets unwieldy, effectively adding an extra 0 for every extra ITAD digit:

123 * 329 = 000 123 329
123 * 56789 = 000 00 123 56789
5551212 * 234567 = 000 000 5551212 234567
5551212 * 2345678 = 000 0000 5551212 2345678
5551212 * 23456789 = 000 00000 5551212 23456789
.. etc

You could pad the ITADs at the start, which is slightly more intuitive for users, but then what happens once, for example, ITADs exceed the number of padding digits? Also this may add more confusion as we'd still have to advise users to add initial 0's to the ITAD to bring it to the required length:

329 = 00329
2345 = 02345
45677 = 45678
567890 = Ah, we need more 0's! We have to advise all our users to change their dialling!

Renumber..... 329 = 0000329 etc....

Or do we just start at

329 = 000 00000329 ;-)


Fixed-length dialing is problematic, as you've discovered. There is no easy solution there, but more discussion is required...


Archive powered by MHonArc 2.6.16.

Top of Page