Status of this Memo

This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on March 31, 2004.

Copyright Notice

Copyright (C) The Internet Society (2003). All Rights Reserved.

Abstract

There is much confusion about how to represent telephone numbers and other related strings of digits in SIP URIs and tel: URIs, especailly when those digit strings are of purely local significance. This matter is complicated by the underspecification of the "user" SIP URI parameter in RFC3261 and the phone-context parameter in RFC2806.This document proposes specific semantics for the user=phone parameter and describes several ways to encode digits strings and phone numbers in a manner consistent with that proposal.

Table of Contents

1.  Conventions
2.  Introduction
3.  Semantics of "user=phone"
4.  Implications
5.  Representing Locally Significant Strings and Numbers
6.  Converting locally dialed digits into a valid URI
7.  Chapter and Verse
8.  Security Considerations
9.  Acknowledgments
§  Normative References
§  Informational References
§  Author's Address
§  Intellectual Property and Copyright Statements

1. Conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119[1].

2. Introduction

One of the most common applications of SIP[2] is Voice over IP. SIP frequently interoperates with telephone networks through gateways, and many "IP telephones" implement SIP using a telephone keypad as their primary addressing mechanism. In this capacity, SIP frequently needs to carry addressing information expressed as strings of digits which may correspond to a telephone number on the Public Switched Telephone Network (PSTN), a private phone number in a private telephone network, and even a string of telephone digits which correspond directly to the digits which are dialed there, which may contain access codes, prefixes, and other locally significant information.

To accomodate telephone addressing, the SIP specification includes a provision to incorporate a tel: URI[4] telephone-subscriber (everything following the tel: prefix) directly into the user part of a sip: or sips: URI, by setting the "user" parameter to "phone". This provision is futher complicated by the fact that RFC3261 references RFC2806[3] which is being revised in a non-backwards compatible way.

The tel: URI telephone-subscriber can be either a global-number or a local-number. ([7] provides additional SIP recommendations for dealing with global-numbers.) RFC2806 is ambiguous about whether a local-number needs to include any additional context. One statement in section 2.5.2 says that an "area-specifier" is mandatory (now called the phone-context parameter), while another statement in the same section says an "area-specifier" SHOULD be used. RFC2806bis requires a phone-context parameter for all local-numbers.

A large number of implementations currently send local-number-digits prepended by tel: with no qualification whatsoever, or include local-number-digits alone in a sip: or sips: URI with the user=phone qualification. An equally large number of implementations intrepret such URIs as illegal. This proposal would deprecate the use of these unqualified local digits strings, while hopefully satisfying all the requirements which motivated their original use.

Finally it is essential to restate that SIP servers which are not authoritative for the host portion of a URI MUST NOT assume that they understand the semantics of the userinfo portion, and MUST NOT attempt to parse the userinfo portion of a URI as anything other than an opaque string of characters matching the "user" ABNF[5] as shown below:

3. Semantics of "user=phone"

The author proposes that the SIP, SIPPING, and IPTEL communities make the following statement explicitly in an update to RFC3261.

When the user parameter in a SIP URI is set to user=phone this indicates that the userpart of the SIP URI MUST be formatted as a valid telephone-subscriber according to RFC2806bis.

(Note that even with such a statement, SIP servers which are not authoritative for the host portion of the URI MUST NOT attempt to enforce this restriction. Trying to police this restriction would violate a fundamental principal of SIP and several normative statements in the core specification.)

Now to defend this proposal we first need to answer several questions about why user=phone exists at all.

Why embed tel URIs in sip and sips URIs instead of just sending requests to tel URIs? First, there is no way to require hop-by-hop TLS protection of a SIP request using a tel: URI. Instead, the tel: URI needs to be embedded in the corresponding sips: URI. Second, tel: URIs do not contain any domain information. This represents a significant semantic distinction. For example, imagine that Aice wants to ask Bob to call a phone number. She could send a REFER[6] request to Bob referring him to a sip: URI or a tel: URI. In the first case, Alice has selected the domain to handle the request, and in the second case Bob will have to select an appropriate domain to handle the request. This distinction is likely to have a number of security, privacy, and billing consequences. As another example, imagine that Alice would like to use the SIP loose-routing mechanism to cause an invitation to pass through callhistory-proxy.example.net, which collects call history information on her behalf. If the Request-URI of her request is a tel: URI, then the server in the example.net domain selects how to handle that tel: URI (it might not process tel URIs at all and simply reject the request), whereas if the Request-URI is a SIP URI, then Alice is in control of the target of her request.

