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

ケース スタディ IP テレフォニーの導入: ナショナル ブリティン シンガポール

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


目次


概要

このドキュメントは、シスコのお客様、パートナー、および従業員がシンガポールの National Bulletin(NB)の IP テレフォニー システムから体験とレッスンを入手できるようにします。 このドキュメントの目的は次のとおりです。

  • 導入されたソリューションの設計について説明し、批評します。

  • 設計の改善の可能性を確認します。

  • 設計におけるトレードオフをハイライトします。

NB は、グローバルな出版社です。 シンガポールの業務運営は、約 6,000 人の営業、印刷、および執筆スタッフで構成されています。 NB のスタッフは、同じ近隣区域にある複数のオフィス ビルに勤務しています。 2000 年後半に、NB は別のビルである DBS ビルを同社の構内に追加しました。 この追加のビルは、750 人の従業員を収容します。 NB は、新しいビルには構内交換機(PBX)を導入するのではなく、IP テレフォニー ソリューションを導入すること決定しました。 このようにして、新規開拓の導入にはネットワーク コンポーネントが含まれるようになりました。

NB の IP テレフォニー ソリューションは、単一サイト設計です。 IP テレフォニー ユーザは、すべて DBS ビルに配置され、5 つのフロア全体に分散されています。 Cisco CallManager、公衆電話交換網(PSTN)のゲートウェイ、およびボイスメールも、DBS ビルに物理的に配備されています。

ワイドエリア ネットワーク(WAN)のリンクは、DBS ビルを 1 Km 未満の距離にある NBAP ビルに接続します。 この Wan リンクは、ゲートウェイが世界規模の NB PBX ネットワークに接続する NBAP に Voice over Internet Protocol(VoIP)トラフィックを伝送します。 次の図は、DBS ビルと NBAP ビルを示します。

/image/gif/paws/13968/65363.gif

キャンパス LAN インフラストラクチャ

DBS の LAN インフラストラクチャは、コアに 1 台の Catalyst 6509 スイッチとワイヤリング クローゼットに 9 台の Catalyst 4006 スイッチで構成されます。 Catalyst 6509 スイッチが設定される仕組みを次の表に示します。

-
スロット モジュール 説明
1 WS-X6K-SUP1A-MSFC マルチレイヤ スイッチ フィーチャ カード(MSFC)搭載のスーパーバイザ
2 WS-X6K-S1A-MSFC2/2 MSFC 搭載のスーパーバイザ
3 WS-X6416-GBIC 16 ポート GE モジュール
4 WS-X6408A-GBIC 8 ポート GE モジュール
5 WS-X6348-RJ45V インライン パワー搭載の 48 ポート 10/100 モジュール
6 WS-X6608-E1 8 ポート E1 ゲートウェイ
7 WS-X6624-FXS 24 ポート Foreign Exchange Station(FXS)ゲートウェイ
8 WS-X6624-FXS 24 ポート FXS ゲートウェイ
9

Catalyst 4006 スイッチが設定され仕組みを次の表に示します。

スロット モジュール 説明
1 WS-X4013 2 つのギガビット イーサネット(GE)ポート搭載のスーパーバイザ 2
2 WS-X4148-RJ45V インライン パワー搭載の 48 ポート 10/100 モジュール
3 WS-X4148-RJ45V インライン パワー搭載の 48 ポート 10/100 モジュール
4 WS-X4148-RJ45V インライン パワー搭載の 48 ポート 10/100 モジュール
5 WS-X4148-RJ45V インライン パワー搭載の 48 ポート 10/100 モジュール
6 WS-X4148-RJ45V インライン パワー搭載の 48 ポート 10/100 モジュール

LAN インフラストラクチャの合計容量は、2,160 台の IP フォンを接続し、電力を供給するために必要です。

Catalyst 4006 スイッチは、純粋なハブアンドスポーク方式のスーパーバイザの GE ポートの 1 つを介して Catalyst 6509 に再接続します。 5 つのフロアの 4 つに、2 台の Catalyst 4006 スイッチがあり、5 番目のフロアに 1 台の Catalyst 4006 スイッチがあります。 次の図は、スイッチがフロア全体にどのように展開され、Catalyst 6509 スイッチにどのように再接続されるかを示しています。

/image/gif/paws/13968/65364.gif

Catalyst 6509 は、重大なシングル ポイント障害を構成します。 2 台目の Catalyst 6509 を追加し、Catalyst 4006 スーパーバイザのスペア GE のポートを使用して両方のコア スイッチに Catalyst 4006 をデュアルホーミングすることで、アベイラビリティの著しい改善を実現することができます。 この設計では、Catalyst 6509 のすべてのモジュールの複製に対する位置調整はほとんどありません。 それどころか、既存のモジュール(スーパーバイザ、GE、および FXS モジュール)を 2 台のシャーシにまたがって分割することができます。 ただし、PSTN 接続も 2 台のシャーシに分割できるように、8 ポート E1 モジュールを追加する必要があります。 この設計では、2 台の Cisco CallManager を別個のスイッチに接続することもできます。 これにより、Catalyst 6509 の障害が Cisco CallManager を完全に隔離してしないようにできます。

2 台目の Catalyst 6509 スイッチは、最初の提案の一部でした。 ただし、コストを考慮した結果、NB は単一の Catalyst 6509 に決定しました。

NB は、シスコの設計推奨事項に従って、別個の仮想 LAN(VLAN)で IP フォンとデータ デバイスを備えています。 各 Catalyst 4006 は、独自の音声 VLAN を備えています。 したがって、フロアごとに 2 つの音声 VLAN、合計 9 つの音声 VLAN があります。 各 Catalyst 4006 は、240 のポートを備えています。 したがって、各音声 VLAN は 240 台の IP フォンのホームにすることができます。 これは保守的な設計ですが、正常に動作しないデバイスがブロードキャストにより VLAN をフラッディングする場合、その影響を限定的なものにするメリットがあります。 Catalyst 6000 ファミリの MSFC が VLAN 間にルーティングされる場合、レイヤ 3 転送パフォーマンスは問題になりません。

65365.gif

すべてのデータ デバイスが、単一の大規模な VLAN に置かれています。 これは、シスコの設計推奨事項に適合していません。 ただし、これは内部運用およびメンテナンス要件に従って、NB によって指定された設計でした。 この単一のデータ VLAN はすべてのスイッチにまたがるため、この VLAN のレイヤ 2 ブロードキャスト ストームがすべての IP フォンに影響を及ぼす可能性があります。 このため、Catalyst スイッチの Quality of Service(QoS)の品質がより一層重要なものになります。 QoS については、このドキュメントの後半で説明されます。

この例は、Catalyst 4006 ポートの一般的な VLAN 設定を示しています。 この例では、音声 VLAN 110 とデータ VLAN 11 のスロット 5 に 48 ポートすべてを配置しています。

set port auxiliaryvlan 5/4-48 110 
set vlan 11 type ethernet state active 
set vlan 11 5/4-48

NB ネットワークには、次の 3 つの明確に区別される QoS の信頼境界があります。

  • Catalyst 4006 10/100 ポート。

  • Cisco CallManager に接続する Catalyst 6509 10/100 ポート。

  • Cisco 7200 ルータに接続する Catalyst 6509 10/100 ポート。

使用中の Catalyst 4000 10/100 モジュールは、1 つの受信(RX)キュー(1q1t)と 2 つの送信(Tx)キュー(2q1t)を備えています。 すべてのポートが、2 番目の TX キューを有効にし、2 番目のキューに 2 ~ 7 の間のサービス クラス(CoS)値を持つフレームを配置するように、コマンドによって設定されています。次に例を示します。 その結果、すべての Real-Time Transport Protocol(RTP)パケット(CoS=5)およびすべての Skinny パケット(CoS=3)が 2 番目のキューに入り、他のトラフィックはすべて最初のキューに入ります。

