Internet Engineering Task Force Eric Zimmerer Internet Draft ipVerse, Inc. draft-zimmerer-sip-isup-mime-00.txt Aparna Vemuri October 1999 Level 3 Communications Expires: April 2000 The SIP ISUP/MIME type 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. 1. Abstract This document proposes the definition of an application/ISUP media type, according to the rules defined in RFC 2048 [1]. 2. 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 messages between SoftSwitches as being part of the payload of SIP [2] messages. The following discussion is specific to this usage and would not apply to the transportation of ISUP messages in other applications. 3. The application/ISUP media type The 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 Zimmerer, Vemuri draft-zimmerer-sip-isup-mime-00.txt [Page 1] Internet Draft The SIP ISUP/MIME type Oct 1999 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. This media type is defined by the following information: Media type name: application Media subtype name: ISUP Required parameters: none Optional parameters: version Encoding scheme: binary Security considerations: See section 5. Note: It is mandatory for SoftSwitches 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 between different ISUP variants. This enables the terminating SoftSwitch (also known as media gateway) 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)". The following is how a typical header would look:- Content-Type: application/ISUP; Version=ETSI1 Content-Transfer-Encoding: binary Table 1 is a partial list of protocol versions supported by the 'application/ISUP' media type. Version Protocol ------- -------- ANSI ANSI ISUP ETSI1 ETSI ISUP v1 ETSI2 ETSI ISUP v2 GR317 Bellcore ISUP GR-317 Zimmerer, Vemuri draft-zimmerer-sip-isup-mime-00.txt [Page 2] Internet Draft The SIP ISUP/MIME type Oct 1999 4. 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: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: 377 Content-Type: multipart/mixed; boundary=unique-boundary-1 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 --unique-boundary-1 Content-type:application/ISUP; Version=ETSI1 Content-Transfer-Encoding: binary 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 Zimmerer, Vemuri draft-zimmerer-sip-isup-mime-00.txt [Page 3] Internet Draft The SIP ISUP/MIME type Oct 1999 used in the draft because a literal encoding of those bytes would have been confusing and unreadable. 5. Security considerations The security mechanisms described in RFC 2543 (SIP - Session Initiation Protocol) should suffice. No new security considerations are thought necessary. 6. Authors Eric Zimmerer ipVerse, Inc. 1901 Landings Drive Mountain View, CA 94043, USA Phone: 650-919-0648 Email: ericz@ipverse.com Aparna Vemuri Level 3 Communications Louisville, CO, USA Phone: 303-926-3768 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. Zimmerer, Vemuri draft-zimmerer-sip-isup-mime-00.txt [Page 4]