この記事の内容
dropdown icon
Webex Calling の概要
    dropdown icon
    コントロールハブのツアーに参加してください
      始めましょう
      初めてのトライアルの魔法使い
      設定を見直してください
      ユーザーを追加してください
      シングルサインオン（SSO）を設定する
      ユーザーにサービスを割り当てる
      ユーザーに力を与える
    ローカルゲートウェイの役割
    dropdown icon
    でサポートされるローカルゲートウェイのデプロイメント Webex Calling
      オンプレミスのIP PBXを使用しないローカルゲートウェイの展開
      Unified CMオンプレミスPBXによるローカルゲートウェイの展開
    コールルーティングに関する考慮事項
    サービスクラス（CoS）
    ダイヤルプランの統合
    dropdown icon
    通話用のプロトコルハンドラー
      Windows用のプロトコルハンドラー
      macOS用のプロトコルハンドラー
dropdown icon
環境を整えましょう
    一般的な前提条件
    ローカルゲートウェイのハードウェアとソフトウェアの要件
    ローカルゲートウェイのライセンス要件
    ローカルゲートウェイの証明書とセキュリティ要件
    ローカルゲートウェイのファイアウォール、NATトラバーサル、およびメディアパス最適化の要件
dropdown icon
Webex Calling のポート参照情報
    のプロキシサポート Webex Calling
    dropdown icon
    ファイアウォールの設定
      サービスのIPサブネット Webex Calling
      サービスの質 (QoS)
      Webex Meetings/メッセージング-ネットワーク要件
    文書の改訂履歴
dropdown icon
Cisco IOS XE for Webex Calling のローカルゲートウェイを設定してください
    概要
dropdown icon
CUBEの高可用性をローカルゲートウェイとして実装してください
    ファンダメンタルズ
    両方のキューブに冗長性を設定してください
    両方のCUBEにローカルゲートウェイを設定してください
dropdown icon
組織に合わせて Webex Calling を設定してください
    初回設定ウィザードで通話設定をセットアップします
    場所を追加してください
    場所を削除する
    dropdown icon
    既存の場所を更新してください
      シスコの通話プランに移行してください
      PSTN接続の変更を開始する方法
      PSTN接続の変更をキャンセルしてください
    Webex Callingダイヤルプランを設定します
    コントロールハブでオンプレミスベースのPSTN（ローカルゲートウェイ）を設定します
    トランクを作ってください
    構内ベースのPSTNのトランクを選択してください
    電話番号を管理します
    コントロールハブの試用版から Webex サービスの購入をリクエストしてください
    通話オプションを設定する
    通話動作を設定する
dropdown icon
Unified CM を Webex Calling に設定してください
    トランクからローカルゲートウェイへのSIPトランクのセキュリティプロファイルを設定してください
    ローカルゲートウェイトランクのSIPプロファイルを設定してください
    Webex からの通話用のコーリングサーチスペースを作成してください
    Webexとの間で送受信するSIPトランクを設定します
    Webex のルートグループを設定してください
    Webex のルートリストを設定してください
    Webex 送信先用のパーティションを作成してください
    Webex 宛先のルートパターンを設定してください
    Webexの短縮サイト間ダイヤリング正規化を設定してください
dropdown icon
Webex Calling 機能をセットアップしてください
    ハントグループを設定してください
    コールキューを作成してください
    受付係のクライアントを作成してください
    自動応答の作成と管理
    ページンググループを設定してください
    コールピックアップを設定する
    コールパークを設定する
    ユーザーの割り込みを有効にする
    ユーザーのプライバシーを有効にする
    監視を設定する
    ユーザーに対してコールブリッジの警告音を有効にする
    ユーザーのホテルサービスを有効にする
dropdown icon
Webex Calling の採用動向と使用状況レポート
    通話レポートを見る
2026年10月10日 | 20092 回表示 | 0 人がこの投稿記事が役に立ったと考えています
Webex Calling 設定ワークフロー
list-menuこの記事の内容
list-menuフィードバックがある場合

パートナー、管理者、ユーザーなど、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 を設定する

初回セットアップ ウィザードで通話設定をセットアップする

Webex Calling サービスを稼働させるための最初のステップは、初回セットアップ ウィザード (FTSW) を完了することです。 最初のロケーションの FTSW が完了した後では、追加のロケーションに対して完了する必要がありません。

1

受け取ったウェルカム メールのはじめにリンクをクリックします。


 

管理者のメール アドレスが、Control Hub へのサインインに自動的に使用されます。その際、管理者パスワードを作成するように求められます。 サインインすると、セットアップ ウィザードが自動的に開始します。

2

利用規約を見直して、承諾します。

3

プランを見直して、[はじめに] をクリックします。


 

アカウント マネージャは FTSW の最初の手順をアクティブにする責任があります。 [使い始める] を選択した時に、「通話をセットアップできません」という通知を受け取った場合は、アカウント マネージャーに連絡してください。

4

データ センターがマッピングする国を選択し、顧客の連絡先と顧客アドレス情報を入力します。

5

[次へ: デフォルトのロケーション

6

次のオプションから選択します:

  • パートナー管理者の場合は、[保存して閉じる] をクリックして、顧客管理者が Webex Calling のプロビジョニングを完了するようにします。
  • 必要なロケーションの情報を入力します。 ウィザードでロケーションを作成した後、後で他にロケーションを作成できます。

 

セットアップ ウィザードを完了した後で、作成したロケーションにメイン番号を追加していることを確認してください。

7

このロケーションに適用する次の選択を行います。

  • 通知言語 - 新しいユーザーと機能に関する音声通知とプロンプト用。
  • メール言語 - 新規ユーザー向けメールのコミュニケーション。
  • 国
  • タイムゾーン
8

[次へ] をクリックします。

9

利用可能な Cisco Webex SIP アドレスを入力し、[次へ] をクリックし、[完了] を選択します。

ロケーションを追加する

始める前に

新しいロケーションを作成するには、以下の情報を指定します。

  • ロケーションの住所

  • 希望する電話番号(オプション)

1

以下で Control Hub にログインします:https://admin.webex.com 、管理次のリンクをクリックしてください:ロケーションを選択します。


 
新しいロケーションは、初回セットアップウィザードを使用して選択した国に対応する地域データセンターでホストされます。
2

ロケーションを設定します。

  • ロケーション名 - ロケーションを識別するための一意の名前を入力します。
  • 国/地域 - ロケーションに関連付ける国を選択します。 たとえば、米国に 1 か所のロケーション (本社) を作成し、イギリスに別のロケーション (支社) を作成することができます。 選択した国に応じて、その後の住所のフィールドが決まります。 ここには、例として、米国の住所書式を使用したものがあります。
  • ロケーションの住所 - ロケーションの郵送先住所の主要部分を入力します。
  • 市区町村 - このロケーションが所在する市区町村を入力します。
  • 都道府県 - ドロップダウンから都道府県を選択します。
  • 郵便番号-ZIP または郵便番号を入力します。
  • 通知言語 - 新規ユーザーと機能に関する音声通知と音声プロンプトで使用する言語を選択します。
  • メール言語 - 新規ユーザーとのメール通信に使用する言語を選択します。
  • タイムゾーン - ロケーションのタイム ゾーンを選択します。
3

クリック保存を選択してはい/いいえをクリックし、今すぐまたは後でロケーションに番号を追加します。

4

[今すぐ追加] をクリックしたら、次のいずれかのオプションを選択してください。

  • Cisco PSTN - Cisco の Cloud PSTN ソリューションが必要な場合は、このオプションを選択します。 Cisco Calling プランは、緊急通話、国内および国際電話の着信および発信を提供する完全な PSTN 代替ソリューションであり、新しい PSTN 番号を注文したり、既存の番号を Cisco にポートしたりできます。


     

    Cisco PSTN オプションは、以下の条件でのみ表示されます。

    • コミットされた Cisco Calling プラン OCP (アウトバウンド通話プラン) を少なくとも 1 つ購入している。

    • Cisco Calling プランがサポートされている国にロケーションがある。

    • ロケーションが新規である。 他の PSTN 機能が割り当てられている既存のロケーションは、今回は Cisco Calling プランの対象外です。 サポート ケースを開いてご相談ください。

    • Cisco Calling プランがサポートされている地域のWebex Callingデータ センターでホストされています。

  • Cloud Connected PSTN - 多くの Cisco CCP パートナーの 1 つからクラウド PSTN ソリューションを探している場合、またはロケーションで Cisco Calling プランが利用できない場合は、このオプションを選択します。 CCP パートナーは、PSTN 代替ソリューション、グローバルな広域カバレッジ、広範でさまざまな機能、パッケージ、価格設定を提供しています。

     

    CCP パートナーと対応地域は、こちらにリストされています。 ロケーションの国がサポートされているパートナーにのみ表示されています。 パートナーは、ロゴで表示されるか、簡単な文字列と括弧で囲んだ地域名で表示されます (例 : (EU)、(US)、または (CA))。 ロゴが表示されているパートナーは、常に CCP の地域メディアを提供しています。 文字列で表示されているパートナーについては、CCP の地域メディアを確保するために、ロケーションの国に最も近い地域を選択してください。

    リストされているプロバイダーの下に [番号を今すぐ注文する] オプションがある場合は、そのオプションを選択して、統合された CCP のメリットを利用することをおすすめします。 統合された CCP の場合、電話番号の調達とプロビジョニングを Control Hub の 1 つのペインで行えます。 統合されていない CCP の場合、Control Hub の外で、CCP パートナーから電話番号を調達する必要があります。

  • プレミスベースのPSTN(ローカル ゲートウェイ)-現在の PSTN プロバイダーを保持する場合、またはクラウド サイトでクラウド サイト以外に接続する場合、このオプションを選択できます。

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](ローカル ゲートウェイ) のいずれかを選択します。 [管理] をクリックして設定を変更してから、[続行] を選択することにより、関連するリスクを承認します。 以下のオプションのいずれかを選択して、[保存] クリックします。

  • Cisco PSTN - Cisco の Cloud PSTN ソリューションが必要な場合は、このオプションを選択します。 Cisco Calling プランは、緊急通話、国内および国際電話の着信および発信を提供する完全な PSTN 代替ソリューションであり、新しい PSTN 番号を注文したり、既存の番号を Cisco にポートしたりできます。


     

    Cisco PSTN オプションは、以下の条件でのみ表示されます。

    • コミットされた Cisco Calling プラン OCP (アウトバウンド通話プラン) を少なくとも 1 つ購入している。

    • Cisco Calling プランがサポートされている国にロケーションがある。

    • ロケーションが新規である。 他の PSTN 機能が割り当てられている既存のロケーションは、今回は Cisco Calling プランの対象外です。 サポート ケースを開いてご相談ください。

    • Cisco Calling プランがサポートされている地域のWebex Callingデータ センターでホストされています。

  • Cloud Connected PSTN - 多くの Cisco CCP パートナーの 1 つからクラウド PSTN ソリューションを探している場合、またはロケーションで Cisco Calling プランが利用できない場合は、このオプションを選択します。 CCP パートナーは、PSTN 代替ソリューション、グローバルな広域カバレッジ、広範でさまざまな機能、パッケージ、価格設定を提供しています。

     

    CCP パートナーと対応地域は、こちらにリストされています。 ロケーションの国がサポートされているパートナーにのみ表示されています。 パートナーは、ロゴで表示されるか、簡単な文字列と括弧で囲んだ地域名で表示されます (例 : (EU)、(US)、または (CA))。 ロゴが表示されているパートナーは、常に CCP の地域メディアを提供しています。 文字列で表示されているパートナーについては、CCP の地域メディアを確保するために、ロケーションの国に最も近い地域を選択してください。

    リストされているプロバイダーの下に [番号を今すぐ注文する] オプションがある場合は、そのオプションを選択して、統合された CCP のメリットを利用することをおすすめします。 統合された CCP の場合、電話番号の調達とプロビジョニングを Control Hub の 1 つのペインで行えます。 統合されていない CCP の場合、Control Hub の外で、CCP パートナーから電話番号を調達する必要があります。

  • プレミスベースのPSTN(ローカル ゲートウェイ)-現在の PSTN プロバイダーを保持する場合、またはクラウド サイトでクラウド サイト以外に接続する場合、このオプションを選択できます。

     

    ローカル ゲートウェイに以前設定されたロケーションを持つ Webex Calling の顧客は、同様のトランクを持つプレミス ベースの PSTN に自動的に変更されます。

3

ロケーションの主な連絡先担当者に連絡する際の代表番号を入力します。

4

(オプション) [緊急コール] で[緊急時のロケーション識別子] を選択して、このロケーションに割り当てることができます。


 

この設定はオプションで、設定が必要な国でのみ適用されます。

一部の国（例： フランス）、セルラー無線システムには、緊急コールを発信する際にセルの ID を確立するための規制要件があり、緊急機関に公開されています。 米国やカナダなどの他の国は、他の方法を使用して場所の特定を実装しています。 詳細については、次のサイトを参照してください。強化された緊急コールを選択します。

緊急通報プロバイダーは、アクセス ネットワークに関する情報を必要とする場合があります。この情報は、新しいプライベート SIP 拡張ヘッダーである P-Access-Network-Info を定義することによって実現されます。 ヘッダーは、アクセス ネットワークに関連する情報を伝送します。

ロケーションの緊急ロケーションの識別子を設定すると、ロケーションの値が SIP メッセージの一部としてプロバイダーに送信されます。 緊急通話プロバイダーに連絡して、この設定が必要かどうか確認し、緊急通話プロバイダーから提供された値を使用してください。」

5

このロケーションでユーザーがボイスメールをチェックするために呼び出せる [ボイスメール番号] を選択します。

6

(オプション) ロケーション ページの上部にある鉛筆アイコンをクリックし、必要に応じて [ロケーションの名前]、[アナウンス言語]、[メール言語]、[タイムゾーン]、[住所] を変更し、[保存] をクリックします。


 

[アナウンス言語] の変更は、このロケーションに追加された新規ユーザーや機能に対して直ちに有効になります。 既存のユーザーや機能のアナウンス言語も変更する必要がある場合は、プロンプトが表示されたら、[既存のユーザーとワークスペースの変更] または [既存機能の変更] を選択します。 [適用] をクリックします。 [タスク] ページで進捗状況を確認できます。 これが完了するまでは、これ以上変更を加えることはできません。


 

ロケーションの [タイム ゾーン] を変更しても、このロケーションに関連する機能のタイム ゾーンは更新されません。 自動アテンダント、ハント グループ、コール キューなどの機能のタイム ゾーンを編集するには、タイムゾーンを更新する特定の機能の [全般設定] エリアに移動し、そこで編集して保存します。

これらの設定は社内ダイヤルに適用されるものであり、最初のセットアップ ウィザードでも設定できます。 ダイヤル プランを変更すると、Control Hub の更新のサンプル番号が表示され、これらの変更が表示されます。


 

ロケーションに対する発信通話の権限を設定できます。 これらのステップをご覧になり、発信権限を設定してください。

1

Control Hub にサインインし、サービス > 通話 > サービス設定を選択してから、［内部ダイヤル］までスクロールします。

2

必要に応じて、次のオプションのダイヤル設定を行います。

  • ロケーション ルーティング プレフィックスの長さ—複数のロケーションがある場合は、この設定を推奨します。 2 ～ 7 桁の長さを入力できます。 同じ内線番号を持つ複数のロケーションがある場合、ロケーション間でコールを行うときに、ユーザーはプレフィックスをダイヤルする必要があります。 たとえば、複数のストアがある場合、内線 1000 を使用すると、各ストアにルーティング プレフィックスを設定することができます。 1 つのストアのプレフィックスが 888 の場合、そのストアに到達するために 8881000 にダイヤルします。

     

    ルーティング プレフィックスの長さには、ステアリング桁が含まれます。 たとえば、ルーティング プレフィックスの長さを 4 に設定すると、3 桁のみを使用してサイトを指定できます。


     

    ルーティング プレフィックスをロケーションに割り当てる場合、そのロケーションに割り当てられた内線のすべての外観には、内線番号の前にルーティング プレフィックスが含まれます。 たとえば、888-1000（ルーティング プレフィックス-内線）です。

  • [ルーティング プレフィックスのステアリング番号（Steering Digit in Routing Prefix）]:すべてのルーティング プレフィックスの最初の桁として設定される番号を選択します。
  • [内線番号の長さ(Internal Extension Length)]:2 ～ 10 桁を入力でき、デフォルトは 2 です。

     

    内線の長さを長くすると、既存の内部内線への短縮ダイヤルが自動的に更新されることはありません。

  • ロケーション間の内線ダイヤルを許可—組織の要件に基づいてロケーション間の内線ダイヤルをカスタマイズできます。

    • 組織にすべてのロケーションで重複する内線がない場合は、トグルを有効にします。

      デフォルトでは、トグルが有効になっています。

    • 組織が別の場所に同じ内線を持っている場合は、トグルを無効にします。 トグルが無効になり、発信者が内線番号をダイヤルすると、通話は、発信者と同じロケーションで内線番号が一致するユーザーにルーティングされます。 発信者は、エンタープライズ重要番号（ロケーションルーティングプレフィックス + 内線）をダイヤルして、他のロケーションの内線番号に到達する必要があります。

3

特定の場所の内部ダイヤルを指定します。 に移動 ［管理］>［ロケーション］を選択し、リストからロケーションを選択して、［通話］をクリックします。 [ダイヤル] までスクロールし、必要に応じて内部ダイヤルを変更します。

  • 内部ダイヤル - 別の場所にいるユーザーがこの場所にいる人に連絡するためにダイヤルする必要があるルーティング プレフィックスを指定します。 各ロケーションのルーティング プレフィックスは固有である必要があります。 プレフィックスの長さは組織レベルで設定された長さに一致することを推奨しますが、長さは 2 ～ 7 桁でなければなりません。
4

特定のロケーションの外部ダイヤルを指定します。 に移動 ［管理］>［ロケーション］を選択し、リストからロケーションを選択して、［通話］をクリックします。 [ダイヤル] までスクロールし、必要に応じて外部ダイヤルを変更します。

  • 外部ダイヤル—外線にダイヤルするためにダイヤルする必要がある外線番号の番号を選択することができます。 デフォルトは [なし] であり、このダイヤル習慣が必要ない場合には、値を [なし] にしておくことができます。 この機能を使用しない場合、組織のステアリング番号とは別の番号を使用することをお勧めします。

     

    ユーザーは、外線発信を行う際に外線発信番号を含め、レガシー システムでダイヤルしていた方法を真似たものにできます。 ただし、すべてのユーザーは引き続き、発信ダイアル番号がなくても外線通話を発信することができます。

  • 必要に応じて、このロケーションの発信ダイヤル番号のダイヤルを強制する機能を使用して、管理者が設定した発信ダイヤル番号を使用して外部コールを発信する必要があります。

     

    この機能が有効になっている場合でも、緊急コールは発信ダイヤル番号の有無にかかわらずダイヤルできます。

    有効にすると、発信ダイヤル番号が含まれていない場合、コール転送に使用されるような外部接続先番号は機能しなくなります。


     
    内線が国番号と同じ場合、内線が国番号よりも優先されます。 したがって、発信ダイヤル番号を有効にすることをお勧めします。

     
    着信および発信 PSTN コールに E.164 番号形式を使用することを強くお勧めします。

ユーザーへの影響:

  • ダイヤル基本設定の変更を有効にするには、ユーザーは電話を再起動する必要があります。

  • ユーザーの内線番号はロケーションのステアリング番号または発信ダイヤル番号と同じ番号で始まるべきではありません。

Control Hub でプレミス ベースの PSTN (ローカル ゲートウェイ) を設定する

付加価値再販業者の場合、これらの手順を使用して Control Hub でローカル ゲートウェイの設定を開始できます。 このゲートウェイがクラウドに登録されると、Webex Calling の 1 つ以上のロケーションで使用して、エンタープライズ PSTN サービス プロバイダーへのルーティングを提供できます。


 

ローカル ゲートウェイがある場所は、ローカル ゲートウェイが他の場所で使用されているときには削除できません。

トランクを作成する

次の手順に従って、Control Hub でトランクを作成します。

始める前に

  • ロケーションが追加されたら、ロケーションに対してプレミスベース PSTN を設定する前に、トランクを作成する必要があります。

  • それぞれについて、ロケーションと固有の設定および番号を作成します。 ロケーションはプレミスベース PSTN を追加する前に存在する必要があります。

  • Webex Calling でのプレミスベース PSTN (ローカル ゲートウェイ) 要件について理解しておいてください。

  • プレミスベース PSTN を持つロケーションに対して、複数のトランクを選択できませんが、複数のロケーションに対して同じトランクを選択することはできます。

1

ログインするコントロールハブで、サービス次のリンクをクリックしてください:電話次のリンクをクリックしてください:コール ルーティングを選択し、トランクの追加を選択します。https://admin.webex.com

2

ロケーションを選択します。

3

トランクの名前を指定し、[保存] をクリックします。


 

名前は 24 文字以内にしてください。

次に行うこと

トランクで設定する必要がある、関連するパラメーターが表示されます。 また、PSTN 接続をセキュアにするための SIP ダイジェスト資格情報のセットも生成します。

画面 [ドメインの登録]、[トランク グループ OTG/DTG]、[回線/ポート]、および [発信プロキシ アドレス] にトランク情報が表示されます。

プレミス ベースの PSTN を設定する準備ができたときに参照できるように、この情報を Control Hub からコピーして、ローカルのテキスト ファイルまたはドキュメントに貼り付けておくことをおすすめします。

資格情報を紛失した場合には、Control Hub のトランク情報画面で生成する必要があります。 [ユーザー名の取得とパスワードのリセット] をクリックして、トランクを使用するための認証資格情報の新しいセットを生成します。

プレミス ベースの PSTN のトランクを選択する

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 で電話番号を管理する」を参照してください。

Control Hub でトライアルからの Webex サービス購入をリクエストする

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に対する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 の 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 メッセージの処理を提供し、必要なターゲットにルーティングします。

Call routing from/to PSTN to/from Webex Calling configuration solution

オンプレミスの 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 インターフェイスに割り当てます。


interface GigabitEthernet0/0/0
  description Interface facing PSTN and/or CUCM
  ip address 10.80.13.12 255.255.255.0
!
interface GigabitEthernet0/0/1
  description Interface facing Webex Calling (Private address)
  ip address 192.51.100.1 255.255.255.240
2

対称暗号化を使用して、ルータ上の登録と STUN クレデンシャルを保護します。 プライマリ暗号化キーと暗号化タイプを次のように設定します。


key config-key password-encrypt YourPassword
password encryption aes
3

プレースホルダー PKI トラストポイントを作成します。


 
後で TLS を設定するには、このトラストポイントが必要です。 登録ベースのトランクの場合、このトラストポイントには証明書は必要ありません。証明書ベースのトランクに必要です。

crypto pki trustpoint EmptyTP 
 revocation-check none
4

TLS1.2 排他を有効にし、次の設定コマンドを使用してデフォルトのトラストポイントを指定します。 登録のための信頼性の高い安全な接続を確保するために、トランスポートパラメータも更新する必要があります。


 
cn-san-validate server コマンドは、テナント 200 で設定されたホスト名がアウトバウンド プロキシから受信した証明書の CN または SAN フィールドに含まれている場合に、ローカル ゲートウェイが接続を許可することを保証します。

  1. を設定 tcp再試行カウント～1000(5msecの倍数=5秒)

  2. タイマー接続の確立コマンドを使用すると、次の利用可能なオプションを検討する前に、LGWがプロキシとの接続を設定するのを待つ時間を調整できます。 このタイマーのデフォルトは 20 秒で、最低 5 秒です。 低値で開始し、ネットワーク条件に対応するために必要な場合は増加します。


sip-ua
 timers connection establish tls 5
 transport tcp tls v1.2
 crypto signaling default trustpoint EmptyTP cn-san-validate server
 tcp-retry 1000
5

Webex Calling で使用される DigiCert CA 証明書を含む Cisco ルート CA バンドルをインストールします。 を使用する crypto pki trustpool インポート クリーン URLコマンドは、指定されたURLからルートCAバンドルをダウンロードし、現在のCAトラストプールをクリアしてから、証明書の新しいバンドルをインストールします。


 

HTTPS を使用してインターネットにアクセスするためにプロキシを使用する必要がある場合は、CA バンドルをインポートする前に、次の設定を追加します。

ip httpクライアントプロキシサーバーyourproxy.comプロキシポート80 

ip http client source-interface GigabitEthernet0/0/1 
crypto pki trustpool import clean url https://www.cisco.com/security/pki/trs/ios_core.p7b

Webex Calling 登録ベースのトランクの設定

1

Control Hub の既存のロケーションに登録ベースの PSTN トランクを作成します。 トランクが作成されると、提供されたトランク情報をメモします。 次の図で強調表示されているこれらの詳細は、このガイドの設定手順で使用されます。 詳細については、次のサイトを参照してください。 Webex Calling用にトランク、ルートグループ、ダイヤルプランを構成するを選択します。

2

次のコマンドを入力して、CUBE を Webex Calling ローカル ゲートウェイとして設定します。

 
voice service voip
 ip address trusted list
  ipv4 x.x.x.x y.y.y.y
 mode border-element
 media statistics
 media bulk-stats 
 allow-connections sip to sip
 no supplementary-service sip refer  
 stun
  stun flowdata agent-id 1 boot-count 4
  stun flowdata shared-secret 0 Password123$
 sip
  asymmetric payload full
  early-offer forced

構成のフィールドの説明はここにあります。


ip address trusted list
 ipv4 x.x.x.x y.y.y.y

  • トール詐欺から保護するために、信頼されたアドレス リストは、ローカル ゲートウェイが正当な VoIP コールを期待するホストとネットワークのリストを定義します。

  • デフォルトでは、ローカル ゲートウェイは、信頼されたリストに含まれていない IP アドレスからのすべての着信 VoIP メッセージをブロックします。 「セッション ターゲット IP」またはサーバ グループ IP アドレスを持つ静的に設定されたダイヤル ピアはデフォルトで信頼されるため、信頼されたリストに追加する必要はありません。

  • ローカル ゲートウェイを設定するときは、地域の Webex Calling データ センターの IP サブネットをリストに追加します。 詳細については、「Webex Calling のポート参照情報」を参照してください。 また、Unified Communications Manager サーバ（使用されている場合）および PSTN トランク ゲートウェイのアドレス範囲を追加します。


     

    LGW が制限されたコーン NAT を備えたファイアウォールの背後にある場合、 Webex Callingに面しているインターフェイスのIPアドレスの信頼済みリストを無効にすることをお勧めします。 ファイアウォールは、未承諾の着信VoIPからすでに保護しています。 無効化することで、長期的な設定のオーバーヘッドが削減されます。次の理由から、 Webex Callingピアは固定されたままになり、いずれの場合でもピアに対してファイアウォールを構成する必要があります。

モード ボーダー要素

プラットフォームで Cisco Unified Border Element（CUBE）機能を有効にします。

メディア統計

ローカル ゲートウェイでメディア監視を有効にします。

メディア一括統計

一括コール統計のためにコントロール プレーンがデータ プレーンを投票できるようにします。

これらのコマンドの詳細については、「メディア」を参照してください。

allow-connections sip to sip

CUBE 基本 SIP バックツーバック ユーザ エージェント機能を有効にします。 詳細については、次のサイトを参照してください。接続を許可を選択します。


 

デフォルトでは、T.38 ファックス転送が有効になっています。 詳細については、ファックスプロトコルt38 (音声サービス)を参照してください。

スタイン

STUN (NAT を介した UDP のセッショントラバーサル) をグローバルに有効にします。

  • コールをWebex Callingユーザ（たとえば、着信側と発信側の両方がWebex Callingメディアをアンカーする場合はWebex Calling SBC)、ピンホールが開いていないため、メディアはローカル ゲートウェイにフローしません。

  • ローカル ゲートウェイの STUN バインディング機能により、ネゴシエートされたメディア パス上でローカルに生成された STUN 要求を送信できます。 これは、ファイアウォールのピンホールを開くのに役立ちます。

詳細については、次のサイトを参照してください。スタンフローデータエージェント-idおよびスタンフローデータ共有シークレットを選択します。

非対称ペイロード フル

DTMF と動的コーデック ペイロードの両方に対して SIP 非対称ペイロード サポートを設定します。 このコマンドの詳細については、次を参照してください非対称ペイロードを選択します。

early-offer forced

ローカル ゲートウェイは、隣接するピアからの確認を待つ代わりに、最初の INVITE メッセージで SDP 情報を送信するように強制します。 このコマンドの詳細については、次を参照してください早期オファーを選択します。

3

を設定する 音声クラス コーデック 100 トランクのフィルタ。 この例では、すべてのトランクに同じコーデックフィルタが使用されます。 正確な制御のために各トランクにフィルタを設定できます。


voice class codec 100
 codec preference 1 opus
 codec preference 2 g711ulaw
 codec preference 3 g711alaw

構成のフィールドの説明はここにあります。

音声クラス コーデック 100

SIP トランクを介したコールの優先コーデックのみを許可するために使用されます。 詳細については、音声クラスコーデック を参照してください。


 

Opus コーデックは、SIP ベースの PSTN トランクでのみサポートされています。 PSTN トランクが音声 T1/E1 またはアナログ FXO 接続を使用している場合は、コーデックの設定 1 オプスから音声クラスコーデック 100の設定。

4

を設定する 音声クラスの使い方 100 は、Webex Calling トランクで ICE を有効にします。


voice class stun-usage 100 
 stun usage firewall-traversal flowdata
 stun usage ice lite

構成のフィールドの説明はここにあります。

stunusageiceliteについて

すべての Webex Calling のダイヤルピアに対して ICE-Lite を有効にして、可能な限り、メディア最適化を可能にするために使用。 詳細については、次のサイトを参照してください。音声クラススタンの使用およびスタン使用アイスライトを選択します。


 

メディア パスの最適化を使用したコール フローには、ICE-lite のスタン使用が必要です。 SIP から TDM ゲートウェイへのメディア最適化を提供するには、IP-IP レッグで ICE-Lite が有効になっているループバック ダイヤル ピアを設定します。 技術的な詳細は、アカウントまたはTACチームにお問い合わせください。

5

Webex トラフィックのメディア暗号化ポリシーを設定します。


voice class srtp-crypto 100
 crypto 1 AES_CM_128_HMAC_SHA1_80

構成のフィールドの説明はここにあります。

音声クラス srtp-crypto 100

SDP の SRTP 暗号スイート CUBE オファーおよび応答メッセージの唯一の SRTP オファーとして SHA1_80 を指定します。 Webex Calling は SHA180 のみをサポートします。_ 詳細については、次のサイトを参照してください。音声クラス SRTP 暗号化を選択します。

6

宛先トランク パラメータに基づいて、ローカル ゲートウェイ トランクへのコールを一意に識別するパターンを設定します。


voice class uri 100 sip
 pattern dtg=Dallas1463285401_LGU

構成のフィールドの説明はここにあります。

音声クラス uri 100 sip

着信トランク ダイヤル ピアへの着信 SIP 招待と一致するパターンを定義します。 このパターンを入力する場合、トランクが作成されたときに、dtg= の後に Control Hub で提供されるトランク OTG/DTG 値を使用します。 詳細については、音声クラス uri を参照してください。

7

を設定する sip プロファイル 100は、Webex Callingに送信される前にSIPメッセージを変更するために使用されます。


voice class sip-profiles 100
 rule 10 request ANY sip-header SIP-Req-URI modify "sips:" "sip:"
 rule 20 request ANY sip-header To modify "<sips:" "<sip:"
 rule 30 request ANY sip-header From modify "<sips:" "<sip:"
 rule 40 request ANY sip-header Contact modify "<sips:(.*)>" "<sip:\1;transport=tls>" 
 rule 50 response ANY sip-header To modify "<sips:" "<sip:"
 rule 60 response ANY sip-header From modify "<sips:" "<sip:"
 rule 70 response ANY sip-header Contact modify "<sips:" "<sip:"
 rule 80 request ANY sip-header From modify ">" ";otg=dallas1463285401_lgu>"
 rule 90 request ANY sip-header P-Asserted-Identity modify "sips:" "sip:"

構成のフィールドの説明はここにあります。

  • ルール10～70、90

    コール シグナリングに使用される SIP ヘッダーが、Webex プロキシによって要求される sips スキームではなく sip を使用することを確認します。 sips を使用するように CUBE を設定すると、セキュアな登録が使用されます。

  • ルール80

    From ヘッダーを変更して、トランク グループの OTG/DTG 識別子を Control Hub から含め、企業内のローカル ゲートウェイ サイトを一意に識別します。

8

Webex Calling トランクの設定:

  1. を作成 音声クラス テナント 100は、Webex Callingトランクに必要な設定を定義し、グループ化します。 特に、以前の Control Hub で提供されるトランク登録の詳細は、以下の手順で使用されます。 このテナントに関連付けられているダイヤルピアは、後でこれらの設定を継承します。


     

    次の例では、このガイドの目的のために、ステップ 1 に示されている値を使用します (太字で表示)。 これらを構成のトランクの値に置き換えます。

    
voice class tenant 100
  registrar dns:98027369.us10.bcld.webex.com scheme sips expires 240 refresh-ratio 50 tcp tls
  credentials number Dallas1171197921_LGU username Dallas1463285401_LGU password 0 9Wt[M6ifY+ realm BroadWorks
  authentication username Dallas1463285401_LGU password 0 9Wt[M6ifY+ realm BroadWorks
  authentication username Dallas1463285401_LGU password 0 9Wt[M6ifY+ realm 98027369.us10.bcld.webex.com
  no remote-party-id
  sip-server dns:98027369.us10.bcld.webex.com
  connection-reuse
  srtp-crypto 100
  session transport tcp tls 
  url sips 
  error-passthru
  asserted-id pai 
  bind control source-interface GigabitEthernet0/0/1
  bind media source-interface GigabitEthernet0/0/1
  no pass-thru content custom-sdp 
  sip-profiles 100 
  outbound-proxy dns:dfw04.sipconnect-us.bcld.webex.com  
  privacy-policy passthru

    構成のフィールドの説明はここにあります。

    音声クラス テナント 100

    Webex Calling トランクにのみ使用される一連の設定パラメータを定義します。 詳細については、次のサイトを参照してください。音声クラス テナントを選択します。

    レジストラdns:98027369.us10.bcld.webex.com スキームsips expires 240 更新比 50 tcp tls

    2 分 (240 秒の50%) ごとに更新するように登録が設定されたローカル ゲートウェイのレジストラ サーバー。 詳細については、次のサイトを参照してください。登録事業者を選択します。

    ここで Control Hub から [ドメインの登録] 値を使用していることを確認します。

    クレデンシャル番号 Dallas1171197921_LGU ユーザー名 Dallas1463285401_LGUパスワード 0 9Wt[M6ifY+realm BroadWorks

    トランク登録チャレンジの資格情報。 詳細については、次のサイトを参照してください。クレデンシャル (SIP UA)を選択します。

    ここで、Control Hub からそれぞれ回線/ポートホスト、認証ユーザ名、認証パスワードの値を使用していることを確認します。

    認証ユーザ名 Dallas1171197921_LGU パスワード 0 9Wt[M6ifY+ realm BroadWorks
    認証ユーザ名 Dallas1171197921_LGUパスワード 0 9Wt[M6ifY+ realm 98027369.us10.bcld.webex.com

    コールの認証の課題。 詳細については、次のサイトを参照してください。認証（ダイヤルピア）を選択します。

    ここで、Control Hub からそれぞれ認証ユーザ名、認証パスワード、およびレジストラドメインの値を使用していることを確認してください。

    no remote-party-id

    ID Webex Callingは PAI をサポートしているため、CIOアサート ID paiを選択します。 詳細については、次のサイトを参照してください。リモートパーティ IDを選択します。

    sip-server dns:us25.sipconnect.bcld.webex.com

    トランクのターゲット SIP サーバを設定します。 トランクを作成するときは、Control Hub で提供されるエッジ プロキシ SRV アドレスを使用します。

    connection-reuse

    登録およびコール処理に対して同じ持続的な接続を使用する。 詳細については、次のサイトを参照してください。接続の再使用を選択します。

    srtp クリプト 100

    SRTP コール レッグ（接続）の優先暗号スイートを設定します（ステップ 5 で指定）。 詳細については、次のサイトを参照してください。音声クラス srtp-crypto。

    session transport tcp tls

    トランスポートをTLSに設定します。 詳細については、次のサイトを参照してください。セッション-トランスポートを選択します。

    url sips

    SRV クエリは、アクセス SBC でサポートされているように SIP である必要があります。他のすべてのメッセージは、sip-profile 200 によって SIP に変更されます。

    error-passthru

    SIP エラー応答パススルー機能を指定します。 詳細については、次のサイトを参照してください。エラーpassthruを選択します。

    asserted-id pai

    ローカル ゲートウェイで PAI 処理をオンにします。 詳細については、次のサイトを参照してください。アサート IDを選択します。

    バインド制御ソースインターフェイス GigabitEthernet0/0/1

    WebexCalling に送信されるメッセージのソース インターフェイスと関連する IP アドレスを設定します。 詳細は、bindを参照してください。

    バインド メディア ソース インターフェイス GigabitEthernet0/0/1

    WebexCalling に送信されるメディアのソース インターフェイスおよび関連する IP アドレスを設定します。 詳細は、bindを参照してください。

    no pass-thru content custom-sdp

    テナントの下のデフォルト コマンド。 このコマンドの詳細については、次を参照してくださいパススルー コンテンツを選択します。

    sipプロファイル 100

    SIP を SIP に変更し、次で定義されているように、INVITE および REGISTER メッセージの回線/ポートを修正します： SIP プロファイル200を選択します。 詳細については、次のサイトを参照してください。音声クラス sip-プロファイルを選択します。

    アウトバウンドプロキシ dns:dfw04.sipconnect-us.bcld.webex.com

    Webex Calling SBC にアクセスします。 トランクを作成したときに、Control Hub で提供されるアウトバウンド プロキシ アドレスを挿入します。 詳細については、次のサイトを参照してください。アウトバウンド-プロキシを選択します。

    privacy-policy passthru

    トランクのプライバシー ヘッダー ポリシー オプションを設定して、受信したメッセージから次のコール レッグにプライバシーの値を渡します。 詳細については、次のサイトを参照してください。プライバシーポリシーを選択します。

  2. Webex Calling トランク ダイヤル ピアを設定します。

    
dial-peer voice 100 voip
 description Inbound/Outbound Webex Calling
 max-conn 250
 destination-pattern BAD.BAD
 session protocol sipv2
 session target sip-server
 incoming uri request 100
 voice-class codec 100
 dtmf-relay rtp-nte
 voice-class stun-usage 100
 no voice-class sip localhost
 voice-class sip tenant 100
 srtp
 no vad

    構成のフィールドの説明はここにあります。

    
dial-peer voice 100 voip
  description Inbound/Outbound Webex Calling

    次のタグでVoIPダイヤルピアを定義します100管理とトラブルシューティングを容易にするために意味のある説明を付けます。

    マックスコン 250

    LGW と Webex Calling の間の同時着信コールと発信コールの数を制限します。 登録トランクの場合、設定されている最大値は 250 である必要があります。 Usea は、展開に適している場合は値を下げます。 ローカル ゲートウェイの同時通話制限の詳細については、「ローカル ゲートウェイを使い始める」のドキュメントを参照してください。

    destination-pattern BAD.BAD

    着信ダイヤル ピア グループを使用して発信コールをルーティングする場合は、ダミー接続先パターンが必要です。 この場合、有効な宛先パターンを使用できます。

    session protocol sipv2

    ダイヤルピアが100 SIP コール レッグを処理します。 詳細については、セッションプロトコル（ダイヤルピア）を参照してください。

    session target sip-server

    テナント 100 で定義された SIP サーバが継承され、このダイヤル ピアからのコールの宛先に使用されることを示します。

    着信 uri リクエスト 100

    VoIP ダイヤル ピアと着信コールのユニフォーム リソース 識別子（URI）を一致させるために使用される音声クラスを指定します。 詳細については、着信 uri を参照してください。

    音声クラス コーデック 100

    共通のコーデック フィルタ リスト 100 を使用するようにダイヤル ピアを設定します。 詳細については、次のサイトを参照してください。音声クラス コーデックを選択します。

    音声クラスのstun使用 100

    ローカル ゲートウェイでローカルに生成された STUN 要求を、ネゴシエートされたメディア パス経由で送信できるようにします。 STUN は、メディア トラフィックのファイアウォールのピンホールを開くのに役立ちます。

    no voice-class sip localhost

    発信メッセージの From、Call- ID、および Remote-Party- IDヘッダーで、物理IPアドレスの代わりにDNSローカル主催者名の置換を無効にします。

    音声クラス SIP テナント 100

    ダイヤル ピアは、グローバルおよびテナント 100 で設定されたすべてのパラメータを継承します。 パラメータはダイヤル ピア レベルで上書きされる場合があります。

    srtp

    コール レッグのSRTPを有効にします。

    no vad

    音声アクティブティの検出を無効にします。

テナント を定義した後 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を受信すると、登録が成功します。

SIP PSTN トランクを使用したローカル ゲートウェイの設定

上記の Webex Calling に対してトランクを構築した後、次の設定を使用して、SIP ベースの PSTN プロバイダーに対して暗号化されていないトランクを作成します。


 

サービス プロバイダーがセキュアな PSTN トランクを提供している場合、上記の Webex Calling トランクと同様の構成に従うことができます。 セキュアからセキュアなコール ルーティングは CUBE でサポートされています。


 

Cisco TDM-SIP ゲートウェイで PSTN コール レッグの TDM インターフェイスを設定するには、「ISDN PRI の設定」を参照してください。

1

PSTN トランクからの着信コールを識別するには、次の音声クラス uri を設定します。


voice class uri 200 sip
  host ipv4:192.168.80.13

構成のフィールドの説明はここにあります。

音声クラス uri 200 sip

着信トランク ダイヤル ピアへの着信 SIP 招待と一致するパターンを定義します。 このパターンを入力するときは、IP PSTN ゲートウェイの IP アドレスを使用します。 詳細については、音声クラス uri を参照してください。

2

次の IP PSTN ダイヤル ピアを設定します。


dial-peer voice 200 voip
 description Inbound/Outbound IP PSTN trunk
 destination-pattern BAD.BAD
 session protocol sipv2
 session target ipv4:192.168.80.13
 incoming uri via 200
 voice-class sip bind control source-interface GigabitEthernet0/0/0 
 voice-class sip bind media source-interface  GigabitEthernet0/0/0 
 voice-class codec 100
 dtmf-relay rtp-nte 
 no vad

構成のフィールドの説明はここにあります。


dial-peer voice 200 voip
 description Inbound/Outbound IP PSTN trunk

次のタグで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 経由で 着信 uri

VIA ヘッダーとIP PSTN のIPアドレスの一致基準を定義します。 ローカル ゲートウェイのすべての着信 IP PSTN コール レッグとダイヤル ピア 200 を一致させます。 詳細については、着信 URLを参照してください。

バインド制御ソースインタフェース GigabitEthernet0/0/0

PSTN に送信されるメッセージのソース インターフェイスと関連する IP アドレスを設定します。 詳細は、bindを参照してください。

バインド メディア ソース インターフェイス GigabitEthernet0/0/0

PSTN に送信されるメディアのソース インターフェイスおよび関連する 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 プラットフォームを使用してローカル ゲートウェイを設定する場合は、次のセクションに進みます。

  1. ダイヤルピア グループを作成して、Webex Calling または PSTN にコールをルーティングします。 Webex Calling に向けて発信ダイヤルピア 100 で DPG 100 を定義します。 DPG 100 は、PSTN からの着信ダイヤルピアに適用されます。 同様に、PSTN に向かって発信ダイヤルピア 200 で DPG 200 を定義します。 DPG 200 は、Webex からの着信ダイヤルピアに適用されます。

    
voice class dpg 100 
 description Route calls to Webex Calling 
 dial-peer 100 
voice class dpg 200 
 description Route calls to PSTN 
 dial-peer 200

    構成のフィールドの説明はここにあります。

    ダイヤルピア 100

    発信ダイヤルピアとダイヤルピア グループを関連付けます。 詳細は、音声クラス dpgを参照してください。

  2. ダイヤルピア グループを適用して、Webex から PSTN に、および PSTN から Webex にコールをルーティングします。

    
dial-peer voice 100
 destination dpg 200
dial-peer voice 200
 destination dpg 100

    構成のフィールドの説明はここにあります。

    destination dpg 200

    どのダイヤル ピア グループを指定します。したがって、この着信ダイヤル ピアに提示されたコールの発信処理にダイヤル ピアを使用する必要があります。

    これでローカル ゲートウェイの設定は終了します。 CUBE 機能が初めて設定される場合は、設定を保存し、プラットフォームをリロードします。

既存のUnified CM環境でローカル ゲートウェイを構成する

前のセクションの 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 を設定:

  1. SIP VIA ポートを使用して Unified CM を Webex コールに分類します。

    
voice class uri 300 sip
 pattern :5065

  2. ポート経由の SIP を使用して、Unified CM を PSTN コールに分類します。

    
voice class uri 400 sip
 pattern :192\.168\.80\.6[0-5]:5060

    発信元のソース アドレスとポート番号を説明する 1 つ以上のパターンを使用して、UCM からの着信メッセージを PSTN トランクに分類します。 必要に応じて、正規表現を使用して、一致するパターンを定義できます。

    上記の例では、192.168.80.60 から 65 までの範囲およびポート番号 5060 の任意の IP アドレスに一致させるために正規表現が使用されます。

2

次の DNS レコードを設定して、Unified CM ホストへの SRV ルーティングを指定します。


 

IOS XE は、これらのレコードをローカルでターゲット UCM ホストとポートを決定するために使用します。 この設定では、DNS システムでレコードを設定する必要はありません。 DNS を使用する場合は、これらのローカル設定は必要ありません。


ip host ucmpub.mydomain.com 192.168.80.60
ip host ucmsub1.mydomain.com 192.168.80.61
ip host ucmsub2.mydomain.com 192.168.80.62
ip host ucmsub3.mydomain.com 192.168.80.63
ip host ucmsub4.mydomain.com 192.168.80.64
ip host ucmsub5.mydomain.com 192.168.80.65
ip host _sip._udp.wxtocucm.io srv 0 1 5065 ucmpub.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub1.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub2.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub3.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub4.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub5.mydomain.com
ip host _sip._udp.pstntocucm.io srv 0 1 5060 ucmpub.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub1.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub2.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub3.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub4.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub5.mydomain.com

構成のフィールドの説明はここにあります。

次のコマンドは、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

次のダイヤルピアを設定します。

  1. Unified CM と Webex Calling 間のコールのダイヤルピア:

    
dial-peer voice 300 voip
 description UCM-Webex Calling trunk
 destination-pattern BAD.BAD
 session protocol sipv2
 session target dns:wxtocucm.io
 incoming uri via 300
 voice-class codec 100
 voice-class sip bind control source-interface GigabitEthernet 0/0/0
 voice-class sip bind media source-interface GigabitEthernet 0/0/0
 dtmf-relay rtp-nte
 no vad

    構成のフィールドの説明はここにあります。

    
dial-peer voice 300 voip
 description UCM-Webex Calling trunk

    タグ 300 を使用して VoIP ダイヤルピアを定義し、管理とトラブルシューティングを容易にするための意味のある説明を提供します。

    destination-pattern BAD.BAD

    着信ダイヤル ピア グループを使用して発信コールをルーティングする場合は、ダミー接続先パターンが必要です。 この場合、有効な宛先パターンを使用できます。

    session protocol sipv2

    ダイヤルピア 300 が SIP コール レッグを処理するように指定します。 詳細については、セッションプロトコル（ダイヤルピア）を参照してください。

    セッション ターゲット dns:wxtocucm.io

    DNS SRV 解決を通じて複数の Unified CM ノードのセッション ターゲットを定義します。 この場合、ローカルで定義された SRV レコード wxtocucm.io がコールをダイレクトするために使用されます。

    incoming uri via 300

    音声クラス URI 300 を使用して、ソース ポート 5065 を使用して Unified CM からのすべての着信トラフィックをこのダイヤル ピアにダイレクトします。 詳細については、着信 uri を参照してください。

    音声クラス コーデック 100

    Unified CM との間のコールのコーデック フィルタ リストを示します。 詳細については、「音声クラスコーデック」を参照してください。

    バインド制御ソースインタフェース GigabitEthernet0/0/0

    PSTN に送信されるメッセージのソース インターフェイスと関連する IP アドレスを設定します。 詳細は、bindを参照してください。

    バインド メディア ソース インターフェイス GigabitEthernet0/0/0

    PSTN に送信されるメディアのソース インターフェイスおよび関連する IP アドレスを設定します。 詳細は、bindを参照してください。

    dtmf-relay rtp-nte

    コール レッグで期待されるDTMF機能として、 RTP -NTE (RFC2833) を定義します。 詳細については、「DTMF Relay (Voice over IP)」を参照してください。

    no vad

    音声アクティブティの検出を無効にします。 詳細については、vad（ダイヤルピア）を参照してください。

  2. Unified CM と PSTN 間のコールのダイヤルピア:

    
dial-peer voice 400 voip
 description UCM-PSTN trunk
 destination-pattern BAD.BAD
 session protocol sipv2
 session target dns:pstntocucm.io
 incoming uri via 400
 voice-class codec 100 
 voice-class sip bind control source-interface GigabitEthernet 0/0/0
 voice-class sip bind media source-interface GigabitEthernet 0/0/0
 dtmf-relay rtp-nte
 no vad

    構成のフィールドの説明はここにあります。

    
dial-peer voice 400 voip
 description UCM-PSTN trunk

    次のタグでVoIPダイヤルピアを定義します300管理とトラブルシューティングを容易にするために意味のある説明を付けます。

    destination-pattern BAD.BAD

    着信ダイヤル ピア グループを使用して発信コールをルーティングする場合は、ダミー接続先パターンが必要です。 この場合、有効な宛先パターンを使用できます。

    session protocol sipv2

    ダイヤルピア 400 が SIP コール レッグを処理するように指定します。 詳細については、セッションプロトコル（ダイヤルピア）を参照してください。

    セッション ターゲット dns:pstntocucm.io

    DNS SRV 解決を通じて複数の Unified CM ノードのセッション ターゲットを定義します。 この場合、ローカルで定義された SRV レコード pstntocucm.io がコールをダイレクトするために使用されます。

    URI を400 経由で着信

    音声クラス URI 400 を使用して、ソース ポート 5060 を使用して指定された Unified CM ホストからのすべての着信トラフィックをこのダイヤル ピアに転送します。 詳細については、着信 uri を参照してください。

    音声クラス コーデック 100

    Unified CM との間のコールのコーデック フィルタ リストを示します。 詳細については、「音声クラスコーデック」を参照してください。

    バインド制御ソースインタフェース GigabitEthernet0/0/0

    PSTN に送信されるメッセージのソース インターフェイスと関連する IP アドレスを設定します。 詳細は、bindを参照してください。

    バインド メディア ソース インターフェイス GigabitEthernet0/0/0

    PSTN に送信されるメディアのソース インターフェイスおよび関連する IP アドレスを設定します。 詳細は、bindを参照してください。

    dtmf-relay rtp-nte

    コール レッグで期待されるDTMF機能として、 RTP -NTE (RFC2833) を定義します。 詳細については、「DTMF Relay (Voice over IP)」を参照してください。

    no vad

    音声アクティブティの検出を無効にします。 詳細については、vad（ダイヤルピア）を参照してください。

4

次の設定を使用してコール ルーティングを追加します。

  1. Unified CM と Webex Calling の間で通話をルーティングするダイヤル ピア グループを作成します。 でDPG 100を定義する 発信ダイヤルピア 100 Webex Calling に移行します。 DPG 100 は、Unified CM から関連付けられた着信ダイヤルピアに適用されます。 同様に、Unified CM に向かって発信ダイヤルピア 300 で DPG 300 を定義します。 DPG 300 は、Webex からの着信ダイヤルピアに適用されます。

    
voice class dpg 100
 description Route calls to Webex Calling
 dial-peer 100
voice class dpg 300
 description Route calls to Unified CM Webex Calling trunk
 dial-peer 300

  2. Unified CM と PSTN の間でコールをルーティングするダイヤル ピア グループを作成します。 でDPG 200を定義する 発信ダイヤルピア 200 PSTNへ。 DPG 200 は、Unified CM から関連付けられた着信ダイヤルピアに適用されます。 同様に、Unified CM に向かって発信ダイヤルピア 400 で DPG 400 を定義します。 DPG 400 は、PSTN からの着信ダイヤルピアに適用されます。

    
voice class dpg 200
 description Route calls to PSTN
 dial-peer 200
voice class dpg 400
 description Route calls to Unified CM PSTN trunk
 dial-peer 400

    構成のフィールドの説明はここにあります。

    ダイヤルピア 100

    発信ダイヤルピアとダイヤルピア グループを関連付けます。 詳細は、音声クラス dpgを参照してください。

  3. ダイヤルピア グループを適用して、Webex から Unified CM に、および Unified CM から Webex にコールをルーティングします。

    
dial-peer voice 100
 destination dpg 300
dial-peer voice 300
 destination dpg 100

    構成のフィールドの説明はここにあります。

    宛先 DPG 300

    どのダイヤル ピア グループを指定します。したがって、この着信ダイヤル ピアに提示されたコールの発信処理にダイヤル ピアを使用する必要があります。

  4. ダイヤルピア グループを適用して、PSTN から Unified CM に、Unified CM から PSTN にコールをルーティングします。

    
dial-peer voice 200
 destination dpg 400
dial-peer voice 400
 destination dpg 200

    これでローカル ゲートウェイの設定は終了します。 CUBE 機能が初めて設定される場合は、設定を保存し、プラットフォームを再読み込みします。

診断署名を使ってローカル ゲートウェイを監視しトラブルシューティングする

診断署名(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 以降を実行しているローカル ゲートウェイ

  1. 診断署名はデフォルトで有効になっています。

  2. デバイスが Cisco IOS XE 17.6.1a 以降を実行している場合、プロアクティブな通知を送信するために使用する、セキュアな電子メールサーバを設定します。

    configure terminal 
call-home  
mail-server <username>:<pwd>@<email server> priority 1 secure tls 
end

  3. 環境変数を構成します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 アカウント設定を構成し、デバイスからのメールを適切に処理するための専用権限を指定する必要があります。

  1. に移動 Googleアカウントの管理 > セキュリティを選択し、[安全性の低いアプリアクセス]設定をオンにします。

  2. 「Google 以外のアプリを使って第三者があなたのアカウントにサインインすることができなくなりました」というメールが Gmail から送られてきたら、「はい、それは私です」と回答します。

プロアクティブ モニタリングのための診断署名をインストールする

高いCPU使用率の監視

この DS は、SNMP OID 1.3.6.1.4.1.9.2.1.56 を使用して、CPU 使用率を 5 秒間追跡します。 使用率が 75% 以上に達すると、すべてのデバッグが無効になり、ローカルゲートウェイにインストールされている診断署名がすべてアンインストールされます。 下記の手順を実行して署名をインストールします。

  1. を使用する 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

  2. Diagnostic Signatures Lookup Tool の以下のドロップダウンオプションを使用して、DS 64224 をダウンロードします。

    フィールド名

    フィールド値

    プラットフォーム

    Cisco 4300、4400 ISR シリーズ、または Cisco CSR 1000V シリーズ

    製品

    Webex Calling ソリューションの CUBE Enterprise

    問題の範囲

    パフォーマンス

    問題の種類

    メール通知での高CPU使用率。

  3. 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)

  4. ローカルゲートウェイに DS XML ファイルをインストールします。

    call-home diagnostic-signature load DS_64224.xml 
Load file DS_64224.xml success

  5. イベント、登録者、出席者にすばやくアクセスするため、 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 自体がアンインストールされます。 署名をインストールするには、以下の手順を使用します。

  1. Diagnostic Signatures Lookup Tool の以下のドロップダウンオプションを使用して、DS 64117 をダウンロードします。

    フィールド名

    フィールド値

    プラットフォーム

    Cisco 4300、4400 ISR シリーズ、または Cisco CSR 1000V シリーズ

    製品

    Webex Calling ソリューションの CUBE Enterprise

    問題の範囲

    SIP-SIP

    問題の種類

    メール通知による SIP トランクの登録解除。

  2. DS XML ファイルをローカルゲートウェイにコピーします。

    copy ftp://username:password@<server name or ip>/DS_64117.xml bootflash:

  3. ローカルゲートウェイに DS XML ファイルをインストールします。

    call-home diagnostic-signature load DS_64117.xml 
Load file DS_64117.xml success 
LocalGateway#

  4. イベント、登録者、出席者にすばやくアクセスするため、 call-home 診断署名の表示を実行して、署名が正常にインストールされたことを確認します。 ステータス列の値が「registered」になっている必要があります。

異常な通話切断の監視

この DS は、10 分おきに SNMP ポーリングを使用して、SIP エラー 403、488、503 の異常な通話切断を検出します。  エラーカウントが前回の投票から 5 以上増えている場合、syslog とメール通知が生成されます。 下記の手順を実行して、署名をインストールしてください。

  1. を使用する 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

  2. Diagnostic Signatures Lookup Tool の以下のオプションを使用して、DS 65221 をダウンロードします。

    フィールド名

    フィールド値

    プラットフォーム

    Cisco 4300、4400 ISR シリーズ、または Cisco CSR 1000V シリーズ

    製品

    Webex Calling ソリューションの CUBE Enterprise

    問題の範囲

    パフォーマンス

    問題の種類

    メールおよび Syslog 通知による SIP の異常な通話切断の検出

  3. DS XML ファイルをローカルゲートウェイにコピーします。

    copy ftp://username:password@<server name or ip>/DS_65221.xml bootflash:

  4. ローカルゲートウェイに DS XML ファイルをインストールします。

    call-home diagnostic-signature load DS_65221.xml 
Load file DS_65221.xml success

  5. イベント、登録者、出席者にすばやくアクセスするため、 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 発生を検出し、以下のステップを使用して診断データ収集を自動化します。

  1. 追加の 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"

  2. SNMP がSNMPを表示 コマンド 有効になっていない場合は、snmpサーバーマネージャ コマンド

    show snmp 
%SNMP agent not enabled 
 
 
config t 
snmp-server manager 
end

  3. CPU使用率が高い期間中のすべてのデバッグと診断署名を無効にする予防策として、高CPUモニタリング DS 64224 をインストールしてください。 Diagnostic Signatures Lookup Tool の以下のオプションを使用して、DS 64224 をダウンロードします。

    フィールド名

    フィールド値

    プラットフォーム

    Cisco 4300、4400 ISR シリーズ、または Cisco CSR 1000V シリーズ

    製品

    Webex Calling ソリューションの CUBE Enterprise

    問題の範囲

    パフォーマンス

    問題の種類

    メール通知での高CPU使用率。

  4. 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

  5. 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:

  6. ローカルゲートウェイに、高 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

  7. 署名が正常にインストールされたことを確認してください。 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 では現在、新しいカスタム署名の作成リクエストをサポートしていません。

Control Hub を使用したCisco IOS XE ゲートウェイの管理と検証

Cisco IOS XE ゲートウェイの管理を改善するため、コントロールハブを通じてゲートウェイを登録し、管理することを推奨します。 これはオプションの設定です。 登録すると、コントロール ハブの設定検証オプションを使用して、ローカル ゲートウェイ構成を検証し、構成の問題を特定することができます。 現在、この機能をサポートしているのは登録ベースのトランクだけです。

詳細については、以下を参照してください。

デザインの概要

このセクションでは、証明書ベースの相互 TLS (mTLS) SIP トランクを使用して、Webex Calling のローカル ゲートウェイとして Cisco Unified Border Element (CUBE) を設定する方法について説明します。 このドキュメントの最初の部分は、シンプルな PSTN ゲートウェイを設定する方法を示しています。 この場合、PSTN からのすべてのコールは Webex Calling にルーティングされ、Webex Calling からのすべてのコールは PSTN にルーティングされます。 次の画像では、このソリューションとそれに続く高レベルのコール ルーティング設定が強調表示されます。

この設計では、次の主な構成が使用されます。

  • 音声クラスのテナント: トランク固有の設定を作成するために使用されます。

  • 音声クラス uri: 着信ダイヤルピアの選択のための SIP メッセージを分類するために使用。

  • 着信ダイヤルピア: 着信 SIP メッセージの処理を提供し、ダイヤルピア グループで発信ルートを決定します。

  • ダイヤルピア グループ: オンワード コール ルーティングに使用する発信ダイヤル ピアを定義します。

  • 発信ダイヤルピア: アウトバウンド SIP メッセージの処理を提供し、必要なターゲットにルーティングします。

Call routing from/to PSTN to/from Webex Calling configuration solution

オンプレミスの 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 インターフェイスに割り当てます。


interface GigabitEthernet0/0/0
 description Interface facing PSTN and/or CUCM
 ip address 192.168.80.14 255.255.255.0
!
interface GigabitEthernet0/0/1
 description Interface facing Webex Calling (Public address)
 ip address 198.51.100.1 255.255.255.240
2

対称暗号化を使用してルータの STUN クレデンシャルを保護します。 プライマリ暗号化キーと暗号化タイプを次のように設定します。


key config-key password-encrypt YourPassword
password encryption aes
3

希望する認証局 (CA) によって署名された証明書を使用して暗号化トラストポイントを作成します。

  1. 次の exec コマンドを使用して RSA キーペアを作成します。

    crypto key generate rsa general-keys exportable label lgw-key modulus 4096

  2. 次の設定コマンドを使用して、署名済み証明書のトラストポイントを作成します。

    
crypto pki trustpoint LGW_CERT
 enrollment terminal pem
 fqdn cube1.lgw.com
 subject-name cn=cube1.lgw.com
 subject-alt-name cube1.lgw.com
 revocation-check none
 rsakeypair lgw-key

  3. 次の exec または configuration コマンドを使用して証明書署名リクエスト（CSR）を生成し、サポートされている CA プロバイダーから署名済み証明書を要求するために使用します。

    crypto pki enroll LGW_CERT
4

中間（またはルート）CA 証明書を使用して新しい証明書を認証し、証明書をインポートします（ステップ 4）。 次の exec または configuration コマンドを入力します。


crypto pki authenticate LGW_CERT
<paste Intermediate X.509 base 64 based certificate here>
5

次の exec または configuration コマンドを使用して、署名済みホスト証明書をインポートします。


crypto pki import LGW_CERT certificate
<paste CUBE host X.509 base 64 certificate here>
6

TLS1.2 排他を有効にし、次の設定コマンドを使用してデフォルトのトラストポイントを指定します。


 sip-ua
  crypto signaling default trustpoint LGW_CERT
  transport tcp tls v1.2
7

Webex Calling で使用される DigiCert CA 証明書を含む Cisco ルート CA バンドルをインストールします。 を使用する crypto pki trustpool インポート クリーン URLコマンドは、指定されたURLからルートCAバンドルをダウンロードし、現在のCAトラストプールをクリアしてから、証明書の新しいバンドルをインストールします。


 

HTTPS を使用してインターネットにアクセスするためにプロキシを使用する必要がある場合は、CA バンドルをインポートする前に、次の設定を追加します。

ip httpクライアントプロキシサーバーyourproxy.comプロキシポート80 

ip http client source-interface GigabitEthernet0/0/1 
crypto pki trustpool import clean url https://www.cisco.com/security/pki/trs/ios_core.p7b

Webex Calling 証明書ベースのトランクの設定

1

Control Hub の既存のロケーションの CUBE 証明書ベースの PSTN トランクを作成します。 詳細については、次のサイトを参照してください。 Webex Calling用にトランク、ルートグループ、ダイヤルプランを構成するを選択します。


 
トランクが作成されると、提供されたトランク情報をメモします。 次の図で強調表示されているこれらの詳細は、このガイドの設定手順で使用されます。
2

次のコマンドを入力して、CUBE を Webex Calling ローカル ゲートウェイとして設定します。


voice service voip
 ip address trusted list
  ipv4 x.x.x.x y.y.y.y
 mode border-element
 allow-connections sip to sip
 no supplementary-service sip refer
 stun
  stun flowdata agent-id 1 boot-count 4
  stun flowdata shared-secret 0 Password123$
 sip 
  asymmetric payload full
  early-offer forced
  sip-profiles inbound

構成のフィールドの説明はここにあります。


ip address trusted list
 ipv4 x.x.x.x y.y.y.y

  • トール詐欺から保護するために、信頼されたアドレス リストは、ローカル ゲートウェイが正当な VoIP コールを期待するホストおよびネットワーク エンティティのリストを定義します。

  • デフォルトでは、ローカル ゲートウェイは、信頼されたリストに含まれていない IP アドレスからのすべての着信 VoIP メッセージをブロックします。 「セッション ターゲット IP」またはサーバー グループ IP アドレスを持つ静的に設定されたダイヤル ピアはデフォルトで信頼されるため、信頼されたリストに追加する必要はありません。

  • ローカル ゲートウェイを設定するときは、地域の Webex Calling データセンターの IP サブネットをリストに追加します。詳細については、「Webex Calling のポート参照情報」を参照してください。 また、Unified Communications Manager サーバ（使用されている場合）および PSTN トランク ゲートウェイのアドレス範囲を追加します。

  • 電話料金の詐欺行為を防ぐためにIPアドレス信頼リストを使用する方法についての詳細は、次を参照してください。 IPアドレス信頼を選択します。

モード ボーダー要素

プラットフォームで Cisco Unified Border Element（CUBE）機能を有効にします。

allow-connections sip to sip

CUBE 基本 SIP バックツーバックユーザーエージェント機能を有効にします。 詳細については、次のサイトを参照してください。接続を許可を選択します。


 

デフォルトでは、T.38 ファックス転送が有効になっています。 詳細については、ファックスプロトコルt38 (音声サービス)を参照してください。

スタイン

STUN (NAT を介した UDP のセッショントラバーサル) をグローバルに有効にします。


 
これらのグローバル スタンコマンドは、NAT の後ろにローカル ゲートウェイを展開する場合にのみ必要です。

  • コールをWebex Callingユーザ（たとえば、着信側と発信側の両方がWebex Callingメディアをアンカーする場合はWebex Calling SBC)、ピンホールが開いていないため、メディアはローカル ゲートウェイにフローしません。

  • ローカル ゲートウェイの STUN バインディング機能により、ネゴシエートされたメディア パス上でローカルに生成された STUN 要求を送信できます。 これは、ファイアウォールのピンホールを開くのに役立ちます。

詳細については、「stun flowdata agent-id」および「stun flowdata shared-secret」を参照してください。

非対称ペイロード フル

DTMF と動的コーデック ペイロードの両方に対して SIP 非対称ペイロード サポートを設定します。 このコマンドの詳細については、次を参照してください非対称ペイロードを選択します。

early-offer forced

ローカル ゲートウェイは、隣接するピアからの確認を待つ代わりに、最初の INVITE メッセージで SDP 情報を送信するように強制します。 このコマンドの詳細については、次を参照してください早期オファーを選択します。

SIP プロファイル着信

CUBE が SIP プロファイルを使用して、受信したメッセージを変更できるようにします。 プロファイルは、ダイヤルピアまたはテナントを介して適用されます。

3

を設定する 音声クラスコーデック 100 トランクの コーデック フィルタ。 この例では、すべてのトランクに同じコーデックフィルタが使用されます。 正確な制御のために各トランクにフィルタを設定できます。


voice class codec 100
 codec preference 1 opus
 codec preference 2 g711ulaw
 codec preference 3 g711alaw

構成のフィールドの説明はここにあります。

音声クラス コーデック 100

SIP トランクを介したコールの優先コーデックのみを許可するために使用されます。 詳細については、音声クラスコーデック を参照してください。


 

Opus コーデックは、SIP ベースの PSTN トランクでのみサポートされています。 PSTN トランクが音声 T1/E1 またはアナログ FXO 接続を使用している場合は、コーデックの設定 1 オプスから音声クラスコーデック 100の設定。

4

を設定する 音声クラスの使い方 100 は、Webex Calling トランクで ICE を有効にします。 (この手順は政府版 Webex には適用されません)


voice class stun-usage 100 
 stun usage firewall-traversal flowdata
 stun usage ice lite

構成のフィールドの説明はここにあります。

stunusageiceliteについて

すべての Webex Calling のダイヤルピアに対して ICE-Lite を有効にして、可能な限り、メディア最適化を可能にするために使用。 詳細については、次のサイトを参照してください。音声クラススタンの使用およびスタン使用アイスライトを選択します。


 
使用量のファイアウォール/トラバーサルフローデータを読み込むコマンドは、NATの後ろにローカルゲートウェイを展開する場合にのみ必要です。

 
メディア パスの最適化を使用したコール フローには、ICE-lite のスタン使用が必要です。 SIP から TDM ゲートウェイへのメディア最適化を提供するには、IP-IP レッグで ICE-Lite が有効になっているループバック ダイヤル ピアを設定します。 技術的な詳細については、アカウントまたは TAC チームにお問い合わせください。
5

Webex トラフィックのメディア暗号化ポリシーを設定します。 (この手順は政府版 Webex には適用されません)


voice class srtp-crypto 100
 crypto 1 AES_CM_128_HMAC_SHA1_80

構成のフィールドの説明はここにあります。

音声クラス srtp-crypto 100

SDP の SRTP 暗号スイート CUBE オファーおよび応答メッセージの唯一の SRTP オファーとして SHA1_80 を指定します。 Webex Calling は SHA180 のみをサポートします。_ 詳細については、次のサイトを参照してください。音声クラス SRTP 暗号化を選択します。

6

FIPS 準拠の GCM 暗号を設定します(この手順は政府版 Webex にのみ適用されます)。


voice class srtp-crypto 100
crypto 1 AEAD_AES_256_GCM

構成のフィールドの説明はここにあります。

音声クラス srtp-crypto 100

CUBE が提供する暗号スイートとして GCM を指定します。 政府版 Webex のローカル ゲートウェイの GCM 暗号を設定することは必須です。

7

宛先 FQDN または SRV に基づいて、ローカル ゲートウェイ トランクへのコールを一意に識別するためのパターンを設定します。


voice class uri 100 sip
 pattern cube1.lgw.com

構成のフィールドの説明はここにあります。

音声クラス uri 100 sip

着信トランク ダイヤル ピアへの着信 SIP 招待と一致するパターンを定義します。 このパターンを入力するときは、トランクの作成中に Control Hub で設定された LGW FQDN または SRV を使用します。

8

SIP メッセージ操作プロファイルを設定します。 ゲートウェイがパブリック IP アドレスで設定されている場合は、次のようにプロファイルを設定するか、NAT を使用している場合は、次のステップにスキップします。 この例では、cube1.lgw.com はローカル ゲートウェイ用に設定された FQDN であり、「198.51.100.1」は Webex Calling に面したローカル ゲートウェイ インターフェイスのパブリック IP アドレスです。


voice class sip-profiles 100
 rule 10 request ANY sip-header Contact modify "@.*:" "@cube1.lgw.com:" 
 rule 20 response ANY sip-header Contact modify "@.*:" "@cube1.lgw.com:"

構成のフィールドの説明はここにあります。

ルール10と20

Webex がローカル ゲートウェイからのメッセージを認証できるようにするには、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 プロファイル

voice class sip-profiles 100
 rule 10 request ANY sip-header Contact modify "@.*:" "@cube1.lgw.com:"
 rule 20 response ANY sip-header Contact modify "@.*:" "@cube1.lgw.com:"
 rule 30 response ANY sdp-header Audio-Attribute modify "(a=candidate:1 1.*) 10.80.13.12" "\1 192.65.79.20"
 rule 31 response ANY sdp-header Audio-Attribute modify "(a=candidate:1 2.*) 10.80.13.12" "\1 192.65.79.20"
 rule 40 response ANY sdp-header Audio-Connection-Info modify "IN IP4 10.80.13.12" "IN IP4 192.65.79.20"
 rule 41 request ANY sdp-header Audio-Connection-Info modify "IN IP4 10.80.13.12" "IN IP4 192.65.79.20"
 rule 50 request ANY sdp-header Connection-Info modify "IN IP4 10.80.13.12" "IN IP4 192.65.79.20"
 rule 51 response ANY sdp-header Connection-Info modify "IN IP4 10.80.13.12" "IN IP4 192.65.79.20"
 rule 60 response ANY sdp-header Session-Owner modify "IN IP4 10.80.13.12" "IN IP4 192.65.79.20"
 rule 61 request ANY sdp-header Session-Owner modify "IN IP4 10.80.13.12" "IN IP4 192.65.79.20"
 rule 70 request ANY sdp-header Audio-Attribute modify "(a=rtcp:.*) 10.80.13.12" "\1 192.65.79.20"
 rule 71 response ANY sdp-header Audio-Attribute modify "(a=rtcp:.*) 10.80.13.12" "\1 192.65.79.20
 rule 80 request ANY sdp-header Audio-Attribute modify "(a=candidate:1 1.*) 10.80.13.12" "\1 192.65.79.20"
 rule 81 request ANY sdp-header Audio-Attribute modify "(a=candidate:1 2.*) 10.80.13.12" "\1 192.65.79.20"

構成のフィールドの説明はここにあります。

ルール10と20

Webex がローカル ゲートウェイからのメッセージを認証できるようにするには、SIP 要求および応答メッセージの「連絡先」ヘッダーに、Control Hub のトランクにプロビジョニングされた値が含まれている必要があります。 これは、単一のホストの FQDN、またはデバイスのクラスタに使用される SRV ドメイン名のいずれかになります。

ルール30～81

プライベート アドレス参照をサイトの外部パブリック アドレスに変換し、Webex が後続のメッセージを正しく解釈してルーティングできるようにします。

Webex Calling からの着信メッセージの SIP プロファイル

voice class sip-profiles 110
 rule 10 response ANY sdp-header Video-Connection-Info modify "192.65.79.20" "10.80.13.12"
 rule 20 response ANY sip-header Contact modify "@.*:" "@cube1.lgw.com:"
 rule 30 response ANY sdp-header Connection-Info modify "192.65.79.20" "10.80.13.12"
 rule 40 response ANY sdp-header Audio-Connection-Info modify "192.65.79.20" "10.80.13.12"
 rule 50 response ANY sdp-header Session-Owner modify "192.65.79.20" "10.80.13.12"
 rule 60 response ANY sdp-header Audio-Attribute modify "(a=candidate:1 1.*) 192.65.79.20" "\1 10.80.13.12"
 rule 70 response ANY sdp-header Audio-Attribute modify "(a=candidate:1 2.*) 192.65.79.20" "\1 10.80.13.12"
 rule 80 response ANY sdp-header Audio-Attribute modify "(a=rtcp:.*) 192.65.79.20" "\1 10.80.13.12"

構成のフィールドの説明はここにあります。

10から80までのルール

パブリックアドレス参照を設定済みのプライベートアドレスに変換し、Webex からのメッセージを CUBE で正しく処理できるようにします。

詳細については、次のサイトを参照してください。音声クラス sip-プロファイルを選択します。

10

ヘッダー変更プロファイルを使用して SIP オプションをキープアライブに設定します。


voice class sip-profiles 115
 rule 10 request OPTIONS sip-header Contact modify "<sip:.*:" "<sip:cube1.lgw.com:" 
 rule 30 request ANY sip-header Via modify "(SIP.*) 10.80.13.12" "\1 192.65.79.20"
 rule 40 response ANY sdp-header Connection-Info modify "10.80.13.12" "192.65.79.20"  
 rule 50 response ANY sdp-header Audio-Connection-Info modify "10.80.13.12" "192.65.79.20"
!
voice class sip-options-keepalive 100
 description Keepalive for Webex Calling
 up-interval 5
 transport tcp tls
 sip-profiles 115

構成のフィールドの説明はここにあります。

音声クラス 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 トランクの設定:

  1. を作成 音声クラス テナント 100は、Webex Callingトランクに必要な設定を定義し、グループ化します。 このテナントに関連付けられているダイヤルピアは、後でこれらの設定を継承します。


     

    次の例では、このガイドの目的のために、ステップ 1 に示されている値を使用します (太字で表示)。 これらを構成のトランクの値に置き換えます。

    
voice class tenant 100
 no remote-party-id
 sip-server dns:us25.sipconnect.bcld.webex.com
 srtp-crypto 100
 localhost dns:cube1.lgw.com
 session transport tcp tls
 no session refresh
 error-passthru
 bind control source-interface GigabitEthernet0/0/1
 bind media source-interface GigabitEthernet0/0/1
 no pass-thru content custom-sdp
 sip-profiles 100 
 sip-profiles 110 inbound
 privacy-policy passthru
!

    構成のフィールドの説明はここにあります。

    音声クラス テナント 100

    テナントを使用して、独自の TLS 証明書と CN または SAN 検証リストを持つトランクを設定することをお勧めします。 ここでは、テナントに関連付けられた tls プロファイルには、新しい接続を受け入れるか作成するために使用される信頼ポイントが含まれており、着信接続を検証するための CN または SAN リストがあります。 詳細については、次のサイトを参照してください。音声クラス テナントを選択します。

    no remote-party-id

    ID Webex Callingは PAI をサポートしているため、CIOアサート ID paiを選択します。 詳細については、次のサイトを参照してください。リモートパーティ IDを選択します。

    sip-server dns:us25.sipconnect.bcld.webex.com

    トランクのターゲット SIP サーバを設定します。 トランクを作成したときに、Control Hub で提供されるエッジ プロキシ SRV アドレスを使用します

    srtp クリプト 100

    SRTP コール レッグ（接続）の優先暗号スイートを設定します（ステップ 5 で指定）。 詳細については、次のサイトを参照してください。音声クラス SRTP 暗号化を選択します。

    localhost DNS: キューブ1.lgw.com

    発信メッセージの [送信元（From）]、[コール ID（Call-ID）]、および [リモートパーティー（Remote-Party-ID）] ヘッダーの物理的な IP アドレスを提供された FQDN に置き換えるように CUBE を設定します。

    session transport tcp tls

    関連付けられたダイヤルピアの TLS へのトランスポートを設定します。 詳細については、次のサイトを参照してください。セッション-トランスポートを選択します。

    セッション更新なし

    SIP セッションの更新をグローバルに無効にします。

    error-passthru

    SIP エラー応答パススルー機能を指定します。 詳細については、次のサイトを参照してください。エラーpassthruを選択します。

    バインド制御ソースインターフェイス GigabitEthernet0/0/1

    Webex Calling に送信されるメッセージのソース インターフェイスと関連する IP アドレスを設定します。 詳細は、bindを参照してください。

    バインド メディア ソース インターフェイス GigabitEthernet0/0/1

    Webex Calling に送信されるメディアのソース インターフェイスおよび関連する IP アドレスを設定します。 詳細は、bindを参照してください。

    音声クラス SIP プロファイル 100

    ヘッダー変更プロファイル（パブリック IP または NAT アドレス）を発信メッセージに使用するように適用します。 詳細については、次のサイトを参照してください。音声クラスの sip プロファイルを選択します。

    音声クラス SIP プロファイル 110 着信

    受信メッセージに使用するヘッダー変更プロファイル（NAT アドレスのみ）を適用します。 詳細については、音声クラス SIP プロファイルを参照してください。

    プライバシーポリシーpassthru

    トランクのプライバシー ヘッダー ポリシー オプションを設定して、受信したメッセージから次のコール レッグにプライバシーの値を渡します。 詳細については、次のサイトを参照してください。プライバシーポリシーを選択します。

  2. Webex Calling トランク ダイヤル ピアを設定します。

    
dial-peer voice 100 voip
 description Inbound/Outbound Webex Calling
 destination-pattern BAD.BAD
 session protocol sipv2
 session target sip-server
 incoming uri request 100
 voice-class codec 100
 voice-class stun-usage 100
 voice-class sip rel1xx disable
 voice-class sip asserted-id pai
 voice-class sip tenant 100
 voice-class sip options-keepalive profile 100
 dtmf-relay rtp-nte 
 srtp
 no vad

    構成のフィールドの説明はここにあります。

    
dial-peer voice 100 voip
 description Inbound/Outbound Webex Calling

    のタグを持つVoIPダイヤルピアを定義する 100で、管理とトラブルシューティングを容易にする意味のある説明を提供します。 詳細については、次のサイトを参照してください。ダイヤルピア音声を選択します。

    destination-pattern BAD.BAD

    着信ダイヤル ピア グループを使用して発信コールをルーティングする場合は、ダミー接続先パターンが必要です。 この場合、有効な宛先パターンを使用できます。

    session protocol sipv2

    ダイヤルピア を指定する 100 は SIP コール レッグを処理します。 詳細については、セッションプロトコル（ダイヤルピア）を参照してください。

    session target sip-server

    テナント 100 で定義された SIP サーバが継承され、このダイヤル ピアからのコールの宛先に使用されることを示します。

    着信 uri リクエスト 100

    VoIP ダイヤル ピアと着信コールのユニフォーム リソース 識別子（URI）を一致させるために使用される音声クラスを指定します。 詳細については、着信 uri を参照してください。

    音声クラス コーデック 100

    Webex Calling との通話のコーデック フィルター リストを示します。 詳細については、音声クラスコーデック を参照してください。

    音声クラスstun使用 100

    ローカル ゲートウェイでローカルに生成された STUN 要求を、ネゴシエートされたメディア パス経由で送信できるようにします。 STUN は、メディア トラフィックのファイアウォールのピンホールを開くのに役立ちます。

    音声クラス sip asserted-id pai

    プライバシー アサート済み ID（PAI）ヘッダーを使用して、発信通話情報を設定します。 詳細については、voice-class sip asserted-idを参照してください。

    音声クラス sip テナント 100

    ダイヤル ピアは、グローバルおよびテナント 100 で設定されたすべてのパラメータを継承します。 パラメータはダイヤルピア レベルで上書きされる場合があります。 詳細については、「音声クラス SIP テナント」を参照してください。

    音声クラス sip options-keepalive プロファイル 100

    このコマンドは、特定のプロファイル（100）を使用して、SIP サーバまたはエンドポイントのグループの可用性を監視するために使用されます。

    srtp

    コール レッグのSRTPを有効にします。

SIP PSTN トランクを使用したローカル ゲートウェイの設定

上記の Webex Calling に対してトランクを構築した後、次の設定を使用して、SIP ベースの PSTN プロバイダーに対して暗号化されていないトランクを作成します。


 

サービス プロバイダーがセキュアな PSTN トランクを提供している場合、上記の Webex Calling トランクと同様の構成に従うことができます。 セキュアからセキュアなコール ルーティングは CUBE でサポートされています。


 

Cisco TDM-SIP ゲートウェイで PSTN コール レッグの TDM インターフェイスを設定するには、「ISDN PRI の設定」を参照してください。

1

PSTN トランクからの着信コールを識別するには、次の音声クラス uri を設定します。


voice class uri 200 sip
  host ipv4:192.168.80.13

構成のフィールドの説明はここにあります。

音声クラス uri 200 sip

着信トランク ダイヤル ピアへの着信 SIP 招待と一致するパターンを定義します。 このパターンを入力するときは、IP PSTN ゲートウェイの IP アドレスを使用します。 詳細については、音声クラス uri を参照してください。

2

次の IP PSTN ダイヤル ピアを設定します。


dial-peer voice 200 voip
 description Inbound/Outbound IP PSTN trunk
 destination-pattern BAD.BAD
 session protocol sipv2
 session target ipv4:192.168.80.13
 incoming uri via 200
 voice-class sip bind control source-interface GigabitEthernet0/0/0 
 voice-class sip bind media source-interface  GigabitEthernet0/0/0 
 voice-class codec 100
 dtmf-relay rtp-nte 
 no vad

構成のフィールドの説明はここにあります。


dial-peer voice 200 voip
 description Inbound/Outbound IP PSTN trunk

次のタグで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 経由で 着信 uri

VIA ヘッダーとIP PSTN のIPアドレスの一致基準を定義します。 ローカル ゲートウェイのすべての着信 IP PSTN コール レッグとダイヤル ピア 200 を一致させます。 詳細については、着信 URLを参照してください。

バインド制御ソースインタフェース GigabitEthernet0/0/0

PSTN に送信されるメッセージのソース インターフェイスと関連する IP アドレスを設定します。 詳細は、bindを参照してください。

バインド メディア ソース インターフェイス GigabitEthernet0/0/0

PSTN に送信されるメディアのソース インターフェイスおよび関連する 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 プラットフォームを使用してローカル ゲートウェイを設定する場合は、次のセクションに進みます。

  1. ダイヤルピア グループを作成して、Webex Calling または PSTN にコールをルーティングします。 Webex Calling に向けて発信ダイヤルピア 100 で DPG 100 を定義します。 DPG 100 は、PSTN からの着信ダイヤルピアに適用されます。 同様に、PSTN に向かって発信ダイヤルピア 200 で DPG 200 を定義します。 DPG 200 は、Webex からの着信ダイヤルピアに適用されます。

    
voice class dpg 100 
 description Route calls to Webex Calling 
 dial-peer 100 
voice class dpg 200 
 description Route calls to PSTN 
 dial-peer 200

    構成のフィールドの説明はここにあります。

    ダイヤルピア 100

    発信ダイヤルピアとダイヤルピア グループを関連付けます。 詳細は、音声クラス dpgを参照してください。

  2. ダイヤルピア グループを適用して、Webex から PSTN に、および PSTN から Webex にコールをルーティングします。

    
dial-peer voice 100
 destination dpg 200
dial-peer voice 200
 destination dpg 100

    構成のフィールドの説明はここにあります。

    destination dpg 200

    どのダイヤル ピア グループを指定します。したがって、この着信ダイヤル ピアに提示されたコールの発信処理にダイヤル ピアを使用する必要があります。

    これでローカル ゲートウェイの設定は終了します。 CUBE 機能が初めて設定される場合は、設定を保存し、プラットフォームをリロードします。

既存のUnified CM環境でローカル ゲートウェイを構成する

前のセクションの PSTN-Webex Calling 設定は、Cisco Unified Communications Manager (UCM) クラスタへの追加のトランクを含めるように変更される場合があります。 この場合、すべてのコールは Unified CM 経由でルーティングされます。 ポート 5060 の UCM からのコールは PSTN にルーティングされ、ポート 5065 からのコールは Webex Calling にルーティングされます。 次の増分設定を追加して、この通話シナリオを含めることができます。

1

以下の音声クラス URI を設定:

  1. SIP VIA ポートを使用して Unified CM を Webex コールに分類します。

    
voice class uri 300 sip
 pattern :5065

  2. ポート経由の SIP を使用して、Unified CM を PSTN コールに分類します。

    
voice class uri 400 sip
 pattern :192\.168\.80\.6[0-5]:5060

    発信元のソース アドレスとポート番号を説明する 1 つ以上のパターンを使用して、UCM からの着信メッセージを PSTN トランクに分類します。 必要に応じて、正規表現を使用して、一致するパターンを定義できます。

    上記の例では、192.168.80.60 から 65 までの範囲およびポート番号 5060 の任意の IP アドレスに一致させるために正規表現が使用されます。

2

次の DNS レコードを設定して、Unified CM ホストへの SRV ルーティングを指定します。


 

IOS XE は、これらのレコードをローカルでターゲット UCM ホストとポートを決定するために使用します。 この設定では、DNS システムでレコードを設定する必要はありません。 DNS を使用する場合は、これらのローカル設定は必要ありません。


ip host ucmpub.mydomain.com 192.168.80.60
ip host ucmsub1.mydomain.com 192.168.80.61
ip host ucmsub2.mydomain.com 192.168.80.62
ip host ucmsub3.mydomain.com 192.168.80.63
ip host ucmsub4.mydomain.com 192.168.80.64
ip host ucmsub5.mydomain.com 192.168.80.65
ip host _sip._udp.wxtocucm.io srv 0 1 5065 ucmpub.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub1.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub2.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub3.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub4.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub5.mydomain.com
ip host _sip._udp.pstntocucm.io srv 0 1 5060 ucmpub.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub1.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub2.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub3.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub4.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub5.mydomain.com

構成のフィールドの説明はここにあります。

次のコマンドは、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

次のダイヤルピアを設定します。

  1. Unified CM と Webex Calling 間のコールのダイヤルピア:

    
dial-peer voice 300 voip
 description UCM-Webex Calling trunk
 destination-pattern BAD.BAD
 session protocol sipv2
 session target dns:wxtocucm.io
 incoming uri via 300
 voice-class codec 100
 voice-class sip bind control source-interface GigabitEthernet 0/0/0
 voice-class sip bind media source-interface GigabitEthernet 0/0/0
 dtmf-relay rtp-nte
 no vad

    構成のフィールドの説明はここにあります。

    
dial-peer voice 300 voip
 description UCM-Webex Calling trunk

    タグ 300 を使用して VoIP ダイヤルピアを定義し、管理とトラブルシューティングを容易にするための意味のある説明を提供します。

    destination-pattern BAD.BAD

    着信ダイヤル ピア グループを使用して発信コールをルーティングする場合は、ダミー接続先パターンが必要です。 この場合、有効な宛先パターンを使用できます。

    session protocol sipv2

    ダイヤルピア 300 が SIP コール レッグを処理するように指定します。 詳細については、セッションプロトコル（ダイヤルピア）を参照してください。

    セッション ターゲット dns:wxtocucm.io

    DNS SRV 解決を通じて複数の Unified CM ノードのセッション ターゲットを定義します。 この場合、ローカルで定義された SRV レコード wxtocucm.io がコールをダイレクトするために使用されます。

    incoming uri via 300

    音声クラス URI 300 を使用して、ソース ポート 5065 を使用して Unified CM からのすべての着信トラフィックをこのダイヤル ピアにダイレクトします。 詳細については、着信 uri を参照してください。

    音声クラス コーデック 100

    Unified CM との間のコールのコーデック フィルタ リストを示します。 詳細については、「音声クラスコーデック」を参照してください。

    バインド制御ソースインタフェース GigabitEthernet0/0/0

    PSTN に送信されるメッセージのソース インターフェイスと関連する IP アドレスを設定します。 詳細は、bindを参照してください。

    バインド メディア ソース インターフェイス GigabitEthernet0/0/0

    PSTN に送信されるメディアのソース インターフェイスおよび関連する IP アドレスを設定します。 詳細は、bindを参照してください。

    dtmf-relay rtp-nte

    コール レッグで期待されるDTMF機能として、 RTP -NTE (RFC2833) を定義します。 詳細については、「DTMF Relay (Voice over IP)」を参照してください。

    no vad

    音声アクティブティの検出を無効にします。 詳細については、vad（ダイヤルピア）を参照してください。

  2. Unified CM と PSTN 間のコールのダイヤルピア:

    
dial-peer voice 400 voip
 description UCM-PSTN trunk
 destination-pattern BAD.BAD
 session protocol sipv2
 session target dns:pstntocucm.io
 incoming uri via 400
 voice-class codec 100 
 voice-class sip bind control source-interface GigabitEthernet 0/0/0
 voice-class sip bind media source-interface GigabitEthernet 0/0/0
 dtmf-relay rtp-nte
 no vad

    構成のフィールドの説明はここにあります。

    
dial-peer voice 400 voip
 description UCM-PSTN trunk

    次のタグでVoIPダイヤルピアを定義します300管理とトラブルシューティングを容易にするために意味のある説明を付けます。

    destination-pattern BAD.BAD

    着信ダイヤル ピア グループを使用して発信コールをルーティングする場合は、ダミー接続先パターンが必要です。 この場合、有効な宛先パターンを使用できます。

    session protocol sipv2

    ダイヤルピア 400 が SIP コール レッグを処理するように指定します。 詳細については、セッションプロトコル（ダイヤルピア）を参照してください。

    セッション ターゲット dns:pstntocucm.io

    DNS SRV 解決を通じて複数の Unified CM ノードのセッション ターゲットを定義します。 この場合、ローカルで定義された SRV レコード pstntocucm.io がコールをダイレクトするために使用されます。

    URI を400 経由で着信

    音声クラス URI 400 を使用して、ソース ポート 5060 を使用して指定された Unified CM ホストからのすべての着信トラフィックをこのダイヤル ピアに転送します。 詳細については、着信 uri を参照してください。

    音声クラス コーデック 100

    Unified CM との間のコールのコーデック フィルタ リストを示します。 詳細については、「音声クラスコーデック」を参照してください。

    バインド制御ソースインタフェース GigabitEthernet0/0/0

    PSTN に送信されるメッセージのソース インターフェイスと関連する IP アドレスを設定します。 詳細は、bindを参照してください。

    バインド メディア ソース インターフェイス GigabitEthernet0/0/0

    PSTN に送信されるメディアのソース インターフェイスおよび関連する IP アドレスを設定します。 詳細は、bindを参照してください。

    dtmf-relay rtp-nte

    コール レッグで期待されるDTMF機能として、 RTP -NTE (RFC2833) を定義します。 詳細については、「DTMF Relay (Voice over IP)」を参照してください。

    no vad

    音声アクティブティの検出を無効にします。 詳細については、vad（ダイヤルピア）を参照してください。

4

次の設定を使用してコール ルーティングを追加します。

  1. Unified CM と Webex Calling の間で通話をルーティングするダイヤル ピア グループを作成します。 でDPG 100を定義する 発信ダイヤルピア 100 Webex Calling に移行します。 DPG 100 は、Unified CM から関連付けられた着信ダイヤルピアに適用されます。 同様に、Unified CM に向かって発信ダイヤルピア 300 で DPG 300 を定義します。 DPG 300 は、Webex からの着信ダイヤルピアに適用されます。

    
voice class dpg 100
 description Route calls to Webex Calling
 dial-peer 100
voice class dpg 300
 description Route calls to Unified CM Webex Calling trunk
 dial-peer 300

  2. Unified CM と PSTN の間でコールをルーティングするダイヤル ピア グループを作成します。 でDPG 200を定義する 発信ダイヤルピア 200 PSTNへ。 DPG 200 は、Unified CM から関連付けられた着信ダイヤルピアに適用されます。 同様に、Unified CM に向かって発信ダイヤルピア 400 で DPG 400 を定義します。 DPG 400 は、PSTN からの着信ダイヤルピアに適用されます。

    
voice class dpg 200
 description Route calls to PSTN
 dial-peer 200
voice class dpg 400
 description Route calls to Unified CM PSTN trunk
 dial-peer 400

    構成のフィールドの説明はここにあります。

    ダイヤルピア 100

    発信ダイヤルピアとダイヤルピア グループを関連付けます。 詳細は、音声クラス dpgを参照してください。

  3. ダイヤルピア グループを適用して、Webex から Unified CM に、および Unified CM から Webex にコールをルーティングします。

    
dial-peer voice 100
 destination dpg 300
dial-peer voice 300
 destination dpg 100

    構成のフィールドの説明はここにあります。

    宛先 DPG 300

    どのダイヤル ピア グループを指定します。したがって、この着信ダイヤル ピアに提示されたコールの発信処理にダイヤル ピアを使用する必要があります。

  4. ダイヤルピア グループを適用して、PSTN から Unified CM に、Unified CM から PSTN にコールをルーティングします。

    
dial-peer voice 200
 destination dpg 400
dial-peer voice 400
 destination dpg 200

    これでローカル ゲートウェイの設定は終了します。 CUBE 機能が初めて設定される場合は、設定を保存し、プラットフォームを再読み込みします。

診断署名を使ってローカル ゲートウェイを監視しトラブルシューティングする

診断署名(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 以降を実行しているローカルゲートウェイ

  1. 診断署名はデフォルトで有効になっています。

  2. デバイスで IOS XE 17.6.1 以降を実行している場合は、プロアクティブ通知の送信に使用するセキュアなメールサーバーを構成します。

    
configure terminal 
call-home  
mail-server <username>:<pwd>@<email server> priority 1 secure tls 
end

  3. 環境変数を構成します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% 以上に達すると、すべてのデバッグが無効になり、ローカルゲートウェイにインストールした診断署名がすべてアンインストールされます。 下記の手順を実行して署名をインストールします。

  1. コマンド を使用して 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

  2. 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 使用率

  3. 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)

  4. ローカルゲートウェイに DS XML ファイルをインストールします。

    
call-home diagnostic-signature load DS_64224.xml 
Load file DS_64224.xml success

  5. イベント、登録者、出席者にすばやくアクセスするため、 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 とメール通知が生成されます。 下記の手順を実行して、署名をインストールしてください。

  1. コマンド を使用して 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

  2. Diagnostic Signatures Lookup Tool の以下のオプションを使用して、DS 65221 をダウンロードします。

    フィールド名

    フィールド値

    プラットフォーム

    Cisco 4300、4400 ISR シリーズ、または Catalyst 8000V Edge ソフトウェア

    製品

    Webex Calling ソリューションの CUBE Enterprise

    問題の範囲

    パフォーマンス

    問題の種類

    メールおよび Syslog 通知による SIP の異常な通話切断の検出

  3. DS XML ファイルをローカルゲートウェイにコピーします。

    copy ftp://username:password@<server name or ip>/DS_65221.xml bootflash:

  4. ローカルゲートウェイに DS XML ファイルをインストールします。

    
call-home diagnostic-signature load DS_65221.xml 
Load file DS_65221.xml success

  5. コマンドを使用する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 発生を検出し、以下のステップを使用して診断データ収集を自動化します。

  1. 別の 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"

  2. コマンド を使用して SNMP が有効になっていることを確認します。 SNMPを表示だ SNMP が有効になっていない場合は、snmpサーバーマネージャ コマンド

    
show snmp 
%SNMP agent not enabled 
 
config t 
snmp-server manager 
end

  3. CPU使用率が高い期間中のすべてのデバッグと診断署名を無効にする予防策として、高CPUモニタリング DS 64224 をインストールすることをお勧めします。 Diagnostic Signatures Lookup Tool の以下のオプションを使用して、DS 64224 をダウンロードします。

    フィールド名

    フィールド値

    プラットフォーム

    Cisco 4300、4400 ISR シリーズ、または Catalyst 8000V Edge ソフトウェア

    製品

    Webex Calling ソリューションの CUBE Enterprise

    問題の範囲

    パフォーマンス

    問題の種類

    メール通知での高CPU使用率。

  4. 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

  5. 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:

  6. 高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

  7. を使用して署名が正常にインストールされていることを確認します。 コールホーム診断署名を表示だ ステータス列の値が「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 では現在、新しいカスタム署名の作成リクエストをサポートしていません。

ローカル ゲートウェイとして CUBE の高可用性を実装する

基礎

前提条件

Webex Calling のローカル ゲートウェイとして CUBE HA を展開する前に、以下の概念を深く理解するようにしてください。

この記事で提供される構成ガイドラインは、既存の音声構成が設定されていない専用のローカル ゲートウェイ プラットフォームが使用されていることを前提としています。 既存の 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 設定ガイドを次に示します。

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

インターフェイスのステータスを追跡するために、グローバル レベルでインターフェイス トラッキングを構成します。

conf t
 track 1 interface GigabitEthernet1 line-protocol
 track 2 interface GigabitEthernet2 line-protocol
 exit


VCUBE-1#conf t

VCUBE-1(config)#track 1 interface GigabitEthernet1 line-protocol

VCUBE-1(config-track)#track 2 interface GigabitEthernet2 line-protocol

VCUBE-1(config-track)#exit

VCUBE-2#conf t

VCUBE-2(config)#track 1 interface GigabitEthernet1 line-protocol

VCUBE-2(config-track)#track 2 interface GigabitEthernet2 line-protocol

VCUBE-2(config-track)#exit

トラッキング CLI は、トラフィック インターフェイスがダウンした後、アクティブ ルートがアクティブな役割を果たすように、RG 内で音声トラフィックインターフェイスの状態を追跡するために使用されます。

2

アプリケーション冗長性サブモード下の VoIP HA で使用する RG を構成します。

redundancy
  application redundancy
   group 1
    name LocalGateway-HA
    priority 100 failover threshold 75
    control GigabitEthernet3 protocol 1
    data GigabitEthernet3
    timers delay 30 reload 60
    track 1 shutdown
    track 2 shutdown
    exit
   protocol 1
    timers hellotime 3 holdtime 10
   exit
  exit
 exit


VCUBE-1(config)#redundancy

VCUBE-1(config-red)#application redundancy

VCUBE-1(config-red-app)#group 1

VCUBE-1(config-red-app-grp)#name LocalGateway-HA

VCUBE-1(config-red-app-grp)#priority 100 failover threshold 75

VCUBE-1(config-red-app-grp)#control GigabitEthernet3 protocol 1

VCUBE-1(config-red-app-grp)#data GigabitEthernet3

VCUBE-1(config-red-app-grp)#timers delay 30 reload 60

VCUBE-1(config-red-app-grp)#track 1 shutdown

VCUBE-1(config-red-app-grp)#track 2 shutdown

VCUBE-1(config-red-app-grp)#exit

VCUBE-1(config-red-app)#protocol 1

VCUBE-1(config-red-app-prtcl)#timers hellotime 3 holdtime 10

VCUBE-1(config-red-app-prtcl)#exit

VCUBE-1(config-red-app)#exit

VCUBE-1(config-red)#exit

VCUBE-1(config)#

VCUBE-2(config)#redundancy

VCUBE-2(config-red)#application redundancy

VCUBE-2(config-red-app)#group 1

VCUBE-2(config-red-app-grp)#name LocalGateway-HA

VCUBE-2(config-red-app-grp)#priority 100 failover threshold 75

VCUBE-2(config-red-app-grp)#control GigabitEthernet3 protocol 1

VCUBE-1(config-red-app-grp)#data GigabitEthernet3

VCUBE-2(config-red-app-grp)#timers delay 30 reload 60

VCUBE-2(config-red-app-grp)#track 1 shutdown

VCUBE-2(config-red-app-grp)#track 2 shutdown

VCUBE-2(config-red-app-grp)#exit

VCUBE-2(config-red-app)#protocol 1

VCUBE-2(config-red-app-prtcl)#timers hellotime 3 holdtime 10

VCUBE-2(config-red-app-prtcl)#exit

VCUBE-2(config-red-app)#exit

VCUBE-2(config-red)#exit

VCUBE-2(config)#

この構成で使用されるフィールドの説明を次に示します。

  • redundancy—冗長性モードに入ります

  • application redundancy—アプリケーション冗長性構成モードに入ります

  • group—冗長性のあるアプリケーション グループ構成モードに入ります

  • name LocalGateway-HA— RG グループの名前を定義します

  • priority 100 failover threshold 75—RG の初期優先度とフェールオーバーしきい値を指定します

  • timers delay 30 reload 60—遅延およびリロードのため 2 回構成します

    • インターフェイスが起動した後、RG グループの初期設定と役割のネゴシエーションの遅延時間を示す遅延タイマーです。デフォルトは 30 秒です。 範囲は 0-10000 秒です

    • Reload—これは、リロード後の RG グループ初期設定と役割ネゴシエーションの遅延時間です。デフォルトは 60 秒です。 範囲は 0-10000 秒です

    • デフォルトのタイマーが推奨されていますが、これらのタイマーは、ネットワークのルーティングが安定した時点の後、RG プロトコルのネゴシエーションが行われることを保証するために、ルーターの起動/再読み込み中に発生する可能性がある追加のネットワーク集約遅延に合わせて調整される場合があります。 たとえば、フェールオーバー後に、新しいスタンバイに最大 20 秒間かかり、新しいアクティブから最初の RG HELLO パケットを確認する場合は、この遅延を考慮して、最初の RG HELLO パケットを「タイマー遅延 60 リロード 120」に調整する必要があります。

  • control GigabitEthernet3 protocol 1—keepalive および hello メッセージを 2 個の CUBE 間で交換するために使用されるインターフェイスを構成し、コントロール インターフェイスに接続するプロトコル インスタンスを指定し、冗長性アプリケーション プロトコル構成モードに入ります

  • data GigabitEthernet3—データ トラフィックのチェックポイントに使用されるインターフェイスを構成します

  • track—インターフェイスの RG グループ トラッキング

  • protocol 1—コントロール インターフェイスに接続するプロトコル インスタンスを指定し、冗長性のあるアプリケーション プロトコル構成モードに入ります

  • timers hellotime 3 holdtime 10—hellotime および holdtime の 2 つのタイマーを設定します

    • Hellotime— 連続する hello メッセージの間隔 (デフォルトで 3 秒)。 範囲は 250 ミリ秒から 254 秒です

    • Holdtime — Hello メッセージの受信と送信ルーターが失敗した推定の間隔。 この継続時間は、hello time (デフォルトの 10 秒より長くする必要があります) 以上である必要があります。 範囲は 750 ミリ秒から 255 秒です

      Holdtime タイマーを hellotime タイマーの最低 3 倍の値に設定することをお勧めします。

3

CUBE アプリケーションのボックス間の冗長性を有効にします。 以下の下にある以前の手順から RG を構成します： voice service voip です。 これにより、CUBE アプリケーションは冗長性プロセスをコントロールすることができます。 

voice service voip
   redundancy-group 1
   exit

VCUBE-1(config)#voice service voip

VCUBE-1(config-voi-serv)#redundancy-group 1

% Created RG 1 association with Voice B2B HA; reload the router for the new configuration to take effect

VCUBE-1(config-voi-serv)# exit

VCUBE-2(config)#voice service voip

VCUBE-2(config-voi-serv)#redundancy-group 1

% Created RG 1 association with Voice B2B HA; reload the router for the new configuration to take effect

VCUBE-2(config-voi-serv)# exit

redundancy-group 1—このコマンドを追加および削除するには、更新された構成を有効にするための再読み込みが必要です。 すべての構成が適用された後で、プラットフォームを再読み込みします。

4

以下に示すように、Gig1 と Gig2 インターフェイスをそれぞれの仮想 IP で構成し、冗長性インターフェイス識別子 (rii) を適用します。

VCUBE-1(config)#interface GigabitEthernet1

VCUBE-1(config-if)# redundancy rii 1

VCUBE-1(config-if)# redundancy group 1 ip 198.18.1.228 exclusive

VCUBE-1(config-if)# exit

VCUBE-1(config)#

VCUBE-1(config)#interface GigabitEthernet2

VCUBE-1(config-if)# redundancy rii 2

VCUBE-1(config-if)# redundancy group 1 ip 198.18.133.228 exclusive

VCUBE-1(config-if)# exit

VCUBE-2(config)#interface GigabitEthernet1

VCUBE-2(config-if)# redundancy rii 1

VCUBE-2(config-if)# redundancy group 1 ip 198.18.1.228 exclusive

VCUBE-2(config-if)# exit

VCUBE-2(config)#

VCUBE-2(config)#interface GigabitEthernet2

VCUBE-2(config-if)# redundancy rii 2

VCUBE-2(config-if)# redundancy group 1 ip 198.18.133.228 exclusive

VCUBE-v(config-if)# exit

この構成で使用されるフィールドの説明を次に示します。

  • redundancy rii—冗長性グループの冗長性インターフェイス ID を構成します。 仮想 MAC (VMAC) アドレスを生成するために必要です。 同じ VIP を持つ各ルーター (アクティブ/スタンバイ) のインターフェイスで同じ rii ID 値を使用する必要があります。


     

    同一の LAN に複数の B2B ペアがある場合、各ペアはそれぞれのインターフェイスで固有の rii Id を持つ必要があります (衝突を防ぐため)。 [冗長性アプリケーショングループのすべてを表示] が正しいローカルとピアの情報を示している必要があります。

  • redundancy group 1—上記の手順 2 で作成された冗長性グループにインターフェイスを関連付けます。 RG グループ、およびこの物理インターフェイスに割り当てられた VIP を構成します。


     

    冗長性のために別のインターフェイスを使用することが必須です。つまり、音声トラフィックに使用されるインターフェイスは、上記の手順 2 で指定したコントロールとデータ インターフェイスとして使用できません。 この例では、RG コントロール/データにギガビット インターフェイス 3 が使用されています。

5

最初の CUBE 構成を保存し、再読み込みします。

最後にリロードするプラットフォームは常にスタンバイです。

VCUBE-1#wr

Building configuration...

[OK]

VCUBE-1#reload

Proceed with reload? [confirm]

VCUBE-1 が完全に起動したら、 VCUBE-2 の構成を保存し、再読み込みします。

VCUBE-2#wr

Building configuration...

[OK]

VCUBE-2#reload

Proceed with reload? [confirm]
6

ボックス間の構成が期待どおりに機能していることを確認します。 関連する出力は太字で強調表示されます。

VCUBE-2 を最後にリロードし、設計上の考慮事項に従います。最後にリロードするプラットフォームは常に [スタンバイ] 状態です。


VCUBE-1#show redundancy application group all
Faults states Group 1 info:
       Runtime priority: [100]
               RG Faults RG State: Up.
                       Total # of switchovers due to faults:           0
                       Total # of down/up state changes due to faults: 0
Group ID:1
Group Name:LocalGateway-HA
  
Administrative State: No Shutdown
Aggregate operational state: Up
My Role: ACTIVE
Peer Role: STANDBY
Peer Presence: Yes
Peer Comm: Yes
Peer Progression Started: Yes

RF Domain: btob-one
         RF state: ACTIVE
         Peer RF state: STANDBY HOT

RG Protocol RG 1
------------------
        Role: Active
        Negotiation: Enabled
        Priority: 100
        Protocol state: Active
        Ctrl Intf(s) state: Up
        Active Peer: Local
        Standby Peer: address 10.1.1.2, priority 100, intf Gi3
        Log counters:
                role change to active: 1
                role change to standby: 1
                disable events: rg down state 0, rg shut 0
                ctrl intf events: up 1, down 0, admin_down 0
                reload events: local request 0, peer request 0

RG Media Context for RG 1
--------------------------
        Ctx State: Active
        Protocol ID: 1
        Media type: Default
        Control Interface: GigabitEthernet3
        Current Hello timer: 3000
        Configured Hello timer: 3000, Hold timer: 10000
        Peer Hello timer: 3000, Peer Hold timer: 10000
        Stats:
            Pkts 1509, Bytes 93558, HA Seq 0, Seq Number 1509, Pkt Loss 0
            Authentication not configured
            Authentication Failure: 0
            Reload Peer: TX 0, RX 0
            Resign: TX 0, RX 0
    Standy Peer: Present. Hold Timer: 10000
            Pkts 61, Bytes 2074, HA Seq 0, Seq Number 69, Pkt Loss 0

VCUBE-1#

VCUBE-2#show redundancy application group all
Faults states Group 1 info:
       Runtime priority: [100]
               RG Faults RG State: Up.
                       Total # of switchovers due to faults:           0
                       Total # of down/up state changes due to faults: 0
Group ID:1
Group Name:LocalGateway-HA
  
Administrative State: No Shutdown
Aggregate operational state: Up
My Role: STANDBY
Peer Role: ACTIVE
Peer Presence: Yes
Peer Comm: Yes
Peer Progression Started: Yes

RF Domain: btob-one
         RF state: ACTIVE
         Peer RF state: STANDBY HOT

RG Protocol RG 1
------------------
        Role: Active
        Negotiation: Enabled
        Priority: 100
        Protocol state: Active
        Ctrl Intf(s) state: Up
        Active Peer: address 10.1.1.2, priority 100, intf Gi3
        Standby Peer: Local
        Log counters:
                role change to active: 1
                role change to standby: 1
                disable events: rg down state 0, rg shut 0
                ctrl intf events: up 1, down 0, admin_down 0
                reload events: local request 0, peer request 0

RG Media Context for RG 1
--------------------------
        Ctx State: Active
        Protocol ID: 1
        Media type: Default
        Control Interface: GigabitEthernet3
        Current Hello timer: 3000
        Configured Hello timer: 3000, Hold timer: 10000
        Peer Hello timer: 3000, Peer Hold timer: 10000
        Stats:
            Pkts 1509, Bytes 93558, HA Seq 0, Seq Number 1509, Pkt Loss 0
            Authentication not configured
            Authentication Failure: 0
            Reload Peer: TX 0, RX 0
            Resign: TX 0, RX 0
    Standy Peer: Present. Hold Timer: 10000
            Pkts 61, Bytes 2074, HA Seq 0, Seq Number 69, Pkt Loss 0

VCUBE-2#

両方の CUBE でローカル ゲートウェイを構成する

この例の構成では、Control Hub から以下のトランク情報を使用して、VCUBE-1、VCUBE-2 の両方のプラットフォームでローカルゲートウェイを構成しています。 この設定のユーザー名とパスワードは以下のとおりです。

  • ユーザー名: フセイン1076_LGU

  • パスワード: lOV12MEaZx

1

クレデンシャルまたは共有秘密で使用する前に、以下のコマンドを使用して、設定キーがパスワードに対して作成されていることを確認してください。 Type 6 パスワードは、AES 暗号化とこのユーザー定義の設定キーを使用して暗号化されます。


LocalGateway#conf t
LocalGateway(config)#key config-key password-encrypt Password123
LocalGateway(config)#password encryption aes

これは、上に表示されている Control Hub のパラメーターに基づき、両方のプラットフォームに適用し、保存し、リロードするローカ ルゲートウェイの構成です。 Control Hub からの SIP ダイジェスト クレデンシャルは太字でハイライトされています。


configure terminal
crypto pki trustpoint dummyTp
revocation-check crl
exit
sip-ua
crypto signaling default trustpoint dummyTp cn-san-validate server
transport tcp tls v1.2
end


configure terminal
crypto pki trustpool import clean url
http://www.cisco.com/security/pki/trs/ios_core.p7b
end


configure terminal
voice service voip
  ip address trusted list
    ipv4 x.x.x.x y.y.y.y
    exit
   allow-connections sip to sip
  media statistics
  media bulk-stats
  no supplementary-service sip refer
  no supplementary-service sip handle-replaces
  fax protocol pass-through g711ulaw
  stun
    stun flowdata agent-id 1 boot-count 4
    stun flowdata shared-secret 0 Password123!
  sip
    g729 annexb-all
    early-offer forced
    end


configure terminal
voice class sip-profiles 200
  rule 9 request ANY sip-header SIP-Req-URI modify "sips:(.*)"
"sip:\1"
  rule 10 request ANY sip-header To modify "<sips:(.*)" "<sip:\1"
  rule 11 request ANY sip-header From modify "<sips:(.*)" "<sip:\1"
  rule 12 request ANY sip-header Contact modify "<sips:(.*)>"
"<sip:\1;transport=tls>"
  rule 13 response ANY sip-header To modify "<sips:(.*)" "<sip:\1"
  rule 14 response ANY sip-header From modify "<sips:(.*)" "<sip:\1"
  rule 15 response ANY sip-header Contact modify "<sips:(.*)"
"<sip:\1"
  rule 20 request ANY sip-header From modify ">"
";otg=hussain1076_lgu>"
  rule 30 request ANY sip-header P-Asserted-Identity modify
"sips:(.*)" "sip:\1"


voice class codec 99
  codec preference 1 g711ulaw
  codec preference 2 g711ulaw
  exit

voice class srtp-crypto 200
  crypto 1 AES_CM_128_HMAC_SHA1_80
  exit

voice class stun-usage 200
  stun usage firewall-traversal flowdata
  exit






voice class tenant 200
  registrar dns:40462196.cisco-bcld.com scheme sips expires 240
refresh-ratio 50 tcp tls
  credentials number Hussain5091_LGU username Hussain1076_LGU
password 0 lOV12MEaZx realm Broadworks 
  authentication username Hussain5091_LGU password 0 lOV12MEaZx
realm BroadWorks

  authentication username Hussain5091_LGU password 0 lOV12MEaZx
realm 40462196.cisco-bcld.com
  no remote-party-id
  sip-server dns:40462196.cisco-bcld.com
  connection-reuse
  srtp-crypto 200
  session transport tcp tls
  url sips
  error-passthru
  asserted-id pai
  bind control source-interface GigabitEthernet1
  bind media source-interface GigabitEthernet1
  no pass-thru content custom-sdp
  sip-profiles 200
  outbound-proxy dns:la01.sipconnect-us10.cisco-bcld.com
  privacy-policy passthru


voice class tenant 100
  session transport udp
  url sip
  error-passthru
  bind control source-interface GigabitEthernet2
  bind media source-interface GigabitEthernet2
  no pass-thru content custom-sdp

voice class tenant 300
  bind control source-interface GigabitEthernet2
  bind media source-interface GigabitEthernet2
  no pass-thru content custom-sdp
  

voice class uri 100 sip
 host ipv4:198.18.133.3

voice class uri 200 sip
 pattern dtg=hussain1076.lgu



dial-peer voice 101 voip
 description Outgoing dial-peer to IP PSTN
 destination-pattern BAD.BAD
 session protocol sipv2
 session target ipv4:198.18.133.3
 voice-class codec 99
 voice-class sip tenant 100
 dtmf-relay rtp-nte
 no vad

dial-peer voice 201 voip
 description Outgoing dial-peer to Webex Calling
 destination-pattern BAD.BAD
 session protocol sipv2
 session target sip-server
 voice-class codec 99
 voice-class stun-usage 200
 no voice-class sip localhost
 voice-class sip tenant 200
 dtmf-relay rtp-nte
 srtp
 no vad


voice class dpg 100
 description Incoming WebexCalling(DP200) to IP PSTN(DP101)
 dial-peer 101 preference 1

voice class dpg 200
 description Incoming IP PSTN(DP100) to Webex Calling(DP201)
 dial-peer 201 preference 1





dial-peer voice 100 voip
 desription Incoming dial-peer from IP PSTN
 session protocol sipv2
 destination dpg 200
 incoming uri via 100
 voice-class codec 99
 voice-class sip tenant 300
 dtmf-relay rtp-nte
 no vad

dial-peer voice 200 voip
 description Incoming dial-peer from Webex Calling
 session protocol sipv2
 destination dpg 100
 incoming uri request 200
 voice-class codec 99
 voice-class stun-usage 200
 voice-class sip tenant 200
 dtmf-relay rtp-nte
 srtp
 no vad

end

copy run start

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-1#show redundancy application group 1
Group ID:1
Group Name:LocalGateway-HA

Administrative State: No Shutdown
Aggregate operational state : Up
My Role: Standby
Peer Role: ACTIVE
Peer Presence: Yes
Peer Comm: Yes
Peer Progression Started: Yes

RF Domain: btob-one
         RF state: STANDBY HOT
         Peer RF state: ACTIVE

VCUBE-1#show sip-ua register status
VCUBE-1#


VCUBE-2#show redundancy application group 1
Group ID:1
Group Name:LocalGateway-HA

Administrative State: No Shutdown
Aggregate operational state : Up
My Role: ACTIVE
Peer Role: STATUS
Peer Presence: Yes
Peer Comm: Yes
Peer Progression Started: Yes

RF Domain: btob-one
         RF state: ACTIVE
         Peer RF state: STANDBY HOT

VCUBE-2#show sip-ua register status

Tenant: 200
--------------------Registrar-Index  1 ---------------------
Line                           peer       expires(sec) reg survival P-Associ-URI
============================== ========== ============ === ======== ============
Hussain5091_LGU                -1          48          yes normal
VCUBE-2#

上記の出力から、 VCUBE-2 がアクティブ LGW で、Webex Calling アクセス SBC への登録を維持していることがわかります。しかし、「show sip-ua register status」の出力は VCUBE-1 では空です

3

VCUBE-1 で次のデバッグを有効にします


VCUBE-1#debug ccsip non-call
SIP Out-of-Dialog tracing is enabled
VCUBE-1#debug ccsip info
SIP Call info tracing is enabled
VCUBE-1#debug ccsip message
4

この場合、アクティブ LGW、VCUBE-2 で次のコマンドを実行してフェールオーバーをシミュレートします。


VCUBE-2#redundancy application reload group 1 self

アクティブからスタンバイ LGW への切り替えは、上記に一覧表示されている CLI に加えて、以下のシナリオで発生します。

  • アクティブ ルーターのリロード時

  • アクティブなルーターの電源が再投入される時

  • トラッキングが有効になっているアクティブなルーターの RG 構成されたインターフェイスがシャットダウンされる時

5

VCUBE-1 が Webex Calling アクセス SBC に登録されているかどうかを確認します。 VCUBE-2 は今すぐにリロードされます。


VCUBE-1#show sip-ua register status

Tenant: 200
--------------------Registrar-Index  1 ---------------------
Line                           peer       expires(sec) reg survival P-Associ-URI
============================== ========== ============ === ======== ============
Hussain5091_LGU                -1          56          yes normal
VCUBE-1#

VCUBE-1 がアクティブ LGW になりました。

6

仮想 IP を通じて SIP REGISTER を Webex Calling に送信し、200 OK を受信する VCUBE-1 に関連するデバッグ ログを確認してください。


VCUBE-1#show log

Jan 9 18:37:24.769: %RG_MEDIA-3-TIMEREXPIRED: RG id 1 Hello Time Expired.
Jan 9 18:37:24.771: %RG_PROTCOL-5-ROLECHANGE: RG id 1 role change from Standby to Active
Jan 9 18:37:24.783: %VOICE_HA-2-SWITCHOVER_IND: SWITCHOVER, from STANDBY_HOT to ACTIVE state.
Jan 9 18:37:24.783: //-1/xxxxxxxxxxxx/SIP/Info/info/4096/sip_ha_notify_active_role_event: Received notify active role event

Jan 9 18:37:25.758: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
REGISTER sip: 40462196.cisco-bcld.com:5061 SIP/2.0
Via: SIP/2.0/TLS 198.18.1.228:5061;branch=z9hG4bK0374
From: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189
To: <sip:Hussain5091_LGU@40462196.cisco-bcld.com>
Date: Thu, 09 Jan 2020 18:37:24 GMT
Call-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97
User-Agent: Cisco-SIPGateway/IOS-16.12.02
Max-Forwards: 70
Timestamp: 1578595044
CSeq: 2 REGISTER
Contact: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls>
Expires: 240
Supported: path
Content-Length: 0


Jan 9 18:37:25.995: //-1/000000000000/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 401 Unauthorized
Via: SIP/2.0/TLS 198.18.1.228:5061;received=173.38.218.1;branch=z9hG4bK0374;rport=4742
From: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189
To: <sip:Hussain5091_LGU@40462196.cisco-bcld.com>;tag=SD1u8bd99-1324701502-1578595045969
Date: Thu, 09 Jan 2020 18:37:24 GMT
Call-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97
Timestamp: 1578595044
CSeq: 2 REGISTER
WWW-Authenticate; DIGEST realm="BroadWorks",qop="auth",nonce="BroadWorksXk572qd01Ti58zliBW",algorithm=MD5
Content-Length: 0


Jan 9 18:37:26.000: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
REGISTER sip:40462196.cisco-bcld.com:5061 SIP/2.0
Via: SIP/2.0/TLS 198.18.1.228:5061;branch=z9hG4bK16DC
From: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189
To: <sip:Hussain5091_LGU@40462196.cisco-bcld.com>
Date: Thu, 09 Jan 2020 18:37:25 GMT
Call-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97
User-Agent:Cisco-SIPGateway/IOS-16.12.02
Max-Forwards: 70
Timestamp: 1578595045
CSeq: 3 REGISTER
Contact: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls>
Expires: 240
Supported: path
Authorization: Digest username="Hussain1076_LGU",realm="BroadWorks",uri="sips:40462196.cisco-bcld.com:5061",response="b6145274056437b9c07f7ecc08ebdb02",nonce="BroadWorksXk572qd01Ti58z1iBW",cnonce="3E0E2C4D",qop=auth,algorithm=MD5,nc=00000001
Content-Length: 0


Jan 9 18:37:26.190: //1/000000000000/SIP/Msg/ccsipDisplayMsg:

Received:
SIP/2.0 200 OK
Via: SIP/2.0/TLS 198.18.1.228:5061;received=173.38.218.1;branch=z9hG4bK16DC;rport=4742
From: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189
To: <sip:Hussain5091_LGU@40462196.cisco-bcld.com>;tag=SD1u8bd99-1897486570-1578595-46184
Call-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97
Timestamp: 1578595045
CSeq: 3 REGISTER
Contact: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls>;expires=120;q=0.5
Allow-Events: call-info,line-seize,dialog,message-summary,as-feature-event,x-broadworks-hoteling,x-broadworks-call-center-status,conference
Content-Length: 0
Webex Calling のために Unified CM を構成する

ローカル ゲートウェイへトランクするための SIP トランク セキュリティ プロファイルを構成する

ローカル ゲートウェイと PSTN ゲートウェイが同じデバイス上に存在する場合、Unified CM を有効にして、同じデバイスから発信された 2 個の異なるトラフィックの種類 (Webex と PSTN のコール) を区別し、これらのコール タイプに対して差別化されたクラスのサービスを適用する必要があります。 この差別化されたコール処理は、Unified CM および結合されたローカル ゲートウェイと PSTN ゲートウェイ デバイスの 2 つのトランクをプロビジョニングすることで行われます。これは、2 つのトランクに異なる SIP リスニング ポートを必要とします。

次の設定でローカル ゲートウェイ トランクの専用の SIP トランク セキュリティ プロファイルを作成します。

設定値
名前固有の名前 (Webex など)
説明Webex SIP トランク セキュリティ プロファイルなどの意味のある説明
着信ポートWebex 間のトラフィックでは、ローカル ゲートウェイ構成で使用されるポートと一致する必要があります。 5065

ローカル ゲートウェイ トランクの SIP プロファイルを構成する

次の設定でローカル ゲートウェイ トランク用の専用の SIP プロファイルを作成します。

設定値
名前固有の名前 (Webex など)
説明意味のある説明 (Webex SIP プロファイルなど)
オプションの Ping を有効にして、サービス タイプ「なし (デフォルト)」のトランクの宛先ステータスをモニタします。選択

Webex からのコールのコール検索スペースを作成する

次の設定で Webex から発信されたコールのためのコール検索スペースを作成します。

設定値
名前固有の名前 (Webex など)
説明意味のある説明 (Webex Calling 検索スペースなど)
選択済みパーティション:

DN (+E.164 ディレクトリ番号)

ESN (省略形のサイトダイヤル)

PSTNInternational (PSTN アクセス)

onNetRemote (GDPR 学習先)


 

最後のパーティション onNetRemote は、Intercluster Lookup Service (ILS) または Global Dialplan Replication (GDPR) を使用して、Unified CM クラスター間でルーティング情報が交換されるマルチクラスター環境でのみ使用されます。

Webex 間で SIP トランクを構成する

次の設定を使用して、ローカル ゲートウェイ経由での Webex 間のコールに SIP トランクを作成します。

設定値
デバイス情報
DeviceName固有の名前 (Webex など)
説明意味のある説明 (Webex SIP トランク など)
すべてのアクティブな Unified CM ノード上で実行する選択
着信コール
コール検索スペース以前に定義されたコール検索スペース: Webex
AAR コール検索スペースPSTN ルート パターンへのアクセス権のみを持つコール検索スペース: PSTNReroute
SIP 情報
接続先アドレスローカル ゲートウェイ CUBE の IP アドレス
移動先ポート5060
SIP トランク セキュリティ プロファイル定義済み: Webex
SIP プロファイル定義済み: Webex

Webex のルート グループを構成する

次の設定でルート グループを作成します。

設定値
ルート グループ情報
ルート グループ名固有の名前 (Webex など)
選択したデバイス以前に構成された SIP トランク: Webex

Webex のルート リストを構成する

次の設定でルート リストを作成します。

設定値
ルート リスト情報
名前一意の名前 (RL_Webex など)
説明意味のある説明 (Webex のルート リストなど)
すべてのアクティブな Unified CM ノード上で実行する選択
ルート リスト メンバー情報
選択したグループ以前に定義されたルート グループのみ: Webex

Webex の移動先のパーティションを作成する

次の設定で Webex の移動先のパーティションを作成します。

設定値
ルート リスト情報
名前固有の名前 (Webex など)
説明意味のある説明 (Webex のパーティションなど)

次に行うこと

このパーティションは、Webex の宛先にアクセスする必要があるすべてのコール検索スペースに追加してください。 このパーティションは、PSTN から Webex への発信がルーティングされるように、PSTN トランクの着信コール検索スペースとして使用されるコール検索スペースに特に追加する必要があります。

Webex の移動先のルート パターンを構成する

次の設定で Webex の各 DID 範囲のルート パターンを構成します。

設定値
ルートパターン「\」が頭文字にある Webex で DID 範囲のフル +E.164 パターン 例: \+140855501XX
ルート パーティションWebex
ゲートウェイ/ルート リストRL_Webex
緊急の優先事項選択

Webex の簡略サイト間ダイヤル正規化を構成する

短縮されたサイト間ダイヤルが Webex に必要な場合は、Webex の各 ESB 範囲にダイヤル正規化パターンを設定します。

設定値
翻訳パターンWebex の ESN 範囲の ESB パターン。 例: 80121XX
パーティションWebex
説明Webex の正規化パターンなどの意味のある説明
発信者のコール検索スペースを使用する選択
緊急の優先事項選択
後続ホップでの連続桁のタイムアウトを待たない選択
着信側トランスフォーム マスク番号を + E.164 に正規化するマスク。 例: +140855501XXさん

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

このユーザーがコールに割り込むときに他のユーザーにトーンを再生する場合は、[このユーザーがコールで割り込むときにトーンを再生] にチェックを入れます。

6

[保存] をクリックします。

ユーザーのプライバシーを有効にする

1

Control Hubにサインインし、管理 > ユーザー。

2

ユーザーを選択し、[Calling] をクリックします。

3

［ユーザー権限間］領域に移動し、［プライバシー］を選択します。

4

このユーザーに適切な　[自動音声応答のプライバシー] 設定を選択します。

  • このユーザーへの内線でのダイヤルを許可
  • このユーザーの名前/姓でのダイヤルを許可
5

[プライバシーを有効にする] チェックボックスをオンにします。 ドロップダウンリストからメンバーを選択しないことで、全員をブロックすることができます。 または、このユーザーの回線ステータスを監視できるユーザー、ワークスペース、仮想回線を選択することもできます。

ロケーション管理者の場合、割り当てられたロケーションに関連するユーザー、ワークスペース、仮想回線だけがドロップダウン リストに表示されます。

[プライバシーを有効にする] チェックボックスをオフにすると、全員が回線のステータスを監視できるようになります。

6

ダイレクト コール ピックアップと割り込みのプライバシーを有効にするには、[ダイレクト コール ピックアップと割り込みのプライバシーを強制] チェックボックスをオンにします。


 
  • このオプションを有効にすると、このユーザーに対してダイレクト コール ピックアップと割り込みを使用できるのは、許可されたユーザー、仮想回線、およびワークスペース デバイスだけです。 それ以外の場合、組織内の誰もが、ダイレクト コール ピックアップと割り込みを回線上で呼び出すことができます。
  • 割り込みの詳細については、他のユーザーの電話での割り込みを参照してください。
  • スーパーバイザは、エージェントがコール キューを介して受信するコールに常に割り込むことができます。 つまり、プライバシー設定はスーパーバイザの割り込みオプションには影響しません。
7

[名前でメンバーを追加] から、電話回線のステータスを監視し、ダイレクト コール ピックアップと割り込みを呼び出せるユーザ、ワークスペース、仮想回線を選択します。

8

選択したメンバーをフィルタリングするには、［名前、番号、またはextでフィルタリング］フィールドを使用します。

9

選択したすべてのメンバーを削除するには、［すべて削除］をクリックします。


 
個々のメンバーを削除するには、メンバー名の横にある [削除] をクリックします。
10

[保存] をクリックします。

Privacy settings

モニタリングの設定

ユーザーの監視対象回線の最大数は 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）] フィールドに入力された名前です。

実際の例を見てみましょう。 これを視聴するビデオデモンストレーションでユーザーの監視設定を管理する方法コントロールハブを選択します。

ユーザーのコール ブリッジ警告トーンを有効にする

始める前に

呼び出されるCall Bridge用に共有回線を設定しておく必要があります。 参加方法を共有回線の設定必要に応じて、Call Bridge警告音の再生を有効にしてください。
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

通話履歴の詳細レポートを参照するには、コントロールハブを表示し、次に移動します。分析次のリンクをクリックしてください:電話を選択します。

2

選択詳細な通話履歴を選択します。

専用インスタンスを使用する通話の詳細については、「専用インスタンスの分析」を参照してください。

3

メディア品質データにアクセスするには、Control Hub にサインインし、[アナリティクス] に移動して、[Calling] を選択します。

詳細については、「クラウド コラボレーション ポートフォリオのためのアナリティクス」を参照してください。
Webex Calling の概要

エンタープライズグレードのクラウド通話、モビリティ、PBX機能に加えて、メッセージングや会議用のWebexアプリや、ソフトクライアントやCiscoデバイスからの通話ができることを想像してみてください。Webex Calling Webex Callingそれこそまさにあなたに提供できるものです。

Webex Callingには、次の機能と利点があります。

  • テレフォニーユーザーおよび共用エリアの通話契約。

  • 信頼できる地域のサービスプロバイダーが提供する安全で信頼性の高いクラウドサービス

  • すべてのユーザーがWebexアプリにアクセスし、豊富なユニファイドコミュニケーションとチームコラボレーションサービスを追加します。

  • Webex Meetingsは、企業ユーザーが期待するプレミアムな会議体験を提供するためのオプションの統合アドオンです。

  • 公衆電話交換網（PSTN）にアクセスして、ユーザーが組織外の番号をダイヤルできるようにします。 このサービスは、既存の企業インフラを通じて提供されます

    • オンプレミスのIP PBXを使用しないローカルゲートウェイ

    • Unified CM既存の通話環境

    • パートナーまたはシスコが提供する PSTN オプション

  • パートナーが提供するティア1のサポート、シスコが提供する次のレベルのサポート

Control HubはWebベースの管理ポータルで、Webex Calling統合して注文や設定を合理化し、バンドルオファー、Webex Calling Webexアプリなどの管理を一元化します。Webex Meetings

テーブル 1.管理者が設定可能な機能

特集

説明

オートアテンダント

あいさつを追加したり、メニューを設定したり、留守番電話、ハントグループ、留守番電話ボックス、または実在の人物に電話をかけたりすることができます。 24時間のスケジュールを作成したり、営業中や営業終了時にさまざまなオプションを提供したりできます。 発信者IDの属性に基づいて通話をルーティングしてVIPリストを作成したり、特定の市外局番からの通話を別の方法で処理したりすることもできます。

コールキュー

着信に応答できないときは、コールキューを設定できます。 自動応答、コンフォートメッセージ、誰かが電話に出られるまで保留音を発信者に伝えることができます。

コールピックアップ

コールピックアップグループを作成して、ユーザーが他のユーザーの電話に応答できるようにすることで、チームワークとコラボレーションを強化できます。 コールピックアップグループにユーザーを追加したときに、グループのメンバーが留守中または話中の場合、別のメンバーが通話に応答できます。

コールパーク

コールパークを有効にして、ユーザーが通話を保留にして別の電話から応答できるようにすることができます。

ハントグループ

次のようなシナリオでは、ハントグループを設定したほうがいいかもしれません。

  • シーケンシャルルーティングを希望する営業チーム。 着信があると、1台の電話が鳴りますが、応答がない場合、その電話はリストの次のエージェントに送られます。

  • サポートチームが、最初に空いているエージェントが電話に出られるように、すべての電話を一度に鳴らしたいと思っています。

ページンググループ

ページンググループを作成して、ユーザーが個人、部門、またはチームに音声メッセージを送信できるようにすることができます。 誰かがページンググループにメッセージを送信すると、そのメッセージはグループ内のすべてのデバイスで再生されます。

受付のクライアント

フルセットの通話制御オプション、大規模な回線監視、通話キューイング、複数のディレクトリオプションとビュー、Outlook統合などを提供することで、フロントオフィス担当者のニーズをサポートします。
テーブル 2.ユーザーが設定可能な機能

特集

説明

匿名通話拒否

ユーザーは、ブロックされた発信者IDで着信を拒否できます。

事業継続性

停電やネットワークの問題などの理由でユーザーの電話がネットワークに接続されていない場合、ユーザーは着信通話を特定の電話番号に転送できます。

電話転送

ユーザーは着信通話を別の電話に転送できます。

コール転送セレクティブ

ユーザーは、特定の時間に、特定の発信者からの通話を転送できます。 この設定は着信転送よりも優先されます。

コール通知

ユーザーは、電話番号や日付と時刻などのあらかじめ定義された基準に従って、電話を受けたときに自分宛にメールを送信できます。

電話待ち

ユーザーは、追加の着信に応答できます。

邪魔しないで

ユーザーは一時的にすべての通話をボイスメールに直接送ることができます。

オフィスならどこでも

ユーザーは、選択した電話（「場所」）を会社の電話番号とダイヤルプランの延長として使用できます。

プライオリティアラート

ユーザーは、電話番号や日付と時刻など、あらかじめ定義された条件が満たされると、独特の呼び出し音で電話をかけることができます。

リモートオフィス

ユーザーはリモート電話から電話をかけて、自分のビジネス回線から電話をかけてもらうことができます。 さらに、相手のビジネスラインへの着信はすべてこのリモート電話で鳴ります。

セレクティブコール受け付け

ユーザーは、特定の時間に、特定の発信者からの電話を受け入れることができます。

選択的通話拒否

ユーザーは、特定の時間に、特定の発信者からの通話を拒否できます。

シーケンシャルリング

着信用に最大5台のデバイスを次々に呼び出してください。

同時リング

着信時に、ユーザーと他の人（「受信者」）の番号を同時に呼び出します。

Control Hubでのサービス、デバイス、ユーザーのプロビジョニング、Calling Admin Portalでの詳細設定へのクロス起動

Control Hub（https://admin.webex.com）は、Webex Callingを統合して注文や設定を合理化し、バンドルオファー、WebexアプリWebex Calling、会議の管理を一元化できる管理ポータルです。

コントロールハブは、すべてのサービス、デバイス、ユーザーをプロビジョニングするための中心点です。 通話サービスの初回設定、クラウドへのMPP電話の登録（MACアドレス使用）、デバイスの関連付け、番号、サービス、通話機能の追加などによるユーザー設定を行うことができます。 また、コントロールハブから、コーリング管理者ポータルへの相互起動も可能です。

ユーザーエクスペリエンス

ユーザーは次のインターフェースにアクセスできます。

  • Webex Callingアプリケーション：Ciscoブランドの通話用のソフトクライアント。 詳細については、「Cisco Webex Calling新しいアプリを探検してください」を参照してください。

  • Webex Settings（https://settings.webex.com）—ユーザーがプロファイルのプリファレンスを設定したり、Webexアプリをダウンロードしたり、通話設定のために通話ユーザーポータルにクロス起動したりできるインターフェイス。 詳細については、「Cisco Webex設定を変更する」を参照してください。

  • Webex App — シスコブランドのチームメッセージングクライアントとしてサブスクリプションに含まれるアプリケーション。 詳細については、「Cisco Webexアプリ入門」を参照してください。

  • Webex Meetings—会議ソリューションとしてオプションのアプリケーションが追加されました。 詳細については、を参照してくださいWebex Meetings。

顧客管理者

の試用版または有料サブスクリプションの顧客管理者はWebex Calling、場所、ライセンス、電話番号、通話機能、ユーザー、ワークスペース（Webex クラウドに登録するルームデバイス）を追加することで、Control Hubで組織を設定できます。 そこから、これらすべてのコンポーネントを管理することもできます。

パートナー

パートナーサービスプロバイダーとして、ブランディング、マーケティング、Webex Calling顧客への販売を行うことができます。 トライアルの設定と延長、顧客へのサービスの展開、顧客向けの注文の作成とプロビジョニングを行うことができます。

空室状況

Cisco Webex販売可能な国については、「販売場所Webex Calling」Webex Calling 記事のヘッダーを参照してください。

コントロールハブのツアーに参加してください

Control Hubは、組織の管理、ユーザーの管理、サービスの割り当て、採用傾向や通話品質の分析などを行うための、頼りになるウェブベースのインターフェイスです。

Control Hub interface overview highlighting and labeling the left navigation menu, company information, notifications, in-app help, feedback, language, and sign out.

組織を立ち上げて運営するために、Control Hub にメールアドレスを入力して、数人のユーザーを Webex アプリに招待することをお勧めします。 電話など、あなたが提供するサービスを人々に利用してもらい、その体験についてフィードバックをもらってください。 準備ができたら、いつでもユーザーを追加できます。

  • コントロールハブは Mozilla Firefox 66 以降、Google Chrome 89 以降、Microsoft Edge 89 以降、Apple Safari 15.1 以降を完全にサポートしています。
  • コントロールハブはサポートしていませんInternet Explorer。
  • Control Hubはモバイルデバイス向けには設計されていません。

以下に示す情報を、組織にサービスを導入する際に期待できることの大まかな概要として使用してください。 より詳細な情報とステップバイステップの説明については、個々の章を参照してください。

始めましょう

パートナーがアカウントを作成すると、ウェルカムメールが届きます。 メールに記載されている「はじめに」リンクをクリックし、ChromeまたはFirefoxを使用してコントロールハブにアクセスします。 リンクをクリックすると、管理者のメールアドレスで自動的にサインインします。 次に、管理者パスワードを作成するように求められます。

Create a new password screen from getting started email for Control Hub setup.

初めてのトライアルの魔法使い

パートナーがあなたをトライアルに登録している場合は、Control Hub にサインインすると、セットアップウィザードが自動的に起動します。 ウィザードの指示に従って、Webex Calling組織を立ち上げて運営するための基本設定など、さまざまなサービスが用意されています。 ウィザードのウォークスルーを終了する前に、通話設定を設定して確認できます。

First time setup wizard for Control Hub.

設定を見直してください

コントロールハブが読み込まれたら、設定を確認できます。

Control Hub overview page.

ユーザーを追加してください

サービスの設定が完了したので、会社のディレクトリから人を追加する準備が整いました。 [ユーザー] > [ユーザー管理] に移動します。

Manage users popup window in Control Hub.

を使用する場合はMicrosoft Active Directory、最初にディレクトリ同期を有効にしてから、ユーザーの追加方法を決定することをお勧めします。 「次へ」をクリックし、指示に従ってCiscoディレクトリコネクタを設定します。

シングルサインオン（SSO）を設定する

Webex アプリは基本認証を使用します。SSOを設定して、ユーザーがWebexに保存および管理されている個別のパスワードではなく、エンタープライズ認証情報を使用してエンタープライズIDプロバイダーで認証されるようにすることができます。

[設定] > [認証] > [変更] に移動し、[サードパーティのIDプロバイダーを統合する] を選択します。

Single sign-on settings screen with 'Integrate a 3rd-party provider' option selected.

ユーザーにサービスを割り当てる

追加したユーザーにサービスを割り当てて、他のユーザーが Webex App を使い始められるようにする必要があります。

「ユーザー」>「ユーザー管理」> CSVファイルを使用してユーザーをエクスポート/インポートし、「エクスポート」をクリックします。

ダウンロードしたファイルに、各ユーザーに割り当てるサービスをTrueと入力してください。

CSV file example for assigning services to users in Control Hub.

完成したファイルをインポートし、「サービスの追加と削除」をクリックして、「送信」をクリックします。 これで、通話機能を設定し、共通の場所で共有できるデバイスを登録し、デバイスを登録してユーザーに関連付ける準備ができました。

ユーザーに力を与える

ユーザーを追加してサービスを割り当てたので、ユーザーはサポートされているマルチプラットフォーム電話（MPP）Webex Callingをメッセージングや会議にWebexアプリで使用できるようになります。 設定にアクセスするためのワンストップショップとして利用するように勧めてください。

ローカルゲートウェイの役割

ローカルゲートウェイは、公衆電話交換網（PSTN）インターワーキングおよび従来の公共支店交換機（PBX）インターワーキング（を含む）のための、企業またはパートナーが管理するエッジデバイスです。Unified CM

コントロールハブを使用してローカルゲートウェイをロケーションに割り当てることができます。その後、コントロールハブはCUBE上で設定できるパラメータを提供します。 これらの手順では、ローカルゲートウェイをクラウドに登録し、Webex Callingゲートウェイを介して特定の場所のユーザーにPSTNサービスを提供します。

ローカルゲートウェイを指定して注文するには、ローカルゲートウェイ注文ガイドを読んでください。

でサポートされるローカルゲートウェイのデプロイメント Webex Calling

次の基本的な導入がサポートされています。

ローカルゲートウェイは、スタンドアロンで導入することも、Cisco Unified Communications Managerへの統合が必要な展開で導入することもできます。

オンプレミスのIP PBXを使用しないローカルゲートウェイの展開

スタンドアロンのローカルゲートウェイのデプロイメント

この図は、既存のIP Webex Calling PBXがない展開を示しており、単一ロケーションまたは複数ロケーションの導入に適用できます。

Illustration showing a Webex Calling deployment without any existing IP PBX.

Webex Calling宛先と一致しないすべての通話について、Webex Callingそれらの通話をその場所に割り当てられているローカルゲートウェイに送信して処理します。 ローカルゲートウェイは、Webex Calling発信されたすべてのコールをPSTNにルーティングし、反対方向、PSTNにルーティングします。Webex Calling

PSTNゲートウェイは、専用プラットフォームにすることも、ローカルゲートウェイと共存させることもできます。 次の図のように、この展開では専用のPSTNゲートウェイバリアントをお勧めします。既存のPSTNゲートウェイをローカルゲートウェイとして使用できない場合に使用できます。Webex Calling

Illustration showing the recommended PSTN gateway variant deployment option, able to be used if the existing PSTN gateway cannot be used as a Webex Calling local gateway.

共存ローカルゲートウェイの導入

ローカルゲートウェイは、IPベース、SIPトランクを使用してITSPに接続するか、ISDNまたはアナログ回路を使用してTDMベースにすることができます。 次の図は、ローカルゲートウェイがPSTN Webex Calling GW/SBCと共存する配置を示しています。

Illustration showing a Webex Calling deployment where the local gateway is coresident with the PSTN GW/SBC.

Unified CMオンプレミスPBXによるローカルゲートウェイの展開

Unified CM次の場合はとの統合が必要です。

  • Webex Calling対応ロケーションは、Cisco UCUnified CMオンプレミスの通話制御ソリューションとして導入されている既存の導入環境に追加されます

  • Webex Calling登録されている電話とロケーションにある電話を直接ダイヤルする必要があります。Unified CM

この図は、Unified CMお客様が既存のIP Webex Calling PBXを持っている展開を示しています。

Illustration showing a Webex Calling deployment where the customer has an existing Unified CM IP PBX.

Webex CallingWebex Callingお客様の宛先と一致しない通話をローカルゲートウェイに送信します。 これには、Unified CM PSTN番号と内部内線番号が含まれますが、Webex Callingこれらは表示されません。 ローカルゲートウェイは、Webex Calling着信したすべての通話をへUnified CM、またはその逆にルーティングします。 Unified CM次に、既存のダイヤルプランに従って、着信通話を現地の宛先またはPSTNにルーティングします。 Unified CMダイヤルプランは番号を+E.164として正規化します。 PSTNゲートウェイは、専用のゲートウェイでも、ローカルゲートウェイと共存していてもかまいません。

専用PSTNゲートウェイ

この図に示すように、この導入の専用PSTNゲートウェイバリアントが推奨オプションで、既存のPSTNゲートウェイをローカルゲートウェイとして使用できない場合に使用できます。Webex Calling

Illustration showing the dedicated PSTN gateway variant; the recommended option that can be used if the existing PSTN gateway cannot be used as a Webex Calling local gateway.

PSTNゲートウェイ共同社長

この図は、Webex CallingUnified CMローカルゲートウェイがPSTNゲートウェイ/SBCと共存する配置を示しています。

Webex CallingWebex Callingお客様の宛先と一致しないすべての通話を、その場所に割り当てられたローカルゲートウェイにルーティングします。 これには、Unified CM PSTN宛先と内部内線へのオンネットコールが含まれます。 Unified CMローカルゲートウェイはすべての通話をにルーティングします。 Unified CM次に、ローカルに登録された電話またはPSTN/SBC機能が同じ場所にあるローカルゲートウェイを介してPSTNに通話をルーティングします。

Illustration showing a Webex Calling deployment with a Unified CM where the local gateway is coresident with the PSTN gateway/SBC.

コールルーティングに関する考慮事項

Webex Callingへの電話 Unified CM

Webex Callingルーティングロジックは次のように機能します。Webex Callingエンドポイントでダイヤルされた番号を同じ顧客内の他の宛先にルーティングできない場合Webex Calling、通話はローカルゲートウェイに送信され、さらに処理されます。 オフネット（外部Webex Calling）の通話はすべてローカルゲートウェイに送信されます。

Webex CallingUnified CM既存のコールに統合されていない展開では、オフネットコールはすべてPSTNコールと見なされます。 と組み合わせるとUnified CM、オフネットコールは、ホストされている任意の宛先へのオンネット通話でも、Unified CM PSTN宛先への実際のオフネット通話でもかまいません。 後者の 2 つのコールタイプの違いは、によって決まり、プロビジョニングされている企業のダイヤルプランによって異なります。Unified CM Unified CM

次の図は、Webex Callingユーザーが米国の国内番号をダイヤルしているところを示しています。

Illustration showing a Webex Calling user dialing a national number in the US.

Unified CMこれで、設定されたダイヤルプランに基づいて、着信先が電話番号として提供されているローカルに登録されたエンドポイントに通話をルーティングします。 そのためには、Unified CMダイヤルプランが+E.164番号のルーティングをサポートしている必要があります。

Unified CMへの電話 Webex Calling

Unified CMWebex CallingUnified CM一連のルートでからへのコールルーティングを有効にするには、+E.164とエンタープライズ番号プランのアドレスのセットを定義するようにプロビジョニングする必要があります。Webex Calling

これらのルートが整っていれば、次の図に示す両方の通話シナリオが可能になります。

Illustration showing call routing from Unified CM to Webex Calling on a Unified CM set of routes.

Webex CallingPSTNの発信者がデバイスに割り当てられているDID番号に電話をかけた場合、その通話は企業のPSTNゲートウェイを介して企業に渡され、着信します。Unified CM その通話の着信者アドレスは、Webex CallingUnified CMプロビジョニングされているルートの1つと一致し、通話はローカルゲートウェイに送信されます。 （ローカルゲートウェイに送信する場合、着信アドレスは+E.164形式である必要があります。）次に、Webex Callingルーティングロジックは、DIDの割り当てに基づいて、Webex Calling通話が目的のデバイスに送信されることを確認します。

また、Unified CM登録されたエンドポイントから発信され、の宛先を宛先とする通話はWebex Calling、プロビジョニングされているダイヤルプランの対象となります。Unified CM 通常、このダイヤルプランでは、ユーザーは一般的な企業ダイヤル習慣を利用して電話をかけることができます。 これらの習慣には、必ずしも+E.164ダイヤルだけが含まれるわけではありません。 +E.164以外のダイヤル習慣は、コールをローカルゲートウェイに送信する前に+E.164に正規化して、正しくルーティングできるようにする必要があります。Webex Calling

サービスクラス（CoS）

コールループの回避や通話詐欺の防止など、さまざまな理由から、厳しいサービスクラス制限を実施することを常にお勧めします。 Webex CallingUnified CMローカルゲートウェイをサービスクラスと統合する場合、次のようなサービスクラスを考慮する必要があります。

  • に登録されているデバイス Unified CM

  • Unified CMPSTNからかかってくるコール

  • Unified CMからの通話 Webex Calling

に登録されているデバイス Unified CM

Webex Calling既存のCoS設定に新しいクラスの宛先として宛先を追加するのはかなり簡単です。宛先への通話許可は通常、オンプレミス（サイト間を含む）Webex Callingの宛先に電話をかける許可と同等です。

企業のダイヤルプランがすでに「（省略された）オンネット間接続」権限を実装している場合、Unified CM同じパーティションで既知のオンネット宛先をすべて使用およびプロビジョニングできるパーティションがすでにプロビジョニングされています。Webex Calling

そうでなければ、「（省略された）オンネットサイト間」権限という概念がまだ存在していないので、新しいパーティション（「OnNetRemote」など）をプロビジョニングし、Webex Calling宛先をこのパーティションに追加し、最後にこの新しいパーティションを適切なコーリングサーチスペースに追加する必要があります。

Unified CMPSTNからかかってくるコール

Webex Calling既存のCoS設定に新しいクラスの宛先として宛先を追加するのはかなり簡単です。宛先への通話許可は通常、オンプレミス（サイト間を含む）Webex Callingの宛先に電話をかける許可と同等です。

企業のダイヤルプランがすでに「（省略された）オンネット間接続」権限を実装している場合、Unified CM同じパーティションで既知のオンネット宛先をすべて使用およびプロビジョニングできるパーティションがすでにプロビジョニングされています。Webex Calling

そうでなければ、「（省略された）オンネットサイト間」権限という概念がまだ存在していないので、新しいパーティション（「OnNetRemote」など）をプロビジョニングし、Webex Calling宛先をこのパーティションに追加し、最後にこの新しいパーティションを適切なコーリングサーチスペースに追加する必要があります。

Unified CMからの通話 Webex Calling

PSTNから着信するコールは、Webex Callingすべての宛先にアクセスできる必要があります。 これには、PSTNトランクの着信コールに使用されるコーリングサーチスペースに、Webex Callingすべての宛先を保持する上記のパーティションを追加する必要があります。 Webex Calling目的地へのアクセスは、既存のアクセスに加えて行われます。

Unified CMPSTNからの通話ではDIDとDIDへのアクセスが必要ですが、Webex CallingWebex CallingUnified CM発信元の通話はDIDとPSTN宛先にアクセスする必要があります。

Illustration of differentiated CoS for calls from PST and Webex Calling.
PSTNからの通話の差別化COと Webex Calling

この図は、PSTNとからの通話のこれら2つの異なるサービスクラスを比較しています。Webex Calling この図は、PSTNゲートウェイ機能をローカルゲートウェイと同じ場所に配置する場合、PSTN GWとローカルゲートウェイを組み合わせて2つのトランクが必要であることも示しています。1つはPSTNから発信されるコール用で、もう1つはPSTNから発信されるコール用です。Unified CM Webex Calling これは、トラフィックタイプごとに差別化されたコーリングサーチスペースを適用するという要件によるものです。 着信トランクが2つある場合は、各トランクの着信コールに必要なコーリングサーチスペースを設定することで簡単に実現できます。Unified CM

ダイヤルプランの統合

このガイドは、「シスココラボレーションオンプレミス展開の推奨アーキテクチャ、CVD」の現在のベストプラクティスに基づいた既存のインストールを前提としています。最新バージョンはこちらから入手できます。

推奨されるダイヤルプラン設計は、こちらから入手できるシスココラボレーションシステム（SRND）の最新バージョンの「ダイヤルプラン」の章に記載されている設計アプローチに従います。

Illustration showing an overview of the recommended dial plan design.
推奨ダイヤルプラン

この図は、推奨されるダイヤルプラン設計の概要を示しています。 このダイヤルプラン設計の主な特徴は次のとおりです。

  • Unified CMに設定されている電話番号はすべて+E.164形式です。

  • すべての電話番号は同じパーティション（DN）にあり、緊急とマークされています。

  • コアルーティングは+E.164に基づいています。

  • +E.164以外のすべてのダイヤル習慣（たとえば、一般的なダイヤル習慣を使った短縮サイト内ダイヤルやPSTNダイヤル）は、ダイヤリング正規化トランスレーションパターンを使用して+E.164に正規化（グローバル化）されます。

  • ダイヤリング正規化トランスレーションパターンは、トランスレーションパターンのコーリングサーチスペースの継承を使用します。「発信者のコーリングサーチスペースを使用する」オプションセットがあります。

  • サービスクラスは、サイトおよびサービスクラス固有のコーリングサーチスペースを使用して実装されます。

  • PSTNアクセス機能（たとえば、国際PSTN宛先へのアクセス）は、サービスクラスを定義するコーリングサーチスペースに、それぞれの +E.164 ルートパターンを持つパーティションを追加することによって実装されます。

への到達可能性 Webex Calling

Illustration showing adding Webex Calling destination to the dial plan.
Webex Callingダイヤルプランに宛先の追加

Webex Callingこのダイヤルプランに宛先の到達可能性を追加するには、Webex Callingすべての宛先を表すパーティションを作成し（「Webex Calling」）、各DID範囲の+E.164ルートパターンをこのパーティションに追加する必要があります。Webex Calling このルートパターンは、メンバーが1人だけのルートリストを参照します。SIPトランクのあるルートグループから、Webex Callingへの通話用のローカルゲートウェイです。 すべての着信先が +E.164 に正規化されるため、Unified CM登録されたエンドポイントから発信されたコールの場合はダイヤリング正規化トランスフォーメーションを使用して、PSTN から発信されたコールには着信側トランスフォーメーションを使用します。この単一セットの +E.164 ルートパターンは、使用されているダイヤル習慣に関係なく、宛先への到達可能性を実現するのに十分です。Webex Calling

たとえば、ユーザーが「914085550165」をダイヤルした場合、パーティション「USToE164」のダイヤル正規化トランスレーションパターンは、このダイヤル文字列を「+14085550165」に正規化し、パーティション「」の宛先のルートパターンと一致させます。Webex Calling Webex CallingUnified CMは最終的にコールをローカルゲートウェイに送信します。

短縮サイト間ダイヤリングを追加してください

Illustration showing adding abbreviated intersite dialing.
短縮サイト間ダイヤリングの追加

参照ダイヤルプランに短縮サイト間ダイヤリングを追加する推奨方法は、企業番号計画のすべてのサイトのダイヤリング正規化トランスレーションパターンを専用パーティション（「ESN」、企業有効番号）に追加することです。 これらのトランスレーションパターンは、エンタープライズ番号計画の形式でダイヤル文字列をインターセプトし、ダイヤルされた文字列を +E.164 に正規化します。

Webex Callingエンタープライズ短縮ダイヤルを宛先に追加するには、Webex Callingその場所のそれぞれのダイヤル正規化トランスレーションパターンを「Webex Calling」パーティション（図の「8101XX」など）に追加します。 正規化後、「Webex Calling」Webex Calling パーティションのルートパターンが一致した後に、コールが再度送信されます。

「ESN」Webex Calling パーティションへの通話用の短縮ダイヤル正規化トランスレーションパターンを追加することはお勧めしません。この設定では、望ましくない通話ルーティングループが発生する可能性があるためです。

通話用のプロトコルハンドラー

Webex Calling次のプロトコルハンドラーをオペレーティングシステムに登録して、ウェブブラウザや他のアプリケーションからのClick-to-Call機能を有効にします。 次のプロトコルは、MacまたはWindowsのデフォルトの通話アプリケーションであるWebexアプリで音声通話またはビデオ通話を開始します。

  • クリックして電話:またはクリックして電話://

  • SIP: または SIP://

  • 電話番号:または電話番号://

  • ウェベクステル:またはウェベクステル://

List of protocol handlers that start an audio or video call in Webex App when it's the default calling application on Mac or Windows.

Windows用のプロトコルハンドラー

他のアプリは、Webex アプリの前にプロトコルハンドラーに登録できます。 Windows 10では、 通話を開始するために使用するアプリをユーザーに選択するように求めるシステムウィンドウ。 ユーザーが「いつもこのアプリを使う」 にチェックを入れれば、ユーザーの好みを覚えることができます。

Windows 10 'Choose an app' with Webex highlighted as the option to select.

ユーザーが Webex アプリを選択できるようにデフォルトの通話アプリ設定をリセットする必要がある場合は、Windows 10 の Webex App のプロトコルの関連付けを変更するようにユーザーに指示できます。

  1. デフォルトアプリ設定のシステム設定を開き、[ アプリごとにデフォルトを設定する] をクリックして、Webex アプリを選択します。

    Windows 10 'Set defaults by app' with Webex highlighted as the option to select.

  2. プロトコルごとに、Webex アプリを選択してください。

    Windows 10 Webex options for file type and protocol associations.

macOS用のプロトコルハンドラー

Mac OSでは、他のアプリがWebexアプリより前に通話プロトコルに登録されている場合、ユーザーは自分のWebexアプリをデフォルトの通話オプションに設定する必要があります。

Mac用Webex アプリでは、一般設定の [通話を開始する] 設定で Webex アプリが選択されていることを確認できます。 また、Outlook の連絡先の番号をクリックしたときに Webex アプリで電話をかけたい場合は、[常に接続する] をチェックすることもできます。Microsoft Outlook

Mac OS protocol handler settings; 'Always connect to Microsoft Outlook' option select and 'Start calls with' dropdown has Webex chosen.

環境を整えましょう

一般的な前提条件

のローカルゲートウェイを設定する前にWebex Calling、次のことを確認してください。

  • VoIPの原則に関する基本的な知識がある

  • Cisco IOS-XEとIOS-XEの音声概念に関する基本的な実務知識がある

  • セッション開始プロトコル（SIP）の基本を理解している

  • 導入モデルに以下が含まれている場合は、Cisco Unified Communications Manager (Unified CM) の基本を理解してください Unified CM

詳細については、Cisco Unified Border Element(CUBE) エンタープライズ構成ガイドを参照してください。

ローカルゲートウェイのハードウェアとソフトウェアの要件

導入環境には、次のようなローカルゲートウェイが1つ以上あることを確認してください。

  • IPベースの接続用シスコキューブ

  • Cisco IOSTDMベースの接続用ゲートウェイ

Webex Calling注文ガイドについては、ローカルゲートウェイの表1を参照してください。 また、プラットフォームがローカルゲートウェイ設定ガイドに従ってサポートされているIOS-XEリリースを実行していることを確認してください。

ローカルゲートウェイは、Webex Calling自分のペースでに移行するのに役立ちます。 ローカルゲートウェイは、既存のオンプレミス環境とを統合します。Webex Calling 既存のPSTN接続を使用することもできます。 「ローカルゲートウェイを使ってみる」を参照してください

ローカルゲートウェイの証明書とセキュリティ要件

Webex Calling安全な信号とメディアが必要です。 ローカルゲートウェイが暗号化を実行し、次の手順でクラウドへのアウトバウンドでTLS接続を確立する必要があります。

  • LGWは、Cisco PKIのCAルートバンドルで更新する必要があります

  • LGWを設定するには、Control Hubのトランク設定ページにあるSIPダイジェスト認証情報のセットを使用します（手順は次の設定の一部です）

  • CAルートバンドルは提示された証明書を検証します

  • 資格情報の入力を求められます（SIPダイジェストが提供されました）

  • クラウドは、どのローカルゲートウェイが安全に登録されているかを識別します

ローカルゲートウェイのファイアウォール、NATトラバーサル、およびメディアパス最適化の要件

ほとんどの場合、ローカルゲートウェイとエンドポイントは、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つのネットワークの境界に適用されます。

組織は、NATまたはPAT サービスを提供するファイアウォールやプロキシなどのゲートウェイ技術を使用して、プライベート IP アドレススペースにある Webex アプリアプリケーションまたは Webex デバイスにインターネットアクセスを提供します。 これらのゲートウェイは、内部のアプリやデバイスからインターネットへのトラフィックが、公にルーティング可能な1つ以上のIPアドレスから来ているように見せかけます。

  • NATを導入する場合、ファイアウォールでインバウンドポートを開くことは必須ではありません。

  • Webex Calling複数のアプリユーザーとデバイスがNATまたはPATを使用してWebex対応サービスにアクセスする場合に、アプリまたはデバイスの接続に必要なNATプールサイズを確認してください。 ポートの枯渇を防ぐために、適切なパブリックIPアドレスがNATプールに割り当てられていることを確認してください。 ポートが枯渇すると、Webex Calling内部のユーザーやデバイスがやWebex Awareサービスに接続できなくなります。

  • 妥当なバインド期間を定義し、NATデバイスでのSIPの操作は避けてください。

  • デバイスが正常に動作するように、最小NATタイムアウトを設定してください。 例：シスコの電話は、1〜2分ごとにフォローアップのREGISTER更新メッセージを送信します。

  • ネットワークがNATまたはSPIを実装している場合は、接続のタイムアウトを大きく（少なくとも30分）設定してください。 このタイムアウトにより、ユーザーのモバイルデバイスのバッテリー消費を抑えながら、信頼性の高い接続が可能になります。

SIPアプリケーション層ゲートウェイ

ルーターやファイアウォールがSIP対応、つまりSIPアプリケーション・レイヤー・ゲートウェイ（ALG）などが有効になっている場合は、サービスを正確に動作させるためにこの機能をオフにすることをお勧めします。 Webex Callingすべてのトラフィックは暗号化されていますが、特定のSIP ALG実装はファイアウォールトラバーサルで問題を引き起こす可能性があります。 したがって、質の高いサービスを確保するために、SIP ALGをオフにすることをお勧めします。

特定のデバイスでSIP ALGを無効にする手順については、関連メーカーのドキュメントを確認してください。

のプロキシサポート Webex Calling

組織は、ネットワークに出入りするHTTPトラフィックを検査、制限、制御するために、インターネットファイアウォールまたはインターネットプロキシとファイアウォールを導入しています。 したがって、さまざまな形態のサイバー攻撃からネットワークを保護します。

プロキシは、次のようないくつかのセキュリティ機能を実行します。

  • 特定のURLへのアクセスを許可またはブロックします。

  • ユーザー認証

  • IPアドレス/ドメイン/ホスト名/URIレピュテーション検索

  • トラフィックの復号化と検査

プロキシ機能の設定は、HTTPのプロトコルを使用するすべてのアプリケーションに適用されます。

Webex アプリと Webex デバイスアプリケーションには次のものが含まれます。

  • Webex サービス

  • GDS、EDOSデバイスアクティベーション、Cisco Cloudプロビジョニング、Webexクラウドへのオンボーディングなどのプロビジョニングプラットフォームを使用した顧客デバイスアクティベーション（CDA）手順。

  • 証明書認証

  • ファームウェアのアップグレード

  • ステータスレポート

  • PRTアップロード

  • XSIサービス

プロキシサーバーのアドレスが設定されている場合は、シグナリングトラフィック（HTTP/HTTPS）のみがプロキシサーバーに送信されます。 Webex CallingSIPを使用してサービスや関連メディアに登録するクライアントは、プロキシには送信されません。 したがって、これらのクライアントがファイアウォールを直接通過できるようにしてください。

サポートされているプロキシオプション、設定、認証タイプ

サポートされているプロキシタイプは:

  • 明示的なプロキシ（検査中または検査しない）—クライアントの「アプリ」または「デバイス」に明示的なプロキシを設定して、使用するサーバーを指定します。

  • トランスペアレントプロキシ（検査なし）—クライアントは特定のプロキシサーバーアドレスを使用するように構成されておらず、検査対象外のプロキシと連携するための変更は必要ありません。

  • トランスペアレントプロキシ（検査中）—クライアントは、特定のプロキシサーバーアドレスを使用するように設定されていません。 いいえ、HTTPの設定を変更する必要はありません。ただし、アプリまたはデバイスのいずれのクライアントも、プロキシを信頼するためにはルート証明書が必要です。 ITチームは検査プロキシを使用して、訪問するウェブサイトや許可されていないコンテンツの種類にポリシーを適用します。

以下を使用して、CiscoデバイスとWebexアプリのプロキシアドレスを手動で設定します。

お好みの製品タイプを設定する際は、表にある次のプロキシ構成と認証タイプから選択してください。

製品

プロキシ設定

認証タイプ

Mac用ウェベックス

マニュアル、WPAD、PAC

認証なし、ベーシック、NTLM、†

ウィンドウズ用Webex

マニュアル、WPAD、PAC、GPO

認証なし、ベーシック、NTLM、†、ネゴシエート†

iOS用ウェベックス

マニュアル、WPAD、PAC

認証なし、ベーシック、ダイジェスト、NTLM

アンドロイド用Webex

マニュアル、PAC

認証なし、ベーシック、ダイジェスト、NTLM

ウェベックス Web App

OSを通じてサポートされています

認証なし、ベーシック、ダイジェスト、NTLM、ネゴシエート†

Webex デバイス

WPAD、PAC、またはマニュアル

認証なし、ベーシック、ダイジェスト

シスコ IP フォン

マニュアル、WPAD、PAC

認証なし、ベーシック、ダイジェスト

Webex ビデオメッシュノード

マニュアル

認証なし、ベーシック、ダイジェスト、NTLM

表の凡例については：

  1. † Mac NTLM Auth-マシンはドメインにログオンする必要はありません。ユーザーはパスワードの入力を求められます

  2. † Windows NTLM認証-マシンがドメインにログオンしている場合にのみサポートされます

  3. ネゴシエート†-NTLMフォールバック認証付きのケルベロス。

  4. Cisco Webex Board、デスク、またはルームシリーズのデバイスをプロキシサーバーに接続するには、「ボード、デスク、またはルームシリーズのデバイスをプロキシサーバーに接続する」を参照してください。

  5. Cisco IP電話の場合、プロキシサーバーと設定の設定例として、プロキシサーバーの設定を参照してください。

ではNo Authentication、認証をサポートしないプロキシアドレスでクライアントを設定します。 使用するときはProxy Authentication、有効な資格情報で設定してください。 ウェブトラフィックを検査するプロキシは、ウェブソケット接続を妨害する可能性があります。 この問題が発生した場合は、*.Webex.comへのトラフィックを検査しないで済むことで問題が解決する可能性があります。 すでに他のエントリが表示されている場合は、最後のエントリの後にセミコロンを追加して、Webex例外を入力してください。

ウィンドウズ OS のプロキシ設定

Microsoft Windowsプロキシ構成を可能にするHTTPトラフィック用の2つのネットワークライブラリ（WinInetとWinHTTP）をサポートしています。WinInetはWinHTTPのスーパーセットです。

  1. WinInetは、シングルユーザーのデスクトップクライアントアプリケーション向けに設計されています

  2. WinHTTPは、主にマルチユーザー、サーバーベースのアプリケーション向けに設計されています

この2つから選択するときは、プロキシ構成の設定にWinInetを選択してください。 詳細については、wininet-vs-winhttpを参照してください。

以下の詳細については、「企業ネットワーク上で Webex へのアクセスを許可するドメインのリストを設定する」を参照してください。

  • ユーザーが事前に定義されたドメインのリストからのアカウントのみを使用してアプリケーションにサインインするようにするため。

  • プロキシサーバーを使用してリクエストを傍受し、許可されるドメインを制限してください。

代理検査と証明書ピン留め

Webex アプリとデバイスは、TLS セッションを確立するときにサーバーの証明書を検証します。 証明書の発行者や電子署名などの証明書チェックは、ルート証明書までの一連の証明書を検証することに依存しています。 検証チェックを行うために、Webex アプリとデバイスは、オペレーティングシステムのトラストストアにインストールされている一連の信頼できるルート CA 証明書を使用します。

トラフィックを傍受、復号化、検査するためにTLS検査プロキシを導入している場合。Webex Calling プロキシが（Webexサービス証明書の代わりに）提示する証明書が認証局によって署名され、ルート証明書がWebexアプリまたはWebexデバイスのトラストストアにインストールされていることを確認してください。

  • Webexアプリの場合-プロキシによる証明書の署名に使用されるCA証明書をデバイスのオペレーティングシステムにインストールします。

  • Webex RoomデバイスとCiscoマルチプラットフォームIP電話の場合-TACチームにサービスリクエストを出して、CA証明書をインストールしてください。

この表は、プロキシサーバーによる TLS 検査をサポートする Webex アプリと Webex デバイスを示しています

製品

TLS検査用のカスタム信頼できるCAをサポートします

Webex アプリ (ウィンドウズ、マック、iOS、アンドロイド、ウェブ)

はい

Webex ルームデバイス

はい

Cisco IPマルチプラットフォーム（MPP）電話

はい

ファイアウォールの設定

シスコはWebex Calling、安全なシスコとアマゾンウェブサービス（AWS）のデータセンターでのサポートと Webex Aware サービスをサポートしています。 AmazonはIPサブネットをシスコ専用に予約し、AWS仮想プライベートクラウド内のこれらのサブネットにあるサービスを保護しています。

デバイス、アプリのアプリケーション、インターネット接続サービスからの通信が適切に機能するようにファイアウォールを設定してください。 この設定では、Webex CallingサポートされているすべてのWebex Awareクラウドサービス、ドメイン名、IPアドレス、ポート、およびプロトコルにアクセスできます。

と Webex Aware サービスが正しく機能するように、ホワイトリストに登録するかWebex Calling、以下へのアクセスをオープンにしてください。

ファイアウォールのみを使用している場合、IPアドレスプールの一部は動的であり、いつでも変更される可能性があるため、Webex Calling IPアドレスだけを使用してトラフィックをフィルタリングすることはできません。 ルールを定期的に更新してください。ファイアウォールのルールリストを更新しないと、ユーザーエクスペリエンスに影響を与える可能性があります。 シスコは、特定の地域やクラウドサービスプロバイダーに基づいてIPアドレスのサブセットをフィルタリングすることを推奨していません。 地域でフィルタリングすると、通話体験が著しく低下する可能性があります。

シスコは動的に変化するIPアドレスプールを管理していないため、この記事には記載していません。

ファイアウォールがドメイン/URLフィルタリングをサポートしていない場合は、エンタープライズプロキシサーバーオプションを使用してください。 このオプションは、ファイアウォールに転送する前に、Webex CallingプロキシサーバーへのHTTPシグナリングトラフィックとWebexAwareサービスをURL/ドメインでフィルタリング/許可します。

コールメディアのポートとIPサブネットフィルタリングを使用してトラフィックを設定できます。 メディアトラフィックはインターネットへの直接アクセスが必要なため、トラフィックのシグナリングにはURLフィルタリングオプションを選択してください。

ではWebex Calling、UDPはシスコが推奨するメディア転送プロトコルであり、UDPよりもSRTPのみを使用することを推奨しています。 メディアのトランスポートプロトコルとしてのTCPとTLSは、Webex Calling本番環境ではサポートされていません。 これらのプロトコルの接続指向の性質は、損失の多いネットワークのメディア品質に影響します。 トランスポートプロトコルについて質問がある場合は、サポートチケットを作成してください。

サービスのドメインとURL Webex Calling

URL（たとえば、*.webex.com）の先頭に* が付いている場合は、最上位ドメインとすべてのサブドメインのサービスにアクセスできることを示しています。

ドメイン/URL

説明

これらのドメイン/ URLを使用するWebexアプリとデバイス

Cisco Webexサービス

*.broadcloudpbx.com

コントロールハブからコーリング管理ポータルへの相互起動のためのWebex認証マイクロサービス。

コントロールハブ

*.broadcloud.com.au

Webex Callingオーストラリアでのサービス。

すべて

*.broadcloud.eu

Webex Callingヨーロッパでのサービス。

すべて

*.broadcloudpbx.net

クライアントの設定と管理サービスを呼び出しています。

Webex アプリ

*.webex.com

*.cisco.com

Webex Callingコアと Webex 対応サービス

  1. IDプロビジョニング

  2. ID ストレージ

  3. 認証

  4. OAuth サービス

  5. デバイスのオンボーディング

  6. クラウド接続UC

電話が初めてネットワークに接続するとき、またはDHCPオプションを設定せずに工場出荷時の状態にリセットした後は、デバイスアクティベーションサーバーに接続してゼロタッチプロビジョニングを行います。 新しい電話はactivate.cisco.comを使用し、ファームウェアリリースが11.2 (1) より前の電話機は、引き続き webapps.cisco.com を使用してプロビジョニングします。

デバイスのファームウェアとロケールの更新を binaries.webex.com からダウンロードしてください。

12.0.3より古いCiscoマルチプラットフォーム電話（MPP）がポート80経由でsudirenewal.cisco.comにアクセスして、製造元インストール証明書（MIC）を更新し、セキュア固有デバイス識別子（SUDI）を取得できるようにします。 詳細については、Field noticeを参照してください。

すべて

*.ucmgmt.cisco.com

Webex Callingサービス

コントロールハブ

*.wbx2.comと*.ciscospark.com

Webex Callingオンボーディング中およびオンボーディング後に Webex Aware サービスに連絡するためのクラウド認識に使用されます。

これらのサービスは、次の場合に必要です

  • アプリとデバイスの管理

  • アプリアプリケーション通知メカニズムサービス管理

すべて

*.webexapis.com

Webex アプリアプリケーションと Webex デバイスを管理する Webex マイクロサービス。

  1. プロフィール写真サービス

  2. ホワイトボードサービス

  3. 近接サービス

  4. プレゼンスサービス

  5. 登録サービス

  6. カレンダーサービス

  7. 検索サービス

すべて

*.webexcontent.com

Webex Messaging以下を含む、一般的なファイルストレージに関連するサービス：

  1. ユーザーファイル

  2. トランスコードされたファイル

  3. 画像

  4. スクリーンショット

  5. ホワイトボードのコンテンツ

  6. クライアントとデバイスのログ

  7. プロフィール写真

  8. ブランディングロゴ

  9. ログファイル

  10. CSVの一括エクスポートファイルとインポートファイル（コントロールハブ）

Webex アプリメッセージングサービス。

webexcontent.comを使用するファイルストレージは、2019年10月にクラウドドライブ.comに置き換えられました

*.accompany.com

ピープルインサイトの統合

Webex アプリ

その他の Webex 関連サービス（サードパーティドメイン）

*.appdynamics.com

*.eum-appdynamics.com

パフォーマンストラッキング、エラーとクラッシュキャプチャ、セッションメトリクス。

コントロールハブ

*.sipflash.com

デバイス管理サービス。 ファームウェアのアップグレードと安全なオンボーディングの目的。

Webex アプリ

*.walkme.com *.walkmeusercontent.com

Webex ユーザーガイダンスクライアント。 新規ユーザー向けのオンボーディングと使用方法のツアーを提供します。

WalkMeの詳細については、ここをクリックしてください。

Webex アプリ

*.google.com

*.googleapis.com

モバイルデバイスのWebexアプリへの通知（例：通話に応答したときの新着メッセージ）

IPサブネットについては、次のリンクを参照してください

グーグルファイアベースクラウドメッセージング（FCM）サービス

アップルのプッシュ通知サービス（APNS）

APNSについては、AppleがこのサービスのIPサブネットを一覧表示しています。

Webex アプリ

サービスのIPサブネット Webex Calling

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-65535TCPWebex Callingサービスについては、IPサブネットを参照してください。5062, 8934

これらのIP/ポートは、ローカルゲートウェイ、デバイス、Webexアプリアプリケーション（ソース）からクラウド（宛先）へのアウトバウンドSIP-TLSコールシグナリングに必要です。Webex Calling

ポート5062（証明書ベースのトランクには必須）。 そしてポート8934（登録ベースのトランクには必要）

デバイス5060-50808934
Webex アプリ エフェメラル（OSに依存）
Webex Calling（SIP TLS）からローカルゲートウェイへのコールシグナリング

Webex Callingアドレス範囲。

サービスのIPサブネットを参照してください Webex Calling

8934TCPお客様がローカルゲートウェイ用に選択したIPまたはIP範囲お客様がローカルゲートウェイ用に選択したポートまたはポート範囲

証明書ベースのローカルゲートウェイに適用されます。 Webex Callingからローカルゲートウェイへの接続を確立する必要があります。

登録ベースのローカルゲートウェイは、ローカルゲートウェイから作成された接続を再利用することで機能します。

宛先ポートはお客様が選択します。トランクの設定

メディアを Webex Calling (STUN、SRTP/SRTCP、T38、DTLS) に呼び出しますローカルゲートウェイ、外部 NIC8000-48199†*UDPWebex Callingサービスについては、IPサブネットを参照してください。

5004、9000（スタンポート）

オーディオ:8500-8599

ビデオ:8600-8699

19560-65535（SRTP over UDP）

  • これらのIP/ポートは、ローカルゲートウェイ、デバイス、Webexアプリアプリケーション（ソース）からクラウド（宛先）へのアウトバウンドSRTPコールメディアに使用されます。Webex Calling

  • STUN、ICEのネゴシエーションが成功している組織内の通話では、クラウド内のメディアリレーが通信パスから削除されます。 このような場合、メディアフローはユーザーのアプリ/デバイス間で直接行われます。

    例：メディアの最適化が成功すると、Webexアプリはポート範囲8500〜8699で相互にメディアを直接送信し、デバイスは19560〜19661のポート範囲で互いにメディアを直接送信します。

  • お客様の構内でファイアウォールが使用されている特定のネットワークトポロジーでは、メディアが通過できるように、ネットワーク内の上記の送信元と宛先のポート範囲へのアクセスを許可してください。

    例：Webex Appの場合、送信元と宛先のポート範囲を許可します

    オーディオ:8500-8599 ビデオ:8600-8699

  • ブラウザは一時的な送信元ポートを使用します。これは、管理対象デバイス管理（MDM）プロファイルでWebRTCUDPorTrangeポリシーを設定することで制御できます。

    Webex CallingMDMサービスが設定されていない場合、またはsiteUrlとEnableForceLoginが設定されていない場合、サービスは正常に動作します。

デバイス † *19560-19661

VG400 データデバイス

19560-19849
Webex アプリ†*

オーディオ:8500-8599

ビデオ:8600-8699

ウェブRTC

エフェメラル（ブラウザポリシーによる）
Webex Calling（SRTP/SRTCP、T38）からメディアを呼び出します

Webex Callingアドレス範囲。

サービスのIPサブネットを参照してください Webex Calling

19560-65535（SRTP over UDP） UDPお客様がローカルゲートウェイ用に選択したIPまたはIP範囲 お客様がローカルゲートウェイ用に選択したメディアポート範囲
PSTNゲートウェイ（SIP TLS）へのコールシグナリングローカルゲートウェイ内蔵NIC8000-65535TCPあなたのITSP、PSTN GW、または Unified CMPSTNオプションによって異なります（たとえば、通常は5060または5061の）Unified CM
メディアをPSTNゲートウェイに呼び出します（SRTP/SRTCP）ローカルゲートウェイ内蔵NIC8000-48199†*UDPあなたのITSP、PSTN GW、または Unified CMPSTNオプションによって異なります（たとえば、通常は5060または5061は）Unified CM
デバイス設定とファームウェア管理（Ciscoデバイス）Webex CallingデバイスエフェメラルTCP

サービスのIPサブネットを参照してください Webex Calling

443, 6970, 80

次の理由で必須：

  1. エンタープライズフォン (Cisco Unified CM) Webex Calling からへの移行 詳細については、upgrade.cisco.comを参照してください。 cloudupgrader.webex.comは、ファームウェアの移行プロセスに6970,443というポートを使用しています。

  2. ファームウェアのアップグレードと、16桁のアクティベーションコード（GDS）を使用したデバイス（MPPとルームフォンまたはデスクフォン）の安全なオンボーディング

  3. CDA/EDOSの場合-MACアドレスベースのプロビジョニング。 新しいファームウェアを搭載したデバイス（MPP電話、ATA、SPA ATA）で使用されます。

  4. Cisco ATAの場合は、デバイスのファームウェアが11.1.0MSR3-9の最小ファームウェアであることを確認してください。

  5. 電話機が初めてネットワークに接続するとき、または工場出荷時の状態にリセットした後、DHCPオプションを設定せずに、デバイスアクティベーションサーバーに接続してゼロタッチプロビジョニングを行います。 新しい電話機のプロビジョニングには、webapps.cisco.comの代わりにactivate.cisco.comを使用してください。 11.2 (1) より前にリリースされたファームウェアを搭載した電話は、引き続き webapps.cisco.com を使用します。 これらのIPサブネットをすべて許可することをお勧めします。

  6. 12.0.3バージョンより古いCiscoマルチプラットフォーム電話（MPP）がポート80経由でsudirenewal.cisco.comにアクセスできるようにして、製造元インストール証明書（MIC）を更新し、セキュア固有デバイス識別子（SUDI）を取得できるようにします。 詳細については、Field Notice を参照してください

Webex アプリの設定Webex アプリアプリケーションエフェメラルTCP

サービスのIPサブネットを参照してください Webex Calling

443, 8443IDブローカー認証、クライアント向けのWebexアプリ設定サービス、セルフケア用のブラウザベースのWebアクセス、および管理インターフェイスアクセスに使用されます。
TCPポート8443は、Webex Cisco Unified CM アプリの設定時に設定をダウンロードするために使用されます。 Webex Callingセットアップを使用して接続するお客様だけがポートを開く必要があります。
デバイスの時刻同期（NTP）Webex Callingデバイス51494UDPWebex Callingサービスについては、IPサブネットを参照してください。123これらのIPアドレスは、デバイス（MPP電話、ATA、SPA ATA）の時刻同期に必要です

ドメインネームシステム（DNS）解決

Webex Callingデバイス、Webex アプリ、Webex デバイスエフェメラルUDP と TCPホスト定義53Webex Callingクラウド内のサービスのIPアドレスを検出するためのDNSルックアップに使用されます。 一般的なDNSルックアップはUDPで行われますが、クエリの応答がUDPパケットに収まらない場合は、TCPが必要なものもあります。
ネットワークタイムプロトコル (NTP)Webex アプリと Webex デバイス123UDPホスト定義123時刻同期
スキャンしますウェブベースのネットワーク準備のための事前認定ツール Webex CallingエフェメラルTCPWebex Callingサービスについては、IPサブネットを参照してください。8934と443ですウェブベースのネットワーク準備のための事前資格確認ツール。Webex Calling 詳細については、cscan.webex.comにアクセスしてください。
UDP19569-19760
Webex Calling追加サービスと Webex 対応サービス (サードパーティ)
プッシュ通知 APNS と FCM サービス Webex Callingアプリケーション エフェメラルTCP

リンクの下に記載されているIPサブネットを参照してください

アップルのプッシュ通知サービス（APNS）

グーグル・ファイアベース・クラウド・メッセージング（FCM）

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 アプリ オーディオ

サービスのIPサブネット、ドメイン、URLを参照してください Webex Calling

8500-8599 8500-8599, 19560-65535 速達転送 (46)
Webex アプリ ビデオ 8600-8699 8600-8699, 19560-65535 確実な転送 41 (34)
Webex アプリ シグナリング エフェメラル（OSに依存） 8934 CS0 (0)
Webex デバイス（MPP とルーム）オーディオとビデオ 19560-19661 19560-65535

速達転送 (46) &

確実な転送 41 (34)

Webex デバイス シグナリング 5060-5080 8934 クラスセレクター 3 (24)

  • オーディオとビデオ/共有には、トラフィックのマーキング方法が異なる送信元ポート範囲が異なるため、個別のQoSプロファイルを作成してください。

  • Windowsクライアントの場合：組織でUDPソースポートの差別化を有効にするには、地域のアカウントチームに連絡してください。 有効にしないと、Windows QoSポリシー（GPO）を使用してオーディオとビデオ/共有を区別できません。ソースポートはオーディオ/ビデオ/共有で同じだからです。 詳細については、「Webex アプリのメディアソースポート範囲を有効にする」を参照してください

  • Webexデバイスの場合は、コントロールハブのデバイス設定からQoS設定の変更を設定します。 詳細については、Webex-Callingのデバイス設定の設定と変更を参照してください

Webex Meetings/メッセージング-ネットワーク要件

クラウドコラボレーションサービス、Webex Suite Webexクラウド登録製品を利用しているお客様のために、通話履歴、ディレクトリ検索、会議、メッセージングなどのサービスのために、MPPデバイスをWebex Cloudにオンボードします。 この記事に記載されているドメイン/URL/IPアドレス/ポートが、Webexサービスのオープンネットワーク要件であることを確認してください。

政府向け Webex のネットワーク要件

政府向けサービス向け Webex のドメイン、URL、IP アドレス範囲、およびポートのリストを必要とするお客様は、こちらの情報をご覧ください。政府向け Webex のネットワーク要件

Webex アテンダントコンソールのネットワーク要件

アテンダントコンソール（受付、アテンダント、オペレーター機能）を使用しているお客様は、ドメイン/URL/IPアドレス/ポート/プロトコルがアテンダントコンソールのオープンネットワーク要件であることを確認してください

Webex Callingローカルゲートウェイを始めましょう

Webex CallingオンプレミスベースのPSTNとサードパーティのSBCの相互運用性を実現するためにローカルゲートウェイソリューションを使用しているお客様は、「ローカルゲートウェイ入門」の記事を読んでください

参考文献

の新機能を知るにはWebex Calling、「の新機能」を参照してください Webex Calling

のセキュリティ要件についてはWebex Calling、記事を参照してください

Webex Callingインタラクティブ接続確立（ICE）によるメディア最適化記事

文書の改訂履歴

日付

この記事に次の変更を加えました

2025年1月21日

SIPアプリケーション層ゲートウェイの使用方法の詳細を追加しました。

2025年1月8日

デバイス設定とWebex アプリ設定に関連するIPサブネットアドレスを、サービスのIPサブネットセクションに移動しました Webex Calling

2024年12月17日

Webex CallingWebRTCのメディア仕様のサポートを追加しました。

2024年11月14日

Webex CallingVG400シリーズATAデバイスのコールメディアでサポートされているポート範囲を更新しました

2024年11月11日

Webex CallingVG400シリーズATAデバイスのコールメディアでサポートされているポート範囲を追加しました

2024年7月25日

Cisco ATAデバイスの設定とファームウェア管理に必要なため、52.26.82.54 IPサブネットを再度追加しました。

2024年7月18日

次の詳細で更新されました：

  • （アプリ、デバイス）でサポートされているQoS（TOS/DSCP）値 Webex Calling

  • ネットワーク図を更新しました

  • Webex Attendant Consoleに関連するネットワーク要件へのリンクを含みます。

2024年6月28日

メディア仕様のSRTP/SRTCPポート範囲の両方の使用法を更新しました。Webex Calling

2024年6月11日

「huron-dev.com」ドメインは使用されていないので削除しました。

2024年5月6日

メディア仕様のSRTP/SRTCPポート範囲の両方の使用法を更新しました。Webex Calling

2024年4月3日

Webex Callingインド地域の市場拡大に対応するため、Webex Calling 163.129.0.0/17のサービスのIPサブネットを更新しました。

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将来の成長に備えて地域の拡大に対応するため、Webex CallingサービスのIPサブネットを更新して、より多くのIPアドレスを含めました。

144.196.33.0/25 — 144.196.0.0/16に変更されました

証明書ベースのトランキングとローカルゲートウェイのファイアウォール要件が明確になるように、Webex Calling（SIP TLS）とCall media toWebex Calling（STUN、SRTP）の「Webex CallingサービスのIPサブネット」セクションが更新されました。

2023年8月14日

エッジとサービスの容量要件の増加に対応するために、次のIPアドレス144.196.33.0/25と150.253.156.128/25を追加しました。Webex Calling

このIP範囲は米国地域でのみサポートされています。

2023年7月5日

Cisco MPP ファームウェアをインストールするための https://binaries.webex.com リンクを追加しました。

2023年3月7日です

記事全体を見直して、次の内容を含めました。

  1. プロキシサポートのオプションが含まれています。

  2. 修正された通話フロー図

  3. とWebex Awareサービス用の簡略化されたドメイン/URL/IPサブネット部分 Webex Calling

  4. & Webex Webex Calling Awareサービスのために170.72.0.0/16 IPサブネット範囲を追加しました。

    次の範囲を削除しました 170.72.231.0、170.72.231.10、170.72.231.161、170.72.242.0/24

2023年3月5日

次の内容を含むように記事を更新しています：

  • アプリケーションで使用されるUDP-SRTPポート範囲（8500-8700）を追加しました。

  • プッシュ通知、APNS、FCMサービスのポートを追加しました。

  • CScanのポート範囲をUDPとTCPに分割してください。

  • 参考文献セクションを追加しました。

2022年11月15日

デバイス設定とファームウェア管理（Ciscoデバイス）用に次のIPアドレスを追加しました。

  • 170.72.231.0

  • 170.72.231.10

  • 170.72.231.161

デバイス設定とファームウェア管理（Ciscoデバイス）から次のIPアドレスを削除しました。

  • 3.20.118.133

  • 3.20.228.133

  • 3.23.144.213

  • 3.130.125.44

  • 3.132.162.62

  • 3.140.117.199

  • 18.232.241.58

  • 35.168.211.203

  • 50.16.236.139

  • 52.45.157.48

  • 54.145.130.71

  • 54.156.13.25

  • 52.26.82.54

  • 54.68.1.225

2022年11月14日

サービスのIPサブネット170.72.242.0/24を追加しました。Webex Calling

2022年9月8日

Cisco MPP ファームウェアは、すべての地域で MPP ファームウェアのアップグレードのホスト URL として https://binaries.webex.com を使用するようになります。 この変更により、ファームウェアのアップグレードパフォーマンスが向上します。

2022年8月30日に

依存関係がないため、ポート表のデバイス構成とファームウェア管理（Ciscoデバイス）、アプリケーション構成、CScan行からポート80への参照を削除しました。

2022年8月18日

ソリューションに変更はありません。 （SIP TLS）へのコールシグナリングの宛先ポート5062（証明書ベースのトランクに必要）、8934（登録ベースのトランクに必要）を更新しました。Webex Calling

2022年7月26日

Cisco 840/860デバイスのファームウェアのアップグレードに必要な 54.68.1.225 IPアドレスを追加しました。

2022年7月21日

Webex Calling（SIP TLS） へのコールシグナリング用の宛先ポート5062、8934を更新しました。

2022年7月14日

Webex Aware サービスのすべての機能をサポートする URL を追加しました。

サービスのIPサブネット23.89.154.0/25を追加しました。Webex Calling

2022年6月27日

Webex Calling サービスのドメインとURLを更新しました：

*.broadcloudpbx.com

*.broadcloud.com.au

*.broadcloud.eu

*.broadcloudpbx.net

2022年6月15日

Webex Callingサービス用IPアドレスとポートに次のポートとプロトコルを追加しました。

  • 接続目的:Webex 機能

  • ソースアドレス:Webex Callingデバイス

  • ソースポート:エフェメラル

  • プロトコル:TCP

  • 宛先アドレス：Webex Meetings/Messaging-ネットワーク要件で定義されているIPサブネットとドメインを参照してください。

  • 宛先ポート:443

    注:Webex Callingデバイスはこれらの IP アドレスとドメインを使用して、ディレクトリ、通話履歴、会議などの Webex Cloud Services と通信します。

Webex Meetings/Messaging-ネットワーク要件セクションの情報を更新しました

2022年5月24日

サービス用のIPサブネット52.26.82.54/24を52.26.82.54/32に追加しました Webex Calling

2022年5月6日

サービス用にIPサブネット52.26.82.54/24を追加しました Webex Calling

2022年4月7日

ローカルゲートウェイの内部および外部UDPポート範囲を8000-48198に更新しました†

2022年4月5日

Webex Callingサービス用に次のIPサブネットを追加しました。

  • 23.89.40.0/25

  • 23.89.1.128/25

2022年3月29日

Webex Callingサービス用に次のIPサブネットを追加しました。

  • 23.89.33.0/24

  • 150.253.209.128/25

2021年9月20日

Webex Callingサービス用に4つの新しいIPサブネットを追加しました：

  • 23.89.76.128/25

  • 170.72.29.0/24

  • 170.72.17.128/25

  • 170.72.0.128/25

2021年4月2日

Webex Webex Calling アプリのユースケースをサポートするために、Webex Callingサービスのドメインと URL の下に*.ciscospark.com を追加しました。

2021年3月25日

activate.cisco.comに6つの新しいIP範囲を追加しました。これは2021年5月8日から有効になります。

  • 72.163.15.64/26

  • 72.163.15.128/26

  • 173.36.127.0/26

  • 173.36.127.128/26

  • 192.133.220.0/26

  • 192.133.220.64/26

2021年3月4日

ファイアウォールの構成を理解しやすくするために、Webex Calling個別のIPと小さいIP範囲を別の表の簡略化された範囲に置き換えました。

2021年2月26日

2021年4月に利用可能になる予定のインタラクティブ接続確立Webex Calling（ICE） をサポートするために、コールメディア （STUN、SRTP） の宛先ポートとして5004を追加しました。Webex Calling

2021年2月22日

ドメインとURLは別の表に表示されるようになりました。

IPアドレスとポートの表は、同じサービスのIPアドレスをグループ化するように調整されています。

要件を理解しやすくするために、IPアドレスとポートの表に「メモ」列を追加します。

デバイス設定とファームウェア管理（Ciscoデバイス）のために、次のIPアドレスを簡略化された範囲に移動します。

アクティベート.cisco.com

  • 72.163.10.125 -> 72.163.10.96/27

  • 173.37.149.125 -> 173.37.149.96/27

webapps.cisco.com

  • 173.37.146.134 -> 173.37.146.128/25

  • 72.163.10.134 -> 72.163.10.128/25

Cisco WebexDNS SRVクライアントは2021年3月にオーストラリアの新しいIPアドレスを指しているので、アプリケーション構成に次のIPアドレスを追加します。

  • 199.59.64.237

  • 199.59.67.237

2021年1月21日

デバイス設定とファームウェア管理（Ciscoデバイス）に次のIPアドレスを追加しました。

  • 3.134.166.179

  • 50.16.236.139

  • 54.145.130.71

  • 72.163.10.125

  • 72.163.24.0/23

  • 173.37.26.0/23

  • 173.37.146.134

デバイス設定とファームウェア管理（Ciscoデバイス）から次のIPアドレスを削除しました。

  • 35.172.26.181

  • 52.86.172.220

  • 52.203.31.41

アプリケーション構成に次のIPアドレスを追加しました。

  • 62.109.192.0/19

  • 64.68.96.0/19

  • 207.182.160.0/19

  • 150.253.128.0/17

アプリケーション構成から次のIPアドレスを削除しました。

  • 64.68.99.6

  • 64.68.100.6

アプリケーション構成から次のポート番号を削除しました。

  • 1081, 2208, 5222, 5280-5281, 52644-52645

アプリケーション構成に次のドメインを追加しました。

  • idbroker-b-us.webex.com

  • idbroker-eu.webex.com

  • ty6-wxt-jp.bcld.webex.com

  • os1-wxt-jp.bcld.webex.com

2020年12月23日

ポートリファレンスイメージに新しいアプリケーション構成のIPアドレスを追加しました。

2020年12月22日

表のアプリケーション構成行を更新して、135.84.171.154と135.84.172.154というIPアドレスを追加しました。

これらのIPアドレスが追加されるまでネットワーク図を非表示にしていました。

2020年12月11日

サポートされているカナダのドメインのデバイス構成とファームウェア管理（Ciscoデバイス）とアプリケーション構成の行を更新しました。

2020 年 10 月 16 日

コールシグナリングとメディアエントリを次のIPアドレスで更新しました。

  • 139.177.64.0/24

  • 139.177.65.0/24

  • 139.177.66.0/24

  • 139.177.67.0/24

  • 139.177.68.0/24

  • 139.177.69.0/24

  • 139.177.70.0/24

  • 139.177.71.0/24

  • 139.177.72.0/24

  • 139.177.73.0/24

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アドレスを追加しました。

  • メディアを Webex Calling (SRTP) に電話 — 135.84.173.0/25,135.84.174.0/25, 199.19.197.0/24, 199.19.199.0/24

  • パブリックアドレスのエンドポイントへのコールシグナリング（SIP TLS）—135.84.173.0/25,135.84.174.0/25、199.19.197.0/24、199.19.199.0/24。

  • デバイス設定とファームウェア管理（シスコデバイス）—135.84.173.155,135.84.174.155

  • デバイスの時刻同期 — 135.84.173.152、135.84.174.152

  • アプリケーションの構成 — 135.84.173.154,135.84.174.154

2020年7月22日

カナダでのデータセンターの導入をサポートするために、次のIPアドレスを追加しました。135.84.173.146

2020年6月9日

cScanエントリに次の変更を加えました。

  • IPアドレスの1つを修正しました。 199.59.67.156を199.59.64.156に変更しました。

  • 新しい機能には新しいポートとUDP—19560-19760が必要です。

2020年3月11日

次のドメインとIPアドレスをアプリケーション構成に追加しました。

  • jp.bcld.webex.com—135.84.169.150

  • クライアント-jp.bcld.webex.com

  • idbroker.webex.com—64.68.99.6、64.68.100.6

デバイス構成とファームウェア管理のために、次のドメインをIPアドレスを追加して更新しました。

  • cisco.webexcalling.eu — 85.119.56.198、85.119.57.198

  • webapps.cisco.com—72.163.10.134

  • activation.webex.com—35.172.26.181、52.86.172.220

  • cloudupgrader.webex.com—3.130.87.169、3.20.185.219

2020年2月27日

デバイス構成とファームウェア管理に次のドメインとポートを追加しました。

cloudupgrader.webex.com—443、6970です

Cisco IOS XE for Webex Calling のローカルゲートウェイを設定してください

概要

Webex Calling現在、ローカルゲートウェイの2つのバージョンをサポートしています。

  • ローカルゲートウェイ

  • 政府向け Webex のローカルゲートウェイ

主な考慮事項

  • 始める前に、の構内公衆交換電話網（PSTN）とローカルゲートウェイ（LGW）の要件を理解してください。Webex Calling 詳細については、シスコプリファードアーキテクチャを参照してください。Webex Calling

  • この記事では、既存の音声設定なしで専用のローカルゲートウェイプラットフォームが導入されていることを前提としています。 既存のPSTNゲートウェイまたはCUBE Enterpriseの導入をローカルゲートウェイ機能として使用するように変更する場合はWebex Calling、構成に細心の注意を払ってください。 変更を加えたからといって、既存の通話フローや機能が中断されないようにしてください。

手順には、 個々のコマンドオプションについて詳しく知ることができるコマンドリファレンスドキュメントへのリンクが含まれています。 特に明記されていない限り、すべてのコマンドリファレンスリンクはWebex Managed Gatewaysコマンドリファレンスに移動します（その場合、 Cisco IOSコマンドリンクは音声コマンドリファレンスに移動します）。 これらすべてのガイドには、Cisco Unified Border Elementコマンドリファレンスからアクセスできます。

サポートされているサードパーティのSBCについては、 それぞれの製品リファレンスドキュメントを参照してください。

ローカルゲートウェイを設定してください

Webex Callingトランクのローカルゲートウェイを設定するには、次の2つの方法があります。

  • 登録ベースのトランク

  • 証明書ベースのトランク

登録ベースのローカルゲートウェイまたは証明書ベースのローカルゲートウェイのいずれかのタスクフローを使用して、トランクのローカルゲートウェイを設定します。 Webex Calling

さまざまなトランクタイプの詳細については、「ローカルゲートウェイ入門」を参照してください。 コマンドラインインターフェイス （CLI）を使用して、ローカルゲートウェイ自体で次の手順を実行します。 トランクの保護にはセッション開始プロトコル（SIP）とトランスポート層セキュリティ（TLS） トランスポートを使用し、 ローカルゲートウェイと間のメディアを保護するにはセキュアリアルタイムプロトコル（SRTP）を使用します。Webex Calling

主な考慮事項

  • ローカルゲートウェイとしてCUBEを選択してください。 政府向け Webex は現在、サードパーティのセッションボーダーコントローラー（SBC）をサポートしていません。 最新のリストを確認するには、「ローカルゲートウェイ入門」を参照してください。

  • すべての Webex for Government ローカルゲートウェイに Cisco IOS XE Dublin 17.12.1a 以降のバージョンをインストールしてください。

  • Webex for Government がサポートしているルート認証局 (CA) のリストを確認するには、「政府向け Webex のルート認証局」を参照してください。

  • Webex for Governmentのローカルゲートウェイの外部ポート範囲の詳細については、「のネットワーク要件」を参照してください。Webex for Government (FedRAMP)

政府向け Webex のローカルゲートウェイは以下をサポートしていません。

  • メディアパス最適化のためのSTUN/ICE-Liteです

  • ファックス (T.38)

政府向け Webex のローカルゲートウェイを設定してください

Webex for Webex Calling Governmentでトランクにローカルゲートウェイを設定するには、次のオプションを使用してください。

  • 証明書ベースのトランク

証明書ベースのローカルゲートウェイのタスクフローを使用して、トランクのローカルゲートウェイを設定します。Webex Calling 証明書ベースのローカルゲートウェイの設定方法の詳細については、「証明書ベースのトランクの設定 Webex Calling」を参照してください。

政府向け Webex のローカルゲートウェイをサポートするには、FIPS 準拠の GCM 暗号を設定する必要があります。 そうでない場合、通話設定は失敗します。 設定の詳細については、「Webex Calling証明書ベースのトランクの設定」を参照してください。

政府向け Webex は、登録ベースのローカルゲートウェイをサポートしていません。

デザイン概要

このセクションでは、登録中のSIPトランクを使用してWebex Calling、Cisco Unified Border Element（CUBE） をローカルゲートウェイとして設定する方法について説明します。 このドキュメントの最初の部分では、 簡単なPSTNゲートウェイの設定方法を説明します。 この場合、 PSTNからのすべての通話はにルーティングされ、Webex CallingWebex Callingからのすべての通話はPSTNにルーティングされます。 下の画像は、このソリューションと、 これから採用される高レベルのコールルーティング設定を示しています。

この設計では、次の主要な構成が使用されています。

  • ボイスクラステナント：トランク固有の設定を作成するために使用されます。

  • 音声クラス URI: インバウンドダイヤルピアの選択のためにSIPメッセージを分類するために使用されます。

  • インバウンドダイヤルピア：インバウンドSIPメッセージを処理し、 ダイヤルピアグループを使用してアウトバウンドルートを決定します。

  • ダイヤルピアグループ:転送コールルーティングに使用されるアウトバウンドダイヤルピアを定義します。

  • アウトバウンドダイヤルピア：アウトバウンドSIPメッセージを処理し、 必要なターゲットにルーティングします。

Call routing from/to PSTN to/from Webex Calling configuration solution

IPとSIPがPSTNトランクのデフォルトプロトコルになっていますが、TDM（ 時分割多重化）ISDN回線は依然として広く使用されており、トランクでサポートされています。Webex Calling TDM-IPコールフローを使用してローカルゲートウェイのIPパスのメディア最適化を可能にするには、現在、双方向のコールルーティングプロセスを使用する必要があります。 このアプローチでは、下の画像に示すように、 Webex CallingとPSTNトランクの間に内部ループバックダイヤルピアのセットを導入することで、 上記のコールルーティング設定が変更されます。

Call routing configuration with a set of internal loop-back dial-peers between Webex Calling and PSTN trunks

Cisco Unified Communications Managerオンプレミスソリューションをに接続するときはWebex Calling、 次の図に示すソリューションを構築するためのベースラインとして、単純なPSTNゲートウェイ構成を使用できます。 この場合、 ユニファイドコミュニケーションマネージャーはすべてのPSTNと通話の一元的なルーティングと処理を行います。Webex Calling

Solution diagram showing Unified Communications Manager provides centralized routing and treatment of all PSTN and Webex Calling calls

このドキュメントでは、次の図に示すホスト名、IPアドレス、インターフェイスが使用されています 。

The host names, IP addresses, and interfaces used in Call routing configuration solutions

このドキュメントの残りの部分にある設定ガイダンスを使用して、 次のようにローカルゲートウェイの設定を完了してください。

  • ステップ1: ルーターのベースライン接続とセキュリティを設定する

  • ステップ2: Webex Calling トランクの設定

    必要なアーキテクチャに応じて、次のいずれかに従ってください。

  • ステップ3：SIP PSTNトランクでローカルゲートウェイを設定します

  • ステップ4: Unified CM 既存の環境でローカルゲートウェイを設定する

    または:

  • ステップ3：TDM PSTNトランクでローカルゲートウェイを設定します

接続とセキュリティを設定する

ベースライン構成

Ciscoルーターをローカルゲートウェイとして準備する最初のステップは、プラットフォームを保護し、Webex Calling 接続を確立するためのベースライン構成を構築することです。

  • すべての登録ベースのローカルゲートウェイ導入には、Cisco IOS XE 17.6.1a以降のバージョンが必要です。 Cisco IOS17.12.2以降をお勧めします。 推奨バージョンについては、 シスコソフトウェアリサーチのページを参照してください。 プラットフォームを検索して、 推奨リリースを1つ選択してください。

    • ISR4000シリーズのルーターは、 ユニファイドコミュニケーションとセキュリティテクノロジーの両方のライセンスで構成する必要があります。

    • ボイスカードまたは DSP を搭載した Catalyst Edge 8000 シリーズのルーターには DNA Advantage のライセンスが必要です。 ボイスカードやDSPのないルーターには、最低でもDNA Essentialsのライセンスが必要です。

  • ビジネスポリシーに沿ったプラットフォームのベースライン構成を構築してください。 特に、以下を設定して確認してください。

    • NTP

    • ACL

    • ユーザー認証とリモートアクセス

    • DNS

    • IPルーティング

    • IPアドレス

  • Webex Calling向かうネットワークはIPv4アドレスを使用する必要があります。

  • CiscoルートCAバンドルをローカルゲートウェイにアップロードします。

構成

1

有効でルーティング可能なIPアドレスを任意のレイヤー3インターフェイスに割り当ててください。 次に例を示します。


interface GigabitEthernet0/0/0
  description Interface facing PSTN and/or CUCM
  ip address 10.80.13.12 255.255.255.0
!
interface GigabitEthernet0/0/1
  description Interface facing Webex Calling (Private address)
  ip address 192.51.100.1 255.255.255.240

2

対称暗号化を使用して、ルーターの登録とSTUN認証情報を保護してください。 プライマリ暗号化キーと暗号化タイプを次のように設定します。


key config-key password-encrypt YourPassword
password encryption aes

3

プレースホルダーPKIトラストポイントを作成します。

後で TLS を設定するにはこのトラストポイントが必要です。 登録ベースのトランクの場合、 このトラストポイントは証明書ベースのトランクで必要な証明書を必要としません。


crypto pki trustpoint EmptyTP 
 revocation-check none
4

次の設定コマンドを使用して、TLS1.2の排他性を有効にし、デフォルトのトラストポイントを指定します。 登録のための信頼性の高い安全な接続を確保するために、トランスポートパラメータも更新する必要があります。

cn-san-validate serverコマンドは、テナント200に設定されたホスト名が、 アウトバウンドプロキシから受信した証明書のCNまたはSANフィールドに含まれている場合、 ローカルゲートウェイが接続を許可することを確認します。

  1. TCP リトライ回数を1000（5ミリ秒の倍数 = 5秒）に設定します。

  2. timer connection establishコマンドを使用すると、 LGWがプロキシとの接続を設定してから次に利用可能なオプションを検討するまでの時間を調整できます。 このタイマーのデフォルトは20秒、最小は5秒です。 低い値から始めて、 ネットワークの状態に合わせて必要に応じて増やしてください。


sip-ua
 timers connection establish tls 5
 transport tcp tls v1.2
 crypto signaling default trustpoint EmptyTP cn-san-validate server
 tcp-retry 1000

5

が使用するDigiCert CA証明書を含むCiscoルートCAバンドルをインストールしてください。 Webex Calling crypto pki trustpool import clean urlコマンドを使用して、指定されたURLからルートCAバンドルをダウンロードし、 現在のCAトラストプールをクリアしてから、新しい証明書バンドルをインストールしてください。

HTTPSを使用してインターネットにアクセスするためにプロキシを使用する必要がある場合は、CAバンドルをインポートする前に次の設定を追加してください。

ip http クライアントプロキシサーバー yourproxy.com プロキシポート 80 

ip http client source-interface GigabitEthernet0/0/1 
crypto pki trustpool import clean url https://www.cisco.com/security/pki/trs/ios_core.p7b
Webex Calling登録ベースのトランクを設定してください
1

コントロールハブの既存の場所用に、登録ベースのPSTNトランクを作成します。 トランクが作成されたら提供されるトランク情報を書き留めておいてください。 図で強調表示されている詳細は、 このガイドの設定手順で使用されます。 詳細については、「トランク、ルートグループ、 ダイヤルプランの設定」を参照してください。Webex Calling

PSTN trunk registered
2

次のコマンドを入力して、Webex Calling CUBEをローカルゲートウェイとして設定します。

 
voice service voip
 ip address trusted list
  ipv4 x.x.x.x y.y.y.y
 mode border-element
 media statistics
 media bulk-stats 
 allow-connections sip to sip
 no supplementary-service sip refer  
 stun
  stun flowdata agent-id 1 boot-count 4
  stun flowdata shared-secret 0 Password123$
 sip
  asymmetric payload full
  early-offer forced

設定用のフィールドの説明は次のとおりです。


ip address trusted list
 ipv4 x.x.x.x y.y.y.y

  • 通話詐欺を防ぐため、信頼できるアドレスリストでは、 ローカルゲートウェイが正当なVoIP通話を期待するホストとネットワークのリストを定義します。

  • デフォルトでは、 ローカルゲートウェイは信頼リストにないIPアドレスからのすべての着信VoIPメッセージをブロックします。 デフォルトでは、「セッションターゲットIP」 またはサーバーグループのIPアドレスを持つ静的に設定されたダイヤルピアが信頼されます。 これらのIPアドレスを信頼リストに追加する必要はありません。

  • ローカルゲートウェイを設定するときは、 Webex Calling地域のデータセンターのIPサブネットをリストに追加してください。 詳細については 、のポートリファレンス情報を参照してくださいWebex Calling。 また、 ユニファイドコミュニケーションマネージャーサーバー（使用している場合） とPSTNトランクゲートウェイのアドレス範囲を追加してください。

    LGWが制限されたコーンNATを備えたファイアウォールの背後にある場合は、 Webex Calling対面インターフェイスのIPアドレスの信頼リストを無効にしたほうがいいかもしれません。 ファイアウォールはすでに、 一方的なインバウンドVoIPからあなたを保護しています。 無効にすると、 ピアのアドレスが固定されることを保証できず、Webex Calling どのような場合でもピア用にファイアウォールを設定する必要があるため、長期的な構成のオーバーヘッドが軽減されます。

モードボーダーエレメント

プラットフォームで Cisco Unified Border Element (CUBE) 機能を有効にします。

メディア統計

ローカルゲートウェイでメディアモニタリングを有効にします。

メディア一括統計情報

コントロールプレーンがデータプレーンをポーリングして一括コール統計を取得できるようにします。

これらのコマンドの詳細については、「メディア」を参照してください。

接続を許可する-スキップ・ツー・シップ

CUBEの基本的なSIPバック・ツー・バック・ユーザー・エージェント機能を有効にします。 詳しくは、「接続を許可する」を参照してください。

デフォルトでは、T.38のファックス転送は有効になっています。 詳細については、 ファックスプロトコル t38 （音声サービス）を参照してください。

気絶させます

STUN（ NATを介したUDPのセッショントラバーサル）をグローバルに有効にします。

  • ローカルゲートウェイのSTUNバインディング機能を使用すると、 ローカルで生成されたSTUNリクエストをネゴシエートされたメディアパスを介して送信できます。 これはファイアウォールのピンホールを開くのに役立ちます。

詳細については、「スタンフローデータエージェントID」と「スタンフローデータ共有シークレット」を参照してください。

非対称ペイロードフル

DTMFペイロードとダイナミックコーデックペイロードの両方のSIP非対称ペイロードサポートを設定します。 詳細については、 非対称ペイロードを参照してください。

アーリーオファーが強制されます

ローカルゲートウェイに、 隣接するピアからの確認を待つのではなく、最初の INVITE メッセージでSDP情報を送信するように強制します。 このコマンドの詳細については、early-offer を参照してください。

3

すべてのトランクに G.711 コーデックのみを許可する音声クラスコーデック 100 を設定します。 このシンプルなアプローチは、ほとんどの導入に適しています。 必要に応じて、 発信側システムと終端側システムの両方でサポートされている追加のコーデックタイプをリストに追加できます。

DSPモジュールを使用したトランスコーディングを含む、 より複雑なソリューションもサポートされていますが、このガイドには含まれていません。 


voice class codec 100
 codec preference 1 g711ulaw
 codec preference 2 g711alaw

設定用のフィールドの説明は次のとおりです。

音声クラスコーデック 100

SIPトランクコールに優先コーデックのみを許可するために使用されます。 詳細については、 音声クラスコーデックを参照してください。

4

トランクでICEを有効にするには、ボイスクラスのstun-usage 100を設定してください。Webex Calling


voice class stun-usage 100 
 stun usage firewall-traversal flowdata
 stun usage ice lite

設定用のフィールドの説明は次のとおりです。

スタン使用法、アイスライト

可能な限りメディアを最適化できるように、 Webex Calling向かい合っているすべてのダイヤルピアでICE-Liteを有効にしていました。 詳細については、ボイスクラスのスタン使用法とスタン使用量「ice lite」を参照してください。

メディアの最適化は可能な限り交渉されます。 通話に録音などのクラウドメディアサービスが必要な場合、 メディアは最適化できません。

5

Webex トラフィックのメディア暗号化ポリシーを設定します。


voice class srtp-crypto 100
 crypto 1 AES_CM_128_HMAC_SHA1_80

設定用のフィールドの説明は次のとおりです。

ボイスクラス srtp-crypto 100

SHA1_80 オファーメッセージとアンサーメッセージでSDPでCUBEが提供している唯一のSRTP暗号スイートとして指定します。 Webex Callingサポートのみです SHA1_80。 詳細については、音声クラス srtp-crypto を参照してください。

6

宛先トランクのパラメータに基づいてローカルゲートウェイトランクへのコールを識別するパターンを設定します。 


voice class uri 100 sip
 pattern dtg=dallas1463285401_lgu

設定用のフィールドの説明は次のとおりです。

ボイスクラス URI 100 チップ

着信したSIP招待を着信トランクのダイヤルピアと一致させるパターンを定義します。 このパターンを入力するときは、 dtg=の後にトランクが作成されたときにコントロールハブで提供されたトランクのOTG/DTG値を続けてください。 詳しくは、ボイスクラスのURIを参照してください。

7

SIPメッセージが送信される前に変更するために使用されるSIPプロファイル100を設定しますWebex Calling。


voice class sip-profiles 100
 rule 10 request ANY sip-header SIP-Req-URI modify "sips:" "sip:"
 rule 20 request ANY sip-header To modify "<sips:" "<sip:"
 rule 30 request ANY sip-header From modify "<sips:" "<sip:"
 rule 40 request ANY sip-header Contact modify "<sips:(.*)>" "<sip:\1;transport=tls>" 
 rule 50 response ANY sip-header To modify "<sips:" "<sip:"
 rule 60 response ANY sip-header From modify "<sips:" "<sip:"
 rule 70 response ANY sip-header Contact modify "<sips:" "<sip:"
 rule 80 request ANY sip-header From modify ">" ";otg=dallas1463285401_lgu>"
 rule 90 request ANY sip-header P-Asserted-Identity modify "sips:" "sip:"

設定用のフィールドの説明は次のとおりです。

  • ルール10から70と90まで

    コールシグナリングに使用されるSIPヘッダーが、Webexプロキシが必要とするSIPスキームではなく、 SIPスキームを使用するようにします。 SIPを使用するようにCUBEを設定すると、安全な登録が確実に使用されます。

  • ルール 80

    企業内のローカルゲートウェイサイトを一意に識別するために、 コントロールハブのトランクグループOTG/DTG識別子を含むようにFromヘッダーを変更します。

米国またはカナダのPSTNプロバイダーは、記事の「迷惑電話または詐欺電話表示」 に記載されている追加設定で、 スパムや詐欺電話の発信者ID認証を提供できます。 Webex Calling

8

Webex Callingトランクの設定:

  1. ボイスクラステナント100を作成して、 Webex Callingトランクに特に必要な設定を定義してグループ化します。 特に、 前にコントロールハブで提供されたトランク登録の詳細は、以下に詳述するように、このステップで使用されます。 このテナントに関連付けられているダイヤルピアは、後でこれらの設定を継承します。

    次の例では、 このガイドの目的のためにステップ1で示した値を使用しています（太字で表示）。 これらを、 構成内のトランクの値に置き換えてください。

    
voice class tenant 100
  registrar dns:98027369.us10.bcld.webex.com scheme sips expires 240 refresh-ratio 50 tcp tls
  credentials number Dallas1171197921_LGU username Dallas1463285401_LGU password 0 9Wt[M6ifY+ realm BroadWorks
  authentication username Dallas1463285401_LGU password 0 9Wt[M6ifY+ realm BroadWorks
  authentication username Dallas1463285401_LGU password 0 9Wt[M6ifY+ realm 98027369.us10.bcld.webex.com
  no remote-party-id
  sip-server dns:98027369.us10.bcld.webex.com
  connection-reuse
  srtp-crypto 100
  session transport tcp tls 
  no session refresh
  url sips 
  error-passthru
  rel1xx disable
  asserted-id pai 
  bind control source-interface GigabitEthernet0/0/1
  bind media source-interface GigabitEthernet0/0/1
  no pass-thru content custom-sdp 
  sip-profiles 100 
  outbound-proxy dns:dfw04.sipconnect-us.bcld.webex.com  
  privacy-policy passthru

    設定用のフィールドの説明は次のとおりです。

    ボイスクラステナント 100

    Webex Callingトランクにのみ使用される設定パラメータのセットを定義します。 詳しくは、 ボイスクラステナントを参照してください。

    レジストラ DNS: 98027369.us10.bcld.webex.com スキームスキップの有効期限 240 リフレッシュ比 50 TCP TLS

    登録が2分ごと（240秒の 50%）に更新されるように設定されているローカルゲートウェイのレジストラサーバー。 詳細については、レジストラを参照してください。

    ここのコントロールハブのドメイン登録値を必ず使用してください。

    Dallas1171197921_LGU Dallas1463285401_LGU 資格情報番号ユーザー名パスワード 0 9Wt [ M6ify+ レルム ブロードワークス

    トランク登録チャレンジの資格情報。 詳細については、資格情報（SIP UA）を参照してください。

    ここでは、 コントロールハブの回線/ポートホスト、 認証ユーザー名、 認証パスワードの値をそれぞれ使用してください。

    認証、ユーザー名、 Dallas1171197921_LGU パスワード 0 9Wt [ M6ify+] レルム-ブロードワークス
    Dallas1171197921_LGU 認証ユーザー名パスワード 0 9Wt [ M6ify+ レルム] 98027369.us10.bcld.webex.com

    通話の認証チャレンジ。 詳細については、認証 (ダイヤルピア) を参照してください。

    ここでは、 コントロールハブの認証ユーザー名、認証パスワード、 レジストラードメインの値をそれぞれ使用してください。

    リモートパーティIDはありません

    Webex CallingPAIをサポートしているので、SIPリモートパーティID （RPID）ヘッダーを無効にしてください。PAIは、アサーテッドID paiを使用して有効になります。 詳細については、リモートパーティーIDを参照してください。

    シップサーバーのDNS: us25.sipconnect.bcld.webex.com

    トランクのターゲットSIPサーバーを設定します。 トランクを作成したときにコントロールハブで提供されたEdgeプロキシSRVアドレスを使用してください。

    接続の再利用

    登録と通話処理に同じ固定接続を使用します。 詳しくは、「接続の再利用」を参照してください。

    stp-crypto 100さん

    SRTPコールレッグ（接続）（ステップ5で指定） の優先暗号スイートを設定します。 詳細については、音声クラス srtp-crypto を参照してください。

    セッショントランスポート TCP TLS

    トランスポートをTLSに設定します。 詳細については、 セッショントランスポートを参照してください。

    セッション更新なし

    CUBE と Webex 間の通話の SIP セッション更新を無効にします。 詳しくは、 セッションの更新を参照してください。

    カール・シップス

    SRVクエリは、 アクセスSBCでサポートされているSIPでなければなりません。他のすべてのメッセージは、sip-profile 200によってSIPに変更されます。

    エラーパススルー

    SIPエラー応答パススルー機能を指定します。 詳細については、 エラーパススルーを参照してください。

    rel1xx 無効にします

    トランクでの信頼できる暫定応答の使用を無効にします。Webex Calling 詳細については、rel1xxを参照してください。

    アサーテッドIDペイ

    （オプション） P-Asserted-Identityヘッダー処理をオンにして、 これがトランクにどのように使用されるかを制御します。Webex Calling

    Webex Callingローカルゲートウェイへのアウトバウンドコールへの招待に、 P-Asserted-Identity（PAI）ヘッダーを含みます。

    このコマンドを設定すると、 PAIヘッダーの発信者情報を使用して、 送信されるFromヘッダーとPAI/Remote-Party-IDヘッダーが入力されます。

    このコマンドが設定されていない場合は、Fromヘッダーの発信者情報を使用して、 送信FromヘッダーとPAI/Remote-Party-IDヘッダーが入力されます。

    詳細については、asserted-idを参照してください。

    バインドコントロールソースインターフェイスギガビットイーサネット 0/0/1

    送信先のメッセージの送信元インターフェイスと関連するIPアドレスを設定します。 Webex Calling 詳しくは、bindを参照してください。

    バインドメディアソースインターフェイスギガビットイーサネット 0/0/1

    WebExcallingに送信されるメディアのソースインターフェイスと関連するIPアドレスを設定します。 詳しくは、bindを参照してください。

    パススルーコンテンツなし custom-sdp

    テナントの下のデフォルトコマンド。 このコマンドの詳細については、 パススルーの内容を参照してください。

    シッププロファイル 100

    SIPをSIPに変更し、 SIPプロファイル100で定義されているようにINVITEおよびREGISTERメッセージの回線/ポートを変更します。 詳しくは、 音声クラスのSIPプロファイルを参照してください。

    アウトバウンドプロキシ DNS : dfw04.sipconnect-us.bcld.webex.com

    Webex CallingSBCにアクセスしてください。 トランクを作成したときにコントロールハブで提供されたアウトバウンドプロキシアドレスを挿入します。 詳細については、 「アウトバウンドプロキシ」を参照してください。

    プライバシーポリシーパススルー

    受信したメッセージのプライバシー値を次のコールレッグに渡すように、 トランクのプライバシーヘッダーポリシーオプションを設定します。 詳細については、プライバシーポリシーを参照してください。

  2. Webex Callingトランクのダイヤルピアを設定してください。 

    
dial-peer voice 100 voip
 description Inbound/Outbound Webex Calling
 max-conn 250
 destination-pattern BAD.BAD
 session protocol sipv2
 session target sip-server
 incoming uri request 100
 voice-class codec 100
 dtmf-relay rtp-nte
 voice-class stun-usage 100
 no voice-class sip localhost
 voice-class sip tenant 100
 srtp
 no vad

    設定用のフィールドの説明は次のとおりです。

    
dial-peer voice 100 voip
  description Inbound/Outbound Webex Calling

    タグ100のVoIPダイヤルピアを定義し、 管理とトラブルシューティングを容易にするためにわかりやすい説明を付けます。

    マックスコン 250%

    LGWと間の同時インバウンドコールとアウトバウンドコールの数を制限します。Webex Calling 登録トランクでは、最大値は250に設定する必要があります。 導入環境に適している場合は、値を小さくしてください。 ローカルゲートウェイの同時通話制限の詳細については、「 ローカルゲートウェイ入門」を参照してください。

    デスティネーションパターン BAD.BAD

    着信ダイヤルピアグループを使用して発信通話をルーティングする場合は、 ダミーの宛先パターンが必要です。 この場合、任意の有効な宛先パターンを使用できます。 詳しくは、デスティネーションパターン (インターフェイス) を参照してください。

    セッションプロトコル sipv2

    ダイヤルピア 100 が SIP コールレッグを処理するように指定します。 詳細については、セッションプロトコル (ダイヤルピア) を参照してください。

    セッションターゲット SIPサーバー

    テナント100で定義されているSIPサーバーが継承され、 このダイヤルピアからの通話の宛先に使用されることを示します。 詳細については、セッションターゲット（ VoIPダイヤルピア）を参照してください。

    受信したURIリクエスト 100%

    VoIPダイヤルピアを着信通話のユニフォームリソース識別子（URI） と照合するために使用される音声クラスを指定します。 詳細については、「 受信URI」を参照してください。

    音声クラスコーデック 100

    共通コーデックフィルタリスト 100 を使用するようにダイヤルピアを設定します。 詳細については、 音声クラスのコーデックを参照してください。

    ボイスクラスのスタン使い方 100

    ローカルゲートウェイでローカルに生成されたSTUNリクエストを、 ネゴシエートされたメディアパスを介して送信できます。 STUNは、メディアトラフィックのファイアウォールのピンホールを開くのに役立ちます。 詳しくは、ボイスクラスのスタン使い方を参照してください 。

    音声クラスなし SIP ローカルホスト

    送信メッセージの From、Call-ID、Remote-Party-ID ヘッダーの物理IPアドレスの代わりにDNSローカルホスト名を使用することを無効にします。

    ボイスクラスのシップテナント 100

    ダイヤルピアは、 グローバルおよびテナント100で設定されたすべてのパラメータを継承します。 パラメータはダイヤルピアレベルでオーバーライドできます。

    STP

    コールレッグのSRTPを有効にします。

    いいえ、悪いです

    音声アクティビティ検出を無効にします。

テナント100を定義し、SIP VoIPダイヤルピアを設定すると、ゲートウェイはへのTLS接続を開始します。Webex Calling この時点で、アクセスSBCは証明書をローカルゲートウェイに提示します。 ローカルゲートウェイは、Webex Calling 以前に更新されたCAルートバンドルを使用してアクセスSBC証明書を検証します。 証明書が認識されると、 Webex CallingローカルゲートウェイとアクセスSBCの間で永続的なTLSセッションが確立されます。 これで、 ローカルゲートウェイはこの安全な接続を使用して、Webex access SBCに登録できます。 認証のために登録が求められるとき：

  • 認証情報設定のユーザー名、パスワード、 レルムパラメーターが応答に使用されます。

  • SIPS URLをSIPSに戻すには、SIPSプロファイル100の変更ルールが使用されます。

アクセスSBCから200 OKを受信すると、登録は成功します。

Flow diagram of authentication and registration of Webex Calling with Local gateway

SIP PSTNトランクでローカルゲートウェイを設定してください

Webex Calling上記のようにトランクを構築したら、次の構成を使用して、 SIPベースのPSTNプロバイダーへの暗号化されていないトランクを作成します。

サービスプロバイダーが安全なPSTNトランクを提供している場合は、 トランクについて上記で説明したのと同様の設定に従うことができます。Webex Calling CUBEは安全な通話ルーティングをサポートしています。

TDM/ISDN PSTNトランクを使用している場合は、次のセクション「TDM PSTNトランクを使ったローカルゲートウェイの設定」に進んでください。

Cisco TDM-SIPゲートウェイのPSTNコールレッグ用のTDMインターフェイスを設定するには、ISDN PRIの設定を参照してください。

1

PSTNトランクからの着信コールを識別するには、次の音声クラスURIを設定してください。


voice class uri 200 sip
  host ipv4:192.168.80.13

設定用のフィールドの説明は次のとおりです。

ボイスクラス URI 200 チップ

着信したSIP招待を着信トランクのダイヤルピアと一致させるパターンを定義します。 このパターンを入力するときは、IP PSTNゲートウェイのIPアドレスを使用してください。 詳しくは、ボイスクラスのURIを参照してください。

2

次のIP PSTNダイヤルピアを設定します。


dial-peer voice 200 voip
 description Inbound/Outbound IP PSTN trunk
 destination-pattern BAD.BAD
 session protocol sipv2
 session target ipv4:192.168.80.13
 incoming uri via 200
 voice-class sip asserted-id pai
 voice-class sip bind control source-interface GigabitEthernet0/0/0 
 voice-class sip bind media source-interface  GigabitEthernet0/0/0 
 voice-class codec 100
 dtmf-relay rtp-nte 
 no vad

設定用のフィールドの説明は次のとおりです。


dial-peer voice 200 voip
 description Inbound/Outbound IP PSTN trunk

タグ200のVoIPダイヤルピアを定義し、 管理とトラブルシューティングを容易にするためにわかりやすい説明を付けます。 詳細については、 ダイヤルピアボイスを参照してください。

デスティネーションパターン BAD.BAD

着信ダイヤルピアグループを使用して発信通話をルーティングする場合は、 ダミーの宛先パターンが必要です。 この場合、任意の有効な宛先パターンを使用できます。 詳しくは、デスティネーションパターン (インターフェイス) を参照してください。

セッションプロトコル sipv2

このダイヤルピアが SIP コールレッグを処理することを指定します。 詳細については、セッションプロトコル（ ダイヤルピア）を参照してください。

セッションターゲット ipv4: 192.168.80.13

PSTNプロバイダーに送信される通話の宛先アドレスを指定します。 これは、 IPアドレスでもDNSホスト名でもかまいません。 詳細については、セッションターゲット ( VoIPダイヤルピア) を参照してください。

200経由でURIが届きます

INVITE VIAヘッダーURIを使用して、 着信コールをこのダイヤルピアに一致させるために使用される音声クラスを指定します。 詳しくは、受信URLを参照してください。

ボイスクラスシップアサーテッドIDペア

（オプション） P-Asserted-Identityヘッダー処理をオンにして、これがPSTNトランクにどのように使用されるかを制御します。 このコマンドを使用すると、 着信ダイヤルピアから提供された発信側のIDが、 発信FromヘッダーとP-Asserted-Identityヘッダーに使用されます。 このコマンドを使用しない場合、 着信ダイヤルピアから提供された発信側のIDが、 発信FromヘッダーとRemote-Party-IDヘッダーに使用されます。 詳細については、ボイスクラス SIP アサーテッドIDを参照してください。

バインドコントロールソースインターフェイスギガビットイーサネット 0/0/0

PSTNに送信されるメッセージの送信元インターフェイスと関連するIPアドレスを設定します。 詳しくは、bindを参照してください。

バインドメディアソースインターフェイスギガビットイーサネット 0/0/0

PSTNに送信されるメディアのソースインターフェイスと関連するIPアドレスを設定します。 詳しくは、bindを参照してください。

音声クラスコーデック 100

共通コーデックフィルタリスト 100 を使用するようにダイヤルピアを設定します。 詳細については、 音声クラスのコーデックを参照してください。

DTMF-リレー rtp-nte

RTP-NTE（RFC2833）を、コールレッグで期待されるDTMF機能として定義しています。 詳細については、「DTMFリレー（ ボイスオーバーIP）」を参照してください。

いいえ、悪いです

音声アクティビティ検出を無効にします。 詳細については、vad (ダイヤルピア) を参照してください。

3

Webex CallingとPSTN間の通話のみをルーティングするようにローカルゲートウェイを設定する場合は、次の通話ルーティング設定を追加してください。 ユニファイドコミュニケーションマネージャープラットフォームでローカルゲートウェイを設定する場合は、 次のセクションに進んでください。

  1. ダイヤルピアグループを作成して、Webex Calling通話をPSTNにルーティングします。 DPG 100をアウトバウンドダイヤルピア100に定義してください。Webex Calling DPG 100は、PSTNからの着信ダイヤルピアに適用されます。 同様に、PSTNへのアウトバウンドダイヤルピア200を備えたDPG 200を定義してください。 DPG 200は、 Webexからの着信ダイヤルピアに適用されます。

    
voice class dpg 100 
 description Route calls to Webex Calling 
 dial-peer 100 
voice class dpg 200 
 description Route calls to PSTN 
 dial-peer 200

    設定用のフィールドの説明は次のとおりです。

    ダイヤルピア 100

    アウトバウンドダイヤルピアをダイヤルピアグループに関連付けます 。 詳細については、 ボイスクラスのDPGを参照してください。

  2. ダイヤルピアグループを適用して、Webex から PSTN に、および PSTN から Webex に通話をルーティングします。 

    
dial-peer voice 100
 destination dpg 200
dial-peer voice 200
 destination dpg 100

    設定用のフィールドの説明は次のとおりです。

    デスティネーション・ドッグ 200

    どのダイヤルピアグループ 、 つまりこの着信ダイヤルピアに送られるコールの発信処理にダイヤルピアを使用するかを指定します。

    これで、ローカルゲートウェイの設定は終了です。 CUBEの機能を初めて設定する場合は、 設定を保存してプラットフォームをリロードしてください。

TDM PSTNトランクでローカルゲートウェイを設定してください

に向けてトランクを構築したらWebex Calling、次の設定を使用して、Webexコールレッグでメディアを最適化できるように、 ループバックコールルーティングを備えたPSTNサービス用のTDMトランクを作成します。

IPメディア最適化が必要ない場合は、SIP PSTNトランクの設定手順に従ってください。 PSTN VoIPダイヤルピアの代わりに音声ポートとPOTSダイヤルピア（手順2と3を参照）を使用してください。

1

ループバックダイヤルピア設定では、ダイヤルピアグループとコールルーティングタグを使用して、 コールルーティングループを作らずにコールがWebexとPSTNの間で正しく渡されるようにします。 コールルーティングタグの追加と削除に使用される次の変換ルールを設定します。


voice translation-rule 100 
 rule 1 /^\+/ /A2A/ 

voice translation-profile 100 
 translate called 100 

voice translation-rule 200 
 rule 1 /^/ /A1A/ 

voice translation-profile 200 
 translate called 200 

voice translation-rule 11 
 rule 1 /^A1A/ // 

voice translation-profile 11 
 translate called 11 

voice translation-rule 12 
 rule 1 /^A2A44/ /0/
 rule 2/^A2A/ /00/

voice translation-profile 12 
 translate called 12

設定用のフィールドの説明は次のとおりです。

音声翻訳ルール

ルールで定義された正規表現を使用して、通話ルーティングタグを追加または削除します。 トラブルシューティングをわかりやすくするために、10進数を超える数字（「A」）が使用されます。

この設定では、 translation-profile 100によって追加されたタグを使用して、Webex Callingループバックダイヤルピアを介して発信元からPSTNにコールを誘導します。 同様に、トランスレーションプロファイル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に取り付けられたPrimary Rate ISDNインターフェイスの基本構成には、 次のものが含まれる場合があります。


card type e1 0 2 
isdn switch-type primary-net5 
controller E1 0/2/0 
 pri-group timeslots 1-31
3

次の TDM PSTN ダイヤルピアを設定します。


dial-peer voice 200 pots 
 description Inbound/Outbound PRI PSTN trunk 
 destination-pattern BAD.BAD 
 translation-profile incoming 200 
 direct-inward-dial 
 port 0/2/0:15

設定用のフィールドの説明は次のとおりです。 


dial-peer voice 200 pots
 description Inbound/Outbound PRI PSTN trunk

タグ200のVoIPダイヤルピアを定義し、 管理とトラブルシューティングを容易にするためにわかりやすい説明を付けます。 詳細については、ダイヤルピアボイスを参照してください。

デスティネーションパターン BAD.BAD

着信ダイヤルピアグループを使用して発信通話をルーティングする場合は、 ダミーの宛先パターンが必要です。 この場合、任意の有効な宛先パターンを使用できます。 詳しくは、デスティネーションパターン (インターフェイス) を参照してください。

翻訳プロフィールが200件届きます

着信着信番号にコールルーティングタグを追加するトランスレーションプロファイルを割り当てます。

ダイレクトインワードダイヤル

セカンダリダイヤルトーンを提供せずに通話をルーティングします。 詳しくは、「ダイレクト・インワードダイヤル」を参照してください。

ポート 0/2/ 0:15

このダイヤルピアに関連付けられている物理的な音声ポート。

4

TDM-IPコールフローを使用してローカルゲートウェイのIPパスのメディア最適化を有効にするには、とPSTNトランク間に内部ループバックダイヤルピアを導入して、 コールルーティングを変更できます。 Webex Calling 次のループバックダイヤルピアを設定します。 この場合、 すべての着信コールは最初にダイヤルピア10にルーティングされ、 そこから適用されたルーティングタグに基づいてダイヤルピア11または12にルーティングされます。 ルーティングタグを削除すると、 コールはダイヤルピアグループを使用して発信トランクにルーティングされます。


dial-peer voice 10 voip
 description Outbound loop-around leg
 destination-pattern BAD.BAD
 session protocol sipv2
 session target ipv4:192.168.80.14
 voice-class sip bind control source-interface GigabitEthernet0/0/0
 voice-class sip bind media source-interface GigabitEthernet0/0/0
 dtmf-relay rtp-nte
 codec g711alaw
 no vad 

dial-peer voice 11 voip
 description Inbound loop-around leg towards Webex
 translation-profile incoming 11
 session protocol sipv2
 incoming called-number A1AT
 voice-class sip bind control source-interface GigabitEthernet0/0/0
 voice-class sip bind media source-interface GigabitEthernet0/0/0
 dtmf-relay rtp-nte
 codec g711alaw
 no vad 

dial-peer voice 12 voip
 description Inbound loop-around leg towards PSTN
 translation-profile incoming 12
 session protocol sipv2
 incoming called-number A2AT
 voice-class sip bind control source-interface GigabitEthernet0/0/0
 voice-class sip bind media source-interface GigabitEthernet0/0/0
 dtmf-relay rtp-nte
 codec g711alaw 
 no vad

設定用のフィールドの説明は次のとおりです。 


dial-peer voice 10 voip
 description Outbound loop-around leg

VoIPダイヤルピアを定義し、管理とトラブルシューティングを容易にするためにわかりやすい説明をしています。 詳細については、ダイヤルピアボイスを参照してください。

翻訳プロフィールが11件届きます

先に定義したトランスレーションプロファイルを適用して、 発信トランクに渡す前にコールルーティングタグを削除します。

デスティネーションパターン BAD.BAD

着信ダイヤルピアグループを使用して発信通話をルーティングする場合は、 ダミーの宛先パターンが必要です。 詳しくは、デスティネーションパターン (インターフェイス) を参照してください。

セッションプロトコル sipv2

このダイヤルピアが SIP コールレッグを処理することを指定します。 詳細については、セッションプロトコル（ ダイヤルピア）を参照してください。

セッションターゲット ipv4: 192.168.80.14

ローカルルーターのインターフェイスアドレスをループバックするコールターゲットとして指定します 。 詳細については、セッションターゲット（ VoIPダイヤルピア）を参照してください。

バインドコントロールソースインターフェイスギガビットイーサネット 0/0/0

ループバックを介して送信されるメッセージの送信元インターフェイスと関連するIPアドレスを設定します。 詳しくは、bindを参照してください。

バインドメディアソースインターフェイスギガビットイーサネット 0/0/0

ループバックを介して送信されるメディアのソースインターフェイスと関連するIPアドレスを設定します。 詳しくは、bindを参照してください。

DTMF-リレー rtp-nte

RTP-NTE（RFC2833）を、コールレッグで期待されるDTMF機能として定義しています。 詳細については、「DTMFリレー（ ボイスオーバーIP）」を参照してください。

コーデック g711alaw

すべてのPSTNコールにG.711を使用するように強制します。 ISDNサービスで使用されているコンパンド方法に合わせて、a-lawまたはu-lawを選択してください。

いいえ、悪いです

音声アクティビティ検出を無効にします。 詳細については、vad (ダイヤルピア) を参照してください。

5

次のコールルーティング設定を追加してください：

  1. ダイヤルピアグループを作成して、PSTNとWebexトランク間の通話をループバック経由でルーティングします。

    
voice class dpg 100
 description Route calls to Webex Calling
 dial-peer 100
voice class dpg 200
 description Route calls to PSTN
 dial-peer 200
voice class dpg 10
 description Route calls to Loopback
 dial-peer 10

    設定用のフィールドの説明は次のとおりです。

    ダイヤルピア 100

    アウトバウンドダイヤルピアをダイヤルピアグループに関連付けます 。 詳細については、 ボイスクラスのDPGを参照してください。

  2. コールをルーティングするためにダイヤルピアグループを適用します。

    
dial-peer voice 100
 destination dpg 10
dial-peer voice 200
 destination dpg 10
dial-peer voice 11
 destination dpg 100
dial-peer voice 12
 destination dpg 200

    設定用のフィールドの説明は次のとおりです。

    デスティネーション・ドッグ 200

    どのダイヤルピアグループ 、 つまりこの着信ダイヤルピアに送られるコールの発信処理にダイヤルピアを使用するかを指定します。

これで、ローカルゲートウェイの設定は終了です。 CUBEの機能を初めて設定する場合は、 設定を保存してプラットフォームをリロードしてください。
Unified CMローカルゲートウェイを既存の環境に設定してください

Webex Calling前のセクションのPSTN-設定は、Cisco Unified Communications Manager（UCM ）クラスタへのトランクを追加するように変更できます。 この場合、Unified CMすべての通話は経由でルーティングされます。 ポート5060のUCMからのコールはPSTNにルーティングされ、ポート5065からのコールはにルーティングされます。Webex Calling この通話シナリオを含めるために、 次の段階的な構成を追加できます。

Webex Calling でトランクを作成するときはUnified CM、 SIPトランクのセキュリティプロファイルの受信ポートを5065に設定してください。 これにより、ポート5065でメッセージが受信できるようになり、 ローカルゲートウェイにメッセージを送信するときにこの値がVIAヘッダーに入力されます。

Enter SIP trunk security profile information
1

次の音声クラスURIを設定してください：

  1. SIP Unified CM VIAポートを使用してWebexコールに分類します。

    
voice class uri 300 sip
 pattern :5065

  2. Unified CMポート経由のSIPを使用してPSTNコールに分類します：

    
voice class uri 400 sip
 pattern 192\.168\.80\.6[0-5]:5060

    発信元のアドレスとポート番号を説明する1つ以上のパターンを使用して、UCMからPSTNトランクへの着信メッセージを分類します。 必要に応じて、 正規表現を使用してマッチングパターンを定義できます。

    上の例では、 192.168.80.60から65までの範囲のIPアドレスとポート番号5060の任意のIPアドレスと照合するために正規表現が使用されています。

2

Unified CM ホストへのSRVルーティングを指定するには、次のDNSレコードを設定します。

IOS XEはこれらのレコードを使用して、 ターゲットUCMホストとポートをローカルで決定します。 この設定では、 DNSシステムにレコードを設定する必要はありません。 DNSを使用したい場合は、 これらのローカル設定は必要ありません。


ip host ucmpub.mydomain.com 192.168.80.60
ip host ucmsub1.mydomain.com 192.168.80.61
ip host ucmsub2.mydomain.com 192.168.80.62
ip host ucmsub3.mydomain.com 192.168.80.63
ip host ucmsub4.mydomain.com 192.168.80.64
ip host ucmsub5.mydomain.com 192.168.80.65
ip host _sip._udp.wxtocucm.io srv 0 1 5065 ucmpub.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub1.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub2.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub3.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub4.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub5.mydomain.com
ip host _sip._udp.pstntocucm.io srv 0 1 5060 ucmpub.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub1.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub2.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub3.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub4.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub5.mydomain.com

設定用のフィールドの説明は次のとおりです。

次のコマンドは、DNS SRVリソースレコードを作成します。 UCMホストとトランクごとにレコードを作成してください：

ip host _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 host ucmsub5.mydomain.com 192.168.80.65

ip host: ローカルの IOS XE データベースにレコードを作成します。

ucmsub5.mydomain.com: Aレコードのホスト名。

192.168.80.65: ホストのIPアドレスです。

UCM環境と希望する通話分散戦略を反映したSRVリソースレコードとAレコードを作成してください。

3

次のダイヤルピアを設定します。

  1. Unified CMととの間の通話のダイヤルピア Webex Calling

    
dial-peer voice 300 voip
 description UCM-Webex Calling trunk
 destination-pattern BAD.BAD
 session protocol sipv2
 session target dns:wxtocucm.io
 incoming uri via 300
 voice-class codec 100
 voice-class sip bind control source-interface GigabitEthernet 0/0/0
 voice-class sip bind media source-interface GigabitEthernet 0/0/0
 dtmf-relay rtp-nte
 no vad

    設定用のフィールドの説明は次のとおりです。

    
dial-peer voice 300 voip
 description UCM-Webex Calling trunk

    300というタグでVoIPダイヤルピアを定義し、 管理とトラブルシューティングを容易にするためにわかりやすい説明を付けます。

    デスティネーションパターン BAD.BAD

    着信ダイヤルピアグループを使用して発信通話をルーティングする場合は、 ダミーの宛先パターンが必要です。 この場合、任意の有効な宛先パターンを使用できます。

    セッションプロトコル sipv2

    ダイヤルピア300がSIPコールレッグを処理することを指定します。 詳細については、セッションプロトコル (ダイヤルピア) を参照してください。

    セッションターゲット DNS: wxtocucm.io

    Unified CMDNS SRV解像度によって複数のノードのセッションターゲットを定義します。 この場合、 ローカルで定義されたSRVレコードwxtocucm.ioがダイレクトコールに使用されます。

    300経由でURIが届きます

    音声クラス URI 300を使用して、Unified CM 送信元ポート5065を使用するすべての着信トラフィックをこのダイヤルピアに転送します。 詳細については、「 受信URI」を参照してください。

    音声クラスコーデック 100

    Unified CM宛先のコールと発信元のコーデックフィルターリストを示します。 詳細については、 音声クラスコーデックを参照してください。

    バインドコントロールソースインターフェイスギガビットイーサネット 0/0/0

    PSTNに送信されるメッセージの送信元インターフェイスと関連するIPアドレスを設定します。 詳しくは、bindを参照してください。

    バインドメディアソースインターフェイスギガビットイーサネット 0/0/0

    PSTNに送信されるメディアのソースインターフェイスと関連するIPアドレスを設定します。 詳しくは、bindを参照してください。

    DTMF-リレー rtp-nte

    RTP-NTE（RFC2833）を、コールレッグで期待されるDTMF機能として定義しています。 詳細については、「DTMFリレー（ ボイスオーバーIP）」を参照してください。

    いいえ、悪いです

    音声アクティビティ検出を無効にします。 詳細については、vad (ダイヤルピア) を参照してください。

  2. Unified CMと PSTN 間の通話用のダイヤルピア:

    
dial-peer voice 400 voip
 description UCM-PSTN trunk
 destination-pattern BAD.BAD
 session protocol sipv2
 session target dns:pstntocucm.io
 incoming uri via 400
 voice-class codec 100 
 voice-class sip bind control source-interface GigabitEthernet 0/0/0
 voice-class sip bind media source-interface GigabitEthernet 0/0/0
 dtmf-relay rtp-nte
 no vad

    設定用のフィールドの説明は次のとおりです。

    
dial-peer voice 400 voip
 description UCM-PSTN trunk

    400というタグでVoIPダイヤルピアを定義し、 管理とトラブルシューティングを容易にするためにわかりやすい説明を付けます。

    デスティネーションパターン BAD.BAD

    着信ダイヤルピアグループを使用して発信通話をルーティングする場合は、 ダミーの宛先パターンが必要です。 この場合、任意の有効な宛先パターンを使用できます。

    セッションプロトコル sipv2

    ダイヤルピア 400 が SIP コールレッグを処理するように指定します。 詳細については、セッションプロトコル (ダイヤルピア) を参照してください。

    セッションターゲット DNS: pstntocucm.io

    Unified CMDNS SRV解像度によって複数のノードのセッションターゲットを定義します。 この場合、 ローカルで定義されたSRVレコードpstntocucm.ioがダイレクトコールに使用されます。

    400経由でURIが届きます

    音声クラス URI 400を使用して、 Unified CM指定されたホストからのすべての着信トラフィックを、 送信元ポート5060を使用してこのダイヤルピアに転送します。 詳細については、「 受信URI」を参照してください。

    音声クラスコーデック 100

    Unified CM宛先のコールと発信元のコーデックフィルターリストを示します。 詳細については、 音声クラスコーデックを参照してください。

    バインドコントロールソースインターフェイスギガビットイーサネット 0/0/0

    PSTNに送信されるメッセージの送信元インターフェイスと関連するIPアドレスを設定します。 詳しくは、bindを参照してください。

    バインドメディアソースインターフェイスギガビットイーサネット 0/0/0

    PSTNに送信されるメディアのソースインターフェイスと関連するIPアドレスを設定します。 詳しくは、bindを参照してください。

    DTMF-リレー rtp-nte

    RTP-NTE（RFC2833）を、コールレッグで期待されるDTMF機能として定義しています。 詳細については、「DTMFリレー（ ボイスオーバーIP）」を参照してください。

    いいえ、悪いです

    音声アクティビティ検出を無効にします。 詳細については、vad (ダイヤルピア) を参照してください。

4

次の設定を使用してコールルーティングを追加します。

  1. Unified CMとの間で通話をルーティングするダイヤルピアグループを作成してください。Webex Calling DPG 100をアウトバウンドダイヤルピア100に定義してください。Webex Calling DPG 100は、 からの関連する着信ダイヤルピアに適用されます。Unified CM 同様に、DPG 300をアウトバウンドダイヤルピア300と定義してください。Unified CM DPG 300は、 Webexからの着信ダイヤルピアに適用されます。

    
voice class dpg 100
 description Route calls to Webex Calling
 dial-peer 100
voice class dpg 300
 description Route calls to Unified CM Webex Calling trunk
 dial-peer 300

  2. Unified CMとPSTNとの間で通話をルーティングするダイヤルピアグループを作成してください 。 PSTNへのアウトバウンドダイヤルピア200でDPG 200を定義してください。 DPG 200は、 からの関連する着信ダイヤルピアに適用されます。Unified CM 同様に、DPG 400をアウトバウンドダイヤルピア400と定義してください。Unified CM DPG 400は、 PSTNからの着信ダイヤルピアに適用されます。

    
voice class dpg 200
 description Route calls to PSTN
 dial-peer 200
voice class dpg 400
 description Route calls to Unified CM PSTN trunk
 dial-peer 400

    設定用のフィールドの説明は次のとおりです。

    ダイヤルピア 100

    アウトバウンドダイヤルピアをダイヤルピアグループに関連付けます 。 詳細については、 ボイスクラスのDPGを参照してください。

  3. ダイヤルピアグループを適用して、Webex から Webex Unified CM への通話と Webex からの通話をルーティングします。 Unified CM 

    
dial-peer voice 100
 destination dpg 300
dial-peer voice 300
 destination dpg 100

    設定用のフィールドの説明は次のとおりです。

    デスティネーション・ドッグ 300%

    どのダイヤルピアグループ 、 つまりこの着信ダイヤルピアに送られるコールの発信処理にダイヤルピアを使用するかを指定します。

  4. ダイヤルピアグループを適用して、PSTNからのコールをPSTNへ、Unified CM Unified CMまたはPSTNからPSTNにルーティングします。

    
dial-peer voice 200
 destination dpg 400
dial-peer voice 400
 destination dpg 200

    これで、ローカルゲートウェイの設定は終了です。 CUBEの機能を初めて設定する場合は、設定を保存してプラットフォームをリロードしてください。

診断シグネチャを使ってローカルゲートウェイを監視し、トラブルシューティングします

Diagnostic Signatures（DS）は、IOS XEベースのローカルゲートウェイでよく見られる問題を積極的に検出し、そのイベントの電子メール、Syslog、またはターミナルメッセージ通知を生成します。 DSをインストールして診断データの収集を自動化し、Cisco TAC収集したデータをケースに転送して解決時間を短縮することもできます。

診断署名（DS）は、 問題のトリガーとなるイベントと、問題の通知、トラブルシューティング、および修復のために取るべきアクションに関する情報を含むXMLファイルです。 問題検出ロジックは、syslogメッセージ、SNMPイベント、 および特定のshowコマンドの出力を定期的に監視することで定義できます。

アクションタイプには、showコマンド出力の収集が含まれます。

  • 統合ログファイルの生成

  • HTTPS、SCP、FTPサーバーなど、ユーザーが提供するネットワークの場所にファイルをアップロードします。

TACのエンジニアは、完全性を保護するためにDSファイルを作成し、デジタル署名します。 各DSファイルには、システムによって割り当てられた一意の数値IDがあります。 診断署名検索ツール（DSLT）は、 さまざまな問題の監視とトラブルシューティングに適切な署名を見つけるための単一の情報源です。

始める前に:

  • DSLTからダウンロードしたDSファイルは編集しないでください。 変更したファイルは、 整合性チェックエラーのためにインストールに失敗します。

  • ローカルゲートウェイがメール通知を送信するために必要な簡易メール転送プロトコル（SMTP）サーバー。

  • メール通知に安全なSMTPサーバーを使用する場合は、ローカルゲートウェイでIOS XE 17.6.1以降が実行されていることを確認してください。

前提条件

IOS XE 17.6.1a以降を実行するローカルゲートウェイ

  1. 診断署名はデフォルトで有効になっています。

  2. Cisco IOSデバイスがXE 17.6.1a以降を実行している場合、プロアクティブな通知を送信するために使用する安全なメールサーバーを設定します。

    configure terminal 
call-home  
mail-server <username>:<pwd>@<email server> priority 1 secure tls 
end

  3. ds_email 通知する管理者のメールアドレスを環境変数に設定してください。 

    configure terminal 
call-home  
diagnostic-signature 
environment ds_email <email address> 
end

以下は、Cisco IOS XE 17.6.1a以降で動作するローカルゲートウェイの設定例で、Gmailを安全なSMTPサーバーとして使用して、プロアクティブな通知を tacfaststart@gmail.com に送信します。

Cisco IOSXEバンガロール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 IOSXEソフトウェア上で動作するローカルゲートウェイは、 OAuthをサポートする一般的なWebベースのGmailクライアントではありません。そのため、デバイスからのメールを正しく処理するには、 特定のGmailアカウント設定を行い、特定の権限を与える必要があります。

  1. [Googleアカウントの管理] > [セキュリティ] に移動し、[安全性の低いアプリアクセス ] 設定を有効にしてください。

  2. Gmailから「 Google以外のアプリを使用して誰かがあなたのアカウントにログインすることを許可しました」というメールを受け取ったら、「はい、私でした」と答えてください。

予防的な監視のために診断シグネチャをインストールしてください

高いCPU使用率の監視

このDSは、SNMP OID 1.3.6.1.4.1.9.2.1.56を使用して、CPU使用率を5秒間追跡します。 使用率が 75% 以上に達すると、 すべてのデバッグが無効になり、ローカルゲートウェイにインストールされているすべての診断シグネチャがアンインストールされます。 以下の手順で署名をインストールしてください。

  1. SNMPを有効にするには、show snmpコマンドを使用してください。 有効にしない場合は、snmp-server managerコマンドを設定してください。

    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

  2. 診断署名検索ツールの次のドロップダウンオプションを使用してDS 64224をダウンロードします。

    フィールド名

    フィールド値

    プラットフォーム

    シスコ4300、4400 ISRシリーズまたはシスコ CSR 1000Vシリーズ

    製品

    CUBE Webex Calling エンタープライズ・イン・ソリューション

    問題の範囲

    パフォーマンス

    問題の種類

    メール通知でCPU使用率が高い。

  3. 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)

  4. DS XMLファイルをローカルゲートウェイにインストールします。

    call-home diagnostic-signature load DS_64224.xml 
Load file DS_64224.xml success

  5. 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

    DSE のダウンロード:

    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回発生すると自動的にアンインストールされます。 以下の手順で署名をインストールしてください。

  1. 診断署名検索ツールの次のドロップダウンオプションを使用してDS 64117をダウンロードします。

    フィールド名

    フィールド値

    プラットフォーム

    シスコ4300、4400 ISRシリーズまたはシスコ CSR 1000Vシリーズ

    製品

    CUBE Webex Calling エンタープライズ・イン・ソリューション

    問題の範囲

    SIP-SIP

    問題の種類

    メール通知によるSIPトランクの登録解除。

  2. DS XMLファイルをローカルゲートウェイにコピーします。

    copy ftp://username:password@<server name or ip>/DS_64117.xml bootflash:

  3. DS XMLファイルをローカルゲートウェイにインストールします。 

    call-home diagnostic-signature load DS_64117.xml 
Load file DS_64117.xml success 
LocalGateway#

  4. show call-home diagnostic-signatureコマンドを使用して、シグニチャが正常にインストールされていることを確認してください。 ステータス列には「登録済み」 の値が必要です。

異常な通話切断の監視

このDSは10分ごとにSNMPポーリングを行い、 SIPエラー403、488、503による異常な通話切断を検出します。  エラー数の増加が前回のポーリングから5以上になると、Syslogと電子メール通知が生成されます。 以下の手順で署名をインストールしてください。

  1. show snmpコマンドを使って、 SNMPが有効かどうかを確認してください。 有効になっていない場合は、snmp-server managerコマンドを設定してください。 

    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

  2. 診断署名検索ツールの次のオプションを使用してDS 65221をダウンロードしてください。

    フィールド名

    フィールド値

    プラットフォーム

    シスコ4300、4400 ISRシリーズまたはシスコ CSR 1000Vシリーズ

    製品

    CUBE Webex Calling エンタープライズ・イン・ソリューション

    問題の範囲

    パフォーマンス

    問題の種類

    メールとSyslog通知によるSIP異常通話切断検出。

  3. DS XMLファイルをローカルゲートウェイにコピーします。 

    copy ftp://username:password@<server name or ip>/DS_65221.xml bootflash:

  4. DS XMLファイルをローカルゲートウェイにインストールします。 

    call-home diagnostic-signature load DS_65221.xml 
Load file DS_65221.xml success

  5. show call-home diagnostic-signatureコマンドを使用して、シグニチャが正常にインストールされていることを確認してください。 ステータス列には「登録済み」 の値が必要です。

問題のトラブルシューティングには診断シグネチャをインストールしてください

問題を迅速に解決するには、診断署名（DS）を使用してください。 Cisco TACエンジニアは、 特定の問題のトラブルシューティング、問題の発生の検出、適切な診断データの収集、 およびケースへのデータの自動転送に必要なデバッグを可能にするいくつかのシグネチャを作成しています。 Cisco TAC 診断シグネチャ（DS）を使用すると、 問題の発生を手動で確認する必要がなくなり、断続的な問題や一時的な問題のトラブルシューティングがはるかに簡単になります。

診断署名検索ツールを使用して、 該当する署名を見つけてインストールし、特定の問題を自己解決することができます。また、 サポート契約の一環としてTACのエンジニアが推奨する署名をインストールすることもできます。

これは、 「% VOICE_IEC -3-GW: CCAPI: 内部エラー (コールスパイクしきい値): IEC=1.1.181.1.29.0" syslogの発生を検出するDSを見つけてインストールし、次の手順を使用して診断データを自動的に収集する方法の例です。

  1. ds_fsurl_prefixCisco TAC収集した診断データをアップロードするファイルサーバーパス （cxd.cisco.com）である追加のDS環境変数を設定します。 ファイルパスのユーザー名はケース番号、 パスワードはファイルアップロードトークンです。 次のコマンドでサポートケースマネージャーから取得できます。 ファイルアップロードトークンは、 必要に応じてサポートケースマネージャーの添付ファイルセクションで生成できます。 

    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"

  2. show snmpコマンドを使用して、 SNMPが有効になっていることを確認してください。 有効になっていない場合は、snmp-server managerコマンドを設定してください。

    show snmp 
%SNMP agent not enabled 
 
 
config t 
snmp-server manager 
end

  3. CPU使用率が高いときにすべてのデバッグと診断シグネチャを無効にする予防策として、必ず高CPU監視DS 64224をインストールしてください。 診断署名検索ツールの次のオプションを使用してDS 64224をダウンロードしてください。

    フィールド名

    フィールド値

    プラットフォーム

    シスコ4300、4400 ISRシリーズまたはシスコ CSR 1000Vシリーズ

    製品

    CUBE Webex Calling エンタープライズ・イン・ソリューション

    問題の範囲

    パフォーマンス

    問題の種類

    メール通知でCPU使用率が高い。

  4. 診断署名検索ツールの次のオプションを使用してDS 65095をダウンロードしてください。

    フィールド名

    フィールド値

    プラットフォーム

    シスコ4300、4400 ISRシリーズまたはシスコ CSR 1000Vシリーズ

    製品

    CUBE Webex Calling エンタープライズ・イン・ソリューション

    問題の範囲

    システムログ

    問題の種類

    シスログ-% VOICE_IEC -3-GW: CCAPI: 内部エラー (コールスパイクしきい値): IEC=1.1.181.1.29.0

  5. 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:

  6. ハイ 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

  7. 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 
           ds_fsurl_prefix: scp://612345678:abcdefghijklmnop@cxd.cisco.com

    ダウンロードした DSE:

    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診断シグネチャ統計情報の出力は 、 診断シグネチャが対象のイベントを検出してアクションを実行するかどうかを確認する最良の方法です。 「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

ダウンロードした DSE:

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/Y

23.053

23.053

診断シグネチャの実行中に送信される通知メールには、問題の種類、デバイスの詳細、ソフトウェアのバージョン、 実行中の構成、 特定の問題のトラブルシューティングに関連するshowコマンドの出力などの重要な情報が含まれています。

診断署名をアンインストールします

診断シグネチャをトラブルシューティングに使用することは、通常、 何らかの問題が発生したことを検出した後にアンインストールするように定義されています。 シグニチャを手動でアンインストールしたい場合は、show call-home diagnostic-signatureコマンドの出力からDS IDを取得して、次のコマンドを実行してください。

call-home diagnostic-signature deinstall <DS ID>

例:

call-home diagnostic-signature deinstall 64224

導入環境によく見られる問題に基づいて、新しい署名が診断署名検索ツールに定期的に追加されます。 TACは現在、 新しいカスタム署名の作成リクエストをサポートしていません。

Cisco IOSコントロールハブでXEゲートウェイを管理し、検証します

Cisco IOSXE Gatewayをより適切に管理するには、Control Hubからゲートウェイを登録して管理することをお勧めします。 これはオプションの設定です。 登録すると、コントロールハブの構成検証オプションを使用して、 ローカルゲートウェイの構成を検証し、構成上の問題を特定できます。 現在、この機能をサポートしているのは登録ベースのトランクだけです。

詳細については、以下を参照してください。

デザイン概要

このセクションでは、証明書ベースの双方向TLSCisco Unified Border Element（mTLS） Webex CallingSIPトランクを使用するためのローカルゲートウェイとして（CUBE）を設定する方法について説明します。 このドキュメントの最初の部分では、 簡単なPSTNゲートウェイの設定方法を説明します。 この場合、 PSTNからのすべての通話はにルーティングされ、Webex CallingWebex Callingからのすべての通話はPSTNにルーティングされます。 次の画像は、 このソリューションとそれに続く高レベルのコールルーティング設定を示しています。

この設計では、次の主要な構成が使用されています。

  • ボイスクラステナント：トランク固有の設定を作成するために使用されます。

  • 音声クラス URI: インバウンドダイヤルピアの選択のためにSIPメッセージを分類するために使用されます。

  • インバウンドダイヤルピア：インバウンドSIPメッセージを処理し、 ダイヤルピアグループを使用してアウトバウンドルートを決定します。

  • ダイヤルピアグループ:転送コールルーティングに使用されるアウトバウンドダイヤルピアを定義します。

  • アウトバウンドダイヤルピア：アウトバウンドSIPメッセージを処理し、 必要なターゲットにルーティングします。

Call routing from/to PSTN to/from Webex Calling configuration solution

Cisco Unified Communications Managerオンプレミスソリューションをに接続するときはWebex Calling、 次の図に示すソリューションを構築するためのベースラインとして、単純なPSTNゲートウェイ構成を使用できます。 この場合、 ユニファイドコミュニケーションマネージャーがすべてのPSTNと通話の一元的なルーティングと処理を行います。Webex Calling

Solution diagram showing Unified Communications Manager provides centralized routing and treatment of all PSTN and Webex Calling calls

このドキュメントでは、次の図に示すホスト名、IPアドレス、インターフェイスが使用されています 。 パブリックアドレスまたはプライベート（NATの後ろ） アドレスのオプションが用意されています。 複数のCUBEインスタンス間で負荷を分散しない限り、SRV DNSレコードはオプションです。

The host names, IP addresses, and interfaces used in certificate based local gateway configurations

このドキュメントの残りの部分にある設定ガイダンスを使用して、 次のようにローカルゲートウェイの設定を完了してください。

接続とセキュリティを設定する

ベースライン構成

Ciscoルーターをローカルゲートウェイとして準備する最初のステップは、プラットフォームを保護し、Webex Calling 接続を確立するためのベースライン構成を構築することです。

  • 証明書ベースのローカルゲートウェイの導入にはすべて、Cisco IOS XE 17.9.1a以降のバージョンが必要です。 Cisco IOSXE 17.12.2以降をお勧めします。 推奨バージョンについては、 シスコソフトウェアリサーチのページを参照してください。 プラットフォームを検索して、 推奨リリースを1つ選択してください。

    • ISR4000シリーズのルーターは、 ユニファイドコミュニケーションとセキュリティテクノロジーの両方のライセンスで構成する必要があります。

    • ボイスカードまたは DSP を搭載した Catalyst Edge 8000 シリーズのルーターには DNA Advantage のライセンスが必要です。 ボイスカードやDSPのないルーターには、最低でもDNA Essentialsのライセンスが必要です。

    • 大容量が必要な場合は、ハイセキュリティ（HSEC） ライセンスと追加のスループット資格が必要な場合もあります。

      詳細については、認証コードを参照してください。

  • ビジネスポリシーに沿ったプラットフォームのベースライン構成を構築してください。 特に、以下を設定して確認してください。

    • NTP

    • ACL

    • ユーザー認証とリモートアクセス

    • DNS

    • IPルーティング

    • IPアドレス

  • Webex Calling向かうネットワークはIPv4アドレスを使用する必要があります。 コントロールハブで設定されたローカルゲートウェイの完全修飾ドメイン名（FQDN）またはサービスレコード（SRV）アドレスは、インターネット上のパブリックIPv4アドレスに変換する必要があります 。

  • Webexに面するローカルゲートウェイインターフェイスのすべてのSIPポートとメディアポートは、 インターネットから直接または静的NAT経由でアクセスできる必要があります。 それに応じてファイアウォールを更新してください。

  • 以下に示す詳細な設定手順に従って、 ローカルゲートウェイに署名付き証明書をインストールしてください。

    • Cisco Webexオーディオおよびビデオプラットフォームへの呼び出しはどのルート認証局がサポートされていますか？で詳しく説明されているパブリックCertificate Authority（CA）。デバイス証明書に署名する必要があります。

    • 証明書のサブジェクトの共通名（CN）、またはサブジェクト代替名 （SAN）の1つは、コントロールハブで設定されているFQDNと同じでなければなりません。 例えば:

      • 組織のコントロールハブに設定されているトランクに、 ローカルゲートウェイのFQDNとしてcube1.lgw.com: 5061がある場合、ルーター証明書のCNまたはSANにはcube1.lgw.comが含まれている必要があります。 

      • 組織のコントロールハブに設定されているトランクに、 トランクからアクセスできるローカルゲートウェイのSRVアドレスとしてlgws.lgw.comがある場合、 ルーター証明書のCNまたはSANにはlgws.lgw.comが含まれている必要があります。 SRVアドレスが解決されるレコード（CNAME、Aレコード、またはIPアドレス）は、SANではオプションです。

      • トランクにFQDNとSRVのいずれを使用する場合でも、 ローカルゲートウェイからのすべての新しいSIPダイアログの連絡先アドレスには、コントロールハブで設定された名前を使用する必要があります。

    • 証明書がクライアントとサーバーで使用できるように署名されていることを確認してください。

  • CiscoルートCAバンドルをローカルゲートウェイにアップロードします。 このバンドルには、 Webexプラットフォームの検証に使用されるCAルート証明書が含まれています。

構成

1

有効でルーティング可能なIPアドレスを任意のレイヤー3インターフェイスに割り当ててください。 次に例を示します。


interface GigabitEthernet0/0/0
 description Interface facing PSTN and/or CUCM
 ip address 192.168.80.14 255.255.255.0
!
interface GigabitEthernet0/0/1
 description Interface facing Webex Calling (Public address)
 ip address 198.51.100.1 255.255.255.240

2

対称暗号化を使用して、ルーターのSTUN認証情報を保護してください。 プライマリ暗号化キーと暗号化タイプを次のように設定します。


key config-key password-encrypt YourPassword
password encryption aes
3

サポートされているCertificate Authority（CA）によって署名された、ドメインの証明書を使用して暗号化トラストポイントを作成します。

  1. 次のexecコマンドを使用してRSAキーペアを作成します。

    crypto key generate rsa general-keys exportable label lgw-key modulus 4096

  2. 次の設定コマンドを使用して証明書のトラストポイントを作成し、 証明書署名要求に使用するフィールド値を指定します。 

    
crypto pki trustpoint LGW_CERT
 enrollment terminal pem
 fqdn none
 subject-name cn=cube1.lgw.com
 subject-alt-name cube1.lgw.com
 revocation-check none
 rsakeypair lgw-key
 hash sha256

    証明書フィールドに関する注意事項：

    • fqdn: これはの必須フィールドではありません。Webex Calling 証明書署名リクエストにこのフィールドを含めない場合は、この設定を「なし」に設定してください。 このコマンドを使用してFQDNを含める必要がある場合でも、 ローカルゲートウェイの操作には影響しません。

    • サブジェクト名：ローカルゲートウェイからの通話を検証するには、WebexはSIP連絡先ヘッダーのFQDNを、 SBC証明書のサブジェクト共通名（CN）属性またはサブジェクト代替名（SAN） フィールドに含まれるFQDNと一致させる必要があります。 件名フィールドには少なくともCN属性が含まれている必要があり、 必要に応じて他の属性を含めることもできます。 詳細については、件名を参照してください。

    • サブジェクト代替名： SBC証明書のサブジェクト代替名（SAN）フィールドには、追加のFQDNのリストを含めることができます。 証明書の Subject CN 属性が一致しない場合、Webex はこのリストをチェックして、ローカルゲートウェイからのメッセージの SIP 連絡先ヘッダーを検証します。

    • ハッシュ：証明書署名リクエスト（CSR） はSHA256を使用して署名することをお勧めします。 Cisco IOSXE 17.11.1はデフォルトでこのアルゴリズムを使用し、以前のリリースではHashコマンドを使用します。

  3. 次の exec コマンドまたは設定コマンドを使用して証明書署名リクエスト（CSR）を生成し、それを使用して、サポートされているCAプロバイダーに署名付き証明書を要求します。

    crypto pki enroll LGW_CERT

4

ホスト証明書を認証するために、 中間署名CAの証明書を提供してください。 次の実行コマンドまたは設定コマンドを入力してください。


crypto pki authenticate LGW_CERT
<paste Intermediate X.509 base 64 based certificate here>

5

次の exec または設定コマンドを使用して、署名付きホスト証明書をインポートします。


crypto pki import LGW_CERT certificate
<paste CUBE host X.509 base 64 certificate here>

6

次の設定コマンドを使用して、TLS1.2の排他性を有効にし、 音声アプリケーションに使用するデフォルトのトラストポイントを指定します。


 sip-ua
  crypto signaling default trustpoint LGW_CERT
  transport tcp tls v1.2

7

が使用するIdenTrust商用ルートCA 1証明書を含むCiscoルートCAバンドルをインストールしてください。Webex Calling crypto pki trustpool import clean url urlコマンドを使用して、 指定されたURLからルートCAバンドルをダウンロードし、現在のCAトラストプールをクリアしてから、新しい証明書バンドルをインストールしてください。

HTTPSを使用してインターネットにアクセスするためにプロキシを使用する必要がある場合は、CAバンドルをインポートする前に次の設定を追加してください。

ip http クライアントプロキシサーバー yourproxy.com プロキシポート 80

ip http client source-interface GigabitEthernet0/0/1 
crypto pki trustpool import clean url https://www.cisco.com/security/pki/trs/ios_core.p7b
Webex Calling証明書ベースのトランクを設定してください
1

コントロールハブの既存の場所に、CUBE証明書ベースのPSTNトランクを作成します。 詳細については、「トランク、ルートグループ、 ダイヤルプランの設定」を参照してください。Webex Calling

トランクが作成されたら提供されるトランク情報を書き留めておいてください。 次の図で強調表示されているこれらの詳細は、 このガイドの設定手順で使用されます。

CUBE certificate-based PSTN trunk is created
2

次のコマンドを入力して、Webex Calling CUBEをローカルゲートウェイとして設定します。


voice service voip
 ip address trusted list
  ipv4 x.x.x.x y.y.y.y
 mode border-element
 allow-connections sip to sip
 no supplementary-service sip refer
 stun
  stun flowdata agent-id 1 boot-count 4
  stun flowdata shared-secret 0 Password123$
 sip 
  asymmetric payload full
  early-offer forced
  sip-profiles inbound

設定用のフィールドの説明は次のとおりです。


ip address trusted list
 ipv4 x.x.x.x y.y.y.y

  • 通話詐欺を防ぐため、信頼できるアドレスリストでは、 ローカルゲートウェイが正当なVoIP通話を期待するホストとネットワークエンティティのリストを定義します。

  • デフォルトでは、 ローカルゲートウェイは信頼リストにないIPアドレスからのすべての着信VoIPメッセージをブロックします。 デフォルトでは、「セッションターゲットIP」 またはサーバーグループのIPアドレスを持つ静的に設定されたダイヤルピアが信頼されます。 これらのIPアドレスを信頼リストに追加する必要はありません。

  • ローカルゲートウェイを設定するときは、 Webex Calling地域のデータセンターのIPサブネットをリストに追加します。詳細については、「ポートリファレンス情報」を参照してください。Webex Calling また、 ユニファイドコミュニケーションマネージャーサーバー（使用している場合） とPSTNトランクゲートウェイのアドレス範囲を追加してください。

  • IPアドレスの信頼リストを使用して通話詐欺を防止する方法の詳細については、「信頼できるIPアドレス」を参照してください。

モードボーダーエレメント

プラットフォームで Cisco Unified Border Element (CUBE) 機能を有効にします。

接続を許可する-スキップ・ツー・シップ

CUBEの基本的なSIPバック・ツー・バック・ユーザー・エージェント機能を有効にします。 詳しくは、「接続を許可する」を参照してください。

デフォルトでは、T.38のファックス転送は有効になっています。 詳細については、 ファックスプロトコル t38 （音声サービス）を参照してください。

気絶させます

STUN（ NATを介したUDPのセッショントラバーサル）をグローバルに有効にします。

これらのグローバルスタンコマンドは、 ローカルゲートウェイをNATの背後に展開する場合にのみ必要です。

  • ローカルゲートウェイのSTUNバインディング機能を使用すると、 ローカルで生成されたSTUNリクエストをネゴシエートされたメディアパスを介して送信できます。 これはファイアウォールのピンホールを開くのに役立ちます。

詳細については、「スタンフローデータエージェントID」と「スタンフローデータ共有シークレット」を参照してください。

非対称ペイロードフル

DTMFペイロードとダイナミックコーデックペイロードの両方のSIP非対称ペイロードサポートを設定します。 このコマンドの詳細については、 非対称ペイロードを参照してください。

アーリーオファーが強制されます

ローカルゲートウェイに、 隣接するピアからの確認を待つのではなく、最初の INVITE メッセージでSDP情報を送信するように強制します。 このコマンドの詳細については、early-offer を参照してください。

SIPプロファイルインバウンド

CUBEがSIPプロファイルを使用して、 受信時にメッセージを変更できるようにします。 プロファイルはダイヤルピアまたはテナントを介して適用されます。

3

すべてのトランクに G.711 コーデックのみを許可する音声クラスコーデック 100 を設定します。 このシンプルなアプローチは、ほとんどの導入に適しています。 必要に応じて、 発信側システムと終端側システムの両方でサポートされている追加のコーデックタイプをリストに追加できます。

DSPモジュールを使用したトランスコーディングを含む、 より複雑なソリューションもサポートされていますが、このガイドには含まれていません。 


voice class codec 100
 codec preference 1 g711ulaw
 codec preference 2 g711alaw

設定用のフィールドの説明は次のとおりです。

音声クラスコーデック 100

SIPトランクコールに優先コーデックのみを許可するために使用されます。 詳細については、 音声クラスコーデックを参照してください。

4

トランクでICEを有効にするには、ボイスクラスのstun-usage 100を設定してください。Webex Calling（このステップは政府向け Webex には適用されません）


voice class stun-usage 100 
 stun usage firewall-traversal flowdata
 stun usage ice lite

設定用のフィールドの説明は次のとおりです。

スタン使用法、アイスライト

可能な限りメディアを最適化できるように、 Webex Calling向かい合っているすべてのダイヤルピアでICE-Liteを有効にしていました。 詳細については、ボイスクラスのスタン使用法とスタン使用量「ice lite」を参照してください。

stun usage firewall-traversal flowdataコマンドは、ローカルゲートウェイをNATの背後にデプロイする場合にのみ必要です。

メディアの最適化は可能な限り交渉されます。 通話に録音などのクラウドメディアサービスが必要な場合、 メディアは最適化できません。

5

Webex トラフィックのメディア暗号化ポリシーを設定します。（このステップは政府向け Webex には適用されません）


voice class srtp-crypto 100
 crypto 1 AES_CM_128_HMAC_SHA1_80

設定用のフィールドの説明は次のとおりです。

ボイスクラス srtp-crypto 100

SHA1_80 オファーメッセージとアンサーメッセージでSDPでCUBEが提供している唯一のSRTP暗号スイートとして指定します。 Webex Callingサポートのみです SHA1_80。 詳細については、音声クラス srtp-crypto を参照してください。

6

FIPS 準拠の GCM 暗号を設定します（このステップは政府向け Webex にのみ適用されます）。 


voice class srtp-crypto 100
crypto 1 AEAD_AES_256_GCM

設定用のフィールドの説明は次のとおりです。

ボイスクラス srtp-crypto 100

CUBEが提供する暗号スイートとしてGCMを指定します。 政府向け Webex のローカルゲートウェイには GCM 暗号を設定することが必須です。

7

宛先のFQDNまたはSRVに基づいてローカルゲートウェイトランクへのコールを一意に識別するパターンを設定してください：


voice class uri 100 sip
 pattern cube1.lgw.com

設定用のフィールドの説明は次のとおりです。

ボイスクラス URI 100 チップ

着信したSIP招待を着信トランクのダイヤルピアと一致させるパターンを定義します。 このパターンを入力するときは、 トランクのコントロールハブで設定されているトランクのFQDNまたはSRVを使用してください。

8

SIPメッセージ操作プロファイルを設定します。 ゲートウェイにパブリックIPアドレスが設定されている場合は、次のようにプロファイルを設定するか、 NATを使用している場合は次のステップに進んでください。 この例では、cube1.lgw.comはローカルゲートウェイに設定されたFQDNです。


voice class sip-profiles 100
 rule 10 request ANY sip-header Contact modify "@.*:" "@cube1.lgw.com:" 
 rule 20 response ANY sip-header Contact modify "@.*:" "@cube1.lgw.com:"

設定用のフィールドの説明は次のとおりです。

ルール10と20

Webexがローカルゲートウェイからのメッセージを認証できるようにするには、 SIPリクエストとレスポンスメッセージの「Contact」ヘッダーに、コントロールハブのトランクにプロビジョニングされた値が含まれている必要があります。 これは、単一ホストのFQDN、 またはデバイスのクラスターに使用されるSRV名のどちらかになります。

9

ゲートウェイが静的NATの背後にあるプライベートIPアドレスで構成されている場合は、 インバウンドとアウトバウンドのSIPプロファイルを次のように設定します。 この例では、 cube1.lgw.comはローカルゲートウェイに設定されたFQDN、「10.80.13.12」 はインターフェイスに面したIPアドレス、「192.65.79.20」はNATのパブリックIPアドレスです。Webex Calling

へのアウトバウンドメッセージ用のSIPプロファイル Webex Calling 

voice class sip-profiles 100
 rule 10 request ANY sip-header Contact modify "@.*:" "@cube1.lgw.com:"
 rule 20 response ANY sip-header Contact modify "@.*:" "@cube1.lgw.com:"
 rule 30 response ANY sdp-header Audio-Attribute modify "(a=candidate:1 1.*) 10.80.13.12" "\1 192.65.79.20"
 rule 31 response ANY sdp-header Audio-Attribute modify "(a=candidate:1 2.*) 10.80.13.12" "\1 192.65.79.20"
 rule 40 response ANY sdp-header Audio-Connection-Info modify "IN IP4 10.80.13.12" "IN IP4 192.65.79.20"
 rule 41 request ANY sdp-header Audio-Connection-Info modify "IN IP4 10.80.13.12" "IN IP4 192.65.79.20"
 rule 50 request ANY sdp-header Connection-Info modify "IN IP4 10.80.13.12" "IN IP4 192.65.79.20"
 rule 51 response ANY sdp-header Connection-Info modify "IN IP4 10.80.13.12" "IN IP4 192.65.79.20"
 rule 60 response ANY sdp-header Session-Owner modify "IN IP4 10.80.13.12" "IN IP4 192.65.79.20"
 rule 61 request ANY sdp-header Session-Owner modify "IN IP4 10.80.13.12" "IN IP4 192.65.79.20"
 rule 70 request ANY sdp-header Audio-Attribute modify "(a=rtcp:.*) 10.80.13.12" "\1 192.65.79.20"
 rule 71 response ANY sdp-header Audio-Attribute modify "(a=rtcp:.*) 10.80.13.12" "\1 192.65.79.20"
 rule 80 request ANY sdp-header Audio-Attribute modify "(a=candidate:1 1.*) 10.80.13.12" "\1 192.65.79.20"
 rule 81 request ANY sdp-header Audio-Attribute modify "(a=candidate:1 2.*) 10.80.13.12" "\1 192.65.79.20"

設定用のフィールドの説明は次のとおりです。

ルール10と20

Webexがローカルゲートウェイからのメッセージを認証できるようにするには、SIPリクエストとレスポンスメッセージの「Contact」ヘッダーに、 コントロールハブのトランクにプロビジョニングされた値が含まれている必要があります。 これは、単一ホストのFQDN、 またはデバイスのクラスターに使用されるSRV名のどちらかになります。

ルール30から81まで

プライベートアドレス参照をサイトの外部パブリックアドレスに変換して、 Webexが後続のメッセージを正しく解釈してルーティングできるようにします。

からの受信メッセージのSIPプロファイル Webex Calling 

voice class sip-profiles 110
 rule 10 response ANY sdp-header Video-Connection-Info modify "192.65.79.20" "10.80.13.12"
 rule 20 response ANY sip-header Contact modify "@.*:" "@cube1.lgw.com:"
 rule 30 response ANY sdp-header Connection-Info modify "192.65.79.20" "10.80.13.12"
 rule 40 response ANY sdp-header Audio-Connection-Info modify "192.65.79.20" "10.80.13.12"
 rule 50 response ANY sdp-header Session-Owner modify "192.65.79.20" "10.80.13.12"
 rule 60 response ANY sdp-header Audio-Attribute modify "(a=candidate:1 1.*) 192.65.79.20" "\1 10.80.13.12"
 rule 70 response ANY sdp-header Audio-Attribute modify "(a=candidate:1 2.*) 192.65.79.20" "\1 10.80.13.12"
 rule 80 response ANY sdp-header Audio-Attribute modify "(a=rtcp:.*) 192.65.79.20" "\1 10.80.13.12"

設定用のフィールドの説明は次のとおりです。

ルール 10から80まで

パブリックアドレス参照を設定済みのプライベートアドレスに変換して、 CUBEがWebexからのメッセージを処理できるようにします。

詳しくは、 音声クラスのSIPプロファイルを参照してください。

米国またはカナダのPSTNプロバイダーは、記事の「迷惑電話または詐欺電話表示」 に記載されている追加設定で、 スパムや詐欺電話の発信者ID認証を提供できます。 Webex Calling

10

ヘッダー変更プロファイルを使用してSIPオプションのキープアライブを設定します。


voice class sip-profiles 115
 rule 10 request OPTIONS sip-header Contact modify "<sip:.*:" "<sip:cube1.lgw.com:" 
 rule 30 request ANY sip-header Via modify "(SIP.*) 10.80.13.12" "\1 192.65.79.20"
 rule 40 response ANY sdp-header Connection-Info modify "10.80.13.12" "192.65.79.20"  
 rule 50 response ANY sdp-header Audio-Connection-Info modify "10.80.13.12" "192.65.79.20"
!
voice class sip-options-keepalive 100
 description Keepalive for Webex Calling
 up-interval 5
 transport tcp tls
 sip-profiles 115

設定用のフィールドの説明は次のとおりです。

ボイスクラス SIP-オプション-キープアライブ 100

キープアライブプロファイルを設定し、 音声クラス設定モードに入ります。 エンドポイントへのハートビート接続が「UP」または「Down」状態のときに、SIP Out of Dialog Options Pingがダイヤルターゲットに送信される時間（秒単位）を設定できます。

このキープアライブプロファイルは、Webexに設定されたダイヤルピアからトリガーされます。

連絡先ヘッダーにSBCの完全修飾ドメイン名が含まれていることを確認するために、SIPプロファイル115が使用されます。 ルール30、40、50は、 SBCがスタティックNATの背後で設定されている場合にのみ必要です。

この例では、 cube1.lgw.comはローカルゲートウェイ用に選択されたFQDNです。スタティックNATを使用する場合、「10.80.13.12」 は宛先となるSBCインターフェイスのIPアドレスで、「192.65.79.20」はNATのパブリックIPアドレスです。Webex Calling

11

Webex Callingトランクの設定:

  1. ボイスクラステナント100を作成して、 Webex Callingトランクに特に必要な設定を定義してグループ化します。 このテナントに関連付けられているダイヤルピアは、 後で次の設定を継承します。

    次の例では、 このガイドの目的のためにステップ1で示した値を使用しています（太字で表示）。 これらを、 構成内のトランクの値に置き換えてください。

    
voice class tenant 100
 no remote-party-id
 sip-server dns:us25.sipconnect.bcld.webex.com
 srtp-crypto 100
 localhost dns:cube1.lgw.com
 session transport tcp tls
 no session refresh
 error-passthru
 rel1xx disable
 asserted-id pai
 bind control source-interface GigabitEthernet0/0/1
 bind media source-interface GigabitEthernet0/0/1
 no pass-thru content custom-sdp
 sip-profiles 100 
 sip-profiles 110 inbound
 privacy-policy passthru
!

    設定用のフィールドの説明は次のとおりです。

    ボイスクラステナント 100

    テナントを使用してトランクを設定することをお勧めします。 トランクには独自のTLS証明書とCNまたはSAN検証リストがあります。 ここで、 テナントに関連付けられているTLSプロファイルには、 新しい接続の受け入れまたは作成に使用されるトラストポイントと、 着信接続を検証するためのCNまたはSANリストが含まれています。 詳しくは、 ボイスクラステナントを参照してください。

    リモートパーティIDはありません

    Webex CallingPAIをサポートしているので、SIPリモートパーティID（RPID） ヘッダーを無効にしてください。PAIは、asserted-id paiコマンドを使用して有効になります。 詳細については、リモートパーティーIDを参照してください。

    シップサーバーのDNS: us25.sipconnect.bcld.webex.com

    トランクのターゲットSIPサーバーを設定します。 トランクを作成したときにコントロールハブで提供されたEdgeプロキシSRVアドレスを使用してください

    stp-crypto 100さん

    SRTPコールレッグ（接続）（ステップ5で指定） の優先暗号スイートを設定します。 詳細については、音声クラス srtp-crypto を参照してください。

    ローカルホスト DNS: キューブ1.lgw.com

    送信メッセージの From、Call-ID、 およびリモートパーティIDヘッダーの物理IPアドレスを、 指定されたFQDNに置き換えるようにCUBEを設定します。 ここでは、コントロールハブでトランクに設定されているトランクのFQDNまたはSRVを使用してください。

    セッショントランスポート TCP TLS

    関連するダイヤルピアの転送をTLSに設定します。 詳細については、 セッショントランスポートを参照してください。

    セッション更新なし

    CUBE と Webex 間の通話の SIP セッション更新を無効にします。 詳しくは、 セッションの更新を参照してください。

    エラーパススルー

    SIPエラー応答パススルー機能を指定します。 詳細については、 エラーパススルーを参照してください。

    rel1xx 無効にします

    トランクでの信頼できる暫定応答の使用を無効にします。Webex Calling 詳細については、rel1xxを参照してください。

    アサーテッドIDペイ

    （オプション） P-Asserted-Identityヘッダー処理をオンにして、 これがトランクにどのように使用されるかを制御します。Webex Calling

    Webex Callingローカルゲートウェイへのアウトバウンドコールへの招待に、 P-Asserted-Identity（PAI）ヘッダーを含みます。

    このコマンドを設定すると、 PAIヘッダーの発信者情報を使用して、 送信されるFromヘッダーとPAI/Remote-Party-IDヘッダーが入力されます。

    このコマンドが設定されていない場合は、Fromヘッダーの発信者情報を使用して、 送信FromヘッダーとPAI/Remote-Party-IDヘッダーが入力されます。

    詳細については、asserted-idを参照してください。

    バインドコントロールソースインターフェイスギガビットイーサネット 0/0/1

    送信先のメッセージの送信元インターフェイスと関連するIPアドレスを設定します。 Webex Calling 詳しくは、bindを参照してください。

    バインドメディアソースインターフェイスギガビットイーサネット 0/0/1

    送信先のメディアのソースインターフェイスと関連するIPアドレスを設定します。Webex Calling 詳しくは、bindを参照してください。

    ボイスクラスのSIPプロファイル 100

    送信メッセージに使用するヘッダー変更プロファイル （パブリックIPまたはNATアドレス）を適用します。 詳しくは、 ボイスクラスのSIPプロファイルを参照してください。

    音声クラス SIP プロファイル 110 インバウンド

    NATのみの背後にあるLGW展開の場合： 受信メッセージに使用するヘッダー変更プロファイルを適用します。 詳しくは、 ボイスクラスのSIPプロファイルを参照してください。

    プライバシーポリシーパススルー

    受信したメッセージのプライバシーヘッダーを次のコールレッグに透過的に渡すようにCUBEを設定します。 詳細については、プライバシーポリシーを参照してください。

  2. Webex Callingトランクのダイヤルピアを設定してください。

    
dial-peer voice 100 voip
 description Inbound/Outbound Webex Calling
 destination-pattern BAD.BAD
 session protocol sipv2
 session target sip-server
 incoming uri request 100
 voice-class codec 100
 voice-class stun-usage 100
 voice-class sip tenant 100
 voice-class sip options-keepalive profile 100
 dtmf-relay rtp-nte 
 srtp
 no vad

    設定用のフィールドの説明は次のとおりです。

    
dial-peer voice 100 voip
 description Inbound/Outbound Webex Calling

    タグ100のVoIPダイヤルピアを定義し、 管理とトラブルシューティングを容易にするためにわかりやすい説明を付けます。 詳細については、ダイヤルピアボイスを参照してください。

    デスティネーションパターン BAD.BAD

    着信ダイヤルピアグループを使用して発信通話をルーティングする場合は、 ダミーの宛先パターンが必要です。 この場合、任意の有効な宛先パターンを使用できます。 詳しくは、デスティネーションパターン (インターフェイス) を参照してください。

    セッションプロトコル sipv2

    このダイヤルピアが SIP コールレッグを処理することを指定します。 詳細については、セッションプロトコル (ダイヤルピア) を参照してください。

    セッションターゲット SIPサーバー

    テナント100で定義されているSIPサーバーが継承され、 このダイヤルピアからの通話の宛先に使用されることを示します。

    受信したURIリクエスト 100%

    INVITE REQUEST ヘッダー URI を使用して、 着信コールをこのダイヤルピアに一致させるために使用する音声クラスを指定します。 詳細については、「 受信URI」を参照してください。

    音声クラスコーデック 100

    Webex Calling宛先のコールと発信元のコーデックフィルターリストを示します。 詳細については、 音声クラスコーデックを参照してください。

    ボイスクラスのスタン使い方 100

    ローカルゲートウェイからローカルで生成されたSTUNリクエストを、 ネゴシエートされたメディアパスを介して送信できます。 STUNパケットは、メディアトラフィックのファイアウォールピンホールを開き、 メディア最適化の有効なパスを検出するのに役立ちます。

    ボイスクラスのシップテナント 100

    ダイヤルピアは、 グローバルおよびテナント100で設定されたすべてのパラメータを継承します。 パラメータはダイヤルピアレベルで上書きされることがあります。 詳細については、ボイスクラスのSIPテナントを参照してください。

    ボイスクラスのSIPオプション-キープアライブプロファイル 100

    このコマンドは、 特定のプロファイル（100） を使用してSIPサーバーまたはエンドポイントのグループの可用性を監視するために使用されます。

    STP

    コールレッグのSRTPを有効にします。

SIP PSTNトランクでローカルゲートウェイを設定してください

Webex Calling上記のようにトランクを構築したら、次の構成を使用して、 SIPベースのPSTNプロバイダーへの暗号化されていないトランクを作成します。

サービスプロバイダーが安全なPSTNトランクを提供している場合は、 トランクについて上記で説明したのと同様の設定に従うことができます。Webex Calling CUBEは安全な通話ルーティングをサポートしています。

TDM/ISDN PSTNトランクを使用している場合は、次のセクション「TDM PSTNトランクを使ったローカルゲートウェイの設定」に進んでください。

Cisco TDM-SIPゲートウェイのPSTNコールレッグ用のTDMインターフェイスを設定するには、ISDN PRIの設定を参照してください。

1

PSTNトランクからの着信コールを識別するには、次の音声クラスURIを設定してください。


voice class uri 200 sip
  host ipv4:192.168.80.13

設定用のフィールドの説明は次のとおりです。

ボイスクラス URI 200 チップ

着信したSIP招待を着信トランクのダイヤルピアと一致させるパターンを定義します。 このパターンを入力するときは、IP PSTNゲートウェイのIPアドレスを使用してください。 詳しくは、ボイスクラスのURIを参照してください。

2

次のIP PSTNダイヤルピアを設定します。


dial-peer voice 200 voip
 description Inbound/Outbound IP PSTN trunk
 destination-pattern BAD.BAD
 session protocol sipv2
 session target ipv4:192.168.80.13
 incoming uri via 200
 voice-class sip asserted-id pai
 voice-class sip bind control source-interface GigabitEthernet0/0/0 
 voice-class sip bind media source-interface  GigabitEthernet0/0/0 
 voice-class codec 100
 dtmf-relay rtp-nte 
 no vad

設定用のフィールドの説明は次のとおりです。


dial-peer voice 200 voip
 description Inbound/Outbound IP PSTN trunk

タグ200のVoIPダイヤルピアを定義し、 管理とトラブルシューティングを容易にするためにわかりやすい説明を付けます。 詳細については、 ダイヤルピアボイスを参照してください。

デスティネーションパターン BAD.BAD

着信ダイヤルピアグループを使用して発信通話をルーティングする場合は、 ダミーの宛先パターンが必要です。 この場合、任意の有効な宛先パターンを使用できます。 詳しくは、デスティネーションパターン (インターフェイス) を参照してください。

セッションプロトコル sipv2

このダイヤルピアが SIP コールレッグを処理することを指定します。 詳細については、セッションプロトコル（ ダイヤルピア）を参照してください。

セッションターゲット ipv4: 192.168.80.13

PSTNプロバイダーに送信される通話の宛先アドレスを指定します。 これは、 IPアドレスでもDNSホスト名でもかまいません。 詳細については、セッションターゲット ( VoIPダイヤルピア) を参照してください。

200経由でURIが届きます

INVITE VIAヘッダーURIを使用して、 着信コールをこのダイヤルピアに一致させるために使用される音声クラスを指定します。 詳しくは、受信URLを参照してください。

ボイスクラスシップアサーテッドIDペア

（オプション） P-Asserted-Identityヘッダー処理をオンにして、これがPSTNトランクにどのように使用されるかを制御します。 このコマンドを使用すると、 着信ダイヤルピアから提供された発信側のIDが、 発信FromヘッダーとP-Asserted-Identityヘッダーに使用されます。 このコマンドを使用しない場合、 着信ダイヤルピアから提供された発信側のIDが、 発信FromヘッダーとRemote-Party-IDヘッダーに使用されます。 詳細については、ボイスクラス SIP アサーテッドIDを参照してください。

バインドコントロールソースインターフェイスギガビットイーサネット 0/0/0

PSTNに送信されるメッセージの送信元インターフェイスと関連するIPアドレスを設定します。 詳しくは、bindを参照してください。

バインドメディアソースインターフェイスギガビットイーサネット 0/0/0

PSTNに送信されるメディアのソースインターフェイスと関連するIPアドレスを設定します。 詳しくは、bindを参照してください。

音声クラスコーデック 100

共通コーデックフィルタリスト 100 を使用するようにダイヤルピアを設定します。 詳細については、 音声クラスのコーデックを参照してください。

DTMF-リレー rtp-nte

RTP-NTE（RFC2833）を、コールレッグで期待されるDTMF機能として定義しています。 詳細については、「DTMFリレー（ ボイスオーバーIP）」を参照してください。

いいえ、悪いです

音声アクティビティ検出を無効にします。 詳細については、vad (ダイヤルピア) を参照してください。

3

Webex CallingとPSTN間の通話のみをルーティングするようにローカルゲートウェイを設定する場合は、次の通話ルーティング設定を追加してください。 ユニファイドコミュニケーションマネージャープラットフォームでローカルゲートウェイを設定する場合は、 次のセクションに進んでください。

  1. ダイヤルピアグループを作成して、Webex Calling通話をPSTNにルーティングします。 DPG 100をアウトバウンドダイヤルピア100に定義してください。Webex Calling DPG 100は、PSTNからの着信ダイヤルピアに適用されます。 同様に、PSTNへのアウトバウンドダイヤルピア200を備えたDPG 200を定義してください。 DPG 200は、 Webexからの着信ダイヤルピアに適用されます。

    
voice class dpg 100 
 description Route calls to Webex Calling 
 dial-peer 100 
voice class dpg 200 
 description Route calls to PSTN 
 dial-peer 200

    設定用のフィールドの説明は次のとおりです。

    ダイヤルピア 100

    アウトバウンドダイヤルピアをダイヤルピアグループに関連付けます 。 詳細については、 ボイスクラスのDPGを参照してください。

  2. ダイヤルピアグループを適用して、Webex から PSTN に、および PSTN から Webex に通話をルーティングします。 

    
dial-peer voice 100
 destination dpg 200
dial-peer voice 200
 destination dpg 100

    設定用のフィールドの説明は次のとおりです。

    デスティネーション・ドッグ 200

    どのダイヤルピアグループ 、 つまりこの着信ダイヤルピアに送られるコールの発信処理にダイヤルピアを使用するかを指定します。

    これで、ローカルゲートウェイの設定は終了です。 CUBEの機能を初めて設定する場合は、 設定を保存してプラットフォームをリロードしてください。

TDM PSTNトランクでローカルゲートウェイを設定してください

に向けてトランクを構築したらWebex Calling、次の設定を使用して、Webexコールレッグでメディアを最適化できるように、 ループバックコールルーティングを備えたPSTNサービス用のTDMトランクを作成します。

IPメディア最適化が必要ない場合は、SIP PSTNトランクの設定手順に従ってください。 PSTN VoIPダイヤルピアの代わりに音声ポートとPOTSダイヤルピア（手順2と3を参照）を使用してください。

1

ループバックダイヤルピア設定では、ダイヤルピアグループとコールルーティングタグを使用して、 コールルーティングループを作らずにコールがWebexとPSTNの間で正しく渡されるようにします。 コールルーティングタグの追加と削除に使用される次の変換ルールを設定します。


voice translation-rule 100 
 rule 1 /^\+/ /A2A/ 

voice translation-profile 100 
 translate called 100 

voice translation-rule 200 
 rule 1 /^/ /A1A/ 

voice translation-profile 200 
 translate called 200 

voice translation-rule 11 
 rule 1 /^A1A/ // 

voice translation-profile 11 
 translate called 11 

voice translation-rule 12 
 rule 1 /^A2A44/ /0/
 rule 2/^A2A/ /00/

voice translation-profile 12 
 translate called 12

設定用のフィールドの説明は次のとおりです。

音声翻訳ルール

ルールで定義された正規表現を使用して、通話ルーティングタグを追加または削除します。 トラブルシューティングをわかりやすくするために、10進数を超える数字（「A」）が使用されます。

この設定では、 translation-profile 100によって追加されたタグを使用して、Webex Callingループバックダイヤルピアを介して発信元からPSTNにコールを誘導します。 同様に、トランスレーションプロファイル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に取り付けられたPrimary Rate ISDNインターフェイスの基本構成には、 次のものが含まれる場合があります。


card type e1 0 2 
isdn switch-type primary-net5 
controller E1 0/2/0 
 pri-group timeslots 1-31
3

次の TDM PSTN ダイヤルピアを設定します。


dial-peer voice 200 pots 
 description Inbound/Outbound PRI PSTN trunk 
 destination-pattern BAD.BAD 
 translation-profile incoming 200 
 direct-inward-dial 
 port 0/2/0:15

設定用のフィールドの説明は次のとおりです。 


dial-peer voice 200 pots
 description Inbound/Outbound PRI PSTN trunk

タグ200のVoIPダイヤルピアを定義し、 管理とトラブルシューティングを容易にするためにわかりやすい説明を付けます。 詳細については、ダイヤルピアボイスを参照してください。

デスティネーションパターン BAD.BAD

着信ダイヤルピアグループを使用して発信通話をルーティングする場合は、 ダミーの宛先パターンが必要です。 この場合、任意の有効な宛先パターンを使用できます。 詳しくは、デスティネーションパターン (インターフェイス) を参照してください。

翻訳プロフィールが200件届きます

着信着信番号にコールルーティングタグを追加するトランスレーションプロファイルを割り当てます。

ダイレクトインワードダイヤル

セカンダリダイヤルトーンを提供せずに通話をルーティングします。 詳しくは、「ダイレクト・インワードダイヤル」を参照してください。

ポート 0/2/ 0:15

このダイヤルピアに関連付けられている物理的な音声ポート。

4

TDM-IPコールフローを使用してローカルゲートウェイのIPパスのメディア最適化を有効にするには、とPSTNトランク間に内部ループバックダイヤルピアを導入して、 コールルーティングを変更できます。 Webex Calling 次のループバックダイヤルピアを設定します。 この場合、 すべての着信コールは最初にダイヤルピア10にルーティングされ、 そこから適用されたルーティングタグに基づいてダイヤルピア11または12にルーティングされます。 ルーティングタグを削除すると、 コールはダイヤルピアグループを使用して発信トランクにルーティングされます。


dial-peer voice 10 voip
 description Outbound loop-around leg
 destination-pattern BAD.BAD
 session protocol sipv2
 session target ipv4:192.168.80.14
 voice-class sip bind control source-interface GigabitEthernet0/0/0
 voice-class sip bind media source-interface GigabitEthernet0/0/0
 dtmf-relay rtp-nte
 codec g711alaw
 no vad 

dial-peer voice 11 voip
 description Inbound loop-around leg towards Webex
 translation-profile incoming 11
 session protocol sipv2
 incoming called-number A1AT
 voice-class sip bind control source-interface GigabitEthernet0/0/0
 voice-class sip bind media source-interface GigabitEthernet0/0/0
 dtmf-relay rtp-nte
 codec g711alaw
 no vad 

dial-peer voice 12 voip
 description Inbound loop-around leg towards PSTN
 translation-profile incoming 12
 session protocol sipv2
 incoming called-number A2AT
 voice-class sip bind control source-interface GigabitEthernet0/0/0
 voice-class sip bind media source-interface GigabitEthernet0/0/0
 dtmf-relay rtp-nte
 codec g711alaw 
 no vad

設定用のフィールドの説明は次のとおりです。 


dial-peer voice 10 voip
 description Outbound loop-around leg

VoIPダイヤルピアを定義し、管理とトラブルシューティングを容易にするためにわかりやすい説明をしています。 詳細については、ダイヤルピアボイスを参照してください。

翻訳プロフィールが11件届きます

先に定義したトランスレーションプロファイルを適用して、 発信トランクに渡す前にコールルーティングタグを削除します。

デスティネーションパターン BAD.BAD

着信ダイヤルピアグループを使用して発信通話をルーティングする場合は、 ダミーの宛先パターンが必要です。 詳しくは、デスティネーションパターン (インターフェイス) を参照してください。

セッションプロトコル sipv2

このダイヤルピアが SIP コールレッグを処理することを指定します。 詳細については、セッションプロトコル（ ダイヤルピア）を参照してください。

セッションターゲット ipv4: 192.168.80.14

ローカルルーターのインターフェイスアドレスをループバックするコールターゲットとして指定します 。 詳細については、セッションターゲット（ VoIPダイヤルピア）を参照してください。

バインドコントロールソースインターフェイスギガビットイーサネット 0/0/0

ループバックを介して送信されるメッセージの送信元インターフェイスと関連するIPアドレスを設定します。 詳しくは、bindを参照してください。

バインドメディアソースインターフェイスギガビットイーサネット 0/0/0

ループバックを介して送信されるメディアのソースインターフェイスと関連するIPアドレスを設定します。 詳しくは、bindを参照してください。

DTMF-リレー rtp-nte

RTP-NTE（RFC2833）を、コールレッグで期待されるDTMF機能として定義しています。 詳細については、「DTMFリレー（ ボイスオーバーIP）」を参照してください。

コーデック g711alaw

すべてのPSTNコールにG.711を使用するように強制します。 ISDNサービスで使用されているコンパンド方法に合わせて、a-lawまたはu-lawを選択してください。

いいえ、悪いです

音声アクティビティ検出を無効にします。 詳細については、vad (ダイヤルピア) を参照してください。

5

次のコールルーティング設定を追加してください：

  1. ダイヤルピアグループを作成して、PSTNとWebexトランク間の通話をループバック経由でルーティングします。

    
voice class dpg 100
 description Route calls to Webex Calling
 dial-peer 100
voice class dpg 200
 description Route calls to PSTN
 dial-peer 200
voice class dpg 10
 description Route calls to Loopback
 dial-peer 10

    設定用のフィールドの説明は次のとおりです。

    ダイヤルピア 100

    アウトバウンドダイヤルピアをダイヤルピアグループに関連付けます 。 詳細については、 ボイスクラスのDPGを参照してください。

  2. コールをルーティングするためにダイヤルピアグループを適用します。

    
dial-peer voice 100
 destination dpg 10
dial-peer voice 200
 destination dpg 10
dial-peer voice 11
 destination dpg 100
dial-peer voice 12
 destination dpg 200

    設定用のフィールドの説明は次のとおりです。

    デスティネーション・ドッグ 200

    どのダイヤルピアグループ 、 つまりこの着信ダイヤルピアに送られるコールの発信処理にダイヤルピアを使用するかを指定します。

これで、ローカルゲートウェイの設定は終了です。 CUBEの機能を初めて設定する場合は、 設定を保存してプラットフォームをリロードしてください。
Unified CMローカルゲートウェイを既存の環境に設定してください

Webex Calling前のセクションのPSTN-設定は、Cisco Unified Communications Manager（UCM ）クラスタへのトランクを追加するように変更できます。 この場合、Unified CMすべての通話は経由でルーティングされます。 ポート5060のUCMからのコールはPSTNにルーティングされ、ポート5065からのコールはにルーティングされます。Webex Calling この通話シナリオを含めるために、 次の段階的な構成を追加できます。

1

次の音声クラスURIを設定してください：

  1. SIP Unified CM VIAポートを使用してWebexコールに分類します。

    
voice class uri 300 sip
 pattern :5065

  2. Unified CMポート経由のSIPを使用してPSTNコールに分類します：

    
voice class uri 400 sip
 pattern 192\.168\.80\.6[0-5]:5060

    発信元のアドレスとポート番号を説明する1つ以上のパターンを使用して、UCMからPSTNトランクへの着信メッセージを分類します。 必要に応じて、 正規表現を使用してマッチングパターンを定義できます。

    上の例では、 192.168.80.60から65までの範囲のIPアドレスとポート番号5060の任意のIPアドレスと照合するために正規表現が使用されています。

2

Unified CM ホストへのSRVルーティングを指定するには、次のDNSレコードを設定します。

IOS XEはこれらのレコードを使用して、 ターゲットUCMホストとポートをローカルで決定します。 この設定では、 DNSシステムにレコードを設定する必要はありません。 DNSを使用したい場合は、 これらのローカル設定は必要ありません。


ip host ucmpub.mydomain.com 192.168.80.60
ip host ucmsub1.mydomain.com 192.168.80.61
ip host ucmsub2.mydomain.com 192.168.80.62
ip host ucmsub3.mydomain.com 192.168.80.63
ip host ucmsub4.mydomain.com 192.168.80.64
ip host ucmsub5.mydomain.com 192.168.80.65
ip host _sip._udp.wxtocucm.io srv 0 1 5065 ucmpub.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub1.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub2.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub3.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub4.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub5.mydomain.com
ip host _sip._udp.pstntocucm.io srv 0 1 5060 ucmpub.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub1.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub2.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub3.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub4.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub5.mydomain.com

設定用のフィールドの説明は次のとおりです。

次のコマンドは、DNS SRVリソースレコードを作成します。 UCMホストとトランクごとにレコードを作成してください：

ip host _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 host ucmsub5.mydomain.com 192.168.80.65

ip host: ローカルの IOS XE データベースにレコードを作成します。

ucmsub5.mydomain.com: Aレコードのホスト名。

192.168.80.65: ホストのIPアドレスです。

UCM環境と希望する通話分散戦略を反映したSRVリソースレコードとAレコードを作成してください。

3

次のダイヤルピアを設定します。

  1. Unified CMととの間の通話のダイヤルピア Webex Calling

    
dial-peer voice 300 voip
 description UCM-Webex Calling trunk
 destination-pattern BAD.BAD
 session protocol sipv2
 session target dns:wxtocucm.io
 incoming uri via 300
 voice-class codec 100
 voice-class sip bind control source-interface GigabitEthernet 0/0/0
 voice-class sip bind media source-interface GigabitEthernet 0/0/0
 dtmf-relay rtp-nte
 no vad

    設定用のフィールドの説明は次のとおりです。

    
dial-peer voice 300 voip
 description UCM-Webex Calling trunk

    300というタグでVoIPダイヤルピアを定義し、 管理とトラブルシューティングを容易にするためにわかりやすい説明を付けます。

    デスティネーションパターン BAD.BAD

    着信ダイヤルピアグループを使用して発信通話をルーティングする場合は、 ダミーの宛先パターンが必要です。 この場合、任意の有効な宛先パターンを使用できます。

    セッションプロトコル sipv2

    ダイヤルピア300がSIPコールレッグを処理することを指定します。 詳細については、セッションプロトコル (ダイヤルピア) を参照してください。

    セッションターゲット DNS: wxtocucm.io

    Unified CMDNS SRV解像度によって複数のノードのセッションターゲットを定義します。 この場合、 ローカルで定義されたSRVレコードwxtocucm.ioがダイレクトコールに使用されます。

    300経由でURIが届きます

    音声クラス URI 300を使用して、Unified CM 送信元ポート5065を使用するすべての着信トラフィックをこのダイヤルピアに転送します。 詳細については、「 受信URI」を参照してください。

    音声クラスコーデック 100

    Unified CM宛先のコールと発信元のコーデックフィルターリストを示します。 詳細については、 音声クラスコーデックを参照してください。

    バインドコントロールソースインターフェイスギガビットイーサネット 0/0/0

    PSTNに送信されるメッセージの送信元インターフェイスと関連するIPアドレスを設定します。 詳しくは、bindを参照してください。

    バインドメディアソースインターフェイスギガビットイーサネット 0/0/0

    PSTNに送信されるメディアのソースインターフェイスと関連するIPアドレスを設定します。 詳しくは、bindを参照してください。

    DTMF-リレー rtp-nte

    RTP-NTE（RFC2833）を、コールレッグで期待されるDTMF機能として定義しています。 詳細については、「DTMFリレー（ ボイスオーバーIP）」を参照してください。

    いいえ、悪いです

    音声アクティビティ検出を無効にします。 詳細については、vad (ダイヤルピア) を参照してください。

  2. Unified CMと PSTN 間の通話用のダイヤルピア:

    
dial-peer voice 400 voip
 description UCM-PSTN trunk
 destination-pattern BAD.BAD
 session protocol sipv2
 session target dns:pstntocucm.io
 incoming uri via 400
 voice-class codec 100 
 voice-class sip bind control source-interface GigabitEthernet 0/0/0
 voice-class sip bind media source-interface GigabitEthernet 0/0/0
 dtmf-relay rtp-nte
 no vad

    設定用のフィールドの説明は次のとおりです。

    
dial-peer voice 400 voip
 description UCM-PSTN trunk

    400というタグでVoIPダイヤルピアを定義し、 管理とトラブルシューティングを容易にするためにわかりやすい説明を付けます。

    デスティネーションパターン BAD.BAD

    着信ダイヤルピアグループを使用して発信通話をルーティングする場合は、 ダミーの宛先パターンが必要です。 この場合、任意の有効な宛先パターンを使用できます。

    セッションプロトコル sipv2

    ダイヤルピア 400 が SIP コールレッグを処理するように指定します。 詳細については、セッションプロトコル (ダイヤルピア) を参照してください。

    セッションターゲット DNS: pstntocucm.io

    Unified CMDNS SRV解像度によって複数のノードのセッションターゲットを定義します。 この場合、 ローカルで定義されたSRVレコードpstntocucm.ioがダイレクトコールに使用されます。

    400経由でURIが届きます

    音声クラス URI 400を使用して、 Unified CM指定されたホストからのすべての着信トラフィックを、 送信元ポート5060を使用してこのダイヤルピアに転送します。 詳細については、「 受信URI」を参照してください。

    音声クラスコーデック 100

    Unified CM宛先のコールと発信元のコーデックフィルターリストを示します。 詳細については、 音声クラスコーデックを参照してください。

    バインドコントロールソースインターフェイスギガビットイーサネット 0/0/0

    PSTNに送信されるメッセージの送信元インターフェイスと関連するIPアドレスを設定します。 詳しくは、bindを参照してください。

    バインドメディアソースインターフェイスギガビットイーサネット 0/0/0

    PSTNに送信されるメディアのソースインターフェイスと関連するIPアドレスを設定します。 詳しくは、bindを参照してください。

    DTMF-リレー rtp-nte

    RTP-NTE（RFC2833）を、コールレッグで期待されるDTMF機能として定義しています。 詳細については、「DTMFリレー（ ボイスオーバーIP）」を参照してください。

    いいえ、悪いです

    音声アクティビティ検出を無効にします。 詳細については、vad (ダイヤルピア) を参照してください。

4

次の設定を使用してコールルーティングを追加します。

  1. Unified CMとの間で通話をルーティングするダイヤルピアグループを作成してください。Webex Calling DPG 100をアウトバウンドダイヤルピア100に定義してください。Webex Calling DPG 100は、 からの関連する着信ダイヤルピアに適用されます。Unified CM 同様に、DPG 300をアウトバウンドダイヤルピア300と定義してください。Unified CM DPG 300は、 Webexからの着信ダイヤルピアに適用されます。

    
voice class dpg 100
 description Route calls to Webex Calling
 dial-peer 100
voice class dpg 300
 description Route calls to Unified CM Webex Calling trunk
 dial-peer 300

  2. Unified CMとPSTNとの間で通話をルーティングするダイヤルピアグループを作成してください 。 PSTNへのアウトバウンドダイヤルピア200でDPG 200を定義してください。 DPG 200は、 からの関連する着信ダイヤルピアに適用されます。Unified CM 同様に、DPG 400をアウトバウンドダイヤルピア400と定義してください。Unified CM DPG 400は、 PSTNからの着信ダイヤルピアに適用されます。

    
voice class dpg 200
 description Route calls to PSTN
 dial-peer 200
voice class dpg 400
 description Route calls to Unified CM PSTN trunk
 dial-peer 400

    設定用のフィールドの説明は次のとおりです。

    ダイヤルピア 100

    アウトバウンドダイヤルピアをダイヤルピアグループに関連付けます 。 詳細については、 ボイスクラスのDPGを参照してください。

  3. ダイヤルピアグループを適用して、Webex から Webex Unified CM への通話と Webex からの通話をルーティングします。 Unified CM 

    
dial-peer voice 100
 destination dpg 300
dial-peer voice 300
 destination dpg 100

    設定用のフィールドの説明は次のとおりです。

    デスティネーション・ドッグ 300%

    どのダイヤルピアグループ 、 つまりこの着信ダイヤルピアに送られるコールの発信処理にダイヤルピアを使用するかを指定します。

  4. ダイヤルピアグループを適用して、PSTNからのコールをPSTNへ、Unified CM Unified CMまたはPSTNからPSTNにルーティングします。

    
dial-peer voice 200
 destination dpg 400
dial-peer voice 400
 destination dpg 200

    これで、ローカルゲートウェイの設定は終了です。 CUBEの機能を初めて設定する場合は、設定を保存してプラットフォームをリロードしてください。

診断シグネチャを使ってローカルゲートウェイを監視し、トラブルシューティングします

Diagnostic Signatures（DS）は、Cisco IOS XEベースのローカルゲートウェイでよく見られる問題を積極的に検出し、そのイベントの電子メール、Syslog、 またはターミナルメッセージ通知を生成します。 DSをインストールして診断データの収集を自動化し、Cisco TAC 収集したデータをケースに転送して解決時間を短縮することもできます。

診断署名（DS）は、問題の通知、トラブルシューティング、 および修復のための問題のトリガーイベントとアクションに関する情報を含むXMLファイルです。 syslogメッセージ、SNMPイベント、 および特定のshowコマンドの出力を定期的に監視して、問題検出ロジックを定義します。 アクションタイプには以下が含まれます：

  • showコマンド出力の収集

  • 統合ログファイルの生成

  • HTTPS、SCP、FTPサーバーなど、ユーザーが提供したネットワークの場所にファイルをアップロードする

TACのエンジニアは、完全性を保護するためにDSファイルを作成し、デジタル署名します。 各DSファイルには、システムによって割り当てられた一意の数値IDがあります。 診断署名検索ツール（DSLT）は、 さまざまな問題の監視とトラブルシューティングに適切な署名を見つけるための単一の情報源です。

始める前に:

  • DSLTからダウンロードしたDSファイルは編集しないでください。 変更したファイルは、 整合性チェックエラーのためにインストールに失敗します。

  • ローカルゲートウェイがメール通知を送信するために必要な簡易メール転送プロトコル（SMTP）サーバー。

  • メール通知に安全なSMTPサーバーを使用する場合は、ローカルゲートウェイでIOS XE 17.6.1以降が実行されていることを確認してください。

前提条件

IOS XE 17.6.1以降を実行するローカルゲートウェイ

  1. 診断署名はデフォルトで有効になっています。

  2. デバイスがIOS XE 17.6.1以降を実行している場合にプロアクティブな通知を送信するために使用する安全なメールサーバーを設定してください。

    
configure terminal 
call-home  
mail-server <username>:<pwd>@<email server> priority 1 secure tls 
end

  3. 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% 以上になると、すべてのデバッグが無効になり、 ローカルゲートウェイにインストールしたすべての診断シグネチャがアンインストールされます。 以下の手順で署名をインストールしてください。

  1. show snmpコマンドを使用してSNMPを有効にしたことを確認してください。 SNMPが有効になっていない場合は、 snmp-server managerコマンドを設定してください。

    
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

  2. 診断署名検索ツールの次のドロップダウンオプションを使用してDS 64224をダウンロードします。

    copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash:

    フィールド名

    フィールド値

    プラットフォーム

    シスコ 4300、4400 ISR シリーズ、または Catalyst 8000V エッジソフトウェア

    製品

    CUBE Webex Calling エンタープライズインソリューション

    問題の範囲

    パフォーマンス

    問題の種類

    メール通知でCPU使用率が高い

    Download DS 64224 from Diagnostic Signatures Lookup tool

  3. 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)

  4. DS XMLファイルをローカルゲートウェイにインストールします。

    
call-home diagnostic-signature load DS_64224.xml 
Load file DS_64224.xml success

  5. 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

    DSE のダウンロード:

    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と電子メール通知が生成されます。 以下の手順で署名をインストールしてください。

  1. show snmpコマンドを使用してSNMPが有効になっていることを確認してください。 SNMPが有効になっていない場合は、 snmp-server managerコマンドを設定してください。 

    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

  2. 診断署名検索ツールの次のオプションを使用してDS 65221をダウンロードしてください。

    フィールド名

    フィールド値

    プラットフォーム

    シスコ 4300、4400 ISR シリーズ、または Catalyst 8000V エッジソフトウェア

    製品

    CUBE Webex Calling エンタープライズ・イン・ソリューション

    問題の範囲

    パフォーマンス

    問題の種類

    メールとSyslog通知によるSIP異常通話切断検出。

  3. DS XMLファイルをローカルゲートウェイにコピーします。

    copy ftp://username:password@<server name or ip>/DS_65221.xml bootflash:

  4. DS XMLファイルをローカルゲートウェイにインストールします。 

    
call-home diagnostic-signature load DS_65221.xml 
Load file DS_65221.xml success

  5. show call-home diagnostic-signatureコマンドを使用して、 シグネチャが正常にインストールされていることを確認します。 ステータス列には「登録済み」 の値があるはずです。

問題のトラブルシューティングには診断シグネチャをインストールしてください

また、診断署名（DS）を使って問題を迅速に解決することもできます。 Cisco TACエンジニアは、 特定の問題のトラブルシューティング、問題の発生の検出、適切な診断データの収集、 およびケースへのデータの自動転送に必要なデバッグを可能にするいくつかのシグネチャを作成しています。 Cisco TAC これにより、問題の発生を手動で確認する必要がなくなり、 断続的な問題や一時的な問題のトラブルシューティングがはるかに簡単になります。

Diagnostic Signatures Lookup Toolを使用して、 該当するシグネチャを見つけてインストールし、特定の問題を自己解決することができます。また、 サポート契約の一環としてTACのエンジニアが推奨するシグネチャをインストールすることもできます。

これは、 「% VOICE_IEC -3-GW: CCAPI: 内部エラー (コールスパイクしきい値): IEC=1.1.181.1.29.0" syslogの発生を検出するDSを見つけてインストールし、次の手順を使用して診断データを自動的に収集する方法の例です。

  1. 診断データをアップロードするには、Cisco TACファイルサーバーパス（cxd.cisco.com）ds_fsurl_prefixとして別のDS環境変数を設定します。 ファイルパスのユーザー名はケース番号、 パスワードはファイルアップロードトークンです。次に示すように、 サポートケースマネージャーから取得できます。 ファイルアップロードトークンは、 必要に応じてサポートケースマネージャーの添付ファイルセクションで生成できます。

     The file upload token generated in the Attachments section of the 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"

  2. show snmpコマンドを使用してSNMPが有効になっていることを確認してください。 SNMPが有効になっていない場合は、 snmp-serverマネージャーコマンドを設定してください。

    
show snmp 
%SNMP agent not enabled 
 
config t 
snmp-server manager 
end

  3. CPU使用率が高いときにすべてのデバッグと診断シグネチャを無効にする予防策として、高CPU監視DS 64224をインストールすることをお勧めします。 診断署名検索ツールの次のオプションを使用してDS 64224をダウンロードしてください。

    フィールド名

    フィールド値

    プラットフォーム

    シスコ 4300、4400 ISR シリーズ、または Catalyst 8000V エッジソフトウェア

    製品

    CUBE Webex Calling エンタープライズ・イン・ソリューション

    問題の範囲

    パフォーマンス

    問題の種類

    メール通知でCPU使用率が高い。

  4. 診断署名検索ツールの次のオプションを使用してDS 65095をダウンロードしてください。

    フィールド名

    フィールド値

    プラットフォーム

    シスコ 4300、4400 ISR シリーズ、または Catalyst 8000V エッジソフトウェア

    製品

    CUBE Webex Calling エンタープライズ・イン・ソリューション

    問題の範囲

    システムログ

    問題の種類

    シスログ-% VOICE_IEC -3-GW: CCAPI: 内部エラー (コールスパイクしきい値): IEC=1.1.181.1.29.0

  5. 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:

  6. ハイ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

  7. 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 
           ds_fsurl_prefix: scp://612345678:abcdefghijklmnop@cxd.cisco.com

    ダウンロードした DSE:

    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 call-home diagnostic-signatureコマンドの「ステータス」列が「実行中」に変わります。 show 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

ダウンロードした DSE:

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/Y

23.053

23.053

Diagnostic Signatureの実行中に送信される通知メールには、問題の種類、デバイスの詳細、ソフトウェアのバージョン、 実行中の構成、 特定の問題のトラブルシューティングに関連するshowコマンドの出力などの重要な情報が含まれています。

Notification email that is sent during Diagnostic Signature execution

診断シグネチャをアンインストールします

診断シグネチャをトラブルシューティングに使用するのは、通常、 何らかの問題が発生したことを検出した後にアンインストールするように定義されています。 シグネチャを手動でアンインストールしたい場合は、show call-home diagnostic-signatureの出力からDS IDを取得して、次のコマンドを実行してください。

call-home diagnostic-signature deinstall <DS ID>

例:

call-home diagnostic-signature deinstall 64224

新しい署名は、 導入時に発生した問題に基づいて、診断署名検索ツールに定期的に追加されます。 TACは現在、 新しいカスタム署名の作成リクエストをサポートしていません。

CUBEの高可用性をローカルゲートウェイとして実装してください

ファンダメンタルズ

前提条件

CUBE HAをのローカルゲートウェイとして導入する前にWebex Calling、次の概念を深く理解していることを確認してください。

この記事に記載されている設定ガイドラインは、既存の音声設定がない専用のローカルゲートウェイプラットフォームを想定しています。 既存のCUBEエンタープライズ環境がローカルゲートウェイ機能も利用するように変更されている場合はCisco Webex Calling、適用されている設定に細心の注意を払って、既存のコールフローや機能が中断されないようにし、CUBE HAの設計要件に従っていることを確認してください。

ハードウェアとソフトウェアのコンポーネント

ローカルゲートウェイとしてのCUBE HAには、IOS-XEバージョン16.12.2以降と、CUBE HAとLGWの両方の機能をサポートするプラットフォームが必要です。

この記事で紹介しているshowコマンドとログは、vCube（CSR1000v）Cisco IOSに実装された-XE 16.12.2の最小ソフトウェアリリースに基づいています。

参考資料

さまざまなプラットフォームの詳細なCUBE HA構成ガイドは次のとおりです。

Webex Callingソリューションの概要

Cisco Webex Callingは、複数のPSTNオプションを備えたオンプレミスのPBX電話サービスに代わるマルチテナント型のクラウドベースの代替サービスを顧客に提供するコラボレーション製品です。

この記事では、ローカルゲートウェイの導入（下記参照）に焦点を当てています。 ローカルゲートウェイ（構内ベースのPSTN）Webex Callingトランクインにより、顧客所有のPSTNサービスに接続できます。 また、次のようなオンプレミスのIP PBX環境への接続も提供します。Cisco Unified CM クラウドとのすべての通信は、SIPの場合はTLS転送、メディアの場合はSRTPを使用して保護されます。

下の図は、既存のIP Webex Calling PBXがない展開を示しており、単一サイトまたは複数サイトの展開に適用できます。 この記事で概説されている設定は、この展開に基づいています。

レイヤー2のボックスツーボックス冗長性

CUBE HAレイヤー2のボックスツーボックス冗長性は、冗長グループ（RG）インフラストラクチャプロトコルを使用して、アクティブ/スタンバイのルーターのペアを形成します。 このペアは、それぞれのインターフェイスで同じ仮想IPアドレス（VIP）を共有し、ステータスメッセージを継続的に交換します。 CUBEセッション情報は、ルータのペア間でチェックポイントされ、アクティブルータがサービスを停止した場合でも、スタンバイルータがすべてのCUBEコール処理をすぐに引き継ぐことができるため、シグナリングとメディアがステートフルに保持されます。

チェックポインティングは、メディアパケットを含む接続された通話に限られます。 転送中のコールはチェックポイントされません（たとえば、送信中または呼び出し中の状態）。

この記事では、CUBE HAはステートフルコール保存のためのCUBEハイアベイラビリティ（HA）レイヤー2のボックスツーボックス（B2B）冗長性について言及します

IOS-XE 16.12.2以降、CUBE Cisco Webex Calling HAはトランク（オンプレミスベースのPSTN）導入用のローカルゲートウェイとして導入できます。この記事では、設計上の考慮事項と構成について説明します。 この図は、Cisco Webex Callingトランク導入のローカルゲートウェイとしての典型的なCUBE HA設定を示しています。

リダンダンシー・グループ・インフラストラクチャー・コンポーネント

冗長グループ（RG）インフラコンポーネントは、2つのCUBE間のボックスツーボックス通信インフラストラクチャサポートを提供し、最終的な安定した冗長状態をネゴシエートします。 このコンポーネントは以下も提供します：

  • 2つのキューブ間で（制御インターフェイスを介して）キープアライブメッセージとハローメッセージを交換することにより、各ルーターの最終的な冗長状態をネゴシエートするHSRPのようなプロトコルです。上の図のGigabitEthernet3です。

  • アクティブルータからスタンバイルータへ（データインターフェイスを介して）各コールのシグナリングとメディア状態をチェックポイントする転送メカニズム。上の図のGigabitEthernet3です。

  • トラフィックインターフェイス用の仮想IP（VIP）インターフェイスの構成と管理（同じRGグループを使用して複数のトラフィックインターフェイスを設定できます）— GigabitEthernet 1と2はトラフィックインターフェイスと見なされます。

このRGコンポーネントは、音声B2B HAをサポートするように特別に設定する必要があります。

シグナリングとメディアの両方の仮想IP（VIP）アドレス管理

B2B HAは冗長性を実現するためにVIPに依存しています。 CUBE HAペアの両方のCUBEのVIPと関連する物理インターフェイスは、同じLANサブネット上にある必要があります。 音声B2B HAサポートには、VIPの設定と特定の音声アプリケーション（SIP）へのVIPインターフェイスのバインディングが必須です。 Webex CallingアクセスSBC Unified CM、サービスプロバイダー、プロキシなどの外部デバイスは、CUBE HAルーターを通過する通話の宛先IPアドレスとしてVIPを使用します。 したがって、Webex Calling観点から見ると、CUBE HAペアは単一のローカルゲートウェイとして機能します。

確立されたコールのコールシグナリングとRTPセッション情報は、アクティブルーターからスタンブルーターにチェックポイントされます。 アクティブルーターがダウンすると、スタンバイルーターが引き継ぎ、最初のルーターで以前にルーティングされていたRTPストリームを転送し続けます。

フェールオーバー時に一時的な状態のコールは、切り替え後も保存されません。 たとえば、まだ完全に確立されていない通話や、転送機能や保留機能で変更中の通話などです。 確立された通話は、切り替え後に切断される場合があります。

CUBE HAをコールのステートフルフェールオーバーのローカルゲートウェイとして使用するには、次の要件があります。

  • CUBE HAでは、TDMやアナログインターフェイスを同じ場所に配置することはできません

  • Gig1とGig2はトラフィック（SIP/RTP）インターフェイスと呼ばれ、Gig3は冗長グループ（RG）制御/データインターフェイスと呼ばれます

  • 同じレイヤー2のドメインに配置できるCUBE HAペアは2つまでです。1組はグループID 1、もう1組はグループID 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は同じスイッチなどで終端する必要があります。

  • WANをCubeで直接終端したり、データHAをどちらかの側で終端したりすることはできません

  • アクティブ/スタンバイの両方が同じデータセンターにある必要があります

  • 冗長性のために個別のL3インターフェイス（RG制御/データ、Gig3）を使用することが必須です。つまり、トラフィックに使用されるインターフェイスは、HAキープアライブとチェックポインティングには使用できません

  • フェイルオーバー時には、以前アクティブだったCUBEが意図的にリロードされ、シグナリングとメディアが保持されます

両方のキューブに冗長性を設定してください

仮想IPを起動するためにHAペアで使用することを目的として、両方のCUBEにレイヤー2のボックスツーボックス冗長性を設定する必要があります。

1

インターフェイスの状態を追跡するために、グローバルレベルでインターフェーストラッキングを設定してください。

conf t
 track 1 interface GigabitEthernet1 line-protocol
 track 2 interface GigabitEthernet2 line-protocol
 exit


VCUBE-1#conf t

VCUBE-1(config)#track 1 interface GigabitEthernet1 line-protocol

VCUBE-1(config-track)#track 2 interface GigabitEthernet2 line-protocol

VCUBE-1(config-track)#exit

VCUBE-2#conf t

VCUBE-2(config)#track 1 interface GigabitEthernet1 line-protocol

VCUBE-2(config-track)#track 2 interface GigabitEthernet2 line-protocol

VCUBE-2(config-track)#exit

Track CLIはRGで音声トラフィックインターフェイスの状態を追跡し、トラフィックインターフェイスがダウンした後もアクティブルートがアクティブな役割を果たすようにします。

2

アプリケーション冗長サブモードで、VoIP HAで使用するようにRGを設定します。

redundancy
  application redundancy
   group 1
    name LocalGateway-HA
    priority 100 failover threshold 75
    control GigabitEthernet3 protocol 1
    data GigabitEthernet3
    timers delay 30 reload 60
    track 1 shutdown
    track 2 shutdown
    exit
   protocol 1
    timers hellotime 3 holdtime 10
   exit
  exit
 exit


VCUBE-1(config)#redundancy

VCUBE-1(config-red)#application redundancy

VCUBE-1(config-red-app)#group 1

VCUBE-1(config-red-app-grp)#name LocalGateway-HA

VCUBE-1(config-red-app-grp)#priority 100 failover threshold 75

VCUBE-1(config-red-app-grp)#control GigabitEthernet3 protocol 1

VCUBE-1(config-red-app-grp)#data GigabitEthernet3

VCUBE-1(config-red-app-grp)#timers delay 30 reload 60

VCUBE-1(config-red-app-grp)#track 1 shutdown

VCUBE-1(config-red-app-grp)#track 2 shutdown

VCUBE-1(config-red-app-grp)#exit

VCUBE-1(config-red-app)#protocol 1

VCUBE-1(config-red-app-prtcl)#timers hellotime 3 holdtime 10

VCUBE-1(config-red-app-prtcl)#exit

VCUBE-1(config-red-app)#exit

VCUBE-1(config-red)#exit

VCUBE-1(config)#

VCUBE-2(config)#redundancy

VCUBE-2(config-red)#application redundancy

VCUBE-2(config-red-app)#group 1

VCUBE-2(config-red-app-grp)#name LocalGateway-HA

VCUBE-2(config-red-app-grp)#priority 100 failover threshold 75

VCUBE-2(config-red-app-grp)#control GigabitEthernet3 protocol 1

VCUBE-1(config-red-app-grp)#data GigabitEthernet3

VCUBE-2(config-red-app-grp)#timers delay 30 reload 60

VCUBE-2(config-red-app-grp)#track 1 shutdown

VCUBE-2(config-red-app-grp)#track 2 shutdown

VCUBE-2(config-red-app-grp)#exit

VCUBE-2(config-red-app)#protocol 1

VCUBE-2(config-red-app-prtcl)#timers hellotime 3 holdtime 10

VCUBE-2(config-red-app-prtcl)#exit

VCUBE-2(config-red-app)#exit

VCUBE-2(config-red)#exit

VCUBE-2(config)#

この設定で使用されるフィールドの説明は次のとおりです。

  • 冗長性—冗長モードに入ります

  • アプリケーション冗長性 — アプリケーション冗長構成モードに入ります

  • group：冗長アプリケーショングループコンフィギュレーションモードに入ります

  • 名前：ローカルゲートウェイ-HA — RGグループの名前を定義します

  • 優先度 100 フェイルオーバーのしきい値 75 — RG の初期優先度とフェイルオーバーのしきい値を指定します

  • タイマー遅延 30、リロード 60 —遅延とリロードの 2 つの時間を設定します

    • インターフェイスが起動してからRGグループの初期化とロールネゴシエーションを遅延させる時間を示す遅延タイマー。デフォルトは30秒です。 範囲は0〜10000秒です

    • リロード-これは、リロード後にRGグループの初期化とロールネゴシエーションを遅延させる時間です。デフォルトは60秒です。 範囲は0〜10000秒です

    • デフォルトのタイマーをお勧めしますが、これらのタイマーは、ネットワーク内のルーティングが安定したポイントに収束した後にRGプロトコルのネゴシエーションが行われるようにするために、ルーターの起動/リロード中に発生する可能性のある追加のネットワークコンバージェンス遅延に対応するように調整できます。 たとえば、フェイルオーバー後、新しいSTANDBYが新しいACTIVEからの最初のRG HELLOパケットを受信するまでに最大20秒かかることがわかった場合は、この遅延を考慮してタイマーを「timers delay 60 reload 120」に調整する必要があります。

  • control GigabitEthernet3プロトコル1 — 2つのキューブ間でキープアライブメッセージとハローメッセージを交換するために使用されるインターフェイスを設定し、制御インターフェイスに接続するプロトコルインスタンスを指定して、冗長アプリケーションプロトコルコンフィギュレーションモードに入ります

  • data GigabitEthernet3 — データトラフィックのチェックポイントに使用されるインターフェイスを設定します

  • track —インターフェイスのRGグループトラッキング

  • プロトコル1 —制御インターフェイスに接続するプロトコルインスタンスを指定し、冗長アプリケーションプロトコルコンフィギュレーションモードに入ります

  • タイマーハロータイム 3 ホールドタイム 10 — ハロータイムとホールドタイムの2つのタイマーを設定します。

    • hello time — 連続する hello メッセージの間隔 — デフォルトは3秒です。 範囲は250ミリ秒から254秒です

    • ホールドタイム：Hello メッセージを受信してから送信側ルーターに障害が発生したと推定されるまでの間隔。 この時間はハロータイムより長くなければなりません-デフォルトは10秒です。 範囲は750ミリ秒から255秒です

      ホールドタイムタイマーは、ハロータイムタイマーの値の少なくとも3倍に設定することをお勧めします。

3

CUBEアプリケーションのボックスツーボックス冗長性を有効にします。 voice service voipの前のステップでRGを設定してください。 これにより、CUBEアプリケーションは冗長プロセスを制御できます。

voice service voip
   redundancy-group 1
   exit

VCUBE-1(config)#voice service voip

VCUBE-1(config-voi-serv)#redundancy-group 1


                        % Created RG 1 association with Voice B2B HA; reload the router for the new configuration to take effect
                      

VCUBE-1(config-voi-serv)# exit

VCUBE-2(config)#voice service voip

VCUBE-2(config-voi-serv)#redundancy-group 1


                        % Created RG 1 association with Voice B2B HA; reload the router for the new configuration to take effect
                      

VCUBE-2(config-voi-serv)# exit

redundancy-group 1 — このコマンドを追加したり削除したりするには、更新された設定を有効にするためにリロードする必要があります。 すべての設定が適用されたら、プラットフォームをリロードします。

4

以下に示すように、Gig1とGig2のインターフェースをそれぞれの仮想IPで設定し、冗長インターフェース識別子（rii）を適用します

VCUBE-1(config)#interface GigabitEthernet1

VCUBE-1(config-if)# redundancy rii 1

VCUBE-1(config-if)# redundancy group 1 ip 198.18.1.228 exclusive

VCUBE-1(config-if)# exit

VCUBE-1(config)#

VCUBE-1(config)#interface GigabitEthernet2

VCUBE-1(config-if)# redundancy rii 2

VCUBE-1(config-if)# redundancy group 1 ip 198.18.133.228 exclusive

VCUBE-1(config-if)# exit

VCUBE-2(config)#interface GigabitEthernet1

VCUBE-2(config-if)# redundancy rii 1

VCUBE-2(config-if)# redundancy group 1 ip 198.18.1.228 exclusive

VCUBE-2(config-if)# exit

VCUBE-2(config)#

VCUBE-2(config)#interface GigabitEthernet2

VCUBE-2(config-if)# redundancy rii 2

VCUBE-2(config-if)# redundancy group 1 ip 198.18.133.228 exclusive

VCUBE-v(config-if)# exit

この設定で使用されるフィールドの説明は次のとおりです。

  • redundancy rii —冗長グループの冗長インターフェイス識別子を設定します。 仮想MAC（VMAC）アドレスの生成に必要です。 同じVIPを持つ各ルーター（ACTIVE/STANDBY）のインターフェイスでは、同じrii ID値を使用する必要があります。

    同じLANに複数のB2Bペアがある場合は、各ペアがそれぞれのインターフェイスに固有のrii IDを持っている必要があります（衝突を防ぐため）。「冗長アプリケーショングループをすべて表示」は、正しいローカル情報とピア情報を示している必要があります。

  • 冗長グループ1 —インターフェイスを上記のステップ2で作成した冗長グループに関連付けます。 RGグループと、この物理インターフェースに割り当てられたVIPを設定します。

    冗長性のために別のインターフェイスを使用することが必須です。つまり、音声トラフィックに使用されるインターフェイスは、上記のステップ2で指定された制御およびデータインターフェイスとして使用できません。 この例では、ギガビットインターフェイス3がRG制御/データに使用されています

5

最初のCUBEの設定を保存してリロードしてください。

最後にリロードするプラットフォームは常にスタンバイです。

VCUBE-1#wr


                        Building configuration...
                      


                        [OK]
                      

VCUBE-1#reload


                        Proceed with reload? [confirm]

VCUBE-1が完全に起動したら、VCUBE-2の設定を保存してリロードしてください。

VCUBE-2#wr


                        Building configuration...
                      


                        [OK]
                      

VCUBE-2#reload


                        Proceed with reload? [confirm]

6

ボックスツーボックスの構成が期待どおりに機能していることを確認してください。 関連する出力は太字で強調表示されています。

VCUBE-2を最後にリロードしましたが、設計上の考慮事項によると、最後にリロードするプラットフォームは常にスタンバイです。 


VCUBE-1#show redundancy application group all
Faults states Group 1 info:
       Runtime priority: [100]
               RG Faults RG State: Up.
                       Total # of switchovers due to faults:           0
                       Total # of down/up state changes due to faults: 0
Group ID:1
Group Name:LocalGateway-HA
  
Administrative State: No Shutdown
Aggregate operational state: Up
My Role: ACTIVE
Peer Role: STANDBY
Peer Presence: Yes
Peer Comm: Yes
Peer Progression Started: Yes

RF Domain: btob-one
         RF state: ACTIVE
         Peer RF state: STANDBY HOT

RG Protocol RG 1
------------------
        Role: Active
        Negotiation: Enabled
        Priority: 100
        Protocol state: Active
        Ctrl Intf(s) state: Up
        Active Peer: Local
        Standby Peer: address 10.1.1.2, priority 100, intf Gi3
        Log counters:
                role change to active: 1
                role change to standby: 1
                disable events: rg down state 0, rg shut 0
                ctrl intf events: up 1, down 0, admin_down 0
                reload events: local request 0, peer request 0

RG Media Context for RG 1
--------------------------
        Ctx State: Active
        Protocol ID: 1
        Media type: Default
        Control Interface: GigabitEthernet3
        Current Hello timer: 3000
        Configured Hello timer: 3000, Hold timer: 10000
        Peer Hello timer: 3000, Peer Hold timer: 10000
        Stats:
            Pkts 1509, Bytes 93558, HA Seq 0, Seq Number 1509, Pkt Loss 0
            Authentication not configured
            Authentication Failure: 0
            Reload Peer: TX 0, RX 0
            Resign: TX 0, RX 0
    Standy Peer: Present. Hold Timer: 10000
            Pkts 61, Bytes 2074, HA Seq 0, Seq Number 69, Pkt Loss 0

VCUBE-1#

VCUBE-2#show redundancy application group all
Faults states Group 1 info:
       Runtime priority: [100]
               RG Faults RG State: Up.
                       Total # of switchovers due to faults:           0
                       Total # of down/up state changes due to faults: 0
Group ID:1
Group Name:LocalGateway-HA
  
Administrative State: No Shutdown
Aggregate operational state: Up
My Role: STANDBY
Peer Role: ACTIVE
Peer Presence: Yes
Peer Comm: Yes
Peer Progression Started: Yes

RF Domain: btob-one
         RF state: ACTIVE
         Peer RF state: STANDBY HOT

RG Protocol RG 1
------------------
        Role: Active
        Negotiation: Enabled
        Priority: 100
        Protocol state: Active
        Ctrl Intf(s) state: Up
        Active Peer: address 10.1.1.2, priority 100, intf Gi3
        Standby Peer: Local
        Log counters:
                role change to active: 1
                role change to standby: 1
                disable events: rg down state 0, rg shut 0
                ctrl intf events: up 1, down 0, admin_down 0
                reload events: local request 0, peer request 0

RG Media Context for RG 1
--------------------------
        Ctx State: Active
        Protocol ID: 1
        Media type: Default
        Control Interface: GigabitEthernet3
        Current Hello timer: 3000
        Configured Hello timer: 3000, Hold timer: 10000
        Peer Hello timer: 3000, Peer Hold timer: 10000
        Stats:
            Pkts 1509, Bytes 93558, HA Seq 0, Seq Number 1509, Pkt Loss 0
            Authentication not configured
            Authentication Failure: 0
            Reload Peer: TX 0, RX 0
            Resign: TX 0, RX 0
    Standy Peer: Present. Hold Timer: 10000
            Pkts 61, Bytes 2074, HA Seq 0, Seq Number 69, Pkt Loss 0

VCUBE-2#

両方のCUBEにローカルゲートウェイを設定してください

この構成例では、Control Hubからの次のトランク情報を使用して、VCUBE-1とVCUBE-2の両方のプラットフォームでローカルゲートウェイ構成を構築しています。 このセットアップのユーザー名とパスワードは次のとおりです。

  • ユーザー名:Hussain1076_LGU

  • パスワード:lov12Meazx

1

認証情報や共有シークレットで使用する前に、以下に示すコマンドを使用してパスワードの設定キーが作成されていることを確認してください。 タイプ6のパスワードは、AES暗号とこのユーザー定義の設定キーを使用して暗号化されます。 


LocalGateway#conf t
LocalGateway(config)#key config-key password-encrypt Password123
LocalGateway(config)#password encryption aes

これは、上記のコントロールハブのパラメータに基づいて両方のプラットフォームに適用されるローカルゲートウェイの設定です。保存してリロードします。 コントロールハブのSIPダイジェスト認証情報は太字で強調表示されています。


configure terminal
crypto pki trustpoint dummyTp
revocation-check crl
exit
sip-ua
crypto signaling default trustpoint dummyTp cn-san-validate server
transport tcp tls v1.2
end


configure terminal
crypto pki trustpool import clean url
http://www.cisco.com/security/pki/trs/ios_core.p7b
end


configure terminal
voice service voip
  ip address trusted list
    ipv4 x.x.x.x y.y.y.y
    exit
   allow-connections sip to sip
  media statistics
  media bulk-stats
  no supplementary-service sip refer
  no supplementary-service sip handle-replaces
  fax protocol pass-through g711ulaw
  stun
    stun flowdata agent-id 1 boot-count 4
    stun flowdata shared-secret 0 Password123!
  sip
    g729 annexb-all
    early-offer forced
    end


configure terminal
voice class sip-profiles 200
  rule 9 request ANY sip-header SIP-Req-URI modify "sips:(.*)"
"sip:\1"
  rule 10 request ANY sip-header To modify "<sips:(.*)" "<sip:\1"
  rule 11 request ANY sip-header From modify "<sips:(.*)" "<sip:\1"
  rule 12 request ANY sip-header Contact modify "<sips:(.*)>"
"<sip:\1;transport=tls>"
  rule 13 response ANY sip-header To modify "<sips:(.*)" "<sip:\1"
  rule 14 response ANY sip-header From modify "<sips:(.*)" "<sip:\1"
  rule 15 response ANY sip-header Contact modify "<sips:(.*)"
"<sip:\1"
  rule 20 request ANY sip-header From modify ">"
";otg=hussain1076_lgu>"
  rule 30 request ANY sip-header P-Asserted-Identity modify
"sips:(.*)" "sip:\1"


voice class codec 99
  codec preference 1 g711ulaw
  codec preference 2 g711ulaw
  exit

voice class srtp-crypto 200
  crypto 1 AES_CM_128_HMAC_SHA1_80
  exit

voice class stun-usage 200
  stun usage firewall-traversal flowdata
  exit






voice class tenant 200
  registrar dns:40462196.cisco-bcld.com scheme sips expires 240
refresh-ratio 50 tcp tls
  credentials number Hussain5091_LGU username Hussain1076_LGU
password 0 lOV12MEaZx realm Broadworks 
  authentication username Hussain5091_LGU password 0 lOV12MEaZx
realm BroadWorks

  authentication username Hussain5091_LGU password 0 lOV12MEaZx
realm 40462196.cisco-bcld.com
  no remote-party-id
  sip-server dns:40462196.cisco-bcld.com
  connection-reuse
  srtp-crypto 200
  session transport tcp tls
  url sips
  error-passthru
  asserted-id pai
  bind control source-interface GigabitEthernet1
  bind media source-interface GigabitEthernet1
  no pass-thru content custom-sdp
  sip-profiles 200
  outbound-proxy dns:la01.sipconnect-us10.cisco-bcld.com
  privacy-policy passthru


voice class tenant 100
  session transport udp
  url sip
  error-passthru
  bind control source-interface GigabitEthernet2
  bind media source-interface GigabitEthernet2
  no pass-thru content custom-sdp

voice class tenant 300
  bind control source-interface GigabitEthernet2
  bind media source-interface GigabitEthernet2
  no pass-thru content custom-sdp
  

voice class uri 100 sip
 host ipv4:198.18.133.3

voice class uri 200 sip
 pattern dtg=hussain1076.lgu



dial-peer voice 101 voip
 description Outgoing dial-peer to IP PSTN
 destination-pattern BAD.BAD
 session protocol sipv2
 session target ipv4:198.18.133.3
 voice-class codec 99
 voice-class sip tenant 100
 dtmf-relay rtp-nte
 no vad

dial-peer voice 201 voip
 description Outgoing dial-peer to Webex Calling
 destination-pattern BAD.BAD
 session protocol sipv2
 session target sip-server
 voice-class codec 99
 voice-class stun-usage 200
 no voice-class sip localhost
 voice-class sip tenant 200
 dtmf-relay rtp-nte
 srtp
 no vad


voice class dpg 100
 description Incoming WebexCalling(DP200) to IP PSTN(DP101)
 dial-peer 101 preference 1

voice class dpg 200
 description Incoming IP PSTN(DP100) to Webex Calling(DP201)
 dial-peer 201 preference 1





dial-peer voice 100 voip
 desription Incoming dial-peer from IP PSTN
 session protocol sipv2
 destination dpg 200
 incoming uri via 100
 voice-class codec 99
 voice-class sip tenant 300
 dtmf-relay rtp-nte
 no vad

dial-peer voice 200 voip
 description Incoming dial-peer from Webex Calling
 session protocol sipv2
 destination dpg 100
 incoming uri request 200
 voice-class codec 99
 voice-class stun-usage 200
 voice-class sip tenant 200
 dtmf-relay rtp-nte
 srtp
 no vad

end

copy run start

showコマンドの出力を表示するために、VCUBE-2をリロードし、続いてVCUBE-1をリロードして、VCUBE-1をスタンバイキューブ、VCUBE-2をアクティブキューブにしました。

2

常に、Webex CallingアクセスSBCを使用してローカルゲートウェイとしてアクティブに登録されているプラットフォームは1つだけです。 次の show コマンドの出力を見てください。

冗長アプリケーショングループ1を示してください

sip-ua登録ステータスを表示してください 


VCUBE-1#show redundancy application group 1
Group ID:1
Group Name:LocalGateway-HA

Administrative State: No Shutdown
Aggregate operational state : Up
My Role: Standby
Peer Role: ACTIVE
Peer Presence: Yes
Peer Comm: Yes
Peer Progression Started: Yes

RF Domain: btob-one
         RF state: STANDBY HOT
         Peer RF state: ACTIVE

VCUBE-1#show sip-ua register status
VCUBE-1#


VCUBE-2#show redundancy application group 1
Group ID:1
Group Name:LocalGateway-HA

Administrative State: No Shutdown
Aggregate operational state : Up
My Role: ACTIVE
Peer Role: STATUS
Peer Presence: Yes
Peer Comm: Yes
Peer Progression Started: Yes

RF Domain: btob-one
         RF state: ACTIVE
         Peer RF state: STANDBY HOT

VCUBE-2#show sip-ua register status

Tenant: 200
--------------------Registrar-Index  1 ---------------------
Line                           peer       expires(sec) reg survival P-Associ-URI
============================== ========== ============ === ======== ============
Hussain5091_LGU                -1          48          yes normal
VCUBE-2#

上の出力から、Webex CallingVCUBE-2はアクセスSBCで登録を維持しているアクティブなLGWであるのに対し、VCUBE-1では「show sip-uaレジスタステータス」の出力が空白であることがわかります。

3

次に、VCUBE-1で次のデバッグを有効にしてください


VCUBE-1#debug ccsip non-call
SIP Out-of-Dialog tracing is enabled
VCUBE-1#debug ccsip info
SIP Call info tracing is enabled
VCUBE-1#debug ccsip message

4

アクティブなLGW、この場合はVCUBE-2で次のコマンドを実行して、フェイルオーバーをシミュレートします。


VCUBE-2#redundancy application reload group 1 self

アクティブからスタンバイLGWへの切り替えは、上記のCLI以外にも次のシナリオで発生します

  • アクティブルーターがリロードされたとき

  • アクティブルーターの電源が再投入されるとき

  • トラッキングが有効になっているアクティブルーターのRG設定インターフェイスがシャットダウンされたとき

5

Webex CallingVCUBE-1がアクセスSBCに登録されているかどうかを確認してください。 VCUBE-2は今頃リロードされているでしょう。


              VCUBE-1#show sip-ua register status

Tenant: 200
--------------------Registrar-Index  1 ---------------------
Line                           peer       expires(sec) reg survival P-Associ-URI
============================== ========== ============ === ======== ============
Hussain5091_LGU                -1          56          yes normal
VCUBE-1#

VCUBE-1は現在アクティブなLGWです。

6

Webex Calling仮想IP経由でSIPレジスタを送信し、200 OKを受信したVCUBE-1の関連するデバッグログを見てください。


VCUBE-1#show log

Jan 9 18:37:24.769: %RG_MEDIA-3-TIMEREXPIRED: RG id 1 Hello Time Expired.
Jan 9 18:37:24.771: %RG_PROTCOL-5-ROLECHANGE: RG id 1 role change from Standby to Active
Jan 9 18:37:24.783: %VOICE_HA-2-SWITCHOVER_IND: SWITCHOVER, from STANDBY_HOT to ACTIVE state.
Jan 9 18:37:24.783: //-1/xxxxxxxxxxxx/SIP/Info/info/4096/sip_ha_notify_active_role_event: Received notify active role event

Jan 9 18:37:25.758: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
REGISTER sip: 40462196.cisco-bcld.com:5061 SIP/2.0
Via: SIP/2.0/TLS 198.18.1.228:5061;branch=z9hG4bK0374
From: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189
To: <sip:Hussain5091_LGU@40462196.cisco-bcld.com>
Date: Thu, 09 Jan 2020 18:37:24 GMT
Call-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97
User-Agent: Cisco-SIPGateway/IOS-16.12.02
Max-Forwards: 70
Timestamp: 1578595044
CSeq: 2 REGISTER
Contact: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls>
Expires: 240
Supported: path
Content-Length: 0


Jan 9 18:37:25.995: //-1/000000000000/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 401 Unauthorized
Via: SIP/2.0/TLS 198.18.1.228:5061;received=173.38.218.1;branch=z9hG4bK0374;rport=4742
From: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189
To: <sip:Hussain5091_LGU@40462196.cisco-bcld.com>;tag=SD1u8bd99-1324701502-1578595045969
Date: Thu, 09 Jan 2020 18:37:24 GMT
Call-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97
Timestamp: 1578595044
CSeq: 2 REGISTER
WWW-Authenticate; DIGEST realm="BroadWorks",qop="auth",nonce="BroadWorksXk572qd01Ti58zliBW",algorithm=MD5
Content-Length: 0


Jan 9 18:37:26.000: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
REGISTER sip:40462196.cisco-bcld.com:5061 SIP/2.0
Via: SIP/2.0/TLS 198.18.1.228:5061;branch=z9hG4bK16DC
From: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189
To: <sip:Hussain5091_LGU@40462196.cisco-bcld.com>
Date: Thu, 09 Jan 2020 18:37:25 GMT
Call-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97
User-Agent:Cisco-SIPGateway/IOS-16.12.02
Max-Forwards: 70
Timestamp: 1578595045
CSeq: 3 REGISTER
Contact: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls>
Expires: 240
Supported: path
Authorization: Digest username="Hussain1076_LGU",realm="BroadWorks",uri="sips:40462196.cisco-bcld.com:5061",response="b6145274056437b9c07f7ecc08ebdb02",nonce="BroadWorksXk572qd01Ti58z1iBW",cnonce="3E0E2C4D",qop=auth,algorithm=MD5,nc=00000001
Content-Length: 0


Jan 9 18:37:26.190: //1/000000000000/SIP/Msg/ccsipDisplayMsg:

Received:
SIP/2.0 200 OK
Via: SIP/2.0/TLS 198.18.1.228:5061;received=173.38.218.1;branch=z9hG4bK16DC;rport=4742
From: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189
To: <sip:Hussain5091_LGU@40462196.cisco-bcld.com>;tag=SD1u8bd99-1897486570-1578595-46184
Call-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97
Timestamp: 1578595045
CSeq: 3 REGISTER
Contact: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls>;expires=120;q=0.5
Allow-Events: call-info,line-seize,dialog,message-summary,as-feature-event,x-broadworks-hoteling,x-broadworks-call-center-status,conference
Content-Length: 0

組織に合わせて Webex Calling を設定してください

初回設定ウィザードで通話設定をセットアップします

Webex Callingサービスを立ち上げて実行するための最初のステップは、初回セットアップウィザード（FTSW）を完了することです。 最初の場所でFTSWが完成したら、他の場所についても完了する必要はありません。

1

届いたウェルカムメールの「はじめに」リンクをクリックしてください。

管理者のメールアドレスは Control Hub へのサインインに自動的に使用され、そこで管理者パスワードを作成するように求められます。 サインインすると、セットアップウィザードが自動的に起動します。

2

利用規約を確認して同意してください。

3

プランを確認して、「始めよう」をクリックしてください。

アカウントマネージャーは、FTSWの最初のステップを有効にする責任があります。 「始めましょう」を選択したときに「電話を設定できません」という通知を受け取った場合は、アカウントマネージャーに連絡してください。

4

データセンターのマップ先の国を選択し、顧客の連絡先と顧客の住所情報を入力します。

5

次をクリックします:デフォルトの場所。

6

次のオプションから選択してください：

  • パートナー管理者で、顧客管理者にプロビジョニングを完了させたい場合は、「保存して閉じる」をクリックしてくださいWebex Calling。
  • 必要な位置情報を記入してください。 ウィザードで場所を作成したら、後でさらに場所を作成できます。

セットアップウィザードを完了したら、作成した場所に必ずメイン番号を追加してください。

7

この場所に適用するには、次の選択を行ってください。

  • アナウンス言語 — 音声アナウンスや、新規ユーザーや新機能のプロンプトに使用します。
  • メール言語 —新規ユーザーのメール通信用。
  • 国
  • タイムゾーン
8

「次へ」をクリックします。

9

Cisco Webex使用可能なSIPアドレスを入力し、[次へ] をクリックして [完了] を選択します。

場所を追加してください

始める前に

新しい場所を作成するには、次の情報を用意してください。

  • 所在地住所

  • 希望する電話番号（任意）

1

https://admin.webex.com でコントロールハブにログインし、[管理] > [場所] に移動します。

新しい場所は、 初回設定ウィザードを使用して選択した国に対応する地域のデータセンターにホストされます。

2

場所の設定をしてください：

  • 場所の名前—場所を識別できる一意の名前を入力してください。
  • 国/地域 —場所を結び付ける国を選択してください。 たとえば、米国に1つの場所（本社）を作成し、英国に別の場所（支店）を作成できます。 選択した国によって、その後に続く住所フィールドが決まります。 ここに記載されているものは、例として米国の住所規則を使用しています。
  • 所在地の住所 —その場所の主要な郵送先住所を入力します。
  • 市/町 —この場所の都市を入力してください。
  • 州/都道府県/地域 —ドロップダウンから州を選択します。
  • ZIP/郵便番号 — ZIPまたは郵便番号を入力してください。
  • アナウンス言語 — 新規ユーザーや新機能の音声アナウンスとプロンプトの言語を選択してください。
  • メール言語 — 新規ユーザーとのメール通信の言語を選択してください。
  • タイムゾーン — 場所のタイムゾーンを選択してください。
3

保存をクリックし、 はい/いいえを選択して、今すぐまたは後でその場所に番号を追加します。

4

「はい」 をクリックした場合は、 次のオプションのいずれかを選択してください。

  • Cisco PSTN —シスコのクラウド PSTN ソリューションを希望する場合は、このオプションを選択してください。 シスコ通話プランは、緊急通話、インバウンド、 アウトバウンドの国内/国際通話が可能な、 PSTNの完全な代替ソリューションです。 新しいPSTN番号を注文したり、既存の番号をシスコに移植したりできます。

    Cisco PSTNオプションは次の条件下でのみ表示されます。

  • クラウド接続 PSTN —多くのCisco CCPパートナーのクラウドPSTNソリューションを探している場合、 またはシスコ通話プランがお住まいの地域で利用できない場合は、このオプションを選択してください。 CCPパートナーは、 PSTNの代替ソリューションを提供し、世界中で幅広く対応し、幅広い機能、パッケージ、価格を提供しています。

    CCPパートナーと地域はこちらに記載されています。 お住まいの国をサポートするパートナーのみが表示されます。 パートナーは、 ロゴが付いているか、 括弧内に地域を記載した短い文字列で表示されます（例：（EU）、（US）、（CA））。 ロゴを付けて掲載されているパートナーは、常にCCP向けの地域メディアを提供しています。 文字列で表示されるパートナーの場合は、お住まいの国に最も近い地域を選択して、Regional Media for CCPを確認してください。

    掲載されているプロバイダーで今すぐ番号を注文するオプションが表示された場合は、 統合CCPのメリットを享受できるように、そのオプションを選択することをお勧めします。 統合されたCCPにより、 コントロールハブの電話番号の調達と提供を一元的に行うことができます。 統合されていない CCP では、Control Hub 以外の CCP パートナーから電話番号を入手する必要があります。

  • オンプレミスベースのPSTN（ローカルゲートウェイ）—現在のPSTNプロバイダーを維持したい場合や、 クラウド以外のサイトをクラウドサイトに接続したい場合は、 このオプションを選択できます。

PSTNオプションは各ロケーションレベルで選択できます（ 各ロケーションにはPSTNオプションは1つだけです）。 導入にはいくつでもオプションを組み合わせることができますが、各場所には1つの選択肢があります。 PSTNオプションを選択して設定したら、PSTNプロパティの場所にある「 管理」をクリックして変更できます。 ただし、Cisco PSTNなどの一部のオプションは、 別のオプションを割り当てると利用できなくなる場合があります。サポートケースを開いてガイダンスを求めてください。

5

番号を今すぐ有効にするか、後で有効にするかを選択してください。

6

統合されていないCCPまたは構内ベースのPSTNを選択した場合は、 電話番号をカンマで区切って入力し、「検証」をクリックします。

特定の場所に番号が追加されます。 有効なエントリは検証済み番号フィールドに移動し、 無効なエントリはエラーメッセージとともに番号の追加フィールドに残ります。

地域の国によっては、 番号は現地のダイヤル要件に従ってフォーマットされます。 たとえば、国コードが必要な場合は、 コードの有無にかかわらず数字を入力できます。コードの先頭にはコードが付きます。

7

[保存] をクリックします。

次にすべきこと

場所を作成したら、その場所で緊急911サービスを有効にできます。 詳細については、RedSky緊急911サービスを参照してください。Webex Calling

場所を削除する

始める前に

使用されていない場所や、それに関連するユーザーとワークスペースを削除した後に正しく設定されなかった場所を削除できます。 場所を削除すると、割り当てられているサービスと電話番号がすべて削除されます。

ある場所に関連付けられているユーザーとワークスペースのリストを取得します。「サービス」>「通話」>「番号」に移動し、ドロップダウンメニューから削除する場所を選択します。 場所を削除する前に、それらのユーザーとワークスペースを削除する必要があります。

この場所に関連付けられている番号はすべてPSTNプロバイダーに返されることに注意してください。あなたはそれらの番号を所有しなくなります。

1

https://admin.webex.com でコントロールハブにログインし、[管理] > [場所] に移動します。

2

クリック More Options button 削除したい場所の横の「アクション」列にあります。

3

[場所を削除] を選択し、その場所を削除することを確認します。

通常、場所を完全に削除するには数分かかりますが、最長で1時間かかることもあります。 More Options buttonロケーション名の横をクリックして [削除ステータス] を選択すると、ステータスを確認できます。

既存の場所を更新してください

場所の作成後に、PSTN設定、名前、タイムゾーン、言語を変更できます。 ただし、新しい言語は新しいユーザーとデバイスにのみ適用されることに注意してください。 既存のユーザーとデバイスは引き続き古い言語を使用します。

既存の場所では、緊急911サービスを有効にできます。 詳細については、RedSky緊急911サービスを参照してください。Webex Calling

1

コントロールハブにサインインしてください。

2

[管理] > [場所] に移動します。

場所の横に注意マークが表示されている場合は、 その場所の電話番号をまだ設定していないということです。 その番号を設定するまで、 電話をかけたり受けたりすることはできません。

3

（オプション）PSTN接続で、設定済みのものに応じて、 クラウド接続PSTNまたはプレミスベースのPSTN（ローカルゲートウェイ）のいずれかを選択します。 [管理] をクリックして設定を変更し、関連するリスクを確認して [ 続行] を選択してください。 次に、 次のオプションのいずれかを選択して、[保存] をクリックします。

  • Cisco PSTN —シスコのクラウド PSTN ソリューションを希望する場合は、このオプションを選択してください。 シスコ通話プランは、緊急通話、インバウンド、 アウトバウンドの国内/国際通話が可能な、 PSTNの完全な代替ソリューションです。 新しいPSTN番号を注文したり、既存の番号をシスコに移植したりできます。

    Cisco PSTNオプションは次の条件下でのみ表示されます。

  • クラウド接続 PSTN —多くのCisco CCPパートナーのクラウドPSTNソリューションを探している場合、 またはシスコ通話プランがお住まいの地域で利用できない場合は、このオプションを選択してください。 CCPパートナーは、 PSTNの代替ソリューションを提供し、世界中で幅広く対応し、幅広い機能、パッケージ、価格を提供しています。

    CCPパートナーと地域はこちらに記載されています。 お住まいの国をサポートするパートナーのみが表示されます。 パートナーは、 ロゴが付いているか、 短い文字列の後に地域を括弧で囲んで記載されています（例：（EU）、（米国）、（CA））。 ロゴを付けて掲載されているパートナーは、常にCCP向けの地域メディアを提供しています。 文字列で表示されるパートナーの場合は、お住まいの国に最も近い地域を選択して、Regional Media for CCPを確認してください。

    掲載されているプロバイダーで今すぐ番号を注文するオプションが表示された場合は、 統合CCPのメリットを享受できるように、そのオプションを選択することをお勧めします。 統合されたCCPにより、 コントロールハブの電話番号の調達と提供を一元的に行うことができます。 統合されていない CCP では、Control Hub 以外の CCP パートナーから電話番号を入手する必要があります。

  • オンプレミスベースのPSTN（ローカルゲートウェイ）—現在のPSTNプロバイダーを維持したい場合や、 非クラウドサイトをクラウドサイトに接続したい場合は、 このオプションを選択できます。

    Webex Calling 以前にローカルゲートウェイで設定されているロケーションのお客様は、 対応するトランクを備えたプレミスベースのPSTNに自動的に変換されます。

移行するには、以下の「シスコ通話プランへの移行」を参照してください。

4

場所については、 ドロップダウンリストからメインナンバーを選択してください。

メインの番号は、 オートアテンダントやその場所内の他の宛先に割り当てることができるので、外部からの発信者は適切な宛先にルーティングされます。

トランクや、ユーザー、ワークスペース、 仮想回線、機能などの内線専用エンティティがある場合は、その場所にメイン番号を割り当てる必要があります。 メインの番号がないと、 トランクは使用できず、内線番号のみの事業体は内部または外部への通話を発信または受信できません。 その地域のユーザーは、PSTN電話をかけるときに、 この番号を外部の発信者IDとして使用することもできます。

ある場所のメイン番号としてフリーダイヤル番号を選択した場合、 その場所の緊急コールバック番号を更新することをお勧めします。 フリーダイヤル番号には緊急サービスの住所がありません。 詳細については、「 ロケーションの緊急コールバック番号を設定する」を参照してください。

5

（オプション）「緊急通話」で、この場所に割り当てる緊急時位置識別子を選択できます。

この設定はオプションで、必要な国にのみ適用されます。

一部の国（例：フランス）では、セルラー無線システムが、緊急通報をかけ、緊急通報時に携帯電話の身元を確認するための規制要件があります。 米国やカナダなどの他の国では、他の方法で位置決定を実施しています。 詳細については、「拡張緊急通話」を参照してください。

緊急通報プロバイダーがアクセスネットワークに関する情報を必要とする場合がありますが、そのためには、 新しいプライベートSIP拡張ヘッダー、P-Access-Network-Infoを定義します。 ヘッダーには、 アクセスネットワークに関する情報が含まれています。

ロケーションに緊急ロケーション識別子を設定すると、ロケーション値がSIPメッセージの一部としてプロバイダーに送信されます。 緊急電話プロバイダーに連絡して、この設定が必要かどうかを確認し、緊急電話プロバイダーが提供する値を使用してください。」

6

ユーザーがこの場所のボイスメールを確認するために電話できるボイスメール番号を選択してください。

7

（オプション）ロケーションページの上部にある鉛筆アイコンをクリックして、必要に応じてロケーション名、アナウンスの言語、メールの言語、タイムゾーン、またはアドレスを変更し、保存をクリックします。

アナウンス言語の変更は、この場所に新しいユーザーや機能を追加するとすぐに有効になります。 既存のユーザーや機能のアナウンス言語も変更する必要がある場合は、メッセージが表示されたら、「既存のユーザーとワークスペースについては変更する」または「既存の機能の場合は 「変更」を選択します。 「適用」をクリックします。 進捗状況はタスクページで見ることができます。 これが完了するまで、これ以上変更することはできません。

ある場所のタイムゾーンを変更しても、 その場所に関連する機能のタイムゾーンは更新されません。 自動応答、ハントグループ、 コールキューなどの機能のタイムゾーンを編集するには、タイムゾーンを更新したい特定の機能の一般設定エリアに行き、 そこで編集して保存してください。

シスコの通話プランに移行してください

既存の場所の PSTN 接続を Cisco PSTN に変更できます。 たとえば、 構内ベースのPSTN（ローカルゲートウェイ） または統合されていないCCP接続の場所をCisco PSTNに変更できます。 Cisco PSTNはシスコのクラウドPSTNソリューションを提供します。

予定されている移植完了時間中のわずかな中断を除いて、すべての携帯番号は引き続き機能します。

また、 PSTN接続移行中のロケーションでは、番号管理を変更することはできません。 ただし、既存の番号は引き続き機能し、 その場所に番号を割り当てたり割り当てを解除したりできます。 その場所の番号を追加、削除、移動することはできません。 このプロセス中に、ルーティングプロファイルが自動的に更新され、 Cisco PSTNが有効になります。

現在、既存のロケーションのPSTN接続をCisco PSTNに変更する機能は、日本地域ではサポートされていません。

PSTN接続を変更すると、通話ライセンス付きのサブスクリプションが適用され、 請求サービスに通知が届きます。

制限事項:

  • 統合されたIntelPeerロケーションからCiscoPSTNロケーションへの移行はサポートされていません

  • 専用インスタンスの場所は Cisco PSTN に移行できません

  • PSTN接続の変更には、複数のポートオーダーが必要になる場合があります。 もしそうなら、 これらの注文はリンクされているので、同時に完了します。 日付の変更または1つのポートオーダーのキャンセルは、 接続を変更するすべてのポートオーダーに適用する必要があります。

PSTN接続の変更を開始する方法

1

コントロールハブにサインインしてください。

2

[管理] > [場所] に移動します。

3

PSTN接続をCisco PSTNに変更したい場所を選択してください。

4

「通話」タブに行き、 構内ベースのPSTNまたは統合されていないクラウド接続PSTNの横にある「 管理」オプションをクリックします。

5

接続タイプの横で編集してください。

6

シスコ通話プランカードを選択し、 その場所のユーザーにシスコ通話プランを割り当てるサブスクリプションを選択してください。 「次へ」をクリックします。

7

確認のための接続変更ページが表示されます。 「次へ」をクリックして 、番号のポート準備状況を確認してください。

PSTN Connection port wizard check if your numbers are ready to be ported page.

「次へ」ボタンは、リスト内のすべての数字がポータブルである場合にのみ有効になります。 これらの指針を読んでください：

  • 「ポータブルではない番号」は使われていない番号を指します。このリストに番号がないことを確認してください。

  • ポータブルでない番号はすべてその場所から削除してください。 番号を移動または割り当て解除してから削除できます。

8

[次へ] をクリックして、契約情報を入力します。

PSTN Connection port wizard emergency service address page.

これは、 Cisco通話プランを利用しているすべての場所（米国）の主要な契約連絡先です。 この連絡先への変更は、 シスコ通話プランを利用している他のすべての場所（米国）にも適用されます。

9

「次へ」をクリックします。 その場所の契約情報を保存するかどうかを確認する通知が表示されます。 「はい、変更してください」を選択してください。

10

緊急サービスの住所を入力して [保存] をクリックしてください。

PSTN Connection port wizard emergency service address page.

緊急時には、 地域の緊急対応チームがこの住所を使用して発信者を見つけます。

11

概要ページには、作成されたポートの数が表示されます。 注文が1つしかない場合は、「 追加情報を入力する」という追加のステップが表示されます。 複数の注文の場合は、 上部に注文セレクターがあり、注文間を移動できます。 「次へ」をクリックし、 詳細を入力してポートウィザードを完了します。

PSTN Connection port wizard summary page.

1回のPSTN移行リクエストですべての情報が提供されると、注文は一度に送信されます。 デフォルトでは、 確定注文の確約日はすべての注文で同じです。 PSTN接続の変更は、 最後にリンクされた注文が完全に移植された後に自動的に適用されます。

  • 注文の送信に失敗すると、サポートチケットが自動的に作成され、 サポートチームに送信されます。

  • PSTN接続の変更で複数の通信事業者からの複数の注文が必要な場合は、 完了するまでに最大10営業日かかることがあります。

移行の詳細は、「サービス」>「通話」>「PSTN」>「注文」タブにあります。 注文IDを選択すると、注文の詳細がサイドパネルに表示されます。 PSTN接続変更から作成されたオーダーのタイプは「PSTNの変更」と表示されます。

PSTN接続の変更をキャンセルしてください

場所がまだ移行中の場合、管理者はPSTNの移行をキャンセルできます。

1

コントロールハブにサインインしてください。

2

[管理] > [場所] に移動します。

3

PSTN接続をキャンセルする場所を選択してください。

4

「通話」タブに行き、 PSTN接続の変更をキャンセルするボタンをクリックしてください。

5

「はい」をクリックして、キャンセルの確認を続けてください。

Webex Callingダイヤルプランを設定します

アウトバウンドダイヤルコードを使用して、Webex Calling導入環境のダイヤルプランを制御できます。 ユーザーのダイヤル習慣に合わせて、内線番号、ルーティングプレフィックス、ダイヤル設定（内部と外部）をカスタマイズします。

これらの設定は内線ダイヤル用で、初めてのセットアップウィザードでも使用できます。 ダイヤルプランを変更すると、コントロールハブのサンプル番号が更新されてこれらの変更が表示されます。

ある場所の発信許可を設定できます。 発信権限を設定するには、次の手順を参照してください。

1

Control Hubにログインし、「サービス」>「通話」>「サービス設定」 に移動して、「内線通話」までスクロールします。

2

必要に応じて、次のオプションのダイヤル設定を設定します。

  • ロケーションルーティングプレフィックス長 —複数のロケーションがある場合は、この設定をお勧めします。 1～7桁の長さを入力できます。 同じ内線番号の複数の場所がある場合、ユーザーは場所間で電話をかけるときにプレフィックスをダイヤルする必要があります。 たとえば、複数の店舗があり、すべてに拡張子1000が付いている場合は、店舗ごとにルーティングプレフィックスを設定できます。 ある店舗のプレフィックスが888の場合、8881000をダイヤルしてその店舗に連絡します。

    • ルーティングプレフィックスの長さにはステアリングディジットが含まれます。 たとえば、ルーティングプレフィックスの長さを4に設定した場合、サイトを指定するのに使用できるのは3桁だけです。

    • ある場所にルーティングプレフィックスを割り当てると、その場所に割り当てられたすべての内線番号の前にルーティングプレフィックスが付きます。 たとえば、888-1000（ルーティングプレフィックス-拡張）。

  • ルーティングプレフィックスのステアリングディジット —すべてのルーティングプレフィックスの最初の桁として設定する番号を選択してください。
  • 内線番号の長さ —2〜10桁を入力できます。デフォルトは2です。

    内線番号の長さを増やしても、内部内線番号への既存のスピードダイヤルは自動的に更新されません。

  • ロケーション間の内線ダイヤルを許可-組織の要件に基づいて、ロケーション間の内線ダイヤルをカスタマイズできます。

    • 組織のすべての場所で重複する内線番号がない場合は、トグルを有効にしてください。

      デフォルトでは、トグルは有効になっています。

    • 組織の異なる場所に同じ拡張子がある場合は、トグルを無効にしてください。 トグルが無効で、発信者が内線番号をダイヤルすると、通話は発信者と同じ場所にいる一致する内線番号を持つユーザーにルーティングされます。 他の場所の内線に電話をかけるには、発信者は企業の重要番号（ロケーションルーティングプレフィックス+内線番号）をダイヤルする必要があります。

3

特定の場所の内部ダイヤルを指定してください。 [管理] > [場所] に移動し、リストから場所を選択して、[通話] をクリックします。 「ダイヤリング」までスクロールし、必要に応じて内線ダイヤルを変更してください：

  • 内部ダイヤル — ある場所のユーザーが別の場所にいる人に連絡するときにダイヤルする必要があるルーティングプレフィックスを指定します。 各場所のルーティングプレフィックスは一意でなければなりません。 プレフィックスの長さは組織レベルで設定された長さと同じにすることをお勧めしますが、長さは1〜7桁でなければなりません。
4

特定の場所への外部ダイヤルを指定してください。 [管理] > [場所] に移動し、リストから場所を選択して、[通話] をクリックします。 「ダイヤリング」までスクロールし、必要に応じて外部ダイヤルを変更してください：

  • 外部ダイヤル —ユーザーが外部回線に接続するためにダイヤルする必要がある発信ダイヤル番号を選択できます。 デフォルトは「なし」です。このダイヤル習慣が必要ない場合は、そのままにしておくことができます。 この機能を使用する場合は、組織のステアリングディジットとは別の番号を使用することをお勧めします。

    ユーザーは、レガシーシステムでのダイヤル方法を模倣して、外部電話をかけるときに発信ダイヤル番号を含めることができます。 ただし、すべてのユーザーは、発信ダイヤル番号がなくても外部電話をかけることができます。

  • オプションで、この場所の発信番号を強制的にダイヤルして、ユーザーが外部電話をかけるときに管理者が設定した発信ダイヤル番号を使用する必要があります。

    • この機能を有効にすると、発信番号の有無にかかわらず緊急通報をダイヤルできます。 いったん有効にすると、発信ダイヤル番号が含まれていないと、 着信転送に使用されるような外部の宛先番号は機能しなくなります。

    • 内線番号が国内番号と同じ場合は、内線番号が国内番号よりも優先されます。 そのため、発信ダイヤルディジットを有効にすることをお勧めします。

    • PSTN通話の着信と発信には、E.164番号形式を使用することを強くお勧めします。

ユーザーへの影響:

  • ダイヤル設定の変更を有効にするには、ユーザーは電話を再起動する必要があります。

  • ユーザー内線番号は、その場所のステアリングディジットまたはアウトバウンドダイヤルディジットと同じ番号で始まってはいけません。

コントロールハブでオンプレミスベースのPSTN（ローカルゲートウェイ）を設定します

付加価値再販業者の場合は、以下の手順でControl Hubでローカルゲートウェイの設定を開始できます。 このゲートウェイをクラウドに登録すると、Webex Calling 1つまたは複数の場所で使用して、企業のPSTNサービスプロバイダーへのルーティングを提供できます。

ローカルゲートウェイのある場所は、そのローカルゲートウェイが他の場所で使用されている場合は削除できません。

トランクを作ってください

コントロールハブでトランクを作成するには、次の手順に従ってください。

始める前に

  • 場所を追加したら、その場所にオンプレミスベースのPSTNを設定する前に、トランクを作成する必要があります。

  • 任意の場所を作成し、それぞれに特定の設定と番号を設定します。 構内ベースのPSTNを追加する前に、場所が存在している必要があります。

  • のプレミスベースのPSTN（ローカルゲートウェイ）要件を理解してください。Webex Calling

  • 構内ベースのPSTNを使用する場所では複数のトランクを選択できませんが、複数の場所で同じトランクを選択することはできます。

1

https://admin.webex.com でコントロールハブにログインし、[サービス] > [通話] > [通話ルーティング] に移動して、[トランクの追加] を選択します。

2

場所を選択してください。

3

トランクに名前を付け、[保存] をクリックします。

名前は24文字を超えてはいけません。

次にすべきこと

トランクで設定する必要のある関連パラメータが表示されます。 また、PSTN接続を保護するためのSIPダイジェスト認証情報のセットも生成します。

トランク情報は、ドメイン、トランクグループ、OTG/DTG、回線/ポート、およびアウトバウンドプロキシアドレスの登録画面に表示されます。

この情報をコントロールハブからコピーして、ローカルのテキストファイルまたは文書に貼り付けることをお勧めします。そうすれば、オンプレミスベースのPSTNを設定する準備ができたときに参照できます。

認証情報を紛失した場合は、Control Hubのトランク情報画面から生成する必要があります。 「ユーザー名の取得」と「パスワードをリセット」をクリックして、トランクで使用する新しい認証資格情報を生成します。

構内ベースのPSTNのトランクを選択してください

1

https://admin.webex.com でコントロールハブにログインし、[管理] > [場所] に移動します。

2

変更する場所を選択し、「管理」をクリックします。

3

オンプレミスベースのPSTNを選択し、次へをクリックします。

4

ドロップダウンメニューからトランクを選んでください。

トランクグループの選択を管理するには、トランクのページにアクセスしてください。

5

確認通知をクリックして、[保存] をクリックします。

次にすべきこと

Control Hubが生成した設定情報を取得し、パラメータをローカルゲートウェイ（たとえば、構内に設置されているCisco CUBE）にマッピングする必要があります。この記事では、そのプロセスを順を追って説明します。 参考までに、コントロールハブの構成情報（左）がCUBE（右）のパラメーターにどのようにマッピングされるかの例については、次の図を参照してください。

Diagram example of a local gateway.

ゲートウェイ自体の設定が正常に完了したら、Control Hubの [サービス] > [通話] > [場所] に戻ることができます。作成したゲートウェイは、割り当てたロケーションカードに、名前の左に緑色の点が付いた状態で表示されます。 このステータスは、ゲートウェイがコーリングクラウドに安全に登録され、そのロケーションのアクティブなPSTNゲートウェイとして機能していることを示しています。

電話番号を管理します

コントロールハブでは、組織の電話番号を簡単に表示、有効化、削除、追加できます。 詳細については、「Control Hub での電話番号の管理」を参照してください。

コントロールハブの試用版から Webex サービスの購入をリクエストしてください

Webex サービスを試していて、トライアルを有料サブスクリプションに切り替えたい場合は、パートナーにメールでリクエストを送信できます。

1

https://admin.webex.com でコントロールハブにログインし、建物のアイコンを選択します Building icon..

2

「購読」タブを選択し、「今すぐ購入」をクリックします。

有料プランへの切り替えに関心があることを知らせるメールがパートナーに送信されます。

通話オプションを設定する

コントロールハブを使用して、Webex アプリでユーザーに表示される利用可能な通話オプションの優先順位を設定できます。 また、シングルクリックで通話できるようにすることもできます。 詳細については、「Webex アプリユーザーの通話オプションの設定」を参照してください。

通話動作を設定する

ユーザーが電話をかけたときにどの通話アプリケーションが開くかを制御できます。 通話クライアントの設定を行うことができます。これには、Webex Callingシスコの有料通話サービスを利用できるユーザーと、Unified CMそうでないユーザーがいる組織の混合モード展開が含まれます。 詳細については、「通話動作を設定する」を参照してください。

Unified CM を Webex Calling に設定してください

トランクからローカルゲートウェイへのSIPトランクのセキュリティプロファイルを設定してください

ローカルゲートウェイとPSTNゲートウェイが同じデバイス上にある場合は、同じデバイスから発信される2つの異なるトラフィックタイプ（WebexとPSTNからのコール）を区別し、Unified CMこれらのコールタイプに異なるサービスクラスを適用できるようにする必要があります。 この差別化された通話処理は、Unified CMローカルゲートウェイとPSTNゲートウェイデバイスの間に2つのトランクをプロビジョニングすることで実現されます。この2つのトランクには異なるSIPリスニングポートが必要です。

次の設定で、ローカルゲートウェイトランク専用のSIPトランクセキュリティプロファイルを作成します。

設定価値
名前Webexなどのユニークな名前
説明Webex SIPトランクセキュリティプロファイルなど、わかりやすい説明
受信ポートWebex: 5065との間のトラフィックには、ローカルゲートウェイ設定で使用されているポートと一致する必要があります

ローカルゲートウェイトランクのSIPプロファイルを設定してください

次の設定で、ローカルゲートウェイトランク専用のSIPプロファイルを作成します。

設定価値
名前Webexなどのユニークな名前
説明Webex SIPプロファイルなど、わかりやすい説明
OPTIONS Pingを有効にして、サービスタイプが「なし（デフォルト）」のトランクの宛先ステータスを監視しますチェックしました

Webex からの通話用のコーリングサーチスペースを作成してください

次の設定で、Webex から発信される通話用のコーリングサーチスペースを作成します。

設定価値
名前Webexなどのユニークな名前
説明Webex Calling検索スペースなど、わかりやすい説明
選択したパーティション

DN（+E.164ディレクトリ番号）

ESN（サイト間短縮ダイヤリング）

PSTNインターナショナル（PSTNアクセス）

オンネットリモート（GDPRが学習した宛先）

OnNetRemoteの最後のパーティションは、Intercluster Lookup Service（ILS）またはグローバルダイヤルプランレプリケーション（GDPR）Unified CMを使用してクラスター間でルーティング情報が交換されるマルチクラスター環境でのみ使用されます。

Webexとの間で送受信するSIPトランクを設定します

次の設定で、ローカルゲートウェイ経由のWebexへの通話とWebexからの通話用のSIPトランクを作成します。

設定価値
デバイス情報
デバイス名Webexのようなユニークな名前
説明Webex SIPトランクなどのわかりやすい説明
Unified CMすべてのアクティブなノードで実行チェックしました
インバウンドコール
コーリングサーチスペース以前に定義したコーリングサーチスペース：Webex
AAR コーリングサーチスペース PSTNルートパターンにのみアクセスできるコーリングサーチスペース：PSTNReRoute
SIP情報
送付先住所ローカルゲートウェイ CUBE の IP アドレス
送信先ポート5060
SIPトランクのセキュリティプロファイル以前に定義しました：Webex
SIPプロフィール以前に定義しました：Webex

Webex のルートグループを設定してください

次の設定でルートグループを作成します。

設定価値
ルートグループ情報
ルートグループ名Webexのようなユニークな名前
選択したデバイス以前に設定したSIPトランク：Webex

Webex のルートリストを設定してください

次の設定でルートリストを作成します。

設定価値
ルートリスト情報
名前ユニークな名前、例えば RL_Webex
説明Webexのルートリストなど、わかりやすい説明
Unified CMすべてのアクティブなノードで実行チェックしました
ルートリスト会員情報
選択したグループ以前に定義したルートグループのみ：Webex

Webex 送信先用のパーティションを作成してください

次の設定で Webex 宛先のパーティションを作成します。

設定価値
ルートリスト情報
名前Webexなどのユニークな名前
説明Webexパーティションなど、わかりやすい説明

次にすべきこと

Webex 宛先にアクセスできるはずのすべてのコーリングサーチスペースにこのパーティションを追加してください。 このパーティションは、PSTNトランクのインバウンドコーリングサーチスペースとして使用されるコーリングサーチスペース専用に追加して、PSTNからWebexへのコールをルーティングできるようにする必要があります。

Webex 宛先のルートパターンを設定してください

次の設定で、Webex の DID 範囲ごとにルートパターンを設定します。

設定価値
ルートパターンWebexのDID範囲のフル+E.164パターンで、先頭に「\」が付いています。 例えば:\ +140855501XX
ルートパーティションWebex
ゲートウェイ/ルートリストRL_Webex
緊急優先事項チェックしました

Webexの短縮サイト間ダイヤリング正規化を設定してください

Webexにサイト間短縮ダイヤルが必要な場合は、次の設定でWebexの各ESN範囲のダイヤル正規化パターンを設定します。

設定価値
翻訳パターンウェベックスのESNレンジのESNパターン。 例えば:80121XX
パーティションWebex
説明Webex 正規化パターンなど、わかりやすい説明
発信者のコーリングサーチスペースを使用してくださいチェックしました
緊急優先事項チェックしました
後続ホップの桁間タイムアウトを待たないでくださいチェックしました
着信側トランスフォーメーションマスク数値を+E.164に正規化するためのマスク。 例えば:+ 140855501XX

Webex Calling 機能をセットアップしてください

ハントグループを設定してください

ハントグループは、着信通話をユーザーグループまたはワークスペースにルーティングします。 グループ全体にルーティングするようにパターンを設定することもできます。

ハントグループの設定方法の詳細については、の「ハントグループ」を参照してください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

コントロールハブにサインインしてください。

2

[管理] > [ユーザー] に移動します。

3

ユーザーを選択して、「通話」をクリックしてください。

4

「ユーザー間の権限」セクションに行き、「割り込み」を選択してください。

5

トグルをオンにして、他のユーザーがこのユーザーの進行中の通話に自分自身を追加できるようにします。

6

このユーザーが通話に割り込んだときに他のユーザーに音を鳴らしたい場合は、「このユーザーが通話に参加したときに音を鳴らす」をチェックしてください。

「このユーザーが電話に出たら音を鳴らす」設定は、 カスタマーエクスペリエンスベーシックとエッセンシャルスーパーバイザーの割り込み機能には適用されません。 スーパーバイザーに対してこのオプションを有効にしても、 スーパーバイザーがコールキューコールに割り込んできても、 システムはエージェントに通知トーンを鳴らしません。

上司が電話に出てきたときにエージェントにトーンを鳴らしたい場合は、「エージェントへの通知トーン」 設定で有効にできます。 詳細については、 「Webex カスタマーエクスペリエンスベーシック」または「Webex カスタマーエクスペリエンスエッセンシャル」の「キューの作成」セクションを参照してください。

7

[保存] をクリックします。

ユーザーのプライバシーを有効にする

1

Control Hub にサインインして、[管理] > [ユーザー] に移動します。

2

ユーザーを選択して「通話」をクリックしてください。

3

「ユーザー間の権限」エリアに行き、「プライバシー」を選択してください。

4

このユーザーに適切な自動応答のプライバシー設定を選択してください。

  • このユーザーに内線番号でダイヤルすることを許可します
  • このユーザーに苗字または苗字でダイヤルすることを許可します
5

プライバシーを有効にするチェックボックスをチェックしてください。 次に、ドロップダウンリストからメンバーを選択しないで、全員をブロックすることもできます。 または、このユーザーの回線ステータスを監視できるユーザー、ワークスペース、仮想回線を選択することもできます。

ロケーション管理者の場合は、割り当てられたロケーションに関連するユーザー、ワークスペース、バーチャルラインだけがドロップダウンリストに表示されます。

プライバシーを有効にするチェックボックスをオフにして、誰もが回線の状態を監視できるようにします。

6

ダイレクトコールピックアップと割り込みのプライバシーを有効にするには、「ダイレクトコールピックアップと割り込みにプライバシーを適用する」チェックボックスをオンにしてください。

  • このオプションを有効にすると、許可されたユーザー、仮想回線、およびワークスペースデバイスのみが、このユーザーのダイレクトコールピックアップとバージインを使用できます。 それ以外の場合は、組織内の誰でも回線のダイレクトコールピックアップとバージインを呼び出すことができます。
  • 割り込みについて詳しくは、「他人の電話への割り込み」を参照してください。
  • スーパーバイザーは、エージェントがコールキューから受信した電話にいつでも割り込みできます。 つまり、プライバシー設定は上司の割り込みオプションには影響しません。

7

「名前でメンバーを追加」から、電話回線のステータスを監視し、ダイレクトコールピックアップとバージインを起動できるユーザー、ワークスペース、仮想回線を選択します。

8

選択したメンバーをフィルタリングするには、名前、番号、またはテキストフィールドでフィルターします。

9

選択したメンバーをすべて削除するには、[すべて削除] をクリックします。

個々のメンバーを削除するには、メンバー名の横にある [削除] をクリックします。

10

[保存] をクリックします。

Privacy settings

監視を設定する

ユーザーが監視する回線の最大数は50です。 ただし、監視リストを設定するときは、Webex Callingとネットワーク間の帯域幅に影響するメッセージの数を考慮してください。 また、監視対象回線の最大数は、ユーザーの電話機の回線ボタンの数で決まります。

1

https://admin.webex.com のカスタマービューから、[管理] に移動し、[ユーザー] をクリックします。

2

変更したいユーザーを選択し、「通話中」をクリックします。

3

ユーザー間権限セクションに行き、監視を選択してください。

4

次の中から選択してください:

  • 監視対象回線を追加してください
  • コールパークエクステンションを追加してください

ユーザー監視用に、監視対象回線の追加リストに仮想回線を含めることができます。

5

このユーザーにパークコールについて通知するかどうかを選択し、監視対象の人物またはコールパークの内線番号を検索して、[保存] をクリックします。

Control Hubの監視対象回線リストは、ユーザーのデバイスに表示される監視対象回線の順序に対応しています。 監視対象回線のリストはいつでも並べ替えることができます。

監視対象回線に表示される名前は、ユーザー、ワークスペース、仮想回線の発信者番号の名と苗字フィールドに入力された名前です。

それがどのように行われるか見たいですか？ Control Hubでユーザーの監視設定を管理する方法についてのこのビデオデモンストレーションを見てください。

ユーザーに対してコールブリッジの警告音を有効にする

始める前に

コールブリッジを呼び出すには、共有回線を設定する必要があります。 コールブリッジの警告トーンを再生する前に、共有回線の設定方法をご覧ください。
1

Control Hub にサインインして、[管理] > [ユーザー] に移動します。

2

ユーザーを選択し、「通話」タブをクリックします。

3

「ユーザー間権限」に移動し、「コールブリッジ警告音」をクリックします。

4

コールブリッジ警告音をオンにして、保存をクリックしてください。

デフォルトでは、この機能は有効になっています。

MPP共有回線のコールブリッジについて詳しくは、「マルチプラットフォームの固定電話の共有回線」を参照してください。

Webex App共有回線のコールブリッジングの詳細については、「WebexAppの共有回線アピアランス」を参照してください。

ユーザーのホテルサービスを有効にする

ユーザーのホテル機能を有効にすると、 メインのデスクフォンの機能や特徴を維持したまま、 ホスト電話を使用できます。

1

コントロールハブにサインインしてください。

2

[管理] > [ユーザー] に移動します。

3

ユーザーを選択し、「通話」タブをクリックします。

4

「ユーザー間権限 」セクションに行き、「Hoteling」を選択して、トグルをオンにしてください。

5

ホテルロケーションの検索フィールドにホテルホストの名前または番号を入力し、 ユーザーに割り当てたいホテルホストを選択します。

ホテルのホストは1つしか選択できません。 別のホテルホストを選択すると、 最初のホテルホストが削除されます。

ロケーション管理者の場合は、 割り当てられたロケーションに関連するホテルホストのみを割り当てることができます。

6

「制限アソシエーション期間」 ドロップダウンから、ユーザーがホテルホストを使用できる時間数を選択します。

電話は、 選択した時間が経過すると自動的にユーザーをログアウトします。

ユーザーに指定された制限関連付け期間が、 選択したホテルホストの制限関連付け期間を超えると、エラーメッセージが画面に表示されます。 たとえば、 ホテルホストの制限関連付け期間が12時間で、 ユーザーの制限関連付け期間が24時間の場合、 エラーメッセージが表示されます。 このような場合、ユーザーがさらに時間を必要とする場合は、 ホテルホストの制限関連付け期間を延長する必要があります。

7

[保存] をクリックします。

ユーザーは、ユーザーハブから、 使用したいホテルホストを検索して見つけることもできます。 詳しくは、「 どこからでも通話プロフィールにアクセスする」を参照してください。

それがどのように行われるか見たいですか？ コントロールハブでホテルを設定する方法については、このビデオデモンストレーションをご覧ください。

Webex Calling の採用動向と使用状況レポート

通話レポートを見る

Control Hub の Analytics ページを使用して、Webex Callingサービスの利用状況、Webex アプリでのエンゲージメント、通話メディアエクスペリエンスの質を確認できます。 Webex Callingアナリティクスにアクセスするには:

1

コントロールハブにサインインしてください。

2

アナリティクスに行き、 通話タブを選択してください。

3

詳細な通話履歴を選択してください。

通話履歴の詳細は、メディア品質データとともに表示されます。
4

メディア品質データにアクセスするには、Control Hubにログインして、Analyticsに行き、「通話」を選択してください。

関連情報
環境を準備する

一般的な前提条件

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 注文ガイドのローカル ゲートウェイの表 1 を参照してください。 また、ローカル ゲートウェイ設定ガイドに従って、プラットフォームがサポートされている IOS-XE リリースを実行していることを確認してください。

ローカル ゲートウェイは、自分のペースで 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

次のオプションから選択します:

  • パートナー管理者の場合は、[保存して閉じる] をクリックして、顧客管理者が Webex Calling のプロビジョニングを完了するようにします。
  • 必要なロケーションの情報を入力します。 ウィザードでロケーションを作成した後、後で他にロケーションを作成できます。

 

セットアップ ウィザードを完了した後で、作成したロケーションにメイン番号を追加していることを確認してください。

7

このロケーションに適用する次の選択を行います。

  • 通知言語 - 新しいユーザーと機能に関する音声通知とプロンプト用。
  • メール言語 - 新規ユーザー向けメールのコミュニケーション。
  • 国
  • タイムゾーン
8

[次へ] をクリックします。

9

利用可能な Cisco Webex SIP アドレスを入力し、[次へ] をクリックし、[完了] を選択します。

ロケーションを追加する

始める前に

新しいロケーションを作成するには、以下の情報を指定します。

  • ロケーションの住所

  • 希望する電話番号(オプション)

1

以下で Control Hub にログインします:https://admin.webex.com 、管理次のリンクをクリックしてください:ロケーションを選択します。


 
新しいロケーションは、初回セットアップウィザードを使用して選択した国に対応する地域データセンターでホストされます。
2

ロケーションを設定します。

  • ロケーション名 - ロケーションを識別するための一意の名前を入力します。
  • 国/地域 - ロケーションに関連付ける国を選択します。 たとえば、米国に 1 か所のロケーション (本社) を作成し、イギリスに別のロケーション (支社) を作成することができます。 選択した国に応じて、その後の住所のフィールドが決まります。 ここには、例として、米国の住所書式を使用したものがあります。
  • ロケーションの住所 - ロケーションの郵送先住所の主要部分を入力します。
  • 市区町村 - このロケーションが所在する市区町村を入力します。
  • 都道府県 - ドロップダウンから都道府県を選択します。
  • 郵便番号-ZIP または郵便番号を入力します。
  • 通知言語 - 新規ユーザーと機能に関する音声通知と音声プロンプトで使用する言語を選択します。
  • メール言語 - 新規ユーザーとのメール通信に使用する言語を選択します。
  • タイムゾーン - ロケーションのタイム ゾーンを選択します。
3

クリック保存を選択してはい/いいえをクリックし、今すぐまたは後でロケーションに番号を追加します。

4

[今すぐ追加] をクリックしたら、次のいずれかのオプションを選択してください。

  • Cisco PSTN - Cisco の Cloud PSTN ソリューションが必要な場合は、このオプションを選択します。 Cisco Calling プランは、緊急通話、国内および国際電話の着信および発信を提供する完全な PSTN 代替ソリューションであり、新しい PSTN 番号を注文したり、既存の番号を Cisco にポートしたりできます。


     

    Cisco PSTN オプションは、以下の条件でのみ表示されます。

    • コミットされた Cisco Calling プラン OCP (アウトバウンド通話プラン) を少なくとも 1 つ購入している。

    • Cisco Calling プランがサポートされている国にロケーションがある。

    • ロケーションが新規である。 他の PSTN 機能が割り当てられている既存のロケーションは、今回は Cisco Calling プランの対象外です。 サポート ケースを開いてご相談ください。

    • Cisco Calling プランがサポートされている地域のWebex Callingデータ センターでホストされています。

  • Cloud Connected PSTN - 多くの Cisco CCP パートナーの 1 つからクラウド PSTN ソリューションを探している場合、またはロケーションで Cisco Calling プランが利用できない場合は、このオプションを選択します。 CCP パートナーは、PSTN 代替ソリューション、グローバルな広域カバレッジ、広範でさまざまな機能、パッケージ、価格設定を提供しています。

     

    CCP パートナーと対応地域は、こちらにリストされています。 ロケーションの国がサポートされているパートナーにのみ表示されています。 パートナーは、ロゴで表示されるか、簡単な文字列と括弧で囲んだ地域名で表示されます (例 : (EU)、(US)、または (CA))。 ロゴが表示されているパートナーは、常に CCP の地域メディアを提供しています。 文字列で表示されているパートナーについては、CCP の地域メディアを確保するために、ロケーションの国に最も近い地域を選択してください。

    リストされているプロバイダーの下に [番号を今すぐ注文する] オプションがある場合は、そのオプションを選択して、統合された CCP のメリットを利用することをおすすめします。 統合された CCP の場合、電話番号の調達とプロビジョニングを Control Hub の 1 つのペインで行えます。 統合されていない CCP の場合、Control Hub の外で、CCP パートナーから電話番号を調達する必要があります。

  • プレミスベースのPSTN(ローカル ゲートウェイ)-現在の PSTN プロバイダーを保持する場合、またはクラウド サイトでクラウド サイト以外に接続する場合、このオプションを選択できます。

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](ローカル ゲートウェイ) のいずれかを選択します。 [管理] をクリックして設定を変更してから、[続行] を選択することにより、関連するリスクを承認します。 以下のオプションのいずれかを選択して、[保存] クリックします。

  • Cisco PSTN - Cisco の Cloud PSTN ソリューションが必要な場合は、このオプションを選択します。 Cisco Calling プランは、緊急通話、国内および国際電話の着信および発信を提供する完全な PSTN 代替ソリューションであり、新しい PSTN 番号を注文したり、既存の番号を Cisco にポートしたりできます。


     

    Cisco PSTN オプションは、以下の条件でのみ表示されます。

    • コミットされた Cisco Calling プラン OCP (アウトバウンド通話プラン) を少なくとも 1 つ購入している。

    • Cisco Calling プランがサポートされている国にロケーションがある。

    • ロケーションが新規である。 他の PSTN 機能が割り当てられている既存のロケーションは、今回は Cisco Calling プランの対象外です。 サポート ケースを開いてご相談ください。

    • Cisco Calling プランがサポートされている地域のWebex Callingデータ センターでホストされています。

  • Cloud Connected PSTN - 多くの Cisco CCP パートナーの 1 つからクラウド PSTN ソリューションを探している場合、またはロケーションで Cisco Calling プランが利用できない場合は、このオプションを選択します。 CCP パートナーは、PSTN 代替ソリューション、グローバルな広域カバレッジ、広範でさまざまな機能、パッケージ、価格設定を提供しています。

     

    CCP パートナーと対応地域は、こちらにリストされています。 ロケーションの国がサポートされているパートナーにのみ表示されています。 パートナーは、ロゴで表示されるか、簡単な文字列と括弧で囲んだ地域名で表示されます (例 : (EU)、(US)、または (CA))。 ロゴが表示されているパートナーは、常に CCP の地域メディアを提供しています。 文字列で表示されているパートナーについては、CCP の地域メディアを確保するために、ロケーションの国に最も近い地域を選択してください。

    リストされているプロバイダーの下に [番号を今すぐ注文する] オプションがある場合は、そのオプションを選択して、統合された CCP のメリットを利用することをおすすめします。 統合された CCP の場合、電話番号の調達とプロビジョニングを Control Hub の 1 つのペインで行えます。 統合されていない CCP の場合、Control Hub の外で、CCP パートナーから電話番号を調達する必要があります。

  • プレミスベースのPSTN(ローカル ゲートウェイ)-現在の PSTN プロバイダーを保持する場合、またはクラウド サイトでクラウド サイト以外に接続する場合、このオプションを選択できます。

     

    ローカル ゲートウェイに以前設定されたロケーションを持つ Webex Calling の顧客は、同様のトランクを持つプレミス ベースの PSTN に自動的に変更されます。

3

ロケーションの主な連絡先担当者に連絡する際の代表番号を入力します。

4

(オプション) [緊急コール] で[緊急時のロケーション識別子] を選択して、このロケーションに割り当てることができます。


 

この設定はオプションで、設定が必要な国でのみ適用されます。

一部の国（例： フランス）、セルラー無線システムには、緊急コールを発信する際にセルの ID を確立するための規制要件があり、緊急機関に公開されています。 米国やカナダなどの他の国は、他の方法を使用して場所の特定を実装しています。 詳細については、次のサイトを参照してください。強化された緊急コールを選択します。

緊急通報プロバイダーは、アクセス ネットワークに関する情報を必要とする場合があります。この情報は、新しいプライベート SIP 拡張ヘッダーである P-Access-Network-Info を定義することによって実現されます。 ヘッダーは、アクセス ネットワークに関連する情報を伝送します。

ロケーションの緊急ロケーションの識別子を設定すると、ロケーションの値が SIP メッセージの一部としてプロバイダーに送信されます。 緊急通話プロバイダーに連絡して、この設定が必要かどうか確認し、緊急通話プロバイダーから提供された値を使用してください。」

5

このロケーションでユーザーがボイスメールをチェックするために呼び出せる [ボイスメール番号] を選択します。

6

(オプション) ロケーション ページの上部にある鉛筆アイコンをクリックし、必要に応じて [ロケーションの名前]、[アナウンス言語]、[メール言語]、[タイムゾーン]、[住所] を変更し、[保存] をクリックします。


 

[アナウンス言語] の変更は、このロケーションに追加された新規ユーザーや機能に対して直ちに有効になります。 既存のユーザーや機能のアナウンス言語も変更する必要がある場合は、プロンプトが表示されたら、[既存のユーザーとワークスペースの変更] または [既存機能の変更] を選択します。 [適用] をクリックします。 [タスク] ページで進捗状況を確認できます。 これが完了するまでは、これ以上変更を加えることはできません。


 

ロケーションの [タイム ゾーン] を変更しても、このロケーションに関連する機能のタイム ゾーンは更新されません。 自動アテンダント、ハント グループ、コール キューなどの機能のタイム ゾーンを編集するには、タイムゾーンを更新する特定の機能の [全般設定] エリアに移動し、そこで編集して保存します。

これらの設定は社内ダイヤルに適用されるものであり、最初のセットアップ ウィザードでも設定できます。 ダイヤル プランを変更すると、Control Hub の更新のサンプル番号が表示され、これらの変更が表示されます。


 

ロケーションに対する発信通話の権限を設定できます。 これらのステップをご覧になり、発信権限を設定してください。

1

Control Hub にサインインし、サービス > 通話 > サービス設定を選択してから、［内部ダイヤル］までスクロールします。

2

必要に応じて、次のオプションのダイヤル設定を行います。

  • ロケーション ルーティング プレフィックスの長さ—複数のロケーションがある場合は、この設定を推奨します。 2 ～ 7 桁の長さを入力できます。 同じ内線番号を持つ複数のロケーションがある場合、ロケーション間でコールを行うときに、ユーザーはプレフィックスをダイヤルする必要があります。 たとえば、複数のストアがある場合、内線 1000 を使用すると、各ストアにルーティング プレフィックスを設定することができます。 1 つのストアのプレフィックスが 888 の場合、そのストアに到達するために 8881000 にダイヤルします。

     

    ルーティング プレフィックスの長さには、ステアリング桁が含まれます。 たとえば、ルーティング プレフィックスの長さを 4 に設定すると、3 桁のみを使用してサイトを指定できます。


     

    ルーティング プレフィックスをロケーションに割り当てる場合、そのロケーションに割り当てられた内線のすべての外観には、内線番号の前にルーティング プレフィックスが含まれます。 たとえば、888-1000（ルーティング プレフィックス-内線）です。

  • [ルーティング プレフィックスのステアリング番号（Steering Digit in Routing Prefix）]:すべてのルーティング プレフィックスの最初の桁として設定される番号を選択します。
  • [内線番号の長さ(Internal Extension Length)]:2 ～ 10 桁を入力でき、デフォルトは 2 です。

     

    内線の長さを長くすると、既存の内部内線への短縮ダイヤルが自動的に更新されることはありません。

  • ロケーション間の内線ダイヤルを許可—組織の要件に基づいてロケーション間の内線ダイヤルをカスタマイズできます。

    • 組織にすべてのロケーションで重複する内線がない場合は、トグルを有効にします。

      デフォルトでは、トグルが有効になっています。

    • 組織が別の場所に同じ内線を持っている場合は、トグルを無効にします。 トグルが無効になり、発信者が内線番号をダイヤルすると、通話は、発信者と同じロケーションで内線番号が一致するユーザーにルーティングされます。 発信者は、エンタープライズ重要番号（ロケーションルーティングプレフィックス + 内線）をダイヤルして、他のロケーションの内線番号に到達する必要があります。

3

特定の場所の内部ダイヤルを指定します。 に移動 ［管理］>［ロケーション］を選択し、リストからロケーションを選択して、［通話］をクリックします。 [ダイヤル] までスクロールし、必要に応じて内部ダイヤルを変更します。

  • 内部ダイヤル - 別の場所にいるユーザーがこの場所にいる人に連絡するためにダイヤルする必要があるルーティング プレフィックスを指定します。 各ロケーションのルーティング プレフィックスは固有である必要があります。 プレフィックスの長さは組織レベルで設定された長さに一致することを推奨しますが、長さは 2 ～ 7 桁でなければなりません。
4

特定のロケーションの外部ダイヤルを指定します。 に移動 ［管理］>［ロケーション］を選択し、リストからロケーションを選択して、［通話］をクリックします。 [ダイヤル] までスクロールし、必要に応じて外部ダイヤルを変更します。

  • 外部ダイヤル—外線にダイヤルするためにダイヤルする必要がある外線番号の番号を選択することができます。 デフォルトは [なし] であり、このダイヤル習慣が必要ない場合には、値を [なし] にしておくことができます。 この機能を使用しない場合、組織のステアリング番号とは別の番号を使用することをお勧めします。

     

    ユーザーは、外線発信を行う際に外線発信番号を含め、レガシー システムでダイヤルしていた方法を真似たものにできます。 ただし、すべてのユーザーは引き続き、発信ダイアル番号がなくても外線通話を発信することができます。

  • 必要に応じて、このロケーションの発信ダイヤル番号のダイヤルを強制する機能を使用して、管理者が設定した発信ダイヤル番号を使用して外部コールを発信する必要があります。

     

    この機能が有効になっている場合でも、緊急コールは発信ダイヤル番号の有無にかかわらずダイヤルできます。

    有効にすると、発信ダイヤル番号が含まれていない場合、コール転送に使用されるような外部接続先番号は機能しなくなります。


     
    内線が国番号と同じ場合、内線が国番号よりも優先されます。 したがって、発信ダイヤル番号を有効にすることをお勧めします。

     
    着信および発信 PSTN コールに E.164 番号形式を使用することを強くお勧めします。

ユーザーへの影響:

  • ダイヤル基本設定の変更を有効にするには、ユーザーは電話を再起動する必要があります。

  • ユーザーの内線番号はロケーションのステアリング番号または発信ダイヤル番号と同じ番号で始まるべきではありません。

Control Hub でプレミス ベースの PSTN (ローカル ゲートウェイ) を設定する

付加価値再販業者の場合、これらの手順を使用して Control Hub でローカル ゲートウェイの設定を開始できます。 このゲートウェイがクラウドに登録されると、Webex Calling の 1 つ以上のロケーションで使用して、エンタープライズ PSTN サービス プロバイダーへのルーティングを提供できます。


 

ローカル ゲートウェイがある場所は、ローカル ゲートウェイが他の場所で使用されているときには削除できません。

トランクを作成する

次の手順に従って、Control Hub でトランクを作成します。

始める前に

  • ロケーションが追加されたら、ロケーションに対してプレミスベース PSTN を設定する前に、トランクを作成する必要があります。

  • それぞれについて、ロケーションと固有の設定および番号を作成します。 ロケーションはプレミスベース PSTN を追加する前に存在する必要があります。

  • Webex Calling でのプレミスベース PSTN (ローカル ゲートウェイ) 要件について理解しておいてください。

  • プレミスベース PSTN を持つロケーションに対して、複数のトランクを選択できませんが、複数のロケーションに対して同じトランクを選択することはできます。

1

ログインするコントロールハブで、サービス次のリンクをクリックしてください:電話次のリンクをクリックしてください:コール ルーティングを選択し、トランクの追加を選択します。https://admin.webex.com

2

ロケーションを選択します。

3

トランクの名前を指定し、[保存] をクリックします。


 

名前は 24 文字以内にしてください。

次に行うこと

トランクで設定する必要がある、関連するパラメーターが表示されます。 また、PSTN 接続をセキュアにするための SIP ダイジェスト資格情報のセットも生成します。

画面 [ドメインの登録]、[トランク グループ OTG/DTG]、[回線/ポート]、および [発信プロキシ アドレス] にトランク情報が表示されます。

プレミス ベースの PSTN を設定する準備ができたときに参照できるように、この情報を Control Hub からコピーして、ローカルのテキスト ファイルまたはドキュメントに貼り付けておくことをおすすめします。

資格情報を紛失した場合には、Control Hub のトランク情報画面で生成する必要があります。 [ユーザー名の取得とパスワードのリセット] をクリックして、トランクを使用するための認証資格情報の新しいセットを生成します。

プレミス ベースの PSTN のトランクを選択する

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 で電話番号を管理する」を参照してください。

Control Hub でトライアルからの Webex サービス購入をリクエストする

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に対する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 の 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 メッセージの処理を提供し、必要なターゲットにルーティングします。

Call routing from/to PSTN to/from Webex Calling configuration solution

オンプレミスの 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 インターフェイスに割り当てます。


interface GigabitEthernet0/0/0
  description Interface facing PSTN and/or CUCM
  ip address 10.80.13.12 255.255.255.0
!
interface GigabitEthernet0/0/1
  description Interface facing Webex Calling (Private address)
  ip address 192.51.100.1 255.255.255.240
2

対称暗号化を使用して、ルータ上の登録と STUN クレデンシャルを保護します。 プライマリ暗号化キーと暗号化タイプを次のように設定します。


key config-key password-encrypt YourPassword
password encryption aes
3

プレースホルダー PKI トラストポイントを作成します。


 
後で TLS を設定するには、このトラストポイントが必要です。 登録ベースのトランクの場合、このトラストポイントには証明書は必要ありません。証明書ベースのトランクに必要です。

crypto pki trustpoint EmptyTP 
 revocation-check none
4

TLS1.2 排他を有効にし、次の設定コマンドを使用してデフォルトのトラストポイントを指定します。 登録のための信頼性の高い安全な接続を確保するために、トランスポートパラメータも更新する必要があります。


 
cn-san-validate server コマンドは、テナント 200 で設定されたホスト名がアウトバウンド プロキシから受信した証明書の CN または SAN フィールドに含まれている場合に、ローカル ゲートウェイが接続を許可することを保証します。

  1. を設定 tcp再試行カウント～1000(5msecの倍数=5秒)

  2. タイマー接続の確立コマンドを使用すると、次の利用可能なオプションを検討する前に、LGWがプロキシとの接続を設定するのを待つ時間を調整できます。 このタイマーのデフォルトは 20 秒で、最低 5 秒です。 低値で開始し、ネットワーク条件に対応するために必要な場合は増加します。


sip-ua
 timers connection establish tls 5
 transport tcp tls v1.2
 crypto signaling default trustpoint EmptyTP cn-san-validate server
 tcp-retry 1000
5

Webex Calling で使用される DigiCert CA 証明書を含む Cisco ルート CA バンドルをインストールします。 を使用する crypto pki trustpool インポート クリーン URLコマンドは、指定されたURLからルートCAバンドルをダウンロードし、現在のCAトラストプールをクリアしてから、証明書の新しいバンドルをインストールします。


 

HTTPS を使用してインターネットにアクセスするためにプロキシを使用する必要がある場合は、CA バンドルをインポートする前に、次の設定を追加します。

ip httpクライアントプロキシサーバーyourproxy.comプロキシポート80 

ip http client source-interface GigabitEthernet0/0/1 
crypto pki trustpool import clean url https://www.cisco.com/security/pki/trs/ios_core.p7b

Webex Calling 登録ベースのトランクの設定

1

Control Hub の既存のロケーションに登録ベースの PSTN トランクを作成します。 トランクが作成されると、提供されたトランク情報をメモします。 次の図で強調表示されているこれらの詳細は、このガイドの設定手順で使用されます。 詳細については、次のサイトを参照してください。 Webex Calling用にトランク、ルートグループ、ダイヤルプランを構成するを選択します。

2

次のコマンドを入力して、CUBE を Webex Calling ローカル ゲートウェイとして設定します。

 
voice service voip
 ip address trusted list
  ipv4 x.x.x.x y.y.y.y
 mode border-element
 media statistics
 media bulk-stats 
 allow-connections sip to sip
 no supplementary-service sip refer  
 stun
  stun flowdata agent-id 1 boot-count 4
  stun flowdata shared-secret 0 Password123$
 sip
  asymmetric payload full
  early-offer forced

構成のフィールドの説明はここにあります。


ip address trusted list
 ipv4 x.x.x.x y.y.y.y

  • トール詐欺から保護するために、信頼されたアドレス リストは、ローカル ゲートウェイが正当な VoIP コールを期待するホストとネットワークのリストを定義します。

  • デフォルトでは、ローカル ゲートウェイは、信頼されたリストに含まれていない IP アドレスからのすべての着信 VoIP メッセージをブロックします。 「セッション ターゲット IP」またはサーバ グループ IP アドレスを持つ静的に設定されたダイヤル ピアはデフォルトで信頼されるため、信頼されたリストに追加する必要はありません。

  • ローカル ゲートウェイを設定するときは、地域の Webex Calling データ センターの IP サブネットをリストに追加します。 詳細については、「Webex Calling のポート参照情報」を参照してください。 また、Unified Communications Manager サーバ（使用されている場合）および PSTN トランク ゲートウェイのアドレス範囲を追加します。


     

    LGW が制限されたコーン NAT を備えたファイアウォールの背後にある場合、 Webex Callingに面しているインターフェイスのIPアドレスの信頼済みリストを無効にすることをお勧めします。 ファイアウォールは、未承諾の着信VoIPからすでに保護しています。 無効化することで、長期的な設定のオーバーヘッドが削減されます。次の理由から、 Webex Callingピアは固定されたままになり、いずれの場合でもピアに対してファイアウォールを構成する必要があります。

モード ボーダー要素

プラットフォームで Cisco Unified Border Element（CUBE）機能を有効にします。

メディア統計

ローカル ゲートウェイでメディア監視を有効にします。

メディア一括統計

一括コール統計のためにコントロール プレーンがデータ プレーンを投票できるようにします。

これらのコマンドの詳細については、「メディア」を参照してください。

allow-connections sip to sip

CUBE 基本 SIP バックツーバック ユーザ エージェント機能を有効にします。 詳細については、次のサイトを参照してください。接続を許可を選択します。


 

デフォルトでは、T.38 ファックス転送が有効になっています。 詳細については、ファックスプロトコルt38 (音声サービス)を参照してください。

スタイン

STUN (NAT を介した UDP のセッショントラバーサル) をグローバルに有効にします。

  • コールをWebex Callingユーザ（たとえば、着信側と発信側の両方がWebex Callingメディアをアンカーする場合はWebex Calling SBC)、ピンホールが開いていないため、メディアはローカル ゲートウェイにフローしません。

  • ローカル ゲートウェイの STUN バインディング機能により、ネゴシエートされたメディア パス上でローカルに生成された STUN 要求を送信できます。 これは、ファイアウォールのピンホールを開くのに役立ちます。

詳細については、次のサイトを参照してください。スタンフローデータエージェント-idおよびスタンフローデータ共有シークレットを選択します。

非対称ペイロード フル

DTMF と動的コーデック ペイロードの両方に対して SIP 非対称ペイロード サポートを設定します。 このコマンドの詳細については、次を参照してください非対称ペイロードを選択します。

early-offer forced

ローカル ゲートウェイは、隣接するピアからの確認を待つ代わりに、最初の INVITE メッセージで SDP 情報を送信するように強制します。 このコマンドの詳細については、次を参照してください早期オファーを選択します。

3

を設定する 音声クラス コーデック 100 トランクのフィルタ。 この例では、すべてのトランクに同じコーデックフィルタが使用されます。 正確な制御のために各トランクにフィルタを設定できます。


voice class codec 100
 codec preference 1 opus
 codec preference 2 g711ulaw
 codec preference 3 g711alaw

構成のフィールドの説明はここにあります。

音声クラス コーデック 100

SIP トランクを介したコールの優先コーデックのみを許可するために使用されます。 詳細については、音声クラスコーデック を参照してください。


 

Opus コーデックは、SIP ベースの PSTN トランクでのみサポートされています。 PSTN トランクが音声 T1/E1 またはアナログ FXO 接続を使用している場合は、コーデックの設定 1 オプスから音声クラスコーデック 100の設定。

4

を設定する 音声クラスの使い方 100 は、Webex Calling トランクで ICE を有効にします。


voice class stun-usage 100 
 stun usage firewall-traversal flowdata
 stun usage ice lite

構成のフィールドの説明はここにあります。

stunusageiceliteについて

すべての Webex Calling のダイヤルピアに対して ICE-Lite を有効にして、可能な限り、メディア最適化を可能にするために使用。 詳細については、次のサイトを参照してください。音声クラススタンの使用およびスタン使用アイスライトを選択します。


 

メディア パスの最適化を使用したコール フローには、ICE-lite のスタン使用が必要です。 SIP から TDM ゲートウェイへのメディア最適化を提供するには、IP-IP レッグで ICE-Lite が有効になっているループバック ダイヤル ピアを設定します。 技術的な詳細は、アカウントまたはTACチームにお問い合わせください。

5

Webex トラフィックのメディア暗号化ポリシーを設定します。


voice class srtp-crypto 100
 crypto 1 AES_CM_128_HMAC_SHA1_80

構成のフィールドの説明はここにあります。

音声クラス srtp-crypto 100

SDP の SRTP 暗号スイート CUBE オファーおよび応答メッセージの唯一の SRTP オファーとして SHA1_80 を指定します。 Webex Calling は SHA180 のみをサポートします。_ 詳細については、次のサイトを参照してください。音声クラス SRTP 暗号化を選択します。

6

宛先トランク パラメータに基づいて、ローカル ゲートウェイ トランクへのコールを一意に識別するパターンを設定します。


voice class uri 100 sip
 pattern dtg=Dallas1463285401_LGU

構成のフィールドの説明はここにあります。

音声クラス uri 100 sip

着信トランク ダイヤル ピアへの着信 SIP 招待と一致するパターンを定義します。 このパターンを入力する場合、トランクが作成されたときに、dtg= の後に Control Hub で提供されるトランク OTG/DTG 値を使用します。 詳細については、音声クラス uri を参照してください。

7

を設定する sip プロファイル 100は、Webex Callingに送信される前にSIPメッセージを変更するために使用されます。


voice class sip-profiles 100
 rule 10 request ANY sip-header SIP-Req-URI modify "sips:" "sip:"
 rule 20 request ANY sip-header To modify "<sips:" "<sip:"
 rule 30 request ANY sip-header From modify "<sips:" "<sip:"
 rule 40 request ANY sip-header Contact modify "<sips:(.*)>" "<sip:\1;transport=tls>" 
 rule 50 response ANY sip-header To modify "<sips:" "<sip:"
 rule 60 response ANY sip-header From modify "<sips:" "<sip:"
 rule 70 response ANY sip-header Contact modify "<sips:" "<sip:"
 rule 80 request ANY sip-header From modify ">" ";otg=dallas1463285401_lgu>"
 rule 90 request ANY sip-header P-Asserted-Identity modify "sips:" "sip:"

構成のフィールドの説明はここにあります。

  • ルール10～70、90

    コール シグナリングに使用される SIP ヘッダーが、Webex プロキシによって要求される sips スキームではなく sip を使用することを確認します。 sips を使用するように CUBE を設定すると、セキュアな登録が使用されます。

  • ルール80

    From ヘッダーを変更して、トランク グループの OTG/DTG 識別子を Control Hub から含め、企業内のローカル ゲートウェイ サイトを一意に識別します。

8

Webex Calling トランクの設定:

  1. を作成 音声クラス テナント 100は、Webex Callingトランクに必要な設定を定義し、グループ化します。 特に、以前の Control Hub で提供されるトランク登録の詳細は、以下の手順で使用されます。 このテナントに関連付けられているダイヤルピアは、後でこれらの設定を継承します。


     

    次の例では、このガイドの目的のために、ステップ 1 に示されている値を使用します (太字で表示)。 これらを構成のトランクの値に置き換えます。

    
voice class tenant 100
  registrar dns:98027369.us10.bcld.webex.com scheme sips expires 240 refresh-ratio 50 tcp tls
  credentials number Dallas1171197921_LGU username Dallas1463285401_LGU password 0 9Wt[M6ifY+ realm BroadWorks
  authentication username Dallas1463285401_LGU password 0 9Wt[M6ifY+ realm BroadWorks
  authentication username Dallas1463285401_LGU password 0 9Wt[M6ifY+ realm 98027369.us10.bcld.webex.com
  no remote-party-id
  sip-server dns:98027369.us10.bcld.webex.com
  connection-reuse
  srtp-crypto 100
  session transport tcp tls 
  url sips 
  error-passthru
  asserted-id pai 
  bind control source-interface GigabitEthernet0/0/1
  bind media source-interface GigabitEthernet0/0/1
  no pass-thru content custom-sdp 
  sip-profiles 100 
  outbound-proxy dns:dfw04.sipconnect-us.bcld.webex.com  
  privacy-policy passthru

    構成のフィールドの説明はここにあります。

    音声クラス テナント 100

    Webex Calling トランクにのみ使用される一連の設定パラメータを定義します。 詳細については、次のサイトを参照してください。音声クラス テナントを選択します。

    レジストラdns:98027369.us10.bcld.webex.com スキームsips expires 240 更新比 50 tcp tls

    2 分 (240 秒の50%) ごとに更新するように登録が設定されたローカル ゲートウェイのレジストラ サーバー。 詳細については、次のサイトを参照してください。登録事業者を選択します。

    ここで Control Hub から [ドメインの登録] 値を使用していることを確認します。

    クレデンシャル番号 Dallas1171197921_LGU ユーザー名 Dallas1463285401_LGUパスワード 0 9Wt[M6ifY+realm BroadWorks

    トランク登録チャレンジの資格情報。 詳細については、次のサイトを参照してください。クレデンシャル (SIP UA)を選択します。

    ここで、Control Hub からそれぞれ回線/ポートホスト、認証ユーザ名、認証パスワードの値を使用していることを確認します。

    認証ユーザ名 Dallas1171197921_LGU パスワード 0 9Wt[M6ifY+ realm BroadWorks
    認証ユーザ名 Dallas1171197921_LGUパスワード 0 9Wt[M6ifY+ realm 98027369.us10.bcld.webex.com

    コールの認証の課題。 詳細については、次のサイトを参照してください。認証（ダイヤルピア）を選択します。

    ここで、Control Hub からそれぞれ認証ユーザ名、認証パスワード、およびレジストラドメインの値を使用していることを確認してください。

    no remote-party-id

    ID Webex Callingは PAI をサポートしているため、CIOアサート ID paiを選択します。 詳細については、次のサイトを参照してください。リモートパーティ IDを選択します。

    sip-server dns:us25.sipconnect.bcld.webex.com

    トランクのターゲット SIP サーバを設定します。 トランクを作成するときは、Control Hub で提供されるエッジ プロキシ SRV アドレスを使用します。

    connection-reuse

    登録およびコール処理に対して同じ持続的な接続を使用する。 詳細については、次のサイトを参照してください。接続の再使用を選択します。

    srtp クリプト 100

    SRTP コール レッグ（接続）の優先暗号スイートを設定します（ステップ 5 で指定）。 詳細については、次のサイトを参照してください。音声クラス srtp-crypto。

    session transport tcp tls

    トランスポートをTLSに設定します。 詳細については、次のサイトを参照してください。セッション-トランスポートを選択します。

    url sips

    SRV クエリは、アクセス SBC でサポートされているように SIP である必要があります。他のすべてのメッセージは、sip-profile 200 によって SIP に変更されます。

    error-passthru

    SIP エラー応答パススルー機能を指定します。 詳細については、次のサイトを参照してください。エラーpassthruを選択します。

    asserted-id pai

    ローカル ゲートウェイで PAI 処理をオンにします。 詳細については、次のサイトを参照してください。アサート IDを選択します。

    バインド制御ソースインターフェイス GigabitEthernet0/0/1

    WebexCalling に送信されるメッセージのソース インターフェイスと関連する IP アドレスを設定します。 詳細は、bindを参照してください。

    バインド メディア ソース インターフェイス GigabitEthernet0/0/1

    WebexCalling に送信されるメディアのソース インターフェイスおよび関連する IP アドレスを設定します。 詳細は、bindを参照してください。

    no pass-thru content custom-sdp

    テナントの下のデフォルト コマンド。 このコマンドの詳細については、次を参照してくださいパススルー コンテンツを選択します。

    sipプロファイル 100

    SIP を SIP に変更し、次で定義されているように、INVITE および REGISTER メッセージの回線/ポートを修正します： SIP プロファイル200を選択します。 詳細については、次のサイトを参照してください。音声クラス sip-プロファイルを選択します。

    アウトバウンドプロキシ dns:dfw04.sipconnect-us.bcld.webex.com

    Webex Calling SBC にアクセスします。 トランクを作成したときに、Control Hub で提供されるアウトバウンド プロキシ アドレスを挿入します。 詳細については、次のサイトを参照してください。アウトバウンド-プロキシを選択します。

    privacy-policy passthru

    トランクのプライバシー ヘッダー ポリシー オプションを設定して、受信したメッセージから次のコール レッグにプライバシーの値を渡します。 詳細については、次のサイトを参照してください。プライバシーポリシーを選択します。

  2. Webex Calling トランク ダイヤル ピアを設定します。

    
dial-peer voice 100 voip
 description Inbound/Outbound Webex Calling
 max-conn 250
 destination-pattern BAD.BAD
 session protocol sipv2
 session target sip-server
 incoming uri request 100
 voice-class codec 100
 dtmf-relay rtp-nte
 voice-class stun-usage 100
 no voice-class sip localhost
 voice-class sip tenant 100
 srtp
 no vad

    構成のフィールドの説明はここにあります。

    
dial-peer voice 100 voip
  description Inbound/Outbound Webex Calling

    次のタグでVoIPダイヤルピアを定義します100管理とトラブルシューティングを容易にするために意味のある説明を付けます。

    マックスコン 250

    LGW と Webex Calling の間の同時着信コールと発信コールの数を制限します。 登録トランクの場合、設定されている最大値は 250 である必要があります。 Usea は、展開に適している場合は値を下げます。 ローカル ゲートウェイの同時通話制限の詳細については、「ローカル ゲートウェイを使い始める」のドキュメントを参照してください。

    destination-pattern BAD.BAD

    着信ダイヤル ピア グループを使用して発信コールをルーティングする場合は、ダミー接続先パターンが必要です。 この場合、有効な宛先パターンを使用できます。

    session protocol sipv2

    ダイヤルピアが100 SIP コール レッグを処理します。 詳細については、セッションプロトコル（ダイヤルピア）を参照してください。

    session target sip-server

    テナント 100 で定義された SIP サーバが継承され、このダイヤル ピアからのコールの宛先に使用されることを示します。

    着信 uri リクエスト 100

    VoIP ダイヤル ピアと着信コールのユニフォーム リソース 識別子（URI）を一致させるために使用される音声クラスを指定します。 詳細については、着信 uri を参照してください。

    音声クラス コーデック 100

    共通のコーデック フィルタ リスト 100 を使用するようにダイヤル ピアを設定します。 詳細については、次のサイトを参照してください。音声クラス コーデックを選択します。

    音声クラスのstun使用 100

    ローカル ゲートウェイでローカルに生成された STUN 要求を、ネゴシエートされたメディア パス経由で送信できるようにします。 STUN は、メディア トラフィックのファイアウォールのピンホールを開くのに役立ちます。

    no voice-class sip localhost

    発信メッセージの From、Call- ID、および Remote-Party- IDヘッダーで、物理IPアドレスの代わりにDNSローカル主催者名の置換を無効にします。

    音声クラス SIP テナント 100

    ダイヤル ピアは、グローバルおよびテナント 100 で設定されたすべてのパラメータを継承します。 パラメータはダイヤル ピア レベルで上書きされる場合があります。

    srtp

    コール レッグのSRTPを有効にします。

    no vad

    音声アクティブティの検出を無効にします。

テナント を定義した後 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を受信すると、登録が成功します。

SIP PSTN トランクを使用したローカル ゲートウェイの設定

上記の Webex Calling に対してトランクを構築した後、次の設定を使用して、SIP ベースの PSTN プロバイダーに対して暗号化されていないトランクを作成します。


 

サービス プロバイダーがセキュアな PSTN トランクを提供している場合、上記の Webex Calling トランクと同様の構成に従うことができます。 セキュアからセキュアなコール ルーティングは CUBE でサポートされています。


 

Cisco TDM-SIP ゲートウェイで PSTN コール レッグの TDM インターフェイスを設定するには、「ISDN PRI の設定」を参照してください。

1

PSTN トランクからの着信コールを識別するには、次の音声クラス uri を設定します。


voice class uri 200 sip
  host ipv4:192.168.80.13

構成のフィールドの説明はここにあります。

音声クラス uri 200 sip

着信トランク ダイヤル ピアへの着信 SIP 招待と一致するパターンを定義します。 このパターンを入力するときは、IP PSTN ゲートウェイの IP アドレスを使用します。 詳細については、音声クラス uri を参照してください。

2

次の IP PSTN ダイヤル ピアを設定します。


dial-peer voice 200 voip
 description Inbound/Outbound IP PSTN trunk
 destination-pattern BAD.BAD
 session protocol sipv2
 session target ipv4:192.168.80.13
 incoming uri via 200
 voice-class sip bind control source-interface GigabitEthernet0/0/0 
 voice-class sip bind media source-interface  GigabitEthernet0/0/0 
 voice-class codec 100
 dtmf-relay rtp-nte 
 no vad

構成のフィールドの説明はここにあります。


dial-peer voice 200 voip
 description Inbound/Outbound IP PSTN trunk

次のタグで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 経由で 着信 uri

VIA ヘッダーとIP PSTN のIPアドレスの一致基準を定義します。 ローカル ゲートウェイのすべての着信 IP PSTN コール レッグとダイヤル ピア 200 を一致させます。 詳細については、着信 URLを参照してください。

バインド制御ソースインタフェース GigabitEthernet0/0/0

PSTN に送信されるメッセージのソース インターフェイスと関連する IP アドレスを設定します。 詳細は、bindを参照してください。

バインド メディア ソース インターフェイス GigabitEthernet0/0/0

PSTN に送信されるメディアのソース インターフェイスおよび関連する 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 プラットフォームを使用してローカル ゲートウェイを設定する場合は、次のセクションに進みます。

  1. ダイヤルピア グループを作成して、Webex Calling または PSTN にコールをルーティングします。 Webex Calling に向けて発信ダイヤルピア 100 で DPG 100 を定義します。 DPG 100 は、PSTN からの着信ダイヤルピアに適用されます。 同様に、PSTN に向かって発信ダイヤルピア 200 で DPG 200 を定義します。 DPG 200 は、Webex からの着信ダイヤルピアに適用されます。

    
voice class dpg 100 
 description Route calls to Webex Calling 
 dial-peer 100 
voice class dpg 200 
 description Route calls to PSTN 
 dial-peer 200

    構成のフィールドの説明はここにあります。

    ダイヤルピア 100

    発信ダイヤルピアとダイヤルピア グループを関連付けます。 詳細は、音声クラス dpgを参照してください。

  2. ダイヤルピア グループを適用して、Webex から PSTN に、および PSTN から Webex にコールをルーティングします。

    
dial-peer voice 100
 destination dpg 200
dial-peer voice 200
 destination dpg 100

    構成のフィールドの説明はここにあります。

    destination dpg 200

    どのダイヤル ピア グループを指定します。したがって、この着信ダイヤル ピアに提示されたコールの発信処理にダイヤル ピアを使用する必要があります。

    これでローカル ゲートウェイの設定は終了します。 CUBE 機能が初めて設定される場合は、設定を保存し、プラットフォームをリロードします。

既存のUnified CM環境でローカル ゲートウェイを構成する

前のセクションの 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 を設定:

  1. SIP VIA ポートを使用して Unified CM を Webex コールに分類します。

    
voice class uri 300 sip
 pattern :5065

  2. ポート経由の SIP を使用して、Unified CM を PSTN コールに分類します。

    
voice class uri 400 sip
 pattern 192\.168\.80\.6[0-5]:5060

    発信元のソース アドレスとポート番号を説明する 1 つ以上のパターンを使用して、UCM からの着信メッセージを PSTN トランクに分類します。 必要に応じて、正規表現を使用して、一致するパターンを定義できます。

    上記の例では、192.168.80.60 から 65 までの範囲およびポート番号 5060 の任意の IP アドレスに一致させるために正規表現が使用されます。

2

次の DNS レコードを設定して、Unified CM ホストへの SRV ルーティングを指定します。


 

IOS XE は、これらのレコードをローカルでターゲット UCM ホストとポートを決定するために使用します。 この設定では、DNS システムでレコードを設定する必要はありません。 DNS を使用する場合は、これらのローカル設定は必要ありません。


ip host ucmpub.mydomain.com 192.168.80.60
ip host ucmsub1.mydomain.com 192.168.80.61
ip host ucmsub2.mydomain.com 192.168.80.62
ip host ucmsub3.mydomain.com 192.168.80.63
ip host ucmsub4.mydomain.com 192.168.80.64
ip host ucmsub5.mydomain.com 192.168.80.65
ip host _sip._udp.wxtocucm.io srv 0 1 5065 ucmpub.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub1.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub2.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub3.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub4.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub5.mydomain.com
ip host _sip._udp.pstntocucm.io srv 0 1 5060 ucmpub.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub1.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub2.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub3.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub4.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub5.mydomain.com

構成のフィールドの説明はここにあります。

次のコマンドは、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

次のダイヤルピアを設定します。

  1. Unified CM と Webex Calling 間のコールのダイヤルピア:

    
dial-peer voice 300 voip
 description UCM-Webex Calling trunk
 destination-pattern BAD.BAD
 session protocol sipv2
 session target dns:wxtocucm.io
 incoming uri via 300
 voice-class codec 100
 voice-class sip bind control source-interface GigabitEthernet 0/0/0
 voice-class sip bind media source-interface GigabitEthernet 0/0/0
 dtmf-relay rtp-nte
 no vad

    構成のフィールドの説明はここにあります。

    
dial-peer voice 300 voip
 description UCM-Webex Calling trunk

    タグ 300 を使用して VoIP ダイヤルピアを定義し、管理とトラブルシューティングを容易にするための意味のある説明を提供します。

    destination-pattern BAD.BAD

    着信ダイヤル ピア グループを使用して発信コールをルーティングする場合は、ダミー接続先パターンが必要です。 この場合、有効な宛先パターンを使用できます。

    session protocol sipv2

    ダイヤルピア 300 が SIP コール レッグを処理するように指定します。 詳細については、セッションプロトコル（ダイヤルピア）を参照してください。

    セッション ターゲット dns:wxtocucm.io

    DNS SRV 解決を通じて複数の Unified CM ノードのセッション ターゲットを定義します。 この場合、ローカルで定義された SRV レコード wxtocucm.io がコールをダイレクトするために使用されます。

    incoming uri via 300

    音声クラス URI 300 を使用して、ソース ポート 5065 を使用して Unified CM からのすべての着信トラフィックをこのダイヤル ピアにダイレクトします。 詳細については、着信 uri を参照してください。

    音声クラス コーデック 100

    Unified CM との間のコールのコーデック フィルタ リストを示します。 詳細については、「音声クラスコーデック」を参照してください。

    バインド制御ソースインタフェース GigabitEthernet0/0/0

    PSTN に送信されるメッセージのソース インターフェイスと関連する IP アドレスを設定します。 詳細は、bindを参照してください。

    バインド メディア ソース インターフェイス GigabitEthernet0/0/0

    PSTN に送信されるメディアのソース インターフェイスおよび関連する IP アドレスを設定します。 詳細は、bindを参照してください。

    dtmf-relay rtp-nte

    コール レッグで期待されるDTMF機能として、 RTP -NTE (RFC2833) を定義します。 詳細については、「DTMF Relay (Voice over IP)」を参照してください。

    no vad

    音声アクティブティの検出を無効にします。 詳細については、vad（ダイヤルピア）を参照してください。

  2. Unified CM と PSTN 間のコールのダイヤルピア:

    
dial-peer voice 400 voip
 description UCM-PSTN trunk
 destination-pattern BAD.BAD
 session protocol sipv2
 session target dns:pstntocucm.io
 incoming uri via 400
 voice-class codec 100 
 voice-class sip bind control source-interface GigabitEthernet 0/0/0
 voice-class sip bind media source-interface GigabitEthernet 0/0/0
 dtmf-relay rtp-nte
 no vad

    構成のフィールドの説明はここにあります。

    
dial-peer voice 400 voip
 description UCM-PSTN trunk

    次のタグでVoIPダイヤルピアを定義します300管理とトラブルシューティングを容易にするために意味のある説明を付けます。

    destination-pattern BAD.BAD

    着信ダイヤル ピア グループを使用して発信コールをルーティングする場合は、ダミー接続先パターンが必要です。 この場合、有効な宛先パターンを使用できます。

    session protocol sipv2

    ダイヤルピア 400 が SIP コール レッグを処理するように指定します。 詳細については、セッションプロトコル（ダイヤルピア）を参照してください。

    セッション ターゲット dns:pstntocucm.io

    DNS SRV 解決を通じて複数の Unified CM ノードのセッション ターゲットを定義します。 この場合、ローカルで定義された SRV レコード pstntocucm.io がコールをダイレクトするために使用されます。

    URI を400 経由で着信

    音声クラス URI 400 を使用して、ソース ポート 5060 を使用して指定された Unified CM ホストからのすべての着信トラフィックをこのダイヤル ピアに転送します。 詳細については、着信 uri を参照してください。

    音声クラス コーデック 100

    Unified CM との間のコールのコーデック フィルタ リストを示します。 詳細については、「音声クラスコーデック」を参照してください。

    バインド制御ソースインタフェース GigabitEthernet0/0/0

    PSTN に送信されるメッセージのソース インターフェイスと関連する IP アドレスを設定します。 詳細は、bindを参照してください。

    バインド メディア ソース インターフェイス GigabitEthernet0/0/0

    PSTN に送信されるメディアのソース インターフェイスおよび関連する IP アドレスを設定します。 詳細は、bindを参照してください。

    dtmf-relay rtp-nte

    コール レッグで期待されるDTMF機能として、 RTP -NTE (RFC2833) を定義します。 詳細については、「DTMF Relay (Voice over IP)」を参照してください。

    no vad

    音声アクティブティの検出を無効にします。 詳細については、vad（ダイヤルピア）を参照してください。

4

次の設定を使用してコール ルーティングを追加します。

  1. Unified CM と Webex Calling の間で通話をルーティングするダイヤル ピア グループを作成します。 でDPG 100を定義する 発信ダイヤルピア 100 Webex Calling に移行します。 DPG 100 は、Unified CM から関連付けられた着信ダイヤルピアに適用されます。 同様に、Unified CM に向かって発信ダイヤルピア 300 で DPG 300 を定義します。 DPG 300 は、Webex からの着信ダイヤルピアに適用されます。

    
voice class dpg 100
 description Route calls to Webex Calling
 dial-peer 100
voice class dpg 300
 description Route calls to Unified CM Webex Calling trunk
 dial-peer 300

  2. Unified CM と PSTN の間でコールをルーティングするダイヤル ピア グループを作成します。 でDPG 200を定義する 発信ダイヤルピア 200 PSTNへ。 DPG 200 は、Unified CM から関連付けられた着信ダイヤルピアに適用されます。 同様に、Unified CM に向かって発信ダイヤルピア 400 で DPG 400 を定義します。 DPG 400 は、PSTN からの着信ダイヤルピアに適用されます。

    
voice class dpg 200
 description Route calls to PSTN
 dial-peer 200
voice class dpg 400
 description Route calls to Unified CM PSTN trunk
 dial-peer 400

    構成のフィールドの説明はここにあります。

    ダイヤルピア 100

    発信ダイヤルピアとダイヤルピア グループを関連付けます。 詳細は、音声クラス dpgを参照してください。

  3. ダイヤルピア グループを適用して、Webex から Unified CM に、および Unified CM から Webex にコールをルーティングします。

    
dial-peer voice 100
 destination dpg 300
dial-peer voice 300
 destination dpg 100

    構成のフィールドの説明はここにあります。

    宛先 DPG 300

    どのダイヤル ピア グループを指定します。したがって、この着信ダイヤル ピアに提示されたコールの発信処理にダイヤル ピアを使用する必要があります。

  4. ダイヤルピア グループを適用して、PSTN から Unified CM に、Unified CM から PSTN にコールをルーティングします。

    
dial-peer voice 200
 destination dpg 400
dial-peer voice 400
 destination dpg 200

    これでローカル ゲートウェイの設定は終了します。 CUBE 機能が初めて設定される場合は、設定を保存し、プラットフォームを再読み込みします。

診断署名を使ってローカル ゲートウェイを監視しトラブルシューティングする

診断署名(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 以降を実行しているローカル ゲートウェイ

  1. 診断署名はデフォルトで有効になっています。

  2. デバイスが Cisco IOS XE 17.6.1a 以降を実行している場合、プロアクティブな通知を送信するために使用する、セキュアな電子メールサーバを設定します。

    configure terminal 
call-home  
mail-server <username>:<pwd>@<email server> priority 1 secure tls 
end

  3. 環境変数を構成します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 アカウント設定を構成し、デバイスからのメールを適切に処理するための専用権限を指定する必要があります。

  1. に移動 Googleアカウントの管理 > セキュリティを選択し、[安全性の低いアプリアクセス]設定をオンにします。

  2. 「Google 以外のアプリを使って第三者があなたのアカウントにサインインすることができなくなりました」というメールが Gmail から送られてきたら、「はい、それは私です」と回答します。

プロアクティブ モニタリングのための診断署名をインストールする

高いCPU使用率の監視

この DS は、SNMP OID 1.3.6.1.4.1.9.2.1.56 を使用して、CPU 使用率を 5 秒間追跡します。 使用率が 75% 以上に達すると、すべてのデバッグが無効になり、ローカルゲートウェイにインストールされている診断署名がすべてアンインストールされます。 下記の手順を実行して署名をインストールします。

  1. を使用する 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

  2. Diagnostic Signatures Lookup Tool の以下のドロップダウンオプションを使用して、DS 64224 をダウンロードします。

    フィールド名

    フィールド値

    プラットフォーム

    Cisco 4300、4400 ISR シリーズ、または Cisco CSR 1000V シリーズ

    製品

    Webex Calling ソリューションの CUBE Enterprise

    問題の範囲

    パフォーマンス

    問題の種類

    メール通知での高CPU使用率。

  3. 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)

  4. ローカルゲートウェイに DS XML ファイルをインストールします。

    call-home diagnostic-signature load DS_64224.xml 
Load file DS_64224.xml success

  5. イベント、登録者、出席者にすばやくアクセスするため、 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 自体がアンインストールされます。 署名をインストールするには、以下の手順を使用します。

  1. Diagnostic Signatures Lookup Tool の以下のドロップダウンオプションを使用して、DS 64117 をダウンロードします。

    フィールド名

    フィールド値

    プラットフォーム

    Cisco 4300、4400 ISR シリーズ、または Cisco CSR 1000V シリーズ

    製品

    Webex Calling ソリューションの CUBE Enterprise

    問題の範囲

    SIP-SIP

    問題の種類

    メール通知による SIP トランクの登録解除。

  2. DS XML ファイルをローカルゲートウェイにコピーします。

    copy ftp://username:password@<server name or ip>/DS_64117.xml bootflash:

  3. ローカルゲートウェイに DS XML ファイルをインストールします。

    call-home diagnostic-signature load DS_64117.xml 
Load file DS_64117.xml success 
LocalGateway#

  4. イベント、登録者、出席者にすばやくアクセスするため、 call-home 診断署名の表示を実行して、署名が正常にインストールされたことを確認します。 ステータス列の値が「registered」になっている必要があります。

異常な通話切断の監視

この DS は、10 分おきに SNMP ポーリングを使用して、SIP エラー 403、488、503 の異常な通話切断を検出します。  エラーカウントが前回の投票から 5 以上増えている場合、syslog とメール通知が生成されます。 下記の手順を実行して、署名をインストールしてください。

  1. を使用する 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

  2. Diagnostic Signatures Lookup Tool の以下のオプションを使用して、DS 65221 をダウンロードします。

    フィールド名

    フィールド値

    プラットフォーム

    Cisco 4300、4400 ISR シリーズ、または Cisco CSR 1000V シリーズ

    製品

    Webex Calling ソリューションの CUBE Enterprise

    問題の範囲

    パフォーマンス

    問題の種類

    メールおよび Syslog 通知による SIP の異常な通話切断の検出

  3. DS XML ファイルをローカルゲートウェイにコピーします。

    copy ftp://username:password@<server name or ip>/DS_65221.xml bootflash:

  4. ローカルゲートウェイに DS XML ファイルをインストールします。

    call-home diagnostic-signature load DS_65221.xml 
Load file DS_65221.xml success

  5. イベント、登録者、出席者にすばやくアクセスするため、 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 発生を検出し、以下のステップを使用して診断データ収集を自動化します。

  1. 追加の 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"

  2. SNMP がSNMPを表示 コマンド 有効になっていない場合は、snmpサーバーマネージャ コマンド

    show snmp 
%SNMP agent not enabled 
 
 
config t 
snmp-server manager 
end

  3. CPU使用率が高い期間中のすべてのデバッグと診断署名を無効にする予防策として、高CPUモニタリング DS 64224 をインストールしてください。 Diagnostic Signatures Lookup Tool の以下のオプションを使用して、DS 64224 をダウンロードします。

    フィールド名

    フィールド値

    プラットフォーム

    Cisco 4300、4400 ISR シリーズ、または Cisco CSR 1000V シリーズ

    製品

    Webex Calling ソリューションの CUBE Enterprise

    問題の範囲

    パフォーマンス

    問題の種類

    メール通知での高CPU使用率。

  4. 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

  5. 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:

  6. ローカルゲートウェイに、高 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

  7. 署名が正常にインストールされたことを確認してください。 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 では現在、新しいカスタム署名の作成リクエストをサポートしていません。

Control Hub を使用したCisco IOS XE ゲートウェイの管理と検証

Cisco IOS XE ゲートウェイの管理を改善するため、コントロールハブを通じてゲートウェイを登録し、管理することを推奨します。 これはオプションの設定です。 登録すると、コントロール ハブの設定検証オプションを使用して、ローカル ゲートウェイ構成を検証し、構成の問題を特定することができます。 現在、この機能をサポートしているのは登録ベースのトランクだけです。

詳細については、以下を参照してください。

デザインの概要

このセクションでは、証明書ベースの相互 TLS (mTLS) SIP トランクを使用して、Webex Calling のローカル ゲートウェイとして Cisco Unified Border Element (CUBE) を設定する方法について説明します。 このドキュメントの最初の部分は、シンプルな PSTN ゲートウェイを設定する方法を示しています。 この場合、PSTN からのすべてのコールは Webex Calling にルーティングされ、Webex Calling からのすべてのコールは PSTN にルーティングされます。 次の画像では、このソリューションとそれに続く高レベルのコール ルーティング設定が強調表示されます。

この設計では、次の主な構成が使用されます。

  • 音声クラスのテナント: トランク固有の設定を作成するために使用されます。

  • 音声クラス uri: 着信ダイヤルピアの選択のための SIP メッセージを分類するために使用。

  • 着信ダイヤルピア: 着信 SIP メッセージの処理を提供し、ダイヤルピア グループで発信ルートを決定します。

  • ダイヤルピア グループ: オンワード コール ルーティングに使用する発信ダイヤル ピアを定義します。

  • 発信ダイヤルピア: アウトバウンド SIP メッセージの処理を提供し、必要なターゲットにルーティングします。

Call routing from/to PSTN to/from Webex Calling configuration solution

オンプレミスの 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 インターフェイスに割り当てます。


interface GigabitEthernet0/0/0
 description Interface facing PSTN and/or CUCM
 ip address 192.168.80.14 255.255.255.0
!
interface GigabitEthernet0/0/1
 description Interface facing Webex Calling (Public address)
 ip address 198.51.100.1 255.255.255.240
2

対称暗号化を使用してルータの STUN クレデンシャルを保護します。 プライマリ暗号化キーと暗号化タイプを次のように設定します。


key config-key password-encrypt YourPassword
password encryption aes
3

希望する認証局 (CA) によって署名された証明書を使用して暗号化トラストポイントを作成します。

  1. 次の exec コマンドを使用して RSA キーペアを作成します。

    crypto key generate rsa general-keys exportable label lgw-key modulus 4096

  2. 次の設定コマンドを使用して、署名済み証明書のトラストポイントを作成します。

    
crypto pki trustpoint LGW_CERT
 enrollment terminal pem
 fqdn cube1.lgw.com
 subject-name cn=cube1.lgw.com
 subject-alt-name cube1.lgw.com
 revocation-check none
 rsakeypair lgw-key

  3. 次の exec または configuration コマンドを使用して証明書署名リクエスト（CSR）を生成し、サポートされている CA プロバイダーから署名済み証明書を要求するために使用します。

    crypto pki enroll LGW_CERT
4

中間（またはルート）CA 証明書を使用して新しい証明書を認証し、証明書をインポートします（ステップ 4）。 次の exec または configuration コマンドを入力します。


crypto pki authenticate LGW_CERT
<paste Intermediate X.509 base 64 based certificate here>
5

次の exec または configuration コマンドを使用して、署名済みホスト証明書をインポートします。


crypto pki import LGW_CERT certificate
<paste CUBE host X.509 base 64 certificate here>
6

TLS1.2 排他を有効にし、次の設定コマンドを使用してデフォルトのトラストポイントを指定します。


 sip-ua
  crypto signaling default trustpoint LGW_CERT
  transport tcp tls v1.2
7

Webex Calling で使用される DigiCert CA 証明書を含む Cisco ルート CA バンドルをインストールします。 を使用する crypto pki trustpool インポート クリーン URLコマンドは、指定されたURLからルートCAバンドルをダウンロードし、現在のCAトラストプールをクリアしてから、証明書の新しいバンドルをインストールします。


 

HTTPS を使用してインターネットにアクセスするためにプロキシを使用する必要がある場合は、CA バンドルをインポートする前に、次の設定を追加します。

ip httpクライアントプロキシサーバーyourproxy.comプロキシポート80 

ip http client source-interface GigabitEthernet0/0/1 
crypto pki trustpool import clean url https://www.cisco.com/security/pki/trs/ios_core.p7b

Webex Calling 証明書ベースのトランクの設定

1

Control Hub の既存のロケーションの CUBE 証明書ベースの PSTN トランクを作成します。 詳細については、次のサイトを参照してください。 Webex Calling用にトランク、ルートグループ、ダイヤルプランを構成するを選択します。


 
トランクが作成されると、提供されたトランク情報をメモします。 次の図で強調表示されているこれらの詳細は、このガイドの設定手順で使用されます。
2

次のコマンドを入力して、CUBE を Webex Calling ローカル ゲートウェイとして設定します。


voice service voip
 ip address trusted list
  ipv4 x.x.x.x y.y.y.y
 mode border-element
 allow-connections sip to sip
 no supplementary-service sip refer
 stun
  stun flowdata agent-id 1 boot-count 4
  stun flowdata shared-secret 0 Password123$
 sip 
  asymmetric payload full
  early-offer forced
  sip-profiles inbound

構成のフィールドの説明はここにあります。


ip address trusted list
 ipv4 x.x.x.x y.y.y.y

  • トール詐欺から保護するために、信頼されたアドレス リストは、ローカル ゲートウェイが正当な VoIP コールを期待するホストおよびネットワーク エンティティのリストを定義します。

  • デフォルトでは、ローカル ゲートウェイは、信頼されたリストに含まれていない IP アドレスからのすべての着信 VoIP メッセージをブロックします。 「セッション ターゲット IP」またはサーバー グループ IP アドレスを持つ静的に設定されたダイヤル ピアはデフォルトで信頼されるため、信頼されたリストに追加する必要はありません。

  • ローカル ゲートウェイを設定するときは、地域の Webex Calling データセンターの IP サブネットをリストに追加します。詳細については、「Webex Calling のポート参照情報」を参照してください。 また、Unified Communications Manager サーバ（使用されている場合）および PSTN トランク ゲートウェイのアドレス範囲を追加します。

  • 電話料金の詐欺行為を防ぐためにIPアドレス信頼リストを使用する方法についての詳細は、次を参照してください。 IPアドレス信頼を選択します。

モード ボーダー要素

プラットフォームで Cisco Unified Border Element（CUBE）機能を有効にします。

allow-connections sip to sip

CUBE 基本 SIP バックツーバックユーザーエージェント機能を有効にします。 詳細については、次のサイトを参照してください。接続を許可を選択します。


 

デフォルトでは、T.38 ファックス転送が有効になっています。 詳細については、ファックスプロトコルt38 (音声サービス)を参照してください。

スタイン

STUN (NAT を介した UDP のセッショントラバーサル) をグローバルに有効にします。


 
これらのグローバル スタンコマンドは、NAT の後ろにローカル ゲートウェイを展開する場合にのみ必要です。

  • コールをWebex Callingユーザ（たとえば、着信側と発信側の両方がWebex Callingメディアをアンカーする場合はWebex Calling SBC)、ピンホールが開いていないため、メディアはローカル ゲートウェイにフローしません。

  • ローカル ゲートウェイの STUN バインディング機能により、ネゴシエートされたメディア パス上でローカルに生成された STUN 要求を送信できます。 これは、ファイアウォールのピンホールを開くのに役立ちます。

詳細については、「stun flowdata agent-id」および「stun flowdata shared-secret」を参照してください。

非対称ペイロード フル

DTMF と動的コーデック ペイロードの両方に対して SIP 非対称ペイロード サポートを設定します。 このコマンドの詳細については、次を参照してください非対称ペイロードを選択します。

early-offer forced

ローカル ゲートウェイは、隣接するピアからの確認を待つ代わりに、最初の INVITE メッセージで SDP 情報を送信するように強制します。 このコマンドの詳細については、次を参照してください早期オファーを選択します。

SIP プロファイル着信

CUBE が SIP プロファイルを使用して、受信したメッセージを変更できるようにします。 プロファイルは、ダイヤルピアまたはテナントを介して適用されます。

3

を設定する 音声クラスコーデック 100 トランクの コーデック フィルタ。 この例では、すべてのトランクに同じコーデックフィルタが使用されます。 正確な制御のために各トランクにフィルタを設定できます。


voice class codec 100
 codec preference 1 opus
 codec preference 2 g711ulaw
 codec preference 3 g711alaw

構成のフィールドの説明はここにあります。

音声クラス コーデック 100

SIP トランクを介したコールの優先コーデックのみを許可するために使用されます。 詳細については、音声クラスコーデック を参照してください。


 

Opus コーデックは、SIP ベースの PSTN トランクでのみサポートされています。 PSTN トランクが音声 T1/E1 またはアナログ FXO 接続を使用している場合は、コーデックの設定 1 オプスから音声クラスコーデック 100の設定。

4

を設定する 音声クラスの使い方 100 は、Webex Calling トランクで ICE を有効にします。 (この手順は政府版 Webex には適用されません)


voice class stun-usage 100 
 stun usage firewall-traversal flowdata
 stun usage ice lite

構成のフィールドの説明はここにあります。

stunusageiceliteについて

すべての Webex Calling のダイヤルピアに対して ICE-Lite を有効にして、可能な限り、メディア最適化を可能にするために使用。 詳細については、次のサイトを参照してください。音声クラススタンの使用およびスタン使用アイスライトを選択します。


 
使用量のファイアウォール/トラバーサルフローデータを読み込むコマンドは、NATの後ろにローカルゲートウェイを展開する場合にのみ必要です。

 
メディア パスの最適化を使用したコール フローには、ICE-lite のスタン使用が必要です。 SIP から TDM ゲートウェイへのメディア最適化を提供するには、IP-IP レッグで ICE-Lite が有効になっているループバック ダイヤル ピアを設定します。 技術的な詳細については、アカウントまたは TAC チームにお問い合わせください。
5

Webex トラフィックのメディア暗号化ポリシーを設定します。 (この手順は政府版 Webex には適用されません)


voice class srtp-crypto 100
 crypto 1 AES_CM_128_HMAC_SHA1_80

構成のフィールドの説明はここにあります。

音声クラス srtp-crypto 100

SDP の SRTP 暗号スイート CUBE オファーおよび応答メッセージの唯一の SRTP オファーとして SHA1_80 を指定します。 Webex Calling は SHA180 のみをサポートします。_ 詳細については、次のサイトを参照してください。音声クラス SRTP 暗号化を選択します。

6

FIPS 準拠の GCM 暗号を設定します(この手順は政府版 Webex にのみ適用されます)。


voice class srtp-crypto 100
crypto 1 AEAD_AES_256_GCM

構成のフィールドの説明はここにあります。

音声クラス srtp-crypto 100

CUBE が提供する暗号スイートとして GCM を指定します。 政府版 Webex のローカル ゲートウェイの GCM 暗号を設定することは必須です。

7

宛先 FQDN または SRV に基づいて、ローカル ゲートウェイ トランクへのコールを一意に識別するためのパターンを設定します。


voice class uri 100 sip
 pattern cube1.lgw.com

構成のフィールドの説明はここにあります。

音声クラス uri 100 sip

着信トランク ダイヤル ピアへの着信 SIP 招待と一致するパターンを定義します。 このパターンを入力するときは、トランクの作成中に Control Hub で設定された LGW FQDN または SRV を使用します。

8

SIP メッセージ操作プロファイルを設定します。 ゲートウェイがパブリック IP アドレスで設定されている場合は、次のようにプロファイルを設定するか、NAT を使用している場合は、次のステップにスキップします。 この例では、cube1.lgw.com はローカル ゲートウェイ用に設定された FQDN であり、「198.51.100.1」は Webex Calling に面したローカル ゲートウェイ インターフェイスのパブリック IP アドレスです。


voice class sip-profiles 100
 rule 10 request ANY sip-header Contact modify "@.*:" "@cube1.lgw.com:" 
 rule 20 response ANY sip-header Contact modify "@.*:" "@cube1.lgw.com:"

構成のフィールドの説明はここにあります。

ルール10と20

Webex がローカル ゲートウェイからのメッセージを認証できるようにするには、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 プロファイル

voice class sip-profiles 100
 rule 10 request ANY sip-header Contact modify "@.*:" "@cube1.lgw.com:"
 rule 20 response ANY sip-header Contact modify "@.*:" "@cube1.lgw.com:"
 rule 30 response ANY sdp-header Audio-Attribute modify "(a=candidate:1 1.*) 10.80.13.12" "\1 192.65.79.20"
 rule 31 response ANY sdp-header Audio-Attribute modify "(a=candidate:1 2.*) 10.80.13.12" "\1 192.65.79.20"
 rule 40 response ANY sdp-header Audio-Connection-Info modify "IN IP4 10.80.13.12" "IN IP4 192.65.79.20"
 rule 41 request ANY sdp-header Audio-Connection-Info modify "IN IP4 10.80.13.12" "IN IP4 192.65.79.20"
 rule 50 request ANY sdp-header Connection-Info modify "IN IP4 10.80.13.12" "IN IP4 192.65.79.20"
 rule 51 response ANY sdp-header Connection-Info modify "IN IP4 10.80.13.12" "IN IP4 192.65.79.20"
 rule 60 response ANY sdp-header Session-Owner modify "IN IP4 10.80.13.12" "IN IP4 192.65.79.20"
 rule 61 request ANY sdp-header Session-Owner modify "IN IP4 10.80.13.12" "IN IP4 192.65.79.20"
 rule 70 request ANY sdp-header Audio-Attribute modify "(a=rtcp:.*) 10.80.13.12" "\1 192.65.79.20"
 rule 71 response ANY sdp-header Audio-Attribute modify "(a=rtcp:.*) 10.80.13.12" "\1 192.65.79.20
 rule 80 request ANY sdp-header Audio-Attribute modify "(a=candidate:1 1.*) 10.80.13.12" "\1 192.65.79.20"
 rule 81 request ANY sdp-header Audio-Attribute modify "(a=candidate:1 2.*) 10.80.13.12" "\1 192.65.79.20"

構成のフィールドの説明はここにあります。

ルール10と20

Webex がローカル ゲートウェイからのメッセージを認証できるようにするには、SIP 要求および応答メッセージの「連絡先」ヘッダーに、Control Hub のトランクにプロビジョニングされた値が含まれている必要があります。 これは、単一のホストの FQDN、またはデバイスのクラスタに使用される SRV ドメイン名のいずれかになります。

ルール30～81

プライベート アドレス参照をサイトの外部パブリック アドレスに変換し、Webex が後続のメッセージを正しく解釈してルーティングできるようにします。

Webex Calling からの着信メッセージの SIP プロファイル

voice class sip-profiles 110
 rule 10 response ANY sdp-header Video-Connection-Info modify "192.65.79.20" "10.80.13.12"
 rule 20 response ANY sip-header Contact modify "@.*:" "@cube1.lgw.com:"
 rule 30 response ANY sdp-header Connection-Info modify "192.65.79.20" "10.80.13.12"
 rule 40 response ANY sdp-header Audio-Connection-Info modify "192.65.79.20" "10.80.13.12"
 rule 50 response ANY sdp-header Session-Owner modify "192.65.79.20" "10.80.13.12"
 rule 60 response ANY sdp-header Audio-Attribute modify "(a=candidate:1 1.*) 192.65.79.20" "\1 10.80.13.12"
 rule 70 response ANY sdp-header Audio-Attribute modify "(a=candidate:1 2.*) 192.65.79.20" "\1 10.80.13.12"
 rule 80 response ANY sdp-header Audio-Attribute modify "(a=rtcp:.*) 192.65.79.20" "\1 10.80.13.12"

構成のフィールドの説明はここにあります。

10から80までのルール

パブリックアドレス参照を設定済みのプライベートアドレスに変換し、Webex からのメッセージを CUBE で正しく処理できるようにします。

詳細については、次のサイトを参照してください。音声クラス sip-プロファイルを選択します。

10

ヘッダー変更プロファイルを使用して SIP オプションをキープアライブに設定します。


voice class sip-profiles 115
 rule 10 request OPTIONS sip-header Contact modify "<sip:.*:" "<sip:cube1.lgw.com:" 
 rule 30 request ANY sip-header Via modify "(SIP.*) 10.80.13.12" "\1 192.65.79.20"
 rule 40 response ANY sdp-header Connection-Info modify "10.80.13.12" "192.65.79.20"  
 rule 50 response ANY sdp-header Audio-Connection-Info modify "10.80.13.12" "192.65.79.20"
!
voice class sip-options-keepalive 100
 description Keepalive for Webex Calling
 up-interval 5
 transport tcp tls
 sip-profiles 115

構成のフィールドの説明はここにあります。

音声クラス 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 トランクの設定:

  1. を作成 音声クラス テナント 100は、Webex Callingトランクに必要な設定を定義し、グループ化します。 このテナントに関連付けられているダイヤルピアは、後でこれらの設定を継承します。


     

    次の例では、このガイドの目的のために、ステップ 1 に示されている値を使用します (太字で表示)。 これらを構成のトランクの値に置き換えます。

    
voice class tenant 100
 no remote-party-id
 sip-server dns:us25.sipconnect.bcld.webex.com
 srtp-crypto 100
 localhost dns:cube1.lgw.com
 session transport tcp tls
 no session refresh
 error-passthru
 bind control source-interface GigabitEthernet0/0/1
 bind media source-interface GigabitEthernet0/0/1
 no pass-thru content custom-sdp
 sip-profiles 100 
 sip-profiles 110 inbound
 privacy-policy passthru
!

    構成のフィールドの説明はここにあります。

    音声クラス テナント 100

    テナントを使用して、独自の TLS 証明書と CN または SAN 検証リストを持つトランクを設定することをお勧めします。 ここでは、テナントに関連付けられた tls プロファイルには、新しい接続を受け入れるか作成するために使用される信頼ポイントが含まれており、着信接続を検証するための CN または SAN リストがあります。 詳細については、次のサイトを参照してください。音声クラス テナントを選択します。

    no remote-party-id

    ID Webex Callingは PAI をサポートしているため、CIOアサート ID paiを選択します。 詳細については、次のサイトを参照してください。リモートパーティ IDを選択します。

    sip-server dns:us25.sipconnect.bcld.webex.com

    トランクのターゲット SIP サーバを設定します。 トランクを作成したときに、Control Hub で提供されるエッジ プロキシ SRV アドレスを使用します

    srtp クリプト 100

    SRTP コール レッグ（接続）の優先暗号スイートを設定します（ステップ 5 で指定）。 詳細については、次のサイトを参照してください。音声クラス SRTP 暗号化を選択します。

    localhost DNS: キューブ1.lgw.com

    発信メッセージの [送信元（From）]、[コール ID（Call-ID）]、および [リモートパーティー（Remote-Party-ID）] ヘッダーの物理的な IP アドレスを提供された FQDN に置き換えるように CUBE を設定します。

    session transport tcp tls

    関連付けられたダイヤルピアの TLS へのトランスポートを設定します。 詳細については、次のサイトを参照してください。セッション-トランスポートを選択します。

    セッション更新なし

    SIP セッションの更新をグローバルに無効にします。

    error-passthru

    SIP エラー応答パススルー機能を指定します。 詳細については、次のサイトを参照してください。エラーpassthruを選択します。

    バインド制御ソースインターフェイス GigabitEthernet0/0/1

    Webex Calling に送信されるメッセージのソース インターフェイスと関連する IP アドレスを設定します。 詳細は、bindを参照してください。

    バインド メディア ソース インターフェイス GigabitEthernet0/0/1

    Webex Calling に送信されるメディアのソース インターフェイスおよび関連する IP アドレスを設定します。 詳細は、bindを参照してください。

    音声クラス SIP プロファイル 100

    ヘッダー変更プロファイル（パブリック IP または NAT アドレス）を発信メッセージに使用するように適用します。 詳細については、次のサイトを参照してください。音声クラスの sip プロファイルを選択します。

    音声クラス SIP プロファイル 110 着信

    受信メッセージに使用するヘッダー変更プロファイル（NAT アドレスのみ）を適用します。 詳細については、音声クラス SIP プロファイルを参照してください。

    プライバシーポリシーpassthru

    トランクのプライバシー ヘッダー ポリシー オプションを設定して、受信したメッセージから次のコール レッグにプライバシーの値を渡します。 詳細については、次のサイトを参照してください。プライバシーポリシーを選択します。

  2. Webex Calling トランク ダイヤル ピアを設定します。

    
dial-peer voice 100 voip
 description Inbound/Outbound Webex Calling
 destination-pattern BAD.BAD
 session protocol sipv2
 session target sip-server
 incoming uri request 100
 voice-class codec 100
 voice-class stun-usage 100
 voice-class sip rel1xx disable
 voice-class sip asserted-id pai
 voice-class sip tenant 100
 voice-class sip options-keepalive profile 100
 dtmf-relay rtp-nte 
 srtp
 no vad

    構成のフィールドの説明はここにあります。

    
dial-peer voice 100 voip
 description Inbound/Outbound Webex Calling

    のタグを持つVoIPダイヤルピアを定義する 100で、管理とトラブルシューティングを容易にする意味のある説明を提供します。 詳細については、次のサイトを参照してください。ダイヤルピア音声を選択します。

    destination-pattern BAD.BAD

    着信ダイヤル ピア グループを使用して発信コールをルーティングする場合は、ダミー接続先パターンが必要です。 この場合、有効な宛先パターンを使用できます。

    session protocol sipv2

    ダイヤルピア を指定する 100 は SIP コール レッグを処理します。 詳細については、セッションプロトコル（ダイヤルピア）を参照してください。

    session target sip-server

    テナント 100 で定義された SIP サーバが継承され、このダイヤル ピアからのコールの宛先に使用されることを示します。

    着信 uri リクエスト 100

    VoIP ダイヤル ピアと着信コールのユニフォーム リソース 識別子（URI）を一致させるために使用される音声クラスを指定します。 詳細については、着信 uri を参照してください。

    音声クラス コーデック 100

    Webex Calling との通話のコーデック フィルター リストを示します。 詳細については、音声クラスコーデック を参照してください。

    音声クラスstun使用 100

    ローカル ゲートウェイでローカルに生成された STUN 要求を、ネゴシエートされたメディア パス経由で送信できるようにします。 STUN は、メディア トラフィックのファイアウォールのピンホールを開くのに役立ちます。

    音声クラス sip asserted-id pai

    プライバシー アサート済み ID（PAI）ヘッダーを使用して、発信通話情報を設定します。 詳細については、voice-class sip asserted-idを参照してください。

    音声クラス sip テナント 100

    ダイヤル ピアは、グローバルおよびテナント 100 で設定されたすべてのパラメータを継承します。 パラメータはダイヤルピア レベルで上書きされる場合があります。 詳細については、「音声クラス SIP テナント」を参照してください。

    音声クラス sip options-keepalive プロファイル 100

    このコマンドは、特定のプロファイル（100）を使用して、SIP サーバまたはエンドポイントのグループの可用性を監視するために使用されます。

    srtp

    コール レッグのSRTPを有効にします。

SIP PSTN トランクを使用したローカル ゲートウェイの設定

上記の Webex Calling に対してトランクを構築した後、次の設定を使用して、SIP ベースの PSTN プロバイダーに対して暗号化されていないトランクを作成します。


 

サービス プロバイダーがセキュアな PSTN トランクを提供している場合、上記の Webex Calling トランクと同様の構成に従うことができます。 セキュアからセキュアなコール ルーティングは CUBE でサポートされています。


 

Cisco TDM-SIP ゲートウェイで PSTN コール レッグの TDM インターフェイスを設定するには、「ISDN PRI の設定」を参照してください。

1

PSTN トランクからの着信コールを識別するには、次の音声クラス uri を設定します。


voice class uri 200 sip
  host ipv4:192.168.80.13

構成のフィールドの説明はここにあります。

音声クラス uri 200 sip

着信トランク ダイヤル ピアへの着信 SIP 招待と一致するパターンを定義します。 このパターンを入力するときは、IP PSTN ゲートウェイの IP アドレスを使用します。 詳細については、音声クラス uri を参照してください。

2

次の IP PSTN ダイヤル ピアを設定します。


dial-peer voice 200 voip
 description Inbound/Outbound IP PSTN trunk
 destination-pattern BAD.BAD
 session protocol sipv2
 session target ipv4:192.168.80.13
 incoming uri via 200
 voice-class sip bind control source-interface GigabitEthernet0/0/0 
 voice-class sip bind media source-interface  GigabitEthernet0/0/0 
 voice-class codec 100
 dtmf-relay rtp-nte 
 no vad

構成のフィールドの説明はここにあります。


dial-peer voice 200 voip
 description Inbound/Outbound IP PSTN trunk

次のタグで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 経由で 着信 uri

VIA ヘッダーとIP PSTN のIPアドレスの一致基準を定義します。 ローカル ゲートウェイのすべての着信 IP PSTN コール レッグとダイヤル ピア 200 を一致させます。 詳細については、着信 URLを参照してください。

バインド制御ソースインタフェース GigabitEthernet0/0/0

PSTN に送信されるメッセージのソース インターフェイスと関連する IP アドレスを設定します。 詳細は、bindを参照してください。

バインド メディア ソース インターフェイス GigabitEthernet0/0/0

PSTN に送信されるメディアのソース インターフェイスおよび関連する 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 プラットフォームを使用してローカル ゲートウェイを設定する場合は、次のセクションに進みます。

  1. ダイヤルピア グループを作成して、Webex Calling または PSTN にコールをルーティングします。 Webex Calling に向けて発信ダイヤルピア 100 で DPG 100 を定義します。 DPG 100 は、PSTN からの着信ダイヤルピアに適用されます。 同様に、PSTN に向かって発信ダイヤルピア 200 で DPG 200 を定義します。 DPG 200 は、Webex からの着信ダイヤルピアに適用されます。

    
voice class dpg 100 
 description Route calls to Webex Calling 
 dial-peer 100 
voice class dpg 200 
 description Route calls to PSTN 
 dial-peer 200

    構成のフィールドの説明はここにあります。

    ダイヤルピア 100

    発信ダイヤルピアとダイヤルピア グループを関連付けます。 詳細は、音声クラス dpgを参照してください。

  2. ダイヤルピア グループを適用して、Webex から PSTN に、および PSTN から Webex にコールをルーティングします。

    
dial-peer voice 100
 destination dpg 200
dial-peer voice 200
 destination dpg 100

    構成のフィールドの説明はここにあります。

    destination dpg 200

    どのダイヤル ピア グループを指定します。したがって、この着信ダイヤル ピアに提示されたコールの発信処理にダイヤル ピアを使用する必要があります。

    これでローカル ゲートウェイの設定は終了します。 CUBE 機能が初めて設定される場合は、設定を保存し、プラットフォームをリロードします。

既存のUnified CM環境でローカル ゲートウェイを構成する

前のセクションの PSTN-Webex Calling 設定は、Cisco Unified Communications Manager (UCM) クラスタへの追加のトランクを含めるように変更される場合があります。 この場合、すべてのコールは Unified CM 経由でルーティングされます。 ポート 5060 の UCM からのコールは PSTN にルーティングされ、ポート 5065 からのコールは Webex Calling にルーティングされます。 次の増分設定を追加して、この通話シナリオを含めることができます。

1

以下の音声クラス URI を設定:

  1. SIP VIA ポートを使用して Unified CM を Webex コールに分類します。

    
voice class uri 300 sip
 pattern :5065

  2. ポート経由の SIP を使用して、Unified CM を PSTN コールに分類します。

    
voice class uri 400 sip
 pattern 192\.168\.80\.6[0-5]:5060

    発信元のソース アドレスとポート番号を説明する 1 つ以上のパターンを使用して、UCM からの着信メッセージを PSTN トランクに分類します。 必要に応じて、正規表現を使用して、一致するパターンを定義できます。

    上記の例では、192.168.80.60 から 65 までの範囲およびポート番号 5060 の任意の IP アドレスに一致させるために正規表現が使用されます。

2

次の DNS レコードを設定して、Unified CM ホストへの SRV ルーティングを指定します。


 

IOS XE は、これらのレコードをローカルでターゲット UCM ホストとポートを決定するために使用します。 この設定では、DNS システムでレコードを設定する必要はありません。 DNS を使用する場合は、これらのローカル設定は必要ありません。


ip host ucmpub.mydomain.com 192.168.80.60
ip host ucmsub1.mydomain.com 192.168.80.61
ip host ucmsub2.mydomain.com 192.168.80.62
ip host ucmsub3.mydomain.com 192.168.80.63
ip host ucmsub4.mydomain.com 192.168.80.64
ip host ucmsub5.mydomain.com 192.168.80.65
ip host _sip._udp.wxtocucm.io srv 0 1 5065 ucmpub.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub1.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub2.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub3.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub4.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub5.mydomain.com
ip host _sip._udp.pstntocucm.io srv 0 1 5060 ucmpub.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub1.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub2.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub3.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub4.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub5.mydomain.com

構成のフィールドの説明はここにあります。

次のコマンドは、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

次のダイヤルピアを設定します。

  1. Unified CM と Webex Calling 間のコールのダイヤルピア:

    
dial-peer voice 300 voip
 description UCM-Webex Calling trunk
 destination-pattern BAD.BAD
 session protocol sipv2
 session target dns:wxtocucm.io
 incoming uri via 300
 voice-class codec 100
 voice-class sip bind control source-interface GigabitEthernet 0/0/0
 voice-class sip bind media source-interface GigabitEthernet 0/0/0
 dtmf-relay rtp-nte
 no vad

    構成のフィールドの説明はここにあります。

    
dial-peer voice 300 voip
 description UCM-Webex Calling trunk

    タグ 300 を使用して VoIP ダイヤルピアを定義し、管理とトラブルシューティングを容易にするための意味のある説明を提供します。

    destination-pattern BAD.BAD

    着信ダイヤル ピア グループを使用して発信コールをルーティングする場合は、ダミー接続先パターンが必要です。 この場合、有効な宛先パターンを使用できます。

    session protocol sipv2

    ダイヤルピア 300 が SIP コール レッグを処理するように指定します。 詳細については、セッションプロトコル（ダイヤルピア）を参照してください。

    セッション ターゲット dns:wxtocucm.io

    DNS SRV 解決を通じて複数の Unified CM ノードのセッション ターゲットを定義します。 この場合、ローカルで定義された SRV レコード wxtocucm.io がコールをダイレクトするために使用されます。

    incoming uri via 300

    音声クラス URI 300 を使用して、ソース ポート 5065 を使用して Unified CM からのすべての着信トラフィックをこのダイヤル ピアにダイレクトします。 詳細については、着信 uri を参照してください。

    音声クラス コーデック 100

    Unified CM との間のコールのコーデック フィルタ リストを示します。 詳細については、「音声クラスコーデック」を参照してください。

    バインド制御ソースインタフェース GigabitEthernet0/0/0

    PSTN に送信されるメッセージのソース インターフェイスと関連する IP アドレスを設定します。 詳細は、bindを参照してください。

    バインド メディア ソース インターフェイス GigabitEthernet0/0/0

    PSTN に送信されるメディアのソース インターフェイスおよび関連する IP アドレスを設定します。 詳細は、bindを参照してください。

    dtmf-relay rtp-nte

    コール レッグで期待されるDTMF機能として、 RTP -NTE (RFC2833) を定義します。 詳細については、「DTMF Relay (Voice over IP)」を参照してください。

    no vad

    音声アクティブティの検出を無効にします。 詳細については、vad（ダイヤルピア）を参照してください。

  2. Unified CM と PSTN 間のコールのダイヤルピア:

    
dial-peer voice 400 voip
 description UCM-PSTN trunk
 destination-pattern BAD.BAD
 session protocol sipv2
 session target dns:pstntocucm.io
 incoming uri via 400
 voice-class codec 100 
 voice-class sip bind control source-interface GigabitEthernet 0/0/0
 voice-class sip bind media source-interface GigabitEthernet 0/0/0
 dtmf-relay rtp-nte
 no vad

    構成のフィールドの説明はここにあります。

    
dial-peer voice 400 voip
 description UCM-PSTN trunk

    次のタグでVoIPダイヤルピアを定義します300管理とトラブルシューティングを容易にするために意味のある説明を付けます。

    destination-pattern BAD.BAD

    着信ダイヤル ピア グループを使用して発信コールをルーティングする場合は、ダミー接続先パターンが必要です。 この場合、有効な宛先パターンを使用できます。

    session protocol sipv2

    ダイヤルピア 400 が SIP コール レッグを処理するように指定します。 詳細については、セッションプロトコル（ダイヤルピア）を参照してください。

    セッション ターゲット dns:pstntocucm.io

    DNS SRV 解決を通じて複数の Unified CM ノードのセッション ターゲットを定義します。 この場合、ローカルで定義された SRV レコード pstntocucm.io がコールをダイレクトするために使用されます。

    URI を400 経由で着信

    音声クラス URI 400 を使用して、ソース ポート 5060 を使用して指定された Unified CM ホストからのすべての着信トラフィックをこのダイヤル ピアに転送します。 詳細については、着信 uri を参照してください。

    音声クラス コーデック 100

    Unified CM との間のコールのコーデック フィルタ リストを示します。 詳細については、「音声クラスコーデック」を参照してください。

    バインド制御ソースインタフェース GigabitEthernet0/0/0

    PSTN に送信されるメッセージのソース インターフェイスと関連する IP アドレスを設定します。 詳細は、bindを参照してください。

    バインド メディア ソース インターフェイス GigabitEthernet0/0/0

    PSTN に送信されるメディアのソース インターフェイスおよび関連する IP アドレスを設定します。 詳細は、bindを参照してください。

    dtmf-relay rtp-nte

    コール レッグで期待されるDTMF機能として、 RTP -NTE (RFC2833) を定義します。 詳細については、「DTMF Relay (Voice over IP)」を参照してください。

    no vad

    音声アクティブティの検出を無効にします。 詳細については、vad（ダイヤルピア）を参照してください。

4

次の設定を使用してコール ルーティングを追加します。

  1. Unified CM と Webex Calling の間で通話をルーティングするダイヤル ピア グループを作成します。 でDPG 100を定義する 発信ダイヤルピア 100 Webex Calling に移行します。 DPG 100 は、Unified CM から関連付けられた着信ダイヤルピアに適用されます。 同様に、Unified CM に向かって発信ダイヤルピア 300 で DPG 300 を定義します。 DPG 300 は、Webex からの着信ダイヤルピアに適用されます。

    
voice class dpg 100
 description Route calls to Webex Calling
 dial-peer 100
voice class dpg 300
 description Route calls to Unified CM Webex Calling trunk
 dial-peer 300

  2. Unified CM と PSTN の間でコールをルーティングするダイヤル ピア グループを作成します。 でDPG 200を定義する 発信ダイヤルピア 200 PSTNへ。 DPG 200 は、Unified CM から関連付けられた着信ダイヤルピアに適用されます。 同様に、Unified CM に向かって発信ダイヤルピア 400 で DPG 400 を定義します。 DPG 400 は、PSTN からの着信ダイヤルピアに適用されます。

    
voice class dpg 200
 description Route calls to PSTN
 dial-peer 200
voice class dpg 400
 description Route calls to Unified CM PSTN trunk
 dial-peer 400

    構成のフィールドの説明はここにあります。

    ダイヤルピア 100

    発信ダイヤルピアとダイヤルピア グループを関連付けます。 詳細は、音声クラス dpgを参照してください。

  3. ダイヤルピア グループを適用して、Webex から Unified CM に、および Unified CM から Webex にコールをルーティングします。

    
dial-peer voice 100
 destination dpg 300
dial-peer voice 300
 destination dpg 100

    構成のフィールドの説明はここにあります。

    宛先 DPG 300

    どのダイヤル ピア グループを指定します。したがって、この着信ダイヤル ピアに提示されたコールの発信処理にダイヤル ピアを使用する必要があります。

  4. ダイヤルピア グループを適用して、PSTN から Unified CM に、Unified CM から PSTN にコールをルーティングします。

    
dial-peer voice 200
 destination dpg 400
dial-peer voice 400
 destination dpg 200

    これでローカル ゲートウェイの設定は終了します。 CUBE 機能が初めて設定される場合は、設定を保存し、プラットフォームを再読み込みします。

診断署名を使ってローカル ゲートウェイを監視しトラブルシューティングする

診断署名(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 以降を実行しているローカルゲートウェイ

  1. 診断署名はデフォルトで有効になっています。

  2. デバイスで IOS XE 17.6.1 以降を実行している場合は、プロアクティブ通知の送信に使用するセキュアなメールサーバーを構成します。

    
configure terminal 
call-home  
mail-server <username>:<pwd>@<email server> priority 1 secure tls 
end

  3. 環境変数を構成します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% 以上に達すると、すべてのデバッグが無効になり、ローカルゲートウェイにインストールした診断署名がすべてアンインストールされます。 下記の手順を実行して署名をインストールします。

  1. コマンド を使用して 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

  2. 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 使用率

  3. 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)

  4. ローカルゲートウェイに DS XML ファイルをインストールします。

    
call-home diagnostic-signature load DS_64224.xml 
Load file DS_64224.xml success

  5. イベント、登録者、出席者にすばやくアクセスするため、 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 とメール通知が生成されます。 下記の手順を実行して、署名をインストールしてください。

  1. コマンド を使用して 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

  2. Diagnostic Signatures Lookup Tool の以下のオプションを使用して、DS 65221 をダウンロードします。

    フィールド名

    フィールド値

    プラットフォーム

    Cisco 4300、4400 ISR シリーズ、または Catalyst 8000V Edge ソフトウェア

    製品

    Webex Calling ソリューションの CUBE Enterprise

    問題の範囲

    パフォーマンス

    問題の種類

    メールおよび Syslog 通知による SIP の異常な通話切断の検出

  3. DS XML ファイルをローカルゲートウェイにコピーします。

    copy ftp://username:password@<server name or ip>/DS_65221.xml bootflash:

  4. ローカルゲートウェイに DS XML ファイルをインストールします。

    
call-home diagnostic-signature load DS_65221.xml 
Load file DS_65221.xml success

  5. コマンドを使用する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 発生を検出し、以下のステップを使用して診断データ収集を自動化します。

  1. 別の 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"

  2. コマンド を使用して SNMP が有効になっていることを確認します。 SNMPを表示だ SNMP が有効になっていない場合は、snmpサーバーマネージャ コマンド

    
show snmp 
%SNMP agent not enabled 
 
config t 
snmp-server manager 
end

  3. CPU使用率が高い期間中のすべてのデバッグと診断署名を無効にする予防策として、高CPUモニタリング DS 64224 をインストールすることをお勧めします。 Diagnostic Signatures Lookup Tool の以下のオプションを使用して、DS 64224 をダウンロードします。

    フィールド名

    フィールド値

    プラットフォーム

    Cisco 4300、4400 ISR シリーズ、または Catalyst 8000V Edge ソフトウェア

    製品

    Webex Calling ソリューションの CUBE Enterprise

    問題の範囲

    パフォーマンス

    問題の種類

    メール通知での高CPU使用率。

  4. 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

  5. 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:

  6. 高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

  7. を使用して署名が正常にインストールされていることを確認します。 コールホーム診断署名を表示だ ステータス列の値が「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 では現在、新しいカスタム署名の作成リクエストをサポートしていません。

ローカル ゲートウェイとして CUBE の高可用性を実装する

基礎

前提条件

Webex Calling のローカル ゲートウェイとして CUBE HA を展開する前に、以下の概念を深く理解するようにしてください。

この記事で提供される構成ガイドラインは、既存の音声構成が設定されていない専用のローカル ゲートウェイ プラットフォームが使用されていることを前提としています。 既存の 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 設定ガイドを次に示します。

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

インターフェイスのステータスを追跡するために、グローバル レベルでインターフェイス トラッキングを構成します。

conf t
 track 1 interface GigabitEthernet1 line-protocol
 track 2 interface GigabitEthernet2 line-protocol
 exit


VCUBE-1#conf t

VCUBE-1(config)#track 1 interface GigabitEthernet1 line-protocol

VCUBE-1(config-track)#track 2 interface GigabitEthernet2 line-protocol

VCUBE-1(config-track)#exit

VCUBE-2#conf t

VCUBE-2(config)#track 1 interface GigabitEthernet1 line-protocol

VCUBE-2(config-track)#track 2 interface GigabitEthernet2 line-protocol

VCUBE-2(config-track)#exit

トラッキング CLI は、トラフィック インターフェイスがダウンした後、アクティブ ルートがアクティブな役割を果たすように、RG 内で音声トラフィックインターフェイスの状態を追跡するために使用されます。

2

アプリケーション冗長性サブモード下の VoIP HA で使用する RG を構成します。

redundancy
  application redundancy
   group 1
    name LocalGateway-HA
    priority 100 failover threshold 75
    control GigabitEthernet3 protocol 1
    data GigabitEthernet3
    timers delay 30 reload 60
    track 1 shutdown
    track 2 shutdown
    exit
   protocol 1
    timers hellotime 3 holdtime 10
   exit
  exit
 exit


VCUBE-1(config)#redundancy

VCUBE-1(config-red)#application redundancy

VCUBE-1(config-red-app)#group 1

VCUBE-1(config-red-app-grp)#name LocalGateway-HA

VCUBE-1(config-red-app-grp)#priority 100 failover threshold 75

VCUBE-1(config-red-app-grp)#control GigabitEthernet3 protocol 1

VCUBE-1(config-red-app-grp)#data GigabitEthernet3

VCUBE-1(config-red-app-grp)#timers delay 30 reload 60

VCUBE-1(config-red-app-grp)#track 1 shutdown

VCUBE-1(config-red-app-grp)#track 2 shutdown

VCUBE-1(config-red-app-grp)#exit

VCUBE-1(config-red-app)#protocol 1

VCUBE-1(config-red-app-prtcl)#timers hellotime 3 holdtime 10

VCUBE-1(config-red-app-prtcl)#exit

VCUBE-1(config-red-app)#exit

VCUBE-1(config-red)#exit

VCUBE-1(config)#

VCUBE-2(config)#redundancy

VCUBE-2(config-red)#application redundancy

VCUBE-2(config-red-app)#group 1

VCUBE-2(config-red-app-grp)#name LocalGateway-HA

VCUBE-2(config-red-app-grp)#priority 100 failover threshold 75

VCUBE-2(config-red-app-grp)#control GigabitEthernet3 protocol 1

VCUBE-1(config-red-app-grp)#data GigabitEthernet3

VCUBE-2(config-red-app-grp)#timers delay 30 reload 60

VCUBE-2(config-red-app-grp)#track 1 shutdown

VCUBE-2(config-red-app-grp)#track 2 shutdown

VCUBE-2(config-red-app-grp)#exit

VCUBE-2(config-red-app)#protocol 1

VCUBE-2(config-red-app-prtcl)#timers hellotime 3 holdtime 10

VCUBE-2(config-red-app-prtcl)#exit

VCUBE-2(config-red-app)#exit

VCUBE-2(config-red)#exit

VCUBE-2(config)#

この構成で使用されるフィールドの説明を次に示します。

  • redundancy—冗長性モードに入ります

  • application redundancy—アプリケーション冗長性構成モードに入ります

  • group—冗長性のあるアプリケーション グループ構成モードに入ります

  • name LocalGateway-HA— RG グループの名前を定義します

  • priority 100 failover threshold 75—RG の初期優先度とフェールオーバーしきい値を指定します

  • timers delay 30 reload 60—遅延およびリロードのため 2 回構成します

    • インターフェイスが起動した後、RG グループの初期設定と役割のネゴシエーションの遅延時間を示す遅延タイマーです。デフォルトは 30 秒です。 範囲は 0-10000 秒です

    • Reload—これは、リロード後の RG グループ初期設定と役割ネゴシエーションの遅延時間です。デフォルトは 60 秒です。 範囲は 0-10000 秒です

    • デフォルトのタイマーが推奨されていますが、これらのタイマーは、ネットワークのルーティングが安定した時点の後、RG プロトコルのネゴシエーションが行われることを保証するために、ルーターの起動/再読み込み中に発生する可能性がある追加のネットワーク集約遅延に合わせて調整される場合があります。 たとえば、フェールオーバー後に、新しいスタンバイに最大 20 秒間かかり、新しいアクティブから最初の RG HELLO パケットを確認する場合は、この遅延を考慮して、最初の RG HELLO パケットを「タイマー遅延 60 リロード 120」に調整する必要があります。

  • control GigabitEthernet3 protocol 1—keepalive および hello メッセージを 2 個の CUBE 間で交換するために使用されるインターフェイスを構成し、コントロール インターフェイスに接続するプロトコル インスタンスを指定し、冗長性アプリケーション プロトコル構成モードに入ります

  • data GigabitEthernet3—データ トラフィックのチェックポイントに使用されるインターフェイスを構成します

  • track—インターフェイスの RG グループ トラッキング

  • protocol 1—コントロール インターフェイスに接続するプロトコル インスタンスを指定し、冗長性のあるアプリケーション プロトコル構成モードに入ります

  • timers hellotime 3 holdtime 10—hellotime および holdtime の 2 つのタイマーを設定します

    • Hellotime— 連続する hello メッセージの間隔 (デフォルトで 3 秒)。 範囲は 250 ミリ秒から 254 秒です

    • Holdtime — Hello メッセージの受信と送信ルーターが失敗した推定の間隔。 この継続時間は、hello time (デフォルトの 10 秒より長くする必要があります) 以上である必要があります。 範囲は 750 ミリ秒から 255 秒です

      Holdtime タイマーを hellotime タイマーの最低 3 倍の値に設定することをお勧めします。

3

CUBE アプリケーションのボックス間の冗長性を有効にします。 以下の下にある以前の手順から RG を構成します： voice service voip です。 これにより、CUBE アプリケーションは冗長性プロセスをコントロールすることができます。 

voice service voip
   redundancy-group 1
   exit

VCUBE-1(config)#voice service voip

VCUBE-1(config-voi-serv)#redundancy-group 1

% Created RG 1 association with Voice B2B HA; reload the router for the new configuration to take effect

VCUBE-1(config-voi-serv)# exit

VCUBE-2(config)#voice service voip

VCUBE-2(config-voi-serv)#redundancy-group 1

% Created RG 1 association with Voice B2B HA; reload the router for the new configuration to take effect

VCUBE-2(config-voi-serv)# exit

redundancy-group 1—このコマンドを追加および削除するには、更新された構成を有効にするための再読み込みが必要です。 すべての構成が適用された後で、プラットフォームを再読み込みします。

4

以下に示すように、Gig1 と Gig2 インターフェイスをそれぞれの仮想 IP で構成し、冗長性インターフェイス識別子 (rii) を適用します。

VCUBE-1(config)#interface GigabitEthernet1

VCUBE-1(config-if)# redundancy rii 1

VCUBE-1(config-if)# redundancy group 1 ip 198.18.1.228 exclusive

VCUBE-1(config-if)# exit

VCUBE-1(config)#

VCUBE-1(config)#interface GigabitEthernet2

VCUBE-1(config-if)# redundancy rii 2

VCUBE-1(config-if)# redundancy group 1 ip 198.18.133.228 exclusive

VCUBE-1(config-if)# exit

VCUBE-2(config)#interface GigabitEthernet1

VCUBE-2(config-if)# redundancy rii 1

VCUBE-2(config-if)# redundancy group 1 ip 198.18.1.228 exclusive

VCUBE-2(config-if)# exit

VCUBE-2(config)#

VCUBE-2(config)#interface GigabitEthernet2

VCUBE-2(config-if)# redundancy rii 2

VCUBE-2(config-if)# redundancy group 1 ip 198.18.133.228 exclusive

VCUBE-v(config-if)# exit

この構成で使用されるフィールドの説明を次に示します。

  • redundancy rii—冗長性グループの冗長性インターフェイス ID を構成します。 仮想 MAC (VMAC) アドレスを生成するために必要です。 同じ VIP を持つ各ルーター (アクティブ/スタンバイ) のインターフェイスで同じ rii ID 値を使用する必要があります。


     

    同一の LAN に複数の B2B ペアがある場合、各ペアはそれぞれのインターフェイスで固有の rii Id を持つ必要があります (衝突を防ぐため)。 [冗長性アプリケーショングループのすべてを表示] が正しいローカルとピアの情報を示している必要があります。

  • redundancy group 1—上記の手順 2 で作成された冗長性グループにインターフェイスを関連付けます。 RG グループ、およびこの物理インターフェイスに割り当てられた VIP を構成します。


     

    冗長性のために別のインターフェイスを使用することが必須です。つまり、音声トラフィックに使用されるインターフェイスは、上記の手順 2 で指定したコントロールとデータ インターフェイスとして使用できません。 この例では、RG コントロール/データにギガビット インターフェイス 3 が使用されています。

5

最初の CUBE 構成を保存し、再読み込みします。

最後にリロードするプラットフォームは常にスタンバイです。

VCUBE-1#wr

Building configuration...

[OK]

VCUBE-1#reload

Proceed with reload? [confirm]

VCUBE-1 が完全に起動したら、 VCUBE-2 の構成を保存し、再読み込みします。

VCUBE-2#wr

Building configuration...

[OK]

VCUBE-2#reload

Proceed with reload? [confirm]
6

ボックス間の構成が期待どおりに機能していることを確認します。 関連する出力は太字で強調表示されます。

VCUBE-2 を最後にリロードし、設計上の考慮事項に従います。最後にリロードするプラットフォームは常に [スタンバイ] 状態です。


VCUBE-1#show redundancy application group all
Faults states Group 1 info:
       Runtime priority: [100]
               RG Faults RG State: Up.
                       Total # of switchovers due to faults:           0
                       Total # of down/up state changes due to faults: 0
Group ID:1
Group Name:LocalGateway-HA
  
Administrative State: No Shutdown
Aggregate operational state: Up
My Role: ACTIVE
Peer Role: STANDBY
Peer Presence: Yes
Peer Comm: Yes
Peer Progression Started: Yes

RF Domain: btob-one
         RF state: ACTIVE
         Peer RF state: STANDBY HOT

RG Protocol RG 1
------------------
        Role: Active
        Negotiation: Enabled
        Priority: 100
        Protocol state: Active
        Ctrl Intf(s) state: Up
        Active Peer: Local
        Standby Peer: address 10.1.1.2, priority 100, intf Gi3
        Log counters:
                role change to active: 1
                role change to standby: 1
                disable events: rg down state 0, rg shut 0
                ctrl intf events: up 1, down 0, admin_down 0
                reload events: local request 0, peer request 0

RG Media Context for RG 1
--------------------------
        Ctx State: Active
        Protocol ID: 1
        Media type: Default
        Control Interface: GigabitEthernet3
        Current Hello timer: 3000
        Configured Hello timer: 3000, Hold timer: 10000
        Peer Hello timer: 3000, Peer Hold timer: 10000
        Stats:
            Pkts 1509, Bytes 93558, HA Seq 0, Seq Number 1509, Pkt Loss 0
            Authentication not configured
            Authentication Failure: 0
            Reload Peer: TX 0, RX 0
            Resign: TX 0, RX 0
    Standy Peer: Present. Hold Timer: 10000
            Pkts 61, Bytes 2074, HA Seq 0, Seq Number 69, Pkt Loss 0

VCUBE-1#

VCUBE-2#show redundancy application group all
Faults states Group 1 info:
       Runtime priority: [100]
               RG Faults RG State: Up.
                       Total # of switchovers due to faults:           0
                       Total # of down/up state changes due to faults: 0
Group ID:1
Group Name:LocalGateway-HA
  
Administrative State: No Shutdown
Aggregate operational state: Up
My Role: STANDBY
Peer Role: ACTIVE
Peer Presence: Yes
Peer Comm: Yes
Peer Progression Started: Yes

RF Domain: btob-one
         RF state: ACTIVE
         Peer RF state: STANDBY HOT

RG Protocol RG 1
------------------
        Role: Active
        Negotiation: Enabled
        Priority: 100
        Protocol state: Active
        Ctrl Intf(s) state: Up
        Active Peer: address 10.1.1.2, priority 100, intf Gi3
        Standby Peer: Local
        Log counters:
                role change to active: 1
                role change to standby: 1
                disable events: rg down state 0, rg shut 0
                ctrl intf events: up 1, down 0, admin_down 0
                reload events: local request 0, peer request 0

RG Media Context for RG 1
--------------------------
        Ctx State: Active
        Protocol ID: 1
        Media type: Default
        Control Interface: GigabitEthernet3
        Current Hello timer: 3000
        Configured Hello timer: 3000, Hold timer: 10000
        Peer Hello timer: 3000, Peer Hold timer: 10000
        Stats:
            Pkts 1509, Bytes 93558, HA Seq 0, Seq Number 1509, Pkt Loss 0
            Authentication not configured
            Authentication Failure: 0
            Reload Peer: TX 0, RX 0
            Resign: TX 0, RX 0
    Standy Peer: Present. Hold Timer: 10000
            Pkts 61, Bytes 2074, HA Seq 0, Seq Number 69, Pkt Loss 0

VCUBE-2#

両方の CUBE でローカル ゲートウェイを構成する

この例の構成では、Control Hub から以下のトランク情報を使用して、VCUBE-1、VCUBE-2 の両方のプラットフォームでローカルゲートウェイを構成しています。 この設定のユーザー名とパスワードは以下のとおりです。

  • ユーザー名: フセイン1076_LGU

  • パスワード: lOV12MEaZx

1

クレデンシャルまたは共有秘密で使用する前に、以下のコマンドを使用して、設定キーがパスワードに対して作成されていることを確認してください。 Type 6 パスワードは、AES 暗号化とこのユーザー定義の設定キーを使用して暗号化されます。


LocalGateway#conf t
LocalGateway(config)#key config-key password-encrypt Password123
LocalGateway(config)#password encryption aes

これは、上に表示されている Control Hub のパラメーターに基づき、両方のプラットフォームに適用し、保存し、リロードするローカ ルゲートウェイの構成です。 Control Hub からの SIP ダイジェスト クレデンシャルは太字でハイライトされています。


configure terminal
crypto pki trustpoint dummyTp
revocation-check crl
exit
sip-ua
crypto signaling default trustpoint dummyTp cn-san-validate server
transport tcp tls v1.2
end


configure terminal
crypto pki trustpool import clean url
http://www.cisco.com/security/pki/trs/ios_core.p7b
end


configure terminal
voice service voip
  ip address trusted list
    ipv4 x.x.x.x y.y.y.y
    exit
   allow-connections sip to sip
  media statistics
  media bulk-stats
  no supplementary-service sip refer
  no supplementary-service sip handle-replaces
  fax protocol pass-through g711ulaw
  stun
    stun flowdata agent-id 1 boot-count 4
    stun flowdata shared-secret 0 Password123!
  sip
    g729 annexb-all
    early-offer forced
    end


configure terminal
voice class sip-profiles 200
  rule 9 request ANY sip-header SIP-Req-URI modify "sips:(.*)"
"sip:\1"
  rule 10 request ANY sip-header To modify "<sips:(.*)" "<sip:\1"
  rule 11 request ANY sip-header From modify "<sips:(.*)" "<sip:\1"
  rule 12 request ANY sip-header Contact modify "<sips:(.*)>"
"<sip:\1;transport=tls>"
  rule 13 response ANY sip-header To modify "<sips:(.*)" "<sip:\1"
  rule 14 response ANY sip-header From modify "<sips:(.*)" "<sip:\1"
  rule 15 response ANY sip-header Contact modify "<sips:(.*)"
"<sip:\1"
  rule 20 request ANY sip-header From modify ">"
";otg=hussain1076_lgu>"
  rule 30 request ANY sip-header P-Asserted-Identity modify
"sips:(.*)" "sip:\1"


voice class codec 99
  codec preference 1 g711ulaw
  codec preference 2 g711ulaw
  exit

voice class srtp-crypto 200
  crypto 1 AES_CM_128_HMAC_SHA1_80
  exit

voice class stun-usage 200
  stun usage firewall-traversal flowdata
  exit






voice class tenant 200
  registrar dns:40462196.cisco-bcld.com scheme sips expires 240
refresh-ratio 50 tcp tls
  credentials number Hussain5091_LGU username Hussain1076_LGU
password 0 lOV12MEaZx realm Broadworks 
  authentication username Hussain5091_LGU password 0 lOV12MEaZx
realm BroadWorks

  authentication username Hussain5091_LGU password 0 lOV12MEaZx
realm 40462196.cisco-bcld.com
  no remote-party-id
  sip-server dns:40462196.cisco-bcld.com
  connection-reuse
  srtp-crypto 200
  session transport tcp tls
  url sips
  error-passthru
  asserted-id pai
  bind control source-interface GigabitEthernet1
  bind media source-interface GigabitEthernet1
  no pass-thru content custom-sdp
  sip-profiles 200
  outbound-proxy dns:la01.sipconnect-us10.cisco-bcld.com
  privacy-policy passthru


voice class tenant 100
  session transport udp
  url sip
  error-passthru
  bind control source-interface GigabitEthernet2
  bind media source-interface GigabitEthernet2
  no pass-thru content custom-sdp

voice class tenant 300
  bind control source-interface GigabitEthernet2
  bind media source-interface GigabitEthernet2
  no pass-thru content custom-sdp
  

voice class uri 100 sip
 host ipv4:198.18.133.3

voice class uri 200 sip
 pattern dtg=hussain1076.lgu



dial-peer voice 101 voip
 description Outgoing dial-peer to IP PSTN
 destination-pattern BAD.BAD
 session protocol sipv2
 session target ipv4:198.18.133.3
 voice-class codec 99
 voice-class sip tenant 100
 dtmf-relay rtp-nte
 no vad

dial-peer voice 201 voip
 description Outgoing dial-peer to Webex Calling
 destination-pattern BAD.BAD
 session protocol sipv2
 session target sip-server
 voice-class codec 99
 voice-class stun-usage 200
 no voice-class sip localhost
 voice-class sip tenant 200
 dtmf-relay rtp-nte
 srtp
 no vad


voice class dpg 100
 description Incoming WebexCalling(DP200) to IP PSTN(DP101)
 dial-peer 101 preference 1

voice class dpg 200
 description Incoming IP PSTN(DP100) to Webex Calling(DP201)
 dial-peer 201 preference 1





dial-peer voice 100 voip
 desription Incoming dial-peer from IP PSTN
 session protocol sipv2
 destination dpg 200
 incoming uri via 100
 voice-class codec 99
 voice-class sip tenant 300
 dtmf-relay rtp-nte
 no vad

dial-peer voice 200 voip
 description Incoming dial-peer from Webex Calling
 session protocol sipv2
 destination dpg 100
 incoming uri request 200
 voice-class codec 99
 voice-class stun-usage 200
 voice-class sip tenant 200
 dtmf-relay rtp-nte
 srtp
 no vad

end

copy run start

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-1#show redundancy application group 1
Group ID:1
Group Name:LocalGateway-HA

Administrative State: No Shutdown
Aggregate operational state : Up
My Role: Standby
Peer Role: ACTIVE
Peer Presence: Yes
Peer Comm: Yes
Peer Progression Started: Yes

RF Domain: btob-one
         RF state: STANDBY HOT
         Peer RF state: ACTIVE

VCUBE-1#show sip-ua register status
VCUBE-1#


VCUBE-2#show redundancy application group 1
Group ID:1
Group Name:LocalGateway-HA

Administrative State: No Shutdown
Aggregate operational state : Up
My Role: ACTIVE
Peer Role: STATUS
Peer Presence: Yes
Peer Comm: Yes
Peer Progression Started: Yes

RF Domain: btob-one
         RF state: ACTIVE
         Peer RF state: STANDBY HOT

VCUBE-2#show sip-ua register status

Tenant: 200
--------------------Registrar-Index  1 ---------------------
Line                           peer       expires(sec) reg survival P-Associ-URI
============================== ========== ============ === ======== ============
Hussain5091_LGU                -1          48          yes normal
VCUBE-2#

上記の出力から、 VCUBE-2 がアクティブ LGW で、Webex Calling アクセス SBC への登録を維持していることがわかります。しかし、「show sip-ua register status」の出力は VCUBE-1 では空です

3

VCUBE-1 で次のデバッグを有効にします


VCUBE-1#debug ccsip non-call
SIP Out-of-Dialog tracing is enabled
VCUBE-1#debug ccsip info
SIP Call info tracing is enabled
VCUBE-1#debug ccsip message
4

この場合、アクティブ LGW、VCUBE-2 で次のコマンドを実行してフェールオーバーをシミュレートします。


VCUBE-2#redundancy application reload group 1 self

アクティブからスタンバイ LGW への切り替えは、上記に一覧表示されている CLI に加えて、以下のシナリオで発生します。

  • アクティブ ルーターのリロード時

  • アクティブなルーターの電源が再投入される時

  • トラッキングが有効になっているアクティブなルーターの RG 構成されたインターフェイスがシャットダウンされる時

5

VCUBE-1 が Webex Calling アクセス SBC に登録されているかどうかを確認します。 VCUBE-2 は今すぐにリロードされます。


VCUBE-1#show sip-ua register status

Tenant: 200
--------------------Registrar-Index  1 ---------------------
Line                           peer       expires(sec) reg survival P-Associ-URI
============================== ========== ============ === ======== ============
Hussain5091_LGU                -1          56          yes normal
VCUBE-1#

VCUBE-1 がアクティブ LGW になりました。

6

仮想 IP を通じて SIP REGISTER を Webex Calling に送信し、200 OK を受信する VCUBE-1 に関連するデバッグ ログを確認してください。


VCUBE-1#show log

Jan 9 18:37:24.769: %RG_MEDIA-3-TIMEREXPIRED: RG id 1 Hello Time Expired.
Jan 9 18:37:24.771: %RG_PROTCOL-5-ROLECHANGE: RG id 1 role change from Standby to Active
Jan 9 18:37:24.783: %VOICE_HA-2-SWITCHOVER_IND: SWITCHOVER, from STANDBY_HOT to ACTIVE state.
Jan 9 18:37:24.783: //-1/xxxxxxxxxxxx/SIP/Info/info/4096/sip_ha_notify_active_role_event: Received notify active role event

Jan 9 18:37:25.758: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
REGISTER sip: 40462196.cisco-bcld.com:5061 SIP/2.0
Via: SIP/2.0/TLS 198.18.1.228:5061;branch=z9hG4bK0374
From: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189
To: <sip:Hussain5091_LGU@40462196.cisco-bcld.com>
Date: Thu, 09 Jan 2020 18:37:24 GMT
Call-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97
User-Agent: Cisco-SIPGateway/IOS-16.12.02
Max-Forwards: 70
Timestamp: 1578595044
CSeq: 2 REGISTER
Contact: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls>
Expires: 240
Supported: path
Content-Length: 0


Jan 9 18:37:25.995: //-1/000000000000/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 401 Unauthorized
Via: SIP/2.0/TLS 198.18.1.228:5061;received=173.38.218.1;branch=z9hG4bK0374;rport=4742
From: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189
To: <sip:Hussain5091_LGU@40462196.cisco-bcld.com>;tag=SD1u8bd99-1324701502-1578595045969
Date: Thu, 09 Jan 2020 18:37:24 GMT
Call-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97
Timestamp: 1578595044
CSeq: 2 REGISTER
WWW-Authenticate; DIGEST realm="BroadWorks",qop="auth",nonce="BroadWorksXk572qd01Ti58zliBW",algorithm=MD5
Content-Length: 0


Jan 9 18:37:26.000: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
REGISTER sip:40462196.cisco-bcld.com:5061 SIP/2.0
Via: SIP/2.0/TLS 198.18.1.228:5061;branch=z9hG4bK16DC
From: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189
To: <sip:Hussain5091_LGU@40462196.cisco-bcld.com>
Date: Thu, 09 Jan 2020 18:37:25 GMT
Call-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97
User-Agent:Cisco-SIPGateway/IOS-16.12.02
Max-Forwards: 70
Timestamp: 1578595045
CSeq: 3 REGISTER
Contact: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls>
Expires: 240
Supported: path
Authorization: Digest username="Hussain1076_LGU",realm="BroadWorks",uri="sips:40462196.cisco-bcld.com:5061",response="b6145274056437b9c07f7ecc08ebdb02",nonce="BroadWorksXk572qd01Ti58z1iBW",cnonce="3E0E2C4D",qop=auth,algorithm=MD5,nc=00000001
Content-Length: 0


Jan 9 18:37:26.190: //1/000000000000/SIP/Msg/ccsipDisplayMsg:

Received:
SIP/2.0 200 OK
Via: SIP/2.0/TLS 198.18.1.228:5061;received=173.38.218.1;branch=z9hG4bK16DC;rport=4742
From: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189
To: <sip:Hussain5091_LGU@40462196.cisco-bcld.com>;tag=SD1u8bd99-1897486570-1578595-46184
Call-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97
Timestamp: 1578595045
CSeq: 3 REGISTER
Contact: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls>;expires=120;q=0.5
Allow-Events: call-info,line-seize,dialog,message-summary,as-feature-event,x-broadworks-hoteling,x-broadworks-call-center-status,conference
Content-Length: 0
Webex Calling のために Unified CM を構成する

ローカル ゲートウェイへトランクするための SIP トランク セキュリティ プロファイルを構成する

ローカル ゲートウェイと PSTN ゲートウェイが同じデバイス上に存在する場合、Unified CM を有効にして、同じデバイスから発信された 2 個の異なるトラフィックの種類 (Webex と PSTN のコール) を区別し、これらのコール タイプに対して差別化されたクラスのサービスを適用する必要があります。 この差別化されたコール処理は、Unified CM および結合されたローカル ゲートウェイと PSTN ゲートウェイ デバイスの 2 つのトランクをプロビジョニングすることで行われます。これは、2 つのトランクに異なる SIP リスニング ポートを必要とします。

次の設定でローカル ゲートウェイ トランクの専用の SIP トランク セキュリティ プロファイルを作成します。

設定値
名前固有の名前 (Webex など)
説明Webex SIP トランク セキュリティ プロファイルなどの意味のある説明
着信ポートWebex 間のトラフィックでは、ローカル ゲートウェイ構成で使用されるポートと一致する必要があります。 5065

ローカル ゲートウェイ トランクの SIP プロファイルを構成する

次の設定でローカル ゲートウェイ トランク用の専用の SIP プロファイルを作成します。

設定値
名前固有の名前 (Webex など)
説明意味のある説明 (Webex SIP プロファイルなど)
オプションの Ping を有効にして、サービス タイプ「なし (デフォルト)」のトランクの宛先ステータスをモニタします。選択

Webex からのコールのコール検索スペースを作成する

次の設定で Webex から発信されたコールのためのコール検索スペースを作成します。

設定値
名前固有の名前 (Webex など)
説明意味のある説明 (Webex Calling 検索スペースなど)
選択済みパーティション:

DN (+E.164 ディレクトリ番号)

ESN (省略形のサイトダイヤル)

PSTNInternational (PSTN アクセス)

onNetRemote (GDPR 学習先)


 

最後のパーティション onNetRemote は、Intercluster Lookup Service (ILS) または Global Dialplan Replication (GDPR) を使用して、Unified CM クラスター間でルーティング情報が交換されるマルチクラスター環境でのみ使用されます。

Webex 間で SIP トランクを構成する

次の設定を使用して、ローカル ゲートウェイ経由での Webex 間のコールに SIP トランクを作成します。

設定値
デバイス情報
DeviceName固有の名前 (Webex など)
説明意味のある説明 (Webex SIP トランク など)
すべてのアクティブな Unified CM ノード上で実行する選択
着信コール
コール検索スペース以前に定義されたコール検索スペース: Webex
AAR コール検索スペースPSTN ルート パターンへのアクセス権のみを持つコール検索スペース: PSTNReroute
SIP 情報
接続先アドレスローカル ゲートウェイ CUBE の IP アドレス
移動先ポート5060
SIP トランク セキュリティ プロファイル定義済み: Webex
SIP プロファイル定義済み: Webex

Webex のルート グループを構成する

次の設定でルート グループを作成します。

設定値
ルート グループ情報
ルート グループ名固有の名前 (Webex など)
選択したデバイス以前に構成された SIP トランク: Webex

Webex のルート リストを構成する

次の設定でルート リストを作成します。

設定値
ルート リスト情報
名前一意の名前 (RL_Webex など)
説明意味のある説明 (Webex のルート リストなど)
すべてのアクティブな Unified CM ノード上で実行する選択
ルート リスト メンバー情報
選択したグループ以前に定義されたルート グループのみ: Webex

Webex の移動先のパーティションを作成する

次の設定で Webex の移動先のパーティションを作成します。

設定値
ルート リスト情報
名前固有の名前 (Webex など)
説明意味のある説明 (Webex のパーティションなど)

次に行うこと

このパーティションは、Webex の宛先にアクセスする必要があるすべてのコール検索スペースに追加してください。 このパーティションは、PSTN から Webex への発信がルーティングされるように、PSTN トランクの着信コール検索スペースとして使用されるコール検索スペースに特に追加する必要があります。

Webex の移動先のルート パターンを構成する

次の設定で Webex の各 DID 範囲のルート パターンを構成します。

設定値
ルートパターン「\」が頭文字にある Webex で DID 範囲のフル +E.164 パターン 例: \+140855501XX
ルート パーティションWebex
ゲートウェイ/ルート リストRL_Webex
緊急の優先事項選択

Webex の簡略サイト間ダイヤル正規化を構成する

短縮されたサイト間ダイヤルが Webex に必要な場合は、Webex の各 ESB 範囲にダイヤル正規化パターンを設定します。

設定値
翻訳パターンWebex の ESN 範囲の ESB パターン。 例: 80121XX
パーティションWebex
説明Webex の正規化パターンなどの意味のある説明
発信者のコール検索スペースを使用する選択
緊急の優先事項選択
後続ホップでの連続桁のタイムアウトを待たない選択
着信側トランスフォーム マスク番号を + E.164 に正規化するマスク。 例: +140855501XXさん

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

このユーザーがコールに割り込むときに他のユーザーにトーンを再生する場合は、[このユーザーがコールで割り込むときにトーンを再生] にチェックを入れます。

6

[保存] をクリックします。

ユーザーのプライバシーを有効にする

1

Control Hubにサインインし、管理 > ユーザー。

2

ユーザーを選択し、[Calling] をクリックします。

3

［ユーザー権限間］領域に移動し、［プライバシー］を選択します。

4

このユーザーに適切な　[自動音声応答のプライバシー] 設定を選択します。

  • このユーザーへの内線でのダイヤルを許可
  • このユーザーの名前/姓でのダイヤルを許可
5

[プライバシーを有効にする] チェックボックスをオンにします。 ドロップダウンリストからメンバーを選択しないことで、全員をブロックすることができます。 または、このユーザーの回線ステータスを監視できるユーザー、ワークスペース、仮想回線を選択することもできます。

ロケーション管理者の場合、割り当てられたロケーションに関連するユーザー、ワークスペース、仮想回線だけがドロップダウン リストに表示されます。

[プライバシーを有効にする] チェックボックスをオフにすると、全員が回線のステータスを監視できるようになります。

6

ダイレクト コール ピックアップと割り込みのプライバシーを有効にするには、[ダイレクト コール ピックアップと割り込みのプライバシーを強制] チェックボックスをオンにします。


 
  • このオプションを有効にすると、このユーザーに対してダイレクト コール ピックアップと割り込みを使用できるのは、許可されたユーザー、仮想回線、およびワークスペース デバイスだけです。 それ以外の場合、組織内の誰もが、ダイレクト コール ピックアップと割り込みを回線上で呼び出すことができます。
  • 割り込みの詳細については、他のユーザーの電話での割り込みを参照してください。
  • スーパーバイザは、エージェントがコール キューを介して受信するコールに常に割り込むことができます。 つまり、プライバシー設定はスーパーバイザの割り込みオプションには影響しません。
7

[名前でメンバーを追加] から、電話回線のステータスを監視し、ダイレクト コール ピックアップと割り込みを呼び出せるユーザ、ワークスペース、仮想回線を選択します。

8

選択したメンバーをフィルタリングするには、［名前、番号、またはextでフィルタリング］フィールドを使用します。

9

選択したすべてのメンバーを削除するには、［すべて削除］をクリックします。


 
個々のメンバーを削除するには、メンバー名の横にある [削除] をクリックします。
10

[保存] をクリックします。

Privacy settings

モニタリングの設定

ユーザーの監視対象回線の最大数は 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）] フィールドに入力された名前です。

実際の例を見てみましょう。 これを視聴するビデオデモンストレーションでユーザーの監視設定を管理する方法コントロールハブを選択します。

ユーザーのコール ブリッジ警告トーンを有効にする

始める前に

呼び出されるCall Bridge用に共有回線を設定しておく必要があります。 参加方法を共有回線の設定必要に応じて、Call Bridge警告音の再生を有効にしてください。
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

通話履歴の詳細レポートを参照するには、コントロールハブを表示し、次に移動します。分析次のリンクをクリックしてください:電話を選択します。

2

選択詳細な通話履歴を選択します。

専用インスタンスを使用する通話の詳細については、「専用インスタンスの分析」を参照してください。

3

メディア品質データにアクセスするには、Control Hub にサインインし、[アナリティクス] に移動して、[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 注文ガイドのローカル ゲートウェイの表 1 を参照してください。また、ローカル ゲートウェイ設定ガイドに従って、プラットフォームがサポートされている IOS-XE リリースを実行していることを確認してください。

ローカル ゲートウェイは、自分のペースで 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

次のオプションから選択します:

  • パートナー管理者の場合は、[保存して閉じる] をクリックして、顧客管理者が Webex Calling のプロビジョニングを完了するようにします。
  • 必要なロケーションの情報を入力します。ウィザードでロケーションを作成した後、後で他にロケーションを作成できます。

セットアップ ウィザードを完了した後で、作成したロケーションにメイン番号を追加していることを確認してください。

7

このロケーションに適用する次の選択を行います。

  • Announcement Language—For audio announcements and prompts for new users and features.
  • Email Language—For email communication for new users.
  • 国
  • タイムゾーン
8

[次へ] をクリックします。

9

利用可能な Cisco Webex SIP アドレスを入力し、[次へ] をクリックし、[完了] を選択します。

ロケーションを追加する

始める前に

新しいロケーションを作成するには、以下の情報を指定します。

  • ロケーションの住所

  • 希望する電話番号(オプション)

1

Log in to Control Hub at https://admin.webex.com, go to Management > Location.

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

ロケーションを設定します。

  • Location Name—Enter a unique name to identify the location.
  • Country/Region—Choose a country to tie the location to. たとえば、米国に 1 か所のロケーション (本社) を作成し、イギリスに別のロケーション (支社) を作成することができます。選択した国に応じて、その後の住所のフィールドが決まります。ここには、例として、米国の住所書式を使用したものがあります。
  • Location Address—Enter the location's main mailing address.
  • City/Town—Enter a city for this location.
  • State/Province/Region—From the drop-down, choose a state.
  • ZIP/Postal Code—Enter the ZIP or postal code.
  • Announcement Language—Choose the language for audio announcements and prompts for new users and features.
  • Email Language—Choose the language for the email communication with new users.
  • Time zone—Choose the time zone for the location.
3

[保存 ] をクリックしてから、[ はい/いいえ ] を選択して、現在または後でロケーションに番号を追加します。

4

[はい] をクリック した場合、次のいずれかのオプションを選択します。

  • Cisco PSTN —Choose this option if you'd like a Cloud PSTN solution from Cisco. Cisco 通話プランは、緊急通話、着信、および国内および国際通話を提供する PSTN 代替ソリューションであり、新しい PSTN 番号または既存の番号を Cisco にポートすることができます。

    Cisco PSTN オプションは、以下の条件でのみ表示されます。

    • コミットされた Cisco Calling プラン OCP (アウトバウンド通話プラン) を少なくとも 1 つ購入している。

    • Cisco Calling プランがサポートされている国にロケーションがある。

    • ロケーションが新規である。他の PSTN 機能が割り当てられている既存のロケーションは、今回は Cisco Calling プランの対象外です。Open a support case for guidance.

    • You’re hosted in a Webex Calling Data Center in a region in which the Cisco Calling Plan is supported.

  • Cloud Connected PSTN—Choose this option if you’re looking for a cloud PSTN solution from one of the many Cisco CCP partners or if the Cisco Calling Plan isn't available in your location. CCP パートナーは、PSTN 代替ソリューション、グローバルな広域カバレッジ、広範でさまざまな機能、パッケージ、価格設定を提供しています。

    CCP パートナーと対応地域は、こちらにリストされています。ロケーションの国がサポートされているパートナーにのみ表示されています。パートナーは、ロゴで表示されるか、簡単な文字列と括弧で囲んだ地域名で表示されます (例: (EU)、(US)、または (CA))。ロゴが表示されているパートナーは、常に CCP の地域メディアを提供しています。文字列で表示されているパートナーについては、CCP の地域メディアを確保するために、ロケーションの国に最も近い地域を選択してください。

    リストされているプロバイダーの下に [番号を今すぐ注文する] オプションがある場合は、そのオプションを選択して、統合された CCP のメリットを利用することをおすすめします。統合された CCP の場合、電話番号の調達とプロビジョニングを Control Hub の 1 つのペインで行えます。統合されていない CCP の場合、Control Hub の外で、CCP パートナーから電話番号を調達する必要があります。

  • Premises-based PSTN (Local Gateway)—You can choose this option if you want to keep your current PSTN provider or you want to connect non-cloud sites with cloud sites.

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 Management > Location.

2

Click in the Actions column beside the location that you'd like to delete.

3

[場所 の削除] を選択し、その場所を削除します。

一般的に、場所が完全に削除されるには数分かかりますが、最大で 1 時間かかる場合があります。ステータスを確認するには、ロケーション名の隣にある をクリックして、[削除ステータス] を 選択します。

既存のロケーションを更新する

作成した後PSTNのセットアップ、名前、タイムゾーン、言語を変更できます。新しい言語は新しいユーザーとデバイスにのみ適用されることに注意してください。既存のユーザーおよびデバイスは古い言語を使用し続けます。

既存のロケーションについては、緊急時の 911 サービスを有効にすることができます。詳細については「Webex Calling の RedSky 緊急 911 サービス」を参照してください。

1

Log in to the Control Hub at https://admin.webex.com, go to Management > Location.

ロケーションの隣に [警告] 記号が表示される場合、そのロケーションの電話番号をまだ設定していないという意味です。その番号を設定するまで、通話の送受信が行えなんす。

2

(オプション) [PSTN 接続] の下で、すでに設定されているものに応じて、[クラウド接続 PSTN] または [プレミスベースの PSTN](ローカル ゲートウェイ) のいずれかを選択します。[管理] をクリックして設定を変更してから、[続行] を選択することにより、関連するリスクを承認します。以下のオプションのいずれかを選択して、[保存] クリックします。

  • Cisco PSTN —Choose this option if you'd like a Cloud PSTN solution from Cisco. Cisco 通話プランは、緊急通話、着信、および国内および国際通話を提供する PSTN 代替ソリューションであり、新しい PSTN 番号または既存の番号を Cisco にポートすることができます。

    Cisco PSTN オプションは、以下の条件でのみ表示されます。

    • コミットされた Cisco Calling プラン OCP (アウトバウンド通話プラン) を少なくとも 1 つ購入している。

    • Cisco Calling プランがサポートされている国にロケーションがある。

    • ロケーションが新規である。Currently, preexisting locations that have had other PSTN capabilities assigned aren't eligible for the Cisco Calling Plan.Open a support case for guidance.

    • You’re hosted in a Webex Calling Data Center in a region in which the Cisco Calling Plan is supported.

  • Cloud Connected PSTN—Choose this option if you’re looking for a cloud PSTN solution from one of the many Cisco CCP partners or if the Cisco Calling Plan isn't available in your location. CCP パートナーは、PSTN 代替ソリューション、グローバルな広域カバレッジ、広範でさまざまな機能、パッケージ、価格設定を提供しています。

    CCP パートナーと対応地域は、こちらにリストされています。ロケーションの国がサポートされているパートナーにのみ表示されています。パートナーは、ロゴで表示されるか、簡単な文字列と括弧で囲んだ地域名で表示されます (例: (EU)、(US)、または (CA))。ロゴが表示されているパートナーは、常に CCP の地域メディアを提供しています。文字列で表示されているパートナーについては、CCP の地域メディアを確保するために、ロケーションの国に最も近い地域を選択してください。

    If you see the option to Order numbers now under a listed provider, we recommend that you choose that option so that you can benefit from an integrated CCP. 統合された CCP の場合、電話番号の調達とプロビジョニングを Control Hub の 1 つのペインで行えます。Nonintegrated CCP requires you to procure your phone numbers from the CCP partner outside of Control Hub.

  • Premises-based PSTN (Local Gateway)—You can choose this option if you want to keep your current PSTN provider or you want to connect noncloud sites with cloud sites.

    Webex Calling ゲートウェイで以前に設定されたロケーションを持つ顧客は、対応するトランクを使用してオンプレミス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 Services > Calling > Service Settings, and then scroll to Internal Dialing.

2

必要に応じて、次のオプションのダイヤル設定を行います。

  • Location Routing Prefix Length—We recommend this setting if you've multiple locations. 2 ～ 7 桁の長さを入力できます。同じ内線番号を持つ複数のロケーションがある場合、ロケーション間でコールを行うときに、ユーザーはプレフィックスをダイヤルする必要があります。たとえば、複数のストアがある場合、内線 1000 を使用すると、各ストアにルーティング プレフィックスを設定することができます。1 つのストアのプレフィックスが 888 の場合、そのストアに到達するために 8881000 にダイヤルします。

    Routing prefix lengths include the steering digit. For example, if you set the routing prefix length to four, only three digits can be used to specify the site.

    If you assign a routing prefix to a location, all appearances of extensions assigned to that location include the routing prefix in front of the extension number. For example, 888-1000 (routing prefix-extension).

  • Steering Digit in Routing Prefix—Choose the number which will be set as the first digit of every routing prefix.
  • Internal Extension Length—You can enter 2-10 digits and the default is 2.

    After you increase your extension length, existing speed dials to internal extensions aren’t automatically updated.

  • Allow extension dialing between locations—Allows you to customize the extension dialing between locations based on your organization's requirements.

    • Enable the toggle if your organization doesn’t have duplicate extensions across all its locations.

      By default, the toggle is enabled.

    • Disable the toggle if your organization has the same extension in different locations. When the toggle is disabled and the caller dials the extension, the call is routed to a user with matching extension in the same location as the caller. The caller must dial the Enterprise Significant Number (location routing prefix + extension) to reach an extension in other locations.

3

特定の場所の内部ダイヤルを指定します。Go to Management > Locations, select a location from the list, and click Calling. Scroll to Dialing, and then change internal dialing as needed:

  • Internal Dialing—Specify the routing prefix that users at other locations need to dial in order to contact someone at this location. 各ロケーションのルーティング プレフィックスは固有である必要があります。We recommend that the prefix length matches the length set at the organization level but it must be 2–7 digits long.
4

Specify external dialing for specific locations. Go to Management > Locations, select a location from the list, and click Calling. Scroll to Dialing, and then change external dialing as needed:

  • External Dialing—You can choose an outbound dial digit that users must dial to reach an outside line. デフォルトは [なし] であり、このダイヤル習慣が必要ない場合には、値を [なし] にしておくことができます。この機能を使用しない場合、組織のステアリング番号とは別の番号を使用することをお勧めします。

    ユーザーは、外線発信を行う際に外線発信番号を含め、レガシー システムでダイヤルしていた方法を真似たものにできます。しかし、すべてのユーザーは、発信ダイアル番号なしで外部通話を発信することができます。

  • Optionally, you have the ability to Enforce dialing the outbound dial digit of this location, ensuring that the user must use the outbound dial digit set by the admin to place external calls.

    Emergency calls can still be dialed with or without the outbound dial digit when this feature is enabled.

    Once enabled, any external destination numbers such as those used for call forwarding will no longer work if an outbound dial digit isn’t included.

    If an extension is same as the national number, then the extension takes precedence over the national number. Hence, we recommend that you enable the outbound dial digit.
    We highly recommend using the E.164 numbering format for incoming and outgoing PSTN calls.

ユーザーへの影響:

  • Users must restart their phones for changes in dialing preferences to take effect.

  • User extensions shouldn’t start with the same number as the location's steering digit or outbound dial digits.

Control Hub でプレミス ベースの PSTN (ローカル ゲートウェイ) を設定する

付加価値再販業者の場合、これらの手順を使用して Control Hub でローカル ゲートウェイの設定を開始できます。このゲートウェイがクラウドに登録されると、Webex Calling の 1 つ以上のロケーションで使用して、エンタープライズ PSTN サービス プロバイダーへのルーティングを提供できます。

ローカル ゲートウェイがある場所は、ローカル ゲートウェイが他の場所で使用されているときには削除できません。

トランクを作成する
次の手順に従って、Control Hub でトランクを作成します。

始める前に

  • ロケーションが追加されたら、ロケーションに対してプレミスベース PSTN を設定する前に、トランクを作成する必要があります。

  • それぞれについて、ロケーションと固有の設定および番号を作成します。ロケーションはプレミスベース PSTN を追加する前に存在する必要があります。

  • Webex Calling でのプレミスベース PSTN (ローカル ゲートウェイ) 要件について理解しておいてください。

  • プレミスベース PSTN を持つロケーションに対して、複数のトランクを選択できませんが、複数のロケーションに対して同じトランクを選択することはできます。

1

Log in to Control Hub at https://admin.webex.com, go to Services > Calling > Call Routing, and select Add Trunk.

2

ロケーションを選択します。

3

トランクの名前を指定し、[保存] をクリックします。

名前は 24 文字以内にしてください。

次にやる必要

トランクで設定する必要がある、関連するパラメーターが表示されます。また、PSTN 接続をセキュアにするための SIP ダイジェスト資格情報のセットも生成します。

画面 [ドメインの登録]、[トランク グループ OTG/DTG]、[回線/ポート]、および [発信プロキシ アドレス] にトランク情報が表示されます。

プレミスベース PSTN を設定する準備ができているときに参照できるように、この情報を Control Hub からコピーして、ローカルのテキスト ファイルまたは文書に貼り付けておくことを推奨します。

この資格情報を紛失した場合には、Control Hub のトランク情報画面で生成する必要があります。[ユーザー名の取得とパスワードのリセット] をクリックして、トランクを使用するための認証資格情報の新しいセットを生成します。

プレミス ベースの PSTN のトランクを選択する
1

Log in to Control Hub at https://admin.webex.com, go to Management > Location.

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 Services > Call > Locations 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 で電話番号を管理する」を参照してください。

Control Hub でトライアルからの Webex サービス購入をリクエストする

Webex サービスを試していて、トライアルから有料サブスクリプションに変更したい場合は、メールでパートナーにリクエストできます。

1

Log in to Control Hub at https://admin.webex.com, select the building icon .

2

[サブスクリプション] タブを選択し、[今すぐ購入] をクリックします。

有料サブスクリプションへの変換に興味を持っていることを知らせるメールがパートナーに送信されます。

Set calling options

Control Hub を使用して、Webex アプリでユーザーに表示する利用可能な通話オプションの優先度を設定できます。シングルクリック通話を有効にすることもできます。詳細については、こちらを参照してください:Set calling options for Webex App users.

Set up calling behavior

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

Key considerations

  • 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.

The procedures contain links to command reference documentation where you can learn more about the individual command options. All command reference links go to the Webex Managed Gateways Command Reference unless stated otherwise (in which case, the command links go to Cisco IOS Voice Command Reference). You can access all these guides at Cisco Unified Border Element Command References.

For information on the supported third-party SBCs, refer to the respective product reference documentation.

Configure your Local Gateway

システム トランクのローカル ゲートウェイを設定するための 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.

Key considerations

Local Gateway for Webex for Government doesn’t support the following:

  • STUN/ICE-Lite for media path optimization

  • Fax (T.38)

Configure your Local Gateway for Webex for Government

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.

Webex for Government doesn’t support registration-based Local Gateway.

Design overview

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.

Call routing from/to PSTN to/from Webex Calling configuration solution

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

Configure connectivity and security

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:

 interface GigabitEthernet0/0/0 description Interface facing PSTN and/or CUCM ip address 10.80.13.12 255.255.255.0 ! interface GigabitEthernet0/0/1 description Interface facing Webex Calling (Private address) ip address 192.51.100.1 255.255.255.240

2

Protect registration and STUN credentials on the router using symmetric encryption. Configure the primary encryption key and encryption type as follows:

 key config-key password-encrypt YourPassword password encryption aes

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.
 crypto pki trustpoint EmptyTP revocation-check none
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.

  1. Set tcp-retry count to 1000 (5-msec multiples = 5 seconds).

  2. The timer connection establish command allows you to tune how long the LGW waits to set up a connection with a proxy before considering the next available option. The default for this timer is 20 seconds and the minimum 5 seconds. Start with a low value and increase if necessary to accommodate network conditions.

 sip-ua timers connection establish tls 5 transport tcp tls v1.2 crypto signaling default trustpoint EmptyTP cn-san-validate server tcp-retry 1000

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
 ip http client source-interface GigabitEthernet0/0/1 crypto pki trustpool import clean url https://www.cisco.com/security/pki/trs/ios_core.p7b
Configure Webex Calling registration-based trunk
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:

 voice service voip ip address trusted list ipv4 x.x.x.x y.y.y.y mode border-element media statistics media bulk-stats allow-connections sip to sip no supplementary-service sip refer stun stun flowdata agent-id 1 boot-count 4 stun flowdata shared-secret 0 Password123$ sip asymmetric payload full early-offer forced

以下は、設定のフィールドの説明です。

 ip address trusted list  ipv4 x.x.x.x y.y.y.y

  • To protect against toll fraud, the trusted address list defines a list of hosts and networks from which the Local Gateway expects legitimate VoIP calls.

  • By default, Local Gateway blocks all incoming VoIP messages from IP addresses not in its trusted list. Statically configured dial-peers with “session target IP” or server group IP addresses are trusted by default, so do not need to be added to the trusted list.

  • When configuring your Local Gateway, add the IP subnets of your regional Webex Calling data center to the list. 詳細については、「Webex Calling のポート参照情報」を参照してください。Also, add address ranges for Unified Communications Manager servers (if used) and PSTN trunk gateways.

    If your LGW is behind a firewall with restricted cone NAT, you may prefer to disable the IP address trusted list on the Webex Calling facing interface. ファイアウォールはすでに、未承諾のインバウンドメッセージから保護VoIP。[無効にする] アクションは、Webex Calling ピアのアドレスが固定されたままである保証を保証できないので、長期構成のオーバーヘッドを削減します。また、いかなる場合にも、ピアに対してファイアウォールを構成する必要があります。

mode border-element

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 sip

Enable 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).

stun

Enables STUN (Session Traversal of UDP through NAT) globally.

  • 通話を Webex Calling ユーザーに転送する場合 ( 例えば、通話側と通話側の両当事者が Webex Calling のサブスクライバーであり、Webex Calling SBC にメディアを固定する場合)、メディアはピンホールが開いていないので、ローカル ゲートウェイにフローできません。

  • The STUN bindings feature on the Local Gateway allows locally generated STUN requests to be sent over the negotiated media path. This helps to open the pinhole in the firewall.

For more information, see stun flowdata agent-id and stun flowdata shared-secret.

asymmetric payload full

Configures SIP asymmetric payload support for both DTMF and dynamic codec payloads. For more information on this command, see asymmetric payload.

early-offer forced

Forces 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 100 codec preference 1 opus codec preference 2 g711ulaw codec preference 3 g711alaw

以下は、設定のフィールドの説明です。

voice class codec 100

Used 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.

 voice class stun-usage 100 stun usage firewall-traversal flowdata stun usage ice lite

以下は、設定のフィールドの説明です。

stun usage ice lite

Used 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 100 crypto 1 AES_CM_128_HMAC_SHA1_80

以下は、設定のフィールドの説明です。

voice class srtp-crypto 100

Specifies 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 sip pattern dtg=Dallas1463285401_LGU

以下は、設定のフィールドの説明です。

voice class uri 100 sip

Defines 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.

 voice class sip-profiles 100 rule 10 request ANY sip-header SIP-Req-URI modify "sips:" "sip:" rule 20 request ANY sip-header To modify "<sips:" "<sip:" rule 30 request ANY sip-header From modify "<sips:" "<sip:" rule 40 request ANY sip-header Contact modify "<sips:(.*)>" "<sip:\1;transport=tls>" rule 50 response ANY sip-header To modify "<sips:" "<sip:" rule 60 response ANY sip-header From modify "<sips:" "<sip:" rule 70 response ANY sip-header Contact modify "<sips:" "<sip:" rule 80 request ANY sip-header From modify ">" ";otg=dallas1463285401_lgu>" rule 90 request ANY sip-header P-Asserted-Identity modify "sips:" "sip:"

以下は、設定のフィールドの説明です。

  • rule 10 to 70 and 90

    Ensures that SIP headers used for call signaling use the sip, rather than sips scheme, which is required by Webex proxies. Configuring CUBE to use sips ensures that secure registration is used.

  • rule 80

    Modifies the From header to include the trunk group OTG/DTG identifier from Control Hub to uniquely identify a Local Gateway site within an enterprise.

8

Configure Webex Calling trunk:

  1. Create voice class tenant 100 to define and group configurations required specifically for the Webex Calling trunk. In particular, the trunk registration details provided in Control Hub earlier will be used in this step as detailed below. Dial-peers associated with this tenant later will inherit these configurations.

    The following example uses the values illustrated in Step 1 for the purpose of this guide (shown in bold). Replace these with values for your trunk in your configuration.

     voice class tenant 100 registrar dns:98027369.us10.bcld.webex.com scheme sips expires 240 refresh-ratio 50 tcp tls credentials number Dallas1171197921_LGU username Dallas1463285401_LGU password 0 9Wt[M6ifY+ realm BroadWorks authentication username Dallas1463285401_LGU password 0 9Wt[M6ifY+ realm BroadWorks authentication username Dallas1463285401_LGU password 0 9Wt[M6ifY+ realm 98027369.us10.bcld.webex.com no remote-party-id sip-server dns:98027369.us10.bcld.webex.com connection-reuse srtp-crypto 100 session transport tcp tls url sips error-passthru asserted-id pai bind control source-interface GigabitEthernet0/0/1 bind media source-interface GigabitEthernet0/0/1 no pass-thru content custom-sdp sip-profiles 100 outbound-proxy dns:dfw04.sipconnect-us.bcld.webex.com privacy-policy passthru

    以下は、設定のフィールドの説明です。

    voice class tenant 100

    Defines a set of configuration parameters that will be used only for the Webex Calling trunk. For more information, see voice class tenant.

    registrar dns:98027369.us10.bcld.webex.com scheme sips expires 240 refresh-ratio 50 tcp tls

    ローカル ゲートウェイの登録サーバーで、2 分ごとに更新が設定されている場合 (240 秒の 50%)。For more information, see registrar.

    Ensure that you use the Register Domain value from Control Hub here.

    credentials number Dallas1171197921_LGU username Dallas1463285401_LGU password 0 9Wt[M6ifY+ realm BroadWorks

    トランク登録認証の資格情報。For more information, see credentials (SIP UA).

    Ensure that you use the Line/Port host, Authentication Username and Authentication Password values respectively from Control Hub here.

    authentication username Dallas1171197921_LGU password 0 9Wt[M6ifY+ realm BroadWorks
    authentication username Dallas1171197921_LGU password 0 9Wt[M6ifY+ realm 98027369.us10.bcld.webex.com

    コールの認証の課題。For more information, see authentication (dial-peer).

    Ensure that you use the Authentication Username, Authentication Password and Registrar Domain values respectively from Control Hub here.

    no remote-party-id

    Disable SIP Remote-Party-ID (RPID) header as Webex Calling supports PAI, which is enabled using CIO asserted-id pai. For more information, see remote-party-id.

    sip-server dns:us25.sipconnect.bcld.webex.com

    Configures the target SIP server for the trunk. Use the edge proxy SRV address provided in Control Hub when you created your trunk.

    connection-reuse

    登録と通話処理に同じ永続的な接続を使用します。For more information, see connection-reuse.

    srtp-crypto 100

    Configures the preferred cipher-suites for the SRTP call leg (connection) (specified in step 5). For more information, see voice class srtp-crypto.

    session transport tcp tls

    TLS へのトランスポートを設定します。For more information, see session-transport.

    url sips

    SRVは、アクセス SBC によりサポートされている SIP である必要があります。その他のすべてのメッセージは、sip-profile 200 により SIP に変更されます。

    error-passthru

    SIP エラー応答パススルー機能を指定します。For more information, see error-passthru.

    asserted-id pai

    ローカル ゲートウェイで簡単に処理をオンにする。For more information, see asserted-id.

    bind control source-interface GigabitEthernet0/0/1

    Configures the source interface and associated IP address for messages sent to WebexCalling. For more information, see bind.

    bind media source-interface GigabitEthernet0/0/1

    Configures the source interface and associated IP address for media sent to WebexCalling. For more information, see bind.

    no pass-thru content custom-sdp

    テナントの下のデフォルト コマンド。For more information on this command, see pass-thru content.

    sip-profiles 100

    Changes SIPs to SIP and modify Line/Port for INVITE and REGISTER messages as defined in sip-profiles 100. For more information, see voice class sip-profiles.

    outbound-proxy dns:dfw04.sipconnect-us.bcld.webex.com

    Webex Calling SBC にアクセスします。Insert the Outbound Proxy Address provided in Control Hub when you created your trunk. For more information, see outbound-proxy.

    privacy-policy passthru

    Configures the privacy header policy options for the trunk to pass privacy values from the received message to the next call leg. For more information, see privacy-policy.

  2. Configure the Webex Calling trunk dial-peer. 

     dial-peer voice 100 voip description Inbound/Outbound Webex Calling max-conn 250 destination-pattern BAD.BAD session protocol sipv2 session target sip-server incoming uri request 100 voice-class codec 100 dtmf-relay rtp-nte voice-class stun-usage 100 no voice-class sip localhost voice-class sip tenant 100 srtp no vad

    以下は、設定のフィールドの説明です。

     dial-peer voice 100 voip  description Inbound/Outbound Webex Calling

    100 VoIP ダイヤルピアを定義し、管理とトラブルシューティングを容易にするための意味のある説明を行います。

    max-conn 250

    Restricts the number of concurrent inbound and outbound calls between the LGW and Webex Calling. For registration trunks, the maximum value configured should be 250. Usea lower value if that would be more appropriate for your deployment. For more information on concurrent call limits for Local Gateway, refer to the Get started with Local Gateway document.

    destination-pattern BAD.BAD

    A dummy destination pattern is required when routing outbound calls using an inbound dial-peer group. Any valid destination pattern may be used in this case.

    session protocol sipv2

    ダイヤルピア 100 が SIP コール のコールコールを処理する場合に指定します。For more information, see session protocol (dial-peer).

    session target sip-server

    Indicates that the SIP server defined in tenant 100 is inherited and used for the destination for calls from this dial peer.

    incoming uri request 100

    To specify the voice class used to match a VoIP dial peer to the uniform resource identifier (URI) of an incoming call. For more information, see incoming uri.

    voice-class codec 100

    Configures the dial-peer to use the common codec filter list 100. For more information, see voice-class codec.

    voice-class stun-usage 100

    Allows locally generated STUN requests on the Local Gateway to be sent over the negotiated media path. STUN helps to open a firewall pinhole for media traffic.

    no voice-class sip localhost

    送信メッセージの物理的 IP アドレスの代用として、From、Call-ID、Remote-Party-ID ヘッダーの DNS ローカル ホスト名の代入を無効にします。

    voice-class sip tenant 100

    The dial-peer inherits all parameters configured globally and in tenant 100. Parameters may be overridden at the dial-peer level.

    srtp

    コールレグの SRTP を有効にする。

    no vad

    音声アクティブティの検出を無効にします。

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.

Configure Local Gateway with a SIP PSTN 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 sip host ipv4:192.168.80.13

以下は、設定のフィールドの説明です。

voice class uri 200 sip

Defines 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:

 dial-peer voice 200 voip description Inbound/Outbound IP PSTN trunk destination-pattern BAD.BAD session protocol sipv2 session target ipv4:192.168.80.13 incoming uri via 200 voice-class sip bind control source-interface GigabitEthernet0/0/0 voice-class sip bind media source-interface GigabitEthernet0/0/0 voice-class codec 100 dtmf-relay rtp-nte no vad

以下は、設定のフィールドの説明です。

 dial-peer voice 200 voip  description Inbound/Outbound IP PSTN trunk

200 VoIP ダイヤル ピアを定義し、管理とトラブルシューティングを容易にするための意味のある説明を行います。For more information, see dial-peer voice.

destination-pattern BAD.BAD

A 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 200

VIA ヘッダーの判断基準を 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/0

Configures the source interface and associated IP address for messages sent to the PSTN. For more information, see  bind.

bind media source-interface GigabitEthernet0/0/0

Configures the source interface and associated IP address for media sent to PSTN. For more information, see  bind.

voice-class codec 100

Configures 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.

  1. Create dial-peer groups to route calls towards Webex Calling or the PSTN. Define DPG 100 with outbound dial-peer 100 toward Webex Calling. DPG 100 is applied to the incoming dial-peer from the PSTN. Similarly, define DPG 200 with outbound dial-peer 200 toward the PSTN. DPG 200 is applied to the incoming dial-peer from Webex.

     voice class dpg 100 description Route calls to Webex Calling dial-peer 100 voice class dpg 200 description Route calls to PSTN dial-peer 200

    以下は、設定のフィールドの説明です。

    dial-peer 100

    Associates an outbound dial-peer with a dial-peer group. For more information, see  voice-class dpg.

  2. Apply dial-peer groups to route calls from Webex to the PSTN and from the PSTN to Webex: 

     dial-peer voice 100 destination dpg 200 dial-peer voice 200 destination dpg 100

    以下は、設定のフィールドの説明です。

    destination dpg 200

    Specifies which dial-peer group, and therefore dial-peer should be used for the outbound treatment for calls presented to this incoming dial-peer.

    This concludes your Local Gateway configuration. Save the configuration and reload the platform if this is the first time CUBE features are configured.

Configure Local Gateway with a TDM PSTN trunk

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.

If you do not require IP media optimization, follow the configuration steps for a SIP PSTN trunk. Use a voice port and POTS dial-peer (as shown in Steps 2 and 3) instead of the PSTN VoIP dial-peer.
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-rule 100 rule 1 /^\+/ /A2A/ voice translation-profile 100 translate called 100 voice translation-rule 200 rule 1 /^/ /A1A/ voice translation-profile 200 translate called 200 voice translation-rule 11 rule 1 /^A1A/ // voice translation-profile 11 translate called 11 voice translation-rule 12 rule 1 /^A2A44/ /0/ rule 2/^A2A/ /00/ voice translation-profile 12 translate called 12

以下は、設定のフィールドの説明です。

voice translation-rule

Uses 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:

 card type e1 0 2 isdn switch-type primary-net5 controller E1 0/2/0 pri-group timeslots 1-31
3

Configure the following TDM PSTN dial-peer:

 dial-peer voice 200 pots description Inbound/Outbound PRI PSTN trunk destination-pattern BAD.BAD translation-profile incoming 200 direct-inward-dial port 0/2/0:15

以下は、設定のフィールドの説明です。 

 dial-peer voice 200 pots  description Inbound/Outbound PRI PSTN trunk

200 VoIP ダイヤル ピアを定義し、管理とトラブルシューティングを容易にするための意味のある説明を行います。For more information, see dial-peer voice.

destination-pattern BAD.BAD

A 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 200

Assigns the translation profile that will add a call routing tag to the incoming called number.

direct-inward-dial

Routes the call without providing a secondary dial-tone. For more information, see direct-inward-dial.

port 0/2/0:15

The 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.

 dial-peer voice 10 voip description Outbound loop-around leg destination-pattern BAD.BAD session protocol sipv2 session target ipv4:192.168.80.14 voice-class sip bind control source-interface GigabitEthernet0/0/0 voice-class sip bind media source-interface GigabitEthernet0/0/0 dtmf-relay rtp-nte codec g711alaw no vad dial-peer voice 11 voip description Inbound loop-around leg towards Webex translation-profile incoming 11 session protocol sipv2 incoming called-number A1AT voice-class sip bind control source-interface GigabitEthernet0/0/0 voice-class sip bind media source-interface GigabitEthernet0/0/0 dtmf-relay rtp-nte codec g711alaw no vad dial-peer voice 12 voip description Inbound loop-around leg towards PSTN translation-profile incoming 12 session protocol sipv2 incoming called-number A2AT voice-class sip bind control source-interface GigabitEthernet0/0/0 voice-class sip bind media source-interface GigabitEthernet0/0/0 dtmf-relay rtp-nte codec g711alaw no vad

以下は、設定のフィールドの説明です。 

 dial-peer voice 10 pots  description Outbound loop-around leg

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 11

Applies the translation profile defined earlier to remove the call routing tag before passing to the outbound trunk.

destination-pattern BAD.BAD

A 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

Specifies that this dial-peer handles SIP call legs. For more information, see  session protocol (dial peer).

session target 192.168.80.14

Specifies 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/0

Configures 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/0

Configures 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:

  1. Create dial-peer groups to route calls between the PSTN and Webex trunks, via the loop-back.

     voice class dpg 100 description Route calls to Webex Calling dial-peer 100 voice class dpg 200 description Route calls to PSTN dial-peer 200 voice class dpg 10 description Route calls to Loopback dial-peer 10

    以下は、設定のフィールドの説明です。

    dial-peer 100

    Associates an outbound dial-peer with a dial-peer group. For more information, see  voice-class dpg.

  2. Apply dial-peer groups to route calls.

     dial-peer voice 100 destination dpg 10 dial-peer voice 200 destination dpg 10 dial-peer voice 11 destination dpg 100 dial-peer voice 12 destination dpg 200

    以下は、設定のフィールドの説明です。

    destination dpg 200

    Specifies which dial-peer group, and therefore dial-peer should be used for the outbound treatment for calls presented to this incoming dial-peer.

This concludes your Local Gateway configuration. Save the configuration and reload the platform if this is the first time CUBE features are configured.
ローカル ゲートウェイを既存の Unified CM 環境で構成する

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 を設定:

  1. Classifies Unified CM to Webex calls using SIP VIA port:

     voice class uri 300 sip
 pattern :5065

  2. Classifies Unified CM to PSTN calls using SIP via port:

     voice class uri 400 sip pattern 192\.168\.80\.6[0-5]:5060

    Classify incoming messages from the UCM towards the PSTN trunk using one or more patterns that describe the originating source addresses and port number. Regular expressions may be used to define matching patterns if required.

    In the example above, a regular expression is used to match any IP address in the range 192.168.80.60 to 65 and port number 5060.

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.

 ip host ucmpub.mydomain.com 192.168.80.60 ip host ucmsub1.mydomain.com 192.168.80.61 ip host ucmsub2.mydomain.com 192.168.80.62 ip host ucmsub3.mydomain.com 192.168.80.63 ip host ucmsub4.mydomain.com 192.168.80.64 ip host ucmsub5.mydomain.com 192.168.80.65 ip host _sip._udp.wxtocucm.io srv 0 1 5065 ucmpub.mydomain.com ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub1.mydomain.com ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub2.mydomain.com ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub3.mydomain.com ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub4.mydomain.com ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub5.mydomain.com ip host _sip._udp.pstntocucm.io srv 0 1 5060 ucmpub.mydomain.com ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub1.mydomain.com ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub2.mydomain.com ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub3.mydomain.com ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub4.mydomain.com ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub5.mydomain.com

以下は、設定のフィールドの説明です。

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:

  1. Dial-peer for calls between Unified CM and Webex Calling:

     dial-peer voice 300 voip description UCM-Webex Calling trunk destination-pattern BAD.BAD session protocol sipv2 session target dns:wxtocucm.io incoming uri via 300 voice-class codec 100 voice-class sip bind control source-interface GigabitEthernet 0/0/0 voice-class sip bind media source-interface GigabitEthernet 0/0/0 dtmf-relay rtp-nte no vad

    以下は、設定のフィールドの説明です。

     dial-peer voice 300 voip  description UCM-Webex Calling trunk

    Defines a VoIP dial-peer with a tag 300 and gives a meaningful description for ease of management and troubleshooting.

    destination-pattern BAD.BAD

    A dummy destination pattern is required when routing outbound calls using an inbound dial-peer group. Any valid destination pattern may be used in this case.

    session protocol sipv2

    Specifies that dial-peer 300 handles SIP call legs. For more information, see  session protocol (dial-peer).

    session target dns:wxtocucm.io

    Defines the session target of multiple Unified CM nodes through DNS SRV resolution. In this case, the locally defined SRV record wxtocucm.io is used to direct calls.

    incoming uri via 300

    Uses voice class URI 300 to direct all incoming traffic from Unified CM using source port 5065 to this dial-peer. For more information, see  incoming uri.

    voice-class codec 100

    Indicates codec filter list for calls to and from Unified CM. For more information, see  voice class codec.

    bind control source-interface GigabitEthernet0/0/0

    Configures the source interface and associated IP address for messages sent to the PSTN. For more information, see  bind.

    bind media source-interface GigabitEthernet0/0/0

    Configures the source interface and associated IP address for media sent to PSTN. For more information, see  bind.

    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).

  2. Dial-peer for calls between Unified CM and the PSTN:

     dial-peer voice 400 voip description UCM-PSTN trunk destination-pattern BAD.BAD session protocol sipv2 session target dns:pstntocucm.io incoming uri via 400 voice-class codec 100 voice-class sip bind control source-interface GigabitEthernet 0/0/0 voice-class sip bind media source-interface GigabitEthernet 0/0/0 dtmf-relay rtp-nte no vad

    以下は、設定のフィールドの説明です。

     dial-peer voice 400 voip  description UCM-PSTN trunk

    400 VoIP ダイヤル ピアを定義し、管理とトラブルシューティングを容易にするための意味のある説明を行います。

    destination-pattern BAD.BAD

    A dummy destination pattern is required when routing outbound calls using an inbound dial-peer group. Any valid destination pattern may be used in this case.

    session protocol sipv2

    Specifies that dial-peer 400 handles SIP call legs. For more information, see  session protocol (dial-peer).

    session target dns:pstntocucm.io

    Defines the session target of multiple Unified CM nodes through DNS SRV resolution. In this case, the locally defined SRV record pstntocucm.io is used to direct calls.

    incoming uri via 400

    Uses voice class URI 400 to direct all incoming traffic from the specified Unified CM hosts using source port 5060 to this dial-peer. For more information, see  incoming uri.

    voice-class codec 100

    Indicates codec filter list for calls to and from Unified CM. For more information, see  voice class codec.

    bind control source-interface GigabitEthernet0/0/0

    Configures the source interface and associated IP address for messages sent to the PSTN. For more information, see  bind.

    bind media source-interface GigabitEthernet0/0/0

    Configures the source interface and associated IP address for media sent to PSTN. For more information, see  bind.

    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).

4

Add call routing using the following configurations:

  1. Create dial-peer groups to route calls between Unified CM and Webex Calling. Define DPG 100 with outbound dial-peer 100 towards Webex Calling. DPG 100 is applied to the associated incoming dial-peer from Unified CM. Similarly, define DPG 300 with outbound dial-peer 300 toward Unified CM. DPG 300 is applied to the incoming dial-peer from Webex.

     voice class dpg 100 description Route calls to Webex Calling dial-peer 100 voice class dpg 300 description Route calls to Unified CM Webex Calling trunk dial-peer 300

  2. Create a dial-peer groups to route calls between Unified CM and the PSTN. Define DPG 200 with outbound dial-peer 200 toward the PSTN. DPG 200 is applied to the associated incoming dial-peer from Unified CM. Similarly, define DPG 400 with outbound dial-peer 400 toward Unified CM. DPG 400 is applied to the incoming dial-peer from the PSTN.

     voice class dpg 200 description Route calls to PSTN dial-peer 200 voice class dpg 400 description Route calls to Unified CM PSTN trunk dial-peer 400

    以下は、設定のフィールドの説明です。

    dial-peer  100

    Associates an outbound dial-peer with a dial-peer group. For more information, see  voice-class dpg.

  3. Apply dial-peer groups to route calls from Webex to Unified CM and from Unified CM to Webex: 

     dial-peer voice 100 destination dpg 300 dial-peer voice 300 destination dpg 100

    以下は、設定のフィールドの説明です。

    destination dpg 300

    Specifies which dial-peer group, and therefore dial-peer should be used for the outbound treatment for calls presented to this incoming dial-peer.

  4. Apply dial-peer groups to route calls from the PSTN to Unified CM and from Unified CM to the PSTN:

     dial-peer voice 200 destination dpg 400 dial-peer voice 400 destination dpg 200

    This concludes your Local Gateway configuration. Save the configuration and reload the platform if this is the first time CUBE features have been configured.

診断署名でローカル ゲートウェイを監視し、トラブルシューティングする

診断署名 (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

  1. 診断署名はデフォルトで有効になっています。

  2. 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

  3. 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 アカウント設定を行い、端末からメールを正しく処理するための権限を与える必要があります:

  1. Go to Manage Google Account > Security and turn on the Less secure app access setting.

  2. 「はい、はい、それは私です」と答えます。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% 以上に達すると、すべてのデバッグを無効にし、ローカル ゲートウェイにインストールされている診断署名をアンインストールします。下記の手順を実行して署名をインストールします。

  1. 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

  2. Diagnostic Signatures Lookup Tool の以下のドロップダウンオプションを使用して、DS 64224 をダウンロードします。

    フィールド名

    フィールド値

    プラットフォーム

    Cisco 4300, 4400 ISR Series or Cisco CSR 1000V Series

    製品

    Webex Calling ソリューションの CUBE Enterprise

    問題の範囲

    パフォーマンス

    問題の種類

    通知メールによる CPU 使用率が高い

  3. 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)

  4. ローカルゲートウェイに DS XML ファイルをインストールします。

    call-home diagnostic-signature load DS_64224.xml Load file DS_64224.xml success

  5. 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:

  1. Diagnostic Signatures Lookup Tool の以下のドロップダウンオプションを使用して、DS 64117 をダウンロードします。

    フィールド名

    フィールド値

    プラットフォーム

    Cisco 4300、4400 ISR シリーズ、または Cisco CSR 1000V シリーズ

    製品

    Webex Calling ソリューションの CUBE Enterprise

    問題の範囲

    SIP-SIP

    問題の種類

    SIP トランクによる登録解除を行いました。

  2. DS XML ファイルをローカルゲートウェイにコピーします。

    copy ftp://username:password@<server name or ip>/DS_64117.xml bootflash:

  3. ローカルゲートウェイに DS XML ファイルをインストールします。 

    call-home diagnostic-signature load DS_64117.xml Load file DS_64117.xml success LocalGateway#

  4. 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.

  1. 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

  2. Diagnostic Signatures Lookup Tool の以下のオプションを使用して、DS 65221 をダウンロードします。

    フィールド名

    フィールド値

    プラットフォーム

    Cisco 4300、4400 ISR シリーズ、または Cisco CSR 1000V シリーズ

    製品

    Webex Calling ソリューションの CUBE Enterprise

    問題の範囲

    パフォーマンス

    問題の種類

    メールおよび Syslog 通知による SIP の異常通話切断検出

  3. DS XML ファイルをローカルゲートウェイにコピーします。 

    copy ftp://username:password@<server name or ip>/DS_65221.xml bootflash:

  4. ローカルゲートウェイに DS XML ファイルをインストールします。 

    call-home diagnostic-signature load DS_65221.xml Load file DS_65221.xml success

  5. 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 を使用して、以下の手順を使用して、診断データの収集を自動化します。

  1. 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"

  2. 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

  3. 高 CPU 使用率の期間中に、すべてのデバッグと診断署名を無効にするためのプロアクティブな措置として、高 CPU モニタリング DS 64224 をインストールしてください。Diagnostic Signatures Lookup Tool の以下のオプションを使用して、DS 64224 をダウンロードします。

    フィールド名

    フィールド値

    プラットフォーム

    Cisco 4300、4400 ISR シリーズ、または Cisco CSR 1000V シリーズ

    製品

    Webex Calling ソリューションの CUBE Enterprise

    問題の範囲

    パフォーマンス

    問題の種類

    通知メールによる CPU 使用率が高い

  4. 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

  5. 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:

  6. ローカルゲートウェイに、高 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

  7. 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 では現在、新しいカスタム署名の作成リクエストをサポートしていません。

Manage and validate Cisco IOS XE Gateways through Control Hub

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:

Design overview

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.

Call routing from/to PSTN to/from Webex Calling configuration solution

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

Configure connectivity and security

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:

 interface GigabitEthernet0/0/0 description Interface facing PSTN and/or CUCM ip address 192.168.80.14 255.255.255.0 ! interface GigabitEthernet0/0/1 description Interface facing Webex Calling (Public address) ip address 198.51.100.1 255.255.255.240

2

Protect STUN credentials on the router using symmetric encryption. Configure the primary encryption key and encryption type as follows:

 key config-key password-encrypt YourPassword password encryption aes
3

Create an encryption trustpoint with a certificate signed by your preferred Certificate Authority (CA).

  1. Create an RSA key pair using the following exec command.

    crypto key generate rsa general-keys exportable label lgw-key modulus 4096

  2. When using cube1.lgw.com as the fqdn for the trunk, create a trustpoint for the signed certificate with the following configuration commands: 

     crypto pki trustpoint LGW_CERT enrollment terminal pem fqdn cube1.lgw.com subject-name cn=cube1.lgw.com subject-alt-name cube1.lgw.com revocation-check none rsakeypair lgw-key

  3. Generate Certificate Signing Request (CSR) with the following exec or configuration command and use it to request a signed certificate from a supported CA provider:

    crypto pki enroll LGW_CERT

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:

 crypto pki authenticate LGW_CERT <paste Intermediate X.509 base 64 based certificate here>

5

Import a signed host certificate using the following exec or configuration command:

 crypto pki import LGW_CERT certificate <paste CUBE host X.509 base 64 certificate here>

6

Enable TLS1.2 exclusivity and specify the default trustpoint using the following configuration commands:

 sip-ua crypto signaling default trustpoint LGW_CERT transport tcp tls v1.2

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
 ip http client source-interface GigabitEthernet0/0/1 crypto pki trustpool import clean url https://www.cisco.com/security/pki/trs/ios_core.p7b
Configure Webex Calling certificate-based trunk
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:

 voice service voip ip address trusted list ipv4 x.x.x.x y.y.y.y mode border-element allow-connections sip to sip no supplementary-service sip refer stun stun flowdata agent-id 1 boot-count 4 stun flowdata shared-secret 0 Password123$ sip asymmetric payload full early-offer forced sip-profiles inbound

以下は、設定のフィールドの説明です。

 ip address trusted list  ipv4 x.x.x.x y.y.y.y

  • To protect against toll fraud, the trusted address list defines a list of hosts and networks entities from which the Local Gateway expects legitimate VoIP calls.

  • By default, Local Gateway blocks all incoming VoIP messages from IP addresses not in its trusted list. Statically configured dial-peers with “session target IP” or server group IP addresses are trusted by default so do not need to be added to the trusted list.

  • When configuring your Local Gateway, add the IP subnets for your regional Webex Calling data center to the list, see Port Reference Information for Webex Calling for more information. Also, add address ranges for Unified Communications Manager servers (if used) and PSTN trunk gateways.

  • For more information on how to use an IP address trusted list to prevent toll fraud, see IP address trusted.

mode border-element

Enables Cisco Unified Border Element (CUBE) features on the platform.

allow-connections sip to sip

Enable 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).

stun

Enables STUN (Session Traversal of UDP through NAT) globally.

These global stun commands are only required when deploying your Local Gateway behind NAT.

  • 通話を Webex Calling ユーザーに転送する場合 ( 例えば、通話側と通話側の両当事者が Webex Calling のサブスクライバーであり、Webex Calling SBC にメディアを固定する場合)、メディアはピンホールが開いていないので、ローカル ゲートウェイにフローできません。

  • The STUN bindings feature on the Local Gateway allows locally generated STUN requests to be sent over the negotiated media path. This helps to open the pinhole in the firewall.

For more information, see  stun flowdata agent-id and  stun flowdata shared-secret.

asymmetric payload full

Configures SIP asymmetric payload support for both DTMF and dynamic codec payloads. For more information on this command, see asymmetric payload.

early-offer forced

Forces 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 inbound

Enables 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 100 codec preference 1 opus codec preference 2 g711ulaw codec preference 3 g711alaw

以下は、設定のフィールドの説明です。

voice class codec 100

Used 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)

 voice class stun-usage 100 stun usage firewall-traversal flowdata stun usage ice lite

以下は、設定のフィールドの説明です。

stun usage ice lite

Used 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 100 crypto 1 AES_CM_128_HMAC_SHA1_80

以下は、設定のフィールドの説明です。

voice class srtp-crypto 100

Specifies 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 100 crypto 1 AEAD_AES_256_GCM

以下は、設定のフィールドの説明です。

voice class srtp-crypto 100

Specifies 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 sip pattern cube1.lgw.com

以下は、設定のフィールドの説明です。

voice class uri 100 sip

Defines 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:

 voice class sip-profiles 100 rule 10 request ANY sip-header Contact modify "@.*:" "@cube1.lgw.com:" rule 20 response ANY sip-header Contact modify "@.*:" "@cube1.lgw.com:"

以下は、設定のフィールドの説明です。

rules 10 and 20

To 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 
 voice class sip-profiles 100 rule 10 request ANY sip-header Contact modify "@.*:" "@cube1.lgw.com:" rule 20 response ANY sip-header Contact modify "@.*:" "@cube1.lgw.com:" rule 30 response ANY sdp-header Audio-Attribute modify "(a=candidate:1 1.*) 10.80.13.12" "\1 192.65.79.20" rule 31 response ANY sdp-header Audio-Attribute modify "(a=candidate:1 2.*) 10.80.13.12" "\1 192.65.79.20" rule 40 response ANY sdp-header Audio-Connection-Info modify "IN IP4 10.80.13.12" "IN IP4 192.65.79.20" rule 41 request ANY sdp-header Audio-Connection-Info modify "IN IP4 10.80.13.12" "IN IP4 192.65.79.20" rule 50 request ANY sdp-header Connection-Info modify "IN IP4 10.80.13.12" "IN IP4 192.65.79.20" rule 51 response ANY sdp-header Connection-Info modify "IN IP4 10.80.13.12" "IN IP4 192.65.79.20" rule 60 response ANY sdp-header Session-Owner modify "IN IP4 10.80.13.12" "IN IP4 192.65.79.20" rule 61 request ANY sdp-header Session-Owner modify "IN IP4 10.80.13.12" "IN IP4 192.65.79.20" rule 70 request ANY sdp-header Audio-Attribute modify "(a=rtcp:.*) 10.80.13.12" "\1 192.65.79.20" rule 71 response ANY sdp-header Audio-Attribute modify "(a=rtcp:.*) 10.80.13.12" "\1 192.65.79.20 rule 80 request ANY sdp-header Audio-Attribute modify "(a=candidate:1 1.*) 10.80.13.12" "\1 192.65.79.20" rule 81 request ANY sdp-header Audio-Attribute modify "(a=candidate:1 2.*) 10.80.13.12" "\1 192.65.79.20"

以下は、設定のフィールドの説明です。

rules 10 and 20

To 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 81

Convert 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 
 voice class sip-profiles 110 rule 10 response ANY sdp-header Video-Connection-Info modify "192.65.79.20" "10.80.13.12" rule 20 response ANY sip-header Contact modify "@.*:" "@cube1.lgw.com:" rule 30 response ANY sdp-header Connection-Info modify "192.65.79.20" "10.80.13.12" rule 40 response ANY sdp-header Audio-Connection-Info modify "192.65.79.20" "10.80.13.12" rule 50 response ANY sdp-header Session-Owner modify "192.65.79.20" "10.80.13.12" rule 60 response ANY sdp-header Audio-Attribute modify "(a=candidate:1 1.*) 192.65.79.20" "\1 10.80.13.12" rule 70 response ANY sdp-header Audio-Attribute modify "(a=candidate:1 2.*) 192.65.79.20" "\1 10.80.13.12" rule 80 response ANY sdp-header Audio-Attribute modify "(a=rtcp:.*) 192.65.79.20" "\1 10.80.13.12"

以下は、設定のフィールドの説明です。

rules 10 to 80

Convert 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-profiles 115 rule 10 request OPTIONS sip-header Contact modify "<sip:.*:" "<sip:cube1.lgw.com:" rule 30 request ANY sip-header Via modify "(SIP.*) 10.80.13.12" "\1 192.65.79.20" rule 40 response ANY sdp-header Connection-Info modify "10.80.13.12" "192.65.79.20" rule 50 response ANY sdp-header Audio-Connection-Info modify "10.80.13.12" "192.65.79.20" ! voice class sip-options-keepalive 100 description Keepalive for Webex Calling up-interval 5 transport tcp tls sip-profiles 115

以下は、設定のフィールドの説明です。

voice class sip-options-keepalive 100

Configures 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:

  1. Create voice class tenant 100 to define and group configurations required specifically for the Webex Calling trunk. Dial-peers associated with this tenant later will inherit these configurations:

    The following example uses the values illustrated in Step 1 for the purpose of this guide (shown in bold). Replace these with values for your trunk in your configuration.

     voice class tenant 100 no remote-party-id sip-server dns:us25.sipconnect.bcld.webex.com srtp-crypto 100 localhost dns:cube1.lgw.com session transport tcp tls no session refresh error-passthru bind control source-interface GigabitEthernet0/0/1 bind media source-interface GigabitEthernet0/0/1 no pass-thru content custom-sdp sip-profiles 100 sip-profiles 110 inbound privacy-policy passthru !

    以下は、設定のフィールドの説明です。

    voice class tenant 100

    We recommend that you use tenants to configure trunks which have their own TLS certificate, and CN or SAN validation list. Here, the tls-profile associated with the tenant contains the trust point to be used to accept or create new connections, and has the CN or SAN list to validate the incoming connections. For more information, see voice class tenant.

    no remote-party-id

    Disable SIP Remote-Party-ID (RPID) header as Webex Calling supports PAI, which is enabled using CIO asserted-id pai. For more information, see remote-party-id.

    sip-server dns:us25.sipconnect.bcld.webex.com

    Configures the target SIP server for the trunk. Use the edge proxy SRV address provided in Control Hub when you created your trunk

    srtp-crypto 100

    Configures the preferred cipher-suites for the SRTP call leg (connection) (specified in Step 5). For more information, see voice class srtp-crypto.

    localhost dns: cube1.lgw.com

    Configures CUBE to replace the physical IP address in the From, Call-ID, and Remote-Party-ID headers in outgoing messages with the provided FQDN.

    session transport tcp tls

    Sets transport to TLS for associated dial-peers. For more information, see session-transport.

    no session refresh

    Disables SIP session refresh globally.

    error-passthru

    SIP エラー応答パススルー機能を指定します。For more information, see error-passthru.

    bind control source-interface GigabitEthernet0/0/1

    Configures the source interface and associated IP address for messages sent to Webex Calling. For more information, see bind.

    bind media source-interface GigabitEthernet0/0/1

    Configures the source interface and associated IP address for media sent to Webex Calling. For more information, see bind.

    voice-class sip profiles 100

    Applies the header modification profile (Public IP or NAT addressing) to use for outbound messages. For more information, see voice-class sip profiles.

    voice-class sip profiles 110 inbound

    Applies the header modification profile (NAT addressing only) to use for inbound messages. For more information, see voice-class sip profiles.

    privacy-policy passthru

    Configures the privacy header policy options for the trunk to pass privacy values from the received message to the next call leg. For more information, see privacy-policy.

  2. Configure the Webex Calling trunk dial-peer.

     dial-peer voice 100 voip description Inbound/Outbound Webex Calling destination-pattern BAD.BAD session protocol sipv2 session target sip-server incoming uri request 100 voice-class codec 100 voice-class stun-usage 100 voice-class sip rel1xx disable voice-class sip asserted-id pai voice-class sip tenant 100 voice-class sip options-keepalive profile 100 dtmf-relay rtp-nte srtp no vad

    以下は、設定のフィールドの説明です。

     dial-peer voice 100 voip  description Inbound/Outbound Webex Calling

    100 VoIP ダイヤル ピアを定義し、管理とトラブルシューティングを容易にするための意味のある説明をします。For more information, see dial-peer voice.

    destination-pattern BAD.BAD

    A dummy destination pattern is required when routing outbound calls using an inbound dial-peer group. Any valid destination pattern may be used in this case.

    session protocol sipv2

    ダイヤルピア 100 が SIP コール のコールコールを処理する場合に指定します。For more information, see session protocol (dial-peer).

    session target sip-server

    Indicates that the SIP server defined in tenant 100 is inherited and used for the destination for calls from this dial peer.

    incoming uri request 100

    To specify the voice class used to match a VoIP dial peer to the uniform resource identifier (URI) of an incoming call. For more information, see  incoming uri.

    voice-class codec 100

    Indicates codec filter list for calls to and from Webex Calling. For more information, see voice class codec.

    voice-class stun-usage 100

    Allows locally generated STUN requests on the Local Gateway to be sent over the negotiated media path. STUN help to open a firewall pinhole for media traffic.

    voice-class sip asserted-id pai

    Sets the outgoing calling information using the privacy asserted ID (PAI) header. For more information, see voice-class sip asserted-id.

    voice-class sip tenant 100

    The dial-peer inherits all parameters configured globally and in tenant 100. Parameters may overridden at the dial-peer level. For more information, see  voice-class sip tenant.

    voice-class sip options-keepalive profile 100

    This command is used to monitor the availability of a group of SIP servers or endpoints using a specific profile (100).

    srtp

    コールレグの SRTP を有効にする。

Configure Local Gateway with a SIP PSTN 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 sip host ipv4:192.168.80.13

以下は、設定のフィールドの説明です。

voice class uri 200 sip

Defines 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:

 dial-peer voice 200 voip description Inbound/Outbound IP PSTN trunk destination-pattern BAD.BAD session protocol sipv2 session target ipv4:192.168.80.13 incoming uri via 200 voice-class sip bind control source-interface GigabitEthernet0/0/0 voice-class sip bind media source-interface GigabitEthernet0/0/0 voice-class codec 100 dtmf-relay rtp-nte no vad

以下は、設定のフィールドの説明です。

 dial-peer voice 200 voip  description Inbound/Outbound IP PSTN trunk

200 VoIP ダイヤル ピアを定義し、管理とトラブルシューティングを容易にするための意味のある説明を行います。For more information, see dial-peer voice.

destination-pattern BAD.BAD

A 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 200

VIA ヘッダーの判断基準を 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/0

Configures the source interface and associated IP address for messages sent to the PSTN. For more information, see  bind.

bind media source-interface GigabitEthernet0/0/0

Configures the source interface and associated IP address for media sent to PSTN. For more information, see  bind.

voice-class codec 100

Configures 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.

  1. Create dial-peer groups to route calls towards Webex Calling or the PSTN. Define DPG 100 with outbound dial-peer 100 toward Webex Calling. DPG 100 is applied to the incoming dial-peer from the PSTN. Similarly, define DPG 200 with outbound dial-peer 200 toward the PSTN. DPG 200 is applied to the incoming dial-peer from Webex.

     voice class dpg 100 description Route calls to Webex Calling dial-peer 100 voice class dpg 200 description Route calls to PSTN dial-peer 200

    以下は、設定のフィールドの説明です。

    dial-peer 100

    Associates an outbound dial-peer with a dial-peer group. For more information, see  voice-class dpg.

  2. Apply dial-peer groups to route calls from Webex to the PSTN and from the PSTN to Webex: 

     dial-peer voice 100 destination dpg 200 dial-peer voice 200 destination dpg 100

    以下は、設定のフィールドの説明です。

    destination dpg 200

    Specifies which dial-peer group, and therefore dial-peer should be used for the outbound treatment for calls presented to this incoming dial-peer.

    This concludes your Local Gateway configuration. Save the configuration and reload the platform if this is the first time CUBE features are configured.

Configure Local Gateway with a TDM PSTN trunk

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.

If you do not require IP media optimization, follow the configuration steps for a SIP PSTN trunk. Use a voice port and POTS dial-peer (as shown in Steps 2 and 3) instead of the PSTN VoIP dial-peer.
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-rule 100 rule 1 /^\+/ /A2A/ voice translation-profile 100 translate called 100 voice translation-rule 200 rule 1 /^/ /A1A/ voice translation-profile 200 translate called 200 voice translation-rule 11 rule 1 /^A1A/ // voice translation-profile 11 translate called 11 voice translation-rule 12 rule 1 /^A2A44/ /0/ rule 2/^A2A/ /00/ voice translation-profile 12 translate called 12

以下は、設定のフィールドの説明です。

voice translation-rule

Uses 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:

 card type e1 0 2 isdn switch-type primary-net5 controller E1 0/2/0 pri-group timeslots 1-31
3

Configure the following TDM PSTN dial-peer:

 dial-peer voice 200 pots description Inbound/Outbound PRI PSTN trunk destination-pattern BAD.BAD translation-profile incoming 200 direct-inward-dial port 0/2/0:15

以下は、設定のフィールドの説明です。 

 dial-peer voice 200 pots  description Inbound/Outbound PRI PSTN trunk

200 VoIP ダイヤル ピアを定義し、管理とトラブルシューティングを容易にするための意味のある説明を行います。For more information, see dial-peer voice.

destination-pattern BAD.BAD

A 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 200

Assigns the translation profile that will add a call routing tag to the incoming called number.

direct-inward-dial

Routes the call without providing a secondary dial-tone. For more information, see direct-inward-dial.

port 0/2/0:15

The 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.

 dial-peer voice 10 voip description Outbound loop-around leg destination-pattern BAD.BAD session protocol sipv2 session target ipv4:192.168.80.14 voice-class sip bind control source-interface GigabitEthernet0/0/0 voice-class sip bind media source-interface GigabitEthernet0/0/0 dtmf-relay rtp-nte codec g711alaw no vad dial-peer voice 11 voip description Inbound loop-around leg towards Webex translation-profile incoming 11 session protocol sipv2 incoming called-number A1AT voice-class sip bind control source-interface GigabitEthernet0/0/0 voice-class sip bind media source-interface GigabitEthernet0/0/0 dtmf-relay rtp-nte codec g711alaw no vad dial-peer voice 12 voip description Inbound loop-around leg towards PSTN translation-profile incoming 12 session protocol sipv2 incoming called-number A2AT voice-class sip bind control source-interface GigabitEthernet0/0/0 voice-class sip bind media source-interface GigabitEthernet0/0/0 dtmf-relay rtp-nte codec g711alaw no vad

以下は、設定のフィールドの説明です。 

 dial-peer voice 10 pots  description Outbound loop-around leg

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 11

Applies the translation profile defined earlier to remove the call routing tag before passing to the outbound trunk.

destination-pattern BAD.BAD

A 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

Specifies that this dial-peer handles SIP call legs. For more information, see  session protocol (dial peer).

session target 192.168.80.14

Specifies 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/0

Configures 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/0

Configures 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:

  1. Create dial-peer groups to route calls between the PSTN and Webex trunks, via the loop-back.

     voice class dpg 100 description Route calls to Webex Calling dial-peer 100 voice class dpg 200 description Route calls to PSTN dial-peer 200 voice class dpg 10 description Route calls to Loopback dial-peer 10

    以下は、設定のフィールドの説明です。

    dial-peer 100

    Associates an outbound dial-peer with a dial-peer group. For more information, see  voice-class dpg.

  2. Apply dial-peer groups to route calls.

     dial-peer voice 100 destination dpg 10 dial-peer voice 200 destination dpg 10 dial-peer voice 11 destination dpg 100 dial-peer voice 12 destination dpg 200

    以下は、設定のフィールドの説明です。

    destination dpg 200

    Specifies which dial-peer group, and therefore dial-peer should be used for the outbound treatment for calls presented to this incoming dial-peer.

This concludes your Local Gateway configuration. Save the configuration and reload the platform if this is the first time CUBE features are configured.
ローカル ゲートウェイを既存の Unified CM 環境で構成する

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 を設定:

  1. Classifies Unified CM to Webex calls using SIP VIA port:

     voice class uri 300 sip
 pattern :5065

  2. Classifies Unified CM to PSTN calls using SIP via port:

     voice class uri 400 sip pattern 192\.168\.80\.6[0-5]:5060

    Classify incoming messages from the UCM towards the PSTN trunk using one or more patterns that describe the originating source addresses and port number. Regular expressions may be used to define matching patterns if required.

    In the example above, a regular expression is used to match any IP address in the range 192.168.80.60 to 65 and port number 5060.

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.

 ip host ucmpub.mydomain.com 192.168.80.60 ip host ucmsub1.mydomain.com 192.168.80.61 ip host ucmsub2.mydomain.com 192.168.80.62 ip host ucmsub3.mydomain.com 192.168.80.63 ip host ucmsub4.mydomain.com 192.168.80.64 ip host ucmsub5.mydomain.com 192.168.80.65 ip host _sip._udp.wxtocucm.io srv 0 1 5065 ucmpub.mydomain.com ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub1.mydomain.com ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub2.mydomain.com ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub3.mydomain.com ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub4.mydomain.com ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub5.mydomain.com ip host _sip._udp.pstntocucm.io srv 0 1 5060 ucmpub.mydomain.com ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub1.mydomain.com ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub2.mydomain.com ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub3.mydomain.com ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub4.mydomain.com ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub5.mydomain.com

以下は、設定のフィールドの説明です。

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:

  1. Dial-peer for calls between Unified CM and Webex Calling:

     dial-peer voice 300 voip description UCM-Webex Calling trunk destination-pattern BAD.BAD session protocol sipv2 session target dns:wxtocucm.io incoming uri via 300 voice-class codec 100 voice-class sip bind control source-interface GigabitEthernet 0/0/0 voice-class sip bind media source-interface GigabitEthernet 0/0/0 dtmf-relay rtp-nte no vad

    以下は、設定のフィールドの説明です。

     dial-peer voice 300 voip  description UCM-Webex Calling trunk

    Defines a VoIP dial-peer with a tag 300 and gives a meaningful description for ease of management and troubleshooting.

    destination-pattern BAD.BAD

    A dummy destination pattern is required when routing outbound calls using an inbound dial-peer group. Any valid destination pattern may be used in this case.

    session protocol sipv2

    Specifies that dial-peer 300 handles SIP call legs. For more information, see  session protocol (dial-peer).

    session target dns:wxtocucm.io

    Defines the session target of multiple Unified CM nodes through DNS SRV resolution. In this case, the locally defined SRV record wxtocucm.io is used to direct calls.

    incoming uri via 300

    Uses voice class URI 300 to direct all incoming traffic from Unified CM using source port 5065 to this dial-peer. For more information, see  incoming uri.

    voice-class codec 100

    Indicates codec filter list for calls to and from Unified CM. For more information, see  voice class codec.

    bind control source-interface GigabitEthernet0/0/0

    Configures the source interface and associated IP address for messages sent to the PSTN. For more information, see  bind.

    bind media source-interface GigabitEthernet0/0/0

    Configures the source interface and associated IP address for media sent to PSTN. For more information, see  bind.

    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).

  2. Dial-peer for calls between Unified CM and the PSTN:

     dial-peer voice 400 voip description UCM-PSTN trunk destination-pattern BAD.BAD session protocol sipv2 session target dns:pstntocucm.io incoming uri via 400 voice-class codec 100 voice-class sip bind control source-interface GigabitEthernet 0/0/0 voice-class sip bind media source-interface GigabitEthernet 0/0/0 dtmf-relay rtp-nte no vad

    以下は、設定のフィールドの説明です。

     dial-peer voice 400 voip  description UCM-PSTN trunk

    400 VoIP ダイヤル ピアを定義し、管理とトラブルシューティングを容易にするための意味のある説明を行います。

    destination-pattern BAD.BAD

    A dummy destination pattern is required when routing outbound calls using an inbound dial-peer group. Any valid destination pattern may be used in this case.

    session protocol sipv2

    Specifies that dial-peer 400 handles SIP call legs. For more information, see  session protocol (dial-peer).

    session target dns:pstntocucm.io

    Defines the session target of multiple Unified CM nodes through DNS SRV resolution. In this case, the locally defined SRV record pstntocucm.io is used to direct calls.

    incoming uri via 400

    Uses voice class URI 400 to direct all incoming traffic from the specified Unified CM hosts using source port 5060 to this dial-peer. For more information, see  incoming uri.

    voice-class codec 100

    Indicates codec filter list for calls to and from Unified CM. For more information, see  voice class codec.

    bind control source-interface GigabitEthernet0/0/0

    Configures the source interface and associated IP address for messages sent to the PSTN. For more information, see  bind.

    bind media source-interface GigabitEthernet0/0/0

    Configures the source interface and associated IP address for media sent to PSTN. For more information, see  bind.

    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).

4

Add call routing using the following configurations:

  1. Create dial-peer groups to route calls between Unified CM and Webex Calling. Define DPG 100 with outbound dial-peer 100 towards Webex Calling. DPG 100 is applied to the associated incoming dial-peer from Unified CM. Similarly, define DPG 300 with outbound dial-peer 300 toward Unified CM. DPG 300 is applied to the incoming dial-peer from Webex.

     voice class dpg 100 description Route calls to Webex Calling dial-peer 100 voice class dpg 300 description Route calls to Unified CM Webex Calling trunk dial-peer 300

  2. Create a dial-peer groups to route calls between Unified CM and the PSTN. Define DPG 200 with outbound dial-peer 200 toward the PSTN. DPG 200 is applied to the associated incoming dial-peer from Unified CM. Similarly, define DPG 400 with outbound dial-peer 400 toward Unified CM. DPG 400 is applied to the incoming dial-peer from the PSTN.

     voice class dpg 200 description Route calls to PSTN dial-peer 200 voice class dpg 400 description Route calls to Unified CM PSTN trunk dial-peer 400

    以下は、設定のフィールドの説明です。

    dial-peer  100

    Associates an outbound dial-peer with a dial-peer group. For more information, see  voice-class dpg.

  3. Apply dial-peer groups to route calls from Webex to Unified CM and from Unified CM to Webex: 

     dial-peer voice 100 destination dpg 300 dial-peer voice 300 destination dpg 100

    以下は、設定のフィールドの説明です。

    destination dpg 300

    Specifies which dial-peer group, and therefore dial-peer should be used for the outbound treatment for calls presented to this incoming dial-peer.

  4. Apply dial-peer groups to route calls from the PSTN to Unified CM and from Unified CM to the PSTN:

     dial-peer voice 200 destination dpg 400 dial-peer voice 400 destination dpg 200

    This concludes your Local Gateway configuration. Save the configuration and reload the platform if this is the first time CUBE features have been configured.

診断署名でローカル ゲートウェイを監視し、トラブルシューティングする

診断署名 (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 以上を実行するローカル ゲートウェイ

  1. 診断署名はデフォルトで有効になっています。

  2. 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

  3. 通知する管理者 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% 以上に達すると、すべてのデバッグが無効し、ローカル ゲートウェイにインストールした診断署名をアンインストールします。下記の手順を実行して署名をインストールします。

  1. コマンドを使用して 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

  2. 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 使用率

  3. 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)

  4. ローカルゲートウェイに DS XML ファイルをインストールします。

     call-home diagnostic-signature load DS_64224.xml Load file DS_64224.xml success

  5. 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.

  1. コマンド 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

  2. Diagnostic Signatures Lookup Tool の以下のオプションを使用して、DS 65221 をダウンロードします。

    フィールド名

    フィールド値

    プラットフォーム

    Cisco 4300, 4400 ISR Series, or Catalyst 8000V Edge Software

    製品

    Webex Calling ソリューションの CUBE Enterprise

    問題の範囲

    パフォーマンス

    問題の種類

    メールおよび Syslog 通知による SIP の異常通話切断検出

  3. DS XML ファイルをローカルゲートウェイにコピーします。

    copy ftp://username:password@<server name or ip>/DS_65221.xml bootflash:

  4. ローカルゲートウェイに DS XML ファイルをインストールします。 

     call-home diagnostic-signature load DS_65221.xml Load file DS_65221.xml success

  5. 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 を使用して、以下の手順を使用して、診断データの収集を自動化します。

  1. 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"

  2. コマンド 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

  3. 高 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 使用率が高い

  4. 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

  5. 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:

  6. 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

  7. 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 エンタープライズ展開が、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 設定ガイドを次に示します。

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

インターフェイスのステータスを追跡するために、グローバル レベルでインターフェイス トラッキングを構成します。

conf t
 track 1 interface GigabitEthernet1 line-protocol
 track 2 interface GigabitEthernet2 line-protocol
 exit 

VCUBE-1#conf t

VCUBE-1(config)#track 1 interface GigabitEthernet1 line-protocol

VCUBE-1(config-track)#track 2 interface GigabitEthernet2 line-protocol

VCUBE-1(config-track)#exit

VCUBE-2#conf t

VCUBE-2(config)#track 1 interface GigabitEthernet1 line-protocol

VCUBE-2(config-track)#track 2 interface GigabitEthernet2 line-protocol

VCUBE-2(config-track)#exit

トラッキング CLI は、トラフィック インターフェイスがダウンした後、アクティブ ルートがアクティブな役割を果たすように、RG 内で音声トラフィックインターフェイスの状態を追跡するために使用されます。

2

アプリケーション冗長性サブモード下の VoIP HA で使用する RG を構成します。

redundancy
  application redundancy
   group 1
    name LocalGateway-HA
    priority 100 failover threshold 75
    control GigabitEthernet3 protocol 1
    data GigabitEthernet3
    timers delay 30 reload 60
    track 1 shutdown
    track 2 shutdown
    exit
   protocol 1
    timers hellotime 3 holdtime 10
   exit
  exit
 exit 

VCUBE-1(config)#redundancy

VCUBE-1(config-red)#application redundancy

VCUBE-1(config-red-app)#group 1

VCUBE-1(config-red-app-grp)#name LocalGateway-HA

VCUBE-1(config-red-app-grp)#priority 100 failover threshold 75

VCUBE-1(config-red-app-grp)#control GigabitEthernet3 protocol 1

VCUBE-1(config-red-app-grp)#data GigabitEthernet3

VCUBE-1(config-red-app-grp)#timers delay 30 reload 60

VCUBE-1(config-red-app-grp)#track 1 shutdown

VCUBE-1(config-red-app-grp)#track 2 shutdown

VCUBE-1(config-red-app-grp)#exit

VCUBE-1(config-red-app)#protocol 1

VCUBE-1(config-red-app-prtcl)#timers hellotime 3 holdtime 10

VCUBE-1(config-red-app-prtcl)#exit

VCUBE-1(config-red-app)#exit

VCUBE-1(config-red)#exit

VCUBE-1(config)#

VCUBE-2(config)#redundancy

VCUBE-2(config-red)#application redundancy

VCUBE-2(config-red-app)#group 1

VCUBE-2(config-red-app-grp)#name LocalGateway-HA

VCUBE-2(config-red-app-grp)#priority 100 failover threshold 75

VCUBE-2(config-red-app-grp)#control GigabitEthernet3 protocol 1

VCUBE-1(config-red-app-grp)#data GigabitEthernet3

VCUBE-2(config-red-app-grp)#timers delay 30 reload 60

VCUBE-2(config-red-app-grp)#track 1 shutdown

VCUBE-2(config-red-app-grp)#track 2 shutdown

VCUBE-2(config-red-app-grp)#exit

VCUBE-2(config-red-app)#protocol 1

VCUBE-2(config-red-app-prtcl)#timers hellotime 3 holdtime 10

VCUBE-2(config-red-app-prtcl)#exit

VCUBE-2(config-red-app)#exit

VCUBE-2(config-red)#exit

VCUBE-2(config)#

この構成で使用されるフィールドの説明を次に示します。

  • redundancy—Enters redundancy mode

  • application redundancy—Enters application redundancy configuration mode

  • group—Enters redundancy application group configuration mode

  • name LocalGateway-HA—Defines the name of the RG group

  • priority 100 failover threshold 75—Specifies the initial priority and failover thresholds for an RG

  • timers delay 30 reload 60—Configures the two times for delay and reload

    • インターフェイスが起動した後、RG グループの初期設定と役割のネゴシエーションの遅延時間を示す遅延タイマーです。デフォルトは 30 秒です。範囲は 0-10000 秒です

    • Reload—これは、リロード後の RG グループ初期設定と役割ネゴシエーションの遅延時間です。デフォルトは 60 秒です。範囲は 0-10000 秒です

    • デフォルトのタイマーが推奨されていますが、これらのタイマーは、ネットワークのルーティングが安定した時点の後、RG プロトコルのネゴシエーションが行われることを保証するために、ルーターの起動/再読み込み中に発生する可能性がある追加のネットワーク集約遅延に合わせて調整される場合があります。たとえば、フェールオーバー後に、新しいスタンバイに最大 20 秒間かかり、新しいアクティブから最初の RG HELLO パケットを確認する場合は、この遅延を考慮して、最初の RG HELLO パケットを「タイマー遅延 60 リロード 120」に調整する必要があります。

  • control GigabitEthernet3 protocol 1—Configures the interface used to exchange keepalive and hello messages between the two CUBEs, and specifies the protocol instance that will be attached to a control interface and enters redundancy application protocol configuration mode

  • data GigabitEthernet3—Configures the interface used for checkpointing of data traffic

  • track—RG group tracking of interfaces

  • protocol 1—Specifies the protocol instance that will be attached to a control interface and enters redundancy application protocol configuration mode

  • timers hellotime 3 holdtime 10—Configures the two timers for hellotime and holdtime:

    • Hellotime— 連続する hello メッセージの間隔 (デフォルトで 3 秒)。範囲は 250 ミリ秒から 254 秒です

    • Holdtime — Hello メッセージの受信と送信ルーターが失敗した推定の間隔。この継続時間は、hello time (デフォルトの 10 秒より長くする必要があります) 以上である必要があります。範囲は 750 ミリ秒から 255 秒です

      Holdtime タイマーを hellotime タイマーの最低 3 倍の値に設定することをお勧めします。

3

CUBE アプリケーションのボックス間の冗長性を有効にします。[voice service voip] の以前の手順から RG を構成します。これにより、CUBE アプリケーションは冗長性プロセスをコントロールすることができます。

voice service voip
   redundancy-group 1
   exit

VCUBE-1(config)#voice service voip

VCUBE-1(config-voi-serv)#redundancy-group 1

 % Created RG 1 association with Voice B2B HA; reload the router for the new configuration to take effect 

VCUBE-1(config-voi-serv)# exit

VCUBE-2(config)#voice service voip

VCUBE-2(config-voi-serv)#redundancy-group 1

 % Created RG 1 association with Voice B2B HA; reload the router for the new configuration to take effect 

VCUBE-2(config-voi-serv)# exit

redundancy-group 1—Adding and removing this command requires a reload for the updated configuration to take effect. すべての構成が適用された後で、プラットフォームを再読み込みします。

4

以下に示すように、Gig1 と Gig2 インターフェイスをそれぞれの仮想 IP で構成し、冗長性インターフェイス識別子 (rii) を適用します。

VCUBE-1(config)#interface GigabitEthernet1

VCUBE-1(config-if)# redundancy rii 1

VCUBE-1(config-if)# redundancy group 1 ip 198.18.1.228 exclusive

VCUBE-1(config-if)# exit

VCUBE-1(config)#

VCUBE-1(config)#interface GigabitEthernet2

VCUBE-1(config-if)# redundancy rii 2

VCUBE-1(config-if)# redundancy group 1 ip 198.18.133.228 exclusive

VCUBE-1(config-if)# exit

VCUBE-2(config)#interface GigabitEthernet1

VCUBE-2(config-if)# redundancy rii 1

VCUBE-2(config-if)# redundancy group 1 ip 198.18.1.228 exclusive

VCUBE-2(config-if)# exit

VCUBE-2(config)#

VCUBE-2(config)#interface GigabitEthernet2

VCUBE-2(config-if)# redundancy rii 2

VCUBE-2(config-if)# redundancy group 1 ip 198.18.133.228 exclusive

VCUBE-v(config-if)# exit

この構成で使用されるフィールドの説明を次に示します。

  • redundancy rii—Configures the redundancy interface identifier for the redundancy group. 仮想 MAC (VMAC) アドレスを生成するために必要です。同じ VIP を持つ各ルーター (アクティブ/スタンバイ) のインターフェイスで同じ rii ID 値を使用する必要があります。

    If there is more than one B2B pair on the same LAN, each pair MUST have unique rii IDs on their respective interfaces (to prevent collision). ‘show redundancy application group all’ should indicate the correct local and peer information.

  • redundancy group 1—Associates the interface with the redundancy group created in Step 2 above. RG グループ、およびこの物理インターフェイスに割り当てられた VIP を構成します。

    冗長性のために別のインターフェイスを使用することが必須です。つまり、音声トラフィックに使用されるインターフェイスは、上記の手順 2 で指定したコントロールとデータ インターフェイスとして使用できません。この例では、RG コントロール/データにギガビット インターフェイス 3 が使用されています。

5

最初の CUBE 構成を保存し、再読み込みします。

最後にリロードするプラットフォームは常にスタンバイです。

VCUBE-1#wr

 構成を検証しています... 

 [OK] 

VCUBE-1#reload

 Proceed with reload? [confirm]

VCUBE-1 が完全に起動したら、 VCUBE-2 の構成を保存し、再読み込みします。

VCUBE-2#wr

 構成を検証しています... 

 [OK] 

VCUBE-2#reload

 Proceed with reload? [confirm]

6

ボックス間の構成が期待どおりに機能していることを確認します。関連する出力は太字で強調表示されます。

VCUBE-2 を最後にリロードし、設計上の考慮事項に従います。最後にリロードするプラットフォームは常に [スタンバイ] 状態です。 

 VCUBE-1#show redundancy application group all Faults states Group 1 info: Runtime priority: [100] RG Faults RG State: UP. Total # of switchovers due to faults: 0 Total # of down/up state changes due to faults: 0 Group ID:1 Group Name:LocalGateway-HA Administrative State: No Shutdown Aggregate operational state: Up My Role: ACTIVE Peer Role: STANDBY Peer Presence: Yes Peer Comm: Yes Peer Progression Started: Yes RF Domain: btob-one RF state: ACTIVE Peer RF state: STANDBY HOT RG Protocol RG 1 ------------------ Role: Active Negotiation: Enabled Priority: 100 Protocol state: Active Ctrl Intf(s) state: Up Active Peer: Local Standby Peer: address 10.1.1.2, priority 100, intf Gi3 Log counters: role change to active: 1 role change to standby: 1 disable events: rg down state 0, rg shut 0 ctrl intf events: up 1, down 0, admin_down 0 reload events: local request 0, peer request 0 RG Media Context for RG 1 -------------------------- Ctx State: Active Protocol ID: 1 Media type: Default Control Interface: GigabitEthernet3 Current Hello timer: 3000 Configured Hello timer: 3000, Hold timer: 10000 Peer Hello timer: 3000, Peer Hold timer: 10000 Stats: Pkts 1509, Bytes 93558, HA Seq 0, Seq Number 1509, Pkt Loss 0 Authentication not configured Authentication Failure: 0 Reload Peer: TX 0, RX 0 Resign: TX 0, RX 0 Standy Peer: Present. Hold Timer: 10000 Pkts 61, Bytes 2074, HA Seq 0, Seq Number 69, Pkt Loss 0 VCUBE-1#
 VCUBE-2#show redundancy application group all Faults states Group 1 info: Runtime priority: [100] RG Faults RG State: UP. Total # of switchovers due to faults: 0 Total # of down/up state changes due to faults: 0 Group ID:1 Group Name:LocalGateway-HA Administrative State: No Shutdown Aggregate operational state: Up My Role: STANDBY Peer Role: ACTIVE Peer Presence: Yes Peer Comm: Yes Peer Progression Started: Yes RF Domain: btob-one RF state: ACTIVE Peer RF state: STANDBY HOT RG Protocol RG 1 ------------------ Role: Active Negotiation: Enabled Priority: 100 Protocol state: Active Ctrl Intf(s) state: Up Active Peer: address 10.1.1.2, priority 100, intf Gi3 Standby Peer: Local Log counters: role change to active: 1 role change to standby: 1 disable events: rg down state 0, rg shut 0 ctrl intf events: up 1, down 0, admin_down 0 reload events: local request 0, peer request 0 RG Media Context for RG 1 -------------------------- Ctx State: Active Protocol ID: 1 Media type: Default Control Interface: GigabitEthernet3 Current Hello timer: 3000 Configured Hello timer: 3000, Hold timer: 10000 Peer Hello timer: 3000, Peer Hold timer: 10000 Stats: Pkts 1509, Bytes 93558, HA Seq 0, Seq Number 1509, Pkt Loss 0 Authentication not configured Authentication Failure: 0 Reload Peer: TX 0, RX 0 Resign: TX 0, RX 0 Standy Peer: Present. Hold Timer: 10000
            Pkts 61, Bytes 2074, HA Seq 0, Seq Number 69, Pkt Loss 0

VCUBE-2#

両方の CUBE でローカル ゲートウェイを構成する

この例の構成では、Control Hub から以下のトランク情報を使用して、VCUBE-1、VCUBE-2 の両方のプラットフォームでローカルゲートウェイを構成しています。この設定のユーザー名とパスワードは以下のとおりです。

  • ユーザー名:Hussain1076_LGU

  • パスワード:lOV12MEaZx

1

クレデンシャルまたは共有秘密で使用する前に、以下のコマンドを使用して、設定キーがパスワードに対して作成されていることを確認してください。Type 6 パスワードは、AES 暗号化とこのユーザー定義の設定キーを使用して暗号化されます。 

 LocalGateway#conf t LocalGateway(config)#key config-key password-encrypt Password123 LocalGateway(config)#password encryption aes

これは、上に表示されている Control Hub のパラメーターに基づき、両方のプラットフォームに適用し、保存し、リロードするローカ ルゲートウェイの構成です。SIP Digest credentials from Control Hub are highlighted in bold.

 configure terminal crypto pki trustpoint dummyTp revocation-check crl exit sip-ua crypto signaling default trustpoint dummyTp cn-san-validate server transport tcp tls v1.2 end configure terminal crypto pki trustpool import clean url http://www.cisco.com/security/pki/trs/ios_core.p7b end configure terminal voice service voip ip address trusted list ipv4 x.x.x.x y.y.y.y exit allow-connections sip to sip media statistics media bulk-stats no supplementary-service sip refer no supplementary-service sip handle-replaces fax protocol pass-through g711ulaw stun stun flowdata agent-id 1 boot-count 4 stun flowdata shared-secret 0 Password123! sip g729 annexb-all early-offer forced end configure terminal voice class sip-profiles 200 rule 9 request ANY sip-header SIP-Req-URI modify "sips:(.*)" "sip:\1" rule 10 request ANY sip-header To modify "<sips:(.*)" "<sip:\1" rule 11 request ANY sip-header From modify "<sips:(.*)" "<sip:\1" rule 12 request ANY sip-header Contact modify "<sips:(.*)>" "<sip:\1;transport=tls>" rule 13 response ANY sip-header To modify "<sips:(.*)" "<sip:\1" rule 14 response ANY sip-header From modify "<sips:(.*)" "<sip:\1" rule 15 response ANY sip-header Contact modify "<sips:(.*)" "<sip:\1" rule 20 request ANY sip-header From modify ">" ";otg=hussain1076_lgu>" rule 30 request ANY sip-header P-Asserted-Identity modify "sips:(.*)" "sip:\1" voice class codec 99 codec preference 1 g711ulaw codec preference 2 g711ulaw exit voice class srtp-crypto 200 crypto 1 AES_CM_128_HMAC_SHA1_80 exit voice class stun-usage 200 stun usage firewall-traversal flowdata exit voice class tenant 200 registrar dns:40462196.cisco-bcld.com scheme sips expires 240 refresh-ratio 50 tcp tls credentials number Hussain5091_LGU username Hussain1076_LGU password 0 lOV12MEaZx realm Broadworks authentication username Hussain5091_LGU password 0 lOV12MEaZx realm BroadWorks authentication username Hussain5091_LGU password 0 lOV12MEaZx realm 40462196.cisco-bcld.com no remote-party-id sip-server dns:40462196.cisco-bcld.com connection-reuse srtp-crypto 200 session transport tcp tls url sips error-passthru asserted-id pai bind control source-interface GigabitEthernet1 bind media source-interface GigabitEthernet1 no pass-thru content custom-sdp sip-profiles 200 outbound-proxy dns:la01.sipconnect-us10.cisco-bcld.com privacy-policy passthru voice class tenant 100 session transport udp url sip error-passthru bind control source-interface GigabitEthernet2 bind media source-interface GigabitEthernet2 no pass-thru content custom-sdp voice class tenant 300 bind control source-interface GigabitEthernet2 bind media source-interface GigabitEthernet2 no pass-thru content custom-sdp voice class uri 100 sip host ipv4:198.18.133.3 voice class uri 200 sip pattern dtg=hussain1076.lgu dial-peer voice 101 voip description Outgoing dial-peer to IP PSTN destination-pattern BAD.BAD session protocol sipv2 session target ipv4:198.18.133.3 voice-class codec 99 voice-class sip tenant 100 dtmf-relay rtp-nte no vad dial-peer voice 201 voip description Outgoing dial-peer to Webex Calling destination-pattern BAD.BAD session protocol sipv2 session target sip-server voice-class codec 99 voice-class stun-usage 200 no voice-class sip localhost voice-class sip tenant 200 dtmf-relay rtp-nte srtp no vad voice class dpg 100 description Incoming WebexCalling(DP200) to IP PSTN(DP101) dial-peer 101 preference 1 voice class dpg 200 description Incoming IP PSTN(DP100) to Webex Calling(DP201) dial-peer 201 preference 1 dial-peer voice 100 voip desription Incoming dial-peer from IP PSTN session protocol sipv2 destination dpg 200 incoming uri via 100 voice-class codec 99 voice-class sip tenant 300 dtmf-relay rtp-nte no vad dial-peer voice 200 voip description Incoming dial-peer from Webex Calling session protocol sipv2 destination dpg 100 incoming uri request 200 voice-class codec 99 voice-class stun-usage 200 voice-class sip tenant 200 dtmf-relay rtp-nte srtp no vad end copy run start

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 

 VCUBE-1#show redundancy application group 1 Group ID:1 Group Name:LocalGateway-HA Administrative State: No Shutdown Aggregate operational state : Up My Role: Standby Peer Role: ACTIVE Peer Presence: Yes Peer Comm: Yes Peer Progression Started: Yes RF Domain: btob-one RF state: STANDBY HOT Peer RF state: ACTIVE VCUBE-1#show sip-ua register status VCUBE-1#

 VCUBE-2#show redundancy application group 1 Group ID:1 Group Name:LocalGateway-HA Administrative State: No Shutdown Aggregate operational state : Up My Role: ACTIVE Peer Role: STATUS Peer Presence: Yes Peer Comm: Yes Peer Progression Started: Yes RF Domain: btob-one RF state: ACTIVE Peer RF state: STANDBY HOT VCUBE-2#show sip-ua register status Tenant: 200 --------------------Registrar-Index 1 --------------------- Line peer expires(sec) reg survival P-Associ-URI ============================== ========== ============ === ======== ============ Hussain5091_LGU -1 48 yes normal VCUBE-2#

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 で次のデバッグを有効にします

 VCUBE-1#debug ccsip non-call SIP Out-of-Dialog tracing is enabled VCUBE-1#debug ccsip info SIP Call info tracing is enabled VCUBE-1#debug ccsip message

4

この場合、アクティブ LGW、VCUBE-2 で次のコマンドを実行してフェールオーバーをシミュレートします。

 VCUBE-2#redundancy application reload group 1 self

アクティブからスタンバイ LGW への切り替えは、上記に一覧表示されている CLI に加えて、以下のシナリオで発生します。

  • アクティブ ルーターのリロード時

  • アクティブなルーターの電源が再投入される時

  • トラッキングが有効になっているアクティブなルーターの RG 構成されたインターフェイスがシャットダウンされる時

5

VCUBE-1 が Webex Calling アクセス SBC に登録されているかどうかを確認します。VCUBE-2 は今すぐにリロードされます。

 VCUBE-1#show sip-ua register status Tenant: 200 --------------------Registrar-Index 1 --------------------- Line peer expires(sec) reg survival P-Associ-URI ============================== ========== ============ === ======== ============ Hussain5091_LGU -1 56 yes normal VCUBE-1#

VCUBE-1 がアクティブ LGW になりました。

6

仮想 IP を通じて SIP REGISTER を Webex Calling に送信し、200 OK を受信する VCUBE-1 に関連するデバッグ ログを確認してください。

 VCUBE-1#show log Jan 9 18:37:24.769: %RG_MEDIA-3-TIMEREXPIRED: RG id 1 Hello Time Expired. Jan 9 18:37:24.771: %RG_PROTCOL-5-ROLECHANGE: RG id 1 role change from Standby to Active Jan 9 18:37:24.783: %VOICE_HA-2-SWITCHOVER_IND: SWITCHOVER, from STANDBY_HOT to ACTIVE state. Jan 9 18:37:24.783: //-1/xxxxxxxxxxxx/SIP/Info/info/4096/sip_ha_notify_active_role_event: Received notify active role event Jan 9 18:37:25.758: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:送信日時: REGISTER sip: 40462196.cisco-bcld.com:5061 SIP/2.0 Via: SIP/2.0/TLS 198.18.1.228:5061;branch=z9hG4bK0374 From: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189 To: <sip:Hussain5091_LGU@40462196.cisco-bcld.com> Date: Thu, 09 Jan 2020 18:37:24 GMT Call-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97 User-Agent: Cisco-SIPGateway/IOS-16.12.02 Max-Forwards: 70 Timestamp: 1578595044 CSeq: 2 REGISTER Contact: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls> Expires: 240 Supported: path Content-Length: 0 

Jan 9 18:37:25.995: //-1/000000000000/SIP/Msg/ccsipDisplayMsg:Received: SIP/2.0 401 Unauthorized Via: SIP/2.0/TLS 198.18.1.228:5061;received=173.38.218.1;branch=z9hG4bK0374;rport=4742 From: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189 To: <sip:Hussain5091_LGU@40462196.cisco-bcld.com>;tag=SD1u8bd99-1324701502-1578595045969 Date: Thu, 09 Jan 2020 18:37:24 GMT Call-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97 Timestamp: 1578595044 CSeq: 2 REGISTER WWW-Authenticate; DIGEST realm="BroadWorks",qop="auth",nonce="BroadWorksXk572qd01Ti58zliBW",algorithm=MD5 Content-Length: 0 

Jan 9 18:37:26.000: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:送信日時: REGISTER sip:40462196.cisco-bcld.com:5061 SIP/2.0 Via: SIP/2.0/TLS 198.18.1.228:5061;branch=z9hG4bK16DC From: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189 To: <sip:Hussain5091_LGU@40462196.cisco-bcld.com> Date: Thu, 09 Jan 2020 18:37:25 GMT Call-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97 User-Agent:Cisco-SIPGateway/IOS-16.12.02 Max-Forwards: 70 Timestamp: 1578595045 CSeq: 3 REGISTER Contact: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls> Expires: 240 Supported: path Authorization: Digest username="Hussain1076_LGU",realm="BroadWorks",uri="sips:40462196.cisco-bcld.com:5061",response="b6145274056437b9c07f7ecc08ebdb02",nonce="BroadWorksXk572qd01Ti58z1iBW",cnonce="3E0E2C4D",qop=auth,algorithm=MD5,nc=00000001 Content-Length: 0 

Jan 9 18:37:26.190: //1/000000000000/SIP/Msg/ccsipDisplayMsg:Received: SIP/2.0 200 OK Via: SIP/2.0/TLS 198.18.1.228:5061;received=173.38.218.1;branch=z9hG4bK16DC;rport=4742 From: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189 To: <sip:Hussain5091_LGU@40462196.cisco-bcld.com>;tag=SD1u8bd99-1897486570-1578595-46184 Call-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97 Timestamp: 1578595045 CSeq: 3 REGISTER Contact: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls>;expires=120;q=0.5 Allow-Events: call-info,line-seize,dialog,message-summary,as-feature-event,x-broadworks-hoteling,x-broadworks-call-center-status,conference Content-Length: 0

Webex Calling のために Unified CM を構成する

ローカル ゲートウェイへトランクするための SIP トランク セキュリティ プロファイルを構成する

ローカル ゲートウェイと PSTN ゲートウェイが同じデバイス上に存在する場合、Unified CM を有効にして、同じデバイスから発信された 2 個の異なるトラフィックの種類 (Webex と PSTN のコール) を区別し、これらのコール タイプに対して差別化されたクラスのサービスを適用する必要があります。この差別化されたコール処理は、Unified CM および結合されたローカル ゲートウェイと PSTN ゲートウェイ デバイスの 2 つのトランクをプロビジョニングすることで行われます。これは、2 つのトランクに異なる SIP リスニング ポートを必要とします。

次の設定でローカル ゲートウェイ トランクの専用の SIP トランク セキュリティ プロファイルを作成します。

設定値
名前Webexなどの一意の名前
説明意味のある説明（Webex SIP トランク セキュリティ プロファイルなど）
着信ポートWebex 間のトラフィックでは、ローカル ゲートウェイ構成で使用されるポートと一致する必要があります。5065

ローカル ゲートウェイ トランクの SIP プロファイルを構成する

次の設定でローカル ゲートウェイ トランク用の専用の SIP プロファイルを作成します。

設定値
名前Webexなどの一意の名前
説明Webex SIP プロファイルなどの意味のある説明
オプションの Ping を有効にして、サービス タイプ「なし (デフォルト)」のトランクの宛先ステータスをモニタします。選択

Webex からのコールのコール検索スペースを作成する

次の設定で Webex から発信されたコールのためのコール検索スペースを作成します。

設定値
名前Webexなどの一意の名前
説明Webex コーリング サーチ スペースなど、意味のある説明
選択済みパーティション:

DN (+E.164 ディレクトリ番号)

ESN (短縮された施設間ダイヤル)

PSTNInternational (PSTNアクセス)

onNetRemote (GDPRで学習した宛先)

最後のパーティション onNetRemote は、Intercluster Lookup Service (ILS) または Global Dialplan Replication (GDPR) を使用して、Unified CM クラスター間でルーティング情報が交換されるマルチクラスター環境でのみ使用されます。

Webex 間で SIP トランクを構成する

次の設定を使用して、ローカル ゲートウェイ経由での Webex 間のコールに SIP トランクを作成します。

設定値
デバイス情報
DeviceNameWebexなどの一意の名前
説明意味のある説明 (Webex SIP トランクなど)
すべてのアクティブな Unified CM ノード上で実行する選択
着信コール
コール検索スペース以前に定義されたコール検索スペース:Webex (ウェベックス)
AAR コール検索スペース PSTN ルート パターンへのアクセス権のみを持つコール検索スペース: PSTNReroute
SIP 情報
接続先アドレスローカル ゲートウェイ CUBE の IP アドレス
移動先ポート5060
SIP トランク セキュリティ プロファイル定義済み:Webex (ウェベックス)
SIP プロファイル定義済み:Webex (ウェベックス)

Webex のルート グループを構成する

次の設定でルート グループを作成します。

設定値
ルート グループ情報
ルート グループ名Webexなどの一意の名前
選択したデバイス以前に構成された SIP トランク:Webex (ウェベックス)

Webex のルート リストを構成する

次の設定でルート リストを作成します。

設定値
ルート リスト情報
名前一意の名前（RL_Webexなど）
説明意味のある説明（Webex のルート リストなど）
すべてのアクティブな Unified CM ノード上で実行する選択
ルート リスト メンバー情報
選択したグループ以前に定義されたルート グループのみ:Webex (ウェベックス)

Webex の移動先のパーティションを作成する

次の設定で Webex の移動先のパーティションを作成します。

設定値
ルート リスト情報
名前Webexなどの固有の名前
説明意味のある説明（Webex Partitionなど）

次にやる必要

このパーティションは、Webex の宛先にアクセスする必要があるすべてのコール検索スペースに追加してください。このパーティションは、PSTN から Webex への発信がルーティングされるように、PSTN トランクの着信コール検索スペースとして使用されるコール検索スペースに特に追加する必要があります。

Webex の移動先のルート パターンを構成する

次の設定で Webex の各 DID 範囲のルート パターンを構成します。

設定値
ルートパターン「\」が頭文字にある Webex で DID 範囲のフル +E.164 パターン例: \+140855501XX
ルート パーティションWebex (ウェベックス)
ゲートウェイ/ルート リストRL_Webex
緊急の優先事項選択

Webex の簡略サイト間ダイヤル正規化を構成する

短縮されたサイト間ダイヤルが Webex に必要な場合は、Webex の各 ESB 範囲にダイヤル正規化パターンを設定します。

設定値
翻訳パターンWebex の ESN 範囲の ESB パターン。例:80121XX
パーティションWebex (ウェベックス)
説明Webex 正規化パターンなどの意味のある説明
発信者のコール検索スペースを使用する選択
緊急の優先事項選択
後続ホップでの連続桁のタイムアウトを待たない選択
着信側トランスフォーム マスク番号を + E.164 に正規化するマスク。例:+140855501XX

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）] フィールドに入力された名前です。

どうやったか見たいか? Control Hub でユーザーのモニタリング設定を管理する方法については、このビデオ デモンストレーション をご覧ください。

ユーザーのコール ブリッジ警告トーンを有効にする

スケジューリングを始める前に

コール ブリッジを呼び出すには、共有回線を設定する必要があります。コール ブリッジの警告トーンが再生される前に、共有回線を設定する 方法を参照してください。
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

[保存] をクリックします。

ユーザは、ユーザ ハブから使用するホテリング ホストを検索し、検索することもできます。詳細については、「どこからでも通話プロファイルにアクセスする」を参照してください。

どうやったか見たいか? Control Hub でホテリングを設定する方法については、このビデオ デモンストレーション をご覧ください。

Webex Calling の採用傾向と使用状況レポート

通話レポートを表示する

Control Hub の [アナリティクス] ページを使用して、ユーザーがどのように Webex Calling と Webex アプリ (エンゲージメント) を使用しているか、また、通話のメディア エクスペリエンスの質について洞察を得ることができます。Webex Calling アナリティクスにアクセスするには、Control Hub にサインインし、[アナリティクス ] に移動して [通話 ] タブを選択します。

1

通話履歴レポートの詳細については、Control Hub にサインインし、[分析 ] > [通話] の順に移動します。

2

[通話履歴の詳細] を選択します。

専用インスタンスを使用する通話の詳細については、「専用インスタンスの分析」を参照してください。

3

メディア品質データにアクセスするには、Control Hub にサインインし、[Analytics ] に移動して [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 注文ガイドのローカル ゲートウェイの表 1 を参照してください。 また、ローカル ゲートウェイ設定ガイドに従って、プラットフォームがサポートされている IOS-XE リリースを実行していることを確認してください。

ローカル ゲートウェイは、自分のペースで 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

次のオプションから選択します:

  • パートナー管理者の場合は、[保存して閉じる] をクリックして、顧客管理者が Webex Calling のプロビジョニングを完了するようにします。
  • 必要なロケーションの情報を入力します。 ウィザードでロケーションを作成した後、後で他にロケーションを作成できます。

セットアップ ウィザードを完了した後で、作成したロケーションにメイン番号を追加していることを確認してください。

7

このロケーションに適用する次の選択を行います。

  • 通知言語 - 新しいユーザーと機能に関する音声通知とプロンプト用。
  • メール言語 - 新規ユーザー向けメールのコミュニケーション。
  • 国
  • タイムゾーン
8

[次へ] をクリックします。

9

利用可能な Cisco Webex SIP アドレスを入力し、[次へ] をクリックし、[完了] を選択します。

ロケーションを追加する

始める前に

新しいロケーションを作成するには、以下の情報を指定します。

  • ロケーションの住所

  • 希望する電話番号(オプション)

1

https://admin.webex.comでControl Hubにログインし、に移動します。 管理 > 場所。

新しいロケーションは、初回セットアップウィザードを使用して選択した国に対応する地域データセンターでホストされます。
2

ロケーションを設定します。

  • ロケーション名 - ロケーションを識別するための一意の名前を入力します。
  • 国/地域 - ロケーションに関連付ける国を選択します。 たとえば、米国に 1 か所のロケーション (本社) を作成し、イギリスに別のロケーション (支社) を作成することができます。 選択した国に応じて、その後の住所のフィールドが決まります。 ここには、例として、米国の住所書式を使用したものがあります。
  • ロケーションの住所 - ロケーションの郵送先住所の主要部分を入力します。
  • 市区町村 - このロケーションが所在する市区町村を入力します。
  • 都道府県 - ドロップダウンから都道府県を選択します。
  • 郵便番号-ZIP または郵便番号を入力します。
  • 通知言語 - 新規ユーザーと機能に関する音声通知と音声プロンプトで使用する言語を選択します。
  • メール言語 - 新規ユーザーとのメール通信に使用する言語を選択します。
  • タイムゾーン - ロケーションのタイム ゾーンを選択します。
3

［保存］をクリックし、［はい／いいえ］を選択して、現在または後でロケーションに番号を追加します。

4

「はい」をクリックした場合は、次のいずれかのオプションを選択します。

  • Cisco PSTN - Cisco の Cloud PSTN ソリューションが必要な場合は、このオプションを選択します。 Cisco Calling プランは、緊急通話、国内および国際電話の着信および発信を提供する完全な PSTN 代替ソリューションであり、新しい PSTN 番号を注文したり、既存の番号を Cisco にポートしたりできます。

    Cisco PSTN オプションは、以下の条件でのみ表示されます。

    • コミットされた Cisco Calling プラン OCP (アウトバウンド通話プラン) を少なくとも 1 つ購入している。

    • Cisco Calling プランがサポートされている国にロケーションがある。

    • ロケーションが新規である。 他の PSTN 機能が割り当てられている既存のロケーションは、今回は Cisco Calling プランの対象外です。 サポート ケースを開いてご相談ください。

    • Cisco Calling プランがサポートされている地域の Webex Calling データセンターでホストされています。

  • Cloud Connected PSTN - 多くの Cisco CCP パートナーの 1 つからクラウド PSTN ソリューションを探している場合、またはロケーションで Cisco Calling プランが利用できない場合は、このオプションを選択します。 CCP パートナーは、PSTN 代替ソリューション、グローバルな広域カバレッジ、広範でさまざまな機能、パッケージ、価格設定を提供しています。

    CCP パートナーと対応地域は、こちらにリストされています。 ロケーションの国がサポートされているパートナーにのみ表示されています。 パートナーは、ロゴで表示されるか、簡単な文字列と括弧で囲んだ地域名で表示されます (例 : (EU)、(US)、または (CA))。 ロゴが表示されているパートナーは、常に CCP の地域メディアを提供しています。 文字列で表示されているパートナーについては、CCP の地域メディアを確保するために、ロケーションの国に最も近い地域を選択してください。

    リストされているプロバイダーの下に [番号を今すぐ注文する] オプションがある場合は、そのオプションを選択して、統合された CCP のメリットを利用することをおすすめします。 統合された CCP の場合、電話番号の調達とプロビジョニングを Control Hub の 1 つのペインで行えます。 統合されていない CCP の場合、Control Hub の外で、CCP パートナーから電話番号を調達する必要があります。

  • プレミスベースのPSTN(ローカル ゲートウェイ)-現在の PSTN プロバイダーを保持する場合、またはクラウド サイトでクラウド サイト以外に接続する場合、このオプションを選択できます。

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](ローカル ゲートウェイ) のいずれかを選択します。 [管理] をクリックして設定を変更してから、[続行] を選択することにより、関連するリスクを承認します。 以下のオプションのいずれかを選択して、[保存] クリックします。

  • Cisco PSTN - Cisco の Cloud PSTN ソリューションが必要な場合は、このオプションを選択します。 Cisco Calling プランは、緊急通話、国内および国際電話の着信および発信を提供する完全な PSTN 代替ソリューションであり、新しい PSTN 番号を注文したり、既存の番号を Cisco にポートしたりできます。

    Cisco PSTN オプションは、以下の条件でのみ表示されます。

    • コミットされた Cisco Calling プラン OCP (アウトバウンド通話プラン) を少なくとも 1 つ購入している。

    • Cisco Calling プランがサポートされている国にロケーションがある。

    • ロケーションが新規である。 現在、他の PSTN 機能が割り当てられている既存のロケーションは、Cisco Calling プランの対象外です。 サポート ケースを開いてご相談ください。

    • Cisco Calling プランがサポートされている地域の Webex Calling データセンターでホストされています。

  • Cloud Connected PSTN - 多くの Cisco CCP パートナーの 1 つからクラウド PSTN ソリューションを探している場合、またはロケーションで Cisco Calling プランが利用できない場合は、このオプションを選択します。 CCP パートナーは、PSTN 代替ソリューション、グローバルな広域カバレッジ、広範でさまざまな機能、パッケージ、価格設定を提供しています。

    CCP パートナーと対応地域は、こちらにリストされています。 ロケーションの国がサポートされているパートナーにのみ表示されています。 パートナーは、ロゴで表示されるか、簡単な文字列と括弧で囲んだ地域名で表示されます (例 : (EU)、(US)、または (CA))。 ロゴが表示されているパートナーは、常に CCP の地域メディアを提供しています。 文字列で表示されているパートナーについては、CCP の地域メディアを確保するために、ロケーションの国に最も近い地域を選択してください。

    リストされているプロバイダーの下で番号を今すぐ注文するオプションが表示された場合は、そのオプションを選択して、統合型CCPを利用することをお勧めします。 統合された CCP の場合、電話番号の調達とプロビジョニングを Control Hub の 1 つのペインで行えます。 統合されていない CCP では、Control Hub 以外の CCP パートナーから電話番号を取得する必要があります。

  • プレミスベースの PSTN（ローカルゲートウェイ）:現在の PSTN プロバイダーを保持する場合、またはクラウド以外のサイトをクラウドサイトに接続する場合は、このオプションを選択できます。

    以前にローカル ゲートウェイで設定されたロケーションを持つ Webex Calling の顧客は、対応するトランクを持つプレミス ベースの PSTN に自動的に変換されます。

3

ロケーションで、ドロップダウンリストから代表番号を選択し、そのロケーションのユーザーがコールを発信および受信できるようにします。

メイン番号を自動アテンダントに割り当てて、外部発信者がそのロケーションの Webex Calling ユーザーに連絡できるようにします。 そのロケーションの Webex Calling ユーザーは、発信時にこの番号を外部発信者 ID として使用することもできます。
4

(オプション) [緊急コール] で[緊急時のロケーション識別子] を選択して、このロケーションに割り当てることができます。

この設定はオプションであり、必要な国でのみ適用されます。

一部の国では (例: フランス)は、緊急通報を行い、緊急当局が利用できるようにしたときに、セル無線システムがセルのIDを確立するための規制要件が存在します。 米国やカナダのような他の国々は、他の方法を用いて位置決定を実施しています。 詳細については、「強化された緊急コール」を参照してください。

緊急コール プロバイダーは、アクセス ネットワークに関する情報を必要とする場合があります。これは、新しいプライベート SIP 拡張ヘッダー P-Access-Network-Info を定義することによって実現されます。 ヘッダーにはアクセスネットワークに関する情報が格納されます。

ロケーションの緊急ロケーション識別子を設定すると、ロケーションの値が SIP メッセージの一部としてプロバイダーに送信されます。 緊急コール プロバイダーに連絡して、この設定が必要かどうかを確認し、緊急コール プロバイダーが提供する値を使用します。

5

このロケーションでユーザーがボイスメールをチェックするために呼び出せる [ボイスメール番号] を選択します。

6

(オプション) ロケーション ページの上部にある鉛筆アイコンをクリックし、必要に応じて [ロケーションの名前]、[アナウンス言語]、[メール言語]、[タイムゾーン]、[住所] を変更し、[保存] をクリックします。

[アナウンス言語] の変更は、このロケーションに追加された新規ユーザーや機能に対して直ちに有効になります。 既存のユーザーや機能のアナウンス言語も変更する必要がある場合は、プロンプトが表示されたら、[既存のユーザーとワークスペースの変更] または [既存機能の変更] を選択します。 [適用] をクリックします。 [タスク] ページで進捗状況を確認できます。 これが完了するまでは、これ以上変更を加えることはできません。

ロケーションの [タイム ゾーン] を変更しても、このロケーションに関連する機能のタイム ゾーンは更新されません。 自動アテンダント、ハント グループ、コール キューなどの機能のタイム ゾーンを編集するには、タイムゾーンを更新する特定の機能の [全般設定] エリアに移動し、そこで編集して保存します。

これらの設定は社内ダイヤルに適用されるものであり、最初のセットアップ ウィザードでも設定できます。 ダイヤル プランを変更すると、Control Hub の更新でこれらの変更を示す例番号が表示されます。

ロケーションに対する発信通話の権限を設定できます。 これらのステップをご覧になり、発信権限を設定してください。

1

Control Hub にサインインし、サービス > 通話 > サービス設定を選択してから、［内部ダイヤル］までスクロールします。

2

必要に応じて、次のオプションのダイヤル設定を行います。

  • ロケーション ルーティング プレフィックスの長さ—複数のロケーションがある場合は、この設定を推奨します。 2 ～ 7 桁の長さを入力できます。 同じ内線番号を持つ複数のロケーションがある場合、ロケーション間でコールを行うときに、ユーザーはプレフィックスをダイヤルする必要があります。 たとえば、複数のストアがある場合、内線 1000 を使用すると、各ストアにルーティング プレフィックスを設定することができます。 1 つのストアのプレフィックスが 888 の場合、そのストアに到達するために 8881000 にダイヤルします。

    ルーティング プレフィックスの長さには、ステアリング番号が含まれます。 たとえば、ルーティング プレフィックスの長さを 4 に設定すると、3 桁のみを使用してサイトを指定できます。

    ルーティング プレフィックスをロケーションに割り当てる場合、そのロケーションに割り当てられた内線のすべての外観には、内線番号の前にルーティング プレフィックスが含まれます。 たとえば、888-1000（ルーティング プレフィックス-内線）です。

  • [ルーティング プレフィックスのステアリング番号（Steering Digit in Routing Prefix）]:すべてのルーティング プレフィックスの最初の桁として設定される番号を選択します。
  • [内線番号の長さ(Internal Extension Length)]:2 ～ 10 桁を入力でき、デフォルトは 2 です。

    内線の長さを長くすると、既存の内部内線への短縮ダイヤルが自動的に更新されることはありません。

  • ロケーション間の内線ダイヤルを許可—組織の要件に基づいてロケーション間の内線ダイヤルをカスタマイズできます。

    • 組織にすべてのロケーションで重複する内線がない場合は、トグルを有効にします。

      デフォルトでは、トグルが有効になっています。

    • 組織が別の場所に同じ内線を持っている場合は、トグルを無効にします。 トグルが無効になり、発信者が内線番号をダイヤルすると、通話は、発信者と同じロケーションで内線番号が一致するユーザーにルーティングされます。 発信者は、エンタープライズ重要番号（ロケーションルーティングプレフィックス + 内線）をダイヤルして、他のロケーションの内線番号に到達する必要があります。

3

特定の場所の内部ダイヤルを指定します。 に移動 ［管理］>［ロケーション］を選択し、リストからロケーションを選択して、［通話］をクリックします。 [ダイヤル] までスクロールし、必要に応じて内部ダイヤルを変更します。

  • 内部ダイヤル - 別の場所にいるユーザーがこの場所にいる人に連絡するためにダイヤルする必要があるルーティング プレフィックスを指定します。 各ロケーションのルーティング プレフィックスは固有である必要があります。 プレフィックスの長さは組織レベルで設定された長さに一致することを推奨しますが、長さは 2 ～ 7 桁でなければなりません。
4

特定のロケーションの外部ダイヤルを指定します。 に移動 ［管理］>［ロケーション］を選択し、リストからロケーションを選択して、［通話］をクリックします。 [ダイヤル] までスクロールし、必要に応じて外部ダイヤルを変更します。

  • 外部ダイヤル—外線にダイヤルするためにダイヤルする必要がある外線番号の番号を選択することができます。 デフォルトは [なし] であり、このダイヤル習慣が必要ない場合には、値を [なし] にしておくことができます。 この機能を使用しない場合、組織のステアリング番号とは別の番号を使用することをお勧めします。

    ユーザーは、外線発信を行う際に外線発信番号を含め、レガシー システムでダイヤルしていた方法を真似たものにできます。 ただし、すべてのユーザは、発信ダイヤル番号なしで外部コールを発信できます。

  • 必要に応じて、このロケーションの発信ダイヤル番号のダイヤルを強制することができます。これにより、ユーザーは外部コールを発信するために管理者が設定した発信ダイヤル番号を使用する必要があります。

    この機能が有効になっている場合でも、緊急コールは発信ダイヤル番号の有無にかかわらずダイヤルできます。

    有効にすると、発信ダイヤル番号が含まれていない場合、コール転送に使用されるような外部接続先番号は機能しなくなります。

    内線が国番号と同じ場合、内線が国番号よりも優先されます。 したがって、発信ダイヤル番号を有効にすることをお勧めします。
    着信および発信 PSTN コールに E.164 番号形式を使用することを強くお勧めします。

ユーザーへの影響:

  • ダイヤル設定の変更を有効にするには、電話機を再起動する必要があります。

  • ユーザーの内線番号はロケーションのステアリング番号または発信ダイヤル番号と同じ番号で始まるべきではありません。

Control Hub でプレミス ベースの PSTN (ローカル ゲートウェイ) を設定する

付加価値再販業者の場合、これらの手順を使用して Control Hub でローカル ゲートウェイの設定を開始できます。 このゲートウェイがクラウドに登録されると、Webex Calling の 1 つ以上のロケーションで使用して、エンタープライズ PSTN サービス プロバイダーへのルーティングを提供できます。

ローカル ゲートウェイがある場所は、ローカル ゲートウェイが他の場所で使用されているときには削除できません。

トランクを作成する
次の手順に従って、Control Hub でトランクを作成します。

始める前に

  • ロケーションが追加されたら、ロケーションに対してプレミスベース PSTN を設定する前に、トランクを作成する必要があります。

  • それぞれについて、ロケーションと固有の設定および番号を作成します。 ロケーションはプレミスベース PSTN を追加する前に存在する必要があります。

  • Webex Calling でのプレミスベース PSTN (ローカル ゲートウェイ) 要件について理解しておいてください。

  • プレミスベース PSTN を持つロケーションに対して、複数のトランクを選択できませんが、複数のロケーションに対して同じトランクを選択することはできます。

1

https://admin.webex.comでControl Hubにログインし、に移動します。 [サービス] > [通話] > [通話ルーティング] を選択し、[トランクの追加] を選択します。

2

ロケーションを選択します。

3

トランクの名前を指定し、[保存] をクリックします。

名前は 24 文字以内にしてください。

次に行うこと

トランクで設定する必要がある、関連するパラメーターが表示されます。 また、PSTN 接続をセキュアにするための SIP ダイジェスト資格情報のセットも生成します。

画面 [ドメインの登録]、[トランク グループ 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

[サブスクリプション] タブを選択し、[今すぐ購入] をクリックします。

有料サブスクリプションへの変換に興味を持っていることを知らせるメールがパートナーに送信されます。

通話オプションの設定
発信動作を設定する

ユーザーがコールを発信するときに、どの通話アプリケーションが開くかを制御できます。 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 のローカル ゲートウェイ機能として使用するように変更する場合は、設定に注意してください。 変更を行うため、既存のコール フローと機能を中断しないようにしてください。

この手順には、個々のコマンド オプションについての詳細を学ぶことができるコマンド リファレンス ドキュメントへのリンクが含まれています。 特に指定のない限り、すべてのコマンド リファレンス リンクは Webex 管理対象ゲートウェイ コマンド リファレンス に移動します (この場合、コマンド リンクは Cisco IOS 音声コマンド リファレンス に移動します)。 これらのガイドはすべて、Cisco Unified Border Element コマンド リファレンスからアクセスできます。

サポートされているサードパーティ 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 の 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 メッセージの処理を提供し、必要なターゲットにルーティングします。

Call routing from/to PSTN to/from Webex Calling configuration solution

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 インターフェイスに割り当てます。


interface GigabitEthernet0/0/0
  description Interface facing PSTN and/or CUCM
  ip address 10.80.13.12 255.255.255.0
!
interface GigabitEthernet0/0/1
  description Interface facing Webex Calling (Private address)
  ip address 192.51.100.1 255.255.255.240
2

対称暗号化を使用して、ルータ上の登録と STUN クレデンシャルを保護します。 プライマリ暗号化キーと暗号化タイプを次のように設定します。


key config-key password-encrypt YourPassword
password encryption aes
3

プレースホルダー PKI トラストポイントを作成します。

後で TLS を設定するには、このトラストポイントが必要です。 登録ベースのトランクの場合、このトラストポイントには証明書は必要ありません。証明書ベースのトランクに必要です。

crypto pki trustpoint EmptyTP 
 revocation-check none
4

TLS1.2 排他を有効にし、次の設定コマンドを使用してデフォルトのトラストポイントを指定します。 登録のための信頼性の高い安全な接続を確保するために、トランスポートパラメータも更新する必要があります。

cn-san-validate server コマンドは、テナント 200 で設定されたホスト名がアウトバウンド プロキシから受信した証明書の CN または SAN フィールドに含まれている場合に、ローカル ゲートウェイが接続を許可することを保証します。

  1. を設定 tcp再試行カウント～1000(5msecの倍数=5秒)

  2. タイマー接続の確立コマンドを使用すると、次の利用可能なオプションを検討する前に、LGWがプロキシとの接続を設定するのを待つ時間を調整できます。 このタイマーのデフォルトは 20 秒で、最低 5 秒です。 低値で開始し、ネットワーク条件に対応するために必要な場合は増加します。


sip-ua
 timers connection establish tls 5
 transport tcp tls v1.2
 crypto signaling default trustpoint EmptyTP cn-san-validate server
 tcp-retry 1000
5

Webex Calling で使用される DigiCert CA 証明書を含む Cisco ルート CA バンドルをインストールします。 を使用する crypto pki trustpool インポート クリーン URLコマンドは、指定されたURLからルートCAバンドルをダウンロードし、現在のCAトラストプールをクリアしてから、証明書の新しいバンドルをインストールします。

HTTPS を使用してインターネットにアクセスするためにプロキシを使用する必要がある場合は、CA バンドルをインポートする前に、次の設定を追加します。

ip httpクライアントプロキシサーバーyourproxy.comプロキシポート80 

ip http client source-interface GigabitEthernet0/0/1 
crypto pki trustpool import clean url https://www.cisco.com/security/pki/trs/ios_core.p7b
Webex Calling 登録ベースのトランクの設定
1

Control Hub の既存のロケーションに登録ベースの PSTN トランクを作成します。 トランクが作成されると、提供されたトランク情報をメモします。 次の図で強調表示されているこれらの詳細は、このガイドの設定手順で使用されます。 詳細については、「Webex Calling のトランク、ルート グループ、ダイヤル プランの設定」を参照してください。

2

次のコマンドを入力して、CUBE を Webex Calling ローカル ゲートウェイとして設定します。

 
voice service voip
 ip address trusted list
  ipv4 x.x.x.x y.y.y.y
 mode border-element
 media statistics
 media bulk-stats 
 allow-connections sip to sip
 no supplementary-service sip refer  
 stun
  stun flowdata agent-id 1 boot-count 4
  stun flowdata shared-secret 0 Password123$
 sip
  asymmetric payload full
  early-offer forced

設定フィールドの説明を次に示します。


ip address trusted list
 ipv4 x.x.x.x y.y.y.y

  • トール詐欺から保護するために、信頼されたアドレス リストは、ローカル ゲートウェイが正当な VoIP コールを期待するホストとネットワークのリストを定義します。

  • デフォルトでは、ローカル ゲートウェイは、信頼されたリストに含まれていない IP アドレスからのすべての着信 VoIP メッセージをブロックします。 「セッション ターゲット IP」またはサーバー グループ IP アドレスを持つ静的に設定されたダイヤル ピアはデフォルトで信頼されるため、信頼されたリストに追加する必要はありません。

  • ローカル ゲートウェイを設定するときは、地域の Webex Calling データ センターの IP サブネットをリストに追加します。 詳細については、「Webex Calling のポート参照情報」を参照してください。 また、Unified Communications Manager サーバ（使用されている場合）および PSTN トランク ゲートウェイのアドレス範囲を追加します。

    LGW が制限されたコーン NAT を備えたファイアウォールの背後にある場合、Webex Calling 向けのインターフェイスの IP アドレスの信頼済みリストを無効にすることをお勧めします。 ファイアウォールは、未承諾の着信 VoIP からすでに保護しています。 アクションを無効にすると、Webex Calling ピアのアドレスが固定されたままであることを保証できず、いずれの場合もピアのファイアウォールを設定する必要があるため、長期的な構成のオーバーヘッドが軽減されます。

モード ボーダー要素

プラットフォームで Cisco Unified Border Element（CUBE）機能を有効にします。

メディア統計

ローカル ゲートウェイでメディア モニタリングを有効にします。

メディア一括統計

制御プレーンが一括コール統計のためにデータ プレーンをポーリングできるようにします。

これらのコマンドの詳細については、「メディア」を参照してください。

allow-connections sip to sip

CUBE 基本 SIP バックツーバック ユーザ エージェント機能を有効にします。 詳細については、「接続を許可」を参照してください。

デフォルトでは、T.38 ファックス転送が有効になっています。 詳細については、ファックスプロトコルt38 (音声サービス)を参照してください。

スタイン

STUN (NAT を介した UDP のセッショントラバーサル) をグローバルに有効にします。

  • Webex Calling ユーザーにコールを転送する場合（たとえば、着信側と発信側の両方が Webex Calling サブスクライバであり、Webex Calling SBC でメディアをアンカーする場合）、ピンホールが開いていないため、メディアはローカル ゲートウェイにフローできません。

  • ローカル ゲートウェイの STUN バインディング機能により、ネゴシエートされたメディア パス上でローカルに生成された STUN 要求を送信できます。 これは、ファイアウォールのピンホールを開くのに役立ちます。

詳細については、「stun flowdata agent-id」および「stun flowdata shared-secret」を参照してください。

非対称ペイロード フル

DTMF と動的コーデック ペイロードの両方に対して SIP 非対称ペイロード サポートを設定します。 このコマンドの詳細については、非対称ペイロードを参照してください。

early-offer forced

ローカル ゲートウェイは、隣接するピアからの確認を待つ代わりに、最初の INVITE メッセージで SDP 情報を送信するように強制します。 このコマンドの詳細については、早期提供を参照してください。

3

を設定する 音声クラス コーデック 100 トランクのフィルタ。 この例では、すべてのトランクに同じコーデックフィルタが使用されます。 正確な制御のために各トランクにフィルタを設定できます。


voice class codec 100
 codec preference 1 opus
 codec preference 2 g711ulaw
 codec preference 3 g711alaw

設定フィールドの説明を次に示します。

音声クラス コーデック 100

SIP トランクを介したコールの優先コーデックのみを許可するために使用されます。 詳細については、「音声クラスコーデック」を参照してください。

Opus コーデックは、SIP ベースの PSTN トランクでのみサポートされています。 PSTN トランクが音声 T1/E1 またはアナログ FXO 接続を使用している場合は、コーデックの設定 1 オプスから音声クラスコーデック 100の設定。

4

を設定する 音声クラスの使い方 100 は、Webex Calling トランクで ICE を有効にします。


voice class stun-usage 100 
 stun usage firewall-traversal flowdata
 stun usage ice lite

設定フィールドの説明を次に示します。

スタンの使用法 アイス ライト

すべての Webex Calling のダイヤルピアに対して ICE-Lite を有効にして、可能な限り、メディア最適化を可能にするために使用。 詳細については、「voice class stun usage」および「stun usage ice lite」を参照してください。

メディア パスの最適化を使用したコール フローには、ICE-lite のスタン使用が必要です。 SIP から TDM ゲートウェイへのメディア最適化を提供するには、IP-IP レッグで ICE-Lite が有効になっているループバック ダイヤル ピアを設定します。 技術的な詳細は、アカウントまたはTACチームにお問い合わせください。

5

Webex トラフィックのメディア暗号化ポリシーを設定します。


voice class srtp-crypto 100
 crypto 1 AES_CM_128_HMAC_SHA1_80

設定フィールドの説明を次に示します。

音声クラス srtp-crypto 100

SDP の SRTP 暗号スイート CUBE オファーおよび応答メッセージの唯一の SRTP オファーとして SHA1_80 を指定します。 Webex Calling は SHA180 のみをサポートします。_ 詳細については、音声クラス srtp-crypto を参照してください。

6

宛先トランク パラメータに基づいて、ローカル ゲートウェイ トランクへのコールを一意に識別するパターンを設定します。


voice class uri 100 sip
 pattern dtg=Dallas1463285401_LGU

設定フィールドの説明を次に示します。

音声クラス uri 100 sip

着信トランク ダイヤル ピアへの着信 SIP 招待と一致するパターンを定義します。 このパターンを入力する場合、トランクが作成されたときに、dtg= の後に Control Hub で提供されるトランク OTG/DTG 値を使用します。 詳細については、音声クラス uri を参照してください。

7

を設定する sip プロファイル 100は、Webex Callingに送信される前にSIPメッセージを変更するために使用されます。


voice class sip-profiles 100
 rule 10 request ANY sip-header SIP-Req-URI modify "sips:" "sip:"
 rule 20 request ANY sip-header To modify "<sips:" "<sip:"
 rule 30 request ANY sip-header From modify "<sips:" "<sip:"
 rule 40 request ANY sip-header Contact modify "<sips:(.*)>" "<sip:\1;transport=tls>" 
 rule 50 response ANY sip-header To modify "<sips:" "<sip:"
 rule 60 response ANY sip-header From modify "<sips:" "<sip:"
 rule 70 response ANY sip-header Contact modify "<sips:" "<sip:"
 rule 80 request ANY sip-header From modify ">" ";otg=dallas1463285401_lgu>"
 rule 90 request ANY sip-header P-Asserted-Identity modify "sips:" "sip:"

設定フィールドの説明を次に示します。

  • ルール10～70、90

    コール シグナリングに使用される SIP ヘッダーが、Webex プロキシによって要求される sips スキームではなく sip を使用することを確認します。 sips を使用するように CUBE を設定すると、セキュアな登録が使用されます。

  • ルール80

    From ヘッダーを変更して、トランク グループの OTG/DTG 識別子を Control Hub から含め、企業内のローカル ゲートウェイ サイトを一意に識別します。

8

Webex Calling トランクの設定:

  1. を作成 音声クラス テナント 100は、Webex Callingトランクに必要な設定を定義し、グループ化します。 特に、以前の Control Hub で提供されるトランク登録の詳細は、以下の手順で使用されます。 このテナントに関連付けられているダイヤルピアは、後でこれらの設定を継承します。

    次の例では、このガイドの目的のために、ステップ 1 に示されている値を使用します (太字で表示)。 これらを構成のトランクの値に置き換えます。

    
voice class tenant 100
  registrar dns:98027369.us10.bcld.webex.com scheme sips expires 240 refresh-ratio 50 tcp tls
  credentials number Dallas1171197921_LGU username Dallas1463285401_LGU password 0 9Wt[M6ifY+ realm BroadWorks
  authentication username Dallas1463285401_LGU password 0 9Wt[M6ifY+ realm BroadWorks
  authentication username Dallas1463285401_LGU password 0 9Wt[M6ifY+ realm 98027369.us10.bcld.webex.com
  no remote-party-id
  sip-server dns:98027369.us10.bcld.webex.com
  connection-reuse
  srtp-crypto 100
  session transport tcp tls 
  url sips 
  error-passthru
  asserted-id pai 
  bind control source-interface GigabitEthernet0/0/1
  bind media source-interface GigabitEthernet0/0/1
  no pass-thru content custom-sdp 
  sip-profiles 100 
  outbound-proxy dns:dfw04.sipconnect-us.bcld.webex.com  
  privacy-policy passthru

    設定フィールドの説明を次に示します。

    音声クラス テナント 100

    Webex Calling トランクにのみ使用される一連の設定パラメータを定義します。 詳細については、「音声クラス テナント」を参照してください。

    レジストラdns:98027369.us10.bcld.webex.com スキームsips expires 240 更新比 50 tcp tls

    2 分 (240 秒の50%) ごとに更新するように登録が設定されたローカル ゲートウェイのレジストラ サーバー。 詳細については、レジストラを参照してください。

    ここで Control Hub から [ドメインの登録] 値を使用していることを確認します。

    クレデンシャル番号 Dallas1171197921_LGU ユーザー名 Dallas1463285401_LGUパスワード 0 9Wt[M6ifY+realm BroadWorks

    トランク登録チャレンジのクレデンシャル。 詳細については、資格情報（SIP UA）を参照してください。

    ここで、Control Hub からそれぞれ回線/ポートホスト、認証ユーザ名、認証パスワードの値を使用していることを確認します。

    認証ユーザ名 Dallas1171197921_LGU パスワード 0 9Wt[M6ifY+ realm BroadWorks
    認証ユーザ名 Dallas1171197921_LGUパスワード 0 9Wt[M6ifY+ realm 98027369.us10.bcld.webex.com

    コールの認証の課題。 詳細については、認証（ダイヤルピア）を参照してください。

    ここで、Control Hub からそれぞれ認証ユーザ名、認証パスワード、およびレジストラドメインの値を使用していることを確認してください。

    no remote-party-id

    Webex Calling が PAI をサポートしているため、SIP Remote-Party-ID (RPID) ヘッダーを無効にします。このヘッダーは CIO アサート済みID PAIだ 詳細については、「remote-party-id」を参照してください。

    sip-server dns:us25.sipconnect.bcld.webex.com

    トランクのターゲット SIP サーバを設定します。 トランクを作成するときは、Control Hub で提供されるエッジ プロキシ SRV アドレスを使用します。

    connection-reuse

    登録とコール処理に同じ永続接続を使用します。 詳細については、「connection-reuse」を参照してください。

    srtp クリプト 100

    SRTP コール レッグ（接続）の優先暗号スイートを設定します（ステップ 5 で指定）。 詳細については、音声クラス srtp-crypto を参照してください。

    session transport tcp tls

    TLS へのトランスポートを設定します。 詳細については、「session-transport」を参照してください。

    url sips

    SRV クエリは、アクセス SBC でサポートされている SIP である必要があります。他のすべてのメッセージは SIP-profile 200 によって SIP に変更されます。

    error-passthru

    SIP エラー応答パススルー機能を指定します。 詳細については、error-passthruを参照してください。

    asserted-id pai

    ローカル ゲートウェイで PAI 処理をオンにします。 詳細については、asserted-idを参照してください。

    バインド制御ソースインターフェイス GigabitEthernet0/0/1

    WebexCalling に送信されるメッセージのソース インターフェイスと関連する IP アドレスを設定します。 詳細は、bindを参照してください。

    バインド メディア ソース インターフェイス GigabitEthernet0/0/1

    WebexCalling に送信されるメディアのソース インターフェイスおよび関連する IP アドレスを設定します。 詳細は、bindを参照してください。

    no pass-thru content custom-sdp

    テナントの下のデフォルト コマンド。 このコマンドの詳細については、パススルー コンテンツを参照してください。

    sipプロファイル 100

    で定義されているように、SIPをSIPに変更し、INVITEおよびREGISTERメッセージの回線/ポートを変更する sipプロファイル 100だ 詳細については、「音声クラス sip プロファイル」を参照してください。

    アウトバウンドプロキシ dns:dfw04.sipconnect-us.bcld.webex.com

    Webex Calling アクセス SBC。 トランクを作成したときに、Control Hub で提供されるアウトバウンド プロキシ アドレスを挿入します。 詳細については、「outbound-proxy」を参照してください。

    privacy-policy passthru

    トランクのプライバシー ヘッダー ポリシー オプションを設定して、受信したメッセージから次のコール レッグにプライバシーの値を渡します。 詳細については、プライバシーポリシーを参照してください。

  2. Webex Calling トランク ダイヤル ピアを設定します。

    
dial-peer voice 100 voip
 description Inbound/Outbound Webex Calling
 max-conn 250
 destination-pattern BAD.BAD
 session protocol sipv2
 session target sip-server
 incoming uri request 100
 voice-class codec 100
 dtmf-relay rtp-nte
 voice-class stun-usage 100
 no voice-class sip localhost
 voice-class sip tenant 100
 srtp
 no vad

    設定フィールドの説明を次に示します。

    
dial-peer voice 100 voip
  description Inbound/Outbound Webex Calling

    タグ 100 で VoIP ダイヤルピアを定義し、管理とトラブルシューティングを容易にするための意味のある説明を提供します。

    マックスコン 250

    LGW と Webex Calling の間の同時着信コールと発信コールの数を制限します。 登録トランクの場合、設定されている最大値は 250 である必要があります。 Usea は、展開に適している場合は値を下げます。 ローカル ゲートウェイの同時通話制限の詳細については、「ローカル ゲートウェイを使い始める」のドキュメントを参照してください。

    destination-pattern BAD.BAD

    着信ダイヤル ピア グループを使用して発信コールをルーティングする場合は、ダミー接続先パターンが必要です。 この場合、有効な宛先パターンを使用できます。

    session protocol sipv2

    ダイヤルピア 100 が SIP コール レッグを処理するように指定します。 詳細については、セッションプロトコル（ダイヤルピア）を参照してください。

    session target sip-server

    テナント 100 で定義された SIP サーバが継承され、このダイヤル ピアからのコールの宛先に使用されることを示します。

    着信 uri リクエスト 100

    VoIP ダイヤル ピアと着信コールのユニフォーム リソース 識別子（URI）を一致させるために使用される音声クラスを指定します。 詳細については、着信 uri を参照してください。

    音声クラス コーデック 100

    共通のコーデック フィルタ リスト 100 を使用するようにダイヤル ピアを設定します。 詳細については、音声クラスコーデックを参照してください。

    音声クラスのstun使用 100

    ローカル ゲートウェイでローカルに生成された STUN 要求を、ネゴシエートされたメディア パス経由で送信できるようにします。 STUN は、メディア トラフィックのファイアウォールのピンホールを開くのに役立ちます。

    no voice-class sip localhost

    発信メッセージの [送信元（From）]、[コール ID（CALL-ID）]、および [リモートパーティ（REMOTE-PARTY-ID）] ヘッダーの物理 IP アドレスの代わりに DNS ローカルホスト名の置換を無効にします。

    音声クラス SIP テナント 100

    ダイヤル ピアは、グローバルおよびテナント 100 で設定されたすべてのパラメータを継承します。 パラメータはダイヤル ピア レベルで上書きされる場合があります。

    srtp

    コール レッグの SRTP を有効にします。

    no vad

    音声アクティブティの検出を無効にします。

テナント を定義した後 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を受信すると、登録が成功します。

SIP PSTN トランクを使用したローカル ゲートウェイの設定

上記の Webex Calling に対してトランクを構築した後、次の設定を使用して、SIP ベースの PSTN プロバイダーに対して暗号化されていないトランクを作成します。

サービス プロバイダーがセキュアな PSTN トランクを提供している場合、上記の Webex Calling トランクと同様の構成に従うことができます。 セキュアからセキュアなコール ルーティングは CUBE でサポートされています。

TDM/ISDN PSTN トランクを使用している場合は、次のセクション「TDM PSTN トランクを使用したローカル ゲートウェイの設定」に進みます。

Cisco TDM-SIP ゲートウェイで PSTN コール レッグの TDM インターフェイスを設定するには、「ISDN PRI の設定」を参照してください。

1

PSTN トランクからの着信コールを識別するには、次の音声クラス uri を設定します。


voice class uri 200 sip
  host ipv4:192.168.80.13

設定フィールドの説明を次に示します。

音声クラス uri 200 sip

着信トランク ダイヤル ピアへの着信 SIP 招待と一致するパターンを定義します。 このパターンを入力するときは、IP PSTN ゲートウェイの IP アドレスを使用します。 詳細については、音声クラス uri を参照してください。

2

次の IP PSTN ダイヤル ピアを設定します。


dial-peer voice 200 voip
 description Inbound/Outbound IP PSTN trunk
 destination-pattern BAD.BAD
 session protocol sipv2
 session target ipv4:192.168.80.13
 incoming uri via 200
 voice-class sip bind control source-interface GigabitEthernet0/0/0 
 voice-class sip bind media source-interface  GigabitEthernet0/0/0 
 voice-class codec 100
 dtmf-relay rtp-nte 
 no vad

設定フィールドの説明を次に示します。


dial-peer voice 200 voip
 description Inbound/Outbound IP PSTN trunk

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 経由で 着信 uri

VIA ヘッダーと IP PSTN の IP アドレスの一致基準を定義します。 ローカル ゲートウェイのすべての着信 IP PSTN コール レッグとダイヤル ピア 200 を一致させます。 詳細については、着信 URLを参照してください。

バインド制御ソースインタフェース GigabitEthernet0/0/0

PSTN に送信されるメッセージのソース インターフェイスと関連する IP アドレスを設定します。 詳細は、bindを参照してください。

バインド メディア ソース インターフェイス GigabitEthernet0/0/0

PSTN に送信されるメディアのソース インターフェイスおよび関連する 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 プラットフォームを使用してローカル ゲートウェイを設定する場合は、次のセクションに進みます。

  1. ダイヤルピア グループを作成して、Webex Calling または PSTN にコールをルーティングします。 Webex Calling に向けて発信ダイヤルピア 100 で DPG 100 を定義します。 DPG 100 は、PSTN からの着信ダイヤルピアに適用されます。 同様に、PSTN に向かって発信ダイヤルピア 200 で DPG 200 を定義します。 DPG 200 は、Webex からの着信ダイヤルピアに適用されます。

    
voice class dpg 100 
 description Route calls to Webex Calling 
 dial-peer 100 
voice class dpg 200 
 description Route calls to PSTN 
 dial-peer 200

    設定フィールドの説明を次に示します。

    ダイヤルピア 100

    発信ダイヤルピアとダイヤルピア グループを関連付けます。 詳細は、音声クラス dpgを参照してください。

  2. ダイヤルピア グループを適用して、Webex から PSTN に、および PSTN から Webex にコールをルーティングします。

    
dial-peer voice 100
 destination dpg 200
dial-peer voice 200
 destination dpg 100

    設定フィールドの説明を次に示します。

    destination dpg 200

    どのダイヤル ピア グループを指定します。したがって、この着信ダイヤル ピアに提示されたコールの発信処理にダイヤル ピアを使用する必要があります。

    これでローカル ゲートウェイの設定は終了します。 CUBE 機能が初めて設定される場合は、設定を保存し、プラットフォームをリロードします。

TDM PSTN トランクを使用したローカル ゲートウェイの設定

Webex Calling に向けてトランクを構築した後は、次の設定を使用して、Webex コール レッグのメディア最適化を可能にするために、ループ バック コール ルーティングを備えた PSTN サービスの TDM トランクを作成します。

IP メディア最適化を必要としない場合は、SIP PSTN トランクの設定手順に従います。 PSTN VoIP ダイヤル ピアの代わりに、ボイス ポートと POTS ダイヤル ピア（手順 2 および 3 を参照）を使用します。
1

ループ バック ダイヤル ピア構成では、ダイヤル ピア グループとコール ルーティング タグを使用して、コール ルーティング ループを作成せずに、Webex と PSTN の間でコールが正しく渡されるようにします。 コール ルーティング タグの追加と削除に使用する次のトランスレーション ルールを設定します。


voice translation-rule 100 
 rule 1 /^\+/ /A2A/ 

voice translation-profile 100 
 translate called 100 

voice translation-rule 200 
 rule 1 /^/ /A1A/ 

voice translation-profile 200 
 translate called 200 

voice translation-rule 11 
 rule 1 /^A1A/ // 

voice translation-profile 11 
 translate called 11 

voice translation-rule 12 
 rule 1 /^A2A44/ /0/
 rule 2/^A2A/ /00/

voice translation-profile 12 
 translate called 12

設定フィールドの説明を次に示します。

音声翻訳ルール

ルールで定義された正規表現を使用して、コール ルーティング タグを追加または削除します。 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 インターフェイスの基本設定には、次のものが含まれます。


card type e1 0 2 
isdn switch-type primary-net5 
controller E1 0/2/0 
 pri-group timeslots 1-31
3

次の TDM PSTN ダイヤル ピアを設定します。


dial-peer voice 200 pots 
 description Inbound/Outbound PRI PSTN trunk 
 destination-pattern BAD.BAD 
 translation-profile incoming 200 
 direct-inward-dial 
 port 0/2/0:15

設定フィールドの説明を次に示します。


dial-peer voice 200 pots
 description Inbound/Outbound PRI PSTN trunk

タグ 200 で VoIP ダイヤル ピアを定義し、管理とトラブルシューティングを容易にするための意味のある説明を提供します。 詳細については、「ダイヤルピアの音声」を参照してください。

destination-pattern BAD.BAD

着信ダイヤル ピア グループを使用して発信コールをルーティングする場合は、ダミー接続先パターンが必要です。 詳細については、destination-pattern (interface)を参照してください。

翻訳プロファイル着信 200

着信着信番号にコール ルーティング タグを追加するトランスレーション プロファイルを割り当てます。

ダイレクト インワード ダイヤル

セカンダリ ダイヤル トーンを提供せずにコールをルーティングします。 詳細は、ダイレクト インワード ダイヤルを参照してください。

ポート 0/2:0:15

このダイヤル ピアに関連付けられている物理的な音声ポート。

4

TDM-IP コール フローでローカル ゲートウェイの IP パスのメディア最適化を有効にするには、Webex Calling と PSTN トランクの間に一連の内部ループ バック ダイヤル ピアを導入して、コール ルーティングを変更できます。 次のループバックダイヤルピアを設定します。 この場合、すべての着信コールは最初にダイヤルピア 10 にルーティングされ、そこから適用されたルーティング タグに基づいてダイヤルピア 11 または 12 にルーティングされます。 ルーティング タグを削除すると、コールはダイヤル ピア グループを使用して発信トランクにルーティングされます。


dial-peer voice 10 voip
 description Outbound loop-around leg
 destination-pattern BAD.BAD
 session protocol sipv2
 session target ipv4:192.168.80.14
 voice-class sip bind control source-interface GigabitEthernet0/0/0
 voice-class sip bind media source-interface GigabitEthernet0/0/0
 dtmf-relay rtp-nte
 codec g711alaw
 no vad 

dial-peer voice 11 voip
 description Inbound loop-around leg towards Webex
 translation-profile incoming 11
 session protocol sipv2
 incoming called-number A1AT
 voice-class sip bind control source-interface GigabitEthernet0/0/0
 voice-class sip bind media source-interface GigabitEthernet0/0/0
 dtmf-relay rtp-nte
 codec g711alaw
 no vad 

dial-peer voice 12 voip
 description Inbound loop-around leg towards PSTN
 translation-profile incoming 12
 session protocol sipv2
 incoming called-number A2AT
 voice-class sip bind control source-interface GigabitEthernet0/0/0
 voice-class sip bind media source-interface GigabitEthernet0/0/0
 dtmf-relay rtp-nte
 codec g711alaw 
 no vad

設定フィールドの説明を次に示します。


dial-peer voice 10 pots
 description Outbound loop-around leg

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

次のコール ルーティング設定を追加します。

  1. ダイヤルピア グループを作成して、ループバックを介して PSTN と Webex トランク間のコールをルーティングします。

    
voice class dpg 100
 description Route calls to Webex Calling
 dial-peer 100
voice class dpg 200
 description Route calls to PSTN
 dial-peer 200
voice class dpg 10
 description Route calls to Loopback
 dial-peer 10

    設定フィールドの説明を次に示します。

    ダイヤルピア 100

    発信ダイヤルピアとダイヤルピア グループを関連付けます。 詳細は、音声クラス dpgを参照してください。

  2. ダイヤル ピア グループを適用してコールをルーティングします。

    
dial-peer voice 100
 destination dpg 10
dial-peer voice 200
 destination dpg 10
dial-peer voice 11
 destination dpg 100
dial-peer voice 12
 destination dpg 200

    設定フィールドの説明を次に示します。

    宛先 DPG 200

    どのダイヤル ピア グループを指定します。したがって、この着信ダイヤル ピアに提示されたコールの発信処理にダイヤル ピアを使用する必要があります。

これでローカル ゲートウェイの設定は終了します。 CUBE 機能が初めて設定される場合は、設定を保存し、プラットフォームをリロードします。
既存の Unified CM 環境でのローカル ゲートウェイの設定

前のセクションの 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 を設定:

  1. SIP VIA ポートを使用して Unified CM を Webex コールに分類します。

    
voice class uri 300 sip
 pattern :5065

  2. ポート経由の SIP を使用して、Unified CM を PSTN コールに分類します。

    
voice class uri 400 sip
 pattern 192\.168\.80\.6[0-5]:5060

    発信元のソース アドレスとポート番号を説明する 1 つ以上のパターンを使用して、UCM からの着信メッセージを PSTN トランクに分類します。 必要に応じて、正規表現を使用して、一致するパターンを定義できます。

    上記の例では、192.168.80.60 から 65 までの範囲およびポート番号 5060 の任意の IP アドレスに一致させるために正規表現が使用されます。

2

次の DNS レコードを設定して、Unified CM ホストへの SRV ルーティングを指定します。

IOS XE は、これらのレコードをローカルでターゲット UCM ホストとポートを決定するために使用します。 この設定では、DNS システムでレコードを設定する必要はありません。 DNS を使用する場合は、これらのローカル設定は必要ありません。


ip host ucmpub.mydomain.com 192.168.80.60
ip host ucmsub1.mydomain.com 192.168.80.61
ip host ucmsub2.mydomain.com 192.168.80.62
ip host ucmsub3.mydomain.com 192.168.80.63
ip host ucmsub4.mydomain.com 192.168.80.64
ip host ucmsub5.mydomain.com 192.168.80.65
ip host _sip._udp.wxtocucm.io srv 0 1 5065 ucmpub.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub1.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub2.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub3.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub4.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub5.mydomain.com
ip host _sip._udp.pstntocucm.io srv 0 1 5060 ucmpub.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub1.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub2.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub3.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub4.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub5.mydomain.com

設定フィールドの説明を次に示します。

次のコマンドは、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

次のダイヤルピアを設定します。

  1. Unified CM と Webex Calling 間のコールのダイヤルピア:

    
dial-peer voice 300 voip
 description UCM-Webex Calling trunk
 destination-pattern BAD.BAD
 session protocol sipv2
 session target dns:wxtocucm.io
 incoming uri via 300
 voice-class codec 100
 voice-class sip bind control source-interface GigabitEthernet 0/0/0
 voice-class sip bind media source-interface GigabitEthernet 0/0/0
 dtmf-relay rtp-nte
 no vad

    設定フィールドの説明を次に示します。

    
dial-peer voice 300 voip
 description UCM-Webex Calling trunk

    タグ 300 を使用して VoIP ダイヤルピアを定義し、管理とトラブルシューティングを容易にするための意味のある説明を提供します。

    destination-pattern BAD.BAD

    着信ダイヤル ピア グループを使用して発信コールをルーティングする場合は、ダミー接続先パターンが必要です。 この場合、有効な宛先パターンを使用できます。

    session protocol sipv2

    ダイヤルピア 300 が SIP コール レッグを処理するように指定します。 詳細については、セッションプロトコル（ダイヤルピア）を参照してください。

    セッション ターゲット dns:wxtocucm.io

    DNS SRV 解決を通じて複数の Unified CM ノードのセッション ターゲットを定義します。 この場合、ローカルで定義された SRV レコード wxtocucm.io がコールをダイレクトするために使用されます。

    incoming uri via 300

    音声クラス URI 300 を使用して、ソース ポート 5065 を使用して Unified CM からのすべての着信トラフィックをこのダイヤル ピアにダイレクトします。 詳細については、着信 uri を参照してください。

    音声クラス コーデック 100

    Unified CM との間のコールのコーデック フィルタ リストを示します。 詳細については、「音声クラスコーデック」を参照してください。

    バインド制御ソースインタフェース GigabitEthernet0/0/0

    PSTN に送信されるメッセージのソース インターフェイスと関連する IP アドレスを設定します。 詳細は、bindを参照してください。

    バインド メディア ソース インターフェイス GigabitEthernet0/0/0

    PSTN に送信されるメディアのソース インターフェイスおよび関連する IP アドレスを設定します。 詳細は、bindを参照してください。

    dtmf-relay rtp-nte

    コール レッグで期待される DTMF 機能として RTP-NTE（RFC2833）を定義します。 詳細については、「DTMF Relay (Voice over IP)」を参照してください。

    no vad

    音声アクティブティの検出を無効にします。 詳細については、vad（ダイヤルピア）を参照してください。

  2. Unified CM と PSTN 間のコールのダイヤルピア:

    
dial-peer voice 400 voip
 description UCM-PSTN trunk
 destination-pattern BAD.BAD
 session protocol sipv2
 session target dns:pstntocucm.io
 incoming uri via 400
 voice-class codec 100 
 voice-class sip bind control source-interface GigabitEthernet 0/0/0
 voice-class sip bind media source-interface GigabitEthernet 0/0/0
 dtmf-relay rtp-nte
 no vad

    設定フィールドの説明を次に示します。

    
dial-peer voice 400 voip
 description UCM-PSTN trunk

    400のタグを含むVoIPダイヤルピアを定義し、管理とトラブルシューティングを容易にするための意味のある説明を提供します。

    destination-pattern BAD.BAD

    着信ダイヤル ピア グループを使用して発信コールをルーティングする場合は、ダミー接続先パターンが必要です。 この場合、有効な宛先パターンを使用できます。

    session protocol sipv2

    ダイヤルピア 400 が SIP コール レッグを処理するように指定します。 詳細については、セッションプロトコル（ダイヤルピア）を参照してください。

    セッション ターゲット dns:pstntocucm.io

    DNS SRV 解決を通じて複数の Unified CM ノードのセッション ターゲットを定義します。 この場合、ローカルで定義された SRV レコード pstntocucm.io がコールをダイレクトするために使用されます。

    URI を400 経由で着信

    音声クラス URI 400 を使用して、ソース ポート 5060 を使用して指定された Unified CM ホストからのすべての着信トラフィックをこのダイヤル ピアに転送します。 詳細については、着信 uri を参照してください。

    音声クラス コーデック 100

    Unified CM との間のコールのコーデック フィルタ リストを示します。 詳細については、「音声クラスコーデック」を参照してください。

    バインド制御ソースインタフェース GigabitEthernet0/0/0

    PSTN に送信されるメッセージのソース インターフェイスと関連する IP アドレスを設定します。 詳細は、bindを参照してください。

    バインド メディア ソース インターフェイス GigabitEthernet0/0/0

    PSTN に送信されるメディアのソース インターフェイスおよび関連する IP アドレスを設定します。 詳細は、bindを参照してください。

    dtmf-relay rtp-nte

    コール レッグで期待される DTMF 機能として RTP-NTE（RFC2833）を定義します。 詳細については、「DTMF Relay (Voice over IP)」を参照してください。

    no vad

    音声アクティブティの検出を無効にします。 詳細については、vad（ダイヤルピア）を参照してください。

4

次の設定を使用してコール ルーティングを追加します。

  1. Unified CM と Webex Calling の間で通話をルーティングするダイヤル ピア グループを作成します。 でDPG 100を定義する 発信ダイヤルピア 100 Webex Calling に移行します。 DPG 100 は、Unified CM から関連付けられた着信ダイヤルピアに適用されます。 同様に、Unified CM に向かって発信ダイヤルピア 300 で DPG 300 を定義します。 DPG 300 は、Webex からの着信ダイヤルピアに適用されます。

    
voice class dpg 100
 description Route calls to Webex Calling
 dial-peer 100
voice class dpg 300
 description Route calls to Unified CM Webex Calling trunk
 dial-peer 300

  2. Unified CM と PSTN の間でコールをルーティングするダイヤル ピア グループを作成します。 でDPG 200を定義する 発信ダイヤルピア 200 PSTNへ。 DPG 200 は、Unified CM から関連付けられた着信ダイヤルピアに適用されます。 同様に、Unified CM に向かって発信ダイヤルピア 400 で DPG 400 を定義します。 DPG 400 は、PSTN からの着信ダイヤルピアに適用されます。

    
voice class dpg 200
 description Route calls to PSTN
 dial-peer 200
voice class dpg 400
 description Route calls to Unified CM PSTN trunk
 dial-peer 400

    設定フィールドの説明を次に示します。

    ダイヤルピア 100

    発信ダイヤルピアとダイヤルピア グループを関連付けます。 詳細は、音声クラス dpgを参照してください。

  3. ダイヤルピア グループを適用して、Webex から Unified CM に、および Unified CM から Webex にコールをルーティングします。

    
dial-peer voice 100
 destination dpg 300
dial-peer voice 300
 destination dpg 100

    設定フィールドの説明を次に示します。

    宛先 DPG 300

    どのダイヤル ピア グループを指定します。したがって、この着信ダイヤル ピアに提示されたコールの発信処理にダイヤル ピアを使用する必要があります。

  4. ダイヤルピア グループを適用して、PSTN から Unified CM に、Unified CM から PSTN にコールをルーティングします。

    
dial-peer voice 200
 destination dpg 400
dial-peer voice 400
 destination dpg 200

    これでローカル ゲートウェイの設定は終了します。 CUBE 機能が初めて設定される場合は、設定を保存し、プラットフォームを再読み込みします。

診断署名によるローカル ゲートウェイの監視とトラブルシューティング

診断署名（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 以降を実行しているローカル ゲートウェイ

  1. 診断署名はデフォルトで有効になっています。

  2. デバイスが Cisco IOS XE 17.6.1a 以降を実行している場合、プロアクティブな通知を送信するために使用する、セキュアな電子メールサーバを設定します。

    configure terminal 
call-home  
mail-server <username>:<pwd>@<email server> priority 1 secure tls 
end

  3. 通知する管理者のメール アドレスで環境変数 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 アカウント設定を構成し、デバイスからのメールを正しく処理するための特定の権限を提供する必要があります。

  1. に移動 Googleアカウントの管理 > セキュリティを選択し、[安全性の低いアプリアクセス]設定をオンにします。

  2. Gmailから「GoogleがGoogle以外のアプリを使用してアカウントにサインインできないようにしました」というメールを受け取ったら、「はい、私でした」と回答してください。

プロアクティブなモニタリングのための診断署名のインストール

高いCPU使用率のモニタリング

この DS は、SNMP OID 1.3.6.1.4.1.9.2.1.56 を使用して、CPU 使用率を 5 秒間追跡します。 使用率が 75% 以上になると、すべてのデバッグが無効になり、ローカル ゲートウェイにインストールされているすべての診断シグネチャがアンインストールされます。 下記の手順を実行して署名をインストールします。

  1. を使用する 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

  2. Diagnostic Signatures Lookup Tool の以下のドロップダウンオプションを使用して、DS 64224 をダウンロードします。

    フィールド名

    フィールド値

    プラットフォーム

    Cisco 4300、4400 ISR シリーズ、または Cisco CSR 1000V シリーズ

    製品

    Webex Calling ソリューションの CUBE Enterprise

    問題の範囲

    パフォーマンス

    問題の種類

    メール通知による高い CPU 使用率。

  3. 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)

  4. ローカルゲートウェイに DS XML ファイルをインストールします。

    call-home diagnostic-signature load DS_64224.xml 
Load file DS_64224.xml success

  5. を使用する コールホーム診断署名を表示コマンドを使用して、署名が正常にインストールされていることを確認します。 ステータス列の値が「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 回発生した後にアンインストールされます。 署名をインストールするには、以下の手順を使用します。

  1. Diagnostic Signatures Lookup Tool の以下のドロップダウンオプションを使用して、DS 64117 をダウンロードします。

    フィールド名

    フィールド値

    プラットフォーム

    Cisco 4300、4400 ISR シリーズ、または Cisco CSR 1000V シリーズ

    製品

    Webex Calling ソリューションの CUBE Enterprise

    問題の範囲

    SIP-SIP

    問題の種類

    メール通知による SIP トランクの登録解除。

  2. DS XML ファイルをローカルゲートウェイにコピーします。

    copy ftp://username:password@<server name or ip>/DS_64117.xml bootflash:

  3. ローカルゲートウェイに DS XML ファイルをインストールします。

    call-home diagnostic-signature load DS_64117.xml 
Load file DS_64117.xml success 
LocalGateway#

  4. を使用する コールホーム診断署名を表示コマンドを使用して、署名が正常にインストールされていることを確認します。 ステータス列には「登録済み」の値が必要です。

異常な通話切断のモニタリング

この DS は、10 分おきに SNMP ポーリングを使用して、SIP エラー 403、488、503 の異常な通話切断を検出します。  エラー数の増加が前回の投票から 5 以上である場合、syslog とメール通知が生成されます。 下記の手順を実行して、署名をインストールしてください。

  1. を使用する 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

  2. Diagnostic Signatures Lookup Tool の以下のオプションを使用して、DS 65221 をダウンロードします。

    フィールド名

    フィールド値

    プラットフォーム

    Cisco 4300、4400 ISR シリーズ、または Cisco CSR 1000V シリーズ

    製品

    Webex Calling ソリューションの CUBE Enterprise

    問題の範囲

    パフォーマンス

    問題の種類

    電子メールおよび Syslog 通知による SIP 異常な通話切断検出。

  3. DS XML ファイルをローカルゲートウェイにコピーします。

    copy ftp://username:password@<server name or ip>/DS_65221.xml bootflash:

  4. ローカルゲートウェイに DS XML ファイルをインストールします。

    call-home diagnostic-signature load DS_65221.xml 
Load file DS_65221.xml success

  5. を使用する コールホーム診断署名を表示コマンドを使用して、署名が正常にインストールされていることを確認します。 ステータス列には「登録済み」の値が必要です。

診断署名をインストールして問題をトラブルシューティング

診断署名（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 は次のステップを使用して診断データ収集を自動化します。

  1. 収集した診断データがアップロードされる 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"

  2. SNMP がSNMPを表示 コマンド 有効になっていない場合は、snmpサーバーマネージャ コマンド

    show snmp 
%SNMP agent not enabled 
 
 
config t 
snmp-server manager 
end

  3. 高CPU使用率時のすべてのデバッグおよび診断シグネチャを無効にするプロアクティブな対策として、高CPUモニタリングDS 64224をインストールしてください。 Diagnostic Signatures Lookup Tool の以下のオプションを使用して、DS 64224 をダウンロードします。

    フィールド名

    フィールド値

    プラットフォーム

    Cisco 4300、4400 ISR シリーズ、または Cisco CSR 1000V シリーズ

    製品

    Webex Calling ソリューションの CUBE Enterprise

    問題の範囲

    パフォーマンス

    問題の種類

    メール通知による高い CPU 使用率。

  4. 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

  5. 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:

  6. ローカルゲートウェイに、高 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

  7. を使用して署名が正常にインストールされていることを確認します。 コールホーム診断署名を表示 コマンド ステータス列には「登録済み」の値が必要です。

    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 では現在、新しいカスタム署名の作成リクエストをサポートしていません。

Control Hub 経由で Cisco IOS XE ゲートウェイを管理および検証する

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 メッセージの処理を提供し、必要なターゲットにルーティングします。

Call routing from/to PSTN to/from Webex Calling configuration solution

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 インターフェイスに割り当てます。


interface GigabitEthernet0/0/0
 description Interface facing PSTN and/or CUCM
 ip address 192.168.80.14 255.255.255.0
!
interface GigabitEthernet0/0/1
 description Interface facing Webex Calling (Public address)
 ip address 198.51.100.1 255.255.255.240
2

対称暗号化を使用してルータの STUN クレデンシャルを保護します。 プライマリ暗号化キーと暗号化タイプを次のように設定します。


key config-key password-encrypt YourPassword
password encryption aes
3

希望する認証局 (CA) によって署名された証明書を使用して暗号化トラストポイントを作成します。

  1. 次の exec コマンドを使用して RSA キーペアを作成します。

    crypto key generate rsa general-keys exportable label lgw-key modulus 4096

  2. トランクの fqdn として cube1.lgw.com を使用する場合、次の設定コマンドを使用して、署名済み証明書のトラストポイントを作成します。

    
crypto pki trustpoint LGW_CERT
 enrollment terminal pem
 fqdn cube1.lgw.com
 subject-name cn=cube1.lgw.com
 subject-alt-name cube1.lgw.com
 revocation-check none
 rsakeypair lgw-key

  3. 次の exec または configuration コマンドを使用して証明書署名リクエスト（CSR）を生成し、サポートされている CA プロバイダーから署名済み証明書を要求するために使用します。

    crypto pki enroll LGW_CERT
4

中間（またはルート）CA 証明書を使用して新しい証明書を認証し、証明書をインポートします（ステップ 4）。 次の exec または configuration コマンドを入力します。


crypto pki authenticate LGW_CERT
<paste Intermediate X.509 base 64 based certificate here>
5

次の exec または configuration コマンドを使用して、署名済みホスト証明書をインポートします。


crypto pki import LGW_CERT certificate
<paste CUBE host X.509 base 64 certificate here>
6

TLS1.2 排他を有効にし、次の設定コマンドを使用してデフォルトのトラストポイントを指定します。


 sip-ua
  crypto signaling default trustpoint LGW_CERT
  transport tcp tls v1.2
7

Webex Calling で使用される DigiCert CA 証明書を含む Cisco ルート CA バンドルをインストールします。 を使用する crypto pki trustpool インポート クリーン URLコマンドは、指定されたURLからルートCAバンドルをダウンロードし、現在のCAトラストプールをクリアしてから、証明書の新しいバンドルをインストールします。

HTTPS を使用してインターネットにアクセスするためにプロキシを使用する必要がある場合は、CA バンドルをインポートする前に、次の設定を追加します。

ip httpクライアントプロキシサーバーyourproxy.comプロキシポート80 

ip http client source-interface GigabitEthernet0/0/1 
crypto pki trustpool import clean url https://www.cisco.com/security/pki/trs/ios_core.p7b
Webex Calling 証明書ベースのトランクの設定
1

Control Hub の既存のロケーションの CUBE 証明書ベースの PSTN トランクを作成します。 詳細については、「Webex Calling のトランク、ルート グループ、ダイヤル プランの設定」を参照してください。

トランクが作成されると、提供されたトランク情報をメモします。 次の図で強調表示されているこれらの詳細は、このガイドの設定手順で使用されます。
2

次のコマンドを入力して、CUBE を Webex Calling ローカル ゲートウェイとして設定します。


voice service voip
 ip address trusted list
  ipv4 x.x.x.x y.y.y.y
 mode border-element
 allow-connections sip to sip
 no supplementary-service sip refer
 stun
  stun flowdata agent-id 1 boot-count 4
  stun flowdata shared-secret 0 Password123$
 sip 
  asymmetric payload full
  early-offer forced
  sip-profiles inbound

設定フィールドの説明を次に示します。


ip address trusted list
 ipv4 x.x.x.x y.y.y.y

  • トール詐欺から保護するために、信頼されたアドレス リストは、ローカル ゲートウェイが正当な VoIP コールを期待するホストおよびネットワーク エンティティのリストを定義します。

  • デフォルトでは、ローカル ゲートウェイは、信頼されたリストに含まれていない IP アドレスからのすべての着信 VoIP メッセージをブロックします。 「セッション ターゲット IP」またはサーバー グループ IP アドレスを持つ静的に設定されたダイヤル ピアはデフォルトで信頼されるため、信頼されたリストに追加する必要はありません。

  • ローカル ゲートウェイを設定するときは、地域の Webex Calling データセンターの IP サブネットをリストに追加します。詳細については、「Webex Calling のポート参照情報」を参照してください。 また、Unified Communications Manager サーバ（使用されている場合）および PSTN トランク ゲートウェイのアドレス範囲を追加します。

  • IPアドレス信頼リストを使用してトール詐欺を防止する方法の詳細については、「IPアドレス信頼済み」を参照してください。

モード ボーダー要素

プラットフォームで Cisco Unified Border Element（CUBE）機能を有効にします。

allow-connections sip to sip

CUBE 基本 SIP バックツーバックユーザーエージェント機能を有効にします。 詳細については、「接続を許可」を参照してください。

デフォルトでは、T.38 ファックス転送が有効になっています。 詳細については、ファックスプロトコルt38 (音声サービス)を参照してください。

スタイン

STUN (NAT を介した UDP のセッショントラバーサル) をグローバルに有効にします。

これらのグローバル スタンコマンドは、NAT の後ろにローカル ゲートウェイを展開する場合にのみ必要です。

  • Webex Calling ユーザーにコールを転送する場合（たとえば、着信側と発信側の両方が Webex Calling サブスクライバであり、Webex Calling SBC でメディアをアンカーする場合）、ピンホールが開いていないため、メディアはローカル ゲートウェイにフローできません。

  • ローカル ゲートウェイの STUN バインディング機能により、ネゴシエートされたメディア パス上でローカルに生成された STUN 要求を送信できます。 これは、ファイアウォールのピンホールを開くのに役立ちます。

詳細については、「stun flowdata agent-id」および「stun flowdata shared-secret」を参照してください。

非対称ペイロード フル

DTMF と動的コーデック ペイロードの両方に対して SIP 非対称ペイロード サポートを設定します。 このコマンドの詳細については、非対称ペイロードを参照してください。

early-offer forced

ローカル ゲートウェイは、隣接するピアからの確認を待つ代わりに、最初の INVITE メッセージで SDP 情報を送信するように強制します。 このコマンドの詳細については、早期提供を参照してください。

SIP プロファイル着信

CUBE が SIP プロファイルを使用して、受信したメッセージを変更できるようにします。 プロファイルは、ダイヤルピアまたはテナントを介して適用されます。

3

を設定する 音声クラスコーデック 100 トランクの コーデック フィルタ。 この例では、すべてのトランクに同じコーデックフィルタが使用されます。 正確な制御のために各トランクにフィルタを設定できます。


voice class codec 100
 codec preference 1 opus
 codec preference 2 g711ulaw
 codec preference 3 g711alaw

設定フィールドの説明を次に示します。

音声クラス コーデック 100

SIP トランクを介したコールの優先コーデックのみを許可するために使用されます。 詳細については、「音声クラスコーデック」を参照してください。

Opus コーデックは、SIP ベースの PSTN トランクでのみサポートされています。 PSTN トランクが音声 T1/E1 またはアナログ FXO 接続を使用している場合は、コーデックの設定 1 オプスから音声クラスコーデック 100の設定。

4

を設定する 音声クラスの使い方 100 は、Webex Calling トランクで ICE を有効にします。 (この手順は政府版 Webex には適用されません)


voice class stun-usage 100 
 stun usage firewall-traversal flowdata
 stun usage ice lite

設定フィールドの説明を次に示します。

スタンの使用法 アイス ライト

すべての 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 には適用されません)


voice class srtp-crypto 100
 crypto 1 AES_CM_128_HMAC_SHA1_80

設定フィールドの説明を次に示します。

音声クラス srtp-crypto 100

SDP の SRTP 暗号スイート CUBE オファーおよび応答メッセージの唯一の SRTP オファーとして SHA1_80 を指定します。 Webex Calling は SHA180 のみをサポートします。_ 詳細については、音声クラス srtp-crypto を参照してください。

6

FIPS 準拠の GCM 暗号を設定します(この手順は政府版 Webex にのみ適用されます)。


voice class srtp-crypto 100
crypto 1 AEAD_AES_256_GCM

設定フィールドの説明を次に示します。

音声クラス srtp-crypto 100

CUBE が提供する暗号スイートとして GCM を指定します。 政府版 Webex のローカル ゲートウェイの GCM 暗号を設定することは必須です。

7

宛先 FQDN または SRV に基づいて、ローカル ゲートウェイ トランクへのコールを一意に識別するためのパターンを設定します。


voice class uri 100 sip
 pattern cube1.lgw.com

設定フィールドの説明を次に示します。

音声クラス uri 100 sip

着信トランク ダイヤル ピアへの着信 SIP 招待と一致するパターンを定義します。 このパターンを入力するときは、トランクの作成中に Control Hub で設定された LGW FQDN または SRV を使用します。

8

SIP メッセージ操作プロファイルを設定します。 ゲートウェイがパブリック IP アドレスで設定されている場合は、次のようにプロファイルを設定するか、NAT を使用している場合は、次のステップにスキップします。 この例では、cube1.lgw.com はローカル ゲートウェイ用に設定された FQDN であり、「198.51.100.1」は Webex Calling に面したローカル ゲートウェイ インターフェイスのパブリック IP アドレスです。


voice class sip-profiles 100
 rule 10 request ANY sip-header Contact modify "@.*:" "@cube1.lgw.com:" 
 rule 20 response ANY sip-header Contact modify "@.*:" "@cube1.lgw.com:"

設定フィールドの説明を次に示します。

ルール10と20

Webex がローカル ゲートウェイからのメッセージを認証できるようにするには、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 プロファイル

voice class sip-profiles 100
 rule 10 request ANY sip-header Contact modify "@.*:" "@cube1.lgw.com:"
 rule 20 response ANY sip-header Contact modify "@.*:" "@cube1.lgw.com:"
 rule 30 response ANY sdp-header Audio-Attribute modify "(a=candidate:1 1.*) 10.80.13.12" "\1 192.65.79.20"
 rule 31 response ANY sdp-header Audio-Attribute modify "(a=candidate:1 2.*) 10.80.13.12" "\1 192.65.79.20"
 rule 40 response ANY sdp-header Audio-Connection-Info modify "IN IP4 10.80.13.12" "IN IP4 192.65.79.20"
 rule 41 request ANY sdp-header Audio-Connection-Info modify "IN IP4 10.80.13.12" "IN IP4 192.65.79.20"
 rule 50 request ANY sdp-header Connection-Info modify "IN IP4 10.80.13.12" "IN IP4 192.65.79.20"
 rule 51 response ANY sdp-header Connection-Info modify "IN IP4 10.80.13.12" "IN IP4 192.65.79.20"
 rule 60 response ANY sdp-header Session-Owner modify "IN IP4 10.80.13.12" "IN IP4 192.65.79.20"
 rule 61 request ANY sdp-header Session-Owner modify "IN IP4 10.80.13.12" "IN IP4 192.65.79.20"
 rule 70 request ANY sdp-header Audio-Attribute modify "(a=rtcp:.*) 10.80.13.12" "\1 192.65.79.20"
 rule 71 response ANY sdp-header Audio-Attribute modify "(a=rtcp:.*) 10.80.13.12" "\1 192.65.79.20
 rule 80 request ANY sdp-header Audio-Attribute modify "(a=candidate:1 1.*) 10.80.13.12" "\1 192.65.79.20"
 rule 81 request ANY sdp-header Audio-Attribute modify "(a=candidate:1 2.*) 10.80.13.12" "\1 192.65.79.20"

設定フィールドの説明を次に示します。

ルール10と20

Webex がローカル ゲートウェイからのメッセージを認証できるようにするには、SIP 要求および応答メッセージの「連絡先」ヘッダーに、Control Hub のトランクにプロビジョニングされた値が含まれている必要があります。 これは、単一のホストの FQDN、またはデバイスのクラスタに使用される SRV ドメイン名のいずれかになります。

ルール30～81

プライベート アドレス参照をサイトの外部パブリック アドレスに変換し、Webex が後続のメッセージを正しく解釈してルーティングできるようにします。

Webex Calling からの着信メッセージの SIP プロファイル

voice class sip-profiles 110
 rule 10 response ANY sdp-header Video-Connection-Info modify "192.65.79.20" "10.80.13.12"
 rule 20 response ANY sip-header Contact modify "@.*:" "@cube1.lgw.com:"
 rule 30 response ANY sdp-header Connection-Info modify "192.65.79.20" "10.80.13.12"
 rule 40 response ANY sdp-header Audio-Connection-Info modify "192.65.79.20" "10.80.13.12"
 rule 50 response ANY sdp-header Session-Owner modify "192.65.79.20" "10.80.13.12"
 rule 60 response ANY sdp-header Audio-Attribute modify "(a=candidate:1 1.*) 192.65.79.20" "\1 10.80.13.12"
 rule 70 response ANY sdp-header Audio-Attribute modify "(a=candidate:1 2.*) 192.65.79.20" "\1 10.80.13.12"
 rule 80 response ANY sdp-header Audio-Attribute modify "(a=rtcp:.*) 192.65.79.20" "\1 10.80.13.12"

設定フィールドの説明を次に示します。

10から80までのルール

パブリックアドレス参照を設定済みのプライベートアドレスに変換し、Webex からのメッセージを CUBE で正しく処理できるようにします。

詳細については、「音声クラス sip プロファイル」を参照してください。

10

ヘッダー変更プロファイルを使用して SIP オプションをキープアライブに設定します。


voice class sip-profiles 115
 rule 10 request OPTIONS sip-header Contact modify "<sip:.*:" "<sip:cube1.lgw.com:" 
 rule 30 request ANY sip-header Via modify "(SIP.*) 10.80.13.12" "\1 192.65.79.20"
 rule 40 response ANY sdp-header Connection-Info modify "10.80.13.12" "192.65.79.20"  
 rule 50 response ANY sdp-header Audio-Connection-Info modify "10.80.13.12" "192.65.79.20"
!
voice class sip-options-keepalive 100
 description Keepalive for Webex Calling
 up-interval 5
 transport tcp tls
 sip-profiles 115

設定フィールドの説明を次に示します。

音声クラス 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 トランクの設定:

  1. を作成 音声クラス テナント 100は、Webex Callingトランクに必要な設定を定義し、グループ化します。 このテナントに関連付けられているダイヤルピアは、後でこれらの設定を継承します。

    次の例では、このガイドの目的のために、ステップ 1 に示されている値を使用します (太字で表示)。 これらを構成のトランクの値に置き換えます。

    
voice class tenant 100
 no remote-party-id
 sip-server dns:us25.sipconnect.bcld.webex.com
 srtp-crypto 100
 localhost dns:cube1.lgw.com
 session transport tcp tls
 no session refresh
 error-passthru
 bind control source-interface GigabitEthernet0/0/1
 bind media source-interface GigabitEthernet0/0/1
 no pass-thru content custom-sdp
 sip-profiles 100 
 sip-profiles 110 inbound
 privacy-policy passthru
!

    設定フィールドの説明を次に示します。

    音声クラス テナント 100

    テナントを使用して、独自の TLS 証明書と CN または SAN 検証リストを持つトランクを設定することをお勧めします。 ここでは、テナントに関連付けられた tls プロファイルに、新しい接続を受け入れるか作成するために使用される信頼ポイントが含まれており、着信接続を検証するための CN または SAN リストがあります。 詳細については、「音声クラス テナント」を参照してください。

    no remote-party-id

    Webex Calling が PAI をサポートしているため、SIP Remote-Party-ID (RPID) ヘッダーを無効にします。このヘッダーは CIO アサート済みID PAIだ 詳細については、「remote-party-id」を参照してください。

    sip-server dns:us25.sipconnect.bcld.webex.com

    トランクのターゲット SIP サーバを設定します。 トランクを作成したときに、Control Hub で提供されるエッジ プロキシ SRV アドレスを使用します

    srtp クリプト 100

    SRTP コール レッグ（接続）の優先暗号スイートを設定します（ステップ 5 で指定）。 詳細については、音声クラス srtp-crypto を参照してください。

    localhost DNS: キューブ1.lgw.com

    発信メッセージの [送信元（From）]、[コール ID（Call-ID）]、および [リモートパーティーID（Remote-Party-ID）] ヘッダーの物理的な IP アドレスを、提供された FQDN で置き換えるように CUBE を設定します。

    session transport tcp tls

    関連付けられたダイヤルピアの TLS へのトランスポートを設定します。 詳細については、「session-transport」を参照してください。

    セッション更新なし

    SIP セッションの更新をグローバルに無効にします。

    error-passthru

    SIP エラー応答パススルー機能を指定します。 詳細については、error-passthruを参照してください。

    バインド制御ソースインターフェイス GigabitEthernet0/0/1

    Webex Calling に送信されるメッセージのソース インターフェイスと関連する IP アドレスを設定します。 詳細は、bindを参照してください。

    バインド メディア ソース インターフェイス GigabitEthernet0/0/1

    Webex Calling に送信されるメディアのソース インターフェイスおよび関連する IP アドレスを設定します。 詳細は、bindを参照してください。

    音声クラス SIP プロファイル 100

    ヘッダー変更プロファイル（パブリック IP または NAT アドレス）を発信メッセージに使用するように適用します。 詳細については、「音声クラス SIP プロファイル」を参照してください。

    音声クラス SIP プロファイル 110 着信

    受信メッセージに使用するヘッダー変更プロファイル（NAT アドレスのみ）を適用します。 詳細については、音声クラス SIP プロファイルを参照してください。

    プライバシーポリシーpassthru

    トランクのプライバシー ヘッダー ポリシー オプションを設定して、受信したメッセージから次のコール レッグにプライバシーの値を渡します。 詳細については、プライバシーポリシーを参照してください。

  2. Webex Calling トランク ダイヤル ピアを設定します。

    
dial-peer voice 100 voip
 description Inbound/Outbound Webex Calling
 destination-pattern BAD.BAD
 session protocol sipv2
 session target sip-server
 incoming uri request 100
 voice-class codec 100
 voice-class stun-usage 100
 voice-class sip rel1xx disable
 voice-class sip asserted-id pai
 voice-class sip tenant 100
 voice-class sip options-keepalive profile 100
 dtmf-relay rtp-nte 
 srtp
 no vad

    設定フィールドの説明を次に示します。

    
dial-peer voice 100 voip
 description Inbound/Outbound Webex Calling

    のタグを持つVoIPダイヤルピアを定義する 100で、管理とトラブルシューティングを容易にする意味のある説明を提供します。 詳細については、「ダイヤルピアの音声」を参照してください。

    destination-pattern BAD.BAD

    着信ダイヤル ピア グループを使用して発信コールをルーティングする場合は、ダミー接続先パターンが必要です。 この場合、有効な宛先パターンを使用できます。

    session protocol sipv2

    ダイヤルピア を指定する 100 は SIP コール レッグを処理します。 詳細については、セッションプロトコル（ダイヤルピア）を参照してください。

    session target sip-server

    テナント 100 で定義された SIP サーバが継承され、このダイヤル ピアからのコールの宛先に使用されることを示します。

    着信 uri リクエスト 100

    VoIP ダイヤル ピアと着信コールのユニフォーム リソース 識別子（URI）を一致させるために使用される音声クラスを指定します。 詳細については、着信 uri を参照してください。

    音声クラス コーデック 100

    Webex Calling との通話のコーデック フィルター リストを示します。 詳細については、「音声クラスコーデック」を参照してください。

    音声クラスstun使用 100

    ローカル ゲートウェイでローカルに生成された STUN 要求を、ネゴシエートされたメディア パス経由で送信できるようにします。 STUN は、メディア トラフィックのファイアウォールのピンホールを開くのに役立ちます。

    音声クラス sip asserted-id pai

    プライバシー アサート済み ID（PAI）ヘッダーを使用して、発信通話情報を設定します。 詳細については、voice-class sip asserted-idを参照してください。

    音声クラス sip テナント 100

    ダイヤル ピアは、グローバルおよびテナント 100 で設定されたすべてのパラメータを継承します。 パラメータはダイヤルピア レベルで上書きされる場合があります。 詳細については、「音声クラス SIP テナント」を参照してください。

    音声クラス sip options-keepalive プロファイル 100

    このコマンドは、特定のプロファイル（100）を使用して、SIP サーバまたはエンドポイントのグループの可用性を監視するために使用されます。

    srtp

    コール レッグの SRTP を有効にします。

SIP PSTN トランクを使用したローカル ゲートウェイの設定

上記の Webex Calling に対してトランクを構築した後、次の設定を使用して、SIP ベースの PSTN プロバイダーに対して暗号化されていないトランクを作成します。

サービス プロバイダーがセキュアな PSTN トランクを提供している場合、上記の Webex Calling トランクと同様の構成に従うことができます。 セキュアからセキュアなコール ルーティングは CUBE でサポートされています。

TDM/ISDN PSTN トランクを使用している場合は、次のセクション「TDM PSTN トランクを使用したローカル ゲートウェイの設定」に進みます。

Cisco TDM-SIP ゲートウェイで PSTN コール レッグの TDM インターフェイスを設定するには、「ISDN PRI の設定」を参照してください。

1

PSTN トランクからの着信コールを識別するには、次の音声クラス uri を設定します。


voice class uri 200 sip
  host ipv4:192.168.80.13

設定フィールドの説明を次に示します。

音声クラス uri 200 sip

着信トランク ダイヤル ピアへの着信 SIP 招待と一致するパターンを定義します。 このパターンを入力するときは、IP PSTN ゲートウェイの IP アドレスを使用します。 詳細については、音声クラス uri を参照してください。

2

次の IP PSTN ダイヤル ピアを設定します。


dial-peer voice 200 voip
 description Inbound/Outbound IP PSTN trunk
 destination-pattern BAD.BAD
 session protocol sipv2
 session target ipv4:192.168.80.13
 incoming uri via 200
 voice-class sip bind control source-interface GigabitEthernet0/0/0 
 voice-class sip bind media source-interface  GigabitEthernet0/0/0 
 voice-class codec 100
 dtmf-relay rtp-nte 
 no vad

設定フィールドの説明を次に示します。


dial-peer voice 200 voip
 description Inbound/Outbound IP PSTN trunk

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 経由で 着信 uri

VIA ヘッダーと IP PSTN の IP アドレスの一致基準を定義します。 ローカル ゲートウェイのすべての着信 IP PSTN コール レッグとダイヤル ピア 200 を一致させます。 詳細については、着信 URLを参照してください。

バインド制御ソースインタフェース GigabitEthernet0/0/0

PSTN に送信されるメッセージのソース インターフェイスと関連する IP アドレスを設定します。 詳細は、bindを参照してください。

バインド メディア ソース インターフェイス GigabitEthernet0/0/0

PSTN に送信されるメディアのソース インターフェイスおよび関連する 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 プラットフォームを使用してローカル ゲートウェイを設定する場合は、次のセクションに進みます。

  1. ダイヤルピア グループを作成して、Webex Calling または PSTN にコールをルーティングします。 Webex Calling に向けて発信ダイヤルピア 100 で DPG 100 を定義します。 DPG 100 は、PSTN からの着信ダイヤルピアに適用されます。 同様に、PSTN に向かって発信ダイヤルピア 200 で DPG 200 を定義します。 DPG 200 は、Webex からの着信ダイヤルピアに適用されます。

    
voice class dpg 100 
 description Route calls to Webex Calling 
 dial-peer 100 
voice class dpg 200 
 description Route calls to PSTN 
 dial-peer 200

    設定フィールドの説明を次に示します。

    ダイヤルピア 100

    発信ダイヤルピアとダイヤルピア グループを関連付けます。 詳細は、音声クラス dpgを参照してください。

  2. ダイヤルピア グループを適用して、Webex から PSTN に、および PSTN から Webex にコールをルーティングします。

    
dial-peer voice 100
 destination dpg 200
dial-peer voice 200
 destination dpg 100

    設定フィールドの説明を次に示します。

    destination dpg 200

    どのダイヤル ピア グループを指定します。したがって、この着信ダイヤル ピアに提示されたコールの発信処理にダイヤル ピアを使用する必要があります。

    これでローカル ゲートウェイの設定は終了します。 CUBE 機能が初めて設定される場合は、設定を保存し、プラットフォームをリロードします。

TDM PSTN トランクを使用したローカル ゲートウェイの設定

Webex Calling に向けてトランクを構築した後は、次の設定を使用して、Webex コール レッグのメディア最適化を可能にするために、ループ バック コール ルーティングを備えた PSTN サービスの TDM トランクを作成します。

IP メディア最適化を必要としない場合は、SIP PSTN トランクの設定手順に従います。 PSTN VoIP ダイヤル ピアの代わりに、ボイス ポートと POTS ダイヤル ピア（手順 2 および 3 を参照）を使用します。
1

ループ バック ダイヤル ピア構成では、ダイヤル ピア グループとコール ルーティング タグを使用して、コール ルーティング ループを作成せずに、Webex と PSTN の間でコールが正しく渡されるようにします。 コール ルーティング タグの追加と削除に使用する次のトランスレーション ルールを設定します。


voice translation-rule 100 
 rule 1 /^\+/ /A2A/ 

voice translation-profile 100 
 translate called 100 

voice translation-rule 200 
 rule 1 /^/ /A1A/ 

voice translation-profile 200 
 translate called 200 

voice translation-rule 11 
 rule 1 /^A1A/ // 

voice translation-profile 11 
 translate called 11 

voice translation-rule 12 
 rule 1 /^A2A44/ /0/
 rule 2/^A2A/ /00/

voice translation-profile 12 
 translate called 12

設定フィールドの説明を次に示します。

音声翻訳ルール

ルールで定義された正規表現を使用して、コール ルーティング タグを追加または削除します。 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 インターフェイスの基本設定には、次のものが含まれます。


card type e1 0 2 
isdn switch-type primary-net5 
controller E1 0/2/0 
 pri-group timeslots 1-31
3

次の TDM PSTN ダイヤル ピアを設定します。


dial-peer voice 200 pots 
 description Inbound/Outbound PRI PSTN trunk 
 destination-pattern BAD.BAD 
 translation-profile incoming 200 
 direct-inward-dial 
 port 0/2/0:15

設定フィールドの説明を次に示します。


dial-peer voice 200 pots
 description Inbound/Outbound PRI PSTN trunk

タグ 200 で VoIP ダイヤル ピアを定義し、管理とトラブルシューティングを容易にするための意味のある説明を提供します。 詳細については、「ダイヤルピアの音声」を参照してください。

destination-pattern BAD.BAD

着信ダイヤル ピア グループを使用して発信コールをルーティングする場合は、ダミー接続先パターンが必要です。 詳細については、destination-pattern (interface)を参照してください。

翻訳プロファイル着信 200

着信着信番号にコール ルーティング タグを追加するトランスレーション プロファイルを割り当てます。

ダイレクト インワード ダイヤル

セカンダリ ダイヤル トーンを提供せずにコールをルーティングします。 詳細は、ダイレクト インワード ダイヤルを参照してください。

ポート 0/2:0:15

このダイヤル ピアに関連付けられている物理的な音声ポート。

4

TDM-IP コール フローでローカル ゲートウェイの IP パスのメディア最適化を有効にするには、Webex Calling と PSTN トランクの間に一連の内部ループ バック ダイヤル ピアを導入して、コール ルーティングを変更できます。 次のループバックダイヤルピアを設定します。 この場合、すべての着信コールは最初にダイヤルピア 10 にルーティングされ、そこから適用されたルーティング タグに基づいてダイヤルピア 11 または 12 にルーティングされます。 ルーティング タグを削除すると、コールはダイヤル ピア グループを使用して発信トランクにルーティングされます。


dial-peer voice 10 voip
 description Outbound loop-around leg
 destination-pattern BAD.BAD
 session protocol sipv2
 session target ipv4:192.168.80.14
 voice-class sip bind control source-interface GigabitEthernet0/0/0
 voice-class sip bind media source-interface GigabitEthernet0/0/0
 dtmf-relay rtp-nte
 codec g711alaw
 no vad 

dial-peer voice 11 voip
 description Inbound loop-around leg towards Webex
 translation-profile incoming 11
 session protocol sipv2
 incoming called-number A1AT
 voice-class sip bind control source-interface GigabitEthernet0/0/0
 voice-class sip bind media source-interface GigabitEthernet0/0/0
 dtmf-relay rtp-nte
 codec g711alaw
 no vad 

dial-peer voice 12 voip
 description Inbound loop-around leg towards PSTN
 translation-profile incoming 12
 session protocol sipv2
 incoming called-number A2AT
 voice-class sip bind control source-interface GigabitEthernet0/0/0
 voice-class sip bind media source-interface GigabitEthernet0/0/0
 dtmf-relay rtp-nte
 codec g711alaw 
 no vad

設定フィールドの説明を次に示します。


dial-peer voice 10 pots
 description Outbound loop-around leg

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

次のコール ルーティング設定を追加します。

  1. ダイヤルピア グループを作成して、ループバックを介して PSTN と Webex トランク間のコールをルーティングします。

    
voice class dpg 100
 description Route calls to Webex Calling
 dial-peer 100
voice class dpg 200
 description Route calls to PSTN
 dial-peer 200
voice class dpg 10
 description Route calls to Loopback
 dial-peer 10

    設定フィールドの説明を次に示します。

    ダイヤルピア 100

    発信ダイヤルピアとダイヤルピア グループを関連付けます。 詳細は、音声クラス dpgを参照してください。

  2. ダイヤル ピア グループを適用してコールをルーティングします。

    
dial-peer voice 100
 destination dpg 10
dial-peer voice 200
 destination dpg 10
dial-peer voice 11
 destination dpg 100
dial-peer voice 12
 destination dpg 200

    設定フィールドの説明を次に示します。

    宛先 DPG 200

    どのダイヤル ピア グループを指定します。したがって、この着信ダイヤル ピアに提示されたコールの発信処理にダイヤル ピアを使用する必要があります。

これでローカル ゲートウェイの設定は終了します。 CUBE 機能が初めて設定される場合は、設定を保存し、プラットフォームをリロードします。
既存の Unified CM 環境でのローカル ゲートウェイの設定

前のセクションの PSTN-Webex Calling 設定は、Cisco Unified Communications Manager (UCM) クラスタへの追加のトランクを含めるように変更される場合があります。 この場合、すべてのコールは Unified CM 経由でルーティングされます。 ポート 5060 の UCM からのコールは PSTN にルーティングされ、ポート 5065 からのコールは Webex Calling にルーティングされます。 次の増分設定を追加して、この通話シナリオを含めることができます。

1

以下の音声クラス URI を設定:

  1. SIP VIA ポートを使用して Unified CM を Webex コールに分類します。

    
voice class uri 300 sip
 pattern :5065

  2. ポート経由の SIP を使用して、Unified CM を PSTN コールに分類します。

    
voice class uri 400 sip
 pattern 192\.168\.80\.6[0-5]:5060

    発信元のソース アドレスとポート番号を説明する 1 つ以上のパターンを使用して、UCM からの着信メッセージを PSTN トランクに分類します。 必要に応じて、正規表現を使用して、一致するパターンを定義できます。

    上記の例では、192.168.80.60 から 65 までの範囲およびポート番号 5060 の任意の IP アドレスに一致させるために正規表現が使用されます。

2

次の DNS レコードを設定して、Unified CM ホストへの SRV ルーティングを指定します。

IOS XE は、これらのレコードをローカルでターゲット UCM ホストとポートを決定するために使用します。 この設定では、DNS システムでレコードを設定する必要はありません。 DNS を使用する場合は、これらのローカル設定は必要ありません。


ip host ucmpub.mydomain.com 192.168.80.60
ip host ucmsub1.mydomain.com 192.168.80.61
ip host ucmsub2.mydomain.com 192.168.80.62
ip host ucmsub3.mydomain.com 192.168.80.63
ip host ucmsub4.mydomain.com 192.168.80.64
ip host ucmsub5.mydomain.com 192.168.80.65
ip host _sip._udp.wxtocucm.io srv 0 1 5065 ucmpub.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub1.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub2.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub3.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub4.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub5.mydomain.com
ip host _sip._udp.pstntocucm.io srv 0 1 5060 ucmpub.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub1.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub2.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub3.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub4.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub5.mydomain.com

設定フィールドの説明を次に示します。

次のコマンドは、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

次のダイヤルピアを設定します。

  1. Unified CM と Webex Calling 間のコールのダイヤルピア:

    
dial-peer voice 300 voip
 description UCM-Webex Calling trunk
 destination-pattern BAD.BAD
 session protocol sipv2
 session target dns:wxtocucm.io
 incoming uri via 300
 voice-class codec 100
 voice-class sip bind control source-interface GigabitEthernet 0/0/0
 voice-class sip bind media source-interface GigabitEthernet 0/0/0
 dtmf-relay rtp-nte
 no vad

    設定フィールドの説明を次に示します。

    
dial-peer voice 300 voip
 description UCM-Webex Calling trunk

    タグ 300 を使用して VoIP ダイヤルピアを定義し、管理とトラブルシューティングを容易にするための意味のある説明を提供します。

    destination-pattern BAD.BAD

    着信ダイヤル ピア グループを使用して発信コールをルーティングする場合は、ダミー接続先パターンが必要です。 この場合、有効な宛先パターンを使用できます。

    session protocol sipv2

    ダイヤルピア 300 が SIP コール レッグを処理するように指定します。 詳細については、セッションプロトコル（ダイヤルピア）を参照してください。

    セッション ターゲット dns:wxtocucm.io

    DNS SRV 解決を通じて複数の Unified CM ノードのセッション ターゲットを定義します。 この場合、ローカルで定義された SRV レコード wxtocucm.io がコールをダイレクトするために使用されます。

    incoming uri via 300

    音声クラス URI 300 を使用して、ソース ポート 5065 を使用して Unified CM からのすべての着信トラフィックをこのダイヤル ピアにダイレクトします。 詳細については、着信 uri を参照してください。

    音声クラス コーデック 100

    Unified CM との間のコールのコーデック フィルタ リストを示します。 詳細については、「音声クラスコーデック」を参照してください。

    バインド制御ソースインタフェース GigabitEthernet0/0/0

    PSTN に送信されるメッセージのソース インターフェイスと関連する IP アドレスを設定します。 詳細は、bindを参照してください。

    バインド メディア ソース インターフェイス GigabitEthernet0/0/0

    PSTN に送信されるメディアのソース インターフェイスおよび関連する IP アドレスを設定します。 詳細は、bindを参照してください。

    dtmf-relay rtp-nte

    コール レッグで期待される DTMF 機能として RTP-NTE（RFC2833）を定義します。 詳細については、「DTMF Relay (Voice over IP)」を参照してください。

    no vad

    音声アクティブティの検出を無効にします。 詳細については、vad（ダイヤルピア）を参照してください。

  2. Unified CM と PSTN 間のコールのダイヤルピア:

    
dial-peer voice 400 voip
 description UCM-PSTN trunk
 destination-pattern BAD.BAD
 session protocol sipv2
 session target dns:pstntocucm.io
 incoming uri via 400
 voice-class codec 100 
 voice-class sip bind control source-interface GigabitEthernet 0/0/0
 voice-class sip bind media source-interface GigabitEthernet 0/0/0
 dtmf-relay rtp-nte
 no vad

    設定フィールドの説明を次に示します。

    
dial-peer voice 400 voip
 description UCM-PSTN trunk

    400のタグを含むVoIPダイヤルピアを定義し、管理とトラブルシューティングを容易にするための意味のある説明を提供します。

    destination-pattern BAD.BAD

    着信ダイヤル ピア グループを使用して発信コールをルーティングする場合は、ダミー接続先パターンが必要です。 この場合、有効な宛先パターンを使用できます。

    session protocol sipv2

    ダイヤルピア 400 が SIP コール レッグを処理するように指定します。 詳細については、セッションプロトコル（ダイヤルピア）を参照してください。

    セッション ターゲット dns:pstntocucm.io

    DNS SRV 解決を通じて複数の Unified CM ノードのセッション ターゲットを定義します。 この場合、ローカルで定義された SRV レコード pstntocucm.io がコールをダイレクトするために使用されます。

    URI を400 経由で着信

    音声クラス URI 400 を使用して、ソース ポート 5060 を使用して指定された Unified CM ホストからのすべての着信トラフィックをこのダイヤル ピアに転送します。 詳細については、着信 uri を参照してください。

    音声クラス コーデック 100

    Unified CM との間のコールのコーデック フィルタ リストを示します。 詳細については、「音声クラスコーデック」を参照してください。

    バインド制御ソースインタフェース GigabitEthernet0/0/0

    PSTN に送信されるメッセージのソース インターフェイスと関連する IP アドレスを設定します。 詳細は、bindを参照してください。

    バインド メディア ソース インターフェイス GigabitEthernet0/0/0

    PSTN に送信されるメディアのソース インターフェイスおよび関連する IP アドレスを設定します。 詳細は、bindを参照してください。

    dtmf-relay rtp-nte

    コール レッグで期待される DTMF 機能として RTP-NTE（RFC2833）を定義します。 詳細については、「DTMF Relay (Voice over IP)」を参照してください。

    no vad

    音声アクティブティの検出を無効にします。 詳細については、vad（ダイヤルピア）を参照してください。

4

次の設定を使用してコール ルーティングを追加します。

  1. Unified CM と Webex Calling の間で通話をルーティングするダイヤル ピア グループを作成します。 でDPG 100を定義する 発信ダイヤルピア 100 Webex Calling に移行します。 DPG 100 は、Unified CM から関連付けられた着信ダイヤルピアに適用されます。 同様に、Unified CM に向かって発信ダイヤルピア 300 で DPG 300 を定義します。 DPG 300 は、Webex からの着信ダイヤルピアに適用されます。

    
voice class dpg 100
 description Route calls to Webex Calling
 dial-peer 100
voice class dpg 300
 description Route calls to Unified CM Webex Calling trunk
 dial-peer 300

  2. Unified CM と PSTN の間でコールをルーティングするダイヤル ピア グループを作成します。 でDPG 200を定義する 発信ダイヤルピア 200 PSTNへ。 DPG 200 は、Unified CM から関連付けられた着信ダイヤルピアに適用されます。 同様に、Unified CM に向かって発信ダイヤルピア 400 で DPG 400 を定義します。 DPG 400 は、PSTN からの着信ダイヤルピアに適用されます。

    
voice class dpg 200
 description Route calls to PSTN
 dial-peer 200
voice class dpg 400
 description Route calls to Unified CM PSTN trunk
 dial-peer 400

    設定フィールドの説明を次に示します。

    ダイヤルピア 100

    発信ダイヤルピアとダイヤルピア グループを関連付けます。 詳細は、音声クラス dpgを参照してください。

  3. ダイヤルピア グループを適用して、Webex から Unified CM に、および Unified CM から Webex にコールをルーティングします。

    
dial-peer voice 100
 destination dpg 300
dial-peer voice 300
 destination dpg 100

    設定フィールドの説明を次に示します。

    宛先 DPG 300

    どのダイヤル ピア グループを指定します。したがって、この着信ダイヤル ピアに提示されたコールの発信処理にダイヤル ピアを使用する必要があります。

  4. ダイヤルピア グループを適用して、PSTN から Unified CM に、Unified CM から PSTN にコールをルーティングします。

    
dial-peer voice 200
 destination dpg 400
dial-peer voice 400
 destination dpg 200

    これでローカル ゲートウェイの設定は終了します。 CUBE 機能が初めて設定される場合は、設定を保存し、プラットフォームを再読み込みします。

診断署名によるローカル ゲートウェイの監視とトラブルシューティング

診断署名（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 以降を実行しているローカル ゲートウェイ

  1. 診断署名はデフォルトで有効になっています。

  2. デバイスが IOS XE 17.6.1 以降を実行している場合、プロアクティブな通知を送信するために使用するセキュア メール サーバを設定します。

    
configure terminal 
call-home  
mail-server <username>:<pwd>@<email server> priority 1 secure tls 
end

  3. 通知する管理者のメールアドレスで環境変数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% 以上になると、すべてのデバッグが無効になり、ローカル ゲートウェイにインストールするすべての診断シグネチャがアンインストールされます。 下記の手順を実行して署名をインストールします。

  1. コマンド を使用して 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

  2. 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 使用率

  3. 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)

  4. ローカルゲートウェイに DS XML ファイルをインストールします。

    
call-home diagnostic-signature load DS_64224.xml 
Load file DS_64224.xml success

  5. を使用する コールホーム診断署名を表示コマンドを使用して、署名が正常にインストールされていることを確認します。 ステータス列には「登録済み」の値が必要です。

    
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 とメール通知が生成されます。 下記の手順を実行して、署名をインストールしてください。

  1. コマンド を使用して 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

  2. Diagnostic Signatures Lookup Tool の以下のオプションを使用して、DS 65221 をダウンロードします。

    フィールド名

    フィールド値

    プラットフォーム

    Cisco 4300、4400 ISR シリーズ、または Catalyst 8000V Edge ソフトウェア

    製品

    Webex Calling ソリューションの CUBE Enterprise

    問題の範囲

    パフォーマンス

    問題の種類

    電子メールおよび Syslog 通知による SIP 異常な通話切断検出。

  3. DS XML ファイルをローカルゲートウェイにコピーします。

    copy ftp://username:password@<server name or ip>/DS_65221.xml bootflash:

  4. ローカルゲートウェイに DS XML ファイルをインストールします。

    
call-home diagnostic-signature load DS_65221.xml 
Load file DS_65221.xml success

  5. コマンド を使用する コールホーム診断署名を表示は、署名が正常にインストールされていることを確認します。 ステータス列の値が「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 は次のステップを使用して診断データ収集を自動化します。

  1. 診断データをアップロードするには、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"

  2. コマンド を使用して SNMP が有効になっていることを確認します。 SNMPを表示だ SNMP が有効になっていない場合は、snmpサーバーマネージャ コマンド

    
show snmp 
%SNMP agent not enabled 
 
config t 
snmp-server manager 
end

  3. High CPU monitoring DS 64224 は、CPU 使用率が高い時間帯にすべてのデバッグおよび診断シグネチャを無効にするプロアクティブな対策としてインストールすることをお勧めします。 Diagnostic Signatures Lookup Tool の以下のオプションを使用して、DS 64224 をダウンロードします。

    フィールド名

    フィールド値

    プラットフォーム

    Cisco 4300、4400 ISR シリーズ、または Catalyst 8000V Edge ソフトウェア

    製品

    Webex Calling ソリューションの CUBE Enterprise

    問題の範囲

    パフォーマンス

    問題の種類

    メール通知による高い CPU 使用率。

  4. 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

  5. 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:

  6. ローカル ゲートウェイに高 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

  7. を使用して署名が正常にインストールされていることを確認します。 コールホーム診断署名を表示だ ステータス列の値が「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 エンタープライズ展開が、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 設定ガイドを次に示します。

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

インターフェイスのステータスを追跡するために、グローバル レベルでインターフェイス トラッキングを構成します。

conf t
 track 1 interface GigabitEthernet1 line-protocol
 track 2 interface GigabitEthernet2 line-protocol
 exit


VCUBE-1#conf t

VCUBE-1(config)#track 1 interface GigabitEthernet1 line-protocol

VCUBE-1(config-track)#track 2 interface GigabitEthernet2 line-protocol

VCUBE-1(config-track)#exit

VCUBE-2#conf t

VCUBE-2(config)#track 1 interface GigabitEthernet1 line-protocol

VCUBE-2(config-track)#track 2 interface GigabitEthernet2 line-protocol

VCUBE-2(config-track)#exit

トラッキング CLI は、トラフィック インターフェイスがダウンした後、アクティブ ルートがアクティブな役割を果たすように、RG 内で音声トラフィックインターフェイスの状態を追跡するために使用されます。

2

アプリケーション冗長性サブモード下の VoIP HA で使用する RG を構成します。

redundancy
  application redundancy
   group 1
    name LocalGateway-HA
    priority 100 failover threshold 75
    control GigabitEthernet3 protocol 1
    data GigabitEthernet3
    timers delay 30 reload 60
    track 1 shutdown
    track 2 shutdown
    exit
   protocol 1
    timers hellotime 3 holdtime 10
   exit
  exit
 exit


VCUBE-1(config)#redundancy

VCUBE-1(config-red)#application redundancy

VCUBE-1(config-red-app)#group 1

VCUBE-1(config-red-app-grp)#name LocalGateway-HA

VCUBE-1(config-red-app-grp)#priority 100 failover threshold 75

VCUBE-1(config-red-app-grp)#control GigabitEthernet3 protocol 1

VCUBE-1(config-red-app-grp)#data GigabitEthernet3

VCUBE-1(config-red-app-grp)#timers delay 30 reload 60

VCUBE-1(config-red-app-grp)#track 1 shutdown

VCUBE-1(config-red-app-grp)#track 2 shutdown

VCUBE-1(config-red-app-grp)#exit

VCUBE-1(config-red-app)#protocol 1

VCUBE-1(config-red-app-prtcl)#timers hellotime 3 holdtime 10

VCUBE-1(config-red-app-prtcl)#exit

VCUBE-1(config-red-app)#exit

VCUBE-1(config-red)#exit

VCUBE-1(config)#

VCUBE-2(config)#redundancy

VCUBE-2(config-red)#application redundancy

VCUBE-2(config-red-app)#group 1

VCUBE-2(config-red-app-grp)#name LocalGateway-HA

VCUBE-2(config-red-app-grp)#priority 100 failover threshold 75

VCUBE-2(config-red-app-grp)#control GigabitEthernet3 protocol 1

VCUBE-1(config-red-app-grp)#data GigabitEthernet3

VCUBE-2(config-red-app-grp)#timers delay 30 reload 60

VCUBE-2(config-red-app-grp)#track 1 shutdown

VCUBE-2(config-red-app-grp)#track 2 shutdown

VCUBE-2(config-red-app-grp)#exit

VCUBE-2(config-red-app)#protocol 1

VCUBE-2(config-red-app-prtcl)#timers hellotime 3 holdtime 10

VCUBE-2(config-red-app-prtcl)#exit

VCUBE-2(config-red-app)#exit

VCUBE-2(config-red)#exit

VCUBE-2(config)#

この構成で使用されるフィールドの説明を次に示します。

  • redundancy—冗長性モードに入ります

  • application redundancy—アプリケーション冗長性構成モードに入ります

  • group—冗長性のあるアプリケーション グループ構成モードに入ります

  • name LocalGateway-HA— RG グループの名前を定義します

  • priority 100 failover threshold 75—RG の初期優先度とフェールオーバーしきい値を指定します

  • timers delay 30 reload 60—遅延およびリロードのため 2 回構成します

    • インターフェイスが起動した後、RG グループの初期設定と役割のネゴシエーションの遅延時間を示す遅延タイマーです。デフォルトは 30 秒です。 範囲は 0-10000 秒です

    • Reload—これは、リロード後の RG グループ初期設定と役割ネゴシエーションの遅延時間です。デフォルトは 60 秒です。 範囲は 0-10000 秒です

    • デフォルトのタイマーが推奨されていますが、これらのタイマーは、ネットワークのルーティングが安定した時点の後、RG プロトコルのネゴシエーションが行われることを保証するために、ルーターの起動/再読み込み中に発生する可能性がある追加のネットワーク集約遅延に合わせて調整される場合があります。 たとえば、フェールオーバー後に、新しいスタンバイに最大 20 秒間かかり、新しいアクティブから最初の RG HELLO パケットを確認する場合は、この遅延を考慮して、最初の RG HELLO パケットを「タイマー遅延 60 リロード 120」に調整する必要があります。

  • control GigabitEthernet3 protocol 1—keepalive および hello メッセージを 2 個の CUBE 間で交換するために使用されるインターフェイスを構成し、コントロール インターフェイスに接続するプロトコル インスタンスを指定し、冗長性アプリケーション プロトコル構成モードに入ります

  • data GigabitEthernet3—データ トラフィックのチェックポイントに使用されるインターフェイスを構成します

  • track—インターフェイスの RG グループ トラッキング

  • protocol 1—コントロール インターフェイスに接続するプロトコル インスタンスを指定し、冗長性のあるアプリケーション プロトコル構成モードに入ります

  • timers hellotime 3 holdtime 10—hellotime および holdtime の 2 つのタイマーを設定します

    • Hellotime— 連続する hello メッセージの間隔 (デフォルトで 3 秒)。 範囲は 250 ミリ秒から 254 秒です

    • Holdtime — Hello メッセージの受信と送信ルーターが失敗した推定の間隔。 この継続時間は、hello time (デフォルトの 10 秒より長くする必要があります) 以上である必要があります。 範囲は 750 ミリ秒から 255 秒です

      Holdtime タイマーを hellotime タイマーの最低 3 倍の値に設定することをお勧めします。

3

CUBE アプリケーションのボックス間の冗長性を有効にします。 以下の下にある以前の手順から RG を構成します： voice service voip です。 これにより、CUBE アプリケーションは冗長性プロセスをコントロールすることができます。 

voice service voip
   redundancy-group 1
   exit

VCUBE-1(config)#voice service voip

VCUBE-1(config-voi-serv)#redundancy-group 1


                        % Created RG 1 association with Voice B2B HA; reload the router for the new configuration to take effect
                      

VCUBE-1(config-voi-serv)# exit

VCUBE-2(config)#voice service voip

VCUBE-2(config-voi-serv)#redundancy-group 1


                        % Created RG 1 association with Voice B2B HA; reload the router for the new configuration to take effect
                      

VCUBE-2(config-voi-serv)# exit

redundancy-group 1—このコマンドを追加および削除するには、更新された構成を有効にするための再読み込みが必要です。 すべての構成が適用された後で、プラットフォームを再読み込みします。

4

以下に示すように、Gig1 と Gig2 インターフェイスをそれぞれの仮想 IP で構成し、冗長性インターフェイス識別子 (rii) を適用します。

VCUBE-1(config)#interface GigabitEthernet1

VCUBE-1(config-if)# redundancy rii 1

VCUBE-1(config-if)# redundancy group 1 ip 198.18.1.228 exclusive

VCUBE-1(config-if)# exit

VCUBE-1(config)#

VCUBE-1(config)#interface GigabitEthernet2

VCUBE-1(config-if)# redundancy rii 2

VCUBE-1(config-if)# redundancy group 1 ip 198.18.133.228 exclusive

VCUBE-1(config-if)# exit

VCUBE-2(config)#interface GigabitEthernet1

VCUBE-2(config-if)# redundancy rii 1

VCUBE-2(config-if)# redundancy group 1 ip 198.18.1.228 exclusive

VCUBE-2(config-if)# exit

VCUBE-2(config)#

VCUBE-2(config)#interface GigabitEthernet2

VCUBE-2(config-if)# redundancy rii 2

VCUBE-2(config-if)# redundancy group 1 ip 198.18.133.228 exclusive

VCUBE-v(config-if)# exit

この構成で使用されるフィールドの説明を次に示します。

  • redundancy rii—冗長性グループの冗長性インターフェイス ID を構成します。 仮想 MAC (VMAC) アドレスを生成するために必要です。 同じ VIP を持つ各ルーター (アクティブ/スタンバイ) のインターフェイスで同じ rii ID 値を使用する必要があります。

    同一の LAN に複数の B2B ペアがある場合、各ペアはそれぞれのインターフェイスで固有の rii Id を持つ必要があります (衝突を防ぐため)。 [冗長性アプリケーショングループのすべてを表示] が正しいローカルとピアの情報を示している必要があります。

  • redundancy group 1—上記の手順 2 で作成された冗長性グループにインターフェイスを関連付けます。 RG グループ、およびこの物理インターフェイスに割り当てられた VIP を構成します。

    冗長性のために別のインターフェイスを使用することが必須です。つまり、音声トラフィックに使用されるインターフェイスは、上記の手順 2 で指定したコントロールとデータ インターフェイスとして使用できません。 この例では、RG コントロール/データにギガビット インターフェイス 3 が使用されています。

5

最初の CUBE 構成を保存し、再読み込みします。

最後にリロードするプラットフォームは常にスタンバイです。

VCUBE-1#wr


                        Building configuration...
                      


                        [OK]
                      

VCUBE-1#reload


                        Proceed with reload? [confirm]

VCUBE-1 が完全に起動したら、 VCUBE-2 の構成を保存し、再読み込みします。

VCUBE-2#wr


                        Building configuration...
                      


                        [OK]
                      

VCUBE-2#reload


                        Proceed with reload? [confirm]
6

ボックス間の構成が期待どおりに機能していることを確認します。 関連する出力は太字で強調表示されます。

VCUBE-2 を最後にリロードし、設計上の考慮事項に従います。最後にリロードするプラットフォームは常に [スタンバイ] 状態です。


VCUBE-1#show redundancy application group all
Faults states Group 1 info:
       Runtime priority: [100]
               RG Faults RG State: Up.
                       Total # of switchovers due to faults:           0
                       Total # of down/up state changes due to faults: 0
Group ID:1
Group Name:LocalGateway-HA
  
Administrative State: No Shutdown
Aggregate operational state: Up
My Role: ACTIVE
Peer Role: STANDBY
Peer Presence: Yes
Peer Comm: Yes
Peer Progression Started: Yes

RF Domain: btob-one
         RF state: ACTIVE
         Peer RF state: STANDBY HOT

RG Protocol RG 1
------------------
        Role: Active
        Negotiation: Enabled
        Priority: 100
        Protocol state: Active
        Ctrl Intf(s) state: Up
        Active Peer: Local
        Standby Peer: address 10.1.1.2, priority 100, intf Gi3
        Log counters:
                role change to active: 1
                role change to standby: 1
                disable events: rg down state 0, rg shut 0
                ctrl intf events: up 1, down 0, admin_down 0
                reload events: local request 0, peer request 0

RG Media Context for RG 1
--------------------------
        Ctx State: Active
        Protocol ID: 1
        Media type: Default
        Control Interface: GigabitEthernet3
        Current Hello timer: 3000
        Configured Hello timer: 3000, Hold timer: 10000
        Peer Hello timer: 3000, Peer Hold timer: 10000
        Stats:
            Pkts 1509, Bytes 93558, HA Seq 0, Seq Number 1509, Pkt Loss 0
            Authentication not configured
            Authentication Failure: 0
            Reload Peer: TX 0, RX 0
            Resign: TX 0, RX 0
    Standy Peer: Present. Hold Timer: 10000
            Pkts 61, Bytes 2074, HA Seq 0, Seq Number 69, Pkt Loss 0

VCUBE-1#

VCUBE-2#show redundancy application group all
Faults states Group 1 info:
       Runtime priority: [100]
               RG Faults RG State: Up.
                       Total # of switchovers due to faults:           0
                       Total # of down/up state changes due to faults: 0
Group ID:1
Group Name:LocalGateway-HA
  
Administrative State: No Shutdown
Aggregate operational state: Up
My Role: STANDBY
Peer Role: ACTIVE
Peer Presence: Yes
Peer Comm: Yes
Peer Progression Started: Yes

RF Domain: btob-one
         RF state: ACTIVE
         Peer RF state: STANDBY HOT

RG Protocol RG 1
------------------
        Role: Active
        Negotiation: Enabled
        Priority: 100
        Protocol state: Active
        Ctrl Intf(s) state: Up
        Active Peer: address 10.1.1.2, priority 100, intf Gi3
        Standby Peer: Local
        Log counters:
                role change to active: 1
                role change to standby: 1
                disable events: rg down state 0, rg shut 0
                ctrl intf events: up 1, down 0, admin_down 0
                reload events: local request 0, peer request 0

RG Media Context for RG 1
--------------------------
        Ctx State: Active
        Protocol ID: 1
        Media type: Default
        Control Interface: GigabitEthernet3
        Current Hello timer: 3000
        Configured Hello timer: 3000, Hold timer: 10000
        Peer Hello timer: 3000, Peer Hold timer: 10000
        Stats:
            Pkts 1509, Bytes 93558, HA Seq 0, Seq Number 1509, Pkt Loss 0
            Authentication not configured
            Authentication Failure: 0
            Reload Peer: TX 0, RX 0
            Resign: TX 0, RX 0
    Standy Peer: Present. Hold Timer: 10000
            Pkts 61, Bytes 2074, HA Seq 0, Seq Number 69, Pkt Loss 0

VCUBE-2#

両方の CUBE でローカル ゲートウェイを構成する

この例の構成では、Control Hub から以下のトランク情報を使用して、VCUBE-1、VCUBE-2 の両方のプラットフォームでローカルゲートウェイを構成しています。 この設定のユーザー名とパスワードは以下のとおりです。

  • ユーザー名: フセイン1076_LGU

  • パスワード: lOV12MEaZx

1

クレデンシャルまたは共有秘密で使用する前に、以下のコマンドを使用して、設定キーがパスワードに対して作成されていることを確認してください。 Type 6 パスワードは、AES 暗号化とこのユーザー定義の設定キーを使用して暗号化されます。


LocalGateway#conf t
LocalGateway(config)#key config-key password-encrypt Password123
LocalGateway(config)#password encryption aes

これは、上に表示されている Control Hub のパラメーターに基づき、両方のプラットフォームに適用し、保存し、リロードするローカ ルゲートウェイの構成です。 Control Hub からの SIP ダイジェスト クレデンシャルは太字でハイライトされています。


configure terminal
crypto pki trustpoint dummyTp
revocation-check crl
exit
sip-ua
crypto signaling default trustpoint dummyTp cn-san-validate server
transport tcp tls v1.2
end


configure terminal
crypto pki trustpool import clean url
http://www.cisco.com/security/pki/trs/ios_core.p7b
end


configure terminal
voice service voip
  ip address trusted list
    ipv4 x.x.x.x y.y.y.y
    exit
   allow-connections sip to sip
  media statistics
  media bulk-stats
  no supplementary-service sip refer
  no supplementary-service sip handle-replaces
  fax protocol pass-through g711ulaw
  stun
    stun flowdata agent-id 1 boot-count 4
    stun flowdata shared-secret 0 Password123!
  sip
    g729 annexb-all
    early-offer forced
    end


configure terminal
voice class sip-profiles 200
  rule 9 request ANY sip-header SIP-Req-URI modify "sips:(.*)"
"sip:\1"
  rule 10 request ANY sip-header To modify "<sips:(.*)" "<sip:\1"
  rule 11 request ANY sip-header From modify "<sips:(.*)" "<sip:\1"
  rule 12 request ANY sip-header Contact modify "<sips:(.*)>"
"<sip:\1;transport=tls>"
  rule 13 response ANY sip-header To modify "<sips:(.*)" "<sip:\1"
  rule 14 response ANY sip-header From modify "<sips:(.*)" "<sip:\1"
  rule 15 response ANY sip-header Contact modify "<sips:(.*)"
"<sip:\1"
  rule 20 request ANY sip-header From modify ">"
";otg=hussain1076_lgu>"
  rule 30 request ANY sip-header P-Asserted-Identity modify
"sips:(.*)" "sip:\1"


voice class codec 99
  codec preference 1 g711ulaw
  codec preference 2 g711ulaw
  exit

voice class srtp-crypto 200
  crypto 1 AES_CM_128_HMAC_SHA1_80
  exit

voice class stun-usage 200
  stun usage firewall-traversal flowdata
  exit






voice class tenant 200
  registrar dns:40462196.cisco-bcld.com scheme sips expires 240
refresh-ratio 50 tcp tls
  credentials number Hussain5091_LGU username Hussain1076_LGU
password 0 lOV12MEaZx realm Broadworks 
  authentication username Hussain5091_LGU password 0 lOV12MEaZx
realm BroadWorks

  authentication username Hussain5091_LGU password 0 lOV12MEaZx
realm 40462196.cisco-bcld.com
  no remote-party-id
  sip-server dns:40462196.cisco-bcld.com
  connection-reuse
  srtp-crypto 200
  session transport tcp tls
  url sips
  error-passthru
  asserted-id pai
  bind control source-interface GigabitEthernet1
  bind media source-interface GigabitEthernet1
  no pass-thru content custom-sdp
  sip-profiles 200
  outbound-proxy dns:la01.sipconnect-us10.cisco-bcld.com
  privacy-policy passthru


voice class tenant 100
  session transport udp
  url sip
  error-passthru
  bind control source-interface GigabitEthernet2
  bind media source-interface GigabitEthernet2
  no pass-thru content custom-sdp

voice class tenant 300
  bind control source-interface GigabitEthernet2
  bind media source-interface GigabitEthernet2
  no pass-thru content custom-sdp
  

voice class uri 100 sip
 host ipv4:198.18.133.3

voice class uri 200 sip
 pattern dtg=hussain1076.lgu



dial-peer voice 101 voip
 description Outgoing dial-peer to IP PSTN
 destination-pattern BAD.BAD
 session protocol sipv2
 session target ipv4:198.18.133.3
 voice-class codec 99
 voice-class sip tenant 100
 dtmf-relay rtp-nte
 no vad

dial-peer voice 201 voip
 description Outgoing dial-peer to Webex Calling
 destination-pattern BAD.BAD
 session protocol sipv2
 session target sip-server
 voice-class codec 99
 voice-class stun-usage 200
 no voice-class sip localhost
 voice-class sip tenant 200
 dtmf-relay rtp-nte
 srtp
 no vad


voice class dpg 100
 description Incoming WebexCalling(DP200) to IP PSTN(DP101)
 dial-peer 101 preference 1

voice class dpg 200
 description Incoming IP PSTN(DP100) to Webex Calling(DP201)
 dial-peer 201 preference 1





dial-peer voice 100 voip
 desription Incoming dial-peer from IP PSTN
 session protocol sipv2
 destination dpg 200
 incoming uri via 100
 voice-class codec 99
 voice-class sip tenant 300
 dtmf-relay rtp-nte
 no vad

dial-peer voice 200 voip
 description Incoming dial-peer from Webex Calling
 session protocol sipv2
 destination dpg 100
 incoming uri request 200
 voice-class codec 99
 voice-class stun-usage 200
 voice-class sip tenant 200
 dtmf-relay rtp-nte
 srtp
 no vad

end

copy run start

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-1#show redundancy application group 1
Group ID:1
Group Name:LocalGateway-HA

Administrative State: No Shutdown
Aggregate operational state : Up
My Role: Standby
Peer Role: ACTIVE
Peer Presence: Yes
Peer Comm: Yes
Peer Progression Started: Yes

RF Domain: btob-one
         RF state: STANDBY HOT
         Peer RF state: ACTIVE

VCUBE-1#show sip-ua register status
VCUBE-1#


VCUBE-2#show redundancy application group 1
Group ID:1
Group Name:LocalGateway-HA

Administrative State: No Shutdown
Aggregate operational state : Up
My Role: ACTIVE
Peer Role: STATUS
Peer Presence: Yes
Peer Comm: Yes
Peer Progression Started: Yes

RF Domain: btob-one
         RF state: ACTIVE
         Peer RF state: STANDBY HOT

VCUBE-2#show sip-ua register status

Tenant: 200
--------------------Registrar-Index  1 ---------------------
Line                           peer       expires(sec) reg survival P-Associ-URI
============================== ========== ============ === ======== ============
Hussain5091_LGU                -1          48          yes normal
VCUBE-2#

上記の出力から、 VCUBE-2 がアクティブ LGW で、Webex Calling アクセス SBC への登録を維持していることがわかります。しかし、「show sip-ua register status」の出力は VCUBE-1 では空です

3

VCUBE-1 で次のデバッグを有効にします


VCUBE-1#debug ccsip non-call
SIP Out-of-Dialog tracing is enabled
VCUBE-1#debug ccsip info
SIP Call info tracing is enabled
VCUBE-1#debug ccsip message
4

この場合、アクティブ LGW、VCUBE-2 で次のコマンドを実行してフェールオーバーをシミュレートします。


VCUBE-2#redundancy application reload group 1 self

アクティブからスタンバイ LGW への切り替えは、上記に一覧表示されている CLI に加えて、以下のシナリオで発生します。

  • アクティブ ルーターのリロード時

  • アクティブなルーターの電源が再投入される時

  • トラッキングが有効になっているアクティブなルーターの RG 構成されたインターフェイスがシャットダウンされる時

5

VCUBE-1 が Webex Calling アクセス SBC に登録されているかどうかを確認します。 VCUBE-2 は今すぐにリロードされます。


              VCUBE-1#show sip-ua register status

Tenant: 200
--------------------Registrar-Index  1 ---------------------
Line                           peer       expires(sec) reg survival P-Associ-URI
============================== ========== ============ === ======== ============
Hussain5091_LGU                -1          56          yes normal
VCUBE-1#

VCUBE-1 がアクティブ LGW になりました。

6

仮想 IP を通じて SIP REGISTER を Webex Calling に送信し、200 OK を受信する VCUBE-1 に関連するデバッグ ログを確認してください。


VCUBE-1#show log

Jan 9 18:37:24.769: %RG_MEDIA-3-TIMEREXPIRED: RG id 1 Hello Time Expired.
Jan 9 18:37:24.771: %RG_PROTCOL-5-ROLECHANGE: RG id 1 role change from Standby to Active
Jan 9 18:37:24.783: %VOICE_HA-2-SWITCHOVER_IND: SWITCHOVER, from STANDBY_HOT to ACTIVE state.
Jan 9 18:37:24.783: //-1/xxxxxxxxxxxx/SIP/Info/info/4096/sip_ha_notify_active_role_event: Received notify active role event

Jan 9 18:37:25.758: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
REGISTER sip: 40462196.cisco-bcld.com:5061 SIP/2.0
Via: SIP/2.0/TLS 198.18.1.228:5061;branch=z9hG4bK0374
From: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189
To: <sip:Hussain5091_LGU@40462196.cisco-bcld.com>
Date: Thu, 09 Jan 2020 18:37:24 GMT
Call-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97
User-Agent: Cisco-SIPGateway/IOS-16.12.02
Max-Forwards: 70
Timestamp: 1578595044
CSeq: 2 REGISTER
Contact: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls>
Expires: 240
Supported: path
Content-Length: 0


Jan 9 18:37:25.995: //-1/000000000000/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 401 Unauthorized
Via: SIP/2.0/TLS 198.18.1.228:5061;received=173.38.218.1;branch=z9hG4bK0374;rport=4742
From: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189
To: <sip:Hussain5091_LGU@40462196.cisco-bcld.com>;tag=SD1u8bd99-1324701502-1578595045969
Date: Thu, 09 Jan 2020 18:37:24 GMT
Call-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97
Timestamp: 1578595044
CSeq: 2 REGISTER
WWW-Authenticate; DIGEST realm="BroadWorks",qop="auth",nonce="BroadWorksXk572qd01Ti58zliBW",algorithm=MD5
Content-Length: 0


Jan 9 18:37:26.000: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
REGISTER sip:40462196.cisco-bcld.com:5061 SIP/2.0
Via: SIP/2.0/TLS 198.18.1.228:5061;branch=z9hG4bK16DC
From: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189
To: <sip:Hussain5091_LGU@40462196.cisco-bcld.com>
Date: Thu, 09 Jan 2020 18:37:25 GMT
Call-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97
User-Agent:Cisco-SIPGateway/IOS-16.12.02
Max-Forwards: 70
Timestamp: 1578595045
CSeq: 3 REGISTER
Contact: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls>
Expires: 240
Supported: path
Authorization: Digest username="Hussain1076_LGU",realm="BroadWorks",uri="sips:40462196.cisco-bcld.com:5061",response="b6145274056437b9c07f7ecc08ebdb02",nonce="BroadWorksXk572qd01Ti58z1iBW",cnonce="3E0E2C4D",qop=auth,algorithm=MD5,nc=00000001
Content-Length: 0


Jan 9 18:37:26.190: //1/000000000000/SIP/Msg/ccsipDisplayMsg:

Received:
SIP/2.0 200 OK
Via: SIP/2.0/TLS 198.18.1.228:5061;received=173.38.218.1;branch=z9hG4bK16DC;rport=4742
From: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189
To: <sip:Hussain5091_LGU@40462196.cisco-bcld.com>;tag=SD1u8bd99-1897486570-1578595-46184
Call-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97
Timestamp: 1578595045
CSeq: 3 REGISTER
Contact: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls>;expires=120;q=0.5
Allow-Events: call-info,line-seize,dialog,message-summary,as-feature-event,x-broadworks-hoteling,x-broadworks-call-center-status,conference
Content-Length: 0

Webex Calling のために Unified CM を構成する

ローカル ゲートウェイへトランクするための SIP トランク セキュリティ プロファイルを構成する

ローカル ゲートウェイと PSTN ゲートウェイが同じデバイス上に存在する場合、Unified CM を有効にして、同じデバイスから発信された 2 個の異なるトラフィックの種類 (Webex と PSTN のコール) を区別し、これらのコール タイプに対して差別化されたクラスのサービスを適用する必要があります。 この差別化されたコール処理は、Unified CM および結合されたローカル ゲートウェイと PSTN ゲートウェイ デバイスの 2 つのトランクをプロビジョニングすることで行われます。これは、2 つのトランクに異なる SIP リスニング ポートを必要とします。

次の設定でローカル ゲートウェイ トランクの専用の SIP トランク セキュリティ プロファイルを作成します。

設定値
名前固有の名前 (Webex など)
説明Webex SIP トランク セキュリティ プロファイルなどの意味のある説明
着信ポートWebex 間のトラフィックでは、ローカル ゲートウェイ構成で使用されるポートと一致する必要があります。 ハインリヒ5世

ローカル ゲートウェイ トランクの SIP プロファイルを構成する

次の設定でローカル ゲートウェイ トランク用の専用の SIP プロファイルを作成します。

設定値
名前固有の名前 (Webex など)
説明意味のある説明 (Webex SIP プロファイルなど)
オプションの Ping を有効にして、サービス タイプ「なし (デフォルト)」のトランクの宛先ステータスをモニタします。選択

Webex からのコールのコール検索スペースを作成する

次の設定で Webex から発信されたコールのためのコール検索スペースを作成します。

設定値
名前固有の名前 (Webex など)
説明意味のある説明 (Webex Calling 検索スペースなど)
選択済みパーティション:

DN (+E.164 ディレクトリ番号)

ESN (省略形のサイトダイヤル)

PSTNInternational (PSTN アクセス)

onNetRemote (GDPR 学習先)

最後のパーティション onNetRemote は、Intercluster Lookup Service (ILS) または Global Dialplan Replication (GDPR) を使用して、Unified CM クラスター間でルーティング情報が交換されるマルチクラスター環境でのみ使用されます。

Webex 間で SIP トランクを構成する

次の設定を使用して、ローカル ゲートウェイ経由での Webex 間のコールに SIP トランクを作成します。

設定値
デバイス情報
DeviceName固有の名前 (Webex など)
説明意味のある説明 (Webex SIP トランク など)
すべてのアクティブな Unified CM ノード上で実行する選択
着信コール
コール検索スペース以前に定義されたコール検索スペース: Webex
AAR コール検索スペースPSTN ルート パターンへのアクセス権のみを持つコール検索スペース: PSTNReroute
SIP 情報
接続先アドレスローカル ゲートウェイ CUBE の IP アドレス
移動先ポートカワサキ・S60
SIP トランク セキュリティ プロファイル定義済み: Webex
SIP プロファイル定義済み: Webex

Webex のルート グループを構成する

次の設定でルート グループを作成します。

設定値
ルート グループ情報
ルート グループ名固有の名前 (Webex など)
選択したデバイス以前に構成された SIP トランク: Webex

Webex のルート リストを構成する

次の設定でルート リストを作成します。

設定値
ルート リスト情報
名前一意の名前 (RL_Webex など)
説明意味のある説明 (Webex のルート リストなど)
すべてのアクティブな Unified CM ノード上で実行する選択
ルート リスト メンバー情報
選択したグループ以前に定義されたルート グループのみ: Webex

Webex の移動先のパーティションを作成する

次の設定で Webex の移動先のパーティションを作成します。

設定値
ルート リスト情報
名前固有の名前 (Webex など)
説明意味のある説明 (Webex のパーティションなど)

次に行うこと

このパーティションは、Webex の宛先にアクセスする必要があるすべてのコール検索スペースに追加してください。 このパーティションは、PSTN から Webex への発信がルーティングされるように、PSTN トランクの着信コール検索スペースとして使用されるコール検索スペースに特に追加する必要があります。

Webex の移動先のルート パターンを構成する

次の設定で Webex の各 DID 範囲のルート パターンを構成します。

設定値
ルートパターン「\」が頭文字にある Webex で DID 範囲のフル +E.164 パターン 例: \+140855501XX
ルート パーティションWebex
ゲートウェイ/ルート リストRL_Webex
緊急の優先事項選択

Webex の簡略サイト間ダイヤル正規化を構成する

短縮されたサイト間ダイヤルが Webex に必要な場合は、Webex の各 ESB 範囲にダイヤル正規化パターンを設定します。

設定値
翻訳パターンWebex の ESN 範囲の ESB パターン。 例: 80121XX
パーティションWebex
説明Webex の正規化パターンなどの意味のある説明
発信者のコール検索スペースを使用する選択
緊急の優先事項選択
後続ホップでの連続桁のタイムアウトを待たない選択
着信側トランスフォーム マスク番号を + E.164 に正規化するマスク。 例: +140855501XXさん

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

[保存] をクリックします。

Privacy settings

モニタリングの設定

ユーザーの監視対象回線の最大数は 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）] フィールドに入力された名前です。

実際の例を見てみましょう。 Control Hub でユーザーのモニタリング設定を管理する方法については、このビデオ デモンストレーションをご覧ください。

ユーザーのコール ブリッジ警告トーンを有効にする

始める前に

コール ブリッジを呼び出すには、共有回線を設定する必要があります。 コール ブリッジの警告トーンが再生される前に、共有回線を設定する方法を参照してください。
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

[保存] をクリックします。

ユーザは、ユーザ ハブから使用するホテリング ホストを検索し、検索することもできます。 詳細については、「どこからでも通話プロファイルにアクセスする」を参照してください。

実際の例を見てみましょう。 Control Hub でホテリングを設定する方法については、このビデオ デモンストレーションをご覧ください。

Webex Calling の導入傾向と使用レポート

通話レポートを表示する

Control Hub の [アナリティクス] ページを使用して、ユーザーがどのように Webex Calling と Webex アプリ (エンゲージメント) を使用しているか、また、通話のメディア エクスペリエンスの質について洞察を得ることができます。 Webex Calling のアナリティクスにアクセスするには、Control Hub にサインインし、[アナリティクス] に移動して、[Calling] タブを選択します。

1

通話履歴レポートの詳細については、Control Hub にサインインし、分析 > 通話。

2

[通話履歴の詳細] を選択します。

専用インスタンスを使用する通話の詳細については、「専用インスタンスの分析」を参照してください。

3

メディア品質データにアクセスするには、Control Hub にサインインし、[アナリティクス] に移動して、[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 注文ガイドのローカル ゲートウェイの表 1 を参照してください。また、ローカル ゲートウェイ設定ガイドに従って、プラットフォームがサポートされている IOS-XE リリースを実行していることを確認してください。

ローカル ゲートウェイは、自分のペースで 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

次のオプションから選択します:

  • パートナー管理者の場合は、[保存して閉じる] をクリックして、顧客管理者が Webex Calling のプロビジョニングを完了するようにします。
  • 必要なロケーションの情報を入力します。ウィザードでロケーションを作成した後、後で他にロケーションを作成できます。

セットアップ ウィザードを完了した後で、作成したロケーションにメイン番号を追加していることを確認してください。

7

このロケーションに適用する次の選択を行います。

  • アナウンス言語—新しいユーザーと機能の音声アナウンスとプロンプト用。
  • メール言語—新規ユーザーのメール通信に使用します。
  • 国
  • タイムゾーン
8

[次へ] をクリックします。

9

利用可能な Cisco Webex SIP アドレスを入力し、[次へ] をクリックし、[完了] を選択します。

ロケーションを追加する

始める前に

新しいロケーションを作成するには、以下の情報を指定します。

  • ロケーションの住所

  • 希望する電話番号(オプション)

1

https://admin.webex.comでControl Hubにログインし、［管理 ］>［ロケーション］の順に移動します。

新しいロケーションは、初回セットアップウィザードを使用して選択した国に対応する地域データセンターでホストされます。
2

ロケーションを設定します。

  • ロケーション名—ロケーションを識別する一意の名前を入力します。
  • 国/地域—ロケーションを結び付ける国を選択します。たとえば、米国に 1 か所のロケーション (本社) を作成し、イギリスに別のロケーション (支社) を作成することができます。選択した国に応じて、その後の住所のフィールドが決まります。ここには、例として、米国の住所書式を使用したものがあります。
  • ロケーションアドレス—ロケーションのメインのメールアドレスを入力します。
  • 都市/町—このロケーションの都市を入力します。
  • 都道府県/地域—ドロップダウンから都道府県を選択します。
  • ZIP/郵便番号—郵便番号または郵便番号を入力します。
  • アナウンス言語—新しいユーザーと機能の音声アナウンスとプロンプトの言語を選択します。
  • メール言語—新規ユーザーとのメール通信に使用する言語を選択します。
  • タイムゾーン:ロケーションのタイムゾーンを選択します。
3

[保存 ] をクリックしてから、[ はい/いいえ ] を選択して、現在または後でロケーションに番号を追加します。

4

[はい] をクリック した場合、次のいずれかのオプションを選択します。

  • Cisco PSTN —Cisco からクラウド PSTN ソリューションを使用する場合は、このオプションを選択します。Cisco 通話プランは、緊急通話、着信、および国内および国際通話を提供する PSTN 代替ソリューションであり、新しい PSTN 番号または既存の番号を Cisco にポートすることができます。

    Cisco PSTN オプションは、以下の条件でのみ表示されます。

    • コミットされた Cisco Calling プラン OCP (アウトバウンド通話プラン) を少なくとも 1 つ購入している。

    • Cisco Calling プランがサポートされている国にロケーションがある。

    • ロケーションが新規である。他の PSTN 機能が割り当てられている既存のロケーションは、今回は Cisco Calling プランの対象外です。サポートケースを開く

    • Cisco Calling プランがサポートされている地域の Webex Calling データセンターでホストされています。

  • Cloud Connected PSTN—多くの Cisco CCP パートナーの 1 つからクラウド PSTN ソリューションを探している場合、またはロケーションで Cisco Calling プランが利用できない場合、このオプションを選択します。CCP パートナーは、PSTN 代替ソリューション、グローバルな広域カバレッジ、広範でさまざまな機能、パッケージ、価格設定を提供しています。

    CCP パートナーと対応地域は、こちらにリストされています。ロケーションの国がサポートされているパートナーにのみ表示されています。パートナーは、ロゴで表示されるか、簡単な文字列と括弧で囲んだ地域名で表示されます (例: (EU)、(US)、または (CA))。ロゴが表示されているパートナーは、常に CCP の地域メディアを提供しています。文字列で表示されているパートナーについては、CCP の地域メディアを確保するために、ロケーションの国に最も近い地域を選択してください。

    リストされているプロバイダーの下に [番号を今すぐ注文する] オプションがある場合は、そのオプションを選択して、統合された CCP のメリットを利用することをおすすめします。統合された CCP の場合、電話番号の調達とプロビジョニングを Control Hub の 1 つのペインで行えます。統合されていない CCP の場合、Control Hub の外で、CCP パートナーから電話番号を調達する必要があります。

  • プレミスベースの PSTN（ローカルゲートウェイ）:現在の PSTN プロバイダーを保持する場合、またはクラウド以外のサイトをクラウドサイトに接続する場合は、このオプションを選択できます。

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](ローカル ゲートウェイ) のいずれかを選択します。[管理] をクリックして設定を変更してから、[続行] を選択することにより、関連するリスクを承認します。以下のオプションのいずれかを選択して、[保存] クリックします。

  • Cisco PSTN —Cisco からクラウド PSTN ソリューションを使用する場合は、このオプションを選択します。Cisco 通話プランは、緊急通話、着信、および国内および国際通話を提供する PSTN 代替ソリューションであり、新しい PSTN 番号または既存の番号を Cisco にポートすることができます。

    Cisco PSTN オプションは、以下の条件でのみ表示されます。

    • コミットされた Cisco Calling プラン OCP (アウトバウンド通話プラン) を少なくとも 1 つ購入している。

    • Cisco Calling プランがサポートされている国にロケーションがある。

    • ロケーションが新規である。現在、他の PSTN 機能が割り当てられている既存のロケーションは、Cisco Calling プランの対象外です。サポートケースを開く

    • Cisco Calling プランがサポートされている地域の Webex Calling データセンターでホストされています。

  • Cloud Connected PSTN—多くの Cisco CCP パートナーの 1 つからクラウド PSTN ソリューションを探している場合、またはロケーションで Cisco Calling プランが利用できない場合、このオプションを選択します。CCP パートナーは、PSTN 代替ソリューション、グローバルな広域カバレッジ、広範でさまざまな機能、パッケージ、価格設定を提供しています。

    CCP パートナーと対応地域は、こちらにリストされています。ロケーションの国がサポートされているパートナーにのみ表示されています。パートナーは、ロゴで表示されるか、簡単な文字列と括弧で囲んだ地域名で表示されます (例: (EU)、(US)、または (CA))。ロゴが表示されているパートナーは、常に CCP の地域メディアを提供しています。文字列で表示されているパートナーについては、CCP の地域メディアを確保するために、ロケーションの国に最も近い地域を選択してください。

    リストされているプロバイダーの下で番号を今すぐ注 文するオプションが表示された場合は、そのオプションを選択して、統合型CCPを利用することをお勧めします。統合された CCP の場合、電話番号の調達とプロビジョニングを Control Hub の 1 つのペインで行えます。統合されていない CCP では、Control Hub 以外の CCP パートナーから電話番号を取得する必要があります。

  • プレミスベースの PSTN（ローカルゲートウェイ）:現在の PSTN プロバイダーを保持する場合、またはクラウド以外のサイトをクラウドサイトに接続する場合は、このオプションを選択できます。

    Webex Calling ゲートウェイで以前に設定されたロケーションを持つ顧客は、対応するトランクを使用してオンプレミスPSTNに自動的に変換されます。

3

ロケーションで、ドロップダウンリストから代表番 号を選択し、そのロケーションのユーザーがコールを発信および受信できるようにします。

メイン番号を自動アテンダントに割り当てて、外部発信者がそのロケーションの Webex Calling ユーザーに連絡できるようにします。そのロケーションの Webex Calling ユーザーは、発信時にこの番号を外部発信者 ID として使用することもできます。
4

(オプション) [緊急コール] で[緊急時のロケーション識別子] を選択して、このロケーションに割り当てることができます。

この設定はオプションで、必要な国にのみ適用されます。

一部の国 (例: フランス) の規制要件は、緊急電話を行い、緊急連絡時にセルの識別を確立するためのセルに関する規制要件であり、緊急権限によって利用可能になります。米国やカナダのような他の国々は、他の方法を用いて位置決定を実施しています。詳細については、「緊急時通話の強化 」を参照してください。

緊急通話プロバイダはアクセスネットワークに関する情報が必要な場合があります。新しいプライベートSIP拡張ヘッダーであるP-Access-Network-Infoを指定することで達成できます。ヘッダーにはアクセスネットワークに関連する情報が含まれます。

場所に緊急ロケーション識別子を設定すると、場所の値は SIP メッセージの一部としてプロバイダーに送信されます。緊急通話プロバイダーに連絡して、この設定が必要で、緊急通話プロバイダーから提供された値を使用する必要がある場合はそれを確認してください。」

5

このロケーションでユーザーがボイスメールをチェックするために呼び出せる [ボイスメール番号] を選択します。

6

(オプション) ロケーション ページの上部にある鉛筆アイコンをクリックし、必要に応じて [ロケーションの名前]、[アナウンス言語]、[メール言語]、[タイムゾーン]、[住所] を変更し、[保存] をクリックします。

[アナウンス言語] の変更は、このロケーションに追加された新規ユーザーや機能に対して直ちに有効になります。既存のユーザーや機能のアナウンス言語も変更する必要がある場合は、プロンプトが表示されたら、[既存のユーザーとワークスペースの変更] または [既存機能の変更] を選択します。[適用] をクリックします。[タスク] ページで進捗状況を確認できます。これが完了するまでは、これ以上変更を加えることはできません。

ロケーションの [タイム ゾーン] を変更しても、このロケーションに関連する機能のタイム ゾーンは更新されません。自動アテンダント、ハント グループ、コール キューなどの機能のタイム ゾーンを編集するには、タイムゾーンを更新する特定の機能の [全般設定] エリアに移動し、そこで編集して保存します。

これらの設定は社内ダイヤルに適用されるものであり、最初のセットアップ ウィザードでも設定できます。ダイヤル プランを変更すると、Control Hub の更新でこれらの変更を示す例番号が表示されます。

ロケーションに対する発信通話の権限を設定できます。これらのステップをご覧になり、発信権限を設定してください。

1

Control Hub にサインインし、[サービス ] > [通話 ] > [サービス設定] の順に移動し、[内部ダイヤル] までスクロールします。

2

必要に応じて、次のオプションのダイヤル設定を行います。

  • ロケーション ルーティング プレフィックスの長さ: 複数のロケーションがある場合は、この設定をお勧めします。2 ～ 7 桁の長さを入力できます。同じ内線番号を持つ複数のロケーションがある場合、ロケーション間でコールを行うときに、ユーザーはプレフィックスをダイヤルする必要があります。たとえば、複数のストアがある場合、内線 1000 を使用すると、各ストアにルーティング プレフィックスを設定することができます。1 つのストアのプレフィックスが 888 の場合、そのストアに到達するために 8881000 にダイヤルします。

    ルーティング プレフィックスの長さには、ステアリング番号が含まれます。たとえば、ルーティング プレフィックスの長さを 4 に設定すると、3 桁のみを使用してサイトを指定できます。

    ルーティング プレフィックスをロケーションに割り当てる場合、そのロケーションに割り当てられた内線のすべての外観には、内線番号の前にルーティング プレフィックスが含まれます。たとえば、888-1000（ルーティング プレフィックス-内線）です。

  • [ルーティング プレフィックスのステアリング番号（Steering Digit in Routing Prefix）]:すべてのルーティング プレフィックスの最初の桁として設定される番号を選択します。
  • [内線番号の長さ(Internal Extension Length)]:2 ～ 10 桁を入力でき、デフォルトは 2 です。

    内線の長さを長くすると、既存の内部内線への短縮ダイヤルが自動的に更新されることはありません。

  • ロケーション間の内線ダイヤルを許可—組織の要件に基づいて、ロケーション間の内線ダイヤルをカスタマイズできます。

    • 組織にすべてのロケーションで重複する内線がない場合は、トグルを有効にします。

      デフォルトでは、トグルが有効になっています。

    • 組織が別の場所に同じ内線を持っている場合は、トグルを無効にします。トグルが無効になり、発信者が内線番号をダイヤルすると、通話は、発信者と同じロケーションで内線番号が一致するユーザーにルーティングされます。発信者は、エンタープライズ重要番号（ロケーションルーティングプレフィックス + 内線）をダイヤルして、他のロケーションの内線番号に到達する必要があります。

3

特定の場所の内部ダイヤルを指定します。［管理 ］>［ロケーション］の順に移動し、リストからロケーションを選択し、［通話］をクリックします。[ダイヤル] までスクロールし、必要に応じて内部ダイヤルを変更します。

  • 内線ダイヤル: このロケーションの誰かに連絡するために、他のロケーションのユーザーがダイヤルする必要があるルーティング プレフィックスを指定します。各ロケーションのルーティング プレフィックスは固有である必要があります。プレフィックスの長さは組織レベルで設定された長さに一致することを推奨しますが、長さは 2 ～ 7 桁でなければなりません。
4

特定のロケーションの外部ダイヤルを指定します。［管理 ］>［ロケーション］の順に移動し、リストからロケーションを選択し、［通話］をクリックします。[ダイヤル] までスクロールし、必要に応じて外部ダイヤルを変更します。

  • 外部ダイヤル:外線に到達するためにユーザがダイヤルする必要がある発信ダイヤル番号を選択できます。デフォルトは [なし] であり、このダイヤル習慣が必要ない場合には、値を [なし] にしておくことができます。この機能を使用しない場合、組織のステアリング番号とは別の番号を使用することをお勧めします。

    ユーザーは、外線発信を行う際に外線発信番号を含め、レガシー システムでダイヤルしていた方法を真似たものにできます。しかし、すべてのユーザーは、発信ダイアル番号なしで外部通話を発信することができます。

  • 必要に応じて、このロケーションの発信ダイヤル番号のダイヤルを強制す ることができます。これにより、ユーザーは外部コールを発信するために管理者が設定した発信ダイヤル番号を使用する必要があります。

    この機能が有効になっている場合でも、緊急コールは発信ダイヤル番号の有無にかかわらずダイヤルできます。

    有効にすると、発信ダイヤル番号が含まれていない場合、コール転送に使用されるような外部接続先番号は機能しなくなります。

    内線が国番号と同じ場合、内線が国番号よりも優先されます。したがって、発信ダイヤル番号を有効にすることをお勧めします。
    着信および発信 PSTN コールに E.164 番号形式を使用することを強くお勧めします。

ユーザーへの影響:

  • ダイヤル設定の変更を有効にするには、電話機を再起動する必要があります。

  • ユーザーの内線番号はロケーションのステアリング番号または発信ダイヤル番号と同じ番号で始まるべきではありません。

Control Hub でプレミス ベースの PSTN (ローカル ゲートウェイ) を設定する

付加価値再販業者の場合、これらの手順を使用して Control Hub でローカル ゲートウェイの設定を開始できます。このゲートウェイがクラウドに登録されると、Webex Calling の 1 つ以上のロケーションで使用して、エンタープライズ PSTN サービス プロバイダーへのルーティングを提供できます。

ローカル ゲートウェイがある場所は、ローカル ゲートウェイが他の場所で使用されているときには削除できません。

トランクを作成する
次の手順に従って、Control Hub でトランクを作成します。

始める前に

  • ロケーションが追加されたら、ロケーションに対してプレミスベース PSTN を設定する前に、トランクを作成する必要があります。

  • それぞれについて、ロケーションと固有の設定および番号を作成します。ロケーションはプレミスベース PSTN を追加する前に存在する必要があります。

  • Webex Calling でのプレミスベース PSTN (ローカル ゲートウェイ) 要件について理解しておいてください。

  • プレミスベース PSTN を持つロケーションに対して、複数のトランクを選択できませんが、複数のロケーションに対して同じトランクを選択することはできます。

1

https://admin.webex.comでControl Hubにログインし、［サービス ］>［通話 ］>［通話ルーティング］の順に移動し、［トランクの追加］を選択します。

2

ロケーションを選択します。

3

トランクの名前を指定し、[保存] をクリックします。

名前は 24 文字以内にしてください。

次にやる必要

トランクで設定する必要がある、関連するパラメーターが表示されます。また、PSTN 接続をセキュアにするための SIP ダイジェスト資格情報のセットも生成します。

画面 [ドメインの登録]、[トランク グループ 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 の有料通話サービスを使用しないユーザーのための混合モード展開など、通話クライアント設定を構成できます。詳細については、次を参照してください。通話動作をセットアップします。

Cisco IOS XE で Webex Calling のローカル ゲートウェイを構成する

概要

Webex Calling は現在、ローカル ゲートウェイの 2 つのバージョンをサポートしています。

  • ローカルゲートウェイ

  • 政府版 Webex のローカル ゲートウェイ

主な考慮事項

  • 開始する前に、Webex Calling のプレミスベースの公衆交換電話ネットワーク (PSTN) およびローカル ゲートウェイ (LGW) の要件を理解してください。詳細については 、「設定されたアーキテクチャ」Webex Calling を参照してください。

  • この記事では、専用のローカル ゲートウェイ プラットフォームが配置されているが、既存の音声構成がないと仮定しています。既存の PSTN ゲートウェイまたは CUBE エンタープライズ展開を Webex Calling のローカル ゲートウェイ機能として使用するように変更する場合は、設定に注意してください。変更を行ったため、既存の通話フローと機能を中断しないようにしてください。

この手順には、個々のコマンド オプションについての詳細を学ぶことができるコマンド リファレンス ドキュメントへのリンクが含まれています。特に指定のない限り、すべてのコマンド リファレンス リンクは Webex 管理対象ゲートウェイ コマンド リファレン ス に移動します (この場合、コマンド リンクは Cisco IOS 音声コマンド リファレンス に移動します)。これらのガイドはすべて、Cisco Unified Border Element コマンド リファレンスからアクセスできます。

サポートされているサードパーティ 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 の 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 メッセージの処理を提供し、必要なターゲットにルーティングします。

PSTN から Webex Calling 構成ソリューションへのコール ルーティング

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 インターフェイスに割り当てます。

 インターフェイス GigabitEthernet0/0/0 説明 PSTN および/または CUCM の ip アドレスに面しているインターフェイス 10.80.13.12 255.255.255.0 ! インターフェイス GigabitEthernet0/0/1 説明 Webex Calling (プライベート アドレス) ip アドレスに面しているインターフェイス 192.51.100.1 255.255.240

2

対称暗号化を使用して、ルータ上の登録と STUN クレデンシャルを保護します。プライマリ暗号化キーと暗号化タイプを次のように設定します。

 key config-key password-encrypt YourPassword パスワード暗号化 aes

3

プレースホルダー PKI トラストポイントを作成します。

後で TLS を設定するには、このトラストポイントが必要です。登録ベースのトランクの場合、このトラストポイントは証明書を必要としません。証明書ベースのトランクでも必須です。
 暗号 pki trustpoint EmptyTP 失効チェック なし
4

TLS1.2 排他を有効にし、次の設定コマンドを使用してデフォルトのトラストポイントを指定します。登録のための信頼性の高い安全な接続を確保するために、トランスポートパラメータも更新する必要があります。

cn-san-validate server コマンドは、テナント 200 で設定されたホスト名がアウトバウンド プロキシから受信した証明書の CN または SAN フィールドに含まれている場合に、ローカル ゲートウェイが接続を許可することを保証します。

  1. tcp-retry count を 1000 に設定します (5-msec multiples = 5 秒)。

  2. タイマー接続を確立する コマンドを使用すると、次に使用可能なオプションを考慮する前に、LGW がプロキシとの接続をセットアップするのを待つ時間を調整できます。このタイマーのデフォルトは 20 秒で、最低 5 秒です。低値で開始し、ネットワーク条件に対応するために必要な場合は増加します。

 sip-ua タイマー接続を確立します tls 5 トランスポート tcp tls v1.2 暗号シグナリング デフォルト トラストポイント EmptyTP cn-san-validate server tcp-retry 1000

5

Webex Calling で使用される DigiCert CA 証明書を含む Cisco ルート CA バンドルをインストールします。crypto pki trustpool import clean url コマンドを使用して、指定された URL からルート CA バンドルをダウンロードし、現在の CA トラストプールをクリアし、証明書の新しいバンドルをインストールします。

HTTPS を使用してインターネットにアクセスするためにプロキシを使用する必要がある場合は、CA バンドルをインポートする前に、次の設定を追加します。

ip httpクライアントプロキシサーバーyourproxy.comプロキシポート80
 ip http クライアント ソースインターフェイス GigabitEthernet0/0/1 暗号 pki trustpool インポート クリーン URL https://www.cisco.com/security/pki/trs/ios_core.p7b
Webex Calling 登録ベースのトランクの設定
1

Control Hub の既存のロケーションに登録ベースの PSTN トランクを作成します。トランクが作成されると、提供されたトランク情報をメモします。次の図で強調表示されているこれらの詳細は、このガイドの設定手順で使用されます。詳細については、「Webex Calling のトランク、ルート グループ、ダイヤル プランの設定」を参照してください。

2

次のコマンドを入力して、CUBE を Webex Calling ローカル ゲートウェイとして設定します。

 音声サービス voip ip address trusted list ipv4 x.x.x.x y.y.y モード border-element media statistics media bulk-stats allow-connections sip to sip supplementary-service sip refer stun stun flowdata agent-id 1 boot-count 4 stun flowdata shared-secret 0 パスワード123$ sip asymmetric payload full early-offer forced

以下は、設定のフィールドの説明です。

 ip アドレスの信頼リスト  ipv4 x.x.x.x y.y.y

  • トール詐欺から保護するために、信頼されたアドレス リストは、ローカル ゲートウェイが正当な VoIP コールを期待するホストとネットワークのリストを定義します。

  • デフォルトでは、ローカル ゲートウェイは、信頼されたリストに含まれていない IP アドレスからのすべての着信 VoIP メッセージをブロックします。「セッション ターゲット IP」またはサーバ グループ IP アドレスを持つ静的に設定されたダイヤル ピアはデフォルトで信頼されるため、信頼されたリストに追加する必要はありません。

  • ローカル ゲートウェイを設定するときは、地域の Webex Calling データ センターの IP サブネットをリストに追加します。詳細については、「Webex Calling のポート参照情報」を参照してください。また、Unified Communications Manager サーバ（使用されている場合）および PSTN トランク ゲートウェイのアドレス範囲を追加します。

    LGW が制限付きコーン NAT のあるファイアウォールの背後にある場合は、Webex Calling に面したインターフェイスの IP アドレスの信頼リストを無効にすることをおすすめします。ファイアウォールはすでに、未承諾のインバウンドメッセージから保護VoIP。[無効にする] アクションは、Webex Calling ピアのアドレスが固定されたままである保証を保証できないので、長期構成のオーバーヘッドを削減します。また、いかなる場合にも、ピアに対してファイアウォールを構成する必要があります。

モード ボーダー要素

プラットフォームで Cisco Unified Border Element（CUBE）機能を有効にします。

メディア統計

ローカル ゲートウェイ上のメディア監視が可能です。

メディア一括統計

一括通話統計のために、コントロール飛行機がデータ 飛行機をポーリングできます。

これらのコマンドの詳細については、「メディア」を参照してください。

allow-connections sip to sip

CUBE 基本 SIP バックツーバック ユーザ エージェント機能を有効にします。詳細については、「接続を許可」を参照してください。

デフォルトでは、T.38 ファックス転送が有効になっています。詳細については、ファックスプロトコルt38 (音声サービス)を参照してください。

スタイン

STUN (NAT を介した UDP のセッショントラバーサル) をグローバルに有効にします。

  • 通話を Webex Calling ユーザーに転送する場合 ( 例えば、通話側と通話側の両当事者が Webex Calling のサブスクライバーであり、Webex Calling SBC にメディアを固定する場合)、メディアはピンホールが開いていないので、ローカル ゲートウェイにフローできません。

  • ローカル ゲートウェイの STUN バインディング機能により、ネゴシエートされたメディア パス上でローカルに生成された STUN 要求を送信できます。これは、ファイアウォールのピンホールを開くのに役立ちます。

詳細については、「stun flowdata agent-i d」および「stun flowdata shared-secret」を参照してください。

非対称ペイロード フル

DTMF と動的コーデック ペイロードの両方に対して SIP 非対称ペイロード サポートを設定します。このコマンドの詳細については、非対称ペイロードを参照してください。

early-offer forced

ローカル ゲートウェイは、隣接するピアからの確認を待つ代わりに、最初の INVITE メッセージで SDP 情報を送信するように強制します。このコマンドの詳細については、早期提供を参照してください。

3

トランクの音声クラス コーデック 100 フィルタを設定します。この例では、すべてのトランクに同じコーデックフィルタが使用されます。正確な制御のために各トランクにフィルタを設定できます。

 音声クラス コーデック 100 コーデックの設定 1 opus コーデックの設定 2 g711ulaw コーデックの設定 3 g711alaw

以下は、設定のフィールドの説明です。

音声クラス コーデック 100

SIP トランクを介したコールの優先コーデックのみを許可するために使用されます。詳細については、「音声クラスコーデック」を参照してください。

Opus コーデックは、SIP ベースの PSTN トランクでのみサポートされています。PSTN トランクが音声 T1/E1 またはアナログ FXO 接続を使用する場合、コーデックの基本設定 1 opus を 音声クラス コーデック 100 構成から除外します。

4

音声クラス stun-usage 100 を設定して、Webex Calling トランクで ICE を有効にします。

 音声クラス stun-usage 100 stun-usage firewall-traversal flowdata stun-usage ice lite

以下は、設定のフィールドの説明です。

スタンの使用法 アイス ライト

すべての 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 100 暗号 1 AES_CM_128_HMAC_SHA1_80

以下は、設定のフィールドの説明です。

音声クラス srtp-crypto 100

SDP の SRTP 暗号スイート CUBE オファーおよび応答メッセージの唯一の SRTP オファーとして SHA1_80 を指定します。Webex Calling は SHA1_80 のみをサポートします。詳細については、音声クラス srtp-crypto を参照してください。

6

宛先トランク パラメータに基づいて、ローカル ゲートウェイ トランクへのコールを一意に識別するパターンを設定します。 

 音声クラス uri 100 sip パターン dtg=Dallas1463285401_LGU

以下は、設定のフィールドの説明です。

音声クラス uri 100 sip

着信トランク ダイヤル ピアへの着信 SIP 招待と一致するパターンを定義します。このパターンを入力する場合、トランクが作成されたときに、dtg= の後に Control Hub で提供されるトランク OTG/DTG 値を使用します。詳細については、音声クラス uri を参照してください。

7

sip プロファイル 100 を構成します。これは、Webex Calling に送信される SIP メッセージを変更するために使用されます。

 voice class sip-profiles 100 rule 10 request ANY sip-header SIP-Req-URI change "sip:" "sip:" rule 20 request ANY sip-header ANY sip-header To modify "" "" ";otg=dallas1463285401_lgu>" rule 90 request ANY sip-header P-Asserted-Identity modify "sips:" "sip:"

以下は、設定のフィールドの説明です。

  • ルール10～70、90

    コール シグナリングに使用される SIP ヘッダーが、Webex プロキシによって要求される sips スキームではなく sip を使用することを確認します。sips を使用するように CUBE を設定すると、セキュアな登録が使用されます。

  • ルール80

    From ヘッダーを変更して、トランク グループの OTG/DTG 識別子を Control Hub から含め、企業内のローカル ゲートウェイ サイトを一意に識別します。

8

Webex Calling トランクの設定:

  1. 音声クラス テナント 100 を作成して、Webex Calling トランクに特別に必要な設定を定義し、グループ化します。特に、以前の Control Hub で提供されるトランク登録の詳細は、以下の手順で使用されます。このテナントに関連付けられているダイヤルピアは、後でこれらの設定を継承します。

    次の例では、このガイドの目的のために、ステップ 1 に示されている値を使用します (太字で表示)。これらを構成のトランクの値に置き換えます。

     音声クラス テナント 100 レジストラの dns:98027369.us10.bcld.webex.com スキーム sips の有効期限が 240 更新比 50 tcp tls 資格情報番号 Dallas1171197921_LGU ユーザー名 Dallas1463285401_LGU パスワード 0 9Wt[M6ifY+ realm BroadWorks 認証ユーザー名 Dallas1463285401_LGU パスワード 0 9Wt[M6ifY+ realm BroadWorks 認証ユーザー名 Dallas1463285401_LGU パスワード 0 9Wt[M6ifY+ realm 98027369.us10.bcld.webex.com remote-party-id sip-server dns なし:98027369.us10.bcld.webex.com connection-reuse srtp-crypto 100 session transport tcp tls url sips error-passthru asserted-id pai bind control source-interface GigabitEthernet0/0/1 bind media source-interface GigabitEthernet0/0/1 no pass-thru content custom-sdp sip-profiles 100 outbound-proxy dns:dfw04.sipconnect-us.bcld.webex.com プライバシー ポリシー passthru

    以下は、設定のフィールドの説明です。

    音声クラス テナント 100

    Webex Calling トランクにのみ使用される一連の設定パラメータを定義します。詳細については、「音声クラス テナント」を参照してください。

    登録者 dns:98027369.us10.bcld.webex.com スキーム sips 有効期限 240 更新比 50 tcp tls

    ローカル ゲートウェイの登録サーバーで、2 分ごとに更新が設定されている場合 (240 秒の 50%)。詳細については、レジストラを参照してください。

    ここで Control Hub から [ドメインの登録] 値を使用していることを確認します。

    資格情報番号 Dallas1171197921_LGU ユーザー名 Dallas1463285401_LGU パスワード 0 9Wt[M6ifY+ realm BroadWorks

    トランク登録認証の資格情報。詳細については、資格情報（SIP UA）を参照してください。

    ここで、Control Hub からそれぞれ回線/ポートホスト、認証ユーザ名、認証パスワードの値を使用していることを確認します。

    認証ユーザー名 Dallas1171197921_LGU パスワード 0 9Wt[M6ifY+ realm BroadWorks
    認証ユーザー名 Dallas1171197921_LGU パスワード 0 9Wt[M6ifY+ realm 98027369.us10.bcld.webex.com

    コールの認証の課題。詳細については、認証（ダイヤルピア）を参照してください。

    ここで、Control Hub からそれぞれ認証ユーザ名、認証パスワード、およびレジストラドメインの値を使用していることを確認してください。

    no remote-party-id

    Webex Calling が PAI をサポートしているため、SIP Remote-Party-ID (RPID) ヘッダーを無効にします。これは、CIO asserted-id pai を使用して有効になります。詳細については、「remote-party-id」を参照してください。

    sip-server dns:us25.sipconnect.bcld.webex.com

    トランクのターゲット SIP サーバを設定します。トランクを作成するときは、Control Hub で提供されるエッジ プロキシ SRV アドレスを使用します。

    connection-reuse

    登録と通話処理に同じ永続的な接続を使用します。詳細については、「connection-reuse」を参照してください。

    srtp-crypto 100

    SRTP コール レッグ（接続）の優先暗号スイートを設定します（手順で指定）5). 詳細については、音声クラス srtp-crypto を参照してください。

    session transport tcp tls

    TLS へのトランスポートを設定します。詳細については、「session-transport」を参照してください。

    url sips

    SRVは、アクセス SBC によりサポートされている SIP である必要があります。その他のすべてのメッセージは、sip-profile 200 により SIP に変更されます。

    error-passthru

    SIP エラー応答パススルー機能を指定します。詳細については、error-passthruを参照してください。

    asserted-id pai

    ローカル ゲートウェイで簡単に処理をオンにする。詳細については、asserted-idを参照してください。

    bind control source-interface GigabitEthernet0/0/1

    WebexCalling に送信されるメッセージのソース インターフェイスと関連する IP アドレスを設定します。詳細は、bindを参照してください。

    bind media source-interface GigabitEthernet0/0/1

    WebexCalling に送信されるメディアのソース インターフェイスおよび関連する IP アドレスを設定します。詳細は、bindを参照してください。

    no pass-thru content custom-sdp

    テナントの下のデフォルト コマンド。このコマンドの詳細については、パススルー コンテンツを参照してください。

    sip プロファイル 100

    sip-profile 100 で定義されているように、SIP を SIP に変更し、INVITE および REGISTER メッセージの回線/ポートを変更します。詳細については、「音声クラス sip プロファイル」を参照してください。

    outbound-proxy dns:dfw04.sipconnect-us.bcld.webex.com

    Webex Calling SBC にアクセスします。トランクを作成したときに、Control Hub で提供されるアウトバウンド プロキシ アドレスを挿入します。詳細については、「outbound-proxy」を参照してください。

    privacy-policy passthru

    トランクのプライバシー ヘッダー ポリシー オプションを設定して、受信したメッセージから次のコール レッグにプライバシーの値を渡します。詳細については、プライバシーポリシーを参照してください。

  2. Webex Calling トランク ダイヤル ピアを設定します。 

     ダイヤルピア ボイス 100 voip の説明 着信/発信 Webex Calling max-conn 250 宛先パターン bad.bad セッションプロトコル sipv2 session target sip-server inbound uri request 100 voice-class codec 100 dtmf-relay rtp-nte voice-class stun-usage 100 no voice-class sip localhost voice-class sip tenant 100 srtp no vad

    以下は、設定のフィールドの説明です。

     ダイヤルピア ボイス 100 voip  の説明 着信/発信 Webex Calling

    100 VoIP ダイヤルピアを定義し、管理とトラブルシューティングを容易にするための意味のある説明を行います。

    max-conn 250

    LGW と Webex Calling の間の同時着信コールと発信コールの数を制限します。登録トランクの場合、設定されている最大値は 250 である必要があります。Usea は、展開に適している場合は値を下げます。ローカル ゲートウェイの同時通話制限の詳細については、「ローカル ゲートウェイを使い始め る」のドキュメントを参照してください。

    destination-pattern BAD.BAD

    着信ダイヤル ピア グループを使用して発信コールをルーティングする場合は、ダミー接続先パターンが必要です。この場合、有効な宛先パターンを使用できます。

    session protocol sipv2

    ダイヤルピア 100 が SIP コール のコールコールを処理する場合に指定します。詳細については、セッションプロトコル（ダイヤルピア）を参照してください。

    session target sip-server

    テナント 100 で定義された SIP サーバが継承され、このダイヤル ピアからのコールの宛先に使用されることを示します。

    着信 uri リクエスト 100

    VoIP ダイヤル ピアと着信コールのユニフォーム リソース 識別子（URI）を一致させるために使用される音声クラスを指定します。詳細については、着信 uri を参照してください。

    音声クラス コーデック 100

    共通のコーデック フィルタ リスト 100 を使用するようにダイヤル ピアを設定します。詳細については、音声クラスコーデックを参照してください。

    音声クラスstun使用 100

    ローカル ゲートウェイでローカルに生成された STUN 要求を、ネゴシエートされたメディア パス経由で送信できるようにします。STUN は、メディア トラフィックのファイアウォールのピンホールを開くのに役立ちます。

    no voice-class sip localhost

    送信メッセージの物理的 IP アドレスの代用として、From、Call-ID、Remote-Party-ID ヘッダーの DNS ローカル ホスト名の代入を無効にします。

    voice-class SIP テナント 100

    ダイヤル ピアは、グローバルおよびテナント 100 で設定されたすべてのパラメータを継承します。パラメータはダイヤル ピア レベルで上書きされる場合があります。

    srtp

    コールレグの SRTP を有効にする。

    no vad

    音声アクティブティの検出を無効にします。

テナント 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を受信すると、登録が成功します。

SIP PSTN トランクを使用したローカル ゲートウェイの設定

上記の 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 ホスト ipv4:192.168.80.13

以下は、設定のフィールドの説明です。

音声クラス uri 200 sip

着信トランク ダイヤル ピアへの着信 SIP 招待と一致するパターンを定義します。このパターンを入力するときは、IP PSTN ゲートウェイの IP アドレスを使用します。詳細については、音声クラス uri を参照してください。

2

次の IP PSTN ダイヤル ピアを設定します。

 ダイヤルピア ボイス 200 voip 説明 インバウンド/アウトバウンド IP PSTN トランクの宛先パターン BAD.BAD セッション プロトコル sipv2 セッション ターゲット ipv4:192.168.80.13 200 voice-class sip bind control source-interface GigabitEthernet0/0/0 voice-class sip bind media source-interface GigabitEthernet0/0/0 voice-class codec 100 dtmf-relay rtp-nte no vad

以下は、設定のフィールドの説明です。

 ダイヤルピア ボイス 200 voip  の説明 着信/発信 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 経由の着信 uri

VIA ヘッダーの判断基準を IP ヘッダーと IP アドレスPSTNを定義します。ローカル ゲートウェイのすべての着信 IP PSTN コール レッグとダイヤル ピア 200 を一致させます。詳細については、着信 URLを参照してください。

バインド制御ソースインタフェース GigabitEthernet0/0/0

PSTN に送信されるメッセージのソース インターフェイスと関連する IP アドレスを設定します。詳細は、bindを参照してください。

バインド メディア ソース インターフェイス GigabitEthernet0/0/0

PSTN に送信されるメディアのソース インターフェイスおよび関連する 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 プラットフォームを使用してローカル ゲートウェイを設定する場合は、次のセクションに進みます。

  1. ダイヤルピア グループを作成して、Webex Calling または PSTN にコールをルーティングします。Webex Calling に向けて発信ダイヤルピア 100 で DPG 100 を定義します。DPG 100 は、PSTN からの着信ダイヤルピアに適用されます。同様に、PSTN に向かって発信ダイヤルピア 200 で DPG 200 を定義します。DPG 200 は、Webex からの着信ダイヤルピアに適用されます。

     音声クラス dpg 100 の説明 Webex Calling のダイヤルピア 100 音声クラス dpg 200 の説明 コールを PSTN ダイヤルピア 200 にルーティングする

    以下は、設定のフィールドの説明です。

    ダイヤルピア 100

    発信ダイヤルピアとダイヤルピア グループを関連付けます。詳細は、音声クラス dpgを参照してください。

  2. ダイヤルピア グループを適用して、Webex から PSTN に、および PSTN から Webex にコールをルーティングします。 

     ダイヤルピア ボイス 100 宛先 dpg 200 ダイヤルピア ボイス 200 宛先 dpg 100

    以下は、設定のフィールドの説明です。

    destination dpg 200

    どのダイヤル ピア グループを指定します。したがって、この着信ダイヤル ピアに提示されたコールの発信処理にダイヤル ピアを使用する必要があります。

    これでローカル ゲートウェイの設定は終了します。CUBE 機能が初めて設定される場合は、設定を保存し、プラットフォームをリロードします。

TDM PSTN トランクを使用したローカル ゲートウェイの設定

Webex Calling に向けてトランクを構築した後は、次の設定を使用して、Webex コール レッグのメディア最適化を可能にするために、ループ バック コール ルーティングを備えた PSTN サービスの TDM トランクを作成します。

IP メディア最適化を必要としない場合は、SIP PSTN トランクの設定手順に従います。PSTN VoIP ダイヤル ピアの代わりに、ボイス ポートと POTS ダイヤル ピア（手順 2 および 3 を参照）を使用します。
1

ループ バック ダイヤル ピア構成では、ダイヤル ピア グループとコール ルーティング タグを使用して、コール ルーティング ループを作成せずに、Webex と PSTN の間でコールが正しく渡されるようにします。コール ルーティング タグの追加と削除に使用する次のトランスレーション ルールを設定します。

 音声翻訳ルール 100 ルール 1 /^\+//A2A/ 音声翻訳プロファイル 100 呼び出された音声翻訳ルール 200 ルール 1 /^//A1A/ 音声翻訳プロファイル 200 呼び出された音声翻訳ルール 11 ルール 1 /^A1A/ // 音声翻訳プロファイル 11 呼び出された音声翻訳ルール 12 ルール 1 /^A2A44//0/ RULE 2/^A2A//00/ 音声翻訳プロファイル 12 呼び出された音声翻訳ルール 12

以下は、設定のフィールドの説明です。

音声翻訳ルール

ルールで定義された正規表現を使用して、コール ルーティング タグを追加または削除します。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 インターフェイスの基本設定には、次のものが含まれます。

 カードタイプ e1 0 2 つの isdn スイッチタイプ primary-net5 コントローラ E1 0/2/0 pri-group タイムスロット 1-31
3

次の TDM PSTN ダイヤル ピアを設定します。

 ダイヤルピア ボイス 200 ポット説明 着信/発信 PRI PSTN トランクの宛先パターン BAD.BAD translation-profile 着信 200 直通ダイヤルポート 0/2/0:15

以下は、設定のフィールドの説明です。 

 ダイヤルピアの音声 200 ポット  の説明 着信/発信 PRI 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 にルーティングされます。ルーティング タグを削除すると、コールはダイヤル ピア グループを使用して発信トランクにルーティングされます。

 dial-peer voice 10 voip description Outbound loop-around leg destination-pattern BAD.BAD session protocol sipv2 session target ipv4:192.168.80.14 voice-class sip bind control source-interface GigabitEthernet0/0/0 dtmf-relay rtp-nte codec g711alaw no vad dial-peer voice 11 voip description Webex translation-profile inbound 11 session protocol sipv2 incoming called-number A1AT voice-class sip bind control source-interface GigabitEthernet0/0/0 dtmf-relay rtp-nte codec g711alaw no vad dial-peer voice 12 voip description PSTN translation-profile incoming 12 session protocol sipv2 incoming called-number A2AT voice-class sip bind control source-interface GigabitEthernet0/0/0 dtmf-relay rtp-nte codec g711alaw no vad dial-peer voice 12 voip description PSTN translation-profile incoming 12 session protocol sipv2 incoming called-number A2AT voice-class sip bind control source-interface GigabitEthernet0/0/0 dtm

以下は、設定のフィールドの説明です。 

 ダイヤルピアの音声 10 ポット  の説明 アウトバウンドループバックレッグ

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

次のコール ルーティング設定を追加します。

  1. ダイヤルピア グループを作成して、ループバックを介して PSTN と Webex トランク間のコールをルーティングします。

     音声クラス dpg 100 の説明 Webex Calling のダイヤルピア 100 音声クラス dpg 200 の説明 コールを PSTN ダイヤルピア 200 の音声クラス dpg 10 の説明 通話をループバックダイヤルピア 10 にルーティングする

    以下は、設定のフィールドの説明です。

    ダイヤルピア 100

    発信ダイヤルピアとダイヤルピア グループを関連付けます。詳細は、音声クラス dpgを参照してください。

  2. ダイヤル ピア グループを適用してコールをルーティングします。

     ダイヤルピア ボイス 100 宛先 dpg 10 ダイヤルピア ボイス 200 宛先 dpg 10 ダイヤルピア ボイス 11 宛先 dpg 100 ダイヤルピア ボイス 12 宛先 dpg 200

    以下は、設定のフィールドの説明です。

    宛先 dpg 200

    どのダイヤル ピア グループを指定します。したがって、この着信ダイヤル ピアに提示されたコールの発信処理にダイヤル ピアを使用する必要があります。

これでローカル ゲートウェイの設定は終了します。CUBE 機能が初めて設定される場合は、設定を保存し、プラットフォームをリロードします。
ローカル ゲートウェイを既存の Unified CM 環境で構成する

前のセクションの 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 を設定:

  1. SIP VIA ポートを使用して Unified CM を Webex コールに分類します。

     voice class uri 300 sip
 pattern :5065

  2. ポート経由の SIP を使用して、Unified CM を PSTN コールに分類します。

     音声クラス uri 400 sip パターン 192\.168\.80\.6[0-5]:5060

    発信元のソース アドレスとポート番号を説明する 1 つ以上のパターンを使用して、UCM からの着信メッセージを PSTN トランクに分類します。必要に応じて、正規表現を使用して、一致するパターンを定義できます。

    上記の例では、192.168.80.60 から 65 までの範囲およびポート番号 5060 の任意の IP アドレスに一致させるために正規表現が使用されます。

2

次の DNS レコードを設定して、Unified CM ホストへの SRV ルーティングを指定します。

IOS XE は、これらのレコードをローカルでターゲット UCM ホストとポートを決定するために使用します。この設定では、DNS システムでレコードを設定する必要はありません。DNS を使用する場合は、これらのローカル設定は必要ありません。

 ip ホスト ucmpub.mydomain.com 192.168.80.60 ip ホスト ucmsub1.mydomain.com 192.168.80.61 ip ホスト ucmsub2.mydomain.com 192.168.80.62 ip ホスト ucmsub3.mydomain.com 192.168.80.63 ip ホスト ucmsub4.mydomain.com 192.168.80.64 ip ホスト ucmsub5.mydomain.com 192.168.80.65 ip ホスト _sip._udp.wxtocucm.io srv 0 1 5065 ucmpub.mydomain.com ip ホスト _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub1.mydomain.com ip ホスト _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub2.mydomain.com ip ホスト _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub3.mydomain.com ip ホスト _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub4.mydomain.com ip ホスト _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub5.mydomain.com ip ホスト _sip._udp.pstntocucm.io srv 0 1 5060 ucmpub.mydomain.com ip ホスト _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub1.mydomain.com ip ホスト _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub2.mydomain.com ip ホスト _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub3.mydomain.com ip ホスト _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub4.mydomain.com ip ホスト _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub5.mydomain.com

以下は、設定のフィールドの説明です。

次のコマンドは、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

次のダイヤルピアを設定します。

  1. Unified CM と Webex Calling 間のコールのダイヤルピア:

     ダイヤルピア ボイス 300 voip の説明 UCM-Webex Calling トランクの宛先パターン BAD.BAD セッション プロトコル sipv2 セッション target dns:wxtocucm.io 着信 uri via 300 voice-class codec 100 voice-class sip bind control source-interface ギガビットイーサネット 0/0/0 voice-class sip bind media source-interface ギガビットイーサネット 0/0/0 dtmf-relay rtp-nte no vad

    以下は、設定のフィールドの説明です。

     ダイヤルピア ボイス 300 voip  の説明 UCM-Webex Calling トランク

    タグ 30 0 を使用して VoIP ダイヤルピアを定義し、管理とトラブルシューティングを容易にするための意味のある説明を提供します。

    destination-pattern BAD.BAD

    着信ダイヤル ピア グループを使用して発信コールをルーティングする場合は、ダミー接続先パターンが必要です。この場合、有効な宛先パターンを使用できます。

    session protocol sipv2

    ダイヤルピア 300 が SIP コール レッグを処理するように指定します。詳細については、セッションプロトコル（ダイヤルピア）を参照してください。

    セッション ターゲット dns:wxtocucm.io

    DNS SRV 解決を通じて複数の Unified CM ノードのセッション ターゲットを定義します。この場合、ローカルで定義された SRV レコード wxtocucm.io がコールをダイレクトするために使用されます。

    incoming uri via 300

    音声クラス URI 300 を使用して、ソース ポート 5065 を使用して Unified CM からのすべての着信トラフィックをこのダイヤル ピアにダイレクトします。詳細については、着信 uri を参照してください。

    音声クラス コーデック 100

    Unified CM との間のコールのコーデック フィルタ リストを示します。詳細については、「音声クラスコーデック」を参照してください。

    バインド制御ソースインタフェース GigabitEthernet0/0/0

    PSTN に送信されるメッセージのソース インターフェイスと関連する IP アドレスを設定します。詳細は、bindを参照してください。

    バインド メディア ソース インターフェイス GigabitEthernet0/0/0

    PSTN に送信されるメディアのソース インターフェイスおよび関連する IP アドレスを設定します。詳細は、bindを参照してください。

    dtmf-relay rtp-nte

    通話レグで予想される DTMF 機能として RTP-NTE (RFC2833) を定義します。詳細については、「DTMF Relay (Voice over IP)」を参照してください。

    no vad

    音声アクティブティの検出を無効にします。詳細については、vad（ダイヤルピア）を参照してください。

  2. Unified CM と PSTN 間のコールのダイヤルピア:

     ダイヤルピア ボイス 400 voip の説明 UCM-PSTN トランクの宛先パターン BAD.BAD セッション プロトコル sipv2 セッション target dns:pstntocucm.io 着信 uri via 400 voice-class codec 100 voice-class sip bind control source-interface ギガビットイーサネット 0/0/0 voice-class sip bind media source-interface ギガビットイーサネット 0/0/0 dtmf-relay rtp-nte no vad

    以下は、設定のフィールドの説明です。

     ダイヤルピア ボイス 400 voip  の説明 UCM-PSTN トランク

    400のタグ を含むVoIPダイヤルピアを定義し、管理とトラブルシューティングを容易にするための意味のある説明を提供します。

    destination-pattern BAD.BAD

    着信ダイヤル ピア グループを使用して発信コールをルーティングする場合は、ダミー接続先パターンが必要です。この場合、有効な宛先パターンを使用できます。

    session protocol sipv2

    ダイヤルピア 400 が SIP コール レッグを処理するように指定します。詳細については、セッションプロトコル（ダイヤルピア）を参照してください。

    セッション ターゲット dns:pstntocucm.io

    DNS SRV 解決を通じて複数の Unified CM ノードのセッション ターゲットを定義します。この場合、ローカルで定義された SRV レコード pstntocucm.io がコールをダイレクトするために使用されます。

    400 経由の着信 uri

    音声クラス URI 400 を使用して、ソース ポート 5060 を使用して指定された Unified CM ホストからのすべての着信トラフィックをこのダイヤル ピアに転送します。詳細については、着信 uri を参照してください。

    音声クラス コーデック 100

    Unified CM との間のコールのコーデック フィルタ リストを示します。詳細については、「音声クラスコーデック」を参照してください。

    バインド制御ソースインタフェース GigabitEthernet0/0/0

    PSTN に送信されるメッセージのソース インターフェイスと関連する IP アドレスを設定します。詳細は、bindを参照してください。

    バインド メディア ソース インターフェイス GigabitEthernet0/0/0

    PSTN に送信されるメディアのソース インターフェイスおよび関連する IP アドレスを設定します。詳細は、bindを参照してください。

    dtmf-relay rtp-nte

    通話レグで予想される DTMF 機能として RTP-NTE (RFC2833) を定義します。詳細については、「DTMF Relay (Voice over IP)」を参照してください。

    no vad

    音声アクティブティの検出を無効にします。詳細については、vad（ダイヤルピア）を参照してください。

4

次の設定を使用してコール ルーティングを追加します。

  1. Unified CM と Webex Calling の間で通話をルーティングするダイヤル ピア グループを作成します。DPG 100 を 発信ダイヤルピア 100 で Webex Calling に対して定義します。DPG 100 は、Unified CM から関連付けられた着信ダイヤルピアに適用されます。同様に、Unified CM に向かって発信ダイヤルピア 300 で DPG 300 を定義します。DPG 300 は、Webex からの着信ダイヤルピアに適用されます。

     音声クラス dpg 100 の説明 Webex Calling のダイヤルピア 100 音声クラス dpg 300 の説明 コールを Unified CM にルーティング Webex Calling トランク ダイヤルピア 300 にルーティング

  2. Unified CM と PSTN の間でコールをルーティングするダイヤル ピア グループを作成します。PSTN に対して発信ダイヤルピア 200 で DPG 200 を定義します。DPG 200 は、Unified CM から関連付けられた着信ダイヤルピアに適用されます。同様に、Unified CM に向かって発信ダイヤルピア 400 で DPG 400 を定義します。DPG 400 は、PSTN からの着信ダイヤルピアに適用されます。

     音声クラス dpg 200 の説明 コールを PSTN ダイヤルピア 200 音声クラス dpg 400 の説明 コールを Unified CM PSTN トランクダイヤルピア 400 にルーティングする

    以下は、設定のフィールドの説明です。

    ダイヤルピア 100

    発信ダイヤルピアとダイヤルピア グループを関連付けます。詳細は、音声クラス dpgを参照してください。

  3. ダイヤルピア グループを適用して、Webex から Unified CM に、および Unified CM から Webex にコールをルーティングします。 

     ダイヤルピア ボイス 100 宛先 dpg 300 ダイヤルピア ボイス 300 宛先 dpg 100

    以下は、設定のフィールドの説明です。

    宛先 dpg 300

    どのダイヤル ピア グループを指定します。したがって、この着信ダイヤル ピアに提示されたコールの発信処理にダイヤル ピアを使用する必要があります。

  4. ダイヤルピア グループを適用して、PSTN から Unified CM に、Unified CM から PSTN にコールをルーティングします。

     ダイヤルピア ボイス 200 宛先 dpg 400 ダイヤルピア ボイス 400 宛先 dpg 200

    これでローカル ゲートウェイの設定は終了します。CUBE 機能が初めて設定される場合は、設定を保存し、プラットフォームを再読み込みします。

診断署名でローカル ゲートウェイを監視し、トラブルシューティングする

診断署名 (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 以降を実行しているローカル ゲートウェイ

  1. 診断署名はデフォルトで有効になっています。

  2. デバイスが Cisco IOS XE 17.6.1a 以降を実行している場合、プロアクティブな通知を送信するために使用する、セキュアな電子メールサーバを設定します。

    ターミナル call-home mail-server :@ 優先順位 1 セキュアな tls エンド

  3. 通知する管理者のメール アドレスで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 アカウント設定を行い、端末からメールを正しく処理するための権限を与える必要があります:

  1. [Google アカウントの管理] > [セキュリティ] に移動し、[安全性の低いアプリ アクセス] 設定をオンにします。

  2. 「はい、はい、それは私です」と答えます。Gmail から「Google は、Google 以外のアプリを使用してアカウントにサインインするユーザーを防ぎました」というメールを受け取ります。

プロアクティブ モニタリングのために診断署名をインストールする

CPU 使用率の監視

この DS は、SNMP OID を使用して 5 秒間 CPU 使用率を追跡します。1.3.6.1.4.1.9.2.1.56. 使用率が 75% 以上に達すると、すべてのデバッグを無効にし、ローカル ゲートウェイにインストールされている診断署名をアンインストールします。下記の手順を実行して署名をインストールします。

  1. 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: 有効

  2. Diagnostic Signatures Lookup Tool の以下のドロップダウンオプションを使用して、DS 64224 をダウンロードします。

    フィールド名

    フィールド値

    プラットフォーム

    Cisco 4300、4400 ISR シリーズまたは Cisco CSR 1000V シリーズ

    製品

    Webex Calling ソリューションの CUBE Enterprise

    問題の範囲

    パフォーマンス

    問題の種類

    通知メールによる CPU 使用率が高い

  3. 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 バイト

  4. ローカルゲートウェイに DS XML ファイルをインストールします。

    call-home diagnostic-signature load DS_64224.xml ロードファイル DS_64224.xml 成功

  5. 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 回の登録解除後に自動的にアンインストールされます。署名をインストールするには、以下の手順を使用します。

  1. Diagnostic Signatures Lookup Tool の以下のドロップダウンオプションを使用して、DS 64117 をダウンロードします。

    フィールド名

    フィールド値

    プラットフォーム

    Cisco 4300、4400 ISR シリーズ、または Cisco CSR 1000V シリーズ

    製品

    Webex Calling ソリューションの CUBE Enterprise

    問題の範囲

    SIP-SIP

    問題の種類

    SIP トランクによる登録解除を行いました。

  2. DS XML ファイルをローカルゲートウェイにコピーします。

    ftp://username:password@/DS_64117.xml bootflash:

  3. ローカルゲートウェイに DS XML ファイルをインストールします。 

    call-home diagnostic-signature load DS_64117.xml ロードファイル DS_64117.xml 成功 LocalGateway#

  4. show call-home diagnostic-signature コマンドを使用 して、署名が正常にインストールされたことを確認します。状態の列には「登録済み」の値が必要です。

異常な通話切断の監視

この DS は、10 分ごとに SNMP ポーリングを使用して、SIP エラーの 403、488、503 で異常な通話切断を検出します。 エラーカウントの増分が最後の投票から 5 以上である場合、syslog とメール通知が生成されます。 署名をインストールするには、以下の手順を使用してください。

  1. 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: 有効

  2. Diagnostic Signatures Lookup Tool の以下のオプションを使用して、DS 65221 をダウンロードします。

    フィールド名

    フィールド値

    プラットフォーム

    Cisco 4300、4400 ISR シリーズ、または Cisco CSR 1000V シリーズ

    製品

    Webex Calling ソリューションの CUBE Enterprise

    問題の範囲

    パフォーマンス

    問題の種類

    メールおよび Syslog 通知による SIP の異常通話切断検出

  3. DS XML ファイルをローカルゲートウェイにコピーします。 

    ftp://username:password@/DS_65221.xml bootflash:

  4. ローカルゲートウェイに DS XML ファイルをインストールします。 

    call-home diagnostic-signature load DS_65221.xml ロードファイル DS_65221.xml 成功

  5. 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 を使用して、以下の手順を使用して、診断データの収集を自動化します。

  1. 収集された診断データがアップロードされる 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"

  2. show snmp コマンドを使用して、SNMP が有効になっていることを確認します。有効になっていない場合は、snmp-server manager コマンドを設定します。

    show snmp %SNMP agent not enabled config t snmp-server manager end

  3. 高 CPU 使用率の期間中に、すべてのデバッグと診断署名を無効にするためのプロアクティブな措置として、高 CPU モニタリング DS 64224 をインストールしてください。Diagnostic Signatures Lookup Tool の以下のオプションを使用して、DS 64224 をダウンロードします。

    フィールド名

    フィールド値

    プラットフォーム

    Cisco 4300、4400 ISR シリーズ、または Cisco CSR 1000V シリーズ

    製品

    Webex Calling ソリューションの CUBE Enterprise

    問題の範囲

    パフォーマンス

    問題の種類

    通知メールによる CPU 使用率が高い

  4. 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

  5. DS XML ファイルをローカルゲートウェイにコピーします。

    ftp://username:password@/DS_64224.xml bootflash: ftp://username:password@/DS_65095.xml bootflash:

  6. ローカルゲートウェイに、高 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 成功

  7. 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 では現在、新しいカスタム署名の作成リクエストをサポートしていません。

Control Hub 経由で Cisco IOS XE ゲートウェイを管理および検証する

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 メッセージの処理を提供し、必要なターゲットにルーティングします。

PSTN から Webex Calling 構成ソリューションへのコール ルーティング

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 インターフェイスに割り当てます。

 インターフェイス GigabitEthernet0/0/0 説明 PSTN および/または CUCM の ip アドレスに面しているインターフェイス 192.168.80.14 255.255.255.0 ! インターフェイス GigabitEthernet0/0/1 の説明 Webex Calling (パブリック アドレス) ip アドレス 198.51.100.1 255.255.240 に面しているインターフェイス

2

対称暗号化を使用してルータの STUN クレデンシャルを保護します。プライマリ暗号化キーと暗号化タイプを次のように設定します。

 key config-key password-encrypt YourPassword パスワード暗号化 aes
3

希望する認証局 (CA) によって署名された証明書を使用して暗号化トラストポイントを作成します。

  1. 次の exec コマンドを使用して RSA キーペアを作成します。

    暗号キーの生成 rsa 汎鍵エクスポートラベル lgw-key modulus 4096

  2. トランクの fqdn として cube1.lgw.com を使用する場合、次の設定コマンドを使用して、署名済み証明書のトラストポイントを作成します。 

     crypto pki trustpoint LGW_CERT 登録ターミナル pem fqdn cube1.lgw.com subject-name cn=cube1.lgw.com subject-alt-name cube1.lgw.com revocation-check none rsakeypair lgw-key

  3. 次の exec または configuration コマンドを使用して証明書署名リクエスト（CSR）を生成し、サポートされている CA プロバイダーから署名済み証明書を要求するために使用します。

    暗号 pki 登録 LGW_CERT

4

中間（またはルート）CA 証明書を使用して新しい証明書を認証し、証明書をインポートします（ステップ 4）。次の exec または configuration コマンドを入力します。

 暗号 pki 認証 LGW_CERT

5

次の exec または configuration コマンドを使用して、署名済みホスト証明書をインポートします。

 暗号 pki インポート LGW_CERT 証明書

6

TLS1.2 排他を有効にし、次の設定コマンドを使用してデフォルトのトラストポイントを指定します。

 sip-ua 暗号シグナリングデフォルト トラストポイント LGW_CERT トランスポート tcp tls v1.2

7

Webex Calling で使用される DigiCert CA 証明書を含む Cisco ルート CA バンドルをインストールします。crypto pki trustpool import clean url コマンドを使用して、指定された URL からルート CA バンドルをダウンロードし、現在の CA トラストプールをクリアし、証明書の新しいバンドルをインストールします。

HTTPS を使用してインターネットにアクセスするためにプロキシを使用する必要がある場合は、CA バンドルをインポートする前に、次の設定を追加します。

ip httpクライアントプロキシサーバーyourproxy.comプロキシポート80
 ip http クライアント ソースインターフェイス GigabitEthernet0/0/1 暗号 pki trustpool インポート クリーン URL https://www.cisco.com/security/pki/trs/ios_core.p7b
Webex Calling 証明書ベースのトランクの設定
1

Control Hub の既存のロケーションの CUBE 証明書ベースの PSTN トランクを作成します。詳細については、「Webex Calling のトランク、ルート グループ、ダイヤル プランの設定」を参照してください。

トランクが作成されると、提供されたトランク情報をメモします。次の図で強調表示されているこれらの詳細は、このガイドの設定手順で使用されます。
2

次のコマンドを入力して、CUBE を Webex Calling ローカル ゲートウェイとして設定します。

 voice service voip ip address trusted list ipv4 x.x.x.x y.y.y モード border-element allow-connections sip to sip supplementary-service sip refer stun stun flowdata agent-id 1 boot-count 4 stun flowdata shared-secret 0 パスワード123$ sip asymmetric payload full early-offer forced sip-profiles inbound

以下は、設定のフィールドの説明です。

 ip アドレスの信頼リスト  ipv4 x.x.x.x y.y.y

  • トール詐欺から保護するために、信頼されたアドレス リストは、ローカル ゲートウェイが正当な VoIP コールを期待するホストおよびネットワーク エンティティのリストを定義します。

  • デフォルトでは、ローカル ゲートウェイは、信頼されたリストに含まれていない IP アドレスからのすべての着信 VoIP メッセージをブロックします。「セッション ターゲット IP」またはサーバー グループ IP アドレスを持つ静的に設定されたダイヤル ピアはデフォルトで信頼されるため、信頼されたリストに追加する必要はありません。

  • ローカル ゲートウェイを設定するときは、地域の Webex Calling データセンターの IP サブネットをリストに追加します。詳細については、「Webex Calling のポート参照情 報」を参照してください。また、Unified Communications Manager サーバ（使用されている場合）および PSTN トランク ゲートウェイのアドレス範囲を追加します。

  • IPアドレス信頼リストを使用してトール詐欺を防止する方法の詳細については、「IPアドレス信頼済み」を参照してください。

モード ボーダー要素

プラットフォームで Cisco Unified Border Element（CUBE）機能を有効にします。

allow-connections sip to sip

CUBE 基本 SIP バックツーバックユーザーエージェント機能を有効にします。詳細については、「接続を許可」を参照してください。

デフォルトでは、T.38 ファックス転送が有効になっています。詳細については、ファックスプロトコルt38 (音声サービス)を参照してください。

スタイン

STUN (NAT を介した UDP のセッショントラバーサル) をグローバルに有効にします。

これらのグローバル スタンコマンドは、NAT の後ろにローカル ゲートウェイを展開する場合にのみ必要です。

  • 通話を Webex Calling ユーザーに転送する場合 ( 例えば、通話側と通話側の両当事者が Webex Calling のサブスクライバーであり、Webex Calling SBC にメディアを固定する場合)、メディアはピンホールが開いていないので、ローカル ゲートウェイにフローできません。

  • ローカル ゲートウェイの STUN バインディング機能により、ネゴシエートされたメディア パス上でローカルに生成された STUN 要求を送信できます。これは、ファイアウォールのピンホールを開くのに役立ちます。

詳細については、「stun flowdata agent-id」および「stun flowdata shared-secret」を参照してください。

非対称ペイロード フル

DTMF と動的コーデック ペイロードの両方に対して SIP 非対称ペイロード サポートを設定します。このコマンドの詳細については、非対称ペイロードを参照してください。

early-offer forced

ローカル ゲートウェイは、隣接するピアからの確認を待つ代わりに、最初の INVITE メッセージで SDP 情報を送信するように強制します。このコマンドの詳細については、早期提供を参照してください。

SIP プロファイル着信

CUBE が SIP プロファイルを使用して、受信したメッセージを変更できるようにします。プロファイルは、ダイヤルピアまたはテナントを介して適用されます。

3

トランクの音声クラス コーデック 100 コーデック フィルタを設定します。この例では、すべてのトランクに同じコーデックフィルタが使用されます。正確な制御のために各トランクにフィルタを設定できます。

 音声クラス コーデック 100 コーデックの設定 1 opus コーデックの設定 2 g711ulaw コーデックの設定 3 g711alaw

以下は、設定のフィールドの説明です。

音声クラス コーデック 100

SIP トランクを介したコールの優先コーデックのみを許可するために使用されます。詳細については、「音声クラスコーデック」を参照してください。

Opus コーデックは、SIP ベースの PSTN トランクでのみサポートされています。PSTN トランクが音声 T1/E1 またはアナログ FXO 接続を使用する場合、コーデックの基本設定 1 opus を 音声クラス コーデック 100 構成から除外します。

4

音声クラス stun-usage 100 を設定して、Webex Calling トランクで ICE を有効にします。(この手順は政府版 Webex には適用されません)

 音声クラス stun-usage 100 stun-usage firewall-traversal flowdata stun-usage ice lite

以下は、設定のフィールドの説明です。

スタンの使用法 アイス ライト

すべての 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 100 暗号 1 AES_CM_128_HMAC_SHA1_80

以下は、設定のフィールドの説明です。

音声クラス srtp-crypto 100

SDP の SRTP 暗号スイート CUBE オファーおよび応答メッセージの唯一の SRTP オファーとして SHA1_80 を指定します。Webex Calling は SHA1_80 のみをサポートします。詳細については、音声クラス srtp-crypto を参照してください。

6

FIPS 準拠の GCM 暗号を設定します(この手順は政府版 Webex にのみ適用されます)。 

 音声クラス srtp-crypto 100 暗号 1 AEAD_AES_256_GCM

以下は、設定のフィールドの説明です。

音声クラス srtp-crypto 100

CUBE が提供する暗号スイートとして GCM を指定します。政府版 Webex のローカル ゲートウェイの GCM 暗号を設定することは必須です。

7

宛先 FQDN または SRV に基づいて、ローカル ゲートウェイ トランクへのコールを一意に識別するためのパターンを設定します。

 音声クラス uri 100 sip パターン cube1.lgw.com

以下は、設定のフィールドの説明です。

音声クラス uri 100 sip

着信トランク ダイヤル ピアへの着信 SIP 招待と一致するパターンを定義します。このパターンを入力するときは、トランクの作成中に Control Hub で設定された LGW FQDN または SRV を使用します。

8

SIP メッセージ操作プロファイルを設定します。ゲートウェイがパブリック IP アドレスで設定されている場合は、次のようにプロファイルを設定するか、NAT を使用している場合は、次のステップにスキップします。この例では、cube1.lgw.com はローカル ゲートウェイ用に設定された FQDN であり、「198.51.100.1」は Webex Calling に面したローカル ゲートウェイ インターフェイスのパブリック IP アドレスです。

 voice class sip-profiles 100 rule 10 リクエスト すべての sip-header 連絡先変更 "@.*:" "@cube1.lgw.com:" rule 20 応答 すべての sip-header 連絡先変更 "@.*:" "@cube1.lgw.com:"

以下は、設定のフィールドの説明です。

ルール10と20

Webex がローカル ゲートウェイからのメッセージを認証できるようにするには、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 プロファイル 
 音声クラス sip-profiles 100 rule 10 リクエスト ANY sip-header Contact modify "@.*:" "@cube1.lgw.com:" rule 20 response any sip-header Contact modify "@.*:" "@cube1.lgw.com:" rule 30 response ANY sdp-header Audio-Attribute modify "(a=candidate:1) 1.*) 10.80.13.12" "\1 192.65.79.20" rule 31 応答 ANY sdp-header Audio-Attribute modify "(a=candidate:1 2.*) 10.80.13.12" "\1 192.65.79.20" rule 40 の応答 ANY sdp-header Audio-Connection-Info 変更 "IN IP4 10.80.13.12" "IN IP4 192.65.79.20" RULE 41 の要求 ANY sdp-header Audio-Connection-Info 変更 "IN IP4 10.80.13.12" "IN IP4 192.65.79.20" RULE 50 の要求 ANY SDP-HEADER Connection-Info 変更 "IN IP4 10.80.13.12" "IN IP4 192.65.79.20" RULE 51 の応答 ANY sdp-header Connection-Info 変更 "IN IP4 10.80.13.12" "IN IP4 192.65.79.20" RULE 61 の要求 ANY sdp-header Session-Owner の変更 "IN IP4 10.80.13.12" "IN IP4 192.65.79.20" RULE 70 の要求 ANY sdp-header Audio-Attribute の変更"(a=rtcp:.*) 10.80.13.12" "\1 192.65.79.20" rule 71 の応答 any sdp-header Audio 1.*) 10.80.13.12" "\1 192.65.79.20" rule 81 リクエスト ANY sdp-header Audio-Attribute modify "(a=candidate:1 2.*) 10.80.13.12" "\1 192.65.79.20"

以下は、設定のフィールドの説明です。

ルール10と20

Webex がローカル ゲートウェイからのメッセージを認証できるようにするには、SIP リクエストと応答メッセージの「Contact」ヘッダーに Control Hub のトランク用にプロビジョニングされた値が含まれている必要があります。これは、単一のホストの FQDN、またはデバイスのクラスタに使用される SRV ドメイン名のいずれかになります。

ルール30～81

プライベート アドレス参照をサイトの外部パブリック アドレスに変換し、Webex が後続のメッセージを正しく解釈してルーティングできるようにします。

Webex Calling からの着信メッセージの SIP プロファイル 
 音声クラス sip-profiles 110 rule 10 応答 ANY sdp-header Video-Connection-Info 変更 "192.65.79.20" "10.80.13.12" rule 20 応答 ANY sip-header Connection-Info 変更 "@.*:" "@cube1.lgw.com:" rule 30 応答 ANY sdp-header Connection-Info 変更 "192.65.79.20" "10.80.13.12" rule 40 応答 ANY sdp-header Audio-Connection-Info 変更 "192.65.79.20" "10.80.13.12" rule 50 応答 ANY sdp-header Session-Owner 変更 "192.65.79.20" "10.80.13.12" rule 60 応答 ANY sdp-header Audio-Attribute modify "(a=candidate:1 1.*) 192.65.79.20" "\1 10.80.13.12" rule 70 応答 ANY sdp-header Audio-Attribute modify "(a=candidate:1 2.*) 192.65.79.20" "\1 10.80.13.12" rule 80 応答 ANY sdp-header Audio-attribute modify "(a=rtcp:.*) 192.65.79.20" "\1 10.80.13.12"

以下は、設定のフィールドの説明です。

10から80までのルール

パブリックアドレス参照を設定済みのプライベートアドレスに変換し、Webex からのメッセージを CUBE で正しく処理できるようにします。

詳細については、「音声クラス sip プロファイル」を参照してください。

10

ヘッダー変更プロファイルを使用して SIP オプションをキープアライブに設定します。

 voice class sip-profiles 115 rule 10 request OPTIONS sip-header 連絡先変更 "<sip:.*:" "<sip:cube1.lgw.com:" rule 30 要求 ANY sip-header 変更経由 "(SIP.*) 10.80.13.12" "\1 192.65.79.20" rule 40 応答 ANY sdp-header Connection-Info 変更 "10.80.13.12" "192.65.79.20" rule 50 応答 ANY sdp-header Audio-Connection-Info 変更 "10.80.13.12" "192.65.79.20" ! voice class sip-options-keepalive 100 説明 Webex Calling up-interval 5 transport tcp tls sip-profiles 115

以下は、設定のフィールドの説明です。

音声クラス 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 トランクの設定:

  1. 音声クラス テナント 100 を作成して、Webex Calling トランクに特別に必要な設定を定義し、グループ化します。このテナントに関連付けられているダイヤルピアは、後でこれらの設定を継承します。

    次の例では、このガイドの目的のために、ステップ 1 に示されている値を使用します (太字で表示)。これらを構成のトランクの値に置き換えます。

     voice class tenant 100 no remote-party-id sip-server dns:us25.sipconnect.bcld.webex.com srtp-crypto 100 localhost dns:cube1.lgw.com session transport tcp tls no session refresh error-passthru bind control source-interface GigabitEthernet0/0/1 bind media source-interface GigabitEthernet0/0/1 no pass-thru content custom-sdp sip-profiles 100 sip-profiles 110 inbound privacy-policy passthru !

    以下は、設定のフィールドの説明です。

    音声クラス テナント 100

    テナントを使用して、独自の TLS 証明書と CN または SAN 検証リストを持つトランクを設定することをお勧めします。ここでは、テナントに関連付けられた tls プロファイルに、新しい接続を受け入れるか作成するために使用される信頼ポイントが含まれており、着信接続を検証するための CN または SAN リストがあります。詳細については、「音声クラス テナント」を参照してください。

    no remote-party-id

    Webex Calling が PAI をサポートしているため、SIP Remote-Party-ID (RPID) ヘッダーを無効にします。これは、CIO asserted-id pai を使用して有効になります。詳細については、「remote-party-id」を参照してください。

    sip-server dns:us25.sipconnect.bcld.webex.com

    トランクのターゲット SIP サーバを設定します。トランクを作成したときに、Control Hub で提供されるエッジ プロキシ SRV アドレスを使用します

    srtp-crypto 100

    SRTP コール レッグ（接続）の優先暗号スイートを設定します（ステップで指定）5). 詳細については、音声クラス srtp-crypto を参照してください。

    localhost DNS: キューブ1.lgw.com

    発信メッセージの [送信元（From）]、[コール ID（Call-ID）]、および [リモートパーティーID（Remote-Party-ID）] ヘッダーの物理的な IP アドレスを、提供された FQDN で置き換えるように CUBE を設定します。

    session transport tcp tls

    関連付けられたダイヤルピアの TLS へのトランスポートを設定します。詳細については、「session-transport」を参照してください。

    セッション更新なし

    SIP セッションの更新をグローバルに無効にします。

    error-passthru

    SIP エラー応答パススルー機能を指定します。詳細については、error-passthruを参照してください。

    bind control source-interface GigabitEthernet0/0/1

    Webex Calling に送信されるメッセージのソース インターフェイスと関連する IP アドレスを設定します。詳細は、bindを参照してください。

    bind media source-interface GigabitEthernet0/0/1

    Webex Calling に送信されるメディアのソース インターフェイスおよび関連する IP アドレスを設定します。詳細は、bindを参照してください。

    voice-class SIP プロファイル 100

    発信メッセージに使用するヘッダー変更プロファイル（パブリック IP または NAT アドレッシング）を適用します。詳細については、「音声クラス SIP プロファイル」を参照してください。

    音声クラス SIP プロファイル 110 着信

    受信メッセージに使用するヘッダー変更プロファイル（NAT アドレスのみ）を適用します。詳細については、音声クラス SIP プロファイルを参照してください。

    privacy-policy passthru

    トランクのプライバシー ヘッダー ポリシー オプションを設定して、受信したメッセージから次のコール レッグにプライバシーの値を渡します。詳細については、プライバシーポリシーを参照してください。

  2. Webex Calling トランク ダイヤル ピアを設定します。

     ダイヤルピア ボイス 100 voip の説明 インバウンド/アウトバウンド Webex Calling の宛先パターン BAD.BAD セッション プロトコル sipv2 セッション target sip-server 着信 uri リクエスト 100 voice-class codec 100 voice-class stun-usage 100 voice-class sip rel1xx 無効 voice-class sip asserted-id pai voice-class sip tenant 100 voice-class sip options-keepalive profile 100 dtmf-relay rtp-nte srtp no vad

    以下は、設定のフィールドの説明です。

     ダイヤルピア ボイス 100 voip  の説明 着信/発信 Webex Calling

    タグ 100 で VoIP ダイヤルピアを定義し、管理とトラブルシューティングを容易にするための意味のある説明を提供します。詳細については、ダイヤルピアの音声を参照してください。

    destination-pattern BAD.BAD

    着信ダイヤル ピア グループを使用して発信コールをルーティングする場合は、ダミー接続先パターンが必要です。この場合、有効な宛先パターンを使用できます。

    session protocol sipv2

    ダイヤルピア 100 が SIP コール のコールコールを処理する場合に指定します。詳細については、セッションプロトコル（ダイヤルピア）を参照してください。

    session target sip-server

    テナント 100 で定義された SIP サーバが継承され、このダイヤル ピアからのコールの宛先に使用されることを示します。

    着信 uri リクエスト 100

    VoIP ダイヤル ピアと着信コールのユニフォーム リソース 識別子（URI）を一致させるために使用される音声クラスを指定します。詳細については、着信 uri を参照してください。

    音声クラス コーデック 100

    Webex Calling との通話のコーデック フィルター リストを示します。詳細については、「音声クラスコーデック」を参照してください。

    音声クラスstun使用 100

    ローカル ゲートウェイでローカルに生成された STUN 要求を、ネゴシエートされたメディア パス経由で送信できるようにします。STUN は、メディア トラフィックのファイアウォールのピンホールを開くのに役立ちます。

    音声クラス sip asserted-id pai

    プライバシー アサート済み ID（PAI）ヘッダーを使用して、発信通話情報を設定します。詳細については、voice-class sip asserted-idを参照してください。

    音声クラス sip テナント 100

    ダイヤル ピアは、グローバルおよびテナント 100 で設定されたすべてのパラメータを継承します。パラメータはダイヤルピア レベルで上書きされる場合があります。詳細については、「音声クラス SIP テナント」を参照してください。

    voice-class sip options-keepalive profile 100

    このコマンドは、特定のプロファイル（100）を使用して、SIP サーバまたはエンドポイントのグループの可用性を監視するために使用されます。

    srtp

    コールレグの SRTP を有効にする。

SIP PSTN トランクを使用したローカル ゲートウェイの設定

上記の 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 ホスト ipv4:192.168.80.13

以下は、設定のフィールドの説明です。

音声クラス uri 200 sip

着信トランク ダイヤル ピアへの着信 SIP 招待と一致するパターンを定義します。このパターンを入力するときは、IP PSTN ゲートウェイの IP アドレスを使用します。詳細については、音声クラス uri を参照してください。

2

次の IP PSTN ダイヤル ピアを設定します。

 ダイヤルピア ボイス 200 voip 説明 インバウンド/アウトバウンド IP PSTN トランクの宛先パターン BAD.BAD セッション プロトコル sipv2 セッション ターゲット ipv4:192.168.80.13 200 voice-class sip bind control source-interface GigabitEthernet0/0/0 voice-class sip bind media source-interface GigabitEthernet0/0/0 voice-class codec 100 dtmf-relay rtp-nte no vad

以下は、設定のフィールドの説明です。

 ダイヤルピア ボイス 200 voip  の説明 着信/発信 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 経由の着信 uri

VIA ヘッダーの判断基準を IP ヘッダーと IP アドレスPSTNを定義します。ローカル ゲートウェイのすべての着信 IP PSTN コール レッグとダイヤル ピア 200 を一致させます。詳細については、着信 URLを参照してください。

バインド制御ソースインタフェース GigabitEthernet0/0/0

PSTN に送信されるメッセージのソース インターフェイスと関連する IP アドレスを設定します。詳細は、bindを参照してください。

バインド メディア ソース インターフェイス GigabitEthernet0/0/0

PSTN に送信されるメディアのソース インターフェイスおよび関連する 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 プラットフォームを使用してローカル ゲートウェイを設定する場合は、次のセクションに進みます。

  1. ダイヤルピア グループを作成して、Webex Calling または PSTN にコールをルーティングします。Webex Calling に向けて発信ダイヤルピア 100 で DPG 100 を定義します。DPG 100 は、PSTN からの着信ダイヤルピアに適用されます。同様に、PSTN に向かって発信ダイヤルピア 200 で DPG 200 を定義します。DPG 200 は、Webex からの着信ダイヤルピアに適用されます。

     音声クラス dpg 100 の説明 Webex Calling のダイヤルピア 100 音声クラス dpg 200 の説明 コールを PSTN ダイヤルピア 200 にルーティングする

    以下は、設定のフィールドの説明です。

    ダイヤルピア 100

    発信ダイヤルピアとダイヤルピア グループを関連付けます。詳細は、音声クラス dpgを参照してください。

  2. ダイヤルピア グループを適用して、Webex から PSTN に、および PSTN から Webex にコールをルーティングします。 

     ダイヤルピア ボイス 100 宛先 dpg 200 ダイヤルピア ボイス 200 宛先 dpg 100

    以下は、設定のフィールドの説明です。

    destination dpg 200

    どのダイヤル ピア グループを指定します。したがって、この着信ダイヤル ピアに提示されたコールの発信処理にダイヤル ピアを使用する必要があります。

    これでローカル ゲートウェイの設定は終了します。CUBE 機能が初めて設定される場合は、設定を保存し、プラットフォームをリロードします。

TDM PSTN トランクを使用したローカル ゲートウェイの設定

Webex Calling に向けてトランクを構築した後は、次の設定を使用して、Webex コール レッグのメディア最適化を可能にするために、ループ バック コール ルーティングを備えた PSTN サービスの TDM トランクを作成します。

IP メディア最適化を必要としない場合は、SIP PSTN トランクの設定手順に従います。PSTN VoIP ダイヤル ピアの代わりに、ボイス ポートと POTS ダイヤル ピア（手順 2 および 3 を参照）を使用します。
1

ループ バック ダイヤル ピア構成では、ダイヤル ピア グループとコール ルーティング タグを使用して、コール ルーティング ループを作成せずに、Webex と PSTN の間でコールが正しく渡されるようにします。コール ルーティング タグの追加と削除に使用する次のトランスレーション ルールを設定します。

 音声翻訳ルール 100 ルール 1 /^\+//A2A/ 音声翻訳プロファイル 100 呼び出された音声翻訳ルール 200 ルール 1 /^//A1A/ 音声翻訳プロファイル 200 呼び出された音声翻訳ルール 11 ルール 1 /^A1A/ // 音声翻訳プロファイル 11 呼び出された音声翻訳ルール 12 ルール 1 /^A2A44//0/ RULE 2/^A2A//00/ 音声翻訳プロファイル 12 呼び出された音声翻訳ルール 12

以下は、設定のフィールドの説明です。

音声翻訳ルール

ルールで定義された正規表現を使用して、コール ルーティング タグを追加または削除します。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 インターフェイスの基本設定には、次のものが含まれます。

 カードタイプ e1 0 2 つの isdn スイッチタイプ primary-net5 コントローラ E1 0/2/0 pri-group タイムスロット 1-31
3

次の TDM PSTN ダイヤル ピアを設定します。

 ダイヤルピア ボイス 200 ポット説明 着信/発信 PRI PSTN トランクの宛先パターン BAD.BAD translation-profile 着信 200 直通ダイヤルポート 0/2/0:15

以下は、設定のフィールドの説明です。 

 ダイヤルピアの音声 200 ポット  の説明 着信/発信 PRI 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 にルーティングされます。ルーティング タグを削除すると、コールはダイヤル ピア グループを使用して発信トランクにルーティングされます。

 dial-peer voice 10 voip description Outbound loop-around leg destination-pattern BAD.BAD session protocol sipv2 session target ipv4:192.168.80.14 voice-class sip bind control source-interface GigabitEthernet0/0/0 dtmf-relay rtp-nte codec g711alaw no vad dial-peer voice 11 voip description Webex translation-profile inbound 11 session protocol sipv2 incoming called-number A1AT voice-class sip bind control source-interface GigabitEthernet0/0/0 dtmf-relay rtp-nte codec g711alaw no vad dial-peer voice 12 voip description PSTN translation-profile incoming 12 session protocol sipv2 incoming called-number A2AT voice-class sip bind control source-interface GigabitEthernet0/0/0 dtmf-relay rtp-nte codec g711alaw no vad dial-peer voice 12 voip description PSTN translation-profile incoming 12 session protocol sipv2 incoming called-number A2AT voice-class sip bind control source-interface GigabitEthernet0/0/0 dtm

以下は、設定のフィールドの説明です。 

 ダイヤルピアの音声 10 ポット  の説明 アウトバウンドループバックレッグ

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

次のコール ルーティング設定を追加します。

  1. ダイヤルピア グループを作成して、ループバックを介して PSTN と Webex トランク間のコールをルーティングします。

     音声クラス dpg 100 の説明 Webex Calling のダイヤルピア 100 音声クラス dpg 200 の説明 コールを PSTN ダイヤルピア 200 の音声クラス dpg 10 の説明 通話をループバックダイヤルピア 10 にルーティングする

    以下は、設定のフィールドの説明です。

    ダイヤルピア 100

    発信ダイヤルピアとダイヤルピア グループを関連付けます。詳細は、音声クラス dpgを参照してください。

  2. ダイヤル ピア グループを適用してコールをルーティングします。

     ダイヤルピア ボイス 100 宛先 dpg 10 ダイヤルピア ボイス 200 宛先 dpg 10 ダイヤルピア ボイス 11 宛先 dpg 100 ダイヤルピア ボイス 12 宛先 dpg 200

    以下は、設定のフィールドの説明です。

    宛先 dpg 200

    どのダイヤル ピア グループを指定します。したがって、この着信ダイヤル ピアに提示されたコールの発信処理にダイヤル ピアを使用する必要があります。

これでローカル ゲートウェイの設定は終了します。CUBE 機能が初めて設定される場合は、設定を保存し、プラットフォームをリロードします。
ローカル ゲートウェイを既存の Unified CM 環境で構成する

前のセクションの PSTN-Webex Calling 設定は、Cisco Unified Communications Manager (UCM) クラスタへの追加のトランクを含めるように変更される場合があります。この場合、すべてのコールは Unified CM 経由でルーティングされます。ポート 5060 の UCM からのコールは PSTN にルーティングされ、ポート 5065 からのコールは Webex Calling にルーティングされます。次の増分設定を追加して、この通話シナリオを含めることができます。

1

以下の音声クラス URI を設定:

  1. SIP VIA ポートを使用して Unified CM を Webex コールに分類します。

     voice class uri 300 sip
 pattern :5065

  2. ポート経由の SIP を使用して、Unified CM を PSTN コールに分類します。

     音声クラス uri 400 sip パターン 192\.168\.80\.6[0-5]:5060

    発信元のソース アドレスとポート番号を説明する 1 つ以上のパターンを使用して、UCM からの着信メッセージを PSTN トランクに分類します。必要に応じて、正規表現を使用して、一致するパターンを定義できます。

    上記の例では、192.168.80.60 から 65 までの範囲およびポート番号 5060 の任意の IP アドレスに一致させるために正規表現が使用されます。

2

次の DNS レコードを設定して、Unified CM ホストへの SRV ルーティングを指定します。

IOS XE は、これらのレコードをローカルでターゲット UCM ホストとポートを決定するために使用します。この設定では、DNS システムでレコードを設定する必要はありません。DNS を使用する場合は、これらのローカル設定は必要ありません。

 ip ホスト ucmpub.mydomain.com 192.168.80.60 ip ホスト ucmsub1.mydomain.com 192.168.80.61 ip ホスト ucmsub2.mydomain.com 192.168.80.62 ip ホスト ucmsub3.mydomain.com 192.168.80.63 ip ホスト ucmsub4.mydomain.com 192.168.80.64 ip ホスト ucmsub5.mydomain.com 192.168.80.65 ip ホスト _sip._udp.wxtocucm.io srv 0 1 5065 ucmpub.mydomain.com ip ホスト _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub1.mydomain.com ip ホスト _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub2.mydomain.com ip ホスト _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub3.mydomain.com ip ホスト _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub4.mydomain.com ip ホスト _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub5.mydomain.com ip ホスト _sip._udp.pstntocucm.io srv 0 1 5060 ucmpub.mydomain.com ip ホスト _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub1.mydomain.com ip ホスト _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub2.mydomain.com ip ホスト _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub3.mydomain.com ip ホスト _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub4.mydomain.com ip ホスト _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub5.mydomain.com

以下は、設定のフィールドの説明です。

次のコマンドは、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

次のダイヤルピアを設定します。

  1. Unified CM と Webex Calling 間のコールのダイヤルピア:

     ダイヤルピア ボイス 300 voip の説明 UCM-Webex Calling トランクの宛先パターン BAD.BAD セッション プロトコル sipv2 セッション target dns:wxtocucm.io 着信 uri via 300 voice-class codec 100 voice-class sip bind control source-interface ギガビットイーサネット 0/0/0 voice-class sip bind media source-interface ギガビットイーサネット 0/0/0 dtmf-relay rtp-nte no vad

    以下は、設定のフィールドの説明です。

     ダイヤルピア ボイス 300 voip  の説明 UCM-Webex Calling トランク

    タグ 30 0 を使用して VoIP ダイヤルピアを定義し、管理とトラブルシューティングを容易にするための意味のある説明を提供します。

    destination-pattern BAD.BAD

    着信ダイヤル ピア グループを使用して発信コールをルーティングする場合は、ダミー接続先パターンが必要です。この場合、有効な宛先パターンを使用できます。

    session protocol sipv2

    ダイヤルピア 300 が SIP コール レッグを処理するように指定します。詳細については、セッションプロトコル（ダイヤルピア）を参照してください。

    セッション ターゲット dns:wxtocucm.io

    DNS SRV 解決を通じて複数の Unified CM ノードのセッション ターゲットを定義します。この場合、ローカルで定義された SRV レコード wxtocucm.io がコールをダイレクトするために使用されます。

    incoming uri via 300

    音声クラス URI 300 を使用して、ソース ポート 5065 を使用して Unified CM からのすべての着信トラフィックをこのダイヤル ピアにダイレクトします。詳細については、着信 uri を参照してください。

    音声クラス コーデック 100

    Unified CM との間のコールのコーデック フィルタ リストを示します。詳細については、「音声クラスコーデック」を参照してください。

    バインド制御ソースインタフェース GigabitEthernet0/0/0

    PSTN に送信されるメッセージのソース インターフェイスと関連する IP アドレスを設定します。詳細は、bindを参照してください。

    バインド メディア ソース インターフェイス GigabitEthernet0/0/0

    PSTN に送信されるメディアのソース インターフェイスおよび関連する IP アドレスを設定します。詳細は、bindを参照してください。

    dtmf-relay rtp-nte

    通話レグで予想される DTMF 機能として RTP-NTE (RFC2833) を定義します。詳細については、「DTMF Relay (Voice over IP)」を参照してください。

    no vad

    音声アクティブティの検出を無効にします。詳細については、vad（ダイヤルピア）を参照してください。

  2. Unified CM と PSTN 間のコールのダイヤルピア:

     ダイヤルピア ボイス 400 voip の説明 UCM-PSTN トランクの宛先パターン BAD.BAD セッション プロトコル sipv2 セッション target dns:pstntocucm.io 着信 uri via 400 voice-class codec 100 voice-class sip bind control source-interface ギガビットイーサネット 0/0/0 voice-class sip bind media source-interface ギガビットイーサネット 0/0/0 dtmf-relay rtp-nte no vad

    以下は、設定のフィールドの説明です。

     ダイヤルピア ボイス 400 voip  の説明 UCM-PSTN トランク

    400のタグ を含むVoIPダイヤルピアを定義し、管理とトラブルシューティングを容易にするための意味のある説明を提供します。

    destination-pattern BAD.BAD

    着信ダイヤル ピア グループを使用して発信コールをルーティングする場合は、ダミー接続先パターンが必要です。この場合、有効な宛先パターンを使用できます。

    session protocol sipv2

    ダイヤルピア 400 が SIP コール レッグを処理するように指定します。詳細については、セッションプロトコル（ダイヤルピア）を参照してください。

    セッション ターゲット dns:pstntocucm.io

    DNS SRV 解決を通じて複数の Unified CM ノードのセッション ターゲットを定義します。この場合、ローカルで定義された SRV レコード pstntocucm.io がコールをダイレクトするために使用されます。

    400 経由の着信 uri

    音声クラス URI 400 を使用して、ソース ポート 5060 を使用して指定された Unified CM ホストからのすべての着信トラフィックをこのダイヤル ピアに転送します。詳細については、着信 uri を参照してください。

    音声クラス コーデック 100

    Unified CM との間のコールのコーデック フィルタ リストを示します。詳細については、「音声クラスコーデック」を参照してください。

    バインド制御ソースインタフェース GigabitEthernet0/0/0

    PSTN に送信されるメッセージのソース インターフェイスと関連する IP アドレスを設定します。詳細は、bindを参照してください。

    バインド メディア ソース インターフェイス GigabitEthernet0/0/0

    PSTN に送信されるメディアのソース インターフェイスおよび関連する IP アドレスを設定します。詳細は、bindを参照してください。

    dtmf-relay rtp-nte

    通話レグで予想される DTMF 機能として RTP-NTE (RFC2833) を定義します。詳細については、「DTMF Relay (Voice over IP)」を参照してください。

    no vad

    音声アクティブティの検出を無効にします。詳細については、vad（ダイヤルピア）を参照してください。

4

次の設定を使用してコール ルーティングを追加します。

  1. Unified CM と Webex Calling の間で通話をルーティングするダイヤル ピア グループを作成します。DPG 100 を 発信ダイヤルピア 100 で Webex Calling に対して定義します。DPG 100 は、Unified CM から関連付けられた着信ダイヤルピアに適用されます。同様に、Unified CM に向かって発信ダイヤルピア 300 で DPG 300 を定義します。DPG 300 は、Webex からの着信ダイヤルピアに適用されます。

     音声クラス dpg 100 の説明 Webex Calling のダイヤルピア 100 音声クラス dpg 300 の説明 コールを Unified CM にルーティング Webex Calling トランク ダイヤルピア 300 にルーティング

  2. Unified CM と PSTN の間でコールをルーティングするダイヤル ピア グループを作成します。PSTN に対して発信ダイヤルピア 200 で DPG 200 を定義します。DPG 200 は、Unified CM から関連付けられた着信ダイヤルピアに適用されます。同様に、Unified CM に向かって発信ダイヤルピア 400 で DPG 400 を定義します。DPG 400 は、PSTN からの着信ダイヤルピアに適用されます。

     音声クラス dpg 200 の説明 コールを PSTN ダイヤルピア 200 音声クラス dpg 400 の説明 コールを Unified CM PSTN トランクダイヤルピア 400 にルーティングする

    以下は、設定のフィールドの説明です。

    ダイヤルピア 100

    発信ダイヤルピアとダイヤルピア グループを関連付けます。詳細は、音声クラス dpgを参照してください。

  3. ダイヤルピア グループを適用して、Webex から Unified CM に、および Unified CM から Webex にコールをルーティングします。 

     ダイヤルピア ボイス 100 宛先 dpg 300 ダイヤルピア ボイス 300 宛先 dpg 100

    以下は、設定のフィールドの説明です。

    宛先 dpg 300

    どのダイヤル ピア グループを指定します。したがって、この着信ダイヤル ピアに提示されたコールの発信処理にダイヤル ピアを使用する必要があります。

  4. ダイヤルピア グループを適用して、PSTN から Unified CM に、Unified CM から PSTN にコールをルーティングします。

     ダイヤルピア ボイス 200 宛先 dpg 400 ダイヤルピア ボイス 400 宛先 dpg 200

    これでローカル ゲートウェイの設定は終了します。CUBE 機能が初めて設定される場合は、設定を保存し、プラットフォームを再読み込みします。

診断署名でローカル ゲートウェイを監視し、トラブルシューティングする

診断署名 (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 以上を実行するローカル ゲートウェイ

  1. 診断署名はデフォルトで有効になっています。

  2. デバイスが IOS XE 17.6.1 以降を実行している場合、プロアクティブ通知の送信に使用するセキュアなメール サーバーを構成します。

     ターミナル コールホーム メール サーバー  を設定します。@ 優先順位 1 セキュア tls エンド

  3. 通知する管理者 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% 以上に達すると、すべてのデバッグが無効し、ローカル ゲートウェイにインストールした診断署名をアンインストールします。下記の手順を実行して署名をインストールします。

  1. コマンドを使用して 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: 有効

  2. 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 使用率

  3. 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 バイト

  4. ローカルゲートウェイに DS XML ファイルをインストールします。

     call-home diagnostic-signature load DS_64224.xml ロードファイル DS_64224.xml 成功

  5. 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 とメール通知が生成されます。 署名をインストールするには、以下の手順を使用してください。

  1. コマンド 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: 有効

  2. Diagnostic Signatures Lookup Tool の以下のオプションを使用して、DS 65221 をダウンロードします。

    フィールド名

    フィールド値

    プラットフォーム

    Cisco 4300、4400 ISR シリーズ、または Catalyst 8000V Edge ソフトウェア

    製品

    Webex Calling ソリューションの CUBE Enterprise

    問題の範囲

    パフォーマンス

    問題の種類

    メールおよび Syslog 通知による SIP の異常通話切断検出

  3. DS XML ファイルをローカルゲートウェイにコピーします。

    ftp://username:password@/DS_65221.xml bootflash:

  4. ローカルゲートウェイに DS XML ファイルをインストールします。 

     call-home diagnostic-signature load DS_65221.xml ロードファイル DS_65221.xml 成功

  5. コマンド 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 を使用して、以下の手順を使用して、診断データの収集を自動化します。

  1. 診断データをアップロードするために、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"

  2. コマンド show snmp を使用して、SNMP が有効 になっている必要があります。SNMP が有効になっていない場合は、snmp-server manager コマンドを設定します。

     show snmp %SNMP agent not enabled config t snmp-server manager end

  3. 高 CPU 使用率の期間中に、すべてのデバッグと診断署名を無効にすることを推奨するプロアクティブな措置として、高 CPU モニタリング DS 64224 をインストールすることを推奨します。Diagnostic Signatures Lookup Tool の以下のオプションを使用して、DS 64224 をダウンロードします。

    フィールド名

    フィールド値

    プラットフォーム

    Cisco 4300、4400 ISR シリーズ、または Catalyst 8000V Edge ソフトウェア

    製品

    Webex Calling ソリューションの CUBE Enterprise

    問題の範囲

    パフォーマンス

    問題の種類

    通知メールによる CPU 使用率が高い

  4. 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

  5. DS XML ファイルをローカルゲートウェイにコピーします。

     ftp://username:password@/DS_64224.xml bootflash: ftp://username:password@/DS_65095.xml bootflash:

  6. ローカル ゲートウェイに高 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 成功

  7. 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 エンタープライズ展開が、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 設定ガイドを次に示します。

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

インターフェイスのステータスを追跡するために、グローバル レベルでインターフェイス トラッキングを構成します。

conf t
 track 1 interface GigabitEthernet1 line-protocol
 track 2 interface GigabitEthernet2 line-protocol
 exit 

VCUBE-1#conf t

VCUBE-1(config)#track 1 インターフェイス GigabitEthernet1 回線プロトコル

VCUBE-1(config-track)#トラック 2 インターフェイス GigabitEthernet2 回線プロトコル

VCUBE-1(config-track)#終了

VCUBE-2#conf t

VCUBE-2(config)#track 1 インターフェイス GigabitEthernet1 回線プロトコル

VCUBE-2(config-track)#トラック 2 インターフェイス GigabitEthernet2 回線プロトコル

VCUBE-2(config-track)#終了

トラッキング CLI は、トラフィック インターフェイスがダウンした後、アクティブ ルートがアクティブな役割を果たすように、RG 内で音声トラフィックインターフェイスの状態を追跡するために使用されます。

2

アプリケーション冗長性サブモード下の VoIP HA で使用する RG を構成します。

redundancy
  application redundancy
   group 1
    name LocalGateway-HA
    priority 100 failover threshold 75
    control GigabitEthernet3 protocol 1
    data GigabitEthernet3
    timers delay 30 reload 60
    track 1 shutdown
    track 2 shutdown
    exit
   protocol 1
    timers hellotime 3 holdtime 10
   exit
  exit
 exit 

VCUBE-1(config)#冗長性

VCUBE-1(config-red)#アプリケーション冗長性

VCUBE-1(config-red-app)#グループ 1

VCUBE-1(config-red-app-grp)#name LocalGateway-HA

VCUBE-1(config-red-app-grp)#priority 100 フェールオーバーしきい値 75

VCUBE-1(config-red-app-grp)#control GigabitEthernet3 プロトコル 1

VCUBE-1(config-red-app-grp)#データ GigabitEthernet3

VCUBE-1(config-red-app-grp)#タイマー遅延 30 再ロード 60

VCUBE-1(config-red-app-grp)#トラック 1 シャットダウン

VCUBE-1(config-red-app-grp)#トラック 2 シャットダウン

VCUBE-1(config-red-app-grp)#exit

VCUBE-1(config-red-app)#プロトコル 1

VCUBE-1(config-red-app-prtcl)#タイマー hellotime 3 holdtime 10

VCUBE-1(config-red-app-prtcl)#exit

VCUBE-1(config-red-app)#exit

VCUBE-1(config-red)#終了

VCUBE-1(config)#

VCUBE-2(config)#冗長性

VCUBE-2(config-red)#アプリケーション冗長性

VCUBE-2(config-red-app)#グループ 1

VCUBE-2(config-red-app-grp)#name LocalGateway-HA

VCUBE-2(config-red-app-grp)#priority 100 フェールオーバーしきい値 75

VCUBE-2(config-red-app-grp)#control GigabitEthernet3 プロトコル 1

VCUBE-1(config-red-app-grp)#データ GigabitEthernet3

VCUBE-2(config-red-app-grp)#タイマー遅延 30 再ロード 60

VCUBE-2(config-red-app-grp)#トラック 1 シャットダウン

VCUBE-2(config-red-app-grp)#トラック 2 シャットダウン

VCUBE-2(config-red-app-grp)#exit

VCUBE-2(config-red-app)#プロトコル 1

VCUBE-2(config-red-app-prtcl)#タイマー hellotime 3 holdtime 10

VCUBE-2(config-red-app-prtcl)#exit

VCUBE-2(config-red-app)#exit

VCUBE-2(config-red)#終了

VCUBE-2(config)#

この構成で使用されるフィールドの説明を次に示します。

  • 冗長性: 冗長モードに入る

  • アプリケーション冗長性: アプリケーション冗長設定モードに入ります

  • group—冗長性アプリケーション グループ設定モードに入ります

  • name LocalGateway-HA—RG グループの名前を定義します。

  • 優先度 100 フェールオーバーしきい値 75: RG の初期優先順位とフェールオーバーしきい値を指定します。

  • タイマー遅延 30 reload 60: 遅延と再読み込みに対して 2 回設定します。

    • インターフェイスが起動した後、RG グループの初期設定と役割のネゴシエーションの遅延時間を示す遅延タイマーです。デフォルトは 30 秒です。範囲は 0-10000 秒です

    • Reload—これは、リロード後の RG グループ初期設定と役割ネゴシエーションの遅延時間です。デフォルトは 60 秒です。範囲は 0-10000 秒です

    • デフォルトのタイマーが推奨されていますが、これらのタイマーは、ネットワークのルーティングが安定した時点の後、RG プロトコルのネゴシエーションが行われることを保証するために、ルーターの起動/再読み込み中に発生する可能性がある追加のネットワーク集約遅延に合わせて調整される場合があります。たとえば、フェールオーバー後に、新しいスタンバイに最大 20 秒間かかり、新しいアクティブから最初の RG HELLO パケットを確認する場合は、この遅延を考慮して、最初の RG HELLO パケットを「タイマー遅延 60 リロード 120」に調整する必要があります。

  • control GigabitEthernet3 protocol 1—2 つの CUBE 間でキープアライブとハローメッセージを交換するために使用されるインターフェイスを構成し、コントロール インターフェイスに接続されるプロトコル インスタンスを指定し、冗長アプリケーション プロトコル構成モードに入ります

  • data GigabitEthernet3—データ トラフィックのチェックポイントに使用されるインターフェイスを設定します

  • track - インターフェイスの RG グループ トラッキング

  • プロトコル 1—コントロール インターフェイスに接続されるプロトコル インスタンスを指定し、冗長性アプリケーション プロトコル設定モードに入ります。

  • タイマー hellotime 3 holdtime 10: hellotime と holdtime の 2 つのタイマーを設定します。

    • Hellotime— 連続する hello メッセージの間隔 (デフォルトで 3 秒)。範囲は 250 ミリ秒から 254 秒です

    • Holdtime — Hello メッセージの受信と送信ルーターが失敗した推定の間隔。この継続時間は、hello time (デフォルトの 10 秒より長くする必要があります) 以上である必要があります。範囲は 750 ミリ秒から 255 秒です

      Holdtime タイマーを hellotime タイマーの最低 3 倍の値に設定することをお勧めします。

3

CUBE アプリケーションのボックス間の冗長性を有効にします。[voice service voip] の以前の手順から RG を構成します。これにより、CUBE アプリケーションは冗長性プロセスをコントロールすることができます。

voice service voip
   redundancy-group 1
   exit

VCUBE-1(config)#音声サービス voip

VCUBE-1(config-voi-serv)#redundancy-group 1

 % Created RG 1 association with Voice B2B HA; reload the router for the new configuration to take effect 

VCUBE-1(config-voi-serv)# 終了

VCUBE-2(config)#音声サービス voip

VCUBE-2(config-voi-serv)#redundancy-group 1

 % Created RG 1 association with Voice B2B HA; reload the router for the new configuration to take effect 

VCUBE-2(config-voi-serv)# 終了

redundancy-group 1: このコマンドを追加および削除するには、更新された構成を有効にするために再読み込みが必要です。すべての構成が適用された後で、プラットフォームを再読み込みします。

4

以下に示すように、Gig1 と Gig2 インターフェイスをそれぞれの仮想 IP で構成し、冗長性インターフェイス識別子 (rii) を適用します。

VCUBE-1(config)#インターフェイス GigabitEthernet1

VCUBE-1(config-if)# 冗長性 rii 1

VCUBE-1(config-if)# 冗長グループ 1 ip 198.18.1.228 限定

VCUBE-1(config-if)# 終了

VCUBE-1(config)#

VCUBE-1(config)#インターフェイス GigabitEthernet2

VCUBE-1(config-if)# 冗長性 rii 2

VCUBE-1(config-if)# 冗長グループ 1 ip 198.18.133.228 専用

VCUBE-1(config-if)# 終了

VCUBE-2(config)#インターフェイス GigabitEthernet1

VCUBE-2(config-if)# 冗長性 rii 1

VCUBE-2(config-if)# 冗長グループ 1 ip 198.18.1.228 限定

VCUBE-2(config-if)# 終了

VCUBE-2(config)#

VCUBE-2(config)#インターフェイス GigabitEthernet2

VCUBE-2(config-if)# 冗長性 rii 2

VCUBE-2(config-if)# 冗長グループ 1 ip 198.18.133.228 専用

VCUBE-v(config-if)# 終了

この構成で使用されるフィールドの説明を次に示します。

  • redundancy rii: 冗長グループの冗長インターフェイス ID を設定します。仮想 MAC (VMAC) アドレスを生成するために必要です。同じ VIP を持つ各ルーター (アクティブ/スタンバイ) のインターフェイスで同じ rii ID 値を使用する必要があります。

    同じ LAN に複数の B2B ペアがある場合、各ペアはそれぞれのインターフェイスに固有の RII ID を持っている必要があります（衝突を防ぐため）。「冗長性アプリケーショングループをすべて表示」は、正しいローカルおよびピア情報を示す必要があります。

  • 冗長グループ 1: 上記のステップ 2 で作成された冗長グループとインターフェイスを関連付けます。RG グループ、およびこの物理インターフェイスに割り当てられた VIP を構成します。

    冗長性のために別のインターフェイスを使用することが必須です。つまり、音声トラフィックに使用されるインターフェイスは、上記の手順 2 で指定したコントロールとデータ インターフェイスとして使用できません。この例では、RG コントロール/データにギガビット インターフェイス 3 が使用されています。

5

最初の CUBE 構成を保存し、再読み込みします。

最後にリロードするプラットフォームは常にスタンバイです。

VCUBE-1#wr

 構成を検証しています... 

 [OK] 

VCUBE-1#再読み込み

 再読み込みを続行しますか? [確認]

VCUBE-1 が完全に起動したら、 VCUBE-2 の構成を保存し、再読み込みします。

VCUBE-2#wr

 構成を検証しています... 

 [OK] 

VCUBE-2#再読み込み

 再読み込みを続行しますか? [確認]

6

ボックス間の構成が期待どおりに機能していることを確認します。関連する出力は太字で強調表示されます。

VCUBE-2 を最後にリロードし、設計上の考慮事項に従います。最後にリロードするプラットフォームは常に [スタンバイ] 状態です。 

 VCUBE-1#冗長性アプリケーショングループのすべての表示 障害状態 グループ 1 の情報: Runtime priority: [100] RG Faults RG State: UP. Total # of switchovers due to faults: 0 Total # of down/up state changes due to faults: 0 Group ID:1 Group Name:LocalGateway-HA Administrative State: No Shutdown Aggregate operational state: Up My Role: ACTIVE Peer Role: STANDBY Peer Presence: Yes Peer Comm: Yes Peer Progression Started: Yes RF Domain: btob-one RF state: ACTIVE Peer RF state: STANDBY HOT RG Protocol RG 1 ------------------ Role: Active Negotiation: Enabled Priority: 100 Protocol state: Active Ctrl Intf(s) state: Up Active Peer: Local Standby Peer: address 10.1.1.2, priority 100, intf Gi3 Log counters: role change to active: 1 role change to standby: 1 disable events: rg down state 0, rg shut 0 ctrl intf events: 上 1、下 0、admin_down 0 イベントの再読み込み: local request 0, peer request 0 RG Media Context for RG 1 -------------------------- Ctx State: Active Protocol ID: 1 Media type: Default Control Interface: GigabitEthernet3 Current Hello timer: 3000 Configured Hello timer: 3000, Hold timer: 10000 Peer Hello timer: 3000, Peer Hold timer: 10000 Stats: Pkts 1509, Bytes 93558, HA Seq 0, Seq Number 1509, Pkt Loss 0 Authentication not configured Authentication Failure: 0 Reload Peer: TX 0, RX 0 Resign: TX 0, RX 0 Standy Peer: Present. Hold Timer: 10000 Pkts 61、Bytes 2074、HA Seq 0、Seq Number 69、Pkt Loss 0 VCUBE-1#
 VCUBE-2#冗長アプリケーション グループを表示 デフォルト状態 グループ 1 情報: Runtime priority: [100] RG Faults RG State: UP. Total # of switchovers due to faults: 0 Total # of down/up state changes due to faults: 0 Group ID:1 Group Name:LocalGateway-HA Administrative State: No Shutdown Aggregate operational state: Up My Role: STANDBY Peer Role: ACTIVE Peer Presence: Yes Peer Comm: Yes Peer Progression Started: Yes RF Domain: btob-one RF state: ACTIVE Peer RF state: STANDBY HOT RG Protocol RG 1 ------------------ Role: Active Negotiation: Enabled Priority: 100 Protocol state: Active Ctrl Intf(s) state: Up Active Peer: address 10.1.1.2, priority 100, intf Gi3 Standby Peer: Local Log counters: role change to active: 1 role change to standby: 1 disable events: rg down state 0, rg shut 0 ctrl intf events: 上 1、下 0、admin_down 0 イベントの再読み込み: local request 0, peer request 0 RG Media Context for RG 1 -------------------------- Ctx State: Active Protocol ID: 1 Media type: Default Control Interface: GigabitEthernet3 Current Hello timer: 3000 Configured Hello timer: 3000, Hold timer: 10000 Peer Hello timer: 3000, Peer Hold timer: 10000 Stats: Pkts 1509, Bytes 93558, HA Seq 0, Seq Number 1509, Pkt Loss 0 Authentication not configured Authentication Failure: 0 Reload Peer: TX 0, RX 0 Resign: TX 0, RX 0 Standy Peer: Present. Hold Timer: 10000
            Pkts 61, Bytes 2074, HA Seq 0, Seq Number 69, Pkt Loss 0

VCUBE-2#

両方の CUBE でローカル ゲートウェイを構成する

この例の構成では、Control Hub から以下のトランク情報を使用して、VCUBE-1、VCUBE-2 の両方のプラットフォームでローカルゲートウェイを構成しています。この設定のユーザー名とパスワードは以下のとおりです。

  • ユーザー名: フセイン1076LGU_

  • パスワード:lOV12MEaZx

1

クレデンシャルまたは共有秘密で使用する前に、以下のコマンドを使用して、設定キーがパスワードに対して作成されていることを確認してください。Type 6 パスワードは、AES 暗号化とこのユーザー定義の設定キーを使用して暗号化されます。 

 LocalGateway#conf t LocalGateway(config)#key config-key password-encrypt Password123 LocalGateway(config)#password encryption aes

これは、上に表示されている Control Hub のパラメーターに基づき、両方のプラットフォームに適用し、保存し、リロードするローカ ルゲートウェイの構成です。Control Hub からの SIP ダイジェスト資格情報は、太字でハイライトされます。

 Configure terminal crypto pki trustpoint dummyTp revocation-check crl exit sip-ua crypto signaling default trustpoint dummyTp cn-san-validate server transport tcp tls v1.2 end configure terminal crypto pki trustpool import clean url http://www.cisco.com/security/pki/trs/ios_core.p7b end configure terminal voice service voip ip address trusted list ipv4 x.x.x.x.x y.y.y exit allow-connections sip to sip media statistics media bulk-stats no supplementary-service sip refer no supplementary-service sip handle-replaces fax protocol pass-through g711ulaw stun stun flowdata agent-id 1 boot-count 4 stun flowdata shared-secret 0 Password123! sip g729 annexb-all early-offer forced end configure terminal voice class sip-profiles 200 rule 9 request ANY sip-header SIP-Req-URI modify "sips:(.*)" "sip:\1" rule 10 request ANY sip-header modify "" "" ";otgフセイン1076_lgu>" rule 30 リクエスト すべての sip-header P-Asserted-Identity 変更 "sips:(.*)" "sip:\1" 音声クラス コーデック 99 コーデックの設定 1 g711ulaw コーデックの設定 2 g711ulaw 終了音声クラス srtp-crypto 200 crypto 1 AES_センチメートル_128_hmac_社 1_80 exit voice class stun-usage 200 stun-usage firewall-traversal flowdata exit voice class tenant 200 レジストラ dns:40462196.cisco-bcld.com スキーム sips の有効期限が 240 更新比 50 tcp tls クレデンシャル番号 フセイン5091_ルグ ユーザ名 Hussain1076_LGU パスワード 0 lOV12MEaZx レルム Broadworks 認証ユーザー名 フセイン5091_ルグ パスワード 0 lOV12MEaZx レルム BroadWorks 認証ユーザー名 フセイン5091_ルグ パスワード 0 lOV12MEaZx レルム 40462196.cisco-bcld.com remote-party-id sip-server がありません dns:40462196.cisco-bcld.com connection-reuse srtp-crypto 200 session transport tcp tls url sips error-passthru asserted-id pai bind control source-interface GigabitEthernet1 bind media source-interface GigabitEthernet1 pass-thru content custom-sdp sip-profiles 200 outbound-proxy dns:la01.sipconnect-us10.cisco-bcld.com privacy-policy passthru voice class tenant 100 session transport udp url sip error-passthru bind control source-interface GigabitEthernet2 bind media source-interface GigabitEthernet2 no pass-thru content custom-sdp voice class tenant 300 bind control source-interface GigabitEthernet2 no pass-thru content custom-sdp voice class uri 100 sip host ipv4:198.18.133.3 voice class uri 200 sip pattern dtg=フセイン1076.lgu ダイヤルピア ボイス 101 voip の説明 発信ダイヤルピア から IP PSTN 宛先パターン BAD.BAD セッション プロトコル sipv2 セッション ターゲット ipv4:198.18.133.3 voice-class codec 99 voice-class sip tenant 100 dtmf-relay rtp-nte no vad ダイヤルピア voice 201 voip の説明 発信ダイヤルピア から Webex Calling の宛先パターン bad.bad セッション プロトコル sipv2 セッション target sip-server voice-class codec 99 voice-class stun-usage 200 voice-class sip localhost voice-class sip tenant 200 dtmf-relay rtp-nte srtp no vad voice class dpg 100 の説明 着信 WebexCalling(DP200) から IP PSTN(DP101) ダイヤルピア 101 の基本設定 1 音声クラス dpg 200 の説明 着信 IP PSTN(DP100) から Webex Calling(DP201) ダイヤルピア 201 の基本設定 1 ダイヤルピア voice 100 voip desription IP PSTN セッション プロトコル sipv2 宛先 dpg 200 着信 uri via 100 voice-class codec 99 voice-class stun-usage 200 voice-class sip tenant 200 dtmf-relay rtp

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-1#冗長性アプリケーショングループ 1 グループ ID:1 グループ名:LocalGateway-HA 管理状態: シャットダウンなし 集約運用状態: Up My Role: Standby Peer Role: ACTIVE Peer Presence: Yes Peer Comm: Yes Peer Progression Started: Yes RF Domain: btob-one RF state: STANDBY HOT Peer RF state: ACTIVE VCUBE-1#sip-ua 登録ステータスを表示する VCUBE-1#

 VCUBE-2#show redundancy application group 1 グループ ID:1 グループ名:LocalGateway-HA 管理状態: シャットダウンなし 集約運用状態: Up My Role: ACTIVE Peer Role: STATUS Peer Presence: Yes Peer Comm: Yes Peer Progression Started: Yes RF Domain: btob-one RF state: ACTIVE Peer RF state: STANDBY HOT VCUBE-2#show sip-ua register status Tenant: 200 --------------------登録者インデックス1 --------------------- 回線ピアの期限が切れる (秒) レグサバイバル P-Associ-URI ============================== ====================== ============= Hussain5091_LGU-1 48 はい 通常の VCUBE-2#

上記の出力から、VCUBE-2 は Webex Calling アクセス SBC への登録を維持するアクティブ LGW であり、「show sip-ua 登録ステータス」の出力は VCUBE-1 では空白です。

3

VCUBE-1 で次のデバッグを有効にします

 VCUBE-1#debug ccsip non-call SIP アウトオブダイアログ トレースが有効になっています VCUBE-1#debug ccsip info SIP 通話情報トレースが有効になっています VCUBE-1#debug ccsip message

4

この場合、アクティブ LGW、VCUBE-2 で次のコマンドを実行してフェールオーバーをシミュレートします。

 VCUBE-2#冗長性アプリケーション再読み込みグループ 1 自分

アクティブからスタンバイ LGW への切り替えは、上記に一覧表示されている CLI に加えて、以下のシナリオで発生します。

  • アクティブ ルーターのリロード時

  • アクティブなルーターの電源が再投入される時

  • トラッキングが有効になっているアクティブなルーターの RG 構成されたインターフェイスがシャットダウンされる時

5

VCUBE-1 が Webex Calling アクセス SBC に登録されているかどうかを確認します。VCUBE-2 は今すぐにリロードされます。

 VCUBE-1#sip-ua 登録ステータスのテナントを表示: 200 --------------------登録者インデックス1 --------------------- 回線ピアの期限が切れる (秒) レグサバイバル P-Associ-URI ============================== ===================== ============= Hussain5091_LGU -1 56 YES NORMAL VCUBE-1#

VCUBE-1 がアクティブ LGW になりました。

6

仮想 IP を通じて SIP REGISTER を Webex Calling に送信し、200 OK を受信する VCUBE-1 に関連するデバッグ ログを確認してください。

 VCUBE-1#show ログ Jan 9 18:37:24.769: %RG_MEDIA-3-TIMEREXPIRED: RG id 1 Hello Time Expired. 1 月 9 日 18:37:24.771: %RG_PROTCOL-5-ROLECHANGE: RG ID 1 ロールがスタンバイからアクティブ 1 月 9 日 18:37:24.783: %VOICE_HA-2-SWITCHOVER_IND: 切り替え、スタンバイ_ホットからアクティブ状態へ。1 月 9 日 18:37:24.783: //-1/xxxxxxxxxxxx/SIP/Info/info/4096/sip_ha_notify_active_role_event: アクティブ ロール イベント通知を受信しました。1 月 9 日 18:37:25.758: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:送信日時: REGISTER sip: 40462196.cisco-bcld.com:5061 SIP/2.0 Via: SIP/2.0/TLS 198.18.1.228:5061;branch=z9hG4bK0374 から: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189 宛先: <sip:Hussain5091_LGU@40462196.cisco-bcld.com> 日付: Thu, 09 Jan 2020 18:37:24 GMT Call-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97 User-Agent: Cisco-SIPGateway/IOS-16.12.02 Max-Forwards: 70 Timestamp: 1578595044 CSeq: 2 登録連絡先: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls> 有効期限: 240 Supported: path Content-Length: 0 

1 月 9 日 18:37:25.995: //-1/000000000000/SIP/Msg/ccsipDisplayMsg:Received: SIP/2.0 401 Unauthorized Via: SIP/2.0/TLS 198.18.1.228:5061;received=173.38.218.1;branch=z9hG4bK0374;rport=4742 から: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189 宛先: <sip:Hussain5091_LGU@40462196.cisco-bcld.com>;tag=SD1u8bd99-1324701502-1578595045969 日付: Thu, 09 Jan 2020 18:37:24 GMT Call-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97 Timestamp: 1578595044 CSeq: 2 REGISTER WWW-Authenticate; DIGEST realm="BroadWorks",qop="auth",nonce="BroadWorksXk572qd01Ti58zliBW",algorithm=MD5 Content-Length: 0 

1 月 9 日 18:37:26.000: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:送信日時: REGISTER sip:40462196.cisco-bcld.com:5061 SIP/2.0 Via: SIP/2.0/TLS 198.18.1.228:5061;branch=z9hG4bK16DC から: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189 宛先: <sip:Hussain5091_LGU@40462196.cisco-bcld.com> 日付: Thu, 09 Jan 2020 18:37:25 GMT Call-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97 User-Agent:Cisco-SIPGateway/IOS-16.12.02 Max-Forwards: 70 Timestamp: 1578595045 CSeq: 3 登録連絡先: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls> 有効期限: 240 Supported: path Authorization: ダイジェスト username="Hussain1076_LGU",realm="BroadWorks",uri="sips:40462196.cisco-bcld.com:5061",response="b6145274056437b9c07f7ecc08ebdb02",nonce="BroadWorksXk572qd01Ti58z1iBW",cnonce="3E0E2C4D",qop=auth,algorithm=MD5,nc=00000001 コンテンツの長さ: 0 

1 月 9 日 18:37:26.190: //1/000000000000/SIP/Msg/ccsipDisplayMsg:Received: SIP/2.0 200 OK 経由: SIP/2.0/TLS 198.18.1.228:5061;received=173.38.218.1;branch=z9hG4bK16DC;rport=4742 から: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189 宛先: <sip:Hussain5091_LGU@40462196.cisco-bcld.com>;tag=SD1u8bd99-1897486570-1578595-46184 コール ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97 Timestamp: 1578595045 CSeq: 3 登録連絡先: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls>;expires=120;q=0.5 Allow-Events: call-info,line-seize,dialog,message-summary,as-feature-event,x-broadworks-hoteling,x-broadworks-call-center-status,conference Content-Length: 0

Webex Calling に Unified CM を構成する

ローカル ゲートウェイへトランクするための SIP トランク セキュリティ プロファイルを構成する

ローカル ゲートウェイと PSTN ゲートウェイが同じデバイス上に存在する場合、Unified CM を有効にして、同じデバイスから発信された 2 個の異なるトラフィックの種類 (Webex と PSTN のコール) を区別し、これらのコール タイプに対して差別化されたクラスのサービスを適用する必要があります。この差別化されたコール処理は、Unified CM および結合されたローカル ゲートウェイと PSTN ゲートウェイ デバイスの 2 つのトランクをプロビジョニングすることで行われます。これは、2 つのトランクに異なる SIP リスニング ポートを必要とします。

次の設定でローカル ゲートウェイ トランクの専用の SIP トランク セキュリティ プロファイルを作成します。

設定値
名前固有の名前 (Webex など)
説明Webex SIP トランク セキュリティ プロファイルなどの意味のある説明
着信ポートWebex 間のトラフィックでは、ローカル ゲートウェイ構成で使用されるポートと一致する必要があります。5065

ローカル ゲートウェイ トランクの SIP プロファイルを構成する

次の設定でローカル ゲートウェイ トランク用の専用の SIP プロファイルを作成します。

設定値
名前固有の名前 (Webex など)
説明Webex SIP プロファイルなどの意味のある説明
オプションの Ping を有効にして、サービス タイプ「なし (デフォルト)」のトランクの宛先ステータスをモニタします。選択

Webex からのコールのコール検索スペースを作成する

次の設定で Webex から発信されたコールのためのコール検索スペースを作成します。

設定値
名前固有の名前 (Webex など)
説明Webex Calling 検索スペースなどの意味のある説明
選択済みパーティション:

DN (+E.164 ディレクトリ番号)

ESN (サイト間ダイヤル)

PSTNInternational (PSTN アクセス)

onNetRemote (GDPR 学習先)

最後のパーティション onNetRemote は、Intercluster Lookup Service (ILS) または Global Dialplan Replication (GDPR) を使用して、Unified CM クラスター間でルーティング情報が交換されるマルチクラスター環境でのみ使用されます。

Webex 間で SIP トランクを構成する

次の設定を使用して、ローカル ゲートウェイ経由での Webex 間のコールに SIP トランクを作成します。

設定値
デバイス情報
DeviceName一意の名前 (Webex など)
説明Webex SIP トランクなどの意味のある説明
すべてのアクティブな Unified CM ノード上で実行する選択
着信コール
コール検索スペース以前に定義されたコール検索スペース:Webex
AAR コール検索スペース PSTN ルート パターンへのアクセス権のみを持つコール検索スペース: PSTNReroute
SIP 情報
接続先アドレスローカル ゲートウェイ CUBE の IP アドレス
移動先ポート5060
SIP トランク セキュリティ プロファイル定義済み:Webex
SIP プロファイル定義済み:Webex

Webex のルート グループを構成する

次の設定でルート グループを作成します。

設定値
ルート グループ情報
ルート グループ名一意の名前 (Webex など)
選択したデバイス以前に構成された SIP トランク:Webex

Webex のルート リストを構成する

次の設定でルート リストを作成します。

設定値
ルート リスト情報
名前一意の名前 (R_LWebex など)
説明Webex のルート リストなど、意味のある説明
すべてのアクティブな Unified CM ノード上で実行する選択
ルート リスト メンバー情報
選択したグループ以前に定義されたルート グループのみ:Webex

Webex の移動先のパーティションを作成する

次の設定で Webex の移動先のパーティションを作成します。

設定値
ルート リスト情報
名前一意の名前 (Webex など)
説明Webex パーティションなどの意味のある説明

次にやる必要

このパーティションは、Webex の宛先にアクセスする必要があるすべてのコール検索スペースに追加してください。このパーティションは、PSTN から Webex への発信がルーティングされるように、PSTN トランクの着信コール検索スペースとして使用されるコール検索スペースに特に追加する必要があります。

Webex の移動先のルート パターンを構成する

次の設定で Webex の各 DID 範囲のルート パターンを構成します。

設定値
ルートパターン「\」が頭文字にある Webex で DID 範囲のフル +E.164 パターン例: \+140855501XX
ルート パーティションWebex
ゲートウェイ/ルート リストRLWebex_
緊急の優先事項選択

Webex の簡略サイト間ダイヤル正規化を構成する

短縮されたサイト間ダイヤルが Webex に必要な場合は、Webex の各 ESB 範囲にダイヤル正規化パターンを設定します。

設定値
翻訳パターンWebex の ESN 範囲の ESB パターン。例:80121XX
パーティションWebex
説明Webex 正規化パターンなどの意味のある説明
発信者のコール検索スペースを使用する選択
緊急の優先事項選択
後続ホップでの連続桁のタイムアウトを待たない選択
着信側トランスフォーム マスク番号を + E.164 に正規化するマスク。例: +140855501XX

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）] フィールドに入力された名前です。

実際の例を見てみましょう。Control Hub でユーザーのモニタリング設定を管理する方法については、このビデオ デモンストレーショ ンをご覧ください。

ユーザーのコール ブリッジ警告トーンを有効にする

開始する前に

コール ブリッジを呼び出すには、共有回線を設定する必要があります。コール ブリッジの警告トーンが再生される前に、共有回線を設定す る方法を参照してください。
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

[保存] をクリックします。

ユーザは、ユーザ ハブから使用するホテリング ホストを検索し、検索することもできます。詳細については、「どこからでも通話プロファイルにアクセスする」を参照してください。

実際の例を見てみましょう。Control Hub でホテリングを設定する方法については、このビデオ デモンストレーショ ンをご覧ください。

Webex Calling の導入傾向と使用レポート

通話レポートを表示する

Control Hub の [アナリティクス] ページを使用して、ユーザーがどのように Webex Calling と Webex アプリ (エンゲージメント) を使用しているか、また、通話のメディア エクスペリエンスの質について洞察を得ることができます。Webex Calling 分析にアクセスするには、Control Hub にサインインし、[アナリティクス] に移動し、[Calling] タブを選択します。

1

詳細な通話履歴レポートについては、Control Hub にサインインし、[アナリティクス] > [通話] に移動します。

2

[通話履歴の詳細] を選択します。

専用インスタンスを使用する通話の詳細については、「専用インスタンスの分析」を参照してください。

3

メディア品質データにアクセスするには、Control Hub にサインインし、[アナリティクス] に移動し、[Calling] を選択します。

詳細については、「クラウド コラボレーション ポートフォリオのためのアナリティクス」を参照してください。

ローカル ゲートウェイとして CUBE の高可用性を実装

基礎

前提条件

Webex Calling のローカル ゲートウェイとして CUBE HA を展開する前に、以下の概念を深く理解するようにしてください。

この記事で提供される構成ガイドラインは、既存の音声構成が設定されていない専用のローカル ゲートウェイ プラットフォームが使用されていることを前提としています。既存の 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 設定ガイドを次に示します。

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

インターフェイスのステータスを追跡するために、グローバル レベルでインターフェイス トラッキングを構成します。

conf t
 track 1 interface GigabitEthernet1 line-protocol
 track 2 interface GigabitEthernet2 line-protocol
 exit 

VCUBE-1#conf t

VCUBE-1(config)#track 1 インターフェイス GigabitEthernet1 回線プロトコル

VCUBE-1(config-track)#トラック 2 インターフェイス GigabitEthernet2 回線プロトコル

VCUBE-1(config-track)#終了

VCUBE-2#conf t

VCUBE-2(config)#track 1 インターフェイス GigabitEthernet1 回線プロトコル

VCUBE-2(config-track)#トラック 2 インターフェイス GigabitEthernet2 回線プロトコル

VCUBE-2(config-track)#終了

トラッキング CLI は、トラフィック インターフェイスがダウンした後、アクティブ ルートがアクティブな役割を果たすように、RG 内で音声トラフィックインターフェイスの状態を追跡するために使用されます。

2

アプリケーション冗長性サブモード下の VoIP HA で使用する RG を構成します。

redundancy
  application redundancy
   group 1
    name LocalGateway-HA
    priority 100 failover threshold 75
    control GigabitEthernet3 protocol 1
    data GigabitEthernet3
    timers delay 30 reload 60
    track 1 shutdown
    track 2 shutdown
    exit
   protocol 1
    timers hellotime 3 holdtime 10
   exit
  exit
 exit 

VCUBE-1(config)#冗長性

VCUBE-1(config-red)#アプリケーション冗長性

VCUBE-1(config-red-app)#グループ 1

VCUBE-1(config-red-app-grp)#name LocalGateway-HA

VCUBE-1(config-red-app-grp)#priority 100 フェールオーバーしきい値 75

VCUBE-1(config-red-app-grp)#control GigabitEthernet3 プロトコル 1

VCUBE-1(config-red-app-grp)#データ GigabitEthernet3

VCUBE-1(config-red-app-grp)#タイマー遅延 30 再ロード 60

VCUBE-1(config-red-app-grp)#トラック 1 シャットダウン

VCUBE-1(config-red-app-grp)#トラック 2 シャットダウン

VCUBE-1(config-red-app-grp)#exit

VCUBE-1(config-red-app)#プロトコル 1

VCUBE-1(config-red-app-prtcl)#タイマー hellotime 3 holdtime 10

VCUBE-1(config-red-app-prtcl)#exit

VCUBE-1(config-red-app)#exit

VCUBE-1(config-red)#終了

VCUBE-1(config)#

VCUBE-2(config)#冗長性

VCUBE-2(config-red)#アプリケーション冗長性

VCUBE-2(config-red-app)#グループ 1

VCUBE-2(config-red-app-grp)#name LocalGateway-HA

VCUBE-2(config-red-app-grp)#priority 100 フェールオーバーしきい値 75

VCUBE-2(config-red-app-grp)#control GigabitEthernet3 プロトコル 1

VCUBE-1(config-red-app-grp)#データ GigabitEthernet3

VCUBE-2(config-red-app-grp)#タイマー遅延 30 再ロード 60

VCUBE-2(config-red-app-grp)#トラック 1 シャットダウン

VCUBE-2(config-red-app-grp)#トラック 2 シャットダウン

VCUBE-2(config-red-app-grp)#exit

VCUBE-2(config-red-app)#プロトコル 1

VCUBE-2(config-red-app-prtcl)#タイマー hellotime 3 holdtime 10

VCUBE-2(config-red-app-prtcl)#exit

VCUBE-2(config-red-app)#exit

VCUBE-2(config-red)#終了

VCUBE-2(config)#

この構成で使用されるフィールドの説明を次に示します。

  • 冗長性: 冗長モードに入る

  • アプリケーション冗長性: アプリケーション冗長設定モードに入ります

  • group—冗長性アプリケーション グループ設定モードに入ります

  • name LocalGateway-HA—RG グループの名前を定義します。

  • 優先度 100 フェールオーバーしきい値 75: RG の初期優先順位とフェールオーバーしきい値を指定します。

  • タイマー遅延 30 reload 60: 遅延と再読み込みに対して 2 回設定します。

    • インターフェイスが起動した後、RG グループの初期設定と役割のネゴシエーションの遅延時間を示す遅延タイマーです。デフォルトは 30 秒です。範囲は 0-10000 秒です

    • Reload—これは、リロード後の RG グループ初期設定と役割ネゴシエーションの遅延時間です。デフォルトは 60 秒です。範囲は 0-10000 秒です

    • デフォルトのタイマーが推奨されていますが、これらのタイマーは、ネットワークのルーティングが安定した時点の後、RG プロトコルのネゴシエーションが行われることを保証するために、ルーターの起動/再読み込み中に発生する可能性がある追加のネットワーク集約遅延に合わせて調整される場合があります。たとえば、フェールオーバー後に、新しいスタンバイに最大 20 秒間かかり、新しいアクティブから最初の RG HELLO パケットを確認する場合は、この遅延を考慮して、最初の RG HELLO パケットを「タイマー遅延 60 リロード 120」に調整する必要があります。

  • control GigabitEthernet3 protocol 1—2 つの CUBE 間でキープアライブとハローメッセージを交換するために使用されるインターフェイスを構成し、コントロール インターフェイスに接続されるプロトコル インスタンスを指定し、冗長アプリケーション プロトコル構成モードに入ります

  • data GigabitEthernet3—データ トラフィックのチェックポイントに使用されるインターフェイスを設定します

  • track - インターフェイスの RG グループ トラッキング

  • プロトコル 1—コントロール インターフェイスに接続されるプロトコル インスタンスを指定し、冗長性アプリケーション プロトコル設定モードに入ります。

  • タイマー hellotime 3 holdtime 10: hellotime と holdtime の 2 つのタイマーを設定します。

    • Hellotime— 連続する hello メッセージの間隔 (デフォルトで 3 秒)。範囲は 250 ミリ秒から 254 秒です

    • Holdtime — Hello メッセージの受信と送信ルーターが失敗した推定の間隔。この継続時間は、hello time (デフォルトの 10 秒より長くする必要があります) 以上である必要があります。範囲は 750 ミリ秒から 255 秒です

      Holdtime タイマーを hellotime タイマーの最低 3 倍の値に設定することをお勧めします。

3

CUBE アプリケーションのボックス間の冗長性を有効にします。[voice service voip] の以前の手順から RG を構成します。これにより、CUBE アプリケーションは冗長性プロセスをコントロールすることができます。

voice service voip
   redundancy-group 1
   exit

VCUBE-1(config)#音声サービス voip

VCUBE-1(config-voi-serv)#redundancy-group 1

 % Created RG 1 association with Voice B2B HA; reload the router for the new configuration to take effect 

VCUBE-1(config-voi-serv)# 終了

VCUBE-2(config)#音声サービス voip

VCUBE-2(config-voi-serv)#redundancy-group 1

 % Created RG 1 association with Voice B2B HA; reload the router for the new configuration to take effect 

VCUBE-2(config-voi-serv)# 終了

redundancy-group 1: このコマンドを追加および削除するには、更新された構成を有効にするために再読み込みが必要です。すべての構成が適用された後で、プラットフォームを再読み込みします。

4

以下に示すように、Gig1 と Gig2 インターフェイスをそれぞれの仮想 IP で構成し、冗長性インターフェイス識別子 (rii) を適用します。

VCUBE-1(config)#インターフェイス GigabitEthernet1

VCUBE-1(config-if)# 冗長性 rii 1

VCUBE-1(config-if)# 冗長グループ 1 ip 198.18.1.228 限定

VCUBE-1(config-if)# 終了

VCUBE-1(config)#

VCUBE-1(config)#インターフェイス GigabitEthernet2

VCUBE-1(config-if)# 冗長性 rii 2

VCUBE-1(config-if)# 冗長グループ 1 ip 198.18.133.228 専用

VCUBE-1(config-if)# 終了

VCUBE-2(config)#インターフェイス GigabitEthernet1

VCUBE-2(config-if)# 冗長性 rii 1

VCUBE-2(config-if)# 冗長グループ 1 ip 198.18.1.228 限定

VCUBE-2(config-if)# 終了

VCUBE-2(config)#

VCUBE-2(config)#インターフェイス GigabitEthernet2

VCUBE-2(config-if)# 冗長性 rii 2

VCUBE-2(config-if)# 冗長グループ 1 ip 198.18.133.228 専用

VCUBE-v(config-if)# 終了

この構成で使用されるフィールドの説明を次に示します。

  • redundancy rii: 冗長グループの冗長インターフェイス ID を設定します。仮想 MAC (VMAC) アドレスを生成するために必要です。同じ VIP を持つ各ルーター (アクティブ/スタンバイ) のインターフェイスで同じ rii ID 値を使用する必要があります。

    同じ LAN に複数の B2B ペアがある場合、各ペアはそれぞれのインターフェイスに固有の RII ID を持っている必要があります（衝突を防ぐため）。「冗長性アプリケーショングループをすべて表示」は、正しいローカルおよびピア情報を示す必要があります。

  • 冗長グループ 1: 上記のステップ 2 で作成された冗長グループとインターフェイスを関連付けます。RG グループ、およびこの物理インターフェイスに割り当てられた VIP を構成します。

    冗長性のために別のインターフェイスを使用することが必須です。つまり、音声トラフィックに使用されるインターフェイスは、上記の手順 2 で指定したコントロールとデータ インターフェイスとして使用できません。この例では、RG コントロール/データにギガビット インターフェイス 3 が使用されています。

5

最初の CUBE 構成を保存し、再読み込みします。

最後にリロードするプラットフォームは常にスタンバイです。

VCUBE-1#wr

 構成を検証しています... 

 [OK] 

VCUBE-1#再読み込み

 再読み込みを続行しますか? [確認]

VCUBE-1 が完全に起動したら、 VCUBE-2 の構成を保存し、再読み込みします。

VCUBE-2#wr

 構成を検証しています... 

 [OK] 

VCUBE-2#再読み込み

 再読み込みを続行しますか? [確認]

6

ボックス間の構成が期待どおりに機能していることを確認します。関連する出力は太字で強調表示されます。

VCUBE-2 を最後にリロードし、設計上の考慮事項に従います。最後にリロードするプラットフォームは常に [スタンバイ] 状態です。 

 VCUBE-1#冗長性アプリケーショングループのすべての表示 障害状態 グループ 1 の情報: Runtime priority: [100] RG Faults RG State: UP. Total # of switchovers due to faults: 0 Total # of down/up state changes due to faults: 0 Group ID:1 Group Name:LocalGateway-HA Administrative State: No Shutdown Aggregate operational state: Up My Role: ACTIVE Peer Role: STANDBY Peer Presence: Yes Peer Comm: Yes Peer Progression Started: Yes RF Domain: btob-one RF state: ACTIVE Peer RF state: STANDBY HOT RG Protocol RG 1 ------------------ Role: Active Negotiation: Enabled Priority: 100 Protocol state: Active Ctrl Intf(s) state: Up Active Peer: Local Standby Peer: address 10.1.1.2, priority 100, intf Gi3 Log counters: role change to active: 1 role change to standby: 1 disable events: rg down state 0, rg shut 0 ctrl intf events: 上 1、下 0、admin_down 0 イベントの再読み込み: local request 0, peer request 0 RG Media Context for RG 1 -------------------------- Ctx State: Active Protocol ID: 1 Media type: Default Control Interface: GigabitEthernet3 Current Hello timer: 3000 Configured Hello timer: 3000, Hold timer: 10000 Peer Hello timer: 3000, Peer Hold timer: 10000 Stats: Pkts 1509, Bytes 93558, HA Seq 0, Seq Number 1509, Pkt Loss 0 Authentication not configured Authentication Failure: 0 Reload Peer: TX 0, RX 0 Resign: TX 0, RX 0 Standy Peer: Present. Hold Timer: 10000 Pkts 61、Bytes 2074、HA Seq 0、Seq Number 69、Pkt Loss 0 VCUBE-1#
 VCUBE-2#冗長アプリケーション グループを表示 デフォルト状態 グループ 1 情報: Runtime priority: [100] RG Faults RG State: UP. Total # of switchovers due to faults: 0 Total # of down/up state changes due to faults: 0 Group ID:1 Group Name:LocalGateway-HA Administrative State: No Shutdown Aggregate operational state: Up My Role: STANDBY Peer Role: ACTIVE Peer Presence: Yes Peer Comm: Yes Peer Progression Started: Yes RF Domain: btob-one RF state: ACTIVE Peer RF state: STANDBY HOT RG Protocol RG 1 ------------------ Role: Active Negotiation: Enabled Priority: 100 Protocol state: Active Ctrl Intf(s) state: Up Active Peer: address 10.1.1.2, priority 100, intf Gi3 Standby Peer: Local Log counters: role change to active: 1 role change to standby: 1 disable events: rg down state 0, rg shut 0 ctrl intf events: 上 1、下 0、admin_down 0 イベントの再読み込み: local request 0, peer request 0 RG Media Context for RG 1 -------------------------- Ctx State: Active Protocol ID: 1 Media type: Default Control Interface: GigabitEthernet3 Current Hello timer: 3000 Configured Hello timer: 3000, Hold timer: 10000 Peer Hello timer: 3000, Peer Hold timer: 10000 Stats: Pkts 1509, Bytes 93558, HA Seq 0, Seq Number 1509, Pkt Loss 0 Authentication not configured Authentication Failure: 0 Reload Peer: TX 0, RX 0 Resign: TX 0, RX 0 Standy Peer: Present. Hold Timer: 10000
            Pkts 61, Bytes 2074, HA Seq 0, Seq Number 69, Pkt Loss 0

VCUBE-2#

両方の CUBE でローカル ゲートウェイを構成する

この例の構成では、Control Hub から以下のトランク情報を使用して、VCUBE-1、VCUBE-2 の両方のプラットフォームでローカルゲートウェイを構成しています。この設定のユーザー名とパスワードは以下のとおりです。

  • ユーザー名:フセイン1076_LGU

  • パスワード:lOV12MEaZx

1

クレデンシャルまたは共有秘密で使用する前に、以下のコマンドを使用して、設定キーがパスワードに対して作成されていることを確認してください。Type 6 パスワードは、AES 暗号化とこのユーザー定義の設定キーを使用して暗号化されます。 

 LocalGateway#conf t LocalGateway(config)#key config-key password-encrypt Password123 LocalGateway(config)#password encryption aes

これは、上に表示されている Control Hub のパラメーターに基づき、両方のプラットフォームに適用し、保存し、リロードするローカ ルゲートウェイの構成です。Control Hub からの SIP ダイジェスト資格情報は、太字でハイライトされます。

 Configure terminal crypto pki trustpoint dummyTp revocation-check crl exit sip-ua crypto signaling default trustpoint dummyTp cn-san-validate server transport tcp tls v1.2 end configure terminal crypto pki trustpool import clean url http://www.cisco.com/security/pki/trs/ios_core.p7b end configure terminal voice service voip ip address trusted list ipv4 x.x.x.x.x y.y.y exit allow-connections sip to sip media statistics media bulk-stats no supplementary-service sip refer no supplementary-service sip handle-replaces fax protocol pass-through g711ulaw stun stun flowdata agent-id 1 boot-count 4 stun flowdata shared-secret 0 Password123! sip g729 annexb-all early-offer forced end configure terminal voice class sip-profiles 200 rule 9 request ANY sip-header SIP-Req-URI modify "sips:(.*)" "sip:\1" rule 10 request ANY sip-header modify "" "" ";otgフセイン1076_lgu>" rule 30 リクエスト すべての sip-header P-Asserted-Identity 変更 "sips:(.*)" "sip:\1" 音声クラス コーデック 99 コーデックの設定 1 g711ulaw コーデックの設定 2 g711ulaw 終了音声クラス srtp-crypto 200 crypto 1 AES_センチメートル_128_hmac_社 1_80 exit voice class stun-usage 200 stun-usage firewall-traversal flowdata exit voice class tenant 200 レジストラ dns:40462196.cisco-bcld.com スキーム sips の有効期限が 240 更新比 50 tcp tls クレデンシャル番号 フセイン5091_ルグ ユーザ名 Hussain1076_LGU パスワード 0 lOV12MEaZx レルム Broadworks 認証ユーザー名 フセイン5091_ルグ パスワード 0 lOV12MEaZx レルム BroadWorks 認証ユーザー名 フセイン5091_ルグ パスワード 0 lOV12MEaZx レルム 40462196.cisco-bcld.com remote-party-id sip-server がありません dns:40462196.cisco-bcld.com connection-reuse srtp-crypto 200 session transport tcp tls url sips error-passthru asserted-id pai bind control source-interface GigabitEthernet1 bind media source-interface GigabitEthernet1 pass-thru content custom-sdp sip-profiles 200 outbound-proxy dns:la01.sipconnect-us10.cisco-bcld.com privacy-policy passthru voice class tenant 100 session transport udp url sip error-passthru bind control source-interface GigabitEthernet2 bind media source-interface GigabitEthernet2 no pass-thru content custom-sdp voice class tenant 300 bind control source-interface GigabitEthernet2 no pass-thru content custom-sdp voice class uri 100 sip host ipv4:198.18.133.3 voice class uri 200 sip pattern dtg=フセイン1076.lgu ダイヤルピア ボイス 101 voip の説明 発信ダイヤルピア から IP PSTN 宛先パターン BAD.BAD セッション プロトコル sipv2 セッション ターゲット ipv4:198.18.133.3 voice-class codec 99 voice-class sip tenant 100 dtmf-relay rtp-nte no vad ダイヤルピア voice 201 voip の説明 発信ダイヤルピア から Webex Calling の宛先パターン bad.bad セッション プロトコル sipv2 セッション target sip-server voice-class codec 99 voice-class stun-usage 200 voice-class sip localhost voice-class sip tenant 200 dtmf-relay rtp-nte srtp no vad voice class dpg 100 の説明 着信 WebexCalling(DP200) から IP PSTN(DP101) ダイヤルピア 101 の基本設定 1 音声クラス dpg 200 の説明 着信 IP PSTN(DP100) から Webex Calling(DP201) ダイヤルピア 201 の基本設定 1 ダイヤルピア voice 100 voip desription IP PSTN セッション プロトコル sipv2 宛先 dpg 200 着信 uri via 100 voice-class codec 99 voice-class stun-usage 200 voice-class sip tenant 200 dtmf-relay rtp

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-1#冗長性アプリケーショングループ 1 グループ ID:1 グループ名:LocalGateway-HA 管理状態: シャットダウンなし 集約運用状態: Up My Role: Standby Peer Role: ACTIVE Peer Presence: Yes Peer Comm: Yes Peer Progression Started: Yes RF Domain: btob-one RF state: STANDBY HOT Peer RF state: ACTIVE VCUBE-1#sip-ua 登録ステータスを表示する VCUBE-1#

 VCUBE-2#show redundancy application group 1 グループ ID:1 グループ名:LocalGateway-HA 管理状態: シャットダウンなし 集約運用状態: Up My Role: ACTIVE Peer Role: STATUS Peer Presence: Yes Peer Comm: Yes Peer Progression Started: Yes RF Domain: btob-one RF state: ACTIVE Peer RF state: STANDBY HOT VCUBE-2#show sip-ua register status Tenant: 200 --------------------登録者インデックス1 --------------------- 回線ピアの期限が切れる (秒) レグサバイバル P-Associ-URI ============================== ====================== ============= Hussain5091_LGU-1 48 はい 通常の VCUBE-2#

上記の出力から、VCUBE-2 は Webex Calling アクセス SBC への登録を維持するアクティブ LGW であり、「show sip-ua 登録ステータス」の出力は VCUBE-1 では空白です。

3

VCUBE-1 で次のデバッグを有効にします

 VCUBE-1#debug ccsip non-call SIP アウトオブダイアログ トレースが有効になっています VCUBE-1#debug ccsip info SIP 通話情報トレースが有効になっています VCUBE-1#debug ccsip message

4

この場合、アクティブ LGW、VCUBE-2 で次のコマンドを実行してフェールオーバーをシミュレートします。

 VCUBE-2#冗長性アプリケーション再読み込みグループ 1 自分

アクティブからスタンバイ LGW への切り替えは、上記に一覧表示されている CLI に加えて、以下のシナリオで発生します。

  • アクティブ ルーターのリロード時

  • アクティブなルーターの電源が再投入される時

  • トラッキングが有効になっているアクティブなルーターの RG 構成されたインターフェイスがシャットダウンされる時

5

VCUBE-1 が Webex Calling アクセス SBC に登録されているかどうかを確認します。VCUBE-2 は今すぐにリロードされます。

 VCUBE-1#sip-ua 登録ステータスのテナントを表示: 200 --------------------登録者インデックス1 --------------------- 回線ピアの期限が切れる (秒) レグサバイバル P-Associ-URI ============================== ===================== ============= Hussain5091_LGU -1 56 YES NORMAL VCUBE-1#

VCUBE-1 がアクティブ LGW になりました。

6

仮想 IP を通じて SIP REGISTER を Webex Calling に送信し、200 OK を受信する VCUBE-1 に関連するデバッグ ログを確認してください。

 VCUBE-1#show ログ Jan 9 18:37:24.769: %RG_MEDIA-3-TIMEREXPIRED: RG id 1 Hello Time Expired. 1 月 9 日 18:37:24.771: %RG_PROTCOL-5-ROLECHANGE: RG ID 1 ロールがスタンバイからアクティブ 1 月 9 日 18:37:24.783: %VOICE_HA-2-SWITCHOVER_IND: 切り替え、スタンバイ_ホットからアクティブ状態へ。1 月 9 日 18:37:24.783: //-1/xxxxxxxxxxxx/SIP/Info/info/4096/sip_ha_notify_active_role_event: アクティブ ロール イベント通知を受信しました。1 月 9 日 18:37:25.758: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:送信日時: REGISTER sip: 40462196.cisco-bcld.com:5061 SIP/2.0 Via: SIP/2.0/TLS 198.18.1.228:5061;branch=z9hG4bK0374 から: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189 宛先: <sip:Hussain5091_LGU@40462196.cisco-bcld.com> 日付: Thu, 09 Jan 2020 18:37:24 GMT Call-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97 User-Agent: Cisco-SIPGateway/IOS-16.12.02 Max-Forwards: 70 Timestamp: 1578595044 CSeq: 2 登録連絡先: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls> 有効期限: 240 Supported: path Content-Length: 0 

1 月 9 日 18:37:25.995: //-1/000000000000/SIP/Msg/ccsipDisplayMsg:Received: SIP/2.0 401 Unauthorized Via: SIP/2.0/TLS 198.18.1.228:5061;received=173.38.218.1;branch=z9hG4bK0374;rport=4742 から: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189 宛先: <sip:Hussain5091_LGU@40462196.cisco-bcld.com>;tag=SD1u8bd99-1324701502-1578595045969 日付: Thu, 09 Jan 2020 18:37:24 GMT Call-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97 Timestamp: 1578595044 CSeq: 2 REGISTER WWW-Authenticate; DIGEST realm="BroadWorks",qop="auth",nonce="BroadWorksXk572qd01Ti58zliBW",algorithm=MD5 Content-Length: 0 

1 月 9 日 18:37:26.000: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:送信日時: REGISTER sip:40462196.cisco-bcld.com:5061 SIP/2.0 Via: SIP/2.0/TLS 198.18.1.228:5061;branch=z9hG4bK16DC から: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189 宛先: <sip:Hussain5091_LGU@40462196.cisco-bcld.com> 日付: Thu, 09 Jan 2020 18:37:25 GMT Call-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97 User-Agent:Cisco-SIPGateway/IOS-16.12.02 Max-Forwards: 70 Timestamp: 1578595045 CSeq: 3 登録連絡先: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls> 有効期限: 240 Supported: path Authorization: ダイジェスト username="Hussain1076_LGU",realm="BroadWorks",uri="sips:40462196.cisco-bcld.com:5061",response="b6145274056437b9c07f7ecc08ebdb02",nonce="BroadWorksXk572qd01Ti58z1iBW",cnonce="3E0E2C4D",qop=auth,algorithm=MD5,nc=00000001 コンテンツの長さ: 0 

1 月 9 日 18:37:26.190: //1/000000000000/SIP/Msg/ccsipDisplayMsg:Received: SIP/2.0 200 OK 経由: SIP/2.0/TLS 198.18.1.228:5061;received=173.38.218.1;branch=z9hG4bK16DC;rport=4742 から: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189 宛先: <sip:Hussain5091_LGU@40462196.cisco-bcld.com>;tag=SD1u8bd99-1897486570-1578595-46184 コール ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97 Timestamp: 1578595045 CSeq: 3 登録連絡先: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls>;expires=120;q=0.5 Allow-Events: call-info,line-seize,dialog,message-summary,as-feature-event,x-broadworks-hoteling,x-broadworks-call-center-status,conference Content-Length: 0

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 の管理を一元化します。

表 1YAZ設定オプション 管理者の設定可能な機能

機能

説明

自動音声応答

セットアップ メニューと、応答サービス、ハント グループ、ボイスメール ボックスや実際のオペレーターなどへのルーティング機能によって、適切なあいさつを返すことができます。24 時間分のスケジュールを作成することができます。あるいは、営業時間内か外かに応じて、異なるオプションを使うこともできます。通話は、発信者の ID 属性に応じてルーティングすることによって、VIP リストを作成したり、特定の市外局番からの通話には対応を変えたりすることができます。

コール キュー

着信通話に応答できないときに、通話キューを設定できます。誰かがコールに応答できるまで、自動応答、ご案内のメッセージ、保留中の音楽を発信者に提供できます。

通話ピックアップ

コール ピックアップ グループを作成して、ユーザーが別のユーザーの通話に応答できるようにすることで、チームワークとコラボレーションを強化できます。ユーザーをコールピックアップグループに追加しておけば、グループメンバーが席を離れていたり、電話中だったりした場合、別のメンバーが電話に出ることができます。

コール パーク

コール パークをオンにすると、ユーザがコールを保留にし、別の電話からピックアップできます。

ハントグループ

以下のようなシナリオでは、ハント グループをセットアップするのがよいでしょう。

  • セールス チームは順番に転送を求めている可能性があります。着信が電話を鳴らしても応答が無かった場合、その通話はリスト中の次のエージェントへと転送されます。

  • サポートチームは最初の対応可能なエージェントが電話に応答できるように、電話が同時に鳴ることを希望する傾向があります。

ページング グループ

ユーザーが音声メッセージを個人、部署、チームに送信できるように、ページング グループを作成できます。誰かがメッセージをページング グループに送信するとき、グループのすべてのデバイスでメッセージが再生されます。

レセプショニスト クライアント

フルセットの通話管理オプション、大規模モニタリング、コール キュー、複数のディレクトリ オプションとビュー、Outlook との統合などを提供することにより、フロントオフィス担当者のニーズを満たします。
表 2. ユーザーの設定可能な機能

機能

説明

匿名コールの拒否

ユーザーはブロックされた発信者 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 で組織をセットアップできます。これらのすべてコンポーネントを同様にそこから管理できます。

パートナー:

パートナー サービス プロバイダーは、ブランドとマーケットを設定して、Webex Calling を顧客に販売できます。トライアルをセットアップして、顧客にサービスを展開し、顧客にオーダーを作成してプロビジョニングすることもできます。

サービス開始日時

Webex Calling が販売可能な国については、『Cisco Webex はどこで利用可能か』という記事の「Webex Calling」の見出しを参照してください。

Control Hub を体験する

Control Hub は、組織の管理、ユーザーの管理、サービスの割り当て、導入の傾向や通話品質の分析などを行うための、ウェブ ベースの単一のインターフェイスです。

Control Hub のインターフェイスの概要は、左側ナビゲーションメニュー、会社情報、通知、アプリ内ヘルプ、フィードバック、言語、サインアウトのハイライトとラベル付けです。

組織をセットアップして実行 するには、Control Hub にメール アドレスを入力して、Webex アプリ に参加する数人のユーザーを招待することを 推奨します。コールを含む、提供されるサービスを使用するようにユーザーを促し、彼らの満足度に関するフィードバックを提供することを求めます。準備が完了したら、いつでもユーザーを追加することができます。

Control Hub にアクセスするには最新の Google Chrome もしくは Mozilla Firefox のデスクトップ バージョンを使用されることを推奨します。モバイル デバイスのブラウザーやその他のデスクトップ ブラウザーを使用した場合、予期せぬ結果が生じる場合があります。

以下に示す情報を、組織がサービスをセットアップし始めた場合に期待できる事柄についての、大まかな概要として用いてください。詳細については、個々の章の、手順を追った説明を参照してください。

使い始める

パートナーがあなたのアカウントを作成すると、ウェルカム メールが届きます。Chrome または Firefox を使用し、[はじめに] リンクをクリックして、Control Hub にアクセスます。このリンクを使うと、管理者のメール アドレスで自動的にサインインすることができます。次に、管理者パスワードを作成するためのプロンプトが表示されます。

Control Hub セットアップの開始メールから、新しいパスワード画面を作成します。

トライアルのための初回ウィザード

パートナーがトライアルに登録した場合、Control Hub にサインインすると、セットアップウィザードが自動的に開始します。このウィザードでは、Webex Calling などのサービスで組織を立ち上げて稼働させるための基本設定を案内します。ウィザードのガイドを終えると、Calling の設定とその確認が完了します。

Control Hub の初回セットアップ ウィザード。

設定の確認

Control Hub がロードされると、設定を確認できます。

Control Hub の概要ページ。

ユーザーの追加

サービスをセットアップしたら、会社ディレクトリからユーザーを追加する準備ができます。[ユーザー] に進んで、[ユーザーの管理] をクリックします。

Control Hub でユーザー ポップアップ ウィンドウを管理します。

Microsoft Active Directory を使用している場合、まずディレクトリ同期を有効にしてからユーザーの追加方法を決定することをお勧めします。[次へ] をクリックし、指示に従って Cisco Directory Connector を設定します。

シングル サインオン (SSO) の設定

Webex アプリは基本認証を使用します。 SSO をセットアップして、ユーザーが Webex に保存され、管理される別のパスワードではなく、エンタープライズ クレデンシャルを使用してエンタープライズ ID プロバイダーで認証されるようにできます。

[設定] に移動し、[認証] までスクロールして、[変更] をクリックしてから、[サードパーティの ID プロバイダを統合させる] を選択します。

[サードパーティ プロバイダーを統合] オプションが選択されているシングル サインオン設定画面です。

サービスをユーザーに割り当てる

ユーザーが Webex アプリの使用を開始するために、追加したユーザーにサービス を割り当てる必要があります。

[ユーザー] に移動して、[ユーザーの管理] をクリックし、[CSV ファイルでユーザーをエクスポートおよびインポートする] を選択してから、[エクスポート] をクリックします。

ダウンロードしたファイルで、各ユーザーに割り当てるサービスに [True] を追加します。

Control Hub でユーザーにサービスを割り当てるための CSV ファイルの例。

完了したファイルをインポートし、[サービスの追加および削除] をクリックして、[提出] をクリックします。これで、コール機能を構成し、共通場所で共有できるデバイスを登録し、デバイスを登録してユーザーに関連付ける準備ができました。

ユーザーを支援する

これで、ユーザーを追加し、サービスを割り当て済みです。メッセージングとミーティングのために、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 展開を示しており、単一の場所または複数の場所のどちらの展開でも適用できます。

既存の IP PBX を使用しない Webex Calling の展開を示す図。

Webex Calling の宛先に一致しないすべてのコールについては、Webex Calling は処理の場所に割り当てられているローカル ゲートウェイにそれらのコールを送信します。ローカルゲートウェイは、Webex Calling から PSTN に送られるすべてのコールと、反対方向に PSTN から Webex Calling に送られるコールのルーティングを行います。

PSTN ゲートウェイは、ローカル ゲートウェイの専用プラットフォームまたは共存プラットフォームになります。次の図のように、この展開の専用の PSTN ゲートウェイのバリエーションをお勧めします。既存の PSTN ゲートウェイを Webex Calling のローカル ゲートウェイとして使用できない場合に使用できます。

既存の PSTN ゲートウェイを Webex Calling ローカル ゲートウェイとして使用できない場合に使用できる、推奨された PSTN ゲートウェイの展開オプションを示すイラスト。

共存型のローカル ゲートウェイの展開

ローカル ゲートウェイとして、ITSP に接続するために SIP トランクを使用する IP ベースのもの、または ISDN またはアナログ回路を使用する TDM ベースのものを使用できます。次の図は、ローカル ゲートウェイが PSTN GW/SBC と共存している場合の、Webex Calling の展開を示しています。

ローカル ゲートウェイが 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 の展開を示しています。

顧客が既存の 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 ゲートウェイを Webex Calling ローカル ゲートウェイとして使用できない場合に使用できる推奨オプション。

共存型 PSTN ゲートウェイ

この図は、ローカル ゲートウェイが PSTN ゲートウェイ/SBC と共存している場合の、Webex Calling と Unified CM の展開を示しています。

Webex Callingの 宛先に一致 しないすべての通話を、ロケーションWebex Calling割り当てられたローカル ゲートウェイにルーティングします。これには、PSTN の宛先と、Unified CM 内部の内線に向けたオンネット コールが含まれます。ローカルゲートウェイは、すべてのコールを Unified CM にルーティングします。その後、Unified CM は PSTN/SBC 機能が共存している ローカル ゲートウェイを通じて、コールをローカルに登録された電話または PSTN にルーティングします。

ローカル ゲートウェイが PSTN ゲートウェイ/SBC と共存する Unified CM を使用した Webex Calling の展開を示す図。

コール ルーティングの考慮点

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 ユーザーを示しています。

米国内の国番号をダイヤルする Webex Calling ユーザーの図です。

Unified CM は、構成済みのダイヤルプランに基づいて、発信先が電話帳としてプロビジョニングされている、ローカルに登録されたエンドポイントにルーティングします。このため、Unified CM のダイヤル プランは + E.164 番号のルーティングをサポートする必要があります。

Unified CM から Webex Calling へのコール

Unified CM から Webex Calling へのコール ルーティングを Unified CM で有効にするには、一連のルートをプロビジョニングして、Webex Calling での +E.１６４ プラン アドレスとエンタープライズ番号の組み合わせを定義する必要があります。

これらのルートを構成することにより、次の図に示されているコール シナリオの両方が可能になります。

Unified CM のルートのセットで Unified CM から Webex Calling へのコール ルーティングを示す図。

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 宛先にアクセスできる必要があります。

PST と Webex Calling からの通話の差別化された CoS の図。
PSTN と Webex Calling からのコールに対応する差別化された CoS

この図は、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 宛先を表すパーティションが作成され ("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://

Mac または Windows のデフォルトの通話アプリケーションの場合、Webex アプリで音声またはビデオ通話を開始するプロトコル ハンドラのリスト。

Windows 用プロトコル ハンドラー

他のアプリは Webex アプリの前にプロトコル ハンドラーに 登録できます。Windows 10 では、通話を開始するために使用するアプリを選択するためにユーザーに尋ねるシステム ウィンドウ。ユーザーは、[常にこのアプリを使う] にチェックを入れて、記憶させることができます。

Windows 10 「アプリを選択」を選択するオプションとして Webex が強調表示されます。

ユーザーが Webex アプリを選択するために、デフォルトの通話アプリ設定をリセットする必要がある場合、Windows 10 の Webex アプリのプロトコル関連付けを変更するように指示できます。

  1. [デフォルトのアプリ設定] システム設定を開き、[アプリごとにデフォルトを設定する] をクリックして、[Webex アプリ] を選択します。

    Windows 10 の [アプリごとにデフォルトを設定する] で、Webex を選択するオプションとして強調表示されます。

  2. 各プロトコルに対して、[Webex アプリ] を選択します。

    ファイル タイプとプロトコルの関連付けのための Windows 10 Webex オプション。

macOS 用のプロトコルハンドラー

Mac OS では、 Webex アプリの前に通話プロトコルに登録されている他のアプリがある場合、ユーザーは Webex アプリ をデフォルトの通話オプションに設定する必要があります。

Mac 版 Webex アプリでは、ユーザーは一般的な基本設定で [通話を開始] 設定に [Webex アプリ] が選択されていることを確認できます。また、Outlook の連絡先の番号をクリックしたときに Webex アプリで発信する場合、[常に Microsoft Outlook に接続する] をオンにすることもできます。

Mac OS プロトコル ハンドラ設定、[常に Microsoft Outlook に接続] オプションを選択し、[コールを開始] ドロップダウンで Webex が選択されています。

環境を準備する

全般的な前提条件

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 注文ガイド」の表 1 を参照してください。また、ローカル ゲートウェイ構成ガイドに従って、プラットフォームがサポートされている IOS-XE リリースを実行していることを確認してください。

ローカル ゲートウェイは、自分のペースで 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 アプリのプロキシ アドレスを手動で設定します。

希望の製品タイプを設定するときに、表で次のプロキシ設定と認証タイプを選択します。

製品

プロキシの設定

認証タイプ

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

表の凡例の場合:

  1. †Mac NTLM 認証 - マシンはドメインにログインする必要はなく、ユーザーはパスワードの入力を求められます

  2. †Windows NTLM 認証 - マシンがドメインにログインしている場合にのみサポートされます

  3. ネゴシエート †- NTLM フォールバック認証で Kerberos。

  4. Cisco Webex Board、Desk、または Room シリーズのデバイスをプロキシ サーバーに接続するには、「Board、Desk、または Room シリーズのデバイスをプロキシ サーバーに接続する」を参照してください。

  5. Cisco IP 電話の場合、プロキシ サーバーと設定を構成する例として、プロキシ サーバーのセットアップ を参照してください。

[認証なし] の場合、認証をサポートしていないプロキシ アドレスでクライアントを設定します。[プロキシ認証] を使用する場合は、有効な資格情報で構成します。Web トラフィックを検査するプロキシは、Web ソケット接続に干渉する場合があります。この問題が発生した場合、*.Webex.com への検査を行わないトラフィックをバイパスすると問題が解決する可能性があります。すでに他のエントリが表示されている場合は、最後のエントリの後にセミコロンを追加し、Webex 例外を入力します。

Windows OS のプロキシ設定

Microsoft Windows は、プロキシ設定を許可する HTTP トラフィック (WinINet および WinHTTP) のための 2 つのネットワーク ライブラリをサポートしています。WinINet は WinHTTP のスーパーセットです。

  1. WinInet は、シングルユーザーのデスクトップ クライアント アプリケーション用に設計されています

  2. 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 サービス

  1. アイデンティティ プロビジョニング

  2. アイデンティティ ストレージ

  3. 認証

  4. OAuth サービス

  5. オンボードのデバイス

  6. クラウド接続 UC

電話機を初めてネットワークに接続する場合、または 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 マイクロサービス。

  1. プロファイル画像サービス

  2. ホワイトボード サービス

  3. Proximity サービス

  4. プレゼンス サービス

  5. 登録サービス

  6. カレンダー サービス

  7. 検索サービス

すべて

*.webexcontent.com

一般的なファイル ストレージに関する Webex メッセージング サービス:

  1. ユーザー ファイル

  2. トランスコードされたファイル

  3. イメージ

  4. スクリーンショット

  5. ホワイトボードの内容

  6. クライアントとデバイスのログ

  7. プロファイル画像

  8. ブランディング ロゴ

  9. ログ ファイル

  10. CSV エクスポート ファイルの一括インポート (Control Hub)

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-65535TCP「Webex Calling サービスの IP サブネット」を参照してください。5062, 8934

これらの IP/ポートは、ローカル ゲートウェイ、デバイス、および Webex アプリ アプリケーション (ソース) から Webex Calling クラウド (宛先) への発信 SIP-TLS コール シグナリングに必要です。

ポート 5062（証明書ベースのトランクに必要）。およびポート 8934 (登録ベースのトランクに必要)

デバイス5060-50808934
Webex アプリ 一時的 (OS 依存)
Webex Calling (SIP TLS) からローカル ゲートウェイへのコール シグナリング

Webex Calling のアドレス範囲。

「Webex Calling サービスの IP サブネット」を参照してください。

8934TCPローカル ゲートウェイに顧客が選択した IP または IP 範囲ローカル ゲートウェイに顧客が選択したポートまたはポート範囲

証明書ベースのローカル ゲートウェイに適用されます。Webex Calling からローカル ゲートウェイへの接続を確立する必要があります。

登録ベースのローカル ゲートウェイは、ローカル ゲートウェイから作成された接続を再利用することで機能します。

宛先ポートは、[トランクの設定] を選択した顧客です。

Webex Calling へのコール メディア (STUN、SRTP/SRTCP、T38、DTLS)ローカル ゲートウェイ外部 NIC8000-48199†*UDP「Webex Calling サービスの IP サブネット」を参照してください。

5004、9000 (STUN ポート)

音声: 8500-8599

ビデオ: 8600-8699

19560-65535 (UDP 経由の SRTP)

  • これらの IP/ポートは、ローカル ゲートウェイ、デバイス、および Webex アプリ アプリケーション (ソース) から Webex Calling クラウド (宛先) への発信 SRTP コール メディアに使用されます。

  • STUN、ICE ネゴシエーションが成功している組織内の通話の場合、通信パスとしてクラウドのメディアリレーが削除されます。このような場合、メディア フローはユーザーのアプリ/デバイス間で直接行われます。

    例: メディア最適化が成功すると、Webex アプリはポート範囲 8500 ～ 8699 で互いに直接メディアを送信し、デバイスは 19560 ～ 19661 で互いに直接メディアを送信します。

  • 顧客のプレミス内でファイアウォールが使用される特定のネットワーク トポロジでは、メディアがフロースルーするために、ネットワーク内の前述の送信元と宛先ポート範囲へのアクセスを許可します。

    例: Webex アプリでは、送信元と送信先のポート範囲を許可します

    音声: 8500-8599 ビデオ:8600-8699

  • ブラウザは、管理対象デバイス管理（MDM）プロファイルで WebRtcUdpPortRange ポリシーを設定することで制御できる一時的なソース ポートを使用します。

    MDM サービスが設定されていない場合、または SiteURL と EnableForceLogin が設定されていない 場合、Webex Calling サービスは通常どおりに動作します。

デバイス†*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)ローカル ゲートウェイ内部 NIC8000-65535TCPITSP、PSTN GW または Unified CMPSTN オプションによって異なる (たとえば、Unified CM の 5060 または 5061)
PSTN ゲートウェイへのコール メディア (SRTP/SRTCP)ローカル ゲートウェイ内部 NIC8000-48199†*UDPITSP、PSTN GW または Unified CMPSTN オプションによって異なります（たとえば、Unified CM の場合は 5060 または 5061）
デバイスの構成とファームウェアの管理 (Cisco デバイス)Webex Calling デバイス一時的TCP

「Webex Calling サービスの IP サブネット」を参照してください。

443, 6970, 80

次の理由で必須:

  1. エンタープライズ電話 (Cisco Unified CM) から Webex Calling への移行。詳細については、upgrade.cisco.com を参照してください。cloudupgrader.webex.com はポートを使用します。ファームウェア移行プロセスの 6970,443。

  2. 16 桁のアクティベーション コード (GDS) を使用したデバイス (MPP および Room または Desk Phone) のファームウェアのアップグレードと安全なオンボーディング

  3. CDA / EDOS - MAC アドレスベースのプロビジョニング。新しいファームウェアを持つデバイス（MPP 電話、ATA、SPA ATA）で使用されます。

  4. Cisco ATA の場合、デバイスが最小ファームウェア 11.1.0MSR3-9 にあることを確認します。

  5. 電話機が初めてネットワークに接続する場合、または初期設定へのリセット後に、DHCP オプションが設定されていない場合は、ゼロ タッチ プロビジョニング用のデバイス アクティベーション サーバに接続します。新しい電話は、プロビジョニングのために webapps.cisco.com の代わりに activate.cisco.com を使用します。11.2(1) より前にリリースされたファームウェアを搭載した電話機は、引き続き webapps.cisco.com を使用します。すべての IP サブネットを許可することをお勧めします。

  6. 12.0.3 バージョンより古い Cisco マルチプラットフォーム フォン (MPP) が、ポート 80 から sudirenewal.cisco.com にアクセスして、製造元でインストールされた証明書 (MIC) を更新し、セキュアな一意のデバイス識別子 (SUDI) を持つことを許可します。詳細については、フィールド通知を参照してください。

Webex アプリの設定Webex アプリ アプリケーション一時的TCP

「Webex Calling サービスの IP サブネット」を参照してください。

443, 8443Id ブローカー認証、クライアントの Webex アプリ構成サービス、セルフケアおよび管理インターフェイス アクセスのためのブラウザベースの Web アクセスに使用されます。
TCP ポート 8443 は、構成をダウンロードするために Cisco Unified CM セットアップの Webex アプリで使用されます。Webex Calling に接続するためにセットアップを使用する顧客のみがポートを開く必要があります。
デバイス時間同期 (NTP)Webex Calling デバイス51494UDP「Webex Calling サービスの IP サブネット」を参照してください。123これらの IP アドレスは、デバイス（MPP 電話、ATA、SPA ATA）の時間同期に必要です。

ドメイン ネーム システム（DNS）の解決

Webex Calling デバイス、Webex アプリ、Webex デバイス一時的UDP および TCP主催者が定義53DNS ルックアップでクラウドの Webex Calling サービスの IP アドレスを検出するために使用されます。典型的な DNS ルックアップは UDP で行われますが、クエリ応答が UDP パケットに収まらない場合、TCP が必要な場合があります。
ネットワーク タイム プロトコル (NTP)Webex アプリと Webex デバイス123UDP主催者が定義123時間同期
CScanWebex Calling の Web ベースのネットワーク準備事前資格ツール一時的TCP「Webex Calling サービスの IP サブネット」を参照してください。8934 および 443Webex Calling の Web ベースのネットワーク準備事前資格ツールです。詳細については、cscan.webex.com を参照してください。
UDP19569-19760
追加の Webex Calling および Webex Aware サービス (サードパーティ)
プッシュ通知 APNS および FCM サービス Webex Calling アプリケーション 一時的TCP

リンクの下に記載されている IP サブネットを参照してください

Apple プッシュ通知サービス (APNS)

Google-Firebase クラウド メッセージング (FCM)

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 日

次の詳細で更新されました。

  • Webex Calling (アプリ、デバイス) でサポートされている QoS (TOS/DSCP) 値

  • ネットワーク図を更新しました

  • Webex アテンダントコンソールに関連するネットワーク要件のリンクを含める。

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 日

記事全体を見直して、以下を含めました。

  1. プロキシ サポートのオプションが含まれています。

  2. 変更された通話フロー図

  3. Webex Calling および Webex Aware サービスの簡素化されたドメイン/URL/IP サブネット部分

  4. Webex Calling および Webex Aware サービスに対して 170.72.0.0/16 IP サブネット範囲を追加しました。

    次の範囲 170.72.231.0、170.72.231.10、170.72.231.161 および 170.72.242.0/24 を削除しました。

2023年3月5日

記事を更新して、以下を含めます。

  • アプリケーションで使用される UDP-SRTP ポート範囲（8500～8700）を追加しました。

  • プッシュ通知 APNS および FCM サービスのポートを追加しました。

  • UDP と TCP の CScan ポート範囲を分割します。

  • リファレンス セクションを追加しました。

2022 年 11 月 15 日

デバイス構成とファームウェア管理 (Cisco デバイス) に次の IP アドレスを追加しました。

  • 170.72.231.0

  • 170.72.231.10

  • 170.72.231.161

デバイス構成とファームウェア管理 (Cisco デバイス) から次の IP アドレスを削除しました。

  • 3.20.118.133

  • 3.20.228.133

  • 3.23.144.213

  • 3.130.125.44

  • 3.132.162.62

  • 3.140.117.199

  • 18.232.241.58

  • 35.168.211.203

  • 50.16.236.139

  • 52.45.157.48

  • 54.145.130.71

  • 54.156.13.25

  • 52.26.82.54

  • 54.68.1.225

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 機能

  • ソース アドレス: Webex Calling デバイス

  • ソースポート: 一時的

  • プロトコルTCP

  • 宛先アドレス: 「Webex Meetings/Messaging - ネットワーク要件」で定義されている IP サブネットとドメインを参照してください。

  • 宛先ポート: 443

    メモ: Webex Calling デバイスは、これらの IP アドレスとドメインを使用して、ディレクトリ、通話履歴、ミーティングなどの Webex クラウド サービスとインターフェイスします。

[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しました。

  • 23.89.40.0/25

  • 23.89.1.128/25

2022 年 3 月 29 日

このサービスに以下の IP サブネットWebex Callingしました。

  • 23.89.33.0/24

  • 150.253.209.128/25

2021 年 9 月 20 日

Webex Calling サービスに 次の 4 つの新しい IP サブネットが追加されました。

  • 23.89.76.128/25

  • 170.72.29.0/24

  • 170.72.17.128/25

  • 170.72.0.128/25

2021 年 4 月 2 日

[Webex Calling サービスのドメインと URL] で *.ciscospark.com を追加し、Webex アプリで Webex Calling の使用事例をサポートします。

2021 年 3 月 25 日

activate.cisco.com に 6 つの新しい IP 範囲が追加されました。これは 2021 年 5 月 8 日から有効になります。

  • 72.163.15.64/26

  • 72.163.15.128/26

  • 173.36.127.0/26

  • 173.36.127.128/26

  • 192.133.220.0/26

  • 192.133.220.64/26

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 デバイス) の簡素化された範囲に移動します。

activate.cisco.com

  • 72.163.10.125 -> 72.163.10.96/27

  • 173.37.149.125 -> 173.37.149.96/27

webapps.cisco.com

  • 173.37.146.134 -> 173.37.146.128/25

  • 72.163.10.134 -> 72.163.10.128/25

Cisco Webex クライアントは 2021 年 3 月にオーストラリアで新しい DNS SRV をポイントしているため、アプリケーション構成に次の IP アドレスを追加します。

  • 199.59.64.237

  • 199.59.67.237

2021 年 1 月 21 日

次の IP アドレスを、デバイス構成とファームウェア管理 (Cisco デバイス) に追加しました。

  • 3.134.166.179

  • 50.16.236.139

  • 54.145.130.71

  • 72.163.10.125

  • 72.163.24.0/23

  • 173.37.26.0/23

  • 173.37.146.134

デバイス構成とファームウェア管理 (Cisco デバイス) から次の IP アドレスを削除しました。

  • 35.172.26.181

  • 52.86.172.220

  • 52.203.31.41

次の IP アドレスをアプリケーション構成に追加しました。

  • 62.109.192.0/19

  • 64.68.96.0/19

  • 207.182.160.0/19

  • 150.253.128.0/17

次の IP アドレスをアプリケーション構成から削除しました。

  • 64.68.99.6

  • 64.68.100.6

アプリケーション構成から次のポート番号を削除しました。

  • 1081, 2208, 5222, 5280-5281, 52644-52645

次のドメインをアプリケーション構成に追加しました。

  • idbroker-b-us.webex.com

  • idbroker-eu.webex.com

  • ty6-wxt-jp.bcld.webex.com

  • os1-wxt-jp.bcld.webex.com

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 アドレスを使用して、通話シグナリングおよびメディア エントリを更新しました。

  • 139.177.64.0/24

  • 139.177.65.0/24

  • 139.177.66.0/24

  • 139.177.67.0/24

  • 139.177.68.0/24

  • 139.177.69.0/24

  • 139.177.70.0/24

  • 139.177.71.0/24

  • 139.177.72.0/24

  • 139.177.73.0/24

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 アドレスが追加されました。

  • Webex Calling への信号発信 (SRTP)—135.84.173.0/25、135.84.174.0/25、199.19.197.0/24、199.19.199.0/24

  • パブリックアドレスエンドポイントへのコールシグナリング（SIP TLS）:135.84.173.0/25、135.84.174.0/25、199.19.197.0/24、199.19.199.0/24。

  • デバイスの構成とファームウェアの管理 (Cisco デバイス) —135.84.173.155、135.84.174.155

  • デバイス時刻の同期—135.84.173.152、135.84.174.152

  • アプリケーションの構成—135.84.173.154、135.84.174.154

2020 年 7 月 22 日

カナダのデータセンターの導入をサポートするために、次の IP アドレスを追加しました。135.84.173.146

2020 年 6 月 9 日

CScan エントリに次の変更を行いました:

  • IP アドレスの 1 つを修正しました。199.59.67.156 から 199.59.64.156 に変更されました。

  • 新しい機能には、新しいポートと UDP（19560-19760）が必要です。

2020/03/11

次のドメインと IP アドレスをアプリケーション構成に追加しました。

  • jp.bcld.webex.com—135.84.169.150

  • client-jp.bcld.webex.com

  • idbroker.webex.com—64.68.99.6, 64.68.100.6

追加の IP アドレスを持つ以下のドメインをデバイスの設定とファームウェア管理に更新しました:

  • cisco.webexcalling.eu—85.119.56.198, 85.119.57.198

  • webapps.cisco.com—72.163.10.134

  • activation.webex.com—35.172.26.181, 52.86.172.220

  • cloudupgrader.webex.com—3.130.87.169, 3.20.185.219

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 で 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 メッセージの処理を提供し、それらを必要なターゲットにルーティングします。

PSTN から Webex Calling 構成ソリューションへのコール ルーティング

IP および SIP は PSTN トランクのデフォルトのプロトコルになっていますが、TDM (時間分割多重化) ISDN 回路は広く使用され、Webex Calling トランクでサポートされています。TDM-IP コール フローを持つローカル ゲートウェイの IP パスのメディア最適化を有効にするには、現在、2 レッグ コール ルーティング プロセスを使用する必要があります。このアプローチでは、下の画像に示すように、Webex Calling と PSTN トランク間に一連の内部ループバックダイヤルピアを導入することで、上記のコール ルーティング設定を変更します。

Webex Calling と PSTN トランク間の内部ループバックダイヤルピアのセットを使用したコール ルーティング設定

オンプレミスの Cisco Unified Communications Manager ソリューションを Webex Calling に接続する場合、以下の図に示すソリューションを構築するためのベースラインとして、シンプルな PSTN ゲートウェイ構成を使用できます。この場合、Unified Communications Manager は、すべての PSTN および Webex Calling コールのルーティングと処理を一元化します。

Unified Communications Manager がすべての PSTN および Webex Calling コールのルーティングと処理を一元化したソリューションダイアグラム

このドキュメントでは、次の画像に示すホスト名、IP アドレス、およびインターフェイスが使用されます。

コール ルーティング設定ソリューションで使用されるホスト名、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 インターフェイスに割り当てることを確認します。

 インターフェイス GigabitEthernet0/0/0 説明 PSTN および/または CUCM の ip アドレスに面しているインターフェイス 10.80.13.12 255.255.255.0 ! インターフェイス GigabitEthernet0/0/1 説明 Webex Calling (プライベート アドレス) ip アドレスに面しているインターフェイス 192.51.100.1 255.255.240

2

対称暗号化を使用して、ルータの登録と STUN クレデンシャルを保護します。プライマリ暗号化キーと暗号化タイプを次のように設定します。

 key config-key password-encrypt YourPassword パスワード暗号化 aes

3

プレースホルダー PKI トラストポイントを作成します。

後で TLS を設定するには、このトラストポイントが必要です。登録ベースのトランクの場合、このトラストポイントは証明書を必要としません。証明書ベースのトランクでも必須です。

 暗号 pki trustpoint EmptyTP 失効チェック なし
4

TLS1.2 の排他性を有効にし、次の設定コマンドを使用してデフォルトのトラストポイントを指定します。トランスポート パラメータも更新して、登録の信頼性の高い安全な接続を確保する必要があります。

cn-san-validate サーバ コマンドにより、テナント 200 で設定されたホスト名がアウトバウンド プロキシから受信した証明書の CN または SAN フィールドに含まれている場合、ローカル ゲートウェイが接続を許可します。

  1. tcp-retry count を 1000 に設定します (5-msec multiples = 5 秒)。

  2. タイマー接続を確立する コマンドを使用すると、次に使用可能なオプションを考慮する前に、LGW がプロキシとの接続をセットアップするのを待つ時間を調整できます。このタイマーのデフォルトは 20 秒、最小は 5 秒です。低値で開始し、ネットワーク条件に対応するために必要に応じて増加します。

 sip-ua タイマー接続を確立します tls 5 トランスポート tcp tls v1.2 暗号シグナリング デフォルト トラストポイント EmptyTP cn-san-validate server tcp-retry 1000

5

Webex Calling で使用される DigiCert CA 証明書を含む Cisco ルート CA バンドルをインストールします。crypto pki trustpool import clean url コマンドを使用して、指定された URL からルート CA バンドルをダウンロードし、現在の CA トラストプールをクリアし、証明書の新しいバンドルをインストールします。

HTTPS を使用してインターネットにアクセスするためにプロキシを使用する必要がある場合は、CA バンドルをインポートする前に次の設定を追加してください。

ip http クライアント プロキシ サーバ yourproxy.com プロキシ ポート 80
 ip http クライアント ソースインターフェイス GigabitEthernet0/0/1 暗号 pki trustpool インポート クリーン URL https://www.cisco.com/security/pki/trs/ios_core.p7b
Webex Calling 登録ベースのトランクを設定
1

Control Hub の既存のロケーションに対して登録ベースの PSTN トランクを作成します。トランクが作成されると、提供されたトランク情報をメモします。図でハイライトされている詳細は、このガイドの設定手順で使用されます。詳細については、「Webex Calling のトランク、ルート グループ、ダイヤル プランを構成する」を参照してください。

PSTN トランクが登録されました
2

次のコマンドを入力して、CUBE を Webex Calling ローカル ゲートウェイとして設定します。

 音声サービス voip ip address trusted list ipv4 x.x.x.x y.y.y モード border-element media statistics media bulk-stats allow-connections sip to sip supplementary-service sip refer stun stun flowdata agent-id 1 boot-count 4 stun flowdata shared-secret 0 パスワード123$ sip asymmetric payload full early-offer forced

以下は、設定のフィールドの説明です。

 ip アドレスの信頼リスト  ipv4 x.x.x.x y.y.y

  • 有料詐欺から保護するために、信頼できるアドレス リストは、ローカル ゲートウェイが合法的な VoIP コールを期待するホストとネットワークのリストを定義します。

  • デフォルトでは、ローカル ゲートウェイは、信頼リストに含まれていない IP アドレスからのすべての着信 VoIP メッセージをブロックします。デフォルトでは、「セッション ターゲット IP」またはサーバ グループ IP アドレスを持つ静的に設定されたダイヤル ピアが信頼されます。これらの IP アドレスを信頼リストに追加する必要はありません。

  • ローカル ゲートウェイを設定する場合は、地域の Webex Calling データ センターの IP サブネットをリストに追加します。詳細については、「Webex Calling のポート参照情報」を参照してください。また、Unified Communications Manager サーバ（使用されている場合）と PSTN トランク ゲートウェイのアドレス範囲を追加します。

    LGW が制限付きコーン NAT のあるファイアウォールの背後にある場合は、Webex Calling に面したインターフェイスの IP アドレスの信頼リストを無効にすることをおすすめします。ファイアウォールはすでに、未承諾のインバウンドメッセージから保護VoIP。[無効にする] アクションは、Webex Calling ピアのアドレスが固定されたままである保証を保証できないので、長期構成のオーバーヘッドを削減します。また、いかなる場合にも、ピアに対してファイアウォールを構成する必要があります。

モードの境界要素

プラットフォームで Cisco Unified Border Element（CUBE）機能を有効にします。

メディア統計

ローカル ゲートウェイ上のメディア監視が可能です。

メディア一括統計

一括通話統計のために、コントロール飛行機がデータ 飛行機をポーリングできます。

これらのコマンドの詳細については、メディアを参照してください。

allow-connections sip to sip

CUBE 基本 SIP バックツーバックのユーザー エージェント機能を有効にします。詳細については、「接続を許可する」を参照してください。

デフォルトでは、T.38 ファックス トランスポートが有効になっています。詳細については、ファックス プロトコル t38 (音声サービス) を参照してください。

ストーン

STUN (NAT 経由の UDP のセッション トラバーサル) をグローバルに有効にします。

  • ローカル ゲートウェイの STUN バインディング機能を使用すると、ネゴシエートされたメディア パスを介して、ローカルで生成された STUN 要求を送信できます。これにより、ファイアウォールのピンホールを開くことができます。

詳細については、stun flowdata agent-id および stun flowdata shared-secret を参照してください。

非対称ペイロード (フル)

DTMF と動的コーデック ペイロードの両方に対して SIP 非対称ペイロード サポートを設定します。詳細については、非対称ペイロードを参照してください。

early-offer forced

ローカル ゲートウェイが、隣接ピアからの確認応答を待つ代わりに、最初の INVITE メッセージで SDP 情報を送信するように強制します。このコマンドの詳細については、早期オファーを参照してください。

3

すべてのトランクに対して G.711 コーデックのみを許可する音声クラス コーデック 100 を設定します。このシンプルなアプローチは、ほとんどの導入に適しています。必要に応じて、発信元システムと終端システムの両方でサポートされている追加のコーデック タイプをリストに追加できます。

DSP モジュールを使用したトランスコーディング を含むより複雑なソリューションはサポートされていますが、このガイドには含まれていません。 

 音声クラス コーデック 100 コーデックの設定 1 g711ulaw コーデックの設定 2 g711alaw

以下は、設定のフィールドの説明です。

音声クラス コーデック 100

SIP トランク コールの優先コーデックのみを許可するために使用されます。詳細については、音声クラス コーデックを参照してください。

4

音声クラス stun-usage 100 を設定して、Webex Calling トランクで ICE を有効にします。

 音声クラス stun-usage 100 stun-usage firewall-traversal flowdata stun-usage ice lite

以下は、設定のフィールドの説明です。

STUNの使用法ice lite

可能なときは常に、メディア最適化を可能にする、すべての Webex Calling でダイヤルピアで ICE-Lite を有効にします。詳細については、音声クラス stun 使用状況 および使用状況のice liteを参照してください。

メディアの最適化は、可能な限り、ネゴシエートされます。通話に録画などのクラウド メディア サービスが必要な場合、メディアを最適化できません。

5

Webex トラフィックのメディア暗号化ポリシーを設定します。

 音声クラス srtp-crypto 100 暗号 1 AES_CM_128_HMAC_SHA1_80

以下は、設定のフィールドの説明です。

音声クラス srtp-crypto 100

オファーと応答メッセージの SDP で唯一の SRTP 暗号スイート CUBE が提供されるため、SHA1_80 を指定します。Webex Calling は SHA1_80 のみをサポートします。詳細については、「voice class srtp-crypto」を参照してください。

6

宛先トランク パラメータに基づいて、ローカル ゲートウェイ トランクへのコールを識別するパターンを設定します。 

 音声クラス uri 100 sip パターン dtg=Dallas1463285401_LGU

以下は、設定のフィールドの説明です。

音声クラス uri 100 sip

着信 SIP 招待を着信トランクダイヤルピアに一致させるパターンを定義します。このパターンを入力する場合は、dtg= の後に、トランクが作成されたときに Control Hub で提供されるトランク OTG/DTG 値を使用します。詳細については、音声クラス uri を参照してください。

7

sip プロファイル 100 を構成します。これは、Webex Calling に送信される SIP メッセージを変更するために使用されます。

 voice class sip-profiles 100 rule 10 request ANY sip-header SIP-Req-URI change "sip:" "sip:" rule 20 request ANY sip-header ANY sip-header To modify "" "" ";otg=dallas1463285401_lgu>" rule 90 request ANY sip-header P-Asserted-Identity modify "sips:" "sip:"

以下は、設定のフィールドの説明です。

  • ルール 10 ～ 70 および 90

    コール シグナリングに使用される SIP ヘッダーが、Webex プロキシが必要な SIP スキームではなく、SIP を使用するようにします。SIP を使用するために CUBE を設定することで、セキュアな登録が使用されます。

  • ルール 80

    エンタープライズ内のローカル ゲートウェイ サイトを一意に識別するために、Control Hub からトランク グループ OTG/DTG 識別子を含めるために、From ヘッダーを変更します。

米国またはカナダの PSTN プロバイダーは、Webex Calling のスパムまたは詐欺通話の表示 の記事で言及されている追加設定を使用して、スパムおよび詐欺通話の発信者 ID 検証を提供できます。

8

Webex Calling トランクの設定:

  1. 音声クラス テナント 100 を作成して、Webex Calling トランクに特別に必要な設定を定義し、グループ化します。特に、以前の Control Hub で提供されたトランク登録の詳細は、以下の詳細に従って、このステップで使用されます。このテナントに関連付けられているダイヤルピアは、後でこれらの設定を継承します。

    次の例では、ステップ 1 で説明されている値を、このガイドの目的で使用しています（太字で示されています）。設定内のトランクの値に置き換えます。

     音声クラス テナント 100 レジストラの dns:98027369.us10.bcld.webex.com スキーム sips の有効期限が 240 更新比 50 tcp tls 資格情報番号 Dallas1171197921_LGU ユーザー名 Dallas1463285401_LGU パスワード 0 9Wt[M6ifY+ realm BroadWorks 認証ユーザー名 Dallas1463285401_LGU パスワード 0 9Wt[M6ifY+ realm BroadWorks 認証ユーザー名 Dallas1463285401_LGU パスワード 0 9Wt[M6ifY+ realm 98027369.us10.bcld.webex.com remote-party-id sip-server dns なし:98027369.us10.bcld.webex.com connection-reuse srtp-crypto 100 セッション トランスポート tcp tls セッションの更新 url sips error-passthru rel1xx disable asserted-id pai bind control source-interface GigabitEthernet0/0/1 bind media source-interface GigabitEthernet0/0/1 no pass-thru content custom-sdp sip-profiles 100 outbound-proxy dns:dfw04.sipconnect-us.bcld.webex.com プライバシー ポリシー passthru

    以下は、設定のフィールドの説明です。

    音声クラス テナント 100

    Webex Calling トランクにのみ使用される設定パラメータのセットを定義します。詳細については、音声クラス テナントを参照してください。

    登録者 dns:98027369.us10.bcld.webex.com スキーム sips 有効期限 240 更新比 50 tcp tls

    ローカル ゲートウェイの登録サーバーで、2 分ごとに更新が設定されている場合 (240 秒の 50%)。詳細については、登録者を参照してください。

    ここから Control Hub から [ドメインの登録] の値を使用していることを確認します。

    資格情報番号 Dallas1171197921_LGU ユーザー名 Dallas1463285401_LGU パスワード 0 9Wt[M6ifY+ realm BroadWorks

    トランク登録認証の資格情報。詳細については、「資格情報 (SIP UA)」を参照してください。

    ここから Control Hub から回線/ポートホスト、認証ユーザ名、認証パスワードの値を使用していることを確認します。

    認証ユーザー名 Dallas1171197921_LGU パスワード 0 9Wt[M6ifY+ realm BroadWorks
    認証ユーザー名 Dallas1171197921_LGU パスワード 0 9Wt[M6ifY+ realm 98027369.us10.bcld.webex.com

    コールの認証の課題。詳細については、認証 (ダイヤルピア) を参照してください。

    ここから Control Hub から、認証ユーザ名、認証パスワード、および登録ドメインの値をそれぞれ使用していることを確認します。

    no remote-party-id

    Webex Calling が PAI をサポートしているため、SIP Remote-Party-ID (RPID) ヘッダーを無効にします。これは asserted-id pai を使用して有効になります。詳細については、remote-party-id を参照してください。

    sip サーバ dns: us25.sipconnect.bcld.webex.com

    トランクのターゲット SIP サーバを設定します。トランクを作成したときに、Control Hub で提供されたエッジ プロキシ SRV アドレスを使用します。

    connection-reuse

    登録と通話処理に同じ永続的な接続を使用します。詳細については、connection-reuse を参照してください。

    srtp-crypto 100

    SRTP コール レッグ（接続）の優先暗号スイートを設定します（手順で指定）5). 詳細については、「voice class srtp-crypto」を参照してください。

    session transport tcp tls

    TLS へのトランスポートを設定します。詳細については、session-transport を参照してください。

    セッションの更新がありません

    CUBE と Webex 間の通話の SIP セッション更新を無効にします。詳細については、セッションの更新を参照してください。

    url sips

    SRVは、アクセス SBC によりサポートされている SIP である必要があります。その他のすべてのメッセージは、sip-profile 200 により SIP に変更されます。

    error-passthru

    SIP エラー応答パススルー機能を指定します。詳細については、error-passthru を参照してください。

    rel1xx を無効にする

    Webex Calling トランクに対する信頼できる仮応答の使用を無効にします。詳細については、rel1xx を参照してください。

    asserted-id pai

    (オプション) P-Asserted-Identity ヘッダー処理をオンにし、これが Webex Calling トランクに使用する方法を制御します。

    Webex Calling には、ローカル ゲートウェイへの発信コール INVITE の P-Asserted-Identity (PAI) ヘッダーが含まれています。

    このコマンドが設定されている場合、PAI ヘッダーからの発信者情報を使用して、発信元および PAI/Remote-Party-ID ヘッダーに入力します。

    このコマンドが設定されていない場合、From ヘッダーの発信者情報を使用して、発信 From ヘッダーと PAI/Remote-Party-ID ヘッダーに入力します。

    詳細については、asserted-id を参照してください。

    bind control source-interface GigabitEthernet0/0/1

    Webex Calling に送信されるメッセージのソース インターフェイスと関連する IP アドレスを設定します。詳細については、バインドを参照してください。

    bind media source-interface GigabitEthernet0/0/1

    WebexCalling に送信されるメディアのソース インターフェイスと関連する IP アドレスを設定します。詳細については、バインドを参照してください。

    no pass-thru content custom-sdp

    テナントの下のデフォルト コマンド。このコマンドの詳細については、pass-thru content を参照してください。

    sip プロファイル 100

    sip-profile 100 で定義されているように、SIP を SIP に変更し、INVITE および REGISTER メッセージの回線/ポートを変更します。詳細については、音声クラス sip-profiles を参照してください。

    outbound-proxy dns:dfw04.sipconnect-us.bcld.webex.com

    Webex Calling SBC にアクセスします。トランクを作成したときに、Control Hub で提供されるアウトバウンド プロキシ アドレスを挿入します。詳細については、outbound-proxy を参照してください。

    privacy-policy passthru

    トランクが受信メッセージから次のコール レッグにプライバシー値を渡すようにプライバシー ヘッダー ポリシー オプションを設定します。詳細については、プライバシー ポリシーを参照してください。

  2. Webex Calling トランクのダイヤルピアを設定します。 

     ダイヤルピア ボイス 100 voip の説明 着信/発信 Webex Calling max-conn 250 宛先パターン bad.bad セッションプロトコル sipv2 session target sip-server inbound uri request 100 voice-class codec 100 dtmf-relay rtp-nte voice-class stun-usage 100 no voice-class sip localhost voice-class sip tenant 100 srtp no vad

    以下は、設定のフィールドの説明です。

     ダイヤルピア ボイス 100 voip  の説明 着信/発信 Webex Calling

    100 VoIP ダイヤルピアを定義し、管理とトラブルシューティングを容易にするための意味のある説明を行います。

    max-conn 250

    LGW と Webex Calling の間の同時着信および発信通話の数を制限します。登録トランクの場合、設定された最大値は 250 である必要があります。展開に適切であれば、ユーザの値を下げます。ローカル ゲートウェイの同時通話制限の詳細については、「ローカル ゲートウェイの使用を開始する 」ドキュメントを参照してください。

    宛先パターン BAD.BAD

    着信ダイヤルピア グループを使用して発信コールをルーティングする場合は、ダミー通知先パターンが必要です。この場合、有効な宛先パターンを使用できます。詳細については、「destination-pattern (interface)」を参照してください。

    session protocol sipv2

    ダイヤルピア 100 が SIP コール のコールコールを処理する場合に指定します。詳細については、セッション プロトコル (ダイヤルピア) を参照してください。

    session target sip-server

    テナント 100 で定義された SIP サーバが継承され、このダイヤル ピアからのコールの宛先に使用されることを示します。詳細については、セッション ターゲット (VoIP ダイヤル ピア) を参照してください。

    着信 uri リクエスト 100

    VoIP ダイヤル ピアと着信コールの Uniform Resource Identifier（URI）を照合するために使用される音声クラスを指定します。詳細については、着信 uri を参照してください。

    音声クラスのコーデック 100

    共通のコーデック フィルター リスト 100 を使用するようにダイヤル ピアを設定します。詳細については、音声クラス コーデックを参照してください。

    音声クラス 使用量

    ローカル ゲートウェイでローカルで生成された STUN 要求が、ネゴシエートされたメディア パスを介して送信されるようにします。STUN は、メディア トラフィック用のファイアウォール ピンホールを開くのに役立ちます。

    no voice-class sip localhost

    送信メッセージの物理的 IP アドレスの代用として、From、Call-ID、Remote-Party-ID ヘッダーの DNS ローカル ホスト名の代入を無効にします。

    voice-class SIP テナント 100

    ダイヤル ピアは、グローバルおよびテナント 100 で設定されたすべてのパラメータを継承します。パラメータは、ダイヤルピア レベルでオーバーライドされる場合があります。

    srtp

    コールレグの SRTP を有効にする。

    no vad

    音声アクティブティの検出を無効にします。

テナント 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 トランクを使用したローカル ゲートウェイの設定

上記で 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 ホスト ipv4:192.168.80.13

以下は、設定のフィールドの説明です。

音声クラス uri 200 sip

着信 SIP 招待を着信トランクダイヤルピアに一致させるパターンを定義します。このパターンを入力する場合は、IP PSTN ゲートウェイの IP アドレスを使用します。詳細については、音声クラス uri を参照してください。

2

次の IP PSTN ダイヤル ピアを設定します。

 ダイヤルピア ボイス 200 voip の説明 インバウンド/アウトバウンド IP PSTN トランクの宛先パターン BAD.BAD セッション プロトコル sipv2 セッション ターゲット ipv4:192.168.80.13 200 voice-class sip asserted-id pai voice-class sip bind control source-interface GigabitEthernet0/0/0 voice-class sip bind media source-interface GigabitEthernet0/0/0 voice-class codec 100 dtmf-relay rtp-nte no vad

以下は、設定のフィールドの説明です。

 ダイヤルピア ボイス 200 voip  の説明 着信/発信 IP PSTN トランク

タグ 200 で VoIP ダイヤルピアを定義し、管理とトラブルシューティングを容易にする意味のある説明を提供します。詳細については、ダイヤルピアの音声を参照してください。

宛先パターン BAD.BAD

着信ダイヤルピア グループを使用して発信コールをルーティングする場合は、ダミー通知先パターンが必要です。この場合、有効な宛先パターンを使用できます。詳細については、「destination-pattern (interface)」を参照してください。

session protocol sipv2

このダイヤル ピアが SIP コール レッグを処理するように指定します。詳細については、セッション プロトコル (ダイヤル ピア) を参照してください。

セッション ターゲット ipv4: 192.168.80.13

PSTN プロバイダーに送信されるコールのターゲット アドレスを指定します。これは IP アドレスまたは DNS ホスト名です。詳細については、セッション ターゲット (VoIP ダイヤル ピア) を参照してください。

200 経由の着信 uri

INVITE 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/0

PSTN に送信されるメディアのソース インターフェイスと関連する IP アドレスを設定します。詳細については、バインドを参照してください。

音声クラスのコーデック 100

共通のコーデック フィルター リスト 100 を使用するようにダイヤル ピアを設定します。詳細については、音声クラス コーデックを参照してください。

dtmf-relay rtp-nte

通話レグで予想される DTMF 機能として RTP-NTE (RFC2833) を定義します。詳細については、「DTMF リレー (音声オーバー IP)」を参照してください。

no vad

音声アクティブティの検出を無効にします。詳細については、vad (ダイヤル ピア) を参照してください。

3

ローカル ゲートウェイを Webex Calling と PSTN 間のコールのみをルーティングするように設定している場合は、次のコール ルーティング設定を追加します。Unified Communications Manager プラットフォームを使用してローカル ゲートウェイを設定する場合は、次のセクションに進みます。

  1. ダイヤルピア グループを作成して、Webex Calling または PSTN にコールをルーティングします。Webex Calling 向け発信ダイヤルピア 100 で DPG 100 を定義します。DPG 100 は、PSTN からの着信ダイヤルピアに適用されます。同様に、PSTN に向けて発信ダイヤルピア 200 を使用して DPG 200 を定義します。DPG 200 は、Webex からの着信ダイヤルピアに適用されます。

     音声クラス dpg 100 の説明 Webex Calling のダイヤルピア 100 音声クラス dpg 200 の説明 コールを PSTN ダイヤルピア 200 にルーティングする

    以下は、設定のフィールドの説明です。

    ダイヤルピア 100

    発信ダイヤルピアをダイヤルピア グループに関連付けます。詳細については、voice-class dpg を参照してください。

  2. ダイヤルピア グループを適用して、Webex から PSTN および PSTN から Webex に通話をルーティングします。 

     ダイヤルピア ボイス 100 宛先 dpg 200 ダイヤルピア ボイス 200 宛先 dpg 100

    以下は、設定のフィールドの説明です。

    宛先 dpg 200

    どのダイヤルピア グループを指定し、この着信ダイヤルピアに表示されるコールのアウトバウンド処理に使用するかを指定します。

    これにより、ローカル ゲートウェイの設定が終了します。CUBE 機能が初めて設定される場合は、設定を保存し、プラットフォームを再読み込みします。

TDM PSTN トランクを使用したローカル ゲートウェイの設定

Webex Calling に向かってトランクを構築した後、次の構成を使用して、ループバック コール ルーティングを持つ PSTN サービスの TDM トランクを作成し、Webex コール レッグのメディア最適化を可能にします。

IP メディアの最適化を必要としない場合は、SIP PSTN トランクの設定手順に従います。PSTN VoIP ダイヤルピアの代わりに、音声ポートと POTS ダイヤルピア（ステップ 2 と 3 に示すように）を使用します。

1

ループバック ダイヤル ピア設定では、ダイヤル ピア グループとコール ルーティング タグを使用して、コール ルーティング ループを作成することなく、コールが Webex と PSTN の間で正しくパスされるようにします。コール ルーティング タグを追加および削除するために使用される次のトランスレーション ルールを設定します。

 音声翻訳ルール 100 ルール 1 /^\+//A2A/ 音声翻訳プロファイル 100 呼び出された音声翻訳ルール 200 ルール 1 /^//A1A/ 音声翻訳プロファイル 200 呼び出された音声翻訳ルール 11 ルール 1 /^A1A/ // 音声翻訳プロファイル 11 呼び出された音声翻訳ルール 12 ルール 1 /^A2A44//0/ RULE 2/^A2A//00/ 音声翻訳プロファイル 12 呼び出された音声翻訳ルール 12

以下は、設定のフィールドの説明です。

音声翻訳ルール

ルールで定義された正規表現を使用して、コール ルーティング タグを追加または削除します。十進法を超える数字（「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 インターフェイスの基本設定には、以下が含まれる場合があります。

 カードタイプ e1 0 2 つの isdn スイッチタイプ primary-net5 コントローラ E1 0/2/0 pri-group タイムスロット 1-31
3

次の TDM PSTN ダイヤル ピアを設定します。

 ダイヤルピア ボイス 200 ポット説明 着信/発信 PRI PSTN トランクの宛先パターン BAD.BAD translation-profile 着信 200 直通ダイヤルポート 0/2/0:15

以下は、設定のフィールドの説明です。 

 ダイヤルピアの音声 200 ポット  の説明 着信/発信 PRI 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 にルーティングされます。ルーティング タグを削除した後、コールはダイヤルピア グループを使用して発信トランクにルーティングされます。

 dial-peer voice 10 voip description Outbound loop-around leg destination-pattern BAD.BAD session protocol sipv2 session target ipv4:192.168.80.14 voice-class sip bind control source-interface GigabitEthernet0/0/0 dtmf-relay rtp-nte codec g711alaw no vad dial-peer voice 11 voip description Webex translation-profile inbound 11 session protocol sipv2 incoming called-number A1AT voice-class sip bind control source-interface GigabitEthernet0/0/0 dtmf-relay rtp-nte codec g711alaw no vad dial-peer voice 12 voip description PSTN translation-profile incoming 12 session protocol sipv2 incoming called-number A2AT voice-class sip bind control source-interface GigabitEthernet0/0/0 dtmf-relay rtp-nte codec g711alaw no vad dial-peer voice 12 voip description PSTN translation-profile incoming 12 session protocol sipv2 incoming called-number A2AT voice-class sip bind control source-interface GigabitEthernet0/0/0 dtm

以下は、設定のフィールドの説明です。 

 ダイヤルピア ボイス 10 voip  説明 アウトバウンドループバックレッグ

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

次のコール ルーティング設定を追加します。

  1. ダイヤルピア グループを作成して、ループバック経由で PSTN と Webex トランク間のコールをルーティングします。

     音声クラス dpg 100 の説明 Webex Calling のダイヤルピア 100 音声クラス dpg 200 の説明 コールを PSTN ダイヤルピア 200 の音声クラス dpg 10 の説明 通話をループバックダイヤルピア 10 にルーティングする

    以下は、設定のフィールドの説明です。

    ダイヤルピア 100

    発信ダイヤルピアをダイヤルピア グループに関連付けます。詳細については、voice-class dpg を参照してください。

  2. ダイヤル ピア グループを適用して通話をルーティングします。

     ダイヤルピア ボイス 100 宛先 dpg 10 ダイヤルピア ボイス 200 宛先 dpg 10 ダイヤルピア ボイス 11 宛先 dpg 100 ダイヤルピア ボイス 12 宛先 dpg 200

    以下は、設定のフィールドの説明です。

    宛先 dpg 200

    どのダイヤルピア グループを指定し、この着信ダイヤルピアに表示されるコールのアウトバウンド処理に使用するかを指定します。

これにより、ローカル ゲートウェイの設定が終了します。CUBE 機能が初めて設定される場合は、設定を保存し、プラットフォームを再読み込みします。
ローカル ゲートウェイを既存の Unified CM 環境で構成する

前のセクションの 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 ヘッダーにこの値を入力できます。

SIP トランク セキュリティ プロファイル情報を入力
1

以下の音声クラス URI を設定:

  1. ポート経由の SIP を使用して、Unified CM から Webex 通話を分類します。

     voice class uri 300 sip
 pattern :5065

  2. ポート経由の SIP を使用して、Unified CM から PSTN コールを分類します。

     音声クラス uri 400 sip パターン 192\.168\.80\.6[0-5]:5060

    発信元のアドレスとポート番号を記述した 1 つ以上のパターンを使用して、UCM からの着信メッセージを PSTN トランクに分類します。必要に応じて、正規表現を使用して、一致するパターンを定義することができます。

    上記の例では、192.168.80.60 ～ 65 およびポート番号 5060 の任意の IP アドレスに正規表現が使用されます。

2

Unified CM ホストへの SRV ルーティングを指定するには、次の DNS レコードを設定します。

IOS XE は、ターゲット UCM ホストとポートをローカルで判別するためにこれらのレコードを使用します。この設定では、DNS システムでレコードを設定する必要はありません。DNS を使用する場合は、これらのローカル設定は必要ありません。

 ip ホスト ucmpub.mydomain.com 192.168.80.60 ip ホスト ucmsub1.mydomain.com 192.168.80.61 ip ホスト ucmsub2.mydomain.com 192.168.80.62 ip ホスト ucmsub3.mydomain.com 192.168.80.63 ip ホスト ucmsub4.mydomain.com 192.168.80.64 ip ホスト ucmsub5.mydomain.com 192.168.80.65 ip ホスト _sip._udp.wxtocucm.io srv 0 1 5065 ucmpub.mydomain.com ip ホスト _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub1.mydomain.com ip ホスト _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub2.mydomain.com ip ホスト _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub3.mydomain.com ip ホスト _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub4.mydomain.com ip ホスト _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub5.mydomain.com ip ホスト _sip._udp.pstntocucm.io srv 0 1 5060 ucmpub.mydomain.com ip ホスト _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub1.mydomain.com ip ホスト _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub2.mydomain.com ip ホスト _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub3.mydomain.com ip ホスト _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub4.mydomain.com ip ホスト _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub5.mydomain.com

以下は、設定のフィールドの説明です。

次のコマンドにより、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

次のダイヤル ピアを設定します。

  1. Unified CM と Webex Calling 間の通話のダイヤル ピア:

     ダイヤルピア ボイス 300 voip の説明 UCM-Webex Calling トランクの宛先パターン BAD.BAD セッション プロトコル sipv2 セッション target dns:wxtocucm.io 着信 uri via 300 voice-class codec 100 voice-class sip bind control source-interface ギガビットイーサネット 0/0/0 voice-class sip bind media source-interface ギガビットイーサネット 0/0/0 dtmf-relay rtp-nte no vad

    以下は、設定のフィールドの説明です。

     ダイヤルピア ボイス 300 voip  の説明 UCM-Webex Calling トランク

    タグ 300 で VoIP ダイヤルピアを定義し、管理とトラブルシューティングを容易にする意味のある説明を提供します。

    destination-pattern BAD.BAD

    着信ダイヤルピア グループを使用して発信コールをルーティングする場合は、ダミー通知先パターンが必要です。この場合、有効な宛先パターンを使用できます。

    session protocol sipv2

    ダイヤルピア 300 が SIP コール レッグを処理するように指定します。詳細については、セッション プロトコル (ダイヤルピア) を参照してください。

    セッション ターゲット dns:wxtocucm.io

    DNS SRV 解決により複数の Unified CM ノードのセッション ターゲットを定義します。この場合、ローカルで定義された SRV レコード wxtocucm.io がコールを転送するために使用されます。

    incoming uri via 300

    音声クラス URI 300 を使用して、ソース ポート 5065 を使用して、Unified CM からすべての着信トラフィックをこのダイヤルピアに誘導します。詳細については、着信 uri を参照してください。

    音声クラスのコーデック 100

    Unified CM 間のコールのコーデック フィルタ リストを示します。詳細については、音声クラス コーデックを参照してください。

    bind control source-interface GigabitEthernet0/0/0

    PSTN に送信されるメッセージのソース インターフェイスと関連する IP アドレスを設定します。詳細については、バインドを参照してください。

    bind media source-interface GigabitEthernet0/0/0

    PSTN に送信されるメディアのソース インターフェイスと関連する IP アドレスを設定します。詳細については、バインドを参照してください。

    dtmf-relay rtp-nte

    通話レグで予想される DTMF 機能として RTP-NTE (RFC2833) を定義します。詳細については、「DTMF リレー (音声オーバー IP)」を参照してください。

    no vad

    音声アクティブティの検出を無効にします。詳細については、vad (ダイヤル ピア) を参照してください。

  2. Unified CM と PSTN 間の通話のダイヤル ピア:

     ダイヤルピア ボイス 400 voip の説明 UCM-PSTN トランクの宛先パターン BAD.BAD セッション プロトコル sipv2 セッション target dns:pstntocucm.io 着信 uri via 400 voice-class codec 100 voice-class sip bind control source-interface ギガビットイーサネット 0/0/0 voice-class sip bind media source-interface ギガビットイーサネット 0/0/0 dtmf-relay rtp-nte no vad

    以下は、設定のフィールドの説明です。

     ダイヤルピア ボイス 400 voip  の説明 UCM-PSTN トランク

    タグ 400 で VoIP ダイヤルピアを定義し、管理とトラブルシューティングを容易にする意味のある説明を提供します。

    destination-pattern BAD.BAD

    着信ダイヤルピア グループを使用して発信コールをルーティングする場合は、ダミー通知先パターンが必要です。この場合、有効な宛先パターンを使用できます。

    session protocol sipv2

    ダイヤルピア 400 が SIP コール レッグを処理するように指定します。詳細については、セッション プロトコル (ダイヤルピア) を参照してください。

    セッションターゲット dns:pstntocucm.io

    DNS SRV 解決により複数の Unified CM ノードのセッション ターゲットを定義します。この場合、ローカルで定義された SRV レコード pstntocucm.io がコールを転送するために使用されます。

    400 経由の着信 uri

    音声クラス URI 400 を使用して、ソース ポート 5060 を使用して指定された Unified CM ホストからのすべての着信トラフィックをこのダイヤルピアに誘導します。詳細については、着信 uri を参照してください。

    音声クラスのコーデック 100

    Unified CM 間のコールのコーデック フィルタ リストを示します。詳細については、音声クラス コーデックを参照してください。

    bind control source-interface GigabitEthernet0/0/0

    PSTN に送信されるメッセージのソース インターフェイスと関連する IP アドレスを設定します。詳細については、バインドを参照してください。

    bind media source-interface GigabitEthernet0/0/0

    PSTN に送信されるメディアのソース インターフェイスと関連する IP アドレスを設定します。詳細については、バインドを参照してください。

    dtmf-relay rtp-nte

    通話レグで予想される DTMF 機能として RTP-NTE (RFC2833) を定義します。詳細については、「DTMF リレー (音声オーバー IP)」を参照してください。

    no vad

    音声アクティブティの検出を無効にします。詳細については、vad (ダイヤル ピア) を参照してください。

4

次の設定を使用してコール ルーティングを追加します。

  1. ダイヤルピア グループを作成し、Unified CM と Webex Calling の間でコールをルーティングします。DPG 100 を 発信ダイヤルピア 100 で Webex Calling に対して定義します。DPG 100 は、Unified CM からの関連付けられた着信ダイヤルピアに適用されます。同様に、Unified CM に対して発信ダイヤルピア 300 を使用して DPG 300 を定義します。DPG 300 は、Webex からの着信ダイヤルピアに適用されます。

     音声クラス dpg 100 の説明 Webex Calling のダイヤルピア 100 音声クラス dpg 300 の説明 コールを Unified CM にルーティング Webex Calling トランク ダイヤルピア 300 にルーティング

  2. Unified CM と PSTN の間でコールをルーティングするためのダイヤル ピア グループを作成します。PSTN に対して発信ダイヤルピア 200 で DPG 200 を定義します。DPG 200 は、Unified CM から関連する着信ダイヤルピアに適用されます。同様に、Unified CM に対して発信ダイヤルピア 400 を使用して DPG 400 を定義します。DPG 400 は、PSTN からの着信ダイヤルピアに適用されます。

     音声クラス dpg 200 の説明 コールを PSTN ダイヤルピア 200 音声クラス dpg 400 の説明 コールを Unified CM PSTN トランクダイヤルピア 400 にルーティングする

    以下は、設定のフィールドの説明です。

    ダイヤルピア 100

    発信ダイヤルピアをダイヤルピア グループに関連付けます。詳細については、voice-class dpg を参照してください。

  3. ダイヤルピア グループを適用して、Webex から Unified CM および Unified CM から Webex に通話をルーティングします。 

     ダイヤルピア ボイス 100 宛先 dpg 300 ダイヤルピア ボイス 300 宛先 dpg 100

    以下は、設定のフィールドの説明です。

    宛先 dpg 300

    どのダイヤルピア グループを指定し、この着信ダイヤルピアに表示されるコールのアウトバウンド処理に使用するかを指定します。

  4. ダイヤルピア グループを適用して、PSTN から Unified CM から Unified CM から PSTN に通話をルーティングします。

     ダイヤルピア ボイス 200 宛先 dpg 400 ダイヤルピア ボイス 400 宛先 dpg 200

    これにより、ローカル ゲートウェイの設定が終了します。CUBE 機能が初めて設定されている場合、設定を保存し、プラットフォームを再読み込みします。

診断署名でローカル ゲートウェイを監視し、トラブルシューティングする

診断署名 (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 以降を実行しているローカル ゲートウェイ

  1. 診断署名はデフォルトで有効になっています。

  2. デバイスが Cisco IOS XE 17.6.1a 以降を実行している場合、プロアクティブ通知を送信するために使用されるセキュアなメール サーバを設定します。

    ターミナルコールホームメールサーバの設定 :@ 優先順位 1 セキュア tls エンド

  3. 通知する管理者のメール アドレスで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 アカウント設定を行い、端末からメールを正しく処理するための権限を与える必要があります:

  1. [Google アカウントの管理] > [セキュリティ] に移動し、[安全性の低いアプリ アクセス] 設定をオンにします。

  2. 「はい、はい、それは私です」と答えます。Gmail から「Google は、Google 以外のアプリを使用してアカウントにサインインするユーザーを防ぎました」というメールを受け取ります。

プロアクティブ モニタリングのために診断署名をインストールする

CPU 使用率の監視

この DS は、SNMP OID を使用して 5 秒間 CPU 使用率を追跡します。1.3.6.1.4.1.9.2.1.56. 使用率が 75% 以上に達すると、すべてのデバッグを無効にし、ローカル ゲートウェイにインストールされている診断署名をアンインストールします。下記の手順を実行して署名をインストールします。

  1. 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: 有効

  2. Diagnostic Signatures Lookup Tool の以下のドロップダウンオプションを使用して、DS 64224 をダウンロードします。

    フィールド名

    フィールド値

    プラットフォーム

    Cisco 4300、4400 ISR シリーズまたは Cisco CSR 1000V シリーズ

    製品

    Webex Calling ソリューションの CUBE Enterprise

    問題の範囲

    パフォーマンス

    問題の種類

    通知メールによる CPU 使用率が高い

  3. 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 バイト

  4. ローカルゲートウェイに DS XML ファイルをインストールします。

    call-home diagnostic-signature load DS_64224.xml ロードファイル DS_64224.xml 成功

  5. 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 回の登録解除後に自動的にアンインストールされます。署名をインストールするには、以下の手順を使用します。

  1. Diagnostic Signatures Lookup Tool の以下のドロップダウンオプションを使用して、DS 64117 をダウンロードします。

    フィールド名

    フィールド値

    プラットフォーム

    Cisco 4300、4400 ISR シリーズ、または Cisco CSR 1000V シリーズ

    製品

    Webex Calling ソリューションの CUBE Enterprise

    問題の範囲

    SIP-SIP

    問題の種類

    SIP トランクによる登録解除を行いました。

  2. DS XML ファイルをローカルゲートウェイにコピーします。

    ftp://username:password@/DS_64117.xml bootflash:

  3. ローカルゲートウェイに DS XML ファイルをインストールします。 

    call-home diagnostic-signature load DS_64117.xml ロードファイル DS_64117.xml 成功 LocalGateway#

  4. show call-home diagnostic-signature コマンドを使用 して、署名が正常にインストールされたことを確認します。状態の列には「登録済み」の値が必要です。

異常な通話切断の監視

この DS は、10 分ごとに SNMP ポーリングを使用して、SIP エラーの 403、488、503 で異常な通話切断を検出します。 エラーカウントの増分が最後の投票から 5 以上である場合、syslog とメール通知が生成されます。 署名をインストールするには、以下の手順を使用してください。

  1. 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: 有効

  2. Diagnostic Signatures Lookup Tool の以下のオプションを使用して、DS 65221 をダウンロードします。

    フィールド名

    フィールド値

    プラットフォーム

    Cisco 4300、4400 ISR シリーズ、または Cisco CSR 1000V シリーズ

    製品

    Webex Calling ソリューションの CUBE Enterprise

    問題の範囲

    パフォーマンス

    問題の種類

    メールおよび Syslog 通知による SIP の異常通話切断検出

  3. DS XML ファイルをローカルゲートウェイにコピーします。 

    ftp://username:password@/DS_65221.xml bootflash:

  4. ローカルゲートウェイに DS XML ファイルをインストールします。 

    call-home diagnostic-signature load DS_65221.xml ロードファイル DS_65221.xml 成功

  5. 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 を使用して、以下の手順を使用して、診断データの収集を自動化します。

  1. 収集された診断データがアップロードされる 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"

  2. show snmp コマンドを使用して、SNMP が有効になっていることを確認します。有効になっていない場合は、snmp-server manager コマンドを設定します。

    show snmp %SNMP agent not enabled config t snmp-server manager end

  3. 高 CPU 使用率の期間中に、すべてのデバッグと診断署名を無効にするためのプロアクティブな措置として、高 CPU モニタリング DS 64224 をインストールしてください。Diagnostic Signatures Lookup Tool の以下のオプションを使用して、DS 64224 をダウンロードします。

    フィールド名

    フィールド値

    プラットフォーム

    Cisco 4300、4400 ISR シリーズ、または Cisco CSR 1000V シリーズ

    製品

    Webex Calling ソリューションの CUBE Enterprise

    問題の範囲

    パフォーマンス

    問題の種類

    通知メールによる CPU 使用率が高い

  4. 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

  5. DS XML ファイルをローカルゲートウェイにコピーします。

    ftp://username:password@/DS_64224.xml bootflash: ftp://username:password@/DS_65095.xml bootflash:

  6. ローカルゲートウェイに、高 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 成功

  7. 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 では現在、新しいカスタム署名の作成リクエストをサポートしていません。

Control Hub を介した Cisco IOS XE ゲートウェイの管理と検証

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 メッセージの処理を提供し、それらを必要なターゲットにルーティングします。

PSTN から Webex Calling 構成ソリューションへのコール ルーティング

IP および SIP は PSTN トランクのデフォルトのプロトコルになっていますが、TDM (時間分割多重化) ISDN 回路は広く使用され、Webex Calling トランクでサポートされています。TDM-IP コール フローを持つローカル ゲートウェイの IP パスのメディア最適化を有効にするには、現在、2 レッグ コール ルーティング プロセスを使用する必要があります。このアプローチでは、下の画像に示すように、Webex Calling と PSTN トランク間に一連の内部ループバックダイヤルピアを導入することで、上記のコール ルーティング設定を変更します。

Webex Calling と PSTN トランク間の内部ループバックダイヤルピアのセットを使用したコール ルーティング設定

オンプレミスの Cisco Unified Communications Manager ソリューションを Webex Calling に接続する場合、以下の図に示すソリューションを構築するためのベースラインとして、シンプルな PSTN ゲートウェイ構成を使用できます。この場合、Unified Communications Manager は、すべての PSTN および Webex Calling コールのルーティングと処理を一元化します。

Unified Communications Manager がすべての PSTN および Webex Calling コールのルーティングと処理を一元化したソリューションダイアグラム

このドキュメントでは、次の画像に示すホスト名、IP アドレス、およびインターフェイスが使用されます。オプションは、パブリックアドレスまたはプライベート（NAT の背後）アドレス指定用に提供されます。複数の CUBE インスタンス間でロード バランシングしない限り、SRV DNS レコードはオプションです。

証明書ベースのローカル ゲートウェイの設定で使用されるホスト名、IP アドレス、およびインターフェイス

このドキュメントの残りの構成ガイダンスを使用して、次のようにローカル ゲートウェイの設定を完了します。

  • ステップ 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 インターフェイスに割り当てることを確認します。

 インターフェイス GigabitEthernet0/0/0 説明 PSTN および/または CUCM の ip アドレスに面しているインターフェイス 192.168.80.14 255.255.255.0 ! インターフェイス GigabitEthernet0/0/1 の説明 Webex Calling (パブリック アドレス) ip アドレス 198.51.100.1 255.255.240 に面しているインターフェイス

2

対称暗号化を使用して、ルータの STUN クレデンシャルを保護します。プライマリ暗号化キーと暗号化タイプを次のように設定します。

 key config-key password-encrypt YourPassword パスワード暗号化 aes
3

サポートされている 証明機関 (CA) によって署名されたドメインの証明書を使用して暗号化トラストポイントを作成します。

  1. 次の exec コマンドを使用して RSA 鍵ペアを作成します。

    暗号キーの生成 rsa 汎鍵エクスポートラベル lgw-key modulus 4096

  2. 次の設定コマンドを使用して、証明書のトラストポイントを作成し、証明書署名要求で使用するフィールド値を指定します。 

     crypto pki trustpoint LGW_CERT 登録ターミナル pem fqdn none subject-name cn=cube1.lgw.com subject-alt-name cube1.lgw.com revocation-check none rsakeypair lgw-key hash sha256

    証明書フィールドのノート:

    • fqdn: これは Webex Calling の必須フィールドではありません。この設定を [なし] に設定すると、証明書署名要求に含まれないことを確認します。このコマンドを使用して FQDN を含める必要がある場合、ローカル ゲートウェイの操作には影響しません。

    • 件名: ローカル ゲートウェイからのコールを検証するには、Webex は SIP 連絡先ヘッダーの FQDN と SBC 証明書のサブジェクト共通名 (CN) 属性または SAN フィールドに含まれるサブジェクト代替名 (SAN) フィールドのいずれかに一致する必要があります。したがって、件名フィールドには少なくとも CN 属性を含める必要がありますが、必要に応じて、他の属性を含めることもできます。詳細については、件名を参照してください。

    • subject-alt-name: SBC 証明書のサブジェクト代替名（SAN）フィールドには、追加の FQDN のリストを含めることができます。証明書の件名 CN 属性が一致しない場合、WEBEX はこのリストをチェックして、ローカル ゲートウェイからのメッセージの SIP 連絡先ヘッダーを検証します。

    • ハッシュ: CSR は SHA256 を使用して署名することを強く推奨します。このアルゴリズムは、Cisco IOS XE 17.11.1 からデフォルトで使用され、以前のリリースでこのコマンドを使用して明示的に設定する必要があります。

  3. 次の exec または設定コマンドで証明書署名リクエスト（CSR）を生成し、サポートされている CA プロバイダーから署名付き証明書を要求するために使用します。

    暗号 pki 登録 LGW_CERT

4

ホスト証明書の認証に使用される中間署名 CA の証明書を提供します。次の exec または configuration コマンドを入力します。

 暗号 pki 認証 LGW_CERT

5

次の exec または設定コマンドを使用して、署名付きホスト証明書をインポートします。

 暗号 pki インポート LGW_CERT 証明書

6

TLS1.2 の排他性を有効にし、次の設定コマンドを使用して、音声アプリケーションに使用するデフォルトのトラストポイントを指定します。

 sip-ua 暗号シグナリングデフォルト トラストポイント LGW_CERT トランスポート tcp tls v1.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
 ip http クライアント ソースインターフェイス GigabitEthernet0/0/1 暗号 pki trustpool インポート クリーン URL https://www.cisco.com/security/pki/trs/ios_core.p7b
Webex Calling 証明書ベースのトランクを設定
1

Control Hub の既存のロケーションに対して CUBE 証明書ベースの PSTN トランクを作成します。詳細については、「Webex Calling のトランク、ルート グループ、ダイヤル プランを構成する」を参照してください。

トランクが作成されると、提供されたトランク情報をメモします。以下の図でハイライトされているこれらの詳細は、このガイドの設定手順で使用されます。

CUBE 証明書ベースの PSTN トランクが作成されます
2

次のコマンドを入力して、CUBE を Webex Calling ローカル ゲートウェイとして設定します。

 voice service voip ip address trusted list ipv4 x.x.x.x y.y.y モード border-element allow-connections sip to sip supplementary-service sip refer stun stun flowdata agent-id 1 boot-count 4 stun flowdata shared-secret 0 パスワード123$ sip asymmetric payload full early-offer forced sip-profiles inbound

以下は、設定のフィールドの説明です。

 ip アドレスの信頼リスト  ipv4 x.x.x.x y.y.y

  • 有料詐欺から保護するために、信頼できるアドレス リストは、ローカル ゲートウェイが合法的な VoIP コールを期待するホストとネットワークエンティティのリストを定義します。

  • デフォルトでは、ローカル ゲートウェイは、信頼リストに含まれていない IP アドレスからのすべての着信 VoIP メッセージをブロックします。デフォルトでは、「セッション ターゲット IP」またはサーバ グループ IP アドレスを持つ静的に設定されたダイヤル ピアが信頼されます。これらの IP アドレスを信頼リストに追加する必要はありません。

  • ローカル ゲートウェイを設定するときに、地域の Webex Calling データ センターの IP サブネットをリストに追加します。詳細については、「Webex Calling のポート参照情報 」を参照してください。また、Unified Communications Manager サーバ（使用されている場合）と PSTN トランク ゲートウェイのアドレス範囲を追加します。

  • 料金詐欺を防ぐために IP アドレス信頼リストを使用する方法の詳細については、「信頼された IP アドレス」を参照してください。

モードの境界要素

プラットフォームで Cisco Unified Border Element（CUBE）機能を有効にします。

allow-connections sip to sip

CUBE の基本 SIP バックツーバックのユーザー エージェント機能を有効にします。詳細については、「接続を許可する」を参照してください。

デフォルトでは、T.38 ファックス トランスポートが有効になっています。詳細については、ファックス プロトコル t38 (音声サービス) を参照してください。

ストーン

STUN (NAT 経由の UDP のセッション トラバーサル) をグローバルに有効にします。

これらのグローバル stun コマンドは、ローカル ゲートウェイを NAT の背後に展開する場合にのみ必要です。

  • ローカル ゲートウェイの STUN バインディング機能を使用すると、ネゴシエートされたメディア パスを介して、ローカルで生成された STUN 要求を送信できます。これにより、ファイアウォールのピンホールを開くことができます。

詳細については、stun flowdata agent-id および stun flowdata shared-secret を参照してください。

非対称ペイロード (フル)

DTMF と動的コーデック ペイロードの両方に対して SIP 非対称ペイロード サポートを設定します。このコマンドの詳細については、非対称ペイロードを参照してください。

early-offer forced

ローカル ゲートウェイが、隣接ピアからの確認応答を待つ代わりに、最初の INVITE メッセージで SDP 情報を送信するように強制します。このコマンドの詳細については、早期オファーを参照してください。

SIP プロファイル インバウンド

CUBE が SIP プロファイルを使用してメッセージを受信したときに変更できるようにします。プロファイルはダイヤルピアまたはテナント経由で適用されます。

3

すべてのトランクに対して G.711 コーデックのみを許可する音声クラス コーデック 100 を設定します。このシンプルなアプローチは、ほとんどの導入に適しています。必要に応じて、発信元システムと終端システムの両方でサポートされている追加のコーデック タイプをリストに追加できます。

DSP モジュールを使用したトランスコーディング を含むより複雑なソリューションはサポートされていますが、このガイドには含まれていません。 

 音声クラス コーデック 100 コーデックの設定 1 g711ulaw コーデックの設定 2 g711alaw

以下は、設定のフィールドの説明です。

音声クラス コーデック 100

SIP トランク コールの優先コーデックのみを許可するために使用されます。詳細については、音声クラス コーデックを参照してください。

4

音声クラス stun-usage 100 を設定して、Webex Calling トランクで ICE を有効にします。(このステップは、政府版 Webex には適用されません)

 音声クラス stun-usage 100 stun-usage firewall-traversal flowdata stun-usage ice lite

以下は、設定のフィールドの説明です。

STUNの使用法ice lite

可能なときは常に、メディア最適化を可能にする、すべての Webex Calling でダイヤルピアで ICE-Lite を有効にします。詳細については、音声クラス stun 使用状況 および使用状況のice liteを参照してください。

stun usage firewall-traversal flowdata コマンドは、NAT の背後にローカル ゲートウェイを展開する場合にのみ必要です。

メディアの最適化は、可能な限り、ネゴシエートされます。通話に録画などのクラウド メディア サービスが必要な場合、メディアを最適化できません。

5

Webex トラフィックのメディア暗号化ポリシーを設定します。(このステップは、政府版 Webex には適用されません)

 音声クラス srtp-crypto 100 暗号 1 AES_CM_128_HMAC_SHA1_80

以下は、設定のフィールドの説明です。

音声クラス srtp-crypto 100

オファーと応答メッセージの SDP で唯一の SRTP 暗号スイート CUBE が提供されるため、SHA1_80 を指定します。Webex Calling は SHA1_80 のみをサポートします。詳細については、「voice class srtp-crypto」を参照してください。

6

FIPS 対応 GCM 暗号を構成します(このステップは政府版 Webex にのみ適用されます)。 

 音声クラス srtp-crypto 100 暗号 1 AEAD_AES_256_GCM

以下は、設定のフィールドの説明です。

音声クラス srtp-crypto 100

CUBE が提供する暗号スイートとして GCM を指定します。政府版 Webex のローカル ゲートウェイの GCM 暗号を設定する必要があります。

7

宛先 FQDN または SRV に基づいて、ローカル ゲートウェイ トランクへのコールを一意に識別するパターンを設定します。

 音声クラス uri 100 sip パターン cube1.lgw.com

以下は、設定のフィールドの説明です。

音声クラス uri 100 sip

着信 SIP 招待を着信トランクダイヤルピアに一致させるパターンを定義します。このパターンを入力する場合は、トランク用に Control Hub で設定されたトランク FQDN または SRV を使用します。

8

SIP メッセージ操作プロファイルを設定します。ゲートウェイにパブリック IP アドレスが設定されている場合は、次のようにプロファイルを設定するか、NAT を使用している場合は、次のステップにスキップします。この例では、cube1.lgw.com はローカル ゲートウェイに設定されている FQDN です。

 voice class sip-profiles 100 rule 10 リクエスト すべての sip-header 連絡先変更 "@.*:" "@cube1.lgw.com:" rule 20 応答 すべての sip-header 連絡先変更 "@.*:" "@cube1.lgw.com:"

以下は、設定のフィールドの説明です。

ルール 10 と 20

Webex がローカル ゲートウェイからのメッセージを認証できるようにするには、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 プロファイル 
 音声クラス sip-profiles 100 rule 10 リクエスト ANY sip-header Contact modify "@.*:" "@cube1.lgw.com:" rule 20 response any sip-header Contact modify "@.*:" "@cube1.lgw.com:" rule 30 response ANY sdp-header Audio-Attribute modify "(a=candidate:1) 1.*) 10.80.13.12" "\1 192.65.79.20" rule 31 応答 ANY sdp-header Audio-Attribute modify "(a=candidate:1 2.*) 10.80.13.12" "\1 192.65.79.20" rule 40 response ANY sdp-header Audio-Connection-Info change "IN IP4 10.80.13.12" "IN IP4 192.65.79.20" RULE 41 REQUEST ANY sdp-header Audio-Connection-Info change "IN IP4 10.80.13.12" "IN IP4 192.65.79.20" RULE 50 REQUEST ANY SDP-HEADER Connection-Info CHANGE "IN IP4 10.80.13.12" "IN IP4 192.65.79.20" RULE 51 RESPONSE ANY sdp-header Connection-Info change "IN IP4 10.80.13.12" "IN IP4 192.65.79.20" RULE 60 RESPONSE ANY sdp-header Session-Owner modify "IN IP4 10.80.13.12" "IN IP4 192.65.79.20" RULE 70 REQUEST ANY sdp-header Audio-Attribute modify"(a=rtcp:.*) 10.80.13.12" "\1 192.65.79.20" rule 71 response any sdp-header Audio-Attribute modify "(a=rtcp:.*) 10. 1.*) 10.80.13.12" "\1 192.65.79.20" rule 81 リクエスト ANY sdp-header Audio-Attribute modify "(a=candidate:1 2.*) 10.80.13.12" "\1 192.65.79.20"

以下は、設定のフィールドの説明です。

ルール 10 と 20

Webex がローカル ゲートウェイからのメッセージを認証できるようにするには、SIP リクエストと応答メッセージの「Contact」ヘッダーに Control Hub のトランクにプロビジョニングされた値が含まれている必要があります。これは、単一のホストの FQDN か、デバイスのクラスタに使用される SRV 名になります。

ルール 30 ～ 81

プライベート アドレスの参照をサイトの外部パブリック アドレスに変換し、Webex が後続のメッセージを正しく解釈してルーティングできるようにします。

Webex Calling からの着信メッセージの SIP プロファイル 
 音声クラス sip-profiles 110 rule 10 応答 ANY sdp-header Video-Connection-Info 変更 "192.65.79.20" "10.80.13.12" rule 20 応答 ANY sip-header Connection-Info 変更 "@.*:" "@cube1.lgw.com:" rule 30 応答 ANY sdp-header Connection-Info 変更 "192.65.79.20" "10.80.13.12" rule 40 応答 ANY sdp-header Audio-Connection-Info 変更 "192.65.79.20" "10.80.13.12" rule 50 応答 ANY sdp-header Session-Owner 変更 "192.65.79.20" "10.80.13.12" rule 60 応答 ANY sdp-header Audio-Attribute 変更 "(a=candidate:1 1.*) 192.65.79.20" "\1 10.80.13.12" rule 70 応答 ANY sdp-header Audio-Attribute modify "(a=candidate:1 2.*) 192.65.79.20" "\1 10.80.13.12" rule 80 応答 ANY sdp-header Audio-attribute modify "(a=rtcp:.*) 192.65.79.20" "\1 10.80.13.12"

以下は、設定のフィールドの説明です。

ルール 10 ～ 80

パブリック アドレス参照を設定したプライベート アドレスに変換し、CUBE が Webex からのメッセージを処理できるようにします。

詳細については、音声クラス sip-profiles を参照してください。

米国またはカナダの PSTN プロバイダーは、Webex Calling のスパムまたは詐欺通話の表示 の記事で言及されている追加設定を使用して、スパムおよび詐欺通話の発信者 ID 検証を提供できます。

10

ヘッダー変更プロファイルを使用して、SIP オプション キープアライブを設定します。

 voice class sip-profiles 115 rule 10 request OPTIONS sip-header 連絡先変更 "<sip:.*:" "<sip:cube1.lgw.com:" rule 30 要求 ANY sip-header 変更経由 "(SIP.*) 10.80.13.12" "\1 192.65.79.20" rule 40 応答 ANY sdp-header Connection-Info 変更 "10.80.13.12" "192.65.79.20" rule 50 応答 ANY sdp-header Audio-Connection-Info 変更 "10.80.13.12" "192.65.79.20" ! voice class sip-options-keepalive 100 説明 Webex Calling up-interval 5 transport tcp tls sip-profiles 115

以下は、設定のフィールドの説明です。

音声クラス 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 トランクの設定:

  1. 音声クラス テナント 100 を作成して、Webex Calling トランクに特別に必要な設定を定義し、グループ化します。このテナントに関連付けられているダイヤルピアは、後でこれらの設定を継承します。

    次の例では、ステップ 1 で説明されている値を、このガイドの目的で使用しています（太字で示されています）。設定内のトランクの値に置き換えます。

     voice class tenant 100 no remote-party-id sip-server dns:us25.sipconnect.bcld.webex.com srtp-crypto 100 localhost dns:cube1.lgw.com session transport tcp tls no session refresh error-passthru rel1xx disable asserted-id pai bind control source-interface GigabitEthernet0/0/1 bind media source-interface GigabitEthernet0/0/1 no pass-thru content custom-sdp sip-profiles 100 sip-profiles 110 inbound privacy-policy passthru !

    以下は、設定のフィールドの説明です。

    音声クラス テナント 100

    独自の TLS 証明書と CN または SAN 検証リストを持つトランクを設定するには、テナントを使用することをお勧めします。ここでは、テナントに関連付けられた tls プロファイルには、新しい接続を受け入れまたは作成するために使用される信頼ポイントが含まれており、着信接続を検証するための CN または SAN リストがあります。詳細については、音声クラス テナントを参照してください。

    no remote-party-id

    Webex Calling が PAI をサポートしているため、SIP Remote-Party-ID (RPID) ヘッダーを無効にします。これは asserted-id pai コマンドを使用して有効になります。詳細については、remote-party-id を参照してください。

    sip サーバ dns: us25.sipconnect.bcld.webex.com

    トランクのターゲット SIP サーバを設定します。トランクを作成したときに、Control Hub で提供されたエッジ プロキシ SRV アドレスを使用します

    srtp-crypto 100

    SRTP コール レッグ（接続）の優先暗号スイートを設定します（ステップで指定）5). 詳細については、「voice class srtp-crypto」を参照してください。

    ローカルホスト DNS: cube1.lgw.com

    発信メッセージの From、Call-ID、および Remote-Party-ID ヘッダー内の物理 IP アドレスを提供された FQDN で置き換えるように CUBE を設定します。ここでトランクのために Control Hub で設定されたトランク FQDN または SRV を使用します。

    session transport tcp tls

    関連するダイヤルピアの TLS へのトランスポートを設定します。詳細については、session-transport を参照してください。

    セッションの更新がありません

    CUBE と Webex 間の通話の SIP セッション更新を無効にします。詳細については、セッションの更新を参照してください。

    error-passthru

    SIP エラー応答パススルー機能を指定します。詳細については、error-passthru を参照してください。

    rel1xx を無効にする

    Webex Calling トランクに対する信頼できる仮応答の使用を無効にします。詳細については、rel1xx を参照してください。

    asserted-id pai

    (オプション) P-Asserted-Identity ヘッダー処理をオンにし、これが Webex Calling トランクに使用する方法を制御します。

    Webex Calling には、ローカル ゲートウェイへの発信コール INVITE の P-Asserted-Identity (PAI) ヘッダーが含まれています。

    このコマンドが設定されている場合、PAI ヘッダーからの発信者情報を使用して、発信元および PAI/Remote-Party-ID ヘッダーに入力します。

    このコマンドが設定されていない場合、From ヘッダーの発信者情報を使用して、発信 From ヘッダーと PAI/Remote-Party-ID ヘッダーに入力します。

    詳細については、asserted-id を参照してください。

    bind control source-interface GigabitEthernet0/0/1

    Webex Calling に送信されるメッセージのソース インターフェイスと関連する IP アドレスを設定します。詳細については、バインドを参照してください。

    bind media source-interface GigabitEthernet0/0/1

    Webex Calling に送信されるメディアのソース インターフェイスと関連する IP アドレスを設定します。詳細については、バインドを参照してください。

    voice-class SIP プロファイル 100

    アウトバウンド メッセージに使用するヘッダー変更プロファイル（パブリック IP または NAT アドレッシング）を適用します。詳細については、「voice-class sip profiles」を参照してください。

    音声クラス SIP プロファイル 110 インバウンド

    NAT のみの背後にある LGW 展開の場合: 着信メッセージに使用するヘッダー変更プロファイルを適用します。詳細については、音声クラス sip プロファイルを参照してください。

    privacy-policy passthru

    受信メッセージから次のコール レッグにプライバシー ヘッダーを透過的に渡すように CUBE を設定します。詳細については、プライバシー ポリシーを参照してください。

  2. Webex Calling トランクのダイヤルピアを設定します。

     ダイヤルピア ボイス 100 voip の説明 インバウンド/アウトバウンド Webex Calling の宛先パターン BAD.BAD セッション プロトコル sipv2 セッション ターゲット sip-server 着信 uri リクエスト 100 voice-class codec 100 voice-class stun-usage 100 voice-class sip tenant 100 voice-class sip options-keepalive profile 100 dtmf-relay rtp-nte srtp no vad

    以下は、設定のフィールドの説明です。

     ダイヤルピア ボイス 100 voip  の説明 着信/発信 Webex Calling

    タグ 100 で VoIP ダイヤルピアを定義し、管理とトラブルシューティングを容易にする意味のある説明を提供します。詳細については、ダイヤルピアの音声を参照してください。

    宛先パターン BAD.BAD

    着信ダイヤルピア グループを使用して発信コールをルーティングする場合は、ダミー通知先パターンが必要です。この場合、有効な宛先パターンを使用できます。詳細については、「destination-pattern (interface)」を参照してください。

    session protocol sipv2

    このダイヤル ピアが SIP コール レッグを処理するように指定します。詳細については、セッション プロトコル (ダイヤルピア) を参照してください。

    session target sip-server

    テナント 100 で定義された SIP サーバが継承され、このダイヤル ピアからのコールの宛先に使用されることを示します。

    着信 uri リクエスト 100

    INVITE 要求ヘッダー URI を使用して、着信コールをこのダイヤルピアに照合するために使用される音声クラスを指定します。詳細については、着信 uri を参照してください。

    音声クラスのコーデック 100

    Webex Calling 間の通話のコーデック フィルター リストを示します。詳細については、音声クラス コーデックを参照してください。

    音声クラス 使用量

    ローカル ゲートウェイからローカルで生成された STUN 要求を、ネゴシエートされたメディア パスを介して送信できるようにします。STUN パケットは、メディア トラフィックのためのファイアウォール ピンホールを開き、メディア最適化のための有効なパスを検出するのに役立ちます。

    音声クラス SIP テナント 100

    ダイヤル ピアは、グローバルおよびテナント 100 で設定されたすべてのパラメータを継承します。パラメータは、ダイヤルピア レベルでオーバーライドされる場合があります。詳細については、「voice-class sip tenant」を参照してください。

    voice-class sip options-keepalive profile 100

    このコマンドは、特定のプロファイル（100）を使用して、SIP サーバまたはエンドポイントのグループの可用性を監視するために使用されます。

    srtp

    コールレグの SRTP を有効にする。

SIP PSTN トランクを使用したローカル ゲートウェイの設定

上記で 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 ホスト ipv4:192.168.80.13

以下は、設定のフィールドの説明です。

音声クラス uri 200 sip

着信 SIP 招待を着信トランクダイヤルピアに一致させるパターンを定義します。このパターンを入力する場合は、IP PSTN ゲートウェイの IP アドレスを使用します。詳細については、音声クラス uri を参照してください。

2

次の IP PSTN ダイヤル ピアを設定します。

 ダイヤルピア ボイス 200 voip の説明 インバウンド/アウトバウンド IP PSTN トランクの宛先パターン BAD.BAD セッション プロトコル sipv2 セッション ターゲット ipv4:192.168.80.13 200 voice-class sip asserted-id pai voice-class sip bind control source-interface GigabitEthernet0/0/0 voice-class sip bind media source-interface GigabitEthernet0/0/0 voice-class codec 100 dtmf-relay rtp-nte no vad

以下は、設定のフィールドの説明です。

 ダイヤルピア ボイス 200 voip  の説明 着信/発信 IP PSTN トランク

タグ 200 で VoIP ダイヤルピアを定義し、管理とトラブルシューティングを容易にする意味のある説明を提供します。詳細については、ダイヤルピアの音声を参照してください。

宛先パターン BAD.BAD

着信ダイヤルピア グループを使用して発信コールをルーティングする場合は、ダミー通知先パターンが必要です。この場合、有効な宛先パターンを使用できます。詳細については、「destination-pattern (interface)」を参照してください。

session protocol sipv2

このダイヤル ピアが SIP コール レッグを処理するように指定します。詳細については、セッション プロトコル (ダイヤル ピア) を参照してください。

セッション ターゲット ipv4: 192.168.80.13

PSTN プロバイダーに送信されるコールのターゲット アドレスを指定します。これは IP アドレスまたは DNS ホスト名です。詳細については、セッション ターゲット (VoIP ダイヤル ピア) を参照してください。

200 経由の着信 uri

INVITE 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/0

PSTN に送信されるメディアのソース インターフェイスと関連する IP アドレスを設定します。詳細については、バインドを参照してください。

音声クラスのコーデック 100

共通のコーデック フィルター リスト 100 を使用するようにダイヤル ピアを設定します。詳細については、音声クラス コーデックを参照してください。

dtmf-relay rtp-nte

通話レグで予想される DTMF 機能として RTP-NTE (RFC2833) を定義します。詳細については、「DTMF リレー (音声オーバー IP)」を参照してください。

no vad

音声アクティブティの検出を無効にします。詳細については、vad (ダイヤル ピア) を参照してください。

3

ローカル ゲートウェイを Webex Calling と PSTN 間のコールのみをルーティングするように設定している場合は、次のコール ルーティング設定を追加します。Unified Communications Manager プラットフォームを使用してローカル ゲートウェイを設定する場合は、次のセクションに進みます。

  1. ダイヤルピア グループを作成して、Webex Calling または PSTN にコールをルーティングします。Webex Calling 向け発信ダイヤルピア 100 で DPG 100 を定義します。DPG 100 は、PSTN からの着信ダイヤルピアに適用されます。同様に、PSTN に向けて発信ダイヤルピア 200 を使用して DPG 200 を定義します。DPG 200 は、Webex からの着信ダイヤルピアに適用されます。

     音声クラス dpg 100 の説明 Webex Calling のダイヤルピア 100 音声クラス dpg 200 の説明 コールを PSTN ダイヤルピア 200 にルーティングする

    以下は、設定のフィールドの説明です。

    ダイヤルピア 100

    発信ダイヤルピアをダイヤルピア グループに関連付けます。詳細については、voice-class dpg を参照してください。

  2. ダイヤルピア グループを適用して、Webex から PSTN および PSTN から Webex に通話をルーティングします。 

     ダイヤルピア ボイス 100 宛先 dpg 200 ダイヤルピア ボイス 200 宛先 dpg 100

    以下は、設定のフィールドの説明です。

    宛先 dpg 200

    どのダイヤルピア グループを指定し、この着信ダイヤルピアに表示されるコールのアウトバウンド処理に使用するかを指定します。

    これにより、ローカル ゲートウェイの設定が終了します。CUBE 機能が初めて設定される場合は、設定を保存し、プラットフォームを再読み込みします。

TDM PSTN トランクを使用したローカル ゲートウェイの設定

Webex Calling に向かってトランクを構築した後、次の構成を使用して、ループバック コール ルーティングを持つ PSTN サービスの TDM トランクを作成し、Webex コール レッグのメディア最適化を可能にします。

IP メディアの最適化を必要としない場合は、SIP PSTN トランクの設定手順に従います。PSTN VoIP ダイヤルピアの代わりに、音声ポートと POTS ダイヤルピア（ステップ 2 と 3 に示すように）を使用します。

1

ループバック ダイヤル ピア設定では、ダイヤル ピア グループとコール ルーティング タグを使用して、コール ルーティング ループを作成することなく、コールが Webex と PSTN の間で正しくパスされるようにします。コール ルーティング タグを追加および削除するために使用される次のトランスレーション ルールを設定します。

 音声翻訳ルール 100 ルール 1 /^\+//A2A/ 音声翻訳プロファイル 100 呼び出された音声翻訳ルール 200 ルール 1 /^//A1A/ 音声翻訳プロファイル 200 呼び出された音声翻訳ルール 11 ルール 1 /^A1A/ // 音声翻訳プロファイル 11 呼び出された音声翻訳ルール 12 ルール 1 /^A2A44//0/ RULE 2/^A2A//00/ 音声翻訳プロファイル 12 呼び出された音声翻訳ルール 12

以下は、設定のフィールドの説明です。

音声翻訳ルール

ルールで定義された正規表現を使用して、コール ルーティング タグを追加または削除します。十進法を超える数字（「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 インターフェイスの基本設定には、以下が含まれる場合があります。

 カードタイプ e1 0 2 つの isdn スイッチタイプ primary-net5 コントローラ E1 0/2/0 pri-group タイムスロット 1-31
3

次の TDM PSTN ダイヤル ピアを設定します。

 ダイヤルピア ボイス 200 ポット説明 着信/発信 PRI PSTN トランクの宛先パターン BAD.BAD translation-profile 着信 200 直通ダイヤルポート 0/2/0:15

以下は、設定のフィールドの説明です。 

 ダイヤルピアの音声 200 ポット  の説明 着信/発信 PRI 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 にルーティングされます。ルーティング タグを削除した後、コールはダイヤルピア グループを使用して発信トランクにルーティングされます。

 dial-peer voice 10 voip description Outbound loop-around leg destination-pattern BAD.BAD session protocol sipv2 session target ipv4:192.168.80.14 voice-class sip bind control source-interface GigabitEthernet0/0/0 dtmf-relay rtp-nte codec g711alaw no vad dial-peer voice 11 voip description Webex translation-profile inbound 11 session protocol sipv2 incoming called-number A1AT voice-class sip bind control source-interface GigabitEthernet0/0/0 dtmf-relay rtp-nte codec g711alaw no vad dial-peer voice 12 voip description PSTN translation-profile incoming 12 session protocol sipv2 incoming called-number A2AT voice-class sip bind control source-interface GigabitEthernet0/0/0 dtmf-relay rtp-nte codec g711alaw no vad dial-peer voice 12 voip description PSTN translation-profile incoming 12 session protocol sipv2 incoming called-number A2AT voice-class sip bind control source-interface GigabitEthernet0/0/0 dtm

以下は、設定のフィールドの説明です。 

 ダイヤルピア ボイス 10 voip  説明 アウトバウンドループバックレッグ

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

次のコール ルーティング設定を追加します。

  1. ダイヤルピア グループを作成して、ループバック経由で PSTN と Webex トランク間のコールをルーティングします。

     音声クラス dpg 100 の説明 Webex Calling のダイヤルピア 100 音声クラス dpg 200 の説明 コールを PSTN ダイヤルピア 200 の音声クラス dpg 10 の説明 通話をループバックダイヤルピア 10 にルーティングする

    以下は、設定のフィールドの説明です。

    ダイヤルピア 100

    発信ダイヤルピアをダイヤルピア グループに関連付けます。詳細については、voice-class dpg を参照してください。

  2. ダイヤル ピア グループを適用して通話をルーティングします。

     ダイヤルピア ボイス 100 宛先 dpg 10 ダイヤルピア ボイス 200 宛先 dpg 10 ダイヤルピア ボイス 11 宛先 dpg 100 ダイヤルピア ボイス 12 宛先 dpg 200

    以下は、設定のフィールドの説明です。

    宛先 dpg 200

    どのダイヤルピア グループを指定し、この着信ダイヤルピアに表示されるコールのアウトバウンド処理に使用するかを指定します。

これにより、ローカル ゲートウェイの設定が終了します。CUBE 機能が初めて設定される場合は、設定を保存し、プラットフォームを再読み込みします。
ローカル ゲートウェイを既存の Unified CM 環境で構成する

前のセクションの PSTN-Webex Calling の設定は、Cisco Unified Communications Manager (UCM) クラスタに追加のトランクを含めるように変更できます。この場合、すべてのコールは Unified CM 経由でルーティングされます。ポート 5060 の UCM からのコールは PSTN にルーティングされ、ポート 5065 からのコールは Webex Calling にルーティングされます。この通話シナリオを含めるには、次の増分設定を追加できます。

1

以下の音声クラス URI を設定:

  1. ポート経由の SIP を使用して、Unified CM から Webex 通話を分類します。

     voice class uri 300 sip
 pattern :5065

  2. ポート経由の SIP を使用して、Unified CM から PSTN コールを分類します。

     音声クラス uri 400 sip パターン 192\.168\.80\.6[0-5]:5060

    発信元のアドレスとポート番号を記述した 1 つ以上のパターンを使用して、UCM からの着信メッセージを PSTN トランクに分類します。必要に応じて、正規表現を使用して、一致するパターンを定義することができます。

    上記の例では、192.168.80.60 ～ 65 およびポート番号 5060 の任意の IP アドレスに正規表現が使用されます。

2

Unified CM ホストへの SRV ルーティングを指定するには、次の DNS レコードを設定します。

IOS XE は、ターゲット UCM ホストとポートをローカルで判別するためにこれらのレコードを使用します。この設定では、DNS システムでレコードを設定する必要はありません。DNS を使用する場合は、これらのローカル設定は必要ありません。

 ip ホスト ucmpub.mydomain.com 192.168.80.60 ip ホスト ucmsub1.mydomain.com 192.168.80.61 ip ホスト ucmsub2.mydomain.com 192.168.80.62 ip ホスト ucmsub3.mydomain.com 192.168.80.63 ip ホスト ucmsub4.mydomain.com 192.168.80.64 ip ホスト ucmsub5.mydomain.com 192.168.80.65 ip ホスト _sip._udp.wxtocucm.io srv 0 1 5065 ucmpub.mydomain.com ip ホスト _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub1.mydomain.com ip ホスト _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub2.mydomain.com ip ホスト _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub3.mydomain.com ip ホスト _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub4.mydomain.com ip ホスト _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub5.mydomain.com ip ホスト _sip._udp.pstntocucm.io srv 0 1 5060 ucmpub.mydomain.com ip ホスト _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub1.mydomain.com ip ホスト _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub2.mydomain.com ip ホスト _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub3.mydomain.com ip ホスト _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub4.mydomain.com ip ホスト _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub5.mydomain.com

以下は、設定のフィールドの説明です。

次のコマンドにより、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

次のダイヤル ピアを設定します。

  1. Unified CM と Webex Calling 間の通話のダイヤル ピア:

     ダイヤルピア ボイス 300 voip の説明 UCM-Webex Calling トランクの宛先パターン BAD.BAD セッション プロトコル sipv2 セッション target dns:wxtocucm.io 着信 uri via 300 voice-class codec 100 voice-class sip bind control source-interface ギガビットイーサネット 0/0/0 voice-class sip bind media source-interface ギガビットイーサネット 0/0/0 dtmf-relay rtp-nte no vad

    以下は、設定のフィールドの説明です。

     ダイヤルピア ボイス 300 voip  の説明 UCM-Webex Calling トランク

    タグ 300 で VoIP ダイヤルピアを定義し、管理とトラブルシューティングを容易にする意味のある説明を提供します。

    destination-pattern BAD.BAD

    着信ダイヤルピア グループを使用して発信コールをルーティングする場合は、ダミー通知先パターンが必要です。この場合、有効な宛先パターンを使用できます。

    session protocol sipv2

    ダイヤルピア 300 が SIP コール レッグを処理するように指定します。詳細については、セッション プロトコル (ダイヤルピア) を参照してください。

    セッション ターゲット dns:wxtocucm.io

    DNS SRV 解決により複数の Unified CM ノードのセッション ターゲットを定義します。この場合、ローカルで定義された SRV レコード wxtocucm.io がコールを転送するために使用されます。

    incoming uri via 300

    音声クラス URI 300 を使用して、ソース ポート 5065 を使用して、Unified CM からすべての着信トラフィックをこのダイヤルピアに誘導します。詳細については、着信 uri を参照してください。

    音声クラスのコーデック 100

    Unified CM 間のコールのコーデック フィルタ リストを示します。詳細については、音声クラス コーデックを参照してください。

    bind control source-interface GigabitEthernet0/0/0

    PSTN に送信されるメッセージのソース インターフェイスと関連する IP アドレスを設定します。詳細については、バインドを参照してください。

    bind media source-interface GigabitEthernet0/0/0

    PSTN に送信されるメディアのソース インターフェイスと関連する IP アドレスを設定します。詳細については、バインドを参照してください。

    dtmf-relay rtp-nte

    通話レグで予想される DTMF 機能として RTP-NTE (RFC2833) を定義します。詳細については、「DTMF リレー (音声オーバー IP)」を参照してください。

    no vad

    音声アクティブティの検出を無効にします。詳細については、vad (ダイヤル ピア) を参照してください。

  2. Unified CM と PSTN 間の通話のダイヤル ピア:

     ダイヤルピア ボイス 400 voip の説明 UCM-PSTN トランクの宛先パターン BAD.BAD セッション プロトコル sipv2 セッション target dns:pstntocucm.io 着信 uri via 400 voice-class codec 100 voice-class sip bind control source-interface ギガビットイーサネット 0/0/0 voice-class sip bind media source-interface ギガビットイーサネット 0/0/0 dtmf-relay rtp-nte no vad

    以下は、設定のフィールドの説明です。

     ダイヤルピア ボイス 400 voip  の説明 UCM-PSTN トランク

    タグ 400 で VoIP ダイヤルピアを定義し、管理とトラブルシューティングを容易にする意味のある説明を提供します。

    destination-pattern BAD.BAD

    着信ダイヤルピア グループを使用して発信コールをルーティングする場合は、ダミー通知先パターンが必要です。この場合、有効な宛先パターンを使用できます。

    session protocol sipv2

    ダイヤルピア 400 が SIP コール レッグを処理するように指定します。詳細については、セッション プロトコル (ダイヤルピア) を参照してください。

    セッションターゲット dns:pstntocucm.io

    DNS SRV 解決により複数の Unified CM ノードのセッション ターゲットを定義します。この場合、ローカルで定義された SRV レコード pstntocucm.io がコールを転送するために使用されます。

    400 経由の着信 uri

    音声クラス URI 400 を使用して、ソース ポート 5060 を使用して指定された Unified CM ホストからのすべての着信トラフィックをこのダイヤルピアに誘導します。詳細については、着信 uri を参照してください。

    音声クラスのコーデック 100

    Unified CM 間のコールのコーデック フィルタ リストを示します。詳細については、音声クラス コーデックを参照してください。

    bind control source-interface GigabitEthernet0/0/0

    PSTN に送信されるメッセージのソース インターフェイスと関連する IP アドレスを設定します。詳細については、バインドを参照してください。

    bind media source-interface GigabitEthernet0/0/0

    PSTN に送信されるメディアのソース インターフェイスと関連する IP アドレスを設定します。詳細については、バインドを参照してください。

    dtmf-relay rtp-nte

    通話レグで予想される DTMF 機能として RTP-NTE (RFC2833) を定義します。詳細については、「DTMF リレー (音声オーバー IP)」を参照してください。

    no vad

    音声アクティブティの検出を無効にします。詳細については、vad (ダイヤル ピア) を参照してください。

4

次の設定を使用してコール ルーティングを追加します。

  1. ダイヤルピア グループを作成し、Unified CM と Webex Calling の間でコールをルーティングします。DPG 100 を 発信ダイヤルピア 100 で Webex Calling に対して定義します。DPG 100 は、Unified CM からの関連付けられた着信ダイヤルピアに適用されます。同様に、Unified CM に対して発信ダイヤルピア 300 を使用して DPG 300 を定義します。DPG 300 は、Webex からの着信ダイヤルピアに適用されます。

     音声クラス dpg 100 の説明 Webex Calling のダイヤルピア 100 音声クラス dpg 300 の説明 コールを Unified CM にルーティング Webex Calling トランク ダイヤルピア 300 にルーティング

  2. Unified CM と PSTN の間でコールをルーティングするためのダイヤル ピア グループを作成します。PSTN に対して発信ダイヤルピア 200 で DPG 200 を定義します。DPG 200 は、Unified CM から関連する着信ダイヤルピアに適用されます。同様に、Unified CM に対して発信ダイヤルピア 400 を使用して DPG 400 を定義します。DPG 400 は、PSTN からの着信ダイヤルピアに適用されます。

     音声クラス dpg 200 の説明 コールを PSTN ダイヤルピア 200 音声クラス dpg 400 の説明 コールを Unified CM PSTN トランクダイヤルピア 400 にルーティングする

    以下は、設定のフィールドの説明です。

    ダイヤルピア 100

    発信ダイヤルピアをダイヤルピア グループに関連付けます。詳細については、voice-class dpg を参照してください。

  3. ダイヤルピア グループを適用して、Webex から Unified CM および Unified CM から Webex に通話をルーティングします。 

     ダイヤルピア ボイス 100 宛先 dpg 300 ダイヤルピア ボイス 300 宛先 dpg 100

    以下は、設定のフィールドの説明です。

    宛先 dpg 300

    どのダイヤルピア グループを指定し、この着信ダイヤルピアに表示されるコールのアウトバウンド処理に使用するかを指定します。

  4. ダイヤルピア グループを適用して、PSTN から Unified CM から Unified CM から PSTN に通話をルーティングします。

     ダイヤルピア ボイス 200 宛先 dpg 400 ダイヤルピア ボイス 400 宛先 dpg 200

    これにより、ローカル ゲートウェイの設定が終了します。CUBE 機能が初めて設定されている場合、設定を保存し、プラットフォームを再読み込みします。

診断署名でローカル ゲートウェイを監視し、トラブルシューティングする

診断署名 (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 以上を実行するローカル ゲートウェイ

  1. 診断署名はデフォルトで有効になっています。

  2. デバイスが IOS XE 17.6.1 以降を実行している場合、プロアクティブ通知の送信に使用するセキュアなメール サーバーを構成します。

     ターミナル コールホーム メール サーバー  を設定します。@ 優先順位 1 セキュア tls エンド

  3. 通知する管理者 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% 以上に達すると、すべてのデバッグが無効し、ローカル ゲートウェイにインストールした診断署名をアンインストールします。下記の手順を実行して署名をインストールします。

  1. コマンドを使用して 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: 有効

  2. 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 使用率

    Diagnostic Signatures Lookup ツールから DS 64224 をダウンロードする

  3. 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 バイト

  4. ローカルゲートウェイに DS XML ファイルをインストールします。

     call-home diagnostic-signature load DS_64224.xml ロードファイル DS_64224.xml 成功

  5. 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 とメール通知が生成されます。 署名をインストールするには、以下の手順を使用してください。

  1. コマンド 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: 有効

  2. Diagnostic Signatures Lookup Tool の以下のオプションを使用して、DS 65221 をダウンロードします。

    フィールド名

    フィールド値

    プラットフォーム

    Cisco 4300、4400 ISR シリーズ、または Catalyst 8000V Edge ソフトウェア

    製品

    Webex Calling ソリューションの CUBE Enterprise

    問題の範囲

    パフォーマンス

    問題の種類

    メールおよび Syslog 通知による SIP の異常通話切断検出

  3. DS XML ファイルをローカルゲートウェイにコピーします。

    ftp://username:password@/DS_65221.xml bootflash:

  4. ローカルゲートウェイに DS XML ファイルをインストールします。 

     call-home diagnostic-signature load DS_65221.xml ロードファイル DS_65221.xml 成功

  5. コマンド 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 を使用して、以下の手順を使用して、診断データの収集を自動化します。

  1. 診断データをアップロードするために、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"

  2. コマンド show snmp を使用して、SNMP が有効 になっている必要があります。SNMP が有効になっていない場合は、snmp-server manager コマンドを設定します。

     show snmp %SNMP agent not enabled config t snmp-server manager end

  3. 高 CPU 使用率の期間中に、すべてのデバッグと診断署名を無効にすることを推奨するプロアクティブな措置として、高 CPU モニタリング DS 64224 をインストールすることを推奨します。Diagnostic Signatures Lookup Tool の以下のオプションを使用して、DS 64224 をダウンロードします。

    フィールド名

    フィールド値

    プラットフォーム

    Cisco 4300、4400 ISR シリーズ、または Catalyst 8000V Edge ソフトウェア

    製品

    Webex Calling ソリューションの CUBE Enterprise

    問題の範囲

    パフォーマンス

    問題の種類

    通知メールによる CPU 使用率が高い

  4. 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

  5. DS XML ファイルをローカルゲートウェイにコピーします。

     ftp://username:password@/DS_64224.xml bootflash: ftp://username:password@/DS_65095.xml bootflash:

  6. 高 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 成功

  7. 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

次のオプションから選択します:

  • パートナー管理者の場合は、[保存して閉じる] をクリックして、顧客管理者が Webex Calling のプロビジョニングを完了するようにします。
  • 必要なロケーションの情報を入力します。ウィザードでロケーションを作成した後、後で他にロケーションを作成できます。

セットアップ ウィザードを完了した後で、作成したロケーションにメイン番号を追加していることを確認してください。

7

このロケーションに適用する次の選択を行います。

  • アナウンス言語: 新規ユーザーと機能に関する音声アナウンスとプロンプト用。
  • メール言語—新規ユーザー向けのメール通信用。
  • 国
  • タイムゾーン
8

[次へ] をクリックします。

9

利用可能な Cisco Webex SIP アドレスを入力し、[次へ] をクリックし、[完了] を選択します。

ロケーションを追加する

始める前に

新しいロケーションを作成するには、以下の情報を指定します。

  • ロケーションの住所

  • 希望する電話番号(オプション)

1

https://admin.webex.com で Control Hub にログインし、[管理] > [ロケーション] に移動します。

新しいロケーションは、初回セットアップ ウィザードを使用して選択した国に対応する地域のデータ センターでホストされます。
2

ロケーションを設定します。

  • ロケーション名—ロケーションを識別する一意の名前を入力します。
  • 国/地域: ロケーションをリンクする国を選択します。たとえば、米国に 1 か所のロケーション (本社) を作成し、イギリスに別のロケーション (支社) を作成することができます。選択した国に応じて、その後の住所のフィールドが決まります。ここには、例として、米国の住所書式を使用したものがあります。
  • ロケーション アドレス—ロケーションのメーリングアドレスを入力します。
  • 市区町村—このロケーションの市区町村を入力します。
  • 州/県/地域—ドロップダウンから都道府県を選択します。
  • ZIP/郵便番号—郵便番号を入力します。
  • アナウンス言語: 新規ユーザーと機能に関する音声アナウンスやプロンプトの言語を選択します。
  • メール言語—新規ユーザーとのメール通信に使用する言語を選択します。
  • タイムゾーン—ロケーションのタイムゾーンを選択します。
3

[保存 ] をクリックしてから、[ はい/いいえ ] を選択して、現在または後でロケーションに番号を追加します。

4

[はい] をクリック した場合、次のいずれかのオプションを選択します。

  • Cisco PSTN—Cisco から Cloud PSTN ソリューションが必要な場合は、このオプションを選択します。Cisco 通話プランは、緊急通話、着信、および国内および国際通話を提供する PSTN 代替ソリューションであり、新しい PSTN 番号または既存の番号を Cisco にポートすることができます。

    Cisco PSTN オプションは、以下の条件でのみ表示されます。

    • コミットされた Cisco Calling プラン OCP (アウトバウンド通話プラン) を少なくとも 1 つ購入している。

    • Cisco Calling プランがサポートされている国にロケーションがある。

    • ロケーションが新規である。他の PSTN 機能が割り当てられている既存のロケーションは、今回は Cisco Calling プランの対象外です。サポートケースを登録 してガイダンスを受けてください。

    • Cisco Calling プランがサポートされている地域の Webex Calling データ センターでホストされています。

  • Cloud Connected PSTN—多くの Cisco CCP パートナーの 1 つからクラウド PSTN ソリューションを探している場合、またはロケーションで Cisco Calling プランが利用できない場合は、このオプションを選択します。CCP パートナーは、PSTN 代替ソリューション、グローバルな広域カバレッジ、広範でさまざまな機能、パッケージ、価格設定を提供しています。

    CCP パートナーと対応地域は、こちらにリストされています。ロケーションの国がサポートされているパートナーにのみ表示されています。パートナーは、ロゴで表示されるか、簡単な文字列と括弧で囲んだ地域名で表示されます (例: (EU)、(US)、または (CA))。ロゴが表示されているパートナーは、常に CCP の地域メディアを提供しています。文字列で表示されているパートナーについては、CCP の地域メディアを確保するために、ロケーションの国に最も近い地域を選択してください。

    リストされているプロバイダーの下に [番号を今すぐ注文する] オプションがある場合は、そのオプションを選択して、統合された CCP のメリットを利用することをおすすめします。統合された CCP の場合、電話番号の調達とプロビジョニングを Control Hub の 1 つのペインで行えます。統合されていない CCP の場合、Control Hub の外で、CCP パートナーから電話番号を調達する必要があります。

  • プレミスベースの PSTN (ローカル ゲートウェイ): 現在の PSTN プロバイダーを保持する場合、またはクラウド サイトで非クラウド サイトに接続する場合に、このオプションを選択できます。

PSTN オプションの選択は各ロケーション レベルで行います (各ロケーションには PSTN オプションが 1 つしかありません)。展開に対して必要な数のオプションを組み合わせることができますが、各ロケーションには 1 つのオプションとなります。PSTN オプションを選択してプロビジョニングしたら、ロケーションの PSTN プロパティで [管理] をクリックすると、オプションを変更できます。ただし、Cisco PSTN などの一部のオプションは、別のオプションが割り当てられた後は使用できない場合があります。サポートケースを登録 してガイダンスを受けてください。

5

番号を今すぐに有効にするか、または後で有効にするかを選択します。

6

統合されていない CCP またはプレミス ベースの PSTN を選択した場合は、電話番号をコンマ区切り値として入力し、[検証] をクリックします。

特定のロケーションのための番号が追加されます。有効なエントリは [検証済みの番号] フィールドに移動し、無効なエントリは [番号の追加] フィールドに残り、エラー メッセージが表示されます。

番号の書式は、ロケーションの所在する国に応じ、ダイヤリングに関する地元の要件に従って定められます。たとえば、国コードが必要な場合には、コードを付けて入力することも、コードなしで入力してからコードが自動的に先頭に追加されるようにすることもできます。

7

[保存] をクリックします。

次に行うこと

ロケーションを作成した後、そのロケーションの緊急 911 サービスを有効にすることができます。詳細については「Webex Calling の RedSky 緊急 911 サービス」を参照してください。

ロケーションを削除

開始する前に

関連付けられているユーザーとワークスペースを削除すると、使用されていない場所または正しく設定されていない場所を削除できます。ロケーションを削除すると、割り当てられたサービスと番号がすべて削除されます。

ロケーションに関連付けられているユーザーとワークスペースのリストを取得します。[サービス] > [Calling] > [番号] に進み、ドロップダウン メニューから削除するロケーションを選択します。ロケーションを削除する前に、これらのユーザーとワークスペースを削除する必要があります。

このロケーションに関連付けられている番号は、PSTN プロバイダーに解放されることに注意してください。これらの番号は所有されなくなります。

1

https://admin.webex.com で Control Hub にログインし、[管理] > [ロケーション] に移動します。

2

削除するロケーションの隣の [その他のオプション] ボタン [アクション] 列で をクリックします。

3

[場所 の削除] を選択し、その場所を削除します。

通常、ロケーションを完全に削除するには数分かかりますが、最大で 1 時間かかる場合があります。ステータスを確認するには、ロケーション名の隣にある [その他のオプション] ボタン をクリックして、[削除ステータス] を 選択します。

既存のロケーションを更新する

作成した後PSTNのセットアップ、名前、タイムゾーン、言語を変更できます。新しい言語は新しいユーザーとデバイスにのみ適用されることに注意してください。既存のユーザーおよびデバイスは古い言語を使用し続けます。

既存のロケーションについては、緊急時の 911 サービスを有効にすることができます。詳細については「Webex Calling の RedSky 緊急 911 サービス」を参照してください。

1

Control Hub にサインインします。

2

[管理] > [ロケーション] に移動します。

ロケーションの隣に [警告] 記号が表示される場合、そのロケーションの電話番号をまだ設定していないという意味です。その番号を設定するまで、通話の送受信が行えなんす。

3

(オプション) [PSTN 接続] の下で、すでに設定されているものに応じて、[クラウド接続 PSTN] または [プレミスベースの PSTN](ローカル ゲートウェイ) のいずれかを選択します。[管理] をクリックして設定を変更してから、[続行] を選択することにより、関連するリスクを承認します。以下のオプションのいずれかを選択して、[保存] クリックします。

  • Cisco PSTN—Cisco から Cloud PSTN ソリューションが必要な場合は、このオプションを選択します。Cisco 通話プランは、緊急通話、着信、および国内および国際通話を提供する PSTN 代替ソリューションであり、新しい PSTN 番号または既存の番号を Cisco にポートすることができます。

    Cisco PSTN オプションは、以下の条件でのみ表示されます。

    • コミットされた Cisco Calling プラン OCP (アウトバウンド通話プラン) を少なくとも 1 つ購入しました。

    • Cisco Calling プランがサポートされている国にロケーションがある。

    • Cisco Calling プランがサポートされている地域の Webex Calling データ センターでホストされています。

  • Cloud Connected PSTN—多くの Cisco CCP パートナーの 1 つからクラウド PSTN ソリューションを探している場合、またはロケーションで Cisco Calling プランが利用できない場合は、このオプションを選択します。CCP パートナーは、PSTN 代替ソリューション、グローバルな広域カバレッジ、広範でさまざまな機能、パッケージ、価格設定を提供しています。

    CCP パートナーと対応地域は、こちらにリストされています。ロケーションの国がサポートされているパートナーにのみ表示されています。パートナーは、ロゴで表示されるか、簡単な文字列と括弧で囲んだ地域名で表示されます (例(EU)、(米国)、または (CA)。ロゴが表示されているパートナーは、常に CCP の地域メディアを提供しています。文字列で表示されているパートナーについては、CCP の地域メディアを確保するために、ロケーションの国に最も近い地域を選択してください。

    リストされているプロバイダーに今すぐ番号を注文 するオプションが表示されている場合は、統合型 CCP を利用できるように、そのオプションを選択することをお勧めします。統合型 CCP を使用すると、Control Hub で電話番号のプロビジョニングとプロビジョニングを 1 つのペインで実行できます。統合されていない CCP では、Control Hub の外部で CCP パートナーから電話番号を取得する必要があります。

  • プレミスベースの PSTN (ローカル ゲートウェイ): 現在の PSTN プロバイダーを保持する場合、またはクラウド サイトで非クラウド サイトに接続する場合に、このオプションを選択できます。

    Webex Calling ゲートウェイで以前に設定されたロケーションを持つ顧客は、対応するトランクを使用してオンプレミス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

Control Hub にサインインします。

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 接続の変更が自動的に適用されます。

  • 注文の送信に失敗すると、サポート チケットが自動的に作成され、サポート チームに送信されます。

  • PSTN 接続の変更が複数の通信事業者からの複数の注文を必要とする場合、完了までに最大 10 営業日かかる場合があります。

移行の詳細は、[サービス] > [Calling] > [PSTN] > [注文] タブで利用できます。注文 ID を選択すると、サイドパネルビューで注文の詳細が表示されます。PSTN 接続変更から作成された注文では、タイプを [PSTN の変更] として確認できます。

PSTN 接続の変更をキャンセル

管理者は、ロケーションがまだ移行状態の場合、PSTN 移行をキャンセルできます。

1

Control Hub にサインインします。

2

[管理] > [ロケーション] に移動します。

3

PSTN 接続をキャンセルするロケーションを選択します。

4

[Calling] タブに移動し、[PSTN 接続変更をキャンセル] ボタンをクリックします。

5

[はい、続行 ] をクリックしてキャンセルを確認します。

Webex Calling ダイヤル プランを設定

アウトバウンド ダイヤル コードダイヤル プラン使用してWebex Callingシステムの設定をコントロールできます。内線の長さ、ルーティング プレフィックス、およびダイヤル設定 (内部と外部) が、ユーザーのダイヤル習慣に適合するようにカスタマイズします。

これらの設定は社内ダイヤルに適用されるものであり、最初のセットアップ ウィザードでも設定できます。ダイヤル プランを変更すると、Control Hub の更新にあるサンプルの番号が更新され、これらの変更が表示されます。

ロケーションの発信通話権限を設定できます。発信権限を設定するには、これらの手順 を参照してください。

1

Control Hub にサインインし、[サービス] > [Calling] > [サービス設定] に移動し、[内線ダイヤル] までスクロールします。

2

必要に応じて、次のオプションのダイヤル設定を行います。

  • ロケーション ルーティング プレフィックスの長さ—複数のロケーションがある場合は、この設定をお勧めします。1 ～ 7 桁の長さを入力できます。同じ内線を持つ複数のロケーションがある場合は、ロケーション間の通話時にプレフィックスをダイヤルする必要があります。たとえば、複数のストアがある場合、内線 1000 を使用すると、各ストアにルーティング プレフィックスを設定することができます。1 つのストアのプレフィックスが 888 の場合、そのストアに到達するために 8881000 にダイヤルします。

    • ルーティング プレフィックスの長には、ステアリング桁が含まれます。たとえば、ルーティング プレフィックスの長さを 4 に設定した場合、サイトを指定できるのは 3 桁のみです。

    • ルーティング プレフィックスをロケーションに割り当てると、そのロケーションに割り当てられた内線番号のすべてのアピアランスには、内線番号の前にルーティング プレフィックスが含まれます。たとえば、888-1000（ルーティング プレフィックス内線）などです。

  • ルーティング プレフィックスのステアリング桁—各ルーティング プレフィックスの最初の桁として設定する番号を選択します。
  • 内線番号の長さ—2 ～ 10 桁を入力でき、デフォルトは 2 です。

    内線の長さを増やしても、社内内線への既存のスピード ダイヤルは自動的に更新されません。

  • ロケーション間の内線ダイヤルを許可: 組織の要件に基づいて、ロケーション間の内線ダイヤルをカスタマイズできます。

    • 組織のすべてのロケーションで重複する内線番号がない場合は、トグルを有効にします。

      デフォルトでは、トグルが有効になっています。

    • 組織が異なるロケーションで同じ内線を持っている場合は、トグルを無効にします。トグルが無効になって発信者が内線番号をダイヤルすると、発信者と同じロケーションに一致する内線番号を持つユーザーにコールがルーティングされます。他のロケーションの内線番号に到達するには、発信者はエンタープライズ有意番号 (ロケーションのルーティングプレフィックス + 内線) をダイヤルする必要があります。

3

特定の場所の内部ダイヤルを指定します。[管理] > [ロケーション] に移動し、リストからロケーションを選択し、[通話] をクリックします。[ダイヤル] までスクロールし、必要に応じて内部ダイヤルを変更します。

  • 内線ダイヤル: あるロケーションのユーザーが別のロケーションの誰かに連絡するためにダイヤルする必要があるルーティング プレフィックスを指定します。各ロケーションのルーティング プレフィックスは固有である必要があります。プレフィックスの長さは組織レベルで設定された長さと一致することを推奨しますが、1 ～ 7 桁の長さである必要があります。
4

特定のロケーションの外線ダイヤルを指定します。[管理] > [ロケーション] に移動し、リストからロケーションを選択し、[通話] をクリックします。[ダイヤル] までスクロールし、必要に応じて外部ダイヤルを変更します。

  • 外線ダイヤル: ユーザーが外線に接続するためにダイヤルする必要がある発信ダイヤル番号を選択できます。デフォルトは [なし] であり、このダイヤル習慣が必要ない場合には、値を [なし] にしておくことができます。この機能を使用しない場合、組織のステアリング番号とは別の番号を使用することをお勧めします。

    ユーザーは、外線発信を行う際に外線発信番号を含め、レガシー システムでダイヤルしていた方法を真似たものにできます。しかし、すべてのユーザーは、発信ダイアル番号なしで外部通話を発信することができます。

  • オプションで、このロケーションの発信ダイヤル番号を強制する ことができます。これにより、ユーザーが外部コールを発信するために管理者が設定した発信ダイヤル番号を使用する必要があります。

    • この機能を有効にすると、発信ダイヤル番号の有無にかかわらず緊急コールをダイヤルできます。

      有効にすると、外線発信番号が含まれない外線番号 (通話転送に使用される番号など) が機能しなくなります。

    • 内線が国番号と同じ場合、内線が国番号よりも優先されます。したがって、発信ダイヤル番号を有効にすることを推奨します。

    • 着信および発信 PSTN 通話に E.164 番号形式を使用することを強くおすすめします。

ユーザーへの影響:

  • ダイヤル設定の変更を有効にするには、ユーザが電話を再起動する必要があります。

  • ユーザーの内線番号は、ロケーションのステアリング番号または発信ダイヤル番号と同じ番号で開始することはできません。

Control Hub でプレミス ベースの PSTN (ローカル ゲートウェイ) を設定する

付加価値再販業者の場合、これらの手順を使用して Control Hub でローカル ゲートウェイの設定を開始できます。このゲートウェイがクラウドに登録されると、Webex Calling の 1 つ以上のロケーションで使用して、エンタープライズ PSTN サービス プロバイダーへのルーティングを提供できます。

ローカル ゲートウェイがある場所は、ローカル ゲートウェイが他の場所で使用されているときには削除できません。

トランクを作成する

次の手順に従って、Control Hub でトランクを作成します。

始める前に

  • ロケーションが追加されたら、ロケーションに対してプレミスベース PSTN を設定する前に、トランクを作成する必要があります。

  • それぞれについて、ロケーションと固有の設定および番号を作成します。ロケーションはプレミスベース PSTN を追加する前に存在する必要があります。

  • Webex Calling でのプレミスベース PSTN (ローカル ゲートウェイ) 要件について理解しておいてください。

  • プレミスベース PSTN を持つロケーションに対して、複数のトランクを選択できませんが、複数のロケーションに対して同じトランクを選択することはできます。

1

https://admin.webex.com で Control Hub にログインし、[サービス] > [Calling] > [コール ルーティング] に移動し、[トランクの追加] を選択します。

2

ロケーションを選択します。

3

トランクの名前を指定し、[保存] をクリックします。

名前は 24 文字以内にしてください。

次にやる必要

トランクで設定する必要がある、関連するパラメーターが表示されます。また、PSTN 接続をセキュアにするための SIP ダイジェスト資格情報のセットも生成します。

画面 [ドメインの登録]、[トランク グループ 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 トランク セキュリティ プロファイルを作成します。

設定値
名前固有の名前 (Webex など)
説明Webex SIP トランク セキュリティ プロファイルなどの意味のある説明
着信ポートWebex 間のトラフィックでは、ローカル ゲートウェイ構成で使用されるポートと一致する必要があります。5065

ローカル ゲートウェイ トランクの SIP プロファイルを構成する

次の設定でローカル ゲートウェイ トランク用の専用の SIP プロファイルを作成します。

設定値
名前固有の名前 (Webex など)
説明Webex SIP プロファイルなどの意味のある説明
オプションの Ping を有効にして、サービス タイプ「なし (デフォルト)」のトランクの宛先ステータスをモニタします。選択

Webex からのコールのコール検索スペースを作成する

次の設定で Webex から発信されたコールのためのコール検索スペースを作成します。

設定値
名前固有の名前 (Webex など)
説明Webex Calling 検索スペースなどの意味のある説明
選択済みパーティション:

DN (+E.164 ディレクトリ番号)

ESN (サイト間ダイヤル)

PSTNInternational (PSTN アクセス)

onNetRemote (GDPR 学習先)

最後のパーティション onNetRemote は、Intercluster Lookup Service (ILS) または Global Dialplan Replication (GDPR) を使用して、Unified CM クラスター間でルーティング情報が交換されるマルチクラスター環境でのみ使用されます。

Webex 間で SIP トランクを構成する

次の設定を使用して、ローカル ゲートウェイ経由での Webex 間のコールに SIP トランクを作成します。

設定値
デバイス情報
DeviceName一意の名前 (Webex など)
説明Webex SIP トランクなどの意味のある説明
すべてのアクティブな Unified CM ノード上で実行する選択
着信コール
コール検索スペース以前に定義されたコール検索スペース:Webex
AAR コール検索スペース PSTN ルート パターンへのアクセス権のみを持つコール検索スペース: PSTNReroute
SIP 情報
接続先アドレスローカル ゲートウェイ CUBE の IP アドレス
移動先ポート5060
SIP トランク セキュリティ プロファイル定義済み:Webex
SIP プロファイル定義済み:Webex

Webex のルート グループを構成する

次の設定でルート グループを作成します。

設定値
ルート グループ情報
ルート グループ名一意の名前 (Webex など)
選択したデバイス以前に構成された SIP トランク:Webex

Webex のルート リストを構成する

次の設定でルート リストを作成します。

設定値
ルート リスト情報
名前固有の名前 (RL_Webex など)
説明Webex のルート リストなど、意味のある説明
すべてのアクティブな Unified CM ノード上で実行する選択
ルート リスト メンバー情報
選択したグループ以前に定義されたルート グループのみ:Webex

Webex の移動先のパーティションを作成する

次の設定で Webex の移動先のパーティションを作成します。

設定値
ルート リスト情報
名前一意の名前 (Webex など)
説明Webex パーティションなどの意味のある説明

次にやる必要

このパーティションは、Webex の宛先にアクセスする必要があるすべてのコール検索スペースに追加してください。このパーティションは、PSTN から Webex への発信がルーティングされるように、PSTN トランクの着信コール検索スペースとして使用されるコール検索スペースに特に追加する必要があります。

Webex の移動先のルート パターンを構成する

次の設定で Webex の各 DID 範囲のルート パターンを構成します。

設定値
ルートパターン「\」が頭文字にある Webex で DID 範囲のフル +E.164 パターン例: \+140855501XX
ルート パーティションWebex
ゲートウェイ/ルート リストRL_ Webex
緊急の優先事項選択

Webex の簡略サイト間ダイヤル正規化を構成する

短縮されたサイト間ダイヤルが Webex に必要な場合は、Webex の各 ESB 範囲にダイヤル正規化パターンを設定します。

設定値
翻訳パターンWebex の ESN 範囲の ESB パターン。例:80121XX
パーティションWebex
説明Webex 正規化パターンなどの意味のある説明
発信者のコール検索スペースを使用する選択
緊急の優先事項選択
後続ホップでの連続桁のタイムアウトを待たない選択
着信側トランスフォーム マスク番号を + E.164 に正規化するマスク。例: +140855501XX

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）] フィールドに入力された名前です。

実際の例を見てみましょう。このビデオ デモンストレーション で、Control Hub のユーザーの監視設定を管理する方法をご覧ください。

ユーザーのコール ブリッジ警告トーンを有効化

開始する前に

コール ブリッジを呼び出すには、共有回線を設定する必要があります。コール ブリッジ警告トーンを再生する前に、共有回線を設定する 方法を参照してください。
1

Control Hub にサインインし、[管理] > [ユーザー] に移動します。

2

ユーザーを選択し、[通話] タブをクリックします。

3

[ユーザー間権限] に移動し、[コール ブリッジング警告音] をクリックします。

4

[コール ブリッジング警告音] をオンにして、[保存] をクリックします。

デフォルトでは、この機能は有効になっています。

MPP 共有回線のコール ブリッジングの詳細については、「マルチプラットフォーム 卓上電話の共有回線」を参照してください。

Webex アプリの共有回線でのコール ブリッジングの詳細については、「WebexApp の共有回線アピアランス」を参照してください。

ユーザーのためにホテリングをオンにする

この機能を有効にすることで、ユーザーは主な卓上電話の機能性と機能を維持しながら、別のスペースで作業をすることができます。
1

https://admin.webex.com の顧客ビューから [管理] に移動し、[ユーザー] を選択します。

2

ユーザーを選択し、[通話] タブをクリックします。

3

[ユーザー間権限] セクションに進み、[ホテリング] を選択し、トグルをオンにします。

4

[ホテリング ロケーション] 検索フィールドにホテリング ホストの名前または番号を入力し、ユーザーに割り当てるホテリング ホストを選択します。

ホテリング ホストは 1 つのみ選択できます。別のホテリング ホストを選択した場合、最初のホストは削除されます。

ロケーション管理者の場合、割り当てられたロケーションに関連するホテリング ホストのみを割り当てることができます。

5

ユーザーがホテリング ホストに関連付けることができる時間を制限するには、[関連付け期間の制限] ドロップダウンから、ユーザーがホテリング ホストを使用できる時間数を選択します。

ユーザーは選択した時間後に自動的にログアウトされます。

ユーザに指定された制限関連付け期間が、選択したホテリング ホストの制限関連付け期間を超えた場合、画面にエラーメッセージが表示されます。たとえば、ホテリング ホストに制限時間が 12 時間あり、ユーザーの制限時間が 24 時間ある場合、エラーメッセージが表示されます。このような場合、ユーザにさらに時間が必要な場合は、ホテリング ホストの制限時間を延長する必要があります。

6

[保存] をクリックします。

ユーザーは、User Hub から使用するホテリング ホストを検索し、検索することもできます。詳細については、「どこからでも通話プロファイルにアクセスする」を参照してください。

実際の例を見てみましょう。このビデオ デモンストレーション で、Control Hub でホテリングを設定する方法をご覧ください。

Webex Calling の導入傾向と使用レポート

通話レポートを表示

Control Hub の [アナリティクス] ページを使用して、Webex Calling サービスの使用方法、Webex アプリでのエンゲージメント、通話メディア エクスペリエンスの品質を確認できます。Webex Calling 分析にアクセスするには:

1

Control Hub にサインインします。

2

[分析] に移動し、[Calling] タブを選択します。

3

[詳細な通話履歴] を選択します。

通話履歴の詳細は、メディア品質データとともに表示されます。
4

メディア品質データにアクセスするには、Control Hub にサインインし、[アナリティクス] に移動し、[Calling] を選択します。

関連情報

Webex Calling の概要

エンタープライズグレードのクラウド通話、モビリティ、PBX 機能を、メッセージングとミーティング、ソフト クライアントまたは Cisco デバイスからの通話に使用できると想像してください。それがまさに、あなたにとって必要なことです。

以下の機能と利点を提供します。

  • テレフォニー ユーザーのためのコール サブスクリプションと共有領域。

  • 信頼できる地域のサービス プロバイダによって配信される安全かつ信頼性のあるクラウド サービス

  • すべてのユーザーにアクセスし、豊富な統合コミュニケーションとチーム コラボレーション サービスを追加します。

  • Webex Meetings はオプションで統合されたアドオンで、エンタープライズ ユーザーが期待するプレミアム ミーティング エクスペリエンスを提供します。

  • ユーザーが組織外に番号をダイヤルできるようにするためのパブリック スイッチ テレフォニー ネットワーク (PSTN) アクセス。サービスは既存のエンタープライズ インフラストラクチャを通じて提供されます

    • オンプレミス IP PBX なしのローカル ゲートウェイ

    • 既存の Unified CM コール環境

    • パートナーまたは Cisco が提供した PSTN オプション

  • パートナーや Cisco により提供されている次のレベルのサポートにより提供される階層 1 サポート

は、注文と構成を合理化し、バンドルされたオファー、、および Webex Meetings の管理を一元化するために統合する Web ベースの管理ポータルです。

表 1YAZ設定オプション 管理者の設定可能な機能

機能

説明

自動音声応答

セットアップ メニューと、応答サービス、ハント グループ、ボイスメール ボックスや実際のオペレーターなどへのルーティング機能によって、適切なあいさつを返すことができます。24 時間分のスケジュールを作成することができます。あるいは、営業時間内か外かに応じて、異なるオプションを使うこともできます。通話は、発信者の ID 属性に応じてルーティングすることによって、VIP リストを作成したり、特定の市外局番からの通話には対応を変えたりすることができます。

コール キュー

着信通話に応答できないときに、通話キューを設定できます。誰かがコールに応答できるまで、自動応答、ご案内のメッセージ、保留中の音楽を発信者に提供できます。

通話ピックアップ

コール ピックアップ グループを作成して、ユーザーが別のユーザーの通話に応答できるようにすることで、チームワークとコラボレーションを強化できます。ユーザーをコールピックアップグループに追加しておけば、グループメンバーが席を離れていたり、電話中だったりした場合、別のメンバーが電話に出ることができます。

コール パーク

コール パークをオンにすると、ユーザがコールを保留にし、別の電話からピックアップできます。

ハントグループ

以下のようなシナリオでは、ハント グループをセットアップするのがよいでしょう。

  • セールス チームは順番に転送を求めている可能性があります。着信が電話を鳴らしても応答が無かった場合、その通話はリスト中の次のエージェントへと転送されます。

  • サポートチームは最初の対応可能なエージェントが電話に応答できるように、電話が同時に鳴ることを希望する傾向があります。

ページング グループ

ユーザーが音声メッセージを個人、部署、チームに送信できるように、ページング グループを作成できます。誰かがメッセージをページング グループに送信するとき、グループのすべてのデバイスでメッセージが再生されます。

レセプショニスト クライアント

フルセットの通話管理オプション、大規模モニタリング、コール キュー、複数のディレクトリ オプションとビュー、Outlook との統合などを提供することにより、フロントオフィス担当者のニーズを満たします。
表 2. ユーザーの設定可能な機能

機能

説明

匿名コールの拒否

ユーザーはブロックされた発信者 ID を使用して着信を拒否できます。

障害時一括転送

停電、ネットワークの問題などの理由でユーザの電話がネットワークに接続されていない場合、ユーザは着信コールを特定の電話番号に転送できます。

コール転送

ユーザーは着信コールを別の電話に転送することができます。

選択的コール転送

ユーザーは特定の発信者、特定の時間のコールを転送することができます。この設定はコール転送より優先されます。

コール通知

ユーザーは、電話番号や日時など、事前に定義された条件に従ってコールを受信したときに自分自身にメールが送られるよう設定することができます。

着信待ち受け

ユーザーは追加の着信に応答することができます。

応答不可

ユーザーは一時的にすべての通話をボイスメールに直接転送できます。

Office Anywhere

ユーザーは選択された電話 (「ロケーション」) を、会社の電話番号とダイヤルプランの内線として使用することができます。

優先アラート

ユーザーは電話番号や日時など、事前に定義された条件が満たされたときに、特別な着信音が鳴るように設定することができます。

リモート オフィス

ユーザーはリモートの電話からコールを発信し、ビジネス回線からのものとして表示させることができます。さらに、ビジネス回線への着信は、このリモート電話で鳴ります。

選択通話承諾

ユーザーは特定の発信者、特定の時間のコールを承認することができます。

匿名通話の拒否

ユーザーは特定の発信者、特定の時間のコールを拒否することができます。

シーケンシャル リング

着信があると、最大で 5 台のデバイスを 1 つずつ鳴らすことができます。

同時リング

着信があると、ユーザーの番号の電話と、別の番号の電話 (「コールの受信者」) 番号が同時に鳴ります。

のサービス、デバイス、ユーザーのプロビジョニング、詳細設定へのクロス起動

() は、注文と構成を合理化し、バンドルされたオファーの管理を一元化する管理ポータルです。

は、すべてのサービス、デバイス、およびユーザーをプロビジョニングする中心点です。コーリング サービスの初回セットアップ、MPP 電話のクラウドへの登録 (MAC アドレスを使用)、デバイスの関連付けや、電話番号、サービス、コール機能の追加などにより、ユーザーを構成することができます。また、 から にクロスローンチすることもできます。

ユーザーエクスペリエンス

ユーザーは次のインターフェイスへのアクセスできます。

  • アプリケーション—Cisco ブランドのコール用のソフト クライアント。詳細については、「新しい Cisco Webex Calling アプリを検索する」を参照してください。

  • ()—ユーザーがプロファイルの基本設定を設定し、Webex アプリをダウンロードし、for Calling 設定にクロス起動できるインターフェイス。詳細については、「Cisco Webex の設定を変更する」を参照してください。

  • Webex アプリ—Cisco ブランドの Team メッセージング クライアントとしてのサブスクリプションに含まれるアプリケーション。詳細については、「新しいアプリを 使い始めるCisco Webexしてください。

  • Webex Meetings —ミーティング ソリューションとして追加されるオプションのアプリケーション。詳細については、「Webex Meetings」を参照してください。

カスタマー管理者

のトライアルまたは有料サブスクリプションの顧客管理者は、ロケーション、ライセンス、電話番号、通話機能、ユーザー、ワークスペース (Webex クラウドに登録されている会議室デバイス) を追加することで、組織をセットアップできます。これらのすべてコンポーネントを同様にそこから管理できます。

パートナー:

パートナー サービス プロバイダとして、ブランドとマーケットを設定し、 を顧客に販売できます。トライアルをセットアップして、顧客にサービスを展開し、顧客にオーダーを作成してプロビジョニングすることもできます。

サービス開始日時

販売可能な国については、「Cisco Webex はどこで利用可能ですか 」の記事を参照してください。

ツアーに参加する

は、組織の管理、ユーザーの管理、サービスの割り当て、導入の傾向と通話品質の分析などを行うための、単一の Web ベースのインターフェイスです。

Control Hub のインターフェイスの概要は、左側ナビゲーションメニュー、会社情報、通知、アプリ内ヘルプ、フィードバック、言語、サインアウトのハイライトとラベル付けです。

組織を立ち上げて稼働させるには、 にメール アドレスを入力して参加するユーザーを数人招待することをおすすめします。コールを含む、提供されるサービスを使用するようにユーザーを促し、彼らの満足度に関するフィードバックを提供することを求めます。準備が完了したら、いつでもユーザーを追加することができます。

にアクセスするには最新のGoogle ChromeもしくはMozilla Firefoxの最新バージョンを使用されることを推奨します。モバイル デバイスのブラウザーやその他のデスクトップ ブラウザーを使用した場合、予期せぬ結果が生じる場合があります。

以下に示す情報を、組織がサービスをセットアップし始めた場合に期待できる事柄についての、大まかな概要として用いてください。詳細については、個々の章の、手順を追った説明を参照してください。

使い始める

パートナーがあなたのアカウントを作成すると、ウェルカム メールが届きます。Chrome または Firefox を使用して、メールの [はじめに] リンクをクリックします。このリンクを使うと、管理者のメール アドレスで自動的にサインインすることができます。次に、管理者パスワードを作成するためのプロンプトが表示されます。

Control Hub セットアップの開始メールから、新しいパスワード画面を作成します。

トライアルのための初回ウィザード

パートナーがトライアルに登録している場合、サインインすると、セットアップ ウィザードが自動的に開始されます。このウィザードでは、組織をセットアップし、他のサービスを実行するための基本設定について説明します。ウィザードのガイドを終えると、Calling の設定とその確認が完了します。

Control Hub の初回セットアップ ウィザード。

設定の確認

ロード時に、設定を確認できます。

Control Hub の概要ページ。

ユーザーの追加

サービスをセットアップしたら、会社ディレクトリからユーザーを追加する準備ができます。[ユーザー] に進んで、[ユーザーの管理] をクリックします。

Control Hub でユーザー ポップアップ ウィンドウを管理します。

Microsoft Active Directory を使用している場合、まずディレクトリ同期を有効にしてからユーザーの追加方法を決定することをお勧めします。[次へ] をクリックし、指示に従って Cisco Directory Connector を設定します。

シングル サインオン (SSO) の設定

基本的な認証を使用します。 SSO をセットアップして、ユーザーが Webex に保存され、管理される別のパスワードではなく、エンタープライズ クレデンシャルを使用してエンタープライズ ID プロバイダーで認証されるようにできます。 SSO

[設定] に移動し、[認証] までスクロールして、[変更] をクリックしてから、[サードパーティの ID プロバイダを統合させる] を選択します。

[サードパーティ プロバイダーを統合] オプションが選択されているシングル サインオン設定画面です。

サービスをユーザーに割り当てる

ユーザーが使用を開始できるように、追加したユーザーにサービスを割り当てる必要があります。

[ユーザー] に移動して、[ユーザーの管理] をクリックし、[CSV ファイルでユーザーをエクスポートおよびインポートする] を選択してから、[エクスポート] をクリックします。

ダウンロードしたファイルで、各ユーザーに割り当てるサービスに [True] を追加します。

Control Hub でユーザーにサービスを割り当てるための CSV ファイルの例。

完了したファイルをインポートし、[サービスの追加および削除] をクリックして、[提出] をクリックします。これで、コール機能を構成し、共通場所で共有できるデバイスを登録し、デバイスを登録してユーザーに関連付ける準備ができました。

ユーザーを支援する

ユーザーを追加し、サービスが割り当てられたら、サポートされているマルチプラットフォーム電話 (MPP) を使用してメッセージングやミーティングを開始できます。ユーザーに、アクセスのためのワンストップショップとしてCisco Webex の設定 を使用するように促してください。

ローカル ゲートウェイの役割

ローカル ゲートウェイは、エンタープライズまたはパートナーにより管理されているエッジ デバイスです。これは、パブリックスイッチのテレフォニー ネットワーク (PSTN) の相互動作と従来型のプライベート ブランチ エクスチェンジ (PBX) との動作のためのものです (Unified CM を含む)。

を使用して、 ローカル ゲートウェイを場所に割り当てることができます。その後、 はキューブで構成できるパラメータが提供されます。これらの手順により、ローカル ゲートウェイがクラウドに登録され、PSTN サービスが特定の場所の ユーザーに対してゲートウェイを通じて提供されます。

ローカル ゲートウェイを指定して注文するには、「ローカルゲートウェイの注文ガイド」を参照してください。

サポートされているローカル ゲートウェイの展開

次の基本的な展開がサポートされています。

ローカル ゲートウェイは、Cisco Unified Communications Manager へのインテグレーションが必要な場合、スタンドアロンまたは導入で展開することができます。

オンプレミスの IP PBX なしのローカル ゲートウェイ展開

スタンドアロンのローカル ゲートウェイ展開

この図は、既存の IP PBX なしの展開を示しており、単一のロケーションまたはマルチロケーションの展開に適用されます。

既存の IP PBX を使用しない Webex Calling の展開を示す図。

宛先と一致しないすべてのコールについて、これらのコールは処理のためにロケーションに割り当てられているローカル ゲートウェイに送信します。ローカル ゲートウェイは、着信するすべてのコールを PSTN にルーティングし、反対方向に PSTN から にルーティングします。

PSTN ゲートウェイは、ローカル ゲートウェイの専用プラットフォームまたは共存プラットフォームになります。次の図のように、この展開の専用 PSTN ゲートウェイのバリアントをお勧めします。既存の PSTN ゲートウェイをローカル ゲートウェイとして使用できない場合に使用できます。

既存の PSTN ゲートウェイを Webex Calling ローカル ゲートウェイとして使用できない場合に使用できる、推奨された PSTN ゲートウェイの展開オプションを示すイラスト。

共存型のローカル ゲートウェイの展開

ローカル ゲートウェイとして、ITSP に接続するために SIP トランクを使用する IP ベースのもの、または ISDN またはアナログ回路を使用する TDM ベースのものを使用できます。次の図は、ローカル ゲートウェイが PSTN GW/SBC と共存している展開を示しています。

ローカル ゲートウェイが PSTN GW/SBC と共存している Webex Calling の展開を示しています。

オンプレミスの Unified CM PBX なしでのローカル ゲートウェイ展開

Unified CM とのインテグレーションは、以下の場合に必要です。

  • -有効なロケーションは、Unified CM がオンプレミス通話制御ソリューションとして展開される既存の Cisco UC 展開に追加されます

  • Unified CM に登録されている電話機とロケーションの電話機間のダイレクト ダイヤルが必要です。

この図は、顧客が既存の Unified CM IP PBX を持っている展開を示しています。

顧客が既存の Unified CM IP PBX を持つ Webex Calling の展開を示しています。

Webex Calling は、顧客の宛先と一致しないコールをローカル ゲートウェイに送信します。これには、PSTNおよび Unified CM 内部内線番号Webex Calling含まれます。ローカル ゲートウェイは、ユーザーから Unified CM へ、その逆Webex Calling、すべての通話をルーティングします。Unified CM は、着信コールを、既存のダイヤル プランに従ってローカルの宛先または PSTN にルーティングします。Unified CM のダイヤル プランは、番号を +E.164 として正規化します。PSTN ゲートウェイには、専用のものと、ローカル ゲートウェイに共存しているものがあります。

専用の PSTN ゲートウェイ

この図に示されているように、この展開の専用 PSTN ゲートウェイのバリアントが推奨オプションであり、既存の PSTN ゲートウェイをローカル ゲートウェイとして使用できない場合に使用できます。

専用 PSTN ゲートウェイのバリエーションを示すイラスト。既存の PSTN ゲートウェイを Webex Calling ローカル ゲートウェイとして使用できない場合に使用できる推奨オプション。

共存型 PSTN ゲートウェイ

この図は、ローカル ゲートウェイが PSTN ゲートウェイ/SBC と共存する Unified CM の展開を示しています。

Webex Calling は、顧客の宛先と一致しないすべてのコールを、ロケーションに割り当てられているローカル ゲートウェイにルーティングします。これには、PSTN の宛先と、Unified CM 内部の内線に向けたオンネット コールが含まれます。ローカルゲートウェイは、すべてのコールを Unified CM にルーティングします。その後、Unified CM は PSTN/SBC 機能が共存している ローカル ゲートウェイを通じて、コールをローカルに登録された電話または PSTN にルーティングします。

ローカル ゲートウェイが PSTN ゲートウェイ/SBC と共存する Unified CM を使用した Webex Calling の展開を示す図。

コール ルーティングの考慮点

Unified CM へのコール

ルーティング ロジックは次のように動作します。エンドポイントでダイヤルされた番号が Webex Calling の同じ顧客内の他の宛先にルーティングできない場合、コールはローカル ゲートウェイに送信され、さらなる処理が行われます。オフネット (外部) のWebex Callingは、ローカル ゲートウェイに送信されます。

既存の Unified CM に統合されていない展開の場合、オフネット コールは PSTN コールと見なされます。Unified CM との組み合わせでは、オフネット コールは、Unified CM でホストされている任意の宛先へのオンネット コール、または PSTN 宛先への実際のオフネット コールになり得ます。後者の 2 つのコールの種類の違いは、Unified CM によって決まり、Unified CM でプロビジョニングされたエンタープライズ ダイヤル プランによって異なります。

次の図は、米国内の国番号をダイヤルするユーザを示しています。

米国内の国番号をダイヤルする Webex Calling ユーザーの図です。

Unified CM は、構成済みのダイヤルプランに基づいて、発信先が電話帳としてプロビジョニングされている、ローカルに登録されたエンドポイントにルーティングします。このため、Unified CM のダイヤル プランは + E.164 番号のルーティングをサポートする必要があります。

Unified CM から

Unified CM から Unified CM へのコール ルーティングを有効にするには、一連のルートをプロビジョニングして、 の +E.164 とエンタープライズ番号プラン アドレスのセットを定義する必要があります。

これらのルートを構成することにより、次の図に示されているコール シナリオの両方が可能になります。

Unified CM のルートのセットで Unified CM から Webex Calling へのコール ルーティングを示す図。

PSTN の発信者がデバイスに割り当てられた DID 番号に発信すると、コールはエンタープライズの PSTN ゲートウェイを介してエンタープライズに渡され、Unified CM にヒットします。そのコールの着信アドレスは、Unified CM でプロビジョニングされたルートの 1 つと一致し、コールがローカル ゲートウェイに送信されます。(ローカル ゲートウェイに送信する場合、着信アドレスは +E.164 形式である必要があります)。次に、Webex Calling のルーティング ロジックにより、DID の割り当てに基づいてコールが目的のデバイスに送信されるようにします。

また、Unified CM 登録済みエンドポイントから発信されたコールは、Unified CM でプロビジョニングされたダイヤル プランの対象となります。通常、このダイヤルプランにより、ユーザーは一般的なエンタープライズダイヤルの習慣を使ってコールを発信することができます。これらの習慣には、必ずしも +E.164 ダイヤルだけが含まれているわけではありません。+E.164 以外のダイヤル習慣は、通話がローカル ゲートウェイに送信される前に +E.164 にノーマライズし、Webex Calling で正しいルーティングを許可する必要があります。

サービス クラス (CoS)

厳しいサービス クラスの制限を実装することは、コールのループの回避や特殊詐欺の防止など、さまざまな理由により常に推奨されます。ローカル ゲートウェイと Unified CM のサービス クラスを統合するコンテキストでは、次のサービスのクラスを考慮する必要があります。

  • Unified CM に登録されているデバイス

  • PSTN からUnified CM に着信するコール

  • ユーザーから Unified CM に着信Webex Calling

Unified CM に登録されているデバイス

既存の CoS セットアップに通知先の新しいクラスとして通知先を追加することは、かなり簡単です。宛先へのコールの権限は、通常、オンプレミス（サイト間を含む）の宛先を呼び出す権限と同等です。

エンタープライズ ダイヤル プランがすでに「（短縮された）オンネット サイト間」権限を実装している場合、Unified CM でプロビジョニングされたパーティションがすでに存在しており、同じパーティション内のすべての既知のオンネット 宛先を使用、プロビジョニングできます。

それ以外の場合、「（短縮された）オンネットサイト間」権限の概念はまだ存在しておらず、新しいパーティション（「onNetRemote」など）をプロビジョニングし、宛先がこのパーティションに追加され、最終的にこの新しいパーティションを適切なコーリング サーチ スペースに追加する必要があります。

PSTN からUnified CM に着信するコール

既存の CoS セットアップに通知先の新しいクラスとして通知先を追加することは、かなり簡単です。宛先へのコールの権限は、通常、オンプレミス（サイト間を含む）の宛先を呼び出す権限と同等です。

エンタープライズ ダイヤル プランがすでに「（短縮された）オンネット サイト間」権限を実装している場合、Unified CM でプロビジョニングされたパーティションがすでに存在しており、同じパーティション内のすべての既知のオンネット 宛先を使用、プロビジョニングできます。

それ以外の場合、「（短縮された）オンネットサイト間」権限の概念はまだ存在しておらず、新しいパーティション（「onNetRemote」など）をプロビジョニングし、宛先がこのパーティションに追加され、最終的にこの新しいパーティションを適切なコーリング サーチ スペースに追加する必要があります。

ユーザーから Unified CM に着信Webex Calling

PSTN からの着信は、すべての宛先にアクセスする必要があります。これには、すべての宛先を保持している上記のパーティションを、PSTN トランク上の着信コールに使用されるコーリング サーチ スペースに追加する必要があります。宛先へのアクセスは、既存のアクセスに加えて、追加されます。

PSTN から Unified CM DID にアクセスするコールと DID は、Unified CM DID と PSTN の宛先へのアクセスに必要なコールが必要です。

PST と Webex Calling からの通話の差別化された CoS の図。
PSTN からのコールのための差別化された CoS

この図は、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 宛先を表すパーティションが作成され ("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」パーティションに追加することを推奨しません。

コール用プロトコル ハンドラー

次のプロトコル ハンドラーをオペレーティング システムに登録して、Web ブラウザーまたはその他のアプリケーションからクリック通話機能を有効にします。Mac または Windows でデフォルトの通話アプリケーションである場合、次のプロトコルは Webex アプリで音声またはビデオ通話を開始します。

  • CLICKTOCALL: または CLICKTOCALL://

  • SIP: または SIP:

  • TEL: または TEL:

  • WEBEXTEL: または WEBEXTEL://

Mac または Windows のデフォルトの通話アプリケーションの場合、Webex アプリで音声またはビデオ通話を開始するプロトコル ハンドラのリスト。

Windows 用プロトコル ハンドラー

他のアプリは、 より前にプロトコル ハンドラーに登録できます。Windows 10 では、通話を開始するために使用するアプリを選択するためにユーザーに尋ねるシステム ウィンドウ。ユーザーは、[常にこのアプリを使う] にチェックを入れて、記憶させることができます。

Windows 10 「アプリを選択」を選択するオプションとして Webex が強調表示されます。

ユーザーが選択できるように、デフォルトの通話アプリ設定をリセットする必要がある場合は、Windows 10 でプロトコルの関連付けを変更するように指示することができます。

  1. [デフォルトのアプリ設定] システム設定を開き、[アプリごとにデフォルトを設定する] をクリックして、 を選択します。

    Windows 10 の [アプリごとにデフォルトを設定する] で、Webex を選択するオプションとして強調表示されます。

  2. 各プロトコルに対して、 を選択します。

    ファイル タイプとプロトコルの関連付けのための Windows 10 Webex オプション。

macOS 用のプロトコルハンドラー

Mac OS では、以前に他のアプリが通話プロトコルに登録されている場合、ユーザーはデフォルトの通話オプションに設定する必要があります。

Mac では、ユーザーは一般的な基本設定で [通話を開始 ] 設定に選択されていることを確認できます。また、Outlook の連絡先の番号をクリックしたときにコールインする場合は、[常に Microsoft Outlook に接続する] をオンにすることもできます。

Mac OS プロトコル ハンドラ設定、[常に Microsoft Outlook に接続] オプションを選択し、[コールを開始] ドロップダウンで Webex が選択されています。

環境を準備する

全般的な前提条件

ローカル ゲートウェイを設定する前に、次のことを確認してください。

  • 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 注文ガイド」の表 1 を参照してください。また、ローカル ゲートウェイ構成ガイドに従って、プラットフォームがサポートされている IOS-XE リリースを実行していることを確認してください。

ローカル ゲートウェイは、自分のペースで Webex Calling に移行するのに役立ちます。ローカル ゲートウェイは、既存のオンプレミス展開を Webex Calling と統合します。既存の PSTN 接続を使用することもできます。「ローカル ゲートウェイの使用を開始する」を参照してください。

ローカル ゲートウェイのライセンスに関する要件

CUBE コールライセンスは、ローカル ゲートウェイにインストールされている必要があります。詳細については、Cisco Unified 境界要素の構成ガイドを参照してください。

ローカル ゲートウェイの認証およびセキュリティ的要件

は、セキュアな信号経路とメディアを必要とします。ローカルゲートウェイは暗号化を行います。また、以下の手順に従って、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 を実行している必要があります。

ポート参照情報

適切に構成されたファイアウォールとプロキシは、通話の展開を成功させるために不可欠です。コール シグナリングに 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 を無効にする手順については、関連する製造元のマニュアルを確認してください。

プロキシ サポート

組織はインターネット ファイアウォールまたはインターネット プロキシおよびファイアウォールを展開し、ネットワークを出入りする 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 アプリのプロキシ アドレスを手動で設定します。

希望の製品タイプを設定するときに、表で次のプロキシ設定と認証タイプを選択します。

製品

プロキシの設定

認証タイプ

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

表の凡例の場合:

  1. †Mac NTLM 認証 - マシンはドメインにログインする必要はなく、ユーザーはパスワードの入力を求められます

  2. †Windows NTLM 認証 - マシンがドメインにログインしている場合にのみサポートされます

  3. ネゴシエート †- NTLM フォールバック認証で Kerberos。

  4. Cisco Webex Board、Desk、または Room シリーズのデバイスをプロキシ サーバーに接続するには、「Board、Desk、または Room シリーズのデバイスをプロキシ サーバーに接続する」を参照してください。

  5. Cisco IP 電話の場合、プロキシ サーバーと設定を構成する例として、プロキシ サーバーのセットアップ を参照してください。

No Authentication の場合、認証をサポートしていないプロキシ アドレスでクライアントを設定します。Proxy Authentication を使用する場合、有効な資格情報で構成します。Web トラフィックを検査するプロキシは、Web ソケット接続に干渉する場合があります。この問題が発生した場合、*.Webex.com への検査を行わないトラフィックをバイパスすると問題が解決する可能性があります。すでに他のエントリが表示されている場合は、最後のエントリの後にセミコロンを追加し、Webex 例外を入力します。

Windows OS のプロキシ設定

Microsoft Windows は、プロキシ設定を許可する HTTP トラフィック (WinINet および WinHTTP) のための 2 つのネットワーク ライブラリをサポートしています。WinINet は WinHTTP のスーパーセットです。

  1. WinInet は、シングルユーザーのデスクトップ クライアント アプリケーション用に設計されています

  2. 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 Aware サービスをサポートし、サポートしています。Amazon は、シスコの単独使用のために IP サブネットを予約し、AWS 仮想プライベート クラウド内のこれらのサブネットにあるサービスを保護しました。

お使いのデバイス、アプリのアプリケーション、およびインターネットサービスからの通信が正常に機能を実行できるようにファイアウォールを設定します。この設定により、サポートされているすべての Webex Aware クラウド サービス、ドメイン名、IP アドレス、ポート、プロトコルにアクセスできます。

Webex Aware サービスが正しく機能するように、ホワイトリストまたは次のアクセス権を開きます。

  • 「Webex Calling サービスのドメインと URL」セクションで言及されている URL/ドメイン

  • 「Webex Calling サービスの IP サブネット」セクションで言及されている IP サブネット、ポート、およびプロトコル

  • 組織内で Webex クラウド コラボレーション サービスの Webex スイート、Webex Meetings、Messaging、Webex アテンダントコンソール、およびその他のサービスを使用している場合は、IP サブネットを持っていることを確認します。これらの記事で言及されているドメイン/URL は、「Webex サービスのネットワーク要件 」および「アテンダントコンソールのネットワーク要件」が開いています。

ファイアウォールのみを使用している場合、一部の IP アドレス プールは動的で、いつでも変更される可能性があるため、IP アドレスだけを使用してトラフィックをフィルタリングすることはサポートされません。ルールを定期的に更新すると、ファイアウォールのルール リストの更新に失敗すると、ユーザーのエクスペリエンスに影響を与える可能性があります。Cisco は、特定の地域またはクラウド サービス プロバイダーに基づいて、IP アドレスのサブセットをフィルタリングすることを推奨しません。地域別にフィルタリングすると、通話エクスペリエンスが著しく低下する可能性があります。

Cisco は IP アドレス プールの動的な変更を維持していないため、この記事には記載されません。

ファイアウォールがドメイン/URL フィルタリングをサポートしていない場合は、エンタープライズ プロキシ サーバー オプションを使用してください。このオプションは、ファイアウォールに転送する前に、HTTP シグナリング トラフィックとプロキシ サーバーの Webex Aware サービスを URL/ドメインでフィルタ/許可します。

コール メディアのポートと IP サブネット フィルタリングを使用してトラフィックを設定できます。メディア トラフィックにはインターネットへの直接アクセスが必要であるため、シグナリング トラフィックの URL フィルタリング オプションを選択します。

の場合、UDP はメディアに対して Cisco が推奨するトランスポートプロトコルであり、UDP 経由の SRTP のみを使用することをお勧めします。メディア用のトランスポート プロトコルとして TCP および TLS は、本番環境ではサポートされていません。これらのプロトコルの接続指向の性質は、損失のあるネットワーク上のメディア品質に影響します。トランスポートプロトコルに関するクエリがある場合は、サポート チケットを発行します。

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 サービス

  1. アイデンティティ プロビジョニング

  2. アイデンティティ ストレージ

  3. 認証

  4. OAuth サービス

  5. オンボードのデバイス

  6. クラウド接続 UC

電話機を初めてネットワークに接続する場合、または 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 マイクロサービス。

  1. プロファイル画像サービス

  2. ホワイトボード サービス

  3. Proximity サービス

  4. プレゼンス サービス

  5. 登録サービス

  6. カレンダー サービス

  7. 検索サービス

すべて

*.webexcontent.com

一般的なファイル ストレージに関する Webex メッセージング サービス:

  1. ユーザー ファイル

  2. トランスコードされたファイル

  3. イメージ

  4. スクリーンショット

  5. ホワイトボードの内容

  6. クライアントとデバイスのログ

  7. プロファイル画像

  8. ブランディング ロゴ

  9. ログ ファイル

  10. CSV エクスポート ファイルの一括インポート (Control Hub)

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-65535TCP「Webex Calling サービスの IP サブネット」を参照してください。5062, 8934

これらの IP/ポートは、ローカル ゲートウェイ、デバイス、および Webex アプリ アプリケーション (ソース) から Webex Calling クラウド (宛先) への発信 SIP-TLS コール シグナリングに必要です。

ポート 5062（証明書ベースのトランクに必要）。およびポート 8934 (登録ベースのトランクに必要)

デバイス5060-50808934
Webex アプリ 一時的 (OS 依存)
Webex Calling (SIP TLS) からローカル ゲートウェイへのコール シグナリング

Webex Calling のアドレス範囲。

「Webex Calling サービスの IP サブネット」を参照してください。

8934TCPローカル ゲートウェイに顧客が選択した IP または IP 範囲ローカル ゲートウェイに顧客が選択したポートまたはポート範囲

証明書ベースのローカル ゲートウェイに適用されます。Webex Calling からローカル ゲートウェイへの接続を確立する必要があります。

登録ベースのローカル ゲートウェイは、ローカル ゲートウェイから作成された接続を再利用することで機能します。

宛先ポートは、[トランクの設定] を選択した顧客です。

Webex Calling へのコール メディア (STUN、SRTP/SRTCP、T38、DTLS)ローカル ゲートウェイ外部 NIC8000-48199†*UDP「Webex Calling サービスの IP サブネット」を参照してください。

5004、9000 (STUN ポート)

音声: 8500-8599

ビデオ: 8600-8699

19560-65535 (UDP 経由の SRTP)

  • これらの IP/ポートは、ローカル ゲートウェイ、デバイス、および Webex アプリ アプリケーション (ソース) から Webex Calling クラウド (宛先) への発信 SRTP コール メディアに使用されます。

  • STUN、ICE ネゴシエーションが成功している組織内の通話の場合、通信パスとしてクラウドのメディアリレーが削除されます。このような場合、メディア フローはユーザーのアプリ/デバイス間で直接行われます。

    例: メディア最適化が成功すると、Webex アプリはポート範囲 8500 ～ 8699 で互いに直接メディアを送信し、デバイスは 19560 ～ 19661 で互いに直接メディアを送信します。

  • 顧客のプレミス内でファイアウォールが使用される特定のネットワーク トポロジでは、メディアがフロースルーするために、ネットワーク内の前述の送信元と宛先ポート範囲へのアクセスを許可します。

    例：Webex アプリでは、送信元と送信先のポート範囲を許可します

    音声: 8500-8599 ビデオ:8600-8699

  • ブラウザは、管理対象デバイス管理（MDM）プロファイルで WebRtcUdpPortRange ポリシーを設定することで制御できる一時的なソース ポートを使用します。

    MDM サービスが設定されていない場合、または SiteURL と EnableForceLogin が設定されていない 場合、Webex Calling サービスは通常どおりに動作します。

デバイス†*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)ローカル ゲートウェイ内部 NIC8000-65535TCPITSP、PSTN GW または Unified CMPSTN オプションによって異なる (たとえば、Unified CM の 5060 または 5061)
PSTN ゲートウェイへのコール メディア (SRTP/SRTCP)ローカル ゲートウェイ内部 NIC8000-48199†*UDPITSP、PSTN GW または Unified CMPSTN オプションによって異なります（たとえば、Unified CM の場合は 5060 または 5061）
デバイスの構成とファームウェアの管理 (Cisco デバイス)Webex Calling デバイス一時的TCP

「Webex Calling サービスの IP サブネット」を参照してください。

443, 6970, 80

次の理由で必須:

  1. エンタープライズ電話 (Cisco Unified CM) から Webex Calling への移行。詳細については、upgrade.cisco.com を参照してください。cloudupgrader.webex.com はポートを使用します。ファームウェア移行プロセスの 6970,443。

  2. 16 桁のアクティベーション コード (GDS) を使用したデバイス (MPP および Room または Desk Phone) のファームウェアのアップグレードと安全なオンボーディング

  3. CDA / EDOS - MAC アドレスベースのプロビジョニング。新しいファームウェアを持つデバイス（MPP 電話、ATA、SPA ATA）で使用されます。

  4. Cisco ATA の場合、デバイスが最小ファームウェア 11.1.0MSR3-9 にあることを確認します。

  5. 電話機が初めてネットワークに接続する場合、または初期設定へのリセット後に、DHCP オプションが設定されていない場合は、ゼロ タッチ プロビジョニング用のデバイス アクティベーション サーバに接続します。新しい電話は、プロビジョニングのために webapps.cisco.com の代わりに activate.cisco.com を使用します。11.2(1) より前にリリースされたファームウェアを搭載した電話機は、引き続き webapps.cisco.com を使用します。すべての IP サブネットを許可することをお勧めします。

  6. 12.0.3 バージョンより古い Cisco マルチプラットフォーム フォン (MPP) が、ポート 80 から sudirenewal.cisco.com にアクセスして、製造元でインストールされた証明書 (MIC) を更新し、セキュアな一意のデバイス識別子 (SUDI) を持つことを許可します。詳細については、フィールド通知を参照してください。

Webex アプリの設定Webex アプリ アプリケーション一時的TCP

「Webex Calling サービスの IP サブネット」を参照してください。

443, 8443Id ブローカー認証、クライアントの Webex アプリ構成サービス、セルフケアおよび管理インターフェイス アクセスのためのブラウザベースの Web アクセスに使用されます。
TCP ポート 8443 は、構成をダウンロードするために Cisco Unified CM セットアップの Webex アプリで使用されます。Webex Calling に接続するためにセットアップを使用する顧客のみがポートを開く必要があります。
デバイス時間同期 (NTP)Webex Calling デバイス51494UDP「Webex Calling サービスの IP サブネット」を参照してください。123これらの IP アドレスは、デバイス（MPP 電話、ATA、SPA ATA）の時間同期に必要です。

ドメイン ネーム システム（DNS）の解決

Webex Calling デバイス、Webex アプリ、Webex デバイス一時的UDP および TCP主催者が定義53DNS ルックアップでクラウドの Webex Calling サービスの IP アドレスを検出するために使用されます。典型的な DNS ルックアップは UDP で行われますが、クエリ応答が UDP パケットに収まらない場合、TCP が必要な場合があります。
ネットワーク タイム プロトコル (NTP)Webex アプリと Webex デバイス123UDP主催者が定義123時間同期
CScanWebex Calling の Web ベースのネットワーク準備事前資格ツール一時的TCP「Webex Calling サービスの IP サブネット」を参照してください。8934 および 443Webex Calling の Web ベースのネットワーク準備事前資格ツールです。詳細については、cscan.webex.com を参照してください。
UDP19569-19760
追加の Webex Calling および Webex Aware サービス (サードパーティ)
プッシュ通知 APNS および FCM サービス Webex Calling アプリケーション 一時的TCP

リンクの下に記載されている IP サブネットを参照してください

Apple プッシュ通知サービス (APNS)

Google-Firebase クラウド メッセージング (FCM)

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 日

次の詳細で更新されました。

  • Webex Calling (アプリ、デバイス) でサポートされている QoS (TOS/DSCP) 値

  • ネットワーク図を更新しました

  • Webex アテンダントコンソールに関連するネットワーク要件のリンクを含める。

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 日

記事全体を見直して、以下を含めました。

  1. プロキシ サポートのオプションが含まれています。

  2. 変更された通話フロー図

  3. Webex Calling および Webex Aware サービスの簡素化されたドメイン/URL/IP サブネット部分

  4. Webex Calling および Webex Aware サービスに対して 170.72.0.0/16 IP サブネット範囲を追加しました。

    次の範囲 170.72.231.0、170.72.231.10、170.72.231.161 および 170.72.242.0/24 を削除しました。

2023年3月5日

記事を更新して、以下を含めます。

  • アプリケーションで使用される UDP-SRTP ポート範囲（8500～8700）を追加しました。

  • プッシュ通知 APNS および FCM サービスのポートを追加しました。

  • UDP と TCP の CScan ポート範囲を分割します。

  • リファレンス セクションを追加しました。

2022 年 11 月 15 日

デバイス構成とファームウェア管理 (Cisco デバイス) に次の IP アドレスを追加しました。

  • 170.72.231.0

  • 170.72.231.10

  • 170.72.231.161

デバイス構成とファームウェア管理 (Cisco デバイス) から次の IP アドレスを削除しました。

  • 3.20.118.133

  • 3.20.228.133

  • 3.23.144.213

  • 3.130.125.44

  • 3.132.162.62

  • 3.140.117.199

  • 18.232.241.58

  • 35.168.211.203

  • 50.16.236.139

  • 52.45.157.48

  • 54.145.130.71

  • 54.156.13.25

  • 52.26.82.54

  • 54.68.1.225

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 機能

  • ソース アドレス: Webex Calling デバイス

  • ソースポート: 一時的

  • プロトコルTCP

  • 宛先アドレス: 「Webex Meetings/Messaging - ネットワーク要件」で定義されている IP サブネットとドメインを参照してください。

  • 宛先ポート: 443

    メモ: Webex Calling デバイスは、これらの IP アドレスとドメインを使用して、ディレクトリ、通話履歴、ミーティングなどの Webex クラウド サービスとインターフェイスします。

[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しました。

  • 23.89.40.0/25

  • 23.89.1.128/25

2022 年 3 月 29 日

このサービスに以下の IP サブネットWebex Callingしました。

  • 23.89.33.0/24

  • 150.253.209.128/25

2021 年 9 月 20 日

Webex Calling サービスに 次の 4 つの新しい IP サブネットが追加されました。

  • 23.89.76.128/25

  • 170.72.29.0/24

  • 170.72.17.128/25

  • 170.72.0.128/25

2021 年 4 月 2 日

[Webex Calling サービスのドメインと URL] で *.ciscospark.com を追加し、Webex アプリで Webex Calling の使用事例をサポートします。

2021 年 3 月 25 日

activate.cisco.com に 6 つの新しい IP 範囲が追加されました。これは 2021 年 5 月 8 日から有効になります。

  • 72.163.15.64/26

  • 72.163.15.128/26

  • 173.36.127.0/26

  • 173.36.127.128/26

  • 192.133.220.0/26

  • 192.133.220.64/26

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 デバイス) の簡素化された範囲に移動します。

activate.cisco.com

  • 72.163.10.125 -> 72.163.10.96/27

  • 173.37.149.125 -> 173.37.149.96/27

webapps.cisco.com

  • 173.37.146.134 -> 173.37.146.128/25

  • 72.163.10.134 -> 72.163.10.128/25

Cisco Webex クライアントは 2021 年 3 月にオーストラリアで新しい DNS SRV をポイントしているため、アプリケーション構成に次の IP アドレスを追加します。

  • 199.59.64.237

  • 199.59.67.237

2021 年 1 月 21 日

次の IP アドレスを、デバイス構成とファームウェア管理 (Cisco デバイス) に追加しました。

  • 3.134.166.179

  • 50.16.236.139

  • 54.145.130.71

  • 72.163.10.125

  • 72.163.24.0/23

  • 173.37.26.0/23

  • 173.37.146.134

デバイス構成とファームウェア管理 (Cisco デバイス) から次の IP アドレスを削除しました。

  • 35.172.26.181

  • 52.86.172.220

  • 52.203.31.41

次の IP アドレスをアプリケーション構成に追加しました。

  • 62.109.192.0/19

  • 64.68.96.0/19

  • 207.182.160.0/19

  • 150.253.128.0/17

次の IP アドレスをアプリケーション構成から削除しました。

  • 64.68.99.6

  • 64.68.100.6

アプリケーション構成から次のポート番号を削除しました。

  • 1081, 2208, 5222, 5280-5281, 52644-52645

次のドメインをアプリケーション構成に追加しました。

  • idbroker-b-us.webex.com

  • idbroker-eu.webex.com

  • ty6-wxt-jp.bcld.webex.com

  • os1-wxt-jp.bcld.webex.com

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 アドレスを使用して、通話シグナリングおよびメディア エントリを更新しました。

  • 139.177.64.0/24

  • 139.177.65.0/24

  • 139.177.66.0/24

  • 139.177.67.0/24

  • 139.177.68.0/24

  • 139.177.69.0/24

  • 139.177.70.0/24

  • 139.177.71.0/24

  • 139.177.72.0/24

  • 139.177.73.0/24

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 アドレスが追加されました。

  • Webex Calling への信号発信 (SRTP)—135.84.173.0/25、135.84.174.0/25、199.19.197.0/24、199.19.199.0/24

  • パブリックアドレスエンドポイントへのコールシグナリング（SIP TLS）:135.84.173.0/25、135.84.174.0/25、199.19.197.0/24、199.19.199.0/24。

  • デバイスの構成とファームウェアの管理 (Cisco デバイス) —135.84.173.155、135.84.174.155

  • デバイス時刻の同期—135.84.173.152、135.84.174.152

  • アプリケーションの構成—135.84.173.154、135.84.174.154

2020 年 7 月 22 日

カナダのデータセンターの導入をサポートするために、次の IP アドレスを追加しました。135.84.173.146

2020 年 6 月 9 日

CScan エントリに次の変更を行いました:

  • IP アドレスの 1 つを修正しました。199.59.67.156 から 199.59.64.156 に変更されました。

  • 新しい機能には、新しいポートと UDP（19560-19760）が必要です。

2020/03/11

次のドメインと IP アドレスをアプリケーション構成に追加しました。

  • jp.bcld.webex.com—135.84.169.150

  • client-jp.bcld.webex.com

  • idbroker.webex.com—64.68.99.6, 64.68.100.6

追加の IP アドレスを持つ以下のドメインをデバイスの設定とファームウェア管理に更新しました:

  • cisco.webexcalling.eu—85.119.56.198, 85.119.57.198

  • webapps.cisco.com—72.163.10.134

  • activation.webex.com—35.172.26.181, 52.86.172.220

  • cloudupgrader.webex.com—3.130.87.169, 3.20.185.219

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 で 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 メッセージの処理を提供し、それらを必要なターゲットにルーティングします。

PSTN から Webex Calling 構成ソリューションへのコール ルーティング

IP および SIP は PSTN トランクのデフォルトのプロトコルになっていますが、TDM (時間分割多重化) ISDN 回路は広く使用され、Webex Calling トランクでサポートされています。TDM-IP コール フローを持つローカル ゲートウェイの IP パスのメディア最適化を有効にするには、現在、2 レッグ コール ルーティング プロセスを使用する必要があります。このアプローチでは、下の画像に示すように、Webex Calling と PSTN トランク間に一連の内部ループバックダイヤルピアを導入することで、上記のコール ルーティング設定を変更します。

Webex Calling と PSTN トランク間の内部ループバックダイヤルピアのセットを使用したコール ルーティング設定

オンプレミスの Cisco Unified Communications Manager ソリューションを Webex Calling に接続する場合、以下の図に示すソリューションを構築するためのベースラインとして、シンプルな PSTN ゲートウェイ構成を使用できます。この場合、Unified Communications Manager は、すべての PSTN および Webex Calling コールのルーティングと処理を一元化します。

Unified Communications Manager がすべての PSTN および Webex Calling コールのルーティングと処理を一元化したソリューションダイアグラム

このドキュメントでは、次の画像に示すホスト名、IP アドレス、およびインターフェイスが使用されます。

コール ルーティング設定ソリューションで使用されるホスト名、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 インターフェイスに割り当てることを確認します。


interface GigabitEthernet0/0/0
  description Interface facing PSTN and/or CUCM
  ip address 10.80.13.12 255.255.255.0
!
interface GigabitEthernet0/0/1
  description Interface facing Webex Calling (Private address)
  ip address 192.51.100.1 255.255.255.240

2

対称暗号化を使用して、ルータの登録と STUN クレデンシャルを保護します。プライマリ暗号化キーと暗号化タイプを次のように設定します。


key config-key password-encrypt YourPassword
password encryption aes

3

プレースホルダー PKI トラストポイントを作成します。

後で TLS を設定するには、このトラストポイントが必要です。登録ベースのトランクの場合、このトラストポイントは証明書を必要としません。証明書ベースのトランクでも必須です。


crypto pki trustpoint EmptyTP 
 revocation-check none
4

TLS1.2 の排他性を有効にし、次の設定コマンドを使用してデフォルトのトラストポイントを指定します。トランスポート パラメータも更新して、登録の信頼性の高い安全な接続を確保する必要があります。

cn-san-validate サーバ コマンドにより、テナント 200 で設定されたホスト名がアウトバウンド プロキシから受信した証明書の CN または SAN フィールドに含まれている場合、ローカル ゲートウェイが接続を許可します。

  1. tcp-retry count を 1000 に設定します (5-msec multiples = 5 秒)。

  2. タイマー接続を確立する コマンドを使用すると、次に使用可能なオプションを考慮する前に、LGW がプロキシとの接続をセットアップするのを待つ時間を調整できます。このタイマーのデフォルトは 20 秒、最小は 5 秒です。低値で開始し、ネットワーク条件に対応するために必要に応じて増加します。


sip-ua
 timers connection establish tls 5
 transport tcp tls v1.2
 crypto signaling default trustpoint EmptyTP cn-san-validate server
 tcp-retry 1000

5

Webex Calling で使用される DigiCert CA 証明書を含む Cisco ルート CA バンドルをインストールします。crypto pki trustpool import clean url コマンドを使用して、指定された URL からルート CA バンドルをダウンロードし、現在の CA トラストプールをクリアし、証明書の新しいバンドルをインストールします。

HTTPS を使用してインターネットにアクセスするためにプロキシを使用する必要がある場合は、CA バンドルをインポートする前に次の設定を追加してください。

ip http クライアント プロキシ サーバ yourproxy.com プロキシ ポート 80

ip http client source-interface GigabitEthernet0/0/1 
crypto pki trustpool import clean url https://www.cisco.com/security/pki/trs/ios_core.p7b
Webex Calling 登録ベースのトランクを設定
1

Control Hub の既存のロケーションに対して登録ベースの PSTN トランクを作成します。トランクが作成されると、提供されたトランク情報をメモします。図でハイライトされている詳細は、このガイドの設定手順で使用されます。詳細については、「Webex Calling のトランク、ルート グループ、ダイヤル プランを構成する」を参照してください。

PSTN トランクが登録されました
2

次のコマンドを入力して、CUBE を Webex Calling ローカル ゲートウェイとして設定します。

 
voice service voip
 ip address trusted list
  ipv4 x.x.x.x y.y.y.y
 mode border-element
 media statistics
 media bulk-stats 
 allow-connections sip to sip
 no supplementary-service sip refer  
 stun
  stun flowdata agent-id 1 boot-count 4
  stun flowdata shared-secret 0 Password123$
 sip
  asymmetric payload full
  early-offer forced

以下は、設定のフィールドの説明です。


ip address trusted list
 ipv4 x.x.x.x y.y.y.y

  • 有料詐欺から保護するために、信頼できるアドレス リストは、ローカル ゲートウェイが合法的な VoIP コールを期待するホストとネットワークのリストを定義します。

  • デフォルトでは、ローカル ゲートウェイは、信頼リストに含まれていない IP アドレスからのすべての着信 VoIP メッセージをブロックします。デフォルトでは、「セッション ターゲット IP」またはサーバ グループ IP アドレスを持つ静的に設定されたダイヤル ピアが信頼されます。これらの IP アドレスを信頼リストに追加する必要はありません。

  • ローカル ゲートウェイを設定する場合は、地域の Webex Calling データ センターの IP サブネットをリストに追加します。詳細については、「Webex Calling のポート参照情報」を参照してください。また、Unified Communications Manager サーバ（使用されている場合）と PSTN トランク ゲートウェイのアドレス範囲を追加します。

    LGW が制限付きコーン NAT のあるファイアウォールの背後にある場合は、Webex Calling に面したインターフェイスの IP アドレスの信頼リストを無効にすることをおすすめします。ファイアウォールはすでに、未承諾のインバウンドメッセージから保護VoIP。[無効にする] アクションは、Webex Calling ピアのアドレスが固定されたままである保証を保証できないので、長期構成のオーバーヘッドを削減します。また、いかなる場合にも、ピアに対してファイアウォールを構成する必要があります。

モードの境界要素

プラットフォームで Cisco Unified Border Element（CUBE）機能を有効にします。

メディア統計

ローカル ゲートウェイ上のメディア監視が可能です。

メディア一括統計

一括通話統計のために、コントロール飛行機がデータ 飛行機をポーリングできます。

これらのコマンドの詳細については、メディアを参照してください。

allow-connections sip to sip

CUBE 基本 SIP バックツーバックのユーザー エージェント機能を有効にします。詳細については、「接続を許可する」を参照してください。

デフォルトでは、T.38 ファックス トランスポートが有効になっています。詳細については、ファックス プロトコル t38 (音声サービス) を参照してください。

ストーン

STUN (NAT 経由の UDP のセッション トラバーサル) をグローバルに有効にします。

  • ローカル ゲートウェイの STUN バインディング機能を使用すると、ネゴシエートされたメディア パスを介して、ローカルで生成された STUN 要求を送信できます。これにより、ファイアウォールのピンホールを開くことができます。

詳細については、stun flowdata agent-id および stun flowdata shared-secret を参照してください。

非対称ペイロード (フル)

DTMF と動的コーデック ペイロードの両方に対して SIP 非対称ペイロード サポートを設定します。詳細については、非対称ペイロードを参照してください。

early-offer forced

ローカル ゲートウェイが、隣接ピアからの確認応答を待つ代わりに、最初の INVITE メッセージで SDP 情報を送信するように強制します。このコマンドの詳細については、早期オファーを参照してください。

3

すべてのトランクに対して G.711 コーデックのみを許可する音声クラス コーデック 100 を設定します。このシンプルなアプローチは、ほとんどの導入に適しています。必要に応じて、発信元システムと終端システムの両方でサポートされている追加のコーデック タイプをリストに追加できます。

DSP モジュールを使用したトランスコーディング を含むより複雑なソリューションはサポートされていますが、このガイドには含まれていません。 


voice class codec 100
 codec preference 1 g711ulaw
 codec preference 2 g711alaw

以下は、設定のフィールドの説明です。

音声クラス コーデック 100

SIP トランク コールの優先コーデックのみを許可するために使用されます。詳細については、音声クラス コーデックを参照してください。

4

音声クラス stun-usage 100 を設定して、Webex Calling トランクで ICE を有効にします。


voice class stun-usage 100 
 stun usage firewall-traversal flowdata
 stun usage ice lite

以下は、設定のフィールドの説明です。

STUNの使用法ice lite

可能なときは常に、メディア最適化を可能にする、すべての Webex Calling でダイヤルピアで ICE-Lite を有効にします。詳細については、音声クラス stun 使用状況 および使用状況のice liteを参照してください。

メディアの最適化は、可能な限り、ネゴシエートされます。通話に録画などのクラウド メディア サービスが必要な場合、メディアを最適化できません。

5

Webex トラフィックのメディア暗号化ポリシーを設定します。


voice class srtp-crypto 100
 crypto 1 AES_CM_128_HMAC_SHA1_80

以下は、設定のフィールドの説明です。

音声クラス srtp-crypto 100

オファーと応答メッセージの SDP で唯一の SRTP 暗号スイート CUBE が提供されるため、SHA1_80 を指定します。Webex Calling は SHA1_80 のみをサポートします。詳細については、「voice class srtp-crypto」を参照してください。

6

宛先トランク パラメータに基づいて、ローカル ゲートウェイ トランクへのコールを識別するパターンを設定します。 


voice class uri 100 sip
 pattern dtg=dallas1463285401_lgu

以下は、設定のフィールドの説明です。

音声クラス uri 100 sip

着信 SIP 招待を着信トランクダイヤルピアに一致させるパターンを定義します。このパターンを入力する場合は、dtg= の後に、トランクが作成されたときに Control Hub で提供されるトランク OTG/DTG 値を使用します。詳細については、音声クラス uri を参照してください。

7

SIP メッセージが Webex Calling に送信される前に、変更するために使用される sip プロファイル 100 を構成します。


voice class sip-profiles 100
 rule 10 request ANY sip-header SIP-Req-URI modify "sips:" "sip:"
 rule 20 request ANY sip-header To modify "" "" 
 rule 50 response ANY sip-header To modify "" ";otg=dallas1463285401_lgu>"
 rule 90 request ANY sip-header P-Asserted-Identity modify "sips:" "sip:"

以下は、設定のフィールドの説明です。

  • ルール 10 ～ 70 および 90

    コール シグナリングに使用される SIP ヘッダーが、Webex プロキシが必要な SIP スキームではなく、SIP を使用するようにします。SIP を使用するために CUBE を設定することで、セキュアな登録が使用されます。

  • ルール 80

    エンタープライズ内のローカル ゲートウェイ サイトを一意に識別するために、Control Hub からトランク グループ OTG/DTG 識別子を含めるために、From ヘッダーを変更します。

米国またはカナダの PSTN プロバイダーは、Webex Calling のスパムまたは詐欺通話の表示 の記事で言及されている追加設定を使用して、スパムおよび詐欺通話の発信者 ID 検証を提供できます。

8

Webex Calling トランクの設定:

  1. 音声クラス テナント 100 を作成して、Webex Calling トランクに特別に必要な設定を定義し、グループ化します。特に、以前の Control Hub で提供されたトランク登録の詳細は、以下の詳細に従って、このステップで使用されます。このテナントに関連付けられているダイヤルピアは、後でこれらの設定を継承します。

    次の例では、ステップ 1 で説明されている値を、このガイドの目的で使用しています（太字で示されています）。設定内のトランクの値に置き換えます。

    
voice class tenant 100
  registrar dns:98027369.us10.bcld.webex.com scheme sips expires 240 refresh-ratio 50 tcp tls
  credentials number Dallas1171197921_LGU username Dallas1463285401_LGU password 0 9Wt[M6ifY+ realm BroadWorks
  authentication username Dallas1463285401_LGU password 0 9Wt[M6ifY+ realm BroadWorks
  authentication username Dallas1463285401_LGU password 0 9Wt[M6ifY+ realm 98027369.us10.bcld.webex.com
  no remote-party-id
  sip-server dns:98027369.us10.bcld.webex.com
  connection-reuse
  srtp-crypto 100
  session transport tcp tls 
  no session refresh
  url sips 
  error-passthru
  rel1xx disable
  asserted-id pai 
  bind control source-interface GigabitEthernet0/0/1
  bind media source-interface GigabitEthernet0/0/1
  no pass-thru content custom-sdp 
  sip-profiles 100 
  outbound-proxy dns:dfw04.sipconnect-us.bcld.webex.com  
  privacy-policy passthru

    以下は、設定のフィールドの説明です。

    音声クラス テナント 100

    Webex Calling トランクにのみ使用される設定パラメータのセットを定義します。詳細については、音声クラス テナントを参照してください。

    登録者 dns:98027369.us10.bcld.webex.com スキーム sips 有効期限 240 更新比 50 tcp tls

    ローカル ゲートウェイの登録サーバーで、2 分ごとに更新が設定されている場合 (240 秒の 50%)。詳細については、登録者を参照してください。

    ここから Control Hub から [ドメインの登録] の値を使用していることを確認します。

    資格情報番号 Dallas1171197921_LGU ユーザー名 Dallas1463285401_LGU パスワード 0 9Wt[M6ifY+ realm BroadWorks

    トランク登録認証の資格情報。詳細については、「資格情報 (SIP UA)」を参照してください。

    ここから Control Hub から回線/ポートホスト、認証ユーザ名、認証パスワードの値を使用していることを確認します。

    認証ユーザー名 Dallas1171197921_LGU パスワード 0 9Wt[M6ifY+ realm BroadWorks
    認証ユーザー名 Dallas1171197921_LGU パスワード 0 9Wt[M6ifY+ realm 98027369.us10.bcld.webex.com

    コールの認証の課題。詳細については、認証 (ダイヤルピア) を参照してください。

    ここから Control Hub から、認証ユーザ名、認証パスワード、および登録ドメインの値をそれぞれ使用していることを確認します。

    no remote-party-id

    Webex Calling が PAI をサポートしているため、SIP Remote-Party-ID (RPID) ヘッダーを無効にします。これは asserted-id pai を使用して有効になります。詳細については、remote-party-id を参照してください。

    sip サーバ dns: us25.sipconnect.bcld.webex.com

    トランクのターゲット SIP サーバを設定します。トランクを作成したときに、Control Hub で提供されたエッジ プロキシ SRV アドレスを使用します。

    connection-reuse

    登録と通話処理に同じ永続的な接続を使用します。詳細については、connection-reuse を参照してください。

    srtp-crypto 100

    SRTP コール レッグ（接続）の優先暗号スイートを設定します（手順で指定）5). 詳細については、「voice class srtp-crypto」を参照してください。

    session transport tcp tls

    TLS へのトランスポートを設定します。詳細については、session-transport を参照してください。

    セッションの更新がありません

    CUBE と Webex 間の通話の SIP セッション更新を無効にします。詳細については、セッションの更新を参照してください。

    url sips

    SRVは、アクセス SBC によりサポートされている SIP である必要があります。その他のすべてのメッセージは、sip-profile 200 により SIP に変更されます。

    error-passthru

    SIP エラー応答パススルー機能を指定します。詳細については、error-passthru を参照してください。

    rel1xx を無効にする

    Webex Calling トランクに対する信頼できる仮応答の使用を無効にします。詳細については、rel1xx を参照してください。

    asserted-id pai

    (オプション) P-Asserted-Identity ヘッダー処理をオンにし、これが Webex Calling トランクに使用する方法を制御します。

    Webex Calling には、ローカル ゲートウェイへの発信コール INVITE の P-Asserted-Identity (PAI) ヘッダーが含まれています。

    このコマンドが設定されている場合、PAI ヘッダーからの発信者情報を使用して、発信元および PAI/Remote-Party-ID ヘッダーに入力します。

    このコマンドが設定されていない場合、From ヘッダーの発信者情報を使用して、発信 From ヘッダーと PAI/Remote-Party-ID ヘッダーに入力します。

    詳細については、asserted-id を参照してください。

    bind control source-interface GigabitEthernet0/0/1

    Webex Calling に送信されるメッセージのソース インターフェイスと関連する IP アドレスを設定します。詳細については、バインドを参照してください。

    bind media source-interface GigabitEthernet0/0/1

    WebexCalling に送信されるメディアのソース インターフェイスと関連する IP アドレスを設定します。詳細については、バインドを参照してください。

    no pass-thru content custom-sdp

    テナントの下のデフォルト コマンド。このコマンドの詳細については、pass-thru content を参照してください。

    sip プロファイル 100

    sip-profile 100 で定義されているように、SIP を SIP に変更し、INVITE および REGISTER メッセージの回線/ポートを変更します。詳細については、音声クラス sip-profiles を参照してください。

    outbound-proxy dns:dfw04.sipconnect-us.bcld.webex.com

    Webex Calling SBC にアクセスします。トランクを作成したときに、Control Hub で提供されるアウトバウンド プロキシ アドレスを挿入します。詳細については、outbound-proxy を参照してください。

    privacy-policy passthru

    トランクが受信メッセージから次のコール レッグにプライバシー値を渡すようにプライバシー ヘッダー ポリシー オプションを設定します。詳細については、プライバシー ポリシーを参照してください。

  2. Webex Calling トランクのダイヤルピアを設定します。 

    
dial-peer voice 100 voip
 description Inbound/Outbound Webex Calling
 max-conn 250
 destination-pattern BAD.BAD
 session protocol sipv2
 session target sip-server
 incoming uri request 100
 voice-class codec 100
 dtmf-relay rtp-nte
 voice-class stun-usage 100
 no voice-class sip localhost
 voice-class sip tenant 100
 srtp
 no vad

    以下は、設定のフィールドの説明です。

    
dial-peer voice 100 voip
  description Inbound/Outbound Webex Calling

    100 VoIP ダイヤルピアを定義し、管理とトラブルシューティングを容易にするための意味のある説明を行います。

    max-conn 250

    LGW と Webex Calling の間の同時着信および発信通話の数を制限します。登録トランクの場合、設定された最大値は 250 である必要があります。展開に適切であれば、ユーザの値を下げます。ローカル ゲートウェイの同時通話制限の詳細については、「ローカル ゲートウェイの使用を開始する 」ドキュメントを参照してください。

    宛先パターン BAD.BAD

    着信ダイヤルピア グループを使用して発信コールをルーティングする場合は、ダミー通知先パターンが必要です。この場合、有効な宛先パターンを使用できます。詳細については、「destination-pattern (interface)」を参照してください。

    session protocol sipv2

    ダイヤルピア 100 が SIP コール のコールコールを処理する場合に指定します。詳細については、セッション プロトコル (ダイヤルピア) を参照してください。

    session target sip-server

    テナント 100 で定義された SIP サーバが継承され、このダイヤル ピアからのコールの宛先に使用されることを示します。詳細については、セッション ターゲット (VoIP ダイヤル ピア) を参照してください。

    着信 uri リクエスト 100

    VoIP ダイヤル ピアと着信コールの Uniform Resource Identifier（URI）を照合するために使用される音声クラスを指定します。詳細については、着信 uri を参照してください。

    音声クラスのコーデック 100

    共通のコーデック フィルタ リスト 100 を使用するようにダイヤル ピアを設定します。詳細については、音声クラス コーデックを参照してください。

    音声クラス 使用量

    ローカル ゲートウェイでローカルで生成された STUN 要求が、ネゴシエートされたメディア パスを介して送信されるようにします。STUN は、メディア トラフィック用のファイアウォール ピンホールを開くのに役立ちます。

    no voice-class sip localhost

    送信メッセージの物理的 IP アドレスの代用として、From、Call-ID、Remote-Party-ID ヘッダーの DNS ローカル ホスト名の代入を無効にします。

    voice-class SIP テナント 100

    ダイヤル ピアは、グローバルおよびテナント 100 で設定されたすべてのパラメータを継承します。パラメータは、ダイヤルピア レベルでオーバーライドされる場合があります。

    srtp

    コールレグの SRTP を有効にする。

    no vad

    音声アクティブティの検出を無効にします。

テナント 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 トランクを使用したローカル ゲートウェイの設定

上記で Webex Calling に対してトランクを構築した場合、以下の構成を使用して、SIP ベースの PSTN プロバイダーに対して暗号化されていないトランクを作成します。

サービス プロバイダーがセキュアな PSTN トランクを提供している場合、Webex Calling トランクの上記と同様の設定に従う場合があります。CUBE はセキュアなコール ルーティングをサポートします。

TDM / ISDN PSTN トランクを使用している場合は、次のセクション [TDM PSTN トランクでローカル ゲートウェイを設定する] に進みます。

Cisco TDM-SIP ゲートウェイの PSTN コール レッグの TDM インターフェイスを設定するには、「ISDN PRI の構成」を参照してください。

1

PSTN トランクからの着信コールを識別するために、次の音声クラス uri を設定します。


voice class uri 200 sip
  host ipv4:192.168.80.13

以下は、設定のフィールドの説明です。

音声クラス uri 200 sip

着信 SIP 招待を着信トランクダイヤルピアに一致させるパターンを定義します。このパターンを入力する場合は、IP PSTN ゲートウェイの IP アドレスを使用します。詳細については、音声クラス uri を参照してください。

2

次の IP PSTN ダイヤル ピアを設定します。


dial-peer voice 200 voip
 description Inbound/Outbound IP PSTN trunk
 destination-pattern BAD.BAD
 session protocol sipv2
 session target ipv4:192.168.80.13
 incoming uri via 200
 voice-class sip asserted-id pai
 voice-class sip bind control source-interface GigabitEthernet0/0/0 
 voice-class sip bind media source-interface  GigabitEthernet0/0/0 
 voice-class codec 100
 dtmf-relay rtp-nte 
 no vad

以下は、設定のフィールドの説明です。


dial-peer voice 200 voip
 description Inbound/Outbound IP PSTN trunk

タグ 200 で VoIP ダイヤルピアを定義し、管理とトラブルシューティングを容易にする意味のある説明を提供します。詳細については、ダイヤルピアの音声を参照してください。

宛先パターン BAD.BAD

着信ダイヤルピア グループを使用して発信コールをルーティングする場合は、ダミー通知先パターンが必要です。この場合、有効な宛先パターンを使用できます。詳細については、「destination-pattern (interface)」を参照してください。

session protocol sipv2

このダイヤル ピアが SIP コール レッグを処理するように指定します。詳細については、セッション プロトコル (ダイヤル ピア) を参照してください。

セッション ターゲット ipv4: 192.168.80.13

PSTN プロバイダーに送信されるコールのターゲット アドレスを指定します。これは IP アドレスまたは DNS ホスト名です。詳細については、セッション ターゲット (VoIP ダイヤル ピア) を参照してください。

200 経由の着信 uri

INVITE 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/0

PSTN に送信されるメディアのソース インターフェイスと関連する IP アドレスを設定します。詳細については、バインドを参照してください。

音声クラスのコーデック 100

共通のコーデック フィルタ リスト 100 を使用するようにダイヤル ピアを設定します。詳細については、音声クラス コーデックを参照してください。

dtmf-relay rtp-nte

通話レグで予想される DTMF 機能として RTP-NTE (RFC2833) を定義します。詳細については、「DTMF リレー (音声オーバー IP)」を参照してください。

no vad

音声アクティブティの検出を無効にします。詳細については、vad (ダイヤル ピア) を参照してください。

3

ローカル ゲートウェイを Webex Calling と PSTN 間のコールのみをルーティングするように設定している場合は、次のコール ルーティング設定を追加します。Unified Communications Manager プラットフォームを使用してローカル ゲートウェイを設定する場合は、次のセクションに進みます。

  1. ダイヤルピア グループを作成して、Webex Calling または PSTN にコールをルーティングします。Webex Calling 向け発信ダイヤルピア 100 で DPG 100 を定義します。DPG 100 は、PSTN からの着信ダイヤルピアに適用されます。同様に、PSTN に向けて発信ダイヤルピア 200 を使用して DPG 200 を定義します。DPG 200 は、Webex からの着信ダイヤルピアに適用されます。

    
voice class dpg 100 
 description Route calls to Webex Calling 
 dial-peer 100 
voice class dpg 200 
 description Route calls to PSTN 
 dial-peer 200

    以下は、設定のフィールドの説明です。

    ダイヤルピア 100

    発信ダイヤルピアをダイヤルピア グループに関連付けます。詳細については、voice-class dpg を参照してください。

  2. ダイヤルピア グループを適用して、Webex から PSTN および PSTN から Webex に通話をルーティングします。 

    
dial-peer voice 100
 destination dpg 200
dial-peer voice 200
 destination dpg 100

    以下は、設定のフィールドの説明です。

    宛先 dpg 200

    どのダイヤルピア グループを指定し、この着信ダイヤルピアに提示されるコールのアウトバウンド処理に使用するかを指定します。

    これにより、ローカル ゲートウェイの設定が終了します。CUBE 機能が初めて設定される場合は、設定を保存し、プラットフォームを再読み込みします。

TDM PSTN トランクを使用したローカル ゲートウェイの設定

Webex Calling に向かってトランクを構築した後、次の設定を使用して、ループバック コール ルーティングを持つ PSTN サービスの TDM トランクを作成し、Webex コール レッグのメディア最適化を可能にします。

IP メディアの最適化を必要としない場合は、SIP PSTN トランクの設定手順に従います。PSTN VoIP ダイヤルピアの代わりに、音声ポートと POTS ダイヤルピア（ステップ 2 と 3 に示すように）を使用します。

1

ループバック ダイヤル ピア設定では、ダイヤル ピア グループとコール ルーティング タグを使用して、コール ルーティング ループを作成することなく、コールが Webex と PSTN の間で正しくパスされるようにします。コール ルーティング タグを追加および削除するために使用される次のトランスレーション ルールを設定します。


voice translation-rule 100 
 rule 1 /^\+/ /A2A/ 

voice translation-profile 100 
 translate called 100 

voice translation-rule 200 
 rule 1 /^/ /A1A/ 

voice translation-profile 200 
 translate called 200 

voice translation-rule 11 
 rule 1 /^A1A/ // 

voice translation-profile 11 
 translate called 11 

voice translation-rule 12 
 rule 1 /^A2A44/ /0/
 rule 2/^A2A/ /00/

voice translation-profile 12 
 translate called 12

以下は、設定のフィールドの説明です。

音声翻訳ルール

ルールで定義された正規表現を使用して、コール ルーティング タグを追加または削除します。十進法を超える数字（「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 インターフェイスの基本設定には、以下が含まれる場合があります。


card type e1 0 2 
isdn switch-type primary-net5 
controller E1 0/2/0 
 pri-group timeslots 1-31
3

次の TDM PSTN ダイヤル ピアを設定します。


dial-peer voice 200 pots 
 description Inbound/Outbound PRI PSTN trunk 
 destination-pattern BAD.BAD 
 translation-profile incoming 200 
 direct-inward-dial 
 port 0/2/0:15

以下は、設定のフィールドの説明です。 


dial-peer voice 200 pots
 description Inbound/Outbound PRI PSTN trunk

タグ 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 にルーティングされます。ルーティング タグを削除した後、コールはダイヤルピア グループを使用して発信トランクにルーティングされます。


dial-peer voice 10 voip
 description Outbound loop-around leg
 destination-pattern BAD.BAD
 session protocol sipv2
 session target ipv4:192.168.80.14
 voice-class sip bind control source-interface GigabitEthernet0/0/0
 voice-class sip bind media source-interface GigabitEthernet0/0/0
 dtmf-relay rtp-nte
 codec g711alaw
 no vad 

dial-peer voice 11 voip
 description Inbound loop-around leg towards Webex
 translation-profile incoming 11
 session protocol sipv2
 incoming called-number A1AT
 voice-class sip bind control source-interface GigabitEthernet0/0/0
 voice-class sip bind media source-interface GigabitEthernet0/0/0
 dtmf-relay rtp-nte
 codec g711alaw
 no vad 

dial-peer voice 12 voip
 description Inbound loop-around leg towards PSTN
 translation-profile incoming 12
 session protocol sipv2
 incoming called-number A2AT
 voice-class sip bind control source-interface GigabitEthernet0/0/0
 voice-class sip bind media source-interface GigabitEthernet0/0/0
 dtmf-relay rtp-nte
 codec g711alaw 
 no vad

以下は、設定のフィールドの説明です。 


dial-peer voice 10 voip
 description Outbound loop-around leg

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

次のコール ルーティング設定を追加します。

  1. ダイヤルピア グループを作成して、ループバック経由で PSTN と Webex トランク間のコールをルーティングします。

    
voice class dpg 100
 description Route calls to Webex Calling
 dial-peer 100
voice class dpg 200
 description Route calls to PSTN
 dial-peer 200
voice class dpg 10
 description Route calls to Loopback
 dial-peer 10

    以下は、設定のフィールドの説明です。

    ダイヤルピア 100

    発信ダイヤルピアをダイヤルピア グループに関連付けます。詳細については、voice-class dpg を参照してください。

  2. ダイヤル ピア グループを適用して通話をルーティングします。

    
dial-peer voice 100
 destination dpg 10
dial-peer voice 200
 destination dpg 10
dial-peer voice 11
 destination dpg 100
dial-peer voice 12
 destination dpg 200

    以下は、設定のフィールドの説明です。

    宛先 dpg 200

    どのダイヤルピア グループを指定し、この着信ダイヤルピアに提示されるコールのアウトバウンド処理に使用するかを指定します。

これにより、ローカル ゲートウェイの設定が終了します。CUBE 機能が初めて設定される場合は、設定を保存し、プラットフォームを再読み込みします。
ローカル ゲートウェイを既存の Unified CM 環境で構成する

前のセクションの 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 ヘッダーにこの値を入力できます。

SIP トランク セキュリティ プロファイル情報を入力
1

以下の音声クラス URI を設定:

  1. ポート経由の SIP を使用して、Unified CM から Webex 通話を分類します。

    
voice class uri 300 sip
 pattern :5065

  2. ポート経由の SIP を使用して、Unified CM から PSTN コールを分類します。

    
voice class uri 400 sip
 pattern 192\.168\.80\.6[0-5]:5060

    発信元のアドレスとポート番号を記述した 1 つ以上のパターンを使用して、UCM からの着信メッセージを PSTN トランクに分類します。必要に応じて、正規表現を使用して、一致するパターンを定義することができます。

    上記の例では、192.168.80.60 ～ 65 およびポート番号 5060 の任意の IP アドレスに正規表現が使用されます。

2

Unified CM ホストへの SRV ルーティングを指定するには、次の DNS レコードを設定します。

IOS XE は、ターゲット UCM ホストとポートをローカルで判別するためにこれらのレコードを使用します。この設定では、DNS システムでレコードを設定する必要はありません。DNS を使用する場合は、これらのローカル設定は必要ありません。


ip host ucmpub.mydomain.com 192.168.80.60
ip host ucmsub1.mydomain.com 192.168.80.61
ip host ucmsub2.mydomain.com 192.168.80.62
ip host ucmsub3.mydomain.com 192.168.80.63
ip host ucmsub4.mydomain.com 192.168.80.64
ip host ucmsub5.mydomain.com 192.168.80.65
ip host _sip._udp.wxtocucm.io srv 0 1 5065 ucmpub.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub1.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub2.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub3.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub4.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub5.mydomain.com
ip host _sip._udp.pstntocucm.io srv 0 1 5060 ucmpub.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub1.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub2.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub3.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub4.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub5.mydomain.com

以下は、設定のフィールドの説明です。

次のコマンドにより、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

次のダイヤル ピアを設定します。

  1. Unified CM と Webex Calling 間の通話のダイヤル ピア:

    
dial-peer voice 300 voip
 description UCM-Webex Calling trunk
 destination-pattern BAD.BAD
 session protocol sipv2
 session target dns:wxtocucm.io
 incoming uri via 300
 voice-class codec 100
 voice-class sip bind control source-interface GigabitEthernet 0/0/0
 voice-class sip bind media source-interface GigabitEthernet 0/0/0
 dtmf-relay rtp-nte
 no vad

    以下は、設定のフィールドの説明です。

    
dial-peer voice 300 voip
 description UCM-Webex Calling trunk

    タグ 300 で VoIP ダイヤルピアを定義し、管理とトラブルシューティングを容易にする意味のある説明を提供します。

    destination-pattern BAD.BAD

    着信ダイヤルピア グループを使用して発信コールをルーティングする場合は、ダミー通知先パターンが必要です。この場合、有効な宛先パターンを使用できます。

    session protocol sipv2

    ダイヤルピア 300 が SIP コール レッグを処理するように指定します。詳細については、セッション プロトコル (ダイヤルピア) を参照してください。

    セッション ターゲット dns:wxtocucm.io

    DNS SRV 解決により複数の Unified CM ノードのセッション ターゲットを定義します。この場合、ローカルで定義された SRV レコード wxtocucm.io がコールを転送するために使用されます。

    incoming uri via 300

    音声クラス URI 300 を使用して、ソース ポート 5065 を使用して、Unified CM からすべての着信トラフィックをこのダイヤルピアに誘導します。詳細については、着信 uri を参照してください。

    音声クラスのコーデック 100

    Unified CM 間のコールのコーデック フィルタ リストを示します。詳細については、音声クラス コーデックを参照してください。

    bind control source-interface GigabitEthernet0/0/0

    PSTN に送信されるメッセージのソース インターフェイスと関連する IP アドレスを設定します。詳細については、バインドを参照してください。

    bind media source-interface GigabitEthernet0/0/0

    PSTN に送信されるメディアのソース インターフェイスと関連する IP アドレスを設定します。詳細については、バインドを参照してください。

    dtmf-relay rtp-nte

    通話レグで予想される DTMF 機能として RTP-NTE (RFC2833) を定義します。詳細については、「DTMF リレー (音声オーバー IP)」を参照してください。

    no vad

    音声アクティブティの検出を無効にします。詳細については、vad (ダイヤル ピア) を参照してください。

  2. Unified CM と PSTN 間の通話のダイヤル ピア:

    
dial-peer voice 400 voip
 description UCM-PSTN trunk
 destination-pattern BAD.BAD
 session protocol sipv2
 session target dns:pstntocucm.io
 incoming uri via 400
 voice-class codec 100 
 voice-class sip bind control source-interface GigabitEthernet 0/0/0
 voice-class sip bind media source-interface GigabitEthernet 0/0/0
 dtmf-relay rtp-nte
 no vad

    以下は、設定のフィールドの説明です。

    
dial-peer voice 400 voip
 description UCM-PSTN trunk

    タグ 400 で VoIP ダイヤルピアを定義し、管理とトラブルシューティングを容易にする意味のある説明を提供します。

    destination-pattern BAD.BAD

    着信ダイヤルピア グループを使用して発信コールをルーティングする場合は、ダミー通知先パターンが必要です。この場合、有効な宛先パターンを使用できます。

    session protocol sipv2

    ダイヤルピア 400 が SIP コール レッグを処理するように指定します。詳細については、セッション プロトコル (ダイヤルピア) を参照してください。

    セッションターゲット dns:pstntocucm.io

    DNS SRV 解決により複数の Unified CM ノードのセッション ターゲットを定義します。この場合、ローカルで定義された SRV レコード pstntocucm.io がコールを転送するために使用されます。

    400 経由の着信 uri

    音声クラス URI 400 を使用して、ソース ポート 5060 を使用して指定された Unified CM ホストからのすべての着信トラフィックをこのダイヤルピアに誘導します。詳細については、着信 uri を参照してください。

    音声クラスのコーデック 100

    Unified CM 間のコールのコーデック フィルタ リストを示します。詳細については、音声クラス コーデックを参照してください。

    bind control source-interface GigabitEthernet0/0/0

    PSTN に送信されるメッセージのソース インターフェイスと関連する IP アドレスを設定します。詳細については、バインドを参照してください。

    bind media source-interface GigabitEthernet0/0/0

    PSTN に送信されるメディアのソース インターフェイスと関連する IP アドレスを設定します。詳細については、バインドを参照してください。

    dtmf-relay rtp-nte

    通話レグで予想される DTMF 機能として RTP-NTE (RFC2833) を定義します。詳細については、「DTMF リレー (音声オーバー IP)」を参照してください。

    no vad

    音声アクティブティの検出を無効にします。詳細については、vad (ダイヤル ピア) を参照してください。

4

次の設定を使用してコール ルーティングを追加します。

  1. ダイヤルピア グループを作成し、Unified CM と Webex Calling の間でコールをルーティングします。DPG 100 を 発信ダイヤルピア 100 で Webex Calling に対して定義します。DPG 100 は、Unified CM からの関連付けられた着信ダイヤルピアに適用されます。同様に、Unified CM に対して発信ダイヤルピア 300 を使用して DPG 300 を定義します。DPG 300 は、Webex からの着信ダイヤルピアに適用されます。

    
voice class dpg 100
 description Route calls to Webex Calling
 dial-peer 100
voice class dpg 300
 description Route calls to Unified CM Webex Calling trunk
 dial-peer 300

  2. Unified CM と PSTN の間でコールをルーティングするためのダイヤル ピア グループを作成します。PSTN に対して発信ダイヤルピア 200 で DPG 200 を定義します。DPG 200 は、Unified CM から関連する着信ダイヤルピアに適用されます。同様に、Unified CM に対して発信ダイヤルピア 400 を使用して DPG 400 を定義します。DPG 400 は、PSTN からの着信ダイヤルピアに適用されます。

    
voice class dpg 200
 description Route calls to PSTN
 dial-peer 200
voice class dpg 400
 description Route calls to Unified CM PSTN trunk
 dial-peer 400

    以下は、設定のフィールドの説明です。

    ダイヤルピア 100

    発信ダイヤルピアをダイヤルピア グループに関連付けます。詳細については、voice-class dpg を参照してください。

  3. ダイヤルピア グループを適用して、Webex から Unified CM および Unified CM から Webex に通話をルーティングします。 

    
dial-peer voice 100
 destination dpg 300
dial-peer voice 300
 destination dpg 100

    以下は、設定のフィールドの説明です。

    宛先 dpg 300

    どのダイヤルピア グループを指定し、この着信ダイヤルピアに提示されるコールのアウトバウンド処理に使用するかを指定します。

  4. ダイヤルピア グループを適用して、PSTN から Unified CM から Unified CM から PSTN に通話をルーティングします。

    
dial-peer voice 200
 destination dpg 400
dial-peer voice 400
 destination dpg 200

    これにより、ローカル ゲートウェイの設定が終了します。CUBE 機能が初めて設定されている場合、設定を保存し、プラットフォームを再読み込みします。

診断署名でローカル ゲートウェイを監視し、トラブルシューティングする

診断署名 (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 以降を実行しているローカル ゲートウェイ

  1. 診断署名はデフォルトで有効になっています。

  2. デバイスが Cisco IOS XE 17.6.1a 以降を実行している場合、プロアクティブ通知を送信するために使用されるセキュアなメール サーバを設定します。

    configure terminal 
call-home  
mail-server :@ priority 1 secure tls 
end

  3. 通知する管理者のメール アドレスでds_email 環境変数を設定します。 

    configure terminal 
call-home  
diagnostic-signature 
environment ds_email  
end

以下は、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 priority 1 secure tls 
diagnostic-signature 
environment ds_email "tacfaststart@gmail.com"

Cisco IOS XE ソフトウェアで起動するローカル ゲートウェイは OAuth に対応する一般的なウェブベースの Gmail クライアントではないので、特定の Gmail アカウント設定を行い、端末からメールを正しく処理するための権限を与える必要があります:

  1. [Google アカウントの管理] > [セキュリティ] に移動し、[安全性の低いアプリ アクセス] 設定をオンにします。

  2. 「はい、はい、それは私です」と答えます。Gmail から「Google は、Google 以外のアプリを使用してアカウントにサインインするユーザーを防ぎました」というメールを受け取ります。

プロアクティブ モニタリングのために診断署名をインストールする

CPU 使用率の監視

この DS は、SNMP OID を使用して 5 秒間 CPU 使用率を追跡します。1.3.6.1.4.1.9.2.1.56. 使用率が 75% 以上に達すると、すべてのデバッグを無効にし、ローカル ゲートウェイにインストールされている診断署名をアンインストールします。下記の手順を実行して署名をインストールします。

  1. show snmp コマンドを使用して、SNMP を有効にします。有効にしない場合は、snmp-server manager コマンドを設定します。

    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

  2. Diagnostic Signatures Lookup Tool の以下のドロップダウンオプションを使用して、DS 64224 をダウンロードします。

    フィールド名

    フィールド値

    プラットフォーム

    Cisco 4300、4400 ISR シリーズまたは Cisco CSR 1000V シリーズ

    製品

    Webex Calling ソリューションの CUBE Enterprise

    問題の範囲

    パフォーマンス

    問題の種類

    通知メールによる CPU 使用率が高い

  3. DS XML ファイルをローカルゲートウェイフラッシュにコピーします。

    LocalGateway# copy ftp://username:password@/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)

  4. ローカルゲートウェイに DS XML ファイルをインストールします。

    call-home diagnostic-signature load DS_64224.xml 
Load file DS_64224.xml success

  5. 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 がアンインストールされます。必要に応じて、DS 64224 を再インストールして、ローカル ゲートウェイの高い CPU 使用率のモニタリングを続行します。

SIP トランク登録のモニタリング

この DS は、60 秒ごとにクラウドにSIP トランクするローカル Webex Calling登録解除をチェックします。登録解除イベントが検出されると、メールと syslog の通知が生成され、2 回の登録解除後に自動的にアンインストールされます。署名をインストールするには、以下の手順を使用します。

  1. Diagnostic Signatures Lookup Tool の以下のドロップダウンオプションを使用して、DS 64117 をダウンロードします。

    フィールド名

    フィールド値

    プラットフォーム

    Cisco 4300、4400 ISR シリーズ、または Cisco CSR 1000V シリーズ

    製品

    Webex Calling ソリューションの CUBE Enterprise

    問題の範囲

    SIP-SIP

    問題の種類

    SIP トランクによる登録解除を行いました。

  2. DS XML ファイルをローカルゲートウェイにコピーします。

    copy ftp://username:password@/DS_64117.xml bootflash:

  3. ローカルゲートウェイに DS XML ファイルをインストールします。 

    call-home diagnostic-signature load DS_64117.xml 
Load file DS_64117.xml success 
LocalGateway#

  4. show call-home diagnostic-signature コマンドを使用 して、署名が正常にインストールされたことを確認します。状態の列には「登録済み」の値が必要です。

異常な通話切断の監視

この DS は、10 分ごとに SNMP ポーリングを使用して、SIP エラーの 403、488、503 で異常な通話切断を検出します。 エラーカウントの増分が最後の投票から 5 以上である場合、syslog とメール通知が生成されます。 署名をインストールするには、以下の手順を使用してください。

  1. show snmp コマンドを使用して、SNMP が有効かどうかを確認します。有効になっていない場合は、snmp-server manager コマンドを設定します。 

    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

  2. Diagnostic Signatures Lookup Tool の以下のオプションを使用して、DS 65221 をダウンロードします。

    フィールド名

    フィールド値

    プラットフォーム

    Cisco 4300、4400 ISR シリーズ、または Cisco CSR 1000V シリーズ

    製品

    Webex Calling ソリューションの CUBE Enterprise

    問題の範囲

    パフォーマンス

    問題の種類

    メールおよび Syslog 通知による SIP の異常通話切断検出

  3. DS XML ファイルをローカルゲートウェイにコピーします。 

    copy ftp://username:password@/DS_65221.xml bootflash:

  4. ローカルゲートウェイに DS XML ファイルをインストールします。 

    call-home diagnostic-signature load DS_65221.xml 
Load file DS_65221.xml success

  5. 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 を使用して、以下の手順を使用して、診断データの収集を自動化します。

  1. 収集された診断データがアップロードされる 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://:@cxd.cisco.com"  
end

    例： 

    call-home  
diagnostic-signature 
environment ds_fsurl_prefix " environment ds_fsurl_prefix "scp://612345678:abcdefghijklmnop@cxd.cisco.com"

  2. show snmp コマンドを使用して、SNMP が有効になっていることを確認します。有効になっていない場合は、snmp-server manager コマンドを設定します。

    show snmp 
%SNMP agent not enabled 
 
 
config t 
snmp-server manager 
end

  3. 高 CPU 使用率の期間中に、すべてのデバッグと診断署名を無効にするためのプロアクティブな措置として、高 CPU モニタリング DS 64224 をインストールしてください。Diagnostic Signatures Lookup Tool の以下のオプションを使用して、DS 64224 をダウンロードします。

    フィールド名

    フィールド値

    プラットフォーム

    Cisco 4300、4400 ISR シリーズ、または Cisco CSR 1000V シリーズ

    製品

    Webex Calling ソリューションの CUBE Enterprise

    問題の範囲

    パフォーマンス

    問題の種類

    通知メールによる CPU 使用率が高い

  4. 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

  5. DS XML ファイルをローカルゲートウェイにコピーします。

    copy ftp://username:password@/DS_64224.xml bootflash: 
copy ftp://username:password@/DS_65095.xml bootflash:

  6. ローカルゲートウェイに、高 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

  7. 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 
           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  
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 名

トリガー済み/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 deinstall

例:

call-home diagnostic-signature deinstall 64224

診断署名検索ツールに定期的に新しい署名が追加されます。これは展開で一般的に見られる問題に基づいて行います。TAC では現在、新しいカスタム署名の作成リクエストをサポートしていません。

Control Hub を介した Cisco IOS XE ゲートウェイの管理と検証

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 メッセージの処理を提供し、それらを必要なターゲットにルーティングします。

PSTN から Webex Calling 構成ソリューションへのコール ルーティング

オンプレミスの Cisco Unified Communications Manager ソリューションを Webex Calling に接続する場合、以下の図に示すソリューションを構築するためのベースラインとして、シンプルな PSTN ゲートウェイ構成を使用できます。この場合、Unified Communications Manager は、すべての PSTN および Webex Calling コールのルーティングと処理を一元化します。

Unified Communications Manager がすべての PSTN および Webex Calling コールのルーティングと処理を一元化したソリューションダイアグラム

このドキュメントでは、次の画像に示すホスト名、IP アドレス、およびインターフェイスが使用されます。オプションは、パブリックアドレスまたはプライベート（NAT の背後）アドレス指定用に提供されます。複数の CUBE インスタンス間でロード バランシングしない限り、SRV DNS レコードはオプションです。

証明書ベースのローカル ゲートウェイの設定で使用されるホスト名、IP アドレス、およびインターフェイス

このドキュメントの残りの構成ガイダンスを使用して、次のようにローカル ゲートウェイの設定を完了します。

接続とセキュリティを設定

ベースライン設定

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 インターフェイスに割り当てることを確認します。


interface GigabitEthernet0/0/0
 description Interface facing PSTN and/or CUCM
 ip address 192.168.80.14 255.255.255.0
!
interface GigabitEthernet0/0/1
 description Interface facing Webex Calling (Public address)
 ip address 198.51.100.1 255.255.255.240

2

対称暗号化を使用して、ルータの STUN クレデンシャルを保護します。プライマリ暗号化キーと暗号化タイプを次のように設定します。


key config-key password-encrypt YourPassword
password encryption aes
3

サポートされている 証明機関 (CA) によって署名されたドメインの証明書を使用して暗号化トラストポイントを作成します。

  1. 次の exec コマンドを使用して RSA 鍵ペアを作成します。

    crypto key generate rsa general-keys exportable label lgw-key modulus 4096

  2. 次の設定コマンドを使用して、証明書のトラストポイントを作成し、証明書署名要求で使用するフィールド値を指定します。 

    
crypto pki trustpoint LGW_CERT
 enrollment terminal pem
 fqdn none
 subject-name cn=cube1.lgw.com
 subject-alt-name cube1.lgw.com
 revocation-check none
 rsakeypair lgw-key
 hash sha256

    証明書フィールドのノート:

    • fqdn: これは Webex Calling の必須フィールドではありません。この設定を [なし] に設定すると、証明書署名要求に含まれないことを確認します。このコマンドを使用して FQDN を含める必要がある場合、ローカル ゲートウェイの操作には影響しません。

    • 件名: ローカル ゲートウェイからのコールを検証するには、Webex は SIP 連絡先ヘッダーの FQDN と SBC 証明書のサブジェクト共通名 (CN) 属性または SAN フィールドに含まれるサブジェクト代替名 (SAN) フィールドのいずれかに一致する必要があります。したがって、件名フィールドには少なくとも CN 属性を含める必要がありますが、必要に応じて、他の属性を含めることもできます。詳細については、件名を参照してください。

    • subject-alt-name: SBC 証明書のサブジェクト代替名（SAN）フィールドには、追加の FQDN のリストを含めることができます。証明書の件名 CN 属性が一致しない場合、WEBEX はこのリストをチェックして、ローカル ゲートウェイからのメッセージの SIP 連絡先ヘッダーを検証します。

    • ハッシュ: CSR は SHA256 を使用して署名することを強く推奨します。このアルゴリズムは、Cisco IOS XE 17.11.1 からデフォルトで使用され、以前のリリースでこのコマンドを使用して明示的に設定する必要があります。

  3. 次の exec または設定コマンドで証明書署名リクエスト（CSR）を生成し、サポートされている CA プロバイダーから署名付き証明書を要求するために使用します。

    crypto pki enroll LGW_CERT

4

ホスト証明書の認証に使用される中間署名 CA の証明書を提供します。次の exec または configuration コマンドを入力します。


crypto pki authenticate LGW_CERT

5

次の exec または設定コマンドを使用して、署名付きホスト証明書をインポートします。


crypto pki import LGW_CERT certificate

6

TLS1.2 の排他性を有効にし、次の設定コマンドを使用して、音声アプリケーションに使用するデフォルトのトラストポイントを指定します。


 sip-ua
  crypto signaling default trustpoint LGW_CERT
  transport tcp tls v1.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

ip http client source-interface GigabitEthernet0/0/1 
crypto pki trustpool import clean url https://www.cisco.com/security/pki/trs/ios_core.p7b
Webex Calling 証明書ベースのトランクを設定
1

Control Hub の既存のロケーションに対して CUBE 証明書ベースの PSTN トランクを作成します。詳細については、「Webex Calling のトランク、ルート グループ、ダイヤル プランを構成する」を参照してください。

トランクが作成されると、提供されたトランク情報をメモします。以下の図でハイライトされているこれらの詳細は、このガイドの設定手順で使用されます。

CUBE 証明書ベースの PSTN トランクが作成されます
2

次のコマンドを入力して、CUBE を Webex Calling ローカル ゲートウェイとして設定します。


voice service voip
 ip address trusted list
  ipv4 x.x.x.x y.y.y.y
 mode border-element
 allow-connections sip to sip
 no supplementary-service sip refer
 stun
  stun flowdata agent-id 1 boot-count 4
  stun flowdata shared-secret 0 Password123$
 sip 
  asymmetric payload full
  early-offer forced
  sip-profiles inbound

以下は、設定のフィールドの説明です。


ip address trusted list
 ipv4 x.x.x.x y.y.y.y

  • 有料詐欺から保護するために、信頼できるアドレス リストは、ローカル ゲートウェイが合法的な VoIP コールを期待するホストとネットワークエンティティのリストを定義します。

  • デフォルトでは、ローカル ゲートウェイは、信頼リストに含まれていない IP アドレスからのすべての着信 VoIP メッセージをブロックします。デフォルトでは、「セッション ターゲット IP」またはサーバ グループ IP アドレスを持つ静的に設定されたダイヤル ピアが信頼されます。これらの IP アドレスを信頼リストに追加する必要はありません。

  • ローカル ゲートウェイを設定するときに、地域の Webex Calling データ センターの IP サブネットをリストに追加します。詳細については、「Webex Calling のポート参照情報 」を参照してください。また、Unified Communications Manager サーバ（使用されている場合）と PSTN トランク ゲートウェイのアドレス範囲を追加します。

  • 料金詐欺を防ぐために IP アドレス信頼リストを使用する方法の詳細については、「信頼された IP アドレス」を参照してください。

モードの境界要素

プラットフォームで Cisco Unified Border Element（CUBE）機能を有効にします。

allow-connections sip to sip

CUBE の基本 SIP バックツーバックのユーザー エージェント機能を有効にします。詳細については、「接続を許可する」を参照してください。

デフォルトでは、T.38 ファックス トランスポートが有効になっています。詳細については、ファックス プロトコル t38 (音声サービス) を参照してください。

ストーン

STUN (NAT 経由の UDP のセッション トラバーサル) をグローバルに有効にします。

これらのグローバル stun コマンドは、ローカル ゲートウェイを NAT の背後に展開する場合にのみ必要です。

  • ローカル ゲートウェイの STUN バインディング機能を使用すると、ネゴシエートされたメディア パスを介して、ローカルで生成された STUN 要求を送信できます。これにより、ファイアウォールのピンホールを開くことができます。

詳細については、stun flowdata agent-id および stun flowdata shared-secret を参照してください。

非対称ペイロード (フル)

DTMF と動的コーデック ペイロードの両方に対して SIP 非対称ペイロード サポートを設定します。このコマンドの詳細については、非対称ペイロードを参照してください。

early-offer forced

ローカル ゲートウェイが、隣接ピアからの確認応答を待つ代わりに、最初の INVITE メッセージで SDP 情報を送信するように強制します。このコマンドの詳細については、早期オファーを参照してください。

SIP プロファイル インバウンド

CUBE が SIP プロファイルを使用してメッセージを受信したときに変更できるようにします。プロファイルはダイヤルピアまたはテナント経由で適用されます。

3

すべてのトランクに対して G.711 コーデックのみを許可する音声クラス コーデック 100 を設定します。このシンプルなアプローチは、ほとんどの導入に適しています。必要に応じて、発信元システムと終端システムの両方でサポートされている追加のコーデック タイプをリストに追加できます。

DSP モジュールを使用したトランスコーディング を含むより複雑なソリューションはサポートされていますが、このガイドには含まれていません。 


voice class codec 100
 codec preference 1 g711ulaw
 codec preference 2 g711alaw

以下は、設定のフィールドの説明です。

音声クラス コーデック 100

SIP トランク コールの優先コーデックのみを許可するために使用されます。詳細については、音声クラス コーデックを参照してください。

4

音声クラス stun-usage 100 を設定して、Webex Calling トランクで ICE を有効にします。(このステップは、政府版 Webex には適用されません)


voice class stun-usage 100 
 stun usage firewall-traversal flowdata
 stun usage ice lite

以下は、設定のフィールドの説明です。

STUNの使用法ice lite

可能なときは常に、メディア最適化を可能にする、すべての Webex Calling でダイヤルピアで ICE-Lite を有効にします。詳細については、音声クラス stun 使用状況 および使用状況のice liteを参照してください。

stun usage firewall-traversal flowdata コマンドは、NAT の背後にローカル ゲートウェイを展開する場合にのみ必要です。

メディアの最適化は、可能な限り、ネゴシエートされます。通話に録画などのクラウド メディア サービスが必要な場合、メディアを最適化できません。

5

Webex トラフィックのメディア暗号化ポリシーを設定します。(このステップは、政府版 Webex には適用されません)


voice class srtp-crypto 100
 crypto 1 AES_CM_128_HMAC_SHA1_80

以下は、設定のフィールドの説明です。

音声クラス srtp-crypto 100

オファーと応答メッセージの SDP で唯一の SRTP 暗号スイート CUBE が提供されるため、SHA1_80 を指定します。Webex Calling は SHA1_80 のみをサポートします。詳細については、「voice class srtp-crypto」を参照してください。

6

FIPS 対応 GCM 暗号を構成します(このステップは政府版 Webex にのみ適用されます)。 


voice class srtp-crypto 100
crypto 1 AEAD_AES_256_GCM

以下は、設定のフィールドの説明です。

音声クラス srtp-crypto 100

CUBE が提供する暗号スイートとして GCM を指定します。政府版 Webex のローカル ゲートウェイの GCM 暗号を設定する必要があります。

7

宛先 FQDN または SRV に基づいて、ローカル ゲートウェイ トランクへのコールを一意に識別するパターンを設定します。


voice class uri 100 sip
 pattern cube1.lgw.com

以下は、設定のフィールドの説明です。

音声クラス uri 100 sip

着信 SIP 招待を着信トランクダイヤルピアに一致させるパターンを定義します。このパターンを入力する場合は、トランク用に Control Hub で設定されたトランク FQDN または SRV を使用します。

8

SIP メッセージ操作プロファイルを設定します。ゲートウェイにパブリック IP アドレスが設定されている場合は、次のようにプロファイルを設定するか、NAT を使用している場合は、次のステップにスキップします。この例では、cube1.lgw.com はローカル ゲートウェイに設定されている FQDN です。


voice class sip-profiles 100
 rule 10 request ANY sip-header Contact modify "@.*:" "@cube1.lgw.com:" 
 rule 20 response ANY sip-header Contact modify "@.*:" "@cube1.lgw.com:"

以下は、設定のフィールドの説明です。

ルール 10 と 20

Webex がローカル ゲートウェイからのメッセージを認証できるようにするには、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 プロファイル 

voice class sip-profiles 100
 rule 10 request ANY sip-header Contact modify "@.*:" "@cube1.lgw.com:"
 rule 20 response ANY sip-header Contact modify "@.*:" "@cube1.lgw.com:"
 rule 30 response ANY sdp-header Audio-Attribute modify "(a=candidate:1 1.*) 10.80.13.12" "\1 192.65.79.20"
 rule 31 response ANY sdp-header Audio-Attribute modify "(a=candidate:1 2.*) 10.80.13.12" "\1 192.65.79.20"
 rule 40 response ANY sdp-header Audio-Connection-Info modify "IN IP4 10.80.13.12" "IN IP4 192.65.79.20"
 rule 41 request ANY sdp-header Audio-Connection-Info modify "IN IP4 10.80.13.12" "IN IP4 192.65.79.20"
 rule 50 request ANY sdp-header Connection-Info modify "IN IP4 10.80.13.12" "IN IP4 192.65.79.20"
 rule 51 response ANY sdp-header Connection-Info modify "IN IP4 10.80.13.12" "IN IP4 192.65.79.20"
 rule 60 response ANY sdp-header Session-Owner modify "IN IP4 10.80.13.12" "IN IP4 192.65.79.20"
 rule 61 request ANY sdp-header Session-Owner modify "IN IP4 10.80.13.12" "IN IP4 192.65.79.20"
 rule 70 request ANY sdp-header Audio-Attribute modify "(a=rtcp:.*) 10.80.13.12" "\1 192.65.79.20"
 rule 71 response ANY sdp-header Audio-Attribute modify "(a=rtcp:.*) 10.80.13.12" "\1 192.65.79.20"
 rule 80 request ANY sdp-header Audio-Attribute modify "(a=candidate:1 1.*) 10.80.13.12" "\1 192.65.79.20"
 rule 81 request ANY sdp-header Audio-Attribute modify "(a=candidate:1 2.*) 10.80.13.12" "\1 192.65.79.20"

以下は、設定のフィールドの説明です。

ルール 10 と 20

Webex がローカル ゲートウェイからのメッセージを認証できるようにするには、SIP リクエストと応答メッセージの「Contact」ヘッダーに Control Hub のトランクにプロビジョニングされた値が含まれている必要があります。これは、単一のホストの FQDN か、デバイスのクラスタに使用される SRV 名になります。

ルール 30 ～ 81

プライベート アドレスの参照をサイトの外部パブリック アドレスに変換し、Webex が後続のメッセージを正しく解釈してルーティングできるようにします。

Webex Calling からの受信メッセージの SIP プロファイル 

voice class sip-profiles 110
 rule 10 response ANY sdp-header Video-Connection-Info modify "192.65.79.20" "10.80.13.12"
 rule 20 response ANY sip-header Contact modify "@.*:" "@cube1.lgw.com:"
 rule 30 response ANY sdp-header Connection-Info modify "192.65.79.20" "10.80.13.12"
 rule 40 response ANY sdp-header Audio-Connection-Info modify "192.65.79.20" "10.80.13.12"
 rule 50 response ANY sdp-header Session-Owner modify "192.65.79.20" "10.80.13.12"
 rule 60 response ANY sdp-header Audio-Attribute modify "(a=candidate:1 1.*) 192.65.79.20" "\1 10.80.13.12"
 rule 70 response ANY sdp-header Audio-Attribute modify "(a=candidate:1 2.*) 192.65.79.20" "\1 10.80.13.12"
 rule 80 response ANY sdp-header Audio-Attribute modify "(a=rtcp:.*) 192.65.79.20" "\1 10.80.13.12"

以下は、設定のフィールドの説明です。

ルール 10 ～ 80

パブリック アドレス参照を設定したプライベート アドレスに変換し、CUBE が Webex からのメッセージを処理できるようにします。

詳細については、音声クラス sip-profiles を参照してください。

米国またはカナダの PSTN プロバイダーは、Webex Calling のスパムまたは詐欺通話の表示 の記事で言及されている追加設定を使用して、スパムおよび詐欺通話の発信者 ID 検証を提供できます。

10

ヘッダー変更プロファイルを使用して、SIP オプション キープアライブを設定します。


voice class sip-profiles 115
 rule 10 request OPTIONS sip-header Contact modify "

以下は、設定のフィールドの説明です。

音声クラス 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 トランクの設定:

  1. 音声クラス テナント 100 を作成して、Webex Calling トランクに特別に必要な設定を定義し、グループ化します。このテナントに関連付けられているダイヤルピアは、後でこれらの設定を継承します。

    次の例では、ステップ 1 で説明されている値を、このガイドの目的で使用しています（太字で示されています）。設定内のトランクの値に置き換えます。

    
voice class tenant 100
 no remote-party-id
 sip-server dns:us25.sipconnect.bcld.webex.com
 srtp-crypto 100
 localhost dns:cube1.lgw.com
 session transport tcp tls
 no session refresh
 error-passthru
 rel1xx disable
 asserted-id pai
 bind control source-interface GigabitEthernet0/0/1
 bind media source-interface GigabitEthernet0/0/1
 no pass-thru content custom-sdp
 sip-profiles 100 
 sip-profiles 110 inbound
 privacy-policy passthru
!

    以下は、設定のフィールドの説明です。

    音声クラス テナント 100

    独自の TLS 証明書と CN または SAN 検証リストを持つトランクを設定するには、テナントを使用することをお勧めします。ここでは、テナントに関連付けられた tls プロファイルには、新しい接続を受け入れまたは作成するために使用される信頼ポイントが含まれており、着信接続を検証するための CN または SAN リストがあります。詳細については、音声クラス テナントを参照してください。

    no remote-party-id

    Webex Calling が PAI をサポートしているため、SIP Remote-Party-ID (RPID) ヘッダーを無効にします。これは asserted-id pai コマンドを使用して有効になります。詳細については、remote-party-id を参照してください。

    sip サーバ dns: us25.sipconnect.bcld.webex.com

    トランクのターゲット SIP サーバを設定します。トランクを作成したときに、Control Hub で提供されたエッジ プロキシ SRV アドレスを使用します

    srtp-crypto 100

    SRTP コール レッグ（接続）の優先暗号スイートを設定します（ステップで指定）5). 詳細については、「voice class srtp-crypto」を参照してください。

    ローカルホスト DNS: cube1.lgw.com

    発信メッセージの From、Call-ID、および Remote-Party-ID ヘッダー内の物理 IP アドレスを提供された FQDN で置き換えるように CUBE を設定します。ここでトランクのために Control Hub で設定されたトランク FQDN または SRV を使用します。

    session transport tcp tls

    関連するダイヤルピアの TLS へのトランスポートを設定します。詳細については、session-transport を参照してください。

    セッションの更新がありません

    CUBE と Webex 間の通話の SIP セッション更新を無効にします。詳細については、セッションの更新を参照してください。

    error-passthru

    SIP エラー応答パススルー機能を指定します。詳細については、error-passthru を参照してください。

    rel1xx を無効にする

    Webex Calling トランクに対する信頼できる仮応答の使用を無効にします。詳細については、rel1xx を参照してください。

    asserted-id pai

    (オプション) P-Asserted-Identity ヘッダー処理をオンにし、これが Webex Calling トランクに使用する方法を制御します。

    Webex Calling には、ローカル ゲートウェイへの発信コール INVITE の P-Asserted-Identity (PAI) ヘッダーが含まれています。

    このコマンドが設定されている場合、PAI ヘッダーからの発信者情報を使用して、発信元および PAI/Remote-Party-ID ヘッダーに入力します。

    このコマンドが設定されていない場合、From ヘッダーの発信者情報を使用して、発信 From ヘッダーと PAI/Remote-Party-ID ヘッダーに入力します。

    詳細については、asserted-id を参照してください。

    bind control source-interface GigabitEthernet0/0/1

    Webex Calling に送信されるメッセージのソース インターフェイスと関連する IP アドレスを設定します。詳細については、バインドを参照してください。

    bind media source-interface GigabitEthernet0/0/1

    Webex Calling に送信されるメディアのソース インターフェイスと関連する IP アドレスを設定します。詳細については、バインドを参照してください。

    voice-class SIP プロファイル 100

    アウトバウンド メッセージに使用するヘッダー変更プロファイル（パブリック IP または NAT アドレッシング）を適用します。詳細については、「voice-class sip profiles」を参照してください。

    音声クラス SIP プロファイル 110 インバウンド

    NAT のみの背後にある LGW 展開の場合: 着信メッセージに使用するヘッダー変更プロファイルを適用します。詳細については、音声クラス sip プロファイルを参照してください。

    privacy-policy passthru

    受信メッセージから次のコール レッグにプライバシー ヘッダーを透過的に渡すように CUBE を設定します。詳細については、プライバシー ポリシーを参照してください。

  2. Webex Calling トランクのダイヤルピアを設定します。

    
dial-peer voice 100 voip
 description Inbound/Outbound Webex Calling
 destination-pattern BAD.BAD
 session protocol sipv2
 session target sip-server
 incoming uri request 100
 voice-class codec 100
 voice-class stun-usage 100
 voice-class sip tenant 100
 voice-class sip options-keepalive profile 100
 dtmf-relay rtp-nte 
 srtp
 no vad

    以下は、設定のフィールドの説明です。

    
dial-peer voice 100 voip
 description Inbound/Outbound Webex Calling

    タグ 100 で VoIP ダイヤルピアを定義し、管理とトラブルシューティングを容易にする意味のある説明を提供します。詳細については、ダイヤルピアの音声を参照してください。

    宛先パターン BAD.BAD

    着信ダイヤルピア グループを使用して発信コールをルーティングする場合は、ダミー通知先パターンが必要です。この場合、有効な宛先パターンを使用できます。詳細については、「destination-pattern (interface)」を参照してください。

    session protocol sipv2

    このダイヤル ピアが SIP コール レッグを処理するように指定します。詳細については、セッション プロトコル (ダイヤルピア) を参照してください。

    session target sip-server

    テナント 100 で定義された SIP サーバが継承され、このダイヤル ピアからのコールの宛先に使用されることを示します。

    着信 uri リクエスト 100

    INVITE 要求ヘッダー URI を使用して、着信コールをこのダイヤルピアに照合するために使用される音声クラスを指定します。詳細については、着信 uri を参照してください。

    音声クラスのコーデック 100

    Webex Calling 間の通話のコーデック フィルター リストを示します。詳細については、音声クラス コーデックを参照してください。

    音声クラス 使用量

    ローカル ゲートウェイからローカルで生成された STUN 要求を、ネゴシエートされたメディア パスを介して送信できるようにします。STUN パケットは、メディア トラフィックのためのファイアウォール ピンホールを開き、メディア最適化のための有効なパスを検出するのに役立ちます。

    音声クラス SIP テナント 100

    ダイヤル ピアは、グローバルおよびテナント 100 で設定されたすべてのパラメータを継承します。パラメータは、ダイヤルピア レベルでオーバーライドされる場合があります。詳細については、「voice-class sip tenant」を参照してください。

    voice-class sip options-keepalive profile 100

    このコマンドは、特定のプロファイル（100）を使用して、SIP サーバまたはエンドポイントのグループの可用性を監視するために使用されます。

    srtp

    コールレグの SRTP を有効にする。

SIP PSTN トランクを使用したローカル ゲートウェイの設定
TDM PSTN トランクを使用したローカル ゲートウェイの設定
ローカル ゲートウェイを既存の Unified CM 環境で構成する

前のセクションの PSTN-Webex Calling の設定は、Cisco Unified Communications Manager (UCM) クラスタに追加のトランクを含めるように変更できます。この場合、すべてのコールは Unified CM 経由でルーティングされます。ポート 5060 の UCM からのコールは PSTN にルーティングされ、ポート 5065 からのコールは Webex Calling にルーティングされます。この通話シナリオを含めるには、次の増分設定を追加できます。

1

以下の音声クラス URI を設定:

  1. ポート経由の SIP を使用して、Unified CM から Webex 通話を分類します。

    
voice class uri 300 sip
 pattern :5065

  2. ポート経由の SIP を使用して、Unified CM から PSTN コールを分類します。

    
voice class uri 400 sip
 pattern 192\.168\.80\.6[0-5]:5060

    発信元のアドレスとポート番号を記述した 1 つ以上のパターンを使用して、UCM からの着信メッセージを PSTN トランクに分類します。必要に応じて、正規表現を使用して、一致するパターンを定義することができます。

    上記の例では、192.168.80.60 ～ 65 およびポート番号 5060 の任意の IP アドレスに正規表現が使用されます。

2

Unified CM ホストへの SRV ルーティングを指定するには、次の DNS レコードを設定します。

IOS XE は、ターゲット UCM ホストとポートをローカルで判別するためにこれらのレコードを使用します。この設定では、DNS システムでレコードを設定する必要はありません。DNS を使用する場合は、これらのローカル設定は必要ありません。


ip host ucmpub.mydomain.com 192.168.80.60
ip host ucmsub1.mydomain.com 192.168.80.61
ip host ucmsub2.mydomain.com 192.168.80.62
ip host ucmsub3.mydomain.com 192.168.80.63
ip host ucmsub4.mydomain.com 192.168.80.64
ip host ucmsub5.mydomain.com 192.168.80.65
ip host _sip._udp.wxtocucm.io srv 0 1 5065 ucmpub.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub1.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub2.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub3.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub4.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub5.mydomain.com
ip host _sip._udp.pstntocucm.io srv 0 1 5060 ucmpub.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub1.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub2.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub3.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub4.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub5.mydomain.com

以下は、設定のフィールドの説明です。

次のコマンドにより、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

次のダイヤル ピアを設定します。

  1. Unified CM と Webex Calling 間の通話のダイヤル ピア:

    
dial-peer voice 300 voip
 description UCM-Webex Calling trunk
 destination-pattern BAD.BAD
 session protocol sipv2
 session target dns:wxtocucm.io
 incoming uri via 300
 voice-class codec 100
 voice-class sip bind control source-interface GigabitEthernet 0/0/0
 voice-class sip bind media source-interface GigabitEthernet 0/0/0
 dtmf-relay rtp-nte
 no vad

    以下は、設定のフィールドの説明です。

    
dial-peer voice 300 voip
 description UCM-Webex Calling trunk

    タグ 300 で VoIP ダイヤルピアを定義し、管理とトラブルシューティングを容易にする意味のある説明を提供します。

    destination-pattern BAD.BAD

    着信ダイヤルピア グループを使用して発信コールをルーティングする場合は、ダミー通知先パターンが必要です。この場合、有効な宛先パターンを使用できます。

    session protocol sipv2

    ダイヤルピア 300 が SIP コール レッグを処理するように指定します。詳細については、セッション プロトコル (ダイヤルピア) を参照してください。

    セッション ターゲット dns:wxtocucm.io

    DNS SRV 解決により複数の Unified CM ノードのセッション ターゲットを定義します。この場合、ローカルで定義された SRV レコード wxtocucm.io がコールを転送するために使用されます。

    incoming uri via 300

    音声クラス URI 300 を使用して、ソース ポート 5065 を使用して、Unified CM からすべての着信トラフィックをこのダイヤルピアに誘導します。詳細については、着信 uri を参照してください。

    音声クラスのコーデック 100

    Unified CM 間のコールのコーデック フィルタ リストを示します。詳細については、音声クラス コーデックを参照してください。

    bind control source-interface GigabitEthernet0/0/0

    PSTN に送信されるメッセージのソース インターフェイスと関連する IP アドレスを設定します。詳細については、バインドを参照してください。

    bind media source-interface GigabitEthernet0/0/0

    PSTN に送信されるメディアのソース インターフェイスと関連する IP アドレスを設定します。詳細については、バインドを参照してください。

    dtmf-relay rtp-nte

    通話レグで予想される DTMF 機能として RTP-NTE (RFC2833) を定義します。詳細については、「DTMF リレー (音声オーバー IP)」を参照してください。

    no vad

    音声アクティブティの検出を無効にします。詳細については、vad (ダイヤル ピア) を参照してください。

  2. Unified CM と PSTN 間の通話のダイヤル ピア:

    
dial-peer voice 400 voip
 description UCM-PSTN trunk
 destination-pattern BAD.BAD
 session protocol sipv2
 session target dns:pstntocucm.io
 incoming uri via 400
 voice-class codec 100 
 voice-class sip bind control source-interface GigabitEthernet 0/0/0
 voice-class sip bind media source-interface GigabitEthernet 0/0/0
 dtmf-relay rtp-nte
 no vad

    以下は、設定のフィールドの説明です。

    
dial-peer voice 400 voip
 description UCM-PSTN trunk

    タグ 400 で VoIP ダイヤルピアを定義し、管理とトラブルシューティングを容易にする意味のある説明を提供します。

    destination-pattern BAD.BAD

    着信ダイヤルピア グループを使用して発信コールをルーティングする場合は、ダミー通知先パターンが必要です。この場合、有効な宛先パターンを使用できます。

    session protocol sipv2

    ダイヤルピア 400 が SIP コール レッグを処理するように指定します。詳細については、セッション プロトコル (ダイヤルピア) を参照してください。

    セッションターゲット dns:pstntocucm.io

    DNS SRV 解決により複数の Unified CM ノードのセッション ターゲットを定義します。この場合、ローカルで定義された SRV レコード pstntocucm.io がコールを転送するために使用されます。

    400 経由の着信 uri

    音声クラス URI 400 を使用して、ソース ポート 5060 を使用して指定された Unified CM ホストからのすべての着信トラフィックをこのダイヤルピアに誘導します。詳細については、着信 uri を参照してください。

    音声クラスのコーデック 100

    Unified CM 間のコールのコーデック フィルタ リストを示します。詳細については、音声クラス コーデックを参照してください。

    bind control source-interface GigabitEthernet0/0/0

    PSTN に送信されるメッセージのソース インターフェイスと関連する IP アドレスを設定します。詳細については、バインドを参照してください。

    bind media source-interface GigabitEthernet0/0/0

    PSTN に送信されるメディアのソース インターフェイスと関連する IP アドレスを設定します。詳細については、バインドを参照してください。

    dtmf-relay rtp-nte

    通話レグで予想される DTMF 機能として RTP-NTE (RFC2833) を定義します。詳細については、「DTMF リレー (音声オーバー IP)」を参照してください。

    no vad

    音声アクティブティの検出を無効にします。詳細については、vad (ダイヤル ピア) を参照してください。

4

次の設定を使用してコール ルーティングを追加します。

  1. ダイヤルピア グループを作成し、Unified CM と Webex Calling の間でコールをルーティングします。DPG 100 を 発信ダイヤルピア 100 で Webex Calling に対して定義します。DPG 100 は、Unified CM からの関連付けられた着信ダイヤルピアに適用されます。同様に、Unified CM に対して発信ダイヤルピア 300 を使用して DPG 300 を定義します。DPG 300 は、Webex からの着信ダイヤルピアに適用されます。

    
voice class dpg 100
 description Route calls to Webex Calling
 dial-peer 100
voice class dpg 300
 description Route calls to Unified CM Webex Calling trunk
 dial-peer 300

  2. Unified CM と PSTN の間でコールをルーティングするためのダイヤル ピア グループを作成します。PSTN に対して発信ダイヤルピア 200 で DPG 200 を定義します。DPG 200 は、Unified CM から関連する着信ダイヤルピアに適用されます。同様に、Unified CM に対して発信ダイヤルピア 400 を使用して DPG 400 を定義します。DPG 400 は、PSTN からの着信ダイヤルピアに適用されます。

    
voice class dpg 200
 description Route calls to PSTN
 dial-peer 200
voice class dpg 400
 description Route calls to Unified CM PSTN trunk
 dial-peer 400

    以下は、設定のフィールドの説明です。

    ダイヤルピア 100

    発信ダイヤルピアをダイヤルピア グループに関連付けます。詳細については、voice-class dpg を参照してください。

  3. ダイヤルピア グループを適用して、Webex から Unified CM および Unified CM から Webex に通話をルーティングします。 

    
dial-peer voice 100
 destination dpg 300
dial-peer voice 300
 destination dpg 100

    以下は、設定のフィールドの説明です。

    宛先 dpg 300

    どのダイヤルピア グループを指定し、この着信ダイヤルピアに提示されるコールのアウトバウンド処理に使用するかを指定します。

  4. ダイヤルピア グループを適用して、PSTN から Unified CM から Unified CM から PSTN に通話をルーティングします。

    
dial-peer voice 200
 destination dpg 400
dial-peer voice 400
 destination dpg 200

    これにより、ローカル ゲートウェイの設定が終了します。CUBE 機能が初めて設定されている場合、設定を保存し、プラットフォームを再読み込みします。

診断署名でローカル ゲートウェイを監視し、トラブルシューティングする

診断署名 (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 以上を実行するローカル ゲートウェイ

  1. 診断署名はデフォルトで有効になっています。

  2. デバイスが IOS XE 17.6.1 以上を実行している場合に、プロアクティブ通知を送信するために使用する安全なメール サーバーを構成します。

    
configure terminal 
call-home  
mail-server :@ priority 1 secure tls 
end

  3. 通知する管理者 ds_email のメールアドレスを使用して、環境変数を設定します。

    
configure terminal 
call-home  
diagnostic-signature 
LocalGateway(cfg-call-home-diag-sign)environment ds_email  
end

プロアクティブ モニタリングのために診断署名をインストールする

CPU 使用率の監視

この DS は SNMP OID 1.3.6.1.4.1.9.2.1.56 を使用して 5 秒間の CPU 使用率を追跡します。使用率が 75% 以上に達すると、すべてのデバッグが無効し、ローカル ゲートウェイにインストールした診断署名をアンインストールします。下記の手順を実行して署名をインストールします。

  1. コマンドを使用して SNMP を有効に設定し、 snmp を表示します。SNMP が有効になっていない場合は、snmp-server manager コマンドを設定します。

    
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

  2. Diagnostic Signatures Lookup Tool の以下のドロップダウンオプションを使用して、DS 64224 をダウンロードします。

    copy ftp://username:password@/DS_64224.xml bootflash:

    フィールド名

    フィールド値

    プラットフォーム

    Cisco 4300、4400 ISR シリーズ、または Catalyst 8000V Edge ソフトウェア

    製品

    Webex Calling ソリューションの CUBE Enterprise

    問題の範囲

    パフォーマンス

    問題の種類

    メール通知による高 CPU 使用率

    Diagnostic Signatures Lookup ツールから DS 64224 をダウンロードする

  3. DS XML ファイルをローカルゲートウェイフラッシュにコピーします。

    copy ftp://username:password@/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)

  4. ローカルゲートウェイに DS XML ファイルをインストールします。

    
call-home diagnostic-signature load DS_64224.xml 
Load file DS_64224.xml success

  5. 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 使用率の監視を続行してください。

異常な通話切断の監視

この DS は、10 分ごとに SNMP ポーリングを使用して、SIP エラーの 403、488、503 で異常な通話切断を検出します。 エラーカウントの増分が最後の投票から 5 以上である場合、syslog とメール通知が生成されます。 署名をインストールするには、以下の手順を使用してください。

  1. コマンド show snmp を使用して、SNMP が有効 になっている必要があります。SNMP が有効になっていない場合は、snmp-server manager コマンドを設定します。 

    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

  2. Diagnostic Signatures Lookup Tool の以下のオプションを使用して、DS 65221 をダウンロードします。

    フィールド名

    フィールド値

    プラットフォーム

    Cisco 4300、4400 ISR シリーズ、または Catalyst 8000V Edge ソフトウェア

    製品

    Webex Calling ソリューションの CUBE Enterprise

    問題の範囲

    パフォーマンス

    問題の種類

    メールおよび Syslog 通知による SIP の異常通話切断検出

  3. DS XML ファイルをローカルゲートウェイにコピーします。

    copy ftp://username:password@/DS_65221.xml bootflash:

  4. ローカルゲートウェイに DS XML ファイルをインストールします。 

    
call-home diagnostic-signature load DS_65221.xml 
Load file DS_65221.xml success

  5. コマンド 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 を使用して、以下の手順を使用して、診断データの収集を自動化します。

  1. 診断データをアップロードするために、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://:@cxd.cisco.com"  
end

    例: 

    
call-home  
diagnostic-signature 
environment ds_fsurl_prefix " environment ds_fsurl_prefix "scp://612345678:abcdefghijklmnop@cxd.cisco.com"

  2. コマンド show snmp を使用して、SNMP が有効 になっている必要があります。SNMP が有効になっていない場合は、snmp-server manager コマンドを設定します。

    
show snmp 
%SNMP agent not enabled 
 
config t 
snmp-server manager 
end

  3. 高 CPU 使用率の期間中に、すべてのデバッグと診断署名を無効にすることを推奨するプロアクティブな措置として、高 CPU モニタリング DS 64224 をインストールすることを推奨します。Diagnostic Signatures Lookup Tool の以下のオプションを使用して、DS 64224 をダウンロードします。

    フィールド名

    フィールド値

    プラットフォーム

    Cisco 4300、4400 ISR シリーズ、または Catalyst 8000V Edge ソフトウェア

    製品

    Webex Calling ソリューションの CUBE Enterprise

    問題の範囲

    パフォーマンス

    問題の種類

    通知メールによる CPU 使用率が高い

  4. 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

  5. DS XML ファイルをローカルゲートウェイにコピーします。

    
copy ftp://username:password@/DS_64224.xml bootflash: 
copy ftp://username:password@/DS_65095.xml bootflash:

  6. 高 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

  7. 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

    DSLGW_IEC_C_all_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 名

トリガー済み/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 deinstall

例:

call-home diagnostic-signature deinstall 64224

診断署名ルックアップ ツールに、展開で見られる問題に基づいて、定期的に新しい署名が追加されます。TAC では現在、新しいカスタム署名の作成リクエストをサポートしていません。

ローカル ゲートウェイとして CUBE のハイ アベイラビリティを実装する

基礎

前提条件

Webex Calling のローカル ゲートウェイとして CUBE HA を展開する前に、以下の概念を深く理解するようにしてください。

この記事で提供される構成ガイドラインは、既存の音声構成が設定されていない専用のローカル ゲートウェイ プラットフォームが使用されていることを前提としています。既存の 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 設定ガイドを次に示します。

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

インターフェイスのステータスを追跡するために、グローバル レベルでインターフェイス トラッキングを構成します。

conf t
 track 1 interface GigabitEthernet1 line-protocol
 track 2 interface GigabitEthernet2 line-protocol
 exit


VCUBE-1#conf t

VCUBE-1(config)#track 1 interface GigabitEthernet1 line-protocol

VCUBE-1(config-track)#track 2 interface GigabitEthernet2 line-protocol

VCUBE-1(config-track)#exit

VCUBE-2#conf t

VCUBE-2(config)#track 1 interface GigabitEthernet1 line-protocol

VCUBE-2(config-track)#track 2 interface GigabitEthernet2 line-protocol

VCUBE-2(config-track)#exit

トラッキング CLI は、トラフィック インターフェイスがダウンした後、アクティブ ルートがアクティブな役割を果たすように、RG 内で音声トラフィックインターフェイスの状態を追跡するために使用されます。

2

アプリケーション冗長性サブモード下の VoIP HA で使用する RG を構成します。

redundancy
  application redundancy
   group 1
    name LocalGateway-HA
    priority 100 failover threshold 75
    control GigabitEthernet3 protocol 1
    data GigabitEthernet3
    timers delay 30 reload 60
    track 1 shutdown
    track 2 shutdown
    exit
   protocol 1
    timers hellotime 3 holdtime 10
   exit
  exit
 exit


VCUBE-1(config)#redundancy

VCUBE-1(config-red)#application redundancy

VCUBE-1(config-red-app)#group 1

VCUBE-1(config-red-app-grp)#name LocalGateway-HA

VCUBE-1(config-red-app-grp)#priority 100 failover threshold 75

VCUBE-1(config-red-app-grp)#control GigabitEthernet3 protocol 1

VCUBE-1(config-red-app-grp)#data GigabitEthernet3

VCUBE-1(config-red-app-grp)#timers delay 30 reload 60

VCUBE-1(config-red-app-grp)#track 1 shutdown

VCUBE-1(config-red-app-grp)#track 2 shutdown

VCUBE-1(config-red-app-grp)#exit

VCUBE-1(config-red-app)#protocol 1

VCUBE-1(config-red-app-prtcl)#timers hellotime 3 holdtime 10

VCUBE-1(config-red-app-prtcl)#exit

VCUBE-1(config-red-app)#exit

VCUBE-1(config-red)#exit

VCUBE-1(config)#

VCUBE-2(config)#redundancy

VCUBE-2(config-red)#application redundancy

VCUBE-2(config-red-app)#group 1

VCUBE-2(config-red-app-grp)#name LocalGateway-HA

VCUBE-2(config-red-app-grp)#priority 100 failover threshold 75

VCUBE-2(config-red-app-grp)#control GigabitEthernet3 protocol 1

VCUBE-1(config-red-app-grp)#data GigabitEthernet3

VCUBE-2(config-red-app-grp)#timers delay 30 reload 60

VCUBE-2(config-red-app-grp)#track 1 shutdown

VCUBE-2(config-red-app-grp)#track 2 shutdown

VCUBE-2(config-red-app-grp)#exit

VCUBE-2(config-red-app)#protocol 1

VCUBE-2(config-red-app-prtcl)#timers hellotime 3 holdtime 10

VCUBE-2(config-red-app-prtcl)#exit

VCUBE-2(config-red-app)#exit

VCUBE-2(config-red)#exit

VCUBE-2(config)#

この構成で使用されるフィールドの説明を次に示します。

  • 冗長性: 冗長モードに入る

  • アプリケーション冗長性: アプリケーション冗長設定モードに入ります

  • group—冗長性アプリケーション グループ設定モードに入ります

  • name LocalGateway-HA—RG グループの名前を定義します。

  • 優先度 100 フェールオーバーしきい値 75: RG の初期優先順位とフェールオーバーしきい値を指定します。

  • タイマー遅延 30 reload 60: 遅延と再読み込みに対して 2 回設定します。

    • インターフェイスが起動した後、RG グループの初期設定と役割のネゴシエーションの遅延時間を示す遅延タイマーです。デフォルトは 30 秒です。範囲は 0-10000 秒です

    • Reload—これは、リロード後の RG グループ初期設定と役割ネゴシエーションの遅延時間です。デフォルトは 60 秒です。範囲は 0-10000 秒です

    • デフォルトのタイマーが推奨されていますが、これらのタイマーは、ネットワークのルーティングが安定した時点の後、RG プロトコルのネゴシエーションが行われることを保証するために、ルーターの起動/再読み込み中に発生する可能性がある追加のネットワーク集約遅延に合わせて調整される場合があります。たとえば、フェールオーバー後に、新しいスタンバイに最大 20 秒間かかり、新しいアクティブから最初の RG HELLO パケットを確認する場合は、この遅延を考慮して、最初の RG HELLO パケットを「タイマー遅延 60 リロード 120」に調整する必要があります。

  • control GigabitEthernet3 protocol 1—2 つの CUBE 間でキープアライブとハローメッセージを交換するために使用されるインターフェイスを構成し、コントロール インターフェイスに接続されるプロトコル インスタンスを指定し、冗長アプリケーション プロトコル構成モードに入ります

  • data GigabitEthernet3—データ トラフィックのチェックポイントに使用されるインターフェイスを設定します

  • track - インターフェイスの RG グループ トラッキング

  • プロトコル 1—コントロール インターフェイスに接続されるプロトコル インスタンスを指定し、冗長性アプリケーション プロトコル設定モードに入ります。

  • タイマー hellotime 3 holdtime 10: hellotime と holdtime の 2 つのタイマーを設定します。

    • Hellotime— 連続する hello メッセージの間隔 (デフォルトで 3 秒)。範囲は 250 ミリ秒から 254 秒です

    • Holdtime — Hello メッセージの受信と送信ルーターが失敗した推定の間隔。この継続時間は、hello time (デフォルトの 10 秒より長くする必要があります) 以上である必要があります。範囲は 750 ミリ秒から 255 秒です

      Holdtime タイマーを hellotime タイマーの最低 3 倍の値に設定することをお勧めします。

3

CUBE アプリケーションのボックス間の冗長性を有効にします。voice service voip の下にある前のステップから RG を構成します。これにより、CUBE アプリケーションは冗長性プロセスをコントロールすることができます。

voice service voip
   redundancy-group 1
   exit

VCUBE-1(config)#voice service voip

VCUBE-1(config-voi-serv)#redundancy-group 1


                        % Created RG 1 association with Voice B2B HA; reload the router for the new configuration to take effect
                      

VCUBE-1(config-voi-serv)# exit

VCUBE-2(config)#voice service voip

VCUBE-2(config-voi-serv)#redundancy-group 1


                        % Created RG 1 association with Voice B2B HA; reload the router for the new configuration to take effect
                      

VCUBE-2(config-voi-serv)# exit

redundancy-group 1: このコマンドを追加および削除するには、更新された構成を有効にするために再読み込みが必要です。すべての構成が適用された後で、プラットフォームを再読み込みします。

4

以下に示すように、Gig1 と Gig2 インターフェイスをそれぞれの仮想 IP で構成し、冗長性インターフェイス識別子 (rii) を適用します。

VCUBE-1(config)#interface GigabitEthernet1

VCUBE-1(config-if)# redundancy rii 1

VCUBE-1(config-if)# redundancy group 1 ip 198.18.1.228 exclusive

VCUBE-1(config-if)# exit

VCUBE-1(config)#

VCUBE-1(config)#interface GigabitEthernet2

VCUBE-1(config-if)# redundancy rii 2

VCUBE-1(config-if)# redundancy group 1 ip 198.18.133.228 exclusive

VCUBE-1(config-if)# exit

VCUBE-2(config)#interface GigabitEthernet1

VCUBE-2(config-if)# redundancy rii 1

VCUBE-2(config-if)# redundancy group 1 ip 198.18.1.228 exclusive

VCUBE-2(config-if)# exit

VCUBE-2(config)#

VCUBE-2(config)#interface GigabitEthernet2

VCUBE-2(config-if)# redundancy rii 2

VCUBE-2(config-if)# redundancy group 1 ip 198.18.133.228 exclusive

VCUBE-v(config-if)# exit

この構成で使用されるフィールドの説明を次に示します。

  • redundancy rii: 冗長グループの冗長インターフェイス ID を設定します。仮想 MAC (VMAC) アドレスを生成するために必要です。同じ VIP を持つ各ルーター (アクティブ/スタンバイ) のインターフェイスで同じ rii ID 値を使用する必要があります。

    同じ LAN に複数の B2B ペアがある場合、各ペアはそれぞれのインターフェイスに固有の RII ID を持っている必要があります（衝突を防ぐため）。「冗長性アプリケーショングループをすべて表示」は、正しいローカルおよびピア情報を示す必要があります。

  • 冗長グループ 1: 上記のステップ 2 で作成された冗長グループとインターフェイスを関連付けます。RG グループ、およびこの物理インターフェイスに割り当てられた VIP を構成します。

    冗長性のために別のインターフェイスを使用することが必須です。つまり、音声トラフィックに使用されるインターフェイスは、上記の手順 2 で指定したコントロールとデータ インターフェイスとして使用できません。この例では、RG コントロール/データにギガビット インターフェイス 3 が使用されています。

5

最初の CUBE 構成を保存し、再読み込みします。

最後にリロードするプラットフォームは常にスタンバイです。

VCUBE-1#wr


                        Building configuration...
                      


                        [OK]
                      

VCUBE-1#reload


                        Proceed with reload? [confirm]

VCUBE-1 が完全に起動したら、 VCUBE-2 の構成を保存し、再読み込みします。

VCUBE-2#wr


                        Building configuration...
                      


                        [OK]
                      

VCUBE-2#reload


                        Proceed with reload? [confirm]

6

ボックス間の構成が期待どおりに機能していることを確認します。関連する出力は太字で強調表示されます。

VCUBE-2 を最後にリロードし、設計上の考慮事項に従います。最後にリロードするプラットフォームは常に [スタンバイ] 状態です。 


VCUBE-1#show redundancy application group all
Faults states Group 1 info:
       Runtime priority: [100]
               RG Faults RG State: Up.
                       Total # of switchovers due to faults:           0
                       Total # of down/up state changes due to faults: 0
Group ID:1
Group Name:LocalGateway-HA
  
Administrative State: No Shutdown
Aggregate operational state: Up
My Role: ACTIVE
Peer Role: STANDBY
Peer Presence: Yes
Peer Comm: Yes
Peer Progression Started: Yes

RF Domain: btob-one
         RF state: ACTIVE
         Peer RF state: STANDBY HOT

RG Protocol RG 1
------------------
        Role: Active
        Negotiation: Enabled
        Priority: 100
        Protocol state: Active
        Ctrl Intf(s) state: Up
        Active Peer: Local
        Standby Peer: address 10.1.1.2, priority 100, intf Gi3
        Log counters:
                role change to active: 1
                role change to standby: 1
                disable events: rg down state 0, rg shut 0
                ctrl intf events: up 1, down 0, admin_down 0
                reload events: local request 0, peer request 0

RG Media Context for RG 1
--------------------------
        Ctx State: Active
        Protocol ID: 1
        Media type: Default
        Control Interface: GigabitEthernet3
        Current Hello timer: 3000
        Configured Hello timer: 3000, Hold timer: 10000
        Peer Hello timer: 3000, Peer Hold timer: 10000
        Stats:
            Pkts 1509, Bytes 93558, HA Seq 0, Seq Number 1509, Pkt Loss 0
            Authentication not configured
            Authentication Failure: 0
            Reload Peer: TX 0, RX 0
            Resign: TX 0, RX 0
    Standy Peer: Present. Hold Timer: 10000
            Pkts 61, Bytes 2074, HA Seq 0, Seq Number 69, Pkt Loss 0

VCUBE-1#

VCUBE-2#show redundancy application group all
Faults states Group 1 info:
       Runtime priority: [100]
               RG Faults RG State: Up.
                       Total # of switchovers due to faults:           0
                       Total # of down/up state changes due to faults: 0
Group ID:1
Group Name:LocalGateway-HA
  
Administrative State: No Shutdown
Aggregate operational state: Up
My Role: STANDBY
Peer Role: ACTIVE
Peer Presence: Yes
Peer Comm: Yes
Peer Progression Started: Yes

RF Domain: btob-one
         RF state: ACTIVE
         Peer RF state: STANDBY HOT

RG Protocol RG 1
------------------
        Role: Active
        Negotiation: Enabled
        Priority: 100
        Protocol state: Active
        Ctrl Intf(s) state: Up
        Active Peer: address 10.1.1.2, priority 100, intf Gi3
        Standby Peer: Local
        Log counters:
                role change to active: 1
                role change to standby: 1
                disable events: rg down state 0, rg shut 0
                ctrl intf events: up 1, down 0, admin_down 0
                reload events: local request 0, peer request 0

RG Media Context for RG 1
--------------------------
        Ctx State: Active
        Protocol ID: 1
        Media type: Default
        Control Interface: GigabitEthernet3
        Current Hello timer: 3000
        Configured Hello timer: 3000, Hold timer: 10000
        Peer Hello timer: 3000, Peer Hold timer: 10000
        Stats:
            Pkts 1509, Bytes 93558, HA Seq 0, Seq Number 1509, Pkt Loss 0
            Authentication not configured
            Authentication Failure: 0
            Reload Peer: TX 0, RX 0
            Resign: TX 0, RX 0
    Standy Peer: Present. Hold Timer: 10000
            Pkts 61, Bytes 2074, HA Seq 0, Seq Number 69, Pkt Loss 0

VCUBE-2#

両方の CUBE でローカル ゲートウェイを構成する

この例の構成では、Control Hub から以下のトランク情報を使用して、VCUBE-1、VCUBE-2 の両方のプラットフォームでローカルゲートウェイを構成しています。この設定のユーザー名とパスワードは以下のとおりです。

  • ユーザー名:フセイン1076_LGU

  • パスワード:lOV12MEaZx

1

クレデンシャルまたは共有秘密で使用する前に、以下のコマンドを使用して、設定キーがパスワードに対して作成されていることを確認してください。Type 6 パスワードは、AES 暗号化とこのユーザー定義の設定キーを使用して暗号化されます。 


LocalGateway#conf t
LocalGateway(config)#key config-key password-encrypt Password123
LocalGateway(config)#password encryption aes

これは、上に表示された Webex Control Hub パラメータに基づいて両方のプラットフォームに適用されるローカル ゲートウェイの構成です。保存と再読み込みを行います。Webex Control Hub からの SIP ダイジェスト資格情報は、太字でハイライトされます。


configure terminal
crypto pki trustpoint dummyTp
revocation-check crl
exit
sip-ua
crypto signaling default trustpoint dummyTp cn-san-validate server
transport tcp tls v1.2
end


configure terminal
crypto pki trustpool import clean url
http://www.cisco.com/security/pki/trs/ios_core.p7b
end


configure terminal
voice service voip
  ip address trusted list
    ipv4 x.x.x.x y.y.y.y
    exit
   allow-connections sip to sip
  media statistics
  media bulk-stats
  no supplementary-service sip refer
  no supplementary-service sip handle-replaces
  fax protocol pass-through g711ulaw
  stun
    stun flowdata agent-id 1 boot-count 4
    stun flowdata shared-secret 0 Password123!
  sip
    g729 annexb-all
    early-offer forced
    end


configure terminal
voice class sip-profiles 200
  rule 9 request ANY sip-header SIP-Req-URI modify "sips:(.*)"
"sip:\1"
  rule 10 request ANY sip-header To modify ""
""
  rule 13 response ANY sip-header To modify ""
";otg=hussain1076_lgu>"
  rule 30 request ANY sip-header P-Asserted-Identity modify
"sips:(.*)" "sip:\1"


voice class codec 99
  codec preference 1 g711ulaw
  codec preference 2 g711ulaw
  exit

voice class srtp-crypto 200
  crypto 1 AES_CM_128_HMAC_SHA1_80
  exit

voice class stun-usage 200
  stun usage firewall-traversal flowdata
  exit






voice class tenant 200
  registrar dns:40462196.cisco-bcld.com scheme sips expires 240
refresh-ratio 50 tcp tls
  credentials number Hussain5091_LGU username Hussain1076_LGU
password 0 lOV12MEaZx realm Broadworks 
  authentication username Hussain5091_LGU password 0 lOV12MEaZx
realm BroadWorks

  authentication username Hussain5091_LGU password 0 lOV12MEaZx
realm 40462196.cisco-bcld.com
  no remote-party-id
  sip-server dns:40462196.cisco-bcld.com
  connection-reuse
  srtp-crypto 200
  session transport tcp tls
  url sips
  error-passthru
  asserted-id pai
  bind control source-interface GigabitEthernet1
  bind media source-interface GigabitEthernet1
  no pass-thru content custom-sdp
  sip-profiles 200
  outbound-proxy dns:la01.sipconnect-us10.cisco-bcld.com
  privacy-policy passthru


voice class tenant 100
  session transport udp
  url sip
  error-passthru
  bind control source-interface GigabitEthernet2
  bind media source-interface GigabitEthernet2
  no pass-thru content custom-sdp

voice class tenant 300
  bind control source-interface GigabitEthernet2
  bind media source-interface GigabitEthernet2
  no pass-thru content custom-sdp
  

voice class uri 100 sip
 host ipv4:198.18.133.3

voice class uri 200 sip
 pattern dtg=hussain1076.lgu



dial-peer voice 101 voip
 description Outgoing dial-peer to IP PSTN
 destination-pattern BAD.BAD
 session protocol sipv2
 session target ipv4:198.18.133.3
 voice-class codec 99
 voice-class sip tenant 100
 dtmf-relay rtp-nte
 no vad

dial-peer voice 201 voip
 description Outgoing dial-peer to Webex Calling
 destination-pattern BAD.BAD
 session protocol sipv2
 session target sip-server
 voice-class codec 99
 voice-class stun-usage 200
 no voice-class sip localhost
 voice-class sip tenant 200
 dtmf-relay rtp-nte
 srtp
 no vad


voice class dpg 100
 description Incoming WebexCalling(DP200) to IP PSTN(DP101)
 dial-peer 101 preference 1

voice class dpg 200
 description Incoming IP PSTN(DP100) to Webex Calling(DP201)
 dial-peer 201 preference 1





dial-peer voice 100 voip
 desription Incoming dial-peer from IP PSTN
 session protocol sipv2
 destination dpg 200
 incoming uri via 100
 voice-class codec 99
 voice-class sip tenant 300
 dtmf-relay rtp-nte
 no vad

dial-peer voice 200 voip
 description Incoming dial-peer from Webex Calling
 session protocol sipv2
 destination dpg 100
 incoming uri request 200
 voice-class codec 99
 voice-class stun-usage 200
 voice-class sip tenant 200
 dtmf-relay rtp-nte
 srtp
 no vad

end

copy run start

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-1#show redundancy application group 1
Group ID:1
Group Name:LocalGateway-HA

Administrative State: No Shutdown
Aggregate operational state : Up
My Role: Standby
Peer Role: ACTIVE
Peer Presence: Yes
Peer Comm: Yes
Peer Progression Started: Yes

RF Domain: btob-one
         RF state: STANDBY HOT
         Peer RF state: ACTIVE

VCUBE-1#show sip-ua register status
VCUBE-1#


VCUBE-2#show redundancy application group 1
Group ID:1
Group Name:LocalGateway-HA

Administrative State: No Shutdown
Aggregate operational state : Up
My Role: ACTIVE
Peer Role: STATUS
Peer Presence: Yes
Peer Comm: Yes
Peer Progression Started: Yes

RF Domain: btob-one
         RF state: ACTIVE
         Peer RF state: STANDBY HOT

VCUBE-2#show sip-ua register status

Tenant: 200
--------------------Registrar-Index  1 ---------------------
Line                           peer       expires(sec) reg survival P-Associ-URI
============================== ========== ============ === ======== ============
Hussain5091_LGU                -1          48          yes normal
VCUBE-2#

上記の出力から、VCUBE-2 は Webex Calling アクセス SBC への登録を維持するアクティブ LGW であり、「show sip-ua 登録ステータス」の出力は VCUBE-1 では空白です。

3

VCUBE-1 で次のデバッグを有効にします


VCUBE-1#debug ccsip non-call
SIP Out-of-Dialog tracing is enabled
VCUBE-1#debug ccsip info
SIP Call info tracing is enabled
VCUBE-1#debug ccsip message

4

この場合、アクティブ LGW、VCUBE-2 で次のコマンドを実行してフェールオーバーをシミュレートします。


VCUBE-2#redundancy application reload group 1 self

アクティブからスタンバイ LGW への切り替えは、上記に一覧表示されている CLI に加えて、以下のシナリオで発生します。

  • アクティブ ルーターのリロード時

  • アクティブなルーターの電源が再投入される時

  • トラッキングが有効になっているアクティブなルーターの RG 構成されたインターフェイスがシャットダウンされる時

5

VCUBE-1 が Webex Calling アクセス SBC に登録されているかどうかを確認します。VCUBE-2 は今すぐにリロードされます。


              VCUBE-1#show sip-ua register status

Tenant: 200
--------------------Registrar-Index  1 ---------------------
Line                           peer       expires(sec) reg survival P-Associ-URI
============================== ========== ============ === ======== ============
Hussain5091_LGU                -1          56          yes normal
VCUBE-1#

VCUBE-1 がアクティブ LGW になりました。

6

仮想 IP を通じて SIP REGISTER を Webex Calling に送信し、200 OK を受信する VCUBE-1 に関連するデバッグ ログを確認してください。


VCUBE-1#show log

Jan 9 18:37:24.769: %RG_MEDIA-3-TIMEREXPIRED: RG id 1 Hello Time Expired.
Jan 9 18:37:24.771: %RG_PROTCOL-5-ROLECHANGE: RG id 1 role change from Standby to Active
Jan 9 18:37:24.783: %VOICE_HA-2-SWITCHOVER_IND: SWITCHOVER, from STANDBY_HOT to ACTIVE state.
Jan 9 18:37:24.783: //-1/xxxxxxxxxxxx/SIP/Info/info/4096/sip_ha_notify_active_role_event: Received notify active role event

Jan 9 18:37:25.758: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
REGISTER sip: 40462196.cisco-bcld.com:5061 SIP/2.0
Via: SIP/2.0/TLS 198.18.1.228:5061;branch=z9hG4bK0374
From: ;tag=8D573-189
To: 
Date: Thu, 09 Jan 2020 18:37:24 GMT
Call-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97
User-Agent: Cisco-SIPGateway/IOS-16.12.02
Max-Forwards: 70
Timestamp: 1578595044
CSeq: 2 REGISTER
Contact: 
Expires: 240
Supported: path
Content-Length: 0


Jan 9 18:37:25.995: //-1/000000000000/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 401 Unauthorized
Via: SIP/2.0/TLS 198.18.1.228:5061;received=173.38.218.1;branch=z9hG4bK0374;rport=4742
From: ;tag=8D573-189
To: ;tag=SD1u8bd99-1324701502-1578595045969
Date: Thu, 09 Jan 2020 18:37:24 GMT
Call-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97
Timestamp: 1578595044
CSeq: 2 REGISTER
WWW-Authenticate; DIGEST realm="BroadWorks",qop="auth",nonce="BroadWorksXk572qd01Ti58zliBW",algorithm=MD5
Content-Length: 0


Jan 9 18:37:26.000: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
REGISTER sip:40462196.cisco-bcld.com:5061 SIP/2.0
Via: SIP/2.0/TLS 198.18.1.228:5061;branch=z9hG4bK16DC
From: ;tag=8D573-189
To: 
Date: Thu, 09 Jan 2020 18:37:25 GMT
Call-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97
User-Agent:Cisco-SIPGateway/IOS-16.12.02
Max-Forwards: 70
Timestamp: 1578595045
CSeq: 3 REGISTER
Contact: 
Expires: 240
Supported: path
Authorization: Digest username="Hussain1076_LGU",realm="BroadWorks",uri="sips:40462196.cisco-bcld.com:5061",response="b6145274056437b9c07f7ecc08ebdb02",nonce="BroadWorksXk572qd01Ti58z1iBW",cnonce="3E0E2C4D",qop=auth,algorithm=MD5,nc=00000001
Content-Length: 0


Jan 9 18:37:26.190: //1/000000000000/SIP/Msg/ccsipDisplayMsg:

Received:
SIP/2.0 200 OK
Via: SIP/2.0/TLS 198.18.1.228:5061;received=173.38.218.1;branch=z9hG4bK16DC;rport=4742
From: ;tag=8D573-189
To: ;tag=SD1u8bd99-1897486570-1578595-46184
Call-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97
Timestamp: 1578595045
CSeq: 3 REGISTER
Contact: ;expires=120;q=0.5
Allow-Events: call-info,line-seize,dialog,message-summary,as-feature-event,x-broadworks-hoteling,x-broadworks-call-center-status,conference
Content-Length: 0

組織の を設定する

初回セットアップ ウィザードで通話設定をセットアップする

サービスを稼働させるための最初のステップは、初回セットアップウィザード（FTSW）を完了することです。最初のロケーションの FTSW が完了した後では、追加のロケーションに対して完了する必要がありません。

1

受け取ったウェルカム メールのはじめにリンクをクリックします。

管理者のメールアドレスが、自動的に、 にサインインするためのメールアドレスとして使用されます。サインインすると、管理者パスワードを作成するように求められます。サインインすると、セットアップ ウィザードが自動的に開始します。

2

利用規約を見直して、承諾します。

3

プランを見直して、[はじめに] をクリックします。

アカウント マネージャは FTSW の最初の手順をアクティブにする責任があります。[使い始める] を選択した時に、「通話をセットアップできません」という通知を受け取った場合は、アカウント マネージャーに連絡してください。

4

データ センターがマッピングする国を選択し、顧客の連絡先と顧客アドレス情報を入力します。

5

[次へ: デフォルトのロケーション

6

次のオプションから選択します:

  • パートナー管理者であり、顧客管理者にプロビジョニングを完了させる場合は、[保存して閉じる] をクリックします。
  • 必要なロケーションの情報を入力します。ウィザードでロケーションを作成した後、後で他にロケーションを作成できます。

セットアップ ウィザードを完了した後で、作成したロケーションにメイン番号を追加していることを確認してください。

7

このロケーションに適用する次の選択を行います。

  • アナウンス言語: 新規ユーザーと機能に関する音声アナウンスとプロンプト用。
  • メール言語—新規ユーザー向けのメール通信用。
  • 国
  • タイムゾーン
8

[次へ] をクリックします。

9

利用可能な Cisco Webex SIP アドレスを入力し、[次へ] をクリックし、[完了] を選択します。

ロケーションを追加する

始める前に

新しいロケーションを作成するには、以下の情報を指定します。

  • ロケーションの住所

  • 希望する電話番号(オプション)

1

https://admin.webex.com で Control Hub にログインし、[管理] > [ロケーション] に移動します。

新しいロケーションは、初回セットアップ ウィザードを使用して選択した国に対応する地域のデータ センターでホストされます。

2

ロケーションを設定します。

  • ロケーション名—ロケーションを識別する一意の名前を入力します。
  • 国/地域: ロケーションをリンクする国を選択します。たとえば、米国に 1 か所のロケーション (本社) を作成し、イギリスに別のロケーション (支社) を作成することができます。選択した国に応じて、その後の住所のフィールドが決まります。ここには、例として、米国の住所書式を使用したものがあります。
  • ロケーション アドレス—ロケーションのメーリングアドレスを入力します。
  • 市区町村—このロケーションの市区町村を入力します。
  • 州/県/地域—ドロップダウンから都道府県を選択します。
  • ZIP/郵便番号—郵便番号を入力します。
  • アナウンス言語: 新規ユーザーと機能に関する音声アナウンスやプロンプトの言語を選択します。
  • メール言語—新規ユーザーとのメール通信に使用する言語を選択します。
  • タイムゾーン—ロケーションのタイムゾーンを選択します。
3

[保存 ] をクリックしてから、[ はい/いいえ ] を選択して、現在または後でロケーションに番号を追加します。

4

[はい] をクリック した場合、次のいずれかのオプションを選択します。

  • Cisco PSTN—Cisco から Cloud PSTN ソリューションが必要な場合は、このオプションを選択します。Cisco 通話プランは、緊急通話、着信、および国内および国際通話を提供する PSTN 代替ソリューションであり、新しい PSTN 番号または既存の番号を Cisco にポートすることができます。

    Cisco PSTN オプションは、以下の条件でのみ表示されます。

    • コミットされた Cisco Calling プラン OCP (アウトバウンド通話プラン) を少なくとも 1 つ購入している。

    • Cisco Calling プランがサポートされている国にロケーションがある。

    • ロケーションが新規である。他の PSTN 機能が割り当てられている既存のロケーションは、今回は Cisco Calling プランの対象外です。サポートケースを登録 してガイダンスを受けてください。

    • Cisco Calling プランがサポートされている地域の Webex Calling データ センターでホストされています。

  • Cloud Connected PSTN—多くの Cisco CCP パートナーの 1 つからクラウド PSTN ソリューションを探している場合、またはロケーションで Cisco Calling プランが利用できない場合は、このオプションを選択します。CCP パートナーは、PSTN 代替ソリューション、グローバルな広域カバレッジ、広範でさまざまな機能、パッケージ、価格設定を提供しています。

    CCP パートナーと対応地域は、こちらにリストされています。ロケーションの国がサポートされているパートナーにのみ表示されています。パートナーは、ロゴで表示されるか、簡単な文字列と括弧で囲んだ地域名で表示されます (例: (EU)、(US)、または (CA))。ロゴが表示されているパートナーは、常に CCP の地域メディアを提供しています。文字列で表示されているパートナーについては、CCP の地域メディアを確保するために、ロケーションの国に最も近い地域を選択してください。

    リストされているプロバイダーの下に [番号を今すぐ注文する] オプションがある場合は、そのオプションを選択して、統合された CCP のメリットを利用することをおすすめします。統合型 CCP を使用すると、電話番号のプロビジョニングとプロビジョニングを 1 つのペインで実行できます。非統合型 CCP では、CCP パートナーから電話番号を取得する必要があります。

  • プレミスベースの PSTN (ローカル ゲートウェイ): 現在の PSTN プロバイダーを保持する場合、またはクラウド サイトで非クラウド サイトに接続する場合に、このオプションを選択できます。

PSTN オプションの選択は各ロケーション レベルで行います (各ロケーションには PSTN オプションが 1 つしかありません)。展開に対して必要な数のオプションを組み合わせることができますが、各ロケーションには 1 つのオプションとなります。PSTN オプションを選択してプロビジョニングしたら、ロケーションの PSTN プロパティで [管理] をクリックすると、オプションを変更できます。ただし、Cisco PSTN などの一部のオプションは、別のオプションが割り当てられた後は使用できない場合があります。サポートケースを登録 してガイダンスを受けてください。

5

番号を今すぐに有効にするか、または後で有効にするかを選択します。

6

統合されていない CCP またはプレミス ベースの PSTN を選択した場合は、電話番号をコンマ区切り値として入力し、[検証] をクリックします。

特定のロケーションのための番号が追加されます。有効なエントリは [検証済みの番号] フィールドに移動し、無効なエントリは [番号の追加] フィールドに残り、エラー メッセージが表示されます。

番号の書式は、ロケーションの所在する国に応じ、ダイヤリングに関する地元の要件に従って定められます。たとえば、国コードが必要な場合には、コードを付けて入力することも、コードなしで入力してからコードが自動的に先頭に追加されるようにすることもできます。

7

[保存] をクリックします。

次に行うこと

ロケーションを作成した後、そのロケーションの緊急 911 サービスを有効にすることができます。詳細については「Webex Calling の RedSky 緊急 911 サービス」を参照してください。

ロケーションを削除

開始する前に

関連付けられているユーザーとワークスペースを削除すると、使用されていない場所または正しく設定されていない場所を削除できます。ロケーションを削除すると、割り当てられたサービスと番号がすべて削除されます。

ロケーションに関連付けられているユーザーとワークスペースのリストを取得します。[サービス] > [Calling] > [番号] に進み、ドロップダウン メニューから削除するロケーションを選択します。ロケーションを削除する前に、これらのユーザーとワークスペースを削除する必要があります。

このロケーションに関連付けられている番号は、PSTN プロバイダーに解放されることに注意してください。これらの番号は所有されなくなります。

1

https://admin.webex.com で Control Hub にログインし、[管理] > [ロケーション] に移動します。

2

削除するロケーションの隣の [その他のオプション] ボタン [アクション] 列で をクリックします。

3

[場所 の削除] を選択し、その場所を削除します。

通常、ロケーションを完全に削除するには数分かかりますが、最大で 1 時間かかる場合があります。ステータスを確認するには、ロケーション名の隣にある [その他のオプション] ボタン をクリックして、[削除ステータス] を 選択します。

既存のロケーションを更新する

作成した後PSTNのセットアップ、名前、タイムゾーン、言語を変更できます。新しい言語は新しいユーザーとデバイスにのみ適用されることに注意してください。既存のユーザーおよびデバイスは古い言語を使用し続けます。

既存のロケーションについては、緊急時の 911 サービスを有効にすることができます。詳細については「Webex Calling の RedSky 緊急 911 サービス」を参照してください。

1

https://admin.webex.comにサインインします。

2

[管理] > [ロケーション] に移動します。

ロケーションの隣に [警告] 記号が表示される場合、そのロケーションの電話番号をまだ設定していないという意味です。その番号を設定するまで、通話の送受信が行えなんす。

3

(オプション) [PSTN 接続] の下で、すでに設定されているものに応じて、[クラウド接続 PSTN] または [プレミスベースの PSTN](ローカル ゲートウェイ) のいずれかを選択します。[管理] をクリックして設定を変更してから、[続行] を選択することにより、関連するリスクを承認します。以下のオプションのいずれかを選択して、[保存] クリックします。

  • Cisco PSTN—Cisco から Cloud PSTN ソリューションが必要な場合は、このオプションを選択します。Cisco 通話プランは、緊急通話、着信、および国内および国際通話を提供する PSTN 代替ソリューションであり、新しい PSTN 番号または既存の番号を Cisco にポートすることができます。

    Cisco PSTN オプションは、以下の条件でのみ表示されます。

    • コミットされた Cisco Calling プラン OCP (アウトバウンド通話プラン) を少なくとも 1 つ購入しました。

    • Cisco Calling プランがサポートされている国にロケーションがある。

    • Cisco Calling プランがサポートされている地域の Webex Calling データ センターでホストされています。

  • Cloud Connected PSTN—多くの Cisco CCP パートナーの 1 つからクラウド PSTN ソリューションを探している場合、またはロケーションで Cisco Calling プランが利用できない場合は、このオプションを選択します。CCP パートナーは、PSTN 代替ソリューション、グローバルな広域カバレッジ、広範でさまざまな機能、パッケージ、価格設定を提供しています。

    CCP パートナーと対応地域は、こちらにリストされています。ロケーションの国がサポートされているパートナーにのみ表示されています。パートナーは、ロゴで表示されるか、簡単な文字列と括弧で囲んだ地域名で表示されます (例(EU)、(米国)、または (CA)。ロゴが表示されているパートナーは、常に CCP の地域メディアを提供しています。文字列で表示されているパートナーについては、CCP の地域メディアを確保するために、ロケーションの国に最も近い地域を選択してください。

    リストされているプロバイダーに今すぐ番号を注文 するオプションが表示されている場合は、統合型 CCP を利用できるように、そのオプションを選択することをお勧めします。統合型 CCP を使用すると、電話番号のプロビジョニングとプロビジョニングを 1 つのペインで実行できます。非統合型 CCP では、電話番号を CCP パートナーから外部に取得する必要があります。

  • プレミスベースの 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

https://admin.webex.comにサインインします。

2

[管理] > [ロケーション] に移動します。

3

PSTN 接続を Cisco PSTN に変更するロケーションを選択します。

4

[Calling] タブに移動し、プレミスベースの PSTN または非統合型 PSTN の隣の [管理] オプションをクリックします。

5

[接続タイプ] の隣の [編集] を選択します。

6

Cisco Calling プラン カードを選択し、このロケーションのユーザーに Cisco Calling プランを割り当てるサブスクリプションを選択します。[次へ] をクリックします。

7

確認のための接続変更ページが表示されます。[次へ] をクリックして、番号のポート準備を確認します。

PSTN 接続ポート ウィザードは、番号をポートする準備ができているかどうかを確認します。

[次へ（Next）] ボタンは、リスト内のすべての番号がポート可能な場合にのみ有効になります。これらのポインタを読みます。

  • 「ポートできない番号」は非アクティブな番号を指します。このリストに番号がないことを確認してください。

  • ロケーションからポートできない番号を削除します。番号を移動または割り当て解除して、番号を削除できます。

8

[次へ] をクリックし、契約情報を入力します。

PSTN 接続ポート ウィザードの緊急サービス アドレス ページ。

これは、Cisco Calling プラン (米国) を使用するすべてのロケーションの主契約連絡先です。この連絡先への変更は、Cisco Calling プラン (米国) を使用する他のすべてのロケーションに適用されます。

9

[次へ] をクリックします。そのロケーションの契約情報を保存するための確認を求める通知が表示されます。[はい、変更します。] を選択します。

10

緊急連絡サービス アドレスを入力し、[保存] をクリックします。

PSTN 接続ポート ウィザードの緊急サービス アドレス ページ。

緊急時、現地の緊急対応チームはこのアドレスを利用して発信元を見つけます。

11

概要ページには、作成されたポートの数が表示されます。注文が 1 つしかない場合、[追加情報を提供] と呼ばれる追加手順を確認できます。複数の注文の場合、上部に注文セレクタが表示され、その間を移動できます。[次へ] をクリックし、詳細を入力してポート ウィザードを完了します。

PSTN 接続ポート ウィザードの概要ページ。

注文は、単一の PSTN 移行リクエストに対してすべての情報が提供されると同時に送信されます。デフォルトでは、すべての注文で確固たる注文コミットメントの日付が一致しています。最後にリンクされた注文が完全にポートされた後、PSTN 接続の変更が自動的に適用されます。

  • 注文の送信に失敗すると、サポート チケットが自動的に作成され、サポート チームに送信されます。

  • PSTN 接続の変更が複数の通信事業者からの複数の注文を必要とする場合、完了までに最大 10 営業日かかる場合があります。

移行の詳細は、[サービス] > [Calling] > [PSTN] > [注文] タブで利用できます。注文 ID を選択すると、サイドパネルビューで注文の詳細が表示されます。PSTN 接続変更から作成された注文では、タイプを [PSTN の変更] として確認できます。

PSTN 接続の変更をキャンセル

管理者は、ロケーションがまだ移行状態の場合、PSTN 移行をキャンセルできます。

1

https://admin.webex.comにサインインします。

2

[管理] > [ロケーション] に移動します。

3

PSTN 接続をキャンセルするロケーションを選択します。

4

[Calling] タブに移動し、[PSTN 接続変更をキャンセル] ボタンをクリックします。

5

[はい、続行 ] をクリックしてキャンセルを確認します。

ダイヤル プランの設定

アウトバウンド ダイヤル コードを使用して、展開のダイヤル プランをコントロールできます。内線の長さ、ルーティング プレフィックス、およびダイヤル設定 (内部と外部) が、ユーザーのダイヤル習慣に適合するようにカスタマイズします。

これらの設定は社内ダイヤルに適用されるものであり、最初のセットアップ ウィザードでも設定できます。ダイヤル プランを変更すると、更新中の番号がこれらの変更を表示します。

ロケーションの発信通話権限を設定できます。発信権限を設定するには、これらの手順 を参照してください。

1

Control Hub にサインインし、[サービス] > [Calling] > [サービス設定] に移動し、[内線ダイヤル] までスクロールします。

2

必要に応じて、次のオプションのダイヤル設定を行います。

  • ロケーション ルーティング プレフィックスの長さ—複数のロケーションがある場合は、この設定をお勧めします。1 ～ 7 桁の長さを入力できます。同じ内線を持つ複数のロケーションがある場合は、ロケーション間の通話時にプレフィックスをダイヤルする必要があります。たとえば、複数のストアがある場合、内線 1000 を使用すると、各ストアにルーティング プレフィックスを設定することができます。1 つのストアのプレフィックスが 888 の場合、そのストアに到達するために 8881000 にダイヤルします。

    • ルーティング プレフィックスの長には、ステアリング桁が含まれます。たとえば、ルーティング プレフィックスの長さを 4 に設定した場合、サイトを指定できるのは 3 桁のみです。

    • ルーティング プレフィックスをロケーションに割り当てると、そのロケーションに割り当てられた内線番号のすべてのアピアランスには、内線番号の前にルーティング プレフィックスが含まれます。たとえば、888-1000（ルーティング プレフィックス内線）などです。

  • ルーティング プレフィックスのステアリング桁—各ルーティング プレフィックスの最初の桁として設定する番号を選択します。
  • 内線番号の長さ—2 ～ 10 桁を入力でき、デフォルトは 2 です。

    内線の長さを増やしても、社内内線への既存のスピード ダイヤルは自動的に更新されません。

  • ロケーション間の内線ダイヤルを許可: 組織の要件に基づいて、ロケーション間の内線ダイヤルをカスタマイズできます。

    • 組織のすべてのロケーションで重複する内線番号がない場合は、トグルを有効にします。

      デフォルトでは、トグルが有効になっています。

    • 組織が異なるロケーションで同じ内線を持っている場合は、トグルを無効にします。トグルが無効になって発信者が内線番号をダイヤルすると、発信者と同じロケーションに一致する内線番号を持つユーザーにコールがルーティングされます。他のロケーションの内線番号に到達するには、発信者はエンタープライズ有意番号 (ロケーションのルーティングプレフィックス + 内線) をダイヤルする必要があります。

3

特定の場所の内部ダイヤルを指定します。[管理] > [ロケーション] に移動し、リストからロケーションを選択し、[通話] をクリックします。[ダイヤル] までスクロールし、必要に応じて内部ダイヤルを変更します。

  • 内線ダイヤル: あるロケーションのユーザーが別のロケーションの誰かに連絡するためにダイヤルする必要があるルーティング プレフィックスを指定します。各ロケーションのルーティング プレフィックスは固有である必要があります。プレフィックスの長さは組織レベルで設定された長さと一致することを推奨しますが、1 ～ 7 桁の長さである必要があります。
4

特定のロケーションの外線ダイヤルを指定します。[管理] > [ロケーション] に移動し、リストからロケーションを選択し、[通話] をクリックします。[ダイヤル] までスクロールし、必要に応じて外部ダイヤルを変更します。

  • 外線ダイヤル: ユーザーが外線に接続するためにダイヤルする必要がある発信ダイヤル番号を選択できます。デフォルトは [なし] であり、このダイヤル習慣が必要ない場合には、値を [なし] にしておくことができます。この機能を使用しない場合、組織のステアリング番号とは別の番号を使用することをお勧めします。

    ユーザーは、外線発信を行う際に外線発信番号を含め、レガシー システムでダイヤルしていた方法を真似たものにできます。しかし、すべてのユーザーは、発信ダイアル番号なしで外部通話を発信することができます。

  • オプションで、このロケーションの発信ダイヤル番号を強制する ことができます。これにより、ユーザーが外部コールを発信するために管理者が設定した発信ダイヤル番号を使用する必要があります。

    • この機能を有効にすると、発信ダイヤル番号の有無にかかわらず緊急コールをダイヤルできます。有効にすると、外線発信番号が含まれない外線番号 (通話転送に使用される番号など) が機能しなくなります。

    • 内線が国番号と同じ場合、内線が国番号よりも優先されます。したがって、発信ダイヤル番号を有効にすることを推奨します。

    • 着信および発信 PSTN 通話に E.164 番号形式を使用することを強くおすすめします。

ユーザーへの影響:

  • ダイヤル設定の変更を有効にするには、ユーザが電話を再起動する必要があります。

  • ユーザーの内線番号は、ロケーションのステアリング番号または発信ダイヤル番号と同じ番号で開始することはできません。

プレミスベースの PSTN (ローカル ゲートウェイ) を設定する

付加価値再販業者の場合は、次の手順を使用して、ローカル ゲートウェイの設定を開始できます。このゲートウェイがクラウドに登録されている場合、1 つ以上のロケーションで使用して、エンタープライズ PSTN サービス プロバイダーへのルーティングを提供できます。

ローカル ゲートウェイがある場所は、ローカル ゲートウェイが他の場所で使用されているときには削除できません。

トランクを作成する

でトランクを作成するには、次の手順に従ってください。

始める前に

  • ロケーションが追加されたら、ロケーションに対してプレミスベース PSTN を設定する前に、トランクを作成する必要があります。

  • それぞれについて、ロケーションと固有の設定および番号を作成します。ロケーションはプレミスベース PSTN を追加する前に存在する必要があります。

  • のプレミスベースの PSTN (ローカル ゲートウェイ) 要件を理解してください。

  • プレミスベース PSTN を持つロケーションに対して、複数のトランクを選択できませんが、複数のロケーションに対して同じトランクを選択することはできます。

1

にログインし、[サービス] > [Calling] > [コール ルーティング] に進み、[トランクの追加] を選択します。

2

ロケーションを選択します。

3

トランクの名前を指定し、[保存] をクリックします。

名前は 24 文字以内にしてください。

次にやる必要

トランクで設定する必要がある、関連するパラメーターが表示されます。また、PSTN 接続をセキュアにするための SIP ダイジェスト資格情報のセットも生成します。

画面 [ドメインの登録]、[トランク グループ OTG/DTG]、[回線/ポート]、および [発信プロキシ アドレス] にトランク情報が表示されます。

プレミスベースの PSTN を構成する準備ができたら参照できるように、この情報をコピーしてローカルのテキスト ファイルまたはドキュメントに貼り付けることをおすすめします。

クレデンシャルを紛失した場合は、 のトランク情報画面からクレデンシャルを生成する必要があります。[ユーザー名の取得とパスワードのリセット] をクリックして、トランクを使用するための認証資格情報の新しいセットを生成します。

プレミス ベースの PSTN のトランクを選択する

1

https://admin.webex.com で Control Hub にログインし、[管理] > [ロケーション] に移動します。

2

変更する場所を選択し、[管理] をクリックします。

3

プレミスベース PSTN を選択して、[次へ] をクリックします。

4

ドロップダウン メニューからトランクを選択します。

トランク ページにアクセスして、トランク グループの選択を管理します。

5

確認通知をクリックし、[保存] をクリックします。

次にやる必要

が生成した構成情報を記録し、パラメーターをローカル ゲートウェイ (たとえばオンプレミスの Cisco CUBE) にマップする必要があります。この記事 では、このプロセスを説明します。参考のため、どのように の構成情報 (左側) が CUBE のパラメーター (右側) にマップされるかを示す例である次の図を参照してください。

ローカル ゲートウェイの例図。

ゲートウェイ自体の設定が正常に完了すると、[サービス] > [通話] > [ロケーション] に戻り、作成したゲートウェイが割り当てたロケーション カードに名前の左側に緑色のドットが付きます。このステータスは、ゲートウェイがセキュアに通話クラウドに対して登録され、そのロケーションでのアクティブな PSTN としての役割を果たしていることを示しています。

電話番号の管理

で組織の電話番号を簡単に表示、アクティベート、削除、追加できます。詳細については、「Control Hub で電話番号を管理する」を参照してください。

トライアルからのサービスの購入をリクエストする

Webex サービスを試していて、トライアルから有料サブスクリプションに変更したい場合は、メールでパートナーにリクエストできます。

1

にログインし、建物のアイコン 建物のアイコン。 を選択します。

2

[サブスクリプション] タブを選択し、[今すぐ購入] をクリックします。

有料サブスクリプションへの変換に興味を持っていることを知らせるメールがパートナーに送信されます。

通話オプションを設定

Control Hub を使用して、Webex アプリでユーザーに表示する利用可能な通話オプションの優先度を設定できます。シングルクリック通話を有効にすることもできます。詳細については、次を参照してください。Webex アプリ ユーザーの通話オプションを設定する。

発信動作を設定する

ユーザーが発信するときに、どの通話アプリケーションが開くかを制御できます。Unified CM で認証されたユーザーがいる組織や、Cisco からの有料通話サービスを利用していないユーザー向けの混合モード展開など、コーリング クライアントの設定を構成できます。詳細については、次を参照してください。通話動作を設定する。

Unified CM の構成

ローカル ゲートウェイへトランクするための SIP トランク セキュリティ プロファイルを構成する

ローカル ゲートウェイと PSTN ゲートウェイが同じデバイス上に存在する場合、Unified CM を有効にして、同じデバイスから発信された 2 個の異なるトラフィックの種類 (Webex と PSTN のコール) を区別し、これらのコール タイプに対して差別化されたクラスのサービスを適用する必要があります。この差別化されたコール処理は、Unified CM および結合されたローカル ゲートウェイと PSTN ゲートウェイ デバイスの 2 つのトランクをプロビジョニングすることで行われます。これは、2 つのトランクに異なる SIP リスニング ポートを必要とします。

次の設定でローカル ゲートウェイ トランクの専用の SIP トランク セキュリティ プロファイルを作成します。

設定値
名前固有の名前 (Webex など)
説明Webex SIP トランク セキュリティ プロファイルなどの意味のある説明
着信ポートWebex 間のトラフィックでは、ローカル ゲートウェイ構成で使用されるポートと一致する必要があります。5065

ローカル ゲートウェイ トランクの SIP プロファイルを構成する

次の設定でローカル ゲートウェイ トランク用の専用の SIP プロファイルを作成します。

設定値
名前固有の名前 (Webex など)
説明Webex SIP プロファイルなどの意味のある説明
オプションの Ping を有効にして、サービス タイプ「なし (デフォルト)」のトランクの宛先ステータスをモニタします。選択

Webex からのコールのコール検索スペースを作成する

次の設定で Webex から発信されたコールのためのコール検索スペースを作成します。

設定値
名前固有の名前 (Webex など)
説明Webex Calling 検索スペースなどの意味のある説明
選択済みパーティション:

DN (+E.164 ディレクトリ番号)

ESN (サイト間ダイヤル)

PSTNInternational (PSTN アクセス)

onNetRemote (GDPR 学習先)

最後のパーティション onNetRemote は、Intercluster Lookup Service (ILS) または Global Dialplan Replication (GDPR) を使用して、Unified CM クラスター間でルーティング情報が交換されるマルチクラスター環境でのみ使用されます。

Webex 間で SIP トランクを構成する

次の設定を使用して、ローカル ゲートウェイ経由での Webex 間のコールに SIP トランクを作成します。

設定値
デバイス情報
DeviceName一意の名前 (Webex など)
説明Webex SIP トランクなどの意味のある説明
すべてのアクティブな Unified CM ノード上で実行する選択
着信コール
コール検索スペース以前に定義されたコール検索スペース:Webex
AAR コール検索スペース PSTN ルート パターンへのアクセス権のみを持つコール検索スペース: PSTNReroute
SIP 情報
接続先アドレスローカル ゲートウェイ CUBE の IP アドレス
移動先ポート5060
SIP トランク セキュリティ プロファイル定義済み:Webex
SIP プロファイル定義済み:Webex

Webex のルート グループを構成する

次の設定でルート グループを作成します。

設定値
ルート グループ情報
ルート グループ名一意の名前 (Webex など)
選択したデバイス以前に構成された SIP トランク:Webex

Webex のルート リストを構成する

次の設定でルート リストを作成します。

設定値
ルート リスト情報
名前固有の名前 (RL_Webex など)
説明Webex のルート リストなど、意味のある説明
すべてのアクティブな Unified CM ノード上で実行する選択
ルート リスト メンバー情報
選択したグループ以前に定義されたルート グループのみ:Webex

Webex の移動先のパーティションを作成する

次の設定で Webex の移動先のパーティションを作成します。

設定値
ルート リスト情報
名前一意の名前 (Webex など)
説明Webex パーティションなどの意味のある説明

次にやる必要

このパーティションは、Webex の宛先にアクセスする必要があるすべてのコール検索スペースに追加してください。このパーティションは、PSTN から Webex への発信がルーティングされるように、PSTN トランクの着信コール検索スペースとして使用されるコール検索スペースに特に追加する必要があります。

Webex の移動先のルート パターンを構成する

次の設定で Webex の各 DID 範囲のルート パターンを構成します。

設定値
ルートパターン「\」が頭文字にある Webex で DID 範囲のフル +E.164 パターン例: \+140855501XX
ルート パーティションWebex
ゲートウェイ/ルート リストRL_ Webex
緊急の優先事項選択

Webex の簡略サイト間ダイヤル正規化を構成する

短縮されたサイト間ダイヤルが Webex に必要な場合は、Webex の各 ESB 範囲にダイヤル正規化パターンを設定します。

設定値
翻訳パターンWebex の ESN 範囲の ESB パターン。例:80121XX
パーティションWebex
説明Webex 正規化パターンなどの意味のある説明
発信者のコール検索スペースを使用する選択
緊急の優先事項選択
後続ホップでの連続桁のタイムアウトを待たない選択
着信側トランスフォーム マスク番号を + E.164 に正規化するマスク。例: +140855501XX

機能をセットアップする

ハント グループをセットアップする

ハント グループは着信をグループのユーザーまたはワークスペースにルーティングします。グループ全体にルーティングするパターンを構成することもできます。

ハント グループのセットアップ方法の詳細については、「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

2

[管理] > [ユーザー] に移動します。

3

ユーザーを選択し、[Calling] をクリックします。

4

[ユーザー間権限] セクションに移動し、[割り込み] を選択します。

5

トグルをオンにすると、他のユーザーがこのユーザーの進行中のコールに自分自身を追加できるようになります。

6

このユーザーが通話に割り込みを行ったときに他の人にトーンを再生する場合は、[このユーザーが通話に割り込みを行ったときにトーンを再生する] をオンにします。

[このユーザーが通話に割り込みを行ったときにトーンを再生する] 設定は、Customer Experience Basic および Essentials スーパーバイザーの割り込み機能には適用されません。スーパーバイザに対してこのオプションを有効にした場合でも、スーパーバイザがコール キュー コールに割り込んだときに、システムはエージェントに通知トーンを再生しません。

スーパーバイザがコールに割り込んだときにエージェントにトーンを再生する場合は、[エージェントの通知トーン] 設定で有効にできます。詳細については、「Webex Customer Experience Basic 」または「Webex Customer Experience Essentials 」の「キューの作成」セクションを参照してください。

7

[保存] をクリックします。

ユーザーのプライバシーを有効化

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

パークされた通話についてこのユーザーに通知するかどうかを選択し、監視するユーザーまたはコール パーク内線番号を検索して、[保存] をクリックします。

[監視対象回線（Monitored Lines）] リストは、ユーザーのデバイスに表示される監視対象回線の順序に対応します。監視対象回線のリストをいつでも並べ替えることができます。

監視対象回線に表示される名前は、ユーザー、ワークスペース、仮想回線の [発信者 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 から使用するホテリング ホストを検索し、検索することもできます。詳細については、「どこからでも通話プロファイルにアクセスする」を参照してください。

その方法を確認したいですか? このビデオ デモンストレーション で、Control Hub でホテリングを設定する方法をご覧ください。

導入傾向と使用状況レポート

通話レポートを表示

[アナリティクス] ページを使用して、サービスの使用方法、アプリでのエンゲージメント、通話メディア エクスペリエンスの品質を確認できます。分析にアクセスするには:

1

2

[分析] に移動し、[Calling] タブを選択します。

3

[詳細な通話履歴] を選択します。

通話履歴の詳細は、メディア品質データとともに表示されます。
4

メディア品質データにアクセスするには、にサインインし、[分析] に移動し、[通話] を選択します。

関連情報

Webex Calling の概要

エンタープライズグレードのクラウド通話、モビリティ、PBX 機能を、メッセージングとミーティング、ソフト クライアントまたは Cisco デバイスからの通話に使用できると想像してください。それがまさに、あなたにとって必要なことです。

以下の機能と利点を提供します。

  • テレフォニー ユーザーのためのコール サブスクリプションと共有領域。

  • 信頼できる地域のサービス プロバイダによって配信される安全かつ信頼性のあるクラウド サービス

  • すべてのユーザーにアクセスし、豊富な統合コミュニケーションとチーム コラボレーション サービスを追加します。

  • Webex Meetings はオプションで統合されたアドオンで、エンタープライズ ユーザーが期待するプレミアム ミーティング エクスペリエンスを提供します。

  • ユーザーが組織外に番号をダイヤルできるようにするためのパブリック スイッチ テレフォニー ネットワーク (PSTN) アクセス。サービスは既存のエンタープライズ インフラストラクチャを通じて提供されます

    • オンプレミス IP PBX なしのローカル ゲートウェイ

    • 既存の Unified CM コール環境

    • パートナーまたは Cisco が提供した PSTN オプション

  • パートナーや Cisco により提供されている次のレベルのサポートにより提供される階層 1 サポート

は、注文と構成を合理化し、バンドルされたオファー、、および Webex Meetings の管理を一元化するために統合する Web ベースの管理ポータルです。

表 1YAZ設定オプション 管理者の設定可能な機能

機能

説明

自動音声応答

セットアップ メニューと、応答サービス、ハント グループ、ボイスメール ボックスや実際のオペレーターなどへのルーティング機能によって、適切なあいさつを返すことができます。24 時間分のスケジュールを作成することができます。あるいは、営業時間内か外かに応じて、異なるオプションを使うこともできます。通話は、発信者の ID 属性に応じてルーティングすることによって、VIP リストを作成したり、特定の市外局番からの通話には対応を変えたりすることができます。

コール キュー

着信通話に応答できないときに、通話キューを設定できます。誰かがコールに応答できるまで、自動応答、ご案内のメッセージ、保留中の音楽を発信者に提供できます。

通話ピックアップ

コール ピックアップ グループを作成して、ユーザーが別のユーザーの通話に応答できるようにすることで、チームワークとコラボレーションを強化できます。ユーザーをコールピックアップグループに追加しておけば、グループメンバーが席を離れていたり、電話中だったりした場合、別のメンバーが電話に出ることができます。

コール パーク

コール パークをオンにすると、ユーザがコールを保留にし、別の電話からピックアップできます。

ハントグループ

以下のようなシナリオでは、ハント グループをセットアップするのがよいでしょう。

  • セールス チームは順番に転送を求めている可能性があります。着信が電話を鳴らしても応答が無かった場合、その通話はリスト中の次のエージェントへと転送されます。

  • サポートチームは最初の対応可能なエージェントが電話に応答できるように、電話が同時に鳴ることを希望する傾向があります。

ページング グループ

ユーザーが音声メッセージを個人、部署、チームに送信できるように、ページング グループを作成できます。誰かがメッセージをページング グループに送信するとき、グループのすべてのデバイスでメッセージが再生されます。

レセプショニスト クライアント

フルセットの通話管理オプション、大規模モニタリング、コール キュー、複数のディレクトリ オプションとビュー、Outlook との統合などを提供することにより、フロントオフィス担当者のニーズを満たします。
表 2. ユーザーの設定可能な機能

機能

説明

匿名コールの拒否

ユーザーはブロックされた発信者 ID を使用して着信を拒否できます。

障害時一括転送

停電、ネットワークの問題などの理由でユーザの電話がネットワークに接続されていない場合、ユーザは着信コールを特定の電話番号に転送できます。

コール転送

ユーザーは着信コールを別の電話に転送することができます。

選択的コール転送

ユーザーは特定の発信者、特定の時間のコールを転送することができます。この設定はコール転送より優先されます。

コール通知

ユーザーは、電話番号や日時など、事前に定義された条件に従ってコールを受信したときに自分自身にメールが送られるよう設定することができます。

着信待ち受け

ユーザーは追加の着信に応答することができます。

応答不可

ユーザーは一時的にすべての通話をボイスメールに直接転送できます。

Office Anywhere

ユーザーは選択された電話 (「ロケーション」) を、会社の電話番号とダイヤルプランの内線として使用することができます。

優先アラート

ユーザーは電話番号や日時など、事前に定義された条件が満たされたときに、特別な着信音が鳴るように設定することができます。

リモート オフィス

ユーザーはリモートの電話からコールを発信し、ビジネス回線からのものとして表示させることができます。さらに、ビジネス回線への着信は、このリモート電話で鳴ります。

選択通話承諾

ユーザーは特定の発信者、特定の時間のコールを承認することができます。

匿名通話の拒否

ユーザーは特定の発信者、特定の時間のコールを拒否することができます。

シーケンシャル リング

着信があると、最大で 5 台のデバイスを 1 つずつ鳴らすことができます。

同時リング

着信があると、ユーザーの番号の電話と、別の番号の電話 (「コールの受信者」) 番号が同時に鳴ります。

のサービス、デバイス、ユーザーのプロビジョニング、詳細設定へのクロス起動

() は、注文と構成を合理化し、バンドルされたオファーの管理を一元化する管理ポータルです。

は、すべてのサービス、デバイス、およびユーザーをプロビジョニングする中心点です。コーリング サービスの初回セットアップ、MPP 電話のクラウドへの登録 (MAC アドレスを使用)、デバイスの関連付けや、電話番号、サービス、コール機能の追加などにより、ユーザーを構成することができます。また、 から にクロスローンチすることもできます。

ユーザーエクスペリエンス

ユーザーは次のインターフェイスへのアクセスできます。

  • アプリケーション—Cisco ブランドのコール用のソフト クライアント。詳細については、「新しい Cisco Webex Calling アプリを検索する」を参照してください。

  • ()—ユーザーがプロファイルの基本設定を設定し、Webex アプリをダウンロードし、for Calling 設定にクロス起動できるインターフェイス。詳細については、「Cisco Webex の設定を変更する」を参照してください。

  • Webex アプリ—Cisco ブランドの Team メッセージング クライアントとしてのサブスクリプションに含まれるアプリケーション。詳細については、「新しいアプリを 使い始めるCisco Webexしてください。

  • Webex Meetings —ミーティング ソリューションとして追加されるオプションのアプリケーション。詳細については、「Webex Meetings」を参照してください。

カスタマー管理者

のトライアルまたは有料サブスクリプションの顧客管理者は、ロケーション、ライセンス、電話番号、通話機能、ユーザー、ワークスペース (Webex クラウドに登録されている会議室デバイス) を追加することで、組織をセットアップできます。これらのすべてコンポーネントを同様にそこから管理できます。

パートナー:

パートナー サービス プロバイダとして、ブランドとマーケットを設定し、 を顧客に販売できます。トライアルをセットアップして、顧客にサービスを展開し、顧客にオーダーを作成してプロビジョニングすることもできます。

サービス開始日時

販売可能な国については、「Cisco Webex はどこで利用可能ですか 」の記事を参照してください。

ツアーに参加する

は、組織の管理、ユーザーの管理、サービスの割り当て、導入の傾向と通話品質の分析などを行うための、単一の Web ベースのインターフェイスです。

Control Hub のインターフェイスの概要は、左側ナビゲーションメニュー、会社情報、通知、アプリ内ヘルプ、フィードバック、言語、サインアウトのハイライトとラベル付けです。

組織を立ち上げて稼働させるには、 にメール アドレスを入力して参加するユーザーを数人招待することをおすすめします。コールを含む、提供されるサービスを使用するようにユーザーを促し、彼らの満足度に関するフィードバックを提供することを求めます。準備が完了したら、いつでもユーザーを追加することができます。

にアクセスするには最新のGoogle ChromeもしくはMozilla Firefoxの最新バージョンを使用されることを推奨します。モバイル デバイスのブラウザーやその他のデスクトップ ブラウザーを使用した場合、予期せぬ結果が生じる場合があります。

以下に示す情報を、組織がサービスをセットアップし始めた場合に期待できる事柄についての、大まかな概要として用いてください。詳細については、個々の章の、手順を追った説明を参照してください。

使い始める

パートナーがあなたのアカウントを作成すると、ウェルカム メールが届きます。Chrome または Firefox を使用して、メールの [はじめに] リンクをクリックします。このリンクを使うと、管理者のメール アドレスで自動的にサインインすることができます。次に、管理者パスワードを作成するためのプロンプトが表示されます。

Control Hub セットアップの開始メールから、新しいパスワード画面を作成します。

トライアルのための初回ウィザード

パートナーがトライアルに登録している場合、サインインすると、セットアップ ウィザードが自動的に開始されます。このウィザードでは、組織をセットアップし、他のサービスを実行するための基本設定について説明します。ウィザードのガイドを終えると、Calling の設定とその確認が完了します。

Control Hub の初回セットアップ ウィザード。

設定の確認

ロード時に、設定を確認できます。

Control Hub の概要ページ。

ユーザーの追加

サービスをセットアップしたら、会社ディレクトリからユーザーを追加する準備ができます。[ユーザー] に進んで、[ユーザーの管理] をクリックします。

Control Hub でユーザー ポップアップ ウィンドウを管理します。

Microsoft Active Directory を使用している場合、まずディレクトリ同期を有効にしてからユーザーの追加方法を決定することをお勧めします。[次へ] をクリックし、指示に従って Cisco Directory Connector を設定します。

シングル サインオン (SSO) の設定

基本的な認証を使用します。 SSO をセットアップして、ユーザーが Webex に保存され、管理される別のパスワードではなく、エンタープライズ クレデンシャルを使用してエンタープライズ ID プロバイダーで認証されるようにできます。 SSO

[設定] に移動し、[認証] までスクロールして、[変更] をクリックしてから、[サードパーティの ID プロバイダを統合させる] を選択します。

[サードパーティ プロバイダーを統合] オプションが選択されているシングル サインオン設定画面です。

サービスをユーザーに割り当てる

ユーザーが使用を開始できるように、追加したユーザーにサービスを割り当てる必要があります。

[ユーザー] に移動して、[ユーザーの管理] をクリックし、[CSV ファイルでユーザーをエクスポートおよびインポートする] を選択してから、[エクスポート] をクリックします。

ダウンロードしたファイルで、各ユーザーに割り当てるサービスに [True] を追加します。

Control Hub でユーザーにサービスを割り当てるための CSV ファイルの例。

完了したファイルをインポートし、[サービスの追加および削除] をクリックして、[提出] をクリックします。これで、コール機能を構成し、共通場所で共有できるデバイスを登録し、デバイスを登録してユーザーに関連付ける準備ができました。

ユーザーを支援する

ユーザーを追加し、サービスが割り当てられたら、サポートされているマルチプラットフォーム電話 (MPP) を使用してメッセージングやミーティングを開始できます。ユーザーに、アクセスのためのワンストップショップとしてCisco Webex の設定 を使用するように促してください。

ローカル ゲートウェイの役割

ローカル ゲートウェイは、エンタープライズまたはパートナーにより管理されているエッジ デバイスです。これは、パブリックスイッチのテレフォニー ネットワーク (PSTN) の相互動作と従来型のプライベート ブランチ エクスチェンジ (PBX) との動作のためのものです (Unified CM を含む)。

を使用して、 ローカル ゲートウェイを場所に割り当てることができます。その後、 はキューブで構成できるパラメータが提供されます。これらの手順により、ローカル ゲートウェイがクラウドに登録され、PSTN サービスが特定の場所の ユーザーに対してゲートウェイを通じて提供されます。

ローカル ゲートウェイを指定して注文するには、「ローカルゲートウェイの注文ガイド」を参照してください。

サポートされているローカル ゲートウェイの展開

次の基本的な展開がサポートされています。

ローカル ゲートウェイは、Cisco Unified Communications Manager へのインテグレーションが必要な場合、スタンドアロンまたは導入で展開することができます。

オンプレミスの IP PBX なしのローカル ゲートウェイ展開

スタンドアロンのローカル ゲートウェイ展開

この図は、既存の IP PBX なしの展開を示しており、単一のロケーションまたはマルチロケーションの展開に適用されます。

既存の IP PBX を使用しない Webex Calling の展開を示す図。

宛先と一致しないすべてのコールについて、これらのコールは処理のためにロケーションに割り当てられているローカル ゲートウェイに送信します。ローカル ゲートウェイは、着信するすべてのコールを PSTN にルーティングし、反対方向に PSTN から にルーティングします。

PSTN ゲートウェイは、ローカル ゲートウェイの専用プラットフォームまたは共存プラットフォームになります。次の図のように、この展開の専用 PSTN ゲートウェイのバリアントをお勧めします。既存の PSTN ゲートウェイをローカル ゲートウェイとして使用できない場合に使用できます。

既存の PSTN ゲートウェイを Webex Calling ローカル ゲートウェイとして使用できない場合に使用できる、推奨された PSTN ゲートウェイの展開オプションを示すイラスト。

共存型のローカル ゲートウェイの展開

ローカル ゲートウェイとして、ITSP に接続するために SIP トランクを使用する IP ベースのもの、または ISDN またはアナログ回路を使用する TDM ベースのものを使用できます。次の図は、ローカル ゲートウェイが PSTN GW/SBC と共存している展開を示しています。

ローカル ゲートウェイが PSTN GW/SBC と共存している Webex Calling の展開を示しています。

オンプレミスの Unified CM PBX なしでのローカル ゲートウェイ展開

Unified CM とのインテグレーションは、以下の場合に必要です。

  • -有効なロケーションは、Unified CM がオンプレミス通話制御ソリューションとして展開される既存の Cisco UC 展開に追加されます

  • Unified CM に登録されている電話機とロケーションの電話機間のダイレクト ダイヤルが必要です。

この図は、顧客が既存の Unified CM IP PBX を持っている展開を示しています。

顧客が既存の Unified CM IP PBX を持つ Webex Calling の展開を示しています。

Webex Calling は、顧客の宛先と一致しないコールをローカル ゲートウェイに送信します。これには、PSTNおよび Unified CM 内部内線番号Webex Calling含まれます。ローカル ゲートウェイは、ユーザーから Unified CM へ、その逆Webex Calling、すべての通話をルーティングします。Unified CM は、着信コールを、既存のダイヤル プランに従ってローカルの宛先または PSTN にルーティングします。Unified CM のダイヤル プランは、番号を +E.164 として正規化します。PSTN ゲートウェイには、専用のものと、ローカル ゲートウェイに共存しているものがあります。

専用の PSTN ゲートウェイ

この図に示されているように、この展開の専用 PSTN ゲートウェイのバリアントが推奨オプションであり、既存の PSTN ゲートウェイをローカル ゲートウェイとして使用できない場合に使用できます。

専用 PSTN ゲートウェイのバリエーションを示すイラスト。既存の PSTN ゲートウェイを Webex Calling ローカル ゲートウェイとして使用できない場合に使用できる推奨オプション。

共存型 PSTN ゲートウェイ

この図は、ローカル ゲートウェイが PSTN ゲートウェイ/SBC と共存する Unified CM の展開を示しています。

Webex Calling は、顧客の宛先と一致しないすべてのコールを、ロケーションに割り当てられているローカル ゲートウェイにルーティングします。これには、PSTN の宛先と、Unified CM 内部の内線に向けたオンネット コールが含まれます。ローカルゲートウェイは、すべてのコールを Unified CM にルーティングします。その後、Unified CM は PSTN/SBC 機能が共存している ローカル ゲートウェイを通じて、コールをローカルに登録された電話または PSTN にルーティングします。

ローカル ゲートウェイが PSTN ゲートウェイ/SBC と共存する Unified CM を使用した Webex Calling の展開を示す図。

コール ルーティングの考慮点

Unified CM へのコール

ルーティング ロジックは次のように動作します。エンドポイントでダイヤルされた番号が Webex Calling の同じ顧客内の他の宛先にルーティングできない場合、コールはローカル ゲートウェイに送信され、さらなる処理が行われます。オフネット (外部) のWebex Callingは、ローカル ゲートウェイに送信されます。

既存の Unified CM に統合されていない展開の場合、オフネット コールは PSTN コールと見なされます。Unified CM との組み合わせでは、オフネット コールは、Unified CM でホストされている任意の宛先へのオンネット コール、または PSTN 宛先への実際のオフネット コールになり得ます。後者の 2 つのコールの種類の違いは、Unified CM によって決まり、Unified CM でプロビジョニングされたエンタープライズ ダイヤル プランによって異なります。

次の図は、米国内の国番号をダイヤルするユーザを示しています。

米国内の国番号をダイヤルする Webex Calling ユーザーの図です。

Unified CM は、構成済みのダイヤルプランに基づいて、発信先が電話帳としてプロビジョニングされている、ローカルに登録されたエンドポイントにルーティングします。このため、Unified CM のダイヤル プランは + E.164 番号のルーティングをサポートする必要があります。

Unified CM から

Unified CM から Unified CM へのコール ルーティングを有効にするには、一連のルートをプロビジョニングして、 の +E.164 とエンタープライズ番号プラン アドレスのセットを定義する必要があります。

これらのルートを構成することにより、次の図に示されているコール シナリオの両方が可能になります。

Unified CM のルートのセットで Unified CM から Webex Calling へのコール ルーティングを示す図。

PSTN の発信者がデバイスに割り当てられた DID 番号に発信すると、コールはエンタープライズの PSTN ゲートウェイを介してエンタープライズに渡され、Unified CM にヒットします。そのコールの着信アドレスは、Unified CM でプロビジョニングされたルートの 1 つと一致し、コールがローカル ゲートウェイに送信されます。(ローカル ゲートウェイに送信する場合、着信アドレスは +E.164 形式である必要があります)。次に、Webex Calling のルーティング ロジックにより、DID の割り当てに基づいてコールが目的のデバイスに送信されるようにします。

また、Unified CM 登録済みエンドポイントから発信されたコールは、Unified CM でプロビジョニングされたダイヤル プランの対象となります。通常、このダイヤルプランにより、ユーザーは一般的なエンタープライズダイヤルの習慣を使ってコールを発信することができます。これらの習慣には、必ずしも +E.164 ダイヤルだけが含まれているわけではありません。+E.164 以外のダイヤル習慣は、通話がローカル ゲートウェイに送信される前に +E.164 にノーマライズし、Webex Calling で正しいルーティングを許可する必要があります。

サービス クラス (CoS)

厳しいサービス クラスの制限を実装することは、コールのループの回避や特殊詐欺の防止など、さまざまな理由により常に推奨されます。ローカル ゲートウェイと Unified CM のサービス クラスを統合するコンテキストでは、次のサービスのクラスを考慮する必要があります。

  • Unified CM に登録されているデバイス

  • PSTN からUnified CM に着信するコール

  • ユーザーから Unified CM に着信Webex Calling

Unified CM に登録されているデバイス

既存の CoS セットアップに通知先の新しいクラスとして通知先を追加することは、かなり簡単です。宛先へのコールの権限は、通常、オンプレミス（サイト間を含む）の宛先を呼び出す権限と同等です。

エンタープライズ ダイヤル プランがすでに「（短縮された）オンネット サイト間」権限を実装している場合、Unified CM でプロビジョニングされたパーティションがすでに存在しており、同じパーティション内のすべての既知のオンネット 宛先を使用、プロビジョニングできます。

それ以外の場合、「（短縮された）オンネットサイト間」権限の概念はまだ存在しておらず、新しいパーティション（「onNetRemote」など）をプロビジョニングし、宛先がこのパーティションに追加され、最終的にこの新しいパーティションを適切なコーリング サーチ スペースに追加する必要があります。

PSTN からUnified CM に着信するコール

既存の CoS セットアップに通知先の新しいクラスとして通知先を追加することは、かなり簡単です。宛先へのコールの権限は、通常、オンプレミス（サイト間を含む）の宛先を呼び出す権限と同等です。

エンタープライズ ダイヤル プランがすでに「（短縮された）オンネット サイト間」権限を実装している場合、Unified CM でプロビジョニングされたパーティションがすでに存在しており、同じパーティション内のすべての既知のオンネット 宛先を使用、プロビジョニングできます。

それ以外の場合、「（短縮された）オンネットサイト間」権限の概念はまだ存在しておらず、新しいパーティション（「onNetRemote」など）をプロビジョニングし、宛先がこのパーティションに追加され、最終的にこの新しいパーティションを適切なコーリング サーチ スペースに追加する必要があります。

ユーザーから Unified CM に着信Webex Calling

PSTN からの着信は、すべての宛先にアクセスする必要があります。これには、すべての宛先を保持している上記のパーティションを、PSTN トランク上の着信コールに使用されるコーリング サーチ スペースに追加する必要があります。宛先へのアクセスは、既存のアクセスに加えて、追加されます。

PSTN から Unified CM DID にアクセスするコールと DID は、Unified CM DID と PSTN の宛先へのアクセスに必要なコールが必要です。

PST と Webex Calling からの通話の差別化された CoS の図。
PSTN からのコールのための差別化された CoS

この図は、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 宛先を表すパーティションが作成され ("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」パーティションに追加することを推奨しません。

コール用プロトコル ハンドラー

次のプロトコル ハンドラーをオペレーティング システムに登録して、Web ブラウザーまたはその他のアプリケーションからクリック通話機能を有効にします。Mac または Windows でデフォルトの通話アプリケーションである場合、次のプロトコルは Webex アプリで音声またはビデオ通話を開始します。

  • CLICKTOCALL: または CLICKTOCALL://

  • SIP: または SIP:

  • TEL: または TEL:

  • WEBEXTEL: または WEBEXTEL://

Mac または Windows のデフォルトの通話アプリケーションの場合、Webex アプリで音声またはビデオ通話を開始するプロトコル ハンドラのリスト。

Windows 用プロトコル ハンドラー

他のアプリは、 より前にプロトコル ハンドラーに登録できます。Windows 10 では、通話を開始するために使用するアプリを選択するためにユーザーに尋ねるシステム ウィンドウ。ユーザーは、[常にこのアプリを使う] にチェックを入れて、記憶させることができます。

Windows 10 「アプリを選択」を選択するオプションとして Webex が強調表示されます。

ユーザーが選択できるように、デフォルトの通話アプリ設定をリセットする必要がある場合は、Windows 10 でプロトコルの関連付けを変更するように指示することができます。

  1. [デフォルトのアプリ設定] システム設定を開き、[アプリごとにデフォルトを設定する] をクリックして、 を選択します。

    Windows 10 の [アプリごとにデフォルトを設定する] で、Webex を選択するオプションとして強調表示されます。

  2. 各プロトコルに対して、 を選択します。

    ファイル タイプとプロトコルの関連付けのための Windows 10 Webex オプション。

macOS 用のプロトコルハンドラー

Mac OS では、以前に他のアプリが通話プロトコルに登録されている場合、ユーザーはデフォルトの通話オプションに設定する必要があります。

Mac では、ユーザーは一般的な基本設定で [通話を開始 ] 設定に選択されていることを確認できます。また、Outlook の連絡先の番号をクリックしたときにコールインする場合は、[常に Microsoft Outlook に接続する] をオンにすることもできます。

Mac OS プロトコル ハンドラ設定、[常に Microsoft Outlook に接続] オプションを選択し、[コールを開始] ドロップダウンで Webex が選択されています。

環境を準備する

全般的な前提条件

ローカル ゲートウェイを設定する前に、次のことを確認してください。

  • 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 注文ガイド」の表 1 を参照してください。また、ローカル ゲートウェイ構成ガイドに従って、プラットフォームがサポートされている IOS-XE リリースを実行していることを確認してください。

ローカル ゲートウェイは、自分のペースで Webex Calling に移行するのに役立ちます。ローカル ゲートウェイは、既存のオンプレミス展開を Webex Calling と統合します。既存の PSTN 接続を使用することもできます。「ローカル ゲートウェイの使用を開始する」を参照してください。

ローカル ゲートウェイのライセンスに関する要件

CUBE コールライセンスは、ローカル ゲートウェイにインストールされている必要があります。詳細については、Cisco Unified 境界要素の構成ガイドを参照してください。

ローカル ゲートウェイの認証およびセキュリティ的要件

は、セキュアな信号経路とメディアを必要とします。ローカルゲートウェイは暗号化を行います。また、以下の手順に従って、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 を実行している必要があります。

ポート参照情報

適切に構成されたファイアウォールとプロキシは、通話の展開を成功させるために不可欠です。コール シグナリングに 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 を無効にする手順については、関連する製造元のマニュアルを確認してください。

プロキシ サポート

組織はインターネット ファイアウォールまたはインターネット プロキシおよびファイアウォールを展開し、ネットワークを出入りする 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 アプリのプロキシ アドレスを手動で設定します。

希望の製品タイプを設定するときに、表で次のプロキシ設定と認証タイプを選択します。

製品

プロキシの設定

認証タイプ

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

表の凡例の場合:

  1. †Mac NTLM 認証 - マシンはドメインにログインする必要はなく、ユーザーはパスワードの入力を求められます

  2. †Windows NTLM 認証 - マシンがドメインにログインしている場合にのみサポートされます

  3. ネゴシエート †- NTLM フォールバック認証で Kerberos。

  4. Cisco Webex Board、Desk、または Room シリーズのデバイスをプロキシ サーバーに接続するには、「Board、Desk、または Room シリーズのデバイスをプロキシ サーバーに接続する」を参照してください。

  5. Cisco IP 電話の場合、プロキシ サーバーと設定を構成する例として、プロキシ サーバーのセットアップ を参照してください。

No Authentication の場合、認証をサポートしていないプロキシ アドレスでクライアントを設定します。Proxy Authentication を使用する場合、有効な資格情報で構成します。Web トラフィックを検査するプロキシは、Web ソケット接続に干渉する場合があります。この問題が発生した場合、*.Webex.com への検査を行わないトラフィックをバイパスすると問題が解決する可能性があります。すでに他のエントリが表示されている場合は、最後のエントリの後にセミコロンを追加し、Webex 例外を入力します。

Windows OS のプロキシ設定

Microsoft Windows は、プロキシ設定を許可する HTTP トラフィック (WinINet および WinHTTP) のための 2 つのネットワーク ライブラリをサポートしています。WinINet は WinHTTP のスーパーセットです。

  1. WinInet は、シングルユーザーのデスクトップ クライアント アプリケーション用に設計されています

  2. 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 Aware サービスをサポートし、サポートしています。Amazon は、シスコの単独使用のために IP サブネットを予約し、AWS 仮想プライベート クラウド内のこれらのサブネットにあるサービスを保護しました。

お使いのデバイス、アプリのアプリケーション、およびインターネットサービスからの通信が正常に機能を実行できるようにファイアウォールを設定します。この設定により、サポートされているすべての Webex Aware クラウド サービス、ドメイン名、IP アドレス、ポート、プロトコルにアクセスできます。

Webex Aware サービスが正しく機能するように、ホワイトリストまたは次のアクセス権を開きます。

  • 「Webex Calling サービスのドメインと URL」セクションで言及されている URL/ドメイン

  • 「Webex Calling サービスの IP サブネット」セクションで言及されている IP サブネット、ポート、およびプロトコル

  • 組織内で Webex クラウド コラボレーション サービスの Webex スイート、Webex Meetings、Messaging、Webex アテンダントコンソール、およびその他のサービスを使用している場合は、IP サブネットを持っていることを確認します。これらの記事で言及されているドメイン/URL は、「Webex サービスのネットワーク要件 」および「アテンダントコンソールのネットワーク要件」が開いています。

ファイアウォールのみを使用している場合、一部の IP アドレス プールは動的で、いつでも変更される可能性があるため、IP アドレスだけを使用してトラフィックをフィルタリングすることはサポートされません。ルールを定期的に更新すると、ファイアウォールのルール リストの更新に失敗すると、ユーザーのエクスペリエンスに影響を与える可能性があります。Cisco は、特定の地域またはクラウド サービス プロバイダーに基づいて、IP アドレスのサブセットをフィルタリングすることを推奨しません。地域別にフィルタリングすると、通話エクスペリエンスが著しく低下する可能性があります。

Cisco は IP アドレス プールの動的な変更を維持していないため、この記事には記載されません。

ファイアウォールがドメイン/URL フィルタリングをサポートしていない場合は、エンタープライズ プロキシ サーバー オプションを使用してください。このオプションは、ファイアウォールに転送する前に、HTTP シグナリング トラフィックとプロキシ サーバーの Webex Aware サービスを URL/ドメインでフィルタ/許可します。

コール メディアのポートと IP サブネット フィルタリングを使用してトラフィックを設定できます。メディア トラフィックにはインターネットへの直接アクセスが必要であるため、シグナリング トラフィックの URL フィルタリング オプションを選択します。

の場合、UDP はメディアに対して Cisco が推奨するトランスポートプロトコルであり、UDP 経由の SRTP のみを使用することをお勧めします。メディア用のトランスポート プロトコルとして TCP および TLS は、本番環境ではサポートされていません。これらのプロトコルの接続指向の性質は、損失のあるネットワーク上のメディア品質に影響します。トランスポートプロトコルに関するクエリがある場合は、サポート チケットを発行します。

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 サービス

  1. アイデンティティ プロビジョニング

  2. アイデンティティ ストレージ

  3. 認証

  4. OAuth サービス

  5. オンボードのデバイス

  6. クラウド接続 UC

電話機を初めてネットワークに接続する場合、または 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 マイクロサービス。

  1. プロファイル画像サービス

  2. ホワイトボード サービス

  3. Proximity サービス

  4. プレゼンス サービス

  5. 登録サービス

  6. カレンダー サービス

  7. 検索サービス

すべて

*.webexcontent.com

一般的なファイル ストレージに関する Webex メッセージング サービス:

  1. ユーザー ファイル

  2. トランスコードされたファイル

  3. イメージ

  4. スクリーンショット

  5. ホワイトボードの内容

  6. クライアントとデバイスのログ

  7. プロファイル画像

  8. ブランディング ロゴ

  9. ログ ファイル

  10. CSV エクスポート ファイルの一括インポート (Control Hub)

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-65535TCP「Webex Calling サービスの IP サブネット」を参照してください。5062, 8934

これらの IP/ポートは、ローカル ゲートウェイ、デバイス、および Webex アプリ アプリケーション (ソース) から Webex Calling クラウド (宛先) への発信 SIP-TLS コール シグナリングに必要です。

ポート 5062（証明書ベースのトランクに必要）。およびポート 8934 (登録ベースのトランクに必要)

デバイス5060-50808934
Webex アプリ 一時的 (OS 依存)
Webex Calling (SIP TLS) からローカル ゲートウェイへのコール シグナリング

Webex Calling のアドレス範囲。

「Webex Calling サービスの IP サブネット」を参照してください。

8934TCPローカル ゲートウェイに顧客が選択した IP または IP 範囲ローカル ゲートウェイに顧客が選択したポートまたはポート範囲

証明書ベースのローカル ゲートウェイに適用されます。Webex Calling からローカル ゲートウェイへの接続を確立する必要があります。

登録ベースのローカル ゲートウェイは、ローカル ゲートウェイから作成された接続を再利用することで機能します。

宛先ポートは、[トランクの設定] を選択した顧客です。

Webex Calling へのコール メディア (STUN、SRTP/SRTCP、T38、DTLS)ローカル ゲートウェイ外部 NIC8000-48199†*UDP「Webex Calling サービスの IP サブネット」を参照してください。

5004、9000 (STUN ポート)

音声: 8500-8599

ビデオ: 8600-8699

19560-65535 (UDP 経由の SRTP)

  • これらの IP/ポートは、ローカル ゲートウェイ、デバイス、および Webex アプリ アプリケーション (ソース) から Webex Calling クラウド (宛先) への発信 SRTP コール メディアに使用されます。

  • STUN、ICE ネゴシエーションが成功している組織内の通話の場合、通信パスとしてクラウドのメディアリレーが削除されます。このような場合、メディア フローはユーザーのアプリ/デバイス間で直接行われます。

    例: メディア最適化が成功すると、Webex アプリはポート範囲 8500 ～ 8699 で互いに直接メディアを送信し、デバイスは 19560 ～ 19661 で互いに直接メディアを送信します。

  • 顧客のプレミス内でファイアウォールが使用される特定のネットワーク トポロジでは、メディアがフロースルーするために、ネットワーク内の前述の送信元と宛先ポート範囲へのアクセスを許可します。

    例：Webex アプリでは、送信元と送信先のポート範囲を許可します

    音声: 8500-8599 ビデオ:8600-8699

  • ブラウザは、管理対象デバイス管理（MDM）プロファイルで WebRtcUdpPortRange ポリシーを設定することで制御できる一時的なソース ポートを使用します。

    MDM サービスが設定されていない場合、または SiteURL と EnableForceLogin が設定されていない 場合、Webex Calling サービスは通常どおりに動作します。

デバイス†*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)ローカル ゲートウェイ内部 NIC8000-65535TCPITSP、PSTN GW または Unified CMPSTN オプションによって異なる (たとえば、Unified CM の 5060 または 5061)
PSTN ゲートウェイへのコール メディア (SRTP/SRTCP)ローカル ゲートウェイ内部 NIC8000-48199†*UDPITSP、PSTN GW または Unified CMPSTN オプションによって異なります（たとえば、Unified CM の場合は 5060 または 5061）
デバイスの構成とファームウェアの管理 (Cisco デバイス)Webex Calling デバイス一時的TCP

「Webex Calling サービスの IP サブネット」を参照してください。

443, 6970, 80

次の理由で必須:

  1. エンタープライズ電話 (Cisco Unified CM) から Webex Calling への移行。詳細については、upgrade.cisco.com を参照してください。cloudupgrader.webex.com はポートを使用します。ファームウェア移行プロセスの 6970,443。

  2. 16 桁のアクティベーション コード (GDS) を使用したデバイス (MPP および Room または Desk Phone) のファームウェアのアップグレードと安全なオンボーディング

  3. CDA / EDOS - MAC アドレスベースのプロビジョニング。新しいファームウェアを持つデバイス（MPP 電話、ATA、SPA ATA）で使用されます。

  4. Cisco ATA の場合、デバイスが最小ファームウェア 11.1.0MSR3-9 にあることを確認します。

  5. 電話機が初めてネットワークに接続する場合、または初期設定へのリセット後に、DHCP オプションが設定されていない場合は、ゼロ タッチ プロビジョニング用のデバイス アクティベーション サーバに接続します。新しい電話は、プロビジョニングのために webapps.cisco.com の代わりに activate.cisco.com を使用します。11.2(1) より前にリリースされたファームウェアを搭載した電話機は、引き続き webapps.cisco.com を使用します。すべての IP サブネットを許可することをお勧めします。

  6. 12.0.3 バージョンより古い Cisco マルチプラットフォーム フォン (MPP) が、ポート 80 から sudirenewal.cisco.com にアクセスして、製造元でインストールされた証明書 (MIC) を更新し、セキュアな一意のデバイス識別子 (SUDI) を持つことを許可します。詳細については、フィールド通知を参照してください。

Webex アプリの設定Webex アプリ アプリケーション一時的TCP

「Webex Calling サービスの IP サブネット」を参照してください。

443, 8443Id ブローカー認証、クライアントの Webex アプリ構成サービス、セルフケアおよび管理インターフェイス アクセスのためのブラウザベースの Web アクセスに使用されます。
TCP ポート 8443 は、構成をダウンロードするために Cisco Unified CM セットアップの Webex アプリで使用されます。Webex Calling に接続するためにセットアップを使用する顧客のみがポートを開く必要があります。
デバイス時間同期 (NTP)Webex Calling デバイス51494UDP「Webex Calling サービスの IP サブネット」を参照してください。123これらの IP アドレスは、デバイス（MPP 電話、ATA、SPA ATA）の時間同期に必要です。

ドメイン ネーム システム（DNS）の解決

Webex Calling デバイス、Webex アプリ、Webex デバイス一時的UDP および TCP主催者が定義53DNS ルックアップでクラウドの Webex Calling サービスの IP アドレスを検出するために使用されます。典型的な DNS ルックアップは UDP で行われますが、クエリ応答が UDP パケットに収まらない場合、TCP が必要な場合があります。
ネットワーク タイム プロトコル (NTP)Webex アプリと Webex デバイス123UDP主催者が定義123時間同期
CScanWebex Calling の Web ベースのネットワーク準備事前資格ツール一時的TCP「Webex Calling サービスの IP サブネット」を参照してください。8934 および 443Webex Calling の Web ベースのネットワーク準備事前資格ツールです。詳細については、cscan.webex.com を参照してください。
UDP19569-19760
追加の Webex Calling および Webex Aware サービス (サードパーティ)
プッシュ通知 APNS および FCM サービス Webex Calling アプリケーション 一時的TCP

リンクの下に記載されている IP サブネットを参照してください

Apple プッシュ通知サービス (APNS)

Google-Firebase クラウド メッセージング (FCM)

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 日

次の詳細で更新されました。

  • Webex Calling (アプリ、デバイス) でサポートされている QoS (TOS/DSCP) 値

  • ネットワーク図を更新しました

  • Webex アテンダントコンソールに関連するネットワーク要件のリンクを含める。

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 日

記事全体を見直して、以下を含めました。

  1. プロキシ サポートのオプションが含まれています。

  2. 変更された通話フロー図

  3. Webex Calling および Webex Aware サービスの簡素化されたドメイン/URL/IP サブネット部分

  4. Webex Calling および Webex Aware サービスに対して 170.72.0.0/16 IP サブネット範囲を追加しました。

    次の範囲 170.72.231.0、170.72.231.10、170.72.231.161 および 170.72.242.0/24 を削除しました。

2023年3月5日

記事を更新して、以下を含めます。

  • アプリケーションで使用される UDP-SRTP ポート範囲（8500～8700）を追加しました。

  • プッシュ通知 APNS および FCM サービスのポートを追加しました。

  • UDP と TCP の CScan ポート範囲を分割します。

  • リファレンス セクションを追加しました。

2022 年 11 月 15 日

デバイス構成とファームウェア管理 (Cisco デバイス) に次の IP アドレスを追加しました。

  • 170.72.231.0

  • 170.72.231.10

  • 170.72.231.161

デバイス構成とファームウェア管理 (Cisco デバイス) から次の IP アドレスを削除しました。

  • 3.20.118.133

  • 3.20.228.133

  • 3.23.144.213

  • 3.130.125.44

  • 3.132.162.62

  • 3.140.117.199

  • 18.232.241.58

  • 35.168.211.203

  • 50.16.236.139

  • 52.45.157.48

  • 54.145.130.71

  • 54.156.13.25

  • 52.26.82.54

  • 54.68.1.225

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 機能

  • ソース アドレス: Webex Calling デバイス

  • ソースポート: 一時的

  • プロトコルTCP

  • 宛先アドレス: 「Webex Meetings/Messaging - ネットワーク要件」で定義されている IP サブネットとドメインを参照してください。

  • 宛先ポート: 443

    メモ: Webex Calling デバイスは、これらの IP アドレスとドメインを使用して、ディレクトリ、通話履歴、ミーティングなどの Webex クラウド サービスとインターフェイスします。

[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しました。

  • 23.89.40.0/25

  • 23.89.1.128/25

2022 年 3 月 29 日

このサービスに以下の IP サブネットWebex Callingしました。

  • 23.89.33.0/24

  • 150.253.209.128/25

2021 年 9 月 20 日

Webex Calling サービスに 次の 4 つの新しい IP サブネットが追加されました。

  • 23.89.76.128/25

  • 170.72.29.0/24

  • 170.72.17.128/25

  • 170.72.0.128/25

2021 年 4 月 2 日

[Webex Calling サービスのドメインと URL] で *.ciscospark.com を追加し、Webex アプリで Webex Calling の使用事例をサポートします。

2021 年 3 月 25 日

activate.cisco.com に 6 つの新しい IP 範囲が追加されました。これは 2021 年 5 月 8 日から有効になります。

  • 72.163.15.64/26

  • 72.163.15.128/26

  • 173.36.127.0/26

  • 173.36.127.128/26

  • 192.133.220.0/26

  • 192.133.220.64/26

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 デバイス) の簡素化された範囲に移動します。

activate.cisco.com

  • 72.163.10.125 -> 72.163.10.96/27

  • 173.37.149.125 -> 173.37.149.96/27

webapps.cisco.com

  • 173.37.146.134 -> 173.37.146.128/25

  • 72.163.10.134 -> 72.163.10.128/25

Cisco Webex クライアントは 2021 年 3 月にオーストラリアで新しい DNS SRV をポイントしているため、アプリケーション構成に次の IP アドレスを追加します。

  • 199.59.64.237

  • 199.59.67.237

2021 年 1 月 21 日

次の IP アドレスを、デバイス構成とファームウェア管理 (Cisco デバイス) に追加しました。

  • 3.134.166.179

  • 50.16.236.139

  • 54.145.130.71

  • 72.163.10.125

  • 72.163.24.0/23

  • 173.37.26.0/23

  • 173.37.146.134

デバイス構成とファームウェア管理 (Cisco デバイス) から次の IP アドレスを削除しました。

  • 35.172.26.181

  • 52.86.172.220

  • 52.203.31.41

次の IP アドレスをアプリケーション構成に追加しました。

  • 62.109.192.0/19

  • 64.68.96.0/19

  • 207.182.160.0/19

  • 150.253.128.0/17

次の IP アドレスをアプリケーション構成から削除しました。

  • 64.68.99.6

  • 64.68.100.6

アプリケーション構成から次のポート番号を削除しました。

  • 1081, 2208, 5222, 5280-5281, 52644-52645

次のドメインをアプリケーション構成に追加しました。

  • idbroker-b-us.webex.com

  • idbroker-eu.webex.com

  • ty6-wxt-jp.bcld.webex.com

  • os1-wxt-jp.bcld.webex.com

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 アドレスを使用して、通話シグナリングおよびメディア エントリを更新しました。

  • 139.177.64.0/24

  • 139.177.65.0/24

  • 139.177.66.0/24

  • 139.177.67.0/24

  • 139.177.68.0/24

  • 139.177.69.0/24

  • 139.177.70.0/24

  • 139.177.71.0/24

  • 139.177.72.0/24

  • 139.177.73.0/24

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 アドレスが追加されました。

  • Webex Calling への信号発信 (SRTP)—135.84.173.0/25、135.84.174.0/25、199.19.197.0/24、199.19.199.0/24

  • パブリックアドレスエンドポイントへのコールシグナリング（SIP TLS）:135.84.173.0/25、135.84.174.0/25、199.19.197.0/24、199.19.199.0/24。

  • デバイスの構成とファームウェアの管理 (Cisco デバイス) —135.84.173.155、135.84.174.155

  • デバイス時刻の同期—135.84.173.152、135.84.174.152

  • アプリケーションの構成—135.84.173.154、135.84.174.154

2020 年 7 月 22 日

カナダのデータセンターの導入をサポートするために、次の IP アドレスを追加しました。135.84.173.146

2020 年 6 月 9 日

CScan エントリに次の変更を行いました:

  • IP アドレスの 1 つを修正しました。199.59.67.156 から 199.59.64.156 に変更されました。

  • 新しい機能には、新しいポートと UDP（19560-19760）が必要です。

2020/03/11

次のドメインと IP アドレスをアプリケーション構成に追加しました。

  • jp.bcld.webex.com—135.84.169.150

  • client-jp.bcld.webex.com

  • idbroker.webex.com—64.68.99.6, 64.68.100.6

追加の IP アドレスを持つ以下のドメインをデバイスの設定とファームウェア管理に更新しました:

  • cisco.webexcalling.eu—85.119.56.198, 85.119.57.198

  • webapps.cisco.com—72.163.10.134

  • activation.webex.com—35.172.26.181, 52.86.172.220

  • cloudupgrader.webex.com—3.130.87.169, 3.20.185.219

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 で 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 メッセージの処理を提供し、それらを必要なターゲットにルーティングします。

PSTN から Webex Calling 構成ソリューションへのコール ルーティング

IP および SIP は PSTN トランクのデフォルトのプロトコルになっていますが、TDM (時間分割多重化) ISDN 回路は広く使用され、Webex Calling トランクでサポートされています。TDM-IP コール フローを持つローカル ゲートウェイの IP パスのメディア最適化を有効にするには、現在、2 レッグ コール ルーティング プロセスを使用する必要があります。このアプローチでは、下の画像に示すように、Webex Calling と PSTN トランク間に一連の内部ループバックダイヤルピアを導入することで、上記のコール ルーティング設定を変更します。

Webex Calling と PSTN トランク間の内部ループバックダイヤルピアのセットを使用したコール ルーティング設定

オンプレミスの Cisco Unified Communications Manager ソリューションを Webex Calling に接続する場合、以下の図に示すソリューションを構築するためのベースラインとして、シンプルな PSTN ゲートウェイ構成を使用できます。この場合、Unified Communications Manager は、すべての PSTN および Webex Calling コールのルーティングと処理を一元化します。

Unified Communications Manager がすべての PSTN および Webex Calling コールのルーティングと処理を一元化したソリューションダイアグラム

このドキュメントでは、次の画像に示すホスト名、IP アドレス、およびインターフェイスが使用されます。

コール ルーティング設定ソリューションで使用されるホスト名、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 インターフェイスに割り当てることを確認します。


interface GigabitEthernet0/0/0
  description Interface facing PSTN and/or CUCM
  ip address 10.80.13.12 255.255.255.0
!
interface GigabitEthernet0/0/1
  description Interface facing Webex Calling (Private address)
  ip address 192.51.100.1 255.255.255.240

2

対称暗号化を使用して、ルータの登録と STUN クレデンシャルを保護します。プライマリ暗号化キーと暗号化タイプを次のように設定します。


key config-key password-encrypt YourPassword
password encryption aes

3

プレースホルダー PKI トラストポイントを作成します。

後で TLS を設定するには、このトラストポイントが必要です。登録ベースのトランクの場合、このトラストポイントは証明書を必要としません。証明書ベースのトランクでも必須です。


crypto pki trustpoint EmptyTP 
 revocation-check none
4

TLS1.2 の排他性を有効にし、次の設定コマンドを使用してデフォルトのトラストポイントを指定します。トランスポート パラメータも更新して、登録の信頼性の高い安全な接続を確保する必要があります。

cn-san-validate サーバ コマンドにより、テナント 200 で設定されたホスト名がアウトバウンド プロキシから受信した証明書の CN または SAN フィールドに含まれている場合、ローカル ゲートウェイが接続を許可します。

  1. tcp-retry count を 1000 に設定します (5-msec multiples = 5 秒)。

  2. タイマー接続を確立する コマンドを使用すると、次に使用可能なオプションを考慮する前に、LGW がプロキシとの接続をセットアップするのを待つ時間を調整できます。このタイマーのデフォルトは 20 秒、最小は 5 秒です。低値で開始し、ネットワーク条件に対応するために必要に応じて増加します。


sip-ua
 timers connection establish tls 5
 transport tcp tls v1.2
 crypto signaling default trustpoint EmptyTP cn-san-validate server
 tcp-retry 1000

5

Webex Calling で使用される DigiCert CA 証明書を含む Cisco ルート CA バンドルをインストールします。crypto pki trustpool import clean url コマンドを使用して、指定された URL からルート CA バンドルをダウンロードし、現在の CA トラストプールをクリアし、証明書の新しいバンドルをインストールします。

HTTPS を使用してインターネットにアクセスするためにプロキシを使用する必要がある場合は、CA バンドルをインポートする前に次の設定を追加してください。

ip http クライアント プロキシ サーバ yourproxy.com プロキシ ポート 80

ip http client source-interface GigabitEthernet0/0/1 
crypto pki trustpool import clean url https://www.cisco.com/security/pki/trs/ios_core.p7b
Webex Calling 登録ベースのトランクを設定
1

Control Hub の既存のロケーションに対して登録ベースの PSTN トランクを作成します。トランクが作成されると、提供されたトランク情報をメモします。図でハイライトされている詳細は、このガイドの設定手順で使用されます。詳細については、「Webex Calling のトランク、ルート グループ、ダイヤル プランを構成する」を参照してください。

PSTN トランクが登録されました
2

次のコマンドを入力して、CUBE を Webex Calling ローカル ゲートウェイとして設定します。

 
voice service voip
 ip address trusted list
  ipv4 x.x.x.x y.y.y.y
 mode border-element
 media statistics
 media bulk-stats 
 allow-connections sip to sip
 no supplementary-service sip refer  
 stun
  stun flowdata agent-id 1 boot-count 4
  stun flowdata shared-secret 0 Password123$
 sip
  asymmetric payload full
  early-offer forced

以下は、設定のフィールドの説明です。


ip address trusted list
 ipv4 x.x.x.x y.y.y.y

  • 有料詐欺から保護するために、信頼できるアドレス リストは、ローカル ゲートウェイが合法的な VoIP コールを期待するホストとネットワークのリストを定義します。

  • デフォルトでは、ローカル ゲートウェイは、信頼リストに含まれていない IP アドレスからのすべての着信 VoIP メッセージをブロックします。デフォルトでは、「セッション ターゲット IP」またはサーバ グループ IP アドレスを持つ静的に設定されたダイヤル ピアが信頼されます。これらの IP アドレスを信頼リストに追加する必要はありません。

  • ローカル ゲートウェイを設定する場合は、地域の Webex Calling データ センターの IP サブネットをリストに追加します。詳細については、「Webex Calling のポート参照情報」を参照してください。また、Unified Communications Manager サーバ（使用されている場合）と PSTN トランク ゲートウェイのアドレス範囲を追加します。

    LGW が制限付きコーン NAT のあるファイアウォールの背後にある場合は、Webex Calling に面したインターフェイスの IP アドレスの信頼リストを無効にすることをおすすめします。ファイアウォールはすでに、未承諾のインバウンドメッセージから保護VoIP。[無効にする] アクションは、Webex Calling ピアのアドレスが固定されたままである保証を保証できないので、長期構成のオーバーヘッドを削減します。また、いかなる場合にも、ピアに対してファイアウォールを構成する必要があります。

モードの境界要素

プラットフォームで Cisco Unified Border Element（CUBE）機能を有効にします。

メディア統計

ローカル ゲートウェイ上のメディア監視が可能です。

メディア一括統計

一括通話統計のために、コントロール飛行機がデータ 飛行機をポーリングできます。

これらのコマンドの詳細については、メディアを参照してください。

allow-connections sip to sip

CUBE 基本 SIP バックツーバックのユーザー エージェント機能を有効にします。詳細については、「接続を許可する」を参照してください。

デフォルトでは、T.38 ファックス トランスポートが有効になっています。詳細については、ファックス プロトコル t38 (音声サービス) を参照してください。

ストーン

STUN (NAT 経由の UDP のセッション トラバーサル) をグローバルに有効にします。

  • ローカル ゲートウェイの STUN バインディング機能を使用すると、ネゴシエートされたメディア パスを介して、ローカルで生成された STUN 要求を送信できます。これにより、ファイアウォールのピンホールを開くことができます。

詳細については、stun flowdata agent-id および stun flowdata shared-secret を参照してください。

非対称ペイロード (フル)

DTMF と動的コーデック ペイロードの両方に対して SIP 非対称ペイロード サポートを設定します。詳細については、非対称ペイロードを参照してください。

early-offer forced

ローカル ゲートウェイが、隣接ピアからの確認応答を待つ代わりに、最初の INVITE メッセージで SDP 情報を送信するように強制します。このコマンドの詳細については、早期オファーを参照してください。

3

すべてのトランクに対して G.711 コーデックのみを許可する音声クラス コーデック 100 を設定します。このシンプルなアプローチは、ほとんどの導入に適しています。必要に応じて、発信元システムと終端システムの両方でサポートされている追加のコーデック タイプをリストに追加できます。

DSP モジュールを使用したトランスコーディング を含むより複雑なソリューションはサポートされていますが、このガイドには含まれていません。 


voice class codec 100
 codec preference 1 g711ulaw
 codec preference 2 g711alaw

以下は、設定のフィールドの説明です。

音声クラス コーデック 100

SIP トランク コールの優先コーデックのみを許可するために使用されます。詳細については、音声クラス コーデックを参照してください。

4

音声クラス stun-usage 100 を設定して、Webex Calling トランクで ICE を有効にします。


voice class stun-usage 100 
 stun usage firewall-traversal flowdata
 stun usage ice lite

以下は、設定のフィールドの説明です。

STUNの使用法ice lite

可能なときは常に、メディア最適化を可能にする、すべての Webex Calling でダイヤルピアで ICE-Lite を有効にします。詳細については、音声クラス stun 使用状況 および使用状況のice liteを参照してください。

メディアの最適化は、可能な限り、ネゴシエートされます。通話に録画などのクラウド メディア サービスが必要な場合、メディアを最適化できません。

5

Webex トラフィックのメディア暗号化ポリシーを設定します。


voice class srtp-crypto 100
 crypto 1 AES_CM_128_HMAC_SHA1_80

以下は、設定のフィールドの説明です。

音声クラス srtp-crypto 100

オファーと応答メッセージの SDP で唯一の SRTP 暗号スイート CUBE が提供されるため、SHA1_80 を指定します。Webex Calling は SHA1_80 のみをサポートします。詳細については、「voice class srtp-crypto」を参照してください。

6

宛先トランク パラメータに基づいて、ローカル ゲートウェイ トランクへのコールを識別するパターンを設定します。 


voice class uri 100 sip
 pattern dtg=dallas1463285401_lgu

以下は、設定のフィールドの説明です。

音声クラス uri 100 sip

着信 SIP 招待を着信トランクダイヤルピアに一致させるパターンを定義します。このパターンを入力する場合は、dtg= の後に、トランクが作成されたときに Control Hub で提供されるトランク OTG/DTG 値を使用します。詳細については、音声クラス uri を参照してください。

7

SIP メッセージが Webex Calling に送信される前に、変更するために使用される sip プロファイル 100 を構成します。


voice class sip-profiles 100
 rule 10 request ANY sip-header SIP-Req-URI modify "sips:" "sip:"
 rule 20 request ANY sip-header To modify "" "" 
 rule 50 response ANY sip-header To modify "" ";otg=dallas1463285401_lgu>"
 rule 90 request ANY sip-header P-Asserted-Identity modify "sips:" "sip:"

以下は、設定のフィールドの説明です。

  • ルール 10 ～ 70 および 90

    コール シグナリングに使用される SIP ヘッダーが、Webex プロキシが必要な SIP スキームではなく、SIP を使用するようにします。SIP を使用するために CUBE を設定することで、セキュアな登録が使用されます。

  • ルール 80

    エンタープライズ内のローカル ゲートウェイ サイトを一意に識別するために、Control Hub からトランク グループ OTG/DTG 識別子を含めるために、From ヘッダーを変更します。

米国またはカナダの PSTN プロバイダーは、Webex Calling のスパムまたは詐欺通話の表示 の記事で言及されている追加設定を使用して、スパムおよび詐欺通話の発信者 ID 検証を提供できます。

8

Webex Calling トランクの設定:

  1. 音声クラス テナント 100 を作成して、Webex Calling トランクに特別に必要な設定を定義し、グループ化します。特に、以前の Control Hub で提供されたトランク登録の詳細は、以下の詳細に従って、このステップで使用されます。このテナントに関連付けられているダイヤルピアは、後でこれらの設定を継承します。

    次の例では、ステップ 1 で説明されている値を、このガイドの目的で使用しています（太字で示されています）。設定内のトランクの値に置き換えます。

    
voice class tenant 100
  registrar dns:98027369.us10.bcld.webex.com scheme sips expires 240 refresh-ratio 50 tcp tls
  credentials number Dallas1171197921_LGU username Dallas1463285401_LGU password 0 9Wt[M6ifY+ realm BroadWorks
  authentication username Dallas1463285401_LGU password 0 9Wt[M6ifY+ realm BroadWorks
  authentication username Dallas1463285401_LGU password 0 9Wt[M6ifY+ realm 98027369.us10.bcld.webex.com
  no remote-party-id
  sip-server dns:98027369.us10.bcld.webex.com
  connection-reuse
  srtp-crypto 100
  session transport tcp tls 
  no session refresh
  url sips 
  error-passthru
  rel1xx disable
  asserted-id pai 
  bind control source-interface GigabitEthernet0/0/1
  bind media source-interface GigabitEthernet0/0/1
  no pass-thru content custom-sdp 
  sip-profiles 100 
  outbound-proxy dns:dfw04.sipconnect-us.bcld.webex.com  
  privacy-policy passthru

    以下は、設定のフィールドの説明です。

    音声クラス テナント 100

    Webex Calling トランクにのみ使用される設定パラメータのセットを定義します。詳細については、音声クラス テナントを参照してください。

    登録者 dns:98027369.us10.bcld.webex.com スキーム sips 有効期限 240 更新比 50 tcp tls

    ローカル ゲートウェイの登録サーバーで、2 分ごとに更新が設定されている場合 (240 秒の 50%)。詳細については、登録者を参照してください。

    ここから Control Hub から [ドメインの登録] の値を使用していることを確認します。

    資格情報番号 Dallas1171197921_LGU ユーザー名 Dallas1463285401_LGU パスワード 0 9Wt[M6ifY+ realm BroadWorks

    トランク登録認証の資格情報。詳細については、「資格情報 (SIP UA)」を参照してください。

    ここから Control Hub から回線/ポートホスト、認証ユーザ名、認証パスワードの値を使用していることを確認します。

    認証ユーザー名 Dallas1171197921_LGU パスワード 0 9Wt[M6ifY+ realm BroadWorks
    認証ユーザー名 Dallas1171197921_LGU パスワード 0 9Wt[M6ifY+ realm 98027369.us10.bcld.webex.com

    コールの認証の課題。詳細については、認証 (ダイヤルピア) を参照してください。

    ここから Control Hub から、認証ユーザ名、認証パスワード、および登録ドメインの値をそれぞれ使用していることを確認します。

    no remote-party-id

    Webex Calling が PAI をサポートしているため、SIP Remote-Party-ID (RPID) ヘッダーを無効にします。これは asserted-id pai を使用して有効になります。詳細については、remote-party-id を参照してください。

    sip サーバ dns: us25.sipconnect.bcld.webex.com

    トランクのターゲット SIP サーバを設定します。トランクを作成したときに、Control Hub で提供されたエッジ プロキシ SRV アドレスを使用します。

    connection-reuse

    登録と通話処理に同じ永続的な接続を使用します。詳細については、connection-reuse を参照してください。

    srtp-crypto 100

    SRTP コール レッグ（接続）の優先暗号スイートを設定します（手順で指定）5). 詳細については、「voice class srtp-crypto」を参照してください。

    session transport tcp tls

    TLS へのトランスポートを設定します。詳細については、session-transport を参照してください。

    セッションの更新がありません

    CUBE と Webex 間の通話の SIP セッション更新を無効にします。詳細については、セッションの更新を参照してください。

    url sips

    SRVは、アクセス SBC によりサポートされている SIP である必要があります。その他のすべてのメッセージは、sip-profile 200 により SIP に変更されます。

    error-passthru

    SIP エラー応答パススルー機能を指定します。詳細については、error-passthru を参照してください。

    rel1xx を無効にする

    Webex Calling トランクに対する信頼できる仮応答の使用を無効にします。詳細については、rel1xx を参照してください。

    asserted-id pai

    (オプション) P-Asserted-Identity ヘッダー処理をオンにし、これが Webex Calling トランクに使用する方法を制御します。

    Webex Calling には、ローカル ゲートウェイへの発信コール INVITE の P-Asserted-Identity (PAI) ヘッダーが含まれています。

    このコマンドが設定されている場合、PAI ヘッダーからの発信者情報を使用して、発信元および PAI/Remote-Party-ID ヘッダーに入力します。

    このコマンドが設定されていない場合、From ヘッダーの発信者情報を使用して、発信 From ヘッダーと PAI/Remote-Party-ID ヘッダーに入力します。

    詳細については、asserted-id を参照してください。

    bind control source-interface GigabitEthernet0/0/1

    Webex Calling に送信されるメッセージのソース インターフェイスと関連する IP アドレスを設定します。詳細については、バインドを参照してください。

    bind media source-interface GigabitEthernet0/0/1

    WebexCalling に送信されるメディアのソース インターフェイスと関連する IP アドレスを設定します。詳細については、バインドを参照してください。

    no pass-thru content custom-sdp

    テナントの下のデフォルト コマンド。このコマンドの詳細については、pass-thru content を参照してください。

    sip プロファイル 100

    sip-profile 100 で定義されているように、SIP を SIP に変更し、INVITE および REGISTER メッセージの回線/ポートを変更します。詳細については、音声クラス sip-profiles を参照してください。

    outbound-proxy dns:dfw04.sipconnect-us.bcld.webex.com

    Webex Calling SBC にアクセスします。トランクを作成したときに、Control Hub で提供されるアウトバウンド プロキシ アドレスを挿入します。詳細については、outbound-proxy を参照してください。

    privacy-policy passthru

    トランクが受信メッセージから次のコール レッグにプライバシー値を渡すようにプライバシー ヘッダー ポリシー オプションを設定します。詳細については、プライバシー ポリシーを参照してください。

  2. Webex Calling トランクのダイヤルピアを設定します。 

    
dial-peer voice 100 voip
 description Inbound/Outbound Webex Calling
 max-conn 250
 destination-pattern BAD.BAD
 session protocol sipv2
 session target sip-server
 incoming uri request 100
 voice-class codec 100
 dtmf-relay rtp-nte
 voice-class stun-usage 100
 no voice-class sip localhost
 voice-class sip tenant 100
 srtp
 no vad

    以下は、設定のフィールドの説明です。

    
dial-peer voice 100 voip
  description Inbound/Outbound Webex Calling

    100 VoIP ダイヤルピアを定義し、管理とトラブルシューティングを容易にするための意味のある説明を行います。

    max-conn 250

    LGW と Webex Calling の間の同時着信および発信通話の数を制限します。登録トランクの場合、設定された最大値は 250 である必要があります。展開に適切であれば、ユーザの値を下げます。ローカル ゲートウェイの同時通話制限の詳細については、「ローカル ゲートウェイの使用を開始する 」ドキュメントを参照してください。

    宛先パターン BAD.BAD

    着信ダイヤルピア グループを使用して発信コールをルーティングする場合は、ダミー通知先パターンが必要です。この場合、有効な宛先パターンを使用できます。詳細については、「destination-pattern (interface)」を参照してください。

    session protocol sipv2

    ダイヤルピア 100 が SIP コール のコールコールを処理する場合に指定します。詳細については、セッション プロトコル (ダイヤルピア) を参照してください。

    session target sip-server

    テナント 100 で定義された SIP サーバが継承され、このダイヤル ピアからのコールの宛先に使用されることを示します。詳細については、セッション ターゲット (VoIP ダイヤル ピア) を参照してください。

    着信 uri リクエスト 100

    VoIP ダイヤル ピアと着信コールの Uniform Resource Identifier（URI）を照合するために使用される音声クラスを指定します。詳細については、着信 uri を参照してください。

    音声クラスのコーデック 100

    共通のコーデック フィルタ リスト 100 を使用するようにダイヤル ピアを設定します。詳細については、音声クラス コーデックを参照してください。

    音声クラス 使用量

    ローカル ゲートウェイでローカルで生成された STUN 要求が、ネゴシエートされたメディア パスを介して送信されるようにします。STUN は、メディア トラフィック用のファイアウォール ピンホールを開くのに役立ちます。

    no voice-class sip localhost

    送信メッセージの物理的 IP アドレスの代用として、From、Call-ID、Remote-Party-ID ヘッダーの DNS ローカル ホスト名の代入を無効にします。

    voice-class SIP テナント 100

    ダイヤル ピアは、グローバルおよびテナント 100 で設定されたすべてのパラメータを継承します。パラメータは、ダイヤルピア レベルでオーバーライドされる場合があります。

    srtp

    コールレグの SRTP を有効にする。

    no vad

    音声アクティブティの検出を無効にします。

テナント 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 トランクを使用したローカル ゲートウェイの設定

上記で Webex Calling に対してトランクを構築した場合、以下の構成を使用して、SIP ベースの PSTN プロバイダーに対して暗号化されていないトランクを作成します。

サービス プロバイダーがセキュアな PSTN トランクを提供している場合、Webex Calling トランクの上記と同様の設定に従う場合があります。CUBE はセキュアなコール ルーティングをサポートします。

TDM / ISDN PSTN トランクを使用している場合は、次のセクション [TDM PSTN トランクでローカル ゲートウェイを設定する] に進みます。

Cisco TDM-SIP ゲートウェイの PSTN コール レッグの TDM インターフェイスを設定するには、「ISDN PRI の構成」を参照してください。

1

PSTN トランクからの着信コールを識別するために、次の音声クラス uri を設定します。


voice class uri 200 sip
  host ipv4:192.168.80.13

以下は、設定のフィールドの説明です。

音声クラス uri 200 sip

着信 SIP 招待を着信トランクダイヤルピアに一致させるパターンを定義します。このパターンを入力する場合は、IP PSTN ゲートウェイの IP アドレスを使用します。詳細については、音声クラス uri を参照してください。

2

次の IP PSTN ダイヤル ピアを設定します。


dial-peer voice 200 voip
 description Inbound/Outbound IP PSTN trunk
 destination-pattern BAD.BAD
 session protocol sipv2
 session target ipv4:192.168.80.13
 incoming uri via 200
 voice-class sip asserted-id pai
 voice-class sip bind control source-interface GigabitEthernet0/0/0 
 voice-class sip bind media source-interface  GigabitEthernet0/0/0 
 voice-class codec 100
 dtmf-relay rtp-nte 
 no vad

以下は、設定のフィールドの説明です。


dial-peer voice 200 voip
 description Inbound/Outbound IP PSTN trunk

タグ 200 で VoIP ダイヤルピアを定義し、管理とトラブルシューティングを容易にする意味のある説明を提供します。詳細については、ダイヤルピアの音声を参照してください。

宛先パターン BAD.BAD

着信ダイヤルピア グループを使用して発信コールをルーティングする場合は、ダミー通知先パターンが必要です。この場合、有効な宛先パターンを使用できます。詳細については、「destination-pattern (interface)」を参照してください。

session protocol sipv2

このダイヤル ピアが SIP コール レッグを処理するように指定します。詳細については、セッション プロトコル (ダイヤル ピア) を参照してください。

セッション ターゲット ipv4: 192.168.80.13

PSTN プロバイダーに送信されるコールのターゲット アドレスを指定します。これは IP アドレスまたは DNS ホスト名です。詳細については、セッション ターゲット (VoIP ダイヤル ピア) を参照してください。

200 経由の着信 uri

INVITE 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/0

PSTN に送信されるメディアのソース インターフェイスと関連する IP アドレスを設定します。詳細については、バインドを参照してください。

音声クラスのコーデック 100

共通のコーデック フィルタ リスト 100 を使用するようにダイヤル ピアを設定します。詳細については、音声クラス コーデックを参照してください。

dtmf-relay rtp-nte

通話レグで予想される DTMF 機能として RTP-NTE (RFC2833) を定義します。詳細については、「DTMF リレー (音声オーバー IP)」を参照してください。

no vad

音声アクティブティの検出を無効にします。詳細については、vad (ダイヤル ピア) を参照してください。

3

ローカル ゲートウェイを Webex Calling と PSTN 間のコールのみをルーティングするように設定している場合は、次のコール ルーティング設定を追加します。Unified Communications Manager プラットフォームを使用してローカル ゲートウェイを設定する場合は、次のセクションに進みます。

  1. ダイヤルピア グループを作成して、Webex Calling または PSTN にコールをルーティングします。Webex Calling 向け発信ダイヤルピア 100 で DPG 100 を定義します。DPG 100 は、PSTN からの着信ダイヤルピアに適用されます。同様に、PSTN に向けて発信ダイヤルピア 200 を使用して DPG 200 を定義します。DPG 200 は、Webex からの着信ダイヤルピアに適用されます。

    
voice class dpg 100 
 description Route calls to Webex Calling 
 dial-peer 100 
voice class dpg 200 
 description Route calls to PSTN 
 dial-peer 200

    以下は、設定のフィールドの説明です。

    ダイヤルピア 100

    発信ダイヤルピアをダイヤルピア グループに関連付けます。詳細については、voice-class dpg を参照してください。

  2. ダイヤルピア グループを適用して、Webex から PSTN および PSTN から Webex に通話をルーティングします。 

    
dial-peer voice 100
 destination dpg 200
dial-peer voice 200
 destination dpg 100

    以下は、設定のフィールドの説明です。

    宛先 dpg 200

    どのダイヤルピア グループを指定し、この着信ダイヤルピアに提示されるコールのアウトバウンド処理に使用するかを指定します。

    これにより、ローカル ゲートウェイの設定が終了します。CUBE 機能が初めて設定される場合は、設定を保存し、プラットフォームを再読み込みします。

TDM PSTN トランクを使用したローカル ゲートウェイの設定

Webex Calling に向かってトランクを構築した後、次の設定を使用して、ループバック コール ルーティングを持つ PSTN サービスの TDM トランクを作成し、Webex コール レッグのメディア最適化を可能にします。

IP メディアの最適化を必要としない場合は、SIP PSTN トランクの設定手順に従います。PSTN VoIP ダイヤルピアの代わりに、音声ポートと POTS ダイヤルピア（ステップ 2 と 3 に示すように）を使用します。

1

ループバック ダイヤル ピア設定では、ダイヤル ピア グループとコール ルーティング タグを使用して、コール ルーティング ループを作成することなく、コールが Webex と PSTN の間で正しくパスされるようにします。コール ルーティング タグを追加および削除するために使用される次のトランスレーション ルールを設定します。


voice translation-rule 100 
 rule 1 /^\+/ /A2A/ 

voice translation-profile 100 
 translate called 100 

voice translation-rule 200 
 rule 1 /^/ /A1A/ 

voice translation-profile 200 
 translate called 200 

voice translation-rule 11 
 rule 1 /^A1A/ // 

voice translation-profile 11 
 translate called 11 

voice translation-rule 12 
 rule 1 /^A2A44/ /0/
 rule 2/^A2A/ /00/

voice translation-profile 12 
 translate called 12

以下は、設定のフィールドの説明です。

音声翻訳ルール

ルールで定義された正規表現を使用して、コール ルーティング タグを追加または削除します。十進法を超える数字（「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 インターフェイスの基本設定には、以下が含まれる場合があります。


card type e1 0 2 
isdn switch-type primary-net5 
controller E1 0/2/0 
 pri-group timeslots 1-31
3

次の TDM PSTN ダイヤル ピアを設定します。


dial-peer voice 200 pots 
 description Inbound/Outbound PRI PSTN trunk 
 destination-pattern BAD.BAD 
 translation-profile incoming 200 
 direct-inward-dial 
 port 0/2/0:15

以下は、設定のフィールドの説明です。 


dial-peer voice 200 pots
 description Inbound/Outbound PRI PSTN trunk

タグ 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 にルーティングされます。ルーティング タグを削除した後、コールはダイヤルピア グループを使用して発信トランクにルーティングされます。


dial-peer voice 10 voip
 description Outbound loop-around leg
 destination-pattern BAD.BAD
 session protocol sipv2
 session target ipv4:192.168.80.14
 voice-class sip bind control source-interface GigabitEthernet0/0/0
 voice-class sip bind media source-interface GigabitEthernet0/0/0
 dtmf-relay rtp-nte
 codec g711alaw
 no vad 

dial-peer voice 11 voip
 description Inbound loop-around leg towards Webex
 translation-profile incoming 11
 session protocol sipv2
 incoming called-number A1AT
 voice-class sip bind control source-interface GigabitEthernet0/0/0
 voice-class sip bind media source-interface GigabitEthernet0/0/0
 dtmf-relay rtp-nte
 codec g711alaw
 no vad 

dial-peer voice 12 voip
 description Inbound loop-around leg towards PSTN
 translation-profile incoming 12
 session protocol sipv2
 incoming called-number A2AT
 voice-class sip bind control source-interface GigabitEthernet0/0/0
 voice-class sip bind media source-interface GigabitEthernet0/0/0
 dtmf-relay rtp-nte
 codec g711alaw 
 no vad

以下は、設定のフィールドの説明です。 


dial-peer voice 10 voip
 description Outbound loop-around leg

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

次のコール ルーティング設定を追加します。

  1. ダイヤルピア グループを作成して、ループバック経由で PSTN と Webex トランク間のコールをルーティングします。

    
voice class dpg 100
 description Route calls to Webex Calling
 dial-peer 100
voice class dpg 200
 description Route calls to PSTN
 dial-peer 200
voice class dpg 10
 description Route calls to Loopback
 dial-peer 10

    以下は、設定のフィールドの説明です。

    ダイヤルピア 100

    発信ダイヤルピアをダイヤルピア グループに関連付けます。詳細については、voice-class dpg を参照してください。

  2. ダイヤル ピア グループを適用して通話をルーティングします。

    
dial-peer voice 100
 destination dpg 10
dial-peer voice 200
 destination dpg 10
dial-peer voice 11
 destination dpg 100
dial-peer voice 12
 destination dpg 200

    以下は、設定のフィールドの説明です。

    宛先 dpg 200

    どのダイヤルピア グループを指定し、この着信ダイヤルピアに提示されるコールのアウトバウンド処理に使用するかを指定します。

これにより、ローカル ゲートウェイの設定が終了します。CUBE 機能が初めて設定される場合は、設定を保存し、プラットフォームを再読み込みします。
ローカル ゲートウェイを既存の Unified CM 環境で構成する

前のセクションの 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 ヘッダーにこの値を入力できます。

SIP トランク セキュリティ プロファイル情報を入力
1

以下の音声クラス URI を設定:

  1. ポート経由の SIP を使用して、Unified CM から Webex 通話を分類します。

    
voice class uri 300 sip
 pattern :5065

  2. ポート経由の SIP を使用して、Unified CM から PSTN コールを分類します。

    
voice class uri 400 sip
 pattern 192\.168\.80\.6[0-5]:5060

    発信元のアドレスとポート番号を記述した 1 つ以上のパターンを使用して、UCM からの着信メッセージを PSTN トランクに分類します。必要に応じて、正規表現を使用して、一致するパターンを定義することができます。

    上記の例では、192.168.80.60 ～ 65 およびポート番号 5060 の任意の IP アドレスに正規表現が使用されます。

2

Unified CM ホストへの SRV ルーティングを指定するには、次の DNS レコードを設定します。

IOS XE は、ターゲット UCM ホストとポートをローカルで判別するためにこれらのレコードを使用します。この設定では、DNS システムでレコードを設定する必要はありません。DNS を使用する場合は、これらのローカル設定は必要ありません。


ip host ucmpub.mydomain.com 192.168.80.60
ip host ucmsub1.mydomain.com 192.168.80.61
ip host ucmsub2.mydomain.com 192.168.80.62
ip host ucmsub3.mydomain.com 192.168.80.63
ip host ucmsub4.mydomain.com 192.168.80.64
ip host ucmsub5.mydomain.com 192.168.80.65
ip host _sip._udp.wxtocucm.io srv 0 1 5065 ucmpub.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub1.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub2.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub3.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub4.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub5.mydomain.com
ip host _sip._udp.pstntocucm.io srv 0 1 5060 ucmpub.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub1.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub2.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub3.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub4.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub5.mydomain.com

以下は、設定のフィールドの説明です。

次のコマンドにより、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

次のダイヤル ピアを設定します。

  1. Unified CM と Webex Calling 間の通話のダイヤル ピア:

    
dial-peer voice 300 voip
 description UCM-Webex Calling trunk
 destination-pattern BAD.BAD
 session protocol sipv2
 session target dns:wxtocucm.io
 incoming uri via 300
 voice-class codec 100
 voice-class sip bind control source-interface GigabitEthernet 0/0/0
 voice-class sip bind media source-interface GigabitEthernet 0/0/0
 dtmf-relay rtp-nte
 no vad

    以下は、設定のフィールドの説明です。

    
dial-peer voice 300 voip
 description UCM-Webex Calling trunk

    タグ 300 で VoIP ダイヤルピアを定義し、管理とトラブルシューティングを容易にする意味のある説明を提供します。

    destination-pattern BAD.BAD

    着信ダイヤルピア グループを使用して発信コールをルーティングする場合は、ダミー通知先パターンが必要です。この場合、有効な宛先パターンを使用できます。

    session protocol sipv2

    ダイヤルピア 300 が SIP コール レッグを処理するように指定します。詳細については、セッション プロトコル (ダイヤルピア) を参照してください。

    セッション ターゲット dns:wxtocucm.io

    DNS SRV 解決により複数の Unified CM ノードのセッション ターゲットを定義します。この場合、ローカルで定義された SRV レコード wxtocucm.io がコールを転送するために使用されます。

    incoming uri via 300

    音声クラス URI 300 を使用して、ソース ポート 5065 を使用して、Unified CM からすべての着信トラフィックをこのダイヤルピアに誘導します。詳細については、着信 uri を参照してください。

    音声クラスのコーデック 100

    Unified CM 間のコールのコーデック フィルタ リストを示します。詳細については、音声クラス コーデックを参照してください。

    bind control source-interface GigabitEthernet0/0/0

    PSTN に送信されるメッセージのソース インターフェイスと関連する IP アドレスを設定します。詳細については、バインドを参照してください。

    bind media source-interface GigabitEthernet0/0/0

    PSTN に送信されるメディアのソース インターフェイスと関連する IP アドレスを設定します。詳細については、バインドを参照してください。

    dtmf-relay rtp-nte

    通話レグで予想される DTMF 機能として RTP-NTE (RFC2833) を定義します。詳細については、「DTMF リレー (音声オーバー IP)」を参照してください。

    no vad

    音声アクティブティの検出を無効にします。詳細については、vad (ダイヤル ピア) を参照してください。

  2. Unified CM と PSTN 間の通話のダイヤル ピア:

    
dial-peer voice 400 voip
 description UCM-PSTN trunk
 destination-pattern BAD.BAD
 session protocol sipv2
 session target dns:pstntocucm.io
 incoming uri via 400
 voice-class codec 100 
 voice-class sip bind control source-interface GigabitEthernet 0/0/0
 voice-class sip bind media source-interface GigabitEthernet 0/0/0
 dtmf-relay rtp-nte
 no vad

    以下は、設定のフィールドの説明です。

    
dial-peer voice 400 voip
 description UCM-PSTN trunk

    タグ 400 で VoIP ダイヤルピアを定義し、管理とトラブルシューティングを容易にする意味のある説明を提供します。

    destination-pattern BAD.BAD

    着信ダイヤルピア グループを使用して発信コールをルーティングする場合は、ダミー通知先パターンが必要です。この場合、有効な宛先パターンを使用できます。

    session protocol sipv2

    ダイヤルピア 400 が SIP コール レッグを処理するように指定します。詳細については、セッション プロトコル (ダイヤルピア) を参照してください。

    セッションターゲット dns:pstntocucm.io

    DNS SRV 解決により複数の Unified CM ノードのセッション ターゲットを定義します。この場合、ローカルで定義された SRV レコード pstntocucm.io がコールを転送するために使用されます。

    400 経由の着信 uri

    音声クラス URI 400 を使用して、ソース ポート 5060 を使用して指定された Unified CM ホストからのすべての着信トラフィックをこのダイヤルピアに誘導します。詳細については、着信 uri を参照してください。

    音声クラスのコーデック 100

    Unified CM 間のコールのコーデック フィルタ リストを示します。詳細については、音声クラス コーデックを参照してください。

    bind control source-interface GigabitEthernet0/0/0

    PSTN に送信されるメッセージのソース インターフェイスと関連する IP アドレスを設定します。詳細については、バインドを参照してください。

    bind media source-interface GigabitEthernet0/0/0

    PSTN に送信されるメディアのソース インターフェイスと関連する IP アドレスを設定します。詳細については、バインドを参照してください。

    dtmf-relay rtp-nte

    通話レグで予想される DTMF 機能として RTP-NTE (RFC2833) を定義します。詳細については、「DTMF リレー (音声オーバー IP)」を参照してください。

    no vad

    音声アクティブティの検出を無効にします。詳細については、vad (ダイヤル ピア) を参照してください。

4

次の設定を使用してコール ルーティングを追加します。

  1. ダイヤルピア グループを作成し、Unified CM と Webex Calling の間でコールをルーティングします。DPG 100 を 発信ダイヤルピア 100 で Webex Calling に対して定義します。DPG 100 は、Unified CM からの関連付けられた着信ダイヤルピアに適用されます。同様に、Unified CM に対して発信ダイヤルピア 300 を使用して DPG 300 を定義します。DPG 300 は、Webex からの着信ダイヤルピアに適用されます。

    
voice class dpg 100
 description Route calls to Webex Calling
 dial-peer 100
voice class dpg 300
 description Route calls to Unified CM Webex Calling trunk
 dial-peer 300

  2. Unified CM と PSTN の間でコールをルーティングするためのダイヤル ピア グループを作成します。PSTN に対して発信ダイヤルピア 200 で DPG 200 を定義します。DPG 200 は、Unified CM から関連する着信ダイヤルピアに適用されます。同様に、Unified CM に対して発信ダイヤルピア 400 を使用して DPG 400 を定義します。DPG 400 は、PSTN からの着信ダイヤルピアに適用されます。

    
voice class dpg 200
 description Route calls to PSTN
 dial-peer 200
voice class dpg 400
 description Route calls to Unified CM PSTN trunk
 dial-peer 400

    以下は、設定のフィールドの説明です。

    ダイヤルピア 100

    発信ダイヤルピアをダイヤルピア グループに関連付けます。詳細については、voice-class dpg を参照してください。

  3. ダイヤルピア グループを適用して、Webex から Unified CM および Unified CM から Webex に通話をルーティングします。 

    
dial-peer voice 100
 destination dpg 300
dial-peer voice 300
 destination dpg 100

    以下は、設定のフィールドの説明です。

    宛先 dpg 300

    どのダイヤルピア グループを指定し、この着信ダイヤルピアに提示されるコールのアウトバウンド処理に使用するかを指定します。

  4. ダイヤルピア グループを適用して、PSTN から Unified CM から Unified CM から PSTN に通話をルーティングします。

    
dial-peer voice 200
 destination dpg 400
dial-peer voice 400
 destination dpg 200

    これにより、ローカル ゲートウェイの設定が終了します。CUBE 機能が初めて設定されている場合、設定を保存し、プラットフォームを再読み込みします。

診断署名でローカル ゲートウェイを監視し、トラブルシューティングする

診断署名 (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 以降を実行しているローカル ゲートウェイ

  1. 診断署名はデフォルトで有効になっています。

  2. デバイスが Cisco IOS XE 17.6.1a 以降を実行している場合、プロアクティブ通知を送信するために使用されるセキュアなメール サーバを設定します。

    configure terminal 
call-home  
mail-server :@ priority 1 secure tls 
end

  3. 通知する管理者のメール アドレスでds_email 環境変数を設定します。 

    configure terminal 
call-home  
diagnostic-signature 
environment ds_email  
end

以下は、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 priority 1 secure tls 
diagnostic-signature 
environment ds_email "tacfaststart@gmail.com"

Cisco IOS XE ソフトウェアで起動するローカル ゲートウェイは OAuth に対応する一般的なウェブベースの Gmail クライアントではないので、特定の Gmail アカウント設定を行い、端末からメールを正しく処理するための権限を与える必要があります:

  1. [Google アカウントの管理] > [セキュリティ] に移動し、[安全性の低いアプリ アクセス] 設定をオンにします。

  2. 「はい、はい、それは私です」と答えます。Gmail から「Google は、Google 以外のアプリを使用してアカウントにサインインするユーザーを防ぎました」というメールを受け取ります。

プロアクティブ モニタリングのために診断署名をインストールする

CPU 使用率の監視

この DS は、SNMP OID を使用して 5 秒間 CPU 使用率を追跡します。1.3.6.1.4.1.9.2.1.56. 使用率が 75% 以上に達すると、すべてのデバッグを無効にし、ローカル ゲートウェイにインストールされている診断署名をアンインストールします。下記の手順を実行して署名をインストールします。

  1. show snmp コマンドを使用して、SNMP を有効にします。有効にしない場合は、snmp-server manager コマンドを設定します。

    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

  2. Diagnostic Signatures Lookup Tool の以下のドロップダウンオプションを使用して、DS 64224 をダウンロードします。

    フィールド名

    フィールド値

    プラットフォーム

    Cisco 4300、4400 ISR シリーズまたは Cisco CSR 1000V シリーズ

    製品

    Webex Calling ソリューションの CUBE Enterprise

    問題の範囲

    パフォーマンス

    問題の種類

    通知メールによる CPU 使用率が高い

  3. DS XML ファイルをローカルゲートウェイフラッシュにコピーします。

    LocalGateway# copy ftp://username:password@/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)

  4. ローカルゲートウェイに DS XML ファイルをインストールします。

    call-home diagnostic-signature load DS_64224.xml 
Load file DS_64224.xml success

  5. 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 がアンインストールされます。必要に応じて、DS 64224 を再インストールして、ローカル ゲートウェイの高い CPU 使用率のモニタリングを続行します。

SIP トランク登録のモニタリング

この DS は、60 秒ごとにクラウドにSIP トランクするローカル Webex Calling登録解除をチェックします。登録解除イベントが検出されると、メールと syslog の通知が生成され、2 回の登録解除後に自動的にアンインストールされます。署名をインストールするには、以下の手順を使用します。

  1. Diagnostic Signatures Lookup Tool の以下のドロップダウンオプションを使用して、DS 64117 をダウンロードします。

    フィールド名

    フィールド値

    プラットフォーム

    Cisco 4300、4400 ISR シリーズ、または Cisco CSR 1000V シリーズ

    製品

    Webex Calling ソリューションの CUBE Enterprise

    問題の範囲

    SIP-SIP

    問題の種類

    SIP トランクによる登録解除を行いました。

  2. DS XML ファイルをローカルゲートウェイにコピーします。

    copy ftp://username:password@/DS_64117.xml bootflash:

  3. ローカルゲートウェイに DS XML ファイルをインストールします。 

    call-home diagnostic-signature load DS_64117.xml 
Load file DS_64117.xml success 
LocalGateway#

  4. show call-home diagnostic-signature コマンドを使用 して、署名が正常にインストールされたことを確認します。状態の列には「登録済み」の値が必要です。

異常な通話切断の監視

この DS は、10 分ごとに SNMP ポーリングを使用して、SIP エラーの 403、488、503 で異常な通話切断を検出します。 エラーカウントの増分が最後の投票から 5 以上である場合、syslog とメール通知が生成されます。 署名をインストールするには、以下の手順を使用してください。

  1. show snmp コマンドを使用して、SNMP が有効かどうかを確認します。有効になっていない場合は、snmp-server manager コマンドを設定します。 

    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

  2. Diagnostic Signatures Lookup Tool の以下のオプションを使用して、DS 65221 をダウンロードします。

    フィールド名

    フィールド値

    プラットフォーム

    Cisco 4300、4400 ISR シリーズ、または Cisco CSR 1000V シリーズ

    製品

    Webex Calling ソリューションの CUBE Enterprise

    問題の範囲

    パフォーマンス

    問題の種類

    メールおよび Syslog 通知による SIP の異常通話切断検出

  3. DS XML ファイルをローカルゲートウェイにコピーします。 

    copy ftp://username:password@/DS_65221.xml bootflash:

  4. ローカルゲートウェイに DS XML ファイルをインストールします。 

    call-home diagnostic-signature load DS_65221.xml 
Load file DS_65221.xml success

  5. 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 を使用して、以下の手順を使用して、診断データの収集を自動化します。

  1. 収集された診断データがアップロードされる 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://:@cxd.cisco.com"  
end

    例： 

    call-home  
diagnostic-signature 
environment ds_fsurl_prefix " environment ds_fsurl_prefix "scp://612345678:abcdefghijklmnop@cxd.cisco.com"

  2. show snmp コマンドを使用して、SNMP が有効になっていることを確認します。有効になっていない場合は、snmp-server manager コマンドを設定します。

    show snmp 
%SNMP agent not enabled 
 
 
config t 
snmp-server manager 
end

  3. 高 CPU 使用率の期間中に、すべてのデバッグと診断署名を無効にするためのプロアクティブな措置として、高 CPU モニタリング DS 64224 をインストールしてください。Diagnostic Signatures Lookup Tool の以下のオプションを使用して、DS 64224 をダウンロードします。

    フィールド名

    フィールド値

    プラットフォーム

    Cisco 4300、4400 ISR シリーズ、または Cisco CSR 1000V シリーズ

    製品

    Webex Calling ソリューションの CUBE Enterprise

    問題の範囲

    パフォーマンス

    問題の種類

    通知メールによる CPU 使用率が高い

  4. 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

  5. DS XML ファイルをローカルゲートウェイにコピーします。

    copy ftp://username:password@/DS_64224.xml bootflash: 
copy ftp://username:password@/DS_65095.xml bootflash:

  6. ローカルゲートウェイに、高 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

  7. 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 
           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  
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 名

トリガー済み/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 deinstall

例:

call-home diagnostic-signature deinstall 64224

診断署名検索ツールに定期的に新しい署名が追加されます。これは展開で一般的に見られる問題に基づいて行います。TAC では現在、新しいカスタム署名の作成リクエストをサポートしていません。

Control Hub を介した Cisco IOS XE ゲートウェイの管理と検証

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 メッセージの処理を提供し、それらを必要なターゲットにルーティングします。

PSTN から Webex Calling 構成ソリューションへのコール ルーティング

オンプレミスの Cisco Unified Communications Manager ソリューションを Webex Calling に接続する場合、以下の図に示すソリューションを構築するためのベースラインとして、シンプルな PSTN ゲートウェイ構成を使用できます。この場合、Unified Communications Manager は、すべての PSTN および Webex Calling コールのルーティングと処理を一元化します。

Unified Communications Manager がすべての PSTN および Webex Calling コールのルーティングと処理を一元化したソリューションダイアグラム

このドキュメントでは、次の画像に示すホスト名、IP アドレス、およびインターフェイスが使用されます。オプションは、パブリックアドレスまたはプライベート（NAT の背後）アドレス指定用に提供されます。複数の CUBE インスタンス間でロード バランシングしない限り、SRV DNS レコードはオプションです。

証明書ベースのローカル ゲートウェイの設定で使用されるホスト名、IP アドレス、およびインターフェイス

このドキュメントの残りの構成ガイダンスを使用して、次のようにローカル ゲートウェイの設定を完了します。

接続とセキュリティを設定

ベースライン設定

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 インターフェイスに割り当てることを確認します。


interface GigabitEthernet0/0/0
 description Interface facing PSTN and/or CUCM
 ip address 192.168.80.14 255.255.255.0
!
interface GigabitEthernet0/0/1
 description Interface facing Webex Calling (Public address)
 ip address 198.51.100.1 255.255.255.240

2

対称暗号化を使用して、ルータの STUN クレデンシャルを保護します。プライマリ暗号化キーと暗号化タイプを次のように設定します。


key config-key password-encrypt YourPassword
password encryption aes
3

サポートされている 証明機関 (CA) によって署名されたドメインの証明書を使用して暗号化トラストポイントを作成します。

  1. 次の exec コマンドを使用して RSA 鍵ペアを作成します。

    crypto key generate rsa general-keys exportable label lgw-key modulus 4096

  2. 次の設定コマンドを使用して、証明書のトラストポイントを作成し、証明書署名要求で使用するフィールド値を指定します。 

    
crypto pki trustpoint LGW_CERT
 enrollment terminal pem
 fqdn none
 subject-name cn=cube1.lgw.com
 subject-alt-name cube1.lgw.com
 revocation-check none
 rsakeypair lgw-key
 hash sha256

    証明書フィールドのノート:

    • fqdn: これは Webex Calling の必須フィールドではありません。この設定を [なし] に設定すると、証明書署名要求に含まれないことを確認します。このコマンドを使用して FQDN を含める必要がある場合、ローカル ゲートウェイの操作には影響しません。

    • 件名: ローカル ゲートウェイからのコールを検証するには、Webex は SIP 連絡先ヘッダーの FQDN と SBC 証明書のサブジェクト共通名 (CN) 属性または SAN フィールドに含まれるサブジェクト代替名 (SAN) フィールドのいずれかに一致する必要があります。したがって、件名フィールドには少なくとも CN 属性を含める必要がありますが、必要に応じて、他の属性を含めることもできます。詳細については、件名を参照してください。

    • subject-alt-name: SBC 証明書のサブジェクト代替名（SAN）フィールドには、追加の FQDN のリストを含めることができます。証明書の件名 CN 属性が一致しない場合、WEBEX はこのリストをチェックして、ローカル ゲートウェイからのメッセージの SIP 連絡先ヘッダーを検証します。

    • ハッシュ: CSR は SHA256 を使用して署名することを強く推奨します。このアルゴリズムは、Cisco IOS XE 17.11.1 からデフォルトで使用され、以前のリリースでこのコマンドを使用して明示的に設定する必要があります。

  3. 次の exec または設定コマンドで証明書署名リクエスト（CSR）を生成し、サポートされている CA プロバイダーから署名付き証明書を要求するために使用します。

    crypto pki enroll LGW_CERT

4

ホスト証明書の認証に使用される中間署名 CA の証明書を提供します。次の exec または configuration コマンドを入力します。


crypto pki authenticate LGW_CERT

5

次の exec または設定コマンドを使用して、署名付きホスト証明書をインポートします。


crypto pki import LGW_CERT certificate

6

TLS1.2 の排他性を有効にし、次の設定コマンドを使用して、音声アプリケーションに使用するデフォルトのトラストポイントを指定します。


 sip-ua
  crypto signaling default trustpoint LGW_CERT
  transport tcp tls v1.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

ip http client source-interface GigabitEthernet0/0/1 
crypto pki trustpool import clean url https://www.cisco.com/security/pki/trs/ios_core.p7b
Webex Calling 証明書ベースのトランクを設定
1

Control Hub の既存のロケーションに対して CUBE 証明書ベースの PSTN トランクを作成します。詳細については、「Webex Calling のトランク、ルート グループ、ダイヤル プランを構成する」を参照してください。

トランクが作成されると、提供されたトランク情報をメモします。以下の図でハイライトされているこれらの詳細は、このガイドの設定手順で使用されます。

CUBE 証明書ベースの PSTN トランクが作成されます
2

次のコマンドを入力して、CUBE を Webex Calling ローカル ゲートウェイとして設定します。


voice service voip
 ip address trusted list
  ipv4 x.x.x.x y.y.y.y
 mode border-element
 allow-connections sip to sip
 no supplementary-service sip refer
 stun
  stun flowdata agent-id 1 boot-count 4
  stun flowdata shared-secret 0 Password123$
 sip 
  asymmetric payload full
  early-offer forced
  sip-profiles inbound

以下は、設定のフィールドの説明です。


ip address trusted list
 ipv4 x.x.x.x y.y.y.y

  • 有料詐欺から保護するために、信頼できるアドレス リストは、ローカル ゲートウェイが合法的な VoIP コールを期待するホストとネットワークエンティティのリストを定義します。

  • デフォルトでは、ローカル ゲートウェイは、信頼リストに含まれていない IP アドレスからのすべての着信 VoIP メッセージをブロックします。デフォルトでは、「セッション ターゲット IP」またはサーバ グループ IP アドレスを持つ静的に設定されたダイヤル ピアが信頼されます。これらの IP アドレスを信頼リストに追加する必要はありません。

  • ローカル ゲートウェイを設定するときに、地域の Webex Calling データ センターの IP サブネットをリストに追加します。詳細については、「Webex Calling のポート参照情報 」を参照してください。また、Unified Communications Manager サーバ（使用されている場合）と PSTN トランク ゲートウェイのアドレス範囲を追加します。

  • 料金詐欺を防ぐために IP アドレス信頼リストを使用する方法の詳細については、「信頼された IP アドレス」を参照してください。

モードの境界要素

プラットフォームで Cisco Unified Border Element（CUBE）機能を有効にします。

allow-connections sip to sip

CUBE の基本 SIP バックツーバックのユーザー エージェント機能を有効にします。詳細については、「接続を許可する」を参照してください。

デフォルトでは、T.38 ファックス トランスポートが有効になっています。詳細については、ファックス プロトコル t38 (音声サービス) を参照してください。

ストーン

STUN (NAT 経由の UDP のセッション トラバーサル) をグローバルに有効にします。

これらのグローバル stun コマンドは、ローカル ゲートウェイを NAT の背後に展開する場合にのみ必要です。

  • ローカル ゲートウェイの STUN バインディング機能を使用すると、ネゴシエートされたメディア パスを介して、ローカルで生成された STUN 要求を送信できます。これにより、ファイアウォールのピンホールを開くことができます。

詳細については、stun flowdata agent-id および stun flowdata shared-secret を参照してください。

非対称ペイロード (フル)

DTMF と動的コーデック ペイロードの両方に対して SIP 非対称ペイロード サポートを設定します。このコマンドの詳細については、非対称ペイロードを参照してください。

early-offer forced

ローカル ゲートウェイが、隣接ピアからの確認応答を待つ代わりに、最初の INVITE メッセージで SDP 情報を送信するように強制します。このコマンドの詳細については、早期オファーを参照してください。

SIP プロファイル インバウンド

CUBE が SIP プロファイルを使用してメッセージを受信したときに変更できるようにします。プロファイルはダイヤルピアまたはテナント経由で適用されます。

3

すべてのトランクに対して G.711 コーデックのみを許可する音声クラス コーデック 100 を設定します。このシンプルなアプローチは、ほとんどの導入に適しています。必要に応じて、発信元システムと終端システムの両方でサポートされている追加のコーデック タイプをリストに追加できます。

DSP モジュールを使用したトランスコーディング を含むより複雑なソリューションはサポートされていますが、このガイドには含まれていません。 


voice class codec 100
 codec preference 1 g711ulaw
 codec preference 2 g711alaw

以下は、設定のフィールドの説明です。

音声クラス コーデック 100

SIP トランク コールの優先コーデックのみを許可するために使用されます。詳細については、音声クラス コーデックを参照してください。

4

音声クラス stun-usage 100 を設定して、Webex Calling トランクで ICE を有効にします。(このステップは、政府版 Webex には適用されません)


voice class stun-usage 100 
 stun usage firewall-traversal flowdata
 stun usage ice lite

以下は、設定のフィールドの説明です。

STUNの使用法ice lite

可能なときは常に、メディア最適化を可能にする、すべての Webex Calling でダイヤルピアで ICE-Lite を有効にします。詳細については、音声クラス stun 使用状況 および使用状況のice liteを参照してください。

stun usage firewall-traversal flowdata コマンドは、NAT の背後にローカル ゲートウェイを展開する場合にのみ必要です。

メディアの最適化は、可能な限り、ネゴシエートされます。通話に録画などのクラウド メディア サービスが必要な場合、メディアを最適化できません。

5

Webex トラフィックのメディア暗号化ポリシーを設定します。(このステップは、政府版 Webex には適用されません)


voice class srtp-crypto 100
 crypto 1 AES_CM_128_HMAC_SHA1_80

以下は、設定のフィールドの説明です。

音声クラス srtp-crypto 100

オファーと応答メッセージの SDP で唯一の SRTP 暗号スイート CUBE が提供されるため、SHA1_80 を指定します。Webex Calling は SHA1_80 のみをサポートします。詳細については、「voice class srtp-crypto」を参照してください。

6

FIPS 対応 GCM 暗号を構成します(このステップは政府版 Webex にのみ適用されます)。 


voice class srtp-crypto 100
crypto 1 AEAD_AES_256_GCM

以下は、設定のフィールドの説明です。

音声クラス srtp-crypto 100

CUBE が提供する暗号スイートとして GCM を指定します。政府版 Webex のローカル ゲートウェイの GCM 暗号を設定する必要があります。

7

宛先 FQDN または SRV に基づいて、ローカル ゲートウェイ トランクへのコールを一意に識別するパターンを設定します。


voice class uri 100 sip
 pattern cube1.lgw.com

以下は、設定のフィールドの説明です。

音声クラス uri 100 sip

着信 SIP 招待を着信トランクダイヤルピアに一致させるパターンを定義します。このパターンを入力する場合は、トランク用に Control Hub で設定されたトランク FQDN または SRV を使用します。

8

SIP メッセージ操作プロファイルを設定します。ゲートウェイにパブリック IP アドレスが設定されている場合は、次のようにプロファイルを設定するか、NAT を使用している場合は、次のステップにスキップします。この例では、cube1.lgw.com はローカル ゲートウェイに設定されている FQDN です。


voice class sip-profiles 100
 rule 10 request ANY sip-header Contact modify "@.*:" "@cube1.lgw.com:" 
 rule 20 response ANY sip-header Contact modify "@.*:" "@cube1.lgw.com:"

以下は、設定のフィールドの説明です。

ルール 10 と 20

Webex がローカル ゲートウェイからのメッセージを認証できるようにするには、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 プロファイル 

voice class sip-profiles 100
 rule 10 request ANY sip-header Contact modify "@.*:" "@cube1.lgw.com:"
 rule 20 response ANY sip-header Contact modify "@.*:" "@cube1.lgw.com:"
 rule 30 response ANY sdp-header Audio-Attribute modify "(a=candidate:1 1.*) 10.80.13.12" "\1 192.65.79.20"
 rule 31 response ANY sdp-header Audio-Attribute modify "(a=candidate:1 2.*) 10.80.13.12" "\1 192.65.79.20"
 rule 40 response ANY sdp-header Audio-Connection-Info modify "IN IP4 10.80.13.12" "IN IP4 192.65.79.20"
 rule 41 request ANY sdp-header Audio-Connection-Info modify "IN IP4 10.80.13.12" "IN IP4 192.65.79.20"
 rule 50 request ANY sdp-header Connection-Info modify "IN IP4 10.80.13.12" "IN IP4 192.65.79.20"
 rule 51 response ANY sdp-header Connection-Info modify "IN IP4 10.80.13.12" "IN IP4 192.65.79.20"
 rule 60 response ANY sdp-header Session-Owner modify "IN IP4 10.80.13.12" "IN IP4 192.65.79.20"
 rule 61 request ANY sdp-header Session-Owner modify "IN IP4 10.80.13.12" "IN IP4 192.65.79.20"
 rule 70 request ANY sdp-header Audio-Attribute modify "(a=rtcp:.*) 10.80.13.12" "\1 192.65.79.20"
 rule 71 response ANY sdp-header Audio-Attribute modify "(a=rtcp:.*) 10.80.13.12" "\1 192.65.79.20"
 rule 80 request ANY sdp-header Audio-Attribute modify "(a=candidate:1 1.*) 10.80.13.12" "\1 192.65.79.20"
 rule 81 request ANY sdp-header Audio-Attribute modify "(a=candidate:1 2.*) 10.80.13.12" "\1 192.65.79.20"

以下は、設定のフィールドの説明です。

ルール 10 と 20

Webex がローカル ゲートウェイからのメッセージを認証できるようにするには、SIP リクエストと応答メッセージの「Contact」ヘッダーに Control Hub のトランクにプロビジョニングされた値が含まれている必要があります。これは、単一のホストの FQDN か、デバイスのクラスタに使用される SRV 名になります。

ルール 30 ～ 81

プライベート アドレスの参照をサイトの外部パブリック アドレスに変換し、Webex が後続のメッセージを正しく解釈してルーティングできるようにします。

Webex Calling からの受信メッセージの SIP プロファイル 

voice class sip-profiles 110
 rule 10 response ANY sdp-header Video-Connection-Info modify "192.65.79.20" "10.80.13.12"
 rule 20 response ANY sip-header Contact modify "@.*:" "@cube1.lgw.com:"
 rule 30 response ANY sdp-header Connection-Info modify "192.65.79.20" "10.80.13.12"
 rule 40 response ANY sdp-header Audio-Connection-Info modify "192.65.79.20" "10.80.13.12"
 rule 50 response ANY sdp-header Session-Owner modify "192.65.79.20" "10.80.13.12"
 rule 60 response ANY sdp-header Audio-Attribute modify "(a=candidate:1 1.*) 192.65.79.20" "\1 10.80.13.12"
 rule 70 response ANY sdp-header Audio-Attribute modify "(a=candidate:1 2.*) 192.65.79.20" "\1 10.80.13.12"
 rule 80 response ANY sdp-header Audio-Attribute modify "(a=rtcp:.*) 192.65.79.20" "\1 10.80.13.12"

以下は、設定のフィールドの説明です。

ルール 10 ～ 80

パブリック アドレス参照を設定したプライベート アドレスに変換し、CUBE が Webex からのメッセージを処理できるようにします。

詳細については、音声クラス sip-profiles を参照してください。

米国またはカナダの PSTN プロバイダーは、Webex Calling のスパムまたは詐欺通話の表示 の記事で言及されている追加設定を使用して、スパムおよび詐欺通話の発信者 ID 検証を提供できます。

10

ヘッダー変更プロファイルを使用して、SIP オプション キープアライブを設定します。


voice class sip-profiles 115
 rule 10 request OPTIONS sip-header Contact modify "

以下は、設定のフィールドの説明です。

音声クラス 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 トランクの設定:

  1. 音声クラス テナント 100 を作成して、Webex Calling トランクに特別に必要な設定を定義し、グループ化します。このテナントに関連付けられているダイヤルピアは、後でこれらの設定を継承します。

    次の例では、ステップ 1 で説明されている値を、このガイドの目的で使用しています（太字で示されています）。設定内のトランクの値に置き換えます。

    
voice class tenant 100
 no remote-party-id
 sip-server dns:us25.sipconnect.bcld.webex.com
 srtp-crypto 100
 localhost dns:cube1.lgw.com
 session transport tcp tls
 no session refresh
 error-passthru
 rel1xx disable
 asserted-id pai
 bind control source-interface GigabitEthernet0/0/1
 bind media source-interface GigabitEthernet0/0/1
 no pass-thru content custom-sdp
 sip-profiles 100 
 sip-profiles 110 inbound
 privacy-policy passthru
!

    以下は、設定のフィールドの説明です。

    音声クラス テナント 100

    独自の TLS 証明書と CN または SAN 検証リストを持つトランクを設定するには、テナントを使用することをお勧めします。ここでは、テナントに関連付けられた tls プロファイルには、新しい接続を受け入れまたは作成するために使用される信頼ポイントが含まれており、着信接続を検証するための CN または SAN リストがあります。詳細については、音声クラス テナントを参照してください。

    no remote-party-id

    Webex Calling が PAI をサポートしているため、SIP Remote-Party-ID (RPID) ヘッダーを無効にします。これは asserted-id pai コマンドを使用して有効になります。詳細については、remote-party-id を参照してください。

    sip サーバ dns: us25.sipconnect.bcld.webex.com

    トランクのターゲット SIP サーバを設定します。トランクを作成したときに、Control Hub で提供されたエッジ プロキシ SRV アドレスを使用します

    srtp-crypto 100

    SRTP コール レッグ（接続）の優先暗号スイートを設定します（ステップで指定）5). 詳細については、「voice class srtp-crypto」を参照してください。

    ローカルホスト DNS: cube1.lgw.com

    発信メッセージの From、Call-ID、および Remote-Party-ID ヘッダー内の物理 IP アドレスを提供された FQDN で置き換えるように CUBE を設定します。ここでトランクのために Control Hub で設定されたトランク FQDN または SRV を使用します。

    session transport tcp tls

    関連するダイヤルピアの TLS へのトランスポートを設定します。詳細については、session-transport を参照してください。

    セッションの更新がありません

    CUBE と Webex 間の通話の SIP セッション更新を無効にします。詳細については、セッションの更新を参照してください。

    error-passthru

    SIP エラー応答パススルー機能を指定します。詳細については、error-passthru を参照してください。

    rel1xx を無効にする

    Webex Calling トランクに対する信頼できる仮応答の使用を無効にします。詳細については、rel1xx を参照してください。

    asserted-id pai

    (オプション) P-Asserted-Identity ヘッダー処理をオンにし、これが Webex Calling トランクに使用する方法を制御します。

    Webex Calling には、ローカル ゲートウェイへの発信コール INVITE の P-Asserted-Identity (PAI) ヘッダーが含まれています。

    このコマンドが設定されている場合、PAI ヘッダーからの発信者情報を使用して、発信元および PAI/Remote-Party-ID ヘッダーに入力します。

    このコマンドが設定されていない場合、From ヘッダーの発信者情報を使用して、発信 From ヘッダーと PAI/Remote-Party-ID ヘッダーに入力します。

    詳細については、asserted-id を参照してください。

    bind control source-interface GigabitEthernet0/0/1

    Webex Calling に送信されるメッセージのソース インターフェイスと関連する IP アドレスを設定します。詳細については、バインドを参照してください。

    bind media source-interface GigabitEthernet0/0/1

    Webex Calling に送信されるメディアのソース インターフェイスと関連する IP アドレスを設定します。詳細については、バインドを参照してください。

    voice-class SIP プロファイル 100

    アウトバウンド メッセージに使用するヘッダー変更プロファイル（パブリック IP または NAT アドレッシング）を適用します。詳細については、「voice-class sip profiles」を参照してください。

    音声クラス SIP プロファイル 110 インバウンド

    NAT のみの背後にある LGW 展開の場合: 着信メッセージに使用するヘッダー変更プロファイルを適用します。詳細については、音声クラス sip プロファイルを参照してください。

    privacy-policy passthru

    受信メッセージから次のコール レッグにプライバシー ヘッダーを透過的に渡すように CUBE を設定します。詳細については、プライバシー ポリシーを参照してください。

  2. Webex Calling トランクのダイヤルピアを設定します。

    
dial-peer voice 100 voip
 description Inbound/Outbound Webex Calling
 destination-pattern BAD.BAD
 session protocol sipv2
 session target sip-server
 incoming uri request 100
 voice-class codec 100
 voice-class stun-usage 100
 voice-class sip tenant 100
 voice-class sip options-keepalive profile 100
 dtmf-relay rtp-nte 
 srtp
 no vad

    以下は、設定のフィールドの説明です。

    
dial-peer voice 100 voip
 description Inbound/Outbound Webex Calling

    タグ 100 で VoIP ダイヤルピアを定義し、管理とトラブルシューティングを容易にする意味のある説明を提供します。詳細については、ダイヤルピアの音声を参照してください。

    宛先パターン BAD.BAD

    着信ダイヤルピア グループを使用して発信コールをルーティングする場合は、ダミー通知先パターンが必要です。この場合、有効な宛先パターンを使用できます。詳細については、「destination-pattern (interface)」を参照してください。

    session protocol sipv2

    このダイヤル ピアが SIP コール レッグを処理するように指定します。詳細については、セッション プロトコル (ダイヤルピア) を参照してください。

    session target sip-server

    テナント 100 で定義された SIP サーバが継承され、このダイヤル ピアからのコールの宛先に使用されることを示します。

    着信 uri リクエスト 100

    INVITE 要求ヘッダー URI を使用して、着信コールをこのダイヤルピアに照合するために使用される音声クラスを指定します。詳細については、着信 uri を参照してください。

    音声クラスのコーデック 100

    Webex Calling 間の通話のコーデック フィルター リストを示します。詳細については、音声クラス コーデックを参照してください。

    音声クラス 使用量

    ローカル ゲートウェイからローカルで生成された STUN 要求を、ネゴシエートされたメディア パスを介して送信できるようにします。STUN パケットは、メディア トラフィックのためのファイアウォール ピンホールを開き、メディア最適化のための有効なパスを検出するのに役立ちます。

    音声クラス SIP テナント 100

    ダイヤル ピアは、グローバルおよびテナント 100 で設定されたすべてのパラメータを継承します。パラメータは、ダイヤルピア レベルでオーバーライドされる場合があります。詳細については、「voice-class sip tenant」を参照してください。

    voice-class sip options-keepalive profile 100

    このコマンドは、特定のプロファイル（100）を使用して、SIP サーバまたはエンドポイントのグループの可用性を監視するために使用されます。

    srtp

    コールレグの SRTP を有効にする。

SIP PSTN トランクを使用したローカル ゲートウェイの設定
TDM PSTN トランクを使用したローカル ゲートウェイの設定
ローカル ゲートウェイを既存の Unified CM 環境で構成する

前のセクションの PSTN-Webex Calling の設定は、Cisco Unified Communications Manager (UCM) クラスタに追加のトランクを含めるように変更できます。この場合、すべてのコールは Unified CM 経由でルーティングされます。ポート 5060 の UCM からのコールは PSTN にルーティングされ、ポート 5065 からのコールは Webex Calling にルーティングされます。この通話シナリオを含めるには、次の増分設定を追加できます。

1

以下の音声クラス URI を設定:

  1. ポート経由の SIP を使用して、Unified CM から Webex 通話を分類します。

    
voice class uri 300 sip
 pattern :5065

  2. ポート経由の SIP を使用して、Unified CM から PSTN コールを分類します。

    
voice class uri 400 sip
 pattern 192\.168\.80\.6[0-5]:5060

    発信元のアドレスとポート番号を記述した 1 つ以上のパターンを使用して、UCM からの着信メッセージを PSTN トランクに分類します。必要に応じて、正規表現を使用して、一致するパターンを定義することができます。

    上記の例では、192.168.80.60 ～ 65 およびポート番号 5060 の任意の IP アドレスに正規表現が使用されます。

2

Unified CM ホストへの SRV ルーティングを指定するには、次の DNS レコードを設定します。

IOS XE は、ターゲット UCM ホストとポートをローカルで判別するためにこれらのレコードを使用します。この設定では、DNS システムでレコードを設定する必要はありません。DNS を使用する場合は、これらのローカル設定は必要ありません。


ip host ucmpub.mydomain.com 192.168.80.60
ip host ucmsub1.mydomain.com 192.168.80.61
ip host ucmsub2.mydomain.com 192.168.80.62
ip host ucmsub3.mydomain.com 192.168.80.63
ip host ucmsub4.mydomain.com 192.168.80.64
ip host ucmsub5.mydomain.com 192.168.80.65
ip host _sip._udp.wxtocucm.io srv 0 1 5065 ucmpub.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub1.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub2.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub3.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub4.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub5.mydomain.com
ip host _sip._udp.pstntocucm.io srv 0 1 5060 ucmpub.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub1.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub2.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub3.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub4.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub5.mydomain.com

以下は、設定のフィールドの説明です。

次のコマンドにより、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

次のダイヤル ピアを設定します。

  1. Unified CM と Webex Calling 間の通話のダイヤル ピア:

    
dial-peer voice 300 voip
 description UCM-Webex Calling trunk
 destination-pattern BAD.BAD
 session protocol sipv2
 session target dns:wxtocucm.io
 incoming uri via 300
 voice-class codec 100
 voice-class sip bind control source-interface GigabitEthernet 0/0/0
 voice-class sip bind media source-interface GigabitEthernet 0/0/0
 dtmf-relay rtp-nte
 no vad

    以下は、設定のフィールドの説明です。

    
dial-peer voice 300 voip
 description UCM-Webex Calling trunk

    タグ 300 で VoIP ダイヤルピアを定義し、管理とトラブルシューティングを容易にする意味のある説明を提供します。

    destination-pattern BAD.BAD

    着信ダイヤルピア グループを使用して発信コールをルーティングする場合は、ダミー通知先パターンが必要です。この場合、有効な宛先パターンを使用できます。

    session protocol sipv2

    ダイヤルピア 300 が SIP コール レッグを処理するように指定します。詳細については、セッション プロトコル (ダイヤルピア) を参照してください。

    セッション ターゲット dns:wxtocucm.io

    DNS SRV 解決により複数の Unified CM ノードのセッション ターゲットを定義します。この場合、ローカルで定義された SRV レコード wxtocucm.io がコールを転送するために使用されます。

    incoming uri via 300

    音声クラス URI 300 を使用して、ソース ポート 5065 を使用して、Unified CM からすべての着信トラフィックをこのダイヤルピアに誘導します。詳細については、着信 uri を参照してください。

    音声クラスのコーデック 100

    Unified CM 間のコールのコーデック フィルタ リストを示します。詳細については、音声クラス コーデックを参照してください。

    bind control source-interface GigabitEthernet0/0/0

    PSTN に送信されるメッセージのソース インターフェイスと関連する IP アドレスを設定します。詳細については、バインドを参照してください。

    bind media source-interface GigabitEthernet0/0/0

    PSTN に送信されるメディアのソース インターフェイスと関連する IP アドレスを設定します。詳細については、バインドを参照してください。

    dtmf-relay rtp-nte

    通話レグで予想される DTMF 機能として RTP-NTE (RFC2833) を定義します。詳細については、「DTMF リレー (音声オーバー IP)」を参照してください。

    no vad

    音声アクティブティの検出を無効にします。詳細については、vad (ダイヤル ピア) を参照してください。

  2. Unified CM と PSTN 間の通話のダイヤル ピア:

    
dial-peer voice 400 voip
 description UCM-PSTN trunk
 destination-pattern BAD.BAD
 session protocol sipv2
 session target dns:pstntocucm.io
 incoming uri via 400
 voice-class codec 100 
 voice-class sip bind control source-interface GigabitEthernet 0/0/0
 voice-class sip bind media source-interface GigabitEthernet 0/0/0
 dtmf-relay rtp-nte
 no vad

    以下は、設定のフィールドの説明です。

    
dial-peer voice 400 voip
 description UCM-PSTN trunk

    タグ 400 で VoIP ダイヤルピアを定義し、管理とトラブルシューティングを容易にする意味のある説明を提供します。

    destination-pattern BAD.BAD

    着信ダイヤルピア グループを使用して発信コールをルーティングする場合は、ダミー通知先パターンが必要です。この場合、有効な宛先パターンを使用できます。

    session protocol sipv2

    ダイヤルピア 400 が SIP コール レッグを処理するように指定します。詳細については、セッション プロトコル (ダイヤルピア) を参照してください。

    セッションターゲット dns:pstntocucm.io

    DNS SRV 解決により複数の Unified CM ノードのセッション ターゲットを定義します。この場合、ローカルで定義された SRV レコード pstntocucm.io がコールを転送するために使用されます。

    400 経由の着信 uri

    音声クラス URI 400 を使用して、ソース ポート 5060 を使用して指定された Unified CM ホストからのすべての着信トラフィックをこのダイヤルピアに誘導します。詳細については、着信 uri を参照してください。

    音声クラスのコーデック 100

    Unified CM 間のコールのコーデック フィルタ リストを示します。詳細については、音声クラス コーデックを参照してください。

    bind control source-interface GigabitEthernet0/0/0

    PSTN に送信されるメッセージのソース インターフェイスと関連する IP アドレスを設定します。詳細については、バインドを参照してください。

    bind media source-interface GigabitEthernet0/0/0

    PSTN に送信されるメディアのソース インターフェイスと関連する IP アドレスを設定します。詳細については、バインドを参照してください。

    dtmf-relay rtp-nte

    通話レグで予想される DTMF 機能として RTP-NTE (RFC2833) を定義します。詳細については、「DTMF リレー (音声オーバー IP)」を参照してください。

    no vad

    音声アクティブティの検出を無効にします。詳細については、vad (ダイヤル ピア) を参照してください。

4

次の設定を使用してコール ルーティングを追加します。

  1. ダイヤルピア グループを作成し、Unified CM と Webex Calling の間でコールをルーティングします。DPG 100 を 発信ダイヤルピア 100 で Webex Calling に対して定義します。DPG 100 は、Unified CM からの関連付けられた着信ダイヤルピアに適用されます。同様に、Unified CM に対して発信ダイヤルピア 300 を使用して DPG 300 を定義します。DPG 300 は、Webex からの着信ダイヤルピアに適用されます。

    
voice class dpg 100
 description Route calls to Webex Calling
 dial-peer 100
voice class dpg 300
 description Route calls to Unified CM Webex Calling trunk
 dial-peer 300

  2. Unified CM と PSTN の間でコールをルーティングするためのダイヤル ピア グループを作成します。PSTN に対して発信ダイヤルピア 200 で DPG 200 を定義します。DPG 200 は、Unified CM から関連する着信ダイヤルピアに適用されます。同様に、Unified CM に対して発信ダイヤルピア 400 を使用して DPG 400 を定義します。DPG 400 は、PSTN からの着信ダイヤルピアに適用されます。

    
voice class dpg 200
 description Route calls to PSTN
 dial-peer 200
voice class dpg 400
 description Route calls to Unified CM PSTN trunk
 dial-peer 400

    以下は、設定のフィールドの説明です。

    ダイヤルピア 100

    発信ダイヤルピアをダイヤルピア グループに関連付けます。詳細については、voice-class dpg を参照してください。

  3. ダイヤルピア グループを適用して、Webex から Unified CM および Unified CM から Webex に通話をルーティングします。 

    
dial-peer voice 100
 destination dpg 300
dial-peer voice 300
 destination dpg 100

    以下は、設定のフィールドの説明です。

    宛先 dpg 300

    どのダイヤルピア グループを指定し、この着信ダイヤルピアに提示されるコールのアウトバウンド処理に使用するかを指定します。

  4. ダイヤルピア グループを適用して、PSTN から Unified CM から Unified CM から PSTN に通話をルーティングします。

    
dial-peer voice 200
 destination dpg 400
dial-peer voice 400
 destination dpg 200

    これにより、ローカル ゲートウェイの設定が終了します。CUBE 機能が初めて設定されている場合、設定を保存し、プラットフォームを再読み込みします。

診断署名でローカル ゲートウェイを監視し、トラブルシューティングする

診断署名 (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 以上を実行するローカル ゲートウェイ

  1. 診断署名はデフォルトで有効になっています。

  2. デバイスが IOS XE 17.6.1 以上を実行している場合に、プロアクティブ通知を送信するために使用する安全なメール サーバーを構成します。

    
configure terminal 
call-home  
mail-server :@ priority 1 secure tls 
end

  3. 通知する管理者 ds_email のメールアドレスを使用して、環境変数を設定します。

    
configure terminal 
call-home  
diagnostic-signature 
LocalGateway(cfg-call-home-diag-sign)environment ds_email  
end

プロアクティブ モニタリングのために診断署名をインストールする

CPU 使用率の監視

この DS は SNMP OID 1.3.6.1.4.1.9.2.1.56 を使用して 5 秒間の CPU 使用率を追跡します。使用率が 75% 以上に達すると、すべてのデバッグが無効し、ローカル ゲートウェイにインストールした診断署名をアンインストールします。下記の手順を実行して署名をインストールします。

  1. コマンドを使用して SNMP を有効に設定し、 snmp を表示します。SNMP が有効になっていない場合は、snmp-server manager コマンドを設定します。

    
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

  2. Diagnostic Signatures Lookup Tool の以下のドロップダウンオプションを使用して、DS 64224 をダウンロードします。

    copy ftp://username:password@/DS_64224.xml bootflash:

    フィールド名

    フィールド値

    プラットフォーム

    Cisco 4300、4400 ISR シリーズ、または Catalyst 8000V Edge ソフトウェア

    製品

    Webex Calling ソリューションの CUBE Enterprise

    問題の範囲

    パフォーマンス

    問題の種類

    メール通知による高 CPU 使用率

    Diagnostic Signatures Lookup ツールから DS 64224 をダウンロードする

  3. DS XML ファイルをローカルゲートウェイフラッシュにコピーします。

    copy ftp://username:password@/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)

  4. ローカルゲートウェイに DS XML ファイルをインストールします。

    
call-home diagnostic-signature load DS_64224.xml 
Load file DS_64224.xml success

  5. 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 使用率の監視を続行してください。

異常な通話切断の監視

この DS は、10 分ごとに SNMP ポーリングを使用して、SIP エラーの 403、488、503 で異常な通話切断を検出します。 エラーカウントの増分が最後の投票から 5 以上である場合、syslog とメール通知が生成されます。 署名をインストールするには、以下の手順を使用してください。

  1. コマンド show snmp を使用して、SNMP が有効 になっている必要があります。SNMP が有効になっていない場合は、snmp-server manager コマンドを設定します。 

    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

  2. Diagnostic Signatures Lookup Tool の以下のオプションを使用して、DS 65221 をダウンロードします。

    フィールド名

    フィールド値

    プラットフォーム

    Cisco 4300、4400 ISR シリーズ、または Catalyst 8000V Edge ソフトウェア

    製品

    Webex Calling ソリューションの CUBE Enterprise

    問題の範囲

    パフォーマンス

    問題の種類

    メールおよび Syslog 通知による SIP の異常通話切断検出

  3. DS XML ファイルをローカルゲートウェイにコピーします。

    copy ftp://username:password@/DS_65221.xml bootflash:

  4. ローカルゲートウェイに DS XML ファイルをインストールします。 

    
call-home diagnostic-signature load DS_65221.xml 
Load file DS_65221.xml success

  5. コマンド 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 を使用して、以下の手順を使用して、診断データの収集を自動化します。

  1. 診断データをアップロードするために、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://:@cxd.cisco.com"  
end

    例: 

    
call-home  
diagnostic-signature 
environment ds_fsurl_prefix " environment ds_fsurl_prefix "scp://612345678:abcdefghijklmnop@cxd.cisco.com"

  2. コマンド show snmp を使用して、SNMP が有効 になっている必要があります。SNMP が有効になっていない場合は、snmp-server manager コマンドを設定します。

    
show snmp 
%SNMP agent not enabled 
 
config t 
snmp-server manager 
end

  3. 高 CPU 使用率の期間中に、すべてのデバッグと診断署名を無効にすることを推奨するプロアクティブな措置として、高 CPU モニタリング DS 64224 をインストールすることを推奨します。Diagnostic Signatures Lookup Tool の以下のオプションを使用して、DS 64224 をダウンロードします。

    フィールド名

    フィールド値

    プラットフォーム

    Cisco 4300、4400 ISR シリーズ、または Catalyst 8000V Edge ソフトウェア

    製品

    Webex Calling ソリューションの CUBE Enterprise

    問題の範囲

    パフォーマンス

    問題の種類

    通知メールによる CPU 使用率が高い

  4. 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

  5. DS XML ファイルをローカルゲートウェイにコピーします。

    
copy ftp://username:password@/DS_64224.xml bootflash: 
copy ftp://username:password@/DS_65095.xml bootflash:

  6. 高 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

  7. 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

    DSLGW_IEC_C_all_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 名

トリガー済み/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 deinstall

例:

call-home diagnostic-signature deinstall 64224

診断署名ルックアップ ツールに、展開で見られる問題に基づいて、定期的に新しい署名が追加されます。TAC では現在、新しいカスタム署名の作成リクエストをサポートしていません。

ローカル ゲートウェイとして CUBE のハイ アベイラビリティを実装する

基礎

前提条件

Webex Calling のローカル ゲートウェイとして CUBE HA を展開する前に、以下の概念を深く理解するようにしてください。

この記事で提供される構成ガイドラインは、既存の音声構成が設定されていない専用のローカル ゲートウェイ プラットフォームが使用されていることを前提としています。既存の 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 設定ガイドを次に示します。

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

インターフェイスのステータスを追跡するために、グローバル レベルでインターフェイス トラッキングを構成します。

conf t
 track 1 interface GigabitEthernet1 line-protocol
 track 2 interface GigabitEthernet2 line-protocol
 exit


VCUBE-1#conf t

VCUBE-1(config)#track 1 interface GigabitEthernet1 line-protocol

VCUBE-1(config-track)#track 2 interface GigabitEthernet2 line-protocol

VCUBE-1(config-track)#exit

VCUBE-2#conf t

VCUBE-2(config)#track 1 interface GigabitEthernet1 line-protocol

VCUBE-2(config-track)#track 2 interface GigabitEthernet2 line-protocol

VCUBE-2(config-track)#exit

トラッキング CLI は、トラフィック インターフェイスがダウンした後、アクティブ ルートがアクティブな役割を果たすように、RG 内で音声トラフィックインターフェイスの状態を追跡するために使用されます。

2

アプリケーション冗長性サブモード下の VoIP HA で使用する RG を構成します。

redundancy
  application redundancy
   group 1
    name LocalGateway-HA
    priority 100 failover threshold 75
    control GigabitEthernet3 protocol 1
    data GigabitEthernet3
    timers delay 30 reload 60
    track 1 shutdown
    track 2 shutdown
    exit
   protocol 1
    timers hellotime 3 holdtime 10
   exit
  exit
 exit


VCUBE-1(config)#redundancy

VCUBE-1(config-red)#application redundancy

VCUBE-1(config-red-app)#group 1

VCUBE-1(config-red-app-grp)#name LocalGateway-HA

VCUBE-1(config-red-app-grp)#priority 100 failover threshold 75

VCUBE-1(config-red-app-grp)#control GigabitEthernet3 protocol 1

VCUBE-1(config-red-app-grp)#data GigabitEthernet3

VCUBE-1(config-red-app-grp)#timers delay 30 reload 60

VCUBE-1(config-red-app-grp)#track 1 shutdown

VCUBE-1(config-red-app-grp)#track 2 shutdown

VCUBE-1(config-red-app-grp)#exit

VCUBE-1(config-red-app)#protocol 1

VCUBE-1(config-red-app-prtcl)#timers hellotime 3 holdtime 10

VCUBE-1(config-red-app-prtcl)#exit

VCUBE-1(config-red-app)#exit

VCUBE-1(config-red)#exit

VCUBE-1(config)#

VCUBE-2(config)#redundancy

VCUBE-2(config-red)#application redundancy

VCUBE-2(config-red-app)#group 1

VCUBE-2(config-red-app-grp)#name LocalGateway-HA

VCUBE-2(config-red-app-grp)#priority 100 failover threshold 75

VCUBE-2(config-red-app-grp)#control GigabitEthernet3 protocol 1

VCUBE-1(config-red-app-grp)#data GigabitEthernet3

VCUBE-2(config-red-app-grp)#timers delay 30 reload 60

VCUBE-2(config-red-app-grp)#track 1 shutdown

VCUBE-2(config-red-app-grp)#track 2 shutdown

VCUBE-2(config-red-app-grp)#exit

VCUBE-2(config-red-app)#protocol 1

VCUBE-2(config-red-app-prtcl)#timers hellotime 3 holdtime 10

VCUBE-2(config-red-app-prtcl)#exit

VCUBE-2(config-red-app)#exit

VCUBE-2(config-red)#exit

VCUBE-2(config)#

この構成で使用されるフィールドの説明を次に示します。

  • 冗長性: 冗長モードに入る

  • アプリケーション冗長性: アプリケーション冗長設定モードに入ります

  • group—冗長性アプリケーション グループ設定モードに入ります

  • name LocalGateway-HA—RG グループの名前を定義します。

  • 優先度 100 フェールオーバーしきい値 75: RG の初期優先順位とフェールオーバーしきい値を指定します。

  • タイマー遅延 30 reload 60: 遅延と再読み込みに対して 2 回設定します。

    • インターフェイスが起動した後、RG グループの初期設定と役割のネゴシエーションの遅延時間を示す遅延タイマーです。デフォルトは 30 秒です。範囲は 0-10000 秒です

    • Reload—これは、リロード後の RG グループ初期設定と役割ネゴシエーションの遅延時間です。デフォルトは 60 秒です。範囲は 0-10000 秒です

    • デフォルトのタイマーが推奨されていますが、これらのタイマーは、ネットワークのルーティングが安定した時点の後、RG プロトコルのネゴシエーションが行われることを保証するために、ルーターの起動/再読み込み中に発生する可能性がある追加のネットワーク集約遅延に合わせて調整される場合があります。たとえば、フェールオーバー後に、新しいスタンバイに最大 20 秒間かかり、新しいアクティブから最初の RG HELLO パケットを確認する場合は、この遅延を考慮して、最初の RG HELLO パケットを「タイマー遅延 60 リロード 120」に調整する必要があります。

  • control GigabitEthernet3 protocol 1—2 つの CUBE 間でキープアライブとハローメッセージを交換するために使用されるインターフェイスを構成し、コントロール インターフェイスに接続されるプロトコル インスタンスを指定し、冗長アプリケーション プロトコル構成モードに入ります

  • data GigabitEthernet3—データ トラフィックのチェックポイントに使用されるインターフェイスを設定します

  • track - インターフェイスの RG グループ トラッキング

  • プロトコル 1—コントロール インターフェイスに接続されるプロトコル インスタンスを指定し、冗長性アプリケーション プロトコル設定モードに入ります。

  • タイマー hellotime 3 holdtime 10: hellotime と holdtime の 2 つのタイマーを設定します。

    • Hellotime— 連続する hello メッセージの間隔 (デフォルトで 3 秒)。範囲は 250 ミリ秒から 254 秒です

    • Holdtime — Hello メッセージの受信と送信ルーターが失敗した推定の間隔。この継続時間は、hello time (デフォルトの 10 秒より長くする必要があります) 以上である必要があります。範囲は 750 ミリ秒から 255 秒です

      Holdtime タイマーを hellotime タイマーの最低 3 倍の値に設定することをお勧めします。

3

CUBE アプリケーションのボックス間の冗長性を有効にします。voice service voip の下にある前のステップから RG を構成します。これにより、CUBE アプリケーションは冗長性プロセスをコントロールすることができます。

voice service voip
   redundancy-group 1
   exit

VCUBE-1(config)#voice service voip

VCUBE-1(config-voi-serv)#redundancy-group 1


                        % Created RG 1 association with Voice B2B HA; reload the router for the new configuration to take effect
                      

VCUBE-1(config-voi-serv)# exit

VCUBE-2(config)#voice service voip

VCUBE-2(config-voi-serv)#redundancy-group 1


                        % Created RG 1 association with Voice B2B HA; reload the router for the new configuration to take effect
                      

VCUBE-2(config-voi-serv)# exit

redundancy-group 1: このコマンドを追加および削除するには、更新された構成を有効にするために再読み込みが必要です。すべての構成が適用された後で、プラットフォームを再読み込みします。

4

以下に示すように、Gig1 と Gig2 インターフェイスをそれぞれの仮想 IP で構成し、冗長性インターフェイス識別子 (rii) を適用します。

VCUBE-1(config)#interface GigabitEthernet1

VCUBE-1(config-if)# redundancy rii 1

VCUBE-1(config-if)# redundancy group 1 ip 198.18.1.228 exclusive

VCUBE-1(config-if)# exit

VCUBE-1(config)#

VCUBE-1(config)#interface GigabitEthernet2

VCUBE-1(config-if)# redundancy rii 2

VCUBE-1(config-if)# redundancy group 1 ip 198.18.133.228 exclusive

VCUBE-1(config-if)# exit

VCUBE-2(config)#interface GigabitEthernet1

VCUBE-2(config-if)# redundancy rii 1

VCUBE-2(config-if)# redundancy group 1 ip 198.18.1.228 exclusive

VCUBE-2(config-if)# exit

VCUBE-2(config)#

VCUBE-2(config)#interface GigabitEthernet2

VCUBE-2(config-if)# redundancy rii 2

VCUBE-2(config-if)# redundancy group 1 ip 198.18.133.228 exclusive

VCUBE-v(config-if)# exit

この構成で使用されるフィールドの説明を次に示します。

  • redundancy rii: 冗長グループの冗長インターフェイス ID を設定します。仮想 MAC (VMAC) アドレスを生成するために必要です。同じ VIP を持つ各ルーター (アクティブ/スタンバイ) のインターフェイスで同じ rii ID 値を使用する必要があります。

    同じ LAN に複数の B2B ペアがある場合、各ペアはそれぞれのインターフェイスに固有の RII ID を持っている必要があります（衝突を防ぐため）。「冗長性アプリケーショングループをすべて表示」は、正しいローカルおよびピア情報を示す必要があります。

  • 冗長グループ 1: 上記のステップ 2 で作成された冗長グループとインターフェイスを関連付けます。RG グループ、およびこの物理インターフェイスに割り当てられた VIP を構成します。

    冗長性のために別のインターフェイスを使用することが必須です。つまり、音声トラフィックに使用されるインターフェイスは、上記の手順 2 で指定したコントロールとデータ インターフェイスとして使用できません。この例では、RG コントロール/データにギガビット インターフェイス 3 が使用されています。

5

最初の CUBE 構成を保存し、再読み込みします。

最後にリロードするプラットフォームは常にスタンバイです。

VCUBE-1#wr


                        Building configuration...
                      


                        [OK]
                      

VCUBE-1#reload


                        Proceed with reload? [confirm]

VCUBE-1 が完全に起動したら、 VCUBE-2 の構成を保存し、再読み込みします。

VCUBE-2#wr


                        Building configuration...
                      


                        [OK]
                      

VCUBE-2#reload


                        Proceed with reload? [confirm]

6

ボックス間の構成が期待どおりに機能していることを確認します。関連する出力は太字で強調表示されます。

VCUBE-2 を最後にリロードし、設計上の考慮事項に従います。最後にリロードするプラットフォームは常に [スタンバイ] 状態です。 


VCUBE-1#show redundancy application group all
Faults states Group 1 info:
       Runtime priority: [100]
               RG Faults RG State: Up.
                       Total # of switchovers due to faults:           0
                       Total # of down/up state changes due to faults: 0
Group ID:1
Group Name:LocalGateway-HA
  
Administrative State: No Shutdown
Aggregate operational state: Up
My Role: ACTIVE
Peer Role: STANDBY
Peer Presence: Yes
Peer Comm: Yes
Peer Progression Started: Yes

RF Domain: btob-one
         RF state: ACTIVE
         Peer RF state: STANDBY HOT

RG Protocol RG 1
------------------
        Role: Active
        Negotiation: Enabled
        Priority: 100
        Protocol state: Active
        Ctrl Intf(s) state: Up
        Active Peer: Local
        Standby Peer: address 10.1.1.2, priority 100, intf Gi3
        Log counters:
                role change to active: 1
                role change to standby: 1
                disable events: rg down state 0, rg shut 0
                ctrl intf events: up 1, down 0, admin_down 0
                reload events: local request 0, peer request 0

RG Media Context for RG 1
--------------------------
        Ctx State: Active
        Protocol ID: 1
        Media type: Default
        Control Interface: GigabitEthernet3
        Current Hello timer: 3000
        Configured Hello timer: 3000, Hold timer: 10000
        Peer Hello timer: 3000, Peer Hold timer: 10000
        Stats:
            Pkts 1509, Bytes 93558, HA Seq 0, Seq Number 1509, Pkt Loss 0
            Authentication not configured
            Authentication Failure: 0
            Reload Peer: TX 0, RX 0
            Resign: TX 0, RX 0
    Standy Peer: Present. Hold Timer: 10000
            Pkts 61, Bytes 2074, HA Seq 0, Seq Number 69, Pkt Loss 0

VCUBE-1#

VCUBE-2#show redundancy application group all
Faults states Group 1 info:
       Runtime priority: [100]
               RG Faults RG State: Up.
                       Total # of switchovers due to faults:           0
                       Total # of down/up state changes due to faults: 0
Group ID:1
Group Name:LocalGateway-HA
  
Administrative State: No Shutdown
Aggregate operational state: Up
My Role: STANDBY
Peer Role: ACTIVE
Peer Presence: Yes
Peer Comm: Yes
Peer Progression Started: Yes

RF Domain: btob-one
         RF state: ACTIVE
         Peer RF state: STANDBY HOT

RG Protocol RG 1
------------------
        Role: Active
        Negotiation: Enabled
        Priority: 100
        Protocol state: Active
        Ctrl Intf(s) state: Up
        Active Peer: address 10.1.1.2, priority 100, intf Gi3
        Standby Peer: Local
        Log counters:
                role change to active: 1
                role change to standby: 1
                disable events: rg down state 0, rg shut 0
                ctrl intf events: up 1, down 0, admin_down 0
                reload events: local request 0, peer request 0

RG Media Context for RG 1
--------------------------
        Ctx State: Active
        Protocol ID: 1
        Media type: Default
        Control Interface: GigabitEthernet3
        Current Hello timer: 3000
        Configured Hello timer: 3000, Hold timer: 10000
        Peer Hello timer: 3000, Peer Hold timer: 10000
        Stats:
            Pkts 1509, Bytes 93558, HA Seq 0, Seq Number 1509, Pkt Loss 0
            Authentication not configured
            Authentication Failure: 0
            Reload Peer: TX 0, RX 0
            Resign: TX 0, RX 0
    Standy Peer: Present. Hold Timer: 10000
            Pkts 61, Bytes 2074, HA Seq 0, Seq Number 69, Pkt Loss 0

VCUBE-2#

両方の CUBE でローカル ゲートウェイを構成する

この例の構成では、Control Hub から以下のトランク情報を使用して、VCUBE-1、VCUBE-2 の両方のプラットフォームでローカルゲートウェイを構成しています。この設定のユーザー名とパスワードは以下のとおりです。

  • ユーザー名:フセイン1076_LGU

  • パスワード:lOV12MEaZx

1

クレデンシャルまたは共有秘密で使用する前に、以下のコマンドを使用して、設定キーがパスワードに対して作成されていることを確認してください。Type 6 パスワードは、AES 暗号化とこのユーザー定義の設定キーを使用して暗号化されます。 


LocalGateway#conf t
LocalGateway(config)#key config-key password-encrypt Password123
LocalGateway(config)#password encryption aes

これは、上に表示された Webex Control Hub パラメータに基づいて両方のプラットフォームに適用されるローカル ゲートウェイの構成です。保存と再読み込みを行います。Webex Control Hub からの SIP ダイジェスト資格情報は、太字でハイライトされます。


configure terminal
crypto pki trustpoint dummyTp
revocation-check crl
exit
sip-ua
crypto signaling default trustpoint dummyTp cn-san-validate server
transport tcp tls v1.2
end


configure terminal
crypto pki trustpool import clean url
http://www.cisco.com/security/pki/trs/ios_core.p7b
end


configure terminal
voice service voip
  ip address trusted list
    ipv4 x.x.x.x y.y.y.y
    exit
   allow-connections sip to sip
  media statistics
  media bulk-stats
  no supplementary-service sip refer
  no supplementary-service sip handle-replaces
  fax protocol pass-through g711ulaw
  stun
    stun flowdata agent-id 1 boot-count 4
    stun flowdata shared-secret 0 Password123!
  sip
    g729 annexb-all
    early-offer forced
    end


configure terminal
voice class sip-profiles 200
  rule 9 request ANY sip-header SIP-Req-URI modify "sips:(.*)"
"sip:\1"
  rule 10 request ANY sip-header To modify ""
""
  rule 13 response ANY sip-header To modify ""
";otg=hussain1076_lgu>"
  rule 30 request ANY sip-header P-Asserted-Identity modify
"sips:(.*)" "sip:\1"


voice class codec 99
  codec preference 1 g711ulaw
  codec preference 2 g711ulaw
  exit

voice class srtp-crypto 200
  crypto 1 AES_CM_128_HMAC_SHA1_80
  exit

voice class stun-usage 200
  stun usage firewall-traversal flowdata
  exit






voice class tenant 200
  registrar dns:40462196.cisco-bcld.com scheme sips expires 240
refresh-ratio 50 tcp tls
  credentials number Hussain5091_LGU username Hussain1076_LGU
password 0 lOV12MEaZx realm Broadworks 
  authentication username Hussain5091_LGU password 0 lOV12MEaZx
realm BroadWorks

  authentication username Hussain5091_LGU password 0 lOV12MEaZx
realm 40462196.cisco-bcld.com
  no remote-party-id
  sip-server dns:40462196.cisco-bcld.com
  connection-reuse
  srtp-crypto 200
  session transport tcp tls
  url sips
  error-passthru
  asserted-id pai
  bind control source-interface GigabitEthernet1
  bind media source-interface GigabitEthernet1
  no pass-thru content custom-sdp
  sip-profiles 200
  outbound-proxy dns:la01.sipconnect-us10.cisco-bcld.com
  privacy-policy passthru


voice class tenant 100
  session transport udp
  url sip
  error-passthru
  bind control source-interface GigabitEthernet2
  bind media source-interface GigabitEthernet2
  no pass-thru content custom-sdp

voice class tenant 300
  bind control source-interface GigabitEthernet2
  bind media source-interface GigabitEthernet2
  no pass-thru content custom-sdp
  

voice class uri 100 sip
 host ipv4:198.18.133.3

voice class uri 200 sip
 pattern dtg=hussain1076.lgu



dial-peer voice 101 voip
 description Outgoing dial-peer to IP PSTN
 destination-pattern BAD.BAD
 session protocol sipv2
 session target ipv4:198.18.133.3
 voice-class codec 99
 voice-class sip tenant 100
 dtmf-relay rtp-nte
 no vad

dial-peer voice 201 voip
 description Outgoing dial-peer to Webex Calling
 destination-pattern BAD.BAD
 session protocol sipv2
 session target sip-server
 voice-class codec 99
 voice-class stun-usage 200
 no voice-class sip localhost
 voice-class sip tenant 200
 dtmf-relay rtp-nte
 srtp
 no vad


voice class dpg 100
 description Incoming WebexCalling(DP200) to IP PSTN(DP101)
 dial-peer 101 preference 1

voice class dpg 200
 description Incoming IP PSTN(DP100) to Webex Calling(DP201)
 dial-peer 201 preference 1





dial-peer voice 100 voip
 desription Incoming dial-peer from IP PSTN
 session protocol sipv2
 destination dpg 200
 incoming uri via 100
 voice-class codec 99
 voice-class sip tenant 300
 dtmf-relay rtp-nte
 no vad

dial-peer voice 200 voip
 description Incoming dial-peer from Webex Calling
 session protocol sipv2
 destination dpg 100
 incoming uri request 200
 voice-class codec 99
 voice-class stun-usage 200
 voice-class sip tenant 200
 dtmf-relay rtp-nte
 srtp
 no vad

end

copy run start

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-1#show redundancy application group 1
Group ID:1
Group Name:LocalGateway-HA

Administrative State: No Shutdown
Aggregate operational state : Up
My Role: Standby
Peer Role: ACTIVE
Peer Presence: Yes
Peer Comm: Yes
Peer Progression Started: Yes

RF Domain: btob-one
         RF state: STANDBY HOT
         Peer RF state: ACTIVE

VCUBE-1#show sip-ua register status
VCUBE-1#


VCUBE-2#show redundancy application group 1
Group ID:1
Group Name:LocalGateway-HA

Administrative State: No Shutdown
Aggregate operational state : Up
My Role: ACTIVE
Peer Role: STATUS
Peer Presence: Yes
Peer Comm: Yes
Peer Progression Started: Yes

RF Domain: btob-one
         RF state: ACTIVE
         Peer RF state: STANDBY HOT

VCUBE-2#show sip-ua register status

Tenant: 200
--------------------Registrar-Index  1 ---------------------
Line                           peer       expires(sec) reg survival P-Associ-URI
============================== ========== ============ === ======== ============
Hussain5091_LGU                -1          48          yes normal
VCUBE-2#

上記の出力から、VCUBE-2 は Webex Calling アクセス SBC への登録を維持するアクティブ LGW であり、「show sip-ua 登録ステータス」の出力は VCUBE-1 では空白です。

3

VCUBE-1 で次のデバッグを有効にします


VCUBE-1#debug ccsip non-call
SIP Out-of-Dialog tracing is enabled
VCUBE-1#debug ccsip info
SIP Call info tracing is enabled
VCUBE-1#debug ccsip message

4

この場合、アクティブ LGW、VCUBE-2 で次のコマンドを実行してフェールオーバーをシミュレートします。


VCUBE-2#redundancy application reload group 1 self

アクティブからスタンバイ LGW への切り替えは、上記に一覧表示されている CLI に加えて、以下のシナリオで発生します。

  • アクティブ ルーターのリロード時

  • アクティブなルーターの電源が再投入される時

  • トラッキングが有効になっているアクティブなルーターの RG 構成されたインターフェイスがシャットダウンされる時

5

VCUBE-1 が Webex Calling アクセス SBC に登録されているかどうかを確認します。VCUBE-2 は今すぐにリロードされます。


              VCUBE-1#show sip-ua register status

Tenant: 200
--------------------Registrar-Index  1 ---------------------
Line                           peer       expires(sec) reg survival P-Associ-URI
============================== ========== ============ === ======== ============
Hussain5091_LGU                -1          56          yes normal
VCUBE-1#

VCUBE-1 がアクティブ LGW になりました。

6

仮想 IP を通じて SIP REGISTER を Webex Calling に送信し、200 OK を受信する VCUBE-1 に関連するデバッグ ログを確認してください。


VCUBE-1#show log

Jan 9 18:37:24.769: %RG_MEDIA-3-TIMEREXPIRED: RG id 1 Hello Time Expired.
Jan 9 18:37:24.771: %RG_PROTCOL-5-ROLECHANGE: RG id 1 role change from Standby to Active
Jan 9 18:37:24.783: %VOICE_HA-2-SWITCHOVER_IND: SWITCHOVER, from STANDBY_HOT to ACTIVE state.
Jan 9 18:37:24.783: //-1/xxxxxxxxxxxx/SIP/Info/info/4096/sip_ha_notify_active_role_event: Received notify active role event

Jan 9 18:37:25.758: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
REGISTER sip: 40462196.cisco-bcld.com:5061 SIP/2.0
Via: SIP/2.0/TLS 198.18.1.228:5061;branch=z9hG4bK0374
From: ;tag=8D573-189
To: 
Date: Thu, 09 Jan 2020 18:37:24 GMT
Call-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97
User-Agent: Cisco-SIPGateway/IOS-16.12.02
Max-Forwards: 70
Timestamp: 1578595044
CSeq: 2 REGISTER
Contact: 
Expires: 240
Supported: path
Content-Length: 0


Jan 9 18:37:25.995: //-1/000000000000/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 401 Unauthorized
Via: SIP/2.0/TLS 198.18.1.228:5061;received=173.38.218.1;branch=z9hG4bK0374;rport=4742
From: ;tag=8D573-189
To: ;tag=SD1u8bd99-1324701502-1578595045969
Date: Thu, 09 Jan 2020 18:37:24 GMT
Call-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97
Timestamp: 1578595044
CSeq: 2 REGISTER
WWW-Authenticate; DIGEST realm="BroadWorks",qop="auth",nonce="BroadWorksXk572qd01Ti58zliBW",algorithm=MD5
Content-Length: 0


Jan 9 18:37:26.000: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
REGISTER sip:40462196.cisco-bcld.com:5061 SIP/2.0
Via: SIP/2.0/TLS 198.18.1.228:5061;branch=z9hG4bK16DC
From: ;tag=8D573-189
To: 
Date: Thu, 09 Jan 2020 18:37:25 GMT
Call-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97
User-Agent:Cisco-SIPGateway/IOS-16.12.02
Max-Forwards: 70
Timestamp: 1578595045
CSeq: 3 REGISTER
Contact: 
Expires: 240
Supported: path
Authorization: Digest username="Hussain1076_LGU",realm="BroadWorks",uri="sips:40462196.cisco-bcld.com:5061",response="b6145274056437b9c07f7ecc08ebdb02",nonce="BroadWorksXk572qd01Ti58z1iBW",cnonce="3E0E2C4D",qop=auth,algorithm=MD5,nc=00000001
Content-Length: 0


Jan 9 18:37:26.190: //1/000000000000/SIP/Msg/ccsipDisplayMsg:

Received:
SIP/2.0 200 OK
Via: SIP/2.0/TLS 198.18.1.228:5061;received=173.38.218.1;branch=z9hG4bK16DC;rport=4742
From: ;tag=8D573-189
To: ;tag=SD1u8bd99-1897486570-1578595-46184
Call-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97
Timestamp: 1578595045
CSeq: 3 REGISTER
Contact: ;expires=120;q=0.5
Allow-Events: call-info,line-seize,dialog,message-summary,as-feature-event,x-broadworks-hoteling,x-broadworks-call-center-status,conference
Content-Length: 0

組織の を設定する

初回セットアップ ウィザードで通話設定をセットアップする

サービスを稼働させるための最初のステップは、初回セットアップウィザード（FTSW）を完了することです。最初のロケーションの FTSW が完了した後では、追加のロケーションに対して完了する必要がありません。

1

受け取ったウェルカム メールのはじめにリンクをクリックします。

管理者のメールアドレスが、自動的に、 にサインインするためのメールアドレスとして使用されます。サインインすると、管理者パスワードを作成するように求められます。サインインすると、セットアップ ウィザードが自動的に開始します。

2

利用規約を見直して、承諾します。

3

プランを見直して、[はじめに] をクリックします。

アカウント マネージャは FTSW の最初の手順をアクティブにする責任があります。[使い始める] を選択した時に、「通話をセットアップできません」という通知を受け取った場合は、アカウント マネージャーに連絡してください。

4

データ センターがマッピングする国を選択し、顧客の連絡先と顧客アドレス情報を入力します。

5

[次へ: デフォルトのロケーション

6

次のオプションから選択します:

  • パートナー管理者であり、顧客管理者にプロビジョニングを完了させる場合は、[保存して閉じる] をクリックします。
  • 必要なロケーションの情報を入力します。ウィザードでロケーションを作成した後、後で他にロケーションを作成できます。

セットアップ ウィザードを完了した後で、作成したロケーションにメイン番号を追加していることを確認してください。

7

このロケーションに適用する次の選択を行います。

  • アナウンス言語: 新規ユーザーと機能に関する音声アナウンスとプロンプト用。
  • メール言語—新規ユーザー向けのメール通信用。
  • 国
  • タイムゾーン
8

[次へ] をクリックします。

9

利用可能な Cisco Webex SIP アドレスを入力し、[次へ] をクリックし、[完了] を選択します。

ロケーションを追加する

始める前に

新しいロケーションを作成するには、以下の情報を指定します。

  • ロケーションの住所

  • 希望する電話番号(オプション)

1

https://admin.webex.com で Control Hub にログインし、[管理] > [ロケーション] に移動します。

新しいロケーションは、初回セットアップ ウィザードを使用して選択した国に対応する地域のデータ センターでホストされます。

2

ロケーションを設定します。

  • ロケーション名—ロケーションを識別する一意の名前を入力します。
  • 国/地域: ロケーションをリンクする国を選択します。たとえば、米国に 1 か所のロケーション (本社) を作成し、イギリスに別のロケーション (支社) を作成することができます。選択した国に応じて、その後の住所のフィールドが決まります。ここには、例として、米国の住所書式を使用したものがあります。
  • ロケーション アドレス—ロケーションのメーリングアドレスを入力します。
  • 市区町村—このロケーションの市区町村を入力します。
  • 州/県/地域—ドロップダウンから都道府県を選択します。
  • ZIP/郵便番号—郵便番号を入力します。
  • アナウンス言語: 新規ユーザーと機能に関する音声アナウンスやプロンプトの言語を選択します。
  • メール言語—新規ユーザーとのメール通信に使用する言語を選択します。
  • タイムゾーン—ロケーションのタイムゾーンを選択します。
3

[保存 ] をクリックしてから、[ はい/いいえ ] を選択して、現在または後でロケーションに番号を追加します。

4

[はい] をクリック した場合、次のいずれかのオプションを選択します。

  • Cisco PSTN—Cisco から Cloud PSTN ソリューションが必要な場合は、このオプションを選択します。Cisco 通話プランは、緊急通話、着信、および国内および国際通話を提供する PSTN 代替ソリューションであり、新しい PSTN 番号または既存の番号を Cisco にポートすることができます。

    Cisco PSTN オプションは、以下の条件でのみ表示されます。

    • コミットされた Cisco Calling プラン OCP (アウトバウンド通話プラン) を少なくとも 1 つ購入している。

    • Cisco Calling プランがサポートされている国にロケーションがある。

    • ロケーションが新規である。他の PSTN 機能が割り当てられている既存のロケーションは、今回は Cisco Calling プランの対象外です。サポートケースを登録 してガイダンスを受けてください。

    • Cisco Calling プランがサポートされている地域の Webex Calling データ センターでホストされています。

  • Cloud Connected PSTN—多くの Cisco CCP パートナーの 1 つからクラウド PSTN ソリューションを探している場合、またはロケーションで Cisco Calling プランが利用できない場合は、このオプションを選択します。CCP パートナーは、PSTN 代替ソリューション、グローバルな広域カバレッジ、広範でさまざまな機能、パッケージ、価格設定を提供しています。

    CCP パートナーと対応地域は、こちらにリストされています。ロケーションの国がサポートされているパートナーにのみ表示されています。パートナーは、ロゴで表示されるか、簡単な文字列と括弧で囲んだ地域名で表示されます (例: (EU)、(US)、または (CA))。ロゴが表示されているパートナーは、常に CCP の地域メディアを提供しています。文字列で表示されているパートナーについては、CCP の地域メディアを確保するために、ロケーションの国に最も近い地域を選択してください。

    リストされているプロバイダーの下に [番号を今すぐ注文する] オプションがある場合は、そのオプションを選択して、統合された CCP のメリットを利用することをおすすめします。統合型 CCP を使用すると、電話番号のプロビジョニングとプロビジョニングを 1 つのペインで実行できます。非統合型 CCP では、CCP パートナーから電話番号を取得する必要があります。

  • プレミスベースの PSTN (ローカル ゲートウェイ): 現在の PSTN プロバイダーを保持する場合、またはクラウド サイトで非クラウド サイトに接続する場合に、このオプションを選択できます。

PSTN オプションの選択は各ロケーション レベルで行います (各ロケーションには PSTN オプションが 1 つしかありません)。展開に対して必要な数のオプションを組み合わせることができますが、各ロケーションには 1 つのオプションとなります。PSTN オプションを選択してプロビジョニングしたら、ロケーションの PSTN プロパティで [管理] をクリックすると、オプションを変更できます。ただし、Cisco PSTN などの一部のオプションは、別のオプションが割り当てられた後は使用できない場合があります。サポートケースを登録 してガイダンスを受けてください。

5

番号を今すぐに有効にするか、または後で有効にするかを選択します。

6

統合されていない CCP またはプレミス ベースの PSTN を選択した場合は、電話番号をコンマ区切り値として入力し、[検証] をクリックします。

特定のロケーションのための番号が追加されます。有効なエントリは [検証済みの番号] フィールドに移動し、無効なエントリは [番号の追加] フィールドに残り、エラー メッセージが表示されます。

番号の書式は、ロケーションの所在する国に応じ、ダイヤリングに関する地元の要件に従って定められます。たとえば、国コードが必要な場合には、コードを付けて入力することも、コードなしで入力してからコードが自動的に先頭に追加されるようにすることもできます。

7

[保存] をクリックします。

次に行うこと

ロケーションを作成した後、そのロケーションの緊急 911 サービスを有効にすることができます。詳細については「Webex Calling の RedSky 緊急 911 サービス」を参照してください。

ロケーションを削除

開始する前に

関連付けられているユーザーとワークスペースを削除すると、使用されていない場所または正しく設定されていない場所を削除できます。ロケーションを削除すると、割り当てられたサービスと番号がすべて削除されます。

ロケーションに関連付けられているユーザーとワークスペースのリストを取得します。[サービス] > [Calling] > [番号] に進み、ドロップダウン メニューから削除するロケーションを選択します。ロケーションを削除する前に、これらのユーザーとワークスペースを削除する必要があります。

このロケーションに関連付けられている番号は、PSTN プロバイダーに解放されることに注意してください。これらの番号は所有されなくなります。

1

https://admin.webex.com で Control Hub にログインし、[管理] > [ロケーション] に移動します。

2

削除するロケーションの隣の [その他のオプション] ボタン [アクション] 列で をクリックします。

3

[場所 の削除] を選択し、その場所を削除します。

通常、ロケーションを完全に削除するには数分かかりますが、最大で 1 時間かかる場合があります。ステータスを確認するには、ロケーション名の隣にある [その他のオプション] ボタン をクリックして、[削除ステータス] を 選択します。

既存のロケーションを更新する

作成した後PSTNのセットアップ、名前、タイムゾーン、言語を変更できます。新しい言語は新しいユーザーとデバイスにのみ適用されることに注意してください。既存のユーザーおよびデバイスは古い言語を使用し続けます。

既存のロケーションについては、緊急時の 911 サービスを有効にすることができます。詳細については「Webex Calling の RedSky 緊急 911 サービス」を参照してください。

1

https://admin.webex.comにサインインします。

2

[管理] > [ロケーション] に移動します。

ロケーションの隣に [警告] 記号が表示される場合、そのロケーションの電話番号をまだ設定していないという意味です。その番号を設定するまで、通話の送受信が行えなんす。

3

(オプション) [PSTN 接続] の下で、すでに設定されているものに応じて、[クラウド接続 PSTN] または [プレミスベースの PSTN](ローカル ゲートウェイ) のいずれかを選択します。[管理] をクリックして設定を変更してから、[続行] を選択することにより、関連するリスクを承認します。以下のオプションのいずれかを選択して、[保存] クリックします。

  • Cisco PSTN—Cisco から Cloud PSTN ソリューションが必要な場合は、このオプションを選択します。Cisco 通話プランは、緊急通話、着信、および国内および国際通話を提供する PSTN 代替ソリューションであり、新しい PSTN 番号または既存の番号を Cisco にポートすることができます。

    Cisco PSTN オプションは、以下の条件でのみ表示されます。

    • コミットされた Cisco Calling プラン OCP (アウトバウンド通話プラン) を少なくとも 1 つ購入しました。

    • Cisco Calling プランがサポートされている国にロケーションがある。

    • Cisco Calling プランがサポートされている地域の Webex Calling データ センターでホストされています。

  • Cloud Connected PSTN—多くの Cisco CCP パートナーの 1 つからクラウド PSTN ソリューションを探している場合、またはロケーションで Cisco Calling プランが利用できない場合は、このオプションを選択します。CCP パートナーは、PSTN 代替ソリューション、グローバルな広域カバレッジ、広範でさまざまな機能、パッケージ、価格設定を提供しています。

    CCP パートナーと対応地域は、こちらにリストされています。ロケーションの国がサポートされているパートナーにのみ表示されています。パートナーは、ロゴで表示されるか、簡単な文字列と括弧で囲んだ地域名で表示されます (例(EU)、(米国)、または (CA)。ロゴが表示されているパートナーは、常に CCP の地域メディアを提供しています。文字列で表示されているパートナーについては、CCP の地域メディアを確保するために、ロケーションの国に最も近い地域を選択してください。

    リストされているプロバイダーに今すぐ番号を注文 するオプションが表示されている場合は、統合型 CCP を利用できるように、そのオプションを選択することをお勧めします。統合型 CCP を使用すると、電話番号のプロビジョニングとプロビジョニングを 1 つのペインで実行できます。非統合型 CCP では、電話番号を CCP パートナーから外部に取得する必要があります。

  • プレミスベースの 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

https://admin.webex.comにサインインします。

2

[管理] > [ロケーション] に移動します。

3

PSTN 接続を Cisco PSTN に変更するロケーションを選択します。

4

[Calling] タブに移動し、プレミスベースの PSTN または非統合型 PSTN の隣の [管理] オプションをクリックします。

5

[接続タイプ] の隣の [編集] を選択します。

6

Cisco Calling プラン カードを選択し、このロケーションのユーザーに Cisco Calling プランを割り当てるサブスクリプションを選択します。[次へ] をクリックします。

7

確認のための接続変更ページが表示されます。[次へ] をクリックして、番号のポート準備を確認します。

PSTN 接続ポート ウィザードは、番号をポートする準備ができているかどうかを確認します。

[次へ（Next）] ボタンは、リスト内のすべての番号がポート可能な場合にのみ有効になります。これらのポインタを読みます。

  • 「ポートできない番号」は非アクティブな番号を指します。このリストに番号がないことを確認してください。

  • ロケーションからポートできない番号を削除します。番号を移動または割り当て解除して、番号を削除できます。

8

[次へ] をクリックし、契約情報を入力します。

PSTN 接続ポート ウィザードの緊急サービス アドレス ページ。

これは、Cisco Calling プラン (米国) を使用するすべてのロケーションの主契約連絡先です。この連絡先への変更は、Cisco Calling プラン (米国) を使用する他のすべてのロケーションに適用されます。

9

[次へ] をクリックします。そのロケーションの契約情報を保存するための確認を求める通知が表示されます。[はい、変更します。] を選択します。

10

緊急連絡サービス アドレスを入力し、[保存] をクリックします。

PSTN 接続ポート ウィザードの緊急サービス アドレス ページ。

緊急時、現地の緊急対応チームはこのアドレスを利用して発信元を見つけます。

11

概要ページには、作成されたポートの数が表示されます。注文が 1 つしかない場合、[追加情報を提供] と呼ばれる追加手順を確認できます。複数の注文の場合、上部に注文セレクタが表示され、その間を移動できます。[次へ] をクリックし、詳細を入力してポート ウィザードを完了します。

PSTN 接続ポート ウィザードの概要ページ。

注文は、単一の PSTN 移行リクエストに対してすべての情報が提供されると同時に送信されます。デフォルトでは、すべての注文で確固たる注文コミットメントの日付が一致しています。最後にリンクされた注文が完全にポートされた後、PSTN 接続の変更が自動的に適用されます。

  • 注文の送信に失敗すると、サポート チケットが自動的に作成され、サポート チームに送信されます。

  • PSTN 接続の変更が複数の通信事業者からの複数の注文を必要とする場合、完了までに最大 10 営業日かかる場合があります。

移行の詳細は、[サービス] > [Calling] > [PSTN] > [注文] タブで利用できます。注文 ID を選択すると、サイドパネルビューで注文の詳細が表示されます。PSTN 接続変更から作成された注文では、タイプを [PSTN の変更] として確認できます。

PSTN 接続の変更をキャンセル

管理者は、ロケーションがまだ移行状態の場合、PSTN 移行をキャンセルできます。

1

https://admin.webex.comにサインインします。

2

[管理] > [ロケーション] に移動します。

3

PSTN 接続をキャンセルするロケーションを選択します。

4

[Calling] タブに移動し、[PSTN 接続変更をキャンセル] ボタンをクリックします。

5

[はい、続行 ] をクリックしてキャンセルを確認します。

ダイヤル プランの設定

アウトバウンド ダイヤル コードを使用して、展開のダイヤル プランをコントロールできます。内線の長さ、ルーティング プレフィックス、およびダイヤル設定 (内部と外部) が、ユーザーのダイヤル習慣に適合するようにカスタマイズします。

これらの設定は社内ダイヤルに適用されるものであり、最初のセットアップ ウィザードでも設定できます。ダイヤル プランを変更すると、更新中の番号がこれらの変更を表示します。

ロケーションの発信通話権限を設定できます。発信権限を設定するには、これらの手順 を参照してください。

1

Control Hub にサインインし、[サービス] > [Calling] > [サービス設定] に移動し、[内線ダイヤル] までスクロールします。

2

必要に応じて、次のオプションのダイヤル設定を行います。

  • ロケーション ルーティング プレフィックスの長さ—複数のロケーションがある場合は、この設定をお勧めします。1 ～ 7 桁の長さを入力できます。同じ内線を持つ複数のロケーションがある場合は、ロケーション間の通話時にプレフィックスをダイヤルする必要があります。たとえば、複数のストアがある場合、内線 1000 を使用すると、各ストアにルーティング プレフィックスを設定することができます。1 つのストアのプレフィックスが 888 の場合、そのストアに到達するために 8881000 にダイヤルします。

    • ルーティング プレフィックスの長には、ステアリング桁が含まれます。たとえば、ルーティング プレフィックスの長さを 4 に設定した場合、サイトを指定できるのは 3 桁のみです。

    • ルーティング プレフィックスをロケーションに割り当てると、そのロケーションに割り当てられた内線番号のすべてのアピアランスには、内線番号の前にルーティング プレフィックスが含まれます。たとえば、888-1000（ルーティング プレフィックス内線）などです。

  • ルーティング プレフィックスのステアリング桁—各ルーティング プレフィックスの最初の桁として設定する番号を選択します。
  • 内線番号の長さ—2 ～ 10 桁を入力でき、デフォルトは 2 です。

    内線の長さを増やしても、社内内線への既存のスピード ダイヤルは自動的に更新されません。

  • ロケーション間の内線ダイヤルを許可: 組織の要件に基づいて、ロケーション間の内線ダイヤルをカスタマイズできます。

    • 組織のすべてのロケーションで重複する内線番号がない場合は、トグルを有効にします。

      デフォルトでは、トグルが有効になっています。

    • 組織が異なるロケーションで同じ内線を持っている場合は、トグルを無効にします。トグルが無効になって発信者が内線番号をダイヤルすると、発信者と同じロケーションに一致する内線番号を持つユーザーにコールがルーティングされます。他のロケーションの内線番号に到達するには、発信者はエンタープライズ有意番号 (ロケーションのルーティングプレフィックス + 内線) をダイヤルする必要があります。

3

特定の場所の内部ダイヤルを指定します。[管理] > [ロケーション] に移動し、リストからロケーションを選択し、[通話] をクリックします。[ダイヤル] までスクロールし、必要に応じて内部ダイヤルを変更します。

  • 内線ダイヤル: あるロケーションのユーザーが別のロケーションの誰かに連絡するためにダイヤルする必要があるルーティング プレフィックスを指定します。各ロケーションのルーティング プレフィックスは固有である必要があります。プレフィックスの長さは組織レベルで設定された長さと一致することを推奨しますが、1 ～ 7 桁の長さである必要があります。
4

特定のロケーションの外線ダイヤルを指定します。[管理] > [ロケーション] に移動し、リストからロケーションを選択し、[通話] をクリックします。[ダイヤル] までスクロールし、必要に応じて外部ダイヤルを変更します。

  • 外線ダイヤル: ユーザーが外線に接続するためにダイヤルする必要がある発信ダイヤル番号を選択できます。デフォルトは [なし] であり、このダイヤル習慣が必要ない場合には、値を [なし] にしておくことができます。この機能を使用しない場合、組織のステアリング番号とは別の番号を使用することをお勧めします。

    ユーザーは、外線発信を行う際に外線発信番号を含め、レガシー システムでダイヤルしていた方法を真似たものにできます。しかし、すべてのユーザーは、発信ダイアル番号なしで外部通話を発信することができます。

  • オプションで、このロケーションの発信ダイヤル番号を強制する ことができます。これにより、ユーザーが外部コールを発信するために管理者が設定した発信ダイヤル番号を使用する必要があります。

    • この機能を有効にすると、発信ダイヤル番号の有無にかかわらず緊急コールをダイヤルできます。有効にすると、外線発信番号が含まれない外線番号 (通話転送に使用される番号など) が機能しなくなります。

    • 内線が国番号と同じ場合、内線が国番号よりも優先されます。したがって、発信ダイヤル番号を有効にすることを推奨します。

    • 着信および発信 PSTN 通話に E.164 番号形式を使用することを強くおすすめします。

ユーザーへの影響:

  • ダイヤル設定の変更を有効にするには、ユーザが電話を再起動する必要があります。

  • ユーザーの内線番号は、ロケーションのステアリング番号または発信ダイヤル番号と同じ番号で開始することはできません。

プレミスベースの PSTN (ローカル ゲートウェイ) を設定する

付加価値再販業者の場合は、次の手順を使用して、ローカル ゲートウェイの設定を開始できます。このゲートウェイがクラウドに登録されている場合、1 つ以上のロケーションで使用して、エンタープライズ PSTN サービス プロバイダーへのルーティングを提供できます。

ローカル ゲートウェイがある場所は、ローカル ゲートウェイが他の場所で使用されているときには削除できません。

トランクを作成する

でトランクを作成するには、次の手順に従ってください。

始める前に

  • ロケーションが追加されたら、ロケーションに対してプレミスベース PSTN を設定する前に、トランクを作成する必要があります。

  • それぞれについて、ロケーションと固有の設定および番号を作成します。ロケーションはプレミスベース PSTN を追加する前に存在する必要があります。

  • のプレミスベースの PSTN (ローカル ゲートウェイ) 要件を理解してください。

  • プレミスベース PSTN を持つロケーションに対して、複数のトランクを選択できませんが、複数のロケーションに対して同じトランクを選択することはできます。

1

にログインし、[サービス] > [Calling] > [コール ルーティング] に進み、[トランクの追加] を選択します。

2

ロケーションを選択します。

3

トランクの名前を指定し、[保存] をクリックします。

名前は 24 文字以内にしてください。

次にやる必要

トランクで設定する必要がある、関連するパラメーターが表示されます。また、PSTN 接続をセキュアにするための SIP ダイジェスト資格情報のセットも生成します。

画面 [ドメインの登録]、[トランク グループ OTG/DTG]、[回線/ポート]、および [発信プロキシ アドレス] にトランク情報が表示されます。

プレミスベースの PSTN を構成する準備ができたら参照できるように、この情報をコピーしてローカルのテキスト ファイルまたはドキュメントに貼り付けることをおすすめします。

クレデンシャルを紛失した場合は、 のトランク情報画面からクレデンシャルを生成する必要があります。[ユーザー名の取得とパスワードのリセット] をクリックして、トランクを使用するための認証資格情報の新しいセットを生成します。

プレミス ベースの PSTN のトランクを選択する

1

https://admin.webex.com で Control Hub にログインし、[管理] > [ロケーション] に移動します。

2

変更する場所を選択し、[管理] をクリックします。

3

プレミスベース PSTN を選択して、[次へ] をクリックします。

4

ドロップダウン メニューからトランクを選択します。

トランク ページにアクセスして、トランク グループの選択を管理します。

5

確認通知をクリックし、[保存] をクリックします。

次にやる必要

が生成した構成情報を記録し、パラメーターをローカル ゲートウェイ (たとえばオンプレミスの Cisco CUBE) にマップする必要があります。この記事 では、このプロセスを説明します。参考のため、どのように の構成情報 (左側) が CUBE のパラメーター (右側) にマップされるかを示す例である次の図を参照してください。

ローカル ゲートウェイの例図。

ゲートウェイ自体の設定が正常に完了すると、[サービス] > [通話] > [ロケーション] に戻り、作成したゲートウェイが割り当てたロケーション カードに名前の左側に緑色のドットが付きます。このステータスは、ゲートウェイがセキュアに通話クラウドに対して登録され、そのロケーションでのアクティブな PSTN としての役割を果たしていることを示しています。

電話番号の管理

で組織の電話番号を簡単に表示、アクティベート、削除、追加できます。詳細については、「Control Hub で電話番号を管理する」を参照してください。

トライアルからのサービスの購入をリクエストする

Webex サービスを試していて、トライアルから有料サブスクリプションに変更したい場合は、メールでパートナーにリクエストできます。

1

にログインし、建物のアイコン 建物のアイコン。 を選択します。

2

[サブスクリプション] タブを選択し、[今すぐ購入] をクリックします。

有料サブスクリプションへの変換に興味を持っていることを知らせるメールがパートナーに送信されます。

通話オプションを設定

Control Hub を使用して、Webex アプリでユーザーに表示する利用可能な通話オプションの優先度を設定できます。シングルクリック通話を有効にすることもできます。詳細については、次を参照してください。Webex アプリ ユーザーの通話オプションを設定する。

発信動作を設定する

ユーザーが発信するときに、どの通話アプリケーションが開くかを制御できます。Unified CM で認証されたユーザーがいる組織や、Cisco からの有料通話サービスを利用していないユーザー向けの混合モード展開など、コーリング クライアントの設定を構成できます。詳細については、次を参照してください。通話動作を設定する。

Unified CM の構成

ローカル ゲートウェイへトランクするための SIP トランク セキュリティ プロファイルを構成する

ローカル ゲートウェイと PSTN ゲートウェイが同じデバイス上に存在する場合、Unified CM を有効にして、同じデバイスから発信された 2 個の異なるトラフィックの種類 (Webex と PSTN のコール) を区別し、これらのコール タイプに対して差別化されたクラスのサービスを適用する必要があります。この差別化されたコール処理は、Unified CM および結合されたローカル ゲートウェイと PSTN ゲートウェイ デバイスの 2 つのトランクをプロビジョニングすることで行われます。これは、2 つのトランクに異なる SIP リスニング ポートを必要とします。

次の設定でローカル ゲートウェイ トランクの専用の SIP トランク セキュリティ プロファイルを作成します。

設定値
名前固有の名前 (Webex など)
説明Webex SIP トランク セキュリティ プロファイルなどの意味のある説明
着信ポートWebex 間のトラフィックでは、ローカル ゲートウェイ構成で使用されるポートと一致する必要があります。5065

ローカル ゲートウェイ トランクの SIP プロファイルを構成する

次の設定でローカル ゲートウェイ トランク用の専用の SIP プロファイルを作成します。

設定値
名前固有の名前 (Webex など)
説明Webex SIP プロファイルなどの意味のある説明
オプションの Ping を有効にして、サービス タイプ「なし (デフォルト)」のトランクの宛先ステータスをモニタします。選択

Webex からのコールのコール検索スペースを作成する

次の設定で Webex から発信されたコールのためのコール検索スペースを作成します。

設定値
名前固有の名前 (Webex など)
説明Webex Calling 検索スペースなどの意味のある説明
選択済みパーティション:

DN (+E.164 ディレクトリ番号)

ESN (サイト間ダイヤル)

PSTNInternational (PSTN アクセス)

onNetRemote (GDPR 学習先)

最後のパーティション onNetRemote は、Intercluster Lookup Service (ILS) または Global Dialplan Replication (GDPR) を使用して、Unified CM クラスター間でルーティング情報が交換されるマルチクラスター環境でのみ使用されます。

Webex 間で SIP トランクを構成する

次の設定を使用して、ローカル ゲートウェイ経由での Webex 間のコールに SIP トランクを作成します。

設定値
デバイス情報
DeviceName一意の名前 (Webex など)
説明Webex SIP トランクなどの意味のある説明
すべてのアクティブな Unified CM ノード上で実行する選択
着信コール
コール検索スペース以前に定義されたコール検索スペース:Webex
AAR コール検索スペース PSTN ルート パターンへのアクセス権のみを持つコール検索スペース: PSTNReroute
SIP 情報
接続先アドレスローカル ゲートウェイ CUBE の IP アドレス
移動先ポート5060
SIP トランク セキュリティ プロファイル定義済み:Webex
SIP プロファイル定義済み:Webex

Webex のルート グループを構成する

次の設定でルート グループを作成します。

設定値
ルート グループ情報
ルート グループ名一意の名前 (Webex など)
選択したデバイス以前に構成された SIP トランク:Webex

Webex のルート リストを構成する

次の設定でルート リストを作成します。

設定値
ルート リスト情報
名前固有の名前 (RL_Webex など)
説明Webex のルート リストなど、意味のある説明
すべてのアクティブな Unified CM ノード上で実行する選択
ルート リスト メンバー情報
選択したグループ以前に定義されたルート グループのみ:Webex

Webex の移動先のパーティションを作成する

次の設定で Webex の移動先のパーティションを作成します。

設定値
ルート リスト情報
名前一意の名前 (Webex など)
説明Webex パーティションなどの意味のある説明

次にやる必要

このパーティションは、Webex の宛先にアクセスする必要があるすべてのコール検索スペースに追加してください。このパーティションは、PSTN から Webex への発信がルーティングされるように、PSTN トランクの着信コール検索スペースとして使用されるコール検索スペースに特に追加する必要があります。

Webex の移動先のルート パターンを構成する

次の設定で Webex の各 DID 範囲のルート パターンを構成します。

設定値
ルートパターン「\」が頭文字にある Webex で DID 範囲のフル +E.164 パターン例: \+140855501XX
ルート パーティションWebex
ゲートウェイ/ルート リストRL_ Webex
緊急の優先事項選択

Webex の簡略サイト間ダイヤル正規化を構成する

短縮されたサイト間ダイヤルが Webex に必要な場合は、Webex の各 ESB 範囲にダイヤル正規化パターンを設定します。

設定値
翻訳パターンWebex の ESN 範囲の ESB パターン。例:80121XX
パーティションWebex
説明Webex 正規化パターンなどの意味のある説明
発信者のコール検索スペースを使用する選択
緊急の優先事項選択
後続ホップでの連続桁のタイムアウトを待たない選択
着信側トランスフォーム マスク番号を + E.164 に正規化するマスク。例: +140855501XX

機能をセットアップする

ハント グループをセットアップする

ハント グループは着信をグループのユーザーまたはワークスペースにルーティングします。グループ全体にルーティングするパターンを構成することもできます。

ハント グループのセットアップ方法の詳細については、「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

2

[管理] > [ユーザー] に移動します。

3

ユーザーを選択し、[Calling] をクリックします。

4

[ユーザー間権限] セクションに移動し、[割り込み] を選択します。

5

トグルをオンにすると、他のユーザーがこのユーザーの進行中のコールに自分自身を追加できるようになります。

6

このユーザーが通話に割り込みを行ったときに他の人にトーンを再生する場合は、[このユーザーが通話に割り込みを行ったときにトーンを再生する] をオンにします。

[このユーザーが通話に割り込みを行ったときにトーンを再生する] 設定は、Customer Experience Basic および Essentials スーパーバイザーの割り込み機能には適用されません。スーパーバイザに対してこのオプションを有効にした場合でも、スーパーバイザがコール キュー コールに割り込んだときに、システムはエージェントに通知トーンを再生しません。

スーパーバイザがコールに割り込んだときにエージェントにトーンを再生する場合は、[エージェントの通知トーン] 設定で有効にできます。詳細については、「Webex Customer Experience Basic 」または「Webex Customer Experience Essentials 」の「キューの作成」セクションを参照してください。

7

[保存] をクリックします。

ユーザーのプライバシーを有効化

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

パークされた通話についてこのユーザーに通知するかどうかを選択し、監視するユーザーまたはコール パーク内線番号を検索して、[保存] をクリックします。

[監視対象回線（Monitored Lines）] リストは、ユーザーのデバイスに表示される監視対象回線の順序に対応します。監視対象回線のリストをいつでも並べ替えることができます。

監視対象回線に表示される名前は、ユーザー、ワークスペース、仮想回線の [発信者 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 から使用するホテリング ホストを検索し、検索することもできます。詳細については、「どこからでも通話プロファイルにアクセスする」を参照してください。

その方法を確認したいですか? このビデオ デモンストレーション で、Control Hub でホテリングを設定する方法をご覧ください。

導入傾向と使用状況レポート

通話レポートを表示

[アナリティクス] ページを使用して、サービスの使用方法、アプリでのエンゲージメント、通話メディア エクスペリエンスの品質を確認できます。分析にアクセスするには:

1

2

[分析] に移動し、[Calling] タブを選択します。

3

[詳細な通話履歴] を選択します。

通話履歴の詳細は、メディア品質データとともに表示されます。
4

メディア品質データにアクセスするには、にサインインし、[分析] に移動し、[通話] を選択します。

関連情報

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 の管理を一元化します。

表 1YAZ設定オプション 管理者の設定可能な機能

機能

説明

自動音声応答

セットアップ メニューと、応答サービス、ハント グループ、ボイスメール ボックスや実際のオペレーターなどへのルーティング機能によって、適切なあいさつを返すことができます。24 時間分のスケジュールを作成することができます。あるいは、営業時間内か外かに応じて、異なるオプションを使うこともできます。通話は、発信者の ID 属性に応じてルーティングすることによって、VIP リストを作成したり、特定の市外局番からの通話には対応を変えたりすることができます。

コール キュー

着信通話に応答できないときに、通話キューを設定できます。誰かがコールに応答できるまで、自動応答、ご案内のメッセージ、保留中の音楽を発信者に提供できます。

通話ピックアップ

コール ピックアップ グループを作成して、ユーザーが別のユーザーの通話に応答できるようにすることで、チームワークとコラボレーションを強化できます。ユーザーをコールピックアップグループに追加しておけば、グループメンバーが席を離れていたり、電話中だったりした場合、別のメンバーが電話に出ることができます。

コール パーク

コール パークをオンにすると、ユーザがコールを保留にし、別の電話からピックアップできます。

ハントグループ

以下のようなシナリオでは、ハント グループをセットアップするのがよいでしょう。

  • セールス チームは順番に転送を求めている可能性があります。着信が電話を鳴らしても応答が無かった場合、その通話はリスト中の次のエージェントへと転送されます。

  • サポートチームは最初の対応可能なエージェントが電話に応答できるように、電話が同時に鳴ることを希望する傾向があります。

ページング グループ

ユーザーが音声メッセージを個人、部署、チームに送信できるように、ページング グループを作成できます。誰かがメッセージをページング グループに送信するとき、グループのすべてのデバイスでメッセージが再生されます。

レセプショニスト クライアント

フルセットの通話管理オプション、大規模モニタリング、コール キュー、複数のディレクトリ オプションとビュー、Outlook との統合などを提供することにより、フロントオフィス担当者のニーズを満たします。
表 2. ユーザーの設定可能な機能

機能

説明

匿名コールの拒否

ユーザーはブロックされた発信者 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 で組織をセットアップできます。これらのすべてコンポーネントを同様にそこから管理できます。

パートナー:

パートナー サービス プロバイダーは、ブランドとマーケットを設定して、Webex Calling を顧客に販売できます。トライアルをセットアップして、顧客にサービスを展開し、顧客にオーダーを作成してプロビジョニングすることもできます。

サービス開始日時

Webex Calling が販売可能な国については、『Cisco Webex はどこで利用可能か』という記事の「Webex Calling」の見出しを参照してください。

Control Hub を体験する

Control Hub は、組織の管理、ユーザーの管理、サービスの割り当て、導入の傾向や通話品質の分析などを行うための、ウェブ ベースの単一のインターフェイスです。

Control Hub のインターフェイスの概要は、左側ナビゲーションメニュー、会社情報、通知、アプリ内ヘルプ、フィードバック、言語、サインアウトのハイライトとラベル付けです。

組織を立ち上げて稼働させるには、Control Hub にメール アドレスを入力して、Webex アプリに参加するユーザーを数人招待することをおすすめします。コールを含む、提供されるサービスを使用するようにユーザーを促し、彼らの満足度に関するフィードバックを提供することを求めます。準備が完了したら、いつでもユーザーを追加することができます。

  • Control Hub は Mozilla Firefox 66 以降、Google Chrome 89 以降、Microsoft Edge 89 以降、および Apple Safari 15.1 以降を完全にサポートしています。
  • Control Hub は Internet Explorer をサポートしていません。
  • Control Hub はモバイル デバイス用には設計されていません。

以下に示す情報を、組織がサービスをセットアップし始めた場合に期待できる事柄についての、大まかな概要として用いてください。詳細および手順を追った説明については、個々のチャプターを参照してください。

使い始める

パートナーがあなたのアカウントを作成すると、ウェルカム メールが届きます。Chrome または Firefox を使用し、[はじめに] リンクをクリックして、Control Hub にアクセスます。このリンクを使うと、管理者のメール アドレスで自動的にサインインすることができます。次に、管理者パスワードを作成するためのプロンプトが表示されます。

Control Hub セットアップの開始メールから、新しいパスワード画面を作成します。

トライアルのための初回ウィザード

パートナーがトライアルに登録した場合、Control Hub にサインインすると、セットアップウィザードが自動的に開始します。このウィザードでは、Webex Calling などのサービスで組織を立ち上げて稼働させるための基本設定を案内します。ウィザードのガイドを終えると、Calling の設定とその確認が完了します。

Control Hub の初回セットアップ ウィザード。

設定の確認

Control Hub がロードされると、設定を確認できます。

Control Hub の概要ページ。

ユーザーの追加

サービスをセットアップしたら、会社ディレクトリからユーザーを追加する準備ができます。[ユーザー] > [ユーザーの管理] に移動します。

Control Hub でユーザー ポップアップ ウィンドウを管理します。

Microsoft Active Directory を使用する場合、まずディレクトリ同期 を有効にして、ユーザーを追加する方法を決定することをお勧めします。[次へ] をクリックし、指示に従って Cisco Directory Connector を設定します。

シングル サインオン (SSO) の設定

Webex アプリは基本認証を使用します。 SSO をセットアップして、ユーザーが Webex に保存され、管理される別のパスワードではなく、エンタープライズ クレデンシャルを使用してエンタープライズ ID プロバイダーで認証されるようにできます。

[設定] > [認証] > [変更] の順に移動し、[サードパーティ ID プロバイダーを統合する] を選択します。

[サードパーティ プロバイダーを統合] オプションが選択されているシングル サインオン設定画面です。

サービスをユーザーに割り当てる

ユーザーが Webex アプリの使用を開始するために、追加したユーザーにサービス を割り当てる必要があります。

[ユーザー] > [ユーザーの管理] > [CSV ファイルでユーザーをエクスポートしてインポートする] の順に移動し、[エクスポート] をクリックします。

ダウンロードしたファイルで、各ユーザーに割り当てるサービスに対して True を追加します。

Control Hub でユーザーにサービスを割り当てるための CSV ファイルの例。

完了したファイルをインポートし、[サービスの追加および削除] をクリックして、[提出] をクリックします。これで、コール機能を構成し、共通場所で共有できるデバイスを登録し、デバイスを登録してユーザーに関連付ける準備ができました。

ユーザーを支援する

これで、ユーザーを追加し、サービスを割り当て済みです。メッセージングとミーティングのために、Webex Calling および Webex アプリでサポートされているマルチプラットフォーム電話 (MPP ) の使用を開始できます。アクセスのためのワンストップ ショップとして [設定] を使用することを推奨します。

ローカル ゲートウェイの役割

ローカル ゲートウェイは、エンタープライズまたはパートナーにより管理されているエッジ デバイスです。これは、パブリックスイッチのテレフォニー ネットワーク (PSTN) の相互動作と従来型のプライベート ブランチ エクスチェンジ (PBX) との動作のためのものです (Unified CM を含む)。

ローカル ゲートウェイをロケーションに割り当てるには Control Hub を使用します。その後、CUBE で設定できるパラメーターが Control Hub により提供されます。これらの手順により、ローカル ゲートウェイがクラウドに登録され、ゲートウェイを通じて PSTN サービスが特定のロケーションの Webex Calling ユーザーに対して提供されます。

ローカル ゲートウェイを指定して注文するには、「ローカルゲートウェイの注文ガイド」を参照してください。

Webex Calling 向けにサポートされているローカル ゲートウェイの展開

次の基本的な展開がサポートされています。

ローカル ゲートウェイは、Cisco Unified Communications Manager へのインテグレーションが必要な場合、スタンドアロンまたは導入で展開することができます。

オンプレミスの IP PBX なしのローカル ゲートウェイ展開

スタンドアロンのローカル ゲートウェイ展開

この図は既存の IP PBX がない場合の Webex Calling 展開を示しており、単一の場所または複数の場所のどちらの展開でも適用できます。

既存の IP PBX を使用しない Webex Calling の展開を示す図。

Webex Calling の宛先に一致しないすべてのコールについては、Webex Calling は処理の場所に割り当てられているローカル ゲートウェイにそれらのコールを送信します。ローカルゲートウェイは、Webex Calling から PSTN に送られるすべてのコールと、反対方向に PSTN から Webex Calling に送られるコールのルーティングを行います。

PSTN ゲートウェイは、ローカル ゲートウェイの専用プラットフォームまたは共存プラットフォームになります。次の図のように、この展開の専用の PSTN ゲートウェイのバリエーションをお勧めします。既存の PSTN ゲートウェイを Webex Calling のローカル ゲートウェイとして使用できない場合に使用できます。

既存の PSTN ゲートウェイを Webex Calling ローカル ゲートウェイとして使用できない場合に使用できる、推奨された PSTN ゲートウェイの展開オプションを示すイラスト。

共存型のローカル ゲートウェイの展開

ローカル ゲートウェイとして、ITSP に接続するために SIP トランクを使用する IP ベースのもの、または ISDN またはアナログ回路を使用する TDM ベースのものを使用できます。次の図は、ローカル ゲートウェイが PSTN GW/SBC と共存している場合の、Webex Calling の展開を示しています。

ローカル ゲートウェイが 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 の展開を示しています。

顧客が既存の 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 ゲートウェイを Webex Calling ローカル ゲートウェイとして使用できない場合に使用できる推奨オプション。

共存型 PSTN ゲートウェイ

この図は、ローカル ゲートウェイが PSTN ゲートウェイ/SBC と共存している場合の、Webex Calling と Unified CM の展開を示しています。

Webex Callingの 宛先に一致 しないすべての通話を、ロケーションWebex Calling割り当てられたローカル ゲートウェイにルーティングします。これには、PSTN の宛先と、Unified CM 内部の内線に向けたオンネット コールが含まれます。ローカルゲートウェイは、すべてのコールを Unified CM にルーティングします。その後、Unified CM は PSTN/SBC 機能が共存している ローカル ゲートウェイを通じて、コールをローカルに登録された電話または PSTN にルーティングします。

ローカル ゲートウェイが PSTN ゲートウェイ/SBC と共存する Unified CM を使用した Webex Calling の展開を示しています。

コール ルーティングの考慮点

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 ユーザーを示しています。

米国内の国番号をダイヤルする Webex Calling ユーザーの図です。

Unified CM は、構成済みのダイヤルプランに基づいて、発信先が電話帳としてプロビジョニングされている、ローカルに登録されたエンドポイントにルーティングします。このため、Unified CM のダイヤル プランは + E.164 番号のルーティングをサポートする必要があります。

Unified CM から Webex Calling へのコール

Unified CM から Webex Calling へのコール ルーティングを Unified CM で有効にするには、一連のルートをプロビジョニングして、Webex Calling での +E.１６４ プラン アドレスとエンタープライズ番号の組み合わせを定義する必要があります。

これらのルートを構成することにより、次の図に示されているコール シナリオの両方が可能になります。

Unified CM のルートのセットで Unified CM から Webex Calling へのコール ルーティングを示す図。

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 宛先にアクセスできる必要があります。

PST と Webex Calling からの通話の差別化された CoS の図。
PSTN と Webex Calling からのコールに対応する差別化された CoS

この図は、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 宛先を表すパーティションが作成され ("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://

Mac または Windows のデフォルトの通話アプリケーションの場合、Webex アプリで音声またはビデオ通話を開始するプロトコル ハンドラのリスト。

Windows 用プロトコル ハンドラー

他のアプリは Webex アプリの前にプロトコル ハンドラーに 登録できます。Windows 10 では、通話を開始するために使用するアプリを選択するためにユーザーに尋ねるシステム ウィンドウ。ユーザーは、[常にこのアプリを使う] にチェックを入れて、記憶させることができます。

Windows 10 「アプリを選択」を選択するオプションとして Webex が強調表示されます。

ユーザーが Webex アプリを選択するために、デフォルトの通話アプリ設定をリセットする必要がある場合、Windows 10 の Webex アプリのプロトコル関連付けを変更するように指示できます。

  1. [デフォルトのアプリ設定] システム設定を開き、[アプリごとにデフォルトを設定する] をクリックして、[Webex アプリ] を選択します。

    Windows 10 の [アプリごとにデフォルトを設定する] で、Webex を選択するオプションとして強調表示されます。

  2. 各プロトコルに対して、[Webex アプリ] を選択します。

    ファイル タイプとプロトコルの関連付けのための Windows 10 Webex オプション。

macOS 用のプロトコルハンドラー

Mac OS では、 Webex アプリの前に通話プロトコルに登録されている他のアプリがある場合、ユーザーは Webex アプリ をデフォルトの通話オプションに設定する必要があります。

Mac 版 Webex アプリでは、ユーザーは一般的な基本設定で [通話を開始] 設定に [Webex アプリ] が選択されていることを確認できます。また、Outlook の連絡先の番号をクリックしたときに Webex アプリで発信する場合、[常に Microsoft Outlook に接続する] をオンにすることもできます。

Mac OS プロトコル ハンドラ設定、[常に Microsoft Outlook に接続] オプションを選択し、[コールを開始] ドロップダウンで Webex が選択されています。

環境を準備する

全般的な前提条件

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 注文ガイド」の表 1 を参照してください。また、ローカル ゲートウェイ構成ガイドに従って、プラットフォームがサポートされている IOS-XE リリースを実行していることを確認してください。

ローカル ゲートウェイは、自分のペースで 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 アプリのプロキシ アドレスを手動で設定します。

希望の製品タイプを設定するときに、表で次のプロキシ設定と認証タイプを選択します。

製品

プロキシの設定

認証タイプ

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

表の凡例の場合:

  1. †Mac NTLM 認証 - マシンはドメインにログインする必要はなく、ユーザーはパスワードの入力を求められます

  2. †Windows NTLM 認証 - マシンがドメインにログインしている場合にのみサポートされます

  3. ネゴシエート †- NTLM フォールバック認証で Kerberos。

  4. Cisco Webex Board、Desk、または Room シリーズのデバイスをプロキシ サーバーに接続するには、「Board、Desk、または Room シリーズのデバイスをプロキシ サーバーに接続する」を参照してください。

  5. Cisco IP 電話の場合、プロキシ サーバーと設定を構成する例として、プロキシ サーバーのセットアップ を参照してください。

No Authentication の場合、認証をサポートしていないプロキシ アドレスでクライアントを設定します。Proxy Authentication を使用する場合、有効な資格情報で構成します。Web トラフィックを検査するプロキシは、Web ソケット接続に干渉する場合があります。この問題が発生した場合、*.Webex.com への検査を行わないトラフィックをバイパスすると問題が解決する可能性があります。すでに他のエントリが表示されている場合は、最後のエントリの後にセミコロンを追加し、Webex 例外を入力します。

Windows OS のプロキシ設定

Microsoft Windows は、プロキシ設定を許可する HTTP トラフィック (WinINet および WinHTTP) のための 2 つのネットワーク ライブラリをサポートしています。WinINet は WinHTTP のスーパーセットです。

  1. WinInet は、シングルユーザーのデスクトップ クライアント アプリケーション用に設計されています

  2. 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 サービス

  1. アイデンティティ プロビジョニング

  2. アイデンティティ ストレージ

  3. 認証

  4. OAuth サービス

  5. オンボードのデバイス

  6. クラウド接続 UC

電話機を初めてネットワークに接続する場合、または 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 マイクロサービス。

  1. プロファイル画像サービス

  2. ホワイトボード サービス

  3. Proximity サービス

  4. プレゼンス サービス

  5. 登録サービス

  6. カレンダー サービス

  7. 検索サービス

すべて

*.webexcontent.com

一般的なファイル ストレージに関する Webex メッセージング サービス:

  1. ユーザー ファイル

  2. トランスコードされたファイル

  3. イメージ

  4. スクリーンショット

  5. ホワイトボードの内容

  6. クライアントとデバイスのログ

  7. プロファイル画像

  8. ブランディング ロゴ

  9. ログ ファイル

  10. CSV エクスポート ファイルの一括インポート (Control Hub)

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-65535TCP「Webex Calling サービスの IP サブネット」を参照してください。5062, 8934

これらの IP/ポートは、ローカル ゲートウェイ、デバイス、および Webex アプリ アプリケーション (ソース) から Webex Calling クラウド (宛先) への発信 SIP-TLS コール シグナリングに必要です。

ポート 5062（証明書ベースのトランクに必要）。およびポート 8934 (登録ベースのトランクに必要)

デバイス5060-50808934
Webex アプリ 一時的 (OS 依存)
Webex Calling (SIP TLS) からローカル ゲートウェイへのコール シグナリング

Webex Calling のアドレス範囲。

「Webex Calling サービスの IP サブネット」を参照してください。

8934TCPローカル ゲートウェイに顧客が選択した IP または IP 範囲ローカル ゲートウェイに顧客が選択したポートまたはポート範囲

証明書ベースのローカル ゲートウェイに適用されます。Webex Calling からローカル ゲートウェイへの接続を確立する必要があります。

登録ベースのローカル ゲートウェイは、ローカル ゲートウェイから作成された接続を再利用することで機能します。

宛先ポートは、[トランクの設定] を選択した顧客です。

Webex Calling へのコール メディア (STUN、SRTP/SRTCP、T38、DTLS)ローカル ゲートウェイ外部 NIC8000-48199†*UDP「Webex Calling サービスの IP サブネット」を参照してください。

5004、9000 (STUN ポート)

音声: 8500-8599

ビデオ: 8600-8699

19560-65535 (UDP 経由の SRTP)

  • これらの IP/ポートは、ローカル ゲートウェイ、デバイス、および Webex アプリ アプリケーション (ソース) から Webex Calling クラウド (宛先) への発信 SRTP コール メディアに使用されます。

  • STUN、ICE ネゴシエーションが成功している組織内の通話の場合、通信パスとしてクラウドのメディアリレーが削除されます。このような場合、メディア フローはユーザーのアプリ/デバイス間で直接行われます。

    例: メディア最適化が成功すると、Webex アプリはポート範囲 8500 ～ 8699 で互いに直接メディアを送信し、デバイスは 19560 ～ 19661 で互いに直接メディアを送信します。

  • 顧客のプレミス内でファイアウォールが使用される特定のネットワーク トポロジでは、メディアがフロースルーするために、ネットワーク内の前述の送信元と宛先ポート範囲へのアクセスを許可します。

    例：Webex アプリでは、送信元と送信先のポート範囲を許可します

    音声: 8500-8599 ビデオ:8600-8699

  • ブラウザは、管理対象デバイス管理（MDM）プロファイルで WebRtcUdpPortRange ポリシーを設定することで制御できる一時的なソース ポートを使用します。

    MDM サービスが設定されていない場合、または SiteURL と EnableForceLogin が設定されていない 場合、Webex Calling サービスは通常どおりに動作します。

デバイス†*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)ローカル ゲートウェイ内部 NIC8000-65535TCPITSP、PSTN GW または Unified CMPSTN オプションによって異なる (たとえば、Unified CM の 5060 または 5061)
PSTN ゲートウェイへのコール メディア (SRTP/SRTCP)ローカル ゲートウェイ内部 NIC8000-48199†*UDPITSP、PSTN GW または Unified CMPSTN オプションによって異なります（たとえば、Unified CM の場合は 5060 または 5061）
デバイスの構成とファームウェアの管理 (Cisco デバイス)Webex Calling デバイス一時的TCP

「Webex Calling サービスの IP サブネット」を参照してください。

443, 6970, 80

次の理由で必須:

  1. エンタープライズ電話 (Cisco Unified CM) から Webex Calling への移行。詳細については、upgrade.cisco.com を参照してください。cloudupgrader.webex.com はポートを使用します。ファームウェア移行プロセスの 6970,443。

  2. 16 桁のアクティベーション コード (GDS) を使用したデバイス (MPP および Room または Desk Phone) のファームウェアのアップグレードと安全なオンボーディング

  3. CDA / EDOS - MAC アドレスベースのプロビジョニング。新しいファームウェアを持つデバイス（MPP 電話、ATA、SPA ATA）で使用されます。

  4. Cisco ATA の場合、デバイスが最小ファームウェア 11.1.0MSR3-9 にあることを確認します。

  5. 電話機が初めてネットワークに接続する場合、または初期設定へのリセット後に、DHCP オプションが設定されていない場合は、ゼロ タッチ プロビジョニング用のデバイス アクティベーション サーバに接続します。新しい電話は、プロビジョニングのために webapps.cisco.com の代わりに activate.cisco.com を使用します。11.2(1) より前にリリースされたファームウェアを搭載した電話機は、引き続き webapps.cisco.com を使用します。すべての IP サブネットを許可することをお勧めします。

  6. 12.0.3 バージョンより古い Cisco マルチプラットフォーム フォン (MPP) が、ポート 80 から sudirenewal.cisco.com にアクセスして、製造元でインストールされた証明書 (MIC) を更新し、セキュアな一意のデバイス識別子 (SUDI) を持つことを許可します。詳細については、フィールド通知を参照してください。

Webex アプリの設定Webex アプリ アプリケーション一時的TCP

「Webex Calling サービスの IP サブネット」を参照してください。

443, 8443Id ブローカー認証、クライアントの Webex アプリ構成サービス、セルフケアおよび管理インターフェイス アクセスのためのブラウザベースの Web アクセスに使用されます。
TCP ポート 8443 は、構成をダウンロードするために Cisco Unified CM セットアップの Webex アプリで使用されます。Webex Calling に接続するためにセットアップを使用する顧客のみがポートを開く必要があります。
デバイス時間同期 (NTP)Webex Calling デバイス51494UDP「Webex Calling サービスの IP サブネット」を参照してください。123これらの IP アドレスは、デバイス（MPP 電話、ATA、SPA ATA）の時間同期に必要です。

ドメイン ネーム システム（DNS）の解決

Webex Calling デバイス、Webex アプリ、Webex デバイス一時的UDP および TCP主催者が定義53DNS ルックアップでクラウドの Webex Calling サービスの IP アドレスを検出するために使用されます。典型的な DNS ルックアップは UDP で行われますが、クエリ応答が UDP パケットに収まらない場合、TCP が必要な場合があります。
ネットワーク タイム プロトコル (NTP)Webex アプリと Webex デバイス123UDP主催者が定義123時間同期
CScanWebex Calling の Web ベースのネットワーク準備事前資格ツール一時的TCP「Webex Calling サービスの IP サブネット」を参照してください。8934 および 443Webex Calling の Web ベースのネットワーク準備事前資格ツールです。詳細については、cscan.webex.com を参照してください。
UDP19569-19760
追加の Webex Calling および Webex Aware サービス (サードパーティ)
プッシュ通知 APNS および FCM サービス Webex Calling アプリケーション 一時的TCP

リンクの下に記載されている IP サブネットを参照してください

Apple プッシュ通知サービス (APNS)

Google-Firebase クラウド メッセージング (FCM)

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 のネットワーク要件

政府版 Webex サービスのドメイン、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 日

次の詳細で更新されました。

  • Webex Calling (アプリ、デバイス) でサポートされている QoS (TOS/DSCP) 値

  • ネットワーク図を更新しました

  • Webex アテンダントコンソールに関連するネットワーク要件のリンクを含める。

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 日

記事全体を見直して、以下を含めました。

  1. プロキシ サポートのオプションが含まれています。

  2. 変更された通話フロー図

  3. Webex Calling および Webex Aware サービスの簡素化されたドメイン/URL/IP サブネット部分

  4. Webex Calling および Webex Aware サービスに対して 170.72.0.0/16 IP サブネット範囲を追加しました。

    次の範囲 170.72.231.0、170.72.231.10、170.72.231.161 および 170.72.242.0/24 を削除しました。

2023年3月5日

記事を更新して、以下を含めます。

  • アプリケーションで使用される UDP-SRTP ポート範囲（8500～8700）を追加しました。

  • プッシュ通知 APNS および FCM サービスのポートを追加しました。

  • UDP と TCP の CScan ポート範囲を分割します。

  • リファレンス セクションを追加しました。

2022 年 11 月 15 日

デバイス構成とファームウェア管理 (Cisco デバイス) に次の IP アドレスを追加しました。

  • 170.72.231.0

  • 170.72.231.10

  • 170.72.231.161

デバイス構成とファームウェア管理 (Cisco デバイス) から次の IP アドレスを削除しました。

  • 3.20.118.133

  • 3.20.228.133

  • 3.23.144.213

  • 3.130.125.44

  • 3.132.162.62

  • 3.140.117.199

  • 18.232.241.58

  • 35.168.211.203

  • 50.16.236.139

  • 52.45.157.48

  • 54.145.130.71

  • 54.156.13.25

  • 52.26.82.54

  • 54.68.1.225

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 機能

  • ソース アドレス: Webex Calling デバイス

  • ソースポート: 一時的

  • プロトコルTCP

  • 宛先アドレス: 「Webex Meetings/Messaging - ネットワーク要件」で定義されている IP サブネットとドメインを参照してください。

  • 宛先ポート: 443

    メモ: Webex Calling デバイスは、これらの IP アドレスとドメインを使用して、ディレクトリ、通話履歴、ミーティングなどの Webex クラウド サービスとインターフェイスします。

[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しました。

  • 23.89.40.0/25

  • 23.89.1.128/25

2022 年 3 月 29 日

このサービスに以下の IP サブネットWebex Callingしました。

  • 23.89.33.0/24

  • 150.253.209.128/25

2021 年 9 月 20 日

Webex Calling サービスに 次の 4 つの新しい IP サブネットが追加されました。

  • 23.89.76.128/25

  • 170.72.29.0/24

  • 170.72.17.128/25

  • 170.72.0.128/25

2021 年 4 月 2 日

[Webex Calling サービスのドメインと URL] で *.ciscospark.com を追加し、Webex アプリで Webex Calling の使用事例をサポートします。

2021 年 3 月 25 日

activate.cisco.com に 6 つの新しい IP 範囲が追加されました。これは 2021 年 5 月 8 日から有効になります。

  • 72.163.15.64/26

  • 72.163.15.128/26

  • 173.36.127.0/26

  • 173.36.127.128/26

  • 192.133.220.0/26

  • 192.133.220.64/26

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 デバイス) の簡素化された範囲に移動します。

activate.cisco.com

  • 72.163.10.125 -> 72.163.10.96/27

  • 173.37.149.125 -> 173.37.149.96/27

webapps.cisco.com

  • 173.37.146.134 -> 173.37.146.128/25

  • 72.163.10.134 -> 72.163.10.128/25

Cisco Webex クライアントは 2021 年 3 月にオーストラリアで新しい DNS SRV をポイントしているため、アプリケーション構成に次の IP アドレスを追加します。

  • 199.59.64.237

  • 199.59.67.237

2021 年 1 月 21 日

次の IP アドレスを、デバイス構成とファームウェア管理 (Cisco デバイス) に追加しました。

  • 3.134.166.179

  • 50.16.236.139

  • 54.145.130.71

  • 72.163.10.125

  • 72.163.24.0/23

  • 173.37.26.0/23

  • 173.37.146.134

デバイス構成とファームウェア管理 (Cisco デバイス) から次の IP アドレスを削除しました。

  • 35.172.26.181

  • 52.86.172.220

  • 52.203.31.41

次の IP アドレスをアプリケーション構成に追加しました。

  • 62.109.192.0/19

  • 64.68.96.0/19

  • 207.182.160.0/19

  • 150.253.128.0/17

次の IP アドレスをアプリケーション構成から削除しました。

  • 64.68.99.6

  • 64.68.100.6

アプリケーション構成から次のポート番号を削除しました。

  • 1081, 2208, 5222, 5280-5281, 52644-52645

次のドメインをアプリケーション構成に追加しました。

  • idbroker-b-us.webex.com

  • idbroker-eu.webex.com

  • ty6-wxt-jp.bcld.webex.com

  • os1-wxt-jp.bcld.webex.com

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 アドレスを使用して、通話シグナリングおよびメディア エントリを更新しました。

  • 139.177.64.0/24

  • 139.177.65.0/24

  • 139.177.66.0/24

  • 139.177.67.0/24

  • 139.177.68.0/24

  • 139.177.69.0/24

  • 139.177.70.0/24

  • 139.177.71.0/24

  • 139.177.72.0/24

  • 139.177.73.0/24

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 アドレスが追加されました。

  • Webex Calling への信号発信 (SRTP)—135.84.173.0/25、135.84.174.0/25、199.19.197.0/24、199.19.199.0/24

  • パブリックアドレスエンドポイントへのコールシグナリング（SIP TLS）:135.84.173.0/25、135.84.174.0/25、199.19.197.0/24、199.19.199.0/24。

  • デバイスの構成とファームウェアの管理 (Cisco デバイス) —135.84.173.155、135.84.174.155

  • デバイス時刻の同期—135.84.173.152、135.84.174.152

  • アプリケーションの構成—135.84.173.154、135.84.174.154

2020 年 7 月 22 日

カナダのデータセンターの導入をサポートするために、次の IP アドレスを追加しました。135.84.173.146

2020 年 6 月 9 日

CScan エントリに次の変更を行いました:

  • IP アドレスの 1 つを修正しました。199.59.67.156 から 199.59.64.156 に変更されました。

  • 新しい機能には、新しいポートと UDP（19560-19760）が必要です。

2020/03/11

次のドメインと IP アドレスをアプリケーション構成に追加しました。

  • jp.bcld.webex.com—135.84.169.150

  • client-jp.bcld.webex.com

  • idbroker.webex.com—64.68.99.6, 64.68.100.6

追加の IP アドレスを持つ以下のドメインをデバイスの設定とファームウェア管理に更新しました:

  • cisco.webexcalling.eu—85.119.56.198, 85.119.57.198

  • webapps.cisco.com—72.163.10.134

  • activation.webex.com—35.172.26.181, 52.86.172.220

  • cloudupgrader.webex.com—3.130.87.169, 3.20.185.219

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 で 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 メッセージの処理を提供し、それらを必要なターゲットにルーティングします。

PSTN から Webex Calling 構成ソリューションへのコール ルーティング

IP および SIP は PSTN トランクのデフォルトのプロトコルになっていますが、TDM (時間分割多重化) ISDN 回路は広く使用され、Webex Calling トランクでサポートされています。TDM-IP コール フローを持つローカル ゲートウェイの IP パスのメディア最適化を有効にするには、現在、2 レッグ コール ルーティング プロセスを使用する必要があります。このアプローチでは、下の画像に示すように、Webex Calling と PSTN トランク間に一連の内部ループバックダイヤルピアを導入することで、上記のコール ルーティング設定を変更します。

Webex Calling と PSTN トランク間の内部ループバックダイヤルピアのセットを使用したコール ルーティング設定

オンプレミスの Cisco Unified Communications Manager ソリューションを Webex Calling に接続する場合、以下の図に示すソリューションを構築するためのベースラインとして、シンプルな PSTN ゲートウェイ構成を使用できます。この場合、Unified Communications Manager は、すべての PSTN および Webex Calling コールのルーティングと処理を一元化します。

Unified Communications Manager がすべての PSTN および Webex Calling コールのルーティングと処理を一元化したソリューションダイアグラム

このドキュメントでは、次の画像に示すホスト名、IP アドレス、およびインターフェイスが使用されます。

コール ルーティング設定ソリューションで使用されるホスト名、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 インターフェイスに割り当てることを確認します。


interface GigabitEthernet0/0/0
  description Interface facing PSTN and/or CUCM
  ip address 10.80.13.12 255.255.255.0
!
interface GigabitEthernet0/0/1
  description Interface facing Webex Calling (Private address)
  ip address 192.51.100.1 255.255.255.240

2

対称暗号化を使用して、ルータの登録と STUN クレデンシャルを保護します。プライマリ暗号化キーと暗号化タイプを次のように設定します。


key config-key password-encrypt YourPassword
password encryption aes

3

プレースホルダー PKI トラストポイントを作成します。

後で TLS を設定するには、このトラストポイントが必要です。登録ベースのトランクの場合、このトラストポイントは証明書を必要としません。証明書ベースのトランクでも必須です。


crypto pki trustpoint EmptyTP 
 revocation-check none
4

TLS1.2 の排他性を有効にし、次の設定コマンドを使用してデフォルトのトラストポイントを指定します。トランスポート パラメータも更新して、登録の信頼性の高い安全な接続を確保する必要があります。

cn-san-validate サーバ コマンドにより、テナント 200 で設定されたホスト名がアウトバウンド プロキシから受信した証明書の CN または SAN フィールドに含まれている場合、ローカル ゲートウェイが接続を許可します。

  1. tcp-retry count を 1000 に設定します (5-msec multiples = 5 秒)。

  2. タイマー接続を確立する コマンドを使用すると、次に使用可能なオプションを考慮する前に、LGW がプロキシとの接続をセットアップするのを待つ時間を調整できます。このタイマーのデフォルトは 20 秒、最小は 5 秒です。低値で開始し、ネットワーク条件に対応するために必要に応じて増加します。


sip-ua
 timers connection establish tls 5
 transport tcp tls v1.2
 crypto signaling default trustpoint EmptyTP cn-san-validate server
 tcp-retry 1000

5

Webex Calling で使用される DigiCert CA 証明書を含む Cisco ルート CA バンドルをインストールします。crypto pki trustpool import clean url コマンドを使用して、指定された URL からルート CA バンドルをダウンロードし、現在の CA トラストプールをクリアし、証明書の新しいバンドルをインストールします。

HTTPS を使用してインターネットにアクセスするためにプロキシを使用する必要がある場合は、CA バンドルをインポートする前に次の設定を追加してください。

ip http クライアント プロキシ サーバ yourproxy.com プロキシ ポート 80

ip http client source-interface GigabitEthernet0/0/1 
crypto pki trustpool import clean url https://www.cisco.com/security/pki/trs/ios_core.p7b
Webex Calling 登録ベースのトランクを設定
1

Control Hub の既存のロケーションに対して登録ベースの PSTN トランクを作成します。トランクが作成されると、提供されたトランク情報をメモします。図でハイライトされている詳細は、このガイドの設定手順で使用されます。詳細については、「Webex Calling のトランク、ルート グループ、ダイヤル プランを構成する」を参照してください。

PSTN トランクが登録されました
2

次のコマンドを入力して、CUBE を Webex Calling ローカル ゲートウェイとして設定します。

 
voice service voip
 ip address trusted list
  ipv4 x.x.x.x y.y.y.y
 mode border-element
 media statistics
 media bulk-stats 
 allow-connections sip to sip
 no supplementary-service sip refer  
 stun
  stun flowdata agent-id 1 boot-count 4
  stun flowdata shared-secret 0 Password123$
 sip
  asymmetric payload full
  early-offer forced

以下は、設定のフィールドの説明です。


ip address trusted list
 ipv4 x.x.x.x y.y.y.y

  • 有料詐欺から保護するために、信頼できるアドレス リストは、ローカル ゲートウェイが合法的な VoIP コールを期待するホストとネットワークのリストを定義します。

  • デフォルトでは、ローカル ゲートウェイは、信頼リストに含まれていない IP アドレスからのすべての着信 VoIP メッセージをブロックします。デフォルトでは、「セッション ターゲット IP」またはサーバ グループ IP アドレスを持つ静的に設定されたダイヤル ピアが信頼されます。これらの IP アドレスを信頼リストに追加する必要はありません。

  • ローカル ゲートウェイを設定する場合は、地域の Webex Calling データ センターの IP サブネットをリストに追加します。詳細については、「Webex Calling のポート参照情報」を参照してください。また、Unified Communications Manager サーバ（使用されている場合）と PSTN トランク ゲートウェイのアドレス範囲を追加します。

    LGW が制限付きコーン NAT のあるファイアウォールの背後にある場合は、Webex Calling に面したインターフェイスの IP アドレスの信頼リストを無効にすることをおすすめします。ファイアウォールはすでに、未承諾のインバウンドメッセージから保護VoIP。[無効にする] アクションは、Webex Calling ピアのアドレスが固定されたままである保証を保証できないので、長期構成のオーバーヘッドを削減します。また、いかなる場合にも、ピアに対してファイアウォールを構成する必要があります。

モードの境界要素

プラットフォームで Cisco Unified Border Element（CUBE）機能を有効にします。

メディア統計

ローカル ゲートウェイ上のメディア監視が可能です。

メディア一括統計

一括通話統計のために、コントロール飛行機がデータ 飛行機をポーリングできます。

これらのコマンドの詳細については、メディアを参照してください。

allow-connections sip to sip

CUBE 基本 SIP バックツーバックのユーザー エージェント機能を有効にします。詳細については、「接続を許可する」を参照してください。

デフォルトでは、T.38 ファックス トランスポートが有効になっています。詳細については、ファックス プロトコル t38 (音声サービス) を参照してください。

ストーン

STUN (NAT 経由の UDP のセッション トラバーサル) をグローバルに有効にします。

  • ローカル ゲートウェイの STUN バインディング機能を使用すると、ネゴシエートされたメディア パスを介して、ローカルで生成された STUN 要求を送信できます。これにより、ファイアウォールのピンホールを開くことができます。

詳細については、stun flowdata agent-id および stun flowdata shared-secret を参照してください。

非対称ペイロード (フル)

DTMF と動的コーデック ペイロードの両方に対して SIP 非対称ペイロード サポートを設定します。詳細については、非対称ペイロードを参照してください。

early-offer forced

ローカル ゲートウェイが、隣接ピアからの確認応答を待つ代わりに、最初の INVITE メッセージで SDP 情報を送信するように強制します。このコマンドの詳細については、早期オファーを参照してください。

3

すべてのトランクに対して G.711 コーデックのみを許可する音声クラス コーデック 100 を設定します。このシンプルなアプローチは、ほとんどの導入に適しています。必要に応じて、発信元システムと終端システムの両方でサポートされている追加のコーデック タイプをリストに追加できます。

DSP モジュールを使用したトランスコーディング を含むより複雑なソリューションはサポートされていますが、このガイドには含まれていません。 


voice class codec 100
 codec preference 1 g711ulaw
 codec preference 2 g711alaw

以下は、設定のフィールドの説明です。

音声クラス コーデック 100

SIP トランク コールの優先コーデックのみを許可するために使用されます。詳細については、音声クラス コーデックを参照してください。

4

音声クラス stun-usage 100 を設定して、Webex Calling トランクで ICE を有効にします。


voice class stun-usage 100 
 stun usage firewall-traversal flowdata
 stun usage ice lite

以下は、設定のフィールドの説明です。

STUNの使用法ice lite

可能なときは常に、メディア最適化を可能にする、すべての Webex Calling でダイヤルピアで ICE-Lite を有効にします。詳細については、音声クラス stun 使用状況 および使用状況のice liteを参照してください。

メディアの最適化は、可能な限り、ネゴシエートされます。通話に録画などのクラウド メディア サービスが必要な場合、メディアを最適化できません。

5

Webex トラフィックのメディア暗号化ポリシーを設定します。


voice class srtp-crypto 100
 crypto 1 AES_CM_128_HMAC_SHA1_80

以下は、設定のフィールドの説明です。

音声クラス srtp-crypto 100

オファーと応答メッセージの SDP で唯一の SRTP 暗号スイート CUBE が提供されるため、SHA1_80 を指定します。Webex Calling は SHA1_80 のみをサポートします。詳細については、「voice class srtp-crypto」を参照してください。

6

宛先トランク パラメータに基づいて、ローカル ゲートウェイ トランクへのコールを識別するパターンを設定します。 


voice class uri 100 sip
 pattern dtg=dallas1463285401_lgu

以下は、設定のフィールドの説明です。

音声クラス uri 100 sip

着信 SIP 招待を着信トランクダイヤルピアに一致させるパターンを定義します。このパターンを入力する場合は、dtg= の後に、トランクが作成されたときに Control Hub で提供されるトランク OTG/DTG 値を使用します。詳細については、音声クラス uri を参照してください。

7

SIP メッセージが Webex Calling に送信される前に、変更するために使用される sip プロファイル 100 を構成します。


voice class sip-profiles 100
 rule 10 request ANY sip-header SIP-Req-URI modify "sips:" "sip:"
 rule 20 request ANY sip-header To modify "" "" 
 rule 50 response ANY sip-header To modify "" ";otg=dallas1463285401_lgu>"
 rule 90 request ANY sip-header P-Asserted-Identity modify "sips:" "sip:"

以下は、設定のフィールドの説明です。

  • ルール 10 ～ 70 および 90

    コール シグナリングに使用される SIP ヘッダーが、Webex プロキシが必要な SIP スキームではなく、SIP を使用するようにします。SIP を使用するために CUBE を設定することで、セキュアな登録が使用されます。

  • ルール 80

    エンタープライズ内のローカル ゲートウェイ サイトを一意に識別するために、Control Hub からトランク グループ OTG/DTG 識別子を含めるために、From ヘッダーを変更します。

米国またはカナダの PSTN プロバイダーは、Webex Calling のスパムまたは詐欺通話の表示 の記事で言及されている追加設定を使用して、スパムおよび詐欺通話の発信者 ID 検証を提供できます。

8

Webex Calling トランクの設定:

  1. 音声クラス テナント 100 を作成して、Webex Calling トランクに特別に必要な設定を定義し、グループ化します。特に、以前の Control Hub で提供されたトランク登録の詳細は、以下の詳細に従って、このステップで使用されます。このテナントに関連付けられているダイヤルピアは、後でこれらの設定を継承します。

    次の例では、ステップ 1 で説明されている値を、このガイドの目的で使用しています（太字で示されています）。設定内のトランクの値に置き換えます。

    
voice class tenant 100
  registrar dns:98027369.us10.bcld.webex.com scheme sips expires 240 refresh-ratio 50 tcp tls
  credentials number Dallas1171197921_LGU username Dallas1463285401_LGU password 0 9Wt[M6ifY+ realm BroadWorks
  authentication username Dallas1463285401_LGU password 0 9Wt[M6ifY+ realm BroadWorks
  authentication username Dallas1463285401_LGU password 0 9Wt[M6ifY+ realm 98027369.us10.bcld.webex.com
  no remote-party-id
  sip-server dns:98027369.us10.bcld.webex.com
  connection-reuse
  srtp-crypto 100
  session transport tcp tls 
  no session refresh
  url sips 
  error-passthru
  rel1xx disable
  asserted-id pai 
  bind control source-interface GigabitEthernet0/0/1
  bind media source-interface GigabitEthernet0/0/1
  no pass-thru content custom-sdp 
  sip-profiles 100 
  outbound-proxy dns:dfw04.sipconnect-us.bcld.webex.com  
  privacy-policy passthru

    以下は、設定のフィールドの説明です。

    音声クラス テナント 100

    Webex Calling トランクにのみ使用される設定パラメータのセットを定義します。詳細については、音声クラス テナントを参照してください。

    登録者 dns:98027369.us10.bcld.webex.com スキーム sips 有効期限 240 更新比 50 tcp tls

    ローカル ゲートウェイの登録サーバーで、2 分ごとに更新が設定されている場合 (240 秒の 50%)。詳細については、登録者を参照してください。

    ここから Control Hub から [ドメインの登録] の値を使用していることを確認します。

    資格情報番号 Dallas1171197921_LGU ユーザー名 Dallas1463285401_LGU パスワード 0 9Wt[M6ifY+ realm BroadWorks

    トランク登録認証の資格情報。詳細については、「資格情報 (SIP UA)」を参照してください。

    ここから Control Hub から回線/ポートホスト、認証ユーザ名、認証パスワードの値を使用していることを確認します。

    認証ユーザー名 Dallas1171197921_LGU パスワード 0 9Wt[M6ifY+ realm BroadWorks
    認証ユーザー名 Dallas1171197921_LGU パスワード 0 9Wt[M6ifY+ realm 98027369.us10.bcld.webex.com

    コールの認証の課題。詳細については、認証 (ダイヤルピア) を参照してください。

    ここから Control Hub から、認証ユーザ名、認証パスワード、および登録ドメインの値をそれぞれ使用していることを確認します。

    no remote-party-id

    Webex Calling が PAI をサポートしているため、SIP Remote-Party-ID (RPID) ヘッダーを無効にします。これは asserted-id pai を使用して有効になります。詳細については、remote-party-id を参照してください。

    sip サーバ dns: us25.sipconnect.bcld.webex.com

    トランクのターゲット SIP サーバを設定します。トランクを作成したときに、Control Hub で提供されたエッジ プロキシ SRV アドレスを使用します。

    connection-reuse

    登録と通話処理に同じ永続的な接続を使用します。詳細については、connection-reuse を参照してください。

    srtp-crypto 100

    SRTP コール レッグ（接続）の優先暗号スイートを設定します（手順で指定）5). 詳細については、「voice class srtp-crypto」を参照してください。

    session transport tcp tls

    TLS へのトランスポートを設定します。詳細については、session-transport を参照してください。

    セッションの更新がありません

    CUBE と Webex 間の通話の SIP セッション更新を無効にします。詳細については、セッションの更新を参照してください。

    url sips

    SRVは、アクセス SBC によりサポートされている SIP である必要があります。その他のすべてのメッセージは、sip-profile 200 により SIP に変更されます。

    error-passthru

    SIP エラー応答パススルー機能を指定します。詳細については、error-passthru を参照してください。

    rel1xx を無効にする

    Webex Calling トランクに対する信頼できる仮応答の使用を無効にします。詳細については、rel1xx を参照してください。

    asserted-id pai

    (オプション) P-Asserted-Identity ヘッダー処理をオンにし、これが Webex Calling トランクに使用する方法を制御します。

    Webex Calling には、ローカル ゲートウェイへの発信コール INVITE の P-Asserted-Identity (PAI) ヘッダーが含まれています。

    このコマンドが設定されている場合、PAI ヘッダーからの発信者情報を使用して、発信元および PAI/Remote-Party-ID ヘッダーに入力します。

    このコマンドが設定されていない場合、From ヘッダーの発信者情報を使用して、発信 From ヘッダーと PAI/Remote-Party-ID ヘッダーに入力します。

    詳細については、asserted-id を参照してください。

    bind control source-interface GigabitEthernet0/0/1

    Webex Calling に送信されるメッセージのソース インターフェイスと関連する IP アドレスを設定します。詳細については、バインドを参照してください。

    bind media source-interface GigabitEthernet0/0/1

    WebexCalling に送信されるメディアのソース インターフェイスと関連する IP アドレスを設定します。詳細については、バインドを参照してください。

    no pass-thru content custom-sdp

    テナントの下のデフォルト コマンド。このコマンドの詳細については、pass-thru content を参照してください。

    sip プロファイル 100

    sip-profile 100 で定義されているように、SIP を SIP に変更し、INVITE および REGISTER メッセージの回線/ポートを変更します。詳細については、音声クラス sip-profiles を参照してください。

    outbound-proxy dns:dfw04.sipconnect-us.bcld.webex.com

    Webex Calling SBC にアクセスします。トランクを作成したときに、Control Hub で提供されるアウトバウンド プロキシ アドレスを挿入します。詳細については、outbound-proxy を参照してください。

    privacy-policy passthru

    トランクが受信メッセージから次のコール レッグにプライバシー値を渡すようにプライバシー ヘッダー ポリシー オプションを設定します。詳細については、プライバシー ポリシーを参照してください。

  2. Webex Calling トランクのダイヤルピアを設定します。 

    
dial-peer voice 100 voip
 description Inbound/Outbound Webex Calling
 max-conn 250
 destination-pattern BAD.BAD
 session protocol sipv2
 session target sip-server
 incoming uri request 100
 voice-class codec 100
 dtmf-relay rtp-nte
 voice-class stun-usage 100
 no voice-class sip localhost
 voice-class sip tenant 100
 srtp
 no vad

    以下は、設定のフィールドの説明です。

    
dial-peer voice 100 voip
  description Inbound/Outbound Webex Calling

    100 VoIP ダイヤルピアを定義し、管理とトラブルシューティングを容易にするための意味のある説明を行います。

    max-conn 250

    LGW と Webex Calling の間の同時着信および発信通話の数を制限します。登録トランクの場合、設定された最大値は 250 である必要があります。展開に適切であれば、ユーザの値を下げます。ローカル ゲートウェイの同時通話制限の詳細については、「ローカル ゲートウェイの使用を開始する 」ドキュメントを参照してください。

    宛先パターン BAD.BAD

    着信ダイヤルピア グループを使用して発信コールをルーティングする場合は、ダミー通知先パターンが必要です。この場合、有効な宛先パターンを使用できます。詳細については、「destination-pattern (interface)」を参照してください。

    session protocol sipv2

    ダイヤルピア 100 が SIP コール のコールコールを処理する場合に指定します。詳細については、セッション プロトコル (ダイヤルピア) を参照してください。

    session target sip-server

    テナント 100 で定義された SIP サーバが継承され、このダイヤル ピアからのコールの宛先に使用されることを示します。詳細については、セッション ターゲット (VoIP ダイヤル ピア) を参照してください。

    着信 uri リクエスト 100

    VoIP ダイヤル ピアと着信コールの Uniform Resource Identifier（URI）を照合するために使用される音声クラスを指定します。詳細については、着信 uri を参照してください。

    音声クラスのコーデック 100

    共通のコーデック フィルタ リスト 100 を使用するようにダイヤル ピアを設定します。詳細については、音声クラス コーデックを参照してください。

    音声クラス 使用量

    ローカル ゲートウェイでローカルで生成された STUN 要求が、ネゴシエートされたメディア パスを介して送信されるようにします。STUN は、メディア トラフィック用のファイアウォール ピンホールを開くのに役立ちます。詳細については、「voice-class stun-usage」を参照してください。

    no voice-class sip localhost

    送信メッセージの物理的 IP アドレスの代用として、From、Call-ID、Remote-Party-ID ヘッダーの DNS ローカル ホスト名の代入を無効にします。

    voice-class SIP テナント 100

    ダイヤル ピアは、グローバルおよびテナント 100 で設定されたすべてのパラメータを継承します。パラメータは、ダイヤルピア レベルでオーバーライドされる場合があります。

    srtp

    コールレグの SRTP を有効にする。

    no vad

    音声アクティブティの検出を無効にします。

テナント 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 トランクを使用したローカル ゲートウェイの設定

上記で Webex Calling に対してトランクを構築した場合、以下の構成を使用して、SIP ベースの PSTN プロバイダーに対して暗号化されていないトランクを作成します。

サービス プロバイダーがセキュアな PSTN トランクを提供している場合、Webex Calling トランクの上記と同様の設定に従う場合があります。CUBE はセキュアなコール ルーティングをサポートします。

TDM / ISDN PSTN トランクを使用している場合は、次のセクション [TDM PSTN トランクでローカル ゲートウェイを設定する] に進みます。

Cisco TDM-SIP ゲートウェイの PSTN コール レッグの TDM インターフェイスを設定するには、「ISDN PRI の構成」を参照してください。

1

PSTN トランクからの着信コールを識別するために、次の音声クラス uri を設定します。


voice class uri 200 sip
  host ipv4:192.168.80.13

以下は、設定のフィールドの説明です。

音声クラス uri 200 sip

着信 SIP 招待を着信トランクダイヤルピアに一致させるパターンを定義します。このパターンを入力する場合は、IP PSTN ゲートウェイの IP アドレスを使用します。詳細については、音声クラス uri を参照してください。

2

次の IP PSTN ダイヤル ピアを設定します。


dial-peer voice 200 voip
 description Inbound/Outbound IP PSTN trunk
 destination-pattern BAD.BAD
 session protocol sipv2
 session target ipv4:192.168.80.13
 incoming uri via 200
 voice-class sip asserted-id pai
 voice-class sip bind control source-interface GigabitEthernet0/0/0 
 voice-class sip bind media source-interface  GigabitEthernet0/0/0 
 voice-class codec 100
 dtmf-relay rtp-nte 
 no vad

以下は、設定のフィールドの説明です。


dial-peer voice 200 voip
 description Inbound/Outbound IP PSTN trunk

タグ 200 で VoIP ダイヤルピアを定義し、管理とトラブルシューティングを容易にする意味のある説明を提供します。詳細については、ダイヤルピアの音声を参照してください。

宛先パターン BAD.BAD

着信ダイヤルピア グループを使用して発信コールをルーティングする場合は、ダミー通知先パターンが必要です。この場合、有効な宛先パターンを使用できます。詳細については、「destination-pattern (interface)」を参照してください。

session protocol sipv2

このダイヤル ピアが SIP コール レッグを処理するように指定します。詳細については、セッション プロトコル (ダイヤル ピア) を参照してください。

セッション ターゲット ipv4: 192.168.80.13

PSTN プロバイダーに送信されるコールのターゲット アドレスを指定します。これは IP アドレスまたは DNS ホスト名です。詳細については、セッション ターゲット (VoIP ダイヤル ピア) を参照してください。

200 経由の着信 uri

INVITE 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/0

PSTN に送信されるメディアのソース インターフェイスと関連する IP アドレスを設定します。詳細については、バインドを参照してください。

音声クラスのコーデック 100

共通のコーデック フィルタ リスト 100 を使用するようにダイヤル ピアを設定します。詳細については、音声クラス コーデックを参照してください。

dtmf-relay rtp-nte

通話レグで予想される DTMF 機能として RTP-NTE (RFC2833) を定義します。詳細については、「DTMF リレー (音声オーバー IP)」を参照してください。

no vad

音声アクティブティの検出を無効にします。詳細については、vad (ダイヤル ピア) を参照してください。

3

ローカル ゲートウェイを Webex Calling と PSTN 間のコールのみをルーティングするように設定している場合は、次のコール ルーティング設定を追加します。Unified Communications Manager プラットフォームを使用してローカル ゲートウェイを設定する場合は、次のセクションに進みます。

  1. ダイヤルピア グループを作成して、Webex Calling または PSTN にコールをルーティングします。Webex Calling 向け発信ダイヤルピア 100 で DPG 100 を定義します。DPG 100 は、PSTN からの着信ダイヤルピアに適用されます。同様に、PSTN に向けて発信ダイヤルピア 200 を使用して DPG 200 を定義します。DPG 200 は、Webex からの着信ダイヤルピアに適用されます。

    
voice class dpg 100 
 description Route calls to Webex Calling 
 dial-peer 100 
voice class dpg 200 
 description Route calls to PSTN 
 dial-peer 200

    以下は、設定のフィールドの説明です。

    ダイヤルピア 100

    発信ダイヤルピアをダイヤルピア グループに関連付けます。詳細については、voice-class dpg を参照してください。

  2. ダイヤルピア グループを適用して、Webex から PSTN および PSTN から Webex に通話をルーティングします。 

    
dial-peer voice 100
 destination dpg 200
dial-peer voice 200
 destination dpg 100

    以下は、設定のフィールドの説明です。

    宛先 dpg 200

    どのダイヤルピア グループを指定し、この着信ダイヤルピアに提示されるコールのアウトバウンド処理に使用するかを指定します。

    これにより、ローカル ゲートウェイの設定が終了します。CUBE 機能が初めて設定される場合は、設定を保存し、プラットフォームを再読み込みします。

TDM PSTN トランクを使用したローカル ゲートウェイの設定

Webex Calling に向かってトランクを構築した後、次の設定を使用して、ループバック コール ルーティングを持つ PSTN サービスの TDM トランクを作成し、Webex コール レッグのメディア最適化を可能にします。

IP メディアの最適化を必要としない場合は、SIP PSTN トランクの設定手順に従います。PSTN VoIP ダイヤルピアの代わりに、音声ポートと POTS ダイヤルピア（ステップ 2 と 3 に示すように）を使用します。

1

ループバック ダイヤル ピア設定では、ダイヤル ピア グループとコール ルーティング タグを使用して、コール ルーティング ループを作成することなく、コールが Webex と PSTN の間で正しくパスされるようにします。コール ルーティング タグを追加および削除するために使用される次のトランスレーション ルールを設定します。


voice translation-rule 100 
 rule 1 /^\+/ /A2A/ 

voice translation-profile 100 
 translate called 100 

voice translation-rule 200 
 rule 1 /^/ /A1A/ 

voice translation-profile 200 
 translate called 200 

voice translation-rule 11 
 rule 1 /^A1A/ // 

voice translation-profile 11 
 translate called 11 

voice translation-rule 12 
 rule 1 /^A2A44/ /0/
 rule 2/^A2A/ /00/

voice translation-profile 12 
 translate called 12

以下は、設定のフィールドの説明です。

音声翻訳ルール

ルールで定義された正規表現を使用して、コール ルーティング タグを追加または削除します。十進法を超える数字（「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 インターフェイスの基本設定には、以下が含まれる場合があります。


card type e1 0 2 
isdn switch-type primary-net5 
controller E1 0/2/0 
 pri-group timeslots 1-31
3

次の TDM PSTN ダイヤル ピアを設定します。


dial-peer voice 200 pots 
 description Inbound/Outbound PRI PSTN trunk 
 destination-pattern BAD.BAD 
 translation-profile incoming 200 
 direct-inward-dial 
 port 0/2/0:15

以下は、設定のフィールドの説明です。 


dial-peer voice 200 pots
 description Inbound/Outbound PRI PSTN trunk

タグ 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 にルーティングされます。ルーティング タグを削除した後、コールはダイヤルピア グループを使用して発信トランクにルーティングされます。


dial-peer voice 10 voip
 description Outbound loop-around leg
 destination-pattern BAD.BAD
 session protocol sipv2
 session target ipv4:192.168.80.14
 voice-class sip bind control source-interface GigabitEthernet0/0/0
 voice-class sip bind media source-interface GigabitEthernet0/0/0
 dtmf-relay rtp-nte
 codec g711alaw
 no vad 

dial-peer voice 11 voip
 description Inbound loop-around leg towards Webex
 translation-profile incoming 11
 session protocol sipv2
 incoming called-number A1AT
 voice-class sip bind control source-interface GigabitEthernet0/0/0
 voice-class sip bind media source-interface GigabitEthernet0/0/0
 dtmf-relay rtp-nte
 codec g711alaw
 no vad 

dial-peer voice 12 voip
 description Inbound loop-around leg towards PSTN
 translation-profile incoming 12
 session protocol sipv2
 incoming called-number A2AT
 voice-class sip bind control source-interface GigabitEthernet0/0/0
 voice-class sip bind media source-interface GigabitEthernet0/0/0
 dtmf-relay rtp-nte
 codec g711alaw 
 no vad

以下は、設定のフィールドの説明です。 


dial-peer voice 10 voip
 description Outbound loop-around leg

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

次のコール ルーティング設定を追加します。

  1. ダイヤルピア グループを作成して、ループバック経由で PSTN と Webex トランク間のコールをルーティングします。

    
voice class dpg 100
 description Route calls to Webex Calling
 dial-peer 100
voice class dpg 200
 description Route calls to PSTN
 dial-peer 200
voice class dpg 10
 description Route calls to Loopback
 dial-peer 10

    以下は、設定のフィールドの説明です。

    ダイヤルピア 100

    発信ダイヤルピアをダイヤルピア グループに関連付けます。詳細については、voice-class dpg を参照してください。

  2. ダイヤル ピア グループを適用して通話をルーティングします。

    
dial-peer voice 100
 destination dpg 10
dial-peer voice 200
 destination dpg 10
dial-peer voice 11
 destination dpg 100
dial-peer voice 12
 destination dpg 200

    以下は、設定のフィールドの説明です。

    宛先 dpg 200

    どのダイヤルピア グループを指定し、この着信ダイヤルピアに提示されるコールのアウトバウンド処理に使用するかを指定します。

これにより、ローカル ゲートウェイの設定が終了します。CUBE 機能が初めて設定される場合は、設定を保存し、プラットフォームを再読み込みします。
ローカル ゲートウェイを既存の Unified CM 環境で構成する

前のセクションの 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 ヘッダーにこの値を入力できます。

SIP トランク セキュリティ プロファイル情報を入力
1

以下の音声クラス URI を設定:

  1. ポート経由の SIP を使用して、Unified CM から Webex 通話を分類します。

    
voice class uri 300 sip
 pattern :5065

  2. ポート経由の SIP を使用して、Unified CM から PSTN コールを分類します。

    
voice class uri 400 sip
 pattern 192\.168\.80\.6[0-5]:5060

    発信元のアドレスとポート番号を記述した 1 つ以上のパターンを使用して、UCM からの着信メッセージを PSTN トランクに分類します。必要に応じて、正規表現を使用して、一致するパターンを定義することができます。

    上記の例では、192.168.80.60 ～ 65 およびポート番号 5060 の任意の IP アドレスに正規表現が使用されます。

2

Unified CM ホストへの SRV ルーティングを指定するには、次の DNS レコードを設定します。

IOS XE は、ターゲット UCM ホストとポートをローカルで判別するためにこれらのレコードを使用します。この設定では、DNS システムでレコードを設定する必要はありません。DNS を使用する場合は、これらのローカル設定は必要ありません。


ip host ucmpub.mydomain.com 192.168.80.60
ip host ucmsub1.mydomain.com 192.168.80.61
ip host ucmsub2.mydomain.com 192.168.80.62
ip host ucmsub3.mydomain.com 192.168.80.63
ip host ucmsub4.mydomain.com 192.168.80.64
ip host ucmsub5.mydomain.com 192.168.80.65
ip host _sip._udp.wxtocucm.io srv 0 1 5065 ucmpub.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub1.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub2.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub3.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub4.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub5.mydomain.com
ip host _sip._udp.pstntocucm.io srv 0 1 5060 ucmpub.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub1.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub2.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub3.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub4.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub5.mydomain.com

以下は、設定のフィールドの説明です。

次のコマンドにより、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

次のダイヤル ピアを設定します。

  1. Unified CM と Webex Calling 間の通話のダイヤル ピア:

    
dial-peer voice 300 voip
 description UCM-Webex Calling trunk
 destination-pattern BAD.BAD
 session protocol sipv2
 session target dns:wxtocucm.io
 incoming uri via 300
 voice-class codec 100
 voice-class sip bind control source-interface GigabitEthernet 0/0/0
 voice-class sip bind media source-interface GigabitEthernet 0/0/0
 dtmf-relay rtp-nte
 no vad

    以下は、設定のフィールドの説明です。

    
dial-peer voice 300 voip
 description UCM-Webex Calling trunk

    タグ 300 で VoIP ダイヤルピアを定義し、管理とトラブルシューティングを容易にする意味のある説明を提供します。

    destination-pattern BAD.BAD

    着信ダイヤルピア グループを使用して発信コールをルーティングする場合は、ダミー通知先パターンが必要です。この場合、有効な宛先パターンを使用できます。

    session protocol sipv2

    ダイヤルピア 300 が SIP コール レッグを処理するように指定します。詳細については、セッション プロトコル (ダイヤルピア) を参照してください。

    セッション ターゲット dns:wxtocucm.io

    DNS SRV 解決により複数の Unified CM ノードのセッション ターゲットを定義します。この場合、ローカルで定義された SRV レコード wxtocucm.io がコールを転送するために使用されます。

    incoming uri via 300

    音声クラス URI 300 を使用して、ソース ポート 5065 を使用して、Unified CM からすべての着信トラフィックをこのダイヤルピアに誘導します。詳細については、着信 uri を参照してください。

    音声クラスのコーデック 100

    Unified CM 間のコールのコーデック フィルタ リストを示します。詳細については、音声クラス コーデックを参照してください。

    bind control source-interface GigabitEthernet0/0/0

    PSTN に送信されるメッセージのソース インターフェイスと関連する IP アドレスを設定します。詳細については、バインドを参照してください。

    bind media source-interface GigabitEthernet0/0/0

    PSTN に送信されるメディアのソース インターフェイスと関連する IP アドレスを設定します。詳細については、バインドを参照してください。

    dtmf-relay rtp-nte

    通話レグで予想される DTMF 機能として RTP-NTE (RFC2833) を定義します。詳細については、「DTMF リレー (音声オーバー IP)」を参照してください。

    no vad

    音声アクティブティの検出を無効にします。詳細については、vad (ダイヤル ピア) を参照してください。

  2. Unified CM と PSTN 間の通話のダイヤル ピア:

    
dial-peer voice 400 voip
 description UCM-PSTN trunk
 destination-pattern BAD.BAD
 session protocol sipv2
 session target dns:pstntocucm.io
 incoming uri via 400
 voice-class codec 100 
 voice-class sip bind control source-interface GigabitEthernet 0/0/0
 voice-class sip bind media source-interface GigabitEthernet 0/0/0
 dtmf-relay rtp-nte
 no vad

    以下は、設定のフィールドの説明です。

    
dial-peer voice 400 voip
 description UCM-PSTN trunk

    タグ 400 で VoIP ダイヤルピアを定義し、管理とトラブルシューティングを容易にする意味のある説明を提供します。

    destination-pattern BAD.BAD

    着信ダイヤルピア グループを使用して発信コールをルーティングする場合は、ダミー通知先パターンが必要です。この場合、有効な宛先パターンを使用できます。

    session protocol sipv2

    ダイヤルピア 400 が SIP コール レッグを処理するように指定します。詳細については、セッション プロトコル (ダイヤルピア) を参照してください。

    セッションターゲット dns:pstntocucm.io

    DNS SRV 解決により複数の Unified CM ノードのセッション ターゲットを定義します。この場合、ローカルで定義された SRV レコード pstntocucm.io がコールを転送するために使用されます。

    400 経由の着信 uri

    音声クラス URI 400 を使用して、ソース ポート 5060 を使用して指定された Unified CM ホストからのすべての着信トラフィックをこのダイヤルピアに誘導します。詳細については、着信 uri を参照してください。

    音声クラスのコーデック 100

    Unified CM 間のコールのコーデック フィルタ リストを示します。詳細については、音声クラス コーデックを参照してください。

    bind control source-interface GigabitEthernet0/0/0

    PSTN に送信されるメッセージのソース インターフェイスと関連する IP アドレスを設定します。詳細については、バインドを参照してください。

    bind media source-interface GigabitEthernet0/0/0

    PSTN に送信されるメディアのソース インターフェイスと関連する IP アドレスを設定します。詳細については、バインドを参照してください。

    dtmf-relay rtp-nte

    通話レグで予想される DTMF 機能として RTP-NTE (RFC2833) を定義します。詳細については、「DTMF リレー (音声オーバー IP)」を参照してください。

    no vad

    音声アクティブティの検出を無効にします。詳細については、vad (ダイヤル ピア) を参照してください。

4

次の設定を使用してコール ルーティングを追加します。

  1. ダイヤルピア グループを作成し、Unified CM と Webex Calling の間でコールをルーティングします。DPG 100 を 発信ダイヤルピア 100 で Webex Calling に対して定義します。DPG 100 は、Unified CM からの関連付けられた着信ダイヤルピアに適用されます。同様に、Unified CM に対して発信ダイヤルピア 300 を使用して DPG 300 を定義します。DPG 300 は、Webex からの着信ダイヤルピアに適用されます。

    
voice class dpg 100
 description Route calls to Webex Calling
 dial-peer 100
voice class dpg 300
 description Route calls to Unified CM Webex Calling trunk
 dial-peer 300

  2. Unified CM と PSTN の間でコールをルーティングするためのダイヤル ピア グループを作成します。PSTN に対して発信ダイヤルピア 200 で DPG 200 を定義します。DPG 200 は、Unified CM から関連する着信ダイヤルピアに適用されます。同様に、Unified CM に対して発信ダイヤルピア 400 を使用して DPG 400 を定義します。DPG 400 は、PSTN からの着信ダイヤルピアに適用されます。

    
voice class dpg 200
 description Route calls to PSTN
 dial-peer 200
voice class dpg 400
 description Route calls to Unified CM PSTN trunk
 dial-peer 400

    以下は、設定のフィールドの説明です。

    ダイヤルピア 100

    発信ダイヤルピアをダイヤルピア グループに関連付けます。詳細については、voice-class dpg を参照してください。

  3. ダイヤルピア グループを適用して、Webex から Unified CM および Unified CM から Webex に通話をルーティングします。 

    
dial-peer voice 100
 destination dpg 300
dial-peer voice 300
 destination dpg 100

    以下は、設定のフィールドの説明です。

    宛先 dpg 300

    どのダイヤルピア グループを指定し、この着信ダイヤルピアに提示されるコールのアウトバウンド処理に使用するかを指定します。

  4. ダイヤルピア グループを適用して、PSTN から Unified CM から Unified CM から PSTN に通話をルーティングします。

    
dial-peer voice 200
 destination dpg 400
dial-peer voice 400
 destination dpg 200

    これにより、ローカル ゲートウェイの設定が終了します。CUBE 機能が初めて設定されている場合、設定を保存し、プラットフォームを再読み込みします。

診断署名でローカル ゲートウェイを監視し、トラブルシューティングする

診断署名 (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 以降を実行しているローカル ゲートウェイ

  1. 診断署名はデフォルトで有効になっています。

  2. デバイスが Cisco IOS XE 17.6.1a 以降を実行している場合、プロアクティブ通知を送信するために使用されるセキュアなメール サーバを設定します。

    configure terminal 
call-home  
mail-server :@ priority 1 secure tls 
end

  3. 通知する管理者のメール アドレスでds_email 環境変数を設定します。 

    configure terminal 
call-home  
diagnostic-signature 
environment ds_email  
end

以下は、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 priority 1 secure tls 
diagnostic-signature 
environment ds_email "tacfaststart@gmail.com"

Cisco IOS XE ソフトウェアで起動するローカル ゲートウェイは OAuth に対応する一般的なウェブベースの Gmail クライアントではないので、特定の Gmail アカウント設定を行い、端末からメールを正しく処理するための権限を与える必要があります:

  1. [Google アカウントの管理] > [セキュリティ] に移動し、[安全性の低いアプリ アクセス] 設定をオンにします。

  2. 「はい、はい、それは私です」と答えます。Gmail から「Google は、Google 以外のアプリを使用してアカウントにサインインするユーザーを防ぎました」というメールを受け取ります。

プロアクティブ モニタリングのために診断署名をインストールする

CPU 使用率の監視

この DS は、SNMP OID を使用して 5 秒間 CPU 使用率を追跡します。1.3.6.1.4.1.9.2.1.56. 使用率が 75% 以上に達すると、すべてのデバッグを無効にし、ローカル ゲートウェイにインストールされている診断署名をアンインストールします。下記の手順を実行して署名をインストールします。

  1. show snmp コマンドを使用して、SNMP を有効にします。有効にしない場合は、snmp-server manager コマンドを設定します。

    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

  2. Diagnostic Signatures Lookup Tool の以下のドロップダウンオプションを使用して、DS 64224 をダウンロードします。

    フィールド名

    フィールド値

    プラットフォーム

    Cisco 4300、4400 ISR シリーズまたは Cisco CSR 1000V シリーズ

    製品

    Webex Calling ソリューションの CUBE Enterprise

    問題の範囲

    パフォーマンス

    問題の種類

    通知メールによる CPU 使用率が高い

  3. DS XML ファイルをローカルゲートウェイフラッシュにコピーします。

    LocalGateway# copy ftp://username:password@/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)

  4. ローカルゲートウェイに DS XML ファイルをインストールします。

    call-home diagnostic-signature load DS_64224.xml 
Load file DS_64224.xml success

  5. 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 がアンインストールされます。必要に応じて、DS 64224 を再インストールして、ローカル ゲートウェイの高い CPU 使用率のモニタリングを続行します。

SIP トランク登録のモニタリング

この DS は、60 秒ごとにクラウドにSIP トランクするローカル Webex Calling登録解除をチェックします。登録解除イベントが検出されると、メールと syslog の通知が生成され、2 回の登録解除後に自動的にアンインストールされます。署名をインストールするには、以下の手順を使用します。

  1. Diagnostic Signatures Lookup Tool の以下のドロップダウンオプションを使用して、DS 64117 をダウンロードします。

    フィールド名

    フィールド値

    プラットフォーム

    Cisco 4300、4400 ISR シリーズ、または Cisco CSR 1000V シリーズ

    製品

    Webex Calling ソリューションの CUBE Enterprise

    問題の範囲

    SIP-SIP

    問題の種類

    SIP トランクによる登録解除を行いました。

  2. DS XML ファイルをローカルゲートウェイにコピーします。

    copy ftp://username:password@/DS_64117.xml bootflash:

  3. ローカルゲートウェイに DS XML ファイルをインストールします。 

    call-home diagnostic-signature load DS_64117.xml 
Load file DS_64117.xml success 
LocalGateway#

  4. show call-home diagnostic-signature コマンドを使用 して、署名が正常にインストールされたことを確認します。状態の列には「登録済み」の値が必要です。

異常な通話切断の監視

この DS は、10 分ごとに SNMP ポーリングを使用して、SIP エラーの 403、488、503 で異常な通話切断を検出します。 エラーカウントの増分が最後の投票から 5 以上である場合、syslog とメール通知が生成されます。 署名をインストールするには、以下の手順を使用してください。

  1. show snmp コマンドを使用して、SNMP が有効かどうかを確認します。有効になっていない場合は、snmp-server manager コマンドを設定します。 

    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

  2. Diagnostic Signatures Lookup Tool の以下のオプションを使用して、DS 65221 をダウンロードします。

    フィールド名

    フィールド値

    プラットフォーム

    Cisco 4300、4400 ISR シリーズ、または Cisco CSR 1000V シリーズ

    製品

    Webex Calling ソリューションの CUBE Enterprise

    問題の範囲

    パフォーマンス

    問題の種類

    メールおよび Syslog 通知による SIP の異常通話切断検出

  3. DS XML ファイルをローカルゲートウェイにコピーします。 

    copy ftp://username:password@/DS_65221.xml bootflash:

  4. ローカルゲートウェイに DS XML ファイルをインストールします。 

    call-home diagnostic-signature load DS_65221.xml 
Load file DS_65221.xml success

  5. 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 を使用して、以下の手順を使用して、診断データの収集を自動化します。

  1. 収集された診断データがアップロードされる 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://:@cxd.cisco.com"  
end

    例： 

    call-home  
diagnostic-signature 
environment ds_fsurl_prefix " environment ds_fsurl_prefix "scp://612345678:abcdefghijklmnop@cxd.cisco.com"

  2. show snmp コマンドを使用して、SNMP が有効になっていることを確認します。有効になっていない場合は、snmp-server manager コマンドを設定します。

    show snmp 
%SNMP agent not enabled 
 
 
config t 
snmp-server manager 
end

  3. 高 CPU 使用率の期間中に、すべてのデバッグと診断署名を無効にするためのプロアクティブな措置として、高 CPU モニタリング DS 64224 をインストールしてください。Diagnostic Signatures Lookup Tool の以下のオプションを使用して、DS 64224 をダウンロードします。

    フィールド名

    フィールド値

    プラットフォーム

    Cisco 4300、4400 ISR シリーズ、または Cisco CSR 1000V シリーズ

    製品

    Webex Calling ソリューションの CUBE Enterprise

    問題の範囲

    パフォーマンス

    問題の種類

    通知メールによる CPU 使用率が高い

  4. 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

  5. DS XML ファイルをローカルゲートウェイにコピーします。

    copy ftp://username:password@/DS_64224.xml bootflash: 
copy ftp://username:password@/DS_65095.xml bootflash:

  6. ローカルゲートウェイに、高 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

  7. 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 
           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  
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 名

トリガー済み/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 deinstall

例:

call-home diagnostic-signature deinstall 64224

診断署名検索ツールに定期的に新しい署名が追加されます。これは展開で一般的に見られる問題に基づいて行います。TAC では現在、新しいカスタム署名の作成リクエストをサポートしていません。

Control Hub を介した Cisco IOS XE ゲートウェイの管理と検証

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 メッセージの処理を提供し、それらを必要なターゲットにルーティングします。

PSTN から Webex Calling 構成ソリューションへのコール ルーティング

オンプレミスの Cisco Unified Communications Manager ソリューションを Webex Calling に接続する場合、以下の図に示すソリューションを構築するためのベースラインとして、シンプルな PSTN ゲートウェイ構成を使用できます。この場合、Unified Communications Manager は、すべての PSTN および Webex Calling コールのルーティングと処理を一元化します。

Unified Communications Manager がすべての PSTN および Webex Calling コールのルーティングと処理を一元化したソリューションダイアグラム

このドキュメントでは、次の画像に示すホスト名、IP アドレス、およびインターフェイスが使用されます。オプションは、パブリックアドレスまたはプライベート（NAT の背後）アドレス指定用に提供されます。複数の CUBE インスタンス間でロード バランシングしない限り、SRV DNS レコードはオプションです。

証明書ベースのローカル ゲートウェイの設定で使用されるホスト名、IP アドレス、およびインターフェイス

このドキュメントの残りの構成ガイダンスを使用して、次のようにローカル ゲートウェイの設定を完了します。

接続とセキュリティを設定

ベースライン設定

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 インターフェイスに割り当てることを確認します。


interface GigabitEthernet0/0/0
 description Interface facing PSTN and/or CUCM
 ip address 192.168.80.14 255.255.255.0
!
interface GigabitEthernet0/0/1
 description Interface facing Webex Calling (Public address)
 ip address 198.51.100.1 255.255.255.240

2

対称暗号化を使用して、ルータの STUN クレデンシャルを保護します。プライマリ暗号化キーと暗号化タイプを次のように設定します。


key config-key password-encrypt YourPassword
password encryption aes
3

サポートされている 証明機関 (CA) によって署名されたドメインの証明書を使用して暗号化トラストポイントを作成します。

  1. 次の exec コマンドを使用して RSA 鍵ペアを作成します。

    crypto key generate rsa general-keys exportable label lgw-key modulus 4096

  2. 次の設定コマンドを使用して、証明書のトラストポイントを作成し、証明書署名要求で使用するフィールド値を指定します。 

    
crypto pki trustpoint LGW_CERT
 enrollment terminal pem
 fqdn none
 subject-name cn=cube1.lgw.com
 subject-alt-name cube1.lgw.com
 revocation-check none
 rsakeypair lgw-key
 hash sha256

    証明書フィールドのノート:

    • fqdn: これは Webex Calling の必須フィールドではありません。この設定を [なし(None)] に設定すると、このフィールドを証明書署名要求に含めません。このコマンドを使用して FQDN を含める必要がある場合、ローカル ゲートウェイの操作には影響はありません。

    • 件名: ローカル ゲートウェイからのコールを検証するには、Webex は SIP 連絡先ヘッダーの FQDN と SBC 証明書のサブジェクト共通名 (CN) 属性または SAN フィールドに含まれるサブジェクト代替名 (SAN) フィールドのいずれかに一致する必要があります。件名 フィールドには少なくとも 1 つの CN 属性を含める必要があり、必要に応じて他の属性を含めることができます。詳細については、件名を参照してください。

    • 件名-alt-name: SBC 証明書のサブジェクト代替名（SAN）フィールドには、追加の FQDN のリストを含めることができます。証明書の件名 CN 属性が一致しない場合、WEBEX はこのリストをチェックして、ローカル ゲートウェイからのメッセージの SIP 連絡先ヘッダーを検証します。

    • ハッシュ: 証明書署名リクエスト (CSR) は SHA256 を使用して署名することをお勧めします。Cisco IOS XE 17.11.1 は、デフォルトでこのアルゴリズムを使用し、以前のリリースでは Hash コマンドを使用します。

  3. 次の exec または設定コマンドで証明書署名リクエスト（CSR）を生成し、サポートされている CA プロバイダーから署名付き証明書を要求するために使用します。

    crypto pki enroll LGW_CERT

4

ホスト証明書を認証するための中間署名 CA の証明書を提供します。次の exec または configuration コマンドを入力します。


crypto pki authenticate LGW_CERT

5

次の exec または設定コマンドを使用して、署名付きホスト証明書をインポートします。


crypto pki import LGW_CERT certificate

6

TLS1.2 の排他性を有効にし、次の設定コマンドを使用して、音声アプリケーションに使用するデフォルトのトラストポイントを指定します。


 sip-ua
  crypto signaling default trustpoint LGW_CERT
  transport tcp tls v1.2

7

Webex Calling で使用される IdenTrust 商用ルート CA 1 証明書を含む Cisco ルート CA バンドルをインストールします。crypto pki trustpool import clean url url コマンドを使用して、指定された URL からルート CA バンドルをダウンロードし、現在の CA トラストプールをクリアし、証明書の新しいバンドルをインストールします。

HTTPS を使用してインターネットにアクセスするためにプロキシを使用する必要がある場合は、CA バンドルをインポートする前に次の設定を追加してください。

ip http クライアント プロキシ サーバ yourproxy.com プロキシ ポート 80

ip http client source-interface GigabitEthernet0/0/1 
crypto pki trustpool import clean url https://www.cisco.com/security/pki/trs/ios_core.p7b
Webex Calling 証明書ベースのトランクを設定
1

Control Hub の既存のロケーションに対して CUBE 証明書ベースの PSTN トランクを作成します。詳細については、「Webex Calling のトランク、ルート グループ、ダイヤル プランを構成する」を参照してください。

トランクが作成されると、提供されたトランク情報をメモします。以下の図でハイライトされているこれらの詳細は、このガイドの設定手順で使用されます。

CUBE 証明書ベースの PSTN トランクが作成されます
2

次のコマンドを入力して、CUBE を Webex Calling ローカル ゲートウェイとして設定します。


voice service voip
 ip address trusted list
  ipv4 x.x.x.x y.y.y.y
 mode border-element
 allow-connections sip to sip
 no supplementary-service sip refer
 stun
  stun flowdata agent-id 1 boot-count 4
  stun flowdata shared-secret 0 Password123$
 sip 
  asymmetric payload full
  early-offer forced
  sip-profiles inbound

以下は、設定のフィールドの説明です。


ip address trusted list
 ipv4 x.x.x.x y.y.y.y

  • 有料詐欺から保護するために、信頼できるアドレス リストは、ローカル ゲートウェイが合法的な VoIP コールを期待するホストとネットワークエンティティのリストを定義します。

  • デフォルトでは、ローカル ゲートウェイは、信頼リストに含まれていない IP アドレスからのすべての着信 VoIP メッセージをブロックします。デフォルトでは、「セッション ターゲット IP」またはサーバ グループ IP アドレスを持つ静的に設定されたダイヤル ピアが信頼されます。これらの IP アドレスを信頼リストに追加する必要はありません。

  • ローカル ゲートウェイを設定するときに、地域の Webex Calling データ センターの IP サブネットをリストに追加します。詳細については、「Webex Calling のポート参照情報 」を参照してください。また、Unified Communications Manager サーバ（使用されている場合）と PSTN トランク ゲートウェイのアドレス範囲を追加します。

  • 料金詐欺を防ぐために IP アドレス信頼リストを使用する方法の詳細については、「信頼された IP アドレス」を参照してください。

モードの境界要素

プラットフォームで Cisco Unified Border Element（CUBE）機能を有効にします。

allow-connections sip to sip

CUBE の基本 SIP バックツーバックのユーザー エージェント機能を有効にします。詳細については、「接続を許可する」を参照してください。

デフォルトでは、T.38 ファックス トランスポートが有効になっています。詳細については、ファックス プロトコル t38 (音声サービス) を参照してください。

ストーン

STUN (NAT 経由の UDP のセッション トラバーサル) をグローバルに有効にします。

これらのグローバル stun コマンドは、ローカル ゲートウェイを NAT の背後に展開する場合にのみ必要です。

  • ローカル ゲートウェイの STUN バインディング機能を使用すると、ネゴシエートされたメディア パスを介して、ローカルで生成された STUN 要求を送信できます。これにより、ファイアウォールのピンホールを開くことができます。

詳細については、stun flowdata agent-id および stun flowdata shared-secret を参照してください。

非対称ペイロード (フル)

DTMF と動的コーデック ペイロードの両方に対して SIP 非対称ペイロード サポートを設定します。このコマンドの詳細については、非対称ペイロードを参照してください。

early-offer forced

ローカル ゲートウェイが、隣接ピアからの確認応答を待つ代わりに、最初の INVITE メッセージで SDP 情報を送信するように強制します。このコマンドの詳細については、早期オファーを参照してください。

SIP プロファイル インバウンド

CUBE が SIP プロファイルを使用してメッセージを受信したときに変更できるようにします。プロファイルはダイヤルピアまたはテナント経由で適用されます。

3

すべてのトランクに対して G.711 コーデックのみを許可する音声クラス コーデック 100 を設定します。このシンプルなアプローチは、ほとんどの導入に適しています。必要に応じて、発信元システムと終端システムの両方でサポートされている追加のコーデック タイプをリストに追加できます。

DSP モジュールを使用したトランスコーディング を含むより複雑なソリューションはサポートされていますが、このガイドには含まれていません。 


voice class codec 100
 codec preference 1 g711ulaw
 codec preference 2 g711alaw

以下は、設定のフィールドの説明です。

音声クラス コーデック 100

SIP トランク コールの優先コーデックのみを許可するために使用されます。詳細については、音声クラス コーデックを参照してください。

4

音声クラス stun-usage 100 を設定して、Webex Calling トランクで ICE を有効にします。(このステップは、政府版 Webex には適用されません)


voice class stun-usage 100 
 stun usage firewall-traversal flowdata
 stun usage ice lite

以下は、設定のフィールドの説明です。

STUNの使用法ice lite

可能なときは常に、メディア最適化を可能にする、すべての Webex Calling でダイヤルピアで ICE-Lite を有効にします。詳細については、音声クラス stun 使用状況 および使用状況のice liteを参照してください。

stun usage firewall-traversal flowdata コマンドは、NAT の背後にローカル ゲートウェイを展開する場合にのみ必要です。

メディアの最適化は、可能な限り、ネゴシエートされます。通話に録画などのクラウド メディア サービスが必要な場合、メディアを最適化できません。

5

Webex トラフィックのメディア暗号化ポリシーを設定します。(このステップは、政府版 Webex には適用されません)


voice class srtp-crypto 100
 crypto 1 AES_CM_128_HMAC_SHA1_80

以下は、設定のフィールドの説明です。

音声クラス srtp-crypto 100

オファーと応答メッセージの SDP で唯一の SRTP 暗号スイート CUBE が提供されるため、SHA1_80 を指定します。Webex Calling は SHA1_80 のみをサポートします。詳細については、「voice class srtp-crypto」を参照してください。

6

FIPS 対応 GCM 暗号を構成します(このステップは政府版 Webex にのみ適用されます)。 


voice class srtp-crypto 100
crypto 1 AEAD_AES_256_GCM

以下は、設定のフィールドの説明です。

音声クラス srtp-crypto 100

CUBE が提供する暗号スイートとして GCM を指定します。政府版 Webex のローカル ゲートウェイの GCM 暗号を設定する必要があります。

7

宛先 FQDN または SRV に基づいて、ローカル ゲートウェイ トランクへのコールを一意に識別するパターンを設定します。


voice class uri 100 sip
 pattern cube1.lgw.com

以下は、設定のフィールドの説明です。

音声クラス uri 100 sip

着信 SIP 招待を着信トランクダイヤルピアに一致させるパターンを定義します。このパターンを入力する場合は、トランク用に Control Hub で設定されたトランク FQDN または SRV を使用します。

8

SIP メッセージ操作プロファイルを設定します。ゲートウェイにパブリック IP アドレスが設定されている場合は、次のようにプロファイルを設定するか、NAT を使用している場合は、次のステップにスキップします。この例では、cube1.lgw.com はローカル ゲートウェイに設定されている FQDN です。


voice class sip-profiles 100
 rule 10 request ANY sip-header Contact modify "@.*:" "@cube1.lgw.com:" 
 rule 20 response ANY sip-header Contact modify "@.*:" "@cube1.lgw.com:"

以下は、設定のフィールドの説明です。

ルール 10 と 20

Webex がローカル ゲートウェイからのメッセージを認証できるようにするには、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 プロファイル 

voice class sip-profiles 100
 rule 10 request ANY sip-header Contact modify "@.*:" "@cube1.lgw.com:"
 rule 20 response ANY sip-header Contact modify "@.*:" "@cube1.lgw.com:"
 rule 30 response ANY sdp-header Audio-Attribute modify "(a=candidate:1 1.*) 10.80.13.12" "\1 192.65.79.20"
 rule 31 response ANY sdp-header Audio-Attribute modify "(a=candidate:1 2.*) 10.80.13.12" "\1 192.65.79.20"
 rule 40 response ANY sdp-header Audio-Connection-Info modify "IN IP4 10.80.13.12" "IN IP4 192.65.79.20"
 rule 41 request ANY sdp-header Audio-Connection-Info modify "IN IP4 10.80.13.12" "IN IP4 192.65.79.20"
 rule 50 request ANY sdp-header Connection-Info modify "IN IP4 10.80.13.12" "IN IP4 192.65.79.20"
 rule 51 response ANY sdp-header Connection-Info modify "IN IP4 10.80.13.12" "IN IP4 192.65.79.20"
 rule 60 response ANY sdp-header Session-Owner modify "IN IP4 10.80.13.12" "IN IP4 192.65.79.20"
 rule 61 request ANY sdp-header Session-Owner modify "IN IP4 10.80.13.12" "IN IP4 192.65.79.20"
 rule 70 request ANY sdp-header Audio-Attribute modify "(a=rtcp:.*) 10.80.13.12" "\1 192.65.79.20"
 rule 71 response ANY sdp-header Audio-Attribute modify "(a=rtcp:.*) 10.80.13.12" "\1 192.65.79.20"
 rule 80 request ANY sdp-header Audio-Attribute modify "(a=candidate:1 1.*) 10.80.13.12" "\1 192.65.79.20"
 rule 81 request ANY sdp-header Audio-Attribute modify "(a=candidate:1 2.*) 10.80.13.12" "\1 192.65.79.20"

以下は、設定のフィールドの説明です。

ルール 10 と 20

Webex がローカル ゲートウェイからのメッセージを認証できるようにするには、SIP リクエストと応答メッセージの「Contact」ヘッダーに Control Hub のトランクにプロビジョニングされた値が含まれている必要があります。これは、単一のホストの FQDN か、デバイスのクラスタに使用される SRV 名になります。

ルール 30 ～ 81

プライベート アドレスの参照をサイトの外部パブリック アドレスに変換し、Webex が後続のメッセージを正しく解釈してルーティングできるようにします。

Webex Calling からの受信メッセージの SIP プロファイル 

voice class sip-profiles 110
 rule 10 response ANY sdp-header Video-Connection-Info modify "192.65.79.20" "10.80.13.12"
 rule 20 response ANY sip-header Contact modify "@.*:" "@cube1.lgw.com:"
 rule 30 response ANY sdp-header Connection-Info modify "192.65.79.20" "10.80.13.12"
 rule 40 response ANY sdp-header Audio-Connection-Info modify "192.65.79.20" "10.80.13.12"
 rule 50 response ANY sdp-header Session-Owner modify "192.65.79.20" "10.80.13.12"
 rule 60 response ANY sdp-header Audio-Attribute modify "(a=candidate:1 1.*) 192.65.79.20" "\1 10.80.13.12"
 rule 70 response ANY sdp-header Audio-Attribute modify "(a=candidate:1 2.*) 192.65.79.20" "\1 10.80.13.12"
 rule 80 response ANY sdp-header Audio-Attribute modify "(a=rtcp:.*) 192.65.79.20" "\1 10.80.13.12"

以下は、設定のフィールドの説明です。

ルール 10 ～ 80

パブリック アドレス参照を設定したプライベート アドレスに変換し、CUBE が Webex からのメッセージを処理できるようにします。

詳細については、音声クラス sip-profiles を参照してください。

米国またはカナダの PSTN プロバイダーは、Webex Calling のスパムまたは詐欺通話の表示 の記事で言及されている追加設定を使用して、スパムおよび詐欺通話の発信者 ID 検証を提供できます。

10

ヘッダー変更プロファイルを使用して、SIP オプション キープアライブを設定します。


voice class sip-profiles 115
 rule 10 request OPTIONS sip-header Contact modify "

以下は、設定のフィールドの説明です。

音声クラス 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 トランクの設定:

  1. 音声クラス テナント 100 を作成して、Webex Calling トランクに特別に必要な設定を定義し、グループ化します。このテナントに関連付けられているダイヤルピアは、後でこれらの設定を継承します。

    次の例では、ステップ 1 で説明されている値を、このガイドの目的で使用しています（太字で示されています）。設定内のトランクの値に置き換えます。

    
voice class tenant 100
 no remote-party-id
 sip-server dns:us25.sipconnect.bcld.webex.com
 srtp-crypto 100
 localhost dns:cube1.lgw.com
 session transport tcp tls
 no session refresh
 error-passthru
 rel1xx disable
 asserted-id pai
 bind control source-interface GigabitEthernet0/0/1
 bind media source-interface GigabitEthernet0/0/1
 no pass-thru content custom-sdp
 sip-profiles 100 
 sip-profiles 110 inbound
 privacy-policy passthru
!

    以下は、設定のフィールドの説明です。

    音声クラス テナント 100

    独自の TLS 証明書と CN または SAN 検証リストを持つトランクを設定するには、テナントを使用することをお勧めします。ここでは、テナントに関連付けられた tls プロファイルには、新しい接続を受け入れまたは作成するために使用される信頼ポイントが含まれており、着信接続を検証するための CN または SAN リストがあります。詳細については、音声クラス テナントを参照してください。

    no remote-party-id

    Webex Calling が PAI をサポートしているため、SIP Remote-Party-ID (RPID) ヘッダーを無効にします。これは asserted-id pai コマンドを使用して有効になります。詳細については、remote-party-id を参照してください。

    sip サーバ dns: us25.sipconnect.bcld.webex.com

    トランクのターゲット SIP サーバを設定します。トランクを作成したときに、Control Hub で提供されたエッジ プロキシ SRV アドレスを使用します

    srtp-crypto 100

    SRTP コール レッグ（接続）の優先暗号スイートを設定します（ステップで指定）5). 詳細については、「voice class srtp-crypto」を参照してください。

    ローカルホスト DNS: cube1.lgw.com

    発信メッセージの From、Call-ID、および Remote-Party-ID ヘッダー内の物理 IP アドレスを提供された FQDN で置き換えるように CUBE を設定します。ここでトランクのために Control Hub で設定されたトランク FQDN または SRV を使用します。

    session transport tcp tls

    関連するダイヤルピアの TLS へのトランスポートを設定します。詳細については、session-transport を参照してください。

    セッションの更新がありません

    CUBE と Webex 間の通話の SIP セッション更新を無効にします。詳細については、セッションの更新を参照してください。

    error-passthru

    SIP エラー応答パススルー機能を指定します。詳細については、error-passthru を参照してください。

    rel1xx を無効にする

    Webex Calling トランクに対する信頼できる仮応答の使用を無効にします。詳細については、rel1xx を参照してください。

    asserted-id pai

    (オプション) P-Asserted-Identity ヘッダー処理をオンにし、これが Webex Calling トランクに使用する方法を制御します。

    Webex Calling には、ローカル ゲートウェイへの発信コール INVITE の P-Asserted-Identity (PAI) ヘッダーが含まれています。

    このコマンドが設定されている場合、PAI ヘッダーからの発信者情報を使用して、発信元および PAI/Remote-Party-ID ヘッダーに入力します。

    このコマンドが設定されていない場合、From ヘッダーの発信者情報を使用して、発信 From ヘッダーと PAI/Remote-Party-ID ヘッダーに入力します。

    詳細については、asserted-id を参照してください。

    bind control source-interface GigabitEthernet0/0/1

    Webex Calling に送信されるメッセージのソース インターフェイスと関連する IP アドレスを設定します。詳細については、バインドを参照してください。

    bind media source-interface GigabitEthernet0/0/1

    Webex Calling に送信されるメディアのソース インターフェイスと関連する IP アドレスを設定します。詳細については、バインドを参照してください。

    voice-class SIP プロファイル 100

    アウトバウンド メッセージに使用するヘッダー変更プロファイル（パブリック IP または NAT アドレッシング）を適用します。詳細については、「voice-class sip profiles」を参照してください。

    音声クラス SIP プロファイル 110 インバウンド

    NAT のみの背後にある LGW 展開の場合: 着信メッセージに使用するヘッダー変更プロファイルを適用します。詳細については、音声クラス sip プロファイルを参照してください。

    privacy-policy passthru

    受信メッセージから次のコール レッグにプライバシー ヘッダーを透過的に渡すように CUBE を設定します。詳細については、プライバシー ポリシーを参照してください。

  2. Webex Calling トランクのダイヤルピアを設定します。

    
dial-peer voice 100 voip
 description Inbound/Outbound Webex Calling
 destination-pattern BAD.BAD
 session protocol sipv2
 session target sip-server
 incoming uri request 100
 voice-class codec 100
 voice-class stun-usage 100
 voice-class sip tenant 100
 voice-class sip options-keepalive profile 100
 dtmf-relay rtp-nte 
 srtp
 no vad

    以下は、設定のフィールドの説明です。

    
dial-peer voice 100 voip
 description Inbound/Outbound Webex Calling

    タグ 100 で VoIP ダイヤルピアを定義し、管理とトラブルシューティングを容易にする意味のある説明を提供します。詳細については、ダイヤルピアの音声を参照してください。

    宛先パターン BAD.BAD

    着信ダイヤルピア グループを使用して発信コールをルーティングする場合は、ダミー通知先パターンが必要です。この場合、有効な宛先パターンを使用できます。詳細については、「destination-pattern (interface)」を参照してください。

    session protocol sipv2

    このダイヤル ピアが SIP コール レッグを処理するように指定します。詳細については、セッション プロトコル (ダイヤルピア) を参照してください。

    session target sip-server

    テナント 100 で定義された SIP サーバが継承され、このダイヤル ピアからのコールの宛先に使用されることを示します。

    着信 uri リクエスト 100

    INVITE 要求ヘッダー URI を使用して、着信コールをこのダイヤルピアに照合するために使用される音声クラスを指定します。詳細については、着信 uri を参照してください。

    音声クラスのコーデック 100

    Webex Calling 間の通話のコーデック フィルター リストを示します。詳細については、音声クラス コーデックを参照してください。

    音声クラス 使用量

    ローカル ゲートウェイからローカルで生成された STUN 要求を、ネゴシエートされたメディア パスを介して送信できるようにします。STUN パケットは、メディア トラフィックのためのファイアウォール ピンホールを開き、メディア最適化のための有効なパスを検出するのに役立ちます。

    音声クラス SIP テナント 100

    ダイヤル ピアは、グローバルおよびテナント 100 で設定されたすべてのパラメータを継承します。パラメータは、ダイヤルピア レベルでオーバーライドされる場合があります。詳細については、「voice-class sip tenant」を参照してください。

    voice-class sip options-keepalive profile 100

    このコマンドは、特定のプロファイル（100）を使用して、SIP サーバまたはエンドポイントのグループの可用性を監視するために使用されます。

    srtp

    コールレグの SRTP を有効にする。

SIP PSTN トランクを使用したローカル ゲートウェイの設定

上記で Webex Calling に対してトランクを構築した場合、以下の構成を使用して、SIP ベースの PSTN プロバイダーに対して暗号化されていないトランクを作成します。

サービス プロバイダーがセキュアな PSTN トランクを提供している場合、Webex Calling トランクの上記と同様の設定に従う場合があります。CUBE はセキュアなコール ルーティングをサポートします。

TDM / ISDN PSTN トランクを使用している場合は、次のセクション [TDM PSTN トランクでローカル ゲートウェイを設定する] に進みます。

Cisco TDM-SIP ゲートウェイの PSTN コール レッグの TDM インターフェイスを設定するには、「ISDN PRI の構成」を参照してください。

1

PSTN トランクからの着信コールを識別するために、次の音声クラス uri を設定します。


voice class uri 200 sip
  host ipv4:192.168.80.13

以下は、設定のフィールドの説明です。

音声クラス uri 200 sip

着信 SIP 招待を着信トランクダイヤルピアに一致させるパターンを定義します。このパターンを入力する場合は、IP PSTN ゲートウェイの IP アドレスを使用します。詳細については、音声クラス uri を参照してください。

2

次の IP PSTN ダイヤル ピアを設定します。


dial-peer voice 200 voip
 description Inbound/Outbound IP PSTN trunk
 destination-pattern BAD.BAD
 session protocol sipv2
 session target ipv4:192.168.80.13
 incoming uri via 200
 voice-class sip asserted-id pai
 voice-class sip bind control source-interface GigabitEthernet0/0/0 
 voice-class sip bind media source-interface  GigabitEthernet0/0/0 
 voice-class codec 100
 dtmf-relay rtp-nte 
 no vad

以下は、設定のフィールドの説明です。


dial-peer voice 200 voip
 description Inbound/Outbound IP PSTN trunk

タグ 200 で VoIP ダイヤルピアを定義し、管理とトラブルシューティングを容易にする意味のある説明を提供します。詳細については、ダイヤルピアの音声を参照してください。

宛先パターン BAD.BAD

着信ダイヤルピア グループを使用して発信コールをルーティングする場合は、ダミー通知先パターンが必要です。この場合、有効な宛先パターンを使用できます。詳細については、「destination-pattern (interface)」を参照してください。

session protocol sipv2

このダイヤル ピアが SIP コール レッグを処理するように指定します。詳細については、セッション プロトコル (ダイヤル ピア) を参照してください。

セッション ターゲット ipv4: 192.168.80.13

PSTN プロバイダーに送信されるコールのターゲット アドレスを指定します。これは IP アドレスまたは DNS ホスト名です。詳細については、セッション ターゲット (VoIP ダイヤル ピア) を参照してください。

200 経由の着信 uri

INVITE 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/0

PSTN に送信されるメディアのソース インターフェイスと関連する IP アドレスを設定します。詳細については、バインドを参照してください。

音声クラスのコーデック 100

共通のコーデック フィルタ リスト 100 を使用するようにダイヤル ピアを設定します。詳細については、音声クラス コーデックを参照してください。

dtmf-relay rtp-nte

通話レグで予想される DTMF 機能として RTP-NTE (RFC2833) を定義します。詳細については、「DTMF リレー (音声オーバー IP)」を参照してください。

no vad

音声アクティブティの検出を無効にします。詳細については、vad (ダイヤル ピア) を参照してください。

3

ローカル ゲートウェイを Webex Calling と PSTN 間のコールのみをルーティングするように設定している場合は、次のコール ルーティング設定を追加します。Unified Communications Manager プラットフォームを使用してローカル ゲートウェイを設定する場合は、次のセクションに進みます。

  1. ダイヤルピア グループを作成して、Webex Calling または PSTN にコールをルーティングします。Webex Calling 向け発信ダイヤルピア 100 で DPG 100 を定義します。DPG 100 は、PSTN からの着信ダイヤルピアに適用されます。同様に、PSTN に向けて発信ダイヤルピア 200 を使用して DPG 200 を定義します。DPG 200 は、Webex からの着信ダイヤルピアに適用されます。

    
voice class dpg 100 
 description Route calls to Webex Calling 
 dial-peer 100 
voice class dpg 200 
 description Route calls to PSTN 
 dial-peer 200

    以下は、設定のフィールドの説明です。

    ダイヤルピア 100

    発信ダイヤルピアをダイヤルピア グループに関連付けます。詳細については、voice-class dpg を参照してください。

  2. ダイヤルピア グループを適用して、Webex から PSTN および PSTN から Webex に通話をルーティングします。 

    
dial-peer voice 100
 destination dpg 200
dial-peer voice 200
 destination dpg 100

    以下は、設定のフィールドの説明です。

    宛先 dpg 200

    どのダイヤルピア グループを指定し、この着信ダイヤルピアに提示されるコールのアウトバウンド処理に使用するかを指定します。

    これにより、ローカル ゲートウェイの設定が終了します。CUBE 機能が初めて設定される場合は、設定を保存し、プラットフォームを再読み込みします。

TDM PSTN トランクを使用したローカル ゲートウェイの設定

Webex Calling に向かってトランクを構築した後、次の設定を使用して、ループバック コール ルーティングを持つ PSTN サービスの TDM トランクを作成し、Webex コール レッグのメディア最適化を可能にします。

IP メディアの最適化を必要としない場合は、SIP PSTN トランクの設定手順に従います。PSTN VoIP ダイヤルピアの代わりに、音声ポートと POTS ダイヤルピア（ステップ 2 と 3 に示すように）を使用します。

1

ループバック ダイヤル ピア設定では、ダイヤル ピア グループとコール ルーティング タグを使用して、コール ルーティング ループを作成することなく、コールが Webex と PSTN の間で正しくパスされるようにします。コール ルーティング タグを追加および削除するために使用される次のトランスレーション ルールを設定します。


voice translation-rule 100 
 rule 1 /^\+/ /A2A/ 

voice translation-profile 100 
 translate called 100 

voice translation-rule 200 
 rule 1 /^/ /A1A/ 

voice translation-profile 200 
 translate called 200 

voice translation-rule 11 
 rule 1 /^A1A/ // 

voice translation-profile 11 
 translate called 11 

voice translation-rule 12 
 rule 1 /^A2A44/ /0/
 rule 2/^A2A/ /00/

voice translation-profile 12 
 translate called 12

以下は、設定のフィールドの説明です。

音声翻訳ルール

ルールで定義された正規表現を使用して、コール ルーティング タグを追加または削除します。十進法を超える数字（「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 インターフェイスの基本設定には、以下が含まれる場合があります。


card type e1 0 2 
isdn switch-type primary-net5 
controller E1 0/2/0 
 pri-group timeslots 1-31
3

次の TDM PSTN ダイヤル ピアを設定します。


dial-peer voice 200 pots 
 description Inbound/Outbound PRI PSTN trunk 
 destination-pattern BAD.BAD 
 translation-profile incoming 200 
 direct-inward-dial 
 port 0/2/0:15

以下は、設定のフィールドの説明です。 


dial-peer voice 200 pots
 description Inbound/Outbound PRI PSTN trunk

タグ 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 にルーティングされます。ルーティング タグを削除した後、コールはダイヤルピア グループを使用して発信トランクにルーティングされます。


dial-peer voice 10 voip
 description Outbound loop-around leg
 destination-pattern BAD.BAD
 session protocol sipv2
 session target ipv4:192.168.80.14
 voice-class sip bind control source-interface GigabitEthernet0/0/0
 voice-class sip bind media source-interface GigabitEthernet0/0/0
 dtmf-relay rtp-nte
 codec g711alaw
 no vad 

dial-peer voice 11 voip
 description Inbound loop-around leg towards Webex
 translation-profile incoming 11
 session protocol sipv2
 incoming called-number A1AT
 voice-class sip bind control source-interface GigabitEthernet0/0/0
 voice-class sip bind media source-interface GigabitEthernet0/0/0
 dtmf-relay rtp-nte
 codec g711alaw
 no vad 

dial-peer voice 12 voip
 description Inbound loop-around leg towards PSTN
 translation-profile incoming 12
 session protocol sipv2
 incoming called-number A2AT
 voice-class sip bind control source-interface GigabitEthernet0/0/0
 voice-class sip bind media source-interface GigabitEthernet0/0/0
 dtmf-relay rtp-nte
 codec g711alaw 
 no vad

以下は、設定のフィールドの説明です。 


dial-peer voice 10 voip
 description Outbound loop-around leg

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

次のコール ルーティング設定を追加します。

  1. ダイヤルピア グループを作成して、ループバック経由で PSTN と Webex トランク間のコールをルーティングします。

    
voice class dpg 100
 description Route calls to Webex Calling
 dial-peer 100
voice class dpg 200
 description Route calls to PSTN
 dial-peer 200
voice class dpg 10
 description Route calls to Loopback
 dial-peer 10

    以下は、設定のフィールドの説明です。

    ダイヤルピア 100

    発信ダイヤルピアをダイヤルピア グループに関連付けます。詳細については、voice-class dpg を参照してください。

  2. ダイヤル ピア グループを適用して通話をルーティングします。

    
dial-peer voice 100
 destination dpg 10
dial-peer voice 200
 destination dpg 10
dial-peer voice 11
 destination dpg 100
dial-peer voice 12
 destination dpg 200

    以下は、設定のフィールドの説明です。

    宛先 dpg 200

    どのダイヤルピア グループを指定し、この着信ダイヤルピアに提示されるコールのアウトバウンド処理に使用するかを指定します。

これにより、ローカル ゲートウェイの設定が終了します。CUBE 機能が初めて設定される場合は、設定を保存し、プラットフォームを再読み込みします。
ローカル ゲートウェイを既存の Unified CM 環境で構成する

前のセクションの PSTN-Webex Calling の設定は、Cisco Unified Communications Manager (UCM) クラスタに追加のトランクを含めるように変更できます。この場合、すべてのコールは Unified CM 経由でルーティングされます。ポート 5060 の UCM からのコールは PSTN にルーティングされ、ポート 5065 からのコールは Webex Calling にルーティングされます。この通話シナリオを含めるには、次の増分設定を追加できます。

1

以下の音声クラス URI を設定:

  1. ポート経由の SIP を使用して、Unified CM から Webex 通話を分類します。

    
voice class uri 300 sip
 pattern :5065

  2. ポート経由の SIP を使用して、Unified CM から PSTN コールを分類します。

    
voice class uri 400 sip
 pattern 192\.168\.80\.6[0-5]:5060

    発信元のアドレスとポート番号を記述した 1 つ以上のパターンを使用して、UCM からの着信メッセージを PSTN トランクに分類します。必要に応じて、正規表現を使用して、一致するパターンを定義することができます。

    上記の例では、192.168.80.60 ～ 65 およびポート番号 5060 の任意の IP アドレスに正規表現が使用されます。

2

Unified CM ホストへの SRV ルーティングを指定するには、次の DNS レコードを設定します。

IOS XE は、ターゲット UCM ホストとポートをローカルで判別するためにこれらのレコードを使用します。この設定では、DNS システムでレコードを設定する必要はありません。DNS を使用する場合は、これらのローカル設定は必要ありません。


ip host ucmpub.mydomain.com 192.168.80.60
ip host ucmsub1.mydomain.com 192.168.80.61
ip host ucmsub2.mydomain.com 192.168.80.62
ip host ucmsub3.mydomain.com 192.168.80.63
ip host ucmsub4.mydomain.com 192.168.80.64
ip host ucmsub5.mydomain.com 192.168.80.65
ip host _sip._udp.wxtocucm.io srv 0 1 5065 ucmpub.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub1.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub2.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub3.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub4.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub5.mydomain.com
ip host _sip._udp.pstntocucm.io srv 0 1 5060 ucmpub.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub1.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub2.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub3.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub4.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub5.mydomain.com

以下は、設定のフィールドの説明です。

次のコマンドにより、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

次のダイヤル ピアを設定します。

  1. Unified CM と Webex Calling 間の通話のダイヤル ピア:

    
dial-peer voice 300 voip
 description UCM-Webex Calling trunk
 destination-pattern BAD.BAD
 session protocol sipv2
 session target dns:wxtocucm.io
 incoming uri via 300
 voice-class codec 100
 voice-class sip bind control source-interface GigabitEthernet 0/0/0
 voice-class sip bind media source-interface GigabitEthernet 0/0/0
 dtmf-relay rtp-nte
 no vad

    以下は、設定のフィールドの説明です。

    
dial-peer voice 300 voip
 description UCM-Webex Calling trunk

    タグ 300 で VoIP ダイヤルピアを定義し、管理とトラブルシューティングを容易にする意味のある説明を提供します。

    destination-pattern BAD.BAD

    着信ダイヤルピア グループを使用して発信コールをルーティングする場合は、ダミー通知先パターンが必要です。この場合、有効な宛先パターンを使用できます。

    session protocol sipv2

    ダイヤルピア 300 が SIP コール レッグを処理するように指定します。詳細については、セッション プロトコル (ダイヤルピア) を参照してください。

    セッション ターゲット dns:wxtocucm.io

    DNS SRV 解決により複数の Unified CM ノードのセッション ターゲットを定義します。この場合、ローカルで定義された SRV レコード wxtocucm.io がコールを転送するために使用されます。

    incoming uri via 300

    音声クラス URI 300 を使用して、ソース ポート 5065 を使用して、Unified CM からすべての着信トラフィックをこのダイヤルピアに誘導します。詳細については、着信 uri を参照してください。

    音声クラスのコーデック 100

    Unified CM 間のコールのコーデック フィルタ リストを示します。詳細については、音声クラス コーデックを参照してください。

    bind control source-interface GigabitEthernet0/0/0

    PSTN に送信されるメッセージのソース インターフェイスと関連する IP アドレスを設定します。詳細については、バインドを参照してください。

    bind media source-interface GigabitEthernet0/0/0

    PSTN に送信されるメディアのソース インターフェイスと関連する IP アドレスを設定します。詳細については、バインドを参照してください。

    dtmf-relay rtp-nte

    通話レグで予想される DTMF 機能として RTP-NTE (RFC2833) を定義します。詳細については、「DTMF リレー (音声オーバー IP)」を参照してください。

    no vad

    音声アクティブティの検出を無効にします。詳細については、vad (ダイヤル ピア) を参照してください。

  2. Unified CM と PSTN 間の通話のダイヤル ピア:

    
dial-peer voice 400 voip
 description UCM-PSTN trunk
 destination-pattern BAD.BAD
 session protocol sipv2
 session target dns:pstntocucm.io
 incoming uri via 400
 voice-class codec 100 
 voice-class sip bind control source-interface GigabitEthernet 0/0/0
 voice-class sip bind media source-interface GigabitEthernet 0/0/0
 dtmf-relay rtp-nte
 no vad

    以下は、設定のフィールドの説明です。

    
dial-peer voice 400 voip
 description UCM-PSTN trunk

    タグ 400 で VoIP ダイヤルピアを定義し、管理とトラブルシューティングを容易にする意味のある説明を提供します。

    destination-pattern BAD.BAD

    着信ダイヤルピア グループを使用して発信コールをルーティングする場合は、ダミー通知先パターンが必要です。この場合、有効な宛先パターンを使用できます。

    session protocol sipv2

    ダイヤルピア 400 が SIP コール レッグを処理するように指定します。詳細については、セッション プロトコル (ダイヤルピア) を参照してください。

    セッションターゲット dns:pstntocucm.io

    DNS SRV 解決により複数の Unified CM ノードのセッション ターゲットを定義します。この場合、ローカルで定義された SRV レコード pstntocucm.io がコールを転送するために使用されます。

    400 経由の着信 uri

    音声クラス URI 400 を使用して、ソース ポート 5060 を使用して指定された Unified CM ホストからのすべての着信トラフィックをこのダイヤルピアに誘導します。詳細については、着信 uri を参照してください。

    音声クラスのコーデック 100

    Unified CM 間のコールのコーデック フィルタ リストを示します。詳細については、音声クラス コーデックを参照してください。

    bind control source-interface GigabitEthernet0/0/0

    PSTN に送信されるメッセージのソース インターフェイスと関連する IP アドレスを設定します。詳細については、バインドを参照してください。

    bind media source-interface GigabitEthernet0/0/0

    PSTN に送信されるメディアのソース インターフェイスと関連する IP アドレスを設定します。詳細については、バインドを参照してください。

    dtmf-relay rtp-nte

    通話レグで予想される DTMF 機能として RTP-NTE (RFC2833) を定義します。詳細については、「DTMF リレー (音声オーバー IP)」を参照してください。

    no vad

    音声アクティブティの検出を無効にします。詳細については、vad (ダイヤル ピア) を参照してください。

4

次の設定を使用してコール ルーティングを追加します。

  1. ダイヤルピア グループを作成し、Unified CM と Webex Calling の間でコールをルーティングします。DPG 100 を 発信ダイヤルピア 100 で Webex Calling に対して定義します。DPG 100 は、Unified CM からの関連付けられた着信ダイヤルピアに適用されます。同様に、Unified CM に対して発信ダイヤルピア 300 を使用して DPG 300 を定義します。DPG 300 は、Webex からの着信ダイヤルピアに適用されます。

    
voice class dpg 100
 description Route calls to Webex Calling
 dial-peer 100
voice class dpg 300
 description Route calls to Unified CM Webex Calling trunk
 dial-peer 300

  2. Unified CM と PSTN の間でコールをルーティングするためのダイヤル ピア グループを作成します。PSTN に対して発信ダイヤルピア 200 で DPG 200 を定義します。DPG 200 は、Unified CM から関連する着信ダイヤルピアに適用されます。同様に、Unified CM に対して発信ダイヤルピア 400 を使用して DPG 400 を定義します。DPG 400 は、PSTN からの着信ダイヤルピアに適用されます。

    
voice class dpg 200
 description Route calls to PSTN
 dial-peer 200
voice class dpg 400
 description Route calls to Unified CM PSTN trunk
 dial-peer 400

    以下は、設定のフィールドの説明です。

    ダイヤルピア 100

    発信ダイヤルピアをダイヤルピア グループに関連付けます。詳細については、voice-class dpg を参照してください。

  3. ダイヤルピア グループを適用して、Webex から Unified CM および Unified CM から Webex に通話をルーティングします。 

    
dial-peer voice 100
 destination dpg 300
dial-peer voice 300
 destination dpg 100

    以下は、設定のフィールドの説明です。

    宛先 dpg 300

    どのダイヤルピア グループを指定し、この着信ダイヤルピアに提示されるコールのアウトバウンド処理に使用するかを指定します。

  4. ダイヤルピア グループを適用して、PSTN から Unified CM から Unified CM から PSTN に通話をルーティングします。

    
dial-peer voice 200
 destination dpg 400
dial-peer voice 400
 destination dpg 200

    これにより、ローカル ゲートウェイの設定が終了します。CUBE 機能が初めて設定されている場合、設定を保存し、プラットフォームを再読み込みします。

診断署名でローカル ゲートウェイを監視し、トラブルシューティングする

診断署名 (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 以上を実行するローカル ゲートウェイ

  1. 診断署名はデフォルトで有効になっています。

  2. デバイスが IOS XE 17.6.1 以上を実行している場合に、プロアクティブ通知を送信するために使用する安全なメール サーバーを構成します。

    
configure terminal 
call-home  
mail-server :@ priority 1 secure tls 
end

  3. 通知する管理者 ds_email のメールアドレスを使用して、環境変数を設定します。

    
configure terminal 
call-home  
diagnostic-signature 
LocalGateway(cfg-call-home-diag-sign)environment ds_email  
end

プロアクティブ モニタリングのために診断署名をインストールする

CPU 使用率の監視

この DS は SNMP OID 1.3.6.1.4.1.9.2.1.56 を使用して 5 秒間の CPU 使用率を追跡します。使用率が 75% 以上に達すると、すべてのデバッグが無効し、ローカル ゲートウェイにインストールした診断署名をアンインストールします。下記の手順を実行して署名をインストールします。

  1. コマンドを使用して SNMP を有効に設定し、 snmp を表示します。SNMP が有効になっていない場合は、snmp-server manager コマンドを設定します。

    
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

  2. Diagnostic Signatures Lookup Tool の以下のドロップダウンオプションを使用して、DS 64224 をダウンロードします。

    copy ftp://username:password@/DS_64224.xml bootflash:

    フィールド名

    フィールド値

    プラットフォーム

    Cisco 4300、4400 ISR シリーズ、または Catalyst 8000V Edge ソフトウェア

    製品

    Webex Calling ソリューションの CUBE Enterprise

    問題の範囲

    パフォーマンス

    問題の種類

    メール通知による高 CPU 使用率

    Diagnostic Signatures Lookup ツールから DS 64224 をダウンロードする

  3. DS XML ファイルをローカルゲートウェイフラッシュにコピーします。

    copy ftp://username:password@/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)

  4. ローカルゲートウェイに DS XML ファイルをインストールします。

    
call-home diagnostic-signature load DS_64224.xml 
Load file DS_64224.xml success

  5. 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 使用率の監視を続行してください。

異常な通話切断の監視

この DS は、10 分ごとに SNMP ポーリングを使用して、SIP エラーの 403、488、503 で異常な通話切断を検出します。 エラーカウントの増分が最後の投票から 5 以上である場合、syslog とメール通知が生成されます。 署名をインストールするには、以下の手順を使用してください。

  1. コマンド show snmp を使用して、SNMP が有効 になっている必要があります。SNMP が有効になっていない場合は、snmp-server manager コマンドを設定します。 

    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

  2. Diagnostic Signatures Lookup Tool の以下のオプションを使用して、DS 65221 をダウンロードします。

    フィールド名

    フィールド値

    プラットフォーム

    Cisco 4300、4400 ISR シリーズ、または Catalyst 8000V Edge ソフトウェア

    製品

    Webex Calling ソリューションの CUBE Enterprise

    問題の範囲

    パフォーマンス

    問題の種類

    メールおよび Syslog 通知による SIP の異常通話切断検出

  3. DS XML ファイルをローカルゲートウェイにコピーします。

    copy ftp://username:password@/DS_65221.xml bootflash:

  4. ローカルゲートウェイに DS XML ファイルをインストールします。 

    
call-home diagnostic-signature load DS_65221.xml 
Load file DS_65221.xml success

  5. コマンド 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 を使用して、以下の手順を使用して、診断データの収集を自動化します。

  1. 診断データをアップロードするために、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://:@cxd.cisco.com"  
end

    例: 

    
call-home  
diagnostic-signature 
environment ds_fsurl_prefix " environment ds_fsurl_prefix "scp://612345678:abcdefghijklmnop@cxd.cisco.com"

  2. コマンド show snmp を使用して、SNMP が有効 になっている必要があります。SNMP が有効になっていない場合は、snmp-server manager コマンドを設定します。

    
show snmp 
%SNMP agent not enabled 
 
config t 
snmp-server manager 
end

  3. 高 CPU 使用率の期間中に、すべてのデバッグと診断署名を無効にすることを推奨するプロアクティブな措置として、高 CPU モニタリング DS 64224 をインストールすることを推奨します。Diagnostic Signatures Lookup Tool の以下のオプションを使用して、DS 64224 をダウンロードします。

    フィールド名

    フィールド値

    プラットフォーム

    Cisco 4300、4400 ISR シリーズ、または Catalyst 8000V Edge ソフトウェア

    製品

    Webex Calling ソリューションの CUBE Enterprise

    問題の範囲

    パフォーマンス

    問題の種類

    通知メールによる CPU 使用率が高い

  4. 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

  5. DS XML ファイルをローカルゲートウェイにコピーします。

    
copy ftp://username:password@/DS_64224.xml bootflash: 
copy ftp://username:password@/DS_65095.xml bootflash:

  6. 高 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

  7. 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

    DSLGW_IEC_C_all_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 名

トリガー済み/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 deinstall

例:

call-home diagnostic-signature deinstall 64224

診断署名ルックアップ ツールに、展開で見られる問題に基づいて、定期的に新しい署名が追加されます。TAC では現在、新しいカスタム署名の作成リクエストをサポートしていません。

ローカル ゲートウェイとして CUBE のハイ アベイラビリティを実装する

基礎

前提条件

Webex Calling のローカル ゲートウェイとして CUBE HA を展開する前に、以下の概念を深く理解するようにしてください。

この記事で提供される構成ガイドラインは、既存の音声構成が設定されていない専用のローカル ゲートウェイ プラットフォームが使用されていることを前提としています。既存の 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 設定ガイドを次に示します。

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

インターフェイスのステータスを追跡するために、グローバル レベルでインターフェイス トラッキングを構成します。

conf t
 track 1 interface GigabitEthernet1 line-protocol
 track 2 interface GigabitEthernet2 line-protocol
 exit


VCUBE-1#conf t

VCUBE-1(config)#track 1 interface GigabitEthernet1 line-protocol

VCUBE-1(config-track)#track 2 interface GigabitEthernet2 line-protocol

VCUBE-1(config-track)#exit

VCUBE-2#conf t

VCUBE-2(config)#track 1 interface GigabitEthernet1 line-protocol

VCUBE-2(config-track)#track 2 interface GigabitEthernet2 line-protocol

VCUBE-2(config-track)#exit

トラッキング CLI は、トラフィック インターフェイスがダウンした後、アクティブ ルートがアクティブな役割を果たすように、RG 内で音声トラフィックインターフェイスの状態を追跡するために使用されます。

2

アプリケーション冗長性サブモード下の VoIP HA で使用する RG を構成します。

redundancy
  application redundancy
   group 1
    name LocalGateway-HA
    priority 100 failover threshold 75
    control GigabitEthernet3 protocol 1
    data GigabitEthernet3
    timers delay 30 reload 60
    track 1 shutdown
    track 2 shutdown
    exit
   protocol 1
    timers hellotime 3 holdtime 10
   exit
  exit
 exit


VCUBE-1(config)#redundancy

VCUBE-1(config-red)#application redundancy

VCUBE-1(config-red-app)#group 1

VCUBE-1(config-red-app-grp)#name LocalGateway-HA

VCUBE-1(config-red-app-grp)#priority 100 failover threshold 75

VCUBE-1(config-red-app-grp)#control GigabitEthernet3 protocol 1

VCUBE-1(config-red-app-grp)#data GigabitEthernet3

VCUBE-1(config-red-app-grp)#timers delay 30 reload 60

VCUBE-1(config-red-app-grp)#track 1 shutdown

VCUBE-1(config-red-app-grp)#track 2 shutdown

VCUBE-1(config-red-app-grp)#exit

VCUBE-1(config-red-app)#protocol 1

VCUBE-1(config-red-app-prtcl)#timers hellotime 3 holdtime 10

VCUBE-1(config-red-app-prtcl)#exit

VCUBE-1(config-red-app)#exit

VCUBE-1(config-red)#exit

VCUBE-1(config)#

VCUBE-2(config)#redundancy

VCUBE-2(config-red)#application redundancy

VCUBE-2(config-red-app)#group 1

VCUBE-2(config-red-app-grp)#name LocalGateway-HA

VCUBE-2(config-red-app-grp)#priority 100 failover threshold 75

VCUBE-2(config-red-app-grp)#control GigabitEthernet3 protocol 1

VCUBE-1(config-red-app-grp)#data GigabitEthernet3

VCUBE-2(config-red-app-grp)#timers delay 30 reload 60

VCUBE-2(config-red-app-grp)#track 1 shutdown

VCUBE-2(config-red-app-grp)#track 2 shutdown

VCUBE-2(config-red-app-grp)#exit

VCUBE-2(config-red-app)#protocol 1

VCUBE-2(config-red-app-prtcl)#timers hellotime 3 holdtime 10

VCUBE-2(config-red-app-prtcl)#exit

VCUBE-2(config-red-app)#exit

VCUBE-2(config-red)#exit

VCUBE-2(config)#

この構成で使用されるフィールドの説明を次に示します。

  • 冗長性: 冗長モードに入る

  • アプリケーション冗長性: アプリケーション冗長設定モードに入ります

  • group—冗長性アプリケーション グループ設定モードに入ります

  • name LocalGateway-HA—RG グループの名前を定義します。

  • 優先度 100 フェールオーバーしきい値 75: RG の初期優先順位とフェールオーバーしきい値を指定します。

  • タイマー遅延 30 reload 60: 遅延と再読み込みに対して 2 回設定します。

    • インターフェイスが起動した後、RG グループの初期設定と役割のネゴシエーションの遅延時間を示す遅延タイマーです。デフォルトは 30 秒です。範囲は 0-10000 秒です

    • Reload—これは、リロード後の RG グループ初期設定と役割ネゴシエーションの遅延時間です。デフォルトは 60 秒です。範囲は 0-10000 秒です

    • デフォルトのタイマーが推奨されていますが、これらのタイマーは、ネットワークのルーティングが安定した時点の後、RG プロトコルのネゴシエーションが行われることを保証するために、ルーターの起動/再読み込み中に発生する可能性がある追加のネットワーク集約遅延に合わせて調整される場合があります。たとえば、フェールオーバー後に、新しいスタンバイに最大 20 秒間かかり、新しいアクティブから最初の RG HELLO パケットを確認する場合は、この遅延を考慮して、最初の RG HELLO パケットを「タイマー遅延 60 リロード 120」に調整する必要があります。

  • control GigabitEthernet3 protocol 1—2 つの CUBE 間でキープアライブ メッセージとハローメッセージを交換するために使用されるインターフェイスを構成し、コントロール インターフェイスに接続されるプロトコル インスタンスを指定し、冗長アプリケーション プロトコル構成モードに入ります

  • data GigabitEthernet3—データ トラフィックのチェックポイントに使用されるインターフェイスを設定します

  • track - インターフェイスの RG グループ トラッキング

  • プロトコル 1—コントロール インターフェイスに接続されるプロトコル インスタンスを指定します。冗長性アプリケーション プロトコル設定モードに入ります。

  • タイマー hellotime 3 holdtime 10: hellotime と holdtime の 2 つのタイマーを設定します。

    • Hellotime— 連続する hello メッセージの間隔 (デフォルトで 3 秒)。範囲は 250 ミリ秒から 254 秒です

    • Holdtime — Hello メッセージの受信と送信ルーターが失敗した推定の間隔。この継続時間は、hello time (デフォルトの 10 秒より長くする必要があります) 以上である必要があります。範囲は 750 ミリ秒から 255 秒です

      Holdtime タイマーを hellotime タイマーの最低 3 倍の値に設定することをお勧めします。

3

CUBE アプリケーションのボックス間の冗長性を有効にします。voice service voip の下にある前のステップから RG を構成します。これにより、CUBE アプリケーションは冗長性プロセスをコントロールすることができます。

voice service voip
   redundancy-group 1
   exit

VCUBE-1(config)#voice service voip

VCUBE-1(config-voi-serv)#redundancy-group 1


                        % Created RG 1 association with Voice B2B HA; reload the router for the new configuration to take effect
                      

VCUBE-1(config-voi-serv)# exit

VCUBE-2(config)#voice service voip

VCUBE-2(config-voi-serv)#redundancy-group 1


                        % Created RG 1 association with Voice B2B HA; reload the router for the new configuration to take effect
                      

VCUBE-2(config-voi-serv)# exit

redundancy-group 1: このコマンドを追加および削除するには、更新された構成を有効にするために再読み込みが必要です。すべての構成が適用された後で、プラットフォームを再読み込みします。

4

以下に示すように、Gig1 と Gig2 インターフェイスをそれぞれの仮想 IP で構成し、冗長性インターフェイス識別子 (rii) を適用します。

VCUBE-1(config)#interface GigabitEthernet1

VCUBE-1(config-if)# redundancy rii 1

VCUBE-1(config-if)# redundancy group 1 ip 198.18.1.228 exclusive

VCUBE-1(config-if)# exit

VCUBE-1(config)#

VCUBE-1(config)#interface GigabitEthernet2

VCUBE-1(config-if)# redundancy rii 2

VCUBE-1(config-if)# redundancy group 1 ip 198.18.133.228 exclusive

VCUBE-1(config-if)# exit

VCUBE-2(config)#interface GigabitEthernet1

VCUBE-2(config-if)# redundancy rii 1

VCUBE-2(config-if)# redundancy group 1 ip 198.18.1.228 exclusive

VCUBE-2(config-if)# exit

VCUBE-2(config)#

VCUBE-2(config)#interface GigabitEthernet2

VCUBE-2(config-if)# redundancy rii 2

VCUBE-2(config-if)# redundancy group 1 ip 198.18.133.228 exclusive

VCUBE-v(config-if)# exit

この構成で使用されるフィールドの説明を次に示します。

  • redundancy rii: 冗長グループの冗長インターフェイス ID を設定します。仮想 MAC (VMAC) アドレスを生成するために必要です。同じ VIP を持つ各ルーター (アクティブ/スタンバイ) のインターフェイスで同じ rii ID 値を使用する必要があります。

    同じ LAN に複数の B2B ペアがある場合、各ペアはそれぞれのインターフェイスに固有の RII ID を持っている必要があります（衝突を防ぐため）。「冗長性アプリケーショングループをすべて表示」は正しいローカルおよびピア情報を示す必要があります。

  • 冗長グループ 1: 上記のステップ 2 で作成された冗長グループとインターフェイスを関連付けます。RG グループ、およびこの物理インターフェイスに割り当てられた VIP を構成します。

    冗長性のために別のインターフェイスを使用することが必須です。つまり、音声トラフィックに使用されるインターフェイスは、上記の手順 2 で指定したコントロールとデータ インターフェイスとして使用できません。この例では、RG コントロール/データにギガビット インターフェイス 3 が使用されています。

5

最初の CUBE 構成を保存し、再読み込みします。

最後にリロードするプラットフォームは常にスタンバイです。

VCUBE-1#wr


                        Building configuration...
                      


                        [OK]
                      

VCUBE-1#reload


                        Proceed with reload? [confirm]

VCUBE-1 が完全に起動したら、 VCUBE-2 の構成を保存し、再読み込みします。

VCUBE-2#wr


                        Building configuration...
                      


                        [OK]
                      

VCUBE-2#reload


                        Proceed with reload? [confirm]

6

ボックス間の構成が期待どおりに機能していることを確認します。関連する出力は太字で強調表示されます。

VCUBE-2 を最後にリロードし、設計上の考慮事項に従います。最後にリロードするプラットフォームは常に [スタンバイ] 状態です。 


VCUBE-1#show redundancy application group all
Faults states Group 1 info:
       Runtime priority: [100]
               RG Faults RG State: Up.
                       Total # of switchovers due to faults:           0
                       Total # of down/up state changes due to faults: 0
Group ID:1
Group Name:LocalGateway-HA
  
Administrative State: No Shutdown
Aggregate operational state: Up
My Role: ACTIVE
Peer Role: STANDBY
Peer Presence: Yes
Peer Comm: Yes
Peer Progression Started: Yes

RF Domain: btob-one
         RF state: ACTIVE
         Peer RF state: STANDBY HOT

RG Protocol RG 1
------------------
        Role: Active
        Negotiation: Enabled
        Priority: 100
        Protocol state: Active
        Ctrl Intf(s) state: Up
        Active Peer: Local
        Standby Peer: address 10.1.1.2, priority 100, intf Gi3
        Log counters:
                role change to active: 1
                role change to standby: 1
                disable events: rg down state 0, rg shut 0
                ctrl intf events: up 1, down 0, admin_down 0
                reload events: local request 0, peer request 0

RG Media Context for RG 1
--------------------------
        Ctx State: Active
        Protocol ID: 1
        Media type: Default
        Control Interface: GigabitEthernet3
        Current Hello timer: 3000
        Configured Hello timer: 3000, Hold timer: 10000
        Peer Hello timer: 3000, Peer Hold timer: 10000
        Stats:
            Pkts 1509, Bytes 93558, HA Seq 0, Seq Number 1509, Pkt Loss 0
            Authentication not configured
            Authentication Failure: 0
            Reload Peer: TX 0, RX 0
            Resign: TX 0, RX 0
    Standy Peer: Present. Hold Timer: 10000
            Pkts 61, Bytes 2074, HA Seq 0, Seq Number 69, Pkt Loss 0

VCUBE-1#

VCUBE-2#show redundancy application group all
Faults states Group 1 info:
       Runtime priority: [100]
               RG Faults RG State: Up.
                       Total # of switchovers due to faults:           0
                       Total # of down/up state changes due to faults: 0
Group ID:1
Group Name:LocalGateway-HA
  
Administrative State: No Shutdown
Aggregate operational state: Up
My Role: STANDBY
Peer Role: ACTIVE
Peer Presence: Yes
Peer Comm: Yes
Peer Progression Started: Yes

RF Domain: btob-one
         RF state: ACTIVE
         Peer RF state: STANDBY HOT

RG Protocol RG 1
------------------
        Role: Active
        Negotiation: Enabled
        Priority: 100
        Protocol state: Active
        Ctrl Intf(s) state: Up
        Active Peer: address 10.1.1.2, priority 100, intf Gi3
        Standby Peer: Local
        Log counters:
                role change to active: 1
                role change to standby: 1
                disable events: rg down state 0, rg shut 0
                ctrl intf events: up 1, down 0, admin_down 0
                reload events: local request 0, peer request 0

RG Media Context for RG 1
--------------------------
        Ctx State: Active
        Protocol ID: 1
        Media type: Default
        Control Interface: GigabitEthernet3
        Current Hello timer: 3000
        Configured Hello timer: 3000, Hold timer: 10000
        Peer Hello timer: 3000, Peer Hold timer: 10000
        Stats:
            Pkts 1509, Bytes 93558, HA Seq 0, Seq Number 1509, Pkt Loss 0
            Authentication not configured
            Authentication Failure: 0
            Reload Peer: TX 0, RX 0
            Resign: TX 0, RX 0
    Standy Peer: Present. Hold Timer: 10000
            Pkts 61, Bytes 2074, HA Seq 0, Seq Number 69, Pkt Loss 0

VCUBE-2#

両方の CUBE でローカル ゲートウェイを構成する

この例の構成では、Control Hub から以下のトランク情報を使用して、VCUBE-1、VCUBE-2 の両方のプラットフォームでローカルゲートウェイを構成しています。この設定のユーザー名とパスワードは以下のとおりです。

  • ユーザー名:フセイン1076_LGU

  • パスワード:lOV12MEaZx

1

クレデンシャルまたは共有秘密で使用する前に、以下のコマンドを使用して、設定キーがパスワードに対して作成されていることを確認してください。Type 6 パスワードは、AES 暗号化とこのユーザー定義の設定キーを使用して暗号化されます。 


LocalGateway#conf t
LocalGateway(config)#key config-key password-encrypt Password123
LocalGateway(config)#password encryption aes

これは、上に表示されている Control Hub のパラメーターに基づき、両方のプラットフォームに適用し、保存し、リロードするローカ ルゲートウェイの構成です。Control Hub からの SIP ダイジェスト資格情報は、太字でハイライトされます。


configure terminal
crypto pki trustpoint dummyTp
revocation-check crl
exit
sip-ua
crypto signaling default trustpoint dummyTp cn-san-validate server
transport tcp tls v1.2
end


configure terminal
crypto pki trustpool import clean url
http://www.cisco.com/security/pki/trs/ios_core.p7b
end


configure terminal
voice service voip
  ip address trusted list
    ipv4 x.x.x.x y.y.y.y
    exit
   allow-connections sip to sip
  media statistics
  media bulk-stats
  no supplementary-service sip refer
  no supplementary-service sip handle-replaces
  fax protocol pass-through g711ulaw
  stun
    stun flowdata agent-id 1 boot-count 4
    stun flowdata shared-secret 0 Password123!
  sip
    g729 annexb-all
    early-offer forced
    end


configure terminal
voice class sip-profiles 200
  rule 9 request ANY sip-header SIP-Req-URI modify "sips:(.*)"
"sip:\1"
  rule 10 request ANY sip-header To modify ""
""
  rule 13 response ANY sip-header To modify ""
";otg=hussain1076_lgu>"
  rule 30 request ANY sip-header P-Asserted-Identity modify
"sips:(.*)" "sip:\1"


voice class codec 99
  codec preference 1 g711ulaw
  codec preference 2 g711ulaw
  exit

voice class srtp-crypto 200
  crypto 1 AES_CM_128_HMAC_SHA1_80
  exit

voice class stun-usage 200
  stun usage firewall-traversal flowdata
  exit






voice class tenant 200
  registrar dns:40462196.cisco-bcld.com scheme sips expires 240
refresh-ratio 50 tcp tls
  credentials number Hussain5091_LGU username Hussain1076_LGU
password 0 lOV12MEaZx realm Broadworks 
  authentication username Hussain5091_LGU password 0 lOV12MEaZx
realm BroadWorks

  authentication username Hussain5091_LGU password 0 lOV12MEaZx
realm 40462196.cisco-bcld.com
  no remote-party-id
  sip-server dns:40462196.cisco-bcld.com
  connection-reuse
  srtp-crypto 200
  session transport tcp tls
  url sips
  error-passthru
  asserted-id pai
  bind control source-interface GigabitEthernet1
  bind media source-interface GigabitEthernet1
  no pass-thru content custom-sdp
  sip-profiles 200
  outbound-proxy dns:la01.sipconnect-us10.cisco-bcld.com
  privacy-policy passthru


voice class tenant 100
  session transport udp
  url sip
  error-passthru
  bind control source-interface GigabitEthernet2
  bind media source-interface GigabitEthernet2
  no pass-thru content custom-sdp

voice class tenant 300
  bind control source-interface GigabitEthernet2
  bind media source-interface GigabitEthernet2
  no pass-thru content custom-sdp
  

voice class uri 100 sip
 host ipv4:198.18.133.3

voice class uri 200 sip
 pattern dtg=hussain1076.lgu



dial-peer voice 101 voip
 description Outgoing dial-peer to IP PSTN
 destination-pattern BAD.BAD
 session protocol sipv2
 session target ipv4:198.18.133.3
 voice-class codec 99
 voice-class sip tenant 100
 dtmf-relay rtp-nte
 no vad

dial-peer voice 201 voip
 description Outgoing dial-peer to Webex Calling
 destination-pattern BAD.BAD
 session protocol sipv2
 session target sip-server
 voice-class codec 99
 voice-class stun-usage 200
 no voice-class sip localhost
 voice-class sip tenant 200
 dtmf-relay rtp-nte
 srtp
 no vad


voice class dpg 100
 description Incoming WebexCalling(DP200) to IP PSTN(DP101)
 dial-peer 101 preference 1

voice class dpg 200
 description Incoming IP PSTN(DP100) to Webex Calling(DP201)
 dial-peer 201 preference 1





dial-peer voice 100 voip
 desription Incoming dial-peer from IP PSTN
 session protocol sipv2
 destination dpg 200
 incoming uri via 100
 voice-class codec 99
 voice-class sip tenant 300
 dtmf-relay rtp-nte
 no vad

dial-peer voice 200 voip
 description Incoming dial-peer from Webex Calling
 session protocol sipv2
 destination dpg 100
 incoming uri request 200
 voice-class codec 99
 voice-class stun-usage 200
 voice-class sip tenant 200
 dtmf-relay rtp-nte
 srtp
 no vad

end

copy run start

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-1#show redundancy application group 1
Group ID:1
Group Name:LocalGateway-HA

Administrative State: No Shutdown
Aggregate operational state : Up
My Role: Standby
Peer Role: ACTIVE
Peer Presence: Yes
Peer Comm: Yes
Peer Progression Started: Yes

RF Domain: btob-one
         RF state: STANDBY HOT
         Peer RF state: ACTIVE

VCUBE-1#show sip-ua register status
VCUBE-1#


VCUBE-2#show redundancy application group 1
Group ID:1
Group Name:LocalGateway-HA

Administrative State: No Shutdown
Aggregate operational state : Up
My Role: ACTIVE
Peer Role: STATUS
Peer Presence: Yes
Peer Comm: Yes
Peer Progression Started: Yes

RF Domain: btob-one
         RF state: ACTIVE
         Peer RF state: STANDBY HOT

VCUBE-2#show sip-ua register status

Tenant: 200
--------------------Registrar-Index  1 ---------------------
Line                           peer       expires(sec) reg survival P-Associ-URI
============================== ========== ============ === ======== ============
Hussain5091_LGU                -1          48          yes normal
VCUBE-2#

上記の出力から、VCUBE-2 は Webex Calling アクセス SBC への登録を維持するアクティブ LGW であり、「show sip-ua 登録ステータス」の出力は VCUBE-1 では空白です。

3

VCUBE-1 で次のデバッグを有効にします


VCUBE-1#debug ccsip non-call
SIP Out-of-Dialog tracing is enabled
VCUBE-1#debug ccsip info
SIP Call info tracing is enabled
VCUBE-1#debug ccsip message

4

この場合、アクティブ LGW、VCUBE-2 で次のコマンドを実行してフェールオーバーをシミュレートします。


VCUBE-2#redundancy application reload group 1 self

アクティブからスタンバイ LGW への切り替えは、上記に一覧表示されている CLI に加えて、以下のシナリオで発生します。

  • アクティブ ルーターのリロード時

  • アクティブなルーターの電源が再投入される時

  • トラッキングが有効になっているアクティブなルーターの RG 構成されたインターフェイスがシャットダウンされる時

5

VCUBE-1 が Webex Calling アクセス SBC に登録されているかどうかを確認します。VCUBE-2 は今すぐにリロードされます。


              VCUBE-1#show sip-ua register status

Tenant: 200
--------------------Registrar-Index  1 ---------------------
Line                           peer       expires(sec) reg survival P-Associ-URI
============================== ========== ============ === ======== ============
Hussain5091_LGU                -1          56          yes normal
VCUBE-1#

VCUBE-1 がアクティブ LGW になりました。

6

仮想 IP を通じて SIP REGISTER を Webex Calling に送信し、200 OK を受信する VCUBE-1 に関連するデバッグ ログを確認してください。


VCUBE-1#show log

Jan 9 18:37:24.769: %RG_MEDIA-3-TIMEREXPIRED: RG id 1 Hello Time Expired.
Jan 9 18:37:24.771: %RG_PROTCOL-5-ROLECHANGE: RG id 1 role change from Standby to Active
Jan 9 18:37:24.783: %VOICE_HA-2-SWITCHOVER_IND: SWITCHOVER, from STANDBY_HOT to ACTIVE state.
Jan 9 18:37:24.783: //-1/xxxxxxxxxxxx/SIP/Info/info/4096/sip_ha_notify_active_role_event: Received notify active role event

Jan 9 18:37:25.758: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
REGISTER sip: 40462196.cisco-bcld.com:5061 SIP/2.0
Via: SIP/2.0/TLS 198.18.1.228:5061;branch=z9hG4bK0374
From: ;tag=8D573-189
To: 
Date: Thu, 09 Jan 2020 18:37:24 GMT
Call-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97
User-Agent: Cisco-SIPGateway/IOS-16.12.02
Max-Forwards: 70
Timestamp: 1578595044
CSeq: 2 REGISTER
Contact: 
Expires: 240
Supported: path
Content-Length: 0


Jan 9 18:37:25.995: //-1/000000000000/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 401 Unauthorized
Via: SIP/2.0/TLS 198.18.1.228:5061;received=173.38.218.1;branch=z9hG4bK0374;rport=4742
From: ;tag=8D573-189
To: ;tag=SD1u8bd99-1324701502-1578595045969
Date: Thu, 09 Jan 2020 18:37:24 GMT
Call-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97
Timestamp: 1578595044
CSeq: 2 REGISTER
WWW-Authenticate; DIGEST realm="BroadWorks",qop="auth",nonce="BroadWorksXk572qd01Ti58zliBW",algorithm=MD5
Content-Length: 0


Jan 9 18:37:26.000: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
REGISTER sip:40462196.cisco-bcld.com:5061 SIP/2.0
Via: SIP/2.0/TLS 198.18.1.228:5061;branch=z9hG4bK16DC
From: ;tag=8D573-189
To: 
Date: Thu, 09 Jan 2020 18:37:25 GMT
Call-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97
User-Agent:Cisco-SIPGateway/IOS-16.12.02
Max-Forwards: 70
Timestamp: 1578595045
CSeq: 3 REGISTER
Contact: 
Expires: 240
Supported: path
Authorization: Digest username="Hussain1076_LGU",realm="BroadWorks",uri="sips:40462196.cisco-bcld.com:5061",response="b6145274056437b9c07f7ecc08ebdb02",nonce="BroadWorksXk572qd01Ti58z1iBW",cnonce="3E0E2C4D",qop=auth,algorithm=MD5,nc=00000001
Content-Length: 0


Jan 9 18:37:26.190: //1/000000000000/SIP/Msg/ccsipDisplayMsg:

Received:
SIP/2.0 200 OK
Via: SIP/2.0/TLS 198.18.1.228:5061;received=173.38.218.1;branch=z9hG4bK16DC;rport=4742
From: ;tag=8D573-189
To: ;tag=SD1u8bd99-1897486570-1578595-46184
Call-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97
Timestamp: 1578595045
CSeq: 3 REGISTER
Contact: ;expires=120;q=0.5
Allow-Events: call-info,line-seize,dialog,message-summary,as-feature-event,x-broadworks-hoteling,x-broadworks-call-center-status,conference
Content-Length: 0

組織のために Webex Calling を設定する

初回セットアップ ウィザードで通話設定をセットアップする

Webex Calling サービスを稼働させるための最初のステップは、初回セットアップ ウィザード (FTSW) を完了することです。最初のロケーションの FTSW が完了した後では、追加のロケーションに対して完了する必要がありません。

1

受け取ったウェルカム メールのはじめにリンクをクリックします。

管理者のメールアドレスが、自動的に、Control Hub にサインインするためのメール アドレスとして使用されます。サインインすると、管理者パスワードを作成するように求められます。サインインすると、セットアップ ウィザードが自動的に開始します。

2

利用規約を見直して、承諾します。

3

プランを見直して、[はじめに] をクリックします。

アカウント マネージャは FTSW の最初の手順をアクティブにする責任があります。[使い始める] を選択した時に、「通話をセットアップできません」という通知を受け取った場合は、アカウント マネージャーに連絡してください。

4

データ センターがマッピングする国を選択し、顧客の連絡先と顧客アドレス情報を入力します。

5

[次へ: デフォルトのロケーション

6

次のオプションから選択します:

  • パートナー管理者の場合は、[保存して閉じる] をクリックして、顧客管理者が Webex Calling のプロビジョニングを完了するようにします。
  • 必要なロケーションの情報を入力します。ウィザードでロケーションを作成した後、後で他にロケーションを作成できます。

セットアップ ウィザードを完了した後で、作成したロケーションにメイン番号を追加していることを確認してください。

7

このロケーションに適用する次の選択を行います。

  • アナウンス言語: 新規ユーザーと機能に関する音声アナウンスとプロンプト用。
  • メール言語—新規ユーザー向けのメール通信用。
  • 国
  • タイムゾーン
8

[次へ] をクリックします。

9

利用可能な Cisco Webex SIP アドレスを入力し、[次へ] をクリックし、[完了] を選択します。

ロケーションを追加する

始める前に

新しいロケーションを作成するには、以下の情報を指定します。

  • ロケーションの住所

  • 希望する電話番号(オプション)

1

https://admin.webex.com で Control Hub にログインし、[管理] > [ロケーション] に移動します。

新しいロケーションは、初回セットアップ ウィザードを使用して選択した国に対応する地域のデータ センターでホストされます。

2

ロケーションを設定します。

  • ロケーション名—ロケーションを識別する一意の名前を入力します。
  • 国/地域: ロケーションをリンクする国を選択します。たとえば、米国に 1 か所のロケーション (本社) を作成し、イギリスに別のロケーション (支社) を作成することができます。選択した国に応じて、その後の住所のフィールドが決まります。ここには、例として、米国の住所書式を使用したものがあります。
  • ロケーション アドレス—ロケーションのメーリングアドレスを入力します。
  • 市区町村—このロケーションの市区町村を入力します。
  • 州/県/地域—ドロップダウンから都道府県を選択します。
  • ZIP/郵便番号—郵便番号を入力します。
  • アナウンス言語: 新規ユーザーと機能に関する音声アナウンスやプロンプトの言語を選択します。
  • メール言語—新規ユーザーとのメール通信に使用する言語を選択します。
  • タイムゾーン—ロケーションのタイムゾーンを選択します。
3

[保存 ] をクリックしてから、[ はい/いいえ ] を選択して、現在または後でロケーションに番号を追加します。

4

[はい] をクリック した場合、次のいずれかのオプションを選択します。

  • Cisco PSTN—Cisco から Cloud PSTN ソリューションが必要な場合は、このオプションを選択します。Cisco 通話プランは、緊急通話、着信、および国内および国際通話を提供する PSTN 代替ソリューションであり、新しい PSTN 番号または既存の番号を Cisco にポートすることができます。

    Cisco PSTN オプションは、以下の条件でのみ表示されます。

    • コミットされた Cisco Calling プラン OCP (アウトバウンド通話プラン) を少なくとも 1 つ購入している。

    • Cisco Calling プランがサポートされている国にロケーションがある。

    • ロケーションが新規である。他の PSTN 機能が割り当てられている既存のロケーションは、今回は Cisco Calling プランの対象外です。サポートケースを登録 してガイダンスを受けてください。

    • Cisco Calling プランがサポートされている地域の Webex Calling データ センターでホストされています。

  • Cloud Connected PSTN—多くの Cisco CCP パートナーの 1 つからクラウド PSTN ソリューションを探している場合、またはロケーションで Cisco Calling プランが利用できない場合は、このオプションを選択します。CCP パートナーは、PSTN 代替ソリューション、グローバルな広域カバレッジ、広範でさまざまな機能、パッケージ、価格設定を提供しています。

    CCP パートナーと対応地域は、こちらにリストされています。ロケーションの国がサポートされているパートナーにのみ表示されています。パートナーは、ロゴで表示されるか、簡単な文字列と括弧で囲んだ地域名で表示されます (例: (EU)、(US)、または (CA))。ロゴが表示されているパートナーは、常に CCP の地域メディアを提供しています。文字列で表示されているパートナーについては、CCP の地域メディアを確保するために、ロケーションの国に最も近い地域を選択してください。

    リストされているプロバイダーの下に [番号を今すぐ注文する] オプションがある場合は、そのオプションを選択して、統合された CCP のメリットを利用することをおすすめします。統合された CCP の場合、電話番号の調達とプロビジョニングを Control Hub の 1 つのペインで行えます。統合されていない CCP の場合、Control Hub の外で、CCP パートナーから電話番号を調達する必要があります。

  • プレミスベースの PSTN (ローカル ゲートウェイ): 現在の PSTN プロバイダーを保持する場合、またはクラウド サイトで非クラウド サイトに接続する場合に、このオプションを選択できます。

PSTN オプションの選択は各ロケーション レベルで行います (各ロケーションには PSTN オプションが 1 つしかありません)。展開に対して必要な数のオプションを組み合わせることができますが、各ロケーションには 1 つのオプションとなります。PSTN オプションを選択してプロビジョニングしたら、ロケーションの PSTN プロパティで [管理] をクリックすると、オプションを変更できます。ただし、Cisco PSTN などの一部のオプションは、別のオプションが割り当てられた後は使用できない場合があります。サポートケースを登録 してガイダンスを受けてください。

5

番号を今すぐに有効にするか、または後で有効にするかを選択します。

6

統合されていない CCP またはプレミス ベースの PSTN を選択した場合は、電話番号をコンマ区切り値として入力し、[検証] をクリックします。

特定のロケーションのための番号が追加されます。有効なエントリは [検証済みの番号] フィールドに移動し、無効なエントリは [番号の追加] フィールドに残り、エラー メッセージが表示されます。

番号の書式は、ロケーションの所在する国に応じ、ダイヤリングに関する地元の要件に従って定められます。たとえば、国コードが必要な場合には、コードを付けて入力することも、コードなしで入力してからコードが自動的に先頭に追加されるようにすることもできます。

7

[保存] をクリックします。

次に行うこと

ロケーションを作成した後、そのロケーションの緊急 911 サービスを有効にすることができます。詳細については「Webex Calling の RedSky 緊急 911 サービス」を参照してください。

ロケーションを削除

開始する前に

関連付けられているユーザーとワークスペースを削除すると、使用されていない場所または正しく設定されていない場所を削除できます。ロケーションを削除すると、割り当てられたサービスと番号がすべて削除されます。

ロケーションに関連付けられているユーザーとワークスペースのリストを取得します。[サービス] > [Calling] > [番号] に進み、ドロップダウン メニューから削除するロケーションを選択します。ロケーションを削除する前に、これらのユーザーとワークスペースを削除する必要があります。

このロケーションに関連付けられている番号は、PSTN プロバイダーに解放されることに注意してください。これらの番号は所有されなくなります。

1

https://admin.webex.com で Control Hub にログインし、[管理] > [ロケーション] に移動します。

2

削除するロケーションの隣の [その他のオプション] ボタン [アクション] 列で をクリックします。

3

[場所 の削除] を選択し、その場所を削除します。

通常、ロケーションを完全に削除するには数分かかりますが、最大で 1 時間かかる場合があります。ステータスを確認するには、ロケーション名の隣にある [その他のオプション] ボタン をクリックして、[削除ステータス] を 選択します。

既存のロケーションを更新する

作成した後PSTNのセットアップ、名前、タイムゾーン、言語を変更できます。新しい言語は新しいユーザーとデバイスにのみ適用されることに注意してください。既存のユーザーおよびデバイスは古い言語を使用し続けます。

既存のロケーションについては、緊急時の 911 サービスを有効にすることができます。詳細については「Webex Calling の RedSky 緊急 911 サービス」を参照してください。

1

Control Hub にサインインします。

2

[管理] > [ロケーション] に移動します。

ロケーションの隣に [警告] 記号が表示される場合、そのロケーションの電話番号をまだ設定していないという意味です。その番号を設定するまで、通話の送受信が行えなんす。

3

(オプション) [PSTN 接続] の下で、すでに設定されているものに応じて、[クラウド接続 PSTN] または [プレミスベースの PSTN](ローカル ゲートウェイ) のいずれかを選択します。[管理] をクリックして設定を変更してから、[続行] を選択することにより、関連するリスクを承認します。以下のオプションのいずれかを選択して、[保存] クリックします。

  • Cisco PSTN—Cisco から Cloud PSTN ソリューションが必要な場合は、このオプションを選択します。Cisco 通話プランは、緊急通話、着信、および国内および国際通話を提供する PSTN 代替ソリューションであり、新しい PSTN 番号または既存の番号を Cisco にポートすることができます。

    Cisco PSTN オプションは、以下の条件でのみ表示されます。

    • コミットされた Cisco Calling プラン OCP (アウトバウンド通話プラン) を少なくとも 1 つ購入しました。

    • Cisco Calling プランがサポートされている国にロケーションがある。

    • Cisco Calling プランがサポートされている地域の Webex Calling データ センターでホストされています。

  • Cloud Connected PSTN—多くの Cisco CCP パートナーの 1 つからクラウド PSTN ソリューションを探している場合、またはロケーションで Cisco Calling プランが利用できない場合は、このオプションを選択します。CCP パートナーは、PSTN 代替ソリューション、グローバルな広域カバレッジ、広範でさまざまな機能、パッケージ、価格設定を提供しています。

    CCP パートナーと対応地域は、こちらにリストされています。ロケーションの国がサポートされているパートナーにのみ表示されています。パートナーは、ロゴで表示されるか、簡単な文字列と括弧で囲んだ地域名で表示されます (例(EU)、(米国)、または (CA)。ロゴが表示されているパートナーは、常に CCP の地域メディアを提供しています。文字列で表示されているパートナーについては、CCP の地域メディアを確保するために、ロケーションの国に最も近い地域を選択してください。

    リストされているプロバイダーに今すぐ番号を注文 するオプションが表示されている場合は、統合型 CCP を利用できるように、そのオプションを選択することをお勧めします。統合型 CCP を使用すると、Control Hub で電話番号のプロビジョニングとプロビジョニングを 1 つのペインで実行できます。統合されていない CCP では、Control Hub の外部で CCP パートナーから電話番号を取得する必要があります。

  • プレミスベースの PSTN (ローカル ゲートウェイ): 現在の PSTN プロバイダーを保持する場合、またはクラウド サイトで非クラウド サイトに接続する場合に、このオプションを選択できます。

    Webex Calling ゲートウェイで以前に設定されたロケーションを持つ顧客は、対応するトランクを使用してオンプレミス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

Control Hub にサインインします。

2

[管理] > [ロケーション] に移動します。

3

PSTN 接続を Cisco PSTN に変更するロケーションを選択します。

4

[Calling] タブに移動し、プレミスベースの PSTN または非統合型 PSTN の隣の [管理] オプションをクリックします。

5

[接続タイプ] の隣の [編集] を選択します。

6

Cisco Calling プラン カードを選択し、このロケーションのユーザーに Cisco Calling プランを割り当てるサブスクリプションを選択します。[次へ] をクリックします。

7

確認のための接続変更ページが表示されます。[次へ] をクリックして、番号のポート準備を確認します。

PSTN 接続ポート ウィザードは、番号をポートする準備ができているかどうかを確認します。

[次へ（Next）] ボタンは、リスト内のすべての番号がポート可能な場合にのみ有効になります。これらのポインタを読みます。

  • 「ポートできない番号」は非アクティブな番号を指します。このリストに番号がないことを確認してください。

  • ロケーションからポートできない番号を削除します。番号を移動または割り当て解除して、番号を削除できます。

8

[次へ] をクリックし、契約情報を入力します。

PSTN 接続ポート ウィザードの緊急サービス アドレス ページ。

これは、Cisco Calling プラン (米国) を使用するすべてのロケーションの主契約連絡先です。この連絡先への変更は、Cisco Calling プラン (米国) を使用する他のすべてのロケーションに適用されます。

9

[次へ] をクリックします。そのロケーションの契約情報を保存するための確認を求める通知が表示されます。[はい、変更します。] を選択します。

10

緊急連絡サービス アドレスを入力し、[保存] をクリックします。

PSTN 接続ポート ウィザードの緊急サービス アドレス ページ。

緊急時、現地の緊急対応チームはこのアドレスを利用して発信元を見つけます。

11

概要ページには、作成されたポートの数が表示されます。注文が 1 つしかない場合、[追加情報を提供] と呼ばれる追加手順を確認できます。複数の注文の場合、上部に注文セレクタが表示され、その間を移動できます。[次へ] をクリックし、詳細を入力してポート ウィザードを完了します。

PSTN 接続ポート ウィザードの概要ページ。

注文は、単一の PSTN 移行リクエストに対してすべての情報が提供されると同時に送信されます。デフォルトでは、すべての注文で確固たる注文コミットメントの日付が一致しています。最後にリンクされた注文が完全にポートされた後、PSTN 接続の変更が自動的に適用されます。

  • 注文の送信に失敗すると、サポート チケットが自動的に作成され、サポート チームに送信されます。

  • PSTN 接続の変更が複数の通信事業者からの複数の注文を必要とする場合、完了までに最大 10 営業日かかる場合があります。

移行の詳細は、[サービス] > [Calling] > [PSTN] > [注文] タブで利用できます。注文 ID を選択すると、サイドパネルビューで注文の詳細が表示されます。PSTN 接続変更から作成された注文では、タイプを [PSTN の変更] として確認できます。

PSTN 接続の変更をキャンセル

管理者は、ロケーションがまだ移行状態の場合、PSTN 移行をキャンセルできます。

1

Control Hub にサインインします。

2

[管理] > [ロケーション] に移動します。

3

PSTN 接続をキャンセルするロケーションを選択します。

4

[Calling] タブに移動し、[PSTN 接続変更をキャンセル] ボタンをクリックします。

5

[はい、続行 ] をクリックしてキャンセルを確認します。

Webex Calling ダイヤル プランを設定

アウトバウンド ダイヤル コードダイヤル プラン使用してWebex Callingシステムの設定をコントロールできます。内線の長さ、ルーティング プレフィックス、およびダイヤル設定 (内部と外部) が、ユーザーのダイヤル習慣に適合するようにカスタマイズします。

これらの設定は社内ダイヤルに適用されるものであり、最初のセットアップ ウィザードでも設定できます。ダイヤル プランを変更すると、Control Hub の更新にあるサンプルの番号が更新され、これらの変更が表示されます。

ロケーションの発信通話権限を設定できます。発信権限を設定するには、これらの手順 を参照してください。

1

Control Hub にサインインし、[サービス] > [Calling] > [サービス設定] に移動し、[内線ダイヤル] までスクロールします。

2

必要に応じて、次のオプションのダイヤル設定を行います。

  • ロケーション ルーティング プレフィックスの長さ—複数のロケーションがある場合は、この設定をお勧めします。1 ～ 7 桁の長さを入力できます。同じ内線を持つ複数のロケーションがある場合は、ロケーション間の通話時にプレフィックスをダイヤルする必要があります。たとえば、複数のストアがある場合、内線 1000 を使用すると、各ストアにルーティング プレフィックスを設定することができます。1 つのストアのプレフィックスが 888 の場合、そのストアに到達するために 8881000 にダイヤルします。

    • ルーティング プレフィックスの長には、ステアリング桁が含まれます。たとえば、ルーティング プレフィックスの長さを 4 に設定した場合、サイトを指定できるのは 3 桁のみです。

    • ルーティング プレフィックスをロケーションに割り当てると、そのロケーションに割り当てられた内線番号のすべてのアピアランスには、内線番号の前にルーティング プレフィックスが含まれます。たとえば、888-1000（ルーティング プレフィックス内線）などです。

  • ルーティング プレフィックスのステアリング桁—各ルーティング プレフィックスの最初の桁として設定する番号を選択します。
  • 内線番号の長さ—2 ～ 10 桁を入力でき、デフォルトは 2 です。

    内線の長さを増やしても、社内内線への既存のスピード ダイヤルは自動的に更新されません。

  • ロケーション間の内線ダイヤルを許可: 組織の要件に基づいて、ロケーション間の内線ダイヤルをカスタマイズできます。

    • 組織のすべてのロケーションで重複する内線番号がない場合は、トグルを有効にします。

      デフォルトでは、トグルが有効になっています。

    • 組織が異なるロケーションで同じ内線を持っている場合は、トグルを無効にします。トグルが無効になって発信者が内線番号をダイヤルすると、発信者と同じロケーションに一致する内線番号を持つユーザーにコールがルーティングされます。他のロケーションの内線番号に到達するには、発信者はエンタープライズ有意番号 (ロケーションのルーティングプレフィックス + 内線) をダイヤルする必要があります。

3

特定の場所の内部ダイヤルを指定します。[管理] > [ロケーション] に移動し、リストからロケーションを選択し、[通話] をクリックします。[ダイヤル] までスクロールし、必要に応じて内部ダイヤルを変更します。

  • 内線ダイヤル: あるロケーションのユーザーが別のロケーションの誰かに連絡するためにダイヤルする必要があるルーティング プレフィックスを指定します。各ロケーションのルーティング プレフィックスは固有である必要があります。プレフィックスの長さは組織レベルで設定された長さと一致することを推奨しますが、1 ～ 7 桁の長さである必要があります。
4

特定のロケーションの外線ダイヤルを指定します。[管理] > [ロケーション] に移動し、リストからロケーションを選択し、[通話] をクリックします。[ダイヤル] までスクロールし、必要に応じて外部ダイヤルを変更します。

  • 外線ダイヤル: ユーザーが外線に接続するためにダイヤルする必要がある発信ダイヤル番号を選択できます。デフォルトは [なし] であり、このダイヤル習慣が必要ない場合には、値を [なし] にしておくことができます。この機能を使用しない場合、組織のステアリング番号とは別の番号を使用することをお勧めします。

    ユーザーは、外線発信を行う際に外線発信番号を含め、レガシー システムでダイヤルしていた方法を真似たものにできます。しかし、すべてのユーザーは、発信ダイアル番号なしで外部通話を発信することができます。

  • オプションで、このロケーションの発信ダイヤル番号を強制する ことができます。これにより、ユーザーが外部コールを発信するために管理者が設定した発信ダイヤル番号を使用する必要があります。

    • この機能を有効にすると、発信ダイヤル番号の有無にかかわらず緊急コールをダイヤルできます。有効にすると、外線発信番号が含まれない外線番号 (通話転送に使用される番号など) が機能しなくなります。

    • 内線が国番号と同じ場合、内線が国番号よりも優先されます。したがって、発信ダイヤル番号を有効にすることを推奨します。

    • 着信および発信 PSTN 通話に E.164 番号形式を使用することを強くおすすめします。

ユーザーへの影響:

  • ダイヤル設定の変更を有効にするには、ユーザが電話を再起動する必要があります。

  • ユーザーの内線番号は、ロケーションのステアリング番号または発信ダイヤル番号と同じ番号で開始することはできません。

Control Hub でプレミス ベースの PSTN (ローカル ゲートウェイ) を設定する

付加価値再販業者の場合、これらの手順を使用して Control Hub でローカル ゲートウェイの設定を開始できます。このゲートウェイがクラウドに登録されると、Webex Calling の 1 つ以上のロケーションで使用して、エンタープライズ PSTN サービス プロバイダーへのルーティングを提供できます。

ローカル ゲートウェイがある場所は、ローカル ゲートウェイが他の場所で使用されているときには削除できません。

トランクを作成する

次の手順に従って、Control Hub でトランクを作成します。

始める前に

  • ロケーションが追加されたら、ロケーションに対してプレミスベース PSTN を設定する前に、トランクを作成する必要があります。

  • それぞれについて、ロケーションと固有の設定および番号を作成します。ロケーションはプレミスベース PSTN を追加する前に存在する必要があります。

  • Webex Calling でのプレミスベース PSTN (ローカル ゲートウェイ) 要件について理解しておいてください。

  • プレミスベース PSTN を持つロケーションに対して、複数のトランクを選択できませんが、複数のロケーションに対して同じトランクを選択することはできます。

1

https://admin.webex.com で Control Hub にログインし、[サービス] > [Calling] > [コール ルーティング] に移動し、[トランクの追加] を選択します。

2

ロケーションを選択します。

3

トランクの名前を指定し、[保存] をクリックします。

名前は 24 文字以内にしてください。

次にやる必要

トランクで設定する必要がある、関連するパラメーターが表示されます。また、PSTN 接続をセキュアにするための SIP ダイジェスト資格情報のセットも生成します。

画面 [ドメインの登録]、[トランク グループ 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 トランク セキュリティ プロファイルを作成します。

設定値
名前固有の名前 (Webex など)
説明Webex SIP トランク セキュリティ プロファイルなどの意味のある説明
着信ポートWebex 間のトラフィックでは、ローカル ゲートウェイ構成で使用されるポートと一致する必要があります。5065

ローカル ゲートウェイ トランクの SIP プロファイルを構成する

次の設定でローカル ゲートウェイ トランク用の専用の SIP プロファイルを作成します。

設定値
名前固有の名前 (Webex など)
説明Webex SIP プロファイルなどの意味のある説明
オプションの Ping を有効にして、サービス タイプ「なし (デフォルト)」のトランクの宛先ステータスをモニタします。選択

Webex からのコールのコール検索スペースを作成する

次の設定で Webex から発信されたコールのためのコール検索スペースを作成します。

設定値
名前固有の名前 (Webex など)
説明Webex Calling 検索スペースなどの意味のある説明
選択済みパーティション:

DN (+E.164 ディレクトリ番号)

ESN (サイト間ダイヤル)

PSTNInternational (PSTN アクセス)

onNetRemote (GDPR 学習先)

最後のパーティション onNetRemote は、Intercluster Lookup Service (ILS) または Global Dialplan Replication (GDPR) を使用して、Unified CM クラスター間でルーティング情報が交換されるマルチクラスター環境でのみ使用されます。

Webex 間で SIP トランクを構成する

次の設定を使用して、ローカル ゲートウェイ経由での Webex 間のコールに SIP トランクを作成します。

設定値
デバイス情報
DeviceName一意の名前 (Webex など)
説明Webex SIP トランクなどの意味のある説明
すべてのアクティブな Unified CM ノード上で実行する選択
着信コール
コール検索スペース以前に定義されたコール検索スペース:Webex
AAR コール検索スペース PSTN ルート パターンへのアクセス権のみを持つコール検索スペース: PSTNReroute
SIP 情報
接続先アドレスローカル ゲートウェイ CUBE の IP アドレス
移動先ポート5060
SIP トランク セキュリティ プロファイル定義済み:Webex
SIP プロファイル定義済み:Webex

Webex のルート グループを構成する

次の設定でルート グループを作成します。

設定値
ルート グループ情報
ルート グループ名一意の名前 (Webex など)
選択したデバイス以前に構成された SIP トランク:Webex

Webex のルート リストを構成する

次の設定でルート リストを作成します。

設定値
ルート リスト情報
名前固有の名前 (RL_Webex など)
説明Webex のルート リストなど、意味のある説明
すべてのアクティブな Unified CM ノード上で実行する選択
ルート リスト メンバー情報
選択したグループ以前に定義されたルート グループのみ:Webex

Webex の移動先のパーティションを作成する

次の設定で Webex の移動先のパーティションを作成します。

設定値
ルート リスト情報
名前一意の名前 (Webex など)
説明Webex パーティションなどの意味のある説明

次にやる必要

このパーティションは、Webex の宛先にアクセスする必要があるすべてのコール検索スペースに追加してください。このパーティションは、PSTN から Webex への発信がルーティングされるように、PSTN トランクの着信コール検索スペースとして使用されるコール検索スペースに特に追加する必要があります。

Webex の移動先のルート パターンを構成する

次の設定で Webex の各 DID 範囲のルート パターンを構成します。

設定値
ルートパターン「\」が頭文字にある Webex で DID 範囲のフル +E.164 パターン例: \+140855501XX
ルート パーティションWebex
ゲートウェイ/ルート リストRL_ Webex
緊急の優先事項選択

Webex の簡略サイト間ダイヤル正規化を構成する

短縮されたサイト間ダイヤルが Webex に必要な場合は、Webex の各 ESB 範囲にダイヤル正規化パターンを設定します。

設定値
翻訳パターンWebex の ESN 範囲の ESB パターン。例:80121XX
パーティションWebex
説明Webex 正規化パターンなどの意味のある説明
発信者のコール検索スペースを使用する選択
緊急の優先事項選択
後続ホップでの連続桁のタイムアウトを待たない選択
着信側トランスフォーム マスク番号を + E.164 に正規化するマスク。例: +140855501XX

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

Control Hub にサインインします。

2

[管理] > [ユーザー] に移動します。

3

ユーザーを選択し、[Calling] をクリックします。

4

[ユーザー間権限] セクションに移動し、[割り込み] を選択します。

5

トグルをオンにすると、他のユーザーがこのユーザーの進行中のコールに自分自身を追加できるようになります。

6

このユーザーが通話に割り込みを行ったときに他の人にトーンを再生する場合は、[このユーザーが通話に割り込みを行ったときにトーンを再生する] をオンにします。

[このユーザーが通話に割り込みを行ったときにトーンを再生する] 設定は、Customer Experience Basic および Essentials スーパーバイザーの割り込み機能には適用されません。スーパーバイザに対してこのオプションを有効にした場合でも、スーパーバイザがコール キュー コールに割り込んだときに、システムはエージェントに通知トーンを再生しません。

スーパーバイザがコールに割り込んだときにエージェントにトーンを再生する場合は、[エージェントの通知トーン] 設定で有効にできます。詳細については、「Webex Customer Experience Basic 」または「Webex Customer Experience Essentials 」の「キューの作成」セクションを参照してください。

7

[保存] をクリックします。

ユーザーのプライバシーを有効化

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）] フィールドに入力された名前です。

実際の例を見てみましょう。このビデオ デモンストレーション で、Control Hub のユーザーの監視設定を管理する方法をご覧ください。

ユーザーのコール ブリッジ警告トーンを有効化

開始する前に

コール ブリッジを呼び出すには、共有回線を設定する必要があります。コール ブリッジ警告トーンを再生する前に、共有回線を設定する 方法を参照してください。
1

Control Hub にサインインし、[管理] > [ユーザー] に移動します。

2

ユーザーを選択し、[通話] タブをクリックします。

3

[ユーザー間権限] に移動し、[コール ブリッジング警告音] をクリックします。

4

[コール ブリッジング警告音] をオンにして、[保存] をクリックします。

デフォルトでは、この機能は有効になっています。

MPP 共有回線のコール ブリッジングの詳細については、「マルチプラットフォーム 卓上電話の共有回線」を参照してください。

Webex アプリの共有回線でのコール ブリッジングの詳細については、「WebexApp の共有回線アピアランス」を参照してください。

ユーザーのためにホテリングをオンにする

ユーザのホテリングを有効にすると、メインの卓上電話の機能と機能を維持しながら、ホストの電話を使用できます。

1

Control Hub にサインインします。

2

[管理] > [ユーザー] に移動します。

3

ユーザーを選択し、[通話] タブをクリックします。

4

[ユーザー間権限] セクションに進み、[ホテリング] を選択し、トグルをオンにします。

5

[ホテリング ロケーション] 検索フィールドにホテリング ホストの名前または番号を入力し、ユーザーに割り当てるホテリング ホストを選択します。

ホテリングホストは 1 つのみ選択できます。別のホテリング ホストを選択した場合、最初のホストは削除されます。

ロケーション管理者の場合、割り当てられたロケーションに関連するホテリング ホストのみを割り当てることができます。

6

[関連付け期間の制限] ドロップダウンから、ユーザーがホテリング ホストを使用できる時間数を選択します。

電話機は、選択した時間後に自動的にユーザをログアウトします。

ユーザに指定された制限関連付け期間が、選択したホテリング ホストの制限関連付け期間を超えた場合、画面にエラーメッセージが表示されます。たとえば、ホテリング ホストの関連付け期間が 12 時間で、ユーザーの関連付け期間が 24 時間である場合、エラーメッセージが表示されます。このような場合、ユーザーがもっと時間が必要な場合は、ホテリング ホストの制限時間を延長する必要があります。

7

[保存] をクリックします。

ユーザーは、User Hub から使用するホテリング ホストを検索して検索することもできます。詳細については、「どこからでも通話プロファイルにアクセスする」を参照してください。

実際の例を見てみましょう。このビデオ デモンストレーション で、Control Hub でホテリングを設定する方法をご覧ください。

Webex Calling の導入傾向と使用レポート

通話レポートを表示

Control Hub の [アナリティクス] ページを使用して、Webex Calling サービスの使用方法、Webex アプリでのエンゲージメント、通話メディア エクスペリエンスの品質を確認できます。Webex Calling 分析にアクセスするには:

1

Control Hub にサインインします。

2

[分析] に移動し、[Calling] タブを選択します。

3

[詳細な通話履歴] を選択します。

通話履歴の詳細は、メディア品質データとともに表示されます。
4

メディア品質データにアクセスするには、Control Hub にサインインし、[アナリティクス] に移動し、[Calling] を選択します。

関連情報
この投稿記事は役に立ちましたか？
この投稿記事は役に立ちましたか？
価格Webex アプリMeetingsCallingメッセージング画面共有
Webex スイートCallingMeetingsメッセージングSlidoウェビナーEventsContact CenterCPaaSセキュリティControl Hub
ヘッドセットカメラDesk シリーズRoom シリーズBoard シリーズPhone シリーズアクセサリ
教育ヘルスケア行政財務スポーツとエンターテインメントフロントライン非営利スタートアップハイブリッド ワーク
ダウンロードテストミーティングに参加オンラインクラスインテグレーションアクセシビリティインクルージョンライブ & オンデマンド ウェビナーWebex CommunityWebex Developersニュース & イノベーション
Ciscoサポートへお問い合わせセールスに問い合わせWebex BlogWebex ソート リーダーシップWebex Merch Storeキャリア
  • X
  • LinkedIn
  • Facebook
  • Youtube
  • Instagram
利用規約プライバシーステートメントクッキー商標
©2026 Cisco and/or its affiliates. All rights reserved.
利用規約プライバシーステートメントクッキー商標