rfc3204.txt

RFC 的详细文档！

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.

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.  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 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).





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=optional

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.

   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 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

         INVITE sip:[e-mail] SIP/2.0
         Via: SIP/2.0/UDP den3.level3.com
         From: sip:[e-mail]
         To: sip:[e-mail]
         Call-ID: [e-mail]
         CSeq: 8348 INVITE
         Contact: <sip:[e-mail]>
         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=optional



Zimmerer, et al.            Standards Track                     [Page 5]