RFC4571 日本語訳

Network Working Group                                         J. Lazzaro
Request for Comments: 4571                                   UC Berkeley
Category: Standards Track                                      July 2006

Lazzaroがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 4571年のUCバークレーカテゴリ: 標準化過程2006年7月

               Framing Real-time Transport Protocol (RTP)
                and RTP Control Protocol (RTCP) Packets
                  over Connection-Oriented Transport

接続指向の輸送の上でリアルタイムのトランスポート・プロトコル(RTP)とRTP制御プロトコル(RTCP)パケットを縁どっています。

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.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2006).

Copyright(C)インターネット協会(2006)。

Abstract

要約

   This memo defines a method for framing Real-time Transport Protocol
   (RTP) and RTP Control Protocol (RTCP) packets onto connection-
   oriented transport (such as TCP).  The memo also defines how session
   descriptions may specify RTP streams that use the framing method.

このメモは縁どりレアル-時間Transportプロトコル(RTP)とRTP Controlプロトコル(RTCP)パケットのために接続指向の輸送(TCPなどの)とメソッドを定義します。 また、メモはセッション記述がどう縁どりメソッドを使用するRTPストリームを指定するかもしれないかを定義します。

Table of Contents

目次

   1. Introduction ....................................................2
      1.1. Terminology ................................................2
   2. The Framing Method ..............................................2
   3. Packet Stream Properties ........................................3
   4. Session Descriptions for RTP/AVP over TCP .......................3
   5. Example .........................................................5
   6. Congestion Control ..............................................6
   7. Acknowledgements ................................................6
   8. Security Considerations .........................................6
   9. IANA Considerations .............................................7
   10. Normative References ...........................................7

1. 序論…2 1.1. 用語…2 2. 縁どりメソッド…2 3. パケットストリームの特性…3 4. TCPの上のRTP/AVPのためのセッション記述…3 5. 例…5 6. 混雑コントロール…6 7. 承認…6 8. セキュリティ問題…6 9. IANA問題…7 10. 標準の参照…7

Lazzaro                     Standards Track                     [Page 1]

RFC 4571     RTP & RTCP over Connection-Oriented Transport     July 2006

Lazzaro規格は2006年7月に接続指向の輸送の上でRFC4571RTP&RTCPを追跡します[1ページ]。

1. Introduction

1. 序論

   The Audio/Video Profile (AVP, [RFC3550]) for the Real-time Transport
   Protocol (RTP, [RFC3551]) does not define a method for framing RTP
   and RTP Control Protocol (RTCP) packets onto connection-oriented
   transport protocols (such as TCP).  However, earlier versions of
   RTP/AVP did define a framing method, and this method is in use in
   several implementations.

レアル-時間Transportプロトコル(RTP、[RFC3551])のためのAudio/ビデオProfile(AVP、[RFC3550])は縁どりRTPとRTP Controlプロトコル(RTCP)パケットのために接続指向のトランスポート・プロトコル(TCPなどの)とメソッドを定義しません。 しかしながら、RTP/AVPの以前のバージョンは縁どりメソッドを定義しました、そして、このメソッドはいくつかの実装で使用中です。

   In this memo, we document the framing method that was defined by
   earlier versions of RTP/AVP.  In addition, we introduce a mechanism
   for a session description [SDP] to signal the use of the framing
   method.  Note that session description signalling for the framing
   method is new and was not defined in earlier versions of RTP/AVP.

このメモでは、私たちはRTP/AVPの以前のバージョンによって定義された縁どりメソッドを記録します。 さらに、セッション記述[SDP]が縁どりメソッドの使用を示すように、私たちはメカニズムを紹介します。 縁どりメソッドのために合図するセッション記述が新しく、RTP/AVPの以前のバージョンで定義されなかったことに注意してください。

1.1.  Terminology

1.1. 用語

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in BCP 14, RFC 2119
   [RFC2119].

キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14RFC2119[RFC2119]で説明されるように本書では解釈されることであるべきです。

2.  The Framing Method

2. 縁どりメソッド

   Figure 1 defines the framing method.

図1は縁どりメソッドを定義します。

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    ---------------------------------------------------------------
   |             LENGTH            |  RTP or RTCP packet ...       |
    ---------------------------------------------------------------

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 --------------------------------------------------------------- | 長さ| RTPかRTCPパケット… | ---------------------------------------------------------------

        Figure 1: The bit field definition of the framing method

