展開は、ドメインと 1 つ以上の Unified Communications サービスプロバイダー (Unified CM、Cisco Unity Connection、IM and Presence Service ノードなど) を囲うために使用される抽象的な境界です展開を複数にする目的は、モバイルおよびリモートアクセス（MRA）ユーザーが使用できる Unified Communications サービスをパーティション化することです。よって、MRA ユーザーの異なるサブセットが同じ Expressway ペアを介してサービス一式にアクセスできます。

10 以上の展開はお勧めしません。

展開、関連ドメインおよびサービスは、Expressway-C で構成されます。

追加の展開を作成し、実装しない限り、1 つのプライマリ展開（名前を変更しなければ「デフォルト展開」と呼ばれる）は、自動ですべてのドメインとサービスを自動包囲します。このプライマリ展開は、名前を変更してもメンバーがいなくても削除できません。

モバイルおよびリモートアクセスを介したサービスをパーティション化するには、必要な数の展開を作成します。それぞれに異なるドメインを関連付けたら、必要な Unified Communications リソースを各展開に関連付けます。

1 つのドメインを 1 つ以上の展開に関連付けることはできません。同様に、各 Unified Communications ノードには、1 つの展開のみ割り当てることができます。

例

2 つの Unified Communications インフラストラクチャを本運用 MRA 環境とステージング環境にそれぞれ実装するとします。この実装には、3 つ目のセットとして機密通信用の独立した環境も必要になる場合があります。

MRA 展開に、iOS または Android デバイスで実行される Cisco Jabber または Webex クライアントが含まれている場合は、プッシュ構成を展開する必要があります。プッシュ構成がない場合、バックグラウンドモードに入ったクライアントにコールやメッセージを送信できない場合があります。

プッシュ構成の動作

クラスタでプッシュ構成が有効になっている場合、Cisco Unified Communications Manager と IM and Presence Service は、Apple または Google のいずれかのプッシュ構成サービスを使用してコールにプッシュ構成を、iOS または Android デバイスで実行する Cisco Jabber または Webex クライアントにメッセージを送信します。プッシュ構成を使用すると、システムがバックグラウンドモード（サスペンドモードとも呼ばれる）に入った後でも、クライアントと通信できます。プッシュ構成がない場合、バックグラウンドモードに入ったクライアントにコールやメッセージを送信できない場合があります。

起動時に、Android および iOS プラットフォームデバイスにインストールされているモバイルおよびリモートの Cisco Jabber または Cisco Webex クライアントは、Expressway-E を介して Cisco Unified Communications Manager および IM and Presence Service に登録されます。クライアントがフォアグラウンドモードのままである限り、新しいコールまたはメッセージを Expressway-E 経由でクライアントに送信できます。ただし、クライアントがバックグラウンドモードに移行すると、標準の通信チャネルは使用できなくなります。プッシュ構成は、該当するパートナークラウド（Apple または Google）を介してクライアントに到達するために大体チャネルを提供します。

プッシュ構成要件

Expressway-E が、Jabber iOS デバイス用にモバイルおよびリモートアクセス（MRA）をすでに提供している場合、プッシュ構成に対しては、Expressway での特定の構成は必要ありません。ただし、次の前提条件および推奨事項が適用されます。

• Expressway のプッシュ構成には、Apple クラウドの Cisco Jabber とプッシュ構成サーバー間でネットワークが必要です。

  インターネットに接続していないプライベートネットワークでは動作しません。

• Expressway は、すでに Jabber for iPhone/iPad に対してモバイルおよびリモートアクセスを提供しています。MRA は完全に構成されている必要があります（ドメイン、ゾーン、サーバ設定）。

• Unified CM 構成に応じて、プッシュ構成を Cisco コラボレーション クラウド に送信するためにフォワードプロキシが必要な場合があります。

• 自己記述トークン承認を使用することを推奨します。

