Movatterモバイル変換

Network Working Group                                     H. SchulzrinneRequest for Comments: 3966                           Columbia UniversityObsoletes:2806                                            December 2004Category: Standards TrackThe tel URI for Telephone NumbersStatus of this Memo   This document specifies an Internet standards track protocol for the   Internet community, and requests discussion and suggestions for   improvements.  Please refer to the current edition of the "Internet   Official Protocol Standards" (STD 1) for the standardization state   and status of this protocol.  Distribution of this memo is unlimited.Copyright Notice   Copyright (C) The Internet Society (2004).Abstract   This document specifies the URI (Uniform Resource Identifier) scheme   "tel".  The "tel" URI describes resources identified by telephone   numbers.  This document obsoletesRFC 2806.Table of Contents1.   Introduction. . . . . . . . . . . . . . . . . . . . . . . . .22.   Terminology . . . . . . . . . . . . . . . . . . . . . . . . .43.   URI Syntax. . . . . . . . . . . . . . . . . . . . . . . . . .44.   URI Comparisons . . . . . . . . . . . . . . . . . . . . . . .65.   Phone Numbers and Their Context . . . . . . . . . . . . . . .65.1.   Phone Numbers. . . . . . . . . . . . . . . . . . . . .65.1.1. Separators in Phone Numbers . . . . . . . . . .7               5.1.2. Alphabetic Characters Corresponding to Digits .  7               5.1.3. Alphabetic, *, and # Characters as Identifiers.  75.1.4. Global Numbers. . . . . . . . . . . . . . . . .75.1.5. Local Numbers . . . . . . . . . . . . . . . . .85.2.   ISDN Subaddresses. . . . . . . . . . . . . . . . . . .95.3.   Phone Extensions . . . . . . . . . . . . . . . . . . .105.4.   Other Parameters . . . . . . . . . . . . . . . . . . .106.   Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .107.   Rationale . . . . . . . . . . . . . . . . . . . . . . . . . .117.1.   Why Not Just Put Telephone Numbers in SIP URIs?. . . .117.2.   Why Not Distinguish between Call Types?. . . . . . . .117.3.   Why tel. . . . . . . . . . . . . . . . . . . . . . . .117.4.   Do Not Confuse Numbers with How They Are Dialed. . . .11Schulzrinne                 Standards Track                     [Page 1]

