Network Working Group J. Lennox
Request for Comments: 5576 Vidyo
Category: Standards Track J. Ott
Helsinki University of Technology
T. Schierl
Fraunhofer HHI
June 2009
Source-Specific Media Attributes in the
Session Description Protocol (SDP)
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として、英語以外の言語に翻訳します。
Abstract
抽象
The Session Description Protocol (SDP) provides mechanisms to describe attributes of multimedia sessions and of individual media streams (e.g., Real-time Transport Protocol (RTP) sessions) within a multimedia session, but does not provide any mechanism to describe individual media sources within a media stream. This document defines a mechanism to describe RTP media sources, which are identified by their synchronization source (SSRC) identifiers, in SDP, to associate attributes with these sources, and to express relationships among sources. It also defines several source-level attributes that can be used to describe properties of media sources.
セッション記述プロトコル（SDP）マルチメディアセッション内でマルチメディアセッションの、個々のメディアストリームの属性（例えば、リアルタイムトランスポートプロトコル（RTP）セッション）を記述するためのメカニズムを提供していますが、内の個々のメディアソースを記述するための任意のメカニズムを提供しません。メディアストリーム。この文書では、これらのソースと属性を関連付けるために、及びソース間の関係を表現するために、SDPに、それらの同期ソース（SSRC）識別子によって識別されたRTPメディアソースを記述するためのメカニズムを定義します。それはまた、メディアソースの特性を記述するために使用できるいくつかのソースレベル属性を定義します。
Table of Contents
目次
1. Introduction ....................................................2
2. Terminology .....................................................3
3. Overview ........................................................3
4. Media Attributes ................................................4
4.1. The "ssrc" Media Attribute .................................5
4.2. The "ssrc-group" Media Attribute ...........................6
5. Usage of Identified Source Identifiers in RTP ...................7
6. Source Attributes ...............................................8
6.1. The "cname" Source Attribute ...............................8
6.2. The "previous-ssrc" Source Attribute .......................9
6.3. The "fmtp" Source Attribute ................................9
6.4. Other Source Attributes ...................................10
7. Examples .......................................................10
8. Usage With the Offer/Answer Model ..............................11
9. Backward Compatibility .........................................11
10. Formal Grammar ................................................12
11. Security Considerations .......................................13
12. IANA Considerations ...........................................14
12.1. New SDP Media-Level Attributes ...........................14
12.2. Registry for Source-Level Attributes .....................14
12.3. Registry for Source Grouping Semantics ...................15
13. References ....................................................16
13.1. Normative References .....................................16
13.2. Informative References ...................................16
The Session Description Protocol (SDP) [RFC4566] provides mechanisms to describe attributes of multimedia sessions and of media streams (e.g., Real-time Transport Protocol (RTP) [RFC3550] sessions) within a multimedia session, but does not provide any mechanism to describe individual media sources within a media stream.
マルチメディアセッション内のセッション記述プロトコル（SDP）[RFC4566]をマルチメディアセッションのメディアストリームの属性を記述するためのメカニズムを提供します（例えば、リアルタイムトランスポートプロトコル（RTP）[RFC3550]セッション）、これに任意のメカニズムを提供しません。メディアストリーム内の個々のメディアソースを記述します。
Several recently proposed protocols, notably RTP single-source multicast [EXT-SSM], have found it useful to describe specific media sources in SDP messages. Single-source multicast, in particular, needs to ensure that receivers' RTP synchronization source (SSRC) identifiers do not collide with those of media senders, as the RTP specification [RFC3550] requires that colliding sources change their SSRC values after a collision has been detected. Earlier work has used mechanisms specific to each protocol to describe the individual sources of an RTP session.
いくつかの最近提案されたプロトコル、特にRTPシングルソースマルチキャスト[EXT-SSM]は、SDPメッセージ内の特定のメディアソースを記述することが有用であることが分かりました。マルチキャストは、具体的には、RTP仕様[RFC3550]は衝突源は衝突後にSSRC値を変更することを必要とするように、受信者のRTP同期ソース（SSRC）識別子は、メディア送付者のものと衝突しないことを保証する必要がある単一源となっています検出されました。以前の研究は、RTPセッションの個々のソースを記述するために各プロトコルに固有のメカニズムを使用してきました。
Moreover, whereas the Real-time Transport Protocol (RTP) [RFC3550] is defined as allowing multiple sources in an RTP session (for example, if a user has more than one camera), SDP has no existing mechanism for an endpoint to indicate that it will be using multiple sources or to describe their characteristics individually.
（ユーザが、複数のカメラを有する場合、例えば）リアルタイムトランスポートプロトコル（RTP）[RFC3550]はRTPセッションで複数のソースを可能にするように定義されるのに対し、また、SDPはそれを示すために、エンドポイントのための既存の機構を有していませんそれは、複数のソースを使用するか、個別にそれらの特性を記述すること。
To address all these problems, this document defines a mechanism to describe RTP sources, identified by their synchronization source (SSRC) identifier, in SDP, to associate attributes with these sources, and to express relationships among individual sources. It also defines a number of new SDP attributes that apply to individual sources ("source-level" attributes), describes how a number of existing media stream ("media-level") attributes can also be applied at the source level, and establishes IANA registries for source-level attributes and source grouping semantics.
すべてのこれらの問題に対処するため、この文書では、これらのソースと属性を関連付けるために、及び個々の光源間の関係を表現するために、SDPに、それらの同期ソース（SSRC）識別子によって識別されるRTPソースを記述するためのメカニズムを定義します。それはまた、個々のソース（「ソースレベル」属性）に適用される新しいSDP属性の数を定義する既存のメディアストリーム（「メディアレベル」）の数は、ソースレベルでも適用することができる属性について説明し、確立IANAは、ソースレベルの属性とソースグループ化セマンティクスのためにレジストリ。
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 RFC 2119 [RFC2119] and indicate requirement levels for compliant implementations.
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119 [RFC2119]に記載され、対応する実装の要求レベルを示すものと解釈されます。
In the Real-time Transport Protocol (RTP) [RFC3550], an association among a group of communicating participants is known as an RTP Session. An RTP session is typically associated with a single transport address (in the case of multicast) or communication flow (in the case of unicast), though RTP translators and single-source multicast [EXT-SSM] can make the situation more complex. RTP topologies are discussed in more detail in [RFC5117].
リアルタイムトランスポートプロトコル（RTP）[RFC3550]において、通信参加者のグループ間の関連は、RTPセッションとして知られています。 RTPトランスレータとシングルソースマルチキャスト[EXT-SSM]は状況はより複雑にすることができてもRTPセッションは、典型的には、（ユニキャストの場合）単一（マルチキャストの場合）トランスポートアドレスまたは通信フローに関連付けられています。 RTPトポロジは、[RFC5117]に詳細に記載されています。
Within an RTP session, the source of a single stream of RTP packets is known as a synchronization source (SSRC). Every synchronization source is identified by a 32-bit numeric identifier. In addition, receivers (who may never send RTP packets) also have source identifiers, which are used to identify their RTP Control Protocol (RTCP) receiver reports and other feedback messages.
RTPセッション内で、RTPパケットの単一ストリームのソースは、同期ソース（SSRC）として知られています。すべての同期ソースは、32ビットの数値識別子によって識別されます。また、（RTPパケットを送信しない場合があります）受信機はまた、RTP制御プロトコル（RTCP）受信機レポートやその他のフィードバックメッセージを識別するために使用されたソース識別子を、持っています。
Messages of the Session Description Protocol (SDP) [RFC4566], known as session descriptions, describe multimedia sessions. A multimedia session is a set of multimedia senders and receivers as well as the data streams flowing from senders to receivers. A multimedia session contains a number of media streams, which are the individual RTP sessions or other media paths over which one type of multimedia data is carried. Information that applies to an entire multimedia session is called session-level information, while information pertaining to one media stream is called media-level information. The collection of all the information describing a media stream is known as a media description. (Media descriptions are also sometimes known informally as SDP "m"-lines, after the SDP syntax that begins a media description.) Several standard information elements are defined at both the session level and the media level. Extended information can be included at both levels through the use of attributes.
セッション記述プロトコル（SDP）のメッセージセッション記述として知られている[RFC4566]は、マルチメディアセッションを記述する。マルチメディアセッションは、マルチメディア送信者と受信者のセットであるだけでなく、データストリームが受信機に送信者から流れます。マルチメディアセッションは、個々のRTPセッション又はマルチメディアデータの一種が担持され介して他のメディア経路であるメディアストリームの数を含んでいます。情報は、メディア・レベルの情報と呼ばれる1つのメディアストリームに関連しながら、全体のマルチメディアセッションに適用される情報は、セッションレベルの情報と呼ばれています。メディアストリームを記述するすべての情報の収集は、メディア記述として知られています。 （メディア記述はまた、時々メディア記述を開始SDP構文後、SDP「M」-linesとして非公式に知られている。）いくつかの標準の情報要素は、セッションレベル及びメディアレベルの両方で定義されています。拡張情報は、属性の使用を介して両方のレベルで含まれることができます。
(The term "media stream" does not appear in the SDP specification itself, but is used by a number of SDP extensions, for instance, Interactive Connectivity Establishment (ICE) [ICE], to denote the object described by an SDP media description. This term is unfortunately rather confusing, as the RTP specification [RFC3550] uses the term "media stream" to refer to an individual media source or RTP packet stream, identified by an SSRC, whereas an SDP media stream describes an entire RTP session, which can contain any number of RTP sources. In this document, the term "media stream" means an SDP media stream, i.e., the thing described by an SDP media description, whereas "media source" is used for a single source of media packets, i.e., an RTP media stream.)
（用語「メディアストリーム」は、SDPの仕様自体には表示されませんが、SDPメディア記述によって記述されたオブジェクトを表すために、インタラクティブ接続確立（ICE）[ICE]、例えば、SDPエクステンションの数によって使用されます。この用語は、RTP仕様として[RFC3550]はSDPメディアストリーム全体RTPセッションを記述する一方、SSRCによって識別個々のメディアソース又はRTPパケットストリームを参照するために、用語「メディア・ストリーム」を使用して、残念ながらかなり混乱していますRTPソースの任意の数を含むことができる。この文書では、用語「メディア・ストリーム」は、SDPメディアストリームを意味し、すなわち、SDPのメディア記述により記載のもの、「メディアソース」は、メディアパケットの単一のソースに使用されるのに対し、すなわち、RTPメディアストリーム。）
The core SDP specification does not have any way of describing individual media sources, particularly RTP synchronization sources, within a media stream. To address this problem, in this document we introduce a third level of information, called source-level information. Syntactically, source-level information is described by a new SDP media-level attribute, "ssrc", which identifies specific synchronization sources within an RTP session and acts as a meta-attribute mapping source-level attribute information to these sources.
中核SDP仕様は、メディア・ストリーム内の、個々のメディアソース、特にRTPの同期ソースを記述する任意の方法を持っていません。この問題に対処するために、本書では、我々はソースレベルの情報と呼ばれる情報の第3レベルを、ご紹介します。構文的に、ソースレベルの情報は、これらのソースに属性情報をメタ属性マッピングソースレベルとしてRTPセッション及び作用内の特定の同期ソースを識別し、新しいSDPメディアレベル属性、「SSRC」によって記述されます。
This document also defines an SDP media-level attribute, "ssrc-group", which can represent relationships among media sources within an RTP session in much the same way as the "group" attribute [RFC3388] represents relationships among media streams within a multimedia session.
「グループ」属性[RFC3388]はマルチメディア内のメディアストリーム間の関係を表しているとほとんど同じ方法でRTPセッション内のメディア・ソース間の関係を表すことができ、この文書はまた、SDPメディアレベル属性を定義し、「SSRC基」、セッション。
This section defines two media-level attributes, "ssrc" and "ssrc-group".
このセクションでは、2つのメディアレベル属性、「SSRC」および「SSRCグループ」を定義します。
a=ssrc:<ssrc-id> <attribute> a=ssrc:<ssrc-id> <attribute>:<value>
= SSRC <SSRC-ID>、<属性> A = SSRC <SSRC-ID>、<属性>：<値>
The SDP media attribute "ssrc" indicates a property (known as a "source-level attribute") of a media source (RTP stream) within an RTP session. <ssrc-id> is the synchronization source (SSRC) ID of the source being described, interpreted as a 32-bit unsigned integer in network byte order and represented in decimal. <attribute> or <attribute>:<value> represents the source-level attribute specific to the given media source. The source-level attribute follows the syntax of the SDP "a=" line. It thus consists of either a single attribute name (a flag) or an attribute name and value, e.g., "cname:user@example.com". No attributes of the former type are defined by this document.
SDPメディア属性「SSRC」はRTPセッション内のメディアソース（RTPストリーム）の（「ソースレベル属性」としても知られる）の特性を示しています。 <SSRC-ID>ソースの同期ソース（SSRC）IDは、ネットワークバイト順で32ビットの符号なし整数として解釈され、小数で表される、記載されています。 <属性>または<属性>：<値>は、ソースレベルは、所与のメディア・ソースに固有の属性を表しています。ソースレベル属性は、SDPの「a =」行の構文に従います。したがって、単一の属性名（フラグ）または属性の名前と値、例えば、「：user@example.com CNAME」のいずれかから成ります。前者のタイプのいかなる属性は、この文書で定義されていません。
Within a media stream, "ssrc" attributes with the same value of <ssrc-id> describe different attributes of the same media sources. Across media streams, <ssrc-id> values are not correlated (unless correlation is indicated by media-stream grouping or some other mechanism) and MAY be repeated.
メディア・ストリーム内に、「SSRCは」<SSRC-ID>の同じ値を持つ属性同じメディアソースの異なる属性を記述する。 （相関がメディアストリームのグループ化またはいくつかの他のメカニズムによって示されない限り）と繰り返すことができるメディアストリームを横切って、<SSRC-id>の値は相関していません。
Each "ssrc" media attribute specifies a single source-level attribute for the given <ssrc-id>. For each source mentioned in SDP, the source-level attribute "cname", defined in Section 6.1, MUST be provided. Any number of other source-level attributes for the source MAY also be provided.
各「SSRC」メディア属性が与えられた<SSRC-id>のための単一のソースレベルの属性を指定します。 SDPに記載された各ソースについては、セクション6.1で定義されたソースレベル属性「CNAME」は、提供されなければなりません。ソースのための他のソースレベル属性の任意の数を設けることもできます。
The "ssrc" media attribute MAY be used for any RTP-based media transport. It is not defined for other transports.
「SSRC」media属性は、任意のRTPベースのメディア転送のために使用されるかもしれません。これは、他のトランスポートのために定義されていません。
If any other SDP attributes also mention RTP SSRC values (for example, Multimedia Internet KEYing (MIKEY) [RFC3830] [RFC4567]), the values used MUST be consistent. (These attributes MAY provide additional information about a source described by an "ssrc" attribute or MAY describe additional sources.)
他のSDPはまた、RTP SSRC値（例えば、マルチメディアインターネットキーイング（MIKEY）[RFC3830]、[RFC4567]）を言及属性場合、使用される値が一致していなければなりません。 （これらの属性は「SSRC」属性で記述されたソースに関する追加情報を提供することができる、または追加のソースを記述してもよいです。）
Though the source-level attributes specified by the ssrc property follow the same syntax as session-level and media-level attributes, they are defined independently. All source-level attributes MUST be registered with IANA, using the registry defined in Section 12.2.
SSRCプロパティで指定されたソース・レベルの属性はセッションレベルとメディアレベル属性と同じ構文に従いますが、彼らは独立して定義されています。すべてのソース・レベルの属性は、セクション12.2で定義されたレジストリを使用して、IANAに登録しなければなりません。
Figure 4 in Section 10 gives a formal Augmented Backus-Naur Form (ABNF) [RFC5234] grammar for the "ssrc" attribute.
セクション10における図4は、「SSRC」属性の正式た拡張バッカス - ナウアフォーム（ABNF）[RFC5234]文法を与えます。
The "ssrc" media attribute is not dependent on charset.
「SSRC」media属性は、文字セットに依存していません。
a=ssrc-group:<semantics> <ssrc-id> ...
= SSRC-グループ：<セマンティクス> <SSRC-ID> ...
The SDP media attribute "ssrc-group" expresses a relationship among several sources of an RTP session. It is analogous to the "group" session-level attribute [RFC3388], which expresses a relationship among media streams in an SDP multimedia session (i.e., a relationship among several logically related RTP sessions). As sources are already identified by their SSRC IDs, no analogous property to the "mid" attribute is necessary; groups of sources are identified by their SSRC IDs directly.
SDPメディア属性「SSRC-グループは、」RTPセッションのいくつかのソース間の関係を表現しています。それは、SDPマルチメディアセッション内のメディアストリーム間の関係を表現「グループ」セッションレベル属性[RFC3388]に類似している（すなわち、いくつかの論理的に関連するRTPセッションの関係）。ソースは、すでに彼らのSSRC IDによって識別されると、「半ば」への類似したプロパティは、属性は必要ありません。ソースのグループは、直接自分のSSRC IDによって識別されます。
The <semantics> parameter is taken from the specification of the "group" attribute [RFC3388]. The initial semantic values defined for the "ssrc-group" attribute are FID (Flow Identification) [RFC3388] and FEC (Forward Error Correction) [RFC4756]. In each case, the relationship among the grouped sources is the same as the relationship among corresponding sources in media streams grouped using the SDP "group" attribute.
<セマンティクス>パラメータは、「グループ」属性[RFC3388]の仕様から取られています。 「SSRCグループ」属性に定義された初期意味値は、FID（フロー識別）[RFC3388]及びFEC（前方誤り訂正）[RFC4756]です。各場合において、グループ化されたソースの関係は、SDP「グループ」属性を使用してグループ化されたメディアストリームに対応するソース間の関係と同じです。
Though the "ssrc-group" semantic values follow the same syntax as "group" semantic values, they are defined independently. All "ssrc-group" semantic values MUST be registered with IANA, using the registry defined in Section 12.3.
「SSRCグループ」セマンティック値は「グループ」意味値と同じ構文に従いますが、彼らは独立して定義されています。すべての「SSRC-グループ」意味値は、12.3節で定義されたレジストリを使用して、IANAに登録しなければなりません。
(The other "group" semantics registered with IANA as of this writing are not useful for source grouping. LS (Lip Synchronization) [RFC3388] is redundant for sources within a media stream as RTP sources with the same CNAME are implicitly synchronized in RTP. SRF (Single Reservation Flow) [RFC3524] and ANAT (Alternative Network Address Types) [RFC4091] refer specifically to the media stream's transport characteristics. CS (Composite Session) [FLUTE] is used to group FLUTE sessions, and so is not applicable to RTP.)
（これを書いているようにIANAに登録された他の「グループ」のセマンティクスは、ソースのグループ化のために有用ではないLS（リップ同期）[RFC3388]と同じCNAMEのRTPソースが暗黙RTPに同期されるように、メディア・ストリーム内のソースの冗長です。 SRF（シングル予約の流れ）[RFC3524]とANAT（代替ネットワークアドレスタイプ）[RFC4091]メディアストリームの輸送特性に特異的に参照してください。CS（コンポジットセッション）[FLUTE]は、グループFLUTEセッションに使用され、そのためには適用されませんRTP。）
The "ssrc-group" attribute indicates the sources in a group by listing the <ssrc-id>s of the sources in the group. It MUST list at least one <ssrc-id> for a group and MAY list any number of additional ones. Every <ssrc-id> listed in an "ssrc-group" attribute MUST be defined by a corresponding "ssrc:" line in the same media description.
「SSRCグループ」属性は、グループ内の光源の<SSRC-ID> Sをリストすることによって、グループ内のソースを示しています。これは、グループのための少なくとも一つの<SSRC-id>をリストする必要があり、追加のものの任意の数をリストアップしてもよいです。同じメディア記述における線「SSRCグループ」属性に記載されているすべての<SSRC-id>は、対応する「SSRC」によって定義されなければなりません。
The "ssrc-group" media attribute is not dependent on charset.
「SSRCグループ」media属性は、文字セットに依存していません。
Figure 5 in Section 10 gives a formal Augmented Backus-Naur Form (ABNF) [RFC5234] grammar for the "ssrc-group" attribute.
第10節で、図5は、「SSRC-グループ」属性の正式な増補バッカス記法（ABNF）[RFC5234]の文法を与えます。
The synchronization source identifiers used in an RTP session are chosen randomly and independently by endpoints. As such, it is possible for two RTP endpoints to choose the same SSRC identifier. Though the probability of this is low, the RTP specification [RFC3550] requires that all RTP endpoints MUST be prepared to detect and resolve collisions.
RTPセッションで使用される同期ソース識別子は、エンドポイントによってランダムかつ独立して選択されます。 2つのRTPのエンドポイントが同じSSRC識別子を選択するためにこのように、それは可能です。この確率は低いですが、RTP仕様[RFC3550]は、すべてのRTPエンドポイントを検出し、衝突を解決するために準備されている必要があります。
As a result, all endpoints MUST be prepared for the fact that information about specific sources identified in a media stream might be out of date. The actual binding between SSRCs and source CNAMEs can only be identified by the source description (SDES) RTCP packets transmitted on the RTP session.
その結果、すべてのエンドポイントは、メディアストリームで識別される特定のソースに関する情報が古いかもしれないという事実のために準備しなければなりません。 SSRCsソースのCNAMEの間の実際の結合は、ソース記述（SDES）RTPセッション上で送信RTCPパケットによって同定することができます。
When endpoints are choosing their own local SSRC values for media streams for which source-level attributes have been specified, they MUST NOT use for themselves any SSRC identifiers mentioned in media descriptions they have received for the media stream.
エンドポイントは、メディアストリームのために独自のローカルSSRC値を選択している場合は、ソースレベルの属性が指定されているため、彼らは自分たちのために、彼らはメディアストリームのために受信したメディアの説明で述べた任意のSSRC識別子を使用してはなりません。
However, sources identified by SDP source-level attributes do not otherwise affect RTP transport logic. Specifically, sources that are only known through SDP, for which neither RTP nor RTCP packets have been received, MUST NOT be counted for RTP group size estimation, and report blocks MUST NOT be sent for them in SR or RR RTCP messages.
しかし、SDPソースレベル属性によって識別されるソースは、そうでない場合はRTP輸送ロジックには影響を与えません。具体的には、唯一のどちらRTPもRTCPパケットが受信されているためSDPを通じて知られているソースは、RTPのグループサイズの推定のためにカウントされてはならない、とレポートブロックはSRやRR RTCPメッセージで彼らのために送ってはいけません。
Endpoints MUST NOT assume that only the sources mentioned in SDP will be present in an RTP session; additional sources, with previously unmentioned SSRC IDs, can be added at any time, and endpoints MUST be prepared to receive packets from these sources. (How endpoints handle such packets is not specified here; they SHOULD be handled in the same manner as packets from additional sources would be handled had the endpoint not received any a=ssrc: attributes at all.)
エンドポイントは、SDPに記載さだけソースがRTPセッションに存在すると仮定してはいけません。追加のソースは、以前にunmentioned SSRC IDと、任意の時点で添加することができ、エンドポイントは、これらのソースからパケットを受信するように準備しなければなりません。 （ここで指定されていませんどのようにエンドポイントは、このようなパケットを処理;エンドポイントが任意のA = SSRCを受けていない、彼らは追加のソースからのパケットと同じように扱われるべき処理される：全然属性。）
An endpoint that observes an SSRC collision between its explicitly signaled source and another entity that has not explicitly signaled an SSRC MAY delay its RTP collision-resolution actions [RFC3550] by 5*1.5*Td, where Td is the deterministic, calculated, reporting interval for receivers defined in Section 6.3.1 of the RTP specification [RFC3550], to see whether the conflict still exists. (This gives precedence to explicitly signaled sources and places the burden of collision resolution on non-signaled sources.) SSRC collisions between multiple explicitly-signaled sources, however, MUST be acted upon immediately.
その明示的にシグナリング源と明示的SSRC Tdが決定論的計算、報告間隔で5 * 1.5 * Tdと、によってそのRTP衝突解決アクション[RFC3550]を遅延させることができる合図していない他のエンティティとの間のSSRC衝突を観察エンドポイントRTP仕様[RFC3550]のセクション6.3.1で定義された受信機のために、競合がまだ存在するかどうかを確認します。 （これは、明示的にソースを合図するための優先順位を与え、非シグナル源に衝突解決の負担を配置します。）複数の明示的合図ソース間のSSRCの衝突は、しかし、すぐに作用しなければなりません。
If, following RTP's collision-resolution procedures [RFC3550], a source identified by source-level attributes has been forced to change its SSRC identifier, the author of the SDP containing the source-level attributes for these sources SHOULD send out an updated SDP session description with the new SSRC if the mechanism by which SDP is being distributed for the multimedia session has a mechanism to distribute updated SDP. This updated SDP MUST include a "previous-ssrc" source-level attribute, described in Section 6.2, listing the source's previous SSRC ID. (If only a single source with a given CNAME has collided, the other RTP session members can infer a correspondence between the source's old and new SSRC IDs without requiring an updated session description. However, if more than one source collides at once, or if sources are leaving and re-joining, this inference is not possible. To avoid confusion, therefore, sending updated SDP messages is always RECOMMENDED.)
、RTPの衝突解決手順[RFC3550]以下、ソースレベルの属性によって識別されたソースが、そのSSRC識別子を変更することを余儀なくされている場合は、これらのソースが更新SDPセッションを送信すべきであるため、ソースレベルを含むSDPの著者属性新しいSSRCと説明SDPは、マルチメディアセッションのために分散されているメカニズムは、更新されたSDPを配布するためのメカニズムを持っている場合。この更新されたSDPは、ソースの前のSSRC IDをリストアップし、セクション6.2に記載された「前回-SSRC」ソースレベル属性を、含まなければなりません。与えられたCNAMEが衝突したとの唯一の単一のソース場合は（、他のRTPセッションメンバーが更新されたセッション記述を必要とせずに元の古いものと新しいSSRC IDの対応関係を推測することができます。しかし、複数のソースは、一度に衝突した場合、または場合この推論が可能ではない、ソースは残していると再合流。混乱を避けるために、したがって、更新されたSDPメッセージを送信常に推奨されています。）
Endpoints MUST NOT reuse the same SSRC ID for identified sources with the same CNAME for at least the duration of the RTP session's participant timeout interval (see Section 6.3.5 of [RFC3550]). They SHOULD NOT reuse any SSRC ID ever mentioned in SDP (either by themselves or by other endpoints) for the entire lifetime of the RTP session.
エンドポイントは、RTPセッションの参加者のタイムアウト間隔の少なくとも期間に同じCNAMEとの識別情報源に同じSSRC IDを再利用してはいけません（[RFC3550]のセクション6.3.5を参照してください）。彼らは、RTPセッションの全体の寿命のために（単独で、または他のエンドポイントのいずれかによって）今までにSDPで述べた任意のSSRCのIDを再利用すべきではありません。
Endpoints MUST be prepared for the possibility that other parties in the session do not understand SDP source-level attributes, unless some higher-level mechanism normatively requires them. See Section 9 for more discussion of this.
エンドポイントは、いくつかのより高いレベルのメカニズムは、規範的にそれらを必要としない限り、セッション内の他の当事者は、SDPソースレベルの属性を理解していないという可能性のために準備しなければなりません。こののより多くの議論については、セクション9を参照してください。
This section describes specific source attributes that can be applied to RTP sources.
このセクションでは、RTPソースに適用することができ、特定のソース属性について説明します。
a=ssrc:<ssrc-id> cname:<cname>
= SSRC <SSRC-ID> CNAME <CNAME>
The "cname" source attribute associates a media source with its Canonical End-Point Identifier (CNAME) source description (SDES) item. This MUST be the CNAME value that the media sender will place in its RTCP SDES packets; it therefore MUST follow the syntax conventions of CNAME defined in the RTP specification [RFC3550]. If a session participant receives an RTCP SDES packet associating this SSRC with a different CNAME, it SHOULD assume there has been an SSRC collision and that the description of the source that was carried in the SDP description is not applicable to the actual source being received. This source attribute is REQUIRED to be present if any source attributes are present for a source. The "cname" attribute
「CNAME」ソース属性は、そのCanonicalのエンドポイント識別子（CNAME）ソース記述（SDES）アイテムとメディアソースを関連付けます。これは、メディアの送信者がそのRTCP SDESパケットに配置することをCNAME値でなければなりません。したがって、RTP仕様[RFC3550]で定義されたCNAMEの構文規則に従わなければなりません。セッション参加者が異なるCNAMEと、このSSRCを関連付けるRTCP SDESパケットを受信した場合、それはSSRC衝突があったと仮定しなければならず、SDP記述に実施したソースの記述が受信される実際のソースには適用されないこと。このソース属性は、任意のソース属性がソースに存在する場合に存在することが必要です。 「CNAME」属性
MUST NOT occur more than once for the same ssrc-id within a given media stream.
与えられたメディア・ストリーム内の同じSSRC-IDに対して複数回発生してはなりません。
The "cname" source attribute is not dependent on charset.
「CNAME」ソース属性は、文字セットに依存していません。
Figure 6 in Section 10 gives a formal Augmented Backus-Naur Form (ABNF) [RFC5234] grammar for the "cname" attribute.
第10節で、図6は、「CNAME」属性の正式な増補バッカス記法（ABNF）[RFC5234]の文法を与えます。
a=ssrc:<ssrc-id> previous-ssrc:<ssrc-id> ...
= SSRC：<SSRC-id>の前の-SSRC：<SSRC-ID> ...
The "previous-ssrc" source attribute associates a media source with previous source identifiers used for the same media source. Following an SSRC change due to an SSRC collision involving a media source described in SDP, the updated session description describing the source's new SSRC (described in Section 5) MUST include the "previous-ssrc" attribute associating the new SSRC with the old one. If further updated SDP descriptions are published describing the media source, the "previous-ssrc" attribute SHOULD be included if the session description was generated before the participant timeout of the old SSRC, and MAY be included after that point. This attribute, if present, MUST list at least one previous SSRC and MAY list any number of additional SSRCs for the source if the source has collided more than once. This attribute MUST be present only once for each source.
「前回-SSRC」source属性は、同じメディアソースに使用する前のソース識別子を持つメディアソースを関連付けます。 SDP、（5節で説明）ソースの新しいSSRCを記述した更新されたセッションの説明に記載されているメディアソースを含むSSRCの衝突によるSSRCの変更に続いて、古いものと新しいSSRCを関連付ける「前-SSRC」属性を含まなければなりません。さらに、更新SDP記述はメディアソースを記述する公開されている場合は、セッション記述が古いSSRCの参加者のタイムアウト前に生成された、その時点の後に含まれる可能性がある場合は、「以前の-SSRC」属性が含まれるべきです。この属性は、存在する場合、少なくとも一つ前のSSRCをリストする必要がありますし、ソースが複数回衝突した場合、ソースのための追加SSRCsの任意の数をリストアップしてもよいです。この属性は、ソースごとに一度しか存在しなければなりません。
The "previous-ssrc" source attribute is not dependent on charset.
「前回-SSRC」source属性は、文字セットに依存していません。
Figure 7 in Section 10 gives a formal Augmented Backus-Naur Form (ABNF) [RFC5234] grammar for the previous-ssrc attribute.
セクション10における図7は、前-SSRC属性の正式た拡張バッカス - ナウアフォーム（ABNF）[RFC5234]文法を与えます。
a=ssrc:<ssrc> fmtp:<format> <format specific parameters>
= SSRC <SSRC>のfmtp：<フォーマット> <形式特定のパラメータ>
The "fmtp" source attribute allows format-specific parameters to be conveyed about a given source. The <format> parameter MUST be one of the media formats (i.e., RTP payload types) specified for the media stream. The meaning of the <format specific parameters> is unique for each media type. This parameter MUST only be used for media types for which source-level format parameters have explicitly been specified; media-level format parameters MUST NOT be carried over blindly.
「のfmtp」ソース属性は、フォーマット固有のパラメータは、所与のソースについて搬送されることを可能にします。 <フォーマット>パラメータは、メディアストリームのために指定されたメディアフォーマット（すなわち、RTPペイロードタイプ）のいずれかでなければなりません。 <フォーマット特定のパラメータ>の意味は、各メディアタイプのユニークです。このパラメータは、ソース・レベル・フォーマット・パラメータが明示的に指定されているメディアタイプのために使用されなければなりません。メディアレベルフォーマットパラメータは、盲目的に持ち越されてはなりません。
The "fmtp" source attribute is not dependent on charset.
「のfmtp」source属性は、文字セットに依存していません。
This document only defines source attributes that are necessary or useful for an endpoint to decode and render the sources in a media stream. It does not include any attributes that would contribute to an endpoint's decision to accept or reject a stream, e.g., in an offer/answer exchange. Such attributes are for future consideration.
この文書は、メディア・ストリーム内のソースをデコードし、レンダリングするエンドポイントのために必要または有用なソース属性を定義します。これは、オファー/アンサー交換では、例えば、ストリームを受け入れるか拒否するエンドポイントの決定に寄与するであろう任意の属性が含まれていません。このような属性は、今後の検討のためのものです。
This section gives several examples of SDP descriptions of media sessions containing source attributes. For brevity, only the media sections of the descriptions are given.
このセクションでは、ソース属性を含むメディアセッションのSDP記述のいくつかの例を示します。簡潔にするために、説明の唯一のメディアセクションが与えられています。
m=audio 49168 RTP/AVP 0 a=ssrc:314159 cname:user@example.com
M =オーディオ49168 RTP / AVP 0 A = SSRC：314159 CNAME：user@example.com
Figure 1: Example of a declaration of a single synchronization source
図1：単一の同期ソースの宣言の例
The example in Figure 1 shows an audio stream advertising a single source.
図1の例では、単一のソースを広告オーディオストリームを示しています。
m=video 49170 RTP/AVP 96 a=rtpmap:96 H264/90000 a=ssrc:12345 cname:another-user@example.com a=ssrc:67890 cname:another-user@example.com
M =ビデオ49170 RTP / AVP 96 = rtpmap：96 H264 / 90000 = SSRC：12345 CNAME：another-user@example.com A = SSRC：67890 CNAME：another-user@example.com
Figure 2: Example of a media stream containing several independent sources from a single session member
図2：単一セッションメンバーからいくつかの独立した源を含むメディア・ストリームの例
The example in Figure 2 shows a video stream where one participant (identified by a single CNAME) has several cameras. The sources could be further distinguished by RTCP Source Description (SDES) information.
図2の例では、（単一のCNAMEによって識別される）一人の参加者が複数のカメラを有するビデオストリームを示しています。ソースはさらにRTCPソース記述（SDES）情報によって区別することができました。
m=video 49174 RTP/AVPF 96 98 a=rtpmap:96 H.264/90000 a=rtpmap:98 rtx/90000 a=fmtp:98 apt=96;rtx-time=3000 a=ssrc-group:FID 11111 22222 a=ssrc:11111 cname:user3@example.com a=ssrc:22222 cname:user3@example.com a=ssrc-group:FID 33333 44444 a=ssrc:33333 cname:user3@example.com a=ssrc:44444 cname:user3@example.com
M =ビデオ49174 RTP / AVPF 96 98 = rtpmap：96 H.264 / 90000 = rtpmap：98 RTX / 90000 =のfmtp：98やすい= 96; RTX-時間= 3000 = SSRCグループ：FID 11111 22222 = SSRC：11111 CNAME：user3@example.com A = SSRC：22222 CNAME：user3@example.com A = SSRCグループ：FID 33333 44444 = SSRC：33333 CNAME：user3@example.com A = SSRC：44444 CNAME：user3@example.com
Figure 3: Example of the relationships among
several retransmission sources
The example in Figure 3 shows how the relationships among sources used for RTP retransmission [RFC4588] can be explicitly signaled. This prevents the complexity of associating original sources with retransmission sources when SSRC multiplexing is used for RTP retransmission, as is described in Section 5.3 of [RFC4588].
図3の例では、RTP再送[RFC4588]のために使用されるソース間の関係を明示的にシグナリングすることができる方法を示しています。これは、[RFC4588]のセクション5.3に記載されているようにSSRC多重化は、RTP再送信のために使用される場合、再送ソースとオリジナルソースを関連付けることの複雑さを防止します。
When used with the SDP Offer/Answer Model [RFC3264], SDP source-specific attributes describe only the sources that each party is willing to send (whether it is sending RTP data or RTCP report blocks). No mechanism is provided by which an answer can accept or reject individual sources within a media stream; if the set of sources in a media stream is unacceptable, the answerer's only option is to reject the media stream or the entire multimedia session.
SDPオファー/アンサーモデル[RFC3264]で使用される場合、SDPのソース固有の属性は、（それがRTPデータまたはRTCPレポートブロックを送信しているかどうか）、各当事者は、送信しても構わないと思っているだけのソースを記載しています。メカニズムは、答えは、メディアストリーム内の個々の供給源を受け入れるか拒否することができるによって提供されていません。メディアストリームにおけるソースのセットが受け入れられない場合は、回答者の唯一のオプションは、メディアストリームまたは全体のマルチメディアセッションを拒否することです。
The SSRC IDs for sources described by an SDP answer MUST be distinct from the SSRC IDs for sources of that media stream in the offer. Similarly, new SSRC IDs in an updated offer MUST be distinct from the SSRC IDs for that media stream established in the most recent offer/ answer exchange for the session and SHOULD be distinct from any SSRC ID ever used by either party within the multimedia session (whether or not it is still being used).
SDPアンサーによって記述ソースのSSRC IDが提供におけるそのメディアストリームのソースのSSRC IDが異なるものでなければなりません。同様に、更新のオファーで新しいSSRC IDはセッションのための最新のオファー/アンサー交換に設立されているメディアストリームのためのSSRC IDとは区別する必要があり、これまでのマルチメディアセッション内のいずれかの当事者（で使用される任意のSSRC IDとは区別すべきである（SHOULD） ）それはまだ使用されているかどうか。
According to the definition of SDP, interpreters of SDP session descriptions ignore unknown attributes. Thus, endpoints MUST be prepared that recipients of their RTP media session may not understand their explicit source descriptions, unless some external mechanism indicates that they were understood. In some cases (such as RTP Retransmission [RFC4588]), this may constrain some choices about the bitstreams that are transmitted.
SDPの定義によれば、SDPセッション記述の通訳は、未知の属性を無視します。このように、エンドポイントは、いくつかの外部機構は、彼らが理解していることを示していない限り、そのRTPメディアセッションの受信者は、明示的なソースの説明を理解しないかもしれないことを準備しなければなりません。 （例えばRTP再送[RFC4588]のような）いくつかの場合において、これは送信されるビットストリームについてのいくつかの選択肢を制限することができます。
Source descriptions are specified in this document such that RTP endpoints that are compliant with the RTP specification [RFC3550] will be able to decode the media streams they describe whether or not they support explicit source descriptions. However, some deployed RTP implementations may not actually support multiple media sources in a media stream. Media senders MAY wish to restrict themselves to a single source at a time unless they have some means of concluding that the receivers of the media stream support source multiplexing.
ソース記述は、この文書で指定されているようにRTP仕様[RFC3550]に準拠したRTPエンドポイントは、彼らが明示的なソース記述をサポートしているか否か、彼らは記述メディアストリームをデコードできるようになること。しかし、いくつかの展開RTPの実装は、実際には、メディアストリーム内の複数のメディアソースをサポートしていないかもしれません。メディアの送信者は、彼らがいることを結論付けるの何らかの手段を持っていない限り、一度に単一のソースに自分自身を制限したい場合も、メディアストリームサポート源多重の受信機。
This section gives a formal Augmented Backus-Naur Form (ABNF) [RFC5234] grammar for each of the new media and source attributes defined in this document. Grammars for existing session or media attributes that have been extended to be source attributes are not included.
このセクションでは、この文書で定義された新しいメディアとソースの属性のそれぞれについて、正式な増補バッカス記法（ABNF）[RFC5234]の文法を与えます。ソース属性が含まれていないことに拡張されている既存のセッションまたはメディア属性の文法。
Copyright (c) 2009 IETF Trust and the persons identified as authors of the code. All rights reserved.
著作権（C）2009 IETF信託コードの作者として特定の人物。全著作権所有。
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
再配布および、改変してまたは改変せずに、ソースおよびバイナリ形式で使用し、以下の条件が満たされていることを許可されます。
o Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
Oソースコードの再配布は、上記の著作権表示、条件のリストおよび以下の免責事項を保持しなければなりません。
o 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.
Oバイナリ形式で再配布は、上記の著作権表示、条件のリストおよび文書および/または分布を備えた他の材料で次の免責事項を再現しなければなりません。
o 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.
Oインターネット協会、IETFやIETFトラストの名称、また具体的な貢献者の名前はどちらも、特定の書面による事前の許可なしに、本ソフトウェアから派生した製品を推薦または促進するために使用することができます。
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 'AS IS' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 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.
このソフトウェアは、著作権所有者によって提供され、貢献者AS IS 'AND明示または黙示の保証、含むがこれらに限定されないが、特定目的に対する適合性の黙示の保証を放棄されています。 NO EVENTの著作権所有者または貢献者は、以下を含むいかなる直接的、間接的、偶発的、特別、懲罰的、または間接的損害（についても責任を負いあってもよいが、代替商品またはサービスの調達、これらに限定されないものとし、使用、データ、または利益の損失; OR事業の中断）原因で生じた（そのような損害の可能性について知らされていた場合でも、一切このソフトウェアの使用の損失、データの損失）過失またはその他を含む責任、それが契約、厳格な責任、不法行為のどのような理論の上で。
ssrc-attr = "ssrc:" ssrc-id SP attribute ; The base definition of "attribute" is in RFC 4566. ; (It is the content of "a=" lines.)
SSRC-ATTR = "SSRC：" SSRC-IDのSP属性。 「属性」の基本定義は、RFC 4566.です。 （これは「A =」行の内容です。）
ssrc-id = integer ; 0 .. 2**32 - 1
SSRC-ID =整数。 0 .. 2 ** 32から1
attribute =/ ssrc-attr
属性= / SSRC-ATTR
Figure 4: Syntax of the "ssrc" media attribute
図4：「SSRC」media属性の構文
ssrc-group-attr = "ssrc-group:" semantics *(SP ssrc-id)
SSRC-グループのattr = "SSRC-グループ：" 意味論*（SP SSRC-ID）
semantics = "FEC" / "FID" / token ; Matches RFC 3388 definition and ; IANA registration rules in this doc.
意味論= "FEC" / "FID" /トークン。 RFC 3388の定義と一致します。このドキュメントでIANA登録ルール。
token = <as defined in RFC 4566>
<RFC 4566で定義されるように> =トークン
attribute =/ ssrc-group-attr
属性= / SSRC-グループATTR
Figure 5: Syntax of the "ssrc-group" media attribute
図5：「SSRC-グループ」の構文media属性
cname-attr = "cname:" cname
CNAME-ATTR = "CNAME：" CNAME
cname = byte-string ; Following the syntax conventions for CNAME as defined in RFC 3550. ; The definition of "byte-string" is in RFC 4566.
CNAME =バイト文字列。 RFC 3550で定義されているCNAMEのための構文規則に続いて、 「バイト列」の定義は、RFC 4566です。
attribute =/ cname-attr
属性= / CNAME-ATTR
Figure 6: Syntax of the "cname" source attribute
図6：「CNAME」ソース属性の構文
previous-ssrc-attr = "previous-ssrc:" ssrc-id *(SP ssrc-id)
前-SSRC-ATTR = "前-SSRC：" SSRC-ID *（SP SSRC-ID）
attribute =/ previous-ssrc-attr
属性= /前回-SSRC-ATTR
Figure 7: Syntax of the "previous-ssrc" source attribute
図7：「前-SSRC」source属性の構文
All the security implications of RTP [RFC3550] and of SDP [RFC4566] apply. Explicitly describing the multiplexed sources of an RTP media stream does not appear to add any further security issues.
RTP [RFC3550]のとSDPのすべてのセキュリティへの影響[RFC4566]適用されます。明示的なRTPメディアストリームの多重化ソースを記述しても、更なるセキュリティの問題を追加するためには表示されません。
This document defines two SDP media-level attributes: "ssrc" and "ssrc-group". These attributes have been registered by IANA under "Session Description Protocol (SDP) Parameters" under "att-field (media level only)".
「SSRC」と「SSRC-グループ」：このドキュメントでは、2 SDPのメディアレベル属性を定義します。これらの属性は、「ATT-フィールド（メディアレベルのみ）」の「セッション記述プロトコル（SDP）パラメータ」の下でIANAによって登録されています。
The "ssrc" attribute is used to identify characteristics of media sources within a media stream. Its format is defined in Section 4.1.
「SSRC」属性は、メディア・ストリーム内のメディアソースの特性を識別するために使用されます。そのフォーマットはセクション4.1で定義されています。
The "ssrc-group" attribute is used to identify relationships among media sources within a media stream. Its format is defined in Section 4.2.
「SSRCグループ」属性は、メディアストリーム内のメディアソース間の関係を識別するために使用されます。そのフォーマットは、セクション4.2で定義されています。
This specification creates a new IANA registry named "att-field (source level)" within the SDP parameters registry. Source attributes MUST be registered with IANA and documented under the same rules as for SDP session-level and media-level attributes as specified in [RFC4566].
この仕様は、SDPパラメータレジストリ内「ATTフィールド（ソースレベル）」という名前の新しいIANAレジストリを作成します。ソース属性はIANAに登録され、[RFC4566]で指定された属性としてSDPセッションレベル及びメディアレベルと同じ規則の下で文書化されなければなりません。
New attribute registrations are accepted according to the "Specification Required" policy of [RFC5226], provided that the specification includes the following information:
新しい属性の登録は[RFC5226]の「仕様が必要である」というポリシーに基づいて受け入れられている、仕様は以下の情報が含まれていることを提供します。
o contact name, email address, and telephone number
Oの連絡先の名前、電子メールアドレス、および電話番号
o attribute name (as it will appear in SDP)
（それはSDPに表示される）O属性名
o long-form attribute name in English
英語でのO長い形式の属性名
o whether the attribute value is subject to the charset attribute
属性値がcharset属性の対象となるかどうかをO
o a one-paragraph explanation of the purpose of the attribute
O属性の目的の1段落の説明
o a specification of appropriate attribute values for this attribute
この属性の適切な属性値の仕様O
The above is the minimum that IANA will accept. The Expert Reviewer will determine if the proposed attributes are expected to see widespread use and interoperability; in that case, the attributes MUST be specified in a Standards Track RFC.
上記はIANAが受け入れる最小値です。提案された属性が広く使用して相互運用性を確認することが予想される場合には専門家のレビューは、決定します。その場合には、属性が標準化過程のRFCで指定する必要があります。
Submitters of registrations should ensure that the specification is in the spirit of SDP attributes, most notably that the attribute is platform independent in the sense that it makes no implicit assumptions about operating systems and does not name specific pieces of software in a manner that might inhibit interoperability.
登録の提出者は、仕様がSDP属性の精神であることを確認する必要があり、最も顕著な属性は、オペレーティング・システムについての暗黙の仮定を行わず、阻害し得る方法で、ソフトウェアの特定の部分に名前を付けていないという意味で、独立したプラットフォームであること相互運用性。
Source-level attributes that are substantially similar in semantics to existing session-level or media-level attributes SHOULD reuse the same attribute name as those session-level or media-level attributes. Source-level attributes SHOULD NOT reuse attribute names of session-level or media-level attributes that are unrelated or substantially different.
既存のセッションレベルまたはメディアレベル属性にセマンティクスが実質的に類似しているソースレベルの属性は、これらのセッションレベルまたはメディアレベルの属性と同じ属性名を再利用する必要があります。ソースレベルの属性は関係のない、または実質的に異なっているセッションレベルまたはメディアレベル属性の属性名を再利用すべきではありません。
The initial set of source attribute names, with definitions in Section 6 of this document, is in Figure 8.
このドキュメントのセクション6で定義とソースの属性名の最初のセットは、図8です。
Type SDP Name Reference
---- ------------------ ---------
att-field (source level)
cname [RFC5576]
previous-ssrc [RFC5576]
fmtp [RFC5576]
Figure 8: Initial contents of the IANA Source Attribute Registry
図8：IANAソース属性レジストリの初期内容
This specification creates a new IANA registry named 'Semantics for the "ssrc-group" SDP Attribute' within the SDP parameters registry. Source group semantics MUST be defined in Standards Track RFCs, under the same rules as [RFC3388].
この仕様は、SDPパラメータレジストリ内の「『SSRC-グループ』 SDP属性の意味」という名前の新しいIANAレジストリを作成します。ソースグループのセマンティクスは[RFC3388]と同じルールの下で、標準化過程のRFCで定義されなければなりません。
The IANA Considerations section of the RFC MUST include the following information, which appears in the IANA registry along with the RFC number of the publication:
RFCのIANA Considerations部は、出版のRFC番号とともにIANAレジストリに表示される次の情報を含める必要があります。
o A brief description of the semantics.
意味論の簡単な説明、O。
o Token to be used within the group attribute. This token may be of any length, but SHOULD be no more than four characters long.
Oトークンは、グループ属性内で使用されます。このトークンは、任意の長さのものであってもよいが、4つ以下の文字長さであるべきです。
o Reference to a Standards Track RFC.
標準化過程のRFCにOリファレンス。
Source grouping semantic values that are substantially similar to existing media grouping semantic values SHOULD reuse the same semantics name as those media grouping semantics. Source grouping semantics SHOULD NOT reuse source grouping semantic names that are unrelated or substantially different.
意味値をグループ化し、既存のメディアに実質的に類似している意味値をグループ化ソースはセマンティクスをグループ化し、それらのメディアと同じセマンティクス名を再利用する必要があります。ソースグループ化セマンティクスは無関係なまたは実質的に異なるセマンティック名をグループ化し、ソースを再利用すべきではありません。
The initial set of source grouping semantic values, for the semantics specified in Section 4.2 of this document, is in Figure 9.
セマンティック値をグループ化ソースの初期セットは、このドキュメントのセクション4.2で指定された意味のために、図9にあります。
Semantics Token Reference
------------------- ----- ---------
Flow Identification FID [RFC5576]
Forward Error Correction FEC [RFC5576]
Figure 9: Initial Contents of IANA Source Group Semantics Registry
図9：IANAソースグループセマンティクスレジストリの初期の内容
[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月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264]ローゼンバーグ、J.とH. Schulzrinneと、RFC 3264、2002年6月 "セッション記述プロトコル（SDP）とのオファー/アンサーモデル"。
[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月。
[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月。
[RFC4756] Li, A., "Forward Error Correction Grouping Semantics in Session Description Protocol", RFC 4756, November 2006.
[RFC4756]李、A.、 "セッション記述プロトコルでセマンティクスをグループ化する前方誤り訂正"、RFC 4756、2006年11月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 5226、2008年5月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]クロッカー、D.、およびP. Overell、 "構文仕様のための増大しているBNF：ABNF"、STD 68、RFC 5234、2008年1月。
[EXT-SSM] Schooler, E., Ott, J., and J. Chesterfield, "RTCP Extensions for Single-Source Multicast Sessions with Unicast Feedback", Work in Progress, March 2009.
[EXT-SSM]学生は、E.、オット、J.、およびJ.チェスターフィールド、 "ユニキャストフィードバック付きシングルソースのマルチキャストセッションのRTCP拡張機能"、進歩、2009年3月での作業。
[FLUTE] Mehta, H., "SDP Descriptors for FLUTE", Work in Progress, January 2006.
[FLUTE]メータ、H.、 "FLUTEのためのSDP記述子"、進歩、2006年1月の作業。
[ICE] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", Work in Progress, October 2007.
[ICE]ローゼンバーグ、J.、「インタラクティブ接続確立（ICE）：オファー/回答プロトコルのためのネットワークアドレス変換（NAT）トラバーサルのための議定書」、進歩、2007年10月の作業。
[RFC3524] Camarillo, G. and A. Monrad, "Mapping of Media Streams to Resource Reservation Flows", RFC 3524, April 2003.
[RFC3524]キャマリロ、G.とA. Monrad、RFC 3524、2003年4月 "予約・フローをリソースへのメディアストリームのマッピング"。
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004.
[RFC3830] Arkko、J.、カララ、E.、リンドホルム、F.、Naslund、M.、およびK. Norrman、 "MIKEY：マルチメディアインターネットキーイング"、RFC 3830、2004年8月。
[RFC4091] Camarillo, G. and J. Rosenberg, "The Alternative Network Address Types (ANAT) Semantics for the Session Description Protocol (SDP) Grouping Framework", RFC 4091, June 2005.
[RFC4091]キャマリロ、G.およびJ.ローゼンバーグ、RFC 4091、2005年6月 "セッション記述プロトコル（SDP）グループ化フレームワークの代替ネットワークアドレスタイプ（ANAT）セマンティクス"。
[RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. Carrara, "Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)", RFC 4567, July 2006.
[RFC4567] Arkko、J.、リンドホルム、F.、Naslund、M.、Norrman、K.、およびE.カララ、 "鍵管理拡張セッション記述プロトコル（SDP）、リアルタイムストリーミングプロトコル（RTSP）のための"、RFC 4567、2006年7月。
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, July 2006.
[RFC4588]レイ、J.、レオン、D.、宮崎、A.、Varsa、V.、およびR. Hakenberg、 "RTP再送信ペイロードフォーマット"、RFC 4588、2006年7月。
[RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, January 2008.
[RFC5117]ウェスター、M.とS.ベンゲル監督、 "RTPトポロジ"、RFC 5117、2008年1月。
Authors' Addresses
著者のアドレス
Jonathan Lennox Vidyo, Inc. 433 Hackensack Avenue Sixth Floor Hackensack, NJ 07601 US
ジョナサン・レノックスにVidyo社433ハッケンサックアベニューシックスフロアハッケンサック、NJ 07601米国
EMail: jonathan@vidyo.com
メールアドレス：jonathan@vidyo.com
Joerg Ott Helsinki University of Technology (TKK) Department of Communications and Networking PO Box 3000 FIN-02015 TKK Finland
通信の技術のイェルクオットヘルシンキ大学（TKK）部門とネットワーク私書箱3000 FIN-02015 TKKフィンランド
EMail: jo@acm.org
メールアドレス：jo@acm.org
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