Cisco Collaboration 9.xソリューション リファレンス ネットワーク デザイン(SRND)
モバイル コラボレーション
モバイル コラボレーション
発行日;2013/10/03 | 英語版ドキュメント(2013/09/09 版) | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 30MB) | フィードバック

目次

モバイル コラボレーション

この章の新規情報

社内型モビリティ

キャンパス企業モビリティ

キャンパス企業モビリティのアーキテクチャ

キャンパス モビリティのタイプ

物理的な有線デバイスの移動

ワイヤレス デバイスのローミング

エクステンション モビリティ(EM)

キャンパス企業モビリティのハイ アベイラビリティ

キャンパス企業モビリティのキャパシティ プランニング

キャンパス企業モビリティの設計上の考慮事項

マルチサイト企業モビリティ

マルチサイト企業モビリティのアーキテクチャ

マルチサイト企業モビリティのタイプ

物理的な有線デバイスの移動

ワイヤレス デバイスのローミング

エクステンション モビリティ(EM)

デバイス モビリティ

マルチサイト企業モビリティのハイ アベイラビリティ

マルチサイト企業モビリティのキャパシティ プランニング

マルチサイト企業モビリティの設計上の考慮事項

リモート企業モビリティ

リモート企業モビリティのアーキテクチャ

リモート企業モビリティのタイプ

クライアントベースの安全なリモート接続

ルータベースの安全なリモート接続

デバイス モビリティと VPN ベースのリモート企業接続

エンタープライズ エッジの安全なリモート接続

リモート企業モビリティのハイ アベイラビリティ

リモート企業モビリティのキャパシティ プランニング

リモート企業モビリティの設計上の考慮事項

社外型モビリティ

Cisco Unified Mobility

モバイル コネクト

モバイル コネクトの機能

モバイル コネクトのアーキテクチャ

モバイル コネクトのハイ アベイラビリティ

Cisco TelePresence FindMe

モバイル ボイス アクセスとエンタープライズ機能アクセス

モバイル ボイス アクセス IVR VoiceXML ゲートウェイ URL

モバイル ボイス アクセス機能

2 ステージ ダイヤリングを伴うエンタープライズ機能アクセス

モバイル ボイス アクセスとエンタープライズ機能アクセスのアーキテクチャ

モバイル ボイス アクセスおよびエンタープライズ機能アクセスのハイ アベイラビリティ

Cisco Unified Mobility の配置の設計

Cisco Unified Mobility のダイヤル プランに関する考慮事項

Unified Mobility に関するガイドラインと制約事項

Cisco Unified Mobility のキャパシティ プランニング

Cisco Unified Mobility の設計上の考慮事項

シスコの Cisco Mobile クライアントおよびデバイス

シスコのモバイル クライアントおよびデバイスのアーキテクチャ

シスコの Cisco Mobile クライアントおよびデバイス

シスコのモバイル クライアントおよびデバイスのハイ アベイラビリティ

シスコのモバイル クライアントおよびデバイスのキャパシティ プランニング

シスコのモバイル クライアントおよびデバイスの設計上の考慮事項

モバイル コラボレーション

モバイル コラボレーション ソリューションおよびアプリケーションを使用すれば、モバイル ワーカーはどこからでも会社の IP コミュニケーション環境の機能を利用できます。モバイル コラボレーション ソリューションを使用すると、モバイル ユーザはビジネス コールをさまざまなデバイスで扱うことができ、オフィスビル内の移動中やオフィス間の移動中、地理的に会社外のロケーション間の移動中に企業アプリケーションにアクセスできます。モバイル コラボレーション ソリューションでは、モバイル ワーカーは持続的に到達可能性を得ることができ、さまざまな場所での移動中や作業中の生産性を向上させることができます。

モバイル コラボレーション ソリューションは、次の 2 つの主なカテゴリに分けられます。

社内型モビリティ

このタイプのモビリティは、企業の敷地内での移動に限られます。

社外型モビリティ

このタイプのモビリティは、企業インフラストラクチャの外部にまで至るモビリティを指し、一般には何らかの形のインターネット、モバイル ボイス ネットワーク、およびモバイル データ ネットワーク通過が含まれます。

社内型モビリティは、企業のネットワーク境界内に使用が制限されます。この境界は単一の物理的な建物のみを範囲としても、近くの、あるいは離れた複数の物理的な建物を範囲としても、またはホーム オフィスまで広がったネットワーク インフラストラクチャの場合、企業により制御され管理されるホーム オフィスを範囲としてもかまいません。

一方、社外型モビリティには、企業インフラストラクチャによるインターネットまたはモバイル プロバイダー インフラストラクチャへのブリッジングが含まれ、ユーザは公共およびプライベート ネットワークを使用して企業サービスに接続できます。これらの 2 つのタイプのモビリティ間の線引きはあいまいな場合もあり、特にモバイル デバイスが、インターネットまたはモバイル データおよびモバイル ボイス ネットワークを介したコラボレーション サービスで企業に接続するようなシナリオの場合に顕著です。

社内型モビリティは、フィーチャ セットおよびソリューションに基づき、次の 3 つの主要な領域に分けられます。

キャンパス/単一サイト モビリティ

このタイプの企業モビリティでは、ユーザの移動は、一般に単一の IP アドレス空間および PSTN 入出力境界により区切られた単一の物理ロケーション内になります。このタイプのモビリティには、1 つの物理ネットワーク ポートから他のポートへの電話の移動や、ワイヤレス インフラストラクチャ アクセス ポイント間でのワイヤレス LAN デバイスのローミング、ユーザが一時的に異なる領域への特定の電話機に企業電話番号などのデバイス プロファイルを適用する Cisco エクステンション モビリティ(EM)などの操作や機能が含まれます。

マルチサイト モビリティ

このタイプのモビリティでは、ユーザは企業内の 1 つの物理ロケーションから他のロケーションに移動します。この移動には、一般的に IP アドレス空間の交差や PSTN 入出力境界も含まれます。このタイプのモビリティには、キャンパス モビリティと同じタイプの操作や機能(物理的なハードウェアの移動、WLAN ローミング、Cisco エクステンション モビリティ)が含まれますが、それらは企業内のそれぞれのサイトに複製されます。さらに、デバイス モビリティ機能を利用して、ユーザがサイト間でデバイスを移動させると、電話のコールがローカル サイトの出力ゲートウェイを介してルーティングされ、メディア コーデックが適切にネゴシエートされ、コール アドミッション制御メカニズムでデバイスの場所が認識されるようにできます。

リモート サイト モビリティ

このタイプのモビリティでは、ユーザは社外のロケーションに移動しても、仮想的に企業ネットワークをリモート ロケーションまで拡張して、何らかの安全な形式で会社に接続できます。このタイプのモビリティには、一般に、Cisco Virtual Office などのリモート テレワーカー ソリューションと、VPN ベースの電話機、オフィス アクセス ポイント機能、Cisco Video Communication Server Expressway(VCS Expressway)経由のリモート エンドポイント登録などのその他のリモート接続方法があります。

社外型モビリティは、大まかに次の 2 つの Cisco ソリューション セットに分けられます。

Cisco Unified Mobility

Cisco Unified Communications Manager(Unified CM)の一部である Cisco Unified Mobility 機能スイートにより、モバイル ユーザの会社の番号をユーザのモバイルまたはリモート デバイスに関連付け、企業ネットワーク上のユーザの固定の会社のデスクフォンと、モバイル ボイス プロバイダー ネットワーク上のユーザのモバイル デバイスとを接続できます。このタイプの機能は、フィックスド モバイル コンバージェンス と呼ばれることがあります。

シスコのモバイル クライアント ソリューション

シスコのモバイル クライアント アプリケーションは、デュアル モード スマート フォンおよび他のモバイル デバイスで実行され、エンタープライズ ボイスへのアクセス、およびコラボレーション アプリケーションとサービスを提供します。デュアルモードの電話機には、802.11 ワイヤレス LAN ネットワークと携帯電話音声およびデータ ネットワークの両方に接続できる二重無線アンテナが装備されています。モバイル デバイスに展開するシスコのモバイル クライアントによって、この電話機は Cisco Unified CM または場合によってはエンタープライズ ワイヤレス LAN 経由、あるいはパブリックまたはプライベートの Wi-Fi ホット スポットやモバイル データ ネットワークを介したインターネット経由で Cisco Video Communication Server(VCS)に登録され、次に IP を介した音声コールとビデオ コールの送受信用のエンタープライズ IP テレフォニー インフラストラクチャを利用できます。デュアル モード電話機では、モバイル ユーザが企業の WLAN に関連付けられていない場合、またはこれらのデバイスを持つ企業ネットワークに安全に接続されていない場合、電話のコールはモバイル ボイス プロバイダー ネットワークを使用して行われます。モバイル デバイスの音声サービスとビデオ サービスをイネーブルにするだけでなく、シスコのモバイル クライアントでは、音声とインスタント メッセージング、プレゼンス、会社の電話番号へのアクセスなどの他のコラボレーション サービスへのアクセスも提供されます。

特に断りがない限り、この章で説明するさまざまなアプリケーションと機能は、すべての Cisco Unified Communications 配置モデルに適用されます。

この章ではまず、モビリティ機能と企業インフラストラクチャ内で利用可能なソリューションについて説明します。これには、キャンパス/単一サイトの配置、マルチサイトの配置、さらにはリモート サイトの配置での、機能検証や設計上の考慮事項が含まれます。この一連の包括ソリューションは、エンタープライズクラスのコミュニケーションや物理ロケーションに関係しない生産性の改善などを含め、社内のモバイル ワーカーに多くの利点をもたらします。この社内型モビリティに関する説明を踏まえて、モバイル プロバイダーおよびインターネット プロバイダーのインフラストラクチャおよび機能を活用した、社外型モビリティ ソリューションを検証します。これらのソリューションにより、安定した企業モビリティ インフラストラクチャの上に、高度なモバイル機能とコミュニケーション フローを活用するための企業ネットワーク インフラストラクチャとプロバイダー ネットワーク インフラストラクチャのモバイル機能のブリッジングが可能になります。

この章では、企業用のコラボレーション モビリティ ソリューションのモビリティ アーキテクチャ、機能性、および設計と配置の示す意味について包括的に検証します。この章の分析と説明は、大まかに次のような構成になっています。

社内型モビリティ

「キャンパス企業モビリティ」

「マルチサイト企業モビリティ」

「リモート企業モビリティ」

社外型モビリティ

「Cisco Unified Mobility」

「シスコの Cisco Mobile クライアントおよびデバイス」

この章の新規情報

表 23-1 に、この章に新しく追加されたトピック、またはこのマニュアルの以前のリリースから大幅に改訂されたトピックの一覧を示します。

表 23-1 新規情報、またはこのマニュアルの以前のリリースからの変更情報

新規トピックまたは改訂されたトピック
説明箇所
改訂日

Cisco VCS Expressway とのリモート セキュア企業接続

「エンタープライズ エッジの安全なリモート接続」

2013 年 4 月 2 日

Cisco VCS FindMe

「Cisco TelePresence FindMe」

2013 年 4 月 2 日

アーキテクチャや機能性などの、Dial via Office 機能

「Dial Via Office」

「Cisco Jabber Dial Via Office」

2013 年 4 月 2 日

WebEx や VCS などクラウドベースのコラボレーション サービスとインフラストラクチャ

「クラウドベースまたはオフプレミスのコラボレーション インフラストラクチャ」

2013 年 4 月 2 日

Cisco WebEx Meeting Center クライアント

「シスコの Cisco Mobile クライアントおよびデバイス」

2013 年 4 月 2 日

Cisco Cius に関して削除された情報

「シスコの Cisco Mobile クライアントおよびデバイス」

2013 年 4 月 2 日

ローカル ルート グループでのデバイス モビリティのダイヤル プランのガイドライン、および回線/デバイス アプローチの制限

「ダイヤル プランの設計に関する考慮事項」

2012 年 9 月 28 日

リモート接続先の番号の設定と発信者 ID の照合に関するガイドラインと動作

「リモート接続先の設定と発信者 ID の照合」

2012 年 9 月 28 日

標準ローカル ルート グループとローカル ルート グループに関する Cisco Unified Mobility ダイヤル プランのガイドライン

「Cisco Unified Mobility のダイヤル プランに関する考慮事項」

2012 年 9 月 28 日

ビデオ機能とクラウドベースの統合など、シスコのモバイル クライアントおよびデバイスのアーキテクチャ、

「シスコのモバイル クライアントおよびデバイスのアーキテクチャ」

2012 年 9 月 28 日

Cisco Jabber for iPad モバイル クライアント

「Cisco Jabber for iPad」

2012 年 9 月 28 日

QoS および Bring Your Own Device(BYOD)に関する考慮事項を含む Cisco Jabber モバイル クライアント

「モバイル クライアントとデバイスの Quality of Service」

「Cisco Bring Your Own Device(BYOD)インフラストラクチャ」

2012 年 9 月 28 日

WLAN チャネル セルあたりのビデオ コールに関連する容量に関するキャパシティ情報

「キャンパス企業モビリティのキャパシティ プランニング」

2012 年 9 月 28 日

詳細なキャパシティ プランニング情報は、「 Unified Communications の設計および配置サイジングに関する考慮事項 」の章に移されました。

「コラボレーション ソリューションの設計および配置サイジングに関する考慮事項」

2012 年 6 月 28 日

拡張シングル企業ボイス メール ボックス(モバイル ボイス メール回避機能):モバイル ボイス メールが接続されないようにするための DTMF ベースのユーザ応答の追加

「シングル企業ボイスメール ボックスによるモバイル ボイスメール回避」

2012 年 6 月 28 日

Intelligent Session Control 機能を拡張するすべてのシェアド ライン呼び出し

「Intelligent Session Control およびすべてのシェアド ライン呼び出し」

2012 年 6 月 28 日

Nokia Call Connect、Cisco Unified Mobile Communicator、および Cisco Mobile 8.5 for Nokia は販売終了(EoS)となり、この章では説明しません

この章から、いくつかの章が削除

2012 年 6 月 28 日

社内型モビリティ

この項では、社内で使用可能なモビリティ機能およびソリューションについて検証します。この検証には、次のタイプの企業モビリティのアーキテクチャ、機能性、および設計と配置の意味に関する説明が含まれます。

「キャンパス企業モビリティ」

「マルチサイト企業モビリティ」

「リモート企業モビリティ」

キャンパス企業モビリティ

キャンパスまたは単一サイトの企業モビリティは、一般に単一の IP アドレス空間および PSTN 入出力境界により区切られた単一の物理ロケーション内のモビリティを指します。ここでのモビリティには、この物理ロケーション内でのユーザの移動だけではなく、エンドポイント デバイスの移動も含まれます。

キャンパス企業モビリティのアーキテクチャ

図 23-1 に示すように、キャンパス企業モビリティのアーキテクチャは、(図のように)近接する単一の建物または複数の建物を含む単一の物理ロケーションに基づいており、ユーザはキャンパス内を自由に移動でき、IP および PSTN 接続を維持できます。一般にキャンパス配置には、アドレス空間および PSTN 入出力境界によって区切られた PSTN およびインターネット プロバイダー ネットワークへの、単一 IP 共有一般接続または接続セットが含まれます。この企業キャンパス内のすべてのユーザは、一般ネットワーク インフラストラクチャに接続され、一般ネットワーク インフラストラクチャから到達可能です。

図 23-1 キャンパス企業モビリティのアーキテクチャ

 

キャンパス モビリティのタイプ

企業キャンパス内のモビリティには一般的に、デバイス、ユーザ、またはその両方のキャンパス インフラストラクチャ全体の移動が含まれます。Cisco Collaboration 展開内のキャンパス企業モビリティは主に、有線電話機の物理的な移動、ワイヤレス デバイスの移動、電話機や通話ソフトウェアを持たないユーザのみの移動の 3 つに分けられます。移動のタイプについては後で説明します。

物理的な有線デバイスの移動

図 23-1 に示すように、物理的な有線電話機の移動は、キャンパス インフラストラクチャ内で簡単に行えます。このタイプの電話機の移動は、建物の単一階内、建物の複数階にわたって、またはキャンパス内の建物間で発生することが考えられます。従来の、物理的な電話機のポートが特定のオフィス、パーティション、または建物内のその他の空間に固定されている PBX 配置とは異なり、IP テレフォニーの配置では、電話はネットワーク インフラストラクチャの任意の IP ポートにつないで IP PBX に接続できます。

Cisco 環境では、これは単に Cisco Unified IP Phone または Cisco TelePresence System エンドポイントをネットワークから取り外し、キャンパス内の他の場所に運んで他の有線ネットワーク ポートに接続するだけということです。新しいネットワーク ロケーションに接続すると、この電話が適切な呼制御(Unified CM または VCS)に再登録され、前のロケーションと同じように発信や着信ができます。

物理デバイスのこれと同じ移動は、有線 PC で実行するソフトウェアベースの電話にも適用されます。たとえば、Cisco IP Communicator または Cisco Jabber を実行しているラップトップ コンピュータを、キャンパス内のあるロケーションから別のロケーションへ移動でき、ラップトップを新しいロケーションのネットワーク ポートに接続すると、ソフトウェアベースの電話を Cisco 呼制御に再登録して、電話の呼処理を再開できます。

キャンパス内の物理的なデバイス モビリティに対応するには、電話デバイスやソフトウェアベースの電話を実行しているコンピュータを物理的に移動する際は、新しいロケーションで使用されるネットワーク接続の IP 接続、接続速度、Quality of Service、セキュリティ、およびインライン パワーや動的ホスト制御プロトコル(DHCP)などのネットワーク サービスが前の場所のものと同じであるよう注意してください。これらの接続パラメータ、サービス、および機能が同じでないと、機能が低下し、場合によっては、機能が完全に失われます。

ワイヤレス デバイスのローミング

キャンパス エッジでワイヤレス ネットワークに接続できるようワイヤレス LAN ネットワークが展開されている場合、ワイヤレス デバイスは、図 23-1 で示すように、企業キャンパス全体を移動またはローミングできます。

ワイヤレス デバイスの例には、Cisco Unified Wireless IP Phone 7925G、無線で接続された Cisco Unified IP Phone 9971、および Cisco Jabber などのシスコのモバイル クライアントが含まれます(「シスコの Cisco Mobile クライアントおよびデバイス」を参照)。

WLAN ネットワークは、1 箇所以上のワイヤレス アクセス ポイント(AP)から構成されます。ワイヤレス AP は、ワイヤレス デバイスに対してワイヤレス ネットワーク接続を提供します。ワイヤレス AP は、ワイヤレス ネットワークと有線ネットワークとの間の境界ポイントとなります。ネットワークのカバー領域および容量を拡張するために、物理的なネットワーク敷設領域に複数の AP が分散して配置されます。

ワイヤレス デバイスおよびワイヤレス クライアントは、基礎となる WLAN インフラストラクチャに依存して重要なシグナリングとリアルタイムの音声とビデオのメディア トラフィックの両方を伝送するため、データ トラフィックとリアルタイム音声トラフィックの両方に最適化された WLAN ネットワークの配置が必要になります。WLAN ネットワークの配置が適切でないと、多くの干渉が発生し、容量が低下するため、音声とビデオの品質が低下するだけでなく、コールがドロップされたり、つながらなかったりする可能性もあります。このように展開された WLAN は、音声コールの発信および受信に使用できなくなります。したがって、ワイヤレス電話機とクライアントを配置する場合は、Voice and Video over WLAN(VVoWLAN)の配置が正常に行われるように、配置前、配置中、配置後に WLAN 無線周波数(RF)サイト サーベイを実施して、適切なセル境界、設定、機能設定、容量、および冗長性を判断する必要があります。

AP は、ネットワーク内に自律的に配置して、各 AP が他のすべての AP とは独立して設定、管理、および運用されるようにすることも、WLAN コントローラによってすべての AP が設定、管理、および制御されるように管理モードで配置することもできます。後者のモードにおいて、WLAN コントローラは、AP の管理、および AP 設定と AP 間ローミングの処理を担当します。いずれの場合も、VVoWLAN が正常に配置されるには、次の一般的なガイドラインに従って AP を配置する必要があります。

図 23-2 に示すように、隣接していない WLAN AP チャネル セルは、20 % 以上オーバーラップする必要があります。このようにオーバーラップさせることによって、ワイヤレス デバイスがキャンパス ロケーション内で移動した場合に AP 間で正常にローミングして、ボイス ネットワーク接続およびデータ ネットワーク接続を維持できます。2 つの AP 間で正常にローミングしたデバイスは、音声品質や音声パスに目立った変更なしにアクティブな音声コールを維持できます。

図 23-2 WLAN チャネル セル オーバーラップ

 

図 23-3 に示すように、WLAN AP チャネル セルは、-67 デシベル/ミリワット(dBm)のセル パワーレベル境界(またはチャネル セル半径)で配置する必要があります。また、同一チャネルのセル境界の分離は、約 19 dBm にする必要があります。

約 -67 dBm(またはそれ未満)のセル半径にすることで、リアルタイムの音声とビデオのトラフィックで問題となるパケット損失を最小限に抑えることができます。19 dBm の同一チャネル セル分離は、AP またはクライアントにおいて、同じチャネルに関連付けられている他のデバイスとの同一チャネル干渉が発生しないようにするために重要です。同一チャネル干渉が発生すると、音声品質が低下するためです。セル半径についての -67 dBm のガイドラインは、2.4 GHz(802.11b/g)と 5 GHz(802.11a)の両方の配置に該当します。

図 23-3 WLAN セル半径および同一チャネル セル分離

 


) 19 dBm の同一チャネル セル分離は、単純化されたものであり、理想的な状態を示しています。ほとんどの配置においては、このような 19 dBm の分離を実現することができません。最も重要な RF 設計基準は、-67 dBm のセル半径と、セル間の 20 % 以上の推奨オーバーラップです。これらの制約を遵守して設計することによって、チャネルの分離が最適化されます。


無線ローミングは無線電話だけではなく、PC で実行するソフトウェアベースの電話にも適用されます。たとえば、ユーザは Cisco IP Communicator または Cisco Jabber を実行しているラップトップ コンピュータを使用して、キャンパス中を無線でローミングできます。

ほとんどのワイヤレス AP、無線電話、および無線 PC クライアントでは、企業の WLAN に安全にアクセスできるように、さまざまなセキュリティ オプションが用意されています。WLAN インフラストラクチャとワイヤレス デバイスの両方でサポートされており、企業のセキュリティ ポリシーおよびセキュリティ要件に一致するセキュリティの方法を必ず選択してください。

Cisco Unified Wireless Network のインフラストラクチャの詳細については、「ワイヤレス LAN インフラストラクチャ」を参照してください。Voice over WLAN 設計の詳細については、次の Web サイトで入手可能な『 Voice over Wireless LAN Design Guide 』を参照してください。

http://www.cisco.com/en/US/solutions/ns340/ns414/ns742/ns820/landing_voice_wireless.html

エクステンション モビリティ(EM)

図 23-1 に示すように、有線およびワイヤレス電話機の物理的な移動に加え、ユーザ自身も電話機または PC ハードウェアを持たずにキャンパス インフラストラクチャ内を移動できます。これらの場合、ユーザの会社の電話番号および他の設定を含むプロファイルを適用することにより、ユーザは 1 つのデバイスから別のデバイスに、会社の内線番号または会社の番号を移動できます。

EM 機能により、ユーザはセキュリティ クレデンシャル(ユーザ ID および PIN 番号)のセットを使用して、キャンパス内にある IP フォンにログインできます。ログインすると、会社の電話番号やコール特権から設定したスピード ダイヤルまでを含めたユーザ個人のデバイス プロファイルが、ユーザがデバイスをログアウトするまで、またはログインのタイムアウトまで、一時的にこの電話に適用されます。EM 機能は、Unified CM の一部として使用できます。

この機能は、会社の外でほとんどの時間を費やし、物理的に、オフィスには時々しかいないモバイル企業ユーザに特に役に立ちます。ホット シーティングまたはフリー シーティングと呼ばれることもあるこれらのタイプのモバイル ユーザに、一時的にオフィスのスペースを提供することで、システム管理者は頻度が低く一時的にしか IP フォンハードウェアを使用する必要がない多数のモバイル ユーザに対応できます。

キャンパス内で EM を利用するには、Unified CM 管理者がユーザ デバイス プロファイルおよびユーザ クレデンシャルを設定し、EM 電話サービスへ IP フォンを登録する必要があります。


) EM は Unified CM 呼制御によってのみ、EM 対応エンドポイント デバイスだけでサポートされます。Cisco TelePresence System エンドポイントは EM をサポートしていません。


EM の詳細については、「エクステンション モビリティ」を参照してください。

キャンパス企業モビリティのハイ アベイラビリティ

キャンパス企業モビリティ機能およびソリューションは、モビリティ機能のハイ アベイラビリティを保証するよう、冗長な方式で設定し配置する必要があります。

たとえば、有線の IP フォンおよびソフトウェアベースの IP フォンを実行しているコンピュータを効率的にサポートするため、冗長で普及しているネットワーク接続またはポートが使用可能である必要があります。さらに、これらの冗長なネットワーク接続は、適切なセキュリティ、Quality of Service、およびその他のネットワークベースの機能などの、有線デバイスのロケーションを移動しても最適な操作とボイス品質を確保できる適切な特性を備えたまま配置される必要があります。最終的には、正常なキャンパス モビリティの配置は、ネットワーク接続、PSTN 接続、およびその他のアプリケーションやサービスが、ハイ アベイラビリティのある方式で配置されている場合にのみ可能です。

同様に、ワイヤレス デバイスを接続およびローミングするための WLAN ネットワークの配置や調整では、無線サービスに対するハイ アベイラビリティを考慮することも重要です。配置するデバイス数に対する弾力性と十分なカバレッジを確保するために、WAN ネットワークは、同一チャネル セルがオーバーラップすることなく、適切で冗長なセルによるカバレッジが保証されるように配置する必要があります。同一チャネル セルがオーバーラップしない十分なセル カバレッジ、および AP 間のローミングを容易に実行可能にするための異なるチャネル セルの十分なオーバーラップを提供することによって、ワイヤレス デバイスおよびクライアントに対するネットワーク接続でハイ アベイラビリティを確保できます。

最後に、EM をキャンパス内のユーザ モビリティに利用する場合、Unified CM クラスタ内の単一ノードの障害が Extension Mobility 機能の動作を妨げないよう、この機能を冗長な方式で配置する必要があります。可用性が高くなるような Cisco Extension Mobility の詳細については、「エクステンション モビリティのハイ アベイラビリティ」を参照してください。

キャンパス企業モビリティのキャパシティ プランニング

キャンパス企業モビリティを正常に配置するには、これらのモビリティ機能とソリューションを使用するすべてのモバイル ユーザに対応できる十分なキャパシティを用意する必要があります。

有線デバイスおよびコンピュータの物理的な移動に対するキャパシティの考慮は、キャンパス ネットワーク インフラストラクチャ内で使用できるネットワーク ポート数に完全に依存しています。キャンパス内でデバイスを移動するユーザのため、それぞれのロケーションに、モバイル ユーザのデバイスの接続に使用できるある程度の数の使用可能なネットワークポートがある必要があります。ネットワークポートが不足してこの有線デバイスの移動に対応できないと、1 つのロケーションから別のロケーションへ物理的にデバイスを移動できないことになる可能性があります。

企業 WLAN 内にワイヤレス デバイスを配置し、ワイヤレス デバイス ローミングを利用する場合、WLAN インフラストラクチャのデバイスの接続性とコール キャパシティを考慮することも重要です。デバイス数またはアクティブ コール数の面でのキャンパス WLAN インフラストラクチャのオーバーサブスクリプションは、無線接続のドロップ、音声とビデオの品質の低下、またはコール セットアップの遅延や失敗の原因となります。Voice and Video over WLAN(VVoWLAN)の配置をオーバーサブスクライブする可能性は、必要なコール キャパシティを処理するために十分な数の AP を配置することで、著しく最小限に抑えられます。AP のコール キャパシティは、単一チャネル セル領域内でサポートできる音声またはビデオの同時双方向ストリームの数に基づきます。VVoWLAN のコール キャパシティの一般的なルールは次のとおりです。

データ レート 24 Mbps 以上の Bluetooth を無効にした 802.11g/n(2.4 GHz)チャネル セルあたり最大 27 個の同時 Voice over WLAN(VoWLAN)双方向ストリーム。

データ レート 24 Mbps 以上の 802.11a/n(5 GHz)チャネル セルあたり最大 27 個の同時 VoWLAN 双方向ストリーム。

720p のビデオ解像度(高解像度)および最大 1 Mbps のビデオ ビット レート、最大 Bluetooth が無効の 802.11 g/n(2.4 GHz)あたり、または 802.11 a/n(5 GHz)チャネル セルあたり最大 8 の VVoWLAN 同時双方向のストリームを前提としています。

これらの音声およびビデオ コール キャパシティ値は、RF 環境、設定またはサポートされているビデオ解像度とビット レート、ワイヤレス エンドポイントとその固有の機能、および基礎となる WLAN システム機能に大きく依存します。一部の配置では、実際のキャパシティはこれよりも小さくなることもあります。


) 同じ AP に関連付けられている 2 台のワイヤレス エンドポイント間の単一のコールは、2 つの同時双方向ストリームであると見なされます。


EM のスケーラビリティは、Unified CM 内のログイン率およびログアウト率にほぼ依存します。十分な EM ログイン/ログアウト キャパシティがモバイル ユーザに提供できるよう、Unified CM クラスタ内で有効なエクステンション モビリティ ユーザ数と、キャンパス内を移動するユーザ数、任意の時間にこの機能を使用しているユーザ数を知ることが重要です。EM のキャパシティ プランニングの詳細については、「コラボレーション ソリューションの設計および配置サイジングに関する考慮事項」の章を参照してください。

いずれの場合も、キャンパス内の Unified CM クラスタまたは VCS クラスタ、あるいはこの両方のクラスタには、有線デバイスかワイヤレス デバイスにかかわらず、移動されたデバイスに対するデバイス登録を処理する十分なデバイス登録キャパシティが必要です。もちろん、キャンパス全体を移動しているすべてのデバイスが、すでにキャンパス ネットワーク内に配置されている場合、呼制御プラットフォーム内の十分なキャパシティが、デバイスの移動の前にすでに配置されている必要があります。ただし、新しいデバイスをモビリティを目的として配置に追加する場合は、デバイス登録キャパシティを考慮する必要があり、必要に応じてさらにキャパシティを追加する必要があります。

最後に、Unified CM および VCS によって提供される多くの機能により、これらのモビリティ ソリューションの設定および配置はシステム全体のサイジングと関わっています。実際のシステム キャパシティの決定は、エンドポイント デバイスや EM ユーザの数、配置されている CTI アプリケーションの数に対する最繁時呼数(BHCA)レートなどの考慮事項に基づきます。一般的なシステム サイジング、キャパシティ プランニング、および配置上の考慮事項の詳細については、「コラボレーション ソリューションの設計および配置サイジングに関する考慮事項」の章を参照してください。

キャンパス企業モビリティの設計上の考慮事項

キャンパス企業モビリティ機能を配置する際は、次の設計上の考慮事項に従ってください。

キャンパス内の物理的なデバイス モビリティに対応するには、新しいロケーションで使用されるネットワーク接続の IP 接続(VLAN や VLAN 間ルーティングなど)、接続速度、Quality of Service、セキュリティ、およびネットワーク サービス(インライン パワー、動的ホスト制御プロトコル(DHCP)など)が前のネットワーク接続と同じタイプであることを確認してください。これらの接続パラメータ、サービス、および機能が同じでないと、機能が低下するか、場合によっては機能が完全に失われます。

ワイヤレス IP デバイスやソフトウェアベース クライアントを展開する場合は、Voice over WLAN(VoWLAN)の展開が正常に行われるように、展開前、展開中、展開後に WLAN 無線周波数(RF)サイト サーベイを実施して、適切なセル境界、設定、機能設定、容量、および冗長性を判断する必要があります。

AP は、20 % 以上のセル オーバーラップを確保して配置する必要があります。このようにオーバーラップさせることによって、デュアルモード デバイスがロケーション内で移動した場合に AP 間で正常にローミングして、ボイス ネットワーク接続およびデータ ネットワーク接続を維持できます。

パケット損失を最小限に抑えるために、AP は -67 dBm のセル パワー レベル境界(またはチャネル セル半径)で配置する必要があります。また、同一チャネルのセル境界の分離は、約 19 dBm にする必要があります。19 dBm の同一チャネル セル分離は、AP またはクライアントにおいて、同じチャネルに関連付けられている他のデバイスとの同一チャネル干渉が発生しないようにするために重要です。同一チャネル干渉が発生すると、音声とビデオの品質が低下するためです。

単一の Unified CM ノードが失われた場合に機能の実行に悪影響が及ばないように、EM サービスは冗長性の高い方式で配置してください。EM サービスが重要な場合、Unified CM ノード障害を回避し可用性が高い機能を提供するためのサーバ ロード バランシング ソリューションを考えます。EM のハイ アベイラビリティの詳細については、「エクステンション モビリティのハイ アベイラビリティ」を参照してください。

キャンパス ネットワークのワイヤレスの音声とビデオコールのキャパシティは十分に用意してください。そのためには、無線ユーザの BHCA レートに基づき、目的のコール キャパシティの処理に適した数のワイヤレス AP を展開します。各 802.11g/n(2.4 GHz)または 802.11a/n(5 GHz)チャネル セルは、24 Mbps 以上のデータ レートで 27 の同時音声のみのコールをサポートできます。各 802.11g/n(2.4 GHz)または 802.11a/n(5 GHz)チャネル セルは、最大 1 Mbps ビット レートで 720p ビデオ解像度であるとすると、最大 8 の同時ビデオ コールをサポートできます。2.4 GHz WLAN 配置では、このキャパシティを実現するには Bluetooth を無効にする必要があります。実際のコール キャパシティは、RF 環境、ワイヤレス エンドポイント タイプおよび WLAN インフラストラクチャによって、さらに小さくなることがあります。

