- ホーム
- /
- 投稿記事
Webex Calling 設定ワークフロー
パートナー、管理者、ユーザーにかかわらず、Webex Calling に関して利用可能なすべての情報を使用して、ベアリングを取得します。ここに記載されているリンクを使用して、Webex Calling で利用可能なすべてのサービスと機能の使用を開始できます。
Webex Calling のローカル ゲートウェイの要件
一般的な前提条件
Webex Callingのローカル ゲートウェイを設定する前に、次のことを確認してください。
VoIP の原理についての基本的な知識があること
Cisco IOS-XE と IOS-XE 音声のコンセプトについて、基本的で実際的な知識があること
セッション開始プロトコル (SIP) の基本的な理解がある
導入モデルに Cisco Unified Communications Manager (Unified CM) が含まれている場合には、Unified CM についての基本的な理解があること
詳細については、『Cisco Unified Border Element (CUBE) Enterprise Configuration Guide』を参照してください。
ローカル ゲートウェイのハードウェアおよびソフトウェア的要件
展開に「Local Gateway for Webex Calling 注文ガイドのローカル ゲートウェイ.」の表 1 にある 1 つ以上のローカル ゲートウェイ (Cisco CUBE (IP ベース接続) または Cisco IOS Gateway (TDM ベース接続)) があることを確認します。 また、「ローカル ゲートウェイ構成ガイド」に従って、プラットフォームがサポートされている IOS-XE リリースを実行しているか確認してください。
ローカル ゲートウェイのライセンスに関する要件
CUBE コールライセンスは、ローカル ゲートウェイにインストールされている必要があります。 詳細については、Cisco Unified 境界要素の構成ガイドを参照してください。
ローカル ゲートウェイの認証およびセキュリティ的要件
Webex Calling は、安全な信号経路とメディアを必要とします。 ローカルゲートウェイは暗号化を行います。また、以下の手順に従って、TLS 接続をクラウド方向に確立する必要があります。
LGW は、Cisco PKI からの CA ルートバンドルで更新しておく必要があります
LGW を構成する際には、Control Hub のトランク構成ページから取得した一連の SIP ダイジェスト資格情報が使用されます(この手順は、この後の構成の一部です)
CA ルート バンドルは、提示された証明書を検証します
資格情報が要求されます (SIP ダイジェストにより提供されたもの)
クラウドは、どのローカル ゲートウェイがセキュアに登録されているかを識別します
ローカルゲートウェイのファイアウォール、NAT Traversal、メディアパス最適化の各要件
ほとんどの場合、ローカル ゲートウェイとエンドポイントは、NAT によるプライベート IP アドレスを使用して、内部の顧客ネットワークに配置することができます。 エンタープライズ ファイアウォールは、特定の IP アドレス/ポートに対する外向きトラフィック (SIP、RTP/UDP、HTTP) を許可していなければなりません。この点は、「ポート参照情報」で説明されています。
ICE でメディアパスの最適化を利用する場合、ローカルゲートウェイの Webex Calling に面しているインターフェイスには Webex Calling エンドポイントとの双方向の直接ネットワークパスが必要です。 エンドポイントが別のロケーションにあり、ローカルゲートウェイの Webex Calling に面しているインターフェイスとこのエンドポイントとの間に直接ネットワークパスがない場合、メディアパスの最適化を利用するには、ローカルゲートウェイとエンドポイント間の通話のために、Webex Calling に面しているインターフェイスに割り当てられたパブリック IP アドレスをローカルゲートウェイに設定する必要があります。 また、IOS-XE バージョン 16.12.5 を実行している必要があります。
Webex Calling サービスを稼働させるための最初のステップは、初回セットアップ ウィザード (FTSW) を完了することです。 最初のロケーションの FTSW が完了した後では、追加のロケーションに対して完了する必要がありません。
1 | 受け取ったウェルカム メールのはじめにリンクをクリックします。
| ||
2 | 利用規約を見直して、承諾します。 | ||
3 | プランを見直して、[はじめに] をクリックします。
| ||
4 | データ センターがマッピングする国を選択し、顧客の連絡先と顧客アドレス情報を入力します。 | ||
5 | [次へ: デフォルトのロケーション | ||
6 | 次のオプションから選択します:
| ||
7 | このロケーションに適用する次の選択を行います。
| ||
8 | [次へ] をクリックします。 | ||
9 | 利用可能な Cisco Webex SIP アドレスを入力し、[次へ] をクリックし、[完了] を選択します。 |
始める前に
新しいロケーションを作成するには、以下の情報を指定します。
ロケーションの住所
希望する電話番号(オプション)
1 | 以下で Control Hub にログインします:https://admin.webex.com 、 を選択します。
| ||||
2 | ロケーションを設定します。
| ||||
3 | クリック保存を選択してはい/いいえをクリックし、今すぐまたは後でロケーションに番号を追加します。 | ||||
4 | [今すぐ追加] をクリックしたら、次のいずれかのオプションを選択してください。
PSTN オプションの選択は各ロケーション レベルで行います (各ロケーションには PSTN オプションが 1 つしかありません)。 展開に対して必要な数のオプションを組み合わせることができますが、各ロケーションには 1 つのオプションとなります。 PSTN オプションを選択してプロビジョニングしたら、ロケーションの PSTN プロパティで [管理] をクリックすると、オプションを変更できます。 ただし、Cisco PSTN などの一部のオプションは、別のオプションが割り当てられた後は使用できない場合があります。 サポート ケースを開いてご相談ください。 | ||||
5 | 番号を今すぐに有効にするか、または後で有効にするかを選択します。 | ||||
6 | 統合されていない CCP またはプレミス ベースの PSTN を選択した場合は、電話番号をコンマ区切り値として入力し、[検証] をクリックします。 特定のロケーションのための番号が追加されます。 有効なエントリは [検証済みの番号] フィールドに移動し、無効なエントリは [番号の追加] フィールドに残り、エラー メッセージが表示されます。 番号の書式は、ロケーションの所在する国に応じ、ダイヤリングに関する地元の要件に従って定められます。 たとえば、国コードが必要な場合には、コードを付けて入力することも、コードなしで入力してからコードが自動的に先頭に追加されるようにすることもできます。 | ||||
7 | [保存] をクリックします。 |
次に行うこと
ロケーションを作成した後、そのロケーションの緊急 911 サービスを有効にすることができます。 詳細については「Webex Calling の RedSky 緊急 911 サービス」を参照してください。
始める前に
ロケーションに関連付けられているユーザーとワークスペースのリストを取得します。 [サービス] >[番号] に移動し、ドロップダウン メニューから削除するロケーションを選択します。これらのユーザーとワークスペースを削除する必要があります。 ロケーションを削除する前に、このロケーションに関連付けられているすべての番号は、PSTN プロバイダーに戻されることに注意してください。つまり、これらの番号は所有しなくなります。 |
1 | 以下で Control Hub にログインします:https://admin.webex.com 、 を選択します。 |
2 | クリック |
3 | 選ぶロケーションを削除を選択し、ロケーションを削除することを確認します。 ロケーションが完全に削除されるまで通常数分かかりますが、最大で 1 時間かかる場合があります。 ロケーション名の横にある [詳細] をクリックし、[削除ステータス] を選択して、ステータスを確認できます。 |
PSTN の設定を変更するだけではなく、作成された後に名前、タイムゾーン、言語を指定することも可能です。 新しい言語は新しいユーザーとデバイスにのみ適用されることに注意してください。 既存のユーザーおよびデバイスは古い言語を使用し続けます。
既存のロケーションについては、緊急時の 911 サービスを有効にすることができます。 詳細については「Webex Calling の RedSky 緊急 911 サービス」を参照してください。 |
1 | 以下で Control Hub にログインします:https://admin.webex.com 、 を選択します。 場所の隣に警告アイコンが表示されている場合は、その場所の電話番号がまだ設定されていないことを意味します。 その番号を設定するまでは、コールを受発信できません。 | ||||||
2 | (オプション) [PSTN 接続] の下で、すでに設定されているものに応じて、[クラウド接続 PSTN] または [プレミスベースの PSTN](ローカル ゲートウェイ) のいずれかを選択します。 [管理] をクリックして設定を変更してから、[続行] を選択することにより、関連するリスクを承認します。 以下のオプションのいずれかを選択して、[保存] クリックします。
| ||||||
3 | ロケーションの主な連絡先担当者に連絡する際の代表番号を入力します。 | ||||||
4 | (オプション) [緊急コール] で[緊急時のロケーション識別子] を選択して、このロケーションに割り当てることができます。
| ||||||
5 | このロケーションでユーザーがボイスメールをチェックするために呼び出せる [ボイスメール番号] を選択します。 | ||||||
6 | (オプション) ロケーション ページの上部にある鉛筆アイコンをクリックし、必要に応じて [ロケーションの名前]、[アナウンス言語]、[メール言語]、[タイムゾーン]、[住所] を変更し、[保存] をクリックします。
|
これらの設定は社内ダイヤルに適用されるものであり、最初のセットアップ ウィザードでも設定できます。 ダイヤル プランを変更すると、Control Hub の更新のサンプル番号が表示され、これらの変更が表示されます。
ロケーションに対する発信通話の権限を設定できます。 これらのステップをご覧になり、発信権限を設定してください。 |
1 | Control Hub にサインインし、 を選択してから、[内部ダイヤル]までスクロールします。 | ||||||||
2 | 必要に応じて、次のオプションのダイヤル設定を行います。
| ||||||||
3 | 特定の場所の内部ダイヤルを指定します。 通話]をクリックします。 [ダイヤル] までスクロールし、必要に応じて内部ダイヤルを変更します。 ]を選択し、リストからロケーションを選択して、[
| ||||||||
4 | 特定のロケーションの外部ダイヤルを指定します。 通話]をクリックします。 [ダイヤル] までスクロールし、必要に応じて外部ダイヤルを変更します。 ]を選択し、リストからロケーションを選択して、[
ユーザーへの影響:
|
付加価値再販業者の場合、これらの手順を使用して Control Hub でローカル ゲートウェイの設定を開始できます。 このゲートウェイがクラウドに登録されると、Webex Calling の 1 つ以上のロケーションで使用して、エンタープライズ PSTN サービス プロバイダーへのルーティングを提供できます。
ローカル ゲートウェイがある場所は、ローカル ゲートウェイが他の場所で使用されているときには削除できません。 |
始める前に
ロケーションが追加されたら、ロケーションに対してプレミスベース PSTN を設定する前に、トランクを作成する必要があります。
それぞれについて、ロケーションと固有の設定および番号を作成します。 ロケーションはプレミスベース PSTN を追加する前に存在する必要があります。
Webex Calling でのプレミスベース PSTN (ローカル ゲートウェイ) 要件について理解しておいてください。
プレミスベース PSTN を持つロケーションに対して、複数のトランクを選択できませんが、複数のロケーションに対して同じトランクを選択することはできます。
1 | ログインするコントロールハブで、サービス次のリンクをクリックしてください:電話次のリンクをクリックしてください:コール ルーティングを選択し、トランクの追加を選択します。https://admin.webex.com | ||
2 | ロケーションを選択します。 | ||
3 | トランクの名前を指定し、[保存] をクリックします。
|
次に行うこと
画面 [ドメインの登録]、[トランク グループ OTG/DTG]、[回線/ポート]、および [発信プロキシ アドレス] にトランク情報が表示されます。
プレミス ベースの PSTN を設定する準備ができたときに参照できるように、この情報を Control Hub からコピーして、ローカルのテキスト ファイルまたはドキュメントに貼り付けておくことをおすすめします。
資格情報を紛失した場合には、Control Hub のトランク情報画面で生成する必要があります。 [ユーザー名の取得とパスワードのリセット] をクリックして、トランクを使用するための認証資格情報の新しいセットを生成します。
1 | 以下で Control Hub にログインします:https://admin.webex.com 、 を選択します。 | ||
2 | 変更する場所を選択し、[管理] をクリックします。 | ||
3 | プレミスベース PSTN を選択して、[次へ] をクリックします。 | ||
4 | ドロップダウン メニューからトランクを選択します。
| ||
5 | 確認通知をクリックし、[保存] をクリックします。 |
次に行うこと
Control Hub で生成された設定情報を記録し、パラメーターをローカル ゲートウェイ (たとえばオンプレミスの Cisco CUBE) にマップする必要があります。 この記事では、このプロセスについて順を追って説明します。 参考のため、次の図を参照して、どのように Control Hub の設定情報 (左側) が CUBE のパラメーター (右側) にマップされるかを確認してください。
ゲートウェイ自体の設定が正常に完了し、Control Hub の [サービス] > [通話] > [ロケーション] に戻ると、作成したゲートウェイが、名前の左側に緑色のドットが付けられてロケーション カードにリストされます。
このステータスは、ゲートウェイがセキュアに通話クラウドに対して登録され、そのロケーションでのアクティブな PSTN としての役割を果たしていることを示しています。Control Hub では、組織の電話番号を簡単に表示、アクティベート、削除、追加できます。 詳細については、「Control Hub で電話番号を管理する」を参照してください。
Webex サービスを試していて、トライアルから有料サブスクリプションに変更したい場合は、メールでパートナーにリクエストできます。
1 | https://admin.webex.comでControl Hubにログインし、建物のアイコンを選択します。 |
2 | [サブスクリプション] タブを選択し、[今すぐ購入] をクリックします。 有料サブスクリプションへの変換に興味を持っていることを知らせるメールがパートナーに送信されます。 |
Control Hub を使用して、Webex アプリでユーザーに表示する利用可能な通話オプションの優先度を設定できます。 シングルクリック通話を有効にすることもできます。 詳細については、「 Webexアプリ ユーザーの通話オプションを設定するを選択します。
ユーザーが発信する際に開く通話アプリケーションを制御することができます。 通話クライアントの設定を構成できます。これにはUnified CMまたはWebex CallingおよびCiscoの有料通話サービスを利用していないユーザー。 詳細については、「 通話動作をセットアップします。
概要
Webex Calling は現在、ローカル ゲートウェイの 2 つのバージョンをサポートしています。
ローカル ゲートウェイ
政府版 Webex のローカル ゲートウェイ
開始する前に、Webex Calling のプレミスベースの公衆交換電話ネットワーク (PSTN) およびローカル ゲートウェイ (LGW) の要件を理解してください。 参照先Webex Callingに対するCiscoの推奨アーキテクチャをご覧ください。
この記事では、既存の音声構成がない専用のローカル ゲートウェイプラットフォームが設置されていることを前提としています。 既存の PSTN ゲートウェイまたは CUBE Enterprise 展開を Webex Calling のローカル ゲートウェイ機能として使用するように変更する場合は、設定に注意してください。 変更を行うため、既存のコール フローと機能を中断しないようにしてください。
この手順には、個々のコマンド オプションの詳細が記載されているコマンド リファレンス ドキュメントへのリンクが含まれています。 すべてのコマンド リファレンス リンクは、 Webexマネージド ゲートウェイ コマンド リファレンス特に断らない限り (その場合、コマンドリンクはCisco IOS音声コマンド リファレンス) を選択してください。 これらのガイドはすべて、Cisco Unified Border Element コマンド リファレンスからアクセスできます。 サポートされているサードパーティ SBC の詳細については、各製品参照ドキュメントを参照してください。 |
ローカル ゲートウェイを構成するためのオプションが 2 つあります。 Webex Callingトランク:
登録ベースのトランク
証明書ベースのトランク
下のいずれかでタスクフローを使用し、登録ベースのローカル ゲートウェイまたは証明書ベースのローカル ゲートウェイローカル ゲートウェイの設定Webex Calling trunk。
さまざまなトランクタイプの詳細については、「ローカル ゲートウェイの使い方」を参照してください。 コマンドライン インターフェイス(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 証明書ベースのトランクの設定」を参照してください。
政府版 Webex は登録ベースのローカル ゲートウェイをサポートしていません。 |
このセクションでは、登録 SIP トランクを使用して、Webex Calling のローカル ゲートウェイとして Cisco Unified Border Element(CUBE)を設定する方法について説明します。 このドキュメントの最初の部分は、シンプルな PSTN ゲートウェイを設定する方法を示しています。 この場合、PSTN からのすべてのコールは Webex Calling にルーティングされ、Webex Calling からのすべてのコールは PSTN にルーティングされます。 下の画像では、このソリューションとそれに続く高レベルのコール ルーティング設定が強調されています。
この設計では、次の主な構成が使用されます。
音声クラスのテナント: トランク固有の設定を作成するために使用されます。
音声クラス uri: 着信ダイヤルピアの選択のための SIP メッセージを分類するために使用。
着信ダイヤルピア: 着信 SIP メッセージの処理を提供し、ダイヤルピア グループで発信ルートを決定します。
ダイヤルピア グループ: オンワード コール ルーティングに使用する発信ダイヤル ピアを定義します。
発信ダイヤルピア: アウトバウンド SIP メッセージの処理を提供し、必要なターゲットにルーティングします。
オンプレミスの 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 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 トラストポイントを作成します。
| ||
4 | TLS1.2 排他を有効にし、次の設定コマンドを使用してデフォルトのトラストポイントを指定します。 登録のための信頼性の高い安全な接続を確保するために、トランスポートパラメータも更新する必要があります。
| ||
5 | Webex Calling で使用される DigiCert CA 証明書を含む Cisco ルート CA バンドルをインストールします。 を使用する crypto pki trustpool インポート クリーン URLコマンドは、指定されたURLからルートCAバンドルをダウンロードし、現在のCAトラストプールをクリアしてから、証明書の新しいバンドルをインストールします。
|
1 | Control Hub の既存のロケーションに登録ベースの PSTN トランクを作成します。 トランクが作成されると、提供されたトランク情報をメモします。 次の図で強調表示されているこれらの詳細は、このガイドの設定手順で使用されます。 詳細については、次のサイトを参照してください。 Webex Calling用にトランク、ルートグループ、ダイヤルプランを構成するを選択します。 | ||||
2 | 次のコマンドを入力して、CUBE を Webex Calling ローカル ゲートウェイとして設定します。
構成のフィールドの説明はここにあります。
プラットフォームで Cisco Unified Border Element(CUBE)機能を有効にします。 メディア統計ローカル ゲートウェイでメディア監視を有効にします。 メディア一括統計一括コール統計のためにコントロール プレーンがデータ プレーンを投票できるようにします。 これらのコマンドの詳細については、「メディア」を参照してください。 allow-connections sip to sipCUBE 基本 SIP バックツーバック ユーザ エージェント機能を有効にします。 詳細については、次のサイトを参照してください。接続を許可を選択します。
STUN (NAT を介した UDP のセッショントラバーサル) をグローバルに有効にします。
詳細については、次のサイトを参照してください。スタンフローデータエージェント-idおよびスタンフローデータ共有シークレットを選択します。 非対称ペイロード フルDTMF と動的コーデック ペイロードの両方に対して SIP 非対称ペイロード サポートを設定します。 このコマンドの詳細については、次を参照してください非対称ペイロードを選択します。 early-offer forcedローカル ゲートウェイは、隣接するピアからの確認を待つ代わりに、最初の INVITE メッセージで SDP 情報を送信するように強制します。 このコマンドの詳細については、次を参照してください早期オファーを選択します。 | ||||
3 | を設定する 音声クラス コーデック 100 トランクのフィルタ。 この例では、すべてのトランクに同じコーデックフィルタが使用されます。 正確な制御のために各トランクにフィルタを設定できます。
構成のフィールドの説明はここにあります。 音声クラス コーデック 100SIP トランクを介したコールの優先コーデックのみを許可するために使用されます。 詳細については、音声クラスコーデック を参照してください。
| ||||
4 | を設定する 音声クラスの使い方 100 は、Webex Calling トランクで ICE を有効にします。
構成のフィールドの説明はここにあります。 stunusageiceliteについてすべての Webex Calling のダイヤルピアに対して ICE-Lite を有効にして、可能な限り、メディア最適化を可能にするために使用。 詳細については、次のサイトを参照してください。音声クラススタンの使用およびスタン使用アイスライトを選択します。
| ||||
5 | Webex トラフィックのメディア暗号化ポリシーを設定します。
構成のフィールドの説明はここにあります。 音声クラス srtp-crypto 100SDP の SRTP 暗号スイート CUBE オファーおよび応答メッセージの唯一の SRTP オファーとして SHA1_80 を指定します。 Webex Calling は SHA180 のみをサポートします。_ 詳細については、次のサイトを参照してください。音声クラス SRTP 暗号化を選択します。 | ||||
6 | 宛先トランク パラメータに基づいて、ローカル ゲートウェイ トランクへのコールを一意に識別するパターンを設定します。
構成のフィールドの説明はここにあります。 音声クラス uri 100 sip着信トランク ダイヤル ピアへの着信 SIP 招待と一致するパターンを定義します。 このパターンを入力する場合、トランクが作成されたときに、dtg= の後に Control Hub で提供されるトランク OTG/DTG 値を使用します。 詳細については、音声クラス uri を参照してください。 | ||||
7 | を設定する sip プロファイル 100は、Webex Callingに送信される前にSIPメッセージを変更するために使用されます。
構成のフィールドの説明はここにあります。
| ||||
8 | Webex Calling トランクの設定: |
テナント を定義した後 100 および SIP VoIP ダイヤル ピアを設定すると、ゲートウェイは Webex Calling への TLS 接続を開始します。 この時点で、アクセス SBC はその証明書をローカル ゲートウェイに提示します。 ローカル ゲートウェイは、以前に更新された CA ルート バンドルを使用して、Webex Calling アクセス SBC 証明書を検証します。 証明書が認識されると、ローカル ゲートウェイと Webex Calling アクセス SBC の間で永続的な TLS セッションが確立されます。 ローカル ゲートウェイは、このセキュアな接続を使用して Webex アクセス SBC に登録できます。 登録が認証にチャレンジされた場合:
レスポンスには、クレデンシャル設定のusername、password、およびrealmパラメータが使用されます。
sip プロファイル 100 の変更ルールは、SIPS URL を SIP に変換するために使用されます。
アクセスSBCから200 OKを受信すると、登録が成功します。
上記の Webex Calling に対してトランクを構築した後、次の設定を使用して、SIP ベースの PSTN プロバイダーに対して暗号化されていないトランクを作成します。
サービス プロバイダーがセキュアな PSTN トランクを提供している場合、上記の Webex Calling トランクと同様の構成に従うことができます。 セキュアからセキュアなコール ルーティングは CUBE でサポートされています。 |
Cisco TDM-SIP ゲートウェイで PSTN コール レッグの TDM インターフェイスを設定するには、「ISDN PRI の設定」を参照してください。 |
1 | PSTN トランクからの着信コールを識別するには、次の音声クラス uri を設定します。
構成のフィールドの説明はここにあります。 音声クラス uri 200 sip着信トランク ダイヤル ピアへの着信 SIP 招待と一致するパターンを定義します。 このパターンを入力するときは、IP PSTN ゲートウェイの IP アドレスを使用します。 詳細については、音声クラス uri を参照してください。 |
2 | 次の IP PSTN ダイヤル ピアを設定します。
構成のフィールドの説明はここにあります。
次のタグでVoIPダイヤルピアを定義します300管理とトラブルシューティングを容易にするために意味のある説明を付けます。 詳細については、次のサイトを参照してください。ダイヤルピア音声。 destination-pattern BAD.BAD着信ダイヤル ピア グループを使用して発信コールをルーティングする場合は、ダミー接続先パターンが必要です。 詳細については、次のサイトを参照してください。 Destination-pattern(インターフェイス)を選択します。 session protocol sipv2ダイヤルピア 200 が SIP コール レッグを処理するように指定します。 詳細については、次のサイトを参照してください。 session Protocol (ダイヤル ピア)を選択します。 session target ipv4:192.168.80.13コール レッグを送信する宛先のターゲットIPv4アドレスを示します。 ここでのセッション ターゲットは ITSP のIPアドレスです。 詳細については、セッションターゲット (VoIP ダイヤルピア)を参照してください。 200 経由で 着信 uriVIA ヘッダーとIP PSTN のIPアドレスの一致基準を定義します。 ローカル ゲートウェイのすべての着信 IP PSTN コール レッグとダイヤル ピア 200 を一致させます。 詳細については、着信 URLを参照してください。 バインド制御ソースインタフェース GigabitEthernet0/0/0PSTN に送信されるメッセージのソース インターフェイスと関連する 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 プラットフォームを使用してローカル ゲートウェイを設定する場合は、次のセクションに進みます。 |
前のセクションの 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 ルーティングを指定します。
構成のフィールドの説明はここにあります。 次のコマンドは、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 コマンド出力の収集が含まれます。
統合ログファイルを生成する
HTTPS、SCP、FTP サーバなどのユーザー提供のネットワークロケーションにファイルをアップロードします。
TAC エンジニアは DS ファイルを作成し、整合性保護のためデジタル署名します。 各 DS ファイルには、システムによって割り当てられた固有の数値 ID があります。 Diagnostic Signatures Lookup ツール(DSLT)は、さまざまな問題の監視とトラブルシューティングに適切な署名を見つけるための単一の情報源です。
開始する前に:
ダウンロードした DS ファイルは編集しないでください。 DSLTを選択します。 変更したファイルは、整合性チェックエラーのためインストールに失敗します。
ローカル ゲートウェイがメール通知を送信するために必要な Simple Mail Transfer Protocol (SMTP) サーバー。
メール通知にセキュアなSMTPサーバーを使用する場合は、ローカルゲートウェイで IOS XE 17.6.1 以上が実行されていることを確認してください。
前提条件
IOS XE 17.6.1a 以降を実行しているローカル ゲートウェイ
診断署名はデフォルトで有効になっています。
デバイスが Cisco IOS XE 17.6.1a 以降を実行している場合、プロアクティブな通知を送信するために使用する、セキュアな電子メールサーバを設定します。
configure terminal call-home mail-server <username>:<pwd>@<email server> priority 1 secure tls end
環境変数を構成しますds_emailを通知する管理者のメールアドレスを入力します。
configure terminal call-home diagnostic-signature environment ds_email <email address> end
以下は、Cisco IOS XE 17.6.1a 以降で実行されているローカル ゲートウェイの設定例で、プロアクティブな通知をtacfaststart@gmail.com 安全なSMTPサーバーとしてGmailを使用:
Cisco IOS XE Bengaluru 17.6.x 以降のバージョンを使用することをお勧めします。 |
call-home
mail-server tacfaststart:password@smtp.gmail.com priority 1 secure tls
diagnostic-signature
environment ds_email "tacfaststart@gmail.com"
Cisco IOS XE ソフトウェアで実行されるローカルゲートウェイは OAuth をサポートする一般的な Web ベースの Gmail クライアントではないため、専用の Gmail アカウント設定を構成し、デバイスからのメールを適切に処理するための専用権限を指定する必要があります。 |
安全性の低いアプリアクセス]設定をオンにします。
を選択し、[「Google 以外のアプリを使って第三者があなたのアカウントにサインインすることができなくなりました」というメールが Gmail から送られてきたら、「はい、それは私です」と回答します。
プロアクティブ モニタリングのための診断署名をインストールする
高いCPU使用率の監視
この DS は、SNMP OID 1.3.6.1.4.1.9.2.1.56 を使用して、CPU 使用率を 5 秒間追跡します。 使用率が 75% 以上に達すると、すべてのデバッグが無効になり、ローカルゲートウェイにインストールされている診断署名がすべてアンインストールされます。 下記の手順を実行して署名をインストールします。
を使用する SNMPを表示 コマンドで SNMP を有効にします。 有効にしない場合は、snmpサーバーマネージャ コマンド
show snmp %SNMP agent not enabled config t snmp-server manager end show snmp Chassis: ABCDEFGHIGK 149655 SNMP packets input 0 Bad SNMP version errors 1 Unknown community name 0 Illegal operation for community name supplied 0 Encoding errors 37763 Number of requested variables 2 Number of altered variables 34560 Get-request PDUs 138 Get-next PDUs 2 Set-request PDUs 0 Input queue packet drops (Maximum queue size 1000) 158277 SNMP packets output 0 Too big errors (Maximum packet size 1500) 20 No such name errors 0 Bad values errors 0 General errors 7998 Response PDUs 10280 Trap PDUs Packets currently in SNMP process input queue: 0 SNMP global trap: enabled
Diagnostic Signatures Lookup Tool の以下のドロップダウンオプションを使用して、DS 64224 をダウンロードします。
フィールド名
フィールド値
プラットフォーム
Cisco 4300、4400 ISR シリーズ、または Cisco CSR 1000V シリーズ
製品
Webex Calling ソリューションの CUBE Enterprise
問題の範囲
パフォーマンス
問題の種類
メール通知での高CPU使用率。
DS XML ファイルをローカルゲートウェイフラッシュにコピーします。
LocalGateway# copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash:
次の例は、 FTPサーバーからローカルゲートウェイにファイルをコピーする方法を示しています。
copy ftp://user:pwd@192.0.2.12/DS_64224.xml bootflash: Accessing ftp://*:*@ 192.0.2.12/DS_64224.xml...! [OK - 3571/4096 bytes] 3571 bytes copied in 0.064 secs (55797 bytes/sec)
ローカルゲートウェイに DS XML ファイルをインストールします。
call-home diagnostic-signature load DS_64224.xml Load file DS_64224.xml success
イベント、登録者、出席者にすばやくアクセスするため、 call-home 診断署名の表示を実行して、署名が正常にインストールされたことを確認します。 ステータス列の値が「registered」になっているはずです。
show call-home diagnostic-signature Current diagnostic-signature settings: Diagnostic-signature: enabled Profile: CiscoTAC-1 (status: ACTIVE) Downloading URL(s): https://tools.cisco.com/its/service/oddce/services/DDCEService Environment variable: 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 は、 Webex Callingクラウドをもつローカルゲートウェイ SIP トランクの登録解除を 60 秒ごとにチェックします。 登録解除イベントが検出されると、メールと syslog 通知が生成され、登録解除が 2 回発生した後に DS 自体がアンインストールされます。 署名をインストールするには、以下の手順を使用します。
Diagnostic Signatures Lookup Tool の以下のドロップダウンオプションを使用して、DS 64117 をダウンロードします。
フィールド名
フィールド値
プラットフォーム
Cisco 4300、4400 ISR シリーズ、または Cisco CSR 1000V シリーズ
製品
Webex Calling ソリューションの CUBE Enterprise
問題の範囲
SIP-SIP
問題の種類
メール通知による SIP トランクの登録解除。
DS XML ファイルをローカルゲートウェイにコピーします。
copy ftp://username:password@<server name or ip>/DS_64117.xml bootflash:
ローカルゲートウェイに DS XML ファイルをインストールします。
call-home diagnostic-signature load DS_64117.xml Load file DS_64117.xml success LocalGateway#
イベント、登録者、出席者にすばやくアクセスするため、 call-home 診断署名の表示を実行して、署名が正常にインストールされたことを確認します。 ステータス列の値が「registered」になっている必要があります。
異常な通話切断の監視
この DS は、10 分おきに SNMP ポーリングを使用して、SIP エラー 403、488、503 の異常な通話切断を検出します。 エラーカウントが前回の投票から 5 以上増えている場合、syslog とメール通知が生成されます。 下記の手順を実行して、署名をインストールしてください。
を使用する SNMPを表示 コマンドを使用して、SNMP が有効になっているかどうかを確認します。 有効になっていない場合は、snmpサーバーマネージャ コマンド
show snmp %SNMP agent not enabled config t snmp-server manager end show snmp Chassis: ABCDEFGHIGK 149655 SNMP packets input 0 Bad SNMP version errors 1 Unknown community name 0 Illegal operation for community name supplied 0 Encoding errors 37763 Number of requested variables 2 Number of altered variables 34560 Get-request PDUs 138 Get-next PDUs 2 Set-request PDUs 0 Input queue packet drops (Maximum queue size 1000) 158277 SNMP packets output 0 Too big errors (Maximum packet size 1500) 20 No such name errors 0 Bad values errors 0 General errors 7998 Response PDUs 10280 Trap PDUs Packets currently in SNMP process input queue: 0 SNMP global trap: enabled
Diagnostic Signatures Lookup Tool の以下のオプションを使用して、DS 65221 をダウンロードします。
フィールド名
フィールド値
プラットフォーム
Cisco 4300、4400 ISR シリーズ、または Cisco CSR 1000V シリーズ
製品
Webex Calling ソリューションの CUBE Enterprise
問題の範囲
パフォーマンス
問題の種類
メールおよび Syslog 通知による SIP の異常な通話切断の検出
DS XML ファイルをローカルゲートウェイにコピーします。
copy ftp://username:password@<server name or ip>/DS_65221.xml bootflash:
ローカルゲートウェイに DS XML ファイルをインストールします。
call-home diagnostic-signature load DS_65221.xml Load file DS_65221.xml success
イベント、登録者、出席者にすばやくアクセスするため、 call-home 診断署名の表示を実行して、署名が正常にインストールされたことを確認します。 ステータス列の値が「registered」になっている必要があります。
問題をトラブルシューティングするための診断署名をインストールする
診断署名(DS)を使用して、問題を迅速に解決します。 特定の問題のトラブルシューティング、問題発生の検出、診断データの適切なセットの収集、およびCisco TACケースへのデータの自動転送に必要なデバッグを可能にする複数の署名をCisco TACエンジニアが作成しました。 診断署名(DS)は、問題の発生を手動で確認する必要性を排除し、断続的および一時的な問題のトラブルシューティングをはるかに容易にします。
また、 Diagnostic Signatures Lookup ツール特定の問題を自分で解決するために、適切な署名を見つけ、インストールするか、サポート契約の一部として TAC エンジニアによって推奨される署名をインストールできます。
以下の例は、「%VOICE_IEC-3-GW: CCAPI: Internal Error (call spike threshold): IEC=1.1.181.1.29.0」の syslog 発生を検出し、以下のステップを使用して診断データ収集を自動化します。
追加の DS 環境変数を構成しますds_fsurl_prefix収集された診断データがアップロードされるCisco TACファイルサーバーパス (cxd.cisco.com) です。 ファイルパス内のユーザ名はケース番号で、パスワードはファイル アップロード トークンです。これはサポートケースマネージャーを次のコマンドで実行できます。 必要に応じて、サポートケースマネージャの [添付] セクションでファイルアップロードトークンを生成できます。
configure terminal call-home diagnostic-signature LocalGateway(cfg-call-home-diag-sign)environment ds_fsurl_prefix "scp://<case number>:<file upload token>@cxd.cisco.com" end
例:
call-home diagnostic-signature environment ds_fsurl_prefix " environment ds_fsurl_prefix "scp://612345678:abcdefghijklmnop@cxd.cisco.com"
SNMP がSNMPを表示 コマンド 有効になっていない場合は、snmpサーバーマネージャ コマンド
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 ファイルをローカルゲートウェイにコピーします。
copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash: copy ftp://username:password@<server name or ip>/DS_65095.xml bootflash:
ローカルゲートウェイに、高 CPU モニタリング DS 64224、DS 65095 XML ファイルの順にインストールします。
call-home diagnostic-signature load DS_64224.xml Load file DS_64224.xml success call-home diagnostic-signature load DS_65095.xml Load file DS_65095.xml success
署名が正常にインストールされたことを確認してください。 call-home 診断署名の表示します。 ステータス列の値が「registered」になっている必要があります。
show call-home diagnostic-signature Current diagnostic-signature settings: Diagnostic-signature: enabled Profile: CiscoTAC-1 (status: ACTIVE) Downloading URL(s): https://tools.cisco.com/its/service/oddce/services/DDCEService Environment variable: 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 日
診断署名の実行を確認する
次のコマンドでは、[状態] 列のcall-home 診断署名の表示ローカル ゲートウェイが署名内で定義されたアクションを実行している間、コマンドは「実行中」に変わります。 出力は次のとおりですCall-home 診断署名統計の表示は、診断署名が対象イベントを検出してアクションを実行するかどうかを検証するための最適な方法です。 [Triggered/Max/Deinstall] 列には、指定した署名がイベントをトリガーした回数、定義済みのイベント最大検出回数、トリガーされたイベントの検出後に署名がアンインストールされるかどうかが表示されます。
show call-home diagnostic-signature
Current diagnostic-signature settings:
Diagnostic-signature: enabled
Profile: CiscoTAC-1 (status: ACTIVE)
Downloading URL(s): https://tools.cisco.com/its/service/oddce/services/DDCEService
Environment variable:
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 |
Call-home 診断署名統計の表示
DS ID | DS 名 | トリガー済み/最大/アンインストール | 平均実行時間(秒) | 最長実行時間(秒) |
---|---|---|---|---|
64224 | DS_LGW_CPU_MON75 | 0/0/N | 0.000 | 0.000 |
65095 | DS_LGW_IEC_Call_spike_threshold | 1/20/Y | 23.053 | 23.053 |
診断署名の実行中に送信される通知メールには、問題の種類、デバイスの詳細、ソフトウェアバージョン、実行中の構成、特定の問題のトラブルシューティングに関連する show コマンド出力などの重要な情報が含まれています。
診断署名をアンインストールする
トラブルシューティング目的で診断署名を使用する場合、通常、診断署名はいくつかの問題の発生が検出された後にアンインストールするように定義されます。 署名を手動でアンインストールする場合は、コールホーム診断署名を表示コマンドを実行し、次のコマンドを実行します。
call-home diagnostic-signature deinstall <DS ID>
例:
call-home diagnostic-signature deinstall 64224
展開でよく見られる問題に基づいて、Diagnostics Signatures Lookup Tool に新しい署名が定期的に追加されます。 TAC では現在、新しいカスタム署名の作成リクエストをサポートしていません。 |
Cisco IOS XE ゲートウェイの管理を改善するため、コントロールハブを通じてゲートウェイを登録し、管理することを推奨します。 これはオプションの設定です。 登録すると、コントロール ハブの設定検証オプションを使用して、ローカル ゲートウェイ構成を検証し、構成の問題を特定することができます。 現在、この機能をサポートしているのは登録ベースのトランクだけです。
詳細については、以下を参照してください。
このセクションでは、証明書ベースの相互 TLS (mTLS) SIP トランクを使用して、Webex Calling のローカル ゲートウェイとして Cisco Unified Border Element (CUBE) を設定する方法について説明します。 このドキュメントの最初の部分は、シンプルな PSTN ゲートウェイを設定する方法を示しています。 この場合、PSTN からのすべてのコールは Webex Calling にルーティングされ、Webex Calling からのすべてのコールは PSTN にルーティングされます。 次の画像では、このソリューションとそれに続く高レベルのコール ルーティング設定が強調表示されます。
この設計では、次の主な構成が使用されます。
音声クラスのテナント: トランク固有の設定を作成するために使用されます。
音声クラス uri: 着信ダイヤルピアの選択のための SIP メッセージを分類するために使用。
着信ダイヤルピア: 着信 SIP メッセージの処理を提供し、ダイヤルピア グループで発信ルートを決定します。
ダイヤルピア グループ: オンワード コール ルーティングに使用する発信ダイヤル ピアを定義します。
発信ダイヤルピア: アウトバウンド SIP メッセージの処理を提供し、必要なターゲットにルーティングします。
オンプレミスの 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 Software Research」ページを参照してください。 プラットフォームを検索し、提案されたリリースのいずれかを選択します。
ISR4000 シリーズ ルータは、Unified Communications および Security テクノロジー ライセンスの両方で設定する必要があります。
Catalyst Edge 8000シリーズのルーターには、ボイスカードまたはDSPが装備されており、DNA Essentialsのライセンスが必要です。 ボイスカードやDSPのないルーターには、最低限のDNA Essentialsライセンスが必要です。
大容量の要件については、High Security(HSEC)ライセンスおよび追加のスループットエンタイトルメントが必要になる場合があります。
詳細については、認証コードを参照してください。
ビジネスポリシーに従うプラットフォームのベースライン設定を構築します。 特に、以下を設定し、作業を確認します。
NTP
ACL
ユーザー認証とリモートアクセス
DNS
IPルーティング
IP アドレス
Webex Calling に向かうネットワークは IPv4 アドレスを使用する必要があります。 ローカル ゲートウェイの完全修飾ドメイン名(FQDN)またはサービス レコード(SRV)アドレスは、インターネット上のパブリック IPv4 アドレスに解決する必要があります。
Webex に面しているローカル ゲートウェイ インターフェイスのすべての SIP ポートとメディア ポートは、直接または静的 NAT 経由でインターネットからアクセスできる必要があります。 それに応じてファイアウォールを更新してください。
署名付き証明書をローカル ゲートウェイにインストールします (詳細な設定手順は次のとおりです)。
Cisco Webex 音声およびビデオ プラットフォームへの通話でサポートされているルート認証局とはに詳述されているパブリック認証局 (CA) は、デバイス証明書に署名する必要があります。
トランクの作成時に Control Hub で設定された FQDN は、ルータの共通名(CN)またはサブジェクト代替名(SAN)の証明書である必要があります。 例:
組織の 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、レコード、またはIPアドレス)は、SAN ではオプションです。
トランクに FQDN または SRV を使用するかどうかにかかわらず、ローカル ゲートウェイからのすべての新しい SIP ダイアログの連絡先アドレスは、Control Hub で設定された名前を使用します。
証明書がクライアントとサーバで使用されていることを確認します。
Cisco ルート CA バンドルをローカル ゲートウェイにアップロードします。
構成
1 | 次のように、有効でルーティング可能な IP アドレスをレイヤ 3 インターフェイスに割り当てます。
| ||
2 | 対称暗号化を使用してルータの STUN クレデンシャルを保護します。 プライマリ暗号化キーと暗号化タイプを次のように設定します。
| ||
3 | 希望する認証局 (CA) によって署名された証明書を使用して暗号化トラストポイントを作成します。 | ||
4 | 中間(またはルート)CA 証明書を使用して新しい証明書を認証し、証明書をインポートします(ステップ 4)。 次の exec または configuration コマンドを入力します。
| ||
5 | 次の exec または configuration コマンドを使用して、署名済みホスト証明書をインポートします。
| ||
6 | TLS1.2 排他を有効にし、次の設定コマンドを使用してデフォルトのトラストポイントを指定します。
| ||
7 | Webex Calling で使用される DigiCert CA 証明書を含む Cisco ルート CA バンドルをインストールします。 を使用する crypto pki trustpool インポート クリーン URLコマンドは、指定されたURLからルートCAバンドルをダウンロードし、現在のCAトラストプールをクリアしてから、証明書の新しいバンドルをインストールします。
|
1 | Control Hub の既存のロケーションの CUBE 証明書ベースの PSTN トランクを作成します。 詳細については、次のサイトを参照してください。 Webex Calling用にトランク、ルートグループ、ダイヤルプランを構成するを選択します。
| ||||
2 | 次のコマンドを入力して、CUBE を Webex Calling ローカル ゲートウェイとして設定します。
構成のフィールドの説明はここにあります。
プラットフォームで Cisco Unified Border Element(CUBE)機能を有効にします。 allow-connections sip to sipCUBE 基本 SIP バックツーバックユーザーエージェント機能を有効にします。 詳細については、次のサイトを参照してください。接続を許可を選択します。
STUN (NAT を介した UDP のセッショントラバーサル) をグローバルに有効にします。
詳細については、「stun flowdata agent-id」および「stun flowdata shared-secret」を参照してください。 非対称ペイロード フルDTMF と動的コーデック ペイロードの両方に対して SIP 非対称ペイロード サポートを設定します。 このコマンドの詳細については、次を参照してください非対称ペイロードを選択します。 early-offer forcedローカル ゲートウェイは、隣接するピアからの確認を待つ代わりに、最初の INVITE メッセージで SDP 情報を送信するように強制します。 このコマンドの詳細については、次を参照してください早期オファーを選択します。 SIP プロファイル着信CUBE が SIP プロファイルを使用して、受信したメッセージを変更できるようにします。 プロファイルは、ダイヤルピアまたはテナントを介して適用されます。 | ||||
3 | を設定する 音声クラスコーデック 100 トランクの コーデック フィルタ。 この例では、すべてのトランクに同じコーデックフィルタが使用されます。 正確な制御のために各トランクにフィルタを設定できます。
構成のフィールドの説明はここにあります。 音声クラス コーデック 100SIP トランクを介したコールの優先コーデックのみを許可するために使用されます。 詳細については、音声クラスコーデック を参照してください。
| ||||
4 | を設定する 音声クラスの使い方 100 は、Webex Calling トランクで ICE を有効にします。 (この手順は政府版 Webex には適用されません)
構成のフィールドの説明はここにあります。 stunusageiceliteについてすべての Webex Calling のダイヤルピアに対して ICE-Lite を有効にして、可能な限り、メディア最適化を可能にするために使用。 詳細については、次のサイトを参照してください。音声クラススタンの使用およびスタン使用アイスライトを選択します。
| ||||
5 | Webex トラフィックのメディア暗号化ポリシーを設定します。 (この手順は政府版 Webex には適用されません)
構成のフィールドの説明はここにあります。 音声クラス srtp-crypto 100SDP の SRTP 暗号スイート CUBE オファーおよび応答メッセージの唯一の SRTP オファーとして SHA1_80 を指定します。 Webex Calling は SHA180 のみをサポートします。_ 詳細については、次のサイトを参照してください。音声クラス SRTP 暗号化を選択します。 | ||||
6 | FIPS 準拠の GCM 暗号を設定します(この手順は政府版 Webex にのみ適用されます)。
構成のフィールドの説明はここにあります。 音声クラス srtp-crypto 100CUBE が提供する暗号スイートとして GCM を指定します。 政府版 Webex のローカル ゲートウェイの GCM 暗号を設定することは必須です。 | ||||
7 | 宛先 FQDN または SRV に基づいて、ローカル ゲートウェイ トランクへのコールを一意に識別するためのパターンを設定します。
構成のフィールドの説明はここにあります。 音声クラス uri 100 sip着信トランク ダイヤル ピアへの着信 SIP 招待と一致するパターンを定義します。 このパターンを入力するときは、トランクの作成中に Control Hub で設定された LGW FQDN または SRV を使用します。 | ||||
8 | SIP メッセージ操作プロファイルを設定します。 ゲートウェイがパブリック IP アドレスで設定されている場合は、次のようにプロファイルを設定するか、NAT を使用している場合は、次のステップにスキップします。 この例では、cube1.lgw.com はローカル ゲートウェイ用に設定された FQDN であり、「198.51.100.1」は Webex Calling に面したローカル ゲートウェイ インターフェイスのパブリック IP アドレスです。
構成のフィールドの説明はここにあります。 ルール10と20Webex がローカル ゲートウェイからのメッセージを認証できるようにするには、SIP 要求および応答メッセージの「連絡先」ヘッダーに、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 要求および応答メッセージの「連絡先」ヘッダーに、Control Hub のトランクにプロビジョニングされた値が含まれている必要があります。 これは、単一のホストの FQDN、またはデバイスのクラスタに使用される SRV ドメイン名のいずれかになります。 ルール30~81プライベート アドレス参照をサイトの外部パブリック アドレスに変換し、Webex が後続のメッセージを正しく解釈してルーティングできるようにします。 Webex Calling からの着信メッセージの SIP プロファイル
構成のフィールドの説明はここにあります。 10から80までのルールパブリックアドレス参照を設定済みのプライベートアドレスに変換し、Webex からのメッセージを CUBE で正しく処理できるようにします。 詳細については、次のサイトを参照してください。音声クラス sip-プロファイルを選択します。 | ||||
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 でサポートされています。 |
Cisco TDM-SIP ゲートウェイで PSTN コール レッグの TDM インターフェイスを設定するには、「ISDN PRI の設定」を参照してください。 |
1 | PSTN トランクからの着信コールを識別するには、次の音声クラス uri を設定します。
構成のフィールドの説明はここにあります。 音声クラス uri 200 sip着信トランク ダイヤル ピアへの着信 SIP 招待と一致するパターンを定義します。 このパターンを入力するときは、IP PSTN ゲートウェイの IP アドレスを使用します。 詳細については、音声クラス uri を参照してください。 |
2 | 次の IP PSTN ダイヤル ピアを設定します。
構成のフィールドの説明はここにあります。
次のタグでVoIPダイヤルピアを定義します300管理とトラブルシューティングを容易にするために意味のある説明を付けます。 詳細については、次のサイトを参照してください。ダイヤルピア音声。 destination-pattern BAD.BAD着信ダイヤル ピア グループを使用して発信コールをルーティングする場合は、ダミー接続先パターンが必要です。 詳細については、次のサイトを参照してください。 Destination-pattern(インターフェイス)を選択します。 session protocol sipv2ダイヤルピア 200 が SIP コール レッグを処理するように指定します。 詳細については、次のサイトを参照してください。 session Protocol (ダイヤル ピア)を選択します。 session target ipv4:192.168.80.13コール レッグを送信する宛先のターゲットIPv4アドレスを示します。 ここでのセッション ターゲットは ITSP のIPアドレスです。 詳細については、セッションターゲット (VoIP ダイヤルピア)を参照してください。 200 経由で 着信 uriVIA ヘッダーとIP PSTN のIPアドレスの一致基準を定義します。 ローカル ゲートウェイのすべての着信 IP PSTN コール レッグとダイヤル ピア 200 を一致させます。 詳細については、着信 URLを参照してください。 バインド制御ソースインタフェース GigabitEthernet0/0/0PSTN に送信されるメッセージのソース インターフェイスと関連する 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 プラットフォームを使用してローカル ゲートウェイを設定する場合は、次のセクションに進みます。 |
前のセクションの PSTN-Webex Calling 設定は、Cisco Unified Communications Manager (UCM) クラスタへの追加のトランクを含めるように変更される場合があります。 この場合、すべてのコールは Unified CM 経由でルーティングされます。 ポート 5060 の UCM からのコールは PSTN にルーティングされ、ポート 5065 からのコールは Webex Calling にルーティングされます。 次の増分設定を追加して、この通話シナリオを含めることができます。
1 | 以下の音声クラス URI を設定: | ||
2 | 次の DNS レコードを設定して、Unified CM ホストへの SRV ルーティングを指定します。
構成のフィールドの説明はここにあります。 次のコマンドは、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 コマンド出力の定期的なモニタリングを通じて、問題検出ロジックを定義します。 アクション タイプには、次のものが含まれます。
show コマンド出力の収集
統合ログファイルを生成する
ユーザーが指定したネットワーク ロケーションへのファイルのアップロード (HTTPS、SCP、 FTPサーバーなど)
TAC エンジニアは DS ファイルを作成し、整合性保護のためデジタル署名を行います。 各 DS ファイルには、システムによって割り当てられた固有の数値IDがあります。 Diagnostic Signatures Lookup ツール(DSLT)は、さまざまな問題の監視とトラブルシューティングに適切な署名を見つけるための単一の情報源です。
開始する前に:
ダウンロードした DS ファイルは編集しないでください。 DSLTを選択します。 変更したファイルは、整合性チェックエラーのためインストールに失敗します。
ローカル ゲートウェイがメール通知を送信するために必要な Simple Mail Transfer Protocol (SMTP) サーバー。
メール通知にセキュアなSMTPサーバーを使用する場合は、ローカルゲートウェイで IOS XE 17.6.1 以上が実行されていることを確認してください。
前提条件
IOS XE 17.6.1 以降を実行しているローカルゲートウェイ
診断署名はデフォルトで有効になっています。
デバイスで IOS XE 17.6.1 以降を実行している場合は、プロアクティブ通知の送信に使用するセキュアなメールサーバーを構成します。
configure terminal call-home mail-server <username>:<pwd>@<email server> priority 1 secure tls end
環境変数を構成しますds_emailに管理者のメールアドレスを指定します。
configure terminal call-home diagnostic-signature LocalGateway(cfg-call-home-diag-sign)environment ds_email <email address> end
プロアクティブ モニタリングのための診断署名をインストールする
高いCPU使用率の監視
この DS はSNMP OID 1.3.6.1.4.1.9.2.1.56 を使用して 5 秒間のCPU使用率を追跡します。 使用率が 75% 以上に達すると、すべてのデバッグが無効になり、ローカルゲートウェイにインストールした診断署名がすべてアンインストールされます。 下記の手順を実行して署名をインストールします。
コマンド を使用して SNMP が有効になっていることを確認します。 SNMPを表示だ SNMPが有効になっていない場合は、snmpサーバーマネージャ コマンド
show snmp %SNMP agent not enabled config t snmp-server manager end show snmp Chassis: ABCDEFGHIGK 149655 SNMP packets input 0 Bad SNMP version errors 1 Unknown community name 0 Illegal operation for community name supplied 0 Encoding errors 37763 Number of requested variables 2 Number of altered variables 34560 Get-request PDUs 138 Get-next PDUs 2 Set-request PDUs 0 Input queue packet drops (Maximum queue size 1000) 158277 SNMP packets output 0 Too big errors (Maximum packet size 1500) 20 No such name errors 0 Bad values errors 0 General errors 7998 Response PDUs 10280 Trap PDUs Packets currently in SNMP process input queue: 0 SNMP global trap: enabled
Diagnostic Signatures Lookup Tool の以下のドロップダウンオプションを使用して、DS 64224 をダウンロードします。
copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash:
フィールド名
フィールド値
プラットフォーム
Cisco 4300、4400 ISR シリーズ、または Catalyst 8000V Edge ソフトウェア
製品
Webex Callingソリューションの CUBE Enterprise
問題の範囲
パフォーマンス
問題の種類
メール通知による高 CPU 使用率
DS XML ファイルをローカルゲートウェイフラッシュにコピーします。
copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash:
次の例は、 FTPサーバーからローカルゲートウェイにファイルをコピーする方法を示しています。
copy ftp://user:pwd@192.0.2.12/DS_64224.xml bootflash: Accessing ftp://*:*@ 192.0.2.12/DS_64224.xml...! [OK - 3571/4096 bytes] 3571 bytes copied in 0.064 secs (55797 bytes/sec)
ローカルゲートウェイに DS XML ファイルをインストールします。
call-home diagnostic-signature load DS_64224.xml Load file DS_64224.xml success
イベント、登録者、出席者にすばやくアクセスするため、 call-home 診断署名の表示を実行して、署名が正常にインストールされたことを確認します。 ステータス列の値が「registered」になっている必要があります。
show call-home diagnostic-signature Current diagnostic-signature settings: Diagnostic-signature: enabled Profile: CiscoTAC-1 (status: ACTIVE) Downloading URL(s): https://tools.cisco.com/its/service/oddce/services/DDCEService Environment variable: 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 とメール通知が生成されます。 下記の手順を実行して、署名をインストールしてください。
コマンド を使用して SNMP が有効になっていることを確認します。 SNMPを表示だ SNMP が有効になっていない場合は、snmpサーバーマネージャ コマンド
show snmp %SNMP agent not enabled config t snmp-server manager end show snmp Chassis: ABCDEFGHIGK 149655 SNMP packets input 0 Bad SNMP version errors 1 Unknown community name 0 Illegal operation for community name supplied 0 Encoding errors 37763 Number of requested variables 2 Number of altered variables 34560 Get-request PDUs 138 Get-next PDUs 2 Set-request PDUs 0 Input queue packet drops (Maximum queue size 1000) 158277 SNMP packets output 0 Too big errors (Maximum packet size 1500) 20 No such name errors 0 Bad values errors 0 General errors 7998 Response PDUs 10280 Trap PDUs Packets currently in SNMP process input queue: 0 SNMP global trap: enabled
Diagnostic Signatures Lookup Tool の以下のオプションを使用して、DS 65221 をダウンロードします。
フィールド名
フィールド値
プラットフォーム
Cisco 4300、4400 ISR シリーズ、または Catalyst 8000V Edge ソフトウェア
製品
Webex Calling ソリューションの CUBE Enterprise
問題の範囲
パフォーマンス
問題の種類
メールおよび Syslog 通知による SIP の異常な通話切断の検出
DS XML ファイルをローカルゲートウェイにコピーします。
copy ftp://username:password@<server name or ip>/DS_65221.xml bootflash:
ローカルゲートウェイに DS XML ファイルをインストールします。
call-home diagnostic-signature load DS_65221.xml Load file DS_65221.xml success
コマンドを使用するcall-home 診断署名の表示をクリックし、署名が正常にインストールされたことを確認します。 ステータス列の値が「registered」になっているはずです。
問題をトラブルシューティングするための診断署名をインストールする
診断署名(DS)を使用して問題を迅速に解決することもできます。 特定の問題のトラブルシューティング、問題発生の検出、診断データの適切なセットの収集、およびCisco TACケースへのデータの自動転送に必要なデバッグを可能にする複数の署名をCisco TACエンジニアが作成しました。 これにより、問題の発生を手動で確認する必要がなくなり、断続的、および一時的な問題のトラブルシューティングがはるかに容易になります。
また、 Diagnostic Signatures Lookup ツール特定の問題を自分で解決するために、適切な署名を見つけ、インストールするか、サポート契約の一部として TAC エンジニアによって推奨される署名をインストールできます。
以下の例は、「%VOICE_IEC-3-GW: CCAPI: Internal Error (call spike threshold): IEC=1.1.181.1.29.0」の syslog 発生を検出し、以下のステップを使用して診断データ収集を自動化します。
別の DS 環境変数を構成するds_fsurl_prefixをCisco TACファイルサーバーパス (cxd.cisco.com) として入力し、診断データをアップロードします。 ファイルパス内のユーザ名はケース番号で、パスワードはファイル アップロード トークンです。これはサポートケースマネージャー次に示すとおりです。 ファイル アップロード トークンは、添付ファイルを追加することができます。
configure terminal call-home diagnostic-signature LocalGateway(cfg-call-home-diag-sign)environment ds_fsurl_prefix "scp://<case number>:<file upload token>@cxd.cisco.com" end
例:
call-home diagnostic-signature environment ds_fsurl_prefix " environment ds_fsurl_prefix "scp://612345678:abcdefghijklmnop@cxd.cisco.com"
コマンド を使用して SNMP が有効になっていることを確認します。 SNMPを表示だ SNMP が有効になっていない場合は、snmpサーバーマネージャ コマンド
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 ファイルをローカルゲートウェイにコピーします。
copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash: copy ftp://username:password@<server name or ip>/DS_65095.xml bootflash:
高CPUモニタリング DS 64224 をインストールし、次に DS 65095 XMLファイルをローカルゲートウェイにインストールします。
call-home diagnostic-signature load DS_64224.xml Load file DS_64224.xml success call-home diagnostic-signature load DS_65095.xml Load file DS_65095.xml success
を使用して署名が正常にインストールされていることを確認します。 コールホーム診断署名を表示だ ステータス列の値が「registered」になっているはずです。
show call-home diagnostic-signature Current diagnostic-signature settings: Diagnostic-signature: enabled Profile: CiscoTAC-1 (status: ACTIVE) Downloading URL(s): https://tools.cisco.com/its/service/oddce/services/DDCEService Environment variable: 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
DS_LGW_IEC_Call_spike_threshold
0.0.12
登録済み
2020-11-08:00:12:53
診断署名の実行を確認する
次のコマンドでは、コマンドの [状態] 列call-home 診断署名の表示ローカル ゲートウェイが署名内で定義されたアクションを実行している間は、「実行中」に変更されます。 出力は次のとおりですCall-home 診断署名統計の表示診断署名が対象イベントを検出してアクションが実行されたかどうかを検証するための最適な方法です。 [Triggered/Max/Deinstall] 列には、指定した署名がイベントをトリガーした回数、定義済みのイベント最大検出回数、トリガーされたイベントの検出後に署名がアンインストールされるかどうかが表示されます。
show call-home diagnostic-signature
Current diagnostic-signature settings:
Diagnostic-signature: enabled
Profile: CiscoTAC-1 (status: ACTIVE)
Downloading URL(s): https://tools.cisco.com/its/service/oddce/services/DDCEService
Environment variable:
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 |
Call-home 診断署名統計の表示
DS ID | DS 名 | トリガー済み/最大/アンインストール | 平均実行時間(秒) | 最長実行時間(秒) |
---|---|---|---|---|
64224 | DS_LGW_CPU_MON75 |
0/0/N |
0.000 |
0.000 |
65095 |
DS_LGW_IEC_Call_spike_threshold |
1/20/Y |
23.053 |
23.053 |
診断署名の実行中に送信される通知メールには、問題の種類、デバイスの詳細、ソフトウェアバージョン、実行中の構成、特定の問題のトラブルシューティングに関連する show コマンド出力などの重要な情報が含まれています。
診断署名をアンインストールする
トラブルシューティング目的で診断署名を使用し、通常はいくつかの問題の発生が検出された後にアンインストールするように定義します。 署名を手動でアンインストールする場合、次の出力から DS IDを取得しますcall-home 診断署名の表示に移動し、次のコマンドを実行します。
call-home diagnostic-signature deinstall <DS ID>
例:
call-home diagnostic-signature deinstall 64224
展開で観察された問題に基づいて、Diagnostics Signatures Lookup Tool に新しい署名が定期的に追加されます。 TAC では現在、新しいカスタム署名の作成リクエストをサポートしていません。 |
基礎
前提条件
Webex Calling のローカル ゲートウェイとして CUBE HA を展開する前に、以下の概念を深く理解するようにしてください。
ステートフル コール保持のための CUBE エンタープライズによるレイヤー 2 ボックス間冗長性
この記事で提供される構成ガイドラインは、既存の音声構成が設定されていない専用のローカル ゲートウェイ プラットフォームが使用されていることを前提としています。 既存の CUBE エンタープライズ展開が、Cisco Webex Calling のローカル ゲートウェイ機能を使用するように変更されている場合、既存のコール フローと機能が中断されないようにして、CUBE HA 設計要件に準拠するように、設定に注意してください。
ハードウェアとソフトウェアのコンポーネント
ローカルゲートウェイとしての CUBE HA には IOS-XE バージョン 16.12.2 以降、および CUBE HA と LGW 機能の両方をサポートするプラットフォームが必要です。
この記事のコマンドとログの表示は、vCUBE(CSR1000v)で実装された Cisco IOS-XE 16.12.2 のソフトウェアの最小リリースに基づいています。 |
参考資料
さまざまなプラットフォーム向けの詳細な CUBE HA 設定ガイドを次に示します。
CSR 1000v (vCUBE)— https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-cube-high-availability-CSR1000v.html
Cisco Preferred Architecture for Cisco Webex Calling— https://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Collaboration/hybrid/AltDesigns/PA-WbxCall.pdf
Webex Calling ソリューションの概要
Cisco Webex Calling は、複数の PSTN オプションにより、オンプレミスの PBX 電話サービスにマルチテナントのクラウドベースの代替手段を提供するコラボレーションソリューションです。
この記事の焦点は、ローカル ゲートウェイの展開 (以下を参照) です。 Webex Calling のローカルゲートウェイ(プレミスベースの PSTN)トランクによって、顧客が所有する PSTN サービスへの接続が可能になります。 また、Cisco Unified CM などのオンプレミス IP PBX 展開への接続も提供します。 クラウド間のすべての通信は、メディア向け SIP および SRTP で TLS トランスポートを使用してセキュリティ保護されています。
次の図では、既存の IP PBX なしでの Webex Calling 展開を示し、単一または複数サイトの展開に適用されます。 この記事に記載されている設定は、この展開に基づいています。
レイヤー 2 のボックス間冗長性
CUBE HA レイヤー 2 ボックス間冗長性は、冗長性グループ (RG) インフラストラクチャ プロトコルを使用して、ルーターのアクティブ/スタンバイ ペアを形成します。 このペアは、それぞれのインターフェイスで同じ仮想 IP アドレス (VIP) を共有し、ステータ スメッセージを継続的に交換します。 CUBE セッションはルーターのペアリングのチェックポイントであり、アクティブ ルーターがサービスを停止した場合に、スタンバイ ルーターがすべての CUBE コール処理の責任を果たすことができるようになりました。その結果、シグナリングとメディアのステートフルな保持が可能になりました。
チェック ポイントは、メディア パケットのある接続されたコールに限定されます。 転送中のコールはチェック ポイントではありません (たとえば、試行中または呼出状態)。 この記事では、CUBE HA は、ステートフルコール保持の CUBE ハイ アベイラビリティ (HA) レイヤー 2 ボックス間 (B2B) 冗長性を参照します。 |
IOS-XE 16.12.2 では、CUBE HA を Cisco Webex Calling トランク(プレミスベースの PSTN)展開のローカルゲートウェイとして展開できます。この記事では、設計の考慮事項と構成について説明します。 この図は、Cisco Webex Calling トランク展開のローカルゲートウェイとしての一般的な CUBE HA 設定を示しています。
冗長性グループ インフラストラクチャ コンポーネント
冗長グループ (RG) インフラ コンポーネントは、2 つの CUBE 間でのボックス間通信インフラストラクチャのサポートを提供し、最終的に安定した冗長性の状態をネゴシエートします。 このコンポーネントは次の機能も提供します。
2 つの CUBE 間で keepalive と hello メッセージを交換することで (コントロール インターフェイス)、各ルータの最終的な冗長状態をネゴシエートする HSRP のようなプロトコル。上の図の GigabitEthernet3です。
アクティブからスタンバイ ルータ (データ インターフェイス経由) への各コールに関して、シグナリングとメディアの状態をチェックするための転送メカニズム。上記の図の GigabitEthernet3です。
トラフィック インターフェイスの仮想 IP (VIP) インターフェイスの構成と管理 (複数のトラフィック インターフェイスは同じ RG グループを使用して構成できます)。GigabitEthernet 1 および 2 はトラフィック インターフェイスと見なされます。
この RG コンポーネントは、音声 B2B HA をサポートするように特別に構成する必要があります。
信号とメディアの両方に関する仮想 IP (VIP) アドレス管理
B2B HA は、冗長性を確保する際に VIP に依存します。 CUBE HA ペアの両方の CUBE で VIP および関連する物理インターフェイスは、同じ LAN サブネット上に存在している必要があります。 VIP の構成、および特定の音声アプリケーション (SIP) への VIP インターフェイスのバインドは、音声 B2B HA サポートに必須です。 Unified CM、Webex Calling アクセス SBC、サービス プロバイダー、プロキシなどの外部デバイスは、CUBE HA ルーターを通過するコールの宛先 IP アドレスとして VIP を使用します。 そのため、Webex Calling の観点から、CUBE HA ペアは単一のローカル ゲートウェイとして機能します。
確立されたコールのコール シグナリングおよび RTP セッション情報は、アクティブなルーターからスタンバイ ルーターへのチェックポイントです。 アクティブ ルーターがダウンすると、スタンバイ ルーターが引き継ぎ、最初のルーターによって以前にルーティングされた RTP ストリームを継続して転送します。
フェイルオーバー時に一時的な状態のコールは、切り替え後には保存されません。 たとえば、まだ完全に確立されていない、または転送や保留の機能により変更中のコールなどです。 確立されたコールは、切り替え後に切断される場合があります。
コールのステートフル フェールオーバーのローカル ゲートウェイとして CUBE HA を使用するには、以下の要件があります。
CUBE HA は TDM またはアナログ インターフェイスを共存させることはできません
Gig1 および Gig2 はトラフィック (SIP/RTP) インターフェイス、Gig3 は冗長グループ (RG) コントロール/データ インターフェイスと呼ばれます
グループ id 1 とグループ id 2 を持つ同じレイヤー 2 ドメインに配置できる CUBE HA ペアは 2 つまでです。 同じグループ ID で 2 つの HA ペアを構成する場合、RG コントロール/データ インターフェイスは異なるレイヤー 2 ドメイン (vlan、個別のスイッチ) に属している必要があります
ポート チャネルは、RG コントロール/データとトラフィック インターフェイスの両方でサポートされています
すべてのシグナリング/メディアは、仮想 IP アドレスから供給されます
プラットフォームが CUBE HA 関係にリロードされると、常にスタンバイとして起動します
すべてのインターフェイスの下位アドレス (Gig1、Gig2、Gig3) は、同じプラットフォームにある必要があります
冗長性インターフェイス識別子、rii は同じレイヤー 2 のペア/インターフェイスの組み合わせに対して固有である必要があります
両方の CUBE の構成は、物理構成を含む必要があり、同じ種類のプラットフォームと IOS-XE バージョンで実行されている必要があります
ループバック インターフェイスは、常に起動しているためバインドとして使用できません
複数のトラフィック (SIP/RTP) インターフェイス (Gig1、Gig2) では、インターフェイスのトラッキングが構成されている必要があります
CUBE-HA は、RG コントロール/データ リンク (Gig3) のクロスオーバー ケーブル接続ではサポートされていません
両方のプラットフォームは同一である必要があり、すべての同様のインターフェイスで CUBE HA が機能するように [物理スイッチ] を介して接続します。例: CUBE-1 と CUBE-2 の GE0/0/0 は同じスイッチ上で終了する必要があります
直接 CUBE 上で、またはいずれかの側のデータ HA で WAN を終了することができません
アクティブ/スタンバイは両方とも同じデータセンターにある必要があります
冗長性 (RG コントロール/データ、Gig3) に別の L3 インターフェイスを使用する必要があります。トラフィックに使用されるインターフェイスは、HA keepalives およびチェックポイントに使用できません
フェールオーバー時に、以前アクティブだった CUBE は、設計によって再読み込みされ、シグナリングとメディアを保持します
両方の CUBE で冗長性を構成する
HA ペアで使用し、仮想 IP を表示するために、両方の CUBE でレイヤー 2 ボックス間冗長性を構成する必要があります。
1 | インターフェイスのステータスを追跡するために、グローバル レベルでインターフェイス トラッキングを構成します。
トラッキング CLI は、トラフィック インターフェイスがダウンした後、アクティブ ルートがアクティブな役割を果たすように、RG 内で音声トラフィックインターフェイスの状態を追跡するために使用されます。 | ||||||
2 | アプリケーション冗長性サブモード下の VoIP HA で使用する RG を構成します。
この構成で使用されるフィールドの説明を次に示します。
| ||||||
3 | CUBE アプリケーションのボックス間の冗長性を有効にします。 以下の下にある以前の手順から RG を構成します:
redundancy-group 1—このコマンドを追加および削除するには、更新された構成を有効にするための再読み込みが必要です。 すべての構成が適用された後で、プラットフォームを再読み込みします。 | ||||||
4 | 以下に示すように、Gig1 と Gig2 インターフェイスをそれぞれの仮想 IP で構成し、冗長性インターフェイス識別子 (rii) を適用します。
この構成で使用されるフィールドの説明を次に示します。
| ||||||
5 | 最初の CUBE 構成を保存し、再読み込みします。 最後にリロードするプラットフォームは常にスタンバイです。
VCUBE-1 が完全に起動したら、 VCUBE-2 の構成を保存し、再読み込みします。
| ||||||
6 | ボックス間の構成が期待どおりに機能していることを確認します。 関連する出力は太字で強調表示されます。 VCUBE-2 を最後にリロードし、設計上の考慮事項に従います。最後にリロードするプラットフォームは常に [スタンバイ] 状態です。
|
両方の CUBE でローカル ゲートウェイを構成する
この例の構成では、Control Hub から以下のトランク情報を使用して、VCUBE-1、VCUBE-2 の両方のプラットフォームでローカルゲートウェイを構成しています。 この設定のユーザー名とパスワードは以下のとおりです。
ユーザー名: フセイン1076_LGU
パスワード: lOV12MEaZx
1 | クレデンシャルまたは共有秘密で使用する前に、以下のコマンドを使用して、設定キーがパスワードに対して作成されていることを確認してください。 Type 6 パスワードは、AES 暗号化とこのユーザー定義の設定キーを使用して暗号化されます。
これは、上に表示されている Control Hub のパラメーターに基づき、両方のプラットフォームに適用し、保存し、リロードするローカ ルゲートウェイの構成です。 Control Hub からの SIP ダイジェスト クレデンシャルは太字でハイライトされています。
Show コマンド出力を表示するには、VCUBE-2 の後に VCUBE-1 をリロードし、VCUBE-1 をスタンバイ CUBE にして、VCUBE-2 をアクティブ CUBE にします。 |
2 | 任意の時点で、1 個のプラットフォームのみが、Webex Calling アクセス SBC を使用したローカル ゲートウェイとしてアクティブ登録を保持します。 以下の show コマンドの出力を見てみましょう。 show redundancy application group 1 sip-ua レジスタ ステータスを表示
上記の出力から、 VCUBE-2 がアクティブ LGW で、Webex Calling アクセス SBC への登録を維持していることがわかります。しかし、「show sip-ua register status」の出力は VCUBE-1 では空です |
3 | VCUBE-1 で次のデバッグを有効にします
|
4 | この場合、アクティブ LGW、VCUBE-2 で次のコマンドを実行してフェールオーバーをシミュレートします。
アクティブからスタンバイ LGW への切り替えは、上記に一覧表示されている CLI に加えて、以下のシナリオで発生します。
|
5 | VCUBE-1 が Webex Calling アクセス SBC に登録されているかどうかを確認します。 VCUBE-2 は今すぐにリロードされます。
VCUBE-1 がアクティブ LGW になりました。 |
6 | 仮想 IP を通じて SIP REGISTER を Webex Calling に送信し、200 OK を受信する VCUBE-1 に関連するデバッグ ログを確認してください。
|
ローカル ゲートウェイへトランクするための SIP トランク セキュリティ プロファイルを構成する
ローカル ゲートウェイと PSTN ゲートウェイが同じデバイス上に存在する場合、Unified CM を有効にして、同じデバイスから発信された 2 個の異なるトラフィックの種類 (Webex と PSTN のコール) を区別し、これらのコール タイプに対して差別化されたクラスのサービスを適用する必要があります。 この差別化されたコール処理は、Unified CM および結合されたローカル ゲートウェイと PSTN ゲートウェイ デバイスの 2 つのトランクをプロビジョニングすることで行われます。これは、2 つのトランクに異なる SIP リスニング ポートを必要とします。
次の設定でローカル ゲートウェイ トランクの専用の SIP トランク セキュリティ プロファイルを作成します。
|
ローカル ゲートウェイ トランクの SIP プロファイルを構成する
次の設定でローカル ゲートウェイ トランク用の専用の SIP プロファイルを作成します。
|
Webex からのコールのコール検索スペースを作成する
次の設定で Webex から発信されたコールのためのコール検索スペースを作成します。
|
Webex 間で SIP トランクを構成する
次の設定を使用して、ローカル ゲートウェイ経由での Webex 間のコールに SIP トランクを作成します。
|
Webex のルート グループを構成する
次の設定でルート グループを作成します。
|
Webex のルート リストを構成する
次の設定でルート リストを作成します。
|
Webex の移動先のパーティションを作成する
次の設定で Webex の移動先のパーティションを作成します。
|
次に行うこと
このパーティションは、Webex の宛先にアクセスする必要があるすべてのコール検索スペースに追加してください。 このパーティションは、PSTN から Webex への発信がルーティングされるように、PSTN トランクの着信コール検索スペースとして使用されるコール検索スペースに特に追加する必要があります。
Webex の移動先のルート パターンを構成する
次の設定で Webex の各 DID 範囲のルート パターンを構成します。
|
Webex の簡略サイト間ダイヤル正規化を構成する
短縮されたサイト間ダイヤルが Webex に必要な場合は、Webex の各 ESB 範囲にダイヤル正規化パターンを設定します。
|
ハント グループをセットアップする
ハント グループは着信をグループのユーザーまたはワークスペースにルーティングします。 グループ全体にルーティングするパターンを構成することもできます。
ハント グループのセットアップ方法の詳細については、「Cisco Webex Control Hub のハント グループ」を参照してください。
通話キューを作成する
コール キューを作成すれば、顧客の発信にすぐに応答がない場合、誰かが応答できるようになるまで自動応答にしたり、お詫びのメッセージや保留中の音楽が流れるようにしたりすることができます。
コール キューをセットアップおよび管理する方法の詳細については、「Cisco Webex Control Hub でコール キューを管理する」を参照してください。
レセプショニスト クライアントを作成する
お客様のフロントオフィスの担当者のニーズに対応します。 ユーザーを電話のアテンダントとして設定すると、組織内の特定のユーザーに着信するコールをスクリーンできます。
レセプショニストクライアントのセットアップ方法と表示方法については、「Cisco Webex Control Hub のレセプショニストクライアント」を参照してください。
自動アテンダントを作成して管理する
セットアップ メニューと、応答サービス、ハント グループ、ボイスメール ボックスや実際のオペレーターなどへのルーティング機能によって、適切なあいさつを返すことができます。 24 時間分のスケジュールを作成できます。あるいは、時間内か外かに応じて、異なるオプションを使うこともできます。
自動アテンダントの作成と管理の方法については、「Cisco Webex Control Hub で自動アテンダントを管理する」を参照してください。
ページング グループを構成する
グループ ページングは、特定のページング グループに割り当てられた番号または内線番号をダイヤルすることにより、最大 75 名のターゲット ユーザーに一方向通話を行うか、グループ ページングを行うことができるようにします。
ページング グループのセットアップ方法と編集方法の詳細については、「Cisco Webex Control Hub のページング グループを構成する」を参照してください。
コール ピックアップを設定する
コール ピックアップ グループを作成し、グループのユーザーがお互いの通話に応答できるようにすることによって、社内でのチームワークと協力体制を強化します。 ユーザーをコールピックアップグループに追加しておけば、グループメンバーが席を離れていたり、電話中だったりした場合、別のメンバーが電話に出ることができます。
コールピックアップグループのセットアップ方法については 、「Cisco Webex Control Hub でのコールピックアップ」を参照してください。
コール パークをセットアップする
コール パークにより、ユーザーの定義されたグループは、コール パーク グループの他の利用可能なメンバーに対するコールをパークすることができます。 パーク中のコールは、グループの他のメンバーが自分の電話で取ることができます。
コールパークのセットアップ方法の詳細については、「Cisco Webex Control Hub コールパーク」を参照してください。
ユーザーの割り込みを有効にする
1 | の顧客ビューから、[管理] > [ユーザー] の順に移動します。https://admin.webex.com |
2 | ユーザーを選択し、[Calling] をクリックします。 |
3 | [ユーザー権限間]セクションに移動し、[割り込み]を選択します。 |
4 | トグルをオンにすると、他のユーザがこのユーザの進行中のコールに自分自身を追加できるようになります。 |
5 | このユーザーがコールに割り込むときに他のユーザーにトーンを再生する場合は、[このユーザーがコールで割り込むときにトーンを再生] にチェックを入れます。 |
6 | [保存] をクリックします。 |
ユーザーのプライバシーを有効にする
1 | Control Hubにサインインし、 。 | ||
2 | ユーザーを選択し、[Calling] をクリックします。 | ||
3 | [ユーザー権限間]領域に移動し、[プライバシー]を選択します。 | ||
4 | このユーザーに適切な [自動音声応答のプライバシー] 設定を選択します。
| ||
5 | [プライバシーを有効にする] チェックボックスをオンにします。 ドロップダウンリストからメンバーを選択しないことで、全員をブロックすることができます。 または、このユーザーの回線ステータスを監視できるユーザー、ワークスペース、仮想回線を選択することもできます。 ロケーション管理者の場合、割り当てられたロケーションに関連するユーザー、ワークスペース、仮想回線だけがドロップダウン リストに表示されます。 [プライバシーを有効にする] チェックボックスをオフにすると、全員が回線のステータスを監視できるようになります。 | ||
6 | ダイレクト コール ピックアップと割り込みのプライバシーを有効にするには、[ダイレクト コール ピックアップと割り込みのプライバシーを強制] チェックボックスをオンにします。
| ||
7 | [名前でメンバーを追加] から、電話回線のステータスを監視し、ダイレクト コール ピックアップと割り込みを呼び出せるユーザ、ワークスペース、仮想回線を選択します。 | ||
8 | 選択したメンバーをフィルタリングするには、[名前、番号、またはextでフィルタリング]フィールドを使用します。 | ||
9 | 選択したすべてのメンバーを削除するには、[すべて削除]をクリックします。
| ||
10 | [保存] をクリックします。 |
モニタリングの設定
ユーザーの監視対象回線の最大数は 50 です。 ただし、モニタリング リストを設定する際には、Webex Calling とネットワーク間の帯域幅に影響を与えるメッセージの数を考慮してください。 また、ユーザの電話機の回線ボタンの数によって、最大監視回線を決定します。
1 | https://admin.webex.comの顧客ビューから、[管理]に移動し、[ユーザー]をクリックします。 | ||||
2 | 変更するユーザーを選択し、[Calling] をクリックします。 | ||||
3 | [ユーザー権限間] セクションに移動し、[モニタリング] を選択します。 | ||||
4 | 次から選択します:
ユーザーモニタリングのために、[モニタリング対象の回線を追加(Add Monitored Line)] リストに仮想回線 を含めることができます。 | ||||
5 | このユーザーにパークされたコールを通知するかどうかを選択し、監視対象のユーザーまたはコール パーク内線を検索し、[保存] をクリックします。
|
ユーザーのコール ブリッジ警告トーンを有効にする
始める前に
1 | Control Hubにサインインし、 。 | ||
2 | ユーザーを選択し、[通話] タブをクリックします。 | ||
3 | [ユーザー権限間] に移動し、[コールブリッジ警告トーン] をクリックします。 | ||
4 | オンにするコール ブリッジの警告トーンを選択し、 [保存を選択します。
MPP 共有回線のコール ブリッジングの詳細については、「マルチプラットフォーム デスク フォンの共有回線」を参照してください。 Webex アプリの共有回線でのコール ブリッジングの詳細については、「WebexApp の共有回線アピアランス」を参照してください。 |
ユーザーのためにホテリングをオンにする
1 | 顧客ビューからhttps://admin.webex.com、管理を選択して、ユーザーを選択します。 | ||
2 | ユーザーを選択し、[通話] タブをクリックします。 | ||
3 | [ユーザー間の権限]セクションに移動し、[ホテリング]を選択してトグルをオンにします。 | ||
4 | [ホテリングロケーション] 検索フィールドにホテリングホストの名前または番号を入力し、ユーザーに割り当てるホテリングホストを選択します。 選択できるホテリング主催者は 1 つのみです。 別のホテリング主催者を選択した場合、最初のホテリング ホストは削除されます。
| ||
5 | ユーザーがホテリングホストに関連付けることができる時間を制限するには、[関連付け期間を制限(Limit Association Period)] ドロップダウンからユーザーがホテリングホストを使用できる時間を選択します。 指定した時間が経過すると、ユーザーは自動的にログアウトします。
| ||
6 | [保存] をクリックします。
|
通話レポートを表示する
Control Hub の [アナリティクス] ページを使用して、ユーザーがどのように Webex Calling と Webex アプリ (エンゲージメント) を使用しているか、また、通話のメディア エクスペリエンスの質について洞察を得ることができます。 Webex Calling のアナリティクスにアクセスするには、Control Hub にサインインし、[アナリティクス] に移動して、[Calling] タブを選択します。
1 | 通話履歴の詳細レポートを参照するには、コントロールハブを表示し、次に移動します。分析次のリンクをクリックしてください:電話を選択します。 |
2 | 選択詳細な通話履歴を選択します。 専用インスタンスを使用する通話の詳細については、「専用インスタンスの分析」を参照してください。 |
3 | メディア品質データにアクセスするには、Control Hub にサインインし、[アナリティクス] に移動して、[Calling] を選択します。 詳細については、「クラウド コラボレーション ポートフォリオのためのアナリティクス」を参照してください。
|
CScan ツールを実行する
CScan は、Webex Calling へのネットワーク接続をテストするために設計されたネットワーク準備ツールです。
詳細については、「CScan を使用して Webex Calling ネットワークの品質をテストする」をご覧ください。 |
一般的な前提条件
Webex Callingのローカル ゲートウェイを設定する前に、次のことを確認してください。
VoIP の原理についての基本的な知識があること
Cisco IOS-XE と IOS-XE 音声のコンセプトについて、基本的で実際的な知識があること
セッション開始プロトコル (SIP) の基本的な理解がある
導入モデルに Cisco Unified Communications Manager (Unified CM) が含まれている場合には、Unified CM についての基本的な理解があること
詳細については、『Cisco Unified Border Element (CUBE) Enterprise Configuration Guide』を参照してください。
ローカル ゲートウェイのハードウェアおよびソフトウェア的要件
展開に次のような 1 つ以上のローカル ゲートウェイがあることを確認します。
IP ベースの接続用 Cisco CUBE
TDM ベースの接続のための Cisco IOS ゲートウェイ
ローカル ゲートウェイは、自分のペースで Webex Calling に移行するのに役立ちます。 ローカル ゲートウェイは、既存のオンプレミス展開を Webex Calling と統合します。 既存の PSTN 接続を使用することもできます。 「ローカル ゲートウェイの使い方」を参照してください
ローカル ゲートウェイのライセンスに関する要件
CUBE コールライセンスは、ローカル ゲートウェイにインストールされている必要があります。 詳細については、Cisco Unified 境界要素の構成ガイドを参照してください。
ローカル ゲートウェイの認証およびセキュリティ的要件
Webex Calling は、安全な信号経路とメディアを必要とします。 ローカルゲートウェイは暗号化を行います。また、以下の手順に従って、TLS 接続をクラウド方向に確立する必要があります。
LGW は、Cisco PKI からの CA ルートバンドルで更新しておく必要があります
LGW を構成する際には、Control Hub のトランク構成ページから取得した一連の SIP ダイジェスト資格情報が使用されます(この手順は、この後の構成の一部です)
CA ルート バンドルは、提示された証明書を検証します
資格情報が要求されます (SIP ダイジェストにより提供されたもの)
クラウドは、どのローカル ゲートウェイがセキュアに登録されているかを識別します
ローカルゲートウェイのファイアウォール、NAT Traversal、メディアパス最適化の各要件
ほとんどの場合、ローカル ゲートウェイとエンドポイントは、NAT によるプライベート IP アドレスを使用して、内部の顧客ネットワークに配置することができます。 エンタープライズ ファイアウォールは、特定の IP アドレス/ポートに対する外向きトラフィック (SIP、RTP/UDP、HTTP) を許可していなければなりません。この点は、「ポート参照情報」で説明されています。
ICE でメディアパスの最適化を利用する場合、ローカルゲートウェイの Webex Calling に面しているインターフェイスには Webex Calling エンドポイントとの双方向の直接ネットワークパスが必要です。 エンドポイントが別のロケーションにあり、ローカルゲートウェイの Webex Calling に面しているインターフェイスとこのエンドポイントとの間に直接ネットワークパスがない場合、メディアパスの最適化を利用するには、ローカルゲートウェイとエンドポイント間の通話のために、Webex Calling に面しているインターフェイスに割り当てられたパブリック IP アドレスをローカルゲートウェイに設定する必要があります。 また、IOS-XE バージョン 16.12.5 を実行している必要があります。
Webex Calling サービスを稼働させるための最初のステップは、初回セットアップ ウィザード (FTSW) を完了することです。 最初のロケーションの FTSW が完了した後では、追加のロケーションに対して完了する必要がありません。
1 | 受け取ったウェルカム メールのはじめにリンクをクリックします。
| ||
2 | 利用規約を見直して、承諾します。 | ||
3 | プランを見直して、[はじめに] をクリックします。
| ||
4 | データ センターがマッピングする国を選択し、顧客の連絡先と顧客アドレス情報を入力します。 | ||
5 | [次へ: デフォルトのロケーション | ||
6 | 次のオプションから選択します:
| ||
7 | このロケーションに適用する次の選択を行います。
| ||
8 | [次へ] をクリックします。 | ||
9 | 利用可能な Cisco Webex SIP アドレスを入力し、[次へ] をクリックし、[完了] を選択します。 |
始める前に
新しいロケーションを作成するには、以下の情報を指定します。
ロケーションの住所
希望する電話番号(オプション)
1 | 以下で Control Hub にログインします:https://admin.webex.com 、 を選択します。
| ||||
2 | ロケーションを設定します。
| ||||
3 | クリック保存を選択してはい/いいえをクリックし、今すぐまたは後でロケーションに番号を追加します。 | ||||
4 | [今すぐ追加] をクリックしたら、次のいずれかのオプションを選択してください。
PSTN オプションの選択は各ロケーション レベルで行います (各ロケーションには PSTN オプションが 1 つしかありません)。 展開に対して必要な数のオプションを組み合わせることができますが、各ロケーションには 1 つのオプションとなります。 PSTN オプションを選択してプロビジョニングしたら、ロケーションの PSTN プロパティで [管理] をクリックすると、オプションを変更できます。 ただし、Cisco PSTN などの一部のオプションは、別のオプションが割り当てられた後は使用できない場合があります。 サポート ケースを開いてご相談ください。 | ||||
5 | 番号を今すぐに有効にするか、または後で有効にするかを選択します。 | ||||
6 | 統合されていない CCP またはプレミス ベースの PSTN を選択した場合は、電話番号をコンマ区切り値として入力し、[検証] をクリックします。 特定のロケーションのための番号が追加されます。 有効なエントリは [検証済みの番号] フィールドに移動し、無効なエントリは [番号の追加] フィールドに残り、エラー メッセージが表示されます。 番号の書式は、ロケーションの所在する国に応じ、ダイヤリングに関する地元の要件に従って定められます。 たとえば、国コードが必要な場合には、コードを付けて入力することも、コードなしで入力してからコードが自動的に先頭に追加されるようにすることもできます。 | ||||
7 | [保存] をクリックします。 |
次に行うこと
ロケーションを作成した後、そのロケーションの緊急 911 サービスを有効にすることができます。 詳細については「Webex Calling の RedSky 緊急 911 サービス」を参照してください。
始める前に
ロケーションに関連付けられているユーザーとワークスペースのリストを取得します。 [サービス] >[番号] に移動し、ドロップダウン メニューから削除するロケーションを選択します。これらのユーザーとワークスペースを削除する必要があります。 ロケーションを削除する前に、このロケーションに関連付けられているすべての番号は、PSTN プロバイダーに戻されることに注意してください。つまり、これらの番号は所有しなくなります。 |
1 | 以下で Control Hub にログインします:https://admin.webex.com 、 を選択します。 |
2 | クリック |
3 | 選ぶロケーションを削除を選択し、ロケーションを削除することを確認します。 ロケーションが完全に削除されるまで通常数分かかりますが、最大で 1 時間かかる場合があります。 ロケーション名の横にある [詳細] をクリックし、[削除ステータス] を選択して、ステータスを確認できます。 |
PSTN の設定を変更するだけではなく、作成された後に名前、タイムゾーン、言語を指定することも可能です。 新しい言語は新しいユーザーとデバイスにのみ適用されることに注意してください。 既存のユーザーおよびデバイスは古い言語を使用し続けます。
既存のロケーションについては、緊急時の 911 サービスを有効にすることができます。 詳細については「Webex Calling の RedSky 緊急 911 サービス」を参照してください。 |
1 | 以下で Control Hub にログインします:https://admin.webex.com 、 を選択します。 場所の隣に警告アイコンが表示されている場合は、その場所の電話番号がまだ設定されていないことを意味します。 その番号を設定するまでは、コールを受発信できません。 | ||||||
2 | (オプション) [PSTN 接続] の下で、すでに設定されているものに応じて、[クラウド接続 PSTN] または [プレミスベースの PSTN](ローカル ゲートウェイ) のいずれかを選択します。 [管理] をクリックして設定を変更してから、[続行] を選択することにより、関連するリスクを承認します。 以下のオプションのいずれかを選択して、[保存] クリックします。
| ||||||
3 | ロケーションの主な連絡先担当者に連絡する際の代表番号を入力します。 | ||||||
4 | (オプション) [緊急コール] で[緊急時のロケーション識別子] を選択して、このロケーションに割り当てることができます。
| ||||||
5 | このロケーションでユーザーがボイスメールをチェックするために呼び出せる [ボイスメール番号] を選択します。 | ||||||
6 | (オプション) ロケーション ページの上部にある鉛筆アイコンをクリックし、必要に応じて [ロケーションの名前]、[アナウンス言語]、[メール言語]、[タイムゾーン]、[住所] を変更し、[保存] をクリックします。
|
これらの設定は社内ダイヤルに適用されるものであり、最初のセットアップ ウィザードでも設定できます。 ダイヤル プランを変更すると、Control Hub の更新のサンプル番号が表示され、これらの変更が表示されます。
ロケーションに対する発信通話の権限を設定できます。 これらのステップをご覧になり、発信権限を設定してください。 |
1 | Control Hub にサインインし、 を選択してから、[内部ダイヤル]までスクロールします。 | ||||||||
2 | 必要に応じて、次のオプションのダイヤル設定を行います。
| ||||||||
3 | 特定の場所の内部ダイヤルを指定します。 通話]をクリックします。 [ダイヤル] までスクロールし、必要に応じて内部ダイヤルを変更します。 ]を選択し、リストからロケーションを選択して、[
| ||||||||
4 | 特定のロケーションの外部ダイヤルを指定します。 通話]をクリックします。 [ダイヤル] までスクロールし、必要に応じて外部ダイヤルを変更します。 ]を選択し、リストからロケーションを選択して、[
ユーザーへの影響:
|
付加価値再販業者の場合、これらの手順を使用して Control Hub でローカル ゲートウェイの設定を開始できます。 このゲートウェイがクラウドに登録されると、Webex Calling の 1 つ以上のロケーションで使用して、エンタープライズ PSTN サービス プロバイダーへのルーティングを提供できます。
ローカル ゲートウェイがある場所は、ローカル ゲートウェイが他の場所で使用されているときには削除できません。 |
始める前に
ロケーションが追加されたら、ロケーションに対してプレミスベース PSTN を設定する前に、トランクを作成する必要があります。
それぞれについて、ロケーションと固有の設定および番号を作成します。 ロケーションはプレミスベース PSTN を追加する前に存在する必要があります。
Webex Calling でのプレミスベース PSTN (ローカル ゲートウェイ) 要件について理解しておいてください。
プレミスベース PSTN を持つロケーションに対して、複数のトランクを選択できませんが、複数のロケーションに対して同じトランクを選択することはできます。
1 | ログインするコントロールハブで、サービス次のリンクをクリックしてください:電話次のリンクをクリックしてください:コール ルーティングを選択し、トランクの追加を選択します。https://admin.webex.com | ||
2 | ロケーションを選択します。 | ||
3 | トランクの名前を指定し、[保存] をクリックします。
|
次に行うこと
画面 [ドメインの登録]、[トランク グループ OTG/DTG]、[回線/ポート]、および [発信プロキシ アドレス] にトランク情報が表示されます。
プレミス ベースの PSTN を設定する準備ができたときに参照できるように、この情報を Control Hub からコピーして、ローカルのテキスト ファイルまたはドキュメントに貼り付けておくことをおすすめします。
資格情報を紛失した場合には、Control Hub のトランク情報画面で生成する必要があります。 [ユーザー名の取得とパスワードのリセット] をクリックして、トランクを使用するための認証資格情報の新しいセットを生成します。
1 | 以下で Control Hub にログインします:https://admin.webex.com 、 を選択します。 | ||
2 | 変更する場所を選択し、[管理] をクリックします。 | ||
3 | プレミスベース PSTN を選択して、[次へ] をクリックします。 | ||
4 | ドロップダウン メニューからトランクを選択します。
| ||
5 | 確認通知をクリックし、[保存] をクリックします。 |
次に行うこと
Control Hub で生成された設定情報を記録し、パラメーターをローカル ゲートウェイ (たとえばオンプレミスの Cisco CUBE) にマップする必要があります。 この記事では、このプロセスについて順を追って説明します。 参考のため、次の図を参照して、どのように Control Hub の設定情報 (左側) が CUBE のパラメーター (右側) にマップされるかを確認してください。
ゲートウェイ自体の設定が正常に完了し、Control Hub の [サービス] > [通話] > [ロケーション] に戻ると、作成したゲートウェイが、名前の左側に緑色のドットが付けられてロケーション カードにリストされます。
このステータスは、ゲートウェイがセキュアに通話クラウドに対して登録され、そのロケーションでのアクティブな PSTN としての役割を果たしていることを示しています。Control Hub では、組織の電話番号を簡単に表示、アクティベート、削除、追加できます。 詳細については、「Control Hub で電話番号を管理する」を参照してください。
Webex サービスを試していて、トライアルから有料サブスクリプションに変更したい場合は、メールでパートナーにリクエストできます。
1 | https://admin.webex.comでControl Hubにログインし、建物のアイコンを選択します。 |
2 | [サブスクリプション] タブを選択し、[今すぐ購入] をクリックします。 有料サブスクリプションへの変換に興味を持っていることを知らせるメールがパートナーに送信されます。 |
Control Hub を使用して、Webex アプリでユーザーに表示する利用可能な通話オプションの優先度を設定できます。 シングルクリック通話を有効にすることもできます。 詳細については、「 Webexアプリ ユーザーの通話オプションを設定するを選択します。
ユーザーが発信する際に開く通話アプリケーションを制御することができます。 通話クライアントの設定を構成できます。これにはUnified CMまたはWebex CallingおよびCiscoの有料通話サービスを利用していないユーザー。 詳細については、「 通話動作をセットアップします。
概要
Webex Calling は現在、ローカル ゲートウェイの 2 つのバージョンをサポートしています。
ローカル ゲートウェイ
政府版 Webex のローカル ゲートウェイ
開始する前に、Webex Calling のプレミスベースの公衆交換電話ネットワーク (PSTN) およびローカル ゲートウェイ (LGW) の要件を理解してください。 参照先Webex Callingに対するCiscoの推奨アーキテクチャをご覧ください。
この記事では、既存の音声構成がない専用のローカル ゲートウェイプラットフォームが設置されていることを前提としています。 既存の PSTN ゲートウェイまたは CUBE Enterprise 展開を Webex Calling のローカル ゲートウェイ機能として使用するように変更する場合は、設定に注意してください。 変更を行うため、既存のコール フローと機能を中断しないようにしてください。
この手順には、個々のコマンド オプションの詳細が記載されているコマンド リファレンス ドキュメントへのリンクが含まれています。 すべてのコマンド リファレンス リンクは、 Webexマネージド ゲートウェイ コマンド リファレンス特に断らない限り (その場合、コマンドリンクはCisco IOS音声コマンド リファレンス) を選択してください。 これらのガイドはすべて、Cisco Unified Border Element コマンド リファレンスからアクセスできます。 サポートされているサードパーティ SBC の詳細については、各製品参照ドキュメントを参照してください。 |
ローカル ゲートウェイを構成するためのオプションが 2 つあります。 Webex Callingトランク:
登録ベースのトランク
証明書ベースのトランク
下のいずれかでタスクフローを使用し、登録ベースのローカル ゲートウェイまたは証明書ベースのローカル ゲートウェイローカル ゲートウェイの設定Webex Calling trunk。
さまざまなトランクタイプの詳細については、「ローカル ゲートウェイの使い方」を参照してください。 コマンドライン インターフェイス(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 証明書ベースのトランクの設定」を参照してください。
政府版 Webex は登録ベースのローカル ゲートウェイをサポートしていません。 |
このセクションでは、登録 SIP トランクを使用して、Webex Calling のローカル ゲートウェイとして Cisco Unified Border Element(CUBE)を設定する方法について説明します。 このドキュメントの最初の部分は、シンプルな PSTN ゲートウェイを設定する方法を示しています。 この場合、PSTN からのすべてのコールは Webex Calling にルーティングされ、Webex Calling からのすべてのコールは PSTN にルーティングされます。 下の画像では、このソリューションとそれに続く高レベルのコール ルーティング設定が強調されています。
この設計では、次の主な構成が使用されます。
音声クラスのテナント: トランク固有の設定を作成するために使用されます。
音声クラス uri: 着信ダイヤルピアの選択のための SIP メッセージを分類するために使用。
着信ダイヤルピア: 着信 SIP メッセージの処理を提供し、ダイヤルピア グループで発信ルートを決定します。
ダイヤルピア グループ: オンワード コール ルーティングに使用する発信ダイヤル ピアを定義します。
発信ダイヤルピア: アウトバウンド SIP メッセージの処理を提供し、必要なターゲットにルーティングします。
オンプレミスの 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 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 トラストポイントを作成します。
| ||
4 | TLS1.2 排他を有効にし、次の設定コマンドを使用してデフォルトのトラストポイントを指定します。 登録のための信頼性の高い安全な接続を確保するために、トランスポートパラメータも更新する必要があります。
| ||
5 | Webex Calling で使用される DigiCert CA 証明書を含む Cisco ルート CA バンドルをインストールします。 を使用する crypto pki trustpool インポート クリーン URLコマンドは、指定されたURLからルートCAバンドルをダウンロードし、現在のCAトラストプールをクリアしてから、証明書の新しいバンドルをインストールします。
|
1 | Control Hub の既存のロケーションに登録ベースの PSTN トランクを作成します。 トランクが作成されると、提供されたトランク情報をメモします。 次の図で強調表示されているこれらの詳細は、このガイドの設定手順で使用されます。 詳細については、次のサイトを参照してください。 Webex Calling用にトランク、ルートグループ、ダイヤルプランを構成するを選択します。 | ||||
2 | 次のコマンドを入力して、CUBE を Webex Calling ローカル ゲートウェイとして設定します。
構成のフィールドの説明はここにあります。
プラットフォームで Cisco Unified Border Element(CUBE)機能を有効にします。 メディア統計ローカル ゲートウェイでメディア監視を有効にします。 メディア一括統計一括コール統計のためにコントロール プレーンがデータ プレーンを投票できるようにします。 これらのコマンドの詳細については、「メディア」を参照してください。 allow-connections sip to sipCUBE 基本 SIP バックツーバック ユーザ エージェント機能を有効にします。 詳細については、次のサイトを参照してください。接続を許可を選択します。
STUN (NAT を介した UDP のセッショントラバーサル) をグローバルに有効にします。
詳細については、次のサイトを参照してください。スタンフローデータエージェント-idおよびスタンフローデータ共有シークレットを選択します。 非対称ペイロード フルDTMF と動的コーデック ペイロードの両方に対して SIP 非対称ペイロード サポートを設定します。 このコマンドの詳細については、次を参照してください非対称ペイロードを選択します。 early-offer forcedローカル ゲートウェイは、隣接するピアからの確認を待つ代わりに、最初の INVITE メッセージで SDP 情報を送信するように強制します。 このコマンドの詳細については、次を参照してください早期オファーを選択します。 | ||||
3 | を設定する 音声クラス コーデック 100 トランクのフィルタ。 この例では、すべてのトランクに同じコーデックフィルタが使用されます。 正確な制御のために各トランクにフィルタを設定できます。
構成のフィールドの説明はここにあります。 音声クラス コーデック 100SIP トランクを介したコールの優先コーデックのみを許可するために使用されます。 詳細については、音声クラスコーデック を参照してください。
| ||||
4 | を設定する 音声クラスの使い方 100 は、Webex Calling トランクで ICE を有効にします。
構成のフィールドの説明はここにあります。 stunusageiceliteについてすべての Webex Calling のダイヤルピアに対して ICE-Lite を有効にして、可能な限り、メディア最適化を可能にするために使用。 詳細については、次のサイトを参照してください。音声クラススタンの使用およびスタン使用アイスライトを選択します。
| ||||
5 | Webex トラフィックのメディア暗号化ポリシーを設定します。
構成のフィールドの説明はここにあります。 音声クラス srtp-crypto 100SDP の SRTP 暗号スイート CUBE オファーおよび応答メッセージの唯一の SRTP オファーとして SHA1_80 を指定します。 Webex Calling は SHA180 のみをサポートします。_ 詳細については、次のサイトを参照してください。音声クラス SRTP 暗号化を選択します。 | ||||
6 | 宛先トランク パラメータに基づいて、ローカル ゲートウェイ トランクへのコールを一意に識別するパターンを設定します。
構成のフィールドの説明はここにあります。 音声クラス uri 100 sip着信トランク ダイヤル ピアへの着信 SIP 招待と一致するパターンを定義します。 このパターンを入力する場合、トランクが作成されたときに、dtg= の後に Control Hub で提供されるトランク OTG/DTG 値を使用します。 詳細については、音声クラス uri を参照してください。 | ||||
7 | を設定する sip プロファイル 100は、Webex Callingに送信される前にSIPメッセージを変更するために使用されます。
構成のフィールドの説明はここにあります。
| ||||
8 | Webex Calling トランクの設定: |
テナント を定義した後 100 および SIP VoIP ダイヤル ピアを設定すると、ゲートウェイは Webex Calling への TLS 接続を開始します。 この時点で、アクセス SBC はその証明書をローカル ゲートウェイに提示します。 ローカル ゲートウェイは、以前に更新された CA ルート バンドルを使用して、Webex Calling アクセス SBC 証明書を検証します。 証明書が認識されると、ローカル ゲートウェイと Webex Calling アクセス SBC の間で永続的な TLS セッションが確立されます。 ローカル ゲートウェイは、このセキュアな接続を使用して Webex アクセス SBC に登録できます。 登録が認証にチャレンジされた場合:
レスポンスには、クレデンシャル設定のusername、password、およびrealmパラメータが使用されます。
sip プロファイル 100 の変更ルールは、SIPS URL を SIP に変換するために使用されます。
アクセスSBCから200 OKを受信すると、登録が成功します。
上記の Webex Calling に対してトランクを構築した後、次の設定を使用して、SIP ベースの PSTN プロバイダーに対して暗号化されていないトランクを作成します。
サービス プロバイダーがセキュアな PSTN トランクを提供している場合、上記の Webex Calling トランクと同様の構成に従うことができます。 セキュアからセキュアなコール ルーティングは CUBE でサポートされています。 |
Cisco TDM-SIP ゲートウェイで PSTN コール レッグの TDM インターフェイスを設定するには、「ISDN PRI の設定」を参照してください。 |
1 | PSTN トランクからの着信コールを識別するには、次の音声クラス uri を設定します。
構成のフィールドの説明はここにあります。 音声クラス uri 200 sip着信トランク ダイヤル ピアへの着信 SIP 招待と一致するパターンを定義します。 このパターンを入力するときは、IP PSTN ゲートウェイの IP アドレスを使用します。 詳細については、音声クラス uri を参照してください。 |
2 | 次の IP PSTN ダイヤル ピアを設定します。
構成のフィールドの説明はここにあります。
次のタグでVoIPダイヤルピアを定義します300管理とトラブルシューティングを容易にするために意味のある説明を付けます。 詳細については、次のサイトを参照してください。ダイヤルピア音声。 destination-pattern BAD.BAD着信ダイヤル ピア グループを使用して発信コールをルーティングする場合は、ダミー接続先パターンが必要です。 詳細については、次のサイトを参照してください。 Destination-pattern(インターフェイス)を選択します。 session protocol sipv2ダイヤルピア 200 が SIP コール レッグを処理するように指定します。 詳細については、次のサイトを参照してください。 session Protocol (ダイヤル ピア)を選択します。 session target ipv4:192.168.80.13コール レッグを送信する宛先のターゲットIPv4アドレスを示します。 ここでのセッション ターゲットは ITSP のIPアドレスです。 詳細については、セッションターゲット (VoIP ダイヤルピア)を参照してください。 200 経由で 着信 uriVIA ヘッダーとIP PSTN のIPアドレスの一致基準を定義します。 ローカル ゲートウェイのすべての着信 IP PSTN コール レッグとダイヤル ピア 200 を一致させます。 詳細については、着信 URLを参照してください。 バインド制御ソースインタフェース GigabitEthernet0/0/0PSTN に送信されるメッセージのソース インターフェイスと関連する 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 プラットフォームを使用してローカル ゲートウェイを設定する場合は、次のセクションに進みます。 |
前のセクションの 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 ルーティングを指定します。
構成のフィールドの説明はここにあります。 次のコマンドは、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 コマンド出力の収集が含まれます。
統合ログファイルを生成する
HTTPS、SCP、FTP サーバなどのユーザー提供のネットワークロケーションにファイルをアップロードします。
TAC エンジニアは DS ファイルを作成し、整合性保護のためデジタル署名します。 各 DS ファイルには、システムによって割り当てられた固有の数値 ID があります。 Diagnostic Signatures Lookup ツール(DSLT)は、さまざまな問題の監視とトラブルシューティングに適切な署名を見つけるための単一の情報源です。
開始する前に:
ダウンロードした DS ファイルは編集しないでください。 DSLTを選択します。 変更したファイルは、整合性チェックエラーのためインストールに失敗します。
ローカル ゲートウェイがメール通知を送信するために必要な Simple Mail Transfer Protocol (SMTP) サーバー。
メール通知にセキュアなSMTPサーバーを使用する場合は、ローカルゲートウェイで IOS XE 17.6.1 以上が実行されていることを確認してください。
前提条件
IOS XE 17.6.1a 以降を実行しているローカル ゲートウェイ
診断署名はデフォルトで有効になっています。
デバイスが Cisco IOS XE 17.6.1a 以降を実行している場合、プロアクティブな通知を送信するために使用する、セキュアな電子メールサーバを設定します。
configure terminal call-home mail-server <username>:<pwd>@<email server> priority 1 secure tls end
環境変数を構成しますds_emailを通知する管理者のメールアドレスを入力します。
configure terminal call-home diagnostic-signature environment ds_email <email address> end
以下は、Cisco IOS XE 17.6.1a 以降で実行されているローカル ゲートウェイの設定例で、プロアクティブな通知をtacfaststart@gmail.com 安全なSMTPサーバーとしてGmailを使用:
Cisco IOS XE Bengaluru 17.6.x 以降のバージョンを使用することをお勧めします。 |
call-home
mail-server tacfaststart:password@smtp.gmail.com priority 1 secure tls
diagnostic-signature
environment ds_email "tacfaststart@gmail.com"
Cisco IOS XE ソフトウェアで実行されるローカルゲートウェイは OAuth をサポートする一般的な Web ベースの Gmail クライアントではないため、専用の Gmail アカウント設定を構成し、デバイスからのメールを適切に処理するための専用権限を指定する必要があります。 |
安全性の低いアプリアクセス]設定をオンにします。
を選択し、[「Google 以外のアプリを使って第三者があなたのアカウントにサインインすることができなくなりました」というメールが Gmail から送られてきたら、「はい、それは私です」と回答します。
プロアクティブ モニタリングのための診断署名をインストールする
高いCPU使用率の監視
この DS は、SNMP OID 1.3.6.1.4.1.9.2.1.56 を使用して、CPU 使用率を 5 秒間追跡します。 使用率が 75% 以上に達すると、すべてのデバッグが無効になり、ローカルゲートウェイにインストールされている診断署名がすべてアンインストールされます。 下記の手順を実行して署名をインストールします。
を使用する SNMPを表示 コマンドで SNMP を有効にします。 有効にしない場合は、snmpサーバーマネージャ コマンド
show snmp %SNMP agent not enabled config t snmp-server manager end show snmp Chassis: ABCDEFGHIGK 149655 SNMP packets input 0 Bad SNMP version errors 1 Unknown community name 0 Illegal operation for community name supplied 0 Encoding errors 37763 Number of requested variables 2 Number of altered variables 34560 Get-request PDUs 138 Get-next PDUs 2 Set-request PDUs 0 Input queue packet drops (Maximum queue size 1000) 158277 SNMP packets output 0 Too big errors (Maximum packet size 1500) 20 No such name errors 0 Bad values errors 0 General errors 7998 Response PDUs 10280 Trap PDUs Packets currently in SNMP process input queue: 0 SNMP global trap: enabled
Diagnostic Signatures Lookup Tool の以下のドロップダウンオプションを使用して、DS 64224 をダウンロードします。
フィールド名
フィールド値
プラットフォーム
Cisco 4300、4400 ISR シリーズ、または Cisco CSR 1000V シリーズ
製品
Webex Calling ソリューションの CUBE Enterprise
問題の範囲
パフォーマンス
問題の種類
メール通知での高CPU使用率。
DS XML ファイルをローカルゲートウェイフラッシュにコピーします。
LocalGateway# copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash:
次の例は、 FTPサーバーからローカルゲートウェイにファイルをコピーする方法を示しています。
copy ftp://user:pwd@192.0.2.12/DS_64224.xml bootflash: Accessing ftp://*:*@ 192.0.2.12/DS_64224.xml...! [OK - 3571/4096 bytes] 3571 bytes copied in 0.064 secs (55797 bytes/sec)
ローカルゲートウェイに DS XML ファイルをインストールします。
call-home diagnostic-signature load DS_64224.xml Load file DS_64224.xml success
イベント、登録者、出席者にすばやくアクセスするため、 call-home 診断署名の表示を実行して、署名が正常にインストールされたことを確認します。 ステータス列の値が「registered」になっているはずです。
show call-home diagnostic-signature Current diagnostic-signature settings: Diagnostic-signature: enabled Profile: CiscoTAC-1 (status: ACTIVE) Downloading URL(s): https://tools.cisco.com/its/service/oddce/services/DDCEService Environment variable: 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 は、 Webex Callingクラウドをもつローカルゲートウェイ SIP トランクの登録解除を 60 秒ごとにチェックします。 登録解除イベントが検出されると、メールと syslog 通知が生成され、登録解除が 2 回発生した後に DS 自体がアンインストールされます。 署名をインストールするには、以下の手順を使用します。
Diagnostic Signatures Lookup Tool の以下のドロップダウンオプションを使用して、DS 64117 をダウンロードします。
フィールド名
フィールド値
プラットフォーム
Cisco 4300、4400 ISR シリーズ、または Cisco CSR 1000V シリーズ
製品
Webex Calling ソリューションの CUBE Enterprise
問題の範囲
SIP-SIP
問題の種類
メール通知による SIP トランクの登録解除。
DS XML ファイルをローカルゲートウェイにコピーします。
copy ftp://username:password@<server name or ip>/DS_64117.xml bootflash:
ローカルゲートウェイに DS XML ファイルをインストールします。
call-home diagnostic-signature load DS_64117.xml Load file DS_64117.xml success LocalGateway#
イベント、登録者、出席者にすばやくアクセスするため、 call-home 診断署名の表示を実行して、署名が正常にインストールされたことを確認します。 ステータス列の値が「registered」になっている必要があります。
異常な通話切断の監視
この DS は、10 分おきに SNMP ポーリングを使用して、SIP エラー 403、488、503 の異常な通話切断を検出します。 エラーカウントが前回の投票から 5 以上増えている場合、syslog とメール通知が生成されます。 下記の手順を実行して、署名をインストールしてください。
を使用する SNMPを表示 コマンドを使用して、SNMP が有効になっているかどうかを確認します。 有効になっていない場合は、snmpサーバーマネージャ コマンド
show snmp %SNMP agent not enabled config t snmp-server manager end show snmp Chassis: ABCDEFGHIGK 149655 SNMP packets input 0 Bad SNMP version errors 1 Unknown community name 0 Illegal operation for community name supplied 0 Encoding errors 37763 Number of requested variables 2 Number of altered variables 34560 Get-request PDUs 138 Get-next PDUs 2 Set-request PDUs 0 Input queue packet drops (Maximum queue size 1000) 158277 SNMP packets output 0 Too big errors (Maximum packet size 1500) 20 No such name errors 0 Bad values errors 0 General errors 7998 Response PDUs 10280 Trap PDUs Packets currently in SNMP process input queue: 0 SNMP global trap: enabled
Diagnostic Signatures Lookup Tool の以下のオプションを使用して、DS 65221 をダウンロードします。
フィールド名
フィールド値
プラットフォーム
Cisco 4300、4400 ISR シリーズ、または Cisco CSR 1000V シリーズ
製品
Webex Calling ソリューションの CUBE Enterprise
問題の範囲
パフォーマンス
問題の種類
メールおよび Syslog 通知による SIP の異常な通話切断の検出
DS XML ファイルをローカルゲートウェイにコピーします。
copy ftp://username:password@<server name or ip>/DS_65221.xml bootflash:
ローカルゲートウェイに DS XML ファイルをインストールします。
call-home diagnostic-signature load DS_65221.xml Load file DS_65221.xml success
イベント、登録者、出席者にすばやくアクセスするため、 call-home 診断署名の表示を実行して、署名が正常にインストールされたことを確認します。 ステータス列の値が「registered」になっている必要があります。
問題をトラブルシューティングするための診断署名をインストールする
診断署名(DS)を使用して、問題を迅速に解決します。 特定の問題のトラブルシューティング、問題発生の検出、診断データの適切なセットの収集、およびCisco TACケースへのデータの自動転送に必要なデバッグを可能にする複数の署名をCisco TACエンジニアが作成しました。 診断署名(DS)は、問題の発生を手動で確認する必要性を排除し、断続的および一時的な問題のトラブルシューティングをはるかに容易にします。
また、 Diagnostic Signatures Lookup ツール特定の問題を自分で解決するために、適切な署名を見つけ、インストールするか、サポート契約の一部として TAC エンジニアによって推奨される署名をインストールできます。
以下の例は、「%VOICE_IEC-3-GW: CCAPI: Internal Error (call spike threshold): IEC=1.1.181.1.29.0」の syslog 発生を検出し、以下のステップを使用して診断データ収集を自動化します。
追加の DS 環境変数を構成しますds_fsurl_prefix収集された診断データがアップロードされるCisco TACファイルサーバーパス (cxd.cisco.com) です。 ファイルパス内のユーザ名はケース番号で、パスワードはファイル アップロード トークンです。これはサポートケースマネージャーを次のコマンドで実行できます。 必要に応じて、サポートケースマネージャの [添付] セクションでファイルアップロードトークンを生成できます。
configure terminal call-home diagnostic-signature LocalGateway(cfg-call-home-diag-sign)environment ds_fsurl_prefix "scp://<case number>:<file upload token>@cxd.cisco.com" end
例:
call-home diagnostic-signature environment ds_fsurl_prefix " environment ds_fsurl_prefix "scp://612345678:abcdefghijklmnop@cxd.cisco.com"
SNMP がSNMPを表示 コマンド 有効になっていない場合は、snmpサーバーマネージャ コマンド
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 ファイルをローカルゲートウェイにコピーします。
copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash: copy ftp://username:password@<server name or ip>/DS_65095.xml bootflash:
ローカルゲートウェイに、高 CPU モニタリング DS 64224、DS 65095 XML ファイルの順にインストールします。
call-home diagnostic-signature load DS_64224.xml Load file DS_64224.xml success call-home diagnostic-signature load DS_65095.xml Load file DS_65095.xml success
署名が正常にインストールされたことを確認してください。 call-home 診断署名の表示します。 ステータス列の値が「registered」になっている必要があります。
show call-home diagnostic-signature Current diagnostic-signature settings: Diagnostic-signature: enabled Profile: CiscoTAC-1 (status: ACTIVE) Downloading URL(s): https://tools.cisco.com/its/service/oddce/services/DDCEService Environment variable: 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
診断署名の実行を確認する
次のコマンドでは、[状態] 列のcall-home 診断署名の表示ローカル ゲートウェイが署名内で定義されたアクションを実行している間、コマンドは「実行中」に変わります。 出力は次のとおりですCall-home 診断署名統計の表示は、診断署名が対象イベントを検出してアクションを実行するかどうかを検証するための最適な方法です。 [Triggered/Max/Deinstall] 列には、指定した署名がイベントをトリガーした回数、定義済みのイベント最大検出回数、トリガーされたイベントの検出後に署名がアンインストールされるかどうかが表示されます。
show call-home diagnostic-signature
Current diagnostic-signature settings:
Diagnostic-signature: enabled
Profile: CiscoTAC-1 (status: ACTIVE)
Downloading URL(s): https://tools.cisco.com/its/service/oddce/services/DDCEService
Environment variable:
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 |
Call-home 診断署名統計の表示
DS ID | DS 名 | トリガー済み/最大/アンインストール | 平均実行時間(秒) | 最長実行時間(秒) |
---|---|---|---|---|
64224 | DS_LGW_CPU_MON75 | 0/0/N | 0.000 | 0.000 |
65095 | DS_LGW_IEC_Call_spike_threshold | 1/20/Y | 23.053 | 23.053 |
診断署名の実行中に送信される通知メールには、問題の種類、デバイスの詳細、ソフトウェアバージョン、実行中の構成、特定の問題のトラブルシューティングに関連する show コマンド出力などの重要な情報が含まれています。
診断署名をアンインストールする
トラブルシューティング目的で診断署名を使用する場合、通常、診断署名はいくつかの問題の発生が検出された後にアンインストールするように定義されます。 署名を手動でアンインストールする場合は、コールホーム診断署名を表示コマンドを実行し、次のコマンドを実行します。
call-home diagnostic-signature deinstall <DS ID>
例:
call-home diagnostic-signature deinstall 64224
展開でよく見られる問題に基づいて、Diagnostics Signatures Lookup Tool に新しい署名が定期的に追加されます。 TAC では現在、新しいカスタム署名の作成リクエストをサポートしていません。 |
Cisco IOS XE ゲートウェイの管理を改善するため、コントロールハブを通じてゲートウェイを登録し、管理することを推奨します。 これはオプションの設定です。 登録すると、コントロール ハブの設定検証オプションを使用して、ローカル ゲートウェイ構成を検証し、構成の問題を特定することができます。 現在、この機能をサポートしているのは登録ベースのトランクだけです。
詳細については、以下を参照してください。
このセクションでは、証明書ベースの相互 TLS (mTLS) SIP トランクを使用して、Webex Calling のローカル ゲートウェイとして Cisco Unified Border Element (CUBE) を設定する方法について説明します。 このドキュメントの最初の部分は、シンプルな PSTN ゲートウェイを設定する方法を示しています。 この場合、PSTN からのすべてのコールは Webex Calling にルーティングされ、Webex Calling からのすべてのコールは PSTN にルーティングされます。 次の画像では、このソリューションとそれに続く高レベルのコール ルーティング設定が強調表示されます。
この設計では、次の主な構成が使用されます。
音声クラスのテナント: トランク固有の設定を作成するために使用されます。
音声クラス uri: 着信ダイヤルピアの選択のための SIP メッセージを分類するために使用。
着信ダイヤルピア: 着信 SIP メッセージの処理を提供し、ダイヤルピア グループで発信ルートを決定します。
ダイヤルピア グループ: オンワード コール ルーティングに使用する発信ダイヤル ピアを定義します。
発信ダイヤルピア: アウトバウンド SIP メッセージの処理を提供し、必要なターゲットにルーティングします。
オンプレミスの 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 Software Research」ページを参照してください。 プラットフォームを検索し、提案されたリリースのいずれかを選択します。
ISR4000 シリーズ ルータは、Unified Communications および Security テクノロジー ライセンスの両方で設定する必要があります。
Catalyst Edge 8000シリーズのルーターには、ボイスカードまたはDSPが装備されており、DNA Essentialsのライセンスが必要です。 ボイスカードやDSPのないルーターには、最低限のDNA Essentialsライセンスが必要です。
大容量の要件については、High Security(HSEC)ライセンスおよび追加のスループットエンタイトルメントが必要になる場合があります。
詳細については、認証コードを参照してください。
ビジネスポリシーに従うプラットフォームのベースライン設定を構築します。 特に、以下を設定し、作業を確認します。
NTP
ACL
ユーザー認証とリモートアクセス
DNS
IPルーティング
IP アドレス
Webex Calling に向かうネットワークは IPv4 アドレスを使用する必要があります。 ローカル ゲートウェイの完全修飾ドメイン名(FQDN)またはサービス レコード(SRV)アドレスは、インターネット上のパブリック IPv4 アドレスに解決する必要があります。
Webex に面しているローカル ゲートウェイ インターフェイスのすべての SIP ポートとメディア ポートは、直接または静的 NAT 経由でインターネットからアクセスできる必要があります。 それに応じてファイアウォールを更新してください。
署名付き証明書をローカル ゲートウェイにインストールします (詳細な設定手順は次のとおりです)。
Cisco Webex 音声およびビデオ プラットフォームへの通話でサポートされているルート認証局とはに詳述されているパブリック認証局 (CA) は、デバイス証明書に署名する必要があります。
トランクの作成時に Control Hub で設定された FQDN は、ルータの共通名(CN)またはサブジェクト代替名(SAN)の証明書である必要があります。 例:
組織の 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、レコード、またはIPアドレス)は、SAN ではオプションです。
トランクに FQDN または SRV を使用するかどうかにかかわらず、ローカル ゲートウェイからのすべての新しい SIP ダイアログの連絡先アドレスは、Control Hub で設定された名前を使用します。
証明書がクライアントとサーバで使用されていることを確認します。
Cisco ルート CA バンドルをローカル ゲートウェイにアップロードします。
構成
1 | 次のように、有効でルーティング可能な IP アドレスをレイヤ 3 インターフェイスに割り当てます。
| ||
2 | 対称暗号化を使用してルータの STUN クレデンシャルを保護します。 プライマリ暗号化キーと暗号化タイプを次のように設定します。
| ||
3 | 希望する認証局 (CA) によって署名された証明書を使用して暗号化トラストポイントを作成します。 | ||
4 | 中間(またはルート)CA 証明書を使用して新しい証明書を認証し、証明書をインポートします(ステップ 4)。 次の exec または configuration コマンドを入力します。
| ||
5 | 次の exec または configuration コマンドを使用して、署名済みホスト証明書をインポートします。
| ||
6 | TLS1.2 排他を有効にし、次の設定コマンドを使用してデフォルトのトラストポイントを指定します。
| ||
7 | Webex Calling で使用される DigiCert CA 証明書を含む Cisco ルート CA バンドルをインストールします。 を使用する crypto pki trustpool インポート クリーン URLコマンドは、指定されたURLからルートCAバンドルをダウンロードし、現在のCAトラストプールをクリアしてから、証明書の新しいバンドルをインストールします。
|
1 | Control Hub の既存のロケーションの CUBE 証明書ベースの PSTN トランクを作成します。 詳細については、次のサイトを参照してください。 Webex Calling用にトランク、ルートグループ、ダイヤルプランを構成するを選択します。
| ||||
2 | 次のコマンドを入力して、CUBE を Webex Calling ローカル ゲートウェイとして設定します。
構成のフィールドの説明はここにあります。
プラットフォームで Cisco Unified Border Element(CUBE)機能を有効にします。 allow-connections sip to sipCUBE 基本 SIP バックツーバックユーザーエージェント機能を有効にします。 詳細については、次のサイトを参照してください。接続を許可を選択します。
STUN (NAT を介した UDP のセッショントラバーサル) をグローバルに有効にします。
詳細については、「stun flowdata agent-id」および「stun flowdata shared-secret」を参照してください。 非対称ペイロード フルDTMF と動的コーデック ペイロードの両方に対して SIP 非対称ペイロード サポートを設定します。 このコマンドの詳細については、次を参照してください非対称ペイロードを選択します。 early-offer forcedローカル ゲートウェイは、隣接するピアからの確認を待つ代わりに、最初の INVITE メッセージで SDP 情報を送信するように強制します。 このコマンドの詳細については、次を参照してください早期オファーを選択します。 SIP プロファイル着信CUBE が SIP プロファイルを使用して、受信したメッセージを変更できるようにします。 プロファイルは、ダイヤルピアまたはテナントを介して適用されます。 | ||||
3 | を設定する 音声クラスコーデック 100 トランクの コーデック フィルタ。 この例では、すべてのトランクに同じコーデックフィルタが使用されます。 正確な制御のために各トランクにフィルタを設定できます。
構成のフィールドの説明はここにあります。 音声クラス コーデック 100SIP トランクを介したコールの優先コーデックのみを許可するために使用されます。 詳細については、音声クラスコーデック を参照してください。
| ||||
4 | を設定する 音声クラスの使い方 100 は、Webex Calling トランクで ICE を有効にします。 (この手順は政府版 Webex には適用されません)
構成のフィールドの説明はここにあります。 stunusageiceliteについてすべての Webex Calling のダイヤルピアに対して ICE-Lite を有効にして、可能な限り、メディア最適化を可能にするために使用。 詳細については、次のサイトを参照してください。音声クラススタンの使用およびスタン使用アイスライトを選択します。
| ||||
5 | Webex トラフィックのメディア暗号化ポリシーを設定します。 (この手順は政府版 Webex には適用されません)
構成のフィールドの説明はここにあります。 音声クラス srtp-crypto 100SDP の SRTP 暗号スイート CUBE オファーおよび応答メッセージの唯一の SRTP オファーとして SHA1_80 を指定します。 Webex Calling は SHA180 のみをサポートします。_ 詳細については、次のサイトを参照してください。音声クラス SRTP 暗号化を選択します。 | ||||
6 | FIPS 準拠の GCM 暗号を設定します(この手順は政府版 Webex にのみ適用されます)。
構成のフィールドの説明はここにあります。 音声クラス srtp-crypto 100CUBE が提供する暗号スイートとして GCM を指定します。 政府版 Webex のローカル ゲートウェイの GCM 暗号を設定することは必須です。 | ||||
7 | 宛先 FQDN または SRV に基づいて、ローカル ゲートウェイ トランクへのコールを一意に識別するためのパターンを設定します。
構成のフィールドの説明はここにあります。 音声クラス uri 100 sip着信トランク ダイヤル ピアへの着信 SIP 招待と一致するパターンを定義します。 このパターンを入力するときは、トランクの作成中に Control Hub で設定された LGW FQDN または SRV を使用します。 | ||||
8 | SIP メッセージ操作プロファイルを設定します。 ゲートウェイがパブリック IP アドレスで設定されている場合は、次のようにプロファイルを設定するか、NAT を使用している場合は、次のステップにスキップします。 この例では、cube1.lgw.com はローカル ゲートウェイ用に設定された FQDN であり、「198.51.100.1」は Webex Calling に面したローカル ゲートウェイ インターフェイスのパブリック IP アドレスです。
構成のフィールドの説明はここにあります。 ルール10と20Webex がローカル ゲートウェイからのメッセージを認証できるようにするには、SIP 要求および応答メッセージの「連絡先」ヘッダーに、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 要求および応答メッセージの「連絡先」ヘッダーに、Control Hub のトランクにプロビジョニングされた値が含まれている必要があります。 これは、単一のホストの FQDN、またはデバイスのクラスタに使用される SRV ドメイン名のいずれかになります。 ルール30~81プライベート アドレス参照をサイトの外部パブリック アドレスに変換し、Webex が後続のメッセージを正しく解釈してルーティングできるようにします。 Webex Calling からの着信メッセージの SIP プロファイル
構成のフィールドの説明はここにあります。 10から80までのルールパブリックアドレス参照を設定済みのプライベートアドレスに変換し、Webex からのメッセージを CUBE で正しく処理できるようにします。 詳細については、次のサイトを参照してください。音声クラス sip-プロファイルを選択します。 | ||||
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 でサポートされています。 |
Cisco TDM-SIP ゲートウェイで PSTN コール レッグの TDM インターフェイスを設定するには、「ISDN PRI の設定」を参照してください。 |
1 | PSTN トランクからの着信コールを識別するには、次の音声クラス uri を設定します。
構成のフィールドの説明はここにあります。 音声クラス uri 200 sip着信トランク ダイヤル ピアへの着信 SIP 招待と一致するパターンを定義します。 このパターンを入力するときは、IP PSTN ゲートウェイの IP アドレスを使用します。 詳細については、音声クラス uri を参照してください。 |
2 | 次の IP PSTN ダイヤル ピアを設定します。
構成のフィールドの説明はここにあります。
次のタグでVoIPダイヤルピアを定義します300管理とトラブルシューティングを容易にするために意味のある説明を付けます。 詳細については、次のサイトを参照してください。ダイヤルピア音声。 destination-pattern BAD.BAD着信ダイヤル ピア グループを使用して発信コールをルーティングする場合は、ダミー接続先パターンが必要です。 詳細については、次のサイトを参照してください。 Destination-pattern(インターフェイス)を選択します。 session protocol sipv2ダイヤルピア 200 が SIP コール レッグを処理するように指定します。 詳細については、次のサイトを参照してください。 session Protocol (ダイヤル ピア)を選択します。 session target ipv4:192.168.80.13コール レッグを送信する宛先のターゲットIPv4アドレスを示します。 ここでのセッション ターゲットは ITSP のIPアドレスです。 詳細については、セッションターゲット (VoIP ダイヤルピア)を参照してください。 200 経由で 着信 uriVIA ヘッダーとIP PSTN のIPアドレスの一致基準を定義します。 ローカル ゲートウェイのすべての着信 IP PSTN コール レッグとダイヤル ピア 200 を一致させます。 詳細については、着信 URLを参照してください。 バインド制御ソースインタフェース GigabitEthernet0/0/0PSTN に送信されるメッセージのソース インターフェイスと関連する 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 プラットフォームを使用してローカル ゲートウェイを設定する場合は、次のセクションに進みます。 |
前のセクションの PSTN-Webex Calling 設定は、Cisco Unified Communications Manager (UCM) クラスタへの追加のトランクを含めるように変更される場合があります。 この場合、すべてのコールは Unified CM 経由でルーティングされます。 ポート 5060 の UCM からのコールは PSTN にルーティングされ、ポート 5065 からのコールは Webex Calling にルーティングされます。 次の増分設定を追加して、この通話シナリオを含めることができます。
1 | 以下の音声クラス URI を設定: | ||
2 | 次の DNS レコードを設定して、Unified CM ホストへの SRV ルーティングを指定します。
構成のフィールドの説明はここにあります。 次のコマンドは、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 コマンド出力の定期的なモニタリングを通じて、問題検出ロジックを定義します。 アクション タイプには、次のものが含まれます。
show コマンド出力の収集
統合ログファイルを生成する
ユーザーが指定したネットワーク ロケーションへのファイルのアップロード (HTTPS、SCP、 FTPサーバーなど)
TAC エンジニアは DS ファイルを作成し、整合性保護のためデジタル署名を行います。 各 DS ファイルには、システムによって割り当てられた固有の数値IDがあります。 Diagnostic Signatures Lookup ツール(DSLT)は、さまざまな問題の監視とトラブルシューティングに適切な署名を見つけるための単一の情報源です。
開始する前に:
ダウンロードした DS ファイルは編集しないでください。 DSLTを選択します。 変更したファイルは、整合性チェックエラーのためインストールに失敗します。
ローカル ゲートウェイがメール通知を送信するために必要な Simple Mail Transfer Protocol (SMTP) サーバー。
メール通知にセキュアなSMTPサーバーを使用する場合は、ローカルゲートウェイで IOS XE 17.6.1 以上が実行されていることを確認してください。
前提条件
IOS XE 17.6.1 以降を実行しているローカルゲートウェイ
診断署名はデフォルトで有効になっています。
デバイスで IOS XE 17.6.1 以降を実行している場合は、プロアクティブ通知の送信に使用するセキュアなメールサーバーを構成します。
configure terminal call-home mail-server <username>:<pwd>@<email server> priority 1 secure tls end
環境変数を構成しますds_emailに管理者のメールアドレスを指定します。
configure terminal call-home diagnostic-signature LocalGateway(cfg-call-home-diag-sign)environment ds_email <email address> end
プロアクティブ モニタリングのための診断署名をインストールする
高いCPU使用率の監視
この DS はSNMP OID 1.3.6.1.4.1.9.2.1.56 を使用して 5 秒間のCPU使用率を追跡します。 使用率が 75% 以上に達すると、すべてのデバッグが無効になり、ローカルゲートウェイにインストールした診断署名がすべてアンインストールされます。 下記の手順を実行して署名をインストールします。
コマンド を使用して SNMP が有効になっていることを確認します。 SNMPを表示だ SNMPが有効になっていない場合は、snmpサーバーマネージャ コマンド
show snmp %SNMP agent not enabled config t snmp-server manager end show snmp Chassis: ABCDEFGHIGK 149655 SNMP packets input 0 Bad SNMP version errors 1 Unknown community name 0 Illegal operation for community name supplied 0 Encoding errors 37763 Number of requested variables 2 Number of altered variables 34560 Get-request PDUs 138 Get-next PDUs 2 Set-request PDUs 0 Input queue packet drops (Maximum queue size 1000) 158277 SNMP packets output 0 Too big errors (Maximum packet size 1500) 20 No such name errors 0 Bad values errors 0 General errors 7998 Response PDUs 10280 Trap PDUs Packets currently in SNMP process input queue: 0 SNMP global trap: enabled
Diagnostic Signatures Lookup Tool の以下のドロップダウンオプションを使用して、DS 64224 をダウンロードします。
copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash:
フィールド名
フィールド値
プラットフォーム
Cisco 4300、4400 ISR シリーズ、または Catalyst 8000V Edge ソフトウェア
製品
Webex Callingソリューションの CUBE Enterprise
問題の範囲
パフォーマンス
問題の種類
メール通知による高 CPU 使用率
DS XML ファイルをローカルゲートウェイフラッシュにコピーします。
copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash:
次の例は、 FTPサーバーからローカルゲートウェイにファイルをコピーする方法を示しています。
copy ftp://user:pwd@192.0.2.12/DS_64224.xml bootflash: Accessing ftp://*:*@ 192.0.2.12/DS_64224.xml...! [OK - 3571/4096 bytes] 3571 bytes copied in 0.064 secs (55797 bytes/sec)
ローカルゲートウェイに DS XML ファイルをインストールします。
call-home diagnostic-signature load DS_64224.xml Load file DS_64224.xml success
イベント、登録者、出席者にすばやくアクセスするため、 call-home 診断署名の表示を実行して、署名が正常にインストールされたことを確認します。 ステータス列の値が「registered」になっている必要があります。
show call-home diagnostic-signature Current diagnostic-signature settings: Diagnostic-signature: enabled Profile: CiscoTAC-1 (status: ACTIVE) Downloading URL(s): https://tools.cisco.com/its/service/oddce/services/DDCEService Environment variable: 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 とメール通知が生成されます。 下記の手順を実行して、署名をインストールしてください。
コマンド を使用して SNMP が有効になっていることを確認します。 SNMPを表示だ SNMP が有効になっていない場合は、snmpサーバーマネージャ コマンド
show snmp %SNMP agent not enabled config t snmp-server manager end show snmp Chassis: ABCDEFGHIGK 149655 SNMP packets input 0 Bad SNMP version errors 1 Unknown community name 0 Illegal operation for community name supplied 0 Encoding errors 37763 Number of requested variables 2 Number of altered variables 34560 Get-request PDUs 138 Get-next PDUs 2 Set-request PDUs 0 Input queue packet drops (Maximum queue size 1000) 158277 SNMP packets output 0 Too big errors (Maximum packet size 1500) 20 No such name errors 0 Bad values errors 0 General errors 7998 Response PDUs 10280 Trap PDUs Packets currently in SNMP process input queue: 0 SNMP global trap: enabled
Diagnostic Signatures Lookup Tool の以下のオプションを使用して、DS 65221 をダウンロードします。
フィールド名
フィールド値
プラットフォーム
Cisco 4300、4400 ISR シリーズ、または Catalyst 8000V Edge ソフトウェア
製品
Webex Calling ソリューションの CUBE Enterprise
問題の範囲
パフォーマンス
問題の種類
メールおよび Syslog 通知による SIP の異常な通話切断の検出
DS XML ファイルをローカルゲートウェイにコピーします。
copy ftp://username:password@<server name or ip>/DS_65221.xml bootflash:
ローカルゲートウェイに DS XML ファイルをインストールします。
call-home diagnostic-signature load DS_65221.xml Load file DS_65221.xml success
コマンドを使用するcall-home 診断署名の表示をクリックし、署名が正常にインストールされたことを確認します。 ステータス列の値が「registered」になっているはずです。
問題をトラブルシューティングするための診断署名をインストールする
診断署名(DS)を使用して問題を迅速に解決することもできます。 特定の問題のトラブルシューティング、問題発生の検出、診断データの適切なセットの収集、およびCisco TACケースへのデータの自動転送に必要なデバッグを可能にする複数の署名をCisco TACエンジニアが作成しました。 これにより、問題の発生を手動で確認する必要がなくなり、断続的、および一時的な問題のトラブルシューティングがはるかに容易になります。
また、 Diagnostic Signatures Lookup ツール特定の問題を自分で解決するために、適切な署名を見つけ、インストールするか、サポート契約の一部として TAC エンジニアによって推奨される署名をインストールできます。
以下の例は、「%VOICE_IEC-3-GW: CCAPI: Internal Error (call spike threshold): IEC=1.1.181.1.29.0」の syslog 発生を検出し、以下のステップを使用して診断データ収集を自動化します。
別の DS 環境変数を構成するds_fsurl_prefixをCisco TACファイルサーバーパス (cxd.cisco.com) として入力し、診断データをアップロードします。 ファイルパス内のユーザ名はケース番号で、パスワードはファイル アップロード トークンです。これはサポートケースマネージャー次に示すとおりです。 ファイル アップロード トークンは、添付ファイルを追加することができます。
configure terminal call-home diagnostic-signature LocalGateway(cfg-call-home-diag-sign)environment ds_fsurl_prefix "scp://<case number>:<file upload token>@cxd.cisco.com" end
例:
call-home diagnostic-signature environment ds_fsurl_prefix " environment ds_fsurl_prefix "scp://612345678:abcdefghijklmnop@cxd.cisco.com"
コマンド を使用して SNMP が有効になっていることを確認します。 SNMPを表示だ SNMP が有効になっていない場合は、snmpサーバーマネージャ コマンド
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 ファイルをローカルゲートウェイにコピーします。
copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash: copy ftp://username:password@<server name or ip>/DS_65095.xml bootflash:
高CPUモニタリング DS 64224 をインストールし、次に DS 65095 XMLファイルをローカルゲートウェイにインストールします。
call-home diagnostic-signature load DS_64224.xml Load file DS_64224.xml success call-home diagnostic-signature load DS_65095.xml Load file DS_65095.xml success
を使用して署名が正常にインストールされていることを確認します。 コールホーム診断署名を表示だ ステータス列の値が「registered」になっているはずです。
show call-home diagnostic-signature Current diagnostic-signature settings: Diagnostic-signature: enabled Profile: CiscoTAC-1 (status: ACTIVE) Downloading URL(s): https://tools.cisco.com/its/service/oddce/services/DDCEService Environment variable: 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
DS_LGW_IEC_Call_spike_threshold
0.0.12
登録済み
2020-11-08:00:12:53
診断署名の実行を確認する
次のコマンドでは、コマンドの [状態] 列call-home 診断署名の表示ローカル ゲートウェイが署名内で定義されたアクションを実行している間は、「実行中」に変更されます。 出力は次のとおりですCall-home 診断署名統計の表示診断署名が対象イベントを検出してアクションが実行されたかどうかを検証するための最適な方法です。 [Triggered/Max/Deinstall] 列には、指定した署名がイベントをトリガーした回数、定義済みのイベント最大検出回数、トリガーされたイベントの検出後に署名がアンインストールされるかどうかが表示されます。
show call-home diagnostic-signature
Current diagnostic-signature settings:
Diagnostic-signature: enabled
Profile: CiscoTAC-1 (status: ACTIVE)
Downloading URL(s): https://tools.cisco.com/its/service/oddce/services/DDCEService
Environment variable:
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 |
Call-home 診断署名統計の表示
DS ID | DS 名 | トリガー済み/最大/アンインストール | 平均実行時間(秒) | 最長実行時間(秒) |
---|---|---|---|---|
64224 | DS_LGW_CPU_MON75 |
0/0/N |
0.000 |
0.000 |
65095 |
DS_LGW_IEC_Call_spike_threshold |
1/20/Y |
23.053 |
23.053 |
診断署名の実行中に送信される通知メールには、問題の種類、デバイスの詳細、ソフトウェアバージョン、実行中の構成、特定の問題のトラブルシューティングに関連する show コマンド出力などの重要な情報が含まれています。
診断署名をアンインストールする
トラブルシューティング目的で診断署名を使用し、通常はいくつかの問題の発生が検出された後にアンインストールするように定義します。 署名を手動でアンインストールする場合、次の出力から DS IDを取得しますcall-home 診断署名の表示に移動し、次のコマンドを実行します。
call-home diagnostic-signature deinstall <DS ID>
例:
call-home diagnostic-signature deinstall 64224
展開で観察された問題に基づいて、Diagnostics Signatures Lookup Tool に新しい署名が定期的に追加されます。 TAC では現在、新しいカスタム署名の作成リクエストをサポートしていません。 |
基礎
前提条件
Webex Calling のローカル ゲートウェイとして CUBE HA を展開する前に、以下の概念を深く理解するようにしてください。
ステートフル コール保持のための CUBE エンタープライズによるレイヤー 2 ボックス間冗長性
この記事で提供される構成ガイドラインは、既存の音声構成が設定されていない専用のローカル ゲートウェイ プラットフォームが使用されていることを前提としています。 既存の CUBE エンタープライズ展開が、Cisco Webex Calling のローカル ゲートウェイ機能を使用するように変更されている場合、既存のコール フローと機能が中断されないようにして、CUBE HA 設計要件に準拠するように、設定に注意してください。
ハードウェアとソフトウェアのコンポーネント
ローカルゲートウェイとしての CUBE HA には IOS-XE バージョン 16.12.2 以降、および CUBE HA と LGW 機能の両方をサポートするプラットフォームが必要です。
この記事のコマンドとログの表示は、vCUBE(CSR1000v)で実装された Cisco IOS-XE 16.12.2 のソフトウェアの最小リリースに基づいています。 |
参考資料
さまざまなプラットフォーム向けの詳細な CUBE HA 設定ガイドを次に示します。
CSR 1000v (vCUBE)— https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-cube-high-availability-CSR1000v.html
Cisco Preferred Architecture for Cisco Webex Calling— https://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Collaboration/hybrid/AltDesigns/PA-WbxCall.pdf
Webex Calling ソリューションの概要
Cisco Webex Calling は、複数の PSTN オプションにより、オンプレミスの PBX 電話サービスにマルチテナントのクラウドベースの代替手段を提供するコラボレーションソリューションです。
この記事の焦点は、ローカル ゲートウェイの展開 (以下を参照) です。 Webex Calling のローカルゲートウェイ(プレミスベースの PSTN)トランクによって、顧客が所有する PSTN サービスへの接続が可能になります。 また、Cisco Unified CM などのオンプレミス IP PBX 展開への接続も提供します。 クラウド間のすべての通信は、メディア向け SIP および SRTP で TLS トランスポートを使用してセキュリティ保護されています。
次の図では、既存の IP PBX なしでの Webex Calling 展開を示し、単一または複数サイトの展開に適用されます。 この記事に記載されている設定は、この展開に基づいています。
レイヤー 2 のボックス間冗長性
CUBE HA レイヤー 2 ボックス間冗長性は、冗長性グループ (RG) インフラストラクチャ プロトコルを使用して、ルーターのアクティブ/スタンバイ ペアを形成します。 このペアは、それぞれのインターフェイスで同じ仮想 IP アドレス (VIP) を共有し、ステータ スメッセージを継続的に交換します。 CUBE セッションはルーターのペアリングのチェックポイントであり、アクティブ ルーターがサービスを停止した場合に、スタンバイ ルーターがすべての CUBE コール処理の責任を果たすことができるようになりました。その結果、シグナリングとメディアのステートフルな保持が可能になりました。
チェック ポイントは、メディア パケットのある接続されたコールに限定されます。 転送中のコールはチェック ポイントではありません (たとえば、試行中または呼出状態)。 この記事では、CUBE HA は、ステートフルコール保持の CUBE ハイ アベイラビリティ (HA) レイヤー 2 ボックス間 (B2B) 冗長性を参照します。 |
IOS-XE 16.12.2 では、CUBE HA を Cisco Webex Calling トランク(プレミスベースの PSTN)展開のローカルゲートウェイとして展開できます。この記事では、設計の考慮事項と構成について説明します。 この図は、Cisco Webex Calling トランク展開のローカルゲートウェイとしての一般的な CUBE HA 設定を示しています。
冗長性グループ インフラストラクチャ コンポーネント
冗長グループ (RG) インフラ コンポーネントは、2 つの CUBE 間でのボックス間通信インフラストラクチャのサポートを提供し、最終的に安定した冗長性の状態をネゴシエートします。 このコンポーネントは次の機能も提供します。
2 つの CUBE 間で keepalive と hello メッセージを交換することで (コントロール インターフェイス)、各ルータの最終的な冗長状態をネゴシエートする HSRP のようなプロトコル。上の図の GigabitEthernet3です。
アクティブからスタンバイ ルータ (データ インターフェイス経由) への各コールに関して、シグナリングとメディアの状態をチェックするための転送メカニズム。上記の図の GigabitEthernet3です。
トラフィック インターフェイスの仮想 IP (VIP) インターフェイスの構成と管理 (複数のトラフィック インターフェイスは同じ RG グループを使用して構成できます)。GigabitEthernet 1 および 2 はトラフィック インターフェイスと見なされます。
この RG コンポーネントは、音声 B2B HA をサポートするように特別に構成する必要があります。
信号とメディアの両方に関する仮想 IP (VIP) アドレス管理
B2B HA は、冗長性を確保する際に VIP に依存します。 CUBE HA ペアの両方の CUBE で VIP および関連する物理インターフェイスは、同じ LAN サブネット上に存在している必要があります。 VIP の構成、および特定の音声アプリケーション (SIP) への VIP インターフェイスのバインドは、音声 B2B HA サポートに必須です。 Unified CM、Webex Calling アクセス SBC、サービス プロバイダー、プロキシなどの外部デバイスは、CUBE HA ルーターを通過するコールの宛先 IP アドレスとして VIP を使用します。 そのため、Webex Calling の観点から、CUBE HA ペアは単一のローカル ゲートウェイとして機能します。
確立されたコールのコール シグナリングおよび RTP セッション情報は、アクティブなルーターからスタンバイ ルーターへのチェックポイントです。 アクティブ ルーターがダウンすると、スタンバイ ルーターが引き継ぎ、最初のルーターによって以前にルーティングされた RTP ストリームを継続して転送します。
フェイルオーバー時に一時的な状態のコールは、切り替え後には保存されません。 たとえば、まだ完全に確立されていない、または転送や保留の機能により変更中のコールなどです。 確立されたコールは、切り替え後に切断される場合があります。
コールのステートフル フェールオーバーのローカル ゲートウェイとして CUBE HA を使用するには、以下の要件があります。
CUBE HA は TDM またはアナログ インターフェイスを共存させることはできません
Gig1 および Gig2 はトラフィック (SIP/RTP) インターフェイス、Gig3 は冗長グループ (RG) コントロール/データ インターフェイスと呼ばれます
グループ id 1 とグループ id 2 を持つ同じレイヤー 2 ドメインに配置できる CUBE HA ペアは 2 つまでです。 同じグループ ID で 2 つの HA ペアを構成する場合、RG コントロール/データ インターフェイスは異なるレイヤー 2 ドメイン (vlan、個別のスイッチ) に属している必要があります
ポート チャネルは、RG コントロール/データとトラフィック インターフェイスの両方でサポートされています
すべてのシグナリング/メディアは、仮想 IP アドレスから供給されます
プラットフォームが CUBE HA 関係にリロードされると、常にスタンバイとして起動します
すべてのインターフェイスの下位アドレス (Gig1、Gig2、Gig3) は、同じプラットフォームにある必要があります
冗長性インターフェイス識別子、rii は同じレイヤー 2 のペア/インターフェイスの組み合わせに対して固有である必要があります
両方の CUBE の構成は、物理構成を含む必要があり、同じ種類のプラットフォームと IOS-XE バージョンで実行されている必要があります
ループバック インターフェイスは、常に起動しているためバインドとして使用できません
複数のトラフィック (SIP/RTP) インターフェイス (Gig1、Gig2) では、インターフェイスのトラッキングが構成されている必要があります
CUBE-HA は、RG コントロール/データ リンク (Gig3) のクロスオーバー ケーブル接続ではサポートされていません
両方のプラットフォームは同一である必要があり、すべての同様のインターフェイスで CUBE HA が機能するように [物理スイッチ] を介して接続します。例: CUBE-1 と CUBE-2 の GE0/0/0 は同じスイッチ上で終了する必要があります
直接 CUBE 上で、またはいずれかの側のデータ HA で WAN を終了することができません
アクティブ/スタンバイは両方とも同じデータセンターにある必要があります
冗長性 (RG コントロール/データ、Gig3) に別の L3 インターフェイスを使用する必要があります。トラフィックに使用されるインターフェイスは、HA keepalives およびチェックポイントに使用できません
フェールオーバー時に、以前アクティブだった CUBE は、設計によって再読み込みされ、シグナリングとメディアを保持します
両方の CUBE で冗長性を構成する
HA ペアで使用し、仮想 IP を表示するために、両方の CUBE でレイヤー 2 ボックス間冗長性を構成する必要があります。
1 | インターフェイスのステータスを追跡するために、グローバル レベルでインターフェイス トラッキングを構成します。
トラッキング CLI は、トラフィック インターフェイスがダウンした後、アクティブ ルートがアクティブな役割を果たすように、RG 内で音声トラフィックインターフェイスの状態を追跡するために使用されます。 | ||||||
2 | アプリケーション冗長性サブモード下の VoIP HA で使用する RG を構成します。
この構成で使用されるフィールドの説明を次に示します。
| ||||||
3 | CUBE アプリケーションのボックス間の冗長性を有効にします。 以下の下にある以前の手順から RG を構成します:
redundancy-group 1—このコマンドを追加および削除するには、更新された構成を有効にするための再読み込みが必要です。 すべての構成が適用された後で、プラットフォームを再読み込みします。 | ||||||
4 | 以下に示すように、Gig1 と Gig2 インターフェイスをそれぞれの仮想 IP で構成し、冗長性インターフェイス識別子 (rii) を適用します。
この構成で使用されるフィールドの説明を次に示します。
| ||||||
5 | 最初の CUBE 構成を保存し、再読み込みします。 最後にリロードするプラットフォームは常にスタンバイです。
VCUBE-1 が完全に起動したら、 VCUBE-2 の構成を保存し、再読み込みします。
| ||||||
6 | ボックス間の構成が期待どおりに機能していることを確認します。 関連する出力は太字で強調表示されます。 VCUBE-2 を最後にリロードし、設計上の考慮事項に従います。最後にリロードするプラットフォームは常に [スタンバイ] 状態です。
|
両方の CUBE でローカル ゲートウェイを構成する
この例の構成では、Control Hub から以下のトランク情報を使用して、VCUBE-1、VCUBE-2 の両方のプラットフォームでローカルゲートウェイを構成しています。 この設定のユーザー名とパスワードは以下のとおりです。
ユーザー名: フセイン1076_LGU
パスワード: lOV12MEaZx
1 | クレデンシャルまたは共有秘密で使用する前に、以下のコマンドを使用して、設定キーがパスワードに対して作成されていることを確認してください。 Type 6 パスワードは、AES 暗号化とこのユーザー定義の設定キーを使用して暗号化されます。
これは、上に表示されている Control Hub のパラメーターに基づき、両方のプラットフォームに適用し、保存し、リロードするローカ ルゲートウェイの構成です。 Control Hub からの SIP ダイジェスト クレデンシャルは太字でハイライトされています。
Show コマンド出力を表示するには、VCUBE-2 の後に VCUBE-1 をリロードし、VCUBE-1 をスタンバイ CUBE にして、VCUBE-2 をアクティブ CUBE にします。 |
2 | 任意の時点で、1 個のプラットフォームのみが、Webex Calling アクセス SBC を使用したローカル ゲートウェイとしてアクティブ登録を保持します。 以下の show コマンドの出力を見てみましょう。 show redundancy application group 1 sip-ua レジスタ ステータスを表示
上記の出力から、 VCUBE-2 がアクティブ LGW で、Webex Calling アクセス SBC への登録を維持していることがわかります。しかし、「show sip-ua register status」の出力は VCUBE-1 では空です |
3 | VCUBE-1 で次のデバッグを有効にします
|
4 | この場合、アクティブ LGW、VCUBE-2 で次のコマンドを実行してフェールオーバーをシミュレートします。
アクティブからスタンバイ LGW への切り替えは、上記に一覧表示されている CLI に加えて、以下のシナリオで発生します。
|
5 | VCUBE-1 が Webex Calling アクセス SBC に登録されているかどうかを確認します。 VCUBE-2 は今すぐにリロードされます。
VCUBE-1 がアクティブ LGW になりました。 |
6 | 仮想 IP を通じて SIP REGISTER を Webex Calling に送信し、200 OK を受信する VCUBE-1 に関連するデバッグ ログを確認してください。
|
ローカル ゲートウェイへトランクするための SIP トランク セキュリティ プロファイルを構成する
ローカル ゲートウェイと PSTN ゲートウェイが同じデバイス上に存在する場合、Unified CM を有効にして、同じデバイスから発信された 2 個の異なるトラフィックの種類 (Webex と PSTN のコール) を区別し、これらのコール タイプに対して差別化されたクラスのサービスを適用する必要があります。 この差別化されたコール処理は、Unified CM および結合されたローカル ゲートウェイと PSTN ゲートウェイ デバイスの 2 つのトランクをプロビジョニングすることで行われます。これは、2 つのトランクに異なる SIP リスニング ポートを必要とします。
次の設定でローカル ゲートウェイ トランクの専用の SIP トランク セキュリティ プロファイルを作成します。
|
ローカル ゲートウェイ トランクの SIP プロファイルを構成する
次の設定でローカル ゲートウェイ トランク用の専用の SIP プロファイルを作成します。
|
Webex からのコールのコール検索スペースを作成する
次の設定で Webex から発信されたコールのためのコール検索スペースを作成します。
|
Webex 間で SIP トランクを構成する
次の設定を使用して、ローカル ゲートウェイ経由での Webex 間のコールに SIP トランクを作成します。
|
Webex のルート グループを構成する
次の設定でルート グループを作成します。
|
Webex のルート リストを構成する
次の設定でルート リストを作成します。
|
Webex の移動先のパーティションを作成する
次の設定で Webex の移動先のパーティションを作成します。
|
次に行うこと
このパーティションは、Webex の宛先にアクセスする必要があるすべてのコール検索スペースに追加してください。 このパーティションは、PSTN から Webex への発信がルーティングされるように、PSTN トランクの着信コール検索スペースとして使用されるコール検索スペースに特に追加する必要があります。
Webex の移動先のルート パターンを構成する
次の設定で Webex の各 DID 範囲のルート パターンを構成します。
|
Webex の簡略サイト間ダイヤル正規化を構成する
短縮されたサイト間ダイヤルが Webex に必要な場合は、Webex の各 ESB 範囲にダイヤル正規化パターンを設定します。
|
ハント グループをセットアップする
ハント グループは着信をグループのユーザーまたはワークスペースにルーティングします。 グループ全体にルーティングするパターンを構成することもできます。
ハント グループのセットアップ方法の詳細については、「Cisco Webex Control Hub のハント グループ」を参照してください。
通話キューを作成する
コール キューを作成すれば、顧客の発信にすぐに応答がない場合、誰かが応答できるようになるまで自動応答にしたり、お詫びのメッセージや保留中の音楽が流れるようにしたりすることができます。
コール キューをセットアップおよび管理する方法の詳細については、「Cisco Webex Control Hub でコール キューを管理する」を参照してください。
レセプショニスト クライアントを作成する
お客様のフロントオフィスの担当者のニーズに対応します。 ユーザーを電話のアテンダントとして設定すると、組織内の特定のユーザーに着信するコールをスクリーンできます。
レセプショニストクライアントのセットアップ方法と表示方法については、「Cisco Webex Control Hub のレセプショニストクライアント」を参照してください。
自動アテンダントを作成して管理する
セットアップ メニューと、応答サービス、ハント グループ、ボイスメール ボックスや実際のオペレーターなどへのルーティング機能によって、適切なあいさつを返すことができます。 24 時間分のスケジュールを作成できます。あるいは、時間内か外かに応じて、異なるオプションを使うこともできます。
自動アテンダントの作成と管理の方法については、「Cisco Webex Control Hub で自動アテンダントを管理する」を参照してください。
ページング グループを構成する
グループ ページングは、特定のページング グループに割り当てられた番号または内線番号をダイヤルすることにより、最大 75 名のターゲット ユーザーに一方向通話を行うか、グループ ページングを行うことができるようにします。
ページング グループのセットアップ方法と編集方法の詳細については、「Cisco Webex Control Hub のページング グループを構成する」を参照してください。
コール ピックアップを設定する
コール ピックアップ グループを作成し、グループのユーザーがお互いの通話に応答できるようにすることによって、社内でのチームワークと協力体制を強化します。 ユーザーをコールピックアップグループに追加しておけば、グループメンバーが席を離れていたり、電話中だったりした場合、別のメンバーが電話に出ることができます。
コールピックアップグループのセットアップ方法については 、「Cisco Webex Control Hub でのコールピックアップ」を参照してください。
コール パークをセットアップする
コール パークにより、ユーザーの定義されたグループは、コール パーク グループの他の利用可能なメンバーに対するコールをパークすることができます。 パーク中のコールは、グループの他のメンバーが自分の電話で取ることができます。
コールパークのセットアップ方法の詳細については、「Cisco Webex Control Hub コールパーク」を参照してください。
ユーザーの割り込みを有効にする
1 | の顧客ビューから、[管理] > [ユーザー] の順に移動します。https://admin.webex.com |
2 | ユーザーを選択し、[Calling] をクリックします。 |
3 | [ユーザー権限間]セクションに移動し、[割り込み]を選択します。 |
4 | トグルをオンにすると、他のユーザがこのユーザの進行中のコールに自分自身を追加できるようになります。 |
5 | このユーザーがコールに割り込むときに他のユーザーにトーンを再生する場合は、[このユーザーがコールで割り込むときにトーンを再生] にチェックを入れます。 |
6 | [保存] をクリックします。 |
ユーザーのプライバシーを有効にする
1 | Control Hubにサインインし、 。 | ||
2 | ユーザーを選択し、[Calling] をクリックします。 | ||
3 | [ユーザー権限間]領域に移動し、[プライバシー]を選択します。 | ||
4 | このユーザーに適切な [自動音声応答のプライバシー] 設定を選択します。
| ||
5 | [プライバシーを有効にする] チェックボックスをオンにします。 ドロップダウンリストからメンバーを選択しないことで、全員をブロックすることができます。 または、このユーザーの回線ステータスを監視できるユーザー、ワークスペース、仮想回線を選択することもできます。 ロケーション管理者の場合、割り当てられたロケーションに関連するユーザー、ワークスペース、仮想回線だけがドロップダウン リストに表示されます。 [プライバシーを有効にする] チェックボックスをオフにすると、全員が回線のステータスを監視できるようになります。 | ||
6 | ダイレクト コール ピックアップと割り込みのプライバシーを有効にするには、[ダイレクト コール ピックアップと割り込みのプライバシーを強制] チェックボックスをオンにします。
| ||
7 | [名前でメンバーを追加] から、電話回線のステータスを監視し、ダイレクト コール ピックアップと割り込みを呼び出せるユーザ、ワークスペース、仮想回線を選択します。 | ||
8 | 選択したメンバーをフィルタリングするには、[名前、番号、またはextでフィルタリング]フィールドを使用します。 | ||
9 | 選択したすべてのメンバーを削除するには、[すべて削除]をクリックします。
| ||
10 | [保存] をクリックします。 |
モニタリングの設定
ユーザーの監視対象回線の最大数は 50 です。 ただし、モニタリング リストを設定する際には、Webex Calling とネットワーク間の帯域幅に影響を与えるメッセージの数を考慮してください。 また、ユーザの電話機の回線ボタンの数によって、最大監視回線を決定します。
1 | https://admin.webex.comの顧客ビューから、[管理]に移動し、[ユーザー]をクリックします。 | ||||
2 | 変更するユーザーを選択し、[Calling] をクリックします。 | ||||
3 | [ユーザー権限間] セクションに移動し、[モニタリング] を選択します。 | ||||
4 | 次から選択します:
ユーザーモニタリングのために、[モニタリング対象の回線を追加(Add Monitored Line)] リストに仮想回線 を含めることができます。 | ||||
5 | このユーザーにパークされたコールを通知するかどうかを選択し、監視対象のユーザーまたはコール パーク内線を検索し、[保存] をクリックします。
|
ユーザーのコール ブリッジ警告トーンを有効にする
始める前に
1 | Control Hubにサインインし、 。 | ||
2 | ユーザーを選択し、[通話] タブをクリックします。 | ||
3 | [ユーザー権限間] に移動し、[コールブリッジ警告トーン] をクリックします。 | ||
4 | オンにするコール ブリッジの警告トーンを選択し、 [保存を選択します。
MPP 共有回線のコール ブリッジングの詳細については、「マルチプラットフォーム デスク フォンの共有回線」を参照してください。 Webex アプリの共有回線でのコール ブリッジングの詳細については、「WebexApp の共有回線アピアランス」を参照してください。 |
ユーザーのためにホテリングをオンにする
1 | 顧客ビューからhttps://admin.webex.com、管理を選択して、ユーザーを選択します。 | ||
2 | ユーザーを選択し、[通話] タブをクリックします。 | ||
3 | [ユーザー間の権限]セクションに移動し、[ホテリング]を選択してトグルをオンにします。 | ||
4 | [ホテリングロケーション] 検索フィールドにホテリングホストの名前または番号を入力し、ユーザーに割り当てるホテリングホストを選択します。 選択できるホテリング主催者は 1 つのみです。 別のホテリング主催者を選択した場合、最初のホテリング ホストは削除されます。
| ||
5 | ユーザーがホテリングホストに関連付けることができる時間を制限するには、[関連付け期間を制限(Limit Association Period)] ドロップダウンからユーザーがホテリングホストを使用できる時間を選択します。 指定した時間が経過すると、ユーザーは自動的にログアウトします。
| ||
6 | [保存] をクリックします。
|
通話レポートを表示する
Control Hub の [アナリティクス] ページを使用して、ユーザーがどのように Webex Calling と Webex アプリ (エンゲージメント) を使用しているか、また、通話のメディア エクスペリエンスの質について洞察を得ることができます。 Webex Calling のアナリティクスにアクセスするには、Control Hub にサインインし、[アナリティクス] に移動して、[Calling] タブを選択します。
1 | 通話履歴の詳細レポートを参照するには、コントロールハブを表示し、次に移動します。分析次のリンクをクリックしてください:電話を選択します。 |
2 | 選択詳細な通話履歴を選択します。 専用インスタンスを使用する通話の詳細については、「専用インスタンスの分析」を参照してください。 |
3 | メディア品質データにアクセスするには、Control Hub にサインインし、[アナリティクス] に移動して、[Calling] を選択します。 詳細については、「クラウド コラボレーション ポートフォリオのためのアナリティクス」を参照してください。
|
CScan ツールを実行する
CScan は、Webex Calling へのネットワーク接続をテストするために設計されたネットワーク準備ツールです。
詳細については、「CScan を使用して Webex Calling ネットワークの品質をテストする」をご覧ください。 |
環境を準備する
一般的な前提条件
Webex Calling のローカル ゲートウェイを設定する前に、次のことを確認してください。
-
VoIP の原理についての基本的な知識があること
-
Cisco IOS-XE と IOS-XE 音声のコンセプトについて、基本的で実際的な知識があること
-
セッション開始プロトコル (SIP) の基本的な理解がある
-
導入モデルに Cisco Unified Communications Manager (Unified CM) が含まれている場合には、Unified CM についての基本的な理解があること
詳細については、『Cisco Unified Border Element (CUBE) Enterprise Configuration Guide 』を参照してください。
ローカル ゲートウェイのハードウェアおよびソフトウェア的要件
展開に次のような 1 つ以上のローカル ゲートウェイがあることを確認します。
-
IP ベースの接続用 Cisco CUBE
-
TDM ベースの接続のための Cisco IOS ゲートウェイ
ローカル ゲートウェイは、自分のペースで Webex Calling に移行するのに役立ちます。ローカル ゲートウェイは、既存のオンプレミス展開を Webex Calling と統合します。既存の PSTN 接続を使用することもできます。「ローカル ゲートウェイの使い方」を参照してください。
ローカル ゲートウェイのライセンスに関する要件
CUBE コールライセンスは、ローカル ゲートウェイにインストールされている必要があります。詳細については、Cisco Unified 境界要素の構成ガイドを参照してください。
ローカル ゲートウェイの認証およびセキュリティ的要件
Webex Calling は、安全な信号経路とメディアを必要とします。ローカルゲートウェイは暗号化を行います。また、以下の手順に従って、TLS 接続をクラウド方向に確立する必要があります。
-
LGW は、Cisco PKI からの CA ルートバンドルで更新しておく必要があります
-
LGW を構成する際には、Control Hub のトランク構成ページから取得した一連の SIP ダイジェスト資格情報が使用されます(この手順は、この後の構成の一部です)
-
CA ルート バンドルは、提示された証明書を検証します
-
資格情報が要求されます (SIP ダイジェストにより提供されたもの)
-
クラウドは、どのローカル ゲートウェイがセキュアに登録されているかを識別します
ローカルゲートウェイのファイアウォール、NAT Traversal、メディアパス最適化の各要件
ほとんどの場合、ローカル ゲートウェイとエンドポイントは、NAT によるプライベート IP アドレスを使用して、内部の顧客ネットワークに配置することができます。エンタープライズ ファイアウォールは、特定の IP アドレス/ポートに対する外向きトラフィック (SIP、RTP/UDP、HTTP) を許可していなければなりません。この点は、「ポート参照情報」で説明されています。
ICE でメディアパスの最適化を利用する場合、ローカルゲートウェイの Webex Calling に面しているインターフェイスには Webex Calling エンドポイントとの双方向の直接ネットワークパスが必要です。エンドポイントが別のロケーションにあり、ローカルゲートウェイの Webex Calling に面しているインターフェイスとこのエンドポイントとの間に直接ネットワークパスがない場合、メディアパスの最適化を利用するには、ローカルゲートウェイとエンドポイント間の通話のために、Webex Calling に面しているインターフェイスに割り当てられたパブリック IP アドレスをローカルゲートウェイに設定する必要があります。また、IOS-XE バージョン 16.12.5 を実行している必要があります。
組織のために Webex Calling を設定する
Webex Calling サービスを稼働させるための最初のステップは、初回セットアップ ウィザード (FTSW) を完了することです。最初のロケーションの FTSW が完了した後では、追加のロケーションに対して完了する必要がありません。
1 |
受け取ったウェルカム メールのはじめにリンクをクリックします。 管理者のメールアドレスが、自動的に、Control Hub にサインインするためのメール アドレスとして使用されます。サインインすると、管理者パスワードを作成するように求められます。サインインすると、セットアップ ウィザードが自動的に開始します。 |
2 |
利用規約を見直して、承諾します。 |
3 |
プランを見直して、[はじめに] をクリックします。 アカウント マネージャは FTSW の最初の手順をアクティブにする責任があります。[使い始める] を選択した時に、「通話をセットアップできません」という通知を受け取った場合は、アカウント マネージャーに連絡してください。 |
4 |
データ センターがマッピングする国を選択し、顧客の連絡先と顧客アドレス情報を入力します。 |
5 |
[次へ: デフォルトのロケーション |
6 |
次のオプションから選択します:
セットアップ ウィザードを完了した後で、作成したロケーションにメイン番号を追加していることを確認してください。 |
7 |
このロケーションに適用する次の選択を行います。
|
8 |
[次へ] をクリックします。 |
9 |
利用可能な Cisco Webex SIP アドレスを入力し、[次へ] をクリックし、[完了] を選択します。 |
始める前に
新しいロケーションを作成するには、以下の情報を指定します。
-
ロケーションの住所
-
希望する電話番号(オプション)
1 |
Log in to Control Hub at https://admin.webex.com, go to . A new location will be hosted in the regional data center that corresponds to the country you selected using the First Time Setup Wizard. |
2 |
ロケーションを設定します。
|
3 |
[保存 ] をクリックしてから、[ はい/いいえ ] を選択して、現在または後でロケーションに番号を追加します。 |
4 |
[はい] をクリック した場合、次のいずれかのオプションを選択します。
PSTN オプションの選択は各ロケーション レベルで行います (各ロケーションには PSTN オプションが 1 つしかありません)。展開に対して必要な数のオプションを組み合わせることができますが、各ロケーションには 1 つのオプションとなります。PSTN オプションを選択してプロビジョニングしたら、ロケーションの PSTN プロパティで [管理] をクリックすると、オプションを変更できます。ただし、Cisco PSTN などの一部のオプションは、別のオプションが割り当てられた後は使用できない場合があります。Open a support case for guidance. |
5 |
番号を今すぐに有効にするか、または後で有効にするかを選択します。 |
6 |
統合されていない CCP またはプレミス ベースの PSTN を選択した場合は、電話番号をコンマ区切り値として入力し、[検証] をクリックします。 特定のロケーションのための番号が追加されます。有効なエントリは [検証済みの番号] フィールドに移動し、無効なエントリは [番号の追加] フィールドに残り、エラー メッセージが表示されます。 番号の書式は、ロケーションの所在する国に応じ、ダイヤリングに関する地元の要件に従って定められます。たとえば、国コードが必要な場合には、コードを付けて入力することも、コードなしで入力してからコードが自動的に先頭に追加されるようにすることもできます。 |
7 |
[保存] をクリックします。 |
次に行うこと
ロケーションを作成した後、そのロケーションの緊急 911 サービスを有効にすることができます。詳細については「Webex Calling の RedSky 緊急 911 サービス」を参照してください。
始める前に
ロケーションに関連付けられているユーザーとワークスペースのリストを取得します。[サービス これらのユーザーとワークスペースを削除する必要があります。
し、ドロップダウン メニューから、削除する場所を選択します。ロケーションを削除する前に、このロケーションに関連付けられているすべての番号は、PSTN プロバイダーに戻されることに注意してください。つまり、これらの番号は所有しなくなります。
1 |
Log in to Control Hub at https://admin.webex.com, go to . |
2 |
Click |
3 |
[場所 の削除] を選択し、その場所を削除します。 一般的に、場所が完全に削除されるには数分かかりますが、最大で 1 時間かかる場合があります。ステータスを確認するには、ロケーション名の隣にある |
作成した後PSTNのセットアップ、名前、タイムゾーン、言語を変更できます。新しい言語は新しいユーザーとデバイスにのみ適用されることに注意してください。既存のユーザーおよびデバイスは古い言語を使用し続けます。
既存のロケーションについては、緊急時の 911 サービスを有効にすることができます。詳細については「Webex Calling の RedSky 緊急 911 サービス」を参照してください。
1 |
Log in to the Control Hub at https://admin.webex.com, go to . ロケーションの隣に [警告] 記号が表示される場合、そのロケーションの電話番号をまだ設定していないという意味です。その番号を設定するまで、通話の送受信が行えなんす。 |
2 |
(オプション) [PSTN 接続] の下で、すでに設定されているものに応じて、[クラウド接続 PSTN] または [プレミスベースの PSTN](ローカル ゲートウェイ) のいずれかを選択します。[管理] をクリックして設定を変更してから、[続行] を選択することにより、関連するリスクを承認します。以下のオプションのいずれかを選択して、[保存] クリックします。
|
3 |
For the location, select the Main Number from the drop-down list to enable users in that location to make and receive calls. The Main Number can be assigned to the auto attendant so that the external callers can contact Webex Calling users at that location. Webex Calling users in that location can also use this number as their external caller ID when making calls. |
4 |
(オプション) [緊急コール] で[緊急時のロケーション識別子] を選択して、このロケーションに割り当てることができます。 この設定はオプションで、必要な国にのみ適用されます。 一部の国 (例: フランス) の規制要件は、緊急電話を行い、緊急連絡時にセルの識別を確立するためのセルに関する規制要件であり、緊急権限によって利用可能になります。Other countries like the U.S and Canada implement location determination using other methods. 詳細については、「緊急時通話の強化 」を参照してください。 緊急通話プロバイダはアクセスネットワークに関する情報が必要な場合があります。新しいプライベートSIP拡張ヘッダーであるP-Access-Network-Infoを指定することで達成できます。ヘッダーにはアクセスネットワークに関連する情報が含まれます。 場所に緊急ロケーション識別子を設定すると、場所の値は SIP メッセージの一部としてプロバイダーに送信されます。緊急通話プロバイダーに連絡して、この設定が必要で、緊急通話プロバイダーから提供された値を使用する必要がある場合はそれを確認してください。」 |
5 |
このロケーションでユーザーがボイスメールをチェックするために呼び出せる [ボイスメール番号] を選択します。 |
6 |
(オプション) ロケーション ページの上部にある鉛筆アイコンをクリックし、必要に応じて [ロケーションの名前]、[アナウンス言語]、[メール言語]、[タイムゾーン]、[住所] を変更し、[保存] をクリックします。 [アナウンス言語] の変更は、このロケーションに追加された新規ユーザーや機能に対して直ちに有効になります。既存のユーザーや機能のアナウンス言語も変更する必要がある場合は、プロンプトが表示されたら、[既存のユーザーとワークスペースの変更] または [既存機能の変更] を選択します。[適用] をクリックします。[タスク] ページで進捗状況を確認できます。これが完了するまでは、これ以上変更を加えることはできません。 ロケーションの [タイム ゾーン] を変更しても、このロケーションに関連する機能のタイム ゾーンは更新されません。自動アテンダント、ハント グループ、コール キューなどの機能のタイム ゾーンを編集するには、タイムゾーンを更新する特定の機能の [全般設定] エリアに移動し、そこで編集して保存します。 |
これらの設定は社内ダイヤルに適用されるものであり、最初のセットアップ ウィザードでも設定できます。As you change your dial plan, the example numbers in the Control Hub update to show these changes.
ロケーションに対する発信通話の権限を設定できます。これらのステップをご覧になり、発信権限を設定してください。
1 |
Sign in to Control Hub, go to , and then scroll to Internal Dialing. |
2 |
必要に応じて、次のオプションのダイヤル設定を行います。
|
3 |
特定の場所の内部ダイヤルを指定します。Go to Calling. Scroll to Dialing, and then change internal dialing as needed: , select a location from the list, and click
|
4 |
Specify external dialing for specific locations. Go to Calling. Scroll to Dialing, and then change external dialing as needed: , select a location from the list, and click
ユーザーへの影響:
|
付加価値再販業者の場合、これらの手順を使用して Control Hub でローカル ゲートウェイの設定を開始できます。このゲートウェイがクラウドに登録されると、Webex Calling の 1 つ以上のロケーションで使用して、エンタープライズ PSTN サービス プロバイダーへのルーティングを提供できます。
ローカル ゲートウェイがある場所は、ローカル ゲートウェイが他の場所で使用されているときには削除できません。
始める前に
-
ロケーションが追加されたら、ロケーションに対してプレミスベース PSTN を設定する前に、トランクを作成する必要があります。
-
それぞれについて、ロケーションと固有の設定および番号を作成します。ロケーションはプレミスベース PSTN を追加する前に存在する必要があります。
-
Webex Calling でのプレミスベース PSTN (ローカル ゲートウェイ) 要件について理解しておいてください。
-
プレミスベース PSTN を持つロケーションに対して、複数のトランクを選択できませんが、複数のロケーションに対して同じトランクを選択することはできます。
1 |
Log in to Control Hub at https://admin.webex.com, go to , and select Add Trunk. |
2 |
ロケーションを選択します。 |
3 |
トランクの名前を指定し、[保存] をクリックします。 名前は 24 文字以内にしてください。 |
次にやる必要
画面 [ドメインの登録]、[トランク グループ OTG/DTG]、[回線/ポート]、および [発信プロキシ アドレス] にトランク情報が表示されます。
プレミスベース PSTN を設定する準備ができているときに参照できるように、この情報を Control Hub からコピーして、ローカルのテキスト ファイルまたは文書に貼り付けておくことを推奨します。
この資格情報を紛失した場合には、Control Hub のトランク情報画面で生成する必要があります。[ユーザー名の取得とパスワードのリセット] をクリックして、トランクを使用するための認証資格情報の新しいセットを生成します。
1 |
Log in to Control Hub at https://admin.webex.com, go to . |
2 |
変更する場所を選択し、[管理] をクリックします。 |
3 |
プレミスベース PSTN を選択して、[次へ] をクリックします。 |
4 |
ドロップダウン メニューからトランクを選択します。 トランク ページにアクセスして、トランク グループの選択を管理します。 |
5 |
確認通知をクリックし、[保存] をクリックします。 |
次にやる必要
Control Hub が生成した構成情報を記録し、パラメーターをローカル ゲートウェイ (たとえばオンプレミスの Cisco CUBE) にマップする必要があります。This article walks you through this process. 参考のため、どのように Control Hub の構成情報 (左側) が CUBE のパラメーター (右側) にマップされるかを示す例である次の図を参照してください。
After you successfully complete the configuration on the gateway itself, you can return to
in Control Hub and the gateway that you created will be listed in the location card that you assigned it to with a green dot to the left of the name. このステータスは、ゲートウェイがセキュアに通話クラウドに対して登録され、そのロケーションでのアクティブな PSTN としての役割を果たしていることを示しています。Control Hub では、組織の電話番号を簡単に表示、アクティベート、削除、追加できます。詳細については、「Control Hub で電話番号を管理する」を参照してください。
Webex サービスを試していて、トライアルから有料サブスクリプションに変更したい場合は、メールでパートナーにリクエストできます。
1 |
Log in to Control Hub at https://admin.webex.com, select the building icon |
2 |
[サブスクリプション] タブを選択し、[今すぐ購入] をクリックします。 有料サブスクリプションへの変換に興味を持っていることを知らせるメールがパートナーに送信されます。 |
Control Hub を使用して、Webex アプリでユーザーに表示する利用可能な通話オプションの優先度を設定できます。シングルクリック通話を有効にすることもできます。詳細については、こちらを参照してください:Set calling options for Webex App users.
You can control what calling application opens when users make calls. You can configure the calling client settings, including mixed-mode deployment for organizations with users entitled with Unified CM or Webex Calling and users without paid calling services from Cisco. 詳細については、こちらを参照してください:Set up calling behavior.
Cisco IOS XE で Webex Calling のローカル ゲートウェイを構成する
概要
Webex Calling currently supports two versions of Local Gateway:
-
ローカル ゲートウェイ
-
Local Gateway for Webex for Government
-
Before you begin, understand the premises-based Public Switched Telephone Network (PSTN) and Local Gateway (LGW) requirements for Webex Calling. 詳細については 、「設定されたアーキテクチャ」Webex Calling を参照してください。
-
この記事では、専用のローカル ゲートウェイ プラットフォームが配置されているが、既存の音声構成がないと仮定しています。If you modify an existing PSTN gateway or CUBE Enterprise deployment to use as the Local Gateway function for Webex Calling, then pay careful attention to the configuration. Ensure that you don't interrupt the existing call flows and functionality because of the changes that you make.
For information on the supported third-party SBCs, refer to the respective product reference documentation.
システム トランクのローカル ゲートウェイを設定するための 2 つの Webex Calling があります。
-
登録ベースのトランク
-
証明書ベースのトランク
Use the task flow either under the Registration-based Local Gateway or Certificate-based Local Gateway to configure Local Gateway for your Webex Calling trunk.
See Get started with Local Gateway for more information on different trunk types. コマンドラインインターフェース (CLI) を使用して、ローカル ゲートウェイ自体で以下の手順を実行します。We use Session Initiation Protocol (SIP) and Transport Layer Security (TLS) transport to secure the trunk and Secure Real Time Protocol (SRTP) to secure the media between the Local Gateway and Webex Calling.
-
Select CUBE as your Local Gateway. Webex for Government doesn’t currently support any third-party Session Border Controllers (SBCs). To review the latest list, see Get started with Local Gateway.
- Install Cisco IOS XE Dublin 17.12.1a or later versions for all Webex for Government Local Gateways.
-
To review the list of root Certificate Authorities (CAs) that Webex for Government support, see Root certificate authorities for Webex for Government.
-
For details on the external port ranges for Local Gateway in Webex for Government, see Network requirements for Webex for Government (FedRAMP).
Local Gateway for Webex for Government doesn’t support the following:
-
STUN/ICE-Lite for media path optimization
-
Fax (T.38)
To configure Local Gateway for your Webex Calling trunk in Webex for Government, use the following option:
-
証明書ベースのトランク
Use the task flow under the Certificate-based Local Gateway to configure the Local Gateway for your Webex Calling trunk. For more details on how to configure a certificate-based Local Gateway, see Configure Webex Calling certificate-based trunk.
It’s mandatory to configure FIPS-compliant GCM ciphers to support Local Gateway for Webex for Government. If not, the call setup fails. For configuration details, see Configure Webex Calling certificate-based trunk.
This section describes how to configure a Cisco Unified Border Element (CUBE) as a Local Gateway for Webex Calling, using a registering SIP trunk. The first part of this document illustrates how to configure a simple PSTN gateway. In this case, all calls from the PSTN are routed to Webex Calling and all calls from Webex Calling are routed to the PSTN. The image below highlights this solution and the high-level call routing configuration that will be followed.
In this design, the following principal configurations are used:
-
voice class tenants: Used to create trunk specific configurations.
-
voice class uri: Used to classify SIP messages for the selection of an inbound dial-peer.
-
inbound dial-peer: Provides treatment for inbound SIP messages and determines the outbound route with a dial-peer group.
-
dial-peer group: Defines the outbound dial-peers used for onward call routing.
-
outbound dial-peer: Provides treatment for outbound SIP messages and routes them to the required target.
While IP and SIP have become the default protocols for PSTN trunks, TDM (Time Division Multiplexing) ISDN circuits are still widely used and are supported with Webex Calling trunks. To enable media optimization of IP paths for Local Gateways with TDM-IP call flows, it is currently necessary to use a two-leg call routing process. This approach modifies the call routing configuration shown above, by introducing a set of internal loop-back dial-peers between Webex Calling and PSTN trunks as illustrated in the image below.
When connecting an on-premises Cisco Unified Communications Manager solution with Webex Calling, you can use the simple PSTN gateway configuration as a baseline for building the solution illustrated in the following diagram. In this case, Unified Communications Manager provides centralized routing and treatment of all PSTN and Webex Calling calls.
Throughout this document, the host names, IP addresses, and interfaces illustrated in the following image are used.
Use the configuration guidance in the rest of this document to complete your Local Gateway configuration as follows:
-
ステップ1: Configure router baseline connectivity and security
-
ステップ2: Configure Webex Calling Trunk
Depending on your required architecture, follow either:
-
ステップ 3: Configure Local Gateway with SIP PSTN trunk
-
ステップ 4: Configure Local Gateway with existing Unified CM environment
または:
-
ステップ 3: Configure Local Gateway with TDM PSTN trunk
Baseline configuration
The first step in preparing your Cisco router as a Local Gateway for Webex Calling is to build a baseline configuration that secures your platform and establishes connectivity.
-
All registration-based Local Gateway deployments require Cisco IOS XE 17.6.1a or later versions. For the recommended versions, see the Cisco Software Research page. Search for the platform and select one of the suggested releases.
-
ISR4000 series routers must be configured with both Unified Communications and Security technology licenses.
-
Catalyst Edge 8000 series routers fitted with voice cards or DSPs require DNA Advantage licensing. Routers without voice cards or DSPs require a minimum of DNA Essentials licensing.
-
-
Build a baseline configuration for your platform that follows your business policies. In particular, configure the following and verify the working:
-
NTP
-
Acl
-
User authentication and remote access
-
DNS
-
IP ルーティング
-
IP addresses
-
-
The network toward Webex Calling must use an IPv4 address.
-
Upload the Cisco root CA bundle to the Local Gateway.
構成
1 |
Ensure that you assign valid and routable IP addresses to any Layer 3 interfaces, for example:
|
2 |
Protect registration and STUN credentials on the router using symmetric encryption. Configure the primary encryption key and encryption type as follows:
|
3 |
Create a placeholder PKI trustpoint. Requires this trustpoint to configure TLS later. For registration-based trunks, this trustpoint doesn't require a certificate - as would be required for a certificate-based trunk. |
4 |
Enable TLS1.2 exclusivity and specify the default trustpoint using the following configuration commands. Transport parameters should also be updated to ensure a reliable secure connection for registration: The cn-san-validate server command ensures that the Local Gateway permits a connection if the host name configured in tenant 200 is included in either the CN or SAN fields of the certificate received from the outbound proxy.
|
5 |
Install the Cisco root CA bundle, which includes the DigiCert CA certificate used by Webex Calling. Use the crypto pki trustpool import clean url command to download the root CA bundle from the specified URL, and to clear the current CA trustpool, then install the new bundle of certificates: If you need to use a proxy for access to the internet using HTTPS, add the following configuration before importing the CA bundle: ip http client proxy-server yourproxy.com proxy-port 80 |
1 |
Create a registration based PSTN trunk for an existing location in Control Hub. Make a note of the trunk information that is provided once the trunk has been created. These details, as highlighted in the following illustration, will be used in the configuration steps in this guide. For more information, see Configure trunks, route groups, and dial plans for Webex Calling. |
2 |
Enter the following commands to configure CUBE as a Webex Calling Local Gateway: 以下は、設定のフィールドの説明です。
Enables Cisco Unified Border Element (CUBE) features on the platform. media statisticsローカル ゲートウェイ上のメディア監視が可能です。 media bulk-stats一括通話統計のために、コントロール飛行機がデータ 飛行機をポーリングできます。 For more information on these commands, see Media. allow-connections sip to sipEnable CUBE basic SIP back-to-back user agent functionality. For more information, see Allow connections. By default, T.38 fax transport is enabled. For more information, see fax protocol t38 (voice-service). Enables STUN (Session Traversal of UDP through NAT) globally.
For more information, see stun flowdata agent-id and stun flowdata shared-secret. asymmetric payload fullConfigures SIP asymmetric payload support for both DTMF and dynamic codec payloads. For more information on this command, see asymmetric payload. early-offer forcedForces the Local Gateway to send SDP information in the initial INVITE message instead of waiting for acknowledgment from the neighboring peer. For more information on this command, see early-offer. |
3 |
Configure voice class codec 100 filter for the trunk. In this example, the same codec filter is used for all trunks. You can configure filters for each trunk for precise control. 以下は、設定のフィールドの説明です。 voice class codec 100Used to only allow preferred codecs for calls through SIP trunks. For more information, see voice class codec. Opus codec is supported only for SIP-based PSTN trunks. If the PSTN trunk uses a voice T1/E1 or analog FXO connection, exclude codec preference 1 opus from the voice class codec 100 configuration. |
4 |
Configure voice class stun-usage 100 to enable ICE on the Webex Calling trunk. 以下は、設定のフィールドの説明です。 stun usage ice liteUsed to enable ICE-Lite for all Webex Calling facing dial-peers to allow media-optimization whenever possible. For more information, see voice class stun usage and stun usage ice lite. You require stun usage of ICE-lite for call flows using media path optimization. To provide media-optimization for a SIP to TDM gateway, configure a loopback dial-peer with ICE-Lite enabled on the IP-IP leg. For further technical details, contact the Account or TAC teams |
5 |
Configure the media encryption policy for Webex traffic. 以下は、設定のフィールドの説明です。 voice class srtp-crypto 100Specifies SHA1_80 as the only SRTP cipher-suite CUBE offers in the SDP in offer and answer messages. Webex Calling only supports SHA1_80. For more information, see voice class srtp-crypto. |
6 |
Configure a pattern to uniquely identify calls to a Local Gateway trunk based on its destination trunk parameter: 以下は、設定のフィールドの説明です。 voice class uri 100 sipDefines a pattern to match an incoming SIP invite to an incoming trunk dial-peer. When entering this pattern, use dtg= followed by the Trunk OTG/DTG value provided in Control Hub when the trunk was created. For more information, see voice class uri. |
7 |
Configure sip profile 100, which will be used to modify SIP messages before they are sent to Webex Calling.
以下は、設定のフィールドの説明です。
|
8 |
Configure Webex Calling trunk: |
After you define tenant 100 and configure a SIP VoIP dial-peer, the gateway initiates a TLS connection toward Webex Calling. At this point the access SBC presents its certificate to the Local Gateway. The Local Gateway validates the Webex Calling access SBC certificate using the CA root bundle that was updated earlier. If the certificate is recognised, a persistent TLS session is established between the Local Gateway and Webex Calling access SBC. The Local Gateway is then able to use this secure connection to register with the Webex access SBC. When the registration is challenged for authentication:
-
The username, password, and realm parameters from the credentials configuration is used in the response.
-
The modification rules in sip profile 100 are used to convert SIPS URL back to SIP.
Registration is successful when a 200 OK is received from the access SBC.
Having built a trunk towards Webex Calling above, use the following configuration to create a non-encrypted trunk towards a SIP based PSTN provider:
If your Service Provider offers a secure PSTN trunk, you may follow a similar configuration as detailed above for the Webex Calling trunk. Secure to secure call routing is supported by CUBE.
If you are using a TDM / ISDN PSTN trunk, skip to next section Configure Local Gateway with TDM PSTN trunk.
To configure TDM interfaces for PSTN call legs on the Cisco TDM-SIP Gateways, see Configuring ISDN PRI.
1 |
Configure the following voice class uri to identify inbound calls from the PSTN trunk: 以下は、設定のフィールドの説明です。 voice class uri 200 sipDefines a pattern to match an incoming SIP invite to an incoming trunk dial-peer. When entering this pattern, use the IP address of you IP PSTN gateway. For more information, see voice class uri. |
2 |
Configure the following IP PSTN dial-peer: 以下は、設定のフィールドの説明です。 200 VoIP ダイヤル ピアを定義し、管理とトラブルシューティングを容易にするための意味のある説明を行います。For more information, see dial-peer voice. destination-pattern BAD.BADA dummy destination pattern is required when routing outbound calls using an inbound dial-peer group. For more information, see destination-pattern (interface). session protocol sipv2ダイヤルピア 200 が SIP コール のコールコールを処理する場合に指定します。For more information, see session protocol (dial peer). session target ipv4:192.168.80.13宛先のターゲット IPv4 アドレスを示し、コールレグを送信します。セッションのターゲットは ITSP の IP アドレスです。For more information, see session target (VoIP dial peer). incoming uri via 200VIA ヘッダーの判断基準を IP ヘッダーと IP アドレスPSTNを定義します。Matches all incoming IP PSTN call legs on the Local Gateway with dial-peer 200. For more information, see incoming url. bind control source-interface GigabitEthernet0/0/0Configures the source interface and associated IP address for messages sent to the PSTN. For more information, see bind. bind media source-interface GigabitEthernet0/0/0Configures the source interface and associated IP address for media sent to PSTN. For more information, see bind. voice-class codec 100Configures the dial-peer to use the common codec filter list 100. For more information, see voice-class codec. dtmf-relay rtp-nte通話レグで予想される DTMF 機能として RTP-NTE (RFC2833) を定義します。For more information, see DTMF Relay (Voice over IP). no vad音声アクティブティの検出を無効にします。For more information, see vad (dial peer). |
3 |
If you are configuring your Local Gateway to only route calls between Webex Calling and the PSTN, add the following call routing configuration. If you are configuring your Local Gateway with a Unified Communications Manager platform, skip to the next section. |
Having built a trunk towards Webex Calling, use the following configuration to create a TDM trunk for your PSTN service with loop-back call routing to allow media optimization on the Webex call leg.
1 |
The loop-back dial-peer configuration uses dial-peer groups and call routing tags to ensure that calls pass correctly between Webex and the PSTN, without creating call routing loops. Configure the following translation rules that will be used to add and remove the call routing tags: 以下は、設定のフィールドの説明です。 voice translation-ruleUses regular expressions defined in rules to add or remove call routing tags. Over-decadic digits (‘A’) are used to add clarity for troubleshooting. In this configuration, the tag added by translation-profile 100 is used to guide calls from Webex Calling towards the PSTN via the loopback dial-peers. Similarly, the tag added by translation-profile 200 is used to guide calls from the PSTN towards Webex Calling. Translation-profiles 11 and 12 remove these tags before delivering calls to the Webex and PSTN trunks respectively. This example assumes that called numbers from Webex Calling are presented in +E.164 format. Rule 100 removes the leading + to maintain a valid called number. Rule 12 then adds a national or international routing digit(s) when removing the tag. Use digits that suit your local ISDN national dial plan. If Webex Calling presents numbers in national format, adjust rules 100 and 12 to simply add and remove the routing tag respectively. For more information, see voice translation-profile and voice translation-rule. |
2 |
Configure TDM voice interface ports as required by the trunk type and protocol used. For more information, see Configuring ISDN PRI. For example, the basic configuration of a Primary Rate ISDN interface installed in NIM slot 2 of a device might include the following: |
3 |
Configure the following TDM PSTN dial-peer: 以下は、設定のフィールドの説明です。 200 VoIP ダイヤル ピアを定義し、管理とトラブルシューティングを容易にするための意味のある説明を行います。For more information, see dial-peer voice. destination-pattern BAD.BADA dummy destination pattern is required when routing outbound calls using an inbound dial-peer group. For more information, see destination-pattern (interface). translation-profile incoming 200Assigns the translation profile that will add a call routing tag to the incoming called number. direct-inward-dialRoutes the call without providing a secondary dial-tone. For more information, see direct-inward-dial. port 0/2/0:15The physical voice port associated with this dial-peer. |
4 |
To enable media optimization of IP paths for Local Gateways with TDM-IP call flows, you can modify the call routing by introducing a set of internal loop-back dial-peers between Webex Calling and PSTN trunks. Configure the following loop-back dial-peers. In this case, all incoming calls will be routed initially to dial-peer 10 and from there to either dial-peer 11 or 12 based on the applied routing tag. After removal of the routing tag, calls will be routed to the outbound trunk using dial-peer groups. 以下は、設定のフィールドの説明です。 Defines a VoIP dial-peer and gives a meaningful description for ease of management and troubleshooting. For more information, see dial-peer voice. translation-profile incoming 11Applies the translation profile defined earlier to remove the call routing tag before passing to the outbound trunk. destination-pattern BAD.BADA dummy destination pattern is required when routing outbound calls using an inbound dial-peer group. For more information, see destination-pattern (interface). session protocol sipv2Specifies that this dial-peer handles SIP call legs. For more information, see session protocol (dial peer). session target 192.168.80.14Specifies the local router interface address as the call target to loop-back. For more information, see session target (voip dial peer). bind control source-interface GigabitEthernet0/0/0Configures the source interface and associated IP address for messages sent through the loop-back. For more information, see bind. bind media source-interface GigabitEthernet0/0/0Configures the source interface and associated IP address for media sent through the loop-back. For more information, see bind. dtmf-relay rtp-nte通話レグで予想される DTMF 機能として RTP-NTE (RFC2833) を定義します。For more information, see DTMF Relay (Voice over IP). codec g711alaw Forces all PSTN calls to use G.711. Select a-law or u-law to match the companding method used by your ISDN service. no vad音声アクティブティの検出を無効にします。For more information, see vad (dial peer). |
5 |
Add the following call routing configuration: This concludes your Local Gateway configuration. Save the configuration and reload the platform if this is the first time CUBE features are configured.
|
The PSTN-Webex Calling configuration in the previous sections may be modified to include additional trunks to a Cisco Unified Communications Manager (UCM) cluster. In this case, all calls are routed via Unified CM. Calls from UCM on port 5060 are routed to the PSTN and calls from port 5065 are routed to Webex Calling. The following incremental configurations may be added to include this calling scenario.
When creating the Webex Calling trunk in Unified CM, ensure that you configure the incoming port in the SIP Trunk Security Profile settings to 5065. This allows incoming messages on port 5065 and populate the VIA header with this value when sending messages to the Local Gateway.
1 |
以下の音声クラス URI を設定: |
2 |
Configure the following DNS records to specify SRV routing to Unified CM hosts: IOS XE uses these records for locally determining target UCM hosts and ports. With this configuration, it is not required to configure records in your DNS system. If you prefer to use your DNS, then these local configurations are not required. 以下は、設定のフィールドの説明です。 The following command creates a DNS SRV resource record. Create a record for each UCM host and trunk: ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub5.mydomain.com _sip._udp.pstntocucm.io: SRV resource record name 2: The SRV resource record priority 1: The SRV resource record weight 5060: The port number to use for the target host in this resource record ucmsub5.mydomain.com: The resource record target host To resolve the resource record target host names, create local DNS A records. 例: ip host ucmsub5.mydomain.com 192.168.80.65 ip host: Creates a record in the local IOS XE database. ucmsub5.mydomain.com: The A record host name. 192.168.80.65: The host IP address. Create the SRV resource records and A records to reflect your UCM environment and preferred call distribution strategy. |
3 |
Configure the following dial-peers: |
4 |
Add call routing using the following configurations: |
診断署名 (DS) は、IOS XE ベースのローカル ゲートウェイで共通に観察される問題を積極的に検出し、イベントのメール、syslog、またはターミナル メッセージ通知を生成します。You can also install the DS to automate diagnostics data collection and transfer-collected data to the Cisco TAC case to accelerate resolution time.
診断署名 (DS) は、問題のトリガー イベントと問題を通知、トラブルシューティング、修正するために取られるアクションに関する情報を含む XML ファイルです。You can define the problem detection logic using syslog messages, SNMP events and through periodic monitoring of specific show command outputs.
アクションタイプには、show command 出力の収集が含まれます。
-
統合ログファイルの生成
-
Uploading the file to a user-provided network location such as HTTPS, SCP, FTP server.
TAC エンジニアは DS ファイルの作成者であり、整合性保護のためにデジタル署名します。各 DS ファイルには、システムによって割り当てられた固有の数値 ID があります。Diagnostic Signatures Lookup Tool (DSLT) is a single source to find applicable signatures for monitoring and troubleshooting various problems.
開始する前に:
-
DSLT からダウンロードした DS ファイルは 編集していない。変更するファイルは、整合性チェックエラーのためインストールに失敗します。
-
ローカル ゲートウェイがメール通知を送信するために必要な簡易メール転送プロトコル (SMTP) サーバー。
-
メール通知に安全な SMTP サーバーを使用する場合は、ローカル ゲートウェイが IOS XE 17.6.1 以上を実行中か確認してください。
前提条件
Local Gateway running IOS XE 17.6.1a or higher
-
診断署名はデフォルトで有効になっています。
-
Configure the secure email server to be used to send proactive notification if the device is running Cisco IOS XE 17.6.1a or higher.
configure terminal call-home mail-server <username>:<pwd>@<email server> priority 1 secure tls end
-
Configure the environment variable ds_email with the email address of the administrator to notify you.
configure terminal call-home diagnostic-signature environment ds_email <email address> end
The following shows an example configuration of a Local Gateway running on Cisco IOS XE 17.6.1a or higher to send the proactive notifications to tacfaststart@gmail.com using Gmail as the secure SMTP server:
We recommend you to use the Cisco IOS XE Bengaluru 17.6.x or later versions.
call-home mail-server tacfaststart:password@smtp.gmail.com priority 1 secure tls diagnostic-signature environment ds_email "tacfaststart@gmail.com"
Cisco IOS XE ソフトウェアで起動するローカル ゲートウェイは OAuth に対応する一般的なウェブベースの Gmail クライアントではないので、特定の Gmail アカウント設定を行い、端末からメールを正しく処理するための権限を与える必要があります:
-
Go to Less secure app access setting.
and turn on the -
「はい、はい、それは私です」と答えます。Gmail から「Google は、Google 以外のアプリを使用してアカウントにサインインするユーザーを防ぎました」というメールを受け取ります。
プロアクティブ モニタリングのために診断署名をインストールする
CPU 使用率の監視
This DS tracks CPU utilization for five seconds using the SNMP OID 1.3.6.1.4.1.9.2.1.56. 使用率が 75% 以上に達すると、すべてのデバッグを無効にし、ローカル ゲートウェイにインストールされている診断署名をアンインストールします。下記の手順を実行して署名をインストールします。
-
Use the show snmp command to enable SNMP. If you do not enable, then configure the snmp-server manager command.
show snmp %SNMP agent not enabled config t snmp-server manager end show snmp Chassis: ABCDEFGHIGK 149655 SNMP packets input 0 Bad SNMP version errors 1 Unknown community name 0 Illegal operation for community name supplied 0 Encoding errors 37763 Number of requested variables 2 Number of altered variables 34560 Get-request PDUs 138 Get-next PDUs 2 Set-request PDUs 0 Input queue packet drops (Maximum queue size 1000) 158277 SNMP packets output 0 Too big errors (Maximum packet size 1500) 20 No such name errors 0 Bad values errors 0 General errors 7998 Response PDUs 10280 Trap PDUs Packets currently in SNMP process input queue: 0 SNMP global trap: enabled
-
Diagnostic Signatures Lookup Tool の以下のドロップダウンオプションを使用して、DS 64224 をダウンロードします。
フィールド名
フィールド値
プラットフォーム
Cisco 4300, 4400 ISR Series or Cisco CSR 1000V Series
製品
Webex Calling ソリューションの CUBE Enterprise
問題の範囲
パフォーマンス
問題の種類
通知メールによる CPU 使用率が高い
-
DS XML ファイルをローカルゲートウェイフラッシュにコピーします。
LocalGateway# copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash:
次の例では、FTP サーバーからローカル ゲートウェイへのファイルのコピーを示しています。
copy ftp://user:pwd@192.0.2.12/DS_64224.xml bootflash: Accessing ftp://*:*@ 192.0.2.12/DS_64224.xml...! [OK - 3571/4096 bytes] 3571 bytes copied in 0.064 secs (55797 bytes/sec)
-
ローカルゲートウェイに DS XML ファイルをインストールします。
call-home diagnostic-signature load DS_64224.xml Load file DS_64224.xml success
-
show call-home diagnostic-signature コマンドを使用 して、署名が正常にインストールされたことを確認します。ステータス列の値が「registered」になっているはずです。
show call-home diagnostic-signature Current diagnostic-signature settings: Diagnostic-signature: enabled Profile: CiscoTAC-1 (status: ACTIVE) Downloading URL(s):https://tools.cisco.com/its/service/oddce/services/DDCEService Environment variable: 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 がアンインストールされます。If necessary, reinstall DS 64224 to continue monitoring high CPU utilization on the Local Gateway.
SIP トランク登録のモニタリング
この DS は、60 秒ごとにクラウドにSIP トランクするローカル Webex Calling登録解除をチェックします。Once the unregistration event is detected, it generates an email and syslog notification and uninstalls itself after two unregistration occurrences. Use the steps below to install the signature:
-
Diagnostic Signatures Lookup Tool の以下のドロップダウンオプションを使用して、DS 64117 をダウンロードします。
フィールド名
フィールド値
プラットフォーム
Cisco 4300、4400 ISR シリーズ、または Cisco CSR 1000V シリーズ
製品
Webex Calling ソリューションの CUBE Enterprise
問題の範囲
SIP-SIP
問題の種類
SIP トランクによる登録解除を行いました。
-
DS XML ファイルをローカルゲートウェイにコピーします。
copy ftp://username:password@<server name or ip>/DS_64117.xml bootflash:
-
ローカルゲートウェイに DS XML ファイルをインストールします。
call-home diagnostic-signature load DS_64117.xml Load file DS_64117.xml success LocalGateway#
-
show call-home diagnostic-signature コマンドを使用 して、署名が正常にインストールされたことを確認します。状態の列には「登録済み」の値が必要です。
異常な通話切断の監視
This DS uses SNMP polling every 10 minutes to detect abnormal call disconnect with SIP errors 403, 488 and 503. If the error count increment is greater than or equal to 5 from the last poll, it generates a syslog and email notification. Please use the steps below to install the signature.
-
Use the show snmp command to check whether SNMP is enabled. If it is not enabled, configure the snmp-server manager command.
show snmp %SNMP agent not enabled config t snmp-server manager end show snmp Chassis: ABCDEFGHIGK 149655 SNMP packets input 0 Bad SNMP version errors 1 Unknown community name 0 Illegal operation for community name supplied 0 Encoding errors 37763 Number of requested variables 2 Number of altered variables 34560 Get-request PDUs 138 Get-next PDUs 2 Set-request PDUs 0 Input queue packet drops (Maximum queue size 1000) 158277 SNMP packets output 0 Too big errors (Maximum packet size 1500) 20 No such name errors 0 Bad values errors 0 General errors 7998 Response PDUs 10280 Trap PDUs Packets currently in SNMP process input queue: 0 SNMP global trap: enabled
-
Diagnostic Signatures Lookup Tool の以下のオプションを使用して、DS 65221 をダウンロードします。
フィールド名
フィールド値
プラットフォーム
Cisco 4300、4400 ISR シリーズ、または Cisco CSR 1000V シリーズ
製品
Webex Calling ソリューションの CUBE Enterprise
問題の範囲
パフォーマンス
問題の種類
メールおよび Syslog 通知による SIP の異常通話切断検出
-
DS XML ファイルをローカルゲートウェイにコピーします。
copy ftp://username:password@<server name or ip>/DS_65221.xml bootflash:
-
ローカルゲートウェイに DS XML ファイルをインストールします。
call-home diagnostic-signature load DS_65221.xml Load file DS_65221.xml success
-
show call-home diagnostic-signature コマンドを使用 して、署名が正常にインストールされたことを確認します。状態の列には「登録済み」の値が必要です。
診断署名をインストールして問題のトラブルシューティングを行う
診断署名 (DS) を使用して、問題を迅速に解決します。Cisco TAC エンジニアは、特定の問題のトラブルシューティング、問題の発生を検出、診断データの正しいセットを収集し、データを Cisco TAC ケースに自動的に転送するために必要なデバッグを可能にするための署名を作成しました。Diagnostic Signatures (DS) eliminate the need to manually check for the problem occurrence and makes troubleshooting of intermittent and transient issues a lot easier.
診断署名ルックアップ ツールを使用して、適用可能な署名を見つけ、自己解決するためにインストールすることができます。または、サポート エンゲージメントの一部として、TAC エンジニアが推奨する署名をインストールできます。
以下の例は、「%VOICE_IEC-3-GW: CCAPI: Internal Error (call spike threshold): SYSLOG=1.1.181.1.29.0" syslog を使用して、以下の手順を使用して、診断データの収集を自動化します。
-
Configure an additional DS environment variable ds_fsurl_prefix which is the Cisco TAC file server path (cxd.cisco.com) to which the collected diagnostics data are uploaded. The username in the file path is the case number and the password is the file upload token which can be retrieved from Support Case Manager in the following command. The file upload token can be generated in the Attachments section of the Support Case Manager, as needed.
configure terminal call-home diagnostic-signature LocalGateway(cfg-call-home-diag-sign)environment ds_fsurl_prefix "scp://<case number>:<file upload token>@cxd.cisco.com" end
例:
call-home diagnostic-signature environment ds_fsurl_prefix " environment ds_fsurl_prefix "scp://612345678:abcdefghijklmnop@cxd.cisco.com"
-
Ensure that SNMP is enabled using the show snmp command. If it is not enabled, configure the snmp-server manager command.
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 ファイルをローカルゲートウェイにコピーします。
copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash: copy ftp://username:password@<server name or ip>/DS_65095.xml bootflash:
-
ローカルゲートウェイに、高 CPU モニタリング DS 64224、DS 65095 XML ファイルの順にインストールします。
call-home diagnostic-signature load DS_64224.xml Load file DS_64224.xml success call-home diagnostic-signature load DS_65095.xml Load file DS_65095.xml success
-
Verify that the signature is successfully installed using the show call-home diagnostic-signature command. 状態の列には「登録済み」の値が必要です。
show call-home diagnostic-signature Current diagnostic-signature settings: Diagnostic-signature: enabled Profile: CiscoTAC-1 (status: ACTIVE) Downloading URL(s):https://tools.cisco.com/its/service/oddce/services/DDCEService Environment variable: 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
診断署名の実行を確認します
In the following command, the “Status” column of the show call-home diagnostic-signature command changes to “running” while the Local Gateway executes the action defined within the signature.show call-home 診断署名 統計の出力は、診断署名が関心のあるイベントを検出してアクションを実行したかどうかを検証するための最適な方法です。「トリガーされた/Max/Deinstall」欄は、指定された署名がイベントをトリガーした回数、イベントを検出するために定義される最大回数、トリガーされたイベントの最大数を検出した後に署名が自身をインストールアンインストールするかどうかを示します。
show call-home diagnostic-signature Current diagnostic-signature settings: Diagnostic-signature: enabled
Profile: CiscoTAC-1 (status: ACTIVE)
Downloading URL(s):https://tools.cisco.com/its/service/oddce/services/DDCEService Environment variable: 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 名 |
Triggered/Max/Deinstall |
平均実行時間(秒) |
最長実行時間(秒) |
---|---|---|---|---|
64224 |
DS_LGW_CPU_MON75 |
0/0/N |
0.000 |
0.000 |
65095 |
DS_LGW_IEC_Call_spike_threshold |
1/20/Y |
23.053 |
23.053 |
診断署名通知メール送信されるコマンドには、問題の種類、デバイスの詳細、ソフトウェア バージョン、実行構成、与えられた問題のトラブルシューティングに関連するコマンド出力の表示など、重要な情報が含まれている必要があります。
診断署名をアンインストールする
トラブルシューティングのために診断署名を使用は、一般的に、いくつかの問題が発生した場合の検出後にアンインストールするために定義されます。If you want to uninstall a signature manually, retrieve the DS ID from the output of the show call-home diagnostic-signature command and run the following command:
call-home diagnostic-signature deinstall <DS ID>
例:
call-home diagnostic-signature deinstall 64224
診断署名検索ツールに定期的に新しい署名が追加されます。これは展開で一般的に見られる問題に基づいて行います。TAC では現在、新しいカスタム署名の作成リクエストをサポートしていません。
For better management of Cisco IOS XE Gateways, we recommend that you enroll and manage the gateways through the Control Hub. It is an optional configuration. When enrolled, you can use the configuration validation option in the Control Hub to validate your Local Gateway configuration and identify any configuration issues. Currently, only registration-based trunks support this functionality.
For more information, refer the following:
This section describes how to configure a Cisco Unified Border Element (CUBE) as a Local Gateway for Webex Calling, using certificate-based mutual TLS (mTLS) SIP trunk. The first part of this document illustrates how to configure a simple PSTN gateway. In this case, all calls from the PSTN are routed to Webex Calling and all calls from Webex Calling are routed to the PSTN. The following image highlights this solution and the high-level call routing configuration that will be followed.
In this design, the following principal configurations are used:
-
voice class tenants: Used to create trunk specific configurations.
-
voice class uri: Used to classify SIP messages for the selection of an inbound dial-peer.
-
inbound dial-peer: Provides treatment for inbound SIP messages and determines the outbound route with a dial-peer group.
-
dial-peer group: Defines the outbound dial-peers used for onward call routing.
-
outbound dial-peer: Provides treatment for outbound SIP messages and routes them to the required target.
While IP and SIP have become the default protocols for PSTN trunks, TDM (Time Division Multiplexing) ISDN circuits are still widely used and are supported with Webex Calling trunks. To enable media optimization of IP paths for Local Gateways with TDM-IP call flows, it is currently necessary to use a two-leg call routing process. This approach modifies the call routing configuration shown above, by introducing a set of internal loop-back dial-peers between Webex Calling and PSTN trunks as illustrated in the image below.
When connecting an on-premises Cisco Unified Communications Manager solution with Webex Calling, you can use the simple PSTN gateway configuration as a baseline for building the solution illustrated in the following diagram. In this case, Unified Communications Manager provides centralized routing and treatment of all PSTN and Webex Calling calls.
Throughout this document, the host names, IP addresses, and interfaces illustrated in the following image are used. Options are provided for public or private (behind NAT) addressing. SRV DNS records are optional, unless load balancing across multiple CUBE instances.
Use the configuration guidance in the rest of this document to complete your Local Gateway configuration as follows:
-
ステップ1: Configure router baseline connectivity and security
-
ステップ2: Configure Webex Calling Trunk
Depending on your required architecture, follow either:
-
ステップ 3: Configure Local Gateway with SIP PSTN trunk
-
ステップ 4: Configure Local Gateway with existing Unified CM environment
または:
-
ステップ 3: Configure Local Gateway with TDM PSTN trunk
Baseline configuration
The first step in preparing your Cisco router as a Local Gateway for Webex Calling is to build a baseline configuration that secures your platform and establishes connectivity.
-
All certificate-based Local Gateway deployments require Cisco IOS XE 17.9.1a or later versions. For the recommended versions, see the Cisco Software Research page. Search for the platform and select one of the suggested releases.
-
ISR4000 series routers must be configured with both Unified Communications and Security technology licenses.
-
Catalyst Edge 8000 series routers fitted with voice cards or DSPs require DNA Essentials licensing. Routers without voice cards or DSPs require a minimum of DNA Essentials licensing.
-
For high-capacity requirements, you may also require a High Security (HSEC) license and additional throughput entitlement.
Refer to Authorization Codes for further details.
-
-
Build a baseline configuration for your platform that follows your business policies. In particular, configure the following and verify the working:
-
NTP
-
Acl
-
User authentication and remote access
-
DNS
-
IP ルーティング
-
IP addresses
-
-
The network toward Webex Calling must use a IPv4 address. Local Gateway Fully Qualified Domain Names (FQDN) or Service Record (SRV) addresses must resolve to a public IPv4 address on the internet.
-
All SIP and media ports on the Local Gateway interface facing Webex must be accessible from the internet, either directly or via static NAT. Ensure that you update your firewall accordingly.
-
Install a signed certificate on the Local Gateway (the following provides detailed configuration steps).
-
A public Certificate Authority (CA) as detailed in What Root Certificate Authorities are Supported for Calls to Cisco Webex Audio and Video Platforms? must sign the device certificate.
-
The FQDN configured in the Control Hub when creating a trunk must be the Common Name (CN) or Subject Alternate Name (SAN) certificate of the router. 例:
-
If a configured trunk in the Control Hub of your organization has cube1.lgw.com:5061 as FQDN of the Local Gateway, then the CN or SAN in the router certificate must contain cube1.lgw.com.
-
If a configured trunk in the Control Hub of your organization has lgws.lgw.com as the SRV address of the Local Gateway(s) reachable from the trunk, then the CN or SAN in the router certificate must contain lgws.lgw.com. クライアント アドレスが 解決SRV (CNAME、A レコード、または IP アドレス) のレコードは、SAN ではオプションです。
-
Whether you use an FQDN or SRV for the trunk, the contact address for all new SIP dialogs from your Local Gateway uses the name configured in the Control Hub.
-
-
-
証明書がクライアントとサーバーの使用状況に対して署名済みである必要があります。
-
Upload the Cisco root CA bundle to the Local Gateway.
構成
1 |
Ensure that you assign valid and routable IP addresses to any Layer 3 interfaces, for example:
|
2 |
Protect STUN credentials on the router using symmetric encryption. Configure the primary encryption key and encryption type as follows: |
3 |
Create an encryption trustpoint with a certificate signed by your preferred Certificate Authority (CA). |
4 |
Authenticate your new certificate using your intermediate (or root) CA certificate, then import the certificate (Step 4). Enter the following exec or configuration command:
|
5 |
Import a signed host certificate using the following exec or configuration command:
|
6 |
Enable TLS1.2 exclusivity and specify the default trustpoint using the following configuration commands:
|
7 |
Install the Cisco root CA bundle, which includes the DigiCert CA certificate used by Webex Calling. Use the crypto pki trustpool import clean url command to download the root CA bundle from the specified URL, and to clear the current CA trustpool, then install the new bundle of certificates: If you need to use a proxy for access to the internet using HTTPS, add the following configuration before importing the CA bundle: ip http client proxy-server yourproxy.com proxy-port 80 |
1 |
Create a CUBE certificate-based PSTN trunk for an existing location in Control Hub. For more information, see Configure trunks, route groups, and dial plans for Webex Calling. Make a note of the trunk information that is provided once the trunk is created. These details, as highlighted in the following illustration, will be used in the configuration steps in this guide. |
2 |
Enter the following commands to configure CUBE as a Webex Calling Local Gateway: 以下は、設定のフィールドの説明です。
Enables Cisco Unified Border Element (CUBE) features on the platform. allow-connections sip to sipEnable CUBE basic SIP back to back user agent functionality. For more information, see Allow connections. By default, T.38 fax transport is enabled. For more information, see fax protocol t38 (voice-service). Enables STUN (Session Traversal of UDP through NAT) globally. These global stun commands are only required when deploying your Local Gateway behind NAT.
For more information, see stun flowdata agent-id and stun flowdata shared-secret. asymmetric payload fullConfigures SIP asymmetric payload support for both DTMF and dynamic codec payloads. For more information on this command, see asymmetric payload. early-offer forcedForces the Local Gateway to send SDP information in the initial INVITE message instead of waiting for acknowledgment from the neighboring peer. For more information on this command, see early-offer. sip-profiles inboundEnables CUBE to use SIP profiles to modify messages as they are received. Profiles are applied via dial-peers or tenants. |
3 |
Configure voice class codec 100 codec filter for the trunk. In this example, the same codec filter is used for all trunks. You can configure filters for each trunk for precise control. 以下は、設定のフィールドの説明です。 voice class codec 100Used to only allow preferred codecs for calls through SIP trunks. For more information, see voice class codec. Opus codec is supported only for SIP-based PSTN trunks. If the PSTN trunk uses a voice T1/E1 or analog FXO connection, exclude codec preference 1 opus from the voice class codec 100 configuration. |
4 |
Configure voice class stun-usage 100 to enable ICE on the Webex Calling trunk.(This step is not applicable for Webex for Government) 以下は、設定のフィールドの説明です。 stun usage ice liteUsed to enable ICE-Lite for all Webex Calling facing dial-peers to allow media-optimization whenever possible. For more information, see voice class stun usage and stun usage ice lite. The stun usage firewall-traversal flowdata command is only required when deploying your Local Gateway behind NAT. You require stun usage of ICE-lite for call flows using media path optimization. To provide media-optimization for a SIP to TDM gateway, configure a loopback dial-peer with ICE-Lite enabled on the IP-IP leg. For further technical details, contact the Account or TAC teams. |
5 |
Configure the media encryption policy for Webex traffic.(This step is not applicable for Webex for Government) 以下は、設定のフィールドの説明です。 voice class srtp-crypto 100Specifies SHA1_80 as the only SRTP cipher-suite CUBE offers in the SDP in offer and answer messages. Webex Calling only supports SHA1_80. For more information, see voice class srtp-crypto. |
6 |
Configure FIPS-compliant GCM ciphers (This step is applicable only for Webex for Government). 以下は、設定のフィールドの説明です。 voice class srtp-crypto 100Specifies GCM as the cipher-suite that CUBE offers. It is mandatory to configure GCM ciphers for Local Gateway for Webex for Government. |
7 |
Configure a pattern to uniquely identify calls to a Local Gateway trunk based on its destination FQDN or SRV: 以下は、設定のフィールドの説明です。 voice class uri 100 sipDefines a pattern to match an incoming SIP invite to an incoming trunk dial-peer. When entering this pattern, use LGW FQDN or SRV configured in Control Hub while creating a trunk. |
8 |
Configure SIP message manipulation profiles. If your gateway is configured with a public IP address, configure a profile as follows or skip to the next step if you are using NAT. In this example, cube1.lgw.com is the FQDN configured for the Local Gateway and "198.51.100.1" is the public IP address of the Local Gateway interface facing Webex Calling: 以下は、設定のフィールドの説明です。 rules 10 and 20To allow Webex to authenticate messages from your local gateway, the 'Contact' header in SIP request and responses messages must contain the value provisioned for the trunk in Control Hub. This will either be the FQDN of a single host, or the SRV domain name used for a cluster of devices. Skip the next step if you have configured your Local Gateway with public IP addresses. |
9 |
If your gateway is configured with a private IP address behind static NAT, configure inbound and outbound SIP profiles as follows. In this example, cube1.lgw.com is the FQDN configured for the Local Gateway, "10.80.13.12" is the interface IP address facing Webex Calling and "192.65.79.20" is the NAT public IP address. SIP profiles for outbound messages to Webex Calling
以下は、設定のフィールドの説明です。 rules 10 and 20To allow Webex to authenticate messages from your local gateway, the 'Contact' header in SIP request and responses messages must contain the value provisioned for the trunk in Control Hub. This will either be the FQDN of a single host, or the SRV domain name used for a cluster of devices. rules 30 to 81Convert private address references to the external public address for the site, allowing Webex to correctly interpret and route subsequent messages. SIP profile for inbound messages from Webex Calling 以下は、設定のフィールドの説明です。 rules 10 to 80Convert public address references to the configured private address, allowing messages from Webex to be correctly processed by CUBE. For more information, see voice class sip-profiles. |
10 |
Configure a SIP Options keepalive with header modification profile. 以下は、設定のフィールドの説明です。 voice class sip-options-keepalive 100Configures a keepalive profile and enters voice class configuration mode. You can configure the time (in seconds) at which an SIP Out of Dialog Options Ping is sent to the dial-target when the heartbeat connection to the endpoint is in UP or Down status. This keepalive profile is triggered from the dial-peer configured towards Webex. To ensure that the contact headers include the SBC fully qualified domain name, SIP profile 115 is used. Rules 30, 40, and 50 are required only when the SBC is configured behind static NAT. In this example, cube1.lgw.com is the FQDN selected for the Local Gateway and if static NAT is used, "10.80.13.12" is the SBC interface IP address towards Webex Calling and "192.65.79.20" is the NAT public IP address. |
11 |
Configure Webex Calling trunk: |
Having built a trunk towards Webex Calling above, use the following configuration to create a non-encrypted trunk towards a SIP based PSTN provider:
If your Service Provider offers a secure PSTN trunk, you may follow a similar configuration as detailed above for the Webex Calling trunk. Secure to secure call routing is supported by CUBE.
If you are using a TDM / ISDN PSTN trunk, skip to next section Configure Local Gateway with TDM PSTN trunk.
To configure TDM interfaces for PSTN call legs on the Cisco TDM-SIP Gateways, see Configuring ISDN PRI.
1 |
Configure the following voice class uri to identify inbound calls from the PSTN trunk: 以下は、設定のフィールドの説明です。 voice class uri 200 sipDefines a pattern to match an incoming SIP invite to an incoming trunk dial-peer. When entering this pattern, use the IP address of you IP PSTN gateway. For more information, see voice class uri. |
2 |
Configure the following IP PSTN dial-peer: 以下は、設定のフィールドの説明です。 200 VoIP ダイヤル ピアを定義し、管理とトラブルシューティングを容易にするための意味のある説明を行います。For more information, see dial-peer voice. destination-pattern BAD.BADA dummy destination pattern is required when routing outbound calls using an inbound dial-peer group. For more information, see destination-pattern (interface). session protocol sipv2ダイヤルピア 200 が SIP コール のコールコールを処理する場合に指定します。For more information, see session protocol (dial peer). session target ipv4:192.168.80.13宛先のターゲット IPv4 アドレスを示し、コールレグを送信します。セッションのターゲットは ITSP の IP アドレスです。For more information, see session target (VoIP dial peer). incoming uri via 200VIA ヘッダーの判断基準を IP ヘッダーと IP アドレスPSTNを定義します。Matches all incoming IP PSTN call legs on the Local Gateway with dial-peer 200. For more information, see incoming url. bind control source-interface GigabitEthernet0/0/0Configures the source interface and associated IP address for messages sent to the PSTN. For more information, see bind. bind media source-interface GigabitEthernet0/0/0Configures the source interface and associated IP address for media sent to PSTN. For more information, see bind. voice-class codec 100Configures the dial-peer to use the common codec filter list 100. For more information, see voice-class codec. dtmf-relay rtp-nte通話レグで予想される DTMF 機能として RTP-NTE (RFC2833) を定義します。For more information, see DTMF Relay (Voice over IP). no vad音声アクティブティの検出を無効にします。For more information, see vad (dial peer). |
3 |
If you are configuring your Local Gateway to only route calls between Webex Calling and the PSTN, add the following call routing configuration. If you are configuring your Local Gateway with a Unified Communications Manager platform, skip to the next section. |
Having built a trunk towards Webex Calling, use the following configuration to create a TDM trunk for your PSTN service with loop-back call routing to allow media optimization on the Webex call leg.
1 |
The loop-back dial-peer configuration uses dial-peer groups and call routing tags to ensure that calls pass correctly between Webex and the PSTN, without creating call routing loops. Configure the following translation rules that will be used to add and remove the call routing tags: 以下は、設定のフィールドの説明です。 voice translation-ruleUses regular expressions defined in rules to add or remove call routing tags. Over-decadic digits (‘A’) are used to add clarity for troubleshooting. In this configuration, the tag added by translation-profile 100 is used to guide calls from Webex Calling towards the PSTN via the loopback dial-peers. Similarly, the tag added by translation-profile 200 is used to guide calls from the PSTN towards Webex Calling. Translation-profiles 11 and 12 remove these tags before delivering calls to the Webex and PSTN trunks respectively. This example assumes that called numbers from Webex Calling are presented in +E.164 format. Rule 100 removes the leading + to maintain a valid called number. Rule 12 then adds a national or international routing digit(s) when removing the tag. Use digits that suit your local ISDN national dial plan. If Webex Calling presents numbers in national format, adjust rules 100 and 12 to simply add and remove the routing tag respectively. For more information, see voice translation-profile and voice translation-rule. |
2 |
Configure TDM voice interface ports as required by the trunk type and protocol used. For more information, see Configuring ISDN PRI. For example, the basic configuration of a Primary Rate ISDN interface installed in NIM slot 2 of a device might include the following: |
3 |
Configure the following TDM PSTN dial-peer: 以下は、設定のフィールドの説明です。 200 VoIP ダイヤル ピアを定義し、管理とトラブルシューティングを容易にするための意味のある説明を行います。For more information, see dial-peer voice. destination-pattern BAD.BADA dummy destination pattern is required when routing outbound calls using an inbound dial-peer group. For more information, see destination-pattern (interface). translation-profile incoming 200Assigns the translation profile that will add a call routing tag to the incoming called number. direct-inward-dialRoutes the call without providing a secondary dial-tone. For more information, see direct-inward-dial. port 0/2/0:15The physical voice port associated with this dial-peer. |
4 |
To enable media optimization of IP paths for Local Gateways with TDM-IP call flows, you can modify the call routing by introducing a set of internal loop-back dial-peers between Webex Calling and PSTN trunks. Configure the following loop-back dial-peers. In this case, all incoming calls will be routed initially to dial-peer 10 and from there to either dial-peer 11 or 12 based on the applied routing tag. After removal of the routing tag, calls will be routed to the outbound trunk using dial-peer groups. 以下は、設定のフィールドの説明です。 Defines a VoIP dial-peer and gives a meaningful description for ease of management and troubleshooting. For more information, see dial-peer voice. translation-profile incoming 11Applies the translation profile defined earlier to remove the call routing tag before passing to the outbound trunk. destination-pattern BAD.BADA dummy destination pattern is required when routing outbound calls using an inbound dial-peer group. For more information, see destination-pattern (interface). session protocol sipv2Specifies that this dial-peer handles SIP call legs. For more information, see session protocol (dial peer). session target 192.168.80.14Specifies the local router interface address as the call target to loop-back. For more information, see session target (voip dial peer). bind control source-interface GigabitEthernet0/0/0Configures the source interface and associated IP address for messages sent through the loop-back. For more information, see bind. bind media source-interface GigabitEthernet0/0/0Configures the source interface and associated IP address for media sent through the loop-back. For more information, see bind. dtmf-relay rtp-nte通話レグで予想される DTMF 機能として RTP-NTE (RFC2833) を定義します。For more information, see DTMF Relay (Voice over IP). codec g711alaw Forces all PSTN calls to use G.711. Select a-law or u-law to match the companding method used by your ISDN service. no vad音声アクティブティの検出を無効にします。For more information, see vad (dial peer). |
5 |
Add the following call routing configuration: This concludes your Local Gateway configuration. Save the configuration and reload the platform if this is the first time CUBE features are configured.
|
The PSTN-Webex Calling configuration in the previous sections may be modified to include additional trunks to a Cisco Unified Communications Manager (UCM) cluster. In this case, all calls are routed via Unified CM. Calls from UCM on port 5060 are routed to the PSTN and calls from port 5065 are routed to Webex Calling. The following incremental configurations may be added to include this calling scenario.
1 |
以下の音声クラス URI を設定: |
2 |
Configure the following DNS records to specify SRV routing to Unified CM hosts: IOS XE uses these records for locally determining target UCM hosts and ports. With this configuration, it is not required to configure records in your DNS system. If you prefer to use your DNS, then these local configurations are not required. 以下は、設定のフィールドの説明です。 The following command creates a DNS SRV resource record. Create a record for each UCM host and trunk: ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub5.mydomain.com _sip._udp.pstntocucm.io: SRV resource record name 2: The SRV resource record priority 1: The SRV resource record weight 5060: The port number to use for the target host in this resource record ucmsub5.mydomain.com: The resource record target host To resolve the resource record target host names, create local DNS A records. 例: ip host ucmsub5.mydomain.com 192.168.80.65 ip host: Creates a record in the local IOS XE database. ucmsub5.mydomain.com: The A record host name. 192.168.80.65: The host IP address. Create the SRV resource records and A records to reflect your UCM environment and preferred call distribution strategy. |
3 |
Configure the following dial-peers: |
4 |
Add call routing using the following configurations: |
診断署名 (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) is a single source to find applicable signatures for monitoring and troubleshooting various problems.
開始する前に:
-
DSLT からダウンロードした DS ファイルは 編集していない。変更するファイルは、整合性チェックエラーのためインストールに失敗します。
-
ローカル ゲートウェイがメール通知を送信するために必要な簡易メール転送プロトコル (SMTP) サーバー。
-
メール通知に安全な SMTP サーバーを使用する場合は、ローカル ゲートウェイが IOS XE 17.6.1 以上を実行中か確認してください。
前提条件
IOS XE 17.6.1 以上を実行するローカル ゲートウェイ
-
診断署名はデフォルトで有効になっています。
-
Configure the secure email server that you use to send proactive notification if the device is running IOS XE 17.6.1 or higher.
configure terminal call-home mail-server <username>:<pwd>@<email server> priority 1 secure tls end
-
通知する管理者 ds_email のメールアドレスを使用して、環境変数を設定します。
configure terminal call-home diagnostic-signature LocalGateway(cfg-call-home-diag-sign)environment ds_email <email address> end
プロアクティブ モニタリングのために診断署名をインストールする
CPU 使用率の監視
この DS は SNMP OID 1.3.6.1.4.1.9.2.1.56 を使用して 5 秒間の CPU 使用率を追跡します。使用率が 75% 以上に達すると、すべてのデバッグが無効し、ローカル ゲートウェイにインストールした診断署名をアンインストールします。下記の手順を実行して署名をインストールします。
-
コマンドを使用して SNMP を有効に設定し、 snmp を表示します。If SNMP is not enabled, then configure the snmp-server manager command.
show snmp %SNMP agent not enabled config t snmp-server manager end show snmp Chassis: ABCDEFGHIGK 149655 SNMP packets input 0 Bad SNMP version errors 1 Unknown community name 0 Illegal operation for community name supplied 0 Encoding errors 37763 Number of requested variables 2 Number of altered variables 34560 Get-request PDUs 138 Get-next PDUs 2 Set-request PDUs 0 Input queue packet drops (Maximum queue size 1000) 158277 SNMP packets output 0 Too big errors (Maximum packet size 1500) 20 No such name errors 0 Bad values errors 0 General errors 7998 Response PDUs 10280 Trap PDUs Packets currently in SNMP process input queue: 0 SNMP global trap: enabled
Diagnostic Signatures Lookup Tool の以下のドロップダウンオプションを使用して、DS 64224 をダウンロードします。
copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash:
フィールド名
フィールド値
プラットフォーム
Cisco 4300, 4400 ISR Series, or Catalyst 8000V Edge Software
対応製品
CUBE Enterprise in Webex Calling solution
問題の範囲
パフォーマンス
問題の種類
メール通知による高 CPU 使用率
-
DS XML ファイルをローカルゲートウェイフラッシュにコピーします。
copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash:
次の例では、FTP サーバーからローカル ゲートウェイへのファイルのコピーを示しています。
copy ftp://user:pwd@192.0.2.12/DS_64224.xml bootflash: Accessing ftp://*:*@ 192.0.2.12/DS_64224.xml...! [OK - 3571/4096 bytes] 3571 bytes copied in 0.064 secs (55797 bytes/sec)
-
ローカルゲートウェイに DS XML ファイルをインストールします。
call-home diagnostic-signature load DS_64224.xml Load file DS_64224.xml success
-
show call-home diagnostic-signature コマンドを使用 して、署名が正常にインストールされたことを確認します。状態の列には「登録済み」の値が必要です。
show call-home diagnostic-signature Current diagnostic-signature settings: Diagnostic-signature: enabled Profile: CiscoTAC-1 (status: ACTIVE) Downloading URL(s):https://tools.cisco.com/its/service/oddce/services/DDCEService Environment variable: 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 使用率の監視を続行してください。
異常な通話切断の監視
This DS uses SNMP polling every 10 minutes to detect abnormal call disconnect with SIP errors 403, 488 and 503. If the error count increment is greater than or equal to 5 from the last poll, it generates a syslog and email notification. Please use the steps below to install the signature.
-
コマンド show snmp を使用して、SNMP が有効 になっている必要があります。If SNMP is not enabled, configure the snmp-server manager command.
show snmp %SNMP agent not enabled config t snmp-server manager end show snmp Chassis: ABCDEFGHIGK 149655 SNMP packets input 0 Bad SNMP version errors 1 Unknown community name 0 Illegal operation for community name supplied 0 Encoding errors 37763 Number of requested variables 2 Number of altered variables 34560 Get-request PDUs 138 Get-next PDUs 2 Set-request PDUs 0 Input queue packet drops (Maximum queue size 1000) 158277 SNMP packets output 0 Too big errors (Maximum packet size 1500) 20 No such name errors 0 Bad values errors 0 General errors 7998 Response PDUs 10280 Trap PDUs Packets currently in SNMP process input queue: 0 SNMP global trap: enabled
-
Diagnostic Signatures Lookup Tool の以下のオプションを使用して、DS 65221 をダウンロードします。
フィールド名
フィールド値
プラットフォーム
Cisco 4300, 4400 ISR Series, or Catalyst 8000V Edge Software
製品
Webex Calling ソリューションの CUBE Enterprise
問題の範囲
パフォーマンス
問題の種類
メールおよび Syslog 通知による SIP の異常通話切断検出
-
DS XML ファイルをローカルゲートウェイにコピーします。
copy ftp://username:password@<server name or ip>/DS_65221.xml bootflash:
-
ローカルゲートウェイに DS XML ファイルをインストールします。
call-home diagnostic-signature load DS_65221.xml Load file DS_65221.xml success
-
Use the command show call-home diagnostic-signature to verify that the signature is successfully installed. ステータス列の値が「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 を使用して、以下の手順を使用して、診断データの収集を自動化します。
Configure another DS environment variable ds_fsurl_prefix as the Cisco TAC file server path (cxd.cisco.com) to upload the diagnostics data. The username in the file path is the case number and the password is the file upload token which can be retrieved from Support Case Manager as shown in the following. The file upload token can be generated in the Attachments section of the Support Case Manager, as required.
configure terminal call-home diagnostic-signature LocalGateway(cfg-call-home-diag-sign)environment ds_fsurl_prefix "scp://<case number>:<file upload token>@cxd.cisco.com" end
例:
call-home diagnostic-signature environment ds_fsurl_prefix " environment ds_fsurl_prefix "scp://612345678:abcdefghijklmnop@cxd.cisco.com"
-
コマンド show snmp を使用して、SNMP が有効 になっている必要があります。If SNMP not enabled, configure the snmp-server manager command.
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 Series, or Catalyst 8000V Edge Software
製品
Webex Calling ソリューションの CUBE Enterprise
問題の範囲
パフォーマンス
問題の種類
通知メールによる CPU 使用率が高い
-
Diagnostic Signatures Lookup Tool の以下のオプションを使用して、DS 65095 をダウンロードします。
フィールド名
フィールド値
プラットフォーム
Cisco 4300, 4400 ISR Series, or Catalyst 8000V Edge Software
製品
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 ファイルをローカルゲートウェイにコピーします。
copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash: copy ftp://username:password@<server name or ip>/DS_65095.xml bootflash:
-
Install the high CPU monitoring DS 64224 and then DS 65095 XML file in the Local Gateway.
call-home diagnostic-signature load DS_64224.xml Load file DS_64224.xml success call-home diagnostic-signature load DS_65095.xml Load file DS_65095.xml success
-
show call-home diagnostic-signature を使用して、署名が正常にインストールされていることを確認します。ステータス列の値が「registered」になっているはずです。
show call-home diagnostic-signature Current diagnostic-signature settings: Diagnostic-signature: enabled Profile: CiscoTAC-1 (status: ACTIVE) Downloading URL(s):https://tools.cisco.com/its/service/oddce/services/DDCEService Environment variable: 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
DS_LGW_IEC_Call_spike_threshold
0.0.12
登録済み
2020-11-08:00:12:53
診断署名の実行を確認します
次のコマンド で、ローカル ゲートウェイが署名内で定義されたアクションを実行する間、コマンドの「ステータス」列は「実行中」に変更されます。show-home 診断署名 統計の出力は、診断署名が関心のあるイベントを検出してアクションを実行したかどうかを検証するための最適な方法です。「トリガーされた/Max/Deinstall」欄は、指定された署名がイベントをトリガーした回数、イベントを検出するために定義される最大回数、トリガーされたイベントの最大数を検出した後に署名が自身をインストールアンインストールするかどうかを示します。
show call-home diagnostic-signature Current diagnostic-signature settings: Diagnostic-signature: enabled
Profile: CiscoTAC-1 (status: ACTIVE)
Downloading URL(s):https://tools.cisco.com/its/service/oddce/services/DDCEService Environment variable: 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 名 |
Triggered/Max/Deinstall |
平均実行時間(秒) |
最長実行時間(秒) |
---|---|---|---|---|
64224 |
DS_LGW_CPU_MON75 |
0/0/N |
0.000 |
0.000 |
65095 |
DS_LGW_IEC_Call_spike_threshold |
1/20/Y |
23.053 |
23.053 |
診断署名通知メール送信されるレポートには、問題の種類、デバイスの詳細、ソフトウェア バージョン、コンフィギュレーションの実行、および与えられた問題のトラブルシューティングに関連するコマンド出力の表示などの重要な情報が含されます。
診断署名をアンインストールする
トラブルシューティングのために診断署名を使用すると、一般的に、いくつかの問題が発生した場合の検出後にアンインストールするために定義されます。署名を手動でアンインストールする場合、show call-home diagnostic-signature の出力から DS ID を取得し、以下のコマンドを実行します。
call-home diagnostic-signature deinstall <DS ID>
例:
call-home diagnostic-signature deinstall 64224
診断署名ルックアップ ツールに、展開で見られる問題に基づいて、定期的に新しい署名が追加されます。TAC では現在、新しいカスタム署名の作成リクエストをサポートしていません。
ローカル ゲートウェイとして CUBE の高可用性を実装する
基礎
前提条件
Webex Calling のローカル ゲートウェイとして CUBE HA を展開する前に、以下の概念を深く理解するようにしてください。
-
ステートフル コール保持のための CUBE エンタープライズによるレイヤー 2 ボックス間冗長性
この記事で提供される構成ガイドラインは、既存の音声構成が設定されていない専用のローカル ゲートウェイ プラットフォームが使用されていることを前提としています。既存の CUBE エンタープライズ展開が、Cisco Webex Calling のローカル ゲートウェイ機能を使用するように変更されている場合、既存のコール フローと機能が中断されないようにして、CUBE HA 設計要件に準拠するように、設定に注意してください。
ハードウェアとソフトウェアのコンポーネント
ローカルゲートウェイとしての CUBE HA には IOS-XE バージョン 16.12.2 以降、および CUBE HA と LGW 機能の両方をサポートするプラットフォームが必要です。
この記事のコマンドとログの表示は、vCUBE(CSR1000v)で実装された Cisco IOS-XE 16.12.2 のソフトウェアの最小リリースに基づいています。
参考資料
さまざまなプラットフォーム向けの詳細な CUBE HA 設定ガイドを次に示します。
-
CSR 1000v (vCUBE)— https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-cube-high-availability-CSR1000v.html
-
Cisco Preferred Architecture for Cisco Webex Calling— https://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Collaboration/hybrid/AltDesigns/PA-WbxCall.pdf
Webex Calling ソリューションの概要
Cisco Webex Calling は、複数の PSTN オプションにより、オンプレミスの PBX 電話サービスにマルチテナントのクラウドベースの代替手段を提供するコラボレーションソリューションです。
この記事の焦点は、ローカル ゲートウェイの展開 (以下を参照) です。Webex Calling のローカルゲートウェイ(プレミスベースの PSTN)トランクによって、顧客が所有する PSTN サービスへの接続が可能になります。また、Cisco Unified CM などのオンプレミス IP PBX 展開への接続も提供します。クラウド間のすべての通信は、メディア向け SIP および SRTP で TLS トランスポートを使用してセキュリティ保護されています。
次の図では、既存の IP PBX なしでの Webex Calling 展開を示し、単一または複数サイトの展開に適用されます。この記事に記載されている設定は、この展開に基づいています。
レイヤー 2 のボックス間冗長性
CUBE HA レイヤー 2 ボックス間冗長性は、冗長性グループ (RG) インフラストラクチャ プロトコルを使用して、ルーターのアクティブ/スタンバイ ペアを形成します。このペアは、それぞれのインターフェイスで同じ仮想 IP アドレス (VIP) を共有し、ステータ スメッセージを継続的に交換します。CUBE セッションはルーターのペアリングのチェックポイントであり、アクティブ ルーターがサービスを停止した場合に、スタンバイ ルーターがすべての CUBE コール処理の責任を果たすことができるようになりました。その結果、シグナリングとメディアのステートフルな保持が可能になりました。
チェック ポイントは、メディア パケットのある接続されたコールに限定されます。転送中のコールはチェック ポイントではありません (たとえば、試行中または呼出状態)。
この記事では、CUBE HA は、ステートフルコール保持の CUBE ハイ アベイラビリティ (HA) レイヤー 2 ボックス間 (B2B) 冗長性を参照します。
IOS-XE 16.12.2 では、CUBE HA を Cisco Webex Calling トランク(プレミスベースの PSTN)展開のローカルゲートウェイとして展開できます。この記事では、設計の考慮事項と構成について説明します。この図は、Cisco Webex Calling トランク展開のローカルゲートウェイとしての一般的な CUBE HA 設定を示しています。
冗長性グループ インフラストラクチャ コンポーネント
冗長グループ (RG) インフラ コンポーネントは、2 つの CUBE 間でのボックス間通信インフラストラクチャのサポートを提供し、最終的に安定した冗長性の状態をネゴシエートします。このコンポーネントは次の機能も提供します。
-
2 つの CUBE 間で keepalive と hello メッセージを交換することで (コントロール インターフェイス)、各ルータの最終的な冗長状態をネゴシエートする HSRP のようなプロトコル。上の図の GigabitEthernet3です。
-
アクティブからスタンバイ ルータ (データ インターフェイス経由) への各コールに関して、シグナリングとメディアの状態をチェックするための転送メカニズム。上記の図の GigabitEthernet3です。
-
トラフィック インターフェイスの仮想 IP (VIP) インターフェイスの構成と管理 (複数のトラフィック インターフェイスは同じ RG グループを使用して構成できます)。GigabitEthernet 1 および 2 はトラフィック インターフェイスと見なされます。
この RG コンポーネントは、音声 B2B HA をサポートするように特別に構成する必要があります。
信号とメディアの両方に関する仮想 IP (VIP) アドレス管理
B2B HA は、冗長性を確保する際に VIP に依存します。CUBE HA ペアの両方の CUBE で VIP および関連する物理インターフェイスは、同じ LAN サブネット上に存在している必要があります。VIP の構成、および特定の音声アプリケーション (SIP) への VIP インターフェイスのバインドは、音声 B2B HA サポートに必須です。Unified CM、Webex Calling アクセス SBC、サービス プロバイダー、プロキシなどの外部デバイスは、CUBE HA ルーターを通過するコールの宛先 IP アドレスとして VIP を使用します。そのため、Webex Calling の観点から、CUBE HA ペアは単一のローカル ゲートウェイとして機能します。
確立されたコールのコール シグナリングおよび RTP セッション情報は、アクティブなルーターからスタンバイ ルーターへのチェックポイントです。アクティブ ルーターがダウンすると、スタンバイ ルーターが引き継ぎ、最初のルーターによって以前にルーティングされた RTP ストリームを継続して転送します。
フェイルオーバー時に一時的な状態のコールは、切り替え後には保存されません。たとえば、まだ完全に確立されていない、または転送や保留の機能により変更中のコールなどです。確立されたコールは、切り替え後に切断される場合があります。
コールのステートフル フェールオーバーのローカル ゲートウェイとして CUBE HA を使用するには、以下の要件があります。
-
CUBE HA は TDM またはアナログ インターフェイスを共存させることはできません
-
Gig1 および Gig2 はトラフィック (SIP/RTP) インターフェイス、Gig3 は冗長グループ (RG) コントロール/データ インターフェイスと呼ばれます
-
グループ id 1 とグループ id 2 を持つ同じレイヤー 2 ドメインに配置できる CUBE HA ペアは 2 つまでです。同じグループ ID で 2 つの HA ペアを構成する場合、RG コントロール/データ インターフェイスは異なるレイヤー 2 ドメイン (vlan、個別のスイッチ) に属している必要があります
-
ポート チャネルは、RG コントロール/データとトラフィック インターフェイスの両方でサポートされています
-
すべてのシグナリング/メディアは、仮想 IP アドレスから供給されます
-
プラットフォームが CUBE HA 関係にリロードされると、常にスタンバイとして起動します
-
すべてのインターフェイスの下位アドレス (Gig1、Gig2、Gig3) は、同じプラットフォームにある必要があります
-
冗長性インターフェイス識別子、rii は同じレイヤー 2 のペア/インターフェイスの組み合わせに対して固有である必要があります
-
両方の CUBE の構成は、物理構成を含む必要があり、同じ種類のプラットフォームと IOS-XE バージョンで実行されている必要があります
-
ループバック インターフェイスは、常に起動しているためバインドとして使用できません
-
複数のトラフィック (SIP/RTP) インターフェイス (Gig1、Gig2) では、インターフェイスのトラッキングが構成されている必要があります
-
CUBE-HA は、RG コントロール/データ リンク (Gig3) のクロスオーバー ケーブル接続ではサポートされていません
-
両方のプラットフォームは同一である必要があり、すべての同様のインターフェイスで CUBE HA が機能するように [物理スイッチ] を介して接続します。例: CUBE-1 と CUBE-2 の GE0/0/0 は同じスイッチ上で終了する必要があります
-
直接 CUBE 上で、またはいずれかの側のデータ HA で WAN を終了することができません
-
アクティブ/スタンバイは両方とも同じデータセンターにある必要があります
-
冗長性 (RG コントロール/データ、Gig3) に別の L3 インターフェイスを使用する必要があります。トラフィックに使用されるインターフェイスは、HA keepalives およびチェックポイントに使用できません
-
フェールオーバー時に、以前アクティブだった CUBE は、設計によって再読み込みされ、シグナリングとメディアを保持します
両方の CUBE で冗長性を構成する
HA ペアで使用し、仮想 IP を表示するために、両方の CUBE でレイヤー 2 ボックス間冗長性を構成する必要があります。
1 |
インターフェイスのステータスを追跡するために、グローバル レベルでインターフェイス トラッキングを構成します。
トラッキング CLI は、トラフィック インターフェイスがダウンした後、アクティブ ルートがアクティブな役割を果たすように、RG 内で音声トラフィックインターフェイスの状態を追跡するために使用されます。 | ||
2 |
アプリケーション冗長性サブモード下の VoIP HA で使用する RG を構成します。
この構成で使用されるフィールドの説明を次に示します。
| ||
3 |
CUBE アプリケーションのボックス間の冗長性を有効にします。
redundancy-group 1—Adding and removing this command requires a reload for the updated configuration to take effect. すべての構成が適用された後で、プラットフォームを再読み込みします。 | ||
4 |
以下に示すように、Gig1 と Gig2 インターフェイスをそれぞれの仮想 IP で構成し、冗長性インターフェイス識別子 (rii) を適用します。
この構成で使用されるフィールドの説明を次に示します。
| ||
5 |
最初の CUBE 構成を保存し、再読み込みします。 最後にリロードするプラットフォームは常にスタンバイです。
VCUBE-1 が完全に起動したら、 VCUBE-2 の構成を保存し、再読み込みします。
| ||
6 |
ボックス間の構成が期待どおりに機能していることを確認します。関連する出力は太字で強調表示されます。 VCUBE-2 を最後にリロードし、設計上の考慮事項に従います。最後にリロードするプラットフォームは常に [スタンバイ] 状態です。 |
両方の CUBE でローカル ゲートウェイを構成する
この例の構成では、Control Hub から以下のトランク情報を使用して、VCUBE-1、VCUBE-2 の両方のプラットフォームでローカルゲートウェイを構成しています。この設定のユーザー名とパスワードは以下のとおりです。
-
ユーザー名:Hussain1076_LGU
-
パスワード:lOV12MEaZx
1 |
クレデンシャルまたは共有秘密で使用する前に、以下のコマンドを使用して、設定キーがパスワードに対して作成されていることを確認してください。Type 6 パスワードは、AES 暗号化とこのユーザー定義の設定キーを使用して暗号化されます。
これは、上に表示されている Control Hub のパラメーターに基づき、両方のプラットフォームに適用し、保存し、リロードするローカ ルゲートウェイの構成です。SIP Digest credentials from Control Hub are highlighted in bold.
Show コマンド出力を表示するには、VCUBE-2 の後に VCUBE-1 をリロードし、VCUBE-1 をスタンバイ CUBE にして、VCUBE-2 をアクティブ CUBE にします。 |
2 |
任意の時点で、1 個のプラットフォームのみが、Webex Calling アクセス SBC を使用したローカル ゲートウェイとしてアクティブ登録を保持します。以下の show コマンドの出力を見てみましょう。 show redundancy application group 1 show sip-ua register status
From the output above, you can see that VCUBE-2 is the active LGW maintaining the registration with Webex Calling access SBC, whereas the output of the “show sip-ua register status” is blank in VCUBE-1 |
3 |
VCUBE-1 で次のデバッグを有効にします
|
4 |
この場合、アクティブ LGW、VCUBE-2 で次のコマンドを実行してフェールオーバーをシミュレートします。
アクティブからスタンバイ LGW への切り替えは、上記に一覧表示されている CLI に加えて、以下のシナリオで発生します。
|
5 |
VCUBE-1 が Webex Calling アクセス SBC に登録されているかどうかを確認します。VCUBE-2 は今すぐにリロードされます。
VCUBE-1 がアクティブ LGW になりました。 |
6 |
仮想 IP を通じて SIP REGISTER を Webex Calling に送信し、200 OK を受信する VCUBE-1 に関連するデバッグ ログを確認してください。
|
Webex Calling のために Unified CM を構成する
ローカル ゲートウェイへトランクするための SIP トランク セキュリティ プロファイルを構成する
ローカル ゲートウェイと PSTN ゲートウェイが同じデバイス上に存在する場合、Unified CM を有効にして、同じデバイスから発信された 2 個の異なるトラフィックの種類 (Webex と PSTN のコール) を区別し、これらのコール タイプに対して差別化されたクラスのサービスを適用する必要があります。この差別化されたコール処理は、Unified CM および結合されたローカル ゲートウェイと PSTN ゲートウェイ デバイスの 2 つのトランクをプロビジョニングすることで行われます。これは、2 つのトランクに異なる SIP リスニング ポートを必要とします。
次の設定でローカル ゲートウェイ トランクの専用の SIP トランク セキュリティ プロファイルを作成します。
|
ローカル ゲートウェイ トランクの SIP プロファイルを構成する
次の設定でローカル ゲートウェイ トランク用の専用の SIP プロファイルを作成します。
|
Webex からのコールのコール検索スペースを作成する
次の設定で Webex から発信されたコールのためのコール検索スペースを作成します。
最後のパーティション onNetRemote は、Intercluster Lookup Service (ILS) または Global Dialplan Replication (GDPR) を使用して、Unified CM クラスター間でルーティング情報が交換されるマルチクラスター環境でのみ使用されます。 |
Webex 間で SIP トランクを構成する
次の設定を使用して、ローカル ゲートウェイ経由での Webex 間のコールに SIP トランクを作成します。
|
Webex のルート グループを構成する
次の設定でルート グループを作成します。
|
Webex のルート リストを構成する
次の設定でルート リストを作成します。
|
Webex の移動先のパーティションを作成する
次の設定で Webex の移動先のパーティションを作成します。
|
次にやる必要
このパーティションは、Webex の宛先にアクセスする必要があるすべてのコール検索スペースに追加してください。このパーティションは、PSTN から Webex への発信がルーティングされるように、PSTN トランクの着信コール検索スペースとして使用されるコール検索スペースに特に追加する必要があります。
Webex の移動先のルート パターンを構成する
次の設定で Webex の各 DID 範囲のルート パターンを構成します。
|
Webex の簡略サイト間ダイヤル正規化を構成する
短縮されたサイト間ダイヤルが Webex に必要な場合は、Webex の各 ESB 範囲にダイヤル正規化パターンを設定します。
|
Webex Calling の機能をセットアップする
ハント グループをセットアップする
ハント グループは着信をグループのユーザーまたはワークスペースにルーティングします。グループ全体にルーティングするパターンを構成することもできます。
ハント グループのセットアップ方法の詳細については、「Cisco Webex Control Hub のハント グループ」を参照してください。
コール キューを作成する
コール キューを作成すれば、顧客の発信にすぐに応答がない場合、誰かが応答できるようになるまで自動応答にしたり、お詫びのメッセージや保留中の音楽が流れるようにしたりすることができます。
コール キューをセットアップおよび管理する方法の詳細については、「Cisco Webex Control Hub でコール キューを管理する」を参照してください。
レセプショニスト クライアントを作成する
お客様のフロントオフィスの担当者のニーズに対応します。ユーザーを電話のアテンダントとして設定すると、組織内の特定のユーザーに着信するコールをスクリーンできます。
レセプショニストクライアントのセットアップ方法と表示方法については、「Cisco Webex Control Hub のレセプショニストクライアント」を参照してください。
自動アテンダントを作成して管理する
セットアップ メニューと、応答サービス、ハント グループ、ボイスメール ボックスや実際のオペレーターなどへのルーティング機能によって、適切なあいさつを返すことができます。24 時間分のスケジュールを作成できます。あるいは、時間内か外かに応じて、異なるオプションを使うこともできます。
自動アテンダントの作成と管理の方法については、「Cisco Webex Control Hub で自動アテンダントを管理する」を参照してください。
ページング グループを構成する
グループ ページングは、特定のページング グループに割り当てられた番号または内線番号をダイヤルすることにより、最大 75 名のターゲット ユーザーに一方向通話を行うか、グループ ページングを行うことができるようにします。
ページング グループのセットアップ方法と編集方法の詳細については、「Cisco Webex Control Hub のページング グループを構成する」を参照してください。
コール ピックアップを設定する
ユーザーがそれぞれの通話に応答できるよう、コール ピックアップ グループを作成し、チームワークとコラボレーションを強化します。ユーザーをコールピックアップグループに追加しておけば、グループメンバーが席を離れていたり、電話中だったりした場合、別のメンバーが電話に出ることができます。
コールピックアップグループのセットアップ方法については 、「Cisco Webex Control Hub でのコールピックアップ」を参照してください。
コール パークをセットアップする
コール パークにより、ユーザーの定義されたグループは、コール パーク グループの他の利用可能なメンバーに対するコールをパークすることができます。パーク中のコールは、グループの他のメンバーが自分の電話で取ることができます。
コールパークのセットアップ方法の詳細については、「Cisco Webex Control Hub コールパーク」を参照してください。
ユーザーの割り込みを有効にする
1 |
https://admin.webex.comの顧客ビューから、[ ]の順に移動します。 |
2 |
ユーザーを選択し、[Calling] をクリックします。 |
3 |
[ユーザー権限間 ]セクションに移動し、[割り込み]を選択します。 |
4 |
トグルをオンにすると、他のユーザがこのユーザの進行中のコールに自分自身を追加できるようになります。 |
5 |
このユーザーがコールに割り込むときに他のユーザーにトーンを再生する場合は、[このユーザーがコールで割り込むときにトーンを再生 ] にチェックを入れます。 このユーザーがコールで割り込むときにトーンを再生する 設定は、Customer Experience BasicおよびEssentialsスーパーバイザの割り込み機能には適用されません。スーパーバイザでこのオプションを有効にした場合でも、スーパーバイザがコール キュー コールで割り込むと、システムはエージェントに通知トーンを再生しません。 スーパーバイザがコールに割り込むときにエージェントにトーンを再生する場合は、[エージェントの通知トーン] 設定を使用して有効にできます。詳細については、「Webex Customer Experience Basic 」または「Webex Customer Experience Essentials」の「キューの作成 」セクションを参照してください。 |
6 |
[保存] をクリックします。 |
ユーザーのプライバシーを有効にする
1 |
Control Hub にサインインし、[ ] の順に移動します。 |
2 |
ユーザーを選択し、[Calling] をクリックします。 |
3 |
[ユーザー間の権限 ]領域に移動し、[プライバシー]を選択します。 |
4 |
このユーザーに適切な [自動音声応答のプライバシー] 設定を選択します。
|
5 |
[プライバシーを有効にする] チェックボックスをオンにします。ドロップダウンリストからメンバーを選択しないことで、全員をブロックすることができます。または、このユーザーの回線ステータスを監視できるユーザー、ワークスペース、仮想回線を選択することもできます。 ロケーション管理者の場合、割り当てられたロケーションに関連するユーザー、ワークスペース、仮想回線だけがドロップダウン リストに表示されます。 [プライバシーを有効にする ] チェックボックスをオフにすると、全員が回線のステータスを監視できるようになります。 |
6 |
ダイレクト コール ピックアップと割り込みのプライバシーを有効にするには、[ダイレクト コール ピックアップと割り込みのプライバシーを強制 ] チェックボックスをオンにします。
|
7 |
[名前でメンバーを追加] から、電話回線のステータスを監視し、ダイレクト コール ピックアップと割り込みを呼び出せるユーザ、ワークスペース、仮想回線を選択します。 |
8 |
選択したメンバーをフィルタリングするには、[名前、番号、またはextでフィルタリング ]フィールドを使用します。 |
9 |
選択したすべてのメンバーを削除するには、[すべて削除 ]をクリックします。 個々のメンバーを削除するには、メンバー名の横にある[削除] をクリックします。 |
10 |
[保存] をクリックします。 |
モニタリングの設定
ユーザーの監視対象回線の最大数は 50 です。ただし、モニタリング リストを設定する際には、Webex Calling とネットワーク間の帯域幅に影響を与えるメッセージの数を考慮してください。また、ユーザの電話機の回線ボタンの数によって、最大監視回線を決定します。
1 |
https://admin.webex.comの顧客ビューから、[管理 ]に移動し、[ユーザー]をクリックします。 |
2 |
変更するユーザーを選択し、[Calling] をクリックします。 |
3 |
[ユーザー権限間 ] セクションに移動し、[モニタリング] を選択します。 |
4 |
次から選択します:
ユーザーモニタリングのために、[モニタリング対象の回線を追加(Add Monitored Line)] リストに仮想回線 を含めることができます。 |
5 |
このユーザーにパークされたコールを通知するかどうかを選択し、監視対象のユーザーまたはコール パーク内線を検索し、[保存] をクリックします。 Control Hub の監視回線リストは、ユーザーのデバイス上で表示される監視回線の順番に対応します。監視対象回線のリストをいつでも並べ替えることができます。 監視対象の回線に表示される名前は、ユーザ、ワークスペース、仮想回線の [発信者 ID 名(Caller ID First Name)] フィールドと [姓(Last Name)] フィールドに入力された名前です。 |
ユーザーのコール ブリッジ警告トーンを有効にする
スケジューリングを始める前に
1 |
Control Hub にサインインし、[ ] の順に移動します。 |
2 |
ユーザーを選択し、[通話] タブをクリックします。 |
3 |
[ユーザー権限間] に移動し、[コールブリッジ警告トーン] をクリックします。 |
4 |
[コールブリッジング警告トーン] をオンにして、[保存] をクリックします。 デフォルトでは、この機能は有効になっています。 MPP 共有回線のコール ブリッジングの詳細については、「マルチプラットフォーム デスク フォンの共有回線」を参照してください。 Webex アプリの共有回線でのコール ブリッジングの詳細については、「WebexApp の共有回線アピアランス」を参照してください。 |
ユーザーのためにホテリングをオンにする
1 |
https://admin.webex.comの顧客ビューから、[管理 ]に移動し、[ユーザー]を選択します。 |
2 |
ユーザーを選択し、[通話] タブをクリックします。 |
3 |
[ユーザー間の権限] セクションに移動し、[ホテリング ]を選択してトグルをオンにします。 |
4 |
[ホテリングロケーション ] 検索フィールドにホテリングホストの名前または番号を入力し、ユーザーに割り当てるホテリングホストを選択します。 選択できるホテリングホストは 1 つだけです。別のホテリング ホストを選択した場合、最初のホストは削除されます。 ロケーション管理者の場合、割り当てられたロケーションに関連するホテリング ホストのみを割り当てることができます。 |
5 |
ユーザーがホテリングホストに関連付けることができる時間を制限するには、[関連付け期間を制限 (Limit Association Period)] ドロップダウンからユーザーがホテリングホストを使用できる時間を選択します。 ユーザーは選択した時間の後に自動的にログアウトされます。 ユーザーに指定された制限関連付け期間が、選択したホテリングホストの制限関連付け期間を超えると、画面にエラーメッセージが表示されます。たとえば、ホテリング ホストの制限関連付け期間が 12 時間で、ユーザーの制限関連付け期間が 24 時間である場合、エラー メッセージが表示されます。この場合、ユーザーにより多くの時間が必要な場合は、ホテリングホストの制限関連期間を延長する必要があります。 |
6 |
[保存] をクリックします。 ユーザは、ユーザ ハブから使用するホテリング ホストを検索し、検索することもできます。詳細については、「どこからでも通話プロファイルにアクセスする」を参照してください。 |
Webex Calling の採用傾向と使用状況レポート
通話レポートを表示する
Control Hub の [アナリティクス] ページを使用して、ユーザーがどのように Webex Calling と Webex アプリ (エンゲージメント) を使用しているか、また、通話のメディア エクスペリエンスの質について洞察を得ることができます。Webex Calling アナリティクスにアクセスするには、Control Hub にサインインし、[アナリティクス ] に移動して [通話 ] タブを選択します。
1 |
通話履歴レポートの詳細については、Control Hub にサインインし、[ ] の順に移動します。 |
2 |
[通話履歴の詳細] を選択します。 専用インスタンスを使用する通話の詳細については、「専用インスタンスの分析」を参照してください。 |
3 |
メディア品質データにアクセスするには、Control Hub にサインインし、[Analytics ] に移動して [Calling] を選択します。 詳細については、「クラウド コラボレーション ポートフォリオのためのアナリティクス」を参照してください。
|
CScanツールを実行する
CScan は、Webex Calling へのネットワーク接続をテストするために設計されたネットワーク準備ツールです。
詳細については、「CScan を使用して Webex Calling ネットワークの品質をテストする」をご覧ください。 |
環境を準備する
一般的な前提条件
Webex Calling のローカル ゲートウェイを設定する前に、次のことを確認してください。
VoIP の原理についての基本的な知識があること
Cisco IOS-XE と IOS-XE 音声のコンセプトについて、基本的で実際的な知識があること
セッション開始プロトコル (SIP) の基本的な理解がある
導入モデルに Cisco Unified Communications Manager (Unified CM) が含まれている場合には、Unified CM についての基本的な理解があること
詳細については、『Cisco Unified Border Element (CUBE) Enterprise Configuration Guide』を参照してください。
ローカル ゲートウェイのハードウェアおよびソフトウェア的要件
展開に次のような 1 つ以上のローカル ゲートウェイがあることを確認します。
IP ベースの接続用 Cisco CUBE
TDM ベースの接続のための Cisco IOS ゲートウェイ
ローカル ゲートウェイは、自分のペースで Webex Calling に移行するのに役立ちます。 ローカル ゲートウェイは、既存のオンプレミス展開を Webex Calling と統合します。 既存の PSTN 接続を使用することもできます。 「ローカル ゲートウェイの使い方」を参照してください
ローカル ゲートウェイのライセンスに関する要件
CUBE コールライセンスは、ローカル ゲートウェイにインストールされている必要があります。 詳細については、Cisco Unified 境界要素の構成ガイドを参照してください。
ローカル ゲートウェイの認証およびセキュリティ的要件
Webex Calling は、安全な信号経路とメディアを必要とします。 ローカルゲートウェイは暗号化を行います。また、以下の手順に従って、TLS 接続をクラウド方向に確立する必要があります。
LGW は、Cisco PKI からの CA ルートバンドルで更新しておく必要があります
LGW を構成する際には、Control Hub のトランク構成ページから取得した一連の SIP ダイジェスト資格情報が使用されます(この手順は、この後の構成の一部です)
CA ルート バンドルは、提示された証明書を検証します
資格情報が要求されます (SIP ダイジェストにより提供されたもの)
クラウドは、どのローカル ゲートウェイがセキュアに登録されているかを識別します
ローカルゲートウェイのファイアウォール、NAT Traversal、メディアパス最適化の各要件
ほとんどの場合、ローカル ゲートウェイとエンドポイントは、NAT によるプライベート IP アドレスを使用して、内部の顧客ネットワークに配置することができます。 エンタープライズ ファイアウォールは、特定の IP アドレス/ポートに対する外向きトラフィック (SIP、RTP/UDP、HTTP) を許可していなければなりません。この点は、「ポート参照情報」で説明されています。
ICE でメディアパスの最適化を利用する場合、ローカルゲートウェイの Webex Calling に面しているインターフェイスには Webex Calling エンドポイントとの双方向の直接ネットワークパスが必要です。 エンドポイントが別のロケーションにあり、ローカルゲートウェイの Webex Calling に面しているインターフェイスとこのエンドポイントとの間に直接ネットワークパスがない場合、メディアパスの最適化を利用するには、ローカルゲートウェイとエンドポイント間の通話のために、Webex Calling に面しているインターフェイスに割り当てられたパブリック IP アドレスをローカルゲートウェイに設定する必要があります。 また、IOS-XE バージョン 16.12.5 を実行している必要があります。
組織のために Webex Calling を設定する
Webex Calling サービスを稼働させるための最初のステップは、初回セットアップ ウィザード (FTSW) を完了することです。 最初のロケーションの FTSW が完了した後では、追加のロケーションに対して完了する必要がありません。
1 | 受け取ったウェルカム メールのはじめにリンクをクリックします。 管理者のメール アドレスが、Control Hub へのサインインに自動的に使用されます。その際、管理者パスワードを作成するように求められます。 サインインすると、セットアップ ウィザードが自動的に開始します。 |
2 | 利用規約を見直して、承諾します。 |
3 | プランを見直して、[はじめに] をクリックします。 アカウント マネージャは FTSW の最初の手順をアクティブにする責任があります。 [使い始める] を選択した時に、「通話をセットアップできません」という通知を受け取った場合は、アカウント マネージャーに連絡してください。 |
4 | データ センターがマッピングする国を選択し、顧客の連絡先と顧客アドレス情報を入力します。 |
5 | [次へ: デフォルトのロケーション |
6 | 次のオプションから選択します:
セットアップ ウィザードを完了した後で、作成したロケーションにメイン番号を追加していることを確認してください。 |
7 | このロケーションに適用する次の選択を行います。
|
8 | [次へ] をクリックします。 |
9 | 利用可能な Cisco Webex SIP アドレスを入力し、[次へ] をクリックし、[完了] を選択します。 |
始める前に
新しいロケーションを作成するには、以下の情報を指定します。
ロケーションの住所
希望する電話番号(オプション)
1 | https://admin.webex.comでControl Hubにログインし、 。 新しいロケーションは、初回セットアップウィザードを使用して選択した国に対応する地域データセンターでホストされます。 |
2 | ロケーションを設定します。
|
3 | [保存]をクリックし、[はい/いいえ]を選択して、現在または後でロケーションに番号を追加します。 |
4 | 「はい」をクリックした場合は、次のいずれかのオプションを選択します。
PSTN オプションの選択は各ロケーション レベルで行います (各ロケーションには PSTN オプションが 1 つしかありません)。 展開に対して必要な数のオプションを組み合わせることができますが、各ロケーションには 1 つのオプションとなります。 PSTN オプションを選択してプロビジョニングしたら、ロケーションの PSTN プロパティで [管理] をクリックすると、オプションを変更できます。 ただし、Cisco PSTN などの一部のオプションは、別のオプションが割り当てられた後は使用できない場合があります。 サポート ケースを開いてご相談ください。 |
5 | 番号を今すぐに有効にするか、または後で有効にするかを選択します。 |
6 | 統合されていない CCP またはプレミス ベースの PSTN を選択した場合は、電話番号をコンマ区切り値として入力し、[検証] をクリックします。 特定のロケーションのための番号が追加されます。 有効なエントリは [検証済みの番号] フィールドに移動し、無効なエントリは [番号の追加] フィールドに残り、エラー メッセージが表示されます。 番号の書式は、ロケーションの所在する国に応じ、ダイヤリングに関する地元の要件に従って定められます。 たとえば、国コードが必要な場合には、コードを付けて入力することも、コードなしで入力してからコードが自動的に先頭に追加されるようにすることもできます。 |
7 | [保存] をクリックします。 |
次に行うこと
ロケーションを作成した後、そのロケーションの緊急 911 サービスを有効にすることができます。 詳細については「Webex Calling の RedSky 緊急 911 サービス」を参照してください。
始める前に
ロケーションに関連付けられているユーザーとワークスペースのリストを取得します。 これらのユーザーとワークスペースを削除する必要があります。
ドロップダウンメニューから、削除するロケーションを選択します。 ロケーションを削除する前に、このロケーションに関連付けられているすべての番号は、PSTN プロバイダーに戻されることに注意してください。つまり、これらの番号は所有しなくなります。
1 | https://admin.webex.comでControl Hubにログインし、 。 |
2 | クリック |
3 | [ロケーションの削除] を選択し、そのロケーションを削除することを確認します。 通常、ロケーションが完全に削除されるまで数分かかりますが、最大で 1 時間かかる場合があります。 ロケーション名の横にある |
PSTN のセットアップ、ロケーションの名前、タイムゾーン、言語は、作成後に変更できます。 新しい言語は新しいユーザーとデバイスにのみ適用されることに注意してください。 既存のユーザーおよびデバイスは古い言語を使用し続けます。
既存のロケーションについては、緊急時の 911 サービスを有効にすることができます。 詳細については「Webex Calling の RedSky 緊急 911 サービス」を参照してください。
1 | https://admin.webex.comでControl Hubにログインし、 。 ロケーションの隣に [注意(Caution)] 記号が表示されている場合、そのロケーションの電話番号がまだ設定されていないことを意味します。 その番号を設定するまで、コールを発信または受信できません。 |
2 | (オプション) [PSTN 接続] の下で、すでに設定されているものに応じて、[クラウド接続 PSTN] または [プレミスベースの PSTN](ローカル ゲートウェイ) のいずれかを選択します。 [管理] をクリックして設定を変更してから、[続行] を選択することにより、関連するリスクを承認します。 以下のオプションのいずれかを選択して、[保存] クリックします。
|
3 | ロケーションで、ドロップダウンリストから代表番号を選択し、そのロケーションのユーザーがコールを発信および受信できるようにします。 メイン番号を自動アテンダントに割り当てて、外部発信者がそのロケーションの Webex Calling ユーザーに連絡できるようにします。 そのロケーションの Webex Calling ユーザーは、発信時にこの番号を外部発信者 ID として使用することもできます。 |
4 | (オプション) [緊急コール] で[緊急時のロケーション識別子] を選択して、このロケーションに割り当てることができます。 この設定はオプションであり、必要な国でのみ適用されます。 一部の国では (例: フランス)は、緊急通報を行い、緊急当局が利用できるようにしたときに、セル無線システムがセルのIDを確立するための規制要件が存在します。 米国やカナダのような他の国々は、他の方法を用いて位置決定を実施しています。 詳細については、「強化された緊急コール」を参照してください。 緊急コール プロバイダーは、アクセス ネットワークに関する情報を必要とする場合があります。これは、新しいプライベート SIP 拡張ヘッダー P-Access-Network-Info を定義することによって実現されます。 ヘッダーにはアクセスネットワークに関する情報が格納されます。 ロケーションの緊急ロケーション識別子を設定すると、ロケーションの値が SIP メッセージの一部としてプロバイダーに送信されます。 緊急コール プロバイダーに連絡して、この設定が必要かどうかを確認し、緊急コール プロバイダーが提供する値を使用します。 |
5 | このロケーションでユーザーがボイスメールをチェックするために呼び出せる [ボイスメール番号] を選択します。 |
6 | (オプション) ロケーション ページの上部にある鉛筆アイコンをクリックし、必要に応じて [ロケーションの名前]、[アナウンス言語]、[メール言語]、[タイムゾーン]、[住所] を変更し、[保存] をクリックします。 [アナウンス言語] の変更は、このロケーションに追加された新規ユーザーや機能に対して直ちに有効になります。 既存のユーザーや機能のアナウンス言語も変更する必要がある場合は、プロンプトが表示されたら、[既存のユーザーとワークスペースの変更] または [既存機能の変更] を選択します。 [適用] をクリックします。 [タスク] ページで進捗状況を確認できます。 これが完了するまでは、これ以上変更を加えることはできません。 ロケーションの [タイム ゾーン] を変更しても、このロケーションに関連する機能のタイム ゾーンは更新されません。 自動アテンダント、ハント グループ、コール キューなどの機能のタイム ゾーンを編集するには、タイムゾーンを更新する特定の機能の [全般設定] エリアに移動し、そこで編集して保存します。 |
これらの設定は社内ダイヤルに適用されるものであり、最初のセットアップ ウィザードでも設定できます。 ダイヤル プランを変更すると、Control Hub の更新でこれらの変更を示す例番号が表示されます。
ロケーションに対する発信通話の権限を設定できます。 これらのステップをご覧になり、発信権限を設定してください。
1 | Control Hub にサインインし、 を選択してから、[内部ダイヤル]までスクロールします。 |
2 | 必要に応じて、次のオプションのダイヤル設定を行います。
|
3 | 特定の場所の内部ダイヤルを指定します。 通話]をクリックします。 [ダイヤル] までスクロールし、必要に応じて内部ダイヤルを変更します。 ]を選択し、リストからロケーションを選択して、[
|
4 | 特定のロケーションの外部ダイヤルを指定します。 通話]をクリックします。 [ダイヤル] までスクロールし、必要に応じて外部ダイヤルを変更します。 ]を選択し、リストからロケーションを選択して、[
ユーザーへの影響:
|
付加価値再販業者の場合、これらの手順を使用して Control Hub でローカル ゲートウェイの設定を開始できます。 このゲートウェイがクラウドに登録されると、Webex Calling の 1 つ以上のロケーションで使用して、エンタープライズ PSTN サービス プロバイダーへのルーティングを提供できます。
ローカル ゲートウェイがある場所は、ローカル ゲートウェイが他の場所で使用されているときには削除できません。
始める前に
ロケーションが追加されたら、ロケーションに対してプレミスベース PSTN を設定する前に、トランクを作成する必要があります。
それぞれについて、ロケーションと固有の設定および番号を作成します。 ロケーションはプレミスベース PSTN を追加する前に存在する必要があります。
Webex Calling でのプレミスベース PSTN (ローカル ゲートウェイ) 要件について理解しておいてください。
プレミスベース PSTN を持つロケーションに対して、複数のトランクを選択できませんが、複数のロケーションに対して同じトランクを選択することはできます。
1 | https://admin.webex.comでControl Hubにログインし、 ] を選択し、[トランクの追加] を選択します。 |
2 | ロケーションを選択します。 |
3 | トランクの名前を指定し、[保存] をクリックします。 名前は 24 文字以内にしてください。 |
次に行うこと
画面 [ドメインの登録]、[トランク グループ OTG/DTG]、[回線/ポート]、および [発信プロキシ アドレス] にトランク情報が表示されます。
プレミス ベースの PSTN を設定する準備ができたときに参照できるように、この情報を Control Hub からコピーして、ローカルのテキスト ファイルまたはドキュメントに貼り付けておくことをおすすめします。
資格情報を紛失した場合には、Control Hub のトランク情報画面で生成する必要があります。 [ユーザー名の取得とパスワードのリセット] をクリックして、トランクを使用するための認証資格情報の新しいセットを生成します。
1 | https://admin.webex.comでControl Hubにログインし、 。 |
2 | 変更する場所を選択し、[管理] をクリックします。 |
3 | プレミスベース PSTN を選択して、[次へ] をクリックします。 |
4 | ドロップダウン メニューからトランクを選択します。 トランク ページにアクセスして、トランク グループの選択を管理します。 |
5 | 確認通知をクリックし、[保存] をクリックします。 |
次に行うこと
Control Hub で生成された設定情報を記録し、パラメーターをローカル ゲートウェイ (たとえばオンプレミスの Cisco CUBE) にマップする必要があります。 この記事では、このプロセスについて順を追って説明します。 参考のため、次の図を参照して、どのように Control Hub の設定情報 (左側) が CUBE のパラメーター (右側) にマップされるかを確認してください。
ゲートウェイ自体の設定が正常に完了し、Control Hub の [サービス] > [通話] > [ロケーション] に戻ると、作成したゲートウェイが、名前の左側に緑色のドットが付けられてロケーション カードにリストされます。
このステータスは、ゲートウェイがセキュアに通話クラウドに対して登録され、そのロケーションでのアクティブな PSTN としての役割を果たしていることを示しています。Control Hub では、組織の電話番号を簡単に表示、アクティベート、削除、追加できます。 詳細については、「Control Hub で電話番号を管理する」を参照してください。
Webex サービスを試していて、トライアルから有料サブスクリプションに変更したい場合は、メールでパートナーにリクエストできます。
1 | https://admin.webex.comでControl Hubにログインし、建物のアイコンを選択します。 |
2 | [サブスクリプション] タブを選択し、[今すぐ購入] をクリックします。 有料サブスクリプションへの変換に興味を持っていることを知らせるメールがパートナーに送信されます。 |
Control Hub を使用して、Webex アプリでユーザーに表示する利用可能な通話オプションの優先度を設定できます。 シングルクリック通話を有効にすることもできます。 詳細については、「 Webex アプリ ユーザーの通話オプションを設定します。
ユーザーがコールを発信するときに、どの通話アプリケーションが開くかを制御できます。 Unified CM または Webex Calling の資格を持つユーザーを持つ組織と、Cisco の有料通話サービスを使用しないユーザーのための混合モード展開など、通話クライアント設定を構成できます。 詳細については、「 通話動作をセットアップします。
Cisco IOS XE で Webex Calling のローカル ゲートウェイを構成する
概要
Webex Calling は現在、ローカル ゲートウェイの 2 つのバージョンをサポートしています。
ローカル ゲートウェイ
政府版 Webex のローカル ゲートウェイ
開始する前に、Webex Calling のプレミスベースの公衆交換電話ネットワーク (PSTN) およびローカル ゲートウェイ (LGW) の要件を理解してください。 詳細については、 Cisco Preferred Architecture for Webex Calling を参照してください。
この記事では、専用のローカル ゲートウェイ プラットフォームが既存の音声設定なしで設置されていることを前提としています。 既存の PSTN ゲートウェイまたは CUBE エンタープライズ展開を Webex Calling のローカル ゲートウェイ機能として使用するように変更する場合は、設定に注意してください。 変更を行うため、既存のコール フローと機能を中断しないようにしてください。
サポートされているサードパーティ SBC の詳細については、各製品参照ドキュメントを参照してください。
Webex Calling トランクのローカル ゲートウェイを設定するには、次の 2 つのオプションがあります。
登録ベースのトランク
証明書ベースのトランク
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 Software Research」ページを参照してください。 プラットフォームを検索し、提案されたリリースのいずれかを選択します。
ISR4000 シリーズ ルータは、Unified Communications および Security テクノロジー ライセンスの両方で設定する必要があります。
Catalyst Edge 8000シリーズのルーターには、ボイスカードまたはDSPが装備されており、DNA Advantageライセンスが必要です。 ボイスカードやDSPのないルーターには、最低限のDNA Essentialsライセンスが必要です。
ビジネスポリシーに従うプラットフォームのベースライン設定を構築します。 特に、以下を設定し、作業を確認します。
NTP
ACLsについて
ユーザー認証とリモートアクセス
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 インポート クリーン 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-id」および「stun flowdata shared-secret」を参照してください。 非対称ペイロード フルDTMF と動的コーデック ペイロードの両方に対して SIP 非対称ペイロード サポートを設定します。 このコマンドの詳細については、非対称ペイロードを参照してください。 early-offer forcedローカル ゲートウェイは、隣接するピアからの確認を待つ代わりに、最初の INVITE メッセージで SDP 情報を送信するように強制します。 このコマンドの詳細については、早期提供を参照してください。 |
3 | を設定する 音声クラス コーデック 100 トランクのフィルタ。 この例では、すべてのトランクに同じコーデックフィルタが使用されます。 正確な制御のために各トランクにフィルタを設定できます。
設定フィールドの説明を次に示します。 音声クラス コーデック 100SIP トランクを介したコールの優先コーデックのみを許可するために使用されます。 詳細については、「音声クラスコーデック」を参照してください。 Opus コーデックは、SIP ベースの PSTN トランクでのみサポートされています。 PSTN トランクが音声 T1/E1 またはアナログ FXO 接続を使用している場合は、コーデックの設定 1 オプスから音声クラスコーデック 100の設定。 |
4 | を設定する 音声クラスの使い方 100 は、Webex Calling トランクで ICE を有効にします。
設定フィールドの説明を次に示します。 スタンの使用法 アイス ライトすべての Webex Calling のダイヤルピアに対して ICE-Lite を有効にして、可能な限り、メディア最適化を可能にするために使用。 詳細については、「voice class stun usage」および「stun usage ice lite」を参照してください。 メディア パスの最適化を使用したコール フローには、ICE-lite のスタン使用が必要です。 SIP から TDM ゲートウェイへのメディア最適化を提供するには、IP-IP レッグで ICE-Lite が有効になっているループバック ダイヤル ピアを設定します。 技術的な詳細は、アカウントまたはTACチームにお問い合わせください。 |
5 | Webex トラフィックのメディア暗号化ポリシーを設定します。
設定フィールドの説明を次に示します。 音声クラス srtp-crypto 100SDP の SRTP 暗号スイート CUBE オファーおよび応答メッセージの唯一の SRTP オファーとして SHA1_80 を指定します。 Webex Calling は SHA180 のみをサポートします。_ 詳細については、音声クラス srtp-crypto を参照してください。 |
6 | 宛先トランク パラメータに基づいて、ローカル ゲートウェイ トランクへのコールを一意に識別するパターンを設定します。
設定フィールドの説明を次に示します。 音声クラス uri 100 sip着信トランク ダイヤル ピアへの着信 SIP 招待と一致するパターンを定義します。 このパターンを入力する場合、トランクが作成されたときに、dtg= の後に Control Hub で提供されるトランク OTG/DTG 値を使用します。 詳細については、音声クラス uri を参照してください。 |
7 | を設定する sip プロファイル 100は、Webex Callingに送信される前にSIPメッセージを変更するために使用されます。
設定フィールドの説明を次に示します。
|
8 | Webex Calling トランクの設定: |
テナント を定義した後 100 および SIP VoIP ダイヤル ピアを設定すると、ゲートウェイは Webex Calling への TLS 接続を開始します。 この時点で、アクセス SBC はその証明書をローカル ゲートウェイに提示します。 ローカル ゲートウェイは、以前に更新された CA ルート バンドルを使用して、Webex Calling アクセス SBC 証明書を検証します。 証明書が認識されると、ローカル ゲートウェイと Webex Calling アクセス SBC の間で永続的な TLS セッションが確立されます。 ローカル ゲートウェイは、このセキュアな接続を使用して Webex アクセス SBC に登録できます。 登録が認証にチャレンジされた場合:
レスポンスには、クレデンシャル設定のusername、password、およびrealmパラメータが使用されます。
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ダイヤルピアを定義し、管理とトラブルシューティングを容易にするための意味のある説明を提供します。 詳細については、ダイヤルピアの音声を参照してください。 destination-pattern BAD.BAD着信ダイヤル ピア グループを使用して発信コールをルーティングする場合は、ダミー接続先パターンが必要です。 詳細については、destination-pattern (interface)を参照してください。 session protocol sipv2ダイヤルピア 200 が SIP コール レッグを処理するように指定します。 詳細については、セッションプロトコル (ダイヤルピア)を参照してください。 session target ipv4:192.168.80.13コール レッグを送信する宛先のターゲット IPv4 アドレスを示します。 ここでのセッションのターゲットは、ITSP の IP アドレスです。 詳細については、セッションターゲット (VoIP ダイヤルピア)を参照してください。 200 経由で 着信 uriVIA ヘッダーと IP PSTN の IP アドレスの一致基準を定義します。 ローカル ゲートウェイのすべての着信 IP PSTN コール レッグとダイヤル ピア 200 を一致させます。 詳細については、着信 URLを参照してください。 バインド制御ソースインタフェース GigabitEthernet0/0/0PSTN に送信されるメッセージのソース インターフェイスと関連する 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 トランクを作成します。
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-profile」および「voice translation-rule」を参照してください。 |
2 | 使用するトランク タイプとプロトコルによって必要に応じて、TDM 音声インターフェイス ポートを設定します。 詳細については、「ISDN PRIの設定」を参照してください。 たとえば、デバイスの NIM スロット 2 にインストールされているプライマリレート ISDN インターフェイスの基本設定には、次のものが含まれます。
|
3 | 次の TDM PSTN ダイヤル ピアを設定します。
設定フィールドの説明を次に示します。
タグ 200 で VoIP ダイヤル ピアを定義し、管理とトラブルシューティングを容易にするための意味のある説明を提供します。 詳細については、「ダイヤルピアの音声」を参照してください。 destination-pattern BAD.BAD着信ダイヤル ピア グループを使用して発信コールをルーティングする場合は、ダミー接続先パターンが必要です。 詳細については、destination-pattern (interface)を参照してください。 翻訳プロファイル着信 200着信着信番号にコール ルーティング タグを追加するトランスレーション プロファイルを割り当てます。 ダイレクト インワード ダイヤルセカンダリ ダイヤル トーンを提供せずにコールをルーティングします。 詳細は、ダイレクト インワード ダイヤルを参照してください。 ポート 0/2:0:15このダイヤル ピアに関連付けられている物理的な音声ポート。 |
4 | TDM-IP コール フローでローカル ゲートウェイの IP パスのメディア最適化を有効にするには、Webex Calling と PSTN トランクの間に一連の内部ループ バック ダイヤル ピアを導入して、コール ルーティングを変更できます。 次のループバックダイヤルピアを設定します。 この場合、すべての着信コールは最初にダイヤルピア 10 にルーティングされ、そこから適用されたルーティング タグに基づいてダイヤルピア 11 または 12 にルーティングされます。 ルーティング タグを削除すると、コールはダイヤル ピア グループを使用して発信トランクにルーティングされます。
設定フィールドの説明を次に示します。
VoIP ダイヤル ピアを定義し、管理とトラブルシューティングを容易にするための意味のある説明を提供します。 詳細については、「ダイヤルピアの音声」を参照してください。 翻訳プロファイル着信 11先に定義したトランスレーション プロファイルを適用して、発信トランクに渡す前にコール ルーティング タグを削除します。 destination-pattern BAD.BAD着信ダイヤル ピア グループを使用して発信コールをルーティングする場合は、ダミー接続先パターンが必要です。 詳細については、destination-pattern (interface)を参照してください。 session protocol sipv2このダイヤル ピアが SIP コール レッグを処理することを指定します。 詳細については、セッションプロトコル (ダイヤルピア)を参照してください。 セッションのターゲット 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 コマンド出力の収集が含まれます。
統合ログ ファイルの生成
HTTPS、SCP、FTP サーバなどのユーザー提供のネットワークロケーションにファイルをアップロードします。
TAC エンジニアは DS ファイルを作成し、完全性保護のためにデジタル署名します。 各 DS ファイルには、システムによって割り当てられた固有の数値 ID があります。 Diagnostic Signatures Lookup Tool (DSLT)は、さまざまな問題を監視およびトラブルシューティングするための適切な署名を見つけるための単一のソースです。
開始する前に:
DSLTからダウンロードしたDSファイルは編集しないでください。 整合性チェックエラーのために修正したファイルはインストールに失敗します。
ローカル ゲートウェイがメール通知を送信するために必要な Simple Mail Transfer Protocol(SMTP)サーバー。
メール通知にセキュアな SMTP サーバを使用する場合は、ローカル ゲートウェイが IOS XE 17.6.1 以降を実行していることを確認します。
前提条件
IOS XE 17.6.1a 以降を実行しているローカル ゲートウェイ
診断署名はデフォルトで有効になっています。
デバイスが Cisco IOS XE 17.6.1a 以降を実行している場合、プロアクティブな通知を送信するために使用する、セキュアな電子メールサーバを設定します。
configure terminal call-home mail-server <username>:<pwd>@<email server> priority 1 secure tls end
通知する管理者のメール アドレスで環境変数 ds_email を設定します。
configure terminal call-home diagnostic-signature environment ds_email <email address> end
以下は、Cisco IOS XE 17.6.1a 以降で実行されているローカル ゲートウェイの設定例で、プロアクティブな通知をtacfaststart@gmail.com 安全なSMTPサーバーとしてGmailを使用:
Cisco IOS XE Bengaluru 17.6.x 以降のバージョンを使用することをお勧めします。
call-home
mail-server tacfaststart:password@smtp.gmail.com priority 1 secure tls
diagnostic-signature
environment ds_email "tacfaststart@gmail.com"
Cisco IOS XE Software で実行されているローカル ゲートウェイは、OAuth をサポートする典型的な Web ベースの Gmail クライアントではないため、特定の Gmail アカウント設定を構成し、デバイスからのメールを正しく処理するための特定の権限を提供する必要があります。
安全性の低いアプリアクセス]設定をオンにします。
を選択し、[Gmailから「GoogleがGoogle以外のアプリを使用してアカウントにサインインできないようにしました」というメールを受け取ったら、「はい、私でした」と回答してください。
プロアクティブなモニタリングのための診断署名のインストール
高いCPU使用率のモニタリング
この DS は、SNMP OID 1.3.6.1.4.1.9.2.1.56 を使用して、CPU 使用率を 5 秒間追跡します。 使用率が 75% 以上になると、すべてのデバッグが無効になり、ローカル ゲートウェイにインストールされているすべての診断シグネチャがアンインストールされます。 下記の手順を実行して署名をインストールします。
を使用する SNMPを表示 コマンドで SNMP を有効にします。 有効にしない場合は、snmpサーバーマネージャ コマンド
show snmp %SNMP agent not enabled config t snmp-server manager end show snmp Chassis: ABCDEFGHIGK 149655 SNMP packets input 0 Bad SNMP version errors 1 Unknown community name 0 Illegal operation for community name supplied 0 Encoding errors 37763 Number of requested variables 2 Number of altered variables 34560 Get-request PDUs 138 Get-next PDUs 2 Set-request PDUs 0 Input queue packet drops (Maximum queue size 1000) 158277 SNMP packets output 0 Too big errors (Maximum packet size 1500) 20 No such name errors 0 Bad values errors 0 General errors 7998 Response PDUs 10280 Trap PDUs Packets currently in SNMP process input queue: 0 SNMP global trap: enabled
Diagnostic Signatures Lookup Tool の以下のドロップダウンオプションを使用して、DS 64224 をダウンロードします。
フィールド名
フィールド値
プラットフォーム
Cisco 4300、4400 ISR シリーズ、または Cisco CSR 1000V シリーズ
製品
Webex Calling ソリューションの CUBE Enterprise
問題の範囲
パフォーマンス
問題の種類
メール通知による高い CPU 使用率。
DS XML ファイルをローカルゲートウェイフラッシュにコピーします。
LocalGateway# copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash:
次の例では、FTP サーバからローカル ゲートウェイにファイルをコピーしています。
copy ftp://user:pwd@192.0.2.12/DS_64224.xml bootflash: Accessing ftp://*:*@ 192.0.2.12/DS_64224.xml...! [OK - 3571/4096 bytes] 3571 bytes copied in 0.064 secs (55797 bytes/sec)
ローカルゲートウェイに DS XML ファイルをインストールします。
call-home diagnostic-signature load DS_64224.xml Load file DS_64224.xml success
を使用する コールホーム診断署名を表示コマンドを使用して、署名が正常にインストールされていることを確認します。 ステータス列の値が「registered」になっているはずです。
show call-home diagnostic-signature Current diagnostic-signature settings: Diagnostic-signature: enabled Profile: CiscoTAC-1 (status: ACTIVE) Downloading URL(s): https://tools.cisco.com/its/service/oddce/services/DDCEService Environment variable: 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 は、Webex Calling クラウドを使用したローカル ゲートウェイ SIP トランクの登録解除を 60 秒ごとにチェックします。 登録解除イベントが検出されると、メールと syslog 通知が生成され、登録解除イベントが 2 回発生した後にアンインストールされます。 署名をインストールするには、以下の手順を使用します。
Diagnostic Signatures Lookup Tool の以下のドロップダウンオプションを使用して、DS 64117 をダウンロードします。
フィールド名
フィールド値
プラットフォーム
Cisco 4300、4400 ISR シリーズ、または Cisco CSR 1000V シリーズ
製品
Webex Calling ソリューションの CUBE Enterprise
問題の範囲
SIP-SIP
問題の種類
メール通知による SIP トランクの登録解除。
DS XML ファイルをローカルゲートウェイにコピーします。
copy ftp://username:password@<server name or ip>/DS_64117.xml bootflash:
ローカルゲートウェイに DS XML ファイルをインストールします。
call-home diagnostic-signature load DS_64117.xml Load file DS_64117.xml success LocalGateway#
を使用する コールホーム診断署名を表示コマンドを使用して、署名が正常にインストールされていることを確認します。 ステータス列には「登録済み」の値が必要です。
異常な通話切断のモニタリング
この DS は、10 分おきに SNMP ポーリングを使用して、SIP エラー 403、488、503 の異常な通話切断を検出します。 エラー数の増加が前回の投票から 5 以上である場合、syslog とメール通知が生成されます。 下記の手順を実行して、署名をインストールしてください。
を使用する SNMPを表示 コマンドを使用して、SNMP が有効になっているかどうかを確認します。 有効になっていない場合は、snmpサーバーマネージャ コマンド
show snmp %SNMP agent not enabled config t snmp-server manager end show snmp Chassis: ABCDEFGHIGK 149655 SNMP packets input 0 Bad SNMP version errors 1 Unknown community name 0 Illegal operation for community name supplied 0 Encoding errors 37763 Number of requested variables 2 Number of altered variables 34560 Get-request PDUs 138 Get-next PDUs 2 Set-request PDUs 0 Input queue packet drops (Maximum queue size 1000) 158277 SNMP packets output 0 Too big errors (Maximum packet size 1500) 20 No such name errors 0 Bad values errors 0 General errors 7998 Response PDUs 10280 Trap PDUs Packets currently in SNMP process input queue: 0 SNMP global trap: enabled
Diagnostic Signatures Lookup Tool の以下のオプションを使用して、DS 65221 をダウンロードします。
フィールド名
フィールド値
プラットフォーム
Cisco 4300、4400 ISR シリーズ、または Cisco CSR 1000V シリーズ
製品
Webex Calling ソリューションの CUBE Enterprise
問題の範囲
パフォーマンス
問題の種類
電子メールおよび Syslog 通知による SIP 異常な通話切断検出。
DS XML ファイルをローカルゲートウェイにコピーします。
copy ftp://username:password@<server name or ip>/DS_65221.xml bootflash:
ローカルゲートウェイに DS XML ファイルをインストールします。
call-home diagnostic-signature load DS_65221.xml Load file DS_65221.xml success
を使用する コールホーム診断署名を表示コマンドを使用して、署名が正常にインストールされていることを確認します。 ステータス列には「登録済み」の値が必要です。
診断署名をインストールして問題をトラブルシューティング
診断署名(DS)を使用して、問題を迅速に解決します。 Cisco TAC エンジニアは、特定の問題のトラブルシューティング、問題発生の検出、適切な診断データのセットを収集し、データを Cisco TAC ケースに自動的に転送するために必要なデバッグを有効にするいくつかの署名を作成しました。 診断署名(DS)は、問題の発生を手動で確認する必要性を排除し、断続的および一時的な問題のトラブルシューティングをはるかに容易にします。
Diagnostic Signatures Lookup Toolを使用して、該当する署名を検索し、それらをインストールして問題を解決するか、またはサポート エンゲージメントの一環として TAC エンジニアが推奨する署名をインストールできます。
以下の例は、「%VOICE_IEC-3-GW: CCAPI: Internal Error (call spike threshold): IEC=1.1.181.1.29.0" syslog は次のステップを使用して診断データ収集を自動化します。
収集した診断データがアップロードされる Cisco TAC ファイル サーバ パス(cxd.cisco.com)である追加の DS 環境変数ds_fsurl_prefix を設定します。 ファイルパスのユーザー名はケース番号で、パスワードはファイルアップロードトークンです。このトークンは、次のコマンドでSupport Case Managerから取得できます。 必要に応じて、サポートケースマネージャの [添付] セクションでファイルアップロードトークンを生成できます。
configure terminal call-home diagnostic-signature LocalGateway(cfg-call-home-diag-sign)environment ds_fsurl_prefix "scp://<case number>:<file upload token>@cxd.cisco.com" end
例:
call-home diagnostic-signature environment ds_fsurl_prefix " environment ds_fsurl_prefix "scp://612345678:abcdefghijklmnop@cxd.cisco.com"
SNMP がSNMPを表示 コマンド 有効になっていない場合は、snmpサーバーマネージャ コマンド
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 ファイルをローカルゲートウェイにコピーします。
copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash: copy ftp://username:password@<server name or ip>/DS_65095.xml bootflash:
ローカルゲートウェイに、高 CPU モニタリング DS 64224、DS 65095 XML ファイルの順にインストールします。
call-home diagnostic-signature load DS_64224.xml Load file DS_64224.xml success call-home diagnostic-signature load DS_65095.xml Load file DS_65095.xml success
を使用して署名が正常にインストールされていることを確認します。 コールホーム診断署名を表示 コマンド ステータス列には「登録済み」の値が必要です。
show call-home diagnostic-signature Current diagnostic-signature settings: Diagnostic-signature: enabled Profile: CiscoTAC-1 (status: ACTIVE) Downloading URL(s): https://tools.cisco.com/its/service/oddce/services/DDCEService Environment variable: 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月8日(火)
65095
00:12:53
DS_LGW_IEC_Call_spike_threshold
0.0.12
登録済み
2020年11月8日(火)
診断署名の実行を確認する
次のコマンドで、コールホーム診断署名を表示コマンドは「実行」に変更され、ローカルゲートウェイは署名内で定義されたアクションを実行します。 の出力 コールホーム診断署名統計を表示は、診断署名が関心のある事象を検出し、アクションを実行するかどうかを確認するための最良の方法です。 「Triggered/Max/Deinstall」列は、指定された署名がイベントをトリガーした回数、イベントを検出するために定義された最大回数、およびトリガーされたイベントの最大数を検出した後に署名が自分自身をデインストールするかどうかを示します。
show call-home diagnostic-signature
Current diagnostic-signature settings:
Diagnostic-signature: enabled
Profile: CiscoTAC-1 (status: ACTIVE)
Downloading URL(s): https://tools.cisco.com/its/service/oddce/services/DDCEService
Environment variable:
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 名 | トリガー済み/最大/アンインストール | 平均実行時間(秒) | 最長実行時間(秒) |
---|---|---|---|---|
64224 | DS_LGW_CPU_MON75 | 0/0/N | 0.000 | 0.000 |
65095 | DS_LGW_IEC_Call_spike_threshold | 1/20/Y | 23.053 | 23.053 |
診断署名の実行中に送信される通知メールには、問題の種類、デバイスの詳細、ソフトウェアバージョン、実行中の設定、および指定された問題のトラブルシューティングに関連するコマンド出力の表示などの重要な情報が含まれています。
診断署名をアンインストールする
トラブルシューティングの目的で診断署名を使用することは、通常、いくつかの問題発生を検出した後にアンインストールするように定義されます。 署名を手動でアンインストールする場合は、コールホーム診断署名を表示コマンドを実行し、次のコマンドを実行します。
call-home diagnostic-signature deinstall <DS ID>
例:
call-home diagnostic-signature deinstall 64224
導入でよく見られる問題に基づいて、新しい署名が Diagnostics Signatures Lookup Tool に定期的に追加されます。 TAC では現在、新しいカスタム署名の作成リクエストをサポートしていません。
Cisco IOS XE ゲートウェイの管理を改善するには、Control Hub を使用してゲートウェイを登録して管理することをお勧めします。 これはオプションの設定です。 登録すると、Control Hub の構成検証オプションを使用して、ローカル ゲートウェイ構成を検証し、構成の問題を特定できます。 現在、登録ベースのトランクのみがこの機能をサポートしています。
詳細については、以下を参照してください。
このセクションでは、証明書ベースの相互 TLS (mTLS) 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 アドレス、およびインターフェイスが使用されます。 オプションは、パブリックまたはプライベート(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 Software Research」ページを参照してください。 プラットフォームを検索し、提案されたリリースのいずれかを選択します。
ISR4000 シリーズ ルータは、Unified Communications および Security テクノロジー ライセンスの両方で設定する必要があります。
Catalyst Edge 8000シリーズのルーターには、ボイスカードまたはDSPが装備されており、DNA Essentialsのライセンスが必要です。 ボイスカードやDSPのないルーターには、最低限のDNA Essentialsライセンスが必要です。
大容量の要件については、High Security(HSEC)ライセンスおよび追加のスループットエンタイトルメントが必要になる場合があります。
詳細については、認証コードを参照してください。
ビジネスポリシーに従うプラットフォームのベースライン設定を構築します。 特に、以下を設定し、作業を確認します。
NTP
ACLsについて
ユーザー認証とリモートアクセス
DNS
IP ルーティング
IP アドレス
Webex Calling に向かうネットワークは IPv4 アドレスを使用する必要があります。 ローカル ゲートウェイの完全修飾ドメイン名(FQDN)またはサービス レコード(SRV)アドレスは、インターネット上のパブリック IPv4 アドレスに解決する必要があります。
Webex に面しているローカル ゲートウェイ インターフェイスのすべての SIP ポートとメディア ポートは、直接または静的 NAT 経由でインターネットからアクセスできる必要があります。 それに応じてファイアウォールを更新してください。
署名付き証明書をローカル ゲートウェイにインストールします (詳細な設定手順は次のとおりです)。
Cisco Webex 音声およびビデオ プラットフォームへの通話でサポートされているルート認証局とはに詳述されているパブリック認証局 (CA) は、デバイス証明書に署名する必要があります。
トランクの作成時に Control Hub で設定された FQDN は、ルータの共通名(CN)またはサブジェクト代替名(SAN)の証明書である必要があります。 例:
組織の 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、レコード、または IP アドレス)は、SAN ではオプションです。
トランクに FQDN または SRV を使用するかどうかにかかわらず、ローカル ゲートウェイからのすべての新しい SIP ダイアログの連絡先アドレスは、Control Hub で設定された名前を使用します。
証明書がクライアントとサーバの使用のために署名されていることを確認します。
Cisco ルート CA バンドルをローカル ゲートウェイにアップロードします。
構成
1 | 次のように、有効でルーティング可能な IP アドレスをレイヤ 3 インターフェイスに割り当てます。
|
2 | 対称暗号化を使用してルータの STUN クレデンシャルを保護します。 プライマリ暗号化キーと暗号化タイプを次のように設定します。
|
3 | 希望する認証局 (CA) によって署名された証明書を使用して暗号化トラストポイントを作成します。 |
4 | 中間(またはルート)CA 証明書を使用して新しい証明書を認証し、証明書をインポートします(ステップ 4)。 次の exec または configuration コマンドを入力します。
|
5 | 次の exec または configuration コマンドを使用して、署名済みホスト証明書をインポートします。
|
6 | TLS1.2 排他を有効にし、次の設定コマンドを使用してデフォルトのトラストポイントを指定します。
|
7 | Webex Calling で使用される DigiCert CA 証明書を含む Cisco ルート CA バンドルをインストールします。 を使用する crypto pki trustpool インポート クリーン 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 | を設定する 音声クラスコーデック 100 トランクの コーデック フィルタ。 この例では、すべてのトランクに同じコーデックフィルタが使用されます。 正確な制御のために各トランクにフィルタを設定できます。
設定フィールドの説明を次に示します。 音声クラス コーデック 100SIP トランクを介したコールの優先コーデックのみを許可するために使用されます。 詳細については、「音声クラスコーデック」を参照してください。 Opus コーデックは、SIP ベースの PSTN トランクでのみサポートされています。 PSTN トランクが音声 T1/E1 またはアナログ FXO 接続を使用している場合は、コーデックの設定 1 オプスから音声クラスコーデック 100の設定。 |
4 | を設定する 音声クラスの使い方 100 は、Webex Calling トランクで ICE を有効にします。 (この手順は政府版 Webex には適用されません)
設定フィールドの説明を次に示します。 スタンの使用法 アイス ライトすべての Webex Calling のダイヤルピアに対して ICE-Lite を有効にして、可能な限り、メディア最適化を可能にするために使用。 詳細については、「voice class stun usage」および「stun usage ice lite」を参照してください。 使用量のファイアウォール/トラバーサルフローデータを読み込むコマンドは、NATの後ろにローカルゲートウェイを展開する場合にのみ必要です。 メディア パスの最適化を使用したコール フローには、ICE-lite のスタン使用が必要です。 SIP から TDM ゲートウェイへのメディア最適化を提供するには、IP-IP レッグで ICE-Lite が有効になっているループバック ダイヤル ピアを設定します。 技術的な詳細については、アカウントまたは TAC チームにお問い合わせください。 |
5 | Webex トラフィックのメディア暗号化ポリシーを設定します。 (この手順は政府版 Webex には適用されません)
設定フィールドの説明を次に示します。 音声クラス srtp-crypto 100SDP の SRTP 暗号スイート CUBE オファーおよび応答メッセージの唯一の SRTP オファーとして SHA1_80 を指定します。 Webex Calling は SHA180 のみをサポートします。_ 詳細については、音声クラス srtp-crypto を参照してください。 |
6 | FIPS 準拠の GCM 暗号を設定します(この手順は政府版 Webex にのみ適用されます)。
設定フィールドの説明を次に示します。 音声クラス srtp-crypto 100CUBE が提供する暗号スイートとして GCM を指定します。 政府版 Webex のローカル ゲートウェイの GCM 暗号を設定することは必須です。 |
7 | 宛先 FQDN または SRV に基づいて、ローカル ゲートウェイ トランクへのコールを一意に識別するためのパターンを設定します。
設定フィールドの説明を次に示します。 音声クラス uri 100 sip着信トランク ダイヤル ピアへの着信 SIP 招待と一致するパターンを定義します。 このパターンを入力するときは、トランクの作成中に Control Hub で設定された LGW FQDN または SRV を使用します。 |
8 | SIP メッセージ操作プロファイルを設定します。 ゲートウェイがパブリック IP アドレスで設定されている場合は、次のようにプロファイルを設定するか、NAT を使用している場合は、次のステップにスキップします。 この例では、cube1.lgw.com はローカル ゲートウェイ用に設定された FQDN であり、「198.51.100.1」は Webex Calling に面したローカル ゲートウェイ インターフェイスのパブリック IP アドレスです。
設定フィールドの説明を次に示します。 ルール10と20Webex がローカル ゲートウェイからのメッセージを認証できるようにするには、SIP 要求および応答メッセージの「連絡先」ヘッダーに、Control Hub のトランクにプロビジョニングされた値が含まれている必要があります。 これは、単一のホストの FQDN、またはデバイスのクラスタに使用される SRV ドメイン名のいずれかになります。 ローカル ゲートウェイにパブリック IP アドレスを設定している場合は、次の手順をスキップします。 |
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 要求および応答メッセージの「連絡先」ヘッダーに、Control Hub のトランクにプロビジョニングされた値が含まれている必要があります。 これは、単一のホストの FQDN、またはデバイスのクラスタに使用される SRV ドメイン名のいずれかになります。 ルール30~81プライベート アドレス参照をサイトの外部パブリック アドレスに変換し、Webex が後続のメッセージを正しく解釈してルーティングできるようにします。 Webex Calling からの着信メッセージの SIP プロファイル
設定フィールドの説明を次に示します。 10から80までのルールパブリックアドレス参照を設定済みのプライベートアドレスに変換し、Webex からのメッセージを CUBE で正しく処理できるようにします。 詳細については、「音声クラス sip プロファイル」を参照してください。 |
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ダイヤルピアを定義し、管理とトラブルシューティングを容易にするための意味のある説明を提供します。 詳細については、ダイヤルピアの音声を参照してください。 destination-pattern BAD.BAD着信ダイヤル ピア グループを使用して発信コールをルーティングする場合は、ダミー接続先パターンが必要です。 詳細については、destination-pattern (interface)を参照してください。 session protocol sipv2ダイヤルピア 200 が SIP コール レッグを処理するように指定します。 詳細については、セッションプロトコル (ダイヤルピア)を参照してください。 session target ipv4:192.168.80.13コール レッグを送信する宛先のターゲット IPv4 アドレスを示します。 ここでのセッションのターゲットは、ITSP の IP アドレスです。 詳細については、セッションターゲット (VoIP ダイヤルピア)を参照してください。 200 経由で 着信 uriVIA ヘッダーと IP PSTN の IP アドレスの一致基準を定義します。 ローカル ゲートウェイのすべての着信 IP PSTN コール レッグとダイヤル ピア 200 を一致させます。 詳細については、着信 URLを参照してください。 バインド制御ソースインタフェース GigabitEthernet0/0/0PSTN に送信されるメッセージのソース インターフェイスと関連する 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 トランクを作成します。
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-profile」および「voice translation-rule」を参照してください。 |
2 | 使用するトランク タイプとプロトコルによって必要に応じて、TDM 音声インターフェイス ポートを設定します。 詳細については、「ISDN PRIの設定」を参照してください。 たとえば、デバイスの NIM スロット 2 にインストールされているプライマリレート ISDN インターフェイスの基本設定には、次のものが含まれます。
|
3 | 次の TDM PSTN ダイヤル ピアを設定します。
設定フィールドの説明を次に示します。
タグ 200 で VoIP ダイヤル ピアを定義し、管理とトラブルシューティングを容易にするための意味のある説明を提供します。 詳細については、「ダイヤルピアの音声」を参照してください。 destination-pattern BAD.BAD着信ダイヤル ピア グループを使用して発信コールをルーティングする場合は、ダミー接続先パターンが必要です。 詳細については、destination-pattern (interface)を参照してください。 翻訳プロファイル着信 200着信着信番号にコール ルーティング タグを追加するトランスレーション プロファイルを割り当てます。 ダイレクト インワード ダイヤルセカンダリ ダイヤル トーンを提供せずにコールをルーティングします。 詳細は、ダイレクト インワード ダイヤルを参照してください。 ポート 0/2:0:15このダイヤル ピアに関連付けられている物理的な音声ポート。 |
4 | TDM-IP コール フローでローカル ゲートウェイの IP パスのメディア最適化を有効にするには、Webex Calling と PSTN トランクの間に一連の内部ループ バック ダイヤル ピアを導入して、コール ルーティングを変更できます。 次のループバックダイヤルピアを設定します。 この場合、すべての着信コールは最初にダイヤルピア 10 にルーティングされ、そこから適用されたルーティング タグに基づいてダイヤルピア 11 または 12 にルーティングされます。 ルーティング タグを削除すると、コールはダイヤル ピア グループを使用して発信トランクにルーティングされます。
設定フィールドの説明を次に示します。
VoIP ダイヤル ピアを定義し、管理とトラブルシューティングを容易にするための意味のある説明を提供します。 詳細については、「ダイヤルピアの音声」を参照してください。 翻訳プロファイル着信 11先に定義したトランスレーション プロファイルを適用して、発信トランクに渡す前にコール ルーティング タグを削除します。 destination-pattern BAD.BAD着信ダイヤル ピア グループを使用して発信コールをルーティングする場合は、ダミー接続先パターンが必要です。 詳細については、destination-pattern (interface)を参照してください。 session protocol sipv2このダイヤル ピアが SIP コール レッグを処理することを指定します。 詳細については、セッションプロトコル (ダイヤルピア)を参照してください。 セッションのターゲット 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 コマンド出力を収集する
統合ログ ファイルの生成
HTTPS、SCP、FTP サーバなどのユーザー提供のネットワークロケーションにファイルをアップロードする
TACエンジニアはDSファイルを作成し、完全性保護のためにデジタル署名します。 各 DS ファイルには、システムによって割り当てられた一意の数値 ID があります。 Diagnostic Signatures Lookup Tool (DSLT)は、さまざまな問題を監視およびトラブルシューティングするための適切な署名を見つけるための単一のソースです。
開始する前に:
DSLTからダウンロードしたDSファイルは編集しないでください。 整合性チェックエラーのために修正したファイルはインストールに失敗します。
ローカル ゲートウェイがメール通知を送信するために必要な Simple Mail Transfer Protocol(SMTP)サーバー。
メール通知にセキュアな SMTP サーバを使用する場合は、ローカル ゲートウェイが IOS XE 17.6.1 以降を実行していることを確認します。
前提条件
IOS XE 17.6.1 以降を実行しているローカル ゲートウェイ
診断署名はデフォルトで有効になっています。
デバイスが IOS XE 17.6.1 以降を実行している場合、プロアクティブな通知を送信するために使用するセキュア メール サーバを設定します。
configure terminal call-home mail-server <username>:<pwd>@<email server> priority 1 secure tls end
通知する管理者のメールアドレスで環境変数ds_emailを設定します。
configure terminal call-home diagnostic-signature LocalGateway(cfg-call-home-diag-sign)environment ds_email <email address> end
プロアクティブなモニタリングのための診断署名のインストール
高いCPU使用率のモニタリング
この DS は、SNMP OID 1.3.6.1.4.1.9.2.1.56 を使用して 5 秒の CPU 使用率を追跡します。 使用率が 75% 以上になると、すべてのデバッグが無効になり、ローカル ゲートウェイにインストールするすべての診断シグネチャがアンインストールされます。 下記の手順を実行して署名をインストールします。
コマンド を使用して SNMP が有効になっていることを確認します。 SNMPを表示だ SNMPが有効になっていない場合は、snmpサーバーマネージャ コマンド
show snmp %SNMP agent not enabled config t snmp-server manager end show snmp Chassis: ABCDEFGHIGK 149655 SNMP packets input 0 Bad SNMP version errors 1 Unknown community name 0 Illegal operation for community name supplied 0 Encoding errors 37763 Number of requested variables 2 Number of altered variables 34560 Get-request PDUs 138 Get-next PDUs 2 Set-request PDUs 0 Input queue packet drops (Maximum queue size 1000) 158277 SNMP packets output 0 Too big errors (Maximum packet size 1500) 20 No such name errors 0 Bad values errors 0 General errors 7998 Response PDUs 10280 Trap PDUs Packets currently in SNMP process input queue: 0 SNMP global trap: enabled
Diagnostic Signatures Lookup Tool の以下のドロップダウンオプションを使用して、DS 64224 をダウンロードします。
copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash:
フィールド名
フィールド値
プラットフォーム
Cisco 4300、4400 ISR シリーズ、または Catalyst 8000V Edge ソフトウェア
製品
Webex Calling ソリューションの CUBE Enterprise
問題の範囲
パフォーマンス
問題の種類
メール通知による高 CPU 使用率
DS XML ファイルをローカルゲートウェイフラッシュにコピーします。
copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash:
次の例では、FTP サーバからローカル ゲートウェイにファイルをコピーしています。
copy ftp://user:pwd@192.0.2.12/DS_64224.xml bootflash: Accessing ftp://*:*@ 192.0.2.12/DS_64224.xml...! [OK - 3571/4096 bytes] 3571 bytes copied in 0.064 secs (55797 bytes/sec)
ローカルゲートウェイに DS XML ファイルをインストールします。
call-home diagnostic-signature load DS_64224.xml Load file DS_64224.xml success
を使用する コールホーム診断署名を表示コマンドを使用して、署名が正常にインストールされていることを確認します。 ステータス列には「登録済み」の値が必要です。
show call-home diagnostic-signature Current diagnostic-signature settings: Diagnostic-signature: enabled Profile: CiscoTAC-1 (status: ACTIVE) Downloading URL(s): https://tools.cisco.com/its/service/oddce/services/DDCEService Environment variable: 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 とメール通知が生成されます。 下記の手順を実行して、署名をインストールしてください。
コマンド を使用して SNMP が有効になっていることを確認します。 SNMPを表示だ SNMP が有効になっていない場合は、snmpサーバーマネージャ コマンド
show snmp %SNMP agent not enabled config t snmp-server manager end show snmp Chassis: ABCDEFGHIGK 149655 SNMP packets input 0 Bad SNMP version errors 1 Unknown community name 0 Illegal operation for community name supplied 0 Encoding errors 37763 Number of requested variables 2 Number of altered variables 34560 Get-request PDUs 138 Get-next PDUs 2 Set-request PDUs 0 Input queue packet drops (Maximum queue size 1000) 158277 SNMP packets output 0 Too big errors (Maximum packet size 1500) 20 No such name errors 0 Bad values errors 0 General errors 7998 Response PDUs 10280 Trap PDUs Packets currently in SNMP process input queue: 0 SNMP global trap: enabled
Diagnostic Signatures Lookup Tool の以下のオプションを使用して、DS 65221 をダウンロードします。
フィールド名
フィールド値
プラットフォーム
Cisco 4300、4400 ISR シリーズ、または Catalyst 8000V Edge ソフトウェア
製品
Webex Calling ソリューションの CUBE Enterprise
問題の範囲
パフォーマンス
問題の種類
電子メールおよび Syslog 通知による SIP 異常な通話切断検出。
DS XML ファイルをローカルゲートウェイにコピーします。
copy ftp://username:password@<server name or ip>/DS_65221.xml bootflash:
ローカルゲートウェイに DS XML ファイルをインストールします。
call-home diagnostic-signature load DS_65221.xml Load file DS_65221.xml success
コマンド を使用する コールホーム診断署名を表示は、署名が正常にインストールされていることを確認します。 ステータス列の値が「registered」になっているはずです。
診断署名をインストールして問題をトラブルシューティング
診断署名(DS)を使用して、問題を迅速に解決することもできます。 Cisco TAC エンジニアは、特定の問題のトラブルシューティング、問題発生の検出、適切な診断データのセットを収集し、データを Cisco TAC ケースに自動的に転送するために必要なデバッグを有効にするいくつかの署名を作成しました。 これにより、問題の発生を手動で確認する必要がなくなり、断続的、および一時的な問題のトラブルシューティングがはるかに容易になります。
Diagnostic Signatures Lookup Toolを使用して、該当する署名を検索し、それらをインストールして問題を解決するか、TACエンジニアがサポート業務の一環として推奨する署名をインストールできます。
以下の例は、「%VOICE_IEC-3-GW: CCAPI: Internal Error (call spike threshold): IEC=1.1.181.1.29.0" syslog は次のステップを使用して診断データ収集を自動化します。
診断データをアップロードするには、Cisco TAC ファイル サーバ パス(cxd.cisco.com)として別の DS 環境変数ds_fsurl_prefix を設定します。 ファイルパスのユーザー名はケース番号で、パスワードはファイルアップロードトークンです。このトークンは、以下に示すようにSupport Case Managerから取得できます。 ファイルのアップロードトークンは、必要に応じて、Support Case Managerの添付ファイルセクションで生成できます。
configure terminal call-home diagnostic-signature LocalGateway(cfg-call-home-diag-sign)environment ds_fsurl_prefix "scp://<case number>:<file upload token>@cxd.cisco.com" end
例:
call-home diagnostic-signature environment ds_fsurl_prefix " environment ds_fsurl_prefix "scp://612345678:abcdefghijklmnop@cxd.cisco.com"
コマンド を使用して SNMP が有効になっていることを確認します。 SNMPを表示だ SNMP が有効になっていない場合は、snmpサーバーマネージャ コマンド
show snmp %SNMP agent not enabled config t snmp-server manager end
High CPU monitoring DS 64224 は、CPU 使用率が高い時間帯にすべてのデバッグおよび診断シグネチャを無効にするプロアクティブな対策としてインストールすることをお勧めします。 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 ファイルをローカルゲートウェイにコピーします。
copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash: copy ftp://username:password@<server name or ip>/DS_65095.xml bootflash:
ローカル ゲートウェイに高 CPU モニタリング DS 64224 および DS 65095 XML ファイルをインストールします。
call-home diagnostic-signature load DS_64224.xml Load file DS_64224.xml success call-home diagnostic-signature load DS_65095.xml Load file DS_65095.xml success
を使用して署名が正常にインストールされていることを確認します。 コールホーム診断署名を表示だ ステータス列の値が「registered」になっているはずです。
show call-home diagnostic-signature Current diagnostic-signature settings: Diagnostic-signature: enabled Profile: CiscoTAC-1 (status: ACTIVE) Downloading URL(s): https://tools.cisco.com/its/service/oddce/services/DDCEService Environment variable: 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
DS_LGW_IEC_Call_spike_threshold
0.0.12
登録済み
2020-11-08:00:12:53
診断署名の実行を確認する
次のコマンドで、コマンドの「ステータス」列 コールホーム診断署名を表示が「実行」に変更され、ローカルゲートウェイが署名内で定義されたアクションを実行します。 の出力 コールホーム診断署名統計を表示は、診断署名が関心のある事象を検出し、アクションを実行したかどうかを確認するための最良の方法です。 「Triggered/Max/Deinstall」列は、指定された署名がイベントをトリガーした回数、イベントを検出するために定義された最大回数、およびトリガーされたイベントの最大数を検出した後に署名が自分自身をデインストールするかどうかを示します。
show call-home diagnostic-signature
Current diagnostic-signature settings:
Diagnostic-signature: enabled
Profile: CiscoTAC-1 (status: ACTIVE)
Downloading URL(s): https://tools.cisco.com/its/service/oddce/services/DDCEService
Environment variable:
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 名 | トリガー済み/最大/アンインストール | 平均実行時間(秒) | 最長実行時間(秒) |
---|---|---|---|---|
64224 | DS_LGW_CPU_MON75 |
0/0/N |
0.000 |
0.000 |
65095 |
DS_LGW_IEC_Call_spike_threshold |
1/20/Y |
23.053 |
23.053 |
診断署名の実行中に送信される通知メールには、問題の種類、デバイスの詳細、ソフトウェアバージョン、実行中の設定、指定された問題のトラブルシューティングに関連するコマンド出力の表示などの重要な情報が含まれています。
診断署名をアンインストールする
トラブルシューティングの目的で診断署名を使用することは、通常、いくつかの問題発生を検出した後にアンインストールするために定義されます。 署名を手動でアンインストールする場合は、コールホーム診断署名を表示を実行し、次のコマンドを実行します。
call-home diagnostic-signature deinstall <DS ID>
例:
call-home diagnostic-signature deinstall 64224
新しい署名は、展開で観察された問題に基づいて、診断署名検索ツールに定期的に追加されます。 TAC では現在、新しいカスタム署名の作成リクエストをサポートしていません。
ローカル ゲートウェイとして CUBE のハイ アベイラビリティを実装する
基礎
前提条件
Webex Calling のローカル ゲートウェイとして CUBE HA を展開する前に、以下の概念を深く理解するようにしてください。
ステートフル コール保持のための CUBE エンタープライズによるレイヤー 2 ボックス間冗長性
この記事で提供される構成ガイドラインは、既存の音声構成が設定されていない専用のローカル ゲートウェイ プラットフォームが使用されていることを前提としています。 既存の CUBE エンタープライズ展開が、Cisco Webex Calling のローカル ゲートウェイ機能を使用するように変更されている場合、既存のコール フローと機能が中断されないようにして、CUBE HA 設計要件に準拠するように、設定に注意してください。
ハードウェアとソフトウェアのコンポーネント
ローカルゲートウェイとしての CUBE HA には IOS-XE バージョン 16.12.2 以降、および CUBE HA と LGW 機能の両方をサポートするプラットフォームが必要です。
この記事のコマンドとログの表示は、vCUBE(CSR1000v)で実装された Cisco IOS-XE 16.12.2 のソフトウェアの最小リリースに基づいています。
参考資料
さまざまなプラットフォーム向けの詳細な CUBE HA 設定ガイドを次に示します。
CSR 1000v (vCUBE)— https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-cube-high-availability-CSR1000v.html
Cisco Preferred Architecture for Cisco Webex Calling— https://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Collaboration/hybrid/AltDesigns/PA-WbxCall.pdf
Webex Calling ソリューションの概要
Cisco Webex Calling は、複数の PSTN オプションにより、オンプレミスの PBX 電話サービスにマルチテナントのクラウドベースの代替手段を提供するコラボレーションソリューションです。
この記事の焦点は、ローカル ゲートウェイの展開 (以下を参照) です。 Webex Calling のローカルゲートウェイ(プレミスベースの PSTN)トランクによって、顧客が所有する PSTN サービスへの接続が可能になります。 また、Cisco Unified CM などのオンプレミス IP PBX 展開への接続も提供します。 クラウド間のすべての通信は、メディア向け SIP および SRTP で TLS トランスポートを使用してセキュリティ保護されています。
次の図では、既存の IP PBX なしでの Webex Calling 展開を示し、単一または複数サイトの展開に適用されます。 この記事に記載されている設定は、この展開に基づいています。
レイヤー 2 のボックス間冗長性
CUBE HA レイヤー 2 ボックス間冗長性は、冗長性グループ (RG) インフラストラクチャ プロトコルを使用して、ルーターのアクティブ/スタンバイ ペアを形成します。 このペアは、それぞれのインターフェイスで同じ仮想 IP アドレス (VIP) を共有し、ステータ スメッセージを継続的に交換します。 CUBE セッションはルーターのペアリングのチェックポイントであり、アクティブ ルーターがサービスを停止した場合に、スタンバイ ルーターがすべての CUBE コール処理の責任を果たすことができるようになりました。その結果、シグナリングとメディアのステートフルな保持が可能になりました。
チェック ポイントは、メディア パケットのある接続されたコールに限定されます。 転送中のコールはチェック ポイントではありません (たとえば、試行中または呼出状態)。
この記事では、CUBE HA は、ステートフルコール保持の CUBE ハイ アベイラビリティ (HA) レイヤー 2 ボックス間 (B2B) 冗長性を参照します。
IOS-XE 16.12.2 では、CUBE HA を Cisco Webex Calling トランク(プレミスベースの PSTN)展開のローカルゲートウェイとして展開できます。この記事では、設計の考慮事項と構成について説明します。 この図は、Cisco Webex Calling トランク展開のローカルゲートウェイとしての一般的な CUBE HA 設定を示しています。
冗長性グループ インフラストラクチャ コンポーネント
冗長グループ (RG) インフラ コンポーネントは、2 つの CUBE 間でのボックス間通信インフラストラクチャのサポートを提供し、最終的に安定した冗長性の状態をネゴシエートします。 このコンポーネントは次の機能も提供します。
2 つの CUBE 間で keepalive と hello メッセージを交換することで (コントロール インターフェイス)、各ルータの最終的な冗長状態をネゴシエートする HSRP のようなプロトコル。上の図の GigabitEthernet3です。
アクティブからスタンバイ ルータ (データ インターフェイス経由) への各コールに関して、シグナリングとメディアの状態をチェックするための転送メカニズム。上記の図の GigabitEthernet3です。
トラフィック インターフェイスの仮想 IP (VIP) インターフェイスの構成と管理 (複数のトラフィック インターフェイスは同じ RG グループを使用して構成できます)。GigabitEthernet 1 および 2 はトラフィック インターフェイスと見なされます。
この RG コンポーネントは、音声 B2B HA をサポートするように特別に構成する必要があります。
信号とメディアの両方に関する仮想 IP (VIP) アドレス管理
B2B HA は、冗長性を確保する際に VIP に依存します。 CUBE HA ペアの両方の CUBE で VIP および関連する物理インターフェイスは、同じ LAN サブネット上に存在している必要があります。 VIP の構成、および特定の音声アプリケーション (SIP) への VIP インターフェイスのバインドは、音声 B2B HA サポートに必須です。 Unified CM、Webex Calling アクセス SBC、サービス プロバイダー、プロキシなどの外部デバイスは、CUBE HA ルーターを通過するコールの宛先 IP アドレスとして VIP を使用します。 そのため、Webex Calling の観点から、CUBE HA ペアは単一のローカル ゲートウェイとして機能します。
確立されたコールのコール シグナリングおよび RTP セッション情報は、アクティブなルーターからスタンバイ ルーターへのチェックポイントです。 アクティブ ルーターがダウンすると、スタンバイ ルーターが引き継ぎ、最初のルーターによって以前にルーティングされた RTP ストリームを継続して転送します。
フェイルオーバー時に一時的な状態のコールは、切り替え後には保存されません。 たとえば、まだ完全に確立されていない、または転送や保留の機能により変更中のコールなどです。 確立されたコールは、切り替え後に切断される場合があります。
コールのステートフル フェールオーバーのローカル ゲートウェイとして CUBE HA を使用するには、以下の要件があります。
CUBE HA は TDM またはアナログ インターフェイスを共存させることはできません
Gig1 および Gig2 はトラフィック (SIP/RTP) インターフェイス、Gig3 は冗長グループ (RG) コントロール/データ インターフェイスと呼ばれます
グループ id 1 とグループ id 2 を持つ同じレイヤー 2 ドメインに配置できる CUBE HA ペアは 2 つまでです。 同じグループ ID で 2 つの HA ペアを構成する場合、RG コントロール/データ インターフェイスは異なるレイヤー 2 ドメイン (vlan、個別のスイッチ) に属している必要があります
ポート チャネルは、RG コントロール/データとトラフィック インターフェイスの両方でサポートされています
すべてのシグナリング/メディアは、仮想 IP アドレスから供給されます
プラットフォームが CUBE HA 関係にリロードされると、常にスタンバイとして起動します
すべてのインターフェイスの下位アドレス (Gig1、Gig2、Gig3) は、同じプラットフォームにある必要があります
冗長性インターフェイス識別子、rii は同じレイヤー 2 のペア/インターフェイスの組み合わせに対して固有である必要があります
両方の CUBE の構成は、物理構成を含む必要があり、同じ種類のプラットフォームと IOS-XE バージョンで実行されている必要があります
ループバック インターフェイスは、常に起動しているためバインドとして使用できません
複数のトラフィック (SIP/RTP) インターフェイス (Gig1、Gig2) では、インターフェイスのトラッキングが構成されている必要があります
CUBE-HA は、RG コントロール/データ リンク (Gig3) のクロスオーバー ケーブル接続ではサポートされていません
両方のプラットフォームは同一である必要があり、すべての同様のインターフェイスで CUBE HA が機能するように [物理スイッチ] を介して接続します。例: CUBE-1 と CUBE-2 の GE0/0/0 は同じスイッチ上で終了する必要があります
直接 CUBE 上で、またはいずれかの側のデータ HA で WAN を終了することができません
アクティブ/スタンバイは両方とも同じデータセンターにある必要があります
冗長性 (RG コントロール/データ、Gig3) に別の L3 インターフェイスを使用する必要があります。トラフィックに使用されるインターフェイスは、HA keepalives およびチェックポイントに使用できません
フェールオーバー時に、以前アクティブだった CUBE は、設計によって再読み込みされ、シグナリングとメディアを保持します
両方の CUBE で冗長性を構成する
HA ペアで使用し、仮想 IP を表示するために、両方の CUBE でレイヤー 2 ボックス間冗長性を構成する必要があります。
1 | インターフェイスのステータスを追跡するために、グローバル レベルでインターフェイス トラッキングを構成します。
トラッキング CLI は、トラフィック インターフェイスがダウンした後、アクティブ ルートがアクティブな役割を果たすように、RG 内で音声トラフィックインターフェイスの状態を追跡するために使用されます。 | ||
2 | アプリケーション冗長性サブモード下の VoIP HA で使用する RG を構成します。
この構成で使用されるフィールドの説明を次に示します。
| ||
3 | CUBE アプリケーションのボックス間の冗長性を有効にします。 以下の下にある以前の手順から RG を構成します:
redundancy-group 1—このコマンドを追加および削除するには、更新された構成を有効にするための再読み込みが必要です。 すべての構成が適用された後で、プラットフォームを再読み込みします。 | ||
4 | 以下に示すように、Gig1 と Gig2 インターフェイスをそれぞれの仮想 IP で構成し、冗長性インターフェイス識別子 (rii) を適用します。
この構成で使用されるフィールドの説明を次に示します。
| ||
5 | 最初の CUBE 構成を保存し、再読み込みします。 最後にリロードするプラットフォームは常にスタンバイです。
VCUBE-1 が完全に起動したら、 VCUBE-2 の構成を保存し、再読み込みします。
| ||
6 | ボックス間の構成が期待どおりに機能していることを確認します。 関連する出力は太字で強調表示されます。 VCUBE-2 を最後にリロードし、設計上の考慮事項に従います。最後にリロードするプラットフォームは常に [スタンバイ] 状態です。
|
両方の CUBE でローカル ゲートウェイを構成する
この例の構成では、Control Hub から以下のトランク情報を使用して、VCUBE-1、VCUBE-2 の両方のプラットフォームでローカルゲートウェイを構成しています。 この設定のユーザー名とパスワードは以下のとおりです。
ユーザー名: フセイン1076_LGU
パスワード: lOV12MEaZx
1 | クレデンシャルまたは共有秘密で使用する前に、以下のコマンドを使用して、設定キーがパスワードに対して作成されていることを確認してください。 Type 6 パスワードは、AES 暗号化とこのユーザー定義の設定キーを使用して暗号化されます。
これは、上に表示されている Control Hub のパラメーターに基づき、両方のプラットフォームに適用し、保存し、リロードするローカ ルゲートウェイの構成です。 Control Hub からの SIP ダイジェスト クレデンシャルは太字でハイライトされています。
Show コマンド出力を表示するには、VCUBE-2 の後に VCUBE-1 をリロードし、VCUBE-1 をスタンバイ CUBE にして、VCUBE-2 をアクティブ CUBE にします。 |
2 | 任意の時点で、1 個のプラットフォームのみが、Webex Calling アクセス SBC を使用したローカル ゲートウェイとしてアクティブ登録を保持します。 以下の show コマンドの出力を見てみましょう。 show redundancy application group 1 sip-ua レジスタ ステータスを表示
上記の出力から、 VCUBE-2 がアクティブ LGW で、Webex Calling アクセス SBC への登録を維持していることがわかります。しかし、「show sip-ua register status」の出力は VCUBE-1 では空です |
3 | VCUBE-1 で次のデバッグを有効にします
|
4 | この場合、アクティブ LGW、VCUBE-2 で次のコマンドを実行してフェールオーバーをシミュレートします。
アクティブからスタンバイ LGW への切り替えは、上記に一覧表示されている CLI に加えて、以下のシナリオで発生します。
|
5 | VCUBE-1 が Webex Calling アクセス SBC に登録されているかどうかを確認します。 VCUBE-2 は今すぐにリロードされます。
VCUBE-1 がアクティブ LGW になりました。 |
6 | 仮想 IP を通じて SIP REGISTER を Webex Calling に送信し、200 OK を受信する VCUBE-1 に関連するデバッグ ログを確認してください。
|
Webex Calling のために Unified CM を構成する
ローカル ゲートウェイへトランクするための SIP トランク セキュリティ プロファイルを構成する
ローカル ゲートウェイと PSTN ゲートウェイが同じデバイス上に存在する場合、Unified CM を有効にして、同じデバイスから発信された 2 個の異なるトラフィックの種類 (Webex と PSTN のコール) を区別し、これらのコール タイプに対して差別化されたクラスのサービスを適用する必要があります。 この差別化されたコール処理は、Unified CM および結合されたローカル ゲートウェイと PSTN ゲートウェイ デバイスの 2 つのトランクをプロビジョニングすることで行われます。これは、2 つのトランクに異なる SIP リスニング ポートを必要とします。
次の設定でローカル ゲートウェイ トランクの専用の SIP トランク セキュリティ プロファイルを作成します。
|
ローカル ゲートウェイ トランクの SIP プロファイルを構成する
次の設定でローカル ゲートウェイ トランク用の専用の SIP プロファイルを作成します。
|
Webex からのコールのコール検索スペースを作成する
次の設定で Webex から発信されたコールのためのコール検索スペースを作成します。
最後のパーティション onNetRemote は、Intercluster Lookup Service (ILS) または Global Dialplan Replication (GDPR) を使用して、Unified CM クラスター間でルーティング情報が交換されるマルチクラスター環境でのみ使用されます。 |
Webex 間で SIP トランクを構成する
次の設定を使用して、ローカル ゲートウェイ経由での Webex 間のコールに SIP トランクを作成します。
|
Webex のルート グループを構成する
次の設定でルート グループを作成します。
|
Webex のルート リストを構成する
次の設定でルート リストを作成します。
|
Webex の移動先のパーティションを作成する
次の設定で Webex の移動先のパーティションを作成します。
|
次に行うこと
このパーティションは、Webex の宛先にアクセスする必要があるすべてのコール検索スペースに追加してください。 このパーティションは、PSTN から Webex への発信がルーティングされるように、PSTN トランクの着信コール検索スペースとして使用されるコール検索スペースに特に追加する必要があります。
Webex の移動先のルート パターンを構成する
次の設定で Webex の各 DID 範囲のルート パターンを構成します。
|
Webex の簡略サイト間ダイヤル正規化を構成する
短縮されたサイト間ダイヤルが Webex に必要な場合は、Webex の各 ESB 範囲にダイヤル正規化パターンを設定します。
|
Webex Calling の機能をセットアップする
ハント グループをセットアップする
ハント グループは着信をグループのユーザーまたはワークスペースにルーティングします。 グループ全体にルーティングするパターンを構成することもできます。
ハント グループのセットアップ方法の詳細については、「Cisco Webex Control Hub のハント グループ」を参照してください。
通話キューを作成する
コール キューを作成すれば、顧客の発信にすぐに応答がない場合、誰かが応答できるようになるまで自動応答にしたり、お詫びのメッセージや保留中の音楽が流れるようにしたりすることができます。
コール キューをセットアップおよび管理する方法の詳細については、「Cisco Webex Control Hub でコール キューを管理する」を参照してください。
レセプショニスト クライアントを作成する
お客様のフロントオフィスの担当者のニーズに対応します。 ユーザーを電話のアテンダントとして設定すると、組織内の特定のユーザーに着信するコールをスクリーンできます。
レセプショニストクライアントのセットアップ方法と表示方法については、「Cisco Webex Control Hub のレセプショニストクライアント」を参照してください。
自動アテンダントを作成して管理する
セットアップ メニューと、応答サービス、ハント グループ、ボイスメール ボックスや実際のオペレーターなどへのルーティング機能によって、適切なあいさつを返すことができます。 24 時間分のスケジュールを作成できます。あるいは、時間内か外かに応じて、異なるオプションを使うこともできます。
自動アテンダントの作成と管理の方法については、「Cisco Webex Control Hub で自動アテンダントを管理する」を参照してください。
ページング グループを構成する
グループ ページングは、特定のページング グループに割り当てられた番号または内線番号をダイヤルすることにより、最大 75 名のターゲット ユーザーに一方向通話を行うか、グループ ページングを行うことができるようにします。
ページング グループのセットアップ方法と編集方法の詳細については、「Cisco Webex Control Hub のページング グループを構成する」を参照してください。
コール ピックアップを設定する
コール ピックアップ グループを作成してチームワークとコラボレーションを強化し、ユーザが互いにコールに応答できるようにします。 ユーザーをコールピックアップグループに追加しておけば、グループメンバーが席を離れていたり、電話中だったりした場合、別のメンバーが電話に出ることができます。
コールピックアップグループのセットアップ方法については 、「Cisco Webex Control Hub でのコールピックアップ」を参照してください。
コール パークをセットアップする
コール パークにより、ユーザーの定義されたグループは、コール パーク グループの他の利用可能なメンバーに対するコールをパークすることができます。 パーク中のコールは、グループの他のメンバーが自分の電話で取ることができます。
コールパークのセットアップ方法の詳細については、「Cisco Webex Control Hub コールパーク」を参照してください。
ユーザーの割り込みを有効にする
1 | https://admin.webex.comの顧客ビューから 。 |
2 | ユーザーを選択し、[Calling] をクリックします。 |
3 | [ユーザー権限間]セクションに移動し、[割り込み]を選択します。 |
4 | トグルをオンにすると、他のユーザがこのユーザの進行中のコールに自分自身を追加できるようになります。 |
5 | このユーザーがコールに割り込むときに他のユーザーにトーンを再生する場合は、[このユーザーがコールで割り込むときにトーンを再生] にチェックを入れます。 このユーザーがコールで割り込むときにトーンを再生する設定は、カスタマー エクスペリエンス Basic および Essentials スーパーバイザの割り込み機能には適用されません。 スーパーバイザでこのオプションを有効にした場合でも、スーパーバイザがコール キュー コールで割り込むと、システムはエージェントに通知トーンを再生しません。 スーパーバイザがコールで割り込むときにエージェントにトーンを再生する場合は、[エージェントの通知トーン] 設定を使用して有効にできます。 詳細については、「Webex Customer Experience Basic」または「Webex Customer Experience Essentials」の「キューの作成」セクションを参照してください。 |
6 | [保存] をクリックします。 |
ユーザーのプライバシーを有効にする
1 | Control Hubにサインインし、 。 |
2 | ユーザーを選択し、[Calling] をクリックします。 |
3 | [ユーザー権限間]領域に移動し、[プライバシー]を選択します。 |
4 | このユーザーに適切な [自動音声応答のプライバシー] 設定を選択します。
|
5 | [プライバシーを有効にする] チェックボックスをオンにします。 ドロップダウンリストからメンバーを選択しないことで、全員をブロックすることができます。 または、このユーザーの回線ステータスを監視できるユーザー、ワークスペース、仮想回線を選択することもできます。 ロケーション管理者の場合、割り当てられたロケーションに関連するユーザー、ワークスペース、仮想回線だけがドロップダウン リストに表示されます。 [プライバシーを有効にする] チェックボックスをオフにすると、全員が回線のステータスを監視できるようになります。 |
6 | ダイレクト コール ピックアップと割り込みのプライバシーを有効にするには、[ダイレクト コール ピックアップと割り込みのプライバシーを強制] チェックボックスをオンにします。
|
7 | [名前でメンバーを追加] から、電話回線のステータスを監視し、ダイレクト コール ピックアップと割り込みを呼び出せるユーザ、ワークスペース、仮想回線を選択します。 |
8 | 選択したメンバーをフィルタリングするには、[名前、番号、またはextでフィルタリング]フィールドを使用します。 |
9 | 選択したすべてのメンバーを削除するには、[すべて削除]をクリックします。 個々のメンバーを削除するには、メンバー名の横にある [削除] をクリックします。 |
10 | [保存] をクリックします。 |
モニタリングの設定
ユーザーの監視対象回線の最大数は 50 です。 ただし、モニタリング リストを設定する際には、Webex Calling とネットワーク間の帯域幅に影響を与えるメッセージの数を考慮してください。 また、ユーザの電話機の回線ボタンの数によって、最大監視回線を決定します。
1 | https://admin.webex.comの顧客ビューから、[管理]に移動し、[ユーザー]をクリックします。 |
2 | 変更するユーザーを選択し、[Calling] をクリックします。 |
3 | [ユーザー権限間] セクションに移動し、[モニタリング] を選択します。 |
4 | 次から選択します:
ユーザーモニタリングのために、[モニタリング対象の回線を追加(Add Monitored Line)] リストに仮想回線 を含めることができます。 |
5 | このユーザーにパークされたコールを通知するかどうかを選択し、監視対象のユーザーまたはコール パーク内線を検索し、[保存] をクリックします。 Control Hub の監視回線リストは、ユーザーのデバイス上で表示される監視回線の順番に対応します。 監視対象回線のリストをいつでも並べ替えることができます。 監視対象の回線に表示される名前は、ユーザ、ワークスペース、仮想回線の [発信者 ID 名(Caller ID First Name)] フィールドと [姓(Last Name)] フィールドに入力された名前です。 |
ユーザーのコール ブリッジ警告トーンを有効にする
始める前に
1 | Control Hubにサインインし、 。 |
2 | ユーザーを選択し、[通話] タブをクリックします。 |
3 | [ユーザー権限間] に移動し、[コールブリッジ警告トーン] をクリックします。 |
4 | [コールブリッジング警告トーン] をオンにして、[保存] をクリックします。 デフォルトでは、この機能は有効になっています。 MPP 共有回線のコール ブリッジングの詳細については、「マルチプラットフォーム デスク フォンの共有回線」を参照してください。 Webex アプリの共有回線でのコール ブリッジングの詳細については、「WebexApp の共有回線アピアランス」を参照してください。 |
ユーザーのためにホテリングをオンにする
1 | https://admin.webex.comの顧客ビューから、[管理]に移動し、[ユーザー]を選択します。 |
2 | ユーザーを選択し、[通話] タブをクリックします。 |
3 | [ユーザー間の権限]セクションに移動し、[ホテリング]を選択してトグルをオンにします。 |
4 | [ホテリングロケーション] 検索フィールドにホテリングホストの名前または番号を入力し、ユーザーに割り当てるホテリングホストを選択します。 選択できるホテリングホストは 1 つだけです。 別のホテリング ホストを選択した場合、最初のホストは削除されます。 ロケーション管理者の場合、割り当てられたロケーションに関連するホテリング ホストのみを割り当てることができます。 |
5 | ユーザーがホテリングホストに関連付けることができる時間を制限するには、[関連付け期間を制限(Limit Association Period)] ドロップダウンからユーザーがホテリングホストを使用できる時間を選択します。 ユーザーは選択した時間の後に自動的にログアウトされます。 ユーザーに指定された制限関連付け期間が、選択したホテリングホストの制限関連付け期間を超えると、画面にエラーメッセージが表示されます。 たとえば、ホテリング ホストの制限関連付け期間が 12 時間で、ユーザーの制限関連付け期間が 24 時間である場合、エラー メッセージが表示されます。 この場合、ユーザーにより多くの時間が必要な場合は、ホテリングホストの制限関連期間を延長する必要があります。 |
6 | [保存] をクリックします。 ユーザは、ユーザ ハブから使用するホテリング ホストを検索し、検索することもできます。 詳細については、「どこからでも通話プロファイルにアクセスする」を参照してください。 |
Webex Calling の導入傾向と使用レポート
通話レポートを表示する
Control Hub の [アナリティクス] ページを使用して、ユーザーがどのように Webex Calling と Webex アプリ (エンゲージメント) を使用しているか、また、通話のメディア エクスペリエンスの質について洞察を得ることができます。 Webex Calling のアナリティクスにアクセスするには、Control Hub にサインインし、[アナリティクス] に移動して、[Calling] タブを選択します。
1 | 通話履歴レポートの詳細については、Control Hub にサインインし、 。 |
2 | [通話履歴の詳細] を選択します。 専用インスタンスを使用する通話の詳細については、「専用インスタンスの分析」を参照してください。 |
3 | メディア品質データにアクセスするには、Control Hub にサインインし、[アナリティクス] に移動して、[Calling] を選択します。 詳細については、「クラウド コラボレーション ポートフォリオのためのアナリティクス」を参照してください。
|
CScanツールを実行する
CScan は、Webex Calling へのネットワーク接続をテストするために設計されたネットワーク準備ツールです。
詳細については、「CScan を使用して Webex Calling ネットワークの品質をテストする」をご覧ください。 |
環境を準備する
一般的な前提条件
Webex Calling のローカル ゲートウェイを設定する前に、次のことを確認してください。
-
VoIP の原理についての基本的な知識があること
-
Cisco IOS-XE と IOS-XE 音声のコンセプトについて、基本的で実際的な知識があること
-
セッション開始プロトコル (SIP) の基本的な理解がある
-
導入モデルに Cisco Unified Communications Manager (Unified CM) が含まれている場合には、Unified CM についての基本的な理解があること
詳細については、『Cisco Unified Border Element (CUBE) Enterprise Configuration Guid e』を参照してください。
ローカル ゲートウェイのハードウェアおよびソフトウェア的要件
展開に次のような 1 つ以上のローカル ゲートウェイがあることを確認します。
-
IP ベースの接続用 Cisco CUBE
-
TDM ベースの接続のための Cisco IOS ゲートウェイ
ローカル ゲートウェイは、自分のペースで Webex Calling に移行するのに役立ちます。ローカル ゲートウェイは、既存のオンプレミス展開を Webex Calling と統合します。既存の PSTN 接続を使用することもできます。「ローカル ゲートウェイの使い方」を参照してください
ローカル ゲートウェイのライセンスに関する要件
CUBE コールライセンスは、ローカル ゲートウェイにインストールされている必要があります。詳細については、Cisco Unified 境界要素の構成ガイドを参照してください。
ローカル ゲートウェイの認証およびセキュリティ的要件
Webex Calling は、安全な信号経路とメディアを必要とします。ローカルゲートウェイは暗号化を行います。また、以下の手順に従って、TLS 接続をクラウド方向に確立する必要があります。
-
LGW は、Cisco PKI からの CA ルートバンドルで更新しておく必要があります
-
LGW を構成する際には、Control Hub のトランク構成ページから取得した一連の SIP ダイジェスト資格情報が使用されます(この手順は、この後の構成の一部です)
-
CA ルート バンドルは、提示された証明書を検証します
-
資格情報が要求されます (SIP ダイジェストにより提供されたもの)
-
クラウドは、どのローカル ゲートウェイがセキュアに登録されているかを識別します
ローカルゲートウェイのファイアウォール、NAT Traversal、メディアパス最適化の各要件
ほとんどの場合、ローカル ゲートウェイとエンドポイントは、NAT によるプライベート IP アドレスを使用して、内部の顧客ネットワークに配置することができます。エンタープライズ ファイアウォールは、特定の IP アドレス/ポートに対する外向きトラフィック (SIP、RTP/UDP、HTTP) を許可していなければなりません。この点は、「ポート参照情報」で説明されています。
ICE でメディアパスの最適化を利用する場合、ローカルゲートウェイの Webex Calling に面しているインターフェイスには Webex Calling エンドポイントとの双方向の直接ネットワークパスが必要です。エンドポイントが別のロケーションにあり、ローカルゲートウェイの Webex Calling に面しているインターフェイスとこのエンドポイントとの間に直接ネットワークパスがない場合、メディアパスの最適化を利用するには、ローカルゲートウェイとエンドポイント間の通話のために、Webex Calling に面しているインターフェイスに割り当てられたパブリック IP アドレスをローカルゲートウェイに設定する必要があります。また、IOS-XE バージョン 16.12.5 を実行している必要があります。
組織に合わせて Webex Calling を設定する
Webex Calling サービスを稼働させるための最初のステップは、初回セットアップ ウィザード (FTSW) を完了することです。最初のロケーションの FTSW が完了した後では、追加のロケーションに対して完了する必要がありません。
1 |
受け取ったウェルカム メールのはじめにリンクをクリックします。 管理者のメールアドレスが、自動的に、Control Hub にサインインするためのメール アドレスとして使用されます。サインインすると、管理者パスワードを作成するように求められます。サインインすると、セットアップ ウィザードが自動的に開始します。 |
2 |
利用規約を見直して、承諾します。 |
3 |
プランを見直して、[はじめに] をクリックします。 アカウント マネージャは FTSW の最初の手順をアクティブにする責任があります。[使い始める] を選択した時に、「通話をセットアップできません」という通知を受け取った場合は、アカウント マネージャーに連絡してください。 |
4 |
データ センターがマッピングする国を選択し、顧客の連絡先と顧客アドレス情報を入力します。 |
5 |
[次へ: デフォルトのロケーション |
6 |
次のオプションから選択します:
セットアップ ウィザードを完了した後で、作成したロケーションにメイン番号を追加していることを確認してください。 |
7 |
このロケーションに適用する次の選択を行います。
|
8 |
[次へ] をクリックします。 |
9 |
利用可能な Cisco Webex SIP アドレスを入力し、[次へ] をクリックし、[完了] を選択します。 |
始める前に
新しいロケーションを作成するには、以下の情報を指定します。
-
ロケーションの住所
-
希望する電話番号(オプション)
1 |
https://admin.webex.comでControl Hubにログインし、[ ]の順に移動します。 新しいロケーションは、初回セットアップウィザードを使用して選択した国に対応する地域データセンターでホストされます。 |
2 |
ロケーションを設定します。
|
3 |
[保存 ] をクリックしてから、[ はい/いいえ ] を選択して、現在または後でロケーションに番号を追加します。 |
4 |
[はい] をクリック した場合、次のいずれかのオプションを選択します。
PSTN オプションの選択は各ロケーション レベルで行います (各ロケーションには PSTN オプションが 1 つしかありません)。展開に対して必要な数のオプションを組み合わせることができますが、各ロケーションには 1 つのオプションとなります。PSTN オプションを選択してプロビジョニングしたら、ロケーションの PSTN プロパティで [管理] をクリックすると、オプションを変更できます。ただし、Cisco PSTN などの一部のオプションは、別のオプションが割り当てられた後は使用できない場合があります。サポートケースを開く |
5 |
番号を今すぐに有効にするか、または後で有効にするかを選択します。 |
6 |
統合されていない CCP またはプレミス ベースの PSTN を選択した場合は、電話番号をコンマ区切り値として入力し、[検証] をクリックします。 特定のロケーションのための番号が追加されます。有効なエントリは [検証済みの番号] フィールドに移動し、無効なエントリは [番号の追加] フィールドに残り、エラー メッセージが表示されます。 番号の書式は、ロケーションの所在する国に応じ、ダイヤリングに関する地元の要件に従って定められます。たとえば、国コードが必要な場合には、コードを付けて入力することも、コードなしで入力してからコードが自動的に先頭に追加されるようにすることもできます。 |
7 |
[保存] をクリックします。 |
次に行うこと
ロケーションを作成した後、そのロケーションの緊急 911 サービスを有効にすることができます。詳細については「Webex Calling の RedSky 緊急 911 サービス」を参照してください。
始める前に
ロケーションに関連付けられているユーザーとワークスペースのリストを取得します。[サービス これらのユーザーとワークスペースを削除する必要があります。
し、ドロップダウン メニューから、削除する場所を選択します。ロケーションを削除する前に、このロケーションに関連付けられているすべての番号は、PSTN プロバイダーに戻されることに注意してください。つまり、これらの番号は所有しなくなります。
1 |
https://admin.webex.comでControl Hubにログインし、[ ]の順に移動します。 |
2 |
削除するロケーション |
3 |
[場所 の削除] を選択し、その場所を削除します。 一般的に、場所が完全に削除されるには数分かかりますが、最大で 1 時間かかる場合があります。ステータスを確認するには、ロケーション名の隣にある |
作成した後PSTNのセットアップ、名前、タイムゾーン、言語を変更できます。新しい言語は新しいユーザーとデバイスにのみ適用されることに注意してください。既存のユーザーおよびデバイスは古い言語を使用し続けます。
既存のロケーションについては、緊急時の 911 サービスを有効にすることができます。詳細については「Webex Calling の RedSky 緊急 911 サービス」を参照してください。
1 |
https://admin.webex.comでControl Hubにログインし、[ ]の順に移動します。 ロケーションの隣に [警告] 記号が表示される場合、そのロケーションの電話番号をまだ設定していないという意味です。その番号を設定するまで、通話の送受信が行えなんす。 |
2 |
(オプション) [PSTN 接続] の下で、すでに設定されているものに応じて、[クラウド接続 PSTN] または [プレミスベースの PSTN](ローカル ゲートウェイ) のいずれかを選択します。[管理] をクリックして設定を変更してから、[続行] を選択することにより、関連するリスクを承認します。以下のオプションのいずれかを選択して、[保存] クリックします。
|
3 |
ロケーションで、ドロップダウンリストから代表番 号を選択し、そのロケーションのユーザーがコールを発信および受信できるようにします。 メイン番号を自動アテンダントに割り当てて、外部発信者がそのロケーションの Webex Calling ユーザーに連絡できるようにします。そのロケーションの Webex Calling ユーザーは、発信時にこの番号を外部発信者 ID として使用することもできます。 |
4 |
(オプション) [緊急コール] で[緊急時のロケーション識別子] を選択して、このロケーションに割り当てることができます。 この設定はオプションで、必要な国にのみ適用されます。 一部の国 (例: フランス) の規制要件は、緊急電話を行い、緊急連絡時にセルの識別を確立するためのセルに関する規制要件であり、緊急権限によって利用可能になります。米国やカナダのような他の国々は、他の方法を用いて位置決定を実施しています。詳細については、「緊急時通話の強化 」を参照してください。 緊急通話プロバイダはアクセスネットワークに関する情報が必要な場合があります。新しいプライベートSIP拡張ヘッダーであるP-Access-Network-Infoを指定することで達成できます。ヘッダーにはアクセスネットワークに関連する情報が含まれます。 場所に緊急ロケーション識別子を設定すると、場所の値は SIP メッセージの一部としてプロバイダーに送信されます。緊急通話プロバイダーに連絡して、この設定が必要で、緊急通話プロバイダーから提供された値を使用する必要がある場合はそれを確認してください。」 |
5 |
このロケーションでユーザーがボイスメールをチェックするために呼び出せる [ボイスメール番号] を選択します。 |
6 |
(オプション) ロケーション ページの上部にある鉛筆アイコンをクリックし、必要に応じて [ロケーションの名前]、[アナウンス言語]、[メール言語]、[タイムゾーン]、[住所] を変更し、[保存] をクリックします。 [アナウンス言語] の変更は、このロケーションに追加された新規ユーザーや機能に対して直ちに有効になります。既存のユーザーや機能のアナウンス言語も変更する必要がある場合は、プロンプトが表示されたら、[既存のユーザーとワークスペースの変更] または [既存機能の変更] を選択します。[適用] をクリックします。[タスク] ページで進捗状況を確認できます。これが完了するまでは、これ以上変更を加えることはできません。 ロケーションの [タイム ゾーン] を変更しても、このロケーションに関連する機能のタイム ゾーンは更新されません。自動アテンダント、ハント グループ、コール キューなどの機能のタイム ゾーンを編集するには、タイムゾーンを更新する特定の機能の [全般設定] エリアに移動し、そこで編集して保存します。 |
これらの設定は社内ダイヤルに適用されるものであり、最初のセットアップ ウィザードでも設定できます。ダイヤル プランを変更すると、Control Hub の更新でこれらの変更を示す例番号が表示されます。
ロケーションに対する発信通話の権限を設定できます。これらのステップをご覧になり、発信権限を設定してください。
1 |
Control Hub にサインインし、[ ] の順に移動し、[内部ダイヤル] までスクロールします。 |
2 |
必要に応じて、次のオプションのダイヤル設定を行います。
|
3 |
特定の場所の内部ダイヤルを指定します。[通話]をクリックします。[ダイヤル] までスクロールし、必要に応じて内部ダイヤルを変更します。 ]の順に移動し、リストからロケーションを選択し、[
|
4 |
特定のロケーションの外部ダイヤルを指定します。[通話]をクリックします。[ダイヤル] までスクロールし、必要に応じて外部ダイヤルを変更します。 ]の順に移動し、リストからロケーションを選択し、[
ユーザーへの影響:
|
付加価値再販業者の場合、これらの手順を使用して Control Hub でローカル ゲートウェイの設定を開始できます。このゲートウェイがクラウドに登録されると、Webex Calling の 1 つ以上のロケーションで使用して、エンタープライズ PSTN サービス プロバイダーへのルーティングを提供できます。
ローカル ゲートウェイがある場所は、ローカル ゲートウェイが他の場所で使用されているときには削除できません。
始める前に
-
ロケーションが追加されたら、ロケーションに対してプレミスベース PSTN を設定する前に、トランクを作成する必要があります。
-
それぞれについて、ロケーションと固有の設定および番号を作成します。ロケーションはプレミスベース PSTN を追加する前に存在する必要があります。
-
Webex Calling でのプレミスベース PSTN (ローカル ゲートウェイ) 要件について理解しておいてください。
-
プレミスベース PSTN を持つロケーションに対して、複数のトランクを選択できませんが、複数のロケーションに対して同じトランクを選択することはできます。
1 |
https://admin.webex.comでControl Hubにログインし、[ ]の順に移動し、[トランクの追加]を選択します。 |
2 |
ロケーションを選択します。 |
3 |
トランクの名前を指定し、[保存] をクリックします。 名前は 24 文字以内にしてください。 |
次にやる必要
画面 [ドメインの登録]、[トランク グループ OTG/DTG]、[回線/ポート]、および [発信プロキシ アドレス] にトランク情報が表示されます。
プレミスベース PSTN を設定する準備ができているときに参照できるように、この情報を Control Hub からコピーして、ローカルのテキスト ファイルまたは文書に貼り付けておくことを推奨します。
この資格情報を紛失した場合には、Control Hub のトランク情報画面で生成する必要があります。[ユーザー名の取得とパスワードのリセット] をクリックして、トランクを使用するための認証資格情報の新しいセットを生成します。
1 |
https://admin.webex.comでControl Hubにログインし、[ ]の順に移動します。 |
2 |
変更する場所を選択し、[管理] をクリックします。 |
3 |
プレミスベース PSTN を選択して、[次へ] をクリックします。 |
4 |
ドロップダウン メニューからトランクを選択します。 トランク ページにアクセスして、トランク グループの選択を管理します。 |
5 |
確認通知をクリックし、[保存] をクリックします。 |
次にやる必要
Control Hub が生成した構成情報を記録し、パラメーターをローカル ゲートウェイ (たとえばオンプレミスの Cisco CUBE) にマップする必要があります。この記事 では、この手順について説明します。参考のため、どのように Control Hub の構成情報 (左側) が CUBE のパラメーター (右側) にマップされるかを示す例である次の図を参照してください。
ゲートウェイ自体の設定を正常に完了すると、Control Hub の [
] の順に移動し、作成したゲートウェイは割り当てたロケーションカードに一覧表示され、名前の左側に緑色のドットが付きます。このステータスは、ゲートウェイがセキュアに通話クラウドに対して登録され、そのロケーションでのアクティブな PSTN としての役割を果たしていることを示しています。Control Hub では、組織の電話番号を簡単に表示、アクティベート、削除、追加できます。詳細については、「Control Hub で電話番号を管理する」を参照してください。
Webex サービスを試していて、トライアルから有料サブスクリプションに変更したい場合は、メールでパートナーにリクエストできます。
1 |
https://admin.webex.comでControl Hubにログインし、建物のアイコン |
2 |
[サブスクリプション] タブを選択し、[今すぐ購入] をクリックします。 有料サブスクリプションへの変換に興味を持っていることを知らせるメールがパートナーに送信されます。 |
Control Hub を使用して、Webex アプリでユーザーに表示する利用可能な通話オプションの優先度を設定できます。シングルクリック通話を有効にすることもできます。詳細については、次を参照してください。Webex アプリ ユーザーの通話オプションを設定します。
ユーザーがコールを発信するときに、どの通話アプリケーションが開くかを制御できます。Unified CM または Webex Calling の資格を持つユーザーを持つ組織と、Cisco の有料通話サービスを使用しないユーザーのための混合モード展開など、通話クライアント設定を構成できます。詳細については、次を参照してください。通話動作をセットアップします。
Cisco IOS XE で 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 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 |
トランクの音声クラス コーデック 100 フィルタを設定します。この例では、すべてのトランクに同じコーデックフィルタが使用されます。正確な制御のために各トランクにフィルタを設定できます。 以下は、設定のフィールドの説明です。 音声クラス コーデック 100SIP トランクを介したコールの優先コーデックのみを許可するために使用されます。詳細については、「音声クラスコーデック」を参照してください。 Opus コーデックは、SIP ベースの PSTN トランクでのみサポートされています。PSTN トランクが音声 T1/E1 またはアナログ FXO 接続を使用する場合、コーデックの基本設定 1 opus を 音声クラス コーデック 100 構成から除外します。 |
4 |
音声クラス stun-usage 100 を設定して、Webex Calling トランクで ICE を有効にします。 以下は、設定のフィールドの説明です。 スタンの使用法 アイス ライトすべての Webex Calling のダイヤルピアに対して ICE-Lite を有効にして、可能な限り、メディア最適化を可能にするために使用。詳細については、「voice class stun usag e」および「stun usage ice lite」を参照してください。 メディア パスの最適化を使用したコール フローには、ICE-lite のスタン使用が必要です。SIP から TDM ゲートウェイへのメディア最適化を提供するには、IP-IP レッグで ICE-Lite が有効になっているループバック ダイヤル ピアを設定します。技術的な詳細は、アカウントまたはTACチームにお問い合わせください。 |
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 メッセージを変更するために使用されます。
以下は、設定のフィールドの説明です。
|
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ダイヤルピアを定義し、管理とトラブルシューティングを容易にするための意味のある説明を提供します。詳細については、ダイヤルピアの音声を参照してください。 destination-pattern BAD.BAD着信ダイヤル ピア グループを使用して発信コールをルーティングする場合は、ダミー接続先パターンが必要です。詳細については、destination-pattern (interface)を参照してください。 session protocol sipv2ダイヤルピア 20 0 が SIP コール レッグを処理するように指定します。詳細については、セッションプロトコル (ダイヤルピア)を参照してください。 session target ipv4:192.168.80.13宛先のターゲット IPv4 アドレスを示し、コールレグを送信します。セッションのターゲットは ITSP の IP アドレスです。詳細については、セッションターゲット (VoIP ダイヤルピア)を参照してください。 200 経由の着信 uriVIA ヘッダーの判断基準を IP ヘッダーと IP アドレスPSTNを定義します。ローカル ゲートウェイのすべての着信 IP PSTN コール レッグとダイヤル ピア 200 を一致させます。詳細については、着信 URLを参照してください。 バインド制御ソースインタフェース GigabitEthernet0/0/0PSTN に送信されるメッセージのソース インターフェイスと関連する 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 トランクを作成します。
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ダイヤルピアを定義し、管理とトラブルシューティングを容易にするための意味のある説明を提供します。詳細については、ダイヤルピアの音声を参照してください。 destination-pattern 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先に定義したトランスレーション プロファイルを適用して、発信トランクに渡す前にコール ルーティング タグを削除します。 destination-pattern BAD.BAD着信ダイヤル ピア グループを使用して発信コールをルーティングする場合は、ダミー接続先パターンが必要です。詳細については、destination-pattern (interface)を参照してください。 session protocol sipv2このダイヤル ピアが SIP コール レッグを処理することを指定します。詳細については、セッションプロトコル (ダイヤルピア)を参照してください。 セッションのターゲット 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 トランクを使用して、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 アドレス、およびインターフェイスが使用されます。オプションは、パブリックまたはプライベート(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 Software Research 」ページを参照してください。プラットフォームを検索し、提 案されたリリースのいずれかを選択します。
-
ISR4000 シリーズ ルータは、Unified Communications および Security テクノロジー ライセンスの両方で設定する必要があります。
-
Catalyst Edge 8000シリーズのルーターには、ボイスカードまたはDSPが装備されており、DNA Essentialsのライセンスが必要です。ボイスカードやDSPのないルーターには、最低限のDNA Essentialsライセンスが必要です。
-
大容量の要件については、High Security(HSEC)ライセンスおよび追加のスループットエンタイトルメントが必要になる場合があります。
詳細については、認証コー ドを参照してください。
-
-
ビジネスポリシーに従うプラットフォームのベースライン設定を構築します。特に、以下を設定し、作業を確認します。
-
NTP
-
Acl
-
ユーザー認証とリモートアクセス
-
DNS
-
IP ルーティング
-
IP アドレス
-
-
Webex Calling に向かうネットワークは IPv4 アドレスを使用する必要があります。ローカル ゲートウェイの完全修飾ドメイン名(FQDN)またはサービス レコード(SRV)アドレスは、インターネット上のパブリック IPv4 アドレスに解決する必要があります。
-
Webex に面しているローカル ゲートウェイ インターフェイスのすべての SIP ポートとメディア ポートは、インターネットから直接アクセスするか、静的 NAT 経由でアクセスする必要があります。それに応じてファイアウォールを更新してください。
-
署名付き証明書をローカル ゲートウェイにインストールします (詳細な設定手順は次のとおりです)。
-
Cisco Webex 音声およびビデオ プラットフォームへの通話でサポートされているルート認証局とはに詳述 されているパブリック認証局 (CA) は、デバイス証明書に署名する必要があります。
-
トランクの作成時に Control Hub で設定された FQDN は、ルータの共通名(CN)またはサブジェクト代替名(SAN)の証明書である必要があります。たとえば、次のようなものです。
-
組織の 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 バンドルをローカル ゲートウェイにアップロードします。
構成
1 |
次のように、有効でルーティング可能な IP アドレスをレイヤ 3 インターフェイスに割り当てます。
|
2 |
対称暗号化を使用してルータの STUN クレデンシャルを保護します。プライマリ暗号化キーと暗号化タイプを次のように設定します。 |
3 |
希望する認証局 (CA) によって署名された証明書を使用して暗号化トラストポイントを作成します。 |
4 |
中間(またはルート)CA 証明書を使用して新しい証明書を認証し、証明書をインポートします(ステップ 4)。次の exec または configuration コマンドを入力します。
|
5 |
次の exec または configuration コマンドを使用して、署名済みホスト証明書をインポートします。
|
6 |
TLS1.2 排他を有効にし、次の設定コマンドを使用してデフォルトのトラストポイントを指定します。
|
7 |
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 の既存のロケーションの 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 |
トランクの音声クラス コーデック 100 コーデック フィルタを設定します。この例では、すべてのトランクに同じコーデックフィルタが使用されます。正確な制御のために各トランクにフィルタを設定できます。 以下は、設定のフィールドの説明です。 音声クラス コーデック 100SIP トランクを介したコールの優先コーデックのみを許可するために使用されます。詳細については、「音声クラスコーデック」を参照してください。 Opus コーデックは、SIP ベースの PSTN トランクでのみサポートされています。PSTN トランクが音声 T1/E1 またはアナログ FXO 接続を使用する場合、コーデックの基本設定 1 opus を 音声クラス コーデック 100 構成から除外します。 |
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 の背後にローカル ゲートウェイを展開する場合にのみ必要です。 メディア パスの最適化を使用したコール フローには、ICE-lite のスタン使用が必要です。SIP から TDM ゲートウェイへのメディア最適化を提供するには、IP-IP レッグで ICE-Lite が有効になっているループバック ダイヤル ピアを設定します。技術的な詳細については、アカウントまたは TAC チームにお問い合わせください。 |
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 で設定された LGW FQDN または SRV を使用します。 |
8 |
SIP メッセージ操作プロファイルを設定します。ゲートウェイがパブリック IP アドレスで設定されている場合は、次のようにプロファイルを設定するか、NAT を使用している場合は、次のステップにスキップします。この例では、cube1.lgw.com はローカル ゲートウェイ用に設定された FQDN であり、「198.51.100.1」は Webex Calling に面したローカル ゲートウェイ インターフェイスのパブリック IP アドレスです。 以下は、設定のフィールドの説明です。 ルール10と20Webex がローカル ゲートウェイからのメッセージを認証できるようにするには、SIP リクエストと応答メッセージの「Contact」ヘッダーに Control Hub のトランク用にプロビジョニングされた値が含まれている必要があります。これは、単一のホストの FQDN、またはデバイスのクラスタに使用される SRV ドメイン名のいずれかになります。 ローカル ゲートウェイにパブリック IP アドレスを設定している場合は、次の手順をスキップします。 |
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までのルールパブリックアドレス参照を設定済みのプライベートアドレスに変換し、Webex からのメッセージを CUBE で正しく処理できるようにします。 詳細については、「音声クラス sip プロファイル」を参照してください。 |
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ダイヤルピアを定義し、管理とトラブルシューティングを容易にするための意味のある説明を提供します。詳細については、ダイヤルピアの音声を参照してください。 destination-pattern BAD.BAD着信ダイヤル ピア グループを使用して発信コールをルーティングする場合は、ダミー接続先パターンが必要です。詳細については、destination-pattern (interface)を参照してください。 session protocol sipv2ダイヤルピア 20 0 が SIP コール レッグを処理するように指定します。詳細については、セッションプロトコル (ダイヤルピア)を参照してください。 session target ipv4:192.168.80.13宛先のターゲット IPv4 アドレスを示し、コールレグを送信します。セッションのターゲットは ITSP の IP アドレスです。詳細については、セッションターゲット (VoIP ダイヤルピア)を参照してください。 200 経由の着信 uriVIA ヘッダーの判断基準を IP ヘッダーと IP アドレスPSTNを定義します。ローカル ゲートウェイのすべての着信 IP PSTN コール レッグとダイヤル ピア 200 を一致させます。詳細については、着信 URLを参照してください。 バインド制御ソースインタフェース GigabitEthernet0/0/0PSTN に送信されるメッセージのソース インターフェイスと関連する 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 トランクを作成します。
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ダイヤルピアを定義し、管理とトラブルシューティングを容易にするための意味のある説明を提供します。詳細については、ダイヤルピアの音声を参照してください。 destination-pattern 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先に定義したトランスレーション プロファイルを適用して、発信トランクに渡す前にコール ルーティング タグを削除します。 destination-pattern BAD.BAD着信ダイヤル ピア グループを使用して発信コールをルーティングする場合は、ダミー接続先パターンが必要です。詳細については、destination-pattern (interface)を参照してください。 session protocol sipv2このダイヤル ピアが SIP コール レッグを処理することを指定します。詳細については、セッションプロトコル (ダイヤルピア)を参照してください。 セッションのターゲット 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 では現在、新しいカスタム署名の作成リクエストをサポートしていません。
ローカル ゲートウェイとして CUBE の高可用性を実装
基礎
前提条件
Webex Calling のローカル ゲートウェイとして CUBE HA を展開する前に、以下の概念を深く理解するようにしてください。
-
ステートフル コール保持のための CUBE エンタープライズによるレイヤー 2 ボックス間冗長性
この記事で提供される構成ガイドラインは、既存の音声構成が設定されていない専用のローカル ゲートウェイ プラットフォームが使用されていることを前提としています。既存の CUBE エンタープライズ展開が、Cisco Webex Calling のローカル ゲートウェイ機能を使用するように変更されている場合、既存のコール フローと機能が中断されないようにして、CUBE HA 設計要件に準拠するように、設定に注意してください。
ハードウェアとソフトウェアのコンポーネント
ローカルゲートウェイとしての CUBE HA には IOS-XE バージョン 16.12.2 以降、および CUBE HA と LGW 機能の両方をサポートするプラットフォームが必要です。
この記事のコマンドとログの表示は、vCUBE(CSR1000v)で実装された Cisco IOS-XE 16.12.2 のソフトウェアの最小リリースに基づいています。
参考資料
さまざまなプラットフォーム向けの詳細な CUBE HA 設定ガイドを次に示します。
-
CSR 1000v (vCUBE)— https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-cube-high-availability-CSR1000v.html
-
Cisco Preferred Architecture for Cisco Webex Calling— https://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Collaboration/hybrid/AltDesigns/PA-WbxCall.pdf
Webex Calling ソリューションの概要
Cisco Webex Calling は、複数の PSTN オプションにより、オンプレミスの PBX 電話サービスにマルチテナントのクラウドベースの代替手段を提供するコラボレーションソリューションです。
この記事の焦点は、ローカル ゲートウェイの展開 (以下を参照) です。Webex Calling のローカルゲートウェイ(プレミスベースの PSTN)トランクによって、顧客が所有する PSTN サービスへの接続が可能になります。また、Cisco Unified CM などのオンプレミス IP PBX 展開への接続も提供します。クラウド間のすべての通信は、メディア向け SIP および SRTP で TLS トランスポートを使用してセキュリティ保護されています。
次の図では、既存の IP PBX なしでの Webex Calling 展開を示し、単一または複数サイトの展開に適用されます。この記事に記載されている設定は、この展開に基づいています。
レイヤー 2 のボックス間冗長性
CUBE HA レイヤー 2 ボックス間冗長性は、冗長性グループ (RG) インフラストラクチャ プロトコルを使用して、ルーターのアクティブ/スタンバイ ペアを形成します。このペアは、それぞれのインターフェイスで同じ仮想 IP アドレス (VIP) を共有し、ステータ スメッセージを継続的に交換します。CUBE セッションはルーターのペアリングのチェックポイントであり、アクティブ ルーターがサービスを停止した場合に、スタンバイ ルーターがすべての CUBE コール処理の責任を果たすことができるようになりました。その結果、シグナリングとメディアのステートフルな保持が可能になりました。
チェック ポイントは、メディア パケットのある接続されたコールに限定されます。転送中のコールはチェック ポイントではありません (たとえば、試行中または呼出状態)。
この記事では、CUBE HA は、ステートフルコール保持の CUBE ハイ アベイラビリティ (HA) レイヤー 2 ボックス間 (B2B) 冗長性を参照します。
IOS-XE 16.12.2 では、CUBE HA を Cisco Webex Calling トランク(プレミスベースの PSTN)展開のローカルゲートウェイとして展開できます。この記事では、設計の考慮事項と構成について説明します。この図は、Cisco Webex Calling トランク展開のローカルゲートウェイとしての一般的な CUBE HA 設定を示しています。
冗長性グループ インフラストラクチャ コンポーネント
冗長グループ (RG) インフラ コンポーネントは、2 つの CUBE 間でのボックス間通信インフラストラクチャのサポートを提供し、最終的に安定した冗長性の状態をネゴシエートします。このコンポーネントは次の機能も提供します。
-
2 つの CUBE 間で keepalive と hello メッセージを交換することで (コントロール インターフェイス)、各ルータの最終的な冗長状態をネゴシエートする HSRP のようなプロトコル。上の図の GigabitEthernet3です。
-
アクティブからスタンバイ ルータ (データ インターフェイス経由) への各コールに関して、シグナリングとメディアの状態をチェックするための転送メカニズム。上記の図の GigabitEthernet3です。
-
トラフィック インターフェイスの仮想 IP (VIP) インターフェイスの構成と管理 (複数のトラフィック インターフェイスは同じ RG グループを使用して構成できます)。GigabitEthernet 1 および 2 はトラフィック インターフェイスと見なされます。
この RG コンポーネントは、音声 B2B HA をサポートするように特別に構成する必要があります。
信号とメディアの両方に関する仮想 IP (VIP) アドレス管理
B2B HA は、冗長性を確保する際に VIP に依存します。CUBE HA ペアの両方の CUBE で VIP および関連する物理インターフェイスは、同じ LAN サブネット上に存在している必要があります。VIP の構成、および特定の音声アプリケーション (SIP) への VIP インターフェイスのバインドは、音声 B2B HA サポートに必須です。Unified CM、Webex Calling アクセス SBC、サービス プロバイダー、プロキシなどの外部デバイスは、CUBE HA ルーターを通過するコールの宛先 IP アドレスとして VIP を使用します。そのため、Webex Calling の観点から、CUBE HA ペアは単一のローカル ゲートウェイとして機能します。
確立されたコールのコール シグナリングおよび RTP セッション情報は、アクティブなルーターからスタンバイ ルーターへのチェックポイントです。アクティブ ルーターがダウンすると、スタンバイ ルーターが引き継ぎ、最初のルーターによって以前にルーティングされた RTP ストリームを継続して転送します。
フェイルオーバー時に一時的な状態のコールは、切り替え後には保存されません。たとえば、まだ完全に確立されていない、または転送や保留の機能により変更中のコールなどです。確立されたコールは、切り替え後に切断される場合があります。
コールのステートフル フェールオーバーのローカル ゲートウェイとして CUBE HA を使用するには、以下の要件があります。
-
CUBE HA は TDM またはアナログ インターフェイスを共存させることはできません
-
Gig1 および Gig2 はトラフィック (SIP/RTP) インターフェイス、Gig3 は冗長グループ (RG) コントロール/データ インターフェイスと呼ばれます
-
グループ id 1 とグループ id 2 を持つ同じレイヤー 2 ドメインに配置できる CUBE HA ペアは 2 つまでです。同じグループ ID で 2 つの HA ペアを構成する場合、RG コントロール/データ インターフェイスは異なるレイヤー 2 ドメイン (vlan、個別のスイッチ) に属している必要があります
-
ポート チャネルは、RG コントロール/データとトラフィック インターフェイスの両方でサポートされています
-
すべてのシグナリング/メディアは、仮想 IP アドレスから供給されます
-
プラットフォームが CUBE HA 関係にリロードされると、常にスタンバイとして起動します
-
すべてのインターフェイスの下位アドレス (Gig1、Gig2、Gig3) は、同じプラットフォームにある必要があります
-
冗長性インターフェイス識別子、rii は同じレイヤー 2 のペア/インターフェイスの組み合わせに対して固有である必要があります
-
両方の CUBE の構成は、物理構成を含む必要があり、同じ種類のプラットフォームと IOS-XE バージョンで実行されている必要があります
-
ループバック インターフェイスは、常に起動しているためバインドとして使用できません
-
複数のトラフィック (SIP/RTP) インターフェイス (Gig1、Gig2) では、インターフェイスのトラッキングが構成されている必要があります
-
CUBE-HA は、RG コントロール/データ リンク (Gig3) のクロスオーバー ケーブル接続ではサポートされていません
-
両方のプラットフォームは同一である必要があり、すべての同様のインターフェイスで CUBE HA が機能するように [物理スイッチ] を介して接続します。例: CUBE-1 と CUBE-2 の GE0/0/0 は同じスイッチ上で終了する必要があります
-
直接 CUBE 上で、またはいずれかの側のデータ HA で WAN を終了することができません
-
アクティブ/スタンバイは両方とも同じデータセンターにある必要があります
-
冗長性 (RG コントロール/データ、Gig3) に別の L3 インターフェイスを使用する必要があります。トラフィックに使用されるインターフェイスは、HA keepalives およびチェックポイントに使用できません
-
フェールオーバー時に、以前アクティブだった CUBE は、設計によって再読み込みされ、シグナリングとメディアを保持します
両方の CUBE で冗長性を構成する
HA ペアで使用し、仮想 IP を表示するために、両方の CUBE でレイヤー 2 ボックス間冗長性を構成する必要があります。
1 |
インターフェイスのステータスを追跡するために、グローバル レベルでインターフェイス トラッキングを構成します。
トラッキング CLI は、トラフィック インターフェイスがダウンした後、アクティブ ルートがアクティブな役割を果たすように、RG 内で音声トラフィックインターフェイスの状態を追跡するために使用されます。 | ||
2 |
アプリケーション冗長性サブモード下の VoIP HA で使用する RG を構成します。
この構成で使用されるフィールドの説明を次に示します。
| ||
3 |
CUBE アプリケーションのボックス間の冗長性を有効にします。
redundancy-group 1: このコマンドを追加および削除するには、更新された構成を有効にするために再読み込みが必要です。すべての構成が適用された後で、プラットフォームを再読み込みします。 | ||
4 |
以下に示すように、Gig1 と Gig2 インターフェイスをそれぞれの仮想 IP で構成し、冗長性インターフェイス識別子 (rii) を適用します。
この構成で使用されるフィールドの説明を次に示します。
| ||
5 |
最初の CUBE 構成を保存し、再読み込みします。 最後にリロードするプラットフォームは常にスタンバイです。
VCUBE-1 が完全に起動したら、 VCUBE-2 の構成を保存し、再読み込みします。
| ||
6 |
ボックス間の構成が期待どおりに機能していることを確認します。関連する出力は太字で強調表示されます。 VCUBE-2 を最後にリロードし、設計上の考慮事項に従います。最後にリロードするプラットフォームは常に [スタンバイ] 状態です。 |
両方の CUBE でローカル ゲートウェイを構成する
この例の構成では、Control Hub から以下のトランク情報を使用して、VCUBE-1、VCUBE-2 の両方のプラットフォームでローカルゲートウェイを構成しています。この設定のユーザー名とパスワードは以下のとおりです。
-
ユーザー名: フセイン1076LGU_
-
パスワード:lOV12MEaZx
1 |
クレデンシャルまたは共有秘密で使用する前に、以下のコマンドを使用して、設定キーがパスワードに対して作成されていることを確認してください。Type 6 パスワードは、AES 暗号化とこのユーザー定義の設定キーを使用して暗号化されます。
これは、上に表示されている Control Hub のパラメーターに基づき、両方のプラットフォームに適用し、保存し、リロードするローカ ルゲートウェイの構成です。Control Hub からの SIP ダイジェスト資格情報は、太字でハイライトされます。
Show コマンド出力を表示するには、VCUBE-2 の後に VCUBE-1 をリロードし、VCUBE-1 をスタンバイ CUBE にして、VCUBE-2 をアクティブ CUBE にします。 |
2 |
任意の時点で、1 個のプラットフォームのみが、Webex Calling アクセス SBC を使用したローカル ゲートウェイとしてアクティブ登録を保持します。以下の show コマンドの出力を見てみましょう。 show redundancy application group 1 sip-ua レジスタ ステータスを表示
上記の出力から、VCUBE-2 は Webex Calling アクセス SBC への登録を維持するアクティブ LGW であり、「show sip-ua 登録ステータス」の出力は VCUBE-1 では空白です。 |
3 |
VCUBE-1 で次のデバッグを有効にします
|
4 |
この場合、アクティブ LGW、VCUBE-2 で次のコマンドを実行してフェールオーバーをシミュレートします。
アクティブからスタンバイ LGW への切り替えは、上記に一覧表示されている CLI に加えて、以下のシナリオで発生します。
|
5 |
VCUBE-1 が Webex Calling アクセス SBC に登録されているかどうかを確認します。VCUBE-2 は今すぐにリロードされます。
VCUBE-1 がアクティブ LGW になりました。 |
6 |
仮想 IP を通じて SIP REGISTER を Webex Calling に送信し、200 OK を受信する VCUBE-1 に関連するデバッグ ログを確認してください。
|
Webex Calling に Unified CM を構成する
ローカル ゲートウェイへトランクするための SIP トランク セキュリティ プロファイルを構成する
ローカル ゲートウェイと PSTN ゲートウェイが同じデバイス上に存在する場合、Unified CM を有効にして、同じデバイスから発信された 2 個の異なるトラフィックの種類 (Webex と PSTN のコール) を区別し、これらのコール タイプに対して差別化されたクラスのサービスを適用する必要があります。この差別化されたコール処理は、Unified CM および結合されたローカル ゲートウェイと PSTN ゲートウェイ デバイスの 2 つのトランクをプロビジョニングすることで行われます。これは、2 つのトランクに異なる SIP リスニング ポートを必要とします。
次の設定でローカル ゲートウェイ トランクの専用の SIP トランク セキュリティ プロファイルを作成します。
|
ローカル ゲートウェイ トランクの SIP プロファイルを構成する
次の設定でローカル ゲートウェイ トランク用の専用の SIP プロファイルを作成します。
|
Webex からのコールのコール検索スペースを作成する
次の設定で Webex から発信されたコールのためのコール検索スペースを作成します。
最後のパーティション onNetRemote は、Intercluster Lookup Service (ILS) または Global Dialplan Replication (GDPR) を使用して、Unified CM クラスター間でルーティング情報が交換されるマルチクラスター環境でのみ使用されます。 |
Webex 間で SIP トランクを構成する
次の設定を使用して、ローカル ゲートウェイ経由での Webex 間のコールに SIP トランクを作成します。
|
Webex のルート グループを構成する
次の設定でルート グループを作成します。
|
Webex のルート リストを構成する
次の設定でルート リストを作成します。
|
Webex の移動先のパーティションを作成する
次の設定で Webex の移動先のパーティションを作成します。
|
次にやる必要
このパーティションは、Webex の宛先にアクセスする必要があるすべてのコール検索スペースに追加してください。このパーティションは、PSTN から Webex への発信がルーティングされるように、PSTN トランクの着信コール検索スペースとして使用されるコール検索スペースに特に追加する必要があります。
Webex の移動先のルート パターンを構成する
次の設定で Webex の各 DID 範囲のルート パターンを構成します。
|
Webex の簡略サイト間ダイヤル正規化を構成する
短縮されたサイト間ダイヤルが Webex に必要な場合は、Webex の各 ESB 範囲にダイヤル正規化パターンを設定します。
|
Webex Calling の機能をセットアップ
ハント グループをセットアップする
ハント グループは着信をグループのユーザーまたはワークスペースにルーティングします。グループ全体にルーティングするパターンを構成することもできます。
ハント グループのセットアップ方法の詳細については、「Cisco Webex Control Hub のハント グループ」を参照してください。
コール キューを作成する
コール キューを作成すれば、顧客の発信にすぐに応答がない場合、誰かが応答できるようになるまで自動応答にしたり、お詫びのメッセージや保留中の音楽が流れるようにしたりすることができます。
コール キューをセットアップおよび管理する方法の詳細については、「Cisco Webex Control Hub でコール キューを管理する」を参照してください。
レセプショニスト クライアントを作成する
フロントオフィス担当者のニーズに応えますユーザーを電話アテンダントに設定することで、組織内の特定の人物への着信をスクリーニングできます。
レセプショニストクライアントのセットアップ方法と表示方法については、「Cisco Webex Control Hub のレセプショニストクライアント」を参照してください。
自動アテンダントを作成して管理する
セットアップ メニューと、応答サービス、ハント グループ、ボイスメール ボックスや実際のオペレーターなどへのルーティング機能によって、適切なあいさつを返すことができます。24 時間分のスケジュールを作成できます。あるいは、時間内か外かに応じて、異なるオプションを使うこともできます。
自動アテンダントの作成と管理の方法については、「Cisco Webex Control Hub で自動アテンダントを管理する」を参照してください。
ページング グループを構成する
グループ ページングは、特定のページング グループに割り当てられた番号または内線番号をダイヤルすることにより、最大 75 名のターゲット ユーザーに一方向通話を行うか、グループ ページングを行うことができるようにします。
ページング グループのセットアップ方法と編集方法の詳細については、「Cisco Webex Control Hub のページング グループを構成する」を参照してください。
コール ピックアップを設定する
ユーザーがそれぞれの通話に応答できるよう、コール ピックアップ グループを作成し、チームワークとコラボレーションを強化します。ユーザーをコールピックアップグループに追加しておけば、グループメンバーが席を離れていたり、電話中だったりした場合、別のメンバーが電話に出ることができます。
コールピックアップグループのセットアップ方法については 、「Cisco Webex Control Hub でのコールピックアップ」を参照してください。
コール パークをセットアップする
コール パークにより、ユーザーの定義されたグループは、コール パーク グループの他の利用可能なメンバーに対するコールをパークすることができます。パーク中のコールは、グループの他のメンバーが自分の電話で取ることができます。
コールパークのセットアップ方法の詳細については、「Cisco Webex Control Hub コールパーク」を参照してください。
ユーザーの割り込みを有効にする
1 |
https://admin.webex.comの顧客ビューから、[ ]の順に移動します。 |
2 |
ユーザーを選択し、[Calling] をクリックします。 |
3 |
[ユーザー権限 間]セクションに移動し、[割り込み]を選択します。 |
4 |
トグルをオンにすると、他のユーザーがこのユーザーの進行中のコールに自分自身を追加できるようになります。 |
5 |
このユーザーがコールに割り込むときに他のユーザーにトーンを再生する場合は、[このユーザーがコールで割り込むときにトーンを再 生] にチェックを入れます。 [このユーザーが通話に割り込みを行ったときにトーンを再生する] 設定は、Customer Experience Basic および Essentials スーパーバイザーの割り込み機能には適用されません。スーパーバイザに対してこのオプションを有効にした場合でも、スーパーバイザがコール キュー コールに割り込んだときに、システムはエージェントに通知トーンを再生しません。 スーパーバイザがコールで割り込むときにエージェントにトーンを再生する場合は、[エージェントの通知トーン] 設定を使用して有効にできます。詳細については、「Webex Customer Experience Basi c」または「Webex Customer Experience Essentials」の「キューの作 成」セクションを参照してください。 |
6 |
[保存] をクリックします。 |
ユーザーのプライバシーを有効にする
1 |
Control Hub にサインインし、[ ] の順に移動します。 |
2 |
ユーザーを選択し、[Calling] をクリックします。 |
3 |
[ユーザー権限 間]領域に移動し、[プライバシー]を選択します。 |
4 |
このユーザーに適切な [自動音声応答のプライバシー] 設定を選択します。
|
5 |
[プライバシーを有効にする] チェックボックスをオンにします。ドロップダウンリストからメンバーを選択しないことで、全員をブロックすることができます。または、このユーザーの回線ステータスを監視できるユーザー、ワークスペース、仮想回線を選択することもできます。 ロケーション管理者の場合、割り当てられたロケーションに関連するユーザー、ワークスペース、仮想回線のみがドロップダウン リストに表示されます。 [プライバシーを有効にす る] チェックボックスをオフにすると、全員が回線のステータスを監視できるようになります。 |
6 |
ダイレクト コール ピックアップと割り込みのプライバシーを有効にするには、[ダイレクト コール ピックアップと割り込みのプライバシーを強 制] チェックボックスをオンにします。
|
7 |
[名前でメンバーを追加] から、電話回線のステータスを監視し、ダイレクト コール ピックアップと割り込みを呼び出せるユーザ、ワークスペース、仮想回線を選択します。 |
8 |
選択したメンバーをフィルタリングするには、[名前、番号、またはextでフィルタリン グ]フィールドを使用します。 |
9 |
選択したすべてのメンバーを削除するには、[すべて削 除]をクリックします。 個々のメンバーを削除するには、メンバーの名前の隣の [削除] をクリックします。 |
10 |
[保存] をクリックします。 |
モニタリングの設定
ユーザーの監視対象回線の最大数は 50 です。ただし、モニタリング リストを設定する際には、Webex Calling とネットワーク間の帯域幅に影響を与えるメッセージの数を考慮してください。また、ユーザの電話機の回線ボタンの数によって、監視される回線の最大数を決定します。
1 |
の顧客ビューから、[管理]に移動し、[ユーザー]をクリックします。https://admin.webex.com |
2 |
変更するユーザーを選択し、[Calling] をクリックします。 |
3 |
[ユーザー権限 間] セクションに移動し、[モニタリング] を選択します。 |
4 |
次から選択します:
ユーザーモニタリングのために、[モニタリング対象の回線を追加(Add Monitored Line)] リストに仮想回 線 を含めることができます。 |
5 |
このユーザーにパークされたコールを通知するかどうかを選択し、監視対象のユーザーまたはコール パーク内線を検索し、[保存] をクリックします。 Control Hub の監視回線リストは、ユーザーのデバイス上で表示される監視回線の順番に対応します。監視対象回線のリストをいつでも並べ替えることができます。 監視対象の回線に表示される名前は、ユーザ、ワークスペース、仮想回線の [発信者 ID 名(Caller ID First Name)] フィールドと [姓(Last Name)] フィールドに入力された名前です。 |
ユーザーのコール ブリッジ警告トーンを有効にする
開始する前に
1 |
Control Hub にサインインし、[ ] の順に移動します。 |
2 |
ユーザーを選択し、[通話] タブをクリックします。 |
3 |
[ユーザー権限間] に移動し、[コールブリッジ警告トーン] をクリックします。 |
4 |
[コールブリッジング警告トーン] をオンにして、[保存] をクリックします。 デフォルトでは、この機能は有効になっています。 MPP 共有回線のコール ブリッジングの詳細については、「マルチプラットフォーム デスク フォンの共有回線」を参照してください。 Webex アプリの共有回線でのコール ブリッジングの詳細については、「WebexApp の共有回線アピアランス」を参照してください。 |
ユーザーのためにホテリングをオンにする
1 |
の顧客ビューから、[管理]に移動し、[ユーザー]を選択します。https://admin.webex.com |
2 |
ユーザーを選択し、[通話] タブをクリックします。 |
3 |
[ユーザー間の権限]セクシ ョンに移動し、[ホテリン グ]を選択してトグルをオンにします。 |
4 |
[ホテリングロケーショ ン] 検索フィールドにホテリングホストの名前または番号を入力し、ユーザーに割り当てるホテリングホストを選択します。 選択できるホテリングホストは 1 つだけです。別のホテリング ホストを選択した場合、最初のホストは削除されます。 ロケーション管理者の場合、割り当てられたロケーションに関連するホテリング ホストのみを割り当てることができます。 |
5 |
ユーザーがホテリングホストに関連付けることができる時間を制限するには、[関連付け期間を制 限(Limit Association Period)] ドロップダウンからユーザーがホテリングホストを使用できる時間を選択します。 ユーザーは選択した時間の後に自動的にログアウトされます。 ユーザーに指定された制限関連付け期間が、選択したホテリングホストの制限関連付け期間を超えると、画面にエラーメッセージが表示されます。たとえば、ホテリング ホストに制限時間が 12 時間あり、ユーザーの制限時間が 24 時間ある場合、エラーメッセージが表示されます。この場合、ユーザーにより多くの時間が必要な場合は、ホテリングホストの制限関連期間を延長する必要があります。 |
6 |
[保存] をクリックします。 ユーザは、ユーザ ハブから使用するホテリング ホストを検索し、検索することもできます。詳細については、「どこからでも通話プロファイルにアクセスする」を参照してください。 |
Webex Calling の導入傾向と使用レポート
通話レポートを表示する
Control Hub の [アナリティクス] ページを使用して、ユーザーがどのように Webex Calling と Webex アプリ (エンゲージメント) を使用しているか、また、通話のメディア エクスペリエンスの質について洞察を得ることができます。Webex Calling 分析にアクセスするには、Control Hub にサインインし、[アナリティクス] に移動し、[Calling] タブを選択します。
1 |
詳細な通話履歴レポートについては、Control Hub にサインインし、 に移動します。 |
2 |
[通話履歴の詳細] を選択します。 専用インスタンスを使用する通話の詳細については、「専用インスタンスの分析」を参照してください。 |
3 |
メディア品質データにアクセスするには、Control Hub にサインインし、[アナリティクス] に移動し、[Calling] を選択します。 詳細については、「クラウド コラボレーション ポートフォリオのためのアナリティクス」を参照してください。
|
CScanツールを実行する
CScan は、Webex Calling へのネットワーク接続をテストするために設計されたネットワーク準備ツールです。
詳細については、「CScan を使用して Webex Calling ネットワークの品質をテストする」をご覧ください。 |
ローカル ゲートウェイとして CUBE の高可用性を実装
基礎
前提条件
Webex Calling のローカル ゲートウェイとして CUBE HA を展開する前に、以下の概念を深く理解するようにしてください。
-
ステートフル コール保持のための CUBE エンタープライズによるレイヤー 2 ボックス間冗長性
この記事で提供される構成ガイドラインは、既存の音声構成が設定されていない専用のローカル ゲートウェイ プラットフォームが使用されていることを前提としています。既存の CUBE エンタープライズ展開が、Cisco Webex Calling のローカル ゲートウェイ機能を使用するように変更されている場合、既存のコール フローと機能が中断されないようにして、CUBE HA 設計要件に準拠するように、設定に注意してください。
ハードウェアとソフトウェアのコンポーネント
ローカルゲートウェイとしての CUBE HA には IOS-XE バージョン 16.12.2 以降、および CUBE HA と LGW 機能の両方をサポートするプラットフォームが必要です。
この記事のコマンドとログの表示は、vCUBE(CSR1000v)で実装された Cisco IOS-XE 16.12.2 のソフトウェアの最小リリースに基づいています。
参考資料
さまざまなプラットフォーム向けの詳細な CUBE HA 設定ガイドを次に示します。
-
CSR 1000v (vCUBE)— https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-cube-high-availability-CSR1000v.html
-
Cisco Preferred Architecture for Cisco Webex Calling— https://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Collaboration/hybrid/AltDesigns/PA-WbxCall.pdf
Webex Calling ソリューションの概要
Cisco Webex Calling は、複数の PSTN オプションにより、オンプレミスの PBX 電話サービスにマルチテナントのクラウドベースの代替手段を提供するコラボレーションソリューションです。
この記事の焦点は、ローカル ゲートウェイの展開 (以下を参照) です。Webex Calling のローカルゲートウェイ(プレミスベースの PSTN)トランクによって、顧客が所有する PSTN サービスへの接続が可能になります。また、Cisco Unified CM などのオンプレミス IP PBX 展開への接続も提供します。クラウド間のすべての通信は、メディア向け SIP および SRTP で TLS トランスポートを使用してセキュリティ保護されています。
次の図では、既存の IP PBX なしでの Webex Calling 展開を示し、単一または複数サイトの展開に適用されます。この記事に記載されている設定は、この展開に基づいています。
レイヤー 2 のボックス間冗長性
CUBE HA レイヤー 2 ボックス間冗長性は、冗長性グループ (RG) インフラストラクチャ プロトコルを使用して、ルーターのアクティブ/スタンバイ ペアを形成します。このペアは、それぞれのインターフェイスで同じ仮想 IP アドレス (VIP) を共有し、ステータ スメッセージを継続的に交換します。CUBE セッションはルーターのペアリングのチェックポイントであり、アクティブ ルーターがサービスを停止した場合に、スタンバイ ルーターがすべての CUBE コール処理の責任を果たすことができるようになりました。その結果、シグナリングとメディアのステートフルな保持が可能になりました。
チェック ポイントは、メディア パケットのある接続されたコールに限定されます。転送中のコールはチェック ポイントではありません (たとえば、試行中または呼出状態)。
この記事では、CUBE HA は、ステートフルコール保持の CUBE ハイ アベイラビリティ (HA) レイヤー 2 ボックス間 (B2B) 冗長性を参照します。
IOS-XE 16.12.2 では、CUBE HA を Cisco Webex Calling トランク(プレミスベースの PSTN)展開のローカルゲートウェイとして展開できます。この記事では、設計の考慮事項と構成について説明します。この図は、Cisco Webex Calling トランク展開のローカルゲートウェイとしての一般的な CUBE HA 設定を示しています。
冗長性グループ インフラストラクチャ コンポーネント
冗長グループ (RG) インフラ コンポーネントは、2 つの CUBE 間でのボックス間通信インフラストラクチャのサポートを提供し、最終的に安定した冗長性の状態をネゴシエートします。このコンポーネントは次の機能も提供します。
-
2 つの CUBE 間で keepalive と hello メッセージを交換することで (コントロール インターフェイス)、各ルータの最終的な冗長状態をネゴシエートする HSRP のようなプロトコル。上の図の GigabitEthernet3です。
-
アクティブからスタンバイ ルータ (データ インターフェイス経由) への各コールに関して、シグナリングとメディアの状態をチェックするための転送メカニズム。上記の図の GigabitEthernet3です。
-
トラフィック インターフェイスの仮想 IP (VIP) インターフェイスの構成と管理 (複数のトラフィック インターフェイスは同じ RG グループを使用して構成できます)。GigabitEthernet 1 および 2 はトラフィック インターフェイスと見なされます。
この RG コンポーネントは、音声 B2B HA をサポートするように特別に構成する必要があります。
信号とメディアの両方に関する仮想 IP (VIP) アドレス管理
B2B HA は、冗長性を確保する際に VIP に依存します。CUBE HA ペアの両方の CUBE で VIP および関連する物理インターフェイスは、同じ LAN サブネット上に存在している必要があります。VIP の構成、および特定の音声アプリケーション (SIP) への VIP インターフェイスのバインドは、音声 B2B HA サポートに必須です。Unified CM、Webex Calling アクセス SBC、サービス プロバイダー、プロキシなどの外部デバイスは、CUBE HA ルーターを通過するコールの宛先 IP アドレスとして VIP を使用します。そのため、Webex Calling の観点から、CUBE HA ペアは単一のローカル ゲートウェイとして機能します。
確立されたコールのコール シグナリングおよび RTP セッション情報は、アクティブなルーターからスタンバイ ルーターへのチェックポイントです。アクティブ ルーターがダウンすると、スタンバイ ルーターが引き継ぎ、最初のルーターによって以前にルーティングされた RTP ストリームを継続して転送します。
フェイルオーバー時に一時的な状態のコールは、切り替え後には保存されません。たとえば、まだ完全に確立されていない、または転送や保留の機能により変更中のコールなどです。確立されたコールは、切り替え後に切断される場合があります。
コールのステートフル フェールオーバーのローカル ゲートウェイとして CUBE HA を使用するには、以下の要件があります。
-
CUBE HA は TDM またはアナログ インターフェイスを共存させることはできません
-
Gig1 および Gig2 はトラフィック (SIP/RTP) インターフェイス、Gig3 は冗長グループ (RG) コントロール/データ インターフェイスと呼ばれます
-
グループ id 1 とグループ id 2 を持つ同じレイヤー 2 ドメインに配置できる CUBE HA ペアは 2 つまでです。同じグループ ID で 2 つの HA ペアを構成する場合、RG コントロール/データ インターフェイスは異なるレイヤー 2 ドメイン (vlan、個別のスイッチ) に属している必要があります
-
ポート チャネルは、RG コントロール/データとトラフィック インターフェイスの両方でサポートされています
-
すべてのシグナリング/メディアは、仮想 IP アドレスから供給されます
-
プラットフォームが CUBE HA 関係にリロードされると、常にスタンバイとして起動します
-
すべてのインターフェイスの下位アドレス (Gig1、Gig2、Gig3) は、同じプラットフォームにある必要があります
-
冗長性インターフェイス識別子、rii は同じレイヤー 2 のペア/インターフェイスの組み合わせに対して固有である必要があります
-
両方の CUBE の構成は、物理構成を含む必要があり、同じ種類のプラットフォームと IOS-XE バージョンで実行されている必要があります
-
ループバック インターフェイスは、常に起動しているためバインドとして使用できません
-
複数のトラフィック (SIP/RTP) インターフェイス (Gig1、Gig2) では、インターフェイスのトラッキングが構成されている必要があります
-
CUBE-HA は、RG コントロール/データ リンク (Gig3) のクロスオーバー ケーブル接続ではサポートされていません
-
両方のプラットフォームは同一である必要があり、すべての同様のインターフェイスで CUBE HA が機能するように [物理スイッチ] を介して接続します。例: CUBE-1 と CUBE-2 の GE0/0/0 は同じスイッチ上で終了する必要があります
-
直接 CUBE 上で、またはいずれかの側のデータ HA で WAN を終了することができません
-
アクティブ/スタンバイは両方とも同じデータセンターにある必要があります
-
冗長性 (RG コントロール/データ、Gig3) に別の L3 インターフェイスを使用する必要があります。トラフィックに使用されるインターフェイスは、HA keepalives およびチェックポイントに使用できません
-
フェールオーバー時に、以前アクティブだった CUBE は、設計によって再読み込みされ、シグナリングとメディアを保持します
両方の CUBE で冗長性を構成する
HA ペアで使用し、仮想 IP を表示するために、両方の CUBE でレイヤー 2 ボックス間冗長性を構成する必要があります。
1 |
インターフェイスのステータスを追跡するために、グローバル レベルでインターフェイス トラッキングを構成します。
トラッキング CLI は、トラフィック インターフェイスがダウンした後、アクティブ ルートがアクティブな役割を果たすように、RG 内で音声トラフィックインターフェイスの状態を追跡するために使用されます。 | ||
2 |
アプリケーション冗長性サブモード下の VoIP HA で使用する RG を構成します。
この構成で使用されるフィールドの説明を次に示します。
| ||
3 |
CUBE アプリケーションのボックス間の冗長性を有効にします。
redundancy-group 1: このコマンドを追加および削除するには、更新された構成を有効にするために再読み込みが必要です。すべての構成が適用された後で、プラットフォームを再読み込みします。 | ||
4 |
以下に示すように、Gig1 と Gig2 インターフェイスをそれぞれの仮想 IP で構成し、冗長性インターフェイス識別子 (rii) を適用します。
この構成で使用されるフィールドの説明を次に示します。
| ||
5 |
最初の CUBE 構成を保存し、再読み込みします。 最後にリロードするプラットフォームは常にスタンバイです。
VCUBE-1 が完全に起動したら、 VCUBE-2 の構成を保存し、再読み込みします。
| ||
6 |
ボックス間の構成が期待どおりに機能していることを確認します。関連する出力は太字で強調表示されます。 VCUBE-2 を最後にリロードし、設計上の考慮事項に従います。最後にリロードするプラットフォームは常に [スタンバイ] 状態です。 |
両方の CUBE でローカル ゲートウェイを構成する
この例の構成では、Control Hub から以下のトランク情報を使用して、VCUBE-1、VCUBE-2 の両方のプラットフォームでローカルゲートウェイを構成しています。この設定のユーザー名とパスワードは以下のとおりです。
-
ユーザー名:フセイン1076_LGU
-
パスワード:lOV12MEaZx
1 |
クレデンシャルまたは共有秘密で使用する前に、以下のコマンドを使用して、設定キーがパスワードに対して作成されていることを確認してください。Type 6 パスワードは、AES 暗号化とこのユーザー定義の設定キーを使用して暗号化されます。
これは、上に表示されている Control Hub のパラメーターに基づき、両方のプラットフォームに適用し、保存し、リロードするローカ ルゲートウェイの構成です。Control Hub からの SIP ダイジェスト資格情報は、太字でハイライトされます。
Show コマンド出力を表示するには、VCUBE-2 の後に VCUBE-1 をリロードし、VCUBE-1 をスタンバイ CUBE にして、VCUBE-2 をアクティブ CUBE にします。 |
2 |
任意の時点で、1 個のプラットフォームのみが、Webex Calling アクセス SBC を使用したローカル ゲートウェイとしてアクティブ登録を保持します。以下の show コマンドの出力を見てみましょう。 show redundancy application group 1 sip-ua 登録ステータスの表示
上記の出力から、VCUBE-2 は Webex Calling アクセス SBC への登録を維持するアクティブ LGW であり、「show sip-ua 登録ステータス」の出力は VCUBE-1 では空白です。 |
3 |
VCUBE-1 で次のデバッグを有効にします
|
4 |
この場合、アクティブ LGW、VCUBE-2 で次のコマンドを実行してフェールオーバーをシミュレートします。
アクティブからスタンバイ LGW への切り替えは、上記に一覧表示されている CLI に加えて、以下のシナリオで発生します。
|
5 |
VCUBE-1 が Webex Calling アクセス SBC に登録されているかどうかを確認します。VCUBE-2 は今すぐにリロードされます。
VCUBE-1 がアクティブ LGW になりました。 |
6 |
仮想 IP を通じて SIP REGISTER を Webex Calling に送信し、200 OK を受信する VCUBE-1 に関連するデバッグ ログを確認してください。
|
Webex Calling の概要
エンタープライズグレードのクラウド通話、モビリティ、PBX 機能を、Webex アプリでメッセージングとミーティング、Webex Calling ソフト クライアントまたは Cisco デバイスからの通話に使用できると想像してください。これこそが、Webex Calling がユーザーへ提供する機能です。
Webex Calling には次のような機能と利点があります。
-
テレフォニー ユーザーのためのコール サブスクリプションと共有領域。
-
信頼できる地域のサービス プロバイダによって配信される安全かつ信頼性のあるクラウド サービス
-
すべてのユーザーが Webex アプリにアクセスし、豊富な統合コミュニケーションとチーム コラボレーション サービスを追加します。
-
Webex Meetings はオプションで統合されたアドオンで、エンタープライズ ユーザーが期待するプレミアム ミーティング エクスペリエンスを提供します。
-
ユーザーが組織外に番号をダイヤルできるようにするためのパブリック スイッチ テレフォニー ネットワーク (PSTN) アクセス。サービスは既存のエンタープライズ インフラストラクチャを通じて提供されます
-
オンプレミス IP PBX なしのローカル ゲートウェイ
-
既存の Unified CM コール環境
-
パートナーまたは Cisco が提供した PSTN オプション
-
-
パートナーや Cisco により提供されている次のレベルのサポートにより提供される階層 1 サポート
Control Hub は、Webex Calling と統合された Web ベースの管理ポータルで、注文と構成を合理化し、バンドルされたオファー、つまり Webex Calling、Webex アプリ、Webex Meetings の管理を一元化します。
機能 |
説明 |
---|---|
自動音声応答 |
セットアップ メニューと、応答サービス、ハント グループ、ボイスメール ボックスや実際のオペレーターなどへのルーティング機能によって、適切なあいさつを返すことができます。24 時間分のスケジュールを作成することができます。あるいは、営業時間内か外かに応じて、異なるオプションを使うこともできます。通話は、発信者の ID 属性に応じてルーティングすることによって、VIP リストを作成したり、特定の市外局番からの通話には対応を変えたりすることができます。 |
コール キュー |
着信通話に応答できないときに、通話キューを設定できます。誰かがコールに応答できるまで、自動応答、ご案内のメッセージ、保留中の音楽を発信者に提供できます。 |
通話ピックアップ |
コール ピックアップ グループを作成して、ユーザーが別のユーザーの通話に応答できるようにすることで、チームワークとコラボレーションを強化できます。ユーザーをコールピックアップグループに追加しておけば、グループメンバーが席を離れていたり、電話中だったりした場合、別のメンバーが電話に出ることができます。 |
コール パーク |
コール パークをオンにすると、ユーザがコールを保留にし、別の電話からピックアップできます。 |
ハントグループ |
以下のようなシナリオでは、ハント グループをセットアップするのがよいでしょう。
|
ページング グループ |
ユーザーが音声メッセージを個人、部署、チームに送信できるように、ページング グループを作成できます。誰かがメッセージをページング グループに送信するとき、グループのすべてのデバイスでメッセージが再生されます。 |
レセプショニスト クライアント |
フルセットの通話管理オプション、大規模モニタリング、コール キュー、複数のディレクトリ オプションとビュー、Outlook との統合などを提供することにより、フロントオフィス担当者のニーズを満たします。 |
機能 |
説明 |
---|---|
匿名コールの拒否 |
ユーザーはブロックされた発信者 ID を使用して着信を拒否できます。 |
障害時一括転送 |
停電、ネットワークの問題などの理由でユーザの電話がネットワークに接続されていない場合、ユーザは着信コールを特定の電話番号に転送できます。 |
コール転送 |
ユーザーは着信コールを別の電話に転送することができます。 |
選択的コール転送 |
ユーザーは特定の発信者、特定の時間のコールを転送することができます。この設定はコール転送より優先されます。 |
コール通知 |
ユーザーは、電話番号や日時など、事前に定義された条件に従ってコールを受信したときに自分自身にメールが送られるよう設定することができます。 |
着信待ち受け |
ユーザーは追加の着信に応答することができます。 |
応答不可 |
ユーザーは一時的にすべての通話をボイスメールに直接転送できます。 |
Office Anywhere |
ユーザーは選択された電話 (「ロケーション」) を、会社の電話番号とダイヤルプランの内線として使用することができます。 |
優先アラート |
ユーザーは電話番号や日時など、事前に定義された条件が満たされたときに、特別な着信音が鳴るように設定することができます。 |
リモート オフィス |
ユーザーはリモートの電話からコールを発信し、ビジネス回線からのものとして表示させることができます。さらに、ビジネス回線への着信は、このリモート電話で鳴ります。 |
選択通話承諾 |
ユーザーは特定の発信者、特定の時間のコールを承認することができます。 |
匿名通話の拒否 |
ユーザーは特定の発信者、特定の時間のコールを拒否することができます。 |
シーケンシャル リング |
着信があると、最大で 5 台のデバイスを 1 つずつ鳴らすことができます。 |
同時リング |
着信があると、ユーザーの番号の電話と、別の番号の電話 (「コールの受信者」) 番号が同時に鳴ります。 |
Control Hub でのサービス、デバイス、およびユーザーのプロビジョニング、Calling 管理ポータルの詳細構成へのクロス起動
Control Hub (https://admin.webex.com) は、Webex Calling と統合された管理ポータルであり、注文と構成を合理化し、バンドルされたオファー、つまり Webex Calling、Webex アプリ、Meetings の管理を一元化します。
Control Hub は、すべてのサービス、デバイス、およびユーザーをプロビジョニングするための中心点です。コーリング サービスの初回セットアップ、MPP 電話のクラウドへの登録 (MAC アドレスを使用)、デバイスの関連付けや、電話番号、サービス、コール機能の追加などにより、ユーザーを構成することができます。また、Control Hub からは、Calling 管理ポータルへのクロスローンチが可能です。
ユーザーエクスペリエンス
ユーザーは次のインターフェイスへのアクセスできます。
-
Webex Calling アプリケーション—Cisco ブランドのコール ソフト クライアント。詳細については、「新しい Cisco Webex Calling アプリを検索する」を参照してください。
-
Webex 設定 (https://settings.webex.com)—ユーザーがプロファイルの基本設定を設定し、Webex アプリをダウンロードし、Calling 設定のために Calling ユーザー ポータルにクロス起動できるインターフェイス。詳細については、「Cisco Webex の設定を変更する」を参照してください。
-
Webex アプリ—Cisco ブランドの Team メッセージング クライアントとしてのサブスクリプションに含まれるアプリケーション。詳細については、「新しいアプリを 使い始めるCisco Webexしてください。
-
Webex Meetings —ミーティング ソリューションとして追加されるオプションのアプリケーション。詳細については、「Webex Meetings」を参照してください。
カスタマー管理者
Webex Calling のトライアルまたは有料サブスクリプションの顧客管理者は、ロケーション、ライセンス、電話番号、通話機能、ユーザー、およびワークスペース (Webex クラウドに登録されている会議室デバイス) を追加することで、Control Hub で組織をセットアップできます。これらのすべてコンポーネントを同様にそこから管理できます。
-
この点のガイダンスについては、『Cisco Webex Calling のカスタマー設定ガイド』を参照してください。
-
Webex Calling オファーの詳細については、「エンドカスタマー向けの Cisco コラボレーション フレックス プランの Cisco Webex Calling」を参照してください。
パートナー:
パートナー サービス プロバイダーは、ブランドとマーケットを設定して、Webex Calling を顧客に販売できます。トライアルをセットアップして、顧客にサービスを展開し、顧客にオーダーを作成してプロビジョニングすることもできます。
-
この点のガイダンスについては、『Cisco Webex Calling のカスタマー設定ガイド』(早期パートナー登録プログラム)を参照してください。
-
パートナーリソースの詳細については、『Webex Calling セールス コネクト リソース』を参照してください。(パートナーの資格情報が必要です。)
サービス開始日時
Webex Calling が販売可能な国については、『Cisco Webex はどこで利用可能か』という記事の「Webex Calling」の見出しを参照してください。
Control Hub を体験する
Control Hub は、組織の管理、ユーザーの管理、サービスの割り当て、導入の傾向や通話品質の分析などを行うための、ウェブ ベースの単一のインターフェイスです。
組織をセットアップして実行 するには、Control Hub にメール アドレスを入力して、Webex アプリ に参加する数人のユーザーを招待することを 推奨します。コールを含む、提供されるサービスを使用するようにユーザーを促し、彼らの満足度に関するフィードバックを提供することを求めます。準備が完了したら、いつでもユーザーを追加することができます。
Control Hub にアクセスするには最新の Google Chrome もしくは Mozilla Firefox のデスクトップ バージョンを使用されることを推奨します。モバイル デバイスのブラウザーやその他のデスクトップ ブラウザーを使用した場合、予期せぬ結果が生じる場合があります。
以下に示す情報を、組織がサービスをセットアップし始めた場合に期待できる事柄についての、大まかな概要として用いてください。詳細については、個々の章の、手順を追った説明を参照してください。
使い始める
パートナーがあなたのアカウントを作成すると、ウェルカム メールが届きます。Chrome または Firefox を使用し、[はじめに] リンクをクリックして、Control Hub にアクセスます。このリンクを使うと、管理者のメール アドレスで自動的にサインインすることができます。次に、管理者パスワードを作成するためのプロンプトが表示されます。
トライアルのための初回ウィザード
パートナーがトライアルに登録した場合、Control Hub にサインインすると、セットアップウィザードが自動的に開始します。このウィザードでは、Webex Calling などのサービスで組織を立ち上げて稼働させるための基本設定を案内します。ウィザードのガイドを終えると、Calling の設定とその確認が完了します。
設定の確認
Control Hub がロードされると、設定を確認できます。
ユーザーの追加
サービスをセットアップしたら、会社ディレクトリからユーザーを追加する準備ができます。[ユーザー] に進んで、[ユーザーの管理] をクリックします。
Microsoft Active Directory を使用している場合、まずディレクトリ同期を有効にしてからユーザーの追加方法を決定することをお勧めします。[次へ] をクリックし、指示に従って Cisco Directory Connector を設定します。
シングル サインオン (SSO) の設定
Webex アプリは基本認証を使用します。 SSO をセットアップして、ユーザーが Webex に保存され、管理される別のパスワードではなく、エンタープライズ クレデンシャルを使用してエンタープライズ ID プロバイダーで認証されるようにできます。
[設定] に移動し、[認証] までスクロールして、[変更] をクリックしてから、[サードパーティの ID プロバイダを統合させる] を選択します。
サービスをユーザーに割り当てる
ユーザーが Webex アプリの使用を開始するために、追加したユーザーにサービス を割り当てる必要があります。
[ユーザー] に移動して、[ユーザーの管理] をクリックし、[CSV ファイルでユーザーをエクスポートおよびインポートする] を選択してから、[エクスポート] をクリックします。
ダウンロードしたファイルで、各ユーザーに割り当てるサービスに [True] を追加します。
完了したファイルをインポートし、[サービスの追加および削除] をクリックして、[提出] をクリックします。これで、コール機能を構成し、共通場所で共有できるデバイスを登録し、デバイスを登録してユーザーに関連付ける準備ができました。
ユーザーを支援する
これで、ユーザーを追加し、サービスを割り当て済みです。メッセージングとミーティングのために、Webex Calling および Webex アプリでサポートされているマルチプラットフォーム電話 (MPP ) の使用を開始できます。ユーザーに、アクセスのためのワンストップショップとしてCisco Webex の設定 を使用するように促してください。
ローカル ゲートウェイの役割
ローカル ゲートウェイは、エンタープライズまたはパートナーにより管理されているエッジ デバイスです。これは、パブリックスイッチのテレフォニー ネットワーク (PSTN) の相互動作と従来型のプライベート ブランチ エクスチェンジ (PBX) との動作のためのものです (Unified CM を含む)。
ローカル ゲートウェイをロケーションに割り当てるには Control Hub を使用します。その後、CUBE で設定できるパラメーターが Control Hub により提供されます。これらの手順により、ローカル ゲートウェイがクラウドに登録され、ゲートウェイを通じて PSTN サービスが特定のロケーションの Webex Calling ユーザーに対して提供されます。
ローカル ゲートウェイを指定して注文するには、「ローカルゲートウェイの注文ガイド」を参照してください。
Webex Calling 向けにサポートされているローカル ゲートウェイの展開
次の基本的な展開がサポートされています。
ローカル ゲートウェイは、Cisco Unified Communications Manager へのインテグレーションが必要な場合、スタンドアロンまたは導入で展開することができます。
オンプレミスの IP PBX なしのローカル ゲートウェイ展開
スタンドアロンのローカル ゲートウェイ展開
この図は既存の IP PBX がない場合の Webex Calling 展開を示しており、単一の場所または複数の場所のどちらの展開でも適用できます。
Webex Calling の宛先に一致しないすべてのコールについては、Webex Calling は処理の場所に割り当てられているローカル ゲートウェイにそれらのコールを送信します。ローカルゲートウェイは、Webex Calling から PSTN に送られるすべてのコールと、反対方向に PSTN から Webex Calling に送られるコールのルーティングを行います。
PSTN ゲートウェイは、ローカル ゲートウェイの専用プラットフォームまたは共存プラットフォームになります。次の図のように、この展開の専用の PSTN ゲートウェイのバリエーションをお勧めします。既存の PSTN ゲートウェイを Webex Calling のローカル ゲートウェイとして使用できない場合に使用できます。
共存型のローカル ゲートウェイの展開
ローカル ゲートウェイとして、ITSP に接続するために SIP トランクを使用する IP ベースのもの、または ISDN またはアナログ回路を使用する TDM ベースのものを使用できます。次の図は、ローカル ゲートウェイが PSTN GW/SBC と共存している場合の、Webex Calling の展開を示しています。
オンプレミスの Unified CM PBX なしでのローカル ゲートウェイ展開
Unified CM とのインテグレーションは、以下の場合に必要です。
-
Webex Calling 対応のロケーションを、Unified CM がオンプレミスのコール コントロール ソリューションとして展開されている場所で、既存の Cisco UC 展開に追加する
-
Unified CM に登録された電話と Webex Calling ロケーションの電話との間で、直接ダイヤリングが必要な場合。
この図は、顧客が既存の Unified CM IP PBX を持っている場所での、Webex Calling の展開を示しています。
Webex Callingの宛先に一致しない通話を ローカル Webex Calling に送信します。これには、PSTNおよび Unified CM 内部内線番号Webex Calling含まれます。ローカル ゲートウェイは、ユーザーから Unified CM へ、その逆Webex Calling、すべての通話をルーティングします。Unified CM は、着信コールを、既存のダイヤル プランに従ってローカルの宛先または PSTN にルーティングします。Unified CM のダイヤル プランは、番号を +E.164 として正規化します。PSTN ゲートウェイには、専用のものと、ローカル ゲートウェイに共存しているものがあります。
専用の PSTN ゲートウェイ
この図に示されているように、この展開での専用 PSTN ゲートウェイのバリエーションは推奨オプションであり、既存の PSTN ゲートウェイを Webex Calling ローカル ゲートウェイとして使用できない場合に使用することができます。
共存型 PSTN ゲートウェイ
この図は、ローカル ゲートウェイが PSTN ゲートウェイ/SBC と共存している場合の、Webex Calling と Unified CM の展開を示しています。
Webex Callingの 宛先に一致 しないすべての通話を、ロケーションWebex Calling割り当てられたローカル ゲートウェイにルーティングします。これには、PSTN の宛先と、Unified CM 内部の内線に向けたオンネット コールが含まれます。ローカルゲートウェイは、すべてのコールを Unified CM にルーティングします。その後、Unified CM は PSTN/SBC 機能が共存している ローカル ゲートウェイを通じて、コールをローカルに登録された電話または PSTN にルーティングします。
コール ルーティングの考慮点
Webex Calling から Unified CM へのコール
Webex Calling のルーティング ロジックは次のように動作します。Webex Calling エンドポイントでダイヤルされた番号が Webex Calling の同じ顧客内の他の宛先にルーティングできない場合、通話はさらに処理するために、ローカル ゲートウェイに送信されます。オフネット (外部) のWebex Callingは、ローカル ゲートウェイに送信されます。
既存の Unified CM に統合されていない Webex Calling 展開の場合、オフネットのコールは PSTN コールとして認識されます。Unified CM との組み合わせでは、オフネット コールは、Unified CM でホストされている任意の宛先へのオンネット コール、または PSTN 宛先への実際のオフネット コールになり得ます。後者の 2 つのコールの種類の違いは、Unified CM によって決まり、Unified CM でプロビジョニングされたエンタープライズ ダイヤル プランによって異なります。
次の図は、米国の国内番号にダイヤルする Webex Calling ユーザーを示しています。
Unified CM は、構成済みのダイヤルプランに基づいて、発信先が電話帳としてプロビジョニングされている、ローカルに登録されたエンドポイントにルーティングします。このため、Unified CM のダイヤル プランは + E.164 番号のルーティングをサポートする必要があります。
Unified CM から Webex Calling へのコール
Unified CM から Webex Calling へのコール ルーティングを Unified CM で有効にするには、一連のルートをプロビジョニングして、Webex Calling での +E.164 プラン アドレスとエンタープライズ番号の組み合わせを定義する必要があります。
これらのルートを構成することにより、次の図に示されているコール シナリオの両方が可能になります。
PSTN の発信者が Webex Calling デバイスに割り当てられた DID 番号を呼び出した場合、コールはエンタープライズの PSTN ゲートウェイを通じてエンタープライズに渡されてから、Unified CM にヒットします。コールの呼び出し先アドレスは、Unified CM でプロビジョニングされた Webex Calling ルートの 1 つと一致し、コールはローカルゲートウェイに送信されます。(ローカル ゲートウェイに送信する場合、着信アドレスは +E.164 形式である必要があります。) Webex Calling のルーティング ロジックは、DID の割り当てに基づいて、コールが意図した Webex Calling デバイスに送信されるようにします。
また、Webex Calling の送信先をターゲットとする、Unified CM の登録済みエンドポイントから発信されるコールは、Unified CM でプロビジョニングされているダイヤルプランに従います。通常、このダイヤルプランにより、ユーザーは一般的なエンタープライズダイヤルの習慣を使ってコールを発信することができます。これらの習慣には、必ずしも +E.164 ダイヤルだけが含まれているわけではありません。+E.164 以外のダイヤル習慣は、通話がローカル ゲートウェイに送信される前に +E.164 にノーマライズし、Webex Calling で正しいルーティングを許可する必要があります。
サービス クラス (CoS)
厳しいサービス クラスの制限を実装することは、コールのループの回避や特殊詐欺の防止など、さまざまな理由により常に推奨されます。Webex Calling ローカル ゲートウェイを Unified CM のサービス クラスと統合するコンテキストでは、以下のサービス クラスについて検討する必要があります。
-
Unified CM に登録されているデバイス
-
PSTN からUnified CM に着信するコール
-
ユーザーから Unified CM に着信Webex Calling
Unified CM に登録されているデバイス
既存の CoS セットアップに新しいクラスの宛先として Webex Calling の宛先を追加すると、次のようになります。Webex Calling の宛先への発信権限は通常、オンプレミス (サイト間を含む) の宛先を呼び出す権限と同等です。
エンタープライズ ダイヤル プランがすでに「(短縮ダイヤルの) オンネット」の権限を実装している場合、Unified CM でプロビジョニングされているパーティションはすでに存在しています。これは、同じパーティション内のすべての既知のオンネット Webex Calling の宛先を使用し、プロビジョニングすることができます。
そうでない場合、「(短縮ダイヤルの) ネット間オンネット」権限の概念はまだ存在していません。新しいパーティション (「onNetRemote」とします) をプロビジョニングし、Webex Calling の宛先をこのパーティションに追加し、最後にこの新しいパーティションを適切なコール検索スペースに追加する必要があります。
PSTN からUnified CM に着信するコール
既存の CoS セットアップに新しいクラスの宛先として Webex Calling の宛先を追加すると、次のようになります。Webex Calling の宛先への発信権限は通常、オンプレミス (サイト間を含む) の宛先を呼び出す権限と同等です。
エンタープライズ ダイヤル プランがすでに「(短縮ダイヤルの) オンネット」の権限を実装している場合、Unified CM でプロビジョニングされているパーティションはすでに存在しています。これは、同じパーティション内のすべての既知のオンネット Webex Calling の宛先を使用し、プロビジョニングすることができます。
そうでない場合、「(短縮ダイヤルの) ネット間オンネット」権限の概念はまだ存在していません。新しいパーティション (「onNetRemote」とします) をプロビジョニングし、Webex Calling の宛先をこのパーティションに追加し、最後にこの新しいパーティションを適切なコール検索スペースに追加する必要があります。
ユーザーから Unified CM に着信Webex Calling
PSTN からの着信は Webex Calling のすべての送信先にアクセスできる必要があります。そのため、PSTN トランク上の着信で使用されるコール検索スペースに、すべての Webex Calling 宛先を保持する上記のパーティションを追加する必要があります。Webex Calling の宛先へのアクセスは、すでに存在するアクセスに追加されます。
PSTN からUnified CM DID へのアクセスに対して、Webex Calling DID が必要なコールの場合、Webex Calling で発生したコールは、Unified CM DID と PSTN 宛先にアクセスできる必要があります。
この図は、PSTN および Webex Calling からの通話に対してこれら 2 つの異なるクラスを比較Webex Calling。この図では、PSTN ゲートウェイ機能がローカル ゲートウェイに併置されている場合に、PSTN GW とローカル ゲートウェイを Unified CM に組み合わせることで 2 つのトランクが必要であることも示しています。1 つはネットワークで発信された通話PSTN、もう 1 つはシステムで発信された通話Webex Calling。これは、トラフィック タイプごとに差別化されたコール検索スペースを適用するための要件により決まります。Unified CM で 2 つの着信トランクを使用することで、各トランクの着信に必要なコール検索スペースを設定することで、これを容易に達成できます。
ダイヤル プランのインテグレーション
このガイドでは、『Cisco コラボレーション オンプレミス展開 (CVD) のための優先アーキテクチャ』で説明されている、現在のベスト プラクティスに基づいた既存のインストールを想定しています。最新バージョンは、こちらで入手できます。
推奨されるダイヤル プランの設計は、こちらで入手可能な、最新バージョンの「Cisco コラボレーション システム SRND」の「ダイヤル プラン」の章に記載されている設計アプローチに従っています。
この図は、推奨されるダイヤル プラン設計の概要を示しています。このダイヤル プラン設計の主な特徴は次のとおりです。
-
Unified CM で構成されているすべてのディレクトリ番号は +E.164 形式です。
-
すべてのディレクトリ番号は同じパーティション (DN) に属しており、緊急としてマークされています。
-
コア ルーティングは +E.164 に基づいています。
-
すべての非 +E.164 ダイヤルの習慣 (たとえば、一般的なダイヤル習慣を使用するサイト内ダイヤルと PSTN ダイヤル) は、ダイヤリング正規化のための翻訳パターンを用いて、+E.164 に正規化 (グローバライズ) されます。
-
ダイヤル正規化の翻訳パターンは、翻訳パターン ルール検索スペースの継承を使用します。これらには、[発信者のコール検索スペースを使用] オプションが設定されています。
-
サービスのクラスは、サービス固有のコール検索スペースのサイトとクラスを使用して実装されます。
-
PSTN アクセス機能 (たとえば、国際 PSTN 宛先へのアクセス) は、サービスのクラスを定義するコール検索スペースに、それぞれの +E.164 ルート パターンを持つパーティションを追加することによって実装されます。
到達可能性Webex Calling
この ダイヤル プラン への Webex Calling 宛先に到達可能性を追加するには、すべての Webex Calling 宛先を表すパーティションが作成され ("Webex Calling")、Webex Calling の各 DID 範囲に対して +E.164 ルート パターン がこのパーティションに追加される必要があります。このルートパターンは、1 つのメンバーのみを持つルートリストを参照します。ローカル ゲートウェイへの SIP トランクを持つルート グループ Webex Calling。すべてのダイヤルされた宛先は、Unified CM 登録済みエンドポイントから発信される通話に対してダイヤル正規化変換パターンを使用するか、PSTN から発する着信着信側の変換を使用して+E.164 ルート パターンの単一セットで、Webex Calling の宛先に対する到達可能性を達成するのに十分です。
たとえば、ユーザーが"914085550165""にダイヤルすると、パーティション「UStoE164」のダイアル正規化変換パターンは、このダイヤル文字列を"+14085550165"にノーマライズし、それをパーティション「Webex Calling」の Webex Calling 宛先の ルート パターン に一致します。Unified CM は最終的、ローカル ゲートウェイにコールを送信します。
サイト間ダイヤルに短縮ダイヤルを追加する
参照ダイヤル プランにサイト間の短縮ダイヤルを追加する際に推奨される方法は、専用パーティション (「ESN」、エンタープライズ有意番号) への、エンタープライズのナンバリング プランの下で、すべてのサイトにダイヤリング正規化の翻訳パターンを追加することです。これらの翻訳パターンは、エンタープライズ ナンバリング プランの形式のダイヤル文字列をインターセプトして、ダイヤル文字列を +E.164 に正規化します。
Webex Calling 宛先にエンタープライズの短縮ダイヤルを追加するには、Webex Calling ロケーションのそれぞれのダイヤル正規化変換パターンを「Webex Calling」パーティション (例えば、図の「8101XX」)に追加します。正規化後、"Webex Calling" パーティションのユーザーと一ルート パターンした後で、通話Webex Callingされます。
この構成により望ましくない通話ルーティング ループが作成される可能性があるため、Webex Calling 通話の短縮ダイヤル正規化変換パターンを「ESN」パーティションに追加することを推奨しません。
コール用プロトコル ハンドラー
Webex Calling は、次のプロトコル ハンドラーをオペレーティング システムに登録して、ウェブ ブラウザーまたはその他のアプリケーションからのクリック通話機能を有効にします。Mac または Windows でデフォルトの通話アプリケーションである場合、次のプロトコルは Webex アプリで音声またはビデオ通話を開始します。
-
CLICKTOCALL: または CLICKTOCALL://
-
SIP: または SIP:
-
TEL: または TEL:
-
WEBEXTEL: または WEBEXTEL://
Windows 用プロトコル ハンドラー
他のアプリは Webex アプリの前にプロトコル ハンドラーに 登録できます。Windows 10 では、通話を開始するために使用するアプリを選択するためにユーザーに尋ねるシステム ウィンドウ。ユーザーは、[常にこのアプリを使う] にチェックを入れて、記憶させることができます。
ユーザーが Webex アプリを選択するために、デフォルトの通話アプリ設定をリセットする必要がある場合、Windows 10 の Webex アプリのプロトコル関連付けを変更するように指示できます。
-
[デフォルトのアプリ設定] システム設定を開き、[アプリごとにデフォルトを設定する] をクリックして、[Webex アプリ] を選択します。
-
各プロトコルに対して、[Webex アプリ] を選択します。
macOS 用のプロトコルハンドラー
Mac OS では、 Webex アプリの前に通話プロトコルに登録されている他のアプリがある場合、ユーザーは Webex アプリ をデフォルトの通話オプションに設定する必要があります。
Mac 版 Webex アプリでは、ユーザーは一般的な基本設定で [通話を開始] 設定に [Webex アプリ] が選択されていることを確認できます。また、Outlook の連絡先の番号をクリックしたときに Webex アプリで発信する場合、[常に Microsoft Outlook に接続する] をオンにすることもできます。
環境を準備する
全般的な前提条件
Webex Calling のローカル ゲートウェイを設定する前に、次のことを確認してください。
-
VoIP の原理についての基本的な知識があること
-
Cisco IOS-XE と IOS-XE 音声のコンセプトについて、基本的で実際的な知識があること
-
Session Initiation Protocol (SIP) の基本的な理解を得る
-
導入モデルに Cisco Unified Communications Manager (Unified CM) が含まれている場合には、Unified CM についての基本的な理解があること
詳細については、「Cisco Unified Border Element (CUBE) Enterprise 設定ガイド 」を参照してください。
ローカル ゲートウェイのハードウェアおよびソフトウェア的要件
展開に、次のようなローカル ゲートウェイが 1 つ以上あることを確認します。
-
IP ベースの接続のための Cisco CUBE
-
TDM ベースの接続用 Cisco IOS Gateway
ローカル ゲートウェイは、自分のペースで Webex Calling に移行するのに役立ちます。ローカル ゲートウェイは、既存のオンプレミス展開を Webex Calling と統合します。既存の PSTN 接続を使用することもできます。「ローカル ゲートウェイの使用を開始する」を参照してください。
ローカル ゲートウェイのライセンスに関する要件
CUBE コールライセンスは、ローカル ゲートウェイにインストールされている必要があります。詳細については、Cisco Unified 境界要素の構成ガイドを参照してください。
ローカル ゲートウェイの認証およびセキュリティ的要件
Webex Calling は、安全な信号経路とメディアを必要とします。ローカルゲートウェイは暗号化を行います。また、以下の手順に従って、TLS 接続をクラウド方向に確立する必要があります。
-
LGW は、Cisco PKI からの CA ルートバンドルで更新しておく必要があります
-
LGW を構成する際には、Control Hub のトランク構成ページから取得した一連の SIP ダイジェスト資格情報が使用されます(この手順は、この後の構成の一部です)
-
CA ルート バンドルは、提示された証明書を検証します
-
資格情報が要求されます (SIP ダイジェストにより提供されたもの)
-
クラウドは、どのローカル ゲートウェイがセキュアに登録されているかを識別します
ローカルゲートウェイのファイアウォール、NAT Traversal、メディアパス最適化の各要件
ほとんどの場合、ローカル ゲートウェイとエンドポイントは、NAT によるプライベート IP アドレスを使用して、内部の顧客ネットワークに配置することができます。エンタープライズ ファイアウォールは、特定の IP アドレス/ポートに対する外向きトラフィック (SIP、RTP/UDP、HTTP) を許可していなければなりません。この点は、「ポート参照情報」で説明されています。
ICE でメディアパスの最適化を利用する場合、ローカルゲートウェイの Webex Calling に面しているインターフェイスには Webex Calling エンドポイントとの双方向の直接ネットワークパスが必要です。エンドポイントが別のロケーションにあり、ローカルゲートウェイの Webex Calling に面しているインターフェイスとこのエンドポイントとの間に直接ネットワークパスがない場合、メディアパスの最適化を利用するには、ローカルゲートウェイとエンドポイント間の通話のために、Webex Calling に面しているインターフェイスに割り当てられたパブリック IP アドレスをローカルゲートウェイに設定する必要があります。また、IOS-XE バージョン 16.12.5 を実行している必要があります。
Webex Calling のポート参照情報
正しく設定されたファイアウォールとプロキシは、Calling の展開を成功させるために不可欠です。Webex Calling はグローバル サービスであるため、Webex Calling はコール シグナリングに SIP および HTTPS を使用し、メディア、ネットワーク接続、ゲートウェイ接続に関連するアドレスとポートを使用します。
すべてのファイアウォール設定で、ポートを開く必要はありません。ただし、内部から外部へのルールを実行している場合、サービスを排除するために必要なプロトコルのポートを開く必要があります。
ネットワーク アドレス変換(NAT)
ネットワーク アドレス変換(NAT)およびポート アドレス変換(PAT)機能は、アドレス スペースを翻訳したり、IP アドレス スペースの衝突を防ぐために、2 つのネットワーク間の境界で適用されます。
組織は、プライベート IP アドレス スペースにある Webex アプリ アプリケーションや Webex デバイスにインターネットアクセスを提供するために、NAT または PAT サービスを提供するファイアウォールやプロキシなどのゲートウェイ テクノロジーを使用します。これらのゲートウェイにより、内部アプリまたはデバイスからインターネットへのトラフィックが 1 つ以上のパブリックルーティング可能な IP アドレスから来ているように見えます。
-
NAT を展開する場合、ファイアウォールで着信ポートを開くことは必須ではありません。
-
複数のアプリのユーザーとデバイスが NAT または PAT を使用して Webex Calling および Webex 対応サービスにアクセスする場合、アプリまたはデバイスの接続に必要な NAT プール サイズを検証します。ポートの枯渇を防ぐために、十分なパブリック IP アドレスが NAT プールに割り当てられていることを確認します。ポートの枯渇は、内部ユーザーとデバイスが Webex Calling および Webex Aware サービスに接続できない原因となります。
-
妥当なバインド期間を定義し、NAT デバイスで SIP を操作しないようにします。
-
デバイスの適切な動作を確保するために、最小 NAT タイムアウトを設定します。例: シスコの電話機は、1 ~ 2 分ごとにフォローアップ REGISTER 更新メッセージを送信します。
-
ネットワークで NAT または SPI が実装されている場合は、接続のタイムアウト(少なくとも 30 分)を設定します。このタイムアウトにより、ユーザーのモバイル デバイスのバッテリー消費を削減しながら、信頼性の高い接続が可能になります。
SIP アプリケーション層ゲートウェイ
ルータまたはファイアウォールが SIP Aware で、SIP アプリケーション レイヤー ゲートウェイ(ALG)または同様の機能が有効になっている場合は、この機能をオフにしてサービスの正確な運用を推奨します。すべての Webex Calling トラフィックは暗号化されますが、一部の SIP ALG 実装では、ファイアウォール トラバーサルで問題が発生する可能性があります。したがって、高品質なサービスを提供するために、SIP ALG をオフにすることをおすすめします。
特定のデバイスで SIP ALG を無効にする手順については、関連する製造元のマニュアルを確認してください。
Webex Calling のプロキシ サポート
組織はインターネット ファイアウォールまたはインターネット プロキシおよびファイアウォールを展開し、ネットワークを出入りする HTTP トラフィックを検査、制限、および制御します。そのため、さまざまな種類のサイバー攻撃からネットワークを保護します。
プロキシは、次のようないくつかのセキュリティ機能を実行します。
-
特定の URL へのアクセスを許可またはブロックします。
-
ユーザー認証
-
IP アドレス/ドメイン/ホスト名/URI 評価のルックアップ
-
トラフィックの解読と検査
プロキシ機能を設定すると、HTTP のプロトコルを使用するすべてのアプリケーションに適用されます。
Webex アプリと Webex デバイス アプリケーションには以下が含まれます。
-
Webex サービス
-
GDS、EDOS デバイスアクティベーション、プロビジョニング、Webex クラウドへのオンボーディングなど、Cisco Cloud プロビジョニング プラットフォームを使用したカスタマー デバイス アクティベーション (CDA) 手順。
-
証明書認証
-
ファームウェア アップグレード
-
ステータス レポート
-
PRT アップロード
-
XSI サービス
プロキシ サーバ アドレスが設定されている場合、シグナリング トラフィック(HTTP/HTTPS)のみがプロキシ サーバに送信されます。SIP を使用して Webex Calling サービスに登録し、関連するメディアを登録するクライアントは、プロキシに送信されません。したがって、これらのクライアントがファイアウォールを直接通過することを許可します。
サポートされているプロキシ オプション、構成および認証タイプ
サポートされるプロキシ タイプは次のとおりです。
-
明示的プロキシ(検査中または非検査中):アプリまたはデバイスのいずれかを明示的プロキシを使用してクライアントを設定し、使用するサーバを指定します。
-
透過プロキシ(非検査用):クライアントは特定のプロキシ サーバ アドレスを使用するように設定されておらず、非検査プロキシで動作するように変更は必要ありません。
-
透過プロキシ(検査中):クライアントは特定のプロキシ サーバ アドレスを使用するように設定されていません。HTTP の設定変更は必要ありませんが、アプリまたはデバイスのクライアントは、プロキシを信頼できるようにルート証明書を必要とします。IT チームは、検査プロキシを使用して、訪問するウェブサイトのポリシーと許可されていないコンテンツのタイプを施行します。
以下を使用して、Cisco デバイスと Webex アプリのプロキシ アドレスを手動で設定します。
-
プラットフォーム OS
-
デバイス UI
-
次のような Web プロキシメカニズムを使用して自動的に検出されます。
-
ウェブ プロキシ自動検出 (WPAD) - ウェブ プロキシ自動検出プロトコル
-
プロキシ自動設定 (PAC) ファイル - プロキシ自動設定ファイル
-
希望の製品タイプを設定するときに、表で次のプロキシ設定と認証タイプを選択します。
製品 |
プロキシの設定 |
認証タイプ |
---|---|---|
Mac 版 Webex |
手動、WPAD、PAC |
認証なし、基本、NTLM、† |
Windows 版 Webex |
手動、WPAD、PAC、GPO |
認証なし、基本、NTLM、†、ネゴシエート † |
iOS 版 Webex |
手動、WPAD、PAC |
認証なし、基本、ダイジェスト、NTLM |
Android 版 Webex |
手動、PAC |
認証なし、基本、ダイジェスト、NTLM |
Webex Web アプリ |
OS でサポート |
認証なし、基本、ダイジェスト、NTLM、ネゴシエート † |
Webex デバイス |
WPAD、PAC、または手動 |
No Auth、ベーシック、ダイジェスト |
Cisco IP Phone |
手動、WPAD、PAC |
No Auth、ベーシック、ダイジェスト |
Webex ビデオ メッシュ ノード |
マニュアル |
認証なし、基本、ダイジェスト、NTLM |
表の凡例の場合:
-
†Mac NTLM 認証 - マシンはドメインにログインする必要はなく、ユーザーはパスワードの入力を求められます
-
†Windows NTLM 認証 - マシンがドメインにログインしている場合にのみサポートされます
-
ネゴシエート †- NTLM フォールバック認証で Kerberos。
-
Cisco Webex Board、Desk、または Room シリーズのデバイスをプロキシ サーバーに接続するには、「Board、Desk、または Room シリーズのデバイスをプロキシ サーバーに接続する」を参照してください。
-
Cisco IP 電話の場合、プロキシ サーバーと設定を構成する例として、プロキシ サーバーのセットアップ を参照してください。
[認証なし]
の場合、認証をサポートしていないプロキシ アドレスでクライアントを設定します。[プロキシ認証]
を使用する場合は、有効な資格情報で構成します。Web トラフィックを検査するプロキシは、Web ソケット接続に干渉する場合があります。この問題が発生した場合、*.Webex.com への検査を行わないトラフィックをバイパスすると問題が解決する可能性があります。すでに他のエントリが表示されている場合は、最後のエントリの後にセミコロンを追加し、Webex 例外を入力します。
Windows OS のプロキシ設定
Microsoft Windows は、プロキシ設定を許可する HTTP トラフィック (WinINet および WinHTTP) のための 2 つのネットワーク ライブラリをサポートしています。WinINet は WinHTTP のスーパーセットです。
-
WinInet は、シングルユーザーのデスクトップ クライアント アプリケーション用に設計されています
-
WinHTTP は、主にマルチユーザのサーバーベースのアプリケーション用に設計されています
いずれかを選択する場合は、プロキシ設定の [WinINet] を選択します。詳細については、wininet-vs-winhttp を参照してください。
以下の詳細については、「企業ネットワークで Webex にアクセスするために許可されたドメインのリストを構成する 」を参照してください。
-
ユーザーがドメインの事前定義済みリストのアカウントを使用してアプリケーションにのみサインインするようにします。
-
プロキシ サーバーを使用して、リクエストを遮断し、許可されているドメインを制限します。
プロキシ 検査および証明書ピニング
Webex アプリとデバイスは、TLS セッションを確立するときに、サーバーの証明書を検証します。証明書は、証明書の発行者およびデジタル署名などの証明書がルート証明書までの証明書のチェーンを検証することに依存していることを確認します。検証チェックを実行するために、Webex アプリとデバイスは、オペレーティング システムの信頼ストアにインストールされた信頼されたルート CA 証明書のセットを使用します。
Webex Calling トラフィックをインターセプト、復号、検査するために TLS 検査プロキシを展開した場合。プロキシが提示する証明書 (Webex サービス証明書の代わりに) が証明機関によって署名されており、ルート証明書が Webex アプリまたは Webex デバイスの信頼ストアにインストールされていることを確認してください。
-
Webex アプリの場合 - デバイスのオペレーティング システムでプロキシによって証明書に署名するために使用される CA 証明書をインストールします。
-
Webex Room デバイスと Cisco マルチプラットフォーム IP 電話の場合 - TAC チームとのサービス リクエストを開き、CA 証明書をインストールします。
この表は、プロキシ サーバーによる TLS 検査をサポートする Webex アプリと Webex デバイスを示しています
製品 |
TLS 検査のためのカスタムの信頼性のある CA をサポートします |
---|---|
Webex アプリ(Windows、Mac、iOS、Android、ウェブ) |
はい |
Webex Room デバイス |
はい |
Cisco IP マルチプラットフォーム(MPP)電話 |
あり |
ファイアウォールの設定
Cisco は、セキュアな Cisco および Amazon Web Services (AWS) データセンターで Webex Calling および Webex Aware サービスをサポートしています。Amazon は、シスコの単独使用のために IP サブネットを予約し、AWS 仮想プライベート クラウド内のこれらのサブネットにあるサービスを保護しました。
お使いのデバイス、アプリのアプリケーション、およびインターネットサービスからの通信が正常に機能を実行できるようにファイアウォールを設定します。この設定により、サポートされているすべての Webex Calling および Webex Aware クラウド サービス、ドメイン名、IP アドレス、ポート、プロトコルにアクセスできます。
Webex Calling および Webex Aware サービスが正しく機能するように、ホワイトリストまたは次のアクセス権を開きます。
-
「Webex Calling サービスのドメインと URL」セクションで言及されている URL/ドメイン
-
「Webex Calling サービスの IP サブネット」セクションで言及されている IP サブネット、ポート、およびプロトコル
-
組織内で Webex クラウド コラボレーション サービスの Webex スイート、Webex Meetings、Messaging、Webex アテンダントコンソール、およびその他のサービスを使用している場合は、IP サブネットを持っていることを確認します。これらの記事で言及されているドメイン/URL は、「Webex サービスのネットワーク要件 」および「アテンダントコンソールのネットワーク要件」が開いています。
ファイアウォールのみを使用している場合、一部の IP アドレス プールは動的で、いつでも変更される可能性があるため、IP アドレスを使用して Webex Calling トラフィックをフィルタリングすることはサポートされません。ルールを定期的に更新すると、ファイアウォールのルール リストの更新に失敗すると、ユーザーのエクスペリエンスに影響を与える可能性があります。Cisco は、特定の地域またはクラウド サービス プロバイダーに基づいて、IP アドレスのサブセットをフィルタリングすることを推奨しません。地域別にフィルタリングすると、通話エクスペリエンスが著しく低下する可能性があります。
Cisco は IP アドレス プールの動的な変更を維持していないため、この記事には記載されません。
ファイアウォールがドメイン/URL フィルタリングをサポートしていない場合は、エンタープライズ プロキシ サーバー オプションを使用してください。このオプションは、ファイアウォールに転送する前に、プロキシ サーバーの Webex Calling および Webex Aware サービスへの HTTP シグナリング トラフィックを URL/ドメインでフィルタ/許可します。
コール メディアのポートと IP サブネット フィルタリングを使用してトラフィックを設定できます。メディア トラフィックにはインターネットへの直接アクセスが必要であるため、シグナリング トラフィックの URL フィルタリング オプションを選択します。
Webex Calling の場合、UDP はメディアに対して Cisco が推奨するトランスポート プロトコルであり、UDP 経由の SRTP のみを使用することをお勧めします。メディアのトランスポート プロトコルとして TCP および TLS は、本番環境の Webex Calling ではサポートされていません。これらのプロトコルの接続指向の性質は、損失のあるネットワーク上のメディア品質に影響します。トランスポートプロトコルに関するクエリがある場合は、サポート チケットを発行します。
Webex Calling サービスのドメインと URL
URL の先頭に表示される * (例: *.webex.com) は、最上位ドメインとすべてのサブドメインのサービスがアクセス可能であることを示します。
ドメイン/ URL |
説明 |
これらのドメイン/URL を使用した Webex アプリとデバイス |
---|---|---|
Cisco Webex サービス | ||
*.broadcloudpbx.com |
Control Hub から通話管理ポータルへのクロスローンチのための Webex 認証マイクロサービス。 |
Control Hub |
*.broadcloud.com.au |
オーストラリアの Webex Calling サービス。 |
すべて |
*.broadcloud.eu |
ヨーロッパの Webex Calling サービス。 |
すべて |
*.broadcloudpbx.net |
Calling クライアントの構成と管理サービス。 |
Webex アプリ |
*.webex.com *.cisco.com |
コア Webex Calling および Webex Aware サービス
電話機を初めてネットワークに接続する場合、または DHCP オプションが設定されていない工場出荷時の状態へのリセット後、ゼロ タッチ プロビジョニングのためにデバイス アクティベーション サーバに接続します。新しい電話機は activate.cisco.com を使用し、11.2(1) 以前のファームウェア リリースの電話機は、引き続きプロビジョニングのために webapps.cisco.com を使用します。 binaries.webex.com からデバイスのファームウェアとロケールの更新をダウンロードします。 12.0.3 バージョンより古い Cisco マルチプラットフォーム フォン (MPP) が、ポート 80 から sudirenewal.cisco.com にアクセスして、製造元でインストールされた証明書 (MIC) を更新し、セキュアな一意のデバイス識別子 (SUDI) を持つことを許可します。詳細については、フィールド通知を参照してください。 |
すべて |
*.ucmgmt.cisco.com |
Webex Calling サーバー |
Control Hub |
*.wbx2.com および *.ciscospark.com |
オンボーディング中およびオンボーディング後に、Webex Calling と Webex Aware サービスに連絡するためのクラウド認識に使用されます。 これらのサービスは
|
すべて |
*.webexapis.com |
Webex アプリと Webex デバイスを管理する Webex マイクロサービス。
|
すべて |
*.webexcontent.com |
一般的なファイル ストレージに関する Webex メッセージング サービス:
|
Webex アプリ メッセージング サービス。 2019 年 10 月に webexcontent.com を使用したファイル ストレージが clouddrive.com に置き換えられました |
*.accompany.com |
People Insights の連携 |
Webex アプリ |
追加の Webex 関連サービス (サードパーティ ドメイン) | ||
*.appdynamics.com *.eum-appdynamics.com |
パフォーマンストラッキング、エラーおよびクラッシュキャプチャ、セッションメトリックス。 |
Control Hub |
*.sipflash.com |
デバイス管理サービス。ファームウェアのアップグレードと安全なオンボーディング目的。 |
Webex アプリ |
*.walkme.com *.walkmeusercontent.com |
Webex ユーザーガイドクライアント。新規ユーザーのためにオンボードの方法と使用方法のツアーが提供されます。 WalkMe の詳細については、ここをクリックしてください。 |
Webex アプリ |
*.google.com *.googleapis.com |
モバイル デバイスの Webex アプリへの通知 (例: 新しいメッセージ (通話への応答時) IP サブネットについては、次のリンクを参照してください。 Google Firebase Cloud Messaging (FCM) サービス Apple Push Notification Service (APNS) APNS の場合、Apple は、このサービスの IP サブネットを一覧表示します。 | Webex アプリ |
Webex Calling サービスの IP サブネット
Webex Calling サービスの IP サブネット*† | ||
---|---|---|
23.89.0.0/16 |
85.119.56.0/23 |
128.177.14.0/24 |
128.177.36.0/24 |
135.84.168.0/21 |
139.177.64.0/21 |
139.177.72.0/23 |
144.196.0.0/16 |
150.253.128.0/17 |
163.129.0.0/17 |
170.72.0.0/16 |
170.133.128.0/18 |
185.115.196.0/22 |
199.19.196.0/23 |
199.19.199.0/24 |
199.59.64.0/21 | ||
デバイス設定とファームウェア管理 (Cisco 逸脱) | ||
3.20.185.219 |
3.130.87.169 |
3.134.166.179 |
52.26.82.54 |
72.163.10.96/27 |
72.163.15.64/26 |
72.163.15.128/26 |
72.163.24.0/23 |
72.163.10.128/25 |
173.37.146.128/25 |
173.36.127.0/26 |
173.36.127.128/26 |
173.37.26.0/23 |
173.37.149.96/27 |
192.133.220.0/26 |
192.133.220.64/26 | ||
Webex アプリの設定 | ||
62.109.192.0/18 |
64.68.96.0/19 |
150.253.128.0/17 |
207.182.160.0/19 |
接続目的 | ソース アドレス | ソース ポート | プロトコル | 接続先アドレス | 宛先ポート | 注 | |
---|---|---|---|---|---|---|---|
Webex Calling へのコール信号 (SIP TLS) | ローカル ゲートウェイ外部 (NIC) | 8000-65535 | TCP | 「Webex Calling サービスの IP サブネット」を参照してください。 | 5062, 8934 |
これらの IP/ポートは、ローカル ゲートウェイ、デバイス、および Webex アプリ アプリケーション (ソース) から Webex Calling クラウド (宛先) への発信 SIP-TLS コール シグナリングに必要です。 ポート 5062(証明書ベースのトランクに必要)。およびポート 8934 (登録ベースのトランクに必要) | |
デバイス | 5060-5080 | 8934 | |||||
Webex アプリ | 一時的 (OS 依存) | ||||||
Webex Calling (SIP TLS) からローカル ゲートウェイへのコール シグナリング |
Webex Calling のアドレス範囲。 「Webex Calling サービスの IP サブネット」を参照してください。 | 8934 | TCP | ローカル ゲートウェイに顧客が選択した IP または IP 範囲 | ローカル ゲートウェイに顧客が選択したポートまたはポート範囲 |
証明書ベースのローカル ゲートウェイに適用されます。Webex Calling からローカル ゲートウェイへの接続を確立する必要があります。 登録ベースのローカル ゲートウェイは、ローカル ゲートウェイから作成された接続を再利用することで機能します。 宛先ポートは、[トランクの設定] を選択した顧客です。 | |
Webex Calling へのコール メディア (STUN、SRTP/SRTCP、T38、DTLS) | ローカル ゲートウェイ外部 NIC | 8000-48199†* | UDP | 「Webex Calling サービスの IP サブネット」を参照してください。 |
5004、9000 (STUN ポート) 音声: 8500-8599 ビデオ: 8600-8699 19560-65535 (UDP 経由の SRTP) |
| |
デバイス†* | 19560-19661 | ||||||
VG400 ATA デバイス | 19560-19849 | ||||||
Webex アプリ†* |
音声: 8500-8599 ビデオ: 8600-8699 | ||||||
WebRTC | 一時的(ブラウザポリシーによる) | ||||||
Webex Calling からのコール メディア (SRTP/SRTCP、T38) |
Webex Calling のアドレス範囲。 「Webex Calling サービスの IP サブネット」を参照してください。 | 19560-65535 (UDP 経由の SRTP) | UDP | ローカル ゲートウェイに顧客が選択した IP または IP 範囲 | 顧客がローカル ゲートウェイに選択したメディアポート範囲 | ||
PSTN ゲートウェイへのコール信号 (SIP TLS) | ローカル ゲートウェイ内部 NIC | 8000-65535 | TCP | ITSP、PSTN GW または Unified CM | PSTN オプションによって異なる (たとえば、Unified CM の 5060 または 5061) | ||
PSTN ゲートウェイへのコール メディア (SRTP/SRTCP) | ローカル ゲートウェイ内部 NIC | 8000-48199†* | UDP | ITSP、PSTN GW または Unified CM | PSTN オプションによって異なります(たとえば、Unified CM の場合は 5060 または 5061) | ||
デバイスの構成とファームウェアの管理 (Cisco デバイス) | Webex Calling デバイス | 一時的 | TCP |
「Webex Calling サービスの IP サブネット」を参照してください。 | 443, 6970, 80 |
次の理由で必須:
| |
Webex アプリの設定 | Webex アプリ アプリケーション | 一時的 | TCP |
「Webex Calling サービスの IP サブネット」を参照してください。 | 443, 8443 | Id ブローカー認証、クライアントの Webex アプリ構成サービス、セルフケアおよび管理インターフェイス アクセスのためのブラウザベースの Web アクセスに使用されます。 TCP ポート 8443 は、構成をダウンロードするために Cisco Unified CM セットアップの Webex アプリで使用されます。Webex Calling に接続するためにセットアップを使用する顧客のみがポートを開く必要があります。 | |
デバイス時間同期 (NTP) | Webex Calling デバイス | 51494 | UDP | 「Webex Calling サービスの IP サブネット」を参照してください。 | 123 | これらの IP アドレスは、デバイス(MPP 電話、ATA、SPA ATA)の時間同期に必要です。 | |
ドメイン ネーム システム(DNS)の解決 | Webex Calling デバイス、Webex アプリ、Webex デバイス | 一時的 | UDP および TCP | 主催者が定義 | 53 | DNS ルックアップでクラウドの Webex Calling サービスの IP アドレスを検出するために使用されます。典型的な DNS ルックアップは UDP で行われますが、クエリ応答が UDP パケットに収まらない場合、TCP が必要な場合があります。 | |
ネットワーク タイム プロトコル (NTP) | Webex アプリと Webex デバイス | 123 | UDP | 主催者が定義 | 123 | 時間同期 | |
CScan | Webex Calling の Web ベースのネットワーク準備事前資格ツール | 一時的 | TCP | 「Webex Calling サービスの IP サブネット」を参照してください。 | 8934 および 443 | Webex Calling の Web ベースのネットワーク準備事前資格ツールです。詳細については、cscan.webex.com を参照してください。 | |
UDP | 19569-19760 | ||||||
追加の Webex Calling および Webex Aware サービス (サードパーティ) | |||||||
プッシュ通知 APNS および FCM サービス | Webex Calling アプリケーション | 一時的 | TCP |
リンクの下に記載されている IP サブネットを参照してください | 443, 2197, 5228, 5229, 5230, 5223 | モバイル デバイスの Webex アプリへの通知 (例: 新しいメッセージを受信したとき、またはコールに応答したとき) |
-
†*CUBE メディアポート範囲は rtp ポート範囲で設定できます。
-
†*SRTP ポート範囲に動的に割り当てられているデバイスおよびアプリケーションのメディアポート。SRTP ポートは番号付きポートでもあり、対応する SRTCP ポートは連続した奇数番号付きポートに割り当てられます。
-
アプリとデバイス用にプロキシ サーバ アドレスが設定されている場合、シグナリング トラフィックがプロキシに送信されます。UDP 経由で転送された SRTP メディアは、プロキシ サーバーの代わりにファイアウォールに直接フローします。
-
エンタープライズ ネットワーク内で NTP および DNS サービスを使用している場合は、ファイアウォールを通してポート 53 および 123 を開きます。
サービスの質(QoS)
ローカル デバイスまたはクライアントから Webex Calling クラウド プラットフォームへのパケットのタグ付けを有効にできます。QoS を使用すると、リアルタイム トラフィックを他のデータ トラフィックよりも優先できます。この設定を有効にすると、SIP シグナリングとメディアを使用するアプリとデバイスの QoS マーキングが変更されます。
ソース アドレス | トラフィック タイプ | 接続先アドレス | ソース ポート | 宛先ポート | DSCP クラスと値 |
---|---|---|---|---|---|
Webex アプリ | 音声 |
Webex Calling サービスの IP サブネット、ドメイン、URL を参照する | 8500-8599 | 8500-8599, 19560-65535 | 迅速な転送 (46) |
Webex アプリ | ビデオ | 8600-8699 | 8600-8699, 19560-65535 | 保証された転送 41 (34) | |
Webex アプリ | 署名 | 一時的 (OS 依存) | 8934 | cs0(0) | |
Webex デバイス (MPP および Room) | 音声 & ビデオ | 19560-19661 | 19560-65535 |
迅速な転送 (46) & 保証された転送 41 (34) | |
Webex デバイス | 署名 | 5060-5080 | 8934 | クラス セレクター 3 (24) |
-
ソースポート範囲が異なるため、音声とビデオ/共有用に別の QoS プロファイルを作成します。
-
Windows クライアントの場合: 組織で UDP ソースポートの差別化を有効にするには、ローカル アカウント チームに連絡してください。有効にしないと、Windows QoS ポリシー (GPO) を使用して音声とビデオ/共有を区別することができません。これは、ソース ポートが音声/ビデオ/共有で同じであるためです。詳細については、「Webex アプリのメディア ソース ポート範囲を有効にする」を参照してください。
-
Webex デバイスの場合、Control Hub デバイス設定から QoS 設定の変更を構成します。詳細については、「Webex-Calling のデバイス設定を構成して変更する」を参照してください。
Webex Meetings/Messaging - ネットワーク要件
Webex Suite of Cloud コラボレーション サービス、Webex クラウド登録製品を使用している顧客の場合、通話履歴、ディレクトリ検索、ミーティング、メッセージングなどのサービスのために、MPP デバイスを Webex Cloud にオンボードします。この記事で説明されているドメイン/URL/IP アドレス/ポートが Webex サービスのネットワーク要件であることを確認してください。
政府版 Webex (FedRAMP) のネットワーク要件
政府版 Webex サービス (FedRAMP) のドメイン、URL、IP アドレス範囲、ポートのリストが必要な顧客については、次の情報を参照してください。Webex for Government のネットワーク要件
Webex アテンダントコンソールのネットワーク要件
アテンダントコンソール - レセプショニスト、アテンダントおよびオペレータ機能を使用している顧客の場合、ドメイン/URL/IP アドレス/ポート/プロトコルがオープンであることを確認してください。アテンダントコンソールのネットワーク要件
Webex Calling ローカル ゲートウェイを使い始める
プレミスベースの PSTN およびサードパーティの SBC の相互運用性のために Webex Calling でローカル ゲートウェイ ソリューションを使用する顧客については、「ローカル ゲートウェイの使用を開始する」の項目を参照してください。
リファレンス
Webex Calling の新機能については、「Webex Calling の新機能」を参照してください。
Webex Calling のセキュリティ要件については、記事を参照してください。
Interactive Connectivity Establishment (ICE) を使用した Webex Calling メディア最適化記事
文書の改訂履歴
日付 |
この記事に次の変更を行いました |
---|---|
2025 年 1 月 21 日 |
SIP Application Layer Gateway の使用に関する詳細を追加しました。 |
2025 年 1 月 8 日 |
デバイス設定および Webex アプリの設定に関連する IP サブネット アドレスを Webex Calling サービスの IP サブネット セクションに移動しました |
2024 年 12 月 17 日 |
Webex Calling メディア仕様の WebRTC にサポートを追加しました。 |
2024 年 11 月 14 日 |
VG400 シリーズ ATA デバイスの Webex Calling コール メディアのサポートされるポート範囲を更新しました |
2024 年 11 月 11 日 |
VG400 シリーズ ATA デバイスの Webex Calling コール メディアのサポートされるポート範囲が追加されました |
2024 年 7 月 25 日 |
Cisco ATA デバイス構成とファームウェア管理に必要な 52.26.82.54 IP サブネットを追加しました。 |
2024 年 7 月 18 日 |
次の詳細で更新されました。
|
2024 年 6 月 28 日 |
Webex Calling メディア仕様の SRTP/SRTCP ポート範囲の使用を更新しました。 |
2024 年 6 月 11 日 |
使用されていないため、「huron-dev.com」ドメインを削除しました。 |
2024 年 5 月 6 日 |
Webex Calling メディア仕様の SRTP/SRTCP ポート範囲の使用を更新しました。 |
2024 年 4 月 3 日 | インド地域の Webex Calling 市場拡大に対応するために、Webex Calling サービスの IP サブネットを 163.129.0.0/17 に更新しました。 |
2023 年 12 月 18 日 |
Cisco MPP 電話の MIC 更新のデバイス設定とファームウェア管理のための sudirenewal.cisco.com URL およびポート 80 の要件が含まれています。 |
2023 年 12 月 11 日 |
Webex Calling サービスの IP サブネットを更新し、より大きな IP アドレスのセットを含めるようにしました。 150.253.209.128/25 – 150.253.128.0/17 に変更 |
2023 年 11 月 29 日 |
Webex Calling サービスの IP サブネットを更新し、将来の成長のために WEBEX Calling リージョンの拡張に対応するために、より大きな IP アドレスを追加しました。 144.196.33.0/25 – 144.196.0.0/16 に変更 Webex Calling (SIP TLS) および Webex Calling へのコール メディア (STUN、SRTP) の下の Webex Calling サービスの IP サブネットセクションが更新され、証明書ベースのトランキングとローカル ゲートウェイのファイアウォールの要件が明確になりました。 |
2023 年 8 月 14 日 |
Edge および Webex Calling サービスの容量要件の増加をサポートするために、次の IP アドレス 144.196.33.0/25 と 150.253.156.128/25 を追加しました。 この IP 範囲は、米国地域でのみサポートされています。 |
2023 年 7 月 5 日 |
Cisco MPP ファームウェアをインストールするためのリンクhttps://binaries.webex.com を追加しました。 |
2023 年 3 月 7 日 |
記事全体を見直して、以下を含めました。
|
2023年3月5日 |
記事を更新して、以下を含めます。
|
2022 年 11 月 15 日 |
デバイス構成とファームウェア管理 (Cisco デバイス) に次の IP アドレスを追加しました。
デバイス構成とファームウェア管理 (Cisco デバイス) から次の IP アドレスを削除しました。
|
2022 年 11 月 14 日 |
Webex Calling サービスの IP サブネット 170.72.242.0/24 を追加しました。 |
2022 年 9 月 8 日 |
Cisco MPP ファームウェアは、すべての地域で MPP ファームウェア アップグレードのホスト URL としてhttps://binaries.webex.com 使用するように移行します。この変更はファームウェア アップグレード のパフォーマンスを改善します。 |
2022 年 8 月 30 日 |
依存関係がないため、ポート テーブル内のデバイス設定とファームウェア管理(Cisco デバイス)、アプリケーション設定、および CScan 行からポート 80 への参照を削除しました。 |
2022 年 8 月 18 日 |
ソリューションに変更はありません。Webex Calling (SIP TLS) への通話シグナリングの宛先ポート 5062 (証明書ベースのトランクに必要)、8934 (登録ベース トランクに必要) を更新しました。 |
2022 年 7 月 26 日 |
Cisco 840/860 デバイスのファームウェア アップグレードに必要な 54.68.1.225 IP アドレスを追加しました。 |
2022 年 7 月 21 日 |
通話シグナリングの宛先ポート 5062、8934 を Webex Calling (SIP TLS) に更新しました。 |
2022 年 7 月 14 日 |
Webex Aware サービスの完全な機能をサポートする URL を追加しました。 Webex Calling サービスに IP サブネット 23.89.154.0/25 を追加しました。 |
2022 年 6 月 27 日 |
サイト サービスのドメインと URL Webex Callingしました。 *.broadcloudpbx.com *.broadcloud.com.au *.broadcloud.eu *.broadcloudpbx.net |
2022 年 6 月 15 日 |
[IP アドレス] の下に以下 のポートとプロトコルを追加し、Webex Callingしました。
[Webex Meetings/メッセージング - ネットワーク要件] セクションの情報を更新しました |
2022 年 5 月 24 日 |
Webex Calling サービスに IP サブネット 52.26.82.54/24 を 52.26.82.54/32 に追加しました |
2022 年 5 月 6 日 |
以下のサービスに IP サブネット 52.26.82.54/24 Webex Callingしました |
2022 年 4 月 7 日 |
ローカル ゲートウェイの内部および外部 UDP ポート範囲を 8000~48198† に更新しました |
2022 年 4 月 5 日 |
このサービスに以下の IP サブネットWebex Callingしました。
|
2022 年 3 月 29 日 |
このサービスに以下の IP サブネットWebex Callingしました。
|
2021 年 9 月 20 日 |
Webex Calling サービスに 次の 4 つの新しい IP サブネットが追加されました。
|
2021 年 4 月 2 日 |
[Webex Calling サービスのドメインと URL] で *.ciscospark.com を追加し、Webex アプリで Webex Calling の使用事例をサポートします。 |
2021 年 3 月 25 日 |
activate.cisco.com に 6 つの新しい IP 範囲が追加されました。これは 2021 年 5 月 8 日から有効になります。
|
2021 年 3 月 4 日 |
ファイアウォールの構成を容易に理解できるように、Webex Calling の個別の IP とより小さい IP 範囲を別のテーブルの簡素化された範囲に置き換えました。 |
2021 年 2 月 26 日 |
2021 年 4 月に Webex Calling で利用可能なインタラクティブ接続性の高さ (ICE) をサポートするために、通話メディアの宛先ポートとして Webex Calling (STUN、SRTP) に 5004 が追加されました。 |
2021 年 2 月 22 日 |
ドメインと URL が別のテーブル内に表示されるようになりました。 IP アドレスとポート テーブルは、同じサービスの IP アドレスをグループ化するように調整されます。 IP アドレスとポートのテーブルに [メモ] 列を追加することで、要件を理解するのに役立ちます。 次の IP アドレスを、デバイス設定とファームウェア管理 (Cisco デバイス) の簡素化された範囲に移動します。
Cisco Webex クライアントは 2021 年 3 月にオーストラリアで新しい DNS SRV をポイントしているため、アプリケーション構成に次の IP アドレスを追加します。
|
2021 年 1 月 21 日 |
次の IP アドレスを、デバイス構成とファームウェア管理 (Cisco デバイス) に追加しました。
デバイス構成とファームウェア管理 (Cisco デバイス) から次の IP アドレスを削除しました。
次の IP アドレスをアプリケーション構成に追加しました。
次の IP アドレスをアプリケーション構成から削除しました。
アプリケーション構成から次のポート番号を削除しました。
次のドメインをアプリケーション構成に追加しました。
|
2020年12月23日 |
ポート参照画像に新しいアプリケーション構成 IP アドレスを追加しました。 |
2020年12月22日 |
テーブルのアプリケーション構成行が更新され、次の IP アドレスが含まれます。135.84.169.186 および 135.84.170.186 これらの IP アドレスが追加されるまで、ネットワーク図を非表示にします。 |
2020年12月11日 |
サポートされているカナダ ドメインの [デバイス] 構成とファームウェア管理 (Cisco デバイス) および [アプリケーション] 構成行を更新しました。 |
2020年10月16日 |
以下の IP アドレスを使用して、通話シグナリングおよびメディア エントリを更新しました。
|
2020 年 9 月 23 日 |
CScan では、199.59.64.156 を 199.59.64.197 に置き換えました。 |
2020 年 8 月 14 日 |
カナダのデータセンターの導入をサポートするために、さらに多くの IP アドレスが追加されました。 Webex Calling への信号発信 (SIP TLS) — 135.84.173.0/25、135.84.174.0/25、199.19.197.0/24、199.19.199.0/24 |
2020 年 8 月 12 日 |
カナダのデータセンターの導入をサポートするために、さらに多くの IP アドレスが追加されました。
|
2020 年 7 月 22 日 |
カナダのデータセンターの導入をサポートするために、次の IP アドレスを追加しました。135.84.173.146 |
2020 年 6 月 9 日 |
CScan エントリに次の変更を行いました:
|
2020/03/11 |
次のドメインと IP アドレスをアプリケーション構成に追加しました。
追加の IP アドレスを持つ以下のドメインをデバイスの設定とファームウェア管理に更新しました:
|
2020 年 2 月 27 日 |
次のドメインとポートをデバイス構成とファームウェア管理に追加しました: cloudupgrader.webex.com—443, 6970 |
Cisco IOS XE で Webex Calling のローカル ゲートウェイを構成する
概要
Webex Calling は現在、ローカル ゲートウェイの 2 つのバージョンをサポートしています。
-
ローカルゲートウェイ
-
政府版 Webex のローカル ゲートウェイ
-
開始する前に、Webex Calling のプレミスベースの公衆交換電話網 (PSTN) とローカル ゲートウェイ (LGW) の要件について理解してください。詳細については 、「設定されたアーキテクチャ」Webex Calling を参照してください。
-
この記事では、専用のローカル ゲートウェイ プラットフォームが配置されているが、既存の音声構成がないと仮定しています。既存の PSTN ゲートウェイまたは CUBE Enterprise の展開を変更して、Webex Calling のローカル ゲートウェイ機能として使用する場合は、設定に注意してください。変更を行ったため、既存の通話フローと機能を中断しないようにしてください。
手順にはコマンドリファレンスドキュメントへのリンクが含まれており、個々のコマンドオプションの詳細を確認できます。特に明記されていない限り、すべてのコマンド参照リンクは Webex 管理対象ゲートウェイのコマンドリファレンス に進みます (その場合、コマンドリンクは Cisco IOS 音声コマンドリファレンスに進みます)。これらのすべてのガイドには、Cisco Unified Border Element コマンドリファレンスからアクセスできます。
サポートされているサードパーティ SBC の詳細については、それぞれの製品参照ドキュメントを参照してください。
システム トランクのローカル ゲートウェイを設定するための 2 つの Webex Calling があります。
-
登録ベースのトランク
-
証明書ベースのトランク
[登録ベースのローカル ゲートウェイ] または [証明書ベースのローカル ゲートウェイ] のタスク フローを使用して、Webex Calling トランクのローカル ゲートウェイを設定します。
異なるトランク タイプの詳細については、「ローカル ゲートウェイを使い始める 」を参照してください。コマンドラインインターフェース (CLI) を使用して、ローカル ゲートウェイ自体で以下の手順を実行します。Session Initiation Protocol (SIP) および Transport Layer Security (TLS) トランスポートを使用してトランクを保護し、Secure Real Time Protocol (SRTP) を使用してローカル ゲートウェイと Webex Calling 間のメディアを保護します。
-
ローカル ゲートウェイとして CUBE を選択します。政府版 Webex は、現在、サードパーティのセッション ボーダー コントローラー (SBC) をサポートしていません。最新のリストを確認するには、「ローカル ゲートウェイの使用を開始する」を参照してください。
- すべての Webex for Government のローカル ゲートウェイに対して 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 証明書ベースのトランクを構成する」を参照してください。
政府版 Webex は、登録ベースのローカル ゲートウェイをサポートしていません。
このセクションでは、登録する SIP トランクを使用して、Cisco Unified Border Element (CUBE) を Webex Calling のローカル ゲートウェイとして設定する方法について説明します。このドキュメントの最初の部分では、シンプルな PSTN ゲートウェイを設定する方法について説明します。この場合、PSTN からのすべてのコールは Webex Calling にルーティングされ、Webex Calling からのすべてのコールは PSTN にルーティングされます。以下の画像は、このソリューションと、それに続く高レベルのコール ルーティング設定を強調しています。
この設計では、次の主要な構成が使用されます。
-
音声クラス テナント: トランク固有の構成の作成に使用されます。
-
音声クラス uri: 着信ダイヤルピアの選択の SIP メッセージを分類するために使用されます。
-
着信ダイヤルピア: 着信 SIP メッセージの処理を提供し、ダイヤルピア グループを使用して発信ルートを決定します。
-
ダイヤルピア グループ: オンワードコール ルーティングに使用する発信ダイヤルピアを定義します。
-
発信ダイヤルピア: アウトバウンド SIP メッセージの処理を提供し、それらを必要なターゲットにルーティングします。
IP および SIP は PSTN トランクのデフォルトのプロトコルになっていますが、TDM (時間分割多重化) 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 シリーズ ルータは、ユニファイド コミュニケーション ライセンスとセキュリティ テクノロジー ライセンスの両方で設定する必要があります。
-
音声カードまたは DSP が搭載されている Catalyst Edge 8000 シリーズ ルータには、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 サーバ コマンドにより、テナント 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-id および stun flowdata shared-secret を参照してください。 非対称ペイロード (フル)DTMF と動的コーデック ペイロードの両方に対して SIP 非対称ペイロード サポートを設定します。詳細については、非対称ペイロードを参照してください。 early-offer forcedローカル ゲートウェイが、隣接ピアからの確認応答を待つ代わりに、最初の INVITE メッセージで SDP 情報を送信するように強制します。このコマンドの詳細については、早期オファーを参照してください。 |
3 |
すべてのトランクに対して G.711 コーデックのみを許可する音声クラス コーデック 100 を設定します。このシンプルなアプローチは、ほとんどの導入に適しています。必要に応じて、発信元システムと終端システムの両方でサポートされている追加のコーデック タイプをリストに追加できます。 DSP モジュールを使用したトランスコーディング を含むより複雑なソリューションはサポートされていますが、このガイドには含まれていません。 以下は、設定のフィールドの説明です。 音声クラス コーデック 100SIP トランク コールの優先コーデックのみを許可するために使用されます。詳細については、音声クラス コーデックを参照してください。 |
4 |
音声クラス stun-usage 100 を設定して、Webex Calling トランクで ICE を有効にします。 以下は、設定のフィールドの説明です。 STUNの使用法ice lite可能なときは常に、メディア最適化を可能にする、すべての Webex Calling でダイヤルピアで ICE-Lite を有効にします。詳細については、音声クラス stun 使用状況 および使用状況のice liteを参照してください。 メディアの最適化は、可能な限り、ネゴシエートされます。通話に録画などのクラウド メディア サービスが必要な場合、メディアを最適化できません。 |
5 |
Webex トラフィックのメディア暗号化ポリシーを設定します。 以下は、設定のフィールドの説明です。 音声クラス srtp-crypto 100オファーと応答メッセージの SDP で唯一の SRTP 暗号スイート CUBE が提供されるため、SHA1_80 を指定します。Webex Calling は SHA1_80 のみをサポートします。詳細については、「voice class 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 に登録できます。登録が認証にチャレンジする場合:
-
資格情報 設定のユーザー名、パスワード、および 領域 パラメータが応答で使用されます。
-
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 を参照してください。 bind control source-interface GigabitEthernet0/0/0
PSTN に送信されるメッセージのソース インターフェイスと関連する IP アドレスを設定します。詳細については、バインドを参照してください。 bind media source-interface GigabitEthernet0/0/0PSTN に送信されるメディアのソース インターフェイスと関連する IP アドレスを設定します。詳細については、バインドを参照してください。 音声クラスのコーデック 100共通のコーデック フィルター リスト 100 を使用するようにダイヤル ピアを設定します。詳細については、音声クラス コーデックを参照してください。 dtmf-relay rtp-nte通話レグで予想される DTMF 機能として RTP-NTE (RFC2833) を定義します。詳細については、「DTMF リレー (音声オーバー IP)」を参照してください。 no vad音声アクティブティの検出を無効にします。詳細については、vad (ダイヤル ピア) を参照してください。 |
3 |
ローカル ゲートウェイを Webex Calling と PSTN 間のコールのみをルーティングするように設定している場合は、次のコール ルーティング設定を追加します。Unified Communications Manager プラットフォームを使用してローカル ゲートウェイを設定する場合は、次のセクションに進みます。 |
Webex Calling に向かってトランクを構築した後、次の構成を使用して、ループバック コール ルーティングを持つ PSTN サービスの TDM トランクを作成し、Webex コール レッグのメディア最適化を可能にします。
IP メディアの最適化を必要としない場合は、SIP PSTN トランクの設定手順に従います。PSTN VoIP ダイヤルピアの代わりに、音声ポートと POTS ダイヤルピア(ステップ 2 と 3 に示すように)を使用します。
1 |
ループバック ダイヤル ピア設定では、ダイヤル ピア グループとコール ルーティング タグを使用して、コール ルーティング ループを作成することなく、コールが Webex と PSTN の間で正しくパスされるようにします。コール ルーティング タグを追加および削除するために使用される次のトランスレーション ルールを設定します。 以下は、設定のフィールドの説明です。 音声翻訳ルールルールで定義された正規表現を使用して、コール ルーティング タグを追加または削除します。十進法を超える数字(「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 を調整して、ルーティング タグを追加および削除するだけです。 詳細については、音声翻訳プロファイル および音声翻訳ルールを参照してください。 |
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 |
ローカル ゲートウェイの IP パスのメディア最適化を TDM-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 ダイヤル ピア) を参照してください。 bind control source-interface GigabitEthernet0/0/0ループバックを通じて送信されるメッセージのソース インターフェイスおよび関連する IP アドレスを設定します。詳細については、バインドを参照してください。 bind media source-interface GigabitEthernet0/0/0ループバックを通じて送信されるメディアのソース インターフェイスと関連する IP アドレスを設定します。詳細については、バインドを参照してください。 dtmf-relay rtp-nte通話レグで予想される DTMF 機能として RTP-NTE (RFC2833) を定義します。詳細については、「DTMF リレー (音声オーバー IP)」を参照してください。 コーデック g711alaw すべての PSTN 通話で G.711 を使用するように強制します。a-law または u-law を選択して、ISDN サービスで使用するcompanding メソッドに一致させます。 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 トランク セキュリティ プロファイル(SIP Trunk Security Profile)] 設定で着信ポートを 5065 に設定してください。これにより、ポート 5065 の着信メッセージが可能になり、ローカル ゲートウェイにメッセージを送信するときに VIA ヘッダーにこの値を入力できます。
1 |
以下の音声クラス URI を設定: |
2 |
Unified CM ホストへの SRV ルーティングを指定するには、次の DNS レコードを設定します。 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 以降を実行している場合、プロアクティブ通知を送信するために使用されるセキュアなメール サーバを設定します。
ターミナルコールホームメールサーバの設定 :@ 優先順位 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 Get-request PDU 138 GET-NEXT PDU 2 つの Set-Request PDU 0 入力キュー パケットドロップ(最大キューサイズ 1000)158277 SNMP パケット出力0 エラーが大きすぎます (最大パケットサイズ 1500) 20 名前エラーなし0 不正な値エラー0 一般的なエラー 7998 応答 PDU 10280 現在 SNMP プロセス入力キューにあるトラップ PDU パケット: 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 Get-request PDU 138 GET-NEXT PDU 2 つの Set-Request PDU 0 入力キュー パケットドロップ(最大キューサイズ 1000)158277 SNMP パケット出力0 エラーが大きすぎます (最大パケットサイズ 1500) 20 名前エラーなし0 不正な値エラー0 一般的なエラー 7998 応答 PDU 10280 現在 SNMP プロセス入力キューにあるトラップ PDU パケット: 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 (時間分割多重化) 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 の背後)アドレス指定用に提供されます。複数の CUBE インスタンス間でロード バランシングしない限り、SRV DNS レコードはオプションです。
このドキュメントの残りの構成ガイダンスを使用して、次のようにローカル ゲートウェイの設定を完了します。
-
ステップ 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 シリーズ ルータは、ユニファイド コミュニケーション ライセンスとセキュリティ テクノロジー ライセンスの両方で設定する必要があります。
-
音声カードまたは DSP が搭載されている Catalyst Edge 8000 シリーズ ルータには、DNA Advantage ライセンスを必要とします。音声カードまたは DSP を使用しないルーターには、少なくとも DNA Essentials ライセンスが必要です。
-
高容量要件については、高セキュリティ(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 のセッション トラバーサル) をグローバルに有効にします。 これらのグローバル stun コマンドは、ローカル ゲートウェイを 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 には適用されません) 以下は、設定のフィールドの説明です。 STUNの使用法ice lite可能なときは常に、メディア最適化を可能にする、すべての Webex Calling でダイヤルピアで ICE-Lite を有効にします。詳細については、音声クラス stun 使用状況 および使用状況のice liteを参照してください。 stun usage firewall-traversal flowdata コマンドは、NAT の背後にローカル ゲートウェイを展開する場合にのみ必要です。 メディアの最適化は、可能な限り、ネゴシエートされます。通話に録画などのクラウド メディア サービスが必要な場合、メディアを最適化できません。 |
5 |
Webex トラフィックのメディア暗号化ポリシーを設定します。(このステップは、政府版 Webex には適用されません) 以下は、設定のフィールドの説明です。 音声クラス srtp-crypto 100オファーと応答メッセージの SDP で唯一の SRTP 暗号スイート CUBE が提供されるため、SHA1_80 を指定します。Webex Calling は SHA1_80 のみをサポートします。詳細については、「voice class 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-profiles を参照してください。 米国またはカナダの PSTN プロバイダーは、Webex Calling のスパムまたは詐欺通話の表示 の記事で言及されている追加設定を使用して、スパムおよび詐欺通話の発信者 ID 検証を提供できます。 |
10 |
ヘッダー変更プロファイルを使用して、SIP オプション キープアライブを設定します。 以下は、設定のフィールドの説明です。 音声クラス sip-options-keepalive 100キープアライブ プロファイルを設定し、音声クラス設定モードに入ります。エンドポイントへのハートビート接続が UP またはダウン ステータスにあるときに、SIP Out of Dialog Options 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 を参照してください。 bind control source-interface GigabitEthernet0/0/0
PSTN に送信されるメッセージのソース インターフェイスと関連する IP アドレスを設定します。詳細については、バインドを参照してください。 bind media source-interface GigabitEthernet0/0/0PSTN に送信されるメディアのソース インターフェイスと関連する IP アドレスを設定します。詳細については、バインドを参照してください。 音声クラスのコーデック 100共通のコーデック フィルター リスト 100 を使用するようにダイヤル ピアを設定します。詳細については、音声クラス コーデックを参照してください。 dtmf-relay rtp-nte通話レグで予想される DTMF 機能として RTP-NTE (RFC2833) を定義します。詳細については、「DTMF リレー (音声オーバー IP)」を参照してください。 no vad音声アクティブティの検出を無効にします。詳細については、vad (ダイヤル ピア) を参照してください。 |
3 |
ローカル ゲートウェイを Webex Calling と PSTN 間のコールのみをルーティングするように設定している場合は、次のコール ルーティング設定を追加します。Unified Communications Manager プラットフォームを使用してローカル ゲートウェイを設定する場合は、次のセクションに進みます。 |
Webex Calling に向かってトランクを構築した後、次の構成を使用して、ループバック コール ルーティングを持つ PSTN サービスの TDM トランクを作成し、Webex コール レッグのメディア最適化を可能にします。
IP メディアの最適化を必要としない場合は、SIP PSTN トランクの設定手順に従います。PSTN VoIP ダイヤルピアの代わりに、音声ポートと POTS ダイヤルピア(ステップ 2 と 3 に示すように)を使用します。
1 |
ループバック ダイヤル ピア設定では、ダイヤル ピア グループとコール ルーティング タグを使用して、コール ルーティング ループを作成することなく、コールが Webex と PSTN の間で正しくパスされるようにします。コール ルーティング タグを追加および削除するために使用される次のトランスレーション ルールを設定します。 以下は、設定のフィールドの説明です。 音声翻訳ルールルールで定義された正規表現を使用して、コール ルーティング タグを追加または削除します。十進法を超える数字(「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 を調整して、ルーティング タグを追加および削除するだけです。 詳細については、音声翻訳プロファイル および音声翻訳ルールを参照してください。 |
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 |
ローカル ゲートウェイの IP パスのメディア最適化を TDM-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 ダイヤル ピア) を参照してください。 bind control source-interface GigabitEthernet0/0/0ループバックを通じて送信されるメッセージのソース インターフェイスおよび関連する IP アドレスを設定します。詳細については、バインドを参照してください。 bind media source-interface GigabitEthernet0/0/0ループバックを通じて送信されるメディアのソース インターフェイスと関連する IP アドレスを設定します。詳細については、バインドを参照してください。 dtmf-relay rtp-nte通話レグで予想される DTMF 機能として RTP-NTE (RFC2833) を定義します。詳細については、「DTMF リレー (音声オーバー IP)」を参照してください。 コーデック g711alaw すべての PSTN 通話で G.711 を使用するように強制します。a-law または u-law を選択して、ISDN サービスで使用するcompanding メソッドに一致させます。 no vad音声アクティブティの検出を無効にします。詳細については、vad (ダイヤル ピア) を参照してください。 |
5 |
次のコール ルーティング設定を追加します。 これにより、ローカル ゲートウェイの設定が終了します。CUBE 機能が初めて設定される場合は、設定を保存し、プラットフォームを再読み込みします。
|
前のセクションの PSTN-Webex Calling の設定は、Cisco Unified Communications Manager (UCM) クラスタに追加のトランクを含めるように変更できます。この場合、すべてのコールは Unified CM 経由でルーティングされます。ポート 5060 の UCM からのコールは PSTN にルーティングされ、ポート 5065 からのコールは Webex Calling にルーティングされます。この通話シナリオを含めるには、次の増分設定を追加できます。
1 |
以下の音声クラス URI を設定: |
2 |
Unified CM ホストへの SRV ルーティングを指定するには、次の DNS レコードを設定します。 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 Get-request PDU 138 GET-NEXT PDU 2 つの Set-Request PDU 0 入力キュー パケットドロップ(最大キューサイズ 1000)158277 SNMP パケット出力0 エラーが大きすぎます (最大パケットサイズ 1500) 20 名前エラーなし0 不正な値エラー0 一般的なエラー 7998 応答 PDU 10280 現在 SNMP プロセス入力キューにあるトラップ PDU パケット: 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 Get-request PDU 138 GET-NEXT PDU 2 つの Set-Request PDU 0 入力キュー パケットドロップ(最大キューサイズ 1000)158277 SNMP パケット出力0 エラーが大きすぎます (最大パケットサイズ 1500) 20 名前エラーなし0 不正な値エラー0 一般的なエラー 7998 応答 PDU 10280 現在 SNMP プロセス入力キューにあるトラップ PDU パケット: 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 では現在、新しいカスタム署名の作成リクエストをサポートしていません。
組織に合わせて Webex Calling を設定する
初回セットアップ ウィザードで通話設定をセットアップする
Webex Calling サービスを稼働させるための最初のステップは、初回セットアップ ウィザード (FTSW) を完了することです。最初のロケーションの FTSW が完了した後では、追加のロケーションに対して完了する必要がありません。
1 |
受け取ったウェルカム メールのはじめにリンクをクリックします。 管理者のメールアドレスが、自動的に、Control Hub にサインインするためのメール アドレスとして使用されます。サインインすると、管理者パスワードを作成するように求められます。サインインすると、セットアップ ウィザードが自動的に開始します。 |
2 |
利用規約を見直して、承諾します。 |
3 |
プランを見直して、[はじめに] をクリックします。 アカウント マネージャは FTSW の最初の手順をアクティブにする責任があります。[使い始める] を選択した時に、「通話をセットアップできません」という通知を受け取った場合は、アカウント マネージャーに連絡してください。 |
4 |
データ センターがマッピングする国を選択し、顧客の連絡先と顧客アドレス情報を入力します。 |
5 |
[次へ: デフォルトのロケーション |
6 |
次のオプションから選択します:
セットアップ ウィザードを完了した後で、作成したロケーションにメイン番号を追加していることを確認してください。 |
7 |
このロケーションに適用する次の選択を行います。
|
8 |
[次へ] をクリックします。 |
9 |
利用可能な Cisco Webex SIP アドレスを入力し、[次へ] をクリックし、[完了] を選択します。 |
ロケーションを追加する
始める前に
新しいロケーションを作成するには、以下の情報を指定します。
-
ロケーションの住所
-
希望する電話番号(オプション)
1 |
https://admin.webex.com で Control Hub にログインし、 に移動します。 新しいロケーションは、初回セットアップ ウィザードを使用して選択した国に対応する地域のデータ センターでホストされます。 |
2 |
ロケーションを設定します。
|
3 |
[保存 ] をクリックしてから、[ はい/いいえ ] を選択して、現在または後でロケーションに番号を追加します。 |
4 |
[はい] をクリック した場合、次のいずれかのオプションを選択します。
PSTN オプションの選択は各ロケーション レベルで行います (各ロケーションには PSTN オプションが 1 つしかありません)。展開に対して必要な数のオプションを組み合わせることができますが、各ロケーションには 1 つのオプションとなります。PSTN オプションを選択してプロビジョニングしたら、ロケーションの PSTN プロパティで [管理] をクリックすると、オプションを変更できます。ただし、Cisco PSTN などの一部のオプションは、別のオプションが割り当てられた後は使用できない場合があります。サポートケースを登録 してガイダンスを受けてください。 |
5 |
番号を今すぐに有効にするか、または後で有効にするかを選択します。 |
6 |
統合されていない CCP またはプレミス ベースの PSTN を選択した場合は、電話番号をコンマ区切り値として入力し、[検証] をクリックします。 特定のロケーションのための番号が追加されます。有効なエントリは [検証済みの番号] フィールドに移動し、無効なエントリは [番号の追加] フィールドに残り、エラー メッセージが表示されます。 番号の書式は、ロケーションの所在する国に応じ、ダイヤリングに関する地元の要件に従って定められます。たとえば、国コードが必要な場合には、コードを付けて入力することも、コードなしで入力してからコードが自動的に先頭に追加されるようにすることもできます。 |
7 |
[保存] をクリックします。 |
次に行うこと
ロケーションを作成した後、そのロケーションの緊急 911 サービスを有効にすることができます。詳細については「Webex Calling の RedSky 緊急 911 サービス」を参照してください。
ロケーションを削除
開始する前に
関連付けられているユーザーとワークスペースを削除すると、使用されていない場所または正しく設定されていない場所を削除できます。ロケーションを削除すると、割り当てられたサービスと番号がすべて削除されます。
ロケーションに関連付けられているユーザーとワークスペースのリストを取得します。これらのユーザーとワークスペースを削除する必要があります。
に進み、ドロップダウン メニューから削除するロケーションを選択します。ロケーションを削除する前に、このロケーションに関連付けられている番号は、PSTN プロバイダーに解放されることに注意してください。これらの番号は所有されなくなります。
1 |
https://admin.webex.com で Control Hub にログインし、 に移動します。 |
2 |
削除するロケーションの隣の |
3 |
[場所 の削除] を選択し、その場所を削除します。 通常、ロケーションを完全に削除するには数分かかりますが、最大で 1 時間かかる場合があります。ステータスを確認するには、ロケーション名の隣にある |
既存のロケーションを更新する
作成した後PSTNのセットアップ、名前、タイムゾーン、言語を変更できます。新しい言語は新しいユーザーとデバイスにのみ適用されることに注意してください。既存のユーザーおよびデバイスは古い言語を使用し続けます。
既存のロケーションについては、緊急時の 911 サービスを有効にすることができます。詳細については「Webex Calling の RedSky 緊急 911 サービス」を参照してください。
1 | |
2 |
に移動します。 ロケーションの隣に [警告] 記号が表示される場合、そのロケーションの電話番号をまだ設定していないという意味です。その番号を設定するまで、通話の送受信が行えなんす。 |
3 |
(オプション) [PSTN 接続] の下で、すでに設定されているものに応じて、[クラウド接続 PSTN] または [プレミスベースの PSTN](ローカル ゲートウェイ) のいずれかを選択します。[管理] をクリックして設定を変更してから、[続行] を選択することにより、関連するリスクを承認します。以下のオプションのいずれかを選択して、[保存] クリックします。
移行するには、以下の 「Cisco Calling プランへの移行」 を参照してください。 |
4 |
ロケーションに対して、ドロップダウンリストから [代表番号] を選択します。 代表番号は、自動アテンダントまたはロケーション内のその他の宛先に割り当てることができ、外部発信者が適切な宛先にルーティングされます。 トランクまたは内線のみのエンティティがある場合、ロケーションに代表番号を割り当てる必要があります (ユーザー、ワークスペース、仮想回線、機能など)。代表番号がない場合、トランクは使用できず、内線番号のみのエンティティは内部コールまたは外線コールを発信または受信できません。そのロケーションのユーザーは、PSTN 通話を行うときに、この番号を外部発信者 ID として使用することもできます。 ロケーションの代表番号としてトールフリー番号を選択した場合は、トールフリー番号に緊急サービス アドレスがないため、そのロケーションの緊急コールバック番号を更新することをおすすめします。詳細については、「ロケーションの緊急コールバック番号を設定する」を参照してください。 |
5 |
(オプション) [緊急コール] で[緊急時のロケーション識別子] を選択して、このロケーションに割り当てることができます。 この設定はオプションで、必要な国にのみ適用されます。 一部の国 (例: フランス) の規制要件は、緊急電話を行い、緊急連絡時にセルの識別を確立するためのセルに関する規制要件であり、緊急権限によって利用可能になります。米国やカナダのような他の国では、他の方法を使用して位置決定を実施しています。詳細については、「緊急時通話の強化 」を参照してください。 緊急通話プロバイダーはアクセス ネットワークに関する情報が必要な場合があります。これは、新しいプライベート SIP 内線ヘッダー、P-Access-Network-Info を定義することによって達成されます。ヘッダーにはアクセスネットワークに関連する情報が含まれます。 場所に緊急ロケーション識別子を設定すると、場所の値は SIP メッセージの一部としてプロバイダーに送信されます。緊急通話プロバイダーに連絡して、この設定が必要で、緊急通話プロバイダーから提供された値を使用する必要がある場合はそれを確認してください。」 |
6 |
このロケーションでユーザーがボイスメールをチェックするために呼び出せる [ボイスメール番号] を選択します。 |
7 |
(オプション) ロケーション ページの上部にある鉛筆アイコンをクリックし、必要に応じて [ロケーションの名前]、[アナウンス言語]、[メール言語]、[タイムゾーン]、[住所] を変更し、[保存] をクリックします。 [アナウンス言語] の変更は、このロケーションに追加された新規ユーザーや機能に対して直ちに有効になります。既存のユーザーや機能のアナウンス言語も変更する必要がある場合は、プロンプトが表示されたら、[既存のユーザーとワークスペースの変更] または [既存機能の変更] を選択します。[適用] をクリックします。[タスク] ページで進捗状況を確認できます。これが完了するまでは、これ以上変更を加えることはできません。 ロケーションの [タイム ゾーン] を変更しても、このロケーションに関連する機能のタイム ゾーンは更新されません。自動アテンダント、ハント グループ、コール キューなどの機能のタイムゾーンを編集するには、タイムゾーンを更新する特定の機能の [全般設定] エリアに移動し、そこで編集して保存します。 |
Cisco Calling プランに移行
既存のロケーションの PSTN 接続を Cisco PSTN に変更できます。たとえば、プレミスベースの PSTN(ローカル ゲートウェイ)または非 Cisco PSTN への統合型 CCP 接続のロケーションを変更できます。Cisco PSTN は Cisco からのクラウド PSTN ソリューションを提供します。
ポートされるすべての番号は、予定されているポートの完了時間中にわずかな中断を除いて、引き続き機能します。
また、PSTN 接続の移行が行われているロケーションでは、番号管理の変更を行うことはできません。ただし、既存の番号は機能したままであり、ロケーションに番号を割り当てたり、割り当て解除したりできます。そのロケーションの番号の追加、削除、移動はできません。このプロセス中に、ルーティング プロファイルが自動的に更新され、Cisco PSTN が有効になります。
現在、既存のロケーションの PSTN 接続を Cisco PSTN に変更する機能は、日本地域ではサポートされていません。
PSTN 接続の変更中に、通話ライセンスを持つサブスクリプションが適用され、課金サービスに通知が送信されます。
制限:
-
統合型 IntelePeer ロケーションから Cisco PSTN ロケーションへの移行はサポートされていません
-
専用インスタンスのロケーションを Cisco PSTN に移行できません
-
PSTN 接続の変更には、複数のポート注文が必要になる場合があります。その場合、これらの注文はリンクされているため、同時に完了します。1 つのポート注文の日付変更またはキャンセルは、接続変更のためにリンクされたすべてのポート注文に適用する必要があります。
PSTN 接続の変更を開始する方法
1 | |
2 |
に移動します。 |
3 |
PSTN 接続を Cisco PSTN に変更するロケーションを選択します。 |
4 |
[Calling] タブに移動し、プレミスベースの PSTN または非統合型 PSTN の隣の [管理] オプションをクリックします。 |
5 |
[接続タイプ] の隣の [編集] を選択します。 |
6 |
Cisco Calling プラン カードを選択し、このロケーションのユーザーに Cisco Calling プランを割り当てるサブスクリプションを選択します。[次へ] をクリックします。 |
7 |
確認のための接続変更ページが表示されます。[次へ] をクリックして、番号のポート準備を確認します。 [次へ(Next)] ボタンは、リスト内のすべての番号がポート可能な場合にのみ有効になります。これらのポインタを読みます。
|
8 |
[次へ] をクリックし、契約情報を入力します。 これは、Cisco Calling プラン (米国) を使用するすべてのロケーションの主契約連絡先です。この連絡先への変更は、Cisco Calling プラン (米国) を使用する他のすべてのロケーションに適用されます。 |
9 |
[次へ] をクリックします。そのロケーションの契約情報を保存するための確認を求める通知が表示されます。[はい、変更します。] を選択します。 |
10 |
緊急連絡サービス アドレスを入力し、[保存] をクリックします。 緊急時、現地の緊急対応チームはこのアドレスを利用して発信元を見つけます。 |
11 |
概要ページには、作成されたポートの数が表示されます。注文が 1 つしかない場合、[追加情報を提供] と呼ばれる追加手順を確認できます。複数の注文の場合、上部に注文セレクタが表示され、その間を移動できます。[次へ] をクリックし、詳細を入力してポート ウィザードを完了します。 注文は、単一の PSTN 移行リクエストに対してすべての情報が提供されると同時に送信されます。デフォルトでは、すべての注文で確固たる注文コミットメントの日付が一致しています。最後にリンクされた注文が完全にポートされた後、PSTN 接続の変更が自動的に適用されます。
移行の詳細は、 タブで利用できます。注文 ID を選択すると、サイドパネルビューで注文の詳細が表示されます。PSTN 接続変更から作成された注文では、タイプを [PSTN の変更] として確認できます。 |
Webex Calling ダイヤル プランを設定
アウトバウンド ダイヤル コードダイヤル プラン使用してWebex Callingシステムの設定をコントロールできます。内線の長さ、ルーティング プレフィックス、およびダイヤル設定 (内部と外部) が、ユーザーのダイヤル習慣に適合するようにカスタマイズします。
これらの設定は社内ダイヤルに適用されるものであり、最初のセットアップ ウィザードでも設定できます。ダイヤル プランを変更すると、Control Hub の更新にあるサンプルの番号が更新され、これらの変更が表示されます。
ロケーションの発信通話権限を設定できます。発信権限を設定するには、これらの手順 を参照してください。
1 |
Control Hub にサインインし、 に移動し、[内線ダイヤル] までスクロールします。 |
2 |
必要に応じて、次のオプションのダイヤル設定を行います。
|
3 |
特定の場所の内部ダイヤルを指定します。[通話] をクリックします。[ダイヤル] までスクロールし、必要に応じて内部ダイヤルを変更します。 に移動し、リストからロケーションを選択し、
|
4 |
特定のロケーションの外線ダイヤルを指定します。[通話] をクリックします。[ダイヤル] までスクロールし、必要に応じて外部ダイヤルを変更します。 に移動し、リストからロケーションを選択し、
ユーザーへの影響:
|
Control Hub でプレミス ベースの PSTN (ローカル ゲートウェイ) を設定する
付加価値再販業者の場合、これらの手順を使用して Control Hub でローカル ゲートウェイの設定を開始できます。このゲートウェイがクラウドに登録されると、Webex Calling の 1 つ以上のロケーションで使用して、エンタープライズ PSTN サービス プロバイダーへのルーティングを提供できます。
ローカル ゲートウェイがある場所は、ローカル ゲートウェイが他の場所で使用されているときには削除できません。
トランクを作成する
始める前に
-
ロケーションが追加されたら、ロケーションに対してプレミスベース PSTN を設定する前に、トランクを作成する必要があります。
-
それぞれについて、ロケーションと固有の設定および番号を作成します。ロケーションはプレミスベース PSTN を追加する前に存在する必要があります。
-
Webex Calling でのプレミスベース PSTN (ローカル ゲートウェイ) 要件について理解しておいてください。
-
プレミスベース PSTN を持つロケーションに対して、複数のトランクを選択できませんが、複数のロケーションに対して同じトランクを選択することはできます。
1 |
https://admin.webex.com で Control Hub にログインし、 に移動し、[トランクの追加] を選択します。 |
2 |
ロケーションを選択します。 |
3 |
トランクの名前を指定し、[保存] をクリックします。 名前は 24 文字以内にしてください。 |
次にやる必要
画面 [ドメインの登録]、[トランク グループ OTG/DTG]、[回線/ポート]、および [発信プロキシ アドレス] にトランク情報が表示されます。
プレミスベース PSTN を設定する準備ができているときに参照できるように、この情報を Control Hub からコピーして、ローカルのテキスト ファイルまたは文書に貼り付けておくことを推奨します。
この資格情報を紛失した場合には、Control Hub のトランク情報画面で生成する必要があります。[ユーザー名の取得とパスワードのリセット] をクリックして、トランクを使用するための認証資格情報の新しいセットを生成します。
プレミス ベースの PSTN のトランクを選択する
1 |
https://admin.webex.com で Control Hub にログインし、 に移動します。 |
2 |
変更する場所を選択し、[管理] をクリックします。 |
3 |
プレミスベース PSTN を選択して、[次へ] をクリックします。 |
4 |
ドロップダウン メニューからトランクを選択します。 トランク ページにアクセスして、トランク グループの選択を管理します。 |
5 |
確認通知をクリックし、[保存] をクリックします。 |
次にやる必要
Control Hub が生成した構成情報を記録し、パラメーターをローカル ゲートウェイ (たとえばオンプレミスの Cisco CUBE) にマップする必要があります。この記事 では、このプロセスを説明します。参考のため、どのように Control Hub の構成情報 (左側) が CUBE のパラメーター (右側) にマップされるかを示す例である次の図を参照してください。
ゲートウェイ自体の設定が正常に完了すると、Control Hub の
に戻り、作成したゲートウェイが割り当てたロケーション カードに名前の左側に緑色のドットが表示されます。このステータスは、ゲートウェイがセキュアに通話クラウドに対して登録され、そのロケーションでのアクティブな PSTN としての役割を果たしていることを示しています。電話番号の管理
Control Hub では、組織の電話番号を簡単に表示、アクティベート、削除、追加できます。詳細については、「Control Hub で電話番号を管理する」を参照してください。
Control Hub でトライアルからの Webex サービス購入をリクエストする
Webex サービスを試していて、トライアルから有料サブスクリプションに変更したい場合は、メールでパートナーにリクエストできます。
1 |
https://admin.webex.com で Control Hub にログインし、建物のアイコン |
2 |
[サブスクリプション] タブを選択し、[今すぐ購入] をクリックします。 有料サブスクリプションへの変換に興味を持っていることを知らせるメールがパートナーに送信されます。 |
通話オプションを設定
Control Hub を使用して、Webex アプリでユーザーに表示する利用可能な通話オプションの優先度を設定できます。シングルクリック通話を有効にすることもできます。詳細については、次を参照してください。Webex アプリ ユーザーの通話オプションを設定する。
通話動作をセットアップ
ユーザーが発信するときに、どの通話アプリケーションが開くかを制御できます。Unified CM または Webex Calling で認証されたユーザー、および Cisco からの有料通話サービスを使用していないユーザーに対する混合モード展開など、コーリング クライアントの設定を構成できます。詳細については、次を参照してください。通話動作を設定する。
Webex Calling に Unified CM を構成する
ローカル ゲートウェイへトランクするための SIP トランク セキュリティ プロファイルを構成する
ローカル ゲートウェイと PSTN ゲートウェイが同じデバイス上に存在する場合、Unified CM を有効にして、同じデバイスから発信された 2 個の異なるトラフィックの種類 (Webex と PSTN のコール) を区別し、これらのコール タイプに対して差別化されたクラスのサービスを適用する必要があります。この差別化されたコール処理は、Unified CM および結合されたローカル ゲートウェイと PSTN ゲートウェイ デバイスの 2 つのトランクをプロビジョニングすることで行われます。これは、2 つのトランクに異なる SIP リスニング ポートを必要とします。
次の設定でローカル ゲートウェイ トランクの専用の SIP トランク セキュリティ プロファイルを作成します。
|
ローカル ゲートウェイ トランクの SIP プロファイルを構成する
次の設定でローカル ゲートウェイ トランク用の専用の SIP プロファイルを作成します。
|
Webex からのコールのコール検索スペースを作成する
次の設定で Webex から発信されたコールのためのコール検索スペースを作成します。
最後のパーティション onNetRemote は、Intercluster Lookup Service (ILS) または Global Dialplan Replication (GDPR) を使用して、Unified CM クラスター間でルーティング情報が交換されるマルチクラスター環境でのみ使用されます。 |
Webex 間で SIP トランクを構成する
次の設定を使用して、ローカル ゲートウェイ経由での Webex 間のコールに SIP トランクを作成します。
|
Webex のルート グループを構成する
次の設定でルート グループを作成します。
|
Webex のルート リストを構成する
次の設定でルート リストを作成します。
|
Webex の移動先のパーティションを作成する
次の設定で Webex の移動先のパーティションを作成します。
|
次にやる必要
このパーティションは、Webex の宛先にアクセスする必要があるすべてのコール検索スペースに追加してください。このパーティションは、PSTN から Webex への発信がルーティングされるように、PSTN トランクの着信コール検索スペースとして使用されるコール検索スペースに特に追加する必要があります。
Webex の移動先のルート パターンを構成する
次の設定で Webex の各 DID 範囲のルート パターンを構成します。
|
Webex の簡略サイト間ダイヤル正規化を構成する
短縮されたサイト間ダイヤルが Webex に必要な場合は、Webex の各 ESB 範囲にダイヤル正規化パターンを設定します。
|
Webex Calling の機能をセットアップ
ハント グループをセットアップする
ハント グループは着信をグループのユーザーまたはワークスペースにルーティングします。グループ全体にルーティングするパターンを構成することもできます。
ハント グループのセットアップ方法の詳細については、「Cisco Webex Control Hub のハント グループ」を参照してください。
コール キューを作成する
コール キューを作成すれば、顧客の発信にすぐに応答がない場合、誰かが応答できるようになるまで自動応答にしたり、お詫びのメッセージや保留中の音楽が流れるようにしたりすることができます。
コール キューをセットアップおよび管理する方法の詳細については、「Cisco Webex Control Hub でコール キューを管理する」を参照してください。
レセプショニスト クライアントを作成する
フロントオフィス担当者のニーズに応えますユーザーを電話アテンダントに設定することで、組織内の特定の人物への着信をスクリーニングできます。
レセプショニストクライアントのセットアップ方法と表示方法については、「Cisco Webex Control Hub のレセプショニストクライアント」を参照してください。
自動アテンダントを作成して管理する
セットアップ メニューと、応答サービス、ハント グループ、ボイスメール ボックスや実際のオペレーターなどへのルーティング機能によって、適切なあいさつを返すことができます。24 時間分のスケジュールを作成できます。あるいは、時間内か外かに応じて、異なるオプションを使うこともできます。
自動アテンダントの作成と管理の方法については、「Cisco Webex Control Hub で自動アテンダントを管理する」を参照してください。
ページング グループを構成する
グループ ページングは、特定のページング グループに割り当てられた番号または内線番号をダイヤルすることにより、最大 75 名のターゲット ユーザーに一方向通話を行うか、グループ ページングを行うことができるようにします。
ページング グループのセットアップ方法と編集方法の詳細については、「Cisco Webex Control Hub のページング グループを構成する」を参照してください。
コール ピックアップを設定する
ユーザーがそれぞれの通話に応答できるよう、コール ピックアップ グループを作成し、チームワークとコラボレーションを強化します。ユーザーをコールピックアップグループに追加しておけば、グループメンバーが席を離れていたり、電話中だったりした場合、別のメンバーが電話に出ることができます。
コールピックアップグループのセットアップ方法については 、「Cisco Webex Control Hub でのコールピックアップ」を参照してください。
コール パークをセットアップする
コール パークにより、ユーザーの定義されたグループは、コール パーク グループの他の利用可能なメンバーに対するコールをパークすることができます。パーク中のコールは、グループの他のメンバーが自分の電話で取ることができます。
コールパークのセットアップ方法の詳細については、「Cisco Webex Control Hub コールパーク」を参照してください。
ユーザーの割り込みを有効にする
1 |
https://admin.webex.com の顧客ビューから、 に移動します。 |
2 |
ユーザーを選択し、[Calling] をクリックします。 |
3 |
[ユーザー間権限] セクションに移動し、[割り込み] を選択します。 |
4 |
トグルをオンにすると、他のユーザーがこのユーザーの進行中のコールに自分自身を追加できるようになります。 |
5 |
このユーザーが通話に割り込みを行ったときに他の人にトーンを再生する場合は、[このユーザーが通話に割り込みを行ったときにトーンを再生する] をオンにします。 [このユーザーが通話に割り込みを行ったときにトーンを再生する] 設定は、Customer Experience Basic および Essentials スーパーバイザーの割り込み機能には適用されません。スーパーバイザに対してこのオプションを有効にした場合でも、スーパーバイザがコール キュー コールに割り込んだときに、システムはエージェントに通知トーンを再生しません。 スーパーバイザがコールに割り込んだときにエージェントにトーンを再生する場合は、[エージェントの通知トーン] 設定で有効にできます。詳細については、「Webex Customer Experience Basic 」または「Webex Customer Experience Essentials 」の「キューの作成」セクションを参照してください。 |
6 |
[保存] をクリックします。 |
ユーザーのプライバシーを有効化
1 |
Control Hub にサインインし、 に移動します。 |
2 |
ユーザーを選択し、[Calling] をクリックします。 |
3 |
[ユーザー間権限] エリアに移動し、[プライバシー] を選択します。 |
4 |
このユーザーに適切な [自動音声応答のプライバシー] 設定を選択します。
|
5 |
[プライバシーを有効にする] チェックボックスをオンにします。次に、ドロップダウンリストからメンバーを選択しないことで、全員をブロックできます。または、このユーザーの回線ステータスを監視できるユーザー、ワークスペース、仮想回線を選択できます。 ロケーション管理者の場合、割り当てられたロケーションに関連するユーザー、ワークスペース、仮想回線のみがドロップダウン リストに表示されます。 [プライバシーの有効化] チェックボックスをオフにして、全員が回線ステータスを監視できるようにします。 |
6 |
[ダイレクト コール ピックアップと割り込みのプライバシーを強制] チェックボックスをオンにして、ダイレクト コール ピックアップと割り込みのプライバシーを有効にします。
|
7 |
[名前でメンバーを追加] から、電話回線のステータスを監視し、ダイレクト コール ピックアップと割り込みを実行できるユーザー、ワークスペース、仮想回線を選択します。 |
8 |
選択したメンバーをフィルタリングするには、[名前、番号、または内線番号でフィルタ] フィールドを使用します。 |
9 |
[すべて削除] をクリックして、選択したすべてのメンバーを削除します。 個々のメンバーを削除するには、メンバーの名前の隣の [削除] をクリックします。 |
10 |
[保存] をクリックします。 |
モニタリングを設定
ユーザーの監視回線の最大数は 50 です。ただし、モニタリングリストを設定する際には、Webex Calling とネットワーク間の帯域幅に影響を与えるメッセージの数を考慮してください。また、ユーザの電話機の回線ボタンの数によって、監視される回線の最大数を決定します。
1 |
https://admin.webex.com の顧客ビューから [管理] に移動し、[ユーザー] をクリックします。 |
2 |
変更するユーザーを選択し、[Calling] をクリックします。 |
3 |
[ユーザー間権限] セクションに移動し、[監視] を選択します。 |
4 |
次から選択します:
ユーザー監視のために、仮想回線を [監視対象回線の追加] リストに含めることができます。 |
5 |
パークされた通話についてこのユーザーに通知するかどうかを選択し、監視するユーザーまたはコール パーク内線番号を検索して、[保存] をクリックします。 Control Hub の監視回線リストは、ユーザーのデバイス上で表示される監視回線の順番に対応します。監視対象回線のリストをいつでも並べ替えることができます。 監視対象回線に表示される名前は、ユーザー、ワークスペース、仮想回線の [発信者 ID 名(Caller ID First Name)] フィールドと [姓(Last Name)] フィールドに入力された名前です。 |
ユーザーのコール ブリッジ警告トーンを有効化
開始する前に
1 |
Control Hub にサインインし、 に移動します。 |
2 |
ユーザーを選択し、[通話] タブをクリックします。 |
3 |
[ユーザー間権限] に移動し、[コール ブリッジング警告音] をクリックします。 |
4 |
[コール ブリッジング警告音] をオンにして、[保存] をクリックします。 デフォルトでは、この機能は有効になっています。 MPP 共有回線のコール ブリッジングの詳細については、「マルチプラットフォーム 卓上電話の共有回線」を参照してください。 Webex アプリの共有回線でのコール ブリッジングの詳細については、「WebexApp の共有回線アピアランス」を参照してください。 |
ユーザーのためにホテリングをオンにする
1 |
https://admin.webex.com の顧客ビューから [管理] に移動し、[ユーザー] を選択します。 |
2 |
ユーザーを選択し、[通話] タブをクリックします。 |
3 |
[ユーザー間権限] セクションに進み、[ホテリング] を選択し、トグルをオンにします。 |
4 |
[ホテリング ロケーション] 検索フィールドにホテリング ホストの名前または番号を入力し、ユーザーに割り当てるホテリング ホストを選択します。 ホテリング ホストは 1 つのみ選択できます。別のホテリング ホストを選択した場合、最初のホストは削除されます。 ロケーション管理者の場合、割り当てられたロケーションに関連するホテリング ホストのみを割り当てることができます。 |
5 |
ユーザーがホテリング ホストに関連付けることができる時間を制限するには、[関連付け期間の制限] ドロップダウンから、ユーザーがホテリング ホストを使用できる時間数を選択します。 ユーザーは選択した時間後に自動的にログアウトされます。 ユーザに指定された制限関連付け期間が、選択したホテリング ホストの制限関連付け期間を超えた場合、画面にエラーメッセージが表示されます。たとえば、ホテリング ホストに制限時間が 12 時間あり、ユーザーの制限時間が 24 時間ある場合、エラーメッセージが表示されます。このような場合、ユーザにさらに時間が必要な場合は、ホテリング ホストの制限時間を延長する必要があります。 |
6 |
[保存] をクリックします。 ユーザーは、User Hub から使用するホテリング ホストを検索し、検索することもできます。詳細については、「どこからでも通話プロファイルにアクセスする」を参照してください。 |
Webex Calling の導入傾向と使用レポート
通話レポートを表示
Control Hub の [アナリティクス] ページを使用して、Webex Calling サービスの使用方法、Webex アプリでのエンゲージメント、通話メディア エクスペリエンスの品質を確認できます。Webex Calling 分析にアクセスするには:
1 | |
2 |
[分析] に移動し、[Calling] タブを選択します。 |
3 |
[詳細な通話履歴] を選択します。 通話履歴の詳細は、メディア品質データとともに表示されます。
|
4 |
メディア品質データにアクセスするには、Control Hub にサインインし、[アナリティクス] に移動し、[Calling] を選択します。 |