[Sipping] Comments (2) on draft-antti-rfc2806bis

[[e-mail]]

To all,

In reviewing the descriptions in the draft concerning the use of the 
"context", I find a number of difficulties in its definition and implied 
usage.

The "context" is described as being used for three very different purposes:

1. as a part of an international number, in which the full E.164 number is 
split between the "global-number-part" in the "context" and the 
"local-number-part". The two parts can be concatenated together to construct 
the real E.164 number. (However, the text also says that this form "SHOULD" 
not be used for international numbers.)

2. with a private number, in which the context is simply used as an 
"identifier" for the private network or dialing plan. In this case, the 
context may not represent actual digits which may be dialed internationally, 
and the two parts in the tel:uri can not be concatenated to form a useful 
number. There is nothing that guarantees uniqueness in the "context" used by 
different networks.

3. with a locally dialable number like 911 or 112 which is not a part of the 
international dialing plan, in which the context is some undefined set of 
digits, shown in the example as the country code ("1" for the US). Again, the 
parts can not be concatenated to form a useful number.

In all three cases, the context is coded as "+" followed by a string of 
digits.

Section 19.1.6 of 2543bis describes how the tel:url (from the 1st version in 
RFC 2806) can be converted into a SIP URL This certainly needs to be updated 
for the update of 2806, but the current definition in 2806bis will prevent 
any straightforward conversion, since nothing in the tel:uri would indicate 
which of the three cases above is being used. The procedures in 
draft-ietf-sipping-e164 would have difficulty since they would not be able to 
accurately form an E.164 address from the tel:uri. Further, the conversion 
required in draft-ietf-sipping-isup could not be done accurately. Any other 
use of the tel:uri would need to understand the three applications of the 
context described above.

The basic problem occurs because of the attempt to use part of an E.164 
number as a private network identifier, while labeling it (with the "+") as 
actually being a part of an international number. In many cases, there is no 
E.164 number or part of one that would be appropriate to identify a network. 
What number would be appropriate to identify the world-wide DoD network? If a 
private network identifier is needed, then one should be defined. (I don't 
know if one has been proposed before.)

This contradiction can be resolved in several ways:

1. Make the use of the full E.164 number format a MUST when dealing with an 
international dialable number. The context would then only be used to 
identify a private network and should be formatted without the leading "+". 
It could contain any desired character string.

or

2. Make a clear distinction in the context between its use to carry the 
leading digits of the international number and its use for a "network 
identifier", for example, "+" to indicate international number and no "+" to 
indicate private string.

A further difficulty is the use of a context with locally dialed numbers such 
as 911 which are not a part of the internatonal dialing scheme, although the 
use of the context beginning with "+" implies that they are. The examples 
show +1-911, although there is no known use for this combination. It is not 
dialable and, in fact, 911 isn't valid everywhere within world-zone 1. A SIP 
client or other device elsewhere in the network would not necessarily know 
which specific combinations were dialable. If such numbers as 911 are to be 
coded in a tel:uli, it is necessary to explicitly identify them as not being 
dialable internationally, which means they can not be used to form an E.164 
number. The current definition of the tel:uri does not provide this 
capability. This can be resolved by never including a context with these 
numbers or by using an explicit coding such as:
     ";phone-context=local".

Interworking with ISUP is required. The current draft-ietf-sipping-isup 
contains a very unsatisfactory description in Section 11 of the conversion 
from a non-international form of tel:url to ISUP. It will need to be updated 
to describe the conversion between the new tel:uri and the Called Party 
Number parameter (and other IAM parameters which carry telephone numbers). 
This will be greatly simplified if the tel:uri definition is patterned after 
what ITU-T and other telephony standards have already done for ISUP. The 
equivalent thing in ISUP is the Called Party Number which contains two fields 
(see Section 11 of draft-ietf-sipping-isup-01 for a summary):

- "Nature of Address indicator". The important values supported in ITU-T 
include: subscriber number, national number, international number, network 
specific number. Additional values with network routing numbers prepended are 
also defined. The tel:uri must explicitly identify each of these cases or 
must explicitly say that they are not used within SIP.
- "Numbering Plan indicator". The values supported in the US are: unknown, 
ISDN numbering plan (E.164), and Private numbering plan. The tel:uri must 
explicitly identify these formats.


Mike Pierce
Artel