マルチサイト企業モビリティ

マルチサイト企業モビリティとは、複数の物理ロケーションがあり、それぞれが一意の IP アドレス空間および PSTN 入出力境界を持つ社内でのモビリティを指します。この場合のモビリティには、ユーザやエンドポイント デバイスの各物理ロケーション内の移動だけではなく、サイトおよびロケーション間のユーザやエンドポイント デバイスの移動も含まれます。

マルチサイト企業モビリティのアーキテクチャ

図 23-4 に示すように、マルチサイト企業モビリティのアーキテクチャは、地理的に離れた 2 つ以上のロケーションまたはサイトに基づいています。ユーザとデバイスの数が多い中央またはキャンパス サイトから、ユーザとデバイスの数が少なめの中規模の地域サイト、それよりも小規模な支社サイトまで、サイトの規模は異なってもかまいません。一般にマルチサイト企業配置は、サイトを相互接続する IP WAN リンクや、各ロケーションでのローカル PSTN 入出力で構成されています。さらに多くの場合、サイト間のネットワーク障害中でも機能を維持するため、重要なサービスはそれぞれの物理サイトに複製されています。モビリティの観点からは、ユーザとそのデバイスはサイト内またはサイト間で移動できます。

図 23-4 マルチサイト企業モビリティのアーキテクチャ

 


図 23-4 では、集中呼処理を使用するマルチサイト配置(中央サイト内にある単一 Unified CM または VCS クラスタから明らか)を示していますが、マルチサイト企業モビリティの配置と同じ設計および配置の考慮が、分散型呼処理環境に適用されます。分散型呼処理環境で配置された場合のモビリティ機能の動作の違いについて、以降で説明します。


マルチサイト企業モビリティのタイプ

マルチサイト企業モビリティ配置には、デバイス、ユーザ、またはその両方の単一サイト内での移動だけではなく、サイト間のユーザおよびデバイスの移動も含まれます。

キャンパス/単一サイト企業配置でサポートされているタイプと同じモビリティ機能とソリューションが、マルチサイト配置の単一サイト内でのユーザやデバイスのサイト内移動に適用されます。これらには、有線電話機の物理的な移動、無線電話ローミング、およびエクステンション モビリティが含まれます。これらのタイプのモビリティソリューションおよび機能の詳細については、「キャンパス企業モビリティ」を参照してください。

マルチサイト配置でのサイト内モビリティでも、これらのモビリティ機能が同じようにサポートされます。ただし、2 つ以上のサイト間に適用される場合の機能との主な違いとして、これらの機能はデバイス モビリティ機能により拡張されます。デバイス モビリティ機能では、企業ネットワークに接続するときにデバイスが使用する IP アドレスを基にしたダイナミックなロケーション認識メカニズムが提供されます。

物理的な有線デバイスの移動

物理的な有線電話機の移動は、マルチサイト配置の各サイト内でも、サイト間でも簡単に対応できます。キャンパス/単一サイト配置と同様、マルチサイト配置の単一サイトに制限された有線デバイスの移動は、Cisco エンドポイントをネットワークから外し、サイト内の別のロケーションに移動して、別の有線ネットワーク ポートに接続するだけです。新しいネットワーク ロケーションに接続すると、この電話が呼制御プラットフォームに再登録され、前のロケーションと同じように発信や着信ができます。

マルチサイト配置でのサイト間またはロケーション間の有線デバイスの移動も、基本的には同じ形です。ただし、このタイプのモビリティと組み合わせた場合、デバイス モビリティ機能により、デバイスが移動先の新しいロケーションで再登録されると、適切にコール アドミッション制御が動作し、ゲートウェイおよびコーデックが選択されます。この機能の詳細については、「デバイス モビリティ」を参照してください。

ワイヤレス デバイスのローミング

各サイトで使用できる、ワイヤレス ネットワークに接続するためのワイヤレス LAN ネットワーク インフラストラクチャが使用可能な場合、単一サイトのキャンパス展開と同様、ワイヤレス デバイスは、図 23-4 に示すように、マルチサイト企業展開全体を移動またはローミングできます。しかし、サイト間の有線電話機の移動と同様ワイヤレス デバイスでも、コールの発着信の際に正しいゲートウェイおよびコーデックが確実に使用されるよう、またコール アドミッション制御が帯域幅を適切に管理するよう、デバイス モビリティ機能が展開されなければなりません。この機能の詳細については、「デバイス モビリティ」を参照してください。

分散型呼処理環境では、有線電話機と同様に、コール ルーティングによる潜在的な問題を回避するため、単一の呼処理プラットフォームまたはクラスタだけにワイヤレス デバイスを登録するように設定する必要があります。

エクステンション モビリティ(EM)

単一サイト内での EM のサポートに加え、図 23-4 に示すように、この機能はサイト間でもサポートされ、ユーザが企業内のサイト間を移動して、各ロケーションで電話機にログインできます。

また、ユーザが異なる Unified CM クラスタのサイト間や電話間を移動する場合、EM も分散型呼処理の配置でサポートされます。分散型呼処理環境でエクステンション モビリティをサポートするには、Cisco クラスタ間のエクステンション モビリティ(EMCC)機能を設定する必要があります。この機能の詳細については、「クラスタ間のエクステンション モビリティ(EMCC)」を参照してください。


) EM と EMCC は、Unified CM 呼制御によってのみ、EM 対応エンドポイント デバイスだけでサポートされます。Cisco TelePresence System エンドポイントは EM または EMCC をサポートしていません。


デバイス モビリティ

Cisco Unified Communications Manager(Unified CM)では、ロケーション、リージョン、コーリング サーチ スペース、メディア リソースなど、さまざまな設定を使用して、サイト、つまり物理ロケーションが識別されます。特定のサイトにある Cisco Unified IP Phone は、これらの設定により静的に設定されます。Unified CM では、適切なコールの確立、コール ルーティング、メディア リソースの選択などのためにこれらの設定を使用します。一方、Cisco Unified Wireless IP Phone などのデュアルモード電話機やその他のモバイル クライアント デバイスがそれらのホーム サイトからリモート サイトに移動されたときに、それらのデュアルモード電話機では電話機に静的に設定されているホーム設定を保持しています。この結果 Unified CM では、リモート サイトの電話機にあるこれらのホーム設定を使用します。この状況は、コール ルーティング、コーデックの選択、メディア リソースの選択、およびその他の呼処理機能における問題の原因となる場合があるため望ましくありません。

Cisco Unified CM では、デバイス モビリティという機能を使用します。この機能により、Unified CM では、IP フォンがホーム ロケーションにあるのか、ローミング ロケーションにあるのかを判別できます。Unified CM では、デバイスの IP サブネットを使用して、その IP フォンの正確な場所を判別します。クラスタ内でのデバイス モビリティを使用できるようにすることで、モバイル ユーザは 1 つのサイトから別のサイトにローミングでき、このときサイト固有の設定を取得します。次に、Unified CM では、これらの動的に割り当てられた設定を使用して、コール ルーティング、コーデックの選択、メディア リソースの選択などを行います。

この項では、最初にデバイス モビリティ機能の主要な目的について説明し、続いてデバイス モビリティ機能そのものについて詳細に説明します。ここでは、デバイス モビリティ機能のさまざまなコンポーネントおよび構成要素について取り上げます。また、この項では、デバイス モビリティ機能が企業ダイヤル プランに与える影響を、さまざまなダイヤル プラン モデルの意味も含めて詳細に説明します。


) デバイス モビリティは Unified CM 呼制御だけでサポートされます。


デバイス モビリティの必要性

この項では、Unified CM クラスタに多くのモバイル ユーザが含まれている場合のデバイス モビリティの必要性について説明します。

図 23-5 は、本社サイト(HQ)にあり、デバイス モビリティ機能を備えない Unified CM クラスタを含んでいる架空のネットワークを示しています。このクラスタには、支社 1 と支社 2 の 2 つのリモート サイトがあります。サイト内コールでは、いずれも G.711 音声コーデックが使用されます。一方サイト間コール(IP WAN を経由するコール)では、いずれも G.729 音声コーデックが使用されます。各サイトには、外部コールのための PSTN ゲートウェイがあります。

図 23-5 リモート サイトを 2 つ持つネットワークの例

 

支社 1 のユーザが支社 2 に移動し、デンバーにいる PSTN ユーザに通話すると、次のような動作が発生します。

Unified CM では、そのユーザが支社 1 から支社 2 に移動したことを認識していません。PSTN への外部コールが WAN を経由して支社 1 のゲートウェイに送られ、そこから PSTN に出ます。これにより、モバイル ユーザの PSTN コールすべてに、引き続きそのユーザのホーム ゲートウェイが使用されます。

このモバイル ユーザと支社 1 ゲートウェイは、同じ Unified CM リージョンおよびロケーションに存在しています。ロケーション ベースのコール アドミッション制御は、異なるロケーションに存在しているデバイスおよび G.711 音声コーデックを使用するリージョン内コールにだけ適用可能です。したがって、IP WAN を経由する支社 1 ゲートウェイへのコールでは G.711 コーデックが使用され、コール アドミッション制御のための Unified CM によるトラッキングは行われません。この動作の結果、リモート リンクすべてが低速リンクである場合に、IP WAN 帯域幅のオーバー サブスクリプションが発生する場合があります。

モバイル ユーザが、複数の支社 2 ユーザを Denver にいる PSTN ユーザとの既存のコールに追加することで、会議を作成します。モバイル ユーザは支社 1 ゲートウェイの会議リソースを使用します。したがって、すべての会議ストリームが IP WAN 経由で流れます。


) デバイス モビリティは、クラスタ内機能で、複数の Unified CM クラスタには拡張されません。分散型呼処理環境では、配置内の各 Unified CM クラスタでデバイス モビリティを有効にし、設定する必要があります。



) デバイス モビリティを使用できない環境では、デバイス モビリティがサポートされていない Cisco VCS 呼制御配置またはデバイス モビリティが設定されていない Unified CM 呼制御配置のため、管理者はサイト ロケーション間に WAN 帯域幅を多めにプロビジョニングし、WAN 経由とサイト間のデバイスの物理的な移動で、WAN を多めにサブスクライブしないようにします。各 WAN リンクについて余分にプロビジョニングする帯域幅の量は、ユーザが 2 か所のロケーション間でデバイスを移動する際の予測レートによって異なります。


デバイス モビリティのアーキテクチャ

Unified CM デバイス モビリティ機能は、上記の問題を解決するために有用です。この項では、この機能の動作方法を簡単に説明します。ただし、この機能の詳細説明については、 http://www.cisco.com で入手可能な製品マニュアルを参照してください。

デバイス モビリティには次のような要素が含まれます。

デバイス モビリティ情報:IP サブネットを設定し、デバイス プールを IP サブネットに関連付けます。

デバイス モビリティ グループ:ダイヤリング パターンが類似しているサイトの論理グループを定義します(たとえば、図 23-6 の US_dmg および EUR_dmg)。

物理ロケーション:デバイス プールの物理ロケーションを定義します。言い換えると、この要素では、IP フォンおよびデバイス プールに関連付けられているその他のデバイスの地理的なロケーションを定義します (たとえば、図 23-6 に示されている San Jose の IP フォンは、すべて物理ロケーション SJ_phyloc を使用して定義されています)。

図 23-6 は、この 3 つの用語すべての関係を示します。

図 23-6 デバイス モビリティ コンポーネントの関係

 

Unified CM では、デバイスの IP サブネットに基づいてデバイス プールを IP フォンに割り当てます。次の手順は、図 23-7 に図示がありますが、この動作を説明したものです。

1. IP フォンでは、その電話の IP アドレスを Skinny Client Control Protocol(SCCP)または Session Initiation Protocol(SIP)登録メッセージに含めて送信することにより、Unified CM への登録を試行します。

2. Unified CM では、デバイスの IP サブネットを抽出し、デバイス モビリティ情報に設定されているサブネットと照合します。

3. サブネットが一致すると、Unified CM では、デバイス プール設定に基づいて、デバイスに新規設定を提供します。

図 23-7 電話登録プロセス

 

Unified CM では、デバイス プール設定にあるパラメータ一式を使用して、デバイス モビリティに対応します。これらのパラメータは、次の 2 つの主要なタイプについてのパラメータです。

「ローミングに依存する設定」

「デバイス モビリティ関連の設定」

ローミングに依存する設定

これらの設定にあるパラメータは、デバイスがデバイス モビリティ グループの内部または外部をローミングしているときに、デバイス レベルの設定より優先されます。この設定には、次のパラメータが含まれます。

日付/時刻グループ

リージョン

メディア リソース グループ リスト

ロケーション

ネットワーク ロケール

SRST リファレンス

物理ロケーション

デバイス モビリティ グループ

ローミングに依存する設定は、主に、適切なコール アドミッション制御および音声コーデックの選択を実施するために有用です。これは、ロケーションおよびリージョンの設定は、デバイスのローミング デバイス プールに基づいて使用されるためです。

さまざまなコール アドミッション制御手法については、「コール アドミッション制御」の章を参照してください。

ローミングに依存する設定により、メディア リソース グループ リスト(MRGL)も更新されて、保留音、会議、トランスコーディングなどで適切なリモート メディア リソースが使用されるようになり、これによりネットワークが効率的に使用されます。

ローミングに依存する設定により、Survivable Remote Site Telephony(SRST)ゲートウェイも更新されます。モバイル ユーザは、ローミング中に別の SRST ゲートウェイに登録します。この登録が、ローミング電話機が SRST モードであるときのダイヤリング動作に影響することがあります。

たとえば、ユーザが Unified CM への接続を失う新しいロケーションに電話機を移動した場合、ローミングに依存するデバイス モビリティ設定に基づいて、移動された電話機に対して新しい SRST リファレンスが設定されます。また、移動された電話機はローカルなローミング ロケーション SRST ルータの制御下に入ります。この場合、デバイスの DID が変更されず、ホーム ロケーションにアンカーされたままになるため、ユーザの電話機は PSTN や他のサイトから到達不能になるだけでなく、SRST 内で実装されている短縮ダイヤルを使用しなければ、ローカルな障害発生サイト内のデバイスから到達することも困難になる可能性があります。

たとえば、ユーザが電話機を San Jose のホーム ロケーション(ディレクトリ番号が 51234 で、関連付けられた DID が 408 555 1234)から New York のリモート ロケーションに移動したとします。また、ユーザが New York ロケーションにローミングして間もなく、New York のサイトと San Jose の間のリンクに障害が発生したとします。このシナリオでは、New York サイトにある電話機はすべて、そのサイト内の SRST ルータにフェールオーバーされます。また、ローミング電話機または移動された電話機は、その SRST リファレンスがデバイス モビリティのローミング依存設定に基づいて更新されたために、New York の SRST ルータに登録されます。このシナリオでは、New York のローカルなデバイスが Unified CM に登録するのと同じように、5 桁の内線番号とともに SRST ルータに登録されます。その結果、ローミング電話機のディレクトリ番号は 51234 のまま変わりません。他のすべてのサイトから、および PSTN からローミング電話機に到達するために、番号 408 555 1234 が、この特定の DID がアンカーされている San Jose の PSTN ゲートウェイにルーティングされます。New York サイトは San Jose サイトから切断されているため、このようなコールはいずれもユーザのデスクフォンには到達不能です。したがって、コールはユーザのボイスメール ボックスにルーティングされます。同様に、ローカルの障害発生サイト内のコールは、5 桁の短縮ダイヤルを使用して、または SRST ルータ内の dialplan-pattern コマンドおよび extension-length コマンドで定義されているように設定済みの番号をプレフィックスとして付加して、ダイヤルする必要があります。いずれの場合も、ローカル発信者が、短縮ダイヤルによりローカル ローミング デバイスに到達するために必要なダイヤリング動作を理解している必要があります。 ローカル ローミング電話機に到達するために、5 桁をダイヤルするだけでよいこともあれば、ユーザが特別な番号プレフィックスをダイヤルする必要があることもあります。同じロジックが、New York の移動された電話機またはローミング電話機からの発信ダイヤリングにも適用されます。短縮ダイヤルを使用してローカル内線番号に到達するためには、そのダイヤリング動作を変更する必要があるためです。ただし、ローカルなローミング デバイスから PSTN への発信ダイヤリングは、常に同じである必要があります。

デバイス モビリティ関連の設定

これらの設定にあるパラメータは、デバイスがデバイス モビリティ グループの内部をローミングしているときにだけ、デバイス レベルの設定より優先されます。この設定には、次のパラメータが含まれます。

デバイス モビリティ コーリング サーチ スペース

AAR コーリング サーチ スペース

AAR グループ

発信側変換 CSS

コーリング サーチ スペースは、ダイヤルできるパターンまたは到達できるデバイスを指示するため、デバイス モビリティ関連の設定は、ダイヤル プランに影響します。

デバイス モビリティ グループ

前述したように、デバイス モビリティ グループは、ダイヤリング パターンが類似したサイト(たとえば、同じ PSTN アクセス コードを持つサイトなど)の論理グループを定義します。このガイドラインを使用すると、すべてのサイトがサイト固有のコーリング サーチ スペースに類似したダイヤリング パターンを持ちます。ダイヤリング動作が異なるサイトは、異なるデバイス モビリティ グループに属します。図 23-6 に示すように、San Jose サイトと RTP サイトのデバイス モビリティ情報、デバイス プール、および物理ロケーションは異なります。ただし、必要なダイヤリング パターンと PSTN アクセス コードは 2 つのロケーション間で同じであるため、これらはすべて同じデバイス モビリティ グループ US_dmg に割り当てられています。一方、London サイトは別のデバイス モビリティ グループ EUR_dmg に割り当てられています。これは、必要なダイヤリング パターンと PSTN アクセス コードが US サイトのものとは異なるためです。デバイス モビリティ グループ内をローミングするユーザは、新規コーリング サーチ スペースを受け取った後であっても、ダイヤリング動作をリモート ロケーションで維持できます。デバイス モビリティ グループの外部をローミングするユーザは、自身のホーム コーリング サーチ スペースを使用するため、やはり、ダイヤリング動作をリモート ロケーションで維持できます。

ただし、デバイス モビリティ グループが、異なるダイヤリング パターンを持つ複数のサイトとともに定義されている場合(たとえば、あるサイトではユーザが外線使用時に 9 をダイヤルする必要があるが、別のサイトではユーザが外線使用時に 8 をダイヤルする必要がある場合)、そのデバイス モビリティ グループ内のユーザ ローミングにより、すべてのロケーションで同じダイヤリング動作を維持できいないことがあります。ユーザは、各ロケーションで新規コーリング サーチ スペースを受け取った後で、異なるロケーションにおいて異なる番号をダイヤルする必要がある場合があります。この動作はユーザの混乱を招く可能性があるため、異なるダイヤリング パターンを持つサイトを同じデバイス モビリティ グループに割り当てることは推奨しません。

デバイス モビリティの動作

デバイス モビリティ機能の動作を図 23-8 のフローチャートに示します。

図 23-8 デバイス モビリティ機能の動作

 

デバイス モビリティ機能には、次のガイドラインが適用されます。

図 23-8 にリストされている重複するパラメータがデバイスおよびデバイス プールで同じ設定を持つ場合は、デバイスではこれらのパラメータに NONE を設定できます。次にこれらのパラメータをデバイス プールに設定する必要があります。この方法を実施すると、デバイスにすべてのパラメータを個別に設定する必要がないため、設定の量を大幅に削減できます。

サイトごとに物理ロケーション 1 つを定義してください。1 つのサイトが複数のデバイス プールを持つことができます。

PSTN または外部/オフネット アクセスのダイヤリング パターンが類似したサイトを、同じデバイス モビリティ グループを使用して定義してください。

企業のポリシーに応じて、未定義のサブネットすべてに対応する、IP サブネット 0.0.0.0 の「catch-all」デバイス モビリティ情報を定義できます。このデバイス モビリティ情報は、ネットワーク リソースのアクセスまたは使用を制限できるデバイス プールを割り当てるために使用できます (たとえば、ローミング中にこのデバイス プールに関連付けられているデバイスからのコールすべてをブロックするコーリング サーチ スペース NONE を使用してデバイス プールを設定できます)。ただし、これを行う場合、管理者は、911 およびその他の緊急コールであってもブロックされるという事実を承知する必要があります。コーリング サーチ スペースは、911 またはその他の緊急コールだけにアクセスを許すパーティションを含めて設定できます。

ダイヤル プランの設計に関する考慮事項

デバイス モビリティ機能は、選択されたローミング デバイス プールの設定、またはエンドポイントが登録されている IP アドレスに基づいて、複数のデバイスおよびデバイス プール設定を使用します。サブネットのデバイス プールの設定によって更新される設定の詳細については、次の Web サイトで入手可能な『 Cisco Unified Communications Manager Features and Services Guide 』を参照してください

http://www.cisco.com/en/US/products/sw/voicesw/ps556/prod_maintenance_guides_list.html

ダイヤル プランから見ると、主に AAR グループ、AAR CSS、デバイス CSS、ローカル ルート グループ、および発信時の発呼側変換 CSS 設定は関連しています。

ローミング デバイスの出力ゲートウェイの選択

通常、ローミング デバイスの目的の出力ゲートウェイの選択動作は、訪問したサイトに対してローカルなゲートウェイを使用することです。発信側デバイスに固有の出力ゲートウェイの選択を実装するための推奨される方法は、標準ローカル ルート グループを使用するルート リストを指す PSTN ルート パターンを使用することです。ルート リストの標準ローカル ルート グループを効果的に使用することは、実際のコールをルーティングする際に標準ローカル ルート グループが発信側エンドポイントのデバイス プール内で設定されたローカル ルート グループと置き換えられることを意味します。このスキーマは、サイトが不特定のルート パターンとルート リストが使用できるようになります。サイト固有の出力ゲートウェイ接続は、デバイス プール レベルでローカル ルート グループの設定に完全に依存します。

ローミング デバイスでは(デバイス モビリティ グループ内またはデバイス モビリティ グループ間のローミング)、デバイス モビリティ機能は、ローミング デバイス プールのローカル ルート グループが標準ローカル ルート グループとして常に使用されるようになります。これは、ローカル ルート グループの出力ゲートウェイの選択で、訪問したサイトに固有のルート グループ(つまり、訪問したサイトに対してローカルなゲートウェイ)が通常使用されることを保証します。この動作は、たとえば、標準ローカル ルート グループのルート リストを使用するルート パターンによってルーティングされる緊急コールが、訪問したサイトに対してローカルな出力ゲートウェイを常に使用するようになります。

ローカル ルート グループの出力ゲートウェイの選択は、「ダイヤル プラン」の章で説明されているすべてのダイヤル プラン アプローチで使用できます。

ローミングしたエンドポイントが、特定のコールをホーム サイトのゲートウェイにルーティングする必要がある場合は、標準ローカル グループの代わりに固定されたサイト固有のルート グループを使用するルート リストを指すルート パターンを使用して実装される必要があります。

回線/デバイスのダイヤル プラン アプローチでは、これらのルート パターンはエンドポイントで設定されたデバイス CSS によってアドレス指定されます。ローミングし、かつ同一モビリティ グループを使用している場合には、発信側エンドポイントのデバイス CSS は、ローミング デバイス プールで設定されたデバイス モビリティ CSS に置き換えられます。固定された出力ゲートウェイの選択がいくつかのコールにおいて必要であり、これらのコールのルート パターンがデバイス CSS によってアドレス指定される場合、ローミング デバイスが常にデバイス モビリティ グループをまたがってローミングを行う必要があります。これは、ローミング エンドポイントが、エンドポイントで設定されたデバイス CSS を常に使用することを保証します。

「ダイヤル プラン」の章で説明されている +E.164 ダイヤル プラン アプローチを使用する場合、すべての PSTN ルート パターンは、ローミング デバイスに対して変更されてないか、更新されていない回線 CSS によってアクセスされます。このダイヤル プランでは、固定ゲートウェイ(たとえば、ローミング デバイスのホーム ロケーション)に特定の PSTN にある宛先を接続しているサイト固有のルート パターンは、デバイス モビリティ動作から影響を受けません。

ローカル ルート グループを持たない回線/デバイス アプローチを使用する、フラット アドレッシングの可変長のオンネット ダイヤリング

図 23-9 は、デバイス モビリティのためのフラット アドレッシングによる可変長オンネット ダイヤリング プランを示します。

図 23-9 デバイス モビリティのためのフラット アドレッシングによる可変長オンネット ダイヤリング プラン

 

次の設計上の考慮事項が、図 23-9 のダイヤル プラン モデルに適用されます。

このダイヤル プランで 4 桁のサイト内ダイヤリングを実装するトランスレーション パターンは、デバイス CSS によって参照されます。これは、サイト固有の回線 CSS を持つ要件を回避するために行われます。(ユーザがデバイス モビリティ グループ内でローミングしているとすると)デバイス CSS がローミング デバイス プールのデバイス モビリティ CSS で更新されるため、モバイル ユーザは訪問したサイトのサイト内ダイヤリングを継承します。この動作が望ましくない場合は、各サイトをデバイス モビリティ グループとして定義することを検討してください。ただし、ユーザは、外部 PSTN コールすべてで、モバイル電話では引き続きホーム ゲートウェイが使用され、したがって WAN 大域幅が消費されることを承知しておく必要があります。これは、標準ローカル ルート グループを使用して回避できます(「ローミング デバイスの出力ゲートウェイの選択」を参照)。

PSTN および内部電話機パーティションへのアクセスだけを持つローミング ユーザのために追加のデバイス コーリング サーチ スペースを設定できます。この設定には、サイトごとに 1 つ以上の追加のデバイス プールとコーリング サーチ スペースが必要です。したがって、 N 個のサイトには、 N 個のデバイス プールおよび N 個のコーリング サーチ スペースが必要です。ただし、この設定では、各サイトをデバイス モビリティ グループとして定義する必要がありません。この設定を適用しているモバイル ユーザは、ローミング時にデバイス CSS からトランスレーション パターンを参照しません。

リモート SRST ゲートウェイに登録されているモバイル ユーザは、一意な内線番号を持ちます。ただし、モバイル ユーザは、リモート SRST ゲートウェイに登録されているときは、PSTN ユーザがモバイル ユーザと通話できないことを承知しておく必要があります。

従来のアプローチとローカル ルート グループを使用した +E.164 ダイヤル プラン

「ダイヤル プラン」の章で説明したように、回線/デバイス アプローチにはいくつかの特定の問題があり、回線/デバイス アプローチに基づいて +E-164 ダイヤル プランを作成することは推奨されません。+E.164 ダイヤル プランの推奨されるアプローチは、回線 CSS でサービス クラスの選択とダイヤリングの正規化を組み合わせて、ローカル ルート グループ機能を使用してサイト固有の出力ゲートウェイ選択の要件に対応することです。このアプローチでは、電話機のデバイス CSS はまったく使用されません。デバイス モビリティとこのアプローチを併用する場合、設計のローミングを受けやすい唯一のコンポーネントは、デバイス プールのローカル ルート グループです。ローミング電話機では(デバイス モビリティ グループ内またはデバイス モビリティ グループ間のローミング)、電話のホーム デバイス プールで定義されたローカル ルート グループは、ローミング デバイス プールで定義されたローカル ルート グループによって常に更新されます。これは、すべてのコールが、訪問したサイトに対してローカルなゲートウェイを介して出力されることを保証されます。

マルチサイト企業モビリティのハイ アベイラビリティ

マルチサイト企業モビリティ機能およびソリューションは、モビリティ機能のハイ アベイラビリティを保証するため、冗長性を備えた方法で設定、配置する必要があります。有線電話機の移動、無線ローミング、およびマルチサイト モビリティ配置での EM のハイ アベイラビリティの考慮事項は、キャンパス モビリティ配置での考慮事項と同様です。キャンパス環境と同じく、冗長ネットワーク ポート、無線セル カバレッジ、およびエクステンション モビリティのログインおよびログアウトを処理する Unified CM ノードが、高可用なサービスを確保するために必要です。

また、デバイス モビリティ機能のハイ アベイラビリティを考慮することも重要です。デバイス モビリティ機能はネイティブで Unified CM 呼制御内に統合されているため、デバイス モビリティの機能がクラスタ ノードの障害による影響を受けることはありません。パブリッシャ ノードまたは呼処理(サブスクライバ)ノードに障害が発生した場合、デバイス プール、デバイス モビリティ情報、デバイス モビリティ グループ、およびデバイス モビリティに関連する他のすべての設定は保持されます。また、呼処理ノードに障害が発生した場合、影響を受ける電話機は、Unified CM Group の構成要素に基づいて、通常どおりセカンダリ呼処理ノードまたは Survivable Remote Site Telephony(SRST)リファレンス ルータにフェールオーバーします。


) Cisco TelePresence System エンドポイントは Cisco Unified CM または IOS SRST での登録の冗長性をサポートしていません。


マルチサイト企業モビリティのキャパシティ プランニング

デバイス モビリティのスケーラビリティの考慮事項と同様、この機能および各種の構成要素(デバイス プールやデバイス モビリティ グループなど)に関連する特定のキャパシティ制限または強制的なキャパシティ制限はありません。一般的なシステム サイジング、キャパシティ プランニング、および配置上の考慮事項の詳細については、「コラボレーション ソリューションの設計および配置サイジングに関する考慮事項」の章を参照してください。

マルチサイト企業モビリティの設計上の考慮事項

企業モビリティの設計上の考慮事項はすべて、マルチサイト企業モビリティ配置にも適用されます(「キャンパス企業モビリティの設計上の考慮事項」を参照)。さらに、次の設計に関する推奨事項が、特にマルチサイト モビリティ環境に適用されます。

サイト間の接続や、他のサイトの接続の障害が重要な動作を妨害しないよう、すべての重要なサービス(デバイス登録、PSTN 接続、DNS、DHCP など)をマルチサイト配置内の各サイトで確実に配置してください。加えて、デバイスや必要なコール キャパシティをサポートするため、十分な数の物理ネットワーク ポートおよびワイヤレス LAN AP が各サイトで使用できるようにしてください。

異なるダイヤリング パターンを持つ複数のサイト(たとえば、異なる PSTN アクセス コードを持つ複数のサイト)が同じデバイス モビリティ グループ内に設定されている場合、ローミング ユーザが各自のロケーションに基づいて異なる方法で番号をダイヤルする必要があるため、混乱を招く可能性があります。このため、類似のダイヤリング パターンを持つサイト(たとえば、同じ PSTN アクセス コードを持つサイト)を同じデバイス モビリティ グループに割り当てることを推奨します。これにより、ローミング ユーザは、デバイス モビリティ グループ内のすべてのサイトで同じ方法で番号をダイヤルできます。

「ローミング」デバイス プールからのデバイス モビリティ設定が適用されるのは、同じデバイス モビリティ グループ内でローミングするときだけです。移動された電話機からの元のコールが「ホーム」またはデバイスで設定されているコーリング サーチ スペースを使用し、結果的にコール ルーティング動作が引き起こされるため、異なるデバイス モビリティ グループ間でのローミングを避けてください。これにより、ローカルな「ローミング」ゲートウェイではなく別のサイトのゲートウェイを経由してコールがルーティングされる可能性があります。その結果、不必要に WAN 帯域幅が消費されることがあります。

物理ロケーションは各サイトに 1 つだけ定義してください。そうすることで、ユーザがサイト間でローミングを行う場合にだけ、デバイス モビリティが適用されます。同じサイト内でローミングを行う場合は、デバイス モビリティに影響する要素(たとえば、WAN 帯域幅消費、コーデック選択、コール アドミッション制御など)を考慮する必要はありません。単一のサイト内では通常、低速のリンクは配置されないためです。

フェールオーバーのシナリオでは、「ローミング」電話機は、「ローミング」デバイス プールのローミング依存設定に従って、SRST リファレンス/ゲートウェイを利用します。したがって、これらの状況においては、「ローミング」電話機の DID は別のロケーションの PSTN ゲートウェイにアンカーされているために、PSTN からこの電話機に到達することはできません。さらに、「ローミング」電話機からコールを発信する場合は、PSTN アクセス コードなどの要素に対してダイヤリング動作を変更する必要があることがあります。また、電話機で設定されているスピード ダイヤルが使用できなくなることもあります。

システムで、短縮ダイヤルを使用できることや、短縮ダイヤルに依存するスピード ダイヤルを使用できることが要求されている場合は、固定オンネット ダイヤル プラン モデルを使用することを推奨します。このモデルを使用すると、(直接またはスピード ダイヤルによる)短縮ダイヤルは、モバイル ユーザの電話機がローミング ロケーションにあっても、動作を継続するためです。すべての内線番号またはディレクトリ番号は全サイトにわたって一意であるため、短縮ダイヤルを使用し続けることができます。また、重複する内線番号がないため、短縮ダイヤルを普遍的に使用できます。

システムが可変長オンネット ダイヤル プラン モデルを使用する場合(回線/デバイスまたは回線 CSS だけの +E.164 ダイヤル プラン アプローチを使用)、コールされたときに単一の一意の内線番号に到達されるように不変的な方法でスピード ダイヤルを設定することを推奨します。完全な +E.164 番号を使用するか、サイトまたはアクセス コードを使用してスピード ダイヤルを設定することにより、ローミング ユーザはすべてのロケーションで同じスピード ダイヤルを使用できます。

VPN 接続を介して企業ネットワークにアクセスすることがあるユーザに対してデバイス モビリティを有効にした場合は、VPN ロケーションへの「ローミング」により確実に動的デバイス モビリティ設定変更が行われるように、VPN が接続された電話機のデバイス モビリティ情報(DMI)に、VPN コンセントレータにより配信または所有された IP サブネットが含まれている必要があります。DMI は、VPN コンセントレータと同じ場所にあるデバイスに使用されているデバイス プールに関連付ける必要があります。