• インスタントメッセージによるプッシュ構成には、Expressway-E の再起動が必要です。IM and Presence Service でプッシュ構成を有効化したら、Expressway-E を再起動する必要があります。再起動するまで、Expressway-E は、IM and Presence Service でプッシュ機能を認識できず、Jabber クライアントに PUSH メッセージを送信しません。

モバイルおよびリモートアクセスの Expressway 展開では、Unified CM と Expressway-C 間の SIP トランク接続は必要ありません。 Expressway-C と検出された Unified CM ノードの間に自動生成されたネイバーゾーンは SIP トランクではないことに注意してください。

ただし、必要に応じて SIP トランクを構成することもできます。（たとえば、B2B 発信者または Expressway に登録されたエンドポイントを有効化して、Unified CM に登録されたエンドポイントにコールするなどが挙げられます。）

SIP トランクが構成されている場合、Unified CMUnified CM への SIP 回線登録に使用されるポートとは別のリスニング ポートを Unified CM で使用する必要があります。競合が起きると、Expressway-C でアラームが出ます。

SIP トランクで使用するポートは、Unified CM と Expressway の両方で構成されます。

SIP トランクの構成詳細については、『Cisco Expressway SIP トランクから Unified CM 導入ガイド』を参照してください。

SIP トランクに OAuth ベースの認証を設定する方法については、 「UC アプリケーションで OAuth を構成する」を参照してください。

Expressway は、MRA 経由の組み込みブリッジ（BiB）録音をサポートしています。この機能は、欧州連合の Markets in Financial Instruments Directive（MiFID II）における電話録音の要件を遵守するのに役立ちます。

提供内容の概要

• BiB を使用して、オフプレミスで作業しているユーザが発信または受信したコールの音声部分を録音できます。

• BiB は Expressway で常に有効になっています。

• BiB は Cisco Unified Communications Manager で設定できます。BiB が有効になっている場合、Unified CM は、エンドポイント間での発着コールをメディア録音サーバにフォークします。

帯域幅とキャパシティの要件

この機能を使用する場合は、帯域幅とコールキャパシティに大きな影響を与えることに注意してください。

• 追加のネットワーク帯域幅をプロビジョニングする必要があります。詳細については、「シスコ コラボレーション システム 12.x ソリューション リファレンス ネットワーク デザイン（SRND）」の「監視および録音用キャパシティプラン」項を参照してください。MRA エンドポイントに対して BiB を有効にするには、通常 2 倍の帯域幅が必要です。これは、コールの発信側と着信側の両方が録音されると仮定すると、BiB 対応の各コールが通常の 2 倍の帯域幅を消費するためです。

• MRA エンドポイントで BiB を有効にすると、Expressway ノードの全体的なコール キャパシティが元のキャパシティの約 3 分の 1 に減少します。これは、録音されている各通話に、それに関連付けられた 2 つの追加の SIP ダイアログがあるためです（したがって、本質的に 3 つの通話に相当します）。

設定要件

MRA を介して BiB Recording を展開するには、次のように構成します。

• BiB 録音を Cisco Unified Communications Manager で構成します。手順の詳細については、「Cisco Unified Communications Manager 向け機能構成ガイド」の「通話録音」章を参照してください。

• SIP パスヘッダーは、Expressway で有効にします。詳細については、SIP パスヘッダーの有効化を参照してください。

さらに、次の要件も満たす必要があります。

• 互換性のあるクライアントが必要です

  • Windows 版 Cisco Jabber 11.9

  • Mac 版 Cisco Jabber 11.9

  • iPhone および iPad 版 Cisco Jabber 11.9

  • Android 版 Cisco Jabber 11.9

  • MRA 対応の Cisco IP Phone 7800 シリーズ、Cisco IP Conference Phone 7832 または Cisco IP Phone 7800 シリーズ デバイス（これらすべての電話が MRA 対応であるとは限りません）

  • 現在 MRA に対応している電話に関しては、このガイドの「MRA インフラストラクチャ要件」項を参照するか、シスコ担当者にお問い合わせください。

