リアルタイムトランスポートプロトコル

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ

Real-time Transport ProtocolRTP)は、IPネットワークを介してオーディオとビデオを配信するためネットワークプロトコルです。RTPは、テレフォニーWebRTCを含むビデオ電話会議アプリケーションテレビサービス、Webベースのプッシュツートーク機能などのストリーミングメディアを含む通信およびエンターテインメントシステムで使用されます。

RTPは通常、ユーザーデータグラムプロトコル(UDP)上で実行されます。RTPは、 RTP制御プロトコル(RTCP)と組み合わせて使用​​されます。RTPはメディアストリーム(オーディオやビデオなど)を伝送しますが、RTCPは伝送統計とサービス品質(QoS)を監視するために使用され、複数のストリームの同期を支援します。RTPはVoiceover IPの技術的基盤の1つであり、このコンテキストでは、ネットワーク全体の接続を確立 するSession Initiation Protocol (SIP)などのシグナリングプロトコルと組み合わせて使用​​されることがよくあります。

RTPは、インターネット技術特別調査委員会(IETF)のオーディオビデオトランスポートワーキンググループによって開発され、1996年にRFC  1889として最初に公開され、2003年に RFC3550に取って代わられました。 

概要

RTPは、ストリーミングメディアのエンドツーエンドリアルタイム転送用に設計されていますこのプロトコルは、特にIPネットワークでのUDP送信中に一般的な、ジッター補償とパケット損失および異常な配信の検出のための機能を提供します。RTPを使用すると、 IPマルチキャストを介して複数の宛先にデータを転送できます[2] RTPは、IPネットワークでのオーディオ/ビデオトランスポートの主要な標準と見なされており、関連するプロファイルとペイロード形式で使用されます。[3] RTPの設計は、アプリケーション層フレーミングとして知られるアーキテクチャの原則に基づいています。ここで、プロトコル機能は、オペレーティングシステムのプロトコルスタックではなく、アプリケーションに実装されます。

リアルタイムマルチメディアストリーミングアプリケーションは、情報をタイムリーに配信する必要があり、多くの場合、この目標を達成するためにある程度のパケット損失を許容できます。たとえば、オーディオアプリケーションでパケットが失われると、オーディオデータの数分の1秒が失われる可能性があります。これは、適切なエラー隠蔽アルゴリズムを使用して気付かれないようにすることができます。[4]伝送制御プロトコル(TCP)は、RTPでの使用が標準化されていますが、[ 5]は、適時性よりも信頼性を優先するため、通常はRTPアプリケーションでは使用されません。代わりに、RTP実装の大部分は、ユーザーデータグラムプロトコル(UDP)に基づいて構築されています。[4]マルチメディアセッション用に特別に設計された他のトランスポートプロトコルは、SCTP [ 6]DCCP [7]ですが、2012年の時点では、広く使用されていません。[8]

RTPは、IETF標準化団体のオーディオ/ビデオトランスポートワーキンググループによって開発されました。RTPは、 H.323RTSPなどの他のプロトコルと組み合わせて使用​​されます[3] RTP仕様では、RTPとRTCPの2つのプロトコルについて説明しています。RTPはマルチメディアデータの転送に使用され、RTCPは制御情報とQoSパラメータを定期的に送信するために使用されます。[9]

データ転送プロトコルであるRTPは、リアルタイムデータを伝送します。このプロトコルによって提供される情報には、タイムスタンプ(同期用)、シーケンス番号(パケット損失および並べ替え検出用)、およびデータのエンコードされた形式を示すペイロード形式が含まれます。[10]制御プロトコルRTCPは、サービス品質(QoS)フィードバックとメディアストリーム間の同期に使用されます。RTPと比較したRTCPトラフィックの帯域幅は小さく、通常は約5%です。[10] [11]

RTPセッションは通常、H.323、Session Initiation Protocol(SIP)、RTSP、またはJingleXMPP)などのシグナリングプロトコルを使用して、通信しているピア間で開始されます。これらのプロトコルは、セッション記述プロトコルを使用して、セッションのパラメーターを指定できます。[12]

