rfc2806.txt

RFC 的详细文档！

   used, the user SHOULD be notified.

2.5.7 ISDN subaddresses

   A phone number MAY also contain an <isdn-subaddress> which indicates
   an ISDN subaddress. The local entity SHOULD support ISDN
   subaddresses. These addresses are sent to the network by using a
   method available to the local entity (typically, ISDN subscribers
   send the address with the call setup signalling). If ISDN
   subaddressing is not supported by the caller, <isdn-subaddress> MUST
   be ignored and the user SHOULD be notified. The user or the local
   entity MAY opt not to place a call if this feature is not supported.

2.5.8 T.33 subaddresses

   A fax number MAY also contain a <t33-subaddress>, which indicates the
   start of a T.33 subaddress [T.33]. Local entities SHOULD support
   this. Otherwise <t33-subaddress> MUST be ignored and the user SHOULD
   be notified. The user or the local entity MAY opt not to place a call
   if this feature is not supported.







Vaha-Sipila                 Standards Track                    [Page 11]

RFC 2806                URLs for Telephone Calls              April 2000


2.5.9 Data call parameters

   <modem-params> indicate the minimum compliance required from the
   local entity to be able to connect to the remote entity. The minimum
   compliance is defined as being equal to or a superset of the
   capabilities of the listed modem type. There can be several <modem-
   param> parameters, in which case compliance to any one of them will
   be accepted.  <recommended-params> indicates the recommended
   compliance required from the local entity. This is typically the
   fastest and/or the most reliable modem type supported by the modem
   pool. The local entity can use this information to select the best
   number from a group of modem URLs.  There can be several recommended
   modem types, which are equally desirable from the modem pool's point
   of view. <recommended-params> MAY NOT conflict with <modem-params>.
   If they do, the local entity MUST ignore the <recommended-params>.

   The local entity MUST call out using compatible hardware, or request
   that the network provides such a service.

   For example, if the local entity only has access to a V.22bis modem
   and the URL indicates that the minimum acceptable connection is
   V.32bis, the local entity MUST NOT try to connect to the remote host
   since V.22bis is a subset of V.32bis. However, if the URL lists V.32
   as the minimum acceptable connection, the local entity can use
   V.32bis to create a connection since V.32bis is a superset of V.32.

   This feature is present because modem pools often have separate
   numbers for slow modems and fast modems, or have different numbers
   for analog and ISDN connections, or may use proprietary modems that
   are incompatible with standards. It is somewhat analogous to the
   connection type specifier (typecode) in FTP URLs [RFC1738]: it
   provides the local entity with information that can not be deduced
   from the scheme specifier, but is helpful for successful operation.

   This also means that the number of data and stop bits and parity MUST
   be set according to the information given in the URL, or to default
   values given in this document, if the information is not present.

   The capability tokens are listed below. If capabilities suggest that
   it is impossible to create a connection, the connection MUST NOT be
   created.

   If new modem types are standardized by ITU-T, this list can be
   extended with those capability tokens. Tokens are formed by taking
   the number of the standard and joining together the first letter (for
   example, "V"), number (for example, 22) and the first letter of the
   postfix (for example "bis" would become "b").




Vaha-Sipila                 Standards Track                    [Page 12]

RFC 2806                URLs for Telephone Calls              April 2000


   Proprietary modem types MUST be specified using the 'vendor naming
   tree', which takes the form "vnd.x.y", in which "x" is the name of
   the entity from which the specifications for the modem type can be
   acquired and "y" is the type or model of the modem. Vendor names MUST
   share the same name space with vendor names used in MIME types
   [RFC2048]. Submitting the modem types to ietf-types list for review
   is strongly recommended.

   New capabilities MUST always be documented in an RFC, and they MUST
   refer to this document or a newer version of it. The documentation
   SHOULD also list the existing modem types with which the newly
   defined modem type is compatible with.

      Capability              Explanation

      V21                     ITU-T V.21
      V22                     ITU-T V.22
      V22b                    ITU-T V.22bis
      V23                     ITU-T V.23
      V26t                    ITU-T V.26ter
      V32                     ITU-T V.32
      V32b                    ITU-T V.32bis
      V34                     ITU-T V.34
      V90                     ITU-T V.90
      V110                    ITU-T V.110
      V120                    ITU-T V.120
      X75                     ITU-T X.75
      B103                    Bell 103
      B212                    Bell 212
      Data bits: "8" or "7"   The number of data bits. If not
                              specified, defaults to "8".
      Parity: "n", "e", "o",  Parity. None, even, odd, mark or
              "m", "s"        space parity, respectively. If
                              not specified, defaults to "n".
      Stop bits: "1" or "2"   The number of stop bits. If not
                              specified, defaults to "1".

2.5.10 Telephony service provider identification

   It is possible to indicate the identity of the telephony service
   provider for the given phone number. <service-provider> MAY be used
   by the user-agent to place the call using this network, to enhance
   the user interface, for billing estimates or to otherwise optimize
   its functionality. It MAY also be ignored by the user-agent.
   <service-provider> consists of a fully qualified Internet domain name
   of the telephony service provider, for example
   ";tsp=terrifictelecom.com". The syntax of the domain name follows
   Internet domain name rules and is defined in [RFC1035].



