Webex Calling 設定ワークフロー
Webex Calling 設定ワークフロー
2024年5月29日
Webex Calling の概要

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

Webex Calling の紹介

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

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

  • 信頼できる地域のサービス プロバイダによって配信される安全かつ信頼性のあるクラウド サービス

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

  • Webex Meetings はオプションの統合型アドオンとして、エンタープライズ ユーザーが期待するプレミアム ミーティング エクスペリエンスを提供します。

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

  • パートナーや Cisco により提供されている次のレベルのサポートにより提供される階層 1 サポート

Control HubはWebex Callingと統合したWebベースの管理ポータルで、注文と構成を合理化し、バンドルされたオファー(Webex Calling、Webex アプリ、Webex Meetings)の管理を一元化します。

表 1. 管理者が設定可能な機能

機能

説明

自動音声応答

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

コール キュー

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

コールピックアップ

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

コール パーク

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

ハントグループ

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

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

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

ページング グループ

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

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

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

表 2. ユーザー設定可能な機能

機能

説明

匿名コールの拒否

ユーザは、ブロックされた発信者 ID で着信を拒否できます。

ビジネスの継続性

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

コール転送

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

選択的コール転送

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

コール通知

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

着信待ち受け

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

応答不可

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

Office Anywhere

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

優先アラート

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

リモート オフィス

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

選択通話承諾

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

匿名通話の拒否

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

シーケンシャル リング

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

同時リング

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

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

Control Hub()は、Webex Callingと統合した管理ポータルです。これにより、注文と構成が合理化され、バンドルされたオファー(Webex Calling、Webex アプリ、Meetings)の管理が一元化されます。https://admin.webex.com

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

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

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

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

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

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

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

カスタマー管理者

Webex Callingのトライアルまたは有料サブスクリプションの顧客管理者は、ロケーション、ライセンス、電話番号、通話機能、ユーザー、ワークスペース(Webex クラウドに登録する会議室デバイス)を追加することで、Control Hubで組織をセットアップできます。 これらのすべてコンポーネントを同様にそこから管理できます。

  • この点のガイダンスについては、『Cisco Webex Calling のカスタマー設定ガイド』を参照してください。

  • Webex Calling のオファーについての詳細は、「エンドカスタマー データ シート」の「Control HubCisco コラボレーション フレックス プランの Cisco Webex Calling」を参照してください。

パートナー

パートナー サービス プロバイダーは、ブランドとマーケットを設定して、Webex Calling を顧客に販売できます。 トライアルをセットアップして、顧客にサービスを展開し、顧客にオーダーを作成してプロビジョニングすることもできます。

サービス開始日時

Webex Calling が販売可能な国については、「Cisco Webex はどこで入手可能か」という記事の「Webex Calling」の見出しを参照してください。

概要

Webex Calling には、Cisco Unified Communications Manager アーキテクチャに基づく専用のクラウド インスタンス オプションが含まれるようになりました。 専用インスタンスは Webex Calling と統合され、Webex プラットフォームサービスを利用して、集中管理と適切なクラウドイノベーションを実現し、Webex プラットフォームのどこにも開発され、通話エクスペリエンスを向上します。 専用インスタンスはまた、古い Cisco エンドポイント、または重要なビジネス ワークフローの一部である既存の統合もサポートします。

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

  • Cisco Unified Communications Manager

  • Cisco Unified IM and 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] を追加します。

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

ユーザーを支援する

ユーザーを追加し、サービスが割り当てられたので、サポートされているマルチプラットフォーム電話 (MPP) を Webex Calling および Webex アプリ でメッセージングとミーティングに使用できるようになります。 ユーザーに、アクセスのためのワンストップショップとして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 宛先と一致しない通話をローカル ゲートウェイに送信します。 これには、Webex Calling では表示できない PSTN 番号と Unified CM の内線番号が含まれます。 ローカル ゲートウェイは、Webex Calling から Unified CM に着信するすべての通話をルーティングします。その逆も同様です。 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 ダイヤルだけが含まれているわけではありません。 Webex Calling で正しいルーティングを可能にするために、コールがローカル ゲートウェイに送信される前に、+E.164 以外のダイヤル習慣を +E.164 に正規化する必要があります。

サービス クラス (CoS)

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

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

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

  • Webex Calling から Unified CM に入ってくるコール

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 の宛先をこのパーティションに追加し、最後にこの新しいパーティションを適切なコール検索スペースに追加する必要があります。

Webex Calling から Unified CM に入ってくるコール

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

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

PSTN と Webex Calling からのコールに対応する差別化された CoS

この図は、PSTN と Webex Calling からの通話に対するこれらの 2 つの異なるクラスのサービスを比較しています。 この図では、PSTN ゲートウェイ機能がローカル ゲートウェイに併置されている場合に、PSTN GW とローカル ゲートウェイを Unified CM に組み合わせることで 2 つのトランクが必要であることも示しています。 1 つは PSTN で発信されるコール用で、もう 1 つは Webex Calling で発信されるコール用です。 これは、トラフィック タイプごとに差別化されたコール検索スペースを適用するための要件により決まります。 Unified CM の 2 つの着信トランクを使用すると、各トランクで着信コールに必要なコーリング サーチ スペースを設定することで、これを簡単に実現できます。

ダイヤル プランのインテグレーション

このガイドでは、『Cisco コラボレーション オンプレミス展開 (CVD) のための優先アーキテクチャ』で説明されている、現在のベスト プラクティスに基づいた既存のインストールを想定しています。 最新バージョンは、こちらで入手できます。

推奨されるダイヤル プランの設計は、こちらで入手可能な、最新バージョンの「Cisco コラボレーション システム SRND」の「ダイヤル プラン」の章に記載されている設計アプローチに従っています。

推奨するダイヤル プラン

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

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

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

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

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

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

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

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

Webex Calling への到達可能性

Webex Calling の宛先をダイヤル プランに追加する

このダイヤル プランに Webex Calling の宛先に到達可能性を追加するには、すべての Webex Calling の宛先を表すパーティション (「Webex Calling」) を作成し、Webex Calling の各 DID 範囲の +E.164 ルート パターンをこのパーティションに追加する必要があります。 このルートパターンは、1 つのメンバーのみを持つルートリストを参照します。 Webex Calling へのコールのローカル ゲートウェイへの SIP トランクを持つルート グループ。 すべてのダイヤルされた宛先は、Unified CM 登録済みエンドポイントから発信された通話のダイヤル正規化翻訳パターンまたは PSTN から発信された通話の着信着信側トランスフォーメーションのいずれかを使用して +E.164 に正規化されるため、この単一の +E.164 ルート パターンは、使用されるダイヤル習慣とは無関係に Webex Calling の宛先の到達可能性を達成するのに十分です。

たとえば、ユーザーが「914085550165」をダイヤルすると、パーティション「UStoE164」のダイヤル正規化トランスレーション パターンが、このダイヤル文字列を「+14085550165」に正規化し、パーティション「Webex Calling」の Webex Calling 宛先のルート パターンと一致します。 Unified CM は最終的、ローカル ゲートウェイにコールを送信します。

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

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

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

エンタープライズ短縮ダイヤルを Webex Calling 宛先に追加するには、Webex Calling ロケーションのそれぞれのダイヤル正規化トランスレーション パターンを「Webex Calling」パーティション(図の「8101XX」など)に追加します。 正規化後、「Webex Calling」パーティションのルート パターンに一致した後、再びコールが Webex Calling に送信されます。

Webex Calling の短縮ダイヤル正規化トランスレーション パターンを「ESN」パーティションに追加することはお勧めしません。この設定により、不要なコール ルーティング ループが作成される可能性があるためです。

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

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

  • CLICKTOCALL: または CLICKTOCALL://

  • SIP: または SIP:

  • TEL: または TEL:

  • WEBEXTEL: または WEBEXTEL://

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

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

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

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

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

macOS のプロトコル ハンドラ

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

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

2024年6月11日
Webex Calling のための環境を準備する

Webex Calling のローカル ゲートウェイ要件を参照してください。 ローカル ゲートウェイは、自分のペースで Webex Calling に移行するのに役立ちます。

Webex Calling のローカル ゲートウェイの要件

一般的な前提条件

Webex Callingのローカル ゲートウェイを設定する前に、次のことを確認してください。

  • VoIP の原理についての基本的な知識があること

  • Cisco IOS-XE と IOS-XE 音声のコンセプトについて、基本的で実際的な知識があること

  • セッション開始プロトコル (SIP) の基本的な理解がある

  • 導入モデルに Cisco Unified Communications Manager (Unified CM) が含まれている場合には、Unified CM についての基本的な理解があること

詳細については、『Cisco Unified Border Element (CUBE) Enterprise Configuration Guide』を参照してください。

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

展開に「Local Gateway for Webex Calling 注文ガイドのローカル ゲートウェイ.」の表 1 にある 1 つ以上のローカル ゲートウェイ (Cisco CUBE (IP ベース接続) または Cisco IOS Gateway (TDM ベース接続)) があることを確認します。 また、「ローカル ゲートウェイ構成ガイド」に従って、プラットフォームがサポートされている IOS-XE リリースを実行しているか確認してください。

ローカル ゲートウェイのライセンスに関する要件

CUBE コールライセンスは、ローカル ゲートウェイにインストールされている必要があります。 詳細については、Cisco Unified 境界要素の構成ガイドを参照してください。

ローカル ゲートウェイの認証およびセキュリティ的要件

Webex Calling は、安全な信号経路とメディアを必要とします。 ローカルゲートウェイは暗号化を行います。また、以下の手順に従って、TLS 接続をクラウド方向に確立する必要があります。

  • LGW は、Cisco PKI からの CA ルートバンドルで更新しておく必要があります

  • LGW を構成する際には、Control Hub のトランク構成ページから取得した一連の SIP ダイジェスト資格情報が使用されます(この手順は、この後の構成の一部です)

  • CA ルート バンドルは、提示された証明書を検証します

  • 資格情報が要求されます (SIP ダイジェストにより提供されたもの)

  • クラウドは、どのローカル ゲートウェイがセキュアに登録されているかを識別します

ローカルゲートウェイのファイアウォール、NAT Traversal、メディアパス最適化の各要件

ほとんどの場合、ローカル ゲートウェイとエンドポイントは、NAT によるプライベート IP アドレスを使用して、内部の顧客ネットワークに配置することができます。 エンタープライズ ファイアウォールは、特定の IP アドレス/ポートに対する外向きトラフィック (SIP、RTP/UDP、HTTP) を許可していなければなりません。この点は、「ポート参照情報」で説明されています。

ICE でメディアパスの最適化を利用する場合、ローカルゲートウェイの Webex Calling に面しているインターフェイスには Webex Calling エンドポイントとの双方向の直接ネットワークパスが必要です。 エンドポイントが別のロケーションにあり、ローカルゲートウェイの Webex Calling に面しているインターフェイスとこのエンドポイントとの間に直接ネットワークパスがない場合、メディアパスの最適化を利用するには、ローカルゲートウェイとエンドポイント間の通話のために、Webex Calling に面しているインターフェイスに割り当てられたパブリック IP アドレスをローカルゲートウェイに設定する必要があります。 また、IOS-XE バージョン 16.12.5 を実行している必要があります。

2024年5月16日
組織のために 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

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


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

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

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

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

4

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

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


     

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

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

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

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

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

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

     

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

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

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

PSTN オプションの選択は各ロケーション レベルで行います (各ロケーションには PSTN オプションが 1 つしかありません)。 展開に対して必要な数のオプションを組み合わせることができますが、各ロケーションには 1 つのオプションとなります。 PSTN オプションを選択してプロビジョニングしたら、ロケーションの PSTN プロパティで [管理] をクリックすると、オプションを変更できます。 ただし、Cisco PSTN などの一部のオプションは、別のオプションが割り当てられた後は使用できない場合があります。 サポート ケースを開いてご相談ください。

5

番号を今すぐに有効にするか、または後で有効にするかを選択します。

6

統合されていない CCP またはプレミス ベースの PSTN を選択した場合は、電話番号をコンマ区切り値として入力し、[検証] をクリックします。

特定のロケーションのための番号が追加されます。 有効なエントリは [検証済みの番号] フィールドに移動し、無効なエントリは [番号の追加] フィールドに残り、エラー メッセージが表示されます。

番号の書式は、ロケーションの所在する国に応じ、ダイヤリングに関する地元の要件に従って定められます。 たとえば、国コードが必要な場合には、コードを付けて入力することも、コードなしで入力してからコードが自動的に先頭に追加されるようにすることもできます。

7

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

次に行うこと

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

始める前に


 

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

このロケーションに関連付けられているすべての番号は、PSTN プロバイダーに戻されることに注意してください。つまり、これらの番号は所有しなくなります。

1

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

2

クリック削除するロケーションの横にある [アクション] 列に表示されます。

3

選ぶロケーションを削除を選択し、ロケーションを削除することを確認します。

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

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


 

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

1

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

場所の隣に警告アイコンが表示されている場合は、その場所の電話番号がまだ設定されていないことを意味します。 その番号を設定するまでは、コールを受発信できません。

2

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

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


     

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

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

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

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

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

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

     

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

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

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

     

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

3

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

4

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


 

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

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

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

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

5

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

6

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


 

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


 

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

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


 

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

1

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

2

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

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

     

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


     

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

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

     

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

  • ロケーション間の内線ダイヤルを許可—組織の要件に基づいてロケーション間の内線ダイヤルをカスタマイズできます。
    • 組織にすべてのロケーションで重複する内線がない場合は、トグルを有効にします。

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

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

3

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

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

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

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

     

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

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

     

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

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

ユーザーへの影響:

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

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

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


 

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

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

始める前に

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

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

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

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

1

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

2

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

3

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


 

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

次に行うこと

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

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

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

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

1

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

2

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

3

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

4

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


 

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

5

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

次に行うこと

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

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

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

Webex サービスを試していて、トライアルから有料サブスクリプションに変更したい場合は、メールでパートナーにリクエストできます。

1

https://admin.webex.comでControl Hubにログインし、建物のアイコンを選択します。です。

2

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

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

Control Hub を使用して、Webex アプリでユーザーに表示する利用可能な通話オプションの優先度を設定できます。 シングルクリック通話を有効にすることもできます。 詳細については、「 Webexアプリ ユーザーの通話オプションを設定するを選択します。

ユーザーが発信する際に開く通話アプリケーションを制御することができます。 通話クライアントの設定を構成できます。これにはUnified CMまたはWebex CallingおよびCiscoの有料通話サービスを利用していないユーザー。 詳細については、「 通話動作を設定を選択します。

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

組織でWebex Callingを構成したら、トランクを構成してローカルゲートウェイをWebex Callingに接続できます。 SIP TLSトランスポートは、ローカル ゲートウェイとWebexクラウド間のトランクを保護します。 ローカル ゲートウェイとWebex Callingの間のメディアは、 SRTPを使用します。

概要

Webex Calling は現在、ローカル ゲートウェイの 2 つのバージョンをサポートしています。

  • ローカル ゲートウェイ

  • 政府版 Webex のローカル ゲートウェイ

  • 開始する前に、Webex Calling のプレミスベースの公衆交換電話ネットワーク (PSTN) およびローカル ゲートウェイ (LGW) の要件を理解してください。 参照先Webex Callingに対するCiscoの推奨アーキテクチャをご覧ください。

  • この記事では、既存の音声構成がない専用のローカル ゲートウェイプラットフォームが設置されていることを前提としています。 既存の PSTN ゲートウェイまたは CUBE Enterprise 展開を Webex Calling のローカル ゲートウェイ機能として使用するように変更する場合は、設定に注意してください。 変更を行うため、既存のコール フローと機能を中断しないようにしてください。


 
この手順には、個々のコマンド オプションの詳細が記載されているコマンド リファレンス ドキュメントへのリンクが含まれています。 すべてのコマンド リファレンス リンクは、 Webexマネージド ゲートウェイ コマンド リファレンス特に断らない限り (その場合、コマンドリンクはCisco IOS音声コマンド リファレンス) を選択してください。 これらのガイドはすべて、Cisco Unified Border Element コマンド リファレンスからアクセスできます。

サポートされているサードパーティ SBC の詳細については、各製品参照ドキュメントを参照してください。

ローカル ゲートウェイを構成するためのオプションが 2 つあります。 Webex Callingトランク:

  • 登録ベースのトランク

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

下のいずれかでタスクフローを使用し、登録ベースのローカル ゲートウェイまたは証明書ベースのローカル ゲートウェイローカル ゲートウェイの設定Webex Calling trunk。

さまざまなトランクタイプの詳細については、「ローカル ゲートウェイの使い方」を参照してください。 コマンドライン インターフェイス(CLI)を使用して、ローカル ゲートウェイ自体で次の手順を実行します。 セッション開始プロトコル (SIP)とトランスポート レイヤ セキュリティ (TLS) トランスポートを使用してトランクのセキュリティを確保し、 Secure Real-time Protocol (SRTP) を使用して、ローカル ゲートウェイとWebex Callingを選択します。

  • ローカル ゲートウェイとして [CUBE] を選択します。 政府版 Webex は現在、サードパーティのセッション ボーダー コントローラ (SBC) をサポートしていません。 最新のリストを確認するには、「ローカル ゲートウェイの使用を開始する」を参照してください。

  • すべての Webex for Government Local Gateways に Cisco IOS XE Dublin 17.12.1a 以降のバージョンをインストールします。
  • 政府版 Webex がサポートしているルート証明機関 (CA) のリストを確認するには、政府版 Webex の ルート証明機関を参照してください

  • 政府版 Webex のローカル ゲートウェイの外部ポート範囲の詳細については、政府版 Webex のネットワーク要件 (FedRAMP) を参照してください。