set qos enable
set qos map 2q1t 1 1 cos 0-1
set qos map 2q1t 2 1 cos 2-3
set qos map 2q1t 2 1 cos 4-5
set qos map 2q1t 2 1 cos 6-7

Catalyst 4006 は、ポリシングを一切サポートしていないことに注意してください。 また、そのポートで受信された任意のフレームの CoS を信頼します。 これは、IP フォンのデフォルトの動作が PC ポートで受信されたトラフィックを信頼しないこと、および CoS によって 0 に書き換えるため、IP フォンが接続されている限り問題ではなりません。 ただし、Catalyst 4006 ポートに直接接続された PC は、データが 802.1p フレームとして送信される場合、潜在的に QoS を利用することができます。 これは、かなり高度なユーザを必要とします。 ただし、Windows 2000 および標準イーサネット ネットワーク インターフェイス カード(NIC)は 802.1pq をサポートしています。

Catalyst 6509 の QoS 設定は、Catalyst 6509 のポートにさまざまなキュー構造があるため、次の表に示すように少し込み入っています。

モジュール 受信キュー 送信キュー
WS-X6K-SUP1A-MSFC 1p1q4t 1p2q2t
WS-X6416-GBIC 1q4t 2q1t
WS-X6408A-GBIC 1p1q4t 1p2q2t
WS-X6348-RJ45V 1p1q4t 1p2q2t

完全優先キューを持つポートが、デフォルトでそのキューに CoS=5 のすべてのフレームを配置します。 ただし、すべての VoIP シグナリング トラフィック(CoS=3 のフレーム)を 2 番目の非プライオリティ キューに配置することをお勧めします。 次の設定により、この動作が有効になります。

set qos map 1p2q2t tx 2 1 cos 3
set qos map 2q2t tx 2 1 cos 3

Catalyst 4006 スイッチに接続する GE ポートは、シスコの信頼境界内にあります。 通常、システムは受信したフレームの CoS を信頼します。 Catalyst 4006 の信頼境界は PC をスイッチ ポートに直接接続することによって侵害される可能性があるため、Catalyst 4006 スイッチからのトラフィックは信頼できないインターフェイスと見なされ、Catalyst 6509 によってポリシングされます。 ポリシングは、RTP、Skinny、H.225、および H.245 パケットを探すアクセス コントロール リスト(ACL)によって実行されます。 RTP パケット ヘッダーは、DSCP=46 に書き換えられる一方で、すべての VoIP シグナリング パケット ヘッダーは DSCP=26 に書き換えられます。 この ACL は、次の例に示すように、すべての GE ポートにマッピングされます。

set qos acl ip ACL_VOIP dscp 46 udp any any range 16384 32767
set qos acl ip ACL_VOIP dscp 46 udp any range 16384 32767 any
set qos acl ip ACL_VOIP dscp 26 tcp any any range 2000 2002
set qos acl ip ACL_VOIP dscp 26 tcp any range 2000 2002 any
set qos acl ip ACL_VOIP dscp 26 tcp any any eq 1720
set qos acl ip ACL_VOIP dscp 26 tcp any eq 1720 any
set qos acl ip ACL_VOIP dscp 26 tcp any any range 11000 11999
set qos acl ip ACL_VOIP dscp 26 tcp any range 11000 11999 any
set qos acl map ACL_VOIP 3/1-16,4/1-8,

Catalyst 6509 の 10/100 ポートの 2 つが、2 台の Cisco CallManager に接続するために使用されます。 これらは基本的に信頼できるポートですが、NB のネットワークでは信頼できないポートとして扱われ、Catalyst 6509 は、受信されたフレームで強制的に CoS=3 として扱います。 次の例は、ポート設定を示しています。

set vlan 110 5/2-3
set port qos 5/2-3 cos 3

代替となる、より巧妙なアプローチは、すべての VoIP シグナリング パケットで IP DiffServ コード ポイント(DSCP)値を設定するように Cisco CallManager を設定する方法です。 これを実行するには、Cisco CallManager で、サービス パラメータ IpTosCm2Cm および IpTosCm2Dvce0x26 に設定します。 Catalyst 6509 は、次の例に示すように、そのポートで受信したフレームに DSCP を信頼するように設定できます。

set port qos 5/2-3 trust trust-dscp

このアプローチには、VoIP 制御されるフレームのみ、および Cisco CallManager からのフレームではまれに、高い QoS を受信する利点があります。 これは、Cisco CallManager のアップグレード イメージが CallManager サーバにアップロードされる場合、または大量のコール詳細レコード(CDR)がサーバから定期的にプル オフされる場合に重要です。 現在、この種類のトラフィックも高い QoS を受信します。

最後に、Catalyst 6509 の 10/100 ポートの 1 つが、Cisco 7200 シリーズ WAN ルータに接続するために使用されます。 これはまた信頼できるポート、現在の Cisco IOS でありではない。 Cisco 7200 ルータで使用中 CoS フィールドに DSCP 値をコピーしません。 この問題を克服するために、スイッチ ポートは GE ポート(同じ ACL を使用して着信トラフィックを分類する)と同様に扱われ、これに基づいて QoS を選択的に提供します。 したがって、ルータ スイッチ ポートの設定は、次の例に示すようになります。

set vlan 10 5/1
set qos acl map ACL_VOIP 5/1

WAN インフラストラクチャ

NB IP テレフォニー ネットワークの WAN のコンポーネント小型です。 DBS ビルの Cisco 7200 シリーズ ルータは、NBAP と Capital Towers の両方に WAN リンクがあります。 ただし、NBAP へのリンクのみが音声を伝送します。 その場合にも、音声およびデータ用に DBS と NBAP 間に別個のリンクがあります。 音声品質の問題が導入の初期段階で発見され、コーデックを G.729 から G.711 に変更することに決まりました。 この結果、追加の帯域幅が必要になり、したがって WAN 上の音声とデータが分離されました。 これらの問題の原因は、その時点で使用中の IP フォンの負荷によって後で発見されました。 保守的な方法として、NB は G.711 を使用し続けることとし、音声およびデータ用 WAN リンクを短期的に分離することに決定しました。

現在、音声 WAN リンクは、マルチリンク PPP(MLP)によって、一緒にバンドルされている 3 つ物理 E1 リンクで構成されます。 リンクは比較的高速であるため、リンク フラグメンテーション/インターリービング(LFI)は不要です。 唯一必要な QoS 機能はキューイングです。 優先キューイング メカニズムは、低遅延キューイング(LLQ)です。 ただし、これは、リンクがダウンしたときに設定から service-policy コマンドが消えた LLQ および MLP による Cisco IOS の問題が原因で動作しませんでした。 暫定回避策として、プライオリティ キューイングが使用されています。 次の例は、現在の WAN 設定を示しています。

interface Multilink88
 ip address 10.104.209.73 255.255.255.248
 priority-group 1
 ppp multilink
 ppp multilink fragment-delay 10
 ppp multilink interleave
 multilink-group 88

interface Serial4/0
 bandwidth 2000
 encapsulation ppp
 ppp multilink
 multilink-group 88

interface Serial4/1
 bandwidth 2000
 encapsulation ppp
 ppp multilink
 multilink-group 88

interface Serial4/2
 bandwidth 2000
 encapsulation ppp
 ppp multilink
 multilink-group 88

