[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (RFC 2806) 00 01 02 03 04 05 06 07 08 09 RFC 3966

Network Working Group                                     H. Schulzrinne
Internet-Draft                                               Columbia U.
Expires: December 25, 2004                                 June 26, 2004


                   The tel URI for Telephone Numbers
                    draft-ietf-iptel-rfc2806bis-09

Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance with
   RFC 3668.

   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 December 25, 2004.

Copyright Notice

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

Abstract

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











Schulzrinne            Expires December 25, 2004                [Page 1]

Internet-Draft                The tel URI                      June 2004


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  URI Syntax . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  URI Comparisons  . . . . . . . . . . . . . . . . . . . . . . .  6
   5.  Phone Numbers and Their Context  . . . . . . . . . . . . . . .  7
     5.1   Phone Numbers  . . . . . . . . . . . . . . . . . . . . . .  7
       5.1.1   Separators in Phone Numbers  . . . . . . . . . . . . .  7
       5.1.2   Alphabetic Characters Corresponding to Digits  . . . .  8
       5.1.3   Alphabetic, * and # Characters as Identifiers  . . . .  8
       5.1.4   Global Numbers . . . . . . . . . . . . . . . . . . . .  8
       5.1.5   Local Numbers  . . . . . . . . . . . . . . . . . . . .  8
     5.2   ISDN Subaddresses  . . . . . . . . . . . . . . . . . . . . 10
     5.3   Phone Extensions . . . . . . . . . . . . . . . . . . . . . 10
     5.4   Other Parameters . . . . . . . . . . . . . . . . . . . . . 10
   6.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
   7.  Rationale  . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     7.1   Why Not Just Put Telephone Numbers in SIP URIs?  . . . . . 11
     7.2   Why Not Distinguish Between Call Types?  . . . . . . . . . 12
     7.3   Why tel? . . . . . . . . . . . . . . . . . . . . . . . . . 12
     7.4   Do Not Confuse Numbers with How They Are Dialed  . . . . . 12
   8.  Usage of Telephone URIs in HTML  . . . . . . . . . . . . . . . 12
   9.  Use of "tel" URIs with SIP (Informative) . . . . . . . . . . . 13
   10.   Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . 14
   11.   Security Considerations  . . . . . . . . . . . . . . . . . . 14
   12.   IANA Considerations  . . . . . . . . . . . . . . . . . . . . 15
   13.   Changes Since RFC 2806 . . . . . . . . . . . . . . . . . . . 15
   14.   References . . . . . . . . . . . . . . . . . . . . . . . . . 15
   14.1  Normative References . . . . . . . . . . . . . . . . . . . . 15
   14.2  Informative References . . . . . . . . . . . . . . . . . . . 16
       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 17
       Intellectual Property and Copyright Statements . . . . . . . . 18


















Schulzrinne            Expires December 25, 2004                [Page 2]

Internet-Draft                The tel URI                      June 2004


1.  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 network
   termination point.  The number contains the information necessary to
   route the call to this termination point.  (This definition is
   derived from [E.164], but encompasses both public and private
   numbers.)

   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 telephone network or the
   Internet. The termination point 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 dialing semantics. Furthermore, it does not refer to a
   specific physical device, only to a telephone number.

   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
      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 such identifiers 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.
      Also, a single termination point may be reachable from different
      networks and may have multiple such 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 of the
      previous paragraph so that a call can be routed.  Dial-strings may
      require pre-pended digits to egress the private branch exchange
      (PBX) the end system is connected to, and they may include



Schulzrinne            Expires December 25, 2004                [Page 3]

Internet-Draft                The tel URI                      June 2004


      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 receiving 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 be
   valid within a local context.  The dialing 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 dialing
   application then converts the telephone number into a dial sequence
   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.

   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 dialing "9" before
   placing a call or prepending a "00" to reach a number in a foreign
   country.  The phone may also need to strip area and country codes.

   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 in
   RFC 3191 [RFC3191] and RFC 3192 [RFC3192].  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 [RFC3261].




Schulzrinne            Expires December 25, 2004                [Page 4]

Internet-Draft                The tel URI                      June 2004


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

   This document obsoletes RFC 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 in BCP 14, RFC 2119
   [RFC2119] and indicate requirement levels for compliant
   implementations.

3.  URI Syntax

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

   The syntax definition follows RFC 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 percent-encoded.  These characters MUST
   be percent-encoded if they appear in parameter values.

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

   The "tel" URI has the following syntax:













Schulzrinne            Expires December 25, 2004                [Page 5]

Internet-Draft                The tel URI                      June 2004


   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 = "+" 1*phonedigit
   local-number-digits  = 1*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].