リモート企業モビリティ

リモート企業モビリティは、企業から離れたロケーションにいて、公共のインターネットを介した安全な接続により企業ネットワーク インフラストラクチャに接続しているモバイル ユーザを指します。ここでモビリティは、これらのリモート ロケーションでのエンドポイント デバイスの配置や、企業と各自のロケーション間での頻度に関わらないユーザの移動や、場合によってはユーザが使用するモバイル デバイスを処理します。

リモート企業モビリティのアーキテクチャ

図 23-10 に示すように、リモート企業モビリティのアーキテクチャは、リモート物理ロケーション(一般に、従業員のホーム オフィスや、それ以外の、インターネット経由で会社に安全に接続できるあらゆるリモート ロケーション)に基づいています。これらのリモート サイトは、一般にユーザのコンピュータ、電話機、およびその他の機器またはエンドポイントへ接続できる IP ネットワークで構成されます。場合によっては、この IP ネットワークを企業の制御下に置き、リモート ロケーションと企業ネットワーク間に安全なトンネルを備えた VPN ルータまたはエッジ セキュリティ プラットフォームを構成できます。また、リモート サイト IP ネットワークをユーザが用意したルータを介してインターネットに接続し、ユーザのコンピュータまたはエンドポイント デバイスでソフトウェアベースの VPN クライアント機能を使用して会社のネットワークへの安全な接続を作成する必要がある場合もあります。無線接続をリモート ロケーションで使用して、ユーザのコンピュータまたはエンドポイントを無線接続できるようにすることもできます。無線接続をリモート ロケーションで使用する場合、ワイヤレス電話機を企業ネットワークからホーム オフィスへ移動することもでき、企業デバイスまたはモバイル電話機をリモート ロケーション内で利用して受信することもできます。

図 23-10 リモート企業モビリティのアーキテクチャ

 

リモート企業モビリティのタイプ

リモート企業モビリティ配置は、通常のユーザまたはデバイスの移動をサポートすることではなく、主にリモート ユーザをサポートすることに重点を置いています。確かにユーザは、エンドポイント デバイスを持っても持たなくても定期的に企業ロケーション間またはロケーションとリモート サイト間を移動できます。ただし、これらの配置の主な目的は、企業ユーザのリモート接続をサポートすることです。一般的にリモート サイト モビリティには、主にルータベースの安全な接続とクライアントベースの安全な接続の 2 つのタイプがあります。両方のタイプとも、リモート サイトへの安全な接続をサポートしており、デュアルモード モバイル電話機、ワイヤレス IP フォンおよびタブレット、さらには有線 IP フォンなどの、リモート サイトと企業間で移動できるさまざまなエンドポイント デバイスに対応できます。

クライアントベースの安全なリモート接続

無線および有線 IP フォンと、ソフトウェアベースの PC テレフォニー クライアントは、図 23-10 に示すように、リモート サイト ロケーションに接続できます。これらのデバイスおよびエンドポイントは、企業の VPN ヘッドエンド ターミネーション コンセントレータに安全に VPN 接続する必要があります。

これらのタイプのデバイスの例には、VPN クライアント、または Cisco Jabber for iPhone および Android クライアントなどのアプリケーション機能を使用する無線接続のモバイル クライアント デバイス(「シスコの Cisco Mobile クライアントおよびデバイス」を参照)、組み込み VPN クライアントを使用する Cisco Unified IP Phone 7965 などの有線の Cisco Unified IP Phone、ならびに企業ネットワークへの接続用のソフトウェア ベースの VPN クライアントを使用する Cisco Jabber などのソフトウェア ベースのテレフォニー クライアントを実行するパーソナル コンピュータが含まれます。

ルータベースの安全なリモート接続

一方、リモート サイト接続は、ルータベースの安全な VPN トンネルを介して行うことができます。これらのタイプのシナリオでは、配置したワイヤレス ネットワーク接続も可能なリモート サイト ルータで、企業ネットワークへの安全な VPN トンネルを設定する必要があります。これにより実質的に、企業ネットワークの境界をリモート サイト ロケーションまで広げます。このタイプの接続のメリットは、より幅広い種類のデバイスとエンドポイントをリモート サイトに配置できることです。これらのデバイスで接続の安全性を確保する必要がなく、特別なソフトウェアや設定の必要がないためです。代わりに、これらのデバイスはリモート サイト ネットワークに接続するだけで、リモート サイト ルータから企業 VPN ヘッドエンドまでの安全な VPN IP パスを利用できます。

このタイプのルートベースのリモート サイト接続の例には、Cisco Virtual Office ソリューションがあります。

デバイス モビリティと VPN ベースのリモート企業接続

クライアントベース接続とルータベースの安全なリモート接続のどちらを配置するかにかかわらず、コール アドミッション制御およびコーデックがエンドポイント デバイスに正しくネゴシエートされ、適切な企業サイトの PSTN ゲートウェイおよびメディア リソースが使用されるようにするため、デバイス モビリティ機能を使用できます。VPN 接続経由で受信したエンドポイント デバイスの IP アドレスに基づいて、Unified CM はデバイスのロケーションを動的に決定します。

図 23-11 は、Cisco Jabber デスクトップ コラボレーション クライアントがリモート サイトのコンピュータで実行されている、クライアントベースの安全なリモート接続の例です。このソフトウェアベースのコラボレーション アプリケーションは、クライアントベースの VPN を介して企業に接続され、Unified CM に登録されています。

図 23-11 リモート サイトの Cisco Jabber 向けのクライアントベースの VPN 接続

 

次は、企業に VPN 接続経由で接続しているリモート サイトにおいて、ユーザ デバイスでのデバイス モビリティ機能の有効化に関する設計ガイドラインです。

VPN コンセントレータによって配布または所有されている IP サブネットを指定してデバイス モビリティ情報(DMI)を設定します。

VPN コンセントレータと同じ場所にあるデバイスに使用されるデバイス プールと同じデバイス プールに DMI を関連付けます。ただし、コール特権、ネットワーク ロケールなどのパラメータを考慮する必要があります。

リモート サイトのユーザに、クライアントベースまたはルータベースの VPN 接続を行う場合は、地理的に最も近い企業 VPN コンセントレータを指定するよう指導します。

これらのガイドラインにより、確実に、企業 WAN 上でおよびリモート サイトへの接続を介して、コール アドミッション制御が正しく適用されます。

VPN の配置の詳細については、次のサイトの「Design Zone for Security」の「 Security in WAN 」で入手可能な各種の VPN 設計ガイドを参照してください。

http://www.cisco.com/en/US/solutions/ns340/ns414/ns742/ns744/landing_wan_security.html

エンタープライズ エッジの安全なリモート接続

さまざまな Cisco TelePresence System エンドポイントは、企業に VPN 接続する必要がなくリモート登録をサポートします。これらのエンドポイントは H460、Asset、SIP などのプロトコルおよび Cisco VCS Expressway を利用します。これらのサポート対象エンドポイントは、直接 VCS Expressway に登録し、VPN 接続なしで暗号化シグナリングおよびメディアを利用できます。Cisco VCS Expressway は企業の DMZ に設置され、Cisco VCS Control とピアを確立することで、社内ネットワークと公共のインターネット間のファイアウォールを通過します。これらのリモート エンドポイントは、これらのリモート エンドポイントは、企業のネットワーク内にある音声エンドポイントやビデオ エンドポイントとコールの送受信が可能です。

図 23-12 は、Cisco VCS とのエンタープライズ エッジ リモート接続の例を示します。リモート ロケーションの Cisco TelePresence エンドポイントは Cisco VCS Expressway に登録されます。これらのエンドポイント間のコールは、VCS Control(VCS-C)と VCS Expressway(VCS-E)間の接続を介して企業ファイアウォールを通過します。

図 23-12 Cisco VCS Expressway とのエンタープライズ エッジの安全なリモート接続

 

リモート企業モビリティのハイ アベイラビリティ

リモート サイト モビリティ環境では、企業 VPN またはリモート エッジ セキュリティ サービスが、冗長性を備えた方法で企業内に構成され配置されている必要があります。これにより、クライアント ベース、ルータ ベース、およびリモート エッジの安全な接続の可用性が高いことが保証されます。企業内の VPN コンセントレータまたは VCS Expressway ノードに障害が発生した場合、他の VPN またはリモート エッジ ノードを備えたクライアントまたはエンドポイントで、新しい安全な接続を設定できます。デバイスの登録、音声サービスおよびビデオ サービスは、ノードの冗長性をもつ Unified CM クラスタ構成によって高可用性が保たれます。デバイスの登録とビデオ サービスは、Cisco VCS Control を用いた SIP 発信、および DNS ベース(SRV または A レコード)の冗長性によって高可用性が保たれます。


) Cisco TelePresence System の C、EX、MX、SX、TX の各シリーズのビデオ エンドポイントは、Unified CM 登録の冗長性をサポートしていません。プライマリ Unified CM ノードが到達不能な場合、これらのエンドポイントはセカンダリ Unified CM ノードに登録をフェールオーバーしません。


リモート企業モビリティのキャパシティ プランニング

リモート企業モビリティ環境のスケーラビリティの考慮事項で最も重要なのは、VPN コンセントレータのキャパシティです。管理者は、クライアントベース、ルータベース、またはリモート エッジの安全な接続のいずれの場合でも、すべてのリモート サイトの接続に対応する十分な VPN セッション キャパシティを配置する必要があります。Cisco VCS Expressway の場合、各ノードで最大 2,500 のリモート デバイス登録をサポートできます。適切なキャパシティを用意しないと、一部のリモート サイトが会社に接続できなくなり、基本的なテレフォニー サービスでもアクセスできなくなります。さらに、キャンパスまたはマルチサイト企業モビリティの配置と同様、すべてのリモート ユーザのデバイスを処理できるよう、企業内に十分なデバイス登録キャパシティを用意することが重要です。

Cisco 呼制御でのエンドポイント キャパシティ(プラットフォーム固有のエンドポイント設定や登録キャパシティなど)の詳細については、「コラボレーション ソリューションの設計および配置サイジングに関する考慮事項」の章を参照してください。

リモート企業モビリティの設計上の考慮事項

モバイル ユーザがリモート サイト接続できるようにする場合、次の設計上の推奨事項を考慮してください。

デバイス モビリティを使用する場合、VPN コンセントレータが配布または所有する IP サブネットを含むデバイス モビリティ情報(DMI)を忘れずに設定し、この DMI を VPN コンセントレータと同じロケーションに配置するデバイスに設定される同じデバイス プールに割り当ててください。

リモート サイト ユーザに、VPN を接続する場合は最も近い VPN コンセントレータを選択するよう指導します。

すべてのリモート サイト ユーザへの接続を用意するため、適切な VPN セッション キャパシティが確実に使用できるようにしてください。

社外型モビリティ

Cisco Mobile Unified Communications を使用すると、モバイル ユーザは、デスクフォンだけでなく、1 台以上のリモート電話機でも会社の電話番号へのコールを処理できます。また、モビリティ ユーザは、まるで社内から電話をかけているかのようにリモート電話機から電話をかけることもできます。さらに、モビリティ ユーザは、保留、転送、会議などのエンタープライズ機能だけでなく、携帯電話上でのボイスメール、会議、プレゼンスなどのエンタープライズ アプリケーションも利用できます。これによって、ユーザは外出先でも生産性を持続させることができます。

さらに、モバイル ボイス ネットワークやモバイル データ ネットワークおよび 802.11 WLAN への接続を提供するデュアルモード電話を使用すると、ユーザは社外で企業アプリケーションを利用できるだけでなく、社内にいるとき、または企業ネットワークにリモート接続されているときにエンタープライズ テレフォニー インフラストラクチャを利用して、モバイル ボイス ネットワークの分単位の料金を支払わずにコールの発信と受信を行うことができます。

Cisco Unified Mobility ソリューション内に配布されるフィックスド・モバイル・コンバージェンス(FMC)モビリティ機能は、Cisco Unified Communications Manager(Unified CM)によって提供され、Cisco Jabber などのシスコのモバイル クライアントとと併用できます。

Cisco Unified Mobility では、次のモビリティ アプリケーション機能が提供されます。

モバイル コネクト

シングル ナンバー リーチとも呼ばれるモバイル コネクトを使用すれば、1 つの会社の電話番号で Cisco Collaboration ユーザの IP デスクフォンと携帯電話の両方を同時に呼び出すことができます。モバイル コネクト ユーザは、着信コールをデスクフォンでも携帯電話でも受けることができ、通話中のコールを妨げることなく別の電話に転送できます。

通話切替機能

通話切替機能により、モビリティ コールの通話中に、携帯電話の保留、保留解除、転送、会議、およびリダイレクト コール パーク機能を呼び出すことができます。これらの機能は、携帯電話のキーによって呼び出され、保留音や会議ブリッジといった企業のメディア リソースを活用します。

シングル企業ボイスメール ボックス

シングル企業ボイスメール ボックスは、モバイル ボイスメール回避機能を提供し、ユーザの会社の電話番号に着信し、さらに携帯電話に転送されたコールに応答がなかった場合に、携帯電話のボイスメール システムではなく、会社のボイスメール システムにコールを蓄積します。これにより、ボイスメール ボックスが 1 箇所に統合され、ユーザは複数のボイスメール システムでメッセージを確認する必要がなくなります。

モバイル ボイス アクセスとエンタープライズ機能アクセスの 2 ステージ ダイヤリング

モバイル ボイス アクセスとエンタープライズ機能アクセスの 2 ステージ ダイヤリングによって、まるで会社の IP デスクフォンからかけているかのように、携帯電話から発信できます。長距離電話や国際電話、または通常は企業外部から到達不能なシステム上の内部の DID 以外の内線番号へのコールにおいてこれらの機能を使用すると、通話料金を節約できます。また、企業でこれらの 2 ステージ ダイヤリング機能を使用すると、中央で一括管理されたコール詳細レコードによって、ユーザのコール発信を容易に追跡管理できるようになります。さらに、これらの機能によって、発信者 ID を送信する際にユーザの携帯電話番号を隠すことができます。代わりに、発信者 ID として、ユーザの会社の電話番号が送信されます。これによって、ユーザへの返信コールは会社の電話番号にアンカーされるため、コールを会社で一括管理できます。

Cisco TelePresence Video Communication Server(Cisco VCS)呼制御プラットフォームは、FindMe 機能によって FMC 機能も提供します。この機能により、ユーザへのコールで呼出音が鳴るエンドポイント(ビデオと音声のみ)を指定できるようになります。FindMe を使用することで、ユーザはプライマリ デバイスのいずれのデバイスも使用中または応答しない場合にコールする、フォールバック デバイスを指定することができます。この機能は、Unified Mobility モバイル コネクト機能と同様のシングル ナンバー リーチ機能を提供します。

シスコのモバイル クライアントおよびデバイスは、音声とデータ接続用のモバイル プロバイダー ネットワークおよび 802.11 のワイヤレス ネットワークの両方に接続できる機能を提供します。これは、ユーザが 1 つのデバイスから両方のエンタープライズ呼制御、場合によってはモバイル ネットワークの呼制御を利用できるようにします。可能であれば、コールを送受信するための企業のテレフォニー インフラストラクチャを利用することによって、また、デュアル モード電話機の場合は企業接続が利用できないときだけにモバイル ボイス ネットワークに戻ることによって、モバイル クライアントおよびデバイスは、テレフォニーのコストの削減を支援できます。また、デュアルモード電話、およびそこで実行されるクライアントには、ハンドオフ メカニズムが備えられているため、ユーザが社内と社外の境界を越えて移動した場合に、通話中のボイスコールにおいて、WLAN インターフェイスとモバイル ボイス インターフェイスを簡単に切り替えることができます。

シスコのモバイル クライアントでは、モバイル デバイスを有効にして、802.11 WLAN またはモバイル データ ネットワーク経由で Voice over IP コールを発信できるようにすることに加え、Dial via Office 機能を使用した企業の自動化ダイヤリングも有効にしました。Dial via Office コールは、IP ネットワーク経由のシグナリングを使用して設定され、一方メディア パスは、モバイル ボイス ネットワークおよび PSTN 経由で設定されます。シスコのモバイル クライアントとデバイスは、社内ディレクトリ アクセス、プレゼンスおよびインスタント メッセージング(IM)などの他の Unified Communications サービスも提供します。これらのデバイスとクライアントでは、モバイル ユーザは、コラボレーション アプリケーションへのアクセスを提供することによって社内、社外にかかわらず生産性を維持できると同時に、ユーザは、パブリックまたはプライベートの WiFi モバイル ホット スポットやモバイル データ ネットワーク、社内で WLAN 経由にかかわらず、モバイル デバイスからエンタープライズ コールを送受信できます。

この項では、まず、Unified Mobility の特徴、機能、および設計と配置に関する考慮事項について説明します。Unified Mobility のさまざまなメリットおよびモバイル クライアントとデバイスを統合することによってその機能が利用できるという事実を前提として、Cisco Jabber などのモバイル クライアント アプリケーションを検証します。モバイル クライアントとデバイスの説明に続いて、ここでは、アーキテクチャ、機能、ならびに次のモビリティ アプリケーションおよび機能の設計と配置との関係を説明します。

「Cisco Unified Mobility」

「シスコの Cisco Mobile クライアントおよびデバイス」

Cisco Unified Mobility

Cisco Unified Mobility は、Cisco Unified Communications Manager(Unified CM)に組み込まれたネイティブなモビリティ機能を意味し、モバイル コネクト、モバイル ボイス アクセス、およびエンタープライズ機能アクセスの各機能が含まれます。

Unified Mobility の機能は、Unified CM の設定によって異なります。したがって、この設定だけでなく、論理コンポーネントの特性も理解することが重要です。

図 23-13 に、Unified Mobility に関する設定要件を示します。 まず、ユーザに関しては、モビリティ ユーザの会社の電話機は、電話番号、パーティション、コーリング サーチ スペースなどの該当する回線レベル設定値を使用して設定されます。この他に、会社の電話機のデバイス レベルの設定には、デバイス プール、共通デバイス設定、コーリング サーチ スペース、メディア リソース グループ リスト、ユーザとネットワークの保留音源などのパラメータが含まれます。ユーザの会社の電話機に関するこれらの回線およびデバイス設定のすべてが、着信コールと発信コールのコール ルーティングや保留音(MoH)の動作に影響を与えます。

次に、Unified Mobility 機能が利用できるように、モビリティ ユーザごとのリモート接続先プロファイルを設定する必要があります。リモート接続先プロファイルは、ユーザの会社の電話回線と同じ電話番号、パーティション、およびコーリング サーチ スペースを使用して回線レベルで設定します。これによって、リモート接続先プロファイルと会社の電話機の間で回線が共有されます。リモート接続先プロファイル設定には、デバイス プール、コーリング サーチ スペース、コーリング サーチ スペースの再ルーティング、およびユーザとネットワークの保留音源に関するパラメータが含まれます。リモート接続先プロファイルは、その設定にユーザの回線レベルの会社の電話機の設定が反映されますが、回線レベルの設定とプロファイル レベルの設定を組み合わせることによって、ユーザのリモート接続先電話機に継承されるコール ルーティングおよび MoH 動作が決定される仮想電話機と見なす必要があります。リモート接続先プロファイルと会社の電話機の間で共有されるユーザの会社の電話番号を使用すれば、その番号に電話することによってユーザのリモート接続先に転送できます。

図 23-13 Cisco Unified Mobility の設定アーキテクチャ

 

図 23-13 に示すように、モビリティ ユーザは、1 つまたは複数のリモート接続先をリモート接続先プロファイルに関連付けることができます。リモート接続先は、ユーザを呼び出すための単一の PSTN 電話番号を表しています。ユーザは、最大で 10 個のリモート接続先を定義できます。リモート接続先ごとにコール ルーティング タイマーを設定して、コールを特定のリモート電話に転送する時間だけでなく、コールを転送する前に待機する時間とリモート電話でコールを受ける準備ができるまでの時間を調整できます。また、モビリティ ユーザは、リモート接続先ごとに、リモート電話に転送する特定の電話番号からのコールを許可または拒否するフィルタを設定できます。


) Cisco Business Edition では、モビリティ ユーザ 1 人につき最大 4 つのリモート接続先がサポートされています。


モバイル コネクト

モバイル コネクト機能を使用すれば、企業ユーザへの着信コールをそのユーザのデスクトップフォンだけでなく、最大 10 個の設定可能なリモート接続先に転送できます。一般的に、ユーザのリモート接続先は携帯電話です。コールがデスクトップフォンとリモート接続先電話機の両方に転送されれば、ユーザはどちらかの電話機で応答できます。ユーザは、リモート接続先電話機のいずれかまたは IP デスクトップフォンでコールに応答したときに、そのコールを別の電話機でハンドオフするか、ピックアップするかを選択できます。

モバイル コネクトの機能

図 23-14 に、基本的なモバイル コネクトのコール フローを示します。この例では、PSTN 上の電話機 A からモバイル コネクト ユーザの会社の電話番号(DN)408-555-1234 に電話をかけます(ステップ 1)。コールが会社の PSTN ゲートウェイから Unified CM を経由して DN 408-555-1234 の IP フォンに転送され(ステップ 2)、この電話が鳴り出します。コールは、同じ DN を共有するユーザのリモート接続先プロファイルにも転送されます(ステップ 3)。次に、コールがユーザのリモート接続先プロファイルに関連付けられたリモート接続先(この場合は 408-555-7890)に発信されます(ステップ 4)。リモート接続先への発信コールが PSTN ゲートウェイを介してルーティングされます(ステップ 5)。最後に、番号が 408 555-7890 のリモート接続先 PSTN 電話機で呼出音が鳴ります(ステップ 6)。どちらの電話機でも応答できます。

図 23-14 モバイル コネクト

 

通常、モバイル コネクト ユーザの設定済みリモート接続先は、モバイル ボイス ネットワークまたはセルラー プロバイダー ネットワーク上の携帯電話です。ただし、PSTN による到達可能な任意の接続先をユーザのリモート接続先として設定できます。さらに、モバイル コネクト ユーザは 10 件までリモート接続先を設定できるため、着信コールは最大で 10 台の PSTN 電話機とユーザのデスクフォンを呼び出すことができます。デスクトップフォンまたはリモート接続先電話機のいずれかでコールに応答すると、他のリモート接続先またはデスクトップフォン(デスクトップフォンで応答しなかった場合)に転送されたすべてのコール レッグがクリアされます。リモート接続先で着信コールに応答した場合は、2 つのゲートウェイ ポートを使用している会社の PSTN ゲートウェイ内で音声メディア パスがヘアピンされます。モバイル コネクト機能を配置する場合はこの利用を考慮する必要があります。


) Cisco Business Edition システムのモビリティ ユーザには、最大 4 つのリモート接続先を設定できます。



図 23-14 に示すようにモバイル コネクトを動作させるには、[End User] 設定ページでユーザ レベルの [Enable Mobility] チェックボックスがオンになっており、少なくとも 1 つのユーザの設定済みリモート接続先で [Enable Mobile Connect] チェックボックスがオンになっていることを確認します。


デスクトップフォンのピックアップ

図 23-15 に示すように、ユーザがリモート接続先デバイスでモバイル コネクトに応答した場合(ステップ 1:この場合は 408 555-7890)は、ユーザはデスクトップフォンの [Resume] ソフトキーを押すだけで、いつでもリモート接続先でコールをいったん切ってから、デスクトップフォンでピックアップできます(ステップ 2:この場合は DN 408 555-1234)。 電話機 A を使用している元の発信者とデスクトップフォンとの間でコールが再開されます(ステップ 3)。

図 23-15 デスクトップフォンのピックアップ

 

デスクトップフォンのピックアップは、設定済みのリモート接続先電話機で会社の固定コールの通話が行われた後、その電話が切られた場合にいつでも実行できます。


) 会社の固定コールとは、会社の PSTN ゲートウェイ経由で接続された少なくとも 1 つのコール レッグがあり、リモート接続先から会社の DID に発信された、あるいはモバイル コネクト、モバイル ボイス アクセス、エンタープライズ機能アクセス、または Intelligent Session Control によって発信されたすべてのコールを指します。


デスクトップフォンでコールをピックアップまたは保留解除するためのオプションは、一定時間しか使用できません。そのため、モバイル コネクト ユーザは、必ず、着信電話機が切れていることを確認してから、リモート接続先電話機を切るようにしてください。これによって、他の誰かがデスクフォンでコールを保留解除できないことが保証されます。デフォルトで、リモート接続先電話機が切られてから 10 秒間はコールをデスクトップフォンでピックアップできます。ただし、この時間は設定可能であり、[End User] 設定ページで Maximum Wait Time for Desk Pickup パラメータを変更することによって、ユーザごとに 0 ~ 30000 ミリ秒に設定できます。デスクトップフォンのピックアップは、リモート接続先電話機で通話切替保留機能を呼び出した後でも実行できます。ただし、このような場合は、Maximum Wait Time for Desk Pickup パラメータの設定が、ピックアップに使用できる時間に影響しません。通話切替保留されたコールは、リモート電話機とデスクトップフォンのどちらかで手動で保留解除されるまで、保留のままで、デスクトップフォンでピックアップできます。

デスクトップフォンのピックアップを実行するもう 1 つの方法に、通話切替セッション ハンドオフ機能を使用する方法があります。この通話切替機能は、セッション ハンドオフのデフォルトのエンタープライズ機能アクセス コードである *74 を手動で入力することによって呼び出します。これにより、Unified CM への DTMF シーケンスが生成されます。この機能が呼び出されると、Unified CM からユーザの会社のデスクトップフォンに新しいコールが送信されます。ユーザは、セッション ハンドオフを完了させるために、この新しいコールがデスクトップフォンの点滅表示または呼出音によって通知されたらこのコールに応答する必要があります。

デスクトップフォンのピックアップを行う場合にこの方法を使用すると、他の方法(携帯電話でコールを切断する方法や通話切替保留機能を使用する方法など)と比較して、ユーザと遠端の電話機との間の会話がハンドオフ プロセス中にも維持されるという利点があります。*74 シーケンスを入力すると、ハンドオフ コールがユーザのデスクトップフォンに送信されるため、ユーザは会話を継続できます。ユーザがデスクトップフォンでコールに応答すると、コール レッグが切り替えられて、遠端へのコール レッグが、デスクトップフォンに作成された新しいコール レッグに接続されます。これにより、音声パスが切断されずに、またはほぼ瞬間的にカットスルーされます。モバイル デバイスの元のコール レッグは、後でクリアされます。

コールを切断してデスクフォンのピックアップを呼び出す方法では、エンド ユーザの Maximum Wait Time for Desk Pickup の設定によってデスクフォンでコールをピックアップできる時間が決定されます。一方、セッション ハンドオフでは、[Session Handoff Alerting Timer] サービス パラメータによって、デスクフォンでどの程度の時間呼出音または点滅表示によってコールが通知された後にハンドオフ コールがクリアされるかが決定されます。デフォルトのハンドオフ アラート時間は 10 秒です。また、セッション ハンドオフでは、デスクトップフォンに設定されたどの自動転送設定も関与しません。その結果、ハンドオフ機能では、ボイスメールやその他の自動転送宛先への転送は行われません。Session Handoff Alerting Timer 期間を経過してもコールに応答しないと、コールはクリアされて、ユーザのデスクフォン回線から Remote In Use 状態が削除されます。ただし、このシナリオでは、携帯電話の元のコールは維持されます。

セッション ハンドオフおよびその他の通話切替機能の詳細については、「通話切替機能」を参照してください。

リモート接続先電話のピックアップ

図 23-16 に、モバイル コネクトのリモート接続先電話機のピックアップ機能を示します。電話機 A からモバイル コネクト ユーザの会社の DN 408 555-1234 が呼び出され、そのコールがユーザのデスクトップフォンで応答されて通話中である場合(ステップ 1)は、ユーザが [Mobility] ソフトキーを押す必要があります。この電話機でモバイル コネクト機能が有効になっており、リモート接続先ピックアップが使用できる場合、ユーザは [Select] ソフトキーを押します(ステップ 2)。ユーザのリモート接続先電話機に対するコール(この場合は 408 555-7890)が実行され、リモート電話機が鳴り出します。リモート電話機でコールが応答されると、電話機 A と、番号が 408 555-7890 のモバイル コネクト ユーザのリモート電話機との間でコールが再開されます(ステップ 3)。

図 23-16 リモート接続先電話のピックアップ

 

モバイル コネクト ユーザに対して複数のリモート接続先が設定されている場合は、[Select] ソフトキーを押したときに各リモート接続先が呼び出され、ユーザは好きな電話機をピックアップできます。


図 23-16 に示すように、リモート接続先電話機のピックアップを動作させるには、1 つ以上のユーザの設定済みリモート接続先で [Mobile Phone] チェックボックスがオンになっていることを確認してください。加えて、[Mobility] ソフトキーをすべてのモビリティ ユーザの関連するデスクトップフォン ソフトキー テンプレートに追加する必要があります。[Mobile Phone] チェックボックスをオンにして、Mobility ユーザが [Mobility] ソフトキーを使用できるようにしなければ、リモート接続先電話機のピックアップ機能が使用できません。



) Cisco TelePresence System の C、EX、MX、SX、TX の各シリーズのビデオ エンドポイントは、上述のリモート接続先のピックアップをサポートしていません。これらのエンドポイントでは、モビリティ ソフトキーまたは [Send call to Mobile Phone] オプションはユーザから見えないようになっています。したがって、これらのエンドポイントは、リモート接続先のピック アップを使用してモバイル デバイスに進行中のコールを送信できません。


通話切替機能

図 23-17 に示すように、ユーザがリモート接続先デバイスでモバイル コネクト コールに応答(ステップ 1:この場合は 408 555-7890)したら、会社の PSTN ゲートウェイ経由でリモート接続先電話機から Unified CM に DTMF 番号を送信することによって、保留、保留解除、転送、会議、ダイレクト コール パーク、セッション ハンドオフなどの通話切替機能を呼び出すことができます(ステップ 2)。通話切替機能の保留、転送、会議、またはダイレクト コール パークが呼び出されると、Unified CM から電話の相手に MoH が送信されます(ステップ 3:この場合は電話機 A)。通話中のコールを別の電話機やダイレクト コール パーク番号に転送したり、会社の会議リソースを使用して新しい電話機で会議に参加できます(ステップ 4)。

図 23-17 モビリティ通話切替機能

 

Unified CM に転送された一連の DTMF 番号によって、リモート接続先電話機で通話切替機能が呼び出されます。Unified CM で受信されるこれらの番号シーケンスが、設定済みの保留、独占保留、保留解除、転送、会議、およびセッション ハンドオフ用のエンタープライズ機能アクセス コードと照合され、該当する機能が実行されます。


) ダイレクト コール パークの通話切替機能を有効にするには、ダイレクト コール パーク番号とコール パーク取得プレフィックスを使用して Cisco Unified CM を設定する必要があります。



) 転送、会議、およびダイレクト コール パークの通話切替機能を実行するために、コールに応答して、ユーザ入力(PIN 番号、通話切替機能アクセス コード、およびターゲット番号を含む)を取得し、必要なコール レッグを作成して転送、会議、またはダイレクト コール パークの処理を完了させる、システム設定のエンタープライズ機能アクセス DID への別のコール レッグがリモート接続先電話機で生成されます。


通話切替セッション ハンドオフ機能では、遠端は保留されないため、MoH は遠端に転送されません。モバイル ユーザがデスクトップフォンでハンドオフ コールに応答するまでの間、元の音声パスが維持されます。ユーザがコールに応答すると、コール レッグが会社のゲートウェイで切り替えられ、音声パスが引き続き維持されます。

通話切替機能は、手動で機能アクセス コードを入力し、適切なキー シーケンスを入力することによって呼び出されます。 表 23-2 に、通話切替機能を呼び出すためのキー シーケンスを示します。

表 23-2 手動通話切替機能のキー シーケンス

通話切替機能
エンタープライズ機能アクセス コード(デフォルト)
手動キー シーケンス

保留

*81

入力:*81

独占保留

*82

入力:*82

復帰

*83

入力:*83

転送

*84

1. 入力:*82(独占保留)

2. エンタープライズ機能アクセス DID への新しいコールの発信

3. 接続時の入力:
<PIN_number> # *84 # <Transfer_Target/DN> #

4. 転送ターゲットでの応答時(打診転送の場合)またはリングバック時(初期在席転送の場合)の入力:*84

ダイレクト コール パーク

該当なし

1. 入力:*82(独占保留)

2. エンタープライズ機能アクセス DID への新しいコールの発信

3. 接続時の入力:
<PIN_number> # *84 # <Directed_Call_Park_Number> # *84 #

(注) パークされたコールを取得するには、モバイル ボイス アクセスまたはエンタープライズ機能アクセス 2 ステージ ダイヤリングを使用してコールをダイレクト コール パーク番号に発信する必要があります。ダイヤルするダイレクト コール パーク番号が入力する際、適切なコール パーク取得プレフィックスを付加する必要があります。

会議

*85

1. 入力:*82(独占保留)

2. エンタープライズ機能アクセス DID への新しいコールの発信

3. 接続時の入力:
<PIN_number> # *85 # <Conference_Target/DN> #

4. 会議ターゲットによる応答時の入力:*85

セッション ハンドオフ

*74

1. 入力:*74

2. デスクトップフォンに呼出音または点滅表示で通知されたら応答


) 保留や会議などの通話切替機能のためのメディア リソース割り当ては、リモート接続先プロファイル設定、またはデュアルモード電話機および Unified Mobile Communicator の場合にはデバイス設定で決定されます。リモート接続先プロファイルまたはモバイル クライアント デバイスに設定されたデバイス プールのメディア リソース グループ リスト(MRGL)が、会議通話切替機能のための会議ブリッジの割り当てに使用されます。リモート接続先プロファイルまたはモバイル クライアント デバイスのユーザ保留オーディオ ソースとネットワーク保留 MoH オーディオ ソースの設定、およびデバイス プールのメディア リソース グループ リスト(MRGL)が、保留デバイスに送信する MoH ストリームの決定に使用されます。