図1: 縁どりメソッドの噛み付いているフィールド定義

   A 16-bit unsigned integer LENGTH field, coded in network byte order
   (big-endian), begins the frame.  If LENGTH is non-zero, an RTP or
   RTCP packet follows the LENGTH field.  The value coded in the LENGTH
   field MUST equal the number of octets in the RTP or RTCP packet.
   Zero is a valid value for LENGTH, and it codes the null packet.

ネットワークバイトオーダー(ビッグエンディアン)でコード化された16ビットの符号のない整数LENGTH分野はフレームを始めます。 LENGTHが非ゼロであるなら、RTPかRTCPパケットがLENGTH野原に続きます。 LENGTH分野でコード化された値はRTPかRTCPパケットの八重奏の数と等しくなければなりません。 ゼロはLENGTHのための有効値です、そして、それはヌルパケットをコード化します。

   This framing method does not use frame markers (i.e., an octet of
   constant value that would precede the LENGTH field).  Frame markers
   are useful for detecting errors in the LENGTH field.  In lieu of a
   frame marker, receivers SHOULD monitor the RTP and RTCP header fields
   whose values are predictable (for example, the RTP version number).
   See Appendix A.1 of [RFC3550] for additional guidance.

この縁どりメソッドはフレームマーカー(すなわち、LENGTH分野に先行する恒常価値の八重奏)を使用しません。 フレームマーカーはLENGTH分野に誤りを検出することの役に立ちます。 フレームマーカーの代わりに、受信機SHOULDは値が予測できるRTPとRTCPヘッダーフィールド(例えば、RTPバージョン番号)をモニターします。 追加指導に関して[RFC3550]のAppendix A.1を見てください。

Lazzaro                     Standards Track                     [Page 2]

RFC 4571     RTP & RTCP over Connection-Oriented Transport     July 2006

Lazzaro規格は2006年7月に接続指向の輸送の上でRFC4571RTP&RTCPを追跡します[2ページ]。

3.  Packet Stream Properties

3. パケットストリームの特性

   In most respects, the framing method does not specify properties
   above the level of a single packet.  In particular, Section 2 does
   not specify the following:

ほとんどの点で、単一のパケットのレベルを超えて縁どりメソッドは特性を指定しません。 特に、セクション2は以下を指定しません:

   Bi-directional issues

双方向の問題

      Section 2 defines a framing method for use in one direction on a
      connection.  The relationship between framed packets flowing in a
      defined direction and in the reverse direction is not specified.

セクション2は接続のときに使用のための縁どりメソッドを一方向と定義します。 定義された方向と反対の方向に流れる縁どられたパケットの間の関係は指定されません。

   Packet loss and reordering

パケット損失と再命令

      The reliable nature of a connection does not imply that a framed
      RTP stream has a contiguous sequence number ordering.  For
      example, if the connection is used to tunnel a UDP stream through
      a network middlebox that only passes TCP, the sequence numbers in
      the framed stream reflect any packet loss or reordering on the UDP
      portion of the end-to-end flow.

接続の信頼性は、隣接の一連番号に注文されて、縁どられたRTPストリームがそうしたのを含意しません。 例えば、接続がTCPを渡すだけであるネットワークmiddleboxを通してUDPストリームにトンネルを堀るのに使用されるなら、縁どられたストリームにおける一連番号は終わりから終わりへの流動のUDP部分でのどんなパケット損失や再命令も反映します。

   Out-of-band semantics

バンドで出ている意味論

      Section 2 does not define the RTP or RTCP semantics for closing a
      TCP socket, or of any other "out of band" signal for the
      connection.

セクション2は、TCPソケットを閉じるか、または接続のためのいかなる他の「バンド」信号についても定義するためにRTPかRTCP意味論を定義しません。

   Memos that normatively include the framing method MAY specify these
   properties.  For example, Section 4 of this memo specifies these
   properties for RTP/AVP sessions specified in session descriptions.

