RFC 3966:The tel URI for Telephone Numbers
RFC-Ref

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

      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.

   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 3191draft [RFC3191] and RFC 3192draft [RFC3192].  However, the syntax
   differs as this document describes URIs whereas RFC 3191draft and RFC 3192draft
   specify electronic mail addresses.  RFC 3191draft and RFC 3192draft 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 obsoletes RFC 2806(-> 3966prop).



Google
Web
RFC-Ref