rfc2848.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   implementation that chooses either of the two possibilities.

1.1 Glossary

   Requestor - An Internet host from which a request for service
   originates

   PINT Service - A service invoked within a phone system in response to
   a request received from an PINT client.

   PINT Client - An Internet host that sends requests for invocation of
   a PINT Service, in accordance with this document.

   PINT Gateway - An Internet host that accepts requests for PINT
   Service and dispatches them onwards towards a telephone network.

   Executive System - A system that interfaces to a PINT Server and to a
   telephone network that executes a PINT service. It need not be
   directly associated with the Internet, and is represented by the PINT
   Server in transactions with Internet entities.

   Requesting User - The initiator of a request for service. This role
   may be distinct from that of the "party" to any telephone network
   call that results from the request.

   (Service Call) Party - A person who is involved in a telephone
   network call that results from the execution of a PINT service
   request, or a telephone network-based resource that is involved (such
   as an automatic Fax Sender or a Text-to-Speech Unit).

2. PINT Milestone Services

   The original motivation for defining this protocol was the desire to
   invoke the following three telephone network services from within an
   IP network:





Petrack & Conroy            Standards Track                     [Page 6]

RFC 2848               The PINT Service Protocol               June 2000


2.1 Request to Call

   A request is sent from an IP host that causes a phone call to be
   made, connecting party A to some remote party B.

2.2 Request to Fax Content

   A request is sent from an IP host that causes a fax to be sent to fax
   machine B. The request MAY contain a pointer to the fax data (that
   could reside in the IP network or in the Telephone Network), OR the
   fax data itself. The content of the fax MAY be text OR some other
   more general image data. The details of the fax transmission are not
   accessible to the IP network, but remain entirely within the
   telephone network.

   Note that this service does not relate to "Fax over IP": the IP
   network is only used to send the request that a certain fax be sent.
   Of course, it is possible that the resulting telephone network fax
   call happens to use a real-time IP fax solution, but this is
   completely transparent to the PINT transaction.

2.3 Request to Speak/Send/Play Content

   A request is sent from an IP host that causes a phone call to be made
   to user A, and for some sort of content to be spoken out. The request
   MUST EITHER contain a URL pointing to the content, OR include the
   content itself. The content MAY be text OR some other more general
   application data. The details of the content transmission are not
   accessible to the IP network, but remain entirely within the
   telephone network. This service could equally be called "Request to
   Hear Content"; the user's goal is to hear the content spoken to them.
   The mechanism by which the request is formulated is outside the scope
   of this document; however, an example might be that a Web page has a
   button that when pressed causes a PINT request to be passed to the
   PSTN, resulting in the content of the page (or other details) being
   spoken to the person.

2.4 Relation between PINT milestone services and traditional telephone
    services

   There are many different versions and variations of each telephone
   call service invoked by a PINT request. Consider as an example what
   happens when a user requests to call 1-800-2255-287 via the PINT
   Request-to-Call service.

   There may be thousands of agents in the call center, and there may be
   any number of sophisticated algorithms and pieces of equipment that
   are used to decide exactly which agent will return the call. And once



Petrack & Conroy            Standards Track                     [Page 7]

RFC 2848               The PINT Service Protocol               June 2000


   this choice is made, there may be many different ways to set up the
   call: the agent's phone might ring first, and only then the original
   user will be called; or perhaps the user might be called first, and
   hear some horrible music or pre-recorded message while the agent is
   located.

   Similarly, when a PINT request causes a fax to be sent, there are
   hundreds of fax protocol details to be negotiated, as well as
   transmission details within the telephone networks used.

   PINT requests do not specify too precisely the exact telephone-side
   service. Operational details of individual events within the
   telephone network that executes the request are outside the scope of
   PINT. This does not preclude certain high-level details of the
   telephone network session from being expressed within a PINT request.
   For example, it is possible to use the SDP "lang" attribute to
   express a language preference for the Request-to-Hear-Content
   Service.  If a particular PINT system wishes to allow requests to
   contain details of the telephone-network-side service, it uses the
   SDP attribute mechanism (see section 3.4.2).

3. PINT Functional and Protocol Architecture

3.1. PINT Functional Architecture

   Familiarity is assumed with SIP 2.0 [1] and with SDP [2].

   PINT clients and servers are SIP clients and servers. SIP is used to
   carry the request over the IP network to the correct PINT server in a
   secure and reliable manner, and SDP is used to describe the telephone
   network session that is to be invoked or whose status is to be
   returned.

   A PINT system uses SIP proxy servers and redirect servers for their
   usual purpose, but at some point there must be a PINT server with the
   means to relay received requests into a telephone system and to
   receive acknowledgement of these relayed requests. A PINT server with
   this capability is called a "PINT gateway". A PINT gateway appears to
   a SIP system as a User Agent Server. Notice that a PINT gateway
   appears to the PINT infrastructure as if it represents a "user",
   while in fact it really represents an entire telephone network
   infrastructure that can provide a set of telephone network services.









Petrack & Conroy            Standards Track                     [Page 8]

