ネットワンシステムズ NWテクノロジー本部 事業推進部 ネットワークアプリケーションチーム 山本 祐樹 ネットワンシステムズ
NWテクノロジー本部
事業推進部
ネットワークアプリケーションチーム
山本 祐樹

IP電話を活用するには、アプリケーションとの連携が重要である。IP電話システムにはそのためのAPIなどが用意されている。しかし、いざ実際に開発を始めてみると、さまざまな問題が発生した。「開発できる業者がいない」「部署単位で電話機がフリーズ」「顔写真の掲載は･･･」。社内からの冷たい視線が突き刺さった。

　IP電話の利点の1つに挙げられるのが連携アプリケーションの活用である。もともとIPはデータ通信のための技術であるから、コンピュータとの親和性は高い。IP電話とコンピュータの連携は当然の流れともいえる。

　すでに各ベンダーが人事システムやCRM（顧客情報管理）システムとIP電話を連携させるアプリケーションを提供している。実際、IP電話を導入するユーザー企業のほとんどが何らかのアプリケーションの導入を検討しているようである。

　ネットワンシステムズでもIP電話連携アプリケーション「Collaboaxl（コラボアクセル）」というアプリケーションを開発した。「Calling System」「Casting System」「Reception System」の3つの要素で構成される（図1）。ネットワンシステムズではシスコのIP電話ソリューションを取り扱っており、このプラットフォーム上でアプリケーションを開発した。

図1●Collboaxl
図1●Collboaxl

　このCollaboaxlの開発の取りまとめを筆者が担当した。完成させるまでにさまざまな苦労、失敗があった。技術面はもちろん、利用方法などで思わぬ事態が発生した。

開発できる業者がいない

　ネットワンシステムズの中核をなすビジネスは、ネットワーク・インフラの構築である。アプリケーション開発に使えるリソースがふんだんにあるわけではない。そこで、ネットワンが技術とプロジェクトを統括し、実際の開発作業を協力会社に任せるという態勢でアプリケーション開発を進めることになった。

　ところが、その協力会社がなかなか見つからない。日本にアプリケーション開発を請け負う業者は山ほどあれど、シスコの「IP Phone」のわかる業者は数えるほど。TAPI/JTAPIを扱える業者は、少しはあるものの、シスコのTAPI/JTAPIとなると皆無。それもそのはず、シスコではプッシュ機能などの独自機能を実現するためにTAPI/JTAPIを改造している。いかんせんシスコのIP電話は日本でそれほどメジャーではなかったため、この独自のTAPI/JTAPIを理解している業者はほとんどいない（シスコ IP Phoneのアプリケーション連携の仕組み）。

　とはいえ、IP電話とアプリの連携は重要である。あきらめるわけにはいかない。千里の道も一歩から。これまで付き合いのあった開発パートナーに、シスコのIP電話についてゼロからレクチャーした。基礎、設定方法、アプリケーション開発に必要なTAPI/JTAPIやシスコ独自の機能について説明した。

　なんとか態勢が整い、実際の開発が始まった。アプリケーションの機能仕様の策定から、設計まで連日連夜の作業とミーティングが続いた。設計が終わり開発作業に入った。ここまでは作業の負荷は非常に大きかったが順調に進み、大したトラブルはなかった。このまま順調にプロジェクトが完了すればいいと考えていたが･･･。世の中甘くはなかった。やっぱりいろいろなトラブルが発生した。

ほかのセグメントの電話から音が出ない

　開発環境で一通りテストしたが、実環境では動作しないことがいくつかあった。たとえばCasting Systemには、アプリケーション・サーバーに登録したWAVファイルをIP電話機に配信するという機能がある。指定した時間にそのWAVファイルがIP電話機に配信、再生されます。開発環境では動作に問題はなかったが、なぜか実環境では動作しない。IP電話機から音が出ないのである。

　Casting Systemでは、部署などグループに属するIP電話機すべてに配信するマルチキャストと特定の1台に配信するユニキャストの2種類のモードを用意している。ユニキャストでは音が出たので、すぐにマルチキャストがらみのトラブルだろうという見当はついた。

　ネットワーク機器の設定を見直したが間違いはない。次にパケットをキャプチャしてみた。すると、答えがあっさり見つかった。アプリケーション・サーバーからのマルチキャスト・パケットのTTL（Time to Live）が1になっていた。

　TTLはIPパケットの有効期間を示すパラメータである。ルーターを経由するたびに1を引き、0になった時点でそのパケットを廃棄する。TTL＝1ということは、セグメントを越えられない（図2）。つまり、到達できるのは同一セグメント内のみということを意味する。

図2●ルーターを越える際にTTLが「1」減少し「0」となりパケットが廃棄される
図2●ルーターを越える際にTTLが「1」減少し「0」となりパケットが廃棄される

　確かに、開発環境はアプリケーション・サーバーも呼制御サーバーもIP電話機もすべて同一セグメント上で動かしていた。開発環境では発生しない問題である。早速、パケット送出時のTTL値を調整して、実環境でも正常にCasting Systemが動作するようになった。「TTLのケアもできてなかったのか、このド素人！」と社内で叱責されたが、へこたれている暇はなかった。次々に発生するトラブルに対応しなくてはならなかったから。

　実環境というのは、ネットワンの社内のIP電話環境である。端末数は1000を超えるくらいで、多過ぎず少な過ぎず実際のユーザー企業に見立てるにはよい環境といえる。社内なので多少のトラブルは大目に見てくれるという期待もある。