シングル企業ボイスメール ボックスによるモバイル ボイスメール回避

Unified Mobility モバイル コネクトに関する追加の考慮事項は、モバイル ボイスメール回避です。シングル企業ボイスメール ボックス機能では、応答がないすべての企業ビジネス コールは最終的に企業ボイスメール システムに転送されます。これによって、ユーザは、応答がない会社の電話番号へのコール用に用意された複数のメールボックス(会社、携帯電話、自宅など)をチェックする必要がなくなります。この機能は、モバイルまたは非企業のボイス メールを避けるために、2 種類の方式を提供します。

タイマー制御方式:この方法によってシステムは、自動転送タイマーと組み合わせた 1 組のタイマー(リモート接続先ごとに 1 つ)に依存し、無応答時にコールがボイスメール システムに転送されると企業ボイスメール システムがコールを受信するようになります。

ユーザ制御方式:この方法によってシステムは、コールが応答されてコールがユーザまたは非企業ボイス メールに受信されたかを判断する場合はリモート接続先からの DTMF トーンの確認に依存します。

システム設定は、タイマー制御方式またはユーザ制御方式が使用されているかどうかを判断します。使用される方式は、Voicemail Selection Policy サービス パラメータによってグローバルに設定でき、また、Single Number Reach Voicemail Policy によって個々のリモート接続先ごとに設定できます。デフォルトでは、システムおよびすべてのリモート宛先はタイマー制御メソッド方式を使用します

タイマー コントロールのモバイル ボイス メールの無効化

この方式では、システムは [Remote Destination] 設定ページのタイマーのセットに依存します。これらのタイマーの目的は、コールが無応答呼び出しでボイスメール システムに転送されたときに、そのコールがリモート接続先のボイスメール システムではなく、会社のボイスメール システムに転送されることを保証することです。これらのタイマーは、他のシステム無応答転送タイマーとともに、次のように非企業ボイスメール システムを回避するように設定する必要があります。

デスクフォンの無応答転送時間をリモート接続先電話機よりも短くします。

これを実現するために、Unified CM のグローバルな無応答転送タイマー フィールドまたは個々の電話回線の無応答呼び出し期間フィールドを、リモート接続先電話機のモバイル ボイスメール システムに転送されるまでの呼び出し期間より短い値に設定します。加えて、[Remote Destination] 設定ページの [Delay Before Ringing Timer] パラメータを使用して、リモート接続先電話機の呼び出しを遅らせることによって、リモート接続先電話機からそのモバイル ボイスメール ボックスに転送されるまでの時間を延ばすことができます。ただし、[Delay Before Ringing Timer] パラメータを調整する場合は、グローバルな Unified CM 無応答転送タイマー(または回線レベルの無応答呼び出し期間フィールド)が、モビリティ ユーザが余裕を持ってリモート接続先電話機の呼び出しに応答できる値に設定されていることを確認する必要があります。[Delay Before Ringing Timer] パラメータは、リモート接続先ごとに設定することが可能で、デフォルト値は 4,000 ミリ秒です。

着信コールがモバイル ボイスメール システムに転送されるまでリモート接続先デバイスで呼び出しを停止します。

これを実現するには、各リモート接続先に Answer Too Soon Timer および Answer Too Late Timer を使用します。まず、[Remote Destination] 設定ページの [Answer Too Soon Timer] パラメータに、電源オフまたは圏外の携帯電話へのコールがモバイル ボイスメール システムに転送されるまでにかかる時間より長い値を設定する必要があります。デフォルトでは、このタイマーは 1,500 ミリ秒(つまり 1.5 秒)に設定されます。Answer Too Soon Timer が切れる前にコールが応答された場合、リモート接続先へのコール レッグが切断されます。これにより、モバイル ボイスメール システムにすぐに転送されたコールは接続されませんが、呼び出し後にユーザが応答したコールは接続されます。

次に、[Remote Destination] 設定ページの [Answer Too Late Timer] パラメータを、リモート接続先電話機が呼び出されてからボイスメール ボックスに転送されるまでの時間より短い値に設定します。デフォルトでは、このタイマーは 19,00 ミリ秒(つまり 19 秒)に設定されます。このタイマーが切れる前にコールに応答がなかった場合、リモート接続先へのコール レッグが切断されます。これにより、コールがモバイル ボイスメール システムに転送されるまでリモート接続先電話機で呼び出しが停止されます。


) モビリティ ユーザが、Answer Too Soon Timer が切れてから、手動でリモート接続先に宛先変更した着信コールは、最終的にモバイル ボイスメール ボックスに転送される可能性があります。この発生を回避するには、モビリティ ユーザがユーザ制御方式を設定するか、またはボイス メールに宛先変更する着信コールの呼出音を無視または停止するように指示される必要があります。これによって、無応答コールは必ず、企業ボイスメール ボックスに転送されることが保証されます。



) ほとんどの配置シナリオでは、[Delay Before Ringing Timer]、[Answer Too Late Timer]、および [Answer Too Soon Timer] のデフォルト値で十分であり、変更する必要はありません。


ユーザ制御のモバイル ボイス メールの無効化

この方式では、システムは、コールが応答されたときのリモート宛先からの DTMF 確認トーンにコールに依存します。DTMF トーンがシステムによって受信された場合、システムはユーザがコールに応答し、DTMF トーンを生成するキーを押したことを認識します。一方、DTMF トーンがシステムで受信されない場合、システムは、コール レッグが非企業ボイス メール システムで応答されてコール レッグが切断されると見なします。

ユーザ制御方式が有効にされると、応答時にエンド ユーザには、DTMF トーンを生成するキー パッド ボタンを押すことを要求する音声プロンプトが聞こえます。デフォルトでは、音声プロンプトは、ユーザがコールに応答してから 1 秒後に再生されます。ユーザが応答直後に DTMF トーンを生成するキー パッドを押すと、音声プロンプトが聞こえない場合があります。音声プロンプトは、リモート接続先のコール レッグでだけ再生されるため、遠端側にはプロンプトが聞こえません。音声プロンプトがユーザに再生されたら、デフォルトでシステムは、DTMF トーンを受信するために 5 秒間待機します。トーンが受信されない場合、システムはコール レッグを切断しますが、通話がユーザによって応答されるまで、または企業ボイス メール システムに転送されるまで、ユーザの設定した他のデバイスを鳴らし続けます。


) ユーザ制御のモバイル ボイス メールの回避方式は、モバイル ボイス ネットワークまたは PSTN のリモート宛先から Unified CM まで DTMF トーンのリレーが成功することに完全に依存しています。DTMF トーンは Unified CM にアウトオブバンドで送信されます。DTMF リレーがネットワークおよびシステムで正しく設定されていない場合、DTMF は受信されず、ユーザ制御方式に依存するリモート宛先へのすべてのコール レッグは切断されます。システム管理者は、ユーザ制御方式を有効にする前に、企業のテレフォニー ネットワークで適切な DTMF の相互運用およびリレーを確認する必要があります。DTMF が PSTN から Unified CM に効果的にリレーできない場合、代わりにタイマー コントロールのモバイル ボイス メールの無効化方式を使用する必要があります。


モバイル コネクトの有効化と無効化

モバイル コネクト機能は、次の方法のいずれかを使用して有効または無効にできます。

[Cisco Unified CM Administration] ページまたは [Cisco Unified CM User Options] ページ

管理者またはユーザが、[Mobile Connect] チェックボックスをオフにしてその機能を無効にするか、[Mobile Connect] チェックボックスをオンにしてその機能を有効にします。これをリモート接続先ごとに実行します。

モバイル ボイス アクセスまたはエンタープライズ機能アクセス

モビリティ対応ユーザが、モバイル ボイス アクセスまたはエンタープライズ機能アクセスにダイヤルインして、適切なクレデンシャルを入力後に、数字の 2 を入力して有効にするか、数字の 3 を入力して無効にします。モバイル ボイス アクセスでは、単一のリモート接続先またはすべてのリモート接続先のモバイル コネクトを有効/無効にするように促されます。エンタープライズ機能アクセスでは、呼び出しているリモート接続先のモバイル コネクトしか有効/無効にできません。

デスクトップフォンの [Mobility] ソフトキー

ユーザは、電話がオンフック状態のときに [Mobility] ソフトキーを押して、モバイル コネクトを有効にするか、無効にするかを選択します。この方法では、ユーザのリモート接続先のモバイル コネクトすべてが有効または無効にされます。

モバイル コネクト コールの許可または拒否用のアクセス リスト

アクセス リストは、Cisco Unified CM 内で設定して、リモート接続先に関連付けることができます。アクセス リストは、モビリティ対応ユーザのリモート接続先に転送される着信コールを許可または拒否(着信コールの発信者 ID に基づく)するために使用されます。さらに、これらのアクセス リストは時刻に基づいて呼び出されます。

アクセス リストは、拒否または許可するモビリティ対応ユーザごとに設定されます。アクセス リストには、特定の番号または番号マスクで構成された 1 つ以上のメンバーまたはフィルタが含まれており、このフィルタが発信側の着信コールの発信者 ID と比較されます。発信者 ID と照合するための特定の番号文字列または番号マスクが含まれることに加えて、アクセス リストには、発信者 ID が使用できない、または、発信者 ID がプライベートに設定されている着信コール用のフィルタも含めることができます。拒否対象のアクセス リストには、アクセス リストに入力された番号からのコールは拒否されるが、その他の番号からのコールは許可されるように、リストの最後に暗黙の「すべて許可」が含まれています。許可対象のアクセス リストには、アクセス リストに入力された番号からのコールは許可されるが、その他の番号からのコールは拒否されるように、リストの最後に暗黙の「すべて拒否」が含まれています。

設定したアクセス リストを Remote Destination 設定画面で設定した Ring Schedule に関連付けると、設定した Ring Schedule と選択したアクセス リストの組み合わせによって、リモート接続先ごとのモバイル コネクトの時刻コール フィルタリングが提供されます。Cisco Unified CM Administration インターフェイスを使用している管理者または Cisco Unified CM User Options インターフェイスを使用しているエンド ユーザは、アクセス リストと Ring Schedule を設定してリモート接続先に関連付けることができます。

モバイル コネクトのアーキテクチャ

モバイル コネクト機能のアーキテクチャを理解することは、その機能を理解することと同様に重要です。図 23-18 に、モバイル コネクトに必要なメッセージ フローとアーキテクチャを示します。次の相互作用とイベントのシーケンスが、Unified CM、モバイル コネクト ユーザ、およびモバイル コネクト ユーザのデスクトップフォンの間で発生する可能性があります。

1. モバイル コネクト機能の有効化または無効化、あるいはリモート接続先電話機の通話中コールのピックアップを希望しているモバイル コネクト電話機のユーザが、デスクトップフォンの [Mobility] ソフトキーを押します(図 23-18 のステップ 1 を参照)。

2. Unified CM からモバイル コネクトのステータス(オンまたはオフ)が返されます。ユーザは、電話が接続状態であれば携帯電話にコールを転送するオプションを選択することも、電話がオン フック状態であればモバイル コネクトのステータスを有効/無効にすることもできます(図 23-18 のステップ 2 を参照)。

3. モバイル コネクト ユーザは、Unified CM User Options インターフェイスを使用して、次の URL にある Web ベースの設定ページ経由で独自のモビリティ設定を構成できます。

http:// <Unified-CM_Server_IP_Address> /ccmuser/

ここで、 <Unified-CM_Server_IP_Address> は、Unified CM パブリッシャ サーバの IP アドレスです(図 23-18 のステップ 3 を参照)。

図 23-18 モバイル コネクトのアーキテクチャ

 

モバイル コネクトのハイ アベイラビリティ

モバイル コネクト機能には、次のコンポーネントが必要です。

Unified CM サーバ

PSTN ゲートウェイ

各コンポーネントの冗長性または弾力性を向上させて、さまざまな障害シナリオでモバイル コネクトの機能が失われないようにする必要があります。

Unified CM サーバの冗長性

モバイル コネクト機能には、Unified CM サーバが不可欠です。Unified CM Group による電話機とゲートウェイの登録が冗長になっていれば、Unified CM サーバが故障してもモバイル コネクト機能は影響を受けません。

モバイル コネクト ユーザが Unified CM User Options Web インターフェイスを使用してモビリティ設定(リモート接続先とアクセス リスト)を構成できるようにするには、Unified CM パブリッシャ サーバが使用可能である必要があります。パブリッシャがダウンすると、ユーザはモビリティ設定を変更できなくなります。同様に、管理者も Unified CM でモビリティ設定を変更できなくなります。ただし、既存のモビリティ設定と機能は維持されます。最後に、システムでモバイル コネクトのステータスに対する変更を Unified CM パブリッシャ サーバ上に記録する必要があります。Unified CM パブリッシャが使用できない場合は、モバイル コネクトの有効化または無効化が使用できなくなります。

PSTN ゲートウェイの冗長性

モバイル コネクト機能は、新しいコール レッグを PSTN に拡張してモバイル コネクト ユーザのリモート接続先電話機に到達する機能に依存しているため、PSTN ゲートウェイの冗長性は重要です。PSTN ゲートウェイが故障したり、容量不足の場合は、モバイル コネクト コールを完了できません。 通常は、会社の IP テレフォニー ダイヤル プランを通して、物理的なゲートウェイの冗長性とコールの再ルーティング機能だけでなく、予想されるコール アクティビティを処理する十分な容量が提供されることによって、PSTN アクセスに冗長性が提供されます。Unified CM が、コール ルーティングの弾力性を確保するための十分な容量、複数のゲートウェイ、およびルート グループとルート リストの構造で構成されていれば、この冗長性によってモバイル コネクト機能の持続性が保証されます。

Cisco TelePresence FindMe

Cisco TelePresence FindMe は、ユーザの FindMe ID を呼び出すときに呼び出し音が鳴るエンドポイント(ビデオおよび音声のみ)を指定する機能を提供する Cisco VCS 機能です。FindMe を使用した場合、いずれかのプライマリ デバイスがビジー状態の場合にコールされるフォールバック デバイスを指定したり、すべてのプライマリ デバイスが応答されない場合にコールされるフォールバック デバイスを指定したりできます。Cisco VCS の FindMe は、Unified CM のモバイル コネクト シングル ナンバー リーチ(SNR)と多くの点で類似しています。

FindMe の重要な機能は、管理者が、着信側のエンドポイントに表示される発信者 ID を、発信者のエンドポイントの ID ではなく、発信者の FindMe ID に設定できることです。これは、コールを返す場合、そのコールが FindMe ID に返され、その結果、ユーザが元のコールを発信したときに位置していたエンドポイントを呼び出すだけでなく、そのユーザの実行中の FindMe ロケーションの電話機のすべてで呼び出し音が鳴ることを意味します。

Unified CM および Cisco VCS の両方を統合した企業は、モバイル コネクトまたは FindMe のどちらを使用するか選択する必要がありますが、両方を選択する必要はありません。

FindMe の配置の詳細については、次の Web サイトで入手可能な VCS のマニュアルを参照してください。

http://www.cisco.com/en/US/products/ps11337/products_installation_and_configuration_guides_list.html

モバイル ボイス アクセスとエンタープライズ機能アクセス

モバイル ボイス アクセス(システム リモート アクセスとも呼ばれる)とエンタープライズ機能アクセス 2 ステージ ダイヤリングは、モバイル コネクト アプリケーションに組み込まれている機能です。両方の機能を使用すれば、モビリティ対応ユーザは、外出先でも、Unified CM に直接接続されているかのように電話をかけることができます。この機能は、従来のテレフォニー環境では、一般的に、Direct Inward System Access(DISA)と呼ばれています。これらの機能を通して、通話料金を抑えたり、モバイル ユーザごとに通話料を請求するのではなく、直接会社に請求するように配慮することによって、会社にメリットがもたらされます。加えて、これらの機能を使用すれば、ユーザは、発信者 ID を外部に送信するときに、携帯電話やリモート接続先の番号を隠すことができます。代わりに、発信者 ID として、ユーザの会社のディレクトリ番号が送信されます。これによって、ユーザへの返信コールは会社の電話番号にアンカーされるため、コールを会社で一括管理できます。また、モバイル ユーザは、これらの機能を使用して、通常は企業外部から到達不能な内部の内線番号や DID 以外の会社の電話番号にダイヤルできます。

モバイル ボイス アクセスには、H.323 または SIP VoiceXML(VXML)ゲートウェイで応答および処理されるシステム設定の DID 番号を呼び出すことによってアクセスします。VoiceXML ゲートウェイによって、モバイル ボイス アクセス ユーザに対する双方向音声応答(IVR)プロンプトが再生され、ユーザ認証と電話機のキーパッド経由でダイヤルされる番号入力が要求されます。

エンタープライズ機能アクセス機能には、前述した通話切替機能や会議機能だけでなく、2 ステージ ダイヤリング機能が含まれています。2 ステージ ダイヤリングは、IVR プロンプトを除いて、モバイル ボイス アクセスと同様の方法で動作します。システム設定のエンタープライズ機能アクセス DID が Unified CM によって応答されます。ユーザは、電話機のキーパッドまたはスマート フォン ソフトキーを使用して、認証とダイヤルする番号を入力します。これらの入力はプロンプトなしで受信されます。

モバイル ボイス アクセスとエンタープライズ機能アクセス 2 ステージ ダイヤリングの両方の機能を使用すれば、ユーザは、入力番号に対するコールが接続されたときに、通話切替機能を呼び出したり、モバイル コネクト コールと同様にデスクトップフォンでコールをピックアップしたりできます。この動作は、コールが会社のゲートウェイにアンカーされることによって可能になります。

モバイル ボイス アクセス IVR VoiceXML ゲートウェイ URL

モバイル ボイス アクセス機能を使用するには、Unified CM VoiceXML アプリケーションを H.323 または SIP ゲートウェイ上にインストールする必要があります。このアプリケーションをロードするための URL は次のとおりです。

http:// <Unified-CM-Publisher_IP-Address> :8080/ccmivr/pages/IVRMainpage.vxml

ここで、 <Unified-CM-Publisher_IP-Address> は、Unified CM パブリッシャ ノードの IP アドレスです。

モバイル ボイス アクセス機能

図 23-19 に、モバイル ボイス アクセスのコール フローを示します。この例では、モバイル ボイス アクセス ユーザが PSTN 電話機(408 555-7890)からモバイル ボイス アクセス会社の DID DN 408-555-2345 にダイヤルします(ステップ 1)。

このコールは、VoiceXML ゲートウェイとしても機能する会社の PSTN H.323 または SIP ゲートウェイに入ります。ユーザは、IVR 経由で、数字のユーザ ID(後ろに # 記号が続く)、PIN 番号(後ろに # 記号が続く)、および 1 の入力と、相手の電話番号が続くモバイル ボイス アクセス コールの発信を要求されます。この場合は、ユーザが相手の番号として 9 1 972 555 3456(後ろに # 記号が続く)を入力します(ステップ 2)。


) モバイル ボイス アクセス ユーザがかけている PSTN 電話機が、そのユーザのモバイル コネクト リモート接続先として設定されており、Unified CM で着信コールの発信者 ID とこのリモート接続先を照合可能な場合は、数字のユーザ ID を入力する必要がありません。代わりに、PIN 番号の入力だけが要求されます。


その一方で、IVR プロンプトが Unified CM からゲートウェイに転送され、ゲートウェイでユーザに対してプロンプトが再生され、ゲートウェイでユーザの数字の ID と PIN 番号を含む入力が収集されます。この情報は、認証と 9 1 972 555 3456 へのコールを発信するために Unified CM に転送されます(ステップ 3)。ユーザの認証とダイヤルする番号の受信後に、Unified CM でユーザのリモート接続先プロファイル経由のコールが発信されます(ステップ 4)。972 555-3456 への発信コールが、PSTN ゲートウェイ経由で経路設定されます(ステップ 5)。最後に、番号が 972 555-3456 の PSTN 接続先電話機で呼出音が鳴ります(ステップ 6)。

図 23-19 モバイル ボイス アクセス

 


) モバイル ボイス アクセスを図 23-19 のように動作させるには、システム全体の Enable Mobile Voice Access サービス パラメータが True に設定され、[End User] 設定ページでユーザごとに [Enable Mobile Voice Access] チェックボックスがオンになっていることを確認してください。



) モバイル ボイス アクセス機能を使用するには、Unified CM Serviceability の設定ページで [Cisco Unified Mobile Voice Access Service] を手動でアクティブにする必要があります。このサービスは、パブリッシャ ノードでのみアクティブにできます。


ヘアピニングを使用したモバイル ボイス アクセス

会社の PSTN ゲートウェイで H.323 または SIP が使用されていない配置では、H.323 を実行している別のゲートウェイ上のヘアピニングを使用することによってモバイル ボイス アクセス機能を提供することもできます。ヘアピニングを使用したモバイル ボイス アクセスの場合は、VoiceXML 機能を別の H.323 ゲートウェイに持たせる必要があります。図 23-20 に、ヘアピニングを使用したモバイル ボイス アクセスのコール フローを示します。この例では、前の例と同じく、モバイル ボイス アクセス ユーザが PSTN 電話機(408 555-7890)からモバイル ボイス アクセス会社の DID DN 408-555-2345 にダイヤルします(ステップ 1)。コールが、会社の PSTN ゲートウェイに入ってきて(ステップ 2)、呼処理のために Unified CM に転送されます(ステップ 3)。Unified CM が着信コールを H.323 VoiceXML ゲートウェイにルーティングします(ステップ 4)。IVR がユーザに、自分の数字のユーザ ID と PIN、およびモバイル ボイス アクセス コールを作成するための 1 を入力し、続けて接続先の電話番号を入力するように求めます。この場合も、ユーザが相手の番号として 9 1 972 555 3456(後ろに # 記号が続く)を入力します。


) ヘアピニングを使用したモバイル ボイス アクセスでは、システムを呼び出しているユーザが発信者 ID によって自動的に特定されません。代わりに、PIN を入力する前に、手動でリモート接続先の番号を入力する必要があります。ユーザが自動的に特定されない理由は、ヘアピニングを使用する配置では、PSTN ゲートウェイにおいて最初にコールを Unified CM にルーティングして、ヘアピンされるモバイル ボイス アクセス ゲートウェイに到達する必要があるためです。コールが最初に Unified CM にルーティングされるため、発信番号が携帯の番号から会社の電話番号に変換されてから、コールがモバイル ボイス アクセス ゲートウェイによって処理されます。このため、モバイル ボイス アクセス ゲートウェイでは、発信番号と設定されているリモート接続先の照合を行うことができず、ユーザはリモート接続先番号の入力を求められます。これは、ヘアピニングを使用する配置に特有の現象です。通常のモバイル ボイス アクセスのフローにおいては、モバイル ボイス アクセス機能はローカル ゲートウェイで利用できるため、PSTN ゲートウェイで最初にコールを Unified CM にルーティングしてからモバイル ボイス アクセスにアクセスする必要がありません。


その間に、H.323 VoiceXML ゲートウェイは、ユーザ入力を収集して Unified CM に転送し、転送された IVR プロンプトを PSTN ゲートウェイおよびモバイル ボイス アクセス ユーザに対して再生します。これを受けて Unified CM がユーザ入力を受信し、ユーザを認証し、ユーザ入力に基づいて適切な IVR プロンプトを H.323 VoiceXML ゲートウェイに転送します(ステップ 5)。ダイヤルする番号の受信後に、Unified CM でユーザのリモート接続先プロファイルを使用したコールが発信されます(ステップ 6)。972 555-3456 への発信コールが、PSTN ゲートウェイ経由で経路設定されます(ステップ 7)。最後に、番号が 972 555-3456 の PSTN 接続先電話機で呼出音が鳴ります(ステップ 8)。

図 23-20 ヘアピニングを使用したモバイル ボイス アクセス

 


) モバイル ボイス アクセスをヘアピニング モードで配置する場合は、PSTN ゲートウェイでのモバイル ボイス アクセス DID と Cisco Unified CM 内のモバイル ボイス アクセス電話番号(Media Resources - Mobile Voice Access)を別々の番号として設定することを推奨します。そうすれば、Unified CM 内のトランスレーション パターンを使用して、モバイル ボイス アクセス DID の着信番号を設定済みのモバイル ボイス アクセス電話番号に変換できます。Unified CM 内で設定されたモバイル ボイス アクセス電話番号は管理者にしか表示されないため、DID と電話番号間の変換をエンド ユーザが意識する必要はなく、エンド ユーザのダイヤリング動作に変更は生じません。この方法は、マルチクラスタ環境でのモビリティ コール ルーティング問題を回避するために推奨されています。この推奨事項は、非ヘアピニング モードのモバイル ボイス アクセスには当てはまりません。



) ヘアピニング モードのモバイル ボイス アクセスは、H.323 VXML ゲートウェイだけでサポートされています。


2 ステージ ダイヤリングを伴うエンタープライズ機能アクセス

図 23-21 に、エンタープライズ機能アクセス 2 ステージ ダイヤリングを示します。この例では、モビリティ ユーザがリモート接続先電話機(408 555-7890)からエンタープライズ機能アクセス DID 408 555-2345 にダイヤルします(ステップ 1)。コールが接続されると、Unified CM で認証されるユーザの PIN(後ろに # 記号が続く)で始まる DTMF 番号を PSTN ゲートウェイ経由で Unified CM に送信するためにリモート接続先電話機が使用されます。次に、2 ステージ ダイヤリング対象コールが試みられることを示す 1(後ろに # 記号が続く)と相手の電話番号が送信されます。この場合は、ユーザが接続先番号として 9 1 972 555 3456 と入力します(ステップ 2)。


) モバイル ボイス アクセスとは違って、エンタープライズ機能アクセスでは、エンド ユーザ アカウントに対して発信者 ID と PIN を照合するためにリモート接続先として設定された電話機から、すべての 2 ステージ ダイヤリング対象コールを発信する必要があります。エンタープライズ機能アクセスにおいては、モビリティ ユーザが自身を識別するためのリモート接続先番号または ID をシステムに入力するための仕組みは用意されていません。同一性は、着信コールの発信者 ID と入力された PIN の組み合わせを通してのみ確立できます。


次に、発信コールがユーザのリモート接続先プロファイル経由で開始され(ステップ 3)、PSTN 番号 972 555-3456 へのコールが会社の PSTN ゲートウェイ経由で経路設定されます(ステップ 4)。最後に、PSTN 電話機が呼び出されます(ステップ 5:この場合は 972 555-3456)。モバイル ボイス アクセスと同様に、各エンタープライズ機能アクセス 2 ステージ ダイヤリング対象コールの音声メディア パスは、2 つのゲートウェイ ポートを使用している PSTN ゲートウェイ内でヘアピンされます。

図 23-21 エンタープライズ機能アクセス 2 ステージ ダイヤリング機能

 


) エンタープライズ機能アクセス 2 ステージ ダイヤリングを図 23-21 のように動作させるには、システム全体の Enable Enterprise Feature Access サービス パラメータが True に設定されていることを確認してください。


デスクトップフォンとリモート接続先電話機のピックアップ

モバイル ボイス アクセス機能とエンタープライズ機能アクセス機能はモバイル コネクトと緊密に統合されているため、モバイル ボイス アクセスまたはエンタープライズ機能アクセス 2 ステージ ダイヤリング対象コールが確立されていれば、ユーザはモバイル コネクト機能を利用して、最初に着信した電話機をオン フックしてデスクトップフォンの [Resume] ソフトキーを押すだけで、または、通話切替保留機能を使用して、通話中のコールをデスクトップフォンでピックアップできます。さらに、その後で、ユーザの設定済みリモート接続先電話機で [Mobility] ソフトキーを押して Send Call to Mobile Phone を選択することによって、そのコールをピックアップできます。

モバイル コネクトの有効化と無効化

モバイル ボイス アクセスとエンタープライズ機能アクセスのユーザにまるで社内にいるかのように PSTN から電話がかけられる能力を提供することに加えて、H.323 または SIP VoiceXML ゲートウェイ上のモバイル ボイス アクセスで提供される機能とエンタープライズ機能アクセスで提供される機能によって、電話機のキーパッド経由でリモート接続先ごとのモバイル コネクト機能をリモートで有効または無効にできる能力もユーザに提供されます。1 を入力して電話をかけるのではなく、ユーザは、2 を入力してモバイル コネクト機能を有効にし、3 を入力してモバイル コネクト機能を無効にします。

モバイル ボイス アクセスを使用するにあたって、複数のリモート接続先を設定する場合は、モバイル コネクト機能を有効または無効にするリモート接続先の電話番号を入力するように要求されます。エンタープライズ機能アクセスでは、呼び出しているリモート接続先電話機のモバイル コネクトしか有効/無効にできません。


) Enable Mobile Voice Access サービス パラメータが False に設定されており、2 ステージ ダイヤリング対象コールを行うことができない場合でも、モバイル ボイス アクセスでは、リモートからモバイル コネクトをユーザが有効または無効にする機能が提供されます。システムにモバイル ボイス アクセス電話番号が設定され、ユーザのアカウントでモバイル ボイス アクセスが有効にされて、Cisco Unified Mobile Voice Access サービスがパブリッシャ上で実行されている限り、発信側のユーザはモバイル コネクトを有効または無効にできます。


モバイル ボイス アクセスとエンタープライズ機能アクセスの番号拒否

管理者は、モバイル ボイス アクセスとエンタープライズ機能アクセスの 2 ステージ ダイヤリングのユーザが、それらの機能の使用中は特定の番号にダイヤルできないようにできます。オフネット コールに対してこれらの機能を使用している場合に特定の番号へのコールを制限または拒否するには、[System Remote Access Blocked Numbers] サービス パラメータ フィールドでそのような番号のカンマ区切りのリストを設定できます。このパラメータに拒否する番号を設定したら、モバイル ボイス アクセスまたはエンタープライズ機能アクセスが使用されている場合は、ユーザのリモート接続先電話機からそれらの番号にダイヤルできなくなります。管理者が拒否したい番号には、911 などの緊急電話番号を含めることができます。拒否する番号を設定する場合は、会社のユーザが該当するプレフィックスまたは振り分け用の数字を付けてダイヤルするようにそれらの番号が設定されていることを確認してください。たとえば、緊急電話番号を拒否対象とし、システム ユーザが緊急電話番号をダイヤルするときは 9911 を使用しなければならない場合は、[System Remote Access Blocked Numbers] フィールドに設定する番号を 9911 にする必要があります。

モバイル ボイス アクセスおよびエンタープライズ機能アクセスのアクセス番号

Unified CM システムでは、1 つのモバイル ボイス アクセス電話番号だけを設定することもできますが、これらの内部で設定された番号にアクセス可能な外部番号を複数使用できます。たとえば、米国の New York に配置されたシステム、San Jose のリモート サイト、および London の海外サイトがある場合を考えます。システムのモバイル ボイス アクセス電話番号が 555-1234 に設定されている場合でも、各ロケーションのゲートウェイを設定して、ローカル DID 番号またはフリーダイヤル DID 番号をこのモバイル ボイス アクセス電話番号にマッピングできます。 たとえば、New York のゲートウェイの DID である +1 212 555 1234 と +1 800 555 1234 の両方をモバイル ボイス アクセス番号にマッピングし、さらに San Jose のゲートウェイの DID +1 408 666 5678 および London のゲートウェイの DID +44 208 777 0987 もシステムのモバイル ボイス アクセス番号にマッピングできます。Unified CM システムでは、複数のエンタープライズ機能アクセス番号を設定できるため、ロケーション固有のシステム アクセス番号を配置の地理的なロケーションごとに設定できます。これにより、地理的なロケーションにかかわらず、すべてのユーザに対してローカルまたはフリーダイヤルのエンタープライズ機能アクセス 2 ステージ ダイヤリング機能が有効になります。

システム管理者は、複数のローカル DID 番号またはフリーダイヤル DID 番号を用意することによって、2 ステージ ダイヤリング対象コールが常にローカルまたはフリーダイヤルのコールとしてシステムに発信されるようにでき、さらにテレフォニー関連コストを削減できます。

リモート接続先の設定と発信者 ID の照合

モバイル ボイス アクセス機能およびエンタープライズ機能アクセス 2 ステージ ダイヤリング機能に加えて、DTMF ベースの通話切替機能の転送と会議のユーザを認証するときに、発信元のリモート接続先電話機の発信者 ID がシステム内で設定されたすべてのリモート接続先に対して照合されます。この発信者 ID の照合は、リモート接続先番号の設定方法、システムで PSTN 振り分け用数字を含めるために番号プレフィックスが必要かどうか、[Matching Caller ID with Remote Destination] パラメータが [Partial Match] と [Complete Match] のどちらに設定されているかなどの複数の要因に左右されます。いずれの場合も、要件は、1 つまたは複数のリモート接続先番号に基づいて各モビリティ ユーザを識別できることです。したがって、リモート宛先番号がシステム内で一意に設定されるだけでなく、着信コールの発信者 ID の一致(完全照合を使用するか、一部照合を使用するか)が 1 つのリモート宛先に常に一意に対応しなければならないことも重要です。単一または一意の一致が見つからない場合、発信者 ID 照合は失敗します。

この照合の特性を制御するために、次の 2 つのアプローチを検討してください。

完全発信者 ID 照合の使用

このアプローチでは、発信者 ID が PSTN から供給されているかのようにリモート接続先を設定します。たとえば、リモート接続先電話機の発信者 ID を PSTN からシステムに 4085557890 として供給する場合は、[Remote Destination] 設定ページでこの番号を設定する必要があります。

