9.2 マルチメディアアプリケーション

前節で説明した伝統的アプリケーションと同様に、電話やビデオ会議といったマルチメディアアプリケーションにも独自のプロトコルが必要となる。マルチメディアアプリケーション用プロトコルを設計する初期の実験は多くが MBone Tools で行われた。MBone Tools は MBone と呼ばれるネットワーク向けに開発されたアプリケーションの総称であり、vat や vic が含まれる。MBone は IP マルチキャストをサポートする実験的オーバーレイネットワークで、複数人参加のビデオ会議などが可能だった (オーバーレイネットワークは第 9.4 節で詳しく説明する)。最初のうちはそれぞれのアプリケーションが独自のプロトコルを (ときには複数) 実装していたものの、異なるマルチメディアアプリケーションでも要件は共通することが明らかになった。ここからマルチメディアアプリケーションでの利用を念頭に置いた汎用プロトコルがいくつも生まれていった。

マルチメディアアプリケーションが利用するプロトコルは本書でいくつか見てきた。第 5.4 節で解説した RTP (Real-time Transport Protocol) は時刻情報の伝達や符号化方式・メディアタイプの識別といったマルチメディアアプリケーションに共通する機能の多くを提供する。

RSVP (Resource Reservation Protocol) を使うと、アプリケーションは自身が必要とする QoS (クオリティオブサービス) を手に入れるためにネットワークが持つリソースの確保をリクエストできる。本節ではリソース割り当てがマルチメディアアプリケーションの他の側面に与える影響を説明する。

マルチメディア転送とリソース割り当てを行うプロトコルに加えて、多くのマルチメディアアプリケーションにはセッション制御 (シグナリング) 用のプロトコルも必要となる。例としてインターネット越しの通話 (Voice over IP, VoIP) を考えよう。このアプリケーションでは、通話がかかってきたときにそのことをユーザーに伝える (例えばマルチメディアサービスに対してメッセージを送信し、受け取ったマルチメディアサービスがベルの音を鳴らす) 仕組みが必要になる。他にも通話の転送や三方向通話といった機能のサポートも必要になるかもしれない。セッション制御の問題を解決するプロトコルとして SIP (Session Initiation Protocol) や H.323 がある。本節ではこれらのプロトコルを解説するところからマルチメディアアプリケーションの議論を始める。

9.2.1 セッション制御と通話制御

セッション制御に関する問題をいくつか理解するために、次のシナリオを考えよう。特定の時刻にビデオ会議を開催し、それを多くの参加者が視聴できるようにしたいとする。映像ストリームを MPEG-2 でエンコードし、そのデータをマルチキャスト IP アドレス 224.1.1.1 を使って、ポート番号 4000 の UDP 上で実行される RTP で送信すると決めたとする。この情報を参加する可能性のある全ての人物に伝えるにはどうすればいいだろうか？メールで送るのも一つの手だが、この種の情報を伝えるための標準フォーマットとプロトコルが存在するのが望ましい。IETF はマルチメディア通信を開始するときに必要な情報を伝えるためだけに存在するプロトコルをいくつか策定している。例えば次のプロトコルが存在する:

SDP (Session Description Protocol)
SAP (Session Announcement Protocol)
SIP (Session Initiation Protocol)
SCCP (Simple Conference Control Protocol)

単純そうに思えるタスクに対してプロトコルが多くあるのはどうしてだろうと不思議に思ったかもしれないが、このタスクには様々な側面があり、対処が全く異なる状況がいくつか存在する。例えば、特定のビデオ会議セッションが MBone 上で視聴可能になることを伝える問題 (SDP と SAP が扱える) と、特定の瞬間に特定のユーザーにインターネット通話を試みる問題 (SDP と SIP が扱える) では対処が異なる。前者では、セッション情報を標準フォーマットでウェルノウンマルチキャストアドレスに送信すれば仕事は終わったと考えて構わない。後者では、通話相手を検索し、発信元が通話を望んでいる事実を相手に伝え (相手の「ベル」を鳴らし)、さらにおそらくは参加者間で音声の適切な符号化方式を交渉しなければならない。本節では最初に多くのアプリケーションで使われる SDP を解説し、その後にインターネット電話といった対話的アプリケーションで使われる SIP を解説する。

SDP (Session Description Protocol)

