Subject: RE: [Iptel] comments on rfc2806bis

From: "Stastny Richard" <[email-masked]>
Date: Tue, 10 Dec 2002 10:08:42 +0100

Hi folks

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]] 
> Sent: Thursday, December 05, 2002 7:14 PM
> To: Rosen, Brian
> Cc: 'Jonathan Rosenberg'; [email-masked]
> Subject: Re: [Iptel] comments on rfc2806bis
> 
> 
> While I don't claim to follow all of your remarks below, let 
> me try to 
> summarize what I see as consensus positions within the working group:
> 
> - We emphasize globally unique identifiers assigned within the PSTN 
> (roughly equivalent to the set of E.164-conformant numbers) that are 
> unique everywhere, but may not be reachable from all places. The 
> document calls these global numbers.

I do not really know why you try to define something new here. In the
PSTN the
globally unique identifiers ARE the E.164 numbers as defined in ITU-T
Rec.E.164,
which is also called the global NUMBERING plan

In ITU-T Rec. E.164 it is also defined, that the maximum lenght of E.164
numbers
is 15 (period).

> 
> - In many cases, these identifiers are never dialed, but are used for 
> identification or lookup only.

Incorrect, these identifiers are NEVER dialled, because there is no
globally
unique DIALING plan. On every PSTN line you are ALWAYS in a (national
and/or local)
context, so to DIAL an E.164 number, you ALWAYS have to DIAL the
international
access code (e.g. 00 or 011 or whatever). Per convention (and I think
there is
even an recommendation out there describing this) one may write E.164
numbers
in the format e.g. +1-123-123-1234. In mobile phone systems (e.g. GSM)
it is
allowed to enter (dial?) the "+" character at the terminal, which is
translated 
by the system into the access code used in the current (roamed into)
network.

