IP電話でQoSを確保するためのチェックポイント：VoIPに耐えるネットワーク構築（3）

» 2004年04月16日 00時00分公開

[延坂成人，ネットワンシステムズ]

　本連載「VoIPに耐えるネットワーク構築」では、第1回『IP電話導入のためのネットワーク必要条件』で、企業がIP電話を導入する際、自社のネットワークに最低限照らし合わせる必要のある条件を、第2回では『IP電話を使うなら知っておきたいパケット制御』の仕組みについて解説してきた。最終回の今回は、導入段階の試験運用のポイントについて解説する。

QoSの考え方

　QoSについて簡単にご説明したい。現在の多くの企業では100Mbit/sのLAN環境になっているだろう。現状一般的に使用されているアプリケーションであれば、特殊環境を除き、構内LANでQoSが必須となることはない。だが、拠点間接続部分、つまりWAN部分をLANと同等である100Mbsのような回線にすることは、ランニングコストが高くなり難しい。このため複数拠点間を結ぶWANの部分ではQoSは必要となってくる。

　では、LAN環境ではまったく不要なのかといえばそうでもなく、例えばウイルスなどが原因でネットワークリソースが圧迫された場合でも音声コミュニケーションを確保するというポリシーの下では必要だろう。セキュリティ側で対応している部分と思われるが、1つの考え方として紹介した。

　いずれにせよ、今後デスクトップビデオカンファレンスやビデオフォンが普及すれば、LAN環境でのQoSの必要性も高まるだろう。

実際の導入

　いままでは技術的な面に触れてきたが、これからは実際の導入に際して各仕様を決定していく段階から試験段階（評価）までの部分について解説していく。

　導入前検討段階での“既存運用コスト”（保守、リース、固定資産、通信費用、ファシリティコストなど）や“現状の問題点と要求事項”などには今回は触れないが、この部分が非常に重要であることを付け加えておく。

　導入に際しての大まかな主要アイテムは次のとおりである。

シグナリングと音声パケットの制御：目次

（1）　調査

　導入が決定された後、まず既存設備調査を行うことになる。回線・設備・端末というハード寄りの部分から、PBXが提供しているサービスにどのようなものが存在したのか、IPアドレスに該当する電話番号計画はどのようになっているのか、既存電話オペレーション（着信方式と保留転送など）がどのように行われているかを調査し把握する必要がある。

調査すべき既存設備項目

既存回線および電話番号調査（PBX収容、未収用回線とその使われ方）
接続端末種別
電話番号計画（トール網と構内）
既存サービス（電話、FAX、ボイスメール、交換台、ページングなど）
電話オペレーション

　特に重要なポイントを以下に挙げて説明したい。

１．既存回線および電話番号調査
　まず、IP化される音声網と既存電話網（PSTN）との接続には、いくつかの方式が存在する。

調査すべき既存設備項目

　従来同様、PSTN回線経由（GWへINS回線を収容）
　VoIPキャリア経由（IPセントレックスサービスへの加入）
　VoIPキャリア経由（自営IP-PBXとVoIPキャリア設備のUNI接続）

　現段階で最も多いのはGWへINS回線を収容して相互接続するタイプだが、各方式ともに現在使用している電話番号をそのまま移行、つまり同番号移行が完全にできるか、調査後すぐに確認しておく必要がある。同番号移行ができない場合もあるからだ。

２．接続端末種別
　FAX端末でG4規格の端末を保有しているユーザーの場合、G4をIPへ変換するGWは現在存在しないと思われる（あるかもしれないが）ので、どうしても必要な場合はINS網にダイレクト接続しなければならない。そのほか特殊端末などは収容の有無を確認するとともに、収容可能である場合にも事前検証を必ず行うことが大切である。

３．電話番号計画（トール網と構内）
　従来の電話番号計画では、0〜9、*、# を使用して内線番号、サービス特番（保留・不在転送ピックアップ等）、仮想番号などが必要であった。これらをIP電話にも適用するためには、従来と同じように各拠点で個別に決定する必要がある。また、そのほか拠点内で決定しなければいけないものとして、外線発信特番(通常“0”発信）、専用線特番（拠点間通信）がある。これらは拠点別ではなく社員がどの拠点にいっても共通使用される基本サービスに該当するために、特別な場合を除いて各拠点共通にアサインされる。

　ここまでが構内である拠点毎に決められた電話番号計画となる。さらに拠点間を結ぶ音声ネットワーク（トール網と呼ぶ）を持つユーザーの場合、各拠点を識別するための事業所番号が必要となる。公衆電話番号で言えば局番に当たるもので、内線番号は加入者番号に相当するものとなる。

　番号計画は従来の物理的ロケーションに依存した方式を採用するのか、それとも組織的に依存した方式（グループ会社識別コードや社員番号など）を採用するのかによって、運用を含めて変わってくる。規模が大きいユーザーであるほどVoIP網と既存電話網との共存期間が長くなり、ミスオペレーションなどの問題も予想されるので、移行なども含めて十分な検討を行う必要がある。

４．既存（電話）サービス
　すべてのサービスをそのままIPへ移行できるわけではない。移行できないサービスや移行できてもオペレーションや実現方法が異なる場合がある。こうした場合は実際のエンドユーザーに事前確認をしてもらう必要がある。

５．電話オペレーション
非常に重要である。ある意味アプリケーションそのものである“電話”がIP化されたことで操作性が損なわれてしまってはマイナスである。操作性が同一であることが一番望ましいのだが、異なった場合でも日本電話特有の機能である“グループ着信”“保留・ピックアップ”を「ワンタッチ」で操作でできるようにする機能の提供は必須機能となる。

