ウォーター マーク
2020年7月27日 | 回表示 | 人がこの投稿が役に立ったと考えています

概要

Cisco Webex Calling の導入

エンタープライズ グレードのクラウド コール、モバイル性、PBX 機能を、Cisco Webex Teams のメッセージングとミーティング機能、Webex Calling ソフト クライアントまたは Cisco デバイスのコール機能と共に使用できたらよいと思いませんか。 これこそが、Webex Calling が果たそうとしているユーザーへの義務です。

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

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

  • すべてのユーザーのための Webex Teams へのアクセス

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

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

表 1. 管理可能な機能

機能

説明

自動音声応答

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

コール キュー

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

コールピックアップ

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

コール パーク

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

ハントグループ

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

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

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

ページング グループ

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

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

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

ユーザーは、Calling ユーザー ポータルとクロス起動する https://settings.webex.com で、以下の機能を構成することができます。

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

機能

説明

匿名通話の拒否

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

ビジネスの継続性

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

コール転送

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

選択的コール転送

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

コール通知

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

通話待機

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

応答不可

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

Office Anywhere

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

優先アラート

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

リモート オフィス

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

選択通話承諾

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

匿名通話の拒否

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

シーケンシャル リング

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

同時リング

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

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

Cisco Webex Control Hub (https://admin.webex.com) は、Webex Calling と統合された管理ポータルであり、注文と構成を合理化し、バンドルされたオファー、つまり Webex Calling、Webex Teams、および Webex Meetings の管理を一元化します。

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

Calling 管理ポータルでは、顧客はコール機能の高度な設定にアクセスしでき、サービス保証についてのクイック ビューを確認できます。 サービス保証は、コールが良好であるか、中程度であるか、または低品質であるかを示すことによって、ビジネス単位内の複数のロケーションにコール品質メトリックを提供します。 コール品質に関するフィードバックをすぐに受け取れるので、パートナーおよび顧客管理者が、顧客に最高品質のサービスを提供することが可能になります。

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

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

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

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

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

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

Cisco Webex Control Hub のツアーを体験する

Control Hub は、組織の管理、ユーザーの管理、サービスの割り当て、導入の傾向やコール品質の分析などを行うための、Web ベースのシングル ゴー インターフェイスです。

Webex 組織を立ち上げて稼動させるにあたり、Control Hub にメール アドレスを入力して、Webex Teams に参加するよう少数のユーザーを招待することをお勧めします。 コールを含む、提供されるサービスを使用するようにユーザーを促し、彼らの満足度に関するフィードバックを提供することを求めます。 準備が完了したら、いつでもユーザーを追加することができます。


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

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

はじめに

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

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

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

設定の確認

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

ユーザーの追加

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

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

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

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

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

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

ユーザーが Webex Teams を使用して開始できるようにするには、追加したユーザにサービスを割り当てる必要があります。

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

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

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

ユーザーを支援する

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

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

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

ローカル ゲートウェイをロケーションに割り当てるには、Cisco Webex Control Hub を使用します。その後、Control Hub から、CUBE 上で構成できるパラメータが提供されます。 これらの手順により、ローカル ゲートウェイがクラウドに登録され、ゲートウェイを通じて 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 の展開を示しています。

BroadCloud は、顧客の Webex Calling 宛先とマッチしないコールは、ローカルゲートウェイに送信します。 これには PSTN 番号と Unified CM 内部拡張機能が含まれています。BroadCloud はこれらを認識できません。 ローカル ゲートウェイは、BroadCloud からのすべてのコールを Unified CM にルーティングします。またその逆も行います。 Unified CM は、着信コールを、既存のダイヤル プランに従ってローカルの宛先または PSTN にルーティングします。 Unified CM のダイヤル プランは、番号を +E.164 として正規化します。 PSTN ゲートウェイとしては、専用のものと、ローカル ゲートウェイに共存しているものがあり得ます。

専用の PSTN ゲートウェイ

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

共存型 PSTN ゲートウェイ

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

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

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

Webex Calling から Unified CM へのコール

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

既存の 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 形式でなければなりません。) BroadCloud のルーティングロジックによって、コールは確実に意図した Webex Calling デバイスに送信されます。

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

サービス クラス (CoS)

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

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

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

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

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

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

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

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

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

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

このガイドでは、『Cisco コラボレーション オンプレミス展開 (CVD) のための優先アーキテクチャ』で説明されている、現在のベスト プラクティスに基づいた既存のインストールを想定しています。 最新版は、https://www.cisco.com/c/en/us/support/unified-communications/unified-communications-system/products-implementation-design で入手できます。

推奨されるダイヤル プランの設計は、最新バージョンの『Cisco コラボレーション システム SRND』の「ダイヤルプラン」の章に記載されている、https://www.cisco.com/go/ucsrnd で利用可能な設計方法に従うものです。

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

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

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

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

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

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

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

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

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

BroadCloud への到達可能性

図 3. BroadCloud の宛先をダイヤル プランに追加する

このダイヤル プランが BroadCloud に接続できるようにするには、BroadCloud のすべての宛先を代表するパーティションを作成し ("BroadCloud")、BroadCloud の各 DID の +E.164 ルート パターンを、このパーティションに追加する必要があります。 このルートパターンは、1 つのメンバーのみを持つルートリストを参照します。 そのメンバーとは、BroadCloud へのコールのための、ローカル ゲートウェイへの SIP トランクを持つルート グループのことです。 すべてのダイヤル先は、エンドポイントに登録された Unified CM から発信するコールのためのダイヤリング正規化翻訳パターンを使用するか、PSTN から発信するコールのための、インバウンド着信側の翻訳を使用して、+E.164 に正規化されるため、使用するダイヤル習慣から独立した、BroadCloud 内の宛先に到着するには、この単一セットの E.164 ルート パターンで十分です。

例えば、ユーザーが「914085550165」にダイヤルした場合、パーティション「UStoE164」内のダイヤル正規化翻訳パターンが、このダイヤル文字列を「+14085550165」に正規化します。その後、パーティション「BroadCloud」の BroadCloud 宛先のためのルート パターンとの間で、マッチングが行われます。 Unified CM は最終的、ローカル ゲートウェイにコールを送信します。

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

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

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

BroadCloud の宛先にエンタープライズの短縮ダイヤルを追加するには、BroadCloud のロケーションから「BroadCloud」パーティションへの、それぞれのダイヤリング正規化翻訳パターンを追加します (たとえばこの図での「8101XX」)。 正規化の後、「BroadCloud」パーティションでルート パターンとのマッチングを行ってから、コールは再び BroadCloud に送信されます。

BroadCloud コールのための短縮ダイヤル正規化翻訳パターンを「ESN」パーティションに追加することは、推奨しません。この構成では、望ましくないコールのルーティング ループが発生する可能性があるからです。

サービスプロバイダと付加価値再販業者の Webex Calling の違い

同じ Webex Calling プラットフォームを利用する 2 つの独立したコール オファーがあります。 1 つはサービス プロバイダー (SP) とその顧客向けのもの、もう 1 つは付加価値再販業者 (VAR) とその顧客向けのものです。 ほとんどの点でこのオファーは同一のものなので、どちらも Webex Calling と呼んでいます。 しかし、いくつかの違いがあり、これらの違いを理解する必要がある場合は、それらが SP または VAR に適用されるかどうかを確認してください。

どちらも Control Hub で管理され、Calling 管理ポータルをクロス起動する一方で、重要な違いがいくつかあります。

SP は、コール ポータルおよびアプリのブランディングを行うため、自社の PSTN サービスを顧客にバンドルして提供するか、またはローカル ゲートウェイ展開を活用する必要があります。 また、SP は独自の Tier 1 サポートを提供する必要もあります。

一方、VAR は Cisco が提供するブランディングを使用します。 VAR は規制の下に置かれるサービス プロバイダーではないため、PSTN サービスを提供することはできません。 PSTN サービスはエンタープライズ ローカル ゲートウェイ展開を通じて活用する必要があります。 VAR もまた、独自の Tier 1 サポートを提供します。または Cisco を使用することもできます。 どちらもメディア品質メトリックスによるサービス保証を提供し、Webex Teams とミーティングをコール アプリケーションと共にバンドルすることができます。

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

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

  • CLICKTOCALL: または CLICKTOCALL://

  • SIP: または SIP:

  • TEL: または TEL:

  • WEBEXTEL: または WEBEXTEL://

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

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

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

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

  2. 各プロトコルに対して Webex Teams を選択し ます。

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

Mac OS で、Webex Teams より前に別のアプリがコール プロトコルに登録されていた場合には、ユーザーは Webex Teams アプリを既定のコール オプションに設定する必要があります。

Mac 版 Webex Teams では、Webex Teams が一般環境設定の下の [コールの開始] 設定に選択されていることを、ユーザーは確認できます。 また、Outlook の連絡先番号をクリックしたときに Webex Teams でコールを行うようにしたい場合には、[常に Microsoft Outlook に接続する] をオンにします。

ウォーター マーク
2020年7月27日| 回表示 | 人がこの投稿が役に立ったと考えています

Webex Calling のための環境を準備する

環境の準備 組織のために Webex Calling を構成する PSTN アクセスにローカル ゲートウェイを構成する (VAR のみ) UCM の構成 Webex Callingの機能を構成する ユーザーの構成と管理 デバイスの構成と管理

通話のための要件

ライセンス

Webex Calling は、Cisco Collaboration フレックス プランで使用できます。 Enterprise Agreement (EA) プラン (50% ワークスぺースデバイスを含むすべてのユーザーに対して) またはネームユーザー (ニュー) プラン (一部またはすべてのユーザー) を購入する必要があります。

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

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

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


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

  • ワークスペース (Common Area とも呼ばれます) —休憩会議室、ロビー、会議室などのエリアに適した制限付きの通話機能を備えた基本的なダイヤルトーンを探している場合に、このオプションを選択します。

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

帯域幅要件

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

PSTN のローカル ゲートウェイ

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

サポートされている機器

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

表 1. サポートされている機器

デバイス カテゴリ

デバイス タイプ

ベーシック

  • Cisco IP Phone 6800 シリーズとマルチプラットフォーム ファームウェア

  • Cisco IP Phone 7800 シリーズとマルチプラットフォーム ファームウェア

アナログ電話アダプター

Cisco ATA 191 および 192 とマルチプラットフォーム ファームウェア

会議

  • Cisco IP Conference Phone 7832 とマルチプラットフォーム ファームウェア

  • Cisco IP Conference Phone 8832 とマルチプラットフォーム ファームウェア

詳細

  • Cisco IP DECT 6800 シリーズとマルチプラットフォーム ファームウェア

  • Cisco IP Phone 8800 シリーズとマルチプラットフォーム ファームウェア

[アクセサリ]

キー拡張モジュール

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

ファイアウォール :

Cisco Webex Calling のポート参照情報に記載されているファイアウォール要件を満たし https://help.webex.com/b2exve/ます。

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

全般的な前提条件

Cisco Webex Calling 用のローカル ゲートウェイを構成するには、次の条件が必要となります

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

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

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

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

    詳細は、『Cisco Unified Border Element (CUBE) エンタープライズ構成ガイド』を参照してください。https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book.html

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

展開に、次のサポートされているハードウェアとソフトウェアに含まれる1つ以上のローカルゲートウェイ (Cisco キューブ (IP ベース接続の場合) または Cisco IOS ゲートウェイ (TDM ベースの接続の場合)) があることを確認してください。

  • ISR 4321, 4331, 4351, 4431, 4451 (ios-xe 16.9.5 または ios-xe 16.12.3 以降), 4461 (ios-xe 17.2.1 r)

  • CSR 1000v (vCUBE) (IOS-XE 16.9.5 および16.12.3 以降)

  • ISR 1100 シリーズ (IOS-XE 16.12.3 以降) ( IP ベースの接続のみ)


IOS-XE 16.10.x リリースは、ローカル ゲートウェイの導入には対応していません。

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

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

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

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

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

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

  • CUBE を構成する際には、Control Hub から取得した SIP ダイジェスト資格情報を使用する必要があります (この手順は、続く構成の一部です)

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

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

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

ローカル ゲートウェイでのファイアウォールと NAT トラバーサルの要件

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

ウォーター マーク
2020年7月27日| 回表示 | 人がこの投稿が役に立ったと考えています

組織のために Cisco Webex Calling を構成する

1

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


 

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

2

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

3

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

4

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

5

[次へ] をクリックし ます: 既定の場所。

6

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

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

 

デフォルトのロケーションの国が、パートナーにより選択された契約国として設定されます。変更することはできません。 後ほど、別の国に他のロケーションを作成することはできますが、それらは、この手順の前の部分で選択した契約国に対応する、地区のデータセンターにホストされることに注意してください。 たとえば、1つのロケーションを米国に、1つを英国にすることができます。


 
7

オプショナル この統合が必要な場合は、Skype for business でトグルし、[次へ] をクリックし ます。


 

有効にすると、このロケーション全体の設定により、すべての既存の Calling アプリが Calling for S4B に変換されます。 このアプリは、Skype for Business for Windows と共に実行され、インテグレーションされた PSTN コール機能を提供します。

8

[次へ] を選択します。

9

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

10

[完了] を選択します。

始める前に

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

  • ロケーションの住所

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

1