> 
> - If they are dialed, we assume that the device connected to 
> a PSTN line 
> or trunk is the only one that truly knows what digits need to 
> be emitted 
> to reach the intended destination successfully. One could argue that 
> this functionality could be split into two parts, but since 
> the dialing 
> process is actually a multi-state process (with timers, waiting for 
> certain network conditions and tones, etc.), it is not clear 
> that this 
> can successfully be done without writing a Turing-complete 
> language (or 
> at least a state-transition language) or re-inventing MGCP or Megaco. 
> Modem AT dial strings come close, but they require a fair amount of 
> external configuration, such as the type of dial-tone expected (e.g., 
> stutter dial-tone) and timers, so this is only modestly 
> helpful. It is 
> well known that AT dial strings are brittle for anything but the most 
> trivial cases since they cannot deal with error cases or 
> anything more 
> complicated than a simple second dial tone and fixed-length 
> waits. (Try 
> creating a dial-string when calling card numbers are involved...)
> 
> Given the global identifier nature of URI/URNs, I doubt that it is 
> useful to encode dial strings as such. To me, this seems like 
> encoding 
> the egress gateway or local proxy server in a HTTP URI or the 
> outbound 
> SMTP MTA in a mailto URI.
> 
> - Local numbers are escape hatches in cases where a terminal does not 
> have a global number. They are strongly discouraged; e.g., they would 
> not be needed for normal cases where a business has DID or 
> extensions. 
> They would only be needed for private dialing plans. They are made 
> globally unique by the addition of the phone-context parameter. The 
> phone-context parameter has only two functions: ensuring global 
> uniqueness across tel URIs and detecting whether the URI scope is 
> identical to the local scope.
> 
> In particular, in the terminology of the document, local numbers are 
> *not* what is actually dialed. (I believe this is where I'm losing 
> Brian's discussion thread.)

IMHO opinion you should not invent your own terminology, there is enough
confusion out there anyway.

As I described above, there is a global NUMBERING PLAN but no global
DIALING Plan.

But there are NATIONAL, LOCAL and PRIVATE NUMBERING and DIALING plans.

I take the European example, because it is more familiar to me, but the 
same (with other access codes) is valid in the NANP.

A PSTN line is ALWAYs (as already stated above) either in a local (or in
countries
with a CLOSED numbering plan -see below- in a national) dialing plan. So
if a number
is dialled, it is assumed by default that it is a local number (e.g. my
office number
can be dialled in Vienna by 789780 (you may, but not need to, dial in
addition the 
extension 32).

If you dial this number from another city in Austria, you have to escape
with "0" to the
national numbering plan, add the area code "1" for Vienna and dial
0-1-79780.

If you dial the number from Germany (they have the same escape code as
in Austria)
you have to dial the international access code "00" and dial also the
country code
for Austria "43" 00-43-1-79780. In the US you would DIAL 011-43-1-79780.

In writing (or on a GSM phone) you may also use +43179780.

Comment: A closed numbering plan is one where no local numbers exists,
so
you always have to dial the national numbers (with area code, e.g.
France, or
within the networks of mobile operators)

BTW, as you may have recognised, in Austria (and other countries) we
have
not only an open numbering plan, but also a numbering plan with variable
lenght.
Both the lenght of the area code (1-4 digits) and the local numbers vary
(3-7 digits).
Furthermore, the lenght of the DDI (dial in) in not fixed, although
there is a 
strong recommendation, that the number of the E.164 number plus the DDI
digit
shall not exceed 15 digits. This and also the access codes (and the not
mentioned
Carrier access code and Carrier identification codes (CAC+CIC) require,
that PSTN
switched can handle at least 18 (better 24) dialled digits. (also some
routing numbers
may add to the digit lenght)

What you mean above with "local" numbers is really PRIVATE numbers or
better numbers out of a PRIVATE numbering plan. If somebody is dialing
my extension from within the office, he/she is dialing 32.

If I want to dial home from my office (+43-1-9793321), I have to dial
"0" to get a "line" and then the local Vienna number (0-9793321).
Somebody
in Germany in an office may need to dial 0-00-43-1-9793321. In the
Mariott
in Atlanta I may need to dial 9-011-43-1-9793321.

On the other hand, in my mobile phone I have this number stored as
+4319793321,
which works in all mobile networks (even in the US) and in the home
network.
Remark: in mobile networks (at least in Austria) you always need to dial

national numbers, never local numbers - closed numbering plan - see
above).

My recommendation is that always E.164 numbers shall be used if the
number
can be given as E.164 number, so NO context is needed. A context SHALL
only be 
used if the number CANNOT be expressed as E.164 number (e.g. a network
specific
number (e.g. used by some mobile operators), or a DDI number which
cannot be 
dialled from outside a private network).

An 800 number (+800, or +1-800, or +43-800) does not require a context.
The 800
number MAY be routed differently (to different PSTN numbers),
if dialed within a specific context (but this information should be
contained in
the originating info and in the translation database translating the 800
number
to PSTN numbers, but not in the context attached to the tel: URI of the
800 number.

Warning: Keeping in mind the current discussion of the possibility to
use with VoIP any
number anywhere in the world, the assumption that the originating number
(CLI) can be
used to derive the originating location as no longer valid. A complete
new system
needs to be defined. If you may use New York City area codes in Montana
or Idaho over
DSL lines, the idea to route your 800 number dialed to a NYC Pizza
service has a 
serious flaw (you may get a very cold pizza). 
(see also the VoIP Numbering Issue from Verizon, Qwest and Bell South)
to NANC.

best regards

Richard Stastny

_______________________________________________
Iptel mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/iptel

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 10 Dec 2002 09:20:41 -0500

I've removed much of the original message since it deals with dialing 
numbers/strings, which, as the draft clearly states up front, are out of 
scope. May I suggest that we do not further burden the discussion with 
this non-topic?

> In ITU-T Rec. E.164 it is also defined, that the maximum lenght of E.164

I'm not defining anything new here. I don't see the benefit of 
restricting the syntax of tel URIs to limit the length, since the 
underlying name space (E.164) already does this. (If E.164 changes its 
mind, it would be nice if the spec and implementations are unaffected.)

If you read the spec, you'll find that it references the 15-digit limit.

> by the system into the access code used in the current (roamed into)

You provide an example where the user "dials" the E.164 number, so I 
don't see why my statement is wrong.

> confusion out there anyway.

As always, constructive suggestions are most welcome.

> As I described above, there is a global NUMBERING PLAN but no global

The draft does not mention global dialing plans.

> my extension from within the office, he/she is dialing 32.

The 'local number' terminology is a holdover from RFC 2806. I'm happy to 
change it to 'private number' if that is less confusing.

> dialled from outside a private network).

I'm confused by this statement. Nobody who has actually followed the 
debate has suggested that E.164 numbers need a context. We determined 
several weeks ago that 800# qualify as bona fide E.164 numbers, after 
resolving the issue of possible non-unique assignment.

> An 800 number (+800, or +1-800, or +43-800) does not require a context.

Again, I've said this many times, in many different ways. I'm not sure 
why this is being raised again. My summary did not say anything 
different, either.

In general, I would find it helpful if people took time to disagree with 
(and suggest improvements to) the actual text in the document, rather 
than with the terse summaries or rephrasings on the mailing list.

Henning