SDP (Session Description Protocol) は様々な状況で利用できる非常に一般的なプロトコルであり、他のプロトコル (SIP など) と一緒に使われることが多い。SDP が伝達できる情報の例を示す:

セッションの名前と用途
セッションの開始時刻と終了時刻
セッションのメディアタイプ (「音声」「映像」など)
セッションを受信するために必要な詳細情報 (データが送信されるマルチキャストアドレス、利用されるトランスポートプロトコル、ポート番号、符号化方式など)

こういった情報を SDP は ASCII テキストで提供する。次の例に示すように、この ASCII テキストの各行は <type>=<value> の形をしている:

v=0
o=larry 2890844526 2890842807 IN IP4 128.112.136.10
s=Networking 101
i=A class on computer networking
u=http://www.cs.princeton.edu/
e=larry@cs.princeton.edu
c=IN IP4 224.2.17.12/127
t=2873397496 2873404696
m=audio 49170 RTP/AVP 0
m=video 51372 RTP/AVP 31
m=application 32416 udp wb

HTML と同様、このフォーマットは人間に読みやすくありつつも、厳格な規則によって機械が曖昧さなく解釈できるようになっている。例えば、SDP の仕様は <type> に許される値および並べるときの順序、そして各 <type> に対する <value> のフォーマットと予約語を定義する。

最初に気が付く点として、全ての <type> は一文字で表される。例えば一行目の v は version の略であり、v=0 は「バージョン」の値が 0 であることを表す: つまりこのメッセージは SDP のバージョン 0 が定めるフォーマットを持つ。次の行の o は origin の略であり、対応する <value> はセッションの「送信元origin」情報を表す。この部分にはセッションを一意に特定するのに十分な情報が含まれる。例えば larry はセッション作成者のユーザーネーム、128.112.136.10 はセッション作成者の IP アドレスを表す。larry に続く二つの数字は送信マシンで一意なセッション識別子と SDP 広報の「バージョン」番号をそれぞれ表す。将来セッション情報が更新されたときに送られるメッセージではバージョン番号が大きくなる。

次の三行 (i=..., s=..., u=...) はセッション名、セッションの説明、セッションの URI (前節で解説した) を表す。これらの情報はユーザーがセッションに参加するかどうかを判断するときに利用される。例えばセッションディレクトリツール (session directory tool) は SDP を使って広報された開催中および開催予定のイベントをユーザーインターフェースに表示するだろう。次の行 (e=...) はセッションに関して問い合わせをしたいときに連絡すべき人物のメールアドレスを表す。図 222 に sdr と呼ばれる (今では使われていない) セッションディレクトリツールのスクリーンショットを示す。ここにはスクリーンショットが取られたときに広報されていたセッションが示されている。

図 222.

SDP メッセージから取り出した情報を表示するセッションディレクトリツール

以降の行にはアプリケーションプログラムがセッションに参加するときに利用する技術的情報が並ぶ。7 行目の c=... はセッションのデータが送信される IP マルチキャストアドレスを表す。セッションの受信を望むユーザーはこのマルチキャストグループに参加する必要がある。次の行はセッションの開始時刻と終了時刻を表す。両方の時刻は NTP (Network Time Protocol) で整数として表される。最後に、セッションが利用するメディアに関する情報が記される。今考えている例ではセッションが三つのメディアを持つ ── このセッションは音声、映像、そして wb と呼ばれるホワイトボードアプリケーションに関するデータを配信する。それぞれのメディアについて、各行は次のフォーマットをしている:

m=<メディアタイプ> <ポート番号> <トランスポートプロトコル> <フォーマット>

「メディアタイプ」に説明は必要ないだろう。「ポート番号」はこの例では UDP のポート番号を表す。「トランスポートプロトコル」の部分を見ると、wb アプリケーションのデータは UDP を使って転送されるのに対して、音声と映像は「RTP/AVP」を使って転送されるのが分かる。「RTP/AVP」は AVP と呼ばれるアプリケーションプロファイル (application profile) を用いる RTP (Real-time Transport Protocol) を意味する。このアプリケーションプロファイルは音声と映像に対する符号化方式をいくつか定義しており、「フォーマット」の部分でどれを使うかが指定される。0 はサンプリングレート 8 KHz で 8 ビットサンプルの音声符号化方式を表し、31 は映像符号化方式 H.261 を表す。符号化方式を表すこれらのマジックナンバーは AVP プロファイルを定義する RFC に記述されている。SDP に非標準の符号化方式を記述することもできる。

