Cisco Unified Communications システム リリース 8.x SRND
モバイル ユニファイド コミュニケーション
モバイル ユニファイド コミュニケーション
発行日;2012/12/18 | 英語版ドキュメント(2012/07/30 版) | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 39MB) | フィードバック

目次

モバイル ユニファイド コミュニケーション

この章の新規情報

社内型モビリティ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

デバイス モビリティ

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

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

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

リモート企業モビリティ

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

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

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

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

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

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

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

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

社外型モビリティ

Cisco Unified Mobility

モバイル コネクト

モバイル コネクトの機能

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

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

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

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

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

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

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

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

Cisco Unified Mobility の配置の設計

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

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

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

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

デュアルモードの電話機とクライアント

デュアルモード電話機のアーキテクチャ

デュアルモード電話機のハイ アベイラビリティ

デュアルモード電話機のキャパシティ プランニング

デュアルモード電話機の設計上の考慮事項

Cisco Unified Mobile Communicator

Cisco Unified Mobile Communicator の電話サポートとデータ プラン要件

Cisco Unified Mobile Communicator のアーキテクチャ

Cisco Unified Mobile Communicator の機能

Cisco Unified Mobile Communicator のハイ アベイラビリティ

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

Cisco Unified Mobile Communicator の設計上の考慮事項

ダイレクト コネクト モバイル クライアント

ダイレクト コネクト モバイル クライアントのアーキテクチャ

ダイレクト コネクト モバイル クライアントの機能

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

ダイレクト コネクト モバイル クライアントのキャパシティ プランニング

ダイレクト コネクト モバイル クライアントの設計上の考慮事項

モバイル ユニファイド コミュニケーション

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

Unified Communications のモビリティ ソリューションは、主に次の 2 つのカテゴリに分けられます。

社内型モビリティ

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

社外型モビリティ

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

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

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

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

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

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

マルチサイト モビリティ

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

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

このタイプのモビリティでは、ユーザは社外のロケーションに移動しても、仮想的に企業ネットワークをリモート ロケーションまで拡張して、何らかの安全な形式で会社に接続できます。このタイプのモビリティは一般に、Cisco Virtual Office や、VPN ベースの電話機や Office Extend Access Point 機能などのその他のリモート接続方法などの、リモート テレワーカーに対するソリューションが含まれます。

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

Cisco Unified Mobility

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

デュアルモードの電話機とクライアント

デュアルモードの電話機とデバイスには、802.11 ワイヤレス LAN ネットワークと携帯電話音声およびデータ ネットワークの両方に接続できる二重無線アンテナが装備されています。これらのデバイスに配置されたデュアルモード クライアントにより、Unified CM に企業ワイヤレス LAN 経由、またはインターネットベースのセキュア接続(パブリックまたはプライベートの WLAN ホット スポットあるいはモバイル データ ネットワーク)上で関連付けることができ、その後企業の IP テレフォニー インフラストラクチャを発信および着信に利用できます。モバイル ユーザがこれらのデバイスで会社に接続できない場合、モバイル ボイス プロバイダー ネットワークを使用して電話のコールが発着信されます。

Cisco Unified Mobile Communicator

Cisco Unified Mobile Communicator ソリューションを使用すると、企業用のさまざまな Unified Communications アプリケーションにユーザのモバイル デバイスからリモート アクセスできます。安全なモバイル データ接続を介して企業に接続し、Cisco Unified Mobile Communicator クライアントが企業のモビリティ機能やルーティング、ボイスメール、プレゼンス サービスにアクセスします。

ダイレクト コネクト モバイル クライアント

ダイレクト コネクト モバイル クライアントを使用した場合も、企業用の音声およびコラボレーション アプリケーションや、コール ルーティング、社内ディレクトリ アクセス、ならびにプレゼンスおよびインスタント メッセージング サービスなどのサービスにユーザのモバイル デバイスから安全にリモート アクセスできます。これらのクライアントはデュアルモード機能も提供し、企業の WLAN ネットワークに接続したときの Voice over WLAN 機能を有効にします。

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

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

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

社内型モビリティ

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

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

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

社外型モビリティ

「Cisco Unified Mobility」

「デュアルモードの電話機とクライアント」

「Cisco Unified Mobile Communicator」

「ダイレクト コネクト モバイル クライアント」

この章の新規情報

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

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

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

細部の訂正および変更

この章の各項で説明

2012 年 7 月 31 日

iPhone 対応の Cisco Jabber デュアルモード/ダイレクト コネクト モバイル クライアント

「デュアルモード クライアント:Cisco Mobile および Cisco Jabber」

2012 年 4 月 30 日

XMPP ベースの IM およびプレゼンス対応の Cisco Jabber IM クライアント

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

2012 年 4 月 30 日

Nokia Call Connect、Cisco Unified Mobile Communicator、および Cisco Mobile 8.5 for Nokia の販売終了(EoS)およびサポート終了日(EoL)のお知らせ

「デュアルモード クライアント:Nokia Call Connect」

「Cisco Unified Mobile Communicator」

「ダイレクト コネクト モバイル クライアント:Cisco Mobile 8.5 for Nokia」

2012 年 4 月 30 日

音声品質、接続上の問題、Cisco AnyConnect と Jabber Secure Connect など、モバイル クライアントのリモート セキュア接続に関する考慮事項

「デュアルモード電話機のアーキテクチャ」

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

「Cisco AnyConnect および Secure Connect」

「VPN インフラストラクチャ」

2012 年 4 月 30 日

細部の訂正および変更

この章の各項で説明

2011 年 7 月 29 日

Android デバイス対応の Cisco Jabber 8.6 デュアルモード クライアント

「デュアルモードの電話機とクライアント」

2011 年 6 月 2 日

Cisco Mobile 8.5 for Nokia クライアントのサポートを含む、ダイレクト コネクト モバイル クライアント ソリューション

「ダイレクト コネクト モバイル クライアント」

2011 年 6 月 2 日

モバイル トール バイパスの最適化機能

「モバイル トール バイパスの最適化」

2011 年 6 月 2 日

セッション再開機能(以前の Dial-via-office 転送リダイヤル)

「セッション再開」

2011 年 6 月 2 日

Cisco Mobile iPhone デュアルモード クライアントのデスクトップフォンの統合

「デュアルモード クライアント:Cisco Mobile および Cisco Jabber」

2010 年 11 月 15 日

企業キャンパス、マルチサイト、およびリモート モビリティ ソリューションおよび機能

「社内型モビリティ」

2010 年 11 月 15 日

元のデバイス モビリティの章はこのバージョンの SRND から削除され、内容は モバイル ユニファイド コミュニケーションのこの章に統合されました。

「デバイス モビリティ」

2010 年 11 月 15 日

エンタープライズ機能アクセス 2 ステージ ダイヤリング機能オートメーションが Nokia Call Connect デュアルモード クライアントで利用可能になりました。

「デュアルモード クライアント:Nokia Call Connect」

2010 年 7 月 23 日

Cisco Mobile iPhone デュアルモード クライアントのハンドアウトのハンドオフ番号方式

「デュアルモード クライアント:Nokia Call Connect」

2010 年 7 月 23 日

Cisco Mobile iPhone デュアルモード クライアントの AP-to-AP ローミングに関する WLAN 設計ガイドライン

「Cisco Mobile および Cisco Jabber デュアルモード クライアントの WLAN 設計上の考慮事項」

2010 年 7 月 23 日

Nokia Call Connect デュアルモード クライアントのハンドオフと AP-to-AP ローミングに関する WLAN 設計ガイドライン

「Nokia Call Connect デュアルモード クライアントの WLAN 設計上の考慮事項」

2010 年 7 月 23 日

Cisco Mobile iPhone デュアルモード クライアントおよび Nokia Call Connect デュアルモード クライアントのサポートを含む、デュアルモード電話機のソリューション

「デュアルモードの電話機とクライアント」

2010 年 4 月 2 日

企業内から発信され、発信先がリモート接続先番号やモビリティ ID 番号のコールのモビリティ コール アンカリングを行う Intelligent Session Control 機能

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

2010 年 4 月 2 日

*74(デフォルトの機能アクセス コード)を使用した新しい通話切替セッション ハンドオフ機能、およびデスクトップフォンのピックアップ操作の意味

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

2010 年 4 月 2 日

Cisco Business Edition の Unified Mobility キャパシティ プランニング情報

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

2010 年 4 月 2 日

社内型モビリティ

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

ワイヤレス デバイスの例としては、Cisco Unified Wireless IP Phone 7925G、無線で接続された Cisco Unified IP Phone 9971、Cisco Cius、Cisco Mobile 8.5 for Nokia などのダイレクト コネクト モバイル クライアント(「ダイレクト コネクト モバイル クライアント」を参照)、および Cisco Jabber、Nokia Call Connect などのデュアルモード電話クライアント(「デュアルモードの電話機とクライアント」を参照)などが挙げられます。

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

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

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

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

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

 

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

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

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

 


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


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

ほとんどのワイヤレス 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)

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

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

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

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

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

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

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

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

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

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

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

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

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

企業 WLAN 内にワイヤレス デバイスを配置し、ワイヤレス デバイス ローミングを利用する場合、WLAN インフラストラクチャのデバイスの接続性とコール キャパシティを考慮することも重要です。デバイス数またはアクティブ コール数の面でのキャンパス WLAN インフラストラクチャのオーバーサブスクリプションは、無線接続のドロップ、音声品質の低下、またはコール セットアップの遅延や失敗の原因となります。必要なコール キャパシティを処理するのに十分な数の AP を配置することによって、VoWLAN の配置においてオーバーサブスクリプションが発生する確率を大幅に減少できます。AP のコール キャパシティは、単一チャネル セル領域内でサポートできる同時 VoWLAN 双方向ストリーム数に基づきます。VoWLAN のコール キャパシティの一般的なルールは次のとおりです。

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

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

これらのコール キャパシティ値は、RF 環境、VoWLAN 無線ハンドセット機能、および基礎となる WLAN システム機能に大きく依存します。一部の配置では、実際のキャパシティはこれよりも小さくなることもあります。


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


EM のスケーラビリティは、Unified CM 内のログイン率およびログアウト率にほぼ依存します。ログインおよびログアウトの操作負荷がクラスタの 2 ノードに分散した場合、1 分あたり最大 375 回の順次ログインおよびログアウト操作が、1 つの Unified CM クラスタでサポートされます。Unified CM クラスタ サーバ ハードウェアによっては、配置のキャパシティがこれより少なくなる可能性もあります。したがって、十分な EM ログイン/ログアウト キャパシティがモバイル ユーザに提供できるよう、Unified CM クラスタ内で有効なエクステンション モビリティ ユーザ数と、キャンパス内を移動するユーザ数、任意の時間にこの機能を使用しているユーザ数を知ることが重要です。EM のキャパシティ プランニングの詳細については、「エクステンション モビリティのキャパシティ プランニング」を参照してください。

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

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

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

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

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

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

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

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

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

キャンパス ネットワークのワイヤレス音声コールのキャパシティは十分に用意してください。そのためには、無線ユーザの BHCA レートに基づき、目的のコール キャパシティの処理に適した数のワイヤレス AP を展開します。各 802.11g(2.4 GHz)または 802.11a(5 GHz)チャネル セルは、24 Mbps 以上のデータ レートで 27 個の同時双方向ストリームまたはコールをサポートできます。802.11g 配置では、このキャパシティを実現するには Bluetooth を無効にする必要があります。

1 分あたり最大 375 回の順次ログインまたはログアウトが単一の Unified CM クラスタでサポート可能です。最大 2 つの Unified CM サブスクライバ ノードが、アクティブに EM ログインを処理できます。EM のキャパシティの詳細については、「エクステンション モビリティのキャパシティ プランニング」を参照してください。

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

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

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

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

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

 


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


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

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

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

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

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

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

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

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

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

分散型呼処理環境では、有線電話機と同様、コール ルーティングに伴う問題が発生する可能性を避けるため、単一の Unified CM クラスタのみに登録するようワイヤレス デバイスを設定する必要があります。

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

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

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

デバイス モビリティ

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

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

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

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

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

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

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

 

支社 1 のユーザが支社 2 に移動し、Denver にいる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 クラスタでデバイス モビリティを有効にし、設定する必要があります。


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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

デバイス モビリティ機能を使用する場合、電話機のダイヤリング動作は電話機のローミング(またはホーム)ロケーションに依存します。前述したように、デバイス プール内のデバイス モビリティ関連設定が、コール フローの動作に影響します。これは、コーリング サーチ スペースが、Unified CM 内の宛先パターンの到達可能性を示すためです。この項では、デバイス モビリティのための複数のダイヤル プラン アプローチについて説明します。

さまざまなダイヤル プラン アプローチの詳細については、「ダイヤル プラン」の章を参照してください。

サービス クラスを構築するためのデバイス モビリティの考慮事項

ローミング中のモバイル ユーザは、一般に、ホーム ロケーションにいるときと同じコール特権を持つ必要があります。「ダイヤル プラン」の章では、サービス クラスを構築するための 2 つのアプローチについて説明します(「従来のアプローチ」および「回線/デバイス アプローチ」)。

従来のアプローチ

従来のアプローチでは、パス選択とサービス クラスはいずれも、デバイスレベルのコーリング サーチ スペースにより決定されます。回線/デバイス アプローチでは、パス選択はデバイスレベルのコーリング サーチ スペースにより決定され、サービス クラスは回線レベルのコーリング サーチ スペースにより決定されます。いずれの配置でも、サービス クラスの構築には回線/デバイス アプローチを推奨します。特に、デバイス モビリティを使用する配置においては、回線/デバイス アプローチを使用することが重要です。このアプローチを使用すると、モバイル デバイスから発信されたコールはいずれもホーム サイト ゲートウェイでなくローミング サイトまたはローカル ゲートウェイを使用するためです。従来のアプローチも使用できますが、この章では、推奨される回線/デバイス アプローチだけを取り上げます。従来のアプローチの全般的な説明は、「ダイヤル プラン」の章を参照してください。

回線/デバイス アプローチ

Unified CM では、所定の IP 電話の回線およびデバイスのコーリング サーチ スペースを連結します。回線/デバイス アプローチにおいては、次の概念が重要です。

デバイス コーリング サーチ スペースは、コール ルーティング情報を提供します。

回線コーリング サーチ スペースは、サービス クラス情報を提供します。

デバイス モビリティ機能を使用すると、デバイス コーリング サーチ スペースは、電話機のロケーションに基づいて、動的に電話機に関連付けられます。デバイス モビリティを使用する場合に、回線/デバイスにおける重要な概念は、引き続き同じです。回線コーリング サーチ スペースがサービス クラス情報を提供する一方、選択されたローミングまたはホーム デバイス コーリング サーチ スペースは、コール ルーティング情報を提供します。

図 25-9 は、クラスタ内でデバイス モビリティを使用する場合に、回線/デバイス アプローチを使用してサービス クラスを構築する例を示します。

図 25-9 サービス クラスを構築するための回線/デバイス アプローチ

 

回線/デバイス アプローチを使用して、サービス クラスを構築することを推奨します。このモデルでは、次の公式が示すように、必要なデバイス プールの数が大幅に削減されるため、デバイス モビリティを使用するうえで重要な利点があります。

合計デバイス プール数 =(サイト数)

このアプローチには、次の設計上の考慮事項が適用されます。

電話デバイスのコーリング サーチ スペースは NONE に設定できます。デバイス プールのコーリング サーチ スペース設定が電話デバイスに割り当てられます。この方法では、電話機にデバイス コーリング サーチ スペースを個別に設定する必要がないため、設定の量を大幅に削減できます。

同じサービス クラスまたはコール特権をすべてのモバイル ユーザに設定することに関して制限はありません。サービス クラスは、回線コーリング サーチ スペースを使用して定義されるため、モバイル ユーザはローミング中に同じサービス クラスを維持します。

モバイル ユーザはプロファイルのデバイス モビリティとエクステンション モビリティの両方を有効にできます。

ダイヤル プラン モデルの選択

「ダイヤル プラン」の章で説明したように、ダイヤル プラン モデルには主に 3 つのアプローチがあります。

固定オンネット ダイヤリング

分割アドレッシングの可変長のオンネット ダイヤリング

フラット アドレッシングの可変長のオンネット ダイヤリング

次の項では、サービス クラスを構築するためのアプローチと組み合わされたさまざまなダイヤル プラン モデルを示します。

回線/デバイス アプローチを使用する固定オンネット ダイヤリング

図 25-10 は、デバイス モビリティのための固定オンネット ダイヤル プランを示します。

図 25-10 デバイス モビリティのための固定オンネット ダイヤル プラン

 

これは、最も基本的なダイヤル プラン モデルであり、次の特性があります。

モバイル ユーザは、すべてのロケーションから短縮ダイヤル(図 25-10 の例に示されている 4 桁)を使用できます。

内線用の短縮設定されたスピード ダイヤルが、ローミング ロケーションにいるユーザの電話機で引き続き動作します。

モバイル ユーザがリモート ロケーションにいるときは、「ローミング」コーリング サーチ スペースが使用されます。サイトすべてのPSTN コールに同じアクセス コードを設定することを推奨します。PSTN アクセス コードが同じでないと、ユーザは、さまざまなアクセス コードを知る必要があります。

回線/デバイス アプローチを使用する、分割アドレッシングの可変長のオンネット ダイヤリング

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

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

 

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

モバイル ユーザがローミング ロケーションから短縮ダイヤルを使用すると、コールが誤った宛先にルーティングされることがあります。図 25-11 の例で、サイト 1 のモバイル ユーザ 1 の内線が 1000 であり、サイト 2 に移動するとします。ユーザ 1 がサイト 1 にいるユーザと通話しようと 1001 をダイヤルすると、コールは代わりにサイト 2 の内線 1001 にルーティングされます。この動作が望ましくない場合は、各サイトをデバイス モビリティ グループとして定義することを検討してください。図 25-8 に示すように、デバイスがローミングを行うときに、「ホーム」デバイス プールのデバイス モビリティ グループが、デバイス モビリティ情報の「ローミング」デバイス プールで定義されているデバイス モビリティ グループと異なる場合、「ローミング」デバイス プールからのローミング依存設定だけが適用されます。つまり、ローミング電話機がコールを発信するときに、ローミング依存の設定ではないデバイス モビリティ コーリング サーチ スペースは使用されず、(電話機のデバイス レベル設定またはデバイス プール設定で定義されている)「ホーム」コーリング サーチ スペースが使用されます。図 25-11 に示す例では、ユーザ 1 が内線番号 1001 をダイヤルすると、サイト 2 で「ホーム」サイトのコーリング サーチ スペースを使用してコールがルーティングされ、その結果、サイト 1 ではコールが内線番号が 1001 にルーティングされます。ただし、このコール シナリオでは、WAN 帯域幅が消費されます。さらに、この例でユーザ 1 が外部PSTN コールにダイヤルしたとすると、ローミング電話機はホーム ゲートウェイも使用します。また、「ホーム」サイトのコーリング サーチ スペースが使用されるため、WAN 帯域幅も消費します。

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

短縮設定のスピード ダイヤルを使用しないでください。すべてのロケーションでユーザがスピード ダイヤルを使用できるようにする普遍的な方法でスピード ダイヤルを設定することを推奨します。たとえば、ユーザは、E.164 番号を使用するか、サイト コードおよびアクセス コードを使用してスピード ダイヤルを設定できます。

複数のサイトの内線番号が重複していると、ローミング ユーザがリモート SRST ゲートウェイに登録されたときに問題を引き起こすことがあります。図 25-11 の例で、サイト 1 のモバイル ユーザ A の内線が 1000 であり、サイト 2 に移動するとします。さらに、サイト 2 の WAN リンクがダウンし、電話機がサイト 2 の SRST ゲートウェイに登録されることになったとします。SRST ゲートウェイにおける内線 1000 への着信コールは、実際のサイト 2 の内線 1000 のほかに、内線番号が 1000 であるモバイル ユーザにもルーティングされます。この結果、コールが適切にルーティングされないことがあります。この問題は、ネットワーク全体で一意の内線番号を使用することにより回避できます。

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

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

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

 

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

モバイル ユーザは、別のサイトにローミングした後では、コールが誤った宛先にルーティングされるおそれがあるため、短縮ダイヤルを使用できません。この動作が望ましくない場合は、各サイトをデバイス モビリティ グループとして定義することを検討してください。ただし、ユーザは、外部PSTN コールすべてで、モバイル電話では引き続きホーム ゲートウェイが使用され、したがって WAN 大域幅が消費されることを承知しておく必要があります。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

