IPテレフォニヌの基瀎、基本原則、甚語、プロトコル



こんにちは、ハラゞテリ。 この蚘事では、IPテレフォニヌの基本原則を怜蚎し、最も䞀般的に䜿甚されるプロトコルを説明し、音声の゚ンコヌドずデコヌドの方法を瀺し、いく぀かの䞀般的な問題を分析したす。



IPテレフォニヌずは、デヌタ通信ネットワヌク、特にIPベヌスのネットワヌクIP-むンタヌネットプロトコルで実行される音声通信を指したす。 今日、IPテレフォニヌは、展開の容易さ、䜎い通話コスト、構成の容易さ、高品質の通信、および接続の比范セキュリティのために、埓来の電話ネットワヌクをたすたす眮き換えおいたす。 このプレれンテヌションでは、OSI参照モデルOpen Systems Interconnection基本参照モデルの原則を順守し、物理レベルずチャネルレベルからデヌタレベルで終わる「ボトムアップ」に぀いお説明したす。



」

OSIモデルずデヌタのカプセル化



IPテレフォニヌの原則



通話を行うず、音声信号は圧瞮されたデヌタパケットに倉換されたすこのプロセスに぀いおは、「パルス笊号倉調」および「コヌデック」の章で詳しく説明したす。 次に、パケットデヌタはパケット亀換ネットワヌク、特にIPネットワヌクを介しお送信されたす。 パケットが受信者に到達するず、パケットは元の音声信号にデコヌドされたす。 これらのプロセスは、倚数の補助プロトコルにより可胜です。その䞀郚に぀いおは埌で説明したす。



これに関連しお、デヌタ転送プロトコルは特定の蚀語であり、2぀のサブスクラむバヌがお互いを理解し、2぀のポむント間の高品質のデヌタ転送を保蚌したす。



埓来の電話ずは異なり



埓来の電話では、接続は電話亀換を䜿甚しお確立され、䌚話の目的のみを目的ずしおいたす。 ここでは、音声信号は専甚回線を介しお電話回線で送信されたす。 IPテレフォニヌの堎合、圧瞮されたデヌタパケットは特定のアドレスでグロヌバルたたはロヌカル゚リアネットワヌクに到着し、このアドレスに基づいお送信されたす。 この堎合、IPアドレスは既に䜿甚されおおり、固有の機胜ルヌティングなどがすべお䜿甚されおいたす。



同時に、IPテレフォニヌは、オペレヌタヌず加入者の䞡方にずっお安䟡な゜リュヌションです。 これは、次の事実によるものです。





䞊蚘ず合わせお、IPテレフォニヌは通信の品質を向䞊させるこずができたす。 これも、3぀の䞻な芁因のおかげで達成されたした。





IPテレフォニヌのおかげで、通話転送たたはスタンバむモヌドぞの転送はPBXの構成ファむル内のいく぀かのコマンドで実行できるため、ビゞヌ回線の問題は非垞に゚レガントに解決されたす。



物理局



物理レベルでは、ビットストリヌムが物理メディアを介しお察応するむンタヌフェむスを介しお送信されたす。 IPテレフォニヌは、既存のネットワヌクむンフラストラクチャにほが完党に䟝存しおいたす。 情報䌝達媒䜓ずしお、原則ずしお、ツむストペアカテゎリ5UTP5、シングルモヌドたたはマルチモヌドの光ファむバヌ、たたは同軞ケヌブルが䜿甚されたす。 したがっお、通信ネットワヌクの収束の原理は完党に実装されおいたす。



PoE



PoEPower Over EthernetテクノロゞヌIEEE 802.3 af-2003およびIEEE 802.3at-2009暙準を怜蚎するのは興味深いこずです。 その本質は、暙準のツむストペアケヌブルを介しおデバむスに電力を䟛絊する可胜性にありたす。 最新のIP電話、特にCisco Unified IP Phone 7900シリヌズには、PoEがサポヌトされおいたす。 2009幎の暙準によれば、デバむスは最倧25.5ワットの電流を受け取るこずができたす。



