GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc2848

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

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
 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
client ←————→ server gatewy=====Syst
_ protocol / cloud | |__

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.

3.3. REQUIRED and OPTIONAL elements for PINT compliance

 Of these, only the TN network type (with its associated RFC2543
 address type) and the "require" attribute MUST be supported by PINT
 1.0 clients and servers. In practice, most PINT service requests will
 use other changes, of which references to Data Objects in requests
 are most likely to appear in PINT requests.
 Each of the other new PINT constructs enables a different function,
 and a client or server that wishes to enable that particular function
 MUST do so by the construct specified in this document. For example,
 building a PINT client and server that provide only the Request-to-
 Call telephone call service, without support for the other Milestone
 services, is allowed.
 The "Require:" SIP header and the "require" attribute provide a
 mechanism that can be used by clients and servers to signal their
 need and/or ability to support specific "new" PINT protocol elements.

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

 It should be noted that many optional features of SIP and SDP make
 sense as specified in the PINT context. One example is the SDP
 a=lang:  attribute, which can be used to describe the preferred
 language of the callee. Another example is the use of the "t="
 parameter to indicate that the time at which the PINT service is to
 be invoked. This is the normal use of the "t=" field. A third example
 is the quality attributes.  Any SIP or SDP option or facility is
 available to PINT clients and servers without change.
 Conversely, support for Data Objects within Internet Conference
 sessions may be useful, even if the aim is not to provide a GSTN
 service request.  In this case, the extensions covering these items
 may be incorporated into an otherwise "plain" SIP/SDP invitation.
 Likewise, support for SDP "require" may be useful, as a framework for
 addition of features to a "traditional" SIP/SDP infrastructure.
 Again, these may be convenient to incorporate into SIP/SDP
 implementations that would not be used for PINT service requests.
 Such additions are beyond the scope of this document, however.

3.4. PINT Extensions to SDP

 PINT 1.0 adds to SDP the possibility to describe audio, fax, and
 pager telephone sessions. It is deliberately designed to hide the
 underlying technical details and complexity of the telephone network.
 The only network type defined for PINT is the generic "TN" (Telephone
 Network).  More precise tags such as "ISDN", "GSM", are not defined.
 Similarly, the transport protocols are designated simply as "fax",
 "voice", and "pager"; there are no more specific identifiers for the
 various telephone network voice, fax, or pager protocols. Similarly,
 the data to be transported are identified only by a MIME content
 type, such as "text" data, "image" data, or some more general
 "application" data. An important example of transporting
 "application" data is the milestone service "Voice Access to Web
 Content". In this case the data to be transported are pointed to by a
 URI, the data content type is application/URI, and the transport
 protocol would be "voice". Some sort of speech-synthesis facility,
 speaking out to a Phone, will have to be invoked to perform this
 service.
 This section gives details of the new SDP keywords.

3.4.1. Network Type "TN" and Address Type "RFC2543"

 The TN ("Telephone Network") network type is used to indicate that
 the terminal is connected to a telephone network.
 The address types allowed for network type TN are "RFC2543" and
 private address types, which MUST begin with an "X-".

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

 Address type RFC2543 is followed by a string conforming to a subset
 of the "telephone-subscriber" BNF specified in figure 4  of SIP [1]).
 Note that this BNF is NOT identical to the BNF that defines the
 "phone-number" within the "p=" field of SDP.
 Examples:
     c= TN  RFC2543  +1-201-406-4090
     c= TN  RFC2543  12014064090
 A telephone-subscriber string is of one of two types:  global-phone-
 number or local-phone-number.  These are distinguished by preceeding
 a global-phone-number with a "plus" sign ("+"). A global-phone-number
 is by default to be interpreted as an internationally significant
 E.164 Number Plan Address, as defined by [6], whilst a local-phone-
 number is a number specified in the default dialling plan within the
 context of the recipient PINT Gateway.
 An implementation MAY use private addressing types, which can be
 useful within a local domain. These address types MUST begin with an
 "X-", and SHOULD contain a domain name after the X-, e.g. "X-
 mytype.mydomain.com".  An example of such a connection line is as
 follows:
       c= TN X-mytype.mydomain.com  A*8-HELEN
 where "X-mytype.mydomain.com" identifies this private address type,
 and "A*8-HELEN" is the number in this format. Such a format is
 defined as an "OtherAddr" in the ABNF of Appendix A. Note that most
 dialable telephone numbers are expressable as local-phone-numbers
 within address RFC2543; new address types SHOULD only be used for
 formats which cannot be so written.

3.4.2. Support for Data Objects within PINT

 One significant change over traditional SIP/SDP Internet Conference
 sessions with PINT is that a PINT service request may refer to a Data
 Object to be used as source information in that request. For example,
 a PINT service request may specify a document to be processed as part
 of a GSTN service by which a Fax is sent. Similarly, a GSTN service
 may be take a Web page and result in a vocoder processing that page
 and speaking the contents over a telephone.
 The SDP specification does not have explicit support for reference to
 or carriage of Data Objects within requests. In order to use SDP for
 PINT, there is a need to describe such media sessions as "a telephone

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

 call to a certain number during which such-and-such an image is sent
 as a fax".
 To support this, two extensions to the session description format are
 specified. These are some new allowed values for the Media Field, and
 a description of the "fmtp" parameter when used with the Media Field
 values (within the context of the Contact Field Network type "TN").
 An addition is also made to the SIP message format to allow the
 inclusion of data objects as sub-parts within the request message
 itself. The original SDP syntax (from [2]) for media-field is given
 as:
    media-field =         "m=" media space port ["/" integer]
                          space proto 1*(space fmt) CRLF
 When used within PINT requests, the definition of the sub-fields is
 expanded slightly. The Media sub-field definition is relaxed to
 accept all of the discrete "top-level" media types defined in [4]. In
 the milestone services the discrete type "video" is not used, and the
 extra types "data" and "control" are likewise not needed. The use of
 these types is not precluded, but the behaviour expected of a PINT
 Gateway receiving a request including such a type is not defined
 here.
 The Port sub-field has no meaning in PINT requests as the destination
 terminals are specified using "TN" addressing, so the value of the
 port sub-field in PINT requests is normally set to "1". A value of
 "0" may be used as in SDP to indicate that the terminal is not
 receiving media.  This is useful to indicate that a telephone
 terminal has gone "on hold" temporarily.  Likewise, the optional
 integer sub-field is not used in PINT.
 As mentioned in [2], the Transport Protocol sub-field is specific to
 the associated Address Type. In the case that the Address Type in the
 preceeding Contact field is one of those defined for use with the
 Network Type "TN", the following values are defined for the Transport
 Protocol sub-field:
 "voice", "fax", and "pager".
 The interpretation of this sub-field within PINT requests is the
 treatment or disposition of the resulting GSTN service. Thus, for
 transport protocol "voice", the intent is that the service will
 result in a GSTN voice call, whilst for protocol "fax" the result
 will be a GSTN fax transmission, and protocol "pager" will result in
 a pager message being sent.

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

 Note that this sub-field does not necessarily dictate the media type
 and subtype of any source data; for example, one of the milestone
 services calls for a textual source to be vocoded and spoken in a
 resulting telephone service call. The transport protocol value in
 this case would be "voice", whilst the media type would be "text".
 The Fmt sub-field is described in [2] as being transport protocol-
 specific. When used within PINT requests having one of the above
 protocol values, this sub-field consists of a list of one or more
 values, each of which is a defined MIME sub-type of the associated
 Media sub-field value. The special value "-" is allowed, meaning that
 there is no MIME sub-type. This sub-field retains (from [2]) its
 meaning that the list will contain a set of alternative sub-types,
 with the first being the preferred value.
 For experimental purposes and by mutual consent of the sender and
 recipient, a sub-type value may be specified as an <X-token>, i.e. a
 character string starting with "X-". The use of such values is
 discouraged, and if such a value is expected to find common use then
 it SHOULD be registered with IANA using the standard content type
 registration process (see Appendix C).
 When the Fmt parameter is the single character "-" ( a dash ), this
 is interpreted as meaning that a unspecified or default sub-type can
 be used for this service. Thus, the media field value "m=audio 1
 voice -<CRLF>" is taken to mean that a voice call is requested, using
 whatever audio sub type is deemed appropriate by the Executive
 System. PINT service is a special case, in that the request comes
 from the IP network but the service call is provided within the GSTN.
 Thus the service request will not normally be able to define the
 particular codec used for the resulting GSTN service call. If such an
 intent IS required, then the quality attribute may be used (see
 "Suggested Attributes" section of [2]).

3.4.2.1. Use of fmtp attributes in PINT requests

 For each element of the Fmt sub-field, there MUST be a following fmtp
 attribute. When used within PINT requests, the fmtp attribute has a
 general structure as defined here:
     "a=fmtp:" <subtype> <space> resolution
                        *(<space> resolution)
                        (<space> ";" 1(<attribute>)
                                     *(<space> <attribute>))
 where:
     <resolution> := (<uri-ref> | <opaque-ref> | <sub-part-ref>)

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

 A fmtp attribute describes the sources used with a given Fmt entry in
 the Media field. The entries in a Fmt sub-field are alternatives
 (with the preferred one first in the list). Each entry will have a
 matching fmtp attribute. The list of resolutions in a fmtp attribute
 describes the set of sources that resolve the matching Fmt choice;
 all elements of this set will be used.
 It should be noted that, for use in PINT services, the elements in
 such a set will be sent as a sequence; it is unlikely that trying to
 send them in parallel would be successful.
 A fmtp attribute can contain a mixture of different kinds of element.
 Thus an attribute might contain a sub-part-ref indicating included
 data held in a sub-part of the current message, followed by an
 opaque-ref referring to some content on the GSTN, followed by a uri-
 ref pointing to some data held externally on the IP network.
 To indicate which form each resolution element takes, each of them
 starts with its own literal tag. The detailed syntax of each form is
 described in the following sub-sections.

3.4.2.2. Support for Remote Data Object References in PINT

 Where data objects stored elsewhere on the IP Network are to be used
 as sources for processing within a PINT service, they may be referred
 to using the uri-ref form. This is simply a Uniform Resource
 Identifier (URI), as described in [9].
 Note that the reference SHOULD be an absolute URI, as there may not
 be enough contextual information for the recipient server to resolve
 a relative reference; any use of relative references requires some
 private agreement between the sender and recipient of the message,
 and SHOULD be avoided unless the sender can be sure that the
 recipient is the one intended and the reference is unambiguous in
 context.
 This also holds for partial URIs (such
 as"uri:http://aNode/index.htm") as these will need to be resolved in
 the context of the eventual recipient of the message.
 The general syntax of a reference to an Internet-based external data
 object in a fmtp line within a PINT session description is:
     <uri-ref> := ("uri:" URI-reference)
 where URI-reference is as defined in Appendix A of [9]

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

 For example:
       c= TN RFC2543 +1-201-406-4090
       m= text 1  fax plain
       a=fmtp:plain  uri:ftp://ftp.isi.edu/in-notes/rfc2468.txt
 or:
       c= TN RFC2543 +1-201-406-4090
       m= text 1  fax plain
       a=fmtp:plain
 uri:http://www.ietf.org/meetings/glance_minneapolis.txt
 means get this data object from the Internet and use it as a source
 for the requested GSTN Fax service.

3.4.2.3. Support for GSTN-based Data Objects in PINT

 PINT services may refer to data that are held not on the IP Network
 but instead within the GSTN. The way in which these items are
 indicated need have no meaning within the context of the Requestor or
 the PINT Gateway; the reference is merely some data that may be used
 by the Executive System to indicate the content intended as part of
 the request. These data form an opaque reference, in that they are
 sent "untouched" through the PINT infrastructure.
 A reference to some data object held on the GSTN has the general
 definition:
     <opaque-ref> := ("opr:" *uric)
 where uric is as defined in Appendix A of [9].
 For example:
       c= TN RFC2543 +1-201-406-4090
       m= text 1  fax plain
       a=fmtp:plain  opr:APPL.123.456
 means send the data that is indexed ON THE GSTN by the reference
 value "APPL.123.456" to the fax machine on +1-201-406-4090. The
 Executive System may also take the Telephone URL held in the To:
 field of the enclosing SIP message into account when deciding the
 context to be used for the data object dereference.
 Of course, an opaque reference may also be used for other purposes;
 it could, for example, be needed to authorise access to a document
 held on the GSTN rather than being required merely to disambiguate

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

 the data object. The purpose to which an opaque reference is put,
 however, is out of scope for this document. It is merely an indicator
 carried within a PINT Request.
 An opaque reference may have no value in the case where the value to
 be used is implicit in the rest of the request. For example, suppose
 some company wishes to use PINT to implement a "fax-back service". In
 their current implementation, the image(s) to be faxed are entirely
 defined by the telephone number dialled. Within the PINT request,
 this telephone number would appear within the "To:" field of the PINT
 request, and so there is no need for an opaque reference value.
 If there are several resolutions for a PINT Service Request, and one
 of these is an opaque reference with no value, then that opaque
 reference MUST be included in the attribute line, but with an empty
 value field.
 For example:
       c= TN RFC2543 +1-201-406-4090
       m= text 1  fax plain
       a=fmtp:plain  uri:http://www.sun.com/index.html opr:
 might be used to precede some data to be faxed with a covering note.
 In the special case where an opaque reference is the sole resolution
 of a PINT Service Request, AND that reference needs no value, there
 is no need for a Fmt list at all; the intent of the service is
 unambiguous without any further resolution.
 For example:
       c= TN RFC2543 +1-201-406-4090
       m= text 1  fax -
 means that there is an implied content stored on the GSTN, and that
 this is uniquely identified by the combination of SIP To-URI and the
 Contact field of the session description.

