[要約] RFC 5888は、SDPグループ化フレームワークに関する規格であり、SDPセッションのグループ化と関連付けをサポートするための方法を提供します。このRFCの目的は、SDPセッションの柔軟性と拡張性を向上させることです。
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
セッション説明プロトコル（SDP）グループ化フレームワーク
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」行をグループ化するフレームワークを定義します。このフレームワークでは、「グループ」と「Mid」SDP属性を使用します。どちらもこの仕様で定義されています。さらに、2つの異なる目的のためにフレームワークを使用する方法を指定します。リップ同期と、さまざまな輸送アドレスのいくつかのメディアストリームで構成されるメディアフローを受信するためです。このドキュメントは、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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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]セッションの説明には、通常、1つ以上のメディアラインが含まれており、一般に「M」行として知られています。セッションの説明に複数の「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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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].
このドキュメントでは、2つの標準セマンティクスを定義します：リップ同期（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」行は、グループラインに表示されるかどうかにかかわらず、「MID」属性で識別する必要があります。セッションの説明に、「中間」の識別がない少なくとも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 = group」行が存在しなかったかのように機能します。グループ化された「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 =グループ」行は、同じセマンティクスまたは異なるセマンティクスを使用できます。「MID」属性によって識別される「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.
次の例は、マルチキャストである会議のセッションの説明を示しています。最初のメディアストリーム（MID：1）には、英語で話すスピーカーの声が含まれています。2番目のメディアストリーム（MID：2）にはビデオコンポーネントが含まれており、3番目の（MID：3）メディアストリームには、彼女が言っていることのスペイン語への翻訳があります。1番目と2番目のメディアストリームを同期する必要があります。
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番目のメディアストリームはグループラインには存在しませんが、以前に記載されているように、「MID」属性（MID：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.
以前の定義は最も一般的なケースをカバーしていますが、1つのメディアインスタンス（オーディオストリームやビデオストリームなど）が複数のRTPセッションを使用して送信される状況があります。この種の状況の2つの例（他の多くの場合）は、セッション開始プロトコル（SIP; [RFC3261]）を使用したセルラーシステムと、音声とは異なるホストのデュアルトーン多頻度（DTMF）トーンを受け取るシステムです。
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トーンを収集するネットワークにアプリケーションサーバーを持つことが一般的です。この状況では、2つのRTPセッションを確立する必要があります。1つは音声用、もう1つはDTMFトーン用です。両方の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を使用する場合、メディアフローは1つ以上の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つのコーデックのみを使用していると想定されています。このコーデックはセッション中に動的に変化する可能性がありますが、特定の瞬間には、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」ラインを1つずつチェックします。特定の「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ユーザーエージェントによって送信される場合があります。ユーザーエージェントは、ポート30000およびポート30002のAMR（Adaptive Multi-Rate）のGSM（モバイルコミュニケーション用のグローバルシステム）をサポートします。リモートパーティがGSMを送信すると、RTPパケットがポート番号30000に送信されます。、パケットはポート30002に送信されます。リモートパーティは、セッションの途中で両方のコーデックを動的に切り替えることができることに注意してください。ただし、この例では、一度に1つのメディアストリームのみが音声を持っています。もう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.) 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.
（FMTPラインのラインブレイクは、RFCのフォーマット制限に対応します。SDPには継続ラインがありません。）前の例では、システムは異なるポート番号の同じ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であるトランスコダーを使用します。Cellular端子には、PCMのサポートを提供するためのSDP説明にTranscoder IPアドレスが含まれています。リモートシステムはAMRを端末に直接送信しますが、PCMはトランスコダーに送信されます。トランスコダーは、着信PCMオーディオをAMRに変換して端末に送信するように構成されます（どんな方法でも推奨される方法を使用します）。
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つの方向で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説明を受信したユーザーエージェントは、特定の瞬間に、PCM U-Lawをポート番号30000に送信するか、PCM A-Lawをポート番号30002に送信できることを知っています。ただし、メディアエージェントは反対側も知っていることも知っています。PCM U-Law（ペイロード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-Law（ペイロード0）を送信している場合、ポート30000で192.0.2.1にRTPパケットを送信し、ポート20000で192.0.2.2に送信します。「m」行）。PCM A-Law（ペイロード8）を送信する場合、ポート30002で192.0.2.1にRTPパケットを送信し、ポート20000（2番目と3番目の「M」ライン）で192.0.2.2に送信します。
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説明を生成したシステムは、ポート30000のPCM U-Lawとポート30002のPCM A-Lawをサポートしています。さらに、会話を記録し、IPアドレスが192.0.2.2であるアプリケーションサーバーを使用します。アプリケーションサーバーはメディアコンテンツを理解する必要がないため、使用されているコーデックとペイロードタイプに関係なく、常にメディアストリームのコピーを受信します。そのため、アプリケーションサーバーは、特定の瞬間に使用されているコーデックに関係なく常にオーディオストリームのコピーを受信します（実際に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.
リモートパーティは、PCMエンコード音声（ペイロード0）を192.0.2.1に送信し、テレフォニーイベントとしてエンコードされたDTMFトーンを192.0.2.2に送信します。音声または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セマンティクスは、アプリケーションが一度に1つのコーデックのみを使用する場合に役立ちます。異なるコーデックを同時に使用して同じメディアをエンコードするアプリケーションは、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
C = IP4 233.252.0.1/127/3
is equivalent to the following three "c" lines:
次の3つの「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
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
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 8
If two "m" lines are grouped using FID, they MUST differ in their transport addresses (i.e., IP address plus port).
FIDを使用して2つの「M」ラインがグループ化されている場合、輸送アドレス（つまり、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]は、この目的に使用できるプロトコルの1つです。
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）を提供します。ただし、[RFC3264]で説明されているように、これら3つのメッセージのうち2つだけが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.
「Mid」属性は、特定のメディアストリームの識別子です。したがって、オファーの「中間」の値は、答えの「中間」値と同じでなければなりません。その上、後続のオファー（例えば、re 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 =" line）が、回答者の説明の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.
「Mid」属性は「M」ラインにラベルを付ける手段を提供するため、nth "m"行を一致させるのではなく、「Mid」ラベルを使用してメディアアラインメントを実行することが可能です。ただし、これは利益をもたらさず、実装に複雑さを加えます。したがって、SIPシステムは、「グループ」または「Mid」属性の存在に関係なく、NTH行を一致させるメディアアライメントを実行する必要があります。
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を交換します。招待状には、以下の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.
「m」線のアライメントはnth行の一致に基づいて実行されるため、最初のストリームには招待状に「Mid：1」、200 OKで「Mid：2」がありました。したがって、アプリケーションは、SDP説明に含まれるすべての「MID」および「グループ」行を無視します。
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 = group」行を含むオファーを受け取る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交換を提供するため、グループ化を要求する回答者は、「グループ」属性が提供者によって受け入れられたかどうかを知りません。メディアラインをグループ化したい回答者は、最初のものに応答した後に別のオファーを発行します（たとえば、re inviteで）。
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.
以下の例は、ポート番号をゼロに設定することにより、Calleeが発信者が提供するメディアストリームをどのように拒否するかを示しています。そのメディアストリームに対応する「ミッド」値は、回答の「グループ」値から削除されます。
SDP description in the INVITE from caller to callee:
発信者からCalleeへの招待での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:
CalleeからCallerへの招待状での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.
「グループ」と「MID」を理解しているが、特定のセッションでこれらの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 =グループ」行の形でその回答に追加する必要があります。
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:
それを提供するサーバーは、LSではなくFIDをサポートします。以下の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
V = 0 O = Laura 289083124 289083124 in ip4 in ip4 sixteen.example.com c = in ip4 192.0.2.1 t = 0 0 a =グループ：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ユーザーエージェントの1つが「グループ」属性を理解していない場合、標準の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セマンティクスの場合、Answererは、メディアストリーム間の同期を実行するか、実行しないことを決定する場合があります。
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.
また、実装は、いくつかの「m」行が含まれているため、リクエストを拒否することも決定する場合があります（ここでは受け入れられない、または606は受け入れられない606）。この場合、サーバーは発信者が確立したいセッションの種類をサポートしていません。とにかく、クライアントがよりシンプルなセッションを確立する意思がある場合、クライアントは「グループ」属性なしでリクエストを再試行し、フローごとに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属性を定義します：「MID」と「グループ」。
The "mid" attribute is used to identify media streams within a session description, and its format is defined in Section 4.
「MID」属性は、セッションの説明内でメディアストリームを識別するために使用され、その形式はセクション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に関する考慮事項セクションには、IANAレジストリに表示されるRFC番号とともに、次の情報を含める必要があります。
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.
o RFCを追跡する標準への参照。
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].
Goran ErikssonとJan HollerはRFC 3388 [RFC3388]の共著者でした。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INTIANIATION Protocol」、RFC 3261、2002年6月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264] Rosenberg、J。およびH. Schulzrinne、「セッション説明プロトコル（SDP）のオファー/回答モデル」、RFC 3264、2002年6月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「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] Crocker、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] Dierks、T。およびE. Rescorla、「The Transport Layer Security（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. Turner、「Secure/Multipurpose Internet Mail Extensions（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.、Frederick、R。、およびV. Jacobson、「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.、Rao、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] Camarillo、G.、Eriksson、G.、Holler、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.、Frederick、R。、およびV. Jacobson、「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. Taylor、「DTMFディジット、テレフォニートーン、テレフォニー信号のRTPペイロード」、RFC 4733、2006年12月。
Authors' Addresses
著者のアドレス
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 FINLAND
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420フィンランド
EMail: Gonzalo.Camarillo@ericsson.com
Henning Schulzrinne Columbia University 1214 Amsterdam Avenue New York, NY 10027 USA
ヘニングシュルツリンコロンビア大学1214アムステルダムアベニューニューヨーク、ニューヨーク10027アメリカ
EMail: schulzrinne@cs.columbia.edu