標準に縁どりメソッドを含んでいるメモはこれらの特性を指定するかもしれません。 例えば、このメモのセクション4はセッション記述で指定されたRTP/AVPセッションとしてこれらの特性を指定します。

   In one respect, the framing protocol does indeed specify a property
   above the level of a single packet.  If a direction of a connection
   carries RTP packets, the streams carried in this direction MUST
   support the use of multiple synchronization sources (SSRCs) in those
   RTP packets.  If a direction of a connection carries RTCP packets,
   the streams carried in this direction MUST support the use of
   multiple SSRCs in those RTCP packets.

本当に、1つの点で、単一のパケットのレベルを超えて縁どりプロトコルは特性を指定します。 接続の方向がRTPパケットを運ぶなら、この方向に運ばれた小川はそれらのRTPパケットにおける複数の同期ソース(SSRCs)の使用をサポートしなければなりません。 接続の方向がRTCPパケットを運ぶなら、この方向に運ばれた小川はそれらのRTCPパケットにおける複数のSSRCsの使用をサポートしなければなりません。

4.  Session Descriptions for RTP/AVP over TCP

4. TCPの上のRTP/AVPのためのセッション記述

   Session management protocols that use the Session Description
   Protocol [SDP] in conjunction with the Offer/Answer Protocol
   [RFC3264] MUST use the methods described in [COMEDIA] to set up
   RTP/AVP streams over TCP.  In this case, the use of Offer/Answer is
   REQUIRED, as the setup methods described in [COMEDIA] rely on
   Offer/Answer.

Offer/答えプロトコル[RFC3264]に関連してSession記述プロトコル[SDP]を使用するセッション管理プロトコルはTCPの上にRTP/AVPストリームをセットアップするために[COMEDIA]で説明されたメソッドを使用しなければなりません。 この場合、[COMEDIA]で説明されたセットアップメソッドがOffer/答えに依存するとき、Offer/答えの使用はREQUIREDです。

Lazzaro                     Standards Track                     [Page 3]

RFC 4571     RTP & RTCP over Connection-Oriented Transport     July 2006

Lazzaro規格は2006年7月に接続指向の輸送の上でRFC4571RTP&RTCPを追跡します[3ページ]。

   In principle, [COMEDIA] is capable of setting up RTP sessions for any
   RTP profile.  In practice, each profile has unique issues that must
   be considered when applying [COMEDIA] to set up streams for the
   profile.

原則として、[COMEDIA]はどんなRTPプロフィールのためのRTPセッションもセットアップできます。 各プロフィールには、実際には、プロフィールのためにストリームをセットアップするのに申し込むとき[COMEDIA]考えなければならないユニークな問題があります。

   In this memo, we restrict our focus to the Audio/Video Profile (AVP,
   [RFC3551]).  Below, we define a token value ("TCP/RTP/AVP") that
   signals the use of RTP/AVP in a TCP session.  We also define the
   operational procedures that a TCP/RTP/AVP stream MUST follow.

このメモでは、私たちは焦点をAudio/ビデオProfile(AVP、[RFC3551])に制限します。 以下では、私たちがTCPセッションにおけるRTP/AVPの使用を示すトークン値(「TCP/RTP/AVP」)を定義します。 また、私たちはTCP/RTP/AVPストリームが従わなければならない操作手順を定義します。

   We expect that other standards-track memos will appear to support the
   use of the framing method with other RTP profiles.  The support memo
   for a new profile MUST define a token value for the profile, using
   the style we used for AVP.  Thus, for profile xyz, the token value
   MUST be "TCP/RTP/xyz".  The memo SHOULD adopt the operational
   procedures we define below for AVP, unless these procedures are in
   some way incompatible with the profile.

私たちは、他の標準化過程メモが他のRTPプロフィールによる縁どりメソッドの使用をサポートするように見えると予想します。 新しいプロフィールのためのサポートメモはプロフィールのためにトークン値を定義しなければなりません、私たちがAVPに使用したスタイルを使用して。 したがって、プロフィールxyzに関して、トークン値は「TCP/RTP/xyz」でなければなりません。 メモSHOULDは私たちがAVPのために以下で定義する操作手順を採用します、これらの手順がプロフィールと両立しない何らかの方法でない場合。

   The remainder of this section describes how to setup and use an AVP
   stream in a TCP session.  Figure 2 shows the syntax of a media (m=)
   line [SDP] of a session description:

このセクションの残りは、TCPセッションのときにどのようにAVPストリームをセットアップして、使用するかを説明します。 図2はセッション記述のメディア(m=)系列[SDP]の構文を示しています:

      "m=" media SP port ["/" integer] SP proto 1*(SP fmt) CRLF