3.4.2.4. Session Description support for included Data Objects

 As an alternative to pointing to the data via a URI or an opaque
 reference to a data item held on the GSTN, it is possible to include
 the content data within the SIP request itself. This is done by using
 multipart MIME for the SIP payload. The first MIME part contains the
 SDP description of the telephone network session to be executed. The
 other MIME parts contain the content data to be transported.

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

 Format specific attribute lines within the session description are
 used to indicate which other MIME part within the request contains
 the content data. Instead of a URI or opaque reference, the format-
 specific attribute indicates the Content-ID of the MIME part of the
 request that contains the actual data, and is defined as:
     <sub-part-ref> := ("spr:" Content-ID)
 where Content-ID is as defined in Appendix A of [3] and in [10]).
 For example:
       c= TN RFC2543 +1-201-406-4090
       m= text 1  fax plain
       a=fmtp:plain  spr:<Content-ID>
 The <Content-ID> parameter is the Content-ID of one of the MIME parts
 inside the message, and this fragment means that the requesting user
 would like the data object held in the sub-part of this message
 labelled <Content-ID> to be faxed to the machine at phone number +1-
 201-406-4090.
 See also section 3.5.1 for a discussion on the support needed in the
 enclosing SIP request for included data objects.

3.4.3. Attribute Tags to pass information into the Telephone Network

 It may be desired to include within the PINT request service
 parameters that can be understood only by some entity in the
 "Telephone Network Cloud". SDP attribute parameters are used for this
 purpose. They MAY appear within a particular media description or
 outside of a media description.
 These attributes may also appear as parameters within PINT URLS (see
 section 3.5.6) as part of a SIP request.
 This is necessary so that telephone terminals that require the
 attributes to be defined can appear within the To: line of a PINT
 request as well as within PINT session descriptions.
 The purpose of these attributes is to allow the client to specify
 extra context within which a particular telephone number is to be
 interpreted.  There are many reasons why extra context might be
 necessary to interpret a given telephone number:

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

    a. The telephone number might be reachable in many different ways
       (such as via competing telephone service providers), and the
       PINT client wishes to indicate its selection of service
       provider.
    b. The telephone number might be reachable only from a limited
       number of networks (such as an '800' freephone number).
    c. The telephone number might be reachable only within a single
       telephone network (such as the '152' customer service number of
       BT). Similarly, the number might be an internal corporate
       extension reachable only within the PBX.
 However, as noted above, it is not usually necessary to use SDP
 attributes to specify the phone context. URLs such as
 152@pint.bt.co.il within the To: and From: headers and/or Request-
 URI, normally offer sufficient context to resolve telephone numbers.
 If the client wishes the request to fail if the attributes are not
 supported, these attributes SHOULD be used in conjunction with the
 "require" attribute (section 3.4.4) and the
 "Require:org.ietf.sdp.require" header (section 3.5.4).
 It is not possible to standardise every possible internal telephone
 network parameter. PINT 1.0 attributes have been chosen for
 specification because they are common enough that many different PINT
 systems will want to use them, and therefore interoperability will be
 increased by having a single specification.
 Proprietary attribute "a=" lines, that by definition are not
 interoperable, may be nonetheless useful when it is necessary to
 transport some proprietary internal telephone network variables over
 the IP network, for example to identify the order in which service
 call legs are to be be made. These private attributes SHOULD BE,
 however, subject to the same IANA registration procedures mentioned
 in the SDP specification[2] (see also this Appendix C).

3.4.3.1. The phone-context attribute

 An attribute is specified to enable "remote local dialling". This is
 the service that allows a PINT client to reach a number from far
 outside the area or network that can usually reach the number. It is
 useful when the sending or receiving address is only dialable within
 some local context, which may be remote to the origin of the PINT
 client.
 For example, if Alice wanted to report a problem with her telephone,
 she might then dial a "network wide" customer care number; within the
 British Telecom network in the U.K., this is "152". Note that in this
 case she doesn't dial any trunk prefix - this is the whole dialable

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

 number. If dialled from another operator's network, it will not
 connect to British Telecom's Engineering Enquiries service; and
 dialling "+44 152" will not normally succeed. Such numbers are called
 Network-Specific Service Numbers.
 Within the telephone network, the "local context" is provided by the
 physical connection between the subscriber's terminal and the central
 office. An analogous association between the PINT client and the PINT
 server that first receives the request may not exist, which is why it
 may be necessary to supply this missing "telephone network context".
 This attribute is defined as follows:
 a=phone-context: <phone-context-ident>
 phone-context-ident     =  network-prefix / private-prefix
 network-prefix          =  intl-network-prefix / local-network-prefix
 intl-network-prefix     =  "+" 1*DIGIT
 local-network-prefix    =  1*DIGIT
 excldigandplus          =  (0x21-0x2d,0x2f,0x40-0x7d))
 private-prefix          =  1*excldigandplus 0*uric
 An intl-network-prefix and local-network-prefix MUST be a bona fide
 network prefix, and a network-prefix that is an intl-network-prefix
 MUST begin with an E.164 service code ("country code").
 It is possible to register new private-prefixes with IANA so as to
 avoid collisions. Prefixes that are not so registered MUST begin with
 an "X-" to indicate their private, non-standard nature (see Appendix
 C).
 Example 1:
       c= TN   RFC2543  1-800-765-4321
       a=phone-context:+972
 This describes an terminal whose address in Israel (E.164 country
 code 972) is 1-800-765-4321.
 Example 2:
       c= TN   RFC2543  1-800-765-4321
       a=phone-context:+1
 This describes an terminal whose address in North America (E.164
 country code 1) is 1-800-765-4321.
 The two telephone terminals described by examples 1 and 2 are
 different; in fact they are located in different countries.

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

 Example 3:
       c=TN RFC2543  123
       a=phone-context:+97252
 This describes a terminal whose address when dialled from within the
 network identified by +97252 is the string "123". It so happens that
 +97252 defines one of the Israeli cell phone providers, and 123
 reaches customer service when dialled within that network.
 It may well be useful or necessary to use the SDP "require" parameter
 in conjunction with the phone-context attribute.
 Example 4:
       c= TN  RFC2543  321
       a=phone-context:X-acme.com-23
 This might describe the telephone terminal that is at extension 321
 of PBX number 23 within the acme.com private PBX network. It is
 expected that such a description would be understandable by the
 acme.com PINT server that receives the request.
 Note that if the PINT server receiving the request is inside the
 acme.com network, the same terminal might be addressable as follows:
       c= TN  RFC2543 7-23-321
 (assuming that "7" is dialled in order to reach the private PBX
 network from within acme.com)

3.4.3.2. Presentation Restriction attribute

 Although it has no affect on the transport of the service request
 through the IP Network, there may be a requirement to allow
 originators of a PINT service request to indicate whether or not they
 wish the "B party" in the resulting service call to be presented with
 the "A party's" calling telephone number. It is a legal requirement
 in some jurisdictions that a caller be able to select whether or not
 their correspondent can find out the calling telephone number (using
 Automatic Number Indication or Caller Display or Calling Line
 Identity Presentation equipment). Thus an attribute may be needed to
 indicate the originator's preference.
 Whether or not the default behaviour of the Executive System is to
 present or not present a party's telephone number to the
 correspondent GSTN terminal is not specified, and it is not mandatory
 in all territories for a PINT Gateway or Executive System to act on

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

 this attribute. It is, however, defined here for use where there are
 regulatory restrictions on GSTN operation, and in that case the
 Executive System can use it to honour the originator's request.
 The attribute is specified as follows:
     a=clir:<"true" | "false">
 This boolean value is needed within the attribute as it may be that
 the GSTN address is, by default, set to NOT present its identity to
 correspondents, and the originator wants to do so for this particular
 call. It is in keeping with the aim of this attribute to allow the
 originator to specify what treatment they want for the requested
 service call.
 The expected interpretation of this attribute is that, if it is
 present and the value is "false" then the Calling Line Identity CAN
 be presented to the correspondent terminal, whilst if it is "true"
 then if possible the Executive System is requested to NOT present the
 Calling Line Identity.

3.4.3.3. ITU-T CalledPartyAddress attributes parameters

 These attributes correspond to fields that appear within the ITU-T
 Q.763 "CalledPartyAddress" field (see [8] ,section 3.9). PINT clients
 use these attributes in order to specify further parameters relating
 to Terminal Addresses, in the case when the address indicates a
 "local-phone-number". In the case that the PINT request contains a
 reference to a GSTN terminal, the parameters may be required to
 correctly identify that remote terminal.
 The general form of this attribute is:  "a=Q763-<token>((":" <value>)
 |"")".  Three of the possible elements and their use in SDP
 attributes are described here. Where other Q763 elements are to be
 used, then these should be the subject of further specification to
 define the syntax of the attribute mapping. It is recommended that
 any such specification maintains the value sets shown in Q.763.
 The defined attributes are:
 a=Q763-nature:  - indicates the "nature of address indicator".
                     The value MAY be any number between 0 and 127.
                     The following values are specified:
                 "1" a subscriber number
                 "2" unknown
                 "3" a nationally significant number
                 "4" an internationally significant number

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

 The values have been chosen to coincide with the values in Q.763.
 Note that other values are possible, according to national rules or
 future expansion of Q.763.
 a=Q763-plan:    - indicates the numbering plan to which the address
                     belongs. The value MAY be any number between 0
                     and 7. The following values are specified:
                 "1" Telephone numbering plan (ITU-T E.164)
                 "3" Data numbering plan (ITU-T X.121)
                 "4" Telex numbering plan (ITU-T F.69)
 The values have been chosen to coincide with the values in Q.763.
 Other values are allowed, according to national rules or future
 expansion of Q.763.
 a=Q763-INN      - indicates if routing to the Internal Network Number
                     is allowed. The value MUST be ONE of:
                 "0" routing to internal network number allowed
                 "1" routing to internal network number not
                               allowed
 The values have been chosen to coincide with the values in Q.763.
 Note that it is possible to use a local-phone-number and indicate via
 attributes that the number is in fact an internationally significant
 E.164 number. Normally this SHOULD NOT be done; an internationally
 significant E.164 number is indicated by using a "global-phone-
 number" for the address string.

3.4.4. The "require" attribute

 According to the SDP specification, a PINT server is allowed simply
 to ignore attribute parameters that it does not understand. In order
 to force a server to decline a request if it does not understand one
 of the PINT attributes, a client SHOULD use the "require" attribute,
 specified as follows:
       a=require:<attribute-list>
 where the attribute-list is a comma-separated list of attributes that
 appear elsewhere in the session description.
 In order to process the request successfully the PINT server must
 BOTH understand the attribute AND ALSO fulfill the request implied by
 the presence of the attribute, for each attribute appearing within
 the attribute-list of the require attribute.

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

 If the server does not recognise the attribute listed, the PINT
 server MUST return an error status code (such as 420 (Bad Extension)
 or 400 (Bad Request)), and SHOULD return suitable Warning: lines
 explaining the problem or an Unsupported: header containing the
 attribute it does not understand. If the server recognizes the
 attribute listed, but cannot fulfill the request implied by the
 presence of the attribute, the request MUST be rejected with a status
 code of (606 Not Acceptable), along with a suitable Unsupported:
 header or Warning: line.
 The "require" attribute may appear anywhere in the session
 description, and any number of times, but it MUST appear before the
 use of the attribute marked as required.
 Since the "require" attribute is itself an attribute, the SIP
 specification allows a server that does not understand the require
 attribute to ignore it. In order to ensure that the PINT server will
 comply with the "require" attribute, a PINT client SHOULD include a
 Require: header with the tag "org.ietf.sdp.require" (section 3.5.4)
 Note that the majority of the PINT extensions are "tagged" and these
 tags can be included in Require strictures. The exception is the use
 of phone numbers in SDP parts. However, these are defined as a new
 network and address type, so that a receiving SIP/SDP server should
 be able to detect whether or not it supports these forms. The default
 behaviour for any SDP recipient is that it will fail a PINT request
 if it does not recognise or support the TN and RFC2543 or X-token
 network and address types, as without the contents being recognised
 no media session could be created. Thus a separate stricture is not
 required in this case.

3.5. PINT Extensions to SIP 2.0

 PINT requests are SIP requests; Many of the specifications within
 this document merely explain how to use existing SIP facilities for
 the purposes of PINT.

3.5.1. Multi-part MIME (sending data along with SIP request)

 A PINT request can contain a payload which is multipart MIME. In this
 case the first part MUST contain an SDP session description that
 includes at least one of the format specific attribute tags for
 "included content data" specified above in section 3.4.3. Subsequent
 parts contain content data that may be transferred to the requested
 Telephone Call Service. As discussed earlier, within a single PINT
 request, some of the data MAY be pointed to by a URI within the
 request, and some of the data MAY be included within the request.

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

 Where included data is carried within a PINT service request, the
 Content Type entity header of the enclosing SIP message MUST indicate
 this. To do so, the media type value within this entity header MUST
 be set to a value of "multipart". There is a content sub-type that is
 intended for situations like this in which sub-parts are to be
 handled together. This is the multipart/related type (defined in
 [19]), and it's use is recommended.
 The enclosed body parts SHOULD include the part-specific Content Type
 headers as appropriate ("application/sdp" for the first body part
 holding the session description, with an appropriate content type for
 each of the subsequent, "included data object" parts). This matches
 the standard syntax of MIME multipart messages as defined in [4].
 For example, in a multipart message where the string
 "------next-------" is the boundary, the first two parts might be as
 follows:
  1. —–next——-

Content-Type: application/sdp

       ....
       c= TN RFC2543 +1-201-406-4090
       m= text 1 pager plain
       a=fmtp:plain spr:17@mymessage.acme.com
  1. ———next——-

