Webex Calling 設定ワークフロー
Webex Calling 設定ワークフロー
2022年9月30日
Webex Calling の概要

Webex Calling の紹介

エンタープライズグレードのクラウド通話、モバイル性、PBX 機能をメッセージングとミーティングのための Webex アプリと共に使用し、Webex Calling ソフト クライアントまたは Cisco デバイスからの通話が可能な想像してください。 これこそが、Webex Calling がユーザーへ提供する機能です。

Webex Calling には次の利点があります。

  • テレフォニー ユーザーのための通話サブスクリプションと共有領域

  • すべてのユーザーの Webex アプリへのアクセス

  • パブリック スイッチ テレフォニー ネットワーク (PSTN) アクセスにより、ユーザーは組織の外にも電話をかけられます。 サービスは、既存のエンタープライズ インフラストラクチャ (オンプレミス IP PBX なしのローカル ゲートウェイ、または既存の Unified CM 通話環境を含む) またはパートナーまたは Cisco が提供する PSTN オプションを通じて提供されます。

Webex Calling は次の機能をサポートしています。 詳細については、「Webex Calling の機能を構成する」の章を参照してください。

表 1. 管理可能な機能

機能

説明

自動音声応答

セットアップ メニューと、応答サービス、ハント グループ、ボイスメール ボックスや実際のオペレーターなどへのルーティング機能によって、適切なあいさつを返すことができます。 24 時間分のスケジュールを作成できます。あるいは、時間内か外かに応じて、異なるオプションを使うこともできます。 コールは、発信者の ID 属性に応じてルーティングすることによって、VIP リストを作成したり、特定の市外局番からの通話には対応を変えたりすることができます。

コール キュー

コール キューを作成すれば着信にすぐに応答できない場合でも、誰かが応答できるようになるまで自動応答にしたり、お詫びのメッセージや保留中の音楽を発信者に伝えるようにしたりすることができます。

コールピックアップ

コール ピックアップ グループを作成し、グループのユーザーがお互いの通話に応答できるようにすることによって、社内でのチームワークと協力体制を強化できます。 ユーザーをコールピックアップグループに追加しておけば、グループメンバーが席を離れていたり、電話中だったりした場合、別のメンバーが電話に出ることができます。

コール パーク

コール パークをオンにすると、ユーザーはコールを保留にし、別の電話からそれを再開できます。

ハントグループ

以下のようなシナリオでは、ハント グループをセットアップするのがよいでしょう。

  • セールス チームは順番に転送を求めている可能性があります。 着信が電話を鳴らしても応答がなかった場合、そのコールはリスト中の次のエージェントへと転送されます。

  • サポートチームは最初の対応可能なエージェントが電話に応答できるように、電話が同時に鳴ることを希望する傾向があります。

ページング グループ

ユーザーが音声メッセージを個人、部署、チームに送信できるように、ページング グループを作成できます。 誰かがメッセージをページング グループに送信すると、グループのすべてのデバイスでメッセージが再生されます。

レセプショニスト クライアント

フルセットの通話管理オプション、大規模モニタリング、コール キュー、複数のディレクトリ オプションとビュー、Outlook との統合などを提供することにより、フロントオフィス担当者のニーズを満たします。

ユーザーは、https://settings.webex.comCalling ユーザー ポータルに相互起動するで、次の機能を設定できます。

表 2. ユーザーが構成可能な機能

機能

説明

匿名コールの拒否

ユーザーはブロックされた発信者 ID を使用して着信を拒否することができます。

ビジネスの継続性

ユーザーの電話が何らかの理由でネットワークに接続されていない場合 (停電、ネットワーク問題など)、ユーザーは着信コールを特定の電話番号に転送することができます。

コール転送

ユーザーは着信コールを別の電話に転送することができます。

選択的コール転送

ユーザーは特定の発信者、特定の時間のコールを転送することができます。 この設定はコール転送より優先されます。

コール通知

ユーザーは、電話番号や日時など、事前に定義された条件に従ってコールを受信したときに自分自身にメールが送られるよう設定することができます。

着信待ち受け

ユーザーは追加の着信に応答することができます。

応答不可

ユーザーは一時的にすべてのコールをボイスメールに直接移動させることができます。

Office Anywhere

ユーザーは選択された電話 (「ロケーション」) を、会社の電話番号とダイヤルプランの内線として使用することができます。

優先アラート

ユーザーは電話番号や日時など、事前に定義された条件が満たされたときに、特別な着信音が鳴るように設定することができます。

リモート オフィス

ユーザーはリモートの電話からコールを発信し、ビジネス回線からのものとして表示させることができます。 さらに、ビジネス回線への着信があると、このリモートの電話が鳴ります。

選択通話承諾

ユーザーは特定の発信者、特定の時間のコールを承認することができます。

匿名通話の拒否

ユーザーは特定の発信者、特定の時間のコールを拒否することができます。

シーケンシャル リング

着信があると、最大で 5 台のデバイスを 1 つずつ鳴らすことができます。

同時リング

着信があると、ユーザーの番号の電話と、別の番号の電話 (「コールの受信者」) 番号が同時に鳴ります。

Control Hub でのサービス、デバイス、およびユーザーのプロビジョニング、Calling 管理ポータルの詳細設定への相互起動

Control Hub () は注文と設定を簡素化するために Webex Callinghttps://admin.webex.com と統合され、バンドル オファー (Webex Calling 、Webex アプリ 、および Meetings) の管理を集中管理する管理ポータルです。

Control Hub は、すべてのサービス、デバイス、およびユーザーをプロビジョニングするための中心点です。 コーリング サービスの初回セットアップ、MPP 電話のクラウドへの登録 (MAC アドレスを使用)、デバイスの関連付けや、電話番号、サービス、コール機能の追加などにより、ユーザーを構成することができます。 また、Control Hub からは、Calling 管理ポータルへのクロスローンチが可能です。

ユーザーエクスペリエンス

