idnits 2.17.1 draft-watson-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 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 == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 282 lines 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. ** 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 176 has weird spacing: '...itebook ets...' -- 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 (October 1999) is 8959 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) ** 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) -- Possible downref: Non-RFC (?) normative reference: ref. '5' Summary: 10 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Mark Watson 2 Internet Draft Nortel Networks, UK 3 Document: draft-watson-sip-isup-mime-00.txt October 1999 4 Expires: April 2000 6 MIME type for ISUP messages 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026 [1]. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. Internet-Drafts are draft documents valid for a maximum of 17 six months and may be updated, replaced, or made obsolete by other 18 documents at any time. It is inappropriate to use Internet- Drafts 19 as reference material or to cite them other than as "work in 20 progress." 21 The list of current Internet-Drafts can be accessed at 22 http://www.ietf.org/ietf/1id-abstracts.txt 23 The list of Internet-Draft Shadow Directories can be accessed at 24 http://www.ietf.org/shadow.html. 26 1. Abstract 28 This document proposes the definition of an application/isup media 29 type, according to the rules defined in RFC 2048 [1], which will 30 allow the carriage of ITU-T Signalling System No. 7 ISDN User Part 31 messages within MIME compliant message bodies. 33 2. Introduction 35 Signalling System No. 7 is defined by the ITU-T for use between ISDN 36 and Telephony exchanges for call control and support of 37 supplementary services and features within ISDNs and PSTNs. The ISDN 38 User Part supports the standard features of ISDNs and has also been 39 extended by regional and national standards bodies throughout the 40 world to support local and regional PSTN and ISDN services. 42 In order that these same services may be supported on calls which 43 traverse an Internet Protocol environment it is necessary to carry 44 these messages between call control entities (e.g. `SoftSwitches'). 46 This draft defines a MIME type which could be used in association 47 with an Internet Protocol based basic call control protocol (such as 48 SIP [2]) to achieve this. 50 3. Regional and National Variants of ISUP 52 Watson Expires April 2000 1 53 draft-watson-sip-isup-mime-00.txt October 1999 55 Many national and regional standards bodies around the world have 56 defined extensions to ISUP which provide for support of local and 57 regional ISDN and PSTN services. An ISUP standard with such 58 extensions is known as a `variant'. 60 There is therefore a need for the entity receiving the ISUP message 61 to know the variant it is receiving in order to process it 62 correctly. 64 The simplest way to achieve this is by including some kind of 65 `variant' indication within a parameter to the MIME type/sub-type. 66 This could be a single parameter and names for the variants could be 67 registered as required. 69 However, the above approach has a key disadvantage in that it is 70 necessary for the originating SoftSwitch to have static knowledge of 71 the ISUP variants supported by all the terminating softswitchs it 72 may directly communicate with. 74 This is not an unusual requirement in an ISDN/PSTN network, where 75 the connections to terminating switches are physical TDM circuits. 76 However in an IP domain, the relationships between originating and 77 terminating switch/UA are likely to be much more dynamic. 79 In particular, the actual terminating softswitch may be identified 80 by an intermediate SIP Proxy, and not by the originating switch at 81 all. It may therefore be impossible for the originating node to 82 ensure that the variant it sends out will be understood by the 83 terminating node. 85 It is also not possible to define a `least common denominator' to be 86 used between softswitchs since this would exclude the case that the 87 variant is understood by the terminating node and that 88 national/regional extensions are required for the call. 90 Fortunately, the structure of ISUP and its variants offers a simple 91 solution to this problem. Since the definition of `White Book' ISUP 92 in 1992, the protocol has included a `Compatibility Mechanism' which 93 allows new parameters to be accompanied by `Instruction Indicators' 94 detailing how they should be handled by nodes which do not 95 understand the new information. 97 In particular, parameters and messages introduced as part of a 98 regional/national variant of ISUP will be accompanied by such 99 indicators and therefore interworking between this national variant 100 and the `base' protocol can be carried out by a node which supports 101 only the `base' from which the national variant is derived. 103 In fact, even if the Compatibility Mechanism is not used, it is 104 possible to tell from the parameter name when it is an extension 106 Watson Expires April 2000 2 107 draft-watson-sip-isup-mime-00.txt October 1999 109 introduced by a national standards body, as these names are 110 allocated from a particular range of values. 112 To support interworking from an unknown variant to the base ISUP, it 113 is necessary to indicate to the terminating switch not only the 114 variant name, but also the `base' version of ISUP from which it is 115 derived. 117 4. `Base' versions of ISUP 119 ISUP is ultimately defined by the ITU-T and all variants of ISUP are 120 derived from ITU-T Recommendations. For the purpose described here 121 is necessary only to make the distinction between those ISUP 122 recommendations that include the Compatibility Mechanism and those 123 which do not i.e. between `Blue Book' ISUP and `White Book' and 124 later versions. 126 In addition, regional standards bodies have defined extensions to 127 ISUP (and perhaps more significantly, subsets to be used in that 128 region). It will be of necessary for a node which understands ETSI 129 ISUP for instance to be aware that an incoming unrecognised ISUP is 130 based on ETSI in order to interworking it to ETSI ISUP, and not just 131 the base ITU-T version. The node may wish to do this to support 132 regional regulatory requirments which are defined as part of the 133 regional enhancements to ISUP. 135 The regional ISUP versions therefore also need to be identified. 137 5. The application/isup media type 139 ISUP messages are composed of arbitrary binary data. The best way to 140 encode these would be to use binary encoding. This is in conformance 141 with the restrictions imposed on the use of binary data for MIME 142 (RFC 2045 [3]). It should be noted that the rules mentioned in the 143 RFC 2045 apply to Internet mail messages and not to SIP messages. 144 Binary has been preferred over Base64 encoding because the latter 145 would only result in adding bulk to the encoded messages as well as 146 prove costly in terms of processing power. 148 The binary data begins with the ISUP Message Type Code and continues 149 as defined in Figure 3/Q.763 [5]. 151 This media type is defined by the following information: 153 Media type name: application 154 Media subtype name: isup 155 Required parameters: none 156 Optional parameters: base, version, variant 157 Encoding scheme: binary 158 Security considerations: See section 5. 160 Watson Expires April 2000 3 161 draft-watson-sip-isup-mime-00.txt October 1999 163 Note: It is mandatory for SoftSwitches to specify the `base' of 164 the ISUP message. Proxies, redirect servers, etc., have no need to 165 process/specify this information. 167 Table 1 is a partial list of the values of the `base' parameter and 168 the values of `version' which are applicable to each. Values of the 169 `variant' parameter should be registered by the standards body 170 responsible for defining the variant. 172 `base' `version' Specification 173 --------------------------------------------- 174 bluebook etsi ETS 300 121 175 ansi ? 176 whitebook etsi EN 300 356 177 ansi ? 178 gr317 Bellcore GR317 180 The following is an example of a typical header:- 182 Content-Type: application/ISUP; base=whitebook; version=etsi 183 Content-Transfer-Encoding: binary 185 6. Illustrative example 187 SIP message format requires a Request line followed by Header lines 188 followed by a CRLF separator followed by the message body. To 189 illustrate the use of the 'application/isup' media type, below is an 190 INVITE message which has the originating SDP information and an 191 encapsulated ISUP IAM. 193 Note that the two payloads are demarcated by the boundary parameter 194 (specified in RFC 2046 [4]) which in the example has the value 195 "unique-boundary-1". This is part of the specification of MIME 196 multipart and is not related to the 'application/isup' media type. 198 INVITE sip:01628434456@dcs1.nortelnetworks.com SIP/2.0 199 From: sip:01628434141@dcs3.nortelnetworks.com 200 To: sip:01628434456@dcs1.nortelnetworks.com 201 Call-ID: DCS22101999121100000001@dcs1.nortelnetworks.com 202 Content-Type: Application/Multipart 203 Content-Length: 327 205 MIME-Version: 1.0 206 Content-Type: multipart/mixed; boundary=unique-boundary-1 208 --unique-boundary-1 209 Content-Type: application/SDP; charset=ISO-10646 211 v=0 213 Watson Expires April 2000 4 214 draft-watson-sip-isup-mime-00.txt October 1999 216 o=mwatson 2890844526 2890842807 IN IP4 47.96.4.192 217 s=SDP seminar 218 c=IN IP4 MG122.nortelnetworks.com 219 t= 2873397496 2873404696 220 m=audio 9092 RTP/AVP 0 3 4 222 --unique-boundary-1 223 Content-type:application/isup; base=whitebook; version=etsi; 224 variant=uk21 225 Content-Transfer-Encoding: binary 227 01 00 00 01 0A 00 02 09 07 03 10 16 28 43 44 56 FE 02 01 00 39 228 02 FE BO 00 230 --unique-boundary-1-- 232 7. Security Considerations 234 The security mechanisms described in RFC 2543 (SIP - Session 235 Initiation Protocol) should suffice. No new security considerations 236 are thought necessary. 238 9. References 240 [1] Freed, Klensin, Postel, "Multipart Internet Mail Extensions 241 (MIME) 242 Part Four: Registration Procedures" RFC 2048, Internet Engineering 243 Task Force, November 1996. 245 [2] Handley, Schulzrinne, Schooler and Rosenberg, "Session 246 Initiation 247 Protocol (SIP)" RFC 2543, Internet Engineering Task Force, March 248 1999. 250 [3] Freed, Borenstein, "Multipart Internet Mail Extensions (MIME) 251 Part 252 One: Format of Internet Message Bodies" RFC 2045, Internet 253 Engineering 254 Task Force, November 1996. 256 [4] Freed, Borenstein, "Multipart Internet Mail Extensions (MIME) 257 Part 258 Two: Media Types" RFC 2046, Internet Engineering Task Force, 259 November 260 1996. 262 [5] ITU-T Recommendation Q.763 264 10. Acknowledgments 266 Watson Expires April 2000 5 267 draft-watson-sip-isup-mime-00.txt October 1999 269 This draft has drawn on draft-zimmerer-mmusic-sip-isup-mime-00.txt 270 by Eric Zimmerer. 272 11. Author's Addresses 274 Mark Watson 275 Nortel Networks 276 Foundation Park 277 Maidenhead, Berks, SL6 3UD, UK 278 Phone: +44 1628 434456 279 Email: mwatson@nortelnetworks.com 281 Watson Expires April 2000 6