Internet DRAFT - draft-antti-rfc2806bis

draft-antti-rfc2806bis









Internet Engineering Task Force
Internet Draft                             H. Schulzrinne/A. Vaha-Sipila
                                                       Columbia U./Nokia
draft-antti-rfc2806bis-08.txt
February 19, 2003
Expires: June 2003


                    The tel URI for Telephone Calls

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

   To view the list Internet-Draft Shadow Directories, see
   http://www.ietf.org/shadow.html.





















H. Schulzrinne/A. Vaha-Sipila                                 [Page 1]

Internet Draft                The tel URI              February 19, 2003


Abstract

   This document specifies the URI (Uniform Resource Identifier) scheme
   "tel". The "tel" URI describes resources identified by telephone
   numbers.


1 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 in RFC 2119 [1] and
   indicate requirement levels for compliant implementations.

2 Introduction

   This document defines the URI scheme "tel". The "tel" URI describes    |
   resources identified by telephone numbers. A telephone number is "a    |
   string of decimal digits that uniquely indicates the public network    |
   termination point. The number contains the information necessary to    |
   route the call to this termination point." [4]                         |

   The "tel" URI telephone number is not restricted in the type of        |
   termination point it refers to. The termination point can be in the    |
   public telephone network, a private circuit-switched network or the    |
   Internet. The termination point can be a mobile terminal or a          |
   landline circuit. The terminal addressed can support voice, data or    |
   fax. The URI can refer to originators or targets of a telephone call.  |

   The "tel" URI is an identifier only; it does not describe the steps    |
   necessary to reach a particular number and does not imply dialing      |
   semantics.

   Telephone numbers as commonly understood actually comprise two
   related, but distinct concepts: as a canonical address-of-record and
   as 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 public network termination point.
             Generally, these numbers follow the rules in E.164 [4].
             Subscribers publish such identifiers phone number as a
             universal means of being reached, independent of the
             location of the caller. (Naturally, not all numbers are
             reachable from everywhere, for a variety of technical and
             local policy reasons.)

        Dial string: "Dial strings" are the actual numbers, symbols and



H. Schulzrinne/A. Vaha-Sipila                                 [Page 2]

Internet Draft                The tel URI              February 19, 2003


             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 a telephone number so that
             a call can be routed. Dial-strings may require pre-pended
             digits to handle local PBXs, and they may include post-dial
             DTMF signaling that could control an IVR or reach an
             extension. Dial strings are beyond the scope of this
             document.

   To reach a telephone number from a particular terminal, the user of
   the terminal or the terminal itself has to know how to convert that
   the telephone number as identifier into a dial string appropriate for
   that terminal. The telephone number itself does not convey what needs
   to be done for a particular terminal. Instructions may include
   dialing "9" before placing a call or prepending a "00" to reach a
   number in a foreign country. The terminal may also need to strip area
   and country codes.

   The notation for phone numbers in this document is similar to that in
   RFC 3191 [5] and RFC 3192 [6].  However, the syntax differs since
   this document describes URIs whereas RFC 3191 and RFC 3192 specify
   electronic mail addresses. RFC 3191 and RFC 3192 use "/" to indicate
   parameters (qualifiers). Since URI 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 [7].

   There are at least two ways one can envision making a telephone
   connection. In the first approach, a URI contains the dial string,
   which is then passed to an entity that can reproduce the actions
   specified in the dial string, by sending DTMF digits, waiting for
   dial tone, pausing and generating post-dial DTMF digits after the
   callee picks up. Another approach has the URI specify the telephone
   number, which can be either globally unique or only be valid within a
   local context. A dialer 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 dialing is
   needed and what tones indicate call progress. The dialer then
   converts the telephone number into a dial string and performs the
   necessary signaling actions. The document below assumes the second
   model. 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.

   The approach pursued here has the disadvantage that certain services,
   such as extensions on a PBX (when direct inward dialing is not used)
   or electronic banking, cannot be specified in a URI.




H. Schulzrinne/A. Vaha-Sipila                                 [Page 3]

Internet Draft                The tel URI              February 19, 2003


   The URI can be used as a request URI in SIP [7] 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 use this URI
   for both query-based and prefix-based applications.

   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.