電源が䟛絊されるず、100BASE-TXケヌブルのツむストペアが2぀だけ䜿甚されたすが、䞀郚のメヌカヌは4぀すべおを䜿甚し、最倧51ワットの電力に達したす。 この技術は、Cat 5ケヌブルを含む既存のケヌブルシステムの倉曎を必芁ずしないこずに泚意しおください。



接続されたデバむスがPD受電デバむスかどうかを刀断するために、ケヌブルに2.8〜10 Vの電圧が印加され、接続されたデバむスの抵抗が蚈算されたす。 この抵抗が19-26.5kΩの範囲にある堎合、プロセスは次のステップに進みたす。 そうでない堎合は、2 ms以䞊の間隔でテストが繰り返されたす。



次に、より高い電圧を印加し、ラむンの電流を枬定するこずにより、受電装眮の電力範囲を怜玢したす。 これに続いお、48 Vがラむンに䟛絊されたす-電源電圧。 茻茳の継続的な監芖もありたす。



リンク局デヌタリンク局



IEEE 802仕様に埓っお、リンク局は2぀のサブレベルに分割されたす。



  1. MACMedia Access Control-物理局ずの盞互䜜甚を提䟛したす;
  2. LLC論理リンク制埡-ネットワヌク局を提䟛したす。


デヌタリンク局では、スむッチが機胜したす。これは、コンピュヌタヌネットワヌクの耇数のノヌドの接続ず、物理MACアドレス指定に基づくホスト間のフレヌムの分散を提䟛するデバむスです。



仮想ロヌカル゚リアネットワヌク仮想ロヌカル゚リアネットワヌクのメカニズムに蚀及する必芁がありたす。 このテクノロゞヌにより、物理特性に関係なく論理ネットワヌクトポロゞを䜜成できたす。 これは、IEEE 802.1Q芏栌で詳现に説明されおいるトラフィックのタグ付けによっお実珟されたす。





フレヌムフォヌマット



IPテレフォニヌのコンテキストでは、Voice VLANに泚意しおください。これは、IP電話で生成された音声トラフィックを他のデヌタから分離するために広く䜿甚されおいたす。 次の2぀の理由から、その䜿甚をお勧めしたす。



  1. 安党性 別の音声VLANを䜜成するず、音声パケットを傍受および分析する機䌚が枛りたす。
  2. 䌝送品質の改善。 VLANメカニズムを䜿甚するず、音声パケットの優先床を高く蚭定でき、その結果、通信の品質が向䞊したす。


ネットワヌク局



ネットワヌクレベルでは、ルヌティングがそれぞれ発生し、ネットワヌク局の䞻芁なデバむスはルヌタヌです。 特定のIPアドレスで受信者にデヌタが到達する方法を決定するのはここです。



䞻なルヌティング可胜なプロトコルはIPむンタヌネットプロトコルであり、これに基づいおIPテレフォニヌが構築され、䞖界芏暡のむンタヌネットが構築されたす。 たた、倚くのダむナミックルヌティングプロトコルがあり、その䞭で最も䞀般的なものはOSPFOpen Shortest Path Firstです。これは、通信チャネルの珟圚の状態に基づいた内郚プロトコルです。



珟圚たで、埓来のアナログ電話をIPネットワヌクに接続する特別なVoIPゲヌトりェむVoice Over IP Gatewayがありたす。 原則ずしお、トラフィックの远跡、ナヌザヌの承認、IPアドレスの自動配垃、垯域幅の管理を可胜にする組み蟌みルヌタヌもありたす。



VoIPゲヌトりェむの暙準機胜の䞭で





IPの送信で発生する可胜性のある遅延に察凊するには、優先順䜍蚭定プロトコルなどの远加ツヌルでそれを補完する必芁がありたす音声デヌタが通垞ず競合しないようにするため。

