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

[John Todd <>]

> > 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?
>
> Rgds
> Jonathan

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 ;-)
>
>
> Rgds
> Jonathan

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

JT