Subject: [IPTEL] Comments on RFC 2806 revision (tel url)

From: [email-masked]
Date: Mon, 31 Dec 2001 17:03:43 EST

To all,

I believe that mention of this RFC in Minneapolis in the March 2001 meeting 
indicated that there was a general feeling that there were significant 
problems with the current text and a rewrite was required. Based on this, I 
will make some rather substantial comments on the current text, with the 
understanding that they propose some significant changes to the concept and 
details described.

The text of RFC 2806 seems to confuse the controls that might be needed 
between a controller and the device doing outgoing dialing (e.g., MGC and MG) 
with what is required in the url to designate the destination (location). For 
example, it takes the AT modem commands for pauses and waits for dial tone 
and includes them with the url. While there may be cases in which one 
specific network element (e.g., a MG) needs to apply these techniques in 
order to send digits (DTMF or dial pulse) to another element (e.g., a circuit 
switched PBX), the originator of the call knows nothing about this, so this 
information should not be a part of the url. In fact, due to alternate 
routing, two calls with the same url might be treated differently because 
they are routed differently. This type of dialing in which the originator 
needed to know the routing in order to formulate the digit string was 
eliminated from most telephony switching environments long ago.

The definition of specific "tel", "fax", and "modem" urls ignores the 
existence of customer premise devices currently in use which allow the 
connection of telephones, faxs, and modems on the same telephone line (using 
the same telephone number). In reality, there is no difference in the urls 
needed for the 3 cases mentioned. The current telephony network is based on 
there being no difference within the network for these different uses. If 
other information needs to be carried (e.g., to specify the type of modem 
supported) this should be separate from the url and may be ignored by some 
equipment. This type information should not be a part of the url, since it 
does not provide an identification of the "resource location". If it did, 
this would then imply, for example, that the following define different 
locations, that is, must be routed differently:

modem:+1-410-555-1234;type=v32b
modem:+1-410-555-1234;type=v21
modem:+1-410-555-1234;type=x75

"Post dial" should not be a part of the url. The example given in Section 2.2 
of accessing a voice mailbox shows the mistake. The digits to be dialed by 
the caller when accessing a voice mailbox depend on the voice prompt from 
that mailbox system after setup of the initial call. For this reason, the 
possible post-dialing digits can not be a part of the url.

There is a fundamental problem in that the urls being described in this RFC 
serve both as a user visible address (like on a letterhead or on a web page) 
and as the inter-network element signaling protocol (e.g., part of SIP). It 
is noted that E.123, which is referenced, only addresses the representation 
of numbers, for example, on letterhead. This dual purpose of the url being 
defined leads to confusion in the description. For example, while some 
signaling relationships may need to be able to code the extra preliminary 
prefix digits needed to do special things (like the "0w00" in the 5th example 
in Section 2.6), this would never be a part of the url as printed or visible 
on a web page, since it is dependent on the location and equipment of the 
originator.

In the telephony world, the digits 0-9 are represented in signaling only by 
those numbers, However, the user may see the address with these numbers 
replaced by letters. Since the url being defined here is intended to be seen 
by the user (as also defined in E.123), it is essential that it be allowed to 
include letters (not the A, B, C, D that are used to designate the extra 4 
codes possible on a DTMF key pad). As E.123 states, "diallable symbols ... 
can be digits, letters, or other signs." Of course, this causes a problem if 
one tries to incorporate the 4 extra DTMF codes into the same address string. 
However, in the ITU-T E.164 numbering plan, these extra DTMF codes can not be 
part of the address. The international number is limited to 15 digits, each 
being a numeral 0-9. So, in the tel: url beginning with +, there is no 
problem with allowing letters a-z. Of course, this depends on the association 
between letters and numbers being as recommended in E.161. For this reason, 
users are advised to avoid using letters to specify telephone numbers in 
international service, but they may.

The 1st, 2nd, and 3rd examples in Section 2.6 show a problem with this scheme 
of treating tel, fax, and modem separately. The three examples use the same 
number, which can really occur. As shown, the three identical numbers must 
all result in exactly the same call setup regardless of the extra parameters. 
Whether it is treated as a telephone or fax or modem call depends on the 
kinds of equipment connected and the in-band signals which occur.

The 4th example in Section 2.6 show the problem with the post-dial logic. 
While there may be valid case to support the extra digits needed to directly 
dial into a PBX at the destination in order to directly reach an extension, 
that capability needs to be under control of the destination. Only the 
destination knows whether DTMF or dial-pulse or something else is needed to 
signal to the final entity. The originating entity does not even need to know 
that there is an extension number present if it is a part of the complete 
number (as happens in the US all the time with DID). If the extension number 
is in addition to the regular international number (which is limited to 15 
digits), then the originating entity might know that there are additional 
digits, but still has no knowledge of how the destination is going to signal 
them (e.g., to a PBX). The other example of the origination entity needing of 
enter DTMF to invoke a particular service would require an audible response 
returned from the destination after call set before these additional DTMF 
digits are sent. Therefore, they can not be part of the url in this case.

The text of the 5th example indicates the problem with this form of the url. 
It states "this kind of phone umber MUST NOT be used in an environment where 
all users of this URL might not be able to successfully dial out by using 
this number directly." Since such a phone number contained on a "company 
intranet" or printed material would be accessible by many people in various 
places, this will not work. The method used, and the format of the url, 
should follow the procedures developed over many decades of such situations 
in the telephony world. The telephone number needs to be shown in a standard 
local or international format and the user needs to understand how to dial it 
from their location (e.g., by dialing "0", waiting for dial tone, and then 
dialling "00" for international access because the local telephone book says 
to do this). Clearly, when the originating user has a computerized user agent 
(SIP phone), it can do this thinking for the person based on dialing rules 
that it has been provisioned with, so the human doesn't have to worry about 
it. That means that the url on a web page must be in one of the standard 
formats (no extra prefix digits). In some environments, there may in fact be 
multiple ways to dial a specific destination. Today the user may decide which 
to use and the new user agent (SIP phone) can also do so, so it should not be 
a part of the url.

Since the 6th example shows a telephone number in country code 1, it should 
be following by a legitimate 10-digit number so as to not confuse. Further, 
the idea should be represented with a better example. It is unknown of any 
case in which an E.164 telephone number (in North America) would be 
specified, but it is only "usable" within that area code. Perhaps the example 
would be better if it were to specify a number usable only within a specific 
country.

I suggest that this RFC be pared down to simply defining the url for a 
"telephone" number and that additional parameters that might control call 
setup, such as modem capabilities, should be a part of SIP or a supplementary 
draft that specifically describes additions to SIP for fax and modem calls.

Mike Pierce
Artel
_______________________________________________
IPTEL mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/iptel