RFC 3966                      The tel URI                  December 20048.   Usage of Telephone URIs in HTML . . . . . . . . . . . . . . .119.   Use of "tel" URIs with SIP (Informative). . . . . . . . . . .1210.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .1411.  Security Considerations . . . . . . . . . . . . . . . . . . .1412.  Changes SinceRFC 2806. . . . . . . . . . . . . . . . . . . .1413.  References. . . . . . . . . . . . . . . . . . . . . . . . . .1513.1.  Normative References . . . . . . . . . . . . . . . . .1513.2.  Informative References . . . . . . . . . . . . . . . .16   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . .16   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . .171.  Introduction   This document defines the URI scheme "tel", which describes resources   identified by telephone numbers.  A telephone number is a string of   decimal digits that uniquely indicates the network termination point.   The number contains the information necessary to route the call to   this point.  (This definition is derived from [E.164] but encompasses   both public and private numbers.)   The termination point of the "tel" URI telephone number is not   restricted.  It can be in the public telephone network, a private   telephone network, or the Internet.  It can be fixed or wireless and   address a fixed wired, mobile, or nomadic terminal.  The terminal   addressed can support any electronic communication service (ECS),   including voice, data, and fax.  The URI can refer to resources   identified by a telephone number, including but not limited to   originators or targets of a telephone call.   The "tel" URI is a globally unique identifier ("name") only; it does   not describe the steps necessary to reach a particular number and   does not imply dialling semantics.  Furthermore, it does not refer to   a specific physical device, only to a telephone number.   As commonly understood, telephone numbers comprise two related but   distinct concepts: a canonical address-of-record and a dial string.   We define the concepts below:   Address-of-record or identifier: The telephone number is understood      here as the canonical address-of-record or identifier for a      termination point within a specific network.  For the public      network, these numbers follow the rules in E.164 [E.164], while      private numbers follow the rules of the owner of the private      numbering plan.  Subscribers publish these identifiers so that      they can be reached, regardless of the location of the caller.      (Naturally, not all numbers are reachable from everywhere, for aSchulzrinne                 Standards Track                     [Page 2]

RFC 3966                      The tel URI                  December 2004      variety of technical and local policy reasons.  Also, a single      termination point may be reachable from different networks and may      have multiple identifiers.)   Dial string: "Dial strings" are the actual numbers, symbols, and      pauses entered by a user to place a phone call.  A dial string is      consumed by one or more network entities and understood in the      context of the configuration of these entities.  It is used to      generate an address-of-record or identifier (in the sense      described above) so that a call can be routed.  Dial strings may      require prepended digits to exit the private branch exchange (PBX)      the end system is connected to, and they may include post-dial      dual-tone multi-frequency (DTMF) signaling that could control an      interactive voice response (IVR) system or reach an extension.      Dial strings are beyond the scope of this document.   Both approaches can be expressed as a URI.  For dial strings, this   URI is passed to an entity that can reproduce the actions specified   in the dial string.  For example, in an analog phone system, a dialer   translates the dial string into a sequence of actions such as waiting   for dial tone, sending DTMF digits, pausing, and generating post-dial   DTMF digits after the callee picks up.  In an integrated services   digital network (ISDN) or ISDN user part (ISUP) environment, the   signaling elements that receive protocol messages containing the dial   string perform the appropriate protocol actions.  As noted, this   approach is beyond the scope of this specification.   The approach described here has the URI specify the telephone number   as an identifier, which can be either globally unique or only valid   within a local context.  The dialling application is aware of the   local context, knowing, for example, whether special digits need to   be dialed to seize an outside line; whether network, pulse, or tone   dialling is needed; and what tones indicate call progress.  The   dialling application then converts the telephone number into a dial   sequence and performs the necessary signaling actions.  The dialer   does not have to be a user application as found in traditional   desktop operating systems but could well be part of an IP-to-PSTN   gateway.   To reach a telephone number from a phone on a PBX, for example, the   user of that phone has to know how to convert the telephone number   identifier into a dial string appropriate for that phone.  The   telephone number itself does not convey what needs to be done for a   particular terminal.  Instructions may include dialling "9" before   placing a call or prepending "00" to reach a number in a foreign   country.  The phone may also need to strip area and country codes.Schulzrinne                 Standards Track                     [Page 3]

RFC 3966                      The tel URI                  December 2004   The identifier approach described in this document has the   disadvantage that certain services, such as electronic banking or   voicemail, cannot be specified in a "tel" URI.   The notation for phone numbers in this document is similar to that inRFC 3191 [RFC3191] andRFC 3192 [RFC3192].  However, the syntax   differs as this document describes URIs whereasRFC 3191 andRFC 3192   specify electronic mail addresses.RFC 3191 andRFC 3192 use "/" to   indicate parameters (qualifiers).  Since URIs use the forward slash   to describe path hierarchy, the URI scheme described here uses the   semicolon, in keeping with Session Initiation Protocol (SIP) URI   conventions [RFC3261].   The "tel" URI can be used as a request URI in SIP [RFC3261] requests.   The SIP specification also inherits the 'subscriber' part of the   syntax as part of the 'user element' in the SIP URI.  Other protocols   may also use this URI scheme.   The "tel" URI does not specify the call type, such as voice, fax, or   data call, and does not provide the connection parameters for a data   call.  The type and parameters are assumed to be negotiated either   in-band by the telephone device or through a signaling protocol such   as SIP.   This document obsoletesRFC 2806.2.  Terminology   In this document, the key words "MUST", "MUST NOT", "REQUIRED",   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",   and "OPTIONAL" are to be interpreted as described inBCP 14,RFC2119, [RFC2119] and indicate requirement levels for compliant   implementations.3.  URI Syntax   The URI is defined using the ABNF (augmented Backus-Naur form)   described inRFC 2234 [RFC2234] and uses elements from the core   definitions (appendix A ofRFC 2234).   The syntax definition followsRFC 2396 [RFC2396], indicating the   actual characters contained in the URI.  If the reserved characters   "+", ";", "=", and "?" are used as delimiters between components of   the "tel" URI, they MUST NOT be percent encoded.  These characters   MUST be percent encoded if they appear in tel URI parameter values.Schulzrinne                 Standards Track                     [Page 4]