政府版 Webex のローカル ゲートウェイは以下をサポートしていません。

  • メディアパス最適化のためのSTUN/ICE-Lite

  • ファクス (T.38)

政府版 Webex の Webex Calling トランクのローカル ゲートウェイを設定するには、次のオプションを使用します。

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

証明書ベースのローカル ゲートウェイの下のタスク フローを使用して、Webex Calling トランクのローカル ゲートウェイを設定します。 証明書ベースのローカル ゲートウェイを設定する方法の詳細については、「Webex Calling 証明書ベースのトランクの設定」を参照してください。

政府版 Webex のローカル ゲートウェイをサポートするには、FIPS 準拠の GCM 暗号を設定する必要があります。 そうでない場合、コールのセットアップは失敗します。 設定の詳細については、「Webex Calling 証明書ベースのトランクの設定」を参照してください。


 
政府版 Webex は登録ベースのローカル ゲートウェイをサポートしていません。

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

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

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

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

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

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

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

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

オンプレミスの Cisco Unified Communications Manager ソリューションを Webex Calling に接続する場合、次の図に示すソリューションを構築するためのベースラインとしてシンプルな PSTN ゲートウェイ設定を使用できます。 この場合、Unified Communications Manager は、すべての PSTN および Webex Calling コールの集中ルーティングと処理を提供します。

このドキュメントでは、次の画像に示すホスト名、IP アドレス、およびインターフェイスが使用されます。

このドキュメントの残りの構成ガイダンスを使用して、ローカル ゲートウェイの設定を次のように完了します。

  • ステップ1: ルーターのベースライン接続とセキュリティを設定する

  • ステップ 2: Webex Calling トランクの設定

    必要なアーキテクチャに応じて、次のいずれかを実行します。

  • ステップ 3: SIP PSTN トランクを使用したローカル ゲートウェイの設定

  • ステップ 4: 既存の Unified CM 環境でのローカル ゲートウェイの設定

    または:

  • ステップ 3: TDM PSTN トランクを使用したローカル ゲートウェイの設定

ベースラインの設定

Webex Calling のローカル ゲートウェイとして Cisco ルータを準備する最初のステップは、プラットフォームを保護し、接続を確立するベースライン設定を構築することです。

  • すべての登録ベースのローカル ゲートウェイ展開には、Cisco IOS XE 17.6.1a 以降のバージョンが必要です。 推奨されるバージョンについては、「Cisco Software Research」ページを参照してください。 プラットフォームを検索し、提案されたリリースのいずれかを選択します。

    • ISR4000 シリーズ ルータは、Unified Communications および Security テクノロジー ライセンスの両方で設定する必要があります。

    • Catalyst Edge 8000シリーズのルーターには、ボイスカードまたはDSPが搭載されており、DNA Advantageライセンスが必要です。 ボイスカードやDSPのないルーターには、最低限のDNA Essentialsライセンスが必要です。

  • ビジネスポリシーに従うプラットフォームのベースライン設定を構築します。 特に、以下を設定し、作業を確認します。

    • NTP

    • ACL

    • ユーザー認証とリモートアクセス

    • DNS

    • IPルーティング

    • IP アドレス

  • Webex Calling に向かうネットワークは IPv4 アドレスを使用する必要があります。

  • Cisco ルート CA バンドルをローカル ゲートウェイにアップロードします。

構成

1

次のように、有効でルーティング可能な IP アドレスをレイヤ 3 インターフェイスに割り当てます。


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

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


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

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


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

crypto pki trustpoint EmptyTP 
 revocation-check none
4

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


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

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


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

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


 

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

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

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

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

2

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

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

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


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

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

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


     

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

モード ボーダー要素

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

メディア統計

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

メディア一括統計

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

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

allow-connections sip to sip

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


 

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

スタイン

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

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

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

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

非対称ペイロード フル

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

early-offer forced

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

3

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


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

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

音声クラス コーデック 100

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


 

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

4

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


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

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

stunusageiceliteについて

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


 

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

5

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


voice class srtp-crypto 100
 crypto 1 AES_CM_128_HMAC_SHA1_80

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

音声クラス srtp-crypto 100

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

6

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


voice class uri 100 sip
 pattern dtg=Dallas1463285401_LGU

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

音声クラス uri 100 sip

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

7

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


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

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

  • ルール10~70、90

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

  • ルール80

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

8

Webex Calling トランクの設定:

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


     

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

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

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

    音声クラス テナント 100

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

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

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

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

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

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

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

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

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

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

    no remote-party-id

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

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

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

    connection-reuse

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

    srtp クリプト 100

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

    session transport tcp tls

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

    url sips

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

    error-passthru

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

    asserted-id pai

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

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

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

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

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

    no pass-thru content custom-sdp

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

    sipプロファイル 100

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

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

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

    privacy-policy passthru

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

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

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

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

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

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

    マックスコン 250

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

    destination-pattern BAD.BAD

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

    session protocol sipv2

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

    session target sip-server

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

    着信 uri リクエスト 100

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

    音声クラス コーデック 100

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

    音声クラスのstun使用 100

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

    no voice-class sip localhost

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

    音声クラス SIP テナント 100

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

    srtp

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

    no vad

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

テナント を定義した後 100 および SIP VoIP ダイヤル ピアを設定すると、ゲートウェイは Webex Calling への TLS 接続を開始します。 この時点で、アクセス SBC はその証明書をローカル ゲートウェイに提示します。 ローカル ゲートウェイは、以前に更新された CA ルート バンドルを使用して、Webex Calling アクセス SBC 証明書を検証します。 証明書が認識されると、ローカル ゲートウェイと Webex Calling アクセス SBC の間で永続的な TLS セッションが確立されます。 ローカル ゲートウェイは、このセキュアな接続を使用して Webex アクセス SBC に登録できます。 登録が認証にチャレンジされた場合:

  • レスポンスには、クレデンシャル設定のusername、password、およびrealmパラメータが使用されます。

  • sip プロファイル 100 の変更ルールは、SIPS URL を SIP に変換するために使用されます。

アクセスSBCから200 OKを受信すると、登録が成功します。

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


 

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


 

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

1

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


voice class uri 200 sip
  host ipv4:192.168.80.13

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

音声クラス uri 200 sip

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

2

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


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

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


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

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

destination-pattern BAD.BAD

着信ダイヤル ピア グループを使用して発信コールをルーティングする場合は、ダミー接続先パターンが必要です。 詳細については、次のサイトを参照してください。 Destination-pattern(インターフェイス)を選択します。

session protocol sipv2

ダイヤルピア 200 が SIP コール レッグを処理するように指定します。 詳細については、次のサイトを参照してください。 session Protocol (ダイヤル ピア)を選択します。

session target ipv4:192.168.80.13

コール レッグを送信する宛先のターゲットIPv4アドレスを示します。 ここでのセッション ターゲットは ITSP のIPアドレスです。 詳細については、セッションターゲット (VoIP ダイヤルピア)を参照してください。

200 経由で 着信 uri

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

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

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

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

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

音声クラス コーデック 100

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

dtmf-relay rtp-nte

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

no vad

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

3

ローカル ゲートウェイを Webex Calling と PSTN 間のコールのみルーティングするように設定している場合は、次のコール ルーティング設定を追加します。 Unified Communications Manager プラットフォームを使用してローカル ゲートウェイを設定する場合は、次のセクションに進みます。

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

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

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

    ダイヤルピア 100

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

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

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

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

    destination dpg 200

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

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

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


 

Unified CM で Webex Calling トランクを作成する場合は、SIP トランク セキュリティ プロファイルの設定で着信ポートを 5065 に設定してください。 これにより、ポート 5065 の着信メッセージを許可し、ローカル ゲートウェイにメッセージを送信するときに、この値を VIA ヘッダーに入力します。

1

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

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

    
    voice class uri 300 sip
     pattern :5065
    
  2. ポート経由の SIP を使用して、Unified CM を PSTN コールに分類します。

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

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

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

2

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


 

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


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

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

次のコマンドは、DNS SRV リソース レコードを作成します。 各 UCM ホストとトランクのレコードを作成します。

ip ホスト_sip._udp.pstntocucm.io srv 2 1 5060 ucmsub5.mydomain.com

_sip._udp.pstntocucm.io: SRV リソースレコード名

2: SRV リソースレコードの優先順位

1: SRV リソースレコードの重み

5060: このリソース レコードでターゲット ホストに使用するポート番号

ucmsub5.mydomain.com: リソースレコードターゲットホスト

リソースレコードのターゲットホスト名を解決するには、ローカル DNS A レコードを作成します。 例:

ip ホスト ucmsub5.mydomain.com 192.168.80.65

IPホスト: ローカル IOS XE データベースにレコードを作成します。

ucmsub5.mydomain.com: A レコードのホスト名。

192.168.80.65: ホスト IP アドレス。

SRV リソース レコードと A レコードを作成し、UCM 環境と優先コール分配戦略を反映させます。

3

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

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

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

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

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

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

    destination-pattern BAD.BAD

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

    session protocol sipv2

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

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

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

    incoming uri via 300

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

    音声クラス コーデック 100

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

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

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

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

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

    dtmf-relay rtp-nte

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

    no vad

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

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

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

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

    
    dial-peer voice 400 voip
     description UCM-PSTN trunk

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

    destination-pattern BAD.BAD

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

    session protocol sipv2

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

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

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

    URI を400 経由で着信

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

    音声クラス コーデック 100

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

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

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

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

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

    dtmf-relay rtp-nte

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

    no vad

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

4

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

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

    
    voice class dpg 100
     description Route calls to Webex Calling
     dial-peer 100
    voice class dpg 300
     description Route calls to Unified CM Webex Calling trunk
     dial-peer 300 
  2. Unified CM と PSTN の間でコールをルーティングするダイヤル ピア グループを作成します。 でDPG 200を定義する 発信ダイヤルピア 200 PSTNへ。 DPG 200 は、Unified CM から関連付けられた着信ダイヤルピアに適用されます。 同様に、Unified CM に向かって発信ダイヤルピア 400 で DPG 400 を定義します。 DPG 400 は、PSTN からの着信ダイヤルピアに適用されます。

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

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

    ダイヤルピア 100

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

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

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

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

    宛先 DPG 300

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

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

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

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

診断署名(DS)は、IOS XE ベースのローカル ゲートウェイでよく発生する問題をプロアクティブに検出し、イベントに関するメール、syslog、またはターミナルメッセージ通知を生成します。 さらに、DS をインストールして診断データ収集を自動化し、収集したデータを Cisco TAC ケースに転送して解決時間を短縮することもできます。

診断署名(DS)は、問題のトリガーイベントと問題を通知、トラブルシューティング、および修正するために取られるアクションに関する情報を含む XML ファイルです。 syslog メッセージ、SNMP イベント、および特定の show コマンド出力の定期的なモニタリングを使用して、問題検出ロジックを定義できます。

アクション タイプには、次の show コマンド出力の収集が含まれます。

  • 統合ログファイルを生成する

  • HTTPS、SCP、FTP サーバなどのユーザー提供のネットワークロケーションにファイルをアップロードします。

TAC エンジニアは DS ファイルを作成し、整合性保護のためデジタル署名します。 各 DS ファイルには、システムによって割り当てられた固有の数値 ID があります。 Diagnostic Signatures Lookup ツール(DSLT)は、さまざまな問題の監視とトラブルシューティングに適切な署名を見つけるための単一の情報源です。

開始する前に:

  • ダウンロードした DS ファイルは編集しないでください。 DSLTを選択します。 変更したファイルは、整合性チェックエラーのためインストールに失敗します。

  • ローカル ゲートウェイがメール通知を送信するために必要な Simple Mail Transfer Protocol (SMTP) サーバー。

  • メール通知にセキュアなSMTPサーバーを使用する場合は、ローカルゲートウェイで IOS XE 17.6.1 以上が実行されていることを確認してください。

前提条件

IOS XE 17.6.1a 以降を実行しているローカル ゲートウェイ

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

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

    configure terminal 
    call-home  
    mail-server <username>:<pwd>@<email server> priority 1 secure tls 
    end 
  3. 環境変数を構成しますds_emailを通知する管理者のメールアドレスを入力します。

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

以下は、Cisco IOS XE 17.6.1a 以降で実行されているローカル ゲートウェイの設定例で、プロアクティブな通知をtacfaststart@gmail.com 安全なSMTPサーバーとしてGmailを使用:


 

Cisco IOS XE Bengaluru 17.6.x 以降のバージョンを使用することをお勧めします。

call-home  
mail-server tacfaststart:password@smtp.gmail.com priority 1 secure tls 
diagnostic-signature 
environment ds_email "tacfaststart@gmail.com" 

 

Cisco IOS XE ソフトウェアで実行されるローカルゲートウェイは OAuth をサポートする一般的な Web ベースの Gmail クライアントではないため、専用の Gmail アカウント設定を構成し、デバイスからのメールを適切に処理するための専用権限を指定する必要があります。

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

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

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

高いCPU使用率の監視

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

  1. を使用する SNMPを表示 コマンドで SNMP を有効にします。 有効にしない場合は、snmpサーバーマネージャ コマンド

    show snmp 
    %SNMP agent not enabled 
    
    config t 
    snmp-server manager 
    end 
    
    show snmp 
    Chassis: ABCDEFGHIGK 
    149655 SNMP packets input 
        0 Bad SNMP version errors 
        1 Unknown community name 
        0 Illegal operation for community name supplied 
        0 Encoding errors 
        37763 Number of requested variables 
        2 Number of altered variables 
        34560 Get-request PDUs 
        138 Get-next PDUs 
        2 Set-request PDUs 
        0 Input queue packet drops (Maximum queue size 1000) 
    158277 SNMP packets output 
        0 Too big errors (Maximum packet size 1500) 
        20 No such name errors 
        0 Bad values errors 
        0 General errors 
        7998 Response PDUs 
        10280 Trap PDUs 
    Packets currently in SNMP process input queue: 0 
    SNMP global trap: enabled 
    
  2. Diagnostic Signatures Lookup Tool の以下のドロップダウンオプションを使用して、DS 64224 をダウンロードします。

    フィールド名

    フィールド値

    プラットフォーム

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

    製品

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

    問題の範囲

    パフォーマンス

    問題の種類

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

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

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

    次の例は、 FTPサーバーからローカルゲートウェイにファイルをコピーする方法を示しています。

    copy ftp://user:pwd@192.0.2.12/DS_64224.xml bootflash: 
    Accessing ftp://*:*@ 192.0.2.12/DS_64224.xml...! 
    [OK - 3571/4096 bytes] 
    3571 bytes copied in 0.064 secs (55797 bytes/sec) 
    
  4. ローカルゲートウェイに DS XML ファイルをインストールします。

    call-home diagnostic-signature load DS_64224.xml 
    Load file DS_64224.xml success 
  5. イベント、登録者、出席者にすばやくアクセスするため、 call-home 診断署名の表示を実行して、署名が正常にインストールされたことを確認します。 ステータス列の値が「registered」になっているはずです。

    show call-home diagnostic-signature  
    Current diagnostic-signature settings: 
    Diagnostic-signature: enabled 
    Profile: CiscoTAC-1 (status: ACTIVE) 
    Downloading  URL(s):  https://tools.cisco.com/its/service/oddce/services/DDCEService 
    Environment variable: 
    ds_email: username@gmail.com 

    DSes をダウンロード:

    DS ID

    DS 名

    リビジョン

    ステータス

    最終更新日時(GMT+00:00)

    64224

    DS_LGW_CPU_MON75

    0.0.10

    登録済み

    2020-11-07 22:05:33


     

    トリガーされると、この署名によって、この署名そのものを含む実行中のすべての DS がアンインストールされます。 必要に応じて、DS 64224 を再インストールして、ローカル ゲートウェイでの高い CPU 使用率の監視を継続します。

SIP トランク登録のモニタリング

この DS は、 Webex Callingクラウドをもつローカルゲートウェイ SIP トランクの登録解除を 60 秒ごとにチェックします。 登録解除イベントが検出されると、メールと syslog 通知が生成され、登録解除が 2 回発生した後に DS 自体がアンインストールされます。 署名をインストールするには、以下の手順を使用します。

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

    フィールド名

    フィールド値

    プラットフォーム

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

    製品

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

    問題の範囲

    SIP-SIP

    問題の種類

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

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

    copy ftp://username:password@<server name or ip>/DS_64117.xml bootflash: 
  3. ローカルゲートウェイに DS XML ファイルをインストールします。

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