最後の行では「フォーマット」の部分に wb が指定されている。このデータの符号化に関する情報は wb アプリケーションに特有なので、この部分にはアプリケーションの名前を指定するだけで十分となる。これは MIME タイプに application/wb を指定するのと同じことだと言える。

SDP の用途の一つにマルチメディア会議の広報がある。これは SDP メッセージをウェルノウンマルチキャストアドレスに送ることで行われる。図 222 に示したようなセッションディレクトリツールは受け取った SDP メッセージから集めた情報をまとめてユーザーに表示する。SDP は IP を通じた娯楽映像の配信 (IPTV と呼ばれる) においても各 TV チャンネルが配信する映像に関する情報を提供するために利用されている。

これで SDP を用いたセッション情報の伝達が説明できたので、次項では実際にセッションを開始する方法を説明する。SDP は SIP (Session Initiation Protocol) と共に使われることでも重要な役割を果たす。VoIP (Voice over IP, IP ネットワーク越しの電話) や IP ベースのビデオ会議が広く使われるようになったことで、SIP はインターネットプロトコルスイートの中でも特に重要なプロトコルの一つとなった。

SIP

SIP はアプリケーション層プロトコルである。リクエスト/レスポンスモデルを採用するので、HTTP と似ていると言えなくもない。しかし SIP は HTTP とは異なる種類のアプリケーションを念頭に置いて設計されており、提供される機能は HTTP と大きく異なる。SIP が提供する機能は次の五つのカテゴリに分類できる:

ユーザーの検索: 特定のユーザーと通信する場合に到達すべき正しいデバイスを特定する。
ユーザーの状態取得: ユーザーが通信セッションに参加できるかどうか、そして参加したいと思っているかどうかを調べる。
ユーザーとの交渉: 利用するメディアや符号化方式といった事項を決定する。
セッションのセットアップ: 通信の参加者が利用するポート番号といったセッションパラメータを設定する。
セッションの管理: セッションの移管 (「通話転送」の実装に必要) やセッションパラメータの変更といった様々な操作を行う。

こういった機能の多くに詳しい説明は必要ないだろう。ただ、ユーザーの検索に関しては議論をしておきたい点がある。SIP と (例えば) HTTP の間の重要な違いの一つに、SIP は主に人間と人間の通信で使われるという事実がある。そのため、マシンではなく個別のユーザーを検索できることが重要となる。そしてメールと異なり、通話では相手のユーザーが後でメッセージを確認するサーバーを見つけてそこにメッセージを送信するだけでは十分でない ── 通話相手のユーザーが現在マシンを利用中で、発信元と通話を望んでいることを確認する必要がある。この問題はユーザーが通話可能なデバイスを複数持つ場合がある事実によってさらに複雑になる: オフィスにいるときはデスクトップ PC で通話し、移動中は携帯デバイスで通話するかもしれない。複数のデバイスが同時に起動されることもあるだろうし、異なるデバイスは機能も大きく異なる (テキストしか送受信できないデバイスもあれば、映像通話が行えるデバイスもある)。理想的には、他のユーザーがどんなときでも適切なデバイスを検索して通信できるのが望ましい。さらに、いつ、どこで、誰からの発信を受け取るかをユーザーが制御できなければならない。

ユーザーが通話を適切なレベルで制御できるようにするために、SIP にはプロキシ (proxy) の概念が存在する。SIP プロキシはユーザーが別のユーザーに最初の通話リクエストを送るときの宛先として機能する。プロキシは発信を受けたユーザーに代わって様々な処理を行う。これから例を使ってプロキシの動作を説明する。

図 223 に示した二人のユーザー間の通話を考えよう。まず気が付くのは、それぞれのユーザーの名前が user@domain というメールアドレスに似たフォーマットをしていることである。Bruce が Larry とのセッションを開始したいと思ったとき、Bruce はドメイン cisco.com を管轄するプロキシに最初の SIP メッセージを送信する。このメッセージには次のような形をした SIP URI が含まれる:

SIP:larry@princeton.edu

SIP URI はユーザーの完全な識別子を提供する。ただしユーザーの場所は時とともに変化するので、(URL と異なり) SIP URI はユーザーの場所を提供しない。ユーザーの場所を特定する方法については後述する。