一般的に、ダイヤル プランには常に回線/デバイス アプローチを使用することが推奨されます。特にこれが重要なのは、デバイス モビリティを配置する際に、各モバイル ユーザに異なるサービス クラスまたはコーリング特権が許可されるためです。回線/デバイス アプローチでは、サービス クラスは、デバイスの回線コーリング サーチ スペースを使用して定義されます。これはローミング時も変わらず、モバイル ユーザはローミング時も同じサービス クラスを保持できます。

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

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

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

リモート企業モビリティ

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

図 25-14 は、Cisco IP Communicator ソフトウェア電話がリモート サイトのコンピュータで実行されている、クライアントベースの安全なリモート接続の例です。このソフトウェアベースの IP 電話は、クライアントベースの VPN を介して企業に接続され、Unified CM に登録されています。

図 25-14 リモート サイトの Cisco IP Communicator 向けのクライアントベースの 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

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

リモート サイト モビリティ環境では、企業 VPN サービスが、冗長性を備えた方法で企業内に構成され配置されている必要があります。これにより確実に、クライアントベースおよびルータベース両方の安全な接続の可用性が高くなります。企業内の VPN コンセントレータに障害がある場合、新しい安全な接続を、他の VPN コンセントレータでセットアップできます。このタイプの配置では、デバイス登録および音声サービスの可用性は、組み込み Unified CM ノードの冗長性のおかげで高くなります。

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

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

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

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

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

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

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

社外型モビリティ

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

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

Cisco Unified Mobility ソリューションに付属のモビリティ機能は、Cisco Unified Communications Manager(Unified CM)を通して提供され、Cisco Unified Mobile Communicator アプリケーション、デュアルモード デバイス、およびダイレクト コネクト クライアント デバイスと組み合わせて使用できます。

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

モバイル コネクト

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

通話切替機能

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

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

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

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

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

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

Cisco Unified Mobile Communicator アプリケーションには、バックホール データ チャネルの使用によってユーザの携帯電話にエンタープライズ向けのユニファイド コミュニケーション機能を提供するモバイル クライアントが含まれます。データ チャネルはインターネット上のサービス プロバイダー データ サービスによって送信され、Cisco Adaptive Security Appliance(ASA)で終端処理されてから、企業の Unified Communications インフラストラクチャ内のさまざまなアプリケーションやコンポーネントとインターフェイスする Unified Mobility Advantage サーバに転送されます。音声サービスでは、PSTN およびモバイル ボイス ネットワークが利用されます。

Cisco Unified Mobile Communicator アプリケーションと統合可能なエンタープライズ アプリケーションおよび機能を次に示します。

ユーザ認証およびディレクトリ ルックアップ用の Microsoft Active Directory を使用した LDAP ディレクトリ

ユーザの企業ボイスメール ボックスのメッセージ待機インジケータおよび視覚ナビゲーション用の Cisco Unity または Unity Connection を使用したボイスメール

会議通知の受信用の Cisco Unified MeetingPlace を使用した会議とコラボレーション

Cisco Unified Personal Communicator などの他のクライアントやアプリケーションとのプレゼンス情報の交換やバディ リストの同期化を可能にする、Cisco Unified Presence とのプレゼンス統合

ユーザの卓上電話からのコール履歴ログの受信およびエンタープライズ IP テレフォニー インフラストラクチャ経由のダイヤリング用の Cisco Unified Communications Manager(Unified CM)を使用したエンタープライズ コール ログと Dial-via-office

その他の Cisco Unified Mobile Communicator クライアントを使用したテキスト メッセージの送受信用のメッセージング

さまざまなエンタープライズ ユニファイド コミュニケーション アプリケーションとの統合機能の提供に加えて、Cisco Unified Mobile Communicator モバイル クライアントと Unified Mobility を統合してモバイル コネクトやシングル企業ボイスメール ボックスなどの機能を利用できます。

ダイレクト コネクト モバイル クライアントを使用すると、携帯電話から、モバイル データ ネットワーク経由で企業ネットワークにリモート接続、または企業 WLAN 経由でローカル接続して、Dial-Via-office および Voice over WLAN などの音声機能や、社内ディレクトリ アクセス、プレゼンスおよび Instant Massaging(IM; インスタント メッセージング)などのその他のユニファイド コミュニケーション サービスを利用できます。これらのダイレクト コネクト クライアントは、Cisco Unified Mobile Communicator と同様の機能(Dial-via-office、社内ディレクトリアクセス、プレゼンスなど)、およびデュアルモード電話やクライアントなどの音声 WLAN 機能を提供するため、モバイル ユーザは社内、社外に関係なくコラボレーション アプリケーションにアクセスでき、生産性を保つことができます。また同時に、社外からパブリックまたはプライベートの Wi-Fi ホット スポットあるいはモバイル データ ネットワークを利用するか、社内で WLAN ネットワークを利用するかにかかわらず、モバイル デバイスからビジネス コールを発信および受信することを可能にします。

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

「Cisco Unified Mobility」

「デュアルモードの電話機とクライアント」

「Cisco Unified Mobile Communicator」

「ダイレクト コネクト モバイル クライアント」

Cisco Unified Mobility

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

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

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

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

図 25-15 Cisco Unified Mobility の設定アーキテクチャ

 

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


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


モバイル コネクト

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

モバイル コネクトの機能

図 25-16 に、基本的なモバイル コネクトのコール フローを示します。この例では、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)。どちらの電話機でも応答できます。

図 25-16 モバイル コネクト

 

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


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



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


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

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

図 25-17 デスクトップフォンのピックアップ

 

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


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


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

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

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

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

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

 

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


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


通話切替機能

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

図 25-19 モビリティ通話切替機能

 

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


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



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


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

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

表 25-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 モバイル コネクトに関する追加の考慮事項は、モバイル ボイスメール回避です。シングル企業ボイスメール ボックス機能では、応答がないすべての企業ビジネス コールは最終的に企業ボイスメール システムに転送されます。これによって、ユーザは、会社の電話番号への応答がないコール用に用意された複数のメールボックス(会社、携帯電話、自宅など)をチェックする必要がなくなります。この機能を実装するために、システムは一連のタイマー(リモート接続先ごとに 1 つずつ)とシステムのコール転送タイマーを併用します。これらのタイマーの目的は、コールが無応答呼び出しでボイスメール ボックスに転送されたときに、そのコールがリモート接続先のボイスメール ボックスではなく、会社のボイスメール ボックスに転送されることを保証することです。これらのタイマーは、他のシステム無応答転送タイマーとともに、次のように非企業ボイスメール システムを回避するように設定する必要があります。

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

これを実現するために、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,000 ミリ秒(つまり 19 秒)に設定されます。このタイマーが切れる前にコールに応答がなかった場合、リモート接続先へのコール レッグが切断されます。これにより、コールがモバイル ボイスメール システムに転送されるまでリモート接続先電話機で呼び出しが停止されます。


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



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


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

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

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

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

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

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

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

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

モバイル クライアント

Cisco Unified Mobile Communicator またはダイレクト コネクト モバイル クライアントを搭載したモバイル デバイスを使用するユーザは、クライアント設定でモバイル コネクトまたはシングル ナンバー リーチの設定を有効または無効に変更することによって、モバイル コネクト機能のステータスを切り替えることができます。この操作では、Cisco Unified Mobile Communicator またはダイレクト コネクト モバイル クライアントのモビリティ ID のみに対してモバイル コネクトが有効または無効になります。

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

アクセス リストは、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 を設定してリモート接続先に関連付けることができます。

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

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

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

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

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

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

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

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

 

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

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

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 が、コール ルーティングの弾力性を確保するための十分な容量、複数のゲートウェイ、およびルート グループとルート リストの構造で構成されていれば、この冗長性によってモバイル コネクト機能の持続性が保証されます。

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

モバイル ボイス アクセス(システム リモート アクセスとも呼ばれる)とエンタープライズ機能アクセス 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 アドレスです。

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

図 25-21 に、モバイル ボイス アクセスのコール フローを示します。この例では、モバイル ボイス アクセス ユーザが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)。

図 25-21 モバイル ボイス アクセス

 


) モバイル ボイス アクセスを図 25-21 のように動作させるには、システム全体の 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 ゲートウェイに持たせる必要があります。図 25-22 に、ヘアピニングを使用したモバイル ボイス アクセスのコール フローを示します。この例では、前の例と同じく、モバイル ボイス アクセス ユーザが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)。

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

 


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



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


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

図 25-23 に、エンタープライズ機能アクセス 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 ゲートウェイ内でヘアピンされます。

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

 


) エンタープライズ機能アクセス 2 ステージ ダイヤリングを図 25-23 のように動作させるには、システム全体の 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] のどちらに設定されているかなどの複数の要因に左右されます。

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

番号プレフィックス メカニズムの使用

このアプローチでは、発信者 ID がPSTN から供給されているかのようにリモート接続先を設定します。たとえば、リモート接続先電話機の発信者 ID をPSTN から 4085557890 として供給する場合は、[Remote Destination] 設定ページでこの番号を設定する必要があります。モバイル コネクト コールを適切にこのリモート接続先にルーティングするには、番号プレフィックス メカニズムを使用して必要な PSTN アクセス コードなどの数字を前に付加する必要があります。たとえば、コール ダイヤル時に PSTN に到達するために 9 が必要で、長距離電話のダイヤルのために 1 が必要な場合は、ダイヤル ストリングの先頭に 9 と 1 を追加するように番号プレフィックスを設定する必要があります。番号プレフィックスは、Unified CM システム内でトランスレーション パターン、ルート パターン、またはルート リスト コンストラクトを使用して実施されます。または、アプリケーション ダイヤル ルールを使用して番号プレフィックスを実施できます。このアプローチを使用する場合は、[Matching Caller ID with Remote Destination] パラメータを [Complete Match] のデフォルト設定のままにする必要があります。


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


部分発信者 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 照合の使用を推奨します。


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

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

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

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

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

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

 


図 25-24 では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 の組み合わせの中に、ユーザのリモート接続先電話機から発信されたビジネス コールのためにアクセスする必要のあるすべてのパーティションが含まれていることを確認してください。

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

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

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

同様に、発信モバイル ボイス アクセスまたはエンタープライズ機能アクセス 2 ステージ ダイヤリング コール ルーティング用のリモート接続先プロファイル CSS を設定する場合は、このコーリング サーチ スペース内のルート パターンが、モバイル ボイス アクセスまたはエンタープライズ機能アクセス DID への着信コール レッグを処理するゲートウェイと同じコール アドミッション制御ロケーションにあるゲートウェイを指すようにすることを推奨します。これによって、ダイヤル先番号への初期発信コール ルーティング中に帯域幅不足によるコール アドミッション制御拒否が発生しないことが保証されます。ただし、デスクトップフォンがモバイル ボイス アクセスまたはエンタープライズ機能アクセス DID が転送されるゲートウェイとは異なるコール アドミッション制御ロケーション内に存在する場合は、以降のデスクトップフォンのピックアップによって、WAN 帯域幅のオーバーサブスクリプションが発生する可能性があることに注意してください。

最後に、モビリティ対応ユーザへの着信PSTN コールは、必ず、会社のデスクトップフォンの DID に基づいてホーム ロケーション ゲートウェイに入るため、モビリティ対応ユーザが、別のサイトでのエクステンション モビリティ ログインまたは別のコール アドミッション制御ロケーションへのデスクトップフォンの物理的移動が原因でコール アドミッション制御ロケーションを移動していた場合は、着信コールが入るゲートウェイと同じコール アドミッション制御ロケーション内に配置された発信ゲートウェイを指すことがほとんど不可能になります。そのため、モビリティ対応ユーザがエクステンション モビリティを使用して、ホーム ロケーション外部のコール アドミッション制御ロケーション内の電話機にログインしたり、コール アドミッション制御ロケーション間でデバイスを物理的に移動したりするシナリオや配置は避けることを推奨します。このようなシナリオを回避または制限することができない場合は、コール アドミッション制御拒否が原因のコール レッグ障害またはデスクトップフォンやリモート接続先のピックアップ アクティビティが原因の 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 機能を使用すると、設定されたリモート接続先番号への社内からの直接コールを、自動的にコール アンカリングできます。通常、モビリティ コール アンカリングは、ユーザの会社の電話番号にかけられたコール、またはユーザの会社の電話番号からかけられたコールでだけ行われます。また、Dial-via-office またはエンタープライズ 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 設定は無視されます。

発信者 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 では、次の容量がサポートされます。

Cisco MCS 7845 サーバまたは同等 Open Virtualization Archive(OVA)サーバを使用したクラスタあたり最大 15,000 人のモビリティ対応ユーザ。

Cisco MCS-7835 または同等 OVA サーバを使用したクラスタあたり最大 10,000 人のモビリティ対応ユーザ。

Cisco MCS 7825 または同等 OVA サーバを使用したクラスタあたり最大 4,000 人のモビリティ対応ユーザ。

MCS 7845 ノードまたは同等 OVA サーバあたり最大 3,750 台のリモート接続先、またはクラスタあたり 15,000 台の接続先。

MCS 7835 または同等 OVA サーバあたり最大 2,500 台のリモート接続先、またはクラスタあたり 10,000 台。

MCS 7825 または同等 OVA サーバあたり最大 1,000 台のリモート接続先、またはクラスタあたり 4,000 台。


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


サポートされるモビリティ対応ユーザの最大数は、ユーザごとに設定されたリモート接続先またはモビリティ ID の数に依存します。前述したモビリティ対応ユーザの最大数は、ユーザあたり 1 つのリモート接続先またはモビリティ ID を想定しています。ユーザあたりのリモート接続先数またはモビリティ ID 数が増加するほど、サポートされるモビリティ対応ユーザ数が減少します。

上の数字が最大容量です。ただし、結果的に、Cisco Unified Mobility のスケーラビリティと性能は、モビリティ ユーザ数、ユーザごとのリモート接続先数またはモビリティ ID 数、およびそれらのユーザの Busy Hour Call Attempt(BHCA)レートに依存します。ユーザあたりの複数のリモート接続先またはユーザあたりの高い BHCA によって、Cisco Unified Mobility の容量が減少します。

Cisco Business Edition システムでの Unified Mobility ユーザの容量は、ユーザあたりのリモート接続先数、およびサーバのハードウェアではなく Unified Mobility で有効にされているユーザの BHCA だけに依存します。したがって、Cisco Business Edition でサポートされるリモート接続先数は、これらのユーザの BHCA に直接依存します。Cisco Business Edition の Unified Mobility のサイジングに関するガイドラインは、次のとおりです。

ユーザあたり 5 台以上のリモート接続先を設定することはできません。Cisco Business Edition システムあたり最大 500 人のユーザがいる場合、リモート接続先の論理的限界は 2,000 台です。ただし、Cisco Business Edition あたりの最大 BHCA が 3,600 である場合は、システムで 2,000 台のリモート接続先をサポートできない可能性があります。代わりに BHCA 計算を使用して、システムによって処理可能なリモート接続先数を適切にサイジングする必要があります。

設定された各リモート接続先は、BHCA に影響があります。ユーザに設定されているリモート接続先ごとに、1 つずつの追加のコール レッグが使用されます。各コールは 2 つのコール レッグで構成されているため、1 つのリモート接続先の呼び出しが 1 つのコールの半分に相当します。そのため、リモート接続先の合計 BHCA は次の式で計算できます。

リモート接続先の合計 BHCA =(ユーザ数)∗(ユーザごとのリモート接続先数)∗(ユーザ BHCA)∗ 0.5

次に、例を示します。

それぞれが 5 BHCA の 300 人のユーザがいて、それぞれのユーザに 1 つずつのリモート接続先(全部で 300 台のリモート接続先)が割り当てられたシステムがあるとすると、リモート接続先の合計 BHCA の計算は次のようになります。

リモート接続先の合計 BHCA =(300 ユーザ)∗(ユーザあたり 1 つのリモート接続先)∗(ユーザあたり 5 BHCA)∗ 0.5 = 750 BHCA

この例でユーザの合計 BHCA は(300 ユーザ)∗(ユーザあたり 5 BHCA)、つまり 1500 です。この値にリモート接続先の合計 BHCA である 750 を加算すると、システムの合計 BHCA 2250(ユーザの合計 BHCA 1500 + リモート接続先の合計 BHCA 750)が求まります。

上記の例のシステムで他のアプリケーションや追加の BHCA 変数が使用されている場合は、容量はさらに制限される可能性があります (詳細については、「Cisco Business Edition のキャパシティ プランニング」を参照してください)。


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


結果的に、Cisco Unified Mobility の拡張性と性能は、モビリティ ユーザ数、ユーザごとのリモート接続先数またはモビリティ ID 数、およびそれらのユーザの最繁時呼数(BHCA)レートに依存します。ユーザあたりの複数のリモート接続先またはユーザあたりの高い BHCA によって、Cisco Unified Mobility の容量が減少することがあります。一般的な Unified CM システムのサイジングの詳細については、「Unified Communications の設計および配置サイジングに関する考慮事項」の章を参照してください。

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 内のルート パターンが、着信コール レッグが到達するゲートウェイと同じコール アドミッション制御ロケーション内に配置されたゲートウェイを指すようにすることを推奨します。詳細については、「リモート接続先プロファイルの設定」を参照してください。

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

デュアルモードの電話機とクライアント

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

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

Cisco Mobile:iPhone 3G モバイル デバイス対応のデュアルモード クライアントで、企業の WLAN ネットワーク上で VoIP コールを発信する機能、および社内ディレクトリとボイスメール サービスにアクセスする機能を提供します。

Cisco Jabber:Android および iPhone モバイル デバイス対応のデュアルモード クライアントで、企業の WLAN ネットワーク上あるいはプライベート/パブリックの 802.11 WLAN ホット スポットやモバイル データ ネットワーク経由で VoIP コールを発信する機能、および社内ディレクトリにアクセスし、企業ボイスメール メッセージ待機インジケータとメッセージ数を受信する機能を提供します。

Nokia Call Connect:Nokia モバイル デバイス対応のデュアルモード クライアントで、企業の WLAN ネットワーク上またはプライベート/パブリックの 802.11 WLAN ホット スポットやモバイル データ ネットワーク経由で VoIP コールを発信する機能、および社内ディレクトリと他のアプリケーションやサービスにアクセスする機能を提供します。


) Nokia Call Connect クライアントは、2012 年 7 月 10 日で販売を終了しました。Nokia モバイル デバイスの代替モバイル クライアントはありません。詳細については、次の URL にある販売終了(EoS)およびサポート終了日(EoL)のお知らせを参照してください。http://www.cisco.com/en/US/prod/collateral/voicesw/ps6789/ps7290/ps10589/end_of_life_notice_c51-696647.html


さらに、この項では、デュアルモードの電話機とクライアントのハイ アベイラビリティおよびキャパシティ プランニングの考慮事項についても説明します。

デュアルモード電話機のアーキテクチャ

デュアルモード電話機には、従来の携帯電話ネットワーク テクノロジーまたはモバイル ネットワーク テクノロジーを使用した音声とデータの携帯通信事業者ネットワークへの接続、および IEEE 802.11 標準を使用した Wireless Local Area Network(WLAN; 無線ローカル エリア ネットワーク)への接続の両方を可能にする、2 つの物理インターフェイスまたは無線機が備えられています。デュアルモード電話機と、その上で動くクライアント ソフトを使用することで、データおよび音声接続が、802.11 WLAN を利用したローカル接続や、プライベート WAN、公衆 WAN、モバイル データ ネットワークを介したリモート接続で使用可能です。


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


図 25-25 に、デュアルモード デバイスを Cisco Unified Communications システムに統合するための基本的なデュアルモード ソリューション アーキテクチャを示します。デュアルモード電話が企業ネットワークに接続し、デュアルモード クライアントが会社の電話機として Cisco Unified CM に登録されます。登録されると、デュアルモード デバイスは、基礎となる企業の Cisco IP テレフォニー ネットワークを利用して、コールを発信および受信します。デュアルモード電話は、企業ネットワーク接続が利用できない場合にだけ、モバイル ボイス ネットワークを利用してコールを発信および受信します。デュアルモード電話機が企業ネットワークに接続されており、かつクライアントが Unified CM に登録されている場合、その電話機はユーザが持つ会社の電話番号を使用して呼の発着が可能です。ユーザの会社の電話番号へのコールが着信すると、デュアルモード電話機の呼出音が鳴ります。ユーザが Cisco デスクトップ IP Phone を持っている場合は、デュアルモード クライアントを登録すると、ユーザの会社の電話番号でシェアド ライン インスタンスが使用可能になり、コールが着信すると、ユーザのデスクトップフォンとデュアルモード電話機の両方の呼出音が鳴ります。デュアルモード クライアントが未登録状態になると、デュアルモード電話機で会社の電話番号に着信したコールを受信しなくなります。ただし、ユーザに対して Cisco Unified Mobility が有効になっており、ユーザの携帯の番号でモバイル コネクト(またはシングル ナンバー リーチ)がオンになっている場合には、会社の電話番号に着信したコールが受信されます。

