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

¬†¬†¬† 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>, ie 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:

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:

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

¬†¬†¬† 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.

¬†¬†¬† 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.

¬†¬†¬† 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]).

¬†¬†¬† 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 UK, 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:

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

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

¬†¬†¬† 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.

¬†¬†¬† 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.

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

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

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

¬†¬†¬† 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 (ie "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 (ie 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.

¬†¬†¬† 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.

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

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

¬†¬†¬† 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.

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

¬†¬†¬† 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" (ie 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.

¬†¬†¬† 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 at= 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:

¬†¬†¬† 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.

¬†¬†¬† 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

¬†¬†¬† 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

¬†¬†¬† 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

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.

¬†¬†¬†¬†¬†¬† 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

¬†¬†¬† 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.

¬†¬†¬†¬†¬†¬† 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 (ie 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.

¬†¬†¬† 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 IN
¬†¬†¬† (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.

¬†¬†¬† 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.

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:

¬†¬†¬† 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.

¬†¬†¬† 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 (ie 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, (ie
¬†¬†¬† 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.

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

¬†¬†¬† 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" (ie not receiving voice) is due to Ray Zibman. Finally,
¬†¬†¬† thanks to Bernie Hoeneisen for his close proofreading.

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

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

¬†¬†¬† 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 (ie 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 (eg 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 (ie 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 (eg vnd.fbi.gov)
¬†¬†¬† * syntax for private context (eg "vnd.fbi.gov" <space> 1*DIGIT, or
¬†¬†¬†¬†¬†¬† "vnd.gtn.gov.uk")
¬†¬†¬† * Description of use (eg "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.

¬†¬†¬† 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.