RFC 3966                      The tel URI                  December 2004   Characters other than those in the "reserved" and "unsafe" sets (seeRFC 2396 [RFC2396]) are equivalent to their "% HEX HEX" percent   encoding.   The "tel" URI has the following syntax:   telephone-uri        = "tel:" telephone-subscriber   telephone-subscriber = global-number / local-number   global-number        = global-number-digits *par   local-number         = local-number-digits *par context *par   par                  = parameter / extension / isdn-subaddress   isdn-subaddress      = ";isub=" 1*uric   extension            = ";ext=" 1*phonedigit   context              = ";phone-context=" descriptor   descriptor           = domainname / global-number-digits   global-number-digits = "+" *phonedigit DIGIT *phonedigit   local-number-digits  =      *phonedigit-hex (HEXDIG / "*" / "#")*phonedigit-hex   domainname           = *( domainlabel "." ) toplabel [ "." ]   domainlabel          = alphanum                          / alphanum *( alphanum / "-" ) alphanum   toplabel             = ALPHA / ALPHA *( alphanum / "-" ) alphanum   parameter            = ";" pname ["=" pvalue ]   pname                = 1*( alphanum / "-" )   pvalue               = 1*paramchar   paramchar            = param-unreserved / unreserved / pct-encoded   unreserved           = alphanum / mark   mark                 = "-" / "_" / "." / "!" / "~" / "*" /                          "'" / "(" / ")"   pct-encoded          = "%" HEXDIG HEXDIG   param-unreserved     = "[" / "]" / "/" / ":" / "&" / "+" / "$"   phonedigit           = DIGIT / [ visual-separator ]   phonedigit-hex       = HEXDIG / "*" / "#" / [ visual-separator ]   visual-separator     = "-" / "." / "(" / ")"   alphanum             = ALPHA / DIGIT   reserved             = ";" / "/" / "?" / ":" / "@" / "&" /                          "=" / "+" / "$" / ","   uric                 = reserved / unreserved / pct-encoded   Each parameter name ("pname"), the ISDN subaddress, the 'extension',   and the 'context' MUST NOT appear more than once.  The 'isdn-   subaddress' or 'extension' MUST appear first, if present, followed by   the 'context' parameter, if present, followed by any other parameters   in lexicographical order.      This simplifies comparison when the "tel" URI is compared      character by character, such as in SIP URIs [RFC3261].Schulzrinne                 Standards Track                     [Page 5]

RFC 3966                      The tel URI                  December 20044.  URI Comparisons   Two "tel" URIs are equivalent according to the following rules:   o  Both must be either a 'local-number' or a 'global-number', i.e.,      start with a '+'.   o  The 'global-number-digits' and the 'local-number-digits' must be      equal, after removing all visual separators.   o  For mandatory additional parameters (section 5.4) and the 'phone-      context' and 'extension' parameters defined in this document, the      'phone-context' parameter value is compared as a host name if it      is a 'domainname' or digit by digit if it is 'global-number-      digits'.  The latter is compared after removing all 'visual-      separator' characters.   o  Parameters are compared according to 'pname', regardless of the      order they appeared in the URI.  If one URI has a parameter name      not found in the other, the two URIs are not equal.   o  URI comparisons are case-insensitive.   All parameter names and values SHOULD use lower-case characters, as   tel URIs may be used within contexts where comparisons are case   sensitive.Section 19.1.4 in the SIP specification [RFC3261] discusses one such   case.5.  Phone Numbers and Their Context5.1.   Phone Numbers   The 'telephone-subscriber' part of the URI indicates the number.  The   phone number can be represented in either global (E.164) or local   notation.  All phone numbers MUST use the global form unless they   cannot be represented as such.  Numbers from private numbering plans,   emergency ("911", "112"), and some directory-assistance numbers   (e.g., "411") and other "service codes" (numbers of the form N11 in   the United States) cannot be represented in global (E.164) form and   need to be represented as a local number with a context.  Local   numbers MUST be tagged with a 'phone-context' (section 5.1.5).   Implementations MUST NOT assume that telephone numbers have a   maximum, minimum, or fixed length, or that they always begin with or   contain certain digits.Schulzrinne                 Standards Track                     [Page 6]

