ここからは,実際にSIPがどのように使われているかを見ていこう。SIPを使った典型的なサービスや機能を5個ほど取り上げて,裏でSIPがこなしている仕事を説き明かす。ここを読むことで,SIPが持つ可能性が実感できるだろう。

IPテレビ電話サービス
利用可能なメディアを伝える

 最初に取り上げるのは,FTTH*1の普及などによりユーザーが増えつつある「IPテレビ電話サービス」である。NTT東日本が提供しているFLET'S.Netナンバー(FdNナンバー)サービスを例に,しくみをのぞいてみよう。

やりとりはIP電話と同じ

 IPテレビ電話サービスでは,自分と通話相手との間で映像と音声という2種類のデータをリアルタイムにやりとりする。このしくみを実現するために,SIP UA同士はどのようなSIPメッセージをやりとりしているのだろうか。

 実は「SIPの基本的なやりとりは,一般的なIP電話サービスとまったく同じ」(NTT東日本の秦泉寺浩史・端末開発担当部長)だったりする。要するに,相手と通話する手順は,図1-5で見たIP電話の手順と同じなのだ。最初にINVITEリクエストを送るところから,BYEバイリクエストを送って通話を終えるまでの手順は何一つ変わらない。

 IP電話のケースと違うのは,相手を呼び出すINVITEリクエストの中身である。IP電話の場合,「このデータ形式の音声を使って通信を始めましょう」と招待する。一方,IPテレビ電話では,「このデータ形式の音声と,このデータ形式の映像を使って通信を始めましょう」と相手に呼びかけるのだ。

 具体的には,INVITEリクエストのボディ部分に,やりとりしたい音声データの情報と映像データの情報をSDPの書式でまとめて書き込む(図2-1)。

図2-1●SIPを使ったIPテレビ電話サービスの例
図2-1●SIPを使ったIPテレビ電話サービスの例
NTT東日本が提供している「FLET’S.Netナンバー」の例を示した。基本的なやりとりはIP電話と同じ。違うのは相手との間で利用する映像の符号化方式の情報をやりとりすることだ。
[画像のクリックで拡大表示]

 これを受け取った相手側のSIP UAは,呼び出し元SIP UAによって指定された音声と映像のデータ形式が自分も利用可能なら,送信元に対してその旨を返答する。こうして無事打ち合わせが済んだら,あとはSIP UA同士がそれぞれ音声と映像用のポートを開けて*2,通信を始める。

転送
INVITEリクエストを5回出す

 オフィスにある多機能電話にはさまざまな機能が備わっている。例えば通話の保留や転送,パーク保留とコール・ピックアップ*3といった機能である。ここでは,その代表的な機能の一つである通話の転送を見てみよう。

「通話して保留」を繰り返す

 ユーザーAからかかってきた電話をユーザーBが取り,これをユーザーCに転送するケースを考えよう。

 通話を転送する方法は二つある。一つは,転送元であるユーザーBが転送先のユーザーCと会話をしないで転送するやり方。こちらを専門用語で「セカンダリ・コールなし」という。

 一方,転送元であるユーザーBがいったんユーザーCに電話をかけて話をしたあと,ユーザーAからの電話を転送するやり方もある。こちらの方法は「セカンダリ・コールあり」と呼ばれる。ここでは,より一般的なセカンダリ・コールありのケースを見ていく。

 二つのSIP UA間で通話するケースと比べて,通話の転送は三つのSIP UAが関係するのでやりとりが少し複雑になる。ただ,どんなに手順が増えても,どちらか一方のSIP UAがリクエストを投げ,これに対して相手がレスポンスを返す基本は同じ。転送を指示するためにREFERリファーメソッドを使う点と,通話開始を呼びかけるためではなく保留するためにもINVITEメソッドを使う点がポイントだ(図2-2)。

図2-1●内線電話の転送サービスのしくみ
図2-2●内線電話の転送サービスのしくみ
着信した電話をほかの人に転送する機能は,内線電話には必須。転送サービスの実現方法はいくつかあるが,ここでは転送元と転送先の2者が通話をしてから転送する「セカンダリ・コールあり」の例を示した。INVITEリクエストは合計5回やりとりされる。
[画像のクリックで拡大表示]

 REFERメソッドは,RFC3261で定義する6個の基本メソッドには含まれない拡張メソッドである*4。転送元のユーザーBは,このREFERメソッドと,実際の転送先を伝えるヘッダー中のRefer-to:フィールドを使って,ユーザーCに電話をかけるように指示する。この指示に対してユーザーAは,NOTIFYノーティファイメソッドという拡張メソッドを使って処理状態を通知する。

 もう一つのINVITEメソッドを使った保留は,通常の通話を始めるためのINVITEリクエストとちょっと違っている。具体的には,ボディ部分に格納する音声のデータ形式のパラメータとして,「a=sendonly(センドオンリー)」あるいは「a=inactive(インアクティブ)」という値を追加する。

 これで,保留元から保留先に対して保留音を音声データとして流す(sendonly)か,保留音を流さず保留先の端末がローカルで保留音を作り出すか(inactive)を指示する。