図 25-25 デュアルモード電話機のアーキテクチャ

 


) コールの音声品質は、Wi-Fi またはモバイル データ ネットワーク接続によって異なります。Cisco Jabber または Cisco AnyConnect Secure Mobility Client の Secure Connect 機能を使用している場合、Cisco Technical Assistance Center(TAC)では、モバイル データ ネットワークまたは企業以外の Wi-Fi ネットワーク上の接続や音声品質の問題を解決できません。


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

Voice over Wireless LAN ネットワークのインフラストラクチャ

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

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


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


デュアルモードの機能

デュアルモード デバイスには、さまざまな機能が用意されています。機能や動作はデバイスによって異なりますが、この項に説明する共通の動作はすべてのデュアルモード デバイスに当てはまります。

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

デュアルモード電話機では、エンタープライズ テレフォニー インフラストラクチャおよび(少なくとも一部において)呼制御サービスが利用されるため、デュアルモード デバイスが社内にある場合のコール ルーティングの特性と動作を理解しておくことが重要です。

着信コール ルーティング

デュアルモード デバイスは、ユーザの会社の電話番号および内線番号として 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 インターフェイスだけが呼び出されます。


) 会社の電話番号への着信コールについては、Unified CM で着信コールをモバイル コネクト経由でモビリティ ID または携帯の番号に転送するまでに SIP デュアルモード クライアントが応答するのを待機する時間は、[SIP Dual Mode Alert Timer] サービス パラメータによって決まります。デフォルトでは、このタイマーは 1,500 ミリ秒に設定されています。デュアルモード クライアントがデバイスの IP インターフェイスで着信コールに応答する時間を長くするには、このタイマーを 3,000 ミリ秒以上に増やすことを推奨します。このグローバル タイマーを 3,000 ミリ秒に調整した後でも、ユーザがセルラー音声インターフェイスまたはモビリティ ID でコールを受信している場合は、タイマーを 4,500 ミリ以上の値に調整します。これは、特に、リモートで VPN を使用して企業ネットワークに接続されているデュアルモード クライアント デバイスで重要です。


デュアルモード デバイスが企業に接続されていないか、Unified CM に登録されていない場合には、ユーザに対して Unified Mobility が有効で、モビリティ ID のモバイル コネクトがオンになっていると、企業の電話番号への着信コールは、設定済みのモビリティ ID に従ってデュアルモード デバイスに転送されます。デュアルモードのデバイスおよびクライアントと Unified Mobility との統合の詳細については、「Cisco Mobile または Cisco Jabber と Cisco Unified Mobility との間の相互作用」および「Nokia Call Connect と Cisco Unified Mobility との間の相互作用」を参照してください。

いずれの場合も、デュアルモード デバイスの携帯電話番号に対して直接発信された着信コールは、プロバイダー ネットワークやデバイスの設定でモバイル ネットワーク経由でデバイスにコールを転送しないように設定されている場合を除き、モバイル ネットワーク経由でデュアルモード デバイスの携帯電話無線機に直接ルーティングされます。このようなコールは、ユーザの会社の電話番号に対して発信されたコールではないため、適切な動作です。これらのコールは個人的なコールであると見なされるため、会社経由でルーティングされません。

発信コール ルーティング

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

一部のデュアルモード クライアントでは、企業ネットワーク接続が利用可能になったときにクライアントを自動的に Unified CM に登録するように、1 つ以上の設定を行う必要がある場合があります。デュアルモード クライアントが Unified CM に登録されていない場合、発信コールは常に企業ネットワークではなくモバイル ボイス ネットワークを使用して発信されます。

ダイヤル プラン

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

企業におけるエンド ユーザ ダイヤリング エクスペリエンスは、最終的には企業のポリシーおよび企業のテレフォニー配置の管理者によって決定されます。ただし、デュアルモード クライアント デバイスでは、デバイスが企業ネットワークに接続されて Unified CM に登録されているかどうかにかかわらず、ユーザ モバイル デバイスのダイヤリング手順が維持されるように、必要なダイヤル ストリングを正規化することを推奨します。モバイル ボイス ネットワークにおけるダイヤリングは、通常完全な E.164(先頭に「+」が付く場合と付かない場合があります)を使用して行われ、携帯電話の連絡先は通常完全な 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 などのストリングを処理できるように設定する必要があります。

会社の他の電話番号へのコールにおいては、短縮ダイヤルが設定されているシステムでは、ダイヤル ストリングを変更して、必要に応じて会社の内線番号に再ルーティングできる必要があります。たとえば、企業のダイヤル プランが 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] フィールドに設定された番号に対するすべてのコールを強制的にモバイル ボイス ネットワーク経由でルーティングします。さらに、デュアルモード電話機のユーザに対して、すべての緊急コールを企業ネットワークではなくモバイル ボイス ネットワーク経由で発信するように指示します。

会社の発信者 ID

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

通話切替機能

デュアルモード電話クライアントが企業に接続され、企業エンドポイントとして Unified CM に登録されている場合、Unified CM でサポートされているコール シグナリング方式を使用して、保留、保留解除、転送、会議などの呼処理付加サービスを呼び出すことができます。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 に登録できる場合、社外でも企業の VoIP コールに IP テレフォニー インフラストラクチャを利用できます。これらのデバイスのリモート セキュア接続には、インターネットを介したクライアント接続をセキュリティで保護するために、Cisco AnyConnect または Cisco Jabber Secure Connect 機能などの VPN ソリューションを使用する必要があります。

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

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

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

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

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

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

ハンドアウト

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

ハンドイン

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

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

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

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

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

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

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

デュアルモード クライアント:Cisco Mobile および Cisco Jabber

この項では、Cisco Mobile および Cisco Jabber の特性と展開に関する考慮事項について説明します。

Cisco Mobile

Cisco Mobile は、Apple iPhone 対応のデュアルモード クライアントです。Apple の App Store からクライアント アプリケーションをダウンロードし、iTunes を使用して iPhone にインストールすると、iPhone を企業の WLAN ネットワークに関連付けて、SIP 対応の会社の電話機として Unified CM に登録できます。

Cisco Mobile デュアルモード iPhone クライアントに登録および呼制御サービスを提供するには、Unified CM 内でデバイスが Cisco Dual Mode for iPhone デバイス タイプとして設定される必要があります。次に、企業の WLAN にアクセスして企業の WLAN インフラストラクチャおよびセキュリティ ポリシーに基づいて接続するように iPhone を設定する必要があります。WLAN にアクセスするように iPhone を設定すると、Cisco Mobile クライアントが起動されたときに、デバイスが Unified CM に登録されます。

Unified Mobility と統合し、ハンドオフ機能を利用するには、iPhone の携帯の番号を、Unified CM 内の Cisco Dual-Mode for iPhone デバイスに関連付けられたモビリティ ID として設定する必要があります。

Cisco Mobile 8.0 クライアントは、ファームウェア バージョン 3.0.1 以降が実行されている iPhone の 3G、3GS、または 4 モデルでサポートされています。iPhone WLAN インターフェイスでは、802.11b および 802.11g ネットワーク接続がサポートされています。


) iPhone 3GS および iPhone 4 デバイスを配置する場合は、Cisco Mobile 8.0 ではなく Cisco Jabber for iPhone クライアントを使用します。Cisco Jabber for iPhone クライアントでは、アプリケーションのマルチタスキングやバックグラウンド処理がサポートされ、優れたユーザ エクスペリエンスが提供されます。iPhone 3G は、Cisco Mobile 8.0 でのみサポートされます。


Cisco Mobile クライアントでは、デュアルモード電話サービスだけではなく、企業の Microsoft Active Directory へのアクセスが設定されている場合にはディレクトリ検索サービスが、Cisco Unity Connection 上のユーザのボイスメール ボックスへのアクセスが設定されている場合にはビジュアル ボイスメール サービスが提供されます。


) Cisco Mobile と iPhone 対応の Cisco Unified Mobile Communicator クライアントの両方を同時に配置する場合は、ユーザの企業ボイスメール ボックスにアクセスするように Cisco Mobile を設定しないでください。代わりに、Cisco Mobile クライアントを使用してビジュアル ボイスメール アクセスを行います。これは、Cisco Mobile クライアントの方が機能が豊富で、よりよいユーザ エクスペリエンスを提供できるためです。


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

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

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

Cisco Jabber

Cisco Jabber は、Android、iPhone、およびその他の 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 S International、Samsung Galaxy Tab International、および Samsung Galaxy S2。 これらのデバイスでは、ファームウェア バージョン 2.2.1 以降が実行されている必要があります。公式にサポートされていませんが、Cisco Jabber for Android はバージョン 2.2 以上が実行している多くの Android デバイスで動作します。制限の度合いはデバイスによって異なります。ほとんどの Android デバイスの WLAN インターフェイスで、802.11b、802.11g、および 802.11n ネットワーク接続がサポートされています。

Apple iOS

iPhone 3GS、4、および 4S、iPod Touch 第 3 世代および第 4 世代、iPad および iPad 2。これらのデバイスでは、iOS バージョン 5.0 以降が実行されている必要があります。Apple iOS デバイスの WLAN インターフェイスでは、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 クライアントでは、Voice over IP(VoIP)電話サービスだけでなく、企業の LDAP ディレクトリへのアクセスが設定されている場合にはディレクトリ検索サービスが、また、Cisco Unity Connection に統合されている場合には企業ボイスメール メッセージ待機インジケータ(MWI)とメッセージ数またはビジュアル ボイスメールが提供されます。

Cisco Jabber クライアントは、「Cisco Mobile および 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 Mobile および Cisco Jabber のハンドオフ

Cisco Mobile や Cisco Jabber などの Cisco デュアルモード クライアントを適切に配置するには、クライアント内部のハンドオフ動作の特性について理解することが重要です。Cisco Mobile および 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 Mobile および Cisco Jabber デュアルモード クライアントの両方でサポートされています。

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

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

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

図 25-26 に示す動作は、社内の iPhone または Android デュアルモード デバイスにおけるアクティブなコールが、手動で WLAN インターフェイスから会社のPSTN ゲートウェイ経由でモバイル ボイス ネットワーク(デバイスの携帯電話インターフェイス)に移動される様子を示しています。図に示すように、企業の WLAN に関連付けられ、Unified CM に登録されたデュアルモード デバイスと、PSTN ネットワーク上の電話機との間に既存のコールがあります(ステップ 1)。これは手動のプロセスであるため、ユーザが Cisco Mobile または 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)。

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

 

ハンドオフ番号方式のハンドオフ

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


) ハンドオフ番号方式のハンドアウトは、iPhone デュアルモード クライアントのみでサポートされています。


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

図 25-27 Cisco Mobile デュアルモード ハンドアウト:ハンドオフ番号方式

 


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



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


Cisco Mobile および Jabber for iPhone デスクフォンの統合

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

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

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

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

Cisco Jabber for Android デュアルモード クライアントを使用すると、Android デバイスから、デュアルモード デバイスと回線を共有する IP デスクフォンにアクティブ コールを移動できます。 この機能を呼び出すには、Cisco Jabber クライアントを介してアクティブ コールを保留にします。保留にしたコールは、シェアド ラインの IP デスクトップフォンまたは Cisco Jabber クライアントで保留解除できます。

Cisco Mobile および Cisco Jabber デュアルモード クライアントの WLAN 設計上の考慮事項

Cisco Mobile および Cisco Jabber デュアルモード クライアントを展開する際には、次の WLAN ガイドラインを考慮してください。

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

Cisco Mobile および Cisco Jabber デュアルモード クライアントは、どの AP でも同じ SSID が使用されている WLAN ネットワーク上に配置してください。SSID が異なると、AP 間のローミングがはるかに低速になります。

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

Cisco Mobile または Cisco Jabber と Cisco Unified Mobility との間の相互作用

Cisco Mobile および Cisco Jabber デュアルモード クライアントを Cisco Unified Mobility に統合することで、Cisco モバイル コネクト、通話切替 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 に登録されている場合には、会社の電話番号への着信コールはデバイスのモバイル ボイス ネットワーク インターフェイスには転送されません。iPhone または Android デュアルモード デバイスが企業に接続されている場合は、デバイスの WLAN またはモバイル データ インターフェイスだけが着信コールを受信します。これにより、会社のPSTN ゲートウェイ リソースの必要以上の消費を回避できます。

企業に接続されず、Unified CM に登録されていない場合、iPhone または Android デュアルモード デバイスでは、DTMF を使用して通話切替機能を呼び出したり、会社の任意の固定コールに対するデスクフォンのピックアップを実行したりできます。また、デュアルモード デバイスでは、コールを発信する場合にモバイル ボイス アクセスとエンタープライズ機能アクセスの 2 ステージ ダイヤリング機能を利用して、これらのコールを会社経由でルーティングし、会社のPSTN ゲートウェイに固定できます。

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

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

Cisco AnyConnect および Secure Connect

Cisco AnyConnect モバイル クライアントおよび Cisco Jabber Secure Connect 機能により、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 接続を提供します。

Cisco Secure Connect は、同じ Cisco AnyConnect ソリューションの ASA ヘッドエンド インフラストラクチャを使用する Cisco Jabber モバイル クライアント機能であり、アプリケーションレベルの SSL セキュア接続を提供します。このとき、別の Cisco AnyConnect クライアント アプリケーションは必要ありません。この機能により、モバイル デバイス全体をセキュリティで保護することなく、Cisco Jabber モバイル クライアント アプリケーションでセキュア接続が可能になります。これにより、Cisco Jabber トラフィックのみが企業ネットワークを通過し、他のすべてのトラフィックはパブリックまたはプライベートの WLAN あるいはモバイル データ ネットワークを通過します。

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

Cisco AnyConnect などのセキュアなリモート VPN 接続ソリューションの詳細については、次の Web サイトで入手可能なセキュア モビリティのマニュアルを参照してください。

http://www.cisco.com/en/US/products/hw/vpndevc/products.html#mobi

Cisco Jabber Secure Connect 機能の詳細については、次の Web サイトで入手可能な『 Cisco Jabber Secure Connect Deployment Guide 』を参照してください。

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

デュアルモード クライアント:Nokia Call Connect


) Nokia Call Connect クライアントは、2012 年 7 月 10 日で販売を終了しました。Nokia モバイル デバイスの代替モバイル クライアントはありません。詳細については、次の URL にある販売終了(EoS)およびサポート終了日(EoL)のお知らせを参照してください。http://www.cisco.com/en/US/prod/collateral/voicesw/ps6789/ps7290/ps10589/end_of_life_notice_c51-696647.html


Nokia Call Connect は、Nokia モバイル スマート フォン対応のデュアルモード クライアントです。クライアントを Nokia デバイスにインストールすると、企業の WLAN ネットワークに関連付けて、Skinny Client Control Protocol(SCCP)対応の会社の電話機として Unified CM に登録できます。

Nokia デュアルモード デバイスに登録および呼制御サービスを提供するには、Unified CM で Nokia S60 デバイス タイプがサポートされている必要があります。このデバイス タイプは、Nokia が提供する Cisco Option Package(COP)ファイルを Unified CM にロードすると使用可能になります。

Unified CM 内でデュアルモード デバイスを設定した後、Nokia Call Connect クライアントを Nokia デバイスにロードする必要があります。この作業は、USB、Bluetooth、または赤外線ポートを備えた、Nokia PC Suite を実行するコンピュータを使用して行うことができます。Nokia Call Connect Symbian Installation System(SIS)ファイルを Nokia デバイスにロードした後、企業の WLAN にアクセスして企業の WLAN インフラストラクチャおよびセキュリティ ポリシーに基づいて接続するようにデバイスを設定する必要があります。WLAN にアクセスするようにハンドセットを設定すると、Nokia Call Connect クライアントが起動されたときに、デバイスが Unified CM に登録されます。Nokia デュアルモード デバイスを Unified Mobility と統合して、ユーザがモバイル コネクトなどの機能を利用できるようにするには、Nokia の携帯電話番号をモビリティ ID として設定し、それを Unified CM 内の Nokia S60 デバイスに関連付けます。


) Nokia Call Connect クライアントの SCCP 登録設定を [Always On] に設定して、Nokia デバイスが企業の WLAN ネットワークに関連付けられた場合に Unified CM への登録が試みられるようにすることを推奨します。また、Nokia デュアルモード電話機の優先コール タイプまたはデフォルト コール タイプの設定を [Internet Call] に設定して、Nokia Call Connect クライアントが Unified CM に登録された場合に、デバイスからの発信コールにおいて常にデュアルモード電話機の WLAN インターフェイス経由でルーティングが試みられるようにすることを推奨します。これらの推奨設定を行うことにより、Nokia デュアルモード電話機において、ビジネス コールの発信および受信時に可能な限りエンタープライズ IP テレフォニー インフラストラクチャを使用できます。


Nokia Call Connect 2.2 クライアントは、Nokia Symbian 3 ハンドセット(Nokia C7、E6、N8 を含む)および Nokia S60 3.2 ハンドセット(Nokia E52、E55、E72、E75 を含む)でサポートされています。E51、E61i、E63、E66、E71、および E90 を含む Nokia S60 3.1 ハンドセットもサポートされていますが、自動ハンドオフなどの高度な機能はサポートされない可能性があります。Nokia 携帯電話の WLAN インターフェイスでは、802.11b、802.11g、および一部の場合では 802.11n ネットワーク接続がサポートされています。

Nokia Call Connect クライアントでは、デュアルモード電話サービスだけでなく、Unified CM ディレクトリへのアクセスが設定された場合には、ディレクトリ検索サービスも提供されます。また、Cisco デスクトップ IP Phone でサポートされているような企業ベースの XML 電話サービスもサポートされます。

Nokia Call Connect 2.0 以降のクライアントでは、以降の項で説明する自動ハンドアウトおよびハンドインを実行できます。

Nokia Call Connect デュアルモード クライアント、サポートされているハンドセット、ソフトウェア バージョンの詳細、および最新のクライアントと COP ファイルについては、次の Web サイトを参照してください。

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

Nokia Call Connect デュアルモード ハンドオフ

Nokia Call Connect デュアルモード クライアントを適切に配置するには、Nokia デュアルモード クライアント内でのハンドオフ動作の特性を理解することが必要です。

以降の例では、ハンドオフ番号は +1 408 555 1234 であるとします(これは、完全な E.164 形式のハンドオフ番号です)。Nokia Call Connect の Voice Call Continuity(VCC)設定の下の [Cellular Handover number] は、この番号に設定されています。

すべての着信コールは、アップストリーム ゲートウェイによって 4 桁に短縮されるため、Unified CM 内に設定するハンドオフ番号は 1234 です。Nokia Call Connect の VCC 設定の下の [VoIP Handover number] は、1234 に設定されています。

ハンドアウト(WLAN から携帯電話へ)

図 25-28 は、社内の Nokia デュアルモード電話機におけるアクティブなコールが、WLAN インターフェイスから会社のPSTN ゲートウェイ経由でモバイル ボイス ネットワーク(デバイスの携帯電話インターフェイス)に移動されるハンドアウト動作を示しています。図に示すように、企業の WLAN に関連付けられ、Unified CM に登録された Nokia デュアルモード デバイスと、PSTN ネットワーク上の電話機との間に既存のコールがあります(ステップ 1)。Nokia デュアルモード ユーザが社外への移動を開始します(ステップ 2)。WLAN 信号強度が 1,000,000 マイクロ秒(1 秒、VCC の [WLAN HO hysteresis] 設定のデフォルト値)にわたって -78 dBm(VCC の [WLAN HO threshold] 設定のデフォルト値)未満に減衰すると、モバイル ボイス ネットワークおよびPSTN 経由で会社のPSTN ゲートウェイに対して +1 408 555 1234(VCC の [Cellular Handover number] 設定、Unified CM で設定されたハンドオフ番号に対応)へのサイレント バックグラウンド コールが開かれ、Unified CM に送信されます(ステップ 3)。このコールが受信されると、発信番号と、システムに設定されているすべてのモビリティ ID が照合されて、一致するものがある場合には、WLAN を通過していた RTP ストリームがPSTN ゲートウェイにリダイレクトされ、デュアルモード デバイスと元のPSTN 電話機との間のコールは会社のゲートウェイで固定されて、中断されずに継続します(ステップ 4)。

図 25-28 Nokia Call Connect デュアルモード ハンドアウト(WLAN からモバイル ボイス ネットワークへ)

 