• レジストラ/呼制御エージェント：Cisco Unified Communications Manager 11.5(1)SU3 BiB は、Expressway 登録エンドポイントではサポートされていません。

• エッジ トラバーサル：Expressway X8.11.1 以降

• レコーディング サーバ：このドキュメントの範囲外です。（Cisco Unified Communications Manager における録音の設定方法の詳細については、『Cisco Unified Communications Manager 機能設定ガイド』を参照してください。）

HTTP 許可リストは、HTTP サービスのアクセスリストの一種です。Expressway-C は、インバウンドルールとアウトバウンドルールの両方を自動追加します。たとえば、Expressway は、MRA 構成中に検出された Unified Communications ノードに外部クライアントがアクセスできるようにするインバウンドルールを自動追加します。これらには、Unified CM ノード（CallManager および TFTP サービスを実行する）、IM and Presence Service ノード、および Cisco Unity Connection ノードが含まれます。

ただし、場合によっては、特定のタイプのアクセスを許可するためにインバウンドルールを編集する必要があります。アウトバウンドルールは編集できません。

• インバウンドルールを表示するには、[構成（Configuration）] > [Unified Communications] > [HTTP許可リスト（HTTP allow list）] > [自動インバウンドルール（Automatic inbound rules）]の順に選択します。

• アウトバウンドルールを表示するには、[構成（Configuration）] > [Unified Communications] > [HTTP許可リスト（HTTP allow list）] > [自動アウトバウンドルール（Automatic outbound rules）]の順に選択します。

HTTP 許可リストの編集

リモートクライアントが企業内の他の Web サービスにアクセスする必要がある場合は、独自のインバウンドルールを HTTP 許可リストに追加できます。たとえば、次のサービスでは許可リストの構成が必要になる場合があります。

• Jabber アップデート サーバ

• Cisco Extension Mobility

• ディレクトリ フォト ホスト

• マネージド ファイル転送

• Problem Report Tool サーバー

• ビジュアル ボイスメール

<link to Appendix and other places for more info>

HTTP 許可リストにアウトバウンドルールを追加することはできません。また、リストに自動追加されたルールを編集または削除することはできません。

（注）	[マネージドファイル転送（Managed File Transfer）] 機能が Expressway 全体で機能するようにするには、手動または自動で追加されたかどうかにかかわらず、すべての Unified CM IM and Presence Service ノードが許可リストに表示されていることを確認してください。

自動インバウンドルール

Expressway は、Unified Communications ノードを検出または更新すると、HTTP 許可リストを自動編集します。このページには、検出されたノードと、それらのノードに適用されるルールが表示されます。

最初のリストは検出されたノードであり、この Expressway-C で現在認識されているすべてのノードが含まれています。各ノードのリストには、ノードのアドレス、タイプ、および発行元のアドレスが含まれています。

2 番目のリストは、さまざまなタイプの Unified Communications ノードへのクライアントアクセスを制御するために追加されたルールです。MRA 構成のノードのタイプごとに、このリストに 1 つ以上のルールが表示されます。編集可能なルールと同じ形式で表示されますが、これらのルールを変更することはできません。

モバイルワーカーは、オフィスで電話をかけるときと同じ高品質、セキュリティ、信頼性を必要としています。Dial via Office-Reverse（DVO-R）機能を有効にして、デュアル モード モバイル デバイスで Cisco Jabber を使用している場合は、そのことを保証できます。DVO-R は、企業を介して Cisco Jabber call を自動的にルーティングします。

DVO-R は、コールシグナリングと音声メディアを別々に処理します。Expressway でのモバイルおよびリモートアクセスのシグナリングを含むコールシグナリングは、クライアントと Cisco Unified Communications Manager 間の IP 接続を通過します。音声メディアは、企業の公衆電話交換網（PSTN）（PSTN）ゲートウェイのセルラーインターフェイスとヘアピンを通過します。オーディオをセルラーインターフェイスに移動すると、IP 接続が失われた場合でも、高品質な通話とオーディオは安全に維持されます。