ユーザーは次のインターフェイスへのアクセスできます。

  • Webex Calling アプリケーション—Cisco ブランドの通話用ソフト クライアント。 詳細については、「新しい Cisco Webex Calling アプリを検索する」を参照してください。

  • Webex 設定 (https://settings.webex.com)—ユーザーがプロファイルの基本設定を行い、Webex アプリ をダウンロードし、通話設定のために通話ユーザー ポータルにクロス起動できる インターフェイス。 詳細については、「Cisco Webex の設定を変更する」を参照してください。

  • Webex アプリ—Cisco ブランドの Team メッセージング クライアントとしてのサブスクリプションに含まれるアプリケーション。 詳細については、「新しいアプリを 使い始めるCisco Webexしてください

  • Webex Meetings —ミーティング ソリューションとして追加されるオプションのアプリケーション。 詳細については、「Webex Meetings」を参照してください。

概要

Webex Calling は、重要なビジネス コミュニケーションをクラウドに移行できるようにすることで、運用コストを削減し、生産性を向上させることができます。 他の Webex アプリやデバイスと組み合わせると、完全なエンタープライズ クラウド通話とコラボレーション エクスペリエンスの中核となります。 Cisco は、オンプレミス、クラウド、および混合モデルの展開をサポートすることで、市場が混乱する状況のなかでも、どこからでも顧客の接続状態を保ち、その生産性を維持できます。

Webex Calling には、Cisco Unified Communications Manager アーキテクチャに基づく専用のクラウド インスタンス オプションが含まれるようになりました。 専用インスタンスは Webex Calling と統合され、Webex プラットフォームサービスを利用して、クラウドのイノベーションと強化されたエクスペリエンスを、古い Cisco エンドポイント、ローカルサバイバービリティソリューション、または重要なビジネスワークフローの一部の既存の統合をサポートする必要がある顧客に提供します。

Webex Calling の専用インスタンス アドオンには次が含まれます。

  • Cisco Unified Communications Manager

  • Cisco Unified IM & Presence

  • Cisco Unified Unity Connection

  • Cisco Expressway

  • Cisco Emergency Responder (アメリカ地域のみ)

  • Cisco Session Management Edition (SME) (オプション)

ROIの 拡大 – 専用インスタンスは、関連するUC Managerリリースと同じ音声およびビデオエンドポイントをサポートします。これは、クラウドに移行する際に、すべての顧客エンドポイントを更新し、これらの資産のROIを拡大する要件を排除します。

基本 Inter-Op – 専用インスタンスは、Webex プラットフォーム経由Webex Callingルーティングのための電話機能と統合されます。 顧客は、専用インスタンスと Webex Calling の両方にユーザーを配布し、クラウド通話のビジネス要件に必要に応じて時間を調整することができます。


プラットフォームでユーザーを分割する顧客には異なる機能があります。 通話機能は、専用インスタンスとユーザー グループの間で設定Webex Calling。 例えば、Webex Callingは専用インスタンス上でハント グループにすることはできません。

Control Hub を体験する

Control Hub は、組織の管理、ユーザーの管理、サービスの割り当て、導入の傾向や通話品質の分析などを行うための、ウェブ ベースの単一のインターフェイスです。

組織をセットアップして実行 するには、Control Hub にメール アドレスを入力して、Webex アプリ に参加する数人のユーザーを招待することを 推奨します。 コールを含む、提供されるサービスを使用するようにユーザーを促し、彼らの満足度に関するフィードバックを提供することを求めます。 準備が完了したら、いつでもユーザーを追加することができます。


Control Hub にアクセスするには最新の Google Chrome もしくは Mozilla Firefox のデスクトップ バージョンを使用されることを推奨します。 モバイル デバイスのブラウザーやその他のデスクトップ ブラウザーを使用した場合、予期せぬ結果が生じる場合があります。

以下に示す情報を、組織がサービスをセットアップし始めた場合に期待できる事柄についての、大まかな概要として用いてください。 詳細については、個々の章の、手順を追った説明を参照してください。

使い始める

パートナーがあなたのアカウントを作成すると、ウェルカム メールが届きます。 Chrome または Firefox を使用し、メールの [はじめに] リンクをクリックして、Control Hub にアクセスします。 このリンクを使うと、管理者のメール アドレスで自動的にサインインすることができます。 次に、管理者パスワードを作成するためのプロンプトが表示されます。

トライアルのための初回ウィザード

パートナーがトライアルに登録した場合、Control Hub にサインインすると、セットアップ ウィザードが自動的に開始します。 このウィザードでは、Webex Calling などのサービスで組織を立ち上げて稼働させるための基本設定を案内します。 ウィザードのガイドを終えると、Calling の設定とその確認が完了します。

設定の確認

Control Hub がロードされると、設定を確認できます。

ユーザーの追加

サービスをセットアップしたら、会社ディレクトリからユーザーを追加する準備ができます。 [ユーザー] に進んで、[ユーザーの管理] をクリックします。

Microsoft Active Directory を使用している場合、まずディレクトリ同期を有効にしてからユーザーの追加方法を決定することをお勧めします。 [次へ] をクリックし、指示に従って Cisco Directory Connector を設定します。

シングル サインオン (SSO) の設定

Webex アプリは基本 認証を使用します。 SSO をセットアップすれば、ユーザーが、Webex で保存され、管理される別個のパスワードではなく、エンタープライズの証明書を使用してエンタープライズ ID プロバイダーで認証できるようにすることができます。

[設定] に移動し、[認証] までスクロールして、[変更] をクリックしてから、[サードパーティの ID プロバイダを統合させる] を選択します。

サービスをユーザーに割り当てる

ユーザーが Webex アプリの使用を開始するために、追加したユーザーにサービス を割り当てる必要があります

[ユーザー] に移動して、[ユーザーの管理] をクリックし、[CSV ファイルでユーザーをエクスポートおよびインポートする] を選択してから、[エクスポート] をクリックします。

ダウンロードしたファイルで、各ユーザーに割り当てるサービスに [True] を追加します。

完了したファイルをインポートし、[サービスの追加および削除] をクリックして、[提出] をクリックします。 これで、コール機能を構成し、共通場所で共有できるデバイスを登録し、デバイスを登録してユーザーに関連付ける準備ができました。

ユーザーを支援する

これで、ユーザーを追加し、サービスを割り当て済みです。メッセージングとミーティングのために、Webex Calling および Webex アプリでサポートされているマルチプラットフォーム電話 (MPP ) の使用を開始できます。 ユーザーに、アクセスのためのワンストップショップとしてCisco Webex の設定 を使用するように促してください。

ローカル ゲートウェイの役割

ローカル ゲートウェイは、エンタープライズまたはパートナーにより管理されているエッジ デバイスです。これは、パブリックスイッチのテレフォニー ネットワーク (PSTN) の相互動作と従来型のプライベート ブランチ エクスチェンジ (PBX) との動作のためのものです (Unified CM を含む)。

ローカル ゲートウェイをロケーションに割り当てるには Control Hub を使用します。その後、CUBE で設定できるパラメーターが Control Hub により提供されます。 これらの手順により、ローカル ゲートウェイがクラウドに登録され、ゲートウェイを通じて PSTN サービスが特定のロケーションの Webex Calling ユーザーに提供されます。

ローカル ゲートウェイを指定して注文するには、「ローカルゲートウェイの注文ガイド」を参照してください。

Webex Calling 向けにサポートされているローカル ゲートウェイの展開

次の基本的な展開がサポートされています。

ローカル ゲートウェイは、Cisco Unified Communications Manager へのインテグレーションが必要な場合、スタンドアロンまたは導入で展開することができます。

オンプレミスの IP PBX なしのローカル ゲートウェイ展開

スタンドアロンのローカル ゲートウェイ展開

この図は既存の IP PBX がない場合の Webex Calling の展開を示しており、単一のロケーションまたは複数のロケーションの展開に適用できます。

Webex Calling の宛先に一致しないすべてのコールについては、Webex Calling は処理のためにロケーションに割り当てられているローカル ゲートウェイにそれらのコールを送信します。 ローカル ゲートウェイは、Webex Calling から PSTN に送られるすべてのコールと、反対方向に PSTN から Webex Calling に送られるコールのルーティングを行います。

PSTN ゲートウェイは、ローカル ゲートウェイの専用プラットフォームまたは共存プラットフォームになります。 次の図のように、この展開の専用の PSTN ゲートウェイのバリエーションをお勧めします。既存の PSTN ゲートウェイを Webex Calling のローカル ゲートウェイとして使用できない場合に使用できます。

共存型のローカル ゲートウェイの展開

ローカル ゲートウェイとして、ITSP に接続するために SIP トランクを使用する IP ベースのもの、または ISDN またはアナログ回路を使用する TDM ベースのものを使用できます。 次の図は、ローカル ゲートウェイが PSTN GW/SBC と共存している場合の、Webex Calling の展開を示しています。

オンプレミスの Unified CM PBX なしでのローカル ゲートウェイ展開

Unified CM とのインテグレーションは、以下の場合に必要です。

  • Webex Calling 対応のロケーションを、Unified CM がオンプレミスのコール コントロール ソリューションとして展開されている場所で、既存の Cisco UC 展開に追加する場合。

  • Unified CM に登録された電話と Webex Calling ロケーションの電話との間で、直接ダイヤルが必要な場合。

この図は、顧客が既存の Unified CM IP PBX を持っている場所での、Webex Calling の展開を示しています。

Webex Callingの宛先に一致しない通話を ローカル Webex Calling に送信します。 これには、PSTNおよび Unified CM 内部内線番号Webex Calling含まれます。 ローカル ゲートウェイは、ユーザーから Unified CM へ、その逆Webex Calling、すべての通話をルーティングします。 Unified CM は、着信コールを、既存のダイヤル プランに従ってローカルの宛先または PSTN にルーティングします。 Unified CM のダイヤル プランは、番号を +E.164 として正規化します。 PSTN ゲートウェイには、専用のものと、ローカル ゲートウェイに共存しているものがあります。

専用の PSTN ゲートウェイ

この図に示されているように、この展開での専用 PSTN ゲートウェイのバリエーションは推奨オプションであり、既存の PSTN ゲートウェイを Webex Calling ローカル ゲートウェイとして使用できない場合に使用することができます。

共存型 PSTN ゲートウェイ

この図は、ローカル ゲートウェイが PSTN ゲートウェイ/SBC と共存している場合の、Webex Calling と Unified CM の展開を示しています。

Webex Callingの 宛先に一致 しないすべての通話を、ロケーションWebex Calling割り当てられたローカル ゲートウェイにルーティングします。 これには、PSTN の宛先と、Unified CM 内部の内線に向けたオンネット コールが含まれます。 ローカルゲートウェイは、すべてのコールを Unified CM にルーティングします。 その後、Unified CM は PSTN/SBC 機能が共存している ローカル ゲートウェイを通じて、コールをローカルに登録された電話または PSTN にルーティングします。

コール ルーティングの考慮点

Webex Calling から Unified CM へのコール

Webex Calling のルーティング ロジックは次のように動作します。 Webex Calling エンドポイントでダイヤルされた番号が Webex Calling の同じ顧客内の他の宛先にルーティングできない場合、通話はさらに処理するために、ローカル ゲートウェイに送信されます。 オフネット (外部) のWebex Callingは、ローカル ゲートウェイに送信されます。

既存の Unified CM に統合されていない Webex Calling 展開の場合、オフネットのコールは PSTN コールとして認識されます。 Unified CM との組み合わせでは、オフネット コールは、Unified CM でホストされている任意の宛先へのオンネット コール、または PSTN 宛先への実際のオフネット コールになり得ます。 後者の 2 つのコールの種類の違いは、Unified CM によって決まり、Unified CM でプロビジョニングされたエンタープライズ ダイヤル プランによって異なります。

次の図は、米国の国内番号にダイヤルする Webex Calling ユーザーを示しています。

Unified CM は、構成済みのダイヤルプランに基づいて、発信先が電話帳としてプロビジョニングされている、ローカルに登録されたエンドポイントにルーティングします。 このため、Unified CM のダイヤル プランは + E.164 番号のルーティングをサポートする必要があります。

Unified CM から Webex Calling へのコール

Unified CM から Webex Calling へのコール ルーティングを Unified CM で有効にするには、一連のルートをプロビジョニングして、Webex Calling で +E.164 とエンタープライズ番号プラン アドレスのセットを定義する必要があります。

これらのルートを構成することにより、次の図に示されているコール シナリオの両方が可能になります。

PSTN コールの発信者が Webex Calling デバイスに割り当てられた DID 番号を呼び出した場合、コールはエンタープライズの PSTN ゲートウェイを通じてエンタープライズに渡されてから、Unified CM にヒットします。 コールの呼び出し先アドレスは、Unified CM でプロビジョニングされた Webex Calling ルートの 1 つと一致し、コールはローカル ゲートウェイに送信されます (ローカル ゲートウェイに送信する場合、コールされたアドレスは +E.164 形式でなければなりません)。 ルーティング ロジックWebex Calling、 DID 割り当てに基づいて、通話が目的のデバイスWebex Calling送られたことを確認します。

また、Webex Calling の宛先をターゲットとする、Unified CM の登録済みエンドポイントから発信されるコールは、Unified CM でプロビジョニングされたダイヤルプランに従います。 通常、このダイヤルプランにより、ユーザーは一般的なエンタープライズダイヤルの習慣を使ってコールを発信することができます。 これらの習慣には、必ずしも +E.164 ダイヤルだけが含まれているわけではありません。 +E.164 以外のダイヤル習慣は、通話がローカル ゲートウェイに送信される前に +E.164 にノーマライズし、Webex Calling で正しいルーティングを許可する必要があります。

サービス クラス (CoS)

厳しいサービス クラスの制限を実装することは、コールのループの回避や特殊詐欺の防止など、さまざまな理由により常に推奨されます。 Webex Calling ローカル ゲートウェイを Unified CM のサービス クラスと統合するコンテキストでは、以下のサービス クラスについて検討する必要があります。

  • Unified CM に登録されているデバイス

  • PSTN からUnified CM に着信するコール

  • ユーザーから Unified CM に着信Webex Calling

Unified CM に登録されているデバイス

既存の CoS セットアップに新しい宛先のクラスとして Webex Calling の宛先を追加するのは非常に簡単です。 通常、Webex Calling の宛先へ発信する権限は、オンプレミス(サイト間を含む)の宛先へ発信する権限と同じです。

エンタープライズ ダイヤル プランがすでに「(省略形)オンネット サイト間」の権限を実装している場合、Unified CM でプロビジョニングされているパーティションはすでに存在しています。これは、同じパーティション内のすべての既知のオンネット Webex Calling の宛先を使用し、プロビジョニングすることができます。

そうでない場合、「(省略形)オンネット サイト間」権限の概念はまだ存在していません。新しいパーティション (たとえば「onNetRemote」) をプロビジョニングし、Webex Calling の宛先をこのパーティションに追加し、最後にこの新しいパーティションを適切なコール検索スペースに追加する必要があります。

PSTN からUnified CM に着信するコール

既存の CoS セットアップに新しい宛先のクラスとして Webex Calling の宛先を追加するのは非常に簡単です。 通常、Webex Calling の宛先へ発信する権限は、オンプレミス(サイト間を含む)の宛先へ発信する権限と同じです。

エンタープライズ ダイヤル プランがすでに「(省略形)オンネット サイト間」の権限を実装している場合、Unified CM でプロビジョニングされているパーティションはすでに存在しています。これは、同じパーティション内のすべての既知のオンネット Webex Calling の宛先を使用し、プロビジョニングすることができます。

そうでない場合、「(省略形)オンネット サイト間」権限の概念はまだ存在していません。新しいパーティション (たとえば「onNetRemote」) をプロビジョニングし、Webex Calling の宛先をこのパーティションに追加し、最後にこの新しいパーティションを適切なコール検索スペースに追加する必要があります。

ユーザーから Unified CM に着信Webex Calling

PSTN からの着信は Webex Calling のすべての宛先にアクセスする必要があります。 そのため、PSTN トランク上の着信で使用されるコール検索スペースに、すべての Webex Calling の宛先を保持する上記のパーティションを追加する必要があります。 Webex Calling の宛先へのアクセスは、既存のアクセスに追加されます。

PSTN から Unified CM DID にアクセスするコールについて、Webex Calling DID が必要な場合、Webex Calling で発信したコールは、Unified CM DID と PSTN の宛先にアクセスする必要があります。

図 1. 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」の「ダイヤル プラン」の章に記載されている設計アプローチに従っています。

図 2. 推奨するダイヤル プラン

この図は、推奨されるダイヤル プラン設計の概要を示しています。 このダイヤル プラン設計の主な特徴は次のとおりです。

  • Unified CM で構成されているすべてのディレクトリ番号は +E.164 形式です。

  • すべてのディレクトリ番号は同じパーティション (DN) に属しており、緊急としてマークされています。

  • コア ルーティングは +E.164 に基づいています。

  • すべての非 +E.164 ダイヤルの習慣 (たとえば、一般的なダイヤル習慣を使用するサイト内ダイヤルと PSTN ダイヤル) は、ダイヤリング正規化のための翻訳パターンを用いて、+E.164 に正規化 (グローバライズ) されます。

  • ダイヤル正規化の翻訳パターンは、翻訳パターン ルール検索スペースの継承を使用します。これらには、[発信者のコール検索スペースを使用] オプションが設定されています。

  • サービスのクラスは、サービス固有のコール検索スペースのサイトとクラスを使用して実装されます。

  • PSTN アクセス機能 (たとえば、国際 PSTN 宛先へのアクセス) は、サービスのクラスを定義するコール検索スペースに、それぞれの +E.164 ルート パターンを持つパーティションを追加することによって実装されます。

到達可能性Webex Calling

図 3. 宛先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 は最終的、ローカル ゲートウェイにコールを送信します。

サイト間ダイヤルに短縮ダイヤルを追加する

図 4. サイト間ダイヤルに短縮ダイヤルを追加する

参照ダイヤル プランにサイト間の短縮ダイヤルを追加する際に推奨される方法は、専用パーティション (「ESN」、エンタープライズ有意番号) への、エンタープライズのナンバリング プランの下で、すべてのサイトにダイヤリング正規化の翻訳パターンを追加することです。 これらの翻訳パターンは、エンタープライズ ナンバリング プランの形式のダイヤル文字列をインターセプトして、ダイヤル文字列を +E.164 に正規化します。

Webex Calling 宛先にエンタープライズの短縮ダイヤルを追加するには、Webex Calling ロケーションのそれぞれのダイヤル正規化変換パターンを「Webex Calling」パーティション (例えば、図の「8101XX」)に追加します。 正規化後、"Webex Calling" パーティションのユーザーと一ルート パターンした後で、通話Webex Callingされます。

この構成により望ましくない通話ルーティング ループが作成される可能性があるため、Webex Calling 通話の短縮ダイヤル正規化変換パターンを「ESN」パーティションに追加することを推奨しません。

コール用プロトコル ハンドラー

Webex Calling は、次のプロトコル ハンドラーをオペレーティング システムに登録して、ウェブ ブラウザーまたはその他のアプリケーションからのクリック通話機能を有効にします。 Mac または Windows でデフォルトの通話アプリケーションである場合、次のプロトコルは Webex アプリで音声またはビデオ通話を開始します。

  • CLICKTOCALL: または CLICKTOCALL://

  • SIP: または SIP:

  • TEL: または TEL:

  • WEBEXTEL: または WEBEXTEL://

Windows 用プロトコル ハンドラー

他のアプリは Webex アプリの前にプロトコル ハンドラーに 登録できます。 Windows 10 では、通話を開始するために使用するアプリを選択するためにユーザーに尋ねるシステム ウィンドウ。 ユーザーは、[常にこのアプリを使う] にチェックを入れて、記憶させることができます。

ユーザーが Webex アプリを選択するために、デフォルトの通話アプリ設定をリセットする必要がある場合、Windows 10 の Webex アプリのプロトコル関連付けを変更するように指示できます。

  1. [アプリの デフォルト設定] システム設定を 開き 、[アプリのデフォルト設定] をクリックして、[Webex アプリ] を選択します。

  2. 各プロトコルに対して、[Webex アプリ ] を選択します。

macOS 用のプロトコルハンドラー

Mac OS では、 Webex アプリの前に通話プロトコルに登録されている他のアプリがある場合、ユーザーは Webex アプリ をデフォルトの通話オプションに設定する必要があります。

Mac 用の Webex アプリ で、ユーザーは基本設定の下で [通話を開始] に対して Webex アプリが選択されているのを確認できます。 また、Outlook 連絡先の番号 をクリックして Webex アプリから通話を行う場合は、[常に Microsoft Outlook に接続する] をチェックすることもできます。

2022年9月30日
Webex Calling のための環境を準備する

通話のための要件

ライセンス

Webex Calling は、Cisco Collaboration フレックス プランで使用できます。 エンタープライズ契約 (EA)(ワークスペース デバイスの 50% を含むすべてのユーザー向け) または指定ユーザー (NU)プラン (一部またはすべてのユーザー)を購入する必要があります。

Webex Calling は、3 種類のライセンス(「ステーション タイプ」)を提供しています。

  • Professional - これらのライセンスは、組織全体にすべての機能を提供します。 このサービスには、統合型コミュニケーション (Webex Calling)、モビリティ ( 複数のデバイスに対応するデスクトップおよびモバイルクライアント)、Webex アプリでのチーム コラボレーション、ミーティングごとに最大で 1000 人の参加者とミーティングをバンドルするオプションが含まれています。

  • ベーシック—ユーザーがモビリティまたは統合コミュニケーションのない限られた機能を必要とする場合に、このオプションを選択します。 これらのユーザーはすべての機能を備えた音声機能を利用することができますが、ユーザーごとに 1 つのデバイスに限定されます。


    ベーシック ライセンスは、ネームド ユーザー サブスクリプションがある場合にのみ利用できます。 エンタープライズ契約のサブスクリプションでは、ベーシック ライセンスはサポートされていません。

  • ワークスペース (共通エリアとも呼ばれています) —小会議室、ロビー、会議室などのエリアに適したコール機能の限定されたセットの基本ダイヤルトーンを検索する場合に、このオプションを選択します。

この文書の後の部分では、Control Hub を使用して、組織全体のロケーションに分配されたこれらのライセンスを管理する方法について説明します。

帯域幅要件

ビデオコールの各デバイスは、最大 2 Mpps の帯域を必要とします。 音声コールの各デバイスは、100 kbps の帯域を必要とします。 アイドル状態の電話機は、最小限の帯域幅しか必要としません。

プレミスベースの PSTN のローカル ゲートウェイ

付加価値再販業者(VAR)とサービス プロバイダー(SP)の両方が、Webex Calling 組織への PSTN アクセスを提供できます。 ローカル ゲートウェイは現在、プレミスベースの PSTN アクセスを提供する唯一のオプションです。 ローカル ゲートウェイは、Cisco Unified Communications Manager へのインテグレーションが必要な場合、スタンドアロンまたは導入で展開することができます。 ローカル ゲートウェイの要件は次のとおりです。

サポートされている機器

Webex Calling は、Cisco マルチプラットフォーム(MPP) IP 電話をサポートします。 管理者は、クラウドに次の電話機を登録できます。 詳細は、次のヘルプ記事を参照してください。


Webex Calling のサポートされたデバイスの完全なリストについては、「Webex Calling のサポートされたデバイス」を参照してください。

Cisco Webex Room、Board、および Desk デバイスは、Control Hub で作成したワークスペースのデバイスとしてサポートされます。 詳細については、「Webex Calling でサポートされたデバイス」「Cisco Webex Room、Board、および Desk デバイス」を参照してください。 ただし、これらのデバイスをワークスペース用の Webex Calling を有効にすることにより、PSTN サービスで提供することができます。

ファイアウォール :

Cisco 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) エンタープライズ構成ガイド」を参照してください。 https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book.html

ローカル ゲートウェイのハードウェアおよびソフトウェア的要件

展開に「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 を実行している必要があります。

2022年9月30日
組織のために Cisco Webex Calling を設定する

Control Hub で 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 または郵便番号を入力します。
  • 通知言語 - 新規ユーザーと機能に関する音声通知と音声プロンプトで使用する言語を選択します。
  • メール言語 - 新規ユーザーとのメール通信に使用する言語を選択します。
  • タイムゾーン - ロケーションのタイム ゾーンを選択します。
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 サービス」を参照してください。

始める前に


ロケーションに関連付けられているユーザーとワークスペースのリストを取得します。 [サービス ] > 通話 番号> し、ドロップダウン メニューから、削除する場所を選択します。 ロケーションを削除する前に、これらのユーザーとワークスペースを削除する必要があります。

1

https://admin.webex.com の顧客ビューから [サービス]>[Calling][ロケーション] に移動します。

2

削除 する場所 隣の [アクション] 列をクリックします。

3

[場所 の削除] を選択し、その場所を削除します。

一般的に、場所が完全に削除されるには数分かかりますが、最大で 1 時間かかる場合があります。 ステータスを確認するには、ロケーション名の隣にある をクリックして、[削除ステータス] を 選択します

作成した後PSTNのセットアップ、名前、タイムゾーン、言語を変更できます。 新しい言語は新しいユーザーとデバイスにのみ適用されることに注意してください。 既存のユーザーおよびデバイスは古い言語を使用し続けます。


既存のロケーションについては、緊急時の 911 サービスを有効にすることができます。 詳細については「Webex Calling の RedSky 緊急 911 サービス」を参照してください。

1

https://admin.webex.com の顧客ビューで、 [サービス]>[Calling]>[ロケーション] に移動して、更新するロケーションを選択します。

ロケーションの隣に [警告] 記号が表示される場合、そのロケーションの電話番号をまだ設定していないという意味です。 その番号を設定するまで、通話の送受信が行えなんす。

2

(オプション) [PSTN 接続] の下で、すでに設定されているものに応じて、[クラウド接続 PSTN] または [プレミスベースの PSTN](ローカル ゲートウェイ) のいずれかを選択します。 [管理] をクリックして設定を変更してから、[続行] を選択することにより、関連するリスクを承認します。 以下のオプションのいずれかを選択して、[保存] クリックします。

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


     

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

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

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

    • ロケーションが新規である。 現在、他の既存のPSTN機能を割り当てた既存のロケーションは、Cisco 通話プランには適用されます。 サポート ケースを開いてご相談ください。

    • 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

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


 

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

一部の国 (例: フランス) の規制要件は、緊急電話を行い、緊急連絡時にセルの識別を確立するためのセルに関する規制要件であり、緊急権限によって利用可能になります。 米国やカナダなどのその他の国は、他の方法を用いて場所の設定を実施します。 詳細については、「緊急時通話の強化 」を参照してください

緊急通話プロバイダはアクセスネットワークに関する情報が必要な場合があります。新しいプライベートSIP拡張ヘッダーであるP-Access-Network-Infoを指定することで達成できます。 ヘッダーにはアクセスネットワークに関連する情報が含まれます。

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

5

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

6

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


 

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


 

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

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


発信ダイヤル コードは、Webex App、Webex Calling Cisco Room デバイスではサポートされていません。


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

