voip 101 - juniper networks...voip 101 voipネットワークの知識ホワイトペーパー...

VoIP 101

VoIPネットワークの知識

ホワイトペーパー

スティーブン・ブラナー上級ネットワークセキュリティコンサルタント

アクラク・A・アリ上級マーケティングエンジニア

Juniper Networks, Inc.1194 North Mathilda AvenueSunnyvale, CA 94089 USA408 745 2000 or 888 JUNIPERwww.juniper.net

ジュニパーネットワークス株式会社〒163-1035 東京都新宿区西新宿3-7-1新宿パークタワーN棟35階電話03-5321-2600FAX 03-5321-2700URL http://www.juniper.co.jp

Part Number: 200087-001 08/04

はじめに ....................................................................................................................................................3VoIPの魅力 ..............................................................................................................................................3VoIPの機能 ..............................................................................................................................................4

シグナリング....................................................................................................................................4 データベースサービス....................................................................................................................4呼接続・切断（ベアラ制御）..........................................................................................................4CODEC処理 ....................................................................................................................................5

VoIPのコンポーネント............................................................................................................................5呼制御サーバー／IP-PBX..............................................................................................................6ユーザー用端末器機........................................................................................................................7メディア／VoIPゲートウェイ／ゲートキーパー........................................................................8IPネットワーク................................................................................................................................9

VoIPシグナリングプロトコル................................................................................................................9 H.323 ..........................................................................................................................................10RTP（Real-time Transport Protocol）................................................................................12 RTCP（Real-time Transport Control Protocol）............................................................13MGCP（Media Gateway Control Protocol）....................................................................14SIP（Session Initiation Protocol）......................................................................................15MEGACO/H.248 ....................................................................................................................17

VoIPサービス利用に当たっての留意点..............................................................................................18遅延（レイテンシ）......................................................................................................................18揺らぎ（ジッタ）..........................................................................................................................20帯域 ................................................................................................................................................20

計算例 ..................................................................................................................................21パケットロス ................................................................................................................................22信頼性 ............................................................................................................................................22セキュリティ.................................................................................................................................23

まとめ ....................................................................................................................................................24

目　次

VoIP 101

はじめに

VoIP（Voice over IP）が登場してからすでに何年も経過していますが、従来の加入電話網に代わる現実的

な選択肢としてVoIP市場が立ち上がったのは、ごく最近のことです。関心や認知度の高まりに一役買った

のは、IPネットワークを活用してデータ通信にも音声通話にも対応できるというコストパフォーマンスの良

さ。しかし、コストだけでは将来の発展は望めません。当然、サービスや機能も重要な条件となります。現

在利用している加入電話並みの音質やサービスが確保できなければ、ユーザーは納得しません。残念なが

ら、現時点ではVoIPはまだそのレベルに到達していません。

現在、音声系のプロトコルは、ほんの数年前の状況と比べると、機能が豊富になっただけでなく、拡張性が

強化され、標準化も進んでいます。新しいネットワークと既存ネットワークのサービス統合（一元化）は、

VoIP製品・サービスの進展に伴ってペースが上がっています。こうした状況の中、高付加価値・高利益率の

サービスを展開できるかどうかが成否の分かれ目となります。たとえば、通信事業者であれば、電話で音

声とメールを連係させるユニファイドメッセージシステムの展開というシナリオが考えられます。

このホワイトペーパーでは、VoIPソリューションに欠かせない機能やコンポーネントを中心に、VoIPの基

本を解説します。「企業にとってVoIP導入はどのような意味があるのか」、「VoIPソリューションはどのよう

な構成要素で成り立っているのか」、「企業によるVoIPの上手な活用法とは」――。こうした疑問にお答えし

ます。VoIPの全体像をつかんでおけば、セキュリティ、信頼性、パフォーマンスの3拍子そろったVoIPネ

ットワークの展開といった高度な課題にも的確に対処できるようになります。

VoIPの魅力

VoIPを調べていて、まず最初に目を引くのは、コストパフォーマンスの高さです。1つのネットワークイン

フラを展開するだけでいいのですから、効率化に貢献することは明らかです。パケット交換方式のネットワ

ークと回線交換方式のネットワークの両方を管理するのと違って、パケット交換方式のネットワークだけを

使用するわけですから、保守・管理費用の削減につながります。また、技術要員も、それぞれの専門知識を

持つ人材を別々に確保しなくても、同じ顔ぶれで音声系とデータ系のシステムを運用できるのです。この

ように音声系とデータ系のネットワークを共通のIPネットワークに統合すれば、当然のことながら柔軟性が

高まり、ネットワーク上のノード（たとえば電話など）の追加・変更・取り外しも簡単です。つまり、手間を

かけずに機器の設置・移設が可能なため、専門業者に現地調整を依頼したり、特殊なノウハウを持つ人材を

確保したりすることなく、手持ちのIT資産を有効活用できます。

さらに、VoIPには、高度なコールルーティングやCTI（コンピュータと電話の連係）、ユニファイドメッセー

ジ、統合型情報サービス、長距離市外通話のトールバイパス、暗号化など、数々の便利な機能があります。

ネットワークインフラが共通化されるため、音声に限らず、映像はもちろん、電子ホワイトボードといった

ものも含め、各種メディアを一元的に扱えます。このような機能の応用例として、いわゆる「フォローミー

機能」（外出時などに自分宛の電話を指定番号に自動転送する機能）が挙げられます。この機能があれば、避

暑地の別荘で仕事をしていようと、海外のホテルに宿泊していようと、社内のデスクにいようと、いつもの

内線番号にかけてもらえば必ず応答できます。また、VoIPとCRM（顧客との良好な関係づくりを実現する

戦略）ソフトの連係機能もあります。たとえば、発信者番号や着信番号を各顧客の取引記録にリンクしてお

き、営業担当者が電話をかけたり受けたりしたときに、手元のPCの画面に自動的に通話相手の取引記録を

表示させることも可能です。

このようにVoIP技術は、IPネットワークに一元化することで優れたコストパフォーマンス、柔軟性、将来

性を備えています。それだけに企業各社は、VoIP技術に熱い視線を送り、メリットを最大限に引き出すに

はどうすればいいのか見極めようとしているのです。

VoIPの機能

VoIPソリューションを構成するコンポーネントを解説する前に、VoIPの基本的な機能を現行の加入電話と

比較しながらご紹介しておきます。前述のように、企業がVoIP導入に成功するためには、加入電話網と同

等の機能を実現できるコンポーネントが必要です。具体的には、次の機能が挙げられます。

■ シグナリング

■ データベースサービス

■ 呼接続・切断（ベアラ制御）

■ CODEC処理

シグナリング

呼（通話）の接続から切断までを確実に実行するには、さまざまなコンポーネントを起動・連係させる必要

があります。ネットワーク内の端末同士が制御信号をやり取りするための規定をシグナリングと呼びます。

加入電話網では、加入者の電話機がまず収容局の加入者交換機（GC交換機＝アナログ）か、従来のPBX（構

内交換機）に接続され、呼接続とコールル－ティングが実行されます。一方、VoIPネットワークのシグナリ

ングは、VoIPコンポーネント間でIPデータグラムのメッセージをやり取りすることで成立します。このメ

ッセージの形式は、通常、各種の標準プロトコルで規定されています。この点については、後ほど取り上げ

ます。

データベースサービス

データベースサービスは、エンドポイントを特定し、2つのネットワーク（通常は異種ネットワーク）で使わ

