rfc3204.txt

RFC 的详细文档！


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 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 'application/QSIG' media type.

         INVITE sip:[e-mail] SIP/2.0
         Via: SIP/2.0/UDP sc10.nortelnetworks.com
         From: sip:[e-mail]
         To: sip:[e-mail]
         Call-ID: [e-mail]
         CSeq: 1234 INVITE
         Contact: <sip:[e-mail]>
         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 4









Zimmerer, 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 in RFC 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 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.







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: [e-mail]

   Aparna Vemuri
   Qwest Communications
   6000 Parkwood Pl
   Dublin, OH 43016, USA
   EMail: [e-mail]

   Jon Peterson
   NeuStar, Inc
   1800 Sutter Street, Suite 570
   Concord, CA 94520, USA
   EMail: [e-mail]

   Lyndon Ong
   Ciena
   Cupertino, CA, USA
   EMail: [e-mail]

   Francois Audet
   Nortel Networks
   4301 Great America Parkway
   Santa Clara, CA 95054, USA
   EMail: [e-mail]







Zimmerer, 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: [e-mail]

   M. Watson
   Nortel Networks
   Maidenhead, UK
   EMail: [e-mail]

8. 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 2001


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.



















Zimmerer, et al.            Standards Track                    [Page 10]