音声とユニファイド コミュニケーション : Cisco Unified Communications Manager(CallManager)

ケース スタディ IP テレフォニーの導入: オーストラリア カトリック大学

2015 年 11 月 26 日 - 機械翻訳について
その他のバージョン: PDFpdf | 英語版 (2015 年 8 月 22 日) | フィードバック


目次


概要

オーストラリア学術研究ネットワーク(AARNet)は、37 のオーストラリアの大学とオーストラリア連邦科学産業研究機構(CSIRO)を相互接続する国際的な高速 IP ネットワークです。

AARNet はデータネットワークとして最初に構築されましたが、早い 2000 年以来の Voice over IP (VoIP)を運びました。 現在展開される大学と CSIRO Private Automatic Branch eXchange (PABX)間の VOIPコールを伝送する VOIPネットワークはトールバイパス ソリューションです。 それはまたホップオフ 費用効率の良いポイントに PSTN を最高で可能にする Public Switched Telephone Network (PSTN) ゲートウェイを提供します。 たとえば、メルボルンの PABX 電話からのシドニーの PSTN 電話へのコールはメルボルンからのシドニー PSTN ゲートウェイへの VoIP として伝送されます。 それは PSTN にそこに接続されます。

Australian Catholic University (ACU)は AARNet に接続する大学の 1 つです。 遅い 2000 年に、ACU は 6 つの大学構内を渡るおよそ 2,000 IP 電話を展開した IPテレフォニー配置を始めました。

このケーススタディは ACU IPテレフォニー配置をカバーします。 プロジェクトは完了します。 ただしネットワークが他の大学が ACU の足音で続くときスケーリングすることである場合、AARNet バックボーンで当たるべき重要な建築問題があります。 この資料はこれらの問題を記述し、さまざまなソリューションを提案し、説明したものです。 ACU IPテレフォニー配置は調節された以降である可能性が高いです最終的な推奨されるアーキテクチャと一直線に落ちるために。

注: ディーキン大学は IP テレフォニーを展開する最初のオーストラリア の 大学でした。 ただし、ディーキン大学は IP テレフォニー トラフィックを運ぶのに AARNet を使用しません。

AARNet

オーストラリア の 大学および CSIRO は Australian Vice-Chancellors' Committee (AVCC)によって 1990 年に AARNet を構築しました。 オーストラリア インターネット トラフィックの99%最初 の 数年の間に創設メンバーにありました。 わずか商業トラフィックは第三およびリサーチ セクターを持つ密接なアソシエーションがあった組織からありました。 遅い 1994 年までにトラフィック総量の 20%に増加する非AARNet userbase によって使用して下さい。

AVCC は 1995 年の 7 月の Telstra に AARNet の商業客層を販売しました。 このイベントは結局 Telstra BigPond になるべきだったものが引き起こ。 これオーストラリアのインターネットの商業および私用 使用の刺激されたそれ以上の増加。 知的 財産および専門知識の転送はオーストラリアのインターネットの開発という結果に終りました。 さもなければ、これはそのような急速なレートに発生しなかろう。

AVCC は早い 1997 年に AARNet2 を開発しました。 それは制限される Cable & Wireless Optus の契約の下で高帯域幅 ATM リンクおよびインターネットサービスを雇うオーストラリアのインターネットのそれ以上の洗練でした。 AARNet2 必要条件を満たす CWO による IP サービスの急速 な 展開は AARNet からのナレッジおよび専門知識の転送が一部には原因でした。

ACU

ACU は 1991 年に設立された公立大学です。 大学におよそ 10,000 人の学生および 1,000 担当者があります。 オーストラリアの東海岸に 6 つのキャンパスがあります。 この表は ACU キャンパスおよび場所を示したものです:

キャンパス 都市 State
マウント St Mary Strathfield New South Wales (NSW)
MacKillop 北シドニー New South Wales (NSW)
パトリック メルボルン ビクトリア(VIC)
アクィナス バララット ビクトリア(VIC)
Signadou キャンベラ Australia Capital Territory (ACT)
McAuley ブリスベーン Queensland (QLD)

ACU は Telstra スペクトル(Centrex)ソリューションにこのケーススタディが記述する IPテレフォニーソリューションのロールアウトの前に頼りました。 IP テレフォニーへの移動はコストを削減する欲求によって主に駆動されました。

CSIRO

CSIRO にオーストラリアで多数のサイトでおよそ 6,500 担当者があります。 農業、鉱物、エネルギー、製造、通信、構築、健全性および環境のようなエリアの CSIRO 行ないリサーチ。

CSIRO は VoIP のために AARNet を使用する最初の組織でした。 組織はこのエリアでできていた初期の作品を開拓しました。

AARNet

AARNet バックボーンはあらゆる大学 IPテレフォニー配置の重要なコンポーネントです。 それは音声 エリアの 2 人の主要なサービスを大学の相互接続に与えます:

  • VoIP 音声に適切な Quality of Service (QoS)の保証を用いるリアルタイム転送 プロトコル(RTP)パケットの転送する

  • 国中の PSTN への低価格 hopoff ポイント

このセクションはこれらのサービスをどのように提供するか AARNet 現在のアーキテクチャを記述し。 それはまたより多くの大学が IPテレフォニーソリューションを展開すると同時に起こるいくつかのスケーラビリティの問題の輪郭を描きます。 最終的には、それはこれらのスケーラビリティの問題のための可能 な 解決策を論議します。

AARNet トポロジー

AARNet は各状態の単一 POP (Point of Presence)で構成されています。 POPs は地域 ネットワーク オペレーション(RNOs)と言われます。 大学はそれぞれ状態の RNO に接続されます。 RNOs は Optus ATM PVC のフル メッシュによってそれから相互接続されます。 ともにそれらは AARNet を構成します。

典型的な RNO は Cisco 1 LS1010 ATM スイッチおよび 1 ATM接続のルータで構成されています。 RNO ルータは E3 マイクロウェーブアクセスを渡る単一 ATM PVC によって各大学のルータに接続します。 各 RNO ルータはまた Optus ATMネットワークが他のすべての RNOs に提供する ATM PVC のフル メッシュを備えています。 このダイアグラムはネットワークの一般の AARNetトポロジーを表します:

/image/gif/paws/13913/60550.gif

トポロジーへ多数の例外があります。 そのうちのいくつかは音声観点から重要です。 これらはいくつかの例外です:

  • ビクトリアの RNO は PVC の代りに RNO に大学を接続するのに Classical IP over ATM (RFC 1577)を使用します。

  • 郊外の大学はフレーム リレーか ISDN によって RNO に戻って一般的に接続されます。

  • いくつかの大きい大学は RNO に戻る複数のリンクがあります。

この表は現在 RNO がある領域および状態を示したものです。 表はオーストラリア地理学についてよくわからない読者のための首都が含まれています。

State 首都 RNO か。 キャンパス接続
ニュー・サウス・ウェールズ シドニー はい 今後、定義予定。
ビクトリア メルボルン はい 今後、定義予定。
クイーンズランド ブリスベーン はい 今後、定義予定。
南 オーストラリア アデレード はい 今後、定義予定。
西 オーストラリア パース はい 今後、定義予定。
オーストラリア首都特別地域 キャンベラ はい 今後、定義予定。
北方領土 ダーウィン いいえ --
タスマニア ホーバート いいえ --

