RTP【Real-time Transport Protocol】

• RTPとは
• RTPの動作
• 補足知識

RTPとは

最終更新

2006-02-04T15:33:00+09:00

この記事のURI参照

https://www.7key.jp/nw/technology/protocol/rtp.html#what

リアルタイムデータ転送プロトコルと訳されます。映像や音声データをリアルタイムに転送することを目的としたプロトコルです。RTPはUDPの上位プロトコルとして機能しますが、設計自体はトランスポート層やネットワーク層のプロトコルに依存しないものとなっています。また、リソースの確保やQoSの保証などを行いません。その変わりに最小限の送達確認や監視を行うための制御プロトコルとしてRTCPが付随しています。RTCPによって実行帯域幅や遅延時間などをの情報をサーバに送出し、サーバは報告された情報に応じてRTPで送信するデータの品質を調整して送信を行う流れとなります。

RTPはリアルタイム伝送を実現するために、データとともに送受信間及びデータ内での同期クロック情報や順序番号、データタイプを送信します。これらの情報を基に受信者側はデータのリアルタイム再生を行うこととなります。これは、映像や音声のデータは部分的にデータが欠けていても再生が可能なため、データの受信側で喪失したり送れて到着したパケットを無視して有効なデータのみで映像や音声を再生するために必要な情報となっています。また、RTPアプリケーションでは処理をレイヤごとではなく、アプリケーション処理とストリーミング伝送処理などで同期を取り、一体化して処理を実行するため、RTP単独では動作をしません。

RTPセッション

RTPではセッションと呼ばれる参加者のグループが規定されています。参加者ごとのセッションの識別には、ネットワークアドレス、データを送信するポートの組、データを受信するポートの組が使用されます。参加者は複数のセッションに同時に参加することも可能です。

RTPプロファイル

ペイロードタイプに割り当てられた番号とペイロードフォーマットの仕様とを関連付ける対応のことを指します。多くのアプリケーションはRTP profile for audio and video conferences with minimal control（RFC1890：通称Audio/Video Profile）と言うRTPプロファイルに従います。このプロファイルでは下表ペイロードタイプで示す対応表が定義されています。

V

バージョン番号を表す（2bit）。通常は2が入る。インターネットドラフトに基づくRTPでは1、vatオーディオツールによる初期実装では0。

P

パディングを表す（1bit）。1を入れた場合、パケットの最後にペイロードがパディングされ、本来の長さよりも長くなっていることを示す。これはパケットが暗号化される際など、フィールド長が固定長とされている場合に使用される。

X

RTPヘッダの直後に拡張ヘッダをもつ場合に設定されるフラグ（1bit）。ヘッダ拡張は可変長だが、先頭に16bitのタイプフィールドとそれに続く16bitの長さフィールドがあり、受信側で拡張部分を理解できない場合にはそれを無視できることとなっている。

CC

CSRCカウント（4bit）。後続するCSRC識別子の数が入る。

M

マーカ（1bit）。パケットストリームでのフレーム境界の有無やストリーム内での重要なイベントにマークを付けるために使用される。意味は使用するRTPプロファイルとメディアタイプによって定義される。

PT

ペイロードタイプ（7bit）。後続するペイロードのタイプを表す（別表参照）。受信側のアプリケーションでは、データをどのデコンプレッサに渡すか等処理法方の判断のためにこの値を使用する。

順序番号

1ずつ増加するパケットの通し番号（16bit）。初期値はセキュリティ確保のためランダム値が用いられる。16bitではシーケンス番号がすぐに1周してしまうため、アプリケーションはこの値をパケットの識別子として使用すべきではない。シーケンス番号を32bit以上に拡張し、下位16bitにシーケンス番号を入れ、上位16bitにシーケンス番号が1周した回数をカウントする方法が採られる。

タイムスタンプ

先頭バイトの送信時刻（32bit）。値はメディアごとに異なる割合で増加し、最大値を超えると0となる。メディアデータの再生をスケジュールするために使用される。

SSRC【Synchrozination Source】

RTPセッション内の参加者の識別子（32bit）。セッションごとに変わる一時的な識別子であり、RTCPによってCNAMEに対応付けられる。SSRCはローカルでランダムに選択される値のため、複数の参加者が同じ値を選び衝突が起きた場合は別の値に変えなければならない。

CSRC【Contributing Source】

メッセージ内の各ストリーム要素を準備した送信元の識別子（32bit）。それぞれの値は各SSRCと同じである。CSRCリストに含まれるのは、ミキサで処理されたパケットである。

リアルタイムデータ

メディアのペイロードデータからなるフレームが1つ以上入る。通常はパケットに入れるフレームの最大数は指定されないため、受信側では数種類のサイズのパケットを処理できるようしておく必要がある。各パケットに入れるフレームの数は、下位層のMTUやパケットのサイズをできるだけ大きくするために後続のデータが作成されるのを待つ際の遅延を考慮に入れ決められる。

RTPの動作

最終更新

2006-01-29T18:31:00+09:00

この記事のURI参照

https://www.7key.jp/nw/technology/protocol/rtp.html#work

送信側

まず、送信側は映像や音声のデータをバッファに取り込みます。このデータから圧縮フレームが生成され、RTPパケットに埋め込まれます。フレームのサイズが大きすぎる場合は複数のRTPパケットに細分化されることもあり、小さすぎる場合は1つのRTPパケットに複数のフレームが埋め込まれることもあります。

受信側

受信側はまず最初にネットワークからパケットを受信し、パケットの正確性を検証します。そして送信者別の入力キューに入れ、パケット欠落等の訂正処理が行われます。パケットはチャネルコーダからソース別の再生バッファに挿入されますが、再生バッファはタイムスタンプ順となっていますので転送中に順番が変更された場合は適時修正されます。フレームが完全に受信されるまでそれぞれのパケットは再生バッファ内に保存されます。

各パケットには対応するフレームの目標再生時間が埋め込まれており、再生時間になるとフレーム形式に復元され、デコードが行われます。この時点で送信側と受信側ではクロックレートの名目上値に差異が生じる場合もあります。この差異は再生クロックとRTPメディアクロックの値のずれとして現れ、再生時にギャップが生じることを避けるため、受信側はこのクロックのずれを補正しなければなりません。

また、RTPセッションは動的にネゴシエートされた2つのポートを使用するため、受信したパケットが本当にRTPのものなのか検証する必要があります。具体的には、バージョン番号が2であることを確かめる、ペイロードデータに予期しない値が使用されていないかどうか確かめる、SSRCが定数となっているかどうか、シーケンス番号は受信パケットごとに1ずつ増加しているかどうか、タイムスタンプの間隔はペイロードタイプと合致しているかどうかなどを元に検証を行います。

補足知識

最終更新

2006-01-29T13:44:00+09:00

この記事のURI参照

https://www.7key.jp/nw/technology/protocol/rtp.html#supplement

• RFC1889【RTP: A Transport Protocol for Real-Time Applications -- January 1996】
• RFC1890【RTP Profile for Audio and Video Conferences with Minimal Control -- January 1996】

UDPを使用する場合、RTPは偶数番のUDPポートを、RTCPはその1つ上の奇数番UDPポートをアプリケーションポート番号として使用します。RTPをUDP/IPで利用する際のデフォルトポート番号は5004と5005ですが、多くの場合アプリケーションはこれらのポートを使用せず、セッションのセットアップ時に動的に割り当てたポートを使用します。ただし、現在ではRTPデータに偶数のポート番号を使用すると言う規制は緩和され、また、RTPとRTCPに連続しないポート番号を使うことも認められています。