間違いだらけのネットワーク作り(72) 99/04/17
「VoIP事例」

 このページの読者の方からVoIPに関する情報が寄せられたのでご紹介します。
企業名、氏名は匿名とし、不要と思われる文章は削除させて頂きました。
−−−−−−−−−−−−−−−−−−−−−−−−−−
松田様のホームページを興味深く読ませていただいております。
弊社は、従業員一万人、拠点数で言えば、100拠点以上の規模
のネットワークです。

松田様のホームページ上では、基本的なスタンスとして
「VoIPはまだ企業内システムとしては使いものにならない」
という論調だと思います。確かに理論に裏付けされた説明には
納得しております。

ところが、社内でVoIPを運用しておりまして、音声チャネル数で
言えば10チャネル以上の数拠点に適用しております。なお、
768Kbps程度のSD上で実現しています。さらにSNAもルータで
トンネリングさせています。ルータ上での優先制御は当然行って
います。

このような状況で使用しておりますが、音質,エコー,遅延そ
の他の問題に関しては一切発生しておりません。全然問題が無
い、というわけではなくて、予想だにしないところで若干の問
題はありますが、それは松田様がホームページ上で指摘してい
るものではありません。

但し、「問題が無い」というレベルの定義が難しいのは事実です。
弊社は製造業ですが、その業種に携わる一般ユーザが、日々
の内線電話にVoIPを使用して「問題が無い」という意味と捉えて
ください。実際に私が試聴してTDM網との違いを認識するのは
難しいです。

結果的に、今後は全社ネットワークをVoIP化していく方針で固
まっています。(細かい話をするとキリがありませんが、基本
的なスタンスということです。)

以上、「問題なく動作している」という事実だけをご連絡させて
いただきます。松田様の論調とは、違う事実であると思いました
のでご指摘させていただきました。

逆にご意見いただければ幸いです。
 −−−−−−−−−−−−−−−−−−−−−−−−−−−
  私のこのページでの論調は繰り返し、いろんな記事で述べていますが
@小規模なネットワークならVoFRだろうが、VoIPだろうが何とでもなるが、
銀行のような大規模なデータ・音声統合網ではQoS制御や帯域制御が
キチンとでき、処理能力も高いATM交換機やFR交換機を使うべき。

Aデータ・音声統合の問題は高速ネットワークでは生じにくい。低速の
アクセス回線・高速基幹回線が多数混在する環境で問題が生じやすい。

 なお、VOIP製品が進歩しつつまるのは事実であり、先日のCISCO社
やNORTEL社の訪問目的も何処まで使えるようになっているか、見極める
のが目的でした。私はVOIPを決してやらない、なんて考えている石頭では
ありませんので誤解しないでください。いつ大規模ネットワークで使えるように
なるのか、判断するのが重要だと思っています。

 上記のメールはネットワーク構成も何もないので細かなコメントは出来ませんが
ポイントは次のとおりです。

@このネットワークは小規模なデータ・音声統合網です。
 
  ネットワーク拠点が100以上あっても、データ・音声統合されている拠点が
数拠点なら、データ・音声統合網としては小規模ネットワークです。私が大規模な
ネットワークでデータ・音声統合が難しいといっているのは、データ・音声統合され
ている拠点が多い場合です。

Aデータ・音声統合されている拠点間がすべて高速で接続されている場合、
問題は少なくなります。
 
 数拠点を768KSDで接続しているというのは、VoIPとしては理想的な環境です。
「色の白いのは七難かくす」といいますが、VOFRであれ、VOIPであれ「速度が速いのは
七難かく」します。さらに言えば、「拠点間速度がほぼ均等でギャップが少ない」となれば
理想的です。

 Delayは音質を大きく左右しますが、768Kといった回線では伝送遅延はきわめて小さく
なります。回線の使用率が何%程度か分かりませんが、音声10チャネル程度では128K
も必要ありませんから、おそらくは低いのでしょう。そうすると伝送待ち時間も小さくなります。
音声を優先していればなおのことです。

 遅延そのものが大きいとクレームになりますが、それがないのは納得できます。エコーは
遅延時間が大きいときに発生するのですから、これも出ないのは当然です。

 このネットワークが真価を問われるのは768Kで接続されている拠点に64K、128Kとい
った低速回線で全事業所が接続され、本当の大規模データ・音声統合網になった時です。

 低速回線、たとえば64K回線で1kバイトを超えるIPパケットがそのままフラグメントされずに
伝送されると、120ミリ秒以上音声パケットが待たされ音がトギレます。でも、768K回線なら
わずか10ミリ秒ですから問題になりません。ルータは何も考えずにデータ・パケットを転送すれ
ばいいのです。

 768Kで拠点のルータまで来た音声パケットやデータパケットが64K回線でリモートオフィスに
接続されるようなケースでは「速度のギャップ」が問題になります。上述したように、768Kでは
1Kバイトで良かったデータパケットは、そのまま64K回線に送出したのでは音声のトギレを生じる
ため、80バイト程度にフラグメントせねばなりません。

 データパケットのフラグメントをしても回線そのものが遅いのですから、音声パケットの遅延が大きく
なり、エンドユーザが遅延に気づいたり、エコーが生じやすくなります。

 768Kでは「まあ、良かろう」と無視できたIP/UDP/RTPといったヘッダのオーバーヘッドも
64Kとか128Kでは回線の利用効率を大きく損ないます。
  
 さらに、本社 →768k→拠点→64K→リモートオフィスという方向で音声パケットと、メールに添付
されたWORD文書が同時に送信されると、拠点のルータから64K回線への送信バッファでconge
stionが生じます。優先制御をしていてもバッファが充分大きくなければ音声パケットが捨てられ、トギレ
が起きます。もちろん、1Kバイトのデータパケットは64K回線に出る前に短く分割されねばなりません。
音声パケットの破棄は768Kと64Kのようにギャップが大きいと生じやすくなります。768Kと768Kなら、
バッファにたまることはありませんから、破棄など起こらないのは当たり前です。

 要は高速回線と低速回線が混在する大規模なデータ・音声統合網を音声をサポートしたルータやVOIP
ゲートウェイとルータで実現するには、優先制御は当然のこと回線速度に応じたデータ・パケットのフラグメント
や、適正なバッファリング、フラグメントされて数倍の数になるパケットを処理する充分な能力、といった条件
が満たされねばなりません。高速回線だけで数拠点を結ぶのとは難しさが違います。

 仮に、VoATMなら、データだろうが音声だろうが53バイトのセルにフラグメントされており、QoS制御も
確実に行えます。オーバーヘッドといっても10%程度で、音声をIPに格納した場合よりはるかに小さくなります。
ちなみに音声は20ミリ秒分程度、8K CS−ACELPだと20バイトを1つのパケットに格納します。IPやUDPのヘッダが40バイト程度であることを考えるとオーバーヘッドは70%近くなります。かといってヘッダの圧縮と伸長をルーティングの度にやっていたのでは遅延が大きくなります。

 VoATMに対してVoIPは超えるべきハードルが高いのです。どのくらいの時間でVOIPがVoATMの品質に
追いつくか分かりませんが、現時点で金融機関をはじめ大規模なデータ・音声統合網を構築するならVoATM
の方が優れていると思います。

 このメールを頂いた方は小規模事業所もVoIPで統合する計画とのことですので、その結果の続報を是非お知らせ頂きたいと思います。

 
***今週から大倉電気株式会社殿の協力を得て週間情報通信ニュース・インデックスを再開しました。

ホームページへ