Cisco IOS XE で Webex Calling のローカル ゲートウェイを構成する
組織のシステムWebex Calling設定した後、トランクを構成して、ローカル ゲートウェイをユーザーに接続Webex Calling。SIP TLS トランスポートは、ローカル ゲートウェイと Webex クラウド間のトランクをセキュアにします。ローカル ゲートウェイとローカル ゲートウェイ間のメディアは、SRTP Webex Calling使用します。
概要
Webex Calling は現在、ローカル ゲートウェイの 2 つのバージョンをサポートしています。
-
ローカルゲートウェイ
-
政府版 Webex のローカル ゲートウェイ
-
開始する前に、Webex Calling のプレミスベースの公衆交換電話ネットワーク (PSTN) およびローカル ゲートウェイ (LGW) の要件を理解してください。詳細については 、「設定されたアーキテクチャ」Webex Calling を参照してください。
-
この記事では、専用のローカル ゲートウェイ プラットフォームが配置されているが、既存の音声構成がないと仮定しています。既存の PSTN ゲートウェイまたは CUBE エンタープライズ展開を Webex Calling のローカル ゲートウェイ機能として使用するように変更する場合は、設定に注意してください。変更を行ったため、既存の通話フローと機能を中断しないようにしてください。
サポートされているサードパーティ SBC の詳細については、各製品参照ドキュメントを参照してください。
システム トランクのローカル ゲートウェイを設定するための 2 つの Webex Calling があります。
-
登録ベースのトランク
-
証明書ベースのトランク
Webex Calling トランクのローカル ゲートウェイを設定するには、[登録ベースのローカル ゲートウェ イ] または [証明書ベースのローカル ゲートウェ イ] のタスク フローを使用します。
さまざまなトランクタイプの詳細については、「ローカル ゲートウェイの使い 方」を参照してください。コマンドラインインターフェース (CLI) を使用して、ローカル ゲートウェイ自体で以下の手順を実行します。セッション開始プロトコル (SIP) およびトランスポート層セキュリティ (TLS) トランスポートを使用してトランクを保護し、Secure Real Time Protocol (SRTP) を使用してローカル ゲートウェイと Webex Calling の間のメディアを保護します。
-
ローカル ゲートウェイとして [CUBE] を選択します。政府版 Webex は現在、サードパーティのセッション ボーダー コントローラ (SBC) をサポートしていません。最新のリストを確認するには、「ローカル ゲートウェイの使用を開始する」を参照してください。
- すべての Webex for Government Local Gateways に Cisco IOS XE Dublin 17.12.1a 以降のバージョンをインストールします。
-
政府版 Webex がサポートするルート証明機関 (CA) のリストを確認するには、「 政府版 Webex のルート証明機関」を参照してください。
-
政府版 Webex のローカル ゲートウェイの外部ポート範囲の詳細については、政府版 Webex のネットワーク要件 (FedRAMP) を参照してください。
政府版 Webex のローカル ゲートウェイは以下をサポートしていません。
-
メディアパス最適化のためのSTUN/ICE-Lite
-
ファクス (T.38)
政府版 Webex の Webex Calling トランクのローカル ゲートウェイを設定するには、次のオプションを使用します。
-
証明書ベースのトランク
証明書ベースのローカル ゲートウェイの下の タスク フローを使用して、Webex Calling トランクのローカル ゲートウェイを設定します。証明書ベースのローカル ゲートウェイを設定する方法の詳細については、「Webex Calling 証明書ベースのトランクの設定」を参照してください。
政府版 Webex のローカル ゲートウェイをサポートするには、FIPS 準拠の GCM 暗号を設定する必要があります。そうでない場合、コールのセットアップは失敗します。設定の詳細については、「Webex Calling 証明書ベースのトランクの設定」を参照してください。
このセクションでは、登録 SIP トランクを使用して、Webex Calling のローカル ゲートウェイとして Cisco Unified Border Element(CUBE)を設定する方法について説明します。このドキュメントの最初の部分は、シンプルな PSTN ゲートウェイを設定する方法を示しています。この場合、PSTN からのすべてのコールは Webex Calling にルーティングされ、Webex Calling からのすべてのコールは PSTN にルーティングされます。下の画像では、このソリューションとそれに続く高レベルのコール ルーティング設定が強調されています。
この設計では、次の主な構成が使用されます。
-
音声クラスのテナント: トランク固有の設定を作成するために使用されます。
-
音声クラスuri: 着信ダイヤルピアの選択のための SIP メッセージを分類するために使用。
-
着信ダイヤルピア: 着信 SIP メッセージの処理を提供し、ダイヤルピア グループを使用して発信ルートを決定します。
-
ダイヤルピア グループ: オンワード コール ルーティングに使用する発信ダイヤル ピアを定義します。
-
発信ダイヤルピア: アウトバウンド SIP メッセージの処理を提供し、必要なターゲットにルーティングします。
IP および SIP は PSTN トランクのデフォルトのプロトコルになりましたが、TDM (Time Division Multiplexing) ISDN 回路はまだ広く使用されており、Webex Calling トランクでサポートされています。TDM-IP コール フローでローカル ゲートウェイの IP パスのメディア最適化を有効にするには、現在、2 レッグのコール ルーティング プロセスを使用する必要があります。このアプローチは、下の画像に示すように、Webex Calling と PSTN トランクの間に一連の内部ループバックダイヤルピアを導入することにより、上記のコール ルーティング設定を変更します。
オンプレミスの Cisco Unified Communications Manager ソリューションを Webex Calling に接続する場合、次の図に示すソリューションを構築するためのベースラインとしてシンプルな PSTN ゲートウェイ設定を使用できます。この場合、Unified Communications Manager は、すべての PSTN および Webex Calling コールの集中ルーティングと処理を提供します。
このドキュメントでは、次の画像に示すホスト名、IP アドレス、およびインターフェイスが使用されます。
このドキュメントの残りの構成ガイダンスを使用して、ローカル ゲートウェイの設定を次のように完了します。
-
ステップ 1:ルーターのベースライン接続とセキュリティを設定する
-
ステップ 2: Webex Calling トランクの設定
必要なアーキテクチャに応じて、次のいずれかを実行します。
-
ステップ 3: SIP PSTN トランクを使用したローカル ゲートウェイの設定
-
ステップ 4: ローカル ゲートウェイを既存の Unified CM 環境で構成する
または:
-
ステップ 3: TDM PSTN トランクを使用したローカル ゲートウェイの設定
ベースラインの設定
Webex Calling のローカル ゲートウェイとして Cisco ルータを準備する最初のステップは、プラットフォームを保護し、接続を確立するベースライン設定を構築することです。
-
すべての登録ベースのローカル ゲートウェイ展開には、Cisco IOS XE 17.6.1a 以降のバージョンが必要です。Cisco IOS 17.12.2 以降を推奨します。推奨されるバージョンについては、「Cisco Software Research 」ページを参照してください。プラットフォームを検索し、提 案されたリリースのいずれかを選択します。
-
ISR4000 シリーズ ルータは、Unified Communications および Security テクノロジー ライセンスの両方で設定する必要があります。
-
Catalyst Edge 8000シリーズのルーターには、ボイスカードまたはDSPが搭載されており、DNA Advantageライセンスが必要です。ボイスカードやDSPのないルーターには、最低限のDNA Essentialsライセンスが必要です。
-
-
ビジネスポリシーに従うプラットフォームのベースライン設定を構築します。特に、以下を構成し、検証します。
-
NTP
-
Acl
-
ユーザー認証とリモートアクセス
-
DNS
-
IP ルーティング
-
IP アドレス
-
-
Webex Calling に向かうネットワークは IPv4 アドレスを使用する必要があります。
-
Cisco ルート CA バンドルをローカル ゲートウェイにアップロードします。
構成
1 |
次のように、有効でルーティング可能な IP アドレスをレイヤ 3 インターフェイスに割り当てます。
|
2 |
対称暗号化を使用して、ルータ上の登録と STUN クレデンシャルを保護します。プライマリ暗号化キーと暗号化タイプを次のように設定します。
|
3 |
プレースホルダー PKI トラストポイントを作成します。 後で TLS を設定するには、このトラストポイントが必要です。登録ベースのトランクの場合、このトラストポイントは証明書を必要としません。証明書ベースのトランクでも必須です。 |
4 |
TLS1.2 排他を有効にし、次の設定コマンドを使用してデフォルトのトラストポイントを指定します。登録のための信頼性の高い安全な接続を確保するために、トランスポートパラメータも更新する必要があります。 cn-san-validate server コマンドは、テナント 200 で設定されたホスト名がアウトバウンド プロキシから受信した証明書の CN または SAN フィールドに含まれている場合に、ローカル ゲートウェイが接続を許可することを保証します。
|
5 |
Webex Calling で使用される DigiCert CA 証明書を含む Cisco ルート CA バンドルをインストールします。crypto pki trustpool import clean url コマンドを使用して、指定された URL からルート CA バンドルをダウンロードし、現在の CA トラストプールをクリアし、証明書の新しいバンドルをインストールします。 HTTPS を使用してインターネットにアクセスするためにプロキシを使用する必要がある場合は、CA バンドルをインポートする前に、次の設定を追加します。 ip httpクライアントプロキシサーバーyourproxy.comプロキシポート80 |
1 |
Control Hub の既存のロケーションに登録ベースの PSTN トランクを作成します。トランクが作成されると、提供されたトランク情報をメモします。図で強調表示されている詳細は、このガイドの設定手順で使用します。詳細については、「Webex Calling のトランク、ルート グループ、ダイヤル プランの設定」を参照してください。 |
2 |
次のコマンドを入力して、CUBE を Webex Calling ローカル ゲートウェイとして設定します。 以下は、設定のフィールドの説明です。
プラットフォームで Cisco Unified Border Element(CUBE)機能を有効にします。 メディア統計ローカル ゲートウェイ上のメディア監視が可能です。 メディア一括統計一括通話統計のために、コントロール飛行機がデータ 飛行機をポーリングできます。 これらのコマンドの詳細については、「メディア」を参照してください。 allow-connections sip to sipCUBE 基本 SIP バックツーバック ユーザ エージェント機能を有効にします。詳細については、「接続を許可」を参照してください。 デフォルトでは、T.38 ファックス転送が有効になっています。詳細については、ファックスプロトコルt38 (音声サービス)を参照してください。 STUN (NAT を介した UDP のセッショントラバーサル) をグローバルに有効にします。
詳細については、「stun flowdata agent-i d」および「stun flowdata shared-secret」を参照してください。 非対称ペイロード フルDTMF と動的コーデック ペイロードの両方に対して SIP 非対称ペイロード サポートを設定します。詳細については、非対称ペイロードを参照してください。 early-offer forcedローカル ゲートウェイは、隣接するピアからの確認を待つ代わりに、最初の INVITE メッセージで SDP 情報を送信するように強制します。このコマンドの詳細については、早期提供を参照してください。 |
3 |
すべてのトランクに対して G.711 コーデックのみを許可する音声クラス コーデック 100 を設定します。このシンプルなアプローチは、ほとんどの導入に適しています。必要に応じて、発信元システムと終端システムの両方でサポートされている追加のコーデック タイプをリストに追加できます。 DSP モジュールを使用したトランスコーディング を含むより複雑なソリューションはサポートされていますが、このガイドには含まれていません。 以下は、設定のフィールドの説明です。 音声クラス コーデック 100SIP トランク コールの優先コーデックのみを許可するために使用されます。詳細については、「音声クラスコーデック」を参照してください。 |
4 |
音声クラス stun-usage 100 を設定して、Webex Calling トランクで ICE を有効にします。 以下は、設定のフィールドの説明です。 スタンの使用法 アイス ライトすべての Webex Calling のダイヤルピアに対して ICE-Lite を有効にして、可能な限り、メディア最適化を可能にするために使用。詳細については、「voice class stun usag e」および「stun usage ice lite」を参照してください。 メディアの最適化は、可能な限り、ネゴシエートされます。通話に録画などのクラウド メディア サービスが必要な場合、メディアを最適化できません。 |
5 |
Webex トラフィックのメディア暗号化ポリシーを設定します。 以下は、設定のフィールドの説明です。 音声クラス srtp-crypto 100SDP の SRTP 暗号スイート CUBE オファーおよび応答メッセージの唯一の SRTP オファーとして SHA1_80 を指定します。Webex Calling は SHA1_80 のみをサポートします。詳細については、音声クラス srtp-crypto を参照してください。 |
6 |
宛先トランク パラメータに基づいて、ローカル ゲートウェイ トランクへのコールを識別するためのパターンを設定します。 以下は、設定のフィールドの説明です。 音声クラス uri 100 sip着信トランク ダイヤル ピアへの着信 SIP 招待と一致するパターンを定義します。このパターンを入力する場合、トランクが作成されたときに、dtg= の後に Control Hub で提供されるトランク OTG/DTG 値を使用します。詳細については、音声クラス uri を参照してください。 |
7 |
sip プロファイル 100 を構成します。これは、Webex Calling に送信される SIP メッセージを変更するために使用されます。
以下は、設定のフィールドの説明です。
米国またはカナダの PSTN プロバイダーは、Webex Calling のスパムまたは詐欺コールの表 示で言及されている追加設定を使用して、スパムおよび詐欺コールの発信者 ID 検証を提供できます。 |
8 |
Webex Calling トランクの設定: |
テナント 100 を定義し、SIP VoIP ダイヤルピアを設定すると、ゲートウェイは、Webex Calling に対して TLS 接続を開始します。この時点で、アクセス SBC は証明書をローカル ゲートウェイに提示します。ローカル ゲートウェイは、以前に更新された CA ルート バンドルを使用して、Webex Calling アクセス SBC 証明書を検証します。証明書が認識されると、ローカル ゲートウェイと Webex Calling アクセス SBC の間で永続的な TLS セッションが確立されます。ローカル ゲートウェイは、このセキュアな接続を使用して Webex アクセス SBC に登録できます。登録が認証にチャレンジされた場合:
-
レスポンスには、クレデンシャ ル設定のusername、password 、およびreal mパラメータが使用されます。
-
sip プロファイル 100 の変更ルールは、SIPS URL を SIP に変換するために使用されます。
アクセスSBCから200 OKを受信すると、登録が成功します。
上記の Webex Calling に対してトランクを構築した後、次の設定を使用して、SIP ベースの PSTN プロバイダーに対して暗号化されていないトランクを作成します。
サービス プロバイダーがセキュアな PSTN トランクを提供している場合、上記の Webex Calling トランクと同様の構成に従うことができます。CUBE はセキュアなコール ルーティングをサポートします。
TDM / ISDN PSTN トランクを使用している場合は、次のセクション [TDM PSTN トランクでローカル ゲートウェイを設定する] に進みます。
Cisco TDM-SIP ゲートウェイで PSTN コール レッグの TDM インターフェイスを設定するには、「ISDN PRI の設定」を参照してください。
1 |
PSTN トランクからの着信コールを識別するには、次の音声クラス uri を設定します。 以下は、設定のフィールドの説明です。 音声クラス uri 200 sip着信トランク ダイヤル ピアへの着信 SIP 招待と一致するパターンを定義します。このパターンを入力する場合は、IP PSTN ゲートウェイの IP アドレスを使用します。詳細については、音声クラス uri を参照してください。 |
2 |
次の IP PSTN ダイヤル ピアを設定します。 以下は、設定のフィールドの説明です。 200のタグ を含むVoIPダイヤルピアを定義し、管理とトラブルシューティングを容易にするための意味のある説明を提供します。詳細については、ダイヤルピアの音声を参照してください。 宛先パターン BAD.BAD着信ダイヤル ピア グループを使用して発信コールをルーティングする場合は、ダミー接続先パターンが必要です。この場合、有効な宛先パターンを使用できます。詳細については、destination-pattern (interface)を参照してください。 session protocol sipv2このダイヤル ピアが SIP コール レッグを処理することを指定します。詳細については、セッションプロトコル (ダイヤルピア)を参照してください。 セッション ターゲット ipv4: 192.168.80.13PSTN プロバイダーに送信されるコールのターゲット アドレスを指定します。これは IP アドレスまたは DNS ホスト名です。詳細については、セッションターゲット (VoIP ダイヤルピア)を参照してください。 200 経由の着信 uriINVITE VIA ヘッダー URI を使用して、着信コールをこのダイヤルピアに照合するために使用される音声クラスを指定します。詳細については、着信 URLを参照してください。 音声クラス sip asserted-id pai
(オプション) P-Asserted-Identity ヘッダー処理をオンにし、これが PSTN トランクに使用する方法を制御します。このコマンドが使用されている場合、着信ダイヤルピアから提供された発信側 ID は、発信元および P-Asserted-Identity ヘッダーに使用されます。このコマンドが使用されていない場合、着信ダイヤルピアから提供された発信側 ID は、発信元および Remote-Party-ID ヘッダーに使用されます。詳細については、voice-class sip asserted-idを参照してください。 バインド制御ソースインタフェース GigabitEthernet0/0/0
PSTN に送信されるメッセージのソース インターフェイスと関連する IP アドレスを設定します。詳細は、bindを参照してください。 バインド メディア ソース インターフェイス GigabitEthernet0/0/0PSTN に送信されるメディアのソース インターフェイスおよび関連する IP アドレスを設定します。詳細は、bindを参照してください。 音声クラス コーデック 100共通のコーデック フィルタ リスト 100 を使用するようにダイヤル ピアを設定します。詳細については、音声クラスコーデックを参照してください。 dtmf-relay rtp-nte通話レグで予想される DTMF 機能として RTP-NTE (RFC2833) を定義します。詳細については、「DTMF Relay (Voice over IP)」を参照してください。 no vad音声アクティブティの検出を無効にします。詳細については、vad(ダイヤルピア)を参照してください。 |
3 |
ローカル ゲートウェイを Webex Calling と PSTN 間のコールのみルーティングするように設定している場合は、次のコール ルーティング設定を追加します。Unified Communications Manager プラットフォームを使用してローカル ゲートウェイを設定する場合は、次のセクションに進みます。 |
Webex Calling に向けてトランクを構築した後は、次の設定を使用して、Webex コール レッグのメディア最適化を可能にするために、ループ バック コール ルーティングを備えた PSTN サービスの TDM トランクを作成します。
IP メディア最適化を必要としない場合は、SIP PSTN トランクの設定手順に従います。PSTN VoIP ダイヤル ピアの代わりに、ボイス ポートと POTS ダイヤル ピア(手順 2 および 3 を参照)を使用します。
1 |
ループ バック ダイヤル ピア構成では、ダイヤル ピア グループとコール ルーティング タグを使用して、コール ルーティング ループを作成せずに、Webex と PSTN の間でコールが正しく渡されるようにします。コール ルーティング タグの追加と削除に使用する次のトランスレーション ルールを設定します。 以下は、設定のフィールドの説明です。 音声翻訳ルールルールで定義された正規表現を使用して、コール ルーティング タグを追加または削除します。Over-decadic digits (A) は、トラブルシューティングの明瞭さを追加するために使用されます。 この設定では、translation-profile 100 によって追加されたタグを使用して、ループバックダイヤルピア経由で Webex Calling から PSTN へのコールをガイドします。同様に、translation-profile 200 によって追加されたタグは、PSTN から Webex Calling へのコールをガイドするために使用されます。翻訳プロファイル 11 と 12 は、Webex トランクと PSTN トランクにコールを配信する前に、これらのタグを削除します。 この例では、Webex Calling からの着信番号が +E.164 形式で表示されていることを前提としています。ルール 100 は、有効な着信番号を維持するために、先頭の + を削除します。ルール 12 では、タグを削除するときに、国内または国際的なルーティング番号を追加します。ローカル ISDN ナショナル ダイヤル プランに合った数字を使用します。 Webex Calling が全国形式で番号を提示する場合、ルール 100 と 12 を調整して、ルーティング タグをそれぞれ追加および削除するだけです。 詳細については、「voice translation-profil e」および「voice translation-rule」を参照してください。 |
2 |
使用するトランク タイプとプロトコルによって必要に応じて、TDM 音声インターフェイス ポートを設定します。詳細については、「ISDN PRIの設定」を参照してください。たとえば、デバイスの NIM スロット 2 にインストールされているプライマリレート ISDN インターフェイスの基本設定には、次のものが含まれます。 |
3 |
次の TDM PSTN ダイヤル ピアを設定します。 以下は、設定のフィールドの説明です。 200のタグを含むVoIPダイヤルピアを定義し、管理とトラブルシューティングを容易にするための意味のある説明を提供します。詳細については、ダイヤルピアの音声を参照してください。 宛先パターン BAD.BAD着信ダイヤル ピア グループを使用して発信コールをルーティングする場合は、ダミー接続先パターンが必要です。この場合、有効な宛先パターンを使用できます。詳細については、destination-pattern (interface)を参照してください。 translation-profile incoming 200着信着信番号にコール ルーティング タグを追加するトランスレーション プロファイルを割り当てます。 ダイレクト インワード ダイヤルセカンダリ ダイヤル トーンを提供せずにコールをルーティングします。詳細は、ダイレクト インワード ダイヤルを参照してください。 ポート 0/2:0:15このダイヤル ピアに関連付けられている物理的な音声ポート。 |
4 |
TDM-IP コール フローでローカル ゲートウェイの IP パスのメディア最適化を有効にするには、Webex Calling と PSTN トランクの間に一連の内部ループ バック ダイヤル ピアを導入して、コール ルーティングを変更できます。次のループバックダイヤルピアを設定します。この場合、すべての着信コールは最初にダイヤルピア 10 にルーティングされ、そこから適用されたルーティング タグに基づいてダイヤルピア 11 または 12 にルーティングされます。ルーティング タグを削除すると、コールはダイヤル ピア グループを使用して発信トランクにルーティングされます。 以下は、設定のフィールドの説明です。 VoIP ダイヤル ピアを定義し、管理とトラブルシューティングを容易にするための意味のある説明を提供します。詳細については、ダイヤルピアの音声を参照してください。 translation-profile 着信 11先に定義したトランスレーション プロファイルを適用して、発信トランクに渡す前にコール ルーティング タグを削除します。 宛先パターン BAD.BAD着信ダイヤル ピア グループを使用して発信コールをルーティングする場合は、ダミー接続先パターンが必要です。詳細については、destination-pattern (interface)を参照してください。 session protocol sipv2このダイヤル ピアが SIP コール レッグを処理することを指定します。詳細については、セッションプロトコル (ダイヤルピア)を参照してください。 セッション ターゲット ipv4: 192.168.80.14ループ バックのコール ターゲットとしてローカル ルータ インターフェイス アドレスを指定します。詳細については、セッションターゲット (voip ダイヤルピア)を参照してください。 バインド制御ソースインタフェース GigabitEthernet0/0/0ループバックを介して送信されるメッセージのソース インターフェイスおよび関連する IP アドレスを設定します。詳細は、bindを参照してください。 バインド メディア ソース インターフェイス GigabitEthernet0/0/0ループバックを介して送信されるメディアのソース インターフェイスおよび関連する IP アドレスを設定します。詳細は、bindを参照してください。 dtmf-relay rtp-nte通話レグで予想される DTMF 機能として RTP-NTE (RFC2833) を定義します。詳細については、「DTMF Relay (Voice over IP)」を参照してください。 コーデック g711alaw すべての PSTN コールに G.711 を使用するように強制します。ISDN サービスで使用されるコンパニオン方法に一致するように、a-law または u-law を選択します。 no vad音声アクティブティの検出を無効にします。詳細については、vad(ダイヤルピア)を参照してください。 |
5 |
次のコール ルーティング設定を追加します。 これでローカル ゲートウェイの設定は終了します。CUBE 機能が初めて設定される場合は、設定を保存し、プラットフォームをリロードします。
|
前のセクションの PSTN-Webex Calling 設定は、Cisco Unified Communications Manager (UCM) クラスタへの追加のトランクを含めるように変更される場合があります。この場合、すべてのコールは Unified CM 経由でルーティングされます。ポート 5060 の UCM からのコールは PSTN にルーティングされ、ポート 5065 からのコールは Webex Calling にルーティングされます。次の増分設定を追加して、この通話シナリオを含めることができます。
Unified CM で Webex Calling トランクを作成する場合は、SIP トランク セキュリティ プロファイルの設定で着信ポートを 5065 に設定してください。これにより、ポート 5065 の着信メッセージを許可し、ローカル ゲートウェイにメッセージを送信するときに、この値を VIA ヘッダーに入力します。
1 |
以下の音声クラス URI を設定: |
2 |
次の DNS レコードを設定して、Unified CM ホストへの SRV ルーティングを指定します。 IOS XE は、これらのレコードをローカルでターゲット UCM ホストとポートを決定するために使用します。この設定では、DNS システムでレコードを設定する必要はありません。DNS を使用する場合は、これらのローカル設定は必要ありません。 以下は、設定のフィールドの説明です。 次のコマンドは、DNS SRV リソース レコードを作成します。各 UCM ホストとトランクのレコードを作成します。 ip ホスト _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub5.mydomain.com _sip._udp.pstntocucm.io: SRV リソースレコード名 2: SRV リソースレコードの優先順位 1: SRV リソースレコードの重み 5060: このリソース レコードでターゲット ホストに使用するポート番号 ucmsub5.mydomain.com: リソースレコードターゲットホスト リソースレコードのターゲットホスト名を解決するには、ローカル DNS A レコードを作成します。たとえば、次のようなものです。 ip ホスト ucmsub5.mydomain.com 192.168.80.65 IPホスト: ローカル IOS XE データベースにレコードを作成します。 ucmsub5.mydomain.com: A レコードのホスト名。 192.168.80.65: ホスト IP アドレス。 SRV リソース レコードと A レコードを作成し、UCM 環境と優先コール分配戦略を反映させます。 |
3 |
次のダイヤルピアを設定します。 |
4 |
次の設定を使用してコール ルーティングを追加します。 |
診断署名 (DS) は、IOS XE ベースのローカル ゲートウェイで共通に観察される問題を積極的に検出し、イベントのメール、syslog、またはターミナル メッセージ通知を生成します。また、DS をインストールして、診断データ収集を自動化し、収集したデータを Cisco TAC ケースに転送して、解決時間を短縮することもできます。
診断署名 (DS) は、問題のトリガー イベントと問題を通知、トラブルシューティング、修正するために取られるアクションに関する情報を含む XML ファイルです。syslog メッセージ、SNMP イベント、および特定の show コマンド出力の定期的なモニタリングを使用して、問題検出ロジックを定義できます。
アクションタイプには、show command 出力の収集が含まれます。
-
統合ログファイルの生成
-
HTTPS、SCP、FTP サーバなどのユーザー提供のネットワークロケーションにファイルをアップロードします。
TAC エンジニアは DS ファイルの作成者であり、整合性保護のためにデジタル署名します。各 DS ファイルには、システムによって割り当てられた固有の数値 ID があります。Diagnostic Signatures Lookup Tool (DSLT)は、さまざまな問題を監視およびトラブルシューティングするための適切な署名を見つけるための単一のソースです。
開始する前に:
-
DSLT からダウンロードした DS ファイルは 編集していない。変更するファイルは、整合性チェックエラーのためインストールに失敗します。
-
ローカル ゲートウェイがメール通知を送信するために必要な簡易メール転送プロトコル (SMTP) サーバー。
-
メール通知に安全な SMTP サーバーを使用する場合は、ローカル ゲートウェイが IOS XE 17.6.1 以上を実行中か確認してください。
前提条件
IOS XE 17.6.1a 以降を実行しているローカル ゲートウェイ
-
診断署名はデフォルトで有効になっています。
-
デバイスが Cisco IOS XE 17.6.1a 以降を実行している場合、プロアクティブな通知を送信するために使用する、セキュアな電子メールサーバを設定します。
ターミナル call-home mail-server :@ 優先順位 1 セキュアな tls エンド
-
通知する管理者のメール アドレスでds_email 環境変数を設定します。
端末の call-home diagnostic-signature 環境の設定 ds_email 終了
以下は、Gmail をセキュアな SMTP サーバーとして使用して、tacfaststart@gmail.com にプロアクティブ通知を送信するために、Cisco IOS XE 17.6.1a 以降で実行されているローカル ゲートウェイの設定の例を示します。
Cisco IOS XE Bengaluru 17.6.x 以降のバージョンを使用することをお勧めします。
call-home mail-server tacfaststart:password@smtp.gmail.com 優先順位 1 セキュアな tls 診断署名環境 ds_email "tacfaststart@gmail.com"
Cisco IOS XE ソフトウェアで起動するローカル ゲートウェイは OAuth に対応する一般的なウェブベースの Gmail クライアントではないので、特定の Gmail アカウント設定を行い、端末からメールを正しく処理するための権限を与える必要があります:
-
[安全性の低いアプリ アクセス] 設定をオンにします。
に移動し、 -
「はい、はい、それは私です」と答えます。Gmail から「Google は、Google 以外のアプリを使用してアカウントにサインインするユーザーを防ぎました」というメールを受け取ります。
プロアクティブ モニタリングのために診断署名をインストールする
CPU 使用率の監視
この DS は、SNMP OID を使用して 5 秒間 CPU 使用率を追跡します。1.3.6.1.4.1.9.2.1.56. 使用率が 75% 以上に達すると、すべてのデバッグを無効にし、ローカル ゲートウェイにインストールされている診断署名をアンインストールします。下記の手順を実行して署名をインストールします。
-
show snmp コマンドを使用して、SNMP を有効にします。有効にしない場合は、snmp-server manager コマンドを設定します。
show snmp %SNMP agent not enabled config t snmp-server manager end show snmp シャーシ: ABCDEFGHIGK 149655 SNMP パケット入力0 悪い SNMP バージョンエラー1 不明なコミュニティ名0 提供されたコミュニティ名の違法操作0 エンコーディングエラー 37763 リクエストされた変数の数2 変数の数 34560 取得リクエストPDU 138 取得ネクストPDU 2 セットリクエスト PDU 0 入力キューパケットドロップ(最大キューサイズ1000) 158277 SNMPパケット出力0 大きすぎるエラー (最大パケットサイズ 1500) 20 そのような名前エラーはありません0 悪い値エラー0 一般エラー 7998 応答 PDU 10280 トラップ PDU 現在 SNMP プロセス入力キューにあるパケット: 0 SNMP global trap: 有効
-
Diagnostic Signatures Lookup Tool の以下のドロップダウンオプションを使用して、DS 64224 をダウンロードします。
フィールド名
フィールド値
プラットフォーム
Cisco 4300、4400 ISR シリーズまたは Cisco CSR 1000V シリーズ
製品
Webex Calling ソリューションの CUBE Enterprise
問題の範囲
パフォーマンス
問題の種類
通知メールによる CPU 使用率が高い
-
DS XML ファイルをローカルゲートウェイフラッシュにコピーします。
LocalGateway# コピー ftp://username:password@/DS_64224.xml bootflash:
次の例では、FTP サーバーからローカル ゲートウェイへのファイルのコピーを示しています。
ftp://user:pwd@192.0.2.12/DS_64224.xml bootflash: ftp://*:*@ 192.0.2.12/DS_64224.xml...! [OK - 3571/4096 バイト] 0.064 秒 (55797 バイト/秒) にコピーされた 3571 バイト
-
ローカルゲートウェイに DS XML ファイルをインストールします。
call-home diagnostic-signature load DS_64224.xml ロードファイル DS_64224.xml 成功
-
show call-home diagnostic-signature コマンドを使用 して、署名が正常にインストールされたことを確認します。ステータス列の値が「registered」になっているはずです。
show call-home diagnostic-signature 現在の診断署名設定: Diagnostic-signature: enabled Profile: CiscoTAC-1 (status: ACTIVE) Downloading URL(s):https://tools.cisco.com/its/service/oddce/services/DDCEService 環境変数: ds_email: username@gmail.com
DSes をダウンロード:
DS ID
DS 名
リビジョン
ステータス
最終更新日時(GMT+00:00)
64224
DS_LGW_CPU_MON75
0.0.10
登録済み
2020-11-07 22:05:33
トリガーされると、この署名によって、この署名そのものを含む実行中のすべての DS がアンインストールされます。必要に応じて、DS 64224 を再インストールして、ローカル ゲートウェイでの高い CPU 使用率の監視を継続します。
SIP トランク登録のモニタリング
この DS は、60 秒ごとにクラウドにSIP トランクするローカル Webex Calling登録解除をチェックします。登録解除イベントが検出されると、メールと syslog の通知が生成され、2 回の登録解除後に自動的にアンインストールされます。署名をインストールするには、以下の手順を使用します。
-
Diagnostic Signatures Lookup Tool の以下のドロップダウンオプションを使用して、DS 64117 をダウンロードします。
フィールド名
フィールド値
プラットフォーム
Cisco 4300、4400 ISR シリーズ、または Cisco CSR 1000V シリーズ
製品
Webex Calling ソリューションの CUBE Enterprise
問題の範囲
SIP-SIP
問題の種類
SIP トランクによる登録解除を行いました。
-
DS XML ファイルをローカルゲートウェイにコピーします。
ftp://username:password@/DS_64117.xml bootflash:
-
ローカルゲートウェイに DS XML ファイルをインストールします。
call-home diagnostic-signature load DS_64117.xml ロードファイル DS_64117.xml 成功 LocalGateway#
-
show call-home diagnostic-signature コマンドを使用 して、署名が正常にインストールされたことを確認します。状態の列には「登録済み」の値が必要です。
異常な通話切断の監視
この DS は、10 分ごとに SNMP ポーリングを使用して、SIP エラーの 403、488、503 で異常な通話切断を検出します。 エラーカウントの増分が最後の投票から 5 以上である場合、syslog とメール通知が生成されます。 署名をインストールするには、以下の手順を使用してください。
-
show snmp コマンドを使用して、SNMP が有効かどうかを確認します。有効になっていない場合は、snmp-server manager コマンドを設定します。
show snmp %SNMP agent not enabled config t snmp-server manager end show snmp シャーシ: ABCDEFGHIGK 149655 SNMP パケット入力0 悪い SNMP バージョンエラー1 不明なコミュニティ名0 提供されたコミュニティ名の違法操作0 エンコーディングエラー 37763 リクエストされた変数の数2 変数の数 34560 取得リクエストPDU 138 取得ネクストPDU 2 セットリクエスト PDU 0 入力キューパケットドロップ(最大キューサイズ1000) 158277 SNMPパケット出力0 大きすぎるエラー (最大パケットサイズ 1500) 20 そのような名前エラーはありません0 悪い値エラー0 一般エラー 7998 応答 PDU 10280 トラップ PDU 現在 SNMP プロセス入力キューにあるパケット: 0 SNMP global trap: 有効
-
Diagnostic Signatures Lookup Tool の以下のオプションを使用して、DS 65221 をダウンロードします。
フィールド名
フィールド値
プラットフォーム
Cisco 4300、4400 ISR シリーズ、または Cisco CSR 1000V シリーズ
製品
Webex Calling ソリューションの CUBE Enterprise
問題の範囲
パフォーマンス
問題の種類
メールおよび Syslog 通知による SIP の異常通話切断検出
-
DS XML ファイルをローカルゲートウェイにコピーします。
ftp://username:password@/DS_65221.xml bootflash:
-
ローカルゲートウェイに DS XML ファイルをインストールします。
call-home diagnostic-signature load DS_65221.xml ロードファイル DS_65221.xml 成功
-
show call-home diagnostic-signature コマンドを使用 して、署名が正常にインストールされたことを確認します。状態の列には「登録済み」の値が必要です。
診断署名をインストールして問題のトラブルシューティングを行う
診断署名 (DS) を使用して、問題を迅速に解決します。Cisco TAC エンジニアは、特定の問題のトラブルシューティング、問題の発生を検出、診断データの正しいセットを収集し、データを Cisco TAC ケースに自動的に転送するために必要なデバッグを可能にするための署名を作成しました。診断署名(DS)は、問題の発生を手動で確認する必要性を排除し、断続的および一時的な問題のトラブルシューティングをはるかに容易にします。
診断署名ルックアップ ツールを使用して、適用可能な署名を見つけ、自己解決するためにインストールすることができます。または、サポート エンゲージメントの一部として、TAC エンジニアが推奨する署名をインストールできます。
以下の例は、「%VOICE_IEC-3-GW: CCAPI: Internal Error (call spike threshold): SYSLOG=1.1.181.1.29.0" syslog を使用して、以下の手順を使用して、診断データの収集を自動化します。
-
収集された診断データがアップロードされる Cisco TAC ファイル サーバー パス (cxd.cisco.com) である追加の DS 環境変数 ds_fsurl_prefix を構成します。ファイル パスのユーザー名はケース番号で、パスワードはファイルアップロードトークンで、次のコマンドの Support Case Manager から取得できます。ファイルアップロードトークンは、必要に応じて Support Case Manager の [添付ファイル] セクションで生成できます。
ターミナル call-home diagnostic-signature LocalGateway(cfg-call-home-diag-sign)環境を構成する ds_fsurl_prefix "scp://:@cxd.cisco.com" end
例:
call-home diagnostic-signature 環境 ds_fsurl_prefix "環境 ds_fsurl_prefix "scp://612345678:abcdefghijklmnop@cxd.cisco.com"
-
show snmp コマンドを使用して、SNMP が有効になっていることを確認します。有効になっていない場合は、snmp-server manager コマンドを設定します。
show snmp %SNMP agent not enabled config t snmp-server manager end
-
高 CPU 使用率の期間中に、すべてのデバッグと診断署名を無効にするためのプロアクティブな措置として、高 CPU モニタリング DS 64224 をインストールしてください。Diagnostic Signatures Lookup Tool の以下のオプションを使用して、DS 64224 をダウンロードします。
フィールド名
フィールド値
プラットフォーム
Cisco 4300、4400 ISR シリーズ、または Cisco CSR 1000V シリーズ
製品
Webex Calling ソリューションの CUBE Enterprise
問題の範囲
パフォーマンス
問題の種類
通知メールによる CPU 使用率が高い
-
Diagnostic Signatures Lookup Tool の以下のオプションを使用して、DS 65095 をダウンロードします。
フィールド名
フィールド値
プラットフォーム
Cisco 4300、4400 ISR シリーズ、または Cisco CSR 1000V シリーズ
製品
Webex Calling ソリューションの CUBE Enterprise
問題の範囲
Syslog
問題の種類
Syslog - %VOICE_IEC-3-GW: CCAPI: Internal Error (Call spike threshold): IEC=1.1.181.1.29.0
-
DS XML ファイルをローカルゲートウェイにコピーします。
ftp://username:password@/DS_64224.xml bootflash: ftp://username:password@/DS_65095.xml bootflash:
-
ローカルゲートウェイに、高 CPU モニタリング DS 64224、DS 65095 XML ファイルの順にインストールします。
call-home diagnostic-signature load DS_64224.xml ロードファイル DS_64224.xml 成功 call-home diagnostic-signature load DS_65095.xml ロードファイル DS_65095.xml 成功
-
show call-home diagnostic-signature コマンドを使用して、署名が正常にインストールされていることを確認します。状態の列には「登録済み」の値が必要です。
show call-home diagnostic-signature 現在の診断署名設定: Diagnostic-signature: enabled Profile: CiscoTAC-1 (status: ACTIVE) Downloading URL(s):https://tools.cisco.com/its/service/oddce/services/DDCEService 環境変数: ds_email: username@gmail.com ds_fsurl_prefix: scp://612345678:abcdefghijklmnop@cxd.cisco.com
ダウンロードされた DSes:
DS ID
DS 名
リビジョン
ステータス
最終更新日時(GMT+00:00)
64224
00:07:45
DS_LGW_CPU_MON75
0.0.10
登録済み
2020-11-08
65095
00:12:53
DS_LGW_IEC_Call_spike_threshold
0.0.12
登録済み
2020-11-08
診断署名の実行を確認します
次のコマンドで、show call-home diagnostic-signature コマンドの「ステータス」列が「実行中」に変わり、ローカル ゲートウェイが署名内で定義されたアクションを実行します。show call-home 診断署名 統計の出力は、診断署名が関心のあるイベントを検出してアクションを実行したかどうかを検証するための最適な方法です。「トリガーされた/Max/Deinstall」欄は、指定された署名がイベントをトリガーした回数、イベントを検出するために定義される最大回数、トリガーされたイベントの最大数を検出した後に署名が自身をインストールアンインストールするかどうかを示します。
show call-home diagnostic-signature 現在の診断署名設定: Diagnostic-signature: enabled
Profile: CiscoTAC-1 (status: ACTIVE)
Downloading URL(s):https://tools.cisco.com/its/service/oddce/services/DDCEService 環境変数: ds_email: carunach@cisco.com ds_fsurl_prefix: scp://612345678:abcdefghijklmnop@cxd.cisco.com
ダウンロードされた DSes:
DS ID |
DS 名 |
リビジョン |
ステータス |
最終更新日時(GMT+00:00) |
---|---|---|---|---|
64224 |
DS_LGW_CPU_MON75 |
0.0.10 |
登録済み |
2020-11-08 00:07:45 |
65095 |
DS_LGW_IEC_Call_spike_threshold |
0.0.12 |
実行中 |
2020-11-08 00:12:53 |
コール ホーム診断署名統計を表示する
DS ID |
DS 名 |
トリガー済み/Max/Deinstall |
平均実行時間(秒) |
最長実行時間(秒) |
---|---|---|---|---|
64224 |
DS_LGW_CPU_MON75 |
0/0/N |
0.000 |
0.000 |
65095 |
DS_LGW_IEC_Call_spike_threshold |
1/20/日 |
23.053 |
23.053 |
診断署名通知メール送信されるコマンドには、問題の種類、デバイスの詳細、ソフトウェア バージョン、実行構成、与えられた問題のトラブルシューティングに関連するコマンド出力の表示など、重要な情報が含まれている必要があります。
診断署名をアンインストールする
トラブルシューティングのために診断署名を使用は、一般的に、いくつかの問題が発生した場合の検出後にアンインストールするために定義されます。署名を手動でアンインストールする場合は、show call-home diagnostic-signature コマンドの出力から DS ID を取得し、次のコマンドを実行します。
call-home diagnostic-signature のデインストール
例:
call-home diagnostic-signature deinstall 64224
診断署名検索ツールに定期的に新しい署名が追加されます。これは展開で一般的に見られる問題に基づいて行います。TAC では現在、新しいカスタム署名の作成リクエストをサポートしていません。
Cisco IOS XE ゲートウェイの管理を改善するには、Control Hub を使用してゲートウェイを登録および管理することをお勧めします。これはオプションの設定です。登録すると、Control Hub の構成検証オプションを使用して、ローカル ゲートウェイ構成を検証し、構成の問題を特定できます。現在、登録ベースのトランクのみがこの機能をサポートしています。
詳細については、以下を参照してください。
このセクションでは、証明書ベースの相互 TLS (mTLS) SIP トランクを使用して、Cisco Unified Border Element (CUBE) を Webex Calling のローカル ゲートウェイとして設定する方法について説明します。このドキュメントの最初の部分は、シンプルな PSTN ゲートウェイを設定する方法を示しています。この場合、PSTN からのすべてのコールは Webex Calling にルーティングされ、Webex Calling からのすべてのコールは PSTN にルーティングされます。次の画像では、このソリューションとそれに続く高レベルのコール ルーティング設定が強調表示されます。
この設計では、次の主な構成が使用されます。
-
音声クラス テナント: トランク固有の構成を作成するために使用されます。
-
音声クラスuri: 着信ダイヤルピアの選択のための SIP メッセージを分類するために使用。
-
着信ダイヤルピア: 着信 SIP メッセージの処理を提供し、ダイヤルピア グループを使用して発信ルートを決定します。
-
ダイヤルピア グループ: オンワード コール ルーティングに使用する発信ダイヤル ピアを定義します。
-
発信ダイヤルピア: アウトバウンド SIP メッセージの処理を提供し、必要なターゲットにルーティングします。
IP および SIP は PSTN トランクのデフォルトのプロトコルになりましたが、TDM (Time Division Multiplexing) ISDN 回路はまだ広く使用されており、Webex Calling トランクでサポートされています。TDM-IP コール フローでローカル ゲートウェイの IP パスのメディア最適化を有効にするには、現在、2 レッグのコール ルーティング プロセスを使用する必要があります。このアプローチは、下の画像に示すように、Webex Calling と PSTN トランクの間に一連の内部ループバックダイヤルピアを導入することにより、上記のコール ルーティング設定を変更します。
オンプレミスの Cisco Unified Communications Manager ソリューションを Webex Calling に接続する場合、次の図に示すソリューションを構築するためのベースラインとしてシンプルな PSTN ゲートウェイ設定を使用できます。この場合、Unified Communications Manager は、すべての PSTN および Webex Calling コールのルーティングと処理を一元化します。
このドキュメントでは、次の画像に示すホスト名、IP アドレス、およびインターフェイスが使用されます。オプションは、パブリックまたはプライベート(NATの背後)アドレッシングに提供されます。SRV DNS レコードは、複数の CUBE インスタンス間でロードバランシングされない限り、オプションです。
このドキュメントの残りの構成ガイダンスを使用して、ローカル ゲートウェイの設定を次のように完了します。
-
ステップ 1:ルーターのベースライン接続とセキュリティを設定する
-
ステップ 2: Webex Calling トランクの設定
必要なアーキテクチャに応じて、次のいずれかを実行します。
-
ステップ 3: SIP PSTN トランクを使用したローカル ゲートウェイの設定
-
ステップ 4: ローカル ゲートウェイを既存の Unified CM 環境で構成する
または:
-
ステップ 3: TDM PSTN トランクを使用したローカル ゲートウェイの設定
ベースラインの設定
Webex Calling のローカル ゲートウェイとして Cisco ルータを準備する最初のステップは、プラットフォームを保護し、接続を確立するベースライン設定を構築することです。
-
すべての証明書ベースのローカル ゲートウェイ展開には、Cisco IOS XE 17.9.1a 以降のバージョンが必要です。Cisco IOS XE 17.12.2 以降を推奨します。推奨されるバージョンについては、「Cisco Software Research 」ページを参照してください。プラットフォームを検索し、提 案されたリリースのいずれかを選択します。
-
ISR4000 シリーズ ルータは、Unified Communications および Security テクノロジー ライセンスの両方で設定する必要があります。
-
Catalyst Edge 8000シリーズのルーターには、ボイスカードまたはDSPが搭載されており、DNA Advantageライセンスが必要です。ボイスカードやDSPのないルーターには、最低限のDNA Essentialsライセンスが必要です。
-
大容量の要件については、High Security(HSEC)ライセンスおよび追加のスループットエンタイトルメントが必要になる場合があります。
詳細については、認証コー ドを参照してください。
-
-
ビジネスポリシーに従うプラットフォームのベースライン設定を構築します。特に、以下を構成し、検証します。
-
NTP
-
Acl
-
ユーザー認証とリモートアクセス
-
DNS
-
IP ルーティング
-
IP アドレス
-
-
Webex Calling に向かうネットワークは IPv4 アドレスを使用する必要があります。Control Hub で設定されたローカル ゲートウェイの完全修飾ドメイン名(FQDN)またはサービスレコード(SRV)アドレスは、インターネット上のパブリック IPv4 アドレスに解決する必要があります。
-
Webex に面しているローカル ゲートウェイ インターフェイスのすべての SIP ポートとメディア ポートは、インターネットから直接アクセスするか、静的 NAT 経由でアクセスする必要があります。それに応じてファイアウォールを更新してください。
-
ローカル ゲートウェイに署名付き証明書をインストールするには、以下に示す詳細な設定手順に従います。
-
Cisco Webex 音声およびビデオ プラットフォームへの通話でサポートされているルート認証局とはに詳述 されているパブリック認証局 (CA) は、デバイス証明書に署名する必要があります。
-
証明書のサブジェクト共通名 (CN)、またはサブジェクト代替名 (SAN) の 1 つは、コントロール ハブで設定された FQDN と同じである必要があります。たとえば、次のようなものです。
-
組織の Control Hub で設定されたトランクにローカル ゲートウェイの FQDN として cube1.lgw.com:5061 がある場合、ルーター証明書の CN または SAN に cube1.lgw.com が含まれている必要があります。
-
組織の Control Hub で設定されたトランクが、トランクから到達可能なローカル ゲートウェイの SRV アドレスとして LGWS.LGW.COM を持っている場合、ルータ証明書の CN または SAN には lgws.lgw.com が含まれている必要があります。クライアント アドレスが 解決SRV (CNAME、A レコード、または IP アドレス) のレコードは、SAN ではオプションです。
-
トランクに FQDN または SRV を使用する場合は、ローカル ゲートウェイからのすべての新しい SIP ダイアログの連絡先アドレスが Control Hub で設定された名前を使用する必要があります。
-
-
証明書がクライアントとサーバの使用のために署名されていることを確認します。
-
-
Cisco ルート CA バンドルをローカル ゲートウェイにアップロードします。このバンドルには、Webex プラットフォームの検証に使用される CA ルート証明書が含まれます。
構成
1 |
次のように、有効でルーティング可能な IP アドレスをレイヤ 3 インターフェイスに割り当てます。
|
2 |
対称暗号化を使用してルータの STUN クレデンシャルを保護します。プライマリ暗号化キーと暗号化タイプを次のように設定します。 |
3 |
サポートされている 証明機関 (CA) によって署名されたドメインの証明書を使用して暗号化トラストポイントを作成します。 |
4 |
ホスト証明書の認証に使用される中間署名 CA の証明書を提供します。次の exec または configuration コマンドを入力します。
|
5 |
次の exec または設定コマンドを使用して、署名付きホスト証明書をインポートします。
|
6 |
TLS1.2 の排他性を有効にし、次の設定コマンドを使用して、音声アプリケーションに使用するデフォルトのトラストポイントを指定します。
|
7 |
Webex Calling で使用される DigiCert CA 証明書を含む Cisco ルート CA バンドルをインストールします。crypto pki trustpool import clean url url コマンドを使用して、指定された URL からルート CA バンドルをダウンロードし、現在の CA トラストプールをクリアし、証明書の新しいバンドルをインストールします。 HTTPS を使用してインターネットにアクセスするためにプロキシを使用する必要がある場合は、CA バンドルをインポートする前に、次の設定を追加します。 ip httpクライアントプロキシサーバーyourproxy.comプロキシポート80 |
1 |
Control Hub の既存のロケーションに対して CUBE 証明書ベースの PSTN トランクを作成します。詳細については、「Webex Calling のトランク、ルート グループ、ダイヤル プランの設定」を参照してください。 トランクが作成されると、提供されたトランク情報をメモします。次の図で強調表示されているこれらの詳細は、このガイドの設定手順で使用されます。 |
2 |
次のコマンドを入力して、CUBE を Webex Calling ローカル ゲートウェイとして設定します。 以下は、設定のフィールドの説明です。
プラットフォームで Cisco Unified Border Element(CUBE)機能を有効にします。 allow-connections sip to sipCUBE 基本 SIP バックツーバックユーザーエージェント機能を有効にします。詳細については、「接続を許可」を参照してください。 デフォルトでは、T.38 ファックス転送が有効になっています。詳細については、ファックスプロトコルt38 (音声サービス)を参照してください。 STUN (NAT を介した UDP のセッショントラバーサル) をグローバルに有効にします。 これらのグローバル スタンコマンドは、NAT の後ろにローカル ゲートウェイを展開する場合にのみ必要です。
詳細については、「stun flowdata agent-id」および「stun flowdata shared-secret」を参照してください。 非対称ペイロード フルDTMF と動的コーデック ペイロードの両方に対して SIP 非対称ペイロード サポートを設定します。このコマンドの詳細については、非対称ペイロードを参照してください。 early-offer forcedローカル ゲートウェイは、隣接するピアからの確認を待つ代わりに、最初の INVITE メッセージで SDP 情報を送信するように強制します。このコマンドの詳細については、早期提供を参照してください。 SIP プロファイル着信CUBE が SIP プロファイルを使用して、受信したメッセージを変更できるようにします。プロファイルは、ダイヤルピアまたはテナントを介して適用されます。 |
3 |
すべてのトランクに対して G.711 コーデックのみを許可する音声クラス コーデック 100 を設定します。このシンプルなアプローチは、ほとんどの導入に適しています。必要に応じて、発信元システムと終端システムの両方でサポートされている追加のコーデック タイプをリストに追加できます。 DSP モジュールを使用したトランスコーディング を含むより複雑なソリューションはサポートされていますが、このガイドには含まれていません。 以下は、設定のフィールドの説明です。 音声クラス コーデック 100SIP トランク コールの優先コーデックのみを許可するために使用されます。詳細については、「音声クラスコーデック」を参照してください。 |
4 |
音声クラス stun-usage 100 を設定して、Webex Calling トランクで ICE を有効にします。(この手順は政府版 Webex には適用されません) 以下は、設定のフィールドの説明です。 スタンの使用法 アイス ライトすべての Webex Calling のダイヤルピアに対して ICE-Lite を有効にして、可能な限り、メディア最適化を可能にするために使用。詳細については、「voice class stun usag e」および「stun usage ice lite」を参照してください。 stun usage firewall-traversal flowdata コマンドは、NAT の背後にローカル ゲートウェイを展開する場合にのみ必要です。 メディアの最適化は、可能な限り、ネゴシエートされます。通話に録画などのクラウド メディア サービスが必要な場合、メディアを最適化できません。 |
5 |
Webex トラフィックのメディア暗号化ポリシーを設定します。(この手順は政府版 Webex には適用されません) 以下は、設定のフィールドの説明です。 音声クラス srtp-crypto 100SDP の SRTP 暗号スイート CUBE オファーおよび応答メッセージの唯一の SRTP オファーとして SHA1_80 を指定します。Webex Calling は SHA1_80 のみをサポートします。詳細については、音声クラス srtp-crypto を参照してください。 |
6 |
FIPS 準拠の GCM 暗号を設定します(この手順は政府版 Webex にのみ適用されます)。 以下は、設定のフィールドの説明です。 音声クラス srtp-crypto 100CUBE が提供する暗号スイートとして GCM を指定します。政府版 Webex のローカル ゲートウェイの GCM 暗号を設定することは必須です。 |
7 |
宛先 FQDN または SRV に基づいて、ローカル ゲートウェイ トランクへのコールを一意に識別するためのパターンを設定します。 以下は、設定のフィールドの説明です。 音声クラス uri 100 sip着信トランク ダイヤル ピアへの着信 SIP 招待と一致するパターンを定義します。このパターンを入力する場合は、トランク用に Control Hub で設定されたトランク FQDN または SRV を使用します。 |
8 |
SIP メッセージ操作プロファイルを設定します。ゲートウェイがパブリック IP アドレスで設定されている場合は、次のようにプロファイルを設定するか、NAT を使用している場合は、次のステップにスキップします。この例では、cube1.lgw.com はローカル ゲートウェイに設定されている FQDN です。 以下は、設定のフィールドの説明です。 ルール10と20Webex がローカル ゲートウェイからのメッセージを認証できるようにするには、SIP リクエストと応答メッセージの「Contact」ヘッダーに Control Hub のトランクにプロビジョニングされた値が含まれている必要があります。これは、単一のホストの FQDN か、デバイスのクラスタに使用される SRV 名になります。 |
9 |
ゲートウェイがスタティック NAT の背後にプライベート IP アドレスで設定されている場合は、次のように着信および発信 SIP プロファイルを設定します。この例では、cube1.lgw.com はローカル ゲートウェイ用に設定された FQDN で、「10.80.13.12」は Webex Calling に面したインターフェイス IP アドレス、「192.65.79.20」は NAT パブリック IP アドレスです。 Webex Calling への発信メッセージの SIP プロファイル
以下は、設定のフィールドの説明です。 ルール10と20Webex がローカル ゲートウェイからのメッセージを認証できるようにするには、SIP リクエストと応答メッセージの「Contact」ヘッダーに Control Hub のトランクにプロビジョニングされた値が含まれている必要があります。これは、単一のホストの FQDN か、デバイスのクラスタに使用される SRV 名になります。 ルール30~81プライベート アドレス参照をサイトの外部パブリック アドレスに変換し、Webex が後続のメッセージを正しく解釈してルーティングできるようにします。 Webex Calling からの着信メッセージの SIP プロファイル 以下は、設定のフィールドの説明です。 10から80までのルールパブリック アドレス参照を設定したプライベート アドレスに変換し、CUBE が Webex からのメッセージを処理できるようにします。 詳細については、「音声クラス sip プロファイル」を参照してください。 米国またはカナダの PSTN プロバイダーは、Webex Calling のスパムまたは詐欺コールの表 示で言及されている追加設定を使用して、スパムおよび詐欺コールの発信者 ID 検証を提供できます。 |
10 |
ヘッダー変更プロファイルを使用して SIP オプションをキープアライブに設定します。 以下は、設定のフィールドの説明です。 音声クラス sip-options-keepalive 100キープアライブ プロファイルを設定し、音声クラス設定モードに入ります。エンドポイントへのハートビート接続が UP または DOWN 状態の場合、SIP アウトオブダイアログオプション Ping がダイヤルターゲットに送信される時間(秒単位)を設定できます。 このキープアライブ プロファイルは、Webex に対して設定されたダイヤル ピアからトリガーされます。 連絡先ヘッダーに SBC 完全修飾ドメイン名が含まれていることを確認するために、SIP プロファイル 115 が使用されます。ルール 30、40、および 50 は、SBC が静的 NAT の後ろに設定されている場合にのみ必要です。 この例では、cube1.lgw.com はローカル ゲートウェイ用に選択された FQDN であり、静的 NAT が使用されている場合は、「10.80.13.12」は Webex Calling に対する SBC インターフェイス IP アドレスであり、「192.65.79.20」は NAT パブリック IP アドレスです。 |
11 |
Webex Calling トランクの設定: |
上記の Webex Calling に対してトランクを構築した後、次の設定を使用して、SIP ベースの PSTN プロバイダーに対して暗号化されていないトランクを作成します。
サービス プロバイダーがセキュアな PSTN トランクを提供している場合、上記の Webex Calling トランクと同様の構成に従うことができます。CUBE はセキュアなコール ルーティングをサポートします。
TDM / ISDN PSTN トランクを使用している場合は、次のセクション [TDM PSTN トランクでローカル ゲートウェイを設定する] に進みます。
Cisco TDM-SIP ゲートウェイで PSTN コール レッグの TDM インターフェイスを設定するには、「ISDN PRI の設定」を参照してください。
1 |
PSTN トランクからの着信コールを識別するには、次の音声クラス uri を設定します。 以下は、設定のフィールドの説明です。 音声クラス uri 200 sip着信トランク ダイヤル ピアへの着信 SIP 招待と一致するパターンを定義します。このパターンを入力する場合は、IP PSTN ゲートウェイの IP アドレスを使用します。詳細については、音声クラス uri を参照してください。 |
2 |
次の IP PSTN ダイヤル ピアを設定します。 以下は、設定のフィールドの説明です。 200のタグ を含むVoIPダイヤルピアを定義し、管理とトラブルシューティングを容易にするための意味のある説明を提供します。詳細については、ダイヤルピアの音声を参照してください。 宛先パターン BAD.BAD着信ダイヤル ピア グループを使用して発信コールをルーティングする場合は、ダミー接続先パターンが必要です。この場合、有効な宛先パターンを使用できます。詳細については、destination-pattern (interface)を参照してください。 session protocol sipv2このダイヤル ピアが SIP コール レッグを処理することを指定します。詳細については、セッションプロトコル (ダイヤルピア)を参照してください。 セッション ターゲット ipv4: 192.168.80.13PSTN プロバイダーに送信されるコールのターゲット アドレスを指定します。これは IP アドレスまたは DNS ホスト名です。詳細については、セッションターゲット (VoIP ダイヤルピア)を参照してください。 200 経由の着信 uriINVITE VIA ヘッダー URI を使用して、着信コールをこのダイヤルピアに照合するために使用される音声クラスを指定します。詳細については、着信 URLを参照してください。 音声クラス sip asserted-id pai
(オプション) P-Asserted-Identity ヘッダー処理をオンにし、これが PSTN トランクに使用する方法を制御します。このコマンドが使用されている場合、着信ダイヤルピアから提供された発信側 ID は、発信元および P-Asserted-Identity ヘッダーに使用されます。このコマンドが使用されていない場合、着信ダイヤルピアから提供された発信側 ID は、発信元および Remote-Party-ID ヘッダーに使用されます。詳細については、voice-class sip asserted-idを参照してください。 バインド制御ソースインタフェース GigabitEthernet0/0/0
PSTN に送信されるメッセージのソース インターフェイスと関連する IP アドレスを設定します。詳細は、bindを参照してください。 バインド メディア ソース インターフェイス GigabitEthernet0/0/0PSTN に送信されるメディアのソース インターフェイスおよび関連する IP アドレスを設定します。詳細は、bindを参照してください。 音声クラス コーデック 100共通のコーデック フィルタ リスト 100 を使用するようにダイヤル ピアを設定します。詳細については、音声クラスコーデックを参照してください。 dtmf-relay rtp-nte通話レグで予想される DTMF 機能として RTP-NTE (RFC2833) を定義します。詳細については、「DTMF Relay (Voice over IP)」を参照してください。 no vad音声アクティブティの検出を無効にします。詳細については、vad(ダイヤルピア)を参照してください。 |
3 |
ローカル ゲートウェイを Webex Calling と PSTN 間のコールのみルーティングするように設定している場合は、次のコール ルーティング設定を追加します。Unified Communications Manager プラットフォームを使用してローカル ゲートウェイを設定する場合は、次のセクションに進みます。 |
Webex Calling に向けてトランクを構築した後は、次の設定を使用して、Webex コール レッグのメディア最適化を可能にするために、ループ バック コール ルーティングを備えた PSTN サービスの TDM トランクを作成します。
IP メディア最適化を必要としない場合は、SIP PSTN トランクの設定手順に従います。PSTN VoIP ダイヤル ピアの代わりに、ボイス ポートと POTS ダイヤル ピア(手順 2 および 3 を参照)を使用します。
1 |
ループ バック ダイヤル ピア構成では、ダイヤル ピア グループとコール ルーティング タグを使用して、コール ルーティング ループを作成せずに、Webex と PSTN の間でコールが正しく渡されるようにします。コール ルーティング タグの追加と削除に使用する次のトランスレーション ルールを設定します。 以下は、設定のフィールドの説明です。 音声翻訳ルールルールで定義された正規表現を使用して、コール ルーティング タグを追加または削除します。Over-decadic digits (A) は、トラブルシューティングの明瞭さを追加するために使用されます。 この設定では、translation-profile 100 によって追加されたタグを使用して、ループバックダイヤルピア経由で Webex Calling から PSTN へのコールをガイドします。同様に、translation-profile 200 によって追加されたタグは、PSTN から Webex Calling へのコールをガイドするために使用されます。翻訳プロファイル 11 と 12 は、Webex トランクと PSTN トランクにコールを配信する前に、これらのタグを削除します。 この例では、Webex Calling からの着信番号が +E.164 形式で表示されていることを前提としています。ルール 100 は、有効な着信番号を維持するために、先頭の + を削除します。ルール 12 では、タグを削除するときに、国内または国際的なルーティング番号を追加します。ローカル ISDN ナショナル ダイヤル プランに合った数字を使用します。 Webex Calling が全国形式で番号を提示する場合、ルール 100 と 12 を調整して、ルーティング タグをそれぞれ追加および削除するだけです。 詳細については、「voice translation-profil e」および「voice translation-rule」を参照してください。 |
2 |
使用するトランク タイプとプロトコルによって必要に応じて、TDM 音声インターフェイス ポートを設定します。詳細については、「ISDN PRIの設定」を参照してください。たとえば、デバイスの NIM スロット 2 にインストールされているプライマリレート ISDN インターフェイスの基本設定には、次のものが含まれます。 |
3 |
次の TDM PSTN ダイヤル ピアを設定します。 以下は、設定のフィールドの説明です。 200のタグを含むVoIPダイヤルピアを定義し、管理とトラブルシューティングを容易にするための意味のある説明を提供します。詳細については、ダイヤルピアの音声を参照してください。 宛先パターン BAD.BAD着信ダイヤル ピア グループを使用して発信コールをルーティングする場合は、ダミー接続先パターンが必要です。この場合、有効な宛先パターンを使用できます。詳細については、destination-pattern (interface)を参照してください。 translation-profile incoming 200着信着信番号にコール ルーティング タグを追加するトランスレーション プロファイルを割り当てます。 ダイレクト インワード ダイヤルセカンダリ ダイヤル トーンを提供せずにコールをルーティングします。詳細は、ダイレクト インワード ダイヤルを参照してください。 ポート 0/2:0:15このダイヤル ピアに関連付けられている物理的な音声ポート。 |
4 |
TDM-IP コール フローでローカル ゲートウェイの IP パスのメディア最適化を有効にするには、Webex Calling と PSTN トランクの間に一連の内部ループ バック ダイヤル ピアを導入して、コール ルーティングを変更できます。次のループバックダイヤルピアを設定します。この場合、すべての着信コールは最初にダイヤルピア 10 にルーティングされ、そこから適用されたルーティング タグに基づいてダイヤルピア 11 または 12 にルーティングされます。ルーティング タグを削除すると、コールはダイヤル ピア グループを使用して発信トランクにルーティングされます。 以下は、設定のフィールドの説明です。 VoIP ダイヤル ピアを定義し、管理とトラブルシューティングを容易にするための意味のある説明を提供します。詳細については、ダイヤルピアの音声を参照してください。 translation-profile 着信 11先に定義したトランスレーション プロファイルを適用して、発信トランクに渡す前にコール ルーティング タグを削除します。 宛先パターン BAD.BAD着信ダイヤル ピア グループを使用して発信コールをルーティングする場合は、ダミー接続先パターンが必要です。詳細については、destination-pattern (interface)を参照してください。 session protocol sipv2このダイヤル ピアが SIP コール レッグを処理することを指定します。詳細については、セッションプロトコル (ダイヤルピア)を参照してください。 セッション ターゲット ipv4: 192.168.80.14ループ バックのコール ターゲットとしてローカル ルータ インターフェイス アドレスを指定します。詳細については、セッションターゲット (voip ダイヤルピア)を参照してください。 バインド制御ソースインタフェース GigabitEthernet0/0/0ループバックを介して送信されるメッセージのソース インターフェイスおよび関連する IP アドレスを設定します。詳細は、bindを参照してください。 バインド メディア ソース インターフェイス GigabitEthernet0/0/0ループバックを介して送信されるメディアのソース インターフェイスおよび関連する IP アドレスを設定します。詳細は、bindを参照してください。 dtmf-relay rtp-nte通話レグで予想される DTMF 機能として RTP-NTE (RFC2833) を定義します。詳細については、「DTMF Relay (Voice over IP)」を参照してください。 コーデック g711alaw すべての PSTN コールに G.711 を使用するように強制します。ISDN サービスで使用されるコンパニオン方法に一致するように、a-law または u-law を選択します。 no vad音声アクティブティの検出を無効にします。詳細については、vad(ダイヤルピア)を参照してください。 |
5 |
次のコール ルーティング設定を追加します。 これでローカル ゲートウェイの設定は終了します。CUBE 機能が初めて設定される場合は、設定を保存し、プラットフォームをリロードします。
|
前のセクションの PSTN-Webex Calling 設定は、Cisco Unified Communications Manager (UCM) クラスタへの追加のトランクを含めるように変更される場合があります。この場合、すべてのコールは Unified CM 経由でルーティングされます。ポート 5060 の UCM からのコールは PSTN にルーティングされ、ポート 5065 からのコールは Webex Calling にルーティングされます。次の増分設定を追加して、この通話シナリオを含めることができます。
1 |
以下の音声クラス URI を設定: |
2 |
次の DNS レコードを設定して、Unified CM ホストへの SRV ルーティングを指定します。 IOS XE は、これらのレコードをローカルでターゲット UCM ホストとポートを決定するために使用します。この設定では、DNS システムでレコードを設定する必要はありません。DNS を使用する場合は、これらのローカル設定は必要ありません。 以下は、設定のフィールドの説明です。 次のコマンドは、DNS SRV リソース レコードを作成します。各 UCM ホストとトランクのレコードを作成します。 ip ホスト _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub5.mydomain.com _sip._udp.pstntocucm.io: SRV リソースレコード名 2: SRV リソースレコードの優先順位 1: SRV リソースレコードの重み 5060: このリソース レコードでターゲット ホストに使用するポート番号 ucmsub5.mydomain.com: リソースレコードターゲットホスト リソースレコードのターゲットホスト名を解決するには、ローカル DNS A レコードを作成します。たとえば、次のようなものです。 ip ホスト ucmsub5.mydomain.com 192.168.80.65 IPホスト: ローカル IOS XE データベースにレコードを作成します。 ucmsub5.mydomain.com: A レコードのホスト名。 192.168.80.65: ホスト IP アドレス。 SRV リソース レコードと A レコードを作成し、UCM 環境と優先コール分配戦略を反映させます。 |
3 |
次のダイヤルピアを設定します。 |
4 |
次の設定を使用してコール ルーティングを追加します。 |
診断署名 (DS) は、Cisco IOS XE ベースのローカル ゲートウェイで共通に観察される問題を事前に検出し、イベントのメール、syslog、またはターミナル メッセージ通知を生成します。さらに、DS をインストールして診断データ収集を自動化し、収集したデータを Cisco TAC ケースに転送して解決時間を短縮することもできます。
診断署名 (DS) は、問題のトリガー イベントと問題を通知、トラブルシューティング、修正するためのアクションに関する情報を含む XML ファイルです。syslog メッセージ、SNMP イベント、および特定のコマンド出力の定期的な監視を使用して、問題の検出ロジックを定義します。アクションタイプには以下が含まれます。
-
show command 出力を収集中
-
統合ログファイルの生成
-
HTTPS、SCP、FTP サーバーなどのネットワークロケーションをユーザーにアップロードする
TAC エンジニアは DS ファイルを作成し、整合性保護のためにデジタル署名します。各 DS ファイルには、システムによって割り当てられた固有の数字の ID があります。Diagnostic Signatures Lookup Tool (DSLT)は、さまざまな問題を監視およびトラブルシューティングするための適切な署名を見つけるための単一のソースです。
開始する前に:
-
DSLT からダウンロードした DS ファイルは 編集していない。変更するファイルは、整合性チェックエラーのためインストールに失敗します。
-
ローカル ゲートウェイがメール通知を送信するために必要な簡易メール転送プロトコル (SMTP) サーバー。
-
メール通知に安全な SMTP サーバーを使用する場合は、ローカル ゲートウェイが IOS XE 17.6.1 以上を実行中か確認してください。
前提条件
IOS XE 17.6.1 以上を実行するローカル ゲートウェイ
-
診断署名はデフォルトで有効になっています。
-
デバイスが IOS XE 17.6.1 以降を実行している場合、プロアクティブ通知の送信に使用するセキュアなメール サーバーを構成します。
ターミナル コールホーム メール サーバー を設定します。@ 優先順位 1 セキュア tls エンド
-
通知する管理者 ds_email のメールアドレスを使用して、環境変数を設定します。
ターミナル call-home diagnostic-signature LocalGateway(cfg-call-home-diag-sign)環境の設定 ds_email end
プロアクティブ モニタリングのために診断署名をインストールする
CPU 使用率の監視
この DS は SNMP OID 1.3.6.1.4.1.9.2.1.56 を使用して 5 秒間の CPU 使用率を追跡します。使用率が 75% 以上に達すると、すべてのデバッグが無効し、ローカル ゲートウェイにインストールした診断署名をアンインストールします。下記の手順を実行して署名をインストールします。
-
コマンドを使用して SNMP を有効に設定し、 snmp を表示します。SNMP が有効になっていない場合は、snmp-server manager コマンドを設定します。
show snmp %SNMP agent not enabled config t snmp-server manager end show snmp シャーシ: ABCDEFGHIGK 149655 SNMP パケット入力0 悪い SNMP バージョンエラー1 不明なコミュニティ名0 提供されたコミュニティ名の違法操作0 エンコーディングエラー 37763 リクエストされた変数の数2 変数の数 34560 取得リクエストPDU 138 取得ネクストPDU 2 セットリクエスト PDU 0 入力キューパケットドロップ(最大キューサイズ1000) 158277 SNMPパケット出力0 大きすぎるエラー (最大パケットサイズ 1500) 20 そのような名前エラーはありません0 悪い値エラー0 一般エラー 7998 応答 PDU 10280 トラップ PDU 現在 SNMP プロセス入力キューにあるパケット: 0 SNMP global trap: 有効
Diagnostic Signatures Lookup Tool の以下のドロップダウンオプションを使用して、DS 64224 をダウンロードします。
ftp://username:password@/DS_64224.xml bootflash:
フィールド名
フィールド値
プラットフォーム
Cisco 4300、4400 ISR シリーズ、または Catalyst 8000V Edge ソフトウェア
製品
Webex Calling ソリューションの CUBE Enterprise
問題の範囲
パフォーマンス
問題の種類
メール通知による高 CPU 使用率
-
DS XML ファイルをローカルゲートウェイフラッシュにコピーします。
ftp://username:password@/DS_64224.xml bootflash:
次の例では、FTP サーバーからローカル ゲートウェイへのファイルのコピーを示しています。
ftp://user:pwd@192.0.2.12/DS_64224.xml bootflash: ftp://*:*@ 192.0.2.12/DS_64224.xml...! [OK - 3571/4096 バイト] 0.064 秒 (55797 バイト/秒) にコピーされた 3571 バイト
-
ローカルゲートウェイに DS XML ファイルをインストールします。
call-home diagnostic-signature load DS_64224.xml ロードファイル DS_64224.xml 成功
-
show call-home diagnostic-signature コマンドを使用 して、署名が正常にインストールされたことを確認します。状態の列には「登録済み」の値が必要です。
show call-home diagnostic-signature 現在の診断署名設定: Diagnostic-signature: enabled Profile: CiscoTAC-1 (status: ACTIVE) Downloading URL(s):https://tools.cisco.com/its/service/oddce/services/DDCEService 環境変数: ds_email: username@gmail.com
DSes をダウンロード:
DS ID
DS 名
リビジョン
ステータス
最終更新日時(GMT+00:00)
64224
DS_LGW_CPU_MON75
0.0.10
登録済み
2020-11-07 22:05:33
トリガーされると、この署名によって、この署名そのものを含む実行中のすべての DS がアンインストールされます。必要な場合、DS 64224 を再インストールして、ローカル ゲートウェイで高い CPU 使用率の監視を続行してください。
異常な通話切断の監視
この DS は、10 分ごとに SNMP ポーリングを使用して、SIP エラーの 403、488、503 で異常な通話切断を検出します。 エラーカウントの増分が最後の投票から 5 以上である場合、syslog とメール通知が生成されます。 署名をインストールするには、以下の手順を使用してください。
-
コマンド show snmp を使用して、SNMP が有効 になっている必要があります。SNMP が有効になっていない場合は、snmp-server manager コマンドを設定します。
show snmp %SNMP agent not enabled config t snmp-server manager end show snmp シャーシ: ABCDEFGHIGK 149655 SNMP パケット入力0 悪い SNMP バージョンエラー1 不明なコミュニティ名0 提供されたコミュニティ名の違法操作0 エンコーディングエラー 37763 リクエストされた変数の数2 変数の数 34560 取得リクエストPDU 138 取得ネクストPDU 2 セットリクエスト PDU 0 入力キューパケットドロップ(最大キューサイズ1000) 158277 SNMPパケット出力0 大きすぎるエラー (最大パケットサイズ 1500) 20 そのような名前エラーはありません0 悪い値エラー0 一般エラー 7998 応答 PDU 10280 トラップ PDU 現在 SNMP プロセス入力キューにあるパケット: 0 SNMP global trap: 有効
-
Diagnostic Signatures Lookup Tool の以下のオプションを使用して、DS 65221 をダウンロードします。
フィールド名
フィールド値
プラットフォーム
Cisco 4300、4400 ISR シリーズ、または Catalyst 8000V Edge ソフトウェア
製品
Webex Calling ソリューションの CUBE Enterprise
問題の範囲
パフォーマンス
問題の種類
メールおよび Syslog 通知による SIP の異常通話切断検出
-
DS XML ファイルをローカルゲートウェイにコピーします。
ftp://username:password@/DS_65221.xml bootflash:
-
ローカルゲートウェイに DS XML ファイルをインストールします。
call-home diagnostic-signature load DS_65221.xml ロードファイル DS_65221.xml 成功
-
コマンド show call-home diagnostic-signature を使用して、署名が正常にインストールされていることを確認します。ステータス列の値が「registered」になっているはずです。
診断署名をインストールして問題のトラブルシューティングを行う
診断署名 (DS) を使用して、問題を迅速に解決できます。Cisco TAC エンジニアは、特定の問題のトラブルシューティング、問題の発生を検出、診断データの正しいセットを収集し、データを Cisco TAC ケースに自動的に転送するために必要なデバッグを可能にするための署名を作成しました。これにより、問題の発生を手動で確認する必要がなくなり、断続的、および一時的な問題のトラブルシューティングがはるかに容易になります。
診断 署名ルックアップ ツールを使用して、適用可能な署名を見つけ、与えられた問題を解決するためにインストールするか、サポート エンゲージメントの一部として、TAC エンジニアが推奨する署名をインストールできます。
以下の例は、「%VOICE_IEC-3-GW: CCAPI: Internal Error (call spike threshold): SYSLOG=1.1.181.1.29.0" syslog を使用して、以下の手順を使用して、診断データの収集を自動化します。
診断データをアップロードするために、Cisco TAC ファイル サーバー パス (cxd.cisco.com) として別の DS 環境変数ds_fsurl_prefix を構成します。 ファイルパスのユーザー名はケース番号で、パスワードはファイルアップロードトークンで、次のように Support Case Manager から取得できます。 ファイルアップロードトークンは、必要に応じて Support Case Manager の [添付ファイル] セクションで生成できます。
ターミナル call-home diagnostic-signature LocalGateway(cfg-call-home-diag-sign)環境を構成する ds_fsurl_prefix "scp://:@cxd.cisco.com" end
例:
call-home diagnostic-signature 環境 ds_fsurl_prefix "環境 ds_fsurl_prefix "scp://612345678:abcdefghijklmnop@cxd.cisco.com"
-
コマンド show snmp を使用して、SNMP が有効 になっている必要があります。SNMP が有効になっていない場合は、snmp-server manager コマンドを設定します。
show snmp %SNMP agent not enabled config t snmp-server manager end
-
高 CPU 使用率の期間中に、すべてのデバッグと診断署名を無効にすることを推奨するプロアクティブな措置として、高 CPU モニタリング DS 64224 をインストールすることを推奨します。Diagnostic Signatures Lookup Tool の以下のオプションを使用して、DS 64224 をダウンロードします。
フィールド名
フィールド値
プラットフォーム
Cisco 4300、4400 ISR シリーズ、または Catalyst 8000V Edge ソフトウェア
製品
Webex Calling ソリューションの CUBE Enterprise
問題の範囲
パフォーマンス
問題の種類
通知メールによる CPU 使用率が高い
-
Diagnostic Signatures Lookup Tool の以下のオプションを使用して、DS 65095 をダウンロードします。
フィールド名
フィールド値
プラットフォーム
Cisco 4300、4400 ISR シリーズ、または Catalyst 8000V Edge ソフトウェア
製品
Webex Calling ソリューションの CUBE Enterprise
問題の範囲
Syslog
問題の種類
Syslog - %VOICE_IEC-3-GW: CCAPI: Internal Error (Call spike threshold): IEC=1.1.181.1.29.0
-
DS XML ファイルをローカルゲートウェイにコピーします。
ftp://username:password@/DS_64224.xml bootflash: ftp://username:password@/DS_65095.xml bootflash:
-
ローカル ゲートウェイに高 CPU モニタリング DS 64224 および DS 65095 XML ファイルをインストールします。
call-home diagnostic-signature load DS_64224.xml ロードファイル DS_64224.xml 成功 call-home diagnostic-signature load DS_65095.xml ロードファイル DS_65095.xml 成功
-
show call-home diagnostic-signature を使用して、署名が正常にインストールされていることを確認します。ステータス列の値が「registered」になっているはずです。
show call-home diagnostic-signature 現在の診断署名設定: Diagnostic-signature: enabled Profile: CiscoTAC-1 (status: ACTIVE) Downloading URL(s):https://tools.cisco.com/its/service/oddce/services/DDCEService 環境変数: ds_email: username@gmail.com ds_fsurl_prefix: scp://612345678:abcdefghijklmnop@cxd.cisco.com
ダウンロードされた DSes:
DS ID
DS 名
リビジョン
ステータス
最終更新日時(GMT+00:00)
64224
00:07:45
DS_LGW_CPU_MON75
0.0.10
登録済み
2020-11-08:00:07:45
65095
00:12:53
DSLGW_IEC_C_all_spike_threshold
0.0.12
登録済み
2020-11-08:00:12:53
診断署名の実行を確認します
次のコマンド で、ローカル ゲートウェイが署名内で定義されたアクションを実行する間、コマンドの「ステータス」列は「実行中」に変更されます。show-home 診断署名 統計の出力は、診断署名が関心のあるイベントを検出してアクションを実行したかどうかを検証するための最適な方法です。「トリガーされた/Max/Deinstall」欄は、指定された署名がイベントをトリガーした回数、イベントを検出するために定義される最大回数、トリガーされたイベントの最大数を検出した後に署名が自身をインストールアンインストールするかどうかを示します。
show call-home diagnostic-signature 現在の診断署名設定: Diagnostic-signature: enabled
Profile: CiscoTAC-1 (status: ACTIVE)
Downloading URL(s):https://tools.cisco.com/its/service/oddce/services/DDCEService 環境変数: ds_email: carunach@cisco.com ds_fsurl_prefix: scp://612345678:abcdefghijklmnop@cxd.cisco.com
ダウンロードされた DSes:
DS ID |
DS 名 |
リビジョン |
ステータス |
最終更新日時(GMT+00:00) |
---|---|---|---|---|
64224 |
DS_LGW_CPU_MON75 |
0.0.10 |
登録済み |
2020-11-08 00:07:45 |
65095 |
DS_LGW_IEC_Call_spike_threshold |
0.0.12 |
実行中 |
2020-11-08 00:12:53 |
コール ホーム診断署名統計を表示する
DS ID |
DS 名 |
トリガー済み/Max/Deinstall |
平均実行時間(秒) |
最長実行時間(秒) |
---|---|---|---|---|
64224 |
DS_LGW_CPU_MON75 |
0/0/N |
0.000 |
0.000 |
65095 |
DS_LGW_IEC_Call_spike_threshold |
1/20/日 |
23.053 |
23.053 |
診断署名通知メール送信されるレポートには、問題の種類、デバイスの詳細、ソフトウェア バージョン、コンフィギュレーションの実行、および与えられた問題のトラブルシューティングに関連するコマンド出力の表示などの重要な情報が含されます。
診断署名をアンインストールする
トラブルシューティングのために診断署名を使用すると、一般的に、いくつかの問題が発生した場合の検出後にアンインストールするために定義されます。署名を手動でアンインストールする場合、show call-home diagnostic-signature の出力から DS ID を取得し、以下のコマンドを実行します。
call-home diagnostic-signature のデインストール
例:
call-home diagnostic-signature deinstall 64224
診断署名ルックアップ ツールに、展開で見られる問題に基づいて、定期的に新しい署名が追加されます。TAC では現在、新しいカスタム署名の作成リクエストをサポートしていません。