MIME media types for ISUP and QSIG Objects
updated by
Extracted elements (20)
Binary encoding was chosen over Base64 for ISUP and QSIG bodies because Base64 would add bulk to encoded messages and impose additional processing cost without benefit, since the MIME rules for binary data in RFC 2045 apply to Internet mail but not to SIP messages.
The media types are scoped specifically to ISUP or QSIG application information used within a SIP session context, and are not intended as a general-purpose transport for SCN (Switched Circuit Network) signaling.
This document deliberately does not address how non-SIP and SIP entities determine or negotiate compatibility with ISUP/QSIG versions. Compatibility is assumed to be handled by external means such as configuration of the interworking functions.
The 'base' parameter enables graceful fallback: if a receiver does not recognize the 'version' string, it may attempt to process the encapsulated ISUP using the identified 'base' specification. Only base values with the compatibility flag 'yes' support the ITU-T 1992 forward compatibility mechanism.
Version symbols beginning with 'X-' are reserved for non-standard/proprietary use and may only be exchanged between administrative domains under a bilateral agreement. They are administered under RFC 2434 Private Use policy.
Where a specification is fully peer-to-peer backwards compatible with a previous issue (i.e., the compatibility mechanism is supported by both), no separate 'version' symbol registration is needed; the original symbol covers backwards-compatible upgrades.
If the 'handling' parameter is missing from Content-Disposition, the value 'required' is to be assumed, meaning the UAS must return 415 if it does not recognize the body type.
If the 'handling' parameter is present with value 'required', the UAS MUST return a 415 (Unsupported Media Type) response when it does not understand the content type or disposition type of the body.
The application/ISUP MIME type carries ISUP signaling messages within SIP. Required parameter: 'version'; optional parameter: 'base'; encoding scheme: binary. The ISUP message is encapsulated beginning with the Message Type Code, omitting Routing Label and Circuit ID Code.
The application/QSIG MIME type carries QSIG signaling messages within SIP. No required parameters; optional parameter: 'version'; encoding scheme: binary. The default Content-Disposition disposition-type is 'signal'.
The 'handling' Content-Disposition parameter specifies how a UAS must react when it receives a message body whose content type or disposition type it does not understand. Valid values are 'optional' and 'required'; if absent, 'required' is assumed.
The optional 'base' parameter on application/ISUP specifies a fallback baseline specification (e.g., 'itu-t88', 'itu-t92+', 'ansi88', 'ansi00', 'etsi121', 'etsi356', 'gr317', 'ttc87', 'ttc93+') so that a receiver that does not recognize the 'version' string can still attempt to process the encapsulated ISUP. The 'base' values also indicate whether the ITU-T 1992 forward compatibility mechanism is supported.
The optional 'version' parameter on application/QSIG identifies the QSIG protocol variant. The only defined value is 'iso', corresponding to ISO/IEC 11572 (Basic Call) and ISO/IEC 11582 (Generic Functional Protocol).
The 'signal' disposition-type is defined for the Content-Disposition header to indicate that a MIME body part contains supplemental signaling information associated with the session but does not describe the session itself. This is the default disposition-type for both ISUP and QSIG body parts.
The 'version' parameter on application/ISUP identifies the specific ISUP variant in use (e.g., 'itu-t', 'ansi', or a proprietary string like 'X-NetxProprietaryISUPv3'). This allows a SoftSwitch/Media Gateway Controller to correctly parse or reject the message. The specification places no constraints on allowed values; these are left to network administrator discretion.
This document registers the 'application/ISUP' MIME media type with IANA. Registrations for 'version' symbols must specify a definitive specification reference and are subject to Expert Review as described in RFC 2434.
This document registers the 'application/QSIG' MIME media type with IANA. The only initially defined 'version' value is 'iso', referencing ISO/IEC 11572 and ISO/IEC 11582.
This document registers the 'signal' disposition-type for the Content-Disposition header, to be used when a MIME body contains supplemental signaling information. It also defines the 'handling' Content-Disposition parameter with values 'optional' and 'required'.
Information contained in ISUP and QSIG bodies may include sensitive customer information, potentially requiring use of encryption. Security mechanisms defined in RFC 2543 (SIP) should be used as appropriate for both the SIP message and the encapsulated ISUP or QSIG body.
ISUP and QSIG message bodies use binary encoding. The ISUP payload begins at the Message Type Code field, omitting the Routing Label and Circuit ID Code that precede it in the native ISUP frame.