idnits 2.17.1 draft-ietf-mmusic-sip-multipart-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 5, 1999) is 9030 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 165, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 168, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 171, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 174, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2327 (ref. '1') (Obsoleted by RFC 4566) -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Obsolete normative reference: RFC 2234 (ref. '3') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2048 (ref. '4') (Obsoleted by RFC 4288, RFC 4289) Summary: 11 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Christian Huitema 3 INTERNET DRAFT Bellcore 4 February 5, 1999 Expires August 5, 1999 5 7 The multipart/sip-id media type 9 Status of this document 11 This document is an Internet-Draft and is in full conformance with all 12 provisions of Section 10 of RFC 2026. 14 Internet-Drafts are working documents of the Internet Engineering Task 15 Force (IETF), its areas, and its working groups. Note that other groups 16 may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet- Drafts as reference material 21 or to cite them other than as "work in progress." 23 To view the entire list of current Internet-Drafts, please check the 24 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 25 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), 26 ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), 27 ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 29 Abstract 31 This document proposes the definition of a multipart/sip-id media type, 32 according to the rules defined in RFC 2048. This media type is intended 33 to be carried by the session invitation protocol messages, when these 34 messages are used to route calls between Internet Telephony domains. 36 1. Motivation 38 There have been proposals to use the "session invitation protocol" to 39 route calls between Internet Telephony domains. It has been observed 40 that these gateways need more information than just the "session 41 description" carried in standard session invitation protocol messages. 42 Specifically: 44 Internet draft The multipart/sip-id media type February 2, 1999 46 * In a situation where a session originates from, or is possibly 47 going intended to terminate to, a classical switched telephony net- 48 work, it may be useful or even necessary to carry the information 49 that was used in generating the Internet Telephony signaling mes- 50 sage as part of the session setup message. This draft proposes a 51 method for tunneling the original signalling information between 52 the "ingress" and "egress" gateways, thus avoiding loss of informa- 53 tion. 55 * Internet Telephony signaling across administrative domains will 56 probably not be practical unless deployed in conjunction to an 57 Electronic Commerce infrastructure for Internet bandwidth and for 58 brokered access to regulated legacy network elements. 60 The content of the session invitation protocol messages is identified by 61 a media type. In the case of domain interconnection, we propose to 62 replace to carry session description, telephony signalling and settle- 63 ment information in a "multipart" content type, of type "multipart/sip- 64 id" (SIP Inter-Domain). The multipart/sip-id will includes up to three 65 content parts: 67 * A session description part, typically of type "application/sdp", 69 * A telephony signalling part, typically of type "application/ISUP", 71 * A settlement information part, for example of type 72 "application/otp". 74 Each of these content types will be identified by a regularly registered 75 media type, such as for example "application/sdp", "application/ISUP" or 76 "application/otp". However, we do not expect all SIP implementations to 77 be able to recognize all possible telephone signallin protocols, or all 78 possible settlement procedures. The multipart format will identify the 79 position and role of the various content parts, so that entities could 80 if necessary focus on the part that they need to understand (e.g., the 81 session description) and ignore the other parts. 83 This memo proposes a definition of an "multipart/sip-id" media type 84 according to the rules defined in RFC 2048. It does not attempt to 85 define the telephony signalling or settlement parts. 87 2. The multipart/sip-id media type 89 The structure of the "sip-id" multipart follows the basic rules for mul- 90 tipart media types defined in RFC 2046. The Multipart/sip-id type is 91 defined as follow: 93 (1) MIME type name: multipart 94 Internet draft The multipart/sip-id media type February 2, 1999 96 (2) MIME subtype name: sip-id 98 (3) Required parameters: boundary 100 (4) Optional parameters: content 102 (5) Security considerations: see section 5. 104 The multipart/sip-id content type contains up to three body parts: 106 * The "session description" body part, if present, contains a valid 107 session description. 109 * The "telephony signalling" body part, if present, contains a copy 110 of the signalling message that triggered the SIP message. 112 * The "payment information" body part, if present, contains informa- 113 tion relevant to the payment or the settlement of the call. 115 Each body part contains a valid MIME media type. The role of the body 116 parts that are present in a given sip-id multipart is specified by the 117 content parameter. 119 The content token for the protocol parameter is "content", i.e., 121 parameter = "content" "=" value 123 The value token is comprised of the roles of the body parts that are 124 present: 126 value = DQUOTE role-list DQUOTE 127 role-list = role / role-list "," role 128 role = session-description / 129 telephony-signalling / 130 payment-information 131 session-description = "sd" 132 telephony-signalling = "ts" 133 payment-information = "pi" 135 If a session-description is present, it should be encoded as the first 136 body part. The telephony signalling should come next (or first, if 137 there is no session description.) The payment information should come 138 last. 140 The content token is optional. If the content token is absent, the 141 first body part is assumed to be a session description, the second body 142 part, if present, is assumed to be a telephone signalling message, and 143 Internet draft The multipart/sip-id media type February 2, 1999 145 the third, if present, is assumed to be a payment information. 147 3. Security considerations 149 Telephony signalling and settlement information often contain sensitive 150 or critical information. The security provisions of the Session Invita- 151 tion Protocol should be use to protect these data when they are 152 transmitted over open networks. 154 In addition, SIP entities should be careful not to relay the telephony 155 signalling or settlement information to unauthorized third parties. 157 4. Acknowledgement 159 This document is based on input from Matthew Cannon, Steve Donovan, Ike 160 Elliott, Francois Menard, Dave Oran, Mike Ramalho, Henning 161 Schulzrinne, Henry Sinnreich, Dean Willis, and Eric Zimmerer. 163 5. References 165 [1] Handley, M, Jacobson, V., "SDP: Session Description Protocol", RFC 166 2327, April 1998. 168 [2] Handley, M., Schooler, E., and H. Schulzrinne, "Session Initiation 169 Protocol (SIP)", Work in Progress. 171 [3] Crocker, D., P. Overell, "Augmented BNF for Syntax Specifications: 172 ABNF", RFC 2234, November 1997. 174 [4] Freed, N., J. Klensin, J. Postel. "Multipurpose Internet Mail 175 Extensions (MIME) Part Four: Registration Procedures." RFC 2048, 176 November 1996. 178 6. Authors' Addresses 180 Christian Huitema 181 Bellcore 182 MCC 1J236B 183 445 South Street 184 Morristown, NJ 07960 185 U.S.A. 187 Phone: +1 973-829-4266 188 EMail: huitema@bellcore.com