Cisco Collaboration システム 10.x ソリューション リファレンス ネットワーク デザイン(SRND)
Cisco Collaboration Systems の移行
Cisco Collaboration Systems の移行
発行日;2014/04/25 | 英語版ドキュメント(2013/11/23 版) | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 27MB) | フィードバック

目次

Cisco Collaboration Systems の移行

この章の新規情報

ソリューションの共存または移行

移行の前提条件

Cisco Collaboration Systems の移行

段階的な移行

並行カットオーバー

IP テレフォニーの移行例

IP テレフォニーの移行の概要

中央集中型の導入

どちらの Cisco Collaboration サービスを最初に移行するか

Cisco Prime License Manager

ライセンス移行の種類

9.1 x 以前のライセンス前を UnifiedCM 10.x に移行する際の考慮事項

Cisco Prime Collaboration Deployment を使用した物理サーバから仮想マシンへの移行

Cisco Prime Collaboration Deployment 移行の種類

Cisco Prime Collaboration Deployment 移行の前提条件

単純な移行

ネットワークによる移行

CiscoVCS から UnifiedCM へのビデオ エンドポイントの移行

H.323 から SIP への移行

H.323 から SIP へのトランクの移行

H.323 から SIP へのゲートウェイの移行

SCCP から SIP へのエンドポイントの移行

SIP URI ダイヤルおよび電話番号

仮想 UnifiedCM による USB サポート

Cisco Collaboration Systems の移行

この章では、管理者が、既存または以前の Unified Communications ソリューション バージョン(6.1.5、7.1.5、8. x 、および 9. x )を最新の Cisco Collaboration システム リリース 10. x に移行する際の管理上の推奨事項について説明します。


) Cisco 7800 Series Media Convergence Servers(MCS)は、Cisco Collaboration システム リリース 10.0 以降のリリースではサポートされなくなりました。


Open Virtualization Archive(OVA)テンプレート、VMware、ESXi Hypervisor、および Unified Communications アプリケーションのハードウェアおよびソフトウェアの最小要件については、次のマニュアルを参照してください。

Unified Communications VMware 要件

http://docwiki.cisco.com/wiki/Unified_Communications_VMware_Requirements

VMware 互換性ガイド

http://www.vmware.com/resources/compatibility

UCSM によって管理されるサーバのハードウェアおよびソフトウェア相互運用性

http://www.cisco.com/en/US/products/ps10477/prod_technical_reference_list.html

Cisco Collaboration システム リリース 10.0 以降のリリースでは、ほとんどの Cisco Collaboration アプリケーションには仮想化の配置が必要であり、ハイパーバイザなしではサーバに直接インストールされない可能性があります。VMware vSphere ESXi は現在サポートされる唯一のハイパーバイザであり、Cisco Collaboration Systems 内のすべての仮想化展開では必須です。Cisco Collaboration システム リリース 10.x は VMware vSphere ESX または ESXi 以外のどの VMware のサーバ仮想化製品もサポートしていません。

この章では、次のような種類の移行について説明します。

Cisco 7800 Series MCS サーバから Cisco Unified Computing System(UCS)サーバ上の Cisco Unified Communications Manager(Unified CM)

Cisco Video Communication Server(VCS)のエンド ポイント登録から Unified CM 登録

H.323 ゲートウェイおよびトランクから SIP ゲートウェイおよびトランク

SCCP エンドポイントから SIP エンドポイント

番号ダイヤルから URI ダイヤル

Cisco Prime License Manager を使用したデバイス ベースのライセンスからユーザ ベースのライセンスへの Pre-9.0.1 ライセンスの移行

移行が正常に行われるように、次のリソースを使用してすべての要件が満たされているかどうかを移行前に検証することを推奨します。

Cisco Unified Communications Compatibility Tool

http://tools.Cisco.com/ITDIT/vtgsca/jsp/index.jsp

『Cisco Unified Communications Manager Software Compatibility Matrix』

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

この検証は、サポートされるアップグレード パスを使用して移行が正常に行われるようにします。たとえば、以前のアプリケーションのソフトウェア バージョンによっては、正常に移行するために複数のアップグレードが必要になることがあります。同様に、ソフトウェアの互換性とともに、サーバ ハードウェアが多段階ハードウェアおよびソフトウェアのアップグレードの組み合わせが必要になる場合があります。

