| 7 | 応用 |
|---|---|
| 6 | プレゼンテーション |
| 5 | セッション |
| 4 | 交通機関 |
| 3 | ネットワーク |
| 2 | データバインディング |
| 1 | 物理的な |
| OSIモデル | |
RTP ( Real-Time Transport Protocol ) は、コンピュータ通信プロトコルです。
これは、UDP を使用するため、実際の転送プロトコルではありません。TCP はマルチキャストではなく、データストリームの即時送信を許可しません。また、それ自体は実際にはリアルタイムではありません (イーサネットなどの現在のネットワークは最大遅延が保証されていないためリアルタイムではありません) が、リアルタイムネットワーク(たとえば、帯域幅が保証されている ATM ネットワークなど) では有利に使用されます。光チャネル、放送、または衛星チャネル）。
インターネットテレフォニーやライブビデオストリーミング用の Voice over IP などのマルチメディアアプリケーションに Time-as-a-Service 機能を提供します。 UDP パケットに特定のヘッダーを追加して、伝送されるメディアのタイプ、データグラムの順序付けと同期を知らせるため、受信機はネットワーク上で失われたデータグラムや誤って受信したデータグラムを検出でき、場合によっては連続ストリームを再構築できます。
RTP は単方向であり、衛星経由のブロードキャスト (マルチキャスト) に使用できます。これにより、多数の受信機にサービスを提供するネットワーク リソースの点で非常に経済的となり、コンテンツの有効ビット レートとコーディング品質を大幅に向上させることができます。
オプションで、独立してネゴシエートされる RTCP (Real Time Control Protocol) 経由のサービス品質(QoS)フィードバックチャネルと組み合わせて使用できます (RTSP を参照)。このフィードバックは、たとえば、チャネルのリアルタイム プロパティ、受信機バッファの状態について送信機に通知したり、マルチメディア アプリケーションの圧縮/ビットレートの変更を要求したりできます (この場合、欠落したデータはユニキャスト経由で送信される可能性があります)。 ）。
ただし、大量放送 (ライブ ストリーム、ブロードキャスト、または衛星経由) では、このリターン パスは通常使用されませんが、放送受信品質の一時的な中断を補うために、コンテンツは十分な時間差を設けて並行して複数回送信されます。受信バッファの制限を超えないこと (通常は 15 秒以内の間隔)。その後、受信機は完全なシーケンスを再構築および並べ替えて、連続的なロスレス ストリームを取得できます。
マルチキャスト モードでの RTP の実装には、受信者レベルでの事前のルーティング設定が必要です。受信者レベルでは、送信者と受信者の間でホスト ルーターに対してルーティング要求を行う必要があります。送信側は、直接接続されているブロードキャスト ルーターに個別に通知します。
付加価値のある保護されたコンテンツの場合、リターン パスが存在しないということは、コンテンツ復号化キーの使用を意味し、受信者は送信者と個別にネゴシエートする必要があります (ルーターのブロードキャストに接続するだけで、暗号化されたコンテンツを簡単に受信できます)。 RTP 自体は暗号化を処理せず、コンテンツを透過的に転送します。
RTP は、廃止されつつある古い独自プロトコルRDP (最初はReal Player用に作成された) の国際標準化バージョンです。
SRTP プロトコル (Secure Real-time Transport Protocol の頭字語) は、RTP の安全な (暗号化された) プロトコルです。