マスタリングTCP／IP RTP編

3.1 RTPの基本的な設計概念

3.1.1 Application-Level Framing

INPUT

配信処理の細部はできるだけ、トランスポートプロトコル以外で対処する。
つまりエラーのハンドリングなどをアプリケーション側で行うようにした。

なぜならば問題から回復するシナリオは複数あるから
下記のような制御はアプリケーション層と厳密にやり取りしなければ難しい。

• このパケットはエラーが出ても無視する
• このパケットは必ず届けなけばクリティカルな問題に繋がる

本来であればOSI参照モデルが定義する、厳密な階層に従えばよい
しかし現実的に下位層を意識しないで制御するのは難しい。

OUTPUT

Application-Level Framingを用いてアプリケーションではデータ転送方法を判断する詳細な情報をアプリケーションにだけ持たせることとした。ADUというアプリケーションが解釈できる単位で扱う。Application-Level Framingを適用することで必要に応じてデータの欠落を容認でき、データの再送や前方誤り訂正といった回復のための技術を柔軟に適応することができる。

3.1.2 end to end の原則

ネットワークシステムの設計手法

1. hop by hop(ポップごとに確実に転送する手法)
2. end to end(転送の責任をエンドポイントに残しておく方法)

3.1.3 優れた柔軟性

RTPは動画音声のリアルタイム転送するフレームワークを提供する。
ほとんどのアプリケーションの要件を満たしながら、
制限を補う必要のあるアプリケーションに網膜適応することができる。 RTP + メディアプロファイルの組み合わせで動作する。 メディアプロファイルはペイロードフォーマットの仕様が記載されており、RTPのフレームワークに含まれる。

RTPプロトコルは必ずUDPとIPを使用する必要はない

TCP/IPを用いて実装されも良いし、ATM（Asynchronous Transfer Mode）で実装してもよい。
特にどの種別のプロトコルを使わなければ行けないという制限はないらしい。

3.2 RTP標準の要素

• ペイロードのフレーム処理
• 欠落検出用のシーケンス番号
• タイミング復帰のためのタイムスタンプ
• ペイロードタイプ
• 送信元に関する識別子
• メディアストリーム内のイベントマーカ
• etc..

タイムスタンプとシーケンス番号

タイムスタンプとシーケンス番号処理の規則や
ストリーム多重化の規則はプロファイルごとに決まっている。

RTP制御プロトコル

RTPを制御するためのシナリオに応じてプロトコルが決まっており、
双方向のSIP・H323や動画音声配信などの双方向ではないセッションを開始するためのRTSPなど。

RTPは意図的にセッションの開始と制御の仕様を除外しており、
幅広いアプリケーションで適応できるように仕様が定められている。

そのためシナリオに応じて制御プロトコルが決まっている。
例として下記のプロトコルがある。

• 双方向の制御を実施するSIP・H323
• 動画音声配信などの単方向のセッションを開始するためのRTSP

RTPにはQOS(Quality of Service)のプロトコルが含まれない。
その為他のプロトコルに助けを借り制御する必要がある。

4.1 RTPセッション

セッション識別に必要な情報

• ネットワーク・アドレス
• データを送信するポートの組
• データを受信するポートの組

ポートの組とは

• 偶数ポート　RTPデータパケットの交換
• 奇数ポート　RTCP制御パケットの交換

4.2 RTPデータ転送パケット

Header

Payload Type

RTPパケットによって転送されるメディアの識別をする。
受信アプリケーションではデータをどのデコンプレッサに渡すか決めるために利用される。

PayloadTypeでフォーマットを識別する。
ちなみに96から127の範囲のペイロード番号が動的割当に利用される。

MINEタイプ

インターネット上で転送されるコンテンツの形式を表現する識別子

RTP/AVP(RTP Profile for audio and Video Conferences with minimal control)

RTPセッションで使用可能なペイロードフォーマットは1種類ではなく複数種類利用できる。 そのため種類の異なる複数のメディアに対して使用することを意図している。

