Internet Engineering Task Force Christian Huitema INTERNET DRAFT Bellcore February 5, 1999 Expires August 5, 1999 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]