SRSVP プロト コルを用いた

1N{5インターネット 放送システムの実装
外池昌嗣 3 古村隆明 y 藤川賢治 y 池田克夫 y3
京都大学工学部 y 京都大学大学院情報学研究科

1 はじめに
本研究では，SRSVP(Simple Resource ReSerVa-tion Protocol)[1] を用いたインターネット放送システムを実装する．ここで取り上げる放送は音声と動画からなるマルチストリームで，RTP[3] のタイムスタンプを用いて音声と動画の同期を取ることができる．SRSVP とはインターネット上で資源予約とマルチキャストを実現するためのプロトコルである．資源予約をすることにより，QoS(Quality of Service)保証された経路を用いて，高品質なストリームを安定して伝送できる．
放送を IP 化するメリットとしては，中継装置が全てルータで済むため，コストが抑えられることや，個人が放送できることがあげられる．

継地点にユニキャスト送信し，ランデブーポイントがマルチキャスト送信する場合もある．資源予約は受信者主導で受信者からランデブーポイントへ資源予約をする．図 1 にその様子を示す．
ランデブーポイント ルータ

P1

T3ルータ

受信者

T4

R1

S1 送信者
資源予約メッセージ
映像・音声ストリーム（マルチキャスト)映像・音声ストリーム（ユニキャスト)

T5

R2ルータ

受信者

図 1: SRSVP マルチキャスト資源予約

今回実装するシステムでは，単独で放送するだけでなく，他の放送局の放送を中継し，加工して放送

3 ibcast URIすることを目指す．これにより，他国の放送に自国の音声を付加して放送することができる．また，他放送の受信に必要な，マルチキャストアドレ ス，ポート番号，放送開始終了時刻，繰り返し間隔，繰国から受信した動画像を再編集して放送することも考慮している．

り返し回数，放送のデータ形式とパラメータといった情報を，本稿で定義する ibcast URI に記載する．

2 章で SRSVP の概略を説明し，3 章で本研究で設計した，放送の受信に必要な情報を記述するためのibcast URI を定義し，4 章でシステムの外観を示し，ibcast URI は SDP[5] を参考に設計した．ibcast URIの構文は以下のようになる．ただし，[ ] は省略可能を表し，*は直前の項目の 0 回以上の繰り返しを，+5 章でその実装及び実験環境について述べる．

は 1 回以上の繰り返しを表す．

2 SRSVP プロト コル

ibcast://<IP アドレ ス>/[t=<開始時刻>:<終了時
刻>&[r=<繰り返し間隔>:<繰り返し時間>&]*][m=rtp:<ポート番号>:<ペイロード タイプ >:<エン
コーデ ィング名>:<クロックレート >[:<パラメータ>]*]+SRSVP は，マルチキャスト，資源予約，課金を実現することを目的としたプロトコルである．資源を予約をすれば，帯域，遅延，パケットロス率といった QoS が一定の値に保証される．SRSVP で資源予約をするためには，経路上のルータが QoS 保証の機能を持っていて，かつ SRSVP 対応でなければならない．
ストリームのマルチキャスト送信は送信者自身が直接行う場合も，ランデブーポイントと呼ばれる中Implementation of an Internet Broadcasting System using
SRSVP
3 TONOIKE Masatsugu, Faculty of Engineering, Kyoto University
y KOMURA Takaaki, FUJIKAWA Kenji, and IKEDA Katsuo, Graduate School of Informatics, Kyoto University

例として，マルチキャストアドレスが 224.130.54.22
で CD 音質 2ch の音声ストリームがポート番号 9000番に，30fps の JPEG ストリームがポート番号 9001番に放送されていることを示す ibcast URI を示す．

ibcast://224.130.54.22/m=rtp:9000:96:L16:44100:2&m=rtp:9001:97:JPEG:30

4 システムの外観
ユーザー側では，まずブラウザで放送局もしくは番組表の Web ページを開く．そこに記載されている

リンクをクリックすれば，専用アプリケーションが起動し，受信を開始，もしくは番組予約をする．図
2 にその様子を示す．また，受信の前に，SRSVP プ
ロトコルの手順にしたがって放送局との間に資源予約を成立させる．

シドニー

京都

AS

C

VS

RVP

CASC
VOD

映像のみ中継東京
IBCAST番組表
ファイル 編集 表示

受信アプリケーション起動

ジャンプ

VSC

RVP

C

RVP

C

AS

C

VS

URL http://www.hogehoge.com/soccer/today.html

C

IBCAST番組表
サッカー 日本対オーストラリア

19:00~22:30

放送中!

見るVOD

VODサーバAS

オーディオサーバ

RVP

ランデブーポイント

VS

ビデオサーバC

クライアントClickユニキャストストリーム
マルチキャストストリーム

図 2: 受信側

図 3: ネットワークの概要

放送局側では，コントロールアプリケーションをできる．京都のエリアでは，VOD のストリームをマルチキャスト送信する．東京のエリアでは，二種用いて，ビデオサーバ，オーディオサーバに初期パラメータを与えてこれらを起動し，ストリームをラ類の放送をする．一つは，東京の映像と音声を一つンデブーポイントに送信する．サーバがランデブーポイントに送信するコンテンツは，サーバがリアルの放送としたものである．もう一つは，シド ニーの放送を受信し，音声のみを別のものに差し替えて中タイムにキャプチャーしたもの，サーバのディスク継したものである．シド ニーのエリアではシド ニーの映像と音声のストリームを一つの放送とする．シ

装置に蓄積されているもの，もしくは他の放送局からリアルタイムに受信したものなどである．
そして，ランデブーポイントは放送局からストリームを受け取り，指定されたマルチキャストアドレスとポート番号に対してストリームを送信する．また，受信者からの資源予約メッセージを受け取り，返答メッセージを受信者に返すことにより，資源予約を成立させる．

5 システムの実装と実験環境
クライアント及びサーバは SRSVP に対応させた
FreeBSD 4.2-RELEASE 上に実装する．実装するものは表 1 の通りである．
表 1: 実装するモジュール

放送局側
オーディオサーバ
オーディオコントローラ
ビデオサーバ
ビデオクライアント
ランデブーポイント
コントローラ

RVP

(RVP)

受信者側
オーディオクライアント
ビデオクライアント
解釈機能付きコントローラURI
AV

実験環境は京都，東京，シド ニー間の通信を想定した，閉じたネットワークを研究室内で構築する．以下にその概要を示す．
実験では，図 3 に示すようにストリームを送信する．なお，クライアントはどのエリアの放送も受信ステム上の複数の送信者に帯域を違反させても，帯域を守って送信しているストリームは影響を受けな
いことも検証する予定である．

6 おわりに本稿では，マルチキャストと資源予約を実現する

SRSVP を用いたインターネット放送の外観と実験環境を示した．今後は，上記のシステムを実装し ，QoS 保証された放送がとぎれることなく受信できることを検証する予定である．

参考文献[1] Fujikawa, K., Ohta, M., and Ikeda, K., \Integration of Multicast Routing and QoS Routing," Proc. ofINET2000, July 2000.
[2] 田中 剛, 藤川 賢治, 池田 克夫, \ランデブーポイント制御に基づく会議のフロアコントロール方式," 情報処理学会研究報告 2000-DPS-97, March 2000.
[3] Schulzrinne, H., \RTP: A Transport Protocol for RealTime Applications," RFC 1889, January 1996.
[4] Schulzrinne, H., \RTP Pro le for Audio and Video Conferences with Minimal Control," RFC 1890, January1996.
[5] Handley, M., and Jacobson, V., \SDP: Session Description Protocol," RFC 2327, April 1998.