異常な通話切断の監視

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

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

    show snmp 
    %SNMP agent not enabled 
     
    
    config t 
    snmp-server manager 
    end 
    
    show snmp 
    Chassis: ABCDEFGHIGK 
    149655 SNMP packets input 
        0 Bad SNMP version errors 
        1 Unknown community name 
        0 Illegal operation for community name supplied 
        0 Encoding errors 
        37763 Number of requested variables 
        2 Number of altered variables 
        34560 Get-request PDUs 
        138 Get-next PDUs 
        2 Set-request PDUs 
        0 Input queue packet drops (Maximum queue size 1000) 
    158277 SNMP packets output 
        0 Too big errors (Maximum packet size 1500) 
        20 No such name errors 
        0 Bad values errors 
        0 General errors 
        7998 Response PDUs 
        10280 Trap PDUs 
    Packets currently in SNMP process input queue: 0 
    SNMP global trap: enabled 
    
  2. Diagnostic Signatures Lookup Tool の以下のオプションを使用して、DS 65221 をダウンロードします。

    フィールド名

    フィールド値

    プラットフォーム

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

    製品

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

    問題の範囲

    パフォーマンス

    問題の種類

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

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

    copy ftp://username:password@<server name or ip>/DS_65221.xml bootflash:
  4. ローカルゲートウェイに DS XML ファイルをインストールします。

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

問題をトラブルシューティングするための診断署名をインストールする

診断署名(DS)を使用して、問題を迅速に解決します。 特定の問題のトラブルシューティング、問題発生の検出、診断データの適切なセットの収集、およびCisco TACケースへのデータの自動転送に必要なデバッグを可能にする複数の署名をCisco TACエンジニアが作成しました。 診断署名(DS)は、問題の発生を手動で確認する必要性を排除し、断続的および一時的な問題のトラブルシューティングをはるかに容易にします。

また、 Diagnostic Signatures Lookup ツール特定の問題を自分で解決するために、適切な署名を見つけ、インストールするか、サポート契約の一部として TAC エンジニアによって推奨される署名をインストールできます。

以下の例は、「%VOICE_IEC-3-GW: CCAPI: Internal Error (call spike threshold): IEC=1.1.181.1.29.0」の syslog 発生を検出し、以下のステップを使用して診断データ収集を自動化します。

  1. 追加の DS 環境変数を構成しますds_fsurl_prefix収集された診断データがアップロードされるCisco TACファイルサーバーパス (cxd.cisco.com) です。 ファイルパス内のユーザ名はケース番号で、パスワードはファイル アップロード トークンです。これはサポートケースマネージャーを次のコマンドで実行できます。 必要に応じて、サポートケースマネージャの [添付] セクションでファイルアップロードトークンを生成できます。

    configure terminal 
    call-home  
    diagnostic-signature 
    LocalGateway(cfg-call-home-diag-sign)environment ds_fsurl_prefix "scp://<case number>:<file upload token>@cxd.cisco.com"  
    end 

    例:

    call-home  
    diagnostic-signature 
    environment ds_fsurl_prefix " environment ds_fsurl_prefix "scp://612345678:abcdefghijklmnop@cxd.cisco.com"  
  2. SNMP がSNMPを表示 コマンド 有効になっていない場合は、snmpサーバーマネージャ コマンド

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

    フィールド名

    フィールド値

    プラットフォーム

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

    製品

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

    問題の範囲

    パフォーマンス

    問題の種類

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

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

    フィールド名

    フィールド値

    プラットフォーム

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

    製品

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

    問題の範囲

    Syslog

    問題の種類

    Syslog - %VOICE_IEC-3-GW: CCAPI: Internal Error (Call spike threshold): IEC=1.1.181.1.29.0

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

    copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash: 
    copy ftp://username:password@<server name or ip>/DS_65095.xml bootflash: 
  6. ローカルゲートウェイに、高 CPU モニタリング DS 64224、DS 65095 XML ファイルの順にインストールします。

    call-home diagnostic-signature load DS_64224.xml 
    Load file DS_64224.xml success 
     
    call-home diagnostic-signature load DS_65095.xml 
    Load file DS_65095.xml success 
    
  7. 署名が正常にインストールされたことを確認してください。 call-home 診断署名の表示します。 ステータス列の値が「registered」になっている必要があります。

    show call-home diagnostic-signature  
    Current diagnostic-signature settings: 
    Diagnostic-signature: enabled 
    Profile: CiscoTAC-1 (status: ACTIVE) 
    Downloading  URL(s):  https://tools.cisco.com/its/service/oddce/services/DDCEService 
    Environment variable: 
               ds_email: username@gmail.com 
               ds_fsurl_prefix: scp://612345678:abcdefghijklmnop@cxd.cisco.com 

    ダウンロードされた DSes:

    DS ID

    DS 名

    リビジョン

    ステータス

    最終更新日時(GMT+00:00)

    64224

    00:07:45

    DS_LGW_CPU_MON75

    0.0.10

    登録済み

    2020 年 11 月 08 日

    65095

    00:12:53

    DS_LGW_IEC_Call_spike_threshold

    0.0.12

    登録済み

    2020 年 11 月 08 日

診断署名の実行を確認する

次のコマンドでは、[状態] 列のcall-home 診断署名の表示ローカル ゲートウェイが署名内で定義されたアクションを実行している間、コマンドは「実行中」に変わります。 出力は次のとおりですCall-home 診断署名統計の表示は、診断署名が対象イベントを検出してアクションを実行するかどうかを検証するための最適な方法です。 [Triggered/Max/Deinstall] 列には、指定した署名がイベントをトリガーした回数、定義済みのイベント最大検出回数、トリガーされたイベントの検出後に署名がアンインストールされるかどうかが表示されます。

show call-home diagnostic-signature  
Current diagnostic-signature settings: 
Diagnostic-signature: enabled 
Profile: CiscoTAC-1 (status: ACTIVE) 
Downloading  URL(s):  https://tools.cisco.com/its/service/oddce/services/DDCEService 
Environment variable: 
           ds_email: carunach@cisco.com 
           ds_fsurl_prefix: scp://612345678:abcdefghijklmnop@cxd.cisco.com 

ダウンロードされた DSes:

DS ID

DS 名

リビジョン

ステータス

最終更新日時(GMT+00:00)

64224

DS_LGW_CPU_MON75

0.0.10

登録済み

2020-11-08 00:07:45

65095

DS_LGW_IEC_Call_spike_threshold

0.0.12

実行中

2020-11-08 00:12:53

Call-home 診断署名統計の表示

DS ID

DS 名

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

平均実行時間(秒)

最長実行時間(秒)

64224

DS_LGW_CPU_MON75

0/0/N

0.000

0.000

65095

DS_LGW_IEC_Call_spike_threshold

1/20/Y

23.053

23.053

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

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

トラブルシューティング目的で診断署名を使用する場合、通常、診断署名はいくつかの問題の発生が検出された後にアンインストールするように定義されます。 署名を手動でアンインストールする場合は、コールホーム診断署名を表示コマンドを実行し、次のコマンドを実行します。

call-home diagnostic-signature deinstall <DS ID> 

例:

call-home diagnostic-signature deinstall 64224 

 

展開でよく見られる問題に基づいて、Diagnostics Signatures Lookup Tool に新しい署名が定期的に追加されます。 TAC では現在、新しいカスタム署名の作成リクエストをサポートしていません。

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

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

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

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

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

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

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

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

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

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

オンプレミスの Cisco Unified Communications Manager ソリューションを Webex Calling に接続する場合、次の図に示すソリューションを構築するためのベースラインとしてシンプルな PSTN ゲートウェイ設定を使用できます。 この場合、Unified Communications Manager は、すべての PSTN および Webex Calling コールの集中ルーティングと処理を提供します。

このドキュメントでは、次の画像に示すホスト名、IP アドレス、およびインターフェイスが使用されます。 オプションは、パブリックまたはプライベート(NATの背後)アドレッシングに提供されます。 SRV DNS レコードは、複数の CUBE インスタンス間でロードバランシングされない限り、オプションです。

このドキュメントの残りの構成ガイダンスを使用して、ローカル ゲートウェイの設定を次のように完了します。

  • ステップ1: ルーターのベースライン接続とセキュリティを設定する

  • ステップ 2: Webex Calling トランクの設定

    必要なアーキテクチャに応じて、次のいずれかを実行します。

  • ステップ 3: SIP PSTN トランクを使用したローカル ゲートウェイの設定

  • ステップ 4: 既存の Unified CM 環境でのローカル ゲートウェイの設定

    または:

  • ステップ 3: TDM PSTN トランクを使用したローカル ゲートウェイの設定

ベースラインの設定

Webex Calling のローカル ゲートウェイとして Cisco ルータを準備する最初のステップは、プラットフォームを保護し、接続を確立するベースライン設定を構築することです。

  • すべての証明書ベースのローカル ゲートウェイ展開には、Cisco IOS XE 17.9.1a 以降のバージョンが必要です。 推奨されるバージョンについては、「Cisco Software Research」ページを参照してください。 プラットフォームを検索し、提案されたリリースのいずれかを選択します。

    • ISR4000 シリーズ ルータは、Unified Communications および Security テクノロジー ライセンスの両方で設定する必要があります。

    • Catalyst Edge 8000シリーズのルーターには、ボイスカードまたはDSPが装備されており、DNA Essentialsのライセンスが必要です。 ボイスカードやDSPのないルーターには、最低限のDNA Essentialsライセンスが必要です。

    • 大容量の要件については、High Security(HSEC)ライセンスおよび追加のスループットエンタイトルメントが必要になる場合があります。

      詳細については、認証コードを参照してください。

  • ビジネスポリシーに従うプラットフォームのベースライン設定を構築します。 特に、以下を設定し、作業を確認します。

    • NTP

    • ACL

    • ユーザー認証とリモートアクセス

    • DNS

    • IPルーティング

    • IP アドレス

  • Webex Calling に向かうネットワークは IPv4 アドレスを使用する必要があります。 ローカル ゲートウェイの完全修飾ドメイン名(FQDN)またはサービス レコード(SRV)アドレスは、インターネット上のパブリック IPv4 アドレスに解決する必要があります。

  • Webex に面しているローカル ゲートウェイ インターフェイスのすべての SIP ポートとメディア ポートは、直接または静的 NAT 経由でインターネットからアクセスできる必要があります。 それに応じてファイアウォールを更新してください。

  • 署名付き証明書をローカル ゲートウェイにインストールします (詳細な設定手順は次のとおりです)。

    • Cisco Webex 音声およびビデオ プラットフォームへの通話でサポートされているルート認証局とはに詳述されているパブリック認証局 (CA) は、デバイス証明書に署名する必要があります。

    • トランクの作成時に Control Hub で設定された FQDN は、ルータの共通名(CN)またはサブジェクト代替名(SAN)の証明書である必要があります。 例:

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

      • 組織の Control Hub で設定されたトランクが、トランクから到達可能なローカル ゲートウェイの SRV アドレスとして LGWS.LGW.COM を持っている場合、ルータ証明書の CN または SAN には lgws.lgw.com が含まれている必要があります。 SRV アドレスが解決されるレコード(CNAME、レコード、またはIPアドレス)は、SAN ではオプションです。

      • トランクに FQDN または SRV を使用するかどうかにかかわらず、ローカル ゲートウェイからのすべての新しい SIP ダイアログの連絡先アドレスは、Control Hub で設定された名前を使用します。

  • 証明書がクライアントとサーバで使用されていることを確認します。

  • Cisco ルート CA バンドルをローカル ゲートウェイにアップロードします。

構成

1

次のように、有効でルーティング可能な IP アドレスをレイヤ 3 インターフェイスに割り当てます。


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

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


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

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

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

    crypto key generate rsa general-keys exportable label lgw-key modulus 4096
  2. 次の設定コマンドを使用して、署名済み証明書のトラストポイントを作成します。

    
    crypto pki trustpoint LGW_CERT
     enrollment terminal pem
     fqdn cube1.lgw.com
     subject-name cn=cube1.lgw.com
     subject-alt-name cube1.lgw.com
     revocation-check none
     rsakeypair lgw-key
  3. 次の exec または configuration コマンドを使用して証明書署名リクエスト(CSR)を生成し、サポートされている CA プロバイダーから署名済み証明書を要求するために使用します。

    crypto pki enroll LGW_CERT
4

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


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

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


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

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


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

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


 

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

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

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

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


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

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


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

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


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

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

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

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

モード ボーダー要素

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

allow-connections sip to sip

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


 

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

スタイン

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


 
これらのグローバル スタンコマンドは、NAT の後ろにローカル ゲートウェイを展開する場合にのみ必要です。
  • コールをWebex Callingユーザ(たとえば、着信側と発信側の両方がWebex Callingメディアをアンカーする場合はWebex Calling SBC)、ピンホールが開いていないため、メディアはローカル ゲートウェイにフローしません。

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

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

非対称ペイロード フル

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

early-offer forced

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

SIP プロファイル着信

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

3

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


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

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

音声クラス コーデック 100

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


 

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

4

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


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

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

stunusageiceliteについて

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


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

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

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


voice class srtp-crypto 100
 crypto 1 AES_CM_128_HMAC_SHA1_80

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

音声クラス srtp-crypto 100

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

6

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


voice class srtp-crypto 100
crypto 1 AEAD_AES_256_GCM

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

音声クラス srtp-crypto 100

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

7

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


voice class uri 100 sip
 pattern cube1.lgw.com

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

音声クラス uri 100 sip

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

8

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


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

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

ルール10と20

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


 

ローカル ゲートウェイにパブリック IP アドレスを設定している場合は、次の手順をスキップします。

9

ゲートウェイが静的 NAT の後ろにプライベート IP アドレスで設定されている場合は、次のようにインバウンドおよびアウトバウンド SIP プロファイルを設定します。 この例では、cube1.lgw.com はローカル ゲートウェイ用に設定された FQDN で、「10.80.13.12」は Webex Calling に面したインターフェイス IP アドレス、「192.65.79.20」は NAT パブリック IP アドレスです。

Webex Callingへのアウトバウンド メッセージの SIP プロファイル

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

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

ルール10と20

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

ルール30~81

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

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

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

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

10から80までのルール

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

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

10

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


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

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

音声クラス sip-options-keepalive 100

キープアライブプロファイルを設定し、音声クラス構成モードを開始します。 エンドポイントへのハートビート接続が UP または DOWN 状態の場合、SIP アウトオブダイアログオプション Ping がダイヤルターゲットに送信される時間(秒単位)を設定できます。

このキープアライブ プロファイルは、Webex に対して設定されたダイヤル ピアからトリガーされます。

連絡先ヘッダーに SBC 完全修飾ドメイン名が含まれていることを確認するために、SIP プロファイル 115 が使用されます。 ルール 30、40、および 50 は、SBC が静的 NAT の後ろに設定されている場合にのみ必要です。

この例では、cube1.lgw.com はローカル ゲートウェイ用に選択された FQDN であり、静的 NAT が使用されている場合は、「10.80.13.12」は Webex Calling に対する SBC インターフェイス IP アドレスであり、「192.65.79.20」は NAT パブリック IP アドレスです。

11

Webex Calling トランクの設定:

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


     

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

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

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

    音声クラス テナント 100

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

    no remote-party-id

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

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

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

    srtp クリプト 100

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

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

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

    session transport tcp tls

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

    セッション更新なし

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

    error-passthru

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

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

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

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

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

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

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

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

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

    プライバシーポリシーpassthru

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

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

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

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

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

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

    destination-pattern BAD.BAD

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

    session protocol sipv2

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

    session target sip-server

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

    着信 uri リクエスト 100

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

    音声クラス コーデック 100

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

    音声クラスstun使用 100

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

    音声クラス sip asserted-id pai

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

    音声クラス sip テナント 100

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

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

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

    srtp

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

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


 

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


 

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

1

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


voice class uri 200 sip
  host ipv4:192.168.80.13

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

音声クラス uri 200 sip

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

2

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


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

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


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

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

destination-pattern BAD.BAD

着信ダイヤル ピア グループを使用して発信コールをルーティングする場合は、ダミー接続先パターンが必要です。 詳細については、次のサイトを参照してください。 Destination-pattern(インターフェイス)を選択します。

session protocol sipv2

ダイヤルピア 200 が SIP コール レッグを処理するように指定します。 詳細については、次のサイトを参照してください。 session Protocol (ダイヤル ピア)を選択します。

session target ipv4:192.168.80.13

コール レッグを送信する宛先のターゲットIPv4アドレスを示します。 ここでのセッション ターゲットは ITSP のIPアドレスです。 詳細については、セッションターゲット (VoIP ダイヤルピア)を参照してください。

200 経由で 着信 uri

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

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

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

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

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

音声クラス コーデック 100

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

dtmf-relay rtp-nte

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

no vad

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

3

ローカル ゲートウェイを Webex Calling と PSTN 間のコールのみルーティングするように設定している場合は、次のコール ルーティング設定を追加します。 Unified Communications Manager プラットフォームを使用してローカル ゲートウェイを設定する場合は、次のセクションに進みます。

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

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

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

    ダイヤルピア 100

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

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

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

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

    destination dpg 200

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

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

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

1

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

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

    
    voice class uri 300 sip
     pattern :5065
    
  2. ポート経由の SIP を使用して、Unified CM を PSTN コールに分類します。

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

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

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

2

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


 

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


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

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

次のコマンドは、DNS SRV リソース レコードを作成します。 各 UCM ホストとトランクのレコードを作成します。