原則ずしお、これらの目的のために、ルヌタヌは䜎遅延キュヌむングLLQたたはクラスベヌスの重み付けキュヌむングCBWFQ-クラスベヌスの重み付け公平キュヌむングを䜿甚したす。

さらに、音声デヌタを送信にずっお最も重芁ず芋なすには、優先順䜍を付けたラベル付けスキヌムが必芁です。



トランスポヌト局



トランスポヌトレベルの特城は次のずおりです。





䞻なトランスポヌト局プロトコルは、TCP䌝送制埡プロトコル、UDPナヌザヌデヌタグラムプロトコル、RTPリアルタむムトランスポヌトプロトコルです。 IPテレフォニヌでは、UDPおよびRTPプロトコルが盎接䜿甚され、TCPずの䞻な違いは、信頌性の高いデヌタ配信を提䟛しないこずです。 電話通信は䌝送遅延に倧きく䟝存したすが、パケット損倱の圱響を受けにくいため、これは配信制埡TCPよりも受け入れられるオプションです。



UDP



UDPはIPネットワヌクプロトコルに基づいおおり、アプリケヌションプロセスにトランスポヌトサヌビスを提䟛したす。 TCPずの䞻な違いは、非保蚌配信の提䟛です。぀たり、デヌタを送受信するずきに確認は芁求されたせん。 たた、情報を送信するずきに、UDPモゞュヌル゜ヌスずレシヌバヌの間に論理接続を確立する必芁はありたせん。



RTP



RTPはトランスポヌト局プロトコルであるず芋なされおいるずいう事実にもかかわらず、原則ずしおUDP䞊で動䜜したす。 RTPを䜿甚しお、トラフィックタむプ認識、タむムスタンプ、䌝送制埡、パケットシヌケンス番号付けが実装されたす。



RTPの䞻な目的は、受信偎で凊理される各発信パケットにタむムスタンプを割り圓おるこずです。 これにより、デヌタを適切な順序で受信し、ネットワヌク䞊の䞍均䞀なパケット通過時間の圱響を軜枛し、オヌディオデヌタずビデオデヌタ間の同期を埩元できたす。



デヌタ局



OSIモデルの最埌の3぀のレベルは䞀緒に怜蚎されたす。 これらのレベルで発生するプロセスは密接に盞互接続されおいるため、このような結合は蚱容されたす。サブレベルぞの分割に関係なく、それらを蚘述する方が論理的です。



H.323



最初のステップは、1996幎に開発されたH.323プロトコルスタックを蚘述するこずです。 この芏栌は、パケット亀換ネットワヌクむンタヌネットでのオヌディオおよびビデオ通信甚の機噚、ネットワヌクサヌビス、および端末デバむスに぀いお説明しおいたす。 H.323暙準デバむスの堎合、音声共有が必芁です。



H.323の掚奚事項





非垞に重芁な事実に泚意しおください。掚奚事項は、物理的な䌝送媒䜓、トランスポヌトプロトコル、およびネットワヌクむンタヌフェむスを定矩するものではありたせん。 これは、H.323暙準をサポヌトするデバむスが、珟圚存圚するパケット亀換ネットワヌクで動䜜できるこずを意味したす。



H.323によるず、VoIP接続の4぀の䞻芁コンポヌネントは次のずおりです。







IPテレフォニヌのネットワヌクブロック図の䟋



H.323プロトコルスタックドキュメントからの抜粋
1.接続制埡ずアラヌム

1.a. H.225.0マルチメディアストリヌムシグナリングおよびパケット化プロトコルQ.931シグナリングプロトコルのサブセットを䜿甚。

1.b. H.225.0 / RAS登録、入堎、およびステヌタスの手順。

1.c. H.245マルチメディアの制埡プロトコル。

2.サりンド凊理

2.a. G.711トヌン呚波数のパルスコヌド倉調。

2.b. G.72264 kbpsでの7 kHzオヌディオコヌディング。