Bruce からの最初の SIP メッセージを受け取ったプロキシは SIP URI を確認し、そのメッセージを princeton.edu を管轄する別のプロキシに転送すべきであることを理解する。ここでは、ユーザーの名前からユーザーが通話の受信を望むデバイスの IP アドレスを取得するデータベースを princeton.edu のプロキシが持っていると仮定する。このデータベースを使って最初のメッセージは Larry が選択したデバイスに転送される。一つのメッセージを複数のデバイスに送ることをフォーク (fork) と呼ぶ。フォークはまとめて行うことも一つずつ (最初に固定電話にメッセージを送り、応答がなければ携帯電話にメッセージを送る、といった形で) 行うこともできる。

Bruce が Larry に送る最初の SIP メッセージは INVITE メッセージである可能性が高い。INVITE メッセージの例を次に示す:

INVITE sip:larry@princeton.edu SIP/2.0
Via: SIP/2.0/UDP bsd-pc.cisco.com;branch=z9hG4bK433yte4
To: Larry <sip:larry@princeton.edu>
From: Bruce <sip:bruce@cisco.com>;tag=55123
Call-ID: xy745jj210re3@bsd-pc.cisco.com
CSeq: 271828 INVITE
Contact: <sip:bruce@bsd-pc.cisco.com>
Content-Type: application/sdp
Content-Length: 142

最初の行は行われる処理 (INVITE)、処理の対象 (通話相手 sip:larry@princeton.edu)、そしてプロトコルのバージョン (2.0) を表す。二行目以降はヘッダーであり、その形式はメールメッセージのヘッダーに似ているので見覚えがあるだろう。SIP は多数のヘッダーフィールドを定義しており、ここで説明するのはその一部でしかない。Via フィールドはこのメッセージの送信元 (最後にメッセージを転送したデバイス) を表す。Content-Type と Content-Length フィールドはヘッダーに続くボディの形態を表す (MIME で符号化されたメールメッセージと同様)。この例でボディは SDP メッセージであり、そこには Bruce が Larry との通話で利用したいと思っているメディアの種類 (音声、映像など) や Bruce のデバイスがサポートする符号化方式といったセッションの設定が含まれる。 SIP ではセッションの設定を伝えるときに任意のプロトコルを利用できる点に注意してほしい。ただ最もよく使われるのは SDP である。

プロキシの動作の解説に戻ろう。INVITE メッセージが cisco.com のプロキシに到着すると、このプロキシはメッセージを princeton.edu のプロキシに転送するのに加えて、INVITE メッセージの送信者に対してレスポンスを返答する。レスポンスは HTTP と同じくレスポンスコードを持ち、その意味も HTTP と似ている。図 224 に SIP セッションで交わされる SIP メッセージとレスポンスの例を示す。

図にある最初のレスポンスメッセージは暫定的なレスポンス 100 trying であり、発信元のプロキシがメッセージを受信してエラーが起こらなかったことを発信元に伝える。INVITE メッセージが Larry のデバイスに到着すると、そのデバイスは「プルプルプル...」という着信音の再生を開始しつつ 180 ringing レスポンスを返答する。このメッセージが Bruce のデバイスに到着すると、そのデバイスでも着信音の再生が始まる。Larry がデバイスを操作して Bruce との通話を受け入れると、Larry のデバイスは 200 OK レスポンスを送信する。Bruce のデバイスは ACK で返答し、そこからメディア (RTP でカプセル化された音声ストリームなど) のやり取りが始まる。なお、ACK を送信する直前の時点で両参加者は通信相手の IP アドレスを知っているので、ACK はプロキシを経由せず直接送信できる。これ以降もプロキシが通話に関わることはない。このため典型的なケースでは、最初に送られるシグナリングメッセージとメディアは異なる経路で転送される。さらに言えば、メディアのやり取りが開始された後にプロキシのいずれかまたは両方で障害が発生したとしても、メディアのやり取りは問題なく進行する。最後に、セッションの終了を望む参加者は BYE メッセージを送信し、それに対して通常の状況では 200 OK レスポンスが返される。

以上の説明で省略した詳細の一つに、セッション形態の交渉がある。例えば Bruce は音声と映像による通話を行いたいと思っているのに対して、Larry の携帯電話は音声通話にしか対応していないかもしれない。このため、Larry の携帯電話が送信する 200 OK レスポンスには Larry とそのデバイスが受け入れられるセッション設定を記述した SDP メッセージが含まれる。この設定は Bruce の INVITE メッセージに含まれるセッション設定を加味した上で決定される。こうすることで、両参加者はメディアのやり取りを始める前に互いに受け入れ可能なセッション設定に合意できる。

