rfc2806.txt

<VC++网络游戏建摸与实现>源代码

   parameters to this URL scheme. See section 2.5.11.

   The <private-prefix>, <token-char> and <quoted-string> nonterminals
   may seem a bit complex at first, but they simply describe the set of
   octets that are legal in those nonterminals. Some octets may have to
   be escaped, see [RFC2396].

2.3 "fax" URL scheme

   The URL syntax is formally described as follows (the definition
   reuses nonterminals from the above definition). For the basis of this
   syntax, see [RFC2303] and [RFC2304].

      fax-url          = fax-scheme ":" fax-subscriber
      fax-scheme       = "fax"
      fax-subscriber   = fax-global-phone / fax-local-phone
      fax-global-phone = "+" base-phone-number [isdn-subaddress]
                         [t33-subaddress] [post-dial]
                         *(area-specifier / service-provider /
                         future-extension)
      fax-local-phone  = 1*(phonedigit / dtmf-digit /
                         pause-character) [isdn-subaddress]
                         [t33-subaddress] [post-dial]
                         area-specifier
                         *(area-specifier / service-provider /
                         future-extension)
      t33-subaddress   = ";tsub=" 1*phonedigit

   The fax: URL is very similar to the tel: URL. The main difference is
   that in addition to ISDN subaddresses, telefaxes also have an another
   type of subaddress, see section 2.5.8.

2.4 "modem" URL scheme

   The URL syntax is formally described as follows (the definition
   reuses nonterminals from the above definitions). For the basis of
   this syntax, see [RFC2303].





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


      modem-url          = modem-scheme ":" remote-host
      modem-scheme       = "modem"
      remote-host        = telephone-subscriber *(modem-params
                           / recommended-params)
      modem-params       = ";type=" data-capabilities
      recommended-params = ";rec=" data-capabilities
      data-capabilities  = accepted-modem ["?" data-bits parity
                           stop-bits]
      accepted-modem     = "V21" / "V22" / "V22b" /
                           "V23" / "V26t" / "V32" /
                           "V32b" / "V34" / "V90" /
                           "V110" / "V120" / "B103" /
                           "B212" / "X75" /
                           "vnd." vendor-name "." modem-type
      data-bits          = "7" / "8"
      parity             = "n" / "e" / "o" / "m" / "s"
      stop-bits          = "1" / "2"
      vendor-name        = 1*(ALPHA / DIGIT / "-" / "+")
      modem-type         = 1*(ALPHA / DIGIT / "-" / "+")

   The modem: URL scheme is also very similar to both the tel: and fax:
   schemes, but it adds the description of the capabilities of the
   remote entity. Minimum required compliance is listed in <modem-
   params> and recommended compliance is listed in <recommended-params>.
   For details, see section 2.5.9.

2.5 Parsing telephone, fax and modem URLs

2.5.1 Call type

   The type of call is specified by the scheme specifier.  "Tel" means
   that a voice call is opened. "Fax" indicates that the call should be
   a facsimile (telefax) call. "Modem" means that it should be a data
   call. Not all networks differentiate between the types of call; in
   this case, the scheme specifier indicates the telecommunications
   equipment type to use.