2.c. G.723.15.3および6.3 kbit / sのマルチメディア通信甚の2レヌト音声゚ンコヌダ。

2.d. G.728䜎遅延励起コヌディングを䜿甚した線圢予枬を䜿甚した16 kbps音声コヌディング。

2.d. G.729共圹構造の励起信号の代数的笊号化による線圢予枬を䜿甚した8 kbps音声信号の笊号化。

3.ビデオ凊理

3.a. H.26164 kbpsの芖聎芚サヌビス甚のビデオコヌデック。

3.b. H.263䜎速䌝送甚のビデオ信号の゚ンコヌド。

4.デヌタ転送のための電話䌚議

4.a. T.120゚ンドポむント間でデヌタを転送するためのプロトコルスタックT.123、T.124、T.125を含む。

5.マルチメディア䌝送

5.a. RTPリアルタむム転送プロトコル。

5.b. RTCPリアルタむム䌝送制埡プロトコル。

6.セキュリティ

6.a. H.235H.323ネットワヌク䞊のマルチメディア端末のセキュリティず暗号化。

7.远加サヌビス

7.a. H.450.1H.323の補足サヌビスを管理するための䞀般化された機胜。

7.b. H.450.2接続を第䞉者の電話番号に転送したす。

7.c. H.450.3コヌル転送。

7.d. H.450.4通話保留。

7.d H.450.5コヌルパヌク公園ずコヌルピックアップ

7..e。 H.450.6通話状態の着信コヌルの通知。

7.g. H.450.7埅機メッセヌゞの衚瀺。

7.h. H.450.8名前識別サヌビス。

7.i. H.450.9H.323ネットワヌクの接続終了サヌビス。






H.323ベヌスの接続セットアップスクリプト



SIPセッション開始プロトコル



SIPは、通信セッションを線成、倉曎、および終了するために蚭蚈されたシグナリングプロトコルです。 SIPはトランスポヌトテクノロゞヌに䟝存したせんが、接続の確立時にUDPを䜿甚するこずをお勧めしたす。 RTPを䜿甚しお音声およびビデオ情報自䜓を送信するこずをお勧めしたすが、他のプロトコルを䜿甚する可胜性は排陀されたせん。



SIPは、芁求ず応答ずいう2皮類のシグナリングメッセヌゞを定矩しおいたす。 6぀の手順もありたす。







SIPセッションスクリプト



コヌデック



オヌディオコヌデックは、デゞタルオヌディオデヌタを圧瞮たたは圧瞮解陀するプログラムたたはアルゎリズムであり、デヌタチャネルの垯域幅芁件を削枛したす。 IPテレフォニヌでは、G.729コヌデックによる倉換ず、A-lawalawおよびΌ-lawulawによるG.711圧瞮が珟圚最も䞀般的です。



G.729


G.729は、デヌタ損倱のある元の信号を圧瞮するコヌデックです。 G.729で芏定されおいる䞻なアむデアは、デゞタル化された信号自䜓ではなく、受信偎での埌続の合成に十分なパラメヌタスペクトル特性、れロを通過する遷移の数の送信です。 同時に、振幅や音色など、音声の基本的な特性はすべお保持されたす。



このコヌデックが蚭蚈されおいるチャネルの垯域幅は8 kbit / sです。 凊理されたG.729のフレヌム長は10 ms、サンプリング呚波数は8 kHzです。 これらのフレヌムのそれぞれに぀いお、数孊モデルのパラメヌタが決定され、その埌、コヌドの圢でチャネルに送信されたす。



G.729゚ンコヌディングを䜿甚する堎合、遅延は15ミリ秒で、そのうち5ミリ秒が予備バッファの充填に費やされたす。 たた、G.729コヌデックはプロセッサリ゜ヌスにかなり高い芁求を課しおいるこずに泚意しおください。



G.711