Content-Type: text/plain

       Content-ID:  17@mymessage.acme.com
       This is the text that is to be paged to +1-201-406-4090
  1. ———next———–
 The ability to indicate different alternatives for the content to be
 transported is useful, even when the alternatives are included within
 the request. For example, a request to send a short message to a
 pager might include the message in Unicode [5] and an alternative
 version of the same content in text/plain, should the PINT server or
 telephone network not be able to process the unicode.
 PINT clients should be extremely careful when sending included data
 within a PINT request. Such requests SHOULD be sent via TCP, to avoid
 fragmentation and to transmit the data reliably. It is possible that
 the PINT server is a proxy server that will replicate and fork the
 request, which could be disastrous if the request contains a large
 amount of application data. PINT proxy servers should be careful not
 to create many copies of a request with large amounts of data in it.

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

 If the client does not know the actual location of the PINT gateway,
 and is using the SIP location services to find it, and the included
 data makes the PINT request likely to be transported in several IP
 datagrams, it is RECOMMENDED that the initial PINT request not
 include the data object but instead hold a reference to it.

3.5.2. Warning header

 A PINT server MUST support the SIP "Warning:" header so that it can
 signal lack of support for individual PINT features. As an example,
 suppose the PINT request is to send a jpeg picture to a fax machine,
 but the server cannot retrieve and/or translate jpeg pictures from
 the Internet into fax transmissions.
 In such a case the server fails the request and includes a Warning
 such as the following:
       Warning:  305  pint.acme.com  Incompatible media format:  jpeg
 SIP servers that do not understand the PINT extensions at all are
 strongly encouraged to implement Warning: headers to indicate that
 PINT extensions are not understood.
 Also, Warning: headers may be included within NOTIFY requests if it
 is necessary to notify the client about some condition concerning the
 invocation of the PINT service (see next).

3.5.3. Mechanism to register interest in the disposition of a PINT

     service, and to receive indications on that disposition
 It can be very useful to find out whether or not a requested service
 has completed, and if so whether or not it was successful. This is
 especially true for PINT service, where the person requesting the
 service is not (necessarily) a party to it, and so may not have an
 easy way of finding out the disposition of that service. Equally, it
 may be useful to indicate when the service has changed state, for
 example when the service call has started.
 Arranging a flexible system to provide extensive monitoring and
 control during a service is non-trivial (see section 6.4 for some
 issues); PINT 1.0 uses a simple scheme that should nevertheless
 provide useful information. It is possible to expand the scheme in a
 "backwards compatible" manner, so if required it can be enhanced at a
 later date.
 The PINT 1.0 status registration and indication scheme uses three new
 methods; SUBSCRIBE, UNSUBSCRIBE, and NOTIFY. These are used to allow
 a PINT client to register an interest in (or "subscribe" to) the

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

 status of a service request, to indicate that a prior interest has
 lapsed (i.e "unsubscribe" from the status), and for the server to
 return service indications. The state machine of
 SUBSCRIBE/UNSUBSCRIBE is identical to that of INVITE/BYE; just as
 INVITE signals the beginning and BYE signals the end of participation
 in a media session, SUBSCRIBE signals the beginning and UNSUBSCRIBE
 signals the end of participation in a monitoring session. During the
 monitoring session, NOTIFY messages are sent to inform the subscriber
 of a change in session state or disposition.

3.5.3.1. Opening a monitoring session with a SUBSCRIBE request

 When a SUBSCRIBE request is sent to a PINT Server, it indicates that
 a user wishes to receive information about the status of a service
 session. The request identifies the session of interest by including
 the original session description along with the request, using the
 SDP global-session-id that forms part of the origin-field to identify
 the service session uniquely.
 The SUBSCRIBE request (like any other SIP request about an ongoing
 session) is sent to the same server as was sent the original INVITE,
 or to a server which was specified in the Contact: field within a
 subsequent response (this might well be the PINT gateway for the
 session).
 Whilst there are situations in which re-use of the Call-ID used in
 the original INVITE that initiated the session of interest is
 possible, there are other situations in which it is not. In detail,
 where the subscription is being made by the user who initiated the
 original service request, the Call-ID may be used as it will be known
 to the receiver to refer to a previously established session.
 However, when the request comes from a user other than the original
 requesting user, the SUBSCRIBE request constitutes a new SIP call
 leg, so the Call-ID SHOULD NOT be used; the only common identifier is
 the origin-field of the session description enclosed within the
 original service request, and so this MUST be used.
 Rather than have two different methods of identifying the "session of
 interest" the choice is to use the origin-field of the SDP sub-part
 included both in the original INVITE and in this SUBSCRIBE request.
 Note that the request MUST NOT include any sub-parts other than the
 session description, even if these others were present in the
 original INVITE request. A server MUST ignore whatever sub-parts are
 included within a SUBSCRIBE request with the sole exception of the
 enclosed session description.

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

 The request MAY contain a "Contact:" header, specifying the PINT User
 Agent Server to which such information should be sent.
 In addition, it SHOULD contain an Expires: header, which indicates
 for how long the PINT Requestor wishes to receive notification of the
 session status. We refer to the period of time before the expiration
 of the SUBSCRIBE request as the "subscription period". See section
 5.1.4.  for security considerations, particularly privacy
 implications.
 A value of 0 within the Expires: header indicates a desire to receive
 one single immediate response (i.e. the request expires immediately).
 It is possible for a sequence of monitoring sessions to be opened,
 exist, and complete, all relating to the same service session.
 A successful response to the SUBSCRIBE request includes the session
 description, according to the Gateway. Normally this will be
 identical to the last cached response that the Gateway returned to
 any request concerning the same SDP global session id (see [2],
 section 6, o= field). The t= line may be altered to indicate the
 actual start or stop time, however. The Gateway might add an i= line
 to the session description to indicate such information as how many
 fax pages were sent. The Gateway SHOULD include an Expires: header
 indicating how long it is willing to maintain the monitoring session.
 If this is unacceptable to the PINT Requestor, then it can close the
 session by sending an immediate UNSUBSCRIBE message (see 3.5.3.3).
 In principle, a user might send a SUBSCRIBE request after the
 telephone network service has completed. This allows, for example,
 checking up "the morning after" to see if the fax was successfully
 transmitted.  However, a PINT gateway is only required to keep state
 about a call for as long as it indicated previously in an Expires:
 header sent within the response to the original INVITE message that
 triggered the service session, within the response to the SUBSCRIBE
 message, within the response to any UNSUBSCRIBE message, or within
 its own UNSUBSCRIBE message (but see section 3.5.8, point 3).
 If the Server no longer has a record of the session to which a
 Requestor has SUBSCRIBEd, it returns "606 Not Acceptable", along with
 the appropriate Warning: 307 header indicating that the SDP session
 ID is no longer valid. This means that a requesting Client that knows
 that it will want information about the status of a session after the
 session terminates SHOULD send a SUBSCRIBE request before the session
 terminates.

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

3.5.3.2. Sending Status Indications with a NOTIFY request

 During the subscription period, the Gateway may, from time to time,
 send a spontaneous NOTIFY request to the entity indicated in the
 Contact:  header of the "opening" SUBSCRIBE request. Normally this
 will happen as a result of any change in the status of the service
 session for which the Requestor has subscribed.
 The receiving user agent server MUST acknowledge this by returning a
 final response (normally a "200 OK"). In this version of the PINT
 extensions, the Gateway is not required to support redirects (3xx
 codes), and so may treat them as a failure.
 Thus, if the response code class is above 2xx then this may be
 treated by the Gateway as a failure of the monitoring session, and in
 that situation it will immediately attempt to close the session (see
 next).
 The NOTIFY request contains the modified session description. For
 example, the Gateway may be able to indicate a more accurate start or
 stop time.
 The Gateway may include a Warning: header to describe some problem
 with the invocation of the service, and may indicate within an i=
 line some information about the telephone network session itself.
 Example:
       NOTIFY  sip:petrack@pager.com SIP/2.0
       To: sip:petrack@pager.com
       From: sip:R2F.pint.com@service.com
       Call-ID: 19971205T234505.56.78@pager.com
       CSeq: 4711 SUBSCRIBE
       Warning: xxx  fax aborted, will try for the next hour.
       Content-Type:application/sdp
       c=...
       i=3 pages of 5 sent
       t=...

3.5.3.3. Closing a monitoring session with an UNSUBSCRIBE request

 At some point, either the Client's representative User Agent Server
 or the Gateway may decide to terminate the monitoring session. This
 is achieved by sending an UNSUBSCRIBE request to the correspondent
 server.  Such a request indicates that the sender intends to close
 the monitoring session immediately, and, on receipt of the final
 response from the receiving server, the session is deemed over.

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

 Note that unlike the SUBSCRIBE request, which is never sent by a PINT
 gateway, an UNSUBSCRIBE request can be sent by a PINT gateway to the
 User Agent Server to indicate that the monitoring session is closed.
 (This is analogous to the fact that a gateway never sends an INVITE,
 although it can send a BYE to indicate that a telephone call has
 ended.)
 If the Gateway initiates closure of the monitoring session by sending
 an UNSUBSCRIBE message, it SHOULD include an "Expires:" header
 showing for how much longer after this monitoring session is closed
 it is willing to store information on the service session. This acts
 as a minimum time within which the Client can send a new SUBSCRIBE
 message to open another monitoring session; after the time indicated
 in the Expires: header the Gateway is free to dispose of any record
 of the service session, so that subsequent SUBSCRIBE requests can be
 rejected with a "606" response.
 If the subscription period specified by the Client has expired, then
 the Gateway may send an immediate UNSUBSCRIBE request to the Client's
 representative User Agent Server. This ensures that the monitoring
 session always completes with a UNSUBSCRIBE/response exchange, and
 that the representative User Agent Server can avoid maintaining state
 in certain circumstances.

3.5.3.4. Timing of SUBSCRIBE requests

 As it relies on the Gateway having a copy of the INVITEd session
 description, the SUBSCRIBE message is limited in when it can be
 issued.  The Gateway must have received the service request to which
 this monitoring session is to be associated, which from the Client's
 perspective happens as soon as the Gateway has sent a 1xx response
 back to it.
 However, once this has been done, there is no reason why the Client
 should not send a monitoring request. It does not have to wait for
 the final response from the Gateway, and it can certainly send the
 SUBSCRIBE request before sending the ACK for the Service request
 final response.  Beyond this point, the Client is free to send a
 SUBSCRIBE request when it decides, unless the Gateway's final
 response to the initial service request indicated a short Expires:
 time.
 However, there are good reasons (see 6.4) why it may be appropriate
 to start a monitoring session immediately before the service is
 confirmed by the PINT Client sending an ACK. At this point the
 Gateway will have decided whether or not it can handle the service
 request, but will not have passed the request on to the Executive
 System. It is therefore in a good position to ask the Executive

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

 System to enable monitoring when it sends the service request
 onwards. In practical implementations, it is likely that more
 information on transient service status will be available if this is
 indicated as being important BEFORE or AS the service execution phase
 starts; once execution has begun the level of information that can be
 returned may be difficult to change.
 Thus, whilst it is free to send a SUBSCRIBE request at any point
 after receiving an Interim response from the Gateway to its service
 request, it is recommended that the Client should send such a
 monitoring request immediately prior to sending an ACK message
 confirming the service if it is interested in transient service
 status messages.

3.5.4. The "Require:" header for PINT

 PINT clients use the Require: header to signal to the PINT server
 that a certain PINT extension of SIP is required. PINT 1.0 defines
 two strings that can go into the Require header:
 org.ietf.sip.subscribe  -- the server can fulfill SUBSCRIBE requests
                            and associated methods (see section 3.5.3)
 org.ietf.sdp.require    -- the PINT server (or the SDP parser
                            associated to it) understands the "require"
                            attribute defined in (section 3.4.4)
 Example:
       Require:org.ietf.sip.subscribe,org.ietf.sdp.require
 A client SHOULD only include a Require: header where it truly
 requires the server to reject the request if the option is not
 supported.

3.5.5. PINT URLs within PINT requests

 Normally the hostnames and domain names that appear in the PINT URLs
 are the internal affair of each individual PINT system. A client uses
 the appropriate SDP payload to indicate the particular service it
 wishes to invoke; it is not necessary to use a particular URL to
 identify the service.
 A PINT URL is used in two different ways within PINT requests: within
 the Request-URI, and within the To: and From: headers. Use within the
 Request-URI requires clarification in order to ensure smooth
 interworking with the Telephone Network serviced by the PINT
 infrastructure, and this is covered next.

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