Nokia Call Connect デュアルモード クライアントでは、[Switch to Cellular] または [Handover to GSM] コール中メニュー オプションを使用した手動でのハンドアウトもサポートされています。これらの手動でのハンドアウト方法が利用可能であるかどうか、およびその動作は、デバイス タイプとファームウェアのバージョンに応じて異なります。バージョン 3.1 以前のバージョンのファームウェアが実行されているデバイスでは、[Switch to Cellular] メニュー オプションを選択すると、アクティブなコールが、会社のPSTN ゲートウェイ経由でデバイスのモバイル ボイス ネットワーク インターフェイスにブラインド転送されます。 バージョン 3.2 以降のバージョンのファームウェアが実行されているデバイスでは、[Handover to GSM] メニュー オプションを選択すると、[WLAN HO threshold] および [WLAN HO hysteresis] の各 VCC 設定を使用しないで、図 25-28 のステップ 3 に示すように Unified CM のハンドオフ番号を使用した手動ハンドオフが実行されます。

ハンドイン(携帯電話から WLAN へ)

図 25-29 は、社外の Nokia デュアルモード電話機におけるアクティブなコールが、モバイル ボイス ネットワーク インターフェイスから会社のPSTN ゲートウェイ経由でデバイスの WLAN インターフェイスに移動されるハンドイン動作を示しています。図に示すように、モバイル ボイス ネットワーク上の Nokia デュアルモード デバイスと、PSTN ネットワーク上の電話機との間に既存のコールがあります(ステップ 1)。Nokia デュアルモード ユーザが社内に移動し(ステップ 2)、バックグラウンドでデバイスが WLAN インフラストラクチャに関連付けられて、Unified CM に登録されます。登録後、デバイスは、VCC の [WLAN HO hysteresis high] 設定に指定された時間(デフォルトで 60 秒)だけ待機し、1234(VCC の [VoIP Handover number] 設定、Unified CM で設定された Unified CM ハンドオフ番号に対応)へのサイレント バックグラウンド コールを開いたあと、Unified CM に送信します(ステップ 3)。このコールが受信されると、発信元である会社の電話番号と、システムに設定されている Nokia S60 デュアルモード電話機が照合されて、一致するものがある場合には、モバイル ボイス ネットワーク、PSTN、および会社のPSTN ゲートウェイを通過していたコールが WLAN ネットワークにリダイレクトされ、デュアルモード デバイスと元のPSTN 電話機との間のコールは中断されずに継続します(ステップ 4)。

図 25-29 Nokia Call Connect デュアルモード ハンドイン(モバイル ボイス ネットワークから WLAN へ)

 

Nokia Call Connect デュアルモード クライアントの WLAN 設計上の考慮事項

Nokia Call Connect デュアルモード クライアントを配置する際には、次の WLAN ガイドラインを考慮してください。

Voice Continuity Configuration(VCC)設定の下の [WLAN HO Threshold] の設定は、ユーザが WLAN カバレッジ エリアから出たときに自動ハンドオフの遅延を経験しない限り、デフォルト設定(Nokia Call Connect 2.1 以降の場合は 73)のままにしておいてください。

[WLAN HO Threshold] を低い値に調整すると、ユーザが WLAN カバレッジ エリアを離れたときの高速自動ハンドオフを保証できます。

[WLAN HO Threshold] の調整は、WLAN Access Point(AP)間のローミングのトリガーしきい値にも影響します。[WLAN HO Threshold] の設定値を下げると、AP 間のローミングしきい値も低くなり、結果、AP 間のローミングが高速になります。ユーザが WLAN 上で低い音声品質を経験している場合、および AP 間のローミングが低速すぎる場合には、この設定を低く調整することを検討してください。ただし、この値を下げると自動ハンドオフも高速になることを念頭に置いておいてください。

Nokia Call Connect の VCC 設定の詳細については、次の Web サイトで入手可能な『 Nokia Call Connect for Cisco User's Guide 』を参照してください。

http://europe.nokia.com/support/download-software/nokia-call-connect-for-cisco

Nokia Call Connect と Cisco Unified Mobility との間の相互作用

Nokia Call Connect デュアルモード クライアントは、Cisco Unified Mobility と統合して、Cisco モバイル コネクト、通話切替 DTMF 機能、2 ステージ ダイヤリング、シングル企業ボイスメール ボックス、およびデスクトップフォンのピックアップを利用できます。

Unified Mobility と統合するには、Unified CM 内で、Nokia デュアルモード電話機の携帯の番号を Nokia S60 デバイスに関連付けられたモビリティ ID として設定する必要があります。システム内で携帯の番号がモビリティ ID として設定されると、Nokia デュアルモード デバイスが社外にあり、Unified CM に登録されていない場合に、モバイル コネクトを利用して、ユーザの会社の電話番号への着信コールをモバイル ボイス ネットワークを経由して Nokia デュアルモード デバイスに転送できます。Nokia デュアルモード デバイスが社内にあり、Unified CM に登録されている状況においては、会社の番号への着信コールはデバイスのモバイル ボイス ネットワーク インターフェイスには転送されません。Nokia デュアルモード デバイスが社内にある場合は、デバイスの WLAN インターフェイスだけが着信コールを受信します。これにより、会社のPSTN ゲートウェイ リソースの必要以上の消費を回避できます。

社外にあり、Unified CM に登録されていない場合、Nokia デュアルモード デバイスでは、会社の任意の固定コールに対して、DTMF を使用して通話切替機能を呼び出したり、デスクトップフォンのピックアップを実行したりできます。Nokia Call Connect 2.1 以降のクライアントは、社外にいるユーザが自身を会社の PSTN ゲートウェイにアンカーするために、会社を通じて発信コールを行いたいというシナリオのために、シスコ エンタープライズ機能アクセス 2 ステージ ダイヤリング機能のオートメーションを提供します。エンタープライズ機能アクセス 2 ステージ ダイヤリングの詳細については、「2 ステージ ダイヤリングを伴うエンタープライズ機能アクセス」を参照してください。

Nokia Call Connect クライアントの 2 ステージ ダイヤリング機能が有効になっている場合は、そのデバイスによって携帯電話インターフェイスに対して発信されたすべてのコールが、Unified CM 内のエンタープライズ機能アクセス 2 ステージ ダイヤリング機能を利用します。Nokia Call Connect 内で設定されている 2 ステージ ダイヤリング番号 の値が、すべての発信携帯電話コールに対してクライアントがダイヤルする番号を決定します。この設定済みの番号は、Unified CM システム上のエンタープライズ機能アクセスの番号に対応している必要があります。Nokia Call Connect クライアント内で設定されている 2 ステージ ダイヤリング PIN の値が、コールがいったんエンタープライズ機能アクセスの番号に接続された後、Unified CM に送信される認証キー シーケンスを決定します。この設定済み PIN は、Unified CM 内のエンド ユーザ アカウントに下で設定されているとおりのユーザの PIN に対応している必要があります。Nokia Call Connect クライアントは、2 ステージ ダイヤル コールを支援するために、これら 2 つの設定に加えて、ユーザがダイヤルまたは選択した番号を使用します。


) エンタープライズ機能アクセス 2 ステージ ダイヤリング オートメーションが使用できるのは、Nokia S60 3.2 ファームウェア バージョンでだけです。


また、Nokia デュアルモード ユーザは、IVR ベースの手動モバイル ボイス アクセス 2 ステージ ダイヤリング機能を利用して、会社を通じてコールをダイヤルし、それらのコールを会社のゲートウェイに固定できます。

Nokia デバイスが Cisco Unified Mobile Communicator クライアントも実行している場合は、ユーザにとって Dial-via-office での経験の方がはるかに優れているという理由で、ユーザは、エンタープライズ機能アクセスまたはモバイル ボイス アクセス 2 ステージ ダイヤリング方式の代わりに、そのクライアントで使用できる Dial-via-office 機能を利用できます。

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

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

デュアルモード電話機のハイ アベイラビリティ

デュアルモード電話は、その特性上ネットワーク接続に関して非常に高い可用性を備えていますが(企業ネットワークへの接続が利用できない場合には、モバイル ボイスおよびデータ ネットワークを音声およびデータ サービスに使用できます)、企業の 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 サーバ ノードで障害が発生しても、デュアルモード デバイスの登録やコール ルーティングは引き続き利用可能です。

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

デュアルモード電話機のキャパシティ プランニング

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

デュアルモード電話を配置する場合、Unified CM における登録の負荷および Unified Mobility の制限について考慮することが重要です。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 の空き容量が制限される可能性があります。

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

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

上記の考慮事項は、デュアルモード電話機に固有のものではありません。これらの考慮事項は、デバイスやユーザが Unified CM に追加されることによって Unified Communications システム全体の負荷が高まるすべての状況に当てはまります。

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

デュアルモード電話機の設計上の考慮事項

デュアルモードの電話機とクライアントを配置する場合には、次の設計上の考慮事項を遵守します。

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

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

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

デュアルモードの電話機とクライアントを接続する場合は、エンタープライズ クラスの音声に最適化された WLAN ネットワークだけを使用することを推奨します。ほとんどのデュアルモードの電話機とクライアントは、パブリックおよびプライベートの WLAN アクセス ポイントやホット スポットに接続し、インターネットを経由して会社に接続して呼制御やその他の Unified Communications サービスを利用できますが、このように接続した場合の音声品質は保証されません。

Unified Mobility モバイル コネクト機能では、デュアルモード デバイスが企業に接続され、Unified CM に登録されている場合には、着信コールはデュアルモード デバイスの設定されたモビリティ ID には転送されません。これは、企業のPSTN リソースの利用を削減するための仕様です。デュアルモード デバイスは Unified CM に登録されるため、システムでは、デバイスが社内で到達可能であるかどうかを把握できます。社内で到達可能である場合は、コールを PSTN に転送してデュアルモード デバイスのセルラー音声無線を呼び出す必要性がありません。モバイル コネクトでは、デュアルモード デバイスが登録されていない場合にだけ、ユーザの会社の電話番号への着信コールがモバイル ボイス ネットワークのモビリティ ID 番号に転送されます。コールがモビリティ ID に早く、または不必要にルーティングされないようにするには、グローバルな [SIP Dual Mode Alert Timer] サービス パラメータを 3,000 ミリ秒以上に調整する必要があります。

デュアルモード電話を配置する場合は、モバイル デバイスが企業に接続されているかどうかにかかわらずユーザがダイヤリング手順を維持できるように、必要なダイヤル ストリングを正規化することを推奨します。モバイル ネットワークにおけるダイヤリングは、通常完全な E.164(先頭に「+」が付く場合と付かない場合があります)を使用して行われ、携帯電話の連絡先は通常完全な E.164 番号で保存されるため、デュアルモード電話においては、企業のダイヤル プランは完全な E.164 番号または先頭に「+」を付けた完全な E.164 番号を使用できるように設定することを推奨します。このように企業のダイヤル プランを設定することによって、ユーザはデバイスが Unified CM に登録されているかどうかを気にする必要がなくなるため、最善のエンド ユーザ ダイヤリング エクスペリエンスを提供できます。

デュアルモード電話のユーザが緊急コールを発信し、デバイスおよびユーザの位置を特定する場合には、モバイル ボイス ネットワークのみを利用することを推奨します。これは、通常モバイル プロバイダー ネットワークでは、WLAN ネットワークよりもはるかに信頼性のある位置情報が提供されるためです。デュアルモード電話で緊急サービスおよび位置サービスにモバイル プロバイダーのボイス ネットワークのみが利用されるようにするには、Unified CM 内のデュアルモード デバイスの [Emergency Numbers] フィールドに 911、999、112 などの緊急番号を設定し、これらのコールを強制的にモバイル ボイス ネットワーク経由で発信します。デュアルモード電話機のユーザに対して、すべての緊急コールを企業ネットワークではなくモバイル ボイス ネットワーク経由で発信するように指示します。

デュアルモード デバイスにおいて、ビジネス コールの発信および受信時に可能なかぎりエンタープライズ IP テレフォニー インフラストラクチャが使用されるようにするために、次の Nokia Call Connect クライアント設定を行うことを推奨します。

Nokia Call Connect クライアントの SCCP 登録設定を [Always On] に設定して、Nokia デバイスが企業の WLAN ネットワークに関連付けられた場合に Unified CM への登録が試みられるようにします。

Nokia デュアルモード電話機の優先コール タイプまたはデフォルト コール タイプの設定を [Internet Call] に設定して、Nokia Call Connect クライアントが Unified CM に登録された場合に、デバイスからの発信コールにおいて常にデュアルモード電話機の WLAN インターフェイス経由でルーティングが試みられるようにします。

デスクフォンの統合を使用して Cisco Mobile または Cisco Jabber Apple iOS クライアントを配置する場合は、Cisco Mobile または Jabber ユーザのエンドユーザ アカウントに対して CTI を有効にする必要があります。また、デスクフォンがコールを自動でパークし、コールがデスクフォンからクライアントに転送された場合は常に Cisco Mobile または Jabber クライアントが取得できるよう、コール パークをシステム レベルで設定する必要があります。Unified CM システム全体をサイジングする場合、この機能の CTI オーバーヘッドを考慮する必要があります。

Cisco Mobile、Cisco Jabber for iPhone、または Cisco Jabber for Android デュアルモード クライアントを配置する際には、次の配置ガイドラインに従って WLAN ネットワークを設定してください。

WLAN 内のレイヤ 3 での Cisco Mobile、Cisco Jabber for iPhone、および Cisco Jabber for Android デュアルモード デバイスのローミングを最小限に抑えます。デバイスの IP アドレスが変わるレイヤ 3 のローミングでは、ローミング時間が長くなり、音声パケットがドロップされるほか、コールがドロップされる場合もあります。

最も高速な AP 間ローミングを確保するために、WLAN 内で Cisco Mobile および Cisco Jabber デュアルモード デバイスが使用するすべての AP に対して同一の SSID を設定します。

コール中に WLAN インフラストラクチャ内の他の AP に参加するように求められるとコールが中断されるおそれがあるので、これを防ぐために、すべての WLAN AP を自身の SSID をブロードキャストするように設定します。

Nokia Call Connect デュアルモード クライアントの配置には、Nokia Call Connect クライアント内の [WLAN HO Threshold] の設定を低くして、より高速な自動ハンドアウトを保証します。ただし、この設定を下げると AP 間のローミング速度も上がることを念頭に置いておいてください。

Cisco Unified Mobile Communicator


) Cisco Unified Mobile Communicator は販売終了(EoS)およびサポート終了日(EoL)に達しました。Cisco Jabber がモバイル デバイスの代替モバイル クライアントです。詳細については、次の URL にあるお知らせを参照してください。http://www.cisco.com/en/US/prod/collateral/voicesw/ps6789/ps7290/ps7271/end_of_life_notice_c51-677140.html


Cisco Unified Mobile Communicator は、携帯電話から Cisco Unified Communications アプリケーションにアクセスし、利用する機能をユーザに提供するモビリティ ソリューションです。Cisco Unified Mobile Communicator および Cisco Mobile グラフィカル クライアントは、Cisco Unified Mobility Advantage ソフトウェアを実行しているサーバと連動して、携帯電話の機能にアクセスし、制御するためのリッチ ユーザ インターフェイスを提供します。このシステムは既存の社内 LDAP ディレクトリに統合されるため、ユーザはすべてのデバイス上で単一のクレデンシャル セットを使用できます。また、Unified Mobile Communicator と Unified Mobility Advantage 間のすべてのトラフィックが、Secure Socket Layer(SSL)プロトコルによって保護されます。Unified Mobile Communicator は、携帯電話ユーザに次の機能を提供します。

社内および個人ディレクトリへのアクセス

プレゼンスとバディの会社との同期化

社内ボイスメールへのビジュアル アクセス

デスクトップフォンの不在コール、発信コール、および受信コールの履歴確認

セキュア Store-and-Forward テキスト メッセージング

会議通知の受信

Cisco Unified CM を使用した Dial-via-office


) 上記に記載されている機能が、サポート対象のすべてのハンドセットまたはモバイル オペレーティング システムで利用できる機能のすべてではありません。



) 引き続き、Cisco Unified Mobility Advantage 7.1(3) はサポートされ、Cisco Unified CM 8.x および他の Cisco Unified Communications システム 8.x アプリケーションと相互運用できます。この項のすべての説明は、Unified Mobility Advantage サーバの 7.1(3) に基づいています。このソリューションの具体的なハードウェアおよびソフトウェア要件の詳細については、次の URL で入手可能な『Compatibility Matrix for Cisco Unified Mobility Advantage, Cisco Mobile, and Cisco Unified Mobile Communicator』を参照してください。http://www.cisco.com/en/US/products/ps7270/products_device_support_tables_list.html


Cisco Unified Mobile Communicator の電話サポートとデータ プラン要件

Cisco Unified Mobile Communicator クライアント アプリケーションはさまざまなモバイル デバイスで動作しますが、その洗練された機能性によって、サポートされる電話機が制限されるようなデバイス要件が最小限に抑えられています。

Cisco Unified Mobile Communicator は、次のモバイル オペレーティング システムまたはハンドセットで実行するように設計されています。

Windows Mobile 6.0 または 6.1 Standard

Nokia Symbian および Nokia S60 Third Edition(Nokia ハンドセット)

ファームウェア バージョン 3.0.1 以降が実行されている Apple iPhone 3G または 3GS(iPhone ハンドセット)

Research In Motion(RIM)Blackberry(Blackberry ハンドセット)


) iPhone および Blackberry デバイス対応の Cisco Unified Mobile Communicator クライアントは、Cisco Mobile と呼ばれています。


ハンドセット モデルのサポートは、モバイル オペレーティング システム(OS)によって異なりますが、特定のハンドセット サポート認証は必要ありません。各モバイル OS について、シスコでは最低限の要件をサポートするハンドセットを必要とします。これらの要件はモバイル OS ごとに異なりますが、次のリストにハンドセットがサポート対象となるための一般的な要件を示します。

モバイル OS の特定のバージョン(OS ごとに異なる)

特定のフォーム ファクタ、スクリーン サイズ、およびキーボード テクノロジー(オペレーティング システムごとに異なる)

認定された認証局(VeriSign または GeoTrust)からのルート認証のインストール

サードパーティ アプリケーションのインストールまたは実行に対する制限なし


) 実際のユーザ エクスペリエンスはデバイスによって異なる可能性があります。


特定のハンドセット要件の詳細については、次の Web サイトで入手可能な『 Compatibility Matrix for Cisco Unified Mobility Advantage and Cisco Unified Mobile Communicator 』を参照してください。

http://www.cisco.com/en/US/products/ps7270/products_device_support_tables_list.html

サポートされているデバイスの提供に加えて、ユーザは、サポートされているデータ プランでそのデバイスを使用する必要があります。クライアントは、モバイル データ ネットワークを使用して Cisco Unified Mobility Advantage サーバと通信します。クライアントとサーバは SSL を使用してすべてのデータ トラフィックを保護しますが、クライアントは、Unified Mobility Advantage 管理者がインストール中に指定したポート上でモバイル データ ネットワークを使用してサーバとの接続を開始します。

このポートが従来と異なる可能性があるため、クライアントは、モバイル データ ネットワークに無制限プランでアクセスできる必要があります。それに反して、多くのオペレータは、クライアントにポート 80 上の HTTP アクセスのみを許可するローエンドの「Web 専用」プランを提供します。この種のプランは、Unified Mobile Communicator と互換性がないため、機能しない可能性があります。代わりに、ユーザは、クライアントからサーバ上の任意のポートへの任意の TCP トラフィックを許可するプランに加入する必要があります。このプランは、VPN プランと呼ばれることがあります。ただし、Unified Mobility Advantage サーバが動的で変換済みのアドレスを適切にマップするため、クライアントはルーティング可能な IP アドレスや固定 IP アドレスを必要としません。

Cisco Unified Mobile Communicator クライアントはすべてのアプリケーション統合と機能を会社へのデータ接続に依存しているため、このデータ接続が極めて重要です。この重要な接続で消費される帯域幅には、かなりのばらつきがあります。これらの接続のさまざまな特性を考えると、分単位やバイト単位のプランではなく、無制限のデータ プランを強く推奨します。ただし、配置によっては、無制限のデータ プランに非常に多くのコストがかかる場合があります。帯域幅を見積もって計画する目的でシスコが行った調査によれば、Unified Mobile Communicator ユーザは、ビジュアル ボイスメール機能を使用しなければ、月平均で、約 5.6 MB の帯域幅を消費します。もちろん、帯域幅の消費は、エンド ユーザの振る舞いによって大きく異なります。たとえば、大量のディレクトリ ルックアップを実行したり、大量のテキスト メッセージを送信したり、大量の Dial-via-office コールを発信したりするユーザは、このような機能をほとんど使用しないユーザよりも広い帯域幅を消費します。したがって、5.6 MB/月という平均値はほとんど参考になりません。ビジュアル ボイスメールを使用した場合は、1 分間のボイスメール メッセージで約 354 kb が消費されます。つまり、約 2 時間のビジュアル メッセージでこの月平均のすべてが消費される計算です。このことから、ビジュアル ボイスメールの使用中は帯域幅の要求が異常に高くなることが容易にわかります。