priority-list 1 protocol ip high list 121
priority-list 1 protocol ip medium list 122
priority-list 1 default low
priority-list 1 queue-limit 500 40 60 80

access-list 121 permit udp any any range 16384 32767
access-list 121 permit udp any range 16384 32767 any
access-list 122 permit tcp any any range 2000 2002
access-list 122 permit tcp any range 2000 2002 any
access-list 122 permit tcp any any eq 1720
access-list 122 permit tcp any eq 1720 any
access-list 122 permit tcp any any range 11000 11999
access-list 122 permit tcp any range 11000 11999 any

現在の WAN 設定は折衷案であり、他の展開での使用はお勧めできません。 中期計画では、音声とデータを単一の WAN リンクに統合し、プライオリティ キューイングを LLQ と交換することになっています。 音声とデータ用の別個のリンクは、スタティック ルーティングまたはポリシーベース ルーティングを必要とし、ダイナミック ルーティング プロトコルを使用する利点が失われます。 高いキューが割り当てられた音声パケットによる場合であっても、音声パケットに厳密なプライオリティが与えられるかどうかは保証されません。 ルーティング アップデート、キープアライブなどのシステム トラフィックは、依然として高いキューの音声パケットよりも優先されます。

LLQ は Cisco IOS ソフトウェア リリース 12.2 で正しく動作することが確認されています。 次の例は、LLQ に移動後のルータ QoS を示しています。 帯域幅は 60 の同時 G.729 コール(RTP: 60 x 24 Kbps = 1440 kbps およびシグナリング: 60 x 0.5 Kbps = 30 kbps)に基づきます。

interface Multilink88
 service-policy output VoIP

class-map VoIP-RTP
 match access-group 121
class-map VoIP-Sig
 match access-group 122

policy-map VoIP
 class VoIP-RTP
  priority 1440
 class skinny
  bandwidth 30

access-list 121 permit udp any any range 16384 32767
access-list 121 permit udp any range 16384 32767 any
access-list 122 permit tcp any any range 2000 2002
access-list 122 permit tcp any range 2000 2002 any
access-list 122 permit tcp any any eq 1720
access-list 122 permit tcp any eq 1720 any
access-list 122 permit tcp any any range 11000 11999
access-list 122 permit tcp any range 11000 11999 any

IP テレフォニー

IP フォンおよびスイッチとの接続

DBS ビルには、約 750 台の IP Phone 7960 が設置されています。 IP フォンは、Catalyst 4006 の 10/100 ポートに接続され、スイッチからインライン パワーを受信します。 PC は、下図に示すように、IP フォンの背面にあるスイッチ ポートに接続します。

/image/gif/paws/13968/65373.gif

IP フォンと PC は、別個の VLAN および IP サブネット上にあります。

サイト計画

すべての IP フォンは、Catalyst 4006 のラインカードからインライン パワーを受信します。 スイッチ自体は 3 台のシャーシ内部の AC 電源で駆動します。 ただし、インライン パワーは Catalyst 4006 補助電源シェルフ(WS-P4603)から外部的に電源が供給されます。 電源シェルフには 3 台の電源装置があります。 それぞれ -52V DC で 1050W を供給します。 これは、240 ポートすべてに接続された Cisco IP Phone 7960 を含む完全に設定された Catalyst 4006 スイッチを駆動するのに十分です。

/image/gif/paws/13968/65366.gif

すべての Catalyst 4006 スイッチは、無停電電源装置(UPS)で駆動します。 これにより、停電時に 2 時間動作を継続できます。 Cisco CallManager は 4 時間駆動 UPS に接続します。

Cisco CallManager

NB の CallManager 導入モデルは、集中呼処理を使用した単一サイトです。 NBAP への WAN リンクおよびそこに配置されている関連ゲートウェイにより、このモデルは実際はマルチサイトであるとも言えます。 ただし、この事実は、コール アドミッション制御(CAC)が WAN を経由する必要がないため(ほとんどの場合)無視できます。 これは、WAN を経由するコールの数が、ゲートウェイを PBX に接続するトランクの数によって暗黙的に制限されるためです。

NB の Cisco CallManager クラスタは、2 台の Cisco Media Convergence Server 7835(MCS-7835)で構成されます。 1 方の CallManager がデータベース パブリッシング機能を実行し、他方の CallManager がデータベースにサブスクライブします。 すべての IP フォンがプライマリ Cisco CallManager としてサブスクライバ レッグに登録され、セカンダリ Cisco CallManager としてパブリッシャを使用します。

2 つの領域 NBAP と DBS が設定されています。 NBAP のゲートウェイが NBAP 領域の唯一のデバイスであり、他のすべてのデバイスは DBS 領域にあります。 所期の設計では、DBS ビル内のすべてのコールに G.711 を使用し、WAN を介したコールにのみ G.729 使用することになっています。 ただし現在は、WAN リンクを介したコールも G.711 が使用されています。

DBS 領域の IP フォンには、17000 ~ 17999 の範囲にある 5 桁の内線電話があります。 シンガポールには、4 桁と 5 桁の内線電話が混在する 5 つの他の NB サイトがあります。 次の表は NB シンガポールのサイトを示したものです。

サイト名 サイト コード 桁数
Department of Binding Singapore DBS 5
NB Acme Printing NBAP 5
Acme Building A ABA 4
Acme Building B ABB 5
Douglas Printing DP 4
Grant Printing GP 4

内線番号は、最初の数字によって内線番号が 4 桁か 5 桁であるかどうかが決まるように割り当てられます。 IP フォンのユーザが 4 または 5 桁の内線番号をダイヤルすることで、NB シンガポールの PBX 内線電話に電話をかけることができます。

ゲートウェイの統合」セクションの後半で説明されるとおり、ゲートウェイには次の 3 つのタイプがあります。

  • レガシー NB PBX ネットワークに接続する 1 つの Cisco 7200 H.323 ゲートウェイ。

  • PSTN に接続されている 3 つの Catalyst 6509 E1 ゲートウェイ。

  • ボイスメールに接続されている 2 つの Catalyst 6509 24 ポート FXS ゲートウェイ。

これは、Cisco CallManager ルート グループ設定に反映されます。 3 つのゲートウェイ タイプごとに 1 つのルート グループが存在します。 次の表は、各ルート グループの特性をまとめたものです。

ルート グループ プラットフォーム スロット/ポート ポート タイプ Priority
DBS VM Catalyst 6509 スイッチ 6/1-24 7/1-24 FXS FXS 1 2
DBS PSTN Catalyst 6509 スイッチ 8/1 8/2 8/3 PRI PRI PRI 1 2 3
NBAP レガシー Cisco 7200 ルータ 5/1-2 PRI 1

各種の宛先へのコールが次のようにルーティングされます。

  • PSTN へのコールは、DBS PSTN ルート グループを使用します。 バックアップはありません。

  • ボイスメールへのコールは、DBS VM ルート グループを使用します。 バックアップはありません。

  • NB Telnet サービスへのコールは、NBAP レガシー ルート グループを使用します。

  • NB シンガポールの PBX 内線電話へのコールは、プライマリ ルート グループとして NBAP レガシー ルート グループを使用し、セカンダリ ルート グループとして DBS PSTN ルート グループを使用します。