れているアドレスを変換します。こうしたマッピングと変換を担うのが呼制御データベースです。もう1つ

の重要な機能として、料金請求用のトランザクションレポートの発行があります。特定のエンドポイントか

らは国際通話を禁止するなど、新たなロジックを追加してネットワークのセキュリティを強化することも可

能です。この機能に呼の状態管理を組み合わせることで、ネットワーク内の構成要素の動作を連係させます。

加入電話網では、エンドポイントの識別に電話番号を使います。

一方、VoIPネットワークでは、IPアドレス（DNSでアドレス抽象化を実行可能）とポート番号でエンドポイ

ントを識別します。

呼接続・切断（ベアラ制御）

2つのエンドポイント同士が通信セッションを開始することを、呼の接続と言います。

加入電話網では、公衆交換機（または構内交換機）がネットワーク上でDS-0の論理回線を相互接続するこ

とで通話が実現します。

VoIP環境では、この回線をマルチメディアデータ（音声、映像）がリアルタイムに流れます。この回線がベ

アラチャンネルに相当し、音声や映像のコンテンツの伝送に使用されます。通信が終了すると、IPセッショ

ンが切断され、必要に応じてネットワークリソースも解放されます。

VPN の選択基準

表1：ITU勧告の音声符号化方式

ITU勧告方式伝送速度（Kbps）変換遅延（ms）

VoIP 101

CODEC処理

音声通信はアナログで、データ通信ネットワークはデジタル。このため、ネットワークで伝送できる形式

に音声を変換する仕組みが必要です。多くの場合、加入電話網はアナログですから、このような仕組みは

必ずしも重要なコンポーネントではありませんが、VoIPでは音声の「パケット化」が欠かせません。アナ

ログの波形をデジタル情報に変換する処理は、CODEC（「符号器・復号器」を意味するcoder-decoder

の略語で、コーデックと表記することも）が担います。ボコーダー（VOCODER）と呼ばれることもあり

ます。アナログ音声信号の変換方法は多数あり、いずれも標準規格となっています。変換処理は複雑なた

め詳しい解説は割愛し、ここでは、変換方式のほとんどがPCM（パルス符号変調）か、PCMの流れを汲

む方式であると言うだけにとどめておきます。音声符号化方式はどれも成立の経緯が異なり、それぞれに

利点があります。また、必要帯域（伝送速度）も異なります。

CODEC処理後のデータストリームは、IPパケットとなり、ネットワークを介してエンドポイントに届け

られます。送り先となるエンドポイントも同じ標準規格に準拠し、共通のCODECパラメータを使用して

いなければなりません。送信元と宛先のエンドポイントが別々の規格やパラメータを使用していたら、や

り取りは成立しません。ITU（国際電気通信連合）に承認されている主要音声符号化方式（規格）を表1

にまとめました。方式によって、符号化効率、伝送速度、変換遅延が異なり、残念ながらすべての条件が

優れた方式というものは存在しません。

VoIPのコンポーネント

VoIPネットワークの主要コンポーネントの働きは、方式こそ違うものの、加入電話網とほとんど変わりま

せん。基本的には、VoIPネットワークも加入電話網も処理内容は同じです。ただし、VoIPネットワーク

の場合、VoIPと加入電話網の間で呼を行き来させるためのゲートウェイ機能が必要です。VoIPネットワ

ークには、次の4つの主要コンポーネントがあります。

■ 呼制御サーバー／IP-PBX

■ ユーザー用端末

■ メディア／VoIPゲートウェイ

■ IPネットワーク

1 2 3

4 5 6

7 8 9

*8 #

1 2 3

4 5 67 8 9

*8 #

3280032800

32901 32900

RTPペイロード

ポートは共通の場合と

異なる場合がある

ポートは共通の場合と

異なる場合がある

接続制御：メディアを32800番ポートに伝送

せよ

接続制御：メディアを32901番ポートに伝送

せよ

呼制御サーバー

VoIP 101

呼制御サーバー／IP-PBX

呼制御サーバー（IP-PBXとも呼ばれています）は、VoIPによる電話システムの心臓部で、VoIP制御の回

線をすべて終端する役割を担います。VoIP通信では、呼の確立（「制御トラフィック」）と実際の音声トラ

フィック（「音声ストリーム」、「VoIPのペイロード」）を処理するシグナリングの仕組みが必要です。他の

呼制御サーバーや電話会議機能、保留メロディ機能に音声トラフィックをルーティングする場合を除き、

呼制御サーバーがVoIPペイロード（音声自体を運ぶRTPストリーム）のトラフィックを処理することは

ありません。通常、こうしたトラフィックは、VoIP電話機などのVoIP端末（端末機器）間を流れます。

VoIPの制御トラフィックは、クライアント／サーバモデルに準じており、メッセージングサーバーを含む

VoIP端末がクライアントとなって、呼制御サーバー（ここでボイスメールのメッセージを処理）と通信し

ます。しかし、VoIPのペイロードは、VoIP端末からVoIP端末へピアツーピア形式でやり取りされます。

このケースで言えば、VoIP端末がトラフィックのフローを決定し、呼制御サーバーは制御メッセージ内で

フローのネゴシエーションを実行します。

通常、呼制御サーバーは、ソフトウェアの形を取りますが、ルータープラットフォームとして提供される

場合や専用アプライアンスとして開発される場合もあります。呼制御機能は、単体サーバー、クラスタ型

サーバー、機能分散型のサーバーファームのいずれかの形態で実現します。

図1：呼制御サーバー

呼制御サーバーを使った典型的なVoIP構成図を図1に示します。

SMTPトラップ

SMTPクエリー

モニタリング

Syslog、独自仕様によるログ作成

管　理

メールによるアラート

Telnet, SSH, WebUI

バックアップ制御信号・ペイロードのバックアップ

バックオフィス

DNS, WINS, NIS, NTP

RADIUS, LDAP/AD, SecureID

VoIPSIP, Skinny, JTAPI, MGCP制御

H.323制御 (H.225, H.245), SIP ALG

RTP (保留メロディ)

RTP (拠点外VoIPの受発信)

受け付けコンソール（独自仕様）

RTP

受け付けコンソール（独自仕様）

Clustercontroller

Clustermember

VoIP

呼制御モジュール

VNC, MS-Term, PC-Anywhere

HTTP/SSL, FTP-GET, 独自仕様のアプリ更新

Skinny, JTAPI制御

SIP ALGSIP ALG

受け付けコンソール

VoIP電話機ソフトフォン

Telnet, SSH,WebUI

VNC, MS-Term, PC-Anywhere

TFTP

ユーザーモジュール

管理

VoIP 101

図2は、呼制御サーバーがIP電話端末、ゲートウェイ／ゲートキーパーとの通信にさまざまなシグナリン

グプロトコルが使われている様子を表しています。この点については、後述します。シグナリングプロト

コルとその機能も「シグナリングプロトコル」のセクションで解説します。

ユーザー用端末機器

ユーザー用の端末機器には、VoIP電話機のほか、PCを電話機として使う端末（ハードウェアの電話機で

はなく、ソフトフォンや受け付けコンソールなどソフトウェアベースの電話）があります。

■ VoIP電話機は、TCP/IPスタックを使ってIPネットワークと通信し、設置されているサブネットのIP

アドレスを割り当てられます。VoIP電話機は、内蔵IMアプリや電話帳検索機能などVoIPならではの機

