[要約] RFC 5576は、SDPでソース固有のメディア属性を定義するための仕様です。このRFCの目的は、マルチキャストやソース固有のメディアストリームをサポートするために、SDPに新しい属性を導入することです。
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)
セッション説明プロトコル（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.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびこのドキュメントの公開日（http://trustee.ietf.org/license-info）に有効なIETFドキュメントに関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの貢献からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得しないと、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版または英語以外の言語に翻訳する。
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.
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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セッションは通常、単一の輸送アドレス（マルチキャストの場合）または通信フロー（ユニキャストの場合）に関連付けられていますが、RTP翻訳者とシングルソースマルチキャスト[EXT-SSM]は状況をより複雑にする可能性があります。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つのタイプのマルチメディアデータが伝達される他のメディアパスです。マルチメディアセッション全体に適用される情報はセッションレベルの情報と呼ばれ、1つのメディアストリームに関連する情報はメディアレベルの情報と呼ばれます。メディアストリームを説明するすべての情報のコレクションは、メディアの説明として知られています。（メディアの説明は、メディアの説明を開始するSDP構文の後、SDP "M"ラインとして非公式に知られていることもあります。）セッションレベルとメディアレベルの両方でいくつかの標準情報要素が定義されます。拡張情報は、属性を使用して両方のレベルに含めることができます。
(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メディアの説明で記述されたオブジェクトを示すために、多くのSDP拡張機能、たとえばインタラクティブ接続確立（ICE）[ICE]で使用されます。RTP仕様[RFC3550]は「メディアストリーム」という用語を使用して、SSRCによって識別される個々のメディアソースまたはRTPパケットストリームを参照するため、この用語はかなり混乱していますが、SDPメディアストリームは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-Group」を定義します。
a=ssrc:<ssrc-id> <attribute>
a=ssrc:<ssrc-id> <attribute>:<value>
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ビットの符号なし整数として解釈され、10進数で表されます。<属性>または<属性>：<value>は、指定されたメディアソースに固有のソースレベルの属性を表します。ソースレベルの属性は、SDP "a ="行の構文に従います。したがって、単一の属性名（フラグ）または属性名と値（「cname：user@example.com」など）で構成されています。このドキュメントでは、前者のタイプの属性は定義されていません。
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-ID>の同じ値を持つ「SSRC」属性は、同じメディアソースの異なる属性を説明しています。メディアストリーム全体で、<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」メディア属性は、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」属性の正式な増強されたBackus-Naurフォーム（ABNF）[RFC5234]文法を示しています。
The "ssrc" media attribute is not dependent on charset.
「SSRC」メディア属性は、charsetに依存しません。
a=ssrc-group:<semantics> <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-Group」は、RTPセッションのいくつかのソース間の関係を表しています。これは、SDPマルチメディアセッション（つまり、いくつかの論理的に関連するRTPセッション間の関係）でメディアストリーム間の関係を表す「グループ」セッションレベルの属性[RFC3388]に類似しています。ソースはすでに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.
<semantic>パラメーターは、「グループ」属性[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-Group」セマンティック値は、「グループ」セマンティック値と同じ構文に従いますが、それらは独立して定義されます。セクション12.3で定義されているレジストリを使用して、すべての「SSRCグループ」セマンティック値を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]およびアナット（代替ネットワークアドレスタイプ）[RFC4091]は、メディアストリームのトランスポート特性を特に参照してください。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-Group」属性は、グループ内のソースの<SSRC-ID>をリストすることにより、グループのソースを示します。グループの少なくとも1つの<SSRC-ID>をリストする必要があり、任意の数の追加のものをリストする場合があります。「SSRCグループ」属性にリストされているすべての<SSRC-ID>は、対応する「SSRC：「」の同じメディアの説明の「線」で定義する必要があります。
The "ssrc-group" media attribute is not dependent on charset.
「SSRC-Group」メディア属性は、charsetに依存しません。
Figure 5 in Section 10 gives a formal Augmented Backus-Naur Form (ABNF) [RFC5234] grammar for the "ssrc-group" attribute.
セクション10の図5は、「SSRC-Group」属性の正式な増強されたバックナウルフォーム（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.
その結果、すべてのエンドポイントは、メディアストリームで特定された特定のソースに関する情報が古くなっている可能性があるという事実に対して準備する必要があります。SSRCとソースCNAMEの間の実際のバインディングは、RTPセッションで送信されるソース説明（SDES）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セッションに存在すると仮定してはなりません。以前に言及されていないSSRC IDを備えた追加のソースは、いつでも追加でき、これらのソースからパケットを受信するためにエンドポイントを準備する必要があります。（このようなパケットを処理する方法は、ここでは指定されていません。追加のソースからのパケットが扱われるのと同じ方法で処理する必要があります。
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を明示的に信号していない別のエンティティとの間のSSRC衝突を観察するエンドポイントは、RTP衝突解像度アクション[RFC3550]を5*1.5*TDで遅らせる可能性があります。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には、セクション6.2で説明されている「以前のSSRC」ソースレベルの属性を含める必要があり、ソースの以前のSSRC IDをリストします。（特定の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>
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 MUST NOT occur more than once for the same ssrc-id within a given media stream.
「CNAME」ソース属性は、メディアソースを標準的なエンドポイント識別子（CNAME）ソース説明（SDES）項目に関連付けます。これは、メディア送信者がRTCP SDESパケットに配置するcname値でなければなりません。したがって、RTP仕様[RFC3550]で定義されているCNAMEの構文規則に従う必要があります。セッション参加者がこのSSRCを別のCNAMEに関連付けたRTCP SDESパケットを受け取った場合、SSRC衝突があり、SDP説明で運ばれたソースの説明が実際のソースに適用されないと仮定する必要があります。ソースにソース属性が存在する場合、このソース属性が存在する必要があります。「CNAME」属性は、特定のメディアストリーム内の同じSSRC-IDで複数回発生してはなりません。
The "cname" source attribute is not dependent on charset.
「cname」ソース属性は、charsetに依存しません。
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> ...
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」ソース属性は、メディアソースを同じメディアソースに使用した以前のソース識別子と関連付けます。SDPに記載されているメディアソースを含むSSRC衝突によるSSRCの変更に続いて、ソースの新しいSSRC（セクション5で説明）を説明する更新されたセッション説明には、新しいSSRCを古いSSRCに関連付ける「以前のSSRC」属性を含める必要があります。メディアソースを記述するさらに更新されたSDPの説明が公開されている場合、古いSSRCの参加者のタイムアウトの前にセッションの説明が生成された場合、「前SSRC」属性を含める必要があり、その時点以降に含まれる場合があります。この属性は、存在する場合、少なくとも1つの以前のSSRCをリストする必要があり、ソースが複数回衝突した場合、ソースの追加のSSRCを任意の数の追加のSSRCをリストする場合があります。この属性は、各ソースに対して一度だけ存在する必要があります。
The "previous-ssrc" source attribute is not dependent on charset.
「以前のSSRC」ソース属性は、charsetに依存しません。
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>
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ペイロードタイプ）の1つでなければなりません。<フォーマット固有のパラメーター>の意味は、メディアタイプごとに一意です。このパラメーターは、ソースレベルの形式パラメーターが明示的に指定されているメディアタイプにのみ使用する必要があります。メディアレベルのフォーマットパラメーターを盲目的に持ち越してはなりません。
The "fmtp" source attribute is not dependent on charset.
「fmtp」ソース属性は、charsetに依存しません。
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
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
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の例は、1人の参加者（単一の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
Figure 3: Example of the relationships among several retransmission sources
図3：いくつかの再送信ソース間の関係の例
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レポートブロックを送信しているかどうか）。回答がメディアストリーム内の個々のソースを受け入れるか拒否できるメカニズムは提供されていません。メディアストリーム内のソースのセットが受け入れられない場合、Answererの唯一のオプションは、メディアストリームまたはマルチメディアセッション全体を拒否することです。
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とは異なる必要があります（それがまだ使用されているかどうか）。
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エンドポイント[RFC3550]が、明示的なソースの説明をサポートするかどうかを説明するメディアストリームをデコードできるように、このドキュメントで指定されています。ただし、いくつかの展開された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.
このセクションでは、このドキュメントで定義されている新しいメディアおよびソース属性のそれぞれについて、正式な増強されたBackus-Naurフォーム（ABNF）[RFC5234]文法を示します。ソース属性に拡張された既存のセッションまたはメディア属性の文法は含まれていません。
Copyright (c) 2009 IETF Trust and the persons identified as authors of the code. All rights reserved.
Copyright（c）2009 IETF TrustおよびCodeの著者として特定された人。全著作権所有。
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
変更とバイナリ形式での再配布と使用は、変更を伴うまたは伴わない場合、次の条件が満たされている場合が許可されています。
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.
このソフトウェアは、著作権所有者と貢献者が「現状のまま」と、特定の目的に対する黙示の保証と黙示的または黙示的な保証が提供されますが、これらに限定されない保証が提供されます。いかなる場合でも、著作権所有者または貢献者は、直接的、間接的、偶発的、特別な、模範的、または結果的な損害（代替品またはサービスの調達を含むがこれらに限定されない、使用の損失、データ、または利益に対して責任を負いません。ただし、契約、厳格責任、または不法行為（過失などを含む）であろうと、このソフトウェアの使用から何らかの形で発生するかどうかにかかわらず、責任の理論に起因します。
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
attribute =/ ssrc-attr
属性=/ ssrc-attr
Figure 4: Syntax of the "ssrc" media attribute
図4：「SSRC」メディア属性の構文
ssrc-group-attr = "ssrc-group:" semantics *(SP ssrc-id)
semantics = "FEC" / "FID" / token
; Matches RFC 3388 definition and
; IANA registration rules in this doc.
token = <as defined in RFC 4566>
attribute =/ ssrc-group-attr
Figure 5: Syntax of the "ssrc-group" media attribute
図5：「SSRC-Group」メディア属性の構文
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 = byte-string;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)
attribute =/ previous-ssrc-attr
属性=/前SSRC-ATTR
Figure 7: Syntax of the "previous-ssrc" source attribute
図7：「前SSRC」ソース属性の構文
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)".
このドキュメントでは、2つのSDPメディアレベルの属性を定義します：「SSRC」と「SSRC-Group」。これらの属性は、「att-field（メディアレベルのみ）」の下にある「セッション説明プロトコル（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-Group」属性は、メディアストリーム内のメディアソース間の関係を識別するために使用されます。その形式は、セクション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-field（source level）」という名前の新しい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)
o 属性名（SDPに表示されるように）
o long-form attribute name in English
o 英語のロングフォーム属性名
o whether the attribute value is subject to the charset attribute
o 属性値がcharset属性の対象かどうか
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-Group」SDP属性のセマンティクスという名前の新しいIANAレジストリを作成します。ソースグループセマンティクスは、[RFC3388]と同じルールの下で、RFCSを追跡する標準で定義する必要があります。
The IANA Considerations section of the RFC MUST include the following information, which appears in the IANA registry along with the RFC number of the publication:
RFCのIANAに関する考慮事項セクションには、IANAレジストリに表示される以下の情報と、出版物のRFC番号を含める必要があります。
o A brief description of the semantics.
o セマンティクスの簡単な説明。
o Token to be used within the group attribute. This token may be of any length, but SHOULD be no more than four characters long.
o グループ属性内で使用されるトークン。このトークンは任意の長さである可能性がありますが、長さ4文字以下でなければなりません。
o Reference to a Standards Track RFC.
o RFCを追跡する標準への参照。
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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Rosenberg、J。およびH. Schulzrinne、「セッション説明プロトコル（SDP）のオファー/回答モデル」、RFC 3264、2002年6月。
[RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H. Schulzrinne, "Grouping of Media Lines in the Session Description Protocol (SDP)", RFC 3388, December 2002.
[RFC3388] Camarillo、G.、Eriksson、G.、Holler、J。、およびH. Schulzrinne、「セッション説明プロトコル（SDP）のメディアラインのグループ化」、RFC 3388、2002年12月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：リアルタイムアプリケーション用の輸送プロトコル」、STD 64、RFC 3550、2003年7月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：セッション説明プロトコル」、RFC 4566、2006年7月。
[RFC4756] Li, A., "Forward Error Correction Grouping Semantics in Session Description Protocol", RFC 4756, November 2006.
[RFC4756] Li、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] Crocker、D。およびP. Overell、「構文仕様のためのBNFの増強」、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] Schooler、E.、Ott、J。、およびJ. Chesterfield、「ユニキャストフィードバックを備えたシングルソースマルチキャストセッション用のRTCP拡張」、2009年3月、進行中の作業。
[FLUTE] Mehta, H., "SDP Descriptors for FLUTE", Work in Progress, January 2006.
[flute] Mehta、H。、「フルートの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] Rosenberg、J。、「Interactive Connectivity Indecivity（ICE）：オファー/回答プロトコルのネットワークアドレス翻訳者（NAT）トラバーサルのプロトコル」、2007年10月の進行中。
[RFC3524] Camarillo, G. and A. Monrad, "Mapping of Media Streams to Resource Reservation Flows", RFC 3524, April 2003.
[RFC3524] Camarillo、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.、Carrara、E.、Lindholm、F.、Naslund、M。、およびK. Norrman、「Mikey：Multimedia Internet Keying」、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] Camarillo、G。およびJ. Rosenberg、「セッション説明プロトコル（SDP）グループ化フレームワークの代替ネットワークアドレスタイプ（ANAT）セマンティクス」、RFC 4091、2005年6月。
[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.、Lindholm、F.、Naslund、M.、Norrman、K。、およびE. Carrara、「セッション説明プロトコル（SDP）およびリアルタイムストリーミングプロトコル（RTSP）の主要な管理拡張機能」、RFC4567、2006年7月。
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, July 2006.
[RFC4588] Rey、J.、Leon、D.、Miyazaki、A.、Varsa、V。、およびR. Hakenberg、「RTP再送信ペイロードフォーマット」、RFC 4588、2006年7月。
[RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, January 2008.
[RFC5117] Westerlund、M。およびS. Wenger、「RTP Topologies」、RFC 5117、2008年1月。
Authors' Addresses
著者のアドレス
Jonathan Lennox Vidyo, Inc. 433 Hackensack Avenue Sixth Floor Hackensack, NJ 07601 US
Jonathan Lennox Vidyo、Inc。433 Hackensack Avenue Sixth Floor Hackensack、NJ 07601 US
EMail: jonathan@vidyo.com
Joerg Ott Helsinki University of Technology (TKK) Department of Communications and Networking PO Box 3000 FIN-02015 TKK Finland
Joerg Ott Helsinki工科大学（TKK）コミュニケーションおよびネットワーキングPO Box 3000 FIN-02015 TKKフィンランド
EMail: jo@acm.org
Thomas Schierl Fraunhofer HHI Einsteinufer 37 D-10587 Berlin Germany
Thomas Schierl Fraunhofer HHI Einsteinufer 37 D-10587ベルリンドイツ
Phone: +49-30-31002-227
EMail: ts@thomas-schierl.de