ネットワーク遅延を考慮した

グループ内メディア同期機構の
提案

広島市立大学大学院　
岸田　崇志
概要
 はじめに

 背景

 グループ内メディア同期の利用場面

 提案機構の特徴

 同期アルゴリズム

 同期機構の設計

 まとめ

02/24/09 2
はじめに
広帯域で低遅延なネットワークの普及

映像や音声を使用したマルチメディアコミュニケーションなど
様々なインタラクションが可能に

テレビ会議，遠隔会議，遠隔ゼミ

遠隔講演

遠隔合唱
02/24/09 3
グループ内メディア遅延

Sender ホスト A

転送遅延があると再生のタイ
ミングにズレが生じる

Internet

再生 再生 再生

ホスト ホスト C ホスト

B
Receiver Receiver D
Receiver
02/24/09 4
 転送遅延によるズレ
Sender

ホスト
A
Receiver
⊿tB ⊿tD －⊿ tB
ホスト
B
Receiver ⊿tD －⊿ tC
⊿tC
ホスト
C
Receiver
⊿tD
ホスト
この時間分ズレて再生されることとなる
D
アプリケーションによっては転送遅延を考慮してズレをあわせる必要がある
02/24/09 5

Time
 メディア同期
 RTP
 メディア内同期…単一メディア内の時間関係を調節するた
めの機構　 ( 再生の時間制御や順序制御 )
 メディア間同期…複数メディア間の時間関係を調節し同期
を行う　 ( 映像と音声を同期させるリップシンクなどに使
用)
 NTP
ホスト間の絶対時間をあわせることが可能


 指定した時刻に同時アプリケーションを実行することが可
能
リアルタイムにメディアを伝送するアプリケーションでは転送遅延が影響する

転送によるズレは RTP を用いたり， NTP により各ホストを同期させるだけでは伝送

にかかった遅延時間を考慮した同期はとれない
02/24/09 6
 同期再生の利用可能性
　同じインタラクションを必要とするグループ内で同期再生が可能になると…　
例 ) 遠隔講義
　　　資料提示ツールで多拠点に同時に資料を
提示

受講者

講師
受講者

Internet
ネットワーク遅延を考慮した
講師の声など音声を同時に配信することも可能
02/24/09
グループ内メディア同期機構の提案 7
受講者
オークションなど同時に同じ情報を提示する場面など
ネットワーク遅延を考慮した
グループ内メディア同期機構の提
案
 概要
 Sender と Receiver 間の転送遅延を計測
 Receiver 間の転送遅延の差分（ offset ）の計算
 Receiver に Offset を通知
 特徴
 NTP サーバなど同期の管理に外部サーバを用いな
い
 ネットワーク遅延を考慮して同期再生を行う
 複数の受信者が存在する場合に，同一のストリー
ムは全受信者で同時に再生される（ストリームの
02/24/09
場合） 8
 提案機構の動作概要

Offset 通知テーブルに登録 ホスト

B
Receiver

Offset 通知
テーブル
ホスト
C
Receiver
ホスト
ASender

ホスト
D
Receiver

Internet

02/24/09 9
3 ) 転送遅延のもっとも長い
12 )) Sender
往復転送遅延 Receiver
は各 Receiver
/2 より片方向の転送遅延を求める
に合わせて Receiver ごとの offset を計算する
の往復転送遅延を測定する
 Offset 算出
Sender
offset 通知テーブ
ホスト ル
A B ⊿tD －⊿ tB
Receiver
C ⊿tD －⊿ tC
⊿tB ⊿tD －⊿ tB
ホスト 0
B D
Receiver ⊿tD －⊿ tC
⊿tC
ホスト
C
Receiver
⊿tD
ホスト
D
02/24/09 10

Time
通知後の offset テーブル
5) Sender から通知された Offset を登録
4) offset 計算後 offset 通知 ホスト
B
Receiver Offset
テーブル

A ⊿tD －
ホスト ⊿ tB
C
Receiver
ホスト Offset
ASender テーブル

Offset 通知 ホスト A ⊿tD －

テーブル D
⊿ tc
Receiver

Offset
B ⊿tD －⊿ tB Internet テーブル