能に対応するため、追加プロトコルを採用することもあります。たとえば、DHCPによる自動設定機

能に対応したVoIP電話機は、DHCPサーバーから設定サーバーの場所に関する情報を取得できます。

なお、設定サーバーは、呼制御サーバーと基本的に同じものです。

■ ソフトフォンは、ノートPC上で動作に対応した電話ソフトウェアで、基本的にはモバイルユーザーを

対象としています。基本機能は、VoIP電話機と変わりません。

■ コンソールは、一定の制御機能を備えたソフトウェアです。通常、ソフトフォンの機能を搭載するほか、

音声ゲートウェイやVoIP電話機を使って従来の電話機にも対応します。呼分配の制御に特化したソフ

トウェアで、呼を接続する受け付けコンソール機能、特定の電話機グループの通話状況を確認するエグ

ゼクティブコンソール機能、呼分配に対応する顧客対応コンソール機能などがあります。コンソールの

タイプには、はっきりとした区別はありません。VoIPコンソールはいずれも独自に拡張したプロトコ

ルを使用しています。インストール先のデスクトップPCはコンソール専用とし、インターネットには

接続せず、データネットワークサービスへの一定のアクセスに制限されます。これは、音声ネットワー

クを外部にさらさないための措置です。コンソールは固定利用とし、接続ネットワークのモジュール内

での使用に限定されています。

図2：呼制御サーバーのシグナリング

図3：VoIPユーザー用端末機器

Telnet, SSH, WebUI

MGCP,

SIP ALG

RS C S T R R D T D C DT A K D A T A

T A K

analog voicegateway

G3 Fax

digital voicegateway

G4 Fax

R S C S T R R D T D C DTA L K D A TA

TA L K

ISDN TAV.90

modem

Voice Gateway

POT

バックオフィスNTP

VoIPSkinny

RTP

RS C S T R R D T D C DT A K D A T A

T A K

G3 Fax G4 Fax

R S C S T R R D T D C DTA L K D A TA

TA L K

ISDN TA TFTP

POT

モニタリング

SMTPトラップ

SMTPクエリー

Syslog, 独自仕様によるログ作成

管理

アナログ音声ゲートウェイ

デジタル音声ゲートウェイ

V.90モデム

音声ゲートウェイ

H.323 control (H.225, H.245) ALG,

VoIP 101

メディア/VoIPゲートウェイ/ゲートキーパー

「ゲートウェイ」と「ゲートキーパー」という用語は、同義語として用いられることがあります。元々、ゲート

キーパーは、呼受付制御と帯域管理に使われてきました。しかし、最近になって技術が進歩した結果、従来

のゲートウェイ（後述）にゲートキーパー機能も組み込まれるようになったのです。

メディアゲートウェイの中心的な機能は、アナログ音声をデジタルに変換し、音声をIPパケット化すること

です（CODEC機能）。さらに、音声圧縮（アナログ、デジタル両対応のものもあり）、エコーキャンセラ、無

音圧縮、統計情報収集などのオプション機能もあります。メディアゲートウェイは、音声コンテンツをIPネ

ットワーク上で伝送するためのインタフェースとなります。

メディアゲートウェイは、ベアラチャネルのトラフィックの送信元となります。通常、各通話（呼）は、UDP

の上位プロトコルとして動作するRTP（Real-time Transport Protocol）によって、ひとまとまりのIPセッ

ションとして伝送されます。ひとくちにメディアゲートウェイと言っても、いくつかの形態があります。たと

えば、通信専用シャーシのハードウェアであったり、VoIPソフトウェアが稼働する汎用PCであったりと、さ

まざまです。機能、サービスには、次のようなものがあります。

■ トランキングゲートウェイ――電話網とVoIPネットワークのインタフェースとして機能。主に、多数の

デジタル回線の管理に利用されます。

■ レジデンシャルゲートウェイ――従来のアナログインタフェースを備え、VoIPネットワークに接続しま

す。レジデンシャルゲートウェイの具体的な例としては、ケーブルモデム、CATV用セットトップボックス、

xDSLモデム、ブロードバンド対応無線モデムなどがあります。

■ アクセスメディアゲートウェイ――従来のアナログとデジタルのPBX用インタフェースを備え、VoIPネ

ットワークに接続します。具体的な例としては、小規模（企業向け）VoIPゲートウェイなどがあります。

■ ビジネスメディアゲートウェイ――従来のデジタルPBX用インタフェースまたは統合型ソフトPBX用イ

ンタフェースを備え、VoIPネットワークに接続します。

■ ネットワークアクセスサーバー――電話回線にモデムを接続し、インターネットにアクセスしてデータ通

信を実現します。

図4は、VoIPゲートウェイが各種シグナリングプロトコルを使ってVoIPの呼制御サーバーやVoIP端末（IP

電話機、メッセージングシステムなど）と通信している状態を表しています。

図4：VoIP／メディアゲートウェイ

IPネットワーク

VoIPネットワークは、1つの論理スイッチと考えることもできます。論理スイッチと言っても、単体のス

イッチではなく、分散型システムです。分散配置された構成要素同士がIPバックボーンで結ばれた形です。

使用するVoIPプロトコルにもよりますが、このシステム全体を指して、ソフトスイッチアーキテクチャと

呼ぶことがあります。

IPインフラ上では、音声パケットとシグナリングパケットをVoIPの構成要素にスムーズに運ぶ環境を整え

なければなりません。とはいえ、両パケットは性格が大きく異なるため、音声系とデータ系のトラフィッ

クを別々に処理する機能がIPネットワークに必要です。IPネットワーク上で音声系とデータ系の両方のト

ラフィックを運ぶのであれば、トラフィックのタイプに応じて優先度を設定する機能が不可欠です。

VoIPと回線交換では、共通するコンポーネントがいくつかありますが、やはり相違点のほうが多いのです。

その1つが、音声トラフィックのトランスポートです。回線交換方式の代表例がTDMネットワークです。

TDMは、交換機同士を結ぶ中継回線に一定の帯域を確保することで、チャネルを割り当てます。つまり、

1回の通話にDS-0回線を1本確保し、通話が終わるまで回線を占有します。

IPネットワークは、パケット交換方式を採用し、いわゆる統計多重効果を生かしている点で、回線交換方

式のインフラとは大きく異なります。優先制御機能の1つであるCoS（Class of Service）を利用すれば、

特定アプリケーションのパケットを優先的に処理することも可能です。リアルタイム性が求められるVoIP

アプリケーションでは、通話サービスが他のトラフィックの影響を受けないように、優先度設定の機能が

不可欠なのです。

VoIPシグナリングプロトコル

VoIPネットワークの実現に欠かせないのが、VoIPのシグナリングプロトコルです。このプロトコルによ

って、利用可能な機能の種類だけでなく、VoIPコンポーネント同士の関係も決まります。

VoIPの製品や実装環境にはさまざまな形があり、現在、多彩な機能が実用化されています。パケット型ネ

ットワーク上でのマルチメディア（音声も含む）伝送技術に関しては、前出のITUとIETF（Internet

Engineering Task Force）が二大標準化団体に位置づけられますが、IETFよりもITUが勧告する規格に

沿った実装例が増加傾向にあります。もっとも、両団体の規格の多くは、同じような問題の解決をめざし

ています。したがって、機能的に重なるものもある一方、手法と名称が異なるものもあります。さらに厄

