RFC3550 日本語訳
3550 RTP: A Transport Protocol for Real-Time Applications. H.Schulzrinne, S. Casner, R. Frederick, V. Jacobson. July 2003. (Format: TXT=259985, PS=630740, PDF=504117 bytes) (Obsoletes RFC1889) (Also STD0064) (Status: STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group H. Schulzrinne
Request for Comments: 3550 Columbia University
Obsoletes: 1889 S. Casner
Category: Standards Track Packet Design
R. Frederick
Blue Coat Systems Inc.
V. Jacobson
Packet Design
July 2003
Schulzrinneがコメントのために要求するワーキンググループH.をネットワークでつないでください: 3550年のコロンビア大学は以下を時代遅れにします。 1889秒間Casnerカテゴリ: 規格はコートシステム株式会社V.ジェーコブソンパケットデザイン2003年7月にパケットデザインR.フレディリック青を追跡します。
RTP: A Transport Protocol for Real-Time Applications
RTP: リアルタイムのアプリケーションのためのトランスポート・プロトコル
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
Abstract
要約
This memorandum describes RTP, the real-time transport protocol. RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. RTP does not address resource reservation and does not guarantee quality-of-service for real-time services. The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. RTP and RTCP are designed to be independent of the underlying transport and network layers. The protocol supports the use of RTP-level translators and mixers.
このメモはRTP、リアルタイムのトランスポート・プロトコルについて説明します。 RTPは終わりから終わりへのネットワーク輸送リアルタイムデータを伝えるアプリケーションに適した機能を提供します、オーディオ、ビデオまたはシミュレーションデータなどのように、マルチキャストかユニキャストネットワーク・サービスの上で。 RTPは資源予約を扱わないで、また本当の時間指定サービスのためにサービスの質を保証しません。 制御プロトコル(RTCP)によってデータ伝送は増大させられて、データ配送が大きいマルチキャストネットワークにスケーラブルな方法でモニターされるのを許容して、最小量のコントロールと識別の機能性を前提とします。 RTPとRTCPは、基本的な輸送とネットワーク層から独立しているように設計されています。 プロトコルはRTP-レベル翻訳者とミキサーの使用をサポートします。
Most of the text in this memorandum is identical to RFC 1889 which it obsoletes. There are no changes in the packet formats on the wire, only changes to the rules and algorithms governing how the protocol is used. The biggest change is an enhancement to the scalable timer algorithm for calculating when to send RTCP packets in order to minimize transmission in excess of the intended rate when many participants join a session simultaneously.
このメモのテキストの大部分はそれが時代遅れにするRFC1889と同じです。 ワイヤのパケット・フォーマットにおける変化ではなく、規則とアルゴリズムへのプロトコルがどう使用されているかを治める変化しかありません。 最も大きい変化は多くの関係者が同時にセッションに参加するとき、意図しているレートを超えてトランスミッションを最小にするためにいつパケットをRTCPに送るかを見込むためのスケーラブルなタイマアルゴリズムへの増進です。
Schulzrinne, et al. Standards Track [Page 1] RFC 3550 RTP July 2003
Schulzrinne、他 規格はRTP2003年7月にRFC3550を追跡します[1ページ]。
Table of Contents
目次
1. Introduction ................................................ 4
1.1 Terminology ............................................ 5
2. RTP Use Scenarios ........................................... 5
2.1 Simple Multicast Audio Conference ...................... 6
2.2 Audio and Video Conference ............................. 7
2.3 Mixers and Translators ................................. 7
2.4 Layered Encodings ...................................... 8
3. Definitions ................................................. 8
4. Byte Order, Alignment, and Time Format ...................... 12
5. RTP Data Transfer Protocol .................................. 13
5.1 RTP Fixed Header Fields ................................ 13
5.2 Multiplexing RTP Sessions .............................. 16
5.3 Profile-Specific Modifications to the RTP Header ....... 18
5.3.1 RTP Header Extension ............................ 18
6. RTP Control Protocol -- RTCP ................................ 19
6.1 RTCP Packet Format ..................................... 21
6.2 RTCP Transmission Interval ............................. 24
6.2.1 Maintaining the Number of Session Members ....... 28
6.3 RTCP Packet Send and Receive Rules ..................... 28
6.3.1 Computing the RTCP Transmission Interval ........ 29
6.3.2 Initialization .................................. 30
6.3.3 Receiving an RTP or Non-BYE RTCP Packet ......... 31
6.3.4 Receiving an RTCP BYE Packet .................... 31
6.3.5 Timing Out an SSRC .............................. 32
6.3.6 Expiration of Transmission Timer ................ 32
6.3.7 Transmitting a BYE Packet ....................... 33
6.3.8 Updating we_sent ................................ 34
6.3.9 Allocation of Source Description Bandwidth ...... 34
6.4 Sender and Receiver Reports ............................ 35
6.4.1 SR: Sender Report RTCP Packet ................... 36
6.4.2 RR: Receiver Report RTCP Packet ................. 42
6.4.3 Extending the Sender and Receiver Reports ....... 42
6.4.4 Analyzing Sender and Receiver Reports ........... 43
6.5 SDES: Source Description RTCP Packet ................... 45
6.5.1 CNAME: Canonical End-Point Identifier SDES Item . 46
6.5.2 NAME: User Name SDES Item ....................... 48
6.5.3 EMAIL: Electronic Mail Address SDES Item ........ 48
6.5.4 PHONE: Phone Number SDES Item ................... 49
6.5.5 LOC: Geographic User Location SDES Item ......... 49
6.5.6 TOOL: Application or Tool Name SDES Item ........ 49
6.5.7 NOTE: Notice/Status SDES Item ................... 50
6.5.8 PRIV: Private Extensions SDES Item .............. 50
6.6 BYE: Goodbye RTCP Packet ............................... 51
6.7 APP: Application-Defined RTCP Packet ................... 52
7. RTP Translators and Mixers .................................. 53
7.1 General Description .................................... 53
1. 序論… 4 1.1用語… 5 2. RTPはシナリオを使用します… 5 2.1の簡単なマルチキャストオーディオコンファレンス… 6 2.2のオーディオとテレビ会議システム… 7 2.3人のミキサーと翻訳者… 7 2.4はEncodingsを層にしました… 8 3. 定義… 8 4. バイトオーダー、整列、および時間形式… 12 5. RTPデータ転送プロトコル… 13 5.1 RTPはヘッダーフィールドを修理しました… 13 5.2 マルチプレクシングRTPセッション… 16 5.3 RTPヘッダーへのプロフィール特有の変更… 18 5.3 .1 RTPヘッダー拡張子… 18 6. RTPはプロトコルを制御します--RTCP。 19 6.1 RTCPパケット・フォーマット… 21 6.2RTCPトランスミッション間隔… 24 6.2 .1 セッションメンバーの数を維持します… 28 6.3RTCPパケットは、規則を送って、受け取ります… 28 6.3 .1 RTCPトランスミッション間隔を計算します… 29 6.3 .2初期設定… 30 6.3 .3 RTPか非不戦勝RTCPパケットを受けます… 31 6.3 .4 RTCPさようならパケットを受けます… 31 6.3 .5 SSRCからのタイミング… 32 6.3 .6 トランスミッションタイマの満了… 32 6.3 .7 さようならパケットを伝えます… 33 6.3 .8アップデート、私たち、_は発信しました… 34 6.3 .9 ソース記述帯域幅の配分… 34 6.4 送付者と受信機レポート… 35 6.4 .1SR: 送付者レポートRTCPパケット… 36 6.4 .2RR: 受信機レポートRTCPパケット… 42 6.4 .3 送付者と受信機を広げるのは報告します… 42 6.4 .4 送付者と受信機を分析するのは報告します… 43 6.5SDES: ソース記述RTCPパケット… 45 6.5 .1CNAME: 正準なエンドポイント識別子SDESの品目. 46 6.5.2名: ユーザ名前SDESの品目… 48 6.5 .3 メール: 電子メールアドレスSDESの品目… 48 6.5 .4 電話: 電話番号SDESの品目… 49 6.5 .5LOC: 地理的なユーザ位置のSDESの品目… 49 6.5 .6ツール: アプリケーションかツール名前SDESの品目… 49 6.5 .7注意: 通知/状態SDESの品目… 50 6.5 .8PRIV: 個人的な拡大SDESの品目… 50 6.6 さようなら: さようならのRTCPパケット… 51 6.7装置: アプリケーションで定義されたRTCPパケット… 52 7. RTP翻訳者とミキサー… 53 7.1 一般記述… 53
Schulzrinne, et al. Standards Track [Page 2] RFC 3550 RTP July 2003
Schulzrinne、他 規格はRTP2003年7月にRFC3550を追跡します[2ページ]。
7.2 RTCP Processing in Translators ......................... 55
7.3 RTCP Processing in Mixers .............................. 57
7.4 Cascaded Mixers ........................................ 58
8. SSRC Identifier Allocation and Use .......................... 59
8.1 Probability of Collision ............................... 59
8.2 Collision Resolution and Loop Detection ................ 60
8.3 Use with Layered Encodings ............................. 64
9. Security .................................................... 65
9.1 Confidentiality ........................................ 65
9.2 Authentication and Message Integrity ................... 67
10. Congestion Control .......................................... 67
11. RTP over Network and Transport Protocols .................... 68
12. Summary of Protocol Constants ............................... 69
12.1 RTCP Packet Types ...................................... 70
12.2 SDES Types ............................................. 70
13. RTP Profiles and Payload Format Specifications .............. 71
14. Security Considerations ..................................... 73
15. IANA Considerations ......................................... 73
16. Intellectual Property Rights Statement ...................... 74
17. Acknowledgments ............................................. 74
Appendix A. Algorithms ........................................ 75
Appendix A.1 RTP Data Header Validity Checks ................... 78
Appendix A.2 RTCP Header Validity Checks ....................... 82
Appendix A.3 Determining Number of Packets Expected and Lost ... 83
Appendix A.4 Generating RTCP SDES Packets ...................... 84
Appendix A.5 Parsing RTCP SDES Packets ......................... 85
Appendix A.6 Generating a Random 32-bit Identifier ............. 85
Appendix A.7 Computing the RTCP Transmission Interval .......... 87
Appendix A.8 Estimating the Interarrival Jitter ................ 94
Appendix B. Changes from RFC 1889 ............................. 95
References ...................................................... 100
Normative References ............................................ 100
Informative References .......................................... 100
Authors' Addresses .............................................. 103
Full Copyright Statement ........................................ 104
7.2 翻訳者でのRTCP処理… 55 7.3 ミキサーでのRTCP処理… 57 7.4はミキサーをどっと落させました… 58 8. SSRC識別子配分と使用… 59 8.1 衝突の確率… 59 8.2衝突解決と輪の検出… 60 8.3 層にされたEncodingsと共に使用します。 64 9. セキュリティ… 65 9.1秘密性… 65 9.2の認証とメッセージの保全… 67 10. 混雑コントロール… 67 11. ネットワークとトランスポート・プロトコルの上のRTP… 68 12. プロトコル定数の概要… 69 12.1RTCPパケットはタイプされます… 70 12.2SDESがタイプします… 70 13. RTPプロフィールと有効搭載量書式仕様… 71 14. セキュリティ問題… 73 15. IANA問題… 73 16. 知的所有権は声明を正します… 74 17. 承認… 74 付録A.アルゴリズム… 75 付録A.1 RTPデータヘッダーバリディティチェック… 78 付録A.2 RTCPヘッダーバリディティチェック… 82 パケットの数が予想して、失ったことを決定する付録A.3… 83 RTCP SDESがパケットであると生成する付録A.4… 84 付録A.5構文解析RTCP SDESパケット… 85 無作為の32ビットの識別子を生成する付録A.6… 85 RTCPトランスミッション間隔を計算する付録A.7… 87 Interarrivalジターを見積もっている付録A.8… 94 付録B.はRFC1889から変化します… 95の参照箇所… 100 標準の参照… 100 有益な参照… 100人の作者のアドレス… 103 完全な著作権宣言文… 104
Schulzrinne, et al. Standards Track [Page 3] RFC 3550 RTP July 2003
Schulzrinne、他 規格はRTP2003年7月にRFC3550を追跡します[3ページ]。
1. Introduction
1. 序論
This memorandum specifies the real-time transport protocol (RTP), which provides end-to-end delivery services for data with real-time characteristics, such as interactive audio and video. Those services include payload type identification, sequence numbering, timestamping and delivery monitoring. Applications typically run RTP on top of UDP to make use of its multiplexing and checksum services; both protocols contribute parts of the transport protocol functionality. However, RTP may be used with other suitable underlying network or transport protocols (see Section 11). RTP supports data transfer to multiple destinations using multicast distribution if provided by the underlying network.
このメモはリアルタイムのトランスポート・プロトコル(RTP)を指定します、対話的なオーディオやビデオのように。(トランスポート・プロトコルはデータのための終わりから終わりへのデリバリ・サービスをリアルタイムの特性に提供します)。 それらのサービスはペイロードタイプ確認、系列付番、timestamping、および配送モニターを含んでいます。 アプリケーションはマルチプレクシングとチェックサムサービスを利用するためにUDPの上でRTPを通常実行します。 両方のプロトコルはトランスポート・プロトコルの機能性の部分を寄付します。 しかしながら、RTPは他の適当な基本的なネットワークかトランスポート・プロトコルと共に使用されるかもしれません(セクション11を見てください)。 RTPは、基本的なネットワークによって提供されるならマルチキャスト分配を使用することで複数の目的地にデータ転送をサポートします。
Note that RTP itself does not provide any mechanism to ensure timely delivery or provide other quality-of-service guarantees, but relies on lower-layer services to do so. It does not guarantee delivery or prevent out-of-order delivery, nor does it assume that the underlying network is reliable and delivers packets in sequence. The sequence numbers included in RTP allow the receiver to reconstruct the sender's packet sequence, but sequence numbers might also be used to determine the proper location of a packet, for example in video decoding, without necessarily decoding packets in sequence.
RTP自身がタイムリーな配送を確実にするか、または他のサービスの質保証を提供するためにどんなメカニズムも提供しませんが、そうするために下層サービスに依存することに注意してください。 それは、荷渡しを保証もしませんし、不適切な配送を防ぎもしないで、基本的なネットワークが信頼できて、連続してパケットを提供すると仮定しません。 受信機はRTPに含まれていた一連番号で送付者のパケット系列を再建できますが、また、一連番号はパケットの適切な位置を決定するのに使用されるかもしれません、例えば、ビデオ解読で、必ず連続してパケットを解読するというわけではなくて。
While RTP is primarily designed to satisfy the needs of multi- participant multimedia conferences, it is not limited to that particular application. Storage of continuous data, interactive distributed simulation, active badge, and control and measurement applications may also find RTP applicable.
RTPはマルチ関係者マルチメディア会議の需要を満たすように主として設計されていますが、それはその特定用途に制限されません。 また、連続したデータ、対話的な分配されたシミュレーション、活性バッジ、コントロール、および測定アプリケーションのストレージによって、RTPが適切であることがわかるかもしれません。
This document defines RTP, consisting of two closely-linked parts:
2つの密接に繋がっている部分から成って、このドキュメントはRTPを定義します:
o the real-time transport protocol (RTP), to carry data that has
real-time properties.
o それには、リアルタイムのトランスポート・プロトコル(RTP)であり、データを運ぶために、リアルタイムの特性があります。
o the RTP control protocol (RTCP), to monitor the quality of service
and to convey information about the participants in an on-going
session. The latter aspect of RTCP may be sufficient for "loosely
controlled" sessions, i.e., where there is no explicit membership
control and set-up, but it is not necessarily intended to support
all of an application's control communication requirements. This
functionality may be fully or partially subsumed by a separate
session control protocol, which is beyond the scope of this
document.
o RTPは、サービスの質をモニターして、継続しているセッションのときに関係者に関して情報を伝達するためにプロトコル(RTCP)を制御します。 すなわち、RTCPの後者の局面は「緩く制御された」セッションのために明白な会員資格コントロールとセットアップが全くないところで十分であるかもしれませんが、アプリケーションのコントロールコミュニケーション要件のすべてをサポートすることを必ず意図するというわけではありません。 この機能性は別々のセッション制御プロトコルによって完全か部分的に包括されるかもしれません。(それは、このドキュメントの範囲にあります)。
RTP represents a new style of protocol following the principles of application level framing and integrated layer processing proposed by Clark and Tennenhouse [10]. That is, RTP is intended to be malleable
クラークとTennenhouse[10]によって提案されたアプリケーションレベル縁どりと統合層の処理の原則に従って、RTPはプロトコルの新式を表します。 すなわち、RTPが可鍛性であることを意図します。
Schulzrinne, et al. Standards Track [Page 4] RFC 3550 RTP July 2003
Schulzrinne、他 規格はRTP2003年7月にRFC3550を追跡します[4ページ]。
to provide the information required by a particular application and will often be integrated into the application processing rather than being implemented as a separate layer. RTP is a protocol framework that is deliberately not complete. This document specifies those functions expected to be common across all the applications for which RTP would be appropriate. Unlike conventional protocols in which additional functions might be accommodated by making the protocol more general or by adding an option mechanism that would require parsing, RTP is intended to be tailored through modifications and/or additions to the headers as needed. Examples are given in Sections 5.3 and 6.4.3.
情報を提供するのは、別々の層として実装されるよりむしろ特定用途で必要であり、しばしば手続きの経緯に統合するようになるでしょう。 RTPは故意に完全でないプロトコルフレームワークです。 このドキュメントはRTPが適切であるすべての仕様の向こう側に一般的であると予想されたそれらの機能を指定します。 追加機能がプロトコルをより一般的にするか、または分析するのを必要とするオプションメカニズムを加えることによって設備されるかもしれない従来のプロトコルと異なって、必要に応じて変更、そして/または、追加を通してRTPによってヘッダーに仕立てられることを意図します。 例はセクション5.3と6.4.3で出されます。
Therefore, in addition to this document, a complete specification of RTP for a particular application will require one or more companion documents (see Section 13):
したがって、このドキュメントに加えて、特定用途のためのRTPの完全な仕様は1通以上の仲間ドキュメントを必要とするでしょう(セクション13を見てください):
o a profile specification document, which defines a set of payload
type codes and their mapping to payload formats (e.g., media
encodings). A profile may also define extensions or modifications
to RTP that are specific to a particular class of applications.
Typically an application will operate under only one profile. A
profile for audio and video data may be found in the companion RFC
3551 [1].
o プロフィール仕様ドキュメント。(そのドキュメントは1セットのペイロードタイプコードと(例えば、メディアencodings)をペイロード形式に写像するのを定義します)。 また、プロフィールは拡大か特定のクラスのアプリケーションに特定のRTPへの変更を定義するかもしれません。 通常、アプリケーションは1個のプロフィールだけの下で作動するでしょう。 オーディオとビデオ・データのためのプロフィールは仲間RFC3551[1]で見つけられるかもしれません。
o payload format specification documents, which define how a
particular payload, such as an audio or video encoding, is to be
carried in RTP.
o ペイロード書式仕様ドキュメント。(そのドキュメントはRTPで運ばれるオーディオかビデオのコード化などの特定のペイロードがことである方法を定義します)。
A discussion of real-time services and algorithms for their implementation as well as background discussion on some of the RTP design decisions can be found in [11].
[11]でRTPデザイン決定のいくつかについてのバックグラウンド議論と同様にそれらの実装のためのリアルタイムのサービスとアルゴリズムの議論を見つけることができます。
1.1 Terminology
1.1 用語
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [2] and indicate requirement levels for compliant RTP implementations.
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTが解釈されるのは中でBCP14について説明しました、RFC2119[2]という本書ではことであり、対応するRTP実装のために要件レベルを示すべきであるかをさせましょう。
2. RTP Use Scenarios
2. RTPはシナリオを使用します。
The following sections describe some aspects of the use of RTP. The examples were chosen to illustrate the basic operation of applications using RTP, not to limit what RTP may be used for. In these examples, RTP is carried on top of IP and UDP, and follows the conventions established by the profile for audio and video specified in the companion RFC 3551.
以下のセクションはRTPの使用のいくつかの局面について説明します。 例は、アプリケーションの基本的な操作を例証するためにRTPが使用されるかもしれないことを制限しないようにRTPを使用することで選ばれました。 これらの例では、RTPは仲間RFC3551で指定されたオーディオとビデオのために、IPとUDPの上で運ばれて、プロフィールによって設立されたコンベンションに続きます。
Schulzrinne, et al. Standards Track [Page 5] RFC 3550 RTP July 2003
Schulzrinne、他 規格はRTP2003年7月にRFC3550を追跡します[5ページ]。
2.1 Simple Multicast Audio Conference
2.1 簡単なマルチキャストオーディオコンファレンス
A working group of the IETF meets to discuss the latest protocol document, using the IP multicast services of the Internet for voice communications. Through some allocation mechanism the working group chair obtains a multicast group address and pair of ports. One port is used for audio data, and the other is used for control (RTCP) packets. This address and port information is distributed to the intended participants. If privacy is desired, the data and control packets may be encrypted as specified in Section 9.1, in which case an encryption key must also be generated and distributed. The exact details of these allocation and distribution mechanisms are beyond the scope of RTP.
IETFのワーキンググループは最新のプロトコルドキュメントについて打ち合わせます、声のコミュニケーションにインターネットのIPマルチキャストサービスを利用して。 何らかの配分メカニズムを通して、ワーキンググループいすはポートのマルチキャストグループアドレスと組を得ます。 1つのポートがオーディオデータに使用されます、そして、もう片方がコントロール(RTCP)パケットに使用されます。 このアドレスとポート情報は意図している関係者に配布されます。 プライバシーが望まれているなら、データとコントロールパケットはまた、セクション9.1、どのケースに暗号化キーを生成しなければならないかで指定されて分配されるとして暗号化されるかもしれません。 これらの配分と分配メカニズムの正確な細部はRTPの範囲を超えています。
The audio conferencing application used by each conference participant sends audio data in small chunks of, say, 20 ms duration. Each chunk of audio data is preceded by an RTP header; RTP header and data are in turn contained in a UDP packet. The RTP header indicates what type of audio encoding (such as PCM, ADPCM or LPC) is contained in each packet so that senders can change the encoding during a conference, for example, to accommodate a new participant that is connected through a low-bandwidth link or react to indications of network congestion.
各会議の参加者によって使用された電話による会議アプリケーションはたとえば、20ms持続時間の小さい塊におけるオーディオデータを送ります。 オーディオデータの各塊はRTPヘッダーによって先行されています。 RTPヘッダーとデータはUDPパケットに順番に含まれています。 RTPヘッダーは、例えば、送付者が低バンド幅リンクを通して接される新しい関係者を収容するか、またはネットワークの混雑のしるしに反応するために会議の間、コード化を変えることができるようにどんなタイプのオーディオコード化(PCM、ADPCMまたはLPCなどの)が各パケットに含まれているかを示します。
The Internet, like other packet networks, occasionally loses and reorders packets and delays them by variable amounts of time. To cope with these impairments, the RTP header contains timing information and a sequence number that allow the receivers to reconstruct the timing produced by the source, so that in this example, chunks of audio are contiguously played out the speaker every 20 ms. This timing reconstruction is performed separately for each source of RTP packets in the conference. The sequence number can also be used by the receiver to estimate how many packets are being lost.
そして、インターネットが他のパケット網のように時折損をする、追加注文パケット、可変量の時間までにそれらを遅らせます。 これらの損傷に対処するために、RTPヘッダーは受信機がソースによって生産されたタイミングを再建できるタイミング情報と一連番号を含んでいて、あらゆる20原稿Thisタイミング再建が使い果たされて、この例、オーディオの塊には、スピーカーが近接しているように、別々に会議でRTPパケットの各源に実行されます。 また、一連番号は受信機によって使用されて、何パケットが失われていると見積もることができます。
Since members of the working group join and leave during the conference, it is useful to know who is participating at any moment and how well they are receiving the audio data. For that purpose, each instance of the audio application in the conference periodically multicasts a reception report plus the name of its user on the RTCP (control) port. The reception report indicates how well the current speaker is being received and may be used to control adaptive encodings. In addition to the user name, other identifying information may also be included subject to control bandwidth limits. A site sends the RTCP BYE packet (Section 6.6) when it leaves the conference.
ワーキンググループのメンバーが会議の間、加わって、いなくなるので、だれがいつ何時、参加するか、そして、彼らがオーディオデータをどれくらいよく受け取っているかを知るのは役に立ちます。 そのために会議におけるオーディオアプリケーションの各インスタンス、定期的である、RTCP(コントロール)の上のユーザのレセプションレポートと名前が移植するマルチキャスト。 レセプションレポートは、適応型のencodingsを制御するために現在のスピーカーがどれくらいよく受け取られていて、使用されるかもしれないかを示します。 また、ユーザ名に加えて、他の身元が分かる情報はコントロール帯域幅限界を条件として含まれるかもしれません。 それが会議を出るとき、サイトはRTCP BYEパケット(セクション6.6)を送ります。
Schulzrinne, et al. Standards Track [Page 6] RFC 3550 RTP July 2003
Schulzrinne、他 規格はRTP2003年7月にRFC3550を追跡します[6ページ]。
2.2 Audio and Video Conference
2.2 オーディオとテレビ会議システム
If both audio and video media are used in a conference, they are transmitted as separate RTP sessions. That is, separate RTP and RTCP packets are transmitted for each medium using two different UDP port pairs and/or multicast addresses. There is no direct coupling at the RTP level between the audio and video sessions, except that a user participating in both sessions should use the same distinguished (canonical) name in the RTCP packets for both so that the sessions can be associated.
オーディオとビデオメディアの両方が会議に使用されるなら、それらは別々のRTPセッションとして伝えられます。 すなわち、別々のRTPとRTCPパケットは、各媒体のために2つの異なったUDPポート組、そして/または、マルチキャストアドレスを使用することで伝えられます。 オーディオとビデオセッションの間には、直結が全くRTPレベルにありません、セッションを関連づけることができて、両方のセッションのときに参加するユーザが両方にRTCPパケットで同じ顕著な(正準な)名前を使用するべきであるのを除いて。
One motivation for this separation is to allow some participants in the conference to receive only one medium if they choose. Further explanation is given in Section 5.2. Despite the separation, synchronized playback of a source's audio and video can be achieved using timing information carried in the RTCP packets for both sessions.
この分離に関する1つの動機は彼らが選ぶなら会議の何人かの関係者が1つの媒体だけを受け取るのを許容することです。 セクション5.2で詳細な説明を与えます。 分離にもかかわらず、両方のセッションのためにRTCPパケットで運ばれたタイミング情報を使用することでソースのオーディオとビデオの連動している再生を達成できます。
2.3 Mixers and Translators
2.3 ミキサーと翻訳者
So far, we have assumed that all sites want to receive media data in the same format. However, this may not always be appropriate. Consider the case where participants in one area are connected through a low-speed link to the majority of the conference participants who enjoy high-speed network access. Instead of forcing everyone to use a lower-bandwidth, reduced-quality audio encoding, an RTP-level relay called a mixer may be placed near the low-bandwidth area. This mixer resynchronizes incoming audio packets to reconstruct the constant 20 ms spacing generated by the sender, mixes these reconstructed audio streams into a single stream, translates the audio encoding to a lower-bandwidth one and forwards the lower- bandwidth packet stream across the low-speed link. These packets might be unicast to a single recipient or multicast on a different address to multiple recipients. The RTP header includes a means for mixers to identify the sources that contributed to a mixed packet so that correct talker indication can be provided at the receivers.
今までのところ、私たちは、サイトがそうしたがっているすべてが同じ形式におけるメディアデータを受け取ると思いました。 しかしながら、これはいつも適切であるかもしれないというわけではありません。 1つの領域の関係者が高速ネットワークアクセサリーを楽しむ会議の参加者の大部分への低速リンクを通して接されるケースを考えてください。 皆に下側の帯域幅、減少している品質のオーディオのコード化を使用させることの代わりに、ミキサーと呼ばれるRTP-レベルリレーは低バンド幅領域の近くに置かれるかもしれません。 このミキサーは、スペースが送付者で生成した一定の20msを再建するために入って来るオーディオパケットを再連動させて、これらの再建されたオーディオストリームをただ一つのストリームに混ぜて、下側の帯域幅に1つをコード化するオーディオを翻訳して、下側の帯域幅パケットストリームを低速リンクの反対側に送ります。 これらのパケットは複数の受取人への異なったアドレスに関する独身の受取人かマルチキャストへのユニキャストであるかもしれません。 RTPヘッダーはミキサーが受信機で正しい話し手指示を提供できるように混ぜられたパケットに貢献したソースを特定する手段を入れます。
Some of the intended participants in the audio conference may be connected with high bandwidth links but might not be directly reachable via IP multicast. For example, they might be behind an application-level firewall that will not let any IP packets pass. For these sites, mixing may not be necessary, in which case another type of RTP-level relay called a translator may be used. Two translators are installed, one on either side of the firewall, with the outside one funneling all multicast packets received through a secure connection to the translator inside the firewall. The translator inside the firewall sends them again as multicast packets to a multicast group restricted to the site's internal network.
オーディオ会議の何人かの意図している関係者は、高帯域リンクに接続されるかもしれませんが、IPマルチキャストで直接届いていないかもしれません。 例えば、彼らはどんなIPパケットも通過しないアプリケーションレベルファイアウォールの後ろにいるかもしれません。 これらのサイトに、混合は必要でないかもしれない、その場合、翻訳者と呼ばれる別のタイプのRTP-レベルリレーは使用されるかもしれません。 2人の翻訳者がインストールされます、ファイアウォールのどちらかの側面の1、外のものがファイアウォールの中の翻訳者との安全な接続で受け取られたすべてのマルチキャストパケットを注いでいて。 ファイアウォールの中の翻訳者は再びマルチキャストパケットとしてサイトの内部のネットワークに制限されたマルチキャストグループにそれらを送ります。
Schulzrinne, et al. Standards Track [Page 7] RFC 3550 RTP July 2003
Schulzrinne、他 規格はRTP2003年7月にRFC3550を追跡します[7ページ]。
Mixers and translators may be designed for a variety of purposes. An example is a video mixer that scales the images of individual people in separate video streams and composites them into one video stream to simulate a group scene. Other examples of translation include the connection of a group of hosts speaking only IP/UDP to a group of hosts that understand only ST-II, or the packet-by-packet encoding translation of video streams from individual sources without resynchronization or mixing. Details of the operation of mixers and translators are given in Section 7.
ミキサーと翻訳者はさまざまな目的のために設計されるかもしれません。 例は別々のビデオストリームで個々の人々のイメージをスケーリングするビデオミキサーであり、合成物はグループ場面をシミュレートする1つのビデオストリームの中へのそれらです。 翻訳に関する他の例はST-IIだけを理解しているホストのグループにIP/UDPだけを話しているホストのグループの接続、パケットごとに個々のソースから再同期なしでビデオストリームに関する翻訳をコード化するまたは混合を含んでいます。 ミキサーと翻訳者の操作の詳細はセクション7で明らかにされます。
2.4 Layered Encodings
2.4 層にされたEncodings
Multimedia applications should be able to adjust the transmission rate to match the capacity of the receiver or to adapt to network congestion. Many implementations place the responsibility of rate- adaptivity at the source. This does not work well with multicast transmission because of the conflicting bandwidth requirements of heterogeneous receivers. The result is often a least-common denominator scenario, where the smallest pipe in the network mesh dictates the quality and fidelity of the overall live multimedia "broadcast".
マルチメディア応用は、受信機の容量を合わせるか、またはネットワークの混雑に順応するように通信速度を調整できるべきです。 多くの実装がレート適応性の責任をソースにみなします。 これは異種の受信機に関する闘争帯域幅要件のためにマルチキャスト送信でうまくいきません。 しばしば結果は共通項シナリオです。(そこでは、ネットワークメッシュで最も小さいパイプが総合的なライブマルチメディア「放送」の品質と信義を書き取ります)。
Instead, responsibility for rate-adaptation can be placed at the receivers by combining a layered encoding with a layered transmission system. In the context of RTP over IP multicast, the source can stripe the progressive layers of a hierarchically represented signal across multiple RTP sessions each carried on its own multicast group. Receivers can then adapt to network heterogeneity and control their reception bandwidth by joining only the appropriate subset of the multicast groups.
代わりに、層にされた伝動装置による層にされたコード化を結合することによって、レート適合への責任を受信機に置くことができます。 IPマルチキャストの上のRTPの文脈では、ソースはそれ自身のマルチキャストグループでそれぞれ運ばれた複数のRTPセッションの向こう側に階層的に表された信号の進歩的な層にしまをつけることができます。 受信機は、マルチキャストグループの適切な部分集合だけを接合することによって、次に、ネットワークの異種性に順応して、それらのレセプション帯域幅を制御できます。
Details of the use of RTP with layered encodings are given in Sections 6.3.9, 8.3 and 11.
層にされたencodingsとのRTPの使用の詳細はセクション6.3.9、8.3、および11で明らかにされます。
3. Definitions
3. 定義
RTP payload: The data transported by RTP in a packet, for
example audio samples or compressed video data. The payload
format and interpretation are beyond the scope of this document.
RTPペイロード: パケット、例えば、オーディオのサンプルまたは圧縮されたビデオデータでRTPによって輸送されたデータ。 ペイロード形式と解釈はこのドキュメントの範囲を超えています。
RTP packet: A data packet consisting of the fixed RTP header, a
possibly empty list of contributing sources (see below), and the
payload data. Some underlying protocols may require an
encapsulation of the RTP packet to be defined. Typically one
packet of the underlying protocol contains a single RTP packet,
but several RTP packets MAY be contained if permitted by the
encapsulation method (see Section 11).
RTPパケット: 固定RTPヘッダーから成るデータ・パケット、ソース(以下を見る)、およびペイロードデータを寄付することによると空のリスト。 いくつかの基本的なプロトコルが、RTPパケットのカプセル化が定義されるのを必要とするかもしれません。 通常、基本的なプロトコルの1つのパケットが単一のRTPパケットを含んでいますが、カプセル化メソッドで受入れられるなら、いくつかのRTPパケットが含まれるかもしれません(セクション11を見てください)。
Schulzrinne, et al. Standards Track [Page 8] RFC 3550 RTP July 2003
Schulzrinne、他 規格はRTP2003年7月にRFC3550を追跡します[8ページ]。
RTCP packet: A control packet consisting of a fixed header part
similar to that of RTP data packets, followed by structured
elements that vary depending upon the RTCP packet type. The
formats are defined in Section 6. Typically, multiple RTCP
packets are sent together as a compound RTCP packet in a single
packet of the underlying protocol; this is enabled by the length
field in the fixed header of each RTCP packet.
RTCPパケット: RTCPパケットタイプに頼っていて、異なる構造化された要素が支えたRTPデータ・パケットのものと同様の固定ヘッダー部分から成るコントロールパケット。 書式はセクション6で定義されます。 通常、合成RTCPパケットとして基本的なプロトコルの単一のパケットで複数のRTCPパケットを一緒に送ります。 これはそれぞれのRTCPパケットの固定ヘッダーの長さの分野によって可能にされます。
Port: The "abstraction that transport protocols use to
distinguish among multiple destinations within a given host
computer. TCP/IP protocols identify ports using small positive
integers." [12] The transport selectors (TSEL) used by the OSI
transport layer are equivalent to ports. RTP depends upon the
lower-layer protocol to provide some mechanism such as ports to
multiplex the RTP and RTCP packets of a session.
ポート: 「トランスポート・プロトコルが与えられたホストコンピュータの中の複数の目的地の中で区別するのに使用する抽象化。」 「TCP/IPプロトコルはわずかな正の整数を使用することでポートを特定します。」 [12] OSIトランスポート層によって使用される輸送セレクタ(TSEL)はポートに同等です。 RTPは、セッションのRTPとRTCPパケットを多重送信するためにポートとして何らかのメカニズムにそのようなものを供給するために下位層プロトコルによります。
Transport address: The combination of a network address and port
that identifies a transport-level endpoint, for example an IP
address and a UDP port. Packets are transmitted from a source
transport address to a destination transport address.
アドレスを輸送してください: 例えば、ネットワーク・アドレスの組み合わせ、輸送レベル終点を特定するポート、IPアドレス、およびUDPポート。 パケットはソース輸送アドレスから送付先輸送アドレスまで伝えられます。
RTP media type: An RTP media type is the collection of payload
types which can be carried within a single RTP session. The RTP
Profile assigns RTP media types to RTP payload types.
RTPメディアはタイプされます: RTPメディアタイプはただ一つのRTPセッション以内に運ぶことができるペイロードタイプの収集です。 RTP ProfileはRTPペイロードタイプにRTPメディアタイプを選任します。
Multimedia session: A set of concurrent RTP sessions among a
common group of participants. For example, a videoconference
(which is a multimedia session) may contain an audio RTP session
and a video RTP session.
マルチメディアセッション: 関係者の一般的なグループの1セットの同時発生のRTPセッション。 例えば、ビデオ会議(マルチメディアセッションである)はオーディオRTPセッションとビデオRTPセッションを含むかもしれません。
RTP session: 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 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とコミュニケートする1セットの関係者の中の協会。 関係者は同時に、複数のRTPセッションにかかわるかもしれません。 マルチメディアセッションでは、コード化自体がただ一つのデータ・ストリームの中にマルチメディアを多重送信しない場合、各媒体はそれ自身のRTCPパケットとの別々のRTPセッションのときに通常運ばれます。 関係者は、異なったセッションのレセプションで異なった組の送付先輸送アドレス(1組の輸送アドレスはRTPとRTCPのために1つのネットワーク・アドレスと1組のポートを包括する)を使用することで複数のRTPセッションに区別します。 RTPセッションのすべての関係者がIPマルチキャストに関するケースのように一般的な目的地輸送アドレス組を共有するかもしれませんか、または各関係者にとって、組は異なるかもしれません、個々のユニキャストネットワーク・アドレスとポート組のケースのように。 ユニキャスト場合では、関係者は、セッションのときに他のすべての関係者からポートの同じ組を使用することで受信するか、またはそれぞれにポートの異なった組を使用するかもしれません。
Schulzrinne, et al. Standards Track [Page 9] RFC 3550 RTP July 2003
Schulzrinne、他 規格はRTP2003年7月にRFC3550を追跡します[9ページ]。
The distinguishing feature of an RTP session is that each
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かCSRC(また、以下では、定義される)としてのRTPかRTCPの関係者のいずれによっても伝えられたSSRC識別子を受け取ることができるものから成ります。 例えば、各関係者が別々のポート組で他の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フレームワークはここで定義された変化を許容しますが、通常、特定の制御プロトコルかアプリケーション設計がこれらの変化に規制を課すでしょう。
Synchronization source (SSRC): The source of a stream of RTP
packets, identified by a 32-bit numeric SSRC identifier carried in
the RTP header so as not to be dependent upon the network address.
All packets from a synchronization source form part of the same
timing and sequence number space, so a receiver groups packets by
synchronization source for playback. Examples of synchronization
sources include the sender of a stream of packets derived from a
signal source such as a microphone or a camera, or an RTP mixer
(see below). A synchronization source may change its data format,
e.g., audio encoding, over time. The SSRC identifier is a
randomly chosen value meant to be globally unique within a
particular RTP session (see Section 8). A participant need not
use the same SSRC identifier for all the RTP sessions in a
multimedia session; the binding of the SSRC identifiers is
provided through RTCP (see Section 6.5.1). If a participant
generates multiple streams in one RTP session, for example from
separate video cameras, each MUST be identified as a different
SSRC.
同期ソース(SSRC): ネットワーク・アドレスに依存していないようにRTPヘッダーで運ばれた32ビットの数値SSRC識別子によって特定されたRTPパケットの水源。 同期ソースからのすべてのパケットが同じタイミングと一連番号スペースの一部を形成するので、受信機は再生のために同期ソースでパケットを分類します。 同期ソースに関する例はマイクロホン、カメラ、またはRTPミキサーなどの信号源から得られたパケットの流れの送付者を含んでいます(以下を見てください)。 同期ソースは時間、データの形式、例えば、オーディオコード化を変えるかもしれません。 SSRC識別子は特定のRTPセッション以内にグローバルに特有であることが意味された手当たりしだいに選ばれた値(セクション8を見る)です。 関係者はマルチメディアセッションにおけるすべてのRTPセッションに同じSSRC識別子を使用する必要はありません。 RTCPを通してSSRC識別子の結合を提供します(セクション6.5.1を見てください)。 関係者が1つのRTPセッションのときに複数のストリームを生成するなら、例えば、別々のビデオカメラと、異なったSSRCとしてそれぞれを特定しなければなりません。
Contributing source (CSRC): A source of a stream of RTP packets
that has contributed to the combined stream produced by an RTP
mixer (see below). The mixer inserts a list of the SSRC
identifiers of the sources that contributed to the generation of a
particular packet into the RTP header of that packet. This list
is called the CSRC list. An example application is audio
conferencing where a mixer indicates all the talkers whose speech
貢献しているソース(CSRC): 結合したストリームに貢献したRTPパケットの水源はRTPミキサーで生産しました(以下を見てください)。 ミキサーは特定のパケットの世代に貢献したソースに関するSSRC識別子のリストをそのパケットのRTPヘッダーに挿入します。 このリストはCSRCリストと呼ばれます。 例のアプリケーションがミキサーがすべての話し手を示すところの電話による会議である、スピーチ
Schulzrinne, et al. Standards Track [Page 10] RFC 3550 RTP July 2003
Schulzrinne、他 規格はRTP2003年7月にRFC3550を追跡します[10ページ]。
was combined to produce the outgoing packet, allowing the receiver
to indicate the current talker, even though all the audio packets
contain the same SSRC identifier (that of the mixer).
出発しているパケットを作り出すために、すべてのオーディオパケットが同じSSRC識別子(ミキサーのもの)を含んでいますが、受信機が現在の話し手を示すのを許容して、結合されました。
End system: An application that generates the content to be sent
in RTP packets and/or consumes the content of received RTP
packets. An end system can act as one or more synchronization
sources in a particular RTP session, but typically only one.
システムを終わらせてください: それが内容であることを作るアプリケーションは、RTPパケットを送る、そして/または、容認されたRTPパケットの内容を消費します。 エンドシステムは1つ以上の同期ソースとしてしかし、特定のRTPセッション、通常1だけで作動できます。
Mixer: An intermediate system that receives RTP packets from one
or more sources, possibly changes the data format, combines the
packets in some manner and then forwards a new RTP packet. Since
the timing among multiple input sources will not generally be
synchronized, the mixer will make timing adjustments among the
streams and generate its own timing for the combined stream.
Thus, all data packets originating from a mixer will be identified
as having the mixer as their synchronization source.
ミキサー: 1つ以上のソースからRTPパケットを受けて、ことによるとデータの形式を変えて、何らかの方法でパケットを結合して、次に新しいRTPパケットを進める中間システム。 複数の入力ソースの中のタイミングが一般に同期しないので、ミキサーは、流れの中でタイミング調整をして、それ自身の結合した流れのタイミングを発生させるでしょう。 したがって、ミキサーから発するすべてのデータ・パケットが彼らの同期ソースとしてミキサーを持っているとして特定されるでしょう。
Translator: An intermediate system that forwards RTP packets
with their synchronization source identifier intact. Examples of
translators include devices that convert encodings without mixing,
replicators from multicast to unicast, and application-level
filters in firewalls.
翻訳者: それらの同期ソース識別子が完全な状態でパケットをRTPに送る中間システム。 翻訳者の例は混合なしでencodingsを変換する装置、マルチキャストからユニキャストまでの反復子、およびファイアウォールのアプリケーションレベルフィルタを含んでいます。
Monitor: An application that receives RTCP packets sent by
participants in an RTP session, in particular the reception
reports, and estimates the current quality of service for
distribution monitoring, fault diagnosis and long-term statistics.
The monitor function is likely to be built into the application(s)
participating in the session, but may also be a separate
application that does not otherwise participate and does not send
or receive the RTP data packets (since they are on a separate
port). These are called third-party monitors. It is also
acceptable for a third-party monitor to receive the RTP data
packets but not send RTCP packets or otherwise be counted in the
session.
以下をモニターしてください。 RTCPパケットを受けるアプリケーションは、RTPセッション、特にレセプションレポートの関係者で発信して、物流監視、欠点診断、および長期の統計のために現在のサービスの質を見積もっています。 モニター機能はセッションのときに参加しながら、アプリケーションが組み込まれそうです、RTPデータ・パケットをまた、そうでなければ参加しない別々のアプリケーションであるかもしれなく、送るか、または受けませんが(別々のポートの上にそれらがあるので)。 これらは第三者モニターと呼ばれます。 また、第三者モニターがRTPデータ・パケットを受けますが、パケットをRTCPに送らないか、またはそうでなければ、セッションのときに数えられるのも、許容できます。
Non-RTP means: Protocols and mechanisms that may be needed in
addition to RTP to provide a usable service. In particular, for
multimedia conferences, a control protocol may distribute
multicast addresses and keys for encryption, negotiate the
encryption algorithm to be used, and define dynamic mappings
between RTP payload type values and the payload formats they
represent for formats that do not have a predefined payload type
value. Examples of such protocols include the Session Initiation
Protocol (SIP) (RFC 3261 [13]), ITU Recommendation H.323 [14] and
applications using SDP (RFC 2327 [15]), such as RTSP (RFC 2326
[16]). For simple
非RTPは以下を意味します。 RTPに加えて使用可能なサービスを提供するのが必要であるかもしれないプロトコルとメカニズム。 制御プロトコルは、マルチメディア会議のために、特に、暗号化のためにマルチキャストアドレスとキーを配布して、使用されるために暗号化アルゴリズムを交渉して、彼らが事前に定義されたペイロードが値をタイプしない形式のために表すRTPペイロードタイプ値とペイロード書式の間のダイナミックなマッピングを定義するかもしれません。 そのようなプロトコルに関する例がSession Initiationプロトコル(SIP)を含んでいる、(RFC3261[13])、ITU Recommendation H.323[14]、およびSDPを使用するアプリケーション、(RTSPなどのRFC2327[15])、(RFC2326[16])。 簡単
Schulzrinne, et al. Standards Track [Page 11] RFC 3550 RTP July 2003
Schulzrinne、他 規格はRTP2003年7月にRFC3550を追跡します[11ページ]。
applications, electronic mail or a conference database may also be
used. The specification of such protocols and mechanisms is
outside the scope of this document.
また、アプリケーション、電子メールまたは会議データベースが使用されるかもしれません。 このドキュメントの範囲の外にそのようなプロトコルとメカニズムの仕様があります。
4. Byte Order, Alignment, and Time Format
4. バイトオーダー、整列、および時間形式
All integer fields are carried in network byte order, that is, most significant byte (octet) first. This byte order is commonly known as big-endian. The transmission order is described in detail in [3]. Unless otherwise noted, numeric constants are in decimal (base 10).
すべての整数野原が最初に、すなわち、ネットワークバイトオーダー、最も重要なバイト(八重奏)で運ばれます。 このバイトオーダーはビッグエンディアンとして一般的に知られています。 トランスミッション命令は[3]で詳細に説明されます。 別の方法で注意されない場合、小数(ベース10)には数値定数があります。
All header data is aligned to its natural length, i.e., 16-bit fields are aligned on even offsets, 32-bit fields are aligned at offsets divisible by four, etc. Octets designated as padding have the value zero.
すべてのヘッダー・データが自然な長さに並べられて、すなわち、16ビットの分野はオフセットのときにさえ並べられて、32ビットの分野は4などで分割可能なオフセットのときに並べられます。 詰め物として指定された八重奏は値ゼロを持っています。
Wallclock time (absolute date and time) is represented using the timestamp format of the Network Time Protocol (NTP), which is in seconds relative to 0h UTC on 1 January 1900 [4]. The full resolution NTP timestamp is a 64-bit unsigned fixed-point number with the integer part in the first 32 bits and the fractional part in the last 32 bits. In some fields where a more compact representation is appropriate, only the middle 32 bits are used; that is, the low 16 bits of the integer part and the high 16 bits of the fractional part. The high 16 bits of the integer part must be determined independently.
Wallclock時間(絶対日時)は、秒に1900年1月1日[4]の0h UTCに比例しているNetwork Timeプロトコル(NTP)のタイムスタンプ形式を使用することで表されます。 完全な解決NTPタイムスタンプは整数部が最初の32ビットにあって、断片的な部分が最後の32ビットにある64ビットの無記名の固定小数点数です。 よりコンパクトな表現が適切であるいくつかの分野では、中くらいの32ビットだけが使用されています。 それはそうであり、整数部と高い16のものの低16ビットは断片的な部分のビットです。 整数部の高い16ビットは独自に決定していなければなりません。
An implementation is not required to run the Network Time Protocol in order to use RTP. Other time sources, or none at all, may be used (see the description of the NTP timestamp field in Section 6.4.1). However, running NTP may be useful for synchronizing streams transmitted from separate hosts.
実現は、RTPを使用するためにNetwork Timeプロトコルを走らせるのに必要ではありません。 他の時間ソース、または全くなにも使用されないかもしれません(セクション6.4.1における、NTPタイムスタンプ分野の記述を見てください)。 しかしながら、走行NTPは別々のホストから伝えられた流れを同時にさせることの役に立つかもしれません。
The NTP timestamp will wrap around to zero some time in the year 2036, but for RTP purposes, only differences between pairs of NTP timestamps are used. So long as the pairs of timestamps can be assumed to be within 68 years of each other, using modular arithmetic for subtractions and comparisons makes the wraparound irrelevant.
NTPタイムスタンプはいつか、2036年の間ゼロに巻きつけられるでしょうが、RTP目的のために、組のNTPタイムスタンプの唯一の違いが使用されています。 互いの68年以内に、タイムスタンプの組があると思うことができる限り、引き算と比較に合同算術を使用するのに巻きつけて着るドレスは無関係になります。
Schulzrinne, et al. Standards Track [Page 12] RFC 3550 RTP July 2003
Schulzrinne、他 規格はRTP2003年7月にRFC3550を追跡します[12ページ]。
5. RTP Data Transfer Protocol
5. RTPデータ転送プロトコル
5.1 RTP Fixed Header Fields
5.1 ヘッダーフィールドが修理されたRTP
The RTP header has the following format:
RTPヘッダーには、以下の形式があります:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC|M| 太平洋標準時| 一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイムスタンプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 同期ソース(SSRC)識別子| +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | ソース(CSRC)識別子を寄付します。| | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The first twelve octets are present in every RTP packet, while the list of CSRC identifiers is present only when inserted by a mixer. The fields have the following meaning:
最初の12の八重奏があらゆるRTPパケットに存在しています、ミキサーによって挿入される場合にだけ、CSRC識別子のリストは存在していますが。 分野には、以下の意味があります:
version (V): 2 bits
This field identifies the version of RTP. The version defined by
this specification is two (2). (The value 1 is used by the first
draft version of RTP and the value 0 is used by the protocol
initially implemented in the "vat" audio tool.)
バージョン(V): Thisがさばく2ビットはRTPのバージョンを特定します。 この仕様で定義されたバージョンは2(2)です。 (値1はRTPの最初の草案バージョンによって使用されて、値0は初めは「大タンク」オーディオツールで実行されたプロトコルによって使用されます。)
padding (P): 1 bit
If the padding bit is set, the packet contains one or more
additional padding octets at the end which are not part of the
payload. The last octet of the padding contains a count of how
many padding octets should be ignored, including itself. Padding
may be needed by some encryption algorithms with fixed block sizes
or for carrying several RTP packets in a lower-layer protocol data
unit.
詰め物(P): 詰め物が噛み付いた1ビットのIfは用意ができていて、パケットは終わりのペイロードの一部でない1つ以上の追加詰め物八重奏を含んでいます。 詰め物の最後の八重奏はそれ自体を含んでいて、いくつの詰め物八重奏が無視されるべきであるかに関するカウントを含んでいます。 詰め物が固定ブロック・サイズがあるいくつかの暗号化アルゴリズムか下位層プロトコルデータ単位でいくつかのRTPパケットを運ぶのに必要であるかもしれません。
extension (X): 1 bit
If the extension bit is set, the fixed header MUST be followed by
exactly one header extension, with a format defined in Section
5.3.1.
拡大(X): 拡大が噛み付いた1ビットのIfは用意ができて、まさに1つのヘッダー拡大が固定ヘッダーのあとに続かなければなりません、書式がセクション5.3.1で定義されている状態で。
CSRC count (CC): 4 bits
The CSRC count contains the number of CSRC identifiers that follow
the fixed header.
CSRCは数えます(CCします): CSRCが数える4ビットは固定ヘッダーに続くCSRC識別子の数を含んでいます。
Schulzrinne, et al. Standards Track [Page 13] RFC 3550 RTP July 2003
Schulzrinne、他 規格はRTP2003年7月にRFC3550を追跡します[13ページ]。
marker (M): 1 bit
The interpretation of the marker is defined by a profile. It is
intended to allow significant events such as frame boundaries to
be marked in the packet stream. A profile MAY define additional
marker bits or specify that there is no marker bit by changing the
number of bits in the payload type field (see Section 5.3).
マーカー(M): 1ビット、マーカーの解釈はプロフィールによって定義されます。 フレーム境界などの重大な行事がパケットの流れでマークされるのを許容するのは意図しています。 プロフィールは、追加マーカービットを定義するか、またはペイロードタイプ分野のビットの数を変えることによって噛み付かれたマーカーが全くないと指定するかもしれません(セクション5.3を見てください)。
payload type (PT): 7 bits
This field identifies the format of the RTP payload and determines
its interpretation by the application. A profile MAY specify a
default static mapping of payload type codes to payload formats.
Additional payload type codes MAY be defined dynamically through
non-RTP means (see Section 3). A set of default mappings for
audio and video is specified in the companion RFC 3551 [1]. An
RTP source MAY change the payload type during a session, but this
field SHOULD NOT be used for multiplexing separate media streams
(see Section 5.2).
ペイロードタイプ(太平洋標準時の): Thisがさばく7ビットは、RTPペイロードの形式を特定して、アプリケーションで解釈を決定します。 プロフィールはペイロードタイプコードのデフォルトの静的なマッピングをペイロード形式に指定するかもしれません。 追加ペイロードタイプコードは非RTP手段でダイナミックに定義されるかもしれません(セクション3を見てください)。 オーディオとビデオのための1セットのデフォルトマッピングは仲間RFC3551[1]で指定されます。 RTPソースはしかし、セッション、この分野SHOULD NOTの間、ペイロードタイプを変えるかもしれません。マルチプレクシングの別々のメディアの流れには、使用されてください(セクション5.2を見てください)。
A receiver MUST ignore packets with payload types that it does not
understand.
受信機はそれが理解していないペイロードタイプがあるパケットを無視しなければなりません。
sequence number: 16 bits
The sequence number increments by one for each RTP data packet
sent, and may be used by the receiver to detect packet loss and to
restore packet sequence. The initial value of the sequence number
SHOULD be random (unpredictable) to make known-plaintext attacks
on encryption more difficult, even if the source itself does not
encrypt according to the method in Section 9.1, because the
packets may flow through a translator that does. Techniques for
choosing unpredictable numbers are discussed in [17].
一連番号: 一連番号がそれぞれのRTPデータ・パケットあたり1つ増加する16ビットは送られて、受信機によって使用されて、パケット損失を検出して、パケット系列を回復するかもしれません。 初期の値、一連番号SHOULDでは、暗号化に対する知られている平文攻撃をより難しくするように無作為であってください(予測できない)、中の方法によると、ソース自体がセクション9.1をコード化しないでも、パケットがそれがする翻訳者を通して流れるかもしれないので。 [17]で予測できない数を選ぶためのテクニックについて議論します。
timestamp: 32 bits
The timestamp reflects the sampling instant of the first octet in
the RTP data packet. The sampling instant MUST be derived from a
clock that increments monotonically and linearly in time to allow
synchronization and jitter calculations (see Section 6.4.1). The
resolution of the clock MUST be sufficient for the desired
synchronization accuracy and for measuring packet arrival jitter
(one tick per video frame is typically not sufficient). The clock
frequency is dependent on the format of data carried as payload
and is specified statically in the profile or payload format
specification that defines the format, or MAY be specified
dynamically for payload formats defined through non-RTP means. If
RTP packets are generated periodically, the nominal sampling
instant as determined from the sampling clock is to be used, not a
reading of the system clock. As an example, for fixed-rate audio
the timestamp clock would likely increment by one for each
sampling period. If an audio application reads blocks covering
タイムスタンプ: 32ビット、タイムスタンプはRTPデータ・パケットにおける最初の八重奏の標本抽出の瞬間を反映します。 同期とジター計算を許容する時間単調に増加して、直線的である時計から標本抽出の瞬間を得なければなりません(セクション6.4.1を見てください)。 時計の解決は必要な同期精度と測定パケット到着ジターに十分であるに違いありません(ビデオフレームあたり1回のカチカチする音は通常十分ではありません)。 クロック周波数は、ペイロードとして運ばれたデータの形式に依存していて、フォーマットを定義するプロフィールかペイロード書式仕様で静的に指定されるか、またはダイナミックに非RTP手段で定義されたペイロード書式に指定されるかもしれません。 RTPパケットが定期的に発生するなら、標本抽出時計から決定するように瞬間を抽出する名目上のことは使用されていることです、システムクロックの読まない。 タイムスタンプ時計がおそらく各サンプリング周期あたり1つ増加する定率オーディオのための例として。 オーディオアプリケーションがブロック覆いを読むなら
Schulzrinne, et al. Standards Track [Page 14] RFC 3550 RTP July 2003
Schulzrinne、他 規格はRTP2003年7月にRFC3550を追跡します[14ページ]。
160 sampling periods from the input device, the timestamp would be
increased by 160 for each such block, regardless of whether the
block is transmitted in a packet or dropped as silent.
入力装置からの160回のサンプリング周期、タイムスタンプはそのような各ブロック単位の160増加するでしょう、ブロックがパケットで伝えられるか、または静かであるとして落とされることにかかわらず。
The initial value of the timestamp SHOULD be random, as for the
sequence number. Several consecutive RTP packets will have equal
timestamps if they are (logically) generated at once, e.g., belong
to the same video frame. Consecutive RTP packets MAY contain
timestamps that are not monotonic if the data is not transmitted
in the order it was sampled, as in the case of MPEG interpolated
video frames. (The sequence numbers of the packets as transmitted
will still be monotonic.)
値に頭文字をつけてください。タイムスタンプSHOULDでは、一連番号のように、無作為であってください。 いくつかの連続したRTPパケットには、それらがすぐに(論理的に)発生すると、等しいタイムスタンプがあるでしょう、例えば、同じビデオフレームに属してください。 データがオーダーで伝えられないで、それは抽出されました、MPEGの場合でビデオフレームを補間するのでことであるなら、連続したRTPパケットは単調でないタイムスタンプを含むかもしれません。 (伝えられるとしてのパケットの一連番号はまだ単調になっているでしょう。)
RTP timestamps from different media streams may advance at
different rates and usually have independent, random offsets.
Therefore, although these timestamps are sufficient to reconstruct
the timing of a single stream, directly comparing RTP timestamps
from different media is not effective for synchronization.
Instead, for each medium the RTP timestamp is related to the
sampling instant by pairing it with a timestamp from a reference
clock (wallclock) that represents the time when the data
corresponding to the RTP timestamp was sampled. The reference
clock is shared by all media to be synchronized. The timestamp
pairs are not transmitted in every data packet, but at a lower
rate in RTCP SR packets as described in Section 6.4.
異なったメディアの流れからのRTPタイムスタンプは、異なった速度で進んで、通常、独立していて、無作為のオフセットを持っているかもしれません。 したがって、これらのタイムスタンプはただ一つの流れのタイミングを再建するために十分ですが、同期には、直接異なったメディアからのRTPタイムスタンプを比較するのは有効ではありません。 代わりに、各媒体において、RTPタイムスタンプに対応するデータが抽出された時を表す基準クロック(wallclock)からのタイムスタンプとそれを対にすることによって、RTPタイムスタンプは標本抽出の瞬間に関連します。 基準クロックは、連動するようにすべてのメディアによって共有されます。 タイムスタンプ組はあらゆるデータ・パケットで伝えられるのではなく、セクション6.4で説明されるようにRTCP SRパケットの低料金で伝えられます。
The sampling instant is chosen as the point of reference for the
RTP timestamp because it is known to the transmitting endpoint and
has a common definition for all media, independent of encoding
delays or other processing. The purpose is to allow synchronized
presentation of all media sampled at the same time.
伝える終点に知られていて、すべてのメディアのために一般的な定義を持っているので、標本抽出の瞬間はRTPタイムスタンプの参照のポイントとして選ばれています、遅れか他の処理をコード化することの如何にかかわらず。 目的は同時に抽出されたすべてのメディアの連動しているプレゼンテーションを許容することです。
Applications transmitting stored data rather than data sampled in
real time typically use a virtual presentation timeline derived
from wallclock time to determine when the next frame or other unit
of each medium in the stored data should be presented. In this
case, the RTP timestamp would reflect the presentation time for
each unit. That is, the RTP timestamp for each unit would be
related to the wallclock time at which the unit becomes current on
the virtual presentation timeline. Actual presentation occurs
some time later as determined by the receiver.
リアルタイムで抽出されたデータよりむしろ記憶されたデータを伝えるアプリケーションが記憶されたデータのそれぞれの媒体の隣のフレームか他のユニットがいつ贈られるべきであるかを決定するwallclock時間から引き出された仮想のプレゼンテーションスケジュールを通常使用します。 この場合、RTPタイムスタンプは各ユニットプレゼンテーション時間を反映するでしょう。 すなわち、各ユニットRTPタイムスタンプはユニットが仮想のプレゼンテーションスケジュールで現在になるwallclock時に関連するでしょう。 実際のプレゼンテーションはその後、受信機で決定するように現れます。
An example describing live audio narration of prerecorded video
illustrates the significance of choosing the sampling instant as
the reference point. In this scenario, the video would be
presented locally for the narrator to view and would be
simultaneously transmitted using RTP. The "sampling instant" of a
video frame transmitted in RTP would be established by referencing
事前に録音されたビデオのライブオーディオナレーションについて説明する例は基準点として標本抽出の瞬間を選ぶ意味を例証します。 このシナリオでは、ビデオは、見るナレーターのために局所的に示されて、同時に、RTPを使用することで送られるでしょう。 RTPで伝えられたビデオフレームの「瞬間を抽出します」は、参照をつけることによって、設立されるでしょう。
Schulzrinne, et al. Standards Track [Page 15] RFC 3550 RTP July 2003
Schulzrinne、他 規格はRTP2003年7月にRFC3550を追跡します[15ページ]。
its timestamp to the wallclock time when that video frame was
presented to the narrator. The sampling instant for the audio RTP
packets containing the narrator's speech would be established by
referencing the same wallclock time when the audio was sampled.
The audio and video may even be transmitted by different hosts if
the reference clocks on the two hosts are synchronized by some
means such as NTP. A receiver can then synchronize presentation
of the audio and video packets by relating their RTP timestamps
using the timestamp pairs in RTCP SR packets.
そのそのビデオフレームがナレーターに贈られたwallclock時までのタイムスタンプ。 ナレーターのスピーチを含むオーディオRTPパケットのための標本抽出の瞬間は、オーディオが抽出されたのと同wallclock時に参照をつけることによって、設置されるでしょう。 2人のホストの上の基準クロックがどうでもNTPなどのように連動するなら、オーディオとビデオは異なったホストによって送られさえするかもしれません。 そして、受信機は、RTCP SRパケットでタイムスタンプ組を使用することでそれらのRTPタイムスタンプについて話すことによって、オーディオとビデオパケットのプレゼンテーションを同時にさせることができます。
SSRC: 32 bits
The SSRC field identifies the synchronization source. This
identifier SHOULD be chosen randomly, with the intent that no two
synchronization sources within the same RTP session will have the
same SSRC identifier. An example algorithm for generating a
random identifier is presented in Appendix A.6. Although the
probability of multiple sources choosing the same identifier is
low, all RTP implementations must be prepared to detect and
resolve collisions. Section 8 describes the probability of
collision along with a mechanism for resolving collisions and
detecting RTP-level forwarding loops based on the uniqueness of
the SSRC identifier. If a source changes its source transport
address, it must also choose a new SSRC identifier to avoid being
interpreted as a looped source (see Section 8.2).
SSRC: SSRCがさばく32ビットは同期ソースを特定します。 この識別子SHOULDが手当たりしだいに選ばれて、いいえ、同じRTPセッション中の2つの同期ソースがそうする意図をもって同じSSRC識別子を持ってください。 無作為の識別子を発生させるための例のアルゴリズムはAppendix A.6に提示されます。 複数のソースが同じ識別子を選ぶという確率が低いのですが、すべてのRTP実現を衝突を検出して、決議するように準備しなければなりません。 セクション8は、衝突を決議して、RTP-レベルを検出するためにSSRC識別子のユニークさに基づく輪を進めながら、メカニズムに伴う衝突確率について説明します。 また、ソースがソース輸送アドレスを変えるなら、それは、輪にされたソースとして解釈されるのを避けるために新しいSSRC識別子を選ばなければなりません(セクション8.2を見てください)。
CSRC list: 0 to 15 items, 32 bits each
The CSRC list identifies the contributing sources for the payload
contained in this packet. The number of identifiers is given by
the CC field. If there are more than 15 contributing sources,
only 15 can be identified. CSRC identifiers are inserted by
mixers (see Section 7.1), using the SSRC identifiers of
contributing sources. For example, for audio packets the SSRC
identifiers of all sources that were mixed together to create a
packet are listed, allowing correct talker indication at the
receiver.
CSRCは記載します: 0〜15の項目、32ビット、CSRCが記載するそれぞれがこのパケットに含まれたペイロードのために貢献しているソースを特定します。 CC分野で識別子の数を与えます。 15以上の貢献しているソースがあれば、15しか特定できません。 貢献しているソースに関するSSRC識別子を使用して、ミキサー(セクション7.1を見る)によってCSRC識別子は挿入されます。 例えば、オーディオパケットに関して、パケットを作成するために一緒に複雑であったすべてのソースのSSRC識別子は記載されています、受信機に正しい話し手指示を許容して。
5.2 Multiplexing RTP Sessions
5.2 マルチプレクシングRTPセッション
For efficient protocol processing, the number of multiplexing points should be minimized, as described in the integrated layer processing design principle [10]. In RTP, multiplexing is provided by the destination transport address (network address and port number) which is different for each RTP session. For example, in a teleconference composed of audio and video media encoded separately, each medium SHOULD be carried in a separate RTP session with its own destination transport address.
効率的なプロトコル処理において、マルチプレクシングポイントの数は最小にされるべきです、統合層の処理設計原理[10]で説明されるように。 RTPに、それぞれのRTPセッションのために異なった送付先輸送アドレス(ネットワーク・アドレスとポートナンバー)でマルチプレクシングを提供します。 例えば、オーディオで構成された電子会議と別々にコード化されたビデオメディア、それぞれの中型のSHOULDでは、それ自身の送付先輸送アドレスとの別々のRTPセッションのときに運ばれてください。
Schulzrinne, et al. Standards Track [Page 16] RFC 3550 RTP July 2003
Schulzrinne、他 規格はRTP2003年7月にRFC3550を追跡します[16ページ]。
Separate audio and video streams SHOULD NOT be carried in a single RTP session and demultiplexed based on the payload type or SSRC fields. Interleaving packets with different RTP media types but using the same SSRC would introduce several problems:
別々のオーディオとビデオストリームSHOULD NOTはペイロードタイプかSSRC分野に基づいてただ一つのRTPセッションのときに運ばれて、反多重送信しました。 異なったRTPメディアでパケットをはさみ込むのはタイプされますが、同じSSRCを使用すると、いくつかの問題が紹介されるでしょう:
1. If, say, two audio streams shared the same RTP session and the
same SSRC value, and one were to change encodings and thus acquire
a different RTP payload type, there would be no general way of
identifying which stream had changed encodings.
1. たとえば、2つのオーディオストリームが同じRTPセッションと同じSSRC値を共有して、1つは、encodingsを変えて、どのストリームがencodingsを変えたかを特定するどんな一般的な方法もあって、その結果、異なったRTPペイロードタイプを取得することがないつもりだったでしょう。
2. An SSRC is defined to identify a single timing and sequence number
space. Interleaving multiple payload types would require
different timing spaces if the media clock rates differ and would
require different sequence number spaces to tell which payload
type suffered packet loss.
2. SSRCは、ただ一つのタイミングと一連番号スペースを特定するために定義されます。 メディアクロックレートが異なって、どのペイロードがタイプされるかがパケット損失を受けたと言うために異なった一連番号空間を必要とするなら、複数のペイロードタイプをはさみ込むのは異なったタイミング空間を必要とするでしょう。
3. The RTCP sender and receiver reports (see Section 6.4) can only
describe one timing and sequence number space per SSRC and do not
carry a payload type field.
3. RTCP送付者と受信機レポート(セクション6.4を見る)は、1SSRCあたりのスペースに1つのタイミングと一連番号しか説明できないで、ペイロードタイプ野原を載せません。
4. An RTP mixer would not be able to combine interleaved streams of
incompatible media into one stream.
4. RTPミキサーは両立しないメディアのはさみ込まれた流れを1つのストリームに合成できないでしょう。
5. Carrying multiple media in one RTP session precludes: the use of
different network paths or network resource allocations if
appropriate; reception of a subset of the media if desired, for
example just audio if video would exceed the available bandwidth;
and receiver implementations that use separate processes for the
different media, whereas using separate RTP sessions permits
either single- or multiple-process implementations.
5. 1つのRTPセッションのときにマルチメディアを運ぶと、以下は排除されます。 適切であるなら、異なることの使用は経路かネットワーク資源配分をネットワークでつなぎます。 レセプション、メディアの部分集合では、望まれているなら、例えば、まさしくオーディオはビデオであるなら利用可能な帯域幅を超えているでしょう。 そして、異なったメディアに別々のプロセスを使用する受信機実装、ところが、別々のRTPセッションを使用すると、シングルか複数のプロセス実現のどちらかが可能にします。
Using a different SSRC for each medium but sending them in the same RTP session would avoid the first three problems but not the last two.
各媒体に異なったSSRCを使用しますが、同じRTPセッションのときにそれらを送ると、最後の2ではなく最初の3つの問題が避けられるでしょう。
On the other hand, multiplexing multiple related sources of the same medium in one RTP session using different SSRC values is the norm for multicast sessions. The problems listed above don't apply: an RTP mixer can combine multiple audio sources, for example, and the same treatment is applicable for all of them. It may also be appropriate to multiplex streams of the same medium using different SSRC values in other scenarios where the last two problems do not apply.
他方では、1つのRTPセッションのときに異なったSSRC値を使用することで同じ媒体の複数の関連する源を多重送信するのは、マルチキャストセッションのための標準です。 上に記載された問題は適用されません: 例えば、RTPミキサーは複数のオーディオソースを結合できます、そして、彼らのすべてに、同じ処理は適切です。 また、同じ媒体の流れを多重送信するのも最後の2つの問題が適用されない他のシナリオで異なったSSRC値を使用するのにおいて適切であるかもしれません。
Schulzrinne, et al. Standards Track [Page 17] RFC 3550 RTP July 2003
Schulzrinne、他 規格はRTP2003年7月にRFC3550を追跡します[17ページ]。
5.3 Profile-Specific Modifications to the RTP Header
5.3 RTPヘッダーへのプロフィール特有の変更
The existing RTP data packet header is believed to be complete for the set of functions required in common across all the application classes that RTP might support. However, in keeping with the ALF design principle, the header MAY be tailored through modifications or additions defined in a profile specification while still allowing profile-independent monitoring and recording tools to function.
既存のRTPデータパケットのヘッダーがRTPがサポートするかもしれないすべてのアプリケーションのクラスの向こう側に一般的で必要である関数群に完全であると信じられています。 しかしながら、ALF設計原理で保つ際に、ヘッダーはプロフィールから独立しているモニターしていて記録しているツールが機能するのをまだ許容している間プロフィール仕様に基づき定義された変更か追加を通して仕立てられるかもしれません。
o The marker bit and payload type field carry profile-specific
information, but they are allocated in the fixed header since many
applications are expected to need them and might otherwise have to
add another 32-bit word just to hold them. The octet containing
these fields MAY be redefined by a profile to suit different
requirements, for example with more or fewer marker bits. If
there are any marker bits, one SHOULD be located in the most
significant bit of the octet since profile-independent monitors
may be able to observe a correlation between packet loss patterns
and the marker bit.
o 固定ヘッダーでは、多くのアプリケーションがそれらを必要とすると予想されて、割り当てます。マーカービットとペイロードタイプ分野がプロフィール特有の情報を運びますが、彼らは、別の方法で、ただそれらを保持するために別の32ビットの単語を加えなければならないかもしれません。 これらの分野を含む八重奏はプロフィールによって再定義されて、異なった要件に合うかもしれません、例えば、より多くか、より少ないマーカービットで。 どんなマーカービットもあります、1SHOULD。プロフィールから独立しているモニターがパケット損失パターンとマーカービットの間の相関関係を観測できるかもしれないので、最も重要なビットの八重奏では、位置してください。
o Additional information that is required for a particular payload
format, such as a video encoding, SHOULD be carried in the payload
section of the packet. This might be in a header that is always
present at the start of the payload section, or might be indicated
by a reserved value in the data pattern.
o 追加情報が運ばれたコネがパケットのペイロード部分であったならビデオのコード化、SHOULDなどの特定のペイロード形式に必要です。 これは、ペイロード部分の始めにいつも出席しているヘッダーにあるか、またはデータパターンで予約された値によって示されるかもしれません。
o If a particular class of applications needs additional
functionality independent of payload format, the profile under
which those applications operate SHOULD define additional fixed
fields to follow immediately after the SSRC field of the existing
fixed header. Those applications will be able to quickly and
directly access the additional fields while profile-independent
monitors or recorders can still process the RTP packets by
interpreting only the first twelve octets.
o 特定のクラスのアプリケーションがペイロード形式の如何にかかわらず追加機能性を必要とするなら、SHOULDが存在のSSRC分野直後続くように追加固定分野を定義するそれらのアプリケーションが作動するプロフィールはヘッダーを修理しました。 プロフィールから独立しているモニターかレコーダーが最初の12の八重奏だけを解釈することによってまだRTPパケットを処理できる間、それらのアプリケーションはすぐに、直接追加分野にアクセスできるでしょう。
If it turns out that additional functionality is needed in common across all profiles, then a new version of RTP should be defined to make a permanent change to the fixed header.
追加機能性がすべてのプロフィールの向こう側に一般的で必要であると判明するなら、RTPの新しいバージョンは、固定ヘッダーへの恒久的変更を作るために定義されるべきです。
5.3.1 RTP Header Extension
5.3.1 RTPヘッダー拡張子
An extension mechanism is provided to allow individual implementations to experiment with new payload-format-independent functions that require additional information to be carried in the RTP data packet header. This mechanism is designed so that the header extension may be ignored by other interoperating implementations that have not been extended.
個々の実装が追加情報がRTPデータパケットのヘッダーで運ばれるのを必要とする新しいペイロード形式独立者機能を実験するのを許容するために拡張機能を提供します。 このメカニズムは、広げられていない他の共同利用実装でヘッダー拡大を無視できるように設計されています。
Schulzrinne, et al. Standards Track [Page 18] RFC 3550 RTP July 2003
Schulzrinne、他 規格はRTP2003年7月にRFC3550を追跡します[18ページ]。
Note that this header extension is intended only for limited use. Most potential uses of this mechanism would be better done another way, using the methods described in the previous section. For example, a profile-specific extension to the fixed header is less expensive to process because it is not conditional nor in a variable location. Additional information required for a particular payload format SHOULD NOT use this header extension, but SHOULD be carried in the payload section of the packet.
このヘッダー拡大が限られた使用のためだけに意図することに注意してください。 前項で説明されたメソッドを使用して、このメカニズムのほとんどの潜在的用途が、より上手にされた別の方法でしょう。 例えばそれが条件付きでないので処理するためにそれほど高価でなく、可変位置で固定ヘッダーへのプロフィール特有の拡大。 特定のペイロードに必要であることで、形式SHOULD NOTが運ばれたコネがパケットのペイロード部分であったならこのヘッダー拡大、しかし、SHOULDを使用するという追加情報。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| defined by profile | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| header extension |
| .... |
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | プロフィールで、定義されます。| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ヘッダー拡大| | .... |
If the X bit in the RTP header is one, a variable-length header extension MUST be appended to the RTP header, following the CSRC list if present. The header extension contains a 16-bit length field that counts the number of 32-bit words in the extension, excluding the four-octet extension header (therefore zero is a valid length). Only a single extension can be appended to the RTP data header. To allow multiple interoperating implementations to each experiment independently with different header extensions, or to allow a particular implementation to experiment with more than one type of header extension, the first 16 bits of the header extension are left open for distinguishing identifiers or parameters. The format of these 16 bits is to be defined by the profile specification under which the implementations are operating. This RTP specification does not define any header extensions itself.
RTPヘッダーのXビットが1であるなら、可変長のヘッダー延長部分をRTPヘッダーに追加しなければなりません、存在しているならCSRCリストに従って。 ヘッダー拡大は拡大における、32ビットの単語の数を数える16ビットの長さの分野を含んでいます、4八重奏の拡張ヘッダーを除いて(したがって、ゼロは有効な長さです)。 RTPデータヘッダーにただ一つの拡大しか追加できません。 異なったヘッダー拡大で独自に複数の共同利用実装を各実験に許容するか、または特定の実装が1つ以上のタイプのヘッダー拡大を実験するのを許容するために、ヘッダー拡大の最初の16ビットは識別子かパラメタを区別するのにおいて開くままにされます。 これらの16ビットの形式は実装が作動しているプロフィール仕様で定義されることです。 このRTP仕様自体は少しのヘッダー拡大も定義しません。
6. RTP Control Protocol -- RTCP
6. RTP制御プロトコル--RTCP
The RTP control protocol (RTCP) is based on the periodic transmission of control packets to all participants in the session, using the same distribution mechanism as the data packets. The underlying protocol MUST provide multiplexing of the data and control packets, for example using separate port numbers with UDP. RTCP performs four functions:
RTP制御プロトコル(RTCP)はセッションのときにすべての関係者へのコントロールパケットの周期的なトランスミッションに基づいています、データ・パケットと同じ分配メカニズムを使用して。 例えば、UDPがある別々のポートナンバーを使用して、基本的なプロトコルはデータとコントロールパケットのマルチプレクシングを提供しなければなりません。 RTCPは4つの機能を実行します:
1. The primary function is to provide feedback on the quality of the
data distribution. This is an integral part of the RTP's role as
a transport protocol and is related to the flow and congestion
control functions of other transport protocols (see Section 10 on
the requirement for congestion control). The feedback may be
directly useful for control of adaptive encodings [18,19], but
experiments with IP multicasting have shown that it is also
1. プライマリ機能は情報配給の品質のフィードバックを提供することです。 これは、トランスポート・プロトコルとしてのRTPの役割の不可欠の部分であり、他のトランスポート・プロトコル(輻輳制御のための要件のセクション10を見る)の流れと輻輳制御機能に関連します。 フィードバックは直接適応型のencodings[18、19]のコントロールの役に立つかもしれませんが、IPマルチキャスティングがある実験は、また、それがそうであることを示しました。
Schulzrinne, et al. Standards Track [Page 19] RFC 3550 RTP July 2003
Schulzrinne、他 規格はRTP2003年7月にRFC3550を追跡します[19ページ]。
critical to get feedback from the receivers to diagnose faults in
the distribution. Sending reception feedback reports to all
participants allows one who is observing problems to evaluate
whether those problems are local or global. With a distribution
mechanism like IP multicast, it is also possible for an entity
such as a network service provider who is not otherwise involved
in the session to receive the feedback information and act as a
third-party monitor to diagnose network problems. This feedback
function is performed by the RTCP sender and receiver reports,
described below in Section 6.4.
分配における欠点を診断するために受信機から反応を得るために、重要です。 レセプションフィードバックレポートをすべての関係者に送るのに、問題を観測している人は、それらの問題がローカルである、またはグローバルであるかを評価できます。 また、IPマルチキャストのような分配メカニズムでは、別の方法でセッションにかかわらないネットワークサービスプロバイダーなどの実体に、ネットワーク問題を診断するために第三者モニターとしてフィードバック情報と行為を受け取るのも可能です。このフィードバック機能はセクション6.4で以下で説明されたRTCP送付者と受信機レポートによって実行されます。
2. RTCP carries a persistent transport-level identifier for an RTP
source called the canonical name or CNAME, Section 6.5.1. Since
the SSRC identifier may change if a conflict is discovered or a
program is restarted, receivers require the CNAME to keep track of
each participant. Receivers may also require the CNAME to
associate multiple data streams from a given participant in a set
of related RTP sessions, for example to synchronize audio and
video. Inter-media synchronization also requires the NTP and RTP
timestamps included in RTCP packets by data senders.
2. RTCPは正準な名前と呼ばれるRTPソースかCNAMEのための永続的な輸送レベル識別子、セクション6.5.1を運びます。 SSRC識別子が、闘争が発見されるか、またはプログラムが再開されるかを変えるかもしれないので、受信機は、CNAMEが各関係者の動向をおさえるのを必要とします。 また、受信機は、CNAMEが関連するRTPセッションの1セットの与えられた関係者から複数のデータ・ストリームを関連づけて、例えばオーディオとビデオを同期させるのを必要とするかもしれません。 また、RTCPパケットにデータ送付者でタイムスタンプを含んでいて、中間体同期はNTPとRTPを必要とします。
3. The first two functions require that all participants send RTCP
packets, therefore the rate must be controlled in order for RTP to
scale up to a large number of participants. By having each
participant send its control packets to all the others, each can
independently observe the number of participants. This number is
used to calculate the rate at which the packets are sent, as
explained in Section 6.2.
3. 最初の2つの機能が、すべての関係者がパケットをRTCPに送るのを必要とします、したがって、RTPが多くの関係者まで拡大するように、レートを制御しなければなりません。 各関係者にコントロールパケットをすべての他のものに送らせることによって、それぞれが独自に関係者の数を観測できます。 この数は、パケットがセクション6.2で説明されるように送られるレートについて計算するのに使用されます。
4. A fourth, OPTIONAL function is to convey minimal session control
information, for example participant identification to be
displayed in the user interface. This is most likely to be useful
in "loosely controlled" sessions where participants enter and
leave without membership control or parameter negotiation. RTCP
serves as a convenient channel to reach all the participants, but
it is not necessarily expected to support all the control
communication requirements of an application. A higher-level
session control protocol, which is beyond the scope of this
document, may be needed.
4. 4分の1、OPTIONAL機能は最小量のセッション制御情報(例えば、ユーザーインタフェースに表示されるべき関与している識別)を伝えることです。 これは「緩く制御された」セッションのときに関係者が会員資格コントロールもパラメタ交渉なしで出入りするところで役に立つ最も傾向があります。 RTCPは参加者各位に届く便利なチャンネルとして勤めますが、すべてのコントロールがアプリケーションのコミュニケーション要件であるとサポートしないと必ず予想されます。 よりハイレベルのセッション制御プロトコル(このドキュメントの範囲にある)が必要であるかもしれません。
Functions 1-3 SHOULD be used in all environments, but particularly in the IP multicast environment. RTP application designers SHOULD avoid mechanisms that can only work in unicast mode and will not scale to larger numbers. Transmission of RTCP MAY be controlled separately for senders and receivers, as described in Section 6.2, for cases such as unidirectional links where feedback from receivers is not possible.
機能1-3SHOULD、すべての環境にもかかわらず、特にIPマルチキャスト環境で、使用されてください。 RTPアプリケーション設計者SHOULDはユニキャストモードで取り組むことができるだけであって、より大きい数に比例しないメカニズムを避けます。 RTCP MAYのトランスミッションが送付者と受信機のために別々にセクション6.2で説明されるように制御されて、ケースのために、単方向としてのそのようなものは受信機からのフィードバックが可能でないところにリンクされます。
Schulzrinne, et al. Standards Track [Page 20] RFC 3550 RTP July 2003
Schulzrinne、他 規格はRTP2003年7月にRFC3550を追跡します[20ページ]。
Non-normative note: In the multicast routing approach
called Source-Specific Multicast (SSM), there is only one sender
per "channel" (a source address, group address pair), and
receivers (except for the channel source) cannot use multicast to
communicate directly with other channel members. The
recommendations here accommodate SSM only through Section 6.2's
option of turning off receivers' RTCP entirely. Future work will
specify adaptation of RTCP for SSM so that feedback from receivers
can be maintained.
非標準の注意: Source特有のMulticast(SSM)と呼ばれるマルチキャストルーティングアプローチには、「チャンネル」(ソースアドレス、グループアドレス組)あたり1人の送付者しかいません、そして、受信機(チャンネルソースを除いた)は他のチャンネルメンバーと共に直接伝達するのにマルチキャストを使用できません。 ここでの推薦は単にセクション6.2の受信機のRTCPを完全にオフにするオプションでSSMを収容します。 今後の活動は、受信機からのフィードバックを維持できるようにRTCPの適合をSSMに指定するでしょう。
6.1 RTCP Packet Format
6.1 RTCPパケット・フォーマット
This specification defines several RTCP packet types to carry a variety of control information:
この仕様はさまざまな制御情報を運ぶためにいくつかのRTCPパケットタイプを定義します:
SR: Sender report, for transmission and reception statistics from
participants that are active senders
SR: トランスミッションのための送付者レポートと活発な送付者である関係者からのレセプション統計
RR: Receiver report, for reception statistics from participants
that are not active senders and in combination with SR for
active senders reporting on more than 31 sources
RR: 活発な送付者でない関係者と31以上のソースに関して報告する活発な送付者のためのSRと組み合わせたレセプション統計のための受信機レポート
SDES: Source description items, including CNAME
SDES: CNAMEを含むソース記述項目
BYE: Indicates end of participation
さようなら: 参加の終わりを示します。
APP: Application-specific functions
装置: アプリケーション具体的な機能
Each RTCP packet begins with a fixed part similar to that of RTP data packets, followed by structured elements that MAY be of variable length according to the packet type but MUST end on a 32-bit boundary. The alignment requirement and a length field in the fixed part of each packet are included to make RTCP packets "stackable". Multiple RTCP packets can be concatenated without any intervening separators to form a compound RTCP packet that is sent in a single packet of the lower layer protocol, for example UDP. There is no explicit count of individual RTCP packets in the compound packet since the lower layer protocols are expected to provide an overall length to determine the end of the compound packet.
それぞれのRTCPパケットは、RTPデータ・パケットのものと同様の固定部分で始まりますが、パケットタイプに従って可変長のものであるかもしれない構造化された要素に従って続きますが、32ビットの境界で終わらなければなりません。 それぞれのパケットの固定一部の整列要求と長さの分野は、RTCPパケットを「スタック可能に」するように含まれています。 下位層プロトコル(例えば、UDP)の単一のパケットで送られる合成RTCPパケットを形成するために少しも介入している分離符なしで複数のRTCPパケットを連結できます。 下位層プロトコルが合成パケットの端を決定するために全長を提供すると予想されて、個々のRTCPパケットをどんな明白なカウントも合成パケットにありません。
Each individual RTCP packet in the compound packet may be processed independently with no requirements upon the order or combination of packets. However, in order to perform the functions of the protocol, the following constraints are imposed:
合成パケットのそれぞれの個々のRTCPパケットはパケットのオーダーか組み合わせのときに要件なしで独自に処理されるかもしれません。 しかしながら、プロトコルの機能を実行するために、以下の規制は課されます:
Schulzrinne, et al. Standards Track [Page 21] RFC 3550 RTP July 2003
Schulzrinne、他 規格はRTP2003年7月にRFC3550を追跡します[21ページ]。
o Reception statistics (in SR or RR) should be sent as often as
bandwidth constraints will allow to maximize the resolution of the
statistics, therefore each periodically transmitted compound RTCP
packet MUST include a report packet.
o 帯域幅規制で統計の解決を最大にするのと同じくらい頻繁にレセプション統計(SRかRRの)を送るべきです、したがって、それぞれの定期的に伝えられた合成RTCPパケットはレポートパケットを含まなければなりません。
o New receivers need to receive the CNAME for a source as soon as
possible to identify the source and to begin associating media for
purposes such as lip-sync, so each compound RTCP packet MUST also
include the SDES CNAME except when the compound RTCP packet is
split for partial encryption as described in Section 9.1.
o 新しい受信機が、できるだけ早くソースを特定して、口パクなどの目的のためにメディアを関連づけ始めるためにCNAMEをソースに受け取る必要があるので、また、合成RTCPパケットが部分的な暗号化のためにセクション9.1で説明されるように分けられる時を除いて、それぞれの合成RTCPパケットはSDES CNAMEを含まなければなりません。
o The number of packet types that may appear first in the compound
packet needs to be limited to increase the number of constant bits
in the first word and the probability of successfully validating
RTCP packets against misaddressed RTP data packets or other
unrelated packets.
o 最初に合成パケットに現れるかもしれないパケットタイプの数は、最初の単語による一定のビットの数と首尾よくmisaddressed RTPデータ・パケットか他の関係ないパケットに対してRTCPパケットを有効にするという確率を増加させるように制限される必要があります。
Thus, all RTCP packets MUST be sent in a compound packet of at least two individual packets, with the following format:
したがって、少なくとも2つの個々のパケットの合成パケットですべてのRTCPパケットを送らなければなりません、以下の形式で:
Encryption prefix: If and only if the compound packet is to be
encrypted according to the method in Section 9.1, it MUST be
prefixed by a random 32-bit quantity redrawn for every compound
packet transmitted. If padding is required for the encryption, it
MUST be added to the last packet of the compound packet.
暗号化接頭語: そして、セクション9.1の方法によると、合成パケットがコード化されるつもりである場合にだけ、あらゆる合成パケットのためのredrawnが伝えた無作為の32ビットの量でそれを前に置かなければなりません。 詰め物が暗号化に必要であるなら、合成パケットの最後のパケットにそれを加えなければなりません。
SR or RR: The first RTCP packet in the compound packet MUST
always be a report packet to facilitate header validation as
described in Appendix A.2. This is true even if no data has been
sent or received, in which case an empty RR MUST be sent, and even
if the only other RTCP packet in the compound packet is a BYE.
SRかRR: いつも合成パケットにおける最初のRTCPパケットはAppendix A.2で説明されるようにヘッダー合法化を容易にするレポートパケットであるに違いありません。 データを全く送らないでも、これが本当であるか、またはその場合、受け取られていて、送られ、合成パケットにおける他の唯一のRTCPパケットがBYEであっても、空のRR MUSTは本当です。
Additional RRs: If the number of sources for which reception
statistics are being reported exceeds 31, the number that will fit
into one SR or RR packet, then additional RR packets SHOULD follow
the initial report packet.
追加RRs: レセプション統計が報告されているソースの数が31、1つのSRかRRパケットに収まる数を超えているなら、追加RRパケットSHOULDは初期のレポートパケットに続きます。
SDES: An SDES packet containing a CNAME item MUST be included
in each compound RTCP packet, except as noted in Section 9.1.
Other source description items MAY optionally be included if
required by a particular application, subject to bandwidth
constraints (see Section 6.3.9).
SDES: それぞれの合成RTCPパケットにCNAMEの品目を含むSDESパケットを含まなければなりません、セクション9.1に述べられるのを除いて。 他のソース記述項目は必要なら特定用途で帯域幅規制を条件として任意に含まれるかもしれません(セクション6.3.9を見てください)。
BYE or APP: Other RTCP packet types, including those yet to be
defined, MAY follow in any order, except that BYE SHOULD be the
last packet sent with a given SSRC/CSRC. Packet types MAY appear
more than once.
さようならか装置: しかし、定義されています、順不同に続くかもしれません、そのBYE SHOULDを除いてことであるには、それらを含んでいて、他のRTCPパケットタイプは与えられたSSRC/CSRCと共に送られた最後のパケットになってください。 パケットタイプは一度より多く見えるかもしれません。
Schulzrinne, et al. Standards Track [Page 22] RFC 3550 RTP July 2003
Schulzrinne、他 規格はRTP2003年7月にRFC3550を追跡します[22ページ]。
An individual RTP participant SHOULD send only one compound RTCP packet per report interval in order for the RTCP bandwidth per participant to be estimated correctly (see Section 6.2), except when the compound RTCP packet is split for partial encryption as described in Section 9.1. If there are too many sources to fit all the necessary RR packets into one compound RTCP packet without exceeding the maximum transmission unit (MTU) of the network path, then only the subset that will fit into one MTU SHOULD be included in each interval. The subsets SHOULD be selected round-robin across multiple intervals so that all sources are reported.
SHOULDが1いつを除いて、正しさ(セクション6.2を見る)に見積もられている関係者あたりのRTCP帯域幅において、整然としているレポート間隔あたり1つの合成RTCPパケットだけに合成RTCPパケットを送る個々のRTP関係者は部分的な暗号化のためにセクション9.1で説明されるように分けられます。 あまりに多くのソースがあれば、ネットワーク経路のマキシマム・トランスミッション・ユニット(MTU)、次に1MTU SHOULDに収まる部分集合だけを超えていなくて1つの合成RTCPパケットにすべての必要なRRパケットに合うには、各間隔で含められてください。 部分集合SHOULD、すべてのソースが報告されるための複数の間隔の向こう側の選択された連続になってください。
It is RECOMMENDED that translators and mixers combine individual RTCP packets from the multiple sources they are forwarding into one compound packet whenever feasible in order to amortize the packet overhead (see Section 7). An example RTCP compound packet as might be produced by a mixer is shown in Fig. 1. If the overall length of a compound packet would exceed the MTU of the network path, it SHOULD be segmented into multiple shorter compound packets to be transmitted in separate packets of the underlying protocol. This does not impair the RTCP bandwidth estimation because each compound packet represents at least one distinct participant. Note that each of the compound packets MUST begin with an SR or RR packet.
翻訳者とミキサーが可能であるときはいつも、彼らがパケットオーバーヘッドを清算するために1つの合成パケットに転送している複数のソースから個々のRTCPパケットを結合するのは(セクション7を見てください)、RECOMMENDEDです。 RTCPがパケットを合成する例は生産されて、ミキサーが図1に示されるということであるかもしれません。 合成パケットの全長はネットワーク経路のMTUを超えて、それはSHOULDです。基本的なプロトコルの別々のパケットで伝えられるために複数の、より脆い合成パケットに区分されます。 それぞれの合成パケットが少なくとも1人の異なった関係者の代理をするので、これはRTCP帯域幅見積りを損ないません。 それぞれの合成パケットがSRかRRパケットと共に始まらなければならないことに注意してください。
An implementation SHOULD ignore incoming RTCP packets with types unknown to it. Additional RTCP packet types may be registered with the Internet Assigned Numbers Authority (IANA) as described in Section 15.
SHOULDが入って来るRTCPパケットを無視する実現はそれに未知をタイプします。 追加RTCPパケットタイプはセクション15で説明されるようにインターネットAssigned民数記Authorityに示されるかもしれません(IANA)。
if encrypted: random 32-bit integer | |[--------- packet --------][---------- packet ----------][-packet-] | | receiver chunk chunk V reports item item item item -------------------------------------------------------------------- R[SR #sendinfo #site1#site2][SDES #CNAME PHONE #CNAME LOC][BYE##why] -------------------------------------------------------------------- | | |<----------------------- compound packet ----------------------->| |<-------------------------- UDP packet ------------------------->|
コード化されるなら: 無作為の32ビットの整数| |[--------- packet --------][---------- packet ----------][-packet-] | | 受信機塊塊Vレポート項目項目項目の品目-------------------------------------------------------------------- R[SR#sendinfo#site1#site2][SDES#CNAME電話#CNAME LOC]、[さようなら##、なぜ]-------------------------------------------------------------------- | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-- 合成パケット----------------------->| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-- UDPパケット------------------------->|
#: SSRC/CSRC identifier
#: SSRC/CSRC識別子
Figure 1: Example of an RTCP compound packet
図1: RTCP合成パケットに関する例
Schulzrinne, et al. Standards Track [Page 23] RFC 3550 RTP July 2003
Schulzrinne、他 規格はRTP2003年7月にRFC3550を追跡します[23ページ]。
6.2 RTCP Transmission Interval
6.2 RTCPトランスミッション間隔
RTP is designed to allow an application to scale automatically over session sizes ranging from a few participants to thousands. For example, in an audio conference the data traffic is inherently self- limiting because only one or two people will speak at a time, so with multicast distribution the data rate on any given link remains relatively constant independent of the number of participants. However, the control traffic is not self-limiting. If the reception reports from each participant were sent at a constant rate, the control traffic would grow linearly with the number of participants. Therefore, the rate must be scaled down by dynamically calculating the interval between RTCP packet transmissions.
RTPは、アプリケーションが自動的に数人の関係者から数千まで及ぶセッションサイズの上比例するのを許容するように設計されています。 例えば、1か2人の人だけが一度に話すので本来オーディオ会議が、データ通信量が自己制限であるので、マルチキャスト分配で、どんな与えられたリンクの上のデータ信号速度は関係者の数の如何にかかわらず比較的一定数にとどまっています。 しかしながら、コントロール交通は自己制限ではありません。 一定の割合で各関係者からのレセプションレポートを送るなら、コントロール交通は関係者の数で直線的になるでしょうに。 したがって、レートは、ダイナミックにRTCPパケット伝送の間隔について計算することによって、縮小しなければなりません。
For each session, it is assumed that the data traffic is subject to an aggregate limit called the "session bandwidth" to be divided among the participants. This bandwidth might be reserved and the limit enforced by the network. If there is no reservation, there may be other constraints, depending on the environment, that establish the "reasonable" maximum for the session to use, and that would be the session bandwidth. The session bandwidth may be chosen based on some cost or a priori knowledge of the available network bandwidth for the session. It is somewhat independent of the media encoding, but the encoding choice may be limited by the session bandwidth. Often, the session bandwidth is the sum of the nominal bandwidths of the senders expected to be concurrently active. For teleconference audio, this number would typically be one sender's bandwidth. For layered encodings, each layer is a separate RTP session with its own session bandwidth parameter.
各セッションのために、データ通信量は関係者の中で分割されるために「セッション帯域幅」と呼ばれる総責任限度額を受けることがあると思われます。 この帯域幅は、予約されていてネットワークによって励行された限界であるかもしれません。 予約が全くなければ、セッションが使用する「妥当な」最大を確立する環境に依存する他の規制があるかもしれません、そして、それはセッション帯域幅でしょう。 セッション帯域幅は利用可能なネットワーク回線容量に関する何らかの費用か先験的な知識に基づいてセッションのために選ばれるかもしれません。 それはメディアコード化からいくらか独立していますが、コード化選択はセッション帯域幅によって制限されるかもしれません。 しばしば、セッション帯域幅は同時にアクティブであると予想された送付者の呼び帯域幅の合計です。 電子会議オーディオのために、この数は通常、1人の送付者の帯域幅でしょう。 層にされたencodingsに関しては、各層はそれ自身のセッション帯域幅パラメタとの別々のRTPセッションです。
The session bandwidth parameter is expected to be supplied by a session management application when it invokes a media application, but media applications MAY set a default based on the single-sender data bandwidth for the encoding selected for the session. The application MAY also enforce bandwidth limits based on multicast scope rules or other criteria. All participants MUST use the same value for the session bandwidth so that the same RTCP interval will be calculated.
メディアアプリケーションを呼び出すとき、セッション管理アプリケーションでセッション帯域幅パラメタが供給されると予想されますが、メディアアプリケーションは独身の送付者データ帯域幅に基づくデフォルトをセッションのために選択されたコード化に設定するかもしれません。 また、アプリケーションはマルチキャスト範囲規則か他の評価基準に基づく帯域幅限界を実施するかもしれません。 同じRTCP間隔が計算されて、すべての関係者がセッション帯域幅に同じ値を使用しなければなりません。
Bandwidth calculations for control and data traffic include lower- layer transport and network protocols (e.g., UDP and IP) since that is what the resource reservation system would need to know. The application can also be expected to know which of these protocols are in use. Link level headers are not included in the calculation since the packet will be encapsulated with different link level headers as it travels.
コントロールのための帯域幅計算とデータ通信量は、それがリソース保留制が知る必要があるだろうことであるので、下側の層の輸送とネットワーク・プロトコル(例えば、UDPとIP)を含んでいます。 また、アプリケーションが、これらのプロトコルのどれが使用中であるかを知っていると予想できます。 移動するのに応じてパケットが異なったリンク・レベルヘッダーと共にカプセルに入れられるので、リンク・レベルヘッダーは計算に含まれていません。
Schulzrinne, et al. Standards Track [Page 24] RFC 3550 RTP July 2003
Schulzrinne、他 規格はRTP2003年7月にRFC3550を追跡します[24ページ]。
The control traffic should be limited to a small and known fraction of the session bandwidth: small so that the primary function of the transport protocol to carry data is not impaired; known so that the control traffic can be included in the bandwidth specification given to a resource reservation protocol, and so that each participant can independently calculate its share. The control traffic bandwidth is in addition to the session bandwidth for the data traffic. It is RECOMMENDED that the fraction of the session bandwidth added for RTCP be fixed at 5%. It is also RECOMMENDED that 1/4 of the RTCP bandwidth be dedicated to participants that are sending data so that in sessions with a large number of receivers but a small number of senders, newly joining participants will more quickly receive the CNAME for the sending sites. When the proportion of senders is greater than 1/4 of the participants, the senders get their proportion of the full RTCP bandwidth. While the values of these and other constants in the interval calculation are not critical, all participants in the session MUST use the same values so the same interval will be calculated. Therefore, these constants SHOULD be fixed for a particular profile.
コントロール交通はセッション帯域幅の小さくて知られている部分に制限されるべきです: したがって、小さく、輸送の第一の機能がデータを運ぶために議定書を作るのは損なわれません。 各関係者が資源予約プロトコルに与えられた帯域幅仕様でコントロール交通を入れることができて、独自にシェアについて計算できるように、知られています。 コントロール交通帯域幅はデータ通信量へのセッション帯域幅に加えています。 RTCPのために加えられたセッション帯域幅の部分が5%で修理されているのは、RECOMMENDEDです。 また、1/4のRTCP帯域幅が新たに関係者に加わるとCNAMEが多くの受信機にもかかわらず、少ない数の送付者とのセッションのときに、よりすぐに送付サイトに受けられるようにデータを送る関係者に捧げられるのは、RECOMMENDEDです。 送付者のプロポーションが1/4人以上の関係者であるときに、送付者は彼らの完全なRTCP帯域幅の割合を得ます。 間隔計算におけるこれらと他の定数の値が重要でない間、セッションのすべての関係者が間隔が計算されるためにとても同じ同じ値を使用しなければなりません。 したがって、これらの定数SHOULD、特定のプロフィールには、修理されてください。
A profile MAY specify that the control traffic bandwidth may be a separate parameter of the session rather than a strict percentage of the session bandwidth. Using a separate parameter allows rate- adaptive applications to set an RTCP bandwidth consistent with a "typical" data bandwidth that is lower than the maximum bandwidth specified by the session bandwidth parameter.
プロフィールは、コントロール交通帯域幅がセッション帯域幅の厳しい割合よりむしろセッションの別々のパラメタであるかもしれないと指定するかもしれません。 別々のパラメタを使用するのに、レートの適応型のアプリケーションは最大の帯域幅がセッション帯域幅パラメタで指定したより低い「典型的な」データ帯域幅と一致したRTCP帯域幅を設定できます。
The profile MAY further specify that the control traffic bandwidth may be divided into two separate session parameters for those participants which are active data senders and those which are not; let us call the parameters S and R. Following the recommendation that 1/4 of the RTCP bandwidth be dedicated to data senders, the RECOMMENDED default values for these two parameters would be 1.25% and 3.75%, respectively. When the proportion of senders is greater than S/(S+R) of the participants, the senders get their proportion of the sum of these parameters. Using two parameters allows RTCP reception reports to be turned off entirely for a particular session by setting the RTCP bandwidth for non-data-senders to zero while keeping the RTCP bandwidth for data senders non-zero so that sender reports can still be sent for inter-media synchronization. Turning off RTCP reception reports is NOT RECOMMENDED because they are needed for the functions listed at the beginning of Section 6, particularly reception quality feedback and congestion control. However, doing so may be appropriate for systems operating on unidirectional links or for sessions that don't require feedback on the quality of reception or liveness of receivers and that have other means to avoid congestion.
プロフィールは、コントロール交通帯域幅がそれらの関係者への活発なデータ送付者とそうしないそれらである2つの別々のセッションパラメタに分割されるかもしれないとさらに指定するかもしれません。 パラメタSとR.Followingを1/4のRTCP帯域幅がデータ送付者に捧げられるという推薦と呼ぼう、これらの2つのパラメタのためのRECOMMENDEDデフォルト値は%と3.75%と、それぞれ1.25でしょう。 送付者のプロポーションが関係者のS/(S+R)より多くときに、送付者は彼らのこれらのパラメタの合計の割合を得ます。 2つのパラメタを使用するのに、RTCPレセプションレポートは、中間体同期のためにまだ送付者レポートを送ることができるようにデータ送付者のためのRTCP帯域幅を非ゼロに合わせるように保っている間、非データの送付者のためのRTCP帯域幅をゼロに設定することによって、下に完全に特定のセッションのためにターンします。 それらがセクション6、特にレセプション品質フィードバック、および輻輳制御の始めに記載された機能に必要であるので、RTCPレセプションレポートをオフにするのは、NOT RECOMMENDEDです。 しかしながら、そうするのは単方向のリンクを作動させるシステムかレセプションの品質か受信機の活性のフィードバックを必要としないで、混雑を避ける他の手段を持っているセッションのために適切であるかもしれません。
Schulzrinne, et al. Standards Track [Page 25] RFC 3550 RTP July 2003
Schulzrinne、他 規格はRTP2003年7月にRFC3550を追跡します[25ページ]。
The calculated interval between transmissions of compound RTCP packets SHOULD also have a lower bound to avoid having bursts of packets exceed the allowed bandwidth when the number of participants is small and the traffic isn't smoothed according to the law of large numbers. It also keeps the report interval from becoming too small during transient outages like a network partition such that adaptation is delayed when the partition heals. At application startup, a delay SHOULD be imposed before the first compound RTCP packet is sent to allow time for RTCP packets to be received from other participants so the report interval will converge to the correct value more quickly. This delay MAY be set to half the minimum interval to allow quicker notification that the new participant is present. The RECOMMENDED value for a fixed minimum interval is 5 seconds.
また、合成RTCPパケットSHOULDのトランスミッションの計算された間隔には、関係者の数が少なく、大数の法則によると、交通が整えられないとき、パケットの炸裂に許容帯域幅を超えさせるのを避ける下界があります。 また、それは、パーティションが回復するとき、適合が遅れるように、レポート間隔がネットワークパーティションのような一時的な供給停止の間、小さくなり過ぎるのを妨げます。 アプリケーション始動では、aはSHOULDを遅らせます。RTCPパケットがレポート間隔が、より急速に正しい値に一点に集まるように他の関係者から受け取られる時間を許容するために最初の合成RTCPパケットを送る前に課してください。 最小間隔の半分にこの遅れが新しい関係者が出席しているというより迅速な通知を許容するように設定されるかもしれません。 固定最小間隔の間のRECOMMENDED値は5秒です。
An implementation MAY scale the minimum RTCP interval to a smaller value inversely proportional to the session bandwidth parameter with the following limitations:
実現は以下の制限で逆にセッション帯域幅パラメタに変化するより小さい値に最小のRTCP間隔について合わせて調整するかもしれません:
o For multicast sessions, only active data senders MAY use the
reduced minimum value to calculate the interval for transmission
of compound RTCP packets.
o マルチキャストセッション、送付者が減少している最小値を使用するかもしれないアクティブなデータだけに関しては、合成RTCPパケットのトランスミッションのために間隔について計算してください。
o For unicast sessions, the reduced value MAY be used by
participants that are not active data senders as well, and the
delay before sending the initial compound RTCP packet MAY be zero.
o ユニキャストセッションのために、減少している値はまた、活発なデータ送付者でない関係者によって使用されるかもしれません、そして、初期の合成RTCPパケットを送る前の遅れはゼロであるかもしれません。
o For all sessions, the fixed minimum SHOULD be used when
calculating the participant timeout interval (see Section 6.3.5)
so that implementations which do not use the reduced value for
transmitting RTCP packets are not timed out by other participants
prematurely.
o すべてのセッションに使用する、最小のSHOULDが修理されて、関与しているタイムアウト間隔について計算するときにはRTCPパケットを伝えるのに減少している値を使用しない実現が早まって他の関係者による外で調節されていないように、使用されてください(セクション6.3.5を見てください)。
o The RECOMMENDED value for the reduced minimum in seconds is 360
divided by the session bandwidth in kilobits/second. This minimum
is smaller than 5 seconds for bandwidths greater than 72 kb/s.
o RECOMMENDED値は、秒の減少している最小限が360であるので、キロビット/秒におけるセッション帯域幅のそばで分割されました。 帯域幅より多くの72kb/sには、この最小限は5秒よりわずかです。
The algorithm described in Section 6.3 and Appendix A.7 was designed to meet the goals outlined in this section. It calculates the interval between sending compound RTCP packets to divide the allowed control traffic bandwidth among the participants. This allows an application to provide fast response for small sessions where, for example, identification of all participants is important, yet automatically adapt to large sessions. The algorithm incorporates the following characteristics:
セクション6.3とAppendix A.7で説明されたアルゴリズムは、このセクションで概説された目標を達成するように設計されました。 それは、関係者の中で許容コントロール交通帯域幅を分割するために送付合成RTCPパケットの間隔について計算します。 これで、アプリケーションは、例えばすべての関係者の識別が重要である小さいセッションのために速い応答を提供しますが、大きいセッションまで自動的に適合します。 アルゴリズムは以下の特性を取り入れます:
Schulzrinne, et al. Standards Track [Page 26] RFC 3550 RTP July 2003
Schulzrinne、他 規格はRTP2003年7月にRFC3550を追跡します[26ページ]。
o The calculated interval between RTCP packets scales linearly with
the number of members in the group. It is this linear factor
which allows for a constant amount of control traffic when summed
across all members.
o RTCPパケットの計算された間隔は会員数でグループで直線的に比例します。 それはすべてのメンバーの向こう側にまとめられると一定の量のコントロール交通を考慮するこの直線的な要素です。
o The interval between RTCP packets is varied randomly over the
range [0.5,1.5] times the calculated interval to avoid unintended
synchronization of all participants [20]. The first RTCP packet
sent after joining a session is also delayed by a random variation
of half the minimum RTCP interval.
o RTCPパケットの間隔は、すべての関係者[20]の故意でない同期を避けるために計算された間隔の[0.5、1.5]回の間の範囲で手当たりしだいに変えられます。 接合して、セッションが送った後にも送る最小のRTCP間隔の半分の不規則変動で遅れる最初のRTCPパケット。
o A dynamic estimate of the average compound RTCP packet size is
calculated, including all those packets received and sent, to
automatically adapt to changes in the amount of control
information carried.
o 平均した合成RTCPパケットサイズのダイナミックな見積りは計算されます、自動的に情報が運んだコントロールの量における変化に順応するために受け取られて、送られたそれらのすべてのパケットを含んでいて。
o Since the calculated interval is dependent on the number of
observed group members, there may be undesirable startup effects
when a new user joins an existing session, or many users
simultaneously join a new session. These new users will initially
have incorrect estimates of the group membership, and thus their
RTCP transmission interval will be too short. This problem can be
significant if many users join the session simultaneously. To
deal with this, an algorithm called "timer reconsideration" is
employed. This algorithm implements a simple back-off mechanism
which causes users to hold back RTCP packet transmission if the
group sizes are increasing.
o 計算された間隔が観測されたグループのメンバーの数に依存しているので、新しいユーザが既存のセッションに参加するとき、望ましくない始動効果があるかもしれませんか、または多くのユーザが同時に、新しいセッションに参加します。 これらの新しいユーザには、初めは、グループ会員資格の不正確な見積りがあるでしょう、そして、その結果、彼らのRTCPトランスミッション間隔は短くなり過ぎるでしょう。 多くのユーザが同時にセッションに参加するなら、この問題は重要である場合があります。 これに対処するために、「タイマ再考」と呼ばれるアルゴリズムは採用しています。 このアルゴリズムはグループサイズが増加しているならユーザがRTCPパケット伝送を抑える簡単な下に後部メカニズムを実行します。
o When users leave a session, either with a BYE or by timeout, the
group membership decreases, and thus the calculated interval
should decrease. A "reverse reconsideration" algorithm is used to
allow members to more quickly reduce their intervals in response
to group membership decreases.
o ユーザがBYEかタイムアウトでセッションを残すとき、グループ会員資格は減少します、そして、その結果、計算された間隔は減少するべきです。 「逆の再考」アルゴリズムは、メンバーが、より急速にグループ会員資格減少に対応して彼らの間隔を短縮するのを許容するのに使用されます。
o BYE packets are given different treatment than other RTCP packets.
When a user leaves a group, and wishes to send a BYE packet, it
may do so before its next scheduled RTCP packet. However,
transmission of BYEs follows a back-off algorithm which avoids
floods of BYE packets should a large number of members
simultaneously leave the session.
o 他のRTCPパケットと異なった処理をBYEパケットに与えます。 ユーザがグループを残して、BYEパケットを送りたがっているとき、それは次の予定されているRTCPパケットの前でそうするかもしれません。 しかしながら、BYEsのトランスミッションは多くのメンバーが同時にセッションを残すならBYEパケットの洪水を避ける下に後部アルゴリズムに従います。
This algorithm may be used for sessions in which all participants are allowed to send. In that case, the session bandwidth parameter is the product of the individual sender's bandwidth times the number of participants, and the RTCP bandwidth is 5% of that.
このアルゴリズムはすべての関係者が発信できるセッションに使用されるかもしれません。 その場合、セッション帯域幅パラメタ、個々の送付者の帯域幅時代の製品は関係者の数であり、RTCP帯域幅はその5%です。
Details of the algorithm's operation are given in the sections that follow. Appendix A.7 gives an example implementation.
アルゴリズムの操作の詳細は従うセクションで明らかにされます。 付録A.7は例の実現を与えます。
Schulzrinne, et al. Standards Track [Page 27] RFC 3550 RTP July 2003
Schulzrinne、他 規格はRTP2003年7月にRFC3550を追跡します[27ページ]。
6.2.1 Maintaining the Number of Session Members
6.2.1 セッションメンバーの数を維持すること。
Calculation of the RTCP packet interval depends upon an estimate of the number of sites participating in the session. New sites are added to the count when they are heard, and an entry for each SHOULD be created in a table indexed by the SSRC or CSRC identifier (see Section 8.2) to keep track of them. New entries MAY be considered not valid until multiple packets carrying the new SSRC have been received (see Appendix A.1), or until an SDES RTCP packet containing a CNAME for that SSRC has been received. Entries MAY be deleted from the table when an RTCP BYE packet with the corresponding SSRC identifier is received, except that some straggler data packets might arrive after the BYE and cause the entry to be recreated. Instead, the entry SHOULD be marked as having received a BYE and then deleted after an appropriate delay.
RTCPパケット間隔の計算はセッションのときに参加するサイトの数の見積りによります。 新しいサイトは作成されたコネがSSRCかCSRC識別子(セクション8.2を見る)によって索引をつけられた、それらの動向をおさえたテーブルであったなら各SHOULDのためにそれらが聞かれてエントリーであることのカウントに加えられます。 新しいエントリーは有効でないと新しいSSRCを運ぶ複数のパケットを受け取ったか(Appendix A.1を見てください)、またはそのSSRCのためのCNAMEを含むSDES RTCPパケットを受け取るまで考えられるかもしれません。 対応するSSRC識別子があるRTCP BYEパケットが受け取られているとき、エントリーはテーブルから削除されるかもしれません、いくつかの落伍者データ・パケットでBYEの後に到着して、エントリーを休養させるかもしれないのを除いて。 代わりに不戦勝を得たとしてマークされて、次に適切な遅れの後に削除されたエントリーSHOULD。
A participant MAY mark another site inactive, or delete it if not yet valid, if no RTP or RTCP packet has been received for a small number of RTCP report intervals (5 is RECOMMENDED). This provides some robustness against packet loss. All sites must have the same value for this multiplier and must calculate roughly the same value for the RTCP report interval in order for this timeout to work properly. Therefore, this multiplier SHOULD be fixed for a particular profile.
関係者は、別のサイトが不活発であるとマークするか、またはそうでなければ、まだ有効な状態でそれを削除するかもしれません、少ない数のRTCPレポート間隔の間、どんなRTPもRTCPパケットも受け取っていないなら(5はRECOMMENDEDです)。 これはパケット損失に対して何らかの丈夫さを提供します。 このタイムアウトが適切に扱うように、すべてのサイトが、この乗数のために同じ値を持たなければならなくて、RTCPレポート間隔の間、およそ同じ値について計算しなければなりません。 特定のプロフィールのためにしたがって、この乗数SHOULDに修理されてください。
For sessions with a very large number of participants, it may be impractical to maintain a table to store the SSRC identifier and state information for all of them. An implementation MAY use SSRC sampling, as described in [21], to reduce the storage requirements. An implementation MAY use any other algorithm with similar performance. A key requirement is that any algorithm considered SHOULD NOT substantially underestimate the group size, although it MAY overestimate.
非常に多くの関係者とのセッションのために、彼らのすべてのためのSSRC識別子と州の情報を格納するためにテーブルを維持するのは非実用的であるかもしれません。 実現は格納要件を減らすために[21]で説明されるようにSSRC標本抽出を使用するかもしれません。 実現は同様の性能があるいかなる他のアルゴリズムも使用するかもしれません。 主要な要件は過大評価するかもしれませんが、どんなアルゴリズムの考えられたSHOULD NOTも実質的にグループサイズを過小評価するということです。
6.3 RTCP Packet Send and Receive Rules
6.3RTCPパケットは、規則を送って、受け取ります。
The rules for how to send, and what to do when receiving an RTCP packet are outlined here. An implementation that allows operation in a multicast environment or a multipoint unicast environment MUST meet the requirements in Section 6.2. Such an implementation MAY use the algorithm defined in this section to meet those requirements, or MAY use some other algorithm so long as it provides equivalent or better performance. An implementation which is constrained to two-party unicast operation SHOULD still use randomization of the RTCP transmission interval to avoid unintended synchronization of multiple instances operating in the same environment, but MAY omit the "timer reconsideration" and "reverse reconsideration" algorithms in Sections 6.3.3, 6.3.6 and 6.3.7.
どのように発信するか、そして、RTCPパケットを受けるのがここに概説されているとき何をしたらよいかためには規則。 マルチキャスト環境か多点ユニキャスト環境における操作を許す実現はセクション6.2で条件を満たさなければなりません。 そのような実現は、それらの必要条件を満たすのにこのセクションで定義されたアルゴリズムを使用するか、または同等であるか、より良い性能を提供する限り、ある他のアルゴリズムを使用するかもしれません。 2パーティーに抑制されて、ユニキャスト操作SHOULDが同じ環境で作動する複数の例の故意でない同期を避けるのにまだRTCPトランスミッション間隔の無作為化を使用していて、「タイマ再考」を省略してください、「再考を逆にしてください」というセクション6.3.3、6.3における唯一の5月のアルゴリズムが.6であり、6.3が.7であるということである実現。
Schulzrinne, et al. Standards Track [Page 28] RFC 3550 RTP July 2003
Schulzrinne、他 規格はRTP2003年7月にRFC3550を追跡します[28ページ]。
To execute these rules, a session participant must maintain several pieces of state:
これらの規則を実行するために、セッション関係者は数片の状態を維持しなければなりません:
tp: the last time an RTCP packet was transmitted;
tp: 最後の時間、RTCPパケットは伝えられました。
tc: the current time;
Tc: 現在の時間。
tn: the next scheduled transmission time of an RTCP packet;
tn: RTCPパケットの次の予定されているトランスミッション時間。
pmembers: the estimated number of session members at the time tn
was last recomputed;
pmembers: 時間tnのセッションメンバーの概算数は最後に再計算されました。
members: the most current estimate for the number of session
members;
メンバー: セッションメンバーの数のための最も多くの現状見積金額。
senders: the most current estimate for the number of senders in
the session;
送付者: セッションにおける、送付者の数のための最も多くの現状見積金額。
rtcp_bw: The target RTCP bandwidth, i.e., the total bandwidth
that will be used for RTCP packets by all members of this session,
in octets per second. This will be a specified fraction of the
"session bandwidth" parameter supplied to the application at
startup.
rtcp_bw: 目標RTCP帯域幅、すなわち、RTCPパケットに1秒あたりの八重奏におけるこのセッションのすべてのメンバーによって使用される総帯域幅。 これは始動でアプリケーションに提供された「セッション帯域幅」パラメタの指定された部分になるでしょう。
we_sent: Flag that is true if the application has sent data
since the 2nd previous RTCP report was transmitted.
私たち、_は発信しました: 前の第2RTCPが報告するのでアプリケーションがデータを送ったなら本当の旗は送られました。
avg_rtcp_size: The average compound RTCP packet size, in octets,
over all RTCP packets sent and received by this participant. The
size includes lower-layer transport and network protocol headers
(e.g., UDP and IP) as explained in Section 6.2.
avg_rtcp_サイズ: この関係者によって送られて、受け取られたすべてのRTCPパケットの上の八重奏における平均した合成RTCPパケットサイズ。 サイズはセクション6.2で説明されるように下層輸送とネットワーク・プロトコルヘッダー(例えば、UDPとIP)を含んでいます。
initial: Flag that is true if the application has not yet sent
an RTCP packet.
頭文字をつけます: アプリケーションがまだRTCPパケットを送らないなら本当の旗。
Many of these rules make use of the "calculated interval" between packet transmissions. This interval is described in the following section.
これらの規則の多くがパケット伝送の間の「計算された間隔」を利用します。 この間隔は以下のセクションで説明されます。
6.3.1 Computing the RTCP Transmission Interval
6.3.1 RTCPトランスミッション間隔を計算すること。
To maintain scalability, the average interval between packets from a session participant should scale with the group size. This interval is called the calculated interval. It is obtained by combining a number of the pieces of state described above. The calculated interval T is then determined as follows:
スケーラビリティを維持するために、セッション関係者からのパケットの平均した間隔はグループサイズで比例するべきです。 この間隔は計算された間隔と呼ばれます。 上で説明された多くの状態を合併することによって、それを得ます。 次に、計算された間隔Tは以下の通り断固としています:
Schulzrinne, et al. Standards Track [Page 29] RFC 3550 RTP July 2003
Schulzrinne、他 規格はRTP2003年7月にRFC3550を追跡します[29ページ]。
1. If the number of senders is less than or equal to 25% of the
membership (members), the interval depends on whether the
participant is a sender or not (based on the value of we_sent).
If the participant is a sender (we_sent true), the constant C is
set to the average RTCP packet size (avg_rtcp_size) divided by 25%
of the RTCP bandwidth (rtcp_bw), and the constant n is set to the
number of senders. If we_sent is not true, the constant C is set
to the average RTCP packet size divided by 75% of the RTCP
bandwidth. The constant n is set to the number of receivers
(members - senders). If the number of senders is greater than
25%, senders and receivers are treated together. The constant C
is set to the average RTCP packet size divided by the total RTCP
bandwidth and n is set to the total number of members. As stated
in Section 6.2, an RTP profile MAY specify that the RTCP bandwidth
may be explicitly defined by two separate parameters (call them S
and R) for those participants which are senders and those which
are not. In that case, the 25% fraction becomes S/(S+R) and the
75% fraction becomes R/(S+R). Note that if R is zero, the
percentage of senders is never greater than S/(S+R), and the
implementation must avoid division by zero.
1. 間隔を送付者の数が会員資格(メンバー)の25%以下であるなら、関係者が送付者であるかどうかに頼っている、(値に基づいている、私たち、送られた_) 関係者が送付者である、(私たち、本当に送られた_)、定数Cは平均したRTCP帯域幅(rtcp_bw)の25%が割られたRTCPパケットサイズ(avg_rtcp_サイズ)に設定されて、定数nは送付者の数に設定されます。 送られた_が私たちであるなら本当でない、定数Cは平均したRTCP帯域幅の75%が割られたRTCPパケットサイズに設定されます。 定数nは受信機(メンバー--送付者)の数に設定されます。 送付者の数が25%以上であるなら、送付者と受信機は一緒に扱われます。 定数Cは平均した総RTCP帯域幅が割られたRTCPパケットサイズに設定されます、そして、nはメンバーの総数に設定されます。 セクション6.2に述べられているように、RTPプロフィールは、それらの関係者への送付者とそうしないそれらである2つの別々のパラメタ(それらをSとRと呼ぶ)によってRTCP帯域幅が明らかに定義されるかもしれないと指定するかもしれません。 その場合、25%の断片はS/(S+R)になります、そして、75%の断片はR/(S+R)になります。 送付者の割合がRがゼロであるなら、S/(S+R)より決してすばらしくなく、実現がゼロ除算を避けなければならないことに注意してください。
2. If the participant has not yet sent an RTCP packet (the variable
initial is true), the constant Tmin is set to 2.5 seconds, else it
is set to 5 seconds.
2. 関係者がまだRTCPパケットを送らないなら(可変イニシャルは正しいです)、一定のTminは2.5秒に用意ができて、ほかに、5秒に設定されます。
3. The deterministic calculated interval Td is set to max(Tmin, n*C).
3. 決定論的な計算された間隔Tdは(Tmin、n*C)に最大限にするように用意ができています。
4. The calculated interval T is set to a number uniformly distributed
between 0.5 and 1.5 times the deterministic calculated interval.
4. 計算された間隔Tは決定論的な計算された間隔の0.5〜1.5回一様に分配された数に設定されます。
5. The resulting value of T is divided by e-3/2=1.21828 to compensate
for the fact that the timer reconsideration algorithm converges to
a value of the RTCP bandwidth below the intended average.
5. e-3/2=1.21828は、タイマ再考アルゴリズムが意図している平均の下のRTCP帯域幅の値に一点に集まるという事実を補うためにTの結果として起こる値に割られます。
This procedure results in an interval which is random, but which, on average, gives at least 25% of the RTCP bandwidth to senders and the rest to receivers. If the senders constitute more than one quarter of the membership, this procedure splits the bandwidth equally among all participants, on average.
この手順は無作為ですが、RTCP帯域幅の少なくとも25%を受信機への送付者と残りに平均的に与える間隔に結果として生じます。 送付者が会員資格の四分の一以上を構成するなら、この手順はすべての関係者の中で等しく帯域幅を分けます、平均的に。
6.3.2 Initialization
6.3.2 初期設定
Upon joining the session, the participant initializes tp to 0, tc to 0, senders to 0, pmembers to 1, members to 1, we_sent to false, rtcp_bw to the specified fraction of the session bandwidth, initial to true, and avg_rtcp_size to the probable size of the first RTCP packet that the application will later construct. The calculated interval T is then computed, and the first packet is scheduled for
セッションに参加すると、関係者はtpを0に初期化します、0へのTc、0への送付者、1へのpmembers、1へのメンバー、私たち、_が偽に発信しました、セッション帯域幅の指定された部分へのrtcp_bw、アプリケーションが後で組み立てる最初のRTCPパケットのありえそうなサイズへの本当の、そして、avgな_rtcp_サイズへのイニシャル。 次に、計算された間隔Tは計算されます、そして、最初のパケットは予定されています。
Schulzrinne, et al. Standards Track [Page 30] RFC 3550 RTP July 2003
Schulzrinne、他 規格はRTP2003年7月にRFC3550を追跡します[30ページ]。
time tn = T. This means that a transmission timer is set which expires at time T. Note that an application MAY use any desired approach for implementing this timer.
T.時間tn=Thisは、トランスミッションタイマがこのタイマを実行するアプリケーションがどんな必要なアプローチも使用する時間T.Noteのときに期限が切れるセットであることを意味します。
The participant adds its own SSRC to the member table.
関係者はメンバーテーブルにそれ自身のSSRCを加えます。
6.3.3 Receiving an RTP or Non-BYE RTCP Packet
6.3.3 RTPか非不戦勝RTCPパケットを受けること。
When an RTP or RTCP packet is received from a participant whose SSRC is not in the member table, the SSRC is added to the table, and the value for members is updated once the participant has been validated as described in Section 6.2.1. The same processing occurs for each CSRC in a validated RTP packet.
SSRCがメンバーテーブルにない関係者からRTPかRTCPパケットを受け取るとき、テーブルにSSRCを加えます、そして、セクション6.2.1で説明されるようにいったん関係者を有効にすると、メンバーのための値をアップデートします。 同じ処理は有効にされたRTPパケットの各CSRCのために起こります。
When an RTP packet is received from a participant whose SSRC is not in the sender table, the SSRC is added to the table, and the value for senders is updated.
SSRCが送付者テーブルにない関係者からRTPパケットを受け取るとき、テーブルにSSRCを加えます、そして、送付者のための値をアップデートします。
For each compound RTCP packet received, the value of avg_rtcp_size is updated:
RTCPパケットが受けた各化合物において、avg_rtcp_サイズの値をアップデートします:
avg_rtcp_size = (1/16) * packet_size + (15/16) * avg_rtcp_size
(1/16)*パケット_サイズ+(15/16)*avg_rtcp_avg_rtcp_サイズ=サイズ
where packet_size is the size of the RTCP packet just received.
パケット_サイズがRTCPのサイズであるところでは、パケットはただ受信されました。
6.3.4 Receiving an RTCP BYE Packet
6.3.4 RTCPさようならパケットを受けること。
Except as described in Section 6.3.7 for the case when an RTCP BYE is to be transmitted, if the received packet is an RTCP BYE packet, the SSRC is checked against the member table. If present, the entry is removed from the table, and the value for members is updated. The SSRC is then checked against the sender table. If present, the entry is removed from the table, and the value for senders is updated.
RTCP BYEが伝えられることになっているとき、容認されたパケットがRTCP BYEパケットであるならケースのためにセクション6.3.7で説明されるのを除いて、SSRCはメンバーテーブルに対してチェックされます。 存在しているなら、テーブルからエントリーを取り除きます、そして、メンバーのための値をアップデートします。 そして、SSRCは送付者テーブルに対してチェックされます。 存在しているなら、テーブルからエントリーを取り除きます、そして、送付者のための値をアップデートします。
Furthermore, to make the transmission rate of RTCP packets more adaptive to changes in group membership, the following "reverse reconsideration" algorithm SHOULD be executed when a BYE packet is received that reduces members to a value less than pmembers:
その上、BYEパケットが受け取られているとき、グループ会員資格における変化、以下の「逆の再考」アルゴリズムSHOULDにより適応型のRTCPパケットの通信速度を実行させるために、それはpmembersほどメンバーを値に減少させません:
o The value for tn is updated according to the following formula:
o 以下の公式によると、tnのための値をアップデートします:
tn = tc + (members/pmembers) * (tn - tc)
tn=Tc+(メンバー/pmembers)*(tn--Tc)
o The value for tp is updated according the following formula:
o 以下の公式tpのための値をアップデートします:
tp = tc - (members/pmembers) * (tc - tp).
tpはTcと等しいです--(メンバー/pmembers。)*(Tc--tp)
Schulzrinne, et al. Standards Track [Page 31] RFC 3550 RTP July 2003
Schulzrinne、他 規格はRTP2003年7月にRFC3550を追跡します[31ページ]。
o The next RTCP packet is rescheduled for transmission at time tn,
which is now earlier.
o 次のRTCPパケットは時間tnのトランスミッションのために時期変更されます。(tnは現在、より初期です)。
o The value of pmembers is set equal to members.
o pmembersの値はメンバーと等しいセットです。
This algorithm does not prevent the group size estimate from incorrectly dropping to zero for a short time due to premature timeouts when most participants of a large session leave at once but some remain. The algorithm does make the estimate return to the correct value more rapidly. This situation is unusual enough and the consequences are sufficiently harmless that this problem is deemed only a secondary concern.
このアルゴリズムは、大きいセッションのほとんどの関係者がすぐに、いなくなりますが、或るものが残っているとグループサイズ見積りが時期尚早なタイムアウトのため短い間不当にゼロまで下がるのを防ぎません。 アルゴリズムで、見積りは、より急速に正しい値に戻ります。 この状況は十分珍しいです、そして、結果は十分無害です。この問題はあまり重要でない関心事だけであると考えられます。
6.3.5 Timing Out an SSRC
6.3.5SSRCからのタイミング
At occasional intervals, the participant MUST check to see if any of the other participants time out. To do this, the participant computes the deterministic (without the randomization factor) calculated interval Td for a receiver, that is, with we_sent false. Any other session member who has not sent an RTP or RTCP packet since time tc - MTd (M is the timeout multiplier, and defaults to 5) is timed out. This means that its SSRC is removed from the member list, and members is updated. A similar check is performed on the sender list. Any member on the sender list who has not sent an RTP packet since time tc - 2T (within the last two RTCP report intervals) is removed from the sender list, and senders is updated.
時々の間隔で、関係者は、もしあれば見るためにもう片方の関係者タイムアウトをチェックしなければなりません。 これをするために、関係者は受信機のために決定論的な(無作為化要素のない)計算された間隔Tdを計算します、すなわち私たち、_が虚偽で発信しました。 時間Tc以来RTPかRTCPパケットを送らないいかなる他のセッションメンバーも--MTd(Mは、タイムアウト乗数であり、5をデフォルトとする)は外で調節されています。 これは、メンバーリストからSSRCを取り外して、メンバーをアップデートすることを意味します。 同様のチェックは送付者リストに実行されます。 送付者リストの上の時間Tc以来RTPパケットを送らないどんなメンバーも--送付者リストから2T(ここ2回のRTCPレポート間隔以内の)を取り外して、送付者をアップデートします。
If any members time out, the reverse reconsideration algorithm described in Section 6.3.4 SHOULD be performed.
どんなメンバータイムアウト、逆の再考アルゴリズムもセクション6.3で.4SHOULDについて説明したなら、実行されてください。
The participant MUST perform this check at least once per RTCP transmission interval.
関係者はRTCPトランスミッション間隔単位でこのチェックを少なくとも一度実行しなければなりません。
6.3.6 Expiration of Transmission Timer
6.3.6 トランスミッションタイマの満了
When the packet transmission timer expires, the participant performs the following operations:
パケット伝送タイマが期限が切れると、関係者は以下の操作を実行します:
o The transmission interval T is computed as described in Section
6.3.1, including the randomization factor.
o トランスミッション間隔Tは無作為化要素を含むセクション6.3.1で説明されるように計算されます。
o If tp + T is less than or equal to tc, an RTCP packet is
transmitted. tp is set to tc, then another value for T is
calculated as in the previous step and tn is set to tc + T. The
transmission timer is set to expire again at time tn. If tp + T
is greater than tc, tn is set to tp + T. No RTCP packet is
transmitted. The transmission timer is set to expire at time tn.
o tp+Tが、よりTc以下であるなら、RTCPパケットは伝えられます。tpはTcに用意ができて、Tが前のステップとtnのように計算されるので、次に、別の値は時間tnのときにもう一度吐き出してくださいトランスミッションタイマが設定されるTc+T.に設定されます。 tp+TがTcより大きいなら、tnはtp+T.に用意ができています。RTCPパケットは全く伝えられません。 トランスミッションタイマが時間tnのときに期限が切れるように設定されます。
Schulzrinne, et al. Standards Track [Page 32] RFC 3550 RTP July 2003
Schulzrinne、他 規格はRTP2003年7月にRFC3550を追跡します[32ページ]。
o pmembers is set to members.
o pmembersはメンバーに用意ができています。
If an RTCP packet is transmitted, the value of initial is set to FALSE. Furthermore, the value of avg_rtcp_size is updated:
RTCPパケットが伝えられるなら、イニシャルの値はFALSEに設定されます。 その上、avg_rtcp_サイズの値をアップデートします:
avg_rtcp_size = (1/16) * packet_size + (15/16) * avg_rtcp_size
(1/16)*パケット_サイズ+(15/16)*avg_rtcp_avg_rtcp_サイズ=サイズ
where packet_size is the size of the RTCP packet just transmitted.
パケット_サイズがRTCPのサイズであるところに、パケットはただ送られました。
6.3.7 Transmitting a BYE Packet
6.3.7 さようならパケットを伝えること。
When a participant wishes to leave a session, a BYE packet is transmitted to inform the other participants of the event. In order to avoid a flood of BYE packets when many participants leave the system, a participant MUST execute the following algorithm if the number of members is more than 50 when the participant chooses to leave. This algorithm usurps the normal role of the members variable to count BYE packets instead:
関係者がセッションを残したがっているとき、BYEパケットは、出来事について他の関係者に知らせるために伝えられます。 多くの関係者がシステムを残すとき、BYEパケットの洪水を避けるために、関係者は関係者が、いなくなるのを選ぶとき、会員数が50以上であるなら以下のアルゴリズムを実行しなければなりません。 このアルゴリズムは代わりにBYEパケットを数えるのにおいて可変なメンバーの正常な役割を僣称します:
o When the participant decides to leave the system, tp is reset to
tc, the current time, members and pmembers are initialized to 1,
initial is set to 1, we_sent is set to false, senders is set to 0,
and avg_rtcp_size is set to the size of the compound BYE packet.
The calculated interval T is computed. The BYE packet is then
scheduled for time tn = tc + T.
o メンバーとpmembersによる1に初期化されています、初期であることが、1へのセットであるということであり、関係者が、システムを残すと決めると、tpはTc、現在の時間までリセットされて、私たちは送られた_です。誤っているのにセットがあります、そして、送付者は0に用意ができています、そして、avg_rtcp_サイズは合成BYEパケットのサイズに設定されます。 計算された間隔Tは計算されます。 そして、BYEパケットは時間tn=Tc+Tのために予定されています。
o Every time a BYE packet from another participant is received,
members is incremented by 1 regardless of whether that participant
exists in the member table or not, and when SSRC sampling is in
use, regardless of whether or not the BYE SSRC would be included
in the sample. members is NOT incremented when other RTCP packets
or RTP packets are received, but only for BYE packets. Similarly,
avg_rtcp_size is updated only for received BYE packets. senders
is NOT updated when RTP packets arrive; it remains 0.
o BYE SSRCはサンプルに含まれているでしょう。別の関係者からのBYEパケットが受け取られているときはいつも、メンバーはその関係者がメンバーテーブルに存在するかどうかと、SSRC標本抽出が他のRTCPパケットかRTPパケットが受け取られているとき、メンバーが増加されていないかどうかにかかわらず使用でのいつであるかにかかわらずBYEパケットのためだけに1つ増加されます。 同様に、容認されたBYEパケットのためだけにavg_rtcp_サイズをアップデートします。RTPパケットが到着する場合、送付者はアップデートしません。 それは0のままで残っています。
o Transmission of the BYE packet then follows the rules for
transmitting a regular RTCP packet, as above.
o そして、BYEパケットのトランスミッションは上のレギュラーのRTCPパケットを伝えるための規則に従います。
This allows BYE packets to be sent right away, yet controls their total bandwidth usage. In the worst case, this could cause RTCP control packets to use twice the bandwidth as normal (10%) -- 5% for non-BYE RTCP packets and 5% for BYE.
これはしかし、すぐ送られるBYEパケット、コントロールにそれらの総帯域幅用法を許容します。 最悪の場合には、これで、RTCPコントロールパケットは正常な同じくらい帯域幅(10%)の2倍を使用するかもしれません--非BYE RTCPパケットのための5%とBYEのための5%。
A participant that does not want to wait for the above mechanism to allow transmission of a BYE packet MAY leave the group without sending a BYE at all. That participant will eventually be timed out by the other group members.
全くBYEを送らないで、上のメカニズムがBYEパケットのトランスミッションを許容するのを待ちたがっていない関係者は仲間から抜けるかもしれません。 その関係者は結局、他のグループのメンバーによる外で調節されるでしょう。
Schulzrinne, et al. Standards Track [Page 33] RFC 3550 RTP July 2003
Schulzrinne、他 規格はRTP2003年7月にRFC3550を追跡します[33ページ]。
If the group size estimate members is less than 50 when the participant decides to leave, the participant MAY send a BYE packet immediately. Alternatively, the participant MAY choose to execute the above BYE backoff algorithm.
関係者が、いなくなると決めるとき、サイズがメンバーであると見積もっているグループが50未満であるなら、関係者はすぐに、BYEパケットを送るかもしれません。 あるいはまた、関係者は、上のBYE backoffアルゴリズムを実行するのを選ぶかもしれません。
In either case, a participant which never sent an RTP or RTCP packet MUST NOT send a BYE packet when they leave the group.
それらが仲間から抜けるとき、関係者のどちらかのケース、どれがRTPを決して送らなかったか、そして、またはRTCPでは、パケットはBYEパケットを送ってはいけません。
6.3.8 Updating we_sent
6.3.8 アップデートしている私たち、_は発信しました。
The variable we_sent contains true if the participant has sent an RTP packet recently, false otherwise. This determination is made by using the same mechanisms as for managing the set of other participants listed in the senders table. If the participant sends an RTP packet when we_sent is false, it adds itself to the sender table and sets we_sent to true. The reverse reconsideration algorithm described in Section 6.3.4 SHOULD be performed to possibly reduce the delay before sending an SR packet. Every time another RTP packet is sent, the time of transmission of that packet is maintained in the table. The normal sender timeout algorithm is then applied to the participant -- if an RTP packet has not been transmitted since time tc - 2T, the participant removes itself from the sender table, decrements the sender count, and sets we_sent to false.
_は発信しました。可変私たち、本当に、そうでなければ、関係者が最近RTPパケットを虚偽で送ったなら、含んでいます。 送付者テーブルに記載された他の関係者のセットを経営するように同じメカニズムを使用することによって、この決断をします。 私たちであるときに、関係者がRTPパケットを送るなら送られた_が偽である、送付者テーブルとセットにそれ自体を追加する、私たち、_は本当に発信しました。 逆再考アルゴリズムはセクション6.3で.4SHOULDについて説明しました。SRパケットを送る前にことによると遅れを減少させるために、実行されます。 別のRTPパケットを送るときはいつも、そのパケットのトランスミッションの時間はテーブルで維持されます。 そして、_虚偽で発信して、正常な送付者タイムアウトアルゴリズムは時間Tc以来RTPパケットは伝えられていません--2T、関係者が送付者テーブルから立ち退いて、減少が送付者カウントであり、セットが私たちであるなら関係者に適用されます。
6.3.9 Allocation of Source Description Bandwidth
6.3.9 ソース記述帯域幅の配分
This specification defines several source description (SDES) items in addition to the mandatory CNAME item, such as NAME (personal name) and EMAIL (email address). It also provides a means to define new application-specific RTCP packet types. Applications should exercise caution in allocating control bandwidth to this additional information because it will slow down the rate at which reception reports and CNAME are sent, thus impairing the performance of the protocol. It is RECOMMENDED that no more than 20% of the RTCP bandwidth allocated to a single participant be used to carry the additional information. Furthermore, it is not intended that all SDES items will be included in every application. Those that are included SHOULD be assigned a fraction of the bandwidth according to their utility. Rather than estimate these fractions dynamically, it is recommended that the percentages be translated statically into report interval counts based on the typical length of an item.
この仕様は義務的なCNAMEの品目に加えた数個のソース記述(SDES)項目を定義します、NAME(個人名)やメール(Eメールアドレス)のように。 また、それは新しいアプリケーション特有のRTCPパケットタイプを定義する手段を提供します。 アプリケーションはレセプションレポートとCNAMEが送られるレートを減速させるのでコントロール帯域幅をこの追加情報に割り当てる際に警戒するべきです、その結果、プロトコルの性能を損ないます。 独身の関係者に割り当てられたRTCP帯域幅の20%未満が追加情報を運ぶのに使用されるのは、RECOMMENDEDです。 その上、すべてのSDESの品目があらゆるアプリケーションに含まれることを意図しません。 それは含まれているSHOULDです。それら、それらのユーティリティに従って、帯域幅の部分は割り当てられてください。 むしろ、割合が静的に項目の典型的な長さに基づくレポート間隔カウントに翻訳されるのは、ダイナミックにこれらの断片を見積もっているよりお勧めです。
For example, an application may be designed to send only CNAME, NAME and EMAIL and not any others. NAME might be given much higher priority than EMAIL because the NAME would be displayed continuously in the application's user interface, whereas EMAIL would be displayed only when requested. At every RTCP interval, an RR packet and an SDES packet with the CNAME item would be sent. For a small session
例えば、アプリケーションは、どんな他のものではなく、CNAME、NAME、およびメールだけも送るように設計されるかもしれません。 アプリケーションのユーザーインタフェースに絶え間なくNAMEを表示するでしょう、したがって、NAMEを優先させるかもしれませんが、メールよりはるかに高い要求する場合にだけ、メールを表示するでしょう。 あらゆるRTCP間隔を置いて、CNAMEの品目があるRRパケットとSDESパケットを送るでしょう。 小さいセッションのために
Schulzrinne, et al. Standards Track [Page 34] RFC 3550 RTP July 2003
Schulzrinne、他 規格はRTP2003年7月にRFC3550を追跡します[34ページ]。
operating at the minimum interval, that would be every 5 seconds on the average. Every third interval (15 seconds), one extra item would be included in the SDES packet. Seven out of eight times this would be the NAME item, and every eighth time (2 minutes) it would be the EMAIL item.
最小間隔に作動して、それは平均して5秒毎でしょう。 あらゆる3番目の間隔(15秒)であり、1つの異常項目がSDESパケットに含まれているでしょう。 これがNAMEの品目であるだろう、第8毎回(2分)それがメール項目であるだろうという8回のうちの7。
When multiple applications operate in concert using cross-application binding through a common CNAME for each participant, for example in a multimedia conference composed of an RTP session for each medium, the additional SDES information MAY be sent in only one RTP session. The other sessions would carry only the CNAME item. In particular, this approach should be applied to the multiple sessions of a layered encoding scheme (see Section 2.4).
複数のアプリケーションがコンサートで一般的なCNAMEを通して各関係者で付きながら交差しているアプリケーションを使用することで作動すると、例えば各媒体のためにRTPセッションで構成されたマルチメディア会議では、1つのRTPセッションだけのときに追加SDES情報を送るかもしれません。 他のセッションはCNAMEの品目だけを運ぶでしょう。 特に、このアプローチは層にされたコード化計画の複数のセッションに適用されるべきです(セクション2.4を見てください)。
6.4 Sender and Receiver Reports
6.4 送付者と受信機レポート
RTP receivers provide reception quality feedback using RTCP report packets which may take one of two forms depending upon whether or not the receiver is also a sender. The only difference between the sender report (SR) and receiver report (RR) forms, besides the packet type code, is that the sender report includes a 20-byte sender information section for use by active senders. The SR is issued if a site has sent any data packets during the interval since issuing the last report or the previous one, otherwise the RR is issued.
RTP受信機は、また、受信機が送付者であるかどうかに頼る2つのフォームの1つを取るかもしれないRTCPレポートパケットを使用することでレセプション品質フィードバックを提供します。 パケットタイプコード以外に、送付者レポート(SR)と受信機レポート(RR)フォームの唯一の違いは送付者レポートが活発な送付者による使用のために20バイトの送付者情報収集部門を含んでいるということです。 最後のレポートを発行するか、前のもの、そうでなければRRが発行されるのでサイトが間隔の間、何かデータ・パケットを送るなら、SRは発行されます。
Both the SR and RR forms include zero or more reception report blocks, one for each of the synchronization sources from which this receiver has received RTP data packets since the last report. Reports are not issued for contributing sources listed in the CSRC list. Each reception report block provides statistics about the data received from the particular source indicated in that block. Since a maximum of 31 reception report blocks will fit in an SR or RR packet, additional RR packets SHOULD be stacked after the initial SR or RR packet as needed to contain the reception reports for all sources heard during the interval since the last report. If there are too many sources to fit all the necessary RR packets into one compound RTCP packet without exceeding the MTU of the network path, then only the subset that will fit into one MTU SHOULD be included in each interval. The subsets SHOULD be selected round-robin across multiple intervals so that all sources are reported.
SRとRR用紙の両方がゼロか、より多くのレセプションレポートブロック(最後のレポート以来この受信機がRTPデータ・パケットを受けているそれぞれの同期源への1)を含んでいます。 レポートは、CSRCリストに記載されたソースを寄付するために発行されません。 それぞれのレセプションレポートブロックはそのブロックで示された特定のソースから受け取られたデータに関する統計を提供します。 最大31レセプションレポートブロック以来、レセプションを含むのに必要である初期のSRかRRパケットが最後のレポート以来間隔の間に聞かれたすべてのソースを届け出た後にSRかRRパケットの発作、追加RRパケットSHOULDは積み重ねられるでしょうか? あまりに多くのソースがあれば、ネットワーク経路のMTU、当時の1MTU SHOULDに収まる部分集合だけを超えていなくて1つの合成RTCPパケットにすべての必要なRRパケットに合うには、各間隔で含められてください。 部分集合SHOULD、すべてのソースが報告されるための複数の間隔の向こう側の選択された連続になってください。
The next sections define the formats of the two reports, how they may be extended in a profile-specific manner if an application requires additional feedback information, and how the reports may be used. Details of reception reporting by translators and mixers is given in Section 7.
次のセクションはアプリケーションが追加フィードバック情報と、レポートがどう使用されるかもしれないかを必要とするならそれらがプロフィール特有の方法でどう広げられるかもしれないかという2つのレポートの書式を定義します。 翻訳者とミキサーで報告するレセプションの詳細はセクション7で明らかにされます。
Schulzrinne, et al. Standards Track [Page 35] RFC 3550 RTP July 2003
Schulzrinne、他 規格はRTP2003年7月にRFC3550を追跡します[35ページ]。
6.4.1 SR: Sender Report RTCP Packet
6.4.1 SR: 送付者レポートRTCPパケット
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
header |V=2|P| RC | PT=SR=200 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of sender |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
sender | NTP timestamp, most significant word |
info +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP timestamp, least significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sender's packet count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sender's octet count |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
report | SSRC_1 (SSRC of first source) |
block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | fraction lost | cumulative number of packets lost |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extended highest sequence number received |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| interarrival jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| last SR (LSR) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| delay since last SR (DLSR) |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
report | SSRC_2 (SSRC of second source) |
block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 : ... :
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| profile-specific extensions |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+++++++++++++++++++++++++++++++++ヘッダー|V=2|P| RC| PTはSR=200と等しいです。| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 送付者のSSRC| 送付者| NTPタイムスタンプ、最も重要な単語| インフォメーション+++++++++++++++++++++++++++++++++| NTPタイムスタンプ、最も重要でない単語| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTPタイムスタンプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 送付者のパケットカウント| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 送付者の八重奏カウント| レポート| SSRC_1(最初のソースのSSRC)| ブロック+++++++++++++++++++++++++++++++++1| 断片は損をしました。| 累積している数のパケットが損をしました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 拡張受け取られる中で最も高い一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | interarrivalジター| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 最後のSR(LSR)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 最後のSR(DLSR)以来の遅れ| レポート| SSRC_2(セカンドソースのSSRC)| +++++++++++++++++++++++++++++++++2を妨げてください: ... : +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | プロフィール特有の拡大| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The sender report packet consists of three sections, possibly followed by a fourth profile-specific extension section if defined. The first section, the header, is 8 octets long. The fields have the following meaning:
送付者レポートパケットは定義されるならことによると第4のプロフィール特有の拡大部によって従われた3つのセクションから成ります。 長い間、最初のセクション(ヘッダー)は8つの八重奏です。 分野には、以下の意味があります:
version (V): 2 bits
Identifies the version of RTP, which is the same in RTCP packets
as in RTP data packets. The version defined by this specification
is two (2).
バージョン(V): 2ビットのIdentifies、RTPのバージョン。(RTPはRTCPパケットでRTPデータ・パケットと同じです)。 この仕様で定義されたバージョンは2(2)です。
Schulzrinne, et al. Standards Track [Page 36] RFC 3550 RTP July 2003
Schulzrinne、他 規格はRTP2003年7月にRFC3550を追跡します[36ページ]。
padding (P): 1 bit
If the padding bit is set, this individual RTCP packet contains
some additional padding octets at the end which are not part of
the control information but are included in the length field. The
last octet of the padding is a count of how many padding octets
should be ignored, including itself (it will be a multiple of
four). Padding may be needed by some encryption algorithms with
fixed block sizes. In a compound RTCP packet, padding is only
required on one individual packet because the compound packet is
encrypted as a whole for the method in Section 9.1. Thus, padding
MUST only be added to the last individual packet, and if padding
is added to that packet, the padding bit MUST be set only on that
packet. This convention aids the header validity checks described
in Appendix A.2 and allows detection of packets from some early
implementations that incorrectly set the padding bit on the first
individual packet and add padding to the last individual packet.
詰め物(P): 詰め物が噛み付いた1ビットのIfは用意ができていて、この個々のRTCPパケットは終わりの制御情報の一部ではありませんが、長さの分野に含まれているいくつかの追加詰め物八重奏を含んでいます。 詰め物の最後の八重奏はいくつの詰め物八重奏が無視されるべきであるかに関するカウントです、それ自体を含んでいて(それは4の倍数になるでしょう)。 詰め物は固定ブロック・サイズでいくつかの暗号化アルゴリズムによって必要とされるかもしれません。 合成RTCPパケットでは、合成パケットがセクション9.1の方法のために全体でコード化されるので、詰め物が1つの個々のパケットの上で必要であるだけです。 したがって、最後の個々のパケットに詰め物を加えるだけでよいです、そして、詰め物がそのパケットに加えられるなら、そのパケットだけの上に詰め物ビットを設定しなければなりません。 このコンベンションは、最後の個々のパケットにそっと歩く不当に最初の個々のパケットの詰め物ビットを設定して、加えるいくつかの早めの実現から、Appendix A.2で説明されたヘッダーバリディティチェックを支援して、パケットの検出を許します。
reception report count (RC): 5 bits
The number of reception report blocks contained in this packet. A
value of zero is valid.
レセプションレポートカウント(RC): 5ビット、レセプションの数はこのパケットに含まれたブロックを報告します。 ゼロの値は有効です。
packet type (PT): 8 bits
Contains the constant 200 to identify this as an RTCP SR packet.
パケットタイプ(太平洋標準時の): 8ビットのContains、これがRTCP SRパケットであると認識する一定の200。
length: 16 bits
The length of this RTCP packet in 32-bit words minus one,
including the header and any padding. (The offset of one makes
zero a valid length and avoids a possible infinite loop in
scanning a compound RTCP packet, while counting 32-bit words
avoids a validity check for a multiple of 4.)
長さ: ヘッダーとどんな詰め物も含む1つを引いた32ビットの単語によるこのRTCPパケットの長さの16ビット。 (1のオフセットは、合成RTCPパケットをスキャンする際にどんなa有効な長さも作らないで、可能な無限ループを避けます、32ビットの単語を数えると、バリディティチェックは4の倍数のために避けられますが。)
SSRC: 32 bits
The synchronization source identifier for the originator of this
SR packet.
SSRC: 32ビット、同期はこのSRパケットの生成元のために識別子の出典を明示します。
The second section, the sender information, is 20 octets long and is present in every sender report packet. It summarizes the data transmissions from this sender. The fields have the following meaning:
第2セクション(送付者情報)は、長い間の20の八重奏であり、あらゆる送付者レポートパケットに存在しています。 それはこの送付者からデータ伝送をまとめます。 分野には、以下の意味があります:
NTP timestamp: 64 bits
Indicates the wallclock time (see Section 4) when this report was
sent so that it may be used in combination with timestamps
returned in reception reports from other receivers to measure
round-trip propagation to those receivers. Receivers should
expect that the measurement accuracy of the timestamp may be
limited to far less than the resolution of the NTP timestamp. The
measurement uncertainty of the timestamp is not indicated as it
NTPタイムスタンプ: タイムスタンプと組み合わせてそれを使用できるようにこのレポートを送ったとき、wallclockが調節する(セクション4を見ます)64ビットのIndicatesは他の受信機からのレセプションレポートで戻って、それらの受信機に往復の伝播を測定しました。 受信機は、タイムスタンプの測定精度がNTPタイムスタンプの解決遠い以下に制限されるかもしれないと予想するはずです。 タイムスタンプの測定の不確実性はそれとして示されません。
Schulzrinne, et al. Standards Track [Page 37] RFC 3550 RTP July 2003
Schulzrinne、他 規格はRTP2003年7月にRFC3550を追跡します[37ページ]。
may not be known. On a system that has no notion of wallclock
time but does have some system-specific clock such as "system
uptime", a sender MAY use that clock as a reference to calculate
relative NTP timestamps. It is important to choose a commonly
used clock so that if separate implementations are used to produce
the individual streams of a multimedia session, all
implementations will use the same clock. Until the year 2036,
relative and absolute timestamps will differ in the high bit so
(invalid) comparisons will show a large difference; by then one
hopes relative timestamps will no longer be needed. A sender that
has no notion of wallclock or elapsed time MAY set the NTP
timestamp to zero.
知られていないかもしれません。 wallclock時間の考えを全く持っていませんが、「システム・アップタイム」などのシステム特有のある時計を持っているシステムの上では、送付者は、相対的なNTPタイムスタンプについて計算するのに参照としてその時計を使用するかもしれません。 一般的に使用された時計を選ぶのは、別々の実現がマルチメディアセッションの個々の流れを起こすのに使用されると、すべての実現が同じ時計を使用するくらい重要です。 2036年まで、相対的で絶対のタイムスタンプが高いビットにおいて異なるので、(無効)の比較は大きな違いを示すでしょう、。 その時までには、人は、相対的なタイムスタンプがもう必要でないことを望んでいます。 wallclockか経過時間の考えを全く持っていない送付者はNTPタイムスタンプをゼロに設定するかもしれません。
RTP timestamp: 32 bits
Corresponds to the same time as the NTP timestamp (above), but in
the same units and with the same random offset as the RTP
timestamps in data packets. This correspondence may be used for
intra- and inter-media synchronization for sources whose NTP
timestamps are synchronized, and may be used by media-independent
receivers to estimate the nominal RTP clock frequency. Note that
in most cases this timestamp will not be equal to the RTP
timestamp in any adjacent data packet. Rather, it MUST be
calculated from the corresponding NTP timestamp using the
relationship between the RTP timestamp counter and real time as
maintained by periodically checking the wallclock time at a
sampling instant.
RTP timestamp: 32 bits Corresponds to the same time as the NTP timestamp (above), but in the same units and with the same random offset as the RTP timestamps in data packets. This correspondence may be used for intra- and inter-media synchronization for sources whose NTP timestamps are synchronized, and may be used by media-independent receivers to estimate the nominal RTP clock frequency. Note that in most cases this timestamp will not be equal to the RTP timestamp in any adjacent data packet. Rather, it MUST be calculated from the corresponding NTP timestamp using the relationship between the RTP timestamp counter and real time as maintained by periodically checking the wallclock time at a sampling instant.
sender's packet count: 32 bits
The total number of RTP data packets transmitted by the sender
since starting transmission up until the time this SR packet was
generated. The count SHOULD be reset if the sender changes its
SSRC identifier.
sender's packet count: 32 bits The total number of RTP data packets transmitted by the sender since starting transmission up until the time this SR packet was generated. The count SHOULD be reset if the sender changes its SSRC identifier.
sender's octet count: 32 bits
The total number of payload octets (i.e., not including header or
padding) transmitted in RTP data packets by the sender since
starting transmission up until the time this SR packet was
generated. The count SHOULD be reset if the sender changes its
SSRC identifier. This field can be used to estimate the average
payload data rate.
sender's octet count: 32 bits The total number of payload octets (i.e., not including header or padding) transmitted in RTP data packets by the sender since starting transmission up until the time this SR packet was generated. The count SHOULD be reset if the sender changes its SSRC identifier. This field can be used to estimate the average payload data rate.
The third section contains zero or more reception report blocks depending on the number of other sources heard by this sender since the last report. Each reception report block conveys statistics on the reception of RTP packets from a single synchronization source. Receivers SHOULD NOT carry over statistics when a source changes its SSRC identifier due to a collision. These statistics are:
The third section contains zero or more reception report blocks depending on the number of other sources heard by this sender since the last report. Each reception report block conveys statistics on the reception of RTP packets from a single synchronization source. Receivers SHOULD NOT carry over statistics when a source changes its SSRC identifier due to a collision. These statistics are:
Schulzrinne, et al. Standards Track [Page 38] RFC 3550 RTP July 2003
Schulzrinne, et al. Standards Track [Page 38] RFC 3550 RTP July 2003
SSRC_n (source identifier): 32 bits
The SSRC identifier of the source to which the information in this
reception report block pertains.
SSRC_n (source identifier): 32 bits The SSRC identifier of the source to which the information in this reception report block pertains.
fraction lost: 8 bits
The fraction of RTP data packets from source SSRC_n lost since the
previous SR or RR packet was sent, expressed as a fixed point
number with the binary point at the left edge of the field. (That
is equivalent to taking the integer part after multiplying the
loss fraction by 256.) This fraction is defined to be the number
of packets lost divided by the number of packets expected, as
defined in the next paragraph. An implementation is shown in
Appendix A.3. If the loss is negative due to duplicates, the
fraction lost is set to zero. Note that a receiver cannot tell
whether any packets were lost after the last one received, and
that there will be no reception report block issued for a source
if all packets from that source sent during the last reporting
interval have been lost.
fraction lost: 8 bits The fraction of RTP data packets from source SSRC_n lost since the previous SR or RR packet was sent, expressed as a fixed point number with the binary point at the left edge of the field. (That is equivalent to taking the integer part after multiplying the loss fraction by 256.) This fraction is defined to be the number of packets lost divided by the number of packets expected, as defined in the next paragraph. An implementation is shown in Appendix A.3. If the loss is negative due to duplicates, the fraction lost is set to zero. Note that a receiver cannot tell whether any packets were lost after the last one received, and that there will be no reception report block issued for a source if all packets from that source sent during the last reporting interval have been lost.
cumulative number of packets lost: 24 bits
The total number of RTP data packets from source SSRC_n that have
been lost since the beginning of reception. This number is
defined to be the number of packets expected less the number of
packets actually received, where the number of packets received
includes any which are late or duplicates. Thus, packets that
arrive late are not counted as lost, and the loss may be negative
if there are duplicates. The number of packets expected is
defined to be the extended last sequence number received, as
defined next, less the initial sequence number received. This may
be calculated as shown in Appendix A.3.
cumulative number of packets lost: 24 bits The total number of RTP data packets from source SSRC_n that have been lost since the beginning of reception. This number is defined to be the number of packets expected less the number of packets actually received, where the number of packets received includes any which are late or duplicates. Thus, packets that arrive late are not counted as lost, and the loss may be negative if there are duplicates. The number of packets expected is defined to be the extended last sequence number received, as defined next, less the initial sequence number received. This may be calculated as shown in Appendix A.3.
extended highest sequence number received: 32 bits
The low 16 bits contain the highest sequence number received in an
RTP data packet from source SSRC_n, and the most significant 16
bits extend that sequence number with the corresponding count of
sequence number cycles, which may be maintained according to the
algorithm in Appendix A.1. Note that different receivers within
the same session will generate different extensions to the
sequence number if their start times differ significantly.
extended highest sequence number received: 32 bits The low 16 bits contain the highest sequence number received in an RTP data packet from source SSRC_n, and the most significant 16 bits extend that sequence number with the corresponding count of sequence number cycles, which may be maintained according to the algorithm in Appendix A.1. Note that different receivers within the same session will generate different extensions to the sequence number if their start times differ significantly.
interarrival jitter: 32 bits
An estimate of the statistical variance of the RTP data packet
interarrival time, measured in timestamp units and expressed as an
unsigned integer. The interarrival jitter J is defined to be the
mean deviation (smoothed absolute value) of the difference D in
packet spacing at the receiver compared to the sender for a pair
of packets. As shown in the equation below, this is equivalent to
the difference in the "relative transit time" for the two packets;
interarrival jitter: 32 bits An estimate of the statistical variance of the RTP data packet interarrival time, measured in timestamp units and expressed as an unsigned integer. The interarrival jitter J is defined to be the mean deviation (smoothed absolute value) of the difference D in packet spacing at the receiver compared to the sender for a pair of packets. As shown in the equation below, this is equivalent to the difference in the "relative transit time" for the two packets;
Schulzrinne, et al. Standards Track [Page 39] RFC 3550 RTP July 2003
Schulzrinne, et al. Standards Track [Page 39] RFC 3550 RTP July 2003
the relative transit time is the difference between a packet's RTP
timestamp and the receiver's clock at the time of arrival,
measured in the same units.
the relative transit time is the difference between a packet's RTP timestamp and the receiver's clock at the time of arrival, measured in the same units.
If Si is the RTP timestamp from packet i, and Ri is the time of
arrival in RTP timestamp units for packet i, then for two packets
i and j, D may be expressed as
If Si is the RTP timestamp from packet i, and Ri is the time of arrival in RTP timestamp units for packet i, then for two packets i and j, D may be expressed as
D(i,j) = (Rj - Ri) - (Sj - Si) = (Rj - Sj) - (Ri - Si)
D(i,j) = (Rj - Ri) - (Sj - Si) = (Rj - Sj) - (Ri - Si)
The interarrival jitter SHOULD be calculated continuously as each
data packet i is received from source SSRC_n, using this
difference D for that packet and the previous packet i-1 in order
of arrival (not necessarily in sequence), according to the formula
The interarrival jitter SHOULD be calculated continuously as each data packet i is received from source SSRC_n, using this difference D for that packet and the previous packet i-1 in order of arrival (not necessarily in sequence), according to the formula
J(i) = J(i-1) + (|D(i-1,i)| - J(i-1))/16
J(i) = J(i-1) + (|D(i-1,i)| - J(i-1))/16
Whenever a reception report is issued, the current value of J is
sampled.
Whenever a reception report is issued, the current value of J is sampled.
The jitter calculation MUST conform to the formula specified here
in order to allow profile-independent monitors to make valid
interpretations of reports coming from different implementations.
This algorithm is the optimal first-order estimator and the gain
parameter 1/16 gives a good noise reduction ratio while
maintaining a reasonable rate of convergence [22]. A sample
implementation is shown in Appendix A.8. See Section 6.4.4 for a
discussion of the effects of varying packet duration and delay
before transmission.
The jitter calculation MUST conform to the formula specified here in order to allow profile-independent monitors to make valid interpretations of reports coming from different implementations. This algorithm is the optimal first-order estimator and the gain parameter 1/16 gives a good noise reduction ratio while maintaining a reasonable rate of convergence [22]. A sample implementation is shown in Appendix A.8. See Section 6.4.4 for a discussion of the effects of varying packet duration and delay before transmission.
last SR timestamp (LSR): 32 bits
The middle 32 bits out of 64 in the NTP timestamp (as explained in
Section 4) received as part of the most recent RTCP sender report
(SR) packet from source SSRC_n. If no SR has been received yet,
the field is set to zero.
last SR timestamp (LSR): 32 bits The middle 32 bits out of 64 in the NTP timestamp (as explained in Section 4) received as part of the most recent RTCP sender report (SR) packet from source SSRC_n. If no SR has been received yet, the field is set to zero.
delay since last SR (DLSR): 32 bits
The delay, expressed in units of 1/65536 seconds, between
receiving the last SR packet from source SSRC_n and sending this
reception report block. If no SR packet has been received yet
from SSRC_n, the DLSR field is set to zero.
delay since last SR (DLSR): 32 bits The delay, expressed in units of 1/65536 seconds, between receiving the last SR packet from source SSRC_n and sending this reception report block. If no SR packet has been received yet from SSRC_n, the DLSR field is set to zero.
Let SSRC_r denote the receiver issuing this receiver report.
Source SSRC_n can compute the round-trip propagation delay to
SSRC_r by recording the time A when this reception report block is
received. It calculates the total round-trip time A-LSR using the
last SR timestamp (LSR) field, and then subtracting this field to
leave the round-trip propagation delay as (A - LSR - DLSR). This
Let SSRC_r denote the receiver issuing this receiver report. Source SSRC_n can compute the round-trip propagation delay to SSRC_r by recording the time A when this reception report block is received. It calculates the total round-trip time A-LSR using the last SR timestamp (LSR) field, and then subtracting this field to leave the round-trip propagation delay as (A - LSR - DLSR). This
Schulzrinne, et al. Standards Track [Page 40] RFC 3550 RTP July 2003
Schulzrinne, et al. Standards Track [Page 40] RFC 3550 RTP July 2003
is illustrated in Fig. 2. Times are shown in both a hexadecimal
representation of the 32-bit fields and the equivalent floating-
point decimal representation. Colons indicate a 32-bit field
divided into a 16-bit integer part and 16-bit fraction part.
is illustrated in Fig. 2. Times are shown in both a hexadecimal representation of the 32-bit fields and the equivalent floating- point decimal representation. Colons indicate a 32-bit field divided into a 16-bit integer part and 16-bit fraction part.
This may be used as an approximate measure of distance to cluster
receivers, although some links have very asymmetric delays.
This may be used as an approximate measure of distance to cluster receivers, although some links have very asymmetric delays.
[10 Nov 1995 11:33:25.125 UTC] [10 Nov 1995 11:33:36.5 UTC]
n SR(n) A=b710:8000 (46864.500 s)
---------------------------------------------------------------->
v ^
ntp_sec =0xb44db705 v ^ dlsr=0x0005:4000 ( 5.250s)
ntp_frac=0x20000000 v ^ lsr =0xb705:2000 (46853.125s)
(3024992005.125 s) v ^
r v ^ RR(n)
---------------------------------------------------------------->
|<-DLSR->|
(5.250 s)
[10 Nov 1995 11:33:25.125 UTC] [10 Nov 1995 11:33:36.5 UTC] n SR(n) A=b710:8000 (46864.500 s) ----------------------------------------------------------------> v ^ ntp_sec =0xb44db705 v ^ dlsr=0x0005:4000 ( 5.250s) ntp_frac=0x20000000 v ^ lsr =0xb705:2000 (46853.125s) (3024992005.125 s) v ^ r v ^ RR(n) ----------------------------------------------------------------> |<-DLSR->| (5.250 s)
A 0xb710:8000 (46864.500 s) DLSR -0x0005:4000 ( 5.250 s) LSR -0xb705:2000 (46853.125 s) ------------------------------- delay 0x0006:2000 ( 6.125 s)
A 0xb710:8000 (46864.500 s) DLSR -0x0005:4000 ( 5.250 s) LSR -0xb705:2000 (46853.125 s) ------------------------------- delay 0x0006:2000 ( 6.125 s)
Figure 2: Example for round-trip time computation
Figure 2: Example for round-trip time computation
Schulzrinne, et al. Standards Track [Page 41] RFC 3550 RTP July 2003
Schulzrinne, et al. Standards Track [Page 41] RFC 3550 RTP July 2003
6.4.2 RR: Receiver Report RTCP Packet
6.4.2 RR: Receiver Report RTCP Packet
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
header |V=2|P| RC | PT=RR=201 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
report | SSRC_1 (SSRC of first source) |
block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | fraction lost | cumulative number of packets lost |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extended highest sequence number received |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| interarrival jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| last SR (LSR) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| delay since last SR (DLSR) |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
report | SSRC_2 (SSRC of second source) |
block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 : ... :
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| profile-specific extensions |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ header |V=2|P| RC | PT=RR=201 | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of packet sender | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ report | SSRC_1 (SSRC of first source) | block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 | fraction lost | cumulative number of packets lost | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | extended highest sequence number received | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | interarrival jitter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | last SR (LSR) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | delay since last SR (DLSR) | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ report | SSRC_2 (SSRC of second source) | block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 : ... : +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | profile-specific extensions | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the receiver report (RR) packet is the same as that of the SR packet except that the packet type field contains the constant 201 and the five words of sender information are omitted (these are the NTP and RTP timestamps and sender's packet and octet counts). The remaining fields have the same meaning as for the SR packet.
The format of the receiver report (RR) packet is the same as that of the SR packet except that the packet type field contains the constant 201 and the five words of sender information are omitted (these are the NTP and RTP timestamps and sender's packet and octet counts). The remaining fields have the same meaning as for the SR packet.
An empty RR packet (RC = 0) MUST be put at the head of a compound RTCP packet when there is no data transmission or reception to report.
An empty RR packet (RC = 0) MUST be put at the head of a compound RTCP packet when there is no data transmission or reception to report.
6.4.3 Extending the Sender and Receiver Reports
6.4.3 Extending the Sender and Receiver Reports
A profile SHOULD define profile-specific extensions to the sender report and receiver report if there is additional information that needs to be reported regularly about the sender or receivers. This method SHOULD be used in preference to defining another RTCP packet type because it requires less overhead:
A profile SHOULD define profile-specific extensions to the sender report and receiver report if there is additional information that needs to be reported regularly about the sender or receivers. This method SHOULD be used in preference to defining another RTCP packet type because it requires less overhead:
o fewer octets in the packet (no RTCP header or SSRC field);
o fewer octets in the packet (no RTCP header or SSRC field);
Schulzrinne, et al. Standards Track [Page 42] RFC 3550 RTP July 2003
Schulzrinne, et al. Standards Track [Page 42] RFC 3550 RTP July 2003
o simpler and faster parsing because applications running under that
profile would be programmed to always expect the extension fields
in the directly accessible location after the reception reports.
o simpler and faster parsing because applications running under that profile would be programmed to always expect the extension fields in the directly accessible location after the reception reports.
The extension is a fourth section in the sender- or receiver-report packet which comes at the end after the reception report blocks, if any. If additional sender information is required, then for sender reports it would be included first in the extension section, but for receiver reports it would not be present. If information about receivers is to be included, that data SHOULD be structured as an array of blocks parallel to the existing array of reception report blocks; that is, the number of blocks would be indicated by the RC field.
The extension is a fourth section in the sender- or receiver-report packet which comes at the end after the reception report blocks, if any. If additional sender information is required, then for sender reports it would be included first in the extension section, but for receiver reports it would not be present. If information about receivers is to be included, that data SHOULD be structured as an array of blocks parallel to the existing array of reception report blocks; that is, the number of blocks would be indicated by the RC field.
6.4.4 Analyzing Sender and Receiver Reports
6.4.4 Analyzing Sender and Receiver Reports
It is expected that reception quality feedback will be useful not only for the sender but also for other receivers and third-party monitors. The sender may modify its transmissions based on the feedback; receivers can determine whether problems are local, regional or global; network managers may use profile-independent monitors that receive only the RTCP packets and not the corresponding RTP data packets to evaluate the performance of their networks for multicast distribution.
It is expected that reception quality feedback will be useful not only for the sender but also for other receivers and third-party monitors. The sender may modify its transmissions based on the feedback; receivers can determine whether problems are local, regional or global; network managers may use profile-independent monitors that receive only the RTCP packets and not the corresponding RTP data packets to evaluate the performance of their networks for multicast distribution.
Cumulative counts are used in both the sender information and receiver report blocks so that differences may be calculated between any two reports to make measurements over both short and long time periods, and to provide resilience against the loss of a report. The difference between the last two reports received can be used to estimate the recent quality of the distribution. The NTP timestamp is included so that rates may be calculated from these differences over the interval between two reports. Since that timestamp is independent of the clock rate for the data encoding, it is possible to implement encoding- and profile-independent quality monitors.
Cumulative counts are used in both the sender information and receiver report blocks so that differences may be calculated between any two reports to make measurements over both short and long time periods, and to provide resilience against the loss of a report. The difference between the last two reports received can be used to estimate the recent quality of the distribution. The NTP timestamp is included so that rates may be calculated from these differences over the interval between two reports. Since that timestamp is independent of the clock rate for the data encoding, it is possible to implement encoding- and profile-independent quality monitors.
An example calculation is the packet loss rate over the interval between two reception reports. The difference in the cumulative number of packets lost gives the number lost during that interval. The difference in the extended last sequence numbers received gives the number of packets expected during the interval. The ratio of these two is the packet loss fraction over the interval. This ratio should equal the fraction lost field if the two reports are consecutive, but otherwise it may not. The loss rate per second can be obtained by dividing the loss fraction by the difference in NTP timestamps, expressed in seconds. The number of packets received is the number of packets expected minus the number lost. The number of
An example calculation is the packet loss rate over the interval between two reception reports. The difference in the cumulative number of packets lost gives the number lost during that interval. The difference in the extended last sequence numbers received gives the number of packets expected during the interval. The ratio of these two is the packet loss fraction over the interval. This ratio should equal the fraction lost field if the two reports are consecutive, but otherwise it may not. The loss rate per second can be obtained by dividing the loss fraction by the difference in NTP timestamps, expressed in seconds. The number of packets received is the number of packets expected minus the number lost. The number of
Schulzrinne, et al. Standards Track [Page 43] RFC 3550 RTP July 2003
Schulzrinne, et al. Standards Track [Page 43] RFC 3550 RTP July 2003
packets expected may also be used to judge the statistical validity of any loss estimates. For example, 1 out of 5 packets lost has a lower significance than 200 out of 1000.
packets expected may also be used to judge the statistical validity of any loss estimates. For example, 1 out of 5 packets lost has a lower significance than 200 out of 1000.
From the sender information, a third-party monitor can calculate the average payload data rate and the average packet rate over an interval without receiving the data. Taking the ratio of the two gives the average payload size. If it can be assumed that packet loss is independent of packet size, then the number of packets received by a particular receiver times the average payload size (or the corresponding packet size) gives the apparent throughput available to that receiver.
From the sender information, a third-party monitor can calculate the average payload data rate and the average packet rate over an interval without receiving the data. Taking the ratio of the two gives the average payload size. If it can be assumed that packet loss is independent of packet size, then the number of packets received by a particular receiver times the average payload size (or the corresponding packet size) gives the apparent throughput available to that receiver.
In addition to the cumulative counts which allow long-term packet loss measurements using differences between reports, the fraction lost field provides a short-term measurement from a single report. This becomes more important as the size of a session scales up enough that reception state information might not be kept for all receivers or the interval between reports becomes long enough that only one report might have been received from a particular receiver.
In addition to the cumulative counts which allow long-term packet loss measurements using differences between reports, the fraction lost field provides a short-term measurement from a single report. This becomes more important as the size of a session scales up enough that reception state information might not be kept for all receivers or the interval between reports becomes long enough that only one report might have been received from a particular receiver.
The interarrival jitter field provides a second short-term measure of network congestion. Packet loss tracks persistent congestion while the jitter measure tracks transient congestion. The jitter measure may indicate congestion before it leads to packet loss. The interarrival jitter field is only a snapshot of the jitter at the time of a report and is not intended to be taken quantitatively. Rather, it is intended for comparison across a number of reports from one receiver over time or from multiple receivers, e.g., within a single network, at the same time. To allow comparison across receivers, it is important the the jitter be calculated according to the same formula by all receivers.
The interarrival jitter field provides a second short-term measure of network congestion. Packet loss tracks persistent congestion while the jitter measure tracks transient congestion. The jitter measure may indicate congestion before it leads to packet loss. The interarrival jitter field is only a snapshot of the jitter at the time of a report and is not intended to be taken quantitatively. Rather, it is intended for comparison across a number of reports from one receiver over time or from multiple receivers, e.g., within a single network, at the same time. To allow comparison across receivers, it is important the the jitter be calculated according to the same formula by all receivers.
Because the jitter calculation is based on the RTP timestamp which represents the instant when the first data in the packet was sampled, any variation in the delay between that sampling instant and the time the packet is transmitted will affect the resulting jitter that is calculated. Such a variation in delay would occur for audio packets of varying duration. It will also occur for video encodings because the timestamp is the same for all the packets of one frame but those packets are not all transmitted at the same time. The variation in delay until transmission does reduce the accuracy of the jitter calculation as a measure of the behavior of the network by itself, but it is appropriate to include considering that the receiver buffer must accommodate it. When the jitter calculation is used as a comparative measure, the (constant) component due to variation in delay until transmission subtracts out so that a change in the
Because the jitter calculation is based on the RTP timestamp which represents the instant when the first data in the packet was sampled, any variation in the delay between that sampling instant and the time the packet is transmitted will affect the resulting jitter that is calculated. Such a variation in delay would occur for audio packets of varying duration. It will also occur for video encodings because the timestamp is the same for all the packets of one frame but those packets are not all transmitted at the same time. The variation in delay until transmission does reduce the accuracy of the jitter calculation as a measure of the behavior of the network by itself, but it is appropriate to include considering that the receiver buffer must accommodate it. When the jitter calculation is used as a comparative measure, the (constant) component due to variation in delay until transmission subtracts out so that a change in the
Schulzrinne, et al. Standards Track [Page 44] RFC 3550 RTP July 2003
Schulzrinne, et al. Standards Track [Page 44] RFC 3550 RTP July 2003
network jitter component can then be observed unless it is relatively small. If the change is small, then it is likely to be inconsequential.
network jitter component can then be observed unless it is relatively small. If the change is small, then it is likely to be inconsequential.
6.5 SDES: Source Description RTCP Packet
6.5 SDES: Source Description RTCP Packet
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
header |V=2|P| SC | PT=SDES=202 | length |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
chunk | SSRC/CSRC_1 |
1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SDES items |
| ... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
chunk | SSRC/CSRC_2 |
2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SDES items |
| ... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ header |V=2|P| SC | PT=SDES=202 | length | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ chunk | SSRC/CSRC_1 | 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SDES items | | ... | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ chunk | SSRC/CSRC_2 | 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SDES items | | ... | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
The SDES packet is a three-level structure composed of a header and zero or more chunks, each of which is composed of items describing the source identified in that chunk. The items are described individually in subsequent sections.
The SDES packet is a three-level structure composed of a header and zero or more chunks, each of which is composed of items describing the source identified in that chunk. The items are described individually in subsequent sections.
version (V), padding (P), length:
As described for the SR packet (see Section 6.4.1).
version (V), padding (P), length: As described for the SR packet (see Section 6.4.1).
packet type (PT): 8 bits
Contains the constant 202 to identify this as an RTCP SDES packet.
packet type (PT): 8 bits Contains the constant 202 to identify this as an RTCP SDES packet.
source count (SC): 5 bits
The number of SSRC/CSRC chunks contained in this SDES packet. A
value of zero is valid but useless.
source count (SC): 5 bits The number of SSRC/CSRC chunks contained in this SDES packet. A value of zero is valid but useless.
Each chunk consists of an SSRC/CSRC identifier followed by a list of zero or more items, which carry information about the SSRC/CSRC. Each chunk starts on a 32-bit boundary. Each item consists of an 8- bit type field, an 8-bit octet count describing the length of the text (thus, not including this two-octet header), and the text itself. Note that the text can be no longer than 255 octets, but this is consistent with the need to limit RTCP bandwidth consumption.
Each chunk consists of an SSRC/CSRC identifier followed by a list of zero or more items, which carry information about the SSRC/CSRC. Each chunk starts on a 32-bit boundary. Each item consists of an 8- bit type field, an 8-bit octet count describing the length of the text (thus, not including this two-octet header), and the text itself. Note that the text can be no longer than 255 octets, but this is consistent with the need to limit RTCP bandwidth consumption.
Schulzrinne, et al. Standards Track [Page 45] RFC 3550 RTP July 2003
Schulzrinne, et al. Standards Track [Page 45] RFC 3550 RTP July 2003
The text is encoded according to the UTF-8 encoding specified in RFC 2279 [5]. US-ASCII is a subset of this encoding and requires no additional encoding. The presence of multi-octet encodings is indicated by setting the most significant bit of a character to a value of one.
The text is encoded according to the UTF-8 encoding specified in RFC 2279 [5]. US-ASCII is a subset of this encoding and requires no additional encoding. The presence of multi-octet encodings is indicated by setting the most significant bit of a character to a value of one.
Items are contiguous, i.e., items are not individually padded to a 32-bit boundary. Text is not null terminated because some multi- octet encodings include null octets. The list of items in each chunk MUST be terminated by one or more null octets, the first of which is interpreted as an item type of zero to denote the end of the list. No length octet follows the null item type octet, but additional null octets MUST be included if needed to pad until the next 32-bit boundary. Note that this padding is separate from that indicated by the P bit in the RTCP header. A chunk with zero items (four null octets) is valid but useless.
Items are contiguous, i.e., items are not individually padded to a 32-bit boundary. Text is not null terminated because some multi- octet encodings include null octets. The list of items in each chunk MUST be terminated by one or more null octets, the first of which is interpreted as an item type of zero to denote the end of the list. No length octet follows the null item type octet, but additional null octets MUST be included if needed to pad until the next 32-bit boundary. Note that this padding is separate from that indicated by the P bit in the RTCP header. A chunk with zero items (four null octets) is valid but useless.
End systems send one SDES packet containing their own source identifier (the same as the SSRC in the fixed RTP header). A mixer sends one SDES packet containing a chunk for each contributing source from which it is receiving SDES information, or multiple complete SDES packets in the format above if there are more than 31 such sources (see Section 7).
End systems send one SDES packet containing their own source identifier (the same as the SSRC in the fixed RTP header). A mixer sends one SDES packet containing a chunk for each contributing source from which it is receiving SDES information, or multiple complete SDES packets in the format above if there are more than 31 such sources (see Section 7).
The SDES items currently defined are described in the next sections. Only the CNAME item is mandatory. Some items shown here may be useful only for particular profiles, but the item types are all assigned from one common space to promote shared use and to simplify profile-independent applications. Additional items may be defined in a profile by registering the type numbers with IANA as described in Section 15.
The SDES items currently defined are described in the next sections. Only the CNAME item is mandatory. Some items shown here may be useful only for particular profiles, but the item types are all assigned from one common space to promote shared use and to simplify profile-independent applications. Additional items may be defined in a profile by registering the type numbers with IANA as described in Section 15.
6.5.1 CNAME: Canonical End-Point Identifier SDES Item
6.5.1 CNAME: Canonical End-Point Identifier SDES Item
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CNAME=1 | length | user and domain name ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CNAME=1 | length | user and domain name ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The CNAME identifier has the following properties:
The CNAME identifier has the following properties:
o Because the randomly allocated SSRC identifier may change if a
conflict is discovered or if a program is restarted, the CNAME
item MUST be included to provide the binding from the SSRC
identifier to an identifier for the source (sender or receiver)
that remains constant.
o Because the randomly allocated SSRC identifier may change if a conflict is discovered or if a program is restarted, the CNAME item MUST be included to provide the binding from the SSRC identifier to an identifier for the source (sender or receiver) that remains constant.
Schulzrinne, et al. Standards Track [Page 46] RFC 3550 RTP July 2003
Schulzrinne, et al. Standards Track [Page 46] RFC 3550 RTP July 2003
o Like the SSRC identifier, the CNAME identifier SHOULD also be
unique among all participants within one RTP session.
o Like the SSRC identifier, the CNAME identifier SHOULD also be unique among all participants within one RTP session.
o To provide a binding across multiple media tools used by one
participant in a set of related RTP sessions, the CNAME SHOULD be
fixed for that participant.
o To provide a binding across multiple media tools used by one participant in a set of related RTP sessions, the CNAME SHOULD be fixed for that participant.
o To facilitate third-party monitoring, the CNAME SHOULD be suitable
for either a program or a person to locate the source.
o To facilitate third-party monitoring, the CNAME SHOULD be suitable for either a program or a person to locate the source.
Therefore, the CNAME SHOULD be derived algorithmically and not entered manually, when possible. To meet these requirements, the following format SHOULD be used unless a profile specifies an alternate syntax or semantics. The CNAME item SHOULD have the format "user@host", or "host" if a user name is not available as on single- user systems. For both formats, "host" is either the fully qualified domain name of the host from which the real-time data originates, formatted according to the rules specified in RFC 1034 [6], RFC 1035 [7] and Section 2.1 of RFC 1123 [8]; or the standard ASCII representation of the host's numeric address on the interface used for the RTP communication. For example, the standard ASCII representation of an IP Version 4 address is "dotted decimal", also known as dotted quad, and for IP Version 6, addresses are textually represented as groups of hexadecimal digits separated by colons (with variations as detailed in RFC 3513 [23]). Other address types are expected to have ASCII representations that are mutually unique. The fully qualified domain name is more convenient for a human observer and may avoid the need to send a NAME item in addition, but it may be difficult or impossible to obtain reliably in some operating environments. Applications that may be run in such environments SHOULD use the ASCII representation of the address instead.
Therefore, the CNAME SHOULD be derived algorithmically and not entered manually, when possible. To meet these requirements, the following format SHOULD be used unless a profile specifies an alternate syntax or semantics. The CNAME item SHOULD have the format "user@host", or "host" if a user name is not available as on single- user systems. For both formats, "host" is either the fully qualified domain name of the host from which the real-time data originates, formatted according to the rules specified in RFC 1034 [6], RFC 1035 [7] and Section 2.1 of RFC 1123 [8]; or the standard ASCII representation of the host's numeric address on the interface used for the RTP communication. For example, the standard ASCII representation of an IP Version 4 address is "dotted decimal", also known as dotted quad, and for IP Version 6, addresses are textually represented as groups of hexadecimal digits separated by colons (with variations as detailed in RFC 3513 [23]). Other address types are expected to have ASCII representations that are mutually unique. The fully qualified domain name is more convenient for a human observer and may avoid the need to send a NAME item in addition, but it may be difficult or impossible to obtain reliably in some operating environments. Applications that may be run in such environments SHOULD use the ASCII representation of the address instead.
Examples are "doe@sleepy.example.com", "doe@192.0.2.89" or "doe@2201:056D::112E:144A:1E24" for a multi-user system. On a system with no user name, examples would be "sleepy.example.com", "192.0.2.89" or "2201:056D::112E:144A:1E24".
Examples are "doe@sleepy.example.com", "doe@192.0.2.89" or "doe@2201:056D::112E:144A:1E24" for a multi-user system. On a system with no user name, examples would be "sleepy.example.com", "192.0.2.89" or "2201:056D::112E:144A:1E24".
The user name SHOULD be in a form that a program such as "finger" or "talk" could use, i.e., it typically is the login name rather than the personal name. The host name is not necessarily identical to the one in the participant's electronic mail address.
The user name SHOULD be in a form that a program such as "finger" or "talk" could use, i.e., it typically is the login name rather than the personal name. The host name is not necessarily identical to the one in the participant's electronic mail address.
This syntax will not provide unique identifiers for each source if an application permits a user to generate multiple sources from one host. Such an application would have to rely on the SSRC to further identify the source, or the profile for that application would have to specify additional syntax for the CNAME identifier.
This syntax will not provide unique identifiers for each source if an application permits a user to generate multiple sources from one host. Such an application would have to rely on the SSRC to further identify the source, or the profile for that application would have to specify additional syntax for the CNAME identifier.
Schulzrinne, et al. Standards Track [Page 47] RFC 3550 RTP July 2003
Schulzrinne, et al. Standards Track [Page 47] RFC 3550 RTP July 2003
If each application creates its CNAME independently, the resulting CNAMEs may not be identical as would be required to provide a binding across multiple media tools belonging to one participant in a set of related RTP sessions. If cross-media binding is required, it may be necessary for the CNAME of each tool to be externally configured with the same value by a coordination tool.
If each application creates its CNAME independently, the resulting CNAMEs may not be identical as would be required to provide a binding across multiple media tools belonging to one participant in a set of related RTP sessions. If cross-media binding is required, it may be necessary for the CNAME of each tool to be externally configured with the same value by a coordination tool.
Application writers should be aware that private network address assignments such as the Net-10 assignment proposed in RFC 1918 [24] may create network addresses that are not globally unique. This would lead to non-unique CNAMEs if hosts with private addresses and no direct IP connectivity to the public Internet have their RTP packets forwarded to the public Internet through an RTP-level translator. (See also RFC 1627 [25].) To handle this case, applications MAY provide a means to configure a unique CNAME, but the burden is on the translator to translate CNAMEs from private addresses to public addresses if necessary to keep private addresses from being exposed.
Application writers should be aware that private network address assignments such as the Net-10 assignment proposed in RFC 1918 [24] may create network addresses that are not globally unique. This would lead to non-unique CNAMEs if hosts with private addresses and no direct IP connectivity to the public Internet have their RTP packets forwarded to the public Internet through an RTP-level translator. (See also RFC 1627 [25].) To handle this case, applications MAY provide a means to configure a unique CNAME, but the burden is on the translator to translate CNAMEs from private addresses to public addresses if necessary to keep private addresses from being exposed.
6.5.2 NAME: User Name SDES Item
6.5.2 NAME: User Name SDES Item
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAME=2 | length | common name of source ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NAME=2 | length | common name of source ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This is the real name used to describe the source, e.g., "John Doe, Bit Recycler". It may be in any form desired by the user. For applications such as conferencing, this form of name may be the most desirable for display in participant lists, and therefore might be sent most frequently of those items other than CNAME. Profiles MAY establish such priorities. The NAME value is expected to remain constant at least for the duration of a session. It SHOULD NOT be relied upon to be unique among all participants in the session.
This is the real name used to describe the source, e.g., "John Doe, Bit Recycler". It may be in any form desired by the user. For applications such as conferencing, this form of name may be the most desirable for display in participant lists, and therefore might be sent most frequently of those items other than CNAME. Profiles MAY establish such priorities. The NAME value is expected to remain constant at least for the duration of a session. It SHOULD NOT be relied upon to be unique among all participants in the session.
6.5.3 EMAIL: Electronic Mail Address SDES Item
6.5.3 EMAIL: Electronic Mail Address SDES Item
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EMAIL=3 | length | email address of source ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EMAIL=3 | length | email address of source ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The email address is formatted according to RFC 2822 [9], for example, "John.Doe@example.com". The EMAIL value is expected to remain constant for the duration of a session.
The email address is formatted according to RFC 2822 [9], for example, "John.Doe@example.com". The EMAIL value is expected to remain constant for the duration of a session.
Schulzrinne, et al. Standards Track [Page 48] RFC 3550 RTP July 2003
Schulzrinne, et al. Standards Track [Page 48] RFC 3550 RTP July 2003
6.5.4 PHONE: Phone Number SDES Item
6.5.4 PHONE: Phone Number SDES Item
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PHONE=4 | length | phone number of source ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PHONE=4 | length | phone number of source ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The phone number SHOULD be formatted with the plus sign replacing the international access code. For example, "+1 908 555 1212" for a number in the United States.
The phone number SHOULD be formatted with the plus sign replacing the international access code. For example, "+1 908 555 1212" for a number in the United States.
6.5.5 LOC: Geographic User Location SDES Item
6.5.5 LOC: Geographic User Location SDES Item
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LOC=5 | length | geographic location of site ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LOC=5| 長さ| サイトの地理的な位置… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Depending on the application, different degrees of detail are appropriate for this item. For conference applications, a string like "Murray Hill, New Jersey" may be sufficient, while, for an active badge system, strings like "Room 2A244, AT&T BL MH" might be appropriate. The degree of detail is left to the implementation and/or user, but format and content MAY be prescribed by a profile. The LOC value is expected to remain constant for the duration of a session, except for mobile hosts.
アプリケーションによって、この項目に、詳細の異なった度合いは適切です。 アクティブなバッジシステムのための「余地の2A244、AT&T BL MH」のようなストリングは適切であるかもしれませんが、会議アプリケーションでは、「マリー・ヒル(ニュージャージー)」のようなストリングは十分であるかもしれなく、適切であってください。 詳細の度合いは実現、そして/または、ユーザに任せますが、形式と内容はプロフィールによって定められるかもしれません。 LOC値がモバイルホスト以外のセッションの持続時間に一定のままで残っていると予想されます。
6.5.6 TOOL: Application or Tool Name SDES Item
6.5.6 ツール: アプリケーションかツール名前SDESの品目
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TOOL=6 | length |name/version of source appl. ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ツール=6| 長さ|ソースapplの名前/バージョン。 ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A string giving the name and possibly version of the application generating the stream, e.g., "videotool 1.2". This information may be useful for debugging purposes and is similar to the Mailer or Mail-System-Version SMTP headers. The TOOL value is expected to remain constant for the duration of the session.
例えば、五弦が名前とことによると流れを発生させるアプリケーションのバージョンを与える「videotool1.2インチ。」 この情報は、デバッグ目的の役に立つかもしれなくて、メイラーかメールシステムバージョンSMTPヘッダーと同様です。 TOOL値がセッションの持続時間に一定のままで残っていると予想されます。
Schulzrinne, et al. Standards Track [Page 49] RFC 3550 RTP July 2003
Schulzrinne、他 規格はRTP2003年7月にRFC3550を追跡します[49ページ]。
6.5.7 NOTE: Notice/Status SDES Item
6.5.7 以下に注意してください。 通知/状態SDESの品目
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NOTE=7 | length | note about the source ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 注意=7| 長さ| ソースに関して、注意します。 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following semantics are suggested for this item, but these or other semantics MAY be explicitly defined by a profile. The NOTE item is intended for transient messages describing the current state of the source, e.g., "on the phone, can't talk". Or, during a seminar, this item might be used to convey the title of the talk. It should be used only to carry exceptional information and SHOULD NOT be included routinely by all participants because this would slow down the rate at which reception reports and CNAME are sent, thus impairing the performance of the protocol. In particular, it SHOULD NOT be included as an item in a user's configuration file nor automatically generated as in a quote-of-the-day.
以下の意味論はこの項目のために示されますが、これらか他の意味論がプロフィールによって明らかに定義されるかもしれません。 注意の品目はソースの現状、例えば「電話に関して、話すことができないこと」と説明する一時的なメッセージのために意図します。 または、セミナーの間、この項目は、話のタイトルを伝えるのに使用されるかもしれません。 それは使用されるべきですが、これはレセプションレポートとCNAMEが送られるレートを減速させるでしょう、したがって、すべての関係者によってきまりきって入れられて、例外的な情報とSHOULD NOTを運ぶ、その結果、プロトコルの性能を損なって。 特にそれ、項目としてユーザの構成ファイルに含まれていて、今日の名言のように自動的に発生するSHOULD NOT。
Since the NOTE item may be important to display while it is active, the rate at which other non-CNAME items such as NAME are transmitted might be reduced so that the NOTE item can take that part of the RTCP bandwidth. When the transient message becomes inactive, the NOTE item SHOULD continue to be transmitted a few times at the same repetition rate but with a string of length zero to signal the receivers. However, receivers SHOULD also consider the NOTE item inactive if it is not received for a small multiple of the repetition rate, or perhaps 20-30 RTCP intervals.
注意の品目がそれがアクティブである間、表示するために重要であるかもしれないので、NAMEなどの他の非CNAMEの品目が伝えられるレートは注意の品目がRTCP帯域幅のその地域を取ることができるように、低下するかもしれません。 一時的なメッセージが不活発になるとき、同じ繰返し率で数回伝えられますが、注意の品目SHOULDは長さのひもでずっと受信機のゼロを信号に合わせます。 しかしながら、また、それが繰返し率のわずかな倍数、または恐らく20-30回のRTCP間隔の間、受け取られないなら、受信機SHOULDは、注意の品目が不活発であると考えます。
6.5.8 PRIV: Private Extensions SDES Item
6.5.8 PRIV: 個人的な拡大SDESの品目
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PRIV=8 | length | prefix length |prefix string...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... | value string ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PRIV=8| 長さ| 接頭語の長さ|ストリングを前に置いてください… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... | ストリングを評価してください… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This item is used to define experimental or application-specific SDES extensions. The item contains a prefix consisting of a length-string pair, followed by the value string filling the remainder of the item and carrying the desired information. The prefix length field is 8 bits long. The prefix string is a name chosen by the person defining the PRIV item to be unique with respect to other PRIV items this application might receive. The application creator might choose to use the application name plus an additional subtype identification if
この項目は、実験的であるかアプリケーション特有のSDES拡張子を定義するのに使用されます。 項目は長さストリング組から成る接頭語を含んでいます、項目の残りをいっぱいにする値のストリングが支えていて、必要な情報を運んで。 接頭語長さの分野は長さ8ビットです。 接頭語ストリングはこのアプリケーションが受けるかもしれない他のPRIVの品目に関して特有になるようにPRIVの品目を定義する人によって選ばれた名前です。 アプリケーション創造者は、アプリケーション名と追加「副-タイプ」識別を使用するのを選ぶかもしれません。
Schulzrinne, et al. Standards Track [Page 50] RFC 3550 RTP July 2003
Schulzrinne、他 規格はRTP2003年7月にRFC3550を追跡します[50ページ]。
needed. Alternatively, it is RECOMMENDED that others choose a name based on the entity they represent, then coordinate the use of the name within that entity.
必要。 あるいはまた、他のものが彼らが表す実体に基づく名前を選んで、次に、その実体の中で名前の使用を調整するのは、RECOMMENDEDです。
Note that the prefix consumes some space within the item's total length of 255 octets, so the prefix should be kept as short as possible. This facility and the constrained RTCP bandwidth SHOULD NOT be overloaded; it is not intended to satisfy all the control communication requirements of all applications.
接頭語ができるだけ短いのが保たれるべきであるために接頭語が項目の255の八重奏の全長の中で何らかのスペースを消費することに注意してください。 この施設と強制的なRTCP帯域幅SHOULD NOT、積みすぎられてください。 それがすべてのアプリケーションのすべてのコントロールコミュニケーション要件を満たすことを意図しません。
SDES PRIV prefixes will not be registered by IANA. If some form of the PRIV item proves to be of general utility, it SHOULD instead be assigned a regular SDES item type registered with IANA so that no prefix is required. This simplifies use and increases transmission efficiency.
SDES PRIV接頭語はIANAによって登録されないでしょう。 形式のPRIVの品目はいくつかなら一般的なユーティリティのである判明して、それはSHOULDです。代わりに接頭語は全く必要でないようにIANAに示されたレギュラーのSDES項目タイプに割り当てられてください。 これは、使用を簡素化して、伝達効率を増加させます。
6.6 BYE: Goodbye RTCP Packet
6.6 さようなら: さようならのRTCPパケット
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| SC | PT=BYE=203 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC/CSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
(opt) | length | reason for leaving ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P| サウスカロライナ| PT=さようなら、=203| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC/CSRC| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : 等しい..選ぶ| 長さ| いなくなるには、推論してください… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The BYE packet indicates that one or more sources are no longer active.
BYEパケットは、1つ以上のソースがもう活発でないことを示します。
version (V), padding (P), length:
As described for the SR packet (see Section 6.4.1).
(P)、長さを水増しするバージョン(V): SRパケット(セクション6.4.1を見る)のために説明されるように。
packet type (PT): 8 bits
Contains the constant 203 to identify this as an RTCP BYE packet.
パケットタイプ(太平洋標準時の): 8ビットのContains、これがRTCP BYEパケットであると認識する一定の203。
source count (SC): 5 bits
The number of SSRC/CSRC identifiers included in this BYE packet.
A count value of zero is valid, but useless.
ソースカウント(サウスカロライナ): このBYEパケットにSSRC/CSRC識別子の数を含んでいる5ビット。 ゼロのカウント値は、有効ですが、役に立ちません。
The rules for when a BYE packet should be sent are specified in Sections 6.3.7 and 8.2.
BYEパケットが送られるべきである時の間の規則はセクション6.3.7と8.2で指定されます。
Schulzrinne, et al. Standards Track [Page 51] RFC 3550 RTP July 2003
Schulzrinne、他 規格はRTP2003年7月にRFC3550を追跡します[51ページ]。
If a BYE packet is received by a mixer, the mixer SHOULD forward the BYE packet with the SSRC/CSRC identifier(s) unchanged. If a mixer shuts down, it SHOULD send a BYE packet listing all contributing sources it handles, as well as its own SSRC identifier. Optionally, the BYE packet MAY include an 8-bit octet count followed by that many octets of text indicating the reason for leaving, e.g., "camera malfunction" or "RTP loop detected". The string has the same encoding as that described for SDES. If the string fills the packet to the next 32-bit boundary, the string is not null terminated. If not, the BYE packet MUST be padded with null octets to the next 32- bit boundary. This padding is separate from that indicated by the P bit in the RTCP header.
ミキサーでBYEパケットを受け取るなら、SSRC/CSRC識別子が変わりがない状態でミキサーSHOULDはBYEパケットを進めます。 ミキサーはaであるなら停止します、それ。SHOULDはそれが扱うソースを皆、寄付しながら、BYEパケットを記載させます、それ自身のSSRC識別子と同様に。 任意に、BYEパケットはいなくなる理由、例えば、「カメラ不調」を示すテキストのそんなに多くの八重奏があとに続いた8ビット・オクテットカウントか「検出されたRTP輪」を含むかもしれません。 ストリングには、SDESのためのそんなに説明されるのと同じコード化があります。 ストリングが次の32ビットの境界にパケットをいっぱいにしているなら、ストリングは終えられた状態でヌルではありません。 そうでなければ、ヌル八重奏で次の32ビット境界にBYEパケットを水増ししなければなりません。 この詰め物はRTCPヘッダーでPビットによって示されたそれから別々です。
6.7 APP: Application-Defined RTCP Packet
6.7装置: アプリケーションで定義されたRTCPパケット
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| subtype | PT=APP=204 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC/CSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| name (ASCII) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| application-dependent data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P| 「副-タイプ」| PT=装置=204| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC/CSRC| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 名前(ASCII)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | アプリケーション依存するデータ… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The APP packet is intended for experimental use as new applications and new features are developed, without requiring packet type value registration. APP packets with unrecognized names SHOULD be ignored. After testing and if wider use is justified, it is RECOMMENDED that each APP packet be redefined without the subtype and name fields and registered with IANA using an RTCP packet type.
新しいアプリケーションと新機能が開発されているので、APPパケットは実験用のために意図します、パケットタイプ値の登録を必要としないで。 認識されていない名前SHOULDが無視されているAPPパケット。 テストしていた後に、より広い使用が正当であるなら、それぞれのAPPパケットがRTCPパケットタイプを使用することで「副-タイプ」と名前欄なしで再定義されて、IANAに登録されるのは、RECOMMENDEDです。
version (V), padding (P), length:
As described for the SR packet (see Section 6.4.1).
(P)、長さを水増しするバージョン(V): SRパケット(セクション6.4.1を見る)のために説明されるように。
subtype: 5 bits
May be used as a subtype to allow a set of APP packets to be
defined under one unique name, or for any application-dependent
data.
「副-タイプ」: 5ビットの5月、「副-タイプ」として使用されて、1セットのAPPパケットが1つのユニークな名前、またはどんなアプリケーション依存するデータのためにも定義されるのを許容してください。
packet type (PT): 8 bits
Contains the constant 204 to identify this as an RTCP APP packet.
パケットタイプ(太平洋標準時の): 8ビットのContains、これがRTCP APPパケットであると認識する一定の204。
Schulzrinne, et al. Standards Track [Page 52] RFC 3550 RTP July 2003
Schulzrinne、他 規格はRTP2003年7月にRFC3550を追跡します[52ページ]。
name: 4 octets
A name chosen by the person defining the set of APP packets to be
unique with respect to other APP packets this application might
receive. The application creator might choose to use the
application name, and then coordinate the allocation of subtype
values to others who want to define new packet types for the
application. Alternatively, it is RECOMMENDED that others choose
a name based on the entity they represent, then coordinate the use
of the name within that entity. The name is interpreted as a
sequence of four ASCII characters, with uppercase and lowercase
characters treated as distinct.
以下を命名してください。 このアプリケーションが受けるかもしれない他のAPPパケットに関して特有になるようにAPPパケットのセットを定義する人によって選ばれた4つの八重奏Aの名前。 アプリケーション創造者は、アプリケーションのための新しいパケットタイプを定義したがっている他のものにアプリケーション名を使用して、次に、「副-タイプ」値の配分を調整するのを選ぶかもしれません。 あるいはまた、他のものが彼らが表す実体に基づく名前を選んで、次に、その実体の中で名前の使用を調整するのは、RECOMMENDEDです。 大文字していて小文字のキャラクタが異なるとして扱われている状態で、存在という名前は4人のASCII文字の系列を解釈しました。
application-dependent data: variable length
Application-dependent data may or may not appear in an APP packet.
It is interpreted by the application and not RTP itself. It MUST
be a multiple of 32 bits long.
アプリケーション依存するデータ: 可変長のApplication依存するデータはAPPパケットに現れるかもしれません。 それはRTPではなく、アプリケーション自体で解釈されます。 長い間、それは32ビットの倍数であるに違いありません。
7. RTP Translators and Mixers
7. RTP翻訳者とミキサー
In addition to end systems, RTP supports the notion of "translators" and "mixers", which could be considered as "intermediate systems" at the RTP level. Although this support adds some complexity to the protocol, the need for these functions has been clearly established by experiments with multicast audio and video applications in the Internet. Example uses of translators and mixers given in Section 2.3 stem from the presence of firewalls and low bandwidth connections, both of which are likely to remain.
エンドシステムに加えて、RTPはRTPレベルにおける「中間システム」であるとみなすことができた「翻訳者」と「ミキサー」の概念を支持します。 このサポートは何らかの複雑さをプロトコルに追加しますが、マルチキャストオーディオとビデオ・アプリケーションがインターネットにある状態で、これらの機能の必要性は実験で明確に確立されました。 セクション2.3で与えられた翻訳者とミキサーの例の用途はファイアウォールと低い帯域幅接続の存在によります。その両方が残っていそうです。
7.1 General Description
7.1 概説
An RTP translator/mixer connects two or more transport-level "clouds". Typically, each cloud is defined by a common network and transport protocol (e.g., IP/UDP) plus a multicast address and transport level destination port or a pair of unicast addresses and ports. (Network-level protocol translators, such as IP version 4 to IP version 6, may be present within a cloud invisibly to RTP.) One system may serve as a translator or mixer for a number of RTP sessions, but each is considered a logically separate entity.
RTP翻訳者/ミキサーは「雲」という2以上輸送レベルを接続します。 一般的なネットワークとトランスポート・プロトコル(例えば、IP/UDP)によって通常、各雲は定義されます、そして、マルチキャストアドレスと輸送は仕向港か1組のユニキャストアドレスとポートを平らにします。 (IPバージョン4からIPバージョン6などのネットワークレベルプロトコル翻訳者は雲の中に目につかないほどRTPに出席しているかもしれません。) 1台のシステムが多くのRTPセッションのための翻訳者かミキサーとして勤めるかもしれませんが、それぞれが論理的に別々の実体であると考えられます。
In order to avoid creating a loop when a translator or mixer is installed, the following rules MUST be observed:
翻訳者かミキサーがインストールされるとき、輪を作成するのを避けるために、以下の規則を守らなければなりません:
o Each of the clouds connected by translators and mixers
participating in one RTP session either MUST be distinct from all
the others in at least one of these parameters (protocol, address,
port), or MUST be isolated at the network level from the others.
o 1つのRTPセッションのときに関与する翻訳者とミキサーによって接続されたそれぞれの雲は、すべての他のものと少なくともこれらのパラメタ(プロトコル、アドレス、ポート)の1つにおいて異ならなければならないか、または他のものからネットワークレベルで孤立しているに違いありません。
Schulzrinne, et al. Standards Track [Page 53] RFC 3550 RTP July 2003
Schulzrinne、他 規格はRTP2003年7月にRFC3550を追跡します[53ページ]。
o A derivative of the first rule is that there MUST NOT be multiple
translators or mixers connected in parallel unless by some
arrangement they partition the set of sources to be forwarded.
o 最初の規則の派生物による複数の翻訳者がいたはずがないか、または何らかのアレンジメントで転送されるソースのセットを仕切らない場合ミキサーが並列に接続したということです。
Similarly, all RTP end systems that can communicate through one or more RTP translators or mixers share the same SSRC space, that is, the SSRC identifiers MUST be unique among all these end systems. Section 8.2 describes the collision resolution algorithm by which SSRC identifiers are kept unique and loops are detected.
同様に、1個以上のRTP翻訳者かミキサーを通って交信できるすべてのRTPエンドシステムが同じSSRCスペースを共有します、すなわち、SSRC識別子はこれらのすべてのエンドシステムの中でユニークであるに違いありません。セクション8.2はSSRC識別子がユニークに保たれて、輪が検出される衝突解決アルゴリズムを説明します。
There may be many varieties of translators and mixers designed for different purposes and applications. Some examples are to add or remove encryption, change the encoding of the data or the underlying protocols, or replicate between a multicast address and one or more unicast addresses. The distinction between translators and mixers is that a translator passes through the data streams from different sources separately, whereas a mixer combines them to form one new stream:
異なる役割とアプリケーションのために設計された多くの種類の翻訳者とミキサーがあるかもしれません。 いくつかの例は、暗号化を加えるか、取り除く、データか基本的なプロトコルのコード化を変えるか、またはマルチキャストアドレスと1つ以上のユニキャストアドレスの間で模写することです。 翻訳者とミキサーの区別は翻訳者が別々にさまざまな原因からデータ・ストリームを通り抜けるということですが、ミキサーは1つの新しい流れを形成するために彼らを結合します:
Translator: Forwards RTP packets with their SSRC identifier
intact; this makes it possible for receivers to identify
individual sources even though packets from all the sources pass
through the same translator and carry the translator's network
source address. Some kinds of translators will pass through the
data untouched, but others MAY change the encoding of the data and
thus the RTP data payload type and timestamp. If multiple data
packets are re-encoded into one, or vice versa, a translator MUST
assign new sequence numbers to the outgoing packets. Losses in
the incoming packet stream may induce corresponding gaps in the
outgoing sequence numbers. Receivers cannot detect the presence
of a translator unless they know by some other means what payload
type or transport address was used by the original source.
翻訳者: それらのSSRC識別子が完全な状態でパケットをRTPに送ります。 これで、すべてのソースからのパケットが同じ翻訳者を通り抜けて、翻訳者のネットワークソースアドレスを運びますが、受信機が個々のソースを特定するのが可能になります。 数種類の翻訳者はデータ触れないのにもかかわらずの、他のもの5月の変化にその結果、データ、RTPデータペイロードタイプ、およびタイムスタンプのコード化を通すでしょう。 複数のデータ・パケットが1つに再コード化されるか、逆もまた同様ですなら、翻訳者は新しい一連番号を出発しているパケットに割り当てなければなりません。 入って来るパケットの流れにおける損失は外向的な一連番号における対応するギャップを引き起こすかもしれません。 それらが、どんなペイロードがタイプされるかをある他の手段で知らないなら、受信機が翻訳者の存在を検出できませんか、または輸送アドレスは一次資料によって使用されました。
Mixer: Receives streams of RTP data packets from one or more
sources, possibly changes the data format, combines the streams in
some manner and then forwards the combined stream. Since the
timing among multiple input sources will not generally be
synchronized, the mixer will make timing adjustments among the
streams and generate its own timing for the combined stream, so it
is the synchronization source. Thus, all data packets forwarded
by a mixer MUST be marked with the mixer's own SSRC identifier.
In order to preserve the identity of the original sources
contributing to the mixed packet, the mixer SHOULD insert their
SSRC identifiers into the CSRC identifier list following the fixed
RTP header of the packet. A mixer that is also itself a
contributing source for some packet SHOULD explicitly include its
own SSRC identifier in the CSRC list for that packet.
ミキサー: 1つ以上のソースからRTPデータ・パケットの流れを受けて、ことによるとデータの形式を変えて、何らかの方法で流れを合成して、次に、結合した流れを進めます。 複数の入力ソースの中のタイミングが一般に同期しないので、ミキサーが流れの中でタイミング調整をして、それ自身の結合した流れのタイミングを発生させるので、それは同期ソースです。 したがって、ミキサーの自己のSSRC識別子でミキサーによって進められたすべてのデータ・パケットをマークしなければなりません。 混ぜられたパケットに貢献する一次資料のアイデンティティを保持するために、パケットの固定RTPヘッダーに続いて、ミキサーSHOULDは彼らのSSRC識別子をCSRC名前の並びに挿入します。 またあるパケットSHOULDのための貢献しているソース自体であるミキサーは明らかにそのパケットのためのCSRCリストのそれ自身のSSRC識別子を含んでいます。
Schulzrinne, et al. Standards Track [Page 54] RFC 3550 RTP July 2003
Schulzrinne、他 規格はRTP2003年7月にRFC3550を追跡します[54ページ]。
For some applications, it MAY be acceptable for a mixer not to
identify sources in the CSRC list. However, this introduces the
danger that loops involving those sources could not be detected.
いくつかのアプリケーションにおいて、ミキサーがCSRCリストのソースを特定しないのは、許容できるかもしれません。 しかしながら、これはそれらのソースにかかわる輪を検出できなかったという危険を導入します。
The advantage of a mixer over a translator for applications like audio is that the output bandwidth is limited to that of one source even when multiple sources are active on the input side. This may be important for low-bandwidth links. The disadvantage is that receivers on the output side don't have any control over which sources are passed through or muted, unless some mechanism is implemented for remote control of the mixer. The regeneration of synchronization information by mixers also means that receivers can't do inter-media synchronization of the original streams. A multi- media mixer could do it.
アプリケーションがオーディオが好きであるので、翻訳者の上のミキサーの利点は複数のソースがインプット側で活発であるときにさえ、出力帯域幅が1つのソースのものに制限されるということです。 低バンド幅リンクに、これは重要であるかもしれません。 不都合はアウトプット側の上の受信機にはソースが通り抜けるか、または音を消される少しのコントロールもないということです、何らかのメカニズムがミキサーの遠隔操作のために実行されない場合。 また、ミキサーによる同期情報の再生は、受信機が元の流れの中間体同期ができないことを意味します。マルチメディアミキサーはそれをするかもしれません。
[E1] [E6]
| |
E1:17 | E6:15 |
| | E6:15
V M1:48 (1,17) M1:48 (1,17) V M1:48 (1,17)
(M1)-------------><T1>-----------------><T2>-------------->[E7]
^ ^ E4:47 ^ E4:47
E2:1 | E4:47 | | M3:89 (64,45)
| | |
[E2] [E4] M3:89 (64,45) |
| legend:
[E3] --------->(M2)----------->(M3)------------| [End system]
E3:64 M2:12 (64) ^ (Mixer)
| E5:45 <Translator>
|
[E5] source: SSRC (CSRCs)
------------------->
[1E] [6E]| | E1:17| E6:15| | | E6:15V M1: 48(1、17)M1: 48(1、17)V M1: 48(1、17)(M1)-------------><T1>。-----------------><T2>。-------------->[7E]^ ^E4:47^E4:47E2:1| E4:47| | M3: 89(64、45)| | | [4E]の[2E]のM3: 89(64、45)| | 伝説: [3E]--------->(M2)----------->(M3)------------| [エンドシステム]E3:64M2: 12(64)^(ミキサー)| E5:45<翻訳者>。| [5E]のソース: SSRC(CSRCs)------------------->。
Figure 3: Sample RTP network with end systems, mixers and translators
図3: エンドシステム、ミキサー、および翻訳者とのサンプルRTPネットワーク
A collection of mixers and translators is shown in Fig. 3 to illustrate their effect on SSRC and CSRC identifiers. In the figure, end systems are shown as rectangles (named E), translators as triangles (named T) and mixers as ovals (named M). The notation "M1: 48(1,17)" designates a packet originating a mixer M1, identified by M1's (random) SSRC value of 48 and two CSRC identifiers, 1 and 17, copied from the SSRC identifiers of packets from E1 and E2.
ミキサーと翻訳者の収集は、SSRCへの彼らの効果とCSRC識別子を例証するために図3に示されます。 図では、エンドシステムは長方形(Eと命名される)、三角形としての翻訳者(Tと命名されます)、および楕円形としてのミキサー(Mと命名される)として示されます。 記法、「M1:」 「48(1、17)」は自分の48と2つのCSRC識別子、1、および17の(無作為)のSSRC値によって特定されたM1が1ユーロと2ユーロからパケットに関するSSRC識別子を回避したミキサーを溯源するパケットを指定します。
7.2 RTCP Processing in Translators
7.2 翻訳者でのRTCP処理
In addition to forwarding data packets, perhaps modified, translators and mixers MUST also process RTCP packets. In many cases, they will take apart the compound RTCP packets received from end systems to
また、恐らく変更されたデータ・パケットを進めることに加えて、翻訳者とミキサーはRTCPパケットを処理しなければなりません。 多くの場合、彼らはRTCPパケットがエンドシステムから受信した化合物を分解するでしょう。
Schulzrinne, et al. Standards Track [Page 55] RFC 3550 RTP July 2003
Schulzrinne、他 規格はRTP2003年7月にRFC3550を追跡します[55ページ]。
aggregate SDES information and to modify the SR or RR packets. Retransmission of this information may be triggered by the packet arrival or by the RTCP interval timer of the translator or mixer itself.
そして、SDES情報に集合になってください、SRかRRパケットを変更するために。 この情報のRetransmissionはパケット到着か翻訳者かミキサー自体のRTCPインタバルタイマによって引き起こされるかもしれません。
A translator that does not modify the data packets, for example one that just replicates between a multicast address and a unicast address, MAY simply forward RTCP packets unmodified as well. A translator that transforms the payload in some way MUST make corresponding transformations in the SR and RR information so that it still reflects the characteristics of the data and the reception quality. These translators MUST NOT simply forward RTCP packets. In general, a translator SHOULD NOT aggregate SR and RR packets from different sources into one packet since that would reduce the accuracy of the propagation delay measurements based on the LSR and DLSR fields.
データ・パケットを変更しない翻訳者(例えばマルチキャストアドレスとユニキャストアドレスの間でただ模写されるもの)は単にまた、変更されていないパケットをRTCPに送るかもしれません。 何らかの方法でペイロードを変える翻訳者は、まだデータの特性とレセプション品質を反映しているように、SRとRRでの対応する変化を情報にしなければなりません。 これらの翻訳者はパケットをRTCPに絶対に送ってはいけません。 一般に、それ以来の1つのパケットへのさまざまな原因からの翻訳者のSHOULD NOTの集合SRとRRパケットはLSRとDLSR分野に基づく伝播遅れ測定値の精度を低下させるでしょう。
SR sender information: A translator does not generate its own
sender information, but forwards the SR packets received from one
cloud to the others. The SSRC is left intact but the sender
information MUST be modified if required by the translation. If a
translator changes the data encoding, it MUST change the "sender's
byte count" field. If it also combines several data packets into
one output packet, it MUST change the "sender's packet count"
field. If it changes the timestamp frequency, it MUST change the
"RTP timestamp" field in the SR packet.
SR送付者情報: 翻訳者はそれ自身の送付者情報を発生させるのではなく、SRパケットが1つの雲から他のものまで受けたフォワードを発生させます。 SSRCは完全なままにされますが、必要なら翻訳で送付者情報を変更しなければなりません。 翻訳者がzデータの符号化を変えるなら、それは「送付者のバイト・カウント」分野を変えなければなりません。 また、1つの出力パケットにいくつかのデータ・パケットを結合するなら、それは「送付者のパケットカウント」分野を変えなければなりません。 タイムスタンプ頻度を変えるなら、それはSRパケットの「RTPタイムスタンプ」分野を変えなければなりません。
SR/RR reception report blocks: A translator forwards reception
reports received from one cloud to the others. Note that these
flow in the direction opposite to the data. The SSRC is left
intact. If a translator combines several data packets into one
output packet, and therefore changes the sequence numbers, it MUST
make the inverse manipulation for the packet loss fields and the
"extended last sequence number" field. This may be complex. In
the extreme case, there may be no meaningful way to translate the
reception reports, so the translator MAY pass on no reception
report at all or a synthetic report based on its own reception.
The general rule is to do what makes sense for a particular
translation.
SR/RRレセプションレポートブロック: 翻訳者は1つの雲から他のものまで受け取られたレセプションレポートを転送します。 これらが指示正反対をデータに流れることに注意してください。 SSRCは完全なままにされます。 翻訳者が1つの出力パケットにいくつかのデータ・パケットを結合して、したがって、一連番号を変えるなら、それはパケット損失のための逆さの操作を分野と「最後の一連番号に広げられて」分野にしなければなりません。 これは複雑であるかもしれません。 極端な場合には、レセプションレポートを翻訳するどんな重要な方法もないかもしれないので、翻訳者はすべてかそれ自身のレセプションに基づく合成のレポートでレセプションレポートを全く伝えないかもしれません。 一般的な規則は特定の翻訳のために理解できることをすることです。
A translator does not require an SSRC identifier of its own, but
MAY choose to allocate one for the purpose of sending reports
about what it has received. These would be sent to all the
connected clouds, each corresponding to the translation of the
data stream as sent to that cloud, since reception reports are
normally multicast to all participants.
翻訳者は、それ自身のSSRC識別子を必要としませんが、それが何を受けたかに関するレポートを送る目的のための1つを割り当てるのを選ぶかもしれません。 すべての接続雲にこれらを送るでしょう、それぞれその雲に送られるデータ・ストリームに関する翻訳に対応しています、レセプションレポートが通常すべての関係者へのマルチキャストであるので。
Schulzrinne, et al. Standards Track [Page 56] RFC 3550 RTP July 2003
Schulzrinne、他 規格はRTP2003年7月にRFC3550を追跡します[56ページ]。
SDES: Translators typically forward without change the SDES
information they receive from one cloud to the others, but MAY,
for example, decide to filter non-CNAME SDES information if
bandwidth is limited. The CNAMEs MUST be forwarded to allow SSRC
identifier collision detection to work. A translator that
generates its own RR packets MUST send SDES CNAME information
about itself to the same clouds that it sends those RR packets.
SDES: 翻訳者は、変化なしで彼らが1つの雲から他のものまで受け取るSDES情報を通常転送しますが、例えば、帯域幅が限られるなら、非CNAME SDES情報をフィルターにかけると決めるかもしれません。 SSRC識別子衝突検出が働くのを許容するためにCNAMEsを進めなければなりません。 それ自身のRRパケットを発生させる翻訳者はそれらのRRパケットを送るという同じ雲へのそれ自体の情報をSDES CNAMEに送らなければなりません。
BYE: Translators forward BYE packets unchanged. A translator
that is about to cease forwarding packets SHOULD send a BYE packet
to each connected cloud containing all the SSRC identifiers that
were previously being forwarded to that cloud, including the
translator's own SSRC identifier if it sent reports of its own.
さようなら: 翻訳者はパケットをBYEに変わりがない状態で送ります。 SHOULDが送るパケットにBYEパケットを送るのをそれぞれにやめようとしている翻訳者は以前にその雲に転送されていたすべてのSSRC識別子を含む雲を接続しました、それ自身のレポートを送ったなら翻訳者の自己のSSRC識別子を含んでいて。
APP: Translators forward APP packets unchanged.
装置: 翻訳者はパケットをAPPに変わりがない状態で送ります。
7.3 RTCP Processing in Mixers
7.3 ミキサーでのRTCP処理
Since a mixer generates a new data stream of its own, it does not pass through SR or RR packets at all and instead generates new information for both sides.
ミキサーがそれ自身の新しいデータ・ストリームを発生させるので、それは、SRかRRパケットを全く通り抜けないで、代わりに両側のための新情報を発生させます。
SR sender information: A mixer does not pass through sender
information from the sources it mixes because the characteristics
of the source streams are lost in the mix. As a synchronization
source, the mixer SHOULD generate its own SR packets with sender
information about the mixed data stream and send them in the same
direction as the mixed stream.
SR送付者情報: ソースの流れの特性がミックスで失われているので、ミキサーはそれが混ぜるソースから送付者情報を通り抜けません。 同期ソースとして、ミキサーSHOULDは複雑なデータ・ストリームの送付者情報でそれ自身のSRパケットを発生させて、複雑な流れと同じ方向にそれらを送ります。
SR/RR reception report blocks: A mixer generates its own
reception reports for sources in each cloud and sends them out
only to the same cloud. It MUST NOT send these reception reports
to the other clouds and MUST NOT forward reception reports from
one cloud to the others because the sources would not be SSRCs
there (only CSRCs).
SR/RRレセプションレポートブロック: ミキサーは、各雲でそれ自身のレセプションレポートをソースに作って、同じ雲だけに彼らを出します。 ソースはそこのSSRCs(CSRCsだけ)でないでしょう、それがこれらのレセプションレポートを他の雲に送ってはいけなくて、したがって、1つの雲から他のものまでレポートをレセプションに転送してはいけません。
SDES: Mixers typically forward without change the SDES
information they receive from one cloud to the others, but MAY,
for example, decide to filter non-CNAME SDES information if
bandwidth is limited. The CNAMEs MUST be forwarded to allow SSRC
identifier collision detection to work. (An identifier in a CSRC
list generated by a mixer might collide with an SSRC identifier
generated by an end system.) A mixer MUST send SDES CNAME
information about itself to the same clouds that it sends SR or RR
packets.
SDES: ミキサーは、変化なしで彼らが1つの雲から他のものまで受け取るSDES情報を通常転送しますが、例えば、帯域幅が限られるなら、非CNAME SDES情報をフィルターにかけると決めるかもしれません。 SSRC識別子衝突検出が働くのを許容するためにCNAMEsを進めなければなりません。 (ミキサーで発生するCSRCリストの識別子はエンドシステムで発生するSSRC識別子に衝突するかもしれません。) ミキサーはSRかRRにパケットを送るという同じ雲へのそれ自体の情報をSDES CNAMEに送らなければなりません。
Schulzrinne, et al. Standards Track [Page 57] RFC 3550 RTP July 2003
Schulzrinne、他 規格はRTP2003年7月にRFC3550を追跡します[57ページ]。
Since mixers do not forward SR or RR packets, they will typically
be extracting SDES packets from a compound RTCP packet. To
minimize overhead, chunks from the SDES packets MAY be aggregated
into a single SDES packet which is then stacked on an SR or RR
packet originating from the mixer. A mixer which aggregates SDES
packets will use more RTCP bandwidth than an individual source
because the compound packets will be longer, but that is
appropriate since the mixer represents multiple sources.
Similarly, a mixer which passes through SDES packets as they are
received will be transmitting RTCP packets at higher than the
single source rate, but again that is correct since the packets
come from multiple sources. The RTCP packet rate may be different
on each side of the mixer.
ミキサーがSRかRRにパケットを送らないので、それらは合成RTCPパケットからSDESパケットを通常抽出するでしょう。 オーバーヘッドを最小にするために、SDESパケットからの塊は次にミキサーから発しながらSRかRRパケットの上で積み重ねられる単一のSDESパケットに集められるかもしれません。 合成パケットが、より長くなるので、SDESパケットに集められるミキサーは個々のソースより多くのRTCP帯域幅を使用するでしょうが、ミキサーが複数のソースの代理をするので、それは適切です。 同様に、それらが受け取られているときSDESパケットを通り抜けるミキサーはただ一つのソースレートより高いところでRTCPパケットを伝えるでしょうが、パケットが複数のソースから来るので、一方、それは正しいです。 RTCPパケットレートはミキサーの各側面で異なっているかもしれません。
A mixer that does not insert CSRC identifiers MAY also refrain
from forwarding SDES CNAMEs. In this case, the SSRC identifier
spaces in the two clouds are independent. As mentioned earlier,
this mode of operation creates a danger that loops can't be
detected.
また、CSRC識別子を挿入しないミキサーは、SDES CNAMEsを進めるのを控えるかもしれません。 この場合、2つの雲におけるSSRC識別子空間は独立しています。 先に述べたように、この運転モードは輪を検出できないという危険を作成します。
BYE: Mixers MUST forward BYE packets. A mixer that is about to
cease forwarding packets SHOULD send a BYE packet to each
connected cloud containing all the SSRC identifiers that were
previously being forwarded to that cloud, including the mixer's
own SSRC identifier if it sent reports of its own.
さようなら: ミキサーはパケットをBYEに送らなければなりません。 SHOULDが送るパケットにBYEパケットを送るのをそれぞれにやめようとしているミキサーは以前にその雲に転送されていたすべてのSSRC識別子を含む雲を接続しました、それ自身のレポートを送ったならミキサーの自己のSSRC識別子を含んでいて。
APP: The treatment of APP packets by mixers is application-specific.
装置: ミキサーによるAPPパケットの処理はアプリケーション特有です。
7.4 Cascaded Mixers
7.4 どっと落しているミキサー
An RTP session may involve a collection of mixers and translators as shown in Fig. 3. If two mixers are cascaded, such as M2 and M3 in the figure, packets received by a mixer may already have been mixed and may include a CSRC list with multiple identifiers. The second mixer SHOULD build the CSRC list for the outgoing packet using the CSRC identifiers from already-mixed input packets and the SSRC identifiers from unmixed input packets. This is shown in the output arc from mixer M3 labeled M3:89(64,45) in the figure. As in the case of mixers that are not cascaded, if the resulting CSRC list has more than 15 identifiers, the remainder cannot be included.
RTPセッションは図3に示されるようにミキサーと翻訳者の収集にかかわるかもしれません。 2個のミキサーがM2やM3のように図をどっと落しているなら、ミキサーで受け取られたパケットは、既に複雑であり、複数の識別子があるCSRCリストを含むかもしれません。 2番目のミキサーSHOULDは、既に混ぜられた入力パケットからのCSRC識別子とまざりもののない入力パケットからのSSRC識別子を使用することで出発しているパケットのためのCSRCリストを造ります。 これはM3とラベルされたミキサーM3から出力アークで示されます: 図の89(64、45)。 結果として起こるCSRCリストに15以上の識別子があるならどっと落さないミキサーに関するケースのように、残りを含むことができません。
Schulzrinne, et al. Standards Track [Page 58] RFC 3550 RTP July 2003
Schulzrinne、他 規格はRTP2003年7月にRFC3550を追跡します[58ページ]。
8. SSRC Identifier Allocation and Use
8. SSRC識別子配分と使用
The SSRC identifier carried in the RTP header and in various fields of RTCP packets is a random 32-bit number that is required to be globally unique within an RTP session. It is crucial that the number be chosen with care in order that participants on the same network or starting at the same time are not likely to choose the same number.
RTPヘッダーとRTCPパケットの多岐で運ばれたSSRC識別子はRTPセッション以内にグローバルに特有になるのに必要である無作為の32ビットの数です。 数が同時にの同じネットワークか始めの関係者が同じ数を選びそうにないために慎重に選ばれているのは、重要です。
It is not sufficient to use the local network address (such as an IPv4 address) for the identifier because the address may not be unique. Since RTP translators and mixers enable interoperation among multiple networks with different address spaces, the allocation patterns for addresses within two spaces might result in a much higher rate of collision than would occur with random allocation.
それは、アドレスがユニークでないかもしれないので、識別子に、企業内情報通信網アドレス(IPv4アドレスなどの)を使用するために十分ではありません。 RTP翻訳者とミキサーが複数のネットワークの中で異なったアドレス空間でinteroperationを有効にするので、2つの空間の中のアドレスのための配分パターンは無作為の配分で起こるだろうより衝突のはるかに高い速度をもたらすかもしれません。
Multiple sources running on one host would also conflict.
また、1人のホストで走っている複数のソースが闘争するでしょう。
It is also not sufficient to obtain an SSRC identifier simply by calling random() without carefully initializing the state. An example of how to generate a random identifier is presented in Appendix A.6.
また、単に慎重に状態を初期化しないで無作為の()と呼ぶことによってSSRC識別子を得るのも十分ではありません。 無作為の識別子をどう発生させるかに関する例はAppendix A.6に提示されます。
8.1 Probability of Collision
8.1 衝突確率
Since the identifiers are chosen randomly, it is possible that two or more sources will choose the same number. Collision occurs with the highest probability when all sources are started simultaneously, for example when triggered automatically by some session management event. If N is the number of sources and L the length of the identifier (here, 32 bits), the probability that two sources independently pick the same value can be approximated for large N [26] as 1 - exp(-N**2 / 2**(L+1)). For N=1000, the probability is roughly 10**-4.
識別子が手当たりしだいに選ばれているので、2つ以上のソースが同じ数を選ぶのは、可能です。 すべてのソースが同時に始められるとき、衝突は最も高い確率で起こります、例えば、いくつかのセッション管理イベントによって自動的に引き起こされると。 Nがソースの数であり、Lが識別子(ここと、32ビット)の長さであるなら、大きいN[26]のために、1として2つのソースが独自に同じ値を選ぶという確率に近似できます--exp(-N**2 / 2**(L+1))。 N=1000に関しては、確率はおよそ10**-4です。
The typical collision probability is much lower than the worst-case above. When one new source joins an RTP session in which all the other sources already have unique identifiers, the probability of collision is just the fraction of numbers used out of the space. Again, if N is the number of sources and L the length of the identifier, the probability of collision is N / 2**L. For N=1000, the probability is roughly 2*10**-7.
典型的な衝突確率は上の最悪の場合よりはるかに低いです。 1つの新しいソースが他のすべてのソースが既にユニークな識別子を持っているRTPセッションに参加するとき、衝突確率はスペースから使用される数の部分です。 一方、Nがソースの数であり、Lが識別子の長さであるなら、衝突確率はN/2**Lです。 N=1000に関しては、確率はおよそ2*10**7です。
The probability of collision is further reduced by the opportunity for a new source to receive packets from other participants before sending its first packet (either data or control). If the new source keeps track of the other participants (by SSRC identifier), then
衝突確率は最初のパケット(データかコントロールのどちらか)を送る前に新しい情報筋が他の関係者からパケットを受け取る機会によってさらに減少させられます。 次に、新しいソースが他の関係者(SSRC識別子による)の動向をおさえるなら
Schulzrinne, et al. Standards Track [Page 59] RFC 3550 RTP July 2003
Schulzrinne、他 規格はRTP2003年7月にRFC3550を追跡します[59ページ]。
before transmitting its first packet the new source can verify that its identifier does not conflict with any that have been received, or else choose again.
最初のパケットを伝える前に、新しいソースは、識別子が受け取られたいずれも衝突しないことを確かめるか、または再び選ぶことができます。
8.2 Collision Resolution and Loop Detection
8.2 衝突解決と輪の検出
Although the probability of SSRC identifier collision is low, all RTP implementations MUST be prepared to detect collisions and take the appropriate actions to resolve them. If a source discovers at any time that another source is using the same SSRC identifier as its own, it MUST send an RTCP BYE packet for the old identifier and choose another random one. (As explained below, this step is taken only once in case of a loop.) If a receiver discovers that two other sources are colliding, it MAY keep the packets from one and discard the packets from the other when this can be detected by different source transport addresses or CNAMEs. The two sources are expected to resolve the collision so that the situation doesn't last.
SSRC識別子衝突の確率が低いのですが、すべてのRTP実装をそれらを決議するために衝突を検出して、適切な行動を取るように準備しなければなりません。 情報筋が、いつでも別のソースがそれ自身のものと同じSSRC識別子を使用していると発見するなら、それは、古い識別子のためにRTCP BYEパケットを送って、別の無作為の1つを選ばなければなりません。 (以下で説明されるように、輪の場合に一度だけこの方法を取ります。) 受信機が、他の2つのソースが衝突していると発見するなら、異なったソース輸送のアドレスかCNAMEsがこれを検出できるとき、それは、1からパケットを控えて、もう片方からパケットを捨てるかもしれません。 2つのソースが衝突を決議すると予想されるので、状況は持続しません。
Because the random SSRC identifiers are kept globally unique for each RTP session, they can also be used to detect loops that may be introduced by mixers or translators. A loop causes duplication of data and control information, either unmodified or possibly mixed, as in the following examples:
無作為のSSRC識別子がそれぞれのRTPセッションのためにグローバルにユニークに保たれるので、また、ミキサーか翻訳者によって紹介されるかもしれない輪を検出するのにそれらを使用できます。 輪は変更されていないかことによると以下の例のように複雑なデータの重複と制御情報を引き起こします:
o A translator may incorrectly forward a packet to the same
multicast group from which it has received the packet, either
directly or through a chain of translators. In that case, the
same packet appears several times, originating from different
network sources.
o 翻訳者は直接かそれがパケットを受けた同じマルチキャストグループか、翻訳者のチェーンを通して不当にパケットを進めるかもしれません。 その場合、異なったネットワークソースから発して、同じパケットは何度か現れます。
o Two translators incorrectly set up in parallel, i.e., with the
same multicast groups on both sides, would both forward packets
from one multicast group to the other. Unidirectional translators
would produce two copies; bidirectional translators would form a
loop.
o すなわち、同じマルチキャストグループが両側にある状態で、不当に平行にセットアップされた2人の翻訳者が1つのマルチキャストグループからもう片方までともにパケットを進めるでしょう。 単方向の翻訳者はコピー2部を生産するでしょう。 双方向の翻訳者は輪を形成するでしょう。
o A mixer can close a loop by sending to the same transport
destination upon which it receives packets, either directly or
through another mixer or translator. In this case a source might
show up both as an SSRC on a data packet and a CSRC in a mixed
data packet.
o ミキサーは、直接か別のそれがパケットを受ける同じ輸送の目的地か、ミキサーか翻訳者を通って発信することによって、輪を閉じることができます。 この場合、ソースはデータ・パケットの上のSSRCと混ぜられたデータ・パケットのCSRCとして現れるかもしれません。
A source may discover that its own packets are being looped, or that packets from another source are being looped (a third-party loop). Both loops and collisions in the random selection of a source identifier result in packets arriving with the same SSRC identifier but a different source transport address, which may be that of the end system originating the packet or an intermediate system.
情報筋は、それ自身のパケットが輪にされているか、または別のソースからのパケットが輪にされている(第三者輪)と発見するかもしれません。 ソース識別子のランダム・セレクションにおける、輪と衝突の両方がパケットを溯源するエンドシステムのものか中間システムであるかもしれない同じSSRC識別子にもかかわらず、異なったソース輸送アドレスと共に到着するパケットをもたらします。
Schulzrinne, et al. Standards Track [Page 60] RFC 3550 RTP July 2003
Schulzrinne、他 規格はRTP2003年7月にRFC3550を追跡します[60ページ]。
Therefore, if a source changes its source transport address, it MAY also choose a new SSRC identifier to avoid being interpreted as a looped source. (This is not MUST because in some applications of RTP sources may be expected to change addresses during a session.) Note that if a translator restarts and consequently changes the source transport address (e.g., changes the UDP source port number) on which it forwards packets, then all those packets will appear to receivers to be looped because the SSRC identifiers are applied by the original source and will not change. This problem can be avoided by keeping the source transport address fixed across restarts, but in any case will be resolved after a timeout at the receivers.
したがって、また、ソースがソース輸送アドレスを変えるなら、それは、輪にされたソースとして解釈されるのを避けるために新しいSSRC識別子を選ぶかもしれません。 これはそうです。(使用目的によってはRTPでは、ソースがセッションの間、アドレスを変えると予想されるかもしれないのでそうしてはいけない、) 翻訳者が再開して、その結果、それがパケットを進めるソース輸送アドレス(例えば、UDPソースポート番号を変える)を変えるならそれらのすべてのパケットが受信機に現れることに注意して、SSRC識別子が一次資料によって当てはまられていて、変化しないので、輪にされてください。 この問題は保つことによって避けられて、横切って修理されたソース輸送アドレスが再開しますが、どのような場合でも、タイムアウトの後に受信機で決議されるということであるかもしれません。
Loops or collisions occurring on the far side of a translator or mixer cannot be detected using the source transport address if all copies of the packets go through the translator or mixer, however, collisions may still be detected when chunks from two RTCP SDES packets contain the same SSRC identifier but different CNAMEs.
パケットのすべてのコピーが翻訳者かミキサーを通るならソース輸送アドレスを使用するのを翻訳者かミキサーを越して現れる輪か衝突は検出できないで、しかしながら、衝突はまだ検出されましたが、2つのRTCP SDESパケットからの塊が同じSSRC識別子を含んでいると異なったCNAMEsであるかもしれません。
To detect and resolve these conflicts, an RTP implementation MUST include an algorithm similar to the one described below, though the implementation MAY choose a different policy for which packets from colliding third-party sources are kept. The algorithm described below ignores packets from a new source or loop that collide with an established source. It resolves collisions with the participant's own SSRC identifier by sending an RTCP BYE for the old identifier and choosing a new one. However, when the collision was induced by a loop of the participant's own packets, the algorithm will choose a new identifier only once and thereafter ignore packets from the looping source transport address. This is required to avoid a flood of BYE packets.
これらの闘争を検出して、解決するために、RTP実装は以下で説明されたものと同様のアルゴリズムを含まなければなりません、実装が衝突している第三者ソースからのパケットが保たれる異なった方針を選ぶかもしれませんが。 以下で説明されたアルゴリズムは新しいソースか輪からの確立したソースと衝突するパケットを無視します。 それは、古い識別子のためにRTCP BYEを送って、新しいものを選ぶことによって、関係者の自己のSSRC識別子との衝突を決議します。 しかしながら、衝突がその後関係者の自己のパケットの輪によって引き起こされたとき、アルゴリズムは、一度だけ新しい識別子を選んで、ループソース輸送アドレスからパケットを無視するでしょう。 これが、BYEパケットの洪水を避けるのに必要です。
This algorithm requires keeping a table indexed by the source identifier and containing the source transport addresses from the first RTP packet and first RTCP packet received with that identifier, along with other state for that source. Two source transport addresses are required since, for example, the UDP source port numbers may be different on RTP and RTCP packets. However, it may be assumed that the network address is the same in both source transport addresses.
このアルゴリズムは、ソース識別子でテーブルに索引をつけ続けて、輸送が最初のRTPパケットとその識別子で受け取られた最初のRTCPパケットから演説するソースを含むのを必要とします、そのソースへの他の状態と共に。 例えば、UDPソースポート番号がRTPとRTCPパケットで異なるかもしれないので、2つのソース輸送アドレスが必要です。 しかしながら、ネットワーク・アドレスが両方のソース輸送アドレスで同じであると思われるかもしれません。
Each SSRC or CSRC identifier received in an RTP or RTCP packet is looked up in the source identifier table in order to process that data or control information. The source transport address from the packet is compared to the corresponding source transport address in the table to detect a loop or collision if they don't match. For control packets, each element with its own SSRC identifier, for example an SDES chunk, requires a separate lookup. (The SSRC identifier in a reception report block is an exception because it
RTPかRTCPパケットに受け取られたそれぞれのSSRCかCSRC識別子が、そのデータか制御情報を処理するためにソース識別子テーブルで調べられます。 彼らが合っていないなら、パケットからのソース輸送アドレスは、輪か衝突を検出するためにテーブルの対応するソース輸送アドレスにたとえられます。 コントロールパケットに関しては、それ自身のSSRC識別子がある各要素(例えば、SDES塊)は別々のルックアップを必要とします。 (レセプションレポートブロックのSSRC識別子が例外である、それ
Schulzrinne, et al. Standards Track [Page 61] RFC 3550 RTP July 2003
Schulzrinne、他 規格はRTP2003年7月にRFC3550を追跡します[61ページ]。
identifies a source heard by the reporter, and that SSRC identifier is unrelated to the source transport address of the RTCP packet sent by the reporter.) If the SSRC or CSRC is not found, a new entry is created. These table entries are removed when an RTCP BYE packet is received with the corresponding SSRC identifier and validated by a matching source transport address, or after no packets have arrived for a relatively long time (see Section 6.2.1).
レポーターによって聞かれたソースであって、SSRC識別子がレポーターによって送られたRTCPパケットのソース輸送アドレスに関係ないのを特定します。) SSRCかCSRCが見つけられないなら、新しいエントリーは作成されます。 これらのテーブル項目は、RTCP BYEパケットを対応するSSRC識別子で受け取って、合っているソース輸送アドレスで有効にするとき、取り除くか、またはパケットの後でないのに比較的長い時間、到着していません(セクション6.2.1を見てください)。
Note that if two sources on the same host are transmitting with the same source identifier at the time a receiver begins operation, it would be possible that the first RTP packet received came from one of the sources while the first RTCP packet received came from the other. This would cause the wrong RTCP information to be associated with the RTP data, but this situation should be sufficiently rare and harmless that it may be disregarded.
受信機が活動を開始するとき同じホストの上の2つの情報筋が同じソース識別子で伝わっているなら、受け取られた最初のRTCPパケットがもう片方から来ましたが、受け取られた最初のRTPパケットがソースのひとりから来たのが、可能であることに注意してください。 これはRTPデータに関連していて、この状況だけが十分まれであって、無害であるべきであるということであるそれがあるかもしれない情報を無視されていた状態で間違ったRTCPに引き起こすでしょう。
In order to track loops of the participant's own data packets, the implementation MUST also keep a separate list of source transport addresses (not identifiers) that have been found to be conflicting. As in the source identifier table, two source transport addresses MUST be kept to separately track conflicting RTP and RTCP packets. Note that the conflicting address list should be short, usually empty. Each element in this list stores the source addresses plus the time when the most recent conflicting packet was received. An element MAY be removed from the list when no conflicting packet has arrived from that source for a time on the order of 10 RTCP report intervals (see Section 6.2).
また、関係者の自己のデータ・パケットの輪を追跡するために、実装は闘争しているのがわかったソース輸送アドレス(識別子でない)の別々のリストを保たなければなりません。 別々に闘争しているRTPとRTCPパケットの跡をつけるためにソース識別子テーブルに2つのソース輸送アドレスを保管しなければならないとき。 闘争住所録が短いはずであることに注意してください、そして、通常、空になってください。 このリストの各要素は最新の闘争パケットが受け取られたソースアドレスと時を保存します。 闘争パケットが全く10回のRTCPレポート間隔の注文の時間そのソースから到着していないとき(セクション6.2を見てください)、リストから要素を取り除くかもしれません。
For the algorithm as shown, it is assumed that the participant's own source identifier and state are included in the source identifier table. The algorithm could be restructured to first make a separate comparison against the participant's own source identifier.
示されるとしてのアルゴリズムにおいて、関係者の自己のソース識別子と状態がソース識別子テーブルに含まれていると思われます。 最初に関係者の自己のソース識別子に対して別々の比較をするようにアルゴリズムを再構築できました。
if (SSRC or CSRC identifier is not found in the source
identifier table) {
create a new entry storing the data or control source
transport address, the SSRC or CSRC and other state;
}
(SSRCかCSRC識別子がソース識別子テーブルで見つけられません)データか制御電源輸送アドレスかSSRCかCSRCと他の状態を保存する新しいエントリーを作成してください。
/* Identifier is found in the table */
/*識別子はテーブル*/で見つけられます。
else if (table entry was created on receipt of a control packet
and this is the first data packet or vice versa) {
store the source transport address from this packet;
}
else if (source transport address from the packet does not match
the one saved in the table entry for this identifier) {
ほか、(テーブル項目はコントロールパケットを受け取り次第作成されました、そして、これは最初のデータ・パケットであるか逆もまた同様です)、ソース輸送がこのパケットから扱う店;、ほか、(パケットからのソース輸送アドレスはこの識別子のためのテーブル項目で保存されたものに合っていません)
Schulzrinne, et al. Standards Track [Page 62] RFC 3550 RTP July 2003
Schulzrinne、他 規格はRTP2003年7月にRFC3550を追跡します[62ページ]。
/* An identifier collision or a loop is indicated */
識別子衝突かaが輪にする/*は示された*/です。
if (source identifier is not the participant's own) {
/* OPTIONAL error counter step */
if (source identifier is from an RTCP SDES chunk
containing a CNAME item that differs from the CNAME
in the table entry) {
count a third-party collision;
} else {
count a third-party loop;
}
abort processing of data packet or control element;
/* MAY choose a different policy to keep new source */
}
(ソース識別子は関係者が自己であるということではありません)/*OPTIONALの誤りの反対のステップ*/、(ソース識別子はテーブル項目でCNAMEと異なっているCNAMEの品目を含むRTCP SDES塊から来ています)、カウントa第三者衝突;、ほか、カウントa第三者輪;、データ処理パケットか制御要素を中止してください; /*は、新しいソース*/を保つために異なった方針を選ぶかもしれません。
/* A collision or loop of the participant's own packets */
/*は、関係者の自己のパケット*/の衝突か輪です。
else if (source transport address is found in the list of
conflicting data or control source transport
addresses) {
/* OPTIONAL error counter step */
if (source identifier is not from an RTCP SDES chunk
containing a CNAME item or CNAME is the
participant's own) {
count occurrence of own traffic looped;
}
mark current time in conflicting address list entry;
abort processing of data packet or control element;
}
ほか、(アドレスが闘争データのリストで見つけられるソース輸送か制御電源輸送アドレス)です。/*OPTIONALの誤りの反対のステップ*/、(ソース識別子はCNAMEの品目かCNAMEを含む塊がRTCP SDESからの、関係者が自己であるということであるということではありません) 輪にされた自己のトラフィックのカウント発生; 現在の時間が中で闘争している住所録エントリーであるとマークしてください; データ・パケットか制御要素のアボート処理
/* New collision, change SSRC identifier */
/*新しい衝突、変化SSRC識別子*/
else {
log occurrence of a collision;
create a new entry in the conflicting data or control
source transport address list and mark current time;
send an RTCP BYE packet with the old SSRC identifier;
choose a new SSRC identifier;
create a new entry in the source identifier table with
the old SSRC plus the source transport address from
the data or control packet being processed;
}
}
ほか、衝突の発生を登録してください; 闘争データか制御電源輸送住所録における新しいエントリーを作成してください、そして、現在の時間を示してください; 古いSSRC識別子があるRTCP BYEパケットを送ってください; 新しいSSRC識別子を選んでください; データかコントロールパケットからの古いSSRCとソース輸送アドレスが処理されている状態で、ソース識別子テーブルで新しいエントリーを作成してください;。
In this algorithm, packets from a newly conflicting source address will be ignored and packets from the original source address will be kept. If no packets arrive from the original source for an extended period, the table entry will be timed out and the new source will be
このアルゴリズムで、新たに闘争しているソースアドレスからのパケットは無視されるでしょう、そして、一次資料アドレスからのパケットは保たれるでしょう。 パケットが全く長期間の間、一次資料から到着しないで、テーブル項目が外で調節されて、新しいソースがあるなら
Schulzrinne, et al. Standards Track [Page 63] RFC 3550 RTP July 2003
Schulzrinne、他 規格はRTP2003年7月にRFC3550を追跡します[63ページ]。
able to take over. This might occur if the original source detects the collision and moves to a new source identifier, but in the usual case an RTCP BYE packet will be received from the original source to delete the state without having to wait for a timeout.
できる、一次資料が衝突を検出して、新しいソース識別子に移行するなら. これを持って行くのは起こるかもしれませんが、普通の場合では、タイムアウトを待つ必要はなくて状態を削除するために一次資料からRTCP BYEパケットを受け取るでしょう。
If the original source address was received through a mixer (i.e., learned as a CSRC) and later the same source is received directly, the receiver may be well advised to switch to the new source address unless other sources in the mix would be lost. Furthermore, for applications such as telephony in which some sources such as mobile entities may change addresses during the course of an RTP session, the RTP implementation SHOULD modify the collision detection algorithm to accept packets from the new source transport address. To guard against flip-flopping between addresses if a genuine collision does occur, the algorithm SHOULD include some means to detect this case and avoid switching.
ミキサー(すなわち、CSRCとして、学習される)を通して一次資料アドレスを受け取って、直接同じ後のソースを受け取って、ミックスにおける他のソースが迷子にならないなら、新しいソースアドレスに切り替わるように上手に受信機にアドバイスするかもしれません。 その上、モバイル実体などの何人かの源がRTPセッションのコースの間にアドレスを変えるかもしれない電話などのアプリケーションのために、RTP実装SHOULDは新しいソース輸送アドレスからパケットを受け入れる衝突検出アルゴリズムを変更します。 本物の衝突が起こるならアドレスの間でコロコロ変わらないように警備するために、アルゴリズムSHOULDは本件を検出して、切り替わるのを避けるいくつかの手段を含んでいます。
When a new SSRC identifier is chosen due to a collision, the candidate identifier SHOULD first be looked up in the source identifier table to see if it was already in use by some other source. If so, another candidate MUST be generated and the process repeated.
新しいSSRC識別子が最初に衝突、候補識別子SHOULDのためそれが既に使用中であったなら見るソース識別子テーブルで調べられた状態である他のソースによって選ばれていると。 そうだとすれば、別の候補を生成しなければなりませんでした、そして、プロセスは繰り返されました。
A loop of data packets to a multicast destination can cause severe network flooding. All mixers and translators MUST implement a loop detection algorithm like the one here so that they can break loops. This should limit the excess traffic to no more than one duplicate copy of the original traffic, which may allow the session to continue so that the cause of the loop can be found and fixed. However, in extreme cases where a mixer or translator does not properly break the loop and high traffic levels result, it may be necessary for end systems to cease transmitting data or control packets entirely. This decision may depend upon the application. An error condition SHOULD be indicated as appropriate. Transmission MAY be attempted again periodically after a long, random time (on the order of minutes).
マルチキャストの目的地へのデータ・パケットの輪は激しいネットワーク氾濫を引き起こす場合があります。 すべてのミキサーと翻訳者は、彼らが輪を壊すことができるように、ここでもののような輪の検出アルゴリズムを実装しなければなりません。 これは余分なトラフィックをオリジナルのトラフィックの1つ未満の写本に制限するべきです。(セッションは、輪の原因を見つけて、修理できるようにそれで、続くかもしれません)。 しかしながら、ミキサーか翻訳者が適切に輪を壊さないで、高いトラフィックレベルが結果として生じる極端な場合では、エンドシステムが、データかコントロールパケットを完全に送るのをやめるのが必要であるかもしれません。 この決定はアプリケーションによるかもしれません。 エラー条件SHOULD、適宜示されてください。 トランスミッションは長くて、無作為の時(数分の注文での)の後に再び定期的に試みられるかもしれません。
8.3 Use with Layered Encodings
8.3 層にされたEncodingsとの使用
For layered encodings transmitted on separate RTP sessions (see Section 2.4), a single SSRC identifier space SHOULD be used across the sessions of all layers and the core (base) layer SHOULD be used for SSRC identifier allocation and collision resolution. When a source discovers that it has collided, it transmits an RTCP BYE packet on only the base layer but changes the SSRC identifier to the new value in all layers.
すべてのSHOULDの層とコア(ベース)層のセッションの向こう側に使用されてください。別々のRTPセッション(セクション2.4を見る)のときに伝えられた、層にされたencodings、ただ一つのSSRC識別子スペースSHOULD、SSRC識別子配分と衝突解決のために、使用されます。 情報筋が、それが衝突したと発見するとき、それは、基層だけでRTCP BYEパケットを伝えますが、すべての層でSSRC識別子を新しい値に変えます。
Schulzrinne, et al. Standards Track [Page 64] RFC 3550 RTP July 2003
Schulzrinne、他 規格はRTP2003年7月にRFC3550を追跡します[64ページ]。
9. Security
9. セキュリティ
Lower layer protocols may eventually provide all the security services that may be desired for applications of RTP, including authentication, integrity, and confidentiality. These services have been specified for IP in [27]. Since the initial audio and video applications using RTP needed a confidentiality service before such services were available for the IP layer, the confidentiality service described in the next section was defined for use with RTP and RTCP. That description is included here to codify existing practice. New applications of RTP MAY implement this RTP-specific confidentiality service for backward compatibility, and/or they MAY implement alternative security services. The overhead on the RTP protocol for this confidentiality service is low, so the penalty will be minimal if this service is obsoleted by other services in the future.
下位層プロトコルは結局RTPのアプリケーションのために望まれるかもしれないすべてのセキュリティー・サービスを提供するかもしれません、認証、保全、および秘密性を含んでいて。 これらのサービスは[27]のIPに指定されました。 そのようなサービスが利用可能にIP層になる前にRTPを使用する初期のオーディオとビデオ・アプリケーションが秘密性サービスを必要としたので、次のセクションで説明された秘密性サービスはRTPとRTCPとの使用のために定義されました。 その記述は、既存の習慣を成文化するためにここに含まれています。 RTP MAYの新しいアプリケーションは、このRTP特有の秘密性が後方の互換性のためのサービスであると実装します、そして、それらは代替のセキュリティがサービスであると実装するかもしれません。 この秘密性サービスのためのRTPプロトコルのオーバーヘッドが低いので、このサービスが将来他のサービスで時代遅れにされるなら、刑罰は最小量になるでしょう。
Alternatively, other services, other implementations of services and other algorithms may be defined for RTP in the future. In particular, an RTP profile called Secure Real-time Transport Protocol (SRTP) [28] is being developed to provide confidentiality of the RTP payload while leaving the RTP header in the clear so that link-level header compression algorithms can still operate. It is expected that SRTP will be the correct choice for many applications. SRTP is based on the Advanced Encryption Standard (AES) and provides stronger security than the service described here. No claim is made that the methods presented here are appropriate for a particular security need. A profile may specify which services and algorithms should be offered by applications, and may provide guidance as to their appropriate use.
あるいはまた、他のサービスであり、サービスと他のアルゴリズムの他の実装は将来、RTPのために定義されるかもしれません。 特に、Secureレアル-時間Transportプロトコル(SRTP)[28]と呼ばれるRTPプロフィールは、リンク・レベルヘッダー圧縮アルゴリズムがまだ作動できるように明確にRTPヘッダーを置き去りにしている間、RTPペイロードの秘密性を提供するために開発されています。 SRTPが多くのアプリケーションのための正しい選択であると予想されます。 SRTPはエー・イー・エス(AES)に基づいていて、ここで説明されたサービスより強いセキュリティを提供します。 特別のセキュリティの必要性に、ここに提示されたメソッドが適切であるというクレームを全くしません。 プロフィールは、どのサービスとアルゴリズムがアプリケーションで提供されるべきであり、彼らの適切な使用に関して指導を提供するかもしれないかを指定するかもしれません。
Key distribution and certificates are outside the scope of this document.
このドキュメントの範囲の外に主要な分配と証明書があります。
9.1 Confidentiality
9.1 秘密性
Confidentiality means that only the intended receiver(s) can decode the received packets; for others, the packet contains no useful information. Confidentiality of the content is achieved by encryption.
秘密性は、所定の受信者だけが容認されたパケットを解読できることを意味します。 他のもののために、パケットは役に立つ情報を全く含んでいません。 内容の秘密性は暗号化で達成されます。
When it is desired to encrypt RTP or RTCP according to the method specified in this section, all the octets that will be encapsulated for transmission in a single lower-layer packet are encrypted as a unit. For RTCP, a 32-bit random number redrawn for each unit MUST be prepended to the unit before encryption. For RTP, no prefix is prepended; instead, the sequence number and timestamp fields are initialized with random offsets. This is considered to be a weak
このセクションで指定されたメソッドによると、RTPかRTCPを暗号化するのが必要であるときに、単一の下層パケットのトランスミッションのためにカプセル化されるすべての八重奏が一体にして暗号化されます。 RTCPに関しては、暗号化の前に各ユニット32ビットの乱数redrawnをユニットにprependedしなければなりません。 RTPに関しては、接頭語は全くprependedされません。 代わりに、一連番号とタイムスタンプ分野は無作為のオフセットで初期化されます。 これはa弱者であると考えられます。
Schulzrinne, et al. Standards Track [Page 65] RFC 3550 RTP July 2003
Schulzrinne、他 規格はRTP2003年7月にRFC3550を追跡します[65ページ]。
initialization vector (IV) because of poor randomness properties. In addition, if the subsequent field, the SSRC, can be manipulated by an enemy, there is further weakness of the encryption method.
貧しい偶発性の特性による初期化ベクトル(IV)。 さらに、敵がその後の分野(SSRC)を操ることができるなら、暗号化メソッドのさらなる弱点があります。
For RTCP, an implementation MAY segregate the individual RTCP packets in a compound RTCP packet into two separate compound RTCP packets, one to be encrypted and one to be sent in the clear. For example, SDES information might be encrypted while reception reports were sent in the clear to accommodate third-party monitors that are not privy to the encryption key. In this example, depicted in Fig. 4, the SDES information MUST be appended to an RR packet with no reports (and the random number) to satisfy the requirement that all compound RTCP packets begin with an SR or RR packet. The SDES CNAME item is required in either the encrypted or unencrypted packet, but not both. The same SDES information SHOULD NOT be carried in both packets as this may compromise the encryption.
RTCPに関しては、実装は合成RTCPパケットで2つの別々の合成RTCPパケット、暗号化されるべき1、および明確で送られる1つに個々のRTCPパケットを隔離するかもしれません。 例えば、暗号化キーに関与していない第三者モニターを収容するために明確でレセプションレポートを送った間、SDES情報を暗号化するかもしれません。 図4に表現されたこの例では、すべての合成RTCPパケットがSRかRRパケットと共に始まるという要件を満たすためにレポート(そして、乱数)なしでSDES情報をRRパケットに追加しなければなりません。 SDES CNAMEの品目が、暗号化されたか非暗号化されたパケットで必要ですが、ともに必要であるというわけではありません。 同じSDES情報SHOULD NOT、これが暗号化に感染するかもしれないので、両方のパケットで運ばれてください。
UDP packet UDP packet
----------------------------- ------------------------------
[random][RR][SDES #CNAME ...] [SR #senderinfo #site1 #site2]
----------------------------- ------------------------------
encrypted not encrypted
UDPパケットUDPパケット----------------------------- ------------------------------ [無作為の] [RR] [SDES#CNAME] [SR#senderinfo#site1#site2]----------------------------- ------------------------------ 暗号化されていなく、暗号化されます。
#: SSRC identifier
#: SSRC識別子
Figure 4: Encrypted and non-encrypted RTCP packets
図4: 暗号化されて非暗号化されたRTCPパケット
The presence of encryption and the use of the correct key are confirmed by the receiver through header or payload validity checks. Examples of such validity checks for RTP and RTCP headers are given in Appendices A.1 and A.2.
暗号化の存在と正しいキーの使用は受信機によってヘッダーかペイロードバリディティチェックで確認されます。 RTPとRTCPヘッダーのためのそのようなバリディティチェックに関する例はAppendices A.1とA.2で出されます。
To be consistent with existing implementations of the initial specification of RTP in RFC 1889, the default encryption algorithm is the Data Encryption Standard (DES) algorithm in cipher block chaining (CBC) mode, as described in Section 1.1 of RFC 1423 [29], except that padding to a multiple of 8 octets is indicated as described for the P bit in Section 5.1. The initialization vector is zero because random values are supplied in the RTP header or by the random prefix for compound RTCP packets. For details on the use of CBC initialization vectors, see [30].
暗号ブロック連鎖(CBC)モードでデフォルト暗号化アルゴリズムはRFC1889でRTPの初期の仕様の既存の実装と一致しているためには、データ暗号化規格(DES)アルゴリズムです、RFC1423[29]のセクション1.1で説明されるように、8つの八重奏の倍数にそっと歩くのがセクション5.1におけるPビットのために説明されるように示されるのを除いて。 RTPヘッダーか無作為の接頭語から無作為の値を供給するので、初期化ベクトルは合成RTCPパケットのためのゼロです。 CBC初期化ベクトルの使用に関する詳細に関しては、[30]を見てください。
Implementations that support the encryption method specified here SHOULD always support the DES algorithm in CBC mode as the default cipher for this method to maximize interoperability. This method was chosen because it has been demonstrated to be easy and practical to use in experimental audio and video tools in operation on the Internet. However, DES has since been found to be too easily broken.
デフォルトとしてここでのメソッドが指定したSHOULDがいつもサポートする暗号化にCBCモードによるDESアルゴリズムをサポートする実装は相互運用性を最大にするこのメソッドのために解かれます。 それがインターネットで実験用オーディオとビデオツールに稼働中であり使用するために簡単であって、実用的になるように示されたので、このメソッドは選ばれました。 しかしながら、DESは以来、あまりに容易に壊されるのがわかっています。
Schulzrinne, et al. Standards Track [Page 66] RFC 3550 RTP July 2003
Schulzrinne、他 規格はRTP2003年7月にRFC3550を追跡します[66ページ]。
It is RECOMMENDED that stronger encryption algorithms such as Triple-DES be used in place of the default algorithm. Furthermore, secure CBC mode requires that the first block of each packet be XORed with a random, independent IV of the same size as the cipher's block size. For RTCP, this is (partially) achieved by prepending each packet with a 32-bit random number, independently chosen for each packet. For RTP, the timestamp and sequence number start from random values, but consecutive packets will not be independently randomized. It should be noted that the randomness in both cases (RTP and RTCP) is limited. High-security applications SHOULD consider other, more conventional, protection means. Other encryption algorithms MAY be specified dynamically for a session by non-RTP means. In particular, the SRTP profile [28] based on AES is being developed to take into account known plaintext and CBC plaintext manipulation concerns, and will be the correct choice in the future.
Triple-DESなどの、より強い暗号化アルゴリズムがデフォルトアルゴリズムに代わって使用されるのは、RECOMMENDEDです。 その上、安全なCBCモードは、それぞれのパケットの最初のブロックが暗号のブロック・サイズと同じIV無作為の、そして、独立しているサイズがあるXORedであることを必要とします。 RTCPにおいて、これは、32ビットの乱数で各パケットをprependingすることによって(部分的に)達成されていて、各パケットに独自に選ばれています。 RTPに関しては、タイムスタンプと一連番号は無作為の値から始めますが、連続したパケットは独自にランダマイズされないでしょう。 両方の場合(RTPとRTCP)における偶発性が限られていることに注意されるべきです。 高セキュリティアプリケーションSHOULDは他の、そして、より従来の保護手段を考えます。 他の暗号化アルゴリズムはセッションとして非RTP手段でダイナミックに指定されるかもしれません。 AESに基づくSRTPプロフィール[28]は、知られている平文とCBC平文操作関心を考慮に入れるために開発されていて、将来、特に、正しい選択になるでしょう。
As an alternative to encryption at the IP level or at the RTP level as described above, profiles MAY define additional payload types for encrypted encodings. Those encodings MUST specify how padding and other aspects of the encryption are to be handled. This method allows encrypting only the data while leaving the headers in the clear for applications where that is desired. It may be particularly useful for hardware devices that will handle both decryption and decoding. It is also valuable for applications where link-level compression of RTP and lower-layer headers is desired and confidentiality of the payload (but not addresses) is sufficient since encryption of the headers precludes compression.
IPレベルにおける、または、上で説明されるRTPレベルにおける暗号化に代わる手段として、プロフィールは暗号化されたencodingsのための追加ペイロードタイプを定義するかもしれません。 それらのencodingsは扱われる暗号化の詰め物と他の局面がことである方法を指定しなければなりません。 このメソッドで、それが望まれているアプリケーションのための明確にヘッダーを置き去りにしている間、データだけを暗号化します。 それは特に復号化と解読の両方を扱うハードウェアデバイスの役に立つかもしれません。 また、RTPと下層ヘッダーのリンク・レベル圧縮が望まれていて、ヘッダーの暗号化が圧縮を排除するのでペイロード(しかし、アドレスでない)の秘密性が十分であるアプリケーションに、それも貴重です。
9.2 Authentication and Message Integrity
9.2 認証とメッセージの保全
Authentication and message integrity services are not defined at the RTP level since these services would not be directly feasible without a key management infrastructure. It is expected that authentication and integrity services will be provided by lower layer protocols.
これらのサービスはかぎ管理インフラストラクチャなしで直接可能でないでしょう、したがって、認証とメッセージの保全サービスはRTPレベルで定義されません。 認証と保全サービスが下位層プロトコルによって提供されると予想されます。
10. Congestion Control
10. 輻輳制御
All transport protocols used on the Internet need to address congestion control in some way [31]. RTP is not an exception, but because the data transported over RTP is often inelastic (generated at a fixed or controlled rate), the means to control congestion in RTP may be quite different from those for other transport protocols such as TCP. In one sense, inelasticity reduces the risk of congestion because the RTP stream will not expand to consume all available bandwidth as a TCP stream can. However, inelasticity also means that the RTP stream cannot arbitrarily reduce its load on the network to eliminate congestion when it occurs.
インターネットで使用されるすべてのトランスポート・プロトコルが、混雑がコントロールであると何らかの方法[31]で扱う必要があります。 RTPは例外ではありませんが、RTPの上で輸送されたデータがしばしば弾力性がないので(修理されたか制御されたレートで、生成されます)、TCPなどの他のトランスポート・プロトコルにおいて、RTPで混雑を制御する手段はそれらと全く異なっているかもしれません。 ある意味で、RTPストリームがすべての利用可能な帯域幅を消費するためにTCPストリームが広がることができるように広がらないので、不順応性は混雑の危険を減少させます。 しかしながら、また、不順応性は、起こる場合RTPストリームが混雑を排除するためにネットワークで負荷を任意に減少させることができないことを意味します。
Schulzrinne, et al. Standards Track [Page 67] RFC 3550 RTP July 2003
Schulzrinne、他 規格はRTP2003年7月にRFC3550を追跡します[67ページ]。
Since RTP may be used for a wide variety of applications in many different contexts, there is no single congestion control mechanism that will work for all. Therefore, congestion control SHOULD be defined in each RTP profile as appropriate. For some profiles, it may be sufficient to include an applicability statement restricting the use of that profile to environments where congestion is avoided by engineering. For other profiles, specific methods such as data rate adaptation based on RTCP feedback may be required.
RTPが多くの異なった文脈におけるさまざまなアプリケーションに使用されるかもしれないので、すべてのために動作するどんなただ一つの混雑制御機構もありません。 したがって、各RTPが輪郭を描く定義されたコネが適切であったので、混雑はSHOULDを制御します。 いくつかのプロフィールでは、そのプロフィールの使用を混雑が工学によって避けられる環境に制限する適用性証明を含んでいるのは十分であるかもしれません。 他のプロフィールに関しては、RTCPフィードバックに基づくデータ信号速度適合などの特定のメソッドが必要であるかもしれません。
11. RTP over Network and Transport Protocols
11. ネットワークとトランスポート・プロトコルの上のRTP
This section describes issues specific to carrying RTP packets within particular network and transport protocols. The following rules apply unless superseded by protocol-specific definitions outside this specification.
このセクションは特定のネットワークの中でRTPパケットを運ぶのに特定の問題とトランスポート・プロトコルについて説明します。 この仕様の外でプロトコル特有の定義で取って代わられない場合、以下の規則は適用されます。
RTP relies on the underlying protocol(s) to provide demultiplexing of RTP data and RTCP control streams. For UDP and similar protocols, RTP SHOULD use an even destination port number and the corresponding RTCP stream SHOULD use the next higher (odd) destination port number. For applications that take a single port number as a parameter and derive the RTP and RTCP port pair from that number, if an odd number is supplied then the application SHOULD replace that number with the next lower (even) number to use as the base of the port pair. For applications in which the RTP and RTCP destination port numbers are specified via explicit, separate parameters (using a signaling protocol or other means), the application MAY disregard the restrictions that the port numbers be even/odd and consecutive although the use of an even/odd port pair is still encouraged. The RTP and RTCP port numbers MUST NOT be the same since RTP relies on the port numbers to demultiplex the RTP data and RTCP control streams.
RTPは、RTPデータとRTCP制御ストリームの逆多重化を提供するために基本的なプロトコルを当てにします。UDPと同様のプロトコルのために、RTP SHOULDは次の、より高い(変な)目的地ポートナンバーに偶数の仕向港番号と対応するRTCPストリームSHOULD使用を使用します。 パラメタとしてただ一つのポートナンバーをみなして、RTPとRTCPポート組にその数に由来しているアプリケーションのために、奇数を供給するなら、アプリケーションSHOULDはその数をポート組のベースとして使用する次の下側)さえの数に取り替えます。 明白で、別々のパラメタ(シグナリングプロトコルか他の手段を使用する)でRTPとRTCP目的地ポートナンバーが指定されるアプリケーションのために、アプリケーションはポートナンバーが/変でさえあって同等の、または、変なポート組の使用がまだ奨励されていますが、連続しているという制限を無視するかもしれません。 RTPとRTCPポートナンバーはRTPがポートナンバーをRTPデータとRTCPが制御する「反-マルチプレックス」を当てにするので同じくらいが流れるということであるはずがありません。
In a unicast session, both participants need to identify a port pair for receiving RTP and RTCP packets. Both participants MAY use the same port pair. A participant MUST NOT assume that the source port of the incoming RTP or RTCP packet can be used as the destination port for outgoing RTP or RTCP packets. When RTP data packets are being sent in both directions, each participant's RTCP SR packets MUST be sent to the port that the other participant has specified for reception of RTCP. The RTCP SR packets combine sender information for the outgoing data plus reception report information for the incoming data. If a side is not actively sending data (see Section 6.4), an RTCP RR packet is sent instead.
ユニキャストセッションのときに、両方の関係者は、RTPとRTCPパケットを受けるためにポート組を特定する必要があります。 両方の関係者は同じポート組を使用するかもしれません。 関係者は、出発しているRTPかRTCPパケットに仕向港として入って来るRTPかRTCPパケットのソースポートを使用できると仮定してはいけません。 RTPデータ・パケットを両方の方向に送るとき、もう片方の関係者がRTCPのレセプションに指定したポートに各関係者のRTCP SRパケットを送らなければなりません。 RTCP SRパケットは発信データのための送付者情報と受信データのためのレセプションレポート情報を結合します。 側が活発にデータを送らないなら(セクション6.4を見てください)、代わりにRTCP RRパケットを送ります。
It is RECOMMENDED that layered encoding applications (see Section 2.4) use a set of contiguous port numbers. The port numbers MUST be distinct because of a widespread deficiency in existing operating
層にされたコード化アプリケーション(セクション2.4を見る)が1セットの隣接のポートナンバーを使用するのは、RECOMMENDEDです。 ポートナンバーは既存の作動における広範囲の欠乏で異なっているに違いありません。
Schulzrinne, et al. Standards Track [Page 68] RFC 3550 RTP July 2003
Schulzrinne、他 規格はRTP2003年7月にRFC3550を追跡します[68ページ]。
systems that prevents use of the same port with multiple multicast addresses, and for unicast, there is only one permissible address. Thus for layer n, the data port is P + 2n, and the control port is P + 2n + 1. When IP multicast is used, the addresses MUST also be distinct because multicast routing and group membership are managed on an address granularity. However, allocation of contiguous IP multicast addresses cannot be assumed because some groups may require different scopes and may therefore be allocated from different address ranges.
同じポートの複数のマルチキャストアドレス、およびユニキャストの使用を防ぐシステム、1つの許されているアドレスしかありません。 したがって、データポートは層nのための、P+2nです、そして、制御ポートはP+2n+1です。 IPマルチキャストが使用されているとき、また、マルチキャストルーティングとグループ会員資格がアドレス粒状で管理されるので、アドレスも異なっているに違いありません。 しかしながら、隣接のIPマルチキャストアドレスの配分をいくつかのグループが異なった範囲を必要とするかもしれないので想定できないで、したがって、異なったアドレスの範囲から割り当てるかもしれません。
The previous paragraph conflicts with the SDP specification, RFC 2327 [15], which says that it is illegal for both multiple addresses and multiple ports to be specified in the same session description because the association of addresses with ports could be ambiguous. It is intended that this restriction will be relaxed in a revision of RFC 2327 to allow an equal number of addresses and ports to be specified with a one-to-one mapping implied.
前のパラグラフはSDP仕様、ポートがあるアドレスの協会があいまいであるかもしれないので複数のアドレスと複数のポートの両方が同じセッション記述で指定されるのが、不法であると言うRFC2327[15]と衝突します。 この規制が1〜1つのマッピングが含意されている状態で等しい数のアドレスとポートが指定されるのを許容するためにRFC2327の改正で緩和されることを意図します。
RTP data packets contain no length field or other delineation, therefore RTP relies on the underlying protocol(s) to provide a length indication. The maximum length of RTP packets is limited only by the underlying protocols.
RTPデータ・パケットはどんな長さの分野も他の輪郭描写も含んでいません、したがって、RTPが長さの指示を提供するために基本的なプロトコルを当てにします。 最大の長さのRTPパケットは基本的なプロトコルだけによって制限されます。
If RTP packets are to be carried in an underlying protocol that provides the abstraction of a continuous octet stream rather than messages (packets), an encapsulation of the RTP packets MUST be defined to provide a framing mechanism. Framing is also needed if the underlying protocol may contain padding so that the extent of the RTP payload cannot be determined. The framing mechanism is not defined here.
RTPパケットがメッセージ(パケット)よりむしろ連続した八重奏ストリームの抽象化を提供する基本的なプロトコルで運ばれるつもりであるなら、縁どりメカニズムを提供するためにRTPパケットのカプセル化を定義しなければなりません。 また、基本的なプロトコルがRTPペイロードの範囲を測定できないように詰め物を含むかもしれないなら、縁どりが必要です。 縁どりメカニズムはここで定義されません。
A profile MAY specify a framing method to be used even when RTP is carried in protocols that do provide framing in order to allow carrying several RTP packets in one lower-layer protocol data unit, such as a UDP packet. Carrying several RTP packets in one network or transport packet reduces header overhead and may simplify synchronization between different streams.
プロフィールはRTPが1つの下位層プロトコルデータ単位でいくつかのRTPパケットを運ぶのを許容するために縁どりを提供するプロトコルで運ばれるときさえ使用されるべき縁どりメソッドを指定するかもしれません、UDPパケットのように。 1つのネットワークか輸送パケットでいくつかのRTPパケットを運ぶと、ヘッダーオーバーヘッドが下げられて、異なったストリームの間の同期は簡素化されるかもしれません。
12. Summary of Protocol Constants
12. プロトコル定数の概要
This section contains a summary listing of the constants defined in this specification.
このセクションはこの仕様に基づき定義された定数の概要リストを含みます。
The RTP payload type (PT) constants are defined in profiles rather than this document. However, the octet of the RTP header which contains the marker bit(s) and payload type MUST avoid the reserved values 200 and 201 (decimal) to distinguish RTP packets from the RTCP SR and RR packet types for the header validation procedure described
RTPペイロードタイプ(太平洋標準時の)定数はこのドキュメントよりむしろプロフィールで定義されます。 しかしながら、マーカービットとペイロードタイプを含むRTPヘッダーの八重奏は、ヘッダー合法化手順のためのタイプが説明したRTCP SRとRRパケットとRTPパケットを区別するために、予約された値200と201(10進)を避けなければなりません。
Schulzrinne, et al. Standards Track [Page 69] RFC 3550 RTP July 2003
Schulzrinne、他 規格はRTP2003年7月にRFC3550を追跡します[69ページ]。
in Appendix A.1. For the standard definition of one marker bit and a 7-bit payload type field as shown in this specification, this restriction means that payload types 72 and 73 are reserved.
付録A.1で。 1マーカービットの標準定義とこの仕様に示される7ビットのペイロードタイプ分野に、この制限は、ペイロードタイプ72と73が控え目であることを意味します。
12.1 RTCP Packet Types
12.1 RTCPパケットタイプ
abbrev. name value SR sender report 200 RR receiver report 201 SDES source description 202 BYE goodbye 203 APP application-defined 204
abbrev名前値のSR送付者レポート200RR受信機レポート201SDESソース記述202BYEさよなら203APPは204をアプリケーションで定義しました。
These type values were chosen in the range 200-204 for improved header validity checking of RTCP packets compared to RTP packets or other unrelated packets. When the RTCP packet type field is compared to the corresponding octet of the RTP header, this range corresponds to the marker bit being 1 (which it usually is not in data packets) and to the high bit of the standard payload type field being 1 (since the static payload types are typically defined in the low half). This range was also chosen to be some distance numerically from 0 and 255 since all-zeros and all-ones are common data patterns.
RTPパケットか他の関係ないパケットと比べて、これらのタイプ値はRTCPパケットの改良されたヘッダー正当性の照合のための範囲200-204で選ばれました。 RTCPパケットタイプ分野がRTPヘッダーの対応する八重奏と比べるとき、この範囲は1(通常、それがデータ・パケットのそうでない)であるマーカービットと、そして、1である標準のペイロードタイプ分野の高いビットに対応しています(静的なペイロードタイプが低い半分で通常定義されるので)。 また、この範囲は、オールゼロとオール1つが一般的なデータパターンであるので、0と255からの数の上で何らかの距離になるように選ばれました。
Since all compound RTCP packets MUST begin with SR or RR, these codes were chosen as an even/odd pair to allow the RTCP validity check to test the maximum number of bits with mask and value.
すべての合成RTCPパケットが始まらなければならないので、RTCPバリディティチェックを許容する同等の、または、変な組がマスクと値に従ったビットの最大数をテストするとき、SRかRRと共に、これらのコードは選ばれました。
Additional RTCP packet types may be registered through IANA (see Section 15).
追加RTCPパケットタイプはIANAを通して示されるかもしれません(セクション15を見てください)。
12.2 SDES Types
12.2SDESがタイプします。
abbrev. name value END end of SDES list 0 CNAME canonical name 1 NAME user name 2 EMAIL user's electronic mail address 3 PHONE user's phone number 4 LOC geographic user location 5 TOOL name of application or tool 6 NOTE notice about the source 7 PRIV private extensions 8
abbrev. name value END end of SDES list 0 CNAME canonical name 1 NAME user name 2 EMAIL user's electronic mail address 3 PHONE user's phone number 4 LOC geographic user location 5 TOOL name of application or tool 6 NOTE notice about the source 7 PRIV private extensions 8
Additional SDES types may be registered through IANA (see Section 15).
Additional SDES types may be registered through IANA (see Section 15).
Schulzrinne, et al. Standards Track [Page 70] RFC 3550 RTP July 2003
Schulzrinne, et al. Standards Track [Page 70] RFC 3550 RTP July 2003
13. RTP Profiles and Payload Format Specifications
13. RTP Profiles and Payload Format Specifications
A complete specification of RTP for a particular application will require one or more companion documents of two types described here: profiles, and payload format specifications.
A complete specification of RTP for a particular application will require one or more companion documents of two types described here: profiles, and payload format specifications.
RTP may be used for a variety of applications with somewhat differing requirements. The flexibility to adapt to those requirements is provided by allowing multiple choices in the main protocol specification, then selecting the appropriate choices or defining extensions for a particular environment and class of applications in a separate profile document. Typically an application will operate under only one profile in a particular RTP session, so there is no explicit indication within the RTP protocol itself as to which profile is in use. A profile for audio and video applications may be found in the companion RFC 3551. Profiles are typically titled "RTP Profile for ...".
RTP may be used for a variety of applications with somewhat differing requirements. The flexibility to adapt to those requirements is provided by allowing multiple choices in the main protocol specification, then selecting the appropriate choices or defining extensions for a particular environment and class of applications in a separate profile document. Typically an application will operate under only one profile in a particular RTP session, so there is no explicit indication within the RTP protocol itself as to which profile is in use. A profile for audio and video applications may be found in the companion RFC 3551. Profiles are typically titled "RTP Profile for ...".
The second type of companion document is a payload format specification, which defines how a particular kind of payload data, such as H.261 encoded video, should be carried in RTP. These documents are typically titled "RTP Payload Format for XYZ Audio/Video Encoding". Payload formats may be useful under multiple profiles and may therefore be defined independently of any particular profile. The profile documents are then responsible for assigning a default mapping of that format to a payload type value if needed.
The second type of companion document is a payload format specification, which defines how a particular kind of payload data, such as H.261 encoded video, should be carried in RTP. These documents are typically titled "RTP Payload Format for XYZ Audio/Video Encoding". Payload formats may be useful under multiple profiles and may therefore be defined independently of any particular profile. The profile documents are then responsible for assigning a default mapping of that format to a payload type value if needed.
Within this specification, the following items have been identified for possible definition within a profile, but this list is not meant to be exhaustive:
Within this specification, the following items have been identified for possible definition within a profile, but this list is not meant to be exhaustive:
RTP data header: The octet in the RTP data header that contains
the marker bit and payload type field MAY be redefined by a
profile to suit different requirements, for example with more or
fewer marker bits (Section 5.3, p. 18).
RTP data header: The octet in the RTP data header that contains the marker bit and payload type field MAY be redefined by a profile to suit different requirements, for example with more or fewer marker bits (Section 5.3, p. 18).
Payload types: Assuming that a payload type field is included,
the profile will usually define a set of payload formats (e.g.,
media encodings) and a default static mapping of those formats to
payload type values. Some of the payload formats may be defined
by reference to separate payload format specifications. For each
payload type defined, the profile MUST specify the RTP timestamp
clock rate to be used (Section 5.1, p. 14).
Payload types: Assuming that a payload type field is included, the profile will usually define a set of payload formats (e.g., media encodings) and a default static mapping of those formats to payload type values. Some of the payload formats may be defined by reference to separate payload format specifications. For each payload type defined, the profile MUST specify the RTP timestamp clock rate to be used (Section 5.1, p. 14).
RTP data header additions: Additional fields MAY be appended to
the fixed RTP data header if some additional functionality is
required across the profile's class of applications independent of
payload type (Section 5.3, p. 18).
RTP data header additions: Additional fields MAY be appended to the fixed RTP data header if some additional functionality is required across the profile's class of applications independent of payload type (Section 5.3, p. 18).
Schulzrinne, et al. Standards Track [Page 71] RFC 3550 RTP July 2003
Schulzrinne, et al. Standards Track [Page 71] RFC 3550 RTP July 2003
RTP data header extensions: The contents of the first 16 bits of
the RTP data header extension structure MUST be defined if use of
that mechanism is to be allowed under the profile for
implementation-specific extensions (Section 5.3.1, p. 18).
RTP data header extensions: The contents of the first 16 bits of the RTP data header extension structure MUST be defined if use of that mechanism is to be allowed under the profile for implementation-specific extensions (Section 5.3.1, p. 18).
RTCP packet types: New application-class-specific RTCP packet
types MAY be defined and registered with IANA.
RTCP packet types: New application-class-specific RTCP packet types MAY be defined and registered with IANA.
RTCP report interval: A profile SHOULD specify that the values
suggested in Section 6.2 for the constants employed in the
calculation of the RTCP report interval will be used. Those are
the RTCP fraction of session bandwidth, the minimum report
interval, and the bandwidth split between senders and receivers.
A profile MAY specify alternate values if they have been
demonstrated to work in a scalable manner.
RTCP report interval: A profile SHOULD specify that the values suggested in Section 6.2 for the constants employed in the calculation of the RTCP report interval will be used. Those are the RTCP fraction of session bandwidth, the minimum report interval, and the bandwidth split between senders and receivers. A profile MAY specify alternate values if they have been demonstrated to work in a scalable manner.
SR/RR extension: An extension section MAY be defined for the
RTCP SR and RR packets if there is additional information that
should be reported regularly about the sender or receivers
(Section 6.4.3, p. 42 and 43).
SR/RR extension: An extension section MAY be defined for the RTCP SR and RR packets if there is additional information that should be reported regularly about the sender or receivers (Section 6.4.3, p. 42 and 43).
SDES use: The profile MAY specify the relative priorities for
RTCP SDES items to be transmitted or excluded entirely (Section
6.3.9); an alternate syntax or semantics for the CNAME item
(Section 6.5.1); the format of the LOC item (Section 6.5.5); the
semantics and use of the NOTE item (Section 6.5.7); or new SDES
item types to be registered with IANA.
SDES use: The profile MAY specify the relative priorities for RTCP SDES items to be transmitted or excluded entirely (Section 6.3.9); an alternate syntax or semantics for the CNAME item (Section 6.5.1); the format of the LOC item (Section 6.5.5); the semantics and use of the NOTE item (Section 6.5.7); or new SDES item types to be registered with IANA.
Security: A profile MAY specify which security services and
algorithms should be offered by applications, and MAY provide
guidance as to their appropriate use (Section 9, p. 65).
Security: A profile MAY specify which security services and algorithms should be offered by applications, and MAY provide guidance as to their appropriate use (Section 9, p. 65).
String-to-key mapping: A profile MAY specify how a user-provided
password or pass phrase is mapped into an encryption key.
String-to-key mapping: A profile MAY specify how a user-provided password or pass phrase is mapped into an encryption key.
Congestion: A profile SHOULD specify the congestion control
behavior appropriate for that profile.
Congestion: A profile SHOULD specify the congestion control behavior appropriate for that profile.
Underlying protocol: Use of a particular underlying network or
transport layer protocol to carry RTP packets MAY be required.
Underlying protocol: Use of a particular underlying network or transport layer protocol to carry RTP packets MAY be required.
Transport mapping: A mapping of RTP and RTCP to transport-level
addresses, e.g., UDP ports, other than the standard mapping
defined in Section 11, p. 68 may be specified.
Transport mapping: A mapping of RTP and RTCP to transport-level addresses, e.g., UDP ports, other than the standard mapping defined in Section 11, p. 68 may be specified.
Schulzrinne, et al. Standards Track [Page 72] RFC 3550 RTP July 2003
Schulzrinne, et al. Standards Track [Page 72] RFC 3550 RTP July 2003
Encapsulation: An encapsulation of RTP packets may be defined to
allow multiple RTP data packets to be carried in one lower-layer
packet or to provide framing over underlying protocols that do not
already do so (Section 11, p. 69).
Encapsulation: An encapsulation of RTP packets may be defined to allow multiple RTP data packets to be carried in one lower-layer packet or to provide framing over underlying protocols that do not already do so (Section 11, p. 69).
It is not expected that a new profile will be required for every application. Within one application class, it would be better to extend an existing profile rather than make a new one in order to facilitate interoperation among the applications since each will typically run under only one profile. Simple extensions such as the definition of additional payload type values or RTCP packet types may be accomplished by registering them through IANA and publishing their descriptions in an addendum to the profile or in a payload format specification.
It is not expected that a new profile will be required for every application. Within one application class, it would be better to extend an existing profile rather than make a new one in order to facilitate interoperation among the applications since each will typically run under only one profile. Simple extensions such as the definition of additional payload type values or RTCP packet types may be accomplished by registering them through IANA and publishing their descriptions in an addendum to the profile or in a payload format specification.
14. Security Considerations
14. Security Considerations
RTP suffers from the same security liabilities as the underlying protocols. For example, an impostor can fake source or destination network addresses, or change the header or payload. Within RTCP, the CNAME and NAME information may be used to impersonate another participant. In addition, RTP may be sent via IP multicast, which provides no direct means for a sender to know all the receivers of the data sent and therefore no measure of privacy. Rightly or not, users may be more sensitive to privacy concerns with audio and video communication than they have been with more traditional forms of network communication [33]. Therefore, the use of security mechanisms with RTP is important. These mechanisms are discussed in Section 9.
RTP suffers from the same security liabilities as the underlying protocols. For example, an impostor can fake source or destination network addresses, or change the header or payload. Within RTCP, the CNAME and NAME information may be used to impersonate another participant. In addition, RTP may be sent via IP multicast, which provides no direct means for a sender to know all the receivers of the data sent and therefore no measure of privacy. Rightly or not, users may be more sensitive to privacy concerns with audio and video communication than they have been with more traditional forms of network communication [33]. Therefore, the use of security mechanisms with RTP is important. These mechanisms are discussed in Section 9.
RTP-level translators or mixers may be used to allow RTP traffic to reach hosts behind firewalls. Appropriate firewall security principles and practices, which are beyond the scope of this document, should be followed in the design and installation of these devices and in the admission of RTP applications for use behind the firewall.
RTP-level translators or mixers may be used to allow RTP traffic to reach hosts behind firewalls. Appropriate firewall security principles and practices, which are beyond the scope of this document, should be followed in the design and installation of these devices and in the admission of RTP applications for use behind the firewall.
15. IANA Considerations
15. IANA Considerations
Additional RTCP packet types and SDES item types may be registered through the Internet Assigned Numbers Authority (IANA). Since these number spaces are small, allowing unconstrained registration of new values would not be prudent. To facilitate review of requests and to promote shared use of new types among multiple applications, requests for registration of new values must be documented in an RFC or other permanent and readily available reference such as the product of another cooperative standards body (e.g., ITU-T). Other requests may also be accepted, under the advice of a "designated expert."
Additional RTCP packet types and SDES item types may be registered through the Internet Assigned Numbers Authority (IANA). Since these number spaces are small, allowing unconstrained registration of new values would not be prudent. To facilitate review of requests and to promote shared use of new types among multiple applications, requests for registration of new values must be documented in an RFC or other permanent and readily available reference such as the product of another cooperative standards body (e.g., ITU-T). Other requests may also be accepted, under the advice of a "designated expert."
Schulzrinne, et al. Standards Track [Page 73] RFC 3550 RTP July 2003
Schulzrinne, et al. Standards Track [Page 73] RFC 3550 RTP July 2003
(Contact the IANA for the contact information of the current expert.)
(Contact the IANA for the contact information of the current expert.)
RTP profile specifications SHOULD register with IANA a name for the profile in the form "RTP/xxx", where xxx is a short abbreviation of the profile title. These names are for use by higher-level control protocols, such as the Session Description Protocol (SDP), RFC 2327 [15], to refer to transport methods.
RTP profile specifications SHOULD register with IANA a name for the profile in the form "RTP/xxx", where xxx is a short abbreviation of the profile title. These names are for use by higher-level control protocols, such as the Session Description Protocol (SDP), RFC 2327 [15], to refer to transport methods.
16. Intellectual Property Rights Statement
16. Intellectual Property Rights Statement
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
17. Acknowledgments
17. Acknowledgments
This memorandum is based on discussions within the IETF Audio/Video Transport working group chaired by Stephen Casner and Colin Perkins. The current protocol has its origins in the Network Voice Protocol and the Packet Video Protocol (Danny Cohen and Randy Cole) and the protocol implemented by the vat application (Van Jacobson and Steve McCanne). Christian Huitema provided ideas for the random identifier generator. Extensive analysis and simulation of the timer reconsideration algorithm was done by Jonathan Rosenberg. The additions for layered encodings were specified by Michael Speer and Steve McCanne.
This memorandum is based on discussions within the IETF Audio/Video Transport working group chaired by Stephen Casner and Colin Perkins. The current protocol has its origins in the Network Voice Protocol and the Packet Video Protocol (Danny Cohen and Randy Cole) and the protocol implemented by the vat application (Van Jacobson and Steve McCanne). Christian Huitema provided ideas for the random identifier generator. Extensive analysis and simulation of the timer reconsideration algorithm was done by Jonathan Rosenberg. The additions for layered encodings were specified by Michael Speer and Steve McCanne.
Schulzrinne, et al. Standards Track [Page 74] RFC 3550 RTP July 2003
Schulzrinne, et al. Standards Track [Page 74] RFC 3550 RTP July 2003
Appendix A - Algorithms
Appendix A - Algorithms
We provide examples of C code for aspects of RTP sender and receiver algorithms. There may be other implementation methods that are faster in particular operating environments or have other advantages. These implementation notes are for informational purposes only and are meant to clarify the RTP specification.
We provide examples of C code for aspects of RTP sender and receiver algorithms. There may be other implementation methods that are faster in particular operating environments or have other advantages. These implementation notes are for informational purposes only and are meant to clarify the RTP specification.
The following definitions are used for all examples; for clarity and brevity, the structure definitions are only valid for 32-bit big- endian (most significant octet first) architectures. Bit fields are assumed to be packed tightly in big-endian bit order, with no additional padding. Modifications would be required to construct a portable implementation.
The following definitions are used for all examples; for clarity and brevity, the structure definitions are only valid for 32-bit big- endian (most significant octet first) architectures. Bit fields are assumed to be packed tightly in big-endian bit order, with no additional padding. Modifications would be required to construct a portable implementation.
/*
* rtp.h -- RTP header file
*/
#include <sys/types.h>
/* * rtp.h -- RTP header file */ #include <sys/types.h>
/*
* The type definitions below are valid for 32-bit architectures and
* may have to be adjusted for 16- or 64-bit architectures.
*/
typedef unsigned char u_int8;
typedef unsigned short u_int16;
typedef unsigned int u_int32;
typedef short int16;
/* * The type definitions below are valid for 32-bit architectures and * may have to be adjusted for 16- or 64-bit architectures. */ typedef unsigned char u_int8; typedef unsigned short u_int16; typedef unsigned int u_int32; typedef short int16;
/*
* Current protocol version.
*/
#define RTP_VERSION 2
/* * Current protocol version. */ #define RTP_VERSION 2
#define RTP_SEQ_MOD (1<<16) #define RTP_MAX_SDES 255 /* maximum text length for SDES */
#define RTP_SEQ_MOD (1<<16) #define RTP_MAX_SDES 255 /* maximum text length for SDES */
typedef enum {
RTCP_SR = 200,
RTCP_RR = 201,
RTCP_SDES = 202,
RTCP_BYE = 203,
RTCP_APP = 204
} rtcp_type_t;
typedef enum { RTCP_SR = 200, RTCP_RR = 201, RTCP_SDES = 202, RTCP_BYE = 203, RTCP_APP = 204 } rtcp_type_t;
typedef enum {
RTCP_SDES_END = 0,
RTCP_SDES_CNAME = 1,
typedef enum { RTCP_SDES_END = 0, RTCP_SDES_CNAME = 1,
Schulzrinne, et al. Standards Track [Page 75] RFC 3550 RTP July 2003
Schulzrinne, et al. Standards Track [Page 75] RFC 3550 RTP July 2003
RTCP_SDES_NAME = 2,
RTCP_SDES_EMAIL = 3,
RTCP_SDES_PHONE = 4,
RTCP_SDES_LOC = 5,
RTCP_SDES_TOOL = 6,
RTCP_SDES_NOTE = 7,
RTCP_SDES_PRIV = 8
} rtcp_sdes_type_t;
RTCP_SDES_NAME = 2, RTCP_SDES_EMAIL = 3, RTCP_SDES_PHONE = 4, RTCP_SDES_LOC = 5, RTCP_SDES_TOOL = 6, RTCP_SDES_NOTE = 7, RTCP_SDES_PRIV = 8 } rtcp_sdes_type_t;
/*
* RTP data header
*/
typedef struct {
unsigned int version:2; /* protocol version */
unsigned int p:1; /* padding flag */
unsigned int x:1; /* header extension flag */
unsigned int cc:4; /* CSRC count */
unsigned int m:1; /* marker bit */
unsigned int pt:7; /* payload type */
unsigned int seq:16; /* sequence number */
u_int32 ts; /* timestamp */
u_int32 ssrc; /* synchronization source */
u_int32 csrc[1]; /* optional CSRC list */
} rtp_hdr_t;
/* * RTP data header */ typedef struct { unsigned int version:2; /* protocol version */ unsigned int p:1; /* padding flag */ unsigned int x:1; /* header extension flag */ unsigned int cc:4; /* CSRC count */ unsigned int m:1; /* marker bit */ unsigned int pt:7; /* payload type */ unsigned int seq:16; /* sequence number */ u_int32 ts; /* timestamp */ u_int32 ssrc; /* synchronization source */ u_int32 csrc[1]; /* optional CSRC list */ } rtp_hdr_t;
/*
* RTCP common header word
*/
typedef struct {
unsigned int version:2; /* protocol version */
unsigned int p:1; /* padding flag */
unsigned int count:5; /* varies by packet type */
unsigned int pt:8; /* RTCP packet type */
u_int16 length; /* pkt len in words, w/o this word */
} rtcp_common_t;
/* * RTCP common header word */ typedef struct { unsigned int version:2; /* protocol version */ unsigned int p:1; /* padding flag */ unsigned int count:5; /* varies by packet type */ unsigned int pt:8; /* RTCP packet type */ u_int16 length; /* pkt len in words, w/o this word */ } rtcp_common_t;
/*
* Big-endian mask for version, padding bit and packet type pair
*/
#define RTCP_VALID_MASK (0xc000 | 0x2000 | 0xfe)
#define RTCP_VALID_VALUE ((RTP_VERSION << 14) | RTCP_SR)
/* * Big-endian mask for version, padding bit and packet type pair */ #define RTCP_VALID_MASK (0xc000 | 0x2000 | 0xfe) #define RTCP_VALID_VALUE ((RTP_VERSION << 14) | RTCP_SR)
/*
* Reception report block
*/
typedef struct {
u_int32 ssrc; /* data source being reported */
unsigned int fraction:8; /* fraction lost since last SR/RR */
/* * Reception report block */ typedef struct { u_int32 ssrc; /* data source being reported */ unsigned int fraction:8; /* fraction lost since last SR/RR */
Schulzrinne, et al. Standards Track [Page 76] RFC 3550 RTP July 2003
Schulzrinne, et al. Standards Track [Page 76] RFC 3550 RTP July 2003
int lost:24; /* cumul. no. pkts lost (signed!) */
u_int32 last_seq; /* extended last seq. no. received */
u_int32 jitter; /* interarrival jitter */
u_int32 lsr; /* last SR packet from this source */
u_int32 dlsr; /* delay since last SR packet */
} rtcp_rr_t;
int lost:24; /* cumul. no. pkts lost (signed!) */ u_int32 last_seq; /* extended last seq. no. received */ u_int32 jitter; /* interarrival jitter */ u_int32 lsr; /* last SR packet from this source */ u_int32 dlsr; /* delay since last SR packet */ } rtcp_rr_t;
/*
* SDES item
*/
typedef struct {
u_int8 type; /* type of item (rtcp_sdes_type_t) */
u_int8 length; /* length of item (in octets) */
char data[1]; /* text, not null-terminated */
} rtcp_sdes_item_t;
/* * SDES item */ typedef struct { u_int8 type; /* type of item (rtcp_sdes_type_t) */ u_int8 length; /* length of item (in octets) */ char data[1]; /* text, not null-terminated */ } rtcp_sdes_item_t;
/*
* One RTCP packet
*/
typedef struct {
rtcp_common_t common; /* common header */
union {
/* sender report (SR) */
struct {
u_int32 ssrc; /* sender generating this report */
u_int32 ntp_sec; /* NTP timestamp */
u_int32 ntp_frac;
u_int32 rtp_ts; /* RTP timestamp */
u_int32 psent; /* packets sent */
u_int32 osent; /* octets sent */
rtcp_rr_t rr[1]; /* variable-length list */
} sr;
/* * One RTCP packet */ typedef struct { rtcp_common_t common; /* common header */ union { /* sender report (SR) */ struct { u_int32 ssrc; /* sender generating this report */ u_int32 ntp_sec; /* NTP timestamp */ u_int32 ntp_frac; u_int32 rtp_ts; /* RTP timestamp */ u_int32 psent; /* packets sent */ u_int32 osent; /* octets sent */ rtcp_rr_t rr[1]; /* variable-length list */ } sr;
/* reception report (RR) */
struct {
u_int32 ssrc; /* receiver generating this report */
rtcp_rr_t rr[1]; /* variable-length list */
} rr;
/* reception report (RR) */ struct { u_int32 ssrc; /* receiver generating this report */ rtcp_rr_t rr[1]; /* variable-length list */ } rr;
/* source description (SDES) */
struct rtcp_sdes {
u_int32 src; /* first SSRC/CSRC */
rtcp_sdes_item_t item[1]; /* list of SDES items */
} sdes;
/* source description (SDES) */ struct rtcp_sdes { u_int32 src; /* first SSRC/CSRC */ rtcp_sdes_item_t item[1]; /* list of SDES items */ } sdes;
/* BYE */
struct {
u_int32 src[1]; /* list of sources */
/* BYE */ struct { u_int32 src[1]; /* list of sources */
Schulzrinne, et al. Standards Track [Page 77] RFC 3550 RTP July 2003
Schulzrinne, et al. Standards Track [Page 77] RFC 3550 RTP July 2003
/* can't express trailing text for reason */
} bye;
} r;
} rtcp_t;
/* can't express trailing text for reason */ } bye; } r; } rtcp_t;
typedef struct rtcp_sdes rtcp_sdes_t;
typedef struct rtcp_sdes rtcp_sdes_t;
/*
* Per-source state information
*/
typedef struct {
u_int16 max_seq; /* highest seq. number seen */
u_int32 cycles; /* shifted count of seq. number cycles */
u_int32 base_seq; /* base seq number */
u_int32 bad_seq; /* last 'bad' seq number + 1 */
u_int32 probation; /* sequ. packets till source is valid */
u_int32 received; /* packets received */
u_int32 expected_prior; /* packet expected at last interval */
u_int32 received_prior; /* packet received at last interval */
u_int32 transit; /* relative trans time for prev pkt */
u_int32 jitter; /* estimated jitter */
/* ... */
} source;
/* * Per-source state information */ typedef struct { u_int16 max_seq; /* highest seq. number seen */ u_int32 cycles; /* shifted count of seq. number cycles */ u_int32 base_seq; /* base seq number */ u_int32 bad_seq; /* last 'bad' seq number + 1 */ u_int32 probation; /* sequ. packets till source is valid */ u_int32 received; /* packets received */ u_int32 expected_prior; /* packet expected at last interval */ u_int32 received_prior; /* packet received at last interval */ u_int32 transit; /* relative trans time for prev pkt */ u_int32 jitter; /* estimated jitter */ /* ... */ } source;
A.1 RTP Data Header Validity Checks
A.1 RTP Data Header Validity Checks
An RTP receiver should check the validity of the RTP header on incoming packets since they might be encrypted or might be from a different application that happens to be misaddressed. Similarly, if encryption according to the method described in Section 9 is enabled, the header validity check is needed to verify that incoming packets have been correctly decrypted, although a failure of the header validity check (e.g., unknown payload type) may not necessarily indicate decryption failure.
An RTP receiver should check the validity of the RTP header on incoming packets since they might be encrypted or might be from a different application that happens to be misaddressed. Similarly, if encryption according to the method described in Section 9 is enabled, the header validity check is needed to verify that incoming packets have been correctly decrypted, although a failure of the header validity check (e.g., unknown payload type) may not necessarily indicate decryption failure.
Only weak validity checks are possible on an RTP data packet from a source that has not been heard before:
Only weak validity checks are possible on an RTP data packet from a source that has not been heard before:
o RTP version field must equal 2.
o RTP version field must equal 2.
o The payload type must be known, and in particular it must not be
equal to SR or RR.
o The payload type must be known, and in particular it must not be equal to SR or RR.
o If the P bit is set, then the last octet of the packet must
contain a valid octet count, in particular, less than the total
packet length minus the header size.
o If the P bit is set, then the last octet of the packet must contain a valid octet count, in particular, less than the total packet length minus the header size.
Schulzrinne, et al. Standards Track [Page 78] RFC 3550 RTP July 2003
Schulzrinne, et al. Standards Track [Page 78] RFC 3550 RTP July 2003
o The X bit must be zero if the profile does not specify that the
header extension mechanism may be used. Otherwise, the extension
length field must be less than the total packet size minus the
fixed header length and padding.
o The X bit must be zero if the profile does not specify that the header extension mechanism may be used. Otherwise, the extension length field must be less than the total packet size minus the fixed header length and padding.
o The length of the packet must be consistent with CC and payload
type (if payloads have a known length).
o The length of the packet must be consistent with CC and payload type (if payloads have a known length).
The last three checks are somewhat complex and not always possible, leaving only the first two which total just a few bits. If the SSRC identifier in the packet is one that has been received before, then the packet is probably valid and checking if the sequence number is in the expected range provides further validation. If the SSRC identifier has not been seen before, then data packets carrying that identifier may be considered invalid until a small number of them arrive with consecutive sequence numbers. Those invalid packets MAY be discarded or they MAY be stored and delivered once validation has been achieved if the resulting delay is acceptable.
The last three checks are somewhat complex and not always possible, leaving only the first two which total just a few bits. If the SSRC identifier in the packet is one that has been received before, then the packet is probably valid and checking if the sequence number is in the expected range provides further validation. If the SSRC identifier has not been seen before, then data packets carrying that identifier may be considered invalid until a small number of them arrive with consecutive sequence numbers. Those invalid packets MAY be discarded or they MAY be stored and delivered once validation has been achieved if the resulting delay is acceptable.
The routine update_seq shown below ensures that a source is declared valid only after MIN_SEQUENTIAL packets have been received in sequence. It also validates the sequence number seq of a newly received packet and updates the sequence state for the packet's source in the structure to which s points.
The routine update_seq shown below ensures that a source is declared valid only after MIN_SEQUENTIAL packets have been received in sequence. It also validates the sequence number seq of a newly received packet and updates the sequence state for the packet's source in the structure to which s points.
When a new source is heard for the first time, that is, its SSRC identifier is not in the table (see Section 8.2), and the per-source state is allocated for it, s->probation is set to the number of sequential packets required before declaring a source valid (parameter MIN_SEQUENTIAL) and other variables are initialized:
When a new source is heard for the first time, that is, its SSRC identifier is not in the table (see Section 8.2), and the per-source state is allocated for it, s->probation is set to the number of sequential packets required before declaring a source valid (parameter MIN_SEQUENTIAL) and other variables are initialized:
init_seq(s, seq);
s->max_seq = seq - 1;
s->probation = MIN_SEQUENTIAL;
init_seq(s, seq); s->max_seq = seq - 1; s->probation = MIN_SEQUENTIAL;
A non-zero s->probation marks the source as not yet valid so the state may be discarded after a short timeout rather than a long one, as discussed in Section 6.2.1.
A non-zero s->probation marks the source as not yet valid so the state may be discarded after a short timeout rather than a long one, as discussed in Section 6.2.1.
After a source is considered valid, the sequence number is considered valid if it is no more than MAX_DROPOUT ahead of s->max_seq nor more than MAX_MISORDER behind. If the new sequence number is ahead of max_seq modulo the RTP sequence number range (16 bits), but is smaller than max_seq, it has wrapped around and the (shifted) count of sequence number cycles is incremented. A value of one is returned to indicate a valid sequence number.
After a source is considered valid, the sequence number is considered valid if it is no more than MAX_DROPOUT ahead of s->max_seq nor more than MAX_MISORDER behind. If the new sequence number is ahead of max_seq modulo the RTP sequence number range (16 bits), but is smaller than max_seq, it has wrapped around and the (shifted) count of sequence number cycles is incremented. A value of one is returned to indicate a valid sequence number.
Schulzrinne, et al. Standards Track [Page 79] RFC 3550 RTP July 2003
Schulzrinne, et al. Standards Track [Page 79] RFC 3550 RTP July 2003
Otherwise, the value zero is returned to indicate that the validation failed, and the bad sequence number plus 1 is stored. If the next packet received carries the next higher sequence number, it is considered the valid start of a new packet sequence presumably caused by an extended dropout or a source restart. Since multiple complete sequence number cycles may have been missed, the packet loss statistics are reset.
Otherwise, the value zero is returned to indicate that the validation failed, and the bad sequence number plus 1 is stored. If the next packet received carries the next higher sequence number, it is considered the valid start of a new packet sequence presumably caused by an extended dropout or a source restart. Since multiple complete sequence number cycles may have been missed, the packet loss statistics are reset.
Typical values for the parameters are shown, based on a maximum misordering time of 2 seconds at 50 packets/second and a maximum dropout of 1 minute. The dropout parameter MAX_DROPOUT should be a small fraction of the 16-bit sequence number space to give a reasonable probability that new sequence numbers after a restart will not fall in the acceptable range for sequence numbers from before the restart.
Typical values for the parameters are shown, based on a maximum misordering time of 2 seconds at 50 packets/second and a maximum dropout of 1 minute. The dropout parameter MAX_DROPOUT should be a small fraction of the 16-bit sequence number space to give a reasonable probability that new sequence numbers after a restart will not fall in the acceptable range for sequence numbers from before the restart.
void init_seq(source *s, u_int16 seq)
{
s->base_seq = seq;
s->max_seq = seq;
s->bad_seq = RTP_SEQ_MOD + 1; /* so seq == bad_seq is false */
s->cycles = 0;
s->received = 0;
s->received_prior = 0;
s->expected_prior = 0;
/* other initialization */
}
void init_seq(source *s, u_int16 seq) { s->base_seq = seq; s->max_seq = seq; s->bad_seq = RTP_SEQ_MOD + 1; /* so seq == bad_seq is false */ s->cycles = 0; s->received = 0; s->received_prior = 0; s->expected_prior = 0; /* other initialization */ }
int update_seq(source *s, u_int16 seq)
{
u_int16 udelta = seq - s->max_seq;
const int MAX_DROPOUT = 3000;
const int MAX_MISORDER = 100;
const int MIN_SEQUENTIAL = 2;
int update_seq(source *s, u_int16 seq) { u_int16 udelta = seq - s->max_seq; const int MAX_DROPOUT = 3000; const int MAX_MISORDER = 100; const int MIN_SEQUENTIAL = 2;
/*
* Source is not valid until MIN_SEQUENTIAL packets with
* sequential sequence numbers have been received.
*/
if (s->probation) {
/* packet is in sequence */
if (seq == s->max_seq + 1) {
s->probation--;
s->max_seq = seq;
if (s->probation == 0) {
init_seq(s, seq);
s->received++;
return 1;
/* * Source is not valid until MIN_SEQUENTIAL packets with * sequential sequence numbers have been received. */ if (s->probation) { /* packet is in sequence */ if (seq == s->max_seq + 1) { s->probation--; s->max_seq = seq; if (s->probation == 0) { init_seq(s, seq); s->received++; return 1;
Schulzrinne, et al. Standards Track [Page 80] RFC 3550 RTP July 2003
Schulzrinne, et al. Standards Track [Page 80] RFC 3550 RTP July 2003
}
} else {
s->probation = MIN_SEQUENTIAL - 1;
s->max_seq = seq;
}
return 0;
} else if (udelta < MAX_DROPOUT) {
/* in order, with permissible gap */
if (seq < s->max_seq) {
/*
* Sequence number wrapped - count another 64K cycle.
*/
s->cycles += RTP_SEQ_MOD;
}
s->max_seq = seq;
} else if (udelta <= RTP_SEQ_MOD - MAX_MISORDER) {
/* the sequence number made a very large jump */
if (seq == s->bad_seq) {
/*
* Two sequential packets -- assume that the other side
* restarted without telling us so just re-sync
* (i.e., pretend this was the first packet).
*/
init_seq(s, seq);
}
else {
s->bad_seq = (seq + 1) & (RTP_SEQ_MOD-1);
return 0;
}
} else {
/* duplicate or reordered packet */
}
s->received++;
return 1;
}
} } else { s->probation = MIN_SEQUENTIAL - 1; s->max_seq = seq; } return 0; } else if (udelta < MAX_DROPOUT) { /* in order, with permissible gap */ if (seq < s->max_seq) { /* * Sequence number wrapped - count another 64K cycle. */ s->cycles += RTP_SEQ_MOD; } s->max_seq = seq; } else if (udelta <= RTP_SEQ_MOD - MAX_MISORDER) { /* the sequence number made a very large jump */ if (seq == s->bad_seq) { /* * Two sequential packets -- assume that the other side * restarted without telling us so just re-sync * (i.e., pretend this was the first packet). */ init_seq(s, seq); } else { s->bad_seq = (seq + 1) & (RTP_SEQ_MOD-1); return 0; } } else { /* duplicate or reordered packet */ } s->received++; return 1; }
The validity check can be made stronger requiring more than two packets in sequence. The disadvantages are that a larger number of initial packets will be discarded (or delayed in a queue) and that high packet loss rates could prevent validation. However, because the RTCP header validation is relatively strong, if an RTCP packet is received from a source before the data packets, the count could be adjusted so that only two packets are required in sequence. If initial data loss for a few seconds can be tolerated, an application MAY choose to discard all data packets from a source until a valid RTCP packet has been received from that source.
The validity check can be made stronger requiring more than two packets in sequence. The disadvantages are that a larger number of initial packets will be discarded (or delayed in a queue) and that high packet loss rates could prevent validation. However, because the RTCP header validation is relatively strong, if an RTCP packet is received from a source before the data packets, the count could be adjusted so that only two packets are required in sequence. If initial data loss for a few seconds can be tolerated, an application MAY choose to discard all data packets from a source until a valid RTCP packet has been received from that source.
Schulzrinne, et al. Standards Track [Page 81] RFC 3550 RTP July 2003
Schulzrinne, et al. Standards Track [Page 81] RFC 3550 RTP July 2003
Depending on the application and encoding, algorithms may exploit additional knowledge about the payload format for further validation. For payload types where the timestamp increment is the same for all packets, the timestamp values can be predicted from the previous packet received from the same source using the sequence number difference (assuming no change in payload type).
Depending on the application and encoding, algorithms may exploit additional knowledge about the payload format for further validation. For payload types where the timestamp increment is the same for all packets, the timestamp values can be predicted from the previous packet received from the same source using the sequence number difference (assuming no change in payload type).
A strong "fast-path" check is possible since with high probability the first four octets in the header of a newly received RTP data packet will be just the same as that of the previous packet from the same SSRC except that the sequence number will have increased by one. Similarly, a single-entry cache may be used for faster SSRC lookups in applications where data is typically received from one source at a time.
A strong "fast-path" check is possible since with high probability the first four octets in the header of a newly received RTP data packet will be just the same as that of the previous packet from the same SSRC except that the sequence number will have increased by one. Similarly, a single-entry cache may be used for faster SSRC lookups in applications where data is typically received from one source at a time.
A.2 RTCP Header Validity Checks
A.2 RTCP Header Validity Checks
The following checks should be applied to RTCP packets.
The following checks should be applied to RTCP packets.
o RTP version field must equal 2.
o RTP version field must equal 2.
o The payload type field of the first RTCP packet in a compound
packet must be equal to SR or RR.
o The payload type field of the first RTCP packet in a compound packet must be equal to SR or RR.
o The padding bit (P) should be zero for the first packet of a
compound RTCP packet because padding should only be applied, if it
is needed, to the last packet.
o The padding bit (P) should be zero for the first packet of a compound RTCP packet because padding should only be applied, if it is needed, to the last packet.
o The length fields of the individual RTCP packets must add up to
the overall length of the compound RTCP packet as received. This
is a fairly strong check.
o The length fields of the individual RTCP packets must add up to the overall length of the compound RTCP packet as received. This is a fairly strong check.
The code fragment below performs all of these checks. The packet type is not checked for subsequent packets since unknown packet types may be present and should be ignored.
The code fragment below performs all of these checks. The packet type is not checked for subsequent packets since unknown packet types may be present and should be ignored.
u_int32 len; /* length of compound RTCP packet in words */
rtcp_t *r; /* RTCP header */
rtcp_t *end; /* end of compound RTCP packet */
u_int32 len; /* length of compound RTCP packet in words */ rtcp_t *r; /* RTCP header */ rtcp_t *end; /* end of compound RTCP packet */
if ((*(u_int16 *)r & RTCP_VALID_MASK) != RTCP_VALID_VALUE) {
/* something wrong with packet format */
}
end = (rtcp_t *)((u_int32 *)r + len);
if ((*(u_int16 *)r & RTCP_VALID_MASK) != RTCP_VALID_VALUE) { /* something wrong with packet format */ } end = (rtcp_t *)((u_int32 *)r + len);
do r = (rtcp_t *)((u_int32 *)r + r->common.length + 1);
while (r < end && r->common.version == 2);
do r = (rtcp_t *)((u_int32 *)r + r->common.length + 1); while (r < end && r->common.version == 2);
Schulzrinne, et al. Standards Track [Page 82] RFC 3550 RTP July 2003
Schulzrinne, et al. Standards Track [Page 82] RFC 3550 RTP July 2003
if (r != end) {
/* something wrong with packet format */
}
if (r != end) { /* something wrong with packet format */ }
A.3 Determining Number of Packets Expected and Lost
A.3 Determining Number of Packets Expected and Lost
In order to compute packet loss rates, the number of RTP packets expected and actually received from each source needs to be known, using per-source state information defined in struct source referenced via pointer s in the code below. The number of packets received is simply the count of packets as they arrive, including any late or duplicate packets. The number of packets expected can be computed by the receiver as the difference between the highest sequence number received (s->max_seq) and the first sequence number received (s->base_seq). Since the sequence number is only 16 bits and will wrap around, it is necessary to extend the highest sequence number with the (shifted) count of sequence number wraparounds (s->cycles). Both the received packet count and the count of cycles are maintained the RTP header validity check routine in Appendix A.1.
In order to compute packet loss rates, the number of RTP packets expected and actually received from each source needs to be known, using per-source state information defined in struct source referenced via pointer s in the code below. The number of packets received is simply the count of packets as they arrive, including any late or duplicate packets. The number of packets expected can be computed by the receiver as the difference between the highest sequence number received (s->max_seq) and the first sequence number received (s->base_seq). Since the sequence number is only 16 bits and will wrap around, it is necessary to extend the highest sequence number with the (shifted) count of sequence number wraparounds (s->cycles). Both the received packet count and the count of cycles are maintained the RTP header validity check routine in Appendix A.1.
extended_max = s->cycles + s->max_seq;
expected = extended_max - s->base_seq + 1;
extended_max = s->cycles + s->max_seq; expected = extended_max - s->base_seq + 1;
The number of packets lost is defined to be the number of packets expected less the number of packets actually received:
The number of packets lost is defined to be the number of packets expected less the number of packets actually received:
lost = expected - s->received;
lost = expected - s->received;
Since this signed number is carried in 24 bits, it should be clamped at 0x7fffff for positive loss or 0x800000 for negative loss rather than wrapping around.
Since this signed number is carried in 24 bits, it should be clamped at 0x7fffff for positive loss or 0x800000 for negative loss rather than wrapping around.
The fraction of packets lost during the last reporting interval (since the previous SR or RR packet was sent) is calculated from differences in the expected and received packet counts across the interval, where expected_prior and received_prior are the values saved when the previous reception report was generated:
The fraction of packets lost during the last reporting interval (since the previous SR or RR packet was sent) is calculated from differences in the expected and received packet counts across the interval, where expected_prior and received_prior are the values saved when the previous reception report was generated:
expected_interval = expected - s->expected_prior;
s->expected_prior = expected;
received_interval = s->received - s->received_prior;
s->received_prior = s->received;
lost_interval = expected_interval - received_interval;
if (expected_interval == 0 || lost_interval <= 0) fraction = 0;
else fraction = (lost_interval << 8) / expected_interval;
expected_interval = expected - s->expected_prior; s->expected_prior = expected; received_interval = s->received - s->received_prior; s->received_prior = s->received; lost_interval = expected_interval - received_interval; if (expected_interval == 0 || lost_interval <= 0) fraction = 0; else fraction = (lost_interval << 8) / expected_interval;
The resulting fraction is an 8-bit fixed point number with the binary point at the left edge.
The resulting fraction is an 8-bit fixed point number with the binary point at the left edge.
Schulzrinne, et al. Standards Track [Page 83] RFC 3550 RTP July 2003
Schulzrinne, et al. Standards Track [Page 83] RFC 3550 RTP July 2003
A.4 Generating RTCP SDES Packets
A.4 Generating RTCP SDES Packets
This function builds one SDES chunk into buffer b composed of argc items supplied in arrays type, value and length. It returns a pointer to the next available location within b.
This function builds one SDES chunk into buffer b composed of argc items supplied in arrays type, value and length. It returns a pointer to the next available location within b.
char *rtp_write_sdes(char *b, u_int32 src, int argc,
rtcp_sdes_type_t type[], char *value[],
int length[])
{
rtcp_sdes_t *s = (rtcp_sdes_t *)b;
rtcp_sdes_item_t *rsp;
int i;
int len;
int pad;
char *rtp_write_sdes(char *b, u_int32 src, int argc, rtcp_sdes_type_t type[], char *value[], int length[]) { rtcp_sdes_t *s = (rtcp_sdes_t *)b; rtcp_sdes_item_t *rsp; int i; int len; int pad;
/* SSRC header */
s->src = src;
rsp = &s->item[0];
/* SSRC header */ s->src = src; rsp = &s->item[0];
/* SDES items */
for (i = 0; i < argc; i++) {
rsp->type = type[i];
len = length[i];
if (len > RTP_MAX_SDES) {
/* invalid length, may want to take other action */
len = RTP_MAX_SDES;
}
rsp->length = len;
memcpy(rsp->data, value[i], len);
rsp = (rtcp_sdes_item_t *)&rsp->data[len];
}
/* SDES items */ for (i = 0; i < argc; i++) { rsp->type = type[i]; len = length[i]; if (len > RTP_MAX_SDES) { /* invalid length, may want to take other action */ len = RTP_MAX_SDES; } rsp->length = len; memcpy(rsp->data, value[i], len); rsp = (rtcp_sdes_item_t *)&rsp->data[len]; }
/* terminate with end marker and pad to next 4-octet boundary */
len = ((char *) rsp) - b;
pad = 4 - (len & 0x3);
b = (char *) rsp;
while (pad--) *b++ = RTCP_SDES_END;
/* terminate with end marker and pad to next 4-octet boundary */ len = ((char *) rsp) - b; pad = 4 - (len & 0x3); b = (char *) rsp; while (pad--) *b++ = RTCP_SDES_END;
return b;
}
return b; }
Schulzrinne, et al. Standards Track [Page 84] RFC 3550 RTP July 2003
Schulzrinne, et al. Standards Track [Page 84] RFC 3550 RTP July 2003
A.5 Parsing RTCP SDES Packets
A.5 Parsing RTCP SDES Packets
This function parses an SDES packet, calling functions find_member() to find a pointer to the information for a session member given the SSRC identifier and member_sdes() to store the new SDES information for that member. This function expects a pointer to the header of the RTCP packet.
This function parses an SDES packet, calling functions find_member() to find a pointer to the information for a session member given the SSRC identifier and member_sdes() to store the new SDES information for that member. This function expects a pointer to the header of the RTCP packet.
void rtp_read_sdes(rtcp_t *r)
{
int count = r->common.count;
rtcp_sdes_t *sd = &r->r.sdes;
rtcp_sdes_item_t *rsp, *rspn;
rtcp_sdes_item_t *end = (rtcp_sdes_item_t *)
((u_int32 *)r + r->common.length + 1);
source *s;
void rtp_read_sdes(rtcp_t *r) { int count = r->common.count; rtcp_sdes_t *sd = &r->r.sdes; rtcp_sdes_item_t *rsp, *rspn; rtcp_sdes_item_t *end = (rtcp_sdes_item_t *) ((u_int32 *)r + r->common.length + 1); source *s;
while (--count >= 0) {
rsp = &sd->item[0];
if (rsp >= end) break;
s = find_member(sd->src);
while (--count >= 0) { rsp = &sd->item[0]; if (rsp >= end) break; s = find_member(sd->src);
for (; rsp->type; rsp = rspn ) {
rspn = (rtcp_sdes_item_t *)((char*)rsp+rsp->length+2);
if (rspn >= end) {
rsp = rspn;
break;
}
member_sdes(s, rsp->type, rsp->data, rsp->length);
}
sd = (rtcp_sdes_t *)
((u_int32 *)sd + (((char *)rsp - (char *)sd) >> 2)+1);
}
if (count >= 0) {
/* invalid packet format */
}
}
for (; rsp->type; rsp = rspn ) { rspn = (rtcp_sdes_item_t *)((char*)rsp+rsp->length+2); if (rspn >= end) { rsp = rspn; break; } member_sdes(s, rsp->type, rsp->data, rsp->length); } sd = (rtcp_sdes_t *) ((u_int32 *)sd + (((char *)rsp - (char *)sd) >> 2)+1); } if (count >= 0) { /* invalid packet format */ } }
A.6 Generating a Random 32-bit Identifier
A.6 Generating a Random 32-bit Identifier
The following subroutine generates a random 32-bit identifier using the MD5 routines published in RFC 1321 [32]. The system routines may not be present on all operating systems, but they should serve as hints as to what kinds of information may be used. Other system calls that may be appropriate include
The following subroutine generates a random 32-bit identifier using the MD5 routines published in RFC 1321 [32]. The system routines may not be present on all operating systems, but they should serve as hints as to what kinds of information may be used. Other system calls that may be appropriate include
Schulzrinne, et al. Standards Track [Page 85] RFC 3550 RTP July 2003
Schulzrinne, et al. Standards Track [Page 85] RFC 3550 RTP July 2003
o getdomainname(),
o getdomainname(),
o getwd(), or
o getwd(), or
o getrusage().
o getrusage().
"Live" video or audio samples are also a good source of random numbers, but care must be taken to avoid using a turned-off microphone or blinded camera as a source [17].
"Live" video or audio samples are also a good source of random numbers, but care must be taken to avoid using a turned-off microphone or blinded camera as a source [17].
Use of this or a similar routine is recommended to generate the initial seed for the random number generator producing the RTCP period (as shown in Appendix A.7), to generate the initial values for the sequence number and timestamp, and to generate SSRC values. Since this routine is likely to be CPU-intensive, its direct use to generate RTCP periods is inappropriate because predictability is not an issue. Note that this routine produces the same result on repeated calls until the value of the system clock changes unless different values are supplied for the type argument.
Use of this or a similar routine is recommended to generate the initial seed for the random number generator producing the RTCP period (as shown in Appendix A.7), to generate the initial values for the sequence number and timestamp, and to generate SSRC values. Since this routine is likely to be CPU-intensive, its direct use to generate RTCP periods is inappropriate because predictability is not an issue. Note that this routine produces the same result on repeated calls until the value of the system clock changes unless different values are supplied for the type argument.
/*
* Generate a random 32-bit quantity.
*/
#include <sys/types.h> /* u_long */
#include <sys/time.h> /* gettimeofday() */
#include <unistd.h> /* get..() */
#include <stdio.h> /* printf() */
#include <time.h> /* clock() */
#include <sys/utsname.h> /* uname() */
#include "global.h" /* from RFC 1321 */
#include "md5.h" /* from RFC 1321 */
/* * Generate a random 32-bit quantity. */ #include <sys/types.h> /* u_long */ #include <sys/time.h> /* gettimeofday() */ #include <unistd.h> /* get..() */ #include <stdio.h> /* printf() */ #include <time.h> /* clock() */ #include <sys/utsname.h> /* uname() */ #include "global.h" /* from RFC 1321 */ #include "md5.h" /* from RFC 1321 */
#define MD_CTX MD5_CTX #define MDInit MD5Init #define MDUpdate MD5Update #define MDFinal MD5Final
#define MD_CTX MD5_CTX #define MDInit MD5Init #define MDUpdate MD5Update #define MDFinal MD5Final
static u_long md_32(char *string, int length)
{
MD_CTX context;
union {
char c[16];
u_long x[4];
} digest;
u_long r;
int i;
static u_long md_32(char *string, int length) { MD_CTX context; union { char c[16]; u_long x[4]; } digest; u_long r; int i;
MDInit (&context);
MDInit (&context);
Schulzrinne, et al. Standards Track [Page 86] RFC 3550 RTP July 2003
Schulzrinne, et al. Standards Track [Page 86] RFC 3550 RTP July 2003
MDUpdate (&context, string, length);
MDFinal ((unsigned char *)&digest, &context);
r = 0;
for (i = 0; i < 3; i++) {
r ^= digest.x[i];
}
return r;
} /* md_32 */
MDUpdate (&context, string, length); MDFinal ((unsigned char *)&digest, &context); r = 0; for (i = 0; i < 3; i++) { r ^= digest.x[i]; } return r; } /* md_32 */
/*
* Return random unsigned 32-bit quantity. Use 'type' argument if
* you need to generate several different values in close succession.
*/
u_int32 random32(int type)
{
struct {
int type;
struct timeval tv;
clock_t cpu;
pid_t pid;
u_long hid;
uid_t uid;
gid_t gid;
struct utsname name;
} s;
/* * Return random unsigned 32-bit quantity. Use 'type' argument if * you need to generate several different values in close succession. */ u_int32 random32(int type) { struct { int type; struct timeval tv; clock_t cpu; pid_t pid; u_long hid; uid_t uid; gid_t gid; struct utsname name; } s;
gettimeofday(&s.tv, 0);
uname(&s.name);
s.type = type;
s.cpu = clock();
s.pid = getpid();
s.hid = gethostid();
s.uid = getuid();
s.gid = getgid();
/* also: system uptime */
gettimeofday(&s.tv, 0); uname(&s.name); s.type = type; s.cpu = clock(); s.pid = getpid(); s.hid = gethostid(); s.uid = getuid(); s.gid = getgid(); /* also: system uptime */
return md_32((char *)&s, sizeof(s));
} /* random32 */
return md_32((char *)&s, sizeof(s)); } /* random32 */
A.7 Computing the RTCP Transmission Interval
A.7 Computing the RTCP Transmission Interval
The following functions implement the RTCP transmission and reception rules described in Section 6.2. These rules are coded in several functions:
The following functions implement the RTCP transmission and reception rules described in Section 6.2. These rules are coded in several functions:
o rtcp_interval() computes the deterministic calculated interval,
measured in seconds. The parameters are defined in Section 6.3.
o rtcp_interval() computes the deterministic calculated interval, measured in seconds. The parameters are defined in Section 6.3.
Schulzrinne, et al. Standards Track [Page 87] RFC 3550 RTP July 2003
Schulzrinne, et al. Standards Track [Page 87] RFC 3550 RTP July 2003
o OnExpire() is called when the RTCP transmission timer expires.
o OnExpire() is called when the RTCP transmission timer expires.
o OnReceive() is called whenever an RTCP packet is received.
o OnReceive() is called whenever an RTCP packet is received.
Both OnExpire() and OnReceive() have event e as an argument. This is the next scheduled event for that participant, either an RTCP report or a BYE packet. It is assumed that the following functions are available:
Both OnExpire() and OnReceive() have event e as an argument. This is the next scheduled event for that participant, either an RTCP report or a BYE packet. It is assumed that the following functions are available:
o Schedule(time t, event e) schedules an event e to occur at time t.
When time t arrives, the function OnExpire is called with e as an
argument.
o Schedule(time t, event e) schedules an event e to occur at time t. When time t arrives, the function OnExpire is called with e as an argument.
o Reschedule(time t, event e) reschedules a previously scheduled
event e for time t.
o Reschedule(time t, event e) reschedules a previously scheduled event e for time t.
o SendRTCPReport(event e) sends an RTCP report.
o SendRTCPReport(event e) sends an RTCP report.
o SendBYEPacket(event e) sends a BYE packet.
o SendBYEPacket(event e) sends a BYE packet.
o TypeOfEvent(event e) returns EVENT_BYE if the event being
processed is for a BYE packet to be sent, else it returns
EVENT_REPORT.
o TypeOfEvent(event e) returns EVENT_BYE if the event being processed is for a BYE packet to be sent, else it returns EVENT_REPORT.
o PacketType(p) returns PACKET_RTCP_REPORT if packet p is an RTCP
report (not BYE), PACKET_BYE if its a BYE RTCP packet, and
PACKET_RTP if its a regular RTP data packet.
o PacketType(p) returns PACKET_RTCP_REPORT if packet p is an RTCP report (not BYE), PACKET_BYE if its a BYE RTCP packet, and PACKET_RTP if its a regular RTP data packet.
o ReceivedPacketSize() and SentPacketSize() return the size of the
referenced packet in octets.
o ReceivedPacketSize() and SentPacketSize() return the size of the referenced packet in octets.
o NewMember(p) returns a 1 if the participant who sent packet p is
not currently in the member list, 0 otherwise. Note this function
is not sufficient for a complete implementation because each CSRC
identifier in an RTP packet and each SSRC in a BYE packet should
be processed.
o NewMember(p) returns a 1 if the participant who sent packet p is not currently in the member list, 0 otherwise. Note this function is not sufficient for a complete implementation because each CSRC identifier in an RTP packet and each SSRC in a BYE packet should be processed.
o NewSender(p) returns a 1 if the participant who sent packet p is
not currently in the sender sublist of the member list, 0
otherwise.
o NewSender(p) returns a 1 if the participant who sent packet p is not currently in the sender sublist of the member list, 0 otherwise.
o AddMember() and RemoveMember() to add and remove participants from
the member list.
o AddMember() and RemoveMember() to add and remove participants from the member list.
o AddSender() and RemoveSender() to add and remove participants from
the sender sublist of the member list.
o AddSender() and RemoveSender() to add and remove participants from the sender sublist of the member list.
Schulzrinne, et al. Standards Track [Page 88] RFC 3550 RTP July 2003
Schulzrinne, et al. Standards Track [Page 88] RFC 3550 RTP July 2003
These functions would have to be extended for an implementation that allows the RTCP bandwidth fractions for senders and non-senders to be specified as explicit parameters rather than fixed values of 25% and 75%. The extended implementation of rtcp_interval() would need to avoid division by zero if one of the parameters was zero.
These functions would have to be extended for an implementation that allows the RTCP bandwidth fractions for senders and non-senders to be specified as explicit parameters rather than fixed values of 25% and 75%. The extended implementation of rtcp_interval() would need to avoid division by zero if one of the parameters was zero.
double rtcp_interval(int members,
int senders,
double rtcp_bw,
int we_sent,
double avg_rtcp_size,
int initial)
{
/*
* Minimum average time between RTCP packets from this site (in
* seconds). This time prevents the reports from `clumping' when
* sessions are small and the law of large numbers isn't helping
* to smooth out the traffic. It also keeps the report interval
* from becoming ridiculously small during transient outages like
* a network partition.
*/
double const RTCP_MIN_TIME = 5.;
/*
* Fraction of the RTCP bandwidth to be shared among active
* senders. (This fraction was chosen so that in a typical
* session with one or two active senders, the computed report
* time would be roughly equal to the minimum report time so that
* we don't unnecessarily slow down receiver reports.) The
* receiver fraction must be 1 - the sender fraction.
*/
double const RTCP_SENDER_BW_FRACTION = 0.25;
double const RTCP_RCVR_BW_FRACTION = (1-RTCP_SENDER_BW_FRACTION);
/*
/* To compensate for "timer reconsideration" converging to a
* value below the intended average.
*/
double const COMPENSATION = 2.71828 - 1.5;
double rtcp_interval(int members, int senders, double rtcp_bw, int we_sent, double avg_rtcp_size, int initial) { /* * Minimum average time between RTCP packets from this site (in * seconds). This time prevents the reports from `clumping' when * sessions are small and the law of large numbers isn't helping * to smooth out the traffic. It also keeps the report interval * from becoming ridiculously small during transient outages like * a network partition. */ double const RTCP_MIN_TIME = 5.; /* * Fraction of the RTCP bandwidth to be shared among active * senders. (This fraction was chosen so that in a typical * session with one or two active senders, the computed report * time would be roughly equal to the minimum report time so that * we don't unnecessarily slow down receiver reports.) The * receiver fraction must be 1 - the sender fraction. */ double const RTCP_SENDER_BW_FRACTION = 0.25; double const RTCP_RCVR_BW_FRACTION = (1-RTCP_SENDER_BW_FRACTION); /* /* To compensate for "timer reconsideration" converging to a * value below the intended average. */ double const COMPENSATION = 2.71828 - 1.5;
double t; /* interval */
double rtcp_min_time = RTCP_MIN_TIME;
int n; /* no. of members for computation */
double t; /* interval */ double rtcp_min_time = RTCP_MIN_TIME; int n; /* no. of members for computation */
/*
* Very first call at application start-up uses half the min
* delay for quicker notification while still allowing some time
* before reporting for randomization and to learn about other
* sources so the report interval will converge to the correct
* interval more quickly.
/* * Very first call at application start-up uses half the min * delay for quicker notification while still allowing some time * before reporting for randomization and to learn about other * sources so the report interval will converge to the correct * interval more quickly.
Schulzrinne, et al. Standards Track [Page 89] RFC 3550 RTP July 2003
Schulzrinne, et al. Standards Track [Page 89] RFC 3550 RTP July 2003
*/
if (initial) {
rtcp_min_time /= 2;
}
/*
* Dedicate a fraction of the RTCP bandwidth to senders unless
* the number of senders is large enough that their share is
* more than that fraction.
*/
n = members;
if (senders <= members * RTCP_SENDER_BW_FRACTION) {
if (we_sent) {
rtcp_bw *= RTCP_SENDER_BW_FRACTION;
n = senders;
} else {
rtcp_bw *= RTCP_RCVR_BW_FRACTION;
n -= senders;
}
}
*/ if (initial) { rtcp_min_time /= 2; } /* * Dedicate a fraction of the RTCP bandwidth to senders unless * the number of senders is large enough that their share is * more than that fraction. */ n = members; if (senders <= members * RTCP_SENDER_BW_FRACTION) { if (we_sent) { rtcp_bw *= RTCP_SENDER_BW_FRACTION; n = senders; } else { rtcp_bw *= RTCP_RCVR_BW_FRACTION; n -= senders; } }
/*
* The effective number of sites times the average packet size is
* the total number of octets sent when each site sends a report.
* Dividing this by the effective bandwidth gives the time
* interval over which those packets must be sent in order to
* meet the bandwidth target, with a minimum enforced. In that
* time interval we send one report so this time is also our
* average time between reports.
*/
t = avg_rtcp_size * n / rtcp_bw;
if (t < rtcp_min_time) t = rtcp_min_time;
/* * The effective number of sites times the average packet size is * the total number of octets sent when each site sends a report. * Dividing this by the effective bandwidth gives the time * interval over which those packets must be sent in order to * meet the bandwidth target, with a minimum enforced. In that * time interval we send one report so this time is also our * average time between reports. */ t = avg_rtcp_size * n / rtcp_bw; if (t < rtcp_min_time) t = rtcp_min_time;
/*
* To avoid traffic bursts from unintended synchronization with
* other sites, we then pick our actual next report interval as a
* random number uniformly distributed between 0.5*t and 1.5*t.
*/
t = t * (drand48() + 0.5);
t = t / COMPENSATION;
return t;
}
/* * To avoid traffic bursts from unintended synchronization with * other sites, we then pick our actual next report interval as a * random number uniformly distributed between 0.5*t and 1.5*t. */ t = t * (drand48() + 0.5); t = t / COMPENSATION; return t; }
void OnExpire(event e,
int members,
int senders,
double rtcp_bw,
int we_sent,
double *avg_rtcp_size,
void OnExpire(event e, int members, int senders, double rtcp_bw, int we_sent, double *avg_rtcp_size,
Schulzrinne, et al. Standards Track [Page 90] RFC 3550 RTP July 2003
Schulzrinne, et al. Standards Track [Page 90] RFC 3550 RTP July 2003
int *initial,
time_tp tc,
time_tp *tp,
int *pmembers)
{
/* This function is responsible for deciding whether to send an
* RTCP report or BYE packet now, or to reschedule transmission.
* It is also responsible for updating the pmembers, initial, tp,
* and avg_rtcp_size state variables. This function should be
* called upon expiration of the event timer used by Schedule().
*/
int *initial, time_tp tc, time_tp *tp, int *pmembers) { /* This function is responsible for deciding whether to send an * RTCP report or BYE packet now, or to reschedule transmission. * It is also responsible for updating the pmembers, initial, tp, * and avg_rtcp_size state variables. This function should be * called upon expiration of the event timer used by Schedule(). */
double t; /* Interval */
double tn; /* Next transmit time */
double t; /* Interval */ double tn; /* Next transmit time */
/* In the case of a BYE, we use "timer reconsideration" to
* reschedule the transmission of the BYE if necessary */
/* In the case of a BYE, we use "timer reconsideration" to * reschedule the transmission of the BYE if necessary */
if (TypeOfEvent(e) == EVENT_BYE) {
t = rtcp_interval(members,
senders,
rtcp_bw,
we_sent,
*avg_rtcp_size,
*initial);
tn = *tp + t;
if (tn <= tc) {
SendBYEPacket(e);
exit(1);
} else {
Schedule(tn, e);
}
if (TypeOfEvent(e) == EVENT_BYE) { t = rtcp_interval(members, senders, rtcp_bw, we_sent, *avg_rtcp_size, *initial); tn = *tp + t; if (tn <= tc) { SendBYEPacket(e); exit(1); } else { Schedule(tn, e); }
} else if (TypeOfEvent(e) == EVENT_REPORT) {
t = rtcp_interval(members,
senders,
rtcp_bw,
we_sent,
*avg_rtcp_size,
*initial);
tn = *tp + t;
if (tn <= tc) {
SendRTCPReport(e);
*avg_rtcp_size = (1./16.)*SentPacketSize(e) +
(15./16.)*(*avg_rtcp_size);
*tp = tc;
} else if (TypeOfEvent(e) == EVENT_REPORT) { t = rtcp_interval(members, senders, rtcp_bw, we_sent, *avg_rtcp_size, *initial); tn = *tp + t; if (tn <= tc) { SendRTCPReport(e); *avg_rtcp_size = (1./16.)*SentPacketSize(e) + (15./16.)*(*avg_rtcp_size); *tp = tc;
/* We must redraw the interval. Don't reuse the
/* We must redraw the interval. Don't reuse the
Schulzrinne, et al. Standards Track [Page 91] RFC 3550 RTP July 2003
Schulzrinne, et al. Standards Track [Page 91] RFC 3550 RTP July 2003
one computed above, since its not actually
distributed the same, as we are conditioned
on it being small enough to cause a packet to
be sent */
one computed above, since its not actually distributed the same, as we are conditioned on it being small enough to cause a packet to be sent */
t = rtcp_interval(members,
senders,
rtcp_bw,
we_sent,
*avg_rtcp_size,
*initial);
t=rtcp_間隔、(_メンバー(送付者)が_bwをrtcpして、私たちが送られた*avg_rtcp_サイズである、*イニシャル)、。
Schedule(t+tc,e);
*initial = 0;
} else {
Schedule(tn, e);
}
*pmembers = members;
}
}
スケジュール(t+Tc、e)。 *=0に頭文字をつけてください。 ほか、スケジュール(tn、e)。 } *pmembersはメンバーと等しいです。 } }
void OnReceive(packet p,
event e,
int *members,
int *pmembers,
int *senders,
double *avg_rtcp_size,
double *tp,
double tc,
double tn)
{
/* What we do depends on whether we have left the group, and are
* waiting to send a BYE (TypeOfEvent(e) == EVENT_BYE) or an RTCP
* report. p represents the packet that was just received. */
OnReceiveを欠如させてください、(パケットp、出来事e、int*メンバー、int*pmembers(int*送付者)は*avg_rtcp_サイズを倍にします、二重*tp、二重Tc、二重tn)/. BYE(TypeOfEvent(e)=EVENT_BYE)をaに送るか、または. pが表すRTCP*レポートにただ受け取られたパケットを送るのを待つ*は、*私たちがすることが私たちが仲間から抜けたかどうかによって、*/です。
if (PacketType(p) == PACKET_RTCP_REPORT) {
if (NewMember(p) && (TypeOfEvent(e) == EVENT_REPORT)) {
AddMember(p);
*members += 1;
}
*avg_rtcp_size = (1./16.)*ReceivedPacketSize(p) +
(15./16.)*(*avg_rtcp_size);
} else if (PacketType(p) == PACKET_RTP) {
if (NewMember(p) && (TypeOfEvent(e) == EVENT_REPORT)) {
AddMember(p);
*members += 1;
}
if (NewSender(p) && (TypeOfEvent(e) == EVENT_REPORT)) {
(PACKET_RTCP_PacketType(p)=REPORT)である、(NewMember(p)、(TypeOfEvent(e)=EVENT_REPORT)) AddMember(p); *メンバー+=1;*avg_rtcp_サイズは(1./16)*ReceivedPacketSize(p)+(15./16)*(*avg_rtcp_サイズ)と等しいです;、ほか、(PacketType(p)=PACKET_RTP)である、(NewMember(p)、(TypeOfEvent(e)=EVENT_REPORT)AddMember(p)(*メンバー+=1)、(NewSender(p)、(TypeOfEvent(e)=EVENT_REPORT)
Schulzrinne, et al. Standards Track [Page 92] RFC 3550 RTP July 2003
Schulzrinne、他 規格はRTP2003年7月にRFC3550を追跡します[92ページ]。
AddSender(p);
*senders += 1;
}
} else if (PacketType(p) == PACKET_BYE) {
*avg_rtcp_size = (1./16.)*ReceivedPacketSize(p) +
(15./16.)*(*avg_rtcp_size);
AddSender(p)。 *送付者+=1。 } ほか、(PacketType(p)=PACKET_BYE)である、*avg_rtcp_サイズは(1./16)*ReceivedPacketSize(p)+(15./16)*(*avg_rtcp_サイズ)と等しいです。
if (TypeOfEvent(e) == EVENT_REPORT) {
if (NewSender(p) == FALSE) {
RemoveSender(p);
*senders -= 1;
}
(TypeOfEvent(e)=出来事_レポート)である、(NewSender(p)=偽)です。RemoveSender(p)(*送付者-=1)
if (NewMember(p) == FALSE) {
RemoveMember(p);
*members -= 1;
}
(NewMember(p)=偽)です。RemoveMember(p)(*メンバー-=1)
if (*members < *pmembers) {
tn = tc +
(((double) *members)/(*pmembers))*(tn - tc);
*tp = tc -
(((double) *members)/(*pmembers))*(tc - *tp);
{tn=Tc+(((二重)の*メンバー)/(*pmembers))*(tn--Tc); *tpはTcと等しいです--((二重)の*メンバー)/(*pmembers))という(*メンバー<*pmembers)*(Tc--*tp)であるなら。
/* Reschedule the next report for time tn */
/*は時間tn*/の次のレポートの時期変更します。
Reschedule(tn, e);
*pmembers = *members;
}
(tn、e)の時期変更してください。 *pmembersは*メンバーと等しいです。 }
} else if (TypeOfEvent(e) == EVENT_BYE) {
*members += 1;
}
}
}
ほか、(TypeOfEvent(e)=EVENT_BYE)である、*メンバー+=1。 } } }
Schulzrinne, et al. Standards Track [Page 93] RFC 3550 RTP July 2003
Schulzrinne、他 規格はRTP2003年7月にRFC3550を追跡します[93ページ]。
A.8 Estimating the Interarrival Jitter
Interarrivalジターを見積もっているA.8
The code fragments below implement the algorithm given in Section 6.4.1 for calculating an estimate of the statistical variance of the RTP data interarrival time to be inserted in the interarrival jitter field of reception reports. The inputs are r->ts, the timestamp from the incoming packet, and arrival, the current time in the same units. Here s points to state for the source; s->transit holds the relative transit time for the previous packet, and s->jitter holds the estimated jitter. The jitter field of the reception report is measured in timestamp units and expressed as an unsigned integer, but the jitter estimate is kept in a floating point. As each data packet arrives, the jitter estimate is updated:
コードは、レセプションレポートのinterarrivalジター分野に挿入されるのをRTPデータinterarrival時間の統計的な変化の見積りに計算するために道具の下でセクション6.4.1で与えられたアルゴリズムを断片化します。 入力がそうである、r->、t、入って来るパケットからのタイムスタンプ、および到着、同じユニットの現在の時間。 ここに、sは状態をソースに示します。 そして、相対的なトランジットが調節するs->が通過している船倉、前のパケットのためにs->、ジター、およそジターを保持します。 レセプションレポートのジター分野は、タイムスタンプユニットで測定されて、符号のない整数として言い表されますが、ジター見積りは浮動小数点で保たれます。 各データ・パケットが到着するとき、ジター見積りをアップデートします:
int transit = arrival - r->ts;
int d = transit - s->transit;
s->transit = transit;
if (d < 0) d = -d;
s->jitter += (1./16.) * ((double)d - s->jitter);
intトランジットは到着と等しいです--、r->、t、。 int dはトランジットと等しいです--s->は通過します。 s->が通過している=トランジット。 (d<0)dが-dと等しいなら。 s->、ジター、+ =(1./16) * (二重)のd--、s->、ジター、)、。
When a reception report block (to which rr points) is generated for this member, the current jitter estimate is returned:
このメンバーのために、レセプションレポートブロック(どのrrポイントへの)を発生させるかとき、現在のジター見積りを返します:
rr->jitter = (u_int32) s->jitter;
rr>のジター=(u_int32)、s->、ジター、。
Alternatively, the jitter estimate can be kept as an integer, but scaled to reduce round-off error. The calculation is the same except for the last line:
あるいはまた、ジター見積りを整数として保たれますが、ロンダード誤りを抑えるためにスケーリングできます。 最終ラインを除いて、計算は同じです:
s->jitter += d - ((s->jitter + 8) >> 4);
s->、ジター、+はdと等しいです--、(s->、ジター、+ 8)>>4)。
In this case, the estimate is sampled for the reception report as:
この場合、見積りはレセプションレポートのために以下として抽出されます。
rr->jitter = s->jitter >> 4;
rr>のジター=、s->、ジター、>>4。
Schulzrinne, et al. Standards Track [Page 94] RFC 3550 RTP July 2003
Schulzrinne、他 規格はRTP2003年7月にRFC3550を追跡します[94ページ]。
Appendix B - Changes from RFC 1889
付録B--RFC1889からの変化
Most of this RFC is identical to RFC 1889. There are no changes in the packet formats on the wire, only changes to the rules and algorithms governing how the protocol is used. The biggest change is an enhancement to the scalable timer algorithm for calculating when to send RTCP packets:
このRFCの大部分はRFC1889と同じです。 ワイヤのパケット・フォーマットにおける変化ではなく、規則とアルゴリズムへのプロトコルがどう使用されているかを治める変化しかありません。 最も大きい変化はいつパケットをRTCPに送るかを見込むためのスケーラブルなタイマアルゴリズムへの増進です:
o The algorithm for calculating the RTCP transmission interval
specified in Sections 6.2 and 6.3 and illustrated in Appendix A.7
is augmented to include "reconsideration" to minimize transmission
in excess of the intended rate when many participants join a
session simultaneously, and "reverse reconsideration" to reduce
the incidence and duration of false participant timeouts when the
number of participants drops rapidly. Reverse reconsideration is
also used to possibly shorten the delay before sending RTCP SR
when transitioning from passive receiver to active sender mode.
o 多くの関係者が関係者の数が急速に低下するときの誤った関与しているタイムアウトの発生と持続時間を減少させるために同時のセッション、および「逆の再考」に参加すると、セクション6.2と6.3で指定されて、Appendix A.7で例証されたRTCPトランスミッション間隔について計算するためのアルゴリズムは、意図しているレートを超えてトランスミッションを最小にするために「再考」を含むように増大します。 また、受け身の受信機からアクティブな送付者モードに移行するとき、逆の再考は、RTCP SRを送る前にことによると遅れを短くするのに使用されます。
o Section 6.3.7 specifies new rules controlling when an RTCP BYE
packet should be sent in order to avoid a flood of packets when
many participants leave a session simultaneously.
o セクション6.3 .7 RTCP BYEパケットがいつ多くの関係者が同時にセッションを残すとき、パケットの洪水を避けるために送られるべきであるかを制御する新しい規則を指定します。
o The requirement to retain state for inactive participants for a
period long enough to span typical network partitions was removed
from Section 6.2.1. In a session where many participants join for
a brief time and fail to send BYE, this requirement would cause a
significant overestimate of the number of participants. The
reconsideration algorithm added in this revision compensates for
the large number of new participants joining simultaneously when a
partition heals.
o しばらく典型的なネットワークパーティションにかかることができるくらいの長い間不活発な関係者のための状態を保有するという要件はセクション6.2.1から取り除かれました。 多くの関係者が簡潔な時間加わって、BYEを送らないセッションのときに、この要件は関係者の数の重要な過大評価を引き起こすでしょう。 この改正で加えられた再考アルゴリズムはパーティションが回復すると同時に加わる多くの新しい関係者を補います。
It should be noted that these enhancements only have a significant effect when the number of session participants is large (thousands) and most of the participants join or leave at the same time. This makes testing in a live network difficult. However, the algorithm was subjected to a thorough analysis and simulation to verify its performance. Furthermore, the enhanced algorithm was designed to interoperate with the algorithm in RFC 1889 such that the degree of reduction in excess RTCP bandwidth during a step join is proportional to the fraction of participants that implement the enhanced algorithm. Interoperation of the two algorithms has been verified experimentally on live networks.
これらの増進がセッション関係者の数が大きく重要な効果(数千)と関係者の大部分が同時に加わるか、またはいなくなるのをさせるだけであることに注意されるべきです。 これで、ライブネットワークでテストするのは難しくなります。 しかしながら、アルゴリズムは、性能について確かめるために徹底的な分析とシミュレーションにかけられました。 その上、高められたアルゴリズムはアルゴリズムがRFC1889にある状態で共同利用するように設計されていて、ステップの間の余分なRTCP帯域幅での減少の度合いが接合するようなものが高められたアルゴリズムを実行する関係者の部分に比例しているということでした。 2つのアルゴリズムのInteroperationはライブネットワークで実験的に確かめられました。
Other functional changes were:
他の機能的な変化は以下の通りでした。
o Section 6.2.1 specifies that implementations may store only a
sampling of the participants' SSRC identifiers to allow scaling to
very large sessions. Algorithms are specified in RFC 2762 [21].
o セクション6.2 .1 実現が非常に大きいセッションまで比例するのを許容するために関係者のSSRC識別子の標本抽出だけを格納するかもしれないと指定します。 アルゴリズムはRFC2762[21]で指定されます。
Schulzrinne, et al. Standards Track [Page 95] RFC 3550 RTP July 2003
Schulzrinne、他 規格はRTP2003年7月にRFC3550を追跡します[95ページ]。
o In Section 6.2 it is specified that RTCP sender and non-sender
bandwidths may be set as separate parameters of the session rather
than a strict percentage of the session bandwidth, and may be set
to zero. The requirement that RTCP was mandatory for RTP sessions
using IP multicast was relaxed. However, a clarification was also
added that turning off RTCP is NOT RECOMMENDED.
o セクション6.2では、RTCP送付者と非送付者帯域幅がセッション帯域幅の厳しい割合よりむしろセッションの別々のパラメタとして設定されて、ゼロに設定されるかもしれないと指定されます。 RTCPがIPマルチキャストを使用することでRTPセッションに義務的であったという要件はリラックスしました。 しかしながら、また、RTCPをオフにして、NOT RECOMMENDEDである明確化は加えられました。
o In Sections 6.2, 6.3.1 and Appendix A.7, it is specified that the
fraction of participants below which senders get dedicated RTCP
bandwidth changes from the fixed 1/4 to a ratio based on the RTCP
sender and non-sender bandwidth parameters when those are given.
The condition that no bandwidth is dedicated to senders when there
are no senders was removed since that is expected to be a
transitory state. It also keeps non-senders from using sender
RTCP bandwidth when that is not intended.
o セクション6.2、6.3の.1とAppendix A.7では、送付者が固定1/4対1比から専用RTCP帯域幅変化を届ける関係者の部分が、それらがいつ与えられるかをRTCP送付者と非送付者帯域幅パラメタに基礎づけたと指定されます。 それが一時的な状態であると予想されるので、送付者が全くいないとき、帯域幅が全く送付者に捧げられないという条件は取り除かれました。 それによって、また、それが意図しないとき、非送付者は送付者RTCP帯域幅を使用できません。
o Also in Section 6.2 it is specified that the minimum RTCP interval
may be scaled to smaller values for high bandwidth sessions, and
that the initial RTCP delay may be set to zero for unicast
sessions.
o セクション6.2でも、最小のRTCP間隔が高帯域セッションの間、より小さい値に合わせて調整されるかもしれなくて、初期のRTCP遅れがユニキャストセッションのためにゼロに設定されるかもしれないと指定されます。
o Timing out a participant is to be based on inactivity for a number
of RTCP report intervals calculated using the receiver RTCP
bandwidth fraction even for active senders.
o 関係者からのタイミングは活発な送付者にさえ受信機RTCP帯域幅断片を使用することで計算された多くのRTCPレポート間隔の間、不活発に基づくことです。
o Sections 7.2 and 7.3 specify that translators and mixers should
send BYE packets for the sources they are no longer forwarding.
o セクション7.2と7.3は、翻訳者とミキサーが彼らがもう転送していないソースのためにパケットをBYEに送るはずであると指定します。
o Rule changes for layered encodings are defined in Sections 2.4,
6.3.9, 8.3 and 11. In the last of these, it is noted that the
address and port assignment rule conflicts with the SDP
specification, RFC 2327 [15], but it is intended that this
restriction will be relaxed in a revision of RFC 2327.
o 層にされたencodingsのためのルール改正はセクション2.4、6.3.9、8.3、および11で定義されます。 これらの最終では、アドレスとポート課題がSDP仕様との闘争を統治すると述べられます、RFC2327[15]にもかかわらず、この規制がRFC2327の改正で緩和されることを意図します。
o The convention for using even/odd port pairs for RTP and RTCP in
Section 11 was clarified to refer to destination ports. The
requirement to use an even/odd port pair was removed if the two
ports are specified explicitly. For unicast RTP sessions,
distinct port pairs may be used for the two ends (Sections 3, 7.1
and 11).
o RTPとRTCPにセクション11で同等の、または、変なポート組を使用するためのコンベンションは、仕向港について言及するためにはっきりさせられました。 2つのポートが明らかに指定されるなら、同等の、または、変なポート組を使用するという要件は取り除かれました。 ユニキャストRTPセッションのために、異なったポート組は2つの終わり(セクション3、7.1、および11)の間、使用されるかもしれません。
o A new Section 10 was added to explain the requirement for
congestion control in applications using RTP.
o 新しいセクション10は、RTPを使用することでアプリケーションにおける輻輳制御のための要件について説明するために加えられました。
o In Section 8.2, the requirement that a new SSRC identifier MUST be
chosen whenever the source transport address is changed has been
relaxed to say that a new SSRC identifier MAY be chosen.
Correspondingly, it was clarified that an implementation MAY
o セクション8.2では、ソース輸送アドレスを変えるときはいつも、新しいSSRC識別子を選ばなければならないという要件は、新しいSSRC識別子が選ばれるかもしれないと言うためにリラックスしました。 それが対応する、はっきりさせられた、実現はそうします。
Schulzrinne, et al. Standards Track [Page 96] RFC 3550 RTP July 2003
Schulzrinne、他 規格はRTP2003年7月にRFC3550を追跡します[96ページ]。
choose to keep packets from the new source address rather than the
existing source address when an SSRC collision occurs between two
other participants, and SHOULD do so for applications such as
telephony in which some sources such as mobile entities may change
addresses during the course of an RTP session.
SSRC衝突が他の2人の関係者の間に起こるときには既存のソースアドレスよりむしろ新しいソースアドレスからパケットを妨げるのを選んでください。そうすれば、SHOULDは可動の実体などの何人かの源がRTPセッションのコースの間にアドレスを変えるかもしれない電話などのアプリケーションのためにそうします。
o An indentation bug in the RFC 1889 printing of the pseudo-code for
the collision detection and resolution algorithm in Section 8.2
has been corrected by translating the syntax to pseudo C language,
and the algorithm has been modified to remove the restriction that
both RTP and RTCP must be sent from the same source port number.
o 疑似C言語に構文を翻訳することによって、セクション8.2の衝突検出と解決アルゴリズムのための中間コードのRFC1889印刷の刻み目の欠陥を修正してあります、そして、アルゴリズムは同じソースポートナンバーからRTPとRTCPの両方を送らなければならないという制限を取り除くように変更されました。
o The description of the padding mechanism for RTCP packets was
clarified and it is specified that padding MUST only be applied to
the last packet of a compound RTCP packet.
o RTCPパケットのための詰め物メカニズムの記述ははっきりさせられました、そして、合成RTCPパケットの最後のパケットに詰め物を適用するだけでよいと指定されます。
o In Section A.1, initialization of base_seq was corrected to be seq
rather than seq - 1, and the text was corrected to say the bad
sequence number plus 1 is stored. The initialization of max_seq
and other variables for the algorithm was separated from the text
to make clear that this initialization must be done in addition to
calling the init_seq() function (and a few words lost in RFC 1889
when processing the document from source to output form were
restored).
o ベース_seqの初期化はseqよりむしろseqになるように修正されました--セクションA.1では、1、およびテキストはそうでした。悪い一連番号と1が格納されると言うために、修正されます。 アルゴリズムのための最大_seqと他の変数の初期化は、イニット_seq()機能を呼ぶことに加えてこの初期化をしなければならないことを明らかにするためにテキストと切り離されました(いくつかの単語がフォームを出力するためにソースから文書を処理するのが回復したRFC1889年に失われました)。
o Clamping of number of packets lost in Section A.3 was corrected to
use both positive and negative limits.
o セクションA.3で失われたパケットの数の固定は、積極的なものと同様に否定的な限界を使用するために修正されました。
o The specification of "relative" NTP timestamp in the RTCP SR
section now defines these timestamps to be based on the most
common system-specific clock, such as system uptime, rather than
on session elapsed time which would not be the same for multiple
applications started on the same machine at different times.
o RTCP SR部の「相対的な」NTPタイムスタンプの仕様は現在最も一般的なシステム特有の時計に基づくようにこれらのタイムスタンプを定義します、いろいろな時間に同じマシンに始められた複数のアプリケーションには、同じでないセッション経過時間にというよりむしろシステム・アップタイムなどのように。
Non-functional changes:
非機能的な変化:
o It is specified that a receiver MUST ignore packets with payload
types it does not understand.
o 受信機がそれが理解していないペイロードタイプがあるパケットを無視しなければならないと指定されます。
o In Fig. 2, the floating point NTP timestamp value was corrected,
some missing leading zeros were added in a hex number, and the UTC
timezone was specified.
o 図2では、浮動小数点NTPタイムスタンプ価値は修正されました、そして、いくつかのなくなった先行ゼロが十六進法番号で加えられました、そして、UTCタイムゾーンは指定されました。
o The inconsequence of NTP timestamps wrapping around in the year
2036 is explained.
o 2036年の間に巻きつけられるNTPタイムスタンプの不合理は説明されます。
Schulzrinne, et al. Standards Track [Page 97] RFC 3550 RTP July 2003
Schulzrinne、他 規格はRTP2003年7月にRFC3550を追跡します[97ページ]。
o The policy for registration of RTCP packet types and SDES types
was clarified in a new Section 15, IANA Considerations. The
suggestion that experimenters register the numbers they need and
then unregister those which prove to be unneeded has been removed
in favor of using APP and PRIV. Registration of profile names was
also specified.
o IANA Considerations、RTCPパケットタイプとSDESタイプの登録のための方針は新しいセクション15ではっきりさせられました。 実験者はAPPとPRIVを使用することを支持して取り除いた状態で彼らが必要とする数を示して、次に、不要であると判明するものが「非-レジスタ」であったのを示すという提案。 また、プロフィール名の登録は指定されました。
o The reference for the UTF-8 character set was changed from an
X/Open Preliminary Specification to be RFC 2279.
o RFC2279になるようにX/Open Preliminary SpecificationからUTF-8文字の組の参照を変えました。
o The reference for RFC 1597 was updated to RFC 1918 and the
reference for RFC 2543 was updated to RFC 3261.
o RFC1597の参照をRFC1918にアップデートしました、そして、RFC2543の参照をRFC3261にアップデートしました。
o The last paragraph of the introduction in RFC 1889, which
cautioned implementors to limit deployment in the Internet, was
removed because it was deemed no longer relevant.
o それがもう関連しているのは考えられなかったので、作成者がインターネットで展開を制限すると警告したRFC1889の序論の最後のパラグラフを取り除きました。
o A non-normative note regarding the use of RTP with Source-Specific
Multicast (SSM) was added in Section 6.
o Source特有のMulticast(SSM)とのRTPの使用に関する非標準の注はセクション6で加えられました。
o The definition of "RTP session" in Section 3 was expanded to
acknowledge that a single session may use multiple destination
transport addresses (as was always the case for a translator or
mixer) and to explain that the distinguishing feature of an RTP
session is that each corresponds to a separate SSRC identifier
space. A new definition of "multimedia session" was added to
reduce confusion about the word "session".
o セクション3との「RTPセッション」の定義は、ただ一つのセッションが複数の送付先輸送アドレス(翻訳者かミキサーのためのいつもケースのような)を使用するかもしれないと認めて、RTPセッションの区別の特徴がそれぞれが別々のSSRC識別子スペースに対応しているということであると説明するために広げられました。 「マルチメディアセッション」の新しい定義は、「セッション」という言葉に関して混乱を抑えるために加えられました。
o The meaning of "sampling instant" was explained in more detail as
part of the definition of the timestamp field of the RTP header in
Section 5.1.
o 「瞬間を抽出します」の意味はさらに詳細にセクション5.1とのRTPヘッダーのタイムスタンプ分野の定義の一部として説明されました。
o Small clarifications of the text have been made in several places,
some in response to questions from readers. In particular:
o 処々方々、読者からの質問に対応したいくつかでテキストの小さい明確化をしました。 特に:
- In RFC 1889, the first five words of the second sentence of
Section 2.2 were lost in processing the document from source to
output form, but are now restored.
- RFC1889では、セクション2.2に関する2番目の文の最初の5つの単語が、フォームを出力するためにソースから文書を処理する際に失われましたが、現在、回復します。
- A definition for "RTP media type" was added in Section 3 to
allow the explanation of multiplexing RTP sessions in Section
5.2 to be more clear regarding the multiplexing of multiple
media. That section also now explains that multiplexing
multiple sources of the same medium based on SSRC identifiers
may be appropriate and is the norm for multicast sessions.
- 「RTPメディアはタイプする」定義が、セクション5.2における、マルチプレクシングRTPセッションの説明がマルチメディアのマルチプレクシングに関して、より明確であることを許容するためにセクション3で加えられました。 また、そのセクションは現在、SSRC識別子に基づく同じ媒体の複数の源を多重送信するのが、適切であるかもしれなく、マルチキャストセッションのための標準であると説明します。
- The definition for "non-RTP means" was expanded to include
examples of other protocols constituting non-RTP means.
- 「非RTP手段」のための定義は、非RTP手段を構成する他のプロトコルに関する例を含むように広げられました。
Schulzrinne, et al. Standards Track [Page 98] RFC 3550 RTP July 2003
Schulzrinne、他 規格はRTP2003年7月にRFC3550を追跡します[98ページ]。
- The description of the session bandwidth parameter is expanded
in Section 6.2, including a clarification that the control
traffic bandwidth is in addition to the session bandwidth for
the data traffic.
- セッション帯域幅パラメタの記述はセクション6.2で広げられます、コントロール交通帯域幅がデータ通信量へのセッション帯域幅に加えている明確化を含んでいて。
- The effect of varying packet duration on the jitter calculation
was explained in Section 6.4.4.
- パケット持続時間を変えるというジター計算への効果はセクション6.4.4で説明されました。
- The method for terminating and padding a sequence of SDES items
was clarified in Section 6.5.
- SDESの品目の系列を終えて、水増しするための方法はセクション6.5ではっきりさせられました。
- IPv6 address examples were added in the description of SDES
CNAME in Section 6.5.1, and "example.com" was used in place of
other example domain names.
- IPv6アドレスの例はセクション6.5.1における、SDES CNAMEの記述で加えられました、そして、"example.com"は他の例のドメイン名に代わって使用されました。
- The Security section added a formal reference to IPSEC now that
it is available, and says that the confidentiality method
defined in this specification is primarily to codify existing
practice. It is RECOMMENDED that stronger encryption
algorithms such as Triple-DES be used in place of the default
algorithm, and noted that the SRTP profile based on AES will be
the correct choice in the future. A caution about the weakness
of the RTP header as an initialization vector was added. It
was also noted that payload-only encryption is necessary to
allow for header compression.
- Security部は、それが利用可能であるのでIPSECの正式な参照を言い足して、この仕様に基づき定義された秘密性方法が主として既存の習慣を成文化することであると言います。 Triple-DESなどの、より強い暗号化アルゴリズムがデフォルトアルゴリズムに代わって使用されるのが、RECOMMENDEDであり、注意されて、将来、SRTPプロフィールがAESを基礎づけたのは、正しい選択でしょう。 初期化ベクトルとしてのRTPヘッダーの弱点に関する警告は加えられました。 また、ペイロードだけ暗号化がヘッダー圧縮を考慮するのに必要であることに注意されました。
- The method for partial encryption of RTCP was clarified; in
particular, SDES CNAME is carried in only one part when the
compound RTCP packet is split.
- RTCPの部分的な暗号化のための方法ははっきりさせられました。 合成RTCPパケットが分けられるとき、特に、SDES CNAMEは一部だけで運ばれます。
- It is clarified that only one compound RTCP packet should be
sent per reporting interval and that if there are too many
active sources for the reports to fit in the MTU, then a subset
of the sources should be selected round-robin over multiple
intervals.
- はっきりさせられて、間隔を報告する単位でその1個の化合物だけのRTCPパケットを送るべきであり、レポートがMTUをうまくはめ込むようにあまりに多くの活発なソースがあればソースの部分集合が複数の間隔にわたって選択された連続であるということです。
- A note was added in Appendix A.1 that packets may be saved
during RTP header validation and delivered upon success.
- 注意はパケットがRTPヘッダー合法化の間、救われて、成功で渡されるかもしれないAppendix A.1で加えられました。
- Section 7.3 now explains that a mixer aggregating SDES packets
uses more RTCP bandwidth due to longer packets, and a mixer
passing through RTCP naturally sends packets at higher than the
single source rate, but both behaviors are valid.
- セクション7.3は、現在SDESパケットに集められるミキサーが、より長いパケットによる、より多くのRTCP帯域幅を使用すると説明します、そして、自然にRTCPを通り抜けるミキサーはただ一つのソースレートより高いところでパケットを送りますが、両方の振舞いは有効です。
- Section 13 clarifies that an RTP application may use multiple
profiles but typically only one in a given session.
- セクション13ははっきりさせられます。RTPアプリケーションは与えられたセッションのときに複数のプロフィールにもかかわらず、通常1つだけを使用するかもしれません。
Schulzrinne, et al. Standards Track [Page 99] RFC 3550 RTP July 2003
Schulzrinne、他 規格はRTP2003年7月にRFC3550を追跡します[99ページ]。
- The terms MUST, SHOULD, MAY, etc. are used as defined in RFC
2119.
- 用語が使用しなければならない、SHOULD、5月などはRFC2119で定義されるように使用されています。
- The bibliography was divided into normative and informative
references.
- 図書目録は規範的で有益な参照に分割されました。
References
参照
Normative References
引用規格
[1] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
Conferences with Minimal Control", RFC 3551, July 2003.
[1]SchulzrinneとH.とS.Casner、「最小量のコントロールがあるオーディオとテレビ会議システムのためのRTPプロフィール」、RFC3551、2003年7月。
[2] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] ブラドナー、S.、「使用のための要件レベルを示すRFCsのキーワード」、BCP14、RFC2119、1997年3月。
[3] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[3] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、1981年9月。
[4] Mills, D., "Network Time Protocol (Version 3) Specification,
Implementation and Analysis", RFC 1305, March 1992.
[4] 工場、D.、「ネットワーク時間は仕様、実現、および分析について議定書の中で述べ(バージョン3)」RFC1305、1992年3月。
[5] Yergeau, F., "UTF-8, a Transformation Format of ISO 10646", RFC
2279, January 1998.
[5]Yergeau、1998年1月のF.、「UTF-8、ISO10646の変化形式」RFC2279。
[6] Mockapetris, P., "Domain Names - Concepts and Facilities", STD
13, RFC 1034, November 1987.
[6]Mockapetris、P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、11月1987日
[7] Mockapetris, P., "Domain Names - Implementation and
Specification", STD 13, RFC 1035, November 1987.
[7]Mockapetris、P.、「ドメイン名--、実現と仕様、」、STD13、RFC1035、11月1987日
[8] Braden, R., "Requirements for Internet Hosts - Application and
Support", STD 3, RFC 1123, October 1989.
[8] ブレーデン、R.、「インターネットホストのための要件--、アプリケーションとサポート、」、STD3、RFC1123、10月1989日
[9] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[9] レズニック、P.、「インターネットメッセージ・フォーマット」、RFC2822、2001年4月。
Informative References
有益な参照
[10] Clark, D. and D. Tennenhouse, "Architectural Considerations for
a New Generation of Protocols," in SIGCOMM Symposium on
Communications Architectures and Protocols , (Philadelphia,
Pennsylvania), pp. 200--208, IEEE Computer Communications
Review, Vol. 20(4), September 1990.
[10] クラークとD.とD.Tennenhouse、Communications ArchitecturesとプロトコルのSIGCOMM Symposium、(フィラデルフィア(ペンシルバニア))、ページの「プロトコルの新しい世代建築問題」 200--208 IEEEコンピュータコミュニケーションレビュー、Vol.20(4)、1990年9月。
[11] Schulzrinne, H., "Issues in designing a transport protocol for
audio and video conferences and other multiparticipant real-time
applications." expired Internet Draft, October 1993.
[11] Schulzrinne(H.)は. 満期のインターネットDraft(1993年10月)を「オーディオ、テレビ会議システム、および他の「マルチ-関係者」のリアルタイムのアプリケーションのためのトランスポート・プロトコルを設計する際に、発行します」。
Schulzrinne, et al. Standards Track [Page 100] RFC 3550 RTP July 2003
Schulzrinne、他 規格はRTP2003年7月にRFC3550を追跡します[100ページ]。
[12] Comer, D., Internetworking with TCP/IP , vol. 1. Englewood
Cliffs, New Jersey: Prentice Hall, 1991.
[12] 新来者、D.、TCP/IP、vol.1とInternetworking。 イングルウッドがけ、ニュージャージー: 新米のホール、1991。
[13] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[13] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
[14] International Telecommunication Union, "Visual telephone systems
and equipment for local area networks which provide a non-
guaranteed quality of service", Recommendation H.323,
Telecommunication Standardization Sector of ITU, Geneva,
Switzerland, July 2003.
[14] 国際電気通信連合、「展示は非保証されたサービスの質を提供するローカル・エリア・ネットワークのためにシステムと設備に電話をします」、Recommendation H.323、ITUのTelecommunication Standardization Sector、ジュネーブ(スイス)2003年7月。
[15] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[15] ハンドレー、M.、およびV.ジェーコブソン、「SDP:」 「セッション記述プロトコル」、RFC2327、1998年4月。
[16] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming
Protocol (RTSP)", RFC 2326, April 1998.
[16]SchulzrinneとH.とラオとA.とR.Lanphier、「リアルタイムのストリーミングのプロトコル(RTSP)」、RFC2326 1998年4月。
[17] Eastlake 3rd, D., Crocker, S. and J. Schiller, "Randomness
Recommendations for Security", RFC 1750, December 1994.
[17] イーストレーク3番目とD.とクロッカーとS.とJ.シラー、「セキュリティのための偶発性推薦」、RFC1750、1994年12月。
[18] Bolot, J.-C., Turletti, T. and I. Wakeman, "Scalable Feedback
Control for Multicast Video Distribution in the Internet", in
SIGCOMM Symposium on Communications Architectures and Protocols,
(London, England), pp. 58--67, ACM, August 1994.
Communications ArchitecturesとプロトコルのSIGCOMM Symposium、(ロンドン(イギリス))、ページにおける[18]BolotとJ.-C.とTurlettiとT.とI.ウェイクマン、「インターネットでのマルチキャストビデオ分配のためのスケーラブルなフィードバック制御」 58--67 1994年8月のACM。
[19] Busse, I., Deffner, B. and H. Schulzrinne, "Dynamic QoS Control
of Multimedia Applications Based on RTP", Computer
Communications , vol. 19, pp. 49--58, January 1996.
[19] Busse、I.、Deffner、B.、およびH.Schulzrinne、「マルチメディア応用のダイナミックなQoSコントロールはRTPを基礎づけました」、コンピュータCommunications、vol.19、ページ 49--58と、1996年1月。
[20] Floyd, S. and V. Jacobson, "The Synchronization of Periodic
Routing Messages", in SIGCOMM Symposium on Communications
Architectures and Protocols (D. P. Sidhu, ed.), (San Francisco,
California), pp. 33--44, ACM, September 1993. Also in [34].
[20] フロイドとS.とV.ジェーコブソン、Communications Architecturesとプロトコル(D.P.Sidhu(教育))のSIGCOMM Symposium、(サンフランシスコ(カリフォルニア))、ページにおける「周期的なルーティング・メッセージの同期」 33--44 1993年9月のACM。 [34]でも。
[21] Rosenberg, J. and H. Schulzrinne, "Sampling of the Group
Membership in RTP", RFC 2762, February 2000.
[21] ローゼンバーグとJ.とH.Schulzrinne、「RTPのグループ会員資格の標本抽出」、RFC2762、2000年2月。
[22] Cadzow, J., Foundations of Digital Signal Processing and Data
Analysis New York, New York: Macmillan, 1987.
[22]CadzowとJ.とデジタル信号処理の財団とデータ分析ニューヨーク(ニューヨーク): マクミラン、1987。
[23] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
Addressing Architecture", RFC 3513, April 2003.
[23]HindenとR.とS.デアリング、「インターネットプロトコルバージョン6(IPv6)アドレッシング体系」、RFC3513、2003年4月。
[24] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. and E.
Lear, "Address Allocation for Private Internets", RFC 1918,
February 1996.
[24] Rekhter(Y.、マスコウィッツ、B.、Karrenberg、D.、deグルート、G.、およびE.リア)は「個人的なインターネットのための配分を記述します」、RFC1918、1996年2月。
Schulzrinne, et al. Standards Track [Page 101] RFC 3550 RTP July 2003
Schulzrinne、他 規格はRTP2003年7月にRFC3550を追跡します[101ページ]。
[25] Lear, E., Fair, E., Crocker, D. and T. Kessler, "Network 10
Considered Harmful (Some Practices Shouldn't be Codified)", RFC
1627, July 1994.
[25] リア、E.、Fair、E.、クロッカー、D.、およびT.ケスラー、「ネットワーク10Considered Harmful、(いくらかのPractices Shouldn、Codifiedでない、)、」、RFC1627(1994年7月)
[26] Feller, W., An Introduction to Probability Theory and its
Applications, vol. 1. New York, New York: John Wiley and Sons,
third ed., 1968.
[26] 奴、W.、Probability TheoryとそのApplicationsへのAn Introduction、vol.1。 ニューヨーク(ニューヨーク): 3番目のジョン・ワイリーとソンス、教育、1968
[27] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[27] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
[28] Baugher, M., Blom, R., Carrara, E., McGrew, D., Naslund, M.,
Norrman, K. and D. Oran, "Secure Real-time Transport Protocol",
Work in Progress, April 2003.
[28] 「安全なリアルタイムのトランスポート・プロトコル」というBaugher、M.、ブロム、R.、カラーラ、E.、マグリュー、D.、ジーター、M.、Norrman、K.、およびD.オランは進行中(2003年4月)で働いています。
[29] Balenson, D., "Privacy Enhancement for Internet Electronic Mail:
Part III", RFC 1423, February 1993.
[29]Balenson、D.、「インターネット電子メールのためのプライバシー増進:」 「パートIII」、RFC1423、1993年2月。
[30] Voydock, V. and S. Kent, "Security Mechanisms in High-Level
Network Protocols", ACM Computing Surveys, vol. 15, pp. 135-171,
June 1983.
[30]VoydockとV.とS.ケント、「ハイレベル・ネットワークプロトコルのセキュリティー対策」、ACM Computing Surveys、vol.15、ページ 135-171と、1983年6月。
[31] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914,
September 2000.
[31] フロイド、S.、「輻輳制御プリンシプルズ」、BCP41、RFC2914、2000年9月。
[32] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
1992.
[32] 1992年4月、最もRivestなR.、「MD5メッセージダイジェストアルゴリズム」RFC1321。
[33] Stubblebine, S., "Security Services for Multimedia
Conferencing", in 16th National Computer Security Conference,
(Baltimore, Maryland), pp. 391--395, September 1993.
[33]Stubblebine、S.、第16NationalコンピュータSecurityコンファレンス、(ボルチモア(メリーランド))、ページにおける「マルチメディア会議のためのセキュリティー・サービス」 391--395と、1993年9月。
[34] Floyd, S. and V. Jacobson, "The Synchronization of Periodic
Routing Messages", IEEE/ACM Transactions on Networking, vol. 2,
pp. 122--136, April 1994.
[34] フロイドとS.とV.ジェーコブソン、「周期的なルーティング・メッセージの同期」、Networking、vol.2、ページのIEEE/ACM Transactions 122--136と、1994年4月。
Schulzrinne, et al. Standards Track [Page 102] RFC 3550 RTP July 2003
Schulzrinne、他 規格はRTP2003年7月にRFC3550を追跡します[102ページ]。
Authors' Addresses
作者のアドレス
Henning Schulzrinne Department of Computer Science Columbia University 1214 Amsterdam Avenue New York, NY 10027 United States
ヘニングSchulzrinneコンピュータサイエンス学部コロンビア大学1214アムステルダムAvenueニューヨーク10027ニューヨーク(合衆国)
EMail: schulzrinne@cs.columbia.edu
メール: schulzrinne@cs.columbia.edu
Stephen L. Casner Packet Design 3400 Hillview Avenue, Building 3 Palo Alto, CA 94304 United States
スティーブンL.CasnerパケットDesign3400Hillviewアベニュー、Building3パロアルト、カリフォルニア94304合衆国
EMail: casner@acm.org
メール: casner@acm.org
Ron Frederick Blue Coat Systems Inc. 650 Almanor Avenue Sunnyvale, CA 94085 United States
ロンフレディリック青いコートSystems株式会社650Almanor Avenueサニーベル(カリフォルニア)94085合衆国
EMail: ronf@bluecoat.com
メール: ronf@bluecoat.com
Van Jacobson Packet Design 3400 Hillview Avenue, Building 3 Palo Alto, CA 94304 United States
ヴァンジェーコブソンパケットDesign3400Hillviewアベニュー、Building3パロアルト、カリフォルニア94304合衆国
EMail: van@packetdesign.com
メール: van@packetdesign.com
Schulzrinne, et al. Standards Track [Page 103] RFC 3550 RTP July 2003
Schulzrinne、他 規格はRTP2003年7月にRFC3550を追跡します[103ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Schulzrinne, et al. Standards Track [Page 104]
Schulzrinne、他 標準化過程[104ページ]
一覧
スポンサーリンク