2.5.2 Phone numbers and their scope

   <telephone-subscriber> and <fax-subscriber> indicate the phone number
   to be dialed. The phone number can be written in either international
   or local notation. All phone numbers SHOULD always be written in the
   international form if there is no good reason to use the local form.

   Not all numbers are valid within all numbering areas. The <area-
   specifier> parameter, which is mandatory for local numbers, is used
   to indicate the locale within which this number is valid, or to
   qualify the phone number so that it may be used unambiguously. The



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


   <area-specifier> can take three forms: <global-network-prefix>,
   <local-network-prefix> or <private-prefix>. These are used to
   describe the validity area of the phone number either in global
   numbering plan, local numbering plan, or in a private numbering plan,
   respectively.

   If <area-specifier> is present, the local entity MUST NOT attempt to
   call out using the phone number if it cannot originate the call
   within the specified locale. If a <local-phone-number> is used, an
   <area-specifier> MUST be included as well.

   There can be multiple instances of <area-specifier>. In this case,
   the number is valid in all of the given numbering areas.

   The global prefix form is intended to act as the outermost context
   for a phone number, so it will start with a "+", followed by some
   part of an E.164 number. It also specifies the region in which the
   phone number is valid. For example, if <global-network-prefix> is
   "+358", the given number is valid only within Finland (country code
   358) - even if it is a <global-phone-number>.

   The local prefix form is intended to act as an intermediate context
   in those situations where the outermost context for a phone number is
   given by another means. One example of use is where the local entity
   is known to originate calls only within the North American Number
   Plan Area, so an "outermost" phone context can be assumed. The local
   context could, for example, be used to indicate the area code within
   which an associated phone number is situated. Thus "tel:456-
   7890;phone-context=213" would suffice to deliver a call to the
   telephone number "[phone]". Note that the version including
   the <phone-context> implies further that the call can only be
   originated within the "area code 213" region.

   The <private-prefix> form is intended for use in those situations
   where the context cannot be expressed with a start of a global phone
   number or a dialing string. The <private-prefix> is actually a name
   of a private context. The creator of the URL and the local entity
   have been configured to recognize this name, and as such they can
   interpret the number and know how they can utilize the number. For
   example, a private network numbering plan may be indicated by the
   name "X-COMPANY-NET", but the private dialling plan from the locales
   of the sender of the telephony URL and the local entity are
   different. The syntax of these tokens will be left for future
   specification. The ABNF above specifies the accepted characters that
   can be a part of <private-prefix>.






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


   Unless the sender is absolutely sure that they share the same private
   network access digit string with the local entity, then they MUST NOT
   use a dialling plan number (a local phone number, or one qualified by
   a local context), as the result may be incorrect. Instead, they
   SHOULD use a global number, or if that is not possible, a private
   context as the last resort. If the local entity does not support
   dialling into the private network indicated by that context, then the
   request MUST be rejected. If it does, then it will use the access
   digit string appropriate for its locale.

   Note that the use of <area-specifier> is orthogonal to use of the
   telephony service provider parameter (see 2.5.10); it qualifies the
   phone number, whilst the <service-provider> parameter indicates the
   carrier to be used for the call attempt.

   For example, a large company may have private network
   interconnections between its sites, as well as connections to the
   Global Switched Telephone Network. A phone number may be given in
   "public network" form, but with a <service-provider> indicating that
   the call should be carried over the corporate network.

   Conversely, it would be possible to represent a phone number in
   private network form, with a private context to indicate this, but
   indicate a public telephony service provider. This would request that
   the user agent convert the private network number plan address into a
   form that can be carried using the selected service provider.

   Any telephone number MUST contain at least one <phonedigit> or
   <dtmf-digit>, that is, subscriber numbers consisting only of pause
   characters are not allowed.

   International numbers MUST begin with the "+" character. Local
   numbers MUST NOT contain that character. International numbers MUST
   be written with the country (CC) and national (NSN) numbers as
   specified in [E.123] and [E.164]. International numbers have the
   property of being totally unambiguous everywhere in the world if the
   local entity is properly configured.

   Local numbers MAY be used if the number only works from inside a
   certain geographical area or a network. Note that some numbers may
   work from several networks but not from the whole world - these
   SHOULD be written in international form, with a set of <area-
   specifier> tags and optional <service-provider> parameters. URLs
   containing local phone numbers should only appear in an environment
   where all local entities can get the call successfully set up by
   passing the number to the dialing entity "as is". An example could be
   a company intranet, where all local entities are located under a the
   same private telephone exchange. If local phone numbers are used,



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


   the document in which they are present SHOULD contain an indication
   of the context in which they are intended to be used, and an
   appropriate <area-specifier> SHOULD be present in the URL.

   In some regions, it is popular to write phone numbers using
   alphabetic characters which correspond to certain numbers on the
   telephone keypad.  Letters in <dtmf-digit> characters do not have
   anything to do with this, nor is this method supported by these URL
   schemes.

   It should also be noted that implementations MUST NOT assume that
   telephone numbers have a maximum, minimum or fixed length, or that
   they would always begin with a certain number.  Implementors are
   encouraged to familiarize themselves with the international
   standards.

2.5.3 Separators in phone numbers

   All <visual-separator> characters MUST be ignored by the local entity
   when using the URL. These characters are present only to aid
   readability: they MUST NOT have any other meaning. Note that although
   [E.123] recommends the use of space (SP) characters as the separators
   in printed telephone numbers, spaces MUST NOT be used in phone
   numbers in URLs as the space character cannot be used in URLs without
   escaping it.

2.5.4 Converting the number to the local numbering scheme

   After the telephone number has been extracted, it can be converted to
   the local dialing convention. (For example, the "+" character might
   be replaced by the international call prefix, or the international
   and trunk prefixes might be removed to place a local call.) Numbers
   that have been specified using <local-phone> or <fax-local-phone>
   MUST be used by the local entity "as is", without any conversions,
   unless the local entity decides to utilize the information in an
   optional <service-provider> parameter.

2.5.5 Sending post-dial sequence after call setup

   The number may contain a <post-dial> sequence, which MUST be dialled
   using Dual Tone Multifrequency (DTMF) in-band signalling or pulse
   dialing after the call setup is complete. If the user agent does not
   support DTMF or pulse dialing after the call has been set up, <post-
   dial> MUST be ignored. In that case, the user SHOULD be notified.







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


2.5.6 Pauses in dialing and post-dial sequence

   A local phone number or a post-dial sequence may contain <pause-
   character> characters which indicate a pause while dialing ("p"), or
   a wait for dial tone ("w").

   Local entities MAY support this method of dialing, and the final
   interpretation of these characters is left to the local entity.  It
   is RECOMMENDED that the length of each pause is about one second.

   If it is not supported, local entities MUST ignore everything in the
   dial string after the first <pause-character> 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 and these characters are present in the
   URL.

   Any <dtmf-digit> characters and all dial string characters after the
   first <pause-character> or <dtmf-digit> SHOULD be sent to line using
   DTMF (Dual Tone Multifrequency) in-band signaling, even if dialing is
   done using direct network signaling (a digital subscriber loop or a
   mobile phone). If the local infrastructure does not support DTMF
   codes, the local entity MAY opt to use pulse dialing. However, it
   should be noted that certain services which are controlled using DTMF
   tones cannot be controlled with pulse dialing. If pulse dialing is