DVO-R を構成して、ユーザーが通話発信したときに、Cisco Unified Communications Manager からの折り返し通話が次のいずれかに送信されるようにすることができます。

• ユーザーのモバイル ID（携帯電話番号）。

• ユーザーの代替番号（ホテルの部屋など）。

DVO-R over MRA のコールフローの例

次のコールフローは、モバイル ID または代替番号のいずれかに折り返し通話を送信する場合の、MRA 通話経由の Dial via Office Reverse について説明します。コールフローの図については、後続の画像を参照してください。

1. 番号をダイヤルすると、信号が IP パス（WLAN またはモバイル ネットワーク）を介して Cisco Unified Communications Manager に送信されます。

2. Cisco Unified Communications Manager は、自分の携帯電話番号または設定した代替番号に電話をかけます。

3. 応答すると、Cisco Unified Communications Manager はダイヤルした番号に通話を転送し、呼び出し音が鳴ります。

4. その人が応答すると、進行中の通話は企業の PSTN ゲートウェイでヘアピンされ、次の処理が行われます。

   • モバイル ID を使用すると、通話は企業ゲートウェイに固定されます。通話は携帯電話とデスクフォンでアクティブであるため、この 2 つを切り替えることができます。

   • 代替番号を使用すると、進行中の通話は固定されず、デスクフォンには出られません。

DVO の要件

この機能は、関連システムの次のバージョンで必要です。

• Cisco Unified Communications Manager 11.0(1) 以降

• Cisco Jabber 11.1 以降

補足事項

• PSTN ゲートウェイと Cisco Unified Communications Manager 間にアウトオブバンド DTMF リレーがある場合、アンカーされたコールで Dual Tone Multi Frequency（DTMF）ベースの通話中機能（例：保留は *81）を使用できます代替番号を使用している場合は、通話中機能を利用できません。

• Cisco Unified Communications Manager からのコールバックレッグがボイスメールにルーティングされるのを防ぎ、ダイヤルしている相手にボイスメールコールが届かないようにするには、DVO-R ボイスメール ポリシーを [ユーザ制御ー（user controlled）] に設定することをお勧めします。これにより、通話を続行する前に、キーパッドのいずれかのキーを押して DTMF トーンを生成する必要があります。

このセクションでは、マルチクラスタ MRA 展開を構成するためのヒントとベストプラクティスについて概説します。次に、マルチクラスタ MRA 展開を構成する際に留意すべきいくつかのベストプラクティスを示します。

• すべての Expressway-C クラスタを、すべての UC クラスタに接続する必要があります。そうしないと、Expressway-C はすべての UC クラスタに要求をプロキシできません。各 Expressway-C クラスタのプライマリピアで、Expressway-C が到達する必要がある各 UC クラスタのパブリッシャ ノードを追加してから、サーバーを更新します。これにより、さまざまな UC クラスタからの残りのサブスクライバノードが Expressway-C に入力されます。

• 一部のクラスタが SIP ドメインを共有している場合：各ユーザーが特定のクラスタに割り当てられるように、各ユーザーの [ホームクラスタ（Home Cluster）] 設定を有効にする必要があります。この設定は、Cisco Unified Communications Manager の [エンドユーザー構成（End User Configuration）] ウィンドウに表示されます。

• 同じドメイン内に複数の Unified CM クラスタがある場合、特に大規模なクラスタ間ネットワークでは、クラスタ間検索サービス (ILS) が推奨されます。初期設定後、ILS は ILS ネットワーク全体で自動クラスタ検出とダイヤル プラン レプリケーションを提供します。ただし、クラスタ検出は手動で構成できるため、ILS は必須ではないことに注意してください。ILS の構成方法については、『Cisco Unified Communications Manager 向け システム構成ガイド』を参照してください。