Cisco Collaboration System 製品の詳細については、次の Web サイトで入手可能なマニュアルを参照してください。

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

サポートされているすべてのシステム ハードウェアの一覧については、次の URL で入手可能な Unified Computing 製品のマニュアルを参照してください。

http://www.cisco.com/en/US/products/ps10265/products.html

この章の新規情報


) この章は、現在のリリースに向けて大幅に改訂されました。既存のシステムを新しいバージョンまたはプラットフォームに移行する前に、この章全体を読むことを推奨します。


ソリューションの共存または移行

これは、決めておくべき重要な選択です。共存とは、通常、2 つ以上のシステムが長期間(6 ヵ月を超える任意の期間)にわたって共存することを意味します。このシナリオでは、PBX、ボイスメール、またはその他のいずれの機能であっても、機能の透過性が重要な考慮事項になります。必要な機能の透過性レベルを実現するために、既存のシステムへの投資やアップグレードが必要となる場合があります。移行は、通常、短期間(6 ヵ月未満の任意の期間)で実施します。このシナリオでは、ユーザは、移行が「短い」期間で完了することを認識しているため、既存の機能のサブセットをより許容しやすくなります。この「短い」期間については、多くの場合、既存のシステム機能で十分であるため、一般的に、移行は共存よりもコストが少なくなります。

移行の前提条件

すべての管理者は、任意のコラボレーション移行手順を実装する前に、IP インフラストラクチャが「コラボレーション対応」(冗長性、ハイ アベイラビリティ、電力消費、Quality of Service(QoS)、インライン パワー、イーサネット ポートなど)となっていることを確認する必要があります 詳細については、「ネットワーク インフラストラクチャ」の章を参照してください。

Cisco Unified Computing System(UCS)に Cisco Unified Communications をはじめて導入する場合、次の Web サイトから入手可能な『 Cisco UCS Site Preparation Guide 』に記載されているガイドラインに従ってください。

http://www.cisco.com/en/US/docs/unified_computing/ucs/hw/site-prep-guide/ucs_site_prep.html

ユーザのビジネス ニーズは、移行中に各機能が保持または変換されて、同等の動作が提供されるようにするための主要なシステム要件を特定するときに重要な役割を果たします。さまざまなデバイスとソフトウェアの機能とバージョンのリストを参照して、サポート内容を理解することができます。通常、すべての要件(FAX/モデム、環境制御システムなど)が適切に特定および考慮されるように、何らかのサイト サーベイまたはユーザ サーベイを実行する必要があります。

Cisco Collaboration Systems の移行

仮想化された Cisco Collaboration Systems を移行するには、主に段階的な移行と並行カットオーバーの 2 種類の方法があります。Cisco Prime Collaboration Deployment は、移行プロセスを管理し、簡略化するのに使用できます。

段階的な移行

この方法は、通常、配置する Cisco Unified Communications Manager(Unified CM)を中心とした、小規模な試用から開始します。カスタマーが Unified CM に慣れたら、新しい Unified CM リリースで管理者は移行手順を開始し、ユーザのグループを実稼働システムに一度に移動できます。

並行カットオーバー

この方法は、段階的アプローチと同様に開始しますが、カスタマーが試用の進行状況に納得した時点で、すべてのユーザを一度に新しい Cisco Collaboration System にカットオーバーする日時を選択します。

並行カットオーバーには、段階的な移行に比べて次の利点があります。

並行カットオーバーを採用した場合、予期しない事態が発生したとき、最小限の労力で、基本的に以前の状態のままのシステムに戻すことができる、バックアウト計画を使用できます。たとえば、PBX からの段階的な移行の場合、IP テレフォニー ゲートウェイからの着信 PSTN トランクを PBX に転送して戻すだけで、ユーザに対してサービスを復元できます。

並行カットオーバーを採用すると、システムがライブ トラフィックを伝送する前に、コラボレーション サービスの設定を確認できます。このシナリオでは、コラボレーション サービスのカットオーバー前に任意の期間実行できるため、すべてのユーザ情報(電話機、ゲートウェイ、ダイヤル プラン、メールボックスなど)が正しく設定されていることを確認できます。

並行カットオーバーを採用すると、ライブ トラフィックを伝送する前に、Unified Communications サービスの設定を確認できます。このシナリオでは、Unified Communications サービスのカットオーバー前に任意の期間実行できるため、すべてのユーザ情報(電話機、ゲートウェイ、ダイヤル プラン、メールボックスなど)を適切に設定できます。