3.5.5.1. PINT URLS within Request-URIs

 There are some occasions when it may be useful to indicate service
 information within the URL in a standardized way:
    a. it may not be possible to use SDP information to route the
       request if it is encrypted;
    b. it allows implementation that make use of I.N. "service
       indicators";
    c. It enables multiple competing PINT gateways to REGISTER with a
       single "broker" server (proxy or redirect) (see section 6.3)
 For these reasons, the following conventions for URLs are offered for
 use in PINT requests:
 1. The user portion of a sip URL indicates the service to be
 requested.  At present the following services are defined:
 R2C   (for Request-to-Call)
 R2F   (for Request-to-Fax)
 R2HC  (for Request-to-Hear-Content)
 The user portions "R2C", "R2F", and "R2HC" are reserved for the PINT
 milestone services. Other user portions MUST be used in case the
 requested service is not one of the Milestone services. See section
 6.2 for some related considerations concerning registrations by
 competing PINT systems to a single PINT proxy server acting as a
 service broker.
 2. The host portion of a sip URL contains the domain name of the PINT
 service provider.
 3. A new url-parameter is defined to be "tsp" (for "telephone service
 provider"). This can be used to indicate the actual telephone network
 provider to be used to fulfill the PINT request.
 Thus, for example:-
       INVITE sip:R2C@pint.pintservice.com SIP/2.0
       INVITE sip:R2F@pint.pintservice.com;tsp=telco.com SIP/2.0
       INVITE sip:R2HC@pint.mycom.com;tsp=pbx23.mycom.com SIP/2.0
       INVITE sip:13@pint.telco.com SIP/2.0

3.5.6. Telephony Network Parameters within PINT URLs

 Any legal SIP URL can appear as a PINT URL within the Request-URI or
 To:  header of a PINT request. But if the address is a telephone
 address, we indicated in section 3.4.3 that it may be necessary to
 include more information in order correctly to identify the remote

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

 telephone terminal or service. PINT clients MAY include these
 attribute tags within PINT URLs if they are necessary or a useful
 complement to the telephone number within the SIP URL. These
 attribute tags MUST be included as URL parameters as defined in [1]
 (i.e. in the semi-colon separated manner).
 The following is an example of a PINT URL containing extra attribute
 tags:

sip:+9725228808@pint.br.com;user=phone;require=Q763-plan;a=Q763-plan:4

 As we noted in section 3.4.3, these extra attribute parameters will
 not normally be needed within a URL, because there is a great deal of
 context available to help the server interpret the phone number
 correctly. In particular, there is the SIP URL within the To: header,
 and there is also the Request-URI. In most cases this provides
 sufficient information for the telephone network.
 The SDP attributes defined in section 3 above will normally only be
 used when they are needed to supply necessary context to identify a
 telephone terminal.

3.5.7. REGISTER requests within PINT

 A PINT gateway is a SIP user agent server. A User Agent Server uses
 the REGISTER request to tell a proxy or redirect server that it is
 available to "receive calls" (i.e. to service requests). Thus a PINT
 Gateway registers with a proxy or redirect server the service that is
 accessible via itself, whilst in SIP, a user is registering his/her
 presence at a particular SIP Server.
 There may be competing PINT servers that can offer the same PINT
 service trying to register at a single PINT server. The PINT server
 might act as a "broker" among the various PINT gateways that can
 fulfill a request. A format for PINT URLs was specified in section
 3.5.5 that enables independent PINT systems to REGISTER an offer to
 provide the same service. The registrar can apply its own mechanisms
 and policies to decide how to respond to INVITEs from clients seeking
 service (See section 6.3 for some possible deployment options). There
 is no change between SIP and PINT REGISTER semantics or syntax.
 Of course, the information in the PINT URLs within the REGISTER
 request may not be sufficient to completely define the service that a
 gateway can offer. The use of SIP and SDP within PINT REGISTER
 requests to enable a gateway to specify in more detail the services
 it can offer is the subject of future study.

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

3.5.8. BYE Requests in PINT

 The semantics of BYE requests within PINT requires some extra
 precision.  One issue concerns conferences that "cannot be left", and
 the other concerns keeping call state after the BYE.
 The BYE request [1] is normally used to indicate that the originating
 entity no longer wishes to be involved in the specified call. The
 request terminates the call and the media session. Applying this
 model to PINT, if a PINT client makes a request that results in
 invocation of a telephone call from A to B, a BYE request from the
 client, if accepted, should result in a termination of the phone
 call.
 One might expect this to be the case if the telephone call has not
 started when the BYE request is received. For example, if a request
 to fax is sent with a t= line indicating that the fax is to be sent
 tomorrow at 4 AM, the requestor might wish to cancel the request
 before the specified time.
 However, even if the call has yet to start, it may not be possible to
 terminate the media session on the telephone system side. For
 example, the fax call may be in progress when the BYE arrives, and
 perhaps it is just not possible to cancel the fax in session. Another
 possibility is that the entire telephone-side service might be
 completed before the BYE is received. In the above Request-to-Fax
 example, the BYE might be sent the following morning, and the entire
 fax has been sent before the BYE was received. It is too late to send
 the BYE.
 In the case where the telephone network cannot terminate the call,
 the server MUST return a "606 Not Acceptable" response to the BYE,
 along with a session description that indicates the telephone network
 session that is causing the problem.
 Thus, in PINT, a "Not Acceptable" response MAY be returned both to
 INVITE and BYE requests. It indicates that some aspect of the session
 description makes the request unacceptable.
 By allowing a server to return a "Not Acceptable" response to BYE
 requests, we are not changing its semantics, just enlarging its use.
 A combination of Warning: headers and i= lines within the session
 description can be used to indicate the precise nature of the
 problem.

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

 Example:
       SIP/2.0 606 Not Acceptable
       From: ...
       To: .......
       .....
       Warning: 399 pint.mycom.com Fax in progress, service cannot be
          aborted
       Content-Type: application/sdp
       Content-Length: ...
       v=0
       ...
       ...
       i=3 of 5 pages sent OK
       c=TN  RFC2543  +12014064090
       m=image 1 fax tif
       a=fmtp:tif uri:http://tifsRus.com/yyyyyy.tif
 Note that the server might return an updated session description
 within a successful response to a BYE as well. This can be used, for
 example, to indicate the actual start times and stop times of the
 telephone session, or how many pages were sent in the fax
 transmission.
 The second issue concerns how long must a server keep call state
 after receiving a BYE. A question arises because other clients might
 still wish to send queries about the telephone network session that
 was the subject of the PINT transaction. Ordinary SIP semantics have
 three important implications for this situation:
 1. A BYE indicates that the requesting client will clear out all call
 state as soon as it receives a successful response. A client SHOULD
 NOT send a SUBSCRIBE request after it has sent a BYE.
 2. A server may return an Expires: header within a successful
 response to a BYE request. This indicates for how long the server
 will retain session state about the telephone network session. At any
 point during this time, a client may send a SUBSCRIBE request to the
 server to learn about the session state (although as explained in the
 previous paragraph, a client that has sent a BYE will not normally
 send a SUBSCRIBE).
 3. When engaged in a SUBSCRIBE/NOTIFY monitoring session, PINT
 servers that send UNSUBSCRIBE to a URL listed in the Contact: header
 of a client request SHOULD not clear session state until after the
 successful response to the UNSUBSCRIBE message is received. For
 example, it may be that the requesting client host is turned off (or

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

 in a low power mode) when the telephone service is executed (and is
 therefore not available at the location previously specified in the
 Contact: attribute) to receive the PINT server's UNSUBSCRIBE. Of
 course, it is possible that the UNSUBSCRIBE request will simply time
 out.

4. Examples of PINT Requests and Responses

4.1. A request to a call center from an anonymous user to receive a

   phone call.
 C->S: INVITE  sip:R2C@pint.mailorder.com  SIP/2.0
       Via: SIP/2.0/UDP 169.130.12.5
       From: sip:anon-1827631872@chinet.net
       To: sip:+1-201-456-7890@iron.org;user=phone
       Call-ID: 19971205T234505.56.78@pager.com
       CSeq: 4711 INVITE
       Subject: Sale on Ironing Boards
       Content-type: application/sdp
       Content-Length: 174
       v=0
       o=- 2353687637 2353687637 IN IP4 128.3.4.5
       s=R2C
       i=Ironing Board Promotion
       e=anon-1827631872@chinet.net
       t=2353687637 0
       m=audio 1  voice -
       c=TN  RFC2543  +1-201-406-4090
 In this example, the context that is required to interpret the To:
 address as a telephone number is not given explicitly; it is
 implicitly known to the R2C@pint.mailorder.com server. But the
 telephone of the person who wishes to receive the call is explicitly
 identified as an internationally significant E.164 number that falls
 within the North American numbering plan (because of the "+1" within
 the c= line).

4.2. A request from a non anonymous customer (John Jones) to receive a

   phone call from a particular sales agent (Mary James) concerning
   the defective ironing board that was purchased
 C->S: INVITE  sip:marketing@pint.mailorder.com  SIP/2.0
       Via: SIP/2.0/UDP 169.130.12.5
       From: sip:john.jones.3@chinet.net
       To: sip:mary.james@mailorder.com
       Call-ID: 19971205T234505.56.78@pager.com
       CSeq: 4712 INVITE

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

       Subject: Defective Ironing Board - want refund
       Content-type: application/sdp
       Content-Length: 150
       v=0
       o=- 2353687640 2353687640 IN IP4 128.3.4.5
       s=marketing
       e=john.jones.3@chinet.net
       c= TN RFC2543  +1-201-406-4090
       t=2353687640 0
       m=audio 1  voice -
 The To: line might include the Mary James's phone number instead of a
 email-like address. An implementation that cannot accept email-like
 URLs in the "To:" header must decline the request with a 606 Not
 Acceptable.  Note that the sending PINT client "knows" that the PINT
 Gateway contacted with the "marketing@pint.mailorder.com" Request-URI
 is capable of processing the client request as expected. (see 3.5.5.1
 for a discussion on this).
 Note also that such a telephone call service could be implemented on
 the phone side with different details. For example, it might be that
 first the agent's phone rings, and then the customer's phone rings,
 or it might be that first the customer's phone rings and he hears
 silly music until the agent comes on line. If necessary, such service
 parameter details might be indicated in "a=" attribute lines within
 the session description. The specification of such attribute lines
 for service consistency is beyond the scope of the PINT 1.0
 specifications.

4.3. A request from the same user to get a fax back on how to assemble

   the Ironing Board

C→S: INVITE sip:faxback@pint.mailorder.com SIP/2.0

    Via: SIP/2.0/UDP 169.130.12.5
    From: sip:john.jones.3@chinet.net
    To: sip:1-800-3292225@steam.edu;user=phone;phone-context=+1
    Call-ID: 19971205T234505.66.79@chinet.net
    CSeq: 4713 INVITE
    Content-type: application/sdp
    Content-Length: 218
    v=0
    o=- 2353687660 2353687660 IN IP4 128.3.4.5
    s=faxback
    e=john.jones.3@chinet.net
    t=2353687660 0
    m=application 1 fax URI

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

    c=TN  RFC2543  1-201-406-4091
    a=fmtp:URI uri:http://localstore/Products/IroningBoards/2344.html
 In this example, the fax to be sent is stored on some local server
 (localstore), whose name may be only resolvable, or that may only be
 reachable, from within the IP network on which the PINT server sits.
 The phone number to be dialled is a "local phone number" as well.
 There is no "phone-context" attribute, so the context (in this case,
 for which nation the number is "nationally significant") must be
 supplied by the faxback@pint.mailorder.com PINT server.
 If the server that receives it does not understand the number, it
 SHOULD decline the request and include a "Network Address Not
 Understood" warning.  Note that no "require" attribute was used here,
 since it is very likely that the request can be serviced even by a
 server that does not support the "require" attribute.

4.4. A request from same user to have that same information read out

   over the phone

C→S: INVITE sip:faxback@pint.mailorder.com SIP/2.0

    Via: SIP/2.0/UDP 169.130.12.5
    From: sip:john.jones.3@chinet.net
    To: sip:1-800-3292225@steam.edu;user=phone;phone-context=+1
    Call-ID: 19971205T234505.66.79@chinet.net
    CSeq: 4713 INVITE
    Content-type: application/sdp
    Content-Length: 220
    v=0
    o=- 2353687660 2353687660 IN IP4 128.3.4.5
    s=faxback
    e=john.jones.3@chinet.net
    t=2353687660 0
    m=application 1 voice URI
    c=TN  RFC2543  1-201-406-4090
    a=fmtp:URI uri:http://localstore/Products/IroningBoards/2344.html

4.5. A request to send an included text page to a friend's pager.

 In this example, the text to be paged out is included in the request.

C→S: INVITE sip:R2F@pint.pager.com SIP/2.0

    Via: SIP/2.0/UDP 169.130.12.5
    From: sip:scott.petrack@chinet.net
    To: sip:R2F@pint.pager.com
    Call-ID: 19974505.66.79@chinet.net
    CSeq: 4714 INVITE

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

    Content-Type: multipart/related; boundary=--next
  1. —next

Content-Type: application/sdp

    Content-Length: 236
    v=0
    o=- 2353687680 2353687680 IN IP4 128.3.4.5
    s=R2F
    e=scott.petrack@chinet.net
    t=2353687680 0
    m=text 1 pager plain
    c= TN  RFC2543  +972-9-956-1867
    a=fmtp:plain spr:2@53655768
  1. —next

Content-Type: text/plain

    Content-ID: 2@53655768
    Content-Length:50
    Hi Joe! Please call me asap at 555-1234.
  1. —next–

4.6. A request to send an image as a fax to phone number +972-9-956-1867

C→S: INVITE sip:faxserver@pint.vocaltec.com SIP/2.0

    Via: SIP/2.0/UDP 169.130.12.5
    From: sip:scott.petrack@chinet.net
    To: sip:faxserver@pint.vocaltec.com
    Call-ID: 19971205T234505.66.79@chinet.net
    CSeq: 4715 INVITE
    Content-type: application/sdp
    Content-Length: 267
    v=0
    o=- 2353687700 2353687700 IN IP4 128.3.4.5
    s=faxserver
    e=scott.petrack@chinet.net
    t=2353687700 0
    m=image  1 fax  tif gif
    c= TN  RFC2543  +972-9-956-1867
    a=fmtp:tif  uri:http://petrack/images/tif/picture1.tif
    a=fmtp:gif  uri:http://petrack/images/gif/picture1.gif

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

 The image is available as tif or as gif. The tif is the preferred
 format. Note that the http server where the pictures reside is local,
 and the PINT server is also local (because it can resolve machine
 name "petrack")

4.7. A request to read out over the phone two pieces of content in

   sequence.
 First some included text is read out by text-to-speech. Then some
 text that is stored at some URI on the internet is read out.

C→S: INVITE sip:R2HC@pint.acme.com SIP/2.0

    Via: SIP/2.0/UDP 169.130.12.5
    From: sip:scott.petrack@chinet.net
    To: sip:R2HC@pint.acme.com
    Call-ID: 19974505.66.79@chinet.net
    CSeq: 4716 INVITE
    Content-Type: multipart/related; boundary=next
  1. -next

Content-Type: application/sdp

    Content-Length: 316
    v=0
    o=- 2353687720 2353687720 IN IP4 128.3.4.5
    s=R2HC
    e=scott.petrack@chinet.net
    c= TN  RFC2543  +1-201-406-4091
    t=2353687720 0
    m=text  1  voice  plain
    a=fmtp:plain   spr:2@53655768
    m=text  1 voice plain
    a=fmtp:plain  uri:http://www.your.com/texts/stuff.doc
  1. -next

Content-Type: text/plain

    Content-ID: 2@53655768
    Content-Length: 172
    Hello!! I am about to read out to you the document you
    requested, "uri:http://www.your.com/texts/stuff.doc".
    We hope you like acme.com's new speech synthesis server.
    --next--

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

4.8. Request for the prices for ISDN to be sent to my fax machine

 INVITE sip:R2FB@pint.bt.co.uk  SIP/2.0
 Via: SIP/2.0/UDP 169.130.12.5
 To: sip:0345-12347-01@pint.bt.co.uk;user=phone;phone-context=+44
 From: sip:hank.wangford@newts.demon.co.uk
 Call-ID: 19981204T201505.56.78@demon.co.uk
 CSeq: 4716 INVITE
 Subject: Price List
 Content-type: application/sdp
 Content-Length: 169
 v=0
 o=- 2353687740 2353687740 IN IP4 128.3.4.5
 s=R2FB
 i=ISDN Price List
 e=hank.wangford@newts.demon.co.uk
 t=2353687740 0
 m=text 1  fax -
 c=TN  RFC2543  +44-1794-8331010

4.9. Request for a callback

 INVITE sip:R2C@pint.bt.co.uk  SIP/2.0
 Via: SIP/2.0/UDP 169.130.12.5
 To: sip:0345-123456@pint.bt.co.uk;user=phone;phone-context=+44
 From: sip:hank.wangford@newts.demon.co.uk
 Call-ID: 19981204T234505.56.78@demon.co.uk
 CSeq: 4717 INVITE
 Subject: It costs HOW much?
 Content-type: application/sdp
 Content-Length: 176
 v=0
 o=- 2353687760 2353687760 IN IP4 128.3.4.5
 s=R2C
 i=ISDN pre-sales query
 e=hank.wangford@newts.demon.co.uk
 c=TN  RFC2543  +44-1794-8331013
 t=2353687760 0
 m=audio 1  voice -

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

4.10. Sending a set of information in response to an enquiry

 INVITE sip:R2FB@pint.bt.co.uk  SIP/2.0
 Via: SIP/2.0/UDP 169.130.12.5
 To: sip:0345-12347-01@pint.bt.co.uk;user=phone;phone-context=+44
 From: sip:colin.masterton@sales.hh.bt.co.uk
 Call-ID: 19981205T234505.56.78@sales.hh.bt.co.uk
 CSeq: 1147 INVITE
 Subject: Price Info, as requested
 Content-Type: multipart/related; boundary=next
  1. -next

Content-type: application/sdp

 Content-Length: 325
 v=0
 o=- 2353687780 2353687780 IN IP4 128.3.4.5
 s=R2FB
 i=Your documents
 e=colin.masterton@sales.hh.bt.co.uk
 t=2353687780 0
 m=application 1  fax octet-stream
 c=TN  RFC2543  +44-1794-8331010
 a=fmtp:octet-stream uri:http://www.bt.co.uk/imgs/pipr.gif opr:
   spr:2@53655768
  1. -next

Content-Type: text/plain

 Content-ID: 2@53655768
 Content-Length: 352
 Dear Sir,
   Thank you for your enquiry. I have checked availability in your
 area, and we can provide service to your cottage. I enclose a
 quote for the costs of installation, together with the ongoing
 rental costs for the line. If you want to proceed with this,
 please quote job reference isdn/hh/123.45.9901.
 Yours Sincerely,
    Colin Masterton
 --next--
 Note that the "implicit" faxback content is given by an EMPTY opaque
 reference in the middle of the fmtp line in this example.

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

4.11. Sportsline "headlines" message sent to your phone/pager/fax

 (i) phone
       INVITE sip:R2FB@pint.wwos.skynet.com  SIP/2.0
       Via: SIP/2.0/UDP 169.130.12.5
       To:
 sip:1-900-123-456-7@wwos.skynet.com;user=phone;phone-context=+1
       From: sip:fred.football.fan@skynet.com
       Call-ID: 19971205T234505.56.78@chinet.net
       CSeq: 4721 INVITE
       Subject: Wonderful World Of Sports NFL Final Scores
       Content-type: application/sdp
       Content-Length: 220
       v=0
       o=- 2353687800 2353687800 IN IP4 128.3.4.5
       s=R2FB
       i=NFL Final Scores
       e=fred.football.fan@skynet.com
       c=TN  RFC2543 +44-1794-8331013
       t=2353687800 0
       m=audio 1 voice x-pay
       a=fmtp:x-pay opr:mci.com/md5:<crypto signature>
 (ii) fax
       INVITE sip:R2FB@pint.wwos.skynet.com  SIP/2.0
       Via: SIP/2.0/UDP 169.130.12.5
       To: sip:1-900-123-456-7@wwos.skynet.com;user=phone;
           phone-context=+1
       From: sip:fred.football.fan@skynet.com
       Call-ID: 19971205T234505.56.78@chinet.net
       CSeq: 4722 INVITE
       Subject: Wonderful World Of Sports NFL Final Scores
       Content-type: application/sdp
       Content-Length: 217
       v=0
       o=- 2353687820 2353687820 IN IP4 128.3.4.5
       s=R2FB
       i=NFL Final Scores
       e=fred.football.fan@skynet.com
       c=TN  RFC2543 +44-1794-8331010
       t=2353687820 0
       m=text 1 fax x-pay
       a=fmtp:x-pay opr:mci.com/md5:<crypto signature>

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

 (iii) pager
       INVITE sip:R2FB@pint.wwos.skynet.com  SIP/2.0
       Via: SIP/2.0/UDP 169.130.12.5
       To: sip:1-900-123-456-7@wwos.skynet.com;user=phone;
           phone-context=+1
       From: sip:fred.football.fan@skynet.com
       Call-ID: 19971205T234505.56.78@chinet.net
       CSeq: 4723 INVITE
       Subject: Wonderful World Of Sports NFL Final Scores
       Content-type: application/sdp
       Content-Length: 219
       v=0
       o=- 2353687840 2353687840 IN IP4 128.3.4.5
       s=R2FB
       i=NFL Final Scores
       e=fred.football.fan@skynet.com
       c=TN  RFC2543 +44-1794-8331015
       t=2353687840 0
       m=text 1 pager x-pay
       a=fmtp:x-pay opr:mci.com/md5:<crypto signature>
 Note that these are all VERY similar.

4.12. Automatically giving someone a fax copy of your phone bill

    INVITE sip:BillsRUs@pint.sprint.com SIP/2.0
    Via: SIP/2.0/UDP 169.130.12.5
    To: sip:+1-555-888-1234@fbi.gov;user=phone
    From: sip:agent.mulder@fbi.gov
    Call-ID: 19991231T234505.56.78@fbi.gov
    CSeq: 911 INVITE
    Subject: Itemised Bill for January 98
    Content-type: application/sdp
    Content-Length: 247
    v=0
    o=- 2353687860 2353687860 IN IP4 128.3.4.5
    s=BillsRUs
    i=Joe Pendleton's Phone Bill
    e=agent.mulder@fbi.gov
    c=TN  RFC2543  +1-202-833-1010
    t=2353687860 0
    m=text 1  fax x-files-id
    a=fmtp:x-files-id opr:fbi.gov/jdcn-123@45:3des;base64,<signature>

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

 Note: in this case the opaque reference is a collection of data used
 to convince the Executive System that the requester has the right to
 get this information, rather than selecting the particular content
 (the A party in the To: field of the SIP "wrapper" does that alone).

5. Security Considerations

5.1. Basic Principles for PINT Use

 A PINT Gateway, and the Executive System(s) with which that Gateway
 is associated, exist to provide service to PINT Requestors. The aim
 of the PINT protocol is to pass requests from those users on to a
 PINT Gateway so an associated Executive System can service those
 requests.

5.1.1. Responsibility for service requests

 The facility of making a GSTN-based call to numbers specified in the
 PINT request, however, comes with some risks. The request can specify
 an incorrect telephone of fax number. It is also possible that the
 Requestor has purposely entered the telephone number of an innocent
 third party. Finally, the request may have been intercepted on its
 way through any intervening PINT or SIP infrastructure, and the
 request may have been altered.
 In any of these cases, the result may be that a call is placed
 incorrectly. Where there is intent or negligence, this may be
 construed as harassment of the person incorrectly receiving the call.
 Whilst the regulatory framework for misuse of Internet connections
 differs throughout the world and is not always mature, the rules
 under which GSTN calls are made are much more settled. Someone may be
 liable for mistaken or incorrect calls.
 Understandably, the GSTN Operators would prefer that this someone is
 not them, so they will need to ensure that any PINT Gateway and
 Executive System combination does not generate incorrect calls
 through some error in the Gateway or Executive system implementation
 or GSTN-internal communications fault. Equally, it is important that
 the Operator can show that they act only on requests that they have
 good reason to believe are correct. This means that the Gateway must
 not pass on requests unless it is sure that they have not been
 corrupted in transit from the Requestor.
 If a request can be shown to have come from a particular Requestor
 and to have been acted on in good faith by the PINT service provider,
 then responsibility for making requests may well fall to the
 Requestor rather than the Operator who executed these requests.

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

 Finally, it may be important for the PINT service provider to be able
 to show that they act only on requests for which they have some
 degree of assurance of origin. In many jurisdictions, it is a
 requirement on GSTN Operators that they place calls only when they
 can, if required, identify the parties to the call (such as when
 required to carry out a Malicious Call Trace). It is at least likely
 that the provider of PINT services will have a similar responsibility
 placed on them.
 It follows that the PINT service provider may require that the
 identity of the Requestor be confirmed. If such confirmation is not
 available, then they may be forced (or choose) not to provide
 service. This identification may require personal authentication of
 the Requesting User.

5.1.2. Authority to make requests

 Where GSTN resources are used to provide a PINT service, it is at
 least possible that someone will have to pay for it. This person may
 not be the Requestor, as, for example, in the case of existing GSTN
 split-charging services like free phone in which the recipient of a
 call rather than the originator is responsible for the call cost.
 This is not, of course, the only possibility; for example, PINT
 service may be provided on a subscription basis, and there are a
 number of other models. However, whichever model is chosen, there may
 be a requirement that the authority of a Requestor to make a PINT
 request is confirmed.
 If such confirmation is not available, then, again, the PINT Gateway
 and associated Executive System may choose not to provide service.

5.1.3. Privacy

 Even if the identity of the Requesting User and the Authority under
 which they make their request is known, there remains the possibility
 that the request is either corrupted, maliciously altered, or even
 replaced whilst in transit between the Requestor and the PINT
 Gateway.
 Similarly, information on the Authority under which a request is made
 may well be carried within that request. This can be sensitive
 information, as an eavesdropper might steal this and use it within
 their own requests. Such authority SHOULD be treated as if it were
 financial information (such as a credit card number or PIN).

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

 The data authorizing a Requesting User to make a PINT request should
 be known only to them and the service provider. However, this
 information may be in a form that does not match the schemes normally
 used within the Internet. For example, X.509 certificates[14] are
 commonly used for secured transactions on the Internet both in the IP
 Security Architecture[12] and in the TLS protocol[13], but the GSTN
 provider may only store an account code and PIN (i.e. a fixed string
 of numbers).
 A Requesting User has a reasonable expectation that their requests
 for service are confidential. For some PINT services, no content is
 carried over the Internet; however, the telephone or fax numbers of
 the parties to a resulting service calls may be considered sensitive.
 As a result, it is likely that the Requestor (and their PINT service
 provider) will require that any request that is sent across the
 Internet be protected against eavesdroppers; in short, the requests
 SHOULD to be encrypted.

5.1.4. Privacy Implications of SUBSCRIBE/NOTIFY

 Some special considerations relate to monitoring sessions using the
 SUBSCRIBE and NOTIFY messages. The SUBSCRIBE message that is used to
 register an interest in the disposition of a PINT service transaction
 uses the original Session Description carried in the related INVITE
 message. This current specification does not restrict the source of
 such a SUBSCRIBE message, so it is possible for an eavesdropper to
 capture an unprotected session description and use this in a
 subsequent SUBSCRIBE request. In this way it is possible to find out
 details on that transaction that may well be considered sensitive.
 The initial solution to this risk is to recommend that a session
 description that may be used within a subsequent SUBSCRIBE message
 SHOULD be protected.
 However, there is a further risk; if the origin-field used is
 "guessable" then it might be possible for an attacker to reconstruct
 the session description and use this reconstruction within a
 SUBSCRIBE message.
 SDP (see section 6 of [2], "o=" field) does not specify the mechanism
 used to generate the sess-id field, and suggests that a method based
 on timestamps produced by Network Time Protocol [16] can be used.
 This is sufficient to guarantee uniqueness, but may allow the value
 to be guessed, particularly if other unprotected requests from the
 same originator are available.

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

 Thus, to ensure that the session identifier is not guessable the
 techniques described in section 6.3 of [17] can be used when
 generating the origin-field for a session description to be used
 inside a PINT INVITE message. If all requests from (and responses to)
 a particular PINT requesting entity are protected, then this is not
 needed. Where such a situation is not assured, AND where session
 monitoring is supported, then a method by which an origin-field
 within a session description is not guessable SHOULD be used.

5.2. Registration Procedures

 Any number of PINT Gateways may register to provide the same service;
 this is indicated by the Gateways specifying the same "userinfo" part
 in the To: header field of the REGISTER request. Whilst such
 ambiguity would be unlikely to occur with the scenarios covered by
 "core" SIP, it is very likely for PINT; there could be any number of
 service providers all willing to support a "Request-To-Fax" service,
 for example.
 Unless a request specifies the Gateway name explicitly, an
 intervening Proxy that acts on a registration database to which
 several Gateways have all registered is in a position to select from
 the registrands using whatever algorithm it chooses; in principle,
 any Gateway that has registered as "R2F" would be appropriate.
 However, this opens up an avenue for attack, and this is one in which
 a "rogue" Gateway operator stands to make a significant gain. The
 standard SIP procedure for releasing a registration is to send a
 REGISTER request with a Contact field having a wildcard value and an
 expires parameter with a value of 0. It is important that a PINT
 Registrar uses authentication of the Registrand, as otherwise one
 PINT service provider would be able to "spoof" another and remove
 their registration. As this would stop the Proxy passing any requests
 to that provider, this would both increase requests being sent to the
 rogue and stop requests going to the victim.
 Another variant on this attack would be to register a Gateway using a
 name that has been registered by another provider; thus a rogue
 Operator might register its Gateway as "R2C@pint.att.com", thereby
 hijacking requests.
 The solution is the same; all registrations by PINT Gateways MUST be
 authenticated; this includes both new or apparent replacement
 registrations, and any cancellation of current registrations. This
 recommendation is also made in the SIP specification, but for the
 correct operation of PINT, it is very important indeed.

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

5.3. Security mechanisms and implications on PINT service

 PINT is a set of extensions to SIP[1] and SDP[2], and will use the
 security procedures described in SIP. There are several implications
 of this, and these are covered here.
 For several of the PINT services, the To: header field of SIP is used
 to identify one of the parties to the resulting service call. The
 PINT Request-To-Call service is an example. As mentioned in the SIP
 specification, this field is used to route SIP messages through an
 infrastructure of Redirect and Proxy server between the corresponding
 User Agent Servers, and so cannot be encrypted. This means that,
 although the majority of personal or sensitive data can be protected
 whilst in transit, the telephone (or fax) number of one of the
 parties to a PINT service call cannot, and will be "visible" to any
 interception. For the PINT milestone services this may be acceptable,
 since the caller named in the To: service is typically a "well known"
 provider address, such as a Call Center.
 Another aspect of this is that, even if the Requesting User does not
 consider the telephone or fax numbers of the parties to a PINT
 service to be private, those parties might. Where PINT servers have
 reason to believe this might be the case they SHOULD encrypt the
 request, even if the Requestor has not done so. This could happen,
 for example, if a Requesting User within a company placed a PINT
 request and this was carried via the company's Intranet to their
 Proxy/firewall and thence over the Internet to a PINT Gateway at
 another location.
 If a request carries data that can be reused by an eavesdropper
 either to "spoof" the Requestor or to obtain PINT service by
 inserting the Requestor's authorization token into an eavesdropper's
 request, then this data MUST be protected. This is particularly
 important if the authorization token consists of static text (such as
 an account code and/or PIN).
 One approach is to encrypt the whole of the request, using the
 methods described in the SIP specification. As an alternative, it may
 be acceptable for the authorization token to be held as an opaque
 reference (see section 3.4.2.3 and examples 4.11 and 4.12), using
 some proprietary scheme agreed between the Requestor and the PINT
 service provider, as long as this is resistant to interception and
 re-use. Also, it may be that the authorization token cannot be used
 outside of a request cryptographically signed by the Requestor; if so
 then this requirement can be relaxed, as in this case the token
 cannot be re-used by another.  However, unless both the Requestor and
 the Gateway are assured that this is the case, any authorization
 token MUST be treated as sensitive, and so MUST be encrypted.

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

 A PINT request may contain data within the SDP message body that can
 be used more efficiently to route that request. For example, it may
 be that one Gateway and Executive System combination cannot handle a
 request that specifies one of the parties as a pager, whilst another
 can. Both gateways may have registered with a PINT/SIP Registrar, and
 this information may be available to intervening PINT/SIP Proxies.
 However, if the message body is encrypted, then the request cannot be
 decoded at the Proxy server, and so Gateway selection based on
 contained information cannot be made there.
 The result is that the Proxy may deliver the request to a Gateway
 that cannot handle it; the implication is that a PINT/SIP Proxy
 SHOULD consider its choice for the appropriate Gateway subject to
 correction, and, on receiving a 501 or 415 rejection from the first
 gateway chosen, try another. In this way, the request will succeed if
 at all possible, even though it may be delayed (and tie up resources
 in the inappropriate Gateways).
 This opens up an interesting avenue for Denial Of Service; sending a
 valid request that appears to be suitable for a number of different
 Gateways, and simply occupying those Gateways in decrypting a message
 requesting a service they cannot provide. As mentioned in section
 3.5.5.1, the choice of service name to be passed in the userinfo
 portion of the SIP Request-URI is flexible, and it is RECOMMENDED
 that names be chosen that allow a Proxy to select an appropriate
 Gateway without having to examine the SDP body part. Thus, in the
 example given here, the service might be called "Request-To-Page" or
 "R2P" rather than the more general use of "R2F", if there is a
 possibility of the SDP body part being protected during transit.
 A variation on this attack is to provide a request that is
 syntactically invalid but that, due to the encryption, cannot be
 detected without expending resources in decoding it. The effects of
 this form of attack can be minimised in the same way as for any SIP
 Invitation; the Proxy should detect the 400 rejection returned from
 the initial Gateway, and not pass the request onwards to another.
 Finally, note that the Requesting User may not have a prior
 relationship with a PINT Gateway, whilst still having a prior
 relationship with the Operator of the Executive System that fulfills
 their request. Thus there may be two levels of authentication and
 authorization; one carried out using the techniques described in the
 SIP specification (for use between the Requestor and the Gateway),
 with another being used between the Requesting User or the Requestor
 and the Executive System.

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

 For example, the Requesting User may have an account with the PINT
 service provider. That provider might require that requests include
 this identity before they will be convinced to provide service. In
 addition, to counter attacks on the request whilst it is in transit
 across the Internet, the Gateway may require a separate X.509-based
 certification of the request. These are two separate procedures, and
 data needed for the former would normally be expected to be held in
 opaque references inside the SDP body part of the request.
 The detailed operation of this mechanism is, by definition, outside
 the scope of an Internet Protocol, and so must be considered a
 private matter. However, one approach to indicating to the Requestor
 that such "second level" authentication or authorization is required
 by their Service Provider would be to ask for this inside the textual
 description carried with a 401 response returned from the PINT
 Gateway.

5.4. Summary of Security Implications

 From the above discussion, PINT always carries data items that are
 sensitive, and there may be financial considerations as well as the
 more normal privacy concerns. As a result, the transactions MUST be
 protected from interception, modification and replay in transit.
 PINT is based on SIP and SDP, and can use the security procedures
 outlined in [1] (sections 13 and 15). However, in the case of PINT,
 the SIP recommendation that requests and responses MAY be protected
 is not enough. PINT messages MUST be protected, so PINT
 Implementations MUST support SIP Security (as described in [1],
 sections 13 & 15), and be capable of handling such received messages.
 In some configurations, PINT Clients, Servers, and Gateways can be
 sure that they operate using the services of network level security
 [13], transport layer security [12], or physical security for all
 communications between them. In these cases messages MAY be exchanged
 without SIP security, since all traffic is protected already. Clients
 and servers SHOULD support manual configuration to use such lower
 layer security facilities.
 When using network layer security [13], the Security Policy Database
 MUST be configured to provide appropriate protection to PINT traffic.
 When using TLS, a port configured MUST NOT also be configured for
 non-TLS traffic. When TLS is used, basic authentication MUST be
 supported, and client-side certificates MAY be supported.

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

 Authentication of the Client making the request is required, however,
 so if this is not provided by the underlying mechanism used, then it
 MUST be included within the PINT messages using SIP authentication
 techniques. In contrast with SIP, PINT requests are often sent to
 parties with which a prior communications relationship exists (such
 as a Telephone Carrier). In this case, there may be a shared secret
 between the client and the PINT Gateway. Such PINT systems MAY use
 authentication based on shared secrets, with HTTP "basic
 authentication". When this is done, the message integrity and privacy
 must be guaranteed by some lower layer mechanism.
 There are implications on the operation of PINT here though. If a
 PINT proxy or redirect server is used, then it must be able to
 examine the contents of the IP datagrams carried. It follows that an
 end-to-end approach using network-layer security between the PINT
 Client and a PINT Gateway precludes the use of an intervening proxy;
 communication between the Client and Gateway is carried via a tunnel
 to which any intervening entity cannot gain access, even if the IP
 datagrams are carried via this node. Conversely, if a "hop-by-hop"
 approach is used, then any intervening PINT proxies (or redirect
 servers) are, by implication, trusted entities.
 However, if there is any doubt that there is an underlying network or
 transport layer security association in place, then the players in a
 PINT protocol exchange MUST use encryption and authentication
 techniques within the protocol itself. The techniques described in
 section 15 of RFC2543 MUST be used, unless there is an alternative
 protection scheme that is agreed between the parties. In either case,
 the content of any message body (or bodies) carried within a PINT
 request or response MUST be protected; this has implications on the
 options for routing requests via Proxies (see 5.3).
 Using SIP techniques for protection, the Request-URI and To: fields
 headers within PINT requests cannot be protected. In  the baseline
 PINT services these fields may contain sensitive information. This is
 a consideration, and if these data ARE considered sensitive, then
 this will preclude the sole use of SIP techniques; in such a
 situation, transport [12] or network layer [13] protection mechanisms
 MUST be used.
 As a final point, this choice will in turn have an influence on the
 choice of transport layer protocol that can be used; if a TLS
 association is available between two nodes, then TCP will have to be
 used. This is different from the default behaviour of SIP (try UDP,
 then try TCP if that fails).

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

6. Deployment considerations and the Relationship PINT to I.N.

 (Informative)

6.1. Web Front End to PINT Infrastructure

 It is possible that some other protocol may be used to communicate a
 Requesting User's requirements. Due to the high numbers of available
 Web Browsers and servers it seems likely that some PINT systems will
 use HTML/HTTP as a "front end". In this scenario, HTTP will be used
 over a connection from the Requesting User's Web Browser (WC) to an
 Intermediate Web Server (WS). This will be closely associated with a
 PINT Client (using some unspecified mechanism to transfer the data
 from the Web Server to the PINT Client). The PINT Client will
 represent the Requesting User to the PINT Gateway, and thus to the
 Executive System that carries out the required action.
  [WC]------[WS]
            [PC]
              \
               \
              [PG]
              [XS]
              Figure 2: Basic "Web-fronted" Configuration

6.2. Redirects to Multiple Gateways

 It is quite possible that a given PINT Gateway is associated with an
 Executive System (or systems) that can connect to the GSTN at
 different places. Equally, if there is a chain of PINT Servers, then
 each of these intermediate or proxy servers (PP) may be able to route
 PINT requests to Executive Systems that connect at specific points to
 the GSTN. The result of this is that there may be more than one PINT
 Gateway or Executive System that can deal with a given request. The
 mechanisms by which the choice on where to deliver a request are
 outside the scope of this document.
  [WC]------[WS]                 [WC]------[WS]
            [PC]                           [PC]
              \                              \
               \                              \
              [PG]                           [PP]
     .........[XS].........                  /  \
     :                    :                 /    \
                                         [PG]    [PG]
                                         [XS]    [XS]
               Figure 3: Multiple Access Configurations

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

 However, there do seem to be two approaches. Either a Server that
 acts as a proxy or redirect will select the appropriate Gateway
 itself and will cause the request to be sent on accordingly, or a
 list of possible Locations will be returned to the Requesting User
 from which they can select their choice.
 In SIP, the implication is that, if a proxy cannot resolve to a
 single unique match for a request destination, then a response
 containing a list of the choices should be returned to the Requesting
 User for selection. This is not too likely a scenario within the
 normal use of SIP.
 However, within PINT, such ambiguity may be quite common; it implies
 that there are a number of possible providers of a given service.

6.3. Competing PINT Gateways REGISTERing to offer the same service

 With PINT, the registration is not for an individual but instead for
 a service that can be handled by a service provider. Thus, one can
 envisage a registration by the PINT Server of the domain telcoA.com
 of its ability to support the service R2C as "R2C@telcoA.com", sent
 to an intermediary server that acts as registrar for the
 "broker.telcos.com" domain from "R2C@pint.telcoA.com" as follows:
       REGISTER sip:registrar@broker.telcos.com SIP/2.0
       To: sip:R2C@pint.telcoA.com
       From: sip:R2C@pint.telcoA.com
       ...
 This is the standard SIP registration service.
 However, what happens if there are a number of different Service
 Providers, all of whom support the "R2C" service? Suppose there is a
 PINT system at domain "broker.com". PINT clients requesting a
 Request-to-Call service from broker.com might be very willing to be
 redirected or proxied to any one of the various service providers
 that had previously registered with the registrar. PINT servers might
 also be interested in providing service for requests that did not
 specify the service provider explicitly, as well as those requests
 that were directed "at them".
 To enable such service, PINT servers would REGISTER at the broker
 PINT server registrations of the form:
       REGISTER sip:registrar@broker.com SIP/2.0
       To: sip:R2C@broker.com
       From: sip:R2C@pint.telcoA.com

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

 When several such REGISTER messages appear at the registrar, each
 differing only in the URL in the From: line, the registrar has many
 possibilities, e.g.:
 (i)  it overwrites the prior registration for "R2C@broker.telcos.com"
      when the next comes in;
 (ii) it rejects the subsequent registration for
      "R2C@broker.telcos.com";
 (iii) it maintains all such registrations.
 In this last case, on receiving an Invitation for the "general"
 service, either:
     (iii.1) it passes on the invitation to all registered service
             providers, returning a collated response with all
             acceptances, using multiple Location: headers,
 or
     (iii.2) it silently selects one of the registrations (using, for
             example, a "round robin" approach) and routes the Invitation
             and response onwards without further comment.
 As an alternative to all of the above approaches, it:
 (iv) may choose to not allow registrations for the "general" service,
      rejecting all such REGISTER requests.
 The algorithm by which such a choice is made will be implementation-
 dependent, and is outside the scope of PINT. Where a behaviour is to
 be defined by requesting users, then some sort of call processing
 language might be used to allow those clients, as a pre-service
 operation, to download the behaviour they expect to the server making
 such decisions. This, however, is a topic for other protocols, not
 for PINT.

6.4. Limitations on Available Information and Request Timing for

   SUBSCRIBE
 A reference configuration for PINT is that service requests are sent,
 via a PINT Gateway, to an Executive System that fulfills the Service
 Control Function (SCF) of an Intelligent Network (see [11]). The
 success or failure of the resulting service call may be information
 available to the SCF and so may potentially be made available to the
 PINT Gateway. In terms of historical record of whether or not a
 service succeeded, a large SCF may be dealing with a million call
 attempts per hour. Given that volume of service transactions, there

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

 are finite limits beyond which it cannot store service disposition
 records; expecting to find out if a Fax was sent last month from a
 busy SCF is unrealistic.
 Other status changes, such as that on completion of a successful
 service call, require the SCF to arrange monitoring of the service
 call in a way that the service may not do normally, for performance
 reasons. In most implementations, it is difficult efficiently to
 interrupt a service to change it once it has begun execution, so it
 may be necessary to have two different services; one that sets GSTN
 resources to monitor service call termination, and one that doesn't.
 It is unlikely to be possible to decide that monitoring is required
 once the service has started.
 These factors can have implications both on the information that is
 potentially available at the PINT Gateway, and when a request to
 register interest in the status of a PINT service can succeed. The
 alternative to using a general SCF is to provide a dedicated Service
 Node just for PINT services. As this node is involved in placing all
 service calls, it is in a position to collect the information needed.
 However, it may well still not be able to respond successfully to a
 registration of interest in call state changes once a service logic
 program instance is running.
 Thus, although a Requesting User may register an interest in the
 status of a service request, the PINT Gateway may not be in a
 position to comply with that request. Although this does not affect
 the protocol used between the Requestor and the PINT Gateway, it may
 influence the response returned. To avoid the problem of changing
 service logic once running, any registration of interest in status
 changes should be made at or before the time at which the service
 request is made.
 Conversely, if a historical request is made on the disposition of a
 service, this should be done within a short time after the service
 has completed; the Executive System is unlikely to store the results
 of service requests for long; these will have been processed as AMA
 (Automatic Message Accounting) records quickly, after which the
 Executive System has no reason to keep them, and so they may be
 discarded.
 Where the PINT Gateway and the Executive System are intimately
 linked, the Gateway can respond to status subscription requests that
 occur while a service is running. It may accept these requests and
 simply not even try to query the Executive System until it has
 information that a service has completed, merely returning the final
 status. Thus the PINT Requestor may be in what it believes is a
 monitoring state, whilst the PINT Gateway has not even informed the

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

 Executive System that a request has been made. This will increase the
 internal complexity of the PINT Gateway in that it will have a
 complex set of interlocking state machines, but does mean that status
 registration and indication CAN be provided in conjunction with an
 I.N. system.

6.5. Parameters needed for invoking traditional GSTN Services within

   PINT
 This section describes how parameters needed to specify certain
 traditional GSTN services can be carried within PINT requests.

6.5.1. Service Identifier

 When a Requesting User asks for a service to be performed, he or she
 will, of course, have to specify in some way which service. This can
 be done in the URLs within the To: header and the Request-URI (see
 section 3.5.5.1).

6.5.2. A and B parties

 With the Request-to-Call service, they will also need to specify the
 A and B parties they want to be engaged in the resulting service
 call. The A party could identify, for example, the Call Center from
 which they want a call back, whilst the B party is their telephone
 number (i.e. who the Call Center agent is to call).
 The Request-to-Fax and Request-to-Hear-Content services require the B
 party to be specified (respectively the telephone number of the
 destination Fax machine or the telephone to which spoken content is
 to be delivered), but the A party is a Telephone Network based
 resource (either a Fax or speech transcoder/sender), and is implicit;
 the Requesting User does not (and cannot) specify it.
 With the "Fax-Back" variant of the Request-to-Fax service, (i.e.
 where the content to be delivered resides on the GSTN) they will also
 have specify two parties. As before, the B party is the telephone
 number of the fax machine to which they want a fax to be sent.
 However, within this variant the A party identifies the "document
 context" for the GSTN-based document store from which a particular
 document is to be retrieved; the analogy here is to a GSTN user
 dialling a particular telephone number and then entering the document
 number to be returned using "touch tone" digits. The telephone number
 they dial is that of the document store or A party, with the "touch
 tone" digits selecting the document within that store.

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

6.5.3. Other Service Parameters

 In terms of the extra parameters to the request, the services again
 differ. The Request-to-Call service needs only the A and B parties.
 Also it is convenient to assert that the resulting service call will
 carry voice, as the Executive System within the destination GSTN may
 be able to check that assertion against the A and B party numbers
 specified and may treat the call differently.
 With the Request-to-Fax and Request-to-Hear-Content services, the
 source information to be transcoded is held on the Internet. That
 means either that this information is carried along with the request
 itself, or that a reference to the source of this information is
 given.
 In addition, it is convenient to assert that the service call will
 carry fax or voice, and, where possible, to specify the format for
 the source information.
 The GSTN-based content or "Fax-Back" variant of the Request-to-Fax
 service needs to specify the Document Store number and the Fax
 machine number to which the information is to be delivered. It is
 convenient to assert that the call will carry Fax data, as the
 destination Executive System may be able to check that assertion
 against the document store number and that of the destination Fax
 machine.
 In addition, the document number may also need to be sent. This
 parameter is an opaque reference that is carried through the Internet
 but has significance only within the GSTN. The document store number
 and document number together uniquely specify the actual content to
 be faxed.

6.5.4. Service Parameter Summary

 The following table summarises the information needed in order to
 specify fully the intent of a GSTN service request. Note that it
 excludes any other parameters (such as authentication or
 authorisation tokens, or Expires: or CallId: headers) that may be
 used in a request.

Service ServiceID AParty BParty CallFmt Source SourceFmt ——- ——— —— —— ——- —— ——-

R2C         x         x         x       voice       -          -
R2F         x         -         x        fax      URI/IL    ISF/ILSF
R2FB        x         x         x        fax        OR         -
R2HC        x         -         x       voice     URI/IL    ISF/ILSF

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

 In this table, "x" means that the parameter is required, whilst "-"
 means that the parameter is not required.
 The Services listed are Request-to-Call (R2C), Request-to-Fax (R2F),
 the GSTN-based content or "Fax-back" Variant of Request-to-Fax
 (R2FB), and Request-to-Hear-Content (R2HC).
 The Call Format parameter values "voice" or "fax" indicate the kind
 of service call that results.
 The Source Indicator "URI/IL" implies that the information is either
 an Internet source reference (a Universal Resource Identifier, or
 URI) or is carried "in-line" with the message. The Source indicator
 "OR" means that the value passed is an Opaque Reference that should
 be carried along with the rest of the message but is to be
 interpreted only within the destination (GSTN) context. As an
 alternative, it could be given as a "local" reference with the "file"
 style, or even using a partial reference with the "http" style.
 However, the way in which such a reference is interpreted is a matter
 for the receiving PINT Server and Executive System; it remains, in
 effect, an opaque reference.
 The Source Format value "ISF/ILSF" means that the format of the
 source is specified either in terms of the URI or that it is carried
 "in-line".  Note that, for some data, the format either can be
 detected by inspection or, if all else fails, can be assumed from the
 URI (for example, by assuming that the file extension part of a URL
 indicates the data type). For an opaque reference, the Source Format
 is not available on the Internet, and so is not given.

6.6. Parameter Mapping to PINT Extensions

 This section describes the way in which the parameters needed to
 specify a GSTN service request fully might be carried within a "PINT
 extended" message. There are other choices, and these are not
 precluded. However, in order to ensure that the Requesting User
 receives the service that they expect, it is necessary to have some
 shared understanding of the parameters passed and the behaviour
 expected of the PINT Server and its attendant Executive System.
 The Service Identifier can be sent as the userinfo element of the
 Request-URI. Thus, the first line of a PINT Invitation would be of
 the form:
       INVITE <serviceID>@<pint-server>.<domain>  SIP/2.0

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

 The A Party for the Request-to-Call and "Fax-back" variant of
 Request-to-Fax service can be held in the "To:" header field. In this
 case the "To:" header value will be different from the Request-URI.
 In the services where the A party is not specified, the "To:" field
 is free to repeat the value held in the Request-URI. This is the case
 for Request-to-Fax and Request-to-Hear-Content services.
 The B party is needed in all these milestone services, and can be
 held in the enclosed SDP sub-part, as the value of the "c=" field.
 The call format parameter can be held as part of the "m=" field
 value.  It maps to the "transport protocol" element as described in
 section 3.4.2 of this document.
 The source format specifier is held in the "m=", as a type and either
 "-" or sub-type. The latter is normally required for all services
 except Request-to-Call or "Faxback", where the "-" form may be used.
 As shown earlier, the source format and source are not always
 required when generating requests for services. However, the
 inclusion in all requests of a source format specifier can make
 parsing the request simpler and allows for other services to be
 specified in the future, and so values are always given. The source
 format parameter is covered in section 3.4.2 as the "media type"
 element.
 The source itself is identified by an "a=fmtp:" field value, where
 needed. With the exception of the Request-to-Call service, all
 invitations will normally include such a field. From the perspective
 of the SDP extensions, it can be considered as qualifying the media
 sub-type, as if to say, for example, "when I say jpeg, what I mean is
 the following".
 In summary, the parameters needed by the different services are
 carried in fields as shown in the following table:

Service Svc Param PINT/SIP or SDP field used Example value ——- ——— ————————– ————-

R2C
        ServiceID:   <SIP Request-URI userinfo>      R2C
        AParty:      <SIP To: field>                 sip:123@p.com
        BParty:      <SDP c= field>                  TN RFC2543 4567
        CallFormat:  <SDP transport protocol
                          sub-field of m= field>     voice
        SourceFmt:   <SDP media type sub-field
                          of m= field>               audio
                     (--- only "-" sub-type
                          sub-field value used)      ---
        Source:      (--- No source specified)       ---

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

R2F
        ServiceID:   <SIP Request-URI userinfo>      R2F
        AParty:      (--- SIP To: field not used) sip:R2F@pint.xxx.net
        BParty:      <SDP c= field>               TN RFCxxx +441213553
        CallFormat:  <SDP transport protocol
                          sub-field of m= field>     fax
        SourceFmt:   <SDP media type sub-field
                          of m= field>               image
                     <SDP media sub-type sub-field
                          of m= field>               jpeg
        Source:      <SDP a=fmtp: field qualifying
                          preceding m= field>    a=fmtp:jpeg<uri-ref>
R2FB
        ServiceID:   <SIP Request-URI userinfo>      R2FB
        AParty:      <SIP To: field>              sip:1-730-1234@p.com
        BParty:      <SDP c= field>               TN RFCxxx +441213553
        CallFormat:  <SDP transport protocol
                          sub-field of m= field>     fax
        SourceFmt:   <SDP media type sub-field
                          of m= field>               image
                     <SDP media sub-type sub-field
                          of m= field>               jpeg
        Source:      <SDP a=fmtp: field qualifying
                          preceding m= field>     a=fmtp:jpeg opr:1234
R2HC
        ServiceID:   <SIP Request-URI userinfo>      R2HC
        AParty:      (--- SIP To: field not used) sip:R2HC@pint.ita.il
        BParty:      <SDP c= field>               TN RFCxxx +441213554
        CallFormat:  <SDP transport protocol
                          sub-field of m= field>     voice
        SourceFmt:   <SDP media type sub-field
                          of m= field>               text
                     <SDP media sub-type sub-field
                          of m= field>               html
        Source:      <SDP a=fmtp: field qualifying
                          preceding m= field>     a=fmtp:html<uri-ref>

7. References

 [1]  Handley, M., Schooler, E., Schulzrinne, H. and J. Rosenberg,
      "SIP: Session Initiation Protocol", RFC 2543, March 1999.
 [2]  Handley, M. and  V. Jacobsen, "SDP: Session Description
      Protocol", RFC 2327, April 1998.

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

 [3]  Freed, N. and  N. Borenstein, "Multipurpose Internet Mail
      Extensions (MIME) Part One: Format of Internet Message Bodies",
      RFC 2045, November 1996.
 [4]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
      Extensions (MIME) Part Two: Media Types", RFC 2046, November
      1996.
 [5]  The Unicode Consortium, "The Unicode Standard -- Version 2.0",
      Addison-Wesley, 1996.
 [6]  ITU-T Study Group 2, "E.164 - The International Public Network
      Numbering Plan", ITU-T, June 1997.
 [7]  Lu, H., Krishnaswamy, M., Conroy, L., Bellovin, S., Burg, F.,
      DeSimone, A., Tewani, K., Davidson, P., Schulzrinne, H. and K.
      Vishwanathan "Toward the PSTN/Internet Inter-Networking--Pre-
      PINT Implementations", RFC 2458, November 1998.
 [8]  ITU-T Study Group XI, "Q.763 - Formats and Codes for the ISDN
      User Part of SS No7" ITU-T, August 1994.
 [9]  Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
      Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
 [10] Crocker, D., "Standard for the format of ARPA Internet text
      messages", STD 11, RFC 822, August 1982.
 [11] ITU-T Study Group XI, "Q.1204 - IN Distributed Functional Plane
      Architecture", ITU-T, February 1994.
 [12] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
      2246, January 1999.
 [13] Kent, S. and R. Atkinson, "Security Architecture for the
      Internet Protocol", RFC 2401, November 1998.
 [14] Housley, R., Ford, W., Polk W. and D. Solo, "Internet X.509
      Public Key Infrastructure Certificate and CRL Profile", RFC
      2459, January 1999.
 [15] Crocker, D. and P. Overall, "Augmented BNF for Syntax
      Specifications: ABNF", RFC 2234, November 1997.
 [16] Mills, D., "Network Time Protocol (version 3) specification and
      implementation", RFC 1305, March 1992.

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

 [17] Eastlake, D., Crocker, S. and J.Schiller, "Randomness
      Recommendations for Security", RFC 1750, December 1994.
 [18] Mockapetris, P., "Domain Names - Implementation and
      Specification", STD 13, RFC 1035, November 1987.
 [19] Levinson, E., "The MIME Multipart/Related Content-type" RFC
      2387, August 1998.

8. Acknowledgements

 The authors wish to thank the members of the PINT working group for
 comments that were helpful to the preparation of this specification.
 Ian Elz's comments were extremely useful to our understanding of
 internal PSTN operations. The SUBSCRIBE and NOTIFY requests were
 first suggested by Henning Schulzrinne and Jonathan Rosenberg. The
 suggestion to use an audio port of 0 to express that the phone is "on
 hold" (i.e. not receiving voice) is due to Ray Zibman. Finally,
 thanks to Bernie Hoeneisen for his close proofreading.

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

Appendix A: Collected ABNF for PINT Extensions

;; –(ABNF is specified in RFC 2234 [15])

;; –Variations on SDP definitions

connection-field = ["c=" nettype space addrtype space

                      connection-address CRLF]

; – this is the original definition from SDP, included for completeness ; – the following are PINT interpretations and modifications

nettype = ("IN"/"TN") ; – redefined as a superset of the SDP definition

addrtype = (INAddrType / TNAddrType) ; – redefined as a superset of the SDP definition

INAddrType = ("IP4"/"IP6") ; – this non-terminal added to hold original SDP address types

TNAddrType = ("RFC2543"/OtherAddrType)

OtherAddrType = (<X-Token>) ; – X-token is as defined in RFC2045

addr = (<FQDN> / <unicast-address> / TNAddr) ; – redefined as a superset of the original SDP definition ; – FQDN and unicast address as specified in SDP

TNAddr = (RFC2543Addr/OtherAddr) ; – TNAddr defined only in context of nettype == "TN"

RFC2543Addr = (INPAddr/LDPAddr)

INPAddr = "+" <POS-DIGIT> 0*1) tsp-attribute = tsp-tag "=" provider-domainname