もう一つの説明していない話題に、Larry が通話に用いるデバイスの特定方法がある。セッションを確立するとき、メッセージを送信・転送するマシンがどのように宛先マシンの IP アドレスを知るかを順に見ていこう。まず、Bruce のコンピューターは cisco.com のプロキシに INVITE メッセージを送信する。プロキシの IP アドレスは Bruce のコンピューターに手動で設定することもできるし、DHCP で学習することもできる。その後 cisco.com のプロキシは princeton.edu のプロキシを特定する。これはドメインが持つ SIP プロキシの IP アドレスを取得する特殊な DNS ルックアップで行える (DNS は次節で解説する)。最後に、princeton.edu のプロキシは Larry が通話を受け取ることができるデバイスを見つける必要がある。通常プロキシは位置情報 (ロケーション) データベースへのアクセスを持つ。このデータベースに手動で情報を設定することもできるものの、SIP の登録 (registration) 機能を使うとさらに柔軟な設定が行える。

ユーザーは自身が属するドメインの SIP レジストラ (registrar, 登録管理者) に SIP の REGISTER メッセージを送信することで自身を位置情報サービスに登録できる。REGISTER メッセージは「レコードのアドレス」と「連絡先アドレス」の関連付けを作成する。典型的に「レコードのアドレス」はユーザーに対する広く知られたアドレスである SIP URI (例えば sip:larry@princeton.edu) を表し、「連絡先アドレス」は現在ユーザーを見つけられるアドレス (例えば sip:larry@llp-ph.cs.princeton.edu) を表す。これは上述の例で princeton.edu のプロキシがまさに必要とする情報である。

単一のユーザーが複数の位置情報を登録することも、複数のユーザーが単一の位置情報を登録することもできる。後者の例として、IP 電話機が備え付けられている会議室を複数人が利用する状況が考えられる。備え付けの IP 電話で通話を受け取ることを望む参加者は、会議室の IP 電話を位置情報に登録することになる。

SIP は複雑な通話シナリオを幅広くサポートする非常に高機能かつ柔軟なプロトコルであり、電話とほとんどあるいは全く関係のないアプリケーションでも利用されている。例えば、SIP は「保留中」の音楽を再生するサーバー (ボイスメールサーバー) に通話を転送する機能を持つ。SIP をインスタントメッセージングに利用できることも簡単に想像できるだろう。実際、そういった用途向けの SIP 拡張の標準化が進んでいる。

H.323

ITU (The International Telecommunication Union, 国際電気通信連合) も通話制御の分野に対して非常に活発に関与してきた。この団体が電話の規格に関連する活動を長く行ってきた事実を考えれば不思議なことではない。幸い、この分野で IETF と ITU は密接に連携しており、様々なプロトコルがある程度の相互運用性を持っている。パケットネットワーク上のマルチメディア通信に関する主要な ITU 勧告は H.323 と呼ばれる。H.323 は様々な勧告をまとめたものであり、その中には通話制御に関する勧告 H.225 も含まれる。H.323 に含まれる全ての勧告をまとめると数百ページになり、そのプロトコルは非常に複雑なことで知られている。そのため本書では簡単な外観だけを示す。

H.323 は映像通話を含むインターネット電話に関するプロトコルとして広く知られている。ここではそういった種類のアプリケーションを議論する。通話を開始あるいは終了するデバイスは H.323 ターミナル (H.323 terminal) と呼ばれる。H.323 ターミナルはインターネット電話アプリケーションを実行するワークステーションかもしれないし、特別に設計された「装置」 ── ネットワーク処理を行うソフトウェアとイーサネットポートを持つ電話の形をしたデバイス ── かもしれない。

H.323 ターミナルは互いに直接データをやり取りできるものの、多くの場合で通話はゲートキーパー (gatekeeper) と呼ばれるデバイスによって中継される。ゲートキーパーは電話の発信で使われる様々なアドレスフォーマット間の変換や、一つの H.323 アプリケーションが同時に行える通話の個数の制御を通した帯域の制限などの処理を行う。