2.1 Resolution

   TBD

3 URI Syntax

   The URI is defined using the ABNF (augmented Backus-Naur form)
   described in RFC 2234 [2] and uses elements from the core definitions
   (Appendix A of RFC 2234).

   The syntax definition follows RFC 2396 [3], indicating the actual
   characters contained in the URI. Note that the reserved characters
   "+", ";", "=", and "?" MUST NOT be escaped if shown in the grammar
   definitions below as they are delimiters for the "tel" URI scheme.
   These reserved characters MUST be escaped if they appear in parameter
   values.

   Characters other than those in the "reserved" and "unsafe" sets (see
   RFC 2396 [3]) are equivalent to their "% HEX HEX" encoding.

   The "tel" URI has the following syntax:



        telephone-uri         =  "tel:" subscriber                              |
        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) |
        descriptor            =  domainname / global-number-digits              |
        global-number-digits  =  "+" 1*phonedigit                               |
        local-number-digits   =  1*phonedigit-hex                               |
        domainname            =  *( domainlabel "." ) toplabel [ "." ]          |
        domainlabel           =  alphanum                                       |



H. Schulzrinne/A. Vaha-Sipila                                 [Page 4]

Internet Draft                The tel URI              February 19, 2003


                                 / alphanum *( alphanum / "-" ) alphanum        |
        toplabel              =  ALPHA / ALPHA *( alphanum / "-" ) alphanum     |
        parameter             =  ";" pname ["=" pvalue ]                        |
        pname                 =  1*( alphanum / "-" )                           |
        pvalue                =  1*paramchar                                    |
        paramchar             =  param-unreserved / unreserved / escaped        |
        unreserved            =  alphanum / mark                                |
        escaped               =  "%" HEXDIG HEXDIG                              |
        param-unreserved      =  "[" / "]" / "/" / ":" / "&" / "+" / "$"        |
        phonedigit            =  DIGIT [ visual-separator ]                     |
        phonedigit-hex        =  HEXDIG [ visual-separator ]                    |
        visual-separator      =  "-" / "." / "(" / ")"                          |
        alphanum              =  ALPHA / DIGIT                                  |


   Each parameter name ("pname"), the ISDN subaddress, the extension and
   the context MUST NOT appear more than once. The order of the URL
   parameters is immaterial. The ISDN subaddress or extension SHOULD
   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 [7].

4 URI Comparisons

   Two "tel" URIs are equivalent according to the following rules:

        o URI are not equal if one is a <local-number> and the other a
          <global-number>.

        o For mandatory extension parameters and the <phone-context> and
          <extension> parameters defined in this document, <phone-
          number> parameter values are compared digit-by-digit after
          removing all <visual-separator>s from consideration.

        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 since
   tel URIs may be used within contexts where comparisons are case-
   sensitive.

        Section 19.1.4 in the SIP specification [7] discusses one
        such case.



H. Schulzrinne/A. Vaha-Sipila                                 [Page 5]

Internet Draft                The tel URI              February 19, 2003


5 Phone Numbers and Their Context

5.1 Phone Numbers

   The <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.4).

   Implementations MUST NOT assume that telephone numbers have a
   maximum, minimum or fixed length, or that they always begin with a
   certain number.


        E.164 limits numbers to 15 digits. For geographic numbers,
        one to three digits are the country code, with the
        remainder divided into area or city code (national
        destination code) and subscriber number. Alternatively,
        there is a global three-digit service code, followed by a
        global subscriber number of up to 12 digits. Finally, a
        "international public telecommunication number for networks
        is composed of decimal digits arranged in three code
        fields. The code fields are the 3-digit shared Country Code
        (CC) field, the IC field, which varies in length between 1
        to 4 digits, and the Subscriber Number (SN) which can be up
        to 15 minus the number of digits in the CC and IC fields."
        [4]

5.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.


        Despite complicating comparisons, this specification
        retains the visual separators to follow the spirit of RFC
        2396 [3], 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 in RFC 3187 [8] use visual
        separators in a manner similar to this specification.




