idnits 2.17.1 draft-ietf-mmusic-sip-isup-mime-00.txt: ** The Abstract section seems to be numbered 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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 4 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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. ** There are 33 instances of lines with control characters in the document. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 30 has weird spacing: '...ocument propo...' == Line 69 has weird spacing: '... if the parti...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2048 (ref. '1') (Obsoleted by RFC 4288, RFC 4289) ** Obsolete normative reference: RFC 2543 (ref. '2') (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Eric Zimmerer 2 Internet Draft Level 3 Communications 3 draft-ietf-mmusic-sip-isup-mime-00.txt Aparna Vemuri 4 July 1999 Level 3 Communications 5 Expires: January 2000 7 The SIP ISUP/MIME type 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance 12 with all provisions of Section 10 of RFC2026. Internet-Drafts are 13 working documents of the Internet Engineering Task Force (IETF), its 14 areas, and its working groups. Note that other groups may also 15 distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 1. Abstract 30 This document proposes the definition of an application/ISUP media 31 type, according to the rules defined in RFC 2048 [1]. 33 2. Introduction 35 ISUP (ISDN User part) defined in the ITU-T recommendations Q.761-4 is 36 a signaling protocol used between telephony switches. There exists a 37 need to transport ISUP messages between SoftSwitches as being part of 38 the payload of SIP [2] messages. The following discussion is specific 39 to this usage and would not apply to the transportation of ISUP 40 messages in other applications. 42 3. The application/ISUP media type 44 The ISUP messages are composed of arbitrary binary data. The best way 45 to encode these would be to use binary encoding. This is in 46 conformance with the restrictions imposed on the use of binary data 47 conformance with the restrictions imposed on the use of binary data 48 for MIME (RFC 2045 [3]). It should be noted that the rules mentioned 49 in the RFC 2045 apply to Internet mail messages and not to SIP 50 messages. Binary has been preferred over Base64 encoding because 51 the latter would only result in adding bulk to the encoded messages 52 as well as prove costly in terms of processing power. 53 This media type is defined by the following information: 55 Media type name: application 56 Media subtype name: ISUP 57 Required parameters: none 58 Optional parameters: version 59 Encoding scheme: binary 60 Security considerations: See section 5. 62 Note: It is mandatory for SoftSwitches to specify the 'version' of 63 the ISUP message. Proxies, redirect servers, etc., have no need to 64 process/specify this information. 66 The use of the 'version' parameter allows differentiation between 67 different ISUP variants. This enables the terminating SoftSwitch (also 68 known as media gateway) to recognize and parse the message correctly, 69 or (possibly) to reject the message if the particular ISUP variant is 70 not supported. The idea here is to allow to specify a preference of 71 version, so that the following scenarios are possible: "I only like 72 application/isup;version=lcd" or "I accept application/isup (but don't 73 really know the details; I just pass them on to some other tool that 74 displays/munges them)". 75 The following is how a typical header would look:- 77 Content-Type: application/ISUP 78 Version: ETSIv1 79 Content-Transfer-Encoding: binary 81 Table 1 is a partial list of protocol versions supported by the 82 'application/ISUP' media type. 84 Version Protocol 85 ------- -------- 86 ANSI-ISUP ANSI ISUP 87 ETSI-ISUP ETSI ISUP 88 GR-317 Bellcore ISUP GR-317 89 BTNUP BT NUP 90 R2 R2 91 4. Illustrative example 93 SIP message format requires a Request line followed by Header lines 94 followed by a CRLF separator followed by the message body. To 95 illustrate the use of the 'application/ISUP' media type, below is 96 an INVITE message which has the originating SDP information and 97 an encapsulated ISUP IAM. 99 Note that the two payloads are demarcated by the boundary parameter 100 (specified in RFC 2046 [4]) which in the example has the value 101 "unique-boundary-1". This is part of the specification of MIME 102 multipart and is not related to the 'application/ISUP' media type. 104 INVITE sip:13039263142@Den1.level3.com SIP/2.0 105 From: sip:13034513355@den3.level3.com 106 To: sip:13039263142@Den1.level3.com 107 Call-ID: DEN1231999021712095500999@Den1.level3.com 108 Content-Type: Application/ Multipart 109 Content-Length: 327 111 MIME-Version: 1.0 112 Content-Type: multipart/mixed; boundary=unique-boundary-1 114 --unique-boundary-1 115 Content-Type: application/SDP; charset=ISO-10646 117 v=0 118 o=ezimmerer 2890844526 2890842807 IN IP4 126.16.64.4 119 s=SDP seminar 120 c=IN IP4 MG122.level3.com 121 t= 2873397496 2873404696 122 m=audio 9092 RTP/AVP 0 3 4 124 --unique-boundary-1 125 Content-type:application/ISUP 126 Version:ETSIv1 127 Content-Transfer-Encoding: binary 129 89 8b 0e 95 1e 1e 1e 06 26 05 0d f5 01 06 10 04 00 131 --unique-boundary-1-- 132 5. Security considerations 134 The security mechanisms described in RFC 2543 (SIP - Session 135 Initiation Protocol) should suffice. No new security considerations 136 are thought necessary. 138 6. Authors 140 Eric Zimmerer 141 Level 3 Communications 142 Louisville, CO, USA 143 Phone: 303-926-3142 144 EMail: eric.zimmerer@level3.com 146 Aparna Vemuri 147 Level 3 Communications 148 Louisville, CO, USA 149 Phone: 303-926-3768 150 EMail: aparna.vemuri@level3.com 152 7. References 154 [1] Freed, Klensin, Postel, "Multipart Internet Mail Extensions (MIME) 155 Part Four: Registration Procedures" RFC 2048, Internet Engineering 156 Task Force, November 1996. 158 [2] Handley, Schulzrinne, Schooler and Rosenberg, "Session Initiation 159 Protocol (SIP)" RFC 2543, Internet Engineering Task Force, March 1999. 161 [3] Freed, Borenstein, "Multipart Internet Mail Extensions (MIME) Part 162 One: Format of Internet Message Bodies" RFC 2045, Internet Engineering 163 Task Force, November 1996. 165 [4] Freed, Borenstein, "Multipart Internet Mail Extensions (MIME) Part 166 Two: Media Types" RFC 2046, Internet Engineering Task Force, November 167 1996.