このリモート接続先にモバイル コネクト コールを適切にルーティングするには、+E.164 ダイヤル方式または番号プレフィックス メカニズムを使用して必要な PSTN アクセス コードおよび他の必要な数字にプレフィックスを付けるようにダイヤル プランを設定する必要があります。たとえば、グローバル +E.164 ダイヤル プランを使用しないで、企業からのコールをダイヤルするときに 9 個のまたは他の PSTN 振り分け用数字または国番号が PSTN に到達するために必要であることが想定される場合、設定済みのリモート接続先番号の先頭に適切な PSTN 振り分け用数字と国番号を追加するように番号プレフィックスを設定する必要があります。番号プレフィックスは、Unified CM システム内でトランスレーション パターン、ルート パターン、またはルート リスト コンストラクトを使用して実施する必要があります。この完全照合アプローチおよび番号プレフィックス方式を使用する場合、Matching Caller ID with Complete Match パラメータをデフォルト設定の [Complete Match] のままにする必要があります。

アプリケーション ダイヤル ルールは、これらのシナリオで番号プレフィックスを提供するためにも使用されることがあります。ただし、アプリケーション ダイヤル ルールが着信ディジット ストリングの長さに基づくため分割できないことも注目すべきことであり、それは、システム全体でグローバルに適用されることを意味します。これは特に、複数のダイヤル ドメイン(たとえば、異なる国)が単一の Unified CM クラスタでサポートされる必要があるシナリオにおけるアプリケーション ダイヤル ルールの使用を厳しく制限します。


) アプリケーション ダイヤル ルールはモバイル コネクト、モバイル ボイス アクセス、およびエンタープライズ機能アクセスのコールに適用されるだけでなく、Cisco WebDialer、Cisco Unified CM Assistant、および Cisco Jabber アプリケーションから発信されたコールにも適用されます。したがって、すべてのアプリケーションを通してダイヤリング動作が期待どおりに機能するように、これらの規則を慎重に設定する必要があります。


推奨されるダイヤル プラン アプローチは、発信者 ID を PSTN からの入力の +E.164 に常にグローバル化し、リモート接続先を +E.164 として常に設定することです。これによって、すべての設定済みリモート接続先と比較すると、PSTN からの発信者 ID(正規化後)が一意の一致を常に提供することが保証されます。+E.164 ダイヤリングをサポートするダイヤル プランと組み合わせると、これは複数の国際番号計画をサポートしている場合でも、番号プレフィックスを不要にし、リモート接続先のユーザおよび番号の一意の ID を確認します。推奨されるダイヤル プラン アプローチがトランクの要件やユーザの希望に従って入力の発信者 ID をグローバル化し、出力でローカライズするため、PSTN から供給される発信者 ID を使用することはこのアプローチと互換性がありません。

部分発信者 ID 照合の使用

このアプローチでは、リモート接続先が、システムから PSTN にダイヤルされたかのように設定されます。たとえば、リモート接続先の番号が 14085557890 で、システムから PSTN にアクセスするために 9 を入力する必要がある場合は、[Remote Destination] 設定ページでこの番号を 914085557890 に設定する必要があります。このアプローチでは、システムにおける番号プレフィックス メカニズムの設定を必要としませんが、[Matching Caller ID with Remote Destination] サービス パラメータを [Partial Match] に設定し、[Number of Digits for Caller ID Partial Match] をリモート接続先発信者 ID に対して照合すべき連続桁数を表す適切な数字に設定する必要があります。たとえば、リモート接続先の発信者 ID が 14085557890 で、リモート接続先が 914085557890 に設定されている場合は、[Number of Digits for Caller ID Partial Match] を 10 または 11 に設定するのが理想的です。この例では、このパラメータをさらに少ない桁数に設定できます。ただし、システム内のすべての設定済みリモート接続先を一意的に識別できるように十分な連続桁数が照合されることを保証するように注意してください。部分発信者 ID 照合を使用したときに完全な一致が見つからない場合、または複数の設定済みリモート接続先が一致した場合は、システムで一致するリモート接続先番号が存在しないものとして処理されます。したがって、モバイル ボイス アクセスの場合は、PIN を入力する前にリモート接続先番号/ID を手動で入力する必要があります。エンタープライズ機能アクセスには、ユーザがリモート接続先番号を入力するメカニズムがありません。そのため、この機能を使用する場合は、一致が一意的にしか発生しないことを確認してください。


) PSTN サービス プロバイダーが可変長の発信者 ID を送信する場合は、着信コールごとの一意的な発信者 ID の一致が保証できない可能性があるため、部分発信者 ID 照合の使用は推奨できません。これらのシナリオでは、完全発信者 ID 照合または +E.164 ダイヤル プランは望ましい方法です。


モバイル ボイス アクセスとエンタープライズ機能アクセスのアーキテクチャ

モバイル ボイス アクセスとエンタープライズ機能アクセスのアーキテクチャを理解することは、それらの機能性を理解することと同じくらい重要です。図 23-22 は、モバイル ボイス アクセスとエンタープライズ機能アクセスに必要なメッセージ フローとアーキテクチャを示しています。Unified CM、PSTN ゲートウェイ、および H.323 または SIP VXML ゲートウェイの間には、次の一連の対話とイベントが発生します。

1. Unified CM から HTTP 経由で IVR プロンプトとインストラクションが H.323 または SIP VXML ゲートウェイに転送されます(図 23-22 のステップ 1 を参照)。これによって、VXML ゲートウェイで着信モバイル ボイス アクセス発信者に対してこれらのプロンプトを再生できます。

2. H.323 または SIP VXML ゲートウェイでは、HTTP を使用してモバイル ボイス アクセス ユーザの入力が Unified CM に戻されます(図 23-22 のステップ 2 を参照)。

3. PSTN ゲートウェイでは、リモート接続先電話機からのエンタープライズ機能アクセス 2 ステージ ダイヤリングおよび通話切替機能に関するユーザまたはスマート フォンのキー シーケンスに応答して DTMF 番号が転送されます(図 23-22 のステップ 3 を参照)。

図 23-22 モバイル ボイス アクセスとエンタープライズ機能アクセスのアーキテクチャ

 


図 23-22 では PSTN ゲートウェイとは別のボックスとして H.323 または SIP VoiceXML ゲートウェイが描かれていますが、これはアーキテクチャ上の要件ではありません。PSTN ゲートウェイで H.323 または SIP 以外のプロトコルを実行する必要がなければ、VoiceXML 機能と PSTN ゲートウェイ機能を同じボックスで処理できます。H.323 または SIP ゲートウェイは、モバイル ボイス アクセス VoiceXML 機能に不可欠です。


モバイル ボイス アクセスおよびエンタープライズ機能アクセスのハイ アベイラビリティ

モバイル ボイス アクセス機能とエンタープライズ機能アクセス機能には、モバイル コネクト機能と同じコンポーネントと冗長性メカニズムが必要です(「モバイル コネクトのハイ アベイラビリティ」を参照)。Unified CM Group は、PSTN ゲートウェイ登録の冗長性に欠かせません。同様に、PSTN の物理ゲートウェイとゲートウェイ接続の冗長性を提供する必要があります。PSTN と会社間の冗長なアクセスは、ゲートウェイが故障した場合に、リモート接続先電話機からモバイル ボイス アクセス機能とエンタープライズ機能アクセス機能にアクセスするために必要です。ただし、必要に応じて、H.323 または SIP VoiceXML ゲートウェイに対して物理的な冗長性を提供できますが、Unified CM 上には、Cisco Unified Mobile Voice Access サービス用の冗長性メカニズムがありません。このサービスは、パブリッシャ ノードでしか有効にして実行することができません。そのため、パブリッシャ ノードが無効な場合は、モバイル ボイス アクセス機能が使用できません。エンタープライズ機能アクセスと 2 ステージ ダイヤリング機能には、このようなパブリッシャとの依存関係がないため、モビリティ ユーザに同等の機能性(IVR プロンプトが再生されない)を提供できます。

Cisco Unified Mobility の配置の設計

Cisco Unified Mobility ソリューションでは、Cisco Unified CM を介してモビリティ機能が提供されます。機能には、モバイル コネクト、モバイル ボイス アクセス、およびエンタープライズ機能アクセスが含まれます。この機能を配置する場合は、ダイヤル プランの意味、ガイドラインと制約事項、および性能と容量に関する考慮事項を理解しておくことが重要です。

Cisco Unified Mobility のダイヤル プランに関する考慮事

Unified Mobility を適切に設定してプロビジョニングするには、リモート接続先プロファイル設定のコール ルーティング動作とダイヤル プランの意味を理解しておくことが重要です。

リモート接続先プロファイルの設定

Unified Mobility を設定する場合は、[Remote Destination Profile] 設定ページにある次の 2 つの設定を考慮する必要があります。

コーリング サーチ スペース

この設定と電話番号または回線レベルのコーリング サーチ スペース(CSS)を組み合わせて、モビリティ ダイヤル対象コール用にアクセス可能なパーティションが決定されます。この設定は、モバイル ボイス アクセスとエンタープライズ機能アクセス 2 ステージ ダイヤリングを含む、リモート接続先電話機からのモビリティ ユーザによるコールだけでなく、通話切替の転送機能と会議機能の組み合わせによるコールにも影響します。この CSS と回線レベルの CSS の組み合わせの中に、ユーザのリモート接続先電話機から発信されたビジネス コールのためにアクセスする必要のあるすべてのパーティションが含まれていることを確認してください。ローカル ルート グループを持つ回線だけの従来のアプローチを使用する +E.164 ダイヤル プランでは、この CSS は必要なく、 <None> に設定できます。

再ルーティング コーリング サーチ スペース

この設定によって、ユーザのリモート接続先電話機にコールが送信されたときにアクセスするパーティションが決定されます。このことは、すべてのモバイル コネクト コールに当てはまります。ユーザの会社の電話番号へのコールもモバイル コネクト経由でユーザのリモート接続先に送信される場合は、この CSS によってシステムからリモート接続先電話機に到達する方法が決定されます。したがって、CSS を通して、PSTN またはモバイル ボイス ネットワークに到達するために、適切なルート パターンとゲートウェイを含むパーティションにアクセスできる必要があります。

リモート接続先プロファイル ルーティング CSS を設定する場合は、この CSS 内のルート パターンが、ユーザのデスクトップフォンへの着信コールを経路設定するゲートウェイと同じコール アドミッション制御ロケーションにあるゲートウェイを指すようにすることを推奨します。これによって、コールをリモート接続先に経路設定するときに、2 地点間の帯域幅不足によるコール アドミッション制御拒否が発生しなくなります。さらに、WAN 帯域幅が不十分な場合は、初期モバイル コネクト コールの経路設定後のコール アドミッション制御チェックで拒否されないため、同じコール アドミッション制御ロケーション内のゲートウェイに着信コール レッグと発信コール レッグを経路設定することによって、このコール中の以降のデスクトップフォンまたはリモート接続先のピックアップ動作で WAN 帯域幅のオーバーサブスクリプションが発生する可能性のあるコール アドミッション制御の必要がなくなることが保証されます。

標準ローカル ルート グループを使用するルート リストを指すルート パターンを使用する場合は、発信者のデバイス プールで設定されたローカル ルート グループが使用されます。この場合リモート接続先へのコール レッグの出力ゲートウェイは、元の発信側デバイスに対してローカルです。PSTN からのコールの場合、これは、元の発信者(この場合、着信ゲートウェイ)と同じコール アドミッション制御ロケーションで出力ゲートウェイを使用する上記の要件を満たすのに役立ちます。

同様に、2 段階ダイヤリング対象コールを送信したときのコール アドミッション制御拒否が最小化されるようにすることも同様に重要です。2 段階ダイヤリング対象コールのコール アドミッション制御拒否は、発信コール レッグをルーティングするために使用される出力ゲートウェイが着信コール レッグの入力ゲートウェイによって選択されるようにローカル ルート グループ コンストラクトを使用することによって最小化、または回避できます。この方法で、使用される入力ゲートウェイおよび出力ゲートウェイは、同じコール アドミッション制御ロケーションにあるようになります。また、リモート接続先プロファイルのデバイス レベルの CCS 内のルート パターンは、モバイル ボイス アクセス システムまたはエンタープライズ機能アクセス システムのアクセス番号への着信コール レッグを処理した入力ゲートウェイと同じコール アドミッション制御ロケーションにある出力ゲートウェイを指す必要があります。ただし、デスクトップフォンがモバイル ボイス アクセスまたはエンタープライズ機能アクセス システムのアクセス番号が転送されるゲートウェイとは異なるコール アドミッション制御ロケーション内に存在する場合は、以降のデスクトップフォンのピックアップによって、WAN 帯域幅のオーバーサブスクリプションが発生する可能性があることに注意してください。

自動発信者 ID 照合とエンタープライズ コール アンカリング

理解しておく必要のある Unified Mobility ダイヤル プランのもう一つの側面は、設定済みのリモート接続先電話機からの着信コールに対する自動発信者 ID 識別に関するシステム動作です。着信コールがシステムに入ると、そのコールに対して提供された発信者 ID が設定済みのすべてのリモート接続先電話機と比較されます。一致するものが見つかった場合は、そのコールが自動的にその会社のものにアンカーされるため、ユーザは通話切替機能を呼び出したり、通話中のコールをデスクトップフォンでピックアップできます。この動作は、着信コールがモバイル ボイス アクセスまたはエンタープライズ機能アクセスを使用したモビリティ コールとして開始されていない場合でも、モビリティ ユーザのリモート接続先電話機からの着信コールすべてに対して行われます。


) 設定済みのリモート接続先番号に対する自動着信コール発信者 ID 照合は、Matching Caller ID with Remote Destination サービス パラメータが Partial Match と Complete Match のどちらに設定されているかの影響を受けます。この設定に関する詳細については、「リモート接続先の設定と発信者 ID の照合」を参照してください。


自動エンタープライズ コール アンカリングに加えて、設定済みのリモート接続先電話機から会社に電話がかかった場合の着信コール ルーティングと発信コール ルーティングも考慮する必要があります。設定済みのリモート接続先からのコールに対する着信コール ルーティングは、Inbound Calling Search Space for Remote Destination サービス パラメータの設定によって次の 2 つの方法のどちらかで発生します。デフォルトで、このサービス パラメータは、 Trunk or Gateway Inbound Calling Search Space に設定されます。このサービス パラメータがデフォルト値に設定されている場合は、設定済みのリモート接続先からの着信コールが、PSTN ゲートウェイの着信コーリング サーチ スペース(CSS)またはコールが入るトランクを使用して経路設定されます。一方、Inbound Calling Search Space for Remote Destination パラメータが Remote Destination Profile + Line Calling Search Space に設定されている場合は、リモート接続先からの着信コールが、PSTN ゲートウェイの着信 CSS またはトランクをバイパスして、代わりに、リモート接続先プロファイル CSS(と回線レベル CSS の組み合わせ)を使用して経路設定されます。

リモート接続先電話機からの着信コールの特性を考えると、このような着信コールへのアクセスを社内の電話機に到達させるために必要なすべてのパーティションに提供するためには、コーリング サーチ スペースが適切に設定されていることを確認する必要があります。これによって、リモート接続先電話機からの適切なコール ルーティングが保証されます。


) 設定済みのリモート接続先電話機からではない着信コールでは、必ず、トランクまたはゲートウェイ着信 CSS が使用されるため、Inbound Calling Search Space for Remote Destination サービス パラメータの影響を受けません。


モバイル ボイス アクセスまたはエンタープライズ機能アクセス コールの発信コール ルーティングでは、必ず、リモート接続先プロファイル回線 CSS とデバイス レベル CSS を連結したものが使用されるため、オフネットまたは PSTN アクセスに必要なすべてのルート パーティションへのアクセスを提供するためには、これらのコーリング サーチ スペースが適切に設定されていることを確認する必要があります。これによって、リモート接続先電話機からの適切な発信コール ルーティングが保証されます。

Intelligent Session Control およびすべてのシェアド ライン呼び出し

Intelligent Session Control 機能を使用すると、設定されたリモート接続先番号への社内からの直接コールを、自動的にコール アンカリングできます。通常、モビリティ コール アンカリングは、ユーザの会社の電話番号にかけられたコール、またはユーザの会社の電話番号からかけられたコールでだけ行われます。エンタープライズ 2 段階ダイヤリングによって外部から発信されたコールは、内部コールとしてルーティングされるため、システムはアンカリングを行います。Intelligent Session Control 機能を有効にすると、社内から設定済みリモート接続先への直接コールもアンカリングが行われます。

この機能は、Reroute Remote Destination Calls to Enterprise Number サービス パラメータを True に設定することによって有効にします。デフォルトで、このサービス パラメータは False に設定されており、この機能は無効になっています。この機能を有効にすると、ダイヤルされたリモート接続先へのコールが PSTN 経由でルーティングされるだけでなく、コールが自動的に会社のゲートウェイ内部でアンカリングされます。このタイプのコールをアンカリングすることによって、着信側モバイル ユーザが通話切替機能およびデスクトップフォンのピックアップまたはセッション ハンドオフを呼び出すことができるようになります。

たとえば、Intelligent Session Control 機能が有効にされており、モビリティ対応ユーザのリモート接続先番号が携帯の番号に対応する 408 555 1234 として設定されているとします。別のユーザがデスクトップフォンからそのモビリティ対応ユーザのリモート接続先番号(408 555 1234)にダイヤルすると、そのコールは PSTN 経由でリモート接続先にルーティングされ、同時に会社のゲートウェイでアンカリングされます。コールがセットアップされてアンカリングされると、着信側モビリティ対応ユーザは、保留、転送、会議などの通話切替機能を呼び出したり、デスクトップフォンのピックアップまたはセッション ハンドオフを実行したりできるようになります。

この同じ例で、Intelligent Session Control 機能が無効であるとすると、システム ユーザがこのモビリティ対応ユーザのリモート接続先に社内のデスクフォンから直接ダイヤルした場合、そのコールは PSTN 経由で着信側リモート接続先にルーティングされますが、アンカリングはされません。その結果、モバイル ユーザは、保留や転送などの通話切替機能を呼び出したり、デスクトップフォンのピックアップまたはセッション ハンドオフを実行したりできません。

この機能を有効にする場合は、ダイヤル プランの設定およびコール ルーティングへの影響を理解することが重要となります。この機能を呼び出すには、内部ユーザが PSTN のリモート接続先番号に到達するためにダイヤルする番号(必要なすべての PSTN 振り分け用数字を含む)は、システムに設定されているリモート接続先(またはモビリティ ID)番号と一致する必要があります。たとえば、リモート接続先番号がシステムに 408 555 1234 と設定されており、通常、発信する番号に加えて PSTN 振り分け用数字 91 を内部ユーザがダイヤルする必要がある場合は、再ルーティングおよびそれによるエンタープライズ コール アンカリングは実行されません。これは、ユーザが PSTN のリモート接続先に到達するために 91 408 555 1234 をダイヤルした一方、リモート接続先は 408 555 1234 と設定されており、これらの番号が一致しないためです。

この機能が適切に機能するには、設定されたリモート接続先と、PSTN のこのリモート接続先に到達するためにダイヤルする必要がある番号とが一致する必要があります。これらの番号が一致するようにするには、Matching Caller ID with Remote Destination サービス パラメータを Partial Match に設定します。このパラメータを Partial Match に設定し、Number of Digits for Caller ID Partial Match サービス パラメータを使用して部分一致対象桁数を指定することによって、ダイヤルされた番号に PSTN 振り分け用数字が含まれていても、設定されたリモート接続先番号とダイヤルされた番号が一致します。

前の例を使用し、システムが 10 桁の部分一致を使用するように設定されているとすると、ダイヤルされた番号 9 1 408 555 1234 は、設定されたリモート接続先 408 555 1234 に一致します。これは、部分一致では、Number of Digits for Caller ID Partial Match に指定された桁数(この場合は 10 桁)が照合されるためです。2 つの番号は、右から左に向かって照合されます。ダイヤルされた番号 9 1 408 555 1234 の最後の 10 桁は 408 555 1234 であり、この 10 桁が、10 桁の設定されたリモート接続先(408 555 1234)に一致します。この例では、発信コールは社内でアンカーされ、着信側モバイル ユーザは通話切替機能を呼び出したり、デスクトップフォンのピックアップまたはセッション ハンドオフを実行したりできます。

この機能を使用する場合、一見すると、必要なすべての PSTN 振り分け用数字を含むリモート接続先番号またはモビリティ ID 番号を設定する方が簡単に見えます。しかし、必要な PSTN 振り分け用数字を含む番号を設定し、発信者 ID の部分一致を設定していない場合、設定されたリモート接続先またはモビリティ ID からの着信コールに対して発信者 ID の自動照合およびエンタープライズ アンカリングを実行できません。前の例では、リモート接続先番号が 9 1 408 555 1234 と設定されており、発信者 ID の完全一致が使用されている場合、リモート接続先からの着信コールの発信者 ID は 408 555 1234 となり、これらの番号が一致せず、リモート接続先からの着信コールが想定どおりにアンカリングされません。

このように発信コールでダイヤルされる Intelligent Session Control 機能を使用する場合には、番号と、着信コールの設定されたリモート接続先番号が異なる可能性があるため、PSTN に到達するために 1 つ以上の振り分け用数字が必要なすべての配置において、発信者 ID の(完全一致ではなく)部分一致を有効にすることを推奨します。これにより、PSTN 振り分け用数字を使用してリモート接続先番号に直接発信されたコールが一致し、アンカーされるようになります。一方で、PSTN に到達するために振り分け用数字が必要なく、ユーザが完全な E.164 番号をダイヤルして PSTN にコールをルーティングできる場合には、発信者 ID と照合されるリモート接続先の番号が、PSTN のリモート接続先またはモビリティ ID に到達するために内部ユーザがダイヤルする番号と同じであるため、発信者 ID の完全一致設定を使用することを推奨します。

Intelligent Session Control 機能を有効にする場合は、再ルーティング機能の実行時の、会社の回線およびリモート接続先回線の動作を理解することも重要です。コールの再ルーティングでは、Do Not Disturb(DND)、Access Lists と Time of Day コール フィルタリング、および Delay Before Ringing Timer の各リモート接続先回線設定は無視されます。再ルーティングされるすべてのコールは、フィルタリングされずにすぐにルーティングされます。会社のデスクトップフォン回線設定も、デフォルトで無視されるか、またはバイパスされます。ただし、Ignore Call Forward All on Enterprise DN サービス パラメータを False に設定することによって、再ルーティング機能の実行時に会社のデスクトップフォン回線の Call Forward All 設定を有効にできます。このパラメータが False に設定されている場合、会社のデスクトップフォン回線に Call Forward All の接続先が設定されていると、再ルーティングの実行時にコールはリモート接続先にルーティングされません。代わりに、コールは Call Forward All の接続先にルーティングされます。デフォルトで、このサービス パラメータは True に設定されており、会社のデスクトップフォン回線の Call Forward All 設定は無視されます。

Intelligent Session Control 機能は、すべてのシェアド ライン呼び出し機能を使用することによって、さらに強化できます。この機能は、すべてのシェアド ライン呼び出しサービス パラメータを True に設定することによって有効になります。デフォルトで、このサービス パラメータは True に設定されており、この機能は有効になっています。ただし、すべてのシェアド ライン呼び出し機能は Intelligent Session Control 機能に依存しており、この機能も、すべてのシェアド ライン呼び出し機能を使用するときに順番に有効にする必要があります。すべてのシェアド ライン呼び出し機能、Intelligent Session Control 機能の両方を有効にすると、システムが内部で発信されたコールをダイヤル対象リモート接続先に PSTN でルーティングさせるだけでなく、ユーザの他のシェアド ライン デバイスもすべて、コールを受信します。これには、ユーザの会社のデスクフォンおよび他の設定済みリモート接続先が含まれます。呼び出されたユーザは、デバイス上で着信コールに応答でき、コールは会社にアンカーされます。


) すべてのシェアド ライン呼び出しが有効であるときに、モバイル クライアント デバイスは、デバイスが Unified CM に登録されている場合にはデバイスの携帯電話音声インターフェイスでコールを受信しません。


発信者 ID 変換

設定済みのリモート接続先番号によってクラスタに発信されたコールは、自動的に、発信者 ID または発呼側番号が、発信元のリモート接続先電話機の番号から関連する会社のデスクトップフォンの番号に変更されます。たとえば、408 555-7890 という番号のリモート接続先電話機が設定され、555-1234 という番号の会社のデスクトップフォンに関連付けられている場合は、クラスタ内の任意の電話番号に向けられたユーザのリモート接続先電話機からのコールがすべて、自動的に、発信者 ID が 408 555-7890 のリモート接続先電話番号から 555-1234 の会社の電話番号に変更されます。これによって、アクティブ コールの発信者 ID 表示とコール履歴ログの発信者 ID に、ユーザの携帯電話の番号ではなく、会社の卓上電話の番号が反映され、すべての返信コールがユーザの会社の電話番号に対して発信され、このようなコールが会社にアンカリングされることが保証されます。

同様に、リモート接続先電話機から外部の PSTN 接続先へのコールと、モバイル ボイス アクセスやエンタープライズ機能アクセス 2 ステージ ダイヤリング経由で会社にアンカーされたコール、つまり、モバイル コネクトの結果として PSTN に分岐されたコールも、発信者 ID が発信元のリモート接続先電話機の番号から関連する会社の電話番号に変更されます。

最後に、発呼側番号を会社の電話番号ではなく、会社の DID 番号として外部の PSTN 電話機に供給する場合は、発信側のトランスフォーメーション パターンを使用できます。発信側のトランスフォーメーション パターンを使用して発信者 ID を会社の電話番号から会社の DID に変換することによって、外部の接続先からの返信コールは、完全な会社の DID 番号でダイヤルされていることから、その会社にアンカーされます。このような変換とダイヤル プランの意味については、「Cisco Unified Mobility 固有の考慮事項」を参照してください。

Unified Mobility に関するガイドラインと制約事項

次のガイドラインと制約事項は、Unified CM テレフォニー環境内のモバイル コネクトの配置と動作に関連して適用されます。

モバイル コネクトは、PRI TDM PSTN 接続でだけサポートされます。T1 接続または E1-CAS、FXO、FXS、および BRI PSTN 接続はサポートされません。この PRI 要件は、完全な機能サポートを保証するためには、Cisco Unified CM で PSTN からの迅速な応答と切断の指示を受信する必要があることに基づいています。応答指示は、モバイル コネクト コールが特定のリモート接続先で応答されたときに、Cisco Unified CM でデスクトップフォンとその他のリモート接続先の呼び出しを停止するために必要です。加えて、応答指示は、シングル企業ボイスメール ボックス機能をサポートするために必要です。最後に、切断指示はデスクトップフォンピックアップのために必要です。PRI PSTN 接続では、必ず、応答指示または切断指示が提供されます。

Cisco IOS Unified Border Element によって Unified CM SIP トランクとサービス プロバイダー トランクとの間に境界ポイントが提供されており、通話切替機能(またはその他の DTMF 依存の機能)が使用されていない場合には、SIP トランク VoIP PSTN 接続でもモバイル コネクトがサポートされます。VoIP PSTN 接続では、通話切替機能はサポートされません。VoIP ベースの PSTN 接続では、VoIP ベースの PSTN 接続によって提供されるエンドツーエンドのシグナリング パスによって、Unified CM に迅速な応答と切断の指示を提供できます。

モバイル コネクトでは、ユーザあたり最大 2 つの同時コールをサポートできます。それ以上の着信コールは、自動的に、ユーザのボイスメールに転送されます。

モバイル コネクトは、Multilevel Precedence and Preemption(MLPP)と連動しません。コールが MLPP によって割り込まれた場合は、そのコールに対するモバイル コネクト機能が無効になります。

モバイル コネクト サービスでは、ビデオ コールに応答できません。デスクトップフォンで受信されたビデオ コールは携帯電話でピックアップできません。

Unified CM の強制承認コード(FAC)機能とクライアント識別コード(CMC)機能が、モバイル ボイス アクセスまたはエンタープライズ機能アクセスと連動しません。

リモート接続先は、別のクラスタまたはシステム上の時分割多重(TDM)装置またはオフシステム IP フォンにする必要があります。IP フォンは、リモート接続先と同じ Unified CM クラスタ内に設定できません。

ガイドラインと制約事項の詳細については、次の Web サイトで入手可能な『 Cisco Unified Communications Manager Features and Services Guide 』の最新版で Cisco Unified Mobility に関する情報を参照してください。

http://www.cisco.com/en/US/products/sw/voicesw/ps556/prod_maintenance_guides_list.html

Cisco Unified Mobility のキャパシティ プランニング

Cisco Unified Mobility は、Unified CM クラスタあたり最大 15,000 のリモート接続先またはモビリティ ID をサポートします。モビリティ対応ユーザの最大数は、ユーザあたり 1 つのリモート接続先またはモビリティ ID を想定すると、15,000 人のユーザになります。ユーザあたりのリモート接続先数またはモビリティ ID 数が増加するほど、サポートされるモビリティ対応ユーザ数が減少します。


) モビリティ対応ユーザは、リモート接続先プロファイルを持ち、1 つ以上のリモート接続先またはモビリティ ID が設定されているユーザとして定義されます。



) モビリティ ID は、システム内でリモート接続先と同様に設定され、リモート接続先と同じ容量になります。ただし、リモート接続先と違って、モビリティ ID は、リモート接続先プロファイルではなく、直接電話機に関連付けられます。モビリティ ID は、Cisco Jabber などのモバイル クライアント デバイスだけに適用されます。


Cisco Unified Mobility の拡張性と性能は、モビリティ ユーザ数、ユーザごとのリモート接続先数またはモビリティ ID 数、およびそれらのユーザの最繁時呼数(BHCA)レートに依存します。ユーザあたりの複数のリモート接続先またはユーザあたりの高い BHCA によって、Cisco Unified Mobility の容量が減少することがあります。Unified CM サーバ ノードのキャパシティ、およびハードウェア固有のノードあたりとクラスタあたりのキャパシティを含む Cisco Unified Mobility のサイジングの詳細については、「コラボレーション ソリューションの設計および配置サイジングに関する考慮事項」の章を参照してください。

Cisco Unified Mobility の設計上の考慮事項

Unified Mobility を配置する場合は、次の設計上の推奨事項に従ってください。

PSTN ゲートウェイ プロトコルで、アウトオブバンド DTMF リレーが使用できる、または、インバンド DTMF をアウトオブバンド DTMF に変換するための Media Termination Point(MTP; メディア ターミネーション ポイント)が割り当てられていることを確認します。 PSTN 接続用の Cisco IOS ゲートウェイを使用している場合は、アウトオブバンド DTMF リレーがサポートされます。ただし、サードパーティ製ゲートウェイでは、一般的なアウトオブバンド DTMF 方式がサポートされない可能性があるため、結果として、MTP が必要になる場合があります。 エンタープライズ機能アクセス 2 ステージ ダイヤリング機能と通話切替機能を使用するには、Cisco Unified CM で DTMF 番号をアウトオブバンドで受信する必要があります。


) インバンド DTMF をアウトオブバンド DTMF に変換するために MTP 上でリレーする場合は、十分な MTP 容量が提供されることを確認してください。エンタープライズ機能アクセス 2 ステージ ダイヤリングまたは通話切替機能の高い使用頻度が予想される場合は、ハードウェア ベースの MTP または Cisco IOS ソフトウェア ベースの MTP を推奨します。


Unified Mobility を配置する前に、PSTN プロバイダーと連携して次のことを保証する必要があります。

会社へのすべての着信コールに関する発信者 ID が、サービス プロバイダーから供給される。これは、エンタープライズ機能アクセス 2 ステージ ダイヤリングまたは通話切替転送、会議、およびダイレクト コール パーク機能が必要な場合の要件です。

発信コールの発信者 ID は、サービス プロバイダーに制限されない。これは、モビリティ対応ユーザが、一般的な会社のシステム番号やその他の意味のない発信者 ID ではなく、リモート接続先にいる元の発信者の発信者 ID を受信することが期待される場合の要件です。


) プロバイダーによっては、トランク上の発信コールの発信者 ID が、そのトランクで処理される DID に制限される場合があります。そのため、発信者 ID が制限されない別の PRI トランクをプロバイダーから入手する必要があります。無制限の PRI トランクを要求すると、プロバイダーによっては、このトランク経由で緊急電話番号にコールを送信または発信しないことが記された署名付きの同意書を要求される場合があります。



) プロバイダーによっては、[Redirected Dialed Number Identification Service (RDNIS)] フィールドまたは SIP の Diversion ヘッダーにトランクで処理される DID が含まれている限り、そのトランクには発信コールの発信者 ID を無制限で許可します。ゲートウェイまたはトランクの設定ページで [Redirecting Number IE Delivery] > [Outbound] チェックボックスをオンにすることによって、リモート接続先に分岐されたコールの RDNIS または SIP の Diversion ヘッダーにユーザの企業番号を取り入れることができます。RDNIS または SIP の Diversion ヘッダーに対応し、発信コールの発信者 ID を無制限で許可しているかどうかは、サービス プロバイダーに問い合わせてください。


一般に、モビリティ コール フローには複数の PSTN コール レッグが含まれるため、Unified Mobility にとって PSTN ゲートウェイ リソースの計画と配置がきわめて重要です。モビリティ対応ユーザ数が多い場合は、PSTN ゲートウェイ リソースを増やす必要があります。PSTN 利用を制限または削減するために、次の方法が推奨されています。

モビリティ対応ユーザあたりのリモート接続先数を 1 つに制限します。これによって、着信コールをユーザのリモート接続先に転送するために必要な DS0 数が削減されます。コールがユーザの会社の電話番号に送られると、そのコールがリモート接続先のいずれかで応答されなくても、設定済みのリモート接続先ごとに 1 つずつの DS0 が消費されます。コールがリモート接続先で応答されなくても、リモート接続先あたり 1 つの DS0 が 10 秒間も使用される可能性があります。