ip ホスト_sip._udp.pstntocucm.io srv 2 1 5060 ucmsub5.mydomain.com

_sip._udp.pstntocucm.io: SRV リソースレコード名

2: SRV リソースレコードの優先順位

1: SRV リソースレコードの重み

5060: このリソース レコードでターゲット ホストに使用するポート番号

ucmsub5.mydomain.com: リソースレコードターゲットホスト

リソースレコードのターゲットホスト名を解決するには、ローカル DNS A レコードを作成します。 例:

ip ホスト ucmsub5.mydomain.com 192.168.80.65

IPホスト: ローカル IOS XE データベースにレコードを作成します。

ucmsub5.mydomain.com: A レコードのホスト名。

192.168.80.65: ホスト IP アドレス。

SRV リソース レコードと A レコードを作成し、UCM 環境と優先コール分配戦略を反映させます。

3

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

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

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

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

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

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

    destination-pattern BAD.BAD

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

    session protocol sipv2

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

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

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

    incoming uri via 300

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

    音声クラス コーデック 100

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

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

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

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

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

    dtmf-relay rtp-nte

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

    no vad

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

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

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

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

    
    dial-peer voice 400 voip
     description UCM-PSTN trunk

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

    destination-pattern BAD.BAD

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

    session protocol sipv2

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

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

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

    URI を400 経由で着信

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

    音声クラス コーデック 100

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

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

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

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

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

    dtmf-relay rtp-nte

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

    no vad

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

4

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

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

    
    voice class dpg 100
     description Route calls to Webex Calling
     dial-peer 100
    voice class dpg 300
     description Route calls to Unified CM Webex Calling trunk
     dial-peer 300 
  2. Unified CM と PSTN の間でコールをルーティングするダイヤル ピア グループを作成します。 でDPG 200を定義する 発信ダイヤルピア 200 PSTNへ。 DPG 200 は、Unified CM から関連付けられた着信ダイヤルピアに適用されます。 同様に、Unified CM に向かって発信ダイヤルピア 400 で DPG 400 を定義します。 DPG 400 は、PSTN からの着信ダイヤルピアに適用されます。

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

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

    ダイヤルピア 100

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

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

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

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

    宛先 DPG 300

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

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

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

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

診断署名(DS)は、 Cisco IOS XE ベースのローカル ゲートウェイでよく発生する問題をプロアクティブに検出し、イベントのメール、syslog、またはターミナル メッセージ通知を生成します。 さらに、DS をインストールして診断データ収集を自動化し、収集したデータを Cisco TAC ケースに転送して解決時間を短縮することもできます。

診断署名(DS)は、問題をトリガーしたイベントと問題を通知、トラブルシューティング、修正するアクションに関する情報を含むXMLファイルです。 syslog メッセージ、 SNMPイベント、特定の show コマンド出力の定期的なモニタリングを通じて、問題検出ロジックを定義します。 アクション タイプには、次のものが含まれます。

  • show コマンド出力の収集

  • 統合ログファイルを生成する

  • ユーザーが指定したネットワーク ロケーションへのファイルのアップロード (HTTPS、SCP、 FTPサーバーなど)

TAC エンジニアは DS ファイルを作成し、整合性保護のためデジタル署名を行います。 各 DS ファイルには、システムによって割り当てられた固有の数値IDがあります。 Diagnostic Signatures Lookup ツール(DSLT)は、さまざまな問題の監視とトラブルシューティングに適切な署名を見つけるための単一の情報源です。

開始する前に:

  • ダウンロードした DS ファイルは編集しないでください。 DSLTを選択します。 変更したファイルは、整合性チェックエラーのためインストールに失敗します。

  • ローカル ゲートウェイがメール通知を送信するために必要な Simple Mail Transfer Protocol (SMTP) サーバー。

  • メール通知にセキュアなSMTPサーバーを使用する場合は、ローカルゲートウェイで IOS XE 17.6.1 以上が実行されていることを確認してください。

前提条件

IOS XE 17.6.1 以降を実行しているローカルゲートウェイ

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

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

    
    configure terminal 
    call-home  
    mail-server <username>:<pwd>@<email server> priority 1 secure tls 
    end 
  3. 環境変数を構成しますds_emailに管理者のメールアドレスを指定します。

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

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

高いCPU使用率の監視

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

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

    
    show snmp 
    %SNMP agent not enabled  
    
    config t 
    snmp-server manager 
    end  
    
    show snmp 
    Chassis: ABCDEFGHIGK 
    149655 SNMP packets input 
        0 Bad SNMP version errors 
        1 Unknown community name 
        0 Illegal operation for community name supplied 
        0 Encoding errors 
        37763 Number of requested variables 
        2 Number of altered variables 
        34560 Get-request PDUs 
        138 Get-next PDUs 
        2 Set-request PDUs 
        0 Input queue packet drops (Maximum queue size 1000) 
    158277 SNMP packets output 
        0 Too big errors (Maximum packet size 1500) 
        20 No such name errors 
        0 Bad values errors 
        0 General errors 
        7998 Response PDUs 
        10280 Trap PDUs 
    Packets currently in SNMP process input queue: 0 
    SNMP global trap: enabled 
    
  2. Diagnostic Signatures Lookup Tool の以下のドロップダウンオプションを使用して、DS 64224 をダウンロードします。

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

    フィールド名

    フィールド値

    プラットフォーム

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

    製品

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

    問題の範囲

    パフォーマンス

    問題の種類

    メール通知による高 CPU 使用率

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

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

    次の例は、 FTPサーバーからローカルゲートウェイにファイルをコピーする方法を示しています。

    copy ftp://user:pwd@192.0.2.12/DS_64224.xml bootflash: 
    Accessing ftp://*:*@ 192.0.2.12/DS_64224.xml...! 
    [OK - 3571/4096 bytes] 
    3571 bytes copied in 0.064 secs (55797 bytes/sec) 
    
  4. ローカルゲートウェイに DS XML ファイルをインストールします。

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

    
    show call-home diagnostic-signature  
    Current diagnostic-signature settings: 
     Diagnostic-signature: enabled 
     Profile: CiscoTAC-1 (status: ACTIVE) 
     Downloading  URL(s):  https://tools.cisco.com/its/service/oddce/services/DDCEService 
     Environment variable: 
               ds_email: username@gmail.com 

    DSes をダウンロード:

    DS ID

    DS 名

    リビジョン

    ステータス

    最終更新日時(GMT+00:00)

    64224

    DS_LGW_CPU_MON75

    0.0.10

    登録済み

    2020-11-07 22:05:33


     

    トリガーされると、この署名によって、この署名そのものを含む実行中のすべての DS がアンインストールされます。 必要な場合は、DS 64224 を再インストールして、ローカルゲートウェイの高CPU使用率の監視を続行してください。

異常な通話切断の監視

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

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

    show snmp 
    %SNMP agent not enabled  
    
    config t 
    snmp-server manager 
    end  
    
    show snmp 
    Chassis: ABCDEFGHIGK 
    149655 SNMP packets input 
        0 Bad SNMP version errors 
        1 Unknown community name 
        0 Illegal operation for community name supplied 
        0 Encoding errors 
        37763 Number of requested variables 
        2 Number of altered variables 
        34560 Get-request PDUs 
        138 Get-next PDUs 
        2 Set-request PDUs 
        0 Input queue packet drops (Maximum queue size 1000) 
    158277 SNMP packets output 
        0 Too big errors (Maximum packet size 1500) 
        20 No such name errors 
        0 Bad values errors 
        0 General errors 
        7998 Response PDUs 
        10280 Trap PDUs 
    Packets currently in SNMP process input queue: 0 
    SNMP global trap: enabled 
  2. Diagnostic Signatures Lookup Tool の以下のオプションを使用して、DS 65221 をダウンロードします。

    フィールド名

    フィールド値

    プラットフォーム

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

    製品

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

    問題の範囲

    パフォーマンス

    問題の種類

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

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

    copy ftp://username:password@<server name or ip>/DS_65221.xml bootflash:
  4. ローカルゲートウェイに DS XML ファイルをインストールします。

    
    call-home diagnostic-signature load DS_65221.xml 
    Load file DS_65221.xml success 
  5. コマンドを使用するcall-home 診断署名の表示をクリックし、署名が正常にインストールされたことを確認します。 ステータス列の値が「registered」になっているはずです。

問題をトラブルシューティングするための診断署名をインストールする

診断署名(DS)を使用して問題を迅速に解決することもできます。 特定の問題のトラブルシューティング、問題発生の検出、診断データの適切なセットの収集、およびCisco TACケースへのデータの自動転送に必要なデバッグを可能にする複数の署名をCisco TACエンジニアが作成しました。 これにより、問題の発生を手動で確認する必要がなくなり、断続的、および一時的な問題のトラブルシューティングがはるかに容易になります。

また、 Diagnostic Signatures Lookup ツール特定の問題を自分で解決するために、適切な署名を見つけ、インストールするか、サポート契約の一部として TAC エンジニアによって推奨される署名をインストールできます。

以下の例は、「%VOICE_IEC-3-GW: CCAPI: Internal Error (call spike threshold): IEC=1.1.181.1.29.0」の syslog 発生を検出し、以下のステップを使用して診断データ収集を自動化します。

  1. 別の DS 環境変数を構成するds_fsurl_prefixをCisco TACファイルサーバーパス (cxd.cisco.com) として入力し、診断データをアップロードします。 ファイルパス内のユーザ名はケース番号で、パスワードはファイル アップロード トークンです。これはサポートケースマネージャー次に示すとおりです。 ファイル アップロード トークンは、添付ファイルを追加することができます。

    
    configure terminal 
    call-home  
    diagnostic-signature 
    LocalGateway(cfg-call-home-diag-sign)environment ds_fsurl_prefix "scp://<case number>:<file upload token>@cxd.cisco.com"  
    end 

    例:

    
    call-home  
    diagnostic-signature 
    environment ds_fsurl_prefix " environment ds_fsurl_prefix "scp://612345678:abcdefghijklmnop@cxd.cisco.com"  
  2. コマンド を使用して SNMP が有効になっていることを確認します。 SNMPを表示だ SNMP が有効になっていない場合は、snmpサーバーマネージャ コマンド

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

    フィールド名

    フィールド値

    プラットフォーム

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

    製品

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

    問題の範囲

    パフォーマンス

    問題の種類

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

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

    フィールド名

    フィールド値

    プラットフォーム

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

    製品

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

    問題の範囲

    Syslog

    問題の種類

    Syslog - %VOICE_IEC-3-GW: CCAPI: Internal Error (Call spike threshold): IEC=1.1.181.1.29.0

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

    
    copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash: 
    copy ftp://username:password@<server name or ip>/DS_65095.xml bootflash: 
  6. 高CPUモニタリング DS 64224 をインストールし、次に DS 65095 XMLファイルをローカルゲートウェイにインストールします。

    
    call-home diagnostic-signature load DS_64224.xml 
    Load file DS_64224.xml success 
    call-home diagnostic-signature load DS_65095.xml 
    Load file DS_65095.xml success 
    
  7. を使用して署名が正常にインストールされていることを確認します。 コールホーム診断署名を表示だ ステータス列の値が「registered」になっているはずです。

    
    show call-home diagnostic-signature  
    Current diagnostic-signature settings: 
     Diagnostic-signature: enabled 
     Profile: CiscoTAC-1 (status: ACTIVE) 
     Downloading  URL(s):  https://tools.cisco.com/its/service/oddce/services/DDCEService 
     Environment variable: 
               ds_email: username@gmail.com 
               ds_fsurl_prefix: scp://612345678:abcdefghijklmnop@cxd.cisco.com 

    ダウンロードされた DSes:

    DS ID

    DS 名

    リビジョン

    ステータス

    最終更新日時(GMT+00:00)

    64224

    00:07:45

    DS_LGW_CPU_MON75

    0.0.10

    登録済み

    2020-11-08:00:07:45

    65095

    00:12:53

    DS_LGW_IEC_Call_spike_threshold

    0.0.12

    登録済み

    2020-11-08:00:12:53

診断署名の実行を確認する

次のコマンドでは、コマンドの [状態] 列call-home 診断署名の表示ローカル ゲートウェイが署名内で定義されたアクションを実行している間は、「実行中」に変更されます。 出力は次のとおりですCall-home 診断署名統計の表示診断署名が対象イベントを検出してアクションが実行されたかどうかを検証するための最適な方法です。 [Triggered/Max/Deinstall] 列には、指定した署名がイベントをトリガーした回数、定義済みのイベント最大検出回数、トリガーされたイベントの検出後に署名がアンインストールされるかどうかが表示されます。

show call-home diagnostic-signature  
Current diagnostic-signature settings: 
 Diagnostic-signature: enabled 
 Profile: CiscoTAC-1 (status: ACTIVE) 
 Downloading  URL(s):  https://tools.cisco.com/its/service/oddce/services/DDCEService 
 Environment variable: 
           ds_email: carunach@cisco.com 
           ds_fsurl_prefix: scp://612345678:abcdefghijklmnop@cxd.cisco.com 

ダウンロードされた DSes:

DS ID

DS 名

リビジョン

ステータス

最終更新日時(GMT+00:00)

64224

DS_LGW_CPU_MON75

0.0.10

登録済み

2020-11-08 00:07:45

65095

DS_LGW_IEC_Call_spike_threshold

0.0.12

実行中

2020-11-08 00:12:53

Call-home 診断署名統計の表示

DS ID

DS 名

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

平均実行時間(秒)

最長実行時間(秒)

64224

DS_LGW_CPU_MON75

0/0/N

0.000

0.000

65095

DS_LGW_IEC_Call_spike_threshold

1/20/Y

23.053

23.053

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

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

トラブルシューティング目的で診断署名を使用し、通常はいくつかの問題の発生が検出された後にアンインストールするように定義します。 署名を手動でアンインストールする場合、次の出力から DS IDを取得しますcall-home 診断署名の表示に移動し、次のコマンドを実行します。

call-home diagnostic-signature deinstall <DS ID> 

例:

call-home diagnostic-signature deinstall 64224 

 

展開で観察された問題に基づいて、Diagnostics Signatures Lookup Tool に新しい署名が定期的に追加されます。 TAC では現在、新しいカスタム署名の作成リクエストをサポートしていません。

2023年10月12日
ローカル ゲートウェイとして 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 の両方のプラットフォームでローカルゲートウェイを構成しています。 この設定のユーザー名とパスワードは以下のとおりです。

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

  • パスワード: lOV12MEaZx

1

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


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

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


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


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


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


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


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

voice class srtp-crypto 200
  crypto 1 AES_CM_128_HMAC_SHA1_80
  exit

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






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

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


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

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

voice class uri 100 sip
 host ipv4:198.18.133.3

voice class uri 200 sip
 pattern dtg=hussain1076.lgu



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

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


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

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





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

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

end

copy run start

Show コマンド出力を表示するには、VCUBE-2 の後に VCUBE-1 をリロードし、VCUBE-1 をスタンバイ CUBE にして、VCUBE-2 をアクティブ CUBE にします。

2

任意の時点で、1 個のプラットフォームのみが、Webex Calling アクセス SBC を使用したローカル ゲートウェイとしてアクティブ登録を保持します。 以下の show コマンドの出力を見てみましょう。

show redundancy application group 1

sip-ua レジスタ ステータスを表示


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

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

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

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

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

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

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

VCUBE-2#show sip-ua register status

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

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

3

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


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

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


VCUBE-2#redundancy application reload group 1 self

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

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

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

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

5

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


VCUBE-1#show sip-ua register status

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

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

6

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


VCUBE-1#show log

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

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

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

Webex Calling が有効になっているロケーションが既存の Cisco UC 展開に追加されている場合、または Unified CM に登録されている電話と Webex Calling ロケーションの電話の間で直接ダイヤルする必要がある場合は、Webex Calling を Unified CM と統合できます。

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

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

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

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

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

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

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

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

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

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

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

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

PSTNInternational (PSTN アクセス)

onNetRemote (GDPR 学習先)


 

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

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

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

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

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

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

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

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

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

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

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

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

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

次に行うこと

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

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

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

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

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

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

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

2024年5月16日
Webex Calling ユーザーの構成と管理

Webex Calling サービスを利用するには、個々のユーザーをすべて Control Hub に追加する必要があります。 ユーザーを Control Hub に追加する方法には、メール アドレスを入力して個々のユーザーを手作業で追加する方法と、CSV ファイルを使用して複数のユーザーをまとめて追加する方法があります。 何人のユーザーを追加するかに応じて決めてください。

2024年5月30日
Webex Calling デバイスの構成と管理

Control Hub でユーザーとワークスペースにデバイスを割り当て、管理できます。 MAC アドレスで追加するか、デバイスに入力するアクティベーション コードを生成して追加するかを選択します。