• 同じドメイン内に複数の IM and Presence Service クラスタがある場合は、同じドメインにある IM and Presence クラスタの Intercluster Sync Agent（ICSA）を使用してクラスタ間ピアリングを構成する必要があります。クラスタ間ピアリングの構成方法については、『IM and Presence Service 向け構成およびアドミニストレーション ガイド』を参照してください。

• 複数の Edge クラスタがある場合は、それらの間で負荷分散を構成します

  • これらのエッジが同じデータセンターにある場合は、負荷分散にドメインネームシステム（DNS）SRV を使用できます。

  • エッジが地理的境界（異なる都市または大陸）にまたがって分割されている場合は、GeoDNS を使用できます。GeoDNS SRV レコードを使用してリクエストを適切なエッジサーバーにルーティングする方法の例については、以下を参照してください。

マルチクラスタの GeoDNS の例

GeoDNS over MRA は、クライアントが MRA に使用される Expressway から比較的離れている場合に、最も近い Expressway を提供するという特定の目的でサポートされます。これにより、待ち時間とネットワーク遅延を最小限に抑えることができます。

次の例は、複数の Unified CM クラスタに接続する 2 つの Expressway-C クラスタを使用したマルチクラスタ展開を示しています。この例では、単一のドメインを使用していますが、地理的に離れた 2 つの Expressway クラスタを使用しているため、2 つのエンタープライズエッジが提供されます。DNS プロバイダーによっては、GeoDNS を SRV または CNAME レコードに適用できます（SRV が使用可能な場合は優先されます）。以下は、2 つの Edge ドメイン（1 つはヨーロッパにあり、もう 1 つは米国にある Edge）がある場合に、GeoDNS を使用する方法の 2 つの例です。

ドメインネームシステム（DNS）プロバイダーがサポートしている場合、推奨される SRV アプローチは、ユーザーの場所（たとえば、米国またはヨーロッパ）に基づく優先度設定での SRV レコード作成です。SRV は、ユーザーの場所と、各エッジサーバーに割り当てられている優先度設定を使用して、要求の送信先のサーバーを決定します。その要求が失敗した場合、他のサーバーはバックアップオプションを提供します。

以下は、2 つの CNAME エイリアス（メインエイリアスと優先度の低いバックアップ CNAME）にルーティングする GeoDNS SRV 構成レコードの例です。各 CNAME レコードは、ユーザーの場所に基づいて異なるサーバーに通話をルーティングします。メイン CNAME に障害がある場合、バックアップ CNAME は通話を別のリージョンのサーバーに送信します（NA ユーザーはヨーロッパベースの Expressway にルーティングされます）。

（注）	SRV アプローチでは、SRV の重み設定をすべてのレコードで同じままにします。

（注）

発信者のロケーションに基づいて通話をルーティングできるように、Unified CM で地理ベースのコーリングサーチスペースとパーティションを設定する必要がある場合もあります。たとえば、地理ベースのコーリングサーチスペース（特定の都市の CSS）を作成し、その都市にあるすべての電話をその CSS 内に配置できます（1 つの CSS は「New_York_CSS」と呼ばれ、別の CSS は「Chicago_CSS」と呼ばれる場合があります) 」） 詳細については、https://www.cisco.com/c/en/us/td/docs/solutions/CVD/Collaboration/enterprise/12x/120/collbcvd/edge.html#pgfId-1081382 の「シスコ コラボレーション 12.x 企業オンプレミス展開向け優先アーキテクチャ」に記載されている「コラボレーション エッジ ソリューションのスケーリング」を参照してください。

このセクションでは、複数のドメインで MRA を展開するお客様向けに、ドメイン関連の情報と構成プロセスの概要を説明します。モバイルおよびリモートアクセスの理想的なシナリオは、すべてのコラボレーション アプリケーションとエンドポイントに対して単一ドメインを割り当てることですが、これがすべての場合に可能であるとは限りません。ネットワークによっては、マルチドメイン設定の複雑さのレベルが異なる場合があるため、ドメイン設定を使用できるさまざまなコンテキストを理解することが重要です。