Cisco Unified Mobile Communicator のアーキテクチャ

このソリューションは、Cisco Unified Mobile Communicator、Adaptive Security Appliance (ASA) TLS プロキシ、および Cisco Unified Mobility Advantage サーバという主要な 3 つのコンポーネントで構成されています (図 25-30 を参照)。図 25-30 に示すように、Cisco Unified Mobility Advantage サーバは既存の Unified Communications アプリケーションおよび企業システムにアクセスします。

図 25-30 Cisco Unified Mobile Communicator のアーキテクチャ

 

モバイル デバイス上で Unified Mobile Communicator が起動するとユーザ セッションが開始されます。アプリケーションが開始すると、Microsoft Active Directory パスワードの入力が要求されます (プロビジョニング中にデバイスがユーザ アカウントに関連付けられるため、クライアントはユーザ ID を収集する必要がありません)。次に、クライアントが、モバイル データ ネットワークを使用して ASA TLS プロキシへの SSL 接続を開始します。この接続は、インターネットからの着信接続としてプロキシで検出されます。この接続に使用されるプロトコルは、Mobile Multiplexing Protocol(MMP)です。このプロトコルは、ハンドセットのバッテリ寿命を節約するように最適化されています。MMP プロトコルは、標準ベースの SSL パケットにカプセル化されます。

SSL 接続が確立されると、ASA から Unified Mobility Advantage サーバに要求が渡され、そこでユーザが LDAP ディレクトリに対して認証されます。SSL トラフィックを運搬する TCP 接続はクライアントによって維持されるため、サーバはアドレス変換や動的クライアント アドレスなどに関係なく、トラフィックをクライアントに委ねることができます。クライアントの接続期間を通して、ASA TLS プロキシがクライアントからの着信パケットを復号し、厳格なパケット インスペクションを実施してパケットが有効で許可されたユーザからのものであることを保証します。検査に合格したパケットは、ASA プロキシが再び暗号化して、Cisco Unified Mobility Advantage サーバに渡します。

Unified Mobile Communicator クライアント ユーザを認証するための LDAP クレデンシャルの使用に加えて、Unified Mobility Advantage サーバでもその他のバックエンド アプリケーション システムに接続するためにクレデンシャルが使用されます。たとえば、Microsoft Exchange サーバにユーザとして接続し、カレンダー、個人連絡表、および会議通知にアクセスするためにこの情報が使用されます。

ASA を TLS プロキシとファイアウォールの両方として配置するか、ASA を DMZ 内の TLS プロキシとしてだけ配置して外部ファイアウォールに依存するかに関係なく、2 つのポートを設定して、それらを外向きのファイアウォールまたはインターフェイス(インターネットと DMZ 間)と内向きのファイアウォールまたはインターフェイス(DMZ と会社間)の両方に対して開く必要があります。外部と内部の両方のファイアウォールに対して、次の一連の範囲に含まれるポートを開く必要があります。

外部ファイアウォール ポート

5400 ~ 5500 の範囲のクライアント接続ポート(TCP/SSL)

9000 ~ 9100 の範囲のプロビジョニング ポート(HTTP)

内部ファイアウォール ポート

5400 ~ 5500 の範囲のクライアント接続ポート(TCP/SSL)

9000 ~ 9100 の範囲のプロビジョニング ポート(HTTP)


) デフォルトのクライアント接続ポート(TCP/SSL)は 5443 で、デフォルトのプロビジョニング ポート(HTTP)は 9080 です。



) iPhone または Blackberry ハンドセットだけを配置している場合、これらのハンドセットはプロビジョニング ポートを介して Cisco Unified Mobile Communicator クライアントをダウンロードしないため、ファイアウォールのプロビジョニング ポートを開く必要はありません。このクライアントは、iPhone ハンドセットの場合は Apple App Store からダウンロードされ、Blackberry ハンドセットの場合は Blackberry Enterprise Server(BES)を介してハンドセットにプッシュされます。


Cisco Unified Mobile Communicator 環境に Blackberry ハンドセットを配置する場合、Cisco Mobile クライアントを実行する Blackberry デバイスは、社内に配置された Blackberry Enterprise Server(BES)経由で Cisco Unified Mobility Advantage サーバに接続する必要があるという点で、アーキテクチャ上の若干の変更があります。他の Cisco Unified Mobile Communicator クライアントおよび Cisco Mobile クライアントとは異なり、Blackberry クライアントから Unified Mobility Advantage サーバへの接続では、ASA 経由でのセキュリティは確保されません。その代わり、Blackberry デバイスと BES サーバとの間のセキュアな接続が使用され、BES サーバが Unified Mobility Advantage サーバと直接統合されます。BES サーバは、Mobile Data Service(MDS)とともに配置し、MDS で設定する必要があります。図 25-30 に示すように、BES サーバと ASA の両方を Unified Mobility Advantage サーバに統合して、Blackberry およびその他のサポートされているモバイル ハンドセットを同じシステム内に配置できます。Blackberry デバイス用に BES および MDS を Unified Mobility Advantage サーバに直接統合する方法の詳細については、次の Web サイトで入手可能なコンフィギュレーション ガイドの『 Enabling Support for Clients in Cisco Unified Mobility Advantage 』を参照してください。

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

Microsoft Active Directory(AD)環境では、LDAP サーバに関するサーバ固有の要件はありません。適切なドメインに属していればどのドメイン コントローラも動作します。Unified Mobility Advantage サーバからこのサーバに対して LDAP バージョン 3 の認証および検索要求が発行され、予期したとおりに AD ドメイン経由で伝播されます。Exchange サーバが複数存在する環境では、Cisco Unified Mobility Advantage サーバが AD に照会してユーザごとの適切なサーバを決定します。

Cisco Unified Mobile Communicator の機能

Cisco Unified Mobile Communicator は、ユーザが社外からモバイル デバイスを使用して社内のさまざまな Unified Communications アプリケーションにアクセスして利用できるようにします。 次の企業アプリケーションを Unified Mobile Communicator ソリューションに統合できます。各アプリケーションからは後述するような機能が提供されます。

Cisco Unified Mobile Communicator ソリューションと統合できるサポート対象のアプリケーションおよびバージョンの全リストについては、次の Web サイトで入手可能な『 Compatibility Matrix for Cisco Unified Mobility Advantage and Cisco Unified Mobile Communicator 』を参照してください。

http://www.cisco.com/en/US/products/ps7270/products_device_support_tables_list.html

LDAP ディレクトリ

Cisco Unified Mobility Advantage サーバと Microsoft Active Directory が統合されます。Unified Mobile Communicator クライアント接続の認証に Active Directory が使用されるため、この統合が必要になります。ユーザの Active Directory アカウント パスワードが Cisco Unified Mobility Advantage サーバまたは Unified Mobile Communicator クライアントに保存されることはありません。クライアントの認証メカニズムの提供に加えて、クライアントからのディレクトリ ルックアップを解決し、ユーザがモバイル デバイスから社内ディレクトリを検索できるようにするためにも Active Directory が使用されます。図 25-30 に示すように、Active Directory との統合は LDAP 経由で行われます。

Cisco Unified CM

Cisco Unified Mobility Advantage サーバと Cisco Unified CM を統合することで、デスクトップフォン コール ログの同期化、Dial-via-office 機能、および Unified Mobility 統合を提供できます。この統合には、管理者が Unified CM に対していくつかの設定手順を実行する必要があります。エンタープライズ コール ログ統合では、Cisco Unified CM 内でアプリケーション ユーザ アカウントを設定して、Unified Mobile Communicator ユーザのデスクトップフォンをそのアカウントに関連付ける必要があります。このアカウントは、Unified Mobility Advantage サーバですべての Unified Mobile Communicator ユーザのデスクトップフォンをモニタして、不在コール、受信コール、および発信コールを収集するために使用されます。アプリケーション ユーザ アカウント数は最大 250 台のモニタ対象デバイスに制限され、Unified Mobility Advantage サーバの設定によって最大 4 つのアカウント名が許可されるため、最大 1,000 人のユーザが利用できます。Cisco Unified CM 内の各アプリケーション ユーザ アカウントを Standard CTI End Users グループと Standard CTI Enabled グループの両方に割り当てる必要があります。

Dial-via-office 機能と Unified Mobility との統合では、各ユーザの Unified Mobile Communicator デバイスを Cisco Unified CM 内のデバイスとして設定し、このデバイスにユーザの会社の電話番号(ユーザのデスクフォンと同じ電話番号)を設定して、ユーザの携帯電話の電話番号に設定されたモビリティ ID をこのデバイスに関連付ける必要があります。

エンタープライズ コール ログ統合、Dial-via-office、および Unified Mobility 統合の設定手順を含む、Unified CM との統合の詳細については、次の Web サイトで入手可能な Cisco Unified Mobility Advantage のインストールおよび設定マニュアルを参照してください。

http://www.cisco.com/en/US/products/ps7270/prod_installation_guides_list.html

デスクトップフォンのコール ログ統合

コール ログ統合を有効にされた Unified Mobile Communicator ユーザは、Unified Mobile Communicator クライアント上でデスクトップフォンからのコール履歴リスト(不在コール、発信コール、および着信コール)を確認できます。

図 25-30 に示すように、Unified Mobility Advantage サーバと Unified CM の間で JTAPI 接続が確立されます。この JTAPI 接続では、CTI を使用してユーザのデスクトップフォンのプライマリ回線に対する着信コールと発信コールがモニタされます。コール ログは、デスクトップフォンから Unified Mobile Communicator クライアントの方向にのみ同期化されることに注意してください。Unified Mobile Communicator クライアントからデスクトップフォンの方向には同期化されません。

Dial-via-office

Dial-via-office 機能を使用すれば、Cisco Unified CM テレフォニー インフラストラクチャと会社のPSTN ゲートウェイを使用して、Cisco Unified Mobile Communicator クライアントを実行している携帯電話からコールを開始できます。図 25-30 に示すように、この機能は、Unified Mobility Advantage サーバと Unified CM 間の SIP 接続上の SIP シグナリングによって実現されます。

Unified Mobile Communicator ユーザが携帯電話から発信したすべてのコールに対して、Unified Mobility Advantage 管理者が Dial-via-office の使用を命令できます。ただし、設定されている緊急番号または直接通話番号へのコールでは、Dial-via-office 命令が無視されます。管理者は、Unified Mobile Communicator ユーザに、Dial-via-office 機能を使用するかどうかといつ使用するかを決めさせることもできます。このとき、エンド ユーザは、コール(モバイル ボイス ネットワークに送信される設定済みの緊急電話番号または直接通話番号へのコール以外)の発信時に必ず Dial-via-office を使用する、または、コールごとにプロンプトを出力するように電話機を設定できます。

Cisco Unified Mobile Communicator ソリューションでサポートされている Dial-via-office には、次の 2 つのタイプがあります。

「Dial-via-office リバース コールバック」

「Dial-via-office 転送」

Dial-via-office リバース コールバック

図 25-31 に、Dial-via-office リバース コールバックのコール フローを示します。この例では、Unified Mobile Communicator ユーザが、PSTN 電話機(972-555-7890)に電話をかけようとしています。ユーザが、番号をダイヤルするか、コンタクト リストまたはディレクトリ リストから番号を選択すると、会社と Cisco Unified Mobility Advantage サーバへのデータ接続上で SIP INVITE が生成されます(ステップ 1)。この SIP INVITE は、MMP プロトコルにカプセル化され、クライアントと Cisco Unified Mobility Advantage サーバ間の(クライアント タイプに応じて)ASA または BES サーバ経由のセキュアな接続によって送信されます。この要求は、SIP 接続経由で Cisco Unified Mobility Advantage サーバから Cisco Unified CM に転送されます(ステップ 2)。次に、Unified CM によって、会社のPSTN ゲートウェイを使用して、ユーザの携帯電話番号へのコールバックが生成されます(ステップ 3)。Unified CM からの着信コールがモバイル デバイスで自動応答されると、ユーザが呼び出した番号または選択した番号にコールが転送されます(ステップ 4:この場合は 972-555-7890)。コールが遠端で応答されると、会社のPSTN ゲートウェイでコールが固定されます(ステップ 5)。コールが会社のゲートウェイに固定されたため、ユーザは、このコール中の任意の時点で Unified Mobility のデスクトップフォン ピックアップ機能を使用したり、Unified Mobility の通話切替機能を呼び出すことができます。


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


図 25-31 Cisco Unified Mobile Communicator、Dial-via-office リバース コールバック

 

Cisco Unified Mobile Communicator に Dial-via-office リバース コールバック機能が搭載されたほか、Unified Mobile Communicator クライアント設定内でコールバック先の代替番号を指定するオプションも追加されました。たとえば、コールバックを携帯電話で受信するのではなく、会議室の電話に転送できます。


) Dial-via-office リバース コールバック機能の呼び出し時に、Unified CM からのコールバックがユーザ指定の代替番号に転送された場合は、そのコールをデスクトップフォンでピックアップしたり、通話切替機能を呼び出すことはできなくなります。


Dial-via-office リバース コールバックは、Windows Mobile、Nokia、および Blackberry のモバイル ハンドセットでサポートされています。

Dial-via-office 転送

図 25-32 に、Dial-via-office 転送のコール フローを示します。この例では、Unified Mobile Communicator ユーザが、PSTN 電話機(972-555-7890)に電話をかけようとしています。ユーザが、番号をダイヤルするか、コンタクト リストまたはディレクトリ リストから番号を選択すると、会社と Cisco Unified Mobility Advantage サーバへのデータ接続上で SIP INVITE が生成されます(ステップ 1)。この SIP INVITE は、MMP プロトコルにカプセル化され、クライアントと Cisco Unified Mobility Advantage サーバ間の(クライアント タイプに応じて)ASA または BES サーバ経由のセキュアな接続によって送信されます。この要求は、SIP 接続経由で Cisco Unified Mobility Advantage サーバから Cisco Unified CM に転送されます(ステップ 2)。次に Unified CM から、設定されているシステム全体のエンタープライズ機能アクセス番号を使用して Cisco Unified Mobility Advantage サーバに応答があり、そこから(クライアント タイプに応じて)ASA または BES サーバ経由のセキュアな接続によってユーザのモバイル デバイスに転送されます(ステップ 3)。モバイル デバイスで番号が受信されると、Cisco Unified Mobile Communicator クライアントは、モバイル デバイスからエンタープライズ機能アクセス番号へのコールを自動的に発信します(ステップ 4)。Unified CM でこのコールが受信されると、ユーザに設定されたモビリティ ID に対して着信コールの発信者 ID が照合されます。着信コールの発信者 ID がユーザに設定されたモビリティ ID と一致すると、システムから、ユーザがダイヤルまたは選択した番号にコールが発信されます(ステップ 5。この場合は 972-555-7890)。コールが遠端で応答されると、会社のPSTN ゲートウェイでコールが固定されます(ステップ 6)。コールが会社のゲートウェイに固定されたため、ユーザは、このコール中の任意の時点で Unified Mobility のデスクトップフォン ピックアップ機能を使用したり、Unified Mobility の通話切替機能を呼び出すことができます。


) Dial-via-office 転送コールを正常に実行するには、Unified CM でPSTN ネットワークから受信する着信コールの発信者 ID が、Dial-via-office コールを発信する Unified Mobile Communicator デバイスに設定されたモビリティ ID 番号と一致する必要があります。PSTN から着信コールの発信者 ID が送信されない、あるいはその発信者 ID がユーザに設定されたモビリティ ID と一致しない場合、Dial-via-office 転送コールは失敗します。



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


図 25-32 Cisco Unified Mobile Communicator、Dial-via-office 転送

 


) バージョン 3.1 よりも前の iPhone ファームウェアでは、Dial-via-office 転送コールは、ユーザが手動で操作してコールを完了する必要があります。バージョン 3.1 よりも前の iPhone ファームウェアでは、Dial-via-office コールは自動的に完了しません。図 25-32 のステップ 3 で、ユーザに対してクライアントにダイアログボックスが表示されます。ステップ 4 でエンタープライズ機能アクセス番号へのコールを発信するには、ユーザは [Call] を選択する必要があります。


Cisco Unified Mobile Communicator から、Dial-via-office 転送コール用に Unified CM によって送信されるエンタープライズ機能アクセス番号にダイヤルできるようにするには、送信される番号が完全な E.164 番号であり、モバイル ボイス ネットワークを介してダイヤルできることが必要です。Unified CM 内の [Enterprise Feature Access Directory Number] フィールド([Call Routing] > [Mobility Configuration] の下)で設定された番号が完全な E.164 番号ではない場合、管理者は、Cisco CallManager サービスの Dial-via-Office Forward Service Access Number サービス パラメータに、Unified CM 内で設定されたエンタープライズ機能アクセス ディレクトリ番号に対応する完全な E.164 番号を設定する必要があります。[Dial-via-Office Forward Service Access Number] サービス パラメータが設定されていないと、Unified CM から、設定されたエンタープライズ機能アクセス番号がそのまま送信されます。この番号は完全な E.164 番号ではないため、Cisco Unified Mobile Communicator から Unified CM システムへのコール(図 25-32 のステップ 4)は失敗し、Dial-via-office 転送機能は動作不能になります。

たとえば、エンタープライズ機能アクセス ディレクトリ番号が Unified CM 内で 51234 として設定されているとします。[Dial-via-Office Forward Service Access Number] が設定されていない場合、Unified CM はそのエンタープライズ機能アクセス番号 51234 を Unified Mobility Advantage に転送し、その結果、Unified Mobile Communicator デバイスのコール ダイアログに 51234 と表示されます。ユーザが [Call] オプションを選択すると、電話機からモバイル ボイス ネットワークを介して 51234 へのコールが試行されますが、このコールは失敗します。ただし、[Dial-via-Office Forward Service Access Number] が 9195551234 と設定されている場合には、Unified CM から Unified Mobility Advantage にエンタープライズ機能アクセス番号 9195551234 が転送されます。これにより、ユーザが [Call] オプションを選択すると、コールは適切にモバイル ボイス ネットワークとPSTN を介して企業にルーティングされます。

Dial-via-office 転送は、Cisco Mobile、つまり iPhone および Blackberry 対応の Cisco Unified Mobile Communicator クライアントでサポートされています。

Nokia Call Connect と Cisco Unified Mobile Communicator との間の相互作用

Nokia Call Connect デュアルモード クライアントは、Nokia 対応の Cisco Unified Mobile Communicator クライアントと並行して使用できます。両方のクライアントが配置された場合、Nokia デバイスからエンタープライズ IP テレフォニー インフラストラクチャを利用して社内でコールを発信および受信できるだけでなく、ディレクトリ ルックアップ、デスクトップフォンのコール ログ統合、プレゼンス、ビジュアル ボイスメール、テキスト メッセージング、Dial-via-office などの Unified Mobile Communicator の機能を利用することもできます。Nokia Call Connect デュアルモード クライアントと Unified Mobile Communicator を統合するには、Unified CM 内の Nokia S60 デバイスの設定ページの [Enable Cisco Unified Mobile Communicator] チェックボックスをオンにします。

Unified CM 内で設定すると、両方のクライアントを Nokia デュアルモード デバイス上で実行できるようになります。ただし、Dial-via-office 機能に対する影響を理解することが重要です。2 つのクライアント内の他のすべての機能は通常どおり動作しますが、Nokia Call Connect クライアントが同じデバイスにインストールされている場合には、Dial-via-office 機能の動作は若干異なります。Unified Mobile Communicator 内の Dial-via-office 機能は、モバイル ボイス ネットワーク(携帯電話インターフェイス)経由でルーティングされたコールに対してだけ実行されます。このため、Nokia Call Connect クライアントから WLAN インターフェイス経由で発信されたコールでは、Dial-via-office は実行されません。この場合コールはすでにエンタープライズ IP テレフォニー インフラストラクチャ経由で発信されているため、これは適切な動作です。