1

https://admin.webex.com の顧客ビューから、[サービス][Calling][>サービス設定]に移動して、[内部ダイヤル] までスクロールします。

2

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

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

     

    内線の長さを増やした後、内部の内線への既存のスピード ダイヤルは、自動的に更新されません。

3

特定の場所の内部ダイヤルを指定します。 [サービス] > [コール] > [ロケーション] に移動し、ロケーションを選択し、次に [ダイヤル中] にスクロールして、必要に応じて内部および外部ダイヤルを変更します。

  • 内部ダイヤル - 別の場所にいるユーザーがこの場所にいる人に連絡するためにダイヤルする必要があるルーティング プレフィックスを指定します。 各ロケーションのルーティング プレフィックスは固有である必要があります。 プレフィックスの長さは組織レベルで設定された長さと一致することを推奨しますが、2-7 桁以内にする必要があります。
  • 外部ダイヤル - 任意に、外線にダイヤルするためにダイヤルする必要がある外線番号の番号を選択することができます。 デフォルトは [なし] であり、このダイヤル習慣が必要ない場合には、値を [なし] にしておくことができます。 この機能を使用しない場合、組織のステアリング番号とは別の番号を使用することをお勧めします。

     

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

ユーザーへの影響:

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

  • ユーザーの内線番号を、ロケーションのステアリング番号と同じ番号で開始することはできません。

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


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

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

始める前に

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

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

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

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

1

https://admin.webex.com の顧客ビューから、 [サービス] > [Calling] > [呼び出しルーティング] に移動し、[トランクの追加] を選択します。

2

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

3

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


 

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

次にやる必要

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

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

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

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

1

https://admin.webex.com の顧客ビューから [サービス]>[Calling][ロケーション] に移動します。

2

変更する場所を選択し、[管理] をクリックします。

3

プレミスベース PSTN を選択して、[次へ] をクリックします。

4

ドロップダウン メニューからトランクを選択します。


 

トランク ページにアクセスして、トランク グループの選択を管理します。

5

確認通知をクリックし、[保存] をクリックします。

次にやる必要

Control Hub で生成された設定情報を記録し、パラメーターをローカル ゲートウェイ (たとえばオンプレミスの Cisco CUBE) にマップする必要があります。 この記事では、このプロセスについて順を追って説明します。 参考のため、次の図を参照して、どのように Control Hub の設定情報 (左側) が CUBE のパラメーター (右側) にマップされるかを確認してください。

ゲートウェイ自体の設定が正常に完了し、Control Hub [サービス] > [通話] > [ロケーション] に戻ると、作成したゲートウェイが、名前の左側に緑色のドットが付けられてロケーション カードにリストされます。 このステータスは、ゲートウェイがセキュアに通話クラウドに対して登録され、そのロケーションでのアクティブな PSTN としての役割を果たしていることを示しています。

Control Hub では、組織の電話番号を簡単に表示、アクティベート、削除、追加できます。 詳細については、「Control Hub で電話番号を管理する」を参照してください。

1

https://admin.webex.com のカスタマー ビューから、建物のアイコン を選択します。

2

[サブスクリプション] タブを選択し、[今すぐ購入] をクリックします。

有料サブスクリプションへの変換に興味を持っていることを知らせるメールがパートナーに送信されます。

1

https://admin.webex.com の顧客ビューから、 [組織設定] > [サービス] に移動し、[Calling] までスクロールして [クライアントの設定] を選択します。

2

ユーザーに表示する通話オプションを [使用可能のコールオプション] フィールドにドラッグアンドドロップしてから、ユーザーに示したい優先順位で並べ替えます。

以下のスクリーンショットは、[非表示のコールオプション] フィールドでユーザーに対して非表示になっているその他のオプションです。

3

前の手順で設定した最初の通話オプションを使用してユーザーが通話を発信できるようにする場合は、[シングルクリック通話を有効にする] をオンに切り替えます。


 

Webex アプリで変更が表示されるまでに最大 24 時間かかる場合があります。 これらの変更をより迅速に把握するために、アプリを再起動するようにユーザーにアドバイスできます。

ユーザーが PSTN コールを行う際、どのコーリング アプリケーションで行うかは、制御することができます。 この設定を組織レベルで設定した後、特定のユーザーで別の設定を行うこともできます。


組織全体を移行する準備ができたら、組織全体のオプションのみを選択してください。

始める前に

  • 組織は、選択した通話動作のための適切なサブスクリプションを持っている必要があります。

  • ユーザーは有効な電話番号を持っている必要があります。 番号が無効な場合でも、Webex アプリは選択した通話アプリに番号を送りますが、そのアプリからの通話は失敗します。

https://admin.webex.comのカスタマービューから [管理] > [組織設定]に進み[発信動作]までスクロールして、以下のいずれかを選択します。 .

  • Webex のコールイン - ユーザーが Webex Calling を使用して Webex アプリで直接発信する場合は、このオプションを選択します。
  • Webex Calling アプリ - 組織が Cisco Webex Calling をサブスクリプションしており、Webex Calling アプリを使用してユーザーが PSTN 通話を行えるようにする場合は、このオプションを選択します。ユーザーが Webex アプリで PSTN 通話を行う場合は、Webex Calling アプリを使用して通話します。

     

    Webex Calling アプリは、一部の顧客のみ利用可能です。

通話動作が更新されたことを示すメッセージが表示されます。 ユーザーは Webex アプリまたは Webex Calling アプリから PSTN 通話を行えるようになりました。

ユーザーは、Webex アプリから PSTN 通話を行うには、対応するアプリケーションをインストールしておく必要があります。 どの方式を選択したかということと、PSTN コールを行う際に別のアプリが使用されることをユーザーに知らせてください。


 

特定のユーザーが別の通話動作を使用する必要がある場合は、この設定をユーザー レベルで変更することができます。 [ユーザー] に移動し、[設定] の下で、[通話動作] を選択します。 必要に応じて選択して、[保存] をクリックします。

2022年10月21日
Webex Calling に IOS-XE でローカル ゲートウェイを構成する

組織のシステムWebex Calling設定した後、トランクを構成して、ローカル ゲートウェイをユーザーに接続Webex Calling。SIP TLS トランスポートは、ローカル ゲートウェイと Webex クラウド間のトランクをセキュアにします。ローカル ゲートウェイとローカル ゲートウェイ間のメディアは、SRTP Webex Calling使用します。

ローカル ゲートウェイ構成タスク フロー

システム トランクのローカル ゲートウェイを設定するための 2 つの Webex Calling があります。

  • 登録ベースのトランク

  • 証明書ベースのトランク

登録ベースのローカル ゲートウェイまたは証明書ベースのローカル ゲートウェイ の下でタスク フローを使用して、ローカル ゲートウェイをローカル Webex Callingします。異 なるトランク タイプに関する詳細については、「システムのトランク、ルート グループ、およびダイヤル Webex Calling を構成する」を参照してください。コマンドラインインターフェース (CLI) を使用して、ローカル ゲートウェイ自体で以下の手順を実行します。ローカル ゲートウェイと Webex Calling 間のメディアをセキュアにするために、セッション開始プロトコル (SIP) および Transport Layer Security (TLS) トランスポートを使用してトランクとセキュアなリアルタイム プロトコル (SRTP) をセキュリティで保護します。

始める前に

  • サイトのオンプレミスの公衆交換電話網 (PSTN) およびローカル ゲートウェイ (LGW) の要件について Webex Calling。詳細については 、「設定されたアーキテクチャ」Webex Calling を参照してください。

  • この記事では、専用のローカル ゲートウェイ プラットフォームが配置されているが、既存の音声構成がないと仮定しています。既存の PSTN ゲートウェイまたはローカル ゲートウェイのエンタープライズ展開を変更して、Webex Callingのローカル ゲートウェイ機能として使用する場合、設定に注意してください。変更内容が変更されたため、既存の通話フローと機能を中断しなでいなことを確認してください。

  • コントロール ハブでトランクを作成し、ロケーションに割り当てします。詳細 については、「システムのトランク、ルート グループ、およびダイヤル プランWebex Callingを参照してください。

始める前に

  • 構成する次の基準プラットフォーム設定が、組織のポリシーと手順に従って設定されていないことを確認してください。

    • NTP

    • Acl

    • パスワードを有効にする

    • プライマリパスワード

    • IP ルーティング

    • IP アドレスなど

  • すべてのローカル ゲートウェイの展開に対して、Cisco IOS XE 16.12 または IOS-XE 17.3 のサポートされている最低のリリースが必要です。

1

任意のレイヤー 3 インターフェイスが、有効でアクセス可能な IP アドレスを持っている必要があります。

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
ip address 192.168.43.197 255.255.255.0
2

証明書と共有シークレットを使用する前に、次のコマンドを使用して、パスワードのプライマリキーを事前に構成してください。AES 暗号とユーザー定義のプライマリキーを使用して、Type 6 パスワードを暗号化します。

conf t
key config-key password-encrypt Password123
password encryption aes
3

IP 名サーバーを構成して、DNS ルックアップと ping を有効にして、サーバーが到達可能な時間を確認します。ローカル ゲートウェイは DNS を使用して、プロキシ Webex Calling解決します。

conf t
Enter configuration commands, one per line.  End with CNTL/Z.
ip name-server 8.8.8.8
end
4

TLS 1.2 の公開およびデフォルトのプレースホルダ トラストポイントを有効にする:

  1. プレースホルダ PKI トラストポイントを作成し、sampleTP と呼 び出します

  2. sip-ua の下で、デフォルトのシグナリング トラストポイント としてトラストポイントを指定します


     
    • cn-san-validate サーバーがローカル ゲートウェイ接続を確立する場合、テナント 200 (後で記載) で構成するアウトバウンド プロキシがサーバーから受信する CN-SAN リストと一致する場合のみ、確認してください。

    • TLS が動作するには暗号化トラストポイントが必要です。ローカルクライアント証明書(mTLSなど)は必要ない場合でも接続を設定します。

  3. TLS v1.0 および v1.1 を無効にするには、v1.2 のエクスカリシを有効にします。

  4. tcp-retry カウントを 1000 (5-msec 複数 = 5 秒) に設定します。

  5. TLS を確立するためのタイマー接続を設定します <wait-timer in="" sec="">。範囲は 5 ~ 20 秒で、デフォルトは 20 秒です。(LGW は次に利用可能なへの接続の確立を試みる前に、TLS 接続障害を検出するのに 20 秒かかっています。 Webex Calling SBC にアクセスできます。CLI により、管理者は値を変更してネットワーク条件に対応し、Access SBC の接続障害を検出する時間がはるかに速くなりました)。


     

    Cisco IOS XE 17.3.2 以降のバージョンが適用できます。

configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
crypto pki trustpoint sampleTP
revocation-check crl
exit

sip-ua
crypto signaling default trustpoint sampleTP cn-san-validate server
transport tcp tls v1.2
tcp-retry 1000
end
5

ローカル ゲートウェイ信頼プールの更新:

デフォルトのトラストプールバンドルには、Webex Callingに対する TLS 接続中にサーバー側の証明書を検証するために必要な「DigiCert Root CA」または「IdenTrust Commercial」証明書は含みません。

最新の「 Cisco Trusted Core Root Bundle」を から http://www.cisco.com/security/pki/ ダウンロードして、トラストプール バンドルを更新します。

  1. DigiCert Room CA と IdenTrust Commercial の証明書が存在しているかどうか確認します。

    show crypto pki trustpool | include DigiCert
  2. DigiCert Room CA と IdenTrust Commercial 証明書が存在しない場合、以下のように更新します。

    configure terminal
    Enter configuration commands, one per line.  End with CNTL/Z.
    crypto pki trustpool import clean url http://www.cisco.com/security/pki/trs/ios_core.p7b
    Reading file from http://www.cisco.com/security/pki/trs/ios_core.p7b
    Loading http://www.cisco.com/security/pki/trs/ios_core.p7b 
    % PEM files import succeeded.
    end
    

     

    代わりに、証明書バンドルをダウンロードして、ローカル サーバーまたはローカル ゲートウェイ フラッシュ メモリからインストールすることもできます。

    例:

    crypto pki trustpool import clean url flash:ios_core.p7b
  3. 確認:

    show crypto pki trustpool | include DigiCert
    cn=DigiCert Global Root CA
    o=DigiCert Inc
    cn=DigiCert Global Root CA
    o=DigiCert Inc
    
    show crypto pki trustpool | include IdenTrust Commercial
    cn=IdenTrust Commercial Root CA 1
    cn=IdenTrust Commercial Root CA 1

始める前に

Control Hub のステップを完了して、ロケーションを作成し、そのロケーションにトランクを追加します。次の例では、Control Hub から情報を取得します。

1

ローカル ゲートウェイ アプリケーションをオンに するために、次のコマンドを入力します。詳細については、サイトに追加する必要がある最新の IP サブネットの Cisco Webex Calling のポート参照情報を信頼リスト。

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 t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none
stun
stun flowdata agent-id 1 boot-count 4
stun flowdata shared-secret 0 Password123$
sip
g729 annexb-all
early-offer forced
asymmetric payload full
end

以下は、設定のフィールドの説明です。

有料不正使用の防止
voice service voip
ip address trusted list
ipv4 x.x.x.x y.y.y.y
  • ローカル ゲートウェイが Webex Calling ピア、Unified CM ノード、IP アドレスなど、VoIP 通話の正当な VoIP を期待するエンティティのソース IP アドレスを有効PSTN。

  • デフォルトで、LGW は、信頼リストにない IP アドレスからのすべての着信 VoIP コール セットアップをブロックします。「セッションターゲット IP」またはサーバーグループを持つダイヤルピアからの IP アドレスは、デフォルトで信頼され、ここに入力する必要はありません。

  • リスト内の IP アドレスは、接続するデータセンターの地域の構成Webex Calling IP サブネットと一致する必要があります。詳細については、「Webex Calling のポート参照情報」を参照してください。


     

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

  • 他のインターフェイスで他の IP アドレスを設定します。例:[Unified CM アドレス] を内側側のインターフェースに追加します。

  • IP アドレスは主催者 IP と outbound-proxyテナント 200 に解決されます。

  • 詳細については、https://www.cisco.com/c/en/us/support/docs/voice/call-routing-dial-plans/112083-tollfraud-ios.htmlを参照してください。

メディア
voice service voip
 media statistics 
 media bulk-stats 
SIP-to-SIP 基本機能
allow-connections sip to sip
補足サービス
no supplementary-service sip refer
no supplementary-service sip handle-replaces

REFER を無効にし、置換ヘッダー内のダイアログ ID をピアダイアログ ID に置き換える。

詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr4/vcr4-cr-book/vcr-s12.html#wp2876138889を参照してください。

FAX プロトコル
fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none

FAX トラフィックは暗号化されませんが、FAX トランスポートに対して T.38 を有効にできます。

詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr2/vcr2-cr-book/vcr-f1.html#wp3472350152を参照してください。
グローバル stun を有効にする
stun
stun flowdata agent-id 1 boot-count 4
stun flowdata shared-secret 0 Password123$
  • 通話を Webex Calling ユーザーに転送する場合 ( 例えば、通話側と通話側の両当事者が Webex Calling のサブスクライバーであり、Webex Calling SBC にメディアを固定する場合)、メディアはピンホールが開いていないので、ローカル ゲートウェイにフローできません。

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

  • Stun パスワードは、ローカル ゲートウェイが stun メッセージを送信する必要があります。Cisco IOS/IOS XE ベースのファイアウォールを構成して、パスワードをチェックし、ピンホールを動的に開く (明示的なインアウトルール無しなど) 設定できます。ただし、ローカル ゲートウェイ の展開の場合、ファイアウォールを静的に構成して、SBC サブネットの構成に基づいて、ピンホールWebex Calling 開きます。そのため、ファイアウォールは SBC サブネットをインバウンド UDP パケットとして扱い、パケットコンテンツを明示的に見る必要なく、ピンホールの開きをトリガーする必要があります。

詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr5/vcr5-cr-book/vcr-v2.html#wp1961799183を参照してください。
G729
sip
g729 annexb-all

G729 のすべてのバリアントを許可します。

詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr5/vcr5-cr-book/vcr-v1.html#wp3562947976を参照してください。
SIP
early-offer forced

ローカル ゲートウェイを強制的に、近隣ピアからの承認を待つ代わりに、最初の INVITE メッセージで SDP 情報を送信します。

詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr2/vcr2-cr-book/vcr-e1.html#wp3350229210を参照してください。
2