「m=」メディアSPポート[「/」整数]SPプロト1*(SP fmt)CRLF

       Figure 2: Syntax for an SDP media (m=) line (from [SDP])

図2: SDPメディア(m=)系列のための構文([SDP]からの)

   The <proto> token value "TCP/RTP/AVP" specifies an RTP/AVP [RFC3550]
   [RFC3551] stream that uses the framing method over TCP.

<proto>トークン価値の「TCP/RTP/AVP」はTCPの上で縁どりメソッドを使用するRTP/AVP[RFC3550][RFC3551]ストリームを指定します。

   The <fmt> tokens that follow <proto> MUST be unique unsigned integers
   in the range 0 to 127.  The <fmt> tokens specify an RTP payload type
   associated with the stream.

<proto>に続く<fmt>トークンは0〜127に範囲のユニークな符号のない整数であるに違いありません。 <fmt>トークンはストリームに関連づけられたRTPペイロードタイプを指定します。

   In all other respects, the session description syntax for the framing
   method is identical to [COMEDIA].

他のすべての点で、縁どりメソッドのためのセッション記述構文は[COMEDIA]と同じです。

   The TCP <port> on the media line carries RTP packets.  If a media
   stream uses RTCP, a second connection carries RTCP packets.  The port
   for the RTCP connection is chosen using the algorithms defined in
   [SDP] or by the mechanism defined in [RFC3605].

メディア系列のTCP<ポート>はRTPパケットを運びます。 メディアストリームがRTCPを使用するなら、2番目の接続はRTCPパケットを運びます。 RTCP接続のためのポートは、[SDP]か[RFC3605]で定義されたメカニズムによって定義されたアルゴリズムを使用することで選ばれています。

   The TCP connections MAY carry bi-directional traffic, following the
   semantics defined in [COMEDIA].  Both directions of a connection MUST
   carry the same type of packets (RTP or RTCP).  The packets MUST
   exclusively code the RTP or RTCP streams specified on the media
   line(s) associated with the connection.

[COMEDIA]で定義された意味論に従って、TCP接続は双方向のトラフィックを運ぶかもしれません。 接続の両方の方向は同じタイプのパケット(RTPかRTCP)を運ばなければなりません。 パケットは排他的に接続に関連しているメディア系列で指定されたRTPかRTCPストリームをコード化しなければなりません。

Lazzaro                     Standards Track                     [Page 4]

RFC 4571     RTP & RTCP over Connection-Oriented Transport     July 2006

Lazzaro規格は2006年7月に接続指向の輸送の上でRFC4571RTP&RTCPを追跡します[4ページ]。

   As noted in [RFC3550], the use of RTP without RTCP is strongly
   discouraged.  However, if a sender does not wish to send RTCP packets
   in a media session, the sender MUST add the lines "b=RS:0" AND
   "b=RR:0" to the media description (from [RFC3556]).

[RFC3550]に述べられるように、RTCPのないRTPの使用は強くお勧めできないです。 しかしながら、送付者がメディアセッションのときにパケットをRTCPに送りたくないなら、送付者が系列を加えなければならない、「b=RS: そして、0インチに、「b=RR: メディア記述([RFC3556]からの)への0インチ。」

   If the session descriptions of the offer AND the answer both contain
   the "b=RS:0" AND "b=RR:0" lines, an RTCP TCP flow for the media
   session MUST NOT be created by either endpoint in the session.  In
   all other cases, endpoints MUST establish two TCP connections for an
   RTP/AVP stream, one for RTP and one for RTCP.

申し出と両方が含む答えのセッション記述である、「b=RS: 0インチと「b=RR: 0インチの系列、メディアセッションのためのRTCP TCP流動はセッションのときにどちらの終点によっても引き起こされてはいけません」。 他のすべての場合では、終点はRTP/AVPストリーム、RTPのためのもの、およびRTCPのためのもののために2つのTCP接続を確立しなければなりません。

   As described in [RFC3264], the use of the "sendonly" or "sendrecv"
   attribute in an offer (or answer) indicates that the offerer (or
   answerer) intends to send RTP packets on the RTP TCP connection.  The
   use of the "recvonly" or "sendrecv" attributes in an offer (or
   answer) indicates that the offerer (or answerer) wishes to receive
   RTP packets on the RTP TCP connection.