介なのは、規格同士の食い違いを埋めたり、他社製品と互換性のない固有の機能を追加したりするために、

独自の仕様を盛り込むベンダーが存在する点です。また、1つの製品群にあらゆるプロトコルが実装され

ているわけではありません。このような製品ベンダーは、自社の得意な分野やサービス、市場に特化した

機能だけを備えた製品を作り出しているわけです。音声プロトコルはそれぞれ長所、短所があり、サービ

ス実現方法も異なります。

音声プロトコルは、それぞれ得意、不得意があり、製品の対象分野に適したプロトコルが採用されていま

す。このセクションで取り上げたのは、特に普及しているプロトコルであり、すべてのプロトコルをもれ

なく取り上げたわけではありません。つまり、ここで紹介されていないプロトコルも選択肢として考えら

れる点をご了承ください。

VoIP 101

H.323

H.323は、ITU勧告です。パケット交換によるマルチメディア通信方式で、複数のプロトコルで構成され

た仕様です。各種シグナリング機能のほか、「パケット化」による音声・動画サービス関連のメディア形

式などが規定されています。

H.323は、LAN関連技術によるマルチメディア通信の問題点を初めて系統立てて解決した規格として登

場しました。しかし、IPネットワークやインターネットの普及を受けて、当時すでにあったH.323の規定

を下敷きに、RFC（インターネットの技術標準文書）として多くのプロトコルや技術が開発されました。

現在ではITUとIETFが共同で問題解決に当たっていますが、H.323よりもRFCによる標準化方式のほう

が主流になりつつあります。

H.323のネットワークは、呼制御サーバー、（メディア）ゲートウェイ、ゲートキーパーで構成されます。

呼制御サーバーは、コールルーティング機能と、VoIPゲートウェイや端末への接続機能を担います。ゲー

トウェイは、H.323の終端エンドポイントとなるほか、加入電話網などH.323以外のネットワークとの

インタフェースにもなります。ゲートキーパーは、呼受付制御、帯域管理、コールシグナリングを一手に

引き受けます。本来、ゲートキーパーはH.323環境で必須の要素ではありませんが、ゲートキーパーを使

って呼制御・管理機能をゲートウェイから切り離すことで、H.323ネットワークの拡張が簡単になります。

H.323仕様は動作が重くなりがち（シグナリング制御の手順が複雑なため）で、そもそもLAN環境での

使用を想定して開発されたものです。特に大規模環境となると、やや拡張性に難があります。基本的には、

H.323セッションを確立するまでのシグナリングの手順の複雑さに原因があります。H.323はTCPベー

ス（コネクション型）のシグナリングを前提としています。ただし、オーバーヘッドが大きくなるため、

大量のTCPセッションを維持するのが厳しくなる問題があります。もっとも、H.323の拡張性に関わる

制約の大部分は、広く使われているバージョン2に原因があります。その後にリリースされたバージョン

では、こうした問題の解決に力が入れられています。

では、H.323の主な手順を見てみましょう。

■ 発呼のたびに、Q.931メッセージのサブセットをカプセル化することで、TCPセッションが始まりま

す。このTCP接続は、通話が終了するまで保持されます。呼設定の手順全体を図5に示します。

■ 続いてH.245プロトコルに従って、第2のセッションが確立されます。このTCPベースのプロセスで

は、対応方式に関する情報の交換（能力交換）、マスター・スレーブ関係（音声符号化方式などの決定

権）の交渉、メディアストリームの確立・解除が実行されます。一連の手順は、H.225.0のプロセス

に続いて実行されます。

■ H.323のQoS制御方式は、RSVP（Resource Reservation Protocol）です。このプロトコルは、

アプリケーションごとのトラフィックフローの管理に特化しているため、拡張性はあまり優れていない

とされています。

■ H.323は通信事業者の環境に最適とは言えないものの、企業内のVoIPアプリケーション導入には最適

です。通信事業者の場合、H.323のサービスやアプリケーションと加入電話網の間の橋渡し、転送、

インタフェースの役割も求められるからです。

VoIP 101

1. 起動時・ログイン時にH.323端末がゲートキーパーに登録

H.323端末（電話機） H.323端末（電話機）

H.323ゲートウェイ H.323ゲートウェイ

ゲートキーパー

7.＆8. （オプション）RSVPの要求を送出。各クライアントが相互のRTPセッションを開始

5. 着信側クライアントに呼設定メッセージ（着信音）で着信を通知

6. 発信側が着信側と対応方式に関する情報（CODECパラメータ、メディアストリーム設定）を交換2. ユーザーが受話器を上げて

相手の電話番号をダイヤルすると、ゲートキーパーに要求が送られる

3. （オプション）ゲートキーパーが呼の確立を承認。ゲートキーパーは呼の帯域要求を監視

4. 発信側が呼制御（Q.931）メッセージを着信側に送出


RTPセッション

VoIP 101

図5：H.323の呼設定手順

RTP（Real-time Transport Protocol）

RFC1889とRFC1890で構成されるRTP（Real-time Transport Protocol）は、音声や映像など、

リアルタイム性が求められるデータを対象に、エンドツーエンドでのサービスを実現します。サービスに

は、ペイロードタイプの識別、シーケンスの番号付与、タイムスタンプ、状況監視などがあります。音声

のデジタル化を担うメディアゲートウェイは、RTPプロトコルを使って音声（ベアラ）トラフィックを送

信します。

RTPプロトコル（図6）は、リアルタイム系アプリケーション向けに、タイミング、パケットロス検出、

セキュリティ、コンテンツ配信、符号化方式の識別を再現します。ユーザーから見れば、それぞれの宛先

となるIPアドレスをペアにして、2つのエンドポイント間のセッションが設定されます。つまり、通話中

の呼ごとに1つのRTPセッションが設定されることになります。RTPは、UDPの上位層で動くアプリケ

ーションサービスのため、ベストエフォート方式のコネクションレス型通信となります。このように、

RTPはコネクションレス型ですが、シーケンスの体系を持っており、パケットロスの検知が可能です。

VoIP 101

図6：RTPプロトコルの上位層

仕様上、RTPのペイロードタイプのフィールドには、メディアゲートウェイが音声のデジタル化に使用す

る符号化方式も含まれます。このフィールドは、RTPのペイロードフォーマットを特定し、メディアゲー

トウェイでのCODECによる変換方法を決定します。プロファイルには、ペイロードタイプのコードとペ

イロードフォーマットのデフォルトでの固定マッピングを指定します。このマッピングは、ITUのGシリ

ーズの音声符号化方式が使われます。

RTPパケットのサイズと送出間隔は、音声符号化方式やパケット化速度によって異なります。管理者が音

声系サービスを計画する際には、RTPパラメータを考慮に入れておく必要があります。RTPセッションの

パラメータをすべて勘案しなければ、ベアラ回線の音声トラフィックが使用する帯域量はつかめません。

実は、VoIPネットワークの負荷のうち、音声トラフィックを運ぶRTPトラフィックが最も大きな割合を

占めているからです。

RTCP（Real-time Transport Control Protocol）

RTCP（Real-time Transport Control Protocol）は、RTPと連係して機能するオプションのプロトコ

ルで、RTCPがなくてもRTPの動作には影響がありません。RTCPの中心的な機能は、RTPが実行したデ

ータ伝送の品質をチェックし、そのフィードバックを伝達することにあります。この機能は、トランスポ