H.323 にはゲートウェイ (gateway) という概念も存在する。ゲートウェイは H.323 ネットワークを PSTN (public switched telephone network, 公衆交換電話網) に接続するために使われることが最も多い (図 225)。こうすると H.323 アプリケーションを実行するユーザーと PSTN に接続された従来の電話を使うユーザーの通話が可能になる。ゲートキーパーが行う有用な処理の一つに、ゲートウェイを検索して H.323 ターミナルに教える処理がある。このときゲートキーパーがゲートウェイの候補をいくつか伝え、H.323 ターミナルはその中で通話先に近いものを利用するといったこともできる。これは従来の電話が PC ベースの電話より圧倒的に多い現実世界で明らかに重要となる。H.323 ターミナルが従来の電話と通話するとき、H.323 通話における事実上のエンドポイントはゲートウェイとなり、ゲートウェイが電話網を流れるシグナリング (セッション制御) 情報やメディアストリームの変換を行う。

H.323 の重要な要素として、上述した SDP のように通話設定の交渉で使われる H.245 プロトコルがある。H.245 メッセージには例えば発信側がサポートする音声コーデックの一覧などが含まれる。このメッセージを受け取った相手のエンドポイントは自身がサポートする音声コーデックの一覧を返答し、最終的に両者がサポートする音声コーデックが選択される。また、H.245 は RTP と RTCP (Real-Time Control Protocol) でメディアストリームを伝達するときに利用される UDP のポート番号を伝えるときにも利用される。通話設定の伝達と交渉が終了すると通話が開始され、RTP がメディアストリームを、RTCP が制御情報をそれぞれ伝達する。

9.2.2 リソース割り当て

これまで見てきたように、マルチメディアアプリケーションにおける通信の開始・制御では SIP や H.323 といったセッション制御プロトコルが利用され、実際のデータストリームに対するトランスポート層レベルの機能は RTP が提供する。マルチメディアアプリケーションを動作させるための最後のピースとして、ネットワークリソースの適切な割り当てが必要になる。十分なリソースが割り当てられなければ、アプリケーションはサービスの質を保証できない。リソース割り当てに関しては第 6 章で多くの手法を紹介した。そういった手法は主にマルチメディアアプリケーションのサポートを目標として開発されていた。では、ネットワークが持つリソース割り当て機能をアプリケーションはどのように活用するのだろうか？

多くのマルチメディアアプリケーションは「ベストエフォート」のネットワークでも問題なく実行できる事実は指摘しておくべきだろう。様々な商用 VoIP サービス (例えば Skype) が存在することは、リソース割り当ての問題はリソースが少ないときにだけ考えれば十分であることの証左と言える ── 現在のインターネットでは、リソースが余りあるほど用意されている場合が多い。

RTCP などのプロトコルがあるとネットワークが実際に提供するサービスの質に関する詳細な情報がアプリケーションに提供されるので、こういったプロトコルはベストエフォートネットワークを利用するアプリケーションでも役立つ。RTCP はマルチメディアのやり取りにおけるロスレートや遅延特性といった情報を伝達することを思い出してほしい。この情報を受け取ったアプリケーションは、例えば帯域が枯渇しているなら符号化方式をビットレートが低いものへと変更するといった対応が行える。なお、ロスレートが高いときに符号化方式を冗長な情報を追加で送信するものに変更したくなるかもしれないが、これは行ってはいけない。この対処はロスが発生しているときに TCP のウィンドウサイズを広げるのに等しく、輻輳崩壊を避けるためにすべき処置の真逆のことを行ってしまう。

第 6.5 節で説明したように、DiffServ (Differentiated Services) は非常に基本的でスケーラブルなリソース割り当てをアプリケーションに提供するために利用できる。マルチメディアアプリケーションは送信する IP パケットのヘッダーに DSCP (Differentiated Services Code Point) を設定することで、メディアパケットと制御パケットに対する適切なクオリティオブサービスを要請できる。例えば音声メディアパケットでは DSCP を「EF」(expedited forwarding, 完全優先転送) に設定して経路上のルーターでパケットが低レイテンシ (優先) キューに配置されるようにする場合が多く、SIP パケットなどのシグナリング (セッション制御) パケットでは DSCP を「AF」(assured forwarding, 相対的優先転送) に設定することでベストエフォートのトラフィックとは異なるキューにパケットが配置されるようにしてパケットロスの可能性を低減させる場合が多い。