後は、適切なルート パターンを定義し、それらをルート グループにリンクすることだけです。 上記の最初の 3 つの項目については、1 つのルート リストが必要になるだけなので簡単です。 最後の項目は、バックアップ ルート グループのため、やや複雑な操作が必要になります。 IP フォンから PBX 内線電話へのコールの優先パスは、NBAP レガシー ルート グループ経由です。 このゲートウェイが使用できない場合、コールは DBS PSTN ルート グループを経由して PSTN を通じてルーティングされます。 これが発生すると、完全な PSTN 電話番号を作成するには、ダイヤルされる内線番号の前に桁数を付加する必要があります。 プレフィックスとして付加する桁数はコールされるサイトによって異なります。このため、サイトごとに異なるルート リストが必要になります。 PBX を持つ 5 つの NB サイト、およびサイトごとに複数の PSTN プレフィックスがあるため、これらは 10 ルート リストになります。

次の図は、すべての NB のルート リストを示します。 ほとんどのルート リストの名前に含まれる 2 桁または 3 桁の番号は、コールが DBS PSTN ルート グループに送信されるときは、必ずコールされる内線番号の前に付加される桁数を反映します。

/image/gif/paws/13968/65367.gif

特定の NB IP フォン ユーザは、コールできる数に制限があります。 これは、一部のパーティションにルート パターンおよび IP フォンの内線番号を設定することによって制御されます。 パーティションは、コーリング サーチ スペースにグループ化されます。 IP フォンはコーリング サーチ スペースに属し、このサーチ スペースのパーティションに含まれている番号のみコールすることができます。 次の表は、NB Cisco CallManager サーチ スペースとパーティションを示します。

サーチ スペース パーティション 説明
ゲスト DBS ユーザ DBS ゲスト NB SGP DBS コール アテンダント 通常の DBS ユーザの電話 ロビーおよびその他の公衆電話 NB シンガポールの PBX 内線電話の受付係
ユーザ DBS ユーザ NB GSDN NB Telnet SGP PSTN DBS ゲスト NB SGP IDD DBS コール アテンダント 通常の DBS のユーザの電話 - 世界規模の NB ネットワークによる国際通話 シンガポール における国内通話 ロビーおよびその他の公衆電話 NB シンガポールの PBX 内線 国際通話の受付係

ボイスメール統合

DBS は、Octel ボイスメール システムを使用します。 世界的な NB の標準であり、さまざまなシステム間のボイスメール ネットワーキングが求められていたので、このシステムが選択されました。

Cisco CallManager は、Catalyst 6509 スイッチの 2 つの 24 ポート FXS カードを通じて Octel ボイスメール システムに接続します。 使用可能な 48 ポートのうち 30 ポートのみ使用されます。 9600 bps の Simplified Message Desk Interface(SMDI)リンクは、プライマリ Cisco CallManager を Octel デバイスに接続します。

Octel システムは、企業の NB Octel ネットワークにも接続されます。 これは、古い Lucent Definity PBX に接続する Octel デバイスの 4 つの Foreign Exchange Office(FXO)のポートを通じて行われます。 次の図は、DBS Octel システムが新旧両方のシステムに接続する仕組みを示します。

/image/gif/paws/13968/65368.gif

注: 最初の設計には、PBX が含まれていませんでした。 むしろ、着想は 24 ポート FXS カードと VoIP ネットワークを介してボイスメールをネットワークに接続することでした。 ただし、試験運用時に、FXS カードが Octel デバイスからの Dual Tone Multi-Frequency(DTMF)トーンを処理する方法で問題が発生しました。 回避策として、24 ポート FXS カードが Cisco IOS ゲートウェイに置き換えられました。 この方法はうまくいきましたが、NB は PBX ベースのソリューションを選択しました。

ボイスメール ソリューションの復元力特性は注目に値します。 ボイスメール システム以外に、次に示すように他のシングル ポイント障害があります。

  • SMDI リンクが冗長ではない場合: プライマリ Cisco CallManager の障害は、ボイスメール システムを使用不能にします。 この状況が発生した場合、NB の取るべき戦略は SMDI ケーブルを手動でバックアップ Cisco CallManager に移動することです。 または、SMDI スプリッタにより、両方の CallManager が同時に接続できるようにして、自動フェールオーバーを可能にします。

  • 現在、24 ポート FXS カードは、両方とも同じ Catalyst 6509 シャーシに存在します。 Catalyst 6509 の障害は、ボイスメール システムを使用不能にします。 このドキュメントの前半で説明したとおり、2 台目の Catalyst 6509 を追加することで、復元力の観点から多くの得られるものがあります。

ゲートウェイの統合

次の表は、NB ネットワークの 3 つの異なる音声ゲートウェイのタイプを示します。

プラットフォーム インターフェイス タイプ ポート数 プロトコル 接続先
Catalyst 6509 PRI/E1 8 x 30 チャネル Skinny PSTN
Catalyst 6509 アナログ FXS 2 X 24 Skinny ボイスメール
7206VXR PRI/CAS/E1 2 x 30 チャネル H.323 レガシー PBX

Catalyst 6509 は、1 つの 8 ポート E1 カードを保持しています。 この 8 ポートのうちの 3 つが PRI を通じて PSTN に接続します。 各 E1 ポートには、独立したゲートウェイとして、独自の IP アドレスとポート機能があります。 ゲートウェイ間のコール ルーティングは、Skinny プロトコルを使用して Cisco CallManager によって制御されます。 ユーザは、0 の後に PSTN 番号をダイヤルすることにより、PSTN 番号に電話をかけます。 着信コールは先頭の桁数が取り去られ、コールは最後の 5 桁に基づいてコールされた IP フォンにルーティングされます。

ユーザは「9」をダイヤルして外線を選択し、Cisco CallManager は PSTN へのコールを提示する前に、この桁を削除します。 NB は、この桁を削除する 2 つの方法を試行しました。 最初の方法は、Cisco CallManager のルート パターンに「ドット」を含めて、PSTN に提示する前にプリドット桁数をすべて破棄するものです。 2 番目の方法は、Cisco CallManager でのゲートウェイ設定の一部として破棄を設定するものです。 これは、[Number of digits to strip] フィールドに 1 を設定することによってに行われます。 この 2 番目の方法は、IP フォンの [Placed calls] ディレクトリに番号が格納されるときに、先頭の「9」が保存されるため、より適切です。 これは、[editdial] を押して、先頭の「9」を追加する必要がないので、ユーザが後でディレクトリから番号をリダイヤルできることを意味します。

FXS ゲートウェイは、ボイスメールにのみ使用されます。 これらのゲートウェイは、Skinny を使用して Cisco CallManager によって制御されます。

Cisco 7200 ゲートウェイは、DBS の IP テレフォニー ネットワー世界規模の NB PBX ネットワーク間の接続を提供します。 このゲートウェイは、物理的に DBS ビルに配置されていない唯一の VoIP デバイスです。 これは Nbap ビルに配置され、WAN リンクを通じて到達します。

Cisco 7200 ゲートウェイには、1 つの 2 ポート E1 ポート アダプタが取り付けられ、H.323 を使用して CallManager と通信します。 両方の E1 ポートが NBAP にある Nortel Meridian に接続します。 1 方のポートが QSIG を使用し、他方が個別線信号方式を使用して PBX に通信します。 シンガポールの PBX 内線電話へのコールは QSIG ポートにルーティングされ、国際通話はプライベート音声ネットワーク(Telnet)を使用して、CAS ポートを通じてルーティングされます。

CAS と QSIG の混在は、設定が複雑になります。 CAS は、世界規模の Telnet 音声ネットワークを通じて、個人識別番号(PIN)コードが保護された国際ダイヤルへのアクセスを提供する必要があります。 ユーザがこのサービスに電話をかける場合、313xxxxxx にダイヤルします。ここで、xxxxxx は 6 桁の PIN コードです。 この PIN コードを認証する Meridian アプリケーションは、PRI ではサポートされていないようです。 したがって、この目的を達成するために、2 つのトランクの 1 つで CAS を使用する必要があります。