ートプロトコルとしてのRTPの重要な役割であり、ネットワークのフロー・輻輳制御機能に関わるもので

す。RTCPからのフィードバックレポートには障害の発生箇所に関する情報までは含まれていません（あ

くまで障害の有無のみ）が、障害探索の有効なツールになります。こうした障害情報は、ネットワーク上

にあるさまざまなメディアゲートウェイから発生するため、RTCPのフィードバックレポートは、ネット

ワークのパフォーマンスが低下していそうな箇所を管理者が調べる際に役立ちます。

管理者は、RTCPを利用してパケットロスや遅延（待ち時間）、揺らぎなど、VoIPに関わる主な指標をチ

ェックすることで、通話セッションの品質が監視できます。この指標は、通話の両端で定期的に取得し、

メディアゲートウェイが通話単位で処理します。

このような指標類のレポート機能はエンドユーザーに不要という理由から、ゲートウェイ機器の中には、

RTCPを採用していないものもあります。たとえば、家庭ユーザー（アナログ電話を使用）がこうしたサ

ービスを提供するゲートウェイにアクセスすることはまずありません。また、メディアゲートウェイのベ

ンダーであれば、もっと拡張性のある方法を使って通話品質の統計データを取得できるはずです。この場

合、統計情報の保存、伝送、表示は、それぞれの機器によって異なります。

ネットワークでRTCP（またはベンダー独自仕様）を使う場合、プロトコルの帯域を計算に入れておく必

要があります。管理者としては、RTCPの制御トラフィックがセッションの帯域全体のごく一部になるよ

うに制限することが大切です。では、どの程度まで抑えるかと言うと、データ伝送プロトコルの機能を損

なわないことが目安になります。事前に必要な帯域を調べて、帯域の仕様に制御トラフィックが含まれる

ようにします。RFCの仕様では、セッション帯域のうち、RTCPに割り当てる割合の推奨値として、RTP

トラフィックの5％に固定することとされています。

VoIP 101

1. ユーザーが受話器を上げて相手の電話番号をダイヤル

2. メディアゲートウェイがコールエージェントに接続要求を通知

3. コールエージェントが電話番号（またはURN）を検索し、ゲートウェイにメディアゲートウェイ間のRTP接続開始（IPアドレスとポート番号）を指示

4. コールエージェントが通話先のメディアゲートウェイに着信を通知（着信音）

5. 相手が受話器を上げると、メディアゲートウェイがRTPセッションを開始

RTPセッション


コールエージェント（メディアゲートウェイコントローラ）

MGCP（Media Gateway Control Protocol）

RFC2705で規定されているMGCP（Media Gateway Control Protocol）は、ソフトスイッチアーキ

テクチャの考え方に沿って策定されました。MGCPでは、従来の電話交換機の役割がメディアゲートウェ

イ、メディアゲートウェイコントローラ、シグナリングゲートウェイの各機能に分割されています。この

結果、各VoIPゲートウェイを別個に管理できるメリットがあります。マスター・スレーブ型の制御プロト

コルとして、各メディアゲートウェイの動作を連係させます（図7）。MGCPのメディアゲートウェイコ

ントローラは、コールエージェントと呼ばれることもあります。コールエージェントは、呼のシグナリン

グ制御を担うインテリジェンス機能の管理役であるのに対して、メディアゲートウェイは、サービスイベ

ントをコールエージェントに通知します。コールエージェントは、呼の生成の際にメディアゲートウェイ

に接続の開始・終了を指示します。ほとんどの場合、コールエージェントは、メディアゲートウェイに対

して、エンドポイント間のRTPセッション開始を指示します。

VoIP 101

図7：MGCPによるメディアゲートウェイの制御

1. SIPクライアントがログイン時または起動時にSIPサーバーに登録（例：[email protected]、[email protected]）

5. 相手が受話器を上げると、SIPクライアント同士がRTPセッションを開始

2. ユーザーが受話器を上げて相手の電話番号をダイヤルするか、URLを指定すると、要求がプロキシサーバーに送られる

3. プロキシサーバーが登録済みの通話相手の電話番号またはURLを検索。SIPサーバーは通話相手（[email protected]）に発呼要求を送信

4. プロキシサーバーからの発呼要求の形で着信側クライアントに着信を通知（着信音）

RTPセッション


SIPプロキシサーバー

IP電話機（SIPクライアント）[email protected]


SIP（Session Initiation Protocol）

RFC2543として標準化されたSIP（Session Initiation Protocol）は、IETFが提唱するマルチメディ

アデータ制御プロトコル体系の一部として開発されました。VoIPネットワーク向けの強力なクライアン

ト／サーバー型シグナリングプロトコルです。SIPは、ユーザー間のマルチメディアセッションの開始・

切断を制御します。具体的には、マルチメディア会議や電話、マルチメディア配信などが挙げられます。

SIPは、テキスト形式のメッセージを採用したシグナリングプロトコルで、TCPまたはUDPの上位層とし

て機能し、軽快に動作するよう設計されています。HTTP（Hypertext Transfer Protocol）やSMTP

（Simple Mail Transfer Protocol）の流れを汲む設計思想とアーキテクチャを採用、シンプルで効率的、

しかも拡張性の高いプロトコルです。

SIPは、いわば“招待状”に相当する「発呼要求」（INVITE）を使い、SDP（Session Description

Protocol）プロトコルに準拠した形式でメッセージを作成します。このメッセージで能力交換を実行し、

呼制御チャネルを確保します。この“招待状”を利用することで、参加者（ユーザー）は、適合するメデ

ィアタイプのセットに同意します。

SIPは、ユーザーの位置に依存しないため、移動利用にも対応します。具体的には、接続要求をプロキシ

サーバに送り、通話相手の現在位置にリダイレクトする方法を取ります。ユーザーは、現在の位置情報を

レジストラサーバーに登録することで、自分の居場所（IPアドレスまたはURL）を通知できます。この機

能は非常に強力で、モバイルの音声通話ユーザーが多くなったときに威力を発揮します。

SIPのクライアント／サーバーアプリケーションには、SIPクライアントがプロキシサーバーかリダイレ

クトサーバーのいずれかを介して通信を実行するという2種類の動作モードがあります。

■ プロキシモード（図8）では、SIPクライアントがプロキシサーバーに要求を送ると、プロキシサーバ

ーは、要求をその場で処理するか、別のSIPサーバーに転送します。プロキシサーバーがシグナリング

メッセージを代理で受け取るため、発信元のSIPユーザーを隔離して非公開にできます。つまり、

VoIPネットワーク上の他のユーザーにとっては、シグナリングメッセージ（発呼要求）はプロキシサ

ーバーから送られているように見えるのです。

VoIP 101



2. ユーザーが受話器を上げて相手の電話番号をダイヤルするか、URLを指定すると、要求がプロキシサーバーに送られる

3. プロキシサーバーが登録済みの通話相手の電話番号またはURLを検索。SIPサーバーは通話相手（[email protected]）に発呼要求を送信

4. プロキシサーバーからの発呼要求の形で着信側クライアントに着信を通知（着信音）

RTPセッション


SIPプロキシサーバー



図8：SIPプロキシサーバーの動作


2. ユーザーが受話器を上げて相手の電話番号をダイヤルするか、URLを指定すると、要求がリダイレクトサーバーに送られる

3. リダイレクトサーバーが登録済みの通話相手の電話番号またはURLを検索。続いてSIPサーバーが発呼側に検索結果（宛先アドレス）を応答

