【トレンド解説】

マイクロソフトがIP電話を面白くする!?
〜いま注目を集める「SIP」の最新トレンドと概要〜

鈴木淳也
2003/5/21

企業内の電話回線とIP網を統合するVoIP（Voice over IP）で用いられるプロトコル、SIP（Session Initiation Protocol）。今年のキーワードの1つ、「ＩＰ電話」や「IP-Centrex」の基盤となる、音声や画像などのマルチメディア情報をやりとりさせるためのテクノロジである。 本文で紹介するマイクロソフトの音声データを中継する新製品サーバにはすでに採用されており、国内のキャリアやベンダでも今年7月のVoIPの新サービスをスタートに向けてSIPの標準化が進めているという。ここでは、SIPの基本的な仕組みを解説したい。

　いま、ネットワークの世界で最も注目の技術は何だろうか？ 前回「無線LANブームで注目を集めるメッシュネットワーク」でレポートしたように、無線LANはその最有力候補だろう。チップセットへの標準搭載を果たし、長距離無線LAN規格の策定や、セキュリティ規格WEPの後継ともいえるIEEE 802.11iのサブセットである「WPA（Wi-Fi Protected Access）」対応の製品の出荷など、ここしばらくトレンドを引っ張るだけの話題が満載だ。各ベンダやインテグレータ、さらには周辺業界なども巻き込み、真剣にビジネスの可能性を模索しつつあり、目が離せない。

　そして私が次に注目するのが、今回のテーマである「SIP（Session Initiation Protocol）」だ。SIPは、VoIPなどの音声通信のIP化で用いられるプロトコルである。だがSIP自体は1990年代半ばごろから標準化が進められており、すでに対応機器やソフトウェアも登場している。ではなぜ、いまSIPなのか？ それは、最近になりSIP普及に向けた動きが活発化してきたからだ。特に注目なのがマイクロソフトである。

　同社は4月9日に、「マイクロソフトが“Greenwich”の正式名称を『Microsoft Real-Time Communications Server 2003』に決定」という形でSIP対応製品を発表している。Microsoft Real-Time Communications Server 2003（以下、RTC）とは、Microsoft Messengerクライアントを束ねて、インスタント・メッセージングや音声データなどの中継を行うサーバ製品である。この仕組みの実現にはSIPが使われており、同社はRTC発表に際して、業界を挙げてSIPを盛り上げていこうとしているからだ。

　今回は、このSIP周辺の最新事情や、その基本的な仕組みについてまとめていこう。

■SIPだけではない通話プロトコル

　一般の加入電話網であるPSTN（Public Switched Telephone Network：公衆交換電話網）では、電話局の交換機や企業などに設置されているPBXが電話回線の交換を行っている。電話番号や内線番号をダイヤルして相手先に接続し、通話できるのはこの交換機のおかげだ。だがこの加入電話システムでは、1通話回線につき回線上のある一定帯域を占有してしまうため、一般にコストが高くなってしまう。そこで、いまある企業のネットワーク網に音声データを載せて、電話／コンピュータと2系統あるネットワークを統合し、さらにネットワークの使用効率をアップさせることでコスト削減を狙うのが、VoIP（Voice over IP）の考え方である。

　企業のIPネットワークに音声データを載せるということは、データは当然パケット単位に分割され、ルータを経由することになる。IPネットワークの特徴は、どんなに遠距離でも通信可能なことと、ネットワークの使用効率が高いことだが、その分、2点間の距離が離れていたり、ネットワークが混み合っている（「輻輳」という）と、遅延の発生やパケットロスの可能性が出てくる。これは品質が重視される音声通話では致命的な問題で、ある意味、非常に相性が悪い組み合わせともいえる。そのため、VoIPを実現するには通常のTCP/IPに加え、音声データをハンドリングするための特別なプロトコルセットを利用する必要があるのだ。

　この音声データ制御のためのプロトコルとして代表的なものには、「H.323」と今回の主役である「SIP」の2種類がある。その目的は共通で、音声やマルチメディア・データ（ビデオ映像など）を取り扱い、それらのアプリケーションをサポートすることだ。H.323はITU-Tによって標準化され、SIPはIETFによってRFC化が行われている。両者の違いは、H.323がさまざまな規約を包含することで比較的重い仕様になっているのに対し、SIPはシンプルなことだ。またSIPは、HTTP 1.1ライクなメッセージ・フォーマットを採用していて、これまでTCP/IPでアプリケーション開発を行っていた人には、とっつきやすいという点でもメリットがある。

■SIPの基本用語と構成要素

　SIPで意外と誤解されがちなのが、その機能だ。SIP自体は、「セッションの開始／変更／終了」の基本的な機能のみしか提供しない。後は、セッション間の通信を安全に行うための暗号化機能である。これには、HTTPと同様にSSL／TLSが用いられる。VoIPで重要な帯域制御やマルチメディア・データのハンドリングなどの機能は、SIPでは標準で提供されない。SIPの利用に当たっては、下記のプロトコルなどと併せて使用することが前提となる。

