doc: Add RFC documents

1 files changed, 4091 insertions, 0 deletions

diff --git a/doc/rfc/rfc2848.txt b/doc/rfc/rfc2848.txt
new file mode 100644
index 0000000..0406d50
--- /dev/null
+++ b/doc/rfc/rfc2848.txt
@@ -0,0 +1,4091 @@
+
+
+
+
+
+
+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| Telephone  /
+| client  |<-------------->|  server |gatewy|=====|Syst| Network    \
+|_________|    protocol    /  cloud  |______|     |____|  Cloud     /
+                           \            \            /              \
+                           /\/\/\/\/\/\/\            \/\/\/\/\/\/\/\/
+
+                 Figure 1: PINT Functional Architecture
+
+   The system of PINT servers is represented as a cloud to emphasise
+   that a single PINT request might pass through a series of location
+   servers, proxy servers, and redirect servers, before finally reaching
+   the correct PINT gateway that can actually process the request by
+   passing it to the Telephone Network Cloud.
+
+   The PINT gateway might have a true telephone network interface, or it
+   might be connected via some other protocol or API to an "Executive
+   System" that is capable of invoking services within the telephone
+   cloud.
+
+   As an example, within an I.N. (Intelligent Network) system, the PINT
+   gateway might appear to realise the Service Control Gateway Function.
+   In an office environment, it might be a server adjunct to the office
+   PBX, connected to both the office LAN and the office PBX.
+
+   The Executive System that lies beyond the PINT gateway is outside the
+   scope of PINT.
+
+3.2. PINT Protocol Architecture
+
+   This section explains how SIP and SDP work in combination to convey
+   the information necessary to invoke telephone network sessions.
+
+   The following list summarises the extension features used in PINT
+   1.0.  Following on from this the features are considered separately
+   for SDP and then for SIP:
+
+   1)  Telephony URLs in SDP Contact Fields
+   2)  Refinement of SIP/SDP Telephony URLs
+       *   Inclusion of private dialling plans
+   3)  Specification of Telephone Service Provider (TSP) and/or phone-
+       context URL-parameters
+   4)  Data Objects as session media
+
+
+
+
+Petrack & Conroy            Standards Track                     [Page 9]
+
+RFC 2848               The PINT Service Protocol               June 2000
+
+
+   4a) Protocol Transport formats to indicate the treatment of the media
+       within the GSTN
+   5)  Implicit (Indirect) media streams and opaque arguments
+   6)  In-line data objects using multipart/mime
+   7)  Refinement/Clarification of Opaque arguments passed onwards to
+       Executive Systems
+       *   Framework for Presentation Restriction Indication
+       *   Framework for Q.763 arguments
+   8)  An extension mechanism for SDP to specify strictures and force
+       failure when a recipient does NOT support the specified
+       extensions, using "require" headers.
+   9)  Mandatory support for "Warning" headers to give more detailed
+       information on request disposition.
+   10) Mechanism to register interest in the disposition of a requested
+       service, and to receive indications on that disposition.
+
+   Both PINT and SIP rely on features of MIME[4]. The use of SIP 2.0 is
+   implied by PINT 1.0, and this also implies compliance with version
+   1.0 of MIME.
+
+3.2.1. SDP operation in PINT
+
+   The SDP payload contains a description of the particular telephone
+   network session that the requestor wishes to occur in the GSTN. This
+   information includes such things as the telephone network address
+   (i.e.  the "telephone number") of the terminal(s) involved in the
+   call, an indication of the media type to be transported (e.g. audio,
+   text, image or application data), and an indication if the
+   information is to be transported over the telephone network via
+   voice, fax, or pager transport. An indication of the content to be
+   sent to the remote telephone terminal (if there is any) is also
+   included.
+
+   SDP is flexible enough to convey these parameters independently. For
+   example, a request to send some text via voice transport will be
+   fulfilled by invoking some text-to-speech-over-the-phone service, and
+   a request to send text via fax will be fulfilled by invoking some
+   text-to-fax service.
+
+   The following is a list of PINT 1.0 enhancements and additions to
+   SDP.
+
+      a. A new network type "TN" and address types "RFC2543" and "X-..."
+         (section 3.4.1)
+      b. New media types "text", "image", and "application", new
+         protocol transport keywords "voice", "fax" and "pager" and the
+         associated format types and attribute tags (section 3.4.2)
+
+
+
+
+Petrack & Conroy            Standards Track                    [Page 10]
+
+RFC 2848               The PINT Service Protocol               June 2000
+
+
+      c. New format specific attributes for included content data
+         (section 3.4.2.4)
+      d. New attribute tags, used to pass information to the telephone
+         network (section 3.4.3)
+      e. A new attribute tag "require", used by a client to indicate
+         that some attribute is required to be supported in the server
+         (section 3.4.4)
+
+3.2.2. SIP Operation in PINT
+
+   SIP is used to carry the request for telephone service from the PINT
+   client to the PINT gateway, and may include a telephone number if
+   needed for the particular service. The following is a complete list
+   of PINT enhancements and additions to SIP:
+
+      f. The multipart MIME payloads (section 3.5.1)
+      g. Mandatory support for "Warning:" headers (section 3.5.2)
+      h. The SUBSCRIBE and NOTIFY, and UNSUBSCRIBE requests (section
+         3.5.3)
+      i. Require: headers (section 3.5.4)
+      j. A format for PINT URLS within a PINT request (section 3.5.5)
+      k. Telephone Network Parameters within PINT URLs (section 3.5.6)
+
+   Section 3.5.8 contains remarks about how BYE requests are used within
+   PINT. This is not an extension to baseline SIP; it is included here
+   only for clarification of the semantics when used with telephone
+   network sessions.
+
+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:
+
+         ------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
+
+         ----------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
+
+         ----------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
+
+      ----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
+
+
+      ----next
+      Content-Type: text/plain
+      Content-ID: 2@53655768
+      Content-Length:50
+
+      Hi Joe! Please call me asap at 555-1234.
+
+      ----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
+
+      --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
+
+      --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
+
+   --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
+
+   --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*(("-" <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))
+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]
+