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)
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と組み合わせて使用するように、定義されています。また、属性は、メディア識別属性（S）およびメディアフォーマット記述（S）で示される「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.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版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つ以上のメディア記述を含んでいてもよいです。メディア記述は、一つの「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つ以上のメディアのパーティションを含んでいます。我々が興味を持っている場合は、二つ以上のメディアのパーティションとのレイヤードやMDCビットストリームです。独自のセッションで複数のメディアパーティションを担持する層またはMDC符号化されたメディアを使用するためのキーの使用事例の一つです。送信者、ネットワーク要素、または受信機は、送信/転送/個々のメディアパーティションを復号化/サブスクライブ抑制し、依然として、おそらく準最適、それでも有用なメディア品質を維持することができます。
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符号化では、メディアのパーティションは相補的である - 多くのメディアパーティション1が受け、より良い再生品質であってもよいです。この文書では、そのような復号化依存性を示すために、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勧告に対するスケーラブルビデオコーディング（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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "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.
デコード依存：関係メディアパーティションのクラスがお互いに持っています。レイヤード符号化および多重記述符号化：現時点で、このメモは、二つの復号化依存性を定義します。
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.
層状マルチ説明：このメモは、復号化依存性の二種類にも関します。キー動機として帯域幅、エラー率、マルチキャストまたはブロードキャストシナリオにおいて、エンドポイントの接続性、等に関連するネットワーク状態にメディア適応、すなわち、のための欲求を共有コーディング積層して多重記述の輸送。
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]の意味で異なるメディアストリームで搬送されてもよいです。古典的なユースケースは、受信品質またはビットレート要求に応答してメディアストリームの組み合わせを選択する受信機駆動型階層化マルチキャストとして知られています。
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年代半ばで、その後、利用可能な層状のメディアフォーマットとコーデックは、主に（あるいは排他的に）層の一次元の階層を想定しました。すなわち、「下」、正確に一つの層と称する各いわゆるエンハンスメント層です。唯一の例外は、自己完結型であり、ベース層、でした。したがって、一つの向上層の識別が完全にデコードされる必要がある他のすべての層についての知識を含む積層符号化方式の動作ポイントを指定します。
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]は、まさにこのユースケースとメディアフォーマットの基本的なサポートを含んでいます。定義により、より高いトランスポートアドレスは、一次元階層内の上位層を特定します。受信機は、このオペレーションポイントをデコードするために、このトランスポートアドレスと下位トランスポート・アドレスを介して搬送データを復号化する必要があります。
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).
新しいメディアフォーマットは、非常に複雑な（少なくとも樹状）依存階層を実現することが可能で、この単純な一次元の階層から逸脱します。これらの複雑な階層のための魅力的なユースケースは、業界で同定されています。それのためのサポートが望まれています。しかし、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-アウトM合計メディアパーティションが意味のある復号化を可能にするために利用可能である必要がある場合、すなわち、想定することができます。
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.
我々は、A）MDCのメディア形式がこのメモの寿命内で実用化されてなることを想定し、そしてb）そのシグナルのための溶液が階層符号化の一つに非常に類似しているので、このメモでは、MDCを覆います。
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 =」と記述されるメディア記述との間のみ可能です。この仕様に応じてグループ化されたすべてのメディア記述は、同じメディアタイプを持たなければなりません。 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で定義された属性でシグナリングされるように）復号化依存性の同一の型でなければなりません。すべてのメディアストリームは、少なくとも一つの動作ポイントを含まなければなりません。 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]で定義されています。 [RFC4566]で定義されるように、以下のABNFにおいて、FMT、トークン、SP、およびCRLFが使用されます。
<CODE BEGINS> Copyright (c) 2009 IETF Trust and the persons identified as authors of the code. All rights reserved.
<CODEが始まる>著作権（C）2009 IETF信託コードの作者として特定の人物。全著作権所有。
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.
このソフトウェアは、著作権保持者と貢献者に制限された状態で提供し、特定目的に対する適合性の黙示の保証も行われません。 NO EVENTの著作権所有者または貢献者は、以下を含むいかなる直接的、間接的、偶発的、特別、懲罰的、または間接的損害（についても責任を負いあってもよいが、代替商品またはサービスの調達、これらに限定されないものとし、使用、データ、または利益の損失; OR事業の中断）原因で生じた（そのような損害の可能性について知らされていた場合でも、一切このソフトウェアの使用の損失、データの損失）過失またはその他を含む責任、それが契約、厳格な責任、不法行為のどのような理論の上で。
depend-attribute = "a=depend:" dependent-fmt SP dependency-tag *(";" SP dependent-fmt SP dependency-tag) CRLF
依存属性= "=は異なり、" 依存-FMT SP依存タグ*（ ";" SP依存-FMTのSP依存タグ）CRLF
dependency-tag = dependency-type *1( SP identification-tag ":" fmt-dependency *("," fmt-dependency ))
依存タグ=依存型* 1（SP識別タグ "：" FMT-依存*（ "" FMT依存））
dependency-type = "lay" / "mdc" / token
依存型=「産む」/「MDC」/トークン
dependent-fmt = fmt
依存-FMT = FMT
fmt-dependency = fmt <CODE ENDS>
FMT-依存= FMT <CODEが終了>
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の一つ以上の依存関係を示しています。これらの依存関係は、他のメディア記述の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は依存タグ内の識別タグの値によって示されるメディア記述内の1つまたは複数のメディアフォーマットの記述に依存する[RFC4566]で定義されるように、メディアフォーマットの説明を示しています。
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つまたは複数のメディアパーティションとして説明したメディアストリームを識別する。使用される「レイ」場合、動作ポイントを復号するために必要なすべてのメディアストリームは、識別タグおよび「レイ」の文字列以下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 - アウト・オブ・Mメディアストリームは、操作ポイントから利用可能にする必要があります。 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の意味を理解していないのいずれか）（1）無視答えのいずれかでグループ分けDDPを含むプランに応じます要求に拒否を持つ属性または（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）メディアタイプのうちの少なくとも1つが、SDPに含まれている場合、それはいつものように、セットアップのための実装固有の基準に従って、これらの候補の中から選択し、受信者の能力の範囲内です。 （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.
この文書で定義されたシグナル伝達機構は、属性値ペア（AVP）[RFC3551]を使用してRTPのための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:
。レイヤード復号化依存性をシグナリングするための）例：
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つのメディア記述とのセッション記述を示し型映像の全て層状復号化依存性（「レイ」）。メディア記述の各々は、「によって与えられた異なるメディアサブタイプ「H264」は、例えば、「パケットモード」（例には示されていない）のような符号化パラメータと「H264-SVC」との二つの可能なメディア形式の説明を含み= rtpmap： " - 行。最初のメディア記述は、[RFC3984]で定義されており、（「：L1半ば」によって識別される）は、ベース層の動作点を表すように、メディア形式の説明、「96」と「97」のような2つのH264ペイロードタイプを含みます。 （「L2中間」によって識別される「中：L3」）は、2つの他のメディア記述は、ベースレイヤの動作ポイント又は第向上に拡張機能を含む[AVT-RTP-SVC]で定義されるようにH264-SVCペイロードタイプを含みます操作ポイント（「：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」グループ、「中」で示される異なるメディア記述のメディア形式の説明の依存性を示し、そして。 「依存」属性が復号依存型で使用された層状復号化依存性を示す「レイ」。例えば、第3のメディア記述（「M =ビデオ40004は...」）によって識別される「中：L3」は、2つの他のメディア記述のメディアフォーマットの説明に異なる依存性を有している：メディアフォーマットの説明「100」メディアフォーマットに依存します説明「半ば：L1」でINDENTIFIEDメディア記述の「96」または「97」。これは、排他的論理和、すなわち、ペイロードタイプ「100」ペイロードタイプ「96」または「97」で使用されてもよいが、2組の一方はペイロードタイプ「100」を復号するために必要とされます。
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」の場合、それは異なっています。この1つは、同時に他のメディア記述の2に依存し、すなわち、それは「半ば：L1」でINDENTIFIEDメディア記述のメディア形式の説明「97」に依存し、それはまたのメディア形式の説明「99」に依存します「：L2半ば」でINDENTIFIEDメディア記述。メディアフォーマットの説明「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
DDP L1 L2 L3のM =ビデオ40000 RTP / AVP 96：IP4 192.0.2.1/127 =グループ内のV = 0 0 = svcsrv 289083124 289083124 IN IP4 host.example.com S = LAYERED VIDEOシグナリングセミナーT = 0℃の= 97 B = AS：90 =フレームレート：15 = rtpmap：96 H264 / 90000 = rtpmap：97 H264 / 90000 =ミッド：L1のM =ビデオ40002 RTP / AVP 98 99 B = AS：64 =フレームレート： 15 = rtpmap：98 H264-SVC / 90000 = rtpmap：99 H264-SVC / 90000 =ミッド：L2のA =は依存：98 L1置く：96,97と、 97メートル=ビデオ40004 RTP / AVP 100 101 B = AS：128 =フレームレート：30 = rtpmap：100 H264-SVC / 90000 = rtpmap：101 H264-SVC / 90000 =ミッド：L3 A 99は、L1を築きます=依存：100は、L1置く：96,97と、 97 L2：99 101は、L1を築きます
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」グループ、「中」で示される異なるメディア記述のメディア形式の説明の依存性を示し、そして。 「依存」属性が層状復号化依存性を示す復号化依存型「MDC」と共に使用されます。例えば、「半ば：M1」のメディア記述（「M =ビデオ40000 ...」）におけるメディアフォーマット記述「104」は、2つの他のメディア記述に依存します。これは、「半ば：M2」とメディア記述のメディアフォーマットの説明「105」に依存し、それはまた、「半ば：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
IP4 192.0.2.1/127 IN V = 0 0 = mdcsrv 289083124 289083124 IN IP4 host.example.com S = MULTI DESCRIPTION VIDEOシグナリングセミナーT = 0のC = =グループ：DDP M1 M2 M3のM =ビデオ40000 RTP / AVP 104 =ミッド：M1のA =依存：104 MDC M2：105 M3：106メートル=ビデオ40002は、RTP / AVP 105 =ミッド：M2のA =依存：105 MDC M1：104 M3：106メートル=ビデオ40004 RTP / AVP 106 =ミッド：M3のA =依存：106 MDC M1：M2 104：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
連絡先：トーマスSchierlメール：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メディアレベル属性「依存」は「ATT-フィールド（メディアレベルのみ）」のために意味でIANAによって登録されています。 [RFC4566]のセクション8.2.4での登録手続きが適用されます。
SDP Attribute ("att-field (media level only)"):
SDP属性（ "ATT-フィールド（メディアレベルのみ）"）：
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.
属性名：属性のATTフィールド型：名前の依存関係の種類をデコード：メディアは文字セットにのみ件名レベルません：目的なし：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属性の意味について新規登録は「仕様が必要である」というポリシーによって追加されます。
9. Informative Note on "The SDP (Session Description Protocol) Grouping Framework"
9.有益な注意「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」の一つのグループのほとんどの部分でなければなりません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H. Schulzrinne, "Grouping of Media Lines in the Session Description Protocol (SDP)", RFC 3388, December 2002.
[RFC3388]キャマリロ、G.、エリクソン、G.、大声、J.、およびH. Schulzrinneと、 "セッション記述プロトコルにおけるメディア行のグループ化（SDP）"、RFC 3388、2002年12月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinneと、H.、Casner、S.、フレデリック、R.、およびV.ヤコブソン、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、STD 64、RFC 3550、2003年7月。
[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.、マグリュー、D.、Naslund、M.、カララ、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]ハンドリー、M.、ヤコブソン、V.、およびC.パーキンス、 "SDP：セッション記述プロトコル"、RFC 4566、2006年7月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 5226、2008年5月。
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
"構文仕様のための増大しているBNF：ABNF" [RFC5234]クロッカー、D.、エド、およびP. Overell、。、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]ウェンガー、S.、王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]カマリロ、G "SDP（セッション記述プロトコル）グループ化フレームワーク"、進歩、2009年1月の作業。
[MMUSIC] Andreasen, F., "SDP Capability Negotiation", Work in Progress, May 2009.
[MMUSIC]アンドレア、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]王、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]ビタリ、A.、ボルネオ、A.、フマガリ、M.、およびR.リナルド、「標準互換多重記述符号化を用いた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]ウェンガー、S.、Hannuksela、M.、Stockhammer、T.、ウェスター、M.、およびD.歌手、 "H.264ビデオのためのRTPペイロードフォーマット"、RFC 3984、2005年2月。
Appendix A. Acknowledgements
付録A.謝辞
The author Thomas Schierl of Fraunhofer HHI is sponsored by the European Commission under the contract number FP7-ICT-214063, project SEA.
著者フラウンホーファーHHIのトーマスSchierlは、契約番号FP7-ICT-214063、プロジェクトSEAの下で、欧州委員会が主催しています。
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.
また、このメモに貴重なと建設的なコメントのためにマグヌスウェスター、イェルク・オット、アリBegen、ダン・ウィング、ヘルムートBurklin、とジャン・フランソワ・ミュールに感謝したいと思います。
Authors' Addresses
著者のアドレス
Thomas Schierl Fraunhofer HHI Einsteinufer 37 D-10587 Berlin Germany
トーマスSchierlフラウンホーファーHHI Einsteinufer 37 D-10587ベルリンドイツ
Phone: +49-30-31002-227 EMail: ts@thomas-schierl.de
電話：+ 49-30-31002-227 Eメール：ts@thomas-schierl.de
Stephan Wenger 2400 Skyfarm Dr. Hillsborough, CA 94010 USA
ステファン・ベンゲル2400 Skyfarm博士ヒルズボロ、CA 94010 USA
Phone: +1-415-713-5473 EMail: stewe@stewe.org
電話：+ 1-415-713-5473 Eメール：stewe@stewe.org