4. 発呼側が宛先（[email protected]）に発呼要求を送信

5. 発呼要求の形で着信側クライアントに着信を通知（着信音）





RTPセッション

SIPリダイレクトサーバー

■ リダイレクトモード（図9）では、発呼要求を受け取ったSIPサーバーは、宛先アドレスを検索したう

えで、宛先アドレス情報を発呼側に返します。情報を受け取ったは発呼側は、目的のSIPクライアント

に接続要求を送ります。

VoIP 101

図9：SIPリダイレクトサーバー


2. ユーザーが受話器を上げて相手の電話番号をダイヤルするか、URLを指定すると、要求がリダイレクトサーバーに送られる

3. リダイレクトサーバーが登録済みの通話相手の電話番号またはURLを検索。続いてSIPサーバーが発呼側に検索結果（宛先アドレス）を応答

4. 発呼側が宛先（[email protected]）に発呼要求を送信

5. 発呼要求の形で着信側クライアントに着信を通知（着信音）





RTPセッション

SIPリダイレクトサーバー

MEGACO/H.248

現在、MEGACO/H.248はドラフト段階の規格で、IETFとITUの両標準化団体が連携して策定していま

す。MEGACOには、前出のMGCPとの共通点が多く、VoIP構成要素の命名方法も同じです。MEGACO

のアーキテクチャでは、メディア変換と発呼元を担うのがメディアゲートウェイで、呼制御を担当するの

がメディアゲートウェイコントローラと規定されています。

MEGACOは、MGCPと同じ要件に対応するため、プロトコルのマージには多少苦労が伴います。通話セ

ッションを確立する際には、メディアゲートウェイコントローラが一連のトランザクションの調整役とな

ることが規定されています。MEGACOの最大の目的は、IP電話機の標準化推進にあります。設計面では、

次のような目標を掲げています。

■ MEGACOのIP電話は、導入した日からビジネス上の基本的なニーズに応えられるものとする。

■ ビジネスシーンでの高度な電話機能をサポートするため、迅速に拡張できる手段を用意する。

■ 幅広い電話機や同様のデバイスを対象に、シンプルなものからきわめて多機能なものまで、自由に設定

できるようにする。

■ シンプルで必要最小限の設計を採用。

■ 機能・能力に見合ったデバイス価格を実現。パッケージや終端のタイプは、高信頼のものとする。

■ IP電話機は、MEGACOの要求仕様書に規定されているとおり、MEGACO/H.248プロトコルの要件

に適合するものとし、MEGACO/H.248プロトコルのアプリケーションとして一目瞭然であること。

VoIP 101

VoIPサービス利用に当たっての留意点

これまでVoIPトラフィックに関連のある機能やコンポーネント、プロトコルについて見てきました。今度

は、トラフィックのパラメータやネットワーク設計など、VoIPソリューションの導入に当たって慎重に検

討しておくべきポイントを解説します。このポイントを事前に考慮しておかないと、信頼性の低いサービ

スや品質低下の激しいサービスを使うことになりかねません。要注意ポイントは次の事項です。

■ 遅延（レイテンシ）

■ 揺らぎ（ジッタ）

■ 帯域

■ パケットロス

■ 信頼性

■ セキュリティ

遅延（レイテンシ）

ネットワークでパケットを送出してから相手に届くまでの時間を、電話の世界では遅延と言います。話し

た声が相手の耳に届くまでの時間と考えていいでしょう。遅延が大きいからと言って、必ずしも通話音質

が劣化するわけではありませんが、会話中に間が空くなど、会話のタイミングがうまく噛み合わなくなる

可能性があります。

一般的に、ネットワーク全体の遅延が150ms未満であれば、加入電話並みの通話品質に相当し、許容範

囲とされています。遅延を150ms未満に抑えるには、下記の主な遅延原因を調べておく必要があります。

マルチサービス型のネットワークを設計する場合、さまざまな遅延を積み上げていくと、信号やパケット

が相手に届くまでの遅延の全体量が求められます。

■ 音声サービスで、エンドポイントがパケット化を実行するのに必要な時間も遅延の原因です。このパケ

ット化に伴う遅延とは、パケットにデータを乗せるための時間です。通常、パケットサイズが大きいほ

ど、パケット化時間が多くなります。パケット化の遅延時間は、使用するCODECの規格によって決ま

ります。また、通話相手側もメディアゲートウェイがパケットからデータを取り出して処理しなければ

ならないため、着信側でも逆パケット化の遅延が発生します。メッセージゲートウェイ装置のハードウ

ェア/ソフトウェアにもよりますが、パケットサイズを小さく抑えれば、通常は遅延時間が発信側、着

信側ともに小さくなります。すべての条件が同じだと仮定すると、メディアゲートウェイ装置の名目上

の動作時間は30ms未満に抑える必要があります。

■ 相互接続装置の物理リンクにデジタル化されたデータ（ビット）をパルスとして送出するための時間

（シリアル化遅延、伝送遅延）も遅延の原因です。この遅延は、リンク速度に反比例します。要するに、

高速のメディアであれば、遅延時間は小さくなります。使用するリンク技術やアクセス方式によっても

多少の違いが出ます。たとえば、64Kビット／秒の回線で1バイトのデータを送出すると、125マイ

クロ秒かかります。同じデータ量をOC-3/STM-1の回線に送出すると、0.05マイクロ秒で済みます。

この遅延は（帯域の大小にかかわらず）避けようがありませんが、通過するリンクの数を抑え、広帯域

のインタフェースを利用すれば、全体的な遅延時間の削減につながります。

■ 伝搬遅延は、電気信号（または光信号）がケーブル全体を移動するのに必要な時間です。信号の移動速

度は光の速度よりも遅いため、必ず伝搬遅延が発生します。しかし、これが問題になるのは、信号（ま

たはパケット）が長距離を移動するときに限られます。一般的に用いられている伝搬遅延の計算式を挙

げておきます。

VoIP 101

■ 伝搬遅延＝回線長（km）/（299,300×0.6）

計算例：総延長6,000kmの光ファイバー回線の片方向の伝搬遅延は次のとおりです（ただし、途中のリピーターは考慮しません）

6000km / (299,300 km x .6) ＝0.0334秒

したがって、伝搬遅延による遅延は、33.4msとなります。

■ 送信待ち時間も大きな遅延の原因です。これは、ゲートウェイやノードの送信バッファ（送信待ちキュ

ー）にあるパケットがリンクに送出されるのを待つ時間です。通常、送信待ちキューとして利用するバ

ッファの大きさは、調整可能なパラメータです。バッファ値を小さくするほど、遅延時間は短縮できま

す。しかし、この遅延は、リンクに送出しようとしているトラフィックの量によっても異なるため、ネ

ットワークに負荷があれば、遅延時間も増えてしまいます。したがって、音声トラフィックには、十分

な帯域とリソースを確保することが大切です。音声トラフィックに使用する送信待ちキューの処理速度

が十分でなく、最大サイズもかなり余裕を持たせてあると、遅延は大きくなります。

■ パケット転送遅延は、ネットワークデバイス（ルーター、スイッチ、ファイアウォールなど）がパケッ

トをバッファに入れてから転送先を決定するまでの時間です。この時間には、パケット転送先のインタ

フェースの決定時間、アクセス制御リスト（ACL）やセキュリティポリシーに照らしてパケットを廃