[RFC3264]で説明されるように、申し出(答える)における"sendonly"か"sendrecv"属性の使用は、申出人(または、answerer)がRTP TCP接続のときにパケットをRTPに送るつもりであるのを示します。 申し出(答える)における"recvonly"か"sendrecv"属性の使用は、申出人(または、answerer)がRTP TCP接続のときにRTPパケットを受けたがっているのを示します。

5.  Example

5. 例

   The session descriptions in Figures 3 and 4 define a TCP RTP/AVP
   session.

図3と4におけるセッション記述はTCP RTP/AVPセッションを定義します。

   v=0
   o=first 2520644554 2838152170 IN IP4 first.example.net
   s=Example
   t=0 0
   c=IN IP4 192.0.2.105
   m=audio 9 TCP/RTP/AVP 11
   a=setup:active
   a=connection:new

v=0oが0 0c=最初に、IN IP4 2520644554 2838152170の最初の.example.net s=例t=IN IP4と等しい、192.0、.2、.105m、オーディオの9TCP/RTP/AVPと等しい、11、=セットアップ: アクティブなaは接続と等しいです:、新しさ

          Figure 3: TCP session description for the first participant

図3: 最初の関係者のためのTCPセッション記述

   v=0
   o=second 2520644554 2838152170 IN IP4 second.example.net
   s=Example
   t=0 0
   c=IN IP4 192.0.2.94
   m=audio 16112 TCP/RTP/AVP 10 11
   a=setup:passive
   a=connection:new

2番目の2520644554 2838152170のIN IP4 2番目のv=0o=.example.net s=例tが0 0c=IN IP4と等しい、192.0、.2、.94m、オーディオの16112TCP/RTP/AVPと等しい、10 11、=セットアップ: 受け身のaは接続と等しいです:、新しさ

          Figure 4: TCP session description for the second participant

図4: 2番目の関係者のためのTCPセッション記述

   The session descriptions define two parties that participate in a
   connection-oriented RTP/AVP session.  The first party (Figure 3) is
   capable of receiving stereo L16 streams (static payload type 11).

セッション記述は接続指向のRTP/AVPセッションのときに参加する2回のパーティーを定義します。 最初のパーティー(図3)はステレオL16ストリーム(静的なペイロードタイプ11)を受けることができます。

Lazzaro                     Standards Track                     [Page 5]

RFC 4571     RTP & RTCP over Connection-Oriented Transport     July 2006

Lazzaro規格は2006年7月に接続指向の輸送の上でRFC4571RTP&RTCPを追跡します[5ページ]。

   The second party (Figure 4) is capable of receiving mono (static
   payload type 10) or stereo L16 streams.

2番目のパーティー(図4)はモノタイプ(静的なペイロードタイプ10)かステレオL16ストリームを受けることができます。

   The "setup" attribute in Figure 3 specifies that the first party is
   "active" and initiates connections, and the "setup" attribute in
   Figure 4 specifies that the second party is "passive" and accepts
   connections [COMEDIA].

図3の「セットアップ」属性が、最初のパーティーが「アクティブであり」、接続を開始すると指定して、図4の「セットアップ」属性は、2番目のパーティーが「受け身である」と指定して、接続[COMEDIA]を受け入れます。

   The first party connects to the network address (192.0.2.94) and port
   (16112) of the second party.  Once the connection is established, it
   is used bi-directionally: the first party sends framed RTP packets to
   the second party in one direction of the connection, and the second
   party sends framed RTP packets to the first party in the other
   direction of the connection.

最初のパーティーがネットワーク・アドレスに接続する、(192.0 .2 .94) そして、2番目のパーティーのポート(16112)。 接続がいったん確立されると、それは2方向に使用されます: 最初のパーティーは接続の一方向における2番目のパーティーに縁どられたRTPパケットを送ります、そして、2番目のパーティーは接続のもう片方の方向における最初のパーティーに縁どられたRTPパケットを送ります。

   The first party also initiates an RTCP TCP connection to port 16113
   (16112 + 1, as defined in [SDP]) of the second party.  Once the
   connection is established, the first party sends framed RTCP packets
   to the second party in one direction of the connection, and the
   second party sends framed RTCP packets to the first party in the
   other direction of the connection.