加入者がカットオーバー前の都合のよいときにコラボレーション サービスを調べたり使用したりできるようにすることによって、ゆとりを持ってトレーニングを実行できます。

システム管理者は、「利害共同体」のために特別なプロビジョニングを行う必要はありません。段階的な移行では、コール ピックアップ グループ、ハント グループ、シェアド ラインなどの機能の完全性の維持を考慮する必要があります。これらのアソシエーションは、並行カットオーバーで完全なサービスに移行するときに、簡単に考慮することができます。

並行カットオーバーには、サポートするインフラストラクチャを含み、コラボレーション サービスのために最初の時点から十分な資金が必要になるという短所があります。これは、サービスを提供する前に、サービス全体を配置する必要があるためです。一方、段階的な移行では、必要となったときにシステムの個々のコンポーネントを購入できます。このアプローチでは、完全に配置する前に、小規模な試用システムから開始できます。いずれかの方法が正しいというわけではなく、それぞれのカスタマーの環境と優先事項に応じて、最適なオプションが決まります。

IP テレフォニーの移行例

次の例は、PBX システムから Cisco Unified Communications への段階的な移行と並行カットオーバーを示します。

例 28-1 IP テレフォニーの段階的な移行

このアプローチは、通常、主要な企業 PBX に接続された IP テレフォニーの小規模な試用を伴います。使用するシグナリング プロトコルの選択は、必要な機能および実装コストによって決まります。Cisco Unified Communications Manager(Unified CM)では、通常の PSTN タイプ PRI や QSIG PRI、および H.323 と SIP をサポートしています。これらのオプションのうち、QSIG PRI は、通常、任意の 2 つのシステム間に最高レベルの機能透過性を提供します。

PSTN タイプ PRI は、基本的なコール接続および自動番号識別(ANI)を提供します。このプロトコルで発信者名情報がサポートされる場合もあります。このレベルの接続は、すべての PBX で使用できるため、最もコストがかからないオプションと見なされます。つまり、PBX は、PRI を介してパブリック ネットワークに接続できる場合、Unified CM に接続できます。これは、Unified CM が接続の「ネットワーク」側として設定できるためです。

PSTN タイプ PRI または QSIG では、段階的な移行のプロセスが似ています。ユーザをグループ単位で PBX から Unified CM に移動しますが、一度にグループを 1 つずつ移動して、移行を完了します。

約 60 のビルに分散された 23,000 人ものユーザで構成されている Cisco San Jose キャンパスでは、この方法で IP テレフォニーへの移行が行われました。週末ごとに 1 つのビルという割合で、開始から完了までちょうど 1 年かかりました。選択されたビル内のすべてのユーザが特定され、金曜日の夜に、それらのユーザの内線番号が PBX から削除されました。同時に、PBX ルーティング テーブルへの追加が行われ、これらの内線番号にダイヤルしたすべての人が正しい PRI トランクを通じてルーティングされ、Unified CM に配信されるようにしました。週末の間に、ユーザの新しい内線番号が Unified CM に作成され、新しい IP Phone が該当するオフィス ロケーションに届けられ、月曜日の朝には使用できる準備が整っていました。このプロセスは、すべてのユーザが移行されるまで、各ビルに対して繰り返されました。

例 28-2 IP テレフォニーの並行カットオーバー

このアプローチでは、すべての IP Phone およびゲートウェイが完全に設定および配置され、ユーザのデスク上には IP Phone と PBX 電話機の両方が同時に置かれます。このアプローチでは、システムをテストする機会だけでなく、新しい IP Phone にユーザが慣れる機会を提供します。発信専用のトランクも IP テレフォニー システムに接続できるため、新しい IP Phone を使用して外部コールおよび内部コールを発信する機会がユーザに提供されます。

IP テレフォニー システムが完全に配置された時点で、着信 PSTN トランクを PBX から IP テレフォニー ゲートウェイに移動して新しいシステムを完全なサービスに移行する日時を選択できます。IP テレフォニー システムの運用に確信を持てるまで、PBX をそのまま残しておき、確信できた時点で PBX の使用を停止することもできます。

