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

   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
        +972-9-956-1867 ............................................ 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

   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

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.

   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.

   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
   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:

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

   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).