SIPPING WG R. Mahy
Internet-Draft Cisco Systems, Inc.
Expires: March 31, 2004 Oct 2003
Proposed Clarification of Encoding of Telephone Numbers in SIP URis
draft-mahy-sipping-user-equals-phone-00.txt
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.
Mahy Expires March 31, 2004 [Page 1]
Internet-Draft Phone Numbers in SIP Oct 2003
Table of Contents
1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Semantics of "user=phone" . . . . . . . . . . . . . . . . . . 4
4. Implications . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Representing Locally Significant Strings and Numbers . . . . . 6
6. Converting locally dialed digits into a valid URI . . . . . . 7
7. Chapter and Verse . . . . . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
Normative References . . . . . . . . . . . . . . . . . . . . . 9
Informational References . . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . 11
Mahy Expires March 31, 2004 [Page 2]
Internet-Draft Phone Numbers in SIP Oct 2003
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.
Legally formatted URIs:
tel:+14085551212
Mahy Expires March 31, 2004 [Page 3]
Internet-Draft Phone Numbers in SIP Oct 2003
tel:1234;phone-context=seattle.example.com
sip:1234@example.com
sip:1234;phone-context=seattle.example.com@example.com;user=phone
sip:+14085551212@example.com;user=phone
sip:+14085551212@example.com
Illegally formatted URIs?
tel:1234
sip:1234@example.com;user=phone
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:
user = 1*(unreserved / escaped / user-unreserved)
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
Mahy Expires March 31, 2004 [Page 4]
Internet-Draft Phone Numbers in SIP Oct 2003
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.
1. tel:+<globalnumber>
sip:+<globalnumber>@<sipserver>;user=phone
Mahy Expires March 31, 2004 [Page 5]
Internet-Draft Phone Numbers in SIP Oct 2003
2. tel:<localnumber>;phone-context=<context>
sip:<localnumber>;phone-context=<context>@<sipserver> \
;user=phone
3. sip:<user>@<sipserver>
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
Mahy Expires March 31, 2004 [Page 6]
Internet-Draft Phone Numbers in SIP Oct 2003
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:
tel:1234;phone-context=alice.example.com
tel:1234;phone-context=+14085551212
sip:1234@sip.example.com
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:
sip:1234;phone-context=atlanta.example.com \
@sip.example.com;user=phone
sip:1234@atlanta.example.com
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:
tel:+14085551234
sip:+14085551234@example.com;user=phone
sip:1234@site.example.com
sip:6781234@example.com
Mahy Expires March 31, 2004 [Page 7]
Internet-Draft Phone Numbers in SIP Oct 2003
7. Chapter and Verse
Section 19.1.1 of RFC3261:
The set of valid telephone-subscriber strings is a subset of
valid user strings. The user URI parameter exists to distinguish
telephone numbers from user names that happen to look like
telephone numbers. If the user string contains a telephone number
formatted as a telephone-subscriber, the user parameter value
"phone" SHOULD be present. Even without this parameter,
recipients of SIP and SIPS URIs MAY interpret the pre-@ part
as a telephone number if local restrictions on the name space
for user name allow it.
Both in section 2.5.2 of RFC2806:
Not all numbers are valid within all numbering areas. The <area-
specifier> parameter, which is mandatory for local numbers, is used
to indicate the locale within which this number is valid, or to
qualify the phone number so that it may be used unambiguously. The
<area-specifier> can take three forms: <global-network-prefix>,
<local-network-prefix> or <private-prefix>. These are used to
describe the validity area of the phone number either in global
numbering plan, local numbering plan, or in a private numbering
plan,respectively.
...
If local phone numbers are used, the document in which
they are present SHOULD contain an indication of the
context in which they are intended to be used, and an
appropriate <area-specifier> SHOULD be present in the URL.
From section 10.3 of RFC3261:
5. The registrar extracts the address-of-record from the To header
field of the request. If the address-ofr ecord is not valid for
the domain in the Request-URI, the registrar MUST send a 404
(Not Found) response and skip the remaining steps. The URI MUST
then be converted to a canonical form. To do that, all URI
parameters MUST be removed (including the user-param), and any
escaped characters MUST be converted to their unescaped form.
The result serves as an index into the list of bindings.
Finally section 19.1.6 of RFC3261:
19.1.6 Relating SIP URIs and tel URLs
Mahy Expires March 31, 2004 [Page 8]
Internet-Draft Phone Numbers in SIP Oct 2003
When a tel URL (RFC 2806 ) is converted to a SIP or SIPS URI,
the entire telephone-subscriber portion of the tel URL,
including any parameters, is placed into the userinfo part of
the SIP or SIPS URI.
Thus, tel:+358-555-1234567;postd=pp22 becomes
sip:+358-555-1234567;postd=pp22@foo.com;user=phone
or sips:+358-555-1234567;postd=pp22@foo.com;user=phone
not sip:+358-555-1234567@foo.com;postd=pp22;user=phone
or sips:+358-555-1234567@foo.com;postd=pp22;user=phone
In general, equivalent "tel" URLs converted to SIP or SIPS URIs
in this fashion may not produce equivalent SIP or SIPS URIs.
The userinfo of SIP and SIPS URIs are compared as a case-
sensitive string. Variance in case-insensitive portions of tel
URLs and reordering of tel URL parameters does not affect tel
URL equivalence, but does affect the equivalence of SIP URIs
formed from them.
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
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[3] Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806, April
2000.
[4] Schulzrinne, H., "The tel URI for Telephone Calls",
draft-ietf-iptel-rfc2806bis-00 (work in progress), June 2003.
[5] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
Mahy Expires March 31, 2004 [Page 9]
Internet-Draft Phone Numbers in SIP Oct 2003
Informational References
[6] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003.
[7] Liu, H., Campbell, B., Peterson, J. and J. Yu, "Using ENUM for
SIP Applications", draft-ietf-sipping-e164-02 (work in
progress), October 2002.
[8] Mealling, M. and P. Faltstrom, "The E.164 to URI DDDS
Application (ENUM)", draft-ietf-enum-rfc2916bis-06 (work in
progress), May 2003.
Author's Address
Rohan Mahy
Cisco Systems, Inc.
5617 Scotts Valley Drive, Suite 200
Scotts Valley, CA 95066
USA
EMail: rohan@cisco.com
Mahy Expires March 31, 2004 [Page 10]
Internet-Draft Phone Numbers in SIP Oct 2003
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
Mahy Expires March 31, 2004 [Page 11]
Internet-Draft Phone Numbers in SIP Oct 2003
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.
Mahy Expires March 31, 2004 [Page 12]