H. Schulzrinne/A. Vaha-Sipila                                 [Page 6]

Internet Draft                The tel URI              February 19, 2003


        Even though ITU-T E.123 [9] recommends the use of space
        characters as visual separators in printed telephone
        numbers, "tel" URIs cannot use spaces to avoid excessive
        escaping.

5.1.2 Alphabetic Characters

   In some countries, it is popular to write phone numbers using
   alphabetic characters which correspond to certain numbers on the
   telephone keypad.  The URI format does not support this notation
   since the mapping from alphabetic characters to digits is not
   completely uniform internationally, although there are standards
   [10,11] addressing this issue.

   Since called and calling terminal numbers (TNs) are encoded in BCD in
   ISUP, this allows for six additional values per digit, sometimes
   represented as the hexadecimal characters A through F. However, in
   accordance with E.164, they may not be included in global numbers.
   Their use in local numbers is not defined, but is not prohibited.

5.1.3 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 and E.164 [9,4].  Globally unique
   numbers have the property of being unambiguous everywhere in the
   world and are RECOMMENDED.


5.1.4 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 dialing software. Digits  |
   needed for accessing an outside line, for example, are not included    |
   in local numbers. Local numbers SHOULD NOT be used.                    |


        Local numbers require that the originator and recipient are  |
        configured appropriately, so that they can insert and        |
        recognize the correct descriptors. Since there is no         |
        algorithm to independently pick the same descriptor,         |
        labeling numbers with their context increases the chances    |
        of mis-configuration, so that valid identifiers are          |
        rejected by mistake. The algorithm to select descriptors     |



H. Schulzrinne/A. Vaha-Sipila                                 [Page 7]

Internet Draft                The tel URI              February 19, 2003


        was chosen that accidental collisions should 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               |
   unambiguously identify the local context within which the number is    |
   unique. Thus, the combination of any one of the descriptors in the     |
   phone-context parameter and local number is again globally unique.     |
   The parameter value is defined by the assignee of the local number.    |
   The parameter can contain a list of contexts that enumerate all the    |
   contexts where this number is unique. 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 matching these initial digits must   |
   be assigned to the same organization that is describing the context    |
   and no such matching number can be used by any other organization. If  |
   such an initial 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-939-7000 through +1-212-939-7199. +1-212-939-7 would not be a   |
   valid global number context, but +1-212-939-7000 would work.)          |

   It is not required that numbers within the context actually begin      |
   with the chosen set of initial numbers.                                |

   For a local number defined within a PBX, the organization can choose   |
   any number under its control to identify the context. For example, a   |
   context consisting of any of the organization's global numbers may be  |
   suitable, or a substring that is completely occupied by the            |
   organization. For example, +49-6151-16 would be a suitable context     |
   for the TU Darmstadt, as it uses all numbers starting with those       |
   digits.                                                                |

   For example, ";phone-context=+31,+49" indicates that the number is     |
   valid in country codes 31 (Holland) and 49 (Germany).                  |



H. Schulzrinne/A. Vaha-Sipila                                 [Page 8]

Internet Draft                The tel URI              February 19, 2003


   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 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 the URI 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 verify that it is within the same context as one of the
   descriptors. If it is not within the same context, it MUST NOT
   initiate the call and treat the URI like an invalid destination.

5.2 ISDN Subaddresses

   A phone number MAY also contain an <isdn-subaddress> parameter which
   indicates an ISDN subaddress.

   ISDN subaddresses typically contain IA5 characters, but may contain
   any octet value.


5.3 Extensions                                                            |




H. Schulzrinne/A. Vaha-Sipila                                 [Page 9]

Internet Draft                The tel URI              February 19, 2003


   Extensions identify stations behind a PBX and are 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 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. An implementation 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.

   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.

   All new parameters MUST be registered with IANA.

6 Examples

        tel:+358-555-1234567

             This URI points to a phone number in Finland. The hyphens
             are included to make the number more human-readable; they
             separate country, area codes and subscriber number.

        tel:7042;phone-context=cs.columbia.edu

             The URI describes a local phone number valid within the
             context "cs.columbia.edu".

        tel:863-1234;phone-context=+1-914-784

             The URI describes a local phone number that is valid within
             a particular phone prefix.