Quality of Service

AARNet の一部は既に VoIP トールバイパス プロジェクトの結果として音声のために QoS 対応です。 QoS は遅延 および ジッターを最小に し、パケットロスを除去するこれらの機能を提供して音声トラフィックに必要です:

  • ポリシング—信頼できないソースからの音声トラフィックの下でマークして下さい。

  • キューイング—音声はリンク輻輳の間に遅延を最小に する他のすべてのトラフィック上の優先順位を与える必要があります。

  • Link Fragmentation and Interleaving (LFI) —データパケットはフラグメント化する低速リンクで入れ込む必要があり、音声パケット。

トラフィックはきちんと音声パケットのポリシングを行ない、キューに入れるために分類する必要があります。 このセクションは分類が AARNet でどのように行われるか記述します。 それに続く章はポリシングおよびキューイング インプリメンテーションを記述します。

分類

すべてのトラフィックが同じ QoS を得ません。 トラフィックはこれらのカテゴリーに選択式に QoS を提供するために分類されます:

  • データ

  • 既知および信頼されたソースからの音声

  • 未知のソースからの音声

信頼されたデバイスだけ AARNet の良質 QoS を与えられます。 これらのデバイスは IP アドレスによって識別される主にゲートウェイです。 Access Control List (ACL)が音声のこれらの信頼されたソースを識別するのに使用されています。

access-list 20 permit 192.168.134.10 
access-list 20 permit 192.168.255.255

IP 優先順位がデータトラフィックと音声トラフィックを区別するのに使用されています。 音声に 5.の IP 優先順位があります。

class-map match-all VOICE
match ip precedence 5

信頼されたソースからのパケットを識別するために前例を結合して下さい。

class-map match-all VOICE-GATEWAY
match class-map VOICE
match access-group 20

未知のソースからの音声パケットを識別するのに同じプリンシパルを使用して下さい。

class-map match-all VOICE-NOT-GATEWAY
match class-map VOICE
match not access-group 20

ポリシング

信頼できない ソースからの音声トラフィックはトラフィックがインターフェイスに到着するときの下で分類され、マークされます。 これら二つの例はどのようなトラフィック 所定のインターフェイスに着くと期待されるかポリシングがどのようにによって実行されたか示します:

ルータはダウンストリーム信頼された音声ソースがある場合信頼できない 音声パケットを探し、0 に IP 優先順位を変更します。

policy-map INPUT-VOICE
class VOICE-NOT-GATEWAY
set ip precedence 0

interface FastEthernet2/0/0
description Downstream voice gateways 
service-policy input INPUT-VOICE

ルータはダウンストリーム既知 音声ソースがない場合音声パケットを探し、0 に IP 優先順位を変更します。

policy-map INPUT-DATA
class VOICE
set ip precedence 0

interface FastEthernet2/0/1
description No downstream voice gateways
service-policy input INPUT-DATA

無音声キューイング

AARNet のすべての VoIP は最近までトールバイパスでした。 この条件は比較的少数の VoIP エンドポイントという結果に終ります。 現在のキューイング設計は VOIPデバイス ダウンストリームおよびインターフェイスがあるインターフェイスの間で区別します。 このセクションは非 VoIP インターフェイスで並べることを論議します。

無音声インターフェイスは均等化キューイング (WFQ)か重み付けランダム早期検出 (WRED)のために設定されます。 これらはインターフェイスで直接設定することができます。 ただし所定のインターフェイス型のキューイング機構を変更することを容易にするため、キューイング機構はポリシーマップによって適用するです。 インターフェイスの種類毎に 1 つのポリシーマップがあります。 これはすべてのキューイング機構がすべてのインターフェイスでサポートされないというファクトを反映します。

policy-map OUTPUT-DATA-ATM
class class-default 
fair-queue

policy-map OUTPUT-DATA-VIP-ATM
class class-default
random-detect

policy-map OUTPUT-DATA-ETHERNET
class class-default 
fair-queue

policy-map OUTPUT-DATA-VIP-ETHERNET
class class-default 
random-detect

policy-map OUTPUT-DATA-SERIAL
class class-default 
fair-queue

policy-map OUTPUT-DATA-VIP-SERIAL
class class-default
random-detect

ポリシーマップは個々のインターフェイスに接続され、インターフェイスの種類に特定です。 たとえば、これは WRED から WFQ へ多用途インターフェイス プロセッサベース(VIP ベース)イーサネットポートのキューイング機構を変更することのプロセスを簡素化します。 それはポリシーマップの単一変更を必要とします。 すべての VIP ベース イーサネットインターフェイスへの変更を行います。

interface ATM0/0
service-policy output OUTPUT-DATA-ATM

interface ATM1/0/0
service-policy output OUTPUT-DATA-VIP-ATM

interface Ethernet2/0
service-policy output OUTPUT-DATA-ETHERNET

interface Ethernet3/0/0
service-policy output OUTPUT-DATA-VIP-ETHERNET

interface Serial4/0
service-policy output OUTPUT-DATA-SERIAL

interface Serial5/0/0
service-policy output OUTPUT-DATA-VIP-SERIAL

低遅延キューイング

ダウンストリーム信頼されした VOIPデバイスがあるどのインターフェイスでも低遅延キューイング (LLQ)のために設定されます。 どのパケットでも LLQ に応じて着信インターフェイス 分類によってそれを作り、5 の優位を保つあります。 他のどのパケットも WFQ か WRED に応じてあります。 これはインターフェイスの種類によって決まります。

別のポリシー マップは各インターフェイスの種類のために QoS を管理することもっと簡単にするために作成されます。 これは無音声キューイング設計に類似したです。 ただし、複数のポリシー マップは各インターフェイスの種類のためにあります。 これは運送音声トラフィックに対するインターフェイスの種類のキャパシティがリンク速度/リンク スピードによって、PVC 設定、等変わるという理由によります。 ポリシーマップ名前の数は呼び出しの数を考慮に入れました 30 の呼び出しを、60 の呼び出し、等反映します。

policy-map OUTPUT-VOICE-VIP-ATM-30
class VOICE
priority 816
class class-default
random-detect

policy-map OUTPUT-VOICE-VIP-ATM-60
class VOICE
priority 1632
class class-default
random-detect

policy-map OUTPUT-VOICE-ATM-30
class VOICE
priority 816
class class-default
random-detect 

policy-map OUTPUT-VOICE-ATM-60
class VOICE
priority 1632
class class-default
random-detect

policy-map OUTPUT-VOICE-ETHERNET-30
class VOICE
priority 912
class class-default
fair-queue

policy-map OUTPUT-VOICE-VIP-ETHERNET-30
class VOICE
priority 
class class-default
random-detect

policy-map OUTPUT-VOICE-HDLC-30
class VOICE
priority 768
class class-default
fair-queue

ポリシーマップは個々のインターフェイスに接続されます。 この例では、ポリシーマップはインターフェイスの種類に特定です。 現在特別な処置は音声シグナリングに与えられません。 ポリシーマップは 1 インポートでこれが所定のインターフェイス型の後の段階で要件になる場合容易に改めることができます。 変更はその型のすべてのインターフェイスのための影響を奪取 します。