「SIP Profile 200」を設定します。

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=hussain2572_lgu>"
rule 30 request ANY sip-header P-Asserted-Identity modify "sips:(.*)" "sip:\1"

以下は、設定のフィールドの説明です。

  • ルール 9

    次のようにヘッダーを一覧表示します “SIP-Req-URI” としてリストされ、次のようにリストされなくなります: “SIP-Req-URL” .

    sip URI と SIP URL の間でルールを変換します。Webex Calling はリクエスト/応答メッセージでは SIP URI をサポートしませんが、SRV クエリーには必要とします。例: _sips._tcp.<outbound-proxy>.
  • ルール 20

    [From] ヘッダーを変更して、Control Hub のトランク グループ OTG/DTG パラメーターを含み、エンタープライズ内のローカル ゲートウェイ サイトを一意的に識別します。

  • SIP プロファイルを音声クラス テナント 200 (後で説明) に、すべてのトラフィックに対して適用Webex Calling。詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr5/vcr5-cr-book/vcr-v1.html#wp3265081475を参照してください。

3

コーデック プロファイル、stun 定義、および SRTP 暗号化スイートを構成します。

voice class codec 99
codec preference 1 g711ulaw
codec preference 2 g711alaw 
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
stun usage ice lite
exit

以下は、設定のフィールドの説明です。


 

ITSP SBC のアンカーメディアとローカル ゲートウェイが NAT の背後にある場合、ITSP からのインバウンド メディア ストリームを待ちます。ダイヤルピアに面する ITSP で stun コマンドを適用できます。


 

メディア パスの最適化を利用した通話フローに対して、stun usage ice-lite が必要です。

4

Control Hub パラメーターをローカル ゲートウェイ設定にマップします。

ローカル Webex Calling ゲートウェイにテナントとして追加します。音声クラス テナント 200 の下でローカル ゲートウェイ を登録するには、構成が必要です。次の画像に示すように、コントロール ハブから [トランク情報] ページから設定の要素を取得する必要があります。次の例は、各ローカル ゲートウェイ CLI にマップされるフィールドを表示します。

ローカル ゲートウェイ 構成内で、Webex Callingピア ( タグ) に対して、テナント 200 2xx を適用します。音声クラステナント機能を使用すると、音声サービス システムおよび sip-ua の下で行われる、sip トランク のパラメーターをグループ化VoIP設定することができます。テナントを構成し、ダイヤルピアの下で適用する場合、以下の基本設定の順序がローカル ゲートウェイの構成に適用されます。

  • ダイヤルピア設定

  • テナント構成

  • グローバル設定 (ボイス サービス VoIP / sip-ua)

5

音声 クラス テナント 200 を設定して 、コントロール ハブから取得したパラメータに基づいて、ローカル ゲートウェイから Webex Calling トランク登録を有効にします。


 

次のコマンド ラインとパラメータは例のみです。独自の展開のパラメータを使用します。

voice class tenant 200
  registrar dns:40462196.cisco-bcld.com scheme sips expires 240 refresh-ratio 50 tcp tls
  credentials number Hussain6346_LGU username Hussain2572_LGU password 0 meX7]~)VmF realm BroadWorks
  authentication username Hussain2572_LGU password 0 meX7]~)VmF realm BroadWorks
  authentication username Hussain2572_LGU password 0 meX7]~)VmF 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 GigabitEthernet0/0/1
  bind media source-interface GigabitEthernet0/0/1
  no pass-thru content custom-sdp 
  sip-profiles 200 
  outbound-proxy dns:la01.sipconnect-us10.cisco-bcld.com  
  privacy-policy passthru

以下は、設定のフィールドの説明です。

voice class tenant 200

テナントに対して差別化されたサービスを許可する SIP トランクの複数のテナントに対して特定のグローバル構成を有効にします。

詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr5/vcr5-cr-book/vcr-v1.html#wp2159082993を参照してください。
registrar dns:40462196.cisco-bcld.com scheme sips expires 240 refresh-ratio 50 tcp tls

ローカル ゲートウェイの登録サーバーで、2 分ごとに更新が設定されている場合 (240 秒の 50%)。詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr3/vcr3-cr-book/vcr-r1.html#wp1687622014 を参照してください。

credentials number Hussain6346_LGU username Hussain2572_LGU password 0 meX71]~)Vmf realm BroadWorks

トランク登録認証の資格情報。詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr1/vcr1-cr-book/vcr-c6.html#wp3153621104 を参照してください。

authentication username Hussain2572_LGU password 0 meX71]~)Vmf realm BroadWorks
authentication username Hussain2572_LGU password 0 meX71]~)Vmf realm 40462196.cisco-bcld.com

コールの認証の課題。詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr1/vcr1-cr-book/vcr-a1.html#wp1551532462 を参照してください。

no remote-party-id

Webex Calling は PAI をサポートしているため、CIO asserted-id pai.詳細については、 https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr3/vcr3-cr-book/vcr-r1.html#wp1580543764を参照してください。

sip-server dns:40462196.cisco-bcld.com
システムサーバーを Webex Calling します。詳細については、次のサイトを参照してください。https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr1/vcr1-cr-book/vcr-a1.html#wp1551532462
connection-reuse

登録と通話処理に同じ永続的な接続を使用します。

詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr1/vcr1-cr-book/vcr-c6.html#wp1622025569を参照してください。
srtp-crypto 200

定義 voice class srtp-crypto 200 を選択して SHA1_80 を指定します。詳細については、 https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr5/vcr5-cr-book/vcr-v1.html#wp1731779246を参照してください。

session transport tcp tls
TLS へのトランスポートを設定します。詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr4/vcr4-cr-book/vcr-s2.html#wp1960850066を参照してください。
url sips

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

error-passthru

SIP エラー応答パススルー機能を指定します。

詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr2/vcr2-cr-book/vcr-e1.html#wp2069028434を参照してください。
asserted-id pai

ローカル ゲートウェイで簡単に処理をオンにする。詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr1/vcr1-cr-book/vcr-a1.html#wp1052365203を参照してください。

bind control source-interface GigabitEthernet0/0/1

このインターフェイスが提供するシグナリング ソース インターフェイス用に、ソース IP アドレスWebex Calling。詳細については https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr1/vcr1-cr-book/vcr-b1.html#wp2714966862 、を参照してください。

bind media source-interface GigabitEthernet0/0/1

このインターフェイス上のメディアソースのソース IP アドレスを Webex Calling。詳細については https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr1/vcr1-cr-book/vcr-b1.html#wp2714966862 、を参照してください。

no pass-thru content custom-sdp

テナントの下のデフォルト コマンド。詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr3/vcr3-cr-book/vcr-p1.html#wp1894635288を参照してください。

sip-profiles 200

SIP に SIP を変更し、 で定義された通り INVITE および REGISTER メッセージ用に回線/ポートを変更します voice class sip-profiles 200.詳細については、 https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr5/vcr5-cr-book/vcr-v1.html#wp3265081475を参照してください。

outbound-proxy dns:la01.sipconnect-us10.cisco-bcld.com

Webex Calling SBC にアクセスします。詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr3/vcr3-cr-book/vcr-o1.html#wp3297755699 を参照してください。

privacy-policy passthru

着信から発信レグにプライバシー ヘッダー値を透過的に渡します。詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr3/vcr3-cr-book/vcr-p2.html#wp2238903481を参照してください。

ローカル ゲートウェイ内でテナント 200 を定義し、SIP VoIP ダイヤルピアを構成した後、ゲートウェイは sBC がローカル ゲートウェイに対して証明書を提示する Webex Callingに対して TLS 接続を開始します。ローカル ゲートウェイは、前 Webex Calling CA ルート バンドルを使用して SBC 証明書にアクセスするユーザーを検証します。ローカル ゲートウェイと SBC へのアクセスの間で 、永続的な TLS Webex Calling 確立します。ローカル ゲートウェイは、後で課題のあるアクセス SBC に REGISTER を送信します。登録 AOR は number@domain です。この数字はサインイン情報の"number"パラメータおよびドメインから「登録 DNS:」から取り出されます<fqdn>。登録の入力が課題が生じ場合:

  • 資格情報からの ユーザー名、パスワード、および領域 パラメータ を使用して、ヘッダーと sip-profile 200 を構築します。

  • SIPS URL を SIP に戻します。

アクセス SBC から 200 OK を受け取った場合、登録は成功しました。

この展開では、ローカル ゲートウェイで以下の構成が必要です。

  1. 音声クラス テナント—ダイヤル ピアに対して作成する 200 と同様のダイヤル ピアの他のテナントを作成します。 Webex Calling 対して作成します。

  2. 音声クラス URI—ローカル ゲートウェイで終了するさまざまなトランクのホスト IP アドレス/ポートのパターンを定義します。

    • Webex Calling LGW へ

    • PSTNの SIP トランク終端

  3. 発信ダイアルピア—LGW から ITSP SIP トランクおよび発信コールWebex Calling。

  4. 音声クラス DPG—インバウンド ダイヤル ピアから発信ダイヤル ピアをターゲットに呼び出す呼び出し可能です。

  5. 着信ダイアルピア—ITSP およびこれらのポートからの着信コールのWebex Calling。

以下の画像に示すように、パートナーがホストするローカル ゲートウェイのセットアップ、または顧客サイト ゲートウェイのいずれかの構成を使用します。

1

以下の音声クラス テナントを設定します:

  1. 音声クラス テナント 100 をすべての 発信ダイアルピア対面 IP アドレスに適用PSTN。

    voice class tenant 100 
    session transport udp
    url sip
    error-passthru
    bind control source-interface GigabitEthernet0/0/0
    bind media source-interface GigabitEthernet0/0/0
    no pass-thru content custom-sdp
    
  2. 音声クラス テナント 300 を IP アドレスからすべてのインバウンド ダイヤル ピアに適用PSTN。

    voice class tenant 300 
    bind control source-interface GigabitEthernet0/0/0
    bind media source-interface GigabitEthernet0/0/0
    no pass-thru content custom-sdp
    
2

以下の音声クラス URI を設定します。

  1. ITSP のホスト IP アドレスを定義:

    voice class uri 100 sip
      host ipv4:192.168.80.13
    
  2. Control Hub のトランク グループ OTG または DTG パラメーターに基づいて、エンタープライズ内のローカル ゲートウェイ サイトを固有に識別するためのパターンを定義します。

    voice class uri 200 sip
     pattern dtg=hussain2572.lgu
    

     

    ローカル ゲートウェイは現在、マッチ パターンのアンダースコア「_」をサポートしません。回避策として、点 "" を使用できます。(任意のものを)「_」にマッチさせます。

    Received
    INVITE sip:+16785550123@198.18.1.226:5061;transport=tls;dtg=hussain2572_lgu SIP/2.0
    Via: SIP/2.0/TLS 199.59.70.30:8934;branch=z9hG4bK2hokad30fg14d0358060.1
    pattern :8934
    
3

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

  1. IP PSTN に向かう発信ダイヤルピア:

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

    以下は、設定のフィールドの説明です。

    dial-peer voice 101 voip
     description Outgoing dial-peer to PSTN
    

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

    destination-pattern BAD.BAD

    ダイヤルピア 101 の選択 を許可します。しかし、この発信ダイヤルピアを、dpg ステートメントを使用してインバウンドダイヤルピアから直接呼び出し、番号パターンマッチ基準をバイパスします。使用している番号は、宛先パターン CLI によって許容される英数字に基づく任意のパターンを使用しています。

    session protocol sipv2

    ダイヤルピア 101 が SIP コールのコールコールを 処理する場合に指定します。

    session target ipv4:192.168.80.13

    宛先のターゲット IPv4 アドレスを示し、コールレグを送信します。この場合、ITSP の IP アドレスです。

    voice-class codec 99

    Codec 基本設定リスト 99 がこのダイヤルピアに使用されることを示します。

    dtmf-relay rtp-nte

    このコール レッグで期待される DTMF 機能として、RTP-NTE (RFC2833) を定義します。

    voice-class sip tenant 100

    ダイヤルピアは、ダイヤル ピア自体の下で同じパラメータが定義されていない限り、テナント 100 からすべてのパラメータを継承します。

    no vad

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

  2. Webex Calling に対する発信ダイアルピア ( 構成ガイドの Webex Calling 以降から受信ダイアルピアとして機能するために、発信ダイアルピアを更新します)。

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

    コマンドの説明:

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

    ダイヤル ピアVoIPダイヤル ピア を管理し、200201トラブルシューティングを容易にするための重要な説明を提供します。

    session target sip-server

    グローバル SIP サーバーがこのダイヤルピアからのコールの宛先であることを示します。 Webex Calling 200 に 定義するサーバーは 、ダイヤルピア構成に対して 継承200201

    voice-class stun-usage 200

    ローカルに生成された stun リクエストをローカル ゲートウェイでネゴシエートされたメディア パス上に送信可能にできます。Stun はファイアウォールのピンホールを開くのに役立ちます。

    no voice-class sip localhost

    送信メッセージの物理的 IP アドレスの代用として、From、Call-ID、Remote-Party-ID ヘッダーの DNS ローカル ホスト名の代入を無効にします。

    voice-class sip tenant 200

    ダイアルピア は、ダイアルピア自体の下で同じパラメータを定義しない限り、テナント 200 (LGW <--> Webex Calling Trunk) からすべてのパラメータを継承します。 </-->

    srtp

    コールレグの SRTP を有効にする。

    no vad

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

4

以下のダイヤルピアグループを構成します (dpg):

  1. ダイヤルピア グループ 100 を定義します。発信ダイヤルピア 101 は、ダイヤルピア グループ 100 を呼び出す着信ダイヤルピアのターゲットです。DPG 100 を 着信ダイアル ピア 200201に Webex Calling --> LGW --> PSTN パスに 適用します。

    voice class dpg 100
    description Incoming WxC(DP200201) to IP PSTN(DP101)
    dial-peer 101 preference 1
    
  2. ダイヤルピア グループ 200 を発信ダイヤルピア 200201 で、PSTN --> LGW --> Webex Calling パスのターゲット200201として定義します。DPG 200 を後 で定義する着信ダイアル ピア 100 に適用します。

    voice class dpg 200
    description Incoming IP PSTN(DP100) to Webex Calling(DP200201)
    dial-peer 200201 preference 1
    
5

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

  1. 着信 IP PSTN コール レッグの着信ダイヤルピア:

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

    以下は、設定のフィールドの説明です。

    dial-peer voice 100 voip
    description Incoming dial-peer from PSTN

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

    session protocol sipv2

    ダイヤルピア 100 が SIP コール のコールコールを処理する場合に指定します。

    incoming uri via 100

    音声クラス uri 100 を 指定して、IP サーバーから VIA ヘッダー PSTNホスト IP アドレスのローカル ゲートウェイへのすべての着信トラフィックを一致します。詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr2/vcr2-cr-book/vcr-i1.html#wp7490919080を参照してください。

    destination dpg 200

    ダイヤルピアグループ 200 を指定して 外線ダイヤルピアを選択します。詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr5/vcr5-cr-book/vcr-v1.html#wp7209864940を参照してください。

    voice-class sip tenant 300

    ダイアルピアは、ダイヤル ピア自体の下で同じパラメータが定義されていない限り、テナント 300 からすべてのパラメータを継承します。

    no vad

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

  2. Webex Calling コール レッグの着信ダイヤルピア:

    dial-peer voice 200201 voip
    description Inbound/Outbound Webex Calling
    max-conn 250
    destination dpg 100
    incoming uri request 200
     

    以下は、設定のフィールドの説明です。

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

    ダイヤル ピアVoIP 構成の タグを200201、管理とトラブルシューティングを容易にするための意味のある説明を行います。

    incoming uri request 200

    音声クラス URI 200 を指定して、要求 URI の一意の dtg パターンで Webex Calling から LGW へのすべての着信トラフィックを一致します。企業内および Webex Calling エコシステム内のローカル ゲートウェイ サイトを一意的に識別します。詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr2/vcr2-cr-book/vcr-i1.html#wp7490919080を参照してください。

    destination dpg 100

    ダイヤル ピア グループ 100 を指定して 外線ダイヤル ピアを選択します。詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr5/vcr5-cr-book/vcr-v1.html#wp7209864940を参照してください。

    max-conn 250

    LGW と Webex Calling の間で同時通話の数を 250 に制限します。この記事で定義されている通りに、受信と発信の両方に対して 1 つのダイヤルピア側の Webex Calling を想定します。ローカル ゲートウェイを含む同時通話の制限の詳細は、 を参照してください https://www.cisco.com/c/dam/en/us/td/docs/solutions/PA/mcp/DEPLOYMENT_CALLING_Unified_CM_to_Webex_Calling.pdf

