As per Relevance of the word telephone, we have this rfc below:
Network Working Group S.
Request for Comments: 2848
Category: Standards Track L.
Siemens Roke Manor
June 2000
The PINT Service Protocol
Extensions to SIP and SDP for IP Access to Telephone Call
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This document contains the specification of the PINT Service
1.0, which defines a protocol for invoking certain telephone
from an IP network. These services include placing basic calls
sending and receiving faxes, and receiving content over
telephone. The protocol is specified as a set of enhancements
additions to the SIP 2.0 and SDP protocols
Table of
1. Introduction ................................................. 4
1.1 Glossary .................................................... 6
2. PINT Milestone Services ...................................... 6
2.1 Request to Call ............................................. 7
2.2 Request to Fax Content ...................................... 7
2.3 Request to Speak/Send/Play Content .......................... 7
2.4 Relation between PINT milestone services and
telephone services .......................................... 7
3. PINT Functional and Protocol Architecture .................... 8
3.1. PINT Functional Architecture ............................... 8
3.2. PINT Protocol Architecture ................................. 9
3.2.1. SDP operation in PINT .................................... 10
3.2.2. SIP Operation in PINT .................................... 11
3.3. REQUIRED and OPTIONAL elements for PINT compliance ......... 11
3.4. PINT Extensions to SDP 2.0 ................................. 12
Petrack & Conroy Standards Track [Page 1]
RFC 2848 The PINT Service Protocol June 2000
3.4.1. Network Type "TN" and Address Type "RFC2543" ............. 12
3.4.2. Support for Data Objects within PINT ..................... 13
3.4.2.1. Use of fmtp attributes in PINT requests ................ 15
3.4.2.2. Support for Remote Data Object References in PINT ...... 16
3.4.2.3. Support for GSTN-based Data Objects in PINT ............ 17
3.4.2.4. Session Description support for included Data Objects .. 18
3.4.3. Attribute Tags to pass information into the
Network .................................................. 19
3.4.3.1. The phone-context attribute ............................ 20
3.4.3.2. Presentation Restriction attribute ..................... 22
3.4.3.3. ITU-T CalledPartyAddress attributes parameters ......... 23
3.4.4. The "require" attribute .................................. 24
3.5. PINT Extensions to SIP 2.0 ................................. 25
3.5.1. Multi-part MIME (sending data along with SIP request) .... 25
3.5.2. Warning header ........................................... 27
3.5.3. Mechanism to register interest in the disposition of a
service, and to receive indications on that disposition .. 27
3.5.3.1. Opening a monitoring session with a SUBSCRIBE request .. 28
3.5.3.2. Sending Status Indications with a NOTIFY request ....... 30
3.5.3.3. Closing a monitoring session with an UNSUBSCRIBE request 30
3.5.3.4. Timing of SUBSCRIBE requests ........................... 31
3.5.4. The "Require:" header for PINT ........................... 32
3.5.5. PINT URLs within PINT requests ........................... 32
3.5.5.1. PINT URLS within Request-URIs .......................... 33
3.5.6. Telephony Network Parameters within PINT URLs ............ 33
3.5.7. REGISTER requests within PINT ............................ 34
3.5.8. BYE Requests in PINT ..................................... 35
4. Examples of PINT Requests and Responses ...................... 37
4.1. A request to a call center from an anonymous user to
a phone call ............................................... 37
4.2. A request from a non anonymous customer (John Jones)
receive a phone call from a particular sales
(Mary James) ............................................... 37
4.3. A request to get a fax back ................................ 38
4.4. A request to have information read out over the phone ...... 39
4.5. A request to send an included text page to a friend's pager. 39
4.6. A request to send an image as a fax to phone
+972-9-956-1867 ............................................ 40
4.7. A request to read out over the phone two pieces of
in sequence ................................................ 41
4.8. Request for the prices for ISDN to be sent to my
machine .................................................... 42
4.9. Request for a callback ..................................... 42
4.10.Sending a set of information in response to an enquiry ..... 43
4.11.Sportsline "headlines" message sent to your phone/fax/pager 44
4.12.Automatically giving someone a fax copy of your phone bill . 45
5. Security Considerations ...................................... 46
5.1. Basic Principles for PINT Use ............................. 46
Petrack & Conroy Standards Track [Page 2]
RFC 2848 The PINT Service Protocol June 2000
5.1.1. Responsibility for service requests ..................... 46
5.1.2. Authority to make requests .............................. 47
5.1.3. Privacy ................................................. 47
5.1.4. Privacy Implications of SUBSCRIBE/NOTIFY ................ 48
5.2. Registration Procedures ................................... 49
5.3. Security mechanisms and implications on PINT service ...... 50
5.4. Summary of Security Implications .......................... 52
6. Deployment considerations and the Relationship PINT to I.N
(Informative) ................................................ 54
6.1. Web Front End to PINT Infrastructure ....................... 54
6.2. Redirects to Multiple Gateways ............................. 54
6.3. Competing PINT Gateways REGISTERing to offer the
service .................................................... 55
6.4. Limitations on Available Information and Request Timing
SUBSCRIBE .................................................. 56
6.5. Parameters needed for invoking traditional GSTN
within PINT................................................. 58
6.5.1. Service Identifier ....................................... 58
6.5.2. A and B parties .......................................... 58
6.5.3. Other Service Parameters ................................. 59
6.5.4. Service Parameter Summary ................................ 59
6.6. Parameter Mapping to PINT Extensions........................ 60
7. References ................................................... 62
8. Acknowledgements ............................................. 64
Appendix A: Collected ABNF for PINT Extensions .................. 65
Appendix B: IANA Considerations ................................. 69
Authors' Addresses .............................................. 72
Full Copyright Statement ........................................ 73
Petrack & Conroy Standards Track [Page 3]
RFC 2848 The PINT Service Protocol June 2000
1.
The desire to invoke certain telephone call services from
Internet has been identified by many different groups (users,
and private network operators, call center service providers
equipment vendors, see [7]). The generic scenario is as follows (
the invocation is successful):
1. an IP host sends a request to a server on an IP network
2. the server relays the request into a telephone network
3. the telephone network performs the requested call service
As examples, consider a user who wishes to have a callback placed
his/her telephone. It may be that a customer wants someone in
support department of some business to call them back. Similarly,
user may want to hear some announcement of a weather warning
from a remote automatic weather service in the event of a storm
We use the term "PSTN/Internet Interworking (PINT) Service" to
such a complete transaction, starting with the sending of a
from an IP client and including the telephone call itself.
services are distinguished by the fact that they always involve
separate networks
an IP network to request the placement of a call, and the
Switched Telephone Network (GSTN) to execute the actual call.
is understood that Intelligent Network systems, private PBXs
cellular phone networks, and the ISDN can all be used to
PINT services. Also, the request for service might come
within a private IP network that is disconnected from the
Internet
The requirements for the PINT protocol were deliberately
to providing the ability to invoke a small number of fixed
call services. These "Milestone PINT services" are specified
section 2. Great care has been taken, however, to develop a
that is aligned with other Internet protocols where possible, so
future extensions to PINT could develop along with
conferencing
Within the Internet conference architecture, establishing media
is done via a combination of protocols. SIP [1] is used to
the association between the participants within the call (
association between participants within the call is called
"session"), and SDP [2] is used to describe the media to be
within the session. The PINT protocol uses these two
together, providing some extensions and enhancements to enable
clients and servers to become PINT clients and servers
Petrack & Conroy Standards Track [Page 4]
RFC 2848 The PINT Service Protocol June 2000
A PINT user who wishes to invoke a service within the
network uses SIP to invite a remote PINT server into a session.
invitation contains an SDP description of the media session that
user would like to take place. This might be a "sending a
session" or a "telephone call session", for example. In a
service execution session the media is transported over the
system, while in a SIP session the media is normally transported
an internet
When used to invoke a PINT service, SIP establishes an
between a requesting PINT client and the PINT server that
responsible for invoking the service within the telephone network
These two entities are not the same entities as the telephone
entities involved in the telephone network service. The SIP
carry within their SDP payloads a description of the
network media session
Note that the fact that a PINT server accepts an invitation and
session is established is no guarantee that the media will
successfully transported. (This is analogous to the fact that if
SIP invitation is accepted successfully, this is no guarantee
a subsequent failure of audio hardware).
The particular requirements of PINT users lead to some new messages
When a PINT server agrees to send a fax to telephone B, it may
that the fax transmission fails after part of the fax is sent
Therefore, the PINT client may wish to receive information about
status of the actual telephone call session that was invoked as
result of the established PINT session. Three new requests
SUBSCRIBE, UNSUBSCRIBE, and NOTIFY, are added here to vanilla SIP
allow this
The enhancements and additions specified here are not intended
alter the behaviour of baseline SIP or SDP in any way. The purpose
PINT extensions is to extend the usual SIP/SDP services to
telephone world. Apart from integrating well into existing
and architectures, and the advantages of reuse, this means that
protocol specified here can handle a rather wider class of
services than just the Milestone services
The rest of this document is organised as follows: Section 2
describes the PINT Milestone services; section 3 specifies the
functional and protocol architecture; section 4 gives examples of
PINT 1.0 extensions of SIP and SDP; section 5 contains some
considerations for PINT. The final section contains descriptions
how the PINT protocol may be used to provide service over the GSTN
Petrack & Conroy Standards Track [Page 5]
RFC 2848 The PINT Service Protocol June 2000
For a summary of the extensions to SIP and SDP specified in
document, Section 3.2 gives an combined list, plus one
describing the extensions to SIP and SDP respectively
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in RFC 2119. In addition
the construct "MUST .... OR ...." implies that it is an
requirement of this specification to implement one of the
possibilities stated (represented by dots in the above phrase).
implementation MUST be able to interoperate with
implementation that chooses either of the two possibilities
1.1
Requestor - An Internet host from which a request for
PINT Service - A service invoked within a phone system in response
a request received from an PINT client
PINT Client - An Internet host that sends requests for invocation
a PINT Service, in accordance with this document
PINT Gateway - An Internet host that accepts requests for
Service and dispatches them onwards towards a telephone network
Executive System - A system that interfaces to a PINT Server and to
telephone network that executes a PINT service. It need not
directly associated with the Internet, and is represented by the
Server in transactions with Internet entities
Requesting User - The initiator of a request for service. This
may be distinct from that of the "party" to any telephone
call that results from the request
(Service Call) Party - A person who is involved in a
network call that results from the execution of a PINT
request, or a telephone network-based resource that is involved (
as an automatic Fax Sender or a Text-to-Speech Unit).
2. PINT Milestone
The original motivation for defining this protocol was the desire
invoke the following three telephone network services from within
IP network
Petrack & Conroy Standards Track [Page 6]
RFC 2848 The PINT Service Protocol June 2000
2.1 Request to
A request is sent from an IP host that causes a phone call to
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
machine B. The request MAY contain a pointer to the fax data (
could reside in the IP network or in the Telephone Network), OR
fax data itself. The content of the fax MAY be text OR some
more general image data. The details of the fax transmission are
accessible to the IP network, but remain entirely within
telephone network
Note that this service does not relate to "Fax over IP": the
network is only used to send the request that a certain fax be sent
Of course, it is possible that the resulting telephone network
call happens to use a real-time IP fax solution, but this
completely transparent to the PINT transaction
2.3 Request to Speak/Send/Play
A request is sent from an IP host that causes a phone call to be
to user A, and for some sort of content to be spoken out. The
MUST EITHER contain a URL pointing to the content, OR include
content itself. The content MAY be text OR some other more
application data. The details of the content transmission are
accessible to the IP network, but remain entirely within
telephone network. This service could equally be called "Request
Hear Content"; the user's goal is to hear the content spoken to them
The mechanism by which the request is formulated is outside the
of this document; however, an example might be that a Web page has
button that when pressed causes a PINT request to be passed to
PSTN, resulting in the content of the page (or other details)
spoken to the person
2.4 Relation between PINT milestone services and traditional
There are many different versions and variations of each
call service invoked by a PINT request. Consider as an example
happens when a user requests to call 1-800-2255-287 via the
Request-to-Call service
There may be thousands of agents in the call center, and there may
any number of sophisticated algorithms and pieces of equipment
are used to decide exactly which agent will return the call. And
Petrack & Conroy Standards Track [Page 7]
RFC 2848 The PINT Service Protocol June 2000
this choice is made, there may be many different ways to set up
call: the agent's phone might ring first, and only then the
user will be called; or perhaps the user might be called first,
hear some horrible music or pre-recorded message while the agent
located
Similarly, when a PINT request causes a fax to be sent, there
hundreds of fax protocol details to be negotiated, as well
transmission details within the telephone networks used
PINT requests do not specify too precisely the exact telephone-
service. Operational details of individual events within
telephone network that executes the request are outside the scope
PINT. This does not preclude certain high-level details of
telephone network session from being expressed within a PINT request
For example, it is possible to use the SDP "lang" attribute
express a language preference for the Request-to-Hear-
Service. If a particular PINT system wishes to allow requests
contain details of the telephone-network-side service, it uses
SDP attribute mechanism (see section 3.4.2).
3. PINT Functional and Protocol
3.1. PINT Functional
Familiarity is assumed with SIP 2.0 [1] and with SDP [2].
PINT clients and servers are SIP clients and servers. SIP is used
carry the request over the IP network to the correct PINT server in
secure and reliable manner, and SDP is used to describe the
network session that is to be invoked or whose status is to
returned
A PINT system uses SIP proxy servers and redirect servers for
usual purpose, but at some point there must be a PINT server with
means to relay received requests into a telephone system and
receive acknowledgement of these relayed requests. A PINT server
this capability is called a "PINT gateway". A PINT gateway appears
a SIP system as a User Agent Server. Notice that a PINT
appears to the PINT infrastructure as if it represents a "user",
while in fact it really represents an entire telephone
infrastructure that can provide a set of telephone network services
Petrack & Conroy Standards Track [Page 8]
RFC 2848 The PINT Service Protocol June 2000
So the PINT system might appear to an individual PINT client
follows
/\/\/\/\/\/\/\ /\/\/\/\/\/\/\/\
___________ \ __/___ ___\_ \
| PINT | PINT \ PINT | PINT | |Exec| Telephone /
| client |<-------------->| server |gatewy|=====|Syst| Network \
|_________| protocol / cloud |______| |____| Cloud /
\ \ / \
/\/\/\/\/\/\/\ \/\/\/\/\/\/\/\/
Figure 1: PINT Functional
The system of PINT servers is represented as a cloud to
that a single PINT request might pass through a series of
servers, proxy servers, and redirect servers, before finally
the correct PINT gateway that can actually process the request
passing it to the Telephone Network Cloud
The PINT gateway might have a true telephone network interface, or
might be connected via some other protocol or API to an "
System" that is capable of invoking services within the
cloud
As an example, within an I.N. (Intelligent Network) system, the
gateway might appear to realise the Service Control Gateway Function
In an office environment, it might be a server adjunct to the
PBX, connected to both the office LAN and the office PBX
The Executive System that lies beyond the PINT gateway is outside
scope of PINT
3.2. PINT Protocol
This section explains how SIP and SDP work in combination to
the information necessary to invoke telephone network sessions
The following list summarises the extension features used in
1.0. Following on from this the features are considered
for SDP and then for SIP
1) Telephony URLs in SDP Contact
2) Refinement of SIP/SDP Telephony
* Inclusion of private dialling
3) Specification of Telephone Service Provider (TSP) and/or phone
context URL-
4) Data Objects as session
Petrack & Conroy Standards Track [Page 9]
RFC 2848 The PINT Service Protocol June 2000
4a) Protocol Transport formats to indicate the treatment of the
within the
5) Implicit (Indirect) media streams and opaque
6) In-line data objects using multipart/
7) Refinement/Clarification of Opaque arguments passed onwards
Executive
* Framework for Presentation Restriction
* Framework for Q.763
8) An extension mechanism for SDP to specify strictures and
failure when a recipient does NOT support the
extensions, using "require" headers
9) Mandatory support for "Warning" headers to give more
information on request disposition
10) Mechanism to register interest in the disposition of a
service, and to receive indications on that disposition
Both PINT and SIP rely on features of MIME[4]. The use of SIP 2.0
implied by PINT 1.0, and this also implies compliance with
1.0 of MIME
3.2.1. SDP operation in
The SDP payload contains a description of the particular
network session that the requestor wishes to occur in the GSTN.
information includes such things as the telephone network
(i.e. the "telephone number") of the terminal(s) involved in
call, an indication of the media type to be transported (e.g. audio
text, image or application data), and an indication if
information is to be transported over the telephone network
voice, fax, or pager transport. An indication of the content to
sent to the remote telephone terminal (if there is any) is
included
SDP is flexible enough to convey these parameters independently.
example, a request to send some text via voice transport will
fulfilled by invoking some text-to-speech-over-the-phone service,
a request to send text via fax will be fulfilled by invoking
text-to-fax service
The following is a list of PINT 1.0 enhancements and additions
SDP
a. A new network type "TN" and address types "RFC2543" and "X-..."
(section 3.4.1)
b. New media types "text", "image", and "application",
protocol transport keywords "voice", "fax" and "pager" and
associated format types and attribute tags (section 3.4.2)
Petrack & Conroy Standards Track [Page 10]
RFC 2848 The PINT Service Protocol June 2000
c. New format specific attributes for included content
(section 3.4.2.4)
d. New attribute tags, used to pass information to the
network (section 3.4.3)
e. A new attribute tag "require", used by a client to
that some attribute is required to be supported in the
(section 3.4.4)
3.2.2. SIP Operation in
SIP is used to carry the request for telephone service from the
client to the PINT gateway, and may include a telephone number
needed for the particular service. The following is a complete
of PINT enhancements and additions to SIP
f. The multipart MIME payloads (section 3.5.1)
g. Mandatory support for "Warning:" headers (section 3.5.2)
h. The SUBSCRIBE and NOTIFY, and UNSUBSCRIBE requests (
3.5.3)
i. Require: headers (section 3.5.4)
j. A format for PINT URLS within a PINT request (section 3.5.5)
k. Telephone Network Parameters within PINT URLs (section 3.5.6)
Section 3.5.8 contains remarks about how BYE requests are used
PINT. This is not an extension to baseline SIP; it is included
only for clarification of the semantics when used with
network sessions
3.3. REQUIRED and OPTIONAL elements for PINT
Of these, only the TN network type (with its associated RFC2543
address type) and the "require" attribute MUST be supported by
1.0 clients and servers. In practice, most PINT service requests
use other changes, of which references to Data Objects in
are most likely to appear in PINT requests
Each of the other new PINT constructs enables a different function
and a client or server that wishes to enable that particular
MUST do so by the construct specified in this document. For example
building a PINT client and server that provide only the Request-to
Call telephone call service, without support for the other
services, is allowed
The "Require:" SIP header and the "require" attribute provide
mechanism that can be used by clients and servers to signal
need and/or ability to support specific "new" PINT protocol elements
Petrack & Conroy Standards Track [Page 11]
RFC 2848 The PINT Service Protocol June 2000
It should be noted that many optional features of SIP and SDP
sense as specified in the PINT context. One example is the
a=lang: attribute, which can be used to describe the
language of the callee. Another example is the use of the "t="
parameter to indicate that the time at which the PINT service is
be invoked. This is the normal use of the "t=" field. A third
is the quality attributes. Any SIP or SDP option or facility
available to PINT clients and servers without change
Conversely, support for Data Objects within Internet
sessions may be useful, even if the aim is not to provide a
service request. In this case, the extensions covering these
may be incorporated into an otherwise "plain" SIP/SDP invitation
Likewise, support for SDP "require" may be useful, as a framework
addition of features to a "traditional" SIP/SDP infrastructure
Again, these may be convenient to incorporate into SIP/
implementations that would not be used for PINT service requests
Such additions are beyond the scope of this document, however
3.4. PINT Extensions to
PINT 1.0 adds to SDP the possibility to describe audio, fax,
pager telephone sessions. It is deliberately designed to hide
underlying technical details and complexity of the telephone network
The only network type defined for PINT is the generic "TN" (
Network). More precise tags such as "ISDN", "GSM", are not defined
Similarly, the transport protocols are designated simply as "fax",
"voice", and "pager"; there are no more specific identifiers for
various telephone network voice, fax, or pager protocols. Similarly
the data to be transported are identified only by a MIME
type, such as "text" data, "image" data, or some more
"application" data. An important example of
"application" data is the milestone service "Voice Access to
Content". In this case the data to be transported are pointed to by
URI, the data content type is application/URI, and the
protocol would be "voice". Some sort of speech-synthesis facility
speaking out to a Phone, will have to be invoked to perform
service
This section gives details of the new SDP keywords
3.4.1. Network Type "TN" and Address Type "RFC2543"
The TN ("Telephone Network") network type is used to indicate
the terminal is connected to a telephone network
The address types allowed for network type TN are "RFC2543"
private address types, which MUST begin with an "X-".
Petrack & Conroy Standards Track [Page 12]
RFC 2848 The PINT Service Protocol June 2000
Address type RFC2543 is followed by a string conforming to a
of the "telephone-subscriber" BNF specified in figure 4 of SIP [1]).
Note that this BNF is NOT identical to the BNF that defines
"phone-number" within the "p=" field of SDP
Examples
c= TN RFC2543 +1-201-406-4090
c= TN RFC2543 12014064090
A telephone-subscriber string is of one of two types: global-phone
number or local-phone-number. These are distinguished by
a global-phone-number with a "plus" sign ("+"). A global-phone-
is by default to be interpreted as an internationally
E.164 Number Plan Address, as defined by [6], whilst a local-phone
number is a number specified in the default dialling plan within
context of the recipient PINT Gateway
An implementation MAY use private addressing types, which can
useful within a local domain. These address types MUST begin with
"X-", and SHOULD contain a domain name after the X-, e.g. "X
mytype.mydomain.com". An example of such a connection line is
follows
c= TN X-mytype.mydomain.com A*8-
where "X-mytype.mydomain.com" identifies this private address type
and "A*8-HELEN" is the number in this format. Such a format
defined as an "OtherAddr" in the ABNF of Appendix A. Note that
dialable telephone numbers are expressable as local-phone-
within address RFC2543; new address types SHOULD only be used
formats which cannot be so written
3.4.2. Support for Data Objects within
One significant change over traditional SIP/SDP Internet
sessions with PINT is that a PINT service request may refer to a
Object to be used as source information in that request. For example
a PINT service request may specify a document to be processed as
of a GSTN service by which a Fax is sent. Similarly, a GSTN
may be take a Web page and result in a vocoder processing that
and speaking the contents over a telephone
The SDP specification does not have explicit support for reference
or carriage of Data Objects within requests. In order to use SDP
PINT, there is a need to describe such media sessions as "a
Petrack & Conroy Standards Track [Page 13]
RFC 2848 The PINT Service Protocol June 2000
call to a certain number during which such-and-such an image is
as a fax".
To support this, two extensions to the session description format
specified. These are some new allowed values for the Media Field,
a description of the "fmtp" parameter when used with the Media
values (within the context of the Contact Field Network type "TN").
An addition is also made to the SIP message format to allow
inclusion of data objects as sub-parts within the request
itself. The original SDP syntax (from [2]) for media-field is
as
media-field = "m=" media space port ["/" integer
space proto 1*(space fmt)
When used within PINT requests, the definition of the sub-fields
expanded slightly. The Media sub-field definition is relaxed
accept all of the discrete "top-level" media types defined in [4].
the milestone services the discrete type "video" is not used, and
extra types "data" and "control" are likewise not needed. The use
these types is not precluded, but the behaviour expected of a
Gateway receiving a request including such a type is not
here
The Port sub-field has no meaning in PINT requests as the
terminals are specified using "TN" addressing, so the value of
port sub-field in PINT requests is normally set to "1". A value
"0" may be used as in SDP to indicate that the terminal is
receiving media. This is useful to indicate that a
terminal has gone "on hold" temporarily. Likewise, the
integer sub-field is not used in PINT
As mentioned in [2], the Transport Protocol sub-field is specific
the associated Address Type. In the case that the Address Type in
preceeding Contact field is one of those defined for use with
Network Type "TN", the following values are defined for the
Protocol sub-field
"voice", "fax", and "pager".
The interpretation of this sub-field within PINT requests is
treatment or disposition of the resulting GSTN service. Thus,
transport protocol "voice", the intent is that the service
result in a GSTN voice call, whilst for protocol "fax" the
will be a GSTN fax transmission, and protocol "pager" will result
a pager message being sent
Petrack & Conroy Standards Track [Page 14]
RFC 2848 The PINT Service Protocol June 2000
Note that this sub-field does not necessarily dictate the media
and subtype of any source data; for example, one of the
services calls for a textual source to be vocoded and spoken in
resulting telephone service call. The transport protocol value
this case would be "voice", whilst the media type would be "text".
The Fmt sub-field is described in [2] as being transport protocol
specific. When used within PINT requests having one of the
protocol values, this sub-field consists of a list of one or
values, each of which is a defined MIME sub-type of the
Media sub-field value. The special value "-" is allowed, meaning
there is no MIME sub-type. This sub-field retains (from [2])
meaning that the list will contain a set of alternative sub-types
with the first being the preferred value
For experimental purposes and by mutual consent of the sender
recipient, a sub-type value may be specified as an , i.e.
character string starting with "X-". The use of such values
discouraged, and if such a value is expected to find common use
it SHOULD be registered with IANA using the standard content
registration process (see Appendix C).
When the Fmt parameter is the single character "-" ( a dash ),
is interpreted as meaning that a unspecified or default sub-type
be used for this service. Thus, the media field value "m=audio 1
voice -" is taken to mean that a voice call is requested,
whatever audio sub type is deemed appropriate by the
System. PINT service is a special case, in that the request
from the IP network but the service call is provided within the GSTN
Thus the service request will not normally be able to define
particular codec used for the resulting GSTN service call. If such
intent IS required, then the quality attribute may be used (
"Suggested Attributes" section of [2]).
3.4.2.1. Use of fmtp attributes in PINT
For each element of the Fmt sub-field, there MUST be a following
attribute. When used within PINT requests, the fmtp attribute has
general structure as defined here
"a=fmtp:"
*( resolution
( ";" 1(<attribute>)
*( <attribute>))
where
<resolution> := ( | | )
Petrack & Conroy Standards Track [Page 15]
RFC 2848 The PINT Service Protocol June 2000
A fmtp attribute describes the sources used with a given Fmt entry
the Media field. The entries in a Fmt sub-field are
(with the preferred one first in the list). Each entry will have
matching fmtp attribute. The list of resolutions in a fmtp
describes the set of sources that resolve the matching Fmt choice
all elements of this set will be used
It should be noted that, for use in PINT services, the elements
such a set will be sent as a sequence; it is unlikely that trying
send them in parallel would be successful
A fmtp attribute can contain a mixture of different kinds of element
Thus an attribute might contain a sub-part-ref indicating
data held in a sub-part of the current message, followed by
opaque-ref referring to some content on the GSTN, followed by a uri
ref pointing to some data held externally on the IP network
To indicate which form each resolution element takes, each of
starts with its own literal tag. The detailed syntax of each form
described in the following sub-sections
3.4.2.2. Support for Remote Data Object References in
Where data objects stored elsewhere on the IP Network are to be
as sources for processing within a PINT service, they may be
to using the uri-ref form. This is simply a Uniform
Identifier (URI), as described in [9].
Note that the reference SHOULD be an absolute URI, as there may
be enough contextual information for the recipient server to
a relative reference; any use of relative references requires
private agreement between the sender and recipient of the message
and SHOULD be avoided unless the sender can be sure that
recipient is the one intended and the reference is unambiguous
context
This also holds for partial URIs (
as"uri:http://aNode/index.htm") as these will need to be resolved
the context of the eventual recipient of the message
The general syntax of a reference to an Internet-based external
object in a fmtp line within a PINT session description is
:= ("uri:" URI-reference
where URI-reference is as defined in Appendix A of [9]
Petrack & Conroy Standards Track [Page 16]
RFC 2848 The PINT Service Protocol June 2000
For example
c= TN RFC2543 +1-201-406-4090
m= text 1 fax
a=fmtp:plain uri:ftp://ftp.isi.edu/in-notes/rfc2468.
or
c= TN RFC2543 +1-201-406-4090
m= text 1 fax
a=fmtp:
uri:http://www.ietf.org/meetings/glance_minneapolis.
means get this data object from the Internet and use it as a
for the requested GSTN Fax service
3.4.2.3. Support for GSTN-based Data Objects in
PINT services may refer to data that are held not on the IP
but instead within the GSTN. The way in which these items
indicated need have no meaning within the context of the Requestor
the PINT Gateway; the reference is merely some data that may be
by the Executive System to indicate the content intended as part
the request. These data form an opaque reference, in that they
sent "untouched" through the PINT infrastructure
A reference to some data object held on the GSTN has the
definition
:= ("opr:" *uric
where uric is as defined in Appendix A of [9].
For example
c= TN RFC2543 +1-201-406-4090
m= text 1 fax
a=fmtp:plain opr:APPL.123.456
means send the data that is indexed ON THE GSTN by the
value "APPL.123.456" to the fax machine on +1-201-406-4090.
Executive System may also take the Telephone URL held in the To
field of the enclosing SIP message into account when deciding
context to be used for the data object dereference
Of course, an opaque reference may also be used for other purposes
it could, for example, be needed to authorise access to a
held on the GSTN rather than being required merely to
Petrack & Conroy Standards Track [Page 17]
RFC 2848 The PINT Service Protocol June 2000
the data object. The purpose to which an opaque reference is put
however, is out of scope for this document. It is merely an
carried within a PINT Request
An opaque reference may have no value in the case where the value
be used is implicit in the rest of the request. For example,
some company wishes to use PINT to implement a "fax-back service".
their current implementation, the image(s) to be faxed are
defined by the telephone number dialled. Within the PINT request
this telephone number would appear within the "To:" field of the
request, and so there is no need for an opaque reference value
If there are several resolutions for a PINT Service Request, and
of these is an opaque reference with no value, then that
reference MUST be included in the attribute line, but with an
value field
For example
c= TN RFC2543 +1-201-406-4090
m= text 1 fax
a=fmtp:plain uri:http://www.sun.com/index.html opr
might be used to precede some data to be faxed with a covering note
In the special case where an opaque reference is the sole
of a PINT Service Request, AND that reference needs no value,
is no need for a Fmt list at all; the intent of the service
unambiguous without any further resolution
For example
c= TN RFC2543 +1-201-406-4090
m= text 1 fax -
means that there is an implied content stored on the GSTN, and
this is uniquely identified by the combination of SIP To-URI and
Contact field of the session description
3.4.2.4. Session Description support for included Data
As an alternative to pointing to the data via a URI or an
reference to a data item held on the GSTN, it is possible to
the content data within the SIP request itself. This is done by
multipart MIME for the SIP payload. The first MIME part contains
SDP description of the telephone network session to be executed.
other MIME parts contain the content data to be transported
Petrack & Conroy Standards Track [Page 18]
RFC 2848 The PINT Service Protocol June 2000
Format specific attribute lines within the session description
used to indicate which other MIME part within the request
the content data. Instead of a URI or opaque reference, the format
specific attribute indicates the Content-ID of the MIME part of
request that contains the actual data, and is defined as
:= ("spr:" Content-ID
where Content-ID is as defined in Appendix A of [3] and in [10]).
For example
c= TN RFC2543 +1-201-406-4090
m= text 1 fax
a=fmtp:plain spr:
The parameter is the Content-ID of one of the MIME
inside the message, and this fragment means that the requesting
would like the data object held in the sub-part of this
labelled to be faxed to the machine at phone number +1-
201-406-4090.
See also section 3.5.1 for a discussion on the support needed in
enclosing SIP request for included data objects
3.4.3. Attribute Tags to pass information into the Telephone
It may be desired to include within the PINT request
parameters that can be understood only by some entity in
"Telephone Network Cloud". SDP attribute parameters are used for
purpose. They MAY appear within a particular media description
outside of a media description
These attributes may also appear as parameters within PINT URLS (
section 3.5.6) as part of a SIP request
This is necessary so that telephone terminals that require
attributes to be defined can appear within the To: line of a
request as well as within PINT session descriptions
The purpose of these attributes is to allow the client to
extra context within which a particular telephone number is to
interpreted. There are many reasons why extra context might
necessary to interpret a given telephone number
Petrack & Conroy Standards Track [Page 19]
RFC 2848 The PINT Service Protocol June 2000
a. The telephone number might be reachable in many different
(such as via competing telephone service providers), and
PINT client wishes to indicate its selection of
provider
b. The telephone number might be reachable only from a
number of networks (such as an '800' freephone number).
c. The telephone number might be reachable only within a
telephone network (such as the '152' customer service number
BT). Similarly, the number might be an internal
extension reachable only within the PBX
However, as noted above, it is not usually necessary to use
attributes to specify the phone context. URLs such
152@pint.bt.co.il within the To: and From: headers and/or Request
URI, normally offer sufficient context to resolve telephone numbers
If the client wishes the request to fail if the attributes are
supported, these attributes SHOULD be used in conjunction with
"require" attribute (section 3.4.4) and
"Require:org.ietf.sdp.require" header (section 3.5.4).
It is not possible to standardise every possible internal
network parameter. PINT 1.0 attributes have been chosen
specification because they are common enough that many different
systems will want to use them, and therefore interoperability will
increased by having a single specification
Proprietary attribute "a=" lines, that by definition are
interoperable, may be nonetheless useful when it is necessary
transport some proprietary internal telephone network variables
the IP network, for example to identify the order in which
call legs are to be be made. These private attributes SHOULD BE
however, subject to the same IANA registration procedures
in the SDP specification[2] (see also this Appendix C).
3.4.3.1. The phone-context
An attribute is specified to enable "remote local dialling". This
the service that allows a PINT client to reach a number from
outside the area or network that can usually reach the number. It
useful when the sending or receiving address is only dialable
some local context, which may be remote to the origin of the
client
For example, if Alice wanted to report a problem with her telephone
she might then dial a "network wide" customer care number; within
British Telecom network in the U.K., this is "152". Note that in
case she doesn't dial any trunk prefix - this is the whole
Petrack & Conroy Standards Track [Page 20]
RFC 2848 The PINT Service Protocol June 2000
number. If dialled from another operator's network, it will
connect to British Telecom's Engineering Enquiries service;
dialling "+44 152" will not normally succeed. Such numbers are
Network-Specific Service Numbers
Within the telephone network, the "local context" is provided by
physical connection between the subscriber's terminal and the
office. An analogous association between the PINT client and the
server that first receives the request may not exist, which is why
may be necessary to supply this missing "telephone network context".
This attribute is defined as follows
a=phone-context:
phone-context-ident = network-prefix / private-
network-prefix = intl-network-prefix / local-network-
intl-network-prefix = "+" 1*
local-network-prefix = 1*
excldigandplus = (0x21-0x2d,0x2f,0x40-0x7d))
private-prefix = 1*excldigandplus 0*
An intl-network-prefix and local-network-prefix MUST be a bona
network prefix, and a network-prefix that is an intl-network-
MUST begin with an E.164 service code ("country code").
It is possible to register new private-prefixes with IANA so as
avoid collisions. Prefixes that are not so registered MUST begin
an "X-" to indicate their private, non-standard nature (see
C).
Example 1:
c= TN RFC2543 1-800-765-4321
a=phone-context:+972
This describes an terminal whose address in Israel (E.164
code 972) is 1-800-765-4321.
Example 2:
c= TN RFC2543 1-800-765-4321
a=phone-context:+1
This describes an terminal whose address in North America (E.164
country code 1) is 1-800-765-4321.
The two telephone terminals described by examples 1 and 2
different; in fact they are located in different countries
Petrack & Conroy Standards Track [Page 21]
RFC 2848 The PINT Service Protocol June 2000
Example 3:
c=TN RFC2543 123
a=phone-context:+97252
This describes a terminal whose address when dialled from within
network identified by +97252 is the string "123". It so happens
+97252 defines one of the Israeli cell phone providers, and 123
reaches customer service when dialled within that network
It may well be useful or necessary to use the SDP "require"
in conjunction with the phone-context attribute
Example 4:
c= TN RFC2543 321
a=phone-context:X-acme.com-23
This might describe the telephone terminal that is at extension 321
of PBX number 23 within the acme.com private PBX network. It
expected that such a description would be understandable by
acme.com PINT server that receives the request
Note that if the PINT server receiving the request is inside
acme.com network, the same terminal might be addressable as follows
c= TN RFC2543 7-23-321
(assuming that "7" is dialled in order to reach the private
network from within acme.com
3.4.3.2. Presentation Restriction
Although it has no affect on the transport of the service
through the IP Network, there may be a requirement to
originators of a PINT service request to indicate whether or not
wish the "B party" in the resulting service call to be presented
the "A party's" calling telephone number. It is a legal
in some jurisdictions that a caller be able to select whether or
their correspondent can find out the calling telephone number (
Automatic Number Indication or Caller Display or Calling
Identity Presentation equipment). Thus an attribute may be needed
indicate the originator's preference
Whether or not the default behaviour of the Executive System is
present or not present a party's telephone number to
correspondent GSTN terminal is not specified, and it is not
in all territories for a PINT Gateway or Executive System to act
Petrack & Conroy Standards Track [Page 22]
RFC 2848 The PINT Service Protocol June 2000
this attribute. It is, however, defined here for use where there
regulatory restrictions on GSTN operation, and in that case
Executive System can use it to honour the originator's request
The attribute is specified as follows
a=clir:<"true" | "false">
This boolean value is needed within the attribute as it may be
the GSTN address is, by default, set to NOT present its identity
correspondents, and the originator wants to do so for this
call. It is in keeping with the aim of this attribute to allow
originator to specify what treatment they want for the
service call
The expected interpretation of this attribute is that, if it
present and the value is "false" then the Calling Line Identity
be presented to the correspondent terminal, whilst if it is "true
then if possible the Executive System is requested to NOT present
Calling Line Identity
3.4.3.3. ITU-T CalledPartyAddress attributes
These attributes correspond to fields that appear within the ITU-
Q.763 "CalledPartyAddress" field (see [8] ,section 3.9). PINT
use these attributes in order to specify further parameters
to Terminal Addresses, in the case when the address indicates
"local-phone-number". In the case that the PINT request contains
reference to a GSTN terminal, the parameters may be required
correctly identify that remote terminal
The general form of this attribute is: "a=Q763-((":" )
|"")". Three of the possible elements and their use in
attributes are described here. Where other Q763 elements are to
used, then these should be the subject of further specification
define the syntax of the attribute mapping. It is recommended
any such specification maintains the value sets shown in Q.763.
The defined attributes are
a=Q763-nature: - indicates the "nature of address indicator".
The value MAY be any number between 0 and 127.
The following values are specified
"1" a subscriber
"2"
"3" a nationally significant
"4" an internationally significant
Petrack & Conroy Standards Track [Page 23]
RFC 2848 The PINT Service Protocol June 2000
The values have been chosen to coincide with the values in Q.763.
Note that other values are possible, according to national rules
future expansion of Q.763.
a=Q763-plan: - indicates the numbering plan to which the
belongs. The value MAY be any number between 0
and 7. The following values are specified
"1" Telephone numbering plan (ITU-T E.164)
"3" Data numbering plan (ITU-T X.121)
"4" Telex numbering plan (ITU-T F.69)
The values have been chosen to coincide with the values in Q.763.
Other values are allowed, according to national rules or
expansion of Q.763.
a=Q763-INN - indicates if routing to the Internal Network
is allowed. The value MUST be ONE of
"0" routing to internal network number
"1" routing to internal network number
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
attributes that the number is in fact an internationally
E.164 number. Normally this SHOULD NOT be done; an
significant E.164 number is indicated by using a "global-phone
number" for the address string
3.4.4. The "require"
According to the SDP specification, a PINT server is allowed
to ignore attribute parameters that it does not understand. In
to force a server to decline a request if it does not understand
of the PINT attributes, a client SHOULD use the "require" attribute
specified as follows
a=require:<attribute-list
where the attribute-list is a comma-separated list of attributes
appear elsewhere in the session description
In order to process the request successfully the PINT server
BOTH understand the attribute AND ALSO fulfill the request implied
the presence of the attribute, for each attribute appearing
the attribute-list of the require attribute
Petrack & Conroy Standards Track [Page 24]
RFC 2848 The PINT Service Protocol June 2000
If the server does not recognise the attribute listed, the
server MUST return an error status code (such as 420 (Bad Extension
or 400 (Bad Request)), and SHOULD return suitable Warning:
explaining the problem or an Unsupported: header containing
attribute it does not understand. If the server recognizes
attribute listed, but cannot fulfill the request implied by
presence of the attribute, the request MUST be rejected with a
code of (606 Not Acceptable), along with a suitable Unsupported
header or Warning: line
The "require" attribute may appear anywhere in the
description, and any number of times, but it MUST appear before
use of the attribute marked as required
Since the "require" attribute is itself an attribute, the
specification allows a server that does not understand the
attribute to ignore it. In order to ensure that the PINT server
comply with the "require" attribute, a PINT client SHOULD include
Require: header with the tag "org.ietf.sdp.require" (section 3.5.4)
Note that the majority of the PINT extensions are "tagged" and
tags can be included in Require strictures. The exception is the
of phone numbers in SDP parts. However, these are defined as a
network and address type, so that a receiving SIP/SDP server
be able to detect whether or not it supports these forms. The
behaviour for any SDP recipient is that it will fail a PINT
if it does not recognise or support the TN and RFC2543 or X-
network and address types, as without the contents being
no media session could be created. Thus a separate stricture is
required in this case
3.5. PINT Extensions to SIP 2.0
PINT requests are SIP requests; Many of the specifications
this document merely explain how to use existing SIP facilities
the purposes of PINT
3.5.1. Multi-part MIME (sending data along with SIP request
A PINT request can contain a payload which is multipart MIME. In
case the first part MUST contain an SDP session description
includes at least one of the format specific attribute tags
"included content data" specified above in section 3.4.3.
parts contain content data that may be transferred to the
Telephone Call Service. As discussed earlier, within a single
request, some of the data MAY be pointed to by a URI within
request, and some of the data MAY be included within the request
Petrack & Conroy Standards Track [Page 25]
RFC 2848 The PINT Service Protocol June 2000
Where included data is carried within a PINT service request,
Content Type entity header of the enclosing SIP message MUST
this. To do so, the media type value within this entity header
be set to a value of "multipart". There is a content sub-type that
intended for situations like this in which sub-parts are to
handled together. This is the multipart/related type (defined
[19]), and it's use is recommended
The enclosed body parts SHOULD include the part-specific Content
headers as appropriate ("application/sdp" for the first body
holding the session description, with an appropriate content type
each of the subsequent, "included data object" parts). This
the standard syntax of MIME multipart messages as defined in [4].
For example, in a multipart message where the
"------next-------" is the boundary, the first two parts might be
follows
------next-------
Content-Type: application/
....
c= TN RFC2543 +1-201-406-4090
m= text 1 pager
a=fmtp:plain spr:17@mymessage.acme.
----------next-------
Content-Type: text/
Content-ID: 17@mymessage.acme.
This is the text that is to be paged to +1-201-406-4090
----------next-----------
The ability to indicate different alternatives for the content to
transported is useful, even when the alternatives are included
the request. For example, a request to send a short message to
pager might include the message in Unicode [5] and an
version of the same content in text/plain, should the PINT server
telephone network not be able to process the unicode
PINT clients should be extremely careful when sending included
within a PINT request. Such requests SHOULD be sent via TCP, to
fragmentation and to transmit the data reliably. It is possible
the PINT server is a proxy server that will replicate and fork
request, which could be disastrous if the request contains a
amount of application data. PINT proxy servers should be careful
to create many copies of a request with large amounts of data in it
Petrack & Conroy Standards Track [Page 26]
RFC 2848 The PINT Service Protocol June 2000
If the client does not know the actual location of the PINT gateway
and is using the SIP location services to find it, and the
data makes the PINT request likely to be transported in several
datagrams, it is RECOMMENDED that the initial PINT request
include the data object but instead hold a reference to it
3.5.2. Warning
A PINT server MUST support the SIP "Warning:" header so that it
signal lack of support for individual PINT features. As an example
suppose the PINT request is to send a jpeg picture to a fax machine
but the server cannot retrieve and/or translate jpeg pictures
the Internet into fax transmissions
In such a case the server fails the request and includes a
such as the following
Warning: 305 pint.acme.com Incompatible media format:
SIP servers that do not understand the PINT extensions at all
strongly encouraged to implement Warning: headers to indicate
PINT extensions are not understood
Also, Warning: headers may be included within NOTIFY requests if
is necessary to notify the client about some condition concerning
invocation of the PINT service (see next).
3.5.3. Mechanism to register interest in the disposition of a
service, and to receive indications on that
It can be very useful to find out whether or not a requested
has completed, and if so whether or not it was successful. This
especially true for PINT service, where the person requesting
service is not (necessarily) a party to it, and so may not have
easy way of finding out the disposition of that service. Equally,
may be useful to indicate when the service has changed state,
example when the service call has started
Arr