Cisco San Jose キャンパスのボイスメール サービスは、23,000 人ものユーザにサービスを提供する 4 つの Octel 350 システムによって行われていました。Cisco Unity サーバがインストールされ、ユーザのメールボックスが設定されました。ユーザは、新しいアクセス番号をダイヤルして自分の Cisco Unity メールボックスにアクセスできます。これにより、自分の名前とグリーティングを録音し、また新しいテレフォニー ユーザ インターフェイス(TUI)に慣れることができます。約 2 週間後、Unified CM 一括管理ツール(BAT)の更新が金曜日の夜に実行され、話中転送番号と無応答転送番号(CFB/CFNA)、および Unity システムへのすべてのユーザの Messages ボタンの宛先番号が変更されました。月曜日の朝に仕事に戻ったときには、Cisco Unity によるサービスがユーザに提供されていました。Octel 350 システムは 1 か月間そのまま残されたため、Octel 350 システムの使用停止までに、ユーザは Octel 350 システムに残っていたすべてのメッセージに応答できました。

IP テレフォニーの移行の概要

IP テレフォニーの移行の 2 つの方法はいずれも適切に機能し、いずれか一方が正しいということはありませんが、ほとんどの場合、並行カットオーバーの方法が、より適切に機能します。シスコは、Unified CM システムと PBX システム間の相互運用性テスト専用の実験施設を持っています。これには、現在のシステム アーキテクチャやアプリケーションが含まれていることも、含まれていないこともあります。これらのテスト システム、相互運用性、エンドユーザの機能はドキュメント化されており、インストールや移行プロセスに大いに役立てることができます。このテストの結果は、次の Web サイトに公開されているアプリケーション ノートとして入手できます。

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

アプリケーション ノートは頻繁に更新され、この Web サイトには新しいドキュメントが絶えず追加されています。この Web サイトを頻繁に確認して、最新情報を入手してください。

Cisco Prime Collaboration Deployment 10. x には Cisco Prime Collaboration の以前のバージョンに対して多くの改良点を搭載しており、Cisco Collaboration System 10 x へ移行するプライマリ ツールです。

中央集中型の導入

企業が Cisco Collaboration System の集中型配置を選択した場合は、次の 2 つのオプションがあります。

外側から開始し、中央サイトに向かって内側に進める(つまり、最も小さいサイトから最も大きいサイトへ)。

中央サイトから開始し、エッジに向かって外側に進める。

ほとんどのカスタマーは、次の利点があるため、最初のオプションを選択します。

すべての Cisco Collaboration サービスを完全に配置したあと、サービスをリモート ロケーションに配置する前に小規模な試用を実行できる。

Cisco Collaboration サービスの配置は、一度に 1 つずつのロケーションで実行でき、以降のロケーションは適宜移行できる。

このオプションは、Cisco Collaboration のコア サービスが中央サイトに配置されたあとには、実装コストが最も低くなる。

IT スタッフは、中央サイトに移行する前に、小規模サイトの移行時に貴重な経験を積むことができる。

リモート サイトは、並行カットオーバー アプローチで移行する必要がありますが、中央サイトは、並行または段階的のいずれかのアプローチを使用して移行できます。

どちらの Cisco Collaboration サービスを最初に移行するか

この選択は、カスタマーの個別のビジネス ニーズに大きく依存し、Cisco Collaboration ソリューションによって、個々のサービスのほとんどを他のサービスとは独立して配置できます。たとえば、IP テレフォニー、音声メッセージング、コンタクト センター、コラボレーティブ会議は、すべて互いに独立して配置できます。

この機能により、大幅な柔軟性がカスタマーにもたらされます。あるカスタマーが、ボイスメール システムのサポートが終了したことによって、顧客満足度の低下につながるさまざまな問題を抱えているとします。多くの場合、Cisco Unity Connection は現在の PBX とともに配置および統合できるため、この問題を解決できます。新しいボイスメール システムが適切に運用されるようになったあと、次のコラボレーション サービス、つまり IP テレフォニーに取り組むことができます。

Cisco Prime License Manager

Cisco Prime License Manager(Prime LM、旧称 Cisco Enterprise License Manager)は、製品の Cisco Prime 管理スイートと連携します。Cisco Prime LM は新しい特長や機能を提供し、Cisco Emergency Responder のサポートを追加します。Cisco Prime LM はまた、Cisco Unified CM バージョン 9.1. x および 10. x などの製品の複数のクラスタと複数のバージョンもサポートします。

Cisco Enterprise License Manager(ELM) 9.1 は Cisco Option Package(COP)ファイルからのアップデートで Unified CM バージョン 9.1 および 10.0 をサポートしますが、シスコでは Cisco Prime LM にアップグレードすることを推奨しています。