RFC 2848               The PINT Service Protocol               June 2000


   So the PINT system might appear to an individual PINT client as
   follows:

                           /\/\/\/\/\/\/\            /\/\/\/\/\/\/\/\
___________                \          __/___      ___\_             \
|  PINT   |      PINT      \   PINT  | PINT |     |Exec| Telephone  /
| client  |<-------------->|  server |gatewy|=====|Syst| Network    \
|_________|    protocol    /  cloud  |______|     |____|  Cloud     /
                           \            \            /              \
                           /\/\/\/\/\/\/\            \/\/\/\/\/\/\/\/

                 Figure 1: PINT Functional Architecture

   The system of PINT servers is represented as a cloud to emphasise
   that a single PINT request might pass through a series of location
   servers, proxy servers, and redirect servers, before finally reaching
   the correct PINT gateway that can actually process the request by
   passing it to the Telephone Network Cloud.

   The PINT gateway might have a true telephone network interface, or it
   might be connected via some other protocol or API to an "Executive
   System" that is capable of invoking services within the telephone
   cloud.

   As an example, within an I.N. (Intelligent Network) system, the PINT
   gateway might appear to realise the Service Control Gateway Function.
   In an office environment, it might be a server adjunct to the office
   PBX, connected to both the office LAN and the office PBX.

   The Executive System that lies beyond the PINT gateway is outside the
   scope of PINT.

3.2. PINT Protocol Architecture

   This section explains how SIP and SDP work in combination to convey
   the information necessary to invoke telephone network sessions.

   The following list summarises the extension features used in PINT
   1.0.  Following on from this the features are considered separately
   for SDP and then for SIP:

   1)  Telephony URLs in SDP Contact Fields
   2)  Refinement of SIP/SDP Telephony URLs
       *   Inclusion of private dialling plans
   3)  Specification of Telephone Service Provider (TSP) and/or phone-
       context URL-parameters
   4)  Data Objects as session media




Petrack & Conroy            Standards Track                     [Page 9]

RFC 2848               The PINT Service Protocol               June 2000


   4a) Protocol Transport formats to indicate the treatment of the media
       within the GSTN
   5)  Implicit (Indirect) media streams and opaque arguments
   6)  In-line data objects using multipart/mime
   7)  Refinement/Clarification of Opaque arguments passed onwards to
       Executive Systems
       *   Framework for Presentation Restriction Indication
       *   Framework for Q.763 arguments
   8)  An extension mechanism for SDP to specify strictures and force
       failure when a recipient does NOT support the specified
       extensions, using "require" headers.
   9)  Mandatory support for "Warning" headers to give more detailed
       information on request disposition.
   10) Mechanism to register interest in the disposition of a requested
       service, and to receive indications on that disposition.

   Both PINT and SIP rely on features of MIME[4]. The use of SIP 2.0 is
   implied by PINT 1.0, and this also implies compliance with version
   1.0 of MIME.

3.2.1. SDP operation in PINT

   The SDP payload contains a description of the particular telephone
   network session that the requestor wishes to occur in the GSTN. This
   information includes such things as the telephone network address
   (i.e.  the "telephone number") of the terminal(s) involved in the
   call, an indication of the media type to be transported (e.g. audio,
   text, image or application data), and an indication if the
   information is to be transported over the telephone network via
   voice, fax, or pager transport. An indication of the content to be
   sent to the remote telephone terminal (if there is any) is also
   included.

   SDP is flexible enough to convey these parameters independently. For
   example, a request to send some text via voice transport will be
   fulfilled by invoking some text-to-speech-over-the-phone service, and
   a request to send text via fax will be fulfilled by invoking some
   text-to-fax service.

   The following is a list of PINT 1.0 enhancements and additions to
   SDP.

      a. A new network type "TN" and address types "RFC2543" and "X-..."
         (section 3.4.1)
      b. New media types "text", "image", and "application", new
         protocol transport keywords "voice", "fax" and "pager" and the
         associated format types and attribute tags (section 3.4.2)




Petrack & Conroy            Standards Track                    [Page 10]

RFC 2848               The PINT Service Protocol               June 2000


      c. New format specific attributes for included content data
         (section 3.4.2.4)
      d. New attribute tags, used to pass information to the telephone
         network (section 3.4.3)
      e. A new attribute tag "require", used by a client to indicate
         that some attribute is required to be supported in the server
         (section 3.4.4)

3.2.2. SIP Operation in PINT

   SIP is used to carry the request for telephone service from the PINT
   client to the PINT gateway, and may include a telephone number if
   needed for the particular service. The following is a complete list
   of PINT enhancements and additions to SIP:

      f. The multipart MIME payloads (section 3.5.1)
      g. Mandatory support for "Warning:" headers (section 3.5.2)
      h. The SUBSCRIBE and NOTIFY, and UNSUBSCRIBE requests (section
         3.5.3)
      i. Require: headers (section 3.5.4)
      j. A format for PINT URLS within a PINT request (section 3.5.5)
      k. Telephone Network Parameters within PINT URLs (section 3.5.6)

   Section 3.5.8 contains remarks about how BYE requests are used within
   PINT. This is not an extension to baseline SIP; it is included here
   only for clarification of the semantics when used with telephone
   network sessions.