[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 04                                                   
Internet Engineering Task Force                                  PINT WG
INTERNET-DRAFT                                                 Scott Petrack
draft-ietf-pint-profile-00.txt                           Lawrence Conroy
7 August 1998                                       Expires: 7 February 1998

                     The PINT Profile of SIP and SDP:
           a Protocol for IP Access to Telephone Call Services

Status of this Memo

This document is an Internet-Draft.  Internet-Drafts are  working
documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other  groups  may  also  distribute
working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of  six  months
and  may  be  updated,  replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as ``work in progress.''

To learn the current status of any  Internet-Draft,  please  check  the
``1id-abstracts.txt''  listing contained  in the Internet-Drafts Shadow
Directories on   ftp.is.co.za (Africa),  nic.nordu.net  (Europe),
munnari.oz.au (Pacific  Rim), ftp.ietf.org (US  East  Coast),  or
ftp.isi.edu (US West Coast).

Distribution of this document is unlimited.

Copyright Notice

Copyright (c) The Internet Society (1998). All Rights Reserved


This document contains the specification of the PINT Profile 1.0, which
defines a protocol for invoking certain telephone services from an IP
network. These services include placing basic calls, sending and
receiving faxes, and receiving content over the telephone. The protocol
is specified as a set of enhancements and additions to the SIP 2.0  and
SDP 2.0 protocols.

This document is intended for the PSTN-Internet Interworking (PINT)
working group of the Internet Engineering Task Force. Comments
are solicited and should be addressed to the working group's mailing
list at pint@lists.research.bell-labs.com and/or the authors.


1. Introduction and Glossary

2. PINT Milestone Services
        2.1     Request to Call
        2.2     Request to Fax
        2.3     Request to Hear Content
        2.4     Relation between PINT Milestone Services and Standard
            Telephone Services

3. PINT Functional and Protocol Architecture
        3.1     PINT Functional Architecture
        3.2     PINT Protocol Architecture
        3.3     REQUIRED and OPTIONAL elements for PINT compliance
        3.4     PINT profile of SDP 2.0
                3.4.1 Network Type "TN" and Address Type "RFCxxxx"
                3.4.2 Media Types, Transport Protocol parameters, format
                  parameters and format specific attributes for TN
                  connected terminals
                3.4.3 Format attributes for included content data
                3.4.4 Attribute Tags to pass information into the Telephone
                3.4.5 The "strict" attribute
        3.5     PINT profile of SIP 2.0
                3.5.1 Multi-part mime sending of data along with SIP request
                3.5.2 Warning header
                3.5.3 The STATUS request
                3.5.5 PINT URLs within PINT requests
                3.5.6 Telephone Network Parameters within PINT URLs
                3.5.7 BYE requests in PINT
                3.5.8 REGISTER requests in PINT

4. Examples of PINT Requests and Responses
        4.1 A request from an anonymous user to receive a phone call from
          a Call Centre
        4.2 A request from a non anonymous user to receive a phone call
        4.3 A request to get a fax back
        4.4 A request to have information read out over the phone
        4.5 A request to send a text page to a user's pager. The text is
          included in the request.
        4.6 A request to send an image as a fax to fax machine.
        4.7 A request to read out over the phone two pieces of content in
        4.8 Interaction with a Proprietary IVR-based FaxBack System

5. Security Considerations
6. Deployment considerations
        6.1 Web Front End to PINT Infrastructure
        6.2 Redirects to Multiple Servers
        6.3 Competing PINT gateways REGISTERing to offer the same service
        6.4 Relations to Intelligent Network and Public Network Standards
                6.4.1 ITU-T
                6.4.2 ETSI
                6.4.3 ANSI
                6.4.4 Other Standards
        6.5  Relation between PINT Milestone services and ITU-T Q.1231
                6.5.1 PINT Services
                Click-to-Dial-Back (CTDBC)
                 Click-to-Fax (CLTFA)
                Click-to-Fax-Back (CLTFB)
                (Internet-Initiated) Voice-Access-to-Content (VATCI)
                PINT vs. ITU-T service descriptions
                6.5.2 Parameters needed for PINT Services
                Service Identifier
                A and B parties
                Other Service Parameters
                Service Parameter Summary
                6.5.3 Q.1231 Parameter Mapping within PINT
7. Open Issues
8. References
9. Acknowledgements
10.Author's Addresses

1. Introduction

The desire to invoke certain telephone call services from the
Internet has been identified by many different groups (users, public and
private network operators, call centre service providers, equipment
vendors, etc.). The generic scenario is as follows (when the invocation
is successful):

        1. an IP host sends a request to a server on an IP network;
        2. the server relays the request into a telephone network;
        3. the telephone network performs the requested call service.

One example is a user sending a request to have a call placed to his/her
telephone. It may be that a customer wishes to get a call from the
support department of some business, or a user wishes to hear some
remote automatic weather service via recorded or synthesised speech.
Within a local environment such a request might result in the placement
of a call between employees over the internal PBX.

We use the term "PINT Service" to denote such a complete transaction,
starting with the sending a request from an IP client and including the
telephone call service.  ("PINT" is short for "Phone-IP Interworking
Services").  A PINT service always involves the placement of a call
within some Telephone Network.  The original meaning of the acronym
"PINT" was "PSTN-Internet Interworking", but the term has since been
broadened to allow services which involve any type of circuit-switched
telephone system, not just the "Public" Switched Telephone System.
Private PBXs, cellular phone networks, and the ISDN can all be used to
deliver PINT services.  Also, the request for service might come from
within a private IP network that is disconnected from the whole Internet.

There is some overlap between PINT service requests and third-party call
control. The requirements for the PINT protocol were deliberately
restricted to providing the ability to invoke a small number of fixed
telephone call services. These "Milestone PINT services" are specified
in section 2. Great care has been taken, however, to develop a protocol
that fits into the emerging Internet Conference Architecture [],
so that future extensions to PINT could develop along with Internet

Within the Internet Conference Architecture, establishing media
calls is done via a combination of protocols. SIP [ ] is used to
establish the association between the participants within the call
(this association between participants within the call is called a
"session"), and SDP [ ] is used to describe the media to be
exchanged within the session. The PINT protocol uses these two
protocols, providing some extensions and enhancements to
enable SIP clients and servers to become PINT clients and servers.

The underlying model of Internet Conference sessions is unchanged. The
PINT user who wishes to invoke a service within the phone system uses
SIP to invite a remote PINT server into a session. ("The user places a
SIP call"). The invitation contains an SDP description of the media
session that the user would like to take place. (This might be a
"sending a fax session" or a "telephone call session", etc.)  Acceptance
of the invitation by the PINT server establishes a session between the
client and server, during which the requested media can be sent. In a
PINT session the media is transported over the phone system, while in a
SIP session the media is normally transported over an internet.

The particular requirements of PINT users lead to some new messages,
however. For example, the fact that a server accepts an invitation and a
session is established is no guarantee that the media will be
successfully transported, neither in vanilla SIP nor in PINT.  For
example, a PINT server may accept to send a fax to telephone B, but it
may be that the fax transmission fails after part of the fax is sent.
Therefore, the PINT client needs to be able to receive information about
the status of the actual telephone call session that was invoked as a
result of the established PINT session. This requirement leads to a new
STATUS request and to some new Warning: messages.

We can summarise the relationship between PINT and SIP as follows: The
invitation sequence (INVITE-OK-ACK) establishes a Internet Session
between the PINT server and client. The request contains a description
of the "telephone network media transport session" requested. The PINT
server sends an OK to signal its agreement to establish a PINT session
with the client. The actual transportation of media over the phone
(a.k.a "the phone call") might happen hours or days after the
establishment of the PINT call. Similarly, the phone call
might complete long before any BYE is sent. As
long as no BYE is sent, then the PINT session exists, and the client may
request the STATUS of the session, or may even request to change a
session parameter. Of course, it may be impossible to change the session
parameters (for example, the fax may already have been totally or
partially sent). The client sends a BYE to signal its desire to end the
PINT call. Once the BYE is acknowledged, there is no
longer any PINT association between the PINT client and server. A
Warning: line is used within the response to the BYE to indicate the
status of the telephone-side media transport session. Finally, at any
point during the PINT session (and possibly even afterwards), a client
may send a STATUS message to the PINT server to retrieve information
about the telephone network session associated to the PINT request.

The enhancements and additions specified here are not intended to alter
the behaviour of baseline SIP or SDP in
any way. The milestone PINT services fit seamlessly into the
rest of the Internet Conference Architecture, and the PINT profile can
be used to extend the usual SIP/SDP services to the telephone world.
This is a great added benefit of using SIP/SDP as the protocol to invoke
the PINT services. Apart from integrating well into existing protocols
and architectures, and the advantages of reuse, this means that the
protocol specified here can handle a rather wider class of call services
than just the Milestone services.

Some of the enhancements specified here (such as the use of
multipart MIME) make sense in the context of a pure Internet Conference.
The PINT profile has been designed so that each enhancement is
independent of any other. SIP transactions that have nothing to do with
telephone call services and telephone sessions should be able to use
these enhancements. It is possible that these will become part of future
versions of SIP and SDP.

The rest of this document is organised as follows: Section 2 describes
the original PINT Milestone services precisely; section 3 specifies the
PINT functional and protocol architecture; section 4 specifies the new
tags and headers in the PINT 1.0 profile of SIP and SDP; section 5
contains some security considerations for PINT. The final section
contains some informative examples.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
document are to be interpreted as described in RFC 2119. In addition,
the construct "MUST .... OR  ...." implies that it is an absolute
requirement of this specification to implement one of the two
possibilities stated (represented by dots in the construct). An
implementation MUST be able to interoperate with another implementation
which chooses either of the two possibilities.

1.1 Glossary

Requestor - An Internet Host from which a request for service originates

PINT Service - A services invoked within a phone system in response to a
request received from an PINT client.

PINT Client - An Internet Host that sends requests for invocation a PINT
Service, in accordance with this profile.

PINT Server - An Internet Host that accepts requests for PINT Service
and dispatches them onwards towards a telephone network.

Executive System - A system which interfaces to a telephone network that
executes a PINT service, and to a PINT Server. It is not directly
associated with the Internet, and is represented by the PINT Server.

Requesting User - The initiator of a request for service. This role may
be distinct from that of the "party" to any telephone network call that
results from the request.

(Service Call) Party - A Person who is involved in a telephone network
call that results from the execution of a PINT service request, or a
telephone network-based resource that is involved (such as an automatic
Fax Sender or a Text-to-Speech Unit).

2. Milestone Services

2.1 Request to Call

        A request is sent from an IP host which causes a phone call to be
made, connecting party A to some remote party B.

2.2 Request to Fax

        A request is sent from an IP host that causes a fax to be sent to
fax machine B. The request MUST EITHER contain a pointer to the fax data
(which could reside in the IP network or in the Telephone Network), OR
the request itself contain fax data. The content of the fax MAY be
text or some other more general image data. The precise rendering of
such data in a suitable form for the remote fax is outside the scope of

2.3 Request to Hear Content

        A request is sent from an IP host which causes a phone call to be
made to user A. Then some sort of content is spoken out over this phone
call. The request MUST EITHER contain a URL pointing to the content, OR
alternatively contain the content itself. The content MAY be text or
some other more general application data. The precise rendering of the
content into speech over the phone is beyond the scope of this
specification. (Although certain aspects of this rendering, such as
language preference, can be expressed and are discussed in section 3).

2.4 Relation between PINT Milestone Services and "Standard" Telephone

The above characterisations may seem to lack precision to those familiar
with various telephone service definitions (see for example [ ], [ ],
[ ]). This is because there are many different versions and variations
of each telephone call service described above. Consider as an example
what happens when a user requests to receive a call from 1-800-CALL-CTR
via the PINT "Request to Call" service. There may be thousands of agents
in the call centre, and there may be any number of sophisticated
algorithms and equipment which is used to decide exactly which agent
will return the call. Even once this choice is made, there may be many
different ways to set up the call. The agent's phone might ring first,
and only then the original user will be called. Or perhaps the user will
be called first, and will hear some horrible music or pre-recorded
message while the agent is located.

PINT 1.0 reflects a deliberate decision to avoid specifying too closely
the precise telephone-side service. Operational details of individual
events within the telephone network that executes the request are
outside the scope of PINT. Section 6.5.1 contains a description of the
relationship between ITU-T telephone service standards and the PINT Milestone services.

3. PINT Functional and Protocol Architecture

3.1     PINT functional architecture

Familiarity is assumed with SIP 2.0 [] and with SDP 2.0 [].

PINT clients and servers are be SIP clients and servers.
SIP is used to route the request over the IP network to the correct
PINT server in a secure and reliable manner, and to communicate the
status of outstanding requests.

A PINT system may use proxy servers and redirect servers for their usual
SIP purpose, but at some point there must be a PINT server with some
means of relaying received requests into a telephone
system, and also some means to receive acknowledgement of these relayed
requests. A PINT server with this capability is called a "PINT gateway".
A PINT gateway appears to a SIP system as a user agent server.

So the PINT system might appear to an individual PINT client as follows:

                      /\/\/\/\/\/\/\          /\/\/\/\/\/\/\/\
___________           \          __/___    ___\_             \
|  PINT   |    PINT   \   PINT  | PINT |   |Exec| Telephone  /
| client  |<--------->|  server |gatewy|===|Syst| Network    \
|_________|  protocol /  cloud  |______|   |____|  Cloud     /
                      \            \          /              \
                      /\/\/\/\/\/\/\          \/\/\/\/\/\/\/\/

                Figure 1: PINT Functional Architecture

The system of PINT servers is represented as a cloud to emphasise that
a single PINT request might pass through a series of location servers,
proxy servers, and redirect servers, before finally reaching the correct
PINT gateway which can actually process the request by passing it to the
Telephone Network Cloud.

gateway might have a true telephone network interface (for example an
analogue, PRI, or SS7 interface supporting DTMF, Q.SIG or ISUP), or it
might be connected via some other protocol or API to an "Executive
System" which is capable of invoking services within the telephone
cloud). The distinction between the PINT gateway and the Executive
System is a logical one; a single server may fulfil both functions.
The communication between the PINT gateway and the Telephone
Network Cloud via the Executive System is outside the scope of PINT.

As an example,
in an IN (Intelligent Networking) -enabled system,  this might be done
by means of an "Intelligent Peripheral" which is attached to both the
IP network and the IN network. In an office environment, it might be
accomplished by a server which is adjunct to the office PBX, connected
to both the office PINT server and the office PBX.

3.2 PINT protocol architecture

PINT uses SIP and SDP in combination to convey the required information
about requests and responses.

The SDP payload contains a description of the particular telephone call
service which the requestor wishes to occur in the PSTN. The information
contained in the session description includes such things as the TN
address (i.e. the "telephone number") of the terminal(s) that should
receive the call, an indication of the media type to be transported
(e.g. audio, text, image or application data), and an indication if the
information is to be transported over the TN via voice, fax, or pager
transport. An indication of the content to be sent to the remote
telephone terminal (if there is any) is also included.

One advantage of using SDP is that the pieces of information are
conveyed independently. For example, a request to send some text via
voice transport will be fulfilled by invoking some text-to-speech-over-
the-phone service, and a request to send text via fax will be fulfilled
by invoking some text-to-fax service.

The following is a list of PINT 1.0 enhancements and additions to SDP.

      a. A new Network Type "TN" and address types "RFCxxxx" and "X-..."
         (section 3.4.1)
      b. New media types "text", "image", and "application", the
         associated new protocol transport keywords "voice", "fax" and
         "pager" and the associated format types and attribute tags
         (section 3.4.2)
      c. New Format Specific Attributes for included content data
         (section 3.4.3)
      d. New attribute tags, used to pass information to the TN (section
      e. A new attribute tag "strict", used by a client to indicate that
         some attribute is required to be supported in the server
         (section in 3.4.5)

SIP is used to route the request for telephone service from the PINT
client to the PINT gateway. The following is a complete list of PINT
enhancements and additions to SIP:

        f. The multipart MIME payloads as specified (section 3.5.1)
        g. The "Warning:" header as specified (section 3.5.2)
        h. The STATUS request as specified (section 3.5.3)
        i. Require: headers for PINT clients (section 3.5.4)
        j. A format for PINT URLS within a PINT request (section 3.5.5)
        k. PINT URLs (section 3.5.6)
      l. The security mechanisms of section 5 for third party

Section 3.5.7 contains remarks about how BYE requests are used within
PINT, and section 3.5.8 contains remarks about how REGISTER requests
are used within PINT. These do not change the behaviour of baseline
SIP in any way; they are included here for clarification of the
semantics when used with Telephone Network Sessions.

3.3     REQUIRED and OPTIONAL elements for PINT compliance

PINT 1.0 clients MUST support the TN network type and the RFCxxxx
address type. Servers MUST in addition support the STATUS method,
"Warning: headers, and the "strict" attribute. The other new protocol
elements are "conditionally mandatory". This means that each new PINT
construct enables a different function, and a client or server which
wishes to enable that particular function MUST do so by the construct
specified in this document. However, there is no single PINT service
that is required to be supported by all PINT clients or servers. For
example, one can build a PINT client and server which only supports the
Request-to-Call telephone call service, without support for the
other Milestone services.

In general, many optional features of SIP and SDP make sense as
specified in the PINT context. An example is the SDP a=lang: attribute,
which can be used to describe the preferred language of the callee.
Another example is the use of the t= parameter to indicate that the time
at which Telephone Call Service is to be invoked. Since the Session
Description within the PINT request describes exactly the "telephone
call session" to be invoked, this is simply the usual use of the t=
field. A third example are the quality attributes. Any SIP or SDP
option or facility is available to PINT clients and servers without

3.4     PINT profile of SDP 2.0

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

This section gives details of these new SDP keywords.

3.4.1   Network Type "TN" and Address Type "RFCxxxx"

        The TN ("Telephone Network") network type is used to indicate that
the terminal is connected to a telephone network.

The address types allowed for network type TN are "RFCxxxx" (the "xxxx"
will be filled in by either the Telephony-URL RFC number or the SIP RFC
number) and private address types, which MUST begin with an "X-".

Address type RFCxxxx is a string conforming to the "telephone-
subscriber" BNF specified in RFCxxxx, [, section x.y.z]

        c= TN  RFCxxxx  +1-201-406-4090
        c= TN  RFCxxxx  12014064090

A telephone-subscriber string is of one of two types: global-phone-
number or local-phone-number. These are distinguished by the fact that a
global-phone-number begins with a "plus" sign "+". A global-phone-number
is by default to be interpreted as an internationally significant E.164
number, as defined by [ ]. A local-phone-number string is by default to
be interpreted as belonging to an unknown numbering plan, as defined by
[ ].

These defaults may be changed by the use of the attributes defined in
section 3.4.5 below.

An implementation MAY use private addressing types, which can be useful
within a local domain. These address types MUST begin with an "X-",
and SHOULD contain a domain name after the X-, e.g. "X-
mytype.mydomain.com". An example of such a connection line is as

        c= TN X-mytype.mydomain.com  A*8-HELEN

Note that most dialable telephone numbers are writeable as local-phone-
numbers within address RFCxxxx; new address types should only be used
for formats which cannot be so written.

[??? Do we need an new address type which includes DTMF keys A, B, C and D???]

3.4.2  Media Types, Transport Protocol parameters, format parameters and
      format specific attributes for TN connected terminals

In order to describe the media that can be transported to TN
terminals within TN sessions, PINT 1.0 specifies the use of some new
media types, transport protocol parameters, format parameters, and
format specific parameters. This specification only applies when used
with terminals connected via the "TN", although much of the semantic
carry over without change to IN connected terminals as well.

The media types within PINT 1.0 requests MUST be one of "audio",
"image", "text" and "application." Note that each of these is a well-
defined MIME type (see []). The port number for PINT terminals MUST be
0.  The transport protocol keywords MUST be one of are "voice", "fax",
and "pager." Within each request, the allowed format parameters are
precisely the MIME sub-types of the MIME types that appear within the
media type within the request. Format Specific Attributes are used to
indicate the actual content to be transported to the remote terminal for
example, when the remote telephone terminal is a fax machine or pager).

Media type "audio" must only be used with transport protocol "voice."
There are no defined format parameters. This indicates a TN terminal
which wishes to receive an "plain old voice telephone call." As an
example, the following excerpt from a session description describes a
phone which is ready to receive an ordinary phone call at E.164
international phone number +12014064090:

        c= TN  RFCxxxx  +12014064090
        m= audio 0      voice

[???One could imagine a media description like "m= audio 0 fax wav"
which would mean to "play a wav file out to a fax machine," for example
via speech-to-text-to-fax. Do we need to mention this explicitly?
Similarly with "m= audio 0 pager wave" for playing out audio files to a
remote pager. These are not milestone services -- do we need to mention
them specifically now? We could just include text allowing any MIME sub-
type of the major type as an option]

Media Type "image" MUST be used with EITHER transport protocol "fax" OR
"pager". The allowed format parameters are any MIME subtype of MIME type
image (see []). The format specific attribute "a=fmtp:<fmt>  <URIs>" MAY
be used to include a URI which points to the image data to be sent to
the remote TN terminal (see section 3.2.3 below). Alternatively, the
format specific attribute "a=fmtp:<fmt>  <Content-ID>" MAY be used to
indicate that image data is included within the PINT request itself,
within a multipart MIME part. (see section 3.4.3 below).

When the protocol is "fax," the image is to be transported over the TN
to a remote fax machine. And when the protocol is "pager" the image is
to be transported over the TN to some remote pager machine.

[??As before, One could easily imagine a media description like "m=
image 0 fax voice" which would mean to "describe in voice the image,"
for example via some sort of image recognition. Do we need this?]

Here is an example of the use of media type image to send a jpeg image
stored on the internet at http://www.acme.com/~sbp/pic1.jpeg to a fax
machine at phone number +1-201-406-4090:

        c= TN  RFCxxxx  +1-201-406-4090
        m= image  0  fax  jpeg
        a=fmtp:jpeg  http://www.acme.com/~sbp/pic1.jpeg

Media Type "text" can be used with transport protocols "fax,"
"voice," or "pager". The "voice" protocol indicates that the phone
system is to use some text-to-speech mechanism to read out the text to
the indicated phone terminal. The "fax" protocol indicates that the text
is to be printed out as is on a remote fax machine. The "pager" protocol
transports the text to a remote machine. (The PINT server may return a
"606 Not Acceptable" error if the content to be transmitted contains
unsupported characters, e.g. If the remote pager can receive only digits
and some text is sent) The allowed format parameters are any MIME
subtype of MIME type text (see [ ]). As with media type "image", the
format specific attribute tags ("a=fmtp:<fmt> <params>) are used to
indicate the precise data to be sent over the Telephone Network to the
remote terminal. The <params> can contain either a URI or a content-ID.

Media type "application" MAY be used with transport protocol
"fax," "voice," or "pager". In principle, any MIME subtype of type
"application" can be used as the format, but the main intent in to allow
media type application is to allow format parameter URI. This is used in
combination with an attribute tag "a=fmtp:URI <URI>" to indicate that
the URI written in the attribute tag points to some content on the
Internet which is to be sent via either "voice transport" or "fax
transport" to the remote TN terminal. This is the generic way that a
PINT request is made to fax/read-out the content pointed to by URI <URI>
to the TN terminal indicated in the connection (c= ) line.

Some PINT requests are to invoke telephone network sessions where
specific content is to be transported to the remote terminal. For
example, this happens when the request is for the Milestone Service
"Request-to-Fax" and Request-to-hear-Content.

If the PINT request is a request to transport data to a TN terminal,
then the media description contains a format parameter which must be a
MIME sub-type of the media type indicated in the start of the m= line.
It is allowed to include several format parameters in the media
description. This indicates alternative image formats of the same
content which are available on the internet for the server.

In order to point to the content on the IP network which is to be
sent, a format specific parameter is used:

        a=fmtp:<fmt> <URIs>

The <fmt> must be one of the MIME subtypes that appear in the m= media
description line. The <URIs> is a string of URIs, each one of which
points to data of the specified MIME subtype. If more than one URI is
included in the attribute, they are to be space separated, and this
indicates that ALL the URIs are to be sent, serially, one after the
other. This can be used, for example, to send several different
unrelated URIs within a single fax transmission.

If there is more than one format in the m= line, this indicates that the
same information is available in different alternative formats. Each
format must have a single associated format specific attribute line.
Within a single media description, all the attribute lines
point to the same information to be sent over the TN, and that the
PINT server can use ANY ONE of the formats and attribute lines to
retrieve the data to be sent. The alternatives are listed in order of
preference, with the first alternative first.

If a single PINT request contain several media descriptions, this
is an indication to send several different pieces of content, each one
with a different format. Each media description describes a single piece
of content to be sent. They are to be sent serially, one after the
other, in the order of their appearance within the session description.

It is also possible to use the media type "application" with format
parameter "URI", with format specific attributes containing a string of
unrelated URIs:

        c= TN RFCxxxx +1-201-406-4090
        m= application 0  voice  URI
        a=fmtp:URI http:xxxxx  http:yyyyyy ......

This is a request to read out the content of a series of unrelated Web
Pages over the TN to the phone terminal at address +1-201-406-4090.
The URIs are sent serially, one after the other, in the order of their
appearance within the attribute line.

This scheme provides maximum simplicity in the usual cases of a request
for sending some single piece of data, but allows the flexibility to
store the same data in various alternative formats (say storing a
picture in some proprietary highly-compressed form and in some more
simple generally-understood form). It allows a single request to
be for sending multiple bits of content to the remote terminal.

Note that it may be more than one PINT request which results in the same
service. For example, the content might be reachable as media type
"text/plain" or more generically as media type application/URI. If the
requestor knows at request time that the data to be sent is of
type image or text, it is RECOMMENDED that the media description
indicate this rather than use the generic media type "application," such
as in "m= application 0 fax URI". The following two descriptions might
result in the same TN service, but the second is more precise
and if it is the desired service it is preferable to use it:

        m=application 0 fax URI
        a=fmtp:URI http://www.acme.com/pic1.tif

        m=image 0 fax tif
        a=fmtp:tif http://www.acme.com/pic1.tif

Note that these two descriptions are not truly equivalent. The first
description is a generic request to "fax me the indicated URI", and it
is not clear exactly what sort of translation will appear at the fax
machine. The second description is a more precise request to render the
tif picture on the remote fax machine. (It is of course true that it is
not specified exactly how the image/tif is to be rendered, but
the instruction to render media type image/tif gives more information
than the instruction to render media type application/URI).

3.4.3 Format attributes for included content data

In addition to pointing to the data on the internet,
it is possible to include the content data within the SIP
request itself. This is done by having the SIP payload be multipart
MIME. The first MIME part contains the SDP description of the telephone
call service to be executed. The other MIME parts contain the Content Data
to be transported. Within the SDP MIME part, format specific
attributes lines are used to indicate which other MIME part within the
request contains the content data. Instead of a URI, the format specific
attributes indicates the Content-ID of the MIME part of the request
which contains the actual data:

        c= TN RFCxxxx +1-201-406-4090
        m= text 0  fax plain
        a=fmtp:plain  <Content-ID>

The <Content-ID> parameter is the Content-ID of one of the MIME parts
inside the message. One can always distinguish a Content-ID
from a URI by the presence of a colon before the @ sign, and this can be
used to distinguish between included content and content which resides
elsewhere on the Internet.

For example, in a multipart message where the string "------next-------"
is the boundary, the first two parts might be as follows:

        Content-Type: application/sdp
        c= TN RFCxxxx +1-201-406-4090
        m= text 0 pager plain
        a=fmtp:plain 17@mymessage.acme.com

        Content-Type: text/plain
        Content-ID:  17@mymessage.acme.com

        This is the text that is to be paged to +1-201-406-4090.


PINT clients should be extremely careful when sending included data
within a PINT request. Such requests SHOULD be sent via TCP, to avoid
fragmentation and to transmit the data reliably. It is possible that the
PINT server is a proxy server that will replicate and fan out the
request, which could be disastrous if the request contains a large
amount of application data. PINT proxy servers should be careful not
to create many copies of a request with large amounts of data in it.

This mechanism is particularly useful when the request is to send a
short message to a Telephone Network Pager. The ability to indicate
different  alternatives for the content to be transported is also
useful, even when the alternatives are included within the request. For
example, a request to send a short message to a pager might include the
message in unicode [ ] and an alternative version of the same content in
text/plain, should the PINT server or telephone network not be able to
process the unicode.

3.4.4  Attribute Tags to pass information into the Telephone Network

It may be desired to include within the PINT request service
parameters which can be understood only by some entity in the Telephone
Network Cloud. SDP attribute parameters are used for this purpose. They
MAY appear within a particular media description or outside of a media
description. These attributes may also appear within PINT URLS
(see section 3.5.6). This is necessary so that telephone terminals
which require the attributes to be defined can appear within the To:
line of a PINT request as well as within PINT session descriptions.

The purpose of these attributes is to allow the client to specify
extra context within which a particular telephone number is to be
interpreted. Although it is recognised that such attributes are
occasionally necessary, for reasons internal to the telephone networks
which carry out the PINT requests, the URLs appearing in the To: and
From: headers and within the Request-URI offer a

These attributes are often used in conjunction with the "strict"
attribute (section 3.4.5) and the "org.ietf.ping.strict" Require: tag
(section 3.5.4).

It is not possible to standardise every possible internal telephone
network parameter. PINT 1.0 attributes have been chosen for
specification because they are common enough that many different PINT
systems will want to use them, and therefore interoperability will be
increased by having a single specification. ITU-T CalledPartyAddress attributes parameters

These attributes correspond to fields that appear within the ITU-T Q.763
"CalledPartyAddress" field [ ITU-T Q.763 ,section 3.9 ]. PINT clients
use these attributes in order to specify further parameters relating to
Terminal Addresses, in the case when the address indicates a
"local-phone-number." In the case that the PINT request contains a
reference to PSTN terminal, the parameters may be required to correctly
identify the remote terminal

The defined attributes are:

a=Q763-nature:  - indicates the "nature of address indicator".
                    The value MAY be any number between 0 and 127.
                    The following values are specified:

                                "1"     a subscriber number
                                "2"     unknown
                                "3"     a nationally significant number
                                "4"     an internationally significant number

The values have been chosen to coincide with the values in Q.763. Note
that other values are possible, according to national rules or future
expansion of Q.763.

a=Q763-plan:    - indicates the numbering plan to which the address
                    belongs. The value MAY be any number between 0 and
                    7. The following values are specified:

                                "1"     Telephone numbering plan (ITU-T E.164)
                                "3"     Data numbering plan (ITU-T X.121)
                                "4"     Telex numbering plan (ITU-T F.69)

The values have been chosen to coincide with the values in Q.763. Note
that other values are possible, according to national rules or future
expansion of Q.763.

a=Q763-INN              - indicates if routing to the Internal Network Number
                    is allowed. The value MUST be ONE of:

                                "0"     routing to internal network number allowed
                                "1"     routing to internal network number not

The values have been chosen to coincide with the values in Q.763.

Note that it is possible to use a local-phone-number and indicate via
attributes that the number is in fact an internationally significant
E.164 number. Normally this SHOULD NOT be done; an internationally
significant E.164 number is indicated by using a "global-phone-number"
for the address string.  The phone-context attribute

An additional attribute is specified to enable "remote local dialling".
This is the service that allows a PINT client to reach a number from
far outside the area or network which can usually reach the number. It
is useful when the sending or receiving address is only dialable within
some local context, which may be remote to the origin of the PINT

For example, if Alice wanted to report a problem with her telephone, she
might then dial a "network wide" customer care number; within the
British Telecom network in the U.K., this is "152". Note that in this
case she doesn't dial any trunk prefix - this is the whole dialable
number. If dialled from another operator's network, it will not connect
to British Telecom's Engineering Enquiries service; dialling "+44 152"
will not normally succeed, as it's Network-Specific Service Number.

Within the telephone network, the "local context" is provided by the
physical connection between the subscriber's terminal and the central
office. An analogous association between the PINT client and the PINT
server which first receives the request may not exist, which is why it
may be necessary to supply this missing "telephone network context."

There are many reasons why extra context might be necessary to interpret
a given telephone number:

        a. The telephone number might be reachable in many different ways,
        such as via competing telephone service providers, and the PINT
        client wishes to indicate its selection of service provider.
        b. The telephone number might be reachable only from a limited
        number of networks, such as an '800' freephone number.
        c. The telephone number might be reachable only within a
        single telephone network, such as the '152' customer service
        number of BT. Similarly, the number might be an internal
        corporate extension reachable only within the PBX.

However, as noted above, it should not usually be necessary to use SDP
attributes to specify the phone context. URLs such as 152@pint.bt.co.il
within the To: header and/or Request-URI, normally offer sufficient
context to resolve telephone numbers.

This attribute is defined as follows:

a=phone-context: <phone-context-identifier>
phone-context-identifier =  network-prefix | private-prefix

network-prefix          = intl-network-prefix | local-network-prefix
intl-network-prefix     = "+" 1*DIGIT
local-network-prefix    =  1*DIGIT
private-prefix          =  <need BNF for a string which is not intl-
                            network-prefix or local-network-prefix>

Although not every phone-context can be specified, the local contexts
which correspond to dialable public telephone networks can be. An
intl-network-prefix and local-network-prefix MUST be a bona fide network
prefix, and a network-prefix which is an intl-network-prefix MUST begin
with an E.164 service code ("country code").

It is possible to register new private-prefixes with IANA so as to
avoid confrontation. Prefixes which are not so registered MUST begin
with an "X-" to indicate their private, non-standard nature.

Example 1:

     c= TN   RFCxxxx  1-800-765-4321

This describes an terminal whose address in Israel (E.164 country code
972) is 1-800-765-4321.

Example 2:

     c= TN   RFCxxxx  1-800-765-4321

This describes an terminal whose address in North America (E.164
country code 1) is 1-800-765-4321.

The two telephone terminals described by these descriptions are
different; in fact they are located in different countries.

Example 3:

     c=TN RFCxxxx  *123

This describes a terminal whose address when dialled from within the
network identified by +97252 is the string "*123". It so happens that
+97252 defines one of Israeli cell phone providers, and *123 reaches
customer service when dialled within that network.

Of course it may well be useful or necessary to use one of the Q.763
attribute parameters in combination with the phone-context attributes.

Example 4:

     c= TN   RFCxxxx   321
     a=phone-context:X-acme.com  23

This might describe the telephone terminal which is at extension 321
of PBX number 23 within the acme.com private PBX network. It is expected
that such a description would be understandable by the acme.com PINT
server which receives the request.

Note that if the PINT server receiving the request is inside the
acme.com network, the same terminal might be addressable as follows:

     c= TN  RFCxxxx 7-23-321

(assuming that "7" is dialled in order to reach the private PBX network
from within acme.com)

Proprietary attribute "a=" lines, which by definition are not
interoperable, may be nonetheless useful when it is necessary to
transport some proprietary internal TN variables over the IP network.
We shall see an example of such usage in section 4.

3.4.5  The "strict" attribute

Unfortunately, according to the SIP specification, a PINT server is
allowed simply to ignore attribute parameters that it does not
understand. In order to force a client to fail a request if it does not
understand one of the PINT attributes, a client should use the "strict"
attribute (section 3.4.5), specified as follows:


where the attribute-list is a comma-separated list of attributes that
appear elsewhere in the session description.

In order to process the request successfully the PINT server must BOTH
understand the attribute AND ALSO fulfil the request implied by the
presence of the attribute, for each attribute appearing within the
attribute-list of the strict attribute.

If the server does not recognise the attribute listed, or cannot fulfil
the request implied by the attribute, the PINT server MUST fail the
request with (606 Not Acceptable), along with (a) suitable Warning:
line(s) explaining the problem.

The "strict" attribute may appear anywhere in the session description,
and any number of times, but it MUST appear before the use of the
attribute marked as strict.

Since the "strict" attribute is itself an attribute, the SIP spec allows
a server which does not understand the strict attribute to ignore it
also. In order to ensure that the PINT server will comply with the
"strict" attribute, a PINT clients should include a Require: header with
the tag "ietf.org.pint.strict" (section 3.5.4)

3.5     PINT profile of SIP 2.0

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

3.5.1   multi-part mime sending of data along with SIP request

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

3.5.2   Warning header

A PINT server MUST support the SIP "Warning:" header.
It is used to signal mismatches between PINT clients and servers from
different versions and with different supported features. (It is also
used to signal the status of an ongoing session that is referred to
within a retransmitted or STATUS request (see 3.5.3 below)).
For example, suppose a client sends a PINT request to a
server which understands PINT requests but which cannot provide the
particular Telephone Call Service requested. Perhaps the PINT
request is to send a jpeg picture to a particular TN fax machine, but
the server cannot retrieve and/or translate jpeg pictures from the
Internet into Fax transmissions. In such a case the server would fail
the request and must include a Warning such as the following:

        Warning:  4xx   pint.acme.com  Incompatible Format:  jpeg

SIP servers which do not understand the PINT extensions at all are
strongly encouraged to use the Warning: header to indicate that that
PINT extensions are not understood.

Note that the Warning: header may be used even if the
response is not an error. In the above example, the request might have
contained several alternative formats for the image to be faxed, and the
server can return the above Warning: even in a successful response, to
indicate that it did not understand the jpeg format, although it did
understand one of the other alternatives and is processing the request
using that alternative:

        Warning:  3xx pint.acme.com  Incompatible Format:  jpeg
        Warning:  502 pint.acme.com  Using tif http://server/pics/a123.tif

PINT defines a new family 5xx of Warning codes to be used to describe
the status of media sessions. PINT 1.0 defines five such codes:

500 Session scheduled for <HTTP-Date>

This indicates that the requested session has been successfully queued,
but it has not yet begun. The <HTTP-Date> is an optional part of the
Warning Text and indicates the time at which the session is scheduled to
begin. The HTTP-Date MUST be at the end of the Warning Text. A Server
MUST NOT end the Warning Text with a valid HTTP-Date UNLESS this
indicates the time at which the session will begin.

501 <HTTP-Date> Session Begun

This indicates that the requested session has begun successfully and is
proceeding normally. The <HTTP-Date> is an optional part of the Warning
Text and indicates the time at which the session began. A Server MUST
NOT begin the Warning Text with a valid HTTP-Date UNLESS this indicates
the time at which the session began.

502 Session in Progress

This indicates that the requested session has begun successfully, is
proceeding normally, and has not yet terminated.

503 <HTTP-Date> Session Completed

This indicates that the requested session completely normally. The
<HTTP-Date> is an optional part of the Warning Text and indicates the
time at which the session ended. A Server MUST NOT begin the Warning
Text with a valid HTTP-Date UNLESS this indicates the time at which the
session ended.

504 <Fax-Prog> Sent XXX Page of YYY

This warning can be included in the response to a fax session to
indicate that XXX out of a total of YYY pages have been sent. The
<Fax-Prog> parameter is an optional part of the Warning text and
indicates the numbers XXX and YYY in a machine readable, language-
independent manner. It is allowed to include only one of the two
numbers, in which case the period "." must be included before or after
the number. A Server MUST NOT begin the Warning Text with a <Fax-Prog>
parameter UNLESS this is to indicate the number of pages sent.

Fax-Prog  =   ( pages-sent "." total-pages | pages-sent "." | "." total-pages )
pages-sent =  *digit
total-pages = *digit

Examples are as follows:

Warning:  504 pint.acme.fr   2.5  2 pages sur 5 envoy'ees
Warning:  504 pint.acme.com  2.   2 pages sent so far

These warning codes can be used independently within a single response.
For example, a 501 and 503 warning can be returned in a single response
to indicate at which time the telephone session started and ended.
Warning code 504 can be returned with various combinations of the other
Warning codes.

The Warning headers can be sent within STATUS requests (section 3.5.3)
as well as within responses, if the original request contained a
Location: header to indicate the presence of a PINT server which can
receive STATUS requests.

3.5.3   The STATUS request

In PINT there is a requirement to propagate the status of the telephone
network sessions described within the SDP payload.
Warning headers are used for this purpose as well, as a Warning can be
merely informational and is not required to indicate an error. PINT
specifies a new method, STATUS, expressly for the purpose of requesting
an update on the server's view of the status of an outstanding request
or media session.

If a STATUS request were required to come from the same client that made
the original request, it would be possible to use client retransmission
instead of a new method. But it is very desirable to allow such
requests to come from other clients in the network. For example, one
might request that a fax be sent, and then have someone else (e.g. a
secretary) check if the fax actually got sent.

The STATUS request is submitted by a client to determine the status
of an outstanding request. The request payload must include an SDP
description which is identical to the original description. It SHOULD
NOT include whatever included Content was present in the original
request, and a server MUST ignore whatever content is included within a
STATUS request. The Call-ID is allowed to be different from that in the
original Call to allow STATUS requests from third parties.

The successful response to a STATUS request is the last cached response
that the Server returned to a Request that has the same global
session ID, along with one or more Warning: headers (see 3.3.5 below)
to indicate the status of the ongoing or completed telephone call
session.  If there are no previously returned response within the
server's cache, the server returns a "606 Not
Acceptable" response with a Warning: header as follows:

Warning: 4xx pint.acme.com Incompatible Session Description: Unknown Session ID.

Note that within SIP, it is allowed that a client include within the
request a "Location:" header to indicate the location of an associated
SIP server. This is usually used to enable a callee to hang up calls or
change the session description. A PINT client may use this facility to
indicate the Location of an associated PINT server which
is capable of receiving a STATUS request from the PINT server which
serviced the client's original request. If a PINT client includes a
Location: header within a request, the associated server indicated in
the Location header SHOULD support receiving the STATUS request from the
server to contain a Warning: line containing indication of
the status of the telephone call service. This allows a client to
receive ongoing status reports of a requested telephone call service
without having to poll the server.

Similarly, Warning: headers MAY be included within BYE requests to a
server which had been previously indicated within a Location: header
from a client (see 3.5.7 below).

Thus in PINT, Warning headers: MAY be included in requests as well as

It is allowed to send a STATUS request about a particular Telephone
Network Session after the Call has been destroyed via a
BYE message. If the Server no longer has a record of the session, it
returns "606 Not Acceptable", along with the appropriate Warning: header
indicating that the SDP session ID is no longer valid.

This allows a client to discover the status of a telephone call service
long after the service has completed.  For example, one might want to
check the next day that the fax was indeed sent the previous night at
1:00 AM. There is no minimum time that a server is required to
retain status of any particular session. Under normal SIP rules, as long
as no BYE has been sent, the PINT server is part of the PINT session,
and it should retain status of the call. A server can return an
Expires: header within any response to INVITE to indicate for how long
it will cache the result.

To summarise, the status Warning: lines can be included in any response,
and can also be included with a STATUS or BYE request in the special
case when these requests are being sent to a server which was
indicated in the "Location:" line within a previous PINT request.

[??? This is very close to Henning's and Jonathan's
NOTIFY request. We should decide on a single name. The main differences
are that STATUS can be client-->server or server-->client, and any old
client can issue a STATUS request to get an update on what is going on
with the session].

3.5.4   Require header for PINT

PINT clients use the Require: header to signal to the PINT server that a
certain PINT extension of SIP is required. (SIP ensures that a PINT
server which does not understand the Require:
org.ietf.pint.XXX  header will return a 420 Bad Extension response,
and list the unsupported option within an Unsupported: header) PINT 1.0
defines three strings that can go into the Require header:

org.ietf.pint.STATUS    -- the server can respond to STATUS requests
                           (section 3.5.3)

org.ietf.pint.Warning   -- the server can return the new PINT Warning
                           headers to indicate the status of requests
                           (section 3.5.2)

org.ietf.pint.strict    -- the PINT server (or the SDP parser associated
                           to it) understands the "strict" attribute
                           defined in (section 3.4.5)

Example: org.ietf.pint.STATUS,org.ietf.pint.Warning

[???? Should we define these tags a org.ietf.mmusic.sip tags??]

The specification of separate tags for each feature allows a client to
require individual PINT features independently. For example, a client
may wish to receive a Warning if the server cannot understand one of
several alternative image formats offered, but apart from this may have
no need for the STATUS request.

A client should only include a Require: header if it really wishes the
Server to fail the request in case the option is not supported. If the
client merely "desires" that the feature is available, but is willing to
accept service from a Server without the PINT feature, the client should
not include the Require: header. PINT servers MUST give Warnings for SIP
headers and elements of the session description that they do not

3.5.5  PINT URLS within PINT requests

URLs are used within the Request-URI and certain SIP headers (such as
To: and From:). The Request-URI within a SIP request refers to the
service or user that services the request. Normally the hostnames and
domain names that appear in the PINT URLs are the internal affair of
each individual PINT system. A client uses the appropriate SDP payload
to indicate the particular service it wishes to invoke; it is not
necessary to use a particular URL to identify the service, although
there are several advantages to doing so:

        a. if the SDP payload is encrypted it may not be possible for the
PINT system to use SDP information to route the request;
        b. doing so may speed up processing by helping to route requests
for a particular service to a particular PINT gateway;
        c. It enables multiple competing PINT gateways to REGISTER with
a single "broker" server (proxy or redirect) (see section 3.5.8)
        d. When the provider of the actual telephone network session is
separate from the provider of the PINT system, it may be important to
indicate the names of the two providers in a machine readable fashion,
for example, to enable equal access to other operator's services.

For these reasons, it is suggested that Request-URI for PINT services
should be of one of the following two forms:

<service>@<Pint Service Provider>
<service>%<Telephone Service Provider>@<Pint Service Provider>

<service> MAY be one of the following three strings:

R2T   (for Request To Call)
R2F   (for Request To Fax)
R2HC  (for Request To Hear Content)

The <Pint Service Provider> is an identifier (domain name or IP) of a
Pint Server.

The <Telephone Service Provider> is an identifier (domain name or IP) of
a server that can provide service inside the Telephone System.

It is customary for Telephone Network services to be identified by
a number. It is RECOMMENDED that service providers use this number
for the <service> parameter. PINT implementations SHOULD NOT use a
number as the <service> parameter unless that number is in fact the
identifier of some Telephone Network service within the domain of the
Telephone Service Provider. This and future versions of this PINT
specification SHALL NOT ever use a raw number as a service identifier.

Thus, for example:-

INVITE RTC@pint.pintservice.com SIP/2.0
INVITE R2F%telco.com@pint.pintservice.com SIP/2.0
INVITE R2HC%pbx23.mycom.com@pint.mycom.com SIP/2.0
INVITE 13@pint.telco.com SIP/2.0

Since such URLs are not strictly necessary for interoperability,
they are only recommendations, and not mandatory. See section 3.5.8
for some related considerations concerning registrations by
competing PINT systems to a single PINT proxy server acting as a
service broker.

3.5.6  Telephony Network Parameters within PINT URLs

Any legal SIP URL can appear as a PINT URL within the Request-URI or To:
header of a PINT request. But if the address is a telephone address, we
saw in section 3.4.4 we saw that it may be necessary to include
more information in order to correctly identify the remote telephone
terminal or service. PINT clients MAY include these attribute tags
within PINT URLs if they are necessary or useful to complement the
telephone number within the SIP URL. These attribute tags MUST be
included as URL parameters as defined in [ ] (i.e. in the semi-colon
separated manner).

The following is an example of a PINT URL which contains extra attribute tags:


As we noted in section 3.4.4, these extra attribute parameters SHOULD
NOT 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 particular, there is the SIP URL within the To: header,
and there is also the Request-URI. In most cases this provides
sufficient information for the telephone network.

The SDP attributes defined in 3 above SHOULD ONLY be used when they are
needed to supply necessary context to identify a telephone terminal.

Note that the terminal with this SIP URL is the same as the one whose
connection is defined by the following part of an SDP description:

        c= TN   RFCxxxx   +97252288088

3.5.7  BYE requests in PINT

The semantics of BYE requests within PINT requires some extra precision.

The BYE request [ ] is used within Internet Conferences to indicate that
the originating entity no longer wishes to be involved in the specified
call.  Normally, a BYE request is a request to terminate the call and
the media session. Thus according to the usual SIP semantics, if a PINT
client made a request have a telephone call made from telephone A to
telephone B, a BYE request from the client, if accepted, should result
in a termination of the phone call.

Note that 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
sent with a t= line indicating that the fax is to be sent tomorrow at
04:00AM, the requestor might wish to cancel the request before the
specified time. A second problem is that it may not be possible to
terminate the media session on the telephone system side. For example,
the fax call may be in progress when the BYE arrives, and perhaps it is
just not possible to cancel a fax in session. A third problem is that
the entire telephone-side service might be completed before the BYE is
received. In the above Request-To-Fax example, the BYE might be sent the
following morning, and the entire fax has been sent before the BYE was

In the case where the telephone network cannot terminate the media
session, or it has already completed when the BYE is received, the
server MUST include a Warning: header to indicate the status of the
telephone session. Even if the PINT server can cancel the Telephone
Network session, it SHOULD include a Warning: message indicating that
the Telephone Session has been cancelled.

Examples of such Warnings: are

Warning:  502  pint.acme.com  Telephone Call is still in session: Hang
up the Phone!!!

Warning:  504 pint.acme.com  3.6 Fax Service sent 3 of 6 pages

Warning:  503 pint.acme.com  04:03 EST 3-12-98 Fax Service Completed Successfully

If the client knows that it wishes to send STATUS requests at some point
in the future, it MUST NOT send a BYE request, since a BYE requests ends
the PINT association between the two parties, and the server might clear
all knowledge of the call upon receipt of a BYE. The PINT server may use
the Expires: header within the response to the BYE to indicate for how
long it will be able to answer future STATUS messages. The PINT server
MUST keep the response to the BYE cached at least as long as indicated
within a Expired: header, of course.

It is possible that some other client may send a STATUS request about a
particular PINT session even after the original PINT requestor sent a
BYE and ended the session. This allows a third party to check up on the
status of the transmission long after the PINT transaction is completed.
There is just no guarantee that the PINT server will retain status of
terminated PINT sessions (unless the PINT server indicated with an
Expires: header that it will retain status for a period of time).

If the original requesting PINT client included a Location: header in
its request, Then the original responding PINT server may send a BYE
request to this location, along with a Warning: header that includes the
final status of the telephone call service. But a PINT server should be
especially careful when sending such a BYE request.
It may be that a PINT request was sent from
a host, along with a Location header, but that the requesting host is
shutdown when the telephone service is executed, so the host is not
available at the Location: specified in the request to receive the PINT
server's BYE. Normally a server would send a STATUS request to the
server indicated within the Location: header, until such time as it is
certain that a BYE request can be received.

Note that the above scenarios make sense with ordinary Internet
multimedia sessions, not just with telephone network sessions.
The intent of these semantics for BYE requests between PINT
clients and servers is to be consistent with their meaning in
ordinary Internet Conferences.

[???What happens in an ordinary SIP audio call? is it REQUIRED that the
RTP stop transmitting when the BYE is sent and acknowledged?
Since the SIP spec speaks about BYE as meaning the requestor is about
to "hang-up the call", I assumed that this is correct.
Or maybe the RTP can go on forever, it's just that after the SIP BYE,
the RTP transmission is no longer within the context of a session.]

3.5.8 REGISTER requests within PINT

A PINT gateway is a SIP user agent server, and user agent services
use the REGISTER request to tell a proxy or redirect server that
it is available to "receive calls" -- i.e. to service requests.
In the case of PINT, the Server is registering the service
that is accessible via itself rather than a user registering presence at
a particular SIP Server.

There may be competing PINT servers which can offer the same
PINT service trying to register at a single PINT server. The PINT
server might act as a "broker" among the various PINT gateways which
can fulfil a request. A format for PINT URLs was specified in section
3.5.5 that enables independent PINT systems to REGISTER an offer to
provide the same service. The registrar can apply its own mechanisms and
policies to decide what to respond to INVITEs from
clients seeking service. (See section 6.3 for some possible deployment
options) There is no change between SIP and PINT REGISTER semantics or syntax.

Of course, the information in the PINT URLs within the REGISTER request
may not be sufficient to completely define the service that a gateway
can offer. The use of SIP and SDP within PINT REGISTER requests to
enable a gateway to specify general services it can offer is the subject
of future study.

[??? The obvious solution is to use wildcards (say *, !, etc.) and
comma separated multiple parameters within the
SDP descriptions in the REGISTER request to indicate phone numbers,
attributes, etc. which can be serviced from the registering PINT gateway.
Do we need to do this in PINT 1.0??? I fear we do???]

4.  Examples of PINT Requests and Responses

[???examples need to include some complete transactions, including responses,
not just requests!!]

4.1 A request to a call centre from an anonymous user to receive a phone
call about a Sale on Ironing Boards

C->S: INVITE  marketing@pint.mailorder.com  SIP/2.0
         Via: SIP/2.0/UDP
         From: anon-1827631872@chinet.net
         To: 1-800-IRON-YES
         Call-ID: 19971205T234505.56.78@chinet.net
         Subject: Sale on Ironing Boards
         Content-type: application/sdp
         Content-Length: ...

         o=- 53655765 2353687637 IN IP4
         i=Ironing Board Promotion
         c= TN  RFCxxxx  +1-201-406-4090
         m=audio 0  voice

In this example, the context which is required to interpret the To:
address as a telephone number is not given explicitly; it is implicitly
known to the marketing@pint.mailorder.com server. But the telephone of
the person who wishes to receive the call is explicitly identified as an
internationally significant E.164 number within the North American
numbering plan (because of the "+1" within the c= line).

4.2 A request from a non anonymous customer (John Jones) to receive a
phone call from a particular sales agent (Mary James) concerning the
defective ironing board that was purchased:

C->S: INVITE  marketing@pint.mailorder.com  SIP/2.0
         Via: SIP/2.0/UDP
         From: john.jones.3@chinet.net
         To: mary.james@mailorder.com
         Call-ID: 19971205T234505.56.79@chinet.net
         Subject: Defective Ironing Board - want refund
         Content-type: application/sdp
         Content-Length: ...

         o=- 53655765 2353687637 IN IP4
         c= GSTN  E163  +1-201-406-4090
         m=audio 0  voice

(The To: line might include the Mary James's phone number instead of a
email-like address.)

Note that such a telephone call service could be
implemented on the phone side with different details. For example, it
might be that first the agent's phone rings, and then the customer's
phone rings, or it might be that first the customer's phone rings and he
hears silly music until the agent comes on line. If necessary, such
service parameter details might be indicated in "a=" attribute lines
within the session description.  The specification of such attribute
lines for service consistency is beyond the scope of the PINT 1.0

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

C->S: INVITE  faxback@pint.mailorder.com  SIP/2.0
         Via: SIP/2.0/UDP
         From: john.jones.3@chinet.net
         To: 1-800-FAXBACK
         Call-ID: 19971205T234505.66.79@chinet.net
         Content-type: application/sdp
         Content-Length: ...

         o=- 53655768  2353687637 IN IP4
         c= TN  RFCxxxx  1-201-406-4091
         m=application 0 fax URI
         a=fmtp:URI http://localstore/Products/IroningBoards/2344.html

In this example, the fax to be sent is stored on some local
server (localstore), whose name may be only resolvable, or which may
only be reachable, from within the IP network on which the PINT server
sits. The phone number to be dialled is a "local phone number" as well.
The Q763-nature was added to further identify the number as a nationally
significant number. There is no "phone-context" attribute, so the
context (in this case, for which nation the number is "nationally
significant") must be supplied by the faxback@pint.mailorder.com PINT
server. If the server which receives does not understand the number, it
should fail the request with and include a "Network Address Not
Understood" warning. Note that no "strict" attribute was used here,
since it is very likely that the request can be serviced even by a
server which does not support the "strict" attribute.

4.4  A request from same user to have that same information read out
over the phone

C->S: INVITE  faxback@pint.mailorder.com  SIP/2.0
         Via: SIP/2.0/UDP
         From: john.jones.3@chinet.net
         To: 1-800-FAXBACK
         Call-ID: 19971205T234505.66.79@chinet.net
         Content-type: application/sdp
         Content-Length: ...

         o=- 53655768  2353687637 IN IP4
         c= TN  RFCxxxx  +1-201-406-4090
         m=application 0 voice URI
         a=fmtp:URI http://localstore/Products/IroningBoards/2344.html

4.5 A request to send a text page to a friend's pager. The text to be
paged out is included in the request.

C->S: INVITE  pages@pint.herpager.com  SIP/2.0
         Via: SIP/2.0/UDP
         From: scott.petrack@chinet.net
         To: text@pint.herpager.com
         Call-ID: 19974505.66.79@chinet.net
         Content-Type: multipart/mixed; boundary=--next

         Content-Type: application/sdp
         Content-Length: ...
         o=- 53655768  2353687637 IN IP4
         c= TN  RFCxxxx  +972-9-956-1867
         m=text 0 pager  plain
         a=fmtp:plain   2@53655768

         Content-Type: text/plain
         Content-ID: 2@53655768
         Content-Length: ...

         Hi Joe! Please call me asap at 555-1234.


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

C->S: INVITE  faxserver@pint.vocaltec.com  SIP/2.0
         Via: SIP/2.0/UDP
         From: scott.petrack@chinet.net
         To: faxserver@pint.vocaltec.com
         Call-ID: 19971205T234505.66.79@chinet.net
         Content-type: application/sdp
         Content-Length: ...

         o=- 53655768  2353687637 IN IP4
         c= TN  RFCxxxx  +972-9-956-1867
         m=image  0 fax  tif gif
         a=fmtp:tif  http://petrack/images/tif/picture1.tif
         a=fmtp:gif  http://petrack/images/gif/picture1.gif

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

4.7 A request to read out over the phone two pieces of content in
sequence. First some included text is read out by text-to-speech. Then
some text which is stored at some URI on the internet is read out.

         INVITE  switchboard@pint.acme.com  SIP/2.0
         Via: SIP/2.0/UDP
         From: scott.petrack@chinet.net
         To: voice_server@pint.acme.com
         Call-ID: 19974505.66.79@chinet.net
         Content-Type: multipart/mixed; boundary=next

         Content-Type: application/sdp
         Content-Length: ...
         o=- 53655768  2353687637 IN IP4
         c= TN  RFCxxxx  +1-201-406-4091
         m=text  0  voice  plain
         a=fmtp:plain   2@53655768
         m=text  0 voice plain
         a=fmtp:plain  http://www.mymachine.com/texts/mytext.doc

         Content-Type: text/plain
         Content-ID: 2@53655768
         Content-Length: ...

         Hello!! I am about to read out to you some text stored on my
Web Site. Let me know how it sounds over acme.com's new speech synthesis

4.8  Interaction with a Proprietary IVR-based FaxBack System

This example is intended to show how PINT systems can be "bolted on" to
existing Telephone System servers, such as "Intelligent Peripherals".
We consider an IVR-based (i.e. DTMF-driven) fax back system. Users
normally call up the system from a Fax machine, type in some DTMF digits
to identify the fax they want to receive, and then hit the "Receive"
button on their fax machines. The FaxBack system retrieves the fax from
storage and sends it out to the machine.

The faxes are stored on some "Intelligent Peripheral" inside the
Telephone Network. The server might be owned by some Telephone Service
Operator, which runs a FaxBack service for many business customers. The
faxes are identified by some customer code and the document code of the
fax. At present customers call in from a fax machine and send DTMF tones
to indicate the document code they wish to receive. Unfortunately the
documents are not identified by URIs (the server is not quite
"intelligent" enough to understand a URI...). It is desired to use
identifiers that are identical to the current customer code and document
code identifiers that customers now use when they dial in for the
faxback service. Here is one way to accomplish this, using a proprietary
"format" code to indicate the format of the fax to be sent.

C->S: INVITE  ivrfax@pint.operator.net  SIP/2.0
         Via: SIP/2.0/UDP
         From: scott.petrack@chinet.net
         To: faxes@pint.vocaltec.com
         Call-ID: 19971205T234505.66.79@chinet.net
         Content-type: application/sdp
         Content-Length: ...

         o=- 53655768  2353687637 IN IP4
         c= GSTN  E163  +972-9-956-1867
         m=application  0  fax  X-ivr.operator.net
         a=fmtp:X-ivr.operator.net   35.1234

The operator has defined X-ivr.operator.net  as a proprietary MIME sub-
type of MIME type application. This MIME sub-type is defined as a
concatenation of  the customer code, followed by a period, followed by
the DTMF code of the fax to be transported.  It is of course possible to
register the MIME sub-type with IANA, if there is a desire to have
interoperability of this form of identification among different vendors.

5. Security Considerations

        [??? There is some preliminary text, including some of the
"responsibility" stuff of Steve. will get to it after the deadline
I'm afraid]

        [??? It seems to me that SIP security mechanisms seem adequate
to the task, except that decent text needs to be written on such
topics as how to use those mechanisms to avoid fraud, trace malicious/
nuisance requests, etc. Some mention must be made as well of third party
authorisation, such as when a corporate PBX allows person A to make
long distance calls, but not person B]

        [??? The basic mechanisms are to be able to both digitally
sign and encrypt payloads. Certificates will be used. The certificates
contain the identity of the certificate authority, and this can be used
as a back end service to authorise the execution of the PINT service.

[???lwc -- Security considerations for REGISTER:
 For example, what's to stop any provider from registering as
"R2T%att.com"? It should be possible to require authentication
authentication of the request, it is indeed
 possible for someone to want to register themselves as "R2T%att.com"
or even to override all
other registrations for "R2T". (by attempting such a registration with a
"zero time" Expiry header).]

6. Deployment considerations and the Relationship PINT to IN

6.1 Web Front End to PINT Infrastructure

In practice, there are not (currently) many PINT Clients. It is likely
that some other protocol will be used to communicate a Requesting User's
requirements. Due to the high numbers of available Web Browsers and
servers it seems likely that some PINT systems will use HTML/HTTP as a
"front end".  In this scenario, HTTP will be used over a connection from
the Requesting User's Web Browser (WC) to an Intermediate Web Server
(WS). This will be closely associated with a PINT Client (using some
unspecified mechanism to transfer the data from the Web Server to the
PINT Client). The PINT Client will represent the Requesting User to the
PINT Server, and thus to the Executive System that carries out the
required action.


6.2 Redirects to Multiple Servers

It is quite possible that a given PINT Server is associated with an
Executive System (or systems) that can connect to the GSTN at different
places. If there is a chain of PINT Servers, then equally each of these
Servers may be able to route PINT requests to Executive Systems that
connect at specific points to the GSTN. The result of this is that there
may be more than one PINT Server or Executive System that can deal with
a given request. The mechanisms by which the choice on where to deliver
a request are outside the scope of this document.

However, there do seem to be two approaches. Either a Server that acts
as a proxy or redirect will select the appropriate server itself and
will cause the request to be sent on accordingly, or a list of possible
Locations will be returned to the Requesting User from which they can
select their choice.

In the SIP document, the implication is that, if a proxy cannot resolve
to a single unique match for a request destination, then a response
containing a list of the choices should be returned to the Requesting
User for selection. This is not too likely a scenario within the normal
use of SIP. However, within PINT, such ambiguity may be quite common; it
implies that there are a number of possible providers of a given service.

6.3 Competing PINT gateways REGISTERing to offer the same service

With PINT, the registration is not for an individual but instead for a
service that can be handled by a service provider. Thus, one can
envisage a registration by the PINT Server of the domain telcoA.com of
its ability to support the service R2T as "R2T@telcoA.com", sent to an
intermediary server that acts as registrar for the "broker.telcos.com"
domain from "R2T@pint.telcoA.com" as follows:

REGISTER sip:@broker.telcos.com SIP/2.0

This is the standard SIP registration service.

However, what happens if there are a number of different Service
Providers, all of whom support the "R2T" service? Suppose there is a
PINT system at domain "broker.com".
PINT clients requesting a Request to Talk service from broker.com might
be very willing to be redirected or proxied to any one of the various
service providers which had previously registered with the registrar.
And PINT servers might be interested in
providing service for requests that did not specify the service provider
explicitly, as well as those requests that were directed "at them".

To enable such service, PINT servers would REGISTER at the broker PINT
server registrations of the form:

REGISTER sip:host@broker.com SIP/2.0

[??? if sip:R2T  is a valid URL, I would rather that this appeared in
the To: line]

When several such REGISTER messages appear at the registrar, each
differing only in the URL in the From: line, the registrar has many
possibilities, e.g.:

(i) it overwrites the prior registration for "R2T@broker.telcos.com"
when the next comes in;
(ii) it rejects the subsequent registration for "R2T@broker.telcos.com";
(iii) it maintains all such registrations.
In this last case, on receiving an Invitation for the "general" service,
        (iii.1) it passes on the invitation to all registered service
        providers, returning a collated response with all acceptances,
        using multiple Location: headers,
        (iii.2) it silently selects one of the registrations (using, for
        example, a "round robin" approach) and routes the Invitation and
        response onwards without further comment.
(iv) may choose to not allow registrations for the "general"
service, rejecting all such REGISTER requests.

6.4 Relation to Intelligent Network and Public Network Standards

The PINT profile for SIP and SDP is used to pass requests to Executive
Systems, where the requests can be serviced. In the particular case when
the Executive Systems are attached to Intelligent Network (I.N.) systems
or other Public Network systems operation with these requires
development work on protocols and functions to be carried
within the GSTN (specifically within the I.N. systems). There are
several groups responsible for developing standards on the operation
(within the GSTN) of associated I.N. functions and protocols. PINT
systems and GSTN systems operating as specified by other groups may well
be part of the same overall system used to provide services, so it is
useful to provide an overview of the relevant Telecommunications

6.4.1 ITU-T
The International Telecommunications Union - Telecommunications
standardisation sector (usually known as ITU-T) has a significant group
working on the development of the Intelligent Network recommendations. In
particular, Study Group 11 has responsibility for this task, and within
it work is being carried out into the development of a new Distributed
Functional Plane architecture (by SG11.4), and into new extensions to
Intelligent Network Application Part (INAP) protocol to be used between
units in an Intelligent Network configuration (SG11.22).

Their current plan is for Internet requests to be supported in the
Recommendations that are part of the "Capability Set 4" (IN-CS4) series.
Work on IN-CS4 is intended to be complete by December 1999, and it seems
likely that the profile proposed in this document can be used to deliver
PINT requests into such a system. Assuming that work on the Internet
Protocols and this profile will be complete before the CS4 development
in the ITU-T, it can be fed into the work of those ITU-T groups, so
helping compatibility. Note that this is an ITU-T problem, not one for
the Internet community, but it is important to be aware of the
standardisation context and how they may be used.

6.4.2 ETSI
ETSI (European Telecommunications Standards Institute) is the body with
responsibility (within Europe) for taking ITU-T specifications and
producing profiles that allow a high degree of interoperation of
Telecommunications Networks. They have produced profiles for IN-CS1 and
IN-CS2 INAP protocols (called "ETSI Core INAP"). The ETSI NA6 group has
started working on Next-generation I.N. systems & extensions to Core-
INAP for Internet support, and has produced contributions to the ITU-T
work to ensure alignment of their efforts.

6.4.3 ANSI
The Telecommunications Standards body with particular interest in North
America is ANSI (American National Standards Institute), and, within
that body, the T1S1 group is concerned with Intelligent Network systems.
On the "Support for Internet" question, there has been a trend for ideas
from this body to be introduced into the appropriate ITU-T study groups.
Thus, although there does not appear to be a separate development being
carried out within ANSI, this is simply due to the fact that the ideas
are passed directly on to ITU-T and influence the ITU-T documents in
that way.

6.4.4 Other Standards
There are other groups working on related areas. For example, there are
proposals within the IETF for development of Protocol Mapping gateways
between the IP networks and networks carrying Signalling System Number 7
(SS#7) messages, as are commonly used within Telecommunications
Networks. In principle, protocol mapping can be to deliver a service
request as well. This would appear to perform a similar task to that
presented with the PINT profile.

However, the degree of coupling between the states
within the SS#7 network and that within the Internet-based Requestors is
much greater when using direct protocol mapping. The end result may be
the same, but the means by which that result is achieved differs. The
thrust of the PINT profile is to deliver the "intent" of a customer's
request towards an Executive System on the GSTN, whilst the other
approach ties the lower level semantics (or even the syntax) of the
request to that used on the GSTN.

PINT fits telephone-network-based multimedia conference set-up into the
larger context of general multimedia conference set-up, rather than into
the context of telephone network protocols.

PINT is designed to deliver requests without the use of direct protocol
mapping to Intelligent Network Application Part (INAP)
messages. It could equally be used where the Executive System was not
associated with an SS#7 network. This allows implementations to be
developed relatively easily; an SS#7 network is not required to
implement or deploy PINT.  Also, it makes PINT development and
standardisation orthogonal to any Intelligent Network standardisation;
development of protocol mappings between IP networks and GSTN
Telecommunications Signalling Networks are intimately dependent on the
GSTN signalling standards.

6.5  Relation between PINT Milestone services and ITU-T Q.1231

[[[??? Q.1231 is a *draft* document. If we include this section,
it must say that details may change]

There are services descriptions made in the ITU-T which are similar to
the PINT milestone services, and the relationship between the two
descriptions is discussed here. After this, a description is given of
the parameters that will be transferred from a Requestor to the eventual
PINT Server that is associated with an Executive System that performs
the ITU-T service. Finally, an example of the way in which these
parameters might be included in messages fitting the PINT profiles for
SIP and SDP is given.

6.5.1  PINT Services

The ITU-T Intelligent Network Outline Service Definitions for Capability
Set 3 (the next development phase in the Intelligent Network) are
included in the ITU-T draft document Q.1231 [11]. This document includes
descriptions of four services initially identified by the PINT Working
Group and that are taken as "benchmarks" for the PINT profiles of SIP
and SDP. These services are: Click-to-Dial-Back, Click-to-Fax, Click-to-
Fax-Back and (Internet-Initiated) Voice-Access-to-Content.

Within the ITU-T definitions below, note that the word "click" should
not be taken literally. It is rather used to point out that initiation
of the related services takes place on the Internet, where point and
click are the most prevalent user actions.  In other words, a service
request could originate from any type of IP-based platforms. There is no
implication that these services must be implemented by a device within
the PSTN or the Internet running a Web server.

The common denominator of the PINT services is that they combine the
Internet and PSTN services in such a way that the Internet is used for
non-voice interactions, while the voice (and fax) are carried entirely
over the PSTN.  Click-to-Dial-Back (CTDBC)

With this service, a user requests (through an IP host) that the PSTN
call be established between another party and himself or herself. An
important pre-requisite for using this service is that the user has
simultaneous access to both the PSTN and Internet.  Click-to-Fax (CLTFA)

With this service, a user at an IP host requests that a fax be sent to a
particular fax number. In particular this service is especially meaningful when the fax is to be sent to someone who has only a fax
machine (but no access to the Internet).  Click-to-Fax-Back (CLTFB)

With this service, a user at an IP host can request that a fax be sent
to him or her.  (Internet-Initiated) Voice-Access-to-Content (VATCI)

With this service, a user at an IP host requests that certain
information on the Internet be accessed (and delivered) in an audio form
over the PSTN, using the telephone as an informational appliance.  PINT vs. ITU-T service descriptions

Within this profile, the service definitions have been specified in a
more precise way, whilst still reflecting the services as described in
the Draft Q.1231 document. Thus, Click-to-Dial-Back as described in the
ITU-T document is a special case of the more general two-party Request-
to-Talk service mentioned earlier in this profile, the Click-to-Fax and
Click-to-Fax-Back are both cases of a Request-to-Fax, and the
(Internet-Initiated) Voice-Access-To-Content ITU-T definition is called

Within the ITU-T service descriptions there is an important difference
between the Click-to-Fax-Back and Click-to-Fax service. In the "Fax"
case the source document is sent
from "the Internet" towards the PSTN. With the "Fax-Back" case, the
source document is stored within "the PSTN" (and the Requesting User is
implied to be the same as the destination party for the resulting
service PSTN call).

Also, the ITU-T Click-to-Dial-Back description given above implies that
the Requesting User (as defined earlier in this document) is one of the
parties to the resulting service PSTN call. We have chosen to use a more
general description for the Request-to-Talk definition shown in section
2 of this profile; the Click-to-Dial-Back description is a pure subset
of the Request-to-Talk service, in which the Requesting User role is
shared by the same person as one of the parties to the PSTN call.

6.5.2  Parameters needed for PINT Services

This section describes how parameters specified by ITU-T Q.1231 can be
carried within PINT requests.  Service Identifier

When a Requesting User asks for a service to be performed, they will, of
course, has to specify which service in some way. This can be done
within the URLs within the To: header and the Request-URI (see )  A and B parties

With the "Request-to-Talk" service, they will also need to specify the A
and B parties they want to be engaged in the resulting service call. The
A party could identify, for example, the Call Centre from which they
want a call back, whilst the B party is their telephone number (i.e. who
the Call Centre agent is to call).

With the "Request-to-Fax-Back" service, they will also have specify two
parties. As before, the B party is the telephone number of the fax
machine to which they want a fax to be sent. However, within Q.1231 the
A 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 a PSTN user dialling a particular telephone number and then
entering the document number to be returned using "touch tone" digits.
The telephone number they dial is that of the document store or A party,
with the "touch tone" digits selecting the document within that store.

The "Request-to-Fax" and "Request-to-Hear-Content" services require the
B party to be specified (respectively the telephone number of the
destination Fax machine or the telephone to which spoken content is to
be delivered), but the A party is a Telephone Network based resource
(either a Fax or speech transcoder/sender), and is implicit; the
Requesting User does not (and cannot) specify it.  Other Service Parameters

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 convenient to assert that the resulting service call will
carry voice, as the Executive System within the destination GSTN may be
able to check that assertion against the A and B party numbers specified
and may treat the call differently.

The "Request-to-Fax-Back" service needs to specify the Document Store
number and the Fax machine number to which the information is to be
delivered. It is convenient to assert that the call will carry Fax data,
as the destination Executive System may be able to check that assertion
against the document store number and that of the destination Fax

In addition, the document number may also need to be sent. This
parameter is an opaque reference that is carried through the Internet
but has significance only within the GSTN. The document store number and
document number together uniquely specify the actual content to be

With the "Request-to-Fax" and "Request-to-Hear-Content" services, the
source information to be transcoded is held on the Internet. That means
either that this information is carried along with the request itself,
or that a reference to the source of this information is given. In
addition, it is convenient to assert that the service call will carry
fax or voice, and, where possible, to specify the format for the source
information.  Service Parameter Summary

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

Service     ServiceID   AParty    BParty   CallFmt    Source    SourceFmt
-------     ---------   ------    ------   -------    ------    -------
  R2T           x         x         x       voice       -          -
  R2F           x         -         x        fax      URI/IL    ISF/ILSF
  R2FB          x         x         x        fax        OR         -
  R2HC          x         -         x       voice     URI/IL    ISF/ILSF

In this table, "x" means that the parameter is required, whilst "-"
means that the parameter is not required.

The Call Format parameter values "voice" or "fax" indicate the kind of
service call that results.

The Source "URI/IL" implies either that the data is either an Internet
source reference (a Universal Resource Identifier, or URI) or is carried
"in-line" with the message. The Source indicator "OR" means that that
the value passed is an Opaque Reference that should be carried along
with the rest of the message but is to be interpreted only within the
destination (GSTN) context. As an alternative, it could be given as a
"local" reference with the "file" style, or even using a partial
reference with the "http" style. However, the way in which such a
reference is interpreted is a matter for the receiving PINT Server and
Executive System; it remains, in effect, an opaque reference.

The Source Format value "ISF/ILSF" means that the format of the source
is specified either in terms of the URI or that it is carried "in-line".
Note that, for some data, the format either can be detected by
inspection or, if all else fails, can be assumed from the URI (for
example, by assuming that the file extension part of a URL indicates the
data type). For an opaque reference, the Source Format is not available
on the Internet, and so is not given.

6.5.3  Parameter Mapping to PINT Profile

This section describes the way in which the parameters needed to specify
a Q.1231 request fully might be carried within a PINT profile message.
There are other choices, and these are not precluded. However, in
order to ensure that the Requesting User receives the service that they
expect, it is necessary to have some shared understanding of the
parameters passed and the behaviour expected of the PINT Server and its
attendant Executive System.

The Service Identifier can be sent as the userinfo element of the
Request-URI. Thus, the first line of a PINT Invitation would be of the
form: INVITE <serviceID>@<pint-server>.<domain>  SIP/2.0

The A Party for the Request-To-Talk and Request-To-Fax-Back service can
be held in the "To:" header field. In this case the "To:" header value
will be different from the Request-URI. In the services where the A party
is not specified, the "To:" field is free to repeat the value held
in the Request-URI. This is the case for "Request-to-Fax" and "Request-
to-Hear-Content" services.

The B party is needed in all these milestone services, and can be held
in the enclosed SDP sub-part, as the value of the "c=" field.

The call format parameter can be held as part of the "m=" field value.
It maps to the "transport protocol" element as described in section
3.4.2 of this document.

The source format specifier is held in the "m=", as a type and optional
sub-type. The latter is required for all services except "Request-to-
Talk". As shown earlier, the source format and source are not always
required when generating requests for services. However, the inclusion
in all requests of a source format specifier can make parsing the
request simpler and allows for other services to be specified in the
future, and so values are always given. The source format parameter is
covered in section 3.4.2 as the "media type" element.

The source itself is identified by an "a=fmtp:" field value, where
needed. With the exception of the "Request-to-Talk" service, all
invitations will include such a field. From the perspective of the SDP
profile, it can be considered as qualifying the media sub-type, as if to
say, for example, "when I say jpeg, what I mean is the following".

In summary, the parameters needed by the different services are carried
in fields as shown in the following table:

Service   Svc Param    PINT/SIP or SDP field used      Example value
-------   ---------    --------------------------      -------------
          ServiceID:   <SIP Request-URI userinfo>      R2T
          BParty:      <SIP To: field>                 sip:123@p.com
          AParty:      <SDP c= field>                  TN RFCxxxx 4567
          CallFormat:  <SDP transport protocol
                            sub-field of m= field>     voice
          SourceFmt:   <SDP media type sub-field
                            of m= field>               audio
                       (--- No media sub-type
                            sub-field value used)      ---
          Source:      (--- No source specified)       ---

          ServiceID:   <SIP Request-URI userinfo>      R2F
          BParty:      (---                   )     sip:R2F@pint.xxx.net
          AParty:      <SDP c= field>               TN RFCxxx +441213553
          CallFormat:  <SDP transport protocol
                            sub-field of m= field>     fax
          SourceFmt:   <SDP media type sub-field
                            of m= field>               image
                       <SDP media sub-type sub-field
                            of m= field>               jpeg
          Source:      <SDP a=fmtp: field qualifying
                            preceding m= field>        a=fmtp:jpeg <URI>

          ServiceID:   <SIP Request-URI userinfo>      R2FB
          BParty:      <SIP To: field>              sip:1-730-1234@p.com
          AParty:      <SDP c= field>               TN RFCxxx +441213553
          CallFormat:  <SDP transport protocol
                            sub-field of m= field>     fax
          SourceFmt:   <SDP media type sub-field
                            of m= field>               image
                       <SDP media sub-type sub-field
                            of m= field>               X-OR
          Source:      <SDP a=fmtp: field qualifying
                            preceding m= field>        a=fmtp:X-OR 1234

          ServiceID:   <SIP Request-URI userinfo>      R2HC
          BParty:      (--- SIP To: field not used) sip:R2HC@pint.ita.il
          AParty:      <SDP c= field>               TN RFCxxx +441213554
          CallFormat:  <SDP transport protocol
                            sub-field of m= field>     voice
          SourceFmt:   <SDP media type sub-field
                            of m= field>               text
                       <SDP media sub-type sub-field
                            of m= field>               html
          Source:      <SDP a=fmtp: field qualifying
                            preceding m= field>        a=fmtp:html <URI>

7.  Open Issues

[All open issues are marked in the text above within square brackets and
three question marks ???]

[[??? lwc - Other Points to consider:
(i) Who makes the decision on the PINT Server or Executive System that is
offered any Invitation (where there is a possible choice)?
(ii) What's the ->policy<- for that choice?,
  i)   is it required to be auditable (i.e. one can prove that this policy
has been carried out)?
  ii)  is it required to be "fair" (and, if so, who decides what's "fair")?
  iii) Who or what sets policy for the decision?]]]

8. References

9. The authors wish to thank the members of the PINT working group for
comments that were helpful to the preparation of this specification. In
particular, Ian Elz's remarks about internal telephone network
parameters was instrumental in the specification of section 3.5.6.

10. Author's Addresses:

Scott Petrack
VocalTec Communications Ltd.
1 Maskit Street
46733 Israel

Lawrence Conroy
Roke Manor Research