RFC1889 日本語訳
1889 RTP: A Transport Protocol for Real-Time Applications. Audio-VideoTransport Working Group, H. Schulzrinne, S. Casner, R. Frederick, V.Jacobson. January 1996. (Format: TXT=188544 bytes) (Obsoleted by RFC3550) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group Audio-Video Transport Working Group
Request for Comments: 1889 H. Schulzrinne
Category: Standards Track GMD Fokus
S. Casner
Precept Software, Inc.
R. Frederick
Xerox Palo Alto Research Center
V. Jacobson
Lawrence Berkeley National Laboratory
January 1996
コメントを求めるワーキンググループオーディオのビデオ輸送ワーキンググループ要求をネットワークでつないでください: 1889時間Schulzrinneカテゴリ: 研究所1996年1月の国家の標準化過程のゼロックスパロアルト研究センターV.ジェーコブソン・ローレンス・GMD Fokus S.Casner Precept Software Inc.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)の現行版を参照してください。 このメモの分配は無制限です。
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-レベル翻訳者とミキサーの使用をサポートします。
Table of Contents
目次
1. Introduction ........................................ 3 2. RTP Use Scenarios ................................... 5 2.1 Simple Multicast Audio Conference ................... 5 2.2 Audio and Video Conference .......................... 6 2.3 Mixers and Translators .............................. 6 3. Definitions ......................................... 7 4. Byte Order, Alignment, and Time Format .............. 9 5. RTP Data Transfer Protocol .......................... 10 5.1 RTP Fixed Header Fields ............................. 10 5.2 Multiplexing RTP Sessions ........................... 13
1. 序論… 3 2. RTPはシナリオを使用します… 5 2.1の簡単なマルチキャストオーディオコンファレンス… 5 2.2のオーディオとテレビ会議システム… 6 2.3人のミキサーと翻訳者… 6 3. 定義… 7 4. バイトオーダー、整列、および時間形式… 9 5. RTPデータ転送プロトコル… 10 5.1 RTPはヘッダーフィールドを修理しました… 10 5.2 マルチプレクシングRTPセッション… 13
Schulzrinne, et al Standards Track [Page 1] RFC 1889 RTP January 1996
Schulzrinne、他Standards Track[1ページ]RFC1889RTP1996年1月
5.3 Profile-Specific Modifications to the RTP Header..... 14
5.3.1 RTP Header Extension ................................ 14
6. RTP Control Protocol -- RTCP ........................ 15
6.1 RTCP Packet Format .................................. 17
6.2 RTCP Transmission Interval .......................... 19
6.2.1 Maintaining the number of session members ........... 21
6.2.2 Allocation of source description bandwidth .......... 21
6.3 Sender and Receiver Reports ......................... 22
6.3.1 SR: Sender report RTCP packet ....................... 23
6.3.2 RR: Receiver report RTCP packet ..................... 28
6.3.3 Extending the sender and receiver reports ........... 29
6.3.4 Analyzing sender and receiver reports ............... 29
6.4 SDES: Source description RTCP packet ................ 31
6.4.1 CNAME: Canonical end-point identifier SDES item ..... 32
6.4.2 NAME: User name SDES item ........................... 34
6.4.3 EMAIL: Electronic mail address SDES item ............ 34
6.4.4 PHONE: Phone number SDES item ....................... 34
6.4.5 LOC: Geographic user location SDES item ............. 35
6.4.6 TOOL: Application or tool name SDES item ............ 35
6.4.7 NOTE: Notice/status SDES item ....................... 35
6.4.8 PRIV: Private extensions SDES item .................. 36
6.5 BYE: Goodbye RTCP packet ............................ 37
6.6 APP: Application-defined RTCP packet ................ 38
7. RTP Translators and Mixers .......................... 39
7.1 General Description ................................. 39
7.2 RTCP Processing in Translators ...................... 41
7.3 RTCP Processing in Mixers ........................... 43
7.4 Cascaded Mixers ..................................... 44
8. SSRC Identifier Allocation and Use .................. 44
8.1 Probability of Collision ............................ 44
8.2 Collision Resolution and Loop Detection ............. 45
9. Security ............................................ 49
9.1 Confidentiality ..................................... 49
9.2 Authentication and Message Integrity ................ 50
10. RTP over Network and Transport Protocols ............ 51
11. Summary of Protocol Constants ....................... 51
11.1 RTCP packet types ................................... 52
11.2 SDES types .......................................... 52
12. RTP Profiles and Payload Format Specifications ...... 53
A. Algorithms .......................................... 56
A.1 RTP Data Header Validity Checks ..................... 59
A.2 RTCP Header Validity Checks ......................... 63
A.3 Determining the Number of RTP Packets Expected and
Lost ................................................ 63
A.4 Generating SDES RTCP Packets ........................ 64
A.5 Parsing RTCP SDES Packets ........................... 65
A.6 Generating a Random 32-bit Identifier ............... 66
A.7 Computing the RTCP Transmission Interval ............ 68
5.3 RTPヘッダーへのプロフィール特有の変更… 14 5.3 .1 RTPヘッダー拡張子… 14 6. RTPはプロトコルを制御します--RTCP 15 6.1 RTCPパケット・フォーマット… 17 6.2RTCPトランスミッション間隔… 19 6.2 .1 セッションメンバーの数を維持します… 21 6.2 .2 ソース記述帯域幅の配分… 21 6.3 送付者と受信機レポート… 22 6.3 .1SR: 送付者レポートRTCPパケット… 23 6.3 .2RR: 受信機レポートRTCPパケット… 28 6.3 .3 送付者と受信機を広げるのは報告します… 29 6.3 .4 送付者と受信機を分析するのは報告します… 29 6.4SDES: ソース記述RTCPパケット… 31 6.4 .1CNAME: 正準なエンドポイント識別子SDESの品目… 32 6.4 .2名: ユーザ名前SDESの品目… 34 6.4 .3 メール: 電子メールアドレスSDESの品目… 34 6.4 .4 電話: 電話番号SDESの品目… 34 6.4 .5LOC: 地理的なユーザ位置のSDESの品目… 35 6.4 .6ツール: アプリケーションかツール名前SDESの品目… 35 6.4 .7注意: 通知/状態SDESの品目… 35 6.4 .8PRIV: 個人的な拡大SDESの品目… 36 6.5 さようなら: さようならのRTCPパケット… 37 6.6装置: アプリケーションで定義されたRTCPパケット… 38 7. RTP翻訳者とミキサー… 39 7.1 一般記述… 39 7.2 翻訳者でのRTCP処理… 41 7.3 ミキサーでのRTCP処理… 43 7.4はミキサーをどっと落させました… 44 8. SSRC識別子配分と使用… 44 8.1 衝突の確率… 44 8.2衝突解決と輪の検出… 45 9. セキュリティ… 49 9.1秘密性… 49 9.2の認証とメッセージの保全… 50 10. ネットワークとトランスポート・プロトコルの上のRTP… 51 11. プロトコル定数の概要… 51 11.1RTCPパケットはタイプされます… 52 11.2SDESがタイプします… 52 12. RTPプロフィールと有効搭載量書式仕様… 53 A.アルゴリズム… 56 A.1 RTPデータヘッダーバリディティチェック… 59 A.2 RTCPヘッダーバリディティチェック… RTPパケットの数が予想して、失ったことを決定する63A.3… SDES RTCPにパケットを生成する63A.4… 64 A.5構文解析RTCP SDESパケット… 無作為の32ビットの識別子を生成する65A.6… RTCPトランスミッション間隔を計算する66A.7… 68
Schulzrinne, et al Standards Track [Page 2] RFC 1889 RTP January 1996
Schulzrinne、他Standards Track[2ページ]RFC1889RTP1996年1月
A.8 Estimating the Interarrival Jitter .................. 71 B. Security Considerations ............................. 72 C. Addresses of Authors ................................ 72 D. Bibliography ........................................ 73
Interarrivalジターを見積もっているA.8… 71 B.セキュリティ問題… 72 作者のC.アドレス… 72 D.図書目録… 73
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 10). RTP supports data transfer to multiple destinations using multicast distribution if provided by the underlying network.
このメモはリアルタイムのトランスポート・プロトコル(RTP)を指定します、対話的なオーディオやビデオのように。(トランスポート・プロトコルはデータのための終わりから終わりへのデリバリ・サービスをリアルタイムの特性に提供します)。 それらのサービスはペイロードタイプ確認、系列付番、timestamping、および配送モニターを含んでいます。 アプリケーションはマルチプレクシングとチェックサムサービスを利用するためにUDPの上でRTPを通常実行します。 両方のプロトコルはトランスポート・プロトコルの機能性の部分を寄付します。 しかしながら、RTPは他の適当な基本的なネットワークかトランスポート・プロトコルと共に使用されるかもしれません(セクション10を見てください)。 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,
o RTPは、サービスの質をモニターして、継続しているセッションのときに関係者に関して情報を伝達するためにプロトコル(RTCP)を制御します。 すなわち、RTCPの後者の局面は「緩く制御された」セッションのために明白な会員資格コントロールとセットアップが全くないところで十分であるかもしれませんが、アプリケーションのコントロールコミュニケーション要件のすべてをサポートすることを必ず意図するというわけではありません。 この機能性は別々のセッション制御プロトコルによって完全か部分的に包括されるかもしれません。
Schulzrinne, et al Standards Track [Page 3] RFC 1889 RTP January 1996
Schulzrinne、他Standards Track[3ページ]RFC1889RTP1996年1月
which is beyond the scope of this document.
このドキュメントの範囲に、あります。
RTP represents a new style of protocol following the principles of application level framing and integrated layer processing proposed by Clark and Tennenhouse [1]. That is, RTP is intended to be malleable 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.3.3.
クラークとTennenhouse[1]によって提案されたアプリケーションレベル縁どりと統合層の処理の原則に従って、RTPはプロトコルの新式を表します。 すなわち、RTPは特定用途で必要である情報を提供することにおいて可鍛性であることを意図して、別々の層として実装されるよりしばしばむしろ手続きの経緯と統合されるでしょう。 RTPは故意に完全でないプロトコルフレームワークです。 このドキュメントはRTPが適切であるすべての仕様の向こう側に一般的であると予想されたそれらの機能を指定します。 追加機能がプロトコルをより一般的にするか、または分析するのを必要とするオプションメカニズムを加えることによって設備されるかもしれない従来のプロトコルと異なって、必要に応じて変更、そして/または、追加を通してRTPによってヘッダーに仕立てられることを意図します。 例はセクション5.3と6.3.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 12):
したがって、このドキュメントに加えて、特定用途のためのRTPの完全な仕様は1通以上の仲間ドキュメントを必要とするでしょう(セクション12を見てください):
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 TBD.
o プロフィール仕様ドキュメント。(そのドキュメントは1セットのペイロードタイプコードと(例えば、メディアencodings)をペイロード形式に写像するのを定義します)。 また、プロフィールは拡大か特定のクラスのアプリケーションに特定のRTPへの変更を定義するかもしれません。 通常、アプリケーションは1個のプロフィールだけの下で作動するでしょう。 オーディオとビデオ・データのためのプロフィールは仲間RFC TBDで見つけられるかもしれません。
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 [2].
[2]でRTPデザイン決定のいくつかについてのバックグラウンド議論と同様にそれらの実装のためのリアルタイムのサービスとアルゴリズムの議論を見つけることができます。
Several RTP applications, both experimental and commercial, have already been implemented from draft specifications. These applications include audio and video tools along with diagnostic tools such as traffic monitors. Users of these tools number in the thousands. However, the current Internet cannot yet support the full potential demand for real-time services. High-bandwidth services using RTP, such as video, can potentially seriously degrade the quality of service of other network services. Thus, implementors should take appropriate precautions to limit accidental bandwidth usage. Application documentation should clearly outline the limitations and possible operational impact of high-bandwidth real-
いくつかの実験用であって、かつ市販のRTPアプリケーションが、草稿仕様から既に実装されました。 これらのアプリケーションはトラフィックモニターなどの診断用道具に伴うオーディオとビデオツールを含んでいます。 数千におけるこれらのツール番号のユーザ。 しかしながら、現在のインターネットはまだ本当の時間指定サービスを求める完全な潜在需要をサポートすることができません。 ビデオなどのRTPを使用する高帯域サービスは潜在的に真剣に他のネットワーク・サービスのサービスの質を下げることができます。 したがって、作成者は、偶然の帯域幅用法を制限するために適切な注意を払うべきです。 アプリケーションドキュメンテーションは明確に高帯域本物の制限と可能な操作上の影響について概説するべきです。
Schulzrinne, et al Standards Track [Page 4] RFC 1889 RTP January 1996
Schulzrinne、他Standards Track[4ページ]RFC1889RTP1996年1月
time services on the Internet and other network services.
インターネットと他のネットワーク・サービスでの時間指定サービス。
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 Internet-Draft draft-ietf-avt-profile
以下のセクションはRTPの使用のいくつかの局面について説明します。 例は、アプリケーションの基本的な操作を例証するためにRTPが使用されるかもしれないことを制限しないようにRTPを使用することで選ばれました。 これらの例では、RTPは仲間インターネット草稿草稿ietf-avtプロフィールで指定されたオーディオとビデオのために、IPとUDPの上で運ばれて、プロフィールによって設立されたコンベンションに続きます。
2.1 Simple Multicast Audio Conference
2.1 簡単なマルチキャストオーディオコンファレンス
A working group of the IETF meets to discuss the latest protocol draft, 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,
ワーキンググループのメンバーが会議の間、加わって、いなくなるので、だれがいつ何時、参加するか、そして、彼らがオーディオデータをどれくらいよく受け取っているかを知るのは役に立ちます。 そのために
Schulzrinne, et al Standards Track [Page 5] RFC 1889 RTP January 1996
Schulzrinne、他Standards Track[5ページ]RFC1889RTP1996年1月
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.5) when it leaves the conference.
会議におけるオーディオアプリケーションの各インスタンス、定期的である、RTCP(コントロール)の上のユーザのレセプションレポートと名前が移植するマルチキャスト。 レセプションレポートは、適応型のencodingsを制御するために現在のスピーカーがどれくらいよく受け取られていて、使用されるかもしれないかを示します。 また、ユーザ名に加えて、他の身元が分かる情報はコントロール帯域幅限界を条件として含まれるかもしれません。 それが会議を出るとき、サイトはRTCP BYEパケット(セクション6.5)を送ります。
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 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セッション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
オーディオ会議の何人かの意図している関係者は、高帯域リンクに接続されるかもしれませんが、IPマルチキャストで直接届いていないかもしれません。 例えば、それらは背中であるかもしれません。
Schulzrinne, et al Standards Track [Page 6] RFC 1889 RTP January 1996
Schulzrinne、他Standards Track[6ページ]RFC1889RTP1996年1月
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パケットも通過しないアプリケーションレベルファイアウォール。 これらのサイトに、混合は必要でないかもしれない、その場合、翻訳者と呼ばれる別のタイプのRTP-レベルリレーは使用されるかもしれません。 2人の翻訳者がインストールされます、ファイアウォールのどちらかの側面の1、外のものがファイアウォールの中の翻訳者との安全な接続で受け取られたすべてのマルチキャストパケットを注いでいて。 ファイアウォールの中の翻訳者は再びマルチキャストパケットとしてサイトの内部のネットワークに制限されたマルチキャストグループにそれらを送ります。
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で明らかにされます。
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 10).
RTPパケット: 固定RTPヘッダーから成るデータ・パケット、ソース(以下を見る)、およびペイロードデータを寄付することによると空のリスト。 いくつかの基本的なプロトコルが、RTPパケットのカプセル化が定義されるのを必要とするかもしれません。 通常、基本的なプロトコルの1つのパケットが単一のRTPパケットを含んでいますが、カプセル化メソッドで受入れられるなら、いくつかのRTPパケットが含まれるかもしれません(セクション10を見てください)。
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." [3] 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プロトコルはわずかな正の整数を使用することでポートを特定します。」 [3] OSIトランスポート層によって使用される輸送セレクタ(TSEL)はポートに同等です。 RTPは、セッションのRTPとRTCPパケットを多重送信するためにポートとして何らかのメカニズムにそのようなものを供給するために下位層プロトコルによります。
Schulzrinne, et al Standards Track [Page 7] RFC 1889 RTP January 1996
Schulzrinne、他Standards Track[7ページ]RFC1889RTP1996年1月
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 session: The association among a set of participants
communicating with RTP. For each participant, the session is
defined by a particular pair of destination transport addresses
(one network address plus a port pair for RTP and RTCP). The
destination transport address pair may be common for all
participants, as in the case of IP multicast, or may be
different for each, as in the case of individual unicast network
addresses plus a common port pair. In a multimedia session,
each medium is carried in a separate RTP session with its own
RTCP packets. The multiple RTP sessions are distinguished by
different port number pairs and/or different multicast
addresses.
RTPセッション: RTPとコミュニケートする1セットの関係者の中の協会。 各関係者に関しては、セッションは送付先輸送アドレス(RTPとRTCPのための1つのネットワーク・アドレスとポート組)の特定の組によって定義されます。 目的地輸送アドレス組は、IPマルチキャストに関するケースのようにすべての関係者にとって一般的であるかもしれないか、またはそれぞれにおいて、異なるかもしれません、個々のユニキャストネットワーク・アドレスと一般的なポート組のケースのように。 マルチメディアセッションのときに、各媒体はそれ自身のRTCPパケットとの別々のRTPセッションのときに運ばれます。 複数の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.4.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.4.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 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).
貢献しているソース(CSRC): 結合したストリームに貢献したRTPパケットの水源はRTPミキサーで生産しました(以下を見てください)。 ミキサーは特定のパケットの世代に貢献したソースに関するSSRC識別子のリストをそのパケットのRTPヘッダーに挿入します。 このリストはCSRCリストと呼ばれます。 例のアプリケーションはミキサーがスピーチが出発しているパケットを作り出すために結合されたすべての話し手を示すところの電話による会議です、受信機が現在の話し手を示すのを許容して、すべてのオーディオパケットが同じSSRC識別子(ミキサーのもの)を含んでいますが。
Schulzrinne, et al Standards Track [Page 8] RFC 1889 RTP January 1996
Schulzrinne、他Standards Track[8ページ]RFC1889RTP1996年1月
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. These are called
third party monitors.
以下をモニターしてください。 RTCPパケットを受けるアプリケーションは、RTPセッション、特にレセプションレポートの関係者で発信して、物流監視、欠点診断、および長期の統計のために現在のサービスの質を見積もっています。 モニター機能はセッションのときに参加しながら、アプリケーションが組み込まれそうです、RTPデータ・パケットをまた、そうでなければ参加しない別々のアプリケーションであるかもしれなく、送るか、または受けませんが。 これらは第三者モニターと呼ばれます。
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 conference control application 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. For simple 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.
非RTPは以下を意味します。 RTPに加えて使用可能なサービスを提供するのが必要であるかもしれないプロトコルとメカニズム。 会議制御アプリケーションは、マルチメディア会議のために、特に、暗号化のためにマルチキャストアドレスとキーを配布して、使用されるために暗号化アルゴリズムを交渉して、彼らが事前に定義されたペイロードが値をタイプしない形式のために表すRTPペイロードタイプ値とペイロード書式の間のダイナミックなマッピングを定義するかもしれません。 また、簡単なアプリケーションのために、電子メールか会議データベースが使用されるかもしれません。 このドキュメントの範囲の外にそのようなプロトコルとメカニズムの仕様があります。
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 [4]. Unless otherwise noted, numeric constants are in decimal (base 10).
すべての整数野原が最初に、すなわち、ネットワークバイトオーダー、最も重要なバイト(八重奏)で運ばれます。 このバイトオーダーはビッグエンディアンとして一般的に知られています。 トランスミッション命令は[4]で詳細に説明されます。 別の方法で注意されない場合、小数(ベース10)には数値定数があります。
Schulzrinne, et al Standards Track [Page 9] RFC 1889 RTP January 1996
Schulzrinne、他Standards Track[9ページ]RFC1889RTP1996年1月
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 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 [5]. 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日[5]の0h UTCに比例しているNetwork Timeプロトコル(NTP)のタイムスタンプ形式を使用することで表されます。 完全な解決NTPタイムスタンプは整数部が最初の32ビットにあって、断片的な部分が最後の32ビットにある64ビットの未署名の固定小数点数です。 よりコンパクトな表現が適切であるいくつかの分野では、中くらいの32ビットだけが使用されています。 それはそうであり、整数部と高い16のものの低16ビットは断片的な部分のビットです。 整数部の高い16ビットは独自に決定していなければなりません。
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
詰め物(P): 詰め物が噛み付いた1ビットのIfが設定している、パケットは終わりの部分でない1つ以上の追加詰め物八重奏を含んでいます。
Schulzrinne, et al Standards Track [Page 10] RFC 1889 RTP January 1996
Schulzrinne、他Standards Track[10ページ]RFC1889RTP1996年1月
payload. The last octet of the padding contains a count of how
many padding octets should be ignored. 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.
ペイロード。 詰め物の最後の八重奏はいくつの詰め物八重奏が無視されるべきであるかに関するカウントを含んでいます。 詰め物が固定ブロック・サイズがあるいくつかの暗号化アルゴリズムか下位層プロトコルデータ単位でいくつかのRTPパケットを運ぶのに必要であるかもしれません。
extension (X): 1 bit
If the extension bit is set, the fixed header is 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識別子の数を含んでいます。
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
specifies 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). An initial
set of default mappings for audio and video is specified in the
companion profile Internet-Draft draft-ietf-avt-profile, and
may be extended in future editions of the Assigned Numbers RFC
[6]. An RTP sender emits a single RTP payload type at any given
time; this field is not intended for multiplexing separate media
streams (see Section 5.2).
ペイロードタイプ(太平洋標準時の): Thisがさばく7ビットは、RTPペイロードの形式を特定して、アプリケーションで解釈を決定します。 プロフィールはペイロードタイプコードのデフォルトの静的なマッピングをペイロード形式に指定します。 追加ペイロードタイプコードは非RTP手段でダイナミックに定義されるかもしれません(セクション3を見てください)。 オーディオとビデオのための1人の始発に関するデフォルトマッピングは、仲間プロフィールインターネット草稿草稿ietf-avtプロフィールで指定されて、将来版を重ねるにあたってAssigned民数記RFC[6]について広げられるかもしれません。 RTP送付者はその時々で単独のRTPペイロードタイプを放ちます。 この分野は、別々のメディアストリームを多重送信するために意図しません(セクション5.2を見てください)。
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 is random (unpredictable) to make known-plaintext attacks
on encryption more difficult, even if the source itself does not
encrypt, because the packets may flow through a translator that
does. Techniques for choosing unpredictable numbers are
discussed in [7].
一連番号: 一連番号がそれぞれのRTPデータ・パケットあたり1つ増加する16ビットは送られて、受信機によって使用されて、パケット損失を検出して、パケット系列を回復するかもしれません。 一連番号の初期の値は暗号化に対する知られている平文攻撃をより難しくするように無作為です(予測できない)、ソース自体がそうしないでも。パケットがそうする翻訳者を通して流れるかもしれないので、暗号化します。 [7]で予測できない数を選ぶためのテクニックについて議論します。
timestamp: 32 bits
The timestamp reflects the sampling instant of the first octet
in the RTP data packet. The sampling instant must be derived
タイムスタンプ: 32ビット、タイムスタンプはRTPデータ・パケットにおける最初の八重奏の標本抽出の瞬間を反映します。 標本抽出の瞬間を引き出さなければなりません。
Schulzrinne, et al Standards Track [Page 11] RFC 1889 RTP January 1996
Schulzrinne、他Standards Track[11ページ]RFC1889RTP1996年1月
from a clock that increments monotonically and linearly in time
to allow synchronization and jitter calculations (see Section
6.3.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 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.
時計から、それは、同期とジター計算を許容する時間、単調に増加して、直線的です(セクション6.3.1を見てください)。 時計の解決は必要な同期精度と測定パケット到着ジターに十分であるに違いありません(ビデオフレームあたり1回のカチカチする音は通常十分ではありません)。 クロック周波数は、ペイロードとして運ばれたデータの形式に依存していて、フォーマットを定義するプロフィールかペイロード書式仕様で静的に指定されるか、またはダイナミックに非RTP手段で定義されたペイロード書式に指定されるかもしれません。 RTPパケットが定期的に生成されるなら、標本抽出時計から決定するように瞬間を抽出する名目上のことは使用されていることです、システムクロックの読まない。 タイムスタンプ時計がおそらく各サンプリング周期あたり1つ増加する定率オーディオのための例として。 オーディオアプリケーションが入力装置から160回のサンプリング周期をカバーするブロックを読むなら、タイムスタンプはそのような各ブロック単位の160増強されるでしょう、ブロックがパケットで伝えられるか、または静かであるとして下げられることにかかわらず。
The initial value of the timestamp is random, as for the sequence number. Several consecutive RTP packets may 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.)
タイムスタンプの初期の値は一連番号のように無作為です。 いくつかの連続したRTPパケットには、それらがすぐに(論理的に)生成されるなら、等しいタイムスタンプがあるかもしれません、例えば、同じビデオフレームに属してください。 データがオーダーで伝えられないで、それは抽出されました、MPEGの場合でビデオフレームを補間するのでことであるなら、連続したRTPパケットは単調でないタイムスタンプを含むかもしれません。 (伝えられるとしてのパケットの一連番号はまだ単調になっているでしょう。)
SSRC: 32 bits
The SSRC field identifies the synchronization source. This
identifier is 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.
SSRC: SSRCがさばく32ビットは同期ソースを特定します。 この識別子は手当たりしだいに選ばれていて、いいえ、同じRTPセッション中の2つの同期ソースがそうする意図をもって同じSSRC識別子を持ってください。 無作為の識別子を生成するための例のアルゴリズムはAppendix A.6に提示されます。 複数のソースが同じ識別子を選ぶという確率が低いのですが、すべてのRTP実装を衝突を検出して、決議するように準備しなければなりません。 セクション8は、衝突を決議して、RTP-レベルを検出するためにSSRC識別子のユニークさに基づく輪を進めながら、メカニズムに伴う衝突確率について説明します。 また、ソースがソース輸送アドレスを変えるなら、それは、輪にされたソースとして解釈されるのを避けるために新しいSSRC識別子を選ばなければなりません。
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 may be identified. CSRC identifiers are
CSRCは記載します: 0〜15の項目、32ビット、CSRCが記載するそれぞれがこのパケットに含まれたペイロードのために貢献しているソースを特定します。 CC分野で識別子の数を与えます。 15以上の貢献しているソースがあれば、15だけを特定してもよいです。 CSRC識別子はそうです。
Schulzrinne, et al Standards Track [Page 12] RFC 1889 RTP January 1996
Schulzrinne、他Standards Track[12ページ]RFC1889RTP1996年1月
inserted by mixers, 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.
ミキサーで、貢献しているソースに関するSSRC識別子を使用して、挿入されます。 例えば、オーディオパケットに関して、パケットを作成するために一緒に複雑であったすべてのソースの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 [1]. In RTP, multiplexing is provided by the destination transport address (network address and port number) which define an 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. It is not intended that the audio and video be carried in a single RTP session and demultiplexed based on the payload type or SSRC fields. Interleaving packets with different payload types but using the same SSRC would introduce several problems:
効率的なプロトコル処理において、マルチプレクシングポイントの数は最小にされるべきです、統合層の処理設計原理[1]で説明されるように。 RTPに、送付先輸送アドレス(ネットワーク・アドレスとポートナンバー)でマルチプレクシングを提供します(RTPセッションを定義します)。 例えば、オーディオで構成された電子会議と別々にコード化されたビデオメディアでは、各媒体はそれ自身の送付先輸送アドレスとの別々のRTPセッションのときに運ばれるべきです。 オーディオとビデオがただ一つのRTPセッションのときに運ばれて、ペイロードタイプかSSRC分野に基づいて反多重送信されることを意図しません。 異なったペイロードタイプでパケットをはさみ込みますが、同じSSRCを使用すると、いくつかの問題が紹介されるでしょう:
1. If one payload type were switched during a session, there
would be no general means to identify which of the old
values the new one replaced.
1. 1つのペイロードタイプがセッションの間、切り換えられるなら、新しい方が古い値のどれを取り替えたかを特定するどんな一般的な手段もないでしょうに。
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.3) can
only describe one timing and sequence number space per SSRC
and do not carry a payload type field.
3. RTCP送付者と受信機レポート(セクション6.3を見る)は、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つの問題が避けられるでしょう。
Schulzrinne, et al Standards Track [Page 13] RFC 1889 RTP January 1996
Schulzrinne、他Standards Track[13ページ]RFC1889RTP1996年1月
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 a 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ビットの単語を加えなければならないかもしれません。 これらの分野を含む八重奏はプロフィールによって再定義されて、異なった要件に合うかもしれません、例えば、より多くか、より少ないマーカービットで。 何かマーカービットがあれば、プロフィールから独立しているモニターがパケット損失パターンの間の相関関係を観測できるかもしれなくて以来の八重奏の最も重要なビットとマーカービットに位置するべきです。
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 ビデオのコード化などの特定のペイロード形式に必要である追加情報はパケットのペイロード部分で運ばれるべきです。 これは、ペイロード部分の始めにいつも出席しているヘッダーにあるか、またはデータパターンで予約された値によって示されるかもしれません。
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 特定のクラスのアプリケーションがペイロード形式の如何にかかわらず追加機能性を必要とするなら、それらのアプリケーションが作動するプロフィールは、既存の固定ヘッダーの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 14] RFC 1889 RTP January 1996
Schulzrinne、他Standards Track[14ページ]RFC1889RTP1996年1月
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.
このヘッダー拡大が限られた使用のためだけに意図することに注意してください。 前項で説明されたメソッドを使用して、このメカニズムのほとんどの潜在的用途が、より上手にされた別の方法でしょう。 例えばそれが条件付きでないので処理するためにそれほど高価でなく、可変位置で固定ヘッダーへのプロフィール特有の拡大。 特定のペイロード形式に必要である追加情報は、このヘッダー拡張子を使用するべきではありませんが、パケットのペイロード部分で運ばれるべきです。
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 is 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 may 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. The feedback may be directly useful for control
of adaptive encodings [8,9], but experiments with IP
1. プライマリ機能は情報配給の品質のフィードバックを提供することです。 これは、トランスポート・プロトコルとしてのRTPの役割の不可欠の部分であり、他のトランスポート・プロトコルの流れと輻輳制御機能に関連します。 フィードバックは、直接適応型のencodings[8、9]のコントロールの役に立つかもしれませんが、IPを実験します。
Schulzrinne, et al Standards Track [Page 15] RFC 1889 RTP January 1996
Schulzrinne、他Standards Track[15ページ]RFC1889RTP1996年1月
multicasting have shown that it is also 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.3.
マルチキャスティングは、また、分配における欠点を診断するために受信機から反応を得るのも重要であることを示しました。 レセプションフィードバックレポートをすべての関係者に送るのに、問題を観測している人は、それらの問題がローカルである、またはグローバルであるかを評価できます。 また、IPマルチキャストのような分配メカニズムでは、別の方法でセッションにかかわらないネットワークサービスプロバイダーなどの実体に、ネットワーク問題を診断するために第三者モニターとしてフィードバック情報と行為を受け取るのも可能です。このフィードバック機能はセクション6.3で以下で説明されたRTCP送付者と受信機レポートによって実行されます。
2. RTCP carries a persistent transport-level identifier for an
RTP source called the canonical name or CNAME, Section
6.4.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 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.
2. RTCPは正準な名前と呼ばれるRTPソースかCNAMEのための永続的な輸送レベル識別子、セクション6.4.1を運びます。 SSRC識別子が、闘争が発見されるか、またはプログラムが再開されるかを変えるかもしれないので、受信機は、CNAMEが各関係者の動向をおさえるのを必要とします。 また、受信機は、CNAMEが関連するRTPセッションの1セットの与えられた関係者から複数のデータ・ストリームを関連づけて、例えばオーディオとビデオを同期させるのを必要とします。
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、任意の機能は最小量のセッション制御情報(例えば、ユーザーインタフェースに表示されるべき関与している識別)を伝えることです。 これは「緩く制御された」セッションのときに関係者が会員資格コントロールもパラメタ交渉なしで出入りするところで役に立つ最も傾向があります。 RTCPは参加者各位に届く便利なチャンネルとして勤めますが、すべてのコントロールがアプリケーションのコミュニケーション要件であるとサポートしないと必ず予想されます。 よりハイレベルのセッション制御プロトコル(このドキュメントの範囲にある)が必要であるかもしれません。
Functions 1-3 are mandatory when RTP is used in the IP multicast environment, and are recommended for all environments. RTP application designers are advised to avoid mechanisms that can only work in unicast mode and will not scale to larger numbers.
RTPがIPマルチキャスト環境で使用されて、すべての環境のために推薦されるとき、機能1-3は義務的です。 RTPアプリケーション設計者がユニキャストモードで取り組むことができるだけであって、より大きい数に比例しないメカニズムを避けるようにアドバイスされます。
Schulzrinne, et al Standards Track [Page 16] RFC 1889 RTP January 1996
Schulzrinne、他Standards Track[16ページ]RFC1889RTP1996年1月
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
RR: 活発な送付者でない関係者からのレセプション統計のための受信機レポート
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 always end on a 32-bit boundary. The alignment requirement and a length field in the fixed part are included to make RTCP packets "stackable". Multiple RTCP packets may 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パケットはパケットタイプに従って可変長がありますが、32ビットの境界でいつも終わるかもしれない構造化された要素が支えたRTPデータ・パケットのものと同様の固定部分で始まります。 固定部分の整列要求と長さの分野は、RTCPパケットを「スタック可能に」するように含まれています。 複数のRTCPパケットが、下位層プロトコル(例えば、UDP)の単一のパケットで送られる合成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パケットはパケットのオーダーか組み合わせのときに要件なしで独自に処理されるかもしれません。 しかしながら、プロトコルの機能を実行するために、以下の規制は課されます:
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 should 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 should also include the SDES CNAME.
o 新しい受信機が、できるだけ早くソースを特定して、口パクなどの目的のためにメディアを関連づけ始めるためにCNAMEをソースに受け取る必要があるので、また、それぞれの合成RTCPパケットはSDES CNAMEを含んでいるはずです。
o The number of packet types that may appear first in the
compound packet should be limited to increase the number of
constant bits in the first word and the probability of
successfully validating RTCP packets against misaddressed RTP
o 最初に合成パケットに現れるかもしれないパケットタイプの数は、最初の単語による一定のビットの数と首尾よくmisaddressed RTPに対してRTCPパケットを有効にするという確率を増強するために制限されるべきです。
Schulzrinne, et al Standards Track [Page 17] RFC 1889 RTP January 1996
Schulzrinne、他Standards Track[17ページ]RFC1889RTP1996年1月
data packets or other unrelated packets.
データ・パケットか他の関係ないパケット。
Thus, all RTCP packets must be sent in a compound packet of at least two individual packets, with the following format recommended:
したがって、少なくとも2つの個々のパケットの合成パケットですべてのRTCPパケットを送らなければなりません、以下の形式がお勧めであることで:
Encryption prefix: If and only if the compound packet is to be
encrypted, it is prefixed by a random 32-bit quantity redrawn
for every compound packet transmitted.
暗号化接頭語: そして、合成パケットが暗号化されているつもりである場合にだけ、それはあらゆる合成パケットのための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 nor
received, in which case an empty RR is sent, and even if the
only other RTCP packet in the compound packet is a BYE.
SRかRR: いつも合成パケットにおける最初のRTCPパケットはAppendix A.2で説明されるようにヘッダー合法化を容易にするレポートパケットであるに違いありません。 これはデータを全く送って、空のRRをどのケースに送るかで受け取らなく、合成パケットにおける他の唯一のRTCPパケットがBYEであっても本当です。
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を超えているか、そして、1SRに収まる数かRRパケット、当時の追加RRパケットが初期のレポートパケットに続くはずです。
SDES: An SDES packet containing a CNAME item must be included in
each compound RTCP packet. Other source description items may
optionally be included if required by a particular application,
subject to bandwidth constraints (see Section 6.2.2).
SDES: それぞれの合成RTCPパケットにCNAMEの品目を含むSDESパケットを含まなければなりません。 他のソース記述項目は必要なら特定用途で帯域幅規制を条件として任意に含まれるかもしれません(セクション6.2.2を見てください)。
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.
さようならか装置: まだ定義されているためにものを含む他のRTCPパケットタイプは順不同に続くかもしれません、BYEが与えられたSSRC/CSRCと共に送られた最後のパケットであるべきであるのを除いて。 パケットタイプは一度より多く見えるかもしれません。
It is advisable for translators and mixers to 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 maximum transmission unit (MTU) of the network path, it may be segmented into multiple shorter compound packets to be transmitted in separate packets of the underlying protocol. Note that each of the compound packets must begin with an SR or RR packet.
翻訳者とミキサーが可能であるときはいつも、彼らがパケットオーバーヘッドを清算するために1つの合成パケットに転送している複数のソースから個々のRTCPパケットを結合するのは、賢明です(セクション7を見てください)。 RTCPがパケットを合成する例は生産されて、ミキサーが図1に示されるということであるかもしれません。 合成パケットの全長がネットワーク経路のマキシマム・トランスミッション・ユニット(MTU)を超えているなら、それは、基本的なプロトコルの別々のパケットで伝えられるために複数の、より脆い合成パケットに区分されるかもしれません。 それぞれの合成パケットがSRかRRパケットと共に始まらなければならないことに注意してください。
An implementation may ignore incoming RTCP packets with types unknown to it. Additional RTCP packet types may be registered with the Internet Assigned Numbers Authority (IANA).
実現はそれにおける、未知のタイプがある入って来るRTCPパケットを無視するかもしれません。 追加RTCPパケットタイプはインターネットAssigned民数記Authorityに示されるかもしれません(IANA)。
Schulzrinne, et al Standards Track [Page 18] RFC 1889 RTP January 1996
Schulzrinne、他Standards Track[18ページ]RFC1889RTP1996年1月
6.2 RTCP Transmission Interval
6.2 RTCPトランスミッション間隔
if encrypted: random 32-bit integer
|
|[------- packet -------][----------- packet -----------][-packet-]
|
| receiver reports chunk chunk
V item item item item
--------------------------------------------------------------------
|R[SR|# sender #site#site][SDES|# CNAME PHONE |#CNAME LOC][BYE##why]
|R[ |# report # 1 # 2 ][ |# |# ][ ## ]
|R[ |# # # ][ |# |# ][ ## ]
|R[ |# # # ][ |# |# ][ ## ]
--------------------------------------------------------------------
|<------------------ UDP packet (compound packet) --------------->|
コード化されるなら: 無作為の32ビットの整数| |[------- packet -------][----------- packet -----------][-packet-] | | 受信機レポート塊塊V項目項目項目の品目-------------------------------------------------------------------- |R[SR| #送付者#サイト#サイト][SDES| #CNAME PHONE| #CNAME LOC]、[BYE##、なぜ]|R[| #レポート#1#2][| #| #][##]|R[| ###][| #| #][##]|R[| ###][| #| #][##]-------------------------------------------------------------------- | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-- UDPパケット(合成パケット)--------------->|
#: SSRC/CSRC
#: SSRC/CSRC
Figure 1: Example of an RTCP compound packet
図1: 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.
RTPは、アプリケーションが自動的に数人の関係者から数千まで及ぶセッションサイズの上比例するのを許容するように設計されています。 例えば、1か2人の人だけが一度に話すので本来オーディオ会議が、データ通信量が自己制限であるので、マルチキャスト分配で、どんな与えられたリンクの上のデータ信号速度は関係者の数の如何にかかわらず比較的一定数にとどまっています。 しかしながら、コントロール交通は自己制限ではありません。 一定の割合で各関係者からのレセプションレポートを送るなら、コントロール交通は関係者の数で直線的になるでしょうに。 したがって、レートは縮小しなければなりません。
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, or it might just be a reasonable share. The session bandwidth may be chosen based or 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. The session bandwidth parameter is expected to be supplied by a session management application when it invokes a media application, but media applications may also 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.
各セッションのために、データ通信量は関係者の中で分割されるために「セッション帯域幅」と呼ばれる総責任限度額を受けることがあると思われます。 この帯域幅は、予約されていてネットワークによって励行された限界であるかもしれませんかそれはまさしく手頃なシェアであるかもしれません。 利用可能なネットワーク回線容量に関するベース的か何らかの費用的か先験的な知識はセッションのためにセッション帯域幅に選ばれるかもしれません。 それはメディアコード化からいくらか独立していますが、コード化選択はセッション帯域幅によって制限されるかもしれません。 メディアアプリケーションを呼び出すとき、セッション管理アプリケーションでセッション帯域幅パラメタが供給されると予想されますが、また、メディアアプリケーションは独身の送付者データ帯域幅に基づくデフォルトをセッションのために選択されたコード化に設定するかもしれません。 また、アプリケーションはマルチキャスト範囲規則か他の評価基準に基づく帯域幅限界を実施するかもしれません。
Schulzrinne, et al Standards Track [Page 19] RFC 1889 RTP January 1996
Schulzrinne、他Standards Track[19ページ]RFC1889RTP1996年1月
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)を含んでいます。 また、アプリケーションが、これらのプロトコルのどれが使用中であるかを知っていると予想できます。 移動するのに応じてパケットが異なったリンク・レベルヘッダーと共にカプセルに入れられるので、リンク・レベルヘッダーは計算に含まれていません。
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. It is suggested that the fraction of the session bandwidth allocated to RTCP be fixed at 5%. While the value of this and other constants in the interval calculation is 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%で修理されていることが提案されます。 間隔計算におけるこれと他の定数の値が重要でない間、セッションのすべての関係者が間隔が計算されるためにとても同じ同じ値を使用しなければなりません。 したがって、これらの定数は特定のプロフィールのために修理されるべきです。
The algorithm described in Appendix A.7 was designed to meet the goals outlined above. 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:
Appendix A.7で説明されたアルゴリズムは、上に概説された目標を達成するように設計されました。 それは、関係者の中で許容コントロール交通帯域幅を分割するために送付合成RTCPパケットの間隔について計算します。 これで、アプリケーションは、例えばすべての関係者の識別が重要である小さいセッションのために速い応答を提供しますが、大きいセッションまで自動的に適合します。 アルゴリズムは以下の特性を取り入れます:
o Senders are collectively allocated at least 1/4 of the control
traffic bandwidth 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.
o 新たに関係者に加わるとCNAMEが多くの受信機にもかかわらず、少ない数の送付者とのセッションのときに、よりすぐに送付サイトに受けられるように、少なくとも1/4のコントロール交通帯域幅を送付者にまとめて割り当てます。
o The calculated interval between RTCP packets is required to be
greater than a minimum of 5 seconds to avoid having bursts of
RTCP 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.
o RTCPパケットの計算された間隔が最低5秒以上になるのに関係者の数が少ないときに、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 [10]. The first
RTCP packet sent after joining a session is also delayed by a
random variation of half the minimum RTCP interval in case the
application is started at multiple sites simultaneously, for
example as initiated by a session announcement.
o RTCPパケットの間隔は、すべての関係者[10]の故意でない同期を避けるために計算された間隔の[0.5、1.5]回の間の範囲で手当たりしだいに変えられます。 アプリケーションが同時に複数のサイトで始められるといけないので最小のRTCP間隔の半分の不規則変動で遅らせられて、接合して、セッションが発信した後にも最初のRTCPパケットは発信しました、例えば、セッション発表で開始されるように。
Schulzrinne, et al Standards Track [Page 20] RFC 1889 RTP January 1996
Schulzrinne、他Standards Track[20ページ]RFC1889RTP1996年1月
o A dynamic estimate of the average compound RTCP packet size is
calculated, including all those received and sent, to
automatically adapt to changes in the amount of control
information carried.
o 平均した合成RTCPパケットサイズのダイナミックな見積りは計算されます、自動的に情報が運んだコントロールの量における変化に順応するために受け取られて、送られたすべてのものを含んでいて。
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%です。
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 is created in a table indexed by the SSRC or CSRC identifier (see Section 8.2) to keep track of them. New entries may not be considered valid until multiple packets carrying the new SSRC have been received (see Appendix A.1). Entries may be deleted from the table when an RTCP BYE packet with the corresponding SSRC identifier is received.
RTCPパケット間隔の計算はセッションのときに参加するサイトの数の見積りによります。 新しいサイトは、それらの動向をおさえるためにそれらが聞かれて、それぞれのためのエントリーがSSRCかCSRC識別子によって索引をつけられたテーブルで作成されるときの(セクション8.2を見てください)カウントに加えられます。 新しいエントリーは有効であると新しいSSRCを運ぶ複数のパケットを受け取るまで(Appendix A.1を見てください)考えられないかもしれません。 対応するSSRC識別子があるRTCP BYEパケットが受け取られているとき、エントリーはテーブルから削除されるかもしれません。
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 suggested). This provides some robustness against packet loss. All sites must calculate roughly the same value for the RTCP report interval in order for this timeout to work properly.
関係者は、別のサイトが不活発であるとマークするか、またはそうでなければ、まだ有効な状態でそれを削除するかもしれません、少ない数のRTCPレポート間隔の間、どんなRTPもRTCPパケットも受け取っていないなら(5は示されます)。 これはパケット損失に対して何らかの丈夫さを提供します。 このタイムアウトが適切に扱うように、すべてのサイトがRTCPレポート間隔の間、およそ同じ値について計算しなければなりません。
Once a site has been validated, then if it is later marked inactive the state for that site should still be retained and the site should continue to be counted in the total number of sites sharing RTCP bandwidth for a period long enough to span typical network partitions. This is to avoid excessive traffic, when the partition heals, due to an RTCP report interval that is too small. A timeout of 30 minutes is suggested. Note that this is still larger than 5 times the largest value to which the RTCP report interval is expected to usefully scale, about 2 to 5 minutes.
サイトがいったん有効にされると、次に、それが後で不活発であるとマークされるなら、そのサイトへの状態はまだ保有されているべきです、そして、サイトはしばらく典型的なネットワークパーティションにかかることができるくらいの長い間RTCP帯域幅を共有するサイトの総数で数えられ続けるべきです。 これは、パーティションが小さ過ぎるRTCPレポート間隔のため回復すると過度の交通を避けるためのものです。 30分のタイムアウトは示されます。 これがRTCPレポート間隔が有効に比例すると予想される最も大きい値の5倍よりなお大きいことに注意してください、およそ2〜5分。
6.2.2 Allocation of source description bandwidth
6.2.2 ソース記述帯域幅の配分
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
この仕様は義務的なCNAMEの品目に加えた数個のソース記述(SDES)項目を定義します、NAME(個人名)やメール(Eメールアドレス)のように。 また、それは新しいアプリケーション特有のRTCPパケットタイプを定義する手段を提供します。 アプリケーションはレセプションレポートとCNAMEが送られるレートを減速させるのでコントロール帯域幅をこの追加情報に割り当てる際に警戒するべきです、その結果、プロトコルの性能を損ないます。 それはRTCPでその20%未満お勧めです。
Schulzrinne, et al Standards Track [Page 21] RFC 1889 RTP January 1996
Schulzrinne、他Standards Track[21ページ]RFC1889RTP1996年1月
bandwidth allocated to a single participant be used to carry the additional information. Furthermore, it is not intended that all SDES items should 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.
帯域幅は関係者をシングルに割り当てました。追加情報を運ぶのが使用されてください。 その上、すべてのSDESの品目があらゆるアプリケーションに含まれるべきであることを意図しません。 それらのユーティリティによると、帯域幅の部分は含まれているものに割り当てられるべきです。 むしろ、割合が静的に項目の典型的な長さに基づくレポート間隔カウントに翻訳されるのは、ダイナミックにこれらの断片を見積もっているよりお勧めです。
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 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.
例えば、アプリケーションは、どんな他のものではなく、CNAME、NAME、およびメールだけも送るように設計されるかもしれません。 アプリケーションのユーザーインタフェースに絶え間なくNAMEを表示するでしょう、したがって、NAMEを優先させるかもしれませんが、メールよりはるかに高い要求する場合にだけ、メールを表示するでしょう。 あらゆるRTCP間隔を置いて、CNAMEの品目があるRRパケットとSDESパケットを送るでしょう。 最小間隔に作動する小さいセッションのために、それは平均して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 might be sent in only one RTP session. The other sessions would carry only the CNAME item.
複数のアプリケーションがコンサートで一般的なCNAMEを通して各関係者で付きながら交差しているアプリケーションを使用することで作動すると、例えば各媒体のためにRTPセッションで構成されたマルチメディア会議では、1つのRTPセッションだけのときに追加SDES情報を送るかもしれません。 他のセッションはCNAMEの品目だけを運ぶでしょう。
6.3 Sender and Receiver Reports
6.3 送付者と受信機レポート
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 may 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.
SRとRR用紙の両方がゼロか、より多くのレセプションレポートブロック(最後のレポート以来この受信機がRTPデータ・パケットを受けているそれぞれの同期源への1)を含んでいます。 レポートは、CSRCリストに記載されたソースを寄付するために発行されません。 それぞれのレセプションレポートブロックはそのブロックで示された特定のソースから受け取られたデータに関する統計を提供します。 最大31レセプションレポートブロックがSRかRRパケットをうまくはめ込むので、レセプションを含むのに必要である初期のSRかRRパケットが最後のレポート以来間隔の間に聞かれたすべてのソースを届け出た後に、追加RRパケットは積み重ねられるかもしれません。
Schulzrinne, et al Standards Track [Page 22] RFC 1889 RTP January 1996
Schulzrinne、他Standards Track[22ページ]RFC1889RTP1996年1月
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で明らかにされます。
6.3.1 SR: Sender report RTCP packet
6.3.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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P| RC | PT=SR=200 | length | header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of sender | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | NTP timestamp, most significant word | sender +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ info | NTP timestamp, least significant word | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTP timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sender's packet count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sender's octet count | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | SSRC_1 (SSRC of first source) | report +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block | fraction lost | cumulative number of packets lost | 1 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | extended highest sequence number received | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | interarrival jitter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | last SR (LSR) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | delay since last SR (DLSR) | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | SSRC_2 (SSRC of second source) | report +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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つの八重奏です。 分野には、以下の意味があります:
Schulzrinne, et al Standards Track [Page 23] RFC 1889 RTP January 1996
Schulzrinne、他Standards Track[23ページ]RFC1889RTP1996年1月
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)です。
padding (P): 1 bit
If the padding bit is set, this RTCP packet contains some
additional padding octets at the end which are not part of the
control information. The last octet of the padding is a count of
how many padding octets should be ignored. Padding may be needed
by some encryption algorithms with fixed block sizes. In a
compound RTCP packet, padding should only be required on the
last individual packet because the compound packet is encrypted
as a whole.
詰め物(P): 詰め物が噛み付いた1ビットのIfは用意ができていて、このRTCPパケットは終わりの制御情報の一部でないいくつかの追加詰め物八重奏を含んでいます。 詰め物の最後の八重奏はいくつの詰め物八重奏が無視されるべきであるかに関するカウントです。 詰め物は固定ブロック・サイズでいくつかの暗号化アルゴリズムによって必要とされるかもしれません。 合成RTCPパケットでは、合成パケットが全体でコード化されるので、詰め物が最後の個々のパケットの上で必要であるだけであるべきです。
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 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 may not be
known. A sender that can keep track of elapsed time but has no
notion of wallclock time may use the elapsed time since joining
NTPタイムスタンプ: タイムスタンプと組み合わせてそれを使用できるようにこのレポートを送ったとき、wallclockが調節する64ビットのIndicatesは他の受信機からのレセプションレポートで戻って、それらの受信機に往復の伝播を測定しました。 受信機は、タイムスタンプの測定精度がNTPタイムスタンプの解決遠い以下に制限されるかもしれないと予想するはずです。 それが知られていないかもしれないようにタイムスタンプの測定の不確実性は示されません。 経過時間の道を保つことができますが、wallclock時間の考えを全く持っていない送付者は接合して以来の経過時間を費やすかもしれません。
Schulzrinne, et al Standards Track [Page 24] RFC 1889 RTP January 1996
Schulzrinne、他Standards Track[24ページ]RFC1889RTP1996年1月
the session instead. This is assumed to be less than 68 years,
so the high bit will be zero. It is permissible to use the
sampling clock to estimate elapsed wallclock time. A sender that
has no notion of wallclock or elapsed time may set the NTP
timestamp to zero.
代わりにセッション。 これが68年未満であると思われるので、高いビットはゼロになるでしょう。 経過したwallclock時間を見積もるのに標本抽出時計を使用するのは許されています。 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 is 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タイムスタンプ: 同じユニットと同じくらいが無作為の状態でRTPタイムスタンプとしてデータ・パケットで相殺するのを除いた32ビットのNTPタイムスタンプ(above)と同時間までのCorresponds。 この通信はイントラと中間体同期にNTPタイムスタンプが同期するソースに使用されて、メディアの独立している受信機によって使用されて、名目上のRTPクロック周波数を見積もるかもしれません。 多くの場合、このタイムスタンプがどんな隣接しているデータ・パケットのRTPタイムスタンプとも等しくならないことに注意してください。 むしろ、それは、対応するNTPタイムスタンプからwallclock時間の標本抽出の瞬間にチェックしながら定期的によって維持されるようにRTPタイムスタンプカウンタとリアルタイムとの関係を使用することで計算されます。
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 is reset if the sender changes its SSRC
identifier.
送付者のパケットカウント: このSRパケットが発生した時まで伝送を始めて以来、32ビット、RTPデータ・パケットの総数は送付者で伝えました。 送付者がSSRC識別子を変えるなら、カウントはリセットされます。
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 is reset if the sender changes its SSRC
identifier. This field can be used to estimate the average
payload data rate.
送付者の八重奏カウント: このSRパケットが発生した時まで伝送を始めて以来、32ビット、ペイロード八重奏(すなわち、ヘッダーを含んでいないか、またはそっと歩かない)の総数はRTPデータ・パケットで送付者で伝えました。 送付者がSSRC識別子を変えるなら、カウントはリセットされます。 平均したペイロードデータ信号速度を見積もるのにこの分野を使用できます。
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 do not carry over statistics when a source changes its SSRC identifier due to a collision. These statistics are:
第3セクションがゼロを含むか、または最終以来この送付者によって聞かれた他のソースの数に応じたより多くのレセプションレポートブロックが報告します。 それぞれのレセプションレポートブロックは単独の同期ソースからRTPパケットのレセプションにおける統計を伝えます。 ソースが衝突のためSSRC識別子を変えるとき、受信機は統計を引き継ぎません。 これらの統計は以下の通りです。
SSRC_n (source identifier): 32 bits
The SSRC identifier of the source to which the information in
this reception report block pertains.
SSRC(ソース識別子): 32ビット、このレセプションにおける情報がブロックを報告するソースに関するSSRC識別子は関係します。
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
断片は損をしました: 前のSRかRRパケットが送られて、言い表されたのでaが修理されたときソースSSRCからのRTPデータ・パケットの部分がなくした8ビット
Schulzrinne, et al Standards Track [Page 25] RFC 1889 RTP January 1996
Schulzrinne、他Standards Track[25ページ]RFC1889RTP1996年1月
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.
バイナリーがあるポイント番号は分野の左の縁を指し示します。 (それは損失断片を256に掛けた後に整数部を取るのに同等です。) この断片は、失われたパケットの数が次のパラグラフで定義されるように予想されたパケットの数を割ったということになるように定義されます。 実現は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.
累積している数のパケットが損をしました: 合計が付番するレセプションの始まり以来なくされているソースSSRCからのRTPデータ・パケットの24ビット。 この数は、パケットの数がそれほど実際に受け取られたパケットの数を予想しませんでした、受け取られたパケットの数が最近のいずれか写しを含んでいるところでことになるように定義されます。 したがって、遅く到着するパケットは失われているように数えられません、そして、写しがあれば、損失は否定的であるかもしれません。 予想されたパケットの数は広げることであることのように最後の一連番号が受けたなるように次に定義されるように定義されて、以下は受け取られた初期シーケンス番号です。 これは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.
拡張最も高い一連番号は受けました: 32ビット、低16ビットはRTPデータ・パケットにソースSSRCから受け取られる中で最も高い一連番号を含んでいます、そして、最も重要な16ビットはAppendix A.1のアルゴリズムによると、維持されるかもしれない一連番号サイクルの対応するカウントがあるその一連番号を広げています。 彼らのスタート時代は有意差があるなら同じセッション中の異なった受信機が異なった拡大を一連番号に発生させることに注意してください。
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; 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.
interarrivalジター: タイムスタンプユニットで測定されて、符号のない整数として言い表されたRTPデータ・パケットinterarrival時間の統計的な変化の32ビットのAn見積り。 interarrivalジターJは、受信機のパケットスペースの違いDの平均偏差(絶対値を整える)に1組のパケットのために送付者と比べて、なるように定義されます。 以下の方程式で示されるように、これは2つのパケットのための「相対的なトランジット時間」の違いに同等です。 相対的なトランジット時間は同じユニットで測定された到着時点のパケットのRTPタイムスタンプと受信機の時計の違いです。
Schulzrinne, et al Standards Track [Page 26] RFC 1889 RTP January 1996
Schulzrinne、他Standards Track[26ページ]RFC1889RTP1996年1月
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
SiがパケットiからのRTPタイムスタンプであり、RiがDがそして、2つのパケットiとjに関して言い表されるかもしれないパケットi RTPタイムスタンプユニットの到着時刻であるなら
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 is 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
interarrivalジターはソースSSRCから各データ・パケットiを受け取るように絶え間なく計算されます、そのパケットと前のパケットi-1に到着順に(必ず連続してであるというわけではない)この違いDを使用して、公式によると
J=J+(|D(i-1,i)|-J)/16
J=J+、(| D(i-1、i)、|、-、J、)、/16
Whenever a reception report is issued, the current value of J is sampled.
レセプションレポートを発行するときはいつも、Jの現行価値は抽出されます。
The jitter calculation is prescribed here 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 [11]. A sample implementation is shown in Appendix A.8.
ジター計算は、プロフィールの独立しているモニターがレポートの有効な解釈をするのを許容するために異なった実現から来ながら、ここに定められます。 このアルゴリズムは最適の最初のオーダー見積り人です、そして、利得パラメタ1/16は集合[11]の妥当な速度を維持している間、良いノイズ・リダクション比を与えます。 サンプル実現はAppendix A.8に示されます。
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.
最後のSRタイムスタンプ(LSR): NTPタイムスタンプ(セクション4で説明されるように)の64ビットのうち中くらいの32が最新のRTCP送付者の一部として受けた32ビットはソースSSRCから(SR)パケットを報告します。 まだSRを全く受け取っていないなら、ゼロに分野を設定します。
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.
最後のSR(DLSR)以来、延着してください: ソースSSRCから最後のSRパケットを受けて、このレセプションを送ることの間の1/65536秒の単位で遅れであって、言い表された32ビットはブロックを報告します。 SSRCからSRパケットを全くまだ受け取っていないなら、DLSR分野をゼロに設定します。
Let SSRC_r denote the receiver issuing this receiver report. Source SSRC_n can compute the round 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 is illustrated in Fig. 2.
SSRC_rにこの受信機レポートを発行する受信機を指示させてください。 ソースSSRCは、このレセプションレポートブロックが受信されている時Aを記録することによって、SSRC_rに丸い伝播遅延を計算できます。 それは、最後のSRタイムスタンプ(LSR)分野を使用して、次に、往復の伝播が延着する休暇(A LSR--DLSR)にこの分野を引き算しながら、総往復の時間A-LSRについて計算します。 これは図2で例証されます。
This may be used as an approximate measure of distance to cluster receivers, although some links have very asymmetric delays.
いくつかのリンクには、非常に非対称の遅れがありますが、これは距離の大体の基準としてクラスタ受信機に使用されるかもしれません。
Schulzrinne, et al Standards Track [Page 27] RFC 1889 RTP January 1996
Schulzrinne、他Standards Track[27ページ]RFC1889RTP1996年1月
6.3.2 RR: Receiver report RTCP packet
6.3.2 RR: 受信機レポートRTCPパケット
[10 Nov 1995 11:33:25.125] [10 Nov 1995 11:33:36.5]
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)
(3024992016.125 s) v ^
r v ^ RR(n)
---------------------------------------------------------------->
|<-DLSR->|
(5.250 s)
[1995年11月10日の11:33:25.125] [1995年11月10日の11:33:36.5] n SR(n) A=b710: 8000 (46864.500秒間)----------------------------------------------------------------^^^>v^ntp_秒の=0xb44db705対dlsr=0x0005.4000(5.250)ntp_frac=0×20000000対lsr =0xb705: 2000(46853.125)(3024992016.125秒間)対r v^RR(n)---------------------------------------------------------------->| <-DLSR、->| (5.250秒間)
A 0xb710:8000 (46864.500 s) DLSR -0x0005:4000 ( 5.250 s) LSR -0xb705:2000 (46853.125 s) ------------------------------- delay 0x 6:2000 ( 6.125 s)
0xb710: 8000(46864.500秒間)DLSR0x0005: 4000(5.250秒間)LSR -0xb705: 2000 (46853.125秒間)------------------------------- 0x6:2000を遅らせてください。(6.125秒間)
Figure 2: Example for round-trip time computation
図2: 往復の時間計算のための例
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=RR=201 | length | header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of packet sender | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | SSRC_1 (SSRC of first source) | report +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block | fraction lost | cumulative number of packets lost | 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | extended highest sequence number received | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | interarrival jitter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | last SR (LSR) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | delay since last SR (DLSR) | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | SSRC_2 (SSRC of second source) | report +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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はRR=201と等しいです。| 長さ| ヘッダー+++++++++++++++++++++++++++++++++| パケット送付者のSSRC| +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | SSRC_1(最初のソースのSSRC)| レポート+++++++++++++++++++++++++++++++++ブロック| 断片は損をしました。| 累積している数のパケットが損をしました。| 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 拡張受け取られる中で最も高い一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | interarrivalジター| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 最後のSR(LSR)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 最後のSR(DLSR)以来の遅れ| +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | SSRC_2(セカンドソースのSSRC)| +++++++++++++++++++++++++++++++++ブロックを報告してください: ... : 2 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | プロフィール特有の拡大| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Schulzrinne, et al Standards Track [Page 28] RFC 1889 RTP January 1996
Schulzrinne、他Standards Track[28ページ]RFC1889RTP1996年1月
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.
パケットタイプ分野が一定の201を含んでいて、送付者情報の5つの単語が省略されるのを除いて(これらは、NTPと、RTPタイムスタンプと送付者のパケットと八重奏カウントです)、受信機レポート(RR)パケットの形式はSRパケットのものと同じです。 残っているフィールドには、同じ意味がSRパケットのようにあります。
An empty RR packet (RC = 0) is put at the head of a compound RTCP packet when there is no data transmission or reception to report.
報告するどんなデータ伝送もレセプションもないとき、空のRRパケット(RC=0)は合成RTCPパケットのヘッドに置かれます。
6.3.3 Extending the sender and receiver reports
6.3.3 送付者と受信機レポートを広げること。
A profile should define profile- or application-specific extensions to the sender report and receiver if there is additional information that should 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:
定期的に送付者か受信機に関して報告されるべきである追加情報があれば、プロフィールはプロフィールかアプリケーション特有の拡大を送付者レポートと受信機と定義するはずです。 より少ないオーバーヘッドを必要とするので別のRTCPパケットタイプを定義することに優先してこの方法は使用されるべきです:
o fewer octets in the packet (no RTCP header or SSRC field);
o パケット(RTCPヘッダーでないSSRC分野がない)の、より少ない八重奏。
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 そのプロフィールの下を走るアプリケーションがレセプションの後に直接アクセスしやすい位置でいつも拡大分野を予想するようにプログラムされるでしょう、したがって、より簡単でより速い構文解析は報告します。
If additional sender information is required, it should be included first in the extension for sender reports, but would not be present in receiver reports. If information about receivers is to be included, that data may 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.
追加送付者情報が必要であるなら、送付者レポートのための最初に拡大で含まれるべきですが、受信機レポートに存在していないでしょう。 受信機の情報が含まれることであるなら、そのデータはブロックのアレイとしてレセプションレポートブロックの既存のアレイに平行に構造化されるかもしれません。 すなわち、ブロックの数はRC分野によって示されるでしょう。
6.3.4 Analyzing sender and receiver reports
6.3.4 送付者と受信機レポートを分析すること。
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.
レセプション品質フィードバックが単に送付者に役に立つのではなく、他の受信機と第三者モニターのも役に立つと予想されます。 送付者はフィードバックに基づくトランスミッションを変更するかもしれません。 受信機は、問題がローカル、地方またはグローバルであるかを決定できます。 ネットワークマネージャはマルチキャスト分配のためにそれらのネットワークの性能を評価するために対応するRTPデータ・パケットではなく、RTCPパケットだけを受けるプロフィールから独立しているモニターを使用するかもしれません。
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
累積AE計数は、短いものと同様に長い期間にわたって測定をして、レポートの損失に対して弾力を提供するためにどんな2つのレポートの間でも違いについて計算できるように送付者情報と受信機レポートブロックの両方で使用されます。 分配の最近の品質を見積もるのに受け取られた最後の2つのレポートの違いを使用できます。 NTPタイムスタンプはそうです。
Schulzrinne, et al Standards Track [Page 29] RFC 1889 RTP January 1996
Schulzrinne、他Standards Track[29ページ]RFC1889RTP1996年1月
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.
2つのレポートの間隔の間、これらの違いからレートについて計算できるように、含まれています。 zデータの符号化において、そのタイムスタンプがクロックレートから独立しているので、コード化していてプロフィールから独立している品質モニタを実行するのは可能です。
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 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 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.
2つのレセプションレポートの間隔の間、例の計算はパケット損失率です。 失われたパケットの累積している数の違いはその間隔の間に失われた数を与えます。 広げることの最後の一連番号が受けた違いは間隔の間に予想されたパケットの数を与えます。 間隔の間、これらの2の比率はパケット損失断片です。 2つのレポートが連続していますが、そうでなければ、連続していないなら、この比率は断片無くなっている分野と等しくあるべきです。 秒に言い表されたNTPタイムスタンプの違いに損失断片を割ることによって、1秒あたりの損失率を得ることができます。 受け取られたパケットの数は失われた数を引いて予想されたパケットの数です。 また、予想されたパケットの数は、どんな損失見積りの統計的な正当性も判断するのに使用されるかもしれません。 例えば、失われた5つのパケットのうちの1には、200より低い意味が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.
送付者情報から、データを受信しないで、第三者モニターは間隔の間、平均したペイロードデータ信号速度と平均したパケットレートについて計算できます。 2つのものの比率を取ると、平均したペイロードサイズは与えられます。 パケット損失がパケットサイズから独立していると思うことができるなら、そして、平均したペイロードサイズ(または、対応するパケットサイズ)の倍がその受信機に有効な見かけのスループットを与える特定の受信機によって受け取られたパケットの数です。
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.
レポートの違い、断片を使用することで長期のパケット損失測定値を許容する累積AE計数に加えて、無くなっている分野はただ一つのレポートから短期的な測定を提供します。 セッションのサイズがレセプション州の情報がすべての受信機のために保たれないかもしれない十分に比例するとき、これが、より重要になるか、またはレポートの間隔は特定の受信機から1つのレポートしか受け取ったことができないくらい長くなります。
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. Since the interarrival jitter field is only a snapshot of the jitter at the time of a report, it may be necessary to analyze a number of reports from one receiver over time or from multiple receivers, e.g., within a single network.
interarrivalジター分野はネットワークの混雑の2番目の短期的な手段を提供します。 ジター測定は一時的な混雑を追跡しますが、パケット損失はしつこい混雑を追跡します。 パケット損失に通じる前にジター測定は混雑を示すかもしれません。 interarrivalジター分野がレポート時点のジターのスナップにすぎないので、時間がたつにつれての1台の受信機か複数の受信機からの多くのレポートを分析するのが必要であるかもしれません、例えば、ただ一つのネットワークの中で。
Schulzrinne, et al Standards Track [Page 30] RFC 1889 RTP January 1996
Schulzrinne、他Standards Track[30ページ]RFC1889RTP1996年1月
6.4 SDES: Source description RTCP packet
6.4SDES: ソース記述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=SDES=202 | length | header +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | SSRC/CSRC_1 | chunk +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 | SDES items | | ... | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | SSRC/CSRC_2 | chunk +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P| サウスカロライナ| PTはSDES=202と等しいです。| 長さ| ヘッダー..等しい| SSRC/CSRC_1| 塊+++++++++++++++++++++++++++++++++1| SDESの品目| | ... | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | SSRC/CSRC_2| 塊+++++++++++++++++++++++++++++++++2| SDESの品目| | ... | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
The SDES packet is a three-level structure composed of a header and zero or more chunks, each of of which is composed of items describing the source identified in that chunk. The items are described individually in subsequent sections.
SDESパケットはソースについて説明するとどれが項目で構成されるかについてその塊が中で特定されたかについてヘッダーとゼロか、より多くの塊でそれぞれ構成された3レベルの構造です。 項目はその後のセクションで個別に説明されます。
version (V), padding (P), length:
As described for the SR packet (see Section 6.3.1).
(P)、長さを水増しするバージョン(V): SRパケット(セクション6.3.1を見る)のために説明されるように。
packet type (PT): 8 bits
Contains the constant 202 to identify this as an RTCP SDES
packet.
パケットタイプ(太平洋標準時の): 8ビットのContains、これがRTCP SDESパケットであると認識する一定の202。
source count (SC): 5 bits
The number of SSRC/CSRC chunks contained in this SDES packet. A
value of zero is valid but useless.
ソースカウント(サウスカロライナ): SSRC/CSRC塊の数がこのSDESパケットに含んだ5ビット。 ゼロの値は、有効ですが、役に立ちません。
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.
各塊はゼロのリストがあとに続いたSSRC/CSRC識別子か、より多くの項目から成ります。(項目はSSRC/CSRCの情報を運びます)。 各塊は32ビットの境界を始めます。 各個条は8ビットのタイプ分野、テキスト(その結果、この2八重奏のヘッダーを含んでいない)の長さについて説明する8ビット・オクテットカウント、およびテキスト自体から成ります。 テキストがもう255の八重奏よりそうであることができますが、これがRTCP帯域幅消費を制限する必要性と一致していることに注意してください。
The text is encoded according to the UTF-2 encoding specified in Annex F of ISO standard 10646 [12,13]. This encoding is also known as UTF-8 or UTF-FSS. It is described in "File System Safe UCS Transformation Format (FSS_UTF)", X/Open Preliminary Specification, Document Number P316 and Unicode Technical Report #4. US-ASCII is a subset of this encoding and requires no additional encoding. The
ISOの標準の10646[12、13]のAnnex Fで指定されたUTF-2コード化に従って、テキストはコード化されます。 また、このコード化はUTF-8かUTF-FSSとして知られています。 それは「ファイルのシステムの安全なUCS変化形式(FSS_UTF)」、X/Open Preliminary Specification、Document Number P316、およびユニコードTechnical Report#4で説明されます。 米国-ASCIIは、このコード化の部分集合であり、追加コード化を必要としません。 The
Schulzrinne, et al Standards Track [Page 31] RFC 1889 RTP January 1996
Schulzrinne、他Standards Track[31ページ]RFC1889RTP1996年1月
presence of multi-octet encodings is indicated by setting the most significant bit of a character to a value of one.
マルチ八重奏encodingsの存在は、1の値へのキャラクタの最も重要なビットを設定することによって、示されます。
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 is 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, and the remainder as needed to pad until the next 32-bit boundary. A chunk with zero items (four null octets) is valid but useless.
項目が隣接である、すなわち、項目は個別に32ビットの境界に水増しされません。 いくつかのマルチ八重奏encodingsがヌル八重奏を含んでいるので、テキストは終えられた状態でヌルではありません。 各塊における項目のリストは必要に応じて1つ以上のヌル八重奏、および残りによって終えられます。リストの終わりを指示するためにゼロ項目タイプとしてその1番目をそれを解釈します。次の32ビットの境界までそっと歩きます。 項目がない(4つのヌル八重奏)塊は、有効ですが、役に立ちません。
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).
エンドシステムはそれら自身のソース識別子(SSRCと固定RTPヘッダーで同じ)を含む1つのSDESパケットを送ります。 ミキサーはそのような31以上のソースがあれば(セクション7を見てください)それが上の形式でSDES情報、または複数の完全なSDESパケットを受け取っているソースを寄付しながらそれぞれのための塊を含む1つのSDESパケットを送ります。
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.
現在定義されているSDESの品目は次のセクションで説明されます。 CNAMEの品目だけが義務的です。 ここに示された数個の項目が特定のプロフィールだけの役に立つかもしれませんが、項目タイプは皆、共有された使用を促進して、プロフィールの独立しているアプリケーションを簡素化するために1つの共用面積から選任されます。 追加項目は、プロフィールで形式数をIANAに示すことによって、定義されるかもしれません。
6.4.1 CNAME: Canonical end-point identifier SDES item
6.4.1 CNAME: 正準なエンドポイント識別子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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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| 長さ| ユーザとドメイン名… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The CNAME identifier has the following properties:
CNAME識別子には、以下の特性があります:
o Because the randomly allocated SSRC identifier may change if a
conflict is discovered or if a program is restarted, the CNAME
item is required to provide the binding from the SSRC
identifier to an identifier for the source that remains
constant.
o 手当たりしだいに割り当てられたSSRC識別子が、闘争が発見されるかどうか、またはプログラムが再開されるかどうかを変えるかもしれないので、CNAMEの品目がSSRC識別子から識別子までの結合を一定のままでいるソースに提供するのに必要です。
o Like the SSRC identifier, the CNAME identifier should also be
unique among all participants within one RTP session.
o また、SSRC識別子のように、CNAME識別子も1つのRTPセッション以内にすべての関係者の中でユニークであるべきです。
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 関連するRTPセッションの1セットの1人の関係者によって使用されたマルチメディアツールの向こう側に結合を提供するために、CNAMEはその関係者のために修理されるべきです。
Schulzrinne, et al Standards Track [Page 32] RFC 1889 RTP January 1996
Schulzrinne、他Standards Track[32ページ]RFC1889RTP1996年1月
o To facilitate third-party monitoring, the CNAME should be
suitable for either a program or a person to locate the source.
o 第三者モニターを容易にするなら、プログラムか人のどちらかがソースの場所を見つけるように、CNAMEは適当であるはずです。
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 [14], RFC 1035 [15] and Section 2.1 of RFC 1123 [16]; 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. 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.
したがって、可能であるときに、CNAMEをalgorithmicallyに引き出して、手動で入るべきではありません。 これらの必要条件を満たすために、プロフィールが交互の構文か意味論を指定しない場合、以下の形式は使用されるべきです。 ユーザ名がただ一つのユーザシステムのように利用可能でないなら、CNAMEの品目には形式" user@host "、または「ホスト」があるべきです。「ホスト」は両方の形式のための、リアルタイムデータが由来するホストの完全修飾ドメイン名です、RFC1123[16]のRFC1034[14]、RFC1035[15]、およびセクション2.1で指定された規則に従ってフォーマットされて。 または、RTPコミュニケーションに使用されるインタフェースにおけるホストの数値アドレスの標準のASCII表現。 例えば、IPバージョン4アドレスの標準のASCII表現はまた、点を打たれるとして知られている「ドット付き10進法」回路です。 他のアドレスタイプには互いにユニークなASCII表現があると予想されます。 完全修飾ドメイン名は、人間の観察者には、より便利であり、さらに、NAMEの品目を送る必要性を避けるかもしれませんが、それは、いくつかの操作環境で確かに得るのが、難しいか、または不可能であるかもしれません。 そのような環境に立候補することであるかもしれないアプリケーションは代わりにアドレスのASCII表現を使用するべきです。
Examples are "doe@sleepy.megacorp.com" or "doe@192.0.2.89" for a multi-user system. On a system with no user name, examples would be "sleepy.megacorp.com" or "192.0.2.89".
例は、マルチユーザーシステムのための" doe@sleepy.megacorp.com "か" doe@192.0.2.89 "です。 または、例がユーザ名のないシステムの上では、"sleepy.megacorp.com"であるだろう、「192.0 .2 0.89インチ」
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.
アプリケーションが、ユーザが1人のホストから複数のソースを作るのを許容するなら、この構文はユニークな識別子を各ソースに提供しないでしょう。 そのようなアプリケーションがさらにソースを特定するためにSSRCを当てにしなければならないでしょうか、またはそのアプリケーションのためのプロフィールはCNAME識別子に追加構文を指定しなければならないでしょう。
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.
各アプリケーションが独自にCNAMEを作成するなら、CNAMEsが同じでないかもしれない結果になることが、関連するRTPセッションの1セットの1人の関係者に属しながらマルチメディアツールの向こう側に結合を提供するのに必要でしょう。 交差しているメディア結合が必要であるなら、コーディネートツールでそれぞれの同じ値で外部的に構成されるべきツールのCNAMEに必要であるかもしれません。
Application writers should be aware that private network address assignments such as the Net-10 assignment proposed in RFC 1597 [17] may create network addresses that are not globally unique. This would
アプリケーション作家はRFC1597[17]で提案されたネット-10課題などの個人的なネットワーク・アドレス課題がグローバルにユニークでないネットワーク・アドレスを作成するかもしれないのを意識しているべきです。 これはそうするでしょう。
Schulzrinne, et al Standards Track [Page 33] RFC 1889 RTP January 1996
Schulzrinne、他Standards Track[33ページ]RFC1889RTP1996年1月
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 [18].) 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.
プライベート・アドレスにもかかわらず、公共のインターネットへのダイレクトIPの接続性がないホストがRTP-レベル翻訳者を通してそれらのRTPパケットを公共のインターネットに送らせるなら、非ユニークなCNAMEsに通じてください。 (また、RFC1627[18]を見てください。) 本件を扱うために、アプリケーションはユニークなCNAMEを構成する手段を提供するかもしれませんが、必要なら、プライベート・アドレスが露出されるのを妨げるためにプライベート・アドレスから場内放送までCNAMEsを翻訳するために、翻訳者の上に負担はあります。
6.4.2 NAME: User name SDES item
6.4.2 以下を命名してください。 ユーザ名前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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 名前=2| 長さ| ソースの一般名… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This is the real name used to describe the source, e.g., "John Doe, Bit Recycler, Megacorp". 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.
これはソース、例えば、「ジョン・ドウ、ビットリサイクル業者、Megacorp」について説明するのに使用される本名です。 それはユーザによって望まれていたどんなフォームにもあるかもしれません。 会議などのアプリケーションにおいて、このフォームの名前を関与しているリストにおける表示に最も望ましいかもしれなく、したがって、CNAME以外のそれらの項目について最も頻繁に送るかもしれません。 プロフィールはそのようなプライオリティを確立するかもしれません。 NAME値が少なくともセッションの持続時間に一定のままで残っていると予想されます。 セッションのときにすべての関係者の中で特有になるようにそれを当てにするべきではありません。
6.4.3 EMAIL: Electronic mail address SDES item
6.4.3 メールしてください: 電子メールアドレス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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | メール=3| 長さ| ソースのEメールアドレス… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The email address is formatted according to RFC 822 [19], for example, "John.Doe@megacorp.com". The EMAIL value is expected to remain constant for the duration of a session.
RFC822[19]、例えば、" John.Doe@megacorp.com "に従って、Eメールアドレスはフォーマットされます。 メール値がセッションの持続時間に一定のままで残っていると予想されます。
6.4.4 PHONE: Phone number SDES item
6.4.4 電話: 電話番号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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 電話=4| 長さ| ソースの電話番号… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
プラスサインが国際的なアクセスコードを置き換えていて、電話番号はフォーマットされるべきです。 +1 「例えば」、aのための1212がインチ合衆国で達する908 555。
Schulzrinne, et al Standards Track [Page 34] RFC 1889 RTP January 1996
Schulzrinne、他Standards Track[34ページ]RFC1889RTP1996年1月
6.4.5 LOC: Geographic user location SDES item
6.4.5 LOC: 地理的なユーザ位置の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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.4.6 TOOL: Application or tool name SDES item
6.4.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値がセッションの持続時間に一定のままで残っていると予想されます。
6.4.7 NOTE: Notice/status SDES item
6.4.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
以下の意味論はこの項目のために示されますが、これらか他の意味論がプロフィールによって明らかに定義されるかもしれません。 注意の品目はソースの現状、例えば「電話に関して、話すことができないこと」と説明する一時的なメッセージのために意図します。 または、セミナーの間、この項目は、話のタイトルを伝えるのに使用されるかもしれません。 これはレセプションレポートとCNAMEが送られるレートを減速させるでしょう、それを使用するべきであり、例外的な情報を運ぶしたがって、すべての関係者がきまりきって入れるべきではありません、その結果、プロトコルの性能を損ないます。 特に、それを含むべきではありません。
Schulzrinne, et al Standards Track [Page 35] RFC 1889 RTP January 1996
Schulzrinne、他Standards Track[35ページ]RFC1889RTP1996年1月
as an item in a user's configuration file nor automatically generated as in a quote-of-the-day.
今日の名言のようにユーザの構成ファイル的に自動的に発生しない項目として。
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帯域幅のその地域を取ることができるように、低下するかもしれません。 一時的なメッセージが不活発になるとき、注意の品目は、同じ繰返し率で数回伝えられ続けるべきですが、長さのひもで、受信機のゼロを信号に合わせてください。 しかしながら、また、それが繰返し率のわずかな倍数、または恐らく20-30回のRTCP間隔の間、受け取られないなら、受信機は、注意の品目が不活発であると考えるはずです。
6.4.8 PRIV: Private extensions SDES item
6.4.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 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.
この項目は、実験的であるかアプリケーション特有のSDES拡張子を定義するのに使用されます。 項目は長さストリング組から成る接頭語を含んでいます、項目の残りをいっぱいにする値のストリングが支えていて、必要な情報を運んで。 接頭語長さの分野は長さ8ビットです。 接頭語ストリングはこのアプリケーションが受けるかもしれない他のPRIVの品目に関して特有になるようにPRIVの品目を定義する人によって選ばれた名前です。 必要であるなら、アプリケーション創造者は、アプリケーション名と追加「副-タイプ」識別を使用するのを選ぶかもしれません。 あるいはまた、他のものが彼らが表す実体に基づく名前を選んで、次に、その実体の中で名前の使用を調整するのは、お勧めです。
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帯域幅を積みすぎるべきではありません。 それがすべてのアプリケーションのすべてのコントロールコミュニケーション要件を満たすことを意図しません。
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の品目の何らかのフォームが一般的なユーティリティがあると判明するなら、それは、接頭語が全く必要でないように、代わりにIANAに示されたレギュラーのSDES項目タイプに割り当てられるべきです。 これは、使用を簡素化して、伝達効率を増加させます。
Schulzrinne, et al Standards Track [Page 36] RFC 1889 RTP January 1996
Schulzrinne、他Standards Track[36ページ]RFC1889RTP1996年1月
6.5 BYE: Goodbye RTCP packet
6.5 さようなら: さようならの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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| length | reason for leaving ... (opt)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.3.1).
(P)、長さを水増しするバージョン(V): SRパケット(セクション6.3.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ビット。 ゼロのカウント値は、有効ですが、役に立ちません。
If a BYE packet is received by a mixer, the mixer forwards 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 is padded with null octets.
ミキサーでBYEパケットを受け取るなら、SSRC/CSRC識別子が変わりがない状態でミキサーはBYEパケットを進めます。 ミキサーが停止するなら、BYEパケットはそれが扱うソースを皆、寄付しながら、それで記載するべきです、それ自身のSSRC識別子と同様に。 任意に、BYEパケットはいなくなる理由、例えば、「カメラ不調」を示すテキストのそんなに多くの八重奏があとに続いた8ビット・オクテットカウントか「検出されたRTP輪」を含むかもしれません。 ストリングには、SDESのためのそんなに説明されるのと同じコード化があります。 ストリングが次の32ビットの境界にパケットをいっぱいにしているなら、ストリングは終えられた状態でヌルではありません。 そうでなければ、BYEパケットはヌル八重奏で水増しされます。
Schulzrinne, et al Standards Track [Page 37] RFC 1889 RTP January 1996
Schulzrinne、他Standards Track[37ページ]RFC1889RTP1996年1月
6.6 APP: Application-defined 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| 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 the Internet Assigned Numbers Authority using an RTCP packet type.
新しいアプリケーションと新機能が開発されているので、APPパケットは実験用のために意図します、パケットタイプ値の登録を必要としないで。 認識されていない名前があるAPPパケットは無視されるべきです。 テストしていた後に、より広い使用が正当であるなら、それぞれのAPPパケットがRTCPパケットタイプを使用するインターネットAssigned民数記Authorityに「副-タイプ」と名前欄なしで再定義されて、登録されるのは、お勧めです。
version (V), padding (P), length:
As described for the SR packet (see Section 6.3.1).
(P)、長さを水増しするバージョン(V): SRパケット(セクション6.3.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。
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の名前。 アプリケーション創造者は、アプリケーションのための新しいパケットタイプを定義したがっている他のものにアプリケーション名を使用して、次に、「副-タイプ」値の配分を調整するのを選ぶかもしれません。 あるいはまた、他のものが彼らが表す実体に基づく名前を選んで、次に、その実体の中で名前の使用を調整するのは、お勧めです。 大文字していて小文字のキャラクタが異なるとして扱われている状態で、存在という名前は4人のASCII文字の系列を解釈しました。
Schulzrinne, et al Standards Track [Page 38] RFC 1889 RTP January 1996
Schulzrinne、他Standards Track[38ページ]RFC1889RTP1996年1月
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), multicast address or pair of unicast addresses, and transport level destination port. (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)、マルチキャストアドレスまたは組が仕向港を平らにします。 (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つにおいて異ならなければならないか、または他のものからネットワークレベルで孤立しているに違いありません。
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識別子がユニークに保たれて、輪が検出される衝突解決アルゴリズムを説明します。
Schulzrinne, et al Standards Track [Page 39] RFC 1889 RTP January 1996
Schulzrinne、他Standards Track[39ページ]RFC1889RTP1996年1月
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に送ります。 これで、すべてのソースからのパケットが同じ翻訳者を通り抜けて、翻訳者のネットワークソースアドレスを運びますが、受信機が個々のソースを特定するのが可能になります。 数種類の翻訳者はデータを通して触れない状態で通るでしょうが、他のものはその結果データのコード化、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 will 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ヘッダーに続いて、ミキサーは彼らのSSRC識別子をCSRC名前の並びに挿入するはずです。 またあるパケットのための貢献しているソース自体であるミキサーは明らかにそのパケットのためのCSRCリストのそれ自身のSSRC識別子を含んでいるはずです。
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
アプリケーションがオーディオが好きであるので、翻訳者の上のミキサーの利点は複数のソースがインプット側で活発であるときにさえ、出力帯域幅が1つのソースのものに制限されるということです。 低バンド幅リンクに、これは重要であるかもしれません。 不都合はアウトプット側の上の受信機にはソースがそうである少しのコントロールもないということです。
Schulzrinne, et al Standards Track [Page 40] RFC 1889 RTP January 1996
Schulzrinne、他Standards Track[40ページ]RFC1889RTP1996年1月
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.
何らかのメカニズムがミキサーの遠隔操作のために実行されない場合、通り抜けるか、または音を消されます。 また、ミキサーによる同期情報の再生は、受信機が元の流れの中間体同期ができないことを意味します。マルチメディアミキサーはそれをするかもしれません。
[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 Figure 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 with 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 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.
また、恐らく変更されたデータ・パケットを進めることに加えて、翻訳者とミキサーはRTCPパケットを処理しなければなりません。 多くの場合、彼らはSDES情報に集めて、SRかRRパケットを変更するためにエンドシステムから受け取られた合成RTCPパケットを分解するでしょう。 この情報の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
データ・パケットを変更しない翻訳者(例えばマルチキャストアドレスとユニキャストアドレスの間でただ模写されるもの)は単にまた、変更されていないパケットをRTCPに送るかもしれません。 A
Schulzrinne, et al Standards Track [Page 41] RFC 1889 RTP January 1996
Schulzrinne、他Standards Track[41ページ]RFC1889RTP1996年1月
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.
何らかの方法でペイロードを変える翻訳者は、まだデータの特性とレセプション品質を反映しているように、SRとRRでの対応する変化を情報にしなければなりません。 これらの翻訳者はパケットをRTCPに絶対に送ってはいけません。 それはLSRとDLSR分野に基づく伝播遅れ測定値の精度を低下させるでしょう、一般に、したがって、翻訳者は1つのパケットへのさまざまな原因からSRとRRパケットに集めるべきではありません。
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つを割り当てるのを選ぶかもしれません。 すべての接続雲にこれらを送るでしょう、それぞれその雲に送られるデータ・ストリームに関する翻訳に対応しています、レセプションレポートが通常すべての関係者へのマルチキャストであるので。
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に送らなければなりません。
Schulzrinne, et al Standards Track [Page 42] RFC 1889 RTP January 1996
Schulzrinne、他Standards Track[42ページ]RFC1889RTP1996年1月
BYE: Translators forward BYE packets unchanged. Translators with
their own SSRC should generate BYE packets with that SSRC
identifier if they are about to cease forwarding packets.
さようなら: 翻訳者はパケットをBYEに変わりがない状態で送ります。 パケットを進めるのをやめようとしているなら、それら自身のSSRCの翻訳者はそのSSRC識別子でBYEパケットを発生させるべきです。
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 generates its own SR packets
with sender information about the mixed data stream and sends
them in the same direction as the mixed stream.
SR送付者情報: ソースの流れの特性がミックスで失われているので、ミキサーはそれが混ぜるソースから送付者情報を通り抜けません。 同期ソースとして、ミキサーは、複雑なデータ・ストリームの送付者情報でそれ自身の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 does not send these reception reports to the
other clouds and does 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に送らなければなりません。
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. The RTCP packet rate may be different on each side of the mixer.
ミキサーがSRかRRにパケットを送らないので、それらは合成RTCPパケットからSDESパケットを通常抽出するでしょう。 オーバーヘッドを最小にするために、SDESパケットからの塊は次にミキサーから発しながらSRかRRパケットの上で積み重ねられる単一のSDESパケットに集められるかもしれません。 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識別子空間は独立しています。 先に述べたように、この運転モードは輪を検出できないという危険を作成します。
Schulzrinne, et al Standards Track [Page 43] RFC 1889 RTP January 1996
Schulzrinne、他Standards Track[43ページ]RFC1889RTP1996年1月
BYE: Mixers need to forward BYE packets. They should generate BYE
packets with their own SSRC identifiers if they are about to
cease forwarding packets.
さようなら: ミキサーは、パケットをBYEに送る必要があります。 パケットを進めるのをやめようとしているなら、それらはそれら自身のSSRC識別子でBYEパケットを発生させるべきです。
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 Figure 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番目のミキサーは、既に混ぜられた入力パケットからのCSRC識別子とまざりもののない入力パケットからのSSRC識別子を使用することで出発しているパケットのためのCSRCリストを造るはずです。 これはM3とラベルされたミキサーM3から出力アークで示されます: 図の89(64、45)。 結果として起こるCSRCリストに15以上の識別子があるならどっと落さないミキサーに関するケースのように、残りを含むことができません。
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
識別子が手当たりしだいに選ばれているので、2つ以上のソースが同じ数を選ぶのは、可能です。 すべてのソースが同時に始められるとき、衝突は最も高い確率で起こります、例えば、いくつかのセッション管理イベントによって自動的に引き起こされると。 Nであるなら、ソースとLの数は識別子(ここと、32ビット)、2が出典を明示する確率の長さですか?
Schulzrinne, et al Standards Track [Page 44] RFC 1889 RTP January 1996
Schulzrinne、他Standards Track[44ページ]RFC1889RTP1996年1月
independently pick the same value can be approximated for large N [20] as 1 - exp(-N**2 / 2**(L+1)). For N=1000, the probability is roughly 10**-4.
独自に、大きいN[20]のために1として同じくらいが評価する選択に近似できます--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 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.
衝突確率は最初のパケット(データかコントロールのどちらか)を送る前に新しい情報筋が他の関係者からパケットを受け取る機会によってさらに減少させられます。 新しいソースが他の関係者(SSRC識別子による)の動向をおさえるなら、最初のパケットを伝える前に、新しいソースは、識別子が受け取られたいずれも衝突しないことを確かめるか、または再び選ぶことができます。
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. 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.
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. 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.
Because the random 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:
Because the random 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:
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 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 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
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
Schulzrinne, et al Standards Track [Page 45] RFC 1889 RTP January 1996
Schulzrinne, et al Standards Track [Page 45] RFC 1889 RTP January 1996
translators would produce two copies; bidirectional translators
would form a loop.
translators would produce two copies; bidirectional translators would form a loop.
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 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.
A source may discover that its own packets are being looped, or that packets from another source are being looped (a third-party loop).
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. Consequently, if a source changes its source transport address, it must also choose a new SSRC identifier to avoid being interpreted as a looped source. 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.
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. Consequently, if a source changes its source transport address, it must also choose a new SSRC identifier to avoid being interpreted as a looped source. 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.
To detect and resolve these conflicts, an RTP implementation must include an algorithm similar to the one described below. It 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.
To detect and resolve these conflicts, an RTP implementation must include an algorithm similar to the one described below. It 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.
This algorithm depends upon the source transport address being the same for both RTP and RTCP packets from a source. The algorithm would require modifications to support applications that don't meet this constraint.
This algorithm depends upon the source transport address being the same for both RTP and RTCP packets from a source. The algorithm would require modifications to support applications that don't meet this constraint.
This algorithm requires keeping a table indexed by source identifiers and containing the source transport address from which the identifier was (first) received, along with other state for that source. Each SSRC or CSRC identifier received in a data or control packet is looked up in this table in order to process that data or control information. For control packets, each element with its own SSRC, for example an SDES chunk, requires a separate lookup. (The SSRC in a reception report block is an exception.) If the SSRC or CSRC is not
This algorithm requires keeping a table indexed by source identifiers and containing the source transport address from which the identifier was (first) received, along with other state for that source. Each SSRC or CSRC identifier received in a data or control packet is looked up in this table in order to process that data or control information. For control packets, each element with its own SSRC, for example an SDES chunk, requires a separate lookup. (The SSRC in a reception report block is an exception.) If the SSRC or CSRC is not
Schulzrinne, et al Standards Track [Page 46] RFC 1889 RTP January 1996
Schulzrinne, et al Standards Track [Page 46] RFC 1889 RTP January 1996
found, a new entry is created. These table entries are removed when an RTCP BYE packet is received with the corresponding SSRC, or after no packets have arrived for a relatively long time (see Section 6.2.1).
found, a new entry is created. These table entries are removed when an RTCP BYE packet is received with the corresponding SSRC, or after no packets have arrived for a relatively long time (see Section 6.2.1).
In order to track loops of the participant's own data packets, it is also necessary to keep a separate list of source transport addresses (not identifiers) that have been found to be conflicting. Note that this should be a short list, usually empty. Each element in this list stores the source address 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).
In order to track loops of the participant's own data packets, it is also necessary to keep a separate list of source transport addresses (not identifiers) that have been found to be conflicting. Note that this should be a short list, usually empty. Each element in this list stores the source address 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).
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.
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 the SSRC or CSRC identifier is not found in the source
identifier table:
THEN create a new entry storing the source transport address
and the SSRC or CSRC along with other state.
CONTINUE with normal processing.
IF the SSRC or CSRC identifier is not found in the source identifier table: THEN create a new entry storing the source transport address and the SSRC or CSRC along with other state. CONTINUE with normal processing.
(identifier is found in the table)
(identifier is found in the table)
IF the source transport address from the packet matches
the one saved in the table entry for this identifier:
THEN CONTINUE with normal processing.
IF the source transport address from the packet matches the one saved in the table entry for this identifier: THEN CONTINUE with normal processing.
(an identifier collision or a loop is indicated)
(an identifier collision or a loop is indicated)
IF the source identifier is not the participant's own:
THEN IF the source identifier is from an RTCP SDES chunk
containing a CNAME item that differs from the CNAME
in the table entry:
THEN (optionally) count a third-party collision.
ELSE (optionally) count a third-party loop.
ABORT processing of data packet or control element.
IF the source identifier is not the participant's own: THEN IF the source identifier is from an RTCP SDES chunk containing a CNAME item that differs from the CNAME in the table entry: THEN (optionally) count a third-party collision. ELSE (optionally) count a third-party loop. ABORT processing of data packet or control element.
(a collision or loop of the participant's own data)
(a collision or loop of the participant's own data)
IF the source transport address is found in the list of
conflicting addresses:
THEN IF the source identifier is not from an RTCP SDES chunk
containing a CNAME item OR if that CNAME is the
participant's own:
IF the source transport address is found in the list of conflicting addresses: THEN IF the source identifier is not from an RTCP SDES chunk containing a CNAME item OR if that CNAME is the participant's own:
Schulzrinne, et al Standards Track [Page 47] RFC 1889 RTP January 1996
Schulzrinne, et al Standards Track [Page 47] RFC 1889 RTP January 1996
THEN (optionally) count occurrence of own traffic looped.
mark current time in conflicting address list entry.
ABORT processing of data packet or control element.
log occurrence of a collision.
create a new entry in the conflicting address list and
mark current time.
send an RTCP BYE packet with the old SSRC identifier.
choose a new identifier.
create a new entry in the source identifier table with the
old SSRC plus the source transport address from the packet
being processed.
CONTINUE with normal processing.
THEN (optionally) count occurrence of own traffic looped. mark current time in conflicting address list entry. ABORT processing of data packet or control element. log occurrence of a collision. create a new entry in the conflicting address list and mark current time. send an RTCP BYE packet with the old SSRC identifier. choose a new identifier. create a new entry in the source identifier table with the old SSRC plus the source transport address from the packet being processed. CONTINUE with normal processing.
In this algorithm, packets from a newly conflicting source address will be ignored and packets from the original source will be kept. (If the original source was through a mixer and later the same source is received directly, the receiver may be well advised to switch unless other sources in the mix would be lost.) 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 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.
In this algorithm, packets from a newly conflicting source address will be ignored and packets from the original source will be kept. (If the original source was through a mixer and later the same source is received directly, the receiver may be well advised to switch unless other sources in the mix would be lost.) 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 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.
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 should be generated and the process repeated.
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 should be generated and the process repeated.
A loop of data packets to a multicast destination can cause severe network flooding. All mixers and translators are required to 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 might be attempted again periodically after a long, random time (on the order of minutes).
A loop of data packets to a multicast destination can cause severe network flooding. All mixers and translators are required to 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 might be attempted again periodically after a long, random time (on the order of minutes).
Schulzrinne, et al Standards Track [Page 48] RFC 1889 RTP January 1996
Schulzrinne, et al Standards Track [Page 48] RFC 1889 RTP January 1996
9. Security
9. Security
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 recently been specified for IP. Since the need for a confidentiality service is well established in the initial audio and video applications that are expected to use RTP, a confidentiality service is defined in the next section for use with RTP and RTCP until lower layer services are available. The overhead on the protocol for this service is low, so the penalty will be minimal if this service is obsoleted by lower layer services in the future.
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 recently been specified for IP. Since the need for a confidentiality service is well established in the initial audio and video applications that are expected to use RTP, a confidentiality service is defined in the next section for use with RTP and RTCP until lower layer services are available. The overhead on the protocol for this service is low, so the penalty will be minimal if this service is obsoleted by lower layer services in the future.
Alternatively, other services, other implementations of services and other algorithms may be defined for RTP in the future if warranted. The selection presented here is meant to simplify implementation of interoperable, secure applications and provide guidance to implementors. 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.
Alternatively, other services, other implementations of services and other algorithms may be defined for RTP in the future if warranted. The selection presented here is meant to simplify implementation of interoperable, secure applications and provide guidance to implementors. 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.
Key distribution and certificates are outside the scope of this document.
Key distribution and certificates are outside the scope of this document.
9.1 Confidentiality
9.1 Confidentiality
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.
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 encryption of RTP or RTCP is desired, 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 is prepended to the unit before encryption to deter known plaintext attacks. For RTP, no prefix is required because the sequence number and timestamp fields are initialized with random offsets.
When encryption of RTP or RTCP is desired, 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 is prepended to the unit before encryption to deter known plaintext attacks. For RTP, no prefix is required because the sequence number and timestamp fields are initialized with random offsets.
For RTCP, it is allowed to split a compound RTCP packet into two lower-layer 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 encrypted) to satisfy the requirement that all compound RTCP packets begin with an SR or RR packet.
For RTCP, it is allowed to split a compound RTCP packet into two lower-layer 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 encrypted) to satisfy the requirement that all compound RTCP packets begin with an SR or RR packet.
Schulzrinne, et al Standards Track [Page 49] RFC 1889 RTP January 1996
Schulzrinne, et al Standards Track [Page 49] RFC 1889 RTP January 1996
UDP packet UDP packet
------------------------------------- -------------------------
[32-bit ][ ][ # ] [ # sender # receiver]
[random ][ RR ][SDES # CNAME, ...] [ SR # report # report ]
[integer][(empty)][ # ] [ # # ]
------------------------------------- -------------------------
encrypted not encrypted
UDP packet UDP packet ------------------------------------- ------------------------- [32-bit ][ ][ # ] [ # sender # receiver] [random ][ RR ][SDES # CNAME, ...] [ SR # report # report ] [integer][(empty)][ # ] [ # # ] ------------------------------------- ------------------------- encrypted not encrypted
#: SSRC
#: SSRC
Figure 4: Encrypted and non-encrypted RTCP packets
Figure 4: Encrypted and non-encrypted RTCP packets
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.
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.
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 [21], 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 [22]. Implementations that support encryption should always support the DES algorithm in CBC mode as the default to maximize interoperability. This method is chosen because it has been demonstrated to be easy and practical to use in experimental audio and video tools in operation on the Internet. Other encryption algorithms may be specified dynamically for a session by non-RTP means.
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 [21], 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 [22]. Implementations that support encryption should always support the DES algorithm in CBC mode as the default to maximize interoperability. This method is chosen because it has been demonstrated to be easy and practical to use in experimental audio and video tools in operation on the Internet. Other encryption algorithms may be specified dynamically for a session by non-RTP means.
As an alternative to encryption 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 should 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.
As an alternative to encryption 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 should 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.
9.2 Authentication and Message Integrity
9.2 Authentication and Message Integrity
Authentication and message integrity are not defined in the current specification of RTP 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 in the future.
Authentication and message integrity are not defined in the current specification of RTP 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 in the future.
Schulzrinne, et al Standards Track [Page 50] RFC 1889 RTP January 1996
Schulzrinne, et al Standards Track [Page 50] RFC 1889 RTP January 1996
10. RTP over Network and Transport Protocols
10. RTP over Network and Transport Protocols
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.
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 relies on the underlying protocol(s) to provide demultiplexing of RTP data and RTCP control streams. For UDP and similar protocols, RTP uses an even port number and the corresponding RTCP stream uses the next higher (odd) port number. If an application is supplied with an odd number for use as the RTP port, it should replace this number with the next lower (even) number.
RTP relies on the underlying protocol(s) to provide demultiplexing of RTP data and RTCP control streams. For UDP and similar protocols, RTP uses an even port number and the corresponding RTCP stream uses the next higher (odd) port number. If an application is supplied with an odd number for use as the RTP port, it should replace this number with the next lower (even) number.
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 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.
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.
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.
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.
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.
11. Summary of Protocol Constants
11. Summary of Protocol Constants
This section contains a summary listing of the constants defined in this specification.
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 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.
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 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.
Schulzrinne, et al Standards Track [Page 51] RFC 1889 RTP January 1996
Schulzrinne, et al Standards Track [Page 51] RFC 1889 RTP January 1996
11.1 RTCP packet types
11.1 RTCP packet types
abbrev. name value SR sender report 200 RR receiver report 201 SDES source description 202 BYE goodbye 203 APP application-defined 204
abbrev. name value SR sender report 200 RR receiver report 201 SDES source description 202 BYE goodbye 203 APP application-defined 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.
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.
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.
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.
Other constants are assigned by IANA. Experimenters are encouraged to register the numbers they need for experiments, and then unregister those which prove to be unneeded.
Other constants are assigned by IANA. Experimenters are encouraged to register the numbers they need for experiments, and then unregister those which prove to be unneeded.
11.2 SDES types
11.2 SDES types
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
Other constants are assigned by IANA. Experimenters are encouraged to register the numbers they need for experiments, and then unregister those which prove to be unneeded.
Other constants are assigned by IANA. Experimenters are encouraged to register the numbers they need for experiments, and then unregister those which prove to be unneeded.
Schulzrinne, et al Standards Track [Page 52] RFC 1889 RTP January 1996
Schulzrinne, et al Standards Track [Page 52] RFC 1889 RTP January 1996
12. RTP Profiles and Payload Format Specifications
12. 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 so there is no explicit indication of which profile is in use. A profile for audio and video applications may be found in the companion Internet-Draft draft-ietf-avt-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 so there is no explicit indication of which profile is in use. A profile for audio and video applications may be found in the companion Internet-Draft draft-ietf-avt-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).
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).
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).
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).
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).
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).
Schulzrinne, et al Standards Track [Page 53] RFC 1889 RTP January 1996
Schulzrinne, et al Standards Track [Page 53] RFC 1889 RTP January 1996
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).
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).
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.3.3).
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.3.3).
SDES use: The profile may specify the relative priorities for RTCP
SDES items to be transmitted or excluded entirely (Section
6.2.2); an alternate syntax or semantics for the CNAME item
(Section 6.4.1); the format of the LOC item (Section 6.4.5); the
semantics and use of the NOTE item (Section 6.4.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.2.2); an alternate syntax or semantics for the CNAME item (Section 6.4.1); the format of the LOC item (Section 6.4.5); the semantics and use of the NOTE item (Section 6.4.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).
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).
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.
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 10 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 10 may be specified.
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 10).
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 10).
Schulzrinne, et al Standards Track [Page 54] RFC 1889 RTP January 1996
Schulzrinne, et al Standards Track [Page 54] RFC 1889 RTP January 1996
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 the Internet Assigned Numbers Authority 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 the Internet Assigned Numbers Authority and publishing their descriptions in an addendum to the profile or in a payload format specification.
Schulzrinne, et al Standards Track [Page 55] RFC 1889 RTP January 1996
Schulzrinne, et al Standards Track [Page 55] RFC 1889 RTP January 1996
A. Algorithms
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 (RFC XXXX)
*/
#include <sys/types.h>
/* * rtp.h -- RTP header file (RFC XXXX) */ #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 56] RFC 1889 RTP January 1996
Schulzrinne, et al Standards Track [Page 56] RFC 1889 RTP January 1996
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 */
u_int16 seq; /* 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 */ u_int16 seq; /* 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 57] RFC 1889 RTP January 1996
Schulzrinne, et al Standards Track [Page 57] RFC 1889 RTP January 1996
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 58] RFC 1889 RTP January 1996
Schulzrinne, et al Standards Track [Page 58] RFC 1889 RTP January 1996
/* 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 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 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, in particular it must not be
equal to SR or RR.
o The payload type must be known, 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.
o The X bit must be zero if the profile does not specify that
the header extension mechanism may be used. Otherwise, the
o The X bit must be zero if the profile does not specify that the header extension mechanism may be used. Otherwise, the
Schulzrinne, et al Standards Track [Page 59] RFC 1889 RTP January 1996
Schulzrinne, et al Standards Track [Page 59] RFC 1889 RTP January 1996
extension length field must be less than the total packet size
minus the fixed header length and padding.
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.
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.
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 should be set to the number of sequential packets required before declaring a source valid (parameter MIN_SEQUENTIAL ) and s->max_seq initialized to seq-1 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.
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 should be set to the number of sequential packets required before declaring a source valid (parameter MIN_SEQUENTIAL ) and s->max_seq initialized to seq-1 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.
Otherwise, the value zero is returned to indicate that the validation failed, and the bad sequence number 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 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
Typical values for the parameters are shown, based on a maximum misordering time of 2 seconds at 50 packets/second and a maximum
Schulzrinne, et al Standards Track [Page 60] RFC 1889 RTP January 1996
Schulzrinne, et al Standards Track [Page 60] RFC 1889 RTP January 1996
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.
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 - 1;
s->max_seq = seq;
s->bad_seq = RTP_SEQ_MOD + 1;
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 - 1; s->max_seq = seq; s->bad_seq = RTP_SEQ_MOD + 1; 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;
}
} 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) {
/*
/* * 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; } } 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) { /*
Schulzrinne, et al Standards Track [Page 61] RFC 1889 RTP January 1996
Schulzrinne, et al Standards Track [Page 61] RFC 1889 RTP January 1996
* 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;
}
* 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 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 could 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 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 could choose to discard all data packets from a source until a valid RTCP packet has been received from that source.
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.
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.
Schulzrinne, et al Standards Track [Page 62] RFC 1889 RTP January 1996
Schulzrinne, et al Standards Track [Page 62] RFC 1889 RTP January 1996
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.
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 can be applied to RTCP packets.
The following checks can 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 only the last should possibly need
padding.
o The padding bit (P) should be zero for the first packet of a compound RTCP packet because only the last should possibly need padding.
o The length fields of the individual RTCP packets must total 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 total 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);
if (r != end) {
/* something wrong with packet format */
}
if (r != end) { /* something wrong with packet format */ }
A.3 Determining the Number of RTP Packets Expected and Lost
A.3 Determining the Number of RTP Packets Expected and Lost
In order to compute packet loss rates, the number of 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
In order to compute packet loss rates, the number of 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
Schulzrinne, et al Standards Track [Page 63] RFC 1889 RTP January 1996
Schulzrinne, et al Standards Track [Page 63] RFC 1889 RTP January 1996
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.
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 number is carried in 24 bits, it should be clamped at 0xffffff rather than wrap around to zero.
Since this number is carried in 24 bits, it should be clamped at 0xffffff rather than wrap around to zero.
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.
A.4 Generating SDES RTCP Packets
A.4 Generating SDES RTCP Packets
This function builds one SDES chunk into buffer b composed of argc items supplied in arrays type , value and length b
This function builds one SDES chunk into buffer b composed of argc items supplied in arrays type , value and length 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;
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;
Schulzrinne, et al Standards Track [Page 64] RFC 1889 RTP January 1996
Schulzrinne, et al Standards Track [Page 64] RFC 1889 RTP January 1996
int i;
int len;
int pad;
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; }
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) {
while (--count >= 0) {
Schulzrinne, et al Standards Track [Page 65] RFC 1889 RTP January 1996
Schulzrinne, et al Standards Track [Page 65] RFC 1889 RTP January 1996
rsp = &sd->item[0];
if (rsp >= end) break;
s = find_member(sd->src);
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 [23]. 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 [23]. 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
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 [7].
"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 [7].
Use of this or similar routine is suggested 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 similar routine is suggested 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.
Schulzrinne, et al Standards Track [Page 66] RFC 1889 RTP January 1996
Schulzrinne, et al Standards Track [Page 66] RFC 1889 RTP January 1996
/*
* 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);
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 */
MDInit (&context); 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;
/* * 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;
Schulzrinne, et al Standards Track [Page 67] RFC 1889 RTP January 1996
Schulzrinne, et al Standards Track [Page 67] RFC 1889 RTP January 1996
pid_t pid;
u_long hid;
uid_t uid;
gid_t gid;
struct utsname name;
} s;
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();
gettimeofday、(s.tv、0)。 uname(s.名)。 s. タイプ=はタイプします。 s. cpuは時計()と等しいです。 s. pidはgetpid()と等しいです。 s. =gethostid()を隠しました。 s. uidはgetuid()と等しいです。 s. ヒツジ暈倒病はgetgid()と等しいです。
return md_32((char *)&s, sizeof(s));
} /* random32 */
Mdの_32(炭*)とs、sizeof(s))を返してください。 } /*random32*/
A.7 Computing the RTCP Transmission Interval
RTCPトランスミッション間隔を計算するA.7
The following function returns the time between transmissions of RTCP packets, measured in seconds. It should be called after sending one compound RTCP packet to calculate the delay until the next should be sent. This function should also be called to calculate the delay before sending the first RTCP packet upon startup rather than send the packet immediately. This avoids any burst of RTCP packets if an application is started at many sites simultaneously, for example as a result of a session announcement.
以下の機能は秒に測定されたRTCPパケットのトランスミッションの間に時間を返します。 次までの遅れが送られるべきであると見込むために1つの合成RTCPパケットを送った後に、それは呼ばれるべきです。 また、この機能は、すぐにパケットを送るよりむしろ最初のRTCPパケットを始動に送る前に遅れについて計算するために呼ばれるべきです。 アプリケーションが同時に多くのサイトで始められるなら、これはRTCPパケットのどんな炸裂も避けます、例えば、セッション発表の結果、。
The parameters have the following meaning:
パラメタには、以下の意味があります:
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 should be 5% of the "session bandwidth"
parameter supplied to the application at startup.
rtcp_bw: 目標RTCP帯域幅、すなわち、RTCPパケットに1秒あたりの八重奏におけるこのセッションのすべてのメンバーによって使用される総帯域幅。 これは始動でアプリケーションに提供された「セッション帯域幅」パラメタの5%であるべきです。
senders: Number of active senders since sending last report, known
from construction of receiver reports for this RTCP packet.
Includes ourselves, if we also sent during this interval.
送付者: 発信以来の活発な送付者の数はこのRTCPパケットのための受信機レポートの工事から知られているレポートを持続します。 また、私たちがこの間隔の間、発信したなら、自分達を含んでいます。
members: The estimated number of session members, including
ourselves. Incremented as we discover new session members from
the receipt of RTP or RTCP packets, and decremented as session
members leave (via RTCP BYE) or their state is timed out (30
minutes is recommended). On the first call, this parameter
should have the value 1.
メンバー: 自分達を含むセッションメンバーの概算数。 私たちが発見するように増加されて、パケットであって、セッションメンバーとして減少したRTPかRTCPの領収書からの新しいセッションメンバーがいなくなるか(RTCP BYEを通して)、または彼らの状態は外で調節されています(30分はお勧めです)。 準備ラッパのときに、このパラメタには、値1があるべきです。
Schulzrinne, et al Standards Track [Page 68] RFC 1889 RTP January 1996
Schulzrinne、他Standards Track[68ページ]RFC1889RTP1996年1月
we_sent: Flag that is true if we have sent data during the last two
RTCP intervals. If the flag is true, the compound RTCP packet
just sent contained an SR packet.
私たち、_は発信しました: 私たちがここ2回のRTCP間隔の間、データを送るなら本当の旗。 旗が本当であるなら、ただ送られた合成RTCPパケットはSRパケットを含みました。
packet_size: The size of the compound RTCP packet just sent, in
octets, including the network encapsulation (e.g., 28 octets for
UDP over IP).
パケット_サイズ: 合成RTCPパケットのサイズはただ発信しました、八重奏で、ネットワークカプセル化(例えば、IPの上のUDPのための28の八重奏)を含んでいて。
avg_rtcp_size: Pointer to estimator for compound RTCP packet size;
initialized and updated by this function for the packet just
sent, and also updated by an identical line of code in the RTCP
receive routine for every RTCP packet received from other
participants in the session.
avg_rtcp_サイズ: 合成RTCPパケットサイズのための見積り人へのポインタ。 ただ送って、また、RTCPのコードの同じ行によってアップデートされたパケットのためにこの機能で初期化して、アップデートして、セッションのときに他の関係者から受け取られたあらゆるRTCPパケットのためのルーチンを受け取ってください。
initial: Flag that is true for the first call upon startup to
calculate the time until the first report should be sent.
頭文字をつけます: 準備ラッパに、最初のレポートまで時間について計算する始動のときに本当の旗を送るべきです。
#include <math.h>
#<math.h>を含めてください。
double rtcp_interval(int members,
int senders,
double rtcp_bw,
int we_sent,
int packet_size,
int *avg_rtcp_size,
int initial)
{
/*
* Minimum 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);
/*
* Gain (smoothing constant) for the low-pass filter that
最小の時間の. 今回の*が、セッション*が小さいときに、レポートが'凝集すること'を防ぐこのサイト(秒の)と大数の法則からのRTCPパケットの間の/**は、*外で交通を整えるのを助けていません。二重rtcp_間隔(_intメンバー(int送付者)はrtcp_bwを倍にして、int私たちは送られて、intなパケット_サイズです、int*avg_rtcp_サイズ、intに初期である)、また、それは、a*ネットワークパーティション*/二重なconst RTCP_MIN_タイム誌=5のような一時的な供給停止の間、ばかばかしく小さくなりながら、*からレポート間隔を控えます; 活発な*送付者(*この断片が1か2人の活発な送付者との典型的な*セッションにおいて、計算されたレポート*時間がおよそ最小のレポート時間と等しいように選ばれたので、私たちは不必要に受信機レポートを減速させません。)*受信機断片の中で共有されるべきRTCP帯域幅の/**部分は1であるに違いありません--送付者断片、*/二重な_const RTCP_SENDER BW_FRACTIONは0.25と等しいです; 二重const RTCP_RCVR_BW_FRACTION=(1-RTCP_SENDER_BW_FRACTION); 低いパスfのための/**利得(定数を整えます)ilter、それ
Schulzrinne, et al Standards Track [Page 69] RFC 1889 RTP January 1996
Schulzrinne、他Standards Track[69ページ]RFC1889RTP1996年1月
* estimates the average RTCP packet size (see Cadzow reference).
*/
double const RTCP_SIZE_GAIN = (1./16.);
* 平均したRTCPがパケットサイズ(Cadzow参照を見る)であると見積もっています。 */二重_const RTCP_SIZE GAINは(1./16)と等しいです。
double t; /* interval */
double rtcp_min_time = RTCP_MIN_TIME;
int n; /* no. of members for computation */
tを倍にしてください。 /*間隔*/二重なrtcp_分_時間はRTCP_MIN_タイム誌と等しいです。 int n。 計算*/のためのメンバーの/*No.
/*
* 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. The average RTCP size is initialized
* to 128 octets which is conservative (it assumes everyone else
* is generating SRs instead of RRs: 20 IP + 8 UDP + 52 SR + 48
* SDES CNAME).
*/
if (initial) {
rtcp_min_time /= 2;
*avg_rtcp_size = 128;
}
それでも、無作為化、そのように他の*ソースに関して学ぶと報告する前の時間*のいくつかにレポート間隔を許容するのは正しい*間隔まで、より急速に一点に集まるでしょうが、アプリケーション上にから始まるところの/**まさしくその準備ラッパは、より迅速な通知に分*遅れの半分を使用します。 平均したRTCPサイズがそう、*初期化されて、128の八重奏に、どれが保守的であるか、(それ、RRs: 20IP+8UDP+52SR+48*SDES CNAMEの代わりにSRsが、*が発生させている他の人皆であると仮定する、) */、(初期)rtcp_分_時間/=2(*avg_rtcp_サイズ=128)
/*
* If there were active senders, give them at least a minimum
* share of the RTCP bandwidth. Otherwise all participants share
* the RTCP bandwidth equally.
*/
n = members;
if (senders > 0 && 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;
}
}
**そこであるなら、/は活発な送付者であり、少なくともRTCP帯域幅の最小の*シェアを彼らに与えてください。 さもなければ、すべての関係者が*を共有する、RTCP帯域幅、等しく。 */nはメンバーと等しいです。 (送付者>0、送付者<メンバー*RTCP_SENDER_BW_FRACTION)(私たち、送られた_) rtcp_bw*はRTCP_RCVR_BW_FRACTIONと等しいです; rtcp_bw*はRTCP_SENDER_BW_FRACTIONと等しいです; n=送付者、ほかに、n-=送付者
/*
* Update the average size estimate by the size of the report
* packet we just sent.
*/
*avg_rtcp_size += (packet_size - *avg_rtcp_size)*RTCP_SIZE_GAIN;
私たちがただ送ったレポート*パケットのサイズに従って、/**は平均のサイズ見積りをアップデートします。 */*avg_rtcp_サイズ+=(パケット_サイズ--*avg_rtcp_サイズ)*RTCP_サイズ_は獲得します。
/*
* The effective number of sites times the average packet size is
* the total number of octets sent when each site sends a report.
有効が付番する各サイトがレポートを送るサイト回平均したパケットサイズが八重奏の総数が送った*であるの/**。
Schulzrinne, et al Standards Track [Page 70] RFC 1889 RTP January 1996
Schulzrinne、他Standards Track[70ページ]RFC1889RTP1996年1月
* 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;
* 有効な帯域幅にこれを割るとそれらのパケットを送らなければならない時間*間隔が与えられる、*帯域幅目標を達成してください、最小限が励行されている状態で。 その*時間間隔では、私たちが1つのレポートを送るので、また、今回はレポートの間の私たちの*平均時間です。 */tは(*avg_rtcp_サイズ)*n/rtcp_bwと等しいです。 (t<_時間rtcp_分)t=rtcp_分_時間であるなら。
/*
* 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.
*/
return t * (drand48() + 0.5);
}
交通を避ける/**は他の*サイトとの故意でない同期からはち切れて、*乱数が0.5の間で一様に*tと1.5*tを分配したので、次に、私たちは次の実際のレポート間隔を選びます。 */リターンt*(drand48()+0.5)。 }
A.8 Estimating the Interarrival Jitter
Interarrivalジターを見積もっているA.8
The code fragments below implement the algorithm given in Section 6.3.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.3.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)。
Schulzrinne, et al Standards Track [Page 71] RFC 1889 RTP January 1996
Schulzrinne、他Standards Track[71ページ]RFC1889RTP1996年1月
In this case, the estimate is sampled for the reception report as:
この場合、見積りはレセプションレポートのために以下として抽出されます。
rr->jitter = s->jitter >> 4;
rr>のジター=、s->、ジター、>>4。
B. Security Considerations
B。 セキュリティ問題
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 [24]. Therefore, the use of security mechanisms with RTP is important. These mechanisms are discussed in Section 9.
RTPは基本的なプロトコルと同じセキュリティ負債が欠点です。 例えば、詐欺師は、ソースか目的地ネットワーク・アドレスを見せかけるか、またはヘッダーかペイロードを変えることができます。 RTCPの中では、CNAMEとNAME情報は、別の関係者をまねるのに使用されるかもしれません。 さらに、IPマルチキャストでRTPを送るかもしれません。(それは、送付者がデータのすべての受信機が発信したのを知るどんなダイレクト手段も提供しないで、またその結果プライバシーの測定を全く提供しません)。 または、正しさ、ユーザはそれらが、より伝統的なフォームに関するネットワークコミュニケーション[24]と共にあったよりオーディオとビデオコミュニケーションでプライバシーの問題に敏感であるかもしれません。 したがって、RTPとのセキュリティー対策の使用は重要です。 セクション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-レベル翻訳者かミキサーが、RTP交通がファイアウォールの後ろでホストに届くのを許容するのに使用されるかもしれません。 これらの装置のデザインとインストールとファイアウォールの後ろの使用のRTPアプリケーションの入場で適切なファイアウォールセキュリティ原則と習慣(このドキュメントの範囲にある)に従うべきです。
C. Authors' Addresses
C。 作者のアドレス
Henning Schulzrinne GMD Fokus Hardenbergplatz 2 D-10623 Berlin Germany
ヘニングSchulzrinne GMD Fokus Hardenbergplatz2D-10623ベルリンドイツ
EMail: schulzrinne@fokus.gmd.de
メール: schulzrinne@fokus.gmd.de
Stephen L. Casner Precept Software, Inc. 21580 Stevens Creek Boulevard, Suite 207 Cupertino, CA 95014 United States
スティーブンL.Casner教訓ソフトウェアInc.21580スティーブンスクリーク並木街、Suite207カルパチーノ、カリフォルニア95014合衆国
EMail: casner@precept.com
メール: casner@precept.com
Schulzrinne, et al Standards Track [Page 72] RFC 1889 RTP January 1996
Schulzrinne、他Standards Track[72ページ]RFC1889RTP1996年1月
Ron Frederick Xerox Palo Alto Research Center 3333 Coyote Hill Road Palo Alto, CA 94304 United States
ロンフレディリックゼロックスパロアルト研究センター3333コヨーテヒル・Roadカリフォルニア94304パロアルト(合衆国)
EMail: frederic@parc.xerox.com
メール: frederic@parc.xerox.com
Van Jacobson MS 46a-1121 Lawrence Berkeley National Laboratory Berkeley, CA 94720 United States
ヴァン・ジェーコブソン・MS46a-1121ローレンス・バークレー、国家の研究所カリフォルニア94720合衆国バークレー
EMail: van@ee.lbl.gov
メール: van@ee.lbl.gov
Acknowledgments
承認
This memorandum is based on discussions within the IETF Audio/Video Transport working group chaired by Stephen Casner. 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.
このメモはスティーブンCasnerによってまとめられたIETF Audio/ビデオTransportワーキンググループの中で議論に基づいています。 現在のプロトコルはNetwork Voiceプロトコル、Packet Videoプロトコル(ダニー・コーエンとランディ・コール)、および大タンクアプリケーションで実行されたプロトコル(バンジェーコブソンとスティーブMcCanne)で起源を発します。 クリスチャンのHuitemaは無作為の識別子ジェネレータのための考えを提供しました。
D. Bibliography
D。 図書目録
[1] D. D. Clark and D. L. Tennenhouse, "Architectural considerations
for a new generation of protocols," in SIGCOMM Symposium on
Communications Architectures and Protocols , (Philadelphia,
Pennsylvania), pp. 200--208, IEEE, Sept. 1990. Computer
Communications Review, Vol. 20(4), Sept. 1990.
[1] D.D.クラークとD.L.Tennenhouse、Communications ArchitecturesとプロトコルのSIGCOMM Symposium、(フィラデルフィア(ペンシルバニア))、ページの「プロトコルの新しい世代建築問題」 200--208 1990年9月のIEEE。 コンピュータコミュニケーションレビュー、Vol.20(4)、1990年9月。
[2] H. Schulzrinne, "Issues in designing a transport protocol for
audio and video conferences and other multiparticipant real-time
applications", Work in Progress.
[2]H.Schulzrinne、「オーディオのためにトランスポート・プロトコルを設計して、テレビ会議システムと他の「マルチ-関係者」のリアルタイムのアプリケーションにおける問題」、ProgressのWork。
[3] D. E. Comer, Internetworking with TCP/IP , vol. 1. Englewood
Cliffs, New Jersey: Prentice Hall, 1991.
[3] D.E.新来者、TCP/IP、vol.1とInternetworking。 イングルウッドがけ、ニュージャージー: 新米のホール、1991。
[4] Postel, J., "Internet Protocol", STD 5, RFC 791, USC/Information
Sciences Institute, September 1981.
[4] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、科学が1981年9月に設けるUSC/情報。
[5] Mills, D., "Network Time Protocol Version 3", RFC 1305, UDEL,
March 1992.
[5] 工場(D.)は「1992年3月に時間プロトコルバージョン3インチ、RFC1305、UDELをネットワークでつなぎます」。
Schulzrinne, et al Standards Track [Page 73] RFC 1889 RTP January 1996
Schulzrinne、他Standards Track[73ページ]RFC1889RTP1996年1月
[6] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
USC/Information Sciences Institute, October 1994.
[6] USC/情報科学が1994年10月に設けるレイノルズ、J.、およびJ.ポステル、「規定番号」、STD2、RFC1700。
[7] Eastlake, D., Crocker, S., and J. Schiller, "Randomness
Recommendations for Security", RFC 1750, DEC, Cybercash, MIT,
December 1994.
[7] イーストレークとD.とクロッカー、S.とJ.シラー、「セキュリティのための偶発性推薦」RFC1750、1994年12月、サイバーキャッシュ、MIT、12月。
[8] J.-C. Bolot, T. Turletti, 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, Aug. 1994.
[8] J.-C。 Bolot、T.Turletti、およびI.ウェイクマン、Communications ArchitecturesとプロトコルのSIGCOMM Symposium、(ロンドン(イギリス))、ページにおける「インターネットにおけるマルチキャストビデオ分配のためのスケーラブルなフィードバック制御」 58--67 1994年8月のACM。
[9] I. Busse, B. Deffner, and H. Schulzrinne, "Dynamic QoS control of
multimedia applications based on RTP," Computer Communications ,
Jan. 1996.
[9] I.Busse、B.Deffner、およびH.Schulzrinne、「マルチメディア応用のダイナミックなQoSコントロールはRTPを基礎づけました」、コンピュータCommunications、1996年1月。
[10] S. Floyd 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, Sept. 1993. also in [25].
[10] S.フロイドとV.ジェーコブソン、Communications Architecturesとプロトコル(D.P.Sidhu(教育))のSIGCOMM Symposium、(サンフランシスコ(カリフォルニア))、ページにおける「周期的なルーティング・メッセージの同期」 33--44、ACM、[25]でも9月1993。
[11] J. A. Cadzow, Foundations of digital signal processing and data
analysis New York, New York: Macmillan, 1987.
[11] J.A.Cadzowとデジタル信号処理の財団とデータ分析ニューヨーク(ニューヨーク): マクミラン、1987。
[12] International Standards Organization, "ISO/IEC DIS 10646-1:1993
information technology -- universal multiple-octet coded
character set (UCS) -- part I: Architecture and basic
multilingual plane," 1993.
[12] 国際Standards Organization、「ISO/IEC DIS10646-1: 1993年の情報技術(普遍的な複数の八重奏コード化文字集合(UCS))はIを分けます」。 「構造的、そして、基本的な多言語飛行機」、1993。
[13] The Unicode Consortium, The Unicode Standard New York, New York:
Addison-Wesley, 1991.
[13] ユニコード共同体、標準のニューヨーク、Unicodeニューヨーク: アディソン-ウエスリー、1991。
[14] Mockapetris, P., "Domain Names - Concepts and Facilities", STD
13, RFC 1034, USC/Information Sciences Institute, November 1987.
[14]Mockapetris、P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、科学が設けるUSC/情報、11月1987日
[15] Mockapetris, P., "Domain Names - Implementation and
Specification", STD 13, RFC 1035, USC/Information Sciences
Institute, November 1987.
[15]Mockapetris、P.、「ドメイン名--、実現と仕様、」、STD13、RFC1035、科学が設けるUSC/情報、11月1987日
[16] Braden, R., "Requirements for Internet Hosts - Application and
Support", STD 3, RFC 1123, Internet Engineering Task Force,
October 1989.
[16] ブレーデン、R.、「STD3、RFC1123、インターネットが特別委員会を設計することでの10月1989日アプリケーションとサポート」インターネットホストのための要件--
[17] Rekhter, Y., Moskowitz, R., Karrenberg, D., and G. de Groot,
"Address Allocation for Private Internets", RFC 1597, T.J. Watson
Research Center, IBM Corp., Chrysler Corp., RIPE NCC, March 1994.
[17] Rekhter、Y.、マスコウィッツ、R.、Karrenberg、D.、およびG.deグルートは「個人的なインターネットのための配分を記述します」、RFC1597、T.J.ワトソン研究所、IBM社、クライスラー社、RIPE NCC、1994年3月。
Schulzrinne, et al Standards Track [Page 74] RFC 1889 RTP January 1996
Schulzrinne、他Standards Track[74ページ]RFC1889RTP1996年1月
[18] Lear, E., Fair, E., Crocker, D., and T. Kessler, "Network 10
Considered Harmful (Some Practices Shouldn't be Codified)", RFC
1627, Silicon Graphics, Inc., Apple Computer, Inc., Silicon
Graphics, Inc., July 1994.
[18] リア、E.、Fair、E.、クロッカー、D.、およびT.ケスラー、「ネットワーク10Considered Harmful、(いくらかのPractices Shouldn、Codifiedでない、)、」、RFC1627、シリコングラフィックス、アップル・コンピューターInc.、シリコングラフィックス(1994年7月)
[19] Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", STD 11, RFC 822, UDEL, August 1982.
[19] クロッカー、D.、「アルパインターネットテキスト・メッセージの形式の規格」、STD11、RFC822、UDEL、1982年8月。
[20] W. Feller, An Introduction to Probability Theory and its
Applications, Volume 1 , vol. 1. New York, New York: John Wiley
and Sons, third ed., 1968.
[20]W.奴、Probability TheoryとそのApplicationsへのAn Introduction、Volume1、vol.1。 ニューヨーク(ニューヨーク): 3番目のジョン・ワイリーとソンス、教育、1968
[21] Balenson, D., "Privacy Enhancement for Internet Electronic Mail:
Part III: Algorithms, Modes, and Identifiers", RFC 1423, TIS, IAB
IRTF PSRG, IETF PEM WG, February 1993.
[21]Balenson、D.、「インターネット電子メールのためのプライバシー増進:」 パートIII: 「アルゴリズム、モード、および識別子」、RFC1423、TIS IAB IRTF PSRG、IETF PEM WG、2月1993日
[22] V. L. Voydock and S. T. Kent, "Security mechanisms in high-level
network protocols," ACM Computing Surveys , vol. 15, pp. 135--
171, June 1983.
[22] L.VoydockとS.T.ケントに対して「ハイレベルのセキュリティー対策はプロトコルをネットワークでつなぎます」、ACM Computing Surveys、vol.15、ページ 135-- 171と、1983年6月。
[23] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, MIT
Laboratory for Computer Science and RSA Data Security, Inc.,
April 1992.
[23] 最もRivestなR.、「MD5メッセージダイジェストアルゴリズム」RFC1321、MITコンピュータサイエンス研究所、およびRSA Data Security Inc.(1992年4月)。
[24] S. Stubblebine, "Security services for multimedia conferencing,"
in 16th National Computer Security Conference , (Baltimore,
Maryland), pp. 391--395, Sept. 1993.
[24] S.Stubblebine、第16NationalコンピュータSecurityコンファレンス、(ボルチモア(メリーランド))、ページにおける「マルチメディア会議のためのセキュリティー・サービス」 391--395と、1993年9月。
[25] S. Floyd and V. Jacobson, "The synchronization of periodic
routing messages," IEEE/ACM Transactions on Networking , vol. 2,
pp. 122-136, April 1994.
[25] S.フロイドとV.ジェーコブソン、「周期的なルーティング・メッセージの同期」、Networking、vol.2、ページのIEEE/ACM Transactions 122-136と、1994年4月。
Schulzrinne, et al Standards Track [Page 75]
Schulzrinne、他のStandards Track[75ページ]
一覧
スポンサーリンク