PSTN から Webex Calling

ローカル ゲートウェイのすべての着信 IP PSTN 呼び出し足をダイアルピア 100 と一致して、VIA ヘッダーの判断基準を IP ゲートウェイの IP アドレスPSTNします。DPG 200 は 発信ダイヤル ピア 200201呼び出し、Webex Callingサーバーをターゲット接続先として持っています。

Webex Calling から PSTN

ローカル ゲートウェイのすべての着信 Webex Calling 呼び出し足をダイアルピア 200201 と一致して、このローカル ゲートウェイ展開固有のトランク グループ OTG/DTG パラメータの REQUEST URI ヘッダー パターンの一致基準を定義します。DPG 100 は 発信ダイヤル ピア 101を呼び出します。これは、IP サーバーおよび IP PSTNをターゲット宛先として持っています。

この展開では、ローカル ゲートウェイで以下の構成が必要です。

  1. 音声クラス テナント—ダイヤル ピアに対して作成する Webex Calling ダイヤル ピアに対して作成するテナント 200 と同様に、Unified CM と ITSP に面するダイヤル ピアのためにさらに多 くのテナントを作成します。

  2. 音声クラス URI—LGW を終了するさまざまなトランクのホスト IP アドレス/ポートのパターンを定義します。

    • この宛先用の Unified CM から LGW PSTNします。

    • この宛先用の Unified CM から LGW Webex Callingする

    • Webex Calling LGW 宛先へ

    • PSTNの SIP トランク終端

  3. 音声クラス サーバー グループ—以下から、送信トランクの IP アドレス/ポートをターゲットにできます。

    • LGW から Unified CM へ

    • LGW から Webex Calling

    • LGW を使って SIP PSTN接続する

  4. 発信ダイアルピア—次から発信コールの呼び出しをルートできます。

    • LGW から Unified CM へ

    • ITSP SIP トランク

    • Webex Calling

  5. 音声クラス DPG—着信ダイヤルピアからターゲットの発信ダイヤルピアに呼び出し可能です。

  6. 着信ダイヤルピア—Unified CM、ITSP、および Webex Calling からの着信コールを受 け付Webex Calling

1

以下の音声クラス テナントを設定します:

  1. Unified CM および IP アドレスに面しているすべての発信ダイヤルピアで、音声クラス テナント 100 をPSTN。

    voice class tenant 100 
    session transport udp
    url sip
    error-passthru
    bind control source-interface GigabitEthernet0/0/0
    bind media source-interface GigabitEthernet0/0/0
    no pass-thru content custom-sdp
    
  2. Unified CM および IP アドレス からすべてのインバウンド ダイヤル ピアに音声クラス テナント 300 を適用PSTN。

    voice class tenant 300 
    bind control source-interface GigabitEthernet0/0/0
    bind media source-interface GigabitEthernet0/0/0
    no pass-thru content custom-sdp
    
2

以下の音声クラス URI を設定します。

  1. ITSP のホスト IP アドレスを定義します。

    voice class uri 100 sip
      host ipv4:192.168.80.13
    
  2. Control Hub のトランク グループ OTG/DTG パラメーターに基づいて、エンタープライズ内のローカル ゲートウェイ サイトを固有に識別するためのパターンを定義します。

    voice class uri 200 sip
    pattern dtg=hussain2572.lgu
    

     

    ローカル ゲートウェイは現在、マッチ パターンの「」_アンダースコアをサポートしません。回避策として、dot "" を使用します。(任意のものを)「_」にマッチさせます。

    Received
    INVITE sip:+16785550123@198.18.1.226:5061;transport=tls;dtg=hussain2572_lgu SIP/2.0
    Via: SIP/2.0/TLS 199.59.70.30:8934;branch=z9hG4bK2hokad30fg14d0358060.1
    pattern :8934
    
  3. Webex Calling トランクの Unified CM シグナリング VIA ポートを定義します。

    voice class uri 300 sip
    pattern :5065
    
  4. Unified CM 送信元シグナリング IP および VIA ポートを、以下のトランクにPSTNします。

    voice class uri 302 sip
    pattern 192.168.80.60:5060
    
3

以下の音声クラス サーバー グループを設定:

  1. Unified CM グループ 1 (5 ノード) に対して、Unified CM トランクのターゲットホスト IP アドレスとポート番号を定義します。Unified CM は Webex Calling トランク (Webex Calling <->LGW --> Unified CM) の着信トラフィックに対してポート 5065 を使用します。

    voice class server-group 301
    ipv4 192.168.80.60 port 5065
    
  2. Unified CM グループ 2 の Unified CM トランクのターゲットホスト IP アドレスとポート番号 (該当する場合) を定義します。

    voice class server-group 303
    ipv4 192.168.80.60 port 5065
    
  3. Unified CM グループ 1 (5 ノード) に対して、Unified CM トランクのターゲットホスト IP アドレスを定義します。Unified CM は PSTN トランクで着信トラフィックに対してデフォルトのポート 5060 を使用します。ポート番号が指定されていない場合は、デフォルトの 5060 ポートを使用できます。(PSTN <-> LGW --> Unified CM)</->

    voice class server-group 305
    ipv4 192.168.80.60
    
  4. 必要に応じ、Unified CM グループ 2 に対して、Unified CM トランクのターゲットホスト IP アドレスを定義します。

    voice class server-group 307 
    ipv4 192.168.80.60
    
4

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

  1. IP PSTN に向かう発信ダイヤルピア:

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

    以下は、設定のフィールドの説明です。

    dial-peer voice 101 voip
    description Outgoing dial-peer to PSTN

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

    destination-pattern BAD.BAD

    ダイヤルピア 101 の選択 を許可します。しかし、dpg ステートメントを使用して着信ダイヤルピアから直接発信ダイアルピアを呼び出し、番号パターンマッチ基準をバイパスします。使用している番号は、宛先パターン CLI によって許容される英数字に基づく任意のパターンです。

    session protocol sipv2

    ダイヤルピア 101 が SIP コール のコールコールを 処理する場合に指定します。

    session target ipv4:192.168.80.13

    宛先のターゲット IPv4 アドレスを示し、コールレグを送信します(この場合、ITSP の IP アドレス)。

    voice-class codec 99

    このダイヤルピアでコーデック 設定リスト 99 が使用されています。

    voice-class sip tenant 100

    ダイヤルピアは、ダイヤル ピア自体の下で同じパラメータを定義しない限り、テナント 100 からすべてのパラメータを継承します。

  2. アウトバウンド ダイヤル ピアを Webex Calling (アウトバウンド ダイヤル ピアを更新して、このアウトバウンド ダイヤルピアをこのグループからのインバウンド ダイヤルピア としてWebex Calling):

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

    以下は、設定のフィールドの説明です。

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

    ダイヤル ピアに VoIPを 定義し、200201トラブルシューティングを容易にするための重要な説明を提供します。

    session target sip-server

    グローバル SIP サーバーがダイアルピアシステムからの 通話の宛先200201。 Webex Calling 200 で 定義されているサーバーは 、ダイヤルピア構成に対して継承 200201

    voice-class stun-usage 200

    ローカルに生成された stun リクエストがネゴシエートされたメディアパス上で送信を許可します。Stun はファイアウォールのピンホールを開くのに役立ちます。

    no voice-class sip localhost

    送信メッセージの物理的 IP アドレスの代用として、From、Call-ID、Remote-Party-ID ヘッダーの DNS ローカル ホスト名の代入を無効にします。

    voice-class sip tenant 200

    ダイアルピア は、ダイアルピア自体の下で同じパラメータを定義しない限り、テナント 200 (LGW <--> Webex Calling トランク) からすべてのパラメータを継承します。 </-->

    srtp

    コールレグの SRTP を有効にする。

  3. Unified CM のクライアント トランクへの外向きダイヤルWebex Callingピア:

    dial-peer voice 301 voip
    description Outgoing dial-peer to CUCM-Group-1 for 
    inbound from Webex Calling - Nodes 1 to 5
    destination-pattern BAD.BAD
    session protocol sipv2
    session server-group 301
    voice-class codec 99
    dtmf-relay rtp-nte
    voice-class sip tenant 100
    no vad
    

    以下は、設定のフィールドの説明です。

    dial-peer voice 301 voip
    description Outgoing dial-peer to CUCM-Group-1 for 
    inbound from Webex Calling – Nodes 1 to 5

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

    session server-group 301

    ダイヤルピアのセッションターゲット IP の代わりに、宛先サーバーグループ (ダイヤルピア 301 のサーバーグループ 301) をポイントして、例には単一ノードしか表示しませんが、複数のターゲット UCM ノードを定義します。

    外線ダイヤルピアのサーバーグループ

    DPG の複数のダイヤルピアとダイヤルピア サーバー グループの複数のサーバーでは、定義された基本設定に基づいて、すべての Unified CM 通話処理サブスクライバーまたはハント上で、通話のランダムな配布を達成できます。各サーバー グループは、最大 5 台のサーバーを持つことができます (ポートあり、またはポートなしの IPv4/v6)。5 つ以上の通話処理サブスクライバーが使用されている場合、第 2 のダイヤルピアと第 2 サーバー グループのみを必要とします。

    詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/multiple-server-groups.htmlを参照してください。

  4. 5 つ以上の Unified CM ノードがある場合、Unified CM の Webex Calling トランクに対する 2 つ目の外線ダイヤルピア。

    dial-peer voice 303 voip
    description Outgoing dial-peer to CUCM-Group-2 
    for inbound from Webex Calling - Nodes 6 to 10
    destination-pattern BAD.BAD
    session protocol sipv2
    session server-group 303
    voice-class codec 99
    dtmf-relay rtp-nte
    voice-class sip tenant 100
    no vad
  5. Unified CM の PSTN トランクに向かう送信ダイヤルピア:

    dial-peer voice 305 voip
    description Outgoing dial-peer to CUCM-Group-1for inbound from PSTN - Nodes 1 to 5
    destination-pattern BAD.BAD
    session protocol sipv2
    session server-group 305
    voice-class codec 99 
    dtmf-relay rtp-nte
    voice-class sip tenant 100
    no vad
    
  6. 5 つ以上の Unified CM ノードがある場合、Unified CM の PSTN トランクに対する 2 つ目の外線ダイヤルピア。

    dial-peer voice 307 voip
    description Outgoing dial-peer to CUCM-Group-2 for inbound from PSTN - Nodes 6 to 10
    destination-pattern BAD.BAD
    session protocol sipv2
    session server-group 307
    voice-class codec 99  
    dtmf-relay rtp-nte
    voice-class sip tenant 100
    no vad
    
5

以下の DPG を構成します。

  1. DPG 100 を定義します。発信ダイヤルピア 101 は、ダイヤルピア グループ 100 を呼び出す着信ダイヤルピアのターゲットです。Unified CM --> LGW --> PSTN パスに定義された着信ダイヤル ピア 302 に DPG 100 を適用 します。

    voice class dpg 100
    dial-peer 101 preference 1
    
  2. 発信ダイアル ピア 200201 に対する DPG 200Unified CM --> LGW --> Webex Calling パスに対して定義します。

    voice class dpg 200
    dial-peer 200201 preference 1
    
  3. 発信ダイヤルピア 301 または 303 の DPG 300 Webex Calling --> LGW --> Unified CM パスに対して定義します。

    voice class dpg 300
    dial-peer 301 preference 1
    dial-peer 303 preference 1
    
  4. 発信ダイアル ピア DPG 305 または 307 に対する 302PSTN --> LGW --> Unified CM パスに対して定義します。

    voice class dpg 302
    dial-peer 305 preference 1
    dial-peer 307 preference 1
    
6

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

  1. 着信 IP PSTN コール レッグの着信ダイヤルピア:

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

    以下は、設定のフィールドの説明です。

    dial-peer voice 100 voip
    description Incoming dial-peer from PSTN

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

    session protocol sipv2

    ダイヤルピア 100 が SIP コールのコールコールを処理する場合に指定します。

    incoming uri via 100

    VIA ヘッダーのホスト IP アドレス上で、Unified CM から LGW へのすべての着信トラフィックに対して、音声クラス uri 100 を指定します。詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr2/vcr2-cr-book/vcr-i1.html#wp7490919080を参照してください。

    destination dpg 302

    ダイヤルピアグループ 302 を 指定して 発信ダイアルピアを選択します。詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr5/vcr5-cr-book/vcr-v1.html#wp7209864940を参照してください。

    voice-class sip tenant 300

    ダイヤルピアは、ダイヤルピア自体の下で同じパラメータを定義しない限り、テナント 300 からすべてのパラメータを継承します。

  2. Webex Calling コール レッグの着信ダイヤルピア:

    dial-peer voice 200201 voip
    description Inbound/Outbound Webex Calling
    max-conn 250
    destination dpg 300
    incoming uri request 200
     

    以下は、設定のフィールドの説明です。

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

    ダイヤル ピアVoIP構成の タグを200201、管理とトラブルシューティングを容易にするための意味のある説明を行います。

    incoming uri request 200

    要求 URI の一意の dtg パターンで、Unified CM から LGW へのすべての着信トラフィックに対して音声クラス uri 200 を指定し、企業内および Webex Calling エコシステム内のローカル ゲートウェイ サイトを一意的に識別します。参照:https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr2/vcr2-cr-book/vcr-i1.html#wp7490919080

    destination dpg 300

    ダイヤルピアグループ 300 を 指定して 発信ダイアルピアを選択します。詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr5/vcr5-cr-book/vcr-v1.html#wp7209864940を参照してください。

    max-conn 250

    本ガイドで定義されているとおり、着信と発信の両方の Webex Calling に対して 1 つのダイヤル ピアがあると想定して、同時通話の数を LGW と Webex Calling の間で 250 に制限します。ローカル ゲートウェイを含む同時通話の制限の詳細は、 を参照してください https://www.cisco.com/c/dam/en/us/td/docs/solutions/PA/mcp/DEPLOYMENT_CALLING_Unified_CM_to_Webex_Calling.pdf

  3. 宛先として Webex Calling をもつ着信 Unified CM コール レッグに対する着信ダイヤルピア。

    dial-peer voice 300 voip
    description Incoming dial-peer from CUCM for Webex Calling
    session protocol sipv2
    destination dpg 200
    incoming uri via 300
    voice-class codec 99
    dtmf-relay rtp-nte
    voice-class sip tenant 300
    no vad
    

    以下は、設定のフィールドの説明です。

    dial-peer voice 300 voip
    description Incoming dial-peer from CUCM for Webex Calling

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

    incoming uri via 300

    送信元ポート (5065) で Unified CM から LGW へのすべての着信トラフィックに対して、音声クラス URI 300 を指定します。詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr2/vcr2-cr-book/vcr-i1.html#wp7490919080を参照してください。

    destination dpg 200

    ダイヤルピアグループ 200 を 指定して 発信ダイアルピアを選択します。詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr5/vcr5-cr-book/vcr-v1.html#wp7209864940を参照してください。

    voice-class sip tenant 300

    ダイヤルピアは、ダイヤルピア自体の下で同じパラメータを定義しない限り、テナント 300 からすべてのパラメータを継承します。

  4. 宛先PSTNとして PSTN をもつ着信 Unified CM コール レッグに対する着信ダイヤルピア。

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

    以下は、設定のフィールドの説明です。

    dial-peer voice 302 voip
    description Incoming dial-peer from CUCM for PSTN

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

    incoming uri via 302

    送信元ポート (5065) で Unified CM から LGW へのすべての着信トラフィックに対して、音声クラス uri 302 を指定します。詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr2/vcr2-cr-book/vcr-i1.html#wp7490919080を参照してください。

    destination dpg 100

    ダイヤルピアグループ 100 を指定して 外線ダイヤルピアを選択します。詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr5/vcr5-cr-book/vcr-v1.html#wp7209864940を参照してください。

    voice-class sip tenant 300

    ダイヤルピアは、ダイヤル ピア自体の下で同じパラメータを定義しない限り、テナント 300 からすべてのパラメータを継承します。

Unified CM PSTN トランクに IP 接続PSTNする

Webex Calling プラットフォームから Unified CM へのトランクWebex Callingする

Unified CM PSTNから IP アドレスへのPSTN

Unified CM Webex Calling と Webex Calling トランク

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

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

  2. デバイスが Cisco IOS XE 17.3.2 以上を実行している場合に、プロアクティブ通知を送信するために使用する安全なメール サーバーを構成します。

    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 

