最近のIP電話では，着信や発信，保留，転送といった通話制御のためのプロトコルとしてSIP（Session Initiation Protocol）を使うのが当たり前になってきた。SIPはRFC3261として定義されたプロトコル。インターネット技術に関する標準化団体の一つであるIETF（Internet Engineering Task Force）によって仕様が公開されている国際規格である。SIPを利用するIP電話が「オープンな技術である」といわれる根拠はここにある。

SIPはぜんぜんオープンじゃない

　しかし，IT Proの読者ならご存じの通り，実際のIP電話はちっともオープンではない。異なるメーカーの機器やサービスの間には相互接続性が保証されない。とくにひどいのが，これまで企業の内線電話で使われていたPBX（構内交換機）を，IP電話に置き換えるために使われる企業向けSIPサーバーの状況だ。

　NECも富士通も日立製作所も沖電気もみんなRFC3261準拠をうたうSIPサーバーを販売しているが，接続を保証するのは自社製か，自社で認定したIP電話機だけ。NECのIP電話機は，富士通や日立や沖電気のSIPサーバーでは使えない。SIPサーバーのベンダーがどこであろうと，ユーザーが好みのIP電話機やソフトフォンと組み合わせて使えるという「オープン」な世界はそこにない。

　こういう状況になっている理由の一つはRFC3261のあいまいさにある。RFC3261はもともと電話の通信制御だけを目的に作られていないうえ，策定したのは海外の技術者。発信や着信くらいならよいが，日本企業の利用事情に合わせた内線電話システムのように，応用的な使い方が増えると問題が出てくる。

　一例を挙げよう。日本の企業ではこんなシーンがよく見られる。部門に外線が掛かって来る。手の空いている誰かがピックアップする。用件を聞いたらいったん保留して「○○さ～ん，3番に電話ですよ～」と声をかける。声をかけられた当人は，電話機のボタンを押して保留を解除し，通話を始める。「お電話替わりました○○です」――。実は，このような使い方が可能なIP電話システムを，RFC3261の規定だけで実現するにはかなり工夫がいる。

　企業向けの電話機には通常，番号ボタンや保留ボタンのほかに，回線を選択するためのランプ付きボタンが並んでいる。ライン・ボタンと呼ばれ，例に挙げたような状況で保留された着信をピックアップするために使う。着信が保留されている場合，このボタンのどれか（先ほどの会話なら3番）のランプをチカチカさせて知らせたりする。

　RFC3261にはライン・ボタンやそのランプをどう制御するかの厳密な規定がない。そもそもライン・ボタンが付いた電話機を想定していないからだ。そのため，国内のSIPサーバー・ベンダーはいくつか考えられる方法から一つを選び，独自に「ほんの少しだけ」拡張して，ランプがチカチカ光るようにしている。方法は自社で勝手に決める。競合他社とはもちろん相談しないから，同じような機能でも実装は少しずつ異なることになる。

　これまで企業向け電話システムで使われてきたPBXにはこうした日本企業向けの機能がたくさんある。SIPサーバー・ベンダーの多くはPBXベンダーでもある。ユーザーの要望に応え，製品に競争力を付けるために，自社のPBXが持っていた独自機能をIP電話に移植する。こうしてSIPサーバーやIP電話機は，実現している機能はさほど違わないのに，他社製品とは相互接続できない仕様になっていく。複数のベンダーやサービス事業者にIP電話機を供給しているメーカーによると，その違いは「供給先ごとにファームウエアごと入れ替える」ほど大きいらしい。

　つまり，ユーザー・ニーズに応えるための努力が結果的に，製品間の相互接続性を失わせている。他社と異なる実装は「ユーザー囲い込みの手段である」という見方もある。確かにそうした側面はあるだろうが，仮にそんな意図がなくても，相互接続性を保つのが難しい状況なのもまた事実なのだ。

独自仕様を国際規格にしてしまえ

　問題の核心はRFC3261の不足を補う明確なガイドラインがないこと。日本企業のビジネス慣習に適合したIP電話向けに，RFC3261を補足・拡張する規格や公開仕様があれば，今のような状況にはならなかったハズ。ならば，今からでも作るべきではないだろうか。

　といっても，話し合って決めるのではたぶん時間が掛かりすぎる。そうではなくて，どこかのSIPベンダーが自社の製品仕様をInternet-Draftとして公開するのが手っ取り早いと思う。Internet-DraftはIETFに対して仕様のRFC化を提案するドキュメント。誰でも投稿でき，一定期間IETFによって公開される。有用だと認められれば，正規のRFCに昇格する可能性がある。

　ベンダー1社の独自仕様でもRFC化されるチャンスはある。実際，「Informational」というカテゴリーに属するRFCには独自仕様が多い。例えば，マイクロソフトが拡張したパスワード認証の方式「MS-CHAP」は，RFC2433として公開されているが，Informationalである。

　もしRFCとして公開できれば，今後，日本市場を狙って新規参入するIP電話機メーカーがこの仕様に準拠した製品を作る可能性は高い。製品が日本市場で実績のあるSIPサーバーにつながった方がいいからだ。新たにSIPサーバーを開発するベンダーも，仕様を参考にするだろう。接続できるIP電話機の種類は多い方がいいからだ。こうした流れが広がっていけば，いずれこの仕様が，ビジネス向けIP電話のデファクト・スタンダードになり，IP電話をオープン化するかもしれない。

　国内のSIPサーバーの開発者のみなさん，どうですか？ RFC化はなかなか遠い道のりかもしれないけど，その第一歩となるInternet-Draftなら誰でも投稿できます。あなたが苦労して開発した仕様で，世界を制覇する夢を見るのも悪くないと思いますよ。

（山田　剛良＝日経コンピュータ）