Interface ATM0/0
service-policy output OUTPUT-VOICE-ATM-30

interface ATM1/0/0
service-policy output OUTPUT-VOICE-VIP-ATM-30

interface Ethernet2/0
service-policy output OUTPUT-VOICE-ETHERNET-60

interface Ethernet3/0/0
service-policy output OUTPUT-VOICE-VIP-ETHERNET-60

interface Serial4/0
service-policy output OUTPUT-VOICE-SERIAL-30

interface Serial5/0/0
service-policy output OUTPUT-VOICE-VIP-SERIAL-60

LLQ スケーラビリティ

キューイング機構はいくつかのスケーラビリティの問題を備えています。 主要な問題はネットワークの各信頼された VOIPデバイスの IP アドレスの知識に頼ることです。 これはトールバイパスを処理する VOIPゲートウェイの限られた数があったときに以前適度な制限でした。 VoIP エンドポイントの数は大幅に増加し、それは IP テレフォニーの配備とますます実際的でなくなります。 ACL は余りにも長く、管理しには余りにもにくくなります。

ACL は ACU の場合には各 ACU キャンパスで仕様音声 IP サブネットワークからのトラフィックを信頼するために追加 されました。 これは暫定ソリューションです。 これらの長期ソリューションは調査されています:

  • H.323 プロキシ

  • QoS 入力 ポリシング

H.323 プロキシ ソリューションの後ろの主旨はプロキシによってある特定のキャンパスから AARNet を入力してすべての RTP トラフィックをもらうことです。 AARNet はこのダイアグラムが示すので、単一 IP アドレスのある特定のキャンパスからのすべての RTP トラフィックを見ます:

/image/gif/paws/13913/60551.gif

QoS ACL のエントリの数はキャンパス毎に 1 つの行にこの方式が一貫して展開される場合制限されます。 複数のキャンパスが付いている 37 の大学があるのでこの方式に 100 に集計する可能性がか More エントリはまだあります。 これは余りにスケーラブルではないです。 各 RNO で共用スーパ プロキシの単一か限られた数との設計に移動することは必要であるかもしれません。 これは 6 に信頼された IP アドレスの数を減らします。 ただし、これは RNO でキャンパスからのプロキシにパスの QoS ポリシング問題を開発します。

注: Cisco Unified CallManager クラスタ間トランクは H.323 プロキシによって現在 クラスタ間シグナリングがネイティブ H.225 ではないのではたらきません。

QoS 入力 ポリシングは代替案です。 信頼境界はキャンパスがこの設計と RNO につながれているポイントで確立されます。 トラフィックは Cisco IOS によって AARNet を入力するポリシングが行われますか。 この境界の専用アクセス レート (CAR) 機能。 VoIP のために AARNet を使用する大学は AARNet ある程度の QoS 帯域幅を支援します。 AARNet を入力する CAR はそれからトラフィックをモニタします。 IP 優先順位 5 の RTP トラフィックの量が定期講読された帯域幅を超過する場合過剰なトラフィックに 0 にマークダウンされる IP 優先順位があります。

このダイアグラムは CAR構成を示します:

/image/gif/paws/13913/60552.gif

CAR構成がこのポリシングをどのように処理するかこの例に示されています:

Interface a1/0.100
rate-limit input access-group 100 2400000 0 0 conform-action set-prec-transmit 5
exceed-action set-prec-transmit 0

access-list 100 permit udp any range 16384 32767 any range 
 16384 32767 precedence critical

これらは CAR構成アプローチのいくつかの長所です:

  • コアはもはやポリシングを処理する必要がありません。 それは信頼境界で今処理されます。 従って、コアの LLQ は信頼された IP アドレスについて確認する必要はありません。 入力で既にポリシングを渡してしまったのでコアの 5 の IP 優先順位のどのパケットでも LLQ に応じて安全にある場合もあります。

  • 想定は個々の大学が選択する VoIP アーキテクチャ、機器およびプロトコルについてなされません。 H.323 プロキシを使用しない大学は Session Initiation Protocol (SIP)をか Media Gateway Control Protocol (MGCP)を展開することを選択できます。 VOIPパケットは 5.の IP 優先順位がある限りコアの適切な QoS を受け取ります。

  • CAR は QoS サービス拒否 (DoS)不正侵入に対して弾力性のあります。 大学から起きる QoS DoS攻撃はコアを損傷する場合がありません。 CAR は許された VOIPコールの最大数がアクティブであるある何よりより多くのトラフィックを生成できない攻撃を制限します。

    そのキャンパスに/からの VOIPコールは攻撃の間に苦しむことができます。 ただし、それはそれ自身を内部で保護する個々の大学まであります。 大学は指定 VoIP サブネットワークを除いてすべてにマークダウンされる IP 優先順位があるようにルータの CAR ACL をきつく締めることができます。

    各キャンパスにユーザが最終的 な 設計のキャンパスLAN に接続するポイントで内部 信頼境界があります。 この信頼境界が受け取る 5 の IP 優先順位のトラフィックはスイッチポート毎に 160 キロビット/秒、か G.711 2 つの VOIPコールに制限されます。 この比率以上のトラフィックはマークダウンされます。 この方式の実装は機能性を制限する比率と類似した Catalyst 6500 スイッチまたは何かを必要とします。

  • コアの帯域幅 プロビジョニングは各大学が一定の QoS 帯域幅を支援すると同時に簡素化します。 これはまた各大学が QoS 帯域幅サブスクリプションに基づいて平らな月極料金を支払うことができるので QoS 請求書を送ることを簡単にします。

この設計の主な弱点は信頼境界が大学のルータにある、従って大学は正しく CAR を管理できる必要がありますことです。 信頼境界は RNO に再び引っ張られます。 RNO管理 機器は最終的 な 設計のポリシングを処理します。 この設計は Catalyst 6000 スイッチか Cisco 7200 ネットワーク サービス エンジン(Cisco 7200 NSE-1) プロセッサのような制限するハードウェア ベース 比率を必要とします。 ただし、それは QoS ポリシングの AARNet および RNOs 完全な制御を与えます。 このダイアグラムはこの設計を示します:

/image/gif/paws/13913/60553.gif

Link Fragmentation and Interleaving

VoIP は高速ATM virtual circuits (VCs)を渡ってだけ比較的運ばれています。 従って、LFI が必要となりません。 VoIP はまた郊外の大学へのフレームリレーフォーラム (FRF)か専用回線を渡って将来転送することができます。 これはインターリーブまたは FRF.12 のマルチリンク PPP (MLP)のような LFI メカニズムを必要とします。

ゲートウェイ

2 種類の AARNet の H.323 ゲートウェイがあります:

  • PSTN — VOIPゲートウェイへの PSTN

  • PABX — VOIPゲートウェイへの PABX

PSTN および PABX ゲートウェイ間の違いは主な役割を果たしています。 PSTN ゲートウェイは PSTN への接続を提供します。 PABX ゲートウェイは VoIP バックボーンに大学 PABX を接続します。 同じ物理的 な ボックスは PSTN および PABX ゲートウェイ両方として多くの場合機能します。 現在 ACU IPテレフォニーソリューションに 31 のゲートウェイがあります。 これらのゲートウェイのほとんどは Cisco AS5300 Universal アクセス サーバです。 他のゲートウェイは Cisco 3600 シリーズ ルータまたは Cisco 2600 シリーズ ルータです。 最低 10 の追加ゲートウェイは Q2CY01 の間に追加されると期待されます。 AARNet は 2001 年の 4 月のおよそ 145,000 の VOIPコールを伝送しました。