ただし、モバイル ボイス ネットワーク(携帯電話インターフェイス)経由で発信されたコールでは、Unified Mobile Communicator クライアント内の Dial-via-office 設定、または Cisco Unified Mobility Advantage サーバの Dial-via-office 設定に応じて、Dial-via-office 機能が実行されるかどうかが決まります。Unified Mobility Advantage サーバの管理者がユーザに対して Dial-via-office の使用を強制した場合、Unified Mobile Communicator クライアントでは、デバイスの携帯電話インターフェイスから発信されたすべてのコールで Dial-via-office の呼び出しが試みられます。このような状況においては、ユーザは、Unified Mobile Communicator クライアントで設定パラメータ [Allow dial via office for] を [Call from this app] に設定して、Unified Mobile Communicator クライアントから直接発信されたコールでだけ Dial-via-office が呼び出されるようにする必要があります。クライアントをこのように設定することによって、ユーザは、Unified Mobile Communicator クライアントの外部で携帯電話インターフェイス経由でコールが発信された場合に Dial-via-office 機能が実行されないようにできます。たとえば、Nokia Call Connect クライアントで企業の WLAN からモバイル ボイス ネットワークへのコールのハンドアウトが試みられている場合には、Nokia デバイスで Dial-via-office を実行することは望ましくありません。ハンドアウト時には、Nokia デュアルモード デバイスの携帯電話インターフェイスから Unified CM ハンドオフ番号に対してコールが発信されます。Dial-via-office が実行されると、追加の不要なコール レッグが作成されて、元のコールのハンドオフに失敗する可能性があります。

同様に、管理者が個々の Unified Mobile Communicator ユーザにクライアント内で独自の Dial-via-office 設定を行うことを許可している場合、ユーザはクライアントを設定して、携帯電話インターフェイス経由でコールの発信が試みられるたびに、直接コールを発信するか、または Dial-via-office を使用して発信するかを選択できるようにできます。Unified Mobile Communicator の [When dialing] 設定を [Let me choose] に設定し、[Allow dial via office for] 設定を [Call from this app] に設定することによって、ユーザは、Dial-via-office が使用されるタイミングについて、各自の意思を最大限反映できます。いずれの場合でも、ユーザは、Nokia デュアルモード デバイスが社外にあり、Unified CM に登録されていない場合にだけ Dial-via-office を使用する必要があります。

Cisco Unified Mobile Communicator のソリューション、フィーチャ セット、および設計と配置の考慮事項の詳細については、「デュアルモードの電話機とクライアント」を参照してください。

Unified Mobility の統合

コール ログ統合と Dial-via-office のための Unified CM との統合に加えて、Unified Mobile Communicator ユーザは、Unified Mobility と統合してモバイル コネクトを利用できます。これによって、ユーザの会社の電話番号への着信コールを携帯電話に転送できるようになります。Cisco Unified Mobile Communicator クライアントと Unified Mobility の統合は、Unified CM 内で Cisco Unified Mobile Communicator デバイスに直接関連付けられた設定済みのモビリティ ID を経由して実現されます。Unified CM 内のモビリティ ID の設定は、リモート接続先と同じです。また、リモート接続先番号と発信者 ID の照合の設定に関するガイドライン(「リモート接続先の設定と発信者 ID の照合」を参照)がすべて、モビリティ ID の設定にも適用されます。Unified Mobile Communicator クライアント インターフェイス内でユーザは、[General] 設定メニューで [Moblie Connect (Single Number Reach)] を有効または無効にできます。

Cisco Unified Presence

Unified Mobile Communicator ユーザが企業ネットワークに対して自分のプレゼンス ステータスや利用可能性を更新できるように、Unified Mobility Advantage サーバと Cisco Unified Presence を統合できます。同様に、Unified Mobile Communicator クライアントは、ユーザのバディ リスト、ディレクトリ リスト、コンタクト リスト、ボイスメール メッセージ リスト、およびコール履歴ログ内で他の社内クライアントに関するプレセンス情報を受信します。プレゼンス ステータスとバディ リストは、Unified Mobile Communicator クライアントとユーザの Cisco Unified Personal Communicator クライアントの間で同期化されます。Unified Mobile Communicator ユーザは、クライアント上で自分の利用可能性を調整したり、Microsoft Exchange パーソナル カレンダーの利用可能性とデスクトップフォンの回線状態に基づく利用可能性の自動更新を利用できます。図 25-30 に示すように、Cisco Unified Presence との統合は、Unified Mobility Advantage サーバと Cisco Unified Presence サーバ間の SIP/SIMPLE 接続を通して実現されます。


) Cisco Mobile、つまり iPhone 対応の Unified Mobile Communicator クライアントには、プレゼンス ステータスは表示されず、プレゼンス ステータスのアップデートの送受信もサポートされていません。


Cisco Unity と Unity Connection ボイスメール

Unified Mobility Advantage サーバを Cisco Unity(Unified Messaging または Integrated Messaging モード)および Cisco Unity Connection ボイスメール システムに統合することにより、Unified Mobile Communicator クライアントにユーザの会社のボイスメール ボックスに関する Message Waiting Indication(MWI; メッセージ待機インジケータ)を提供できます。この統合によって、ユーザは、モバイル デバイスを使用して視覚的にボイスメール ボックスをナビゲートすることもできます。ボイスメール ボックス内のすべてのメッセージのリストをナビゲートできます。このリストには次の情報が含まれています。

メッセージが残された時間

メッセージ長

メッセージを残した人物の発信者 ID または名前(可能な場合)

メッセージの優先順位指定

メッセージを残した人物の現在のプレゼンスまたは利用可能性の指定(その人物が会社のプレゼンス インフラストラクチャにプレゼンス ステータスを提供している場合)

ユーザがリストからメッセージを選択すると、Unified Mobile Communicator クライアントによってデータ接続を通してメッセージがダウンロードされます。ユーザは、ボイスメール システム上でそのメッセージを再生して、削除または保存できます。Cisco Unified Mobile Communicator クライアントによるボイスメール メッセージのステータスに対する変更(メッセージに対する再生済みのマーキングやメッセージの削除など)は、ボイスメール システムに伝播され、ユーザのデスクトップフォンと Cisco Unified Personal Communicator などのその他のクライアントに適切に反映されます。ボイスメール メッセージは任意の順序でナビゲートできます。図 25-30 に示すように、Unified Mobility Advantage サーバと Cisco Unity または Unity Connection は IMAP プロトコルを使用して統合されます。

Cisco Unified MeetingPlace

Unified Mobile Communicator ユーザが MeetingPlace 会議の開催通知または招待を受信できるように、Unified Mobility Advantage サーバと Cisco Unified MeetingPlace を統合できます。この会議通知には、会議の議題、日時、ダイヤルイン番号、および会議 ID が含まれています。ユーザは、ダイヤルイン番号をクリックすれば呼び出すことができます。


) クリックツージョインは、Cisco Mobile、つまり iPhone および Blackberry 対応の Cisco Unified Mobile Communicator だけでサポートされています。その他すべての Cisco Unified Mobile Communicator クライアントについては、コールが接続された後、ユーザが手動で会議 ID を入力する必要があります。


Cisco Unified MeetingPlace との統合は、Unified Mobility Advantage サーバから会議システムで使用されている Microsoft Exchange サーバへの直接接続を経由して実現されます。図 25-30 に示すように、この接続では、Web-based Distributed Authoring and Versioning(WebDAV)プロトコルが使用されます。

Cisco Unified Mobile Communicator クライアント(Cisco Mobile を含む)で会議通知を受信するには、システム管理者は Cisco Unified MeetingPlace 会議通知電子メール テンプレートを変更して、各会議通知に cump:// のプレフィックスが付いたリンクを含める必要があります。Cisco Unified Mobility Advantage サーバでは、ユーザの Exchange メールボックス内に含まれるすべての会議通知でこのリンクが検索されます。会議通知にこのリンクが含まれていない場合、会議の通知はクライアントで受信されず、表示もされません。Cisco Unified MeetingPlace 会議通知電子メール テンプレートで必要な変更の詳細については、次の Web サイトで入手可能な『 Configuring Features in Cisco Unified Mobility Advantage: Meeting Features 』を参照してください。

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

MeetingPlace との統合により、会議通知がサポートされるだけでなく、パスワードや会議 ID の入力を必要としない会議へのクリックツージョインも可能です。図 25-30 のとおり、このクリックツージョイン機能は、MeetingPlace サーバの Web Services API への SOAP コールによって実施されます。


) クリックツージョインは、Cisco Mobile、つまり iPhone および Blackberry 対応の Unified Mobile Communicator クライアントだけでサポートされています。


Cisco WebEx によって Cisco Unified MeetingPlace 会議の Web 共有機能が提供される配置においては、iPhone Cisco Mobile クライアントは、iPhone で Cisco WebEx Meeting Center アプリケーションを相互に起動します(このアプリケーションがデバイスにインストール済みであることが前提です)。この相互起動が動作するには、Cisco Unified MeetingPlace システムが Cisco WebEx と正常に統合されている必要があります。

Microsoft Exchange

Cisco Unified MeetingPlace の会議統合に関する Microsoft Exchange との通信に加えて、Cisco Unified Mobility Advantage サーバと Microsoft Exchange を WebDAV 経由で統合すれば、Exchange に保存されたユーザの個人的なコンタクト リストの維持管理が容易になります。Exchange との統合によって、ユーザのプレゼンス ステータスを Exchange カレンダーの利用可能性に基づいて自動的に更新することもできます。Microsoft Exchange はオプションのコンポーネントであり、会議通知、個人的なコンタクト リスト、またはカレンダー統合が必要である場合にだけ必要です。

安全なテキスト メッセージング

前述したアプリケーションと機能の統合に加えて、Unified Mobile Communicator ユーザは、Unified Mobile Communicator クライアントを使用している他のユーザに安全なテキスト メッセージを送信することもできます。このメッセージ交換は、Cisco Unified Mobility Advantage サーバ内でネイティブに実施されます。これらのメッセージは、モバイル データ接続を使用して交換されるため、SMS プロバイダーの利用料がかかります。


) Cisco Mobile、つまり iPhone 対応の Unified Mobile Communicator クライアントでは、Cisco Unified Mobility Advantage サーバを使用した安全なテキスト メッセージングをサポートしていません。


Cisco Unified Mobile Communicator のハイ アベイラビリティ

Cisco Unified Mobile Communicator クライアントは、アプリケーションの相互作用と機能を Cisco Unified Mobility Advantage Server にバックホールされるモバイル データ ネットワーク上のデータ接続に完全に依存しています。このデータ接続が、モバイル データ ネットワーク内の障害、モバイル データ ネットワークとの接続切断、または ASA TLS プロキシや BES サーバ、Cisco Unified Mobility Advantage サーバの故障が原因で失われた場合は、企業アプリケーションにアクセスできなくなります。この種の障害が発生した場合、ユーザは、Unified Mobile Communicator にアクセスしてさまざまなアプリケーション統合を利用できなくなります。たとえば、ディレクトリ ルックアップの実行、他のクライアントへのテキスト メッセージの送信、ビジュアル ボイスメールへのアクセス、個人連絡先へのアクセス、メッセージ待機インジケータの受信、会議通知の受信、バディ リストとプレゼンス情報の更新または同期化、Dial-via-office 機能を使用した発信などができなくなります。


) Cisco Unified Mobile Communicator クライアントと Cisco Unified Mobility Advantage 間のデータ接続または Cisco Unified Mobility Advantage と Cisco Unified CM 間の接続に障害がある場合、クライアントは、Dial-via-office が強制されていても、直接通話に戻ります。


会社へのデータ接続が使用できない場合は、Unified Mobile Communicator から提供される機能を利用できなくなりますが、モバイル ボイス ネットワークを使用してモバイル デバイスで電話をかけたり、電話に出ることができます。加えて、Unified CM 上でユーザと携帯電話が Unified Mobility に統合されている場合は、モバイル コネクト機能だけでなく、モバイル ボイス アクセスやエンタープライズ機能アクセスなどの機能も使用できます。

Cisco Unified Presence、Cisco Unified CM、Cisco Unity および Unity Connection などの企業アプリケーションに不具合がある場合は、構成によりそれらのアプリケーションの特性に応じて特定の機能が利用できなくなります。ただし、ほとんどの場合、Unified Mobility Advantage サーバ内に複数のアダプタを設定できますし、さまざまなアプリケーションに対する冗長性が提供されていれば、アプリケーションまたはアプリケーション サーバに障害が発生しても機能性を維持できます。

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

Cisco Unified Mobility Advantage サーバでは、次のユーザの容量をサポートしています。

Cisco MCS 7845-H2/I2 では、最大 1,000 台の Unified Mobile Communicator クライアントをサポートする。

Cisco MCS 7825-H4/I4 では、最大 500 台の Unified Mobile Communicator クライアントをサポートする。

Cisco MCS 7825-H2/I2 または 7825-H3/I3 では、最大 250 台の Unified Mobile Communicator クライアントをサポートする。

1 箇所で 1,000 人を超える Unified Mobile Communicator ユーザをサポートするには、追加の Unified Mobility Advantage サーバをインストールする必要があります。ただし、1 台の Cisco Unified Mobility Advantage サーバに関連付けるように設定された Unified Mobile Communicator クライアントは、別のサーバ上のクライアントにテキスト メッセージを送信できません。

エンタープライズ コール ログ統合のために Unified Mobile Communicator と Cisco Unified CM を統合した場合は、Unified Mobility Advantage サーバと Unified CM CTIManager が連携してデスクトップフォンの回線をモニタします。コール ログ統合が有効にされた Unified Mobile Communicator ごとに、Cisco Unified Mobility Advantage サーバが CTIManager への CTI 接続を確立します。そのため、すべてのユーザに対してコール ログ統合が有効にされた MCS 7845 を実行しているフル実装の Unified Mobility Advantage サーバと一緒に Unified Mobile Communicator を配置した場合は、1,000 個の CTI 接続が消費されます。この理由から、Unified Mobile Communicator とコール ログ統合を配置する際は、次に示す CTI 接続に対するクラスタ全体の制限に関して、必要な CTI 接続の数を検討する必要があります。

MCS 7845-I3 または同等 OVA サーバを使用する場合は、Unified CM クラスタごとに 40,000 個の CTI 接続。

Cisco MCS 7845-H2/I2 または同等 OVA サーバを使用する場合は、Unified CM クラスタごとに 20,000 個の CTI 接続。

Cisco MCS 7835-H3/I3 または同等 OVA サーバを使用する場合は、Unified CM クラスタごとに 10,000 個の CTI 接続。

Cisco MCS 7835-H2/I2 サーバを使用する場合は、Unified CM クラスタごとに 8,000 個の CTI 接続

Cisco MCS 7825-H5/I5 または同等 OVA サーバを使用する場合は、Unified CM クラスタごとに 4,000 個の CTI 接続。

現在サポートされているその他すべての Cisco MCS 7825 および MCS 7835 サーバを使用する場合は、Unified CM クラスタごとに 3,600 個の CTI 接続。

他のアプリケーション用の CTI 接続が必要な場合は、コール ログ統合を有効にする Unified Mobile Communicator ユーザの容量を制限できます。

Dial-via-office と Unified Mobility 機能のための Unified Mobile Communicator と Unified CM の統合では、各 Unified Mobile Communicator を Unified CM デバイスとして設定し、携帯の番号をモビリティ ID として設定する必要があります。したがって、これらの統合を実施する場合は、Unified CM 電話機とモビリティ対応ユーザの機能全体を検証する必要もあります。

Cisco Unified Mobile Communicator の設計上の考慮事項

Cisco Unified Mobile Communicator を配置する際は、次の設計上の考慮事項に従ってください。

Cisco Unified Mobility Advantage サーバはすべての企業サービスおよびアプリケーションの統合ポイントであるため、セキュリティ上の理由から、このサーバは企業ファイアウォールの後ろに配置する必要があります。

Cisco Adaptive Security Appliance(ASA)は、Cisco Unified Mobile Communicator クライアントと Cisco Unified Mobility Advantage サーバとの通信用のプロキシ サーバとして機能するため、企業 DMZ には ASA を配置する必要があります。

認証局から SSL 認証を取得する必要があります。この認証は、Cisco Unified Mobile Communicator クライアントと Cisco Unified Mobility Advantage サーバ間に流れるデータの暗号化を有効にするために必要です。

携帯電話にはルート認証のインポートに関する機能制限があるため、SSL 認証は、VeriSign または GeoTrust などの有名な認証局から取得する必要があります。VeriSign や GeoTrust からのルート認証は通常、ほとんどのモバイル ハンドセットで利用できます。

社内ファイアウォールのファイアウォール ポートを開いて、インターネット上の Cisco Unified Mobile Communicator クライアントから DMZ 内の ASA、および DMZ 内の ASA から社内の Cisco Unified Mobility Advantage サーバに接続できるようにする必要があります。次のファイアウォール ポートを開く必要があります。

クライアント接続ポート(SSL):5400 ~ 5500 の範囲の 1 つの TCP ポート(デフォルト ポートは 5443)

プロビジョニング ポート(HTTP):9000 ~ 9100 の範囲の 1 つの TCP ポート(デフォルト ポートは 9080)


) iPhone または Blackberry ハンドセットだけを配置している場合、これらのハンドセットはプロビジョニング ポートを介して Cisco Unified Mobile Communicator クライアントをダウンロードしないため、ファイアウォールのプロビジョニング ポートを開く必要はありません。このクライアントは、iPhone ハンドセットの場合は Apple App Store からダウンロードされ、Blackberry ハンドセットの場合は Blackberry Enterprise Server(BES)を介してハンドセットにプッシュされます。


Cisco Unified Mobile Communicator ユーザを認証するため、Microsoft Active Directory が必要です。すべての Cisco Unified Mobile Communicator ユーザは Microsoft Active Directory 内に有効なアカウントを持つ必要があります。そうしないと、認証に失敗し、このソリューションが提供する機能やサービスを利用できません。

常に、適切なバックエンド企業アプリケーション サーバが配置され、必要な Cisco Unified Mobile Communicator ソリューション機能に基づいて適切に設定されていることを確認します。サポートされている機能および必要なバックエンド アプリケーション サーバの全リストについては、次の Web サイトで入手可能な『 Compatibility Matrix for Cisco Unified Mobility Advantage and Cisco Unified Mobile Communicator 』を参照してください。

http://www.cisco.com/en/US/products/ps7270/products_device_support_tables_list.html

Blackberry 対応の Unified Mobile Communicator クライアントである Cisco Mobile を配置する場合、Blackberry Enterprise Server(BES)および Mobile Data Services(MDS)も配置して、これを Unified Mobility Advantage サーバに直接統合する必要があります。Blackberry デバイス上の Cisco Mobile クライアントは、会社の ASA には接続せず、セキュアな Research In Motion(RIM)モバイル Network Operations Center(NOC; ネットワーク オペレーション センター)および NOC から会社の BES サーバへのセキュア接続を使用して Unified Mobility Advantage サーバに接続します。

Nokia Call Connect デュアルモード クライアントと Cisco Unified Mobile Communicator Nokia クライアントの両方が同じハンドセットに配置されている状況においては、デュアルモード デバイスが社内にあり、Unified CM に登録されている場合に Dial-via-office を使用しないでください。次のことを推奨します。

企業にデュアルモード電話機を配置する場合、Cisco Unified Mobility Advantage Server の管理者は、[Dial Via Office Policy] 設定を使用して Dial-via-office の使用を強制しないでください。代わりに、Dial-via-office を使用するかどうかをユーザが選択できるようにする必要があります。

Cisco Unified Mobility Advantage サーバの管理者によって Cisco Unified Mobile Communicator における Dial-via-office の使用が強制されている場合、ユーザは Unified Mobile Communicator クライアント内で [Allow dial via office for] 設定を [Call from this app] に設定して、Unified Mobile Communicator クライアント内から直接発信されたコールでだけ Dial-via-office の呼び出しが試みられるようにする必要があります。クライアントをこのように設定することによって、ユーザは、予期せず Dial-via-office が実行されないようにできます。Unified Mobile Communicator クライアントがフォアグラウンドで実行されていない場合、Dial-via-office は呼び出されません。

Unified Mobility Advantage の管理者によって Dial-via-office の使用が強制されていない場合、Unified Mobile Communicator ユーザは、[When dialing] 設定を [Let me choose] に、[Allow dial via office for] 設定を [Call from this app] に設定する必要があります。このように設定することによって、ユーザは、Dial-via-office が使用されるタイミングについて、各自の意思を最大限反映できます。いずれの場合でも、ユーザは、Nokia デュアルモード デバイスが社外にあり、Unified CM に登録されていない場合にだけ Dial-via-office を使用する必要があります。

ダイレクト コネクト モバイル クライアント