Vaha-Sipila                 Standards Track                    [Page 13]

RFC 2806                URLs for Telephone Calls              April 2000


2.5.11 Additional parameters

   In addition to T.33 and ISDN subaddresses, modem types and area
   specifiers, future extensions to this URL scheme may add other
   additional parameters (<future-extension> in the BNF) to these URLs.
   These parameters are added to the URL after a semicolon (";").
   Implementations MUST be prepared to handle additional and/or unknown
   parameters gracefully. Implementations MUST NOT use the URL if it
   contains unknown parameters, as they may be vital for the correct
   interpretation of the URL. Instead, the implementation SHOULD report
   an error.

   For example, <future-extension> 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.  Whenever a
   <future-extension> is used in an open environment, its syntax and
   usage MUST be properly documented in an RFC.

   <future-extension> nonterminal a rephrased version of, and compatible
   with the <other-param> as defined in [RFC2543] (which actually
   borrows BNF from an earlier version of this specification).

2.6 Examples of Use

     tel:[phone]

   This URL points to a phone number in Finland capable of receiving
   voice calls. The hyphens are included to make the number more human-
   readable: country and area codes have been separated from the
   subscriber number.

     fax:[phone]

   The above URL describes a phone number which can receive fax calls.
   It uses dots instead of hyphens as separators, but they have no
   effect on the functionality.

     modem:[phone];type=v32b?7e1;type=v110

   This phone number belongs to an entity which is able to receive data
   calls. The local entity may opt to use either a ITU-T V.32bis modem
   (or a faster one, which is compatible with V.32bis), using settings
   of 7 data bits, even parity and one stop bit, or an ISDN connection
   using ITU-T V.110 protocol.







Vaha-Sipila                 Standards Track                    [Page 14]

RFC 2806                URLs for Telephone Calls              April 2000


     tel:[phone];postd=pp22

   The above URL instructs the local entity to place a voice call to
   [phone], then wait for an implementation-dependent time (for
   example, two seconds) and emit two DTMF dialing tones "2" on the line
   (for example, to choose a particular extension number, or to invoke a
   particular service).

     tel:0w003585551234567;phone-context=[phone]

   This URL places a voice call to the given number. The number format
   is intended for local use: the first zero opens an outside line, the
   "w" character waits for a second dial tone, and the number already
   has the international access code appended to it ("00"). This kind of
   phone number MUST NOT be used in an environment where all users of
   this URL might not be able to successfully dial out by using this
   number directly. However, this might be appropriate for pages in a
   company intranet. The <area-specifier> which is present hints that
   the number is usable only in an environment where the local entity's
   phone number starts with the given string (perhaps singling out a
   company-wide block of telephone numbers).

     tel:[phone];phone-context=+1234;vnd.company.option=foo

   The URL describes a phone number which, even if it is written in its
   international form, is only usable within the numbering area where
   phone numbers start with +1234. There is also a proprietary extension
   "vnd.company.option", which has the value "foo". The meaning of this
   extension is application-specific. Note that the order of these
   parameters (phone-context and vnd.company.option) is irrelevant.

2.7 Rationale behind the syntax

2.7.1 Why distinguish between call types?

   URLs locate resources, which in this case is some telecommunications
   equipment at a given phone number. However, it is not necessarily
   enough to know the subscriber number in order to successfully
   communicate with that equipment. Digital phone networks distinguish
   between voice, fax and data calls (and possibly other types of calls,
   not discussed in this specification). To be able to successfully
   connect to, say, a fax machine, the caller may have to specify that a
   fax call is being made. Otherwise the call might be routed to the
   voice number of the subscriber. In this sense, the call type is an
   integral part of the 'location' of the target resource.






Vaha-Sipila                 Standards Track                    [Page 15]

RFC 2806                URLs for Telephone Calls              April 2000


   The reason to have the call type in the scheme specifier is to make
   the URL simple to remember and use. Making it a parameter, much like
   the way modem parameters are handled now, will substantially reduce
   the human readability of this URL.

2.7.2 Why "tel" is "tel"?

   There has been discussion on whether the scheme name "tel" is
   appropriate. To summarize, these are the points made against the
   other proposals.

      callto      URL schemes locate a resource and do not specify
                  an action to be taken.
      telephone   Too long. Also, "tel" considered to be a more
                  international form.
      phone       Was countered on the basis that "tel" is more
                  internationally acceptable.

2.7.3 Why to use E.164-style numbering?

   E.164 refers to international telephone numbers, and the string of
   digits after the country code is usually a national matter. In any
   case, phone numbers are usually written as a simple string of numbers
   everywhere. Because of this, the syntax in this specification is
   intuitively clear to most people. This is the usual way to write
   phone numbers in business cards, advertisements, telephone books and
   so on.

   It should be noted that phone numbers may have 'hierarchical'
   characteristics, so that one could build a 'forest' of phone numbers
   with country codes as roots, area codes as branches and subscriber
   numbers as leaves. However, this is not always the case. Not all
   areas have area codes; some areas may have different area codes
   depending on how one wants to route the call; some numbers must
   always be dialled "as is", without prepending area or country codes
   (notably emergency numbers); and area codes can and do change.

   Usually, if something has a hierarchical structure, the URL syntax
   should reflect that fact. These URLs are an exception.