そうは言っても、CAS シグナリングは、QSIG トランクよりも容易に取りかかれることがわかりました。 発生した問題の中に、Meridian でのタイムスロットのロックアップと B チャネルの番号付けの不一致がありました。 ほとんどの問題は、Cisco 7200 および Meridian 側の設定パラメータに不一致と関係していました。 これらの問題は、Cisco IOS が Meridian の動作設定を提供した後に解決しました。

Meridian 設定のコピーは、下記に含まれています。 この設定は、ソフトウェア リリース 24.24 を実行する Meridian Option 11C からの引用です。 この設定をアクティブにするには、次のソフトウェア パッケージが必要にあります。

QSIG      263
QSIGGF    305
MASTER    309
QSIG-SS   316
ETSI-SS   323

次の設定は、Config Route Data Block ブロックからの引用です。

TYPE  RDB     (Route Data Block)
CUST  00      (Customer Number)
DMOD
ROUT  xx      (Route Number)
DES           (Trunk Description)
TKTP  TIE     (Trunk type - Tie Line or DID)
ESN   NO 
RPA   NO
CNVT  NO
SAT   NO
RCLS  INT     (Route Class - Internal or External)
DTRK  YES     (Digital Trunk - YES)
BRIP  NO
DGTP  PRI2    (Digital Group Type - PRI 30B + D)
ISDN  YES     (YES when DGTP is PRI or PRI2)
MODE  PRA     (ISDN/PRA Route)
IFC   ESGF    (ESGF req QSIG & QSIF GF Pkgs)
SBN   NO
PNI   00000
NCNA  NO
NCRD  NO
CTYP  UKWN
INAC  NO
ISAR  NO
CPFXS YES
DAPC  NO
INTC  NO
DSEL  VOD
PTYP  DTT
AUTO  NO
DNIS  NO
DCDR  NO
ICOG  IAO     (Bothway Trunk In and Out (IAO))
SRCH  RRB
TRMB  YES
STEP
ACOD  xxxx    (Trunk access code)
TCPP  NO
TARG  03
BILN  NO
OABS
INST
ANTK
SIGO  STD
MFC   NO
ICIS  YES
OGIS  YES
PTUT  0
TIMR  ICF     512
OGF   512
EOD   13952
NRD   10112
DDL   70
ODT   4096
RGV   640
GTO   896
GTI   896
SFB   3
NBS   2048
NBL   4096
IENB  5
TFD   0
VSS   0
VGD   6
DTD   NO
SCDT  NO
2 DT  NO
DRNG  NO
CDR   NO
NATL  YES
SSL
CFWR  NO
IDOP  NO
VRAT  NO
MUS   NO
PANS  YES
FRL   0 x
FRL   1 x
FRL   2 x
FRL   3 x
FRL   4 x
FRL   5 x
FRL   6 x
FRL   7 x
OHQ   NO
OHQT  00
CBQ   NO
AUTH  NO
TTBL  0
PLEV  2
OPR   NO
ALRM  NO
ART   0
PECL  NO
DCTI  0
TIDY  xx
SGRP  0
AACR

この設定は、D チャネルからの引用です。

