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

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Tue, 01 Jan 2002 08:54:52 -0500

Mike, Jon:

thanks for your helpful comments. In rewriting the spec, I also found
this dual use somewhat confusing.

I'm all for shorter specs that we can actually get implementation
reports for, so if I get the gist of your proposal:

- Just a "tel" URL in this draft; no 'fax:' or 'modem:'

- No post-dial strings or 'waiting-for-dial-tone' characters (p, w).

- No carrier identification.

For the record (and to conserve the text in case it needs to reappear),
the new I-D will appear as is, but I will then push out a streamlined
version unless somebody makes a convincing argument within the next week
that the features above are vital and that they have implemented them or
are planning to. (As usual for interop reports, I will be glad to treat
such information as confidential; there is no need to make your intents
and identity a matter of public record.)

Note that special-purpose, private parameters are permissible. We should
probably get IANA involved soon. I'd rather not delay the 2806bis draft
in the desperate attempt to demonstrate interoperability of special
features.

[email-masked] wrote:
> 
> 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

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
_______________________________________________
IPTEL mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/iptel

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 04 Jan 2002 21:23:29 -0500

The original motivation for the tel URL was not the same as its current 
usage. It was created to enable a PC with an internal fax/modem card to 
dial phone numbers when a URL is clicked. For example, when you click on 
tel:12345, your modem card would pick up and dial 12345. Since the URL 
is used directly to operate the modem, this is why things like pauses 
and post-dial digits were included.

This usage is quite different from its usage to describe a telephony 
resource, which is how it is used in SIP.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 04 Jan 2002 21:36:23 -0500

> resource, which is how it is used in SIP.

Agreed; the question is if the first usage is useful. It doesn't seem to
have attracted much use in practice. Part of the problem is that adding
URL schemes to browsers is still somewhat painful, if possible at all.
But I also think that this is like the perennial SDP and RTP URL
proposals - URLs just aren't expressive enough to contain "programs" and
complicated data structures.

As I mentioned before, for a modem connection, one typically needs a
whole lot more than a phone number and the number of stop bits,
including various pieces of authentication and PPP information.

For a fax URL, I'm not sure what this would do in a web page. Which
object would get faxed? 
(I can see popping up an application that then prompts for the document
to be faxed, similar to a mailto: URL.)

This is a decision the WG that are the "customers" of this URL need to
make. I'm basically of the opinion that unless there's a demonstrated
need for a feature, it gets ditched. Otherwise, we'll never get RFCs
beyond Proposed.
_______________________________________________
IPTEL mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/iptel