7 Rationale

7.1 Why Not Just Put Telephone Numbers in SIP URIs?

   The "tel" URI describes a service, reaching a telephone number, that



H. Schulzrinne/A. Vaha-Sipila                                [Page 10]

Internet Draft                The tel URI              February 19, 2003


   is independent of the means of doing so, be it via a SIP-to-PSTN
   gateway, a direct SIP call via ENUM translation, some other signaling
   protocols such as H.323 or a traditional circuit-switched call
   initiated on the client side via, say, TAPI. It is thus, in spirit,
   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 to negotiate the call type and
   parameters, making the very basic indication within the URL 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 since it is widely recognized none of the other
   suggestions appeared appropriate. "Callto" was discarded since URI
   schemes locate a resource and do not specify an action to be taken.
   "Telephone" and "phone" were considered too long and not as
   internationally recognized.

7.4 Do Not Confuse Numbers with How They Are Dialed

   As an example, the E.164 number "+1-212-555-3141" will be dialed in
   many countries as 00-1-212-555-3141, where the leading "00" is a
   prefix for international calls. (In general, "+" in E.164 indicates
   that an international prefix is required.) Tel URIs MUST NOT contain
   the local dialing prefixes in numbers such as +1-212-555-3141, as the
   transformation back to an international number is not guaranteed to
   be correct or unique.

   If a network entity receives a "tel" URI containing a local number,
   it MUST make sure that it knows the context in which the local phone
   number is to be processed, or else the number MUST NOT be used.
   Equally, the originator of a "tel" URI must take into consideration
   that the recipient may have insufficient information about the phone
   number's context.

8 Usage of Telephone URIs in HTML

   Links using the "tel" URL SHOULD enclose the telephone number, so
   that users can easily predict the action taken when following the
   link.



H. Schulzrinne/A. Vaha-Sipila                                [Page 11]

Internet Draft                The tel URI              February 19, 2003


     Dial <a href="tel:+3585551234567">+358-555-1234567</a> for assistance.


   instead of

     Dial <a href="tel:+3585551234567">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 dialing in Finland):
       <a href="tel:+3585551234567">(0555) 1234567</a>



   or even


     For having RFCs read aloud, call
     <a href="tel:+1-555-438-3732">1-555-IETF-RFC</a>.



9 IANA Considerations

   "Tel" URI parameters (<parameter>) MUST be registered with IANA.
   Mandatory parameters must be described in a standards-track RFC,
   while an informational RFC is sufficient for other parameters.

   The registration must indicate:

        o the parameter name;

        o a description of its applicability;

        o whether the parameter is mandatory or not ( Only the names of
          mandatory parameters must start with "m-" as described in
          Section 5.4.);

        o restrictions on the syntax of the parameter value in ABNF
          form;

        o a reference to the specification that defines it.




H. Schulzrinne/A. Vaha-Sipila                                [Page 12]

Internet Draft                The tel URI              February 19, 2003


10 Security Considerations

   The security considerations parallel those for the mailto URL [12].

   A recipient of a "tel" URI SHOULD NOT place calls without the consent
   of its owner. 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 the e-mail or IP address.

        o A call may use the same local number in different contexts, in
          which the number may have a different meaning.

A Use of "tel" URIs with SIP (Informative)

   SIP can use the "tel" URI 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., in front of the @
   symbol. While

   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.
   However, a proxy server could also delegate this translation task to
   any other proxy server since proxy servers are free to apply whatever
   routing logic they desire.

   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.



H. Schulzrinne/A. Vaha-Sipila                                [Page 13]

Internet Draft                The tel URI              February 19, 2003


   While 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 dialing shorter strings, e.g., for PBX extensions or local
   numbers.  These so-called dial-strings (Section refsec:intro) are not
   directly represented by tel URIs, as noted. We refer to the
   translation of dial strings into SIP and tel URIs, global or local,
   as the dial plan.  There are at least two appropriate ways to deal
   with dial strings in SIP terminals:

        Local translation: 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, be 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 the user's home network. Generally,
             dialed numbers that are 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
             dialing 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 that do not have 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 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 that receive a tel URI with a context they do