C ⊿tD －⊿ tC
A 0
D 0
02/24/09 11
 ホスト B での動作例
ホスト B の offset テーブル
 ホスト A からのメディ
アに対しては⊿ tD －⊿ tB
A ⊿tD －⊿ tB
時間待って処理を行う

Sender

ホスト
Ａ
Receiver 再生
⊿tB ⊿tD －⊿ tB
ホスト
転送遅延 offset
Ｂ
02/24/09
同じメディアは同時刻に再生される 12
 同期再生機構の設計
定期的に全ての Receiver との転送遅延を計
転送遅延情報管理部 転送遅延情報をもとに Offset測 を算出し， Receiver と
offset の対応関係を示した通知用 offset テーブルに記
転送遅延計測部
Sender 通知用
録する
offset
offset 計算部 通知用 offset テーブルよりそれぞれの
テーブル
offset 通知部 Receiver に対して該当する offset を通知す
る

Internet 通信部
Offset を受け取って処理するアプリケーショ
ン
再生アプリケーション Sender から送られてきた情報をも
再生アプリケー
とに Receiver
ションへ offsetで処理を加え応答を
通
転送遅延情報管理部 知 返す
Receiver offset
転送遅延計測部 テーブル
offset 受信部
02/24/09 Sender から通知された offset を Sender13と
offset の対応を示した offset テーブルに記録
 転送遅延の測定方法
転送遅延計測部に RTCP(RFC3550) を用いている
アプリケーションに近い層で計測できる
― 実際に動作しているアプリケーションが受ける遅延時間に
近い

Sender Receiver
LSR
LSR
送信時のタイムスタンプを刻
む
RTCP Sender Report

受信時の処理にかかった
時間を DLSR として計 DLSR
測

RTCP Receiver Report

受信した時点でのタイム
スタンプを TA として刻 TA
む
TA
受信時刻 送信時刻 Receiver での処理時
刻
02/24/09 14
往復転送遅延 = TA ー LSR ー
転送遅延の測定方法（続き）
 実装に向けての問題
 タイムスタンプは gettimeofday で取得するため，タ
スクスイッチの影響などで精度が下がる

 通常の Linux のカーネルでは 1ms 単位の精度はだせ

ず転送遅延がばらつく

 転送遅延の傾向がつかめればよい
 RFC3550 でジッタの計測方法に用いられている方法

転送遅延 = (α× 新たな転送遅延 ) + ((1 － α) × 今までの転送遅延 )

02/24/09 　　　 (α= 1/16) 15
提案機構の実装
 本提案機構の転送遅延計測部
を音声伝送システム
RAT4.2.20 に実装

 RAT(Robust Audio Tool)

 Mbone の音声伝送ツール
 マルチキャスト通信可

02/24/09 16
実験
どのように転送遅延が計測できるか
Case1 : 片道 100ms の遅延を発生させた場合
Case2 : 片道 200ms の遅延を発生させた場合
CPU :
PentiumⅡ300MHz
遅延生成用 PC OS : Vine Linux2.6
片道 Kernel : 2.4.22
遅延発生にネットワークエミュ
100ms ， 200ms の レータの NISTNET 2.0.12 を使用
転送遅延生成
転送遅延計測メッセージ
転送遅延計測応答

Ethernet 100Mbps

CPU : Pentium4 CPU : Pentium4

3.2GHz 3.2GHz
ホスト A ホスト B OS : 　 RedHat Linux
02/24/09 OS : 　 RedHat Linux 17
8.0 8.0

Kernel : 2.4.22 Kernel : 2.4.22

実験結果
250

200
delay =200ms
delay =200ms : icmp
転送遅延 [msec]

150 delay =100ms

delay =100ms : icmp

100

50

0
0 100アプリケーション層でのオーバーヘッド
200 300 400 500 600
経過時間 [sec]
02/24/09 18
転送遅延の変動が少なくても処理遅延で 10ms 程度揺れる
処理遅延の変動
120

118

116

114
Delay = 100ms
転送遅延 [msec]

112

110

108

106