（2）　設計

　詳細な調査結果を基に実際のPSTNとの接続方式、提供サービス、着信方式、番号計画などを決定する。また従来のPBXと異なるのは、IPであるためIPアドレスやQoSポリシー、ネットワーク設計の要素も含まれてくるので、この点は十分に注意するようにしたい。

１．着信方式
　日本の会社ではグループ着信を行っているケースが最も多い。この中でも一斉呼び出しを行うかラウンドロビン方式で着信呼数を均等受け付け処理させるなどの方式が一般的である。また、内線・外線呼を区別するための鳴り分けや回線状態をラインボタンで表示させるなどPBXが提供していた機能との差異を事前にユーザーと確認しておく必要がある。ユーザーの代表にデモ環境で操作性などを見てもらい、着信方式を決定してもらうのが一番良いだろう。

　また、内線・外線呼を区別するための鳴り分けや回線状態をラインボタンで表示させるなどPBXが提供していた機能との差異を事前にユーザーと確認しておく必要がある。ユーザーの代表にデモ環境で操作性などを見てもらい、着信方式を決定してもらうのが一番良いだろう。

２．提供サービス
　よくPBXは数百の機能を持ち、IP-PBXなどは数十の機能しかないと比較されるが、実際にエンドユーザーの立場から見た場合、IP-PBXでも十分すぎる機能を保有する。またユーザープロビジョニング機能やユニファイドメッセージなどは、従来PBXよりも優れたものを提供できるようになっている。多機能電話機にボタンが割り付けられているだけでほとんど使用されていない機能も中には存在するかもしれない。

３．番号計画
　着信方式や提供サービスが決定されれば番号計画もだいたいまとまってくる。

0：外線発信特番

1：緊急特番

2〜4：内線番号

5：グループ代表番号

6〜8：空き（リザーブ）

9：専用線発信特番

＊：サービス特番

＃：サービス特番

　上記以外に仮想番号といわれる実際には使用しない番号が必要となるIP-PBXも存在する。これはPBX同様に外線からの呼を同時複数着信可能とするために必要となる番号である。

　このような考えが不要な製品も存在する。ちなみに、このユーザーが選択したものは考慮する必要のない製品であった。

４．可用性
　回線・IP-PBX・IPネットワーク・電源系の4つの要素がバラバラでは障害対策もアンバランスで無意味なものになってしまう。また、複雑な冗長構成も別要因の障害を引き起こすことも考えられる。可能な限りシンプルな構成での障害対策を施すことが大切である。また、対策レベルの分類を行い、拠点や建物単位または部署ごとにどのレベルの対策を講じるかなどをコストとともに確認しておく必要がある。

1.正常系
　これは内線・外線での発着信試験（発切・着切）と保留や転送などの基本機能と長時間通話試験などを行う。

2.準正常系
　正常系とは異なり、相手話中状態，未登録番号への発信・転送、途中放棄・呼び出しタイムアウトなどの試験を行う。

3.異常系
　言葉のとおり通常状態ではない状況での動作を確認することである。具体的には、以下の異常が挙げられる。

IPネットワーク異常（端末側、GW側、サーバ側、キャリア側）状態での発着信
通話中後のIPネットワーク異常

4．機能試験
　正常系で基本機能は確認したが、無応答転送・無条件転送やボイスメールなどの拡張機能試験の確認を行う。また、キャリア側とVoIPでダイレクト接続する場合などはキャリア側サービスとの連携確認も行う必要がある。

　実際の検証をベースに、もし不具合があればベンダ側と実装改修や機能追加などについて早期に検討する必要が出てくる。大変ではあるが、その分、逆にネットワーク・エンジニアとしては楽しい部分でもある。

（4）　構築

　特殊なことはないが、気を付けることは試験方法や手順を遺漏なくかつ効率よく考えておくことが重要となる。すべての電話機で全機能を試験することも、ある程度の規模までならば可能だろうが、規模が大きくなれば不可能だ。基本発着信試験は全台数行うにしても、それ以外の機能についてはグループ単位で実施するように人員や試験用電話機やFAXを決めておくこととあらかじめチェックシートを作成しておくことは大切である。

（5）　教育

　構築の中盤から終盤以降ではユーザー管理者やエンドユーザー向けに対しての教育を行っていかなければならない。これにはユーザー側の協力が不可欠であり、当初のプロジェクト体制の中に事前に盛り込んでおくことが重要である。操作や機能説明また従来電話との差異などはマニュアルなどを準備して周知徹底しておくことが大切である。

（6）　試験運用

　オペレーションミスなどによる障害コール（ナンセンスコール）が初期段階では必ず発生する。このコール数を極力少なくし新システムに少しでも早く移行できるようにするためにも大切なことである。

（7）　運用

　どのような体制と役割で運用していくかを決めなくてはいけない。一番大切なことであるが、この部分が忘れられているケースが非常に多い。導入して完了ではなく、導入してからがスタートになるわけである。特に組織的に総務と情報システム部門にまたがっている場合には運用保守体制と役割区分はお互いに明確化して確認しておくことが大切である。物理的な配線管理、番号管理、新規・移動・削除手順、障害受付窓口、運用監視の仕組みと体制などを詳細設計段階から別ワーキンググループで行っていくことが大切である。そして時間が許せば構築当初の段階からこれらのメンバーがかかわっていけばスムーズな移行へつながるはずである。