Control Hub では、個人使用のために電話機をユーザーに割り当てることができます。 ここ にリストされている電話機は Webex Calling をサポートしています。 これらの電話機はすべて MAC アドレスを使用して追加できますが、アクティベーション コードを使用して登録できるのは次のサブセットのみです。

  • Cisco IP Phone 6800 シリーズ マルチプラットフォーム電話(音声電話- 6821、6841、6851、6861、6871)

  • Cisco IP Phone 7800 シリーズマルチプラットフォーム電話 (音声電話7811、-6821、7841、7861)

  • Cisco IP Phone 8800 シリーズ マルチプラットフォーム電話 (音声電話-8811、8841、8851、8861)

  • Cisco IP Phone 8800 シリーズ マルチ プラットフォーム電話 (ビデオ電話-8845、8865)

  • Cisco IP 電話会議 Phone 7832 および 8832

  • Cisco Video Phone 8875

  • Cisco Desk Phone 9800 シリーズ


 

DECTデバイスについては、 DECTベースデバイス ( DECTハンドセットではありません) のみを割り当てに使用できます。コントロールハブを選択します。 ベース ユニットをユーザーに割り当てた後、手動で DECT ハンドセットをそのベース ユニットにペアリングする必要があります。 詳細については、「ハンドセットを基地局に接続する」を参照してください。

1

https://admin.webex.comの顧客ビューからに移動します。 管理 > デバイス > デバイスの追加

に移動して、「ユーザー」セクションからデバイスをユーザーに追加することもできます。 管理 > ユーザー > ユーザーを選択 > [デバイス] > [デバイスの追加]を選択します。
2

デバイスをユーザーに割り当てる場合は[個人使用]を選択し、[次へ]をクリックします。

3

電話機の所有者のユーザー名または実際の名前を入力し、結果からユーザーを選択し、[次へ] をクリックします。

4

ユーザーに設定するデバイスの種類を選択します。

  • Cisco Desk Phone:このオプションを選択した場合は、[デバイスの選択] ドロップダウン メニューから Cisco Desk Phone モデルを選択します。
  • Cisco 電話、ATA、またはサードパーティ製デバイス—このオプションを選択した場合は、 Cisco 管理対象デバイス FROM デバイスを選択 ドロップダウンメニュー。 次に、ドロップダウンメニューからデバイスタイプを選択します。
5

電話機をアクティベーションコード(オプションが表示される場合)または MAC アドレスで登録するかどうかを選択し、[保存] をクリックします。

  • アクティベーション コード - デバイス所有者と共有可能なアクティベーション コードを生成する場合は、このオプションを選択します。 16桁のアクティベーション コードはデバイスに手動で入力する必要があります。

     

    マルチプラットフォーム電話のアクティベーション コード画面を表示するには、11.2.3 MSR1 以降のファームウェア ロードが必要です。 電話のファームウェアを更新する必要がある場合は、[ユーザー] を https://upgrade.cisco.com/MPP_upgrade.html に指定します。

  • MAC アドレス - デバイスの MAC アドレスを知っている場合は、このオプションを選択します。 電話機の MAC アドレスは固有なエントリーでなければなりません。 すでに登録されている電話機の MAC アドレスを入力した場合、または番号を入力する際に間違った場合には、エラー メッセージが表示されます。

 

サードパーティのデバイスを使用している場合、制限が適用される場合があります。

デバイス用にアクティベーションコードを生成し、そのコードをまだ使用していない場合、Control Hub では、割り当てられているユーザーの [デバイス] セクションとメインの [デバイス] リストでそのデバイスのステータスが [アクティベート中] と表示されます。 デバイス ステータスが更新されるまでに最大 10 分かかることがあります。コントロールハブを選択します。

ユーザーに割り当てられたデバイスを変更または管理するには、この記事の「ユーザーのデバイスを管理する」セクションを参照してください。

ユーザーが職場にいる際、ランチ ルーム、ロビー、会議室などの場所に集まります。 これらの場所にある共有 Cisco Webex デバイスをセットアップし、サービスを追加し、コラボレーションの様子を確認できます。

Workspaces デバイスの主な原則は、特定のユーザーに割り当てるのではなく、物理的な場所に割り当てられ、共有の使用を許可することです。

こちらに記載されている会議端末は Webex Calling をサポートしています。 これらのほとんどのデバイスは MAC アドレスを使用して登録できますが、アクティベーション コードを使用して登録できるのは次のサブセットだけです。

  • Cisco IP Phone 6800 シリーズマルチプラットフォーム電話 (音声電話-6821、6841、6851)

  • Cisco IP Phone 7800 シリーズマルチプラットフォーム電話 (音声電話7811、-6821、7841、7861)

  • Cisco IP Phone 8800 シリーズ マルチプラットフォーム電話 (音声電話-8811、8841、8851、8861)

  • Cisco IP Phone 8800 シリーズ マルチ プラットフォーム電話 (ビデオ電話-8845、8865)

  • Cisco IP 電話会議 Phone 7832 および 8832

  • Cisco Desk Phone 9800 シリーズ

1

https://admin.webex.comの顧客ビューからに移動します。 管理 > デバイス > デバイスの追加

に移動して、[ワークスペース] セクションから新しいワークスペースにデバイスを追加することもできます。 管理 > ワークスペース > ワークスペースを追加
2

[共有使用状況] を選択し、[次へ] をクリックします。

3

[新規ワークスペース] を選択し、[次へ] をクリックします。

4

ワークスペースの名前 (物理的な会議室の名前など) を入力し、会議室のタイプを選択し、会議室の容量を追加し、ワークスペースの場所を選択します。 [次へ] をクリックします。


 

ワークスペースの名前は 30 文字以内にしてください。また、%、#、<、>、/、\、" の記号は使用できません。

5

ワークスペースに設定するデバイスの種類を選択します。

  • Cisco Desk Phone:このオプションを選択した場合は、[デバイスの選択] ドロップダウン メニューから Cisco Desk Phone モデルを選択します。
  • Cisco 電話、ATA、またはサードパーティ製デバイス—このオプションを選択した場合は、 Cisco 管理対象デバイス FROM デバイスを選択 ドロップダウンメニュー。 次に、ドロップダウンメニューからデバイスタイプを選択します。
6

電話機をアクティベーションコード(オプションが表示される場合)または MAC アドレスで登録するかどうかを選択し、[次へ] をクリックします。

  • アクティベーション コード - デバイス所有者と共有可能なアクティベーション コードを生成する場合は、このオプションを選択します。 16桁のアクティベーション コードはデバイスに手動で入力する必要があります。

     

    マルチプラットフォーム電話のアクティベーション コード画面を表示するには、11.2.3 MSR1 以降のファームウェア ロードが必要です。 電話のファームウェアを更新する必要がある場合は、[ユーザー] を https://upgrade.cisco.com/MPP_upgrade.html に指定します。

  • MAC アドレス - デバイスの MAC アドレスを知っている場合は、このオプションを選択します。 電話機の MAC アドレスは固有なエントリーでなければなりません。 すでに登録されている電話機の MAC アドレスを入力した場合、または番号を入力する際に間違った場合には、エラー メッセージが表示されます。

 
Webex Calling の場合、ワークスペースに共有電話を 1 つしか追加できません。

Cisco IP 会議電話 7832 の場合、一部のソフトキーが使用できない場合があります。 フルセットのソフトキーが必要な場合は、ユーザーにこの電話を割り当てることをお勧めします。

7

Calling サービスをクリックし、ワークスペースに割り当てるサブスクリプションとライセンスのタイプを選択します。

  • プロフェッショナル ワークスペース

  • 共用エリアのワークスペース


 

ライセンスで利用可能な機能の詳細については、Webex Calling のライセンス タイプ別の機能を参照してください。

8

[ロケーション][電話番号](選択したロケーションによって決まるもの) を割り当てて、[保存] をクリックします。 拡張機能を割り当てるオプションもあります。


 
ワークスペースに割り当てられたデバイスを変更または管理するには、「ワークスペースのデバイスを管理する」セクションを参照してください。

Webex Callingユーザー/ワークスペースに割り当てられている電話機を別のWebex Callingユーザー/ワークスペースで再利用するには、次の手順に従います。

1

顧客ビューからhttps://admin.webex.com、デバイスが現在割り当てられているユーザー / ワークスペースに移動します。

次のシナリオでは、デバイスを再割り当てできます。

  1. ユーザーを削除したい場合は、ユーザー / ワークスペースを削除して、ユーザー / ワークスペースと関連するデバイスを削除します。

  2. デバイスを削除する場合、デバイスを選択し、削除するデバイスを選択します。

2

電話機で、設定メニューに進み、次の手順を実行して電話機を再割り当てします。

  1. 選択デバイスの管理を選択し、工場出荷時の状態へのリセットを選択します。

  2. 電話機が再起動します。 再起動が完了すると、電話機に [アクティベーション コード(Activation Code)] 画面が表示されます。

  3. この電話機はこれで再割り当ての準備ができました。

3

の指示に従ってください。電話機を追加し、ユーザーに割り当てるまたは電話を新しいワークスペースに追加するを選択して、ユーザー/ワークスペースに電話を割り当てるか追加します。

4

Control Hub にデバイスを追加する際には、電話で以下の操作を完了します。

  1. アクティベーション コードの場合:

    アクティベーションコードを入力します。 電話機は再起動し、新しいユーザ/ワークスペースにオンボードされます。

  2. MACアドレスの場合:

    [アクティベーション コード] 画面で #000 を入力すると、電話は Webex Webex Callingで再オンボードされ、新しいユーザ/ワークスペースにプロビジョニングされます。

ユーザーが職場にいる際、ランチ ルーム、ロビー、会議室など、多くのワークスペースに集まります。 これらの場所にある共有 Cisco Webex デバイスをセットアップし、サービスを追加し、コラボレーションの様子を確認できます。

ワークスペース デバイスの主な原則は、特定のユーザーに割り当てられるのではなく、物理的なロケーションに割り当てられ、共用を可能にすることです。

ここに記載されているデバイスは Webex Calling をサポートしています。

1

https://admin.webex.comの顧客ビューからに移動します。 管理 > デバイス > デバイスの追加

に移動して、[ワークスペース] セクションから新しいワークスペースにデバイスを追加することもできます。 管理 > ワークスペース > ワークスペースを追加
2

[共有使用状況] を選択し、[次へ] をクリックします。

3

[新規ワークスペース] を選択し、[次へ] をクリックします。

4

ワークスペースの名前 (物理的な会議室の名前など) を入力し、会議室のタイプを選択し、会議室の容量を追加し、ワークスペースの場所を選択します。 [次へ] をクリックします。

5

Cisco Room および Desk デバイス を選択します。

6

次のサービスのいずれかを選択し、[次へ]をクリックします。

  • Webex での通話 (1 対 1 通話、非 PSTN) —ユーザーは、SIP アドレス (username@example.calls.webex.com など) を使用して Webex アプリ または Webex セッション開始プロトコル (SIP) 通話のみ行うことができます。
  • Cisco Webex Calling —Webex アプリと SIP コールの発信と受信に加えて、このワークスペースのユーザーは、デバイスを使用して、Webex Calling 番号プラン内から電話の発信と受信を行うことができます。 たとえば、電話番号 555-555-5555、内線 5555、または SIP アドレス username@example.webex.com をダイヤルすることで同僚に電話をかけることができますが、ローカルのピザ店に電話することもできます。
7

Cisco Webex Calling サービスを選択した場合は、ワークスペースに割り当てるサブスクリプションとライセンス タイプを選択します。

  • プロフェッショナル ワークスペース

  • 共用エリアのワークスペース


 

ライセンスで利用可能な機能の詳細については、Webex Calling のライセンス タイプ別の機能を参照してください。

8

[ロケーション][電話番号](選択したロケーションによって決まるもの)、および [内線番号] を割り当てて、[保存] をクリックします。

9

与えられたコードを使用してデバイスを有効にします。 アクティベーション コードはコピー、メール、または印刷により使用できます。

ユーザーとワークスペースに複数のデバイスを割り当てるには、必要な情報を CSV ファイルに入力し、2、3 の簡単な手順でそれらのデバイスをアクティブ化できます。

ここに記載されているデバイスは Webex Calling をサポートしています。 MAC アドレスを使用してすべてのデバイスを登録できますが、アクティベーション コードを使用して次のデバイスのサブセットを登録します。

  • Cisco IP Phone 6800 シリーズマルチプラットフォーム電話 (音声電話-6821、6841、6851)

  • Cisco IP Phone 7800 シリーズマルチプラットフォーム電話 (音声電話7811、-6821、7841、7861)

  • Cisco IP Phone 8800 シリーズ マルチプラットフォーム電話 (音声電話-8811、8841、8851、8861)

  • Cisco IP Phone 8800 シリーズ マルチ プラットフォーム電話 (ビデオ電話-8845、8865)

  • Cisco IP 電話会議 Phone 7832 および 8832

  • Cisco Video Phone 8875

  • Cisco Desk Phone 9800 シリーズ

1

https://admin.webex.comの顧客ビューからに移動します。 管理 > デバイス > デバイスの追加 > 複数のCisco IP電話

2

次のいずれかのオプションを選択し、[ダウンロード]をクリックします。

  • 組織内のユーザー—組織内のすべてのユーザーと関連する属性のリストを取得できるため、各ユーザーを手動で検索する必要はありません。
  • 組織内のワークスペース—組織内のすべてのワークスペースと関連する属性のリストを取得できるため、各ワークスペースを手動で検索する必要はありません。
  • デバイス サンプル テンプレートの追加:使用可能なテンプレートを使用して、ユーザー名、タイプ(ユーザーかワークスペースかを示します)、MAC アドレス、デバイス モデルなどの情報を入力できます。
次の表を使用して、CSV ファイルを準備できます。

 
Webex Calling ユーザーとワークスペースにデバイスを割り当てる場合、次のフィールドは必須です。
  • ユーザーの場合: デバイス タイプが IP の場合は、ユーザ名、タイプ、デバイス タイプ、およびモデル。
  • ワークスペースの場合: ユーザ名、タイプ、電話番号または内線、Webex Calling Workspace [サブスクリプション名]、デバイス タイプ、およびデバイス タイプが IP の場合のモデル。

列名説明サポートされる値

ユーザー名

デバイスをユーザーに割り当てるには、ユーザーのメール アドレスを入力します。


 
ユーザー ID またはユーザー名を入力しないでください。

デバイスをワークスペースに割り当てるには、ワークスペース名を入力します。


 
まだ存在していないワークスペースを入力すると、そのワークスペースが自動的に作成されます。

ユーザーの電子メールの例: test@example.com

ワークスペース名の例: 休憩室

種類

ユーザーまたはワークスペースとして適切なタイプを入力します。

USER

ワークスペース

電話番号

電話番号を入力します。

例: +12815550100

Extension

内線番号を入力します。

例: 00 ~ 999999

デバイス タイプ

デバイスのタイプを入力します。

Webex Calling でマルチプラットフォーム電話、ATA または DECT デバイスを使用するには、IP を入力します。

RoomOS デバイスを持つ新しいワークスペースを作成するには、希望の [通話] オプションに応じて WEBEX または WEBEX_CALLING を入力します

モデル

デバイス タイプが IP の場合は、デバイス モデルを入力します。

デバイス モデルの例: Cisco 7841、Cisco 8851 など

MAC アドレス

デバイスの MAC アドレスを入力します。

MAC アドレス フィールドを空白のままにすると、アクティベーション コードが生成されます。


 
RoomOS デバイスのアクティベーション コードを使用します。

MAC アドレスの例: 001A2B3C4D5Eの

場所

ユーザーまたはワークスペースの場所の名前を入力します。

例: サンノゼ

通話プラン

TRUE を入力して、新しく追加されたワークスペースの Cisco Calling プランを有効にします。

この機能は、ユーザー、既存のワークスペース、およびサポートされていないロケーションのワークスペースでは機能しません。

○(はい)

FALSE

Webex Calling ワークスペース [サブスクリプション ID]

共通エリアまたはプロフェッショナルな通話ワークスペースの作成に使用するサブスクリプションを指定します。

ワークスペース ライセンスを所有する各サブスクリプションには、対応する列があります。 共通エリア ワークスペース ライセンスまたはプロフェッショナル ワークスペース ライセンスのいずれかを割り当てることができます。 ライセンスを割り当てるには、各サブスクリプションのライセンスタイプの列のいずれかに TRUE を入力します。


 
ワークスペースには 1 つのサブスクリプションのみ割り当てる必要があります。

ワークスペースを 1 つのサブスクリプションから別のサブスクリプションに転送することもできます。 転送するには、ソース サブスクリプション 列に FALSE を、ターゲット サブスクリプション 列に TRUE を入力します。


 
ワークスペース ライセンスのアクティブ サブスクリプションに関する正確な情報が含まれているため、最近生成されたテンプレートを使用して CSV インポート ファイルを準備することをお勧めします。

○(はい)

FALSE

Webex Calling Professional Workspace [サブスクリプション ID]


 
[電話番号(Phone Number)] フィールドと [内線(Extension)] フィールドには、以前は [電話番号(Directory Number)] および [直通回線(Direct Line)] というタイトルが付いていました。これらの列名は短時間サポートされます。

 
CSV ファイルあたりのデバイス数を 1000 に制限することをお勧めします。 1,000 を超えるデバイスを追加する場合は、2 番目の CSV ファイルを使用します。
3

スプレッドシートに入力します。

4

CSV ファイルをドラッグ アンド ドロップするか、[ファイルを選択] をクリックしてアップロードします。

5