もちろん、ルーターをはじめとしたネットワーク機器が DSCP に注意を払わないなら、送信側のホストや機器がパケットに DSCP の値を設定する意味はない。一般に、公共インターネット内のルーターは DSCP を無視して全てのパケットにベストエフォートサービスを提供する。しかし、エンタープライズ (企業) のネットワークでは組織内のマルチメディアトラフィックに対して DiffServ を有効にでき、たいていは有効にされる。また、たとえ家庭用回線しか持たないユーザーであっても、外向きインターネット接続で DiffServ を使うだけで VoIP などのマルチメディアアプリケーションの質が向上することがよくある (図 226)。この現象は多くのブロードバンドインターネット接続が持つ非対称性によって発生する。典型的なユーザーの外向きリンクは内向きリンクと比べて圧倒的に遅い (リソースが制約されている) ので、その外向きリンクで DiffServ を使ったリソース割り当てを行った結果としてレイテンシとロスに敏感なアプリケーションの質が体感できるほど改善されたとしても不思議ではない。

図 226.

VoIP アプリケーションに適用された DiffServ; 顧客ルーターから ISP へ向かう上流リンクでのみ DiffServ キューイングが用いられる

DiffServ は魅力的な単純性を持つものの、あらゆるアプリケーションのあらゆる場面における需要を満たすことはできないのは明らかである。例えば図 226 における上流帯域がわずか 100 Kbps で、顧客が 64 Kbps コーデックを利用する VoIP 通話を二つ起動したとしよう。このとき上流リンクの負荷は 100% 以上となり、大きなキューイング遅延やパケットロスが発生する。どれだけ賢いキューイングを顧客のルーターで行ったとしても、この事実は変わらない。

多くのマルチメディアアプリケーションは「パイプが狭いとき、たくさんの通話を押し込むのではなく、一つの通話をパイプに通して他はブロックした方がいい」という特徴を持つ。つまり、一人に通常通りの通話を提供しつつ他の人には「混雑中」の音声を聞かせる方が、全員に耐えられない音質の通話を提供するより望ましい (ここで「通話」は一般的なマルチメディアストリーミングを意味するので、映像の視聴などでも構わない)。こういったアプリケーションは「急な効用曲線 (steep utility curve) を持つ」と言われる: ネットワークが提供するサービスの質が低下すると、アプリケーションの効用 (ユーザーに提供される価値) が急激に低下する。この特徴はマルチメディアアプリケーションでよく見られるのに対して、多くの伝統的アプリケーションでは見られない。例えばメールを考えると、遅延がたとえ数時間になったとしてもユーザーに提供される価値が全く無くなるわけではない。

急な効用曲線を持つアプリケーションには何らかのアドミッション制御が適している場合が多い。アドミッション制御はネットワークのリソースがアプリケーションの負荷に耐えられるかどうか定かでないときに利用を拒否することで、現在ネットワークを利用中のアプリケーションが提供するサービスの質が低下するのを回避する。

第 6.5 節では RSVP を使ったアドミッション制御を説明した。RSVP については後述する。まずはマルチメディアアプリケーションにおけるアドミッション制御に複数の選択肢があることを説明する。重要な事実として、SIP や H.323 といったセッション制御プロトコルではセッション開始時に SIP プロキシや H.323 ゲートキーパーとのメッセージ交換が行われる。十分なリソースを用意できないセッションを拒否する便利な機会がここで提供される。

例として図 227 に示すネットワークを考えよう。支店と本店を接続するワイドエリアネットワークがあり、そのリンクの帯域は 64 Kbps コーデックを使った三つの VoIP 通話を同時に行えるとする。アドミッション制御が存在しない場合でも、それぞれの IP 電話はローカルの SIP プロキシまたは H.323 ゲートキーパーとの通信から通話を始める。そのため、リンクの空き帯域が足りないことを理由に「混雑中」の音声を再生するよう IP 電話に伝えるメッセージの送信は SIP プロキシまたは H.323 ゲートキーパーを使って簡単に行える。加えて、単一の IP 電話が複数の通話を行い、それぞれで異なるコーデックを使うケースにも対応できる。しかし、この方式はプロキシやゲートキーパーを経由せずにリンクに大きな負荷をかけるデバイスが存在しないときに限って上手く動作する。DiffServ キューイングを使えば、例えばファイル転送を行う PC が VoIP 通話に干渉しないことを保証できる。ただ、ゲートキーパーやプロキシと対話を行わずに通話を行う VoIP アプリケーションがリモートオフィスで実行されていることを想像してほしい。このとき、そういったアプリケーションがパケットに適切な DSCP を設定すると仮定すれば、その VoIP トラフィックは何の指示も受けず回線に大きな負荷をかけてしまう。