G.711は、コンパンディング以倖の圧瞮を必芁ずしない音声コヌデックであり、ダむナミックレンゞが制限されおいるチャネルの圱響を軜枛する方法です。 この方法の基瀎は、音質を維持しながら、高ボリュヌム領域の信号の量子化レベルの数を枛らすずいう原則です。 電話で広く䜿甚されおいる2぀の圧䌞方匏は、alawずulawです。



このコヌデックの信号は、64 kbit / sのストリヌムによっお提䟛されたす。 サンプリングレヌト-8ビット/秒で8000フレヌム。 音声品質は、G.729コヌデックを䜿甚するよりも䞻芳的に優れおいたす。



law


alawたたはA-lawは、情報が倱われたオヌディオデヌタを圧瞮するためのアルゎリズムです。 䞻にペヌロッパずロシアで䜿甚されおいたす。



信号xの堎合、alaw倉換は次のずおりです。



ここで、Aは圧瞮パラメヌタヌです通垞は87.7になりたす。



りル


ulawたたはΌ-lawは、情報の損倱を䌎うオヌディオデヌタ圧瞮アルゎリズムです。 䞻に日本ず北米で䜿甚されおいたす。



信号xのulaw倉換は次のずおりです。



ここで、北米および日本の暙準では、Όは2558ビットに等しくなりたす。



パルス笊号倉調PCM-パルス笊号倉調



パルス笊号倉調-䞀連の連続パルスの圢での連続関数の転送。



通信チャネルの入力で倉調信号を取埗するために、キャリア信号の瞬時倀が䞀定の呚期でADCによっお枬定されたす。 この堎合、1秒あたりのデゞタル化された倀の数サンプリングレヌトは、アナログ信号のスペクトルの最倧呚波数の2倍以䞊でなければなりたせん。



さらに、取埗された倀は、以前に受け入れられたレベルのいずれかに䞞められたす。 レベルの数は2のべき乗の倍数ずしおずらなければならないこずに泚意しおください。 決定されたレベル数に応じお、信号は特定のビット数で゚ンコヌドされたす。





信号量子化



この図は、4ビットを䜿甚したコヌディングを瀺しおいたす぀たり、アナログ信号のすべおの䞭間倀は、事前定矩された16レベルのいずれかに䞞められたす。 たずえば、時間がれロの堎合、信号は同様の方法で衚瀺されたす0111。



埩調䞭、れロず1のシヌケンスは、量子化レベルが倉調噚の量子化レベルに等しい埩調噚によっおパルスに倉換されたす。 その埌、これらのパルスに基づいおDACが信号を埩元し、平滑化フィルタヌが最終的に䞍正確性を排陀したす。



珟代の電話では、量子化レベルの数は100以䞊である必芁がありたす。぀たり、信号を゚ンコヌドできる最小ビット数は7です。



サヌビス品質-QoSの問題



TCP / IPスタックに基づいたネットワヌクでは、䌝送遅延の圱響を受けやすい高品質のトラフィックサヌビスはデフォルトでは提䟛されたせん。 TCPプロトコルを䜿甚する堎合、信頌できる情報配信の保蚌がありたすが、その転送は予枬できない遅延で実行できたす。 UDPは遅延を最小限に抑えるこずを特城ずしおいたすが、正しいパケット配信の保蚌はありたせん。



同時に、音声トラフィックの品質係数は䌝送の品質に匷く䟝存し、適切な品質を保蚌するメカニズムが実装されおいないネットワヌクでは、IPテレフォニヌの実装がナヌザヌの芁件を満たさない堎合がありたす。



サヌビス品質の䞻な指暙は、ネットワヌク垯域幅ず䌝送遅延です。 この堎合の遅延は、パケットが送信されおから受信されるたでの経過時間ずしお定矩されたす。



ネットワヌクの可甚性や信頌性などの特性もありたすサヌビスレベルを長時間監芖した結果、たたは䜿甚率によっお評䟡されたす。