tsp-tag = "tsp"

provider-domainname = <domain> ; – domain is defined in RFC1035

; – NOTE the following is redefined relative to the normal use in SDP pint-fmtp-attribute = "fmtp:" <subtype> <space> resolution

  • (<space> resolution)

(<space> ";" 1(<attribute>) *(<space> <attribute>)) ; – subtype as defined in RFC2046. ; – NOTE that this value MUST match a fmt on the ultimately preceeding ; – media-field ; – attribute is as defined in SDP

resolution = (uri-ref / opaque-ref / sub-part-ref)

uri-ref = uri-tag ":" <URI-Reference>

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

; – URI-Reference defined in RFC2396

uritag = "uri"

opaque-ref = opr-tag ":" 0*<uric>

opr-tag = "opr"

sub-part-ref = spr-tag ":" <Content-ID> ; – Content-ID is as defined in RFC2046 and RFC822

spr-tag = "spr"

strict-attribute = "require:" att-tag-list

att-tag-list = 1(PINT-att-tag-list / <att-field> /

                  pint-fmtp-tag-list)
                *(","
                  (PINT-att-tag-list / <att-field> /
                    pint-fmtp-tag-list)
                 )

; – att-field as defined in SDP

PINT-att-tag-list = (phone-context-tag / clir-tag /

                     q763-nature-tag / q763-plan-tag /
                     q763-INN-tag)