MAC アドレスが空白の場合、アクティベーション コードが送信される場所を選択するオプションが表示されます。

  • リンクを提供:アクティベーション コードが CSV ファイルに追加されます。 インポート後、[インポートステータス(Import Status)] 画面にアクティベーション コード ファイルをダウンロードするためのリンクが表示されます。
  • アクティベーション コード メール—デバイスがワークスペース用である場合、アクティベーションコードは管理者として、あなたに送信されます。 デバイスがユーザー用の場合、アクティベーション コードはユーザーにメールで送信されます。

ユーザまたはユーザは、アクティベーションするためにデバイスにアクティベーション コードを入力する必要があります。

6

[送信] をクリックします。

デバイスがアクティブになったときに更新されたステータスを表示します。

 

マルチプラットフォーム デバイスは、ユーザーがデバイスにアクティベーション コードを入力できるように、11.2.3 MSR1 以降のファームウェア ロードを実行している必要があります。 電話機のファームウェアのアップグレードについては、この記事を参照してください。

ユーザーとワークスペースに割り当てられているデバイスのリストを表示する場合は、 CSVファイルをエクスポートできます。

https://admin.webex.com の顧客ビューから、[デバイス] に移動します。

デバイス リストから複数のデバイスを選択し、必要に応じてエクスポートを選択します。 CSVファイルに含めるフィールドを選択でき、コンテンツをローカル フォルダーにエクスポートできます。


 

CSVファイルに表示されるフィールドは、プラットフォームに対するデバイスの接続によって異なります。 したがって、出力ファイルで使用できないフィールドもあります。

組織内のユーザーに割り当てられたデバイスに対して、アクティベーションの追加、削除、再起動、チェック、または新しいアクティベーションコードの作成を行うことができます。 これは、必要に応じてユーザー画面でデバイスを表示および管理するのに役立ちます。

1

の顧客ビューから、[管理] > [ユーザー] の順に移動します。https://admin.webex.com

2

ユーザーを選択し、[デバイス] をクリックします。

3

このユーザーにデバイスを追加するには、[デバイスの追加] をクリックします。


 
ユーザーがすでにデバイスを割り当てられていて、別のデバイスを追加する場合は、 をクリックします。 アクション > デバイスの追加

デバイスをユーザに追加する方法の詳細については、「ユーザに電話を追加する」セクションを参照してください。

4

既存のデバイスを変更するには、デバイス名を選択します。

これにより、[デバイス] ページに移動します。 ここでは、デバイス設定を表示および編集したり、デバイスを削除したり、デバイスを再起動したり、必要に応じてデバイスの新しいアクティベーションコードを作成したりできます。 電話設定の構成についての詳細は、「電話設定の構成と更新」を参照してください。

5

ユーザーに追加されたデバイスがWebex Aware の場合、図に示すように、 Webex Aware オプションがデバイスの下に表示されます。 Webex Aware は、デバイスがWebexプラットフォームにオンボードされ、電話機でサポートされているWebex機能にアクセスできることを示します。

6

クリックアクションに移動して、デバイスを管理します。 アクションは、MPP デバイスの構成変更を適用したり、ファームウェアを更新したりするのに役立ちます。

[アクション] タブには、 Webex Aware 対応デバイスのこれらのオプションがあります。
  • [変更の適用(Apply Changes)]:ダウンロードして設定変更を適用する要求を電話機に発行します。
  • 再起動:デバイスを強制的に再起動し、現在の構成をダウンロードするリクエストを発行します。
  • レポートの問題:PRT を生成し、クラウドにアップロードするようにデバイスにリクエストを発行します。
  • [削除(Delete)]:ユーザにリストされているデバイスを削除します。

デバイスは、ワークスペースのプロファイルから直接追加および管理できます。 ワークスペースのデバイスにはファックスのような ATA デバイスを含めることが可能です。 また、ワークスペースのデバイスをホテリングホストとしてセットアップすることもできます。 ホテリングに関する詳細は、以下を参照してください。 Cisco Webex Control Hubのホテリングを選択します。

1

https://admin.webex.comの顧客ビューからに移動します。 管理 > ワークスペース

2

変更するワークスペースを選択します。

3

デバイスを追加するには、[デバイス]タイルの[デバイスの追加]をクリックします。

ワークスペースにデバイスを追加する方法の詳細については、「新しいワークスペースに電話を追加する」セクションを参照してください。

4

既存のデバイスを変更するには、デバイス名を選択します。

これにより、[デバイス] ページに移動します。 ここでは、デバイス設定を表示および編集したり、デバイスを削除したり、デバイスを再起動したり、デバイスをホテリングホストとして使用したりできます。 電話設定の構成についての詳細は、「電話設定の構成と更新」を参照してください。

5

ワークスペースに追加されたデバイスがWebex Aware である場合、 Webex Aware オプションがデバイスの下に図に示されます。 Webex Aware は、デバイスがWebexプラットフォームにオンボードされており、電話機でサポートされているWebex機能にアクセスできることを示します。

6

クリックアクションに移動して、デバイスを管理します。 アクションは、MPP デバイスの構成変更を適用したり、ファームウェアを更新したりするのに役立ちます。

[アクション] タブには、 Webex Aware 対応デバイスのこれらのオプションがあります。
  • [変更の適用(Apply Changes)]:ダウンロードして設定変更を適用する要求を電話機に発行します。
  • 再起動:デバイスを強制的に再起動し、現在の構成をダウンロードするリクエストを発行します。
  • レポートの問題:PRT を生成し、クラウドにアップロードするようにデバイスにリクエストを発行します。
  • [削除(Delete)]:ユーザにリストされているデバイスを削除します。

共有回線アピアランスを使用すると、ユーザのプライマリ デバイスに回線を追加し、回線の表示方法を変更できます。 この機能により、ユーザは自分の電話を使用して別のユーザの内線番号へのコールを受信したり、発信したりできます。 共有ライン アピアランスの例としては、上司の回線から通話を発信および受信するエグゼクティブ アシスタントがいます。 共有回線のアピアランスは、プライマリユーザーの回線の別のインスタンスにもなります。

設定できるデバイスはユーザーの電話番号ごとに最大で 35 台です (ユーザーのデスクトップまたはモバイル アプリも含みます)。 ワークスペースの電話機に追加の回線を追加できます。 ただし、共有回線としてプロライセンスを持つワークスペースの電話機のみを追加できます。


 

共有電話を割り当てる場合は、別の電話番号を指定できます。 Webex Callingを別のロケーションのデバイスに追加します。 たとえば、英国のロケーションからの番号 (ユーザー、ワークスペース、仮想回線) は、米国のロケーションでユーザーに割り当てられているデバイスに割り当てることができます。

ロケーション間での共有回線の詳細については、次を参照してください。 「ロケーション間の共有回線と仮想回線の設定」をご覧ください。


 

ユーザーが MPP 電話にスピード ダイヤルを追加すると、Control Hub には表示されません。 スピード ダイヤルは、共有回線の設定時に上書きできます。

ユーザのデバイスで他のユーザ/グループからの番号が設定されている場合、共有回線にカスタムラベルを追加できます。 このカスタム ラベルは、共有回線のアピアランスを他のアピアランスから識別するのに役立ちます。

1

https://admin.webex.com のカスタマービューから、[ユーザー] または [ワークスペース] (変更するデバイスが割り当てられている場所によって異なる)に移動します。

2

変更するユーザーまたはワークスペースを選択し、[デバイス] にスクロールします。

3

共有回線を追加または変更するデバイスを選択し、電話ユーザーおよび設定を選択します。

電話に表示されるユーザーおよび場所は、表示順にリストされます。

4

この電話からユーザーまたは場所を追加または削除するには、[回線を設定する] を選択します。

5

回線を削除するには、アイコンを選択します。


 
回線 1 のプライマリ ユーザーを削除することはできません。
6

共有回線アピアランスを追加するには、アイコンを選択します。


 
表示したい順番になるように回線を追加します。 共有回線のアピアランスを並べ替えるには、表示したい順番になるようにリストを削除し、追加します。
7

名前または電話番号を入力し、表示されるオプションから選択し、[保存] をクリックします。

Control Hub のユーザーに割り当てられたアナログ電話アダプター(ATA)デバイスのポートを構成できます。 現在、ATA デバイスで使用可能な 2 つの構成は、2 ポートのデバイスと 24 ポートのデバイスです。

1

https://admin.webex.com の顧客ビューから [ユーザー] に移動します。

2

変更するユーザーを選択し、[デバイス] までスクロールします。

3

追加または変更するデバイスを選択します。

4

[このデバイス上のユーザー] で、[ポートを設定する] をクリックします。

5

共有ポート設定を追加するには、アイコンを選択します。

6

名前または電話番号を入力し、表示されるオプションから選択し、次に [保存] をクリックします。


 
ルックアップには、デバイスのないワークスペースだけが表示されます。
7

デバイスに T.38 ファックス圧縮が必要な場合、T.38 列のボックスをオンにするか、ユーザーレベルの圧縮オプションをオーバーライドしてから、保存を選択します。


 
ワークスペースには ATA を含めることができます。 これはファックスに便利です。

電話番号は、トライアル中であるか、有料のサブスクリプションに変更したかには関わりなく、顧客の卓上電話および室内デバイスにいつでも追加できます。


 

追加できる電話番号の数を増やしましたコントロールハブ250~1000

1

https://admin.webex.com のカスタマービューから、[サービス] > [通話] > [番号] の順に移動してから、[番号の追加] をクリックします。

2

[ロケーション][番号タイプ] を指定します。 番号を移行する場合には、現在の新しい請求番号と新しい番号の両方を入力してください。

3

ロケーション]、[状態]、[エリアコード]、[プレフィックス](オプション)を指定し、[検索]をクリックします。

使用可能な番号が表示されます。

4

ロケーションに追加する番号を選択します。

選択した番号は、[選択した番号] フィールドに移動します。

5

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

組織が注文した PSTN 番号は、リストとして確認できます。 この情報により、利用可能な未使用の番号、間もなく利用可能になる注文中の番号を確認できます。

https://admin.webex.com の顧客ビューから [サービス] > [Calling] > [PSTN 注文] に移動します。

MPP デバイスにアクセサリ (ヘッドセット /KEM) を接続すると、Control Hub の [デバイス] タブにインベントリ アイテムとして表示されます。 Control Hub のデバイス インベントリでは、アクセサリのモデル、ステータス、アクセサリの所有者を確認できます。 アクセサリを選択すると、アクセサリのシリアル番号や現在のソフトウェア バージョンなどの追加情報を取得できます。 アクセサリが MPP に接続されている限り、アクセサリ ステータスのフィールドは「オンライン」と報告されます。 MPP 接続されたヘッドセットは、デバイス管理から最新バージョンのソフトウェアを取得して自動アップグレードされます。

実際の例を見てみましょう。 これを視聴するビデオデモンストレーションでアクセサリの表示方法を確認するコントロールハブを選択します。
表 1. 互換性のあるヘッドセット

機種

Cisco ヘッドセット 520 シリーズ

Cisco ヘッドセット 530 シリーズ

Cisco ヘッドセット 560 シリーズ

Cisco ヘッドセット 730 シリーズ

Cisco IP Phone 8811/8841/8845

RJ9 & RJ11

Cisco IP Phone 8851/8861/8865

USB

USB

USB

RJ9 & RJ11

Cisco IP Phone 7811/7821/7841/7861

Cisco IP Phone 6821/6841/6851/6861

Cisco IP Phone 6871

USB

USB

USB

Cisco IP Conference Phone 7832/8832

表 2. 互換性のあるキー拡張モジュール

機種

KEM

Cisco IP Phone 8811/8841/8845

Cisco IP Phone 8851/8861/8865

BEKEM

CP-8800-A-KEM

CP-8800-V-KEM

Cisco IP Phone 7811/7821/7841/7861

Cisco IP Phone 6821/6841/6861/6871

Cisco IP Phone 6851

CP-68KEM-3PCC

Cisco IP Conference Phone 7832/8832


 

Webex Callingに登録された電話で Key Expansion Module (キー拡張モジュール) が直面する問題をトラブルシューティングするには、次を参照してください。 Webex Callingのキー拡張モジュールの問題をトラブルシューティングするをご覧ください。

2024年5月20日
Webex Callingの導入傾向と使用レポート

管理者は、 Webex Callingサービスがどのように、どのような頻度で使用されているかを判断するのに役立つ、多数のレポートを提供しています。 管理者は、お客様の場所でのメディアの品質を簡単に評価できます。

通話レポートを表示する

Control Hub の [アナリティクス] ページを使用して、ユーザーがどのように Webex Calling と Webex アプリ (エンゲージメント) を使用しているか、また、通話のメディア エクスペリエンスの質について洞察を得ることができます。 Webex Calling のアナリティクスにアクセスするには、Control Hub にサインインし、[アナリティクス] に移動して、[Calling] タブを選択します。

1

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

2

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

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

3

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

2024年5月29日
Cisco Webex Calling のポート参照情報

この記事は、ネットワーク管理者、特に組織内の Webex Calling サービスを使用するファイアウォールとプロキシのセキュリティ管理者を対象にしています。 ネットワーク要件を説明し、電話、 Webexアプリ、ゲートウェイをWebex Callingサービスに接続するために使用するアドレス、ポート、プロトコルをリスト化しています。

正しく設定されたファイアウォールとプロキシは、通話展開を成功させるために不可欠です。 Webex Callingでは、コール シグナリングに SIP と HTTPS を、メディア、ネットワーク接続、およびゲートウェイ接続に関連するアドレスとポートを使用します。 Webex Callingグローバルサービスです。

すべてのファイアウォール構成にポートを開く必要があるわけではありません。 ただし、内部から外部へのルールを実行している場合、必要なプロトコルのポートを開き、サービスを許可する必要があります。

ネットワーク アドレス変換

Network Address Translation (NAT) と Port Address Translation (PAT) 機能は、2 つのネットワーク間の境界でアドレス空間を翻訳したり、IP アドレス空間の衝突を防ぐために適用されます。

組織は、プライベート IP アドレス スペース上にあるアプリケーションまたはデバイスへのインターネット アクセスを提供するために、NAT または PAT サービスを提供するファイアウォールやプロキシなどのゲートウェイ テクノロジーを使用します。 これらのゲートウェイにより、内部アプリまたはデバイスからインターネットへのトラフィックは、1つまたは複数の公的にルーティング可能なIPアドレスから来ているように見えます。

  • NAT を展開する場合、ファイアウォールの受信ポートを開く必要はありません。

  • 複数のアプリのユーザーとデバイスが NAT または PAT を使用して Webex Calling および Webex 認識サービスにアクセスする場合、アプリまたはデバイスの接続に必要な NAT プールのサイズを確認します。 ポートの枯渇を防ぐために、適切なパブリック IP アドレスが NAT プールに割り当てられていることを確認します。 ポートの消耗により、内部ユーザーとデバイスが Webex Calling および Webex Aware サービスに接続できなくなります。

  • 適切なバインド期間を定義し、NAT デバイスで SIP を操作しないようにします。

  • デバイスの適切な動作を確保するための最小の NAT タイムアウトを構成します。 例: Cisco 電話は、1 ~ 2 分ごとにフォローアップ レジスタ更新メッセージを送信します。

  • ネットワークが NAT または API を実装している場合は、接続に対して長いタイムアウト (少なくとも 30 分) を設定してください。 このタイムアウトにより信頼性の高い接続を可能にし、ユーザーのモバイル デバイスのバッテリー消費を削減します。

アプリケーション レイヤー ゲートウェイ

ルーターまたはファイアウォールが SIP に対応している場合、SIP アプリケーションレイヤーゲートウェイ (ALG) または同様に有効になっている場合、この機能をオフにして、サービスの正常な動作を維持することをお勧めします。

特定のデバイスで SIP ALG を無効にする方法については、関連する製造元のドキュメントを参照してください。

プロキシ サポートWebex Calling

ほとんどの顧客はインターネット ファイアウォール、またはインターネット プロキシとファイアウォールを展開し、ネットワークを出入りするトラフィックを制限し、コントロールします。 これにより、さまざまな形態のサイバー攻撃からネットワークを保護できます。

プロキシは、次のようないくつかのセキュリティ機能を実行します。

  • 特定の URL へのアクセスを許可またはブロックします。

  • ユーザー認証

  • IPアドレス/ドメイン/ホスト名/ URI評価検索

  • トラフィックの復号化と検査

プロキシ機能の設定では、HTTP のプロトコルを使用するすべてのアプリケーションに適用されます。

アプリケーションには次のものが含まれます。

  • Webex サービス

  • GDS、EDOS デバイスのアクティベーション、プロビジョニングとWebexクラウドへのオンボードなどのCisco Cloud プロビジョニングプラットフォームを使用した顧客のデバイスのアクティベーション (CDA)。

  • 証明書認証

  • ファームウェア アップグレード

  • ステータス レポート

  • PRT アップロード

  • VoIP サービス


 

プロキシ サーバーアドレスが構成されている場合、シグナリング トラフィック (HTTP/HTTPS) のみがプロキシ サーバーに送信されます。 SIP を使用してWebex Callingサービスに登録するクライアント、および関連付けられたメディアは、プロキシに送信されません。 そのため、これらのクライアントがファイアウォールを直接通過することを許可します。

サポートされているプロキシ オプション、構成および認証タイプ

