[要約] RFC 5583は、SDPでメディアデコードの依存関係をシグナリングするための仕様です。目的は、SDPセッションのメディアデコードの依存関係を明確にし、正確なメディアストリームの再生を保証することです。
Network Working Group T. Schierl
Request for Comments: 5583 Fraunhofer HHI
Category: Standards Track S. Wenger
Independent
July 2009
Signaling Media Decoding Dependency in the Session Description Protocol (SDP)
セッション説明プロトコル（SDP）のシグナリングメディアデコード依存関係
Abstract
概要
This memo defines semantics that allow for signaling the decoding dependency of different media descriptions with the same media type in the Session Description Protocol (SDP). This is required, for example, if media data is separated and transported in different network streams as a result of the use of a layered or multiple descriptive media coding process.
このメモは、セッション説明プロトコル（SDP）で同じメディアタイプを使用して、異なるメディアの説明のデコード依存性を信号することを可能にするセマンティクスを定義します。これは、たとえば、階層化されたまたは複数の記述メディアコーディングプロセスの使用の結果として、メディアデータが異なるネットワークストリームで分離および輸送される場合に必要です。
A new grouping type "DDP" -- decoding dependency -- is defined, to be used in conjunction with RFC 3388 entitled "Grouping of Media Lines in the Session Description Protocol". In addition, an attribute is specified describing the relationship of the media streams in a "DDP" group indicated by media identification attribute(s) and media format description(s).
新しいグループタイプ「DDP」 - デコード依存関係 - が定義されており、「セッション説明プロトコルのメディアラインのグループ化」と題されたRFC 3388と組み合わせて使用されます。さらに、メディア識別属性とメディア形式の説明で示される「DDP」グループのメディアストリームの関係を説明する属性が指定されています。
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびこのドキュメントの公開日（http://trustee.ietf.org/license-info）に有効なIETFドキュメントに関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの貢献からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得しないと、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版または英語以外の言語に翻訳する。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Definitions .....................................................4
4. Motivation, Use Cases, and Architecture .........................5
4.1. Motivation .................................................5
4.2. Use Cases ..................................................7
5. Signaling Media Dependencies ....................................7
5.1. Design Principles ..........................................7
5.2. Semantics ..................................................8
5.2.1. SDP Grouping Semantics for Decoding Dependency ......8
5.2.2. "depend" Attribute for Dependency Signaling
per Media-Stream ....................................8
6. Usage of New Semantics in SDP ..................................10
6.1. Usage with the SDP Offer/Answer Model .....................10
6.2. Declarative usage .........................................12
6.3. Usage with AVP and SAVP RTP Profiles ......................12
6.4. Usage with Capability Negotiation .........................12
6.5. Examples ..................................................12
7. Security Considerations ........................................15
8. IANA Considerations ............................................15
9. Informative Note on "The SDP (Session Description Protocol)
Grouping Framework" ............................................16
10. References ....................................................16
10.1. Normative References .....................................16
10.2. Informative References ...................................17
Appendix A. Acknowledgements .....................................18
An SDP session description may contain one or more media descriptions, each identifying a single media stream. A media description is identified by one "m=" line. Today, if more than one "m=" lines exist indicating the same media type, a receiver cannot identify a specific relationship between those media.
SDPセッションの説明には、それぞれが単一のメディアストリームを識別する1つ以上のメディアの説明が含まれる場合があります。メディアの説明は、1つの「m =」行で識別されます。今日、同じメディアタイプを示す複数の「m =」行が存在する場合、レシーバーはそれらのメディア間の特定の関係を識別できません。
A Multiple Description Coding (MDC) or layered Media Bitstream contains, by definition, one or more Media Partitions that are conveyed in their own media stream. The cases we are interested in are layered and MDC Bitstreams with two or more Media Partitions. Carrying more than one Media Partition in its own session is one of the key use cases for employing layered or MDC-coded media. Senders, network elements, or receivers can suppress sending/forwarding/subscribing/decoding individual Media Partitions and still preserve perhaps suboptimal, but still useful, media quality.
複数の説明コーディング（MDC）または階層化されたメディアビットストリームには、定義上、独自のメディアストリームで伝達される1つ以上のメディアパーティションが含まれています。私たちが興味を持っているケースは、2つ以上のメディアパーティションを備えたレイヤードとMDCビットストリームです。独自のセッションで複数のメディアパーティションを運ぶことは、層状またはMDCコード化されたメディアを採用するための重要なユースケースの1つです。送信者、ネットワーク要素、または受信機は、個々のメディアパーティションの送信/転送/サブスクライティング/デコードを抑制し、おそらく最適ではあるが、それでも有用なメディア品質を保持できます。
One property of all Media Bitstreams relevant to this memo is that their Media Partitions have a well-defined usage relationship. For example, in layered coding, "higher" Media Partitions are useless without "lower" ones. In MDC coding, Media Partitions are complementary -- the more Media Partitions one receives, the better a reproduced quality may be. This document defines an SDP extension to indicate such a decoding dependency.
このメモに関連するすべてのメディアビットストリームの1つのプロパティは、メディアパーティションが明確に定義された使用関係を持っていることです。たとえば、階層化されたコーディングでは、「より高い」メディアパーティションが「低い」ものなしで役に立たない。MDCコーディングでは、メディアパーティションは補完的です。メディアパーティションがより多く受信するほど、品質が再現される可能性があります。このドキュメントでは、このようなデコード依存関係を示すSDP拡張機能を定義します。
The trigger for the present memo has been the standardization process of the RTP payload format for the Scalable Video Coding (SVC) extension to ITU-T Rec. H.264 / MPEG-4 AVC [AVT-RTP-SVC]. When drafting [AVT-RTP-SVC], it was observed that the aforementioned lack in signaling support is one that is not specific to SVC, but applies to all layered or MDC codecs. Therefore, this memo presents a generic solution. Likely, the second technology utilizing the mechanisms of this memo will be Multi-View video coding. In Multi-View Coding (MVC) [AVT-RTP-MVC], layered dependencies between views are used to increase the coding efficiency, and, therefore, the properties of MVC with respect to the SDP signaling are comparable to those of SVC.
現在のメモのトリガーは、ITU-T Recのスケーラブルビデオコーディング（SVC）拡張のRTPペイロード形式の標準化プロセスでした。H.264 / MPEG-4 AVC [AVT-RTP-SVC]。[AVT-RTP-SVC]を起草するとき、前述のシグナリングサポートの欠如はSVCに固有のものではなく、すべての層状またはMDCコーデックに適用されるものであることが観察されました。したがって、このメモは一般的なソリューションを提示します。おそらく、このメモのメカニズムを利用する2番目のテクノロジーは、マルチビュービデオコーディングです。マルチビューコーディング（MVC）[AVT-RTP-MVC]では、ビュー間の層状依存関係を使用してコーディング効率を向上させるため、SDPシグナル伝達に対するMVCの特性はSVCの特性に匹敵します。
The mechanisms defined herein are media transport protocol dependent, and applicable only in conjunction with the use of RTP [RFC3550].
ここで定義されているメカニズムは、メディアトランスポートプロトコルに依存し、RTP [RFC3550]の使用と組み合わせてのみ適用されます。
The SDP grouping of Media Lines of different media types is out of scope of this memo.
さまざまなメディアタイプのメディアラインの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 BCP 14, RFC 2119 [RFC2119].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、BCP 14、RFC 2119 [RFC2119]に記載されているように解釈される。
Media stream: As per [RFC4566].
メディアストリーム：[RFC4566]に従って。
Media Bitstream: A valid, decodable stream, containing all Media Partitions generated by the encoder. A Media Bitstream normally conforms to a media coding standard.
メディアビットストリーム：エンコーダによって生成されたすべてのメディアパーティションを含む有効でデコード可能なストリーム。メディアビットストリームは通常、メディアコーディング標準に適合します。
Media Partition: A subset of a Media Bitstream intended for independent transportation. An integer number of Media Partitions forms a Media Bitstream. In layered coding, a Media Partition represents one or more layers that are handled as a unit. In MDC coding, a Media Partition represents one or more descriptions that are handled as a unit.
メディアパーティション：独立した輸送を目的としたメディアビットストリームのサブセット。整数数のメディアパーティションがメディアビットストリームを形成します。階層化されたコーディングでは、メディアパーティションは、ユニットとして処理される1つ以上のレイヤーを表します。MDCコーディングでは、メディアパーティションは、ユニットとして処理される1つ以上の説明を表します。
Decoding dependency: The class of relationships Media Partitions have to each other. At present, this memo defines two decoding dependencies: layered coding and Multiple Description Coding.
依存関係の解読：関係のメディアパーティションのクラスは、互いに必要です。現在、このメモは、レイヤードコーディングと複数の説明コーディングの2つのデコード依存関係を定義しています。
Layered coding dependency: Each Media Partition is only useful (i.e., can be decoded) when all of the Media Partitions it depends on are available. The dependencies between the Media Partitions therefore create a directed graph. Note: normally, in layered coding, the more Media Partitions are employed (following the rule above), the better a reproduced quality is possible.
階層化されたコーディング依存関係：各メディアパーティションは、依存するすべてのメディアパーティションが利用可能である場合にのみ便利です（つまり、デコードできます）。したがって、メディアパーティション間の依存関係は、指示されたグラフを作成します。注：通常、階層化されたコーディングでは、より多くのメディアパーティションが採用されます（上記のルールに従って）、再現された品質が可能になります。
Multiple Description Coding (MDC) dependency: N of M Media Partitions are required to form a Media Bitstream, but there is no hierarchy between these Media Partitions. Most MDC schemes aim at an increase of reproduced media quality when more media partitions are decoded. Some MDC schemes require more than one Media Partition to form an Operation Point.
複数の説明コーディング（MDC）依存関係：MメディアパーティションのNは、メディアビットストリームを形成するために必要ですが、これらのメディアパーティション間に階層はありません。ほとんどのMDCスキームは、より多くのメディアパーティションがデコードされると、再現されたメディア品質の向上を目指しています。一部のMDCスキームでは、操作ポイントを形成するために複数のメディアパーティションが必要です。
Operation Point: In layered coding, a subset of a layered Media Bitstream that includes all Media Partitions required for reconstruction at a certain point of quality, error resilience, or another property, and that does not include any other Media Partitions. In MDC coding, a subset of an MDC Media Bitstream that is compliant with the MDC coding standard in question.
操作点：階層化されたコーディングでは、特定の品質、エラーの回復力、または他のプロパティでの再構築に必要なすべてのメディアパーティションを含む層状メディアビットストリームのサブセットであり、他のメディアパーティションは含まれません。MDCコーディングでは、問題のMDCコーディング標準に準拠したMDCメディアビットストリームのサブセット。
This memo is concerned with two types of decoding dependencies: layered and multi-description. The transport of layered and Multiple Description Coding share as key motivators the desire for media adaptation to network conditions, i.e., related to bandwidth, error rates, connectivity of endpoints in multicast or broadcast scenarios, and the like.
このメモは、レイヤードとマルチ説明の2種類のデコード依存関係に関係しています。主要な動機としての層状および複数の説明コーディングの輸送は、ネットワーク条件へのメディア適応の欲求、つまり帯域幅、エラー率、マルチキャストやブロードキャストシナリオのエンドポイントの接続性などに関連しています。
o Layered decoding dependency:
o 層状デコード依存関係：
In layered coding, the partitions of a Media Bitstream are known as media layers or simply layers. One or more layers may be transported in different media streams in the sense of [RFC4566]. A classic use case is known as receiver-driven layered multicast, in which a receiver selects a combination of media streams in response to quality or bit-rate requirements.
階層化されたコーディングでは、メディアビットストリームのパーティションはメディアレイヤーまたは単にレイヤーとして知られています。[RFC4566]という意味で、1つ以上の層をさまざまなメディアストリームで輸送できます。古典的なユースケースは、レシーバー駆動型の層状マルチキャストとして知られています。このマルチキャストでは、レシーバーは品質またはビットレートの要件に応じてメディアストリームの組み合わせを選択します。
Back in the mid 1990s, the then-available layered media formats and codecs envisioned primarily (or even exclusively) a one-dimensional hierarchy of layers. That is, each so-called enhancement layer referred to exactly one layer "below". The single exception has been the base layer, which is self-contained. Therefore, the identification of one enhancement layer fully specifies the Operation Point of a layered coding scheme, including knowledge about all the other layers that need to be decoded.
1990年代半ばに戻って、当時利用可能な階層化されたメディア形式とコーデックは、主に（または排他的に）層の1次元階層を想定していました。つまり、いわゆる強化層は、「以下」の正確な1つのレイヤーを参照しています。単一の例外は基本層であり、自己完結型です。したがって、1つの拡張層の識別は、デコードする必要がある他のすべての層に関する知識を含む、層状コーディングスキームの動作点を完全に指定します。
SDP [RFC4566] contains rudimentary support for exactly this use case and media formats, in that it allows for signaling a range of transport addresses in a certain media description. By definition, a higher transport address identifies a higher layer in the one-dimensional hierarchy. A receiver needs only to decode data conveyed over this transport address and lower transport addresses to decode this Operation Point.
SDP [RFC4566]には、特定のメディアの説明でさまざまな輸送アドレスを通知できるという点で、まさにこのユースケースとメディア形式に対する基本的なサポートが含まれています。定義上、より高い輸送アドレスは、1次元階層のより高い層を識別します。受信者は、この輸送アドレスを介して伝えられたデータをデコードするだけで、この動作点をデコードするために輸送アドレスを下げます。
Newer media formats depart from this simple one-dimensional hierarchy, in that highly complex (at least tree-shaped) dependency hierarchies can be implemented. Compelling use cases for these complex hierarchies have been identified by industry. Support for it is therefore desirable. However, SDP, in its current form, does not allow for the signaling of these complex relationships. Therefore, receivers cannot make an informed decision on which layers to subscribe (in case of layered multicast).
新しいメディア形式は、この単純な1次元階層から離れています。これらの複雑な階層の説得力のあるユースケースは、業界によって特定されています。したがって、それに対するサポートが望ましいです。ただし、SDPは現在の形式では、これらの複雑な関係のシグナル伝達を許可していません。したがって、レシーバーは、サブスクライブするレイヤーについて（階層化されたマルチキャストの場合）に情報に基づいた決定を下すことができません。
Layered decoding dependencies may also exist in a Multi-View Coding environment. Views may be coded using inter-view dependencies to increase coding efficiency. This results in Media Bitstreams, that logically may be separated into Media Partitions representing different views of the reconstructed video signal. These Media Partitions cannot be decoded independently, and, therefore, other Media Partitions are required for reconstruction. To express this relationship, the signaling needs to express the dependencies of the views, which in turn are Media Partitions in the sense of this document.
マルチビューコーディング環境には、階層化されたデコード依存関係も存在する場合があります。ビューは、インタービューの依存関係を使用してコーディングされ、コーディング効率を向上させることができます。これにより、メディアビットストリームが発生します。これは、再構築されたビデオ信号のさまざまなビューを表すメディアパーティションに論理的に分離される可能性があります。これらのメディアパーティションは独立してデコードすることはできないため、再構築には他のメディアパーティションが必要です。この関係を表現するには、シグナル伝達は、この文書の意味でのメディアパーティションであるビューの依存関係を表現する必要があります。
o Multiple descriptive decoding dependency:
o 複数の記述デコード依存関係：
In the most basic form of MDC, each Media Partition forms an independent representation of the media. That is, decoding of any of the Media Partitions yields useful reproduced media data. When more than one Media Partition is available, then a decoder can process them jointly, and the resulting media quality increases. The highest reproduced quality is available if all original Media Partitions are available for decoding.
MDCの最も基本的な形式では、各メディアパーティションはメディアの独立した表現を形成します。つまり、メディアパーティションのいずれかをデコードすると、有用な再現されたメディアデータが得られます。複数のメディアパーティションが利用可能な場合、デコーダーはそれらを共同で処理でき、結果として生じるメディアの品質が向上します。すべての元のメディアパーティションがデコードできる場合、最高の再現された品質が利用可能です。
More complex forms of Multiple Description Coding can also be envisioned, i.e., where, as a minimum, N-out-of-M total Media Partitions need to be available to allow meaningful decoding.
複数の説明コーディングのより複雑な形式も想定することができます。つまり、最低限、意味のあるデコードを可能にするために、最小限のn-outメディアパーティションを利用できる必要があります。
MDC has not yet been embraced heavily by the media standardization community, though it is the subject of a lot of academic research. As an example, we refer to [MDC].
MDCは、メディア標準化コミュニティにまだ頻繁に受け入れられていませんが、多くの学術研究の主題です。例として、[MDC]を参照します。
In this memo, we cover MDC because we a) envision that MDC media formats will come into practical use within the lifetime of this memo, and b) the solution for its signaling is very similar to the one of layered coding.
このメモでは、MDCをカバーしています。これは、a）MDCメディア形式がこのメモの寿命の中で実用化されることを想定しており、b）そのシグナル伝達の解決策は層状コーディングのソリューションと非常に似ているからです。
o Other decoding dependency relationships:
o その他のデコード依存関係関係：
At the time of writing, no decoding dependency relationships beyond the two mentioned above have been identified that would warrant standardization. However, the mechanisms of this memo could be extended by introducing new codepoints for new decoding dependency types. If such an extension becomes necessary, as formally required in Section 5.2.2, the new decoding dependency type MUST be documented in an IETF Standards-Track document.
執筆時点では、標準化を保証する上記の2つを超える依存関係の関係が特定されていません。ただし、このメモのメカニズムは、新しいデコード依存型タイプの新しいコードポイントを導入することで拡張できます。セクション5.2.2で正式に必要とされるように、このような拡張機能が必要になる場合、新しいデコード依存関係タイプはIETF標準トラックドキュメントに文書化する必要があります。
o Receiver-driven layered multicast:
o レシーバー駆動型の層状マルチキャスト：
This technology is discussed in [RFC3550] and references therein. We refrain from elaborating further; the subject is well known and understood.
この技術は[RFC3550]とその参照で説明されています。私たちはさらに詳しく説明することを控えます。主題はよく知られ、理解されています。
o Multiple end-to-end transmission with different properties:
o 異なるプロパティを備えた複数のエンドツーエンドトランスミッション：
Assume a unicast and point-to-point topology, wherein one endpoint sends media to another. Assume further that different forms of media transmission are available. The difference may lie in the cost of the transmission (free, charged), in the available protection (unprotected/secure), in the quality of service (QoS) (guaranteed quality / best effort), or other factors.
ユニキャストとポイントツーポイントトポロジを仮定します。さらに、さまざまな形式のメディア送信が利用可能であると仮定します。違いは、送信のコスト（無料、充電された）、利用可能な保護（保護されていない /安全な）、サービス品質（QOS）（保証された品質 /ベストエフェクト）、またはその他の要因にある場合があります。
Layered and MDC coding allows matching of the media characteristics to the available transmission path(s). For example, in layered coding, it makes sense to convey the base layer over high QoS. Enhancement layers, on the other hand, can be conveyed over best effort, as they are "optional" in their characteristic -- nice to have, but non-essential for media consumption. In a different scenario, the base layer may be offered in a non-encrypted session as a free preview. An encrypted enhancement layer references this base layer and allows optimal quality play-back; however, it is only accessible to users who have the key, which may have been distributed by a conditional access mechanism.
層状およびMDCコーディングにより、メディア特性を使用可能な送信パスに一致させることができます。たとえば、階層化されたコーディングでは、高いQosでベース層を伝えることは理にかなっています。一方、拡張層は、特徴が「オプション」であるため、最善の努力を払うことができます。別のシナリオでは、無料プレビューとして、暗号化されていないセッションでベースレイヤーを提供することができます。暗号化された拡張層は、このベースレイヤーを参照し、最適な品質のプレイバックを可能にします。ただし、キーを持っているユーザーは条件付きアクセスメカニズムによって配布されている可能性があるユーザーのみがアクセスできます。
The dependency signaling is only feasible between media descriptions described with an "m="-line and with an assigned media identification attribute ("mid"), as defined in [RFC3388]. All media descriptions grouped according to this specification MUST have the same media type. Other dependencies relations expressed by SDP grouping have to be addressed in other specifications. A media description MUST NOT be part of more than one group of the grouping type defined in this specification.
[RFC3388]で定義されているように、依存関係のシグナル伝達は、「M =」ラインと割り当てられたメディア識別属性（「MID」）で説明されているメディアの説明の間でのみ実行可能です。この仕様に従ってグループ化されたすべてのメディアの説明には、同じメディアタイプが必要です。SDPグループによって表明されたその他の依存関係は、他の仕様で対処する必要があります。メディアの説明は、この仕様で定義されているグループタイプの複数のグループの一部であってはなりません。
This specification defines a new grouping semantic Decoding Dependency "DDP":
この仕様は、新しいグループ化セマンティックデコード依存関係「DDP」を定義します。
DDP associates a media stream, identified by its mid attribute, with a DDP group. Each media stream MUST be composed of an integer number of Media Partitions. A media stream is identified by a session-unique media format description (RTP payload type number) within a media description. In a DDP group, all media streams MUST have the same type of decoding dependency (as signaled by the attribute defined in Section 5.2.2). All media streams MUST contain at least one Operation Point. The DDP group type informs a receiver about the requirement for handling the media streams of the group according to the new media level attribute "depend", as defined in Section 5.2.2.
DDPは、中間属性によって識別されたメディアストリームをDDPグループと関連付けます。各メディアストリームは、整数数のメディアパーティションで構成されている必要があります。メディアストリームは、メディアの説明内でセッションとユニークのメディア形式の説明（RTPペイロードタイプ番号）によって識別されます。DDPグループでは、すべてのメディアストリームには、同じタイプのデコード依存関係を持つ必要があります（セクション5.2.2で定義されている属性によって示されています）。すべてのメディアストリームには、少なくとも1つの操作ポイントを含める必要があります。DDPグループタイプは、セクション5.2.2で定義されているように、新しいメディアレベルの属性「依存」に従って、グループのメディアストリームを処理するための要件について受信者に通知します。
When using multiple codecs, e.g., for the Offer/Answer model, the media streams MUST have the same dependency structure, regardless of which media format description (RTP payload type number) is used.
複数のコーデックを使用する場合、たとえば、オファー/回答モデルの場合、メディアストリームは、どのメディア形式の説明（RTPペイロードタイプ番号）が使用されるかに関係なく、同じ依存関係構造を持つ必要があります。
This memo defines a new media-level attribute, "depend", with the following ABNF [RFC5234]. The identification-tag is defined in [RFC3388]. In the following ABNF, fmt, token, SP, and CRLF are used as defined in [RFC4566].
このメモは、次のABNF [RFC5234]を使用して、新しいメディアレベルの属性「依存」を定義します。識別タグは[RFC3388]で定義されています。次のABNFでは、[RFC4566]で定義されているように、FMT、トークン、SP、およびCRLFが使用されています。
<CODE BEGINS> Copyright (c) 2009 IETF Trust and the persons identified as authors of the code. All rights reserved.
<Code Begins> Copyright（c）2009 IETF TrustおよびCodeの著者として特定された人。全著作権所有。
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
変更とバイナリ形式での再配布と使用は、変更を伴うまたは伴わない場合、次の条件が満たされている場合が許可されています。
- Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
- ソースコードの再配布は、上記の著作権通知、この条件リスト、および次の免責事項を保持する必要があります。
- Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
- バイナリ形式の再配布は、上記の著作権通知、この条件のリスト、および分布に提供されたドキュメントおよび/またはその他の資料の次の免責事項を再現する必要があります。
- Neither the name of Internet Society, IETF or IETF Trust, nor the names of specific contributors, may be used to endorse or promote products derived from this software without specific prior written permission.
- インターネット社会、IETFまたはIETFトラストの名前も、特定の貢献者の名前も、特定の事前の書面による許可なしにこのソフトウェアから派生した製品を支持または宣伝するために使用することはできません。
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
このソフトウェアは、制限された著作権所有者と貢献者によって提供されます。商品性と特定の目的に対する適合性の暗黙の保証は否認されます。いかなる場合でも、著作権所有者または貢献者は、直接的、間接的、偶発的、特別な、模範的、または結果的な損害（代替品またはサービスの調達を含むがこれらに限定されない、使用の損失、データ、または利益に対して責任を負いません。ただし、契約、厳格責任、または不法行為（過失などを含む）であろうと、このソフトウェアの使用から何らかの形で発生するかどうかにかかわらず、責任の理論に起因します。
depend-attribute =
"a=depend:" dependent-fmt SP dependency-tag
*(";" SP dependent-fmt SP dependency-tag) CRLF
dependency-tag =
dependency-type *1( SP identification-tag ":"
fmt-dependency *("," fmt-dependency ))
dependency-type = "lay" / "mdc" / token
dependency-type = "lay" / "mdc" / token
dependent-fmt = fmt
fmt-dependency = fmt <CODE ENDS>
fmt-dependency = fmt <code end>
dependency-tag indicates one or more dependencies of one dependent-fmt in the media description. These dependencies are signaled as fmt-dependency values, which indicate fmt values of other media descriptions. These other media descriptions are identified by their identification-tag values in the depend-attribute. There MUST be exactly one dependency-tag indicated per dependent-fmt.
依存関係タグは、メディアの説明における1つの従属FMTの1つ以上の依存関係を示します。これらの依存関係は、他のメディアの説明のFMT値を示すFMT依存性値としてシグナル化されます。これらの他のメディアの説明は、依存関係の識別タグ値によって識別されます。依存FMTごとに示されている依存関係タグが正確に1つある必要があります。
dependent-fmt indicates the media format description, as defined in [RFC4566], that depends on one or more media format descriptions in the media description indicated by the value of the identification-tag within the dependency-tag.
依存型FMTは、[RFC4566]で定義されているメディア形式の説明を示します。これは、依存関係タグ内の識別タグの値によって示されるメディアの説明の1つ以上のメディア形式の説明に依存します。
fmt-dependency indicates the media format description in the media description identified by the identification-tag within the dependency-tag, on which the dependent-fmt of the dependent media description depends. In case a list of fmt-dependency values is given, any element of the list is sufficient to satisfy the dependency, at the choice of the decoding entity.
FMT依存性は、依存メディアの説明の依存FMTが依存する依存関係タグ内の識別タグによって識別されたメディアの説明のメディア形式の説明を示します。FMT依存の値のリストが与えられた場合、リストの任意の要素は、デコードエンティティを選択して、依存関係を満たすのに十分です。
The depend-attribute describes the decoding dependency. The depend-attribute MUST be followed by a sequence of dependent-fmt and the corresponding dependency-tag fields, which identify all related media format descriptions in all related media descriptions of the dependent-fmt. The attribute MAY be used with multicast as well as with unicast transport addresses. The following dependency-type values are defined in this memo:
依存関係は、デコード依存関係について説明します。依存属性の後に、依存型FMTのシーケンスと対応する依存関係タグフィールドが続く必要があります。これは、従属FMTの関連するすべてのメディア説明におけるすべての関連メディア形式の説明を識別します。属性は、マルチキャストとユニキャスト輸送アドレスで使用できます。次の依存関係型値は、このメモで定義されています。
o lay: Layered decoding dependency -- identifies the described media stream as one or more Media Partitions of a layered Media Bitstream. When "lay" is used, all media streams required for decoding the Operation Point MUST be identified by identification-tag and fmt-dependency following the "lay" string.
o レイ：レイヤードデコード依存関係 - 記載されているメディアストリームを、レイヤードメディアビットストリームの1つ以上のメディアパーティションとして識別します。「lay」を使用する場合、操作ポイントのデコードに必要なすべてのメディアストリームは、「レイ」文字列に続く識別タグとFMT依存性によって識別される必要があります。
o mdc: Multi-descriptive decoding dependency -- signals that the described media stream is part of a set of a MDC Media Bitstream. By definition, at least N-out-of-M media streams of the group need to be available to from an Operation Point. The values of N and M depend on the properties of the Media Bitstream and are not signaled within this context. When "mdc" is used, all required media streams for the Operation Point MUST be identified by identification-tag and fmt-dependency following the "mdc" string.
o MDC：多記述的デコード依存関係 - 説明されたメディアストリームがMDCメディアビットストリームのセットの一部であることを示しています。定義上、グループの少なくともn-out-of-ofメディアストリームは、操作ポイントから利用できる必要があります。nとmの値は、メディアビットストリームのプロパティに依存し、このコンテキスト内では通知されません。「MDC」を使用する場合、操作点に必要なすべてのメディアストリームは、「MDC」文字列に続く識別タグとFMT依存性によって識別する必要があります。
Further, dependency types MUST be defined in a Standards-Track document.
さらに、依存関係のタイプは、標準トラックドキュメントで定義する必要があります。
The backward compatibility in Offer/Answer is generally handled as specified in Section 8.4 of [RFC3388], as summarized below.
以下に要約されているように、提供/回答の後方互換性は、一般に[RFC3388]のセクション8.4で指定されているように処理されます。
Depending on the implementation, a node that does not understand DDP grouping (either does not understand line grouping at all, or just does not understand the DDP semantics) SHOULD respond to an offer containing DDP grouping either (1) with an answer that ignores the grouping attribute or (2) with a refusal to the request (e.g., 488 Not acceptable here or 606 Not acceptable in SIP).
実装に応じて、DDPグループ化を理解していないノード（ライングループ化をまったく理解していないか、DDPセマンティクスを理解していない）は、DDPグループを含むオファー（1）を含むオファーに応答する必要があります。属性をグループ化または（2）リクエストを拒否して（例：ここでは受け入れられない488またはSIPでは受け入れられない606）。
In case (1), if the original sender of the offer still wishes to establish communications, it SHOULD generate a new offer with a single media stream that represents an Operation Point. Note: in most cases, this will be the base layer of a layered Media Bitstream, equally possible are Operation Points containing a set of enhancement layers as long as all are part of a single media stream. In case (2), if the sender of the original offer has identified that the refusal to the request is caused by the use of DDP grouping, and if the sender of the offer still wishes to establish the session, it SHOULD retry the request with an offer including only a single media stream.
場合（1）、オファーの元の送信者がまだ通信を確立したい場合、操作ポイントを表す単一のメディアストリームで新しいオファーを生成する必要があります。注：ほとんどの場合、これは層状のメディアビットストリームの基本層になります。すべてが単一のメディアストリームの一部である限り、強化層のセットを含む操作ポイントも同様に可能です。場合（2）、元のオファーの送信者がリクエストの拒否がDDPグループの使用によって引き起こされることを特定した場合、およびオファーの送信者がまだセッションの確立を希望する場合、リクエストを再試行する必要があります単一のメディアストリームのみを含むオファー。
If the answerer understands the DDP semantics, it is necessary to take the "depend" attribute into consideration in the Offer/Answer procedure. The main rule for the "depend" attribute is that the offerer decides the number of media streams and the dependency between them. The answerer cannot change the dependency relations.
回答者がDDPセマンティクスを理解している場合、オファー/回答手順で「依存」属性を考慮に入れる必要があります。「依存」属性の主なルールは、オファーがメディアストリームの数とそれらの間の依存関係を決定することです。応答者は依存関係を変更することはできません。
For unicast sessions where the answerer receives media, i.e., for offers including media streams that have a directionality indicated by "sendonly", "sendrecv", or have no directionality indicated, the answerer MAY remove media Operation Points. The answerer MUST use the dependency relations provided in the offer when sending media. The answerer MAY send according to all of the Operation Points present in the offer, even if the answerer has removed some of those Operation Points. Thus, an answerer can limit the number of Operation Points being delivered to the answerer while the answerer can still send media to the offerer using all of the Operation Points indicated in the offer.
回答者がメディアを受け取るユニキャストセッション、つまり、「sendonly」、「sendrecv」、または指示が示されていない方向性を持つメディアストリームを含むオファーの場合、応答者はメディアの操作ポイントを削除する場合があります。応答者は、メディアを送信するときに提供される依存関係を使用する必要があります。回答者は、応答者がこれらの操作ポイントの一部を削除したとしても、オファーに存在するすべての操作ポイントに従って送信する場合があります。したがって、応答者は、応募者に指定されているすべての操作ポイントを使用して、応募者にメディアを送信することができますが、応答者は回答者に配信される操作ポイントの数を制限できます。
For multicast sessions, the answerer MUST accept all Operation Points and their related decoding dependencies or MUST remove non-accepted Operation Points completely. Due to the nature of multicast, the receiver can select which Operation Points it actually receives and processes. For multicast sessions that allow the answerer to also send data, the answerer MAY send all of the offered Operation Points.
マルチキャストセッションの場合、回答者はすべての操作ポイントとそれらに関連するデコード依存関係を受け入れるか、受容していない操作ポイントを完全に削除する必要があります。マルチキャストの性質により、受信者は実際に受信して処理する操作ポイントを選択できます。回答者がデータを送信できるようにするマルチキャストセッションの場合、応答者は提供されるすべての操作ポイントを送信する場合があります。
In any case, if the answerer cannot accept one or more offered Operation Points and/or the media stream's dependencies, the answerer MAY re-invite with an offer including acceptable Operation Points and/or dependencies.
いずれにせよ、応答者が1つ以上の提供された操作ポイントおよび/またはメディアストリームの依存関係を受け入れることができない場合、回答者は許容可能な操作ポイントおよび/または依存関係を含むオファーを再認識できます。
Note: Applications may limit the possibility of performing a re-invite. The previous offer is also a good hint to the capabilities of the other agent.
注：アプリケーションは、再インバイトを実行する可能性を制限する場合があります。以前のオファーは、他のエージェントの機能に対する良いヒントでもあります。
If a Real Time Streaming Protocol (RTSP) receiver understands signaling according to this memo, it SHALL set up all media streams that are required to decode the Operation Point of its choice.
リアルタイムストリーミングプロトコル（RTSP）レシーバーがこのメモに従ってシグナリングを理解している場合、選択した動作点をデコードするために必要なすべてのメディアストリームをセットアップするものとします。
If an RTSP receiver does not understand the signaling defined within this memo, it falls back to normal SDP processing. Two likely cases have to be distinguished: (1) if at least one of the media types included in the SDP is within the receiver's capabilities, it selects among those candidates according to implementation specific criteria for setup, as usual. (2) If none of the media types included in the SDP can be processed, then obviously no setup can occur.
RTSPレシーバーがこのメモ内で定義されているシグナル伝達を理解していない場合、通常のSDP処理に戻ります。（1）SDPに含まれるメディアタイプの少なくとも1つが受信機の機能内にある場合、通常どおり、SDPに含まれるメディアタイプの少なくとも1つが受信機の機能内にある場合、それらの候補者の間では、通常どおりセットアップの特定の基準に従って選択します。（2）SDPに含まれるメディアタイプを処理できない場合、明らかにセットアップは発生しません。
The signaling mechanisms defined in this document MUST NOT be used to negotiate between using the attribute-value pair (AVP) [RFC3551] and SAVP [RFC3711] profile for RTP. However, both profiles MAY be used separately or jointly with the signaling mechanism defined in this document.
このドキュメントで定義されているシグナル伝達メカニズムは、RTPの属性値ペア（AVP）[RFC3551]とSAVP [RFC3711]プロファイルを使用することとの間の交渉に使用してはなりません。ただし、両方のプロファイルは、このドキュメントで定義されているシグナル伝達メカニズムと個別に、または共同で使用できます。
This memo does not cover the interaction with Capability Negotiation [MMUSIC]. This issue is for further study and will be addressed in a different memo.
このメモは、能力交渉との相互作用[MMUSIC]をカバーしていません。この問題はさらなる研究のためであり、別のメモで対処されます。
a.) Example for signaling layered decoding dependency:
a。）シグナリング層のデコード依存関係の例：
The example below shows a session description with three media descriptions, all of type video and with layered decoding dependency ("lay"). Each of the media descriptions includes two possible media format descriptions with different encoding parameters as, e.g., "packetization-mode" (not shown in the example) for the media subtypes "H264" and "H264-SVC" given by the "a=rtpmap:"-line. The first media description includes two H264 payload types as media format descriptions, "96" and "97", as defined in [RFC3984] and represents the base layer Operation Point (identified by "mid:L1"). The two other media descriptions (identified by "mid:L2" and "mid:L3") include H264-SVC payload types as defined in [AVT-RTP-SVC], which contain enhancements to the base layer Operation Point or the first enhancement layer Operation Point (media description identified by "mid:L2").
以下の例は、3つのメディアの説明、すべてのタイプビデオと層状デコード依存関係（「lay "）を含むセッションの説明を示しています。各メディアの説明には、メディアサブタイプ「H264」および「H264-SVC」の「パケット化モード」（例には示されていない）など、異なるエンコードパラメーターを持つ2つの可能なメディア形式の説明が含まれています。rtpmap： " - line。最初のメディアの説明には、[RFC3984]で定義されているように、メディア形式の説明「96」と「97」として2つのH264ペイロードタイプが含まれ、基本層の動作点（「MID：L1」で識別）を表します。他の2つのメディアの説明（「MID：L2」と「MID：L3」で識別される）には、[AVT-RTP-SVC]で定義されているH264-SVCペイロードタイプが含まれます。レイヤー操作ポイント（「MID：L2」で識別されるメディアの説明）。
The example shows the dependencies of the media format descriptions of the different media descriptions indicated by "DDP" grouping, "mid", and "depend" attributes. The "depend" attribute is used with the decoding dependency type "lay" indicating layered decoding dependency. For example, the third media description ("m=video 40004...") identified by "mid:L3" has different dependencies on the media format descriptions of the two other media descriptions: Media format description "100" depends on media format description "96" or "97" of the media description indentified by "mid:L1". This is an exclusive-OR, i.e., payload type "100" may be used with payload type "96" or with "97", but one of the two combinations is required for decoding payload type "100".
この例は、「DDP」グループ化、「MID」、および「依存」属性によって示されるさまざまなメディアの説明のメディア形式の説明の依存関係を示しています。「依存」属性は、デコード依存関係タイプ「レイ」で使用され、層状のデコード依存関係を示します。たとえば、「MID：L3」によって識別された3番目のメディアの説明（「M =ビデオ40004 ...」）は、他の2つのメディア説明のメディア形式の説明に異なる依存関係を持っています。メディア形式の説明「100」はメディア形式に依存します説明「96」または「97」メディアの説明「MID：L1」によって刻まれた説明。これは排他的です。つまり、ペイロードタイプ「100」は、ペイロードタイプ「96」または「97」で使用できますが、ペイロードタイプ「100」を解読するには2つの組み合わせの1つが必要です。
For media format description "101", it is different. This one depends on two of the other media descriptions at the same time, i.e., it depends on media format description "97" of the media description indentified by "mid:L1" and it also depends on media format description "99" of the media description indentified by "mid:L2". For decoding media format description "101", both media format description "97" and media format description "99" are required by definition.
メディア形式の説明「101」の場合、それは異なります。これは、他の2つのメディアの説明に同時に依存します。つまり、「MID：L1」によって識別されるメディアの説明のメディア形式の説明「97」に依存し、メディア形式の説明「99」にも依存します。メディアの説明「Mid：L2」によって識別されます。メディア形式の説明「101」を解読するには、メディア形式の説明 "97"とメディア形式の説明 "99"の両方が定義により必要です。
v=0
o=svcsrv 289083124 289083124 IN IP4 host.example.com
s=LAYERED VIDEO SIGNALING Seminar
t=0 0
c=IN IP4 192.0.2.1/127
a=group:DDP L1 L2 L3
m=video 40000 RTP/AVP 96 97
b=AS:90
a=framerate:15
a=rtpmap:96 H264/90000
a=rtpmap:97 H264/90000
a=mid:L1
m=video 40002 RTP/AVP 98 99
b=AS:64
a=framerate:15
a=rtpmap:98 H264-SVC/90000
a=rtpmap:99 H264-SVC/90000
a=mid:L2
a=depend:98 lay L1:96,97; 99 lay L1:97
m=video 40004 RTP/AVP 100 101
b=AS:128
a=framerate:30
a=rtpmap:100 H264-SVC/90000
a=rtpmap:101 H264-SVC/90000
a=mid:L3
a=depend:100 lay L1:96,97; 101 lay L1:97 L2:99
b.) Example for signaling of multi-descriptive decoding dependency:
b。）多記述的デコード依存関係のシグナル伝達の例：
The example shows a session description with three media descriptions, all of type video and with multi-descriptive decoding dependency. Each of the media descriptions includes one media format description. The example shows the dependencies of the media format descriptions of the different media descriptions indicated by "DDP" grouping, "mid", and "depend" attributes. The "depend" attribute is used with the decoding dependency type "mdc" indicating layered decoding dependency. For example, media format description "104" in the media description ("m=video 40000...") with "mid:M1" depends on the two other media descriptions. It depends on media format description "105" of media description with "mid:M2", and it also depends on media format description "106" of media description with "mid:M3". In case of the multi-descriptive decoding dependency, media format description "105" and "106" can be used by definition to enhance the decoding process of media format description "104", but they are not required for decoding.
この例は、3つのメディアの説明、すべてのタイプのビデオと多記述的なデコード依存関係を備えたセッションの説明を示しています。各メディアの説明には、1つのメディア形式の説明が含まれています。この例は、「DDP」グループ化、「MID」、および「依存」属性によって示されるさまざまなメディアの説明のメディア形式の説明の依存関係を示しています。「依存」属性は、デコード依存関係タイプ「MDC」で使用され、レイヤードデコード依存関係を示します。たとえば、メディア形式の説明「104」メディアの説明（「M =ビデオ40000 ...」）の「MID：M1」は、他の2つのメディアの説明に依存します。メディア形式の説明に依存します。「MID：M2」を使用したメディア説明の「105」であり、「MID：M3」を使用したメディアの説明「106」に依存します。複数の記述的なデコード依存関係の場合、メディア形式の説明「105」と「106」を使用して、メディア形式の説明「104」のデコードプロセスを強化することができますが、デコードには必要ありません。
v=0
o=mdcsrv 289083124 289083124 IN IP4 host.example.com
s=MULTI DESCRIPTION VIDEO SIGNALING Seminar
t=0 0
c=IN IP4 192.0.2.1/127
a=group:DDP M1 M2 M3
m=video 40000 RTP/AVP 104
a=mid:M1
a=depend:104 mdc M2:105 M3:106
m=video 40002 RTP/AVP 105
a=mid:M2
a=depend:105 mdc M1:104 M3:106
m=video 40004 RTP/AVP 106
a=mid:M3
a=depend:106 mdc M1:104 M2:105
All security implications of SDP apply.
SDPのすべてのセキュリティへの影響が適用されます。
There may be a risk of manipulation of the dependency signaling of a session description by an attacker. This may mislead a receiver or middle box, e.g., a receiver may try to compose a Media Bitstream out of several RTP packet streams that does not form an Operation Point, although the signaling made it believe it would form a valid Operation Point, with potential fatal consequences for the media decoding process. It is recommended that the receiver SHOULD perform an integrity check on SDP and follow the security considerations of SDP to only trust SDP from trusted sources.
攻撃者によるセッション説明の依存関係シグナルを操作するリスクがあるかもしれません。これにより、レシーバーまたは中央のボックスが誤解を招く可能性があります。たとえば、受信機は、動作点を形成しないいくつかのRTPパケットストリームからメディアビットストリームを作成しようとする場合がありますが、シグナルは潜在的な操作ポイントを形成すると信じていました。メディアデコードプロセスに対する致命的な結果。受信者は、SDPの整合性チェックを実行し、SDPのセキュリティ上の考慮事項に従い、信頼できるソースからSDPのみを信頼することをお勧めします。
The following contact information shall be used for all registrations included here:
次の連絡先情報は、ここに含まれるすべての登録に使用するものとします。
Contact: Thomas Schierl
email: ts@thomas-schierl.de
tel: +49-30-31002-227
The following semantics have been registered by IANA in Semantics for the "group" SDP Attribute under SDP Parameters.
次のセマンティクスは、SDPパラメーターの下で「グループ」SDP属性のセマンティクスでIANAによって登録されています。
Semantics Token Reference
------------------- ----- ---------
Decoding Dependency DDP RFC 5583
The SDP media-level attribute "depend" has been registered by IANA in
Semantics for "att-field (media level only)". The registration
procedure in Section 8.2.4 of [RFC4566] applies.
SDP Attribute ("att-field (media level only)"):
SDP属性（ "att-field（メディアレベルのみ）"）：
Attribute name: depend Long form: decoding dependency Type of name: att-field Type of attribute: media level only Subject to charset: no Purpose: RFC 5583 Reference: RFC 5583 Values: see this document and registrations below.
属性名：依存longフォーム：依存関係のデコード名前のタイプ：att-field属性タイプの属性：charsetのみのみ：目的なし：RFC 5583リファレンス：RFC 5583値：このドキュメントと登録を参照してください。
The following semantics have been registered by IANA in Semantics for the "depend" SDP Attribute under SDP Parameters:
次のセマンティクスは、SDPパラメーターの下で「依存」SDP属性のセマンティクスでIANAによって登録されています。
Semantics of the "depend" SDP attribute:
「依存」SDP属性のセマンティクス：
Semantics Token Reference
---------------------------- ----- ---------
Layered decoding dependency lay RFC 5583
Multi-descriptive decoding dependency mdc RFC 5583
New registrations for semantics of the "depend" SDP attribute are added by the "Specification Required" policy as defined in [RFC5226].
[RFC5226]で定義されている「依存」SDP属性のセマンティクスの新しい登録は、「必要な仕様」ポリシーによって追加されます。
Currently, there is ongoing work on [RFC3388bis]. In [RFC3388bis], the grouping mechanism is extended in a way that a media description can be part of more than one group of the same grouping type in the same session description. However, media descriptions grouped by this document must be at most part of one group of the type "DDP" in the same session description.
現在、[RFC3388bis]に関する継続的な作業があります。[RFC3388BIS]では、グループ化メカニズムは、メディアの説明が同じセッションの説明で同じグループタイプの複数のグループの一部になるように拡張されています。ただし、このドキュメントによってグループ化されたメディアの説明は、同じセッションの説明にあるタイプ「DDP」の1つのグループのほとんどの部分でなければなりません。
[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月。
[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月。
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[RFC3551] Schulzrinne、H。およびS. Casner、「最小限のコントロールを備えたオーディオおよびビデオ会議のRTPプロファイル」、STD 65、RFC 3551、2003年7月。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711] Baugher、M.、McGrew、D.、Naslund、M.、Carrara、E。、およびK. Norrman、「安全なリアルタイム輸送プロトコル（SRTP）」、RFC 3711、2004年3月。
[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., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] Crocker、D.、ed。、およびP. Overell、「構文仕様のためのBNFの増強」、STD 68、RFC 5234、2008年1月。
[AVT-RTP-SVC] Wenger, S., Wang Y.-K., Schierl, T. and A. Eleftheriadis, "RTP Payload Format for SVC Video", Work in Progress, March 2009.
[AVT-RTP-SVC] Wenger、S.、Wang Y.-K.、Schierl、T。およびA. Eleftheriadis、「SVCビデオのRTPペイロード形式」、2009年3月の作業。
[RFC3388bis] Camarillo, G "The SDP (Session Description Protocol) Grouping Framework", Work in Progress, January 2009.
[RFC3388BIS] Camarillo、G「SDP（セッション説明プロトコル）グループ化フレームワーク」、2009年1月の作業。
[MMUSIC] Andreasen, F., "SDP Capability Negotiation", Work in Progress, May 2009.
[MMUSIC] Andreasen、F。、「SDP能力交渉」、2009年5月の作業。
[AVT-RTP-MVC] Wang, Y.-K. and T. Schierl, "RTP Payload Format for MVC Video", Work in Progress, February 2009.
[AVT-RTP-MVC] Wang、Y.-K。T. Schierl、「MVCビデオ用のRTPペイロード形式」、2009年2月、進行中の作業。
[MDC] Vitali, A., Borneo, A., Fumagalli, M., and R. Rinaldo, "Video over IP using Standard-Compatible Multiple Description Coding: an IETF proposal", Packet Video Workshop, April 2006, Hangzhou, China.
[MDC] Vitali、A.、Borneo、A.、Fumagalli、M。、およびR. Rinaldo、「標準互換性のある複数の説明コーディングを使用したIP上のビデオ：IETF提案」、パケットビデオワークショップ、2006年4月、杭州、中国。
[RFC3984] Wenger, S., Hannuksela, M., Stockhammer, T., Westerlund, M., and D. Singer, "RTP Payload Format for H.264 Video", RFC 3984, February 2005.
[RFC3984] Wenger、S.、Hannuksela、M.、Stockhammer、T.、Westerlund、M。、およびD. Singer、「H.264ビデオのRTPペイロード形式」、RFC 3984、2005年2月。
The author Thomas Schierl of Fraunhofer HHI is sponsored by the European Commission under the contract number FP7-ICT-214063, project SEA.
Fraunhofer HHIの著者Thomas Schierlは、Project Seaの契約番号FP7-ICT-214063の下で欧州委員会によって後援されています。
We want to also thank Magnus Westerlund, Joerg Ott, Ali Begen, Dan Wing, Helmut Burklin, and Jean-Francois Mule for their valuable and constructive comments to this memo.
また、このメモへの貴重で建設的なコメントをしてくれたマグナス・ウェスターランド、ジョーグ・オット、アリ・ベジェン、ダン・ウィング、ヘルムート・バークリン、ジャン・フランソワ・ミュールにも感謝します。
Authors' Addresses
著者のアドレス
Thomas Schierl Fraunhofer HHI Einsteinufer 37 D-10587 Berlin Germany
Thomas Schierl Fraunhofer HHI Einsteinufer 37 D-10587ベルリンドイツ
Phone: +49-30-31002-227
EMail: ts@thomas-schierl.de
Stephan Wenger 2400 Skyfarm Dr. Hillsborough, CA 94010 USA
Stephan Wenger 2400 Skyfarm Dr. Hillsborough、CA 94010 USA
Phone: +1-415-713-5473
EMail: stewe@stewe.org