pint-fmtp-tag-list = (uri-tag / opr-tag / spr-tag)

;; –Variations on SIP definitions

clir-parameter = clir-tag "=" ("true" / "false")

q763-nature-parameter = Q763-nature-tag "=" Q763-natures

q763plan-parameter = Q763-plan-tag "=" q763plans

q763-INN-parameter = Q763-INN-tag "=" q763-INNs

tsp-parameter = tsp-tag "=" provider-domainname

phone-context-parameter = phone-context-tag "=" phone-context-ident

SIP-param = ( <transport-param> / <user-param> / <method-param> /

              <ttl-param> / <maddr-param> / <other-param> )

; – the values in this list are all as defined in SIP

PINT-param = ( clir-parameter / q763-nature-parameter /

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

              q763plan-parameter / q763-INN-parameter/
              tsp-parameter / phone-context-parameter )

URL-parameter = (SIP-param / PINT-param) ; – redefined SIP's URL-parameter to include ones defined in PINT

Require-header = "require:" 1(required-extensions)

  • ("," required-extensions)

; – NOTE this is redefined as a subset of the SIP definition ; – (from RFC2543/section 6.30)

required-extensions = ("org.ietf.sip.subscribe" /

                     "org.ietf.sdp.require")

Appendix B: IANA Considerations

 There are three kinds of identifier used in PINT extensions that
 SHOULD be registered with IANA, if a new value is specified. These
 are:
  • Media Format sub-types, as described in section 3.4.2 of this