アクセス リストを使用して、着信コールの発信者 ID に基づいて、特定のリモート接続先へのコールの拡張を拒否または制限します。時刻に基づいてアクセス リストを呼び出すことができるため、エンド ユーザまたは管理者がアクセス リストを頻繁に更新する必要がありません。

不要になったモバイル コネクトを無効にしたり、会社の番号に電話がかけられた場合の DS0 の使用をさらに制限するようにエンド ユーザを教育します。モバイル コネクトが無効になっている場合は、着信コールでデスクトップフォンの呼出音が鳴りますが、誰も電話に出なければ、そのコールが会社のボイスメールに転送されます。

ロケーション間の WAN 帯域幅の不足によってコール アドミッション制御が拒否される可能性と、デスクトップフォンのピックアップまたはリモート接続先のピックアップによって WAN 帯域幅のオーバーサブスクリプションが発生する可能性があるため、リモート接続先プロファイル CSS と CSS の再ルーティングを設定して、CSS 内のルート パターンが、着信コール レッグが到達するゲートウェイと同じコール アドミッション制御ロケーション内に配置されたゲートウェイを指すようにすることを推奨します。詳細については、「リモート接続先プロファイルの設定」を参照してください。

公衆網にアクセスするために公衆網振り分け用数字をダイヤルする必要がある配置において Intelligent Session Control 機能を有効にする場合は、Matching Caller ID with Remote Destination サービス パラメータを Partial Match に設定し、適切な桁数(Number of Digits for Caller ID Partial Match サービス パラメータ)を設定して、設定されたリモート接続先またはモビリティ ID の部分一致が実行されるようにすることを推奨します。これにより、Intelligent Session Control 機能、およびモビリティの発信者 ID の自動照合機能とアンカリング機能が適切に機能するようになります。

Unified CM および Cisco VCS の両方を統合した配置では、管理者は、シングル ナンバー リーチ機能のみを 1 つだけ有効にする必要があります。つまり、Unified CM のモバイル コネクトまたは VCS の FindMe のいずれか一方を有効にする必要がありますが、両方を有効にする必要はありません。

シスコの Cisco Mobile クライアントおよびデバイス

モバイル ユーザ、携帯電話、携帯通信事業者サービスが普及するにつれて、単一のデバイスを使用して社内および社外の両方で音声、ビデオ、およびデータ サービスを使用できることがますます魅力的なソリューションとなっています。デュアル モード スマート フォン、およびそのスマート フォンで実行されるクライアントなどのモバイル デバイスは、企業に対して、カスタマイズされた音声、ビデオ、およびデータ サービスを社内にいながらユーザに提供する機能、および一般的な音声およびデータ サービスの代替の接続方法としてモバイル通信事業者ネットワークを利用する機能を利用可能にします。社内で音声、ビデオ、およびデータ サービスを利用可能にし、モバイル クライアント サービスに対してネットワーク接続を提供することによって、企業はこれらのサービスをローカルでより安価な接続コストで提供できます。たとえば、企業ネットワーク上で発信される Voice over IP(VoIP)コールは、通常、モバイル ボイス ネットワーク上で発信される同じコールよりもコストが少なく済みます。

Voice and Video over IP(VVoIP)機能に加えて、これらのモバイル クライアントとデバイスによって、モバイル ユーザは他のバック エンドのコラボレーション アプリケーションとサービスにアクセスできます。 シスコ モバイル クライアントとサービスを通じて利用可能なサービスおよびアプリケーションには、会社のディレクトリ、会社のボイス メール、および XMPP ベースの IM(インスタント メッセージング)とプレゼンスが含まれます。さらに、ユーザがモバイル コネクト、モバイル ボイス アクセスまたはエンタープライズ機能アクセスを介したエンタープライズ 2 段階ダイヤリング、および 1 つの企業ボイスメール ボックスなどのモバイル デバイスで追加機能を利用できるように、これらのクライアントおよびデバイスは Cisco Unified Mobility とともに配置できます。

この項では、モバイル クライアントのアーキテクチャについて説明します。また、企業の WLAN ネットワークとモバイル ボイス ネットワークとの間でアクティブなボイスコールを移動する場合のリモート セキュア接続およびハンドオフに関する考慮事項を含む、シスコのモバイル クライアントとデバイスによって提供される共通の機能について説明します。一般的なモバイル クライアント ソリューション アーキテクチャおよび機能について説明した後、ここでは、次の特定のモバイル クライアントとデバイスのさまざまな機能および統合に関する考慮事項について説明します。

Cisco Jabber:Android および iPhone や iPad などの iOS モバイル デバイス用のモバイル クライアント一式であり、企業の WLAN ネットワークの IP 経由、またはモバイル データ ネットワーク経由で音声またはビデオ コールを発信する機能、ならびに社内ディレクトリと企業ボイスメール サービス、および XMPP ベースの企業向け IM およびプレゼンスにアクセスする機能を提供します。

Cisco WebEx 会議:Android、Blackberry および iPhone や iPad などの Apple iOS デバイス向けの一連のモバイル クライアントであり、ユーザが移動中に Cisco WebEx 会議に出席、参加できるようになります。

Cisco AnyConnect Mobile:Android および Apple iOS デバイスで使用可能なモバイル クライアントであり、ユーザが企業外にいる場合でも、オンプレミス コラボレーション アプリケーションおよびサービスへのアクセスに対して、企業が安全にリモートから接続できるようにします。

また、シスコのモバイル クライアントとデバイスのハイ アベイラビリティおよびキャパシティ プランニングの考慮事項についても説明します。

シスコのモバイル クライアントおよびデバイスのアーキテクチャ

シスコのモバイル クライアントは、IP ベースのネットワーク接続機能(IEEE 802.11 無線ローカル エリア ネットワークまたはモバイル プロバイダーのデータ ネットワーク)およびデュアル モード電話機だけを備えたタブレットおよびハンドヘルド デバイスなどのさまざまなモバイル デバイスで配置されます。デバイスが従来のセルラーまたはモバイル ネットワーク テクノロジーによってモバイル ボイス ネットワークとデータ キャリア ネットワークの両方に接続でき、また、802.11 を使用してワイヤレス ローカルエリア ネットワーク(WLAN)に接続できる 2 つの物理インターフェイスが含まれます。シスコのモバイル クライアントとデバイスは、802.11 WLAN 経由でのオンプレミス データおよびリアルタイム トラフィック(音声およびビデオ)接続を可能にします。また、これらのクライアントおよびデバイスは、パブリックまたはプライベートの WLAN 経由、またはモバイル データ ネットワーク経由で企業へのリモート データおよびリアルタイム トラフィック(音声およびビデオ)接続を提供します。プロバイダーの携帯電話音声の無線を備えたデバイスでは、音声接続がモバイル ボイス ネットワークおよび PSTN 経由で有効にされることもあります。


) この項でデュアルモード電話機という用語を使用する場合、802.11 に準拠した無線機、および音声とデータの通信事業者ネットワークへの接続用の携帯電話無線機を備えたデバイスを指します。Digital Enhanced Cordless Telecommunications(DECT)やその他の規格に準拠した無線機、または複数の携帯電話無線機を備えたデュアルモード デバイスは、この項のデュアルモード電話機には含まれません。


図 23-23 は、Cisco Unified Communications システムにモバイル クライアント デバイスを接続する場合の基本的な Cisco モバイル クライアントおよびデバイスのソリューション アーキテクチャを示します。音声サービスとビデオ サービスの場合は、モバイル クライアント デバイスが企業の WLAN に関連付けられるか、インターネットに(パブリックまたはプライベートから WLAN ホット スポットまたはモバイル データ ネットワークから)接続され、シスコのモバイル クライアントは、Session Initiation Protocol(SIP)を使用して会社の電話機として Cisco Unified CM に登録されます。また、一部のモバイル クライアントは、代わりに Cisco Video Communications System(VCS)に SIP を使用するビデオ エンドポイントとして登録される場合があります。登録されると、クライアント デバイスは、基礎となる企業の Cisco IP テレフォニー ネットワークを利用して、コールを発信および受信します。モバイル デバイスが企業ネットワークに接続されており、かつクライアントが Unified CM に登録されている場合、そのデバイスはユーザが持つ会社の電話番号を使用して発着することができます。ユーザの会社の電話番号に着信コールがあると、モバイル クライアント デバイスの呼出音が鳴ります。ユーザが Cisco IP デスクフォンを持っている場合は、モバイル クライアントを登録すると、ユーザの会社の番号でシェアド回線インスタンスが使用可能になり、コールが着信すると、ユーザのデスクフォンとモバイル デバイスの両方の呼出音が鳴ります。モバイル クライアント デバイスが Unified CM に登録されていない場合で、かつ条件を満たしていない場合(携帯電話網へ接続している、ユーザが Cisco Unified Mobility を有効にしている、ユーザの携帯電話番号に対してモバイル コネクトを有効にしている)、会社の番号で着信しない場合があります。このようなシナリオではモバイル ボイス ネットワークおよび PSTN は音声のみのコールの発信および受信に使用されます。

モバイル コネクトなどの Unified Mobility 機能は、携帯電話音声の無線を持たないタブレットや他のモバイル クライアント デバイスと互換性がありません。その理由は、これらの非デュアル モードのデバイスはネイティブ PSTN の到達可能番号を持たないためです。非デュアル モードのデバイスは、企業に接続してエンタープライズ呼制御システムに登録される場合だけ、エンタープライズ コールを発信および受信できます。

図 23-23 に示すように、シスコのモバイル クライアントとデバイスは、企業に接続されると、LDAP 社内ディレクトリ、Cisco Unity Connection 企業ボイス メール システム、およびメッセージングやプレゼンスなどの追加エンタープライズ ユニファイド コミュニケーション サービスにアクセスするための Cisco IM and Presence サービスなどの他のバック エンド アプリケーション サーバと直接通信することもできます。シスコのモバイル クライアントとデバイスは、IM およびプレゼンス、ポイントツーポイント IP コール、および Web Conferencing サービスを提供する Cisco WebEx などのクラウドベースのコラボレーション サービスとも統合します。

図 23-23 シスコのモバイル クライアントおよびデバイスのアーキテクチャ

 


) コールの音声とビデオの品質は、Wi-Fi またはモバイル データ ネットワーク接続によって異なります。Cisco Technical Assistance Center(TAC)は、3G/4G モバイル データ ネットワークまたは非社内 Wi-Fi ネットワーク経由で接続または音声およびビデオ品質の問題を解決できません。


モバイル ボイス ネットワークとモバイル データ ネットワーク、および WLAN ネットワークの両方に同時に接続するために、デュアルモードのモバイル クライアント デバイスでは、デュアル転送モード(DTM)がサポートされている必要があります。デバイスで DTM がサポートされていると、デバイスの携帯電話無線機と WLAN インターフェイスの両方からデバイスに到達可能になり、両方のインターフェイスでコールを発信および受信できます。モバイル ボイス ネットワークおよびモバイル データ ネットワークでデュアル接続デバイスがサポートされていない場合には、適切なモバイル クライアント操作が実行できない場合があります。

ワイヤレス LAN ネットワーク インフラストラクチャを介した音声およびビデオ

さまざまなモバイル クライアント デバイス機能、およびこれらの機能がエンタープライズ テレフォニー インフラストラクチャに与える影響について考慮する前に、適切に調整され、QoS に対応し、ハイ アベイラビリティを備えた WLAN ネットワークを計画して配置することが重要です。デュアルモード電話機および他のモバイル デバイスは、重要なシグナリング トラフィック、コールのセットアップやさまざまなアプリケーションへのアクセスのためのその他のトラフィック、およびリアルタイムの音声とビデオのメディア トラフィックにおいて、基礎となる WLAN インフラストラクチャを利用するため、データ トラフィックおよびリアルタイムのメディア トラフィックの両方に最適化された WLAN ネットワークの配置が必要になります。WLAN ネットワークの配置が適切でないと、多くの干渉が発生し、容量が低下するため、音声とビデオの品質が低下するだけでなく、コールがドロップされたり、つながらなかったりする可能性もあります。このように展開された WLAN は、コールの発信および受信に使用できなくなります。したがって、デュアル モード フォンと他のモバイル デバイスを配置する場合は、Voice and Video over WLAN の配置が正常に行われるように、配置前、配置中、配置後に WLAN 無線周波数(RF)サイト サーベイを実施して、適切なセル境界、設定、機能設定、容量、および冗長性を判断する必要があります。実稼働環境への配置の前に、WLAN の配置に対してモバイル デバイスのデバイス タイプまたはクライアントごとにテストを実施して、統合および動作が適切に行われるようにする必要があります。Quality of Service を含む WLAN サービス(Cisco Unified Wireless Network など)経由の最適なリアルタイム トラフィックが提供されるように配置および設定された WLAN を使用することによって、モバイル クライアント デバイスを正常に展開できます。

シスコでは、可能な場合は、音声およびビデオ トラフィックを生成できるモバイル クライアントとデバイスを接続するための 5 GHz 帯域 WLAN を利用することを推奨します(802.11a/n)。5 GHz WLAN は、音声コールとビデオ コールに対し、スループットを改善して干渉を低減します。

Voice and Video over WLAN の配置およびワイヤレス デバイス ローミングの詳細については、「ワイヤレス デバイスのローミング」を参照してください。


) デュアルモード電話と他のモバイル クライアント デバイスは、インターネットを経由して会社に接続して呼制御やその他の Unified Communications サービスを利用できますが、シスコでは、このように接続した場合の音声とビデオの品質を保証できず、接続または音声とビデオの品質上の問題を解決できません。このような接続には、パブリックまたはプライベートの WLAN アクセス ポイント(AP)やホット スポット経由、あるいはモバイル データ ネットワーク経由の企業へのリモート接続があります。シスコでは、デュアル モード電話機およびその他のモバイル クライアント デバイスを接続するためのエンタープライズ クラスの音声およびビデオが最適化された WLAN ネットワークを推奨します。ほとんどのパブリックまたはプライベートの WLAN AP およびホット スポットは、データ アプリケーションおよびデバイスに合せて調整されています。この場合、AP 無線が最大電力に合わせて調整され、ダイナミック パワー コントロールにより、ネットワーク接続時にデバイスで最大電力が有効になり、クライアントの容量が大きくなります。このような調整方法は、パケットのドロップや損失時に再送信ができるデータ アプリケーションにとっては理想的ですが、パケットのドロップが大量に発生する可能性があるため、リアルタイム トラフィック アプリケーションでは音声とビデオの品質が非常に悪くなる可能性があります。同様に、モバイル プロバイダーのデータ ネットワークは、輻輳や接続のドロップの影響を受けやすいため、コール品質が低下したり、コールがドロップされる可能性があります。


クラウドベースまたはオフプレミスのコラボレーション インフラストラクチャ

Cisco WebEx、Cisco Collaboration クラウドベース インフラストラクチャは、ハードウェアを企業構内に配置する必要がないコラボレーション ソリューションです。すべてのサービス(音声、ビデオ、およびコンテンツ共有)は、インターネットまたはクラウドで安全にホストされます。これは、クライアントからのすべてのコンテンツ、音声とビデオのトラフィックがインターネットを通過し、WebEx データセンターのクラウド内で混合され管理されていることを意味します。オプションで、アグリゲーション サービス ルータ(ASR)向け Cisco WebEx ノードでは、クラウドの主要コンポーネントをオンプレミスに拡張することができます。

Cisco Collaboration クラウド インフラストラクチャは、モバイル クライアントとデバイスに対して、Web ベースの音声およびビデオ会議にコンテンツの共有を提供する WebEx Meeting や、ポイントツーポイントの音声およびビデオ コーリングと同時に XMPP ベースの IM およびプレゼンスを提供する WebEx Messenger などの WebEx 機能を提供します。

Cisco WebEx コラボレーション クラウド ベース インフラストラクチャの詳細については、「Cisco Collaboration サービス」の章を参照してください。

モバイル クライアントとデバイスの Quality of Service

シスコのモバイル クライアントのアプリケーションおよびデバイスは、シスコのコラボレーション QoS マーキング推奨事項に従って、一般にレイヤ 3 QoS パケット値をマークします。 表 23-3 は、これらのマーキングをまとめています。

 

表 23-3 シスコのモバイル クライアントのレイヤ 3 QoS マーキング

トラフィックのタイプ
レイヤ 3 マーキング
DSCP1
PHB2

音声メディア(音声のみ)

DSCP 46

PHB EF

ビデオ メディア(音声およびビデオ)

DSCP 34

PHB AF41

コール シグナリング

DSCP 24

PHB CS3

1.DiffServ コード ポイント

2.Per-hop behavior

シスコのモバイル クライアントのレイヤ 2 802.11 WLAN パケット マーキング(ユーザ プライオリティ、または UP)には、さまざまなモバイル プラットフォームおよびファームウェアの制約による課題があります。シスコのモバイル クライアントがさまざまなモバイル デバイスで実行されるため、レイヤ 2 ワイヤレス QoS が矛盾する場合があります。したがって、レイヤ 2 ワイヤレス QoS のマーキングを、WLAN のトラフィックを適切に処理するためには使用できません。Cisco Unified Wireless LAN Controller での配置では、ワイヤレス SIP コール アドミッション制御(CAC)を有効にすると、適切でないか、または存在しないレイヤ 2 WLAN マーキングに対する何らかの対策になる場合があります。 SIP CAC はメディア セッションのスヌーピングを使用し、ダウンストリームの音声およびビデオ フレームが適切に優先順位を付けられて処理できるようになります。

適切なモバイル クライアントのアプリケーション レイヤ 3 またはレイヤ 2 パケット マーキングにかかわらず、モバイル デバイスは、データおよびリアルタイム トラフィックの両方を含むさまざまなタイプのトラフィックの生成において、デスクトップ PC と同じさまざまな課題を示します。これを考えると、一般にモバイル デバイスはコラボレーション エンドポイントの信頼できないカテゴリに分類されます。モバイル クライアント デバイスが信頼されているエンドポイントとして見なされない配置では、ネットワークのプライオリティ キューイングと専用帯域幅が適切なトラフィックに適用されるようにするために、トラフィック タイプとポート番号に基づいてパケット マーキングまたは再マーキングすることが必要です。モバイル デバイスのトラフィックを再マーキングするだけでなく、ネットワーク ベースのポリシングとレート制限を使用してモバイル クライアント デバイスが大量のネットワーク帯域幅を消費しないようにすることを推奨します。

また、シスコのモバイル クライアントのレイヤ 3 マーキングが適切で、モバイル クライアント デバイスが信頼されているとすると、シスコのモバイル クライアントのトラフィックは、プライオリティの音声キューイングおよび専用ビデオ メディアとコール シグナリング帯域幅キューを使用して企業ネットワークを通過すると、適切にキューに入ります。

シスコのモバイル クライアントおよびデバイスの性能と機能

シスコのモバイル クライアントおよびデバイスは、さまざまな性能と機能が用意されます。性能や動作はデバイスによって異なりますが、この項で説明する共通の動作はすべてのシスコのモバイル クライアント デバイスに適用されます。

エンタープライズ コール ルーティング

シスコのモバイル クライアントとデバイスが企業のテレフォニー インフラストラクチャおよび呼制御サービスを使用してコールを発信および受信できるため、モバイル クライアント デバイスに関係するコール ルーティングの性質と動作を理解することが重要です。

着信コール ルーティング

モバイル クライアントとデバイスが会社の電話番号を持つエンタープライズ デバイスとして Unified CM に登録すると、モバイル デバイスは、システムへの着信コールがユーザの会社の電話番号宛てである場合に呼出音が鳴ります。これは、PSTN または他の Unified CM クラスタや企業 IP テレフォニー システムから発信された着信コール、および同じ Unified CM 内の他のユーザから発信された着信コールにおける動作です。モバイル クライアント デバイスのユーザは、会社の電話番号に関連付けられている他のデバイスまたはクライアントを持っている場合には、これらのデバイスもシェアド ラインとして呼び出されます。コールがいずれかのデバイスまたはクライアントで応答されると、他のすべてのデバイスおよびクライアントの呼出音は停止します。

ユーザに対して Cisco Unified Mobility が有効になっており、ユーザのデュアルモード携帯電話の番号でモバイル コネクトまたはシングル ナンバー リーチが有効になっているシナリオにおいては、着信コールはユーザの携帯電話の番号に対応するモビリティ ID に転送される場合があります。ただし、これは、モバイル デバイスが企業の WLAN ネットワークに接続されているか、セキュアな VPN 経由で企業ネットワークに接続され、Unified CM に登録されているかによって異なります。デバイスが企業ネットワークに直接接続されているか、セキュア リモート接続を介して接続されている場合には、携帯の番号でモバイル コネクトがオンになっていても、ユーザの会社の電話番号への着信コールは、モバイル コネクトによってモバイル デバイスのモビリティ ID に転送されません。Unified CM に登録されている場合にデュアルモード モバイル デバイスのモビリティ ID に会社の電話番号への着信コールが転送されない理由は、デバイスが企業ネットワークに接続され、利用可能であるということがシステムによって認識されるためです。したがって、企業の PSTN リソースの利用を少なくするために、Unified CM では、PSTN を経由してデュアルモード携帯電話のモバイル ボイス ネットワーク インターフェイスにコールを転送する処理は行われません。代わりに、会社の電話番号に対応する WLAN またはモバイル データ ネットワーク インターフェイスだけがコールを受信します。


) Dial Via Office が有効になっている場合(「Dial Via Office」を参照してください)で、クライアントが登録されていても、Unified CM は着信コールを VoIP 経由で会社の電話番号に転送せず、モバイル コネクトを使用してユーザの携帯電話番号に転送します。


モバイル デバイスが企業ネットワークに直接またはセキュア リモート接続を介して接続されておらず、あるいは Unified CM に登録されていない状況においては、ユーザが Unified Mobility で有効にされており、そのモビリティ ID に対してモバイル コネクトが有効であると仮定すると、会社の番号への着信コールは、設定済みのモビリティ ID ごとのデュアル モード携帯電話番号に拡張されます。Unified Mobility でのモバイル クライアントおよびデバイスの統合の詳細については、「Cisco Jabber と Cisco Unified Mobility との間の相互作用」を参照してください。

上記の同じ動作とロジックは、すべてのシェアド ライン呼び出し機能に適用されます。この機能が有効である場合、デュアル モード モバイル クライアント デバイスが Unified CM に 登録されていない 場合に限り、コールはモビリティ ID または携帯電話番号に拡張されます。すべてのシェアド ライン呼び出し機能の詳細については、「Intelligent Session Control およびすべてのシェアド ライン呼び出し」を参照してください。

いずれの場合も、デュアル モード デバイスのモバイル ネットワーク電話番号に直接発信された着信コールは、プロバイダー ネットワークまたはデバイス設定がモバイル ネットワークによってデバイスに拡張されないように設定されている場合、モバイル ネットワークのデュアル モード デバイスのモバイル ボイス インターフェイスに必ず直接ルーティングされます。このようなコールは、ユーザの会社の電話番号に対して発信されたコールではないため、適切な動作です。これらのコールは個人的なコールであると見なされるため、会社経由でルーティングされません。


) タブレット デバイスなどの携帯電話音声の無線のないモバイル クライアント デバイスは、デュアルモード デバイスではなく、モバイル ボイス ネットワーク インターフェイスでは到達できません。これらのデバイスは、Voice over IP によって会社の電話番号でのみ到達できます。


発信コール ルーティング

デュアルモード モバイル デバイスからの発信コールで使用されるインターフェイスは、ロケーション、およびその特定の時刻におけるデバイスの接続状況に応じて異なります。デュアルモード デバイスが企業に接続されず、Unified CM に登録されていない場合、コールは、通常どおりセルラー音声無線インターフェイスによってモバイル ボイス ネットワークにルーティングされます。ただし、企業に接続され、Unified CM に登録されている場合、モバイル デバイスはすべてのコールをエンタープライズ テレフォニー インフラストラクチャ経由で発信する必要があります。企業接続が使用できない場合、またはモバイル クライアントが登録されていない場合は、会社の番号からコールを発信することはできず、代わりにモバイル クライアント デバイスの携帯の番号を利用してモバイル ボイス ネットワーク経由でコールを発信する必要があります。または、Cisco Unified Mobility に装備されている 2 ステージ ダイヤリング機能を利用することもできます(「モバイル ボイス アクセスとエンタープライズ機能アクセス」を参照)。

ダイヤル プラン

企業のダイヤル プランによって、モバイル クライアント デバイスが企業に接続され、Unified CM に登録されている場合のダイヤリング動作が決定されます。たとえば、企業のダイヤル プランの設定で、内部の内線番号に到達するために短縮ダイヤルの使用が許可されている場合、Unified CM に登録されているモバイル デバイスではこの短縮ダイヤルを利用できます。デュアルモードの携帯電話ユーザが発信コールにおいて社内で企業のダイヤリング手順、短縮ダイヤル、およびサイトベースの番号または PSTN 振り分け用数字を使用してダイヤルできることは確かに便利ですが、携帯電話ユーザは、通常、携帯電話において、モバイル ボイス ネットワークで発信コールに対して要求される完全な E.164 ダイヤル ストリングを使用して発信コールの番号をダイヤルするため、これは若干不自然なダイヤリング方式となります。

企業におけるエンド ユーザ ダイヤリング エクスペリエンスは、最終的には企業のポリシーおよび企業のテレフォニー配置の管理者によって決定されます。ただし、デュアルモード モバイル デバイスでは、デバイスが企業ネットワークに接続されて Unified CM に登録されているかどうかにかかわらず、デュアルモード クライアント デバイスのダイヤリング手順が維持されるように、必要なダイヤル ストリングを正規化することを推奨します。モバイル ボイス ネットワークにおけるダイヤリングは、通常完全な +E.164(先頭に「+」が付きます)を使用して行われ、携帯電話の連絡先は通常完全な +E.164 番号で保存されるため、デュアルモード モバイル デバイスにおいては、企業のダイヤル プランは先頭に「+」を付けた完全な +E.164 番号を使用できるように設定することを推奨します。Unified CM 内で、デュアルモード電話のこのような発信ダイヤリングを処理するようにダイヤル プランが設定されている場合、ユーザは連絡先を +E.164 形式で 1 セットだけ電話機に保存するだけで済みます。これらの連絡先からダイヤルする場合や、完全な +E.164 番号を使用して手動でダイヤルする場合、デバイスが企業ネットワークに直接接続されているか、セキュア リモート接続を介して接続され Unified CM に登録されているか、またはモバイル ボイス ネットワークにだけ接続されているかにかかわらず、コールは常に適切な接続先にルーティングされます。このように企業のダイヤル プランを設定すると、ユーザのモバイル デバイスのダイヤリング手順が維持され、デバイスが企業に接続され Unified CM に登録されているかどうかを気にする必要がなくなるため、最善のエンド ユーザ ダイヤリング エクスペリエンスが提供されます。

デュアルモード電話から正規化されたダイヤリングを行うには、企業に接続されているか、またはモバイル ボイス ネットワークだけに接続されているかにかかわらず、次の点を考慮して Unified CM 内のダイヤル プランを設定します。

企業のダイヤル プランで、デュアルモード電話機からの、通常モバイル ボイス ネットワークで使用されるダイヤル ストリングを処理できるようにします。たとえば、ダイヤル プランでは、携帯電話からモバイル ボイス ネットワークを経由して特定の電話機に到達するためにダイヤルされる +1 408 555 1234 や 408 555 1234 などのストリングを処理できるように設定する必要があります。後者の 10 桁のダイヤル方式(たとえば、408 555 1234)をサポートすると、サイト内の短縮ダイヤルなどの他のダイヤリング手順と潜在的にオーバーラップする可能性があります。この場合、管理者は、どのオーバーラップしているダイヤリング手順(10 桁のダイヤルまたはサイト内の短縮ダイヤル)が企業ネットワークに登録されているデュアル モード電話機で使用できるようにする必要があるかを決定する必要があります。デュアル モード電話機でサポートされているダイヤリング手順のセットは、標準のエンドポイントでサポートされるダイヤリング手順のセットと異なることがよくあります。

会社の他の電話番号へのコールにおいては、短縮ダイヤルが設定されているシステムでは、ダイヤル ストリングを変更して、必要に応じて会社の内線番号に再ルーティングできる必要があります。たとえば、企業のダイヤル プランが 5 桁の内部ダイヤルに基づいているとすると、会社の内線番号へのコール ルーティングが処理されるようにシステムを設定して、デュアルモード デバイスが Unified CM に登録されているときにコールが発信された場合、+1 408 555 1234 や 408 555 1234 に発信されたコールが変更されて、51234 に再ルーティングされるようにする必要があります。

会社のデュアルモード デバイスへのすべての着信コールの発信番号または発信者 ID プレフィックスの先頭に適切な数字を付加して、不在コール、発信コール、および着信コールのコール履歴リストが完全な +E.164 形式となるようにします。これにより、デュアルモード デバイスのユーザは、ダイヤル ストリングを編集することなくコール履歴リストからダイヤルできます。ユーザは、企業に接続されているかどうかにかかわらず、コール履歴リストから番号を選択してリダイヤルできます。たとえば、社内の 51234 からデュアルモード ユーザの会社の電話番号にコールが発信され、そのコールに応答がない場合、発信番号を操作して、デュアルモード デバイスの履歴リストに 408 555 1234 または +1 408 555 1234 という形式のエントリが残るように Unified CM を設定する必要があります。この番号は、デュアル モード デバイスが、これ以上の処理の必要とすることなく、企業または単にモバイル ボイス ネットワークに接続されているかどうかダイヤルできます。

デュアルモード デバイスの正規化されたダイヤリングの例外の 1 つに、会社の内線番号または電話に内部からだけ到達可能なシナリオがあります(つまり、対応する外部から到達可能な DID 番号がない場合)。このような場合は、短縮形式を使用して、外部から到達できない番号をダイヤルできます(手動でダイヤルするか、または連絡先からダイヤルします)。これらの番号は外部では利用できず、社内からだけダイヤルできるため、連絡先リストにこれらの番号を保存する場合には、社内だけで使用できるという何らかのマークが必要となります。さらに、これらの内部専用番号からの着信コールの発信番号をコール履歴リストに保存する場合は、番号が変更されないようにする必要があります。これらの番号には、社内からだけ発信できるためです。すべてのコール履歴リストにおいて、これらの内線番号からのコールは番号を変更しないで保存する必要があります。このように変更しないで保存された番号、つまり短縮ダイヤル ストリングは、デバイスが企業に接続され Unified CM に登録されているときにだけ正常にダイヤルできます。

タブレットなどの携帯電話音声の無線がないモバイル クライアント デバイスは、企業接続および企業の音声とビデオ テレフォニーまたはクラウドベースのコラボレーション サービスだけに依存します。

緊急サービスおよびダイヤリングの考慮事項

モバイル クライアント デバイスから 911、999、112 などの緊急サービス番号に対してコールを発信する場合、事態は少々複雑になります。モバイル クライアント デバイスは社内または社外に位置する可能性があるため、緊急時におけるデバイスおよびユーザの位置の通知について考慮する必要があります。セルラー音声無線を備えたデュアルモード モバイル デバイスはプロバイダー ネットワークの位置サービスを利用しています。デバイスが接続され、通常は企業ワイヤレス ネットワークよりもはるかに正確に位置を特定できる場合は、これらの位置サービスは常に利用可能できます。そのため、デュアルモード デバイス ユーザは緊急コールを発信し、デバイスおよびユーザの位置を特定する場合には、モバイル ボイス ネットワークを利用することを推奨します。シスコのデュアルモード クライアント デバイスが緊急サービスおよび位置サービスにモバイル プロバイダーのボイス ネットワークのみを利用するよう、これらのクライアントは、モバイル クライアント デバイス設定ページの [Emergency Numbers] フィールドに設定された番号に対するすべてのコールを強制的にモバイル ボイス ネットワーク経由でルーティングします。さらに、デュアルモード電話機のユーザに対して、すべての緊急コールを企業ネットワークではなくモバイル ボイス ネットワーク経由で発信するように指示します。

WLAN またはモバイル データ ネットワークを介した緊急コールを発信することは推奨されませんが、携帯電話音声の無線がないモバイル デバイスは、これらのデータ インターフェイスだけを経由して発信できます。携帯電話音声の無線がないモバイル デバイスは、緊急コール発信用に利用すべきではありません。

会社の発信者 ID

モバイル クライアント デバイスが企業に接続され、Unified CM に(モバイル データ ネットワークまたは WLAN 経由で)登録された場合、WLAN またはモバイル データ ネットワーク経由の企業回線で行われたすべてのコールは、発信者 ID としてユーザの会社の電話番号でルーティングされます。これにより、遠端でコール履歴リストから発信される返信コールはユーザの会社の電話番号に対して発信されることになり、常に会社経由でルーティングされます。デュアルモード モバイル デバイス ユーザに対して Cisco Unified Mobility が有効になっており、携帯電話の番号でモバイル コネクトがオンになっている場合、デュアルモード デバイスが企業に接続されていないときには、会社の電話番号への返信コールも PSTN 経由でデュアルモード デバイスに転送されます。

通話切替機能

モバイル クライアント デバイスが企業に接続され、企業エンドポイントとして Unified CM に登録されている場合、Unified CM でサポートされている SIP コール シグナリング方式を使用して、保留、保留解除、転送、会議などの呼処理付加サービスを呼び出すことができます。Unified CM に登録された IP Phone やクライアントと同様に、これらのデバイスでは、保留音(MoH)、会議ブリッジ、メディア ターミネーション ポイント、トランスコーダなどの企業のメディア リソースを利用できます。

外部コール ルーティング