ダイレクト コネクト モバイル クライアントは、モバイル ユーザが携帯電話から Cisco Unified Communications アプリケーションにアクセスし、利用することを可能にするソリューションを提供します。Cisco Unified Mobile Communicator ソリューションと同様に、モバイル スマート フォンで動作するダイレクト コネクト クライアント アプリケーションは、企業内の 1 つまたは複数のアプリケーション サーバと連動して動作し、企業のボイスおよびコラボレーション アプリケーションにアクセスして利用するための高度なユーザ インターフェイスを提供します。ただし、Cisco Unified Mobile Communicator ソリューションとは異なり、ダイレクト コネクト モバイル クライアントは、Cisco Unified Mobility Advantage などの中間サーバを介さずにバックエンド アプリケーション サーバと直接通信するので、「ダイレクト コネクト」と呼ばれます。ダイレクト コネクト モバイル クライアントは、各種のバックエンド企業アプリケーション サーバに備わっているスケーラビリティと信頼性を利用します。

ダイレクト コネクト モバイル クライアントは、コラボレーション アプリケーションにアクセスし、使用する機能を提供するばかりでなく、コールの発信および受信に Voice over WLAN(VoWLAN)機能も利用できるので、デュアルモード機能が実現します。Dial-via-office 操作と Voice over WLAN コールの両方をサポートする企業は、携帯電話ネットワークの音声トラフィックを企業データ ネットワークにオフロードしたり、市内通話やフリーダイヤル システムのアクセス番号を利用して会社経由の低コストのコール ルーティングを実現したりすることで、モバイル コールのコストを大幅に削減できます。

ここでは、ダイレクト コネクト モバイル クライアントのアーキテクチャと、Dial-via-office や XMPP ベースの IM およびプレゼンスなど、これらのクライアントが提供する共通の機能について説明します。この項では、一般的なダイレクト コネクト モバイル クライアントのアーキテクチャおよび機能について説明した後、Cisco Mobile 8.5 for Nokia ダイレクト コネクト モバイル クライアントのさまざまな機能および統合に関する考慮事項について説明します。

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

ダイレクト コネクト モバイル クライアントのアーキテクチャ

ダイレクト コネクト モバイル クライアントは、会社へのリモート データ接続と IEEE 802.11 標準を使用した Wireless Local Area Network(WLAN)経由のオンプレミス データ接続の両方を可能にします。さらに音声接続も、モバイル ボイス ネットワークおよび PSTN 経由あるいは 802.11 WLAN またはモバイル データ ネットワーク経由で有効になります。

図 25-33 は、モバイル スマート フォン デバイスを Cisco Unified Communications System に接続するための基本的なダイレクト コネクト ソリューション アーキテクチャを示しています。ダイレクト コネクト モバイル クライアントを使用すると、モバイル データ ネットワークあるいはパブリックまたはプライベートの Wi-Fi ホット スポットを使用してインターネット経由でモバイル デバイスから企業に接続し、Cisco Unified CM、LDAP 社内ディレクトリ、Cisco Unified Presence などのバックエンド アプリケーション サーバと通信することができます。さらに、社内では、デバイスを企業の WLAN を介してこれらの同じバックエンド アプリケーションおよびサービスに接続できます。

図 25-33 ダイレクト コネクト モバイル クライアントのアーキテクチャ

 

ダイレクトコネクト クライアントは会社の電話機として、モバイル データ ネットワークや Wi-Fi ホット スポットを介してリモートから、または企業の WLAN に関連付けてローカルに、Cisco Unified CM に登録されます。登録されたダイレクト コネクト クライアントは、エンタープライズ テレフォニー インフラストラクチャを利用して、音声パスがモバイル ボイス ネットワークまたはPSTN を経由している場合は Dial-via-office を介して、または VoWLAN を介してコールを発信および受信します。また、保留、転送、会議などの付加的なコール機能を提供するため、およびモバイル コネクトを有効または無効にするために SIP(および場合によっては SCCP)シグナリングも利用できます。企業の WLAN 接続およびモバイル ボイス ネットワークまたは Wi-Fi ホット スポットを介した会社へのリモート データ接続が利用できない場合、携帯電話はモバイル ボイス ネットワークを利用してコールを発信および受信します。また、この場合、通話中の付加機能は、モバイル ボイス ネットワークおよび PSTN 経由で DTMF 機能アクセス コードのみにより呼び出すことができます。

ダイレクト コネクト クライアント デバイスが企業ネットワークに接続されている場合、そのデバイスにはユーザの会社の電話番号を通じて到達できます。ユーザの会社の電話番号に着信コールがあると、IP に接続したデバイスの呼出音が鳴ります。ユーザが Cisco IP デスクフォンを持っている場合は、ダイレクト コネクト クライアントを登録すると、ユーザの会社の番号でシェアド回線インスタンスが使用可能になり、コールが着信すると、ユーザのデスクフォンと携帯電話の両方の呼出音が鳴ります。企業ネットワークに接続されていない場合、クライアント デバイスは未登録となります。この場合、ユーザに対して Unified Mobility が有効になっており、携帯の番号でモバイル コネクト(またはシングル ナンバー リーチ)がオンになっているときに限り、ビジネス コールを受信できます。

同様に、ダイレクト コネクト クライアントを利用すると、企業に直接またはリモート接続している場合は、XMPP 経由で IM およびプレゼンス サービスにアクセスしたり、LDAP 経由でディレクトリ サービスにアクセスすることができます。

ネットワーク接続:WLAN および VPN

ダイレクト コネクト モバイル クライアントは、WLAN およびモバイル データ ネットワークの両方を使用した企業ネットワークへの接続に対応します。企業にリモートから接続するには、通常、VPN セキュア接続が必要です。これらのクライアントに対してこのネットワーク接続を有効にするには、会社が利用を計画している接続方式に応じて、適切な WLAN、VPN、またはその両方のインフラストラクチャを装備することが重要です。

WLAN インフラストラクチャ

WLAN をネットワーク接続に利用する場合、適切に調整され、QoS に対応し、高い可用性を備えた WLAN ネットワークを展開することが不可欠です。ダイレクト コネクト モバイル クライアントは、基礎となる WLAN インフラストラクチャに全体的または部分的に依存して重要なシグナリングとリアルタイム音声メディア トラフィックの両方、および各種アプリケーションにアクセスするためのデータ トラフィックを伝送するため、データ トラフィックとリアルタイム音声トラフィックの両方に対して最適化された WLAN ネットワークを展開する必要があります。WLAN ネットワークの展開が適切でないと、多くの干渉が発生し、容量が低下するため、音声品質が低下するだけでなく、コールがドロップされたり、つながらなかったりする可能性もあります。このように展開された WLAN は、音声コールの発信および受信に使用できなくなります。したがって、展開されたダイレクト コネクト モバイル クライアントに WLAN 接続を利用する場合は、Voice over WLAN(VoWLAN)の展開が正常に行われるように、展開前、展開中、展開後に WLAN Radio Frequency(RF; 無線周波数)実地調査を実施して、適切なセル境界、設定、機能設定、容量、および冗長性を判断する必要があります。他の WLAN 対応クライアントと同様に、実稼働環境への展開の前に、WLAN の展開に対して各携帯電話機やクライアントをテストして、統合および動作が適切に行われるようにする必要があります。Quality of Service を含む最適な VoWLAN サービス(Cisco Unified Wireless Network など)が提供されるように配置および設定された WLAN を使用することによって、ダイレクトコネクト デバイスを正常に展開できます。

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

VPN インフラストラクチャ

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

VPN 接続のタイプと方式はさまざまで、Cisco IOS VPN または Cisco Adaptive Security Appliance(ASA)を利用する標準ベースの IPSec から、Cisco ASA を利用する Cisco AnyConnect および Cisco Jabber Secure Connect 機能まで各種のオプションがあります。使用する VPN 方式またはクライアントのタイプは、多くの場合、配置するモバイル デバイスによって異なります。

Cisco AnyConnect などのセキュアなリモート VPN 接続ソリューションの詳細については、次の Web サイトで入手可能なセキュア モビリティのマニュアルを参照してください。

http://www.cisco.com/en/US/products/hw/vpndevc/products.html#mobi

Cisco Jabber Secure Connect の詳細については、次の Web サイトで入手可能な『 Cisco Jabber Secure Connect Deployment Guide 』を参照してください。

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


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


ダイレクト コネクト モバイル クライアントの機能

ダイレクト コネクト モバイル クライアントには、さまざまな機能が用意されています。サポートされている機能および操作はクライアントごとに異なりますが、ここで説明する機能や動作はすべてのダイレクト コネクト モバイル クライアントに適用されます。

コール ルーティング

ダイレクト コネクト モバイル クライアントは、企業の電話インフラストラクチャを使用してコールを発信および受信できるので、ダイレクト コネクト モバイル クライアントの動作に関係しているコール ルーティングの特性を理解することが大切です。

着信コール ルーティング

ダイレクト コネクト モバイル クライアントを Unified CM に登録すると、Dial-via-office と VoIP コールの両方を利用できますが、ネットワーク接続によって着信コール ルーティングの動作がわずかに異なります。クライアントが企業の WLAN 経由または企業へのセキュアな VPN 経由で Unified CM に接続および登録されている場合、そのクライアントは、登録されている IP デスクフォンのように(発信が社内か PSTN からかに関係なく)会社の番号への着信コールを受信します。ユーザがデスクフォンを所有している場合、着信コールによってモバイル クライアント デバイスとデスクフォンの両方のシェアド ラインが呼び出されます。一方、クライアントが企業ネットワークに直接またはセキュア リモート接続経由で接続していない場合は、ユーザに対して Cisco Unified Mobility が有効になっており、ユーザのダイレクト コネクト クライアント デバイスの携帯の番号でモバイル コネクト(シングル ナンバー リーチ)が有効であるときに、会社の番号に着信コールがあると(発信元が社内か PSTN からかに関係なく)、デバイスの携帯の番号が呼び出されます。デュアルモード クライアント デバイスと同様に、クライアント デバイスが企業ネットワークに接続し、Unified CM に登録されている場合、会社の番号への着信コールがモバイル コネクトを介してダイレクト コネクト クライアント デバイスの携帯の番号に転送されることはありません。

いずれの場合も、ダイレクト コネクト クライアント デバイスの携帯電話番号に対して直接発信された着信コールは、プロバイダー ネットワークやデバイスの設定でモバイル ネットワーク経由でデバイスにコールが転送されないように設定されている場合を除き、モバイル ネットワークでデバイスに直接ルーティングされます。このようなコールは、ユーザの会社の電話番号に対して発信されたコールではないため、適切な動作です。これらのコールは個人的なコールであると見なされるため、会社経由でルーティングされません。

発信コール ルーティング

ダイレクト コネクト モバイル クライアント デバイスのネットワーク接続の特性により、発信コールのルーティング動作はわずかに異なります。デバイスが企業の WLAN に接続し、Unified CM に登録されている場合、発信コールは社内番号宛てか、社外のPSTN 番号宛てかにかかわらず、Unified CM 内のダイヤル プラン設定に基づきエンタープライズ テレフォニー インフラストラクチャによってルーティングされます。代わりにデバイスがモバイル データ ネットワーク経由あるいはパブリックまたはプライベートの Wi-Fi ホット スポット経由で企業に安全に接続されている場合、接続品質に応じて、発信コール ルーティングが VoIP または Unified CM 内の Dial-via-office 機能によって実施されます。Dial-via-office の場合、コール シグナリングは企業へのモバイル データ接続を通過し、音声メディアはモバイル ボイス ネットワークと PSTN を通過します。企業接続が使用できない場合、会社の番号からコールを発信することはできず、代わりにダイレクト コネクト クライアント デバイスの携帯の番号を利用してモバイル ボイス ネットワーク経由でコールを発信する必要があります。または、Cisco Unified Mobility に装備されている 2 ステージ ダイヤリング機能を利用することもできます(「モバイル ボイス アクセスとエンタープライズ機能アクセス」を参照)。

ダイヤル プラン

Dial-via-office および VoIP コールの使用により、ダイレクト コネクト モバイル クライアントでは、内線用の短縮ダイヤルや PSTN およびサイト間の振り分け用数字を利用したダイヤリングを含む企業のダイヤリング方式を使用して、発信コールをダイヤルできます。ただし、企業接続がないために Dial-via-office 機能や VoIP コールを使用できない場合には、企業のダイヤリング方式を使用できず、ユーザはモバイル ボイス ネットワークおよび PSTN で必要とされる完全長の E.164 番号ダイヤリングを使用して発信コールをダイヤルする必要があります。

企業のダイヤリングでは便利な短縮ダイヤルを利用できますが、企業のダイヤリングとPSTN またはモバイル ボイス ネットワーク ダイヤリングでは異なるため、ユーザが会社に接続しているかどうかに関係なく同じ番号をダイヤルして着信側接続先に到達できるよう、必要なダイヤリング パターンを正規化することが推奨されます。ダイレクト コネクト モバイル クライアントのユーザ用に Unified CM 内でダイヤル プランとダイヤリング動作を正規化することにより、管理者は、クライアント デバイスが会社に接続し、Unified CM に登録されているかどうかをユーザが気にする必要のない、最善のエンドユーザ ダイヤリング エクスペリエンスを提供できます。

モバイル クライアントのダイヤル プランの正規化の詳細については、デュアルモードの電話機とクライアントに関する「ダイヤル プラン」を参照してください。

発信者 ID

ダイレクト コネクト モバイル クライアント デバイスが(直接、パブリックまたはプライベートの Wi-Fi ホット スポット経由、またはモバイル データ ネットワーク経由で)企業に接続され、Unified CM に登録されている場合、Dial-via-office または IP ネットワークを利用して発信されたすべてのコールは、ユーザの会社の番号を発信者 ID とした状態でルーティングされます。これにより、遠端でコール履歴リストから発信される返信コールはユーザの会社の番号に対して発信されることになり、常に会社経由でルーティングされます。ダイレクト コネクト モバイル クライアントのユーザに対して Cisco Unified Mobility が有効になっており、ダイレクト コネクト クライアント デバイスの携帯の番号でモバイル コネクトがオンになっている場合、クライアント デバイスに企業ネットワーク接続がないと、会社の番号への返信コールも PSTN 経由でダイレクト コネクト モバイル クライアント デバイスに転送されます。

緊急サービス

他のモビリティ クライアント ソリューションと同様に、ダイレクト コネクト モバイル クライアントから 911、999、および 112 などの公共サービス番号への緊急コールを発信すると問題が生じます。 ダイレクト コネクト モバイル クライアント デバイスは社内にある可能性も、社外にある可能性もあるので、緊急時における位置の通知について考慮する必要があります。携帯電話はすでにプロバイダー ネットワークの位置サービスを利用しています。これらの位置サービスは常に利用可能であり、通常は企業ワイヤレス ネットワークよりもはるかに正確に位置を特定できるため、緊急コールを発信し、デバイスおよびユーザの位置を特定する場合には、モバイル ボイス ネットワークを利用することを推奨します。ダイレクト コネクト モバイル クライアント デバイスが緊急サービスおよび位置サービスにモバイル ボイス ネットワークのみを利用するよう、Unified CM は、ダイレクト コネクト クライアント デバイス設定ページの [Emergency Numbers] フィールドに設定された番号に対するすべてのコールを強制的にモバイル ボイス ネットワーク経由でルーティングします。

外部コール ルーティング

ダイレクト コネクト モバイル クライアント デバイスが社外にあり、企業接続が存在しない場合は、モバイル ボイス ネットワーク経由でのみコールの発信と受信を行うことができます。このようにモバイル ボイス ネットワーク経由で直接ダイヤルされるコールは、会社に固定されていないので、Unified CM からは認識できません。そのため、これらのコールに対しては、会社の通話切替機能を呼び出したり、デスクトップフォンのピックアップを行ったりすることはできません。このような状況では、システム管理者が利用可能に設定している場合、ユーザは Unified Mobility エンタープライズ機能アクセスまたはモバイル ボイス アクセス 2 ステージ ダイヤリング機能を利用してコールを会社に固定できます。

Dial-via-office

Dial-via-office 機能を利用すると、ダイレクト コネクト モバイル クライアントには、携帯電話から Cisco Unified CM テレフォニー インフラストラクチャおよび会社のPSTN ゲートウェイを使用してコールを発信する機能が備わります。この機能は、ダイレクト コネクト モバイル クライアントと Unified CM との間の IP ネットワーク接続を介した SIP シグナリングによって実施されます。Unified CM システム管理者が Dial-via-office の使用を強制することも、管理者がユーザに対して、Dial-via-office を使用するか、モバイル ボイス ネットワーク経由でコールを直接ダイヤルするかを決定させることもできます。前述のとおり、Dial-via-office コールが強制されている場合でも、緊急番号へのコール(ダイレクト コネクト クライアント デバイス設定ページの [Emergency Numbers] フィールドで設定したとおり)は常に、モバイル ボイス ネットワークを介して直接ダイヤルされます。

Dial-via-office の操作および動作は、Cisco Unified Mobile Communicator ソリューションに関する説明とほぼ同じですが(「Dial-via-office」を参照)、Cisco Unified Mobility Advantage サーバと Cisco Unified Mobile Communication クライアントが関与しない点が唯一異なります。代わりに、Dial-via-office コール セットアップ用の通信は、ダイレクト コネクト モバイル クライアントと Unified CM の間で IP ネットワーク接続を介して直接実施されます。

Cisco Unified Mobile Communicator ソリューションと同様に、ダイレクト コネクト モバイル クライアントは Dial-via-Office Reverse Call Back(DVO-R: Dial-via-office リバース コールバック)または Dial-via-Office Forward(DVO-F; Dial-via-office 転送)操作を実行できます。

Dial-via-office コール フローおよび操作については、「Dial-via-office」を参照してください。

セッション再開

Cisco Unified CM 8.5 以降、ダイレクト コネクト モバイル クライアントのユーザは、コールのセットアップ時やネットワーク障害の発生時に Dial-via-office 転送コールのリダイヤルを行うことができます。Unified CM 8.5 以降のリリースでは、ユーザが最後にダイヤルした相手の電話番号が、Redial Await Timer サービス パラメータで指定した期間キャッシュされます。デフォルトでは、相手の電話番号がキャッシュされるのは 3 分間です。コールのセットアップ時やネットワーク障害が発生した場合などに、リダイヤル ソフトキーを押すかモバイル電話機のコール履歴リストを選択すると、Redial Await Time で期限切れになるまでは、最後にダイヤルした電話番号に Dial-via-office 転送機能を使用して自動的に再接続します。


) Unified CM 8.5 以降のリリースに搭載されたセッション再開機能または Dial-via-office 転送リダイヤル機能は、Dial-via-office 転送機能に対応する Cisco Unified Mobile Communicator 7.x クライアントおよび Cisco Unified Mobility Advantage 7.1(3) の新規および既存の展開で使用することもできます。この機能を使用するために、Unified Mobile Communicator や Unified Mobility Advantage の設定を変更する必要はありません。


モバイル トール バイパスの最適化

Dial-via-office コールの最低料金のルーティングを実現するため、Cisco Unified CM 8.5 より、管理者は、Dial-via-office 操作に使用できるように複数のエンタープライズ機能アクセス番号をシステムに設定できるようになりました。また、これらの番号は、新しいモビリティ プロファイル構成要素を使用してユーザに割り当てることができます。複数のエンタープライズ機能アクセス番号を使用できることにより、Dial-via-office 転送コールのローカル アクセス番号および Dial-via-office リバース コールのローカル側で有効な発信者 ID に対応できます。Dial-via-office 転送アクセス番号および Dial-via-office リバース発信者 ID は、地理的に適したモビリティ プロファイルの割り当てに従ったユーザの地理的な位置に基づいています。

モバイル トール バイパス最適化機能では、まず、複数のエンタープライズ機能アクセス番号を設定します。この番号はそれぞれ特定の地理的な位置に対応しています。グローバルに展開されているシステムでは、管理者は世界中の位置に対し、ユーザ数とオフィスの場所に基づいてローカル アクセス番号または DID を付与します。たとえば、ローカル番号を米国の都市の San Jose、New York、Miami、および英国の London、ドイツの Berlin、日本の Tokyo に設定できます。

次に、これらの複数のアクセス番号を、モビリティ プロファイルの設定に基づいてユーザに割り当てます。モビリティ プロファイルは、それぞれの地理的な位置で作成され、その位置のユーザに割り当てられます。たとえば、モビリティ プロファイルは、San Jose、New York、Miami、London、Berlin、Tokyo のユーザに設定されます。それぞれのプロファイルにはローカル側で有効な、その地理的な位置に特定したアクセス番号または DID が含まれています。この方法では、それぞれの位置のユーザは Dial-via-office 転送サービスに、長距離用番号や国際番号ではなく市内番号を使用してアクセスできます。それぞれの地理的な位置に市内番号を付与することで、一般に市内発信に適用される請求料率の方が安いため、コスト削減になります。

