Internet Engineering Task Force Christian Huitema
INTERNET DRAFT Bellcore
February 5, 1999 Expires August 5, 1999
<draft-ietf-mmusic-sip-multipart-00.txt>
The multipart/sip-id media type
Status of this document
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."
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 proposes the definition of a multipart/sip-id media type,
according to the rules defined in RFC 2048. This media type is intended
to be carried by the session invitation protocol messages, when these
messages are used to route calls between Internet Telephony domains.
1. Motivation
There have been proposals to use the "session invitation protocol" to
route calls between Internet Telephony domains. It has been observed
that these gateways need more information than just the "session
description" carried in standard session invitation protocol messages.
Specifically:
Huitema [Page 1]
Internet draft The multipart/sip-id media type February 2, 1999
* In a situation where a session originates from, or is possibly
going intended to terminate to, a classical switched telephony net-
work, it may be useful or even necessary to carry the information
that was used in generating the Internet Telephony signaling mes-
sage as part of the session setup message. This draft proposes a
method for tunneling the original signalling information between
the "ingress" and "egress" gateways, thus avoiding loss of informa-
tion.
* Internet Telephony signaling across administrative domains will
probably not be practical unless deployed in conjunction to an
Electronic Commerce infrastructure for Internet bandwidth and for
brokered access to regulated legacy network elements.
The content of the session invitation protocol messages is identified by
a media type. In the case of domain interconnection, we propose to
replace to carry session description, telephony signalling and settle-
ment information in a "multipart" content type, of type "multipart/sip-
id" (SIP Inter-Domain). The multipart/sip-id will includes up to three
content parts:
* A session description part, typically of type "application/sdp",
* A telephony signalling part, typically of type "application/ISUP",
* A settlement information part, for example of type
"application/otp".
Each of these content types will be identified by a regularly registered
media type, such as for example "application/sdp", "application/ISUP" or
"application/otp". However, we do not expect all SIP implementations to
be able to recognize all possible telephone signallin protocols, or all
possible settlement procedures. The multipart format will identify the
position and role of the various content parts, so that entities could
if necessary focus on the part that they need to understand (e.g., the
session description) and ignore the other parts.
This memo proposes a definition of an "multipart/sip-id" media type
according to the rules defined in RFC 2048. It does not attempt to
define the telephony signalling or settlement parts.
2. The multipart/sip-id media type
The structure of the "sip-id" multipart follows the basic rules for mul-
tipart media types defined in RFC 2046. The Multipart/sip-id type is
defined as follow:
(1) MIME type name: multipart
Huitema [Page 2]
Internet draft The multipart/sip-id media type February 2, 1999
(2) MIME subtype name: sip-id
(3) Required parameters: boundary
(4) Optional parameters: content
(5) Security considerations: see section 5.
The multipart/sip-id content type contains up to three body parts:
* The "session description" body part, if present, contains a valid
session description.
* The "telephony signalling" body part, if present, contains a copy
of the signalling message that triggered the SIP message.
* The "payment information" body part, if present, contains informa-
tion relevant to the payment or the settlement of the call.
Each body part contains a valid MIME media type. The role of the body
parts that are present in a given sip-id multipart is specified by the
content parameter.
The content token for the protocol parameter is "content", i.e.,
parameter = "content" "=" value
The value token is comprised of the roles of the body parts that are
present:
value = DQUOTE role-list DQUOTE
role-list = role / role-list "," role
role = session-description /
telephony-signalling /
payment-information
session-description = "sd"
telephony-signalling = "ts"
payment-information = "pi"
If a session-description is present, it should be encoded as the first
body part. The telephony signalling should come next (or first, if
there is no session description.) The payment information should come
last.
The content token is optional. If the content token is absent, the
first body part is assumed to be a session description, the second body
part, if present, is assumed to be a telephone signalling message, and
Huitema [Page 3]
Internet draft The multipart/sip-id media type February 2, 1999
the third, if present, is assumed to be a payment information.
3. Security considerations
Telephony signalling and settlement information often contain sensitive
or critical information. The security provisions of the Session Invita-
tion Protocol should be use to protect these data when they are
transmitted over open networks.
In addition, SIP entities should be careful not to relay the telephony
signalling or settlement information to unauthorized third parties.
4. Acknowledgement
This document is based on input from Matthew Cannon, Steve Donovan, Ike
Elliott, Francois Menard, Dave Oran, Mike Ramalho, Henning
Schulzrinne, Henry Sinnreich, Dean Willis, and Eric Zimmerer.
5. References
[1] Handley, M, Jacobson, V., "SDP: Session Description Protocol", RFC
2327, April 1998.
[2] Handley, M., Schooler, E., and H. Schulzrinne, "Session Initiation
Protocol (SIP)", Work in Progress.
[3] Crocker, D., P. Overell, "Augmented BNF for Syntax Specifications:
ABNF", RFC 2234, November 1997.
[4] Freed, N., J. Klensin, J. Postel. "Multipurpose Internet Mail
Extensions (MIME) Part Four: Registration Procedures." RFC 2048,
November 1996.
6. Authors' Addresses
Christian Huitema
Bellcore
MCC 1J236B
445 South Street
Morristown, NJ 07960
U.S.A.
Phone: +1 973-829-4266
EMail: huitema@bellcore.com
Huitema [Page 4]
