Network Working Group E. Zimmerer Request for Comments: 3204 Rankom, Inc. Category: Standards Track J. Peterson Neustar, Inc. A. Vemuri Qwest Communications L. Ong Ciena Networks F. Audet M. Watson M. Zonoun Nortel Networks December 2001 MIME media types for ISUP and QSIG Objects Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved.
AbstractThis document describes MIME types for application/ISUP and application/QSIG objects for use in SIP applications, according to the rules defined in RFC 2048. 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 in an environment where part of the call involves interworking to the PSTN.
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 in some environments. This document 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 non-SIP and SIP entities exchanging messages determine or negotiate compatibility. It is assumed that this is addressed by alternative means such as the configuration of the interworking functions. 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. RFC 2045 ). 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. section 5. The ISUP message is encapsulated beginning with the Message Type Code (i.e., omitting Routing Label and Circuit ID Code).
The use of the 'version' parameter allows network administrators to identify specific versions of ISUP that will be exchanged on a bilateral basis. This enables a particular client such as a SoftSwitch/Media Gateway Controller to recognize and parse the message correctly, or (possibly) to reject the message if the specified ISUP version is not supported. This specification places no constraints on the values that may be used in 'version'; these are left to the discretion of the network administrator. This 'version' could, for example, be used to identify a network- specific implementation of ISUP, e.g., X-NetxProprietaryISUPv3, or to identify a well-known standard version of ISUP, e.g., itu-t or ansi. A 'base' parameter can optionally be included in some cases (e.g., if the receiver may not recognize the 'version' string) to specify that the encapsulated ISUP can also be processed using the identified 'base' specification. Table 1 provides a list of 'base' values supported by the 'application/ISUP' media type, including whether or not the forward compatibility mechanism defined in ITU-T 1992 ISUP is supported. Table 1: ISUP 'base' values 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 ansi00 ANSI T1.113-2000 yes 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 The Content-Disposition header  may be included to describe how the encapsulated ISUP is to be processed, and in particular what the handling should be if the received Content-Type is not recognized. The default disposition-type for an ISUP message body is "signal". This type indicates that the body part contains signaling information associated with the session, but does not describe the session. Supplementing the description of the Content-Disposition header in , as well as any characterization of the Content-Disposition header in the SIP standard, is the following BNF describing disposition-types and disposition-params that may be used in the header of ISUP and QSIG MIME bodies.
Content-Disposition = "Content-Disposition" ":" disposition-type *( ";" disposition-param ) disposition-type = "signal" | disp-extension-token disposition-param = "handling" "=" ( "optional" | "required" | other-handling ) | generic-param other-handling = token disp-extension-token = token A full definition of the use of the "handling" parameter is given in the IANA Considerations section below. The following is how a typical header would look ('base' may be omitted): Content-Type: application/ISUP; version=nxv3; base=etsi121 Content-Disposition: signal; handling=optional section 5. 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. Table 2 is a list of protocol versions supported by the 'application/QSIG' media type. Table 2: QSIG versions version protocol ------- -------- iso ISO/IEC 11572 (Basic Call) and ISO/IEC 11582 (Generic Functional Protocol)
The following is how a typical header would look (Content-Disposition not included in this instance): Content-Type: application/QSIG; version=iso The default Content-Disposition disposition-type is "signal" as in an ISUP body part. The "handling" parameter described above can also be used for QSIG bodies. RFC 2046 ) 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 INVITE sip:13039263142@Den1.level3.com SIP/2.0 Via: SIP/2.0/UDP den3.level3.com From: sip:firstname.lastname@example.org To: sip:13039263142@Den1.level3.com Call-ID: DEN1231999021712095500999@Den1.level3.com CSeq: 8348 INVITE Contact: <sip:email@example.com> Content-Length: 436 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=jpeterson 2890844526 2890842807 IN IP4 126.96.36.199 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=nxv3; base=etsi121 Content-Disposition: signal; handling=optional
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 document because a literal encoding of those bytes would have been confusing and unreadable. RFC 2046 ) 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:firstname.lastname@example.org SIP/2.0 Via: SIP/2.0/UDP sc10.nortelnetworks.com From: sip:email@example.com To: sip:firstname.lastname@example.org Call-ID: email@example.com CSeq: 1234 INVITE Contact: <sip:firstname.lastname@example.org> Content-Length: 358 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=audet 2890844526 2890842807 5 IN IP4 188.8.131.52 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-- RFC 2543 (SIP - Session Initiation Protocol) and should be used as appropriate for both the SIP message and the encapsulated ISUP or QSIG body. RFC 2434  under Expert Review. Note that where a specification is fully peer-to-peer backwards compatible with a previous issue (i.e., the compatibility mechanism is supported by both), then there is no need for separate symbols to be registered. The symbol for the original specification should be used to identify backwards-compatible upgrades of that specification as well. Symbols beginning with the characters 'X-' are reserved for non- standard usage (e.g., cases in which a token other than a string representing an issue of an ISUP specification is appropriate for characterizing ISUP within an administrative domain). Such non- standard version can only be transmitted between administrative domains in accordance with a bilateral agreement. These symbols should be administered under the Private Use policy described in RFC 2434.
This document registers a new disposition-type for the Content- Disposition header, 'signal', to be used when a MIME body contains supplemental signaling information (ISUP and QSIG as MIME bodies being examples of this). This document also defines a Content Disposition parameter, "handling". The handling parameter, handling-parm, describes how the UAS should react if it receives a message body whose content type or disposition type it does not understand. If the parameter has the value "optional", the UAS MUST ignore the message body; if it has the value "required", the UAS MUST return 415 (Unsupported Media Type). If the handling parameter is missing, the value "required" is to be assumed.
Mo Zonoun Nortel Networks 4301 Great America Parkway Santa Clara, CA 95054, USA EMail: email@example.com M. Watson Nortel Networks Maidenhead, UK EMail: firstname.lastname@example.org  Freed, N., Klensin, J. and J. Postel, "Multipart Internet Mail Extensions (MIME) Part Four: Registration Procedures", BCP 13, RFC 2048, November 1996.  Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, "Session Initiation Protocol (SIP)", RFC 2543, March 1999.  Freed, N. and N. Borenstein, "Multipart Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.  Freed, N. and N. Borenstein, "Multipart Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.  Troost, R., Dorner, S. and K. Moore, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, August 1997.  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.