デュアル モード モバイル クライアント デバイスが企業に接続されている場合、または Unified CM に登録されていない場合は、モバイル ボイス ネットワーク経由だけでコールを発信および受信できます。このため、デュアルモード モバイル デバイスが登録されていない場合に発信または受信されるすべてのコールにおいて、Unified CM は関与しません。企業に接続されていないデュアルモード電話からコールが発信された場合、ネットワークに送信される発信者 ID は携帯の番号です。このため、応答されなかったコールへの返信コールは、会社経由でルーティングされるのではなく、デュアルモード デバイスの携帯の番号に直接発信されることになります。

デュアルモード モバイル クライアント デバイスが Cisco Unified Mobility と統合されている場合は、デュアルモード デバイスが社外にあり Unified CM に登録されていない場合でも、エンタープライズ 2 段階ダイヤリング サービスを利用して会社経由でコールを発信できます。Unified Mobility の 2 ステージ ダイヤリングは、モバイル ボイス アクセスまたはエンタープライズ機能アクセスを使用して実行され、ユーザはエンタープライズ システム アクセスの DID 番号をダイヤルし、クレデンシャルを入力してから発信番号をダイヤルする必要があります。Unified Mobility の 2 ステージ ダイヤリング機能の詳細については、「モバイル ボイス アクセスとエンタープライズ機能アクセス」を参照してください。

同様に、デュアルモード電話機が Unified Mobility と統合されている場合、ユーザは、会社の電話番号への着信コールをモバイル コネクト経由で携帯の番号で受信したり、DTMF キー シーケンスを使用して保留、保留解除、転送、会議などの通話切替機能を呼び出したり、デスクトップフォンのピックアップを実行してアクティブなコールを携帯電話から会社のデスクトップフォンに移動したりできます。

リモート セキュア企業接続

モバイル クライアント デバイスは、Unified CM に対してクライアントを登録するために企業に安全な接続があるとすれば、企業に接続されていない場合でも IP コール経由でエンタープライズ音声およびビデオ用の IP テレフォニーのインフラストラクチャを利用できます。これらのデバイスに対するリモート セキュア接続は、インターネット経由のクライアント接続を保護するために Cisco AnyConnect モバイル クライアントなどの VPN ソリューションの使用が必要です。

リモート接続されたモバイル クライアント デバイスの音声およびビデオの品質とユーザ エクスペリエンスは、インターネット ベースのネットワーク接続の特性によって異なります。このようなクライアント接続タイプでは、シスコは音声とビデオの品質も正常接続も保証しません。このような接続を業務上重要な通信に使用する場合は、注意が必要です。信頼できない、または低帯域幅のインターネット接続を備えたデュアルモード デバイスの場合、デュアルモード デバイスのユーザは、接続が企業テレフォニー インフラストラクチャに依存しているのでなく、使用可能である場合、モバイル ボイス ネットワーク経由でコールを発信することが推奨されます。

追加のサービスおよび機能

呼処理サービスや呼制御サービスに加えて、シスコのモバイル クライアントとデバイスは、この項で説明する追加の機能およびサービスを提供できます。

デュアルモード コール ハンドオフ

デュアル モード デバイス配置の、1 つの非常に重要な側面は、ユーザが社内と社外の間を移動する、またはデバイスが企業ネットワークとの間で接続、切断するときに、ネットワーク接続が携帯電話音声の無線から WLAN 無線に切り替わり、また、その逆のことが起こるコール プリザベーションです。デュアルモード電話のユーザは多くの場合移動するため、デュアルモード ユーザが社内と社外の間を移動するときにアクティブなコールが維持されることが重要です。このため、デュアルモード クライアント デバイスおよび基礎となる企業のテレフォニー ネットワークでは、何らかの形式のコール ハンドオフが可能である必要があります。

デュアルモード クライアント、および基礎となる IP テレフォニー インフラストラクチャの両方でサポートされる必要がある 2 種類のコール ハンドオフがあります。

ハンドアウト

コール ハンドアウトとは、アクティブ コールをデュアルモード電話の WLAN またはモバイル データ ネットワーク インターフェイスからデュアルモード電話のセルラー音声インターフェイスに移動することを指します。このためには、コールが、会社の PSTN ゲートウェイ経由で、企業の IP ネットワークからモバイル ボイス ネットワークにハンドアウトされることが必要です。

ハンドイン

コール ハンドインとは、アクティブ コールをデュアルモード電話のセルラー音声インターフェイスからデュアルモード電話の WLAN またはモバイル データ ネットワーク インターフェイスに移動することを指します。このためには、コールが、会社の PSTN ゲートウェイ経由で、モバイル ボイス ネットワークから企業の IP ネットワークにハンドインされることが必要です。

デュアルモード電話機のハンドオフ動作は、デュアルモード クライアントの特性およびその特定の機能に依存しています。デュアル モード クライアントのハンドオフは、ユーザによって手動で呼び出したり、またはネットワーク条件に基づいて自動的に呼び出したりできます。手動ハンドオフのシナリオにおいては、デュアルモード ユーザは、各自のロケーションおよび必要性に基づいてハンドオフ動作を行い、完了する必要があります。自動ハンドオフにより、モバイル クライアントは WLAN 信号をモニタし、クライアントの WLAN 信号の強弱に基づいてハンドオフの決定を行います。弱い WLAN 信号の場合はハンドアウトが行われ、強い WLAN 信号の場合はハンドインが行われます。自動ハンドオフは、WLAN 信号の強度をモニタする機能を提供するモバイル デバイスに依存します。

ハンドオフ動作は、電話のコールにおいてエンタープライズ IP テレフォニー インフラストラクチャを最大限に活用するために重要となります。 また、これらの動作は、音声の継続性と良好なユーザ エクスペリエンスを提供し、ユーザが元のコールをいったん切ってから再度コールを発信し直す必要がないようにするためにも必要です。

XMPP ベースの IM およびプレゼンス

一部のモバイル クライアントは、オンプレミスのまたはオフプレミスのアプリケーション サーバまたはサービスとの統合によって、Extensible Messaging and Presence Protocol(XMPP)に基づいて企業インスタント メッセージング(IM)およびプレゼンス サービスを提供できます。いずれの場合も、これらのモバイル クライアントの IM およびプレゼンス機能は、次を有効化します。

ユーザを連絡先リストまたはバディ リストに追加する。

ユーザのプレゼンスおよび応答可能性のステータスを設定および伝達する。

バディまたは連絡先のプレゼンス ステータスを受信する。

インスタント メッセージング(IM)またはテキスト メッセージを作成し、送信する。

IM またはテキスト メッセージを受信する。

IM およびプレゼンスはモバイル クライアントで必要でない機能ですが、これによって、ユーザはアベイラビリティ ステータスを連絡先に表示させ、連絡先の可用性ステータスを表示可能にすることで生産性を向上できます。さらに、ユーザは、モバイル ショート メッセージ サービス(SMS)メッセージのコストを負担するのではなく、企業ベースの IM メッセージを送信できます。

社内ディレクトリ アクセス

一部のモバイル クライアントとデバイスは、ディレクトリ ルックアップおよび個人的なコンタクト リストを含む LDAP 社内ディレクトリ サービスにアクセスできます。この機能はモバイル デバイスおよびクライアントに必須の機能ではありませんが、モバイル ユーザがモバイル デバイスから社内ディレクトリ情報にアクセスできると、これらのユーザの生産性が向上します。

企業ボイスメール サービス

多くのモバイル クライアントとデバイスも、企業ボイス メール サービスにアクセスできます。シスコのモバイル クライアントでは、ユーザの企業ボイスメール ボックスに未読のボイスメールが存在し、モバイル デバイスが企業ネットワークに接続されている場合に、企業のメッセージ待機インジケータを受信できます。さらに、モバイル クライアントを使用して、企業ボイスメール メッセージを取得することもできます。通常、企業ボイスメール メッセージは、ユーザがボイスメール システム番号にダイヤルし、必要なクレデンシャルを入力してから各自のボイスメール ボックスに移動して取得します。ただし、Cisco Jabber モバイル クライアントは、ボイスメール ボックス内のすべてのメッセージのリストをダウンロードおよび表示し、モバイル デバイスにダウンロードして再生する個別のメッセージを選択することによって、ボイスメール ボックスからボイスメール メッセージを取得する機能を備えています。この機能は、ビジュアル ボイスメールと呼ばれることもあります。モバイル クライアントおよび企業ボイスメール システムの両方において、ネットワーク経由でのメッセージ待機インジケータ(MWI)、ボイスメール メッセージ情報、およびメッセージのダウンロードの提供と受信が可能である必要があります。Cisco Unity Connection は、IMAP または VMREST を使用したビジュアル ボイス メールをサポートし、MWI とボイス メール リストおよびダウンロードを提供できます。

Dial Via Office

Dial Via Office(DVO)機能によって企業のダイヤリング機能が自動化され、デュアル モードのモバイル デバイスが企業テレフォニー インフラストラクチャ経由でコールを開始できるようになりました。DVO コーリングを導入すると、企業に次の利点がもたらされます。

直接ダイヤルされた携帯電話コールと比較して、国際電話(おそらくは)長距離電話のコストを削減します。モバイル データ通過の場合は、モバイル データのコストも考慮する必要があることに注意してください。

社内番号に電話をかけることができます。DVO コールは会社の内線番号を使用して発信されるため、DID 以外または内部専用の会社の内線番号にも到達できます。

携帯電話番号のマスキング。DVO コールでは、システムは携帯電話番号ではなくユーザの社内番号を発信者 ID として送信します。

一元化された会社のコール詳細レコード(CDR)とコール ログ。DVO コールは企業テレフォニー インフラストラクチャから発信されるため、コールが PSTN およびモバイル ボイス ネットワークを通過する場合も、管理者はこれらのコールを完全に認識しています。

社内コール アンカリング。DVO コールは社内でアンカーされるため、ユーザは Cisco Unified Mobility DTMF ベースの通話切替機能、およびデスクトップフォンのピック アップを利用することができます。

Cisco Jabber クライアントを実行するデュアル モードのモバイル デバイスは、会社の内線番号を使用して電話をかける Unified CM テレフォニー インフラストラクチャと会社の PSTN ゲートウェイを使用して DVO コールを発信することができます。ただし、音声メディアが IP ネットワークを通過する Voice over IP(VoIP)とは異なり、この機能は、図 23-24 に示すように、クライアントと IP 接続(WLAN またはモバイル データ)経由の Unified CM 間の SIP シグナリングと、モバイル デバイス、モバイル ボイス ネットワーク、PSTN 間の音声メディアによって実現されます。

図 23-24 Cisco Dial Via Office のアーキテクチャ

 


) DVO コールの場合、ユーザの携帯電話からのすべての音声またはメディアは、モバイル ボイス ネットワーク、PSTN、および会社の PSTN ゲートウェイを経由して常に移動します。メディアが会社へのデータ接続を通過することはありません。モバイル データ ネットワーク接続は、コール シグナリング トラフィックとその他のアプリケーションの相互作用以外には使用されません。


Cisco Jabber クライアント向け Dial via Office の詳細については、「Cisco Jabber Dial Via Office」を参照してください。

Cisco Bring Your Own Device(BYOD)インフラストラクチャ

Cisco Jabber などのシスコのモバイル クライアント アプリケーションは、Android や Apple iOS のスマートフォンとタブレットなどのモバイル デバイスのユーザへの、音声、ビデオ、およびインスタント メッセージングを含むコアの Unified Communications およびコラボレーション機能を提供します。シスコのモバイル クライアント デバイスが企業ワイヤレス LAN に接続されている場合、クライアントは Cisco Bring Your Own Device(BYOD)インフラストラクチャ内に配置できます。

シスコのモバイル クライアントとデバイスは、企業ワイヤレス LAN 接続、または VPN 経由のリモート セキュア接続に依存しているため、Cisco Unified アクセス ネットワーク内に配置でき、BYOD インフラストラクチャで配信される ID、セキュリティ、およびポリシー機能を利用できます。

Cisco BYOD インフラストラクチャは、さまざまなデバイスの所有権とアクセス要件に対応するために、種々のアクセス使用例またはシナリオが用意されています。次のハイレベルなアクセス使用例モデルを考慮する必要があります。

基本的なアクセス:この使用例は、ゲストのデバイスの基本的なインターネット アクセスだけを有効にします。この使用例では、企業リソースへのアクセスを提供せずに、従業員所有の個人用デバイスのネットワーク接続を可能にする機能を提供します。

制限付きアクセス:この使用例は、社内ネットワーク リソースへのフル アクセスを有効にしますが、企業所有デバイスだけに適用されます。

拡張アクセス:この使用例は、社内ポリシーに基づいて、企業所有デバイスと従業員所有の個人用デバイスの両方が社内ネットワーク リソースに対して高精度なアクセスを実現します。

シスコのコラボレーション モバイル クライアントは、社内または個人的なデバイスで動作しているにかかわらず、通常は多数のバック エンドのオンプレミスの企業アプリケーション コンポーネントへのフル機能でのアクセスが必要です。このため、制限付きアクセスまたは拡張アクセスの使用例のシナリオは一般に、Cisco Jabber for Android or iPhone などのアプリケーションに適用されます。この 2 つのアクセス モデルの主な違いは、制限付きアクセスでは、企業所有デバイスに社内ネットワーク リソースへのフル アクセスが与えられている点です。拡張アクセスの場合は、従業員所有のデバイスにもフル アクセスが与えられるだけでなく、社内ネットワーク リソースへのアクセスが高精度で行われるため、このアクセス状態で実行されるデバイスとアプリ ケーションは、企業のセキュリティ ポリシーに基づいて特定のリソースだけにアクセスすることができます。

クラウドベースのコラボレーション サービスの場合は、シスコのモバイル クライアントおよびデバイスは、VPN または完全な企業ネットワーク接続は不要で、インターネットを介してクラウドに直接接続します。これらの使用例がインターネット アクセスだけを必要とするため、これらのシナリオでは、ユーザおよびモバイル デバイスは、基本的なアクセス モデルを使用して配置できます。

Cisco BYOD インフラストラクチャおよび BYOD アクセス使用例の詳細については、次の Web サイトで入手可能な『 Cisco Bring Your Own Device (BYOD) Smart Solution Design Guide 』を参照してください。

http://www.cisco.com/go/byoddesign

Cisco BYOD インフラストラクチャ内にシスコのモバイル クライアントおよびデバイスを配置する場合は、次のハイレベルな設計と配置のガイドラインを考慮してください。

ネットワーク管理者は、企業のテレフォニー インフラストラクチャの最大使用を保証するために、音声およびビデオ対応クライアントがバックグラウンドで企業ネットワークに(初期のプロビジョニングの後)、ユーザの介入なしで接続することを許可することを検討する必要があります。具体的には、証明書ベースの ID および認証を使用すると、ネットワーク接続および認証の遅延を最小化することによって優れたユーザ エクスペリエンスを容易にします。

シスコのモバイル クライアントとデバイスがセキュア VPN を介して企業ネットワークにリモート接続できるシナリオの場合:

ネットワーク管理者は、企業テレフォニー インフラストラクチャを最大限に活用するために、企業のセキュリティ ポリシーをユーザの介入のないシームレス セキュア接続の必要性に対して評価する必要があります。デバイスのピン ロック ポリシーの証明書ベースの認証および適用の使用は、エンド ユーザがデバイスを所有してネットワークにアクセスするためにピン ロックを知る必要があるため、2 ファクタ認証と同様にユーザの介入および機能なしで、シームレスな接続が提供されます。2 ファクタ認証が要求された場合、デバイスが企業にリモート接続できるようにユーザの介入が必要となります。

インフラストラクチャのファイアウォール設定によって、必要なすべてのクライアント アプリケーションのネットワーク トラフィックが企業ネットワークにアクセスできることが重要です。企業のファイアウォールで適切なポートおよびプロトコルに対してオープン アクセスを失敗すると、シスコのモバイル クライアントまたはデバイスが、音声およびビデオ テレフォニー サービスまたは企業ディレクトリのアクセスまたは企業ビジュアル ボイス メールなどの他のクライアント機能の損失に対するオンプレミスのシスコの呼制御に登録できなくなります。

Cisco Jabber などの企業のコラボレーション アプリケーションが従業員所有のモバイル デバイスにインストールされている場合に、特定の条件下でのデバイスのワイプや工場デフォルト設定へのリセットを企業のセキュリティ ポリシーが求めている場合は、デバイスの所有者はポリシーを認識してデバイスから個人データを定期的にバックアップする必要があります。

シスコのコラボレーション クライアントおよびモバイル デバイスを導入する場合は、クライアント アプリケーションの音声とビデオ コールの品質、およびすべての機能の適切な動作を保証するために、エンドツーエンドの基盤となるネットワーク インフラストラクチャが、音声メディア用のプライオリティ キューイング、専用のビデオおよびシグナリング用帯域幅などを含む必要な QoS サービス クラスをサポートすることが重要です。

シスコの Cisco Mobile クライアントおよびデバイス

ここでは、次の Cisco モバイル クライアントおよびデバイスについて説明します。

「Cisco Jabber for Android および iPhone」

「Cisco Jabber for iPad」

「Cisco Jabber IM」

「Cisco WebEx 会議」

「Cisco AnyConnect モバイル クライアント」

Cisco Jabber for Android および iPhone

ここでは、Cisco Jabber の特性および配置上の考慮事項について説明します。

Cisco Jabber モバイル クライアントは、Android、iPhone、および他の Apple iOS のモバイル デバイスで使用できます。クライアント アプリケーションを適切なストアやマーケット(Apple の App Store や Google Play(以前の Android Market))からダウンロードし、Apple iOS または Android デバイスにインストールすると、企業ネットワークに接続して SIP 対応の会社の電話機として Unified CM に登録できます。

Cisco Jabber デュアルモード Android クライアントまたは iPhone クライアントに登録および呼制御サービスを提供するには、Unified CM 内でデバイスが Cisco Dual-Mode for Android または iPhone デバイス タイプとして設定される必要があります。次に、企業の WLAN にアクセスして企業の WLAN インフラストラクチャおよびセキュリティ ポリシーに基づいて接続するようにモバイル デバイスを設定する必要があります。または、モバイル デバイスをモバイル データ ネットワークまたは非企業 WLAN 経由で企業ネットワークに接続できます。企業ネットワークにアクセスするようにモバイル デバイスを設定すると、Cisco Jabber クライアントが起動したときに、デバイスが Unified CM に登録されます。Unified Mobility と統合し、ハンドオフ機能を利用するには、Android または iPhone の携帯の番号を、Unified CM 内で Cisco Dual-Mode for Android または iPhone デバイスに関連付けられたモビリティ ID として設定する必要があります。

Cisco Jabber クライアントは、次のデバイスでサポートされます。

Android

電話機の Samsung Galaxy ファミリのさまざまなモデル。(特定のデバイスおよびファームウェアのサポート情報については、次に参照されているリリース ノートを参照してください)。これらのデバイスは、ファームウェア バージョン 2.3、4.0、4.1 を実行している必要があります。公式にサポートされていませんが、Cisco Jabber for Android はバージョン 2.3、4.0、4.1 を実行している多くの Android デバイスで動作します。制限の度合いはデバイスによって異なります。ほとんどの Android デバイスの WLAN インターフェイスで、802.11a、802.11b、802.11g、および 802.11n ネットワーク接続がサポートされています。

Apple iOS

iPhone、iPad などのさまざまな Apple iOS デバイス。(特定のデバイスおよびファームウェアのサポート情報については、次に参照されているリリース ノートを参照してください)。これらのデバイスは、iOS バージョン 6 以降を実行している必要があります。これらの Apple iOS デバイスの WLAN インターフェイスでは、802.11a、802.11b、802.11g、および 802.11n ネットワーク接続がサポートされています。

最新の特定のデバイスおよびファームウェア バージョンの詳細については、次の製品リリース ノートを参照してください。

Android

http://www.cisco.com/en/US/products/ps11678/prod_release_notes_list.html

iPhone

http://www.cisco.com/en/US/products/ps11596/prod_release_notes_list.html

Cisco Jabber for iPhone および Android のクライアントは、Voice-over-IP フォン サービスだけでなく、企業 LDAP ディレクトリにアクセスするように設定された場合は、ディレクトリ ルックアップ サービスも提供します。Cisco Unity Connection に統合された場合は、企業ボイスメール メッセージ待機インジケータ(MWI)およびビジュアル ボイスメールを提供します。

Cisco Jabber for iPhone および Android のクライアントは、「Cisco Jabber ハンドオフ」の項に説明されているように、手動でのハンドアウトだけを実行できます。

Cisco Jabber Android および iPhone クライアント、追加の機能、およびサポートされているハードウェアとソフトウェアのバージョンの詳細については、次の Cisco Jabber のマニュアルを参照してください。

Android

http://www.cisco.com/en/US/products/ps11678/tsd_products_support_series_home.html

iPhone

http://www.cisco.com/en/US/products/ps11596/tsd_products_support_series_home.html

Cisco Jabber ハンドオフ

Cisco Jabber などの Cisco デュアルモード クライアントを適切に配置するには、クライアント内部のハンドオフ動作の特性について理解することが重要です。Cisco Jabber デュアルモード クライアントによって使用されるハンドオフ方式は、Cisco Dual-Mode for iPhone または Cisco Dual-Mode for Android デバイスの設定ページの [Transfer to Mobile Network] 設定に基づきます。

[Transfer to Mobile Network] の設定に応じて、ハンドオフには次の 2 つの方式があります。

「モバイル ソフトキー方式のハンドオフ」

この方式では、[Transfer to Mobile Network] の設定を [Use Mobility Softkey (user receives call)] に設定する必要があります。このタイプのハンドオフでは、Unified CM システムは、PSTN を介してユーザのモバイル番号へのコールを発信します。このハンドアウト方式は、すべての Cisco Jabber デュアル モード クライアントでサポートされています。

「ハンドオフ番号方式のハンドアウト」

この方式では、[Transfer to Mobile Network] の設定を [Use HandoffDN Feature (user places call)] に設定する必要があります。このタイプのハンドオフでは、モバイル クライアントが、モバイル ボイス ネットワークを介して、Unified CM システム内で設定されているハンドオフ番号に対してコールを発信します。このハンドアウト方式は、Cisco Jabber for iPhone クライアントだけでサポートされています。

モバイル ソフトキー方式のハンドオフ

図 23-25 に示す動作は、社内の iPhone または Android デュアルモード デバイスにおけるアクティブなコールが、手動で WLAN インターフェイスから会社の PSTN ゲートウェイ経由でモバイル ボイス ネットワーク(デバイスの携帯電話インターフェイス)に移動される様子を示しています。図に示すように、企業の WLAN に関連付けられ、Unified CM に登録されたモバイル クライアント デバイスと、PSTN ネットワーク上の電話機との間に既存のコールがあります(ステップ 1)。これは手動のプロセスであるため、ユーザが Cisco Jabber クライアント内のコール中メニューから [Use Mobile Network] ボタンを選択して、コールをハンドアウトする意図があることを Unified CM に通知する必要があります(ステップ 2)。次に、Unified CM から、このモバイル デバイスに対応する設定済みのモビリティ ID 番号に対して、会社の PSTN ゲートウェイを経由してコールが発信されます(ステップ 3)。このモビリティ ID へのコールは、モバイル ボイス ネットワーク(iPhone または Android デバイスの携帯電話インターフェイス)に対して発信されます。これで、ユーザは、社外に移動して、WLAN ネットワークのカバー領域から離れることができます(ステップ 4)。一方、Unified CM からの着信コールがモバイル ボイス ネットワーク インターフェイスで受信され、ユーザは手動でこのコールに応答し、ハンドアウトを完了する必要があります。携帯電話インターフェイスで着信コールが応答されると、WLAN を通過していた RTP ストリームが PSTN ゲートウェイにリダイレクトされ、モバイル クライアント デバイスと元の PSTN 電話機との間のコールは会社のゲートウェイでアンカーされて、中断されずに継続します(ステップ 5)。

図 23-25 Cisco Jabber デュアル モード ハンドアウト(WLAN からモバイル ボイス ネットワークへ):モバイル ソフトキー方式

 

ハンドオフ番号方式のハンドアウト

図 23-26 に、社内の iPhone デュアルモード電話機におけるアクティブなコールが、手動で WLAN インターフェイスから会社の PSTN ゲートウェイ経由でモバイル ボイス ネットワークまたは携帯電話インターフェイスに移動される図 23-25 と同じハンドオフ動作を示します。ただし、このケースでは、ハンドオフ番号方式のハンドアウトが使用されます。


) ハンドオフ番号方式のハンドアウトは、Cisco Jabber for iPhone 対応の iPhone だけでサポートされています


図 23-26 に示すように、企業の WLAN に関連付けられ、Unified CM に登録された iPhone デュアルモード デバイスと、PSTN ネットワーク上の電話機との間に既存のコールがあります(ステップ 1)。これは手動のプロセスであるため、ユーザが Cisco Jabber デュアルモード クライアント内のコール中メニューから [Use Mobile Network] ボタンを選択して、コールをハンドアウトすることを Unified CM に通知する必要があります(ステップ 2)。次に、Cisco Jabber クライアントが、Unified CM システム内で設定されているハンドオフ番号に向けて、モバイル ボイス ネットワークを介して携帯電話インターフェイスからコールを自動発信します(ステップ 3)。これで、ユーザは、社外に移動して、WLAN ネットワークのカバー領域から離れることができます(ステップ 4)。その間に、Cisco Jabber クライアントからの着信コールが Unified CM によって受信されます。着信したコールの発信番号がユーザに設定されているモビリティ ID と一致したと仮定すると、WLAN を通過した RTP ストリームが PSTN ゲートウェイにリダイレクトされ、Cisco Jabber モバイル クライアントと元の PSTN 電話との間のコールは、会社のゲートウェイでアンカーされて、中断されることなく継続します(ステップ 5)。

図 23-26 Cisco Jabber デュアルモード ハンドアウト:ハンドオフ番号方式

 


) ハンドオフ番号方式のハンドアウトでは、Unified CM が、着信したコールの発信番号として、ハンドオフを試みている Cisco Dual Mode for iPhone デバイスの下で設定されているモビリティ ID 番号と一致する番号を PSTN ネットワークから受け取る必要があります。発信者 ID が iPhone から送信されない場合、PSTN プロバイダーが着信したコールの発信者 ID を会社に送信しなかったり、着信したコールの発信者 ID が設定されているモビリティ ID と一致しなかった場合は、ハンドアウト動作は失敗します。



) Cisco Jabber デュアル モード クライアントでは、ハンドインをサポートしません。デュアルモード モバイル ボイス ネットワーク(セルラー インターフェイス)と会社の電話(または会社のゲートウェイでコールがアンカーされた PSTN 電話機)との間で通話中のコールがアクティブである場合、コールをデュアルモード デバイスの WLAN インターフェイスに移動するには、コールをいったん切断し、デュアルモード クライアントが企業ネットワークに接続されて Unified CM に登録されてからリダイヤルするのが唯一の方法です。


Cisco Jabber for iPhone デスクフォンの統合

Cisco Jabber for iPhone モバイル クライアントを使用すると、アクティブまたは保留中の通話をデスクトップフォンから iPhone デバイスに転送できます。この機能を使用するには、デスクフォンのプライマリ回線の CTI モニタリングおよびコール パーク機能が必要です。

デスクトップフォンで提供される機能を使用するには、デスクトップフォンのプライマリ回線の CTI モニタリングがアクティブである必要があります。アクティブまたは保留中の通話が Cisco Jabber クライアントに検知されると、デュアルモード デバイスに通話を転送するかどうかをたずねられます。通話を転送する場合は、デスクトップフォンが自動的にコールをパークし、モバイル クライアントがパーク番号から自動的に通話を取得します。

デスクトップフォンの統合を有効にするには、ユーザのエンド ユーザ アカウントが CRI が有効なユーザ グループに割り当てられており、ユーザのデスクトップフォンで CTI 制御が可能になっていることを確認してください。また、Cisco Dual-Mode for iPhone デバイスの [CTI Control Username] フィールドを、ユーザのエンド ユーザ アカウント userID を使用して設定する必要があります。

Cisco Jabber モバイル クライアントの WLAN 設計上の考慮事項

Cisco Jabber モバイル クライアントを配置する際には、次の WLAN ガイドラインを考慮してください。

可能な場合は、Cisco Jabber モバイル クライアントが、デバイスの WLAN インターフェイス上で同じ IP アドレスを使用できるように、必ず WLAN のレイヤ 2 でだけローミングするようにしてください。デバイスの IP アドレスの変わり、サブネットの境界を越えるレイヤ 3 のローミングでは、コールがドロップされます。

同じ SSID が AP 全体で使用される WLAN ネットワークに Cisco Jabber モバイル クライアントを配置します。SSID が異なると、AP 間のローミングがはるかに低速になります。

WLAN 上のすべての AP が、その SSID をブロードキャストするようにしてください。SSID が AP によってブロードキャストされないと、他の Wi-Fi ネットワークに参加するようにデバイスから要求される場合や、デバイスが自動的に他の Wi-Fi ネットワークに参加する場合があります。この場合、コールは中断されます。

可能な場合は、5 GHz 帯域 WLAN(802.11a/n)に Cisco Jabber モバイル クライアントを配置します。5 GHz WLAN は、音声コールとビデオ コールに対し、スループットを改善して干渉を低減します。

Cisco Jabber Dial Via Office

Unified CM の管理者は、Cisco Dual Mode for iPhone または Android デバイス設定ページの [Product Specific Configuration Layout] セクションを使用して各デュアル モード デバイスに対する Dial Via Office(DVO)コールを有効または無効にできます。DVO が有効な場合、ユーザは Cisco Jabber アプリケーション内の [Calling Option] 設定を使用して DVO をオンにできます。DVO のコール オプションは、Jabber クライアントによって使用される発信コール方式だけでなく、着信コール方式も定めることに注意することが重要です。 表 23-4 は、ネットワーク接続の種類に基づいたさまざまなコール オプションと、対応する発信コール方式と着信コール方式を示します。

 

表 23-4 Cisco Jabber Dial Via Office コール オプションを使用した着信コール方式と発信コール方式

デバイス
IP 接続
Cisco Jabber DVO 通話オプション
Automatically Select
(デフォルト)
Always Use DVO
Always Use Internet
発信コール
着信コール
発信コール
着信コール
発信コール
着信コール

802.11 WLAN(社内/企業)

Voice over IP

Voice over IP

オフィス経由のダイヤル

モバイル コネクト

Voice over IP

Voice over IP

802.11 WLAN(非社内/企業)

モバイル データ

オフィス経由のダイヤル

モバイル コネクト

IP なし

発信コール:ネイティブ携帯電話

着信コール:モバイル コネクト

DVO が最初に有効になったときのデフォルトのコール オプションは [Automatically Select] です。これは、デバイスが 802.11 WAN 経由で接続している場合は、Cisco Jabber の着信コールと発信コールの両方で Voice over IP(VoIP)が発生します。デバイスがモバイル データ ネットワークに接続している場合は、発信コールに DVO が使用され、着信コールにモバイル コネクトが使用されます。

いずれの場合も、Unified CM 内のモバイル クライアント デバイス設定で [Emergency Numbers] フィールドに設定された緊急番号に発信されたコールは、選択されているコール オプションに関係なく、携帯電話ネットワーク経由で直接ダイヤルされます。

Dial Via Office が Cisco Jabber クライアントで有効な場合は、モバイル コネクトと同様に、Cisco Unified Mobility のモバイル ボイス メールの無効化またはシングル企業ボイスメール ボックス機能が実行されます。Dial Via Office の場合、このボイス メールの無効化機能により、DVO コールのセットアップ中にネットワーク パス障害やその他の通信エラーが発生した場合、呼び出されたユーザが発信側ユーザのボイス メール ボックスに転送しないことが保証されます。通常、ユーザ制御のモバイル ボイス メールの回避方式が、全体的に最も優れたユーザ エクスペリエンスを実現します。これは、DVO コール レッグが誤ってボイス メール システムによる応答を転送することになった場合、DTMF トーンが Unified CM によって受信されない場合、コール レッグが切断され、DVO コールがクリアされます。Cisco Jabber ユーザがユーザ制御のモバイル ボイス メールの回避方式で有効になっている場合、クライアント デバイスでモビリティ コールを受信したときに、モバイル デバイスのキー パッドにあるボタンを押す必要があります。ボタンを押さないと、コール セットアップで障害が発生します。


) ユーザ制御のモバイル ボイス メールの回避方式は、PTSN 接続と PTSN ゲートウェイおよびアウトオブバンド経由のモバイル デバイスから Unified CM まで、DTMF トーンのリレーが成功することに完全に依存しているため、PSTN から Unified CM への着信 DTMF が伝達できなかった場合、モバイル デバイスから発信(Dial Via Office Reverse)またはモバイル デバイスが受信(モバイル コネクト)した社内コールのすべてが切断されます。DTMF が PSTN から Unified CM に効果的にリレーできない場合、代わりにタイマー コントロールのモバイル ボイス メールの無効化方式を使用する必要があります。


シングル企業ボイス メール ボックスのボイス メールの回避機能に関する詳細情報については、「シングル企業ボイスメール ボックスによるモバイル ボイスメール回避」を参照してください。

Dial Via Office コール オプションの使用例

Dial Via Office を配置する場合、次の Cisco Jabber クライアントのコール オプションのユーザ プロファイルを考慮してください。

Automatically Select(デフォルトのコール オプション)

[Automatically Select] の一般的なユーザ プロファイルは、オフィス内とオフィス外の両方で移動するユーザです。このユーザ プロファイルの [Automatically Select] は、802.11 WLAN 接続が使用可能な場合、VoIP を利用することでコストをできるだけ抑え、WLAN 接続が使用できない場合は、モバイル ボイスおよびデータ ネットワーク(DVO およびモバイル コネクト)に戻ります。

Always Use DVO

