draft-ietf-pint-protocol-00.txt   draft-ietf-pint-protocol-01.txt 
INTERNET-DRAFT Scott Petrack, INTERNET-DRAFT Scott Petrack,
Internet Engineering Task Force Metatel Internet Engineering Task Force Metatel
PINT Working Group Lawrence Conroy, PINT Working Group Lawrence Conroy,
Issued: 18th June 1999 Siemens Roke Manor Research Issued: 3 August 1999 Siemens Roke Manor Research
Expires: 18th December 1999 Expires: 14 January 2000
The PINT Service Protocol: The PINT Service Protocol:
Extensions to SIP and SDP for IP Access to Telephone Call Services Extensions to SIP and SDP for IP Access to Telephone Call Services
<draft-ietf-pint-protocol-00.txt> <draft-ietf-pint-protocol-01.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 10, line ? skipping to change at page 10, line ?
faxes, and receiving content over the telephone. The protocol is specified faxes, and receiving content over the telephone. The protocol is specified
as a set of enhancements and additions to the SIP 2.0 and SDP 2.0 protocols. as a set of enhancements and additions to the SIP 2.0 and SDP 2.0 protocols.
This document is intended for the PSTN-Internet Interworking (PINT) working This document is intended for the PSTN-Internet Interworking (PINT) working
group of the Internet Engineering Task Force. Comments are solicited and group of the Internet Engineering Task Force. Comments are solicited and
should be addressed to the working group's mailing list at should be addressed to the working group's mailing list at
pint@lists.research.bell-labs.com and/or the authors. pint@lists.research.bell-labs.com and/or the authors.
Petrack & Conroy [Page 1] Petrack & Conroy [Page 1]
<draft-ietf-pint-protocol-01.txt> PSP: Extensions to SIP and SDP June, 1999
Contents Contents
1. Introduction ......................................................... 4 1. Introduction ......................................................... 4
1.1 Glossary ............................................................ 5 1.1 Glossary ............................................................ 5
2. PINT Milestone Services .............................................. 6 2. PINT Milestone Services .............................................. 6
2.1 Request to Call ................................................. 6 2.1 Request to Call ................................................. 6
2.2 Request to Fax .................................................. 6 2.2 Request to Fax .................................................. 6
2.3 Request to Hear Content ......................................... 6 2.3 Request to Hear Content ......................................... 6
2.4 Relation between PINT milestone services and traditional 2.4 Relation between PINT milestone services and traditional
skipping to change at page 10, line ? skipping to change at page 10, line ?
3.5.8. BYE Requests in PINT ..................................... 28 3.5.8. BYE Requests in PINT ..................................... 28
4. Examples of PINT Requests and Responses .............................. 30 4. Examples of PINT Requests and Responses .............................. 30
4.1. A request to a call centre from an anonymous user to receive a 4.1. A request to a call centre from an anonymous user to receive a
phone call ..................................................... 30 phone call ..................................................... 30
4.2. A request from a non anonymous customer (John Jones) to receive a 4.2. A request from a non anonymous customer (John Jones) to receive a
phone call from a particular sales agent (Mary James) .......... 30 phone call from a particular sales agent (Mary James) .......... 30
4.3. A request to get a fax back .................................... 31 4.3. A request to get a fax back .................................... 31
Petrack & Conroy [Page 2] Petrack & Conroy [Page 2]
<draft-ietf-pint-protocol-01.txt> PSP: Extensions to SIP and SDP June, 1999
4.4. A request to have information read out over the phone .......... 32 4.4. A request to have information read out over the phone .......... 32
4.5. A request to send an included text page to a friend's pager .... 32 4.5. A request to send an included text page to a friend's pager .... 32
4.6. A request to send an image as a fax to phone number 4.6. A request to send an image as a fax to phone number
+972-9-956-1867 ................................................ 33 +972-9-956-1867 ................................................ 33
4.7. A request to read out over the phone two pieces of content in 4.7. A request to read out over the phone two pieces of content in
sequence ....................................................... 33 sequence ....................................................... 33
4.8. Request for the prices for ISDN to be sent to my fax machine ... 34 4.8. Request for the prices for ISDN to be sent to my fax machine ... 34
4.9. Request for a callback ......................................... 34 4.9. Request for a callback ......................................... 34
4.10.Sending a set of information in response to an enquiry ......... 34 4.10.Sending a set of information in response to an enquiry ......... 34
4.11.Sportsline "headlines" message sent to your phone/fax/pager .... 35 4.11.Sportsline "headlines" message sent to your phone/fax/pager .... 35
skipping to change at page 10, line ? skipping to change at page 10, line ?
9. Acknowledgements ..................................................... 53 9. Acknowledgements ..................................................... 53
Appendix A: Collected ABNF for PINT Extensions .......................... 54 Appendix A: Collected ABNF for PINT Extensions .......................... 54
Appendix B: IANA Considerations ......................................... 59 Appendix B: IANA Considerations ......................................... 59
Appendix C: Authors' Addresses .......................................... 61 Appendix C: Authors' Addresses .......................................... 61
Petrack & Conroy [Page 3] Petrack & Conroy [Page 3]
<draft-ietf-pint-protocol-01.txt> PSP: Extensions to SIP and SDP June, 1999
1. Introduction 1. Introduction
The desire to invoke certain telephone call services from the Internet has The desire to invoke certain telephone call services from the Internet has
been identified by many different groups (users, public and private network been identified by many different groups (users, public and private network
operators, call center service providers, equipment vendors, see [7]). The operators, call center service providers, equipment vendors, see [7]). The
generic scenario is as follows (when the invocation is successful): generic scenario is as follows (when the invocation is successful):
1. an IP host sends a request to a server on an IP network; 1. an IP host sends a request to a server on an IP network;
2. the server relays the request into a telephone network; 2. the server relays the request into a telephone network;
3. the telephone network performs the requested call service. 3. the telephone network performs the requested call service.
skipping to change at page 10, line ? skipping to change at page 10, line ?
A PINT user who wishes to invoke a service within the telephone network uses A PINT user who wishes to invoke a service within the telephone network uses
SIP to invite a remote PINT server into a session. The invitation contains SIP to invite a remote PINT server into a session. The invitation contains
an SDP description of the media session that the user would like to take an SDP description of the media session that the user would like to take
place. This might be a "sending a fax session" or a "telephone call place. This might be a "sending a fax session" or a "telephone call
session", for example. In a PINT service execution session the media is session", for example. In a PINT service execution session the media is
transported over the phone system, while in a SIP session the media is transported over the phone system, while in a SIP session the media is
normally transported over an internet. normally transported over an internet.
Petrack & Conroy [Page 4] Petrack & Conroy [Page 4]
<draft-ietf-pint-protocol-01.txt> PSP: Extensions to SIP and SDP June, 1999
When used to invoke a PINT service, SIP establishes an association between a When used to invoke a PINT service, SIP establishes an association between a
requesting PINT client and the PINT server that is responsible for invoking requesting PINT client and the PINT server that is responsible for invoking
the service within the telephone network. These two entities are not the the service within the telephone network. These two entities are not the
same entities as the telephone network entities involved in the telephone same entities as the telephone network entities involved in the telephone
network service. The SIP messages carry within their SDP payloads a network service. The SIP messages carry within their SDP payloads a
description of the telephone network media session. description of the telephone network media session.
Note that the fact that a PINT server accepts an invitation and a session is Note that the fact that a PINT server accepts an invitation and a session is
established is no guarantee that the media will be successfully transported. established is no guarantee that the media will be successfully transported.
(This is analogous to the fact that if a SIP invitation is accepted (This is analogous to the fact that if a SIP invitation is accepted
skipping to change at page 10, line ? skipping to change at page 10, line ?
request received from an PINT client. request received from an PINT client.
PINT Client - An Internet host that sends requests for invocation of a PINT PINT Client - An Internet host that sends requests for invocation of a PINT
Service, in accordance with this document. Service, in accordance with this document.
PINT Gateway - An Internet host that accepts requests for PINT Service and PINT Gateway - An Internet host that accepts requests for PINT Service and
dispatches them onwards towards a telephone network. dispatches them onwards towards a telephone network.
Petrack & Conroy [Page 5] Petrack & Conroy [Page 5]
<draft-ietf-pint-protocol-01.txt> PSP: Extensions to SIP and SDP June, 1999
Executive System - A system that interfaces to a telephone network that Executive System - A system that interfaces to a telephone network that
executes a PINT service, and to a PINT Server. It is not directly associated executes a PINT service, and to a PINT Server. It is not directly associated
with the Internet, and is represented by the PINT Server. with the Internet, and is represented by the PINT Server.
Requesting User - The initiator of a request for service. This role may be Requesting User - The initiator of a request for service. This role may be
distinct from that of the "party" to any telephone network call that results distinct from that of the "party" to any telephone network call that results
from the request. from the request.
(Service Call) Party - A person who is involved in a telephone network call (Service Call) Party - A person who is involved in a telephone network call
that results from the execution of a PINT service request, or a telephone that results from the execution of a PINT service request, or a telephone
skipping to change at page 10, line ? skipping to change at page 10, line ?
2.4 Relation between PINT milestone services and traditional telephone 2.4 Relation between PINT milestone services and traditional telephone
services services
There are many different versions and variations of each telephone call There are many different versions and variations of each telephone call
service invoked by a PINT request. Consider as an example what happens when service invoked by a PINT request. Consider as an example what happens when
a user requests to call 1-800-2255-287 via the PINT Request-to-Call service. a user requests to call 1-800-2255-287 via the PINT Request-to-Call service.
Petrack & Conroy [Page 6] Petrack & Conroy [Page 6]
<draft-ietf-pint-protocol-01.txt> PSP: Extensions to SIP and SDP June, 1999
There may be thousands of agents in the call centre, and there may be any There may be thousands of agents in the call centre, and there may be any
number of sophisticated algorithms and equipments that are used to decide number of sophisticated algorithms and equipments that are used to decide
exactly which agent will return the call. And once this choice is made, exactly which agent will return the call. And once this choice is made,
there may be many different ways to set up the call: the agent's phone might there may be many different ways to set up the call: the agent's phone might
ring first, and only then the original user will be called; or perhaps the ring first, and only then the original user will be called; or perhaps the
user might be called first, and hear some horrible music or pre-recorded user might be called first, and hear some horrible music or pre-recorded
message while the agent is located. message while the agent is located.
Similarly, when a PINT request causes a fax to be sent, there are hundreds Similarly, when a PINT request causes a fax to be sent, there are hundreds
of fax protocol details to be negotiated, as well as transmission details of fax protocol details to be negotiated, as well as transmission details
skipping to change at page 10, line ? skipping to change at page 10, line ?
| PINT | PINT \ PINT | PINT | |Exec| Telephone / | PINT | PINT \ PINT | PINT | |Exec| Telephone /
| client |<-------------->| server |gatewy|=====|Syst| Network \ | client |<-------------->| server |gatewy|=====|Syst| Network \
|_________| protocol / cloud |______| |____| Cloud / |_________| protocol / cloud |______| |____| Cloud /
\ \ / \ \ \ / \
/\/\/\/\/\/\/\ \/\/\/\/\/\/\/\/ /\/\/\/\/\/\/\ \/\/\/\/\/\/\/\/
Figure 1: PINT Functional Architecture Figure 1: PINT Functional Architecture
Petrack & Conroy [Page 7] Petrack & Conroy [Page 7]
<draft-ietf-pint-protocol-01.txt> PSP: Extensions to SIP and SDP June, 1999
The system of PINT servers is represented as a cloud to emphasise that a The system of PINT servers is represented as a cloud to emphasise that a
single PINT request might pass through a series of location servers, proxy single PINT request might pass through a series of location servers, proxy
servers, and redirect servers, before finally reaching the correct PINT servers, and redirect servers, before finally reaching the correct PINT
gateway that can actually process the request by passing it to the gateway that can actually process the request by passing it to the
Telephone Network Cloud. Telephone Network Cloud.
The PINT gateway might have a true telephone network interface, or it might The PINT gateway might have a true telephone network interface, or it might
be connected via some other protocol or API to an "Executive System" that be connected via some other protocol or API to an "Executive System" that
is capable of invoking services within the telephone cloud. is capable of invoking services within the telephone cloud.
skipping to change at page 10, line ? skipping to change at page 10, line ?
information on request disposition. information on request disposition.
10) Mechanism to register interest in the disposition of a requested 10) Mechanism to register interest in the disposition of a requested
service, and to receive indications on that disposition. service, and to receive indications on that disposition.
-*-* -*-*
Both PINT and SIP rely on features of MIME[4]. The use of SIP 2.0 is implied Both PINT and SIP rely on features of MIME[4]. The use of SIP 2.0 is implied
by PINT 1.0, and this also implies compliance with version 1.0 of MIME. by PINT 1.0, and this also implies compliance with version 1.0 of MIME.
Petrack & Conroy [Page 8] Petrack & Conroy [Page 8]
<draft-ietf-pint-protocol-01.txt> PSP: Extensions to SIP and SDP June, 1999
*-*- *-*-
3.2.1. SDP operation in PINT 3.2.1. SDP operation in PINT
The SDP payload contains a description of the particular telephone network The SDP payload contains a description of the particular telephone network
session that the requestor wishes to occur in the PSTN. This information session that the requestor wishes to occur in the PSTN. This information
includes such things as the telephone network address (i.e. the "telephone includes such things as the telephone network address (i.e. the "telephone
number") of the terminal(s) involved in the call, an indication of the media number") of the terminal(s) involved in the call, an indication of the media
type to be transported (e.g. audio, text, image or application data), and an type to be transported (e.g. audio, text, image or application data), and an
indication if the information is to be transported over the telephone indication if the information is to be transported over the telephone
network via voice, fax, or pager transport. An indication of the content to network via voice, fax, or pager transport. An indication of the content to
skipping to change at page 10, line ? skipping to change at page 10, line ?
j. A format for PINT URLS within a PINT request (section 3.5.5) j. A format for PINT URLS within a PINT request (section 3.5.5)
k. Telephone Network Parameters within PINT URLs (section 3.5.6) k. Telephone Network Parameters within PINT URLs (section 3.5.6)
*-*- *-*-
Section 3.5.8 contains remarks about how BYE requests are used within PINT. Section 3.5.8 contains remarks about how BYE requests are used within PINT.
This is not an extension to baseline SIP; it is included here only for This is not an extension to baseline SIP; it is included here only for
clarification of the semantics when used with telephone network sessions. clarification of the semantics when used with telephone network sessions.
Petrack & Conroy [Page 9] Petrack & Conroy [Page 9]
<draft-ietf-pint-protocol-01.txt> PSP: Extensions to SIP and SDP June, 1999
3.3. REQUIRED and OPTIONAL elements for PINT compliance 3.3. REQUIRED and OPTIONAL elements for PINT compliance
*-*- *-*-
Of these, only the TN network type (with its associated RFC2543 address Of these, only the TN network type (with its associated RFC2543 address
type) and the "require" attribute MUST be supported by PINT 1.0 clients type) and the "require" attribute MUST be supported by PINT 1.0 clients
and servers. In practice, most PINT service requests will use other changes, and servers. In practice, most PINT service requests will use other changes,
of which references to Data Objects in requests are most likely to appear of which references to Data Objects in requests are most likely to appear
in PINT requests. in PINT requests.
Each of the other new PINT constructs enables a different function, and a Each of the other new PINT constructs enables a different function, and a
skipping to change at page 11, line 5 skipping to change at page 11, line 5
more specific identifiers for the various telephone network voice, fax, or more specific identifiers for the various telephone network voice, fax, or
pager protocols. Similarly, the data to be transported is identified only as pager protocols. Similarly, the data to be transported is identified only as
a MIME type, such as "text" data, "image" data, or some more general a MIME type, such as "text" data, "image" data, or some more general
"application" data, etc. An important example of transporting "application" "application" data, etc. An important example of transporting "application"
data is the milestone service "Voice Access to Web Content". In this case data is the milestone service "Voice Access to Web Content". In this case
the data to be transported is pointed to by a URI, the data type is the data to be transported is pointed to by a URI, the data type is
application/URI, and the transport protocol would be "voice". Some sort of application/URI, and the transport protocol would be "voice". Some sort of
speech-synthesis facility, speaking out to a Phone, will have to be invoked speech-synthesis facility, speaking out to a Phone, will have to be invoked
to perform this service. to perform this service.
<draft-ietf-pint-protocol-01.txt> PSP: Extensions to SIP and SDP June, 1999
This section gives details of the new SDP keywords. This section gives details of the new SDP keywords.
3.4.1. Network Type "TN" and Address Type "RFC2543" 3.4.1. Network Type "TN" and Address Type "RFC2543"
The TN ("Telephone Network") network type is used to indicate that the The TN ("Telephone Network") network type is used to indicate that the
terminal is connected to a telephone network. terminal is connected to a telephone network.
The address types allowed for network type TN are "RFC2543" and private The address types allowed for network type TN are "RFC2543" and private
address types, which MUST begin with an "X-". address types, which MUST begin with an "X-".
-.-. -.-.
skipping to change at page 12, line 5 skipping to change at page 12, line 5
3.4.2. Support for Data Objects within PINT 3.4.2. Support for Data Objects within PINT
One significant change over traditional SIP/SDP Internet Conference sessions One significant change over traditional SIP/SDP Internet Conference sessions
with PINT is that a PINT service request may refer to a Data Object to be with PINT is that a PINT service request may refer to a Data Object to be
used as source information in that request. For example, a PINT service used as source information in that request. For example, a PINT service
request may specify a document to be processed as part of a GSTN service by request may specify a document to be processed as part of a GSTN service by
which a Fax is sent. Similarly, a GSTN service may be take a Web page and which a Fax is sent. Similarly, a GSTN service may be take a Web page and
result in a vocoder processing that page and speaking the contents over a result in a vocoder processing that page and speaking the contents over a
telephone. telephone.
<draft-ietf-pint-protocol-01.txt> PSP: Extensions to SIP and SDP June, 1999
The SDP specification does not have explicit support for reference to or The SDP specification does not have explicit support for reference to or
carriage of Data Objects within requests. In order to use SDP for PINT, carriage of Data Objects within requests. In order to use SDP for PINT,
there is a need to describe such media sessions as "a telephone call to a there is a need to describe such media sessions as "a telephone call to a
certain number during which such-and-such an image is sent as a fax". certain number during which such-and-such an image is sent as a fax".
To support this, two extensions to the session description format are To support this, two extensions to the session description format are
specified. These are some new allowed values for the Media Field, specified. These are some new allowed values for the Media Field,
and a description of the "fmtp" parameter when used with the Media and a description of the "fmtp" parameter when used with the Media
Field values (within the context of the Contact Field Network type "TN"). Field values (within the context of the Contact Field Network type "TN").
skipping to change at page 13, line 5 skipping to change at page 13, line 5
whilst the media type would be "text". whilst the media type would be "text".
-.-. -.-.
The Fmt sub-field is described in [2] as being transport protocol-specific. 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, 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 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 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. 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 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. a set of alternative sub-types, with the first being the preferred value.
<draft-ietf-pint-protocol-01.txt> PSP: Extensions to SIP and SDP June, 1999
-.-. -.-.
For experimental purposes and by mutual consent of the sender and recipient, For experimental purposes and by mutual consent of the sender and recipient,
a sub-type value may be specified as an <X-token>, i.e. a character string a sub-type value may be specified as an <X-token>, i.e. a character string
starting with "X-". The use of such values is discouraged, and if such a 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 value is expected to find common use then it SHOULD be registered with IANA
using the standard content type registration process (see Appendix C). using the standard content type registration process (see Appendix C).
-.-. -.-.
When the Fmt parameter is the single character "-" ( a dash ), this is When the Fmt parameter is the single character "-" ( a dash ), this is
interpreted as meaning that a unspecified or default sub-type should be used interpreted as meaning that a unspecified or default sub-type should be used
for this service. Thus, the media field value "m=audio 1 voice -<CRLF>" is for this service. Thus, the media field value "m=audio 1 voice -<CRLF>" is
skipping to change at page 14, line 5 skipping to change at page 14, line 5
To indicate which form each resolution element takes, each of them To indicate which form each resolution element takes, each of them
starts with its own literal tag. The detailed syntax of each form is starts with its own literal tag. The detailed syntax of each form is
described in the following sub-sections. described in the following sub-sections.
3.4.2.2. Support for Remote Data Object References in PINT 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 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 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 the uri-ref form. This is simply a Uniform Resource Identifier (URI), as
described in [9]. described in [9].
<draft-ietf-pint-protocol-01.txt> PSP: Extensions to SIP and SDP June, 1999
Note that the reference SHOULD be an absolute URI, as there may not be 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 enough contextual information for the recipient server to resolve a relative
reference; any use of relative references requires some private agreement reference; any use of relative references requires some private agreement
between the sender and recipient of the message, and should be avoided 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 unless the sender can be sure that the recipient is the one intended and the
reference is unambiguous in context. reference is unambiguous in context.
This also holds for partial URIs (such as: "uri:http://aMachine/index.html") This also holds for partial URIs (such as: "uri:http://aMachine/index.html")
as these will need to be resolved in the context of the eventual recipient as these will need to be resolved in the context of the eventual recipient
of the message. of the message.
skipping to change at page 15, line 5 skipping to change at page 15, line 5
For example: For example:
c= TN RFC2543 +1-201-406-4090 c= TN RFC2543 +1-201-406-4090
m= text 1 fax plain m= text 1 fax plain
a=fmtp:plain opr:APPL.123.456 a=fmtp:plain opr:APPL.123.456
means send me the data that is indexed ON THE GSTN by the reference value means send me the data that is indexed ON THE GSTN by the reference value
"APPL.123.456"; the Executive System may also take the Telephone URL held in "APPL.123.456"; the Executive System may also take the Telephone URL held in
the To: field of the enclosing SIP message into account when deciding the the To: field of the enclosing SIP message into account when deciding the
context to be used for the data object dereference. context to be used for the data object dereference.
<draft-ietf-pint-protocol-01.txt> PSP: Extensions to SIP and SDP June, 1999
Of course, an opaque reference may also be used for other purposes; it 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 could, for example, be needed to authorise access to a document held on the
GSTN rather than being required merely to disambiguate the data object. The GSTN rather than being required merely to disambiguate the data object. The
purpose to which an opaque reference is put, however, is out of scope for 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. 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 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 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 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 implementation, the image(s) to be faxed are entirely defined by the
skipping to change at page 15, line 40 skipping to change at page 15, line 38
might be used to precede some unambiguous "faxed back" data with a covering might be used to precede some unambiguous "faxed back" data with a covering
note (see next sub-section for details of the sub-part reference). note (see next sub-section for details of the sub-part reference).
In the special case where an opaque reference is the sole resolution of a 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 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 for a Fmt list at all; the intent of the service is unambiguous without any
further resolution. further resolution.
For example: For example:
c= TN RFC2543 +1-201-406-4090 c= TN RFC2543 +1-201-406-4090
m= text 1 fax m= text 1 fax -
means that there is an implied content stored on the GSTN, and that this is 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 uniquely identified by the combination of SIP To-URI and the Contact field
of the session description. of the session description.
*-*- *-*-
3.4.2.4. Session Description support for included Data Objects 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 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 to a data item held on the GSTN, it is possible to include the content data
skipping to change at page 16, line 5 skipping to change at page 16, line 5
telephone network session to be executed. The other MIME parts contain the telephone network session to be executed. The other MIME parts contain the
content data to be transported. content data to be transported.
Format specific attribute lines within the session description are used to Format specific attribute lines within the session description are used to
indicate which other MIME part within the request contains the content data. indicate which other MIME part within the request contains the content data.
Instead of a URI or opaque reference, the format-specific attribute 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 indicates the Content-ID of the MIME part of the request that contains the
actual data, and is defined as: actual data, and is defined as:
<sub-part-ref> := ("spr:" Content-ID) <sub-part-ref> := ("spr:" Content-ID)
<draft-ietf-pint-protocol-01.txt> PSP: Extensions to SIP and SDP June, 1999
where Content-ID is as defined in Appendix A of [3] and in [10]). where Content-ID is as defined in Appendix A of [3] and in [10]).
For example: For example:
c= TN RFC2543 +1-201-406-4090 c= TN RFC2543 +1-201-406-4090
m= text 1 fax plain m= text 1 fax plain
a=fmtp:plain spr:<Content-ID> a=fmtp:plain spr:<Content-ID>
*-*- *-*-
The <Content-ID> parameter is the Content-ID of one of the MIME parts inside 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 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 data object held in the sub-part of this message labelled <Content-ID> to be
skipping to change at page 17, line 5 skipping to change at page 17, line 5
However, as noted above, it is not usually necessary to use SDP 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 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 within the To: and From: headers and/or Request-URI, normally offer
sufficient context to resolve telephone numbers. sufficient context to resolve telephone numbers.
-.-. -.-.
If the client wishes the request to fail if the attributes are not If the client wishes the request to fail if the attributes are not
supported, these attributes should be used in conjunction with the supported, these attributes should be used in conjunction with the
"require" attribute (section 3.4.4) and the "Require:org.ietf.sdp.require" "require" attribute (section 3.4.4) and the "Require:org.ietf.sdp.require"
header (section 3.5.4). header (section 3.5.4).
<draft-ietf-pint-protocol-01.txt> PSP: Extensions to SIP and SDP June, 1999
It is not possible to standardise every possible internal telephone network It is not possible to standardise every possible internal telephone network
parameter. PINT 1.0 attributes have been chosen for specification because parameter. PINT 1.0 attributes have been chosen for specification because
they are common enough that many different PINT systems will want to use they are common enough that many different PINT systems will want to use
them, and therefore interoperability will be increased by having a single them, and therefore interoperability will be increased by having a single
specification. specification.
*-*- *-*-
Proprietary attribute "a=" lines, that by definition are not interoperable, Proprietary attribute "a=" lines, that by definition are not interoperable,
may be nonetheless useful when it is necessary to transport some proprietary may be nonetheless useful when it is necessary to transport some proprietary
internal telephone network variables over the IP network, for example to internal telephone network variables over the IP network, for example to
skipping to change at page 18, line 5 skipping to change at page 18, line 5
private-prefix = 1*excldigandplus 0*uric private-prefix = 1*excldigandplus 0*uric
An intl-network-prefix and local-network-prefix MUST be a bona fide network 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 prefix, and a network-prefix that is an intl-network-prefix MUST begin with
an E.164 service code ("country code"). an E.164 service code ("country code").
It is possible to register new private-prefixes with IANA so as to avoid It is possible to register new private-prefixes with IANA so as to avoid
confrontation. Prefixes that are not so registered MUST begin with an "X-" confrontation. Prefixes that are not so registered MUST begin with an "X-"
to indicate their private, non-standard nature (see Appendix C). to indicate their private, non-standard nature (see Appendix C).
<draft-ietf-pint-protocol-01.txt> PSP: Extensions to SIP and SDP June, 1999
Example 1: Example 1:
c= TN RFC2543 1-800-765-4321 c= TN RFC2543 1-800-765-4321
a=phone-context:+972 a=phone-context:+972
This describes an terminal whose address in Israel (E.164 country code 972) This describes an terminal whose address in Israel (E.164 country code 972)
is 1-800-765-4321. is 1-800-765-4321.
Example 2: Example 2:
skipping to change at page 19, line 5 skipping to change at page 19, line 5
Note that if the PINT server receiving the request is inside the acme.com Note that if the PINT server receiving the request is inside the acme.com
network, the same terminal might be addressable as follows: network, the same terminal might be addressable as follows:
c= TN RFC2543 7-23-321 c= TN RFC2543 7-23-321
(assuming that "7" is dialled in order to reach the private PBX network from (assuming that "7" is dialled in order to reach the private PBX network from
within acme.com) within acme.com)
*-*- *-*-
<draft-ietf-pint-protocol-01.txt> PSP: Extensions to SIP and SDP June, 1999
*-*- *-*-
3.4.3.2. Presentation Restriction attribute 3.4.3.2. Presentation Restriction attribute
Although it has no affect on the transport of the service request through 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 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 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 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 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 caller be able to select whether or not their correspondent can find out
the calling telephone number (using Automatic Number Indication or Caller the calling telephone number (using Automatic Number Indication or Caller
skipping to change at page 20, line 5 skipping to change at page 20, line 5
identify that remote terminal. identify that remote terminal.
*-*- *-*-
The general form of this attribute is "a=Q763-<token>((":" <value>) |"")". The general form of this attribute is "a=Q763-<token>((":" <value>) |"")".
Three of the possible elements and their use in SDP attributes are described 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 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 subject of further specification to define the syntax of the attribute
mapping. It is recommended that any such specification maintains the value mapping. It is recommended that any such specification maintains the value
sets shown in Q.763. sets shown in Q.763.
<draft-ietf-pint-protocol-01.txt> PSP: Extensions to SIP and SDP June, 1999
The defined attributes are: The defined attributes are:
a=Q763-nature: - indicates the "nature of address indicator". a=Q763-nature: - indicates the "nature of address indicator".
The value MAY be any number between 0 and 127. The value MAY be any number between 0 and 127.
The following values are specified: The following values are specified:
"1" a subscriber number "1" a subscriber number
"2" unknown "2" unknown
"3" a nationally significant number "3" a nationally significant number
"4" an internationally significant number "4" an internationally significant number
skipping to change at page 21, line 5 skipping to change at page 21, line 5
ignore attribute parameters that it does not understand. In order to force a ignore attribute parameters that it does not understand. In order to force a
server to fail a request if it does not understand one of the PINT server to fail a request if it does not understand one of the PINT
attributes, a client should use the "require" attribute, specified as attributes, a client should use the "require" attribute, specified as
follows: follows:
-.-. -.-.
a=require:<attribute-list> a=require:<attribute-list>
where the attribute-list is a comma-separated list of attributes that appear where the attribute-list is a comma-separated list of attributes that appear
elsewhere in the session description. elsewhere in the session description.
<draft-ietf-pint-protocol-01.txt> PSP: Extensions to SIP and SDP June, 1999
-.-. -.-.
In order to process the request successfully the PINT server must BOTH In order to process the request successfully the PINT server must BOTH
understand the attribute AND ALSO fulfil the request implied by the presence understand the attribute AND ALSO fulfil the request implied by the presence
of the attribute, for each attribute appearing within the attribute-list of of the attribute, for each attribute appearing within the attribute-list of
the require attribute. the require attribute.
If the server does not recognise the attribute listed, the PINT server MUST 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 return an error status code (such as 420 (Bad Extension) or 400 (Bad
Request)), Request)),
and SHOULD return suitable Warning: lines explaining the problem or an and SHOULD return suitable Warning: lines explaining the problem or an
skipping to change at page 22, line 5 skipping to change at page 22, line 5
A PINT request can contain a payload which is multipart MIME. In this case 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 the first part MUST contain an SDP session description that includes at
least one of the format specific attribute tags for "included content data" least one of the format specific attribute tags for "included content data"
specified above in section 3.4.3. All subsequent parts contain content data specified above in section 3.4.3. All subsequent parts contain content data
that is to be transferred to the requested Telephone Call Service. As that is to be transferred to the requested Telephone Call Service. As
discussed earlier, within a single PINT request, some of the data MAY be 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 pointed to by a URI within the request, and some of the data MAY be included
within the request. within the request.
<draft-ietf-pint-protocol-01.txt> PSP: Extensions to SIP and SDP June, 1999
*-*- *-*-
Where included data is carried within a PINT service request, the Content 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 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 so, the media type value within this entity header MUST be set to a value of
"multipart". "multipart".
The enclosed body parts SHOULD include the part-specific Content Type The enclosed body parts SHOULD include the part-specific Content Type
headers as appropriate ("application/sdp" for the first body part holding headers as appropriate ("application/sdp" for the first body part holding
the session description, with an appropriate content type for each of the the session description, with an appropriate content type for each of the
subsequent, "included data object" parts). This matches the standard syntax subsequent, "included data object" parts). This matches the standard syntax
skipping to change at page 23, line 5 skipping to change at page 23, line 5
the data but instead hold a reference to it. the data but instead hold a reference to it.
3.5.2. Warning header 3.5.2. Warning header
A PINT server MUST support the SIP "Warning:" header so that it can signal 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 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 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 cannot retrieve and/or translate jpeg pictures from the Internet into fax
transmissions. transmissions.
<draft-ietf-pint-protocol-01.txt> PSP: Extensions to SIP and SDP June, 1999
In such a case the server fails the request and includes a In such a case the server fails the request and includes a
Warning such as the following: Warning such as the following:
Warning: 305 pint.acme.com Incompatible media format: jpeg Warning: 305 pint.acme.com Incompatible media format: jpeg
SIP servers that do not understand the PINT extensions at all are strongly SIP servers that do not understand the PINT extensions at all are strongly
encouraged to implement Warning: headers to indicate that PINT extensions encouraged to implement Warning: headers to indicate that PINT extensions
are not understood. are not understood.
Also, Warning: headers may be included within NOTIFY requests if it is Also, Warning: headers may be included within NOTIFY requests if it is
skipping to change at page 24, line 5 skipping to change at page 24, line 5
service request, the Call-ID may be used as it will be known to the receiver service request, the Call-ID may be used as it will be known to the receiver
to refer to a previously established session. (When the request comes from a to refer to a previously established session. (When the request comes from a
user other than the original requesting user, the request constitutes a new user other than the original requesting user, the request constitutes a new
call, so the Call-ID should not be used; instead the origin-field of the call, so the Call-ID should not be used; instead the origin-field of the
session description enclosed within the original service request is used). session description enclosed within the original service request is used).
The request MUST NOT include whatever content was present in the original The request MUST NOT include whatever content was present in the original
request other than the session description, and a server MUST ignore request other than the session description, and a server MUST ignore
whatever content is included within a SUBSCRIBE request with the sole whatever content is included within a SUBSCRIBE request with the sole
exception of the enclosed session description. exception of the enclosed session description.
<draft-ietf-pint-protocol-01.txt> PSP: Extensions to SIP and SDP June, 1999
-.-. -.-.
The request MAY contain a "Contact:" header, specifying the PINT User Agent The request MAY contain a "Contact:" header, specifying the PINT User Agent
Server to which such information should be sent. In addition, it SHOULD Server to which such information should be sent. In addition, it SHOULD
contain an Expires: header, which indicates for how long the PINT Requestor contain an Expires: header, which indicates for how long the PINT Requestor
wishes to receive notification of the session status. See section 5.1.4. wishes to receive notification of the session status. See section 5.1.4.
for security considerations, particularly privacy implications. for security considerations, particularly privacy implications.
A value of 0 within the Expires: header indicates a desire to receive one A value of 0 within the Expires: header indicates a desire to receive one
single immediate response (i.e. the request expires immediately). We refer single immediate response (i.e. the request expires immediately). We refer
to the period of time before the expiration of the SUBSCRIBE request as the to the period of time before the expiration of the SUBSCRIBE request as the
skipping to change at page 25, line 5 skipping to change at page 25, line 5
The receiving user agent server MUST acknowledge this by returning a final 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 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 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 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 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). that situation it will immediately attempt to close the session (see next).
The NOTIFY request contains the modified session description. For example, 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 be able to indicate a more accurate start or stop time.
<draft-ietf-pint-protocol-01.txt> PSP: Extensions to SIP and SDP June, 1999
The Gateway may include a Warning: header to describe some problem with the 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 invocation of the service, and may indicate within an i= line some
information about the telephone network session itself. information about the telephone network session itself.
Example: Example:
NOTIFY sip:petrack@pager.com SIP/2.0 NOTIFY sip:petrack@pager.com SIP/2.0
To:sip:petrack@pager.com To:sip:petrack@pager.com
From:sip:R2F.pint.com@service.com From:sip:R2F.pint.com@service.com
Warning: xxx fax aborted, will try for the next hour. Warning: xxx fax aborted, will try for the next hour.
skipping to change at page 26, line 5 skipping to change at page 26, line 5
soon as the Gateway has sent a 1xx response back to it. 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 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 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 response from the Gateway, and it can certainly send the SUBSCRIBE request
before sending the ACK for the Service request final response. Beyond this 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, 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 unless the Gateway's final response to the initial service request indicated
a short Expires: time. a short Expires: time.
<draft-ietf-pint-protocol-01.txt> PSP: Extensions to SIP and SDP June, 1999
However, there are good reasons (see 6.4) why it may be appropriate to start 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 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 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 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 request on to the Executive System. It is therefore in a good position to
ask the Executive System to enable monitoring when it sends the service ask the Executive System to enable monitoring when it sends the service
request onwards. In practical implementations, it is likely that more request onwards. In practical implementations, it is likely that more
information on transient service status will be available if this is information on transient service status will be available if this is
indicated as being important BEFORE or AS the service execution phase indicated as being important BEFORE or AS the service execution phase
starts; once execution has begun the level of information that can be starts; once execution has begun the level of information that can be
skipping to change at page 27, line 5 skipping to change at page 27, line 5
internal affair of each individual PINT system. A client uses the internal affair of each individual PINT system. A client uses the
appropriate SDP payload to indicate the particular service it wishes to 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. 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 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, and within the To: and From: headers. Use within the
Request-URI requires clarification in order to ensure smooth interworking Request-URI requires clarification in order to ensure smooth interworking
with the Telephone Network serviced by the PINT infrastructure, and this with the Telephone Network serviced by the PINT infrastructure, and this
is covered next. is covered next.
<draft-ietf-pint-protocol-01.txt> PSP: Extensions to SIP and SDP June, 1999
3.5.5.1. PINT URLS within Request-URIs 3.5.5.1. PINT URLS within Request-URIs
There are some occasions when it may be useful to indicate service There are some occasions when it may be useful to indicate service
information within the URL in a standardized way: information within the URL in a standardized way:
a. it may not be possible to use SDP information to route the request if a. it may not be possible to use SDP information to route the request if
it is encrypted; it is encrypted;
b. it allows implementation that make use of I.N. "service indicators"; b. it allows implementation that make use of I.N. "service indicators";
c. It enables multiple competing PINT gateways to REGISTER with a single c. It enables multiple competing PINT gateways to REGISTER with a single
"broker" server (proxy or redirect) (see section 6.3) "broker" server (proxy or redirect) (see section 6.3)
skipping to change at page 28, line 5 skipping to change at page 28, line 5
information in order correctly to identify the remote telephone terminal or information in order correctly to identify the remote telephone terminal or
service. PINT clients MAY include these attribute tags within PINT URLs if 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 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 SIP URL. These attribute tags MUST be included as URL parameters as defined
in [1] (i.e. in the semi-colon separated manner). in [1] (i.e. in the semi-colon separated manner).
The following is an example of a PINT URL containing extra attribute tags: The following is an example of a PINT URL containing extra attribute tags:
-.-. -.-.
sip:+9725228808@pint.br.com;user=phone;require=Q763-plan;a=Q763-plan:4 sip:+9725228808@pint.br.com;user=phone;require=Q763-plan;a=Q763-plan:4
<draft-ietf-pint-protocol-01.txt> PSP: Extensions to SIP and SDP June, 1999
As we noted in section 3.4.3, these extra attribute parameters will not 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 normally be needed within a URL, because there is a great deal of context
available to the help the server interpret the phone number correctly. In available to the help the server interpret the phone number correctly. In
particular, there is the SIP URL within the To: header, and there is also 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 the Request-URI. In most cases this provides sufficient information for the
telephone network. telephone network.
The SDP attributes defined in section 3 above will normally only be used 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 when they are needed to supply necessary context to identify a telephone
terminal. terminal.
skipping to change at page 29, line 5 skipping to change at page 29, line 5
terminates the call and the media session. Applying this model to PINT, if a 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 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 from A to B, a BYE request from the client, if accepted, should result in a
termination of the phone call. termination of the phone call.
A question arises when the telephone call might not have even started at the A question arises when the telephone call might not have even started at the
time when the BYE request is received. For example, if a request to fax is time when the BYE request is received. For example, if a request to fax is
sent with a t= line indicating that the fax is to be sent tomorrow at 4 AM, sent with a t= line indicating that the fax is to be sent tomorrow at 4 AM,
the requestor might wish to cancel the request before the specified time. the requestor might wish to cancel the request before the specified time.
<draft-ietf-pint-protocol-01.txt> PSP: Extensions to SIP and SDP June, 1999
Even if the call has yet to start, it may not be possible to terminate the 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 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 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 cancel the fax in session. Another possibility is that the entire
telephone-side service might be completed before the BYE is received. In the 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, 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 and the entire fax has been sent before the BYE was received. It is too late
to send the BYE. to send the BYE.
In the case where the telephone network cannot terminate the call, the In the case where the telephone network cannot terminate the call, the
skipping to change at page 30, line 5 skipping to change at page 30, line 5
The second issue concerns how long must a server keep call state after 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 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 send queries about the telephone network session that was the subject of
the PINT transaction. Ordinary SIP semantics have three important the PINT transaction. Ordinary SIP semantics have three important
implications for this situation: implications for this situation:
1. A BYE indicates that the requesting client will clear out all call state 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 as soon as it receives a successful response. A client SHOULD NOT send a
SUBSCRIBE request after it has sent a BYE. SUBSCRIBE request after it has sent a BYE.
<draft-ietf-pint-protocol-01.txt> PSP: Extensions to SIP and SDP June, 1999
2. A server may return an Expires: header within a successful response to a 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 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 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 client may send a SUBSCRIBE request to the server to learn about the session
state. state.
3. When engaged in a SUBSCRIBE/NOTIFY monitoring session, PINT servers that 3. When engaged in a SUBSCRIBE/NOTIFY monitoring session, PINT servers that
send BYE to a URL listed in the Contact: header of a client request SHOULD send BYE to a URL listed in the Contact: header of a client request SHOULD
not clear session state until after the successful response to the BYE is not clear session state until after the successful response to the BYE is
received. For example, it may be that the requesting client host is turned received. For example, it may be that the requesting client host is turned
skipping to change at page 30, line 40 skipping to change at page 30, line 38
To: sip:+1-201-456-7890@iron.org;user=phone To: sip:+1-201-456-7890@iron.org;user=phone
Call-ID: 19971205T234505.56.78@chinet.net Call-ID: 19971205T234505.56.78@chinet.net
Subject: Sale on Ironing Boards Subject: Sale on Ironing Boards
Content-type: application/sdp Content-type: application/sdp
Content-Length: ... Content-Length: ...
v=0 v=0
o=- 53655765 2353687637 IN IP4 128.3.4.5 o=- 53655765 2353687637 IN IP4 128.3.4.5
i=Ironing Board Promotion i=Ironing Board Promotion
c= TN RFC2543 +1-201-406-4090 c= TN RFC2543 +1-201-406-4090
m=audio 1 voice m=audio 1 voice -
-.-. -.-.
In this example, the context that is required to interpret the To: address 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 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 R2C@pint.mailorder.com server. But the telephone of the person who wishes to
receive the call is explicitly identified as an internationally significant receive the call is explicitly identified as an internationally significant
E.164 number that falls within the North American numbering plan E.164 number that falls within the North American numbering plan
(because of the "+1" within the c= line). (because of the "+1" within the c= line).
4.2. A request from a non anonymous customer (John Jones) to receive a phone 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 call from a particular sales agent (Mary James) concerning the defective
ironing board that was purchased ironing board that was purchased
<draft-ietf-pint-protocol-01.txt> PSP: Extensions to SIP and SDP June, 1999
C->S: INVITE sip:marketing@pint.mailorder.com SIP/2.0 C->S: INVITE sip:marketing@pint.mailorder.com SIP/2.0
Via: SIP/2.0/UDP 169.130.12.5 Via: SIP/2.0/UDP 169.130.12.5
From: sip:john.jones.3@chinet.net From: sip:john.jones.3@chinet.net
To: sip:mary.james@mailorder.com To: sip:mary.james@mailorder.com
Call-ID: 19971205T234505.56.79@chinet.net Call-ID: 19971205T234505.56.79@chinet.net
Subject: Defective Ironing Board - want refund Subject: Defective Ironing Board - want refund
Content-type: application/sdp Content-type: application/sdp
Content-Length: ... Content-Length: ...
v=0 v=0
skipping to change at page 32, line 5 skipping to change at page 32, line 5
a=fmtp:URI uri:http://localstore/Products/IroningBoards/2344.html a=fmtp:URI uri:http://localstore/Products/IroningBoards/2344.html
In this example, the fax to be sent is stored on some local server 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 (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 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 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 "phone-context" attribute, so the context (in this case, for which nation
the number is "nationally significant") must be supplied by the the number is "nationally significant") must be supplied by the
faxback@pint.mailorder.com PINT server. faxback@pint.mailorder.com PINT server.
<draft-ietf-pint-protocol-01.txt> PSP: Extensions to SIP and SDP June, 1999
-.-. -.-.
If the server that receives does not understand the number, it should fail If the server that receives does not understand the number, it should fail
the request with and include a "Network Address Not Understood" warning. the request with and include a "Network Address Not Understood" warning.
Note that no "require" attribute was used here, since it is very likely 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 that the request can be serviced even by a server that does not support
the "require" attribute. the "require" attribute.
4.4. A request from same user to have that same information read out over 4.4. A request from same user to have that same information read out over
the phone the phone
skipping to change at page 33, line 5 skipping to change at page 33, line 5
----next ----next
Content-Type: text/plain Content-Type: text/plain
Content-ID: 2@53655768 Content-ID: 2@53655768
Content-Length:... Content-Length:...
Hi Joe! Please call me asap at 555-1234. Hi Joe! Please call me asap at 555-1234.
----next-- ----next--
<draft-ietf-pint-protocol-01.txt> PSP: Extensions to SIP and SDP June, 1999
4.6. A request to send an image as a fax to phone number +972-9-956-1867 4.6. A request to send an image as a fax to phone number +972-9-956-1867
C->S: INVITE sip:faxserver@pint.vocaltec.com SIP/2.0 C->S: INVITE sip:faxserver@pint.vocaltec.com SIP/2.0
Via: SIP/2.0/UDP 169.130.12.5 Via: SIP/2.0/UDP 169.130.12.5
From: scott.petrack@chinet.net From: scott.petrack@chinet.net
To: sip:faxserver@pint.vocaltec.com To: sip:faxserver@pint.vocaltec.com
Call-ID: 19971205T234505.66.79@chinet.net Call-ID: 19971205T234505.66.79@chinet.net
Content-type: application/sdp Content-type: application/sdp
Content-Length: ... Content-Length: ...
skipping to change at page 34, line 5 skipping to change at page 34, line 5
--next --next
Content-Type: text/plain Content-Type: text/plain
Content-ID: 2@53655768 Content-ID: 2@53655768
Content-Length: ... Content-Length: ...
Hello!! I am about to read out to you the document you Hello!! I am about to read out to you the document you
requested, "uri:http://www.your.com/texts/stuff.doc". requested, "uri:http://www.your.com/texts/stuff.doc".
We hope you like acme.com's new speech synthesis server. We hope you like acme.com's new speech synthesis server.
--next-- --next--
<draft-ietf-pint-protocol-01.txt> PSP: Extensions to SIP and SDP June, 1999
*-*- *-*-
4.8. Request for the prices for ISDN to be sent to my fax machine 4.8. Request for the prices for ISDN to be sent to my fax machine
INVITE sip:R2FB@pint.bt.co.uk SIP/2.0 INVITE sip:R2FB@pint.bt.co.uk SIP/2.0
Via: SIP/2.0/UDP 169.130.12.5 Via: SIP/2.0/UDP 169.130.12.5
To:0345-12347-01;user=phone;phone-context=+44 To:0345-12347-01;user=phone;phone-context=+44
From: sip:hank.wangford@newts.demon.co.uk From: sip:hank.wangford@newts.demon.co.uk
Call-ID: 19981204T201505.56.78@demon.co.uk Call-ID: 19981204T201505.56.78@demon.co.uk
Subject: Price List Subject: Price List
Content-type: application/sdp Content-type: application/sdp
Content-Length: 116 Content-Length: 116
v=0 v=0
o=-53655765 2353687637 IN IP4 128.3.4.5 o=-53655765 2353687637 IN IP4 128.3.4.5
i=ISDN Price List i=ISDN Price List
c=TN RFC2543 +44-1794-8331010 c=TN RFC2543 +44-1794-8331010
m=text 1 fax m=text 1 fax -
4.9. Request for a callback 4.9. Request for a callback
INVITE sip:R2C@pint.bt.co.uk SIP/2.0 INVITE sip:R2C@pint.bt.co.uk SIP/2.0
Via: SIP/2.0/UDP 169.130.12.5 Via: SIP/2.0/UDP 169.130.12.5
To:0345-123456;user=phone;phone-context=+44 To:0345-123456;user=phone;phone-context=+44
From: sip:hank.wangford@newts.demon.co.uk From: sip:hank.wangford@newts.demon.co.uk
Call-ID: 19981204T234505.56.78@demon.co.uk Call-ID: 19981204T234505.56.78@demon.co.uk
Subject: It costs HOW much? Subject: It costs HOW much?
Content-type: application/sdp Content-type: application/sdp
Content-Length: 123 Content-Length: 123
v=0 v=0
o=- 53655765 2353687637 IN IP4 128.3.4.5 o=- 53655765 2353687637 IN IP4 128.3.4.5
i=ISDN pre-sales query i=ISDN pre-sales query
c= TN RFC2543 +44-1794-8331013 c= TN RFC2543 +44-1794-8331013
m=audio 1 voice m=audio 1 voice -
4.10.Sending a set of information in response to an enquiry 4.10.Sending a set of information in response to an enquiry
INVITE sip:R2FB@pint.bt.co.uk SIP/2.0 INVITE sip:R2FB@pint.bt.co.uk SIP/2.0
Via: SIP/2.0/UDP 169.130.12.5 Via: SIP/2.0/UDP 169.130.12.5
To:0345-12347-01;user=phone;phone-context=+44 To:0345-12347-01;user=phone;phone-context=+44
From: sip:colin.masterton@sales.hh.bt.co.uk From: sip:colin.masterton@sales.hh.bt.co.uk
Call-ID: 19981205T234505.56.78@sales.hh.bt.co.uk Call-ID: 19981205T234505.56.78@sales.hh.bt.co.uk
Subject: Price Info, as requested Subject: Price Info, as requested
Content-Type: multipart/mixed; boundary=next Content-Type: multipart/mixed; boundary=next
skipping to change at page 35, line 4 skipping to change at page 35, line 4
--next --next
Content-type: application/sdp Content-type: application/sdp
Content-Length: 211 Content-Length: 211
v=0 v=0
o=-53655765 2353687637 IN IP4 128.3.4.5 o=-53655765 2353687637 IN IP4 128.3.4.5
i=Your documents i=Your documents
c=TN RFC2543 +44-1794-8331010 c=TN RFC2543 +44-1794-8331010
m=application 1 fax octet-stream m=application 1 fax octet-stream
a=fmtp:octet-stream uri:http://www.bt.co.uk/imgs/pipr.gif opr: a=fmtp:octet-stream uri:http://www.bt.co.uk/imgs/pipr.gif opr:
spr:2@53655768 spr:2@53655768
<draft-ietf-pint-protocol-01.txt> PSP: Extensions to SIP and SDP June, 1999
--next --next
Content-Type: text/plain Content-Type: text/plain
Content-ID: 2@53655768 Content-ID: 2@53655768
Content-Length: 352 Content-Length: 352
Dear Sir, Dear Sir,
Thank you for your enquiry. I have checked availability in your Thank you for your enquiry. I have checked availability in your
area, and we can provide service to your cottage. I enclose a quote area, and we can provide service to your cottage. I enclose a quote
for the costs of installation, together with the ongoing rental for the costs of installation, together with the ongoing rental
costs for the line. If you want to proceed with this, please quote costs for the line. If you want to proceed with this, please quote
skipping to change at page 36, line 5 skipping to change at page 36, line 5
Content-type: application/sdp Content-type: application/sdp
Content-Length: 173 Content-Length: 173
v=0 v=0
o=- 53655765 2353687637 IN IP4 128.3.4.5 o=- 53655765 2353687637 IN IP4 128.3.4.5
i=NFL Final Scores i=NFL Final Scores
c= TN RFC2543 +44-1794-8331010 c= TN RFC2543 +44-1794-8331010
m=text 1 fax x-pay m=text 1 fax x-pay
a=fmtp:x-pay opr:mci.com/md5:<crypto signature> a=fmtp:x-pay opr:mci.com/md5:<crypto signature>
<draft-ietf-pint-protocol-01.txt> PSP: Extensions to SIP and SDP June, 1999
(iii) pager (iii) pager
INVITE sip:R2FB@pint.wwos.skynet.com SIP/2.0 INVITE sip:R2FB@pint.wwos.skynet.com SIP/2.0
Via: SIP/2.0/UDP 169.130.12.5 Via: SIP/2.0/UDP 169.130.12.5
To:1-900-123-456-7;user=phone;phone-context=+1 To:1-900-123-456-7;user=phone;phone-context=+1
From: sip:fred.football.fan@skynet.com From: sip:fred.football.fan@skynet.com
Call-ID: 19971205T234505.56.78@chinet.net Call-ID: 19971205T234505.56.78@chinet.net
Subject: Wonderful World Of Sports NFL Final Scores Subject: Wonderful World Of Sports NFL Final Scores
Content-type: application/sdp Content-type: application/sdp
Content-Length: 173 Content-Length: 173
skipping to change at page 37, line 5 skipping to change at page 37, line 5
i=Joe Pendleton's Phone Bill i=Joe Pendleton's Phone Bill
c=TN RFC2543 +1-202-833-1010 c=TN RFC2543 +1-202-833-1010
m=text 1 fax x-files-id m=text 1 fax x-files-id
a=fmtp:x-files-id opr:fbi.gov/jdcn-123@45:3des;base64,<signature> a=fmtp:x-files-id opr:fbi.gov/jdcn-123@45:3des;base64,<signature>
Note: in this case the opaque reference is data used to convince the Note: in this case the opaque reference is data used to convince the
Executive System that the requester has the right to get this information, 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 rather than selecting the particular content (the A party in the To: field
of the SIP "wrapper" does that alone). of the SIP "wrapper" does that alone).
<draft-ietf-pint-protocol-01.txt> PSP: Extensions to SIP and SDP June, 1999
5. Security Considerations 5. Security Considerations
5.1. Basic Principles for PINT Use 5.1. Basic Principles for PINT Use
A PINT Gateway, and the Executive System(s) with which that Gateway is 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 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 protocol is to pass requests from those users on to a PINT Gateway so an
associated Executive System can service those requests. associated Executive System can service those requests.
5.1.1. Responsibility for service requests 5.1.1. Responsibility for service requests
The facility of making a PSTN-based call to numbers specified in the PINT The facility of making a PSTN-based call to numbers specified in the PINT
request, however, comes with some risks. The request can specify an incorrect request, however, comes with some risks. The request can specify an incorrect
skipping to change at page 38, line 5 skipping to change at page 38, line 5
be forced (or choose) not to provide service. This identification will require be forced (or choose) not to provide service. This identification will require
personal authentication of the Requesting User. personal authentication of the Requesting User.
5.1.2. Authority to make requests 5.1.2. Authority to make requests
Where PSTN resources are used to provide a PINT service, it is at least Where PSTN 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 possible that someone will have to pay for it. This person may not be the
Requestor, as, for example, in the case of existing PSTN split-charging Requestor, as, for example, in the case of existing PSTN split-charging
services like free phone in which the recipient of a call rather than the services like free phone in which the recipient of a call rather than the
originator is responsible for the call cost. originator is responsible for the call cost.
<draft-ietf-pint-protocol-01.txt> PSP: Extensions to SIP and SDP June, 1999
This is not, of course, the only possibility; for example, PINT service may be 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. 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 However, whichever model is chosen, there may be a requirement that the
authority of a Requestor to make a PINT request is confirmed. authority of a Requestor to make a PINT request is confirmed.
If such confirmation is not available, then, again, the PINT Gateway and If such confirmation is not available, then, again, the PINT Gateway and
associated Executive System may choose not to provide service. associated Executive System may choose not to provide service.
5.1.3. Privacy 5.1.3. Privacy
Even if the identity of the Requesting User and the Authority under which they Even if the identity of the Requesting User and the Authority under which they
skipping to change at page 39, line 5 skipping to change at page 39, line 5
and use this in a subsequent SUBSCRIBE request. In this way it is possible to 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. 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 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. 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 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 it might be possible for an attacker to reconstruct the session description
and use this reconstruction within a SUBSCRIBE message. and use this reconstruction within a SUBSCRIBE message.
<draft-ietf-pint-protocol-01.txt> PSP: Extensions to SIP and SDP June, 1999
SDP (see section 6 of [2], "o=" field) does not specify the mechansim used to SDP (see section 6 of [2], "o=" field) does not specify the mechansim used to
generate the sess-id field, and suggests that a method based on timestamps 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 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 guarantee uniqueness, but may allow the value to be guessed, particularly if
other unprotected requests from the same originator are available. other unprotected requests from the same originator are available.
Thus, to ensure that the session identifier is not guessable the techniques 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 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 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 requests from (and responses to) a particular PINT requesting entity are
skipping to change at page 40, line 5 skipping to change at page 40, line 5
and any cancellation of current registrations. This recommendation is also and any cancellation of current registrations. This recommendation is also
made in the SIP specification, but for the correct operation of PINT, it is made in the SIP specification, but for the correct operation of PINT, it is
very important indeed. very important indeed.
5.3. Security mechanisms and implications on PINT service 5.3. Security mechanisms and implications on PINT service
PINT is a set of extensions to SIP[1] and SDP[2], and will use the security 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 procedures described in SIP. There are several implications of this, and these
are covered here. are covered here.
<draft-ietf-pint-protocol-01.txt> PSP: Extensions to SIP and SDP June, 1999
For several of the PINT services, the To: header field of SIP is used to 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 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, 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 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 and Proxy server between the corresponding User Agent Servers, and so cannot
be encrypted. This means that, although the majority of personal or sensitive 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 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 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 interception. For the PINT milestone services this may be acceptable, since
the caller named in the To: service is typically a "well known" provider the caller named in the To: service is typically a "well known" provider
skipping to change at page 41, line 5 skipping to change at page 41, line 5
encrypted, then the request cannot be decoded at the Proxy server, and so encrypted, then the request cannot be decoded at the Proxy server, and so
Gateway selection based on contained information cannot be made there. 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 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 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 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 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 request will succeed if at all possible, even though it may be delayed (and
tie up resources in the inappropriate Gateways). tie up resources in the inappropriate Gateways).
<draft-ietf-pint-protocol-01.txt> PSP: Extensions to SIP and SDP June, 1999
This opens up an interesting avenue for Denial Of Service; sending a valid 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 request that appears to be suitable for a number of different Gateways, and
simply occupying those Gateways in decrypting a message requesting a service 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 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, 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 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 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" 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 rather than the more general use of "R2F", if there is a possibility of the
SDP body part being protected during transit. SDP body part being protected during transit.
skipping to change at page 41, line 48 skipping to change at page 41, line 47
expected to be held in opaque references inside the SDP body part of the expected to be held in opaque references inside the SDP body part of the
request. request.
The detailed operation of this mechanism is, by definition, outside the scope 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, of an Internet Protocol, and so must be considered a private matter. However,
one approach to indicating to the Requestor that such "second level" one approach to indicating to the Requestor that such "second level"
authentication or authorization is required by their Service Provider would be authentication or authorization is required by their Service Provider would be
to ask for this inside the textual description carried with a 401 response to ask for this inside the textual description carried with a 401 response
returned from the PINT Gateway. returned from the PINT Gateway.
-..-
5.4. Summary of Security Implications 5.4. Summary of Security Implications
>From the above discussion, PINT always carries data items that are sensitive, >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 and there may be financial considerations as well as the more normal privacy
concerns. As a result, the transactions MUST be protected from interception, concerns. As a result, the transactions MUST be protected from interception,
modification and replay in transit. modification and replay in transit.
PINT is based on SIP and SDP, and can use the security procedures outlined in 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 [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 that requests and responses MAY be protected is not enough. PINT messages MUST
be protected, so PINT Implementations MUST support SIP Security (as described 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 [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] for ALL
communications between them. In this case, PINT messages need not be
<draft-ietf-pint-protocol-01.txt> PSP: Extensions to SIP and SDP June, 1999 In some configurations, PINT Clients, Servers, and Gateways can be sure that
protected using the procedures described in SIP; all traffic is protected they operate using the services of network level security [13], transport
already. The initiating entity can instead send the request "in plain". 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.
Authentication of the Client making the request is required, however, so 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 if this is not provided by the underlying mechanism used, then it MUST be
included within the PINT messages using SIP authentication techniques. In included within the PINT messages using SIP authentication techniques. In
contrast with SIP, PINT requests are often sent to parties with which a contrast with SIP, PINT requests are often sent to parties with which a
prior communications relationship exists (such as a Telephone Carrier). In prior communications relationship exists (such as a Telephone Carrier). In
this case, there may be a shared secret between the client and the PINT 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, Gateway. Such PINT systems MAY use authentication based on shared secrets,
with HTTP "basic authentication". When this is done, the message integrity with HTTP "basic authentication". When this is done, the message integrity
must be guaranteed by some lower layer mechanism. and privacy must be guaranteed by some lower layer mechanism.
There are implications on the operation of PINT here though. If a PINT proxy 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 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 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 network-layer security between the PINT Client and a PINT Gateway precludes
the use of an intervening proxy; communication between the Client and Gateway 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, 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 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 "hop-by-hop" approach is used, then any intervening PINT proxies (or redirect
servers) are, by implication, trusted entities. servers) are, by implication, trusted entities.
If using TCP for underlying transport of PINT messages, then transport layer
security mechanisms (SSL or TLS [12]) may be used as an alternative. Again,
all PINT players MUST be sure that TLS is in operation if they wish to avoid
using SIP Security, and if mutual authentication is not available, then SIP
authentication techniques MUST be used.
In any case, TLS is required for HTTP traffic, in those configurations that
use a "Web" front-end "prior" to any PINT protocol transactions; there is no
point in protecting the PINT transactions if the data used to construct
requests via HTTP requests is passed "in clear".
However, if there is any doubt that there is an underlying network or 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 transport layer security association in place, then the players in a PINT
protocol exchange MUST use encryption and authentication techniques within the protocol exchange MUST use encryption and authentication techniques within the
protocol itself. The techniques described in section 15 of RFC2543 MUST be protocol itself. The techniques described in section 15 of RFC2543 MUST be
used, unless there is an alternative protection scheme that is agreed between 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) 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 carried within a PINT request or response MUST be protected; this has
implications on the options for routing requests via Proxies (see 5.3). implications on the options for routing requests via Proxies (see 5.3).
Using SIP techniques for protection, the Request-URI and To: fields headers Using SIP techniques for protection, the Request-URI and To: fields headers
within PINT requests cannot be protected. In the baseline PINT services these within PINT requests cannot be protected. In the baseline PINT services these
fields may contain sensitive information. This is a consideration, and if fields may contain sensitive information. This is a consideration, and if
these data ARE considered sensitive, then this will preclude the use of the 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] SIP techniques; in such a situation, transport [12] or network layer [13]
protection mechanisms MUST be used. protection mechanisms MUST be used.
Choice of mechanism is by mutual agreement between the PINT entities.
As a final point, this choice will in turn have an influence on the choice of 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 transport layer protocol that can be used; if a TLS association is available
between two nodes, then TCP will have to be used. This means that the default between two nodes, then TCP will have to be used. This is different from
behaviour of SIP entities (try UDP, then try TCP if that fails) may be the default behaviour of SIP (try UDP, then try TCP if that fails).
modified in such a situation.
<draft-ietf-pint-protocol-01.txt> PSP: Extensions to SIP and SDP June, 1999
6. Deployment considerations and the Relationship PINT to I.N. (Informative) 6. Deployment considerations and the Relationship PINT to I.N. (Informative)
6.1. Web Front End to PINT Infrastructure 6.1. Web Front End to PINT Infrastructure
It is possible that some other protocol may be used to communicate a 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 Requesting User's requirements. Due to the high numbers of available Web
Browsers and servers it seems likely that some PINT systems will use 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 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 connection from the Requesting User's Web Browser (WC) to an Intermediate
skipping to change at page 44, line 5 skipping to change at page 44, line 5
However, there do seem to be two approaches. Either a Server that acts as a 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 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 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. 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 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 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 the choices should be returned to the Requesting User for selection. This is
not too likely a scenario within the normal use of SIP. not too likely a scenario within the normal use of SIP.
<draft-ietf-pint-protocol-01.txt> PSP: Extensions to SIP and SDP June, 1999
However, within PINT, such ambiguity may be quite common; it implies that However, within PINT, such ambiguity may be quite common; it implies that
there are a number of possible providers of a given service. there are a number of possible providers of a given service.
6.3. Competing PINT Gateways REGISTERing to offer the same 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 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 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 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 support the service R2C as "R2C@telcoA.com", sent to an intermediary server
that acts as registrar for the "broker.telcos.com" domain from that acts as registrar for the "broker.telcos.com" domain from
skipping to change at page 45, line 5 skipping to change at page 45, line 5
In this last case, on receiving an Invitation for the "general" service, In this last case, on receiving an Invitation for the "general" service,
either: either:
(iii.1) it passes on the invitation to all registered service (iii.1) it passes on the invitation to all registered service
providers, returning a collated response with all providers, returning a collated response with all
acceptances, using multiple Location: headers, acceptances, using multiple Location: headers,
or or
(iii.2) it silently selects one of the registrations (using, for (iii.2) it silently selects one of the registrations (using, for
example, a "round robin" approach) and routes the Invitation example, a "round robin" approach) and routes the Invitation
and response onwards without further comment. and response onwards without further comment.
<draft-ietf-pint-protocol-01.txt> PSP: Extensions to SIP and SDP June, 1999
As an alternative to all of the above approaches, it: As an alternative to all of the above approaches, it:
(iv) may choose to not allow registrations for the "general" service, (iv) may choose to not allow registrations for the "general" service,
rejecting all such REGISTER requests. rejecting all such REGISTER requests.
The algorithm by which such a choice is made will be The algorithm by which such a choice is made will be
implementation-dependent, and is outside the scope of PINT. Where a implementation-dependent, and is outside the scope of PINT. Where a
behaviour is to be defined by requesting users, then some sort of call 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 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 operation, to download the behaviour they expect to the server making such
decisions. This, however, is a topic for other protocols, not for PINT. decisions. This, however, is a topic for other protocols, not for PINT.
skipping to change at page 46, line 5 skipping to change at page 46, line 5
that request. Although this does not affect the protocol used between the that request. Although this does not affect the protocol used between the
Requestor and the PINT Gateway, it may influence the response returned. Requestor and the PINT Gateway, it may influence the response returned.
To avoid the problem of changing service logic once running, any To avoid the problem of changing service logic once running, any
registration of interest in status changes should be made at or before the registration of interest in status changes should be made at or before the
time at which the service request is made. time at which the service request is made.
Conversely, if a historical request is made on the disposition of a service, 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 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 Executive System is unlikely to store the results of service requests for
<draft-ietf-pint-protocol-01.txt> PSP: Extensions to SIP and SDP June, 1999
long; these will have been processed as AMA (Automatic Message Accounting) long; these will have been processed as AMA (Automatic Message Accounting)
records quickly, after which the Executive System has no reason to keep records quickly, after which the Executive System has no reason to keep
them, and so they may be discarded. them, and so they may be discarded.
Where the PINT Gateway and the Executive System are intimately linked, the Where the PINT Gateway and the Executive System are intimately linked, the
Gateway can respond to status subscription requests that occur while a 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 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 query the Executive System until it has information that a service has
completed, merely returning the final status. Thus the PINT Requestor may be 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 in what it believes is a monitoring state, whilst the PINT Gateway has not
skipping to change at page 47, line 5 skipping to change at page 47, line 5
content to be delivered resides on the GSTN) they will also have specify two 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 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 to which they want a fax to be sent. However, within this variant the A
party identifies the "document context" for the PSTN-based document store party identifies the "document context" for the PSTN-based document store
from which a particular document is to be retrieved; the analogy here is to from which a particular document is to be retrieved; the analogy here is to
a PSTN user dialling a particular telephone number and then entering the a PSTN user dialling a particular telephone number and then entering the
document number to be returned using "touch tone" digits. The telephone 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 number they dial is that of the document store or A party, with the "touch
tone" digits selecting the document within that store. tone" digits selecting the document within that store.
<draft-ietf-pint-protocol-01.txt> PSP: Extensions to SIP and SDP June, 1999
6.5.3. Other Service Parameters 6.5.3. Other Service Parameters
In terms of the extra parameters to the request, the services again differ. In terms of the extra parameters to the request, the services again differ.
The Request-to-Talk service needs only the A and B parties. Also it is The Request-to-Talk service needs only the A and B parties. Also it is
convenient to assert that the resulting service call will carry voice, as 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 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 assertion against the A and B party numbers specified and may treat the call
differently. differently.
With the Request-to-Fax and Request-to-Hear-Content services, the source With the Request-to-Fax and Request-to-Hear-Content services, the source
skipping to change at page 48, line 5 skipping to change at page 48, line 5
The Services listed are Request to Talk (R2C), Request to Fax (R2F), the The Services listed are Request to Talk (R2C), Request to Fax (R2F), the
PSTN-based content or "Fax-back" Variant of Request-to-Fax (R2FB), and PSTN-based content or "Fax-back" Variant of Request-to-Fax (R2FB), and
Request-to-Hear-Content (R2HC). Request-to-Hear-Content (R2HC).
The Call Format parameter values "voice" or "fax" indicate the kind of The Call Format parameter values "voice" or "fax" indicate the kind of
service call that results. service call that results.
The Source Indicator "URI/IL" implies either that the data is either an The Source Indicator "URI/IL" implies either that the data is either an
Internet source reference (a Universal Resource Identifier, or URI) or is Internet source reference (a Universal Resource Identifier, or URI) or is
<draft-ietf-pint-protocol-01.txt> PSP: Extensions to SIP and SDP June, 1999
carried "in-line" with the message. The Source indicator "OR" means that carried "in-line" with the message. The Source indicator "OR" means that
the value passed is an Opaque Reference that should be carried along 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 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 destination (GSTN) context. As an alternative, it could be given as a
"local" reference with the "file" style, or even using a partial reference "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 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; interpreted is a matter for the receiving PINT Server and Executive System;
it remains, in effect, an opaque reference. it remains, in effect, an opaque reference.
The Source Format value "ISF/ILSF" means that the format of the source is The Source Format value "ISF/ILSF" means that the format of the source is
skipping to change at page 49, line 5 skipping to change at page 49, line 5
The source format specifier is held in the "m=", as a type and optional The source format specifier is held in the "m=", as a type and optional
sub-type. The latter is normally required for all services except sub-type. The latter is normally required for all services except
Request-to-Talk. As shown earlier, the source format and source are not Request-to-Talk. As shown earlier, the source format and source are not
always required when generating requests for services. However, the inclusion always required when generating requests for services. However, the inclusion
in all requests of a source format specifier can make parsing the request 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 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 values are always given. The source format parameter is covered in section
3.4.2 as the "media type" element. 3.4.2 as the "media type" element.
<draft-ietf-pint-protocol-01.txt> PSP: Extensions to SIP and SDP June, 1999
The source itself is identified by an "a=fmtp:" field value, where needed. The source itself is identified by an "a=fmtp:" field value, where needed.
With the exception of the Request-to-Talk service, all invitations will With the exception of the Request-to-Talk service, all invitations will
normally include such a field. From the perspective of the SDP extensions, 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, 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". for example, "when I say jpeg, what I mean is the following".
In summary, the parameters needed by the different services are carried in In summary, the parameters needed by the different services are carried in
fields as shown in the following table: fields as shown in the following table:
Service Svc Param PINT/SIP or SDP field used Example value Service Svc Param PINT/SIP or SDP field used Example value
------- --------- -------------------------- ------------- ------- --------- -------------------------- -------------
R2C R2C
ServiceID: <SIP Request-URI userinfo> R2C ServiceID: <SIP Request-URI userinfo> R2C
BParty: <SIP To: field> sip:123@p.com BParty: <SIP To: field> sip:123@p.com
AParty: <SDP c= field> TN RFC2543 4567 AParty: <SDP c= field> TN RFC2543 4567
CallFormat: <SDP transport protocol CallFormat: <SDP transport protocol
sub-field of m= field> voice sub-field of m= field> voice
SourceFmt: <SDP media type sub-field SourceFmt: <SDP media type sub-field
of m= field> audio of m= field> audio
(--- No media sub-type (--- only "-" sub-type
sub-field value used) --- sub-field value used) ---
Source: (--- No source specified) --- Source: (--- No source specified) ---
R2F R2F
ServiceID: <SIP Request-URI userinfo> R2F ServiceID: <SIP Request-URI userinfo> R2F
BParty: (--- SIP To: field not used) sip:R2F@pint.xxx.net BParty: (--- SIP To: field not used) sip:R2F@pint.xxx.net
AParty: <SDP c= field> TN RFCxxx +441213553 AParty: <SDP c= field> TN RFCxxx +441213553
CallFormat: <SDP transport protocol CallFormat: <SDP transport protocol
sub-field of m= field> fax sub-field of m= field> fax
SourceFmt: <SDP media type sub-field SourceFmt: <SDP media type sub-field
skipping to change at page 50, line 4 skipping to change at page 50, line 4
BParty: <SIP To: field> sip:1-730-1234@p.com BParty: <SIP To: field> sip:1-730-1234@p.com
AParty: <SDP c= field> TN RFCxxx +441213553 AParty: <SDP c= field> TN RFCxxx +441213553
CallFormat: <SDP transport protocol CallFormat: <SDP transport protocol
sub-field of m= field> fax sub-field of m= field> fax
SourceFmt: <SDP media type sub-field SourceFmt: <SDP media type sub-field
of m= field> image of m= field> image
<SDP media sub-type sub-field <SDP media sub-type sub-field
of m= field> jpeg of m= field> jpeg
Source: <SDP a=fmtp: field qualifying Source: <SDP a=fmtp: field qualifying
preceding m= field> a=fmtp:jpeg opr:1234 preceding m= field> a=fmtp:jpeg opr:1234
<draft-ietf-pint-protocol-01.txt> PSP: Extensions to SIP and SDP June, 1999
R2HC R2HC
ServiceID: <SIP Request-URI userinfo> R2HC ServiceID: <SIP Request-URI userinfo> R2HC
BParty: (--- SIP To: field not used) sip:R2HC@pint.ita.il BParty: (--- SIP To: field not used) sip:R2HC@pint.ita.il
AParty: <SDP c= field> TN RFCxxx +441213554 AParty: <SDP c= field> TN RFCxxx +441213554
CallFormat: <SDP transport protocol CallFormat: <SDP transport protocol
sub-field of m= field> voice sub-field of m= field> voice
SourceFmt: <SDP media type sub-field SourceFmt: <SDP media type sub-field
of m= field> text of m= field> text
<SDP media sub-type sub-field <SDP media sub-type sub-field
of m= field> html of m= field> html
skipping to change at page 50, line 52 skipping to change at page 50, line 49
Changes from version 01 to previous interim version: Changes from version 01 to previous interim version:
* Corrected a few typos, orphaned internal references, and some of the * Corrected a few typos, orphaned internal references, and some of the
examples. examples.
* Made a few corrections and added some comments on changes to be expected * Made a few corrections and added some comments on changes to be expected
in the next draft. These were highlighted by **** before the affected in the next draft. These were highlighted by **** before the affected
paragraphs. paragraphs.
* Removed references to the Telephony URL draft that has expired. It seems * Removed references to the Telephony URL draft that has expired. It seems
likely that the SIP draft will reach RFC status first. likely that the SIP draft will reach RFC status first.
Changes from interim version to version 03: Changes from interim version to profile version 03:
* removed previous change marks * removed previous change marks
* New changes are indicated by *-*- in the text above the change * New changes are indicated by *-*- in the text above the change
* Corrected a few more typos, and re-visited the examples * Corrected a few more typos, and re-visited the examples
(thanks to Francois for the MIME comments!) (thanks to Francois for the MIME comments!)
* removed refs to out of date Internet Conference Architecture draft * removed refs to out of date Internet Conference Architecture draft
from "Introduction" from "Introduction"
* Corrected a few more typos, and re-visited the examples * Corrected a few more typos, and re-visited the examples
<draft-ietf-pint-protocol-01.txt> PSP: Extensions to SIP and SDP June, 1999
* added initial summary list for new PINT features * added initial summary list for new PINT features
in "PINT Protocol Architecture" in "PINT Protocol Architecture"
* added a comment on the MIME version implied by PINT 1.0 * added a comment on the MIME version implied by PINT 1.0
in "PINT Protocol Architecture" in "PINT Protocol Architecture"
* added sub-section number for SDP description in "PINT Protocol * added sub-section number for SDP description in "PINT Protocol
Architecture" Architecture"
* added sub-section number for SIP description in "PINT Protocol * added sub-section number for SIP description in "PINT Protocol
Architecture" Architecture"
* removed reference to Security mechanisms in "SIP Operation in PINT" * removed reference to Security mechanisms in "SIP Operation in PINT"
* added strictures as MUST and split into separate paras for clarity in * added strictures as MUST and split into separate paras for clarity in
skipping to change at page 51, line 56 skipping to change at page 51, line 54
* removed sub-section on " PINT URLS within To: headers" and comments on * removed sub-section on " PINT URLS within To: headers" and comments on
"1-800-FLOWERS" style telephony URLs "1-800-FLOWERS" style telephony URLs
* removed references to wildcards in REGISTER messages within " REGISTER * removed references to wildcards in REGISTER messages within " REGISTER
requests within PINT" requests within PINT"
* replaced example 4.8 with new examples 4.8 - 4.12 * replaced example 4.8 with new examples 4.8 - 4.12
* added section on "Limitations on Available Information and Request * added section on "Limitations on Available Information and Request
Timing for SUBSCRIBE" Timing for SUBSCRIBE"
* added a few references that were missing * added a few references that were missing
* added "Collected ABNF" Appendix. * added "Collected ABNF" Appendix.
Changes from version 3 to verion 4: Changes from profile version 3 to verion 4:
* New changes are indicated by a -*-* mark on the line before the change * New changes are indicated by a -*-* mark on the line before the change
* added a Security Considerations Section * added a Security Considerations Section
* really added the comment on PINT/SIP implying MIME 1.0 this time! * really added the comment on PINT/SIP implying MIME 1.0 this time!
<draft-ietf-pint-protocol-01.txt> PSP: Extensions to SIP and SDP June, 1999
* added ABNF definition for the use of PINT attributes as URL parameters * added ABNF definition for the use of PINT attributes as URL parameters
* added ABNF definition of tsp URL parameter * added ABNF definition of tsp URL parameter
* added a statement that there are no current technical open issues * added a statement that there are no current technical open issues
* corrected boilerplate * corrected boilerplate
* added reference to SIP RFC number. * added reference to SIP RFC number.
Changes from version 4 to this version (indicated by -.-.) Changes from profile version 4 to this version (indicated by -.-.)
* In section 4.1, changed wording to emphasize that a "+1" number falls * In section 4.1, changed wording to emphasize that a "+1" number falls
within the N.A.N.P. region. within the N.A.N.P. region.
* Changed Ordering of Authors. * Changed Ordering of Authors.
* Changed incorrect reference to SIP in 3.4.4 - should be SDP * Changed incorrect reference to SIP in 3.4.4 - should be SDP
* CHANGED! "strict:" SDP attribute to "require:" throughout * CHANGED! "strict:" SDP attribute to "require:" throughout
* Corrected typos in 3.1 and 4.6 and 3.4.3.1, clarified text in 3.4.1 * Corrected typos in 3.1 and 4.6 and 3.4.3.1, clarified text in 3.4.1
* Changed title (repl. "profile" with more appropriate terms throughout) * Changed title (repl. "profile" with more appropriate terms throughout)
* CHANGED! SHOULD to MUST in 5.2 and also in 5.3 * CHANGED! SHOULD to MUST in 5.2 and also in 5.3
* Added section on privacy implications of identifying the associated * Added section on privacy implications of identifying the associated
requst within SUBSCRIBE (section 5.1.4) requst within SUBSCRIBE (section 5.1.4)
skipping to change at page 52, line 58 skipping to change at page 52, line 57
Note that they now share the same tag value ("require:"). Note that they now share the same tag value ("require:").
* added strict-attribute to the list of PINT/SDP attributes (duh!) * added strict-attribute to the list of PINT/SDP attributes (duh!)
* added some extra rule names for common elements (for q763xx) * added some extra rule names for common elements (for q763xx)
* added the fmtp explicit source type tags (uri, spr, and opr) to the * added the fmtp explicit source type tags (uri, spr, and opr) to the
list of items that may be specified in a strict-attribute. For PINT, list of items that may be specified in a strict-attribute. For PINT,
the expected behaviour on the part of a recipient (as mentioned in the the expected behaviour on the part of a recipient (as mentioned in the
body text) is that it should fail an Invitation including one of these body text) is that it should fail an Invitation including one of these
constructs that it doesn't support. However, including these in a constructs that it doesn't support. However, including these in a
strict-attribute allows them to be used in the wider SIP/SDP context strict-attribute allows them to be used in the wider SIP/SDP context
(e.g. as part of an OPTIONS message exchange). (e.g. as part of an OPTIONS message exchange).
Changes from "protocol" version 00 to this version (indicated by -..-)
* Security summary section 5.4 clarified and improved
8. References 8. References
[1] M. Handley, E. Schooler, H. Schulzrinne, & J. Rosenberg, [1] M. Handley, E. Schooler, H. Schulzrinne, & J. Rosenberg,
"SIP: Session Initiation Protocol", RFC2543, "SIP: Session Initiation Protocol", RFC2543,
Internet Engineering Task Force, March 1999. Internet Engineering Task Force, March 1999.
<draft-ietf-pint-protocol-01.txt> PSP: Extensions to SIP and SDP June, 1999
[2] M. Handley & V. Jacobsen, [2] M. Handley & V. Jacobsen,
"SDP: Session Description Protocol", RFC2327, "SDP: Session Description Protocol", RFC2327,
Internet Engineering Task Force, April 1998. Internet Engineering Task Force, April 1998.
[3] N. Freed & N. Borenstein, [3] N. Freed & N. Borenstein,
"Multipurpose Internet Mail Extensions (MIME) "Multipurpose Internet Mail Extensions (MIME)
Part One: Format of Internet Message Bodies", Part One: Format of Internet Message Bodies",
RFC2045, November 1996. RFC2045, November 1996.
[4] N. Freed & N. Borenstein, [4] N. Freed & N. Borenstein,
"Multipurpose Internet Mail Extensions (MIME) "Multipurpose Internet Mail Extensions (MIME)
Part Two: Media Types", Part Two: Media Types",
skipping to change at page 53, line 41 skipping to change at page 53, line 40
Internet Engineering Task Force, August 1998. Internet Engineering Task Force, August 1998.
[10] D. Crocker, [10] D. Crocker,
"Standard for the format of ARPA Internet text messages",RFC822, "Standard for the format of ARPA Internet text messages",RFC822,
Internet Engineering Task Force, August 1982. Internet Engineering Task Force, August 1982.
[11] ITU-T Study Group XI, [11] ITU-T Study Group XI,
"Q.1204 - IN Distributed Functional Plane Architecture", "Q.1204 - IN Distributed Functional Plane Architecture",
ITU-T, February 1994. ITU-T, February 1994.
[12] T. Dierks & C. Allen, [12] T. Dierks & C. Allen,
"The TLS Protocol Version 1.0", RFC2246, "The TLS Protocol Version 1.0", RFC2246,
Internet Engineering Task Force, January 1999. Internet Engineering Task Force, January 1999.
[13] R. Thayer, N. Doraswamy & R. Glenn, [13] S. Kent, R. Atkinson,
"IP Security Document Roadmap", Informational RFC2411, "Security Architecture for the Internet Protocol", RFC2401,
Internet Engineering Task Force, November 1998. Internet Engineering Task Force, November 1998.
[14] R. Housley, W. Ford, W. Polk & D. Solo, [14] R. Housley, W. Ford, W. Polk & D. Solo,
"Internet X.509 Public Key Infrastructure Certificate and CRL Profile", "Internet X.509 Public Key Infrastructure Certificate and CRL Profile",
RFC2459, Internet Engineering Task Force, January 1999. RFC2459, Internet Engineering Task Force, January 1999.
[15] D. Crocker & P. Overall, [15] D. Crocker & P. Overall,
"Augmented BNF for Syntax Specifications: ABNF", RFC2234, "Augmented BNF for Syntax Specifications: ABNF", RFC2234,
Internet Engineering Task Force, November 1997. Internet Engineering Task Force, November 1997.
[16] D. Mills, "Network Time Protocol (version 3) specification and [16] D. Mills, "Network Time Protocol (version 3) specification and
implementation", RFC1305, Internet Engineering Task Force, March 1992. implementation", RFC1305, Internet Engineering Task Force, March 1992.
[17] D. Eastlake, S. Crocker & J.Schiller, [17] D. Eastlake, S. Crocker & J.Schiller,
"Randomness Recommendations for Security", Informational RFC 1305, "Randomness Recommendations for Security", Informational RFC 1305,
Internet Engineering Task Force, March 1992. Internet Engineering Task Force, March 1992.
9. Acknowledgements 9. Acknowledgements
The authors wish to thank the members of the PINT working group for comments 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 that were helpful to the preparation of this specification. Ian Elz's
comments were extremely useful to our understanding of internal PSTN comments were extremely useful to our understanding of internal PSTN
operations. The SUBSCRIBE and NOTIFY requests were first suggested by operations. The SUBSCRIBE and NOTIFY requests were first suggested by
Henning Schulzrinne and Jonathan Rosenberg. Henning Schulzrinne and Jonathan Rosenberg.
<draft-ietf-pint-protocol-01.txt> PSP: Extensions to SIP and SDP June, 1999
Appendix A: Collected ABNF for PINT Extensions Appendix A: Collected ABNF for PINT Extensions
;; --(ABNF is specified in RFC 2234 [15]) ;; --(ABNF is specified in RFC 2234 [15])
;; --Variations on SDP definitions ;; --Variations on SDP definitions
connection-field = ["c=" nettype space addrtype space connection-field = ["c=" nettype space addrtype space
connection-address CRLF] connection-address CRLF]
; -- this is the original definition from SDP, included for completeness ; -- this is the original definition from SDP, included for completeness
; -- the following are PINT interpretations and modifications ; -- the following are PINT interpretations and modifications
skipping to change at page 54, line 50 skipping to change at page 54, line 48
INPAddr = "+" <POS-DIGIT> 0*(("-" <DIGIT>)/<DIGIT>) INPAddr = "+" <POS-DIGIT> 0*(("-" <DIGIT>)/<DIGIT>)
; -- POS-DIGIT and DIGIT as defined in SDP ; -- POS-DIGIT and DIGIT as defined in SDP
LDPAddr = <DIGIT> 0*(("-" <DIGIT>)/<DIGIT>) LDPAddr = <DIGIT> 0*(("-" <DIGIT>)/<DIGIT>)
OtherAddr = 1*<uric> OtherAddr = 1*<uric>
; -- OtherAdd defined in the context of OtherAddrType ; -- OtherAdd defined in the context of OtherAddrType
; -- uric is as defined in RFC2396 ; -- uric is as defined in RFC2396
media-field = "m=" media <space> port <space> proto media-field = "m=" media <space> port <space> proto
0*(<space> fmt) <CRLF> 1*(<space> fmt) <CRLF>
; -- NOTE redefined as subset/relaxation of original SDP definition ; -- NOTE redefined as subset/relaxation of original SDP definition
; -- space and CRLF as defined in SDP ; -- space and CRLF as defined in SDP
media = ("application"/"audio"/"image"/"text") media = ("application"/"audio"/"image"/"text")
; -- NOTE redefined as a subset of the original SDP definition ; -- NOTE redefined as a subset of the original SDP definition
; -- This could be any MIME discrete type; Only those listed are ; -- This could be any MIME discrete type; Only those listed are
; -- used in PINT 1.0 ; -- used in PINT 1.0
<draft-ietf-pint-protocol-01.txt> PSP: Extensions to SIP and SDP June, 1999
port = ("0" / "1") port = ("0" / "1")
; -- NOTE redefined from the original SDP definition; ; -- NOTE redefined from the original SDP definition;
; -- 0 retains usual sdp meaning of "temporarily no media" ; -- 0 retains usual sdp meaning of "temporarily no media"
; -- (i.e. "line is on hold") ; -- (i.e. "line is on hold")
; -- (1 means there is media) ; -- (1 means there is media)
proto = (INProto/TNProto) proto = (INProto/TNProto)
; -- redefined as a superset of the original SDP definition ; -- redefined as a superset of the original SDP definition
INProto = 1* (<alpha-numeric>) INProto = 1* (<alpha-numeric>)
; -- this is the "classic" SDP protocol, defined if nettype == "IN" ; -- this is the "classic" SDP protocol, defined if nettype == "IN"
; -- alpha-numeric is as defined in SDP ; -- alpha-numeric is as defined in SDP
TNProto = ("phone"/"fax"/"pager") TNProto = ("phone"/"fax"/"pager")
; -- this is the PINT protocol, defined if nettype == "TN" ; -- this is the PINT protocol, defined if nettype == "TN"
fmt = <subtype> fmt = (<subtype> / "-")
; -- NOTE redefined as a subset of the original SDP definition ; -- NOTE redefined as a subset of the original SDP definition
; -- subtype as defined in RFC2046. MUST be a subtype of type held ; -- subtype as defined in RFC2046, or "-". MUST be a subtype of type held
; -- in associated media sub-field ; -- in associated media sub-field or the special value "-".
-.-. -.-.
attribute-fields = *("a=" attribute-list <CRLF>) attribute-fields = *("a=" attribute-list <CRLF>)
; -- redefined as a superset of the definition given in SDP ; -- redefined as a superset of the definition given in SDP
; -- CRLF is as defined in SDP ; -- CRLF is as defined in SDP
attribute-list = 1(PINT-attribute / <attribute>) attribute-list = 1(PINT-attribute / <attribute>)
; -- attribute is as defined in SDP ; -- attribute is as defined in SDP
-.-. -.-.
skipping to change at page 56, line 5 skipping to change at page 56, line 5
-.-. -.-.
q763-natures = ("1" / "2" / "3" / "4") q763-natures = ("1" / "2" / "3" / "4")
-.-. -.-.
q763-plan-attribute = Q763-plan-tag ":" q763-plans q763-plan-attribute = Q763-plan-tag ":" q763-plans
-.-. -.-.
q763-plan-tag = "Q763-plan" q763-plan-tag = "Q763-plan"
<draft-ietf-pint-protocol-01.txt> PSP: Extensions to SIP and SDP June, 1999
-.-. -.-.
q763-plans = ("1" / "2" / "3" / "4" / "5" / "6" / "7") q763-plans = ("1" / "2" / "3" / "4" / "5" / "6" / "7")
; -- of these, the meanings of 1, 3, and 4 are defined in the text ; -- of these, the meanings of 1, 3, and 4 are defined in the text
-.-. -.-.
q763-INN-attribute = Q763-INN-tag ":" q763-INNs q763-INN-attribute = Q763-INN-tag ":" q763-INNs
-.-. -.-.
q763-INN-tag = "Q763-INN" q763-INN-tag = "Q763-INN"
skipping to change at page 57, line 5 skipping to change at page 57, line 5
; -- URI-Reference defined in RFC2396 ; -- URI-Reference defined in RFC2396
-.-. -.-.
uritag = "uri" uritag = "uri"
-.-. -.-.
opaque-ref = opr-tag ":" 0*<uric> opaque-ref = opr-tag ":" 0*<uric>
-.-. -.-.
opr-tag = "opr" opr-tag = "opr"
<draft-ietf-pint-protocol-01.txt> PSP: Extensions to SIP and SDP June, 1999
-.-. -.-.
sub-part-ref = spr-tag ":" <Content-ID> sub-part-ref = spr-tag ":" <Content-ID>
; -- Content-ID is as defined in RFC2046 and RFC822 ; -- Content-ID is as defined in RFC2046 and RFC822
-.-. -.-.
spr-tag = "spr" spr-tag = "spr"
-.-. -.-.
strict-attribute = "require:" att-tag-list strict-attribute = "require:" att-tag-list
skipping to change at page 58, line 5 skipping to change at page 58, line 5
-.-. -.-.
tsp-tag = "tsp" tsp-tag = "tsp"
-.-. -.-.
phone-context-parameter = phone-context-tag "=" phone-context-ident phone-context-parameter = phone-context-tag "=" phone-context-ident
SIP-param = ( <transport-param> / <user-param> / <method-param> / SIP-param = ( <transport-param> / <user-param> / <method-param> /
<ttl-param> / <maddr-param> / <other-param> ) <ttl-param> / <maddr-param> / <other-param> )
; -- the values in this list are all as defined in SIP ; -- the values in this list are all as defined in SIP
<draft-ietf-pint-protocol-01.txt> PSP: Extensions to SIP and SDP June, 1999
PINT-param = ( clir-parameter / q763-nature-parameter / PINT-param = ( clir-parameter / q763-nature-parameter /
q763plan-parameter / q763-INN-parameter/ q763plan-parameter / q763-INN-parameter/
tsp-parameter / phone-context-parameter ) tsp-parameter / phone-context-parameter )
URL-parameter = (SIP-param / PINT-param) URL-parameter = (SIP-param / PINT-param)
; -- redefined SIP's URL-parameter to include ones defined in PINT ; -- redefined SIP's URL-parameter to include ones defined in PINT
-.-. -.-.
Require-header = "require:" 1(required-extensions) Require-header = "require:" 1(required-extensions)
*("," required-extensions) *("," required-extensions)
; -- NOTE this is redefined as a subset of the SIP definition ; -- NOTE this is redefined as a subset of the SIP definition
; -- (from RFC2543/section 6.30) ; -- (from RFC2543/section 6.30)
-.-. -.-.
required-extensions = ("org.ietf.sip.subscribe" / required-extensions = ("org.ietf.sip.subscribe" /
"org.ietf.sdp.require") "org.ietf.sdp.require")
<draft-ietf-pint-protocol-01.txt> PSP: Extensions to SIP and SDP June, 1999
Appendix B: IANA Considerations Appendix B: IANA Considerations
There are three kinds of identifier used in PINT extensions that SHOULD There are three kinds of identifier used in PINT extensions that SHOULD
be registered with IANA, if a new value is specified. These are: be registered with IANA, if a new value is specified. These are:
* Media Format sub-types, as described in section 3.4.2 of this document. * Media Format sub-types, as described in section 3.4.2 of this document.
* Private Attributes as mentioned in section 3.4.3 * Private Attributes as mentioned in section 3.4.3
* Private Phone Context values, as described in section 3.4.3.1. * Private Phone Context values, as described in section 3.4.3.1.
It should be noted that private Address Types (in section 3.4.1) have been 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 explicitly excluded from this process, as they must be in the form of
skipping to change at page 60, line 5 skipping to change at page 60, line 5
be "all values of TNProto". be "all values of TNProto".
B.2. Private Attributes B.2. Private Attributes
Any proprietary attribute lines that are added may be registered with IANA 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 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 used in SDP. If the attribute is defined for use only within PINT, then it
may be approapriate to mention this in the supporting documentation. Note may be approapriate to mention this in the supporting documentation. Note
that, in the PINT 1.0 specification covered here, there is no mechanism to that, in the PINT 1.0 specification covered here, there is no mechanism to
add such freshly registered attribute lines to a "require:" clause. add such freshly registered attribute lines to a "require:" clause.
<draft-ietf-pint-protocol-01.txt> PSP: Extensions to SIP and SDP June, 1999
B.3. Private phone-contexts B.3. Private phone-contexts
Within the session description used for PINT requests, a phone-context Within the session description used for PINT requests, a phone-context
attribute may be used to specify the prefix or context within which an attribute may be used to specify the prefix or context within which an
associated telephone-number (in a connextion line) should be interpreted. associated telephone-number (in a connextion line) should be interpreted.
For "public" phone contexts the prefix to be used MUST start with either 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 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 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 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 (see example 4 in section 3.4.3.1). In the example, the prefix acts as
skipping to change at page 61, line 5 skipping to change at page 61, line 5
In short, this context is the telephone equivalent of a "Net 10" address 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 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 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 for the network and address types (and address value syntax) with which this
context is associated. context is associated.
Of course, IANA may refer the requested registration to the IESG or an 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 appropriate IETF working group for review, and may require revisions to be
made before the registration is accepted. made before the registration is accepted.
<draft-ietf-pint-protocol-01.txt> PSP: Extensions to SIP and SDP June, 1999
Appendix C: Author's Addresses Appendix C: Author's Addresses
Scott Petrack Scott Petrack
MetaTel, Inc. MetaTel, Inc.
284 North Ave. 284 North Ave.
Weston, MA 02493 Weston, MA 02493
scott.petrack@metatel.com scott.petrack@metatel.com
+1 (781)-891-9000 +1 (781)-891-9000
Lawrence Conroy Lawrence Conroy
 End of changes. 81 change blocks. 
147 lines changed or deleted 38 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/