複数エッジドメイン

次の図は、内部 UC ドメインが外部ドメインと異なる基本的なマルチドメインシナリオを示しています。

（注）	MRA エンドポイントは、Expressway-E に到達できるように、外部パブリック ドメインネームシステム（DNS）サーバーに接続できる必要があります。

個別のデプロイメントを持つ複数のドメイン

次の例は、内部 UC 環境が 2 つの展開（デフォルトの UC 展開）に分割されている、より複雑なマルチドメインシナリオを示しています。これには、Expressway と 2 番目のステージング展開の両方を含む、メインの UC アプリケーションが含まれます。2 つの展開は、異なるドメインにあります。デフォルトの展開には、ILS と ICSA を使用して内部クラスタ間でデータを同期する複数の UC クラスタがあります。この例では、別の外部 IdP ドメインにあるクラウドベースの ID プロバイダーも使用しています。

ドメイン用語一覧

次の表は、MRA 展開内でドメイン用語を使用できるさまざまなコンテキストと、それらを Expressway で設定する方法を概説しています。展開によっては、これらすべてのコンテキストに同じドメインが適用される場合があります。

セッション持続性により、ローミング中のユーザーエクスペリエンスが向上し、Webex アプリで次のことができるようになります。

• ネットワーク内の異なるアクセスポイント間をローミングします。

• 再登録することなく、異なるネットワーク（Wi-Fi、VPN over 3G/4G など）間をローミングできます。

• 異なるネットワーク間をローミングしている間、SIP ベースのサブスクリプション ステータスを維持します。

• ネットワーク接続が失われた場合に備えて登録を維持します。

• アクティブな通話と保留中の通話の両方を、通話が途切れることなく、あるネットワークから別のネットワークにシームレスに転送します。

ネットワーク間のローミング中の接続を容易にするために、セッション持続性では、キープアライブ登録による動的な IP アドレス/ポートの変更が可能です。さらに、この機能には構成可能な TCP 再接続タイマーが含まれており、これは製品レベルで有効にする必要があり、一時的なネットワーク接続の切断またはローミングの場合に Webex アプリクライアントが接続を維持できるようにする必要があります。タイマーは、クライアントが元の TCP 接続を明示的に切断した場合にのみ有効です。セッション持続性機能を利用するには、シスコ定義の SIP インターフェイスに準拠する必要があります。

たとえば、オフィス内で Webex アプリクライアントで通話中に、Wi-Fi 接続を失って建物の外に出た場合、クライアントが Expressway 経由でモバイルおよびリモートアクセスに切り替えると、通話は続行されます。同様に、クライアントが Expressway 経由でモバイルおよびリモートアクセスからオフィスの Wi-Fi ネットワークに切り替えても、通話が切断されることはありません。

Note	セッション永続性機能にはソフトウェアの依存関係があり、Expressway での設定は必要ありませんが、機能が正しく動作するために CUCM でチェックするポリシーがあります。

以下は、ソフトウェアの依存関係です: Wi-Fi から LTE へのコールハンドオフは、ソフトクライアントのエンドユーザーが、ネットワークの切り替え中にアクティブな通話を切断することなく、Wi-Fi ネットワークと LTE ネットワークを切り替えることができるようにします。Wi-Fi から LTE へのコールハンドオフ機能は自動的に有効になりますが、Unified Communications Manager リリース 14SU1 以降が必要です。

通話中に、ソフトクライアントがネットワークの変更を検出すると、登録の切り替えを行い、切り替えについてエンドユーザーに音声やビジュアルで表示してアクティブな通話を再接続します。ただし、ユーザーは、通話でシームレスなオーディオとビデオのエクスペリエンスを引き続き利用できます。