マルチメディアストリームごとにRTPセッションが確立されます。オーディオストリームとビデオストリームは別々のRTPセッションを使用する場合があり、受信者が特定のストリームのコンポーネントを選択的に受信できるようにします。[13] RTPおよびRTCPの設計は、トランスポートプロトコルに依存しません。アプリケーションは通常、非特権範囲(1024〜65535)のポート番号でUDPを使用します。[14]信頼性の高いトランスポートプロトコルが必要な場合は、Stream Control Transmission Protocol(SCTP)およびDatagram Congestion Control Protocol(DCCP)を使用できますRTP仕様では、RTPに偶数のポート番号を使用し、関連するRTCPセッションに次の奇数のポート番号を使用することを推奨しています。[15] :68 プロトコルを多重化するアプリケーションでは、RTPとRTCPに単一のポートを使用できます。[16]

RTPは、 Voice over IPAudio over IPWebRTCインターネットプロトコルテレビなどのリアルタイムマルチメディアアプリケーションで使用されます

プロファイルとペイロード形式

RTPは、多数のマルチメディア形式を伝送するように設計されているため、RTP標準を改訂することなく新しい形式を開発できます。この目的のために、プロトコルの特定のアプリケーションに必要な情報は、汎用RTPヘッダーに含まれていません。アプリケーションのクラス(オーディオ、ビデオなど)ごとに、RTPはプロファイルと関連するペイロード形式を定義します。[9]特定のアプリケーションでRTPをインスタンス化するたびに、プロファイルとペイロード形式の仕様が必要になります。[15] :71 

プロファイルは、RTPヘッダーのプロトコルフィールドペイロードタイプ(PT)で、ペイロードデータのエンコードに使用されるコーデックとペイロードフォーマットコードへのマッピングを定義します。各プロファイルには、特定のエンコードされたデータの転送を説明するいくつかのペイロード形式の仕様が付属しています。[3]オーディオペイロードフォーマットの例はG.711G.723G.726G.729GSMQCELPMP3、およびDTMFであり、ビデオペイロードの例はH.261H.263Hです。 264H.265およびMPEG-1/ MPEG-2[17] MPEG-4オーディオ/ビデオストリームのRTPパケットへのマッピングは、 RFC 3016で指定されており、H.263ビデオペイロードはRFC2429で説明されています[18]  

RTPプロファイルの例は次のとおりです。

  • 最小限の制御による音声およびビデオ会議のRTPプロファイルRFC 3551)は、静的ペイロードタイプの割り当てのセット、およびペイロード形式とセッション記述プロトコル(SDP)を使用したPT値との間のマッピングのための動的メカニズムを定義します。 
  • Secure Real-time Transport Protocol(SRTP)(RFC 3711 )は、ペイロードデータの転送に暗号化サービスを提供するRTPプロファイルを定義します。[19] 
  • マシン間通信用のRTP (RTP / CDP)の実験的な制御データプロファイル。[20]

パケットヘッダー

RTPパケットは、アプリケーション層で作成され、配信のためにトランスポート層に渡されます。アプリケーションによって作成されたRTPメディアデータの各ユニットは、RTPパケットヘッダーで始まります。

RTPパケットヘッダー
オフセット オクテット 0 1 2 3
オクテット ビット[a] 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 バージョン P バツ CC M PT シーケンス番号
4 32 タイムスタンプ
8 64 SSRC識別子
12 96 CSRC識別子
..。
12 + 4×CC 96 + 32×CC プロファイル固有の拡張ヘッダーID 拡張ヘッダーの長さ
16 + 4×CC 128 + 32×CC 拡張ヘッダー
..。