通信の品質を向䞊させるために、次のメカニズムが䜿甚されたす。



  1. 再ルヌティング。 通信チャネルの1぀が過負荷になるず、バックアップルヌトを介した配信が可胜になりたす。
  2. 接続䞭の通信チャネルリ゜ヌスの予玄。
  3. トラフィックの優先順䜍付け。 重芁床に応じおパッケヌゞをマヌクし、ラベルに基づいおサヌビスを実行できたす。


前述のように、音声トラフィックは䌝送遅延に非垞に敏感です。 最倧遅延時間は400ミリ秒を超えおはなりたせんこれには、端末での情報凊理の期間も含たれたす。 遅延には䞻に2぀のタむプがありたす。



-音声ゲヌトりェむたたは端末機噚で情報を゚ンコヌドする際の遅延。 音声凊理および倉換アルゎリズムを改善するこずにより削枛されたす。

-䌝送ネットワヌクによっお導入された遅延。 ネットワヌクむンフラストラクチャを改善するこずにより、特にルヌタヌの数を枛らし、高速チャネルを䜿甚するこずにより、削枛されたす。





IPテレフォニヌの遅延の原因



ゞッタ



IPテレフォニヌに特有のもう1぀の珟象は、ゞッタ、぀たりパケットの配信におけるランダムな遅延です。



ゞッタは次の3぀の芁因によっお決たりたす。





ゞッタを凊理する最も䞀般的に䜿甚される方法は、䞀定数のパケットを保存するゞッタバッファです。



通垞、接続の存続期間党䜓にわたるバッファヌ長の動的調敎が提䟛されたす。 ヒュヌリスティックアルゎリズムを䜿甚しお、最適な長さを遞択したす。



ゞッタバッファ


䞍均等なパケット到着率を補正するために、䞀時的なパケットストレヌゞ、たたはいわゆるゞッタバッファが受信偎に䜜成されたす。 そのタスクは、着信パケットをタむムスタンプに埓っお正しい順序で収集し、正しい間隔で正しい順序でコヌデックに発行するこずです。





ゞッタバッファ



受信VOIPデバむスのバッファサむズは、動䜜䞭に蚈算されるか、蚭定で匷制的に蚭定されたす。 䞀方で、茞送遅延を増加させないように、倧きすぎるこずはできたせん。 䞀方、バッファサむズが小さいず、IPネットワヌクの遅延時間が原因でパケット損倱が発生したす。



これは、むンタヌネットプロバむダヌずIPテレフォニヌナヌザヌの䞻な矛盟の1぀です。 プロバむダヌの芳点から芋るず、すべおのパケットはサブスクラむバヌに配信されたす。぀たり、損倱はありたせん。 VoIPデバむスの芳点から芋るず、パケットの到着間の時間差はゞッタバッファを倧幅に超えおいたす。 したがっお、実際には損倱がありたす。 実際には、1を超える損倱は特定の䞍快感を匕き起こしたす。 2では、䌚話は困難です。 4を超える倀では、䌚話はほずんど䞍可胜です。



ゞッタバッファサむズ


i番目のパケットのランダム䌝搬遅延Jiは、次の匏で決定できたす。



ここで

Di-i番目のパケットの予想到着時間からの偏差。

i番目のパケットDiの予想到着時間からの偏差は、次の匏で決定されたす。



ここで

RはRTPタむムスタンプでのパケット到着時間、

Sは、パケットから取埗したRTPタむムスタンプです。



前の2぀に基づいお、5番目のパケットのランダム䌝搬遅延の予想サむズを蚈算する䟋を次に瀺したす。



J4 = 10ミリ秒ずしたす。 R4 = 10、R3 = 11、S4 = 6、S3 = 5、D5は10-11-6-5=-2。



珟圚の䟋では、平均しお、1぀のパケットの䌝搬時間のランダムな遅延は10ミリ秒になりたすより正確には、䞊蚘の匏に埓っお蚈算できたす。 次に、パケットが砎棄されないようにするには、ゞッタバッファのサむズを10ミリ秒にする必芁がありたす。



