[要約] RFC 8088は、RTPペイロード形式の作成方法についてのガイドラインです。このRFCの目的は、RTPパケットのペイロード形式を定義するための手順と要件を提供することです。
Internet Engineering Task Force (IETF) M. Westerlund
Request for Comments: 8088 Ericsson
Updates: 2736 May 2017
Category: Informational
ISSN: 2070-1721
How to Write an RTP Payload Format
RTPペイロード形式の書き方
Abstract
概要
This document contains information on how best to write an RTP payload format specification. It provides reading tips, design practices, and practical tips on how to produce an RTP payload format specification quickly and with good results. A template is also included with instructions.
このドキュメントには、RTPペイロード形式の仕様を記述するための最良の方法に関する情報が含まれています。 RTPペイロード形式の仕様を迅速に作成し、優れた結果を得る方法についての、読み方のヒント、設計方法、および実用的なヒントを提供します。説明書にはテンプレートも含まれています。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8088.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8088で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Structure ..................................................4
2. Terminology .....................................................5
2.1. Definitions ................................................5
2.2. Abbreviations ..............................................5
2.3. Use of Normative Requirements Language .....................6
3. Preparations ....................................................6
3.1. Read and Understand the Media Coding Specification .........6
3.2. Recommended Reading ........................................7
3.2.1. IETF Process and Publication ........................7
3.2.2. RTP .................................................9
3.3. Important RTP Details .....................................13
3.3.1. The RTP Session ....................................13
3.3.2. RTP Header .........................................14
3.3.3. RTP Multiplexing ...................................16
3.3.4. RTP Synchronization ................................16
3.4. Signaling Aspects .........................................18
3.4.1. Media Types ........................................19
3.4.2. Mapping to SDP .....................................20
3.5. Transport Characteristics .................................23
3.5.1. Path MTU ...........................................23
3.5.2. Different Queuing Algorithms .......................23
3.5.3. Quality of Service .................................24
4. Standardization Process for an RTP Payload Format ..............24
4.1. IETF ......................................................25
4.1.1. Steps from Idea to Publication .....................25
4.1.2. WG Meetings ........................................27
4.1.3. Draft Naming .......................................27
4.1.4. Writing Style ......................................28
4.1.5. How to Speed Up the Process ........................29
4.2. Other Standards Bodies ....................................29
4.3. Proprietary and Vendor Specific ...........................30
4.4. Joint Development of Media Coding Specification
and RTP Payload Format ....................................31
5. Designing Payload Formats ......................................31
5.1. Features of RTP Payload Formats ...........................32
5.1.1. Aggregation ........................................32
5.1.2. Fragmentation ......................................33
5.1.3. Interleaving and Transmission Rescheduling .........33
5.1.4. Media Back Channels ................................34
5.1.5. Media Scalability ..................................34
5.1.6. High Packet Rates ..................................37
5.2. Selecting Timestamp Definition ............................37
6. Noteworthy Aspects in Payload Format Design ....................39
6.1. Audio Payloads ............................................39
6.2. Video .....................................................40
6.3. Text ......................................................41
6.4. Application ...............................................41
7. Important Specification Sections ...............................42
7.1. Media Format Description ..................................42
7.2. Security Considerations ...................................43
7.3. Congestion Control ........................................44
7.4. IANA Considerations .......................................45
8. Authoring Tools ................................................45
8.1. Editing Tools .............................................46
8.2. Verification Tools ........................................46
9. Security Considerations ........................................47
10. Informative References ........................................47
Appendix A. RTP Payload Format Template ...........................58
A.1. Title .....................................................58
A.2. Front-Page Boilerplate ....................................58
A.3. Abstract ..................................................58
A.4. Table of Contents .........................................58
A.5. Introduction ..............................................59
A.6. Conventions, Definitions, and Abbreviations ...............59
A.7. Media Format Description ..................................59
A.8. Payload Format ............................................59
A.8.1. RTP Header Usage ......................................59
A.8.2. Payload Header ........................................59
A.8.3. Payload Data ..........................................60
A.9. Payload Examples ..........................................60
A.10. Congestion Control Considerations .........................60
A.11. Payload Format Parameters .................................60
A.11.1. Media Type Definition ................................60
A.11.2. Mapping to SDP .......................................62
A.12. IANA Considerations .......................................63
A.13. Security Considerations ...................................63
A.14. RFC Editor Considerations .................................64
A.15. References ................................................64
A.15.1. Normative References .................................64
A.15.2. Informative References ...............................64
A.16. Authors' Addresses ........................................64
Acknowledgements ..................................................64
Contributors ......................................................65
Author's Address ..................................................65
RTP [RFC3550] payload formats define how a specific real-time data format is structured in the payload of an RTP packet. A real-time data format without a payload format specification cannot be transported using RTP. This creates an interest in many individuals/ organizations with media encoders or other types of real-time data to define RTP payload formats. However, the specification of a well-designed RTP payload format is nontrivial and requires knowledge of both RTP and the real-time data format.
RTP [RFC3550]ペイロード形式は、RTPパケットのペイロードで特定のリアルタイムデータ形式がどのように構成されるかを定義します。ペイロード形式が指定されていないリアルタイムデータ形式は、RTPを使用して転送できません。これは、RTPペイロード形式を定義するためにメディアエンコーダーまたは他のタイプのリアルタイムデータを持つ多くの個人/組織に関心をもたらします。ただし、適切に設計されたRTPペイロード形式の仕様は重要であり、RTPとリアルタイムデータ形式の両方の知識が必要です。
This document is intended to help any author of an RTP payload format specification make important design decisions, consider important features of RTP and RTP security, etc. The document is also intended to be a good starting point for any person with little experience in the IETF and/or RTP to learn the necessary steps.
このドキュメントは、RTPペイロード形式仕様の作成者が重要な設計上の決定を行ったり、RTPおよびRTPセキュリティの重要な機能を検討したりするのに役立つことを目的としています。このドキュメントは、IETFの経験がほとんどない人にとっても良い出発点になることを目的としています。および/または必要な手順を学ぶRTP。
This document extends and updates the information that is available in "Guidelines for Writers of RTP Payload Format Specifications" [RFC2736]. Since that RFC was written, further experience has been gained on the design and specification of RTP payload formats. Several new RTP profiles and robustness tools have been defined, and these need to be considered.
このドキュメントは、「RTPペイロード形式仕様の作成者のためのガイドライン」[RFC2736]で入手可能な情報を拡張および更新します。そのRFCが作成されて以来、RTPペイロード形式の設計と仕様に関してさらなる経験が得られました。いくつかの新しいRTPプロファイルと堅牢性ツールが定義されており、これらを考慮する必要があります。
This document also discusses the possible venues for defining an RTP payload format: the IETF, other standards bodies, and proprietary ones.
このドキュメントでは、RTPペイロード形式を定義するための可能な場所についても説明します。IETF、その他の標準化団体、独自のものなどです。
Note, this document does discuss IETF, IANA, and RFC Editor processes and rules as they were when this document was published. This to make clear how the work to specify an RTP payload formats depends, uses, and interacts with these rules and processes. However, these rules and processes are subject to change and the formal rule and process specifications always takes precedence over what is written here.
このドキュメントでは、IETF、IANA、RFC Editorのプロセスとルールについて、このドキュメントの公開時と同じように説明しています。これは、RTPペイロード形式を指定する作業がこれらのルールとプロセスに依存し、使用し、相互作用する方法を明確にするためです。ただし、これらのルールとプロセスは変更される可能性があり、正式なルールとプロセスの仕様は常にここに記載されている内容よりも優先されます。
This document has several different parts discussing different aspects of the creation of an RTP payload format specification. Section 3 discusses the preparations the author(s) should make before starting to write a specification. Section 4 discusses the different processes used when specifying and completing a payload format, with focus on working inside the IETF. Section 5 discusses the design of payload formats themselves in detail. Section 6 discusses current design trends and provides good examples of practices that should be followed when applicable. Following that, Section 7 provides a discussion on important sections in the RTP payload format specification itself such as Security Considerations and IANA Considerations. This document ends with an appendix containing a template that can be used when writing RTP payload formats specifications.
このドキュメントには、RTPペイロード形式仕様の作成のさまざまな側面を説明するいくつかの異なる部分があります。セクション3では、仕様の作成を開始する前に作成者が行う準備について説明します。セクション4では、IETF内での作業に重点を置いて、ペイロード形式を指定および完了するときに使用されるさまざまなプロセスについて説明します。セクション5では、ペイロード形式自体の設計について詳しく説明します。セクション6では、現在の設計の傾向について説明し、該当する場合に従うべき実践の良い例を示します。その後、セクション7では、セキュリティに関する考慮事項やIANAに関する考慮事項など、RTPペイロード形式仕様自体の重要なセクションについて説明します。このドキュメントは、RTPペイロード形式の仕様を作成するときに使用できるテンプレートを含む付録で終わります。
RTP Stream: A sequence of RTP packets that together carry part or all of the content of a specific media (audio, video, text, or data whose form and meaning are defined by a specific real-time application) from a specific sender source within a given RTP session.
RTPストリーム：特定のメディア（オーディオ、ビデオ、テキスト、または形式と意味が特定のリアルタイムアプリケーションによって定義されるデータ、オーディオ、ビデオ、テキスト、またはデータ）のコンテンツの一部またはすべてを一緒に運ぶ一連のRTPパケット。特定のRTPセッション。
RTP Session: An association among a set of participants communicating with RTP. The distinguishing feature of an RTP session is that each session maintains a full, separate space of synchronization source (SSRC) identifiers. See also Section 3.3.1.
RTPセッション：RTPと通信する一連の参加者間の関連付け。 RTPセッションの際立った特徴は、各セッションが同期ソース（SSRC）識別子の完全な個別のスペースを維持することです。セクション3.3.1も参照してください。
RTP Payload Format: The RTP payload format specifies how units of a specific encoded media are put into the RTP packet payloads and how the fields of the RTP packet header are used, thus enabling the format to be used in RTP applications.
RTPペイロード形式：RTPペイロード形式は、特定のエンコードされたメディアのユニットがどのようにRTPパケットペイロードに入れられるか、およびRTPパケットヘッダーのフィールドがどのように使用されるかを指定します。
A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources [RFC7656] defines many useful terms.
リアルタイム転送プロトコル（RTP）ソースの意味論とメカニズムの分類[RFC7656]は、多くの有用な用語を定義しています。
ABNF: Augmented Backus-Naur Form [RFC5234]
ABNF：拡張バッカスナウアフォーム[RFC5234]
ADU: Application Data Unit
ADU：アプリケーションデータユニット
ALF: Application Level Framing
ALF：アプリケーションレベルのフレーミング
ASM: Any-Source Multicast
ASM：Any-Source Multicast
BCP: Best Current Practice
BCP：現在のベストプラクティス
I-D: Internet-Draft
I-D：インターネットドラフト
IESG: Internet Engineering Steering Group
IESG：Internet Engineering Steering Group
MTU: Maximum Transmission Unit
MTU：最大転送単位
WG: Working Group QoS: Quality of Service
WG：ワーキンググループQoS：サービス品質
RFC: Request For Comments
RFC：コメントのリクエスト
RTP: Real-time Transport Protocol
RTP：リアルタイム転送プロトコル
RTCP: RTP Control Protocol
RTCP：RTP制御プロトコル
RTT: Round-Trip Time
RTT：往復時間
SSM: Source-Specific Multicast
SSM：ソース固有のマルチキャスト
As this document is both Informational and instructional rather than a specification, this document does not use any RFC 2119 language and the use of "may", "should", "recommended", and "must" carries no special connotation.
このドキュメントは仕様ではなく情報と説明の両方であるため、このドキュメントではRFC 2119言語を使用せず、「may」、「should」、「recommended」、「must」の使用は特別な意味を持ちません。
RTP is a complex real-time media delivery framework, and it has a lot of details that need to be considered when writing an RTP payload format. It is also important to have a good understanding of the media codec / format so that all of its important features and properties are considered. Only when one has sufficient understanding of both parts can one produce an RTP payload format of high quality. On top of this, one needs to understand the process within the IETF and especially the Working Group responsible for standardizing payload formats (currently the PAYLOAD WG) to go quickly from the initial idea stage to a finished RFC. This and the next sections help an author prepare himself in those regards.
RTPは複雑なリアルタイムのメディア配信フレームワークであり、RTPペイロード形式を作成する際に考慮する必要のある多くの詳細があります。メディアコーデック/フォーマットを十分に理解して、そのすべての重要な機能とプロパティを考慮することも重要です。両方の部分を十分に理解している場合にのみ、高品質のRTPペイロード形式を生成できます。これに加えて、IETF内のプロセス、特にペイロード形式（現在はPAYLOAD WG）の標準化を担当するワーキンググループを理解して、初期のアイデア段階から完成したRFCにすばやく移行する必要があります。これと次のセクションは、著者がそれらの点で準備するのに役立ちます。
It may be obvious, but it is necessary for an author of an RTP payload specification to have a solid understanding of the media to be transported. Important are not only the specifically spelled out transport aspects (if any) in the media coding specification, but also core concepts of the underlying technology. For example, an RTP payload format for video coded with inter-picture prediction will perform poorly if the payload designer does not take the use of inter-picture prediction into account. On the other hand, some (mostly older) media codecs offer error-resilience tools against bit errors, which, when misapplied over RTP, in almost all cases would only introduce overhead with no measurable return.
当たり前かもしれませんが、RTPペイロード仕様の作成者は、転送されるメディアをしっかりと理解している必要があります。重要なのは、メディアコーディング仕様で具体的に記述されているトランスポートの側面（存在する場合）だけでなく、基盤となるテクノロジのコアコンセプトです。たとえば、ペイロードの設計者が画像間予測の使用を考慮に入れていない場合、画像間予測でコーディングされたビデオのRTPペイロード形式はパフォーマンスが低下します。一方、一部の（主に古い）メディアコーデックは、ビットエラーに対するエラー耐性ツールを提供します。RTPを誤って適用すると、ほとんどすべての場合、オーバーヘッドは測定可能なリターンなしで発生します。
The following subsections list a number of documents. Not all need to be read in full detail. However, an author basically needs to be aware of everything listed below.
以下のサブセクションには、いくつかのドキュメントがリストされています。すべてを詳細に読む必要はありません。ただし、作成者は基本的に以下にリストされているすべてに注意する必要があります。
Newcomers to the IETF are strongly recommended to read the "Tao of the IETF" [TAO] that goes through most things that one needs to know about the IETF: the history, organizational structure, how the WGs and meetings work, etc.
IETFの初心者は、IETFについて知る必要のあるほとんどの事柄（履歴、組織構造、WGや会議の仕組みなど）について説明する「IETFのタオ」[TAO]を読むことを強くお勧めします。
It is very important to note and understand the IETF Intellectual Property Rights (IPR) policy that requires early disclosures based on personal knowledge from anyone contributing in IETF. The IETF policies associated with IPR are documented in BCP 78 [BCP78] (related to copyright, including software copyright, for example, code) and BCP 79 [BCP79] (related to patent rights). These rules may be different from other standardization organizations. For example, a person that has a patent or a patent application that he or she reasonably and personally believes to cover a mechanism that gets added to the Internet-Draft they are contributing to (e.g., by submitting the draft, posting comments or suggestions on a mailing list, or speaking at a meeting) will need to make a timely IPR disclosure. Read the above documents for the authoritative rules. Failure to follow the IPR rules can have dire implications for the specification and the author(s) as discussed in [RFC6701].
IETFに貢献している人からの個人的な知識に基づいた早期の開示を要求するIETFの知的財産権（IPR）ポリシーに注意して理解することは非常に重要です。 IPRに関連するIETFポリシーは、BCP 78 [BCP78]（ソフトウェアの著作権などの著作権に関連するコード）およびBCP 79 [BCP79]（特許権に関連）に文書化されています。これらのルールは、他の標準化組織とは異なる場合があります。たとえば、自分が貢献しているインターネットドラフトに追加されるメカニズムをカバーすると合理的かつ個人的に確信している特許または特許出願を持っている人（たとえば、ドラフトを提出したり、コメントや提案を投稿したりすることによって）メーリングリスト、または会議での発言）は、適時のIPR開示を行う必要があります。信頼できるルールについては、上記のドキュメントをお読みください。 [RFC6701]で説明されているように、IPRルールに従わないと、仕様と作成者に重大な影響を与える可能性があります。
Note: These IPR rules apply on what is specified in the RTP payload format Internet-Draft (and later RFC); an IPR that relates to a codec specification from an external body does not require IETF IPR disclosure. Informative text explaining the nature of the codec would not normally require an IETF IPR declaration. Appropriate IPR declarations for the codec itself would normally be found in files of the external body defining the codec, in accordance with that external body's own IPR rules.
注：これらのIPRルールは、RTPペイロード形式Internet-Draft（およびそれ以降のRFC）で指定されているものに適用されます。外部機関からのコーデック仕様に関連するIPRは、IETF IPR開示を必要としません。コーデックの性質を説明する有益なテキストは、通常、IETF IPR宣言を必要としません。コーデック自体の適切なIPR宣言は、通常、コーデックを定義する外部本体のファイルに、その外部本体の独自のIPR規則に従って見つかります。
The main part of the IETF process is formally defined in BCP 9 [BCP9]. BCP 25 [BCP25] describes the WG process, the relation between the IESG and the WG, and the responsibilities of WG Chairs and participants.
IETFプロセスの主要部分は、BCP 9 [BCP9]で正式に定義されています。 BCP 25 [BCP25]は、WGプロセス、IESGとWGの関係、およびWGの議長と参加者の責任について説明しています。
It is important to note that the RFC Series contains documents of several different publication streams as defined by The RFC Series and RFC Editor [RFC4844]. The most important stream for RTP payload formats authors is the IETF Stream. In this stream, the work of the IETF is published. The stream contains documents of several different categories: Standards Track, Informational, Experimental, Best Current Practice, and Historic. "Standards Track" contains two maturity levels: Proposed Standard and Internet Standard [RFC6410]. A Standards Track document must start as a Proposed Standard; after successful deployment and operational experience with at least two implementations, it can be moved to an Internet Standard. The Independent Submission Stream could appear to be of interest as it provides a way of publishing documents of certain categories such as Experimental and Informational with a different review process. However, as long as IETF has a WG that is chartered to work on RTP payload formats, this stream should not be used.
RFCシリーズには、RFCシリーズおよびRFCエディター[RFC4844]で定義されているいくつかの異なる公開ストリームのドキュメントが含まれていることに注意することが重要です。 RTPペイロード形式の作成者にとって最も重要なストリームはIETFストリームです。このストリームでは、IETFの作業が公開されています。ストリームには、いくつかの異なるカテゴリのドキュメントが含まれています：標準トラック、情報、実験的、現在のベストプラクティス、および歴史的。 「Standards Track」には、Proposed StandardとInternet Standard [RFC6410]の2つの成熟度レベルが含まれています。 Standards TrackドキュメントはProposed Standardとして開始する必要があります。少なくとも2つの実装での展開と運用の経験が成功したら、インターネット標準に移行できます。 Independent Submission Streamは、ExperimentalやInformationalなどの特定のカテゴリのドキュメントを別のレビュープロセスで公開する方法を提供するため、興味があるように見えます。ただし、IETFにRTPペイロード形式で動作するようにチャーターされているWGがある限り、このストリームは使用しないでください。
As the content of a given RFC is not allowed to change once published, the only way to modify an RFC is to write and publish a new one that either updates or replaces the old one. Therefore, whether reading or referencing an RFC, it is important to consider both the Category field in the document header and to check if the RFC is the latest on the subject and still valid. One way of checking the current status of an RFC is to use the RFC Editor's RFC search page (https://www.rfc-editor.org/search), which displays the current status and which if any RFC has updated or obsoleted it. The RFC Editor search engine will also indicate if there exist any errata reports for the RFC. Any verified errata report contains issues of significant importance with the RFC; thus, they should be known prior to an update and replacement publication.
所定のRFCの内容は一度公開されると変更できないため、RFCを変更する唯一の方法は、古いものを更新または置き換える新しいものを作成して公開することです。したがって、RFCを読み取るか参照するかに関係なく、ドキュメントヘッダーの[Category]フィールドの両方を検討することと、RFCが主題に関して最新であり、まだ有効かどうかを確認することが重要です。 RFCの現在のステータスを確認する1つの方法は、RFCエディターのRFC検索ページ（https://www.rfc-editor.org/search）を使用することです。これは、現在のステータスを表示し、RFCが更新または廃止した場合。 RFCエディターの検索エンジンは、RFCのエラータレポートが存在するかどうかも示します。検証済みの正誤表レポートには、RFCで非常に重要な問題が含まれています。したがって、それらは更新および置換の発行の前に知っておく必要があります。
Before starting to write a draft, one should also read the Internet-Draft writing guidelines (http://www.ietf.org/ietf/1id-guidelines.txt), the I-D checklist (http://www.ietf.org/ID-Checklist.html), and the RFC Style Guide [RFC7322]. Another document that can be useful is "Guide for Internet Standards Writers" [RFC2360].
下書きの作成を始める前に、インターネットドラフト作成ガイドライン（http://www.ietf.org/ietf/1id-guidelines.txt)、IDチェックリスト（http://www.ietf.org）も読む必要があります。 /ID-Checklist.html）、およびRFCスタイルガイド[RFC7322]。役立つ可能性のある別のドキュメントは、「インターネット標準ライターのガイド」[RFC2360]です。
There are also a number of documents to consider in the process of writing drafts intended to become RFCs. These are important when writing certain types of text.
RFCになることを目的としたドラフトを作成するプロセスで検討する必要のあるドキュメントも多数あります。これらは、特定のタイプのテキストを書くときに重要です。
RFC 2606: When writing examples using DNS names in Internet-Drafts, those names shall be chosen from the example.com, example.net, and example.org domains.
RFC 2606：Internet-DraftでDNS名を使用して例を記述する場合、それらの名前はexample.com、example.net、example.orgドメインから選択されるものとします。
RFC 3849: Defines the range of IPv6 unicast addresses (2001:DB8::/32) that should be used in any examples.
RFC 3849：例で使用されるIPv6ユニキャストアドレスの範囲（2001：DB8 :: / 32）を定義します。
RFC 5737: Defines the ranges of IPv4 unicast addresses reserved for documentation and examples: 192.0.2.0/24, 198.51.100.0/24, and 203.0.113.0/24.
RFC 5737：ドキュメントと例のために予約されているIPv4ユニキャストアドレスの範囲を定義します：192.0.2.0/24、198.51.100.0/24、および203.0.113.0/24。
RFC 5234: Augmented Backus-Naur Form (ABNF) is often used when writing text field specifications. Not commonly used in RTP payload formats, but may be useful when defining media type parameters of some complexity.
RFC 5234：テキストフィールドの仕様を記述する場合は、拡張バッカスナウルフォーム（ABNF）がよく使用されます。 RTPペイロード形式では一般的に使用されませんが、複雑なメディアタイプパラメータを定義するときに役立つ場合があります。
The recommended reading for RTP consists of several different parts: design guidelines, the RTP protocol, profiles, robustness tools, and media-specific recommendations.
RTPの推奨資料は、設計ガイドライン、RTPプロトコル、プロファイル、堅牢性ツール、メディア固有の推奨事項など、いくつかの異なる部分で構成されています。
Any author of RTP payload formats should start by reading "Guidelines for Writers of RTP Payload Format Specifications" [RFC2736], which contains an introduction to the Application Level Framing (ALF) principle, the channel characteristics of IP channels, and design guidelines for RTP payload formats. The goal of ALF is to be able to transmit Application Data Units (ADUs) that are independently usable by the receiver in individual RTP packets, thus minimizing dependencies between RTP packets and the effects of packet loss.
RTPペイロード形式の作成者は、最初に「RTPペイロード形式仕様の作成者向けガイドライン」[RFC2736]を読む必要があります。これには、アプリケーションレベルフレーミング（ALF）の原理、IPチャネルのチャネル特性、およびRTPの設計ガイドラインが含まれています。ペイロード形式。 ALFの目的は、個々のRTPパケットで受信者が独立して使用できるアプリケーションデータユニット（ADU）を送信できるようにすることで、RTPパケット間の依存関係とパケット損失の影響を最小限に抑えます。
Then, it is advisable to learn more about the RTP protocol, by studying the RTP specification "RTP: A Transport Protocol for Real-Time Applications" [RFC3550] and the existing profiles. As a complement to the Standards Track documents, there exists a book totally dedicated to RTP [CSP-RTP]. There exist several profiles for RTP today, but all are based on "RTP Profile for Audio and Video Conferences with Minimal Control" [RFC3551] (abbreviated as RTP/AVP). The other profiles that one should know about are "The Secure Real-time Transport Protocol (SRTP)" (RTP/SAVP) [RFC3711], "Extended RTP Profile for RTCP-based Feedback (RTP/AVPF)" [RFC4585], and "Extended Secure Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)" [RFC5124]. It is important to understand RTP and the RTP/AVP profile in detail. For the other profiles, it is sufficient to have an understanding of what functionality they provide and the limitations they create.
次に、RTP仕様「RTP：リアルタイムアプリケーション用のトランスポートプロトコル」[RFC3550]と既存のプロファイルを研究することにより、RTPプロトコルの詳細を学ぶことをお勧めします。 Standards Trackドキュメントを補足するものとして、完全にRTP [CSP-RTP]に特化した本が存在します。現在、RTPにはいくつかのプロファイルが存在しますが、すべてが「Minimal Controlを使用したオーディオおよびビデオ会議のRTPプロファイル」[RFC3551]（略してRTP / AVP）に基づいています。他に知っておくべきプロファイルは、「Secure Real-time Transport Protocol（SRTP）」（RTP / SAVP）[RFC3711]、「RTCPベースのフィードバック用の拡張RTPプロファイル（RTP / AVPF）」[RFC4585]、そして「Extended Secure Real-time Transport Control Protocol（RTCP）-Based Feedback（RTP / SAVPF）」[RFC5124]。 RTPおよびRTP / AVPプロファイルを詳細に理解することが重要です。他のプロファイルについては、それらが提供する機能とそれらが作成する制限を理解することで十分です。
A number of robustness tools have been developed for RTP. The tools are for different use cases and real-time requirements.
RTP用に多くの堅牢性ツールが開発されています。これらのツールは、さまざまなユースケースとリアルタイム要件に対応しています。
RFC 2198: "RTP Payload for Redundant Audio Data" [RFC2198] provides functionalities to transmit redundant copies of audio or text payloads. These redundant copies are sent together with a primary format in the same RTP payload. This format relies on the RTP timestamp to determine where data belongs in a sequence; therefore, it is usually most suitable to be used with audio. However, the RTP Payload format for T.140 [RFC4103] text format also uses this format. The format's major property is that it only preserves the timestamp of the redundant payloads, not the original sequence number. This makes it unusable for most video formats. This format is also only suitable for media formats that produce relatively small RTP payloads.
RFC 2198：「冗長オーディオデータのRTPペイロード」[RFC2198]は、オーディオまたはテキストペイロードの冗長コピーを送信する機能を提供します。これらの冗長コピーは、同じRTPペイロードでプライマリフォーマットとともに送信されます。このフォーマットは、RTPタイムスタンプに基づいて、データがシーケンスのどこに属するかを決定します。したがって、通常はオーディオでの使用に最適です。ただし、T.140 [RFC4103]テキスト形式のRTPペイロード形式もこの形式を使用します。このフォーマットの主な特性は、元のシーケンス番号ではなく、冗長ペイロードのタイムスタンプのみを保持することです。これにより、ほとんどのビデオ形式で使用できなくなります。このフォーマットは、比較的小さなRTPペイロードを生成するメディアフォーマットにも適しています。
RFC 6354: The "Forward-Shifted RTP Redundancy Payload Support" [RFC6354] is a variant of RFC 2198 that allows the redundant data to be transmitted prior to the original.
RFC 6354：「Forward-Shifted RTP Redundancy Payload Support」[RFC6354]は、RFC 2198のバリアントであり、元のデータの前に冗長データを送信できます。
RFC 5109: The "RTP Payload Format for Generic Forward Error Correction" [RFC5109] provides an XOR-based Forward Error Correction (FEC) of the whole or parts of a number of RTP packets. This specification replaced the previous specification for XOR-based FEC [RFC2733]. These FEC packets are sent in a separate stream or as a redundant encoding using RFC 2198. This FEC scheme has certain restrictions in the number of packets it can protect. It is suitable for applications with low-to-medium delay tolerance with a limited amount of RTP packets.
RFC 5109：「Generic Forward Error CorrectionのRTPペイロードフォーマット」[RFC5109]は、多数のRTPパケットの全体または一部のXORベースのForward Error Correction（FEC）を提供します。この仕様は、XORベースのFEC [RFC2733]の以前の仕様を置き換えました。これらのFECパケットは、別のストリームで送信されるか、RFC 2198を使用して冗長エンコーディングとして送信されます。このFECスキームには、保護できるパケット数に特定の制限があります。これは、RTPパケットの量が限られている、低から中程度の遅延許容度を持つアプリケーションに適しています。
RFC 6015: "RTP Payload Format for 1-D Interleaved Parity Forward Error Correction (FEC)" [RFC6015] provides a variant of the XOR-based Generic protection defined in [RFC2733]. The main difference is to use interleaving scheme on which packets gets included as source packets for a particular protection packet. The interleaving is defined by using every L packets as source data and then producing protection data over D number of packets. Thus, each block of D x L source packets will result in L number of Repair packets, each capable of repairing one loss. The goal is to provide better burst-error robustness when the packet rate is higher.
RFC 6015：「1-D Interleaved Parity Forward Error Correction（FEC）のRTPペイロード形式」[RFC6015]は、[RFC2733]で定義されているXORベースのGeneric保護のバリアントを提供します。主な違いは、特定の保護パケットのソースパケットとしてパケットが含まれるインターリービングスキームを使用することです。インターリーブは、すべてのLパケットをソースデータとして使用し、Dのパケット数で保護データを生成することによって定義されます。したがって、D x Lソースパケットの各ブロックは、それぞれが1つの損失を修復できるL個の修復パケットになります。目標は、パケットレートが高い場合に、バーストエラーの堅牢性を向上させることです。
FEC Framework: "Forward Error Correction (FEC) Framework" [RFC6363] defines how to use FEC protection for arbitrary packet flows. This framework can be applied for RTP/RTCP packet flows, including using RTP for transmission of repair symbols, an example is in "RTP Payload Format for Raptor Forward Error Correction (FEC)" [RFC6682].
FECフレームワーク：「Forward Error Correction（FEC）Framework」[RFC6363]は、任意のパケットフローに対してFEC保護を使用する方法を定義します。このフレームワークは、RTP / RTCPパケットフローに適用できます。これには、RTPを使用した修復シンボルの送信が含まれます。例は、「RTPペイロード形式のRaptor前方誤り訂正（FEC）」[RFC6682]です。
RTP Retransmission: The RTP retransmission scheme [RFC4588] is used for semi-reliability of the most important RTP packets in a RTP stream. The level of reliability between semi- and in-practice full reliability depends on the targeted properties and situation where parameters such as round-trip time (RTT) allowed additional overhead and allowable delay. It often requires the application to be quite delay tolerant as a minimum of one round-trip time plus processing delay is required to perform a retransmission. Thus, it is mostly suitable for streaming applications but may also be usable in certain other cases when operating in networks with short round-trip times.
RTP再送信：RTP再送信スキーム[RFC4588]は、RTPストリーム内の最も重要なRTPパケットの半信頼性のために使用されます。半信頼性と実際の完全信頼性の間の信頼性のレベルは、対象のプロパティと、ラウンドトリップ時間（RTT）などのパラメーターが追加のオーバーヘッドと許容遅延を許可する状況に依存します。再送信を実行するには、最低1回のラウンドトリップ時間に加えて処理遅延が必要であるため、多くの場合、アプリケーションは非常に遅延に強い必要があります。したがって、ストリーミングアプリケーションに最も適していますが、往復時間が短いネットワークで動作している場合、他の特定のケースでも使用できます。
RTP over TCP: RFC 4571 [RFC4571] defines how one sends RTP and RTCP packets over connection-oriented transports like TCP. If one uses TCP, one gets reliability for all packets but loses some of the real-time behavior that RTP was designed to provide. Issues with TCP transport of real-time media include head-of-line blocking and wasting resources on retransmission of data that is already late. TCP is also limited to point-to-point connections, which further restricts its applicability.
RTP over TCP：RFC 4571 [RFC4571]は、TCPなどのコネクション型トランスポートを介してRTPパケットとRTCPパケットを送信する方法を定義しています。 TCPを使用すると、すべてのパケットの信頼性が得られますが、RTPが提供するように設計されたリアルタイムの動作の一部が失われます。リアルタイムメディアのTCPトランスポートに関する問題には、ヘッドオブラインブロッキングと、すでに遅れているデータの再送信によるリソースの浪費が含まれます。また、TCPはポイントツーポイント接続に限定されているため、その適用範囲はさらに制限されます。
There have been both discussion and design of RTP payload formats, e.g., Adaptive Multi-Rate (AMR) and AMR Wideband (AMR-WB) [RFC4867], supporting the unequal error detection provided by UDP-Lite [RFC3828]. The idea is that by not having a checksum over part of the RTP payload one can allow bit errors from the lower layers. By allowing bit errors one can increase the efficiency of some link layers and also avoid unnecessary discarding of data when the payload and media codec can get at least some benefit from the data. The main issue is that one has no idea of the level of bit errors present in the unprotected part of the payload. This makes it hard or impossible to determine whether or not one can design something usable. Payload format designers are not recommended to consider features for unequal error detection using UDP-Lite unless very clear requirements exist.
UDP-Lite [RFC3828]によって提供される不均等なエラー検出をサポートする、RTPペイロード形式、たとえばアダプティブマルチレート（AMR）やAMRワイドバンド（AMR-WB）[RFC4867]の議論と設計の両方がありました。 RTPペイロードの一部にチェックサムを持たないことにより、下位層からのビットエラーを許容できるという考え方です。ビットエラーを許可することで、一部のリンクレイヤーの効率を向上させ、ペイロードとメディアコーデックがデータから少なくともある程度の利益を得ることができる場合に、データの不要な破棄を回避できます。主な問題は、ペイロードの保護されていない部分に存在するビットエラーのレベルがわからないことです。これにより、使いやすいものを設計できるかどうかを判断することが困難または不可能になります。ペイロード形式の設計者は、非常に明確な要件がない限り、UDP-Liteを使用して不平等なエラーを検出する機能を検討することはお勧めしません。
There also exist some management and monitoring extensions.
管理と監視の拡張機能もいくつかあります。
RFC 2959: The RTP protocol Management Information Database (MIB) [RFC2959] that is used with SNMP [RFC3410] to configure and retrieve information about RTP sessions.
RFC 2959：RTPセッションに関する情報を構成および取得するためにSNMP [RFC3410]で使用されるRTPプロトコル管理情報データベース（MIB）[RFC2959]。
RFC 3611: The RTCP Extended Reports (RTCP XR) [RFC3611] consists of a framework for reports sent within RTCP. It can easily be extended by defining new report formats, which has and is occurring. The XRBLOCK WG in the IETF is chartered (at the time of writing) with defining new report formats. The list of specified formats is available in IANA's RTCP XR Block Type registry (http://www.iana.org/assignments/rtcp-xr-block-types/). The report formats that are defined in RFC 3611 provide report information on packet loss, packet duplication, packet reception times, RTCP statistics summary, and VoIP Quality. [RFC3611] also defines a mechanism that allows receivers to calculate the RTT to other session participants when used.
RFC 3611：RTCP拡張レポート（RTCP XR）[RFC3611]は、RTCP内で送信されるレポートのフレームワークで構成されています。新しいレポート形式を定義することにより、簡単に拡張できます。 IETFのXRBLOCK WGは（執筆時点で）新しいレポート形式を定義してチャーターされています。指定されたフォーマットのリストは、IANAのRTCP XRブロックタイプレジストリ（http://www.iana.org/assignments/rtcp-xr-block-types/）で入手できます。 RFC 3611で定義されているレポート形式は、パケット損失、パケットの重複、パケット受信時間、RTCP統計の要約、VoIP品質に関するレポート情報を提供します。 [RFC3611]は、受信者が使用時に他のセッション参加者へのRTTを計算できるようにするメカニズムも定義しています。
RMONMIB: The Remote Network Monitoring WG has defined a mechanism [RFC3577] based on usage of the MIB that can be an alternative to RTCP XR.
RMONMIB：リモートネットワーク監視WGは、RTCP XRの代替となるMIBの使用に基づいたメカニズム[RFC3577]を定義しています。
A number of transport optimizations have also been developed for use in certain environments. They are all intended to be transparent and do not require special consideration by the RTP payload format writer. Thus, they are primarily listed here for informational reasons.
特定の環境で使用するために、多くのトランスポート最適化も開発されています。これらはすべて透過的であることを意図しており、RTPペイロード形式ライターによる特別な考慮を必要としません。したがって、これらは主に情報上の理由でここにリストされています。
RFC 2508: "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links" (CRTP) [RFC2508] is the first IETF-developed RTP header compression mechanism. It provides quite good compression; however, it has clear performance problems when subject to packet loss or reordering between compressor and decompressor.
RFC 2508：「低速シリアルリンク用のIP / UDP / RTPヘッダーの圧縮」（CRTP）[RFC2508]は、IETFが開発した最初のRTPヘッダー圧縮メカニズムです。それはかなり良い圧縮を提供します。ただし、パケットの損失や、コンプレッサーとデコンプレッサー間の並べ替えの影響を受けると、明らかにパフォーマンスの問題があります。
RFCs 3095 and 5795: These are the base specifications of the robust header compression (ROHC) protocol version 1 [RFC3095] and version 2 [RFC5795]. This solution was created as a result of CRTP's lack of performance when compressed packets are subject to loss.
RFC 3095および5795：これらは、堅牢なヘッダー圧縮（ROHC）プロトコルバージョン1 [RFC3095]およびバージョン2 [RFC5795]の基本仕様です。このソリューションは、圧縮されたパケットが失われる場合のCRTPのパフォーマンスの欠如の結果として作成されました。
RFC 3545: Enhanced compressed RTP (E-CRTP) [RFC3545] was developed to provide extensions to CRTP that allow for better performance over links with long RTTs, packet loss, and/or reordering.
RFC 3545：拡張圧縮RTP（E-CRTP）[RFC3545]は、長いRTT、パケット損失、および/または並べ替えを伴うリンクでのパフォーマンスを向上させるCRTPへの拡張を提供するために開発されました。
RFC 4170: "Tunneling Multiplexed Compressed RTP (TCRTP)" [RFC4170] is a solution that allows header compression within a tunnel carrying multiple multiplexed RTP flows. This is primarily used in voice trunking.
RFC 4170：「Tunneling Multiplexed Compressed RTP（TCRTP）」[RFC4170]は、複数の多重化されたRTPフローを運ぶトンネル内のヘッダー圧縮を可能にするソリューションです。これは主に音声トランキングで使用されます。
There exist a couple of different security mechanisms that may be used with RTP. By definition, generic mechanisms are transparent for the RTP payload format and do not need special consideration by the format designer. The main reason that different solutions exist is that different applications have different requirements; thus, different solutions have been developed. For more discussion on this, please see "Options for Securing RTP Sessions" [RFC7201] and "Securing the RTP Framework: Why RTP Does Not Mandate a Single Media Security Solution" [RFC7202]. The main properties for an RTP security mechanism are to provide confidentiality for the RTP payload, integrity protection to detect manipulation of payload and headers, and source authentication. Not all mechanisms provide all of these features, a point that will need to be considered when a specific mechanisms is chosen.
RTPで使用できるいくつかの異なるセキュリティメカニズムが存在します。定義により、汎用メカニズムはRTPペイロード形式に対して透過的であり、形式設計者による特別な考慮は必要ありません。ソリューションが異なる主な理由は、アプリケーションごとに要件が異なるためです。したがって、さまざまなソリューションが開発されています。この詳細については、「RTPセッションを保護するためのオプション」[RFC7201]および「RTPフレームワークの保護：RTPが単一のメディアセキュリティソリューションを義務付けない理由」[RFC7202]を参照してください。 RTPセキュリティメカニズムの主な特性は、RTPペイロードの機密性、ペイロードとヘッダーの操作を検出するための整合性保護、およびソース認証を提供することです。すべてのメカニズムがこれらの機能のすべてを提供するわけではありません。特定のメカニズムを選択するときに考慮する必要があるポイントです。
The profile for Secure RTP - SRTP (RTP/SAVP) [RFC3711] and the derived profile (RTP/SAVPF [RFC5124]) are a solution that enables confidentiality, integrity protection, replay protection, and partial source authentication. It is the solution most commonly used with RTP at the time of writing this document. There exist several key-management solutions for SRTP, as well other choices, affecting the security properties. For a more in-depth review of the options and solutions other than SRTP consult "Options for Securing RTP Sessions" [RFC7201].
Secure RTP-SRTP（RTP / SAVP）[RFC3711]のプロファイルと派生プロファイル（RTP / SAVPF [RFC5124]）は、機密性、完全性保護、再生保護、および部分的なソース認証を可能にするソリューションです。これは、このドキュメントの執筆時点でRTPと共に最も一般的に使用されているソリューションです。 SRTPには、セキュリティプロパティに影響を与える他の選択肢と同様に、いくつかのキー管理ソリューションがあります。 SRTP以外のオプションとソリューションの詳細については、「RTPセッションを保護するためのオプション」[RFC7201]を参照してください。
This section reviews a number of RTP features and concepts that are available in RTP, independent of the payload format. The RTP payload format can make use of these when appropriate, and even affect the behavior (RTP timestamp and marker bit), but it is important to note that not all features and concepts are relevant to every payload format. This section does not remove the necessity to read up on RTP. However, it does point out a few important details to remember when designing a payload format.
このセクションでは、ペイロードの形式に関係なく、RTPで使用できる多くのRTP機能と概念を確認します。 RTPペイロード形式は、適切な場合にこれらを利用でき、動作（RTPタイムスタンプとマーカービット）にも影響しますが、すべての機能と概念がすべてのペイロード形式に関連しているわけではないことに注意することが重要です。このセクションでは、RTPを読む必要はありません。ただし、ペイロード形式を設計するときに覚えておくべきいくつかの重要な詳細を指摘しています。
The definition of the RTP session from RFC 3550 is:
RFC 3550からのRTPセッションの定義は次のとおりです。
An association among a set of participants communicating with RTP. A participant may be involved in multiple RTP sessions at the same time. In a multimedia session, each medium is typically carried in a separate RTP session with its own RTCP packets unless the encoding itself multiplexes multiple media into a single data stream. A participant distinguishes multiple RTP sessions by reception of different sessions using different pairs of destination transport addresses, where a pair of transport addresses comprises one network address plus a pair of ports for RTP and RTCP. All participants in an RTP session may share a common destination transport address pair, as in the case of IP multicast, or the pairs may be different for each participant, as in the case of individual unicast network addresses and port pairs. In the unicast case, a participant may receive from all other participants in the session using the same pair of ports, or may use a distinct pair of ports for each.
RTPと通信する一連の参加者間の関連付け。参加者は、複数のRTPセッションに同時に関与する場合があります。マルチメディアセッションでは、エンコード自体が複数のメディアを単一のデータストリームに多重化しない限り、各メディアは通常、独自のRTCPパケットを使用して個別のRTPセッションで伝送されます。参加者は、宛先トランスポートアドレスの異なるペアを使用して異なるセッションを受信することにより、複数のRTPセッションを区別します。トランスポートアドレスのペアは、1つのネットワークアドレスとRTPおよびRTCPのポートのペアで構成されます。 RTPセッションのすべての参加者は、IPマルチキャストの場合のように、共通の宛先トランスポートアドレスのペアを共有するか、個々のユニキャストネットワークアドレスとポートのペアの場合のように、参加者ごとにペアが異なる場合があります。ユニキャストの場合、参加者は同じペアのポートを使用してセッションの他のすべての参加者から受信するか、それぞれに異なるペアのポートを使用します。
The distinguishing feature of an RTP session is that each session maintains a full, separate space of SSRC identifiers (defined next). The set of participants included in one RTP session consists of those that can receive an SSRC identifier transmitted by any one of the participants either in RTP as the SSRC or a CSRC (also defined below) or in RTCP. For example, consider a three-party conference implemented using unicast UDP with each participant receiving from the other two on separate port pairs. If each participant sends RTCP feedback about data received from one other participant only back to that participant, then the conference is composed of three separate point-to-point RTP sessions. If each participant provides RTCP feedback about its reception of one other participant to both of the other participants, then the conference is composed of one multi-party RTP session. The latter case simulates the behavior that would occur with IP multicast communication among the three participants.
RTPセッションの際立った特徴は、各セッションがSSRC識別子（次に定義）の完全な個別のスペースを維持することです。 1つのRTPセッションに含まれる参加者のセットは、参加者のいずれかが送信したSSRC識別子をRTPでSSRCまたはCSRC（以下でも定義）またはRTCPで受信できる参加者で構成されます。たとえば、各参加者が別のポートペアで他の2つから受信するユニキャストUDPを使用して実装された3者間会議について考えてみます。各参加者が他の1人の参加者から受信したデータに関するRTCPフィードバックをその参加者にのみ送信する場合、会議は3つの個別のポイントツーポイントRTPセッションで構成されます。各参加者が他の1人の参加者の受信に関するRTCPフィードバックを他の参加者の両方に提供する場合、会議は1つのマルチパーティRTPセッションで構成されます。後者のケースは、3人の参加者間のIPマルチキャスト通信で発生する動作をシミュレートします。
The RTP framework allows the variations defined here, but a particular control protocol or application design will usually impose constraints on these variations.
RTPフレームワークはここで定義されたバリエーションを許可しますが、特定の制御プロトコルまたはアプリケーション設計は通常これらのバリエーションに制約を課します。
The RTP header contains a number of fields. Two fields always require additional specification by the RTP payload format, namely the RTP timestamp and the marker bit. Certain RTP payload formats also use the RTP sequence number to realize certain functionalities, primarily related to the order of their application data units. The payload type is used to indicate the used payload format. The SSRC is used to distinguish RTP packets from multiple senders and media sources identifying the RTP stream. Finally, [RFC5285] specifies how to transport payload format independent metadata relating to the RTP packet or stream.
RTPヘッダーには、いくつかのフィールドが含まれています。 2つのフィールドには、RTPペイロード形式による追加の指定が常に必要です。つまり、RTPタイムスタンプとマーカービットです。特定のRTPペイロード形式もRTPシーケンス番号を使用して、主にアプリケーションデータユニットの順序に関連する特定の機能を実現します。ペイロードタイプは、使用されるペイロード形式を示すために使用されます。 SSRCは、RTPストリームを識別する複数の送信者およびメディアソースからRTPパケットを区別するために使用されます。最後に、[RFC5285]は、RTPパケットまたはストリームに関連するペイロード形式に依存しないメタデータを転送する方法を指定します。
Marker Bit: A single bit normally used to provide important indications. In audio, it is normally used to indicate the start of a talk burst. This enables jitter buffer adaptation prior to the beginning of the burst with minimal audio quality impact. In video, the marker bit is normally used to indicate the last packet part of a frame. This enables a decoder to finish decoding the picture, where it otherwise may need to wait for the next packet to explicitly know that the frame is finished.
マーカービット：重要な指標を提供するために通常使用される単一ビット。オーディオでは通常、トークバーストの開始を示すために使用されます。これにより、バーストの開始前にジッターバッファを適応させ、オーディオ品質への影響を最小限に抑えることができます。ビデオでは、マーカービットは通常、フレームの最後のパケット部分を示すために使用されます。これにより、デコーダーは画像のデコードを完了することができます。そうでなければ、フレームが終了したことを次のパケットが明示的に知るのを待つ必要がある場合があります。
Timestamp: The RTP timestamp indicates the time instance the media sample belongs to. For discrete media like video, it normally indicates when the media (frame) was sampled. For continuous media, it normally indicates the first time instance the media present in the payload represents. For audio, this is the sampling time of the first sample. All RTP payload formats must specify the meaning of the timestamp value and the clock rates allowed. Selecting a timestamp rate is an active design choice and is further discussed in Section 5.2.
タイムスタンプ：RTPタイムスタンプは、メディアサンプルが属するタイムインスタンスを示します。ビデオなどの個別のメディアの場合、通常はメディア（フレーム）がいつサンプリングされたかを示します。連続メディアの場合、通常、ペイロードに存在するメディアが表す最初のインスタンスを示します。オーディオの場合、これは最初のサンプルのサンプリング時間です。すべてのRTPペイロード形式は、タイムスタンプ値の意味と許可されるクロックレートを指定する必要があります。タイムスタンプレートの選択はアクティブな設計上の選択であり、セクション5.2でさらに説明します。
Discontinuous Transmission (DTX) that is common among speech codecs, typically results in gaps or jumps in the timestamp values due to that there is no media payload to transmit and the next used timestamp value represent the actual sampling time of the data transmitted.
音声コーデックに共通の不連続送信（DTX）では、送信するメディアペイロードがなく、次に使用されるタイムスタンプ値が送信されるデータの実際のサンプリング時間を表すため、通常はタイムスタンプ値にギャップまたはジャンプが生じます。
Sequence Number: The sequence number is monotonically increasing and is set as the packet is sent. This property is used in many payload formats to recover the order of everything from the whole stream down to fragments of application data units (ADUs) and the order they need to be decoded. Discontinuous transmissions do not result in gaps in the sequence number, as it is monotonically increasing for each sent RTP packet.
シーケンス番号：シーケンス番号は単調に増加し、パケットの送信時に設定されます。このプロパティは多くのペイロード形式で使用され、ストリーム全体からアプリケーションデータユニット（ADU）のフラグメントまでのすべての順序と、それらをデコードする必要がある順序を復元します。不連続な送信は、送信された各RTPパケットに対して単調に増加するため、シーケンス番号にギャップが発生することはありません。
Payload Type: The payload type is used to indicate, on a per-packet basis, which format is used. The binding between a payload type number and a payload format and its configuration are dynamically bound and RTP session specific. The configuration information can be bound to a payload type value by out-of-band signaling (Section 3.4). An example of this would be video decoder configuration information. Commonly, the same payload type is used for a media stream for the whole duration of a session. However, in some cases it may be necessary to change the payload format or its configuration during the session.
ペイロードタイプ：ペイロードタイプは、使用される形式をパケットごとに示すために使用されます。ペイロードタイプ番号とペイロードフォーマット間のバインディングとその設定は、動的にバインドされ、RTPセッション固有です。構成情報は、帯域外シグナリング（セクション3.4）によってペイロードタイプ値にバインドできます。この例は、ビデオデコーダの構成情報です。一般に、セッションの全期間中、メディアストリームには同じペイロードタイプが使用されます。ただし、場合によっては、セッション中にペイロード形式またはその構成を変更する必要があります。
SSRC: The synchronization source (SSRC) identifier is normally not used by a payload format other than to identify the RTP timestamp and sequence number space a packet belongs to, allowing simultaneously reception of multiple media sources. However, some of the RTP mechanisms for improving resilience to packet loss uses multiple SSRCs to separate original data and repair or redundant data, as well as multi-stream transmission of scalable codecs.
SSRC：同期ソース（SSRC）識別子は通常、パケットが属するRTPタイムスタンプとシーケンス番号スペースを識別する以外のペイロード形式では使用されないため、複数のメディアソースを同時に受信できます。ただし、パケット損失に対する耐性を向上させるための一部のRTPメカニズムは、複数のSSRCを使用して、元のデータを分離し、冗長データや、スケーラブルなコーデックのマルチストリーム伝送を修復します。
Header Extensions: RTP payload formats often need to include metadata relating to the payload data being transported. Such metadata is sent as a payload header, at the start of the payload section of the RTP packet. The RTP packet also includes space for a header extension [RFC5285]; this can be used to transport payload format independent metadata, for example, an SMPTE time code for the packet [RFC5484]. The RTP header extensions are not intended to carry headers that relate to a particular payload format, and must not contain information needed in order to decode the payload.
ヘッダー拡張：RTPペイロード形式には、転送されるペイロードデータに関連するメタデータを含める必要があることがよくあります。このようなメタデータは、RTPパケットのペイロードセクションの先頭にあるペイロードヘッダーとして送信されます。 RTPパケットには、ヘッダー拡張[RFC5285]のスペースも含まれます。これは、ペイロード形式に依存しないメタデータ、たとえば、パケットのSMPTEタイムコード[RFC5484]を転送するために使用できます。 RTPヘッダー拡張は、特定のペイロード形式に関連するヘッダーを運ぶことを意図しておらず、ペイロードをデコードするために必要な情報を含んではなりません。
The remaining fields do not commonly influence the RTP payload format. The padding bit is worth clarifying as it indicates that one or more bytes are appended after the RTP payload. This padding must be removed by a receiver before payload format processing can occur. Thus, it is completely separate from any padding that may occur within the payload format itself.
残りのフィールドは、一般的にRTPペイロード形式に影響を与えません。パディングビットは、RTPペイロードの後に1バイト以上が追加されることを示しているため、明確にする価値があります。このパディングは、ペイロード形式の処理が行われる前に、レシーバによって削除される必要があります。したがって、ペイロード形式自体の中で発生する可能性のあるパディングとは完全に分離されています。
RTP has three multiplexing points that are used for different purposes. A proper understanding of this is important to correctly use them.
RTPには、さまざまな目的で使用される3つの多重化ポイントがあります。これを正しく理解することは、それらを正しく使用するために重要です。
The first one is separation of RTP streams of different types or usages, which is accomplished using different RTP sessions. So, for example, in the common multimedia session with audio and video, RTP commonly multiplexes audio and video in different RTP sessions. To achieve this separation, transport-level functionalities are used, normally UDP port numbers. Different RTP sessions can also be used to realize layered scalability as it allows a receiver to select one or more layers for multicast RTP sessions simply by joining the multicast groups over which the desired layers are transported. This separation also allows different Quality of Service (QoS) to be applied to different media types. Use of multiple transport flows has potential issues due to NAT and firewall traversal. The choices how one applies RTP sessions as well as transport flows can affect the transport properties an RTP media stream experiences.
1つ目は、さまざまなタイプまたは使用法のRTPストリームの分離です。これは、さまざまなRTPセッションを使用して実現されます。したがって、たとえば、オーディオとビデオを使用する一般的なマルチメディアセッションでは、RTPは通常、オーディオとビデオを異なるRTPセッションで多重化します。この分離を実現するために、トランスポートレベルの機能（通常はUDPポート番号）が使用されます。さまざまなRTPセッションを使用して、階層化されたスケーラビリティを実現することもできます。これにより、受信者は、目的のレイヤーが転送されるマルチキャストグループに参加するだけで、マルチキャストRTPセッションの1つ以上のレイヤーを選択できます。この分離により、異なるメディアタイプに異なるサービス品質（QoS）を適用することもできます。複数のトランスポートフローを使用すると、NATとファイアウォールトラバーサルが原因で問題が発生する可能性があります。 RTPセッションとトランスポートフローをどのように適用するかの選択は、RTPメディアストリームが経験するトランスポートプロパティに影響を与える可能性があります。
The next multiplexing point is separation of different RTP streams within an RTP session. Here, RTP uses the SSRC to identify individual sources of RTP streams. An example of individual media sources would be the capture of different microphones that are carried in an RTP session for audio, independently of whether they are connected to the same host or different hosts. There also exist cases where a single media source, is transmitted using multiple RTP streams. For each SSRC, a unique RTP sequence number and timestamp space is used.
次の多重化ポイントは、RTPセッション内のさまざまなRTPストリームの分離です。ここでは、RTPはSSRCを使用してRTPストリームの個々のソースを識別します。個々のメディアソースの例は、同じホストに接続されているか、異なるホストに接続されているかに関係なく、オーディオ用のRTPセッションで伝送される異なるマイクのキャプチャです。単一のメディアソースが複数のRTPストリームを使用して送信される場合もあります。 SSRCごとに、一意のRTPシーケンス番号とタイムスタンプスペースが使用されます。
The third multiplexing point is the RTP header payload type field. The payload type identifies what format the content in the RTP payload has. This includes different payload format configurations, different codecs, and also usage of robustness mechanisms like the one described in RFC 2198 [RFC2198].
3番目の多重化ポイントは、RTPヘッダーのペイロードタイプフィールドです。ペイロードタイプは、RTPペイロードのコンテンツの形式を識別します。これには、さまざまなペイロード形式の構成、さまざまなコーデック、およびRFC 2198 [RFC2198]で説明されているような堅牢性メカニズムの使用法が含まれます。
There are several types of synchronization, and we will here describe how RTP handles the different types:
同期にはいくつかのタイプがあります。ここでは、RTPがさまざまなタイプを処理する方法について説明します。
Intra media: The synchronization within a media stream from a synchronization source (SSRC) is accomplished using the RTP timestamp field. Each RTP packet carries the RTP timestamp, which specifies the position in time of the media payload contained in this packet relative to the content of other RTP packets in the same RTP stream (i.e., a given SSRC). This is especially useful in cases of discontinuous transmissions. Discontinuities can be caused by network conditions; when extensive losses occur the RTP timestamp tells the receiver how much later than previously received media the present media should be played out.
イントラメディア：同期ソース（SSRC）からのメディアストリーム内の同期は、RTPタイムスタンプフィールドを使用して行われます。各RTPパケットは、RTPタイムスタンプを伝達します。RTPタイムスタンプは、同じRTPストリーム（つまり、特定のSSRC）内の他のRTPパケットのコンテンツに対するこのパケットに含まれるメディアペイロードの時間的位置を指定します。これは、不連続な送信の場合に特に役立ちます。不連続はネットワークの状態によって引き起こされる可能性があります。大規模な損失が発生した場合、RTPタイムスタンプは、以前に受信したメディアよりも現在のメディアを再生する必要がある時間をレシーバーに通知します。
Inter-media: Applications commonly have a desire to use several media sources, possibly of different media types, at the same time. Thus, there exists a need to synchronize different media from the same endpoint. This puts two requirements on RTP: the possibility to determine which media are from the same endpoint and if they should be synchronized with each other and the functionality to facilitate the synchronization itself.
インターメディア：アプリケーションは、通常、複数のメディアソースを使用する可能性があり、メディアタイプが異なる可能性があります。したがって、同じエンドポイントの異なるメディアを同期する必要があります。これは、RTPに2つの要件を課します。どのメディアが同じエンドポイントからのものであるかを判断する可能性、それらを互いに同期する必要があるかどうか、および同期自体を容易にする機能です。
The first step in inter-media synchronization is to determine which SSRCs in each session should be synchronized with each other. This is accomplished by comparing the CNAME fields in the RTCP source description (SDES) packets. SSRCs with the same CNAME sent in any of multiple RTP sessions can be synchronized.
メディア間同期の最初のステップは、各セッションのどのSSRCを互いに同期させるかを決定することです。これは、RTCPソース記述（SDES）パケットのCNAMEフィールドを比較することで実現されます。複数のRTPセッションのいずれかで送信された同じCNAMEを持つSSRCを同期できます。
The actual RTCP mechanism for inter-media synchronization is based on the idea that each RTP stream provides a position on the media specific time line (measured in RTP timestamp ticks) and a common reference time line. The common reference time line is expressed in RTCP as a wall-clock time in the Network Time Protocol (NTP) format. It is important to notice that the wall-clock time is not required to be synchronized between hosts, for example, by using NTP [RFC5905]. It can even have nothing at all to do with the actual time; for example, the host system's up-time can be used for this purpose. The important factor is that all media streams from a particular source that are being synchronized use the same reference clock to derive their relative RTP timestamp time scales. The type of reference clock and its timebase can be signaled using RTP Clock Source Signaling [RFC7273].
メディア間同期の実際のRTCPメカニズムは、各RTPストリームがメディア固有のタイムライン（RTPタイムスタンプのティックで測定）および共通の基準タイムライン上の位置を提供するという考えに基づいています。共通の基準タイムラインは、RTCPではネットワークタイムプロトコル（NTP）形式の実時間として表現されます。たとえば、NTP [RFC5905]を使用するなど、ホスト間で壁時計時刻を同期する必要がないことに注意することが重要です。実際の時間とは何の関係もありません。たとえば、ホストシステムのアップタイムをこの目的に使用できます。重要な要素は、同期されている特定のソースからのすべてのメディアストリームが同じ基準クロックを使用して、相対RTPタイムスタンプタイムスケールを導出することです。基準クロックのタイプとそのタイムベースは、RTP Clock Source Signaling [RFC7273]を使用して通知できます。
Figure 1 illustrates how if one receives RTCP Sender Report (SR) packet P1 for one RTP stream and RTCP SR packet P2 for the other RTP stream, then one can calculate the corresponding RTP timestamp values for any arbitrary point in time T. However, to be able to do that, it is also required to know the RTP timestamp rates for each RTP stream currently used in the sessions.
図1は、1つのRTPストリームのRTCP送信者レポート（SR）パケットP1と他のRTPストリームのRTCP SRパケットP2を受信した場合、任意の時点Tの対応するRTPタイムスタンプ値を計算する方法を示しています。それを行うには、現在セッションで使用されている各RTPストリームのRTPタイムスタンプレートを知る必要もあります。
TS1 --+---------------+------->
| |
P1 |
| |
NTP ---+-----+---------T------>
| |
P2 |
| |
TS2 ---------+---------+---X-->
Figure 1: RTCP Synchronization
図1：RTCP同期
Assume that medium 1 uses an RTP timestamp clock rate of 16 kHz, and medium 2 uses a clock rate of 90 kHz. Then, TS1 and TS2 for point T can be calculated in the following way: TS1(T) = TS1(P1) + 16000 * (NTP(T)-NTP(P1)) and TS2(T) = TS2(P2) + 90000 * (NTP(T)-NTP(P2)). This calculation is useful as it allows the implementation to generate a common synchronization point for which all time values are provided (TS1(T), TS2(T) and T). So, when one wishes to calculate the NTP time that the timestamp value present in packet X corresponds to, one can do that in the following way: NTP(X) = NTP(T) + (TS2(X) - TS2(T))/90000.
メディア1が16 kHzのRTPタイムスタンプクロックレートを使用し、メディア2が90 kHzのクロックレートを使用するとします。次に、ポイントTのTS1およびTS2は、次の方法で計算できます。TS1（T）= TS1（P1）+ 16000 *（NTP（T）-NTP（P1））およびTS2（T）= TS2（P2）+ 90000 *（NTP（T）-NTP（P2））。この計算は、すべての時間値が提供される共通の同期ポイント（TS1（T）、TS2（T）およびT）を実装で生成できるため、便利です。したがって、パケットXに存在するタイムスタンプ値が対応するNTP時間を計算する場合、次の方法で計算できます。NTP（X）= NTP（T）+（TS2（X）-TS2（T） ）/ 90000。
Improved signaling for layered codecs and fast tune-in have been specified in "Rapid Synchronization for RTP Flows" [RFC6051].
レイヤードコーデックと高速チューンインの改善されたシグナリングは、「RTPフローの高速同期」[RFC6051]で指定されています。
Leap seconds are extra seconds added or seconds removed to keep our clocks in sync with the earth's rotation. Adding or removing seconds can impact the reference clock as discussed in "RTP and Leap Seconds" [RFC7164]; also, in cases where the RTP timestamp values are derived using the wall clock during the leap second event, errors can occur. Implementations need to consider leap seconds and should consider the recommendations in [RFC7164].
うるう秒は、地球の回転と時計を同期させるために追加される秒または削除される秒です。秒の追加または削除は、「RTPおよびうるう秒」[RFC7164]で説明されているように、基準クロックに影響を与える可能性があります。また、うるう秒イベント中にウォールクロックを使用してRTPタイムスタンプ値が取得される場合、エラーが発生する可能性があります。実装ではうるう秒を考慮する必要があり、[RFC7164]の推奨事項を考慮する必要があります。
RTP payload formats are used in the context of application signaling protocols such as SIP [RFC3261] using the Session Description Protocol (SDP) [RFC4566] with Offer/Answer [RFC3264], RTSP [RFC7826], or the Session Announcement Protocol [RFC2974]. These examples all use out-of-band signaling to indicate which type of RTP streams are desired to be used in the session and how they are configured. To be able to declare or negotiate the media format and RTP payload packetization, the payload format must be given an identifier. In addition to the identifier, many payload formats also have the need to signal further configuration information out-of-band for the RTP payloads prior to the media transport session.
RTPペイロード形式は、セッション記述プロトコル（SDP）[RFC4566]とオファー/アンサー[RFC3264]、RTSP [RFC7826]、またはセッションアナウンスメントプロトコル[RFC2974]を使用するSIP [RFC3261]などのアプリケーションシグナリングプロトコルのコンテキストで使用されます。 。これらの例はすべて、帯域外シグナリングを使用して、セッションで使用するRTPストリームのタイプとその構成方法を示しています。メディアフォーマットとRTPペイロードパケット化を宣言またはネゴシエートできるようにするには、ペイロードフォーマットに識別子を与える必要があります。識別子に加えて、多くのペイロード形式では、メディアトランスポートセッションの前に、RTPペイロードの帯域外にさらに構成情報を通知する必要があります。
The above examples of session-establishing protocols all use SDP, but other session description formats may be used. For example, there was discussion of a new XML-based session description format within the IETF (SDP-NG). In the end, the proposal did not get beyond draft protocol specification because of the enormous installed base of SDP implementations. However, to avoid locking the usage of RTP to SDP based out-of-band signaling, the payload formats are identified using a separate definition format for the identifier and associated parameters. That format is the media type.
上記のセッション確立プロトコルの例ではすべてSDPを使用していますが、他のセッション記述形式を使用することもできます。たとえば、IETF（SDP-NG）内の新しいXMLベースのセッション記述形式についての議論がありました。結局、SDP実装の膨大なインストールベースのため、提案はドラフトプロトコル仕様を超えませんでした。ただし、RTPの使用をSDPベースのアウトオブバンドシグナリングにロックしないようにするために、ペイロード形式は、識別子と関連するパラメーターの個別の定義形式を使用して識別されます。その形式はメディアタイプです。
Media types [RFC6838] are identifiers originally created for identifying media formats included in email. In this usage, they were known as MIME types, where the expansion of the MIME acronym includes the word "mail". The term "media type" was introduced to reflect a broader usage, which includes HTTP [RFC7231], Message Session Relay Protocol (MSRP) [RFC4975], and many other protocols to identify arbitrary content carried within the protocols. Media types also provide a media hierarchy that fits RTP payload formats well. Media type names are of two parts and consist of content type and sub-type separated with a slash, e.g., 'audio/PCMA' or 'video/ h263-2000'. It is important to choose the correct content-type when creating the media type identifying an RTP payload format. However, in most cases, there is little doubt what content type the format belongs to. Guidelines for choosing the correct media type and registration rules for media type names are provided in "Media Type Specifications and Registration Procedures" [RFC6838]. The additional rules for media types for RTP payload formats are provided in "Media Type Registration of RTP Payload Formats" [RFC4855].
メディアタイプ[RFC6838]は、もともとメールに含まれるメディアフォーマットを識別するために作成された識別子です。この使用法では、それらはMIMEタイプと呼ばれ、MIMEの頭字語の拡張には「メール」という単語が含まれています。 「メディアタイプ」という用語は、HTTP [RFC7231]、メッセージセッションリレープロトコル（MSRP）[RFC4975]、およびプロトコル内で運ばれる任意のコンテンツを識別するための他の多くのプロトコルを含む、幅広い使用法を反映するために導入されました。メディアタイプは、RTPペイロード形式によく適合するメディア階層も提供します。メディアタイプ名は2つの部分で構成され、スラッシュで区切られたコンテンツタイプとサブタイプで構成されます（例： 'audio / PCMA'または 'video / h263-2000'）。 RTPペイロード形式を識別するメディアタイプを作成するときは、正しいコンテンツタイプを選択することが重要です。ただし、ほとんどの場合、フォーマットがどのコンテンツタイプに属しているかはほぼ間違いありません。正しいメディアタイプとメディアタイプ名の登録ルールを選択するためのガイドラインは、「メディアタイプの仕様と登録手順」[RFC6838]に記載されています。 RTPペイロード形式のメディアタイプの追加ルールは、「RTPペイロード形式のメディアタイプ登録」[RFC4855]で提供されています。
Registration of the RTP payload name is something that is required to avoid name collision in the future. Note that "x-" names are not suitable for any documented format as they have the same problem with name collision and can't be registered. The list of already-registered media types can be found at <https://www.iana.org/assignments/media-types/media-types.xhtml>.
RTPペイロード名の登録は、将来名前の衝突を回避するために必要なものです。 「x-」の名前は、名前の衝突に関する同じ問題があり、登録できないため、文書化された形式には適していません。すでに登録されているメディアタイプのリストは、<https://www.iana.org/assignments/media-types/media-types.xhtml>にあります。
Media types are allowed any number of parameters, which may be required or optional for that media type. They are always specified on the form "name=value". There exist no restrictions on how the value is defined from the media type's perspective, except that parameters must have a value. However, the usage of media types in SDP, etc., has resulted in the following restrictions that need to be followed to make media types usable for RTP-identifying payload formats:
メディアタイプには、任意の数のパラメータが許可されます。これらのパラメータは、そのメディアタイプに必須またはオプションです。それらは常に「name = value」の形式で指定されます。メディアタイプの観点からの値の定義方法に制限はありませんが、パラメータには値が必要です。ただし、SDPなどでメディアタイプを使用すると、RTPを識別するペイロード形式でメディアタイプを使用できるようにするために、次の制限に従う必要があります。
1. Arbitrary binary content in the parameters is allowed, but it needs to be encoded so that it can be placed within text-based protocols. Base64 [RFC4648] is recommended, but for shorter content Base16 [RFC4648] may be more appropriate as it is simpler to interpret for humans. This needs to be explicitly stated when defining a media type parameter with binary values.
1. パラメータ内の任意のバイナリコンテンツは許可されていますが、テキストベースのプロトコル内に配置できるようにエンコードする必要があります。 Base64 [RFC4648]が推奨されますが、コンテンツが短い場合は、Base16 [RFC4648]の方が人間にとって解釈が簡単なので、より適切な場合があります。これは、バイナリ値でメディアタイプパラメータを定義するときに明示的に指定する必要があります。
2. The end of the value needs to be easily found when parsing a message. Thus, parameter values that are continuous and not interrupted by common text separators, such as space and semicolon characters, are recommended. If that is not possible, some type of escaping should be used. Usage of quote (") is recommended; do not forget to provide a method of encoding any character used for quoting inside the quoted element.
2. メッセージを解析するときに、値の終わりを簡単に見つける必要があります。したがって、連続していて、スペースやセミコロン文字などの一般的なテキスト区切り文字によって中断されないパラメーター値をお勧めします。それが不可能な場合は、ある種のエスケープを使用する必要があります。引用（ "）の使用をお勧めします;引用された要素内の引用に使用される文字をエンコードする方法を提供することを忘れないでください。
3. A common representation form for the media type and its parameters is on a single line. In that case, the media type is followed by a semicolon-separated list of the parameter value pairs, e.g.:
3. メディアタイプとそのパラメーターの一般的な表現形式は1行です。その場合、メディアタイプの後にパラメーター値のペアのセミコロン区切りのリストが続きます。例：
audio/amr octet-align=0; mode-set=0,2,5,7; mode-change-period=2
Since SDP [RFC4566] is so commonly used as an out-of-band signaling protocol, a mapping of the media type into SDP exists. The details on how to map the media type and its parameters into SDP are described in [RFC4855]. However, this is not sufficient to explain how certain parameters must be interpreted, for example, in the context of Offer/Answer negotiation [RFC3264].
SDP [RFC4566]はアウトオブバンドシグナリングプロトコルとして一般的に使用されるため、メディアタイプのSDPへのマッピングが存在します。メディアタイプとそのパラメータをSDPにマップする方法の詳細は、[RFC4855]で説明されています。ただし、これは、たとえばオファー/アンサーネゴシエーション[RFC3264]のコンテキストで、特定のパラメーターをどのように解釈する必要があるかを説明するには十分ではありません。
The Offer/Answer (O/A) model allows SIP to negotiate which media formats and payload formats are to be used in a session and how they are to be configured. However, O/A does not define a default behavior; instead, it points out the need to define how parameters behave. To make things even more complex, the direction of media within a session has an impact on these rules, so that some cases may require separate descriptions for RTP streams that are send-only, receive-only, or both sent and received as identified by the SDP attributes a=sendonly, a=recvonly, and a=sendrecv. In addition, the usage of multicast adds further limitations as the same RTP stream is delivered to all participants. If those multicast-imposed restrictions are too limiting for unicast, then separate rules for unicast and multicast will be required.
オファー/アンサー（O / A）モデルにより、SIPはセッションで使用されるメディアフォーマットとペイロードフォーマット、およびそれらの構成方法をネゴシエートできます。ただし、O / Aはデフォルトの動作を定義していません。代わりに、パラメーターの動作を定義する必要性を指摘しています。さらに複雑にするために、セッション内のメディアの方向はこれらのルールに影響を与えるため、場合によっては、送信専用、受信専用、または送信と受信の両方であるRTPストリームの個別の説明が必要になることがあります。 SDP属性a = sendonly、a = recvonly、およびa = sendrecv。さらに、マルチキャストを使用すると、同じRTPストリームがすべての参加者に配信されるため、さらに制限が追加されます。マルチキャストによって課されるこれらの制限がユニキャストに対してあまりにも制限的である場合、ユニキャストとマルチキャストの別々のルールが必要になります。
The simplest and most common O/A interpretation is that a parameter is defined to be declarative; i.e., the SDP Offer/Answer sending agent can declare a value and that has no direct impact on the other agent's values. This declared value applies to all media that are going to be sent to the declaring entity. For example, most video codecs have a level parameter that tells the other participants the highest complexity the video decoder supports. The level parameter can be declared independently by two participants in a unicast session as it will be the media sender's responsibility to transmit a video stream that fulfills the limitation the other side has declared. However, in multicast, it will be necessary to send a stream that follows the limitation of the weakest receiver, i.e., the one that supports the lowest level. To simplify the negotiation in these cases, it is common to require any answerer to a multicast session to take a yes or no approach to parameters.
最も単純で最も一般的なO / Aの解釈は、パラメーターが宣言型として定義されていることです。つまり、SDP Offer / Answer送信エージェントは値を宣言でき、それが他のエージェントの値に直接影響を与えることはありません。この宣言された値は、宣言エンティティに送信されるすべてのメディアに適用されます。たとえば、ほとんどのビデオコーデックには、他の参加者にビデオデコーダーがサポートする最高の複雑さを伝えるレベルパラメーターがあります。 levelパラメータは、ユニキャストセッションの2人の参加者が独立して宣言できます。これは、相手側が宣言した制限を満たすビデオストリームを送信するのがメディア送信者の責任であるためです。ただし、マルチキャストでは、最も弱いレシーバー、つまり最低レベルをサポートするレシーバーの制限に従うストリームを送信する必要があります。これらの場合のネゴシエーションを簡素化するために、マルチキャストセッションへのすべての回答者に、パラメーターに対して「はい」または「いいえ」のアプローチを取ることを要求することが一般的です。
A "negotiated" parameter is a different case, for which both sides need to agree on its value. Such a parameter requires the answerer to either accept it as it is offered or remove the payload type the parameter belonged to from its answer. The removal of the payload type from the answer indicates to the offerer the lack of support for the parameter values presented. An unfortunate implication of the need to use complete payload types to indicate each possible configuration so as to maximize the chances of achieving interoperability, is that the number of necessary payload types can quickly grow large. This is one reason to limit the total number of sets of capabilities that may be implemented.
「ネゴシエートされた」パラメーターは別のケースであり、両方の側がその値について合意する必要があります。そのようなパラメーターは、それが提供されたときにそれを受け入れるか、そのパラメーターが属していたペイロードタイプをその応答から削除するかのいずれかを、応答側に要求します。回答からのペイロードタイプの削除は、提示されたパラメーター値のサポートの欠如を提供者に示します。相互運用性を実現する可能性を最大化するために、可能性のある各構成を示すために完全なペイロードタイプを使用する必要があるという残念な影響は、必要なペイロードタイプの数が急速に大きくなる可能性があることです。これは、実装できる機能のセットの総数を制限する1つの理由です。
The most problematic type of parameters are those that relate to the media the entity sends. They do not really fit the O/A model, but can be shoehorned in. Examples of such parameters can be found in the H.264 video codec's payload format [RFC6184], where the name of all parameters with this property starts with "sprop-". The issue with these parameters is that they declare properties for a RTP stream that the other party may not accept. The best one can make of the situation is to explain the assumption that the other party will accept the same parameter value for the media it will receive as the offerer of the session has proposed. If the answerer needs to change any declarative parameter relating to streams it will receive, then the offerer may be required to make a new offer to update the parameter values for its outgoing RTP stream.
最も問題のあるタイプのパラメーターは、エンティティーが送信するメディアに関連するパラメーターです。これらは実際にはO / Aモデルに適合しませんが、簡単に組み込むことができます。このようなパラメーターの例は、H.264ビデオコーデックのペイロード形式[RFC6184]にあります。このプロパティを持つすべてのパラメーターの名前は、「sprop -」これらのパラメータの問題は、相手が受け入れない可能性のあるRTPストリームのプロパティを宣言することです。セッションの提供者が提案したのと同じように、相手が受信するメディアに対して同じパラメータ値を受け入れるという仮定を説明することが、状況を理解する最良の方法です。応答側が受信するストリームに関連する宣言的パラメーターを変更する必要がある場合、オファー側は、発信RTPストリームのパラメーター値を更新するための新しいオファーを行う必要がある場合があります。
Another issue to consider is the send-only RTP streams in offers. Parameters that relate to what the answering entity accepts to receive have no meaning other than to provide a template for the answer. It is worth pointing out in the specification that these really provide a set of parameter values that the sender recommends. Note that send-only streams in answers will need to indicate the offerer's parameters to ensure that the offerer can match the answer to the offer.
考慮すべきもう1つの問題は、オファーの送信専用RTPストリームです。応答エンティティが受け取ることを受け入れるものに関連するパラメータは、応答のテンプレートを提供する以外に意味はありません。これらは実際に送信者が推奨する一連のパラメーター値を提供することを仕様で指摘する価値があります。回答の送信専用ストリームは、オファーへの回答をオファーに確実に一致させるために、オファーのパラメータを示す必要があることに注意してください。
A further issue with Offer/Answer that complicates things is that the answerer is allowed to renumber the payload types between offer and answer. This is not recommended, but allowed for support of gateways to the ITU conferencing suite. This means that it must be possible to bind answers for payload types to the payload types in the offer even when the payload type number has been changed, and some of the proposed payload types have been removed. This binding must normally be done by matching the configurations originally offered against those in the answer. This may require specification in the payload format of which parameters that constitute a configuration, for example, as done in Section 8.2.2 of the H.264 RTP Payload format [RFC6184], which states: "The parameters identifying a media format configuration for H.264 are profile-level-id and packetization-mode".
物事を複雑にするオファー/アンサーの別の問題は、オファーとアンサーの間でペイロードタイプの番号を変更できることです。これは推奨されませんが、ITU会議スイートへのゲートウェイのサポートのために許可されています。つまり、ペイロードタイプ番号が変更され、提案されたペイロードタイプの一部が削除されている場合でも、ペイロードタイプの回答をオファーのペイロードタイプにバインドできる必要があります。このバインディングは通常、最初に提供された構成を回答の構成と照合することによって行われる必要があります。これには、たとえば、H.264 RTPペイロード形式[RFC6184]のセクション8.2.2で行われているように、構成を構成するパラメーターのペイロード形式での指定が必要になる場合があります。 H.264は、プロファイルレベルIDとパケット化モードです。」
SAP (Session Announcement Protocol) [RFC2974] was experimentally used for announcing multicast sessions. Similar but better protocols are using SDP in a declarative style to configure multicast-based applications. Independently of the usage of Source-Specific Multicast (SSM) [RFC3569] or Any-Source Multicast (ASM), the SDP provided by these configuration delivery protocols applies to all participants. All media that is sent to the session must follow the RTP stream definition as specified by the SDP. This enables everyone to receive the session if they support the configuration. Here, SDP provides a one-way channel with no possibility to affect the configuration that the session creator has decided upon. Any RTP payload format that requires parameters for the send direction and that needs individual values per implementation or instance will fail in a SAP session for a multicast session allowing anyone to send.
SAP（Session Announcement Protocol）[RFC2974]は、マルチキャストセッションのアナウンスに実験的に使用されました。似ているがより優れたプロトコルは、宣言型のSDPを使用して、マルチキャストベースのアプリケーションを構成しています。 Source-Specific Multicast（SSM）[RFC3569]またはAny-Source Multicast（ASM）の使用とは関係なく、これらの構成配信プロトコルによって提供されるSDPはすべての参加者に適用されます。セッションに送信されるすべてのメディアは、SDPで指定されたRTPストリーム定義に従う必要があります。これにより、構成をサポートするすべてのユーザーがセッションを受信できるようになります。ここで、SDPは、セッション作成者が決定した構成に影響を与える可能性のない一方向チャネルを提供します。送信方向のパラメーターを必要とし、実装またはインスタンスごとに個別の値を必要とするRTPペイロード形式は、誰でも送信できるマルチキャストセッションのSAPセッションでは失敗します。
Real-Time Streaming Protocol (RTSP) [RFC7826] allows the negotiation of transport parameters for RTP streams that are part of a streaming session between a server and client. RTSP has divided the transport parameters from the media configuration. SDP is commonly used for media configuration in RTSP and is sent to the client prior to session establishment, either through use of the DESCRIBE method or by means of an out-of-band channel like HTTP, email, etc. The SDP is used to determine which RTP streams and what formats are being used prior to session establishment.
リアルタイムストリーミングプロトコル（RTSP）[RFC7826]は、サーバーとクライアント間のストリーミングセッションの一部であるRTPストリームのトランスポートパラメーターのネゴシエーションを可能にします。 RTSPは、メディア構成からトランスポートパラメータを分割しました。 SDPは一般にRTSPのメディア構成に使用され、DESCRIBEメソッドを使用するか、HTTPや電子メールなどの帯域外チャネルを使用して、セッションの確立前にクライアントに送信されます。SDPは、セッションの確立前に、どのRTPストリームとどのフォーマットが使用されているかを判別します。
Thus, both SAP and RTSP use SDP to configure receivers and senders with a predetermined configuration for a RTP stream including the payload format and any of its parameters. All parameters are used in a declarative fashion. This can result in different treatment of parameters between Offer/Answer and declarative usage in RTSP and SAP. Any such difference will need to be spelled out by the payload format specification.
したがって、SAPとRTSPはどちらもSDPを使用して、ペイロード形式とそのパラメーターを含むRTPストリームの事前定義された構成でレシーバーとセンダーを構成します。すべてのパラメーターは宣言的な方法で使用されます。これにより、RTSPとSAPでオファー/アンサーと宣言的な使用法の間でパラメーターの処理が異なる可能性があります。このような違いは、ペイロード形式の仕様で詳しく説明する必要があります。
The general channel characteristics that RTP flows experience are documented in Section 3 of "Guidelines for Writers of RTP Payload Format Specifications" [RFC2736]. The discussion below provides additional information.
RTPフローが経験する一般的なチャネル特性は、「RTPペイロード形式仕様の作成者のためのガイドライン」[RFC2736]のセクション3に記載されています。以下の説明では、追加情報を提供します。
At the time of writing, the most common IP Maximum Transmission Unit (MTU) in commonly deployed link layers is 1500 bytes (Ethernet data payload). However, there exist both links with smaller MTUs and links with much larger MTUs. An example for links with small MTU size is older generation cellular links. Certain parts of the Internet already support an IP MTU of 8000 bytes or more, but these are limited islands. The most likely places to find MTUs larger than 1500 bytes are within enterprise networks, university networks, data centers, storage networks, and over high capacity (10 Gbps or more) links. There is a slow, ongoing evolution towards larger MTU sizes. However, at the same time, it has become common to use tunneling protocols, often multiple ones, whose overhead when added together can shrink the MTU significantly. Thus, there exists a need both to consider limited MTUs as well as enable support of larger MTUs. This should be considered in the design, especially in regard to features such as aggregation of independently decodable data units.
これを書いている時点では、一般的に配備されているリンク層で最も一般的なIP最大伝送ユニット（MTU）は1500バイト（イーサネットデータペイロード）です。ただし、MTUが小さいリンクとMTUがはるかに大きいリンクの両方が存在します。 MTUサイズが小さいリンクの例は、旧世代のセルラーリンクです。インターネットの特定の部分はすでに8000バイト以上のIP MTUをサポートしていますが、これらは制限されたアイランドです。 1500バイトを超えるMTUを見つける可能性が最も高い場所は、エンタープライズネットワーク、大学ネットワーク、データセンター、ストレージネットワーク内、および大容量（10 Gbps以上）リンク上です。より大きなMTUサイズに向けて、ゆっくりと進行中の進化があります。ただし、同時に、多くの場合、複数のトンネリングプロトコルを使用することが一般的になり、それらを追加するとオーバーヘッドによってMTUが大幅に縮小する可能性があります。したがって、限られたMTUを考慮するだけでなく、より大きなMTUのサポートを可能にする必要がある。これは、特に独立してデコード可能なデータユニットの集約などの機能に関して、設計で考慮する必要があります。
Routers and switches on the network path between an IP sender and a particular receiver can exhibit different behaviors affecting the end-to-end characteristics. One of the more important aspects of this is queuing behavior. Routers and switches have some amount of queuing to handle temporary bursts of data that designated to leave the switch or router on the same egress link. A queue, when not empty, results in an increased path delay.
IP送信側と特定の受信側の間のネットワークパス上のルーターとスイッチは、エンドツーエンドの特性に影響するさまざまな動作を示す可能性があります。これのより重要な側面の1つは、キューイング動作です。ルーターとスイッチには、スイッチまたはルーターを同じ出力リンクに残すように指定された一時的なデータバーストを処理するために、ある程度のキューイングがあります。キューが空でない場合、パス遅延が増加します。
The implementation of the queuing affects the delay and also how congestion signals (Explicit Congestion Notification (ECN) [RFC6679] or packet drops) are provided to the flow. The other aspects are if the flow shares the queue with other flows and how the implementation affects the flow interaction. This becomes important, for example, when real-time flows interact with long-lived TCP flows. TCP has a built-in behavior in its congestion control that strives to fill the buffer; thus, all flows sharing the buffer experienced the delay build up.
キューイングの実装は遅延に影響し、輻輳信号（明示的輻輳通知（ECN）[RFC6679]またはパケットドロップ）がフローに提供される方法にも影響します。他の側面は、フローが他のフローとキューを共有するかどうか、および実装がフローの相互作用にどのように影響するかです。これは、たとえば、リアルタイムフローが長寿命のTCPフローと相互作用する場合に重要になります。 TCPには、バッファをいっぱいにしようとする輻輳制御の組み込み動作があります。したがって、バッファを共有するすべてのフローで遅延の蓄積が発生しました。
A common, but quite poor, queue-handling mechanism is tail-drop, i.e., only drop packets when the incoming packet doesn't fit in the queue. If a bad queuing algorithm is combined with too much queue space, the queuing time can grow to be very significant and can even become multiple seconds. This is called "bufferbloat" [BLOAT]. Active Queue Management (AQM) is a term covering mechanisms that try to do something smarter by actively managing the queue, for example, sending congestion signals earlier by dropping packets earlier in the queue. The behavior also affects the flow interactions. For example, Random Early Detection (RED) [RED] selects which packet(s) to drop randomly. This gives flows that have more packets in the queue a higher probability to experience the packet loss (congestion signal). There is ongoing work in the IETF WG AQM to find suitable mechanisms to recommend for implementation and reduce the use of tail-drop.
一般的な、しかしかなり貧弱なキュー処理メカニズムはテールドロップです。つまり、着信パケットがキューに収まらない場合にのみパケットをドロップします。不適切なキューイングアルゴリズムとキュースペースが多すぎると、キューイング時間が非常に長くなり、数秒になることさえあります。これは「バッファブロート」[BLOAT]と呼ばれます。アクティブキュー管理（AQM）は、キューをアクティブに管理することにより、たとえば、パケットをキューに早くドロップすることで輻輳信号を早く送信することで、よりスマートなことを試みるメカニズムをカバーする用語です。この動作は、流れの相互作用にも影響します。たとえば、ランダム早期検出（RED）[RED]は、ランダムにドロップするパケットを選択します。これにより、キューにより多くのパケットがあるフローは、パケット損失（輻輳信号）を経験する可能性が高くなります。 IETF WG AQMには、実装を推奨し、テールドロップの使用を減らすための適切なメカニズムを見つけるための作業が進行中です。
Using best-effort Internet has no guarantees for the path's properties. QoS mechanisms are intended to provide the possibility to bound the path properties. Where Diffserv [RFC2475] markings affect the queuing and forwarding behaviors of routers, the mechanism provides only statistical guarantees and care in how much marked packets of different types that are entering the network. Flow-based QoS, like IntServ [RFC1633], has the potential for stricter guarantees as the properties are agreed on by each hop on the path, at the cost of per-flow state in the network.
ベストエフォートのインターネットを使用しても、パスのプロパティは保証されません。 QoSメカニズムは、パスプロパティをバインドする可能性を提供することを目的としています。 Diffserv [RFC2475]マーキングがルーターのキューイングおよび転送動作に影響を与える場合、メカニズムは統計的な保証のみを提供し、ネットワークに入るさまざまなタイプのマークされたパケットの量に注意します。 IntServ [RFC1633]のようなフローベースのQoSは、ネットワーク内のフローごとの状態を犠牲にして、パス上の各ホップでプロパティが合意されるため、より厳密な保証の可能性があります。
This section discusses the recommended process to produce an RTP payload format in the described venues. This is to document the best current practice on how to get a well-designed and specified payload format as quickly as possible. For specifications that are defined by standards bodies other than the IETF, the primary milestone is the registration of the media type for the RTP payload format. For proprietary media formats, the primary goal depends on whether interoperability is desired at the RTP level. However, there is also the issue of ensuring best possible quality of any specification.
このセクションでは、説明されている場所でRTPペイロード形式を生成するための推奨プロセスについて説明します。これは、適切に設計され指定されたペイロード形式をできるだけ早く取得する方法に関する現在のベストプラクティスを文書化するためのものです。 IETF以外の標準化団体によって定義された仕様の場合、主要なマイルストーンは、RTPペイロード形式のメディアタイプの登録です。独自のメディア形式の場合、主な目標は、RTPレベルで相互運用性が必要かどうかによって異なります。ただし、どの仕様でも可能な限り最高の品質を確保するという問題もあります。
For all standardized media formats, it is recommended that the payload format be specified in the IETF. The main reason is to provide an openly available RTP payload format specification that has been reviewed by people experienced with RTP payload formats. At the time of writing, this work is done in the PAYLOAD Working Group (WG), but that may change in the future.
すべての標準化されたメディア形式について、ペイロード形式をIETFで指定することをお勧めします。主な理由は、RTPペイロード形式の経験者によってレビューされた、オープンに利用可能なRTPペイロード形式仕様を提供することです。執筆時点では、この作業はPAYLOADワーキンググループ（WG）で行われていますが、将来的には変更される可能性があります。
There are a number of steps that an RTP payload format should go through from the initial idea until it is published. This also documents the process that the PAYLOAD WG applies when working with RTP payload formats.
RTPペイロード形式は、最初のアイデアから公開されるまでに実行する必要があるいくつかのステップがあります。これは、RTPペイロード形式で作業するときにPAYLOAD WGが適用するプロセスも文書化しています。
Idea: Determine the need for an RTP payload format as an IETF specification.
アイデア：IETF仕様としてのRTPペイロード形式の必要性を判断します。
Initial effort: Using this document as a guideline, one should be able to get started on the work. If one's media codec doesn't fit any of the common design patterns or one has problems understanding what the most suitable way forward is, then one should contact the PAYLOAD WG and/or the WG Chairs. The goal of this stage is to have an initial individual draft. This draft needs to focus on the introductory parts that describe the real-time media format and the basic idea on how to packetize it. Not all the details are required to be filled in. However, the security chapter is not something that one should skip, even initially. From the start, it is important to consider any serious security risks that need to be solved. The first step is completed when one has a draft that is sufficiently detailed for a first review by the WG. The less confident one is of the solution, the less work should be spent on details; instead, concentrate on the codec properties and what is required to make the packetization work.
初期の取り組み：このドキュメントをガイドラインとして使用すると、作業を開始できるはずです。メディアコーデックが一般的なデザインパターンのいずれにも適合しない場合、または最も適切な方法を理解するのに問題がある場合は、PAYLOAD WGおよび/またはWG議長に連絡する必要があります。この段階の目標は、最初の個別ドラフトを作成することです。このドラフトでは、リアルタイムメディアフォーマットとそれをパケット化する方法の基本的な考え方を説明する導入部に焦点を当てる必要があります。すべての詳細を入力する必要があるわけではありません。ただし、セキュリティの章は、最初であってもスキップすべきものではありません。最初から、解決する必要がある深刻なセキュリティリスクを考慮することが重要です。最初のステップは、WGによる最初のレビューのために十分詳細なドラフトがある場合に完了します。解決策の信頼性が低いほど、詳細に費やす作業が少なくなります。代わりに、コーデックのプロパティと、パケット化を機能させるために必要なことに集中してください。
Submission of the first version: When one has performed the above, one submits the draft as an individual draft (https://datatracker.ietf.org/submit/). This can be done at any time, except for a period prior to an IETF meeting (see important dates related to the next IETF meeting for draft submission cutoff date). When the Internet-Draft announcement has been sent out on the draft announcement list (https://www.ietf.org/mailman/listinfo/I-D-Announce), forward it to the PAYLOAD WG (https://www.ietf.org/mailman/listinfo/payload) and request that it be reviewed. In the email, outline any issues the authors currently have with the design.
最初のバージョンの提出：上記を実行した後、ドラフトを個別のドラフトとして提出します（https://datatracker.ietf.org/submit/）。これは、IETF会議の前の期間を除いて、いつでも行うことができます（ドラフト提出締切日については、次回のIETF会議に関連する重要な日付を参照してください）。ドラフト発表リスト（https://www.ietf.org/mailman/listinfo/ID-Announce）でインターネットドラフト発表が送信されたら、PAYLOAD WG（https：//www.ietf。 org / mailman / listinfo / payload）にアクセスして、レビューを依頼してください。メールに、著者がデザインに関して現在抱えている問題の概要を説明します。
Iterative improvements: Taking the feedback received into account, one updates the draft and tries resolve issues. New revisions of the draft can be submitted at any time (again except for a short period before meetings). It is recommended to submit a new version whenever one has made major updates or has new issues that are easiest to discuss in the context of a new draft version.
反復的な改善：受け取ったフィードバックを考慮に入れて、下書きを更新し、問題の解決を試みます。ドラフトの新しい改訂はいつでも（会議の前の短い期間を除いて）提出できます。新しいドラフトバージョンのコンテキストで話し合うのが最も簡単なメジャーアップデートや新しい問題がある場合は、新しいバージョンを送信することをお勧めします。
Becoming a WG document: Given that the definition of RTP payload formats is part of the PAYLOAD WG's charter, RTP payload formats that are going to be published as Standards Track RFCs need to become WG documents. Becoming a WG document means that the WG Chairs or an appointed document shepherd are responsible for administrative handling, for example, issuing publication requests. However, be aware that making a document into a WG document changes the formal ownership and responsibility from the individual authors to the WG. The initial authors normally continue being the document editors, unless unusual circumstances occur. The PAYLOAD WG accepts new RTP payload formats based on their suitability and document maturity. The document maturity is a requirement to ensure that there are dedicated document editors and that there exists a good solution.
WGドキュメントになる：RTPペイロード形式の定義がPAYLOAD WGの憲章の一部であることを考えると、Standards Track RFCとして公開されるRTPペイロード形式はWGドキュメントになる必要があります。 WGドキュメントになるとは、WGの議長または任命されたドキュメントシェパードが、管理要求（発行要求の発行など）を担当することを意味します。ただし、ドキュメントをWGドキュメントにすると、個々の作成者からWGへの正式な所有権と責任が変わることに注意してください。異常な状況が発生しない限り、最初の作成者は通常、ドキュメント編集者であり続けます。 PAYLOAD WGは、適合性とドキュメントの成熟度に基づいて、新しいRTPペイロード形式を受け入れます。ドキュメントの成熟度は、専用のドキュメントエディタが存在し、優れたソリューションが存在することを保証するための要件です。
Iterative improvements: The updates and review cycles continue until the draft has reached the level of maturity suitable for publication. The authors are responsible for judging when the document is ready for the next step, most likely WG Last Call, but they can ask the WG chairs or Shepherd.
反復的な改善：ドラフトが公開に適した成熟度のレベルに達するまで、更新とレビューのサイクルが続きます。作成者は、ドキュメントが次のステップ、おそらくWGラストコールの準備ができた時期を判断する責任がありますが、WGの議長またはシェパードに質問することができます。
WG Last Call: A WG Last Call of at least two weeks is always performed for payload formats in the PAYLOAD WG (see Section 7.4 of [RFC2418]). The authors request WG Last Call for a draft when they think it is mature enough for publication. The WG Chairs or shepherd perform a review to check if they agree with the authors' assessment. If the WG Chairs or shepherd agree on the maturity, the WG Last Call is announced on the WG mailing list. If there are issues raised, these need to be addressed with an updated draft version. For any more substantial changes to the draft, a new WG Last Call is announced for the updated version. Minor changes, like editorial fixes, can be progressed without an additional WG Last Call.
WGラストコール：PAYLOAD WGのペイロード形式では、少なくとも2週間のWGラストコールが常に実行されます（[RFC2418]のセクション7.4を参照）。執筆者は、公開が十分に成熟していると思われる場合、ドラフトをWG Last Callに要求します。 WGの議長または羊飼いは、レビューを実行して、著者の評価に同意するかどうかを確認します。 WGの議長または羊飼いが成熟度について合意した場合、WGラストコールはWGメーリングリストで発表されます。問題が発生した場合は、更新されたドラフトバージョンでこれらに対処する必要があります。ドラフトへの大幅な変更については、更新版の新しいWG Last Callが発表されます。編集上の修正などのマイナーな変更は、WG Last Callを追加しなくても進行できます。
Publication requested: For WG documents, the WG Chairs or shepherd request publication of the draft after it has passed WG Last Call. After this, the approval and publication process described in BCP 9 [BCP9] is performed. The status after the publication has been requested can be tracked using the IETF Datatracker [TRACKER]. Documents do not expire as they normally do after publication has been requested, so authors do not have to issue keep-alive updates. In addition, any submission of document updates requires the approval of WG Chair(s). The authors are commonly asked to address comments or issues raised by the IESG. The authors also do one last review of the document immediately prior to its publication as an RFC to ensure that no errors or formatting problems have been introduced during the publication process.
要求された公開：WGドキュメントの場合、WGの議長または羊飼いは、ドラフトがWGラストコールを通過した後に、ドラフトの公開を要求します。この後、BCP 9 [BCP9]に記載されている承認および公開プロセスが実行されます。公開が要求された後のステータスは、IETF Datatracker [TRACKER]を使用して追跡できます。ドキュメントは、発行が要求された後、通常のように有効期限が切れないため、作成者はキープアライブ更新を発行する必要はありません。さらに、ドキュメントの更新を提出するには、WG議長の承認が必要です。著者は通常、IESGによって提起されたコメントまたは問題に対処するよう求められます。著者はまた、RFCとしての発行直前に文書の最後のレビューを行い、発行プロセス中にエラーやフォーマットの問題が発生していないことを確認します。
WG meetings are for discussing issues, not presentations. This means that most RTP payload formats should never need to be discussed in a WG meeting. RTP payload formats that would be discussed are either those with controversial issues that failed to be resolved on the mailing list or those including new design concepts worth a general discussion.
WGミーティングはプレゼンテーションではなく、問題を議論するためのものです。これは、ほとんどのRTPペイロード形式がWGミーティングで議論される必要がないことを意味します。議論されるRTPペイロード形式は、メーリングリストで解決できなかった物議を醸す問題がある形式、または一般的な議論に値する新しい設計概念を含む形式です。
There exists no requirement to present or discuss a draft at a WG meeting before it becomes published as an RFC. Thus, even authors who lack the possibility to go to WG meetings should be able to successfully specify an RTP payload format in the IETF. WG meetings may become necessary only if the draft gets stuck in a serious debate that cannot easily be resolved.
RFCとして公開される前に、草案をWGミーティングで提示または議論する必要はありません。したがって、WGミーティングに行く可能性のない作成者でも、IETFでRTPペイロード形式を正常に指定できるはずです。草案が簡単に解決できない深刻な議論に巻き込まれた場合にのみ、WGミーティングが必要になる場合があります。
To simplify the work of the PAYLOAD WG Chairs and WG members, a specific Internet-Draft file-naming convention shall be used for RTP payload formats. Individual submissions shall be named using the template: draft-<lead author family name>-payload-rtp-<descriptive name>-<version>. The WG documents shall be named according to this template: draft-ietf-payload-rtp-<descriptive name>-<version>. The inclusion of "payload" in the draft file name ensures that the search for "payload-" will find all PAYLOAD-related drafts. Inclusion of "rtp" tells us that it is an RTP payload format draft. The descriptive name should be as short as possible while still describing what the payload format is for. It is recommended to use the media format or codec abbreviation. Please note that the version must start at 00 and is increased by one for each submission to the IETF secretary of the draft. No version numbers may be skipped. For more details on draft naming, please see Section 7 of [ID-GUIDE].
PAYLOAD WGの議長とWGメンバーの作業を簡略化するために、RTPペイロード形式には、特定のインターネットドラフトファイル命名規則を使用する必要があります。個々の提出物は、テンプレートを使用して名前を付ける必要があります：ドラフト-<主執筆者のファミリ名> -payload-rtp- <説明的な名前>-<バージョン>。 WG文書は、このテンプレートに従って名前が付けられます：draft-ietf-payload-rtp- <説明的な名前>-<バージョン>。ドラフトファイル名に「payload」を含めると、「payload-」を検索すると、PAYLOAD関連のすべてのドラフトが確実に見つかります。 「rtp」を含めることは、RTPペイロード形式のドラフトであることを示しています。ペイロード形式の目的を説明しながら、説明的な名前はできるだけ短くする必要があります。メディア形式またはコーデックの省略形を使用することをお勧めします。バージョンは00から開始する必要があり、ドラフトのIETF幹事に提出されるたびに1つずつ増加することに注意してください。バージョン番号はスキップできません。ドラフトの命名の詳細については、[ID-GUIDE]のセクション7を参照してください。
When writing an Internet-Draft for an RTP payload format, one should observe some few considerations (that may be somewhat divergent from the style of other IETF documents and/or the media coding spec's author group may use):
RTPペイロード形式のInternet-Draftを作成する場合、いくつかの考慮事項に注意する必要があります（他のIETFドキュメントのスタイルやメディアコーディング仕様の作成者グループが使用するスタイルとは多少異なる場合があります）。
Include Motivations: In the IETF, it is common to include the motivation for why a particular design or technical path was chosen. These are not long statements: a sentence here and there explaining why suffice.
動機を含める：IETFでは、特定の設計または技術パスが選択された理由の動機を含めるのが一般的です。これらは長い説明ではありません。なぜ十分なのかを説明するあちこちの文章です。
Use the Defined Terminology: There exists defined terminology both in RTP and in the media codec specification for which the RTP payload format is designed. A payload format specification needs to use both to make clear the relation of features and their functions. It is unwise to introduce or, worse, use without introduction, terminology that appears to be more accessible to average readers but may miss certain nuances that the defined terms imply. An RTP payload format author can assume the reader to be reasonably familiar with the terminology in the media coding specification.
定義された用語の使用：RTPと、RTPペイロード形式が設計されているメディアコーデック仕様の両方に定義された用語があります。ペイロード形式の仕様では、機能とその機能の関係を明確にするために両方を使用する必要があります。平均的な読者にとってよりアクセスしやすいように見えるが、定義された用語が意味する特定のニュアンスを見逃す可能性がある用語を紹介するか、悪いことに紹介なしで使用することは賢明ではありません。 RTPペイロード形式の作成者は、読者がメディアコーディング仕様の用語にある程度精通していると想定できます。
Keeping It Simple: The IETF has a history of specifications that are focused on their main usage. Historically, some RTP payload formats have a lot of modes and features, while the actual deployments have only included the most basic features that had very clear requirements. Time and effort can be saved by focusing on only the most important use cases and keeping the solution simple. An extension mechanism should be provided to enable backward-compatible extensions, if that is an organic fit.
シンプルに保つ：IETFには、主な使用法に焦点を当てた仕様の歴史があります。従来、一部のRTPペイロード形式には多くのモードと機能がありますが、実際の展開には、非常に明確な要件を持つ最も基本的な機能しか含まれていませんでした。最も重要なユースケースのみに焦点を当て、ソリューションをシンプルに保つことで、時間と労力を節約できます。下位互換性のある拡張を可能にする拡張メカニズムを提供する必要があります。
Normative Requirements: When writing specifications, there is commonly a need to make it clear when something is normative and at what level. In the IETF, the most common method is to use "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119], which defines the meaning of "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL".
規範的要件：仕様を作成する場合、通常、何かが規範的であるとき、そのレベルを明確にする必要があります。 IETFでは、最も一般的な方法は、「必須レベルを示すためにRFCで使用するキーワード」[RFC2119]を使用することです。これは、「必須」、「必須」、「必須」、「必須」、「必須」の意味を定義します。 SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」。
There a number of ways to lose a lot of time in the above process. This section discusses what to do and what to avoid.
上記のプロセスで多くの時間を失ういくつかの方法があります。このセクションでは、何をすべきか、何を避けるべきかについて説明します。
o Do not update the draft only for the meeting deadline. An update to each meeting automatically limits the draft to three updates per year. Instead, ignore the meeting schedule and publish new versions as soon as possible.
o 会議の締め切りのためだけにドラフトを更新しないでください。各会議の更新により、ドラフトは自動的に年間3回に制限されます。代わりに、会議のスケジュールを無視して、できるだけ早く新しいバージョンを公開してください。
o Try to avoid requesting reviews when people are busy, like the few weeks before a meeting. It is actually more likely that people have time for them directly after a meeting.
o 会議の数週間前など、人が忙しいときにレビューをリクエストしないようにしてください。実際には、会議の直後に人々が時間を割く可能性が高くなります。
o Perform draft updates quickly. A common mistake is that the authors let the draft slip. By performing updates to the draft text directly after getting resolution on an issue, things speed up. This minimizes the delay that the author has direct control over. The time taken for reviews, responses from Area Directors and WG Chairs, etc., can be much harder to speed up.
o ドラフト更新をすばやく実行します。よくある間違いは、著者がドラフトを間違えたことです。問題の解決を得た直後に下書きテキストの更新を実行することにより、処理がスピードアップします。これにより、作成者が直接制御できる遅延が最小限に抑えられます。レビュー、エリアディレクターやWG議長からの回答などにかかる時間を短縮することは、はるかに困難です。
o Do not fail to take human nature into account. It happens that people forget or need to be reminded about tasks. Send a kind reminder to the people you are waiting for if things take longer than expected. Ask people to estimate when they expect to fulfill the requested task.
o 人間性を考慮に入れてください。人々がタスクを忘れたり、思い出す必要がある場合があります。予定よりも時間がかかる場合は、待っている人に親切なリマインダーを送信してください。要求されたタスクをいつ完了するかを予測するように人々に依頼します。
o Ensure there is enough review. It is common that documents take a long time and many iterations because not enough review is performed in each iteration. To improve the amount of review you get on your own document, trade review time with other document authors. Make a deal with some other document author that you will review their draft if they review yours. Even inexperienced reviewers can help with language, editorial, or clarity issues. Also, try approaching the more experienced people in the WG and getting them to commit to a review. The WG Chairs cannot, even if desirable, be expected to review all versions. Due to workload, the Chairs may need to concentrate on key points in a draft evolution like checking on initial submissions, a draft's readiness to become a WG document, or its readiness for WG Last Call.
o 十分なレビューがあることを確認してください。各イテレーションで十分なレビューが実行されないため、ドキュメントは長い時間と多くのイテレーションを要することが一般的です。自分のドキュメントで取得するレビューの量を改善するには、レビュー時間を他のドキュメント作成者と交換します。他の文書作成者と契約を結び、草稿をレビューする場合は草稿もレビューするようにします。経験の浅いレビュアーでも、言語、編集、または明確さの問題を解決できます。また、WGの経験豊富な人々にアプローチして、レビューに参加してもらいます。 WG議長は、たとえ望ましいとしても、すべてのバージョンをレビューすることは期待できません。作業負荷のため、議長は、最初の提出の確認、ドラフトのWGドキュメントになる準備、またはWGラストコールの準備など、ドラフトの展開における重要なポイントに集中する必要がある場合があります。
Other standards bodies may define RTP payloads in their own specifications. When they do this, they are strongly recommended to contact the PAYLOAD WG Chairs and request review of the work. It is recommended that at least two review steps are performed. The first should be early in the process when more fundamental issues can be easily resolved without abandoning a lot of effort. Then, when nearing completion, but while it is still possible to update the specification, a second review should be scheduled. In that pass, the quality can be assessed; hopefully, no updates will be needed. Using this procedure can avoid both conflicting definitions and serious mistakes, like breaking certain aspects of the RTP model.
他の標準化団体は、独自の仕様でRTPペイロードを定義する場合があります。これを行うときは、PAYLOAD WGの議長に連絡して作業のレビューを要求することを強くお勧めします。少なくとも2つの確認ステップを実行することをお勧めします。 1つ目は、多くの労力を放棄することなく、より根本的な問題を簡単に解決できるプロセスの早い段階です。その後、完成に近づいたときに、仕様を更新することはまだ可能ですが、2回目のレビューをスケジュールする必要があります。そのパスでは、品質を評価できます。うまくいけば、更新は必要ありません。この手順を使用すると、RTPモデルの特定の側面を壊すなど、矛盾する定義と重大な間違いの両方を回避できます。
RTP payload media types may be registered in the standards tree by other standards bodies. The requirements on the organization are outlined in the media types registration documents [RFC4855] and [RFC6838]). This registration requires a request to the IESG, which ensures that the filled-in registration template is acceptable. To avoid last-minute problems with these registrations the registration template must be sent for review both to the PAYLOAD WG and the media types list (ietf-types@iana.org) and is something that should be included in the IETF reviews of the payload format specification.
RTPペイロードメディアタイプは、他の標準化団体によって標準化ツリーに登録される場合があります。組織の要件は、メディアタイプ登録ドキュメント[RFC4855]および[RFC6838]に概説されています。この登録にはIESGへの要求が必要です。これにより、入力済みの登録テンプレートが受け入れ可能になります。これらの登録の直前の問題を回避するには、登録テンプレートをPAYLOAD WGとメディアタイプリスト（ietf-types@iana.org）の両方にレビューのために送信する必要があり、ペイロードのIETFレビューに含める必要があります。フォーマット仕様。
Proprietary RTP payload formats are commonly specified when the real-time media format is proprietary and not intended to be part of any standardized system. However, there are reasons why also proprietary formats should be correctly documented and registered:
独自のRTPペイロード形式は、リアルタイムメディア形式が独自仕様であり、標準化されたシステムの一部となることを意図していない場合に一般的に指定されます。ただし、プロプライエタリなフォーマットも正しく文書化および登録する必要がある理由があります。
o Usage in a standardized signaling environment, such as SIP/SDP. RTP needs to be configured with the RTP profiles, payload formats, and their payload types being used. To accomplish this, it is desirable to have registered media type names to ensure that the names do not collide with those of other formats.
o SIP / SDPなどの標準化されたシグナリング環境での使用。 RTPは、RTPプロファイル、ペイロード形式、および使用されるペイロードタイプで構成する必要があります。これを実現するには、メディアタイプ名を登録して、他のフォーマットの名前と衝突しないようにすることが望ましいです。
o Sharing with business partners. As RTP payload formats are used for communication, situations often arise where business partners would like to support a proprietary format. Having a well-written specification of the format will save time and money for both parties, as interoperability will be much easier to accomplish.
o ビジネスパートナーとの共有。 RTPペイロード形式は通信に使用されるため、ビジネスパートナーが独自の形式をサポートしたい場合がよくあります。相互運用性の実現がはるかに容易になるため、フォーマットの仕様を適切に記述することで、両者の時間と費用を節約できます。
o To ensure interoperability between different implementations on different platforms.
o 異なるプラットフォームの異なる実装間の相互運用性を確保するため。
To avoid name collisions, there is a central registry keeping track of the registered media type names used by different RTP payload formats. When it comes to proprietary formats, they should be registered in the vendor's own tree. All vendor-specific registrations use sub-type names that start with "vnd.<vendor-name>". Names in the vendor's own tree are not required to be registered with IANA. However, registration [RFC6838] is recommended if the media type is used at all in public environments.
名前の衝突を回避するために、さまざまなRTPペイロード形式で使用される登録済みのメディアタイプ名を追跡する中央レジストリがあります。独自フォーマットについては、ベンダー独自のツリーに登録する必要があります。ベンダー固有の登録はすべて、「vnd。<vendor-name>」で始まるサブタイプ名を使用します。ベンダー独自のツリーの名前は、IANAに登録する必要はありません。ただし、公共の環境でメディアタイプを使用する場合は、登録[RFC6838]をお勧めします。
If interoperability at the RTP level is desired, a payload type specification should be standardized in the IETF following the process described above. The IETF does not require full disclosure of the codec when defining an RTP payload format to carry that codec, but a description must be provided that is sufficient to allow the IETF to judge whether the payload format is well designed. The media type identifier assigned to a standardized payload format of this sort will lie in the standards tree rather than the vendor tree.
RTPレベルでの相互運用性が必要な場合は、上記のプロセスに従って、ペイロードタイプの仕様をIETFで標準化する必要があります。 IETFは、RTPペイロード形式を定義してそのコーデックを伝送するときに、コーデックを完全に開示する必要はありませんが、IETFがペイロード形式が適切に設計されているかどうかを判断できる十分な説明を提供する必要があります。この種類の標準化されたペイロード形式に割り当てられたメディアタイプ識別子は、ベンダーツリーではなく標準ツリーにあります。
4.4. Joint Development of Media Coding Specification and RTP Payload Format
4.4. メディアコーディング仕様とRTPペイロード形式の共同開発
In the last decade, there have been a few cases where the media codec and the associated RTP payload format have been developed concurrently and jointly. Developing the two specs not only concurrently but also jointly, in close cooperation with the group developing the media codec, allows one to leverage the benefits joint source/channel coding can provide. Doing so has historically resulted in well-performing payload formats and in success of both the media coding specification and associated RTP payload format. Insofar, whenever the opportunity presents it, it may be useful to closely keep the media coding group in the loop (through appropriate liaison means whatever those may be) and influence the media coding specification to be RTP friendly. One example for such a media coding specification is H.264, where the RTP payload header co-serves as the H.264 NAL unit header and vice versa, and is documented in both specifications.
この10年間で、メディアコーデックと関連するRTPペイロード形式が同時に共同で開発されたケースがいくつかあります。 2つの仕様を同時に開発するだけでなく、共同で開発することにより、メディアコーデックを開発するグループと密接に協力して、ソース/チャネルの共同コーディングがもたらすメリットを活用できます。そうすることで、歴史的にパフォーマンスの高いペイロード形式が生まれ、メディアコーディング仕様と関連するRTPペイロード形式の両方が成功しています。これまでのところ、機会がそれを提示するときはいつでも、メディアコーディンググループをループ内に密接に保持し（適切なリエゾンを介してそれらが何であれ）、RTPフレンドリーになるようにメディアコーディング仕様に影響を与えることが役立つ場合があります。このようなメディアコーディング仕様の一例はH.264です。RTPペイロードヘッダーはH.264 NALユニットヘッダーとして機能し、その逆も同様です。両方の仕様で文書化されています。
The best summary of payload format design is KISS (Keep It Simple, Stupid). A simple payload format is easier to review for correctness, easier to implement, and has low complexity. Unfortunately, contradictory requirements sometimes make it hard to do things simply. Complexity issues and problems that occur for RTP payload formats are:
ペイロード形式設計の最良の要約はKISS（Keep It Simple、Stupid）です。単純なペイロード形式は、正確性を確認しやすく、実装が簡単で、複雑度も低くなっています。残念ながら、矛盾した要件により、物事を単純に行うことが困難な場合があります。複雑さの問題とRTPペイロード形式で発生する問題は次のとおりです。
Too many configurations: Contradictory requirements lead to the result that one configuration is created for each conceivable case. Such contradictory requirements are often between functionality and bandwidth. This outcome has two big disadvantages; First all configurations need to be implemented. Second, the user application must select the most suitable configuration. Selecting the best configuration can be very difficult and, in negotiating applications, this can create interoperability problems. The recommendation is to try to select a very limited set of configurations (preferably one) that perform well for the most common cases and are capable of handling the other cases, but maybe not that well.
構成が多すぎる：要件が矛盾していると、考えられるケースごとに1つの構成が作成されます。このような相反する要件は、多くの場合、機能と帯域幅の間にあります。この結果には2つの大きな欠点があります。最初に、すべての構成を実装する必要があります。次に、ユーザーアプリケーションは、最も適切な構成を選択する必要があります。最適な構成を選択することは非常に困難な場合があり、アプリケーションのネゴシエーションで相互運用性の問題が発生する可能性があります。最も一般的なケースで十分に機能し、他のケースを処理できる非常に限定された構成のセット（できれば1つ）を選択することをお勧めしますが、そうでない場合もあります。
Hard to implement: Certain payload formats may become difficult to implement both correctly and efficiently. This needs to be considered in the design.
実装が困難：特定のペイロード形式は、正しく効率的に実装することが困難になる場合があります。これは設計で考慮する必要があります。
Interaction with general mechanisms: Special solutions may create issues with deployed tools for RTP, such as tools for more robust transport of RTP. For example, a requirement for an unbroken sequence number space creates issues for mechanisms relying on payload type switching interleaving media-independent resilience within a stream.
一般的なメカニズムとの相互作用：特別なソリューションは、RTPのより堅牢なトランスポート用のツールなど、RTP用にデプロイされたツールに問題を引き起こす可能性があります。たとえば、連続したシーケンス番号スペースの要件は、ストリーム内のメディアに依存しない回復力をインターリーブするペイロードタイプスイッチングに依存するメカニズムに問題を引き起こします。
There are a number of common features in RTP payload formats. There is no general requirement to support these features; instead, their applicability must be considered for each payload format. In fact, it may be that certain features are not even applicable.
RTPペイロード形式には、多くの共通機能があります。これらの機能をサポートするための一般的な要件はありません。代わりに、ペイロードの形式ごとにその適用性を考慮する必要があります。実際、特定の機能が適用できない場合もあります。
Aggregation allows for the inclusion of multiple Application Data Units (ADUs) within the same RTP payload. This is commonly supported for codecs that produce ADUs of sizes smaller than the IP MTU. One reason for the use of aggregation is the reduction of header overhead (IP/UDP/RTP headers). When setting into relation the ADU size and the MTU size, do remember that the MTU may be significantly larger than 1500 bytes. An MTU of 9000 bytes is available today and an MTU of 64k may be available in the future. Many speech codecs have the property of ADUs of a few fixed sizes. Video encoders may generally produce ADUs of quite flexible sizes. Thus, the need for aggregation may be less. But some codecs produce small ADUs mixed with large ones, for example, H.264 Supplemental Enhancement Information (SEI) messages. Sending individual SEI message in separate packets are not efficient compared to combing the with other ADUs. Also, some small ADUs are, within the media domain, semantically coupled to the larger ADUs (for example, in-band parameter sets in H.264 [RFC6184]). In such cases, aggregation is sensible, even if not required from a payload/header overhead viewpoint. There also exist cases when the ADUs are pre-produced and can't be adopted to a specific networks MTU. Instead, their packetization needs to be adopted to the network. All above factors should be taken into account when deciding on the inclusion of aggregation, and weighting its benefits against the complexity of defining them (which can be significant especially when aggregation is performed over ADUs with different playback times).
集約により、同じRTPペイロード内に複数のアプリケーションデータユニット（ADU）を含めることができます。これは、IP MTUよりも小さいサイズのADUを生成するコーデックで一般的にサポートされています。集約を使用する1つの理由は、ヘッダーのオーバーヘッド（IP / UDP / RTPヘッダー）の削減です。 ADUサイズとMTUサイズの関係を設定するときは、MTUが1500バイトを大幅に超える可能性があることに注意してください。現在、9000バイトのMTUが利用可能であり、将来的には64kのMTUが利用可能になる可能性があります。多くの音声コーデックには、いくつかの固定サイズのADUの特性があります。ビデオエンコーダーは、通常、非常に柔軟なサイズのADUを生成します。したがって、集約の必要性は少なくなる場合があります。ただし、一部のコーデックでは、H.264 Supplemental Enhancement Information（SEI）メッセージなど、大きなADUと大きなADUが混在しています。個別のSEIメッセージを個別のパケットで送信することは、を他のADUと組み合わせるよりも効率的ではありません。また、一部の小さなADUは、メディアドメイン内で、大きなADUに意味的に結合されます（たとえば、H.264のインバンドパラメータセット[RFC6184]）。そのような場合、たとえペイロード/ヘッダーのオーバーヘッドの観点から必要でなくても、集約は賢明です。 ADUが事前に作成され、特定のネットワークMTUに採用できない場合もあります。代わりに、それらのパケット化をネットワークに採用する必要があります。集約を含めるかどうかを決定するときは、上記のすべての要素を考慮に入れ、それらの利点をそれらの定義の複雑さに対して重み付けする必要があります（特に、再生時間が異なるADUで集約を実行する場合に重要になります）。
The main disadvantage of aggregation, beyond implementation complexity, is the extra delay introduced (due to buffering until a sufficient number of ADUs have been collected at the sender) and reduced robustness against packet loss. Aggregation also introduces buffering requirements at the receiver.
集約の主な欠点は、実装の複雑さを超えて、追加の遅延が導入され（十分な数のADUが送信側で収集されるまでバッファリングされるため）、パケット損失に対する堅牢性が低下することです。集約では、レシーバーでのバッファリング要件も発生します。
If the real-time media format has the property that it may produce ADUs that are larger than common MTU sizes, then fragmentation support should be considered. An RTP payload format may always fall back on IP fragmentation; however, as discussed in RFC 2736, this has some drawbacks. Perhaps the most important reason to avoid IP fragmentation is that IP fragmented packets commonly are discarded in the network, especially by NATs or firewalls. The usage of fragmentation at the RTP payload format level allows for more efficient usage of RTP packet loss recovery mechanisms. It may also in some cases also allow better usage of partial ADUs by doing media specific fragmentation at media-specific boundaries. In use cases where the ADUs are pre-produced and can't be adopted to the network's MTU size, support for fragmentation can be crucial.
リアルタイムメディアフォーマットに、一般的なMTUサイズよりも大きいADUが生成される可能性がある場合は、断片化のサポートを検討する必要があります。 RTPペイロード形式は常にIPフラグメンテーションにフォールバックする可能性があります。ただし、RFC 2736で説明されているように、これにはいくつかの欠点があります。おそらく、IPフラグメンテーションを回避する最も重要な理由は、IPフラグメント化されたパケットが、特にNATまたはファイアウォールによって、ネットワークで一般的に破棄されることです。 RTPペイロード形式レベルでフラグメンテーションを使用すると、RTPパケット損失回復メカニズムをより効率的に使用できます。また、場合によっては、メディア固有の境界でメディア固有の断片化を行うことにより、部分的なADUをより適切に使用することもできます。 ADUが事前に作成されており、ネットワークのMTUサイズに採用できないユースケースでは、フラグメンテーションのサポートが重要になる場合があります。
Interleaving has been implemented in a number of payload formats to allow for less quality reduction when packet loss occurs. When losses are bursty and several consecutive packets are lost, the impact on quality can be quite severe. Interleaving is used to convert that burst loss to several spread-out individual packet losses. It can also be used when several ADUs are aggregated in the same packets. A loss of an RTP packet with several ADUs in the payload has the same effect as a burst loss if the ADUs would have been transmitted in individual packets. To reduce the burstiness of the loss, the data present in an aggregated payload may be interleaved, thus, spreading the loss over a longer time period.
インターリービングは、パケット損失が発生した場合の品質低下を少なくするために、いくつかのペイロード形式で実装されています。損失が急増し、いくつかの連続するパケットが失われると、品質への影響は非常に深刻になります。インターリーブは、そのバースト損失をいくつかの個別のパケット損失に変換するために使用されます。複数のADUが同じパケットに集約されている場合にも使用できます。ペイロードに複数のADUがあるRTPパケットの損失は、ADUが個別のパケットで送信された場合のバースト損失と同じ効果があります。損失のバースト性を減らすために、集約されたペイロードに存在するデータをインターリーブして、損失をより長い時間に分散させることができます。
A requirement for doing interleaving within an RTP payload format is the aggregation of multiple ADUs. For formats that do not use aggregation, there is still a possibility of implementing a transmission order rescheduling mechanism. That has the effect that the packets transmitted consecutively originate from different points in the RTP stream. This can be used to mitigate burst losses, which may be useful if one transmits packets at frequent intervals. However, it may also be used to transmit more significant data earlier in combination with RTP retransmission to allow for more graceful degradation and increased possibility to receive the most important data, e.g., intra frames of video.
RTPペイロード形式内でインターリーブを行うための要件は、複数のADUの集約です。集約を使用しない形式の場合でも、送信順序の再スケジューリングメカニズムを実装する可能性があります。これには、連続して送信されるパケットがRTPストリームの異なるポイントから発信されるという効果があります。これは、バースト損失を軽減するために使用できます。これは、パケットを頻繁に送信する場合に役立ちます。ただし、RTP再送信と組み合わせてより重要なデータを早期に送信して、より適切な劣化とビデオのイントラフレームなどの最も重要なデータを受信する可能性を高めるためにも使用できます。
The drawback of interleaving is the significantly increased transmission buffering delay, making it less useful for low-delay applications. It may also create significant buffering requirements on the receiver. That buffering is also problematic, as it is usually difficult to indicate when a receiver may start consume data and still avoid buffer under run caused by the interleaving mechanism itself. Transmission rescheduling is only useful in a few specific cases, as in streaming with retransmissions. The potential gains must be weighed against the complexity of these schemes.
インターリーブの欠点は、伝送バッファリング遅延が大幅に増加することであり、低遅延アプリケーションにはあまり役立ちません。また、レシーバーに重要なバッファリング要件を作成する場合もあります。受信機がいつデータを消費し始めても、インターリーブメカニズム自体によって引き起こされる実行中のバッファを回避することは通常困難であるため、このバッファリングも問題があります。再送信を伴うストリーミングの場合のように、送信の再スケジュールは、いくつかの特定の場合にのみ役立ちます。潜在的な利益は、これらのスキームの複雑さと比較検討する必要があります。
A few RTP payload formats have implemented back channels within the media format. Those have been for specific features, like the AMR [RFC4867] codec mode request (CMR) field. The CMR field is used in the operation of gateways to circuit-switched voice to allow an IP terminal to react to the circuit-switched network's need for a specific encoder mode. A common motivation for media back channels is the need to have signaling in direct relation to the media or the media path.
いくつかのRTPペイロード形式は、メディア形式内にバックチャネルを実装しています。これらは、AMR [RFC4867]コーデックモード要求（CMR）フィールドなどの特定の機能用です。 CMRフィールドは、回線交換音声へのゲートウェイの動作で使用され、IP端末が特定のエンコーダモードに対する回線交換ネットワークのニーズに対応できるようにします。メディアバックチャネルの一般的な動機は、メディアまたはメディアパスに直接関係するシグナリングが必要なことです。
If back channels are considered for an RTP payload format they should be for a specific requirements which cannot be easily satisfied by more generic mechanisms within RTP or RTCP.
バックチャネルがRTPペイロード形式と見なされる場合、RTPまたはRTCP内のより一般的なメカニズムでは簡単に満たすことができない特定の要件に対応する必要があります。
Some codecs support various types of media scalability, i.e. some data of a RTP stream may be removed to adapt the media's properties, such as bitrate and quality. The adaptation may be applied in the following dimensions of the media:
一部のコーデックは、さまざまなタイプのメディアスケーラビリティをサポートします。つまり、RTPストリームの一部のデータは、ビットレートや品質などのメディアのプロパティを適合させるために削除される場合があります。適応は、メディアの次の次元に適用できます。
Temporal: For most video codecs it is possible to adapt the frame rate without any specific definition of a temporal scalability mode, e.g., for H.264 [RFC6184]. In these cases, the sender changes which frames it delivers and the RTP timestamp makes it clear the frame interval and each frames relative capture time. H.264 Scalable Video Coding (SVC) [RFC6190] has more explicit support for temporal scalability.
テンポラル：ほとんどのビデオコーデックでは、H.264 [RFC6184]など、時間スケーラビリティモードの特定の定義なしでフレームレートを適応させることが可能です。これらの場合、送信者は送信するフレームを変更し、RTPタイムスタンプにより、フレーム間隔と各フレームの相対キャプチャ時間をクリアします。 H.264スケーラブルビデオコーディング（SVC）[RFC6190]は、時間スケーラビリティをより明示的にサポートしています。
Spatial: Video codecs supporting scalability may adapt the resolution, e.g., in SVC [RFC6190].
空間：スケーラビリティをサポートするビデオコーデックは、たとえばSVC [RFC6190]で解像度を適応させることができます。
Quality: The quality of the encoded stream may be scaled by adapting the accuracy of the coding process, as, e.g. possible with Signal to Noise Ratio (SNR) fidelity scalability of SVC [RFC6190].
品質：エンコードされたストリームの品質は、たとえば、 SVCの信号対雑音比（SNR）の忠実度スケーラビリティ[RFC6190]で可能。
At the time of writing this document, codecs that support scalability have a bit of a revival. It has been realized that getting the required functionality for supporting the features of the media stream into the RTP framework is quite challenging. One of the recent examples for layered and scalable codecs is SVC [RFC6190].
このドキュメントを書いている時点で、スケーラビリティをサポートするコーデックは少し復活しています。メディアストリームの機能をサポートするために必要な機能をRTPフレームワークに取り込むのは非常に難しいことがわかっています。階層化されスケーラブルなコーデックの最近の例の1つはSVC [RFC6190]です。
SVC is a good example for a payload format supporting media scalability features, which have been in its basic form already included in RTP. A layered codec supports the dropping of data parts of a RTP stream, i.e., RTP packets may not be transmitted or forwarded to a client in order to adapt the RTP streams bitrate as well as the received encoded stream's quality, while still providing a decodable subset of the encoded stream to a client. One example for using the scalability feature may be an RTP Mixer (Multipoint Control Unit) [RFC7667], which controls the rate and quality sent out to participants in a communication based on dropping RTP packets or removing part of the payload. Another example may be a transport channel, which allows for differentiation in Quality of Service (QoS) parameters based on RTP sessions in a multicast session. In such a case, the more important packets of the scalable encoded stream (base layer) may get better QoS parameters than the less important packets (enhancement layer) in order to provide some kind of graceful degradation. The scalability features required for allowing an adaptive transport, as described in the two examples above, are based on RTP multiplexing in order to identify the packets to be dropped or transmitted/forwarded. The multiplexing features defined for Scalable Video Coding [RFC6190] are:
SVCは、メディアスケーラビリティ機能をサポートするペイロードフォーマットの良い例です。これは、RTPにすでに含まれている基本的な形式になっています。階層化されたコーデックは、RTPストリームのデータ部分のドロップをサポートします。つまり、RTPストリームは、RTPストリームのビットレートと受信したエンコードされたストリームの品質を適合させるためにクライアントに送信または転送されず、デコード可能なサブセットを提供できます。エンコードされたストリームをクライアントに送信します。スケーラビリティ機能を使用する1つの例は、RTPミキサー（マルチポイントコントロールユニット）[RFC7667]で、RTPパケットのドロップまたはペイロードの一部の削除に基づいて、通信の参加者に送信されるレートと品質を制御します。別の例は、マルチキャストセッションのRTPセッションに基づいてサービス品質（QoS）パラメータを区別できるトランスポートチャネルです。このような場合、スケーラブルなエンコードされたストリーム（ベースレイヤー）のより重要なパケットは、ある種の優雅な劣化を提供するために、それほど重要ではないパケット（拡張レイヤー）よりも優れたQoSパラメーターを取得できます。上記の2つの例で説明したように、アダプティブトランスポートを許可するために必要なスケーラビリティ機能は、ドロップまたは送信/転送されるパケットを識別するためのRTP多重化に基づいています。スケーラブルビデオコーディング[RFC6190]に定義されている多重化機能は次のとおりです。
Single Session Transmission (SST), where all media layers of the media are transported as a single synchronization source (SSRC) in a single RTP session; as well as
メディアのすべてのメディアレイヤーが単一のRTPセッションで単一の同期ソース（SSRC）として転送されるシングルセッション伝送（SST）。と同様
Multi-Session Transmission (MST), which should more accurately be called multi-stream transmission, where different media layers or a set of media layers are transported in different RTP streams, i.e., using multiple sources (SSRCs).
マルチセッション送信（MST）。より正確にマルチストリーム送信と呼ばれる必要があります。異なるメディアレイヤーまたはメディアレイヤーのセットが異なるRTPストリームで、つまり複数のソース（SSRC）を使用して転送されます。
In the first case (SST), additional in-band as well as out-of-band signaling is required in order to allow identification of packets belonging to a specific media layer. Furthermore, an adaptation of the encoded stream requires dropping of specific packets in order to provide the client with a compliant encoded stream. In case of using encryption, it is typically required for an adapting network device to be in the security context to allow packet dropping and providing an intact RTP session to the client. This typically requires the network device to be an RTP mixer.
最初のケース（SST）では、特定のメディア層に属するパケットの識別を可能にするために、帯域内および帯域外の追加のシグナリングが必要です。さらに、エンコードされたストリームの適応には、クライアントに準拠したエンコードされたストリームを提供するために、特定のパケットのドロップが必要です。暗号化を使用する場合、通常、適応するネットワークデバイスがセキュリティコンテキスト内にあり、パケットのドロップとクライアントへの完全なRTPセッションの提供を可能にする必要があります。これには通常、ネットワークデバイスがRTPミキサーである必要があります。
In general, having a media-unaware network device dropping excessive packets will be more problematic than having a Media-Aware Network Entity (MANE). First is the need to understand the media format and know which ADUs or payloads belong to the layers, that no other layer will be dependent on after the dropping. Second, if the MANE can work as an RTP mixer or translator, it can rewrite the RTP and RTCP in such a way that the receiver will not suspect unintentional RTP packet losses needing repair actions. This as the receiver can't determine if a lost packet was an important base layer packet or one of the less important extension layers.
一般に、メディアを認識しないネットワークデバイスが過剰なパケットをドロップすることは、メディアを認識するネットワークエンティティ（MANE）よりも問題が多くなります。 1つ目は、メディア形式を理解し、どのADUまたはペイロードがレイヤーに属しているかを知る必要があることです。ドロップ後に他のレイヤーが依存することはありません。第2に、MANEがRTPミキサーまたはトランスレーターとして機能できる場合は、RTPとRTCPを書き換えて、受信者が意図しないRTPパケットの損失を疑い、修復アクションを必要としないようにすることができます。これは、失われたパケットが重要なベースレイヤーパケットなのか、それともそれほど重要でない拡張レイヤーの1つなのかをレシーバーが判断できないためです。
In the second case (MST), the RTP packet streams can be sent using a single or multiple RTP session, and thus transport flows, e.g., on different multicast groups. Transmitting the streams in different RTP sessions, then the out-of-band signaling typically provides enough information to identify the media layers and its properties. The decision on dropping packets is based on the Network Address that identifies the RTP session to be dropped. In order to allow correct data provisioning to a decoder after reception from different sessions, data realignment mechanisms are required. In some cases, existing generic tools, as described below, can be employed to enable such realignment; when those generic mechanisms are sufficient, they should be used. For example, "Rapid Synchronisation for RTP Flows" [RFC6051], uses existing RTP mechanisms, i.e. the NTP timestamp, to ensure timely inter-session synchronization. Another is the signaling feature for indicating dependencies of RTP sessions in SDP, as defined in the Media Decoding Dependency Grouping in SDP [RFC5583].
2番目のケース（MST）では、RTPパケットストリームは、単一または複数のRTPセッションを使用して送信できるため、フローをトランスポートして、たとえば、異なるマルチキャストグループに送信できます。異なるRTPセッションでストリームを送信すると、通常、帯域外シグナリングは、メディアレイヤーとそのプロパティを識別するのに十分な情報を提供します。パケットをドロップするかどうかの決定は、ドロップするRTPセッションを識別するネットワークアドレスに基づいています。異なるセッションから受信した後、デコーダーへの正しいデータプロビジョニングを可能にするために、データ再調整メカニズムが必要です。以下に説明する既存の汎用ツールを使用して、このような再調整を可能にする場合もあります。これらの一般的なメカニズムで十分な場合は、それらを使用する必要があります。たとえば、「RTPフローの迅速な同期」[RFC6051]では、既存のRTPメカニズム、つまりNTPタイムスタンプを使用して、タイムリーなセッション間同期を保証します。もう1つは、SDPのMedia Decoding Dependency Grouping in SDP [RFC5583]で定義されている、SDPのRTPセッションの依存関係を示すシグナリング機能です。
Using MST within a single RTP session is also possible and allows stream level handling instead of looking deeper into the packets by a MANE. However, transport flow-level properties will be the same unless packet based mechanisms like Diffserv is used.
単一のRTPセッション内でMSTを使用することも可能であり、MANEがパケットをより深く調べる代わりに、ストリームレベルの処理を可能にします。ただし、Diffservなどのパケットベースのメカニズムを使用しない限り、トランスポートフローレベルのプロパティは同じです。
When QoS settings, e.g., Diffserv markings, are used to ensure that the extension layers are dropped prior the base layer the receiving endpoint has the benefit in MST to know which layer or set of layers the missing packets belong to as it will be bound to different RTP sessions or RTP packet streams (SSRCs), thus, explicitly indicating the importance of the loss.
QoS設定（Diffservマーキングなど）を使用して、拡張レイヤーがベースレイヤーの前に確実にドロップされるようにする場合、受信エンドポイントはMSTで、失われたパケットが属するレイヤーまたはレイヤーのセットが属するレイヤーを知ることができるという利点があります。異なるRTPセッションまたはRTPパケットストリーム（SSRC）。したがって、損失の重要性を明示的に示します。
Some media codecs require high packet rates; in these cases, the RTP sequence number wraps too quickly. As a rule of thumb, it must not be possible to wrap the sequence number space within at least three RTCP reporting intervals. As the reporting interval can vary widely due to configuration and session properties, and also must take into account the randomization of the interval, one can use the TCP maximum segment lifetime (MSL), i.e., 2 minutes, in ones consideration. If earlier wrapping may occur, then the payload format should specify an extended sequence number field to allow the receiver to determine where a specific payload belongs in the sequence, even in the face of extensive reordering. The RTP payload format for uncompressed video [RFC4175] can be used as an example for such a field.
一部のメディアコーデックでは、高いパケットレートが必要です。これらの場合、RTPシーケンス番号は非常に速く折り返します。経験則として、少なくとも3つのRTCPレポート間隔内でシーケンス番号スペースをラップすることはできません。レポートの間隔は、構成とセッションのプロパティにより大きく異なる可能性があり、間隔のランダム化も考慮する必要があるため、TCPの最大セグメント存続時間（MSL）、つまり2分を考慮に入れることができます。以前のラッピングが発生する可能性がある場合は、ペイロードのフォーマットで拡張シーケンス番号フィールドを指定して、大規模な並べ替えが行われた場合でも、レシーバーが特定のペイロードがシーケンスのどこに属するかを判別できるようにする必要があります。非圧縮ビデオのRTPペイロード形式[RFC4175]は、そのようなフィールドの例として使用できます。
RTCP is also affected by high packet rates. For RTCP mechanisms that do not use extended counters, there is significant risk that they wrap multiple times between RTCP reporting or feedback; thus, producing uncertainty about which packet(s) are referenced. The payload designer can't effect the RTCP packet formats used and their design, but can note this considerations when configuring RTCP bandwidth and reporting intervals to avoid to wrapping issues.
RTCPは、高いパケットレートの影響も受けます。拡張カウンターを使用しないRTCPメカニズムの場合、RTCPレポートまたはフィードバックの間に複数回ラップするという重大なリスクがあります。したがって、どのパケットが参照されるかについて不確実性が生じます。ペイロード設計者は、使用するRTCPパケット形式とその設計に影響を与えることはできませんが、RTCP帯域幅とレポート間隔を構成するときにこの問題に注意して、折り返しの問題を回避できます。
The RTP timestamp is an important part and has two design choices associated with it. The first is the definition that determines what the timestamp value in a particular RTP packet will be, the second is which timestamp rate should be used.
RTPタイムスタンプは重要な部分であり、それに関連する2つの設計上の選択肢があります。 1つ目は、特定のRTPパケットのタイムスタンプ値を決定する定義です。2つ目は、使用するタイムスタンプレートです。
The timestamp definition needs to explicitly define what the timestamp value in the RTP packet represent for a particular payload format. Two common definitions are used; for discretely sampled media, like video frames, the sampling time of the earliest included video frame which the data represent (fully or partially) is used; for continuous media like audio, the sampling time of the earliest sample which the payload data represent. There exist cases where more elaborate or other definitions are used.
タイムスタンプ定義は、RTPパケットのタイムスタンプ値が特定のペイロード形式を表すものを明示的に定義する必要があります。 2つの一般的な定義が使用されます。ビデオフレームのように個別にサンプリングされたメディアの場合、データが（完全にまたは部分的に）表す、含まれる最も古いビデオフレームのサンプリング時間が使用されます。オーディオなどの連続メディアの場合、ペイロードデータが表す最も早いサンプルのサンプリング時間。より精巧なまたは他の定義が使用される場合があります。
RTP payload formats with a timestamp definition that results in no or little correlation between the media time instance and its transmission time cause the RTCP jitter calculation to become unusable due to the errors introduced on the sender side. A common example is a payload format for a video codec where the RTP timestamp represents the capture time of the video frame, but frames are large enough that multiple RTP packets need to be sent for each frame spread across the framing interval. It should be noted whether or not the payload format has this property.
メディアタイムインスタンスとその伝送時間との間に相関がないかほとんどないタイムスタンプ定義のRTPペイロードフォーマットは、送信側で導入されたエラーが原因で、RTCPジッタの計算が使用できなくなる原因になります。一般的な例は、ビデオコーデックのペイロード形式です。RTPタイムスタンプはビデオフレームのキャプチャ時間を表しますが、フレームが十分に大きいため、フレーミング間隔全体に広がる各フレームに対して複数のRTPパケットを送信する必要があります。ペイロード形式にこのプロパティがあるかどうかに注意する必要があります。
An RTP payload format also needs to define what timestamp rates, or clock rates (as it is also called), may be used. Depending on the RTP payload format, this may be a single rate or multiple ones or theoretically any rate. So what needs to be considered when selecting a rate?
RTPペイロード形式では、使用できるタイムスタンプレートまたはクロックレート（別名）も定義する必要があります。 RTPペイロード形式に応じて、これは単一のレートまたは複数のレート、あるいは理論的には任意のレートになります。それでは、レートを選択するときに何を考慮する必要がありますか？
The rate needs be selected so that one can determine where in the time line of the media a particular sample (e.g., individual audio sample, or video frame) or set of samples (e.g., audio frames) belong. To enable correct synchronization of this data with previous frames, including over periods of discontinuous transmission or irregularities.
レートは、メディアのタイムラインで特定のサンプル（たとえば、個々のオーディオサンプル、またはビデオフレーム）またはサンプルのセット（たとえば、オーディオフレーム）が属する場所を決定できるように選択する必要があります。このデータを以前のフレームと正しく同期させるには、不連続な送信や不規則な期間を含めます。
For audio, it is common to require audio sample accuracy. Thus, one commonly selects the input sampling rate as the timestamp rate. This can, however, be challenging for audio codecs that support multiple different sampling frequencies, either as codec input or being used internally but effecting output, for example, frame duration. Depending on how one expects to use these different sampling rates one can allow multiple timestamp rates, each matching a particular codec input or sampling rate. However, due to the issues with using multiple different RTP timestamp rates for the same source (SSRC) [RFC7160], this should be avoided if one expects to need to switch between modes.
オーディオの場合、オーディオサンプルの精度が必要になるのが一般的です。したがって、一般に、タイムスタンプレートとして入力サンプリングレートを選択します。ただし、これは、コーデックの入力として、または内部で使用されているがフレームの継続時間などの出力に影響を与える、複数の異なるサンプリング周波数をサポートするオーディオコーデックにとっては困難な場合があります。これらの異なるサンプリングレートの使用方法に応じて、それぞれが特定のコーデック入力またはサンプリングレートに一致する複数のタイムスタンプレートを許可できます。ただし、同じソース（SSRC）[RFC7160]に対して複数の異なるRTPタイムスタンプレートを使用する場合の問題のため、モードを切り替える必要がある場合は、これを回避する必要があります。
Then, an alternative is to find a common denominator frequency between the different modes, e.g., OPUS [RFC7587] that uses 48 kHz. If the different modes uses or can use a common input/output frequency, then selecting this also needs to be considered. However, it is important to consider all aspects as the case of AMR-WB+ [RFC4352] illustrates. AMR-WB+'s RTP timestamp rate has the very unusual value of 72 kHz, despite the fact that output normally is at a sample rate of 48kHz. The design is motivated by the media codec's production of a large range of different frame lengths in time perspective. The 72 kHz timestamp rate is the smallest found value that would make all of the frames the codec could produce result in an integer frame length in RTP timestamp ticks. This way, a receiver can always correctly place the frames in relation to any other frame, even when the frame length changes. The downside is that the decoder outputs for certain frame lengths are, in fact, partial samples. The result is that the output in samples from the codec will vary from frame to frame, potentially making implementation more difficult.
次に、別の方法は、異なるモード間で共通の分母周波数を見つけることです。たとえば、48 kHzを使用するOPUS [RFC7587]です。異なるモードが共通の入力/出力周波数を使用する、または使用できる場合、これを選択することも考慮する必要があります。ただし、AMR-WB + [RFC4352]の場合が示すように、すべての側面を考慮することが重要です。 AMR-WB +のRTPタイムスタンプレートは、出力が通常48kHzのサンプルレートであるにもかかわらず、72kHzという非常に異常な値を持っています。この設計は、メディアコーデックが時間の観点から見たさまざまなフレーム長の幅広い範囲の制作を動機としています。 72 kHzのタイムスタンプレートは、コーデックがRTPタイムスタンプティックの整数フレーム長を生成する可能性があるすべてのフレームを作成する最小の検出値です。このようにして、フレーム長が変化した場合でも、レシーバーは常に他のフレームに対してフレームを正しく配置できます。欠点は、特定のフレーム長のデコーダー出力が実際には部分サンプルであることです。その結果、コーデックからのサンプルの出力はフレームごとに異なり、実装がより困難になる可能性があります。
Video codecs have commonly been using 90 kHz; the reason is this is a common denominator between the usually used frame rates such as 24, 25, 30, 50 and 60, and NTSC's odd 29.97 Hz. There does, however, exist at least one exception in the payload format for SMPTE 292M video [RFC3497] that uses a clock rate of 148.5 MHz. The reason here is that the timestamp then identify the exact start sample within a video frame.
ビデオコーデックは通常90 kHzを使用しています。これは、これが24、25、30、50、60などの通常使用されるフレームレートとNTSCの奇数29.97 Hzの間の共通の特徴であるためです。ただし、148.5 MHzのクロックレートを使用するSMPTE 292Mビデオ[RFC3497]のペイロード形式には、少なくとも1つの例外が存在します。ここでの理由は、タイムスタンプがビデオフレーム内の正確な開始サンプルを特定するためです。
Timestamp rates below 1000 Hz are not appropriate, because this will cause a resolution too low in the RTCP measurements that are expressed in RTP timestamps. This is the main reason that the text RTP payload formats, like T.140 [RFC4103], use 1000 Hz.
1000 Hz未満のタイムスタンプレートは、RTPタイムスタンプで表されるRTCP測定で解像度が低すぎるため、適切ではありません。これが、T.140 [RFC4103]のようなテキストRTPペイロード形式が1000 Hzを使用する主な理由です。
This section provides a few examples of payload formats that are worth noting for good or bad design in general or in specific details.
このセクションでは、一般的または特定の詳細で、設計の良し悪しを指摘する価値のあるペイロード形式の例をいくつか示します。
The AMR [RFC4867], AMR-WB [RFC4867], EVRC [RFC3558], SMV [RFC3558] payload formats are all quite similar. They are all for frame-based audio codecs and use a table of contents structure. Each frame has a table of contents entry that indicates the type of the frame and if additional frames are present. This is quite flexible, but produces unnecessary overhead if the ADU is of fixed size and if, when aggregating multiple ADUs, they are commonly of the same type. In that case, a solution like the one in AMR-WB+ [RFC4352] may be more suitable.
AMR [RFC4867]、AMR-WB [RFC4867]、EVRC [RFC3558]、SMV [RFC3558]のペイロード形式はすべて非常によく似ています。これらはすべてフレームベースのオーディオコーデック用で、目次構造を使用します。各フレームには、フレームのタイプと追加のフレームが存在するかどうかを示す目次エントリがあります。これは非常に柔軟性がありますが、ADUのサイズが固定されていて、複数のADUを集約するときに、それらが一般に同じタイプである場合、不要なオーバーヘッドが発生します。その場合、AMR-WB + [RFC4352]のようなソリューションの方が適している場合があります。
The RTP payload format for MIDI [RFC6295] contains some interesting features. MIDI is an audio format sensitive to packet losses, as the loss of a "note off" command will result in a note being stuck in an "on" state. To counter this, a recovery journal is defined that provides a summarized state that allows the receiver to recover from packet losses quickly. It also uses RTCP and the reported highest sequence number to be able to prune the state the recovery journal needs to contain. These features appear limited in applicability to media formats that are highly stateful and primarily use symbolic media representations.
MIDI [RFC6295]のRTPペイロード形式には、いくつかの興味深い機能が含まれています。 「ノートオフ」コマンドが失われるとノートが「オン」状態のままになるため、MIDIはパケット損失に敏感なオーディオ形式です。これに対抗するために、受信者がパケット損失から迅速に回復できるようにする要約された状態を提供する回復ジャーナルが定義されています。また、RTCPと報告された最も高いシーケンス番号を使用して、回復ジャーナルに含まれる必要がある状態を整理できます。これらの機能は、非常にステートフルであり、主にシンボリックメディア表現を使用するメディアフォーマットへの適用が制限されているように見えます。
There exists a security concern with variable bitrate audio and speech codecs that changes their payload length based on the input data. This can leak information, especially in structured communication like a speech recognition prompt service that asks people to enter information verbally. This issue also exists to some degree for discontinuous transmission as that allows the length of phrases to be determined. The issue is further discussed in "Guidelines for the Use of Variable Bit Rate Audio with Secure RTP" [RFC6562], which needs to be read by anyone writing an RTP payload format for an audio or speech codec with these properties.
入力データに基づいてペイロード長を変更する可変ビットレートオーディオおよび音声コーデックには、セキュリティ上の懸念があります。これは、特に人々に口頭で情報を入力するように求める音声認識プロンプトサービスのような構造化されたコミュニケーションで、情報を漏らす可能性があります。この問題は、フレーズの長さを決定できるようにするため、不連続送信の場合にもある程度存在します。この問題については、「セキュアRTPでの可変ビットレートオーディオの使用に関するガイドライン」[RFC6562]でさらに説明しています。これらは、これらのプロパティを持つオーディオまたは音声コーデック用のRTPペイロード形式を書く人が読む必要があります。
The definition of RTP payload formats for video has seen an evolution from the early ones such as H.261 [RFC4587] towards the latest for VP8 [RFC7741] and H.265/HEVC [RFC7798].
ビデオのRTPペイロード形式の定義は、H.261 [RFC4587]などの初期のものからVP8 [RFC7741]およびH.265 / HEVC [RFC7798]の最新のものへと進化しています。
The H.264 RTP payload format [RFC3984] can be seen as a smorgasbord of functionality: some of it, such as the interleaving, being pretty advanced. The reason for this was to ensure that the majority of applications considered by the ITU-T and MPEG that can be supported by RTP are indeed supported. This has created a payload format that rarely is fully implemented. Despite that, no major issues with interoperability has been reported with one exception namely the Offer/Answer and parameter signaling, which resulted in a revised specification [RFC6184]. However, complaints about its complexity are common.
H.264 RTPペイロード形式[RFC3984]は、機能のほんの一部と見なすことができます。インターリーブなど、その一部はかなり高度です。これは、RTPでサポートできるITU-TおよびMPEGで検討されているアプリケーションの大部分が実際にサポートされるようにするためです。これにより、ほとんど完全に実装されないペイロード形式が作成されました。それにもかかわらず、相互運用性に関する大きな問題は報告されていませんが、1つの例外、つまりオファー/アンサーとパラメーターシグナリングがあり、仕様が改訂されました[RFC6184]。ただし、その複雑さに関する不満はよく見られます。
The RTP payload format for uncompressed video [RFC4175] must be mentioned in this context as it contains a special feature not commonly seen in RTP payload formats. Due to the high bitrate and thus packet rate of uncompressed video (gigabits rather than megabits per second) the payload format includes a field to extend the RTP sequence number since the normal 16-bit one can wrap in less than a second. [RFC4175] also specifies a registry of different color sub-samplings that can be reused in other video RTP payload formats.
非圧縮ビデオのRTPペイロード形式[RFC4175]には、RTPペイロード形式では一般的に見られない特別な機能が含まれているため、このコンテキストで言及する必要があります。高いビットレート、したがって非圧縮ビデオのパケットレート（メガビット/秒ではなくギガビット）のため、ペイロード形式にはRTPシーケンス番号を拡張するフィールドが含まれています。通常の16ビットは1秒未満でラップできるためです。 [RFC4175]は、他のビデオRTPペイロード形式で再利用できるさまざまな色のサブサンプリングのレジストリも指定しています。
Both the H.264 and the uncompressed video format enable the implementer to fulfill the goals of application-level framing, i.e., each individual RTP Packet's payload can be independently decoded and its content used to create a video frame (or part of) and that irrespective of whether preceding packets has been lost (see Section 4) [RFC2736]. For uncompressed, this is straightforward as each pixel is independently represented from others and its location in the video frame known. H.264 is more dependent on the actual implementation, configuration of the video encoder and usage of the RTP payload format.
H.264と非圧縮ビデオ形式の両方により、実装者はアプリケーションレベルのフレーミングの目標を達成できます。つまり、個々のRTPパケットのペイロードを個別にデコードし、そのコンテンツを使用してビデオフレーム（またはその一部）を作成できます。前のパケットが失われたかどうかに関係なく（セクション4を参照）[RFC2736]。非圧縮の場合、各ピクセルは他のピクセルから独立して表され、ビデオフレーム内のその位置は既知であるため、これは簡単です。 H.264は、実際の実装、ビデオエンコーダーの構成、RTPペイロード形式の使用により依存しています。
The common challenge with video is that, in most cases, a single compressed video frame doesn't fit into a single IP packet. Thus, the compressed representation of a video frame needs to be split over multiple packets. This can be done unintelligently with a basic payload level fragmentation method or more integrated by interfacing with the encoder's possibilities to create ADUs that are independent and fit the MTU for the RTP packet. The latter is more robust and commonly recommended unless strong packet loss mechanisms are used and sufficient delay budget for the repair exist. Commonly, both payload-level fragmentation as well as explaining how tailored ADUs can be created are needed in a video payload format. Also, the handling of crucial metadata, like H.264 Parameter Sets, needs to be considered as decoding is not possible without receiving the used parameter sets.
ビデオの一般的な課題は、ほとんどの場合、単一の圧縮ビデオフレームが単一のIPパケットに収まらないことです。したがって、ビデオフレームの圧縮表現は、複数のパケットに分割する必要があります。これは、基本的なペイロードレベルのフラグメント化方法でインテリジェントに実行することも、エンコーダーの可能性と連動してRTPパケットのMTUに依存しない独立したADUを作成することにより、より統合的に行うこともできます。後者はより強力であり、強力なパケット損失メカニズムが使用され、修復に十分な遅延バジェットが存在しない限り、一般的に推奨されます。通常、ビデオペイロード形式では、ペイロードレベルの断片化と、調整されたADUの作成方法の説明の両方が必要です。また、H.264パラメータセットなどの重要なメタデータの処理は、使用済みのパラメータセットを受信しないとデコードできないため、考慮する必要があります。
Only a single format text format has been standardized in the IETF, namely T.140 [RFC4103]. The 3GPP Timed Text format [RFC4396] should be considered to be text, even though in the end was registered as a video format. It was registered in that part of the tree because it deals with decorated text, usable for subtitles and other embellishments of video. However, it has many of the properties that text formats generally have.
IETFで標準化されているのは、1つの形式のテキスト形式、つまりT.140 [RFC4103]だけです。 3GPP Timed Text形式[RFC4396]は、最終的にはビデオ形式として登録されていたとしても、テキストと見なす必要があります。ツリーのその部分に登録されたのは、字幕やビデオの他の装飾に使用できる装飾されたテキストを扱うためです。ただし、テキスト形式が一般的に持つ多くのプロパティがあります。
The RTP payload format for T.140 was designed with high reliability in mind as real-time text commonly is an extremely low bitrate application. Thus, it recommends the use of RFC 2198 with many generations of redundancy. However, the format failed to provide a text-block-specific sequence number and instead relies on the RTP one to detect loss. This makes detection of missing text blocks unnecessarily difficult and hinders deployment with other robustness mechanisms that would involve switching the payload type, as that may result in erroneous error marking in the T.140 text stream.
T.140のRTPペイロード形式は、リアルタイムテキストは一般に非常に低いビットレートアプリケーションであるため、高い信頼性を考慮して設計されています。したがって、多くの世代の冗長性を備えたRFC 2198の使用をお勧めします。ただし、この形式ではテキストブロック固有のシーケンス番号を提供できず、代わりにRTPを使用して損失を検出しました。これにより、欠落しているテキストブロックの検出が不必要に困難になり、ペイロードタイプの切り替えを伴う他の堅牢性メカニズムによる展開が妨げられます。これにより、T.140テキストストリームで誤ったエラーマーキングが発生する可能性があります。
At the time of writing, the application content type contains two media types that aren't RTP transport robustness tools such as FEC [RFC3009] [RFC5109] [RFC6015] [RFC6682] and RTP retransmission [RFC4588].
執筆時点では、アプリケーションコンテンツタイプには、FEC [RFC3009] [RFC5109] [RFC6015] [RFC6682]やRTP再送信[RFC4588]などのRTPトランスポートロバストネスツールではない2つのメディアタイプが含まれています。
The first one is H.224 [RFC4573], which enables far-end camera control over RTP. This is not an IETF-defined RTP format, only an IETF-performed registration.
1つ目はH.224 [RFC4573]で、RTPを介した遠端カメラ制御を可能にします。これは、IETF定義のRTP形式ではなく、IETFによって実行される登録のみです。
The second one is "RTP Payload Format for Society of Motion Picture and Television Engineers (SMPTE) ST 336 Encoded Data" [RFC6597], which carries generic key length value (KLV) triplets. These pairs may contain arbitrary binary metadata associated with video transmissions. It has a very basic fragmentation mechanism requiring reception without packet loss, not only of the triplet itself but also one packet before and after the sequence of fragmented KLV triplet, to ensure correct reception. Specific KLV triplets themselves may have recommendations on how to handle incomplete ones allowing the use and repair of them. In general, the application using such a mechanism must be robust to errors and also use some combination of application-level repetition, RTP-level transport robustness tools, and network-level requirements to achieve low levels of packet loss rates and repair of KLV triplets.
2つ目は、「Social for Motion Picture and Television Engineers（SMPTE）ST 336 Encoded DataのRTPペイロード形式」[RFC6597]で、これは一般的なキー長値（KLV）トリプレットを伝送します。これらのペアには、ビデオ送信に関連する任意のバイナリメタデータが含まれる場合があります。これには、トリプレット自体だけでなく、フラグメント化されたKLVトリプレットのシーケンスの前後の1つのパケットもパケット損失なしで受信する必要がある非常に基本的なフラグメンテーションメカニズムがあり、正しい受信を保証します。特定のKLVトリプレット自体は、不完全なものを処理および使用できるようにする方法に関する推奨事項を持っている場合があります。一般に、このようなメカニズムを使用するアプリケーションは、エラーに対して堅牢でなければならず、アプリケーションレベルの繰り返し、RTPレベルのトランスポートの堅牢性ツール、およびネットワークレベルの要件を組み合わせて使用して、低レベルのパケット損失率とKLVトリプレットの修復を実現する必要があります。 。
An author should consider applying for a media subtype under the application media type (application/<foo>) when the payload format is of a generic nature or does not clearly match any of the media types described above (audio, video, or text). However, existing limitations in, for example, SDP, have resulted in generic mechanisms normally registered in all media types possibly having been associated with any existing media types in an RTP session.
ペイロード形式が一般的な性質のものであるか、上記のメディアタイプ（オーディオ、ビデオ、またはテキスト）のいずれにも明確に一致しない場合、作成者はアプリケーションメディアタイプ（application / <foo>）の下にメディアサブタイプを申請することを検討する必要があります。 。ただし、SDPなどの既存の制限により、すべてのメディアタイプに通常登録されている汎用メカニズムがRTPセッションの既存のメディアタイプに関連付けられている可能性があります。
A number of sections in the payload format draft need special consideration. These include the Security Considerations and IANA Considerations sections that are required in all drafts. Payload formats are also strongly recommended to have the media format description and congestion control considerations. The included RTP payload format template (Appendix A) contains sample text for some of these sections.
ペイロード形式草案のいくつかのセクションには、特別な考慮が必要です。これらには、すべてのドラフトで必要なセキュリティの考慮事項とIANAの考慮事項のセクションが含まれます。メディアフォーマットの説明と輻輳制御の考慮事項を検討するために、ペイロードフォーマットも強く推奨されます。含まれているRTPペイロード形式テンプレート（付録A）には、これらのセクションの一部のサンプルテキストが含まれています。
The intention of this section is to enable reviewers and other readers to get an overview of the capabilities and major properties of the media format. It should be kept short and concise and is not a complete replacement for reading the media format specification.
このセクションの目的は、レビュー担当者やその他の読者がメディア形式の機能と主要なプロパティの概要を理解できるようにすることです。これは短く簡潔にする必要があり、メディア形式の仕様を読むための完全な代替ではありません。
The actual specification of the RTP payload format generally uses normative references to the codec format specification to define how codec data elements are included in the payload format. This normative reference can be to anything that have sufficient stability for a normative reference. There exist no formal requirement on the codec format specification being publicly available or free to access. However, it significantly helps in the review process if that specification is made available to any reviewer. There exist RTP payload format RFCs for open-source project specifications as well as an individual company's proprietary format, and a large variety of standards development organizations or industrial forums.
RTPペイロード形式の実際の仕様では、通常、コーデック形式仕様への規範的な参照を使用して、コーデックデータ要素をペイロード形式に含める方法を定義します。この規範的参照は、規範的参照に対して十分な安定性を持つものであれば何でも可能です。コーデック形式の仕様が公に利用可能または自由にアクセスできるという正式な要件はありません。ただし、レビュー担当者がその仕様を利用できるようにすると、レビュープロセスに大きく役立ちます。オープンソースプロジェクト仕様のRTPペイロード形式のRFCだけでなく、個々の会社の独自の形式や、さまざまな標準開発組織や産業フォーラムが存在します。
All Internet-Drafts require a Security Considerations section. The Security Considerations section in an RTP payload format needs to concentrate on the security properties this particular format has. Some payload formats have very few specific issues or properties and can fully fall back on the security considerations for RTP in general and those of the profile being used. Because those documents are always applicable, a reference to these is normally placed first in the Security Considerations section. There is suggested text in the template below.
すべてのインターネットドラフトには、セキュリティに関する考慮事項のセクションが必要です。 RTPペイロード形式の「セキュリティに関する考慮事項」セクションでは、この特定の形式が持つセキュリティプロパティに集中する必要があります。一部のペイロード形式には、特定の問題やプロパティがほとんどなく、RTPの一般的なセキュリティ上の考慮事項と、使用されているプロファイルのセキュリティ上の考慮事項に完全に頼ることができます。これらのドキュメントは常に適用可能であるため、これらへの参照は通常、セキュリティに関する考慮事項セクションの最初に配置されます。以下のテンプレートに推奨テキストがあります。
The security issues of confidentiality, integrity protection, replay protection and source authentication are common issue for all payload formats. These should be solved by mechanisms external to the payload and do not need any special consideration in the payload format except for a reminder on these issues. There exist exceptions, such as payload formats that includes security functionality, like ISMAcrypt [ISMACrypt2]. Reasons for this division is further documented in "Securing the RTP Protocol Framework: Why RTP Does Not Mandate a Single Media Security Solution" [RFC7202]. For a survey of available mechanisms to meet these goals, review "Options for Securing RTP Sessions" [RFC7201]. This also includes key-exchange mechanisms for the security mechanisms, which can be both integrated or separate. The choice of key-management can have significant impact on the security properties of the RTP-based application. Suitable stock text to inform people about this is included in the template.
機密性、完全性保護、リプレイ保護、ソース認証のセキュリティ問題は、すべてのペイロード形式に共通の問題です。これらは、ペイロードの外部のメカニズムによって解決する必要があり、これらの問題に関するリマインダーを除いて、ペイロード形式で特別な考慮をする必要はありません。 ISMAcrypt [ISMACrypt2]などのセキュリティ機能を含むペイロード形式などの例外が存在します。この分割の理由については、「RTPプロトコルフレームワークのセキュリティ保護：RTPが単一のメディアセキュリティソリューションを義務付けない理由」[RFC7202]で詳しく説明されています。これらの目標を達成するために利用可能なメカニズムの調査については、「RTPセッションを保護するためのオプション」[RFC7201]を確認してください。これには、セキュリティメカニズムのキー交換メカニズムも含まれます。これらは、統合することも分離することもできます。キー管理の選択は、RTPベースのアプリケーションのセキュリティプロパティに大きな影響を与える可能性があります。これについて人々に知らせるのに適したストックテキストがテンプレートに含まれています。
Potential security issues with an RTP payload format and the media encoding that need to be considered if they are applicable:
RTPペイロード形式とメディアエンコーディングの潜在的なセキュリティ問題は、それらが該当する場合に考慮する必要があります。
1. The decoding of the payload format or its media results in substantial non-uniformity, either in output or in complexity to perform the decoding operation. For example, a generic non-destructive compression algorithm may provide an output of almost an infinite size for a very limited input, thus consuming memory or storage space out of proportion with what the receiving application expected. Such inputs can cause some sort of disruption, i.e., a denial-of-service attack on the receiver side by preventing that host from performing usable work. Certain decoding operations may also vary in the amount of processing needed to perform those operations depending on the input. This may also be a security risk if it is possible to raise processing load significantly above nominal simply by designing a malicious input sequence. If such potential attacks exist, this must be made clear in the Security Considerations section to make implementers aware of the need to take precautions against such behavior.
１．ペイロードフォーマットまたはそのメディアの復号は、復号動作を実行するための出力または複雑さのいずれかにおいて、実質的な不均一性をもたらす。たとえば、一般的な非破壊圧縮アルゴリズムは、非常に限られた入力に対してほぼ無限のサイズの出力を提供する可能性があり、受信アプリケーションが期待するものと比例してメモリまたはストレージ領域を消費します。そのような入力は、そのホストが使用可能な作業を実行できないようにすることにより、受信側での一種の混乱、つまりサービス拒否攻撃を引き起こす可能性があります。特定の復号化操作では、入力に応じて、これらの操作を実行するために必要な処理量も異なります。悪意のある入力シーケンスを設計するだけで処理負荷を公称値を大幅に超える可能性がある場合、これはセキュリティリスクになることもあります。そのような潜在的な攻撃が存在する場合は、「セキュリティに関する考慮事項」セクションでこれを明確にして、そのような動作に対して予防策を講じる必要があることを実装者に知らせる必要があります。
2. The inclusion of active content in the media format or its transport. "Active content" means scripts, etc., that allow an attacker to perform potentially arbitrary operations on the receiver. Most active contents has limited possibility to access the system or perform operations outside a protected sandbox. RFC 4855 [RFC4855] has a requirement that it be noted in the media types registration whether or not the payload format contains active content. If the payload format has active content, it is strongly recommended that references to any security model applicable for such content are provided. A boilerplate text for "no active content" is included in the template. This must be changed if the format actually carries active content.
2. メディア形式またはそのトランスポートにアクティブコンテンツを含める。 「アクティブコンテンツ」とは、攻撃者が受信者に対して任意の操作を実行できるようにするスクリプトなどを意味します。ほとんどのアクティブコンテンツは、システムにアクセスしたり、保護されたサンドボックスの外で操作を実行したりする可能性が限られています。 RFC 4855 [RFC4855]には、ペイロード形式にアクティブコンテンツが含まれているかどうかに関係なく、メディアタイプの登録で注記する必要があります。ペイロード形式にアクティブなコンテンツがある場合は、そのようなコンテンツに適用可能なセキュリティモデルへの参照を提供することを強くお勧めします。 「アクティブコンテンツなし」のボイラープレートテキストがテンプレートに含まれています。形式が実際にアクティブコンテンツを運ぶ場合は、これを変更する必要があります。
3. Some media formats allow for the carrying of "user data", or types of data which are not known at the time of the specification of the payload format. Such data may be a security risk and should be mentioned.
3. 一部のメディア形式では、「ユーザーデータ」、またはペイロード形式の仕様の時点ではわかっていないデータの種類を運ぶことができます。このようなデータはセキュリティリスクとなる可能性があるため、言及する必要があります。
4. Audio or Speech codecs supporting variable bitrate based on 'audio/speech' input or having discontinuous transmission support must consider the issues discussed in "Guidelines for the Use of Variable Bit Rate Audio with Secure RTP" [RFC6562].
4. 「オーディオ/スピーチ」入力に基づく可変ビットレートをサポートする、または不連続送信をサポートするオーディオまたは音声コーデックは、「Secure RTPでの可変ビットレートオーディオの使用に関するガイドライン」[RFC6562]で説明されている問題を考慮する必要があります。
Suitable stock text for the Security Considerations section is provided in the template in Appendix A. However, authors do need to actively consider any security issues from the start. Failure to address these issues may block approval and publication.
「セキュリティに関する考慮事項」セクションの適切なストックテキストは、付録Aのテンプレートに記載されています。ただし、作成者は最初からセキュリティの問題を積極的に検討する必要があります。これらの問題に対処しないと、承認と公開がブロックされる可能性があります。
RTP and its profiles do discuss congestion control. There is ongoing work in the IETF with both a basic circuit-breaker mechanism [RFC8083] using basic RTCP messages intended to prevent persistent congestion and also work on more capable congestion avoidance / bitrate adaptation mechanism in the RMCAT WG.
RTPとそのプロファイルでは、輻輳制御について説明しています。 IETFでは、継続的な輻輳を防止することを目的とした基本的なRTCPメッセージを使用する基本的なサーキットブレーカーメカニズム[RFC8083]と、RMCAT WGのより有能な輻輳回避/ビットレート適応メカニズムの両方で作業が進行中です。
Congestion control is an important issue in any usage in networks that are not dedicated. For that reason, it is recommended that all RTP payload format documents discuss the possibilities that exist to regulate the bitrate of the transmissions using the described RTP payload format. Some formats may have limited or step-wise regulation of bitrate. Such limiting factors should be discussed.
輻輳制御は、専用ではないネットワークでの使用において重要な問題です。そのため、すべてのRTPペイロード形式のドキュメントで、説明されているRTPペイロード形式を使用して送信のビットレートを規制するために存在する可能性について説明することをお勧めします。一部の形式では、ビットレートが制限されているか、段階的に調整されている場合があります。このような制限要因についても検討する必要があります。
Since all RTP payload formats contain a media type specification, they also need an IANA Considerations section. The media type name must be registered, and this is done by requesting that IANA register that media name. When that registration request is written, it shall also be requested that the media type is included under the "RTP Payload Format media types" subregistry of the RTP registry (http://www.iana.org/assignments/rtp-parameters).
すべてのRTPペイロード形式にはメディアタイプの仕様が含まれているため、IANAに関する考慮事項セクションも必要です。メディアタイプ名を登録する必要があります。これを行うには、IANAにそのメディア名を登録するように要求します。その登録要求が記述されるとき、メディアタイプがRTPレジストリの「RTP Payload Formatメディアタイプ」サブレジストリ（http://www.iana.org/assignments/rtp-parameters）に含まれていることも要求されます。
Parameters for the payload format need to be included in this registration and can be specified as required or optional ones. The format of these parameters should be such that they can be included in the SDP attribute "a=fmtp" string (see Section 6 [RFC4566]), which is the common mapping. Some parameters, such as "Channel" are normally mapped to the rtpmap attribute instead; see Section 3 of [RFC4855].
ペイロード形式のパラメーターは、この登録に含める必要があり、必須またはオプションのパラメーターとして指定できます。これらのパラメーターの形式は、一般的なマッピングであるSDP属性「a = fmtp」文字列（セクション6 [RFC4566]を参照）に含めることができるような形式にする必要があります。 「チャネル」などの一部のパラメーターは通常、代わりにrtpmap属性にマップされます。 [RFC4855]のセクション3をご覧ください。
In addition to the above request for media type registration, some payload formats may have parameters where, in the future, new parameter values need to be added. In these cases, a registry for that parameter must be created. This is done by defining the registry in the IANA Considerations section. BCP 26 [BCP26] provides guidelines to specifying such registries. Care should be taken when defining the policy for new registrations.
上記のメディアタイプ登録のリクエストに加えて、一部のペイロード形式にはパラメータが含まれる場合があり、将来、新しいパラメータ値を追加する必要があります。これらの場合、そのパラメーターのレジストリーを作成する必要があります。これは、IANAの考慮事項セクションでレジストリを定義することによって行われます。 BCP 26 [BCP26]は、そのようなレジストリを指定するためのガイドラインを提供します。新規登録のポリシーを定義するときは注意が必要です。
Before specifying a new registry, it is worth checking the existing ones in the IANA "MIME Media Type Sub-Parameter Registries". For example, video formats that need a media parameter expressing color sub-sampling may be able to reuse those defined for 'video/raw' [RFC4175].
新しいレジストリを指定する前に、IANAの「MIME Media Type Sub-Parameter Registry」で既存のレジストリを確認することをお勧めします。たとえば、カラーサブサンプリングを表現するメディアパラメータを必要とするビデオ形式は、「ビデオ/生」[RFC4175]に定義されたものを再利用できる場合があります。
This section provides information about some tools that may be used. Don't feel pressured to follow these recommendations. There exist a number of alternatives, including the ones listed at <http://tools.ietf.org>. But these suggestions are worth checking out before deciding that the grass is greener somewhere else.
このセクションでは、使用できるいくつかのツールについて説明します。これらの推奨事項に従うようにプレッシャーを感じないでください。 <http://tools.ietf.org>にリストされているものを含め、いくつかの代替案が存在します。しかし、これらの提案は、芝生が他のどこかでより緑が良いと判断する前に確認する価値があります。
Note that these options are related to the old text only RFC format, and do not cover tools for at the time of publication recently approved new RFC format, see [RFC7990].
これらのオプションは古いテキストのみのRFC形式に関連しており、公開時に最近承認された新しいRFC形式のツールは対象外であることに注意してください。[RFC7990]を参照してください。
There are many choices when it comes to tools to choose for authoring Internet-Drafts. However, in the end, they need to be able to produce a draft that conforms to the Internet-Draft requirements. If you don't have any previous experience with authoring Internet-Drafts, xml2rfc does have some advantages. It helps by creating a lot of the necessary boilerplate in accordance with the latest rules, thus reducing the effort. It also speeds up publication after approval as the RFC Editor can use the source XML document to produce the RFC more quickly.
インターネットドラフトを作成するために選択するツールに関しては、多くの選択肢があります。ただし、最終的には、インターネットドラフトの要件に準拠するドラフトを作成できる必要があります。 Internet-Draftsのオーサリングの経験がない場合、xml2rfcにはいくつかの利点があります。最新のルールに従って必要なボイラープレートをたくさん作成することで、労力を削減できます。また、RFCエディターはソースXMLドキュメントを使用してRFCをより迅速に作成できるため、承認後の公開も高速化されます。
Another common choice is to use Microsoft Word and a suitable template (see [RFC5385]) to produce the draft and print that to file using the generic text printer. It has some advantages when it comes to spell checking and change bars. However, Word may also produce some problems, like changing formatting, and inconsistent results between what one sees in the editor and in the generated text document, at least according to the author's personal experience.
別の一般的な選択肢は、Microsoft Wordと適切なテンプレート（[RFC5385]を参照）を使用してドラフトを作成し、汎用テキストプリンターを使用してファイルに印刷することです。スペルチェックとバーの変更に関しては、いくつかの利点があります。ただし、少なくとも作成者の個人的な経験によれば、Wordでは、書式の変更や、エディターと生成されたテキストドキュメントの表示に一貫性のない結果などの問題が発生する場合もあります。
There are a few tools that are very good to know about when writing a draft. These help check and verify parts of one's work. These tools can be found at <http://tools.ietf.org>.
下書きを作成するときに知っておくと便利なツールがいくつかあります。これらは、自分の仕事の一部をチェックおよび検証するのに役立ちます。これらのツールは<http://tools.ietf.org>にあります。
o I-D Nits checker (https://tools.ietf.org/tools/idnits/). It checks that the boilerplate and some other things that are easily verifiable by machine are okay in your draft. Always use it before submitting a draft to avoid direct refusal in the submission step.
o I-D Nitsチェッカー（https://tools.ietf.org/tools/idnits/）。ボイラープレートなど、機械で簡単に確認できるものはドラフトで問題ないことを確認します。提出ステップでの直接の拒否を回避するために、ドラフトを提出する前に必ずそれを使用してください。
o ABNF Parser and verification (https://tools.ietf.org/tools/bap/ abnf.cgi). Checks that your ABNF parses correctly and warns about loose ends, like undefined symbols. However, the actual content can only be verified by humans knowing what it intends to describe.
o ABNFパーサーと検証（https://tools.ietf.org/tools/bap/ abnf.cgi）。 ABNFが正しく解析され、未定義のシンボルなどの不完全な終端について警告することを確認します。ただし、実際のコンテンツを検証できるのは、それが何を記述しようとしているのかを知っている人間だけです。
o RFC diff (https://tools.ietf.org/rfcdiff). A diff tool that is optimized for drafts and RFCs. For example, it does not point out that the footer and header have moved in relation to the text on every page.
o RFC diff（https://tools.ietf.org/rfcdiff）。ドラフトおよびRFC向けに最適化された差分ツール。たとえば、フッターとヘッダーがすべてのページのテキストに関連して移動したことを指摘していません。
As this is an Informational RFC about writing drafts that are intended to become RFCs, there are no direct security considerations. However, the document does discuss the writing of Security Considerations sections and what should be particularly considered when specifying RTP payload formats.
これはRFCになることを目的としたドラフトの作成に関する情報RFCであるため、セキュリティに関する直接の考慮事項はありません。ただし、このドキュメントでは、セキュリティに関する考慮事項のセクションの記述と、RTPペイロード形式を指定するときに特に考慮すべき事項について説明しています。
[BCP9] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[BCP9] Bradner、S.、「インターネット標準プロセス-リビジョン3」、BCP 9、RFC 2026、1996年10月。
Kolkman, O., Bradner, S., and S. Turner, "Characterization of Proposed Standards", BCP 9, RFC 7127, January 2014.
Kolkman、O.、Bradner、S。、およびS. Turner、「Characterization of Proposed Standards」、BCP 9、RFC 7127、2014年1月。
Dusseault, L. and R. Sparks, "Guidance on Interoperation and Implementation Reports for Advancement to Draft Standard", BCP 9, RFC 5657, September 2009.
Dusseault、L.およびR. Sparks、「相互運用に関するガイダンスおよびドラフト標準への移行に関する実装レポート」、BCP 9、RFC 5657、2009年9月。
Housley, R., Crocker, D., and E. Burger, "Reducing the Standards Track to Two Maturity Levels", BCP 9, RFC 6410, October 2011.
Housley、R.、Crocker、D。、およびE. Burger、「Reducing the Standards Track to Two Maturity Levels」、BCP 9、RFC 6410、2011年10月。
Resnick, P., "Retirement of the "Internet Official Protocol Standards" Summary Document", BCP 9, RFC 7100, December 2013.
Resnick、P。、「「インターネット公式プロトコル標準」要約文書の廃止」、BCP 9、RFC 7100、2013年12月。
Dawkins, S., "Increasing the Number of Area Directors in an IETF Area", BCP 9, RFC 7475, March 2015.
Dawkins、S。、「IETFエリアのエリアディレクター数の増加」、BCP 9、RFC 7475、2015年3月。
<http://www.rfc-editor.org/info/bcp9>
[BCP25] Wasserman, M., "Updates to RFC 2418 Regarding the Management of IETF Mailing Lists", BCP 25, RFC 3934, October 2004.
[BCP25] Wasserman、M。、「IETFメーリングリストの管理に関するRFC 2418の更新」、BCP 25、RFC 3934、2004年10月。
Bradner, S., "IETF Working Group Guidelines and Procedures", BCP 25, RFC 2418, September 1998.
Bradner、S。、「IETF Working Group Guidelines and Procedures」、BCP 25、RFC 2418、1998年9月。
Resnick, P. and A. Farrel, "IETF Anti-Harassment Procedures", BCP 25, RFC 7776, March 2016.
Resnick、P。およびA. Farrel、「IETF嫌がらせ手続き」、BCP 25、RFC 7776、2016年3月。
<http://www.rfc-editor.org/info/bcp25>
[BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008, <http://www.rfc-editor.org/info/bcp26>.
[BCP26] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月、<http://www.rfc-editor.org/info/bcp26> 。
[BCP78] Bradner, S., Ed. and J. Contreras, Ed., "Rights Contributors Provide to the IETF Trust", BCP 78, RFC 5378, November 2008, <http://www.rfc-editor.org/info/bcp78>.
[BCP78]ブラドナー、S。、エド。およびJ. Contreras編、「IETFトラストに提供する権利の貢献者」、BCP 78、RFC 5378、2008年11月、<http://www.rfc-editor.org/info/bcp78>。
[BCP79] Bradner, S., Ed., "Intellectual Property Rights in IETF Technology", BCP 79, RFC 3979, March 2005.
[BCP79] Bradner、S。、編、「IETFテクノロジーの知的財産権」、BCP 79、RFC 3979、2005年3月。
Narten, T., "Clarification of the Third Party Disclosure Procedure in RFC 3979", BCP 79, RFC 4879, April 2007.
ナルテン、T。、「RFC 3979での第三者開示手続きの明確化」、BCP 79、RFC 4879、2007年4月。
<http://www.rfc-editor.org/info/bcp79>
[BLOAT] Nichols, K. and V. Jacobson, "Controlling Queue Delay", ACM Networks, Vol. 10, No. 5, DOI 10.1145/2208917.2209336, May 2012, <http://queue.acm.org/detail.cfm?id=2209336>.
[BLOAT] Nichols、K。およびV. Jacobson、「Controlling Queue Delay」、ACM Networks、Vol。 10、No。5、DOI 10.1145 / 2208917.2209336、2012年5月、<http://queue.acm.org/detail.cfm?id=2209336>。
[CSP-RTP] Perkins, C., "RTP: Audio and Video for the Internet", Addison-Wesley Professional, ISBN 0-672-32249-8, June 2003.
[CSP-RTP]パーキンス、C。、「RTP：インターネット用オーディオおよびビデオ」、Addison-Wesley Professional、ISBN 0-672-32249-8、2003年6月。
[ID-GUIDE] Housley, R., "Guidelines to Authors of Internet-Drafts", December 2010, <http://www.ietf.org/id-info/guidelines.html>.
[IDガイド] Housley、R。、「インターネットドラフトの作成者へのガイドライン」、2010年12月、<http://www.ietf.org/id-info/guidelines.html>。
[ISMACrypt2] Internet Streaming Media Alliance (ISMA), "ISMA Encryption and Authentication, Version 2.0 release version", November 2007, <http://www.oipf.tv/docs/mpegif/isma_easpec2.0.pdf>.
[ISMACrypt2]インターネットストリーミングメディアアライアンス（ISMA）、「ISMA暗号化および認証、バージョン2.0リリースバージョン」、2007年11月、<http://www.oipf.tv/docs/mpegif/isma_easpec2.0.pdf>。
[RED] Floyd, S. and V. Jacobson, "Random Early Detection (RED) gateways for Congestion Avoidance", IEEE/ACM Transactions on Networking 1(4) 397--413, August 1993, <http://www.aciri.org/floyd/papers/early.pdf>.
[RED] Floyd、S。およびV. Jacobson、「Random Early Detection（RED）gateways for Congestion Avoidance」、IEEE / ACM Transactions on Networking 1（4）397--413、1993年8月、<http：// www。 aciri.org/floyd/papers/early.pdf>。
[RFC1633] Braden, R., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, DOI 10.17487/RFC1633, June 1994, <http://www.rfc-editor.org/info/rfc1633>.
[RFC1633] Braden、R.、Clark、D。、およびS. Shenker、「Integrated Services in the Internet Architecture：a Overview」、RFC 1633、DOI 10.17487 / RFC1633、1994年6月、<http：//www.rfc- editor.org/info/rfc1633>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse-Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, DOI 10.17487/RFC2198, September 1997, <http://www.rfc-editor.org/info/rfc2198>.
[RFC2198]パーキンス、C。、クーベラス、I。、ホドソン、O。、ハードマン、V。、ハンドラリー、M。、ボロ、J。、ベガガルシア、A。、およびS.フォッセ-パリシス、「RTPペイロードfor Redundant Audio Data」、RFC 2198、DOI 10.17487 / RFC2198、1997年9月、<http://www.rfc-editor.org/info/rfc2198>。
[RFC2360] Scott, G., "Guide for Internet Standards Writers", BCP 22, RFC 2360, DOI 10.17487/RFC2360, June 1998, <http://www.rfc-editor.org/info/rfc2360>.
[RFC2360] Scott、G。、「Guide for Internet Standards Writers」、BCP 22、RFC 2360、DOI 10.17487 / RFC2360、1998年6月、<http://www.rfc-editor.org/info/rfc2360>。
[RFC2418] Bradner, S., "IETF Working Group Guidelines and Procedures", BCP 25, RFC 2418, DOI 10.17487/RFC2418, September 1998, <http://www.rfc-editor.org/info/rfc2418>.
[RFC2418] Bradner、S。、「IETF Working Group Guidelines and Procedures」、BCP 25、RFC 2418、DOI 10.17487 / RFC2418、1998年9月、<http://www.rfc-editor.org/info/rfc2418>。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, <http://www.rfc-editor.org/info/rfc2475>.
[RFC2475] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z.、and W. Weiss、 "An Architecture for Differentiated Services"、RFC 2475、DOI 10.17487 / RFC2475、December 1998、<http://www.rfc-editor.org/info/rfc2475>。
[RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, DOI 10.17487/RFC2508, February 1999, <http://www.rfc-editor.org/info/rfc2508>.
[RFC2508] Casner、S。およびV. Jacobson、「Compressing IP / UDP / RTP headers for Low-Speed Serial Links」、RFC 2508、DOI 10.17487 / RFC2508、1999年2月、<http：//www.rfc-editor。 org / info / rfc2508>。
[RFC2733] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format for Generic Forward Error Correction", RFC 2733, DOI 10.17487/RFC2733, December 1999, <http://www.rfc-editor.org/info/rfc2733>.
[RFC2733] Rosenberg、J。およびH. Schulzrinne、「Generic Forward Error CorrectionのRTPペイロードフォーマット」、RFC 2733、DOI 10.17487 / RFC2733、1999年12月、<http://www.rfc-editor.org/info/ rfc2733>。
[RFC2736] Handley, M. and C. Perkins, "Guidelines for Writers of RTP Payload Format Specifications", BCP 36, RFC 2736, DOI 10.17487/RFC2736, December 1999, <http://www.rfc-editor.org/info/rfc2736>.
[RFC2736] Handley、M。およびC. Perkins、「RTPペイロード形式仕様の作成者のためのガイドライン」、BCP 36、RFC 2736、DOI 10.17487 / RFC2736、1999年12月、<http://www.rfc-editor.org/ info / rfc2736>。
[RFC2959] Baugher, M., Strahm, B., and I. Suconick, "Real-Time Transport Protocol Management Information Base", RFC 2959, DOI 10.17487/RFC2959, October 2000, <http://www.rfc-editor.org/info/rfc2959>.
[RFC2959] Baugher、M.、Strahm、B。、およびI. Suconick、「Real-Time Transport Protocol Management Information Base」、RFC 2959、DOI 10.17487 / RFC2959、2000年10月、<http：//www.rfc-editor .org / info / rfc2959>。
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, DOI 10.17487/RFC2974, October 2000, <http://www.rfc-editor.org/info/rfc2974>.
[RFC2974] Handley、M.、Perkins、C。、およびE. Whelan、「Session Announcement Protocol」、RFC 2974、DOI 10.17487 / RFC2974、2000年10月、<http://www.rfc-editor.org/info/ rfc2974>。
[RFC3009] Rosenberg, J. and H. Schulzrinne, "Registration of parityfec MIME types", RFC 3009, DOI 10.17487/RFC3009, November 2000, <http://www.rfc-editor.org/info/rfc3009>.
[RFC3009] Rosenberg、J。およびH. Schulzrinne、「Registration of Parityfec MIME Type」、RFC 3009、DOI 10.17487 / RFC3009、2000年11月、<http://www.rfc-editor.org/info/rfc3009>。
[RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, DOI 10.17487/RFC3095, July 2001, <http://www.rfc-editor.org/info/rfc3095>.
[RFC3095] Bormann、C.、Burmeister、C.、Degermark、M。、福島、H.、Hannu、H.、Jonsson、LE。、Hakenberg、R.、Koren、T.、Le、K.、Liu、 Z.、Martensson、A。、宮崎、A.、Svanbro、K.、Wiebke、T。、吉村、T。、およびH. Zheng、「RObust Header Compression（ROHC）：Framework and 4 profiles：RTP、UDP、 ESP、および非圧縮」、RFC 3095、DOI 10.17487 / RFC3095、2001年7月、<http://www.rfc-editor.org/info/rfc3095>。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <http://www.rfc-editor.org/info/rfc3261>.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：セッション開始プロトコル」 、RFC 3261、DOI 10.17487 / RFC3261、2002年6月、<http://www.rfc-editor.org/info/rfc3261>。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, <http://www.rfc-editor.org/info/rfc3264>.
[RFC3264] Rosenberg、J。およびH. Schulzrinne、「セッション記述プロトコル（SDP）を備えたオファー/アンサーモデル」、RFC 3264、DOI 10.17487 / RFC3264、2002年6月、<http://www.rfc-editor.org / info / rfc3264>。
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, DOI 10.17487/RFC3410, December 2002, <http://www.rfc-editor.org/info/rfc3410>.
[RFC3410] Case、J.、Mundy、R.、Partain、D。、およびB. Stewart、「Introduction and Applicability Statements for Internet-Standard Management Framework」、RFC 3410、DOI 10.17487 / RFC3410、2002年12月、<http： //www.rfc-editor.org/info/rfc3410>。
[RFC3497] Gharai, L., Perkins, C., Goncher, G., and A. Mankin, "RTP Payload Format for Society of Motion Picture and Television Engineers (SMPTE) 292M Video", RFC 3497, DOI 10.17487/RFC3497, March 2003, <http://www.rfc-editor.org/info/rfc3497>.
[RFC3497] Gharai、L.、Perkins、C.、Goncher、G。、およびA. Mankin、「Social for Motion Picture and Television Engineers（SMPTE）292M Video」のRTPペイロード形式、RFC 3497、DOI 10.17487 / RFC3497、 2003年3月、<http://www.rfc-editor.org/info/rfc3497>。
[RFC3545] Koren, T., Casner, S., Geevarghese, J., Thompson, B., and P. Ruddy, "Enhanced Compressed RTP (CRTP) for Links with High Delay, Packet Loss and Reordering", RFC 3545, DOI 10.17487/RFC3545, July 2003, <http://www.rfc-editor.org/info/rfc3545>.
[RFC3545] Koren、T.、Casner、S.、Geevarghese、J.、Thompson、B。、およびP. Ruddy、「高遅延、パケット損失、および再配列を伴うリンクのための拡張圧縮RTP（CRTP）」、RFC 3545、 DOI 10.17487 / RFC3545、2003年7月、<http://www.rfc-editor.org/info/rfc3545>。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, <http://www.rfc-editor.org/info/rfc3550>.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：A Transport Protocol for Real-Time Applications」、STD 64、RFC 3550、DOI 10.17487 / RFC3550、2003年7月、 <http://www.rfc-editor.org/info/rfc3550>。
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, DOI 10.17487/RFC3551, July 2003, <http://www.rfc-editor.org/info/rfc3551>.
[RFC3551] Schulzrinne、H。およびS. Casner、「最小制御のオーディオおよびビデオ会議のRTPプロファイル」、STD 65、RFC 3551、DOI 10.17487 / RFC3551、2003年7月、<http：//www.rfc-editor。 org / info / rfc3551>。
[RFC3558] Li, A., "RTP Payload Format for Enhanced Variable Rate Codecs (EVRC) and Selectable Mode Vocoders (SMV)", RFC 3558, DOI 10.17487/RFC3558, July 2003, <http://www.rfc-editor.org/info/rfc3558>.
[RFC3558] Li、A。、「Enhanced Variable Rate Codecs（EVRC）およびSelectable Mode Vocoders（SMV）のRTPペイロードフォーマット」、RFC 3558、DOI 10.17487 / RFC3558、2003年7月、<http：//www.rfc-editor .org / info / rfc3558>。
[RFC3569] Bhattacharyya, S., Ed., "An Overview of Source-Specific Multicast (SSM)", RFC 3569, DOI 10.17487/RFC3569, July 2003, <http://www.rfc-editor.org/info/rfc3569>.
[RFC3569] Bhattacharyya、S。、編、「ソース固有のマルチキャスト（SSM）の概要」、RFC 3569、DOI 10.17487 / RFC3569、2003年7月、<http://www.rfc-editor.org/info/ rfc3569>。
[RFC3577] Waldbusser, S., Cole, R., Kalbfleisch, C., and D. Romascanu, "Introduction to the Remote Monitoring (RMON) Family of MIB Modules", RFC 3577, DOI 10.17487/RFC3577, August 2003, <http://www.rfc-editor.org/info/rfc3577>.
[RFC3577] Waldbusser、S.、Cole、R.、Kalbfleisch、C。、およびD. Romascanu、「Introduction to the Remote Monitoring（RMON）Family of MIB Modules」、RFC 3577、DOI 10.17487 / RFC3577、2003年8月、< http://www.rfc-editor.org/info/rfc3577>。
[RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, DOI 10.17487/RFC3611, November 2003, <http://www.rfc-editor.org/info/rfc3611>.
[RFC3611]フリードマン、T。、編、カセレス、R、編、およびA.クラーク、編、「RTP制御プロトコル拡張レポート（RTCP XR）」、RFC 3611、DOI 10.17487 / RFC3611、2003年11月、 <http://www.rfc-editor.org/info/rfc3611>。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004, <http://www.rfc-editor.org/info/rfc3711>.
[RFC3711]バウアー、M。、マクルー、D。、ナスルンド、M。、カララ、E。、およびK.ノーマン、「The Secure Real-time Transport Protocol（SRTP）」、RFC 3711、DOI 10.17487 / RFC3711、March 2004、<http://www.rfc-editor.org/info/rfc3711>。
[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., Ed., and G. Fairhurst, Ed., "The Lightweight User Datagram Protocol (UDP-Lite)", RFC 3828, DOI 10.17487/RFC3828, July 2004, <http://www.rfc-editor.org/info/rfc3828>.
[RFC3828] Larzon、LA。、Degermark、M.、Pink、S.、Jonsson、LE。、Ed。、and G. Fairhurst、Ed。、 "The Lightweight User Datagram Protocol（UDP-Lite）"、RFC 3828、 DOI 10.17487 / RFC3828、2004年7月、<http://www.rfc-editor.org/info/rfc3828>。
[RFC3984] Wenger, S., Hannuksela, M., Stockhammer, T., Westerlund, M., and D. Singer, "RTP Payload Format for H.264 Video", RFC 3984, DOI 10.17487/RFC3984, February 2005, <http://www.rfc-editor.org/info/rfc3984>.
[RFC3984] Wenger、S.、Hannuksela、M.、Stockhammer、T.、Westerlund、M。、およびD. Singer、「RTP Payload Format for H.264 Video」、RFC 3984、DOI 10.17487 / RFC3984、2005年2月、 <http://www.rfc-editor.org/info/rfc3984>。
[RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text Conversation", RFC 4103, DOI 10.17487/RFC4103, June 2005, <http://www.rfc-editor.org/info/rfc4103>.
[RFC4103] Hellstrom、G。およびP. Jones、「RTP Payload for Text Conversation」、RFC 4103、DOI 10.17487 / RFC4103、2005年6月、<http://www.rfc-editor.org/info/rfc4103>。
[RFC4170] Thompson, B., Koren, T., and D. Wing, "Tunneling Multiplexed Compressed RTP (TCRTP)", BCP 110, RFC 4170, DOI 10.17487/RFC4170, November 2005, <http://www.rfc-editor.org/info/rfc4170>.
[RFC4170] Thompson、B.、Koren、T。、およびD. Wing、「Tunneling Multiplexed Compressed RTP（TCRTP）」、BCP 110、RFC 4170、DOI 10.17487 / RFC4170、2005年11月、<http：//www.rfc -editor.org/info/rfc4170>。
[RFC4175] Gharai, L. and C. Perkins, "RTP Payload Format for Uncompressed Video", RFC 4175, DOI 10.17487/RFC4175, September 2005, <http://www.rfc-editor.org/info/rfc4175>.
[RFC4175] Gharai、L。およびC. Perkins、「非圧縮ビデオのRTPペイロード形式」、RFC 4175、DOI 10.17487 / RFC4175、2005年9月、<http://www.rfc-editor.org/info/rfc4175>。
[RFC4352] Sjoberg, J., Westerlund, M., Lakaniemi, A., and S. Wenger, "RTP Payload Format for the Extended Adaptive Multi-Rate Wideband (AMR-WB+) Audio Codec", RFC 4352, DOI 10.17487/RFC4352, January 2006, <http://www.rfc-editor.org/info/rfc4352>.
[RFC4352] Sjoberg、J.、Westerlund、M.、Lakaniemi、A。、およびS. Wenger、「拡張適応型マルチレートワイドバンド（AMR-WB +）オーディオコーデックのRTPペイロードフォーマット」、RFC 4352、DOI 10.17487 / RFC4352、2006年1月、<http://www.rfc-editor.org/info/rfc4352>。
[RFC4396] Rey, J. and Y. Matsui, "RTP Payload Format for 3rd Generation Partnership Project (3GPP) Timed Text", RFC 4396, DOI 10.17487/RFC4396, February 2006, <http://www.rfc-editor.org/info/rfc4396>.
[RFC4396] Rey、J。およびY. Matsui、「RTP Payload Format for 3rd Generation Partnership Project（3GPP）Timed Text」、RFC 4396、DOI 10.17487 / RFC4396、2006年2月、<http：//www.rfc-editor。 org / info / rfc4396>。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, <http://www.rfc-editor.org/info/rfc4566>.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：Session Description Protocol」、RFC 4566、DOI 10.17487 / RFC4566、2006年7月、<http://www.rfc-editor.org/ info / rfc4566>。
[RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over Connection-Oriented Transport", RFC 4571, DOI 10.17487/RFC4571, July 2006, <http://www.rfc-editor.org/info/rfc4571>.
[RFC4571] Lazzaro、J。、「コネクション型トランスポートを介したフレーミングリアルタイムトランスポートプロトコル（RTP）およびRTP制御プロトコル（RTCP）パケット」、RFC 4571、DOI 10.17487 / RFC4571、2006年7月、<http：// www .rfc-editor.org / info / rfc4571>。
[RFC4573] Even, R. and A. Lochbaum, "MIME Type Registration for RTP Payload Format for H.224", RFC 4573, DOI 10.17487/RFC4573, July 2006, <http://www.rfc-editor.org/info/rfc4573>.
[RFC4573]でも、R。およびA. Lochbaum、「H.224のRTPペイロード形式のMIMEタイプ登録」、RFC 4573、DOI 10.17487 / RFC4573、2006年7月、<http://www.rfc-editor.org/ info / rfc4573>。
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI 10.17487/RFC4585, July 2006, <http://www.rfc-editor.org/info/rfc4585>.
[RFC4585] Ott、J.、Wenger、S.、Sato、N.、Burmeister、C。、およびJ. Rey、「リアルタイムトランスポートコントロールプロトコル（RTCP）ベースのフィードバック用の拡張RTPプロファイル（RTP / AVPF） "、RFC 4585、DOI 10.17487 / RFC4585、2006年7月、<http://www.rfc-editor.org/info/rfc4585>。
[RFC4587] Even, R., "RTP Payload Format for H.261 Video Streams", RFC 4587, DOI 10.17487/RFC4587, August 2006, <http://www.rfc-editor.org/info/rfc4587>.
[RFC4587]偶数、R。、「H.261ビデオストリームのRTPペイロード形式」、RFC 4587、DOI 10.17487 / RFC4587、2006年8月、<http://www.rfc-editor.org/info/rfc4587>。
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, DOI 10.17487/RFC4588, July 2006, <http://www.rfc-editor.org/info/rfc4588>.
[RFC4588]レイ、J。、レオン、D。、宮崎、A。、ヴァルサ、V。、およびR.ハケンバーグ、「RTP Retransmission Payload Format」、RFC 4588、DOI 10.17487 / RFC4588、2006年7月、<http：/ /www.rfc-editor.org/info/rfc4588>。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <http://www.rfc-editor.org/info/rfc4648>.
[RFC4648] Josefsson、S。、「The Base16、Base32、およびBase64データエンコーディング」、RFC 4648、DOI 10.17487 / RFC4648、2006年10月、<http://www.rfc-editor.org/info/rfc4648>。
[RFC4844] Daigle, L., Ed. and Internet Architecture Board, "The RFC Series and RFC Editor", RFC 4844, DOI 10.17487/RFC4844, July 2007, <http://www.rfc-editor.org/info/rfc4844>.
[RFC4844]ダイグル、L。、エド。およびインターネットアーキテクチャボード、「The RFC Series and RFC Editor」、RFC 4844、DOI 10.17487 / RFC4844、2007年7月、<http://www.rfc-editor.org/info/rfc4844>。
[RFC4855] Casner, S., "Media Type Registration of RTP Payload Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007, <http://www.rfc-editor.org/info/rfc4855>.
[RFC4855] Casner、S。、「RTPペイロードフォーマットのメディアタイプ登録」、RFC 4855、DOI 10.17487 / RFC4855、2007年2月、<http://www.rfc-editor.org/info/rfc4855>。
[RFC4867] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie, "RTP Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs", RFC 4867, DOI 10.17487/RFC4867, April 2007, <http://www.rfc-editor.org/info/rfc4867>.
[RFC4867] Sjoberg、J.、Westerlund、M.、Lakaniemi、A。、およびQ. Xie、「アダプティブマルチレート（AMR）およびアダプティブマルチレートワイドバンド（AMR-WB）のRTPペイロード形式およびファイルストレージ形式）オーディオコーデック」、RFC 4867、DOI 10.17487 / RFC4867、2007年4月、<http://www.rfc-editor.org/info/rfc4867>。
[RFC4975] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., "The Message Session Relay Protocol (MSRP)", RFC 4975, DOI 10.17487/RFC4975, September 2007, <http://www.rfc-editor.org/info/rfc4975>.
[RFC4975] Campbell、B.、Ed。、Mahy、R.、Ed。、and C. Jennings、Ed。、 "The Message Session Relay Protocol（MSRP）"、RFC 4975、DOI 10.17487 / RFC4975、September 2007、< http://www.rfc-editor.org/info/rfc4975>。
[RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error Correction", RFC 5109, DOI 10.17487/RFC5109, December 2007, <http://www.rfc-editor.org/info/rfc5109>.
[RFC5109] Li、A。、編、「Generic Forward Error CorrectionのRTPペイロードフォーマット」、RFC 5109、DOI 10.17487 / RFC5109、2007年12月、<http://www.rfc-editor.org/info/rfc5109> 。
[RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February 2008, <http://www.rfc-editor.org/info/rfc5124>.
[RFC5124] Ott、J。およびE. Carrara、「リアルタイム転送制御プロトコル（RTCP）ベースのフィードバック用の拡張セキュアRTPプロファイル（RTP / SAVPF）」、RFC 5124、DOI 10.17487 / RFC5124、2008年2月、<http ：//www.rfc-editor.org/info/rfc5124>。
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.
[RFC5234]クロッカー、D。、エド。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、DOI 10.17487 / RFC5234、2008年1月、<http://www.rfc-editor.org/info/rfc5234>。
[RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July 2008, <http://www.rfc-editor.org/info/rfc5285>.
[RFC5285] Singer、D。およびH. Desineni、「一般的なRTPヘッダー拡張メカニズム」、RFC 5285、DOI 10.17487 / RFC5285、2008年7月、<http://www.rfc-editor.org/info/rfc5285> 。
[RFC5385] Touch, J., "Version 2.0 Microsoft Word Template for Creating Internet Drafts and RFCs", RFC 5385, DOI 10.17487/RFC5385, February 2010, <http://www.rfc-editor.org/info/rfc5385>.
[RFC5385] Touch、J。、「インターネットドラフトとRFCを作成するためのバージョン2.0 Microsoft Wordテンプレート」、RFC 5385、DOI 10.17487 / RFC5385、2010年2月、<http://www.rfc-editor.org/info/rfc5385> 。
[RFC5484] Singer, D., "Associating Time-Codes with RTP Streams", RFC 5484, DOI 10.17487/RFC5484, March 2009, <http://www.rfc-editor.org/info/rfc5484>.
[RFC5484] Singer、D。、「Associating Time-Codes with RTP Streams」、RFC 5484、DOI 10.17487 / RFC5484、2009年3月、<http://www.rfc-editor.org/info/rfc5484>。
[RFC5583] Schierl, T. and S. Wenger, "Signaling Media Decoding Dependency in the Session Description Protocol (SDP)", RFC 5583, DOI 10.17487/RFC5583, July 2009, <http://www.rfc-editor.org/info/rfc5583>.
[RFC5583] Schierl、T。およびS. Wenger、「Signaling Media Decoding Dependency in the Session Description Protocol（SDP）」、RFC 5583、DOI 10.17487 / RFC5583、2009年7月、<http://www.rfc-editor.org / info / rfc5583>。
[RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust Header Compression (ROHC) Framework", RFC 5795, DOI 10.17487/RFC5795, March 2010, <http://www.rfc-editor.org/info/rfc5795>.
[RFC5795] Sandlund、K.、Pelletier、G。、およびL-E。 Jonsson、「The RObust Header Compression（ROHC）Framework」、RFC 5795、DOI 10.17487 / RFC5795、2010年3月、<http://www.rfc-editor.org/info/rfc5795>。
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, <http://www.rfc-editor.org/info/rfc5905>.
[RFC5905] Mills、D.、Martin、J.、Ed。、Burbank、J。、およびW. Kasch、「Network Time Protocol Version 4：Protocol and Algorithms Specification」、RFC 5905、DOI 10.17487 / RFC5905、2010年6月、 <http://www.rfc-editor.org/info/rfc5905>。
[RFC6015] Begen, A., "RTP Payload Format for 1-D Interleaved Parity Forward Error Correction (FEC)", RFC 6015, DOI 10.17487/RFC6015, October 2010, <http://www.rfc-editor.org/info/rfc6015>.
[RFC6015] Begen、A。、「1-D Interleaved Parity Forward Error Correction（FEC）のRTPペイロードフォーマット」、RFC 6015、DOI 10.17487 / RFC6015、2010年10月、<http://www.rfc-editor.org/ info / rfc6015>。
[RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP Flows", RFC 6051, DOI 10.17487/RFC6051, November 2010, <http://www.rfc-editor.org/info/rfc6051>.
[RFC6051] Perkins、C。およびT. Schierl、「RTPフローの迅速な同期」、RFC 6051、DOI 10.17487 / RFC6051、2010年11月、<http://www.rfc-editor.org/info/rfc6051>。
[RFC6184] Wang, Y., Even, R., Kristensen, T., and R. Jesup, "RTP Payload Format for H.264 Video", RFC 6184, DOI 10.17487/RFC6184, May 2011, <http://www.rfc-editor.org/info/rfc6184>.
[RFC6184] Wang、Y.、Even、R.、Kristensen、T.、R。Jesup、「RTP Payload Format for H.264 Video」、RFC 6184、DOI 10.17487 / RFC6184、2011年5月、<http：// www.rfc-editor.org/info/rfc6184>。
[RFC6190] Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis, "RTP Payload Format for Scalable Video Coding", RFC 6190, DOI 10.17487/RFC6190, May 2011, <http://www.rfc-editor.org/info/rfc6190>.
[RFC6190] Wenger、S.、Wang、Y.、Schierl、T。、およびA. Eleftheriadis、「RTP Payload Format for Scalable Video Coding」、RFC 6190、DOI 10.17487 / RFC6190、2011年5月、<http：// www .rfc-editor.org / info / rfc6190>。
[RFC6295] Lazzaro, J. and J. Wawrzynek, "RTP Payload Format for MIDI", RFC 6295, DOI 10.17487/RFC6295, June 2011, <http://www.rfc-editor.org/info/rfc6295>.
[RFC6295] Lazzaro、J。、およびJ. Wawrzynek、「RTP Payload Format for MIDI」、RFC 6295、DOI 10.17487 / RFC6295、2011年6月、<http://www.rfc-editor.org/info/rfc6295>。
[RFC6354] Xie, Q., "Forward-Shifted RTP Redundancy Payload Support", RFC 6354, DOI 10.17487/RFC6354, August 2011, <http://www.rfc-editor.org/info/rfc6354>.
[RFC6354] Xie、Q。、「Forward-Shifted RTP Redundancy Payload Support」、RFC 6354、DOI 10.17487 / RFC6354、2011年8月、<http://www.rfc-editor.org/info/rfc6354>。
[RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error Correction (FEC) Framework", RFC 6363, DOI 10.17487/RFC6363, October 2011, <http://www.rfc-editor.org/info/rfc6363>.
[RFC6363] Watson、M.、Begen、A。、およびV. Roca、「Forward Error Correction（FEC）Framework」、RFC 6363、DOI 10.17487 / RFC6363、2011年10月、<http：//www.rfc-editor。 org / info / rfc6363>。
[RFC6410] Housley, R., Crocker, D., and E. Burger, "Reducing the Standards Track to Two Maturity Levels", BCP 9, RFC 6410, DOI 10.17487/RFC6410, October 2011, <http://www.rfc-editor.org/info/rfc6410>.
[RFC6410] Housley、R.、Crocker、D。、およびE. Burger、「Standard Tracks to Two Maturity Levels」、BCP 9、RFC 6410、DOI 10.17487 / RFC6410、2011年10月、<http：// www。 rfc-editor.org/info/rfc6410>。
[RFC6562] Perkins, C. and JM. Valin, "Guidelines for the Use of Variable Bit Rate Audio with Secure RTP", RFC 6562, DOI 10.17487/RFC6562, March 2012, <http://www.rfc-editor.org/info/rfc6562>.
[RFC6562]パーキンス、C。およびJM。 Valin、「Secure RTPでの可変ビットレートオーディオの使用に関するガイドライン」、RFC 6562、DOI 10.17487 / RFC6562、2012年3月、<http://www.rfc-editor.org/info/rfc6562>。
[RFC6597] Downs, J., Ed. and J. Arbeiter, Ed., "RTP Payload Format for Society of Motion Picture and Television Engineers (SMPTE) ST 336 Encoded Data", RFC 6597, DOI 10.17487/RFC6597, April 2012, <http://www.rfc-editor.org/info/rfc6597>.
[RFC6597]ダウンズ、J。、エド。およびJ. Arbeiter編、「Social of Motion Picture and Television Engineers（SMPTE）ST 336 Encoded DataのRTPペイロード形式」、RFC 6597、DOI 10.17487 / RFC6597、2012年4月、<http：//www.rfc-editor .org / info / rfc6597>。
[RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., and K. Carlberg, "Explicit Congestion Notification (ECN) for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August 2012, <http://www.rfc-editor.org/info/rfc6679>.
[RFC6679] Westerlund、M.、Johansson、I.、Perkins、C.、O'Hanlon、P。、およびK. Carlberg、「RTP over UDPの明示的輻輳通知（ECN）」、RFC 6679、DOI 10.17487 / RFC6679 、2012年8月、<http://www.rfc-editor.org/info/rfc6679>。
[RFC6682] Watson, M., Stockhammer, T., and M. Luby, "RTP Payload Format for Raptor Forward Error Correction (FEC)", RFC 6682, DOI 10.17487/RFC6682, August 2012, <http://www.rfc-editor.org/info/rfc6682>.
[RFC6682] Watson、M.、Stockhammer、T。、およびM. Luby、「RTP Payload Format for Raptor Forward Error Correction（FEC）」、RFC 6682、DOI 10.17487 / RFC6682、2012年8月、<http：// www。 rfc-editor.org/info/rfc6682>。
[RFC6701] Farrel, A. and P. Resnick, "Sanctions Available for Application to Violators of IETF IPR Policy", RFC 6701, DOI 10.17487/RFC6701, August 2012, <http://www.rfc-editor.org/info/rfc6701>.
[RFC6701] Farrel、A。およびP. Resnick、「IETF IPRポリシーの違反者へのアプリケーションに適用可能な制裁措置」、RFC 6701、DOI 10.17487 / RFC6701、2012年8月、<http://www.rfc-editor.org/info / rfc6701>。
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, <http://www.rfc-editor.org/info/rfc6838>.
[RFC6838] Freed、N.、Klensin、J。、およびT. Hansen、「Media Type Specifications and Registration Procedures」、BCP 13、RFC 6838、DOI 10.17487 / RFC6838、2013年1月、<http：//www.rfc- editor.org/info/rfc6838>。
[RFC7160] Petit-Huguenin, M. and G. Zorn, Ed., "Support for Multiple Clock Rates in an RTP Session", RFC 7160, DOI 10.17487/RFC7160, April 2014, <http://www.rfc-editor.org/info/rfc7160>.
[RFC7160] Petit-Huguenin、M。およびG. Zorn、編、「RTPセッションでの複数のクロックレートのサポート」、RFC 7160、DOI 10.17487 / RFC7160、2014年4月、<http：//www.rfc-editor .org / info / rfc7160>。
[RFC7164] Gross, K. and R. Brandenburg, "RTP and Leap Seconds", RFC 7164, DOI 10.17487/RFC7164, March 2014, <http://www.rfc-editor.org/info/rfc7164>.
[RFC7164] Gross、K。およびR. Brandenburg、「RTP and Leap Seconds」、RFC 7164、DOI 10.17487 / RFC7164、2014年3月、<http://www.rfc-editor.org/info/rfc7164>。
[RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, <http://www.rfc-editor.org/info/rfc7201>.
[RFC7201] Westerlund、M。およびC. Perkins、「RTPセッションを保護するためのオプション」、RFC 7201、DOI 10.17487 / RFC7201、2014年4月、<http://www.rfc-editor.org/info/rfc7201>。
[RFC7202] Perkins, C. and M. Westerlund, "Securing the RTP Framework: Why RTP Does Not Mandate a Single Media Security Solution", RFC 7202, DOI 10.17487/RFC7202, April 2014, <http://www.rfc-editor.org/info/rfc7202>.
[RFC7202] Perkins、C。およびM. Westerlund、「RTPフレームワークの保護：RTPが単一のメディアセキュリティソリューションを義務付けない理由」、RFC 7202、DOI 10.17487 / RFC7202、2014年4月、<http：//www.rfc- editor.org/info/rfc7202>。
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, <http://www.rfc-editor.org/info/rfc7231>.
[RFC7231]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Semantics and Content」、RFC 7231、DOI 10.17487 / RFC7231、2014年6月、<http://www.rfc-editor.org/info/rfc7231 >。
[RFC7273] Williams, A., Gross, K., van Brandenburg, R., and H. Stokking, "RTP Clock Source Signalling", RFC 7273, DOI 10.17487/RFC7273, June 2014, <http://www.rfc-editor.org/info/rfc7273>.
[RFC7273]ウィリアムズ、A。、グロス、K。、ファンブランデンブルク、R。、およびH.ストキング、「RTPクロックソースシグナリング」、RFC 7273、DOI 10.17487 / RFC7273、2014年6月、<http：//www.rfc -editor.org/info/rfc7273>。
[RFC7322] Flanagan, H. and S. Ginoza, "RFC Style Guide", RFC 7322, DOI 10.17487/RFC7322, September 2014, <http://www.rfc-editor.org/info/rfc7322>.
[RFC7322] Flanagan、H。およびS. Ginoza、「RFCスタイルガイド」、RFC 7322、DOI 10.17487 / RFC7322、2014年9月、<http://www.rfc-editor.org/info/rfc7322>。
[RFC7587] Spittka, J., Vos, K., and JM. Valin, "RTP Payload Format for the Opus Speech and Audio Codec", RFC 7587, DOI 10.17487/RFC7587, June 2015, <http://www.rfc-editor.org/info/rfc7587>.
[RFC7587] Spittka、J.、Vos、K。、およびJM。 Valin、「Opus Speech and Audio CodecのRTPペイロード形式」、RFC 7587、DOI 10.17487 / RFC7587、2015年6月、<http://www.rfc-editor.org/info/rfc7587>。
[RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources", RFC 7656, DOI 10.17487/RFC7656, November 2015, <http://www.rfc-editor.org/info/rfc7656>.
[RFC7656] Lennox、J.、Gross、K.、Nandakumar、S.、Salgueiro、G。、およびB. Burman、編、「リアルタイムの転送プロトコル（RTP）ソースのセマンティクスとメカニズムの分類法」、 RFC 7656、DOI 10.17487 / RFC7656、2015年11月、<http://www.rfc-editor.org/info/rfc7656>。
[RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, DOI 10.17487/RFC7667, November 2015, <http://www.rfc-editor.org/info/rfc7667>.
[RFC7667] Westerlund、M。およびS. Wenger、「RTPトポロジ」、RFC 7667、DOI 10.17487 / RFC7667、2015年11月、<http://www.rfc-editor.org/info/rfc7667>。
[RFC7741] Westin, P., Lundin, H., Glover, M., Uberti, J., and F. Galligan, "RTP Payload Format for VP8 Video", RFC 7741, DOI 10.17487/RFC7741, March 2016, <http://www.rfc-editor.org/info/rfc7741>.
[RFC7741] Westin、P.、Lundin、H.、Glover、M.、Uberti、J。、およびF. Galligan、「VP8ビデオのRTPペイロード形式」、RFC 7741、DOI 10.17487 / RFC7741、2016年3月、<http ：//www.rfc-editor.org/info/rfc7741>。
[RFC7798] Wang, Y., Sanchez, Y., Schierl, T., Wenger, S., and M. Hannuksela, "RTP Payload Format for High Efficiency Video Coding (HEVC)", RFC 7798, DOI 10.17487/RFC7798, March 2016, <http://www.rfc-editor.org/info/rfc7798>.
[RFC7798] Wang、Y.、Sanchez、Y.、Schiell、T.、Wenger、S。、およびM. Hannuksela、「高効率ビデオコーディング（HEVC）のRTPペイロード形式」、RFC 7798、DOI 10.17487 / RFC7798、 2016年3月、<http://www.rfc-editor.org/info/rfc7798>。
[RFC7826] Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., and M. Stiemerling, Ed., "Real-Time Streaming Protocol Version 2.0", RFC 7826, DOI 10.17487/RFC7826, December 2016, <http://www.rfc-editor.org/info/rfc7826>.
[RFC7826] Schulzrinne、H.、Rao、A.、Lanphier、R.、Westerlund、M。、およびM. Stiemerling、編、「Real-Time Streaming Protocol Version 2.0」、RFC 7826、DOI 10.17487 / RFC7826、12月2016、<http://www.rfc-editor.org/info/rfc7826>。
[RFC7990] Flanagan, H., "RFC Format Framework", RFC 7990, DOI 10.17487/RFC7990, December 2016, <http://www.rfc-editor.org/info/rfc7990>.
[RFC7990] Flanagan、H。、「RFC Format Framework」、RFC 7990、DOI 10.17487 / RFC7990、2016年12月、<http://www.rfc-editor.org/info/rfc7990>。
[RFC8083] Perkins, C. and V. Singh, "Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions", RFC 8083, DOI 10.17487/RFC8083, March 2017, <http://www.rfc-editor.org/info/rfc8083>.
[RFC8083] Perkins、C。およびV. Singh、「Multimedia Congestion Control：Circuit Breaks for Unicast RTP Sessions」、RFC 8083、DOI 10.17487 / RFC8083、2017年3月、<http://www.rfc-editor.org/info / rfc8083>。
[TAO] Hoffman, P., Ed., "The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force", November 2012, <http://www.ietf.org/tao.html>.
[TAO]ホフマン、P。、編、「IETFのタオ：インターネットエンジニアリングタスクフォースの初心者向けガイド」、2012年11月、<http://www.ietf.org/tao.html>。
[TRACKER] "IETF Datatracker", <https://datatracker.ietf.org/>.
[トラッカー]「IETFデータトラッカー」、<https://datatracker.ietf.org/>。
This section contains a template for writing an RTP payload format in the form of an Internet-Draft. Text within [...] are instructions and must be removed from the draft itself. Some text proposals that are included are conditional. "..." is used to indicate where further text should be written.
このセクションには、インターネットドラフトの形式でRTPペイロード形式を記述するためのテンプレートが含まれています。 [...]内のテキストは指示であり、ドラフト自体から削除する必要があります。含まれているいくつかのテキスト提案は条件付きです。 「...」は、さらにテキストを書き込む場所を示すために使用されます。
[The title shall be descriptive but as compact as possible. RTP is allowed and recommended abbreviation in the title]
[タイトルはわかりやすいものにしますが、できるだけ簡潔にする必要があります。 RTPは許可されており、タイトルに略称を使用することをお勧めします]
RTP payload format for ...
...のRTPペイロード形式
Status of this Memo
本文書の状態
[Insert the IPR notice and copyright boilerplate from BCP 78 and 79 that applies to this draft.]
[このドラフトに適用されるBCP 78および79からのIPR通知および著作権ボイラープレートを挿入します。]
[Insert the current Internet-Draft document explanation. At the time of publishing it was:]
[現在のインターネットドラフトドキュメントの説明を挿入します。公開時は次のとおりでした：]
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Draftsは、Internet Engineering Task Force（IETF）の作業文書です。他のグループも作業文書をインターネットドラフトとして配布する場合があることに注意してください。現在のインターネットドラフトのリストは、http：//datatracker.ietf.org/drafts/current/にあります。
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
インターネットドラフトは、最長6か月間有効なドラフト文書であり、いつでも他の文書によって更新、置換、または廃止される可能性があります。インターネットドラフトを参考資料として使用したり、「進行中の作業」以外の方法で引用することは不適切です。
[A payload format abstract should mention the capabilities of the format, for which media format is used, and a little about that codec formats capabilities. Any abbreviation used in the payload format must be spelled out here except the very well known like RTP. No citations are allowed, and no use of language from RFC 2119 either.]
[ペイロード形式の要約では、メディア形式が使用される形式の機能と、そのコーデック形式の機能について少し説明する必要があります。ペイロード形式で使用される省略形は、RTPのような非常によく知られているものを除いて、ここにスペルアウトする必要があります。引用は許可されておらず、RFC 2119の言語も使用されていません。]
[If your draft is approved for publication as an RFC, a Table of Contents is required, per [RFC7322].]
[ドラフトがRFCとしての公開が承認されている場合、[RFC7322]に従って目次が必要です。]
[The Introduction should provide a background and overview of the payload format's capabilities. No normative language in this section, i.e., no MUST, SHOULDs etc.]
[はじめに、ペイロード形式の機能の背景と概要を提供する必要があります。このセクションには規範的な言語はありません。つまり、MUST、SHOULDなどはありません。]
[Define conventions, definitions, and abbreviations used in the document in this section. The most common definition used in RTP payload formats are the RFC 2119 definitions of the uppercase normative words, e.g., MUST and SHOULD.]
[このセクションのドキュメントで使用される規則、定義、および略語を定義します。 RTPペイロード形式で使用される最も一般的な定義は、大文字の規範的な単語のRFC 2119定義です（MUSTやSHOULDなど）。]
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.
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119で説明されているように解釈されます。
[The intention of this section is to enable reviewers and persons to get an overview of the capabilities and major properties of the media format. It should be kept short and concise and is not a complete replacement for reading the media format specification.]
[このセクションの目的は、レビュー担当者と担当者がメディアフォーマットの機能と主要なプロパティの概要を理解できるようにすることです。これは短く簡潔にする必要があり、メディア形式の仕様を読むための完全な代替ではありません。]
[Overview of payload structure]
【ペイロード構造の概要】
[RTP header usage needs to be defined. The fields that absolutely need to be defined are timestamp and marker bit. Further fields may be specified if used. All the rest should be left to their RTP specification definition.]
[RTPヘッダーの使用法を定義する必要があります。絶対に定義する必要があるフィールドは、タイムスタンプとマーカービットです。使用する場合は、さらにフィールドを指定できます。残りはすべて、RTP仕様の定義に任せる必要があります。]
The remaining RTP header fields are used as specified in RTP [RFC3550].
残りのRTPヘッダーフィールドは、RTP [RFC3550]での指定に従って使用されます。
[Define how the payload header, if it exists, is structured and used.]
[ペイロードヘッダーが存在する場合、その構造と使用方法を定義します。]
[The payload data, i.e., what the media codec has produced. Commonly done through reference to the media codec specification, which defines how the data is structured. Rules for padding may need to be defined to bring data to octet alignment.]
[ペイロードデータ、つまりメディアコーデックが生成したもの。通常は、データの構造を定義するメディアコーデック仕様を参照して行われます。データをオクテットアライメントにするために、パディングのルールを定義する必要がある場合があります。]
[One or more examples are good to help ease the understanding of the RTP payload format.]
[RTPペイロード形式の理解を容易にするのに役立つ例が1つ以上あります。]
[This section is to describe the possibility to vary the bitrate as a response to congestion. Below is also a proposal for an initial text that reference RTP and profiles definition of congestion control.]
[このセクションでは、輻輳への対応としてビットレートを変更する可能性について説明します。以下は、RTPおよび輻輳制御のプロファイル定義を参照する最初のテキストの提案でもあります。]
Congestion control for RTP SHALL be used in accordance with RFC 3550 [RFC3550], and with any applicable RTP profile: e.g., RFC 3551 [RFC3551]. An additional requirement if best-effort service is being used is users of this payload format MUST monitor packet loss to ensure that the packet loss rate is within acceptable parameters. Circuit Breakers [RFC8083] is an update to RTP [RFC3550] that defines criteria for when one is required to stop sending RTP Packet Streams. The circuit breakers is to be implemented and followed.
RTPの輻輳制御は、RFC 3550 [RFC3550]、および適用可能なRTPプロファイル（RFC 3551 [RFC3551]など）に従って使用する必要があります（SHALL）。ベストエフォートサービスが使用されている場合の追加の要件は、このペイロード形式のユーザーがパケット損失を監視して、パケット損失率が許容可能なパラメータ内であることを確認する必要があることです。 Circuit Breakers [RFC8083]は、RTP [RFC3550]のアップデートであり、RTPパケットストリームの送信を停止する必要がある場合の基準を定義します。回路ブレーカーを実装し、それに従ってください。
This RTP payload format is identified using the ... media type, which is registered in accordance with RFC 4855 [RFC4855] and using the template of RFC 6838 [RFC6838].
このRTPペイロード形式は、...メディアタイプを使用して識別されます。これは、RFC 4855 [RFC4855]に従って登録され、RFC 6838 [RFC6838]のテンプレートを使用します。
[Here the media type registration template from RFC 6838 is placed and filled out. This template is provided with some common RTP boilerplate.]
[ここでは、RFC 6838のメディアタイプ登録テンプレートが配置され、入力されています。このテンプレートには、いくつかの一般的なRTPボイラープレートが付属しています。]
Type name:
タイプ名：
Subtype name:
サブタイプ名：
Required parameters:
必須パラメーター：
Optional parameters: Encoding considerations:
オプションのパラメーター：エンコードに関する考慮事項：
This media type is framed and binary; see Section 4.8 in RFC 6838 [RFC6838].
このメディアタイプはフレーム付きでバイナリです。 RFC 6838 [RFC6838]のセクション4.8をご覧ください。
Security considerations:
セキュリティに関する考慮事項：
Please see the Security Considerations section in RFC XXXX
RFC XXXXのセキュリティに関する考慮事項のセクションを参照してください
Interoperability considerations:
相互運用性に関する考慮事項：
Published specification:
公開された仕様：
Applications that use this media type:
このメディアタイプを使用するアプリケーション：
Additional information:
追加情報：
Deprecated alias names for this type:
このタイプの非推奨のエイリアス名：
[Only applicable if there exists widely deployed alias for this media type; see Section 4.2.9 of [RFC6838]. Remove or use N/A otherwise.]
[このメディアタイプに広く展開されているエイリアスが存在する場合にのみ適用されます。 [RFC6838]のセクション4.2.9をご覧ください。それ以外の場合は削除または使用しないでください。]
Magic number(s):
マジックナンバー：
[Only applicable for media types that has file format specification. Remove or use N/A otherwise.]
[ファイル形式が指定されているメディアタイプにのみ適用されます。それ以外の場合は削除または使用しないでください。]
File extension(s):
ファイル拡張子：
[Only applicable for media types that has file format specification. Remove or use N/A otherwise.]
[ファイル形式が指定されているメディアタイプにのみ適用されます。それ以外の場合は削除または使用しないでください。]
Macintosh file type code(s):
Macintoshファイルタイプコード：
[Only applicable for media types that has file format specification. Even for file formats they can be skipped as they are not relied on after Mac OS 9.X. Remove or use N/A otherwise.]
[ファイル形式が指定されているメディアタイプにのみ適用されます。ファイル形式の場合でも、Mac OS 9.X以降は依存しないため、スキップできます。それ以外の場合は削除または使用しないでください。]
Person & email address to contact for further information:
詳細について連絡する人とメールアドレス：
Intended usage:
使用目的：
[One of COMMON, LIMITED USE, or OBSOLETE.]
[共通、限定使用、または廃止のいずれか。]
Restrictions on usage:
使用上の制限：
[The below text is for media types that is only defined for RTP payload formats. There exist certain media types that are defined both as RTP payload formats and file transfer. The rules for such types are documented in RFC 4855 [RFC4855].]
[以下のテキストは、RTPペイロード形式に対してのみ定義されているメディアタイプ用です。 RTPペイロード形式とファイル転送の両方として定義されている特定のメディアタイプが存在します。そのようなタイプのルールは、RFC 4855 [RFC4855]で文書化されています。]
This media type depends on RTP framing and, hence, is only defined for transfer via RTP [RFC3550]. Transport within other framing protocols is not defined at this time.
このメディアタイプはRTPフレーミングに依存するため、RTP [RFC3550]を介した転送に対してのみ定義されます。現在、他のフレーミングプロトコル内のトランスポートは定義されていません。
Author:
著者：
Change controller:
コントローラを変更：
IETF Payload working group delegated from the IESG.
IESGから委任されたIETFペイロードワーキンググループ。
Provisional registration? (standards tree only):
仮登録？ （標準ツリーのみ）：
No
の
(Any other information that the author deems interesting may be added below this line.)
（著者が興味深いと考えるその他の情報は、この行の下に追加できます。）
[From RFC 6838:
[RFC 6838から：
"N/A", written exactly that way, can be used in any field if desired to emphasize the fact that it does not apply or that the question was not omitted by accident. Do not use 'none' or other words that could be mistaken for a response.
「N / A」は正確にそのように記述されており、適用されない、または質問が誤って省略されなかったという事実を強調するために、必要に応じて任意のフィールドで使用できます。 「なし」または応答と間違われる可能性のある他の単語を使用しないでください。
Limited-use media types should also note in the applications list whether or not that list is exhaustive.]
用途が限定されたメディアタイプも、アプリケーションリストにそのリストが網羅的であるかどうかを記載する必要があります。]
The mapping of the above defined payload format media type and its parameters SHALL be done according to Section 3 of RFC 4855 [RFC4855].
上記で定義されたペイロード形式のメディアタイプとそのパラメータのマッピングは、RFC 4855 [RFC4855]のセクション3に従って行う必要があります。
[More specific rules only need to be included if some parameter does not match these rules.]
[一部のパラメーターがこれらのルールに一致しない場合にのみ、より具体的なルールを含める必要があります。]
[Here write your Offer/Answer considerations section; please see Section 3.4.2.1 for help.]
[ここに、オファー/アンサーの考慮事項セクションを書きます。セクション3.4.2.1を参照してください。]
[Here write your considerations for declarative SDP, please see Section 3.4.2.2 for help.]
[ここに宣言型SDPに関する考慮事項を記述してください。ヘルプについては、セクション3.4.2.2を参照してください。]
This memo requests that IANA registers [insert media type name here] as specified in Appendix A.11.1. The media type is also requested to be added to the IANA registry for "RTP Payload Format MIME types" <http://www.iana.org/assignments/rtp-parameters>.
このメモは、IANAが付録A.11.1で指定されている[メディアタイプ名をここに挿入]を登録することを要求します。メディアタイプは、「RTP Payload Format MIMEタイプ」<http://www.iana.org/assignments/rtp-parameters>のIANAレジストリに追加することも要求されます。
[See Section 7.4 and consider if any of the parameter needs a registered name space.]
[セクション7.4を参照し、登録された名前空間を必要とするパラメーターがあるかどうかを検討してください。]
[See Section 7.2.]
[セクション7.2を参照。]
RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [RFC3550] , and in any applicable RTP profile such as RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711], or RTP/ SAVPF [RFC5124]. However, as "Securing the RTP Protocol Framework: Why RTP Does Not Mandate a Single Media Security Solution" [RFC7202] discusses, it is not an RTP payload format's responsibility to discuss or mandate what solutions are used to meet the basic security goals like confidentiality, integrity, and source authenticity for RTP in general. This responsibility lays on anyone using RTP in an application. They can find guidance on available security mechanisms and important considerations in "Options for Securing RTP Sessions" [RFC7201]. Applications SHOULD use one or more appropriate strong security mechanisms. The rest of this Security Considerations section discusses the security impacting properties of the payload format itself.
この仕様で定義されているペイロード形式を使用するRTPパケットは、RTP仕様[RFC3550]で説明されているセキュリティ上の考慮事項、およびRTP / AVP [RFC3551]、RTP / AVPF [RFC4585]、RTP / SAVPなどの適用可能なRTPプロファイルの対象です。 [RFC3711]、またはRTP / SAVPF [RFC5124]。ただし、「RTPプロトコルフレームワークのセキュリティ保護：RTPが単一のメディアセキュリティソリューションを義務付けない理由」[RFC7202]が説明しているように、機密性などの基本的なセキュリティ目標を達成するために使用されるソリューションについて話し合う、または義務付けることは、RTPペイロード形式の責任ではありません。 、整合性、および一般的なRTPのソースの信頼性。この責任は、アプリケーションでRTPを使用するすべての人にあります。利用可能なセキュリティメカニズムと重要な考慮事項に関するガイダンスは、「RTPセッションを保護するためのオプション」[RFC7201]にあります。アプリケーションは、1つ以上の適切な強力なセキュリティメカニズムを使用する必要があります。このセキュリティの考慮事項セクションの残りの部分では、ペイロード形式自体のセキュリティに影響を与えるプロパティについて説明します。
This RTP payload format and its media decoder do not exhibit any significant non-uniformity in the receiver-side computational complexity for packet processing, and thus are unlikely to pose a denial-of-service threat due to the receipt of pathological data. Nor does the RTP payload format contain any active content.
このRTPペイロード形式とそのメディアデコーダーは、パケット処理の受信側の計算の複雑さに大きな不均一性を示さないため、病理学的データの受信によるサービス拒否の脅威をもたらす可能性は低いです。また、RTPペイロード形式にはアクティブコンテンツが含まれていません。
[The previous paragraph may need editing due to the format breaking either of the statements. Fill in here any further potential security threats created by the payload format itself.]
[前の段落では、どちらかのステートメントが壊れた形式のため、編集が必要になる場合があります。ペイロード形式自体によって作成される潜在的なセキュリティの脅威をここに入力します。]
Note to RFC Editor: This section may be removed after carrying out all the instructions of this section.
RFCエディタへの注意：このセクションは、このセクションのすべての指示を実行した後で削除される場合があります。
RFC XXXX is to be replaced by the RFC number this specification receives when published.
RFC XXXXは、公開時にこの仕様が受け取るRFC番号に置き換えられます。
[References must be classified as either normative or informative and added to the relevant section. References should use descriptive reference tags.]
[参照は、規範的または情報的のいずれかに分類され、関連セクションに追加される必要があります。参照には説明的な参照タグを使用する必要があります。]
[Normative references are those that are required to be used to correctly implement the payload format. Also, when requirements language is used, as in the sample text for "Congestion Control Considerations" above, there should be a normative reference to [RFC2119].]
[規範的な参照は、ペイロード形式を正しく実装するために使用する必要がある参照です。また、上記の「輻輳制御に関する考慮事項」のサンプルテキストのように、要件言語が使用されている場合、[RFC2119]への規範的な参照があるはずです。
[All other references.]
[他のすべての参照。]
[All authors need to include their name and email address as a minimum: postal mail and possibly phone numbers are included commonly.]
[すべての作成者は、少なくとも自分の名前と電子メールアドレスを含める必要があります。郵便とおそらく電話番号が一般的に含まれています。]
[The Template Ends Here!]
[テンプレートはここで終わります！]
Acknowledgements
謝辞
The author would like to thank the individuals who have provided input to this document. These individuals include Richard Barnes, Ali C. Begen, Bo Burman, Ross Finlayson, Russ Housley, John Lazzaro, Jonathan Lennox, Colin Perkins, Tom Taylor, Stephan Wenger, and Qin Wu.
著者は、この文書への入力を提供してくれた個人に感謝したいと思います。これらの個人には、Richard Barnes、Ali C. Begen、Bo Burman、Ross Finlayson、Russ Housley、John Lazzaro、Jonathan Lennox、Colin Perkins、Tom Taylor、Stephan Wenger、およびQin Wuが含まれます。
Contributors
貢献者
The author would like to thank Tom Taylor for the editing pass of the whole document and contributing text regarding proprietary RTP payload formats. Thanks also goes to Thomas Schierl who contributed text regarding Media Scalability features in payload formats (Section 5.1.5). Stephan Wenger has contributed text on the need to understand the media coding (Section 3.1) as well as joint development of payload format with the media coding (Section 4.4).
著者は、ドキュメント全体の編集パスと、プロプライエタリなRTPペイロード形式に関するテキストの寄稿について、トムテイラーに感謝します。ペイロード形式のMedia Scalability機能に関するテキストを寄稿したThomas Schierlにも感謝します（セクション5.1.5）。 Stephan Wengerは、メディアコーディング（セクション3.1）と、メディアコーディング（セクション4.4）とのペイロード形式の共同開発を理解する必要性についてテキストを提供しています。
Author's Address
著者のアドレス
Magnus Westerlund Ericsson Farogatan 2 SE-164 80 Kista Sweden
Magnus Westerlund Ericsson Farogatan 2 SE-164 80 Kistaスウェーデン
Phone: +46 10 714 82 87
Email: magnus.westerlund@ericsson.com