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:+ sip:+@;user=phone Mahy Expires March 31, 2004 [Page 5] Internet-Draft Phone Numbers in SIP Oct 2003 2. tel:;phone-context= sip:;phone-context=@ \ ;user=phone 3. sip:@ 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 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 can take three forms: , or . 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 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]