Internet Engineering Task Force (IETF) G. Camarillo
Request for Comments: 5888 Ericsson
Obsoletes: 3388 H. Schulzrinne
Category: Standards Track Columbia University
ISSN: 2070-1721 June 2010
The Session Description Protocol (SDP) Grouping Framework
Abstract
抽象
In this specification, we define a framework to group "m" lines in the Session Description Protocol (SDP) for different purposes. This framework uses the "group" and "mid" SDP attributes, both of which are defined in this specification. Additionally, we specify how to use the framework for two different purposes: for lip synchronization and for receiving a media flow consisting of several media streams on different transport addresses. This document obsoletes RFC 3388.
本明細書において、我々は、異なる目的のために、セッション記述プロトコル（SDP）のグループ「M」の行にフレームワークを定義します。このフレームワークは、本明細書で定義されている両方とも「基」および「中間」SDP属性を使用します。リップシンクのために、異なるトランスポートアドレス上の複数のメディアストリームからなるメディアフローを受信するために：また、我々は二つの異なる目的のためのフレームワークを使用する方法を指定します。この文書はRFC 3388を廃止します。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これは、インターネット標準化過程文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。インターネット標準の詳細については、RFC 5741のセクション2で利用可能です。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5888.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5888で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 3
4. Media Stream Identification Attribute . . . . . . . . . . . . 4
5. Group Attribute . . . . . . . . . . . . . . . . . . . . . . . 4
6. Use of "group" and "mid" . . . . . . . . . . . . . . . . . . . 4
7. Lip Synchronization (LS) . . . . . . . . . . . . . . . . . . . 5
7.1. Example of LS . . . . . . . . . . . . . . . . . . . . . . 5
8. Flow Identification (FID) . . . . . . . . . . . . . . . . . . 6
8.1. SIP and Cellular Access . . . . . . . . . . . . . . . . . 6
8.2. DTMF Tones . . . . . . . . . . . . . . . . . . . . . . . . 7
8.3. Media Flow Definition . . . . . . . . . . . . . . . . . . 7
8.4. FID Semantics . . . . . . . . . . . . . . . . . . . . . . 7
8.4.1. Examples of FID . . . . . . . . . . . . . . . . . . . 8
8.5. Scenarios That FID Does Not Cover . . . . . . . . . . . . 11
8.5.1. Parallel Encoding Using Different Codecs . . . . . . . 11
8.5.2. Layered Encoding . . . . . . . . . . . . . . . . . . . 12
8.5.3. Same IP Address and Port Number . . . . . . . . . . . 12
9. Usage of the "group" Attribute in SIP . . . . . . . . . . . . 13
9.1. Mid Value in Answers . . . . . . . . . . . . . . . . . . . 13
9.1.1. Example . . . . . . . . . . . . . . . . . . . . . . . 14
9.2. Group Value in Answers . . . . . . . . . . . . . . . . . . 15
9.2.1. Example . . . . . . . . . . . . . . . . . . . . . . . 15
9.3. Capability Negotiation . . . . . . . . . . . . . . . . . . 16
9.3.1. Example . . . . . . . . . . . . . . . . . . . . . . . 16
9.4. Backward Compatibility . . . . . . . . . . . . . . . . . . 17
9.4.1. Offerer Does Not Support "group" . . . . . . . . . . . 17
9.4.2. Answerer Does Not Support "group" . . . . . . . . . . 17
10. Changes from RFC 3388 . . . . . . . . . . . . . . . . . . . . 18
11. Security Considerations . . . . . . . . . . . . . . . . . . . 18
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
14.1. Normative References . . . . . . . . . . . . . . . . . . . 20
14.2. Informative References . . . . . . . . . . . . . . . . . . 20
RFC 3388 [RFC3388] specified a media-line grouping framework for SDP [RFC4566]. This specification obsoletes RFC 3388 [RFC3388].
RFC 3388 [RFC3388]はSDPのメディア行グループ化フレームワーク[RFC4566]を指定しました。この仕様はRFC 3388 [RFC3388]を廃止します。
An SDP [RFC4566] session description typically contains one or more media lines, which are commonly known as "m" lines. When a session description contains more than one "m" line, SDP does not provide any means to express a particular relationship between two or more of them. When an application receives an SDP session description with more than one "m" line, it is up to the application to determine what to do with them. SDP does not carry any information about grouping media streams.
SDP [RFC4566]セッション記述は、典型的には、一般に「M」ラインとして知られている1つまたは複数のメディア行を含んでいます。セッション記述は、複数の「M」の行が含まれている場合、SDPは、それらの2つ以上の間の特定の関係を表現する任意の手段を提供しません。アプリケーションが複数の「M」のラインとのSDPセッション記述を受信すると、それはそれらをどうするかを決定するために、アプリケーション次第です。 SDPは、メディアストリームをグループ化に関する情報を運びません。
While in some environments this information can be carried out of band, it is necessary to have a mechanism in SDP to express how different media streams within a session description relate to each other. The framework defined in this specification is such a mechanism.
一部の環境では、この情報は、帯域外で行うことができるが、セッション記述内で異なるメディアストリームが互いにどのように関係するかを表現するSDPにおける機構を有することが必要です。本明細書で定義されたフレームワークは、このような機構です。
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 [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
This section provides a non-normative description of how the SDP Grouping Framework defined in this document works. In a given session description, each "m" line is identified by a token, which is carried in a "mid" attribute below the "m" line. The session description carries session-level "group" attributes that group different "m" lines (identified by their tokens) using different group semantics. The semantics of a group describe the purpose for which the "m" lines are grouped. For example, the "group" line in the session description below indicates that the "m" lines identified by tokens 1 and 2 (the audio and the video "m" lines, respectively) are grouped for the purpose of lip synchronization (LS).
このセクションでは、この文書で定義されたSDPグループ化フレームワークがどのように動作するかの非規範的な記述を提供します。所与のセッション記述において、各「M」の行を「M」行の下に「中間」属性で運ばれるトークンによって識別されます。セッション記述は、セッションレベル「基」（そのトークンによって識別される）グループの異なる「M」の行は、異なるグループのセマンティクスを使用して、その属性を運びます。グループのセマンティクスは「M」の行をグループ化する目的を記述しています。例えば、セッション記述における「グループ」の行は、以下のトークン1及び2（それぞれ、オーディオとビデオの「M」の行）によって識別される「M」線がリップシンクの目的（LS）のためにグループ化されていることを示しています。
v=0
o=Laura 289083124 289083124 IN IP4 one.example.com
c=IN IP4 192.0.2.1
t=0 0
a=group:LS 1 2
m=audio 30000 RTP/AVP 0
a=mid:1
m=video 30002 RTP/AVP 31
a=mid:2
This document defines the "media stream identification" media attribute, which is used for identifying media streams within a session description. Its formatting in SDP [RFC4566] is described by the following Augmented Backus-Naur Form (ABNF) [RFC5234]:
この文書は、セッション記述内のメディアストリームを識別するために使用される「メディアストリーム識別」メディア属性を定義します。 SDP [RFC4566]での書式は以下の増補バッカス - ナウアフォーム（ABNF）[RFC5234]によって記載されています。
mid-attribute = "a=mid:" identification-tag
identification-tag = token
; token is defined in RFC 4566
The identification-tag MUST be unique within an SDP session description.
識別タグは、SDPセッション記述内で一意でなければなりません。
This document defines the "group" session-level attribute, which is used for grouping together different media streams. Its formatting in SDP is described by the following ABNF [RFC5234]:
この文書は、一緒に異なるメディアストリームをグループ化するために使用される「グループ」セッションレベルの属性を定義します。 SDPでの書式は以下のABNF [RFC5234]によって記載されています。
group-attribute = "a=group:" semantics
*(SP identification-tag)
semantics = "LS" / "FID" / semantics-extension
semantics-extension = token
; token is defined in RFC 4566
This document defines two standard semantics: Lip Synchronization (LS) and Flow Identification (FID). Semantics extensions follow the Standards Action policy [RFC5226].
リップ同期（LS）とフロー識別（FID）：この文書は、二つの標準的な意味を定義しています。セマンティクスの拡張機能は、標準アクションポリシー[RFC5226]を実行します。
All of the "m" lines of a session description that uses "group" MUST be identified with a "mid" attribute whether they appear in the group line(s) or not. If a session description contains at least one "m" line that has no "mid" identification, the application MUST NOT perform any grouping of media lines.
「グループ」を使用してセッション記述の「M」の行のすべてのは、彼らがグループライン（複数可）にか表示するかどうかを「ミッド」属性で識別されなければなりません。セッション記述がない「中間」識別を有していない少なくとも1つの「M」の行が含まれている場合、アプリケーションは、メディア行の任意のグループ化を行ってはいけません。
"a=group" lines are used to group together several "m" lines that are identified by their "mid" attribute. "a=group" lines that contain identification-tags that do not correspond to any "m" line within the session description MUST be ignored. The application acts as if the "a=group" line did not exist. The behavior of an application receiving an SDP description with grouped "m" lines is defined by the semantics field in the "a=group" line.
「A =グループ」線が一緒にグループにそれらの「中間」属性によって識別される複数の「M」の行に使用されます。セッション記述内の任意の「M」の行に対応していない識別タグを含む「A =基」行は無視されなければなりません。 「A =グループ」行が存在しなかったかのようにアプリケーションが動作します。グループ化された「M」の行とのSDP記述を受信するアプリケーションの動作は、「A =基」行のセマンティクスフィールドによって定義されます。
There MAY be several "a=group" lines in a session description. The "a=group" lines of a session description can use the same or different semantics. An "m" line identified by its "mid" attribute MAY appear in more than one "a=group" line.
セッション記述のいくつかの「A =グループ」行があるかもしれません。セッション記述の「A =基」の行は、同じまたは異なるセマンティクスを使用することができます。その「半ば」属性によって識別される「M」の行には、複数の「A =グループ」行に表示されることがあります。
An application that receives a session description that contains "m" lines that are grouped together using LS semantics MUST synchronize the playout of the corresponding media streams. Note that LS semantics apply not only to a video stream that has to be synchronized with an audio stream; the playout of two streams of the same type can be synchronized as well.
LSセマンティクスを使用して一緒にグループ化される「M」行を含むセッション記述を受信するアプリケーションは、対応するメディアストリームの再生を同期させる必要があります。それは意味が唯一のオーディオストリームと同期する必要があるビデオストリームにない適用LSに注意してください。同じタイプの2つのストリームの再生も同様に同期させることができます。
For RTP streams, synchronization is typically performed using the RTP Control Protocol (RTCP), which provides enough information to map time stamps from the different streams into a local absolute time value. However, the concept of media stream synchronization MAY also apply to media streams that do not make use of RTP. If this is the case, the application MUST recover the original timing relationship between the streams using whatever mechanism is available.
RTPストリームのために、同期は、典型的には、ローカル絶対時間値に異なるストリームからのタイムスタンプをマッピングするための十分な情報を提供するRTP制御プロトコル（RTCP）を用いて行われます。しかし、メディアストリームの同期化の概念は、RTPを使用しないメディアストリームに適用される場合があります。この場合、アプリケーションが利用可能であるどのようなメカニズム用いてストリーム間の元のタイミング関係を回復しなければなりません。
The following example shows a session description of a conference that is being multicast. The first media stream (mid:1) contains the voice of the speaker who speaks in English. The second media stream (mid:2) contains the video component, and the third (mid:3) media stream carries the translation to Spanish of what she is saying. The first and second media streams have to be synchronized.
次の例では、マルチキャストされる会議のセッション記述を示します。最初のメディアストリーム（ミッドは：1）英語で話す話者の音声が含まれています。第2のメディアストリーム（ミッド：2）ビデオ・コンポーネントが含まれており、第三（ミッド：3）メディア・ストリームは、彼女が何を言っているかのスペイン語への翻訳を運びます。第一及び第二のメディアストリームを同期させる必要があります。
v=0
o=Laura 289083124 289083124 IN IP4 two.example.com
c=IN IP4 233.252.0.1/127
t=0 0
a=group:LS 1 2
m=audio 30000 RTP/AVP 0
a=mid:1
m=video 30002 RTP/AVP 31
a=mid:2
m=audio 30004 RTP/AVP 0
i=This media stream contains the Spanish translation
a=mid:3
Note that although the third media stream is not present in the group line, it still has to contain a "mid" attribute (mid:3), as stated before.
前に述べたように、：第三のメディアストリームは、グループ行に存在しないが、それはまだ（3半ば）、「半ば」属性が含まれている必要があることに注意してください。
An "m" line in an SDP session description defines a media stream. However, SDP does not define what a media stream is. This definition can be found in the Real Time Streaming Protocol (RTSP) specification. The RTSP RFC [RFC2326] defines a media stream as "a single media instance, e.g., an audio stream or a video stream as well as a single whiteboard or shared application group. When using RTP, a stream consists of all RTP and RTCP packets created by a source within an RTP session".
SDPセッション記述における「M」の行は、メディアストリームを定義します。しかし、SDPは、メディアストリームが何であるかを定義していません。この定義は、リアルタイムストリーミングプロトコル（RTSP）の仕様に記載されています。 RTSP RFC [RFC2326]は、オーディオストリームまたはビデオストリーム、ならびに単一ホワイトボードまたは共有アプリケーション基、例えば、単一のメディアインスタンス」としてメディアストリームを定義する。RTPを使用する場合、ストリームは、すべてのRTPとRTCPパケットから成りRTPセッション内のソース」で作成されました。
This definition assumes that a single audio (or video) stream maps into an RTP session. The RTP RFC [RFC1889] (at present obsoleted by [RFC3550]) used to define an RTP session as follows: "For each participant, the session is defined by a particular pair of destination transport addresses (one network address plus a port pair for RTP and RTCP)".
この定義は、単一のオーディオ（またはビデオ）ストリームは、RTPセッションにマップすることを前提としています。 RTP RFC [RFC1889]（[RFC3550]によって廃止現時点では）次のようにRTPセッションを定義するために使用される：「各参加者について、セッションは、宛先トランスポートアドレス（一つのネットワークアドレスとのポートペアの特定の組によって定義されますRTPおよびRTCP）」。
While the previous definitions cover the most common cases, there are situations where a single media instance (e.g., an audio stream or a video stream) is sent using more than one RTP session. Two examples (among many others) of this kind of situation are cellular systems using the Session Initiation Protocol (SIP; [RFC3261]) and systems receiving Dual-Tone Multi-Frequency (DTMF) tones on a different host than the voice.
以前の定義は、最も一般的なケースをカバーしながら、単一のメディアインスタンス（例えば、オーディオストリームまたはビデオストリーム）が複数のRTPセッションを使用して送信される状況があります。音声は別のホストにデュアルトーン多重周波数（DTMF）トーンを受け取り、システム、このような状況の（他の多くの間）は、2つの例は、セッション開始プロトコル（[RFC3261] SIP）を用いて細胞系です。
Systems using a cellular access and SIP as a signalling protocol need to receive media over the air. During a session, the media can be encoded using different codecs. The encoded media has to traverse the radio interface. The radio interface is generally characterized as being prone to bit errors and associated with relatively high packet transfer delays. In addition, radio interface resources in a cellular environment are scarce and thus expensive, which calls for special measures in providing a highly efficient transport. In order to get an appropriate speech quality in combination with an efficient transport, precise knowledge of codec properties is required so that a proper radio bearer for the RTP session can be configured before transferring the media. These radio bearers are dedicated bearers per media type (i.e., codec).
シグナリングプロトコルとしてセルラアクセスとSIPを使用するシステムは、空気を介してメディアを受信する必要があります。セッション中に、メディアが異なるコーデックを使用してエンコードすることができます。エンコードされたメディアは、無線インターフェイスを横断しなければなりません。無線インタフェースは、一般的にビット誤りが発生しやすいものとして特徴付けられ、比較的高いパケット転送遅延と関連しています。また、細胞環境における無線インタフェース資源は非常に効率的な輸送を提供するには、特別な措置を求めている、希少ので、高価です。 RTPセッションのための適切な無線ベアラがメディアを転送する前に設定することができるように、効率的な輸送と組み合わせて、適切な音声品質を得るために、コーデックの特性の正確な知識が必要とされています。これらの無線ベアラは、メディアタイプ（すなわち、コーデック）ごとに専用ベアラです。
Cellular systems typically configure different radio bearers on different port numbers. Therefore, incoming media has to have different destination port numbers for the different possible codecs in order to be routed properly to the correct radio bearer. Thus, this is an example in which several RTP sessions are used to carry a single media instance (the encoded speech from the sender).
セルラーシステムは、典型的には、異なるポート番号の異なる無線ベアラを設定します。したがって、入ってくるメディアは、正しい無線ベアラに適切にルーティングするために、異なる可能なコーデックの異なる宛先ポート番号を有していなければなりません。したがって、これはいくつかのRTPセッションが単一のメディアインスタンス（送信者からの符号化された音声）を搬送するために使用された例です。
Some voice sessions include DTMF tones. Sometimes, the voice handling is performed by a different host than the DTMF handling. It is common to have an application server in the network gathering DTMF tones for the user while the user receives the encoded speech on his user agent. In this situation, it is necessary to establish two RTP sessions: one for the voice and the other for the DTMF tones. Both RTP sessions are logically part of the same media instance.
いくつかの音声セッションは、DTMFトーンを含んでいます。時には、音声処理はDTMF取り扱いとは異なるホストで実行されます。ユーザーが自分のユーザエージェントに符号化された音声を受信しながら、ユーザーのためのDTMFトーンを集めるネットワーク内のアプリケーションサーバを持つことが一般的です。 DTMFトーンのための音声用とその他：この状況では、2つのRTPセッションを確立する必要があります。どちらのRTPセッションは、論理的に同じメディアインスタンスの一部です。
The previous examples show that the definition of a media stream in [RFC2326] does not cover some scenarios. It cannot be assumed that a single media instance maps into a single RTP session. Therefore, we introduce the definition of a media flow:
前の例では、[RFC2326]でのメディアストリームの定義はいくつかのシナリオをカバーしていないことを示しています。単一のメディアインスタンスは、単一のRTPセッションにマップすることを想定することはできません。したがって、我々は、メディアフローの定義を紹介します：
A media flow consists of a single media instance, e.g., an audio stream or a video stream as well as a single whiteboard or shared application group. When using RTP, a media flow comprises one or more RTP sessions.
メディアフローは、単一のメディアインスタンス、例えば、オーディオストリームまたはビデオストリーム、ならびに単一ホワイトボードまたは共有アプリケーショングループから成ります。 RTPを使用する場合は、メディアフローは、一回の以上のRTPセッションを備えます。
Several "m" lines grouped together using FID semantics form a media flow. A media agent handling a media flow that comprises several "m" lines MUST send a copy of the media to every "m" line that is part of the flow as long as the codecs and the direction attribute present in a particular "m" line allow it.
FIDセマンティクスを使用して一緒にグループ化されたいくつかの「M」の行は、メディアフローを形成します。限りコーデックと方向が特定の「M」の行に存在する属性としてフローの一部であるすべての「M」ラインへのメディアのコピーを送信しなければならないいくつかの「M」の行を含むメディアフローを扱うメディアエージェント許す。
It is assumed that the application uses only one codec at a time to encode the media produced. This codec MAY change dynamically during the session, but at any particular moment, only one codec is in use.
アプリケーションが生成メディアを符号化するために同時に複数のコーデックを使用することを想定しています。このコーデックは、セッション中に動的に変更されることがありますが、任意の特定の瞬間に、1つのコーデックだけが使用されています。
The application encodes the media using the current codec and checks, one by one, all of the "m" lines that are part of the flow. If a particular "m" line contains the codec being used and the direction attribute is "sendonly" or "sendrecv", a copy of the encoded media is sent to the address/port specified in that particular media stream. If either the "m" line does not contain the codec being used or the direction attribute is neither "sendonly" nor "sendrecv", nothing is sent over this media stream.
アプリケーションは、現在のコーデックとチェック、一つずつ、フローの一部である「M」の行のすべてを使用してメディアを符号化します。特定の「M」の行が含まれている場合に使用されるコーデックと方向属性が「sendonlyで」または「のsendrecv」であり、符号化されたメディアのコピーが、その特定のメディアストリームで指定されたアドレス/ポートに送信されます。 「M」の行が使用されているコーデックが含まれていないか、方向属性が「sendonlyで」も「のsendrecv」でもないのいずれかの場合は、何もこのメディア・ストリームを介して送信されません。
The application typically ends up sending media to different destinations (IP address/port number) depending on the codec used at any moment.
アプリケーションは、典型的には、任意の時点で使用されるコーデックに応じて、異なる宛先（IPアドレス/ポート番号）にメディアを送信してしまいます。
The session description below might be sent by a SIP user agent using a cellular access. The user agent supports GSM (Global System for Mobile communications) on port 30000 and AMR (Adaptive Multi-Rate) on port 30002. When the remote party sends GSM, it will send RTP packets to port number 30000. When AMR is the codec chosen, packets will be sent to port 30002. Note that the remote party can switch between both codecs dynamically in the middle of the session. However, in this example, only one media stream at a time carries voice. The other remains "muted" while its corresponding codec is not in use.
以下のセッション記述は、セルラーアクセスを使用してSIPユーザエージェントによって送信される可能性があります。相手がGSMを送信すると、ユーザーエージェントはポート30002上のポート30000およびAMR（適応マルチレート）上（移動通信用グローバルシステム）GSMをサポートAMRは、選択したコーデックである場合は、ポート番号30000にRTPパケットを送信します、パケットがリモートパーティが動的にセッションの途中で両方のコーデックを切り替えることができますポート30002注に送信されます。しかし、この例では、一度に1つのメディアストリームは、音声を運びます。それに対応するコーデックが使用されていない間に、他には、「ミュート」のまま。
v=0
o=Laura 289083124 289083124 IN IP4 three.example.com
c=IN IP4 192.0.2.1
t=0 0
a=group:FID 1 2
m=audio 30000 RTP/AVP 3
a=rtpmap:3 GSM/8000
a=mid:1
m=audio 30002 RTP/AVP 97
a=rtpmap:97 AMR/8000
a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2;
mode-change-neighbor; maxframes=1
a=mid:2
(The linebreak in the fmtp line accommodates RFC formatting restrictions; SDP does not have continuation lines.)
（のfmtpラインの改行は、RFCフォーマットの制約を収容し、SDPは、継続行を持っていません。）
In the previous example, a system receives media on the same IP address on different port numbers. The following example shows how a system can receive different codecs on different IP addresses.
前の例では、システムは、異なるポート番号で同一のIPアドレスにメディアを受信します。次の例では、システムは、異なるIPアドレス上の異なるコーデックを受け取ることができる方法を示しています。
v=0
o=Laura 289083124 289083124 IN IP4 four.example.com
c=IN IP4 192.0.2.1
t=0 0
a=group:FID 1 2
m=audio 20000 RTP/AVP 0
c=IN IP4 192.0.2.2
a=rtpmap:0 PCMU/8000
a=mid:1
m=audio 30002 RTP/AVP 97
a=rtpmap:97 AMR/8000
a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2;
mode-change-neighbor; maxframes=1
a=mid:2
(The linebreak in the fmtp line accommodates RFC formatting restrictions; SDP does not have continuation lines.)
（のfmtpラインの改行は、RFCフォーマットの制約を収容し、SDPは、継続行を持っていません。）
The cellular terminal in this example only supports the AMR codec. However, many current IP phones only support PCM (Pulse-Code Modulation; payload 0). In order to be able to interoperate with them, the cellular terminal uses a transcoder whose IP address is 192.0.2.2. The cellular terminal includes the transcoder IP address in its SDP description to provide support for PCM. Remote systems will send AMR directly to the terminal, but PCM will be sent to the transcoder. The transcoder will be configured (using whatever method is preferred) to convert the incoming PCM audio to AMR and send it to the terminal.
この例では、携帯端末がAMRコーデックをサポートしています。しかし、多くの現在のIP電話機のみPCM（;ペイロード0パルス符号変調）をサポート。それらと相互運用できるようにするために、携帯端末は、IPアドレスが192.0.2.2であるトランスコーダを使用しています。携帯端末は、PCMのサポートを提供するために、そのSDP記述のトランスコーダIPアドレスを含みます。リモートシステムは、端末に直接AMRを送信しますが、PCMは、トランスコーダに送信されます。トランスコーダは、AMR着信PCMオーディオを変換して端末に送信する（好ましい何らかの方法を使用して）構成されます。
The next example shows how the "group" attribute used with FID semantics can indicate the use of two different codecs in the two directions of a bidirectional media stream.
次の例では、FIDセマンティクスで使用される「グループ」属性は、双方向メディアストリームの二つの方向に2つの異なるコーデックを使用することを示すことができます方法を示しています。
v=0
o=Laura 289083124 289083124 IN IP4 five.example.com
c=IN IP4 192.0.2.1
t=0 0
a=group:FID 1 2
m=audio 30000 RTP/AVP 0
a=mid:1
m=audio 30002 RTP/AVP 8
a=recvonly
a=mid:2
A user agent that receives the SDP description above knows that, at a certain moment, it can send either PCM u-law to port number 30000 or PCM A-law to port number 30002. However, the media agent also knows that the other end will only send PCM u-law (payload 0).
上記のSDP記述が特定の瞬間に、それはポート番号30002にポート番号30000またはPCM A則のいずれかのPCM U-法則を送信することができるが、メディアエージェントはまた、そのもう一方の端を知っている、ことを知っている受信ユーザエージェント唯一のPCM U-法則（ペイロード0）を送信します。
The following example shows a session description with different "m" lines grouped together using FID semantics that contain the same codec.
次の例では、同じコーデックを含むFIDセマンティクスを使用して一緒にグループ化された異なる「M」の行とのセッション記述を示します。
v=0
o=Laura 289083124 289083124 IN IP4 six.example.com
c=IN IP4 192.0.2.1
t=0 0
a=group:FID 1 2 3
m=audio 30000 RTP/AVP 0
a=mid:1
m=audio 30002 RTP/AVP 8
a=mid:2
m=audio 20000 RTP/AVP 0 8
c=IN IP4 192.0.2.2
a=recvonly
a=mid:3
At a particular point in time, if the media agent receiving the SDP message above is sending PCM u-law (payload 0), it sends RTP packets to 192.0.2.1 on port 30000 and to 192.0.2.2 on port 20000 (first and third "m" lines). If it is sending PCM A-law (payload 8), it sends RTP packets to 192.0.2.1 on port 30002 and to 192.0.2.2 on port 20000 (second and third "m" lines).
上記SDPメッセージを受信し、メディアエージェントは、PCMのU則（ペイロード0）を送信している場合に特定の時点で、それは、第1及び第3の（ポート30000に192.0.2.1し、ポート20000上192.0.2.2するRTPパケットを送信します。 "M" の行）。それはPCMのA則（ペイロード8）を送信している場合は、ポート30002上192.0.2.1し、ポート20000（第二及び第三の「M」の行）に192.0.2.2するRTPパケットを送信します。
The system that generated the SDP description above supports PCM u-law on port 30000 and PCM A-law on port 30002. Besides, it uses an application server that records the conversation and whose IP address is 192.0.2.2. The application server does not need to understand the media content, so it always receives a copy of the media stream, regardless of the codec and payload type that is being used. That is why the application server always receives a copy of the audio stream regardless of the codec being used at any given moment (it actually performs an RTP dump, so it can effectively receive any codec).
上記のSDP記述を生成したシステムは、それがし、IPアドレス192.0.2.2での会話を記録したアプリケーションサーバを使用して、ほかにポート30002上でポート30000およびPCM A-法にPCMのU-法則をサポートしています。それが常に使用されているコーデックおよびペイロードタイプに関係なく、メディア・ストリームのコピーを受け取るように、アプリケーション・サーバは、メディアコンテンツを理解する必要はありません。アプリケーションサーバは常に（それが効果的に任意のコーデックを受け取ることができますので、それは実際には、RTPのダンプを実行）にかかわらず、任意の時点で使用されているコーデックのオーディオストリームのコピーを受け取る理由です。
Remember that if several "m" lines that are grouped together using the FID semantics contain the same codec, the media agent MUST send copies of the same media stream as several RTP sessions at the same time.
FIDのセマンティクスを使用して一緒にグループ化されているいくつかの「m」の行が同じコーデックが含まれている場合は、メディアエージェントは、同時に複数のRTPセッションと同じメディア・ストリームのコピーを送信しなければならないことに注意してください。
The last example in this section deals with DTMF tones. DTMF tones can be transmitted using a regular voice codec or can be transmitted as telephony events. The RTP payload for DTMF tones treated as telephone events is described in [RFC4733]. Below, there is an example of an SDP session description using FID semantics and this payload type.
このセクションの最後の例では、DTMFトーンを扱います。 DTMFトーンは、通常の音声コーデックを使用して送信することができますまたはテレフォニーイベントとして送信することができます。電話イベントとして扱わDTMFトーンのためのRTPペイロードは[RFC4733]に記載されています。以下、FIDセマンティクスを使用してSDPセッション記述と、このペイロードタイプの例があります。
v=0
o=Laura 289083124 289083124 IN IP4 seven.example.com
c=IN IP4 192.0.2.1
t=0 0
a=group:FID 1 2
m=audio 30000 RTP/AVP 0
a=mid:1
m=audio 20000 RTP/AVP 97
c=IN IP4 192.0.2.2
a=rtpmap:97 telephone-events
a=mid:2
The remote party would send PCM encoded voice (payload 0) to 192.0.2.1 and DTMF tones encoded as telephony events to 192.0.2.2. Note that only voice or DTMF is sent at a particular point in time. When DTMF tones are sent, the first media stream does not carry any data and, when voice is sent, there is no data in the second media stream. FID semantics provide different destinations for alternative codecs.
相手は192.0.2.2にテレフォニーイベントとしてエンコード192.0.2.1とDTMFトーンにPCM符号化された音声（ペイロード0）を送信します。音声のみまたはDTMFが特定の時点で送信されることに注意してください。 DTMFトーンが送信されると、第一のメディアストリームは、音声が送信されたとき、第2のメディアストリーム内のデータが存在しない、任意のデータを搬送せず。 FID意味論は、代替コーデックの異なる宛先を提供しています。
It is worthwhile mentioning some scenarios where the "group" attribute using existing semantics (particularly FID) might seem to be applicable but is not.
これは、既存のセマンティクスを使用して「グループ」属性（特にFID）が適用されるように見えるかもしれないいくつかのシナリオを言及する価値があるではないです。
FID semantics are useful when the application only uses one codec at a time. An application that encodes the same media using different codecs simultaneously MUST NOT use FID to group those media lines. Some systems that handle DTMF tones are a typical example of parallel encoding using different codecs. Some systems implement the RTP payload defined in RFC 4733 [RFC4733], but when they send DTMF tones, they do not mute the voice channel. Therefore, in effect they are sending two copies of the same DTMF tone: encoded as voice and encoded as a telephony event. When the receiver gets both copies, it typically uses the telephony event rather than the tone encoded as voice. FID semantics MUST NOT be used in this context to group both media streams, since such a system is not using alternative codecs but rather different parallel encodings for the same information.
アプリケーションは一度に一つのコーデックを使用する場合、FIDセマンティクスが便利です。同時に異なるコーデックを使用して、同じメディアをエンコードするアプリケーションは、グループこれらのメディアラインにFIDを使用してはいけません。 DTMFトーンを処理するいくつかのシステムは、異なるコーデックを使用して、並列符号化の典型的な例です。一部のシステムでは、RFC 4733 [RFC4733]で定義されたRTPペイロードを実装するが、彼らはDTMFトーンを送信するとき、彼らは音声チャネルをミュートしないでください。そのため、実際にはそれらは同じDTMFトーンの2つのコピーを送信している：声としてエンコードおよびテレフォニーイベントとしてエンコードされました。受信機は両方のコピーを取得すると、それは一般的に音声としてエンコードされた音ではなく、テレフォニーイベントを使用しています。このようなシステムは、同じ情報のための代替コーデックではなく、異なる並列エンコーディングを使用していないので、FIDのセマンティクスは、両方のメディアストリームグループにこの文脈で使用してはいけません。
Layered encoding schemes encode media in different layers. The quality of the media stream at the receiver varies depending on the number of layers received. SDP provides a means to group together contiguous multicast addresses that transport different layers. The "c" line below:
階層符号化方式が異なる層にメディアをエンコードします。受信機でのメディアストリームの品質は、受信された層の数に応じて変化します。 SDPは、異なる層を輸送グループ一緒に連続するマルチキャストアドレスするための手段を提供します。以下の「C」のライン：
c=IN IP4 233.252.0.1/127/3
IP4 233.252.0.1/127/3のC =
is equivalent to the following three "c" lines:
次の三つの「C」の行に相当します。
c=IN IP4 233.252.0.1/127
c=IN IP4 233.252.0.2/127
c=IN IP4 233.252.0.3/127
FID MUST NOT be used to group "m" lines that do not represent the same information. Therefore, FID MUST NOT be used to group "m" lines that contain the different layers of layered encoding schemes. Besides, we do not define new group semantics to provide a more flexible way of grouping different layers, because the already existing SDP mechanism covers the most useful scenarios. Since the existing SDP mechanism already covers the most useful scenarios, we do not define a new group semantics to define a more flexible way of grouping different layers.
FIDは、同じ情報を表すものではないグループ「M」の行に使用してはいけません。したがって、FIDは、階層符号化方式の異なる層を含むグループ「M」の行に使用してはいけません。加えて、我々は、既存のSDPメカニズムが最も有用なシナリオをカバーしているため、異なる層をグループ化するより柔軟な方法を提供するために、新しいグループのセマンティクスを定義していません。既存のSDPメカニズムはすでに最も有用なシナリオをカバーしているので、我々は異なる層をグループ化するより柔軟な方法を定義するには、新しいグループのセマンティクスを定義していません。
If media streams using several different codecs have to be sent to the same IP address and port, the traditional SDP syntax of listing several codecs in the same "m" line MUST be used. FID MUST NOT be used to group "m" lines with the same IP address/port. Therefore, an SDP description like the one below MUST NOT be generated.
いくつかの異なるコーデックを使用して、メディアストリームが同じIPアドレスとポートに送信する必要がある場合は、同じ「m」の行に複数のコーデックをリストの伝統的なSDP構文を使用しなければなりません。 FIDは、同一のIPアドレス/ポートでグループ「M」の行に使用してはいけません。したがって、以下のようなSDP記述を生成してはいけません。
v=0
o=Laura 289083124 289083124 IN IP4 eight.example.com
c=IN IP4 192.0.2.1
t=0 0
a=group:FID 1 2
m=audio 30000 RTP/AVP 0
a=mid:1
m=audio 30000 RTP/AVP 8
a=mid:2
The correct SDP description for the session above would be the following one:
上記セッションの正しいSDP説明は以下のものであろう。
v=0
o=Laura 289083124 289083124 IN IP4 nine.example.com
c=IN IP4 192.0.2.1
t=0 0
m=audio 30000 RTP/AVP 0 8
If two "m" lines are grouped using FID, they MUST differ in their transport addresses (i.e., IP address plus port).
二つの「m個」の行はFIDを使用してグループ化されている場合、彼らはトランスポートアドレス（すなわち、IPアドレスに加えてポート）で異なっていなければなりません。
SDP descriptions are used by several different protocols, SIP among them. We include a section about SIP, because the "group" attribute will most likely be used mainly by SIP systems.
SDP記述は、いくつかの異なるプロトコル、それらの間のSIPで使用されています。 「グループ」属性は、最も可能性の高いSIPシステムで主に使用されますので、私たちは、SIPに関するセクションが含まれています。
SIP [RFC3261] is an application layer protocol for establishing, terminating, and modifying multimedia sessions. SIP carries session descriptions in the bodies of the SIP messages but is independent from the protocol used for describing sessions. SDP [RFC4566] is one of the protocols that can be used for this purpose.
SIP [RFC3261]は、確立終端、及びマルチメディアセッションを修正するためのアプリケーション層プロトコルです。 SIPは、SIPメッセージのボディのセッション記述を搬送するが、セッションを記述するために使用されるプロトコルから独立しています。 SDP [RFC4566]は、この目的のために使用することができるプロトコルの一つです。
At session establishment, SIP provides a three-way handshake (INVITE-200 OK-ACK) between end systems. However, just two of these three messages carry SDP, as described in [RFC3264].
セッション確立時に、SIPは、エンド・システム間の3ウェイハンドシェイク（INVITE-200 OK-ACK）を提供します。しかし、これらの3個のメッセージのちょうど2つは[RFC3264]に記載されているように、SDPを運びます。
The "mid" attribute is an identifier for a particular media stream. Therefore, the "mid" value in the offer MUST be the same as the "mid" value in the answer. Besides, subsequent offers (e.g., in a re-INVITE) SHOULD use the same "mid" value for the already existing media streams.
「半ば」属性は、特定のメディアストリームの識別子です。そのため、提供中の「中期」の値は、答えの「中期」の値と同じでなければなりません。また、その後のオファー（例えば、中に再INVITE）既存のメディアストリームのための同じ「中間」値を使用する必要があります。
[RFC3264] describes the usage of SDP in text of SIP. The offerer and the answerer align their media description so that the nth media stream ("m=" line) in the offerer's session description corresponds to the nth media stream in the answerer's description.
[RFC3264]はSIPのテキストにおけるSDPの使用を記載しています。オファーのセッション記述におけるn番目のメディアストリーム（「M =」行）は回答の説明におけるn番目のメディア・ストリームに対応するようにオファーとアンサーは、そのメディア記述を整列させます。
The presence of the "group" attribute in an SDP session description does not modify this behavior.
SDPセッション記述では、「グループ」属性の存在は、この動作を変更しません。
Since the "mid" attribute provides a means to label "m" lines, it would be possible to perform media alignment using "mid" labels rather than matching nth "m" lines. However, this would not bring any gain and would add complexity to implementations. Therefore, SIP systems MUST perform media alignment matching nth lines regardless of the presence of the "group" or "mid" attributes.
「中間」属性が「M」の行にラベルを付けるための手段を提供するので、「中間」のラベルではなく、n番目の「M」の行にマッチを使用してメディアの位置合わせを行うことが可能であろう。しかし、これは、任意のゲインを持っていないでしょうし、実装に複雑さを追加します。したがって、SIPシステムにかかわらず、「基」または「中間」属性の存在のn番目の行に一致するメディア・アラインメントを実行しなければなりません。
If a media stream that contained a particular "mid" identifier in the offer contains a different identifier in the answer, the application ignores all of the "mid" and "group" lines that might appear in the session description. The following example illustrates this scenario.
提供中の特定の「中期」の識別子を含まメディアストリームが答えで異なる識別子が含まれている場合、アプリケーションはセッション記述に表示される場合があります「半ば」と「グループ」の行のすべてを無視します。次の例では、このシナリオを示しています。
Two SIP entities exchange SDPs during session establishment. The INVITE contains the SDP description below:
2つのSIPエンティティは、セッション確立中のSDPを交換します。 INVITE以下SDP記述が含まれています。
v=0
o=Laura 289083124 289083124 IN IP4 ten.example.com
c=IN IP4 192.0.2.1
t=0 0
a=group:FID 1 2
m=audio 30000 RTP/AVP 0 8
a=mid:1
m=audio 30002 RTP/AVP 0 8
a=mid:2
The 200 OK response contains the following SDP description:
200 OK応答は以下のSDP記述が含まれています。
v=0
o=Bob 289083122 289083122 IN IP4 eleven.example.com
c=IN IP4 192.0.2.3
t=0 0
a=group:FID 1 2
m=audio 25000 RTP/AVP 0 8
a=mid:2
m=audio 25002 RTP/AVP 0 8
a=mid:1
Since alignment of "m" lines is performed based on matching of nth lines, the first stream had "mid:1" in the INVITE and "mid:2" in the 200 OK. Therefore, the application ignores every "mid" and "group" line contained in the SDP description.
200 OKで：INVITE「2中間」の「M」の行のアラインメントがn番目のラインのマッチングに基づいて行われるので、第一の流れは、「1中間」を有していました。したがって、アプリケーションは、SDP記述に含まれるすべての「中間」および「グループ」行を無視します。
A well-behaved SIP user agent would have returned the SDP description below in the 200 OK response.
行儀SIPユーザエージェントは、200 OK応答で以下のSDP記述を返されたであろう。
v=0
o=Bob 289083122 289083122 IN IP4 twelve.example.com
c=IN IP4 192.0.2.3
t=0 0
a=group:FID 1 2
m=audio 25002 RTP/AVP 0 8
a=mid:1
m=audio 25000 RTP/AVP 0 8
a=mid:2
A SIP entity that receives an offer that contains an "a=group" line with semantics that it does not understand MUST return an answer without the "group" line. Note that, as described in the previous section, the "mid" lines MUST still be present in the answer.
それは、「グループ」行せずに答えを返さなければなら理解していないセマンティクスを持つ「A =グループ」の行が含まれているの申し出を受けたSIPエンティティ。前のセクションで説明したように、「ミッド」の行は、まだ答えに存在しなければならない、ということに注意してください。
A SIP entity that receives an offer that contains an "a=group" line with semantics that are understood MUST return an answer that contains an "a=group" line with the same semantics. The identification-tags contained in this "a=group" line MUST be the same as those received in the offer, or a subset of them (zero identification-tags is a valid subset). When the identification-tags in the answer are a subset, the "group" value to be used in the session MUST be the one present in the answer.
理解される意味論を持つ「A =グループ」行を含むオファーを受信するSIPエンティティは、同じ意味を持つ「A =グループ」線を含む応答を返さなければなりません。この「A =基」行に含まれる識別タグは、オファーで受信したものと同じ、またはそのサブセットである必要があり（ゼロ識別タグの有効なサブセットです）。答えで識別タグがサブセットである場合、セッションで使用される「グループ」値は、回答の一方に存在していなければなりません。
SIP entities refuse media streams by setting the port to zero in the corresponding "m" line. "a=group" lines MUST NOT contain identification-tags that correspond to "m" lines with the port set to zero.
SIPエンティティは、対応する「M」の行にはゼロにポートを設定することによって、メディアストリームを拒否します。 「A =グループ」線はゼロにポートが設定された「M」の行に対応する識別タグを含んではなりません。
Note that grouping of "m" lines MUST always be requested by the offerer, but never by the answerer. Since SIP provides a two-way SDP exchange, an answerer that requested grouping would not know whether the "group" attribute was accepted by the offerer or not. An answerer that wants to group media lines issues another offer after having responded to the first one (in a re-INVITE, for instance).
「M」の行のグループ化は常にオファー側から要求されなければならないことに注意してくださいませんが、決して回答によります。 SIPは、双方向のSDP交換を提供するので、グループ化要求された回答は、「グループ」属性は、オファーかによって受け入れられたかどうかを知ることはできません。グループのメディア・ラインに望んでいる回答は、（例えば、再INVITEで、）最初の1に応答した後に別のオファーを発行します。
The example below shows how the callee refuses a media stream offered by the caller by setting its port number to zero. The "mid" value corresponding to that media stream is removed from the "group" value in the answer.
以下の例では、被呼者がゼロにポート番号を設定することにより、呼び出し側が提供するメディアストリームを拒否する方法を示しています。そのメディア・ストリームに対応した「中期」値が答えで「グループ」値から削除されます。
SDP description in the INVITE from caller to callee:
呼び出し先への発信者からのINVITEでSDP記述：
v=0
o=Laura 289083124 289083124 IN IP4 thirteen.example.com
c=IN IP4 192.0.2.1
t=0 0
a=group:FID 1 2 3
m=audio 30000 RTP/AVP 0
a=mid:1
m=audio 30002 RTP/AVP 8
a=mid:2
m=audio 30004 RTP/AVP 3
a=mid:3
SDP description in the INVITE from callee to caller:
呼び出し元に呼び出し先からINVITEでSDP記述：
v=0
o=Bob 289083125 289083125 IN IP4 fourteen.example.com
c=IN IP4 192.0.2.3
t=0 0
a=group:FID 1 3
m=audio 20000 RTP/AVP 0
a=mid:1
m=audio 0 RTP/AVP 8
a=mid:2
m=audio 20002 RTP/AVP 3
a=mid:3
A client that understands "group" and "mid", but does not want to use these SDP features in a particular session, may still want to indicate that it supports these features. To indicate this support, a client can add an "a=3Dgroup" line with no identification-tags for every semantics value it understands.
「グループ」と「中期」を理解しますが、特定のセッションではこれらのSDPの機能を使用したくないクライアントは、まだそれがこれらの機能をサポートしていることを示すために必要がある場合があります。このサポートを示すために、クライアントはそれを理解し、すべての意味値に対して無識別タグで「A = 3Dgroup」の行を追加することができます。
If a server receives an offer that contains empty "a=group" lines, it SHOULD add its capabilities also in the form of empty "a=group" lines to its answer.
サーバは空の「A =グループ」の行が含まれているの申し出を受けた場合、それはその答えに空「=グループは」ラインの形でも、その機能を追加する必要があります。
A system that supports both LS and FID semantics but does not want to group any media stream for this particular session generates the following SDP description:
この特定のセッションのための任意のメディアストリームをLSとFID意味論の両方をサポートしていますが、グループに望んでいないシステムでは、以下のSDP記述を生成します。
v=0
o=Bob 289083125 289083125 IN IP4 fifteen.example.com
c=IN IP4 192.0.2.3
t=0 0
a=group:LS
a=group:FID
m=audio 20000 RTP/AVP 0 8
The server that receives that offer supports FID but not LS. It responds with the SDP description below:
その申し出を受けたサーバはFIDではなく、LSをサポートしています。それは以下のSDP記述で応答します。
v=0
o=Laura 289083124 289083124 IN IP4 sixteen.example.com
c=IN IP4 192.0.2.1
t=0 0
a=group:FID
m=audio 30000 RTP/AVP 0
This document does not define any SIP "Require" header field. Therefore, if one of the SIP user agents does not understand the "group" attribute, the standard SDP fall-back mechanism MUST be used, namely, attributes that are not understood are simply ignored.
この文書では、ヘッダフィールドを「必須」すべてのSIPを定義していません。 SIPユーザエージェントのいずれかが「グループ」属性を理解していない場合したがって、標準SDPは、フォールバック機構、すなわち、理解されていない属性は単に無視され、使用されなければなりません。
This situation does not represent a problem, because grouping requests are always performed by offerers and not by answerers. If the offerer does not support "group", this attribute will simply not be used.
グループ化の要求は常に回答で申し出人によって行われていないので、このような状況では、問題を示すものではありません。オファー側は、「グループ」をサポートしていない場合、この属性は単純に使用されることはありません。
The answerer will ignore the "group" attribute since it does not understand it and will also ignore the "mid" attribute. For LS semantics, the answerer might decide to perform, or not to perform, synchronization between media streams.
回答は、それはそれを理解していないため、「グループ」属性を無視し、また、「半ば」属性を無視します。 LSセマンティクスについては、回答は、メディアストリーム間の同期を実行するために、または実行しないと決定するかもしれません。
For FID semantics, the answerer will consider the session to consist of several media streams.
FID意味論について、回答には、いくつかのメディアストリームから成るようにセッションを検討します。
Different implementations will behave in different ways.
異なる実装は異なる方法で動作します。
In the case of audio and different "m" lines for different codecs, an implementation might decide to act as a mixer with the different incoming RTP sessions, which is the correct behavior.
異なるコーデックのオーディオと異なる「M」の行の場合、実装は、正しい動作であり、異なる着信RTPセッションとミキサーとして作用することを決定するかもしれません。
An implementation might also decide to refuse the request (e.g., 488 Not Acceptable Here, or 606 Not Acceptable), because it contains several "m" lines. In this case, the server does not support the type of session that the caller wanted to establish. In case the client is willing to establish a simpler session anyway, the client can re-try the request without the "group" attribute and with only one "m" line per flow.
実装はまた、要求を拒否することを決定するかもしれない（例えば、ここでは488受け入れられない、または606受け入れられない）、それはいくつかの「M」の行が含まれているため。この場合、サーバは、発信者が確立したかったセッションの種類をサポートしていません。場合は、クライアントはとにかくシンプルなセッションを確立するために喜んで、クライアントが「グループ」属性なし、フローごとに1つだけの「M」の行で、要求を再試行することができます。
Section 3 (Overview of Operation) has been added for clarity. The AMR and GSM acronyms are now expanded on their first use. The examples now use IP addresses in the range suitable for examples.
セクション3（動作の概要）わかりやすくするために追加されました。 AMRとGSM頭字語は今、彼らの最初の使用時に展開されます。例を実施例に適した範囲内のIPアドレスを使用します。
The grouping mechanism is now defined as an extensible framework. Earlier, RFC 3388 [RFC3388] used to discourage extensions to this mechanism in favor of using new session description protocols.
グループ化機構は、現在の拡張可能なフレームワークとして定義されます。以前、RFC 3388 [RFC3388]は、新たなセッション記述プロトコルを使用しての賛成でこのメカニズムへの拡張を阻止するために使用しました。
Given a semantics value, RFC 3388 [RFC3388] used to restrict "m" line identifiers to only appear in a single group using that semantics. That restriction has been lifted in this specification. From conversations with implementers, existing (i.e., legacy) implementations enforce this restriction on a per-semantics basis. That is, they only enforce this restriction for supported semantics. Because of the nature of existing semantics, implementations will only use a single "m" line identifier across groups using a given semantics even after the restriction has been lifted by this specification. Consequently, the lifting of this restriction will not cause backward-compatibility problems, because implementations supporting new semantics will be updated to not enforce this restriction at the same time as they are updated to support the new semantics.
セマンティクス値が与えられると、RFC 3388 [RFC3388]は唯一そのセマンティクスを使用して単一のグループに表示されるように「M」の行識別子を制限するために使用されます。この制限は、この仕様で持ち上げられました。実装者との会話から、既存の（すなわち、レガシー）の実装ごとのセマンティクスに基づいて、この制限を強制します。つまり、彼らは唯一サポートされているセマンティクスのために、この制限を適用します。なぜなら、既存のセマンティクスの性質のため、実装が唯一の制限は、本明細書によって持ち上げられた後も所定のセマンティクスを使用してグループ間で単一の「M」の行識別子を使用します。新しいセマンティクスをサポートする実装は、それらが新しいセマンティクスをサポートするように更新されていると同時に、この制限を強制しないように更新されるため、結果的に、この制限の解除は、下位互換性の問題が発生することはありません。
Using the "group" parameter with FID semantics, an entity that managed to modify the session descriptions exchanged between the participants to establish a multimedia session could force the participants to send a copy of the media to any destination of its choosing.
FID意味論と「グループ」パラメータ、セッション記述を修正するために管理し、その選択した任意の宛先へのメディアのコピーを送信するために参加者を強制することができ、マルチメディアセッションを確立するために、参加者間で交換されるエンティティを使用します。
Integrity mechanisms provided by protocols used to exchange session descriptions and media encryption can be used to prevent this attack. In SIP, Secure/Multipurpose Internet Mail Extensions (S/MIME) [RFC5750] and Transport Layer Security (TLS) [RFC5246] can be used to protect session description exchanges in an end-to-end and a hop-by-hop fashion, respectively.
交換セッションの説明とメディアの暗号化に使用されるプロトコルが提供する整合性のメカニズムは、この攻撃を防ぐために使用することができます。 SIPにおいては、セキュア/多目的インターネットメール拡張（S / MIME）[RFC5750]とトランスポート層セキュリティ（TLS）[RFC5246]は、セッション記述の交換を保護するために使用することができるエンドツーエンドとホップバイホップファッション、それぞれ。
This document defines two SDP attributes: "mid" and "group".
「半ば」と「グループ」：このドキュメントでは、2つのSDP属性を定義します。
The "mid" attribute is used to identify media streams within a session description, and its format is defined in Section 4.
「中間」属性はセッション記述内のメディアストリームを識別するために使用され、そのフォーマットはセクション4で定義されています。
The "group" attribute is used for grouping together different media streams, and its format is defined in Section 5.
「グループ」属性が共に異なるメディアストリームをグループ化するために使用され、そのフォーマットはセクション5で定義されています。
This document defines a framework to group media lines in SDP using different semantics. Semantics values to be used with this framework are registered by the IANA following the Standards Action policy [RFC5226].
この文書は、異なるセマンティクスを使用してSDP内のグループメディアラインにフレームワークを定義します。このフレームワークで使用するセマンティック値は標準アクションポリシー[RFC5226]以下のIANAによって登録されています。
The IANA Considerations section of the RFC MUST include the following information, which appears in the IANA registry along with the RFC number of the publication.
RFCのIANA Considerations部は、出版のRFC番号とともにIANAレジストリに表示される次の情報を含まなければなりません。
o A brief description of the semantics.
意味論の簡単な説明、O。
o Token to be used within the "group" attribute. This token may be of any length, but SHOULD be no more than four characters long.
Oトークンは、「グループ」属性内で使用されます。このトークンは、任意の長さのものであってもよいが、4つ以下の文字長さであるべきです。
o Reference to a standards track RFC.
標準トラックRFCにOリファレンス。
The following are the current entries in the registry:
以下は、レジストリ内の現在のエントリです。
Semantics Token Reference
--------------------------------- ----- -----------
Lip Synchronization LS [RFC5888]
Flow Identification FID [RFC5888]
Single Reservation Flow SRF [RFC3524]
Alternative Network Address Types ANAT [RFC4091]
Forward Error Correction FEC [RFC4756]
Decoding Dependency DDP [RFC5583]
Goran Eriksson and Jan Holler were coauthors of RFC 3388 [RFC3388].
ゴラン・エリクソンとJan大声はRFC 3388 [RFC3388]の共著者でした。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264]ローゼンバーグ、J.とH. Schulzrinneと、RFC 3264、2002年6月 "セッション記述プロトコル（SDP）とのオファー/アンサーモデル"。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]ハンドリー、M.、ヤコブソン、V.、およびC.パーキンス、 "SDP：セッション記述プロトコル"、RFC 4566、2006年7月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 5226、2008年5月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]クロッカー、D.、およびP. Overell、 "構文仕様のための増大しているBNF：ABNF"、STD 68、RFC 5234、2008年1月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン1.2"、RFC 5246、2008年8月。
[RFC5750] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Certificate Handling", RFC 5750, January 2010.
[RFC5750] Ramsdell、B.とS.ターナー、 "（S / MIME）バージョン3.2証明書の取り扱い/セキュア多目的インターネットメール拡張"、RFC 5750、2010年1月。
[RFC1889] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.
[RFC1889] Schulzrinneと、H.、Casner、S.、フレデリック、R.、およびV.ヤコブソン、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、RFC 1889、1996年1月。
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RFC2326] SchulzrinneとH.とラオとA.、およびR. Lanphier、 "リアルタイムのストリーミングプロトコル（RTSP）"、RFC 2326、1998年4月。
[RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H. Schulzrinne, "Grouping of Media Lines in the Session Description Protocol (SDP)", RFC 3388, December 2002.
[RFC3388]キャマリロ、G.、エリクソン、G.、大声、J.、およびH. Schulzrinneと、 "セッション記述プロトコルにおけるメディア行のグループ化（SDP）"、RFC 3388、2002年12月。
[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：リアルタイムアプリケーションのためのトランスポートプロトコル"、STD 64、RFC 3550、2003年7月。
[RFC4733] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals", RFC 4733, December 2006.
[RFC4733] Schulzrinneと、H.、およびT.テイラー、 "DTMFケタ、電話トーン、およびテレフォニーシグナルのためのRTPペイロード"、RFC 4733、2006年12月。
Authors' Addresses
著者のアドレス
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 FINLAND
ゴンサロ・カマリロエリクソンHirsalantie 11 Jorvas 02420 FINLAND
EMail: Gonzalo.Camarillo@ericsson.com
メールアドレス：Gonzalo.Camarillo@ericsson.com
Henning Schulzrinne Columbia University 1214 Amsterdam Avenue New York, NY 10027 USA
ヘニングSchulzrinneとコロンビア大学1214アムステルダムアベニュー、ニューヨーク、NY 10027 USA
EMail: schulzrinne@cs.columbia.edu
メールアドレス：schulzrinne@cs.columbia.edu