
連載:VoIPに耐えるネットワーク構築(2)
IP電話を使うなら知っておきたいパケット制御
ネットワンシステムズ
延坂 成人
2004/3/5
| シグナリングと音声パケットの制御 |
「連載:VoIPに耐えるネットワーク構築」では、企業が自社の電話設備を『拠点間VoIP』や『IP電話』などを導入してIP化していく際に、どのように技術的観点から調査し設計導入を行っていけばよいのかを考察している。第1回「IP電話導入のためのネットワーク必要条件」では、通信料金、既存ネットワーク環境、運用保守などの“ユーザー環境”のベースとなるネットワークがどうなっていれば、新規投資が抑えられ、“最大の効果”が得られるのかを考えた。
連載第2回目となる今回は、さらに深い考察のため、実際にVoIPがどのような技術を基礎として実現されているかを見ていきたい。
IP電話サービス、IPセントレックス、IP-PBX、IP-Telephonyなどいろいろな“言葉”が飛び交っているが、基本は通信相手との接続制御と通信メディアとしての音声情報の伝達をどのようにして行われるのか、このことをよく理解しておくことが大切である。要素技術として接続制御を行うシグナリング部分と音声などのリアルタイム情報がどのようにパケット化されているのかについて解説する。
前者のシグナリングについてはいくつかの標準技術や、メーカーによる独自方式が存在する。後者の音声トラフィックについては、標準技術で実現されている。では、具体的に見ていこう。
| シグナリングと音声パケットの制御:目次 | ||||
|
| (1) VoIPで使用されるシグナリングプロトコルとは? |
最初にVoIPで使用されるシグナリングプロトコルについて見てみる。冒頭で触れたとおり標準と独自方式が存在する。独自方式については、それらを規定したメーカーからの解説に任せたい。ここでは、標準方式を中心にお話ししたい。
標準方式の代表的な方式には、H.323、 MGCP、 SIPの3方式が挙げられる。ITU-T側で考えられたものがH.323、IETF側で考えられたものにMGCP、 SIPなどがある。それぞれのプロトコルの特徴は表1のとおりだ。
|
||||||||||||||||||||||||||||
| 表1 モニタリングのカテゴリと対応するチェック内容 |
表1にも記載してあるが、今後VoIPキャリアが採用するプロトコルはSIPであり、携帯端末にしても同様であることがIT関連ニュースなどでも見られる状況となってきた。
| (2) SIPプロトコルを読み解く |
VoIPを導入すると、従来のネットワークと比較し大きな違いとなるのは何か? 答えは、内線側の通信方式である。従来のPBXは公衆網と内線側は別プロトコルで、内線側は各社独自方式が用いられ、差別化が図られてきた。これに対してVoIPでは網から端末レベルまで標準化されたプロトコル(技術)にすることが可能となってくる。特定のメーカーに依存するのではなく、ユーザー側の製品選択の幅が広がり、音声ネットワークを構築する際の自由度も大きくなってくることが予想される。
もちろん、端末レベルまでシームレスな環境を望むには相互接続検証がまず大切であり、この行為を避けて実現させることは現状では不可能に近い。しかし、同一基礎技術をベースにすることで相互接続性をかなり高められる。
現在各キャリアが提供する法人向けIP電話サービスで使用されるシグナリングプロトコルはSIPである。従来は先に触れたとおり、外側(外線や中継線)と内側(内線側)は別のプロトコル(技術)が用いられていたが、それらをIP化するのであれば単に伝送路をIP化するだけでなく、端末レベルまでサービス授受可能な形態を目指すべきである。
既存PBXと同様に内線は独自方式でVoIPキャリアとの接続にはPSTN-GWで接続するか、その部分だけSIPに対応するような製品も存在する。先に述べたとおり、シームレスな環境になることを踏まえ内外線ともにSIPに対応できるものが望ましい。
SIPはセッションの確立・変更・切断(終了)を規定している。具体的なSIPメッセージのやりとりはメソッド(リクエスト)とレスポンスコード(応答)で行われ、セッションコントロールを行っている。各メソッドとレスポンスコードの一覧は次の通りである。
|
メソッド |
|
上記メソッドの中にSIPヘッダを用いてリクエストやレスポンスの詳細情報を提供する。
|
レスポンスコード |
|
これらのSIPメッセージはUDPを用いて行われる。SIPのプロトコルスタックは以下のようになっている。
![]() |
| 図1 モニタリングのカテゴリと対応するチェック内容 |
通常SIPのサーバポートはUDP 5060ポートが一般的に使用される。IP電話機を使用した基本接続シーケンスは次の通りである。
![]() |
| 図2 SIPプロトコルのリクエストをやりとりする様子 |
電話の接続手順を具体的にイメージしていただけると思うが、実際のメッセージの中身を見てみると、どのように音声符号化を行い、どのプロトコルで通信するかなど、メッセージの中で互いにネゴシエーションを行い、「もしもし、はいはい」の音声のやりとりに繋がっていく様子が分かる。
ネゴシエーションにはSDP(Session Description Protocol RFC2327)が使用される。具体的には発信者側からのINVITEリクエストメッセージで、メディアの種類(音声か映像かなど)、メディアを運ぶために使用するプロトコル、使用するポート番号などが明示される。
|
SDPから読み取れる情報 |
|
着信側では、発信者側からのコミュニケーション手段をSDP内部から認識して共通のディアタイプ(具体的にはコーデックの種類や送出周期など)があれば、その内容を[200 OK]にのせて応答する。実際のメッセージは次の通りである。
INVITE sip:2200@sip.netone.co.jp SIP/2.0
……(1)
|
| 図3 発側のINVITEメッセージの中身 |
SIP/2.0 200 Ok
|
| 図4 着側の 200 OKメッセージの中身 |
上記2つのメッセージから、以下の情報が読み取れる。
|
上のSIPメッセージから分かる情報 |
| (1) 2100番から2200番へのコール (2) 2100番は音声メディアG.711でRTP ポート番号24538 IPアドレス10.32.31.139 (3) 2200番は音声メディアG.711でRTP ポート番号26696 IPアドレス10.32.31.111 (4) 音声のパケット送出間隔は20msec |
では、実際の音声パケットがどのようにネットワーク上に流れていくのかを見てみたい。
| (3) 音声パケット化の仕組みとコーデック |
音声パケットはシグナリングプロトコルにかかわらず、ほぼRTP(real-time transport protocol RFC 1889/RFC 3350)を使い、音声情報をIPネットワーク上へ送出している。これは、リアルタイムストリームを運ぶためのプロトコルとしてIETFで標準化されている。
ほぼ全てのVoIP関連製品が、このRTPを使用して音声情報の送受信を行っている。音声パケット構成は以下のようにIP化されてネットワーク上へ送出されるが、Payload部分は使用するコーデックによって情報量が異なる。
一般的にVoIPの世界で使用されているのはG.729系で、IP電話などではG.711が多くなってきている。G.711はISDNでも使用されているコーデックであり音質は良いが、G.729と比較すると情報量が大きくなってしまう。G.729は圧縮率が高くかつ音質評価も良いコーデックである。それぞれ音声1チャンネル当たりの必要帯域は、G.711が64kbps、G.729で8kbpsとなっている。通常双方のコーデックは共に20msec間隔(間隔を変更することも可能)で送出される。実際の1パケット当たりの長さを算出してみる。
音声情報はアナログ信号である。音声をパケット化するためにはまずアナログ信号をデジタル信号処理しなければならない。ご存知の方が多いと思うが、アナログ音声信号をデジタル伝送する仕組みは以下の通りである。
![]() |
| 図5 アナログ音声信号をデジタル伝送する仕組み |
現状の電話交換網で使用されている符号化方式は、G.711(PCM)となっている。この符号化(送信側)と復号化(受信側)は同じ方式でないと会話をすることができないが、この2つの機能を併せてコーデックと呼んでいる。
VoIPのコーデックは次の2つが代表的なアルゴリムである。
|
G.711(PCM方式:PCM=パルス符号変調 :Pulse Code Modulation) |
|
|
G.729(CS-ACELP方式:Conjugate Structure Algebraic Code Excited Linear Prediction) |
|
|
この2つのコーデックをベースに話を進めるが、コーデックだけでは音声情報をデジタル化しただけでパケット化したことにはならない。
パケット化するために、DSP(Digital Signal Processor)といわれるチップがVoIP端末に埋め込まれている。この分野は特に専門ではないので詳細に触れることはできないが、アナログ信号である音声情報を符号化した後、膨大なデジタル信号をリアルタイムに処理するチップだ。
実際のパケット化では、RTPを使用して音声パケットとしてネットワークへ流れる。このRTPパケットの中にはペイロード種別(コーデック種別)、シーケンス番号(音声パケット化された順番)、タイムスタンプ(音声パケットの送信間隔)などの情報が含まれている。受信側ではこれらの情報をもとに音声パケットを元のアナログ音声へ変換する。
| (4) 音声IPパケットと帯域を算出してみよう |
実際の音声がIPパケット化されたときのパケットフォーマットは次のようになる。
![]() |
| 図6 モニタリングのカテゴリと対応するチェック内容 |
音声をIP化する場合にレイヤ3以上のオーバーヘッドとして必ず40byteが必要となる。実際にG.711、G.729でそれぞれ20msec周期で音声をパケット化することを前提としIPネットワークにおける必要帯域を算出してみる。
|
G.711の場合 |
| 1秒間に送出するパケット数:1000/20msec = 50pps 音声1チャンネル当たりの必要帯域64kbps = 50pps×Payloadサイズ Payloadサイズ =64000/50=1280bit=160byte 音声パケットの長さは200byteとなる。 |
|
G.729の場合 |
|
1秒間に送出するパケット数:50pps |
具体的にどちらのコーデックを使用するかについてであるが、音声サービスのみであればどちらのコーデックを選択しても問題はない。
ただし、FAXやVoIPキャリアとの相互接続を行うのであれば、G.711を選択しなければならない。しかし、複数拠点を持つ企業が、拠点間の回線帯域にLAN同様の10M/100Mを採用しているケースは稀である。実際は、128kbpsなどで結ばれている拠点が多いのが実情だ。
このような場合にG.711を選択してしまうと、音声帯域だけで回線を占有してしまうことになる。製品に左右されるが接続拠点毎に使用するコーデックを選択できる機能がある。この機能を利用して、狭回線帯域幅との接続にはG.729を、その他はG.711を採用することも可能だ。このような製品を使用するのであれば、運用ポリシーを統一するために、拠点間はG.729を、LANはG.711にすることをお勧めする。ただし、FAXについては拠点間であってもG.711による音声通信にしたい。
この他、帯域計算で留意すべき点は、レイヤ2のオーバーヘッドである。具体的にイーサネットサービスを考えた場合に、イーサネットフレームのオーバーヘッド(MACフレーム)を加味する必要があるためだ。
|
イーサネット帯域の算出項目 |
|
|
帯域計算の2つの例を以下に挙げる。
|
帯域計算例1:イーサネットフレームとしてVLANタグ付き |
|
|
帯域計算例1では、イーサネットフレームとしてVLANタグ付きのケースだが、合計28byteの帯域を確保する必要がある。
|
帯域計算例2:イーサネットフレームとしてVLANタグなし |
|
|
一方、帯域計算例2では、イーサネットフレームとしてVLANタグなしのケースである。こちらは、合計26byteの帯域が実際のイーサネット上で必要となる。
以上、VoIPの帯域計算で気を付けるべき点を列挙した。それぞれのケースによって、選択すべき方式が変わってくるので状況に合わせて、十分に考慮していただきたい。
第2回目の今回はIP電話の導入前に知っておくべき『シグナリングと音声パケットの制御』についてお伝えしました。いかがでしたでしょうか。次回はいよいよ導入段階の試験運用のポイントについて解説していきます。
| 関連記事 | |
| いま注目を集める「SIP」の最新トレンドと概要 【トレンド解説】 マイクロソフトがIP電話を面白くする!? 特集:10ギガビット・イーサネット大解剖 標準化の完了した最新イーサネット規格 【トレンド解説】 10ギガを超えて さらなる進化を続けるイーサネット 〜 10GBASE-T、Power over Ethernet、RPR 〜 連載 最適インフラビルダーからの提言 インフラソリューションはこう選べ |
|
| 「Master of IP Nestwork総合インデックス」 |
TechTargetジャパン
- 実機では測定できない性能を測定? (2012/2/7)
システムの完成前に、達成し得る性能値や必要なサーバリソースを知るには? その解となる「性能シミュレーション技法」を解説 - 性能チューニング個所の検討 (2012/1/30)
アプリのチューニングや環境増強で、どの程度改善が見込める? 今回からは「実際に活用できる性能対策」を解説します - 遅いところを直すだけでいいのですか? (2012/1/24)
負荷が集中したときの性能ボトルネックを改善するのに、アプリケーションサーバとDB、どちらを優先すべきでしょう? - cloudfoundry.comを使ってみよう (2012/1/19)
VMwareが提供するPaaSプラットフォーム「CloudFoundry」。注目を集めるこの基盤を活用してPaaSを構築!
|
|
キャリアアップ
スポンサーからのお知らせ
- - PR -
イベントカレンダー
- - PR -




