Internet Engineering Task Force Adam Roach
Internet Draft Ericsson Inc.
Category: Standards Track June 1999
Expires January 2000
<draft-roach-mmusic-sip-pstn-require-header-00.txt>
SIP PSTN Interworking Umbrella "Require:" Header
Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC 2026.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
To view the entire list of current Internet-Drafts, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
(Northern Europe), ftp.nis.garr.it (Southern Europe),
munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
This document outlines a new value for the SIP "Require:" header
which denotes compliance with a number of mechanisms necessary to
interwork smoothly with existing telephony networks.
1. Introduction
There have been a number of extensions to the SIP protocol ( ref
[1] ) proposed to provide smooth interoperation between SIP and
the PSTN network. Most of these are negotiated by means of
"Require:" and "Proxy-Require:" headers.
It has not yet been made clear which of these extensions are
expected to be supported by nodes which need to interoperate with
the PSTN.
Additionally, since each extension may add up to two additional
headers, and many calls involving interworking will be carrying
bodies with multiple payloads, the risk of overflowing an MTU
during UDP communications is becoming a potential problem.
Roach [Page 1]
Internet Draft June 1999
This draft seeks to alleviate these problems by adding the
capability to imply a set of SIP extensions necessary for
fully-functional PSTN interworking with a single pair of
"Require" and "Proxy-Require" headers.
2. Included Features
The following sections outline the extensions required for
full-featured PSTN interworking and the rationale for their
inclusion. Note that some features do not apply to native SIP
clients, and only place requirements on those nodes which
interface with the existing telephony infrastructure. These
extensions are noted as appropriate.
2.1. Transparent Transit of ISUP messages
To provide users the ability to take advantage of the full range
of services afforded by the existing telephone network when
placing calls from PSTN to PSTN across a SIP network, SIP
messages will need to carry ISUP payloads from gateway to
gateway.
All nodes which serve as SIP/PSTN interworking points and
generate or accept the "Require:" header value defined in this
document MUST provide for transparent transmission of ISUP
messages in the body of SIP messages to trusted clients. This
behavior is outlined in "The application/ISUP media type" ( ref
[2] ) and "ISUP Parameters Expected in SIP Messages" ( ref [6] ).
Proxy servers which accept the "Proxy-Require:" header value
defined in this document SHOULD NOT behave in a way to preclude
the transmission of ISUP bodies; they should pass any ISUP bodies
through untouched. Exceptions include proxies which serve as
policy enforcement points between providers' networks or to
non-trusted clients.
UAC/UAS nodes which generate or accept the "Require:" header
value defined in this document but do not serve as PSTN
interworking points are not required to understand or generate
ISUP messages under any circumstances; however, they SHOULD
silently discard any ISUP bodies or body parts without generating
an error code.
2.2. Understanding of Multipart Bodies
In most PSTN interworking situations, the SIP body will be
required to carry session information in addition to ISUP and/or
billing information.
All nodes which generate or accept the "Require:" header value
Roach [Page 2]
Internet Draft June 1999
defined in this document MUST understand the multipart body
extension defined in "The multipart/sip-id media type" ( ref [3]
). Generation of SIP messages which are not multipart is,
however, still allowable.
Proxies which accept the "Proxy-Require:" header value defined in
this document MUST behave in such a way as to not preclude the
transmission of multipart bodies.
2.3. In-Band Transmission of DTMF information
Since the codec selected for voice transmission may not be
ideally suited for carrying DTMF information, a symbolic method
of transmitting this information in-band is necessary.
All nodes which generate or accept the "Require:" header value
defined in this document and have direct control over the audio
stream SHOULD be capable of generating in-band signalling
representing DTMF information as defined in "RTP Payload for DTMF
Digits, Telephony Tones and Telephony Signals" ( ref [4] ).
Nodes which do not perform PSTN interworking are not required to
generate packets of type "line" and "trunk," nor are they
required to interpret any of the extended RTP payload signalling;
however, they MUST not treat receipt of such packets as an error.
Nodes which do perform PSTN interworking SHOULD understand and
generate "tone," "line," and "trunk" payloads as defined in the
previously referenced document, when and if such payloads are
applicable.
Those nodes which do not have direct control over the audio
stream (e.g. media gateway controllers) have no requirements
placed on them by this section.
Media gateways may claim full compliance with this document if
they generate and understand "tone," "line," and "trunk" payloads
as defined in the previously referenced document.
2.4. Out-of-Band Transmission of DTMF information
In addition to the need to faithfully carry telephony tones
across the audio channel, PSTN interworking situations will
require the capability on the part of SIP nodes to collect
further digits from the end user. This may be used, for example,
to provide authentication information to a SIP node via DTMF.
All nodes which generate or accept the "Require:" header value
defined in this document and have direct control over the audio
stream SHOULD understand the SUBSCRIBE and NOTIFY extension
Roach [Page 3]
Internet Draft June 1999
designed for transport of DTMF information. This document is not
yet written.
Proxy servers which accept the "Proxy-Require:" header value
defined in this document MUST either understand the SUBSCRIBE and
NOTIFY extensions mentioned above or allow SUBSCRIBE and NOTIFY
requests and responses to pass between endpoints.
2.5. Reliable Transmission of Provisional Responses
Since provisional messages, such as "180 Ringing," will probably
be used by most PSTN interworking implementations to trigger
generation of messages indicating that a complete address has
been collected, the reliable transmission of such messages is
very important to prevent calls from timing out during the setup
phase.
All nodes which generate or accept the "Require:" and/or
"Proxy-Require:" header values defined in this document MUST
implement the extension defined in "Reliability of Provisional
Responses in SIP" ( ref [7] ).
2.6. Provisional Media Streams
To allow the transmission of messages and tones before a final
connection has been established, SIP nodes which interwork with
the PSTN need to be able to establish temporary media connections
during this period.
All nodes which generate the "Require:" header values defined in
this document MUST support receipt of temporary provisional media
streams, as specified in "Provisional SIP Responses with Media" (
ref [5] ).
All nodes which serve as SIP/PSTN interworking points and accept
the "Require:" header value defined in this document SHOULD
transmit provisional media streams whenever appropriate (e.g. to
deliver remote ring-tone).
2.7. Mandatory Provisional Responses
As previously mentioned, the transmission of provisional
responses serves an important role in PSTN interworking
situations. To this end, such responses are required to be used
consistently by clients.
All nodes which accept the "Require:" header value defined in
this document MUST generate a provisional response with a code
between 180 and 199 inclusive once it has determined that the
INVITE request contains sufficient information to uniquely
Roach [Page 4]
Internet Draft June 1999
identify an end device.
2.8. Mid-Call Transactions Which do not Change SIP State
When interworking with PSTN, there are several situations when
PSTN nodes will need to send messages which do not correspond to
any SIP operations to each other across a SIP network.
To allow transit of such methods, proxies which accept the
"Proxy-Require:" header value defined in this document SHOULD
allow INFO messages to be carried between endpoints. Exceptions
include proxies which serve as policy enforcement points between
providers' networks or to non-trusted clients; if the proxy
elects to block transmission of the INFO message, it SHOULD
return "405 Method Not Allowed."
UAC/UAS nodes which generate or accept the "Require:" header
value defined in this document but do not serve as PSTN
interworking points are not required to generate or understand
INFO messages (in which case they may return "501 Not
Implemented"); however, they MUST NOT treat such messages as
fatal errors.
Nodes which do serve as PSTN interworking points SHOULD accept
"405 Method Not Allowed" and "501 Not Implemented" responses to
INFO requests as non-fatal.
2.9. Call Control Services
To facilitate the implementation of value-added services, many of
which require some degree of third party call control, units
which support PSTN interworking will also need to support basic
call control services.
All nodes which accept or generate the "Require:" header values
defined in this document MUST understand the extensions defined
in "SIP Call Control Services" ( ref [8] ).
3. "Require:" and "Proxy-Require:" Headers
The method for indicating protocol extensions is that described
in sections 6.28 and 6.30 of "SIP: Session Initiation Protocol" (
ref [1] ).
Note that the headers defined in this document will be used
instead of, not in addition to, the "Require:" and
"Proxy-Require:" headers defined in the referenced documents.
3.1. Values
Roach [Page 5]
Internet Draft June 1999
The header value defined for the purpose of denoting the need for
the above services is "org.ietf.sip.pstn-interwork". When using
the extensions described in this document, the client MUST
include the extension name in both a "Require:" and a
"Proxy-Require:" header for all INVITE requests.
3.2. Negotiation
If a server requires the extensions described in this document
but receives no appropriate "Require:" header from the client, it
SHOULD respond with a "403 Forbidden" response which contains a
"Warning:" header. The value of the warning code will be reserved
from the IANA at a later date. Clients understanding the warning
code SHOULD then automatically re-issue the INVITE request with
appropriate headers.
If a server supports but does not require the extensions defined
in this document and receives an INVITE which does not contain an
appropriate "Require:" header, it SHOULD include the above
mentioned "Warning:" header in all responses, including 100 and
200 class responses.
A client which supports but does not require the extensions
defined in this document will respond to any 100 or 200 class
messages containing the above mentioned "Warning:" header by
re-issuing the INVITE request with an appropriate set of
"Require:" and "Proxy-Require:" headers. The client MAY cache the
fact that a particular URI supports PSTN interworking extensions.
If, upon re-issuing the INVITE, the client receives a 420
response (e.g. from a proxy), it SHOULD re-issue the original
INVITE request. The client MAY cache the fact that the path to a
particular URI does not support PSTN interworking extensions. If
such information is not cached, the client MUST take other
precautions to ensure that it does not become locked in a loop
(e.g. INVITE, 403, INVITE, 200, INVITE, 403...).
4. References
[1] M. Handley/H. Schulzrinne/E. Schooler/J. Rosenberg, "SIP:
Session Initiation Protocol", RFC 2543, IETF; March 1999.
[2] Christian Huitema, "The application/ISUP media type",
Internet Draft <draft-ietf-sigtran-mime-isup-00.txt>, IETF;
Feb. 1999. Work in progress.
[3] Christian Huitema, "The multipart/sip-id media type",
Internet Draft <draft-ietf-mmusic-sip-multipart-00.txt>,
IETF; Feb. 1999. Work in progress.
Roach [Page 6]
Internet Draft June 1999
[4] H. Schulzrinne/S Petrack, "RTP Payload for DTMF Digits,
Telephony Tones and Telephony Signals", Internet Draft
<ietf-avt-tones-01.txt>, IETF; June 1999. Work in progress.
[5] Adam Roach, "Provisional SIP Responses with Media", Internet
Draft <draft-roach-mmusic-sip-provisional-media-00.txt>,
IETF; June 1999. Work in progress.
[6] Adam Roach, "ISUP Parameters Expected in SIP Messages",
Internet Draft <draft-roach-sip-isup-parameters-00.txt>,
IETF; June 1999. Work in progress.
[7] J. Rosenberg/H. Schulzrinne, "Reliability of Provisional
Responses in SIP", Internet Draft
<draft-ietf-mmusic-sip-100rel-01.txt>, IETF; May 1999. Work
in progress.
[8] H. Schulzrinne/J. Rosenberg, "SIP Call Control Services",
Internet Draft <draft-ietf-mmusic-sip-cc-01.txt>, IETF;
June/July 1999. Work in progress (not yet released).
[9] Steven R. Donovan, "The SIP INFO Method", Internet Draft
<draft-ietf-mmusic-sip-info-method-00.txt>, IETF; Feb. 1999.
Work in progress.
5. Security Considerations
This memo adds no security considerations beyond those applicable
to the referenced documents.
6. Author's Address
Adam Roach
Ericsson Inc.
Mailstop L-04
851 International Pkwy.
Richardson, TX 75081
USA
Phone: 972-583-7594
Fax: 972-669-0154
E-Mail: adam.roach@ericsson.com
Roach [Page 7]