4.  URI Comparisons

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

   o  Both must be either a 'local-number' or both must be a
      'global-number', i.e., start with a '+'.




Schulzrinne            Expires December 25, 2004                [Page 6]

Internet-Draft                The tel URI                      June 2004


   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 since
   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 Context

5.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 a or
   contain certain digits.

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.

   Although it complicates comparisons, this specification retains
   visual separators, in order to follow the spirit of RFC 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



Schulzrinne            Expires December 25, 2004                [Page 7]

Internet-Draft                The tel URI                      June 2004


   consists of meaningful components." Also, ISBN URNs documented in RFC
   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 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
   [E.161][T1.703] addressing this issue.

5.1.3  Alphabetic, * and # Characters as Identifiers

   Since 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, they 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 have the property of being unambiguous
   everywhere in the world and SHOULD be used.

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




Schulzrinne            Expires December 25, 2004                [Page 8]

Internet-Draft                The tel URI                      June 2004


   There are several reason why 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 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 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 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.
   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 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-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



Schulzrinne            Expires December 25, 2004                [Page 9]

Internet-Draft                The tel URI                      June 2004


   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 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 which
   indicates an ISDN subaddress.

   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
   roughly equivalent in functionality 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



Schulzrinne            Expires December 25, 2004               [Page 10]

Internet-Draft                The tel URI                      June 2004


   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, "isub"
   and "ext" are optional.

   New mandatory parameters must be described in a standards-track RFC,
   while 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 codes 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.

7.  Rationale

7.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
   [RFC2916], 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). 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.





Schulzrinne            Expires December 25, 2004               [Page 11]

Internet-Draft                The tel URI                      June 2004


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

   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 dialing in the United States):
     <a href="tel:+1-201-555-0111">(201) 555-0111</a>

   or even




Schulzrinne            Expires December 25, 2004               [Page 12]

Internet-Draft                The tel URI                      June 2004


   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 since proxy servers
   are free to apply whatever routing logic they desire.  For local
   numbers, the proxy MUST NOT translate "tel" URIs whose context 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.

   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 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 at the time of 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,
   be downloaded as part of a device configuration mechanism.  (At this
   time, there is no standardized mechanism for this.)




Schulzrinne            Expires December 25, 2004               [Page 13]

Internet-Draft                The tel URI                      June 2004


   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 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 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 that
       receive a tel URI with a context they do 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.

10.  Acknowledgments

   This document is derived from RFC 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



Schulzrinne            Expires December 25, 2004               [Page 14]

Internet-Draft                The tel URI                      June 2004


   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 the 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
   such numbers.

12.  IANA Considerations

   This document requires no IANA actions.

13.  Changes Since RFC 2806

   The specification is syntactically backwards-compatible with the
   "tel" URI defined in RFC 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.
   Compared to RFC 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 to RFC 2396 [RFC2396].

   A section on using "tel" URIs in SIP was added.

14.  References

14.1  Normative References

   [E.123]    International Telecommunications Union, "Notation for
              national and international telephone numbers,  e-mail



Schulzrinne            Expires December 25, 2004               [Page 15]

Internet-Draft                The tel URI                      June 2004


              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.

14.2  Informative References

   [I-D.yu-tel-url]
              Yu, J., "New Parameters for the 'tel' URL to Support
              Number Portability and  Freephone Service",
              draft-yu-tel-url-08 (work in progress), November 2003.

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

   [RFC2916]  Faltstrom, P., "E.164 number and DNS", RFC 2916, September
              2000.

   [RFC3187]  Hakala, J. and H. Walravens, "Using International Standard
              Book Numbers as Uniform Resource Names", RFC 3187, October



Schulzrinne            Expires December 25, 2004               [Page 16]

Internet-Draft                The tel URI                      June 2004


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





















Schulzrinne            Expires December 25, 2004               [Page 17]

Internet-Draft                The tel URI                      June 2004


Intellectual Property Statement

   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 in BCP 78 and BCP 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 at
   http://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.


Disclaimer of Validity

   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.


Copyright Statement

   Copyright (C) The Internet Society (2004). This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

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




Schulzrinne            Expires December 25, 2004               [Page 18]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/