必芁なゞッタバッファのサむズをメガバむト単䜍で決定するには、結果の倀に100 Mbps-平均ネットワヌク垯域幅を乗算したす10•10 ^ -3•100 = 128 kb。



ゞッタバッファのサむズは、ネットワヌク内の通過時間の倉動よりも倧きくする必芁がありたす。 たずえば、10パケットの堎合、通過時間が5〜10ミリ秒の間で倉動する堎合、パケットが倱われないように、バッファは少なくずも8ミリ秒でなければなりたせん。 バッファヌがさらに倧きい堎合たずえば、12ミリ秒であれば、倱われたパケットを再芁求するメカニズムが機胜するようになりたす。



電話ネットワヌク展開゜リュヌション



アスタリスク







アスタリスクは、VoIP通話ず、IP電話ず埓来の公衆亀換電話網の間で行われた通話の䞡方を切り替えるこずができる゜フトりェアベヌスのPBXです。



サポヌトされるプロトコルIAX、SIP、H.323、スキニヌ、UNIStim。

サポヌトされおいるコヌデックG.711ulaw and alaw、G.722、G.723、G.729、GSM、iLBC、LPC-10、Speex。



アスタリスクは、ラむセンスに関係なくむンストヌルできる動的なオヌプン゜ヌス゜フトりェアです。 これにより、この゜フトりェアPBXは䞭小䌁業にずっお魅力的です。 ネットワヌク内のサブスクラむバヌの数は2000に達するこずができ、サヌバヌの容量によっおのみ制限されたす。



アスタリスクのもう1぀の利点は、柔軟に構成できるこずです。 必芁な機胜はすべお既に実装されおいるか、倚倧な時間ず費甚をかけずに独立しお远加できたす。 原則はこれに貢献したす1぀のタスク-1぀の゜フトりェアモゞュヌル。



シスコやアバむアなどのベンダヌの゜リュヌションず比范するず、アスタリスクには魅力的な展開コストもありたす。 実際、すべおのコストは、電話ず、必芁なネットワヌク負荷を提䟛できるサヌバヌを賌入するだけで匕き䞋げられたす。 プログラム自䜓は完党に無料です。



Cisco Unified Communication ManagerCallManager







CallManagerは、最倧30,000人の加入者を持぀倧芏暡なネットワヌクに適しおいたす。この゜フトりェアずハ​​ヌドりェアの耇合䜓は、信頌性の高い操䜜を提䟛し、コヌル転送や音声メニュヌなどの倚くのパラメヌタヌを構成できたす。小芏暡オフィス向けの「ラむト」゚クスプレスバヌゞョンもありたす。



Cisco CallManagerの利点の䞭で、たず第䞀に、シスコからの有名なテクニカルサポヌトに泚目する䟡倀がありたす。適切なレベルのサヌビス契玄があれば、セットアップに関する質問から機噚の故障に至るたでの問題はほが瞬時に解決されたす。したがっお、Cisco CallManagerは、倚額のお金を払うだけでなく、最高品質のサヌビスを受ける䌁業に適しおいたす。



アバむアIPオフィス







IPオフィスは、䞭芏暡の電話ネットワヌクに適しおいたす。ここでのサブスクラむバの数は、サヌバヌの容量だけでなく、賌入したラむセンスの数によっおも制限されたす。拡匵カヌド、䜿甚枈みアプリケヌションなど、ほずんどすべおのラむセンスが必芁です。これにより、特定の䞍䟿が生じる可胜性がありたす。



構成は倚くのプログラムで実行できたすが、最も䞀般的で䜿いやすいのはAvaya IP Office Managerです。 Avaya Terminal Emulatorを䜿甚しおコン゜ヌルから制埡するこずもできたす。



䞀般に、Avaya補品は1぀のIPオフィスに限定されたせん。 2009幎に別の有名なメヌカヌNortelず合䜵したAvayaは、IPテレフォニヌ機噚垂堎のリヌダヌずしお認められおいたす。



トピックで読むこずができるもの






All Articles