サポートされているプロキシタイプは次のとおりです。

  • 明示的プロキシ (検査または検査なし) — アプリまたはデバイスのいずれかのクライアントを明示的なプロキシを使用して構成し、使用するサーバーを指定します。 このオプションは、次のいずれかの認証タイプに対応しています。

  • 透過型プロキシ (検査なし)—クライアントは特定のプロキシ サーバーアドレスを使用するように設定されていないため、検査なしのプロキシで動作するように変更を加える必要はありません 。

  • 透過型プロキシ (検査あり)—クライアントは特定のプロキシ サーバーアドレスを使用するように設定されていません。 HTTP の構成の変更は必要ありません。ただし、 アプリまたはデバイスのいずれかのクライアントは、プロキシを信頼するためにルート証明書を必要とします。 IT チームは検査プロキシを使用して、アクセスするウェブサイトや許可されていないコンテンツのタイプにポリシーを適用します。

以下を使用して、 Webex Room デバイス、 Cisco IPマルチプラットフォーム フォン (MPP)、 Webexアプリのプロキシアドレスを手動で構成します。

  • プラットフォーム OS

  • デバイス URL

  • 自動検出

設定する際は、次のプロキシ構成および認証タイプから選択してください。

製品

プロキシの設定

認証タイプ

Mac 版 Webex

手動、WPAD、PAC

認証なし、基本、NTLM

Windows 版 Webex

手動、WPAD、PAC、GPO

認証なし、基本、NTLM、ネゴシエート

iOS 版 Webex

手動、WPAD、PAC

認証なし、基本、ダイジェスト、NTLM

Android 版 Webex

手動、PAC

認証なし、基本、ダイジェスト、NTLM

Webex Web アプリ

OS を通じてサポート対象

認証なし、基本、ダイジェスト、NTLM、ネゴシエート

Webex Room デバイス

WPAD、PAC、または手動

認証なし、基本、ダイジェスト

Cisco IP Phone

手動、WPAD、PAC

認証なし、基本、ダイジェスト

Webex ビデオ メッシュ ノード

手動

認証なし、基本、ダイジェスト、NTLM

表内の凡例

  1. Mac NTLM 認証 - マシンはドメインにログオンする必要はなく、ユーザーは 1 つのパスワードの入力を指示されます (2):

  2. Windows NTLM 認証 - 1 つのマシンがドメインにログオンする場合にのみサポートされます

  3. ウェブ プロキシ自動検出 (WPAD) - 「 Web プロキシ自動検出プロトコルをご覧ください。

  4. プロキシ自動設定 (PAC) ファイル - 「プロキシ自動構成ファイルをご覧ください。

  5. Cisco Webex Board、Desk、または Room Series デバイスをプロキシ サーバーに接続するには、次を参照してください。 Board、Desk、または Room Series デバイスをプロキシ サーバーに接続するを選択します。

  6. Cisco IP Phone の場合は、次を参照してください。プロキシ サーバを設定する例として、プロキシ サーバーと設定の構成。


 

対象: No Authentication の場合、認証をサポートしていないプロキシアドレスでクライアントを設定します。 閲覧方法: Proxy Authentication 、有効な資格情報を使用して設定します。 Web トラフィックを検査するプロキシは、Web ソケット接続に干渉する場合があります。 この問題が発生した場合、検査していないトラフィックを *. Webex.com によって問題が解決する場合があります。 他に入力されているものがある場合、最後に入力されているものの次にセミコロンを追加し、Webex の例外を入力します。

Windows OS のプロキシ設定

Microsoft Windowsは、プロキシ構成を可能にする HTTP トラフィック (WinINet と WinHTTP) 用に 2 つのネットワーク ライブラリをサポートしています。WinINet は WinHTTP のスーパーセットです。

  1. WinInet は、シングルユーザーおよびデスクトップクライアント アプリケーション用にのみ設計されています。

  2. WinHTTP は、主にマルチユーザーのサーバーベースのアプリケーション用に設計されています。

これらの間で選択する場合、プロキシ設定で [WinINet] を選択します。 詳細については、次を参照してくださいWininet-vs-winhttpを選択します。

参照先:社内ネットワーク内でWebexにアクセスするための許可ドメインのリストを構成するを参照してください。

  • ユーザーがドメインの事前定義済みリストのアカウントを使用するアプリケーションにのみサインインできるようにする。

  • プロキシ サーバーを使用して、リクエストを遮断し、許可されているドメインを制限します。

プロキシ 検査および証明書ピニング

Webex アプリと Webex デバイスは、TLS セッションを確立するサーバーの証明書を検証します。 証明書は、証明書の発行者とデジタル署名が、ルート証明書まで証明書のチェーンを検証することなどに依存していることを確認します。 アプリまたはデバイスでこれらの検証チェックを実行するには、オペレーティング システムの信頼ストアにインストールされている信頼できるルート CA 証明書のセットを使用します。

TLS検査プロキシを展開した場合、 Webex Callingトラフィックをインターセプトし、復号化し、検査します。 プロキシが提示する証明書 ( Webexサービス証明書の代わり) が証明機関によって署名されていること、およびルート証明書がWebexアプリまたはWebexデバイスの信頼ストアにインストールされていることを確認します。

  • Webexアプリの場合 - デバイスのオペレーティング システムのプロキシで証明書に署名するために使用されるCA 証明書をインストールします。

  • Webex Room デバイスおよびCiscoマルチプラットフォームIP電話の場合-TAC チームでサービス要求を開き、 CA 証明書をインストールします。

プロキシ サーバーによる TLS 検査に対する Webex アプリと Webex デバイスのサポートを次の表に示します

製品

TLS 検査のためのカスタムの信頼性のある CA をサポートします

Webex アプリ(Windows、Mac、iOS、Android、ウェブ)

はい

Webex Room デバイス

はい

Cisco IPマルチプラットフォーム(MPP)電話機

はい

ファイアウォールの設定

CiscoがサポートしていますWebex CallingおよびCisco Webex Aware サービス。 Amazon は、Cisco による使用のために唯一のIPサブネットを予約し、AWS 仮想プライベート クラウド内のこれらのサブネットにあるサービスを確保しました。

ファイアウォールを構成して、デバイス、アプリケーション、およびインターネットに接続されたサービスからの通信を許可し、機能を適切に実行します。 この設定では、サポートされているすべてのWebex CallingおよびWebex Aware クラウド サービス、ドメイン名、 IPアドレス、ポートとプロトコル。

次の URL をホワイトリストに登録するか、オープン アクセスを行って、 Webex CallingおよびWebex Aware サービスは正しく機能します。

  • セクションの下で言及されている URL/ドメインWebex Callingサービスのドメインと URL

  • セクションで示されているIPサブネット、ポート、およびプロトコルWebex CallingサービスのIPサブネット

  • Webex Meetings、メッセージング、その他のサービスを使用している場合は、この記事に記載されているドメイン/URL も開いている ことを確認してください。 Webex サービスのネットワーク要件

ファイアウォールのみを使用している場合、IP アドレス プールが動的であり、いつでも変更される可能性があるため、Webex Calling トラフィックを IP アドレスだけを使用してフィルタリングすることはサポートされません。 ルールを定期的に更新します。ファイアウォール ルール リストを更新しないと、ユーザー エクスペリエンスに影響を与える可能性があります。 Ciscoは特定の地理的領域またはクラウド サービス プロバイダーに基づいて、 IPアドレスのサブセットをフィルタリングすることを推奨していません。 地域別にフィルタリングすると、通話エクスペリエンスが大幅に低下する場合があります。

ファイアウォールがドメイン/ URLフィルタリングをサポートしていない場合、エンタープライズ プロキシ サーバー オプションを使用してください。 このオプションは、HTTPS シグナリング トラフィックをURL/ドメイン別にフィルタリング/許可しますWebex Callingファイアウォールに転送する前に、プロキシ サーバーでWebex Aware サービス。

対象: Webex Calling 、 UDPはメディアに対して Cisco が優先するトランスポート プロトコルであり、 UDPではSRTPのみを使用することを推奨します。 メディアのトランスポート プロトコルとしての TCP および TLS は、本番環境の Webex Calling ではサポートされていません。 これらのプロトコルの接続指向の性質は、可逆ネットワーク上のメディア品質に影響を与えます。 トランスポートプロトコルに関する質問がある場合は、サポートチケットを作成してください。

Webex Calling サービスのドメインと URL

URL の先頭に * が付されている場合 (例:*.webex.com)、最上位のドメインおよびすべてのサブドメインのサービスにアクセス可能でなければならないことを示しています。

ドメイン/ URL

説明

これらのドメイン/URL を使用した Webex アプリとデバイス

Cisco Webex サービス

*.broadcloudpbx.com

Control Hub から通話管理ポータルへのクロスローンチのための Webex 認証マイクロサービス。

Control Hub

*.broadcloud.com.au

オーストラリアの Webex Calling サービス。

すべて

*.broadcloud.eu

ヨーロッパの Webex Calling サービス。

すべて

*.broadcloudpbx.net

Calling クライアントの構成と管理サービス。

Webex アプリ

*.webex.com

*.cisco.com

Webex CallingとWebex Aware サービス

  1. アイデンティティ プロビジョニング

  2. アイデンティティ ストレージ

  3. 認証

  4. OAuth サービス

  5. オンボードのデバイス

  6. Cloud Connected UC

電話機を初めてネットワークに接続した場合、またはDHCPオプションを設定せずに初期設定にリセットした場合は、ゼロ タッチ プロビジョニングのためにデバイス アクティベーション サーバに接続します。 新しい電話は activate.cisco.com を使用し、11.2(1) 以前のファームウェアがリリースされた電話は、引き続きプロビジョニングに webapps.cisco.com を使用します。

デバイス ファームウェアとロケールの更新をからダウンロードしますbinary.webex.comを選択します。

12.0.3 バージョンより古い Cisco マルチプラットフォーム フォン(MPP)が、ポート 80 経由で sudirenewal.cisco.com にアクセスして、製造元インストール証明書(MIC)を更新し、セキュア一意デバイス識別子(SUDI)を持つことを許可します。 詳細は、フィールド通知を参照してください。

すべて

*.ucmgmt.cisco.com

Webex Calling サーバー

Control Hub

*.wbx2.com および *.ciscospark.com

クラウド認識、CSDM、WDM、Meetings などに使用されます。 これらのサービスは、オンボード中および後に、アプリおよびデバイスがWebex CallingおよびWebex Aware サービスに連絡するために必要です。

すべて

webexapis.com

アプリケーションとデバイスを管理する Webex マイクロサービス。

  1. プロファイル画像サービス

  2. ホワイトボード サービス

  3. Proximity サービス

  4. プレゼンス サービス

  5. 登録サービス

  6. カレンダー サービス

  7. 検索サービス

すべて

*.webexconnect.com

一般的なファイルストレージに関連する Webex Messaging サービス:

  1. ユーザー ファイル、

  2. トランスコードされたファイル、

  3. 画像

  4. スクリーンショット

  5. ホワイトボード コンテキスト、

  6. クライアントとデバイスのログ、

  7. プロファイル画像

  8. ブランド ロゴ、

  9. ログ ファイル

  10. CSV エクスポート ファイルの一括インポート (Control Hub)

Webexアプリ メッセージング サービス。


 

2019 年 10 月に webexcontent.com を使用したファイル ストレージが clouddrive.com に置き換えられました

*.accompany.com

ユーザーの総合情報のインテグレーション

Webex アプリ

追加の Webex 関連サービス(サードパーティドメイン)

*.appdynamics.com

*.eum-appdynamics.com

パフォーマンストラッキング、エラーおよびクラッシュキャプチャ、セッションメトリックス。

Control Hub

*.huron-dev.com

トグルサービス、電話番号の注文、割り当てサービスのような Webex Calling マイクロサービス。

Control Hub

*.sipflash.com

デバイス管理サービス ファームウェア アップグレードと安全なオンボーディング目的。

Webex アプリ

*.walkme.com *.walkmeusercontent.com

Webex ユーザーガイドクライアント。 新規ユーザーのためにオンボードの方法と使用方法のツアーが提供されます。

WalkMe の詳細については、ここをクリックしてください

Webex アプリ

*.google.com

*.googleapis.com