AARNet はこのダイアグラムが示すので、ほとんどの主要な都市の PSTN接続 H.323 ゲートウェイを展開しました:

/image/gif/paws/13913/60554.gif

大学は PSTN にアウトバウンドコールを作るのにこれらのゲートウェイを使用できます。 大学は現在サポートされないのでインバウンドコールのための自身のトランクを維持しなければなりません。 AARNet はこれらのゲートウェイを通過する呼び出しの音量が理由でキャリアによって競争 価格を非常にネゴシエートできます。 呼び出しはまたを離れて費用効率の良いポイント最高で廃棄することができます。 たとえば、パースの電話番号を呼出すシドニーの誰かはパース ゲートウェイを使用し、市内電話のためにしか満たすことができません。 これは別名テールエンド ホップオフ(TEHO)です。

単一のゲートキーパーは IP アドレス解決に E.164 を行うために配置されます。 PSTN へのすべての呼び出しは最も適切なゲートウェイの IP アドレスを戻すゲートキーパーに送られます。 ゲートキーパーに関する詳細な情報詳細についてはダイヤル プランおよびゲートキーパー セクションを参照して下さい。

請求および会計

PSTN ゲートウェイは RADIUS および認証、許可、アカウンティング(AAA)を課金目的に使用します。 ゲートウェイを通した各コールは各コールレグのためのコール詳細レコード(CDR)を作成します。 これらの CDR は RADIUSサーバに掲示されます。 CDR の Cisco Unified CallManager の IP アドレスは大学を識別し、正しいパーティが請求書を送られるようにします。

ゲートウェイ セキュリティ

DoS攻撃および欺瞞に対する PSTN ゲートウェイを保護することは主な心配です。 H.323 クライアントは広く利用可能です。 Microsoft NetMeeting は Microsoft Windows 2000 によって組み込まれます、従って非技術的なユーザがこれらのゲートウェイを通して自由な呼び出しを送信することは比較的容易です。 これらのゲートウェイを保護するために受信 ACL を信頼された IP アドレスからのその割り当て H.225 シグナリング設定して下さい。 このアプローチに QoS セクションが記述する全く同じスケーラビリティの問題があります。 ACL のエントリの数は H.323 信頼されたエンドポイントの数が増加すると同時に増加します。

H.323 プロキシはこのエリアの救助を提供します。 ゲートウェイ の ACL は PSTN ゲートウェイ パススルーによって大学構内毎に割り当て 1 IP アドレスをすべての呼び出しキャンパス プロキシ必要とします。 冗長 な プロキシとして 2 IP アドレスはほとんどの場合好ましいです。 プロキシと、ACL は 100 つ以上のエントリが含まれている場合があります。

プロキシは ACL によってどの H.323 でもプロキシによってコールを設定できるので保護する必要があります。 これが毎キャンパス基礎でされるのでローカル ポリシーが必要となると同時にプロキシ ACL は割り当て構内 H.323 デバイスなります。

2 つの Cisco Unified CallManager の IP アドレスはゲートウェイ の ACL にキャンパスが IP 電話からの呼び出しだけ AARNet PSTN ゲートウェイを使用するようにたいと思う場合含んでいる必要があります。 プロキシは値をこの場合追加しません。 必須 ACL エントリの数は 2 いずれにしてもです。

キャンパス間の IP 電話に IP 呼び出しがパススルーをプロキシ必要としないことに注目して下さい。

ダイヤル プラン

現在の VoIP ダイヤル プランは簡単です。 ユーザは VOIPゲートウェイ観点からの呼び出しのこれら二つの型を置くことができます:

  • 別のキャンパスで同じ大学で電話を呼出して下さい。

  • 別の大学で PSTN 電話か電話を呼出して下さい。

ゲートウェイ ダイヤル ピアは呼び出しにはたった 2 つの型があるというファクトを反映します。 この例が示すので、基本的に 2 つの VOIPダイヤルピア型があります:

dial-peer voice 1 voip
destination-pattern 7…
session-target ipv4:x.x.x.x

dial-peer voice 1 voip
destination-pattern 0………
session-target ras

最初のダイヤル ピアは誰かがこの例の別のキャンパスで拡張 7 を…呼出す場合使用されます。 このコールはリモートゲートウェイの IP アドレスに直接ルーティングされます。 ゲートキーパーがバイパスされるので、コール アドミッション制御(CAC)は実行された。

第 2 ダイヤル ピアはコールが PSTN 数のためであるとき使用されます。 これはどちらかこれらの項目のである場合もあります 1 つ:

  • PSTN の電話の数

  • 別の大学の電話の完全修飾 PSTN 数

コールは最初のケースの Admission Request (ARQ) メッセージによってゲートキーパーに発信されます。 ゲートキーパーは Admission Confirm (ACF)メッセージの推奨 PSTN ゲートウェイの IP アドレスを戻します。

コールはまた第 2 ケースの ARQ メッセージによってゲートキーパーに発信されます。 ただし、ゲートキーパーはコールを受信する大学で VOIPゲートウェイの IP アドレスの ACF メッセージを返します。

ゲートキーパー

AARNet は現在 単一のゲートキーパーを操作します。 このゲートキーパーの唯一の目的は IP アドレス解決へ E.164 の形で呼ルーティングを行うことです。 ゲートキーパーは CAC を行いません。 ゲートウェイに接続される PABX トランクの数は同時コールの数を制限します。 コア 帯域幅は使用中のすべてのトランクをすぐに考慮に入れます。 これは ACU および他の大学で IP テレフォニーのロールアウトと変更します。 またはこの新しい環境のある特定のキャンパスからソースをたどることができる同時 VOIPコールの数に自然な制限がありません。 利用可能 な QoS 帯域幅は余りにも多くの呼び出しが開始される場合オーバースクライブされます。 すべての呼び出しはこの状態の下で低質で被害を受けることができます。 ゲートキーパーを CAC を提供するのに使用して下さい。

大学音声ネットワークの分散 性質および可能性サイズは分散ゲートキーパー アーキテクチャにそれ自身を貸します。 1 つの可能 な 解決策は各大学が自身のゲートキーパーを維持する二重階層的 な ゲートキーパー の 設計を持つことです。 この大学ゲートキーパーは層 2 ゲートキーパーと言われます。 AARNet は層 1 ゲートキーパーと言われるディレクトリゲートキーパーを操作します。

大学は Cisco CallManager クラスタ間の呼ルーティングのためにゲートキーパーを使用するのにこの二重アプローチを利用する必要があります。 ゲートキーパーはこのシナリオの 4 または 5 ディジット 拡張に基づいて呼び出しをルーティングします。 各大学は自身のゲートキーパーを必要とします。 これはこれがローカルで管理されたアドレス スペースであるので拡張範囲が大学の間で重複するという理由によります。