104 転送遅延が安定していても処理遅延でゆれる
102
音声などリアルタイム性の高いものには精度をさらに追求する必要がある
100
10ms 150
程度の揺れは資料提示ツールのような用途では許容範囲
200 250 300 350 400 450 500 550 600
02/24/09 19
経過時間 [sec]
実験 2
Offset の変動を観察するために以下の構成で実験を行っ
た．
転送遅延計測メッセージ
転送遅延計測応答
Ethernet 100Mbps

Sender ホスト A ホスト B

CPU Pentium4 　 CPU Pentium III 　 CPU Pentium4
3.2GHz 1GHz 3.2GHz
02/24/09 20
OS RedHat Linux OS Vine Linux 2.6 OS RedHat Linux 8.0
8.0
offset の変動
30

25
ホスト
A
20
転送遅延 [msec]

15

ホスト
10 B

ホスト B の
0 offset
0 50 100 150 200 250 300 350 400 450
02/24/09 経過時間 [sec] 21
プロトタイプの実装に当っての適
用条件

一つのストリームに対して保証
 同期するストリーム数
転送遅延計測応答が集中する
 Receiver の数 Receiver が増えると長い送出時間幅が必要にな
IGMP を使用 (IPv6 の場合は る MLD:Multicast
現在は 10 台程度を想定
 グループのメンバ管理 Listener Discovery)

 グループの状態変化と offset テーブル

Offset の再計算は，新たな Receiver
 転送遅延情報の信頼性 が参加してきた場合，
最長遅延の Receiver が離脱した場
 同期の精度 合に行う．

OS 自体の割り込み精度や同時に起動しているアプリ
ケーションによって精度への影響を十分に検討する 5 秒おきに Offset 通知．届かない
必要がある 場合は次回の通知を待つ．
利用するアプリケーションによって許容できる精度 転送遅延計測メッセージが不達の
の検討を行う必要がある 場合，前回の転送遅延を使用して
offset 計算を行う．
02/24/09 22
まとめ
同期再生が可能になると…
 遠隔講義
 資料提示ツールで多拠点に同時に資料を提示
 講師の音声また映像を同時に配信
受講者
 遠隔合唱
 伴奏を同時に多拠点に配信
 同じタイミングで合唱できる

受講者

 その他
 オークションなど同時に同じ情報を提示したい場面
Internet
 遠隔地にあるカメラを同時にコントロール
02/24/09 23
受講者
適用例（アプリケーションゲー
トウェイ）
Application Application
Gateway Gateway

Internet

Application
Gateway

遅延の変動の大きな区間に適用
02/24/09 24
全てのエンドシステムを変更する必要がない
今後の課題
 精度の問題
 アプリケーションの必要とする精度
 提案機構の実装
 Offset 通知部
 アプリケーションの実装
 資料提示ツール
 適用条件をさらに検討
 機能拡張

02/24/09 25
収束率 α
 収束率 α は以下の文献による
 時間とともにジッタが平均して滑らかに変化し、なお
かつジッタが現在のネットワーク状態を反映できるよ
うにする妥協点として α=16 が選ばれている。
 連続するジッタ量における瞬間的な突出を和らげる傾
向があり長期的な平均を示すことができる
 J. A. Cadzow, Foundations of Digital Signal
Processing and Data Analysis, MacMillan, New
York, 1987.

02/24/09 26
転送遅延と係数 α
タスクスイッチが影響している？
ノーマルのカーネルでは精度がでない
50

45 α =1/ 16
α =1
40

35
転送遅延 [mesc]

30

25

20

15

10

0
02/24/09 0 100 200 300 400 500 600 700 800 900 1000
27
経過時間 [sec]
実験
通信の途中に片道の転送遅延を切り替えた場合
ここでは 200ms から 300ms に切り替えた
転送遅延 = (α× 新たな転送遅延 ) + ((1 － α) × 今までの転送遅延 )
　　　 (α= 1/16)
CPU :
PentiumⅡ300MHz
遅延生成用 PC OS : Vine Linux2.6
Kernel : 2.4.22
遅延発生にネットワークエミュ
レータの NISTNET 2.0.12 を使用

転送遅延計測メッセージ
転送遅延計測応答