RFC 3966                      The tel URI                  December 20045.1.1.  Separators in Phone Numbers   Phone numbers MAY contain visual separators.  Visual separators   ('visual-separator') merely aid readability and are not used for URI   comparison or placing a call.   Although it complicates comparisons, this specification retains   visual separators in order to follow the spirit ofRFC 2396   [RFC2396], which remarks that "A URI often needs to be remembered by   people, and it is easier for people to remember a URI when it   consists of meaningful components".  Also, ISBN URNs documented inRFC 3187 [RFC3187] use visual separators in a manner similar to this   specification.   However, even though ITU-T E.123 [E.123] recommends the use of space   characters as visual separators in printed telephone numbers, "tel"   URIs MUST NOT use spaces in visual separators to avoid excessive   escaping.5.1.2.  Alphabetic Characters Corresponding to Digits   In some countries, it is common to write phone numbers with   alphabetic characters corresponding to certain numbers on the   telephone keypad.  The URI format does not support this notation, as   the mapping from alphabetic characters to digits is not completely   uniform internationally, although there are standards [E.161][T1.703]   addressing this issue.5.1.3.  Alphabetic, *, and # Characters as Identifiers   As called and calling terminal numbers (TNs) are encoded in BCD in   ISUP, six additional values per digit can be encoded, sometimes   represented as the hexadecimal characters A through F.  Similarly,   DTMF allows for the encoding of the symbols *, #, and A through D.   However, in accordance with E.164, these may not be included in   global numbers.  Their meaning in local numbers is not defined here,   but they are not prohibited.5.1.4.  Global Numbers   Globally unique numbers are identified by the leading "+" character.   Global numbers MUST be composed with the country (CC) and national   (NSN) numbers as specified in E.123 [E.123] and E.164 [E.164].   Globally unique numbers are unambiguous everywhere in the world and   SHOULD be used.Schulzrinne                 Standards Track                     [Page 7]

RFC 3966                      The tel URI                  December 20045.1.5.  Local Numbers   Local numbers are unique only within a certain geographical area or a   certain part of the telephone network, e.g., a private branch   exchange (PBX), a state or province, a particular local exchange   carrier, or a particular country.  URIs with local phone numbers   should only appear in environments where all local entities can   successfully set up the call by passing the number to the dialling   software.  Digits needed for accessing an outside line, for example,   are not included in local numbers.  Local numbers SHOULD NOT be used   unless there is no way to represent the number as a global number.   Local numbers SHOULD NOT be used for several reasons.  Local numbers   require that the originator and recipient are configured   appropriately so that they can insert and recognize the correct   context descriptors.  Since there is no algorithm to pick the same   descriptor independently, labelling numbers with their context   increases the chances of misconfiguration so that valid identifiers   are rejected by mistake.  The algorithm to select descriptors was   chosen so that accidental collisions would be rare, but they cannot   be ruled out.   Local numbers MUST have a 'phone-context' parameter that identifies   the scope of their validity.  The parameter MUST be chosen to   identify the local context within which the number is unique   unambiguously.  Thus, the combination of the descriptor in the   'phone-context' parameter and local number is again globally unique.   The parameter value is defined by the assignee of the local number.   It does NOT indicate a prefix that turns the local number into a   global (E.164) number.   There are two ways to label the context:  via a global number or any   number of its leading digits (e.g., "+33") and via a domain name,   e.g., "houston.example.com".  The choice between the two is left to   the "owner" of the local number and is governed by whether there is a   global number or domain name that is a valid identifier for a   particular local number.   The domain name does not have to resolve to any actual host but MUST   be under the administrative control of the entity managing the local   phone context.   A global number context consists of the initial digits of a valid   global number.  All global numbers with these initial digits must be   assigned to the same organization, and no such matching number can be   used by any other organization.  For example, +49-6151-16 would be a   suitable context for the Technical University of Darmstadt, as it   uses all numbers starting with those digits.  If such an initialSchulzrinne                 Standards Track                     [Page 8]