大学層 2 ゲートキーパーはその大学だけに出入して呼び出しのための CAC を行います。 それはまたその大学のキャンパスだけ間の呼び出しのための E.164 解決を行います。 コールは Location Request (LRQ) メッセージによって層 1 ゲートキーパーに層 2 ゲートキーパーによって誰かが別の大学で IP Phone を呼出すか、または AARNetゲートウェイを通して PSTN を呼出せばルーティングされます。 LRQ はその大学の層 2 ゲートキーパーにコールが別の大学のためである場合転送されます。 このゲートキーパーはコールが起きる大学で層 2 ゲートキーパーにそれから ACF メッセージを返します。 層 2 ゲートキーパーは両方とも CAC を行います。 彼らはコールを両方で利用可能 な 十分 な 帯域幅が呼出すことおよび呼出されたゾーンある場合その時だけ続行します。

AARNet はあらゆる大学のそれらのような AARNet PSTN ゲートウェイを扱うことを選択できます。 自身の層 2 ゲートキーパーはそれらを守ります。 層 1 ゲートキーパーはまたこれらのゲートウェイのための層 2 ゲートキーパーとしてロードならおよびパフォーマンス割り当て行動できます。

ゲートキーパーのそれぞれは(AARNet を含むディレクトリゲートキーパー)ゲートウェイがそのような重要なコンポーネントであるので複製される必要があります。 各大学は 2 人のゲートキーパーがある必要があります。 Cisco IOSゲートウェイが Cisco IOS ソフトウェア リリース 12.0(7)T の場合にはように代替ゲートキーパーを、持っていることは可能性のあるです。 ただし、これは Cisco Unified CallManager か H.323 他のどのサード パーティ デバイスによっても現在サポートされません。 現時点でこの機能を使用しないで下さい。 代りの簡単なホット スタンバイ ルータ プロトコルベース(Hsrp ベース)ソリューションを使用して下さい。 これはゲートキーパーが両方とも同じ IP サブネットワークで置かれることを必要とします。 HSRP はどのゲートキーパーがアクティブであるか判別します。

ACU IP テレフォニーネットワーク

この表は ACU のキャンパスでインストールされる IP 電話の概数を示したものです:

キャンパス 都市 おおよそ IP 電話
マウント St Mary Strathfield 400
MacKillop 北シドニー 300
パトリック メルボルン 400
アクィナス バララット 100
Signadou キャンベラ 100
McAuley ブリスベーン 400
  Total : 1700

ACU は最近 IPテレフォニーソリューションを展開しました。 ソリューションは各キャンパスで 2 つの Cisco Unified CallManager、Cisco 3640 ゲートウェイ、および IP 電話のクラスタで構成されています。 AARNet はキャンパスを相互接続します。 このダイアグラムは ACU IP テレフォニー ネットワークの高レベル トポロジーおよびさまざまなコンポーネントを描写します:

/image/gif/paws/13913/60555.gif

ACU ネットワーク トポロジ

このダイアグラムは典型的な ACU キャンパスを示します。 各キャンパスに Catalyst スイッチの 3 つの層があります。 ワイヤリング クローゼットはより古い Catalyst 1900 スイッチを収納します。 Catalyst 1900 スイッチは Extended Framing によって Catalyst 3500XL に戻ってスイッチを接続します。 これらは Gigabit Ethernet (GE)によって単一 Catalyst 6509 スイッチに戻って接続します。 単一 Cisco 7200VXR ルータはローカル RNO に ATM VC によって AARNet にキャンパスを接続します。

/image/gif/paws/13913/60556.gif

RNO への接続 方式は状態とこの表が示すので示すためにわずかに異なります。 ビクトリアは Classical IP over ATM (RFC 1577)に基づいています。 他の RNOs に RFC1483 カプセル化と設定されるまっすぐな PVC があります。 Open Shortest Path First (OSPF)は ACU と RNOs の間で使用されるルーティング プロトコルです。

キャンパス State RNO への接続 ルーティング プロトコル
マウント St Mary NSW RFC1483 PVC OSPF
MacKillop NSW RFC1483 PVC OSPF
パトリック VIC RFC 1577 Classical IP over ATM OSPF
アクィナス VIC RFC 1577 Classical IP over ATM OSPF
Signadou ACT RFC1483 PVC OSPF
McAuley QLD RFC1483 PVC OSPF

アップリンクだけでトランキングする Catalyst 1900 シリーズ スイッチ サポート。 従って、IP 電話および PC は 1 つの大きい VLAN にすべてです。 実際、全体のキャンパスは 1 つの大きい VLAN およびブロードキャスト ドメインです。 セカンダリ IP サブネットワークは多数デバイスが理由で使用されます。 IP 電話は 1 IP サブネットワークにあり、PC は別のものにあります。 AARNet コアは IP Phone サブネットワークを信頼し、この IP サブネットワークに出入するトラフィックは LLQ に応じてあります。

プライマリおよびセカンダリ IP サブネットワーク間の Cisco 7200 ルータ ルーティング。 Catalyst 6500 スイッチのマルチレイヤ スイッチ フィーチャ カード I (MSFC)は現在使用されません。

Catalyst 3500XL および Catalyst 6500 スイッチは QoS 機能を備えていますが、現在 有効に なりません。

キャンパスのQoS

現在のキャンパスデザインは IP テレフォニーのための Cisco 推奨 設計のガイドラインに従いません。 これらは QoS についてのいくつかの問題です:

  • ブロードキャスト ドメインは非常に大きいです。 それらを処理しなければならない過度のブロードキャストは IP 電話のパフォーマンスに影響を及ぼす場合があります。

  • Catalyst 1900 スイッチは QoS可能ではないです。 IP Phone および PC が同じスイッチポートに接続される場合、音声パケットは PC がデータを高いレートで受け取る場合廃棄することができます。

著しい改善を実現するためにキャンパス インフラストラクチャの一部分を設計し直して下さい。 ハードウェア アップグレードが必要となりません。 このダイアグラムはお勧めのデザイン変更の後ろのプリンシパルを説明します:

60557.gif

キャンパスは voice VLAN およびデータVLAN に分割する必要があります。 Catalyst 1900 スイッチに接続する PC 異なるポートにおよび電話は VLAN の 分離を実現させるために今接続される必要があります。 各 Catalyst 1900 スイッチからの Cisco 3500XL スイッチへの追加アップリンクは追加されます。 2 アップリンクの 1 つは voice VLAN のメンバーです。 他のアップリンクはデータVLAN のメンバーです。 2 アップリンクに代替としてトランキングする InterSwitch Link (ISL)を使用しないで下さい。 これは別々のキューを音声 および データ トラフィックに与えません。 Catalyst 3500XL スイッチから Catalyst 6000 スイッチへの GE リンクはまた 802.1q トランクに音声およびデータVLAN が両方このコア スイッチを渡って運ぶことができるように変換する必要があります。

データVLAN に持っているゼロのデフォルト サービスの分類 (CoS)をある Catalyst 3500XL のポートは切り替えます。 Catalyst 3500 または Catalyst 6500 コアで着けば voice VLAN その結果のメンバーであるポートに 5.のデフォルト CoS が、音声トラフィック正しく優先順位をつけられますあります。 Catalyst 3500 QoS スイッチポート設定はによってこの例が示すのでメンバーはどの VLAN スイッチポートであるかわずかに異なります、:

Interface fastethernet 0/1
description Port member of voice VLAN
switchport priority 5
switchport access vlan 1