• RTP（Real-time Transport Protocol）：QoS制御
• RTSP（Real-Time Streaming Protocol）：ストリーミングメディアの制御
• MEGACO（MEdia GAteway COntrol）：PSTNへのゲートウェイの制御
• SDP（Session Description Protocol）：マルチメディア・セッションの制御

　SIPでは基本的なセッション制御のみにフォーカスし、ほかのプロトコルでその機能を補う。SIPがシンプルで拡張性が高いのも、このようなプロトコル形態を取っているためである。

　次に、SIPの基本用語と構成要素について見ていこう。SIPでは、ユーザー・エージェントとサーバの2つの構成要素に分割することができる。その対応は次のようになっている。

●ユーザー・エージェント（UA）
　ユーザー・エージェント（UA）とは、一般にはIP電話端末やWindows MessengerなどのPC上の通信ソフトウェアのことである。だがその実態は、リクエストに応じて作成される論理的なプロセスのことを指している。UAには、クライアント（UAC）とサーバ（UAS）の2種類があるが、リクエスト送受信のどちら側になるかでUAC／UASになるかが決まるため、同じUAソフトウェア内に両方が混在する可能性がある。また後述のプロキシ・サーバにおいても、リクエストの代理応答を行う関係で、UASばかりでなくUACも動作することになる。

ユーザー・エージェント・クライアント（UAC） リクエストの送信を行うUA ユーザー・エージェント・サーバ（UAS） リクエストへの応答を行うUA

表1　SIPの構成要素（PC上の通信ソフトウェア）

●SIPサーバ
　基本となるのはプロキシ・サーバで、ユーザーのドメインごとに配置され、ネットワークにおける案内人、いわゆるDNSサーバのような役割を果たす。UACからのリクエストはいったんプロキシ・サーバに送られ、別のプロキシ・サーバやUAS（この場合は通信先のクライアント）に対してリクエストを転送する。それに対してリダイレクト・サーバでは、リクエストの中継は行わず、通信先の現在地の情報を返送し、UACに対して再アクセスを促す。登録サーバは、UACからのREGISTERリクエスト、つまり現在地などの登録情報を受け付けるサーバだ。3つのサーバ機能は、1つのサーバ内で同時に動かしても構わないし、別々のサーバに配置することも可能である。

プロキシ・サーバ （Proxy Server） UACからのリクエストを、次のサーバまたはUASに転送する リダイレクト・サーバ （Redirect Server） UACからのリクエストに対し、通信先の現在のアドレスを返答する 登録サーバ （Registrar） UACから、現在の位置を登録するREGISTERリクエストを受け取る

表2　SIPサーバを構成する3つのサーバ機能

　では、実際にこれらUAやSIPサーバがどのように協調してシステムとして動作するかを見ていこう。

■SIPの基本的な仕組み

　SIPの基本動作は非常にシンプルだ。イメージ的には、SMTPが電子メールを中継する様子に近いかもしれない。図1を参照してほしい。

図1　プロキシ・サーバを介したSIP通信

　クライアントAは、SIP対応のIP電話機である。ここで、通信先となるクライアントBを呼び出したいとする。相手先の指定は、SIP-URI（Uniform Resource Identifiers）と呼ばれる下記のようなアドレス表記で指定を行う。

sip:client-b@domain.com

　アドレス指定の最初の「sip:」の部分はプロトコルを指定するもので、暗号化が行われる場合には「sips:」という表記になる。後はおなじみのメール・アドレスの表記に近いことが分かるだろう。「@」より後ろの「domain.com」がドメインで、「client-b」が通信先ユーザーのIDである。

　図2をご覧いただきたい。クライアントAは、クライアントBを呼び出す際に、まず自身のドメイン「california.com」内にあるプロキシ・サーバAに対してINVITEリクエストを発行し、セッションの確立を促す。クライアントAがドメイン内のサーバがプロキシ・サーバAであることを認識するには、直接サーバ名を指定するか、DHCPなどによってあらかじめ通知しておけばいい。リクエストを受け取ったプロキシ・サーバAは、ステータスとして100（Trying：現在リクエストを転送中）をクライアントAに返答し、目的地であるドメイン「domain.com」内のプロキシ・サーバBに対してINVITEリクエストを行う。

図2　SIPの通信手順

　INVITEリクエストを受け取ったプロキシ・サーバBは、もし通信先のユーザーIDが存在する場合、さらにクライアントBに対してINVITEリクエストの転送を試みる。その際には、先ほどと同様にプロキシ・サーバAに対してステータス100を返答する。プロキシ・サーバを中継して到達したINVITEリクエストは、ここで初めてクライアントBに到達することになる。ここでクライアントBは、自身が呼ばれていることを利用者に対して通知し（多くの場合は呼び出し音やPC上でのポップアップなど）、その状態をステータス180（Ringing）としてクライアントAに対して通知する。