アプリケーションにてAudioとVideoの両方を送信する場合は1セッションで配信するのではなく、 2つのセッションで分けて送信する。送信するセッションを分けることでメディア毎に異なるQOSを要求できる。

QOSって何さ？

[QOS](http://www.infraexpert.com/study/telephony6.html)

QOSはネットワーク上で提供するサービス品質のことでネットワーク機能などのに実装される。
主な機能として特定の通信を優先して伝送する機能や帯域幅を確保する機能が含まれる。

つまりRTPで配信する際にはAudio・Videoで混ぜるとここにQOSによるセッション管理ができなくなる。 そのため2セッションに分けると何かと便利だということ。

シーケンス番号（SequenceNumber）

シーケンス番号はUINT16なのですぐに1周したり、通信相手が再起動してシーケンス番号がリセットされたときの動作を考慮する必要がある。この問題を改善するアルゴリズムがあるらしいがここでは詳細は省く。 またシーケンス番号はKnown-Plain-Texts-Attack対策のためシーケンス番号は無作為に決める。

タイムスタンプ（TimeStamp）

32ビット符号なし整数でメディアごとに異なる割合で送信する。

タイムスタンプは連続した値でなくてはならない

• 動画の巻き戻しを実施したときも同様、RTSPサーバでタイムスタンプを制御しなくてはならない
• タイムスタンプを取得してから順番が変わってからパケットが送信されることもあるので受信で姿勢する前にタイムスタンプを取得した後に最構成する必要がある。

RTPではメディアクロックの解決・正確性・安定性に関しては保証しないアプリケーションで保証する。

例えばVideoの場合、90kHzのクロックレートで送信する。  
90kHzで送信した場合タイムスタンプは13時間で1周する。

s = uint32 ÷ 90kHz = 429467295 ÷ 90000  =  47721.8
m = 47721.8 ÷ 60 = 795.35
h = 795.35 ÷ 60 = 13.255

PAL (Phase Alternating Line)

カラーコンポジット映像信号の規格

SSRC (Synchronization Source Indentifer Uniquely Identifies)

32bitの整数セッション参加時に参加者が無作為に選択する。 他の参加者との衝突するためユニークでなければならない、また衝突を検知する仕組みが必要。 同じ乱数のシードでSSRCを生成すると衝突しやすくなるので品質を上げる仕組みが別途必要。

CSRC

ミキサ・トランスレータはデータに関与するが、同期・タイミングなどの責任は持たないもの者を管理するリスト。

マーカ

アプリケーションに状態を伝えるため利用する。定義はプロファイルによって違う。

Padding

以下に記載する場合に容量調整するために利用される。

1. 暗号化方式のブロック方式が固定されている場合
2. ペイロードフォーマットが容量固定の場合

Ex-Header

• ペイロードの前に置かれる情報
• プロファイルごとに定義されるもの

Payload-Header

ヘッダに含まれるもので静的なものと動的なものがある。

• 静的か動的かはフォーマットによって決まる
• 動的な設定をセッションごとに行う、SDPを用いて通知する。

Payload

フレームデータのこと、1つのデータに複数のフレームを入れることが許可されている。

4.3 パケットの検証

特になし

4.4 トランスレータとミキサ

トランスレータ

SSRCとタイムラインを維持しながら、RTP処理の中継をする。 RTPデータの処理を行うシステム

ブリッジ(1対1)

• メディアエンコードなし
• 下記のネットワーク間のゲートウェイとして機能する
• RTP/UDP/IP ⇔ RTP/ATM
• RTP/UDP/IPv4 ⇔ RTP/UDP/IPv6

トランスコーダ(1対1)

圧縮データのデコード、別タイプでエンコードする役割を持つ。

エクスプローダ(1対多)

複数フレームを別のパケットにする。その時生成されるSSRCは同じだがその他ヘッダ情報はパケットごとに異なる。

マージャ−(多対1)

複数のパケットを1つに結合する、多対1の変換処理を実行する。エクスプローダと逆の処理を行う。

ミキサ

ソースのグループから受け取ったRTPパケットを1つの出力に合成して転送する中継システム