Cisco Prime LM は現在次の Cisco Collaboration アプリケーションをサポートしています。

Cisco Unified CM

Cisco Unified CM Session Management Edition(SME)

Cisco IM and Presence サービス

Cisco Unity Connection

Cisco Business Edition 6000

Cisco Emergency Responder

Cisco WebEx Meetings Server

Cisco Prime Collaboration Deployment でサポートされていない他のアプリケーションの移行については、次の Web サイトで入手可能なマニュアルに記載された、特定の製品の移行ガイドラインに従ってください。

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

ライセンス移行の種類

手動による移行

Cisco Unified CM および Unity Connection で使用される。Cisco Unified Workspace License(CUWL)のみ

手動でのライセンス取得による移行

必要なシスコ サポートのない移行。Customer Portal 経由でライセンス取得

Cisco Unified CM および Unity Connection のバージョン 9.1(1) によって使用される

Cisco Unity Connection 9.1(2)(CUWL 以外)によって使用される

Cisco Unity Connection(CUWL 以外)バージョン 10. x および Emergency Responder で使用される電子的なライセンス取得による移行

必要なシスコ サポートのない移行。Cisco Prime LM を介した電子的なライセンス取得

9.1 x 以前のライセンス前を Unified CM 10. x に移行する際の考慮事項

すべての Product Activation Key(PAK)を登録し、インストールします。

購入し、インストールされているライセンスすべてをインベントリします。

License Count Utility を使用して、licensing@cisco.com に送信します。

必要な数量および種類ごとにアップグレードを購入します。

拡張予定の場合は、拡張する数量分の新しいユーザを購入します。

Cisco Prime License Manager(Prime LM)をインストールおよび設定し、製品のインベントリを追加します。

Prime LM Migration Utility を実行します。

Migration Utility 出力を licensing@cisco.com に送信します。

Cisco Licensing は 10. x ライセンスを発行します。

PAK は、Cisco Global Licensing Operations(GLO)チーム(licensing@cisco.com)に電子メールで送信するすべての移行ライセンス要求に必要です。要求が満たされると、GLO は要求者に電子メール経由でライセンス ファイルを提供し、移行を継続できます。Cisco Enterprise License Manager とともに Cisco Unified Communications 9.1. x リリースを使用している既存の顧客は、Cisco Prime LM のすべてのメリットを実現するためにリリース 10. x に直接アップグレードできます。新しいライセンスを取得するには、次の Web サイトの Cisco Product License Registration ポータルに進みます。

http://www.Cisco.com/go/license

Cisco Prime Collaboration Deployment を使用した物理サーバから仮想マシンへの移行

Cisco Prime Collaboration Deployment は、管理者がレガシー Cisco Unified CM および Cisco IM and Presence サービスから Cisco Collaboration Systems リリース 10. x の仮想化環境への移行を実行できるようにする管理アプリケーションです。Cisco Prime Collaboration Deployment はクラスタを移行してデータ移行を処理し、実稼働(ソース)クラスタにほとんど影響を与えないで新しいすべての VMware ESXi ホストに 10. x リリースをインストールできます。Cisco Prime Collaboration Deployment では直接移行を実行しますが、以前の移行方法では、バックアップからのリストアに続いて最初のアップグレードに依存する「サーバ リカバリ」Disaster Recovery System でのより多くの手順が含まれます。

Cisco Prime Collaboration Deployment も次に利用できます。

Unified Communications ソフトウェア(8.6.1 以降のリリース)のアップグレード

クラスタ(8.6.1 以降のリリース)上での Cisco Option Package(COP)ファイル(ロケールまたはデバイス パック)のインストール

スイッチのバージョン

再起動

既存の 10. x クラスタ上の IP アドレスまたはホスト名の変更

新しい Unified CM または IM and Presence クラスタのインストール

Cisco Prime Collaboration Deployment 移行の種類

Cisco Prime Collaboration Deployment は 2 種類の移行をサポートします。

「単純な移行」

単純な移行では、クラスタ内の各ノードは元のホスト名、IP アドレスや他のすべてのネットワーク設定を保持します。

「ネットワークによる移行」

ネットワーク移行では、クラスタ内の 1 つ以上のノードにホスト名、IP アドレス、および Collaboration Applications に必要な他のネットワーク設定の変更があります。

