Subject: New phone system proposal

From: "Raides J." <[email-masked]>
Date: Wed, 07 Oct 1998 17:50:43 +0100

This is an informal proposal susceptible to be turned into a draft. If
I don't do this by myself is because I have not the time, not the money
to start a drafting proccess which involves assisting to IETF meetings
in the other side of the world (I'm in Spain), but I'll be glad to give
away this idea to a more capable individual and/or group providing they
credit me as the originator of everything (not the responsible one,
however).

	My proposal is settled to unify the world's phone system into one
common environment without having to rebuild the whole system from the
scratch. This system provides a method to interface with the legacy
phone system (the actual one) while allowing for more sophisticated ways
of implementing certain services such as private numbers, secret
combinations, and so on.

	FIRST CONSIDERATIONS.

	In first place, there is the legacy phone system. Now-a-days, if I want
to call my friend from my nearby city I have to use a provincial prefix
(something I had not to use some months ago) and then the number itself
(total: 9 digits). If I want to do the same from abroad, I have to dial
international access (from 2 to 4 digits), plus the country code (34 in
the case of Spain), plus a special form of the number (in some countries
I have to strip the first of the 9 digits, in Spain now you have not to
do so). This means that his phone number is anywere between 9 and 15
digits. If I call to Japan, I will need to dial, from Spain, 00
(international access) + 2 (Japan code) + 1 (Tokio area) + 10 digits
(local phone number). This means 14 digits. If I call from a 4 digits
international access code (such as Israel) this rises up to 16 digits...

	It doesn't matter if I've given the non-spanish examples right or not.
What is important is that there's a bunch of numbers to remember for the
same person, deppending on the originator's and on the destination's
physical location. And if someone have more than one phone number, the
mess is big enough to manage easily.

	THE PROPOSAL.

	My proposal is to assign numbers with 21 decimal digits (this gives
2^21 combinations, which in binary can be represented by 70 bits, raised
to 72 for rounding purposes). Every legacy number will be represented
with the following format:

	(padding ceros)+country code+area code+phone number

	The area code *shall* retain the number that's stripped out in the
system, so that it keeps coherent with its national and international
uses (in Spain you had to strip out the first 9 from any phone number
when calling from abroad, but now the 9 is mandatory -what I say is to
do the same to every country). The phone number of my friend will be
-fictionary number, of course- then:

	0000000000 + 34 + 123456789

	To facilitate the dialing of such a long number, an asterisk (*) could
be used to substitute the leading zeroes. This way, my friend's phone
number will be dialed as:

	* + 34 + 123456789 (of course, without the plus signs)

	Every new number assigned to the users of the new phone system (so it
can be implemented in a scalable way) *shall* begin with a non-zero
digit. The shortcut to avoid unnecessary zeroes will be accepted too.
This way, the first of the new numbers to be assigned will be:

	1 + * + 0 (a leading zero is mandatory to avoid confussion with
extended numbers, discused later)

	Every zero-initiated number will be considered part of the legacy
network and thus it won't be treated the same way as the new numbers
will.

	Special services in countries such as the 112 European emergency number
or the 901 US police code will be kept into working using two different
approaches:

	a) With an special version of the asterisk system:

		* + #01#* + 112 (for the European number, see regions below)

	b) Using an extended number from the new system:

		# + 112 (to access a world-wide *new* version of the European number)

	The internal network encoding of the extended numbers will use the
