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

   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.

      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

; 編註: generic-param の定義は RFC 3204 にはなし。

   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

**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 in RFC 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 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.

*SEE ALSO

-[[MIME]]
--[[Content-Disposition:領域]]
-[[Internet媒体型]]

*LICENSE

See [[RFCのライセンス]]