Why not just send all phone numbers encoded in the userpart of an ordinary SIP user and deprecate the user parameter? While it is certainly reasonable for individual domains to make this decision, this is not feasible in every domain. In some cases, local accounts (typically numeric) might collide with valid telephone numbers within some domains. The classic example at the time the user parameter was added was the CompuServe address, which was completely numeric and a very common length for local telephone numbers (for example: sip:71234567@compuserve.com could be a local phone number in some countries, or a CompuServe account number.) Note also that since the characters A through F are valid phone-digits, even the semantics of some non-numeric addresses can be ambiguous.

Since the user parameter is arguably needed to disambiguate the situation described above, it makes sense that some domains might want to take advantage of a parameter that indicates specific semantics about the userpart of the request. Using user=phone with a global-number is an excellent convention for inter-domain communications, since the semantics are clear. Alice could confidently send a request to sip:+14085551212@example.net;user=phone and know that the semantics of the request are obvious without arranging in advance the format in which specific global phone numbers are encoded in an "ordinary" SIP URI (a URI where user=ip). Note that the existence of such a convention does not mean that example.net will process the request, but it insures that the semantics are unambiguous. If example.net rejects the request it does so because it chooses to, not due to ambiguity or lack of knowledge of the semantics or syntax of the requested address.

4. Implications

With this proposal in place, there are three types of styles of user addresses we can represent in SIP, global-numbers, local-numbers, and ordinary SIP URIs where user=up or the user parameter is absent.

As noted above, a domain may choose to process global or local strings of digits in the user part of a SIP URI even when user=ip. However, there are several optimizations which simplify processing for domains which only process digit strings when user=phone is present. First observe that according to section 10.3 step 5 of RFC3261, the user param is ignored in the To header in a registration. In other words you cannot register sip:+14085551212@example.com and sip:+14085551212@example.com;user=phone separately. Thus a sip URI with user-param set to phone is NOT an address-of-record (AOR).

Most domains which handle telephone numbers perform transformations on them (for example, lookup a corresponding SIP URI for a local number, do an ENUM[8] lookup, or change a local-number in a specific phone-context to a global-number or vice-versa) and then select an appropriate route based on specific prefixes or ranges of addresses. This processing can be limited (as a local domain choice) to requests which contain a user=phone parameter. Requests which arrived for a phone number which corresponds to a registered AOR can (legally) spiral the request. Proxies could then treat requests where user=ip (the default) so the userpart of the request is interpreted in a flat namespace which corresponds to local registrations only for example (again, as a local domain choice).

5. Representing Locally Significant Strings and Numbers

RFC2806bis briefly describes the difference between a phone number and a "dial string". However it does not provide a rigorous definition. So what's the difference between a phone number and a dial string? It appears that the main distinction that the authors of 2806 were concerned with is that dial strings can contain pauses and waits and other post-dial digits used to enter access codes and negotiate IVRs (Interactive Voice Response units) and other two-stage dialing systems. This later category is clearly out of scope. Other than this distinction, this author has concluded that a local phone number is therefore any string which parses under the local-number-digits ABNF and contains a valid phone-context. This allows us to represent all digits dialable from a standard keypad. (The * and # symbols are represented by digits "E" and "F" respectively (did I get this right?)).

The phone context can be useful to disambiguate local phone numbers from other otherwise identical local phone numbers in a multi-tenant proxy for example. (for example dialing "0" or "9" to get an operator).

6. Converting locally dialed digits into a valid URI

There have been many mailing list comments that making devices such as telephones send legal tel URIs is hard or requires burdensome configuration. sending a valid URI is very easy actually. Either a device like a phone has a digit map or it does not. A phone which has no digit map needs to be configured with a handful of parameters, for example SIP server address, domain name, and typically the local address and authentication user name which the phone uses to send registrations.

For example, lets assume Alice's phone uses the sip.example.com proxy server, is in the example.com domain, has a local address of tel:+14085551212, and uses the username alice to register. In the absense of any additional configuration such a phone could convert the string 1234 into any of the following valid URIs:

To work better in environments where a single proxy server provides services to many different phones with no digit maps, but different numbering plans, Alice can provide an additional piece of explicit phone-context, or an explicit default domain. If Alice's phone-context is atlanta.example.com her phone can convert the string 1234 into any of the following valid URIs:

A phone with digit map needs to configured with that digit map. Once it is configured, it could transform a string like "1234" into any of the following for example:

7. Chapter and Verse

Section 19.1.1 of RFC3261:

Both in section 2.5.2 of RFC2806:

From section 10.3 of RFC3261:

Finally section 19.1.6 of RFC3261:

8. Security Considerations

This document introduces no new security considerations.

9. Acknowledgments

Thanks to Francios Audet, Brian Rosen, and Dean Willis for a hearty list discussion.

Normative References

Informational References

Author's Address

Intellectual Property Statement

The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.

Full Copyright Statement

Copyright (C) The Internet Society (2003). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

Funding for the RFC Editor function is currently provided by the Internet Society.