One document matched: draft-ietf-mmusic-sip-multipart-00.txt

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]