また、最初のパーティーは、2番目の16113人のパーティー(中で定義されるとしての16112+1[SDP])を移植するためにRTCP TCP接続を開始します。 接続がいったん確立されると、最初のパーティーは接続の一方向における2番目のパーティーに縁どられたRTCPパケットを送ります、そして、2番目のパーティーは接続のもう片方の方向における最初のパーティーに縁どられたRTCPパケットを送ります。

6.  Congestion Control

6. 輻輳制御

   The RTP congestion control requirements are defined in [RFC3550].  As
   noted in [RFC3550], all transport protocols used on the Internet need
   to address congestion control in some way, and RTP is not an
   exception.

RTP輻輳制御要件は[RFC3550]で定義されます。 [RFC3550]に述べられるように、インターネットで使用されるすべてのトランスポート・プロトコルが、混雑がコントロールであると何らかの方法で扱う必要があります、そして、RTPは例外ではありません。

   In addition, the congestion control requirements for the Audio/Video
   Profile are defined in [RFC3551].  The basic congestion control
   requirement defined in [RFC3551] is that RTP sessions should compete
   fairly with TCP flows that share the network.  As the framing method
   uses TCP, it competes fairly with other TCP flows by definition.

さらに、Audio/ビデオProfileのための輻輳制御要件は[RFC3551]で定義されます。 [RFC3551]で定義された基本の輻輳制御要件はRTPセッションがネットワークを共有するTCP流れと公正に競争するべきであるということです。 縁どりメソッドがTCPを使用するとき、それは定義上他のTCP流れと公正に競争します。

7.  Acknowledgements

7. 承認

   This memo, in part, documents discussions on the AVT mailing list
   about TCP and RTP.  Thanks to all of the participants in these
   discussions.

このメモはTCPとRTPに関するAVTメーリングリストについての議論を一部記録します。 これらの議論の関係者のすべてをありがとうございます。

8.  Security Considerations

8. セキュリティ問題

   Implementors should carefully read the Security Considerations
   sections of the RTP [RFC3550] and RTP/AVP [RFC3551] documents, as
   most of the issues discussed in these sections directly apply to RTP
   streams framed over TCP.

作成者はRTP[RFC3550]とRTP/AVP[RFC3551]ドキュメントのSecurity Considerations部を注意して読むべきです、これらのセクションで議論した問題の大部分が直接TCPの上で縁どられたRTPストリームに適用されるとき。

Lazzaro                     Standards Track                     [Page 6]

RFC 4571     RTP & RTCP over Connection-Oriented Transport     July 2006

Lazzaro規格は2006年7月に接続指向の輸送の上でRFC4571RTP&RTCPを追跡します[6ページ]。

   Session descriptions that specify connection-oriented media sessions
   (such as the example session shown in Figures 3 and 4 of Section 5)
   raise unique security concerns for streaming media.  The Security
   Considerations section of [COMEDIA] describes these issues in detail.

接続指向のメディアセッション(セクション5の図3と4に示された例のセッションなどの)を指定するセッション記述はストリーミング・メディアのためにユニークな安全上の配慮を上げます。 [COMEDIA]のSecurity Considerations部は詳細にこれらの問題について説明します。

   Below, we discuss security issues that are unique to the framing
   method defined in Section 2.

以下では、私たちがセクション2で定義された縁どりメソッドにユニークな安全保障問題について議論します。

   Attackers may send framed packets with large LENGTH values to exploit
   security holes in applications.  For example, a C implementation may
   declare a 1500-byte array as a stack variable, and use LENGTH as the
   bound on the loop that reads the framed packet into the array.  This
   code would work fine for friendly applications that use Etherframe-
   sized RTP packets, but may be open to exploit by an attacker.  Thus,
   an implementation needs to handle packets of any length, from a NULL
   packet (LENGTH == 0) to the maximum-length packet holding 64K octets
   (LENGTH = 0xFFFF).

攻撃者は、アプリケーションにおけるセキュリティーホールを利用するために大きいLENGTH値がある縁どられたパケットを送るかもしれません。 例えば、C実装は、スタックとしての1500年のバイトの配列が可変であると申告して、バウンドとして配列から縁どられたパケットを読み取る輪の上でLENGTHを使用するかもしれません。 このコードは、Etherframeの大きさで分けられたRTPパケットを使用する好意的なアプリケーションのためにきめ細かに働いているでしょうが、攻撃者で利用するために開いているかもしれません。 したがって、実装は、どんな長さのパケットも扱う必要があります、NULLパケット(LENGTH=0)から64Kの八重奏を保持する最大の長さのパケットまで(LENGTHは0xFFFFと等しいです)。

