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 に参加するよう少数のユーザーを招待することをお勧めします。 コールを含む、提供されるサービスを使用するようにユーザーを促し、彼らの満足度に関するフィードバックを提供することを求めます。 準備が完了したら、いつでもユーザーを追加することができます。


Control Hub にアクセスするには最新の 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 に接続する] をオンにします。