[Always Use DVO] コール オプションの一般的なユーザ プロファイルは、IP 接続経由で優れた品質で信頼性も高い通話を実現するため、WLAN カバレッジがほぼなく、モバイル データ接続では満足なスループットと信頼性が得られない高度なモバイル ユーザです。

Always Use the Internet

[Always Use Internet] の一般的なユーザ プロファイルは、オフィス(自宅または会社)内で移動していて、社内コールが通常は社外への発信を必要としないユーザです。また、このユーザ プロファイルを使用する場合、モバイル ボイスおよびデータのコストは、企業負担および従業員負担のモバイル ボイスおよびデータ サービスの両方で重要な考慮事項です。

Dial Via Office Reverse

Cisco Jabber クライアントは Dial Via Office Reverse(DVO-R)をサポートします。DVO のこの方式では、Unified CM システムからユーザに設定されたモビリティ ID または携帯電話番号への着信コールによって実施されます。

図 23-27 は、DVO-R のコール フローを示します。この例では、Cisco Jabber ユーザは + 1 408 555 - 7890 で PSTN 電話機に電話します。ユーザは番号をダイヤルするか、Cisco Jabber クライアント内の連絡先リストから番号を選択し、企業および Unified CM(ステップ 1)に IP 接続経由で SIP コール セットアップ要求を生成します。コール セットアップ要求に基づいて、Unified CM は、社内 PSTN ゲートウェイ(ステップ 2)を使用してユーザの設定したモビリティ ID(携帯電話番号)にリバース コールを発信します。Unified CM からの着信コールがモバイル デバイスで応答されると、ユーザが呼び出した番号または選択した番号にコールが転送されます(ステップ 3:この場合は +1 408-555-7890)。一度コールが遠端で応答されると、メディア パスが接続され、会社の PSTN ゲートウェイ(ステップ 4)経由で固定されます。コールが会社のゲートウェイに固定されたため、ユーザは、このコール中の任意の時点で Unified Mobility のデスクトップフォン ピックアップ機能を使用したり、Unified Mobility DTMF ベースの通話切替機能を呼び出したりすることができます。

図 23-27 Cisco Jabber Dial Via Office Reverse

 


図 23-27 に示すコール フローは、Cisco Jabber が Unified CM に登録されていると想定し、DVO がユーザに対して有効で、クライアントのコール オプション設定が [Always Use DVO] または [Automatically Select] であると想定しています。クライアント設定が [Automatically Select] の場合、Cisco Jabber を実行しているデュアル モード デバイスはモバイル データ ネットワーク経由で IP 接続している必要があります。802.11 WLAN 経由で接続されている場合は、クライアントは DVO ではなく Voice over IP を使用します。


デフォルトで DVO-R コールバックのコール レッグは、図 23-27 に示すようにユーザのモバイル デバイスに転送されますが、ユーザは、Cisco Jabber クライアント内の [DVO Callback Number] フィールドに代替コールバック番号を指定することがあります。デフォルトで [DVO Callback Number] フィールドには、ユーザによって設定されたモビリティ ID が入ります。ユーザがこのフィールドに異なる番号を設定すると、DVO-R コールバックのコール レッグがその番号に転送されます。たとえば、ユーザはコールバックを携帯電話で受信するよりも、自宅の電話に転送できます。


) 代替コールバック番号を使用して DVO-R を呼び出す場合で、Unified CM からのコールバックのコール レッグがユーザ指定の代替番号へ転送される場合、そのコールは会社に固定されません。このような場合、ユーザはデスクトップフォンのピック アップを実行したり、代替コールバック番号を使用した DVO-R コールでの DTMF ベースの通話切替機能を呼び出したりすることはできません。また、ボイス メールの回避は DVO-R の代替番号へのコールに対して適用されません。


モバイル プロファイルおよび Dial Via Office Reverse

Cisco Unified CM モビリティ プロファイルはモバイル クライアント デバイス向けモビリティ ID に割り当てられる可能性があります。必須ではありませんが、モビリティ プロファイルは、モビリティ ID または代替コールバック番号に DVO-R コールバックのコール レッグのセットアップ時にシステムによって送信される発信者 ID を指定します。モビリティ プロファイル設定ページの [Dial-via-Office Reverse Callback Configuration] セクションの [Callback Caller ID] フィールドに設定された番号は、発信者 ID として送信される番号です モビリティ プロファイルが、モビリティ ID に割り当てられていない場合、または [Callback Caller ID] フィールドが空白のままである場合、システムは設定されたデフォルトのエンタープライズ機能アクセス番号を送信します。


) モビリティ プロファイルの [Mobile Client Calling Option] フィールドは、DVO 操作に影響しません。設定に関係なく、Cisco Jabber クライアントが DVO コールで有効である場合、DVO-R のコールを発信します。Dial via Office Forward(DVO-F)現在使用可能なコール オプションではありません。


Cisco Jabber と Cisco Unified Mobility との間の相互作用

Cisco Jabber モバイル クライアントを Cisco Unified Mobility に統合することで、Cisco Mobile Connect、通話切替 DTMF 機能、2 段階ダイヤリング、シングル企業ボイスメール ボックスのモバイル ボイスメール回避を利用できます。

Unified Mobility と統合するには、Unified CM 内で、iPhone または Android デュアルモード携帯電話番号を Cisco Dual-Mode for iPhone または Cisco Dual-Mode for Android デバイスに関連付けられたモビリティ ID として設定する必要があります。システム内で携帯の番号をモビリティ ID として設定した後は、iPhone または Android デュアルモード デバイスが企業に接続されず Unified CM に登録されていない場合に、モバイル コネクトを利用して、ユーザの会社の電話番号への着信コールをモバイル ボイス ネットワーク経由で iPhone または Android デュアルモード デバイスに転送できます。デュアル モード デバイスが会社に接続されていて、Unified CM に登録されている場合に、クライアントのコール オプションが設定されていると、着信 Voice-over-IP コールが有効(デバイスが WLAN に接続している場合の [Always Use Internet] または [Automatically Select])で、会社の電話番号に対する着信 IP コールはデバイスのモバイル ボイス ネットワーク インターフェイスに転送されません。iPhone または Android デュアルモード デバイスが企業に接続されている場合は、デバイスの WLAN またはモバイル データ インターフェイスだけが着信コールを受信します。これにより、会社の PSTN ゲートウェイ リソースの必要以上の消費を回避できます。

携帯電話音声ネットワークを介して社内コールを処理する場合、iPhone または Android デュアル モード デバイスは、DTMF を使用して通話切替機能を呼び出したり、会社の任意の固定コールに対するデスクトップフォンのピック アップを実行したりできます。また、デュアルモード デバイスでは、コールを発信する場合にモバイル ボイス アクセスとエンタープライズ機能アクセスの 2 ステージ ダイヤリング機能を利用して、これらのコールを会社経由でルーティングし、会社の PSTN ゲートウェイにアンカリングできます。

iPhone または Android デュアルモード デバイスにモビリティ ID を設定することに加えて、リモート接続先として追加の携帯電話番号またはオフシステム電話番号を設定して、それらの番号を Unified CM 内で Cisco Dual Mode for iPhone または Cisco Dual-Mode for Android デバイスに関連付けることができます。モビリティ ID および追加のリモート接続先をデュアルモード デバイスに関連付ける場合に、リモート接続先プロファイルを設定する必要はありません。

モバイル ユーザが複数のモバイル デバイスにまたがり複数のシスコ モバイル クライアントプロビジョニングする(Android スマート フォンで Cisco Jabber for Android を実行し、Apple iPad で Cisco Jabber for iPad を実行しているユーザなど)と、モビリティ ID をタブレット デバイス(Cisco Jabber for Tablet)ではなく、デュアル モード デバイス(Cisco Dual Mode for Android など)に関連付けます。デュアル モード デバイスは、デュアル モード ハンドオフや Dial Via Office などのモビリティ ID 固有の機能を利用するため、モビリティ ID をこのデバイスに関連付ける必要があります。モビリティ ID と同じデバイスに他のリモート接続先をすべて関連付けます。同じユーザに対して異なるモバイル クライアント デバイスの異なるリモート宛先を関連付けると、設定がより複雑になり、問題の修復が難しくなります。

Cisco Unified Mobility のフィーチャ セット、および設計と配置の考慮事項の詳細については、「Cisco Unified Mobility」を参照してください。

Cisco Jabber for iPad

ここでは、Cisco Jabber for iPad の特性および配置上の考慮事項について説明します。

Cisco Jabber for iPad は Apple iPad 用のモバイル クライアントであり、音声およびビデオのコーリング機能、および企業のビジュアル ボイス メールとディレクトリ アクセスを提供します。Cisco Jabber for iPad のクライアントは、オンプレミスの Cisco IM and Presence サービスまたは Cisco WebEx Messenger などのクラウドベースのコラボレーション サービスに統合される場合に XMPP ベースの IM およびプレゼンスを提供します。

クライアント アプリケーションが、iPad デバイスの Apple App Store からダウンロードされて iPad デバイスにインストールされると、企業ネットワークに接続し、Unified CM または Cisco TelePresence Video Communication Server(VCS)に SIP のエンタープライズ エンドポイントとして登録できます。 Cisco Jabber iPad クライアントに登録および呼制御サービスを提供するには、デバイスを Unified CM または VCS 内で設定する必要があります。Unified CM 呼制御サービスに登録すると、クライアント デバイスは、 Cisco Jabber for Tablet デバイスとして設定されます。VCS 呼制御サービスに登録する場合、クライアント デバイスは jabbertablet のプロビジョニング テンプレートと Cisco TelePresence Management Suite(TMS)を使用して設定およびプロビジョニングされます。

次に、企業の WLAN にアクセスして企業の WLAN インフラストラクチャおよびセキュリティ ポリシーに基づいて接続するようにクライアント デバイスを設定する必要があります。また、デバイスの企業ネットワークへの接続は、モバイル データ ネットワーク経由(デバイスがモバイル プロバイダーのデータをサポートし、モバイル データ サービスが有効である場合)または非企業 WLAN 経由で行うことができます。クライアント デバイスが企業のネットワークにアクセスするように設定されている場合、Cisco Jabber for iPad のクライアントは起動されると、音声およびビデオ呼制御サービス用の Unified CM または VCS にデバイスを登録します。

Cisco Jabber for iPad のクライアントは、Apple iOS の iPad 2 または新しい iPad でサポートされます。Apple iPad デバイスの WLAN インターフェイスは、802.11a、802.11b、802.11g、および 802.11n をサポートします。

最新の特定のデバイスおよびファームウェア バージョンの詳細については、次の Web サイトの製品リリース ノートを参照してください。

http://www.cisco.com/en/US/products/ps12430/prod_release_notes_list.html

Cisco Jabber for iPad クライアント、追加機能の内容、およびサポートされているハードウェアとソフトウェアのバージョンの詳細については、次の Web サイトの iPad のマニュアルには、Cisco Jabber for iPad マニュアルを参照してください。

http://www.cisco.com/en/US/products/ps12430/tsd_products_support_series_home.html

Cisco Jabber for iPad の配置に関する詳細情報については、次の URL にある『 Cisco Jabber for iPad Deployment Guide 』を参照してください

http://www.cisco.com/en/US/products/ps12430/product_solution_overview_list.html

Cisco Jabber IM

ここでは、Cisco Jabber IM の特性および配置上の考慮事項について説明します。

Cisco Jabber IM は、Android、BlackBerry、iPhone と他の Apple iOS のモバイル デバイス用の XMPP ベースのインスタント メッセージング(IM)とプレゼンス モバイル クライアントです。クライアント アプリケーションが適切なアプリケーション ストアまたはダウンロード サイト(Apple App Store、Google Play Store または Web)からダウンロードされ、Android、Apple iOS または BlackBerry デバイスにインストールされている場合、Cisco IM and Presence が提供するようなオンプレミスの企業 IM およびプレゼンス サービスのための企業ネットワークへの接続、または、オフプレミスの企業 IM およびプレゼンス サービスの Cisco WebEx Messenger サービスへの接続が可能となります。企業の WLAN にアクセスして企業の WLAN インフラストラクチャおよびセキュリティ ポリシーに基づいて接続するようにモバイル デバイスを設定する必要があります。または、モバイル デバイスをモバイル データ ネットワークまたは非企業 WLAN 経由で企業ネットワークに接続できます。企業ネットワークにアクセスするためにモバイル デバイスを設定すると、Cisco Jabber IM クライアントは、起動したときに適切な IM およびプレゼンス サービスに接続し、登録します。

Cisco Jabber IM クライアントは、Android 2.3、4.0、4.1 を実行する大部分の Android デバイスで利用可能です。Cisco Jabber IM クライアントは、iPhone、iPad などの Apple iOS デバイス(Apple iOS バージョン 4.2 以降)で使用可能です。Cisco Jabber IM クライアントは、BlackBerry OS 4.6 以降のバージョンが実行されている広範囲の BlackBerry デバイスでも利用できます。

Cisco Jabber IM クライアントの詳細情報については、次のマニュアルを参照してください。

Cisco Jabber IM for BlackBerry データ シート

http://www.cisco.com/en/US/products/ps11763/products_data_sheets_list.html

Cisco Jabber IM for Android データ シート

http://www.cisco.com/en/US/products/ps11678/products_data_sheets_list.html

Cisco Jabber IM for iPhone データ シート

http://www.cisco.com/en/US/products/ps11596/products_data_sheets_list.html

Cisco Jabber IM と Cisco Jabber との間の相互作用

Cisco Jabber IM クライアントでは、Cisco Jabber クライアント(インストールされている場合)のエスカレーションまたは相互起動が、連絡先の画面から企業の IP コール経由の音声またはビデオに実行できます。次に、Cisco Jabber クライアントは、連絡先の画面から企業 IM(インストールされている場合)に Cisco Jabber IM を相互起動できたり、チャットできたりします。

Cisco WebEx 会議

Cisco WebEx 会議モバイル クライアントは、特定の BlackBerry、Android、Apple iOS のモバイル スマート フォンやタブレットで実行されます。このクライアントによって、モバイル エンドポイントはデスクトップ ブラウザ ベースの Cisco WebEx 会議と同様に、同様の機能を持つ Cisco WebEx 会議に参加できます。このクライアントによって、Cisco WebEx 音声およびビデオ会議へのアクティブな参加(参加者リストや共有コンテンツを表示する機能など)が可能になります。

Cisco WebEx モバイル クライアントに関する詳細情報については、次の URL にある製品情報を参照してください。

http://www.cisco.com/en/US/products/ps12584/index.html

Cisco AnyConnect モバイル クライアント

Cisco AnyConnect モバイル クライアントは、Cisco Jabber モバイル デバイス クライアントの安全なリモート接続機能を提供し、モバイル データ ネットワークと非企業 WLAN 経由の接続を有効にします。Cisco AnyConnect モバイル クライアントは、Apple の App Store または Google Play(以前の Android Market)からダウンロードできます。このクライアント アプリケーションは、Cisco Adaptive Security Appliance(ASA)ヘッドエンドで利用可能な Cisco AnyConnect VPN ソリューションを使用して、Apple iOS および Android モバイル デバイスに SSL VPN 接続を提供します。

モバイル データ ネットワークあるいはパブリックまたはプライベートの Wi-Fi ホット スポットを介した接続に VPN ネットワーク接続を利用する場合は、企業のセキュリティ要件およびポリシーに沿った広帯域でセキュアな VPN インフラストラクチャを配置することが重要です。この接続を利用するユーザおよびデバイスの数に基づいた広帯域幅、信頼性の高い接続、および適切なセッションまたは接続キャパシティをこの VPN インフラストラクチャで提供できるよう、慎重に計画することが必要です。

Cisco AnyConnect を使用したセキュアなリモート VPN 接続の詳細については、次の Web サイトで入手可能な Cisco AnyConnect Secure Mobile Client マニュアルを参照してください。

http://www.cisco.com/en/US/products/ps10884/tsd_products_support_series_home.html

シスコのモバイル クライアントおよびデバイスのハイ アベイラビリティ

モバイル デバイス、特にデュアルモード フォンは、その特性上ネットワーク接続に関して非常に高い可用性を備えていますが(WLAN ネットワークが利用できない場合には、モバイル ボイスおよびデータ ネットワークを音声およびデータ サービスに使用可能)、企業の WLAN および IP テレフォニー インフラストラクチャのハイ アベイラビリティについてはまだ考慮すべき点があります。

まず、企業の WLAN は、冗長な WLAN アクセスが可能になるように配置する必要があります。たとえば、AP およびその他の WLAN インフラストラクチャ コンポーネントは、ワイヤレス AP の 1 つに障害が発生しても、モバイル デバイスのネットワーク接続には影響がないように配置する必要があります。同様に、常にモバイル デバイスがネットワークに安全に接続できるように、WLAN の管理およびセキュリティ インフラストラクチャも高い冗長性を備えた配置にする必要があります。企業内 AP の集中型設定および管理が可能であり、ネットワーク アクティビティおよび AP の障害に基づいて WLAN を動的に調整できることから、コントローラベースのワイヤレス LAN インフラストラクチャが推奨されます。

次に、VPN セッション端末の損失がモバイル クライアント デバイスのリモート セキュア企業接続に影響したり、妨げになったりしないように、Cisco ASA ヘッドエンド VPN または AnyConnect セッション端末を含む VPN インフラストラクチャ コンポーネントも高い冗長性を備えた配置にします。

次に、Unified CM の呼処理サービスおよび登録サービスのハイ アベイラビリティについて考慮する必要があります。Unified CM の呼処理サービスを利用する企業内の他のデバイスと同様に、モバイル クライアント デバイスも Unified CM に登録する必要があります。Unified CM クラスタのアーキテクチャにはプライマリおよびバックアップの呼処理サービスおよびデバイス登録サービスが用意されており、冗長な特性を持っているため、1 つの Unified CM サーバ ノードで障害が発生しても、モバイル デバイスの登録やコール ルーティングは引き続き利用可能です。

VCS の場合も同様に、呼処理のハイ アベイラビリティおよび登録サービスを考慮する必要があります。呼処理サービスに VCS を利用する企業内のデバイスは、VCS に登録する必要があります。モバイル クライアント登録の場合、VCS 冗長性は Domain Name Server(DNS)サービス(SRV)レコードを使用して実施されます。VCS クラスタ内の複数のノードを指すために DNS SRV レコードを使用することにより、デバイスの登録やコール ルーティングは VCS ノードに障害が発生した場合でも引き続き使用可能です。

PSTN アクセスについても同様の事項を考慮する必要があります。IP テレフォニー配置と同様、複数の PSTN ゲートウェイおよびコール ルーティング パスを配置して、PSTN への可用性の高いアクセスを確保する必要があります。このことは、モバイル クライアント デバイスの配置に固有の考慮事項ではありませんが、重要な考慮事項です。

シスコのモバイル クライアントおよびデバイスのキャパシティ プランニング

シスコのモバイル クライアントおよびデバイス(デュアル モード フォンを含む)におけるキャパシティ プランニングに関する考慮事項は、登録、呼処理、PSTN アクセス サービスのために、IP テレフォニー インフラストラクチャおよびアプリケーションを利用している他の IP テレフォニー エンドポイントまたはデバイスの場合と同じです。

シスコのモバイル クライアントとデバイスを Unified CM を使用して配置する場合、Unified Mobility の制限と同様 Unified CM の登録負荷を考慮することが重要です。1 つの Unified CM サーバでは、最大 40,000 のデバイスの設定および登録を処理できます。モバイル クライアントとデバイスを配置する場合、クラスタあたりでサポートされる最大デバイス数を考慮する必要があり、追加の負荷を処理するために呼処理クラスタを配置する必要があることもあります。

また、前に説明したように、1 つの Unified CM クラスタ内のリモート接続先およびモビリティ ID の最大数は 15,000 です。ほとんどのデュアルモード モバイル クライアント デバイスは、モバイル コネクト、シングル企業ボイスメール ボックス、モバイル ボイスメール、モバイル ボイスメール回避、デスクトップフォンのピックアップ、2 段階ダイヤリングなどの機能を利用するために Unified Mobility と統合されるとみられるため、これらの各デュアルモード モバイル デバイスの携帯電話番号を Unified CM クラスタ内のモビリティ ID として設定する必要があります。これは、Unified Mobility との統合を容易にするため、場合によってはハンドオフを容易にするために必要です。したがって、これらのデュアルモード デバイスを Unified Mobility と統合する場合には、Unified CM クラスタにおけるリモート接続先およびモビリティ ID の全体的な容量を考慮して、十分な容量を確保することが重要です。追加のユーザまたはデバイスがシステム内の Unified Mobility にすでに統合されている場合は、これらのユーザまたはデバイスによって、デュアルモード デバイスで利用可能なリモート接続先およびモビリティ ID の空き容量が制限される可能性があります。

CTI のキャパシティは、デスクトップフォンの統合を使用して Cisco Jabber for iPhone クライアントを配置する場合にも考慮する必要があります。この機能がデスクフォンのプライマリ回線の CTI モニタリングを必要とするため、デスクトップフォンの統合が有効な Cisco Jabber for iPhone モビリティ ユーザごとに Unified CM システムで CTI 接続が消費されます。この負荷は、システムの CTI キャパシティ全体に関連して考慮する必要があります。

Cisco VCS を使用してシスコのモバイル クライアントを配置する場合、VCS 登録の負荷を考慮することが重要です。1 つの VCS サーバでは、最大 10,000 のデバイスの設定および登録を処理できます。モバイル クライアントを配置する場合、サポート対象デバイスのクラスタ単位の最大数を考慮し、追加の負荷を処理するために VCS の追加配置が必要な場合があります。

モバイル クライアント デバイスを展開する場合、Unified CM または VCS システムおよび PSTN ゲートウェイの全体的な呼処理容量も考慮する必要があります。モバイル デバイスの実際の設定および登録を処理する以外に、こうしたシステムでは、これらのモバイル デバイスとユーザによって増加する BHCA の影響を吸収するために十分な容量も必要です。同様に、モバイル デバイスを処理するのに十分な PSTN ゲートウェイの容量を確保することも重要です。通常、デュアルモード モバイル デバイスを持つユーザは頻繁に移動することが多いため、Unified Mobility に統合されているデュアルモード デバイスではこのことは特に重要です。通常、頻繁に移動するユーザは、モバイル ユーザの会社の電話番号への着信コールによって PSTN への 1 つ以上のコールが発信されるモバイル コネクトなどのモビリティ機能や、会社の PSTN ゲートウェイを利用してユーザが会社経由でコールを発信する 2 ステージ ダイヤリングなどを使用することで、会社の PSTN ゲートウェイの負荷を高める傾向にあります。

最後に、シスコのモバイル クライアントとデバイスを配置する場合、企業モビリティ配置と同様に、802.11 WLAN コール キャパシティを考慮する必要があります。前述のとおり、802.11 チャネル セルあたり、最大 27 の VoWLAN コールまたは最大 8 の VVoWLAN コールが可能です。これは、デバイスが 2.4 GHz 帯域に配置され、VoWLAN コールに対して 24 Mbps 以上のデータ レート、および VVoWLAN のコールに対して最大 1 Mbps のビット レートで 720p のビデオ解像度の場合における Bluetooth なしを想定しています。実際のコール キャパシティは、RF 環境、ワイヤレス エンドポイント タイプおよび WLAN インフラストラクチャによって、さらに小さくなることがあります。802.11 WLAN コール キャパシティの詳細については、「キャンパス企業モビリティのキャパシティ プランニング」を参照してください。

上記の考慮事項は、モバイル クライアントおよびデバイスにすべて一意ではありません。これらの考慮事項は、デバイスやユーザが Unified CM または VCS に追加されることによってシステム全体の負荷が高まるすべての状況に当てはまります。

一般的なシステム サイジング、キャパシティ プランニング、および配置上の考慮事項の詳細については、「コラボレーション ソリューションの設計および配置サイジングに関する考慮事項」の章を参照してください。

シスコのモバイル クライアントおよびデバイスの設計上の考慮事項

シスコのモバイル クライアントとデバイスを配置する際は、次の設計上の推奨事項に従ってください。

モバイル ボイス ネットワークとモバイル データ ネットワーク、および WLAN ネットワークの両方に同時に接続するために、デュアルモード モバイル デバイスでは、デュアル転送モード(DTM)がサポートされている必要があります。これにより、デバイスのセルラー無線と WLAN インターフェイスの両方からデバイスに到達可能になり、両方のインターフェイスでコールを発信および受信できます。モバイル ボイス ネットワークおよびモバイル データ ネットワークでデュアル接続デバイスがサポートされていない場合には、適切なデュアルモード クライアント操作が実行できない場合があります。

WLAN AP は、20% 以上のセル オーバーラップを確保して配置する必要があります。このようにオーバーラップさせることによって、モバイル デバイスがロケーション内で移動した場合に AP 間で正常にローミングして、ボイス ネットワーク接続およびデータ ネットワーク接続を維持できます。

パケット損失を最小限に抑えるために、WLAN AP は -67 dBm のセル パワー レベル境界(またはチャネル セル半径)で配置する必要があります。また、同一チャネルのセル境界の分離は、約 19 dBm にする必要があります。19 dBm の同一チャネル セル分離は、AP またはクライアントにおいて、同じチャネルに関連付けられている他のデバイスとの同一チャネル干渉が発生しないようにするために重要です。同一チャネル干渉が発生すると、音声とビデオの品質が低下するためです。

可能であれば、音声およびビデオ トラフィックを生成できるモバイル クライアントとデバイスの接続用の 5 GHz WLAN 帯域(802.11a/n)を利用します。5 GHz WLAN は、音声コールとビデオ コールに対し、スループットを改善して干渉を低減します。

企業の有線および無線 LAN は、クライアント アプリケーションの音声とビデオ コールの品質、およびすべての機能の適切な動作を保証するために、音声メディアと専用ビデオおよびシグナリング帯域幅に対するプライオリティ キューイングを含む必要なエンドツーエンド QoS サービス クラスをサポートするように配置および設定する必要があります。ほとんどのクライアントがシスコの QoS の推奨事項に基づいてレイヤ 3 でトラフィックを適切にマークしますが、適切なレイヤ 2 WLAN UP マーキングはクライアント デバイスとベンダー実装に依存しています。このため、レイヤ 2 マーキングはプラットフォーム全体で一貫しておらず、依存できません。

モバイル デバイスがデスクトップ コンピュータに似ており、多種多様のデータおよびリアルタイム トラフィックを生成できるため、これらのデバイスは通常、信頼できないと見なされます。したがって、ネットワークは、ポート番号やプロトコルに基づいてこれらのクライアント デバイスからのすべてのトラフィックを再マーキングするように設定する必要があります。同様に、ネットワークへの入口のレート制限およびポリシングが推奨されます。

シスコでは、モバイル デバイスとクライアントの接続用のエンタープライズ クラスの音声およびビデオの最適化された WLAN ネットワークだけを使用することを推奨します。ほとんどのモバイル クライアント デバイスは、パブリックおよびプライベートの WLAN アクセス ポイントやホット スポットに接続し、インターネット経由で会社に接続して呼制御やその他の Unified Communications サービスを利用できますが、このようなタイプの接続の場合、音声とビデオの品質は保証されません。

シスコのコラボレーション モバイル クライアントおよびデバイスを Bring Your Own Device(BYOD)インフラストラクチャに配置する場合、ユーザの介入を必要とせず、IP テレフォニー インフラストラクチャを最大限に活用できるネットワーク接続方式を管理者は考慮する必要があります。さらに、リモート接続シナリオでは、シスコ モバイル クライアントとデバイスがコラボレーション サービスにアクセスできるように、すべての関連するポートを企業ファイアウォールでオープンにする必要があります。

BYOD インフラストラクチャにおいて、紛失または盗難されたモバイル デバイスをリモートで消去、あるいは工場出荷時の状態にリセットすることが企業のポリシーにより定められている場合、個人のモバイル デバイスを使用している従業員はポリシーを認識し、定期的に個人データをバック アップする必要があります。

Unified Mobility モバイル コネクト機能では、デュアルモード デバイスが社内にあり、Unified CM に登録されている場合には、着信コールはデュアルモード デバイスの設定されたモビリティ ID には転送されません。これは、企業の PSTN リソースの利用を削減するための仕様です。デュアルモード デバイスは Unified CM に登録されるため、システムでは、デバイスが社内で到達可能であるかどうかを把握できます。社内で到達可能である場合は、コールを PSTN に転送してデュアルモード デバイスのセルラー音声無線を呼び出す必要性がありません。モバイル コネクトでは、デュアルモード デバイスが登録されていない場合にだけ、ユーザの会社の電話番号への着信コールが公衆網のモビリティ ID 番号に転送されます。

モバイル デバイスを配置する場合は、モバイル デバイスが企業に接続されているかどうかにかかわらずユーザがダイヤリング手順を維持できるように、必要なダイヤル ストリングを正規化することを推奨します。モバイル ネットワークにおけるダイヤリングは、通常完全な E.164(先頭に「+」が付く場合と付かない場合があります)を使用して行われ、携帯電話の連絡先は通常完全な E.164 番号で保存されるため、モバイル クライアント デバイスにおいては、企業のダイヤル プランは完全な E.164 番号または先頭に「+」を付けた完全な E.164 番号を使用できるように設定することを推奨します。このように企業のダイヤル プランを設定することによって、ユーザはデバイスが Unified CM に登録されているかどうかを気にする必要がなくなるため、最善のエンド ユーザ ダイヤリング エクスペリエンスを提供できます。

デュアルモード電話のユーザが緊急コールを発信し、デバイスおよびユーザの位置を特定する場合には、モバイル ボイス ネットワークのみを利用することを推奨します。これは、通常モバイル プロバイダー ネットワークでは、WLAN ネットワークよりもはるかに信頼性のある位置情報が提供されるためです。デュアルモード電話で緊急サービスおよび位置サービスにモバイル プロバイダーのボイス ネットワークのみが利用されるようにするには、Unified CM 内のデュアルモード デバイスの [Emergency Numbers] フィールドに 911、999、112 などの緊急番号を設定し、これらのコールを強制的にモバイル ボイス ネットワーク経由で発信します。デュアルモード電話機のユーザに対して、すべての緊急コールを企業ネットワークではなくモバイル ボイス ネットワーク経由で発信するように指示します。企業の WLAN またはモバイル データ ネットワークを介した緊急コールを発信することは推奨されませんが、携帯電話音声の無線がないモバイル デバイスは、これらのデータ インターフェイスを経由する場合に限り発信できます。携帯電話音声の無線がないモバイル デバイスは、緊急コール発信用に利用すべきではありません。

デスクフォンの統合を使用して Cisco Jabber for iPhone を配置する場合は、Cisco Jabber ユーザのエンド ユーザ アカウントが CTI で有効になっている必要があります。また、デスクフォンが通話を自動でパークし、通話がデスクトップフォンから Cisco Jabber クライアントに転送された場合は常に Cisco Jabber クライアントが取得できるよう、コール パークをシステム レベルで設定する必要があります。Unified CM システム全体をサイジングする場合、この機能の CTI オーバーヘッドを考慮する必要があります。

Cisco Jabber for iPhone または Android モバイル クライアントを配置する場合は、次の配置ガイドラインに従って WLAN ネットワークを設定してください。

WLAN のレイヤ 3 で Cisco Jabber for iPhone および Android モバイル デバイスのローミングを最小限に抑えます。デバイスの IP アドレスが変わるレイヤ 3 のローミングでは、ローミング時間が長くなり、音声パケットがドロップされ、コールがドロップされる場合もあります。

最も高速な AP 間ローミングを確保するために、WLAN 内の Cisco Jabber モバイル クライアント デバイスで使用されるすべての AP に対して同一の SSID を設定します。

コール中に WLAN インフラストラクチャ内の他の AP に参加するように求められるとコールが中断されるおそれがあるので、これを防ぐために、会社のすべての WLAN AP を自身の SSID をブロードキャストするように設定します。

モビリティ対応ユーザの BHCA レートに基づき求められるコール キャパシティを処理できる適切な数のワイヤレス AP を配置することで、シスコのモバイル クライアントおよびデバイスの企業ワイヤレス ネットワークに十分なワイヤレス音声およびビデオ コールのキャパシティを提供します。各 802.11g/n(2.4 GHz)または 802.11a/n(5 GHz)チャネル セルは、24 Mbps 以上のデータ レートで最大 27 の同時音声のみのコールをサポートできます。各 802.11g/n(2.4 GHz)または 802.11a/n(5 GHz)チャネル セルは、最大 1 Mbps ビット レートでビデオ解像度 720p の場合、最大 8 の同時ビデオ コールをサポートできます。2.4 GHz WLAN 配置では、このキャパシティを実現するには Bluetooth を無効にする必要があります。実際のコール キャパシティは、RF 環境、ワイヤレス エンドポイント タイプおよび WLAN インフラストラクチャによって、さらに小さくなることがあります。

Dial via Office Reverse(DVO-R)を配置する場合、ユーザ制御のモバイル ボイス メールの無効化方式を使用すると、発信側ユーザのボイス メール ボックスに転送されないことが保証されます。このボイス メールの無効化方式では、DVO-R コールを接続するため、発信側ユーザがモバイル デバイスのキー パッドの番号を押す必要があります。モバイル デバイスのキーを押さなかった場合、DVO コールがクリアされます。

代替コールバック番号を使用する DVO-R コールは、会社に固定されていないので、デスクトップフォンのピック アップと DTMF ベースの通話切替機能は、これらのコールに使用されない場合があります。また、ボイス メールの無効化は、代替コールバック番号に対するコールに使用されません。

モバイル ユーザが複数のモバイル デバイスにまたがり、複数のシスコ モバイル クライアントによってプロビジョニングされると、モビリティ ID および追加のリモート接続先は、Cisco Jabber デュアル モード デバイス タイプと常に関連付ける必要があります。