9.  IANA Considerations

9. IANA問題

   [SDP] defines the syntax of session description media lines.  We
   reproduce this definition in Figure 2 of Section 4 of this memo.  In
   Section 4, we define a new token value for the <proto> field of media
   lines: "TCP/RTP/AVP".  Section 4 specifies the semantics associated
   with the <proto> field token, and Section 5 shows an example of its
   use in a session description.

[SDP]はセッション記述メディア系列の構文を定義します。 私たちはこのメモのセクション4の図2とのこの定義を再生させます。 セクション4では、私たちはメディア系列の<proto>分野と新しいトークン値を定義します: 「TCP/RTP/AVP。」 セクション4は<proto>分野トークンに関連している意味論を指定します、そして、セクション5はセッション記述における使用に関する例を示しています。

10.  Normative References

10. 引用規格

   [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
             Jacobson, "RTP: A Transport Protocol for Real-Time
             Applications", STD 64, RFC 3550, July 2003.

[RFC3550] Schulzrinne、H.、Casner、S.、フレディリック、R.、およびV.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、STD64、RFC3550、2003年7月。

   [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
             Video Conferences with Minimal Control", STD 65, RFC 3551,
             July 2003.

[RFC3551] Schulzrinne、H.、およびS.Casner、「オーディオのためのRTPプロフィールと最小量があるテレビ会議システムは制御します」、STD65、RFC3551、2003年7月。

   [COMEDIA] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the
             Session Description Protocol (SDP)", RFC 4145, September
             2005.

[COMEDIA] あそこのものとD.とG.キャマリロ、「セッション記述プロトコル(SDP)におけるTCPベースのメディア輸送」、RFC4145、2005年9月。

   [SDP]     Handley, M., Jacobson, V., and C. Perkins.  "SDP: Session
             Description Protocol", RFC 4566, July 2006.

[SDP] ハンドレー、M.、ジェーコブソン、V.、およびC.パーキンス。 「SDP:」 「セッション記述プロトコル」、RFC4566、2006年7月。

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

Lazzaro                     Standards Track                     [Page 7]

RFC 4571     RTP & RTCP over Connection-Oriented Transport     July 2006

Lazzaro規格は2006年7月に接続指向の輸送の上でRFC4571RTP&RTCPを追跡します[7ページ]。

   [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
             with Session Description Protocol (SDP)", RFC 3264, June
             2002.

[RFC3264] ローゼンバーグとJ.とH.Schulzrinne、「セッション記述プロトコル(SDP)がある申し出/答えモデル」、RFC3264、2002年6月。

   [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute
             in Session Description Protocol (SDP)", RFC 3605, October
             2003.

[RFC3605]Huitema、C.、「(RTCP)がSession記述プロトコル(SDP)で結果と考える本当のTime Controlプロトコル」、RFC3605、2003年10月。

   [RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth
             Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC
             3556, July 2003.

[RFC3556] Casner、S.、「RTP制御プロトコル(RTCP)帯域幅へのセッション記述プロトコル(SDP)帯域幅修飾語」、RFC3556、2003年7月。

Author's Address

作者のアドレス

   John Lazzaro
   UC Berkeley
   CS Division
   315 Soda Hall
   Berkeley CA 94720-1776

ジョンLazzaro UCバークレーのCs区画315ソーダホールバークレーカリフォルニア94720-1776

   EMail: lazzaro@cs.berkeley.edu

メール: lazzaro@cs.berkeley.edu

Lazzaro                     Standards Track                     [Page 8]

RFC 4571     RTP & RTCP over Connection-Oriented Transport     July 2006

Lazzaro規格は2006年7月に接続指向の輸送の上でRFC4571RTP&RTCPを追跡します[8ページ]。

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2006).

Copyright(C)インターネット協会(2006)。

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM 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.

このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Intellectual Property

知的所有権

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を扱ってください。

Acknowledgement

承認

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。

Lazzaro                     Standards Track                     [Page 9]

Lazzaro標準化過程[9ページ]