Internet Engineering Task Force Mark Watson Internet Draft Nortel Networks, UK Document: draft-watson-sip-isup-mime-00.txt October 1999 Expires: April 2000 MIME type for ISUP messages Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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 made obsolete 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 1. Abstract This document proposes the definition of an application/isup media type, according to the rules defined in RFC 2048 [1], which will allow the carriage of ITU-T Signalling System No. 7 ISDN User Part messages within MIME compliant message bodies. 2. Introduction Signalling System No. 7 is defined by the ITU-T for use between ISDN and Telephony exchanges for call control and support of supplementary services and features within ISDNs and PSTNs. The ISDN User Part supports the standard features of ISDNs and has also been extended by regional and national standards bodies throughout the world to support local and regional PSTN and ISDN services. In order that these same services may be supported on calls which traverse an Internet Protocol environment it is necessary to carry these messages between call control entities (e.g. `SoftSwitches'). This draft defines a MIME type which could be used in association with an Internet Protocol based basic call control protocol (such as SIP [2]) to achieve this. 3. Regional and National Variants of ISUP Watson Expires April 2000 1 draft-watson-sip-isup-mime-00.txt October 1999 Many national and regional standards bodies around the world have defined extensions to ISUP which provide for support of local and regional ISDN and PSTN services. An ISUP standard with such extensions is known as a `variant'. There is therefore a need for the entity receiving the ISUP message to know the variant it is receiving in order to process it correctly. The simplest way to achieve this is by including some kind of `variant' indication within a parameter to the MIME type/sub-type. This could be a single parameter and names for the variants could be registered as required. However, the above approach has a key disadvantage in that it is necessary for the originating SoftSwitch to have static knowledge of the ISUP variants supported by all the terminating softswitchs it may directly communicate with. This is not an unusual requirement in an ISDN/PSTN network, where the connections to terminating switches are physical TDM circuits. However in an IP domain, the relationships between originating and terminating switch/UA are likely to be much more dynamic. In particular, the actual terminating softswitch may be identified by an intermediate SIP Proxy, and not by the originating switch at all. It may therefore be impossible for the originating node to ensure that the variant it sends out will be understood by the terminating node. It is also not possible to define a `least common denominator' to be used between softswitchs since this would exclude the case that the variant is understood by the terminating node and that national/regional extensions are required for the call. Fortunately, the structure of ISUP and its variants offers a simple solution to this problem. Since the definition of `White Book' ISUP in 1992, the protocol has included a `Compatibility Mechanism' which allows new parameters to be accompanied by `Instruction Indicators' detailing how they should be handled by nodes which do not understand the new information. In particular, parameters and messages introduced as part of a regional/national variant of ISUP will be accompanied by such indicators and therefore interworking between this national variant and the `base' protocol can be carried out by a node which supports only the `base' from which the national variant is derived. In fact, even if the Compatibility Mechanism is not used, it is possible to tell from the parameter name when it is an extension Watson Expires April 2000 2 draft-watson-sip-isup-mime-00.txt October 1999 introduced by a national standards body, as these names are allocated from a particular range of values. To support interworking from an unknown variant to the base ISUP, it is necessary to indicate to the terminating switch not only the variant name, but also the `base' version of ISUP from which it is derived. 4. `Base' versions of ISUP ISUP is ultimately defined by the ITU-T and all variants of ISUP are derived from ITU-T Recommendations. For the purpose described here is necessary only to make the distinction between those ISUP recommendations that include the Compatibility Mechanism and those which do not i.e. between `Blue Book' ISUP and `White Book' and later versions. In addition, regional standards bodies have defined extensions to ISUP (and perhaps more significantly, subsets to be used in that region). It will be of necessary for a node which understands ETSI ISUP for instance to be aware that an incoming unrecognised ISUP is based on ETSI in order to interworking it to ETSI ISUP, and not just the base ITU-T version. The node may wish to do this to support regional regulatory requirments which are defined as part of the regional enhancements to ISUP. The regional ISUP versions therefore also need to be identified. 5. The application/isup media type ISUP messages are composed of arbitrary binary data. The best way to encode these would be to use binary encoding. This is in conformance with the restrictions imposed on the use of binary data for MIME (RFC 2045 [3]). It should be noted that the rules mentioned in the RFC 2045 apply to Internet mail messages and not to SIP messages. Binary has been preferred over Base64 encoding because the latter would only result in adding bulk to the encoded messages as well as prove costly in terms of processing power. The binary data begins with the ISUP Message Type Code and continues as defined in Figure 3/Q.763 [5]. This media type is defined by the following information: Media type name: application Media subtype name: isup Required parameters: none Optional parameters: base, version, variant Encoding scheme: binary Security considerations: See section 5. Watson Expires April 2000 3 draft-watson-sip-isup-mime-00.txt October 1999 Note: It is mandatory for SoftSwitches to specify the `base' of the ISUP message. Proxies, redirect servers, etc., have no need to process/specify this information. Table 1 is a partial list of the values of the `base' parameter and the values of `version' which are applicable to each. Values of the `variant' parameter should be registered by the standards body responsible for defining the variant. `base' `version' Specification --------------------------------------------- bluebook etsi ETS 300 121 ansi ? whitebook etsi EN 300 356 ansi ? gr317 Bellcore GR317 The following is an example of a typical header:- Content-Type: application/ISUP; base=whitebook; version=etsi Content-Transfer-Encoding: binary 6. Illustrative example SIP message format requires a Request line followed by Header lines followed by a CRLF separator followed by the message body. To illustrate the use of the 'application/isup' media type, below is an INVITE message which has the originating SDP information and an encapsulated ISUP IAM. Note that the two payloads are demarcated by the boundary parameter (specified in RFC 2046 [4]) which in the example has the value "unique-boundary-1". This is part of the specification of MIME multipart and is not related to the 'application/isup' media type. INVITE sip:01628434456@dcs1.nortelnetworks.com SIP/2.0 From: sip:01628434141@dcs3.nortelnetworks.com To: sip:01628434456@dcs1.nortelnetworks.com Call-ID: DCS22101999121100000001@dcs1.nortelnetworks.com Content-Type: Application/Multipart Content-Length: 327 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=unique-boundary-1 --unique-boundary-1 Content-Type: application/SDP; charset=ISO-10646 v=0 Watson Expires April 2000 4 draft-watson-sip-isup-mime-00.txt October 1999 o=mwatson 2890844526 2890842807 IN IP4 47.96.4.192 s=SDP seminar c=IN IP4 MG122.nortelnetworks.com t= 2873397496 2873404696 m=audio 9092 RTP/AVP 0 3 4 --unique-boundary-1 Content-type:application/isup; base=whitebook; version=etsi; variant=uk21 Content-Transfer-Encoding: binary 01 00 00 01 0A 00 02 09 07 03 10 16 28 43 44 56 FE 02 01 00 39 02 FE BO 00 --unique-boundary-1-- 7. Security Considerations The security mechanisms described in RFC 2543 (SIP - Session Initiation Protocol) should suffice. No new security considerations are thought necessary. 9. References [1] Freed, Klensin, Postel, "Multipart Internet Mail Extensions (MIME) Part Four: Registration Procedures" RFC 2048, Internet Engineering Task Force, November 1996. [2] Handley, Schulzrinne, Schooler and Rosenberg, "Session Initiation Protocol (SIP)" RFC 2543, Internet Engineering Task Force, March 1999. [3] Freed, Borenstein, "Multipart Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies" RFC 2045, Internet Engineering Task Force, November 1996. [4] Freed, Borenstein, "Multipart Internet Mail Extensions (MIME) Part Two: Media Types" RFC 2046, Internet Engineering Task Force, November 1996. [5] ITU-T Recommendation Q.763 10. Acknowledgments Watson Expires April 2000 5 draft-watson-sip-isup-mime-00.txt October 1999 This draft has drawn on draft-zimmerer-mmusic-sip-isup-mime-00.txt by Eric Zimmerer. 11. Author's Addresses Mark Watson Nortel Networks Foundation Park Maidenhead, Berks, SL6 3UD, UK Phone: +44 1628 434456 Email: mwatson@nortelnetworks.com Watson Expires April 2000 6