RFC 3966                      The tel URI                  December 2004   string of digits does not exist, the organization SHOULD use the   lowest number of the global number range assigned to it.  (This can   occur if two organizations share the same decimal block of numbers.   For example, assume an organization owns the number range +1-212-   555-0100 through +1-212-555-0149.  +1-212-555-1 would not be a valid   global number context, but +1-212-555-0100 would work.) It is not   required that local numbers within the context actually begin with   the chosen set of initial numbers.   A context consisting of the initial digits of a global number does   not imply that adding these to the local number will generate a valid   E.164 number.  It might do so by coincidence, but this cannot be   relied upon.  (For example, "911" should be labeled with the context   "+1", but "+1-911" is not a valid E.164 number.)   National freephone numbers do not need a context, even though they   are not necessarily reachable from outside a particular country code   or numbering plan.  Recall that "tel" URIs are identifiers; it is   sufficient that a global number is unique, but it is not required   that it be reachable from everywhere.      Even non-freephone numbers may be out of date or may not be      reachable from a particular location.  For example, premium      services such as "900" numbers in the North American numbering      plan are often not dialable from outside the particular country      code.      The two label types were chosen so that, in almost all cases, a      local administrator can pick an identifier that is reasonably      descriptive and does not require a new IANA-managed assigned      number.  It is up to the administrator to assign an appropriate      identifier and to use it consistently.  Often, an organization can      choose among several different identifiers.   If the recipient of a "tel" URI uses it simply for identification,   the receiver does not need to know anything about the context   descriptor.  It simply treats it as one part of a globally unique   identifier, with the other being the local number.  If a recipient of   the URI intends to place a call to the local number, it MUST   understand the context and be able to place calls within that   context.5.2.  ISDN Subaddresses   A phone number MAY also contain an 'isdn-subaddress' parameter that   indicates an ISDN subaddress.Schulzrinne                 Standards Track                     [Page 9]

RFC 3966                      The tel URI                  December 2004   ISDN subaddresses typically contain International Alphabet 5 (IA5   [T.50]) characters but may contain any octet value.5.3.  Phone Extensions   Phone extensions identify stations behind a non-ISDN PBX and are   functionally roughly equivalent to ISDN subaddresses.  They are   identified with the 'extension' parameter.  At most, one of the   'isdn-subaddress' and 'extension' parameters can appear in a "tel"   URI, i.e., they cannot appear both at the same time.5.4.  Other Parameters   Future protocol extensions to this URI scheme may add other   parameters ('parameter' in the ABNF).  Such parameters can be either   mandatory or optional.  Mandatory parameters start with "m-".  An   implementation MAY ignore optional parameters and MUST NOT use the   URI if it contains unknown mandatory parameters.  The "m-" prefix   cannot be added to parameters that were already registered (except to   create a new, logically distinct parameter).  The "phone-context"   parameter in this document is mandatory,  and "isub" and "ext" are   optional.   New mandatory parameters must be described in a standards-track RFC,   but an informational RFC is sufficient for optional parameters.   For example, 'parameter' parameters can be used to store   application-specific additional data about the phone number, its   intended use, or any conversions that have been applied to the   number.   Entities that forward protocol requests containing "tel" URIs with   optional parameters MUST NOT delete or modify parameters they do not   understand.6.  Examples   tel:+1-201-555-0123: This URI points to a phone number in the United      States.  The hyphens are included to make the number more human      readable; they separate country, area code and subscriber number.   tel:7042;phone-context=example.com: The URI describes a local phone         number valid within the context "example.com".   tel:863-1234;phone-context=+1-914-555: The URI describes a local      phone number that is valid within a particular phone prefix.Schulzrinne                 Standards Track                    [Page 10]

