doc: Add RFC documents

1 files changed, 563 insertions, 0 deletions

diff --git a/doc/rfc/rfc3204.txt b/doc/rfc/rfc3204.txt
new file mode 100644
index 0000000..f8f048e
--- /dev/null
+++ b/doc/rfc/rfc3204.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+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: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=optional
+
+
+
+Zimmerer, 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 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: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 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: 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.com
+
+
+
+
+
+
+
+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: audet@nortelnetworks.com
+
+   M. Watson
+   Nortel Networks
+   Maidenhead, UK
+   EMail: mwatson@nortelnetworks.com
+
+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]
+