棄するか転送するかの判断時間も含まれます。パケット転送遅延は、ネットワークデバイスの機能やア

ーキテクチャによって大きく異なります。パケット処理の関係でバッファ時間が長くなれば、当然遅延

は大きくなります。

VoIP 101

時　間

予定到着タイミング

実際の到着タイミング

揺らぎ（ジッタ）

揺らぎは、パケットの到着間隔がばらつくことで、予定の到着タイミングと実際の到着タイミングのズレ

を指します。つまり、20msごとに一定のタイミングをパケットを送出すれば、本来なら宛先に20ms間

隔で到着するはずです。ところが常にそうとは限りません。たとえば、図9の下段では、1番目のパケッ

ト（P1）と3番目のパケット（P3）は予定どおり到着していますが、2番目のパケット（P2）は予定よ

り12ms遅れて到着し、4番目のパケット（P4）は予定より5ms遅れて到着しています。

VoIP 101

揺らぎの最大の原因は、ネットワークトラフィックの負荷が刻一刻と変化することで発生するキューのば

らつきです。また、ルーティングコストが同じでも物理的（電気的）な距離が異なるリンクを選択したパ

ケットも、揺らぎの原因になることがあります。

メディアゲートウェイには、音声再生用のバッファ（揺らぎ吸収バッファ）があります。これはパケット

のストリームを一定量ためておいてから音声波形を再現することで、揺らぎの影響が及ばないようにする

ものです。この音声再生用バッファがあれば、揺らぎの影響を最小限に抑えられますが、深刻な揺らぎは

除去できません。

ある程度の揺らぎは仕方ないとしても、深刻な揺らぎは音質劣化の問題につながります。到着タイミング

が乱れたパケットをメディアゲートウェイが破棄することがあるからです。このような事態が発生すると、

メディアゲートウェイの音声再生用バッファが埋まらず、再現した音声波形に抜けができかねないのです。

帯域

音声トラフィック用に確保すべき帯域は、簡単な計算で求めることができます。しかし、音声系とデータ

系を網羅する統合型ネットワークの場合には、それぞれに割り当てる帯域の比率を決定しておく必要があ

ります。各組織の優先課題や実際に調達可能な帯域に基づいて慎重に判断してください。管理者が音声系

サービスにあまり帯域を割り当てないと、ひどい品質になりかねません。帯域が少なくなったときに、音

声系サービスは、通常のインターネットのトラフィックよりも許容力が低いという問題もあります。そこ

図10：揺らぎの例

で、音声系サービスと対応シグナリングに使う帯域は、ベストエフォート型のインターネットトラフィッ

クよりも優先度を高くしておかなければなりません。現行の加入電話網で一般的な音声符号化方式

（CODEC）をネットワークに採用する場合、VoIPネットワークのほうが、同じ処理能力を持つ回線交換

方式の電話網よりも多くの帯域が必要になるはずです。この理由は、音声系サービスに使用するプロトコ

ルのオーバーヘッドがあるからです。通常、数千の通話セッションをサポートするには、OC-12c/STM-

4以上の速度が必要です。しかし、パケット方式のネットワークが使用する帯域は、回線のサイズが固定

されているTDMネットワークよりも柔軟に細分化して利用できるメリットがあります。そこで、圧縮と無

音圧縮を生かしたVoIPネットワークであれば、同様の回線交換網よりも実質的な帯域使用量は少なくなる

可能性があります。

ネットワーク帯域の割り当ては、ピーク時の予想呼数に基づいて決定します。音声用帯域に対する要求超

過が発生すると、音質が劣化することがあります。また、呼をきちんと完了し、サービス停止の可能性を

なるべく排除するには、シグナリング用の帯域も十分に確保しておかなければなりません。音声トラフィ

ックに必要な帯域は、意外に簡単な計算式で求められます。

任意の通話数のときにRTPのベアラチャネルの音声帯域使用率を求める公式は、次のとおりです。

帯域（ビット／秒）＝1秒当たりのパケット化速度×パケットサイズ×通話数×8ビット／秒

ここで、1秒当たりのサンプル数＝1000ms / パケット化速度

計算例

G.711の音声符号化方式による全二重音声チャネルが2,000回線あり、パケット化速度が20ms、パケ

ットサイズが200バイト（IPヘッダ40バイト＋ペイロード160バイト）のとき

1秒当たり50サンプル＝1,000ms / 20ms

160 Mビット／秒 = 50×200×2,000×8

この数値は、IPトラフィックそのもののを示しており、伝送メディア（ルーター間のリンク）で使用する

オーバーヘッドやデータリンクレイヤのプロトコルは考慮されていない点に注意してください。この生の

数値にオーバーヘッドを加えると、この呼数をサポートするのに必要なリンク速度が求められます。ただ

し、ベアラチャネルのコンテンツ（音声）に限定した数値です。

シグナリング用の帯域要件は、呼生成の速度や使用するシグナリングプロトコルによって異なります。比

較的短時間に大量の発呼数がある場合、シグナリングに必要な最大帯域がきわめて大きくなることがあり

ます。IPシグナリングプロトコルに必要な最大帯域の一般的な目安は、ベアラトラフィックの約3％です。

前出の計算例に出てきた条件を使うと、1秒間の発呼数2,000の場合に必要なシグナリング帯域は、およ

そ4.8Mビット／秒（160Mビット／秒の3％）となります。

ここまでの計算で、ベアラとシグナリングに必要な帯域が求められました。G.711で符号化した2,000

の呼をサポートするのに必要な帯域は、最大で164.8Mビット／秒となります。この帯域要件は、あくま

でこのケースだけに当てはまる最大理論値です。発呼速度や音声符号化方式、パケット化速度、圧縮や無

音圧縮の有無などの条件が変われば、必要な帯域も変わってきます。

かなりの帯域を必要とする大規模VoIP環境の場合、要求されたサービスを常に高いパフォーマンスで提供

することが、IPネットワークに課せられた使命なのです。

VoIP 101

パケットロス

パケットロスを引き起こす原因はさまざまで、避けようのないケースもあります。多くの場合、ネットワ

ークを流れるトラフィック量が少なめに見積もられています。ネットワークの輻輳時に、ルーターやスイ

ッチで送信待ちバッファあふれが発生すると、パケットを強制的に破棄することがあります。ウェブブラ

ウザやファイル転送など、リアルタイム性が求められないアプリケーションでは、パケットロスは好まし

いとは言えないまでも、重大な問題ではありません。非リアルタイム系アプリケーションは、通常、TCP

などのプロトコルを使っており、多少のパケットロスがあっても、再送信機能があるため、特に問題にな

らないように設計されています。

一方、パケットロスに非常に弱いのが、UDPの上位層で稼働するリアルタイム系のアプリケーションです。

UDPは再送信機能がありませんが、仮にあったとしてもまず役に立ちません。RTPセッションでメディ

アゲートウェイがパケットの再送信を受けたとしても、すでに音声波形の再現には間に合わないのです。

結局、再送信されたパケット内にある波形の一部は、使われずじまいとなります。

むしろ、音質劣化やサービス停止が発生しないように、ベアラとシグナリングのパケットが破棄されない

ようにすることが重要です。そのような場合、イーサネットレイヤには、IPのDSCPのような役割を果た

すCoS（Class of Service）があります。この仕組みが非常に重要なのです。重要なパケットに高い優

先度が設定されるようにCoSパラメータを調整すれば、たとえネットワーク輻輳時でも、大切なアプリケ