Cisco Prime Collaboration Deployment 移行の前提条件

VMware ESXi Hypervisor をインストールします。

Cisco Prime Collaboration Deployment への仮想マシンの展開(仮想アプライアンスとして渡されます)

必要な Virtualization Archive(OVA)テンプレートをダウンロードし、テンプレートを使用してターゲットの仮想マシンを作成します。

ターゲット リリース用の Cisco ISO イメージをダウンロードし、Cisco Prime Collaboration Deployment にアップロードします。

新しい仮想マシンのインポートとインストールに備えて、古いノードから Secure File Transfer Protocol(SFTP)サーバにデータをエクスポートします。

仮想マシンに Cisco Collaboration システム リリース 10. x ノードをインストールします。

単純な移行

ネットワークに変更を加えない移行(ホスト名、IP アドレス、または DNS の変更など)により、段階的移行のアプローチを使用できます。単純な移行では、Cisco Prime Collaboration Deployment はクラスタ内の各ノードに最初に COP ファイルをインストールします。次に、パブリッシャ ノードのデータをエクスポートします。Cisco Prime Collaboration Deployment は、次に既存のパブリッシャの電源を切断し、パブリッシャのデータを新しい仮想マシンにインストールおよびインポートします。パブリッシャの移行が完了したら、Cisco Prime Collaboration Deployment はデータのエクスポート、既存サーバの電源切断、クラスタのバックアップ呼処理ノードのインストールを開始します。これらのバックアップ ノードが起動すると、Cisco Prime Collaboration Deployment はプライマリ呼処理ノードからデータをエクスポートします。Cisco Prime Collaboration Deployment がプライマリ呼処理ノードの電源を切断すると、電話機はバックアップ呼処理ノードに登録されます。Cisco Prime Collaboration Deployment は、続いて新しいプライマリ呼処理ノードのインストールとインポートを開始します。


) Cisco Prime Collaboration Deployment はさまざまなリリースからの移行を実行できますが、仮想マシンへの移行の宛先のリリースは Cisco Collaboration システム リリース 10x である必要があります。


ネットワークによる移行

ネットワークの変更が伴う移行では、Cisco Prime Collaboration Deployment を並行カットオーバーのアプローチに利用できます。ネットワーク移行では、すべてのノードがデータのエクスポートを同時に実行してから Cisco Prime Collaboration Deployment はパブリッシャ ノードをインストールします。その後、すべてのノードを同時にインストールできます。新しいクラスタ ノードのインストール後、電話機をリセットして新しい TFTP サーバを追加できます。電話機を新しいノードに切り替えると、古いクラスタ ノードの電源を切断し、カットオーバーを新しいシステムに補完できます。

Cisco VCS から Unified CM へのビデオ エンドポイントの移行

Cisco TelePresence Video Communication Server(VCS)から Cisco Unified CM 10. x に移行したビデオ エンドポイントは、ビデオ中心の VCS 環境で使用できる機能のサブセットのみをサポートする場合があります。ただし、Cisco Unified CM に移行すると、単一の呼制御エージェントにある他の機能の考慮事項や統合ダイヤル プランなどの利点を提供できます。Cisco Unified CM へのビデオ エンドポイントの移行は、SIP および SCCP エンドポイントの両方をサポートしますが、すべてのお客様が SIP エンドポイントに移動することをシスコは推奨します。SCCP はサポートされていますが、Unified Communications ベンダーと顧客の両方で SIP の人気が高まり、SIP 特長や機能も増大したため、SIP は Unified Communications の新しい標準および推奨される選択肢になりました。

ビデオ エンドポイントを SIP エンドポイントとして Unified CM に移行する際は、次の推奨事項を考慮してください。

技術的機能(コーデックまたはコンテンツ共有を行う機能など)が完全にサポートされ、移行によって何らかの機能が失われることがないことを確認します。

ユーザが良いエクスペリエンスを得られるように、十分なネットワーク キャパシティを提供します。ビデオ解像度が高まるにつれ、音声専用コールと比較した場合よりも高い帯域幅が必要になります。

ダイヤル プランと関連するゲートウェイまたはトランク(ISDN H.320 ゲートウェイなど)、およびアプリケーション サーバ(会議サーバおよびブリッジなど)を移行します。

エンドポイントについては、エンドポイントのバージョンがアップグレードされるか、一部のデバイスで異なるライセンスが必要な場合は、必要な追加ライセンスを検討します。