Ethernet 100Mbps

CPU : Pentium4 CPU : Pentium4

3.2GHz 3.2GHz
ホスト A ホスト B OS : 　 RedHat Linux
02/24/09 OS : 　 RedHat Linux 28
8.0 8.0

Kernel : 2.4.22 Kernel : 2.4.22

 収束するまでの時
間
α＝2 10 [sec]

転送遅延と係数 α
α＝4 25 [sec]
α＝8 60 [sec]
α ＝ 16 115 [sec]

400

350

300
転送遅延 [msec]

250

200

150
転送遅延
100 α =16
α =8
50 α =4
α =2

0
0 100 200 300 400 500 600 700 800 900
02/24/09 29
経過時間 [sec]
 転送遅延の振れ幅

α＝2 25 [msec]

転送遅延と係数 α α＝4
α＝8
16 [msec]
14 [msec]
α ＝ 16 5 [msec]
250 転送遅延
α =16
α =8
240
α =4
α =2
230
転送遅延 [msec]

220
48ms

210

200

190

180
02/24/09 200 250 300 350 400 450 500 550 600 30
経過時間 [sec]
転送遅延と係数 α
100
α =1
90 α =16
ICMP
80

70

60
RTT [msec]

50

40

30

20

10

0
0 200 400 600 800 1000 1200 1400 1600 1800 2000

02/24/09 経過時間 [sec] 31

同期再生機構の設計 (Sender)
 転送遅延情報管理部
 転送遅延計測部
 定期的に全ての Receiver との転送遅延を計測
 Offset 計算部
 転送遅延情報をもとに Offset を算出し， Receiver と
offset の対応関係を示した通知用 offset テーブルに記
録する
 Offset 通知部
 通知用 offset テーブルよりそれぞれの Receiver に対
して該当する offset を通知する
転送遅延情報管理部
転送遅延計測部
Sender 通知用 offset
offset 計算部
テーブル
02/24/09 offset 通知部 32
同期再生機構の設計 (Receiver)
 転送遅延情報管理部
 転送遅延計測部
 Sender から送られてきた情報をもとに Receiver で処
理を加え応答を返す
 Offset 受信部
 Sender から通知された offset を Sender と offset の対
応を示した offset テーブルに記録する
 再生アプリケーション
 Offset を受け取って処理するアプリケーション
再生アプリケーション
再生アプリケー
ションへ offset 通
転送遅延情報管理部 知
Receiver offset
転送遅延計測部 テーブル
offset 受信部
02/24/09 33
同期再生の利用可能性
 同じインタラクションを必要とするグループ内
で同期再生が可能になると…

 資料提示ツールで多拠点に同時に資料を提示

 遠隔セッションで伴奏など基準となる音声を同
時に配信できる
 一斉にカメラコントロールできる

ネットワーク遅延を考慮した
02/24/09 グループ内メディア同期機構の提案 34
実験環境
遅延生成用 PC により任意の遅延を発生させ、それぞれ遅延を変動させる
・遅延の変動を追えるか CPU PentiumⅡ 　
300MHz
・遅延の同期を行えているかを検証する
Subnet A OS Vine Linux2.1

200ms
Ethernet
100Mbps 300ms

遅延生成用 PC
遅延生成用に
Nistnet 使用

Ethernet
100Mbps
02/24/09 35

Subnet B
Nistnet
 NationalInstitute of Standards and
Technology: NIST で開発されたネットワー
クエミュレータ
 Linux で動作
 帯域やバッファの制限、遅延、ランダムなパケッ
ト損失を実現できる

Nistnet-2.0.12

02/24/09 36
グループの状態変化と offset
テーブル（グループから離脱
した場合）
 グループから離脱した場合
 最長遅延である Receiver が離脱した場合
 最長遅延である Receiver が離脱した時点で 2 番目に
遅延が長い Receiver を基準として再計算を行う
 最長遅延でない Receiver が離脱した場合
 Offset の再計算を行う必要はない
 離脱して 180 秒経過したのち該当の Receiver を
offset テーブルから削除する