Interface fastethernet 0/2
description Port member of data VLAN
switchport priority 0
switchport access vlan 2

IP 電話が Catalyst 3500XL スイッチに直接接続する稀なケースの IP Phone の後部スイッチポートに PC を接続できます。 IP 電話は 802.1q トランクによってスイッチにこの場合接続します。 これは音声 および データパケットが別々のVLAN で移動するようにし入力でパケットに正しい CoS を与えることができます。 それらがライフの終わりに達するように Catalyst 3500XL スイッチか他の QoS可能 スイッチによって Catalyst 1900 スイッチを取り替えて下さい。 このトポロジーはそれからネットワークに IP 電話および PC を接続する標準的な方法になります。 このシナリオは Catalyst 3500XL スイッチ QoS 設定を示します:

Interface fastethernet 0/3
description Port connects to a 79xx IPhone
switchport trunk encapsulation dot1q
switchport priority extend 0

最終的には、2 つの Cisco Unified CallManager に接続する 2 つのポートは Cisco Unified CallManager がすべての音声シグナリング パケットの 3 に IP 優先順位を設定 する 3.にハードコードされる CoS があるはずです。 ただし、Cisco Unified CallManager からの Catalyst 3500XL スイッチへのリンクは 801.1p を使用しません。 従って、CoS 値はこの例が示すと同時にスイッチで強制です:

Interface fastethernet 0/1
description Port member of voice VLAN
switchport priority 3
switchport access vlan 1

この設計の主要なハードルは 2 つのスイッチポートがデスクトップで必要となることです。 パトリック キャンパスは 400 IP 電話のために余分な物 400 スイッチポートを必要とするかもしれません。 追加 Catalyst 3500XL スイッチは十分なポートが利用できない場合配置する必要があります。 2 つの抜けた Catalyst 1900 スイッチ ポート毎にに 1 つの Catalyst 3500XL スイッチポートだけ必要となります。

電流 ACU Catalyst 6500 スイッチは QoS 機能がありますが、現在 有効に なりません。 これらのモジュールはこれらのキュー機能の ACU Catalyst 6000 スイッチにあります:

- -
スロット モジュール ポート Rx キュー Tx キュー
1 WS-X6K-SUP1A-2GE 2 1p1q4t 1p2q2t
3 WS-X6408-GBIC 8 1q4t 2q2t
4 WS-X6408-GBIC 8 1q4t 2q2t
5 WS-X6248-RJ-45 48 1q4t 2q2t
15 WS-F6K-MSFC 0

Catalyst 6000 スイッチの適切な QoS 機能をアクティブにするためにこれらのステップを完了して下さい:

  1. スイッチにこのコマンドを VLAN ごとに QoS に与えるように指示して下さい:

    Cat6K>(enable)set port qos 1/1-2,3/1-8,4/1-8 vlan-based
    
  2. スイッチにこのコマンドで Catalyst 3500XL スイッチから届く CoS 値を信頼するように指示して下さい:

    Cat6K>(enable)set port qos 1/1-2,3/1-8,4/1-8 trust trust-cos
    

CoS は Differentiated Services Code Point (DSCP) マッピング することに今設定 する必要があります。 Catalyst 6000 スイッチが受け取った CoS 値に基づいて IP ヘッダーの DSCP 値を書き換えるのでこれが必要となります。 VOIPシグナリング パケットは AF31 (26)の DSCP と書き換えられる 3 の CoS がなければなりません。 RTP パケットは EF の DSCP と書き換えられる 5 の CoS がなければなりません(46)。 次のコマンドを発行します。

Cat6K>(enable)set qos cos-dscp-map 0 8 16 26 32 46 48 56

CoS-to-DSCPマップを確認するのにこの例を使用して下さい。

Cat6K> (enable) show qos map run COs-DSCP-map
CoS - DSCP map:
CoS DSCP
--- ----
 0   0
 1   8
 2   16
 3   26
 4   32
 5   46
 6   48
 7   56

さまざまな IP サブネットワークの間でルーティングするために MSFC を設定して下さい。

RNO のQoS

電流 RNO 設計は IP テレフォニーのための Cisco 推奨 設計のガイドラインに従いません。 これらの問題は QoS に関してあります:

  • LLQ は Cisco ACU 7200 シリーズ WAN ルータで適用されません。

  • パトリックおよびアクィナス キャンパスは ATM スイッチド VC (SVC)によって RNO につながれています。 LLQ は SVC でサポートされません。

ファースト イーサネット付属 Cisco 7200 ルータは 34 Mbps E4 ATMリンクによって RNO にキャンパスを接続します。 トラフィックは 100M 速度ミスマッチ vs 4M が理由で可能性としては 34M リンクの発信を並べることができます。 従って、音声トラフィックに優先順位をつけることは必要です。 LLQ を使用して下さい。 Cisco 7200 ルータ 設定はこの例に類似したです:

class-map VoiceRTP
match access-group name IP-RTP

policy-map RTPvoice
class VoiceRTP
priority 10000

interface ATM1/0.1 point-to-point
description ATM PVC to RNO
pvc 0/100 
tx-ring-limit 3
service-policy output RTPvoice

ip access-list extended IP-RTP
deny ip any any fragments
permit udp any range any range 16384 32768 precedence critical

LLQ に割り当てられる帯域幅は N が G.729 同時呼び出しの数であるところに、N x 24Kbps ある必要があります。

パトリックおよびアクィナス Cisco 7200 ルータのそれぞれから AARNet ルータに 1 PVC を設定して下さい。 Classical IP over ATM (RFC 1577)に基づいているので、ビクトリア RNO の ATM SVC は LLQ をサポートしません。 ビクトリア RNO の他の大学は RFC 1577 を今のところ使用し続けることができます。 ただし、結局 Classical IP over ATM インフラストラクチャを取り替えて下さい。

ゲートウェイ

H.323 ゲートウェイとして機能する ACU キャンパスのそれぞれに Cisco 3640 ルータがあります。 これらのゲートウェイは ISDN によって PSTN に接続します。 一次群速度インターフェイス(PRI)および B チャネルの数はキャンパスのサイズによって異なります。 この表は各キャンパスのための PRI および B チャネルの数をリストしたものです:

キャンパス PRI 数量 B チャネル数量
マウント St Mary 2 30
MacKillop 2 50
パトリック 2 50
アクィナス 1 20
Signadou 1 20
McAuley 1 30

これらのゲートウェイは DOD (直接 外線 ダイヤル 方式)のためにセカンダリ ゲートウェイとしてだけ使用されます。 AARNetゲートウェイはプライマリゲートウェイです。 ACU ゲートウェイは DID (Direct Inward Dialing)のために常に使用されます。

ダイヤルプラン

ダイヤル プランは 4桁拡張番号に基づいています。 拡張はまた DID の数の最後の 4 ディジットです。 この表は各キャンパスのための拡張範囲および DID の数をリストしたものです:

キャンパス 拡張子 DID
マウント St Mary 9xxx 02 9764 9xxx
MacKillop 8xxx 02 9463 8xxx
パトリック 3xxx 03 8413 3xxx
アクィナス 5xxx 03 5330 5xxx
Signadou 2xxx 02 6123 2xxx
McAuley 7xxx 07 3354 7xxx