16.11.1 以上を実行しているローカル ゲートウェイ

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

  2. デバイスで 17.3.2 以前のバージョンを実行している場合は、プロアクティブ通知の送信に使用するメールサーバーを構成します。

    configure terminal 
    call-home  
    mail-server <email server> priority 1 
    end 
  3. 通知を受け取る管理者のメールアドレスで環境変数 ds_email を構成します。

    configure terminal 
    call-home  
    diagnostic-signature 
    environment ds_email <email address>
    end 

16.9.x バージョンを実行しているローカルゲートウェイ

  1. 次のコマンドを入力して、診断署名を有効にします。

    configure terminal 
    call-home reporting contact-email-addr sch-smart-licensing@cisco.com  
    end  
  2. デバイスで 17.3.2 以前のバージョンを実行している場合は、プロアクティブ通知の送信に使用するメールサーバーを構成します。

    configure terminal 
    call-home  
    mail-server  <email server> priority 1 
    end 
  3. 通知を受け取る管理者のメールアドレスで環境変数 ds_email を構成します。

    configure terminal 
    call-home  
    diagnostic-signature 
    environment ds_email <email address> 
    end 

Cisco IOS XE 17.3.2 で実行中のローカル ゲートウェイの構成の例を示します。Gmail を安全な SMTP サーバーとして使用して tacfaststart@gmail.com にプロアクティブ通知を送信します。

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 1.3.6.1.4.1.9.2.1.56 を使用して 5 秒間の CPU 使用率を追跡します。使用率が 75% 以上に達すると、すべてのデバッグを無効にし、ローカル ゲートウェイにインストールされている診断署名をアンインストールします。下記の手順を実行して署名をインストールします。

  1. コマンドを使用して 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@<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 がアンインストールされます。必要な場合、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@<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-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@<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-home 診断署名を使用して、を使用して署名が正常にインストールされたことを確認します。状態の列には「登録済み」の値が必要です。

診断署名をインストールして問題のトラブルシューティングを行う

診断署名 (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. 収集された診断データが ds_fsurl_prefix アップロードされる Cisco TAC ファイルサーバーパス (cxd.cisco.com) である、追加の DS 環境変数を設定します。ファイルの場所 のユーザー名はケース番号であり、パスワードは次のコマンドの 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-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@<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 

    ダウンロードされた 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 診断署名 統計の出力は、診断署名が関心のあるイベントを検出してアクションを実行したかどうかを検証するための最適な方法です。「トリガーされた/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

診断署名通知メール送信されるコマンドには、問題の種類、デバイスの詳細、ソフトウェア バージョン、実行構成、与えられた問題のトラブルシューティングに関連するコマンド出力の表示など、重要な情報が含まれている必要があります。

診断署名をアンインストールする

トラブルシューティングのために診断署名を使用は、一般的に、いくつかの問題が発生した場合の検出後にアンインストールするために定義されます。署名を手動でアンインストールする場合、show call-home diagnostic-signature の出力から DS ID を取得し、以下のコマンドを実行します。

call-home diagnostic-signature deinstall <DS ID> 

例:

call-home diagnostic-signature deinstall 64224 

診断署名検索ツールに定期的に新しい署名が追加されます。これは展開で一般的に見られる問題に基づいて行います。TAC では現在、新しいカスタム署名の作成リクエストをサポートしていません。

始める前に

  • 構成する次の基準プラットフォーム設定が、組織のポリシーと手順に従って設定されていないことを確認してください。

    • NTP

    • Acl

    • パスワードを有効にする

    • プライマリパスワード

    • IP ルーティング

    • IP アドレスなど

  • すべてのローカル ゲートウェイの展開に対して、IOS XE 17.6 のサポートされている最低のリリースが必要です。

1

任意のレイヤー 3 インターフェースに、有効でアクセス可能な IP アドレスを割り当て注意してください。

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
 ip address 198.51.100.1 255.0.0.0

 
インターフェイスはWebex Calling から到達できる必要があります。

 

ローカル ゲートウェイの新しい構成FQDN/SRV Control Hub のみ設定できます。インターフェイス IP FQDN解決されるのを確認してください。

2

パスワードは、サインイン情報および共有シークレットとして使用する前に、次のコマンドを使用して、パスワードのプライマリキーを事前に構成してください。タイプ 6 のパスワードは、AES 暗号とユーザーが指定したプライマリキーを使用して暗号化されます。

conf t
key config-key password-encrypt Password123
password encryption aes
3

IP ネームサーバーを設定して DNS 検索を有効にします。IP Name Server を Ping してサーバーに到達可能な環境を確認してください。ローカル ゲートウェイは、この DNS をWebex Calling プロキシ アドレスを解決する必要があります。

conf t
Enter configuration commands, one per line. End with CNTL/Z. 
ip name-server 8.8.8.8
end
4

TLS 1.2 排他性とデフォルトのプレースホルダー Trustpoint の有効化:


 
  • 署名され信頼できる CA 証明書を認識する必要があります。

  • SIP リクエスト メッセージの [連絡先ヘッダー URI] 内のドメイン (例:招待、オプション) は、TLS 接続を確立するために SAN 証明書に存在する必要があります。

  1. 以下のコマンドで、証明書の長さと一ルート証明書 RSA キーを作成します。

    crypto key generate rsa general-keys exportable label my-cube modulus 4096
  2. 以下のコマンドを使用して、CA 署名付き証明書を保持するトラストポイントを作成します。

    crypto pki trustpoint CUBE_CA_CERT
     enrollment terminal pem
     serial-number none
     subject-name CN=my-cube.domain.com (this has to match the router’s hostname  [hostname.domain.name])
     revocation-check none
     rsakeypair TestRSAkey !(this has to match the RSA key you just created)
  3. 次のコマンドを使用して証明書署名リクエスト (CSR) を生成します。

    crypto pki enroll CUBE_CA_CERT

     
    • この CSR を使用して、サポートされている認証局の 1 つから証明書をリクエストします。

    • コントロール ハブで設定したトランクFQDNおよびルート SRV) が証明書の SAN に存在するか確認します。

5

中間 CA ルート証明書場合、次のコマンドを実行します。


 

中間証明がない場合、ステップ 6 に 進みます

crypto pki trustpoint Root_CA_CERT
 enrollment terminal
 revocation-check none
!
crypto pki authenticate Root_CA_CERT
<paste root CA X.64 based certificate here >

crypto pki trustpoint Intermediate_CA
 enrollment terminal
 chain-validation continue Root_CA_CERT
 revocation-check none
!
crypto pki authenticate Intermediate_CA
<paste Intermediate CA X.64 based certificate here >

crypto pki authenticate CUBE_CA_CERT 
<paste Intermediate CA X.64 based certificate here >


crypto pki import CUBE_CA_CERT certificate
<paste CUBE  CA X.64 based certificate here >
6

トラストポイントを作成してポイントを保留ルート証明書。中間 CA がない場合、次のコマンドを実行します。

crypto pki trustpoint Root_CA_CERT
enrollment terminal
revocation-check none
!
crypto pki authenticate Root_CA_CERT
<paste root CA X.64 based certificate here >

crypto pki authenticate CUBE_CA_CERT 
<paste root  CA X.64 based certificate here >

crypto pki import CUBE_CA_CERT certificate
<paste CUBE  CA X.64 based certificate here >

7

作成したトラストポイントを使用するために、SIP-UA を設定します。

configure terminal
sip-ua
crypto signaling default trustpoint CUBE_CA_CERT
transport tcp tls v1.2

始める前に

  • システムへ送信される Webex Calling 、パブリック IPv4 アドレスを使用する必要があります。完全修飾ドメイン名 (FQDN) またはサービスレコード (SRV) アドレスは、インターネット上のパブリック IPv4 アドレスに解決する必要があります。

  • 外部インターフェース上のすべての SIP およびメディアポートはインターネットからアクセス可能である必要があります。ポートはネットワーク アドレス変換 (NAT) の背後に置く必要があります。エンタープライズ ネットワーク コンポーネントでファイアウォールを更新してください。

  • ローカル ゲートウェイに署名済み証明書をインストールします。

    • 認証局 (CA) は、 音声およびビデオ プラットフォームへの通話をサポートしているルート証明機関Cisco Webex証明書に署名する必要があります。 .

    • Control Hub FQDN選択された証明書の共通名 (CN) またはサブジェクト代替名 (SAN) である必要があります。例:

      • 組織の Control Hub から設定されたトランクがローカル ゲートウェイの london.lgw.cisco.com:5061 として FQDN である場合、CN または SAN は証明書に london.lgw.cisco.com する必要があります。  

      • 組織のコントロール ハブから設定されたトランクが、ローカル ゲートウェイの SRV アドレスとして london.lgw.cisco.com を持っている場合、CN または SAN は証明書に london.lgw.cisco.com する必要があります。クライアント アドレスが 解決SRV (CNAME、A レコード、または IP アドレス) のレコードは、SAN ではオプションです。

      • トランクにFQDN または SRV を使用する場合、ローカル ゲートウェイからのすべての新しい SIP ダイアログの連絡先アドレスは、SIP アドレスのホスト部分に london.lgw.cisco.com が入っている必要があります。構成については、 ステップ 5 を参照してください。

  • 証明書がクライアントとサーバーの使用状況に対して署名済みである必要があります。

  • 「どのルート証明機関が、音声およびビデオ プラットフォームを サポートしていますか?」で説明されている通り、信頼バンドルをローカル ゲートウェイCisco Webexアップロードします

1

