パチンコ まとめ の まとめk8 カジノIP電話を使うなら知っておきたいパケット制御仮想通貨カジノパチンコスーパー 海 物語 in 沖縄 3
リゼロ 価格k8 カジノ シグナリングと音声パケットの制御
パチンコ 三重 「連載：VoIPに耐えるネットワーク構築」では、企業が自社の電話設備を『拠点間VoIP』や『IP電話』などを導入してIP化していく際に、どのように技術的観点から調査し設計導入を行っていけばよいのかを考察している。第1回「IP電話導入のためのネットワーク必要条件」では、通信料金、既存ネットワーク環境、運用保守などの“ユーザー環境”のベースとなるネットワークがどうなっていれば、新規投資が抑えられ、“最大の効果”が得られるのかを考えた。
連載第2回目となる今回は、さらに深い考察のため、実際にVoIPがどのような技術を基礎として実現されているかを見ていきたい。
IP電話サービス、IPセントレックス、IP-PBX、IP-Telephonyなどいろいろな“言葉”が飛び交っているが、基本は通信相手との接続制御と通信メディアとしての音声情報の伝達をどのようにして行われるのか、このことをよく理解しておくことが大切である。要素技術として接続制御を行うシグナリング部分と音声などのリアルタイム情報がどのようにパケット化されているのかについて解説する。
前者のシグナリングについてはいくつかの標準技術や、メーカーによる独自方式が存在する。後者の音声トラフィックについては、標準技術で実現されている。では、具体的に見ていこう。
シグナリングと音声パケットの制御：目次
（1） VoIPで使用されるシグナリングプロトコルとは？
（2） SIPプロトコルを読み解く
（3） 音声パケット化の仕組みとコーデックとは？
（4） 音声IPパケットと帯域を算出してみよう
（1） VoIPで使用されるシグナリングプロトコルとは？
最初にVoIPで使用されるシグナリングプロトコルについて見てみる。冒頭で触れたとおり標準と独自方式が存在する。独自方式については、それらを規定したメーカーからの解説に任せたい。ここでは、標準方式を中心にお話ししたい。
標準方式の代表的な方式には、H.323、 MGCP、 SIPの3方式が挙げられる。ITU-T側で考えられたものがH.323、IETF側で考えられたものにMGCP、 SIPなどがある。それぞれのプロトコルの特徴は表1のとおりだ。
表1にも記載してあるが、今後VoIPキャリアが採用するプロトコルはSIPであり、携帯端末にしても同様であることがIT関連ニュースなどでも見られる状況となってきた。
（2） SIPプロトコルを読み解く
VoIPを導入すると、従来のネットワークと比較し大きな違いとなるのは何か？ 答えは、内線側の通信方式である。従来のPBXは公衆網と内線側は別プロトコルで、内線側は各社独自方式が用いられ、差別化が図られてきた。これに対してVoIPでは網から端末レベルまで標準化されたプロトコル（技術）にすることが可能となってくる。特定のメーカーに依存するのではなく、ユーザー側の製品選択の幅が広がり、音声ネットワークを構築する際の自由度も大きくなってくることが予想される。
もちろん、端末レベルまでシームレスな環境を望むには相互接続検証がまず大切であり、この行為を避けて実現させることは現状では不可能に近い。しかし、同一基礎技術をベースにすることで相互接続性をかなり高められる。
現在各キャリアが提供する法人向けIP電話サービスで使用されるシグナリングプロトコルはSIPである。従来は先に触れたとおり、外側（外線や中継線）と内側（内線側）は別のプロトコル（技術）が用いられていたが、それらをIP化するのであれば単に伝送路をIP化するだけでなく、端末レベルまでサービス授受可能な形態を目指すべきである。
既存PBXと同様に内線は独自方式でVoIPキャリアとの接続にはPSTN-GWで接続するか、その部分だけSIPに対応するような製品も存在する。先に述べたとおり、シームレスな環境になることを踏まえ内外線ともにSIPに対応できるものが望ましい。
SIPはセッションの確立・変更・切断（終了）を規定している。具体的なSIPメッセージのやりとりはメソッド（リクエスト）とレスポンスコード（応答）で行われ、セッションコントロールを行っている。各メソッドとレスポンスコードの一覧は次の通りである。
メソッド INVITE セッション開始 ACK セッション確立 CANCEL 未確立セッション取り消し BYE セッション終了 REGISTER contactアドレス登録 OPTIONS 機能問い合わせ（UAが持つ機能確認） REFER 転送 INFO セッション内での情報交換 SUBSCRIBE ユーザーの情報伝達要求 NOTIFY ユーザーの情報伝達 PRACK 信頼性のある暫定応答 UPDATE セッション情報の更新 MESSAGE メッセージ送信
上記メソッドの中にSIPヘッダを用いてリクエストやレスポンスの詳細情報を提供する。
レスポンスコード 1xx（100〜199） 経過情報（暫定応答） 2xx（200〜299） 成功 3xx（300〜399） 転送 4xx（400〜4xx） クライアントエラー 5xx（500〜5xx） サーバエラー 6xx（600〜6xx） グローバルエラー（リトライ不可）
これらのSIPメッセージはUDPを用いて行われる。SIPのプロトコルスタックは以下のようになっている。
通常SIPのサーバポートはUDP 5060ポートが一般的に使用される。IP電話機を使用した基本接続シーケンスは次の通りである。
電話の接続手順を具体的にイメージしていただけると思うが、実際のメッセージの中身を見てみると、どのように音声符号化を行い、どのプロトコルで通信するかなど、メッセージの中で互いにネゴシエーションを行い、「もしもし、はいはい」の音声のやりとりに繋がっていく様子が分かる。
ネゴシエーションにはSDP（Session Description Protocol RFC2327）が使用される。具体的には発信者側からのINVITEリクエストメッセージで、メディアの種類（音声か映像かなど）、メディアを運ぶために使用するプロトコル、使用するポート番号などが明示される。
SDPから読み取れる情報 メディア（音声・映像・テキスト）は何を使用するのか 音声メディアであれば符号化方式は何を使用するのか 音声パケットを運ぶプロトコルには何を使用するのか使用するポート番号や音声パケット送出周期
着信側では、発信者側からのコミュニケーション手段をSDP内部から認識して共通のディアタイプ（具体的にはコーデックの種類や送出周期など）があれば、その内容を［200 OK］にのせて応答する。実際のメッセージは次の通りである。
INVITE sip:2200@sip.netone.co.jp SIP/2.0 ……（1）From: <sip:2100@sip.netone.co.jp>;tag=8b1f200a-13c4-402bee2a-5e04a-72af ……（1）To: <sip:2200@sip.netone.co.jp> Call-ID: 105552a4-8b1f200a-13c4-402bee2a-5e046-2a89@sip.netone.co.jp CSeq: 1 INVITE Via: SIP/2.0/UDP 10.32.31.139:5060;branch=z9hG4bK-402bee2a-5e04c-56bc Max-Forwards: 70 Supported: 100rel,replaces,timer Contact: <sip:2100@10.32.31.139> Session-Expires: 120 Allow: INVITE,ACK,OPTIONS,CANCEL,BYE,REFER,NOTIFY,PRACK Content-Type: application/SDP Content-Length:261 v=0 o=2100 274027172 274027172 IN IP4 10.32.31.139 ……（2）s=Phone Call i=SIP-2000 SANYO 2003 c=IN IP4 10.32.31.139 t=0 0 m=audio 24538 RTP/AVP 0 18 101 ……（2）a=rtpmap:0 PCMU/8000 ……（2）a=rtpmap:18 G729/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20……（4）図3 発側のINVITEメッセージの中身SIP/2.0 200 OkVia: SIP/2.0/UDP 10.32.31.139:5060;branch=z9hG4bK-402bee2a-5e15a-419aFrom: <sip:2100@sip.netone.co.jp>;tag=8b1f200a-13c4-402bee2a-5e04a-72afTo: <sip:2200@sip.netone.co.jp>;tag=atelo-4ae1-4c3db1eCall-ID: 105552a4-8b1f200a-13c4-402bee2a-5e046-2a89@sip.netone.co.jpCSeq: 1 INVITEContent-Length: 235Content-Type: application/sdpAllow: INVITEAllow: ACKAllow: CANCELAllow: BYEAllow: REFERAllow: NOTIFYAllow: INFOAllow: REGISTERAllow: SUBSCRIBESupported: timerSession-Expires: 120;refresher=uasRequire: timerContact: sip:2200@10.32.31.135;transport=udp v=0o=2200 274026860 274026860 IN IP4 10.32.31.111 ……（3）s=Phone Calli=SIP-2000 SANYO 2003c=IN IP4 10.32.31.111 ……（3）t=0 0m=audio 26696 RTP/AVP 0 101 ……（3）a=rtpmap:0 PCMU/8000 ……（3）a=rtpmap:101 telephone-event/8000a=fmtp:101 0-15a=ptime:20 ……（4）図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パケット当たりの長さを算出してみる。
音声情報はアナログ信号である。音声をパケット化するためにはまずアナログ信号をデジタル信号処理しなければならない。ご存知の方が多いと思うが、アナログ音声信号をデジタル伝送する仕組みは以下の通りである。
現状の電話交換網で使用されている符号化方式は、G.711（PCM）となっている。この符号化（送信側）と復号（受信側）は同じ方式でないと会話をすることができないが、この2つの機能を併せてコーデックと呼んでいる。
VoIPのコーデックは次の2つが代表的なアルゴリムである。
G.711（PCM方式：PCM＝パルス符号変調 ：Pulse Code Modulation） サンプリング周波数：8kHz 情報量：64kbps／チャンネル 原理遅延：0.125msec 品質：MOS値で4.10 G.729（CS-ACELP方式：Conjugate Structure Algebraic Code Excited Linear Prediction） サンプリング周波数：8kHz 情報量：8kbps／チャンネル フレーム長：10msec 原理遅延：15msec 品質：MOS値で3.9
この2つのコーデックをベースに話を進めるが、コーデックだけでは音声情報をデジタル化しただけでパケット化したことにはならない。
パケット化するために、DSP（Digital Signal Processor）といわれるチップがVoIP端末に埋め込まれている。この分野は特に専門ではないので詳細に触れることはできないが、アナログ信号である音声情報を符号化した後、膨大なデジタル信号をリアルタイムに処理するチップだ。
実際のパケット化では、RTPを使用して音声パケットとしてネットワークへ流れる。このRTPパケットの中にはペイロード種別（コーデック種別）、シーケンス番号（音声パケット化された順番）、タイムスタンプ（音声パケットの送信間隔）などの情報が含まれている。受信側ではこれらの情報をもとに音声パケットを元のアナログ音声へ変換する。
（4） 音声IPパケットと帯域を算出してみよう
実際の音声がIPパケット化されたときのパケットフォーマットは次のようになる。
音声を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
音声1チャンネル当たりの必要帯域 8kbps＝50pps×Payloadサイズ
Payloadサイズ＝ 8000／50 ＝160bit＝20byte
音声パケットの長さは60byteとなる。
具体的にどちらのコーデックを使用するかについてであるが、音声サービスのみであればどちらのコーデックを選択しても問題はない。
ただし、FAXやVoIPキャリアとの相互接続を行うのであれば、G.711を選択しなければならない。しかし、複数拠点を持つ企業が、拠点間の回線帯域にLAN同様の10M/100Mを採用しているケースは稀である。実際は、128kbpsなどで結ばれている拠点が多いのが実情だ。
このような場合にG.711を選択してしまうと、音声帯域だけで回線を占有してしまうことになる。製品に左右されるが接続拠点毎に使用するコーデックを選択できる機能がある。この機能を利用して、狭回線帯域幅との接続にはG.729を、その他はG.711を採用することも可能だ。このような製品を使用するのであれば、運用ポリシーを統一するために、拠点間はG.729を、LANはG.711にすることをお勧めする。ただし、FAXについては拠点間であってもG.711による音声通信にしたい。
この他、帯域計算で留意すべき点は、レイヤ2のオーバーヘッドである。具体的にイーサネットサービスを考えた場合に、イーサネットフレームのオーバーヘッド（MACフレーム）を加味する必要があるためだ。
イーサネット帯域の算出項目 プリアンブル：7byte（フレーム送信の開始を通知し、同期をとるタイミングを与えるための信号） SFD：1byte（Start Frame Delimiter：フレーム開始部） 送信先MACアドレス：6byte 送信元MACアドレス：6byte プロトコル：2byte（VLANの場合は802.1qに含まれる） 802.1q：4byte（VLANを使用した場合） FCS：4byte
帯域計算の2つの例を以下に挙げる。
帯域計算例1：イーサネットフレームとしてVLANタグ付き プリアンブル：7byte SFD：1byte 送信先MACアドレス：6byte 送信元MACアドレス：6byte 802.1q：4byte（VLANを使用した場合） FCS：4byte
帯域計算例1では、イーサネットフレームとしてVLANタグ付きのケースだが、合計28byteの帯域を確保する必要がある。
帯域計算例2：イーサネットフレームとしてVLANタグなし プリアンブル：7byte SFD：1byte 送信先MACアドレス：6byte 送信元MACアドレス：6byteプロトコル：2byte FCS：4byte
一方、帯域計算例2では、イーサネットフレームとしてVLANタグなしのケースである。こちらは、合計26byteの帯域が実際のイーサネット上で必要となる。
以上、VoIPの帯域計算で気を付けるべき点を列挙した。それぞれのケースによって、選択すべき方式が変わってくるので状況に合わせて、十分に考慮していただきたい。
第2回目の今回はIP電話の導入前に知っておくべき『シグナリングと音声パケットの制御』についてお伝えしました。いかがでしたでしょうか。次回はいよいよ導入段階の試験運用のポイントについて解説していきます。
「次回」へ
「VoIPに耐えるネットワーク構築」バックナンバー IP電話でQoSを確保するためのチェックポイントIP電話を使うなら知っておきたいパケット制御IP電話導入のためのネットワーク必要条件仮想通貨カジノパチンコjfa 新卒