02/24/09 37
グループの状態変化と offset テーブル
（最長遅延である Receiver が離脱した
場合）
Offset 通知テーブル
最長遅延である Receiver が離脱した時点で
ホスト 2 番目に遅延が長い Receiver を基準として再計算を行う
A B ⊿t3(A) -⊿t1(A)
C ⊿t3(A) -⊿t2(A)
⊿t1(A) ⊿t3(A) -⊿t1(A)
ホスト D 0

B
⊿t2(A) ⊿t3(A) -⊿t2(A)
ホスト
C
⊿t3(A)
ホスト
D 最長遅延のホスト D が離
02/24/09 脱 38

Time
グループの状態変化と offset テーブル
（最長遅延である Receiver が離脱した場
合）
Offset 通知テーブル
ホスト
A B ⊿t2(A) -⊿t1(A)

⊿t2(A) -⊿t1(A) C 0
⊿t1(A)
ホスト D
B
⊿t2(A)
ホスト
C 次に遅延の長いホスト C
を基準として再計算

ホスト
D
02/24/09 39

Time
 グループの状態変化と offset テーブル
（最長遅延でない Receiver が離脱し
た場合）
Offset 通知テーブル
ホスト
A B ⊿t3(A) -⊿t1(A)

C ⊿t3(A) -⊿t2(A)
⊿t1(A) ⊿t3(A) -⊿t1(A)
ホスト D 0

B
⊿t2(A) ⊿t3(A) -⊿t2(A)
ホスト
C 180ホスト
秒経過したのち削除
C が離脱

⊿t3(A)
ホスト
Offset の再計算を行う必要はない
D
02/24/09 40
離脱して 180 秒経過したのち該当の Receiver を offset テーブルから削除する
Time
グループの状態変化
（グループに参加した場合）
 新たに Receiver が参加した場合
 Sender が offset の再計算を行い，各 Receiver に
通知する
 参加してきた Receiver が最長遅延か否かに関わ
らず再計算を行う

02/24/09 41
グループの状態変化と offset テー
ブル
（グループに参加した場合）
Offset 通知テーブル
ホスト
A B ⊿t3(A) -⊿t1(A)

C ⊿t3(A) -⊿t2(A)
⊿t1(A) ⊿t3(A) -⊿t1(A)
ホスト D 0

B
⊿t2(A) ⊿t3(A) -⊿t2(A)
ホスト
C
⊿t3(A)
ホスト
D
02/24/09
Sender が offset の再計算を行い，各 Receiver に通知する 42

Time
 グループの状態変化と offset テー
ブル
（グループに参加した場合）
Offset 通知テーブル
ホスト
A B ⊿t3(A) -⊿t1(A)

C ⊿t3(A) -⊿t2(A)
⊿t1(A) ⊿t3(A) -⊿t1(A)
ホスト D 0

B E ⊿t3(A) -⊿t4(A)

⊿t2(A) ⊿t3(A) -⊿t2(A)

ホスト 追加
C
⊿t3(A)
ホスト
D
⊿t4(A)
ホスト
E02/24/09 43

Time
転送遅延情報の信頼性
 Offset 通知は 5 秒おき Sender Receiver
転送遅延計測

転送遅延計測応答
 パケット損失などで
Offset 通知
Receiver に offset 通知が 転送遅延計測

届かない場合は再送など 5sec
転送遅延計測応答

の信頼性の回復は行わず Offset 通知

次回の通知を待つ 転送遅延計測 不達
次回通知を待つ
転送遅延計測応答

Offset 通知

02/24/09 44
背景
 RTP では実時間性（ソースの時間的な順序）は保証
するがホスト間の同期性は保証できない

3 同時に再生
2

1 1 1

1 2 3

グループ内メディア同期再生機構のフレームワークの
02/24/09 45
転送遅延情報の信頼性（続
き）
 Sender からの転送遅延計測メッセージに対
して Receiver からの応答が帰ってこなかっ
た場合
 前回の転送遅延を使用して offset 計算を行う
 不達の Receiver は Timeout 状態とし， Timeout
Sender Receiver
が 60 秒超すと
不達の場合： Stale 状態となり
Timeout 状態 offset の計算に
転送遅延計測