ローカル ゲートウェイ アプリケーションをオンにするには、次のコマンドを入力します ( 拡張として追加する最新の IP サブネットについては、「Cisco Webex Calling のポート参照情報」を信頼リスト。

configure terminal
voice service voip
ip address trusted list
ipv4 x.x.x.x y.y.y.y
allow-connections sip to sip
no supplementary-service sip refer
no supplementary-service sip handle-replaces
fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none 
sip 
early-offer forced
asymmetric payload full

以下は、設定のフィールドの説明です。

有料不正使用の防止
voice service voip
ip address trusted list
ipv4 x.x.x.x y.y.y.y
  • ローカル ゲートウェイがユーザーやピアから 、通話の正当なVoIP期待するエンティティのソース IP アドレスWebex Calling します。

  • デフォルトで、ローカル ゲートウェイは信頼されたリストVoIPからのすべての着信および着信設定を IP アドレスからブロックします。「セッションターゲット IP」またはサーバーグループを持つダイヤルピアからの IP アドレスは、デフォルトで信頼され、ここには入力されません。

  • このリスト中の IP アドレスは、顧客が接続するデータセンター の地域的なWebex Calling IP サブネットと一致する必要があります。詳細 については、サイトのポートWebex Calling を参照してください。


     

    ローカル ゲートウェイが制限された静的 NAT を持つファイアウォールの背後にある場合、デバイスに対して向くインターフェイスで IP アドレスの信頼できるWebex Calling。ファイアウォールは、未承諾のインバウンド 通話からVoIPします。このアクションは、 Webex Calling ピアのアドレスが変更される可能性がある上に、ピアに対してファイアウォールを構成する必要があるため、長期構成のオーバーヘッドを減らします。

  • 詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr2/vcr2-cr-book/vcr-i1.html#wp3977511557を参照してください。

SIP-to-SIP 基本機能
allow-connections sip to sip
FAX プロトコル
fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none

FAX トラフィックは暗号化されませんが、FAX トランスポートに対して T.38 を有効にできます。詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr2/vcr2-cr-book/vcr-f1.html#wp3472350152を参照してください。

SIP
early-offer forced

ローカル ゲートウェイを強制的に、近隣ピアからの承認を待つ代わりに、最初の INVITE メッセージで SDP 情報を送信します。

詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr2/vcr2-cr-book/vcr-f1.htmlを参照してください。
2

「音声クラス コーデック 100」を設定します。

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

以下は、設定のフィールドの説明です。

音声クラス コーデック 100

セッションに opus と g711 (mu および a-law) コーデックの両方を許可します。希望のコーデックをすべてのダイヤルピアに適用します。詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr5/vcr5-cr-book/vcr-v1.html#wp3562947976を参照してください。

3

「音声クラスの stun-usage 100」を設定して ICE を有効にしてください。

voice class stun-usage 100 
stun usage ice lite

以下は、設定のフィールドの説明です。

音声クラス使用量 100

使用率を定義します。Unified CM 電話が 通話を別の Webex Calling電話に転送するときに音声が避け、すべての Webex Calling 対面ダイヤルピアに stun を 適用 します。

詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr5/vcr5-cr-book/vcr-v2.html#wp1961799183を参照してください。
4

「音声クラス srtp-crypto 100」を設定して、暗号化サポートを制限します。

voice class srtp-crypto 100
 crypto 1 AES_CM_128_HMAC_SHA1_80

以下は、設定のフィールドの説明です。

音声クラス srtp-暗号化 100
SHA1_80 を唯一の SRTP 暗号スイートとして指定し、SDP 内のローカル ゲートウェイが提供するオファーと応答です。 Webex Calling は SHA1_80 のみをサポートします。
5

「SIP プロファイル 100」を設定します。この例では、cube1.abc.lgwtrunking.com ゲートウェイに選択されている FQDN で、「172.x.x.x」はローカル ゲートウェイ インターフェイスの IP アドレスで、次の 2 つの値Webex Calling。

voice class sip-profiles 100
rule 10 request ANY sip-header Contact modify "172.x.x.x" "cube1.abc.lgwtrunking.com" 
rule 20 response ANY sip-header Contact modify "172.x.x.x" "cube1.abc.lgwtrunking.com" 
 

以下は、設定のフィールドの説明です。

ルール 10 からルール 20
ローカル ゲートウェイ IP アドレスを「連絡先」ヘッダーのFQDN応答メッセージのアドレスに置き換える必要があります。

これは、組織の指定されたロケーションの トランクとして使用するために、ローカル ゲートウェイWebex Calling 要件です。

詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr5/vcr5-cr-book/vcr-v1.html#wp3265081475を参照してください。
6

以下の 4 つの外線ダイヤルピアを構成します。

  1. 最初のアウトバウンドダイヤルピアをシステム向Webex Calling

    dial-peer voice 101 voip 
    description OutBound Dial peer towards Webex Calling
    destination-pattern BAD.BAD 
    session protocol sipv2
    session target dns:peering1.sipconnect-int.bcld.webex.com:5062
    session transport tcp tls
    voice-class sip rel1xx disable 
    voice-class codec 100
    voice-class stun-usage 100 
    voice-class sip profiles 100 
    voice-class sip srtp-crypto 100
    voice-class sip options-keepalive
    voice-class sip bind control source-interface GigabitEthernet 1 
    voice-class sip bind media source-interface GigabitEthernet 1 
    dtmf-relay rtp-nte
    srtp!
    以下は、設定のフィールドの説明です。
    dial-peer voice 101 voip
    description OutBound Dial peer towards Webex Calling

    101 VoIP ダイヤルピアを定義し、管理とトラブルシューティングを容易にするための意味のある説明を行います。詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr2/vcr2-cr-book/vcr-d1.html#wp2182184624を参照してください。

    destination-pattern BAD.BAD

    ダイヤルピア 101 の選択 を許可します。しかし、DPG ステートメントを使用して着信ダイヤルピアから発信ダイヤル ピア 101 を直接呼び出し、番号パターンマッチ基準をバイパスします。使用している番号は、宛先パターン CLI によって許容される英数字に基づく任意のパターンです。詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr2/vcr2-cr-book/vcr-d1.html#wp3350083587を参照してください。

    session protocol sipv2

    ダイヤルピア 101 が SIP コール のコールコールを 処理する場合に指定します。詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr4/vcr4-cr-book/vcr-s2.html#wp1960850066を参照してください。

    session target dns:peering1.sipconnect-int.bcld.webex.com:5062

    Control Hub からの宛先のターゲット FQDNし、コールレグを送信します。詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr4/vcr4-cr-book/vcr-s2.html#wp3465578841を参照してください。

    voice-class codec 100

    ダイヤルピア 101 に使用する コーデック基本設定リスト 100 を示します。詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr5/vcr5-cr-book/vcr-v1.html#wp3869826384を参照してください。

  2. アウトバウンド ダイヤル ピアの残りの部分を、ロケーションに向けてWebex Calling 。手順は手順 6a同じままですが、ダイヤル ピアには異なる「セッション ターゲット」があります。

    dial-peer voice 102 voip
    description OutBound Dial peer towards Webex Calling
    destination-pattern BAD.BAD
    session protocol sipv2
    session target dns:peering2.sipconnect-int.bcld.webex.com:5062
    session transport tcp tls
    voice-class sip rel1xx disable
    voice-class codec 100  
    voice-class stun-usage 100
    voice-class sip profiles 100
    voice-class sip srtp-crypto 100
    voice-class sip options-keepalive
    voice-class sip bind control source-interface GigabitEthernet 1
    voice-class sip bind media source-interface GigabitEthernet 1
    dtmf-relay rtp-nte
    srtp
    !
    dial-peer voice 103 voip
    description OutBound Dial peer towards Webex Calling
    destination-pattern BAD.BAD
    session protocol sipv2
    session target dns:peering3.sipconnect-int.bcld.webex.com:5062
    session transport tcp tls
    voice-class sip rel1xx disable
    voice-class codec 100  
    voice-class stun-usage 100
    voice-class sip profiles 100
    voice-class sip srtp-crypto 100
    voice-class sip options-keepalive
    voice-class sip bind control source-interface GigabitEthernet 1
    voice-class sip bind media source-interface GigabitEthernet 1
    dtmf-relay rtp-nte
    srtp
    !
    dial-peer voice 104 voip
    description OutBound Dial peer towards Webex Calling
    destination-pattern BAD.BAD
    session protocol sipv2
    session target dns:peering4.sipconnect-int.bcld.webex.com:5062
    session transport tcp tls
    voice-class sip rel1xx disable
    voice-class codec 100  
    voice-class stun-usage 100
    voice-class sip profiles 100
    voice-class sip srtp-crypto 100
    voice-class sip options-keepalive
    voice-class sip bind control source-interface GigabitEthernet 1
    voice-class sip bind media source-interface GigabitEthernet 1
    dtmf-relay rtp-nte
    srtp
     !
7

アクティブ/アクティブ モデル内のダイアル ピアに対するダイヤル ピアWebex Calling して作成します。


 

この設定は、シンガポールベースのロケーションで設定したトランクを除くすべての地域に適用されます。詳細については 、ステップ 8 を参照してください。

  1. ダイヤル ピア 101、102103104 をアウトバウンド ダイヤル ピア 100 で DPG 100 Webex Calling。DPG 100 を着信 ダイアル ピア 100 に適用して、新しいPSTN Unified CM を定義します。

voice class dpg 100
dial-peer 101 preference 1 
dial-peer 102 preference 1 
dial-peer 103 preference 1 
dial-peer 104 preference 1 
以下は、設定のフィールドの説明です。
dial-peer 101 preference 1 

発信ダイアル ピアをダイヤルピア グループ 100 に関連付け、同じ基本設定でダイヤルピア 101 、102 、103 、および 104 を設定します。詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr2/vcr2-cr-book/vcr-d1.html#wp2182184624を参照してください。

8

ダイアルピアをプライマリ/バックアップモデルの各システム向けダイヤル Webex Callingダイアルピアグループを作成します。


 

この設定は、シンガポールのロケーションで設定したトランクにのみ適用されます。

  1. ダイヤルピア グループ 100 をアウトバウンド ダイヤル ピア 101102103104 を ダイヤルWebex Calling。DPG 100 を着信 ダイアル ピア 100 に適用して、新しいPSTN Unified CM を定義します。

voice class dpg 100
dial-peer 101 preference 1 
dial-peer 102 preference 1 
dial-peer 103 preference 2 
dial-peer 104 preference 2 
以下は、設定のフィールドの説明です。
dial-peer 101 and 102 preference 1 

発信ダイヤルピアをダイヤルピア グループ 100 に関連付け、最初の基本設定としてダイヤル ピア 101 および 102 を設定します。詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr5/vcr5-cr-book/vcr-v1.html#wp7209864940を参照してください。

dial-peer 103 and 104 preference 2 

発信ダイヤルピアをダイヤルピア グループ 100 に関連付け、ダイヤル ピア 103 および 104 を第 2 の基本設定として構成します。詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr5/vcr5-cr-book/vcr-v1.html#wp7209864940を参照してください。

9

サイトからインバウンド ダイヤル ピアをWebex Calling 。着信の一致は URI リクエストに基づいて行います。

voice class uri 120 sip 
pattern cube.domain.com 
dial-peer voice 110 voip 
session protocol sipv2
session transport tcp tls
destination dpg 120
incoming uri request 120
voice-class codec 100
voice-class stun-usage 100 
voice-class sip profiles 100 
voice-class sip srtp-crypto 100
voice-class sip bind control 
source-interface GigabitEthernet1 
voice-class sip bind media 
source-interface GigabitEthernet1 
srtp!

以下は、設定のフィールドの説明です。

voice class uri 120 sip
ユーザーからの着信通話に対するマッチパターンを Webex Calling。詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr5/vcr5-cr-book/vcr-v1.html#wp3880836726を参照してください。
session transport tcp tls
TLS へのトランスポートを設定します。詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr4/vcr4-cr-book/vcr-s2.html#wp3059887680を参照してください。
destination dpg 120
ダイヤルピアグループ 120 を指定して 発信ダイアルピアを選択します。詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr5/vcr5-cr-book/vcr-v1.html#wp7209864940を参照してください。
incoming uri request 120

リクエスト URI の固有の DTG パターンで、Webex Calling からローカル ゲートウェイへのすべての着信トラフィックを一致し、エンタープライズ内および Webex Calling エコシステム内のローカル ゲートウェイ サイトを一意的に識別します。詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr2/vcr2-cr-book/vcr-i1.html#wp7490919080を参照してください。

Voice class srtp-crypto 100

SRTP 通話レグ (接続) に優先する暗号スイートを構成します。詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr5/vcr5-cr-book/vcr-v1.html#wp1731779246を参照してください。

bind control source-interface GigabitEthernet0/0/1

このインターフェイスが提供するシグナリング ソース インターフェイス用に、ソース IP アドレスWebex Calling。詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr1/vcr1-cr-book/vcr-b1.html#wp2714966862を参照してください。

bind media source-interface GigabitEthernet0/0/1

このインターフェイス上のメディアソースのソース IP アドレスを Webex Calling。詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr1/vcr1-cr-book/vcr-b1.html#wp2714966862を参照してください。

この展開では、ローカル ゲートウェイで以下の構成が必要です。

  1. 音声クラス URI—ローカル ゲートウェイで終了するさまざまなトランクのホスト IP アドレス/ポート パターンを定義できます。

    • Webex Calling LGW へ

    • PSTNの SIP トランク終端

  2. 発信ダイアルピア—LGW から インターネット テレフォニー サービス プロバイダー (ITSP) SIP トランクおよびロケーションへ発信コールWebex Calling。

  3. 音声クラス DPG—着信ダイヤルピアからターゲットの発信ダイヤルピアに呼び出し可能です。

  4. 着信ダイアルピア—ITSP およびこれらのポートからの着信コールのWebex Calling。

パートナーがホストするローカル ゲートウェイのセットアップ、またはローカルの顧客サイト ゲートウェイのいずれかの構成を使用します。参照:

1

以下の音声クラス URI を設定します。

  1. ITSP のホスト IP アドレスを定義:

    voice class uri 100 sip
      host ipv4:192.168.80.13
    
  2. エンタープライズ内のローカル ゲートウェイ サイトを固有に識別するためのパターンを定義します。ローカルゲートウェイホスト名を UNIFORM Resource Identifier (URI) 一致パターンとして使用します。

    voice class uri 200 sip
    pattern cube.domain.com
    

     

    ローカル ゲートウェイは現在、マッチ パターンのアンダースコア「_」をサポートしません。回避策として、dot "" を使用します。(任意のものを)「_」にマッチさせます。

    Received
    INVITE sip:+6531239003@awscube1a.var1-sg.lgwtrunking.com:5061;transport=tls;dtg=awscube1a.var1-sg.lgwtrunking.com SIP/2.0 
2

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

  1. IP PSTN に向かう発信ダイヤルピア:

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

    以下は、設定のフィールドの説明です。

    dial-peer voice 121 voip
     description Outgoing dial-peer to PSTN
    

    121 VoIP ダイヤル ピアを定義し、管理とトラブルシューティングを容易にするための意味のある説明をします。詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr2/vcr2-cr-book/vcr-d1.html#wp2182184624を参照してください。

    destination-pattern BAD.BAD

    ダイヤルピア 121 の選択 を許可します。しかし、この発信ダイヤルピアを DPG ステートメントを使用して受信ダイヤルピアから直接呼び出し、番号パターンマッチ基準をバイパスします。使用している番号は、宛先パターン CLI によって許容される英数字に基づく任意のパターンです。詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr2/vcr2-cr-book/vcr-d1.html#wp3350083587を参照してください。

    session protocol sipv2

    ダイヤルピア 121 が SIP コール のコールコールを 処理する場合に指定します。詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr4/vcr4-cr-book/vcr-s2.html#wp1960850066を参照してください。

    session target ipv4:192.168.80.13

    宛先のターゲット IPv4 アドレスを示し、コールレグを送信します。セッションのターゲットは ITSP の IP アドレスです。詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr4/vcr4-cr-book/vcr-s2.html#wp3465578841を参照してください。

    voice-class codec 100.

    ダイヤルピア 121 に使用するコーデック基本 設定リスト 100 を示します

    詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr5/vcr5-cr-book/vcr-v1.html#wp3869826384を参照してください。

    dtmf-relay rtp-nte

    通話レグで予想される DTMF 機能として RTP-NTE (RFC2833) を定義します。詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr2/vcr2-cr-book/vcr-d2.html#wp3639536185を参照してください。

    no vad

    音声アクティブティの検出を無効にします。詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr5/vcr5-cr-book/vcr-v1.html#wp2063966724を参照してください。

  2. システムへの発信ダイアル ピアWebex Calling。設定については 、「証明書ベースのトランクを設定 する」を参照してください。

3

以下のダイヤルピア グループ (DPG) を構成します。

  1. ダイヤルピアグループ 120 を定義します。アウトバウンド ダイヤル ピア 121 は、Webex Calling-> LGW --> PSTN のターゲットです。DPG 120 を WEBEX CALLING --> LGW --> PSTN パスに対して、着信ダイアルピア 110 に適用 します。

    voice class dpg 120
    description Incoming IP PSTN to Webex Calling
    dial-peer 110 

     

    DPG 120 を Webex Calling からのインバウンド ダイヤル ピアに設定する必要があります。詳細については、「証明書ベース トランクの設定」のステップ 9 を参照してください。

4

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

  1. 着信 IP PSTN コール レッグの着信ダイヤルピア:

    dial-peer voice 122 voip
    description Incoming dial-peer from PSTN 
    session protocol sipv2
    destination dpg 100 
    incoming uri via 100 
    voice-class codec 100 
    dtmf-relay rtp-nte
    no vad
    

    以下は、設定のフィールドの説明です。

    dial-peer voice 122 voip
    description Incoming dial-peer from PSTN

    122 VoIP ダイヤル ピアを定義し、管理とトラブルシューティングを容易にするための意味のある説明を行います。詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr2/vcr2-cr-book/vcr-d1.html#wp2182184624を参照してください。

    session protocol sipv2

    ダイヤルピア 122 が SIP コール のコールコールを処理する場合に指定します。詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr4/vcr4-cr-book/vcr-s2.html#wp1960850066を参照してください。

    incoming uri via 100

    VIA ヘッダーの判断基準を IP ヘッダーと IP アドレスPSTNを定義します。ローカル ゲートウェイのコールPSTNすべての 着信 IP コールとダイヤルピア 122 をマッチします。詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr2/vcr2-cr-book/vcr-i1.html#wp7490919080を参照してください。

    destination dpg 100

    宛先 DPG 100 で、ローカル ゲートウェイで、従来の発信ダイヤルピア照合基準をバイパスします。ダイヤルピア 101,102,103,104である宛先 DPG 100 内で定義されたダイヤルピアを使って発信コールレグをセットアップします。詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr5/vcr5-cr-book/vcr-v1.html#wp7209864940を参照してください。

    no vad

    音声アクティブティの検出を無効にします。詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr5/vcr5-cr-book/vcr-v1.html#wp2063966724を参照してください。

  2. Webex Calling コール レッグの着信ダイヤルピア:

PSTNのWebex Calling :

ローカル ゲートウェイのすべての着信 IP PSTNとダイヤルピア 122 の呼び出し足を一致 して、IP アドレスの IP アドレスを持つ VIA ヘッダーのPSTN基準を定義します。DPG 100 は発信ダイヤル ピア 101102103104 を呼び出します。これは、Webex Calling サーバーをターゲット宛先として持っています。

Webex CallingのPSTN:

ローカル ゲートウェイ のすべての着信 Webex Calling 呼び出し足をダイアルピア 110 と一致して、ローカル ゲートウェイ展開固有の URI ヘッダー パターンの要求の基準をローカル ゲートウェイホスト名と一致します。DPG 120 は 発信ダイ アルピア 121を呼び出します。これは、IP PSTN IP アドレスをターゲット宛先として持っています。

この展開では、ローカル ゲートウェイで以下の構成が必要です。

  1. 音声クラス URI—LGW を終了するさまざまなトランクのホスト IP アドレス/ポートのパターンを定義できます。

    • この宛先用の Unified CM から LGW PSTNします。

    • この宛先用の Unified CM から LGW Webex Callingする

    • Webex Calling LGW 宛先へ

    • PSTNの SIP トランク終端

  2. 音声クラス サーバー グループ—以下から、送信トランクの IP アドレスまたはポートをターゲットにできます。

    • LGW から Unified CM へ

    • LGW から Webex Calling

    • LGW を使って SIP PSTN接続する

  3. 発信ダイアルピア—次から発信コールの呼び出しをルートできます。

    • LGW から Unified CM へ

    • インターネット テレフォニー サービス プロバイダー (ITSP) SIP トランク

    • Webex Calling

  4. 音声クラス dpg—インバウンド ダイヤル ピアから発信ダイヤル ピアを呼び出すターゲットが可能です。

  5. 着信ダイヤルピア—Unified CM、ITSP、および Webex Calling からの着信コールを受 け付Webex Calling

1

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

  1. ITSP のホスト IP アドレスを定義します。

    voice class uri 100 sip
    host ipv4:192.168.80.13
    
  2. エンタープライズ内のローカル ゲートウェイ サイトを固有に識別するためのパターンを定義します。必要な Uniform Resource Identifier (URI) 一致パターンとしてローカル ゲートウェイホスト名を使用します。

    voice class uri 200 sip
    pattern cube.domain.com

     

    ローカル ゲートウェイは現在、マッチ パターンのアンダースコア「_」をサポートしません。回避策として、dot "" を使用します。(任意のものを)「_」にマッチさせます。

    Received
    INVITE sip:+6531239003@awscube1a.var1-sg.lgwtrunking.com:5061;transport=tls;dtg=awscube1a.var1-sg.lgwtrunking.com SIP/2.0 
  3. Webex Calling トランクの Unified CM シグナリング VIA ポートを定義します。

    voice class uri 300 sip
    pattern :5065
    
  4. Unified CM 送信元シグナリング IP および VIA ポートを、以下のトランクにPSTNします。

    voice class uri 302 sip
    pattern 192.168.80.60:5060
    
2

以下の音声クラス サーバー グループを設定:

  1. Unified CM グループ 1 (5 ノード) に対して、Unified CM トランクのターゲットホスト IP アドレスとポート番号を定義します。Unified CM は Webex Calling トランク (Webex Calling <->LGW --> Unified CM) の着信トラフィックに対してポート 5065 を使用します。

    voice class server-group 301
    ipv4 192.168.80.60 port 5065
    
  2. 適宜、Unified CM トランクのターゲット ホスト IP アドレスと Unified CM Group 1 のポート番号を定義します。

    voice class server-group 303
    ipv4 192.168.80.60 port 5065
    
  3. Unified CM Group 1 (5 ノード) に対する Unified CM トランクのターゲット ホスト IP アドレスを定義します。Unified CM は PSTN トランクで着信トラフィックに対してデフォルトのポート 5060 を使用します。ポート番号を指定しない場合は、デフォルトの 5060 ポートを使用します。(PSTN <-> LGW --> Unified CM)</->

    voice class server-group 305
    ipv4 192.168.80.60
    
  4. 適宜、Unified CM Group 2 に対する Unified CM トランクのターゲット ホスト IP アドレスを定義します。

    voice class server-group 307
    ipv4 192.168.80.60
    
3

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

  1. IP PSTN に向かう発信ダイヤルピア:

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

    以下は、設定のフィールドの説明です。

    dial-peer voice 121 voip
    description Outgoing dial-peer to PSTN

    121 VoIPダイヤル ピアを定義し、管理とトラブルシューティングを容易にするための意味のある説明をします。詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr2/vcr2-cr-book/vcr-d1.html#wp2182184624を参照してください。

    destination-pattern BAD.BAD

    ダイヤル ピア 121 の選択 を許可します。しかし、この発信ダイヤル ピアを DPG ステートメントを使用してインバウンド ダイヤル ピアから直接呼び出し、番号パターンマッチ基準をバイパスします。当社は、宛先パターン CLI によって許可される英数字に基づく任意のパターンを使用しています。詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr2/vcr2-cr-book/vcr-d1.html#wp3350083587を参照してください。 session protocol sipv2

    ダイヤルピア 121 が SIP コール のコールコールを 処理する場合に指定します。

    session target ipv4:192.168.80.13

    宛先のターゲット IPv4 アドレスを指定してコールレグを送信します。(この場合、ITSP の IP アドレス)詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr4/vcr4-cr-book/vcr-s2.html#wp1960850066を参照してください。

    voice-class codec 100

    ダイヤルピア 121 に使用するコーデック設定リスト 100 を示します

    詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr5/vcr5-cr-book/vcr-v1.html#wp3869826384を参照してください。

  2. アウトバウンド ダイアルピア (Webex Calling :

    dial-peer voice 200201 voip
    description Outgoing dial-peer to Webex Calling
    destination-pattern BAD.BAD
    session protocol sipv2
    session target dns:peering1.sipconnect-int.bcld.webex.com:5062
    session transport tcp tls
    voice-class sip rel1xx disable
    voice-class codec 100  
    voice-class stun-usage 100
    voice-class sip profiles 100
    voice-class sip srtp-crypto 100
    voice-class sip options-keepalive
    voice-class sip bind control source-interface GigabitEthernet 1
    voice-class sip bind media source-interface GigabitEthernet 1
    dtmf-relay rtp-nte
    srtp
    !
    
    dial-peer voice 200202 voip
    description Outgoing dial-peer to Webex Calling
    destination-pattern BAD.BAD
    session protocol sipv2
    session target dns:peering2.sipconnect-int.bcld.webex.com:5062
    session transport tcp tls
    voice-class sip rel1xx disable
    voice-class codec 100  
    voice-class stun-usage 100
    voice-class sip profiles 100
    voice-class sip srtp-crypto 100
    voice-class sip options-keepalive
    voice-class sip bind control source-interface GigabitEthernet 1
    voice-class sip bind media source-interface GigabitEthernet 1
    dtmf-relay rtp-nte
    srtp
    !
    
    dial-peer voice 200203 voip
    description Outgoing dial-peer to Webex Calling
    destination-pattern BAD.BAD
    session protocol sipv2
    session target dns:peering3.sipconnect-int.bcld.webex.com:5062
    session transport tcp tls
    voice-class sip rel1xx disable
    voice-class codec 100  
    voice-class stun-usage 100
    voice-class sip profiles 100
    voice-class sip srtp-crypto 100
    voice-class sip options-keepalive
    voice-class sip bind control source-interface GigabitEthernet 1
    voice-class sip bind media source-interface GigabitEthernet 1
    dtmf-relay rtp-nte
    srtp
    !
    
    dial-peer voice 200204 voip
    description Outgoing dial-peer to Webex Calling
    destination-pattern BAD.BAD
    session protocol sipv2
    session target dns:peering4.sipconnect-int.bcld.webex.com:5062
    session transport tcp tls
    voice-class sip rel1xx disable
    voice-class codec 100  
    voice-class stun-usage 100
    voice-class sip profiles 100
    voice-class sip srtp-crypto 100
    voice-class sip options-keepalive
    voice-class sip bind control source-interface GigabitEthernet 1
    voice-class sip bind media source-interface GigabitEthernet 1
    dtmf-relay rtp-nte
    srtp
    !
    

    以下は、設定のフィールドの説明です。

    dial-peer voice 200201 voip
    description Outgoing dial-peer to Webex Calling

    200201、200202、200203、200204 のタグを使用して VoIP ダイヤルピアを定義し、管理とトラブルシューティングを容易にするための重要な説明を提供します。

    voice-class stun-usage 100

    ローカルに生成された stun リクエストをネゴシエートされたメディアパス上で送信します。Stun によりファイアウォールのピンホールが開きます。

    srtp

    コールレグの SRTP を有効にする。

  3. Unified CM のクライアント トランクへの発信 ダイ Webex Callingピア:

    dial-peer voice 301 voip
    description Outgoing dial-peer to CUCM-Group-1 for inbound from Webex Calling - Nodes 1 to 5
    destination-pattern BAD.BAD
    session protocol sipv2
    session server-group 301
    voice-class codec 100
    dtmf-relay rtp-nte
    no vad
    

    以下は、設定のフィールドの説明です。

    dial-peer voice 301 voip
    description Outgoing dial-peer to CUCM-Group-1 for inbound from Webex Calling – Nodes 1 to 5

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

    session server-group 301

    例には単一ノードのみ表示しますが、複数 Unified CM ノード (ダイヤルピア 301 のサーバーグループ 301) のセッションターゲットを定義します。

    送信ダイヤル ピアのサーバー グループ

    DPG 内の複数のダイヤルピアおよびダイヤルピア サーバー グループ内の複数のサーバーを使用して、定義された基本設定に基づいて、すべての Unified CM 通話処理サブスクライバーに対して通話のランダム配布を行います。各サーバー グループは、最大 5 台のサーバーを持つことができます (ポートあり、またはポートなしの IPv4/v6)。5 つ以上の通話処理サブスクライバに対し、第 2 のダイヤルピアおよび第 2 サーバー グループのみ使用できます。

    詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/multiple-server-groups.htmlを参照してください。

  4. 5 つ以上の Unified CM ノードがある場合、Unified CM の Webex Calling トランクに対する 2 つ目の外線ダイヤルピア。

    dial-peer voice 303 voip
    description Outgoing dial-peer to CUCM-Group-2 for inbound from Webex Calling - Nodes 6 to 10
    destination-pattern BAD.BAD
    session protocol sipv2
    session server-group 303
    voice-class codec 100
    dtmf-relay rtp-nte
    no vad
  5. Unified CM の PSTN トランクに向かう送信ダイヤルピア:

    dial-peer voice 305 voip
    description Outgoing dial-peer to CUCM-Group-1 for inbound from PSTN - Nodes 1 to 5
    destination-pattern BAD.BAD
    session protocol sipv2
    session server-group 305
    voice-class codec 100 
    dtmf-relay rtp-nte
    no vad
    
  6. 5 つ以上の Unified CM ノードがある場合、Unified CM の PSTN トランクに対する 2 つ目の外線ダイヤルピア。

    dial-peer voice 307 voip
    description Outgoing dial-peer to CUCM-Group-2 for inbound from PSTN - Nodes 6 to 10
    destination-pattern BAD.BAD
    session protocol sipv2
    session server-group 307
    voice-class codec 100  
    dtmf-relay rtp-nte
    no vad
    
4

以下のダイヤルピア グループ (DPG) を構成します。

  1. DPG 121 を定義します。発信ダイアルピア 121 は、DPG 121 を呼び出す着信ダイヤルピアのターゲットです。Unified CM --> LGW --> PSTN パスに定義された着信ダイヤル ピア 302 に DPG 121 を適用 します。

    voice class dpg 121
    dial-peer 121 preference 1
    
  2. Unified CM --> LGW -- > Webex Calling パスのターゲットとして、発信ダイアルピア 200201、200202、200203、200204 を DPG 100 を定義 します。


     

    基本設定の変更が、構成されたローカル ゲートウェイの場所に基づいて行されていることを確認してください。詳細 については、「証明書ベース トランクの 設定」のステップ 7とステップ 8 を参照してください。

    voice class dpg 100
    dial-peer 200201 preference 1
    dial-peer 200202 preference 1
    dial-peer 200203 preference 1
    dial-peer 200204 preference 1
    
  3. 発信ダイヤルピア 301 または 303 の DPG 300 Webex Calling --> LGW --> Unified CM パスに対して定義します。

    voice class dpg 300
    dial-peer 301 preference 1
    dial-peer 303 preference 1
    
  4. 発信ダイアル ピア DPG 305 または 307 に対する 302PSTN --> LGW --> Unified CM パスに対して定義します。

    voice class dpg 302
    dial-peer 305 preference 1
    dial-peer 307 preference 1
    
5

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

  1. 着信 IP PSTN コール レッグの着信ダイヤルピア:

    dial-peer voice 100 voip
    description Incoming dial-peer from PSTN
    session protocol sipv2
    destination dpg 302
    incoming uri via 100
    voice-class codec 100
    dtmf-relay rtp-nte
    no vad
    

    以下は、設定のフィールドの説明です。

    dial-peer voice 100 voip
    description Incoming dial-peer from PSTN

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

    session protocol sipv2

    ダイヤルピア 100 が SIP コール のコールコールを処理する場合に指定します。

    incoming uri via 100

    音声クラス uri 100 を 指定して、IP アドレスから受信 VIA ヘッダーのホスト IP アドレスのPSTN ローカル ゲートウェイからのすべての着信トラフィックを一致します。詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr2/vcr2-cr-book/vcr-i1.html#wp7490919080を参照してください。

    destination dpg 302

    ダイヤル ピア グループ 302 を指定して 外線ダイヤル ピアを選択します。詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr5/vcr5-cr-book/vcr-v1.html#wp7209864940を参照してください。
  2. Webex Calling コール レッグの着信ダイヤルピア:

    dial-peer voice 110 voip
    description Incoming dial-peer from Webex Calling  
    session protocol sipv2 
    session transport tcp tls 
    destination dpg 120 
    incoming uri request 120  
    voice-class codec 100 
    voice-class stun-usage 100 
    voice-class sip profiles 100 
    voice-class sip srtp-crypto 100 
    voice-class sip bind control source-interface GigabitEthernet1 
    voice-class sip bind media source-interface GigabitEthernet1 
    srtp 
     

    以下は、設定のフィールドの説明です。

    dial-peer voice 110 voip
    description Incoming dial-peer from Webex Calling

    110 VoIP してダイヤル ピアを更新し、管理とトラブルシューティングを容易にするための意味のある説明を行います。

    destination dpg 120

    ダイヤル ピア グループ 120 を指定して 外線ダイヤル ピアを選択します。詳細については https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr5/vcr5-cr-book/vcr-v1.html#wp7209864940 、を参照してください。

    Voice class srtp-crypto 100

    SRTP 通話レグ (接続) に優先する暗号スイートを構成します。詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr5/vcr5-cr-book/vcr-v1.html#wp1731779246を参照してください。

    bind control source-interface GigabitEthernet0/0/1

    このインターフェイスが提供するシグナリング ソース インターフェイス用に、ソース IP アドレスWebex Calling。

    詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr1/vcr1-cr-book/vcr-b1.html#wp2714966862を参照してください。

    bind media source-interface GigabitEthernet0/0/1

    このインターフェイス上のメディアソースのソース IP アドレスを Webex Calling

    詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr1/vcr1-cr-book/vcr-b1.html#wp2714966862を参照してください。

  3. 宛先として Webex Calling をもつ着信 Unified CM コール レッグに対する着信ダイヤルピア。

    dial-peer voice 300 voip
    description Incoming dial-peer from CUCM for Webex Calling
    session protocol sipv2
    destination dpg 200
    incoming uri via 300
    voice-class codec 100
    dtmf-relay rtp-nte
    no vad
    

    以下は、設定のフィールドの説明です。

    dial-peer voice 300 voip
    description Incoming dial-peer from CUCM for Webex Calling

    300 VoIP ダイヤル ピアを定義し、管理とトラブルシューティングを容易にするための意味のある説明をします。詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr2/vcr2-cr-book/vcr-d1.html#wp2182184624を参照してください。

    incoming uri via 300

    送信元ポート (5065) で Unified CM から LGW へのすべての着信トラフィックに対して、音声クラス URI 300 を指定します。詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr2/vcr2-cr-book/vcr-i1.html#wp7490919080を参照してください。

    destination dpg 200

    ダイヤルピアグループ 200 を指定して 外線ダイヤルピアを選択します。詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr5/vcr5-cr-book/vcr-v1.html#wp7209864940を参照してください。

  4. 宛先PSTNとして PSTN をもつ着信 Unified CM コール レッグに対する着信ダイヤルピア。

    dial-peer voice 302 voip
    description Incoming dial-peer from CUCM for PSTN
    session protocol sipv2
    destination dpg 100
    incoming uri via 302
    voice-class codec 100
    dtmf-relay rtp-nte
    no vad
    

    以下は、設定のフィールドの説明です。

    dial-peer voice 302 voip
    description Incoming dial-peer from CUCM for PSTN

    302 VoIP ダイヤル ピアを定義し、管理とトラブルシューティングを容易にするための意味のある説明をします。詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr2/vcr2-cr-book/vcr-d1.html#wp2182184624を参照してください。

    incoming uri via 302

    VIA ポートのロケーションで Unified CM からローカル ゲートウェイへのすべての着信トラフィックを一致PSTN音声クラス URI 300 を指定します。5060 ポートを標準 SIP ポートとして使用できます。詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr5/vcr5-cr-book/vcr-v1.html#wp3880836726を参照してください。

    destination dpg 100

    ダイヤル ピア グループ 100 を指定して 外線ダイヤル ピアを選択します。詳細については、https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr5/vcr5-cr-book/vcr-v1.html#wp7209864940を参照してください。

診断署名 (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 <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 

17.6.1 バージョンを実行しているローカル ゲートウェイ

  1. 次のコマンドを入力して診断署名を有効にします。

    configure terminal 
    call-home reporting contact-email-addr sch-smart-licensing@cisco.com  
    end  
  2. デバイスが 17.6.1 より前のバージョンを実行している場合に、プロアクティブ通知を送信するためにメール サーバーを構成します。

    configure terminal 
    call-home  
    mail-server  <email server> priority 1 
    end 
  3. 通知する管理者 ds_email のメールアドレスを使用して環境変数を設定します

    .
    
    configure terminal 
    call-home  
    diagnostic-signature 
    LocalGateway(cfg-call-home-diag-sign)environment ds_email <email address> 
    end 

次に示すのは、セキュアな SMTP サーバーとして Gmail を使用して tacfaststart@gmail.com にプロアクティブ通知を送信するために Cisco IOS XE 17.6.1 で起動するローカル ゲートウェイの構成の例を示します。


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 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@<server name or ip>/DS_64224.xml bootflash:

    フィールド名

    フィールド値

    プラットフォーム

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

    製品

    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 コマンドを使用 して、署名が正常にインストールされたことを確認します。状態の列には「登録済み」の値が必要です。

    
    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 シリーズ、または 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 を使用して、署名が正常にインストールされたことを確認します。ステータス列の値が「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. 別の DS 環境変数を ds_fsurl_prefix Cisco TAC ファイル サーバー パス (cxd.cisco.com) として設定して、診断データをアップロードします。システム内のファイルの場所はケース番号であり、パスワードは以下に示すように、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. コマンド 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 シリーズ、または 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 を使用して、署名が正常にインストールされていることを確認します。ステータス列の値が「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 名

トリガー済み/最大/アンインストール

平均実行時間(秒)

最長実行時間(秒)

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 では現在、新しいカスタム署名の作成リクエストをサポートしていません。

2022年9月30日
ローカル ゲートウェイとして CUBE のハイ アベイラビリティを実装する

ローカルゲートウェイ(LGW)は、Cisco Webex Calling 顧客にプレミスベースの PSTN アクセスを提供するための唯一のオプションです。 このドキュメントの目的は、アクティブなコールのステートフル フェールオーバーのために、CUBE のハイ アベイラビリティ、アクティブ/スタンバイ 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 の両方のプラットフォームでローカルゲートウェイを構成しています。 この設定のユーザー名とパスワードは以下のとおりです。

  • ユーザー名: 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 のパラメーターに基づき、両方のプラットフォームに適用し、保存し、リロードするローカ ルゲートウェイの構成です。 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

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#

上記の出力から、 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
2022年9月30日
Webex Calling のために Unified CM を構成する

Unified CM がオンプレミスのコール制御ソリューションである既存の展開に Webex Calling が有効なロケーションが追加される場合や、Webex Calling ロケーションの Unified CM および電話に登録されている電話間で直接ダイヤルする必要がある場合、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 のルート リストを構成する

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

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

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

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

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

次にやる必要

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

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

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

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

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

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

設定
翻訳パターン Webex の ESN 範囲の ESB パターン。 例: 80121XX
パーティション Webex
説明