Movatterモバイル変換

Network Working Group                                        E. ZimmererRequest 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 2001MIME media types for ISUP and QSIG ObjectsStatus 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.Abstract   This document describes MIME types for application/ISUP and   application/QSIG objects for use in SIP applications, according to   the rules defined inRFC 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.1. Introduction   ISUP (ISDN User part) defined in the ITU-T recommendations Q.761-4 is   a signaling protocol used between telephony switches.  There are   configurations in which ISUP-encoded signaling information needs to   be transported between SIP entities as part of the payload of SIP   messages, where the preservation of ISUP data is necessary for the   proper operation of PSTN features.Zimmerer, et al.            Standards Track                     [Page 1]

RFC 3204               ISUP and QSIG MIME Objects          December 2001   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.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 theRFC 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: Seesection 5.   The ISUP message is encapsulated beginning with the Message Type Code   (i.e., omitting Routing Label and Circuit ID Code).Zimmerer, et al.            Standards Track                     [Page 2]

RFC 3204               ISUP and QSIG MIME Objects          December 2001   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 [5] 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   [5], 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.Zimmerer, et al.            Standards Track                     [Page 3]

RFC 3204               ISUP and QSIG MIME Objects          December 2001      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=optional3.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: Seesection 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)Zimmerer, et al.            Standards Track                     [Page 4]

RFC 3204               ISUP and QSIG MIME Objects          December 2001   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.4. Illustrative examples4.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 inRFC 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         INVITE sip:13039263142@Den1.level3.com SIP/2.0         Via: SIP/2.0/UDP den3.level3.com         From: sip:13034513355@den3.level3.com         To: sip:13039263142@Den1.level3.com         Call-ID: DEN1231999021712095500999@Den1.level3.com         CSeq: 8348 INVITE         Contact: <sip:jpeterson@level3.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.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=nxv3;         base=etsi121         Content-Disposition: signal; handling=optionalZimmerer, et al.            Standards Track                     [Page 5]

RFC 3204               ISUP and QSIG MIME Objects          December 2001         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.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 inRFC 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         Via: SIP/2.0/UDP sc10.nortelnetworks.com         From: sip:14085655675@sc10.nortelnetworks.com         To: sip:14084955072@sc1.nortelnetworks.com         Call-ID: 1231999021712095500999@sc12.nortelnetworks.com         CSeq: 1234 INVITE         Contact: <sip:14085655675@sc10.nortelnetworks.com>         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 134.177.64.4         s=SDP seminar         c=IN IP4 MG141.nortelnetworks.com         t= 2873397496 2873404696         m=audio 9092 RTP/AVP 0 3 4Zimmerer, et al.            Standards Track                     [Page 6]

RFC 3204               ISUP and QSIG MIME Objects          December 2001         --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--5. Security considerations   Information contained in ISUP and QSIG bodies may include sensitive   customer information, potentially requiring use of encryption.   Security mechanisms are provided inRFC 2543 (SIP - Session   Initiation Protocol) and should be used as appropriate for both the   SIP message and the encapsulated ISUP or QSIG body.6. IANA considerations   This document registers the "application/ISUP" and "application/QSIG"   MIME media types.   Registrations for the 'version' symbols used within the ISUP and QSIG   MIME types must specify a definitive specification reference,   identifying a particular issue of the specification, to which the new   symbol shall refer. Identifying a definite specification reference   requires a review process; the authors recommend that a subject   matter expert be designated as described inRFC 2434 [6] 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 inRFC2434.Zimmerer, et al.            Standards Track                     [Page 7]

RFC 3204               ISUP and QSIG MIME Objects          December 2001   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.7. Authors Addresses   Eric Zimmerer   Rankom Inc.   19500 Pruneridge Ave Suite #4303   Cupertino, CA 95014, USA   EMail: eric_zimmerer@yahoo.com   Aparna Vemuri   Qwest Communications   6000 Parkwood Pl   Dublin, OH 43016, USA   EMail: Aparna.Vemuri@Qwest.com   Jon Peterson   NeuStar, Inc   1800 Sutter Street, Suite 570   Concord, CA 94520, USA   EMail: jon.peterson@neustar.com   Lyndon Ong   Ciena   Cupertino, CA, USA   EMail: lyndon_ong@yahoo.com   Francois Audet   Nortel Networks   4301 Great America Parkway   Santa Clara, CA 95054, USA   EMail: mzonoun@nortelnetworks.comZimmerer, et al.            Standards Track                     [Page 8]

RFC 3204               ISUP and QSIG MIME Objects          December 2001   Mo Zonoun   Nortel Networks   4301 Great America Parkway   Santa Clara, CA 95054, USA   EMail: audet@nortelnetworks.com   M. Watson   Nortel Networks   Maidenhead, UK   EMail: mwatson@nortelnetworks.com8. References   [1] Freed, N., Klensin, J. and J. Postel, "Multipart Internet Mail       Extensions (MIME) Part Four: Registration Procedures",BCP 13,RFC 2048, November 1996.   [2] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg,       "Session Initiation Protocol (SIP)",RFC 2543, March 1999.   [3] Freed, N. and N. Borenstein, "Multipart Internet Mail Extensions       (MIME) Part One: Format of Internet Message Bodies",RFC 2045,       November 1996.   [4] Freed, N. and N. Borenstein, "Multipart Internet Mail Extensions       (MIME) Part Two: Media Types",RFC 2046, November 1996.   [5] Troost, R., Dorner, S. and K. Moore, "Communicating Presentation       Information in Internet Messages: The Content-Disposition Header       Field",RFC 2183, August 1997.   [6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA       Considerations Section in RFCs",BCP 26,RFC 2434, October 1998.Zimmerer, et al.            Standards Track                     [Page 9]

RFC 3204               ISUP and QSIG MIME Objects          December 2001Full 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.Zimmerer, et al.            Standards Track                    [Page 10]