システム管理ツールは、多数のエンドポイントがある場合や、エンドポイントにより多くのバック エンド管理やサポートが必要な場合に非常に役立つ可能性があります。

顧客は、Unified CM へのビデオ デバイスの移行が可能な限り効率的かつ効果的に行われるようにするため、デバイスの種類、実行可能性、および必要なタスクの範囲を評価する必要があります。

H.323 から SIP への移行

H.323 は、音声、ビデオ、およびデータ会議を含む IP ネットワーク上でのマルチメディア通信の要件を十分に理解した上で設計されました。また、これらの機能を実行するための統合システム全体を定義します。SIP の導入は増加しているものの、H.323 はそのフィールドにおける寿命から、今でもビデオ会議のエンドポイントに最も広く導入されているプロトコルです。組織は、H.323 を配置するために多くの労力とコストを費やして、使用環境にどのように適合させるかを理解してきました。

SIP は実装しやすく、ビデオ市場での人気を得始めました。組織がシグナリング プロトコルを変更するといった案と苦戦する間にも、業界は成長を続け、SIP はその使いやすさと他のベンダーの製品と統合可能なことから人気が高まりました。Cisco Collaboration Systems は H.323 および SIP の両方をサポートしていますが、シスコでは、H.323 に類似した一連のサービスを提供する、H.323 よりもはるかに簡単で豊富な拡張性とスケーラビリティに優れた SIP を推奨しています。

H.323 から SIP へのトランクの移行

Cisco Unified CM は SIP と H.323 の両方のクラスタ間トランクをサポートし、多くの場合、SIP または H.323 のいずれを使用するかは、各プロトコルで提供される一義的な機能により異なります。エクスペリエンス、相互運用性の容易さ、特長、他のさまざまな製品との機能性など、多くの要因が顧客の選択に影響します。Cisco Collaboration System は H.323 トランクと SIP トランクの両方をサポートしますが、SIP トランクは相互運用性の容易さや H.323 トランクでは利用できない追加された特長および機能を提供するため、すべての配置に SIP トランクを使用することを推奨します。

H.323 および SIP トランク機能と操作の詳細については、「Cisco Unified CM トランク」の章を参照してください。

H.323 から SIP へのゲートウェイの移行

Cisco Unified Communications Manager(Unified CM)は、ゲートウェイの SIP と H.323 の両方のプロトコルをサポートします。Cisco ゲートウェイは、Cisco Collaboration Systems を公衆電話交換網(PSTN)、従来型の PBX、またはサードパーティ製の外部配置ソリューションに接続するための複数の方法を提供します。シスコは音声とビデオ ゲートウェイの両方を、両方のプロトコルを完全にサポートするエントリレベルからハイエンドまで提供しますが、Cisco Collaboration 音声とビデオ製品のポートフォリオ全体でより優れた相互運用ができる SIP をすべてのコール シグナリングに選択することを強く推奨します。

H.323 および SIP ゲートウェイ機能と操作の詳細については、「ゲートウェイ」の章を参照してください。

SCCP から SIP へのエンドポイントの移行

Session Initiation Protocol(SIP)の標準シグナリングに関する一般的な推奨事項を考慮し、管理者用は、既存の SCCP IP エンドポイントを SIP IP エンドポイントに移行し、同等の機能と規格適合の実現を検討する必要があります。既存の SCCP IP 電話機モデルが SIP ロードをサポートする場合、管理者は、Cisco Unified CM Bulk Administration Tool(BAT)を使用してこの移行を実行できます。

Unified CM BAT は、SCCP 電話機から SIP 電話機への移行に推奨されるツールです。SIP は、業界のユニバーサル プロトコル規格です。Unified CM BAT 内では、既存の SCCP 電話機のレポートを生成する SCCP-to-SIP 電話機移行ワークフロー( [Bulk Administration] > [Phones] > [Migrate Phones] > [SCCP to SIP])があります。移行する SCCP 電話機を選択した後は、これらのデバイスを SIP に移行するジョブは、すぐに実行されるか、後で実行するようスケジュールできます。SCCP-to-SIP の移行中は電話レポート内の SIP に特定のデフォルト値のみが移行され、テンプレート内の他の値は移行されません。SCCP から SIP への電話機の移行は、移行自体が電話機のリセットを処理するため、手動でリセットする必要はありません。