RFC 3966                      The tel URI                  December 20047.  Rationale7.1.  Why Not Just Put Telephone Numbers in SIP URIs?   The "tel" URI describes a service, reaching a telephone number, that   is independent of the means of doing so, be it via a SIP-to-PSTN   gateway, a direct SIP call via E.164 number ("ENUM") translation   [RFC3761], some other signaling protocols such as H.323, or a   traditional circuit-switched call initiated on the client side via,   say, the Telephony Application Programming Interface (TAPI).  Thus,   in spirit, it is closer to the URN schemes that also leave the   resolution to an external mechanism.  The same "tel" URI may get   translated to any number of other URIs in the process of setting up   the call.7.2.  Why Not Distinguish between Call Types?   Signaling protocols such as SIP allow negotiating the call type and   parameters, making the very basic indication within the URI scheme   moot.  Also, since the call type can change frequently, any such   indication in a URI is likely to be out of date.  If such designation   is desired for a device that directly places calls without a   signaling protocol such as SIP, mechanisms such as the "type"   attribute for the "A" element in HTML may be more appropriate.7.3.  Why "tel"?   "tel" was chosen because it is widely recognized that none of the   other suggestions appeared appropriate.  "Callto" was discarded   because URI schemes locate a resource and do not specify an action to   be taken.  "Telephone" and "phone" were considered too long and not   easily recognized internationally.7.4.  Do Not Confuse Numbers with How They Are Dialed   As an example, in many countries the E.164 number "+1-212-555-3141"   will be dialed  as 00-1-212-555-3141, where the leading "00" is a   prefix for international calls.  (In general, a "+" symbol in E.164   indicates that an international prefix is required.)8.  Usage of Telephone URIs in HTML   Links using the "tel" URI SHOULD enclose the telephone number so that   users can easily predict the action taken when following the link   Dial <a href="tel:+1-212-555-0101">+1-212-555-0101</a> for   assistance.Schulzrinne                 Standards Track                    [Page 11]