RTPヘッダーの最小サイズは12バイトです。ヘッダーの後に、オプションのヘッダー拡張が存在する場合があります。この後にRTPペイロードが続き、その形式は特定のアプリケーションクラスによって決定されます。[21]ヘッダーのフィールドは次のとおりです。

  • バージョン:(2ビット)プロトコルのバージョンを示します。現在のバージョンは2です。[22]
  • P(パディング) :( 1ビット)RTPパケットの最後に余分なパディングバイトがあるかどうかを示すために使用されます。パディングは、たとえば暗号化アルゴリズムで必要とされる場合など、特定のサイズのブロックを埋めるために使用できます。パディングの最後のバイトには、追加されたパディングバイトの数(それ自体を含む)が含まれます。[15] :12  [22]
  • X(拡張) :( 1ビット)ヘッダーとペイロードデータの間に拡張ヘッダーが存在することを示します。拡張ヘッダーは、アプリケーションまたはプロファイルに固有です。[22]
  • CC(CSRCカウント) :( 4ビット)SSRC(以下に定義)に続くCSRC識別子(以下に定義)の数が含まれます。[15] :12 
  • M(マーカー) :( 1ビット)プロファイル固有の方法でアプリケーションレベルで使用されるシグナリング。設定されている場合は、現在のデータがアプリケーションに特別な関連性を持っていることを意味します。[15] :13 
  • PT(ペイロードタイプ) :( 7ビット)ペイロードの形式を示し、アプリケーションによるその解釈を決定します。値はプロファイル固有であり、動的に割り当てることができます。[23]
  • シーケンス番号:(16ビット)シーケンス番号は、送信されるRTPデータパケットごとに増分され、受信者がパケット損失を検出し[2] 、順不同の配信に対応するために使用されます。Secure Real-time Transport Protocolに対する既知平文攻撃より困難にするために、シーケンス番号の初期値をランダム化する必要があります。[15] :13 
  • タイムスタンプ:(32ビット)受信したサンプルを適切な時間と間隔で再生するために受信者が使用します。複数のメディアストリームが存在する場合、タイムスタンプは各ストリームで独立している可能性があります。[b]タイミングの粒度はアプリケーション固有です。たとえば、125μs(8 kHz、デジタルテレフォニーの一般的なサンプルレート)ごとに1回データをサンプリングするオーディオアプリケーションは、その値をクロック解像度として使用します。ビデオストリームは通常、90kHzクロックを使用します。クロックの粒度は、アプリケーションのRTPプロファイルで指定されている詳細の1つです。[24]
  • SSRC:(32ビット)同期ソース識別子は、ストリームのソースを一意に識別します。同じRTPセッション内の同期ソースは一意になります。[15] :15 
  • CSRC:(各32ビット、エントリの数はCSRCカウントフィールドで示されます)貢献ソースIDは、複数のソースから生成されたストリームへの貢献ソースを列挙します。[15] :15 
  • ヘッダー拡張:(オプション、拡張フィールドで示される存在)最初の32ビットワードには、プロファイル固有の識別子(16ビット)と、拡張の長さを32ビット単位で示す長さ指定子(16ビット)が含まれます。拡張ヘッダーの32ビット。拡張ヘッダーデータは次のとおりです。[15] :18 

アプリケーション設計

機能的なマルチメディアアプリケーションには、RTPと組み合わせて使用​​される他のプロトコルと標準が必要です。SIP、Jingle、RTSP、H.225H.245などのプロトコルは、セッションの開始、制御、および終了に使用されます。H.264、MPEG、H.263などの他の標準は、該当するRTPプロファイルで指定されているペイロードデータのエンコードに使用されます。[25]

RTP送信者は、マルチメディアデータをキャプチャし、エンコード、フレーム化して、適切なタイムスタンプとタイムスタンプとシーケンス番号を増やしたRTPパケットとして送信します。送信者は、接続ネゴシエーションと使用中のRTPプロファイルに従ってペイロードタイプフィールドを設定します。RTPレシーバーは、欠落しているパケットを検出し、パケットを並べ替えることがあります。ペイロードタイプに従ってパケット内のメディアデータをデコードし、ストリームをユーザーに提示します。[25]

