Internet Engineering Task Force Eric Zimmerer Internet Draft ipVerse, Inc. draft-ietf-sip-isup-mime-03.txt Aparna Vemuri June 2000 Level 3 Communications Expires: Dec 2000 L. Ong M. Zonoun M. Watson Nortel Networks MIME media types for ISUP and QSIG Objects Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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." 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. Abstract This document describes MIME types for application/ISUP and application/QSIG objects for use in SIP applications, according to the rules defined in RFC 2048 [1]. These types can be used to identify ISUP and QSIG objects within a SIP message such as INVITE or INFO, as might be implemented when using SIP between legacy systems. 1. Introduction ISUP (ISDN User part) defined in the ITU-T recommendations Q.761-4 is a signaling protocol used between telephony switches. There exists a need to transport ISUP-encoded signaling information between SIP entities as part of the payload of SIP [2] messages, in order to access ISUP-based legacy service logic. For example, this may be implemented when using SIP to control sessions between two systems that support legacy telephony services or gateway between legacy systems. QSIG is the analogous signaling protocol used between private branch exchanges to support calls within private telephony networks. There is a similar need to transport QSIG-encoded signaling information between SIP entities to support legacy services or gateway between legacy systems. Zimmerer, Vemuri draft-ietf-sip-isup-mime-03.txt [Page 1]
Internet Draft ISUP and QSIG/MIME types May 2000 The following discussion is specific to this usage and would not apply to the transportation of ISUP or QSIG messages in other applications. These media types are intended for ISUP or QSIG application information that is used within the context of a SIP session, and not as general purpose transport of SCN signaling. The definition of media types for ISUP and QSIG application information does not address fully how the entities exchanging messages determine or negotiate compatibility. It is assumed that this is addressed by alternative means such as configuration or routing protocols. It is assumed in this document that the processing of ISUP and QSIG information is in addition to the standard SIP processing, and that no interworking of SIP and ISUP or QSIG signaling is required. This is intended to be an IETF approved MIME type, and to be defined through an RFC. NOTE: usage of Q.SIG within SIP is neither endorsed nor recommended as a result of this MIME registration. 3. Proposed new media types ISUP and QSIG messages are composed of arbitrary binary data that is transparent to SIP processing. The best way to encode these is 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 and possibly be more costly in terms of processing power. 3.1 ISUP Media Type This media type is defined by the following information: Media type name: application Media subtype name: ISUP Required parameters: version Optional parameters: base Encoding scheme: binary Security considerations: See section 5. The ISUP message is encapsulated beginning with the Message Type Code (i.e., omitting Routing Label and Circuit ID Code). Note: It is mandatory for clients to specify the 'version' of the ISUP message. Proxies, redirect servers, etc., have no need to process/specify this information. The use of the 'version' parameter allows differentiation Zimmerer, Vemuri draft-ietf-sip-isup-mime-03.txt [Page 2]
Internet Draft ISUP and QSIG/MIME types June 2000 between different base ISUP variants. This enables a client such as a SoftSwitch/Media Gateway Controller to recognize and parse the message correctly, or (possibly) to reject the message if the particular ISUP variant is not supported. The idea here is to allow to specify a preference of version, so that the following scenarios are possible: "I only like application/isup;version=lcd" or "I accept application/isup (but don't really know the details; I just pass them on to some other tool that displays/munges them)". If not specified, the default version is assumed to be ITU-T ISUP 1992. The 'base' parameter provides identification of a base regional variant of ISUP that can be used to process the ISUP body. This may be used, for example, to identify that the message can be processed using ITU-T 1992 ISUP processing, including support of the forward compatibility mechanism. The following is how a typical header would look: Content-Type: application/ISUP; version=uk21; base=etsi121 Content-Transfer-Encoding: binary Table 1 is a partial list of protocol base versions supported by the 'application/ISUP' media type, and whether they support the forward compatibility mechanism defined in later versions of ISUP. base protocol compatibility itu-t88 ITU-T Q.761-4 (1988) no itu-t92+ ITU-T Q.761-4 (1992) yes ansi88 ANSI T1.113-1988 no etsi121 ETS 300 121 no etsi356 ES 300 356 yes gr317 BELLCORE GR-317 no ttc87 JT-Q761-4(1987-1992) no ttc93+ JT-Q761-4(1993-) yes 3.2 QSIG Media Type The application/QSIG media type is defined by the following information: Media type name: application Media subtype name: QSIG Required parameters: none Optional parameters: version Encoding scheme: binary Security considerations: See section 5. Zimmerer, Vemuri draft-ietf-sip-isup-mime-03.txt [Page 3]
Internet Draft ISUP and QSIG/MIME types June 2000 The use of the 'version' parameter allows identification of different QSIG variants. This enables the terminating Connection Server to recognize and parse the message correctly, or (possibly) to reject the message if the particular QSIG variant is not supported. The following is how a typical header would look:- Content-Type: application/QSIG; version=iso Content-Transfer-Encoding: binary Table 2 is a list of protocol versions supported by the 'application/QSIG' media type. version protocol ------- -------- iso ISO/IEC 11572 (Basic Call) and ISO/IEC 11582 (Generic Function) 4. Illustrative examples 4.1 ISUP 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:13039263142@Den1.level3.com SIP/2.0 From: sip:13034513355@den3.level3.com To: sip:13039263142@Den1.level3.com Call-ID: DEN1231999021712095500999@Den1.level3.com Content-Length: 385 Content-Type: multipart/mixed; boundary=unique-boundary-1 CSeq: 8348 INVITE MIME-Version: 1.0 --unique-boundary-1 Content-Type: application/SDP; charset=ISO-10646 v=0 o=ezimmerer 2890844526 2890842807 IN IP4 126.16.64.4 s=SDP seminar c=IN IP4 MG122.level3.com t= 2873397496 2873404696 m=audio 9092 RTP/AVP 0 3 4 Zimmerer, Vemuri draft-ietf-sip-isup-mime-03.txt [Page 4]
Internet Draft ISUP and QSIG/MIME types June 2000 --unique-boundary-1 Content-type:application/ISUP; version=uk21; base=etsi121 01 00 49 00 00 03 02 00 07 04 10 00 33 63 21 43 00 00 03 06 0d 03 80 90 a2 07 03 10 03 63 53 00 10 0a 07 03 10 27 80 88 03 00 00 89 8b 0e 95 1e 1e 1e 06 26 05 0d f5 01 06 10 04 00 --unique-boundary-1-- Note: Since binary encoding is used for the ISUP payload, each byte is encoded as a byte, and not as a two-character hex representation. Hex digits were used in the draft because a literal encoding of those bytes would have been confusing and unreadable. 4.2 QSIG To illustrate the use of the 'application/QSIG' media type, below is an INVITE message which has the originating SDP information and an encapsulated QSIG SETUP message. 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/QSIG' media type. INVITE sip:14084955072@sc1.nortelnetworks.com SIP/2.0 From: sip:14085655675@sc10.nortelnetworks.com To: sip:14084955072@sc1.nortelnetworks.com Call-ID: 1231999021712095500999@sc12.nortelnetworks.com Content-Length: 358 Content-Type: multipart/mixed; boundary=unique-boundary-1 CSeq: 1234 INVITE MIME-Version: 1.0 --unique-boundary-1 Content-Type: application/SDP; charset=ISO-10646 v=0 o=audet 2890844526 2890842807 5 IN IP4 134.177.64.4 s=SDP seminar c=IN IP4 MG141.nortelnetworks.com t= 2873397496 2873404696 m=audio 9092 RTP/AVP 0 3 4 --unique-boundary-1 Content-type:application/QSIG; version=iso 08 02 55 55 05 04 02 90 90 18 03 a1 83 01 70 0a 89 31 34 30 38 34 39 35 35 30 37 32 --unique-boundary-1-- Zimmerer, Vemuri draft-ietf-sip-isup-mime-03.txt [Page 5]
Internet Draft ISUP and QSIG/MIME types June 2000 5. Security considerations Information contained in ISUP and QSIG bodies may include sensitive customer information, potentially requiring use of encryption. Security mechanisms are provided in RFC 2543 (SIP - Session Initiation Protocol) and should be used as appropriate for both the SIP message and the encapsulated ISUP or QSIG body. 6. Authors Eric Zimmerer L. Ong ipVerse, Inc. M. Zonoun 1901 Landings Drive Nortel Networks Mountain View, CA 94043, USA Santa Clara, CA 95054 Phone: 650-919-0648 long@nortelnetworks.com Email: ericz@ipverse.com mzonoun@nortelnetworks.com Aparna Vemuri M. Watson Level 3 Communications Nortel Networks Louisville, CO, USA Maidenhead, UK Phone: 303-926-3768 mwatson@nortelnetworks.com EMail: aparna.vemuri@level3.com 7. 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. This Internet Draft expires Dec 2000 Zimmerer, Vemuri draft-ietf-sip-isup-mime-03.txt [Page 6]
