Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 2848

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

Pages: 73
Proposed Standard
Part 1 of 4 – Pages 1 to 8
None   None   Next

Top   ToC   RFC2848 - Page 1
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
Top   ToC   RFC2848 - Page 2
   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
Top   ToC   RFC2848 - Page 3
   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
Top   ToC   RFC2848 - Page 4

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.
Top   ToC   RFC2848 - Page 5
   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.
Top   ToC   RFC2848 - Page 6
   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:
Top   ToC   RFC2848 - Page 7

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
Top   ToC   RFC2848 - Page 8
   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).



(page 8 continued on part 2)

Next Section