ADAN  DCH 12      (D-Channel Number assigned by programmer)
CTYP  MSDL        (D-Channel Card type) 
CARD  02          (Card Location)
PORT  1           (Port Number) 
DES   CISCO_5300  (Description)
USR   PRI         (User type - PRI for ISDN PRA only)
DCHL  2           (Loop the D-Channel will be associated with)
OTBF  32          (Output request buffer)
PARM  RS422 DTE   (Default)
DRAT  64KC        (64kb/s Clear - Don't change) 
CLOK  EXT         (Clock Source - External)
NASA  NO          (Default NO)
IFC   ESIG        (ETSI Q Reference Signaling - MSDL D-Channel ONLY) 
ISDN_MCNT  300    (Default)
CLID  OPT0        (Opt0 is default for ESIG and ISIG interfaces)
CO_TYPE  STD      (100% Compatible)
SIDE  NET         (Network or User Side)
CNEG  2           (2 = Channel is indicated - alternative is accepted)
RLS   ID  **      (Default)
RCAP  COLP        (COLP is default for ESIG, ISIG interfaces)
MBGA  NO          (Default)
OVLR  NO          (Default)
OVLS  NO          (Default)
T310  120         (Default)
T200  3           (Default)
T203  10          (Default)
N200  3           (Default)
N201  260         (Default)
K     7           (Default)

これは PRI タイライン インターフェイスのループ タイマーの設定です。

LOOP 2

MFF    AFF
ACRC   NO
ALRM   REG
RAIE   NO
G1OS   YES
SLP    5       24 H    30    1 H
BPV    128    122
CRC    201     97
FAP    28       1
RATS   10
GP2    20     100 S    12 S    12 S    4 S
MNG1   60 S
NCG1   60 S
OSG1   60 S
MNG2   15 S
NCG2   15 S
OSG2   15 S
PERS   50
CLRS   50
OOSC   0

この設定は、B チャネルからの引用です。

TN     00x 0x      (LEN, TN (Terminal Number))
TYPE   TIE         (Trunk Type - Tie Line)
CDEN   SD          (Single Density Card
CUST   0           (Customer 0)
TRK    PRI2        (Trunk Type)
PDCA   x           (Pad Category Table)
PCML   A           (A-law or Mu-Law)
NCOS   0           (Network Class of Service)
RTMB   x y         (Route Member- x is router no., y is member no.)
B-CHANNEL SIGNALING
TGAR   0           (TGAR Restricted Dialing Leave as 0)
AST    NO          (Default)
IAPG   0           (Default)
CLS    CTD DIP WTA LPR APN THFD XREP BARD
P10    VNL         (Class of services)
TKID

ここでは、2 つの E1 トランクのゲートウェイ設定を示します。 ゲートウェイはネットワーク側で動作する一方、Meridian はユーザ側で動作することに注意してください。

controller E1 5/0
 pri-group timeslots 1-31

!-–– Defines PRI trunk.


controller E1 5/1
 framing NO-CRC4
 ds0-group 0 timeslots 1-15,17-31 type e&m-wink-start

!-–– CAS trunk.


interface Serial5/0:15
 isdn switch-type primary-qsig

!-–– Defines Q.SIG signaling.

 isdn protocol-emulate network

!-–– The network side.

 isdn incoming-voice voice
 isdn send-alerting
 isdn sending-complete

ゲートウェイには、15 の POTS ダイヤル ピアがあります。 ダイヤル ピアのほとんどは、PBX 側で到達可能なさまざまな PBX 内線番号を反映した QSIG トランクを指しています。

残りのダイヤル ピアは、Telnet 音声ネットワークへのコールを指示する CAS トランクを指しています。 また、QSIG トランクが、PBX に警告メッセージを返信するときに、値 8 を持つプログレス インジケータを取り込むように設定されていることに注意してください。 これは、ゲートウェイがインバンド リングバック トーンを提供し、コールが IP フォンによって応答されるであっても、PBX が音声パスをオープンするように PBX に指示ます。

dial-peer voice 33 pots
 preference 1
 destination-pattern 33.......
 direct-inward-dial
 port 5/1:0

!-–– Calls routed out of the CAS trunk.

 forward-digits all
!
dial-peer voice 313 pots
 destination-pattern 313......
 direct-inward-dial
 port 5/1:0
 forward-digits all
!
dial-peer voice 40000 pots
 destination-pattern 4....
 progress_ind alert enable 8

!-–– Gateway to provide ringback.

 direct-inward-dial
 port 5/0:15

!-–– Calls routed out of the QSIG trunk.

 forward-digits all
!
dial-peer voice 8 pots
 destination-pattern 8T
 progress_ind alert enable 8
 direct-inward-dial
 port 5/0:15
 forward-digits all
!
dial-peer voice 7 pots
 destination-pattern 7T
 progress_ind alert enable 8
 direct-inward-dial
 port 5/0:15
 forward-digits all
!
dial-peer voice 6 pots
 destination-pattern 6T
 progress_ind alert enable 8
 direct-inward-dial
 port 5/0:15
 forward-digits all
!
dial-peer voice 5 pots
 destination-pattern 5T
 progress_ind alert enable 8
 direct-inward-dial
 port 5/0:15
 forward-digits all
!
dial-peer voice 16 pots
 destination-pattern 16...
 progress_ind alert enable 8
 direct-inward-dial
 port 5/0:15
 forward-digits all
!
dial-peer voice 13 pots
 destination-pattern 13...
 progress_ind alert enable 8
 direct-inward-dial
 port 5/0:15
 forward-digits all
!
dial-peer voice 2 pots
 destination-pattern 2T
 progress_ind alert enable 8
 direct-inward-dial
 port 5/0:15
 forward-digits all
!
dial-peer voice 1000 pots
 destination-pattern 1...
 progress_ind alert enable 8
 direct-inward-dial
 port 5/0:15
 forward-digits all
!
dial-peer voice 10 pots
 destination-pattern 0...
 progress_ind alert enable 8
 direct-inward-dial
 port 5/0:15
 forward-digits all
!
dial-peer voice 3 pots
 destination-pattern 3...
 progress_ind alert enable 8
 direct-inward-dial
 port 5/0:15
 forward-digits all
!
dial-peer voice 508200 pots
 destination-pattern 5082..
 progress_ind alert enable 8
 port 5/0:15
 forward-digits all

VoIP ダイヤル ピアは 2 つしかなく、そのうち 1 つは各 Cisco CallManager を指しています。 ダイヤル ピアは優先設定を除き同一です。これにより、コールは確実にプライマリ Cisco CallManager にルーティングされます(使用可能な場合)。 progress_ind setup enable 3 は、設定メッセージのプログレス インジケータを通じて PBX に信号を送信するよう、ゲートウェイに指示します。 最後に、h225 timeout tcp establish 3 は、Cisco CallManager によって H.225 セッションを確立するときに、最大 3 秒間待つように、ゲートウェイに指示します。 Cisco CallManager が 3 秒以内に応答しない場合、ゲートウェイはセカンダリ Cisco CallManager を試行します。

dial-peer voice 17000 voip
 preference 1

!-–– Route to primary Cisco CallManager is preferred.

destination-pattern 17...
 progress_ind setup enable 3

!-–– Progress indicator = non-ISDN.

 voice-class h323 10
 session target ipv4:10.66.184.13
 dtmf-relay cisco-rtp h245-signal h245-alphanumeric
 codec g711ulaw
 ip precedence 5
 no vad
!
dial-peer voice 17001 voip
 preference 2
 destination-pattern 17...
 progress_ind setup enable 3
 voice-class h323 10
 session target ipv4:10.66.184.14
 dtmf-relay cisco-rtp h245-signal h245-alphanumeric
 codec g711ulaw
 ip precedence 5
 no vad

voice class h323 10
 h225 timeout tcp establish 3

NB IP テレフォニー プロジェクトの展開中に発生したほとんどの未解決の問題のいくつかはエコーに関係していました。 主なエコーの問題は、IP フォン ユーザが Cisco 7200 ゲートウェイを通じて特定の番号をコールしたときに体験していました。 エコーを減らそうとして講じられた取り組みが広範囲に及んだため、次の情報によって他の導入に役立つ可能性があるこの体験の一部を記録する試みが行われています。

IP テレフォニーの設計チームの当初の見込みは、Cisco 7200 ゲートウェイが VoIP 側と NBAP の 1 つの PBX 間の接続を提供することでした。 結果的に実際に提供されたものは、VoIP 側と非常に大規模な世界規模の NB 音声ネットワーク間の接続でした。 NB 音声ネットワークには、多くのエコー問題を含む、独自のレガシーがあります。 以前、NB はエコーの量を最小限に抑えるために、このネットワークのさまざまなノードの電力レベルを調整しようとしました。 Cisco 7200 ゲートウェイが接続していたネットワークは、既存のエコー問題を持つネットワークでした。 また、コールの宛先に応じて、信号電力のレベルが変動していました。 これは困難な統合でした。

パケット化された音声ソリューションの導入によって、さらに遅延が生じ、エコー問題が悪化しました。 この問題を処理するために、次の調整が行われました。

  • Cisco 7200 エコー キャンセラが、最もアグレッシブな設定に調整されました。

  • 入力ゲインが低下しました。

  • 2 つの E1 トランクで出力減衰が増加しました。

これによりエコーが減少する一方で、NB 音声ネットワークで特定の宛先へのコールを行うときに、音量レベルが非常に小さくなり、ユーザが苦情を申し立てるという望ましくない副作用が生じました。 レガシー側の信号レベルの不一致が原因で、すべての宛先間のコールに適したゲインと減衰の組み合わせが 1 つもありませんでした。 香港向けのコールではうまく動作したものが、韓国向けのコールでエコーが発生しました。 韓国向けに動作したものが香港向けでは低音量問題をもたらしました。 以下の設定は、Cisco 7200 ゲートウェイの音声ポートに対する現在の妥協による設定を示します。

voice-port 5/0:15
 input gain 0
 output attenuation 3
 echo-cancel coverage 32
 compand-type u-law
 cptone SG

voice-port 5/1:0
 input gain -2
 echo-cancel coverage 32
 compand-type u-law
 cptone SG
 timeouts interdigit 5
 timeouts wait-release infinity
 timing percentbreak 60

現在、開発技術陣が一部のシスコ製品のエコー キャンセル機能の改善に取り組んでいます。 NB は、さらにエコーを減らすために、これらの改善を心待ちにしています。

NB に代替ソリューションが提案されていますが、シスコの改善を待つことに決定しました。 他のプロジェクトにもあてはまる可能性を考慮して、2 つの提案された回避策について以下に説明します。 NB から学んだ一般的な教訓は、推奨された IP テレフォニー ソリューションが大規模なプライベート レガシー音声ネットワークに接続している場合、早期に赤いフラグのアラートを立てる必要があるということです。 これにより、以下の回避策を最初からソリューションの設計に組み込み、コストを下げることができます。

  • 回避策 1 - Cisco ゲートウェイと PBX 間にサードパーティ製エコー キャンセラを挿入します。 シスコのエコー キャンセリング技術は、現在 32 ミリ秒未満の遅延があるエコー テールを消去できます。 エコー信号は、少なくとも 6 dB のエコー リターン ロス(ERL)が適用される必要があります。つまり、受信したエコー信号は、元の送信信号より少なくとも 6 dB 低速になる必要があります。 これを有益なものにするためには、サードパーティ製キャンセラのパフォーマンスが上記の値を超える必要があります。

  • 回避策 2 - Cisco ゲートウェイと PBX 間のトランク数を増やします。 これにより、各トランクを異なるゲイン/減衰設定によって設定できるようになります。 コールは、最適のエコー特性によってトランク間をルーティングすることができます。 たとえば、香港へのコールがトランク 1 を通過する一方で、韓国へのコールがトランク 2 を通過するように設定できます。 また、PBX は、コールの発信元に基づき、正しいトランクを介してコールをルーティングできる必要があります。

コンファレンスおよびトランスコードのための DSP プロビジョニング

G.711 は現在ネットワーク全体に使用されていますが、意図は DBS と NBAP 間の WAN リンクにまたがって G.729 を使用することです。 設計は、会議用にハードウェア デジタル信号プロセッサ(DSP)のリソースを割り当てることにより、これを考慮しています。 ハードウェア リソースは、Catalyst 6509 上に存在します。 8 つの E1 ポートの 3 つだけが PSTN 接続に使用されていることに思い出してください。 残りの 5 つのポートのうち 3 つが会議に使用されます。

トランスコーディング リソースとして設定された Catalyst 6509 E1 モジュールに 2 つの未使用ポートがあります。 現在トランスコーディングの必要はありませんが、NB が IP 音声自動応答装置(IVR)サーバを導入することに決定した場合に必要になります。

ソフトウェア バージョン

次の表は、このドキュメントの執筆時点に NB ネットワークで使用されているソフトウェア バージョンを示します。

デバイス Version
Catalyst 6509 5.5(3)
Catalyst 4006 6.1(1)
Cisco 7260VXR 12.1(3a)XI5
Cisco CallManager 3.0(8)
IP Phone 7960 P003Q301
WS-X6608-E1 C001W300
WS-X6624-FXS A002S300

ネットワーク管理

現在、ネットワーク管理ツールは、NB IP テレフォニー ネットワークの管理に使用されていません。

学ぶべきレッスン

検出された異常、警告および解像度

次の表は、導入時に発生する主要な問題をまとめたものです。 これらの問題の詳細については、このドキュメントの前半で説明されています。

注意 解決策
パケット音声ネットワークを大規模レガシー音声ネットワークにインターフェイスする際にエコーが発生する。 追加のトランクに委任し、適切な設定によってコールをトランク全体にルーティングできるようにゲイン/減衰を変更します。 サードパーティ製エコー キャンセラを導入します。 シスコ エコー キャンセリング技術の改善を待ちます。
ゲートウェイとの PBX 側の QSIG パラメータが一致しない。 類似の設定を使用して、既存のサイトからの稼働している PBX の設定を取得します。
[placed-calls] ディレクトリに格納されていない外線を選択する桁数。 ゲートウェイ設定の先頭の桁数を破棄し、ルート パターンでプリドット破棄操作を使用しないでください。

TAC ケース

次の表は、TAC ケースに結びつくすべての問題を示します。 また、導入チームによってローカルに解決された、その他の重要な問題も含まれています。

- - - - - - - - - -
ケース番号 説明 ステータスと解決
B124306 QSIG チャネルのロックアウト。 Nortel PBX の LD17 Channel Negotiation(CNEG)パラメータを Option(2) から Option(1) に再設定することで、最初に解決されました。 ただし、しばらくしてから問題の症状が再発しました。 その後、PBX のベンダーは、PBX の PRI QSIG 設定を ESIG(GF QSIG 設定)から ESGF(ヨーロッパの QSIG 設定)に変更しました。 変更後、チャネル ロックアウトは発生しなくなりましたが、上限 15 のチャネルのみが機能しました。 この問題を是正するために、ISDN contiguous-bchan コマンドが VoIP ルータから削除されました。
A612818 Nortel PBX がコントロール チャネルとしてチャネル 31 を使用する一方で、シスコ音声ゲートウェイ PRI がチャネル 16 を使用する場合に、B チャネルが一致しない。 PRI QSIG インターフェイスで ISDN contiguous-bchan コマンドを設定することで解決されました。 このコマンドは、B チャネル 1 ~ 30(チャネル 16 を省略)がタイムスロット 1 ~ 31 にマッピングされるように、隣接するベアラー チャネルの処理を指定するために使用されます。 これは、primary-qsig スイッチ タイプ オプションが isdn switch-type コマンドを使用して設定されている場合にのみ、E1 PRI インターフェイスに使用できます。
B124306 エコー。 7200 エコー キャンセラがエコーをキャンセルを無効にできない可能性がある 2 つのシナリオがあります。 シナリオ 1: エコーが大きすぎるため、キャンセラはキャンセルを無効にできません。 シナリオ 2: エコーは、7200 キャンセラのカバレッジを超える 32 ミリ秒以上遅延します。 シナリオ 1: PBX の音声ゲートウェイおよびパディングで出力減衰と入力ゲインに調整を行うことで、エコーの状況が大幅に向上しました。 最終的な設定は次のとおりです。
  • Cisco 7200 PRI の入力ゲイン = 0
  • Ciisco 7200 PRI の出力減衰 = 3
  • Cisco 7200 CAS のゲイン = -2
  • Cisco 7200 CAS の出力減衰 = 0
  • PBX PRI TX の減衰 = 2
  • PBX PRI RX の減衰 = 4
  • PBX CAS TX の減衰 = 0
  • PBX CAS RX の減衰 = 5
残留エコーは、RTP ストリームの最初の 1 ~ 2 秒のスタティック ノイズとして発生します。 持続時間は、オーディオ ストリーム上でトレーニングし、効果的なキャンセルの輪郭を描くために適合アルゴリズムでは不可避です。 シナリオ 2: 32 ミリ秒を超えるエコー テールは、アナログ音声ネットワークで発生する可能性はありません。 ただし、パケット音声ネットワークでは発生する可能性があります。 エコー キャンセレーションのカバレッジは、現在最大 32 ミリ秒であり、サードパーティ製の G.168 対応エコー キャンセラ(少なくとも 64 ミリ秒のテール長さを持つ)を統合するコードを生成するために開発が行われている最中です。
クラッカー ノイズ、劣悪な音声品質(電話負荷)。 IP フォンにロードされた P003Q301 ファームウェア。 Q 負荷はジッターと遅延に対してより堅牢です。
QSIG を介して外線番号は呼び出したとき、IP フォンのリングバックが聞こえない。 ゲートウェイは、設定メッセージにプログレスインジケータ(PI)3(元の ISDN 発信元アドレス)を含むリングバック トーンを生成しません。 これは、ゲートウェイが、PI 3 なしで発信元スイッチが ISDN であり、リングバック トーンを生成するスイッチを予期すると仮定するためです。 PI 3 なしの設定で、ゲートウェイは、ISDN スイッチがリングを生成すると予期していますが、ISDN スイッチはリングを生成しません。 これは、ISDN インターネットワーキング問題に起因する可能性があります。 ゲートウェイがリングバック トーンを生成できるようにするには、VoIP ダイヤル ピア上で progress_ind を設定します。
dial-peer voice 1 voip
 destination-pattern 8...
  progress_ind setup enable 3
  session target ipv4:192.168.2.10
  dtmf-relay h245-alphanumeric
  codec g711ulaw
  ip precedence 5
上記は、ゲートウェイが、その VoIP ダイヤル ピアをタンデム アウトする ISDN に着信するコールにリングバック トーンを提供するようを強制します。
A695422 DTMF の持続時間には違いがあります。 これは、Catalyst がボイスメール システムによって送信される DTMF トーンを正しく認識していないという事実に起因する可能性があります。 Catalyst カードから着信する場合、DTMF の持続時間はデフォルトで 300 ミリ秒です。 ボイスメールから着信する場合、持続時間は 130 ミリ秒です。 Octel の仕様では、ハンドシェイキングが正しく動作するには、少なくとも毎秒 5 デジットが必要であることが求められます。 現在、Cisco CallManager は、持続時間が 300 ミリ秒、合計 300×5 = 1.5 秒間 H245-SIGNALLING を送信します。 この持続時間では、Octel 音声メールはボイスメール ネットワーキングのヘッダーを完全に受信する前にタイムアウトしてしまいます。 FXS カードによってロードされた Cisco 3640 ゲートウェイ(H.323 デバイス)を備えた 24 ポート FXS モジュール(Skinny デバイス)をバイパスしました。
音声ゲートウェイを経由するコールの片通話。 問題は、ループバック インターフェイスの IP アドレス以外の IP アドレスを選択するゲートウェイに起因します。 ループバックは、CallManager のトラフィックがルータを離れるインターフェイスです。 このインターフェイスに h323-gateway voip bind srcaddr ip address h323-gateway を挿入して、ルータに RTP 送信元アドレスとして指定された IP アドレスを使用するように強制します。
interface Loopback0
 description ::: Loopback for BGP peering
 ip address 192.170.94.34 255.255.255.255
 h323-gateway voip interface
 h323-gateway voip bind srcaddr 192.170.94.34
Cisco CallManager では、H.323 ゲートウェイ デバイスを名前から IP アドレスに変更します。 これは、逆 DNS/ホスト検索に伴う望ましくない問題を防ぐこともできます。
Cisco CallManager には、メモリ リークにより、時間の経過とともに徐々にサービスが低下する既知の問題があります。 一時的な解決策は、Cisco CallManager を毎週リブートすることです。 インストール済 Windows 2000 サービス パック 1 および CallManager サーバへの仮想メモリの修正。 追加の予防措置として、NB は、安定性を最大限確保するため、その後数か月にわたって CallManager を毎週リブートするように勧められました。 適切と思われる場合、NB は毎週リブートを中止する必要があります。
A944914 WFQ は、複数の 2 Mbps リンクを介したマルチ PPP では動作しません。 LLQ 実装のための Service-policy コマンドは、不確定の WAN 動作を示した後、しばらくしてから消滅します。 この問題を処理するために、次の 3 つのオプションを利用できます。
  • MPPP がバンドルされたすべてのインターフェイスの場合、シリアル インターフェイスの帯域幅を少なくとも 4800(4/3 X 3600)に設定します。
  • 12.2 のプレリリース バージョンである 12.2.018 にアップグレードします。 これは、サポートされる DE(TAC ではなく)です。 問題は、このバージョンで修正されます。
  • WAN QoS の別の種類のプライオリティ キューイングを実装します。
当初、電話機の [Message] ボタンが動作しませんでした。 [Message] ボタンを有効にするには、次の設定が必要です。
  • サービス パラメータでは、[VoiceMailDN] フィールドの値として、ボイスメールの内線番号を入力します。
  • エンタープライズ パラメータでは、[MessageDirectoryNumber] フィールドの値として、ボイスメールの内線番号を入力します。
Catalyst 6509 Skinny ゲートウェイ モジュールのアドレス解決プロトコル(ARP)コードのバグによる E1 カード(WS-X6608)からの高レベルのブロードキャスト トラフィック。 回避策として、E1 カード(WS-X6608)が別個の VLAN に設定されます。 これは、ARP キャッシュのサイズを最大 3 つのエントリに縮小します。 同時に、問題を解決するために、新しい Skinny ゲートウェイ ファームウェア アップグレード(D004R300)がモジュールにロードされました。
WAN リンク全体にわたる Cos の損失。 Cisco IOS ソフトウェア リリース 12.1(5)T 以降の新機能の 1 つは、ToS-to-CoS マッピングです。 これにより、Catalyst 6509 に何かを送信する前に、ルータを CoS=ToS に設定できます。 その後、Catalyst 6509 は、ルータ ポート上で trust-cos に設定され、そこから内部 DSCP 値を選択します。 Cisco QoS は、DSCP を使用して ToS および CoS 値を維持します。
ARP テーブルが破損したため、WS-X6624 カードを介してボイスメール システムにアクセスする際にオーディオ ストリームが失われます。 回避策として、FXS カード(WS-X6624)が別個の VLAN に設定されます。 これは、ARP キャッシュのサイズを最大 3 つのエントリに縮小します。 同時に、新しい Skinny ゲートウェイ ファームウェア アップグレード(A002S300)がモジュールにロードされました。
Octel ボイスメール デバイスに接続された FXS ポートの頻繁なハングの発生。 この問題は、アナログ(FXO)接続による Octel ボイスメール システムに共通と思われます。 ハングするポートの番号は、ボイスメール デバイスが異なる PBX システムとインターフェイスするときに変動する場合があります。 従来の PBX は、通常ボイスメールの操作全体に影響を与えることなく、ハングしたポートを個別にリセットする機能を備えています。 シスコは、ユーザが FXS カードの個別ポートをリセットおよびモニタできるようになる DickTracy ユーティリティを活用できるようにしました。 DickTracy ユーティリティは、ネットワーク上の PC にインストールできます。 このコマンドを実行し、WS-X6624 の IP アドレスに接続します。 接続が完了したら、[Option] をクリックします。 ロギングを開始し、コマンドライン フィールドに次のコマンドを入力します。 ポート ステータスを取得するには、5 show states を入力します(これは各ポートのステータスを示します。 DickTracy では、ポート番号は 0 をベースとします。 つまり、ブレードのポート 1 は、DickTracy ではポート 0 になります)。 ポートをリセットするには、次のように入力します。
4 set kill port[x] 

!--- Where x is the 0-based port number.

5 disable port x
5 enable port x
マルチリンク設定に使用できるモニタリングはありません。 個別シリアル リンクでは、IP を有効にできません。 インターフェイスのステータスをポーリングするには、簡易ネットワーク管理プロトコル(SNMP)を使用することを推奨します。 これを実行するには、いくつかの方法があります。 テスト対象のオプションは、snmpget コマンドを使用して UNIX スクリプトを作成し、ping script コマンドと同じ方法でインターフェイスのステータスを収集します。 もう 1 つのオプションは、インターフェイスのステータスを収集するために、MRTG(これは、インターフェイスの使用率を収集するフリーウェアの SNMP ツールです)の機能を拡張することです。 オプションで、SNMP ベースのネットワーク管理アプリケーションを使用する方法があります。
B300309 ルータがバス エラーにより定期的にリブートします。 Cisco Bug ID 問題 CSCdm74172登録ユーザ専用)で説明されているように、PA-2FEISL ハードウェアの初期リビジョンで、変則的なパケット処理動作が検出されました。 問題は、2 ポート ファースト イーサネット/ISL ポート アダプタのハードウェア変更によって解決されました。 次に示すハードウェア リビジョン番号以降の PA-2FEISL-xx カードは、この問題には該当しません。 PA-2FEISL-TX および PA-2FEISL-FX ハードウェア リビジョン 1.2 のハードウェア リビジョン 2.0 NB は、ハードウェア リビジョン 1.1 を使用していました。
A953213 Cisco CallManager User ページにアクセスできません。 この問題は、次の手順を使用して解決しました。
  1. [CCMAdmin] ページに移動します。 メイン メニューで [System] をクリックし、次に [Enterprise Parameters] をクリックします。
  2. [Enterprise Parameter] ページから、次のとおり LDAP を確認します。 Cisco ベースおよび LDAP: ユーザ ベース パラメータ。 (LDAP: Cisco ベースは o=cisco.com と LDAP: ユーザ ベースは =Users, o=cisco.com である必要があります)。
これらのパラメータを更新後、すべてのユーザがユーザ ページからログインできるようになりました。 この問題は、上記のパラメータが NULL である Cisco CallManager 3.0.4 で検出されました。

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

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


関連情報


Document ID: 13968