　またここでクライアントBの利用者が呼び出しに応じれば、ステータス200（OK）がクライアントAに対して返送され、次にSDPセッションのネゴシエーションが開始される。SDPはSIPと協調して動作する、マルチメディア・セッションのハンドリングを行うプロトコルだ。以上が、SIPによるセッション確立の概略だ。

■SIPサーバがなぜ重要なのか

　SIPの特徴として、周辺プロトコルのサポートにより音声やビデオ、テキストなどの幅広いマルチメディア・データをサポートすることが挙げられる。冒頭でマイクロソフトのRTCの話をしたが、MSN／Windows Messengerのような幅広いメディアに対応したインスタント・メッセージング・アプリケーションにとっては、まさに最適のプロトコルだということが分かるだろう。

　同アプリケーションは従来（NetMeetingのころ？）までH.323準拠だったが、バージョン4.63以降はSIP対応となった。だが、SIP動作の基盤となるSIPサーバ製品がほとんど存在しなかったため、事実上PtoP形式かマイクロソフトの.NET Passportサービスなどを利用するほかはなかった。なかには、LinuxなどでフリーのSIPサーバが提供されていることを利用して、自前でサーバ・アプリケーションを用意するパワー・ユーザーもいたかもしれない。だが、Messengerでこれだけクライアント・アプリケーションが普及しているのに対し、サーバ・アプリケーションの不在というのは、SIP普及に関していささかバランスが悪かったといえる。

画面1　Windows MessengerのオプションでRTCサービスを利用する設定を行うには、RTCサーバが必要になる

　マイクロソフトの今回のRTC発表は、この大量のクライアント配布で下地ができたところに、満を持してサーバ・アプリケーションを提供することで、SIP普及に弾みをつけることになるはずだ。マイクロソフトは今回、RTCの製品本体以外に、2つの関連製品も2003年の第3四半期にリリースするとしている。1つは、先日発表されたばかりのWindows Server 2003用のアドオンで、Windows Serverがクライアントのオンライン／オフライン／利用状態などのステータスを、リアルタイムで確認できるようになる。2つ目は、開発者向けのSDKで、音声通話アプリケーションの開発を可能にするものだ。SIPの特徴として、HTTP 1.1などに近いメッセージ・フォーマットを持つと説明したが、Webプログラミングに慣れた開発者にとってSIPは、意外ととっつきやすいものとなるだろう。

　企業ユーザーはRTCを利用することで、自前でWindows Messengerのインスタント・メッセージング環境を用意できるようになる。テキスト／音声／ビデオなど、この環境だけでもさまざまな種類のデータが扱えるのだ。だが、せっかくSIPの導入を行うのであれば、次のことも考慮に入れておくべきではないだろうか。

■SIPと内線／外線通信網との接続

　インスタント・メッセージングは、社員同士の連携を強めるという、コラボレーションウェアとしての性格が強い。だが、SIPを使って音声／データの混在環境を考えるなら、内線電話の統合による通信コスト削減も、その延長上にあることを覚えておくべきだ。

　SIPなどのプロトコルを使って内線／外線網を企業ネットワークに統合する際には、これまでのネットワーク構築とは少々異なるアイデアが必要になる。内線電話の適用範囲がギガビット・イーサネットなどの高速ネットワークで構築される社内LANなら問題ないが、もし支店や営業所などの遠距離拠点までも含めた統合を考えると、音声品質維持のために、遅延や利用帯域についてしっかりとした設計が求められる。

　まずはWANや複数のゲートウェイを経由することによる、遅延やパケットロスである。SIP自体は帯域制御機能を持たないため、ここでRTPやRTSPなどの力を借りることになる。最近では、IP-VPNや広域イーサネットなど、そのままIPパケットを流して高速に通信する広域ネットワーク・サービスの提供も始まっている。管理の大変だったフレーム・リレーやATMなどに比べても、導入のハードルは低くなってきたといえる。

　もう1つは外線部分だ。SIPの通信体系では、相手はドメイン、つまりIPアドレスで指定を行うため、E.164という規格に準拠した「03-1234-5678」といった電話番号とは直接通話できない。そこで、ENUMという方法を用いる。ENUMでは、上記のような電話番号とSIP-URIとのマッピングを行い、必要に応じて変換を行う仕組みである。SIPネットワークと外線に当たるPSTNの間には、PBXや専用のゲートウェイなどが設置されるが、ENUMを介することで異なる2つのネットワークを相互に接続できるようになる。

---

　このような形で、電話専用の通信回線の見直しや、PBXなどの交換機のリプレイスなどで、トータルなコストの削減を実現しようというのがVoIPの究極のゴールだ。もちろん、その効果は大企業であるほど出てくるだろう。

　まずは、社内情報システムの拡張としてSIPでインスタント・メッセージングから始めて、次に徐々にその範囲を拡大していく。企業のSIP採用とVoIP導入の動きは、今年後半から本格化するはずだ。

「Master of IP Network総合インデックス」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）