移行手順の詳細については、次の Web サイトで入手可能な『 Cisco Unified Communications Manager Bulk Administration Guide 』の最新バージョンを参照してください。

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

SIP URI ダイヤルおよび電話番号

SIP ユニフォーム リソース識別子(URI)は、ユーザにコールを転送するのアドレッシング スキーマです。URI は、基本的にユーザに割り当てられた電話番号のエイリアスです。SIP URI は電子メール アドレスに似ており、次の形式で記述されます。

sip: x @ y : Port

ここで、 x はユーザ名、 y はホスト(ドメインまたは IP)です。

次に、例を示します。

username@cisco.com または users-directorynumber@cisco.com

URI は、@ 記号で区切られたユーザ名とホスト アドレスで構成される英数字の文字列です。Cisco Unified CM は次のディレクトリ URI の形式をサポートしています。

User @ domain (たとえば、joe@cisco.com)

Users-directorynumber @ domain (たとえば、9728135555@cisco.com)

SIP 要求に user=phone タグがある場合、SIP URI は常に数値 SIP URI として解釈され、Unified CM は SIP URI のユーザ部分をディレクトリ番号と見なします。user=phone が存在しない場合、発呼側デバイス(エンドポイントまたはトランク)の SIP プロファイルのダイヤル ストリング解釈の設定に基づいて決定されます。この設定は、Unified CM が数値 SIP URI として受け入れる文字セット(0 ~ 9、*、#、+ およびオプションとして A ~ D)を定義するか、または ディレクトリ URI としての解釈を強制します。

Cisco Unified CM 9.0 以前のリリースでは、すべての SIP URI が常に数値 SIP URI として処理されます。


) ポートを指定しない場合、デフォルトの SIP ポート(5060)が使用されます。デフォルト SIP ポートを別のポートに変更した場合は、SIP URI に指定する必要があります。


次の URI およびディレクトリ番号(DN)の考慮事項は、Unified CM およびサポートされるエンドポイントに適用されます。

DN は、エンドポイント デバイスのプライマリ ID です。

URI は DN に割り当てられ、各 DN は最大 5 つの URI をサポートできます。

デバイスは常に DN に登録されます。

URI は、Cisco Unified IP Phone 9900 シリーズ、Cisco Unified IP Phone 8961、Cisco Jabber for Windows 9.6、Cisco Desktop Collaboration Experience DX650、およびサードパーティのエンドポイントから電話をかけることができます。

プライマリ URI は、Unified CM での LDAP から直接同期できます。

詳細については、「エンドポイント SIP URI の実行」の項を参照してください。

仮想 Unified CM による USB サポート

オーディオ ソース ファイルからの保留音(MoH)(ユニキャストまたはマルチキャストを使用して)はサポートされますが、Unified CM への固定またはライブのオーディオ ソースの接続は、仮想サーバによる USB 音声サポートの不足により、Unified CM 10. x ではサポートされません。次のガイドラインは、仮想 Unified CM サーバ ノードによるライブ オーディオ ソース MoH に適用されます。

USB 音声デバイスからのライブまたは固定オーディオ ソース フィードは Unified CM 10 x ではサポートされません。

代わりに、固定またはライブオーディオ ソースからマルチキャスト MoH フィードを渡すために、Cisco IOS ルータが使用される場合があります。これには、Survivable Remote Site Telephony(SRST)または拡張 SRST を使用した Cisco IOS ルータのマルチキャスト MoH の設定が必要です。

Cisco IOS ルータがエンドポイントおよびゲートウェイに音声をストリーミングするために、マルチキャストをネットワークでイネーブルにする必要があります。

Cisco UCS B シリーズ ブレード サーバおよび C シリーズ ラックマウント サーバは、シリアル ポート、Video Graphics Array(VGA)モニタ ポート、および 2 つの Universal Serial Bus(USB)ポートを提供するローカルのキーボード、ビデオ、およびマウス(KVM)ケーブル接続をサポートしますが、Unified CM VMware 仮想アプリケーションはこれらの USB ポートおよびシリアル ポートにアクセスできません。したがって、Unified CM は、Simplified Message Desk Interface(SMDI)統合や、これらのサーバへのオーディオ カードまたはフラッシュ ドライブを使用したライブ MoH オーディオ フィードの固定 MoH オーディオ ソース統合のための Cisco Messaging Interface(CMI)サービスをサポートしなくなりました。