available 2 bits (insufficient to represent any valid decimal digit) to
be coded. So the numeric (#) character will mean '1' for the 70th bit of
the number. There will be 2^70 possible combinations for this kind of
numbers, this is, the same number of the whole network directly
accesible to the user. However, for the preliminary version, the right
internal -binary- format of a # number will be:

	01 + 40 zeroed bits + 30 bits

	This leaves the opportunity to use up to 9 digits for special
world-wide numbers like the emergency ones and/or commercial related
phones. The remaining combinations will depend on special codes with the
40 bits all zeroes and they will offer the opportunity for private (i.e.
not publicily accesible) codes only accesible via a special Hexadecimal
dialing phone which will be only delivered to the Army, the Secret
Services and so on.

	The numbers that start -internally- with "10" and with "11" are
reserved for future expansion.

	SPECIAL NUMBERS.

	As mentioned above, there will exist some numbers that cannont be
represented with the usual decimal notation. This numbers can be used to
permit the creation of internal networks within the system. They all
start (in decimal representation) with a digit before the 1st of the 21
digits that make up a number, but to avoid them for being dialed with a
normal phone, they *shall be* dialed only through a hexadecimal phone,
using the regular asterisk abbreviation to avoid dialing leading zeroes.
Trailing zeroes cannot be substituted to avoid confussion.

	Regions are special country codes used to access internal services
-such as free-call and short-dial-emergency numbers- from anywhere in
the world. A compensation mechanism will allow to pay a small fee for
accessing externally the internally free-call numbers. The regions will
be surrounded by two numeric (#) characters and their codes will
correspond to the UN coding, with up to two digits for each possible
region. After the region code, an asterisk (*) will indicate that it is
a region-wise number, valid for the whole area (like in the European
emergency number examble above). If it is a number only pertaining to a
particular country in the area, its international code as determined by
the UN (whatever it will be, if there's any - if there's not, the usual
number for phone access will be used instead, e.g. the 1 for USA)
*shall* be included between the last numeric sign (#) and the asterisk
(*). This way, and using the usual country code for phone calls, the
phone to access Spain's Telefonica information number (locally the 1004)
will be:

	* (to elude the leading zeroes) + #01# (supposing this is the Europe
region number) + 34* (the Spanish country code) + 1004

	This has to be standardized before first implementation, so one of the
proposed schemes to numerate the countries for this shortcuts must be
selected in the next draft.

	CALLING THE NEW NUMBERS FROM THE LEGACY PHONE NETWORK.

	To allow access to this extended numbers from an existing phone sytem,
a special "international code" shall be allocated so that anyone can
call a number using their international prefix, followed by the choosen
international code, followed by the 21 digits number they want to call.
Of course, the special codes and abbreviations could -or couldnot- be
available to the calling party, deppending on the wishes of their
particular service provider. This provider could charge long distance
charges or use a special rate, as he/she wishes because nobody can
mandate them to give this kind of access to their customers. Phone
providers using the new numbering system, however, *shall* let their
customers access the legacy phone system, as it is a subset of the
system.

	OTHER CONSIDERATIONS.

	I have drafted briefly how this system *shall* work but I have not
explained the technical aspects behind it. This is because it doesn't
matter how it is actually implemented, but that it'll be implemented
with the capabilities I have enumerated *as a minimum requirement*.
Extensions to this system, providing they are compatible with the
proposal, can be added to serve special needs. The whole range of 40
bits of the "01" prefixed network is available to allow propietary
extensions and/or value-added services of any kind. Also, the extra
combinations of the 30 bits (9 digits) left to code the internationally
accesible short-numbers, this is 73,741,824 different combinations can
be used to create internal networks and/or to manage different
extensions for multi-line numbers. This codes will be only accesible via
the hexadecimal phones mentioned above and I think they are enough to
provide extensions without having to break the standard.

	CONCLUSSIONS.

	As a conclussion, I must say that this system has been devised to allow
a TRUE world-wide deployment and standardisation in the field of the
telephony, even allowing the computers to have a phone number in the
system the same way they have their IP codes. We can even use an IPv6
number (8 bytes) prefixed with one of the special extension codes
available to pad it to 9 bytes (e.g. "01000001" binary on the first bit)
so that we will be able to directly call an IPv6 device from our mobile
phone anywhere in the world -and even in another planets! ;)

	Thanks for reading my contribution to a more global village.

	Raides J.

---

From: Michael Ridley <[email-masked]>
Date: Thu, 8 Oct 1998 23:54:23 -0700

---proposal snipped---
> 	Thanks for reading my contribution to a more global village.

You have some interesting ideas which probably do merit further
study, but I wonder if this is really within the realm of the IETF?
Wouldn't this be more appropriate for the ITU or some other group?
The IETF is, by acroynm, the Internet Engineering Task Force and it
seems that the only impact your proposal has to the Internet is somewhat
coincedental.  Anyway, just my two cents.

-- 
Michael Ridley
[email-masked]

---

From: Michael Ridley <[email-masked]>
Date: Thu, 8 Oct 1998 23:54:23 -0700

---proposal snipped---

-- 
Michael Ridley
[email-masked]

---

From: "Raides J." <[email-masked]>
Date: Fri, 09 Oct 1998 10:34:42 +0100

> coincedental.  Anyway, just my two cents.

	Well. Maybe you're right, but ... isn't the ITU now involved in the
IETF, or, at least, in an Internet-related organization (see below)?

Robert Shaw escribió:
>Asunto: ITU takes action to address IP-Related aspects in standards-setting >in cooperation with IETF
>  Fecha: Mon, 21 Sep 1998 13:03:50 +0200
>    De:  Robert Shaw <[email-masked]>
>      A: ietf <[email-masked]>
> 
> http://www.itu.int/newsroom/press/releases/1998/NP-2.html
> 
> Robert
> --
> Robert Shaw <[email-masked]>
> Head a.i., IED/Advisor, Global Information Infrastructure
> International Telecommunication Union <http://www.itu.int>
> Place des Nations, 1211 Geneva, Switzerland

	By the way, thanks for your "two cents". I thought nobody could hear me
in the middle of this battle sounds I hear all around me! ;-)

	Raides J.

---

From: "Raides J." <[email-masked]>
Date: Fri, 09 Oct 1998 10:34:42 +0100

Raides J.

---

From: Robert Shaw <[email-masked]>
Date: Fri, 09 Oct 1998 13:03:55 +0200

> > coincedental.  Anyway, just my two cents.

Numbering issues are handled by ITU-T Study Group 2. You can try contacting 
the SG 2 chair, Dr. Geza Gosztony at <[email-masked]> or one of the 
vice chairs, Mr. Roy Blane at <[email-masked]> or Mr. A. Lewis at 
<[email-masked]>.

Robert

---

From: Robert Shaw <[email-masked]>
Date: Fri, 09 Oct 1998 13:03:55 +0200

Robert

---

From: "Ad Hoc" <[email-masked]>
Date: Mon, 12 Oct 1998 22:03:58 +0200

Dear all

Is there a RFC or draft dealing with on-ramp gateway behaviour in response
to signals coming from a
call routing device e.g. an autodialer. As the design and manufacturing of
inexpensive call routing and autodialing devices is of utmost importance for
the wide implementation of IP communication, this is
an important issue, which I suppose is being dealt with

Any references in this respect would be highly appreciated.

Best regards
Per Ekstrom
Ad Hoc AB

---

From: "Ad Hoc" <[email-masked]>
Date: Mon, 12 Oct 1998 22:03:58 +0200

Dear all

Best regards
Per Ekstrom
Ad Hoc AB