それぞれのモビリティ プロファイルは、ダイヤル プランおよび Dial-via-office によって最大 3 つまで設定されます。各プロファイルの Dial-via-office 転送の箇所で、管理者はエンタープライズ機能アクセス番号およびサービス アクセス番号を設定できます。短縮形式で設定した場合は、サービス アクセス番号はエンタープライズ機能アクセス番号の E.164 形式で提供され、サービス アクセス番号およびエンタープライズ機能アクセス番号がペアで使用されます。エンタープライズ機能アクセス番号が完全な E.164 形式で設定されている場合、サービス アクセス番号を設定する必要はありません。これらの番号のいずれかまたは両方が、システムによりダイレクト コネクト モバイル クライアントに転送された番号として、次に Dial-via-office 転送コールを完了するためのシステムへのコールにクライアントが使用する番号として、Dial-via-office 転送動作で使用されます。モビリティ プロファイルで設定できる他の番号は、それぞれのプロファイルの Dial-via-office リバース コールバック部分の、コールバック発信者 ID です。この番号は、Dial-via-office リバース コールバック コールでPSTN にあるダイレクト コネクト モバイル クライアント デバイスへの発信コールを行うときに Unified CM システムが使用する発信者 ID として指定します。

モビリティ プロファイルには [Mobile Client Calling Option] フィールドも含まれており、システム管理者はこのフィールドを使用して、Dial-via-office コールが発信されたときに Dial-via-Office リバースを使用するか、Dial-via-Office 転送を使用するかを指定できます。これにより、モバイル クライアントが使用する Dial-via-office コール方向の管理制御が可能になり、管理者は最も安価な方法で Dial-via-office コールが発信されるようにすることができます。

モビリティ プロファイルは、ユーザが通常クライアントを使用する位置に基づいてユーザに割り当てる必要があります。ユーザが地理的な位置を移動した場合、管理者は新しい位置に基づいて、手動でユーザに別のプロファイルを割り当てる必要があります。システムでは、モビリティ プロフィルは、ユーザの位置に基づいて動的に更新されません。

モビリティ プロファイルは、モビリティ ID および Dial-via-office 機能を利用できるように設定されたモバイル デバイスだけに割り当てることができます。Cisco Mobile 8.5 for Nokia などのダイレクト コネクト モバイル クライアントおよび旧リリースの Cisco Unified Mobile Communicator クライアントは、モビリティ ID および Dial-via-office 機能が設定されたデバイスです。モビリティ プロファイルは、通常の Unified Mobility リモート接続先に設定できません。


) Unified CM 8.5 以降のリリースで提供されているモバイル トール バイパス最適化機能は、Cisco Unified Mobile Communicator 7.x クライアントおよび Cisco Unified Mobility Advantage 7.1(3) の新規および既存の展開で使用できます。この機能を使用するために、Unified Mobile Communicator や Unified Mobility Advantage の設定を変更する必要はありません。Unified Mobility Advantage サーバでは、Unified CM 8.5 以降のリリースで転送されたアクセス番号が自動的に使用されます。ただし、管理者が Dial-via-office リバースまたは Dial-via-office 転送を指定できる [Mobile Client Calling Option] フィールドは、Cisco Unified Mobile Communicator デバイスの Dial-via-office コール フローに影響を与えません。Cisco Unified Mobile Communicator クライアントの Dial-via-office の方向は、クライアント自身だけで制御されます。


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

Dial-via-office および VoIP 呼処理サービスまたは呼制御サービスに加えて、ダイレクト コネクト モバイル クライアントでは、この項に説明する機能およびサービスを提供できます。

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

Cisco Mobile 8.5 for Nokia および Cisco Jabber IM ダイレクト コネクト モバイル クライアントは、Extensible Messaging and Presence Protocol(XMPP)に対応しており、自社管理の Cisco Unified Presence サーバまたは構外の Cisco WebEx Connect クラウド サービスへの統合を通じた企業向けの IM およびプレゼンス サービスを利用できます。どちらの場合も、これらのダイレクト コネクト モバイル クライアントの IM およびプレゼンス機能により、次の操作を実行できます。

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

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

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

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

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

IM またはテキスト メッセージを音声コールにエスカレーションする。

Cisco Jabber IM クライアントは、Apple iOS iPhone、iPod Touch、および iPad デバイス(Apple iOS バージョン 4.2 以降)で利用できます。Cisco Jabber IM クライアントは、BlackBerry OS 4.6 以降のバージョンが実行されている広範囲の BlackBerry デバイスでも利用できます。

Cisco Jabber IM を使用すると、VoIP コールのために Cisco Jabber モバイル クライアント(インストールされている場合)を相互起動できます。Cisco Jabber モバイル クライアントは、連絡先ベースの企業向けの IM およびチャットのために Cisco Jabber IM(インストールされている場合)を相互起動できます。

Cisco Jabber IM クライアントの詳細については、 http://www.cisco.com/en/US/products/ps11763/products_data_sheets_list.html で入手可能な『 Cisco Jabber IM for BlackBerry 』データ シートおよび http://www.cisco.com/en/US/products/ps11596/products_data_sheets_list.html で入手可能な『 Cisco Jabber IM for iPhone 』データ シートを参照してください。

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

ダイレクト コネクト モバイル クライアントは、モバイル データ ネットワークまたは WLAN 経由で会社に接続している場合、LDAP を使用して社内ディレクトリにアクセスし、ディレクトリ ルックアップを行うことができます。この機能はダイレクト コネクト モバイル クライアントに必須の機能ではありませんが、携帯電話から社内ディレクトリ情報にアクセスできると、ダイレクト コネクト クライアント ユーザの生産性が向上します。

企業の MWI およびメッセージ数インジケータ

ダイレクト コネクト モバイル クライアントは、企業ボイスメール サービスにアクセスすることもできます。ダイレクト コネクト クライアントは、企業のメッセージ待機インジケータ(MWI)とメッセージ数を受信でき、企業ボイスメール ボックスに視覚的にアクセスできます。MWI とメッセージ数インジケータを受信したりビジュアル ボイスメールにアクセスするには、ダイレクト コネクト モバイル クライアントが企業ネットワークに(モバイル データ ネットワークまたは WLAN 経由で)接続している必要があります。

通常の会社の電話機と同様に、ダイレクト コネクト モバイル クライアントを使用して、ボイスメール システム番号にダイヤルし、必要な資格情報を提供した後で適切なボイスメール ボックスに移動することにより、企業ボイスメール メッセージを取得できます。

モバイル コネクトのオン/オフ

Unified Mobility に統合し、モバイル コネクトを有効にしている場合、ダイレクト コネクト モバイル クライアントではモバイル コネクトのステータスを表示し、クライアント設定インターフェイスを介してモバイル コネクトのオフとオフを切り替えることができます。このため、ユーザは、モバイル データ ネットワーク経由でリモートから会社に接続している場合でも、ダイレクト コネクト モバイル クライアント デバイスの携帯の番号に対してモバイル コネクトまたはシングル ナンバー リーチ機能を有効にしたり、無効にしたりすることができます。

ダイレクト コネクト モバイル クライアント:Cisco Mobile 8.5 for Nokia


) Cisco Mobile 8.5 for Nokia クライアントは、2012 年 7 月 10 日で販売を終了しました。Nokia モバイル デバイスの代替モバイル クライアントはありません。詳細については、次の URL にある販売終了(EoS)およびサポート終了日(EoL)のお知らせを参照してください。http://www.cisco.com/en/US/prod/collateral/voicesw/ps6789/ps7290/ps10589/end_of_life_notice_c51-696647.html


Cisco Mobile 8.5 for Nokia は、Nokia モバイル スマート フォン対応のダイレクト コネクト モバイル クライアントです。Nokia デバイスにインストールすると、クライアントはローカルの企業 WLAN ネットワークに関連付けることも、モバイル データ ネットワークを介して会社にリモートに関連付けることもできます。クライアントは Unified CM に登録され、通信できるようになります。

Cisco Mobile 8.5 ダイレクト コネクト モバイル クライアントを登録し、Dial-via-office サービスを提供するには、Unified CM で適切な Nokia S60 デバイス タイプがサポートされている必要があります。このデバイス タイプは、必要な Cisco Options Package(COP)ファイルを Unified CM にロードすると使用可能になります。COP ファイル(cmterm-nokia_s60_8.5.2v06-sccp.cop.sgn)は、次の場所で見つけることができます。

http://www.cisco.com/cisco/software/release.html?mdfid=281001428&release=8.5(2)&flowid=&softwareid=282074304&os=null

COP ファイルがインストールされ、ダイレクト コネクト クライアント デバイスが Unified CM 内に設定された後は、Cisco Mobile 8.5 for Nokia クライアントを Nokia デバイスにロードする必要があります。この作業は、USB、Bluetooth、または赤外線ポートを備えたコンピュータを使用して行うことができます。Cisco Mobile 8.5 Symbian Installation System(SIS)ファイルを Nokia デバイスにロードした後は、少なくとも、ローカルの企業 WLAN にアクセスして企業の WLAN インフラストラクチャおよびセキュリティ ポリシーに基づいて接続するようにデバイスを設定する必要があります。VPN を使用したリモートの企業ネットワーク接続を有効にするには、その他の設定も必要です。

Cisco Mobile 8.5 Nokia デバイスを Unified Mobility と統合して、ユーザがモバイル コネクトなどの機能を利用できるようにするには、Nokia の携帯電話番号をモビリティ ID として設定し、それを Unified CM 内で Nokia S60 デバイスに関連付けます。

Cisco Mobile 8.5 クライアントは、Symbian Series 60 Third Edition Feature Pack 1 (3.1) または Feature Pack 2 (3.2) ファームウェアを実行する Nokia ハンドセットでサポートされます。たとえば、Nokia E55、E66、E71、E72、および E75 などのデバイスが含まれます。

Nokia 携帯電話の WLAN インターフェイスは通常、802.11b および 802.11g ネットワーク接続をサポートしています。

Cisco Mobile 8.5 クライアントは、Dial-via-office サービスを提供するだけでなく、LDAP 準拠のディレクトリを指すように設定されている場合はディレクトリ ルックアップ サービスも提供します。また、Cisco Unified Presence または Cisco WebEx Connect に統合されている場合は XMPP ベースのプレゼンスおよび IM を提供します。

システム要件とサポートされているデバイスの詳細については、次の Web サイトにある Cisco Mobile 8.5 for Nokia のリリース ノートを参照してください。

http://www.cisco.com/en/US/docs/voice_ip_comm/cumc/cisco_mobile/nokia/8_x/Release_Notes/Cisco_Mobile_Nokia_8_x_RN.html

Cisco Mobile 8.5 for Nokia のインストールと設定の詳細については、次の Web サイトで入手可能な管理ガイドを参照してください。

http://www.cisco.com/en/US/docs/voice_ip_comm/cumc/cisco_mobile/nokia/8_x/admin/Cisco_Mobile_for_Nokia_8.5_Admin_Guide.html

Cisco Mobile 8.5 と Nokia Call Connect の共存

デュアルモードの Voice over IP(VoIP)機能をサポートするには、デバイスに Cisco Mobile 8.5 と Nokia Call Connect デュアルモード クライアントを共存インストールする必要があります。Nokia Call Connect クライアントは、VoIP コールをサポートします。両方のクライアントが、Unified CM 内の Nokia デバイスに対する Nokia S60 デバイス設定に関連付けられます。

共存で動作する場合、Nokia Call Connect デュアルモード クライアントは「デュアルモード クライアント:Nokia Call Connect」で説明したとおりに動作します。Cisco Mobile 8.5 と共存する Nokia Call Connect デュアルモード クライアントの操作と展開に関しては、操作的および機能的な動作においてスタンドアロンの Nokia Call Connect デュアルモード クライアントのインストールと変わりません。ハンドオフ操作と設定に関する同一の設計上および展開上の要件を考慮する必要があります。 同様に、「ワイヤレス デバイスのローミング」に示されている設計上の推奨事項と要件はすべて、Cisco Mobile 8.5 と共存して動作する Nokia Call Connect に適用されます。

Cisco Mobile 8.5 および Nokia Call Connect クライアントを共存展開する際、Unified CM 管理者は Dial-via-office を強制しないでください。代わりに、Nokia S60 デバイス設定ページの [Dial Policy] パラメータを [Let User Choose] として設定してください。これにより、ユーザは、Dial-via-office を使用するときに各自の意思を最大限反映できるので、ユーザが企業に接続されていないときや、IP ネットワーク経由の音声品質が低いときにだけ、この機能が使用されるようにすることができます。

管理者が Cisco Mobile 8.5 に対して Dial-via-office を強制する場合には、ユーザは Cisco Mobile 8.5 クライアント内で [Allow dial via office for] を [Calls from this app] に設定して、クライアント アプリケーション内から直接発信されたコールだけが Dial-via-office の呼び出しを試みるようにする必要があります。クライアントをこのように設定することによって、ユーザは、予期せず Dial-via-office が実行されないようにできます。Cisco Mobile 8.5 クライアントがフォアグラウンドで実行されていない場合、Dial-via-office は呼び出されません。

これらの 2 つのクライアントが共存して動作するときは、次の点を考慮してください。

WLAN またはモバイル データ ネットワークの接続信号の強度が強く、信頼できる場合には、Nokia Call Connect デュアルモード クライアントを VoIP コールの発信および受信に使用します。

音声品質が低いか、IP 接続が信頼できない場合には、Cisco Mobile 8.5 ダイレクト コネクト クライアントを Dial-via-office コールに使用します。

いずれの場合も、ユーザは、ダイレクト コネクト モバイル クライアント デバイスが社外にあるか、IP ネットワーク接続上の音声品質が低い場合に限り、Dial-via-office を使用するようにします。

Cisco Mobile 8.5 と Cisco Unified Mobility との間の相互作用

Nokia 対応の Cisco Mobile 8.5 ダイレクト コネクト モバイル クライアントを Cisco Unified Mobility と統合することで、Cisco モバイル コネクト、通話切替 DTMF 機能(モバイル データ接続または WLAN 接続が使用できない場合)、シングル企業ボイスメール ボックス、およびデスクトップフォンのピックアップを利用できます。

Unified Mobility と統合するには、Unified CM 内で、Nokia ダイレクト コネクト クライアント デバイスの携帯電話番号を Nokia S60 デバイスに関連付けられたモビリティ ID として設定する必要があります。システム内で携帯の番号をモビリティ ID として設定した後は、モバイル コネクトを利用して、ユーザの会社の番号への着信コールがモバイル ボイス ネットワーク経由で Nokia ダイレクト コネクト クライアント デバイスに転送されるようにすることができます。モバイル コネクト機能は、Cisco Mobile 8.5 クライアント内でリモートから有効または無効にすることもできます。Nokia デバイスで Nokia Call Connect デュアルモード クライアントも実行している場合には、デバイスが企業に接続され、Unified CM に登録されていると、会社の番号への着信コールはデバイスのモバイル ボイス ネットワーク インターフェイスには転送されません。Nokia デバイスが企業に接続されている場合、デバイスは IP ネットワークを介して着信コールを受信します。これにより、会社のPSTN ゲートウェイ リソースの必要以上の消費を回避できます。

社外では、パブリックまたはプライベートの Wi-Fi ホット スポットあるいはモバイル データ ネットワークに Nokia デバイスから到達でき、企業へのセキュア接続が利用できる場合、Cisco Mobile 8.5 クライアントは、企業接続の品質に応じて VoIP または Dial-via-office を発信コールに使用できます。ただし、IP ネットワーク接続を使用できない場合でも、ユーザは、Unified Mobility 2 ステージ ダイヤリング機能のモバイル ボイス アクセスまたはエンタープライズ機能アクセスを使用してビジネス コールを発信できます。また、会社の任意の固定コール(Dial-via-office、2 ステージ ダイヤリング、またはダイレクト ダイヤリング対象の会社の番号およびモバイル コネクト)については、ユーザは Cisco Mobile 8.5 クライアントのデスクへのコールの移動機能を使用して、アクティブ コールをデスクトップフォンに移動できます。企業接続を使用できない場合には、DTMF 機能アクセス コードによって通話切替機能を呼び出すこともできます。

Nokia ダイレクト コネクト モバイル クライアント デバイスに対してモビリティ ID を設定することに加えて、リモート接続先として追加の携帯電話番号またはオフシステム電話番号を設定して、これらの番号を Unified CM 内の Nokia S60 デバイスに関連付けることができます。モビリティ ID および追加のリモート接続先を Nokia デバイスに関連付ける場合は、リモート接続先プロファイルを設定する必要はありません。既存の Nokia 携帯電話ユーザに対して Unified Mobility がすでに有効になっており、Cisco Mobile 8.5 に移行している場合、既存のリモート接続先プロファイルを削除し、設定されているリモート接続先を削除して Nokia S60 デバイスに直接追加しなおす必要があります。リモート接続先およびモビリティ ID が Unified CM システム内で固有でなければならないため、この作業が必要になります。

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

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

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

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

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

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

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

ダイレクト コネクト モバイル クライアントのキャパシティ プランニング

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

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

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

ダイレクト コネクト モバイル クライアントを展開する場合、Unified CM システムおよびPSTN ゲートウェイの全体的な呼処理容量も考慮する必要があります。クライアント デバイスの実際の設定および登録を処理する以外に、システムでは、これらのデバイスとユーザによって増加する BHCA の影響を吸収するために十分な容量も必要です。同様に、ダイレクト コネクト クライアントを処理するのに十分なPSTN ゲートウェイの容量を確保することも重要です。

上記の考慮事項は、ダイレクト コネクト クライアント デバイスに固有なものではありません。これらの考慮事項は、デバイスやユーザが Unified CM に追加されることによって Unified Communications システム全体の負荷が高まるすべての状況に当てはまります。

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

ダイレクト コネクト モバイル クライアントの設計上の考慮事項

ダイレクト コネクト モバイル クライアントを展開するときは、次の設計上の推奨事項に従ってください。

ダイレクト コネクト モバイル クライアントのユーザが緊急コールを発信し、デバイスおよびユーザの位置を特定する場合には、モバイル ボイス ネットワークを利用することを推奨します。これは、通常モバイル プロバイダー ネットワークでは、企業の WLAN ネットワークよりもはるかに信頼性のある位置情報が提供されるためです。これらのクライアント デバイスから緊急コールを発信したり位置サービスを利用したりする場合にモバイル ボイス ネットワークだけが利用されるようにするには、911、999、および 112 などの緊急番号がダイレクト コネクト クライアント デバイス設定ページの [Emergency Numbers] フィールドに設定されており、これらの番号に対するすべてのコールがモバイル ボイス ネットワーク経由で送信されることを確認します。

地理的な複数の位置にわたってユーザのダイレクト コネクト モバイル クライアントを展開する際に、位置に固有のシステム アクセス番号を Dial-via-office に割り当てるために、モバイル トール バイパスの最適化機能を使用することを検討してください。Dial-via-office の方向がコール コストに影響する場合には、特定の Dial-via-office 方向(フォワードまたはリバース)を強制するために、モビリティ プロファイルの [Mobile Client Calling Option] フィールドを使用することを検討してください。

Cisco Mobile 8.5 ダイレクト コネクト クライアントと Nokia Call Connect デュアルモードの両方が同じハンドセットに展開されている場合は、次のことが推奨されます。

「ワイヤレス デバイスのローミング」で説明する Voice over WLAN に関するすべての推奨事項と要件に従ってください。

「デュアルモードの電話機とクライアント」で説明する Nokia Call Connect の設定および展開に関するすべての推奨事項と要件に従ってください。

デュアルモード機能が有効である場合、Unified CM 管理者は Dial-via-office を強制しないでください。代わりに、Nokia S60 デバイス設定ページの [Dial Policy] パラメータを [Let User Choose] として設定してください。

管理者が Cisco Mobile 8.5 に対して Dial-via-office を強制する場合、ユーザは Cisco Mobile 8.5 クライアント内で [Allow dial via office for] を [Calls from this app] に設定して、クライアント アプリケーション内から直接発信されたコールだけが Dial-via-office の呼び出しを試みるようにする必要があります。クライアントをこのように設定することによって、ユーザは、予期せず Dial-via-office が実行されないようにできます。Cisco Mobile 8.5 クライアントがフォアグラウンドで実行されていない場合、Dial-via-office は呼び出されません。

共存して動作する Cisco Mobile 8.5 と Nokia Call Connect クライアントでのコールの発信に関して、次の点を考慮してください。

WLAN またはモバイル データ ネットワークの接続信号の強度が強い場合には、Nokia Call Connect デュアルモード クライアントを Voice over IP(VoIP)コールの発信および受信に使用します。

音声品質が低いか、IP ネットワーク接続が使用できない場合、Cisco Mobile 8.5 ダイレクト コネクト クライアントを Dial-via-office コールに使用します。