ゲートウェイの簡単な num-expエントリは 4桁拡張に Cisco Unified CallManager にそれを渡す前に DID の数を切捨てます。 たとえば、パトリック キャンパス ゲートウェイはこのエントリを備えています:

num-exp 84133... 3...

ユーザは外部行を選択するためにゼロをダイヤルします。 この先行ゼロはゲートウェイに通じます。 単一 POTSダイヤルピアは ISDNポートが先行ゼロに基づかせていた呼出をルーティングします。

Dial-peer voice 100 pots
destination-pattern 0
direct-inward-dial
port 2/0:15

着信コールは 4桁拡張に着番号をトランスフォームするのにこの num-expエントリを使用します。 コールはそれから両方の VOIPダイヤルピアと一致します。 より低い 優先度に基づいて、それは Cisco Unified CallManager サブスクライバにこのルートを優先します:

dial-peer voice 200 voip
preference 1
destination-pattern 3...
session target ipv4:172.168.0.4

dial-peer voice 201 voip
preference 2
destination-pattern 3...
session target ipv4:172.168.0.5

Cisco CallManager

2 つの Cisco CallManager サーバで構成されているキャンパスのそれぞれにクラスタがあります。 Cisco CallManager サーバは Media Convergence Server 7835 (MCS-7835)の組合せおよび Media Convergence Server 7820 (MCS-7820)です。 サーバは両方ともこの出版物の時にバージョン 3.0(10)を動作しました。 1 つの Cisco Unified CallManager はパブリッシャであり、他の Cisco Unified CallManager はサブスクライバです。 サブスクライバはすべての IP 電話のためのプライマリ Cisco CallManager として行動します。 この表は各キャンパスで配置されるハードウェアをリストしたものです:

キャンパス プラットフォーム CallManager
マウント St Mary MCS-7835 2
MacKillop MCS-7835 2
パトリック MCS-7835 2
アクィナス MCS-7820 2
Signadou MCS-7820 2
McAuley MCS-7835 2

各クラスタは 2 つの領域で設定されます:

  • intracampus のための 1 つは呼出します(G.711)

  • 構内コール(G.729)のための 1 つ

ロケーションに基づいたCAC は各クラスタによって動作されるすべての IP 電話が単一 キャンパスにあるので ACU のために適切ではないです。 構内コールのためのゲートキーパー ベース CAC へ利点がありますが、これは現在設定されません。 ただし、そう近い将来にするべき計画があります。

各 Cisco Unified CallManager は 22 H.323 ゲートウェイで設定されます。 これは各キャンパスの 5 つの他の Cisco CallManager クラスタ、AARNet 6 つの PSTN ゲートウェイおよび 1 つの ACU ゲートウェイへのクラスタ間トランクで構成されます。

H.323 デバイスの種類 数量
キャンパス間の CallManager 2 x 5 = 10
AARNet PSTN ゲートウェイ 6
ACU PSTN ゲートウェイ 6
Total : 22

ルート リストがおよびルート グループは PSTN ゲートウェイをランク付けするのに使用されています。 たとえばルート グループとともに呼び出しを結ぶのにメルボルンのパトリック Cisco Unified CallManager からのシドニー PSTN への呼び出しがどのように 4 つのゲートウェイを使用できるか、この表に示されています。

ゲートウェイ Priority
AARNet シドニー 1
ACU シドニー 2
AARNet メルボルン 3
ACU メルボルン 4

Cisco Unified CallManager はおよそ 30 のルートパターンでこの表が示すので、設定されます。 ルートパターンはそうそこにですすべての国内オーストラリア数に特定のマッチ設計されています。 こうすればは Cisco Unified CallManager の前に切れるために、ユーザ開始しますコールを桁間タイムアウトを待つ必要がありません。 ワイルドカード「!」 国際番号のためにルートパターンでだけ使用されます。 ユーザは海外 の 宛先にダイヤルするとき桁間タイムアウト(デフォルト 10 秒)がコールプログレスの前に期限切れになるまで待つ必要があります。 ユーザはまたルートパターン "0.0011!#" を追加できます。 ユーザはダイヤル番号が完了したことを#」後 Cisco Unified CallManager に示す最後 の 数字それから「入力することができました。 この操作は国際ダイヤルを促進します。

-
ルート パターン 説明
市内電話
0.00 -ユーザが外部行のための 0 をダイヤルすることを忘れている場合非常呼出
0.000 非常呼出
0.013 番号案内
0.1223
0.0011! 国際電話のコール
ニュー・サウス・ウェールズへの呼び出し
ビクトリアへの呼び出し
携帯 電話への呼び出し
クイーンズランドへの呼び出し
西 オーストラリアへの呼び出し
南 オーストラリアおよび北方領土への呼び出し
1800 xxx xxx および 1900 年 xxx xxx への呼び出し
0.1144X 緊急事態
0.119[4-6] 時間および天候
0.1245X ディレクトリ
0.13[1-9]XXX 13xxxx 数への呼び出し
1300 の xxx xxx 第への呼び出し
2[0-1]XX Signadou へのクラスタ間呼出し
3[0-4]XX パトリックへのクラスタ間呼出し
5[3-4]XX アクィナスへのクラスタ間呼出し
7[2-5]XX McAuley へのクラスタ間呼出し
8[0-3]XX MacKillop へのクラスタ間呼出し
9[3-4]XX St Mary をマウントするクラスタ間呼出し
9[6-7]XX St Mary をマウントするクラスタ間呼出し

ゲートウェイの数は、ルート グループ、ルート リストし、設定される ACU Cisco Unified CallManager のルートパターンに大きな 番号になる可能性があります。 新しい RNO ゲートウェイが配置される場合、5 つの Cisco CallManager クラスタはすべて追加ゲートウェイによって再構成する必要があります。 ACU Cisco Unified CallManager が他のすべての大学に VOIPコールを直接ルーティングし、PSTN を全体でバイパスすればより悪い、何百ものゲートウェイは追加される必要があります。 明らかにこれは非常によくスケーリングしません。

ソリューションは Cisco Unified CallManager をゲートキーパーで制御されしたようにすることです。 新しいゲートウェイか Cisco Unified CallManager が AARNet にどこかに追加されるときしかゲートキーパーをアップデートしなくて下さい。 各 Cisco Unified CallManager はこれが起こるとき設定されるローカル キャンパス ゲートウェイおよび匿名デバイスだけ備えなければなりません。 ポイント マルチポイント間 トランクとしてこのデバイスを捉えることができます。 それは Cisco Unified CallManager ダイヤル プラン モデルの一致させた PPP トランクのための必要を取除きます。 単一経路 グループはバックアップ ゲートウェイとして優先ゲートウェイとして匿名デバイスとローカル ゲートウェイを指します。 ローカル PSTN ゲートウェイはある特定の市内電話とまた一般のオフネット コールのためにゲートキーパーが利用できなくなる場合使用されます。 現在、匿名デバイスはゾーン間または H.225、同時に両方のどちらである場合もありません。