RFC 3966                      The tel URI                  December 2004   instead of   Dial <a href="tel:+1-212-555-0101">this number</a> for assistance.   On a public HTML page, the telephone number in the URI SHOULD always   be in the global form, even if the text of the link uses some local   format:   Telephone (if dialling in the United States):     <a href="tel:+1-201-555-0111">(201) 555-0111</a>   or even   For having RFCs read aloud, call <a   href="tel:+1-555-438-3732">1-555-IETF-RFC</a>.9.  Use of "tel" URIs with SIP (Informative)   SIP can use the "tel" URI anywhere a URI is allowed, for example as a   Request-URI, along with "sip" and "sips" URIs.  For brevity, we will   imply "sips" URIs when talking about SIP URIs.  Both "tel" and SIP   URIs can contain telephone numbers.  In SIP URIs, they appear as the   user part, i.e., before the @ symbol (section 19.1.6 in [RFC3261]).   Unless a SIP UA connects directly to a PSTN gateway, one of the SIP   proxy servers has to translate the "tel" URI to a SIP URI, with the   host part of that URI pointing to a gateway.  Typically, the outbound   proxy server, as the first proxy server visited by a call request,   performs this translation.  A proxy server can translate all "tel"   URIs to the same SIP host name or select a different gateway for   different "tel" prefixes, based, for example, on information learned   from TRIP [RFC3219].  However, a proxy server could also delegate   this translation task to any other proxy server, as proxy servers are   free to apply whatever routing logic they desire.  For local numbers,   the proxy MUST NOT translate "tel" URIs whose contexts it does not   understand.   As noted earlier, all phone numbers MUST use the global form unless   they cannot be represented as such.  If the local-number format is   used, it MUST be qualified by the 'phone-context' parameter.   Effectively, the combination of local number and phone context makes   the "tel" URI globally unique.   Although web pages, vCard business cards, address books, and   directories can easily contain global "tel" URIs, users on twelve-   button (IP) phones cannot dial such numbers directly and are   typically accustomed to dialling shorter strings, e.g., for PBX   extensions or local numbers.  These so-called dial strings (sectionSchulzrinne                 Standards Track                    [Page 12]

RFC 3966                      The tel URI                  December 2004   1) are not directly represented by "tel" URIs, as noted.  We refer to   the rules that govern the translation of dial strings into SIP and   "tel" URIs, global or local, as the dial plan.  Currently,   translations from dial strings to "tel" URIs have to take place in   end systems.  Future efforts may provide means to carry dial strings   in a SIP URI, for example, but no such mechanisms exist as of this   writing.   A SIP UA can use a dial plan to translate dial strings into SIP or   "tel" URIs.  The dial plan can be manually configured or, preferably,   downloaded as part of a device configuration mechanism.  (At this   time, there is no standardized mechanism for this.)   A mobile user can use at least two dial plans, namely the dial plan   for the network that he is currently visiting and the dial plan for   his home network.  Generally, dialed numbers meant to represent   global numbers will look the same after the translation regardless of   the dial plan, even if, say, the visited network uses '0' for   dialling an 'outside' number and the user's home network uses '9', as   long as the user is aware of the current dial plan.  However, local   extensions without a direct global equivalent may well behave   differently.  To avoid any ambiguity, the dial plan MUST insert a   suitable 'phone-context' string when performing the translation.  If   the 'phone-context' is a domain name, there are three cases:   1.  The outbound proxy recognizes the domain name in the "tel" or SIP       URI as its local context and can route the request to a gateway       that understands the local number.   2.  The outbound proxy does not use the same phone context but can       route to a proxy that handles this phone context.  This routing       can be done via a lookup table, or the domain name of the phone       context might be set up to reflect the SIP domain name of a       suitable proxy.  For example, a proxy may always route calls with       "tel" URIs like          tel:1234;phone-context=munich.example.com       to the SIP proxy located at munich.example.com.  (Proxies       receiving a tel URI with a context they do not understand are       obligated to return a 404 (Not Found) status response so that an       outbound proxy may decide to attempt such a heuristic.)   3.  The outbound proxy does not recognize the phone context and       cannot find the appropriate proxy for that phone context.  In       that case, the translation fails, and the outbound proxy returns       a 404 (Not Found) error response.Schulzrinne                 Standards Track                    [Page 13]

RFC 3966                      The tel URI                  December 200410.  Acknowledgments   This document is derived fromRFC 2806 [RFC2806], written by Antti   Vaehae-Sipilae.  Mark Allman, Flemming Andreasen, Francois Audet,   Lawrence Conroy, Cullen Jennings, Michael Hammer, Paul Kyzivat,   Andrew Main, Xavier Marjou, Jon Peterson, Mike Pierce, Jonathan   Rosenberg, and James Yu provided extensive comments.11.  Security Considerations   The security considerations parallel those for the mailto URL   [RFC2368].   Web clients and similar tools MUST NOT use the "tel" URI to place   telephone calls without the explicit consent of the user of that   client.  Placing calls automatically without appropriate user   confirmation may incur a number of risks, such as those described   below:   o  Calls may incur costs.   o  The URI may be used to place malicious or annoying calls.   o  A call will take the user's phone line off-hook, thus preventing      its use.   o  A call may reveal the user's possibly unlisted phone number to the      remote host in the caller identification data and may allow the      attacker to correlate the user's phone number with other      information, such as an e-mail or IP address.   This is particularly important for "tel" URIs embedded in HTML links,   as a malicious party may hide the true nature of the URI in the link   text, as in   <a href="tel:+1-900-555-0191">Find free information here</a>   <a href="tel:+1-900-555-0191">tel:+1-800-555-0191</a>   "tel" URIs may reveal private information, similar to including phone   numbers as text.  However, the presence of the tel: schema identifier   may make it easier for an adversary using a search engine to discover   these numbers.12.  Changes SinceRFC 2806   The specification is syntactically backwards-compatible with the   "tel" URI defined inRFC 2806 [RFC2806] but has been completely   rewritten.  This document more clearly distinguishes telephone   numbers as identifiers of network termination points from dial   strings and removes the latter from the purview of "tel" URIs.Schulzrinne                 Standards Track                    [Page 14]

