• 宝贝是地名,你能想到这么浪漫的地名在哪儿吗? 2019-08-15
  • 何树山副省长到方圆机电调研指导工作 2019-08-15
  • 时时中彩app:RFC3204 - MIME media types for ISUP and QSIG Objects

    来源:本网整理

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

    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 (RFC2045 [3]). It should be noted
    that the rules mentioned in the RFC2045 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).

    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

    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)

    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 RFC2046 [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:[email protected] SIP/2.0
    Via: SIP/2.0/UDP den3.level3.com
    From: sip:130345133[email protected]
    To: sip:[email protected]
    Call-ID: [email protected]
    CSeq: 8348 INVITE
    Contact: <sip:[email protected]>
    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

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

    --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 RFC2543 (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 RFC2434 [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.

    7. Authors Addresses

    Eric Zimmerer
    Rankom Inc.
    19500 Pruneridge Ave Suite #4303
    Cupertino, CA 95014, USA
    EMail: [email protected]

    Aparna Vemuri
    Qwest Communications
    6000 Parkwood Pl
    Dublin, OH 43016, USA
    EMail: [email protected]

    Jon Peterson
    NeuStar, Inc
    1800 Sutter Street, Suite 570
    Concord, CA 94520, USA
    EMail: [email protected]

    Lyndon Ong
    Ciena
    Cupertino, CA, USA
    EMail: [email protected]

    Francois Audet
    Nortel Networks
    4301 Great America Parkway
    Santa Clara, CA 95054, USA
    EMail: [email protected]

    Mo Zonoun
    Nortel Networks
    4301 Great America Parkway
    Santa Clara, CA 95054, USA
    EMail: [email protected]

    M. Watson
    Nortel Networks
    Maidenhead, UK
    EMail: [email protected]

    8. References

    [1] Freed, N., Klensin, J. and J. Postel, "Multipart Internet Mail
    Extensions (MIME) Part Four: Registration Procedures", BCP 13,
    RFC2048, November 1996.

    [2] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg,
    "Session Initiation Protocol (SIP)", RFC2543, March 1999.

    [3] Freed, N. and N. Borenstein, "Multipart Internet Mail Extensions
    (MIME) Part One: Format of Internet Message Bodies", RFC2045,
    November 1996.

    [4] Freed, N. and N. Borenstein, "Multipart Internet Mail Extensions
    (MIME) Part Two: Media Types", RFC2046, November 1996.

    [5] Troost, R., Dorner, S. and K. Moore, "Communicating Presentation
    Information in Internet Messages: The Content-Disposition Header
    Field", RFC2183, August 1997.

    [6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
    Considerations Section in RFCs", BCP 26, RFC2434, October 1998.

    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 RFCEditor function is currently provided by the
    Internet Society.

    彩票双色球历史开奖结果 www.s9h6.com

  • 本文相关:
  • RFC3199 - Request for Comments Summary RFCNumbers 3100-3199
  • RFC3197 - Applicability Statement for DNS MIB Extensions
  • RFC3198 - Terminology for Policy-Based Management
  • RFC3175 - Aggregation of RSVP for IPv4 and IPv6 Reservations
  • RFC3196 - Internet Printing Protocol/1.1: Implementors Guide
  • RFC3174 - US Secure Hash Algorithm 1 (SHA1)
  • RFC3254 - Definitions for talking about directories
  • RFC3257 - Stream Control Transmission Protocol Applicability Statement
  • RFC3252 - Binary Lexical Octet Ad-hoc Transport
  • RFC3251 - Electricity over IP
  • 免责声明 - 关于我们 - 联系我们 - 广告联系 - 友情链接 - 彩票双色球历史开奖结果 - 频道导航
    Copyright © 2017 彩票双色球历史开奖结果 www.s9h6.com All Rights Reserved
  • 宝贝是地名,你能想到这么浪漫的地名在哪儿吗? 2019-08-15
  • 何树山副省长到方圆机电调研指导工作 2019-08-15
  • 足球赛果预测软件 2010彩票走势图 牛牛大逃亡 北单足彩 大乐透家破人亡 2019香港生肖排码表图 黑龙江福彩36选7走势图大星 中国体育排三试机号 安徽快3形态走势图百度乐彩网 排列5预测号 重庆幸运农场彩票 香港六肖中特网主大全 体彩p5开奖结果 京东彩票扫码 保险一个点是多少