いれない 転送遅延計測応答
Timeout 状態で 60 秒超過： Stale 状態
Offset 通知
Stale 状態で転送遅延応答受信
転送遅延計測
： Reachable 状態
転送遅延計測応答

前回の転送遅延
02/24/09
を使用
損失 46
検討要因
　　　　　転 150ms 以下 150ms 以上 400ms 以上
送遅延 400ms 未満
双方向性 高 中 低

補正幅 高精度 (1ms 中精度 低精度

単位 ) (10ms 単位 ) (50ms 単位 )
収束時間 ? ? 長くても可

利用場面 遠隔合唱な 会話，テレ 放送型

ど同期性の ビ会議
02/24/09 高い利用場 47

面
通知後の offset テーブル
ホスト B ホスト C
A ⊿t3(A) -⊿t1(A) A ⊿t3(A) -⊿t2(A)

ホスト D
A 0

02/24/09 48
同期再生できるとこんなこと
ができる
 単一ホスト内でのメディア同期
 メディア内同期
 メディア間同期
 グループ通信でホスト間同期することで広が
る
 ＲＭＣＰ

 ネットワーク遅延は変動する

ネットワーク遅延を考慮したグループ内メディア同期機構の必要性
02/24/09 49
同期の精度
 本提案機構は，より遅延が増加する傾向にあ
る
 低遅延が要求されるアプリケーションでは実用が
難しい場合がある
 要求する遅延時間に対して再生アプリケーション
自体の処理遅延が十分小さい場合には有用
処理遅延 要求遅延

ex) 処理遅延 30ms 要求遅延 200ms

OS 自体の割り込み精度や同時に起動しているアプリケーションによって
精度への影響を十分に検討する必要がある
02/24/09 50
ホスト A からのオフセット
オフセット通知テー
ホスト ブル
A B ⊿t3(A) -⊿t1(A)
C ⊿t3(A) -⊿t2(A)
⊿t1(A) ⊿t3(A) -⊿t1(A)
ホスト 0
D
B
⊿t2(A) ⊿t3(A) -⊿t2(A)
ホスト
C
⊿t3(A)
ホスト
D
02/24/09 51

Time
ホスト B からのオフセット
オフセット通知テー
ホスト ブル
A ⊿t3(B) -⊿t1(B)
B
C ⊿t3(B) -⊿t2(B)
⊿t1(B)
ホスト D 0
A
⊿t2(B)
ホスト
C
⊿t3(B)
ホスト
D
02/24/09 52

Time
ホスト C からのオフセット
オフセット通知テー
ホスト ブル
A ⊿t3(C) -⊿t1(C)
C
B ⊿t3(C) -⊿t2(C)
⊿t1(C)
ホスト D 0
A
⊿t2(C)
ホスト
B
⊿t3(C)
ホスト
D
02/24/09 53

Time
ホスト D からのオフセット
オフセット通知テー
ホスト ブル
A ⊿t3(D) -⊿t1(D)
D
B ⊿t3(D) -⊿t2(D)
⊿t1(D)
ホスト C 0
A
⊿t2(D)
ホスト
B
⊿t3(D)
ホスト
C
02/24/09 54

Time
 求められたオフセットテーブ
ル
ホスト ホスト
B A ⊿t3(B) -⊿t1(B) A B ⊿t3(A) -⊿t1(A)

C ⊿t3(C) -⊿t1(C) C ⊿t3(C) -⊿t2(C)

D ⊿t3(D) -⊿t1(D) D ⊿t3(D) -⊿t2(D)

ホスト ホスト
A C ⊿t3(A) -⊿t1(A) A D 0

B ⊿t3(B) -⊿t2(B) B 0

D 0 C 0
02/24/09 55
RTP （ Real-time Transport
Protocol ） RFC1889
 ストリーミング用の伝送を行う標準プロトコル
 主に多人数での電子会議を行うために作られた
 現在ではストリーミングのためのプロトコルとして利用

 RTP の特徴
 実時間データ転送
 タイムスタンプによりデータの時間的な関係を把握
 音声や映像の情報を転送することを目的としている
 通常、音と画像は別ストリーム
 制御用のプロトコル RTCP