H. Schulzrinne/A. Vaha-Sipila                                [Page 14]

Internet Draft                The tel URI              February 19, 2003


                  not understand are obligated to return a 404 (Not
                  Found) status resonse, 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
                  cognizant of that phone context. In that case, the
                  translation fails and the outbound proxy returns a 404
                  (Not Found) error response.

        Proxy translation: In proxy translation mode, the SIP UA simply
             turns the dialed digits into the user part of the SIP URI
             and appends a ;user=phone parameter. The host name or IP
             address of the outbound proxy becomes the host part of the
             SIP request URI. The outbound proxy can then apply its
             local dial plan to translate the SIP URI into a tel URI or
             other SIP URI. Translation into a tel URI makes sense only
             if the proxy wants to delegate finding the PSTN gateway to
             another proxy.

B Change History

B.1 Changes Since -07

        o Added section on using tel URIs in SIP.

B.2 Changes Since -06

        o Clarified semantics.

        o Removed context from freephone numbers.

        o Added phone extensions.

B.3 Changes Since -05

        o URI comparisons are case-insensitive.

        o Specified recommended order of parameters to simplify use
          within SIP URIs.

B.4 Changes Since -04

        o ISDN subaddresses can contain any IA5 character or even binary
          data; represented now as "uric".

B.5 Changes Since -03




H. Schulzrinne/A. Vaha-Sipila                                [Page 15]

Internet Draft                The tel URI              February 19, 2003


        o Clarified use of multiple contexts and how to express this, as
          a comma-separated list.

B.6 Changes Since -02

        o Clarifications and editorial fixes.

        o Now, mandatory parameters are labeled, to avoid making [13]
          obsolete.

B.7 Changes Since -01

   The draft has been greatly simplified to reflect parts that have
   actually been implemented.

        o Removed references to carrier selection.

        o Removed dial context.

        o Removed fax and modem URIs.

        o Removed post-dial strings.

        o Removed pause characters.

B.8 Changes Since RFC 2806

   The specification is backwards-compatible with RFC 2806.

        o Editorial changes and clarifications. The document has been
          shortened and reorganized. Most paragraphs have been rewritten
          to be more concise.

        o Syntax now conforms to RFC 2396 [3], in particular related to
          escaping.

C Acknowledgments

   This document inherits a large amount of text from RFC 2806 [14].
   Flemming Andreasen, Francois Audet, Lawrence Conroy, Andrew Main,
   Michael Hammer, Jon Peterson, Mike Pierce, Jonathan Rosenberg and
   James Yu provided extensive comments.

D References

E Normative References

   [1] S. Bradner, "Key words for use in RFCs to indicate requirement



H. Schulzrinne/A. Vaha-Sipila                                [Page 16]

Internet Draft                The tel URI              February 19, 2003


   levels," RFC 2119, Internet Engineering Task Force, Mar. 1997.

   [2] D. Crocker and P. Overell, eds., "Augmented BNF for syntax
   specifications: ABNF," RFC 2234, Internet Engineering Task Force,
   Nov. 1997.

   [3] T. Berners-Lee, R. Fielding, and L. Masinter, "Uniform resource
   identifiers (URI): generic syntax," RFC 2396, Internet Engineering
   Task Force, Aug. 1998.

F Informative References

   [4] International Telecommunication Union, "The international public
   telecommunication numbering plan," Recommendation E.164,
   Telecommunication Standardization Sector of ITU, Geneva, Switzerland,
   May 1997.

   [5] C. Allocchio, "Minimal GSTN address format in internet mail," RFC
   3191, Internet Engineering Task Force, Oct. 2001.

   [6] C. Allocchio, "Minimal FAX address format in internet mail," RFC
   3192, Internet Engineering Task Force, Oct. 2001.

   [7] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J.
   Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: session
   initiation protocol," RFC 3261, Internet Engineering Task Force, June
   2002.

   [8] J. Hakala and H. Walravens, "Using international standard book
   numbers as uniform resource names," RFC 3187, Internet Engineering
   Task Force, Oct. 2001.

   [9] International Telecommunication Union, "Notation for national and
   international phone numbers," Recommendation E.123, Telecommunication
   Standardization Sector of ITU, Geneva, Switzerland, 1998.

   [10] International Telecommunication 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,
   Telecommunication Standardization Sector of ITU, Geneva, Switzerland,
   May 1995.

   [11] ANSI, "Allocation of letters to the keys of numeric keypads for
   telecommunications," Standard T1.703-1995 (R1999), ANSI, 1999.

   [12] P. Hoffman, L. Masinter, and J. Zawinski, "The mailto URL
   scheme," RFC 2368, Internet Engineering Task Force, July 1998.