ーションのパケットを確実に配送する環境が実現します。

パケットロスはどのようなものであれ、好ましいものではありませんが、容認できるパケットロスもあり

ます。音声系サービスのパケットロスも、多数のユーザーに影響を与えないのであれば、ある程度は許容

できます。一般に、パケットロスの量が全呼数の5％未満であれば、音質に悪影響が及ばないとされてい

ます。バッファを大きくしてパケットがそろうまでの遅延を増やすくらいなら、パケット落ちにしたほう

がはるかに適切な判断と言えます。

信頼性

ネットワーク障害はめったに発生しないとしても、障害対策の計画はないがしろにできません。ネットワ

ークデバイスの不具合やリンク切断といった事態には、フェイルオーバーが効果的です。大切なのは、ネ

ットワークデバイス間のリンクの冗長化や設備の冗長化です。サービス停止のない環境を実現するには、

メディアゲートウェイやメディアゲートウェイコントローラが冗長構成を十分に生かせる態勢づくりが不

可欠です。

IPネットワークは、ルーティングプロトコルを使ってルーティング情報を交換します。この一連の処理を

実行する中で、ルーティングプロトコルは接続リンクの状態を監視しています。通常、ルーティングプロ

トコルが障害を検知した場合、代替パスが存在するときには、障害箇所を迂回するパスにパケットを転送

（リルート）します。障害検知と代替パスの再計算にかかる時間は、リンクに使われているメディアによ

って異なります。たとえば、SONET/SDH回線であれば、信号の損失の検知とリルートは非常に短時間

で実行できます。しかし、LANスイッチを経由する回線の場合、KeepAliveメッセージの確認、タイムア

ウトを経て、ようやく障害が検知されます。

フェイルオーバー機構の一環として、ネクストホップアドレス（デフォルトのゲートウェイ）の状態を先

回りして検知する機能をメディアゲートウェイとメディアゲートウェイコントローラに持たせておけば、

大規模なサービス停止の危険性を抑えることができます。このほか、メディアゲートウェイとメディアゲ

ートウェイコントローラを直接ルーターに接続する方法もあります。この方法の場合、リンク障害（障害

VoIP 101

の内容によります）の可能性を即座に検知し、ネットワークデバイスが適切な措置を実行できます。さら

に、長時間の障害を減少させる方法として、VRRP（Virtual Router Redundancy Protocol）などの

冗長化機能が挙げられます。

セキュリティ

特に音声系とデータ系の統合ネットワークの場合、セキュリテ

ィは非常に重要なポイントです。企業としては、音声通信デバ

イスを不正アクセスや悪意のある攻撃から守る必要がありま

す。不正アクセスはセキュリティ用のプロトコル（RADIUSや

SSHなど）を使って阻止できますが、むしろ音声系サービス

にとって真の脅威は、DoS（Denial-of-Service）攻撃と言え

ます。こうした攻撃によって、音声系サービスの停止や完全麻

痺といった事態に陥ることが考えられます。

VoIPデバイスのセキュリティを確保する方法として、メディアゲートウェイや呼制御サーバーにプライベ

ートIPアドレスを割り当てる方法があります。プライベートアドレスは、パブリック空間であるインター

ネットにアドバタイズされることはないため、デバイスが外部にアクセスできなくなるというわけです。

さらに、VoIPに関わる処理サーバーやゲートウェイ、メッセージングシステムはすべてファイアウォール

の内側に置き、アクセス制御ポリシーを適用してDoS攻撃を防御します。ファイアウォールがネットワー

クで使われているシグナリングプロトコルを解釈できれば、ポートの開閉を動的に実行し、通話中はVoIP

トラフィックだけを通すことも可能です。ポートが開きっ放しにされないため、不正使用のターゲットに

はなりません。こうしたサーバーはVoIP通信になくてはならないものだけに、ファイアウォールポリシー

をきちんと作成して、サーバーとVoIP端末の通信をしっかりと保護することが大切です。こういったポリ

シーを作成する場合には、権限のある端末かどうか、あるいは特定のIPアドレスやインタフェースとやり

取りするトラフィックかどうかを基準に、VoIP通信に制限をかける必要があります。ファイアウォールを

使ってVoIPネットワークをセグメント化すれば、音声トラフィックとその他のトラフィックが分離できる

ため、適切な優先度とポリシーを適用できます。また、DoS攻撃の緩和や不正侵入証拠保全のログ作成と

いった用途にもファイアウォールは活躍します。さらに、侵入防御システムを配備すれば、DHCPメッセ

ージの悪用やFIBテーブルのフラッド攻撃などの攻撃を検知・防御できます。

VoIP 101

VoIPを取り巻くセキュリティ上

のリスク、リスク低減策の詳しい

解説については、ジュニパーネッ

トワークスのホワイトペーパー

「Deploying a Secure VoIP

Network」をご覧ください。

まとめ

ビジネスの世界では、従来の加入電話網に代わる魅力的なソリューションとしてVoIPの注目度が高まって

います。しかし、VoIP導入は、スイッチオンで準備完了と言えるような簡単なものではありません。

VoIPネットワークにはどのような機能が必要なのか、VoIPネットワークの導入に伴って問題になりそう

な機能はどれか――。こうした視点に立って、機能をあらゆる角度から検討することが大切です。データ

通信ネットワークの導入時にさまざまなプロトコルを選定したように、VoIPの要件に合わせて各種プロト

コルを選ぶことになります。もちろん、この要件は、各社のビジネス上の要件や技術上の要件によって大

きく異なります。VoIP用プロトコルが乱立していて市場では混乱も見受けられますが、これだけプロトコ

ルの自由度が高いからこそ、VoIPの電話システムは従来の電話と比べてはるかに大きな利用価値があると

も言えるのです。そこで、ベンダー選びの際には、次の3大ポイントに注目するといいでしょう。

■ 自社製品に関して標準規格のサポートを確約しているか――すべてのVoIPプロトコルとの相互運用性

を考慮した音声ソリューション戦略を積極的に打ち出しているベンダーかどうか。こうした姿勢が見ら

れなければ、VoIPシステムが従来の電話システム同様にベンダー独自仕様で固められてしまう恐れが

あります。

■ 複数プロトコルのサポートをしているか――新たなプロトコルに対応したシステムへの移行や製品の追

加に乗り出すことになったとしても、複数プロトコルをサポートしているベンダーであれば、ホールセ

ール業者のインフラの総入れ替えや大規模更新の必要はありません。

■ あらゆるVoIPプロトコルを対象としたエンドツーエンドのサポート体制があるか――シングルプロト

コル環境でもマルチプロトコル環境でも機能するソリューションを提供するのが、ベンダーの務めです。

また、このホワイトペーパーで取り上げた問題点に対処可能なソリューションかどうかも重要なポイント

です。遅延、揺らぎ、帯域、パケットロス、信頼性、セキュリティなどの事項について、VoIPインフラに

求められる要件を満たしているVoIPソリューションでなければなりません。自由度の高いVoIP環境を構

築できるベンダーを味方につければ、VoIPを有効活用はもちろん、次世代ネットワークの要件にも対応可

能な拡張性と信頼性のネットワーク構築に取り組むことができるのです。

VoIP 101

voip 101 - juniper networks...voip 101 voipネットワークの知識 ホワイトペーパー...

Documents

voip 101 - juniper networks...voip 101 voipネットワークの知識ホワイトペーパー...