RFC 3966                      The tel URI                  December 2004   Compared toRFC 2806, references to carrier selection, dial context,   fax and modem URIs, post-dial strings, and pause characters have been   removed.  The URI syntax now conforms toRFC 2396 [RFC2396].   A section on using "tel" URIs in SIP was added.13.  References13.1.  Normative References   [E.123]    International Telecommunications Union, "Notation for              national and international telephone numbers,  e-mail              addresses and web addresses", Recommendation E.123,              February 2001.   [E.161]    International Telecommunications Union, "Arrangement of              digits, letters and symbols on telephones and other              devices that can be used for gaining access to a telephone              network", Recommendation E.161, May 1995.   [E.164]    International Telecommunications Union, "The international              public telecommunication numbering plan", Recommendation              E.164, May 1997.   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate              Requirement Levels",BCP 14,RFC 2119, March 1997.   [RFC2234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax              Specifications: ABNF",RFC 2234, November 1997.   [RFC3261]  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.   [T1.703]   ANSI, "Allocation of Letters to the Keys of Numeric              Keypads for Telecommunications", Standard T1.703-1995              (R1999), 1999.Schulzrinne                 Standards Track                    [Page 15]

RFC 3966                      The tel URI                  December 200413.2.  Informative References   [RFC2368]  Hoffman, P., Masinter, L., and J. Zawinski, "The mailto              URL scheme",RFC 2368, July 1998.   [RFC2396]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform              Resource Identifiers (URI): Generic Syntax",RFC 2396,              August 1998.   [RFC2806]  Vaha-Sipila, A., "URLs for Telephone Calls",RFC 2806,              April 2000.   [RFC3761]  Faltstrom, P. and M. Mealling, "The E.164 to Uniform              Resource Identifiers (URI) Dynamic Delegation Discovery              System (DDDS) Application (ENUM)",RFC 3761, April 2004.   [RFC3187]  Hakala, J. and H. Walravens, "Using International Standard              Book Numbers as Uniform Resource Names",RFC 3187, October              2001.   [RFC3191]  Allocchio, C., "Minimal GSTN address format in Internet              Mail",RFC 3191, October 2001.   [RFC3192]  Allocchio, C., "Minimal FAX address format in Internet              Mail",RFC 3192, October 2001.   [RFC3219]  Rosenberg, J., Salama, H., and M. Squire, "Telephony              Routing over IP (TRIP)",RFC 3219, January 2002.   [T.50]     International Telecommunications Union, "International              Reference Alphabet (IRA) (Formerly International Alphabet              No. 5 or IA5) - Information technology - 7-bit coded              character set for information interchange", Recommendation              T.50, 1992.Author's Address   Henning Schulzrinne   Columbia University   Department of Computer Science   450 Computer Science Building   New York, NY  10027   US   Phone: +1 212 939 7042   EMail: hgs@cs.columbia.edu   URI:http://www.cs.columbia.eduSchulzrinne                 Standards Track                    [Page 16]

RFC 3966                      The tel URI                  December 2004Full Copyright Statement   Copyright (C) The Internet Society (2004).   This document is subject to the rights, licenses and restrictions   contained inBCP 78, and except as set forth therein, the authors   retain all their rights.   This document and the information contained herein are provided on an   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET   ENGINEERING TASK FORCE DISCLAIM 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.Intellectual Property   The IETF takes no position regarding the validity or scope of any   Intellectual Property Rights 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; nor does it represent that it has   made any independent effort to identify any such rights.  Information   on the IETF's procedures with respect to rights in IETF Documents can   be found inBCP 78 andBCP 79.   Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this   specification can be obtained from the IETF on-line IPR repository athttp://www.ietf.org/ipr.   The IETF invites any interested party to bring to its attention any   copyrights, patents or patent applications, or other proprietary   rights that may cover technology that may be required to implement   this standard.  Please address the information to the IETF at ietf-   ipr@ietf.org.Acknowledgement   Funding for the RFC Editor function is currently provided by the   Internet Society.Schulzrinne                 Standards Track                    [Page 17]