H. Schulzrinne/A. Vaha-Sipila                                [Page 17]

Internet Draft                The tel URI              February 19, 2003


   [13] J. Yu, "Extensions to the 'tel' URL to support number
   portability and freephone service," Internet Draft, Internet
   Engineering Task Force, Aug. 2002.  Work in progress.

   [14] A. Vaha-Sipila, "URLs for telephone calls," RFC 2806, Internet
   Engineering Task Force, Apr. 2000.

G Authors' Addresses

   Henning Schulzrinne
   Dept. of Computer Science
   Columbia University
   1214 Amsterdam Avenue
   New York, NY 10027
   USA
   electronic mail: schulzrinne@cs.columbia.edu

   Antti Vaha-Sipila
   (ISO 8859-15 quoted-printable: Antti V=E4h=E4-Sipil=E4)
   Nokia Mobile Phones
   P. O. Box 321
   FIN-00045 Nokia Group
   Finland
   electronic mail: avs@iki.fi, antti.vaha-sipila@nokia.com

H Full Copyright Notice

   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.

   This document and translations of it may be copied and furnished to



H. Schulzrinne/A. Vaha-Sipila                                [Page 18]

Internet Draft                The tel URI              February 19, 2003


   others, and derivative works that comment on or otherwise explain it
   or assist in its implmentation 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 assigns.

   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.





























H. Schulzrinne/A. Vaha-Sipila                                [Page 19]







                           Table of Contents



   1          Terminology .........................................    2
   2          Introduction ........................................    2
   2.1        Resolution ..........................................    4
   3          URI Syntax ..........................................    4
   4          URI Comparisons .....................................    5
   5          Phone Numbers and Their Context .....................    6
   5.1        Phone Numbers .......................................    6
   5.1.1      Separators in Phone Numbers .........................    6
   5.1.2      Alphabetic Characters ...............................    7
   5.1.3      Global Numbers ......................................    7
   5.1.4      Local Numbers .....7.................................    |
   5.2        ISDN Subaddresses ...................................    9
   5.3        Extensions .....9....................................    |
   5.4        Other Parameters ....................................   10
   6          Examples ............................................   10
   7          Rationale ...........................................   10
   7.1        Why Not Just Put Telephone Numbers in SIP URIs?
   ................................................................   10
   7.2        Why Not Distinguish Between Call Types?  ............   11
   7.3        Why "tel"?  .........................................   11
   7.4        Do Not Confuse Numbers with How They Are Dialed .....   11
   8          Usage of Telephone URIs in HTML .....................   11
   9          IANA Considerations .................................   12
   10         Security Considerations .............................   13
   A          Use of "tel" URIs with SIP (Informative) ............   13
   B          Change History ......................................   15
   B.1        Changes Since -07 ...................................   15
   B.2        Changes Since -06 ...................................   15
   B.3        Changes Since -05 ...................................   15
   B.4        Changes Since -04 ...................................   15
   B.5        Changes Since -03 ...................................   15
   B.6        Changes Since -02 ...................................   16
   B.7        Changes Since -01 ...................................   16
   B.8        Changes Since RFC 2806 ..............................   16
   C          Acknowledgments .....................................   16
   D          References ..........................................   16
   E          Normative References ................................   16
   F          Informative References ..............................   17
   G          Authors' Addresses ..................................   18
   H          Full Copyright Notice ...............................   18




H. Schulzrinne/A. Vaha-Sipila                                 [Page 1]