02/24/09 56
 RTCP の機能
通信状態の報告 識別子の提供

RTCP を用いてデータの受
信状況の報告を行うことが ユーザの名前や e-mail アドレス
できる。 などから構成される識別子を提
パケット損失、ジッタ、参 供する
加者情報

制御メッセージの送信間隔の自律的な制御 メディア間の同期

セッションの参加者数が増加する
と、転送する RTCP の制御メッ
RTP のタイムスタンプと実時
セージの転送量も増加する、そのた 間の関連付けを行う機能を提供
め、制御メッセージのトラフィック する。この機能により異なる
量を制限するために、メッセージの データストリーム間の同期をと
送信頻度を低下させる機構を持つ ることができる

02/24/09 57
 RTCP Sender Report
v=2 P RC PT=SR=200 パケット長
送信元 SSRC 識別子
sender report
NTP タイムスタンプ (MSB)
NTP タイムスタンプ (LSB)
RTP タイムスタンプ
送出パケット数 (total_packets)
送出バイト数 (total_bytes)

report block * n
SSRC 識別子 #n
瞬時廃棄率 累積廃棄パケット数
シーケンスナンバの最大値
ジッタ遅延
SSRC #n の最新の SR 受信時の NTP タイムスタンプ (LSR)
02/24/09 LSR から現在までの遅延 (DLSR) 58
 RTCP Receiver Report
v=2 P RC PT=RR=201 パケット長
送信元 SSRC 識別子
report block * n
SSRC 識別子 #n
瞬時廃棄率 累積廃棄パケット数
シーケンスナンバの最大値
ジッタ遅延
SSRC #n の最新の SR 受信時の NTP タイムスタンプ (LSR)
LSR から現在までの遅延 (DLSR)

02/24/09 59
 RTCP Application Specific
v=2 P RC PT=204 パケット長

report block * n
SSRC 識別子
アプリケーション名
ＳＳＲＣ #n
SSRC #n オフセットタイムスタンプ

アプリケーション固有データ

02/24/09 60
RTCP パケット一覧

名称 目的

SR (Sender Report) 送信者からのＮＴＰタイムスタンプと統計情報 ( 送信パケット

数、送信バイト数 ) の通知
＋　受信者でもある場合は Receiver Report

RR (Receiver Report) 受信者からの統計情報 ( パケット損失率、累積喪失パケット

数、最大受信シーケンス番号、ジッタ等 ) の通知

SDES (Source Description) セッション参加者の情報 (CNAME 、メールアドレス等 )

BYE セッションからの明示的な離脱

APP (Application Specific) アプリケーション拡張

アプリケーション固有メッセージを規定できる

02/24/09 61
2 階層のメディア同期
メディア内同期
(1) メディア内同期
一つのメディア ( ビデオ、あるいはオーディオ )
の同期再生の実現
― 　時間的な順序どおりに再生
( 手段 ) RTP タイムスタンプ

ビデオ
(2) メディア間同期
メディア間同期
複数のメディア ( ビデオとオーディオ ) の同期
オーディオ
再生の実現
― 　リップシンク
( 手段 ) RTCP によるタイムスタンプの関連付け

02/24/09 62
メディア内同期
入力 送信 受信 再生
TS =100

TS =100 バッファリング遅延
TS =150 RTP パケット

TS =200 TS =150
RTP タイムスタンプに
TS =200 よる再生時刻の復元
TS =250
TS =100
TS =300 TS =250
TS =150
TS =300 Interne
TS =350
t TS =200
TS =350
TS =250

TS =300

TS =350
到着時間の
ジッタ
揺らぎ
02/24/09 エンコード デコード 63
メディア間同期
リップシンクのずれ
補正後 ( メディア間同期 )
補正前 ( メディア内同期 )

オーディオ 音声 (RTP) 時間軸

ビデオ 補正 補正
ビデオ (RTP) 時間軸

補正
RTCP 共通 (NTP) 時間軸
(Sender のシステム時間 )

個々のメディア用タイムスタンプ (RTP)
共通時間軸との差分
＋ 共通時間軸のタイムスタンプ (NTP)
02/24/09 をとり補正 64