上述のアプローチが持つ別の問題として、各アプリケーションが利用する経路に関する知識がゲートキーパーとプロキシに必要とされる点がある。これは図 227 のような単純なトポロジーであれば問題ではないものの、複雑なネットワークではすぐに手に負えない問題となる。これを理解するにはリモートオフィスが外部との接続を二つ持っている状況を考えれば十分である。このとき、ゲートキーパーとプロキシは SIP と H.323 だけではなく、ルーティング、リンク障害、現在のネットワーク状況といった事項を理解しなければならない。これはすぐに手に負えない規模の問題となる。

こういった問題に手を出さないアドミッション制御はオフパス (off-path) と呼ばれる。これは、割り当て対象のリソースが通る経路上にアドミッション制御の判断を下すデバイスが存在しないことを意味する。逆に、割り当て対象のリソースが通る経路上に存在するデバイスが判断を下すアドミッション制御はオンパス (on-path) と呼ばれる。オンパスのアドミッション制御を行うプロトコルの標準的な例として RSVP (Resource Reservation Protocol) がある。第 6.5 節では RSVP を使って経路上に必要なリソースを確保する仕組みを解説した。さらに解説が必要な点として、アドミッション制御プロトコルとセッション制御プロトコルの対話がある。

図 228.

SIP によるセッション制御と RSVP によるアドミッション制御の連携; 実線が SIP メッセージを、破線が RSVP メッセージを表す。

アドミッション制御 (リソース予約) プロトコルとセッション制御プロトコルの連携は難しい問題ではないものの、注意が必要な点がいくつか存在する。例として、二つのデバイスの間で電話通話を行う単純なシナリオを考えよう。発信側はリソースを予約する前に、まず通話が使用する帯域を知る必要がある。使用する帯域はコーデックによって変わるので、これはセッション制御プロトコルでお互いのデバイスがサポートするコーデックに関する情報を交換する必要があることを意味する。しかし、アドミッション制御によって通話が拒否される可能性もあるため、アドミッション制御の判断を待ってから相手の「ベル」を鳴らさなければならない。よってサポートされるコーデックに関する情報を交換するときにセッション制御の処理を全て終わらせることはできない。図 228 に SIP によるセッション制御と RSVP によるアドミッション制御で交わされるメッセージの例を示す (この例では両方とも成功し、通話が開始される)。

図 228 では実線が SIP メッセージを、破線が RSVP メッセージを表す。セッション制御の処理とアドミッション制御の処理が互い違いになっていることに注目してほしい。また、この例で SIP メッセージは (間にある SIP プロキシを除けば) 電話から電話に転送されるのに対して、RSVP メッセージは経路上にある全てのルーターで処理され、通話を行うだけのリソースを用意できるかどうかがチェックされる。

最初の二つの SIP メッセージでコーデック情報の交換が行われる (こういったセッション制御に関する情報は SDP でやり取りされることを思い出してほしい)。その次の PRACK は provisional acknowledgment (暫定的確認応答) を意味する。これらのメッセージが交換されると、次にリソース予約の最初のステップとして必要とされるリソースが記述された RSVP の PATH メッセージが両方向に送信される。その後 RESV メッセージが送り返され、実際のリソース予約が行われる。RESV メッセージが返ってくると、リソースが片方向に予約された事実を伝える更新された SDP メッセージが送信される。二つの SDP メッセージと自身が送った RESV の返答を受け取った時点で、電話の受信側は応答可能な (必要なリソースが双方向に確保された) 電話がかかってきたことをユーザーに伝える「ベル」を鳴らすことができる。以降は図 224 と同じように SIP による通常のセッション制御とメディア制御が行われる。

以上の議論もまた、アプリケーションを構築するために異なる構成要素 (今の例では SIP と RSVP) 間の対話を理解しなければならない例と言える。なお、SIP は異なる処理を行うためにプロトコルを互い違いに利用する使い方を可能にするために過去に変更が加えられている。システムの「層」や「コンポーネント」を他の部分と切り離すのではなく、システム全体を見渡して問題に取り組むことに重点を置くという本書で繰り返し登場する考え方の背後にはこういった事例がある。