の顧客ビューから、[ https://admin.webex.comサービスの > 通話場所] に移動し > て、[場所の追加] をクリックし ます。

新しいロケーションは、初回のセットアップ ウィザードを使用して選択した契約国に対応する、地区のデータセンターにホストされることに注意してください。

2

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

  • ロケーション名—ロケーションを識別するための一意の名前を入力します。
  • —ロケーションに関連付ける国を選択します。 たとえば、米国では1つのロケーション (本社) を作成し、英国で別の場所 (ブランチ) を生成することができます。 選択した国に応じて、その後の住所のフィールドが決まります。 ここに記載されているものは、例として米国アドレス規約を使用しています。
  • 言語-ロケーションの言語を選択します。
  • 住所—ロケーションの郵送先住所の主要部分を入力します。
  • 都市—このロケーションが所在する都市を入力します。
  • —ドロップダウンから州を選択します。
  • 郵便番号—郵便番号を入力します。電話番号—ロケーションの主要な連絡先に到達できる電話番号を入力します。
3

(任意) このロケーションのユーザーが Microsoft Skype for Business デスクトップ アプリを使用したコラボレーションの続行を希望する場合、Skype for business でトグルします。ユーザーは組織外から電話をかけたり、受けたりすることができます。また、Webex Calling S4B アプリが提供する高度なコール機能を利用することも可能です。 ユーザーは Webex Calling S4B 変換アプリをダウンロードしてインストールし、Microsoft Skype アプリで PSTN コールを開始または受信するときに、Webex Calling S4B アプリにクロス起動されるようにする必要があります。


 

これは、Webex Calling アプリとの Skype for Business の統合を選択したり外したりすることができる唯一の時間です。ロケーションが作成されると、この設定を変更するオプションがなくなります。

4

[ 保存] をクリックし て、番号を今すぐ追加するか、または後で加えるかを選択します。

5

[今すぐ追加] をクリックした場合は 、次のいずれかのオプションを選択します。

  • クラウド接続 PSTN —ローカル ハードウェアへの多大な投資を必要としないクラウド ソリューションを探している場合は、このオプションを選択し、選択する CCP プロバイダーを選択します。


     

    ロケーションの国でサポートされているサービス プロバイダーのみが表示されます。

  • ローカル ゲートウェイ-現在の PSTN プロバイダーを保持する場合、またはクラウド サイトで非クラウド サイトに接続し、共通のダイヤル プラン (ハイブリッド オプション) を使用する場合に、このオプションを選択できます。 複数のロケーションがある場合、すべてのクラウドに一度に移動する必要はありません。
6

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

7

電話番号を コンマ区切りの値で入力し、[検証] をクリックし ます。

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

番号の書式は、ロケーションの所在する国に応じ、ダイヤリングに関する地元の要件に従って定められます。 たとえば、国コードが必要な場合には、コードを付けて、またはコードを分け、前に置いて入力します。

8

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

次のタスク

場所を作成した後、その場所の緊急911サービスを有効にすることができます。 詳細については、Webex Calling の redsky エマージェンシー911サービスを参照してください

Control Hub で顧客組織を作成すると、最初に作成したロケーションが自動的にデフォルトの場所になります。 組織に追加するユーザーは、特に指定しない限り、このデフォルトの場所に割り当てられます。 任意のロケーションをデフォルトのロケーションにすることができますが、デフォルトのロケーションを削除することはできないことに注意してください。

始める前に


ロケーションに関連付けられているユーザーとワークスペースのリストを取得するには: [サービス番号] に移動 > し、ドロップダウンメニューから、削除するロケーションを選択します。 https://help.webex.com/en-us/0qse04/Delete-a-User-Account-from-Your-Organization-in-Cisco-Webex-Control-Hub 場所を削除する前に、これらのユーザーとワークスペースを削除する必要があります。

1

の顧客ビューから、[ https://admin.webex.comサービスの > 通話場所 > ] に移動し、削除するロケーションを選択します。

2

ロケーション名の隣にある [詳細] をクリックし、[ロケーションの削除] を 選択して、 そのロケーションを削除することを確認します。

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

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


既存の場所については、緊急時の911サービスを有効にすることができます。 詳細については、Webex Calling の redsky エマージェンシー911サービスを参照してください

1

の顧客ビューから https://admin.webex.com、[サービスの通話場所] に移動し、 更新する場所を > > 選択します。

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

2

オプショナル[ PSTN 接続] の下で、すで に構成されているものに応じて、Cloud Connected PSTN またはローカルゲートウェイのいずれかを選択します。 [編集] をクリックして設定を変更して から、関連するリスクを承認し ます。 以下のオプションのいずれかを選択して、[保存] クリックします。

  • クラウド接続 PSTN —ローカル ハードウェアへの多大な投資を必要としないクラウド ソリューションを探している場合は、このオプションを選択し、選択する CCP プロバイダーを選択します。


     

    ロケーションの国でサポートされているサービス プロバイダーのみが表示されます。

  • ローカル ゲートウェイ-現在の PSTN プロバイダーを保持する場合、またはクラウド サイトで非クラウド サイトに接続し、共通のダイヤル プラン (ハイブリッド オプション) を使用する場合に、このオプションを選択します。 複数のロケーションがある場合、すべてのクラウドに一度に移動する必要はありません。

     

    このオプションは、価値が付加されたリセラーだけが利用できます。

3

ロケーションのメインの連絡先に到達できる主な番号を選択し ます。

4

この場所のボイスメールを確認するためにユーザーが発信できるボイスメール番号を選択します。

5

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

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

1

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

2

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

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

     

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

3

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

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

ユーザーへの影響:

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

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

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

始める前に

  • それぞれについて、ロケーションと固有の設定および番号を作成します。 ロケーションはローカル ゲートウェイを追加する前に存在する必要があります。

  • Webex Calling でのローカル ゲートウェイの要件について理解しておいてください。

  • 1 か所のロケーションに複数のゲートウェイを指定することはできませんが、同じゲートウェイを複数のロケーションに指定することはできます。

1

の顧客ビューから https://admin.webex.com、[サービスの通話場所] に移動し、 > > ローカルゲートウェイを追加する場所を選択します。

2

(オプション) [PSTN 接続] の下で、[クラウド接続 PSTN] を選択し、[編集] をクリックしてから、[続行] を選択して関連するリスクを承認します。

3

[ローカル ゲートウェイ] を選択し、[管理] をクリックしてから、ドロップダウン メニューから [新しいローカル ゲートウェイの作成] をクリックし ます。

4

Control Hub にゲートウェイを識別するための名前を入力し、チェック マークをクリックして変更を保存します。

ローカル ゲートウェイで構成することが必要な、関連するパラメーターが表示されます。 また、ローカル ゲートウェイをセキュアにするための、SIP ダイジェスト資格情報のセットも生成します。

5

画面に表示されるローカル ゲートウェイの情報に注意してください (登録ドメイントランク グループ OTG/DTG回線/ポート外向きプロキシ アドレス)。


 

オンプレミスのローカル ゲートウェイを構成するときに参照できるように、パラメーター情報を Control Hub からコピーして、ローカルのテキスト ファイルまたは文書にペーストしておくことを推奨します。

6

[ユーザー名の取得とパスワードのリセット] をクリックして、オンプレミスのローカル ゲートウェイで使用する認証資格情報の新しいセットを生成します。


 

この資格情報を紛失した場合には、Control Hub のゲートウェイ構成画面で再生性することが必要になります。 オンプレミスのローカル ゲートウェイを構成するときに参照できるように、これらの資格情報を Control Hub からコピーして、ローカルのテキスト ファイルまたは文書にペーストしておくことを推奨します。

次のタスク

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

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

1

の顧客ビューから https://admin.webex.com、[ サービス通話番号] に移動 > > します。

すべてのロケーションでの番号とそれに対応する情報を記した表が表示されます。 特定のロケーションをフィルタリングするには、[すべてのロケーション] ドロップダウンをクリックして、ロケーションを選択します。 この表には、番号が割り当てられた人物とそのステータスなどの情報が含まれてい ます。

2

オプショナル番号エントリの隣にある [アクション] の下でをクリックし、 次のいずれかのオプションを選択します。

  • 編集—現在ユーザーまたは場所に割り当てられているアクティブな番号を表示します。 このオプションをクリックすると、Calling 管理ポータルが表示されるので、変更を加えることができます。

  • アクティベーション-非アクティブステータスの番号については、このオプションは、注文で送信された Webex Calling ポート番号が完了した時点で利用可能になります。 番号をアクティベートした後、使用する準備ができると、その番号はアクティブになります。

  • 削除—非アクティブ ステータスで、現在ユーザーや場所に割り当てられていない番号では、このオプションが利用可能になります。

3

オプショナル[番号の追加] をクリックし、 必要な情報を入力して、ロケーションに最低1つの新しい番号を追加し、[保存] をクリックし ます。


 

有効なエントリは 、[ 番号の追加] フィールドにエラーメッセージが表示されている場合に、[検証済みの番号] フィールドに移動し ます。

番号はどの国の場合でも E.164 書式に従っている必要があります。ただし、米国では国内書式でも受け付けられます。

番号の書式は、ロケーションの所在する国に応じ、ダイヤリングに関する地元の要件に従って定められます。 たとえば、国コードが必要な場合には、コードを付けて、またはコードを分け、前に置いて入力します。

1

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

2

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

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

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


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

始める前に

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

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

https://admin.webex.com の顧客ビューから [設定] に移動して、[コール動作] までスクロールして、次のうちいずれかを選択します。 .

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

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

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


 

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

ウォーター マーク
2020年7月27日| 回表示 | 人がこの投稿が役に立ったと考えています

Webex Calling に IOS-XE でローカル ゲートウェイを構成する

組織のために Webex Calling を構成したら、それぞれの CLI インターフェイスを使用してローカル ゲートウェイを構成する必要があります。 ローカル ゲートウェイと Webex クラウド間のトランクは、ローカル ゲートウェイと Webex Calling Access SBC 間のメディア用の SIP TLS トランスポートとSRTPを使用して常に保護されます。

Webex Calling 展開にローカル ゲートウェイを設定するには、このタスク フローを使用します。 次のステップは、CLI インターフェイス自体で実行されます。 ローカル ゲートウェイと Webex Calling 間のトランクは、ローカル ゲートウェイと Webex Calling アクセス SBC の間のメディア用の SIP TLS トランスポートと SRTP を使用して常に保護されます。

始める前に

  • Webex Calling のローカル ゲートウェイの要件を満たします。

  • Control Hub でのローカル ゲートウェイを作成します。

  • このドキュメントで提供される構成ガイドラインは、既存の音声設定がない専用のローカル ゲートウェイ プラットフォームが配置されていることを前提としています。 既存の PSTN ゲートウェイまたは CUBE エンタープライズ展開が、Webex Calling に対するローカル ゲートウェイ機能も使用するように変更されている場合、適用された構成に注意を払い、行った変更の結果として既存のコール フローと機能が中断されないようにしてください。

  コマンドまたはアクション 目的
1

Cisco Webex Control Hub と Cisco Unified ボーダー エレメント間のパラメーター マッピング

この表は、Control Hub からのパラメーターと、ローカル ゲートウェイにマッピングされる場所の参照として使用します。

2

参照プラットフォーム構成を実行する

これらの手順をローカル ゲートウェイの共通のグローバル構成として実装します。 構成には、ベースライン プラットフォーム構成と信頼プールの更新が含まれます。

3

ローカル ゲートウェイを Webex Calling に登録する

4

展開に応じて 1 つ選択します。

ローカル ゲートウェイ上の呼び出しルーティングは、選択した Webex Calling 展開オプションに基づいています。 このセクションでは、IP PSTN 終端がローカル ゲートウェイと同じプラットフォーム上にあることを前提としています。 次の設定は、ローカルゲート ウェイ上のこれらのオプションのいずれかです。

  • オンプレミス IP PBX なしのローカル ゲートウェイ展開オプション。 ローカル ゲートウェイと IP PSTN CUBE は共存しています。

  • 既存の Unified CM 環境内のローカル ゲートウェイ展開オプション。 ローカル ゲートウェイと IP PSTN CUBE は共存しています。

表 1. Cisco Webex Control Hub とローカル ゲートウェイ間のパラメーター マッピング

Control Hub

ローカル ゲートウェイ

登録ドメイン:

Control Hub は、UCAPI から受信した LinePort からドメインを解析する必要があります。

example.com

registrar

example.com

トランク グループ OTG/DTG

sip profiles:

rule <rule-number> request ANY sip-header

From modify ">" ";otg=otgDtgId>"

回線/ポート

user@example.com

number: ユーザー

Outbound Proxy

outbound proxy (DNS name – SRV of the Access SBC)

SIP Username

username

SIP Password

パスワード

始める前に

  • NTP、ACL、イネーブル パスワード、マスターパスワード (IOS-XE 16.11.1 以降)、IP ルーティング、IP アドレスなどのベースライン プラットフォーム構成が、組織のポリシーと手順に従って構成されていることを確認します。

  • ローカル ゲートウェイの展開には、IOS-XE 16.9.3 以降または 16.11.1 以降が必要です。 IOS-SOCKS releases16.10.x はサポートされません

1

レイヤー 3 インターフェイスに有効でルーティング可能な IP アドレスが割り当てられていることを確認します。

interface GigabitEthernet0/0/0 description Interface facing PSTN and/or CUCM ip address 192.168.80.14 255.255.255.0 ! interface GigabitEthernet0/0/1 description Interface facing Webex Calling ip address 192.168.43.197 255.255.255.0
2

IOS-XE 16.11.1 以降を使用している場合、資格情報と共有秘密で使用する前に、以下に示すコマンドを使用してパスワードのマスター キーを事前に構成する必要があります。 Type 6 パスワードは、AES 暗号化とユーザー定義のマスター キーを使用して暗号化されます。

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

IP ネーム サーバーを構成して DNS ルックアップを有効にし、ping で到達できることを確認します。

LocalGateway#conf t 1 行ごとに 1 個ずつ設定コマンドを入力します。 CNTL/Z で終了します。 LocalGateway(config)#ip name-server 8.8.8.8 LocalGateway(config)#end
4

TLS 1.2 排他性とデフォルト ダミー Trustpoint の有効化:

  1. ダミー PKI Trustpoint を作成して、それを dummyTp で呼び出します

  2. デフォルトのシグナリング トラストポイントとしてトラストポイントを sip-ua 下に割り当てます

  3. Cn-san-validate server で設定されたアウトバウンド プロキシがローカル ゲートウェイで接続を確立することを保証するために必要です。 tenant 200 (後述) は、サーバーから受信した CN-SAN リストと一致します。

  4. 接続のセットアップにローカルクライアント証明書 (たとえば、mTLS) は必要ありませんが、TLS が機能するには暗号トラストポイントが必要です。

  5. V1.2 を排他的に有効化することで、TLS v1.0 および v1.1 を無効化します。

LocalGateway#conf terminal 1 行ごとに 1 個ずつ設定コマンドを入力します。 CNTL/Z で終了します。 LocalGateway(config)# LocalGateway(config)#crypto pki trustpoint dummyTp LocalGateway(ca-trustpoint)# revocation-check crl LocalGateway(ca-trustpoint)#exit LocalGateway(config)#sip-ua LocalGateway(config-sip-ua)# crypto signaling default trustpoint dummyTp cn-san-validate server LocalGateway(config-sip-ua)# transport tcp tls v1.2 LocalGateway(config-sip-ua)#end
5

ローカル ゲートウェイ Trustpool の更新:

デフォルトの Trustpool バンドルには、Webex Calling への TLS 接続の確立中のサーバー側の証明書の検証のための「DigiCert Root CA」証明書が含まれていません。

Trustpool バンドルは、最新の「Cisco Trusted Core Root Bundle」http://www.cisco.com/security/pki/ からダウンロードすることにより、更新されなければなりません。

  1. DigiCert Room CA 証明書が存在するかどうかを確認してください。

    LocalGateway# trustpool を表示 | DigiCert を含む
  2. 存在しない場合は、以下のとおり更新します。

    LocalGateway#conf terminal 1 行ごとに 1 個ずつ設定コマンドを入力します。 CNTL/Z で終了します。 LocalGateway(config)#crypto pki trustpool import clean url http://www.cisco.com/security/pki/trs/ios_core.p7b Reading file from http://www.cisco.com/security/pki/trs/ios_core.p7b Loading http://www.cisco.com/security/pki/trs/ios_core.p7b % PEM files import succeeded. LocalGateway(config)#end
  1. 確認:

    LocalGateway#show crypto pki trustpool | include DigiCert cn=DigiCert Global Root CA o=DigiCert Inc cn=DigiCert Global Root CA o=DigiCert Inc

始める前に

Control Hub の手順を完了して、場所を作成し、ローカル ゲートウェイを追加したことを確認します。 ここで示されるローカル ゲートウェイの例では、情報は Control Hub から取得されました。

1

次のコマンドを入力して、ローカル ゲートウェイ アプリケーションをオンにします。

LocalGateway#configure terminal LocalGateway(config)#voice service voip LocalGateway(conf-voi-serv)#ip address trusted list LocalGateway(cfg-iptrust-list)#ipv4 128.177.14.0 255.255.255.128 LocalGateway(cfg-iptrust-list)#ipv4 128.177.36.0 255.255.255.192 LocalGateway(cfg-iptrust-list)#ipv4 135.84.169.0 255.255.255.128 LocalGateway(cfg-iptrust-list)#ipv4 135.84.170.0 255.255.255.128 LocalGateway(cfg-iptrust-list)#ipv4 135.84.171.0 255.255.255.128 LocalGateway(cfg-iptrust-list)#ipv4 135.84.172.0 255.255.255.128 LocalGateway(cfg-iptrust-list)#ipv4 199.59.65.0 255.255.255.128 LocalGateway(cfg-iptrust-list)#ipv4 199.59.66.0 255.255.255.128 LocalGateway(cfg-iptrust-list)#ipv4 199.59.70.0 255.255.255.128 LocalGateway(cfg-iptrust-list)#ipv4 199.59.71.0 255.255.255.128 LocalGateway(cfg-iptrust-list)#ipv4 199.59.64.0 255.255.255.128 LocalGateway(cfg-iptrust-list)#ipv4 199.59.67.0 255.255.255.128 LocalGateway(cfg-iptrust-list)#ipv4 85.119.56.128 255.255.255.192 LocalGateway(cfg-iptrust-list)#ipv4 85.119.57.128 255.255.255.192 LocalGateway(cfg-iptrust-list)#ipv4 185.115.196.0 255.255.255.128 LocalGateway(cfg-iptrust-list)#ipv4 185.115.197.0 255.255.255.128 CUBE(cfg-iptrust-list)#exit LocalGateway(conf-voi-serv)#allow-connections sip to sip LocalGateway(conf-voi-serv)#media statistics LocalGateway(conf-voi-serv)#media bulk-stats LocalGateway(conf-voi-serv)#media-address range 192.168.43.197 192.168.43.197 port-range 8000 48000  LocalGateway(cfg-media-addr-range)#exit LocalGateway(conf-voi-serv)#no supplementary-service sip refer LocalGateway(conf-voi-serv)#no supplementary-service sip handle-replaces LocalGateway(conf-voi-serv)# fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none LocalGateway(conf-serv-stun)#stun LocalGateway(conf-serv-stun)#stun flowdata agent-id 1 boot-count 4 LocalGateway(conf-serv-stun)#stun flowdata shared-secret 0 Password123$ LocalGateway(conf-serv-stun)#sip LocalGateway(conf-serv-sip)#g729 annexb-all LocalGateway(conf-serv-sip)#early-offer forced LocalGateway(conf-serv-sip)#end

コマンドの説明:

不正料金の防止
デバイス (config) # ボイスサービス voip デバイス (config-voi-serv) # ip アドレス信頼リスト デバイス (cfg-iptrust-list) # ipv4 199.59.70.0 255.255.255.128 Device (cfg-iptrust リスト) # ipv4 199.59.71.0 255.255.255.128
  • ローカル ゲートウェイが Webex Calling ピア、Unified CM ノード、IP PSTN などの正当な VoIP コールを期待するエンティティのソース IP アドレスを明示的に有効にします。

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

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


     

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

  • 他のインターフェイスでは、他の IP アドレスを設定することが必要になる場合があります。たとえば、Unified CM アドレスを内向きのインターフェイスに追加する必要がある場合があります。

  • IP アドレスは、outbound-proxytenant 200 で解決するホストの IP と一致する必要があります。

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

メディア
voice service voip media statistics media bulk-stats media-address range 192.168.43.197 192.168.43.197 port-range 8000 48000
  • メディア統計は、ローカル ゲートウェイのメディア監視を有効にします。

  • メディア一括統計は、一括呼び出し統計のためのコントロール プレーンがデータプレーンをポーリングできるようにします。

  • メディアアドレス範囲 <LGW IP Address Range> ポート範囲 の設定では、このメディアアドレス範囲に使用する RTP ソースポートを決定します。 これは、Webex Calling 向けの Gig0/0/1 インターフェイスに対して設定されています。

SIP-to-SIP 基本機能
allow-connections sip to sip
補足サービス
no supplementary-service sip refer no supplementary-service sip handle-replaces

REFER を無効にして、ピア ダイアログ ID の Replace ヘッダーでダイアログ ID を置換します。

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

ファックス プロトコル
fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none

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

Enable Global STUN
stun stun flowdata agent-id 1 boot-count 4 stun flowdata shared-secret 0 Password123$
  • コールが Webex Calling ユーザー(例: 着信側と発信側の両方が Webex Calling サブスクライバーであり、Webex Calling SBC でアンカーされているメディアを持っている)に転送されたとき、ピンホールが開いていないため、メディアはローカル ゲートウェイにフローしません。

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

  • STUN パスワードは、ローカル ゲートウェイが STUN メッセージを送信するための前提条件です。 IOS/IOS-XE ベースのファイアウォールは、このパスワードを確認し、ピンホールをダイナミックに開くように設定できます (たとえば、明示的な in-out ルールなし)。 しかし、ローカル ゲートウェイ 展開の場合、ファイアウォールは、Webex Calling SBC サブネットに基づいてピンホールを内外に開くようにスタティックに設定されます。 そのため、ファイアウォールは、パケットの内容を明示的に確認せずにピンホールを開くトリガーとなるインバウンド UDP パケットとしてこれを処理する必要があります。

G729
sip g729 annexb-all

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

[SIP]
early-offer forced

ローカル ゲートウェイに、隣接ピアからの確認応答待知の代わりに、初期 INVITE メッセージで SDP 情報を送信するように強制します。

2

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

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

これらのルールは、以下のとおりです。

コマンドの説明:

  • rule 9 ensures the header is listed as “SIP-Req-URI” and not “SIP-Req-URL”

    これは、SIP URI と SIP URL の間で変換されます。Webex Calling はリクエスト/応答メッセージで SIP URI をサポートしませんが、_sips._tcp.<outbound-proxy> などの SRV クエリ―に対してそれらを必要とするためです。
  • rule 20 は、From ヘッダーに Control Hub からの Trunk Group OTG/DTG パラメーターを含めて、エンタープライズ内の LGW サイトを固有に識別できるように変更します。

  • この SIP プロファイルは、Webex Calling 向けのすべてのトラフィックに対して voice class tenant 200(後で取り上げる)を適用します。

3

Codec プロファイル、STUN 定義、および SRTP Crypto スイートを設定します。

LocalGateway(config)# voice class codec 99 LocalGateway(config-class)# codec preference 1 g711ulaw LocalGateway(config-class)# codec preference 2 g711alaw LocalGateway(config-class)# codec preference 3 g729r8 LocalGateway(config-class)# exit LocalGateway(config)# voice class srtp-crypto 200 LocalGateway(config-class)# crypto 1 AES_CM_128_HMAC_SHA1_80 LocalGateway(config-class)# exit LocalGateway(config)# voice class stun-usage 200 LocalGateway(config-class)# stun usage firewall-traversal flowdata LocalGateway(config-class)# exit

コマンドの説明:

  • Voice class codec 99: セッションに対して g729 および g711 (mu および a-law) codecs を許可します。 すべてのダイヤルピアに適用されるls。

  • Voice class srtp-crypto 200: 要求と応答の SDP で ローカル ゲートウェイ で提供される唯一の SRTP 暗号スイートとして、SHA1_80 を指定します。 Webex Calling は SHA1_80 のみをサポートします。

  • Webex Calling 向けの voice class tenant 200 (後で取り上げる)に適用されます。

  • Voice class stun-usage 200: STUN の使用量を定義します。 Is は Unified CM が別の Webex Calling 電話に転送されるときに音声を回避するために、すべての Webex Calling 向きの (2XX タグ) ダイヤルピアに適用されます。


 

メディアが ITSP SBC で固定されており、ローカル ゲートウェイが NAT の背後で、ITSP からのインバウンド メディア ストリームを待っている場合、このコマンドはダイヤルピア向きの ITSP に適用されます。

4

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

Webex Calling はローカル ゲートウェイ内のテナントとして追加されます。 ローカル ゲートウェイを登録する必要がある設定は、voice class tenant 200 の下で定義されます。 このスクリーンショットで示されているとおり、Control Hub の中でローカル ゲートウェイ管理ページからその設定の要素を取得する必要があります。 これは、それぞれのローカル ゲートウェイ CLI にマップされるフィールドを表示している例です。

テナント 200 は、その後ローカル ゲートウェイ設定の中で、Webex Calling 向けのすべてのダイヤルピア (2xx タグ) に適用されます。 音声クラス テナント機能では、音声サービス voip と sip-ua の下で行われた SIP トランク パラメータのグループ化と設定が可能になります。 テナントがダイヤルピアの下で設定され、適用される場合、IOS-XE 設定は次の優先順位で適用されます。

  • ダイヤルピア設定

  • テナント構成

  • グローバル構成(音声サービス voip / sip-ua)

5

voice class tenant 200 を LGW から Webex Calling にトランク登録するための設定を行います。:

LocalGateway(config)#voice class tenant 200 registrar dns:40462196.cisco-bcld.com scheme sips expires 240 refresh-ratio 50 tcp tls credentials number Hussain6346_LGU username Hussain2572_LGU password 0 meX7]~)VmF realm BroadWorks authentication username Hussain2572_LGU password 0 meX7]~)VmF realm BroadWorks authentication username Hussain2572_LGU password 0 meX7]~)VmF realm 40462196.cisco-bcld.com no remote-party-id sip-server dns:40462196.cisco-bcld.com connection-reuse srtp-crypto 200 session transport tcp tls url sips error-passthru asserted-id pai bind control source-interface GigabitEthernet0/0/1 bind media source-interface GigabitEthernet0/0/1 no pass-thru content custom-sdp sip-profiles 200 outbound-proxy dns:1a01.sipconnect-us10.cisco-bcld.com privacy-policy passthru 

コマンドの説明:

voice class tenant 200

ローカル ゲートウェイのマルチテナント機能により、テナントに対して差別化されたサービスに許可される SIP トランクの複数のテナントの特定のグローバル設定が有効になります。

registrar dns:40462196.cisco-bcld.com scheme sips expires 240 refresh-ratio 50 tcp tls

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

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

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

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

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

no remote-party-id

SIP Remote-Party-ID (RPID) ヘッダーを無効にします。 Webex Calling が PAI をサポートし、それが CIO asserted-id pai を使用して有効化されるためです (下記参照)。

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

登録とコール処理に対して同じ持続的な接続を使用するため。

srtp-crypto 200

voice class srtp-crypto 200 で定義されているとおりに、SHA1_80 を指定します。

session transport tcp tls
Sets transport to TLS
url sips

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

error-passthru

SIP エラー応答パススルー機能

asserted-id pai

ローカル ゲートウェイで PAI 処理をオンにします。

bind control source-interface GigabitEthernet0/0/1

Webex Calling に向けたシグナリング ソース インターフェイス。

bind media source-interface GigabitEthernet0/0/1

メディア ソース インターフェイスは Webex Calling に向いています。

no pass-thru content custom-sdp

テナントの下のデフォルト コマンド。

sip-profiles 200

SIPS を SIP に変更し、voice class sip-profiles 200で定義されているとおり、INVITE および REGISTER メッセージの回線/ポートを修正します。

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

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

privacy-policy passthru

着信レッグから発信レッグにプライバシー ヘッダー値を透過的に通過します。

tenant 200 がローカル ゲートウェイ内で定義され、SIP VoIP ダイアルピヤが設定された後、ゲートウェイは Webex Calling に向けて TLS 接続を開始し、その時点で Access SBC はその証明書をローカル ゲートウェイに提示します。 ローカル ゲートウェイは、以前に更新された CA ルート バンドルを使用して、Webex Calling Access SBC 証明書を検証します。 持続的な TLS セッションは、ローカル ゲートウェイと Webex Calling Access SBC の間で確立されます。 ローカル ゲートウェイはその後、課題となる Access SBC に REGISTER を送信します。 登録 AOR は number@domain です。 番号は資格情報の「number」パラメーターから取得され、ドメインは「registrar dns:<fqdn>」から取得されます。 登録がチャレンジされると、資格情報ユーザー名、パスワード、および領域パラメーターはヘッダーを構築するために使用され、sip-profile 200 は SIPS URL を SIP に変換します。 Access SBC から 200 OK を受け取ると、登録は正常に行われたことになります。

ローカル ゲートウェイでの次の設定は、展開のオプションに必要です。

  1. 音声クラスのテナント—最初に、 Webex Calling に 直面しているダイヤルピアのために作成したテナント200のようなダイヤルピア向けの追加のテナントを作成します。

  2. 音声クラス URI—ローカル ゲートウェイで終端するさまざまなトランクのためのホスト IP アドレス/ポートを定義するパターン: Webex Calling から LGWへ。および LGW の PSTN SIP トランク終端。

  3. 発信ダイヤルピア—LGW から ITSP SIP トランクおよび Webex Calling への発信コール レッグをルートするため。

  4. 音声クラス DPG—受信ダイヤルピアから呼び出された発信ダイヤルピアを宛先にします。

  5. 受信ダイヤルピア—ITSP および Webex Calling からの受信コール レッグを受け取るため。

このセクションの設定は、次に示すように、パートナーによりホストされたローカル ゲートウェイのセットアップ、またはローカルの顧客サイト ゲートウェイのいずれかに使用できます。

1

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

  1. 音声クラス テナント 100 は、IP PSTN に向かうすべての発信ダイヤルピアに適用されます。

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

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

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

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

    voice class uri 100 sip host ipv4:192.168.80.13
  2. コントロール ハブの TrunkGroup OTG / DTG パラメーターに基づいて、エンタープライズ内のローカル ゲートウェイ サイトを一意に識別するパターンを定義します:

    voice class uri 200 sip pattern dtg=hussain2572.lgu

     

    ローカル ゲートウェイ は現在、マッチ パターンで、下線「_」をサポートしていません。 回避策として、ドット「.」を使用してください (任意のものを)「_」にマッチさせます。

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

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

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

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

    コマンドの説明:

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

    タグ 101 で VOIP ダイヤルピアを定義し、意味のある説明が与えられて管理とトラブルシューティングを容易にします。

    destination-pattern BAD.BAD

    ダイヤルピアの選択を許可するディジット パターン。 しかし、DPG ステートメントを使用してインバウンドから直接、発信ダイヤルピアを呼び出し、ディジット パターンマッチ基準をバイパスします。 結果として、宛先パターン CLI により許可される英数字桁に基づいた任意のパターンを使用します。

    session protocol sipv2

    このダイヤルピアが SIP 呼び出しレッグを処理することを指定します。

    session target ipv4:192.168.80.13

    このコール レッグが発信される宛先のターゲット Ipv4 アドレスを示します。 この場合、ITSP の IP アドレスです。

    voice-class codec 99

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

    dtmf-relay rtp-nte

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

    voice-class sip tenant 100

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

    no vad

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

  2. Webex Calling に向かう発信ダイヤルピア

    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 dtmf-relay rtp-nte voice-class stun-usage 200 no voice-class sip localhost voice-class sip tenant 200 srtp no vad

    コマンドの説明:

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

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

    session target sip-server

    グローバル SIP サーバーがこのダイヤルピアからのコールの宛先であることを示します。 テナント 200 で定義されている Webex Calling サーバーは、このダイヤルピアに継承されます。

    voice-class stun-usage 200

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

    no voice-class sip localhost

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

    voice-class sip tenant 200

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

    srtp

    SRTP は、このコール レッグに対して有効になっています。

    no vad

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

4

以下のダイヤルピア グループ (DPG) を設定します:

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

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

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

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

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

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

    コマンドの説明

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

    タグ 100 で VOIP ダイヤルピアを定義し、意味のある説明が与えられて管理とトラブルシューティングを容易にします。

    session protocol sipv2

    このダイヤルピアが SIP 呼び出しレッグを処理することを指定します。

    incoming uri via 100

    IP PSTN から LocalGW へのすべての着信トラフィックは、音声クラス URI 100 SIP で定義されたヘッダーのホスト IP アドレス経由の着信とソース IP (ITSP) アドレスに基づいて照合されます。

    destination dpg 200

    宛先 dpg 200 では、IOS-XE は従来の発信ダイヤルピア マッチング基準に合格し、すぐに宛先ダイヤルピア グループ 200 (ダイヤルピア 201) 内で定義されたダイヤルピアを使用して発信コールレッグをセットアップします。

    voice-class sip tenant 300

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

    no vad

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

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

    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 srtp no vad

    コマンドの説明

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

    タグ 200 で VOIP ダイヤルピアを定義し、意味のある説明が与えられて管理とトラブルシューティングを容易にします。

    incoming uri request 200

    Webex Calling から LGW へのすべての着信トラフィックは、リクエスト URI の一意の dtg パターンで一致し、エンタープライズ(アカウント)内および Webex Calling エコシステム内のローカル ゲートウェイ サイトを固有に識別します。

    destination dpg 100

    宛先 dpg 100 では、IOS-XE は従来の発信ダイヤルピア マッチング基準に合格し、すぐに宛先ダイヤルピア グループ 300 (ダイヤルピア 101) 内で定義されたダイヤルピアを使用して発信コールレッグをセットアップします。

    voice-class stun-usage 200

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

    voice-class sip tenant 200

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

    srtp

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

    no vad

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

PSTN から Webex Calling

ローカル ゲートウェイ のすべての着信 IP PSTN コール レッグは、IP PSTN の IP アドレスを持つ VIA ヘッダーのマッチング基準を定義するため、ダイヤルピア 100 でマッチングします。 発信ダイヤルピアの選択は、発信ダイヤルピア 201 を直接呼び出す DPG 200 によって指示され、ターゲット宛先として Webex Calling サーバーがリストされています。

Webex Calling から PSTN

ローカル ゲートウェイ のすべての Webex Calling コール レッグの着信は、このローカル ゲートウェイ展開に固有の TrunkGroup OTG / DTG パラメータを使用して REQUEST URI ヘッダー パターンのマッチング基準を満たしているため、ダイヤルピア 200 でマッチングします。 発信ダイヤルピアの選択は、発信ダイヤルピア 101 を直接呼び出す DPG 100 によって指示され、それは、ターゲット宛先として IP PSTN IP アドレスがリストされています。

この展開オプションの場合、ローカル ゲートウェイの以下の設定が必要です。

  1. 音声クラス テナント—ダイヤルピアに面した Webex Calling に対して作成された tenant 200 と同様に、Unified CM および ITSP に面しているダイヤルピアの追加テナントを作成する必要があります。

  2. 音声クラス URI—LGW で終端するさまざまなトランクのためのホスト IP アドレス/ポートを定義するパターン: PSTN 宛先に対する Unified CM から LGW、Webex Calling 宛先に対する Unified CM から LGW、Webex Calling から LGW、および LGW で PSTN SIP トランク終端。

  3. 音声クラス サーバー グループ—LGW から Unified CM、LGW から Webex Calling 、LGW から PSTN SIP トランクの送信トランクの宛先 IP アドレス/ポート。

  4. 発信ダイヤルピア—LGW から Unified CM、ITSP SIP トランク、および/または Webex Calling への発信コール レッグをルートするため。

  5. 音声クラス DPG—着信ダイヤルピアから呼び出された発信ダイヤルピアをターゲットします。

  6. 受信ダイヤルピア—Unified CM、ITSP および/または Webex Calling からの受信コール レッグを受け付けるため。

1

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

  1. 音声クラス テナント 100 は、Unified CM と IP PSTN に面したすべての発信ダイヤルピアに適用されます。

    voice class tenant 100 session transport udp url sip error-passthru bind control source-interface GigabitEthernet0/0/0 bind media source-interface GigabitEthernet0/0/0 no pass-thru content custom-sdp
  2. 音声クラス テナント 300 は、Unified CM と IP PSTN からのすべての着信ダイヤルピアに適用されます。

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

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

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

    voice class uri 100 sip host ipv4:192.168.80.13
  2. コントロール ハブの TrunkGroup OTG / DTG パラメーターに基づいて、エンタープライズ内のローカル ゲートウェイ サイトを一意に識別するパターンを定義します:

    voice class uri 200 sip pattern dtg=hussain2572.lgu

     

    ローカル ゲートウェイは現在、マッチ パターンで、下線「_」をサポートしていません。 回避策として、ドット「.」を使用してください (任意のものを)「_」にマッチさせます。

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

    voice class uri 300 sip pattern :5065
  4. PSTN トランクの CUCM ソースシグナリング IP と VIA ポートを定義します。

    voice class uri 302 sip pattern 192.168.80.60:5060
3

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

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

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

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

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

    voice class server-group 307 ipv4 192.168.80.60
4

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

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

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

    コマンドの説明

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

    タグ 101 で VOIP ダイヤルピアを定義し、意味のある説明が与えられて管理とトラブルシューティングを容易にします。

    destination-pattern BAD.BAD

    このダイヤルピアの選択を許可するディジット パターン。 しかし、DPG ステートメントを使用してインバウンドから直接、発信ダイヤルピアを呼び出し、ディジット パターンマッチ基準をバイパスします。 結果として、宛先パターン CLI により許可される英数字桁に基づいた任意のパターンを使用します。

    session protocol sipv2

    このダイヤルピアが SIP 呼び出しレッグを処理することを指定します。

    session target ipv4:192.168.80.13

    このコール レッグが発信される宛先の Ipv4 アドレスを示します。(この場合は ITSP の IP アドレス。)

    voice-class codec 99

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

    voice-class sip tenant 100

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

  2. Webex Calling に向かう発信ダイヤルピア:

    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 dtmf-relay rtp-nte voice-class stun-usage 200 no voice-class sip localhost voice-class sip tenant 200 srtp no vad

    コマンドの説明

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

    タグ 201 で VOIP ダイヤルピアを定義し、意味のある説明が与えられて管理とトラブルシューティングを容易にします。

    session target sip-server

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

    voice-class stun-usage 200

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

    no voice-class sip localhost

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

    voice-class sip tenant 200

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

    srtp

    SRTP は、このコール レッグに対して有効になっています。

  3. Unified CM の Webex Calling トランクに向かう送信ダイヤルピア:

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

    コマンドの説明

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

    タグ 301 で VOIP ダイヤルピアを定義し、意味のある説明が与えられて管理とトラブルシューティングを容易にします。

    session server-group 301

    ダイヤルピアのセッション ターゲット IP の代わりに、宛先サーバー グループをポイントし (ダイヤルピア 301 の サーバーグループ 301)、サンプルを通じて複数のターゲット UCM ノードを定義する場合は、シングルノードのみを表示します。

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

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

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

  4. 5 つ以上の Unified CM ノードをもつ場合に、Unified CM の Webex Calling Trunk に向かう 2 番目の送信ダイヤルピア。

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

    dial-peer voice 305 voip description Outgoing dial-peer to CUCM-Group-1 for inbound from PSTN - Nodes 1 to 5 destination-pattern BAD.BAD session protocol sipv2 session server-group 305 voice-class codec 99 dtmf-relay rtp-nte voice-class sip tenant 100 no vad
  6. 5 つ以上の Unified CM ノードをもつ場合に、Unified CM の PSTN Trunk に向かう 2 番目の送信ダイヤルピア。

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

以下の DPG を構成します。

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

    voice class dpg 100 dial-peer 101 preference 1
  2. DPG 200 を発信ダイヤルピア 201 で、Unified CM --> LGW --> Webex Calling パス: のターゲットとして定義します。

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

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

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

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

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

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

    コマンドの説明

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

    タグ 100 で VOIP ダイヤルピアを定義し、意味のある説明が与えられて管理とトラブルシューティングを容易にします。

    session protocol sipv2

    このダイヤルピアが SIP 呼び出しレッグを処理することを指定します。

    incoming uri via 100

    IP PSTN から LGW へのすべての着信トラフィックは、音声クラス URI 100 SIP で定義されたヘッダーのホスト IP アドレス経由の着信とソース IP (ITSP) アドレスに基づいて照合されます。

    destination dpg 302

    宛先 DPG 302 では、IOS-XE は従来の送信ダイヤルピア マッチング基準に合格し、すぐに宛先 DLG 302(ダイヤルピア 305 またはダイアルピア 307 のいずれか) 内で定義されたダイヤルピアを使用して送信コールレッグをセットアップします。

    voice-class sip tenant 300

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

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

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

    コマンドの説明

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

    タグ 200 で VOIP ダイヤルピアを定義し、意味のある説明が与えられて管理とトラブルシューティングを容易にします。

    incoming uri request 200

    Webex Calling から LGW へのすべての着信トラフィックは、リクエスト URI の一意の dtg パターンで照合でき、エンタープライズ内および Webex Calling エコシステム内のローカルゲートウェイサイトを一意に識別します。

    destination dpg 300

    宛先 DPG 300 では、IOS-XE は従来の送信ダイヤルピア マッチング基準に合格し、すぐに宛先 DLG 300(ダイヤルピア 301 またはダイアルピア 303 のいずれか) 内で定義されたダイヤルピアを使用して送信コールレッグをセットアップします。

    voice-class stun-usage 200

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

    voice-class sip tenant 200

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

    srtp

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

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

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

    コマンドの説明

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

    タグ 300 で VOIP ダイヤルピアを定義し、意味のある説明が与えられて管理とトラブルシューティングを容易にします。

    incoming uri via 300

    Unified CM から LGW へのすべての着信トラフィックは、音声クラス URI 300 SIP で定義された VIA ソース ポート (5065)で照合されます。

    destination dpg 200

    宛先 DPG 200 では、IOS-XE は従来の発信ダイヤルピア マッチング基準に合格し、すぐに宛先 DPG 200 (ダイヤルピア 201) 内で定義されたダイヤルピアを使用して発信コールレッグをセットアップします。

    voice-class sip tenant 300

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

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

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

    コマンドの説明

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

    タグ 302 で VOIP ダイヤルピアを定義し、意味のある説明が与えられて管理とトラブルシューティングを容易にします。

    incoming uri via 302

    PSTN 宛先に対する Unified CM から LGW へのすべての着信トラフィックは、Unified CM ソース シグナル IP アドレス、および音声クラス URI 302 SIP で定義された VIA ソース ポート (5065)で照合されます。 標準 SIP ポート 5060 が使用されます。

    destination dpg 100

    宛先 DPG 100 では、IOS-XE は従来の発信ダイヤルピア マッチング基準に合格し、すぐに宛先 DPG 100 (ダイヤルピア 101) 内で定義されたダイヤルピアを使用して発信コールレッグをセットアップします。

    voice-class sip tenant 300

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

IP PSTN to Unified CM PSTN Trunk

Unified CM Webex Calling Trunk への Webex Calling プラットフォーム

IP PSTN への Unified CM PSTN Trunk to IP PSTN

Webex Calling プラットフォームへの Unified CM Webex Calling Trunk

ウォーター マーク
2020年7月27日| 回表示 | 人がこの投稿が役に立ったと考えています

ローカル ゲートウェイとして 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 以降を必要とし、以下のプラットフォームでサポートされています。

  • ISR4000 シリーズ—4321、4331、4351、4431、4451、4461 (IOS-XE 17.2.1 r)
  • CSR1000 シリーズ—vCUBE (1、2、および 4 vCPU 構成)


この記事のコマンドとログの表示は、vCUBE (CSR1000v) で実装された Cisco IOS-XE 16.12.2 のソフトウェアの最小リリースに基づいています。

参考資料

Webex Calling ソリューションの概要

Cisco Webex Calling は、次の 2 つの PSTN オプションにより、オンプレミスの PBX 電話サービスにマルチテナント クラウドベースの代替手段を提供するコラボレーション ソリューションです。

  • クラウド接続 PSTN プロバイダー
  • ローカル ゲートウェイ

ローカル ゲートウェイの展開 (以下を参照) はこの記事の中心です。 ローカル ゲートウェイは、顧客所有の PSTN サービスへの接続を提供することで、Cisco Webex Calling に独自の 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 展開のローカル ゲートウェイとして展開することができます。この記事では、設計の考慮事項と構成について説明します。 この図は、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) コントロール/データ インターフェイスと呼ばれます

  • 2 つ以上の CUBE HA ペアは、グループ id 1 とグループ id 2 を持つ同じレイヤー 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 アプリケーションのボックス間の冗長性を有効にします。 [voice service voip] の以前の手順から RG を構成します。 これにより、CUBE アプリケーションは冗長性プロセスをコントロールすることができます。

voice service voip redundancy-group 1 exit
VCUBE-1(config)#voice service voip
VCUBE-1(config-voi-serv)#redundancy-group 1
% Created RG 1 associatiation 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 associatiation 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
構成を検証しています...
[OK]
VCUBE-1#reload
リロードを続行しますか? [confirm]

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

VCUBE-2#wr
構成を検証しています...
[OK]
VCUBE-2#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 でローカル ゲートウェイを構成する

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

  • ユーザー名: Hussain1076_LGU

  • パスワード: lOV12MEaZx

1

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

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

これは、上に表示されている Control Hub のパラメーターに基づき、両方のプラットフォームに適用し、保存し、リロードするローカ ルゲートウェイの構成です。 Control Jub からの 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 85.119.56.128 255.255.255.192 ipv4 85.119.57.128 255.255.255.192 ipv4 185.115.196.0 255.255.255.128 ipv4 185.115.197.0 255.255.255.128 ipv4 199.59.64.0 255.255.255.128 ipv4 199.59.65.0 255.255.255.128 ipv4 199.59.66.0 255.255.255.128 ipv4 199.59.67.0 255.255.255.128 ipv4 199.59.70.0 255.255.255.128 ipv4 199.59.71.0 255.255.255.128 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 "<sip:(.*)" "<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 codec preference 3 g729r8 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:1a01.sipconnect-us10.cisco-bcld.com privacy-policy passthru voice class tenant 100 session transport udp url sip error-passthru bind control source-interface GigabitEthernet2 bind media source-interface GigabitEthernet2 no pass-thru content custom-sdp voice class tenant 300 bind control source-interface GigabitEthernet2 bind media source-interface GigabitEthernet2 no pass-thru content custom-sdp voice class uri 100 sip host ipv4:198.18.133.3 voice class uri 200 sip pattern dtg=hussain1076.lgu dial-peer voice 101 voip description Outgoing dial-peer to IP PSTN destination-pattern BAD.BAD session protocol sipv2 session target ipv4:198.18.133.3 voice-class codec 99 voice-class sip tenant 100 dtmf-relay rtp-nte no vad dial-peer voice 201 voip description Outgoing dial-peer to Webex Calling destination-pattern BAD.BAD session protocol sipv2 session target sip-server voice-class codec 99 voice-class stun-usage 200 no voice-class sip localhost voice-class sip tenant 200 dtmf-relay rtp-nte srtp no vad voice class dpg 100 description Incoming WebexCalling(DP200) to IP PSTN(DP101) dial-peer 101 preference 1 voice class dpg 200 description Incoming IP PSTN(DP100) to Webex Calling(DP201) dial-peer 201 preference 1 dial-peer voice 100 voip desription Incoming dial-peer from IP PSTN session protocol sipv2 destination dpg 200 incoming uri via 100 voice-class codec 99 voice-class sip tenant 300 dtmf-relay rtp-nte no vad dial-peer voice 200 voip description Incoming dial-peer from Webex Calling session protocol sipv2 destination dpg 100 incoming uri request 200 voice-class codec 99 voice-class stun-usage 200 voice-class sip tenant 200 dtmf-relay rtp-nte srtp no vad end copy run start

Show コマンド出力を表示するには、VCUBE-2 の後に VCUBE-1 をリロードし、VCUBE-1 をスタンバイ CUBE にして、VCUBE-2 をアクティブ CUBE にします。

2

任意の時点で、1 個のプラットフォームのみが、Webex Calling アクセス SBC を使用したローカル ゲートウェイとしてアクティブ登録を保持します。 以下の show コマンドの出力を見てみましょう。

show redundancy application group 1

show sip-ua-register status

VCUBE-1#show redundancy application group 1 Group ID:1 Group Name:LocalGateway-HA Administrative State: No Shutdown Aggregate operational state : Up My Role: Standby Peer Role: ACTIVE Peer Presence: Yes Peer Comm: Yes Peer Progression Started: Yes RF Domain: btob-one RF state: STANDBY HOT Peer RF state: ACTIVE VCUBE-1#show sip-ua register status VCUBE-1#
VCUBE-2#show redundancy application group 1 Group ID:1 Group Name:LocalGateway-HA Administrative State: No Shutdown Aggregate operational state : Up My Role: ACTIVE Peer Role: STATUS Peer Presence: Yes Peer Comm: Yes Peer Progression Started: Yes RF Domain: btob-one RF state: ACTIVE Peer RF state: STANDBY HOT VCUBE-2#show sip-ua register status Tenant: 200 --------------------Registrar-Index 1 --------------------- Line peer expires(sec) reg survival P-Associ-URI ============================== ========== ============ === ======== ============ Hussain5091_LGU -1 48 yes normal VCUBE-2#

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

3

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

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

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

VCUBE-2#redundancy application reload group 1 self

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

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

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

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

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

6

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

VCUBE-1#show log Jan 9 18:37:24.769: %RG_MEDIA-3-TIMEREXPIRED: RG id 1 Hello Time Expired. Jan 9 18:37:24.771: %RG_PROTCOL-5-ROLECHANGE: RG id 1 role change from Standby to Active Jan 9 18:37:24.783: %VOICE_HA-2-SWITCHOVER_IND: SWITCHOVER, from STANDBY_HOT to ACTIVE state. Jan 9 18:37:24.783: //-1/xxxxxxxxxxxx/SIP/Info/info/4096/sip_ha_notify_active_role_event: Received notify active role event Jan 9 18:37:25.758: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Sent: REGISTER sip: 40462196.cisco-bcld.com:5061 SIP/2.0 Via: SIP/2.0/TLS 198.18.1.228:5061;branch=z9hG4bK0374 From: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189 To: <sip:Hussain5091_LGU@40462196.cisco-bcld.com> Date: Thu, 09 Jan 2020 18:37:24 GMT Call-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97 User-Agent: Cisco-SIPGateway/IOS-16.12.02 Max-Forwards: 70 Timestamp: 1578595044 CSeq: 2 REGISTER Contact: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls> Expires: 240 Supported: path Content-Length: 0
Jan 9 18:37:25.995: //-1/000000000000/SIP/Msg/ccsipDisplayMsg: Received: SIP/2.0 401 Unauthorized Via: SIP/2.0/TLS 198.18.1.228:5061;received=173.38.218.1;branch=z9hG4bK0374;rport=4742 From: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189 To: <sip:Hussain5091_LGU@40462196.cisco-bcld.com>;tag=SD1u8bd99-1324701502-1578595045969 Date: Thu, 09 Jan 2020 18:37:24 GMT Call-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97 Timestamp: 1578595044 CSeq: 2 REGISTER WWW-Authenticate; DIGEST realm="BroadWorks",qop="auth",nonce="BroadWorksXk572qd01Ti58zliBW",algorithm=MD5 Content-Length: 0
Jan 9 18:37:26.000: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Sent: REGISTER sip:40462196.cisco-bcld.com:5061 SIP/2.0 Via: SIP/2.0/TLS 198.18.1.228:5061;branch=z9hG4bK16DC From: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189 To: <sip:Hussain5091_LGU@40462196.cisco-bcld.com> Date: Thu, 09 Jan 2020 18:37:25 GMT Call-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97 User-Agent:Cisco-SIPGateway/IOS-16.12.02 Max-Forwards: 70 Timestamp: 1578595045 CSeq: 3 REGISTER Contact: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls> Expires: 240 Supported: path Authorization: Digest username="Hussain1076_LGU",realm="BroadWorks",uri="sips:40462196.cisco-bcld.com:5061",response="b6145274056437b9c07f7ecc08ebdb02",nonce="BroadWorksXk572qd01Ti58z1iBW",cnonce="3E0E2C4D",qop=auth,algorithm=MD5,nc=00000001 Content-Length: 0
Jan 9 18:37:26.190: //1/000000000000/SIP/Msg/ccsipDisplayMsg: Received: SIP/2.0 200 OK Via: SIP/2.0/TLS 198.18.1.228:5061;received=173.38.218.1;branch=z9hG4bK16DC;rport=4742 From: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189 To: <sip:Hussain5091_LGU@40462196.cisco-bcld.com>;tag=SD1u8bd99-1897486570-1578595-46184 Call-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97 Timestamp: 1578595045 CSeq: 3 REGISTER Contact: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls>;expires=120;q=0.5 Allow-Events: call-info,line-seize,dialog,message-summary,as-feature-event,x-broadworks-hoteling,x-broadworks-call-center-status,conference Content-Length: 0
ウォーター マーク
2020年7月27日| 回表示 | 人がこの投稿が役に立ったと考えています

Webex Calling のために Unified CM を構成する

Unified CM がオンプレミスのコール制御ソリューションである既存の展開に Webex Calling が有効なロケーションが追加される場合や、Webex Calling ロケーションの Unified CM および電話に登録されている電話間で直接ダイヤルする必要がある場合、Unified CM とのインテグレーションが必要になる場合があります。

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

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

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

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

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

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

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

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

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

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

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

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

PSTNInternational (PSTN アクセス)

onNetRemote (GDPR 学習先)


 

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

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

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

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

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

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

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

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

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

設定
ルート リスト情報
名前 固有の名前 (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
ウォーター マーク
2020年7月27日| 回表示 | 人がこの投稿が役に立ったと考えています

Cisco Webex Calling の機能をセットアップする

自動音声応答の作成

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

1

の顧客ビューから https://admin.webex.comサービス > 通話機能に移動 > します。

2

[新規] をクリックして [自動音声応答] を選択します。

3

パイロット番号を選択し、番号を所有している かどうかを指定します。パートナーにより提供されたものであるか、または番号を発信するかを示します。

4

番号の移行を行う場合には、現在のサービス プロバイダーに関連付けられている請求番号と、新しいサービス プロバイダーに関連付けられている請求番号を入力する必要があります。

5

ロケーションを 選択 し、[保存] をクリックし ます。

次のタスク

[ サービス通話注文] に移動 > > して注文のステータスを確認します。

注文が完了したら、[サービス通話からの自動アテンダント] 機能を選択して、通話機能をさらに設定することができ > > ます。 Calling 管理ポータルの [高度なサービス] にリダイレクトされ、ここで構成を完了することができます。 詳細については、[自動音声応答の管理] を参照してください。

ハント グループのセットアップ

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

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

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

1

の顧客ビューから https://admin.webex.comサービス > 通話機能に移動 > します。

2

[新しい機能] をクリックして [ハント グループ] を選択します。

3

[パイロット番号] を入力し、番号が自分自身のものなのか、パートナーから提供されたものなのか、それとも番号を移行するのかを指定します。

4

番号の移行を行う場合には、現在のサービス プロバイダーに関連付けられている請求番号と、新しいサービス プロバイダーに関連付けられている請求番号を入力する必要があります。

5

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

次のタスク

[ サービス通話注文] に移動 > > して注文のステータスを確認します。

処理が完了したら、[サービス通話] 機能からハントグループを選択して、通話機能をさらに構成することができ > > ます。 通話管理者ポータルの [高度なサービス] にリダイレクトされ、ここで構成を完了することができます。 詳細については、「ハント グループの変更」を参照してください。

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

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

1

の顧客ビューから https://admin.webex.comサービス > 通話機能に移動 > します。

2

[新しい機能] をクリックして [レセプショニスト クライアント] を選択します。

通話管理者ポータルの [高度なサービス] にリダイレクトされ、ここで構成を完了することができます。 詳細については、「レセプニショストの構成」.

ページング グループのセットアップ

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

始める前に

  • ページングには、IP アドレス 239.192.16.240 を使用したマルチキャスト転送が必要です。 IP アドレスがマルチキャスト転送のみにフリーであることを確認します。

  • ページング グループに割り当てる外線が利用可能で、まだ割り当てされていないことを確認します。

  • ページング グループには 1 人以上のメンバーが必要で、各メンバーには最低 1 つ以上の登録デバイスが必要です。 登録されていないデバイスでグループをページングすると、ビジー信号が発信されます。

  • ページング グループは Cisco IP Phone 7800 または 8800 シリーズのみで動作し、アナログの電話アダプター (ATA) では動作しません。

1

の顧客ビューから https://admin.webex.comサービス > 通話機能に移動 > します。

2

[新しい機能] をクリックして [ページング グループ] を選択します。

3

[パイロット番号] を入力し、番号が自分自身のものなのか、パートナーから提供されたものなのか、それとも番号を移行するのかを指定します。

4

番号の移行を行う場合には、現在のサービス プロバイダーに関連付けられている請求番号と、新しいサービス プロバイダーに関連付けられている請求番号を入力する必要があります。

5

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

次のタスク

[ サービス通話注文] に移動 > > して注文のステータスを確認します。

処理が完了したら、[サービス通話] 機能からページンググループを選択して、通話機能をさらに構成することができ > > ます。 通話管理者ポータルの [高度なサービス] にリダイレクトされ、ここで構成を完了することができます。 詳細については、「ページングのグループ設定」を参照してください。

通話キューの作成

通話キューを作成すれば、顧客の発信にすぐに応答がない場合、誰かが応答できるようになるまで自動応答、お詫びのメッセージ、および保留中の音楽が流れるようにすることができます。

1

の顧客ビューから https://admin.webex.comサービス > 通話機能に移動 > します。

2

[新しい機能] をクリックして [通話キュー] を選択します。

3

[パイロット番号] を入力し、番号が自分自身のものなのか、パートナーから提供されたものなのか、それとも番号を移行するのかを指定します。

4

番号の移行を行う場合には、現在のサービス プロバイダーに関連付けられている請求番号と、新しいサービス プロバイダーに関連付けられている請求番号を入力する必要があります。

5

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

次のタスク

[ サービス通話注文] に移動 > > して注文のステータスを確認します。

注文が完了したら、サービス通話機能から通話キューインスタンスを選択することで、通話機能をさらに構成することができ > > ます。 通話管理者ポータルの [高度なサービス] にリダイレクトされ、ここで構成を完了することができます。 詳細については、「通話キューの構成」を参照してください。

コール ピックアップの設定

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

コールピックアップグループの設定方法については、 Cisco Webex Control Hub のコールピックアップを参照してください

コール パークのセットアップ

コールパークにより、定義されたユーザーグループは、コールパークグループの他の利用可能なメンバーに対して通話をパークすることができます。 保留中の通話は、電話のグループの他のメンバーが選択することができます。

コールパークの設定方法の詳細については、Cisco Webex Control Hub のコールパークを参照してください https://help.webex.com/nfoxd2m/

ユーザーが他のユーザーのコールに割り込むことを許可する

1

https://admin.webex.com の顧客ビューで、[ユーザー] に移動して、変更するユーザーを選択します。

2

[コール] を選択し、[高度なコール設定] に進み、[割り込み] を選択します。

3

[割り込み] をオンにし、誰かがコールに割り込んできたと電話で音を鳴らすかどうかを選択し、[保存] をクリックします。

Webex Calling ユーザーのためにホテリングをオンにする

Hoteling は 2 つの機能で構成されています。 Hoteling ホストと Hoteling ゲストです。 これらの機能は一緒に機能し、ユーザー (ゲスト) が一時的にサインインして、自分の電話として使用できる特定の電話 (主催者) を指定することができます。 ゲストが主催者の電話にサインインすると、そのユーザー プロファイルは自動的にデバイスに転送されます。 主催者デバイスは、指定された期間、ユーザーのプライマリ デバイスになります。

ここで説明されている手順に従うことで、ゲストとしてユーザーを構成することができます。 主催者の電話の詳細については、[主催者の電話を構成する] を参照してください。

1

https://admin.webex.com の顧客ビューで、[ユーザー] に移動して、変更するユーザーを選択します。

2

[ 通話] を選択し、[通話の設定] を選択 ます。

3

[選択] をオンにし て、[保存] をクリックし ます。

ユーザーの回線ステータスを監視することを禁止する

1

https://admin.webex.com の顧客ビューで、[ユーザー] に移動し、て、変更するユーザーを選択します。

2

[コール] を選択し、[プライバシー] に移動します。

3

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

4

[プライバシーを有効にする] チェックボックスをオンにします。 次に、[名前による検索] フィールドを空白にして全員をブロックするか、またはこのユーザーの回線状態を監視できるユーザーを選択します。

上記の執行役員の例では、管理アシスタントの名前を検索することになります。

5

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

ユーザーが他の人の電話またはコールパークの内線の回線ステータスを確認できるようにする

監視回線の最大数は 50 ですが、帯域幅を考慮する必要があります。 最大値が、ユーザーの電話の回線ボタンの数によって決定される場合もあります。

1

https://admin.webex.com の顧客ビューで、[ユーザー] に移動し、て、変更するユーザーを選択します。

2

[通話] を選択し 、[通話の設定] を選択し、 [監視] に移動し ます。

3

次から選択します:

  • 監視回線の追加
  • コールパーク拡張機能の追加
4

このユーザーに保留中の通話について通知するかどうかを選択 https://help.webex.com/0r7a2z/Set-Up-Your-Webex-Calling-Features#id_100086し、監視するユーザーまたはコールパーク拡張機能を検索して、[保存] をクリックし ます。


 

Control Hub の監視回線リストは、ユーザーのデバイス上で表示される監視回線の順番に対応します。 監視回線のリストはいつでも順番を変更することができます。

ウォーター マーク
2020年7月27日| 回表示 | 人がこの投稿が役に立ったと考えています

Webex Calling ユーザーの構成と管理

Webex Calling サービスから益を得られるようにするには、すべてのユーザーを Cisco Webex Control Hub に追加する必要があります。 ユーザーを Control Hub に追加する方法には、メール アドレスを入力して個々のユーザーを手作業で追加する方法と、CSV ファイルを使用して複数のユーザーをまとめて追加する方法があります。 何人のユーザーを追加するかに応じて決めてください。

トライアル アカウントを作成するために自分のメール アドレスを使用したユーザーを追加しようとするとエラーが発生します。 組織に追加する前に、ユーザーが組織を削除してください。


Active Directory があり、ユーザーを手動で Control Hub に追加する際、Cisco Directory Connector を使用する場合は、Active Directory にもユーザーを追加する必要があります。

Cisco Webex Contact Center は Active Directory をサポートしていません。

1

https://admin.webex.com のカスタマー ビューから [ユーザー] に移動し [ユーザーの管理] をクリックします。

2

[手動でユーザーを追加または変更する] を選択します。

3

(任意) 自動的にようこそメールを送信する場合には、[次へ] をクリックします。

4

いずれかを選択して、[次へ] をクリックします。

  • [メール アドレス] を選択し、最大 25 個のメール アドレスを入力します。
  • [名前とメール アドレス] を選択し、最大 25 個の名前とメール アドレスを入力します。

 

組織に変換できるユーザーを追加できます。

5

ライセンス契約:

  • アクティブなライセンス テンプレートがある場合は、新しいユーザーにライセンスが自動的に割り当てられ、ライセンスの概要を確認できます。
  • 割り当てるサービスを選択します。 複数の申請がある場合は、一覧から申請を選択します。


 

Cisco Webex Contact Center のライセンスを割り当てる場合は、[Webex Teams] を選択し、次に [プレミアムとスタンダード エージェント] オプションを使用して [カスタマー ケア] を選択します。 スーパーバイザーを追加するには、[プレミアム][スーパーバイザー] の両方のオプションを選択します。 ユーザーはスーパーバイザーに指名しない限り、エージェントとして扱われます。

6

コンテンツ管理

  • エンタープライズ コンテンツ管理でグローバル アクセスを選択した場合、コンテンツ管理は自動的にユーザーに割り当てられます。
  • ユーザーごとのコンテンツ管理オプションを選択します。

7

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

  • 参加するための招待メールが各ユーザーに送信されます。

  • Control Hub では、ユーザーが最初にサイン インするまでは、ユーザーは「招待保留中」の状態で表示されます。 ユーザーが最初にサインインした後にライセンスが割り当てられます。または、要求されたドメインで Cisco Directory Connector を使用する場合、ユーザーの作成時にライセンスが割り当てられます。

8

処理されたレコードの要約ページを確認し、[完了] をクリックします。

次のタスク

組織のユーザーに、管理者権限を付与することができます。

始める前に

組織に複数の CSV ファイルがある場合、1 つのファイルをアップロードし、タスクが完了したら、次のファイルをアップロードできます。


スプレッドシート エディターの中には、.csv を開くときに + 記号を削除するものがあります。 .csv を更新する際には、テキスト エディターを使用するようにお勧めします。 スプレッドシート エディターを使用する場合には、セルの書式をテキストにして、削除された + 記号があれば戻すようにしてください。

1

https://admin.webex.com の顧客ビューから [ユーザー] に移動し、[ユーザーの管理] をクリックして [CSV を追加するかユーザーを修正する] を選択します。

2

[エクスポート] をクリックしてファイルをダウンロードし、CSV ファイルの新規ラインにユーザー情報を入力できます。

  • サービスを割り当てるには、サービスの列に [TRUE] を追加します。サービスを除外するには、[FALSE] を追加します。 [ユーザー ID/電子メール (必須)] 列のみが必須フィールドです。 それぞれの新規ユーザーに特定のディレクトリおよび外線番号を割り当てる場合には、外線番号に他の文字を含めずに先頭の + だけを含めます。

    アクティブなライセンス テンプレートがある場合は、すべてのサービス列を空白のままにしておけば、その行に新しいユーザーのテンプレートが自動的に割り当てられます。


     

    エンタープライズ コンテンツ管理の権限を、ライセンス テンプレートを使用しているユーザーに割り当てることはできません。詳細については、「Cisco Webex Control Hub でユーザーがコンテンツを管理することを可能にする」を参照してください。

  • ロケーションを割り当てるには、[ロケーション] カラムに名前を入力します。 このフィールドを空白にしておくと、ユーザーはデフォルトの場所に割り当てられます。

  • Cisco Webex Contact Center のスーパーバイザーとしてユーザーを追加する場合は、 ユーザーを手動で追加する必要があります。 標準とプレミアムの役割は、CSV でのみ割り当てることができます。

 

ユーザー名を入力する際には、姓が含まれていることを確認してください。そうしないと、問題が発生する可能性があります。

3

[インポート] をクリックし、自分のファイルを選択して [開く] をクリックします。

4

[サービスのみ追加] または [サービスの追加および削除] のいずれかを選択します。

アクティブなライセンス テンプレートがある場合は、[サービスのみ追加] を選択します。

5

[送信] をクリックします。

CSV ファイルがアップロードされ、タスクが作成されます。 ブラウザーまたはこのウィンドウを閉じると、タスクが引き続き実行されます。 タスクの進行状況を確認するには、「Cisco Webex Control Hub でのタスクの管理」をご覧ください。

フル権限を持つ管理者は、Cisco Webex Control Hub の個々のユーザーに対し、サービスの特定の詳細を編集することができます。

1

https://admin.webex.com のカスタマー ビューから [ユーザー] に移動します。

2

ユーザーを選択し、[サービス > 編集] をクリックします。

3

複数の申請がある場合は、一覧から申請を選択します。

4

追加または削除するサービスを選択し、[保存] をクリックします。

始める前に

組織に複数の CSV ファイルがある場合、1 つのファイルをアップロードし、タスクが完了したら、次のファイルをアップロードできます。

ユーザーを削除したり、CSV テンプレートでユーザーに割り当てられているロケーションを変更することはできません。


スプレッドシート エディターの中には、.csv を開くときに + 記号を削除するものがあります。 .csv を更新する際には、テキスト エディターを使用するようにお勧めします。 スプレッドシート エディターを使用する場合には、セルの書式をテキストにして、削除された + 記号があれば戻すようにしてください。

1

https://admin.webex.com のカスタマー ビューから [ユーザー] に移動し、[ユーザーの管理] をクリックして [CSV を追加するかユーザーを修正する] を選択します。

2

(任意) 自動的にようこそメールを送信する場合には、[次へ] をクリックします。

3

[エクスポート] をクリックして、ファイルをダウンロードします。 以下のいずれかの方法で、ダウンロードしたファイル (exported_users.csv) を編集できます。

  • 既存のユーザーを変更するには、[ユーザー ID/メール (必須)[ディレクトリ番号][直接回線][ロケーション]. 以外の列を更新できます。 たとえば、[ユーザー ID/電子メール] を変更すると、新しいユーザーが作成されます。

  • ロケーションを割り当てるには、[ロケーション] カラムに名前を入力します。 このフィールドを空白にしておくと、ユーザーはデフォルトの場所に割り当てられます。

  • サービスを割り当てるには、サービスの列に [TRUE] を追加します。サービスを除外するには、[FALSE] を追加します。

  • 複数のサブスクリプションがある場合、列見出しのサブスクリプション ID を使用して、追加するサービスを識別します。 たとえば、同じサービスの 2 つのサブスクリプションがある場合は、ユーザーに適用される特定のサブスクリプションからサービスを指定できます。

4

特定のユーザーに対してコールが発生する方法を変更する場合は、[通話動作] 列に値を入力します。 以下のオプションのいずれかを入力して、各設定の詳細については 「Cisco Webex Teams 通話の動作を設定する」を参照してください。

  • USE_ORG_SETTINGS—組織全体の設定を使用するには、この文字列を入力します。

  • NATIVE_WEBEX_TEAMS_CALLING[Webex Teams で通話] オプションを使用するには、この文字列を入力します。

  • CALL_WITH_APP_REGISTERED_FOR_WEBEXCALLTEL[Webex Calling アプリ] オプションを使用するには、この文字列を入力します。

5

CSV ファイルを保存した後で、[インポート] をクリックして、変更したファイルを選択し、[開く] をクリックします。

6

[サービスのみ追加のみ] または [サービスの追加および削除] のいずれかを選択し、[提出] をクリックします。

CSV ファイルがアップロードされ、タスクが作成されます。 ブラウザーまたはこのウィンドウを閉じると、タスクが引き続き実行されます。 タスクの進行状況を確認するには、「Cisco Webex Control Hub でのタスクの管理」をご覧ください。

管理者招待メールを抑制しない場合、新規ユーザーはアクティベーション メールを受信します。

随時ユーザーのデバイスに番号、内線番号、または両方を割り当てることができます。 割り当てられた内線は、電話のディスプレイに表示されます。

複数の電話番号が同じ電話に着信するように、代替番号を構成することもできます。 各番号に異なる呼出音を指定して、どの回線が呼び出されているかを区別することができます。

1

https://admin.webex.com のカスタマー ビューから、[ユーザー] にアクセスし、番号の割り当て先を選択します。

2

[通話] をクリックし、[番号の追加] をクリックします。

3

利用可能な電話番号のリストから番号を選択します。 拡張機能を割り当てるオプションもあります。

4

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

5

(オプション) このユーザーの代替番号を構成します。


リマインダー メールは現在 Cisco Webex Meetings ユーザーは利用できません。

1

https://admin.webex.com のカスタマー ビューから、[ユーザー] に行き、[ステータス] 列をフィルタリングし、[招待保留中] ステータスになっている人を表示します。

2

[アクション] の下で、[招待保留中] ステータスになっている人について、さらに [ > 招待状の再送信] を選択します。

組織でディレクトリ同期化を使用している場合には、Control Hub で削除オプションを使用することは使用できません。ユーザー アカウントを Active Directory から削除しておく必要があります。 また、ユーザーアカウント情報が同期された際、Cisco Directory Connector は、組織のユーザーリストを更新します。

https://admin.webex.com の顧客ビューから、[ユーザー] に移動して、さらに ボタンをクリックしてから [ユーザーの削除] をクリックします。

ユーザーは Webex サイトにサインインできなくなり、割り当てられていた Webex サービスは削除されます。また、参加しているスペースやチームから削除されます。 スペースで作成したコンテンツは削除されません。コンテンツには、各スペース所有者が実装した保持に関するポリシーが適用されます。

別の権限レベルをもつ顧客管理者を設定できます。 それらの管理者としては、フル管理者、サポート管理者、読み取り専用管理者またはコンプライアンス オフィサーがあり得ます。 フル管理者権限があれば、1 つまたは複数のロールを組織のユーザーに割り当てられます。


ユーザーおよびデバイス管理者を、またはデバイス管理者ロールを割り当てた人は、Webex Calling を管理することはできません。

ロールをユーザーに割り当てる

通常、1 組織に対して複数の管理者を設けるのがよいでしょう。 それはベスト プラクティスで、管理者の 1 人が使用できない場合、いつでも管理的な変更を行うことができます。

組織のユーザーには、特定の管理ロールを割り当てて、表示できるもの、およびコントロール ハブにアクセスできるかどうかを判断できます。 管理者の特定の役割を割り当てるときには、管理者の責任を合理化して、その責任を負いやすくしてください。 コンプライアンス担当者は、社内の特定のユーザーを検索し、彼らが共有したコンテンツを検索するか、特定のスペースを検索して、検索結果のレポートを生成することができます。


Cisco Webex Control Hub での HCS 管理者権限についての詳細は、以下を参照してください。 https://collabkp.cisco.com/detail/HCS_AdminRoles/data/cisco_toc/chcs_m_hcs-admin-privileges-control-hub.xml

1

https://admin.webex.comのカスタマー ビューから [ユーザー] に移動し、ユーザーを選択します。

2

[ロールとセキュリティ] の下で、 [管理者ロール] または [サービスアクセス] をクリックします。

3

そのユーザーに割り当てるロールを選択します。

ユーザーを Webex サイト管理者として指定するには、 [Webex サイト管理者ロール] のとなりにある (編集) をクリックし、 ユーザーが管理する 各 Webex サイトのロールを選択します。

4

[保存] を選択します。

ウォーター マーク
2020年7月27日| 回表示 | 人がこの投稿が役に立ったと考えています

Webex Calling デバイスの構成と管理

管理者として、Webex Control Hub のユーザーまたはワークスペースにデバイスを割り当てることができます。 デバイスの MAC アドレスを提供するか、後でデバイスに手動で入力する必要があるアクティベーション コードを生成するかを選択できます。

Cisco Webex Control Hub により、ユーザーに個人使用のためのデバイスを割り当て、それらのデバイスをクラウドに登録することができます。

ここに記載されているデバイスは 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


DECT デバイスに関しては、Control Hub では DECT ベース デバイス (DECT ハンドセットではありません) のみ割り当てに使用できます。 ベース ユニットをユーザーに割り当てた後、手動で DECT ハンドセットをそのベース ユニットにペアリングする必要があります。 詳細については、「ハンドセットを基地局に接続する」を参照してください。

1

の顧客ビューから https://admin.webex.com、[デバイス] に移動し、 次にデバイスの追加を クリックし ます。

2

[既存のユーザー] を選択し、電話機の所有者を入力します。ユーザー名または実名の一部を入力すると補完されるので、結果からユーザーを選択して、[次へ] をクリックします。

3

そして、ドロップダウン メニューからパーティションを選択し、[次へ] をクリックします。

4

以下のオプションのいずれかを選択して、[保存] をクリックします。

  • アクティベーション コード—デバイス所有者と共有可能なアクティベーション コードを生成する場合は、このオプションを選択します。 16桁のアクティベーション コードはデバイスに手動で入力する必要があります。

     

    マルチプラットフォーム電話のアクティベーション コード画面を表示するには、11.2.3 MSR1 以降のファームウェア ロードが必要です。 電話のファームウェアを更新する必要がある場合は、[ユーザー] をhttps://upgrade.cisco.com/MPP_upgrade.htmlに指定します。

  • MAC アドレス—デバイスの MAC アドレスを知っている場合は、このオプションを選択します。 電話機の MAC アドレスは固有なエントリーでなければなりません。 すでに登録されている電話機の MAC アドレスを入力した場合、または番号を入力する際に間違った場合には、エラー メッセージが表示されます。

 

サードパーティのデバイスを使用している場合、制限が適用される場合があります。

デバイスのアクティベーション コードの生成を選択しても、そのコードをまだ使用していない場合、Control Hub では、割り当てられているユーザーのデバイス セクションで、またコール管理ポータルでは、メイン デバイスの一覧 で、そのデバイスのステータスはアクティブ化として読み取ります。 デバイスが正常にアクティベートされるまで、アクティベーション デバイスは Control Hub のメイン デバイス ウィンドウに表示されません。 Control Hub でデバイスのステータスが更新されるまで最大 10 分かかる場合があることに注意してください。

ユーザーが職場にいる際、ランチ ルーム、ロビー、会議室などの場所に集まります。 これらのワークスペースで共有 Cisco Webex デバイスをセットアップし、サービスを追加して、コラボレーションの発生を確認することができます。

ワークスぺースデバイスの重要な原則は、特定のユーザーに割り当てられているのではなく、物理的な場所であり、共有使用が可能であることです。

ここに記載されているデバイスは 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

1

の顧客ビューから、[ https://admin.webex.comワークスペース] に移動し、次に「Workspace の追加」を クリックします。

2

ワークスペースの名前を入力します (物理的会議室の名前など)。会議室の種類を選択して、容量を追加します。 [次へ] をクリックします。

3

[Cisco IP 電話] を選択して[次へ] をクリックします。

4

ドロップダウン リストからデバイス タイプを選択し、アクティベーション コードまたは MAC アドレスで電話を登録するかどうかを選択し、[次へ] をクリックします。 アクティベーション コードを使用してデバイスを登録することを選択した場合、コードはその場所に指定された管理者にメールで送られることに注意してください。

Webex Calling には、1つの共有電話をワークスペースに追加することしかできません。

Cisco IP 会議電話 7832 の場合、一部のソフトキーが使用できない場合があります。 フルセットのソフトキーが必要な場合は、ユーザーにこの電話を割り当てることをお勧めします。

5

[ロケーション][電話番号](選択したロケーションによって決まるもの) を割り当てて、[保存] をクリックします。 拡張機能を割り当てるオプションもあります。

ユーザーが仕事をしている場合、ランチルーム、ロビー、会議室のような多くのワークスペースに集まってしまいます。 これらのワークスペースで共有 Cisco Webex デバイスをセットアップし、サービスを追加して、コラボレーションの発生を確認することができます。

ワークスぺースデバイスの重要な原則は、特定のユーザーに割り当てられているのではなく、物理的な場所であり、共有使用が可能であることです。

ここに記載されているデバイスは Webex Calling をサポートしています。

1

の顧客ビューから、[ https://admin.webex.comワークスペース] に移動し、次に「Workspace の追加」を クリックします。

2

ワークスペースの名前を入力します (物理的会議室の名前など)。会議室の種類を選択して、容量を追加します。 [次へ] をクリックします。

3

[その他の Cisco デバイス] を選択して[次へ] をクリックします。

その他の Cisco Webex Device には、Cisco Webex Board を含む Webex Room または 卓上デバイスなどがあります。

4

次のいずれかのオプションを選択します。

  • 無料コール—ユーザーは Webex Teams または Webex セッション開始プロトコル (SIP) コールのみを、SIP アドレス (例 username@example.calls.webex.com) を使用して行うことができます。
  • Cisco Webex Calling— Webex Teams と SIP 通話の送受信が可能であることに加えて、このワークスペースのユーザーはデバイスを使用して、Webex Calling 番号プラン内での電話通話を行うことができます。 例えば、電話番号 555-555-5555、内線 5555、または彼の SIP アドレス gedwards@example.webex.com にダイヤルすることで、同僚の Giacomo Edwards にコールすることができますが、ローカル pizzeria にコールすることもできます。
5

与えられたコードを使用してデバイスを有効にします。 アクティベーション コードはコピー、メール、または印刷により使用できます。

ユーザーや場所に割り当てる必要があるデバイスが複数ある場合は、必要な情報を含む CSV ファイルを作成し、それらのデバイスを 2 つの簡単な手順でアクティベートすることができます。

ここに記載されているデバイスは 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

1

https://admin.webex.comのカスタマー ビューから [デバイス] に移動し、[デバイスの追加] をクリックして、 ユーザーまたは場所にデバイスを追加するかどうかを選択します。

2

[CSV ファイルのインポート/アップロード] を選択します。

3

次のいずれかのオプションを選択します。

  • ユーザー属性のエクスポート—組織内のすべてのユーザーのリストと関連する属性を取得することで、各ユーザーを手動で参照する必要がなくなります。
  • CSV テンプレートのダウンロード—ユーザー名、タイプ(それがユーザーか場所のどちらかを示す)、MAC アドレス、デバイス モデルなどの情報を入力するためのテンプレートを使用することができます。 Cisco Spark アプリでコールを行うには、以下の点に留意してください:
    • CSV ファイルの [ユーザー名] 列には、ユーザー ID や名前ではなく、ユーザーのメールアドレスを入力することを確認してください。 この列に場所名を挿入することもできます。

    • CSV ファイルあたりのデバイス数を 1000 に制限することをお勧めします。 それ以上を追加する必要がある場合は、2 つ目の CSV ファイルを使用してください。

    • まだ存在していない場所を入力すると、その場所が自動的に作成されます。

    • MAC アドレス列を空欄にしておくと、アクティベーション コードが生成され、デバイス本体に入力する必要があります。

4

MAC アドレスが空のままの場合、アクティベーション コードを送信する場所を選択できます。

  • リンクの提供—アクティベーション コードが CSV ファイルに追加され、ダウンロードできるようになりました。
  • メール アクティベーション コード—デバイスが場所を対象にしている場合、アクティベーション コードが管理者として送信されます。 デバイスがユーザー用の場合、アクティベーション コードはユーザーにメールで送信されます。
5

データが入力された CSV ファイルをインポートします。

6

[送信] をクリックします。

デバイスがアクティベートされると、ステータスの更新が表示されます。

 

マルチプラットフォーム デバイスは、ユーザーがデバイスにアクティベーション コードを入力できるようにするために、11.2.3 MSR1 以降のファームウェア ロードを実行している必要があります。 電話機のファームウェアをアップグレードする方法については、こちらの記事を参照してください。

Cisco Webex Control Hub から Calling 管理ポータルをクロス起動でき、クラウド登録済みデバイスを管理することができます。

https://admin.webex.com のカスタマー ビューから、[デバイス] に移動してデバイスを選択し、[デバイスの管理] をクリックします。


 

Webex Calling デバイス以外を Calling 管理ポータルを通して直接構成することもできますが、これらのデバイスは Cisco から公式にサポートされているわけではありません。

次のタスク

このステップでは Calling 管理ポータル を起動し、クラウドに登録したデバイスを管理することができます。 詳細は [デバイス管理] を参照してください。

電話番号は、トライアル中であるか、有料のサブスクリプションに変更したかには関わりなく、顧客の卓上電話および室内デバイスにいつでも追加できます。


Control Hub で追加できる電話番号の数を 250 から 1000 に増やすことができました。

1

の顧客ビューから https://admin.webex.com、サービス通話番号に移動して、 > > [番号の追加] をクリックし ます。

2

[ロケーション][番号タイプ] を指定します。 番号を移行する場合には、現在の新しい請求番号と新しい番号の両方を入力してください。

3

コンマで区切って少なくとも 2 件の電話番号を入力し、[保存] をクリックします。

組織が注文した番号は、リストとして確認することができます。 この情報により、利用可能な未使用の番号、間もなく使用可能になる注文中の番号を表示できます。

の顧客ビューから https://admin.webex.com、[サービス通話の注文] に進み > > ます。

Calling 管理ポータルが表示されます。ここでは Calling 管理ポータル、提出された注文と処理が完了した注文を確認できます。 注文 ID がわかっている場合には、パラメーターとして入力して、特定の注文の詳細を表示することができます。そうでなくても、すべての注文の概要が表示されます。
ウォーター マーク
2020年7月27日| 回表示 | 人がこの投稿が役に立ったと考えています

Cisco Webex Calling の導入の傾向と使用のレポート

Webex Calling サービスがどのように、どのような頻度で使用されているかを判断するのに役立ち、簡単に分析できる多数のレポートを提供しています。 また、お客様の場所での、メディアの品質を簡単に評価できます。

コールレポートの表示

Webex Teams と Meetings のアクティベーションと使用に関する詳細を含む、Cisco Webex Control Hub のさまざまなレポートにアクセスできます。

Cisco Webex Control Hub からコールデータにアクセスすると、Calling 管理ポータルに移動します。 お客様の組織で Cisco Webex サービスがどのように使用されているか、どのくらいの頻度で使用されているかを評価するために、この情報を使用することができます。

https://admin.webex.com の顧客ビューから [分析] に移動し、[Webex Calling] を選択します。

コールの使用状況と品質を分析して評価することができる電話管理ポータルに自動的に移動します。 特定のコール機能で利用可能なレポートの詳細については、「Calling 管理ポータル-レポート」を参照してください。 コールアクティビティの詳細については、[Calling 管理ポータル-分析] を参照してください。

ロケーションのメディア品質を評価する

コールロケーションのメディア品質を、ロケーションごとのビューで取得します。 メディア品質は、顧客が特定のロケーションにおいて、Cisco MPP 電話から、およびコールソフト クライアントから発信および受信したコールの平均意見スコア (MOS) の集計に基づいています。 取り得る値は以下の通りです。

  • 高— > 3.2

  • 中— 2.7 ~ 3.2

  • 低—<2.7

  • 利用できるデータはありません—選択された期間にこのロケーションで発信や受信は行われていません。

1

https://admin.webex.com の顧客ビューから [分析] に移動し、[Webex Calling] を選択します。

Calling 管理ポータルに移動します。

2

[ダッシュボード] に移動し、[サービス アシュアランス] までスクロールして、組織全体の健全性を確認します。

CScan ツールで遅延、帯域幅、ポートを確認する場合には、[ネットワーク対応テスト] をクリックします。

次のタスク

ロケーションのスコアが低であった場合、いずれかのロケーションのメディア品質に問題があることを示しています。 一般的な原因としては、帯域幅が十分ではないことや、トラフィックの輻輳があります。 問題が解決しない場合は、https://admin.webex.com の顧客ビューに移動して、管理ユーザー名をクリックし、[フィードバック] をクリックして、ケースを開きます。

CSCAN ツールを実行する

Cisco CSCAN スキャンツールを使用して、遅延、帯域幅、およびポートを確認することができます。

https://cscan.webex.com/ に移動して、サーバーを選択し、[テストの実行] をクリックします。

ウォーター マーク
2020年7月27日| 回表示 | 人がこの投稿が役に立ったと考えています

Cisco Webex Calling のポート参照情報

電話とゲートウェイを任意の地域のものから Cisco Webex Calling に接続するために使用されるアドレス、ポート、およびプロトコルをここに一覧表示します。 製品版 (北米、EMEA、オーストラリア、および日本を含む) およびベータ版。 ネットワークを通過する特定のトラフィックに対してこれらのポートを利用できるようにする必要があります。 ローカル ゲートウェイの設定は、サービス プロバイダでも利用できるようになりました。

日付

この記事に次の変更を行いました

2020年7月22日

カナダのデータセンターの導入をサポートするために、次の IP アドレスを追加しました。 135.84.173.146

2020 年 6 月 9 日

CScan エントリに次の変更を行いました:
  • IP アドレスの1つを修正しました—199.59.67.156 を199.59.64.156 に変更した。

  • 新しい機能には、UDP だけでなく新しいポートも必要です。 19560-19760

2020年3月11日水曜日

次のドメインと IP アドレスをアプリケーション構成に追加しました:

  • 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.broadcloud.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

適切に構成されたファイアウォールは、コーリングの展開を正常に行うために不可欠です。 すべてのファイアウォール構成には、開いているポートが必要なわけではありませんが、内部から外部へのルールを実行している場合は、サービスのために必要なプロトコルを許可するためにポートを開く必要があります。

NAT を展開する限り、適切なバインド期間を定義し、NAT デバイスで SIP を操作しないようにするには、ファイアウォールでインバウンドのポートを開く必要はないはずです。


ルーターまたはファイアウォールが SIP に対応している場合、SIP アプリケーションレイヤーゲートウェイ (ALG) または同様に有効になっている場合、この機能をオフにして、サービスの正常な動作を維持することをお勧めします。 特定のデバイスで SIP ALG を無効にする方法については、関連する製造元のドキュメントを参照してください。

表 1. Webex Calling (製品版)

接続目的

ソース アドレス

ソース ポート

プロトコル

接続先アドレス

宛先ポート

Webex Calling へのコール信号 (SIP TLS)

ローカル ゲートウェイ外部 (NIC) 8000-65535

TCP

85.119.56.128/26

85.119.57.128/26

128.177.14.0/25

128.177.36.0/26

135.84.169.0/25

135.84.170.0/25

135.84.171.0/25

135.84.172.0/25

185.115.196.0/25

185.115.197.0/25

199.59.64.0/25

199.59.65.0/25

199.59.66.0/25

199.59.67.0/25

199.59.70.0/25

199.59.71.0/25

8934

デバイス

5060-5080

アプリケーション

一時的 (OS 依存)

Webex Calling へのコール メディア (SRTP)

ローカル ゲートウェイ外部 NIC

8000-48000

UDP

85.119.56.128/26

85.119.57.128/26

128.177.14.0/25

128.177.36.0/26

135.84.169.0/25

135.84.170.0/25

135.84.171.0/25

135.84.172.0/25

185.115.196.0/25

185.115.197.0/25

199.59.64.0/25

199.59.65.0/25

199.59.66.0/25

199.59.67.0/25

199.59.70.0/25

199.59.71.0/25

19560-65535

デバイス

19560-19660

アプリケーション

一時的

PSTN ゲートウェイへのコール信号 (SIP TLS) ローカル ゲートウェイ内部 NIC 8000-65535 TCP ITSP、PSTN GW または Unified CM PSTN オプションによって異なる (たとえば、Unified CM の 5060 または 5061)
PSTN ゲートウェイへのコール メディア (SRTP) ローカル ゲートウェイ内部 NIC

8000-48000

UDP ITSP、PSTN GW または Unified CM PSTN オプションによって異なる (たとえば、Unified CM の 5060 または 5061)

公開アドレスのエンドポイントへのコール信号 (SIP TLS)

85.119.56.128/26

85.119.57.128/26

128.177.14.0/25

128.177.36.0/26

135.84.169.0/25

135.84.170.0/25

135.84.171.0/25

135.84.172.0/25

185.115.196.0/25

185.115.197.0/25

199.59.64.0/25

199.59.65.0/25

199.59.66.0/25

199.59.67.0/25

199.59.70.0/25

199.59.71.0/25

一時的

TCP

エンドポイント IP

8934

デバイスの構成とファームウェアの管理 (Cisco デバイス)

Webex Calling デバイス

一時的

TCP

3.20.185.219

3.130.87.169

35.172.26.181

52.86.172.220

72.163.10.134

85.119.56.128/26

85.119.56.198

85.119.57.128/26

85.119.57.198

135.84.169.186

135.84.170.186

173.37.149.125

199.59.64.143

199.59.65.228

199.59.66.228

199.59.67.143

*ドメイン:

  • cisco-jp.bcld.webex.com

  • cisco.broadcloud.com.au

  • cisco.broadcloud.eu

  • cisco.broadcloud.eu

  • webapps.cisco.com

  • activate.cisco.com

  • activation.webex.com

  • cisco.sipflash.com

80, 443

**cloudupgrader.webex.com

**443, 6970

デバイス時間同期 (NTP)

Webex Calling デバイス

51494

UDP

85.119.56.128/26

85.119.57.128/26

135.84.169.154

135.84.170.154

199.59.64.152

199.59.65.181

199.59.66.181

199.59.67.152

123

デバイス名解決

Webex Calling デバイス

一時的

UDP および TCP

主催者が定義

53

アプリケーションの構成

Webex Calling アプリケーション

一時的

TCP

64.68.99.6

64.68.100.6

85.119.56.128/26

85.119.57.128/26

128.177.36.138

128.177.14.181

135.84.169.150

135.84.169.185

135.84.170.185

199.59.64.140

199.59.67.140

*ドメイン:

  • client-jp.bcld.webex.com

  • jp.bcld.webex.com

  • idbroker.webex.com

80、443、1081、2208、8443、5222、5280-5281、52644-52645

アプリケーション時間同期

Webex Calling アプリケーション

123

UDP

主催者が定義

123

アプリケーション名解決

Webex Calling アプリケーション

一時的

UDP および TCP

主催者が定義

53

CScan

Webex Calling デバイス

一時的

UDP および TCP

135.84.169.183

135.84.173.146

185.115.196.0/25

199.59.65.243

199.59.64.156

8934および80、443、19569-19760

† CUBE メディアポート範囲は rtp ポート範囲で構成可能です

*電話が初めてネットワークに接続したとき、またはファクトリリセット後に、DHCP オプションが設定されていない場合は、ゼロ タッチ プロビジョニングのデバイス アクティベーション サーバーと通信します。 新しい電話はプロビジョニングの webapps.cisco.com の代わりに activate.cisco.com を使用します。 11.2 (1) より前にファームウェアがリリースされた電話は、引き続き webapps.cisco.com を使用します。 ファイアウォールを通して両方のドメインを許可することをお勧めします。

**エンタープライズ電話 (Cisco Unified CM) から Webex Calling に移行する場合にのみ、cloudupgrader.webex.com および 443 と 6970 ポートを有効にする必要があります。 詳しくは、upgrade.cisco.com を参照してください。

表 2. Webex Calling (ベータ版)

接続目的

ソース アドレス

ソース ポート

プロトコル

接続先アドレス

宛先ポート

Webex Calling へのコール信号 (SIP/SIP TLS)

ローカル ゲートウェイ外部 NIC

8000-65535

TCP

135.84.171.0/25

135.84.172.0/25

199.59.65.0/25

199.59.66.0/25

199.59.70.0/25

199.59.71.0/25

8934

デバイス

5060-5080

アプリケーション

一時的な範囲 (OS 依存)

Webex Calling へのコール メディア (RTP/SRTP)

ローカル ゲートウェイ外部 NIC

8000-48000

UDP

135.84.171.0/25

135.84.172.0/25

199.59.65.0/25

199.59.66.0/25

199.59.70.0/25

199.59.71.0/25

19560-65535

デバイス

19560-19660

アプリケーション

一時的

PSTN ゲートウェイへのコール信号 (SIP TLS)

ローカル ゲートウェイ内部 NIC

8000-65535

TCP

ITSP、PSTN GW、またはUnified CM

PSTN オプションによって異なります。例: Unified CM、通常 5060 または5061

PSTN ゲートウェイへのコール メディア (SRTP)

ローカル ゲートウェイ内部 NIC

8000-48000

UDP

ITSP、PSTN GW、またはUnified CM

PSTN オプションによって異なる

公開アドレスのエンドポイントへのコール信号 (SIP/SIP TLS)

199.59.65.0/25

199.59.66.0/25

199.59.70.0/25

199.59.71.0/25

一時的

TCP

エンドポイント IP

8934

デバイスの構成とファームウェアの管理 (Cisco デバイス)

Webex Calling デバイス

一時的

TCP

173.37.149.125

199.59.66.227

199.59.65.227

*ドメイン:

  • betacisco.sipflash.com

  • webapps.cisco.com

  • activate.cisco.com

  • activation.webex.com

80, 443

**cloudupgrader.webex.com

**443, 6970

デバイス時間同期 (NTP)

Webex Calling デバイス

51494

UDP

199.59.65.181

199.59.66.181

123

デバイス名解決

Webex Calling デバイス

一時的

UDP および TCP

主催者が定義

53

アプリケーションの構成

Webex Calling アプリケーション

一時的

TCP

128.177.36.137

128.177.14.182

80, 443

アプリケーション時間同期

Webex Calling アプリケーション

123

UDP

主催者が定義

123

アプリケーション名解決

Webex Calling アプリケーション

一時的

UDP および TCP

主催者が定義

53

† CUBE メディアポート範囲は rtp ポート範囲で構成可能です

*電話が初めてネットワークに接続したとき、またはファクトリリセット後に、DHCP オプションが設定されていない場合は、ゼロ タッチ プロビジョニングのデバイス アクティベーション サーバーと通信します。 新しい電話はプロビジョニングのために webapps.cisco.com for provisioning の代わりに activate.cisco.com 11.2 (1) より前にファームウェアがリリースされた電話は、引き続き webapps.cisco.com を使用します。 ファイアウォールを通して両方のドメインを許可することをお勧めします。

**エンタープライズ電話 (Cisco Unified CM) から Webex Calling に移行する場合にのみ、cloudupgrader.webex.com および 443 と 6970 ポートを有効にする必要があります。 詳しくは、upgrade.cisco.com を参照してください。

表 3. Webex Calling (製品版)

接続目的

ソース アドレス

ソース ポート

プロトコル

接続先アドレス

宛先ポート

Webex Calling へのコール信号 (SIP TLS)

ローカル ゲートウェイ外部 NIC

8000-65535

TCP

85.119.56.128/26

85.119.57.128/26

135.84.169.0/25

135.84.170.0/25

135.84.171.0/25

135.84.172.0/25

185.115.196.0/25

185.115.197.0/25

199.59.64.0/25

199.59.65.0/25

199.59.66.0/25

199.59.67.0/25

199.59.70.0/25

199.59.71.0/25

128.177.14.0/25

128.177.36.0/26

8934

デバイス

5060-5080

アプリケーション

一時的 (OS 依存)

Webex Calling へのコール メディア (SRTP)

ローカル ゲートウェイ外部 NIC

8000-48000

UDP

85.119.56.128/26

85.119.57.128/26

135.84.169.0/25

135.84.170.0/25

135.84.171.0/25

135.84.172.0/25

185.115.196.0/25

185.115.197.0/25

199.59.64.0/25

199.59.65.0/25

199.59.66.0/25

199.59.67.0/25

199.59.70.0/25

199.59.71.0/25

128.177.14.0/25

128.177.36.0/26

19560-65535

デバイス

19560-19660

アプリケーション

一時的

PSTN ゲートウェイへのコール信号 (SIP TLS)

ローカル ゲートウェイ内部 NIC

8000-65535

TCP

ITSP、PSTN GW、またはUnified CM

PSTN オプションによって異なります。例: Unified CM、通常 5060 または5061

PSTN ゲートウェイへのコール メディア (SRTP)

ローカル ゲートウェイ内部 NIC

8000-48000

UDP

ITSP、PSTN GW、またはUnified CM

PSTN オプションによって異なる

公開アドレスのエンドポイントへのコール信号 (SIP TLS)

85.119.56.128/26

85.119.57.128/26

135.84.169.0/25

135.84.170.0/25

135.84.171.0/25

135.84.172.0/25

185.115.196.0/25

185.115.197.0/25

199.59.64.0/25

199.59.65.0/25

199.59.66.0/25

199.59.67.0/25

199.59.70.0/25

199.59.71.0/25

一時的

TCP

エンドポイント IP

8934

デバイスの構成とファームウェアの管理 (Cisco デバイス)

Webex Calling デバイス

一時的

TCP

3.130.87.169,

3.20.185.219

35.172.26.181,

52.86.172.220

72.163.10.134

85.119.56.198

85.119.57.198

135.84.169.186

135.84.170.186

173.37.149.125

199.59.64.143

199.59.65.228

199.59.66.228

199.59.67.143

*ドメイン:

  • cisco-jp.bcld.webex.com

  • cisco.broadcloud.eu

  • cisco. broadcloud.com.au

  • cisco.sipflash.com

  • webapps.cisco.com

  • activate.cisco.com
  • activation.webex.com

80, 443

**cloudupgrader.webex.com

**443, 6970

デバイス時間同期 (NTP)

Webex Calling デバイス

51494

UDP

85.119.56.218

85.119.57.218

135.84.169.154

135.84.170.154

199.59.64.152

199.59.65.181

199.59.66.181

199.59.67.152

123

デバイス名解決

Webex Calling デバイス

一時的

UDP および TCP

主催者が定義

53

アプリケーションの構成

Webex Calling アプリケーション

一時的

TCP

64.68.99.6

64.68.100.6

85.119.56.197

85.119.57.197

128.177.36.138

128.177.14.181

135.84.169.150

135.84.169.185

135.84.170.185

199.59.64.140

199.59.67.140

*ドメイン:

  • client-jp.bcld.webex.com

  • jp.bcld.webex.com

  • idbroker.webex.com

80, 443

アプリケーション時間同期

Webex Calling アプリケーション

123

UDP

主催者が定義

123

アプリケーション名解決

Webex Calling アプリケーション

一時的

UDP および TCP

主催者が定義

53

CScan

デバイス

一時的

UDP および TCP

135.84.169.183

135.84.173.146

185.115.196.129

199.59.65.243

199.59.64.156

8934および80、443、19560-19760

† CUBE メディアポート範囲は rtp ポート範囲で構成可能です

*電話が初めてネットワークに接続したとき、またはファクトリリセット後に、DHCP オプションが設定されていない場合は、ゼロ タッチ プロビジョニングのデバイス アクティベーション サーバーと通信します。 新しい電話はプロビジョニングのために webapps.cisco.com for provisioning の代わりに activate.cisco.com 11.2 (1) より前にファームウェアがリリースされた電話は、引き続き webapps.cisco.com を使用します。 ファイアウォールを通して両方のドメインを許可することをお勧めします。

**エンタープライズ電話 (Cisco Unified CM) から Webex Calling に移行する場合にのみ、cloudupgrader.webex.com および 443 と 6970 ポートを有効にする必要があります。 詳しくは、upgrade.cisco.com を参照してください。

表 4. Webex Calling (ベータ版)

接続目的

ソース アドレス

ソース ポート

プロトコル

接続先アドレス

宛先ポート

Webex Calling へのコール信号 (SIP TLS)

ローカル ゲートウェイ外部 NIC

8000-65535

TCP

135.84.171.0/25

135.84.172.0/25

199.59.65.0/25

199.59.66.0/25

199.59.70.0/25

199.59.71.0/25

8934

デバイス

5060-5080

アプリケーション

一時的な範囲 (OS 依存)

Webex Calling へのコール メディア (SRTP)

ローカル ゲートウェイ外部 NIC

8000-48000

UDP

135.84.171.0/25

135.84.172.0/25

199.59.65.0/25

199.59.66.0/25

199.59.70.0/25

199.59.71.0/25

19560-65535

デバイス

19560-19660

アプリケーション

一時的

PSTN ゲートウェイへのコール信号 (SIP TLS)

ローカル ゲートウェイ内部 NIC

8000-65535

TCP

ITSP、PSTN GW、またはUnified CM

PSTN オプションによって異なります。例: Unified CM、通常 5060 または5061

PSTN ゲートウェイへのコール メディア (SRTP)

ローカル ゲートウェイ内部 NIC

8000-48000

UDP

ITSP、PSTN GW、またはUnified CM

PSTN オプションによって異なる

公開アドレスのエンドポイントへのコール信号 (SIP TLS)

135.84.171.0/25

135.84.172.0/25

199.59.65.0/25

199.59.66.0/25

199.59.70.0/25