document.

  • Private Attributes as mentioned in section 3.4.3
  • Private Phone Context values, as described in section 3.4.3.1.
 It should be noted that private Address Types (in section 3.4.1) have
 been explicitly excluded from this process, as they must be in the
 form of an X-Token.

B.1. Media Format Sub-types

 Taking these in turn, the media format sub-types are used within the
 PINT extensions to SDP to specify the attribute line that holds the
 data source definitions. In normal use, the values in this field are
 sub-types of MIME discrete types[4]. If a value other than an IANA-
 registered sub-type is to be used, then it should either be an X-
 Token (i.e. start with "X-") or it should be registered with IANA. if
 the intention is to describe a new MIME sub-type, then the procedures
 specified in RFC 2048 should be used. It is ASSUMED that any new MIME
 sub-type would follow the syntactic rules for interpretation of
 associated PINT fmtp lines defined in this document.
 Note that, in keeping with the SDP description, such registrations
 SHOULD include the "proto" field values within which they are
 defined; however, it is appropriate to specify only that they can be
 used with "all values of TNProto".

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

 Conversely, if the intent is to define a new way of including data
 source definitions within PINT, then it will be necessary to specify,
 in the documentation supporting any such new "PINT Media Format Sub-
 type" registration, the syntax of the associated "fmtp" attribute
 line, as the identifier serves to indicate the interpretation that
 should be made of format specific attribute lines "tagged" with such
 a sub-type.
 If the fmtp interpretation follows the PINT default, then it is
 adequate to mention this in the defining document rather than
 repeating the syntax definition given here (although, in this case,
 it is unclear why such a new registration would be required). As
 before, the Media Format sub-type SHOULD specify the values of
 "proto" field within which it is defined, but this can be "all values
 of TNProto".

