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

[Rick van Rein <>]

Hello,

I am surprised by this discussion.

Any desire to have prefix codes for numbers to dial stems from the
old-fashioned model with smart switches and stupid phones.  I do not
think this distinction is a current-day practice, even when actually
using these dumb analog phones.  The two ways of embedding the ISN
syntax in a dialplan are:

1. Having a digital switch which somehow receives numbers from a truely
   analog phone (i.e, through some form of Analog Telephone Adapter),

2. Having a digital switch which receives numbers from a digital phone.
   (Like SIP, IAX2, ISDN?, mobile phones and DECT handsets.)

In case 1, the only mode of operation is usually to have the analog
phone dial one digit at a time.  At some point however, the entire
number has to be collected, because that is how backbones [1] now
operate.  Unlike in the old days, where each digit dialed directly
steered a 2D-dialer arm that would select the wire to connect through.

   [1]  I know that this excludes an approach where one dials out
        on a digital line through a modem.  I don't think this is
        a realistic approach to take into account when designing
        an ISN scheme: doing VoIP over an analog modem line.

If dialed numbers are processed one at a time, for example when
going through an analog PBX before ending on a digital gateway,
there is an obvious need for a use of prefix codes.  This is
needed because the switch cannot say "oh wait, an e164 syntax error
(namely a *) on position 5 makes it necessary for me to use an
alternate route".  Prefix codes are normal for users of analog
equipment, so we shall have to introduce another one to be able
to dial an ISN.  But IMHO it is a mistake to want to standardise
_which_ prefix.  This is a local issue, dedicated entirely to the
local PBX setup.  If you use predial codes, you will always dial
a _fixed_ number of keys before you can transparantly enter an
ISN.  This is perfectly LL(1) parseable, so there is no need for
any special arrangement.  And so it is no problem to accept 0*880
as a proper ISN.  And as for what 0* means -- the idea of an ISN
is to give people control over their telephony domain, at best
with some suggestions or "best common practices".

Case 2 can simulate dial-per-digit, in the case of SIP using the 484
response code to indicate an incomplete number.  The user will not
like this, as it means that falsely entered digits cannot be corrected.
Also, the 484 approach is not needed in practice, and AFAIK it is not
common practice either.  Digital telecom providers (dialing out to the
e164 backbone) generally want a whole number at once, so they are
basically assuming some form of cleverness at their clients.  And that
makes sense -- given that we use digital protocols, why not expect a
bit of local computational power, or less dumb terminal equipment.

So, given the practice that a whole number to dial is being collected at
some point, and that it is neither useful nor ever needed [1] to continue
to pass it on as individual digits, why not demand that it is collected
at the stage where we already have the computational power to perform the
DNS NAPTR lookups needed to resolve ISN addresses?


To summerise, IMHO:

1. Only analog PBXs introduce the _need_ for predial codes;

2. Other PBXs have computational power, and can collect the whole number
   to see if a * is present (which implies it is not an e164 number);

3. Collecting a whole number never really [1] cause inefficiencies;

4. Prefixes in an older PBX are bound to be determined by the local
   dialplan as well as the equipment's flexibility, so they cannot be
   standardised;

5. Prefixes in an older PBX are always fixed-length and users do not
   experience them as part of the numbers to dial;

6. Consequently, there is no need from a dialing perspective to constrain
   the use of certain initial digits such as 0.


A sidenote to 6 is that there may be other reasons to restrict what is
possible.  Notably, a canonical form of a number could be required so
as to avoid distinction between number 5 and 0005.  On the other hand,
much may be said for multiple prefixed zeroes, as this could help to
fix a local dialplan to a given number of digits.  From this it sounds
to me like the canonical number format is part of a local dialplan,
and that we should treat the local part of an ISN as a text string
that happens to be composed of digits (and, perhaps, the other DTMF
symbols * # A B C D).


As for any issues of order between domain and local number: It's mainly
a matter of taste, isn't it?  So any choice would be a pragmatic one.
I've seen sipbroker.com do it the other way: *, domainnr, localnr.  Their
problem is that they are running out of domain numbers and have to supply
ever-longer ones.  At least the infix * of an ISN makes parsing it very
straightforward.  Even if it makes the job a little bit harder on the
PBX.  But come on, if you can do NAPTR lookups, you can also collect a
whole number to check its syntax against e164 and/or detect a * in it!


I hope this helps.  I know I'm a newcomer on this forum but still wanted
to express my surprise for some of the issues that this thread is
exposing.


Cheers,

Rick van Rein
OpenFortress

TBD*880