Cisco Unified CallManager は今持っているよりゲートキーパーが付いている少数のルートパターンを必要とします。 原則的には、Cisco Unified CallManager は必要とします単一経路 パターンだけの「!」 ゲートキーパーを指すこと。 実際には、呼び出しがルーティングされる方法はより多くの仕様であるこれらの理由により必要があります:

  • いくつかの呼び出しはローカル ゲートウェイを通して(1-800 への呼び出しか緊急時番号のような)ルーティングされるを地理的に必要とします。 ピザハットのようなポリシングするかレストランのチェーン店にダイヤルするメルボルンの誰かはパースのポリシングするかピザハットに接続されたいと思いません。 特定のルートパターンはこれらの数のためのローカル キャンパス PSTN ゲートウェイに必要ことポイント直接です。

    未来の IP テレフォニー配備を行うことを計画する大学は AARNetゲートウェイにもっぱら頼り、自身のローカル ゲートウェイを管理しないことを選択できます。 これらの数はこの設計をローカルで廃棄される必要がある呼び出しのためにはたらかせますゲートキーパーへそれを送信 する前に Cisco Unified CallManager によって付加される仮想 な エリアコードがなければなりません。 たとえば、Cisco Unified CallManager はメルボルン ベース電話からのピザハット 1-800 番に呼び出しに 003 を付加できます。 これはゲートキーパーがメルボルン ベース AARNetゲートウェイにコールをルーティングすることを可能にします。 ゲートウェイは PSTN にコールを送信する前に導く 003 を除去します。

  • コールが開始される前に桁間タイムアウトのためのユーザ待機を持っていることを避けるためにすべての国内数のために特定の一致とルートパターンを使用して下さい。

この表はゲートキーパーで制御されした Cisco Unified CallManager のためのルートパターンを示したものです:

-
ルート パターン 説明 ルート ゲートキーパー
市内電話 ルート リスト AARNet
0.00 非常呼出 ローカル ゲートウェイ なし
0.000 非常呼出 ローカル ゲートウェイ なし
0.013 番号案内 ローカル ゲートウェイ なし
0.1223 ローカル ゲートウェイ なし
0.0011! 国際電話のコール ルート リスト AARNet
0.0011!# 国際電話のコール ルート リスト AARNet
ニュー・サウス・ウェールズ、ビクトリアおよび携帯 電話への呼び出し ルート リスト AARNet
南 オーストラリア、西 オーストラリアおよび北方領土への呼び出し ルート リスト AARNet
1800 xxx xxx および 1900 年 xxx xxx への呼び出し ローカル ゲートウェイ なし
0.1144X 緊急事態 ローカル ゲートウェイ なし
0.119[4-6] 時間および天候 ローカル ゲートウェイ なし
0.13[1-9]XXX 13xxxx 数への呼び出し ローカル ゲートウェイ なし
1300 の xxx xxx 第への呼び出し ローカル ゲートウェイ なし
[2-3]XXX Signadou への呼び出し ルート リスト ACU
5XXX アクィナスへの呼び出し ルート リスト ACU
[7-9]XXX McAuley、MacKillop およびマウント St Mary への呼び出し ルート リスト ACU

ゲートキーパーはローカル ゲートウェイを通して発信されない国際電話のコールをルーティングします。 これは AARNet が国際的なゲートウェイを将来配置できるので重要です。 ゲートウェイが米国で配置される場合、簡単なゲートキーパーコンフィギュレーション変更は大学が米国国内レートで米国に呼び出しを送信するようにします。

ゲートキーパーは 4桁 ACU 拡張に基づいてクラスタ間呼出し ルーティングを行います。 このアドレス スペースは他の大学と多分オーバーラップします。 これは ACU が自身のゲートキーパーを管理し、ディレクトリゲートキーパーとして AARNet ゲートキーパーを使用することを定めます。 この表のゲートキーパー カラムは呼ルーティングが ACU ゲートキーパーか AARNet ゲートキーパーによって実行されたかどうか示します。

注: 提案されたゲートキーパー ソリューションの唯一警告は匿名デバイスが現在 ゾーン間または H.225 のどれである場合もある両方こと同時にではないです。 Cisco Unified CallManager はゲートキーパーに両方のゲートウェイ(H.225)および提言された構想の他の Cisco Unified CallManager に呼び出しを(ゾーン間の)ルーティングするために頼ります。 この問題のための回避策はない使用へクラスタ間ルーティングのためのゲートキーパーまたはすべての呼び出しを H.225 としてゲートキーパーで処理するためにです。 後の回避策はいくつかの補足機能がクラスタ間呼出しで利用できないかもしれませんことを意味します。

ボイスメール

ACU に IP テレフォニーに移行前に対話形式電話委員会が付いている 3 つのアクティブボイスRepartee OS/2ベース 音声メールサーバがありました。 計画は IPテレフォニー環境のこれらのサーバを再使用することです。 設定されたとき、各 Reparteeサーバは簡易メッセージ デスク インターフェイス(SMDI)および Catalyst 6000 24 ポート Foreign Exchange Station (FXS) カードによって Cisco Unified CallManager に接続します。 これは 6 つのキャンパスの 3 に音声メールなしで 3 つのキャンパスを去る音声メールを提供します。 ゾーン間のH.323 (MWI)2Cisco CallManagerRepartee

ACU は残るキャンパスのための 3 つの Cisco Unity サーバを購入するかもしれません。 これらのサーバはスキニー ベースです、従ってゲートウェイが必要となりません。 この表は ACU が追加音声メールサーバを購入すれば音声メール ソリューションをリストしたものです:

- - -
キャンパス 音声メールシステム ゲートウェイ
マウント St Mary アクティブボイスRepartee Catalyst 6000 24 ポート FXS
MacKillop アクティブボイスRepartee Catalyst 6000 24 ポート FXS
パトリック アクティブボイスRepartee Catalyst 6000 24 ポート FXS
アクィナス Cisco Unity
Signadou Cisco Unity
McAuley Cisco Unity

6 つの音声メールサーバはこの計画の隔離された音声メール アイランドとして動作します。 音声メールネットワーキングがありません。

メディア リソース

ハードウェア デジタル信号プロセッサ(DSP)は ACU で現在配置されません。 会議は Cisco Unified CallManager のソフトウェアベースのコンファレンスブリッジを使用します。 ゾーン間の会議は現在サポートされません。

トランスコードすることが現在必要となりません。 G.711 だけおよび G.729 コーダ/デコーダは使用され、すべての配置された端デバイスによってサポートされます。

ファクシミリおよびモデムのサポート

ファクシミリおよびモデムトラフィックは ACU IP テレフォニー ネットワークによって現在サポートされません。 大学は Catalyst 6000 24 ポート FXS カードをこのために利用することを計画します。

ソフトウェア バージョン

この表はこのパブリケーションの時に使用されるソフトウェア バージョン ACU をリストしたものです:

-
プラットフォーム 機能 [Software Version]
callmanager IP-PBX 3.0(10)
Catalyst 3500XL ディストリビューションスイッチ 12.0(5.1)XP
Catalyst 6500 コア スイッチ 5.5(5)
Catalyst 1900 ワイヤリングクローゼットスイッチ
Cisco 7200 プロセッサ WAN ルータ 12.1(4)
Cisco 3640 ルータ H.323 ゲートウェイ 12.1(3a)XI6

関連するシスコ サポート コミュニティ ディスカッション

シスコ サポート コミュニティは、どなたでも投稿や回答ができる情報交換スペースです。


関連情報


Document ID: 13913