モバイル デバイス上のWebexアプリへの通知 (例: 新しいメッセージ(コールに応答したとき)

IPサブネットの場合、これらのリンクを参照してください。

Google Firebase クラウドメッセージング (FCM) サービス

Apple Push Notification Service


 

APNS については、Apple がこのサービスのIPサブネットを列挙しています。

Webex アプリ

Webex Calling サービスの IP サブネット

Webex Calling サービスの IP サブネット

23.89.0.0/16

85.119.56.0/23

128.177.14.0/24

128.177.36.0/24

135.84.168.0/21

139.177.64.0/21

139.177.72.0/23

144.196.0.0/16

150.253.128.0/17

〒163.129.0.0/17

170.72.0.0/16

170.133.128.0/18

185.115.196.0/22

199.19.196.0/23

199.19.199.0/24

199.59.64.0/21

接続目的

ソース アドレス

ソース ポート

プロトコル

接続先アドレス

宛先ポート

Webex Calling へのコール信号 (SIP TLS)

ローカル ゲートウェイ外部 (NIC)

8000-65535

TCP

Webex Calling サービスの IP サブネット」を参照してください。

5062, 8934

これらの IP/ポートは、ローカル ゲートウェイ、デバイス、およびアプリケーション (ソース) から Webex Calling Cloud (宛先) へのアウトバウンド SIP-TLS 通話シグナリングに必要です。

ポート 5062(証明書ベースのトランクに必要)。 ポート 8934 および (登録ベースのトランクに必要

デバイス

5060-5080

8934

アプリケーション

一時的 (OS 依存)

Webex Calling (SIP TLS) からローカル ゲートウェイへのコール シグナリング

Webex Calling アドレス範囲。

Webex Calling サービスの IP サブネットを参照してください

8934

TCP

顧客がローカル ゲートウェイ用に選択した IP または IP 範囲

ローカル ゲートウェイ用に顧客が選択したポートまたはポート範囲

証明書ベースのローカル ゲートウェイに適用されます。 Webex Calling からローカル ゲートウェイへの接続を確立する必要があります。

登録ベースのローカル ゲートウェイは、ローカル ゲートウェイから作成された接続を再利用することで機能します。

接続先ポートは顧客が選択したトランクの設定

Webex Calling へのコール メディア (STUN、SRTP/SRTCP、T38)

ローカル ゲートウェイ外部 NIC

8000-48199*

UDP

Webex Calling サービスの IP サブネット」を参照してください。

5004、9000 (STUN ポート)

8500-8701,19560-65535 (UDP 上の SRTP)

  • これらの IP/ポートは、ローカルゲートウェイ、デバイス、アプリケーション(ソース)から Webex Calling クラウド(宛先)へのアウトバウンド SRTP コールメディアに必要です。

  • STUN、ICE ネゴシエーションが成功した組織内の通話の場合、クラウド内のメディアリレーが通信パスとして削除されます。 この場合、メディアフローはユーザーのアプリ/デバイス間で直接行われます。

    例: メディア最適化が成功した場合、アプリケーションはポート範囲 8500 ~ 8701 でメディアを相互に直接送信し、デバイスはポート範囲 19560 ~ 19661 でメディアを相互に直接送信します。

  • ファイアウォールが顧客のプレミス内で使用される特定のネットワーク トポロジでは、ネットワーク内の前述のソースおよび宛先ポート範囲にアクセスして、メディアをフロースルーできるようにします。

    例: アプリケーションの場合、ソースポートと宛先ポートの範囲 8500 ~ 8701 を許可します。

デバイス*

19560~19661

アプリケーション*

小惑星の一覧

Webex Calling からの通話メディア (SRTP/SRTCP、T38)

Webex Calling アドレス範囲。

Webex Calling サービスの IP サブネットを参照してください

19560-65535 ( UDP上のSRTP )

UDP

顧客がローカル ゲートウェイ用に選択した IP または IP 範囲

顧客がローカル ゲートウェイ用に選択したメディア ポート範囲

PSTN ゲートウェイへのコール信号 (SIP TLS)ローカル ゲートウェイ内部 NIC8000-65535

TCP

ITSP、PSTN GW または Unified CMPSTN オプションによって異なる (たとえば、Unified CM の 5060 または 5061)
PSTN ゲートウェイへのコール メディア (SRTP/SRTCP)ローカル ゲートウェイ内部 NIC

8000-48199*

UDP

ITSP、PSTN GW または Unified CMPSTN オプションに依存します(たとえば、Unified CM では通常 5060 または 5061)。

デバイスの構成とファームウェアの管理 (Cisco デバイス)

Webex Calling デバイス

一時的

TCP

3.20.185.219

3.130.87.169

3.134.166.179

72.163.10.96/27

72.163.15.64/26

72.163.15.128/26

72.163.24.0/23

72.163.10.128/25

173.37.146.128/25

173.36.127.0/26

173.36.127.128/26

173.37.26.0/23

173.37.149.96/27

192.133.220.0/26

192.133.220.64/26

443、6970、80

次の理由で必要です。

  1. エンタープライズ電話 (Cisco Unified CM) からWebex Callingへの移行。 参照先アップグレード.cisco.comをご覧ください。 cloudupgrader.webex.com はポートを使用します: ファームウェア移行プロセスの 6970,443。

  2. 16桁のアクティベーションコード(GDS)を使用したデバイス(MPP、会議室またはデスクフォン)のファームウェアのアップグレードと安全なオンボーディング

  3. CDA / EDOS の場合 - MACアドレス ベースのプロビジョニング。 新しいファームウェアを持つデバイス(MPP 電話、ATA、SPA ATA)で使用されます。

  4. 電話機が初めてネットワークに接続される場合、または初期設定へのリセット後に、 DHCPオプションが設定されていない場合、電話機はゼロ タッチ プロビジョニングのためにデバイス アクティベーション サーバに接続します。 新しい電話機の使用 アクティブ化.cisco.com代わりに webapps.cisco.com (ウェブアプリ) プロビジョニング用。 11.2(1) より前にリリースされたファームウェアを持つ電話機は、引き続き webapps.cisco.com を使用 します。 これらのすべてのIPサブネットを許可することを推奨します。

  5. 12.0.3 バージョンより古い Cisco マルチプラットフォーム フォン(MPP)が、sudirenewal.cisco.comにポート 80 経由でアクセスして、製造元インストール証明書(MIC)を更新し、セキュア一意デバイス識別子(SUDI)を持つことを許可します。 詳細は、フィールド通知を参照してください。

アプリケーションの構成

Webex Calling アプリケーション

一時的

TCP

62.109.192.0/18

64.68.96.0/19

150.253.128.0/17

207.182.160.0/19

443, 8443

Idbroker 認証、クライアント用のアプリケーション構成サービス、セルフケアのためのブラウザ ベースのウェブ アクセス、および管理インターフェイス アクセスに使用されます。

デバイス時間同期 (NTP)

Webex Calling デバイス

51494

UDP

Webex Calling サービスの IP サブネット」を参照してください。

123

これらの IP アドレスは、デバイス(MPP 電話、ATA、SPA ATA)の時間同期に必要です。

デバイスの名前解決とアプリケーションの名前解決

Webex Calling デバイス

一時的

UDPおよびTCP

主催者が定義

53

DNS ルックアップに使用され、クラウド内の Webex サーバーの IP アドレスを検出します。

通常の DNS ルックアップは UDP で行われますが、クエリ応答が UDP パケットに収まらない場合は、TCP が必要な場合があります。

アプリケーション時間同期

Webex Calling アプリケーション

123

UDP

主催者が定義

123

CScan

ウェブ ベースのネットワークの準備と事前資格確認ツールWebex Calling

一時的

TCP

Webex Calling サービスの IP サブネット」を参照してください。

8934 および 443

Webex Calling用のウェブ ベースのネットワーク準備事前検証ツール 。 詳細については、cscan.webex.com を参照してください。

UDP

1969~19760 年

追加のWebex CallingとWebex Aware サービス(サードパーティ)

プッシュ通知 APNS および FCM サービス

Webex Calling アプリケーション

一時的

TCP

リンクの下に記載されているIPサブネットを参照してください

Apple プッシュ通知サービス (APNS)

Google-Firebase クラウドメッセージング (FCM)

443、2197、5228、5229、5230、5223

モバイル デバイス上のWebexアプリへの通知 (例: 新しいメッセージを受信したとき、またはコールに応答したとき)


 
  • † CUBE メディアポート範囲は、rtp ポート範囲で構成可能です。

  • *デバイスとアプリケーションのメディア ポートは、SRTP ポート レイジの任意の場所に動的に割り当てられます。 SRTP ポートは偶数番号のポートであり、対応する SRTCP ポートは連続した奇数番号のポートで割り当てられます。

  • アプリとデバイスに対してプロキシ サーバーアドレスが構成されている場合、シグナリング トラフィックはプロキシに送信されます。 メディアが UDP 経由で SRTP を転送すると、プロキシ サーバの代わりにファイアウォールに直接フローされます。

  • エンタープライズ ネットワーク内で NTP および DNS サービスを使用している場合は、ファイアウォールを介してポート 53 および 123 を開きます。

Webex Meetings/Messaging - ネットワーク要件

通話履歴、ディレクトリ検索、ミーティングなどのサービスのために、MPP デバイスを Webex Cloud にオンボードします。 これらの Webex サービスのネットワーク要件は 、Webex サービスのネットワーク要件に示されています。 Webex アプリからミーティング、メッセージング、その他のサービスを使用している場合、この記事で説明されているドメイン/URL/アドレスが開いていることを確認してください。

リファレンス

Webex Callingの新機能については、以下を参照してください。 Webex Callingの新機能

Webex Callingのセキュリティ要件については、次を参照してください。投稿記事

Interactive Connectivity Establishment (ICE) を使用したWebex Calling のメディア最適化投稿記事

マニュアルの改訂履歴

日付

この記事に次の変更を行いました

2024年5月6日。

Webex Calling メディア仕様の両方の SRTP/SRTCP ポート範囲の使用方法を更新しました。

2024年4月3日。

Webex Calling サービスの IP サブネットを 163.129.0.0/17 で更新し、インド地域の Webex Calling 市場拡大に対応しました。

2023年12月18日。

Cisco MPP 電話の MIC 更新のデバイス設定とファームウェア管理には、sudirenewal.cisco.com の URL とポート 80 要件が含まれています。

2023年12月11日。

Webex Calling サービスの IP サブネットを更新し、より大きな IP アドレスを追加しました。

150.253.209.128/25 – 150.253.128/17 に変更

2023年11月29日。

Webex Calling サービスの IP サブネットを更新し、将来の成長のために Webex Calling リージョンの拡張に対応するために、より大きな IP アドレスを追加しました。

144.196.33.0/25 – 144.196.0/16 に変更

Webex Calling (SIP TLS) および Webex Calling へのコール メディア (STUN、SRTP) の下の Webex Calling サービス セクションの IP サブネットが更新され、証明書ベースのトランキングとローカル ゲートウェイのファイアウォールの要件が明確になりました。

2023 年 8 月 14 日

Edge および Webex Calling サービスのキャパシティ要件の増加をサポートするために、次の IP アドレス 144.196.33.0/25 および 150.253.156.128/25 を追加しました。


 

この IP 範囲は、米国地域でのみサポートされています。

2023 年 7 月 5 日

リンクの追加https://binaries.webex.comCisco MPP ファームウェアをインストールします。

2023 年 3 月 7 日

記事全体を見直し、次の内容を追加しました。

  1. プロキシ サポートに含まれるオプション。

  2. 変更された Calling フロー図

  3. Webex CallingおよびWebex Aware サービスの簡素化されたドメイン/URL/ IPサブネット部分

  4. Webex Calling および Webex Aware サービスに 170.72.0.0/16 IP サブネット範囲を追加しました。

    次の範囲を削除しました 170.72.231.0、170.72.231.10、170.72.231.161 および 170.72.242.0/24

2023年3月5日

記事を更新して次の内容を追加します。

  • アプリケーションで使用されるUDP- SRTPポート範囲 (8500-8700) を追加しました。

  • プッシュ通知 APNS および FCM サービス用のポートを追加しました。

  • CScan ポート範囲をUDPとTCP用に分割します。

  • 「参照」セクションを追加。

2022 年 11 月 15 日

デバイス設定とファームウェア管理 (Cisco デバイス) に次の IP アドレスを追加しました。

  • 170.72.231.0

  • 170.72.231.10

  • 170.72.231.161

デバイス設定とファームウェア管理 (Cisco デバイス) から以下の IP アドレスを削除しました。

  • 3.20.118.133

  • 3.20.228.133

  • 3.23.144.213

  • 3.130.125.44

  • 3.132.162.62

  • 3.140.117.199

  • 18.232.241.58

  • 35.168.211.203

  • 50.16.236.139

  • 52.45.157.48

  • 54.145.130.71

  • 54.156.13.25

  • 52.26.82.54

  • 54.68.1.225

2022 年 11 月 14 日

Webex CallingサービスにIPサブネット 170.72.242.0/24 を追加しました。

2022 年 9 月 8 日

Cisco MPP ファームウェアは を使用するhttps://binaries.webex.comをすべての地域での MPP ファームウェア アップグレードの主催者URLとして使用しています。 この変更はファームウェア アップグレード のパフォーマンスを改善します。

2022 年 8 月 30 日

デバイス構成とファームウェア管理 (Cisco デバイス)、アプリケーション構成、およびポートテーブルの CScan 行からポート 80 の参照を削除しました。

2022 年 8 月 18 日木曜日

ソリューションに変更はありません。 Webex Calling (SIP TLS) への通話シグナリングの宛先ポート 5062 (証明書ベースのトランクに必要)、8934 (登録ベース トランクに必要) を更新しました。

2022 年 7 月 26 日

Cisco 840/860 デバイスのファームウェア アップグレードに必要な 54.68.1.225 IP アドレスを追加しました。

2022 年 7 月 21 日

通話シグナリングの宛先ポート 5062、8934 を Webex Calling (SIP TLS) に更新しました。

2022 年 7 月 14 日

Webex Awareサービスのすべての機能をサポートする URL を追加しました。

Webex CallingサービスにIPサブネット 23.89.154.0/25 を追加しました。

2022 年 6 月 27 日

サイト サービスのドメインと URL Webex Callingしました。

*.broadcloudpbx.com

*.broadcloud.com.au

*.broadcloud.eu

*.broadcloudpbx.net

2022 年 6 月 15 日

[IP アドレス] の下に以下 のポートとプロトコルを追加し、Webex Callingしました

  • 接続目的: Webex 機能

  • ソース アドレス: Webex Calling デバイス

  • ソースポート: 一時的

  • プロトコル TCP

  • 宛先アドレス: 次で定義されたIPサブネットとドメインを参照しますWebex Meetings/Messaging - ネットワーク要件。

  • 宛先ポート: 443

    注意: Webex CallingデバイスはこれらのIPアドレスとドメインを使用して、ディレクトリ、通話履歴、ミーティングなどのWebexクラウド サービスと連携します。

メッセージ - ネットワーク Webex Meetingsセクションの更新情報

2022 年 5 月 24 日

Webex Calling サービスに IP サブネット 52.26.82.54/24 を 52.26.82.54/32 に追加しました

2022 年 5 月 6 日

以下のサービスに IP サブネット 52.26.82.54/24 Webex Callingしました

2022 年 4 月 7 日

ローカル ゲートウェイの内部および外部 UDP ポート範囲を 8000-48198 に更新しました†

2022 年 4 月 5 日

このサービスに以下の IP サブネットWebex Callingしました。

  • 23.89.40.0/25

  • 23.89.1.128/25

2022 年 3 月 29 日

このサービスに以下の IP サブネットWebex Callingしました。

  • 23.89.33.0/24

  • 150.253.209.128/25

2021 年 9 月 20 日

Webex Calling サービスに 次の 4 つの新しい IP サブネットが追加されました。

  • 23.89.76.128/25

  • 170.72.29.0/24

  • 170.72.17.128/25

  • 170.72.0.128/25

2021 年 4 月 2 日

Webex アプリで Webex Calling の用途をサポートするために、[Webex Calling サービスのドメインと URL] に *.ciscospark.com が追加されました。

2021 年 3 月 25 日

activate.cisco.com に次の新しい IP 範囲が 6 つ追加され、2021 年 5 月 8 日から有効になります。

  • 72.163.15.64/26

  • 72.163.15.128/26

  • 173.36.127.0/26

  • 173.36.127.128/26

  • 192.133.220.0/26

  • 192.133.220.64/26

2021 年 3 月 4 日

ファイアウォールの構成を容易に理解できるように、Webex Calling の個別の IP とより小さい IP 範囲を別のテーブルの簡素化された範囲に置き換えました。

2021 年 2 月 26 日

2021 年 4 月に Webex Calling で利用可能なインタラクティブ接続性の高さ (ICE) をサポートするために、通話メディアの宛先ポートとして Webex Calling (STUN、SRTP) に 5004 が追加されました。

2021 年 2 月 22 日

ドメインと URL が別のテーブル内に表示されるようになりました。

IP アドレスとポートの表は、同じサービスのグループ IP アドレスに調整されます。

IPアドレスとポートのテーブルへの「注」列の追加は、要件の理解を支援するものです。

以下のIPアドレスをデバイス構成とファームウェア管理の簡素化された範囲に移動 (Ciscoデバイス):

activate.cisco.com

  • 72.163.10.125 -> 72.163.10.96/27

  • 173.37.149.125 -> 173.37.149.96/27

webapps.cisco.com

  • 173.37.146.134 -> 173.37.146.128/25

  • 72.163.10.134 -> 72.163.10.128/25

2021 年 3 月にオーストラリアで、 Cisco Webexクライアントが新しいDNS SRV をポイントするため、アプリケーション構成に次のIPアドレスを追加します。

  • 199.59.64.237

  • 199.59.67.237

2021 年 1 月 21 日

次の IP アドレスをデバイス設定とファームウェア管理 (Cisco デバイス) に追加しました。

  • 3.134.166.179

  • 50.16.236.139

  • 54.145.130.71

  • 72.163.10.125

  • 72.163.24.0/23

  • 173.37.26.0/23

  • 173.37.146.134

デバイス設定とファームウェア管理 (Cisco デバイス) から以下の IP アドレスを削除しました。

  • 35.172.26.181

  • 52.86.172.220

  • 52.203.31.41

次の IP アドレスをアプリケーション構成に追加しました。

  • 62.109.192.0/19

  • 64.68.96.0/19

  • 207.182.160.0/19

  • 150.253.128.0/17

アプリケーション構成から次の IP アドレスを削除しました。

  • 64.68.99.6

  • 64.68.100.6

アプリケーション設定から次のポート番号を削除しました。

  • 1081, 2208, 5222, 5280-5281, 52644-52645

次のドメインをアプリケーション構成に追加しました。

  • idbroker-b-us.webex.com

  • idbroker-eu.webex.com

  • ty6-wxt-jp.bcld.webex.com

  • os1-wxt-jp.bcld.webex.com

2020年12月23日

ポート参照画像に新しいアプリケーション構成 IP アドレスを追加しました。

2020年12月22日

テーブルのアプリケーション構成行が更新され、次の IP アドレスが含まれます。 135.84.169.186 および 135.84.170.186

これらのIPアドレスが追加されるまでネットワーク図が非表示になります。

2020年12月11日

サポートされているカナダ ドメインの [デバイス] 構成とファームウェア管理 (Cisco デバイス) および [アプリケーション] 構成行を更新しました。

2020年10月16日

以下の IP アドレスを使用して、通話シグナリングおよびメディア エントリを更新しました。

  • 139.177.64.0/24

  • 139.177.65.0/24

  • 139.177.66.0/24

  • 139.177.67.0/24

  • 139.177.68.0/24

  • 139.177.69.0/24

  • 139.177.70.0/24

  • 139.177.71.0/24

  • 139.177.72.0/24

  • 139.177.73.0/24

2020 年 9 月 23 日

CScan では、199.59.64.156 を 199.59.64.197 に置き換えました。

2020 年 8 月 14 日

カナダのデータセンターの導入をサポートするために、さらに多くの IP アドレスが追加されました。

Webex Calling への信号発信 (SIP TLS) — 135.84.173.0/25、135.84.174.0/25、199.19.197.0/24、199.19.199.0/24

2020 年 8 月 12 日

カナダのデータセンターの導入をサポートするために、さらに多くの IP アドレスが追加されました。

  • Webex Calling への信号発信 (SRTP)—135.84.173.0/25、135.84.174.0/25、199.19.197.0/24、199.19.199.0/24

  • 公にアドレスされているエンドポイント (SIP TLS)—135.84.173.0/25,135.84.174.0/25, 199.19.197.0/24, 199.199.0/24.

  • デバイスの構成とファームウェアの管理 (Cisco デバイス) —135.84.173.155、135.84.174.155

  • デバイス時刻の同期—135.84.173.152、135.84.174.152

  • アプリケーションの構成—135.84.173.154、135.84.174.154

2020 年 7 月 22 日

カナダのデータセンターの導入をサポートするために、次の IP アドレスを追加しました。 135.84.173.146

2020 年 6 月 9 日

CScan エントリに次の変更を行いました:

  • IP アドレスの 1 つを修正しました。199.59.67.156 から 199.59.64.156 に変更されました。

  • 新機能には新しいポートと UDP が必要です—19560-19760

2020/03/11

次のドメインとIPアドレスをアプリケーション構成に追加しました:

  • bcld. webex. .com —135.84.169.150

  • client-jp.bcld.webex.com

  • idbroker.webex.com—64.68.99.6, 64.68.100.6

追加の IP アドレスを持つ以下のドメインをデバイスの設定とファームウェア管理に更新しました:

  • cisco.webexcalling.eu—85.119.56.198、85.119.57.198

  • webapps. cisco .com —72.163.10.134

  • activation.webex.com—35.172.26.181, 52.86.172.220

  • cloudupgrader —3.130.87.169、3.20.185.219

2020 年 2 月 27 日

次のドメインとポートをデバイス構成とファームウェア管理に追加しました:

cloudupgrader.webex.com—443, 6970

この投稿記事は役に立ちましたか?
Webex Calling 設定ワークフロー