B.2. Private Attributes

 Any proprietary attribute lines that are added may be registered with
 IANA using the procedures mentioned in [2]; the mechanism is the same
 as that used in SDP. If the attribute is defined for use only within
 PINT, then it may be appropriate to mention this in the supporting
 documentation. Note that, in the PINT 1.0 specification covered here,
 there is no mechanism to add such freshly registered attribute lines
 to a "require:" clause.

B.3. Private phone-contexts

 Within the session description used for PINT requests, a phone-
 context attribute may be used to specify the prefix or context within
 which an associated telephone-number (in a connection line) should be
 interpreted.
 For "public" phone contexts the prefix to be used MUST start with
 either a DIGIT or a "+". Private phone contexts may be registered
 with IANA that do NOT start with either of these characters. Such a
 prefix may be useful to identify a private network, potentially with
 an associated numeric ID (see example 4 in section 3.4.3.1). In the
 example, the prefix acts as the context for X-acme.com's private
 network numbering plan.
 It is recommended that any private context to be registered have the
 general form of a token including a domain name, optionally followed
 by a digit string or other token. The appropriate form of the initial
 token name space will be similar to that used for private or vendor
 registrations for sub-types (e.g. vnd.acme.com). However, note that
 the registration will be used to specify a customer's private network
 numbering plan format rather than being used generally for all of

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

 their equipment vendor's customer's; thus, fbi.gov would be
 appropriate, but lucent.com would not (unless the private network
 were to be that used by Lucent internally).
 In addition, the supporting documentation MUST either declare that
 there is no associated token, or define the syntax by which that
 token can be parsed (e.g. vnd.fbi.gov <space> 1*DIGIT). Note that the
 registration describes a format, not a value range; it is sufficient
 that the private context can be parsed, without the value being
 interpreted.
 In detail, the registration request SHOULD include:
  • Kind of registration (i.e. private phone-context attribute to be

used within the service description of PINT service requests)

  • Contact details for the person responsible for the registration

request (name, organisation, e-mail address, public telephone

    number)
 *  Private Prefix initial token name (e.g. vnd.fbi.gov)
 *  syntax for private context (e.g. "vnd.fbi.gov" <space> 1*DIGIT, or
    "vnd.gtn.gov.uk")
 *  Description of use (e.g. "This phone context declares an
    associated telephone number to be within the 'government
    telecommunications network'; the number is in an internal or
    private number plan form)
 *  Network Type and Address Type with which this private context is
    associated; If the "normal" telephone types (as specified in this
    document) are used, then the values would be shown as:
    "nettype=TN" , addrtype="RFC2543Addr". If, however, this context
    were to be used with another address type, then a reference to
    that address type name and the syntax of that address value would
    be required.
 In short, this context is the telephone equivalent of a "Net 10"
 address space behind a NAT, and the initial name (and contact
 information) shows the context within which that address is valid. It
 also specifies the format for the network and address types (and
 address value syntax) with which this context is associated.
 Of course, IANA may refer the requested registration to the IESG or
 an appropriate IETF working group for review, and may require
 revisions to be made before the registration is accepted.

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

Authors' Addresses

 Scott Petrack
 MetaTel, Inc.
 45 Rumford Ave.
 Waltham MA 02453-3844
 Phone: +1 (781)-891-9000
 EMail: scott.petrack@metatel.com
 Lawrence Conroy
 Siemens Roke Manor Research
 Roke Manor
 Old Salisbury Lane
 Romsey, Hampshire
 U.K.    SO51 0ZN
 Phone: +44 (1794) 833666
 EMail: lwc@roke.co.uk

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

Full Copyright Statement

 Copyright (C) The Internet Society (2000).  All Rights Reserved.
 This document and translations of it may be copied and furnished to
 others, and derivative works that comment on or otherwise explain it
 or assist in its implementation may be prepared, copied, published
 and distributed, in whole or in part, without restriction of any
 kind, provided that the above copyright notice and this paragraph are
 included on all such copies and derivative works.  However, this
 document itself may not be modified in any way, such as by removing
 the copyright notice or references to the Internet Society or other
 Internet organizations, except as needed for the purpose of
 developing Internet standards in which case the procedures for
 copyrights defined in the Internet Standards process must be
 followed, or as required to translate it into languages other than
 English.
 The limited permissions granted above are perpetual and will not be
 revoked by the Internet Society or its successors or assigns.
 This document and the information contained herein is provided on an
 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

 Funding for the RFC Editor function is currently provided by the
 Internet Society.

Petrack & Conroy Standards Track [Page 73]

1)
"-" <DIGIT>)/<DIGIT>) ; – POS-DIGIT and DIGIT as defined in SDP LDPAddr = <DIGIT> 0*(("-" <DIGIT>)/<DIGIT>) OtherAddr = 1*<uric> ; – OtherAdd defined in the context of OtherAddrType ; – uric is as defined in RFC2396 media-field = "m=" media <space> port <space> proto
                 1*(<space> fmt) <CRLF>
; – NOTE redefined as subset/relaxation of original SDP definition ; – space and CRLF as defined in SDP Petrack & Conroy Standards Track [Page 65] RFC 2848 The PINT Service Protocol June 2000 media = ("application"/"audio"/"image"/"text") ; – NOTE redefined as a subset of the original SDP definition ; – This could be any MIME discrete type; Only those listed are ; – used in PINT 1.0 port = ("0" / "1") ; – NOTE redefined from the original SDP definition; ; – 0 retains usual sdp meaning of "temporarily no media" ; – (i.e. "line is on hold") ; – (1 means there is media) proto = (INProto/TNProto) ; – redefined as a superset of the original SDP definition INProto = 1* (<alpha-numeric>) ; – this is the "classic" SDP protocol, defined if nettype == "IN" ; – alpha-numeric is as defined in SDP TNProto = ("voice"/"fax"/"pager") ; – this is the PINT protocol, defined if nettype == "TN" fmt = (<subtype> / "-") ; – NOTE redefined as a subset of the original SDP definition ; – subtype as defined in RFC2046, or "-". MUST be a subtype of type held ; – in associated media sub-field or the special value "-". attribute-fields = *("a=" attribute-list <CRLF>) ; – redefined as a superset of the definition given in SDP ; – CRLF is as defined in SDP attribute-list = 1(PINT-attribute / <attribute>) ; – attribute is as defined in SDP PINT-attribute = (clir-attribute / q763-nature-attribute /
                 q763plan-attribute / q763-INN-attribute /
                 phone-context-attribute / tsp-attribute /
                 pint-fmtp-attribute / strict-attribute)
clir-attribute = clir-tag ":" ("true" / "false") clir-tag = "clir" q763-nature-attribute = Q763-nature-tag ":" q763-natures q763-nature-tag = "Q763-nature" q763-natures = ("1" / "2" / "3" / "4") Petrack & Conroy Standards Track [Page 66] RFC 2848 The PINT Service Protocol June 2000 q763-plan-attribute = Q763-plan-tag ":" q763-plans q763-plan-tag = "Q763-plan" q763-plans = ("1" / "2" / "3" / "4" / "5" / "6" / "7") ; – of these, the meanings of 1, 3, and 4 are defined in the text q763-INN-attribute = Q763-INN-tag ":" q763-INNs q763-INN-tag = "Q763-INN" q763-INNs = ("0" / "1") phone-context-attribute = phone-context-tag ":" phone-context-ident phone-context-tag = "phone-context" phone-context-ident = network-prefix / private-prefix network-prefix = intl-network-prefix / local-network-prefix intl-network-prefix = "+" 1*<DIGIT> local-network-prefix = 1*<DIGIT> private-prefix = 1*excldigandplus 0*<uric> excldigandplus = (0x21-0x2d,0x2f,0x40-0x7d
/data/webs/external/dokuwiki/data/pages/rfc/rfc2848.txt · Last modified: 2000/06/14 19:26 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki