rfc2848.txt

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

Network Working Group                                        S. Petrack
Request for Comments: 2848                                      MetaTel
Category: Standards Track                                     L. Conroy
                                            Siemens Roke Manor Research
                                                              June 2000


                       The PINT Service Protocol:
   Extensions to SIP and SDP for IP Access to Telephone Call Services

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

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

Abstract

   This document contains the specification of the PINT Service Protocol
   1.0, which defines a protocol for invoking certain telephone services
   from an IP network. These services include placing basic calls,
   sending and receiving faxes, and receiving content over the
   telephone. The protocol is specified as a set of enhancements and
   additions to the SIP 2.0 and SDP protocols.

Table of Contents

   1. Introduction .................................................  4
   1.1 Glossary ....................................................  6
   2. PINT Milestone Services ......................................  6
   2.1 Request to Call .............................................  7
   2.2 Request to Fax Content ......................................  7
   2.3 Request to Speak/Send/Play Content ..........................  7
   2.4 Relation between PINT milestone services and traditional
       telephone services ..........................................  7
   3. PINT Functional and Protocol Architecture ....................  8
   3.1. PINT Functional Architecture ...............................  8
   3.2. PINT Protocol Architecture .................................  9
   3.2.1. SDP operation in PINT .................................... 10
   3.2.2. SIP Operation in PINT .................................... 11
   3.3. REQUIRED and OPTIONAL elements for PINT compliance ......... 11
   3.4. PINT Extensions to SDP 2.0 ................................. 12



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


   3.4.1. Network Type "TN" and Address Type "RFC2543" ............. 12
   3.4.2. Support for Data Objects within PINT ..................... 13
   3.4.2.1. Use of fmtp attributes in PINT requests ................ 15
   3.4.2.2. Support for Remote Data Object References in PINT ...... 16
   3.4.2.3. Support for GSTN-based Data Objects in PINT ............ 17
   3.4.2.4. Session Description support for included Data Objects .. 18
   3.4.3. Attribute Tags to pass information into the Telephone
          Network .................................................. 19
   3.4.3.1. The phone-context attribute ............................ 20
   3.4.3.2. Presentation Restriction attribute ..................... 22
   3.4.3.3. ITU-T CalledPartyAddress attributes parameters ......... 23
   3.4.4. The "require" attribute .................................. 24
   3.5. PINT Extensions to SIP 2.0 ................................. 25
   3.5.1. Multi-part MIME (sending data along with SIP request) .... 25
   3.5.2. Warning header ........................................... 27
   3.5.3. Mechanism to register interest in the disposition of a PINT
          service, and to receive indications on that disposition .. 27
   3.5.3.1. Opening a monitoring session with a SUBSCRIBE request .. 28
   3.5.3.2. Sending Status Indications with a NOTIFY request ....... 30
   3.5.3.3. Closing a monitoring session with an UNSUBSCRIBE request 30
   3.5.3.4. Timing of SUBSCRIBE requests ........................... 31
   3.5.4. The "Require:" header for PINT ........................... 32
   3.5.5. PINT URLs within PINT requests ........................... 32
   3.5.5.1. PINT URLS within Request-URIs .......................... 33
   3.5.6. Telephony Network Parameters within PINT URLs ............ 33
   3.5.7. REGISTER requests within PINT ............................ 34
   3.5.8. BYE Requests in PINT ..................................... 35
   4. Examples of PINT Requests and Responses ...................... 37
   4.1. A request to a call center from an anonymous user to receive
        a phone call ............................................... 37
   4.2. A request from a non anonymous customer (John Jones) to
        receive a phone call from a particular sales agent
        (Mary James) ............................................... 37
   4.3. A request to get a fax back ................................ 38
   4.4. A request to have information read out over the phone ...... 39
   4.5. A request to send an included text page to a friend's pager. 39
   4.6. A request to send an image as a fax to phone number
        [phone] ............................................ 40
   4.7. A request to read out over the phone two pieces of content
        in sequence ................................................ 41
   4.8. Request for the prices for ISDN to be sent to my fax
        machine .................................................... 42
   4.9. Request for a callback ..................................... 42
   4.10.Sending a set of information in response to an enquiry ..... 43
   4.11.Sportsline "headlines" message sent to your phone/fax/pager  44
   4.12.Automatically giving someone a fax copy of your phone bill . 45
   5. Security Considerations ...................................... 46
   5.1.  Basic Principles for PINT Use ............................. 46



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


   5.1.1.  Responsibility for service requests ..................... 46
   5.1.2.  Authority to make requests .............................. 47
   5.1.3.  Privacy ................................................. 47
   5.1.4.  Privacy Implications of SUBSCRIBE/NOTIFY ................ 48
   5.2.  Registration Procedures ................................... 49
   5.3.  Security mechanisms and implications on PINT service ...... 50
   5.4.  Summary of Security Implications .......................... 52
   6. Deployment considerations and the Relationship PINT to I.N.
      (Informative) ................................................ 54
   6.1. Web Front End to PINT Infrastructure ....................... 54
   6.2. Redirects to Multiple Gateways ............................. 54
   6.3. Competing PINT Gateways REGISTERing to offer the same
        service .................................................... 55
   6.4. Limitations on Available Information and Request Timing for
        SUBSCRIBE .................................................. 56
   6.5. Parameters needed for invoking traditional GSTN Services
        within PINT................................................. 58
   6.5.1. Service Identifier ....................................... 58
   6.5.2. A and B parties .......................................... 58
   6.5.3. Other Service Parameters ................................. 59
   6.5.4. Service Parameter Summary ................................ 59
   6.6. Parameter Mapping to PINT Extensions........................ 60
   7. References ................................................... 62
   8. Acknowledgements ............................................. 64
   Appendix A: Collected ABNF for PINT Extensions .................. 65
   Appendix B: IANA Considerations ................................. 69
   Authors' Addresses .............................................. 72
   Full Copyright Statement ........................................ 73























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


1. Introduction

   The desire to invoke certain telephone call services from the
   Internet has been identified by many different groups (users, public
   and private network operators, call center service providers,
   equipment vendors, see [7]). The generic scenario is as follows (when
   the invocation is successful):

      1. an IP host sends a request to a server on an IP network;
      2. the server relays the request into a telephone network;
      3. the telephone network performs the requested call service.

   As examples, consider a user who wishes to have a callback placed to
   his/her telephone. It may be that a customer wants someone in the
   support department of some business to call them back. Similarly, a
   user may want to hear some announcement of a weather warning sent
   from a remote automatic weather service in the event of a storm.

   We use the term "PSTN/Internet Interworking (PINT) Service" to denote
   such a complete transaction, starting with the sending of a request
   from an IP client and including the telephone call itself. PINT
   services are distinguished by the fact that they always involve two
   separate networks:

      an IP network to request the placement of a call, and the Global
      Switched Telephone Network (GSTN) to execute the actual call. It
      is understood that Intelligent Network systems, private PBXs,
      cellular phone networks, and the ISDN can all be used to deliver
      PINT services.  Also, the request for service might come from
      within a private IP network that is disconnected from the whole
      Internet.

   The requirements for the PINT protocol were deliberately restricted
   to providing the ability to invoke a small number of fixed telephone
   call services. These "Milestone PINT services" are specified in
   section 2.  Great care has been taken, however, to develop a protocol
   that is aligned with other Internet protocols where possible, so that
   future extensions to PINT could develop along with Internet
   conferencing.

   Within the Internet conference architecture, establishing media calls
   is done via a combination of protocols. SIP [1] is used to establish
   the association between the participants within the call (this
   association between participants within the call is called a
   "session"), and SDP [2] is used to describe the media to be exchanged
   within the session. The PINT protocol uses these two protocols
   together, providing some extensions and enhancements to enable SIP
   clients and servers to become PINT clients and servers.



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


   A PINT user who wishes to invoke a service within the telephone
   network uses SIP to invite a remote PINT server into a session. The
   invitation contains an SDP description of the media session that the
   user would like to take place. This might be a "sending a fax
   session" or a "telephone call session", for example. In a PINT
   service execution session the media is transported over the phone
   system, while in a SIP session the media is normally transported over
   an internet.

   When used to invoke a PINT service, SIP establishes an association
   between a requesting PINT client and the PINT server that is
   responsible for invoking the service within the telephone network.
   These two entities are not the same entities as the telephone network
   entities involved in the telephone network service. The SIP messages
   carry within their SDP payloads a description of the telephone
   network media session.

   Note that the fact that a PINT server accepts an invitation and a
   session is established is no guarantee that the media will be
   successfully transported. (This is analogous to the fact that if a
   SIP invitation is accepted successfully, this is no guarantee against
   a subsequent failure of audio hardware).

   The particular requirements of PINT users lead to some new messages.
   When a PINT server agrees to send a fax to telephone B, it may be
   that the fax transmission fails after part of the fax is sent.
   Therefore, the PINT client may wish to receive information about the
   status of the actual telephone call session that was invoked as a
   result of the established PINT session. Three new requests,
   SUBSCRIBE, UNSUBSCRIBE, and NOTIFY, are added here to vanilla SIP to
   allow this.

   The enhancements and additions specified here are not intended to
   alter the behaviour of baseline SIP or SDP in any way. The purpose of
   PINT extensions is to extend the usual SIP/SDP services to the
   telephone world. Apart from integrating well into existing protocols
   and architectures, and the advantages of reuse, this means that the
   protocol specified here can handle a rather wider class of call
   services than just the Milestone services.

   The rest of this document is organised as follows: Section 2
   describes the PINT Milestone services; section 3 specifies the PINT
   functional and protocol architecture; section 4 gives examples of the
   PINT 1.0 extensions of SIP and SDP; section 5 contains some security
   considerations for PINT. The final section contains descriptions of
   how the PINT protocol may be used to provide service over the GSTN.





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


   For a summary of the extensions to SIP and SDP specified in this
   document, Section 3.2 gives an combined list, plus one each
   describing the extensions to SIP and SDP respectively.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119. In addition,
   the construct "MUST .... OR ...." implies that it is an absolute
   requirement of this specification to implement one of the two
   possibilities stated (represented by dots in the above phrase). An
   implementation MUST be able to interoperate with another