標準文書

  • RFC  3550、Standard 64、RTP:リアルタイムアプリケーション用のトランスポートプロトコル
  • RFC  3551、標準65、最小限の制御による音声およびビデオ会議のRTPプロファイル
  • RFC  4855RTPペイロード形式のメディアタイプ登録
  • RFC  4856オーディオおよびビデオ会議のRTPプロファイルでのペイロード形式のメディアタイプ登録
  • RFC  7656リアルタイムトランスポートプロトコル(RTP)ソースのセマンティクスとメカニズムの分類法

も参照してください

メモ

  1. ^ ビットは最上位から最下位の順に並べられます。ビットオフセット0は、最初のオクテットの最上位ビットです。オクテットはネットワーク順に送信されます。ビットの送信順序はメディアに依存します。
  2. ^ RFC 7273は、異なるストリームのメディアクロック間の関係を通知する手段を提供します。 

参考文献

  1. ^ W. Richard Stevens、 TCP / IP Illustrated、Volume 1:The Protocols、Addison Wesley、1994、ISBN0-201-63346-9。
  2. ^ a b ダニエルハーディ(2002)。ネットワークDeBoeckUniversité。p。 298
  3. ^ a b c Perkins 2003、p。55
  4. ^ a b Perkins 2003、p。46
  5. ^ RFC 4571 
  6. ^ ファレル、エイドリアン(2004)。インターネットとそのプロトコルモーガンカウフマン。p。363. ISBN 978-1-55860-913-6
  7. ^ Ozaktas、Haldun M。; Levent Onural(2007)。三次元テレビスプリンガー。p。356. ISBN 978-3-540-72531-2
  8. ^ ホッグ、スコット。「StreamControlTransmission Protocol(SCTP)はどうですか?」ネットワークワールド2017年10月4日取得
  9. ^ a b ラリーL.ピーターソン(2007)。コンピュータネットワークモーガンカウフマン。p。 430ISBN 978-1-55860-832-0
  10. ^ a b Perkins 2003、p。56
  11. ^ Peterson 2007、p。435
  12. ^ RFC 4566 SDP:Session Description Protocol、M。Handley、V。Jacobson、C。Perkins、IETF(2006年7月) 
  13. ^ Zurawski、Richard(2004)。「RTP、RTCPおよびRTSPプロトコル」産業情報技術ハンドブックCRCプレス。pp。28–7  _ ISBN 978-0-8493-1985-3
  14. ^ コリンズ、ダニエル(2002)。「IPを使用した音声の転送」。キャリアグレードのVoiceoverIPマグロウヒルプロフェッショナル。pp。47  _ ISBN 978-0-07-136326-6
  15. ^ a b c d e f g h i RFC 3550 
  16. ^ 単一ポートでのRTPデータと制御パケットの多重化IETF。2010年4月。doi10.17487 / RFC5761RFC5761 _ 2015年11月21日取得
  17. ^ Perkins 2003、p。60
  18. ^ チョウ、フィリップA。; ミハエラ・ファン・デル・シャール(2007)マルチメディアオーバーIPおよびワイヤレスネットワークアカデミックプレス。pp。514  _ ISBN 978-0-12-088480-3
  19. ^ Perkins 2003、p。367
  20. ^ Breese、Finley(2010)。RTP / CDPを介したシリアル通信BoD-ブックオンデマンド。pp。  [1]ISBN 978-3-8391-8460-8
  21. ^ Peterson 2007、p。430
  22. ^ a b c Peterson 2007、p。431
  23. ^ Perkins 2003、p。59
  24. ^ ピーターソン、p。432
  25. ^ a b Perkins 2003、pp。11–13
  • パーキンス、コリン(2003)。RTPアディソン-ウェスリー。ISBN 978-0-672-32249-5
  • ピーターソン、ラリーL。; デイビー、ブルースS.(2007)。コンピュータネットワーク(4版)。モーガンカウフマン。ISBN 978-0-12-374013-7

さらに読む

外部リンク