この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
この章では、管理者が従来の PBX システムから IP テレフォニー、および以前の Cisco Collaboration System リリース(9. x 、10. x 、11. x )から最新の Cisco Collaboration システム リリース(CSR)12. x に移行する際の管理上の推奨事項について説明します。
Open Virtualization Archive(OVA)テンプレート、VMware、ESXi Hypervisor、および Collaboration アプリケーションのハードウェアおよびソフトウェアの最小要件については、次のマニュアルを参照してください。
https://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/uc_system/virtualization/virtualization-software-requirements.html
https://www.vmware.com/resources/compatibility
Cisco Collaboration システム リリース 12. x 以降のリリースでは、ほとんどの Cisco Collaboration アプリケーションには仮想化の導入が必要であり、ハイパーバイザなしではサーバに直接インストールされない可能性があります。VMware vSphere ESXi は現在サポートされる唯一のハイパーバイザであり、Cisco Collaboration システム内のすべての仮想化展開で必須です。Cisco Collaboration システム リリースのいずれのリリースも、VMware vSphere ESX を含めて、ESXi 以外のどの VMware のサーバ仮想化製品もサポートしていません。
移行が正常に行われるように、次のリソースを使用してすべての要件が満たされているかどうかを移行前に検証することを推奨します。
https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/uc_system/unified/communications/system/Compatibility/CSR-Compatibility-Matrix.html
https://www.cisco.com/c/en/us/support/unified-communications/unified-communications-manager-callmanager/products-device-support-tables-list.html
この検証は、サポートされるアップグレード パスを使用して移行が正常に行われるようにします。たとえば、アプリケーションの以前のソフトウェア バージョンの中には、正常に移行するために複数のアップグレードが必要になるものもあります。同様に、サーバ ハードウェアとソフトウェアの互換性を実現するために、複数ステップのハードウェアおよびソフトウェアのアップグレードを組み合わせる必要がある場合があります。
Cisco Collaboration システム製品の詳細については、次の Web サイトで入手可能なマニュアルを参照してください。
https://www.cisco.com/c/en/us/solutions/collaboration/collaboration-systems-release/index.html
サポートされているすべてのシステム ハードウェアの一覧については、次の URL で入手可能なユニファイド コンピューティング製品のマニュアルを参照してください。
https://www.cisco.com/c/en/us/products/servers-unified-computing/product-listing.html
表 26-1 に、この章に新しく追加されたトピック、またはこのマニュアルの以前のリリースから大幅に改訂されたトピックの一覧を示します。
|
|
|
---|---|---|
Cisco Prime License Manager がシスコ スマート ソフトウェア ライセンシングで置き換えられました。 |
||
Cisco Collaboration System Release(CSR)12. x のその他のマイナー アップデート。 |
これは重要な選択です。共存とは、通常、2 つ以上のシステムが長期間(たとえば 6 ヵ月を超える任意の期間)にわたって共存することを意味します。このシナリオでは、PBX やボイスメールなどの機能の透過性が重要な考慮事項になります。必要な機能の透過性レベルを実現するために、既存のシステムへの投資やアップグレードが必要となる場合があります。移行は、通常、短期間(6 ヵ月未満の任意の期間)で実施します。このシナリオでは、ユーザは、移行が「短い」期間で完了することを認識しているため、既存の機能の一部しか提供されないことを許容しやすくなります。この「短い」期間については、多くの場合、既存のシステム機能で十分であるため、一般的に、移行は共存よりもコストが少なくなります。
すべての管理者は、いずれのコラボレーション移行手順も実行する前に、IP インフラストラクチャが「コラボレーション対応」(冗長性、ハイ アベイラビリティ、電力消費、Quality of Service(QoS)、インライン パワー、イーサネット ポートなど)となっていることを確認する必要があります。詳細については、ネットワーク インフラストラクチャの章を参照してください。
Cisco Unified Computing System(UCS)に Cisco Unified Communications を初めて導入する場合、次の Web サイトから入手可能な『 Cisco UCS Site Preparation Guide 』に記載されているガイドラインに従ってください。
https://www.cisco.com/c/en/us/td/docs/unified_computing/ucs/hw/site-prep-guide/ucs_site_prep.html
特長や機能が移行時に保持または変換されて同等の動作が保証されるよう、主要なシステム要件を判断する上で、ユーザのビジネス ニーズは重要となります。サポートされる機能を理解するには、さまざまなデバイスとソフトウェアの機能とバージョンのリストが役に立ちます。通常、すべての要件(FAX/モデム、環境制御システムなど)が適切に特定および考慮されるように、何らかのサイト サーベイまたはユーザ サーベイを実施する必要があります。
仮想化された Cisco Collaboration システムの移行方法としては、段階的な移行と並行カットオーバーの 2 種類が主となっています。Cisco Prime Collaboration Deployment を使うことで、移行プロセスを管理し、簡略化できます。
この方法は通常、Cisco Unified Communications Manager(Unified CM)を中心とした、小規模なトライアルから始めます。カスタマーが Unified CM に慣れてきたら、管理者はユーザを新しい Unified CM リリースの実稼働システムへとグループ単位で移行、移動します。
この方法の始め方は段階的な移行と同様ですが、カスタマーがトライアルの進行状況に納得した時点でカットオーバーする日時を決め、すべてのユーザを一度に新しい Cisco Collaboration システムに移行します。
並行カットオーバーには、段階的な移行に比べて次の利点があります。
並行カットオーバーでは、サービスを提供する前にサービス全体を導入しなくてはならないため、最初の時点からコラボレーション サービス(サポートするインフラストラクチャを含む)に対する全額投資が必要であるという短所があります。一方、段階的な移行では、必要となったときにシステムの個々のコンポーネントを購入できます。このアプローチでは、完全に配置する前に、小規模な試用システムから開始できます。いずれかの方法が正しいというわけではなく、それぞれのカスタマーの環境と優先事項に応じて、最適なオプションが決まります。
PBX システムから Cisco Collaboration システムに移行する場合の、段階的な移行と並行カットオーバーの例を以下に 示します。
例 26-1 Cisco Collaboration システムへの段階的な移行
このアプローチは通常、主要な企業 PBX に接続された Cisco Collaboration システムの小規模なトライアルを伴います。使用するシグナリング プロトコルの選択は、必要な機能および実装コストによって決まります。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 つずつ移動して、移行を完了します。
23,000 人ほどのユーザが約 60 のビルに分散した Cisco San Jose キャンパスでは、この方法で Cisco Collaboration システムへの移行が行われました。週末ごとに 1 つのビルというペースで、開始から完了までかかった期間はわずか 1 年余りです。選択されたビル内のすべてのユーザが特定され、金曜日の夜に、それらのユーザの内線番号が PBX から削除されました。同時に、PBX ルーティング テーブルへの追加が行われ、これらの内線番号にダイヤルしたすべての人が正しい PRI トランクを通じてルーティングされ、Unified CM に配信されるようにしました。週末の間に、ユーザの新しい内線番号が Unified CM に作成され、新しい IP Phone が該当するオフィス ロケーションに届けられ、月曜日の朝には使用できる準備が整っていました。このプロセスは、すべてのユーザが移行されるまで、各ビルに対して繰り返されました。
例 26-2 Cisco Collaboration システムへの並行カットオーバー
このアプローチでは、すべての IP Phone およびゲートウェイが完全に設定および導入され、ユーザのデスク上には IP Phone と PBX 電話機の両方が同時に置かれます。このアプローチでは、システムをテストする機会だけでなく、新しい IP Phone にユーザが慣れる機会を提供します。発信専用のトランクも Cisco Collaboration システムに接続できるため、ユーザは新しい IP Phone を使用して外線電話と内線電話のいずれも発信することができます。
Cisco Collaboration テレフォニー システムが完全に導入された時点で、着信 PSTN トランクを PBX から IP テレフォニー ゲートウェイに移動して新しいシステムを完全なサービスに移行する日時を選択できます。Cisco Collaboration システムの運用に確信が持てるまで PBX をそのまま残しておき、確信できた時点で PBX の使用を停止することもできます。
Cisco San Jose キャンパスのボイスメール サービスは、4 つの Octel 350 システムによって 23,000 人ものユーザに提供されていました。Cisco Unity サーバがインストールされ、ユーザのメールボックスが設定されました。ユーザは、新しいアクセス番号をダイヤルして自分の Cisco Unity メールボックスにアクセスできます。これにより、自分の名前とグリーティングを録音し、また新しいテレフォニー ユーザ インターフェイス(TUI)に慣れることができます。約 2 週間後の金曜日の夜、Unified CM 一括管理ツール(BAT)による更新が実行され、話中転送番号と無応答転送番号(CFB/CFNA)、および Unity システムへのすべてのユーザの Messages ボタンの宛先番号が変更されました。月曜日の朝には、Cisco Unity によるサービスがユーザに提供されていました。Octel 350 システムは 1 ヵ月間そのまま残されたので、ユーザは使用停止までに同システムに残っていたすべてのメッセージに対応することができました。
Cisco Collaboration システムの移行は 2 つの方法いずれでも可能であり、どちらか一方の方法が正しいということはありません。しかし、並行カットオーバーの方法が最適である場合がほとんどです。シスコは、Unified CM システムと PBX システム間の相互運用性テスト専用の実験施設を持っています。現在お使いのシステム アーキテクチャやアプリケーションは、その対象である場合とそうでない場合があります。シスコはこれらのテスト システムとその相互運用性およびエンドユーザ機能について文書化しています。こうしたドキュメントはインストールや移行プロセスに大いに役立ちます。このテストの結果は、次の Web サイトに公開されているアプリケーション ノートとして入手できます。
https://www.cisco.com/c/en/us/solutions/enterprise/interoperability-portal/index.html
アプリケーション ノートは頻繁に更新され、この Web サイトには新しいドキュメントが継続的に追加されています。この Web サイトを頻繁に確認して、最新情報を入手してください。
Cisco Prime Collaboration Deployment は、MCS サーバ上で稼働する Cisco Collaboration システムから仮想化環境で稼働する同システム、あるいは以前のバージョンから Cisco Collaboration システム リリース 12. x へ移行する際に使用される主要なツールです。
Cisco Collaboration システムの集中型導入を選択した企業は、次の 2 つのオプションから選択できます。
ほとんどのカスタマーは、次の利点があるため、最初のオプションを選択します。
リモート サイトは、並行カットオーバーの方法で移行するべきですが、中央サイトの移行は、並行または段階的のいずれの方法でも可能です。
この選択は、カスタマーの個別のビジネス ニーズに大きく依存します。Cisco Collaboration ソリューションでは、個々のサービスのほとんどを他のサービスとは独立して導入できます。たとえば、IP テレフォニーとボイス メッセージングは互いに独立して導入できます。
この機能により、大幅な柔軟性がカスタマーにもたらされます。あるカスタマーが、ボイスメール システムのサポートが終了したことによって、顧客満足度の低下につながるさまざまな問題を抱えているとします。多くの場合、Cisco Unity Connection は現在使用している PBX と併用して導入、または統合できるため、この問題は解決できます。新しいボイスメール システムが適切に運用できるようになった後、次のコラボレーション サービス、つまり IP テレフォニーに取りかかることができます。
Cisco Unified Communications Manager(Unified CM)によって制御されているビデオ エンドポイントは、ビデオ中心の Cisco Video Communications Server(VCS)で使用できる機能の一部のみをサポートします。一方で、Cisco Unified CM に移行することで、単一の呼制御エージェントのもと、統合ダイヤル プランなど、さまざまな機能が統一されるという利点もあります。以下に、Unified CM へのビデオ エンドポイントの移行についてのガイドラインを示します。
– 段階的な移行ではしばらくの間、既存の電話機はバックアップとして残したまま、新しいデバイスに慣れることができます。このため、この目的を達成するにはこの移行方法が最も一般的です。
– ユーザが優れたエクスペリエンスを得られるように、十分なネットワーク キャパシティを提供します。ビデオ解像度の向上に伴い、音声のみのコールと比較して高い帯域幅が必要になります。
– ダイヤル プランと関連するゲートウェイ(ISDN H.320 ゲートウェイなど)、およびアプリケーション サーバ(会議サーバおよびブリッジなど)を移行します。
– システム管理ツールは、多数のエンドポイントがある場合や、エンドポイントにより多くのバックエンド管理やサポートが必要な場合に非常に役立ちます。
組織はデバイスの種類、実行可能性、および必要なタスクの範囲を評価して、Unified CM へのビデオ デバイスの移行が可能な限り効率的かつ効果的に行われるようにできます。
Cisco Collaboration システム リリース 12. x では、シスコ スマート ソフトウェア ライセンシングにより、ライセンスを一元管理できるようになっています。12. x リリースのライセンス モデルは、以前のシステム リリースで使用されていた Prime License Manager ではなく、Cisco Smart Software Manager(SSM)で管理されます。
Cisco Unified Communications またはコラボレーション ソリューションを導入済みのお客様は Cisco Global Licensing Operations(GLO)プロセスを使用して既存のライセンスをシスコ スマート ソフトウェア ライセンシングに移行できます。
Cisco ソフトウェア ライセンシング プロセスおよび機能に熟練したユーザ向けのセルフサービス オプションが用意されています。このセルフサービス オプションは Product License Registration ツールより利用できます。
https://tools.cisco.com/SWIFT/LicensingUI/migrateDisplayProducts
(注) 上記のリンクで Product License Registration ツールにアクセスするには、有効な Cisco.com のログイン ID とパスワードが必要です。
また、Support Case Manager https://tools.cisco.com/ServiceRequestTool/scm/mgmt/case を使用してケースを開くことで、Cisco Global Licensing Operation(GLO)チームのサポートを受けることもできます。
ライセンスを移行する場合は必ずこのセクションで示すガイドラインに従ってください。
ライセンス移行プロセスが簡素化されて、Cisco Smart Software License Manager への移行が大幅に容易になりました。Cisco Collaboration システム リリース 12. x へのアップグレードを希望するカスタマーは、移行に関するあらゆるニーズに関して、Cisco Global Licensing Operations(GLO)チームに直接問い合わせることできます。GLO がリクエストを処理して、組織の Cisco スマート アカウントにライセンスを転送します。シスコはライセンスの付与対象となるリリース 12. x ユーザの数を反映するべく、現行のソフトウェア サービス契約書の製品記録を調整します。
移行するシステムに未使用の製品アクティベーション キー(PAK)がある場合は必ず登録してください。以前のライセンス モデルで拡張を考慮していた場合は、今回の移行でも考慮してください。たとえば、12. x よりも前のリリースのクラスタを保持しつつ、残りを 12. x にアップグレードする必要がある場合、GLO チームへのライセンス移行リクエストに、移行する必要があるユーザの正確な数と、現状のままにするユーザの正確な数を明記してください。
必ずすべてのライセンスのニーズを詳しく分析して、リクエストでニーズを明確に伝えるようにしてください。DLU を含む 9. x よりも前のリリースからの移行の場合、DLU は移行後は「失効」状態となるため、古いスキーマに戻すことはできません。
(注) ライセンス プロセスは新しいリリースごとに変更される可能性があります。必ずシスコの GLO チームにプロセスを確認してから license@cisco.com にライセンス リクエストを送信してください。
ライセンス移行に関する GLO への問い合わせは、以下の段階で行うことができます。
(注) 9.x よりも前のシステムを Collaboration システム リリース 12.x に移動する場合、カスタマーは未使用の DLU を使用するか、移行時に破棄するかを決定する必要があります。DLU を破棄した場合、払い戻しはありませんが、その後のサービス料金に対して割引を受けられます。現行の契約書上の Cisco Unified Communications Software Subscription(UCSS)ユーザとの違いを確認し、更新時に UCSS および Essential Operate サービス(ESW)の料金に変更がある場合はその金額を見積もります。
移行時にカスタマーは既存のライセンスの使用方法を選択できます。次のオプションがあります。
アップグレード プロセスが完了すると、情報がロックされ、今後のカスタマーの権利として記録されます。これ以降、ライセンス移行情報が変更されることはありません。
https://www.cisco.com/go/smartlicensing
https://www.cisco.com/c/en/us/support/unified-communications/unified-communications-manager-callmanager/products-installation-and-configuration-guides-list.html
Cisco Smart Software Manager(Cisco SSM)では現在、以下のシスコ コラボレーション アプリケーションをサポートしています。
Cisco Smart Software Manager の詳細については、以下のリンク先から入手可能なマニュアルを参照してください。
https://www.cisco.com/c/en/us/buy/smart-accounts/software-manager.html
Cisco Prime Collaboration Deployment は、管理者がレガシーの Cisco Unified CM および Cisco IM and Presence サービスから Cisco Collaboration システム リリース 12. x の仮想化環境への移行を実行できるようにする管理アプリケーションです。Cisco Prime Collaboration Deployment はクラスタを移行してデータ移行を処理し、実稼働(ソース)クラスタにほとんど影響を与えずにすべての新しい VMware ESXi ホストに 12. x リリースをインストールできます。以前の移行方法は、「サーバ リカバリ」を行う Disaster Recovery System を使って、アップグレードを行った後にバックアップから復元するという、多くの手順を要するものでした。Cisco Prime Collaboration Deployment では、直接移行することができます。
Cisco Prime Collaboration Deployment を使って、以下を行うことも可能です。
Cisco Prime Collaboration Deployment は 2 種類の移行をサポートします。
単純な移行では、クラスタ内の各ノードは元のホスト名、IP アドレスなどのネットワーク設定をすべて保持します。
ネットワーク移行では、クラスタ内の 1 つ以上のノードでホスト名や IP アドレスなど、Collaboration Applications に必要なネットワーク設定が変更されます。
この移行方法では、移行中に IP アドレスやホスト名が変更されません。以下に Cisco Prime Collaboration Deployment における移行タスク設定で推奨される手順を示します。この手順に従うことで、高い可用性を提供しながら移行を実現できます。
Cisco Prime Collaboration Deployment はまずすべての既存ノードのデータをエクスポートします。次に既存のパブリッシャを停止し、仮想マシンとして稼働する新しいパブリッシャをインストールして、パブリッシャのデータをインポートします。
パブリッシャの移行が完了したら、Cisco Prime Collaboration Deployment はクラスタの TFTP ノードとバックアップ コール処理ノードを移行します。まず、既存の TFTP ノードとバックアップ コール処理ノードを停止します。次に、Prime Collaboration Deployment は新しい TFTP ノードとバックアップ コール処理ノードをインストールし、バックアップ データをインポートします。
バックアップ コール処理ノードの移行が完了すると、Cisco Prime Collaboration Deployment の移行タスクが一時停止します。ここで管理者は、Unified Communications Manager グループ内の順序を変更して、またはデバイス プールを使用して、すべての電話機がバックアップ コール処理ノードに再登録されるよう設定します。
最後に、Cisco Prime Collaboration Deployment はプライマリ呼処理ノードを移行します。これが完了すると、電話機をプライマリ呼処理サーバに再登録できます。
詳細については、以下のリンク先から入手可能な最新バージョンの『 Upgrade and Migration Guide for Cisco Unified Communications Manager and IM and Presence Service 』を参照してください。
https://www.cisco.com/c/en/us/support/unified-communications/unified-communications-manager-callmanager/products-installation-guides-list.html
Cisco Prime Collaboration Deployment は、ネットワーク設定の、サーバの IP アドレスやホスト名などのパラメータの変更が必要な移行でも使用できます。移行元となる Unified CM クラスタがリリース 8. x 以降を搭載している場合、Bulk Certificate Management のエクスポート、統合、インポートの各機能を使って、個々の電話機の ITL を手動で削除することなく電話機の初期信頼リスト(ITL)を移行中に更新できます。
詳細については、次のサイトで入手可能な『 Cisco Prime Collaboration Deployment Administration Guide 』の最新版を参照してください。
https://www.cisco.com/c/en/us/support/unified-communications/unified-communications-manager-callmanager/products-maintenance-guides-list.html
Cisco TelePresence Video Communication Server(VCS)から Cisco Unified CM に移行したビデオ エンドポイントでは、ビデオ中心の VCS 環境で使用できる機能の一部しかサポートされない場合があります。一方で、Cisco Unified CM に移行することで、単一の呼制御エージェントのもと、統合ダイヤル プランなど、さまざまな機能が統一されるという利点もあります。Cisco Unified CM へのビデオ エンドポイントの移行は、SIP および SCCP エンドポイントの両方をサポートしますが、シスコはすべてのカスタマーに、SIP エンドポイントに移行することを推奨します。SCCP はサポートされてはいますが、Unified Communications ベンダーとカスタマーの両方で SIP の人気が高まり、SIP の機能も拡張されています。このため、SIP は Unified Communications の新しい標準、そして推奨される選択肢となっています。
ビデオ エンドポイントを SIP エンドポイントとして Unified CM に移行する際は、次の推奨事項を考慮してください。
H.323 は、音声、ビデオ、およびデータ会議など、IP ネットワーク上でのマルチメディア通信の要件を十分に理解した上で設計されています。また、これらの機能を実行するための統合システム全体を定義しています。SIP の導入は増加しているものの、H.323 はビデオ会議分野での歴史が長いため、今でもビデオ会議のエンドポイントに最も広く導入されているプロトコルです。多くの組織が、H.323 の導入に多大な労力とコストを費やし、その結果使用環境への適合方法を理解しています。
SIP は実装しやすく、ビデオ市場での人気が高まりつつあります。多くの組織がシグナリング プロトコルの変更に苦慮する中、業界は進化を続け、SIP はその使いやすさと他のベンダー製品と統合可能なことから人気を博しています。Cisco Collaboration システムは H.323 と SIP の両方をサポートしていますが、シスコは SIP を推奨しています。H.323 に類似した一連のサービスを提供し、かつ H.323 よりもはるかにシンプルで柔軟性に富み、拡張性にも優れているためです。
Cisco Unified CM は SIP と H.323 の両方のクラスタ間トランクをサポートしています。多くの場合、SIP と H.323 のどちらを使用するかは、それぞれのプロトコルが提供する独自の機能によって決定されます。エクスペリエンス、相互運用性の容易さ、特長、他のさまざまな製品との機能性など、多くの要因がカスタマーの選択に影響します。Cisco Collaboration システムは H.323 トランクと SIP トランクの両方をサポートしますが、シスコはすべての導入において SIP トランクを使用することを推奨します。SIP トランクは相互運用がしやすく、他にも H.323 トランクでは利用できない特長や機能を提供しているためです。
H.323 および SIP トランクの機能と操作の詳細については、Cisco Unified CM トランクの章を参照してください。
Cisco Unified Communications Manager(Unified CM)は、ゲートウェイで SIP と H.323 の両方のプロトコルをサポートします。シスコのゲートウェイは、Cisco Collaboration システムを公衆電話交換網(PSTN)、従来型の PBX、またはサードパーティ製の外部導入ソリューションに接続するための複数の方法を提供します。シスコは音声とビデオ両方のゲートウェイを、エントリレベルからハイエンドまで、両方のプロトコルを完全にサポートする形で提供していますが、すべてのコール シグナリングにおいて SIP を選択することを強く推奨します。SIP は Cisco Collaboration の音声およびビデオ製品のポートフォリオ全体との相互運用性に優れているためです。
H.323 および SIP ゲートウェイの機能と操作の詳細については、ゲートウェイの章を参照してください。
Session Initiation Protocol(SIP)の標準シグナリングに関する一般的な推奨事項を考慮すると、同等の機能と規格適合の実現に向けて、管理者は既存の SCCP IP エンドポイントを SIP IP エンドポイントに移行することを検討する必要があります。既存の SCCP IP Phone モデルが SIP ロードをサポートする場合、管理者は Cisco Unified CM Bulk Administration Tool(BAT)を使用して移行できます。
Unified CM BAT は、SCCP 電話機から SIP 電話機への移行における推奨ツールです。SIP は、業界の普遍的なプロトコル標準です。Unified CM BAT には、電話機を SCCP から SIP に移行するワークフローがオプションとして提供されています( [一括管理(Bulk Administration)] > [電話(Phones)] > [電話機の移行(Migrate Phones)] > [SCCP から IP(SCCP to SIP)] )。このワークフローを使って既存の SCCP 電話機についてのレポートを作成できます。移行する SCCP 電話機を選択した後、SIP に移行するジョブは、すぐに実行するか、後で実行するようスケジュールできます。SCCP から SIP への移行では電話機レポート内の SIP 固有のデフォルト値のみが移行され、テンプレート内の他の値は移行されません。SCCP から SIP への電話機の移行は、移行自体が電話機をリセットするため、手動でリセットする必要はありません。
移行詳細と具体的な手順については、以下のリンク先から入手可能な最新バージョンの『 Bulk Administration Guide for Cisco Unified Communications Manager 』を参照してください。
https://www.cisco.com/c/en/us/support/unified-communications/unified-communications-manager-callmanager/products-maintenance-guides-list.html
SIP Uniform Resource Identifier(URI)は、ユーザにコールを転送する際のアドレッシング スキーマです。URI とは、本質的にはユーザに割り当てられた電話番号のエイリアスです。SIP URI は電子メール アドレスに似ており、次の形式で記述されます。
ここで、 x はユーザ名、 y はホスト(ドメインまたは IP)です。
username@cisco.com または users-directorynumber@cisco.com
URI は、@ 記号で区切られたユーザ名とホスト アドレスで構成される英数字の文字列です。Cisco Unified CM は次のディレクトリ URI の形式をサポートしています。
SIP 要求に user=phone タグがある場合、SIP URI は数値型の SIP URI として解釈され、Unified CM は SIP URI のユーザ部分を電話番号と見なします。user=phone がない場合は、発信側デバイス(エンドポイントまたはトランク)の SIP プロファイルのダイヤル ストリング解釈の設定に従います。この設定では、Unified CM が数値型 SIP URI として許容する文字セット(0 ~ 9、*、#、+ およびオプションとして A ~ D)を定義するか、またはディレクトリ URI としての解釈を強制します。
(注) ポートを指定しない場合、デフォルトの SIP ポート(5060)が使用されます。SIP ポートをデフォルトから変更した場合は、SIP URI で指定する必要があります。
以下に Unified CM およびサポートされるエンドポイントについての、URI および電話番号(DN)の考慮事項を示します。
詳細については、エンドポイント SIP URI の実装の項を参照してください。
オーディオ ソース ファイルからの保留音(MoH、ユニキャストまたはマルチキャストを使用)はサポートされますが、仮想サーバで USB オーディオがサポートされていないため、Unified CM への固定またはライブのオーディオ ソースの接続はサポートされていません。以下に、仮想 Unified CM サーバ ノードによるライブ オーディオ ソース MoH についてのガイドラインを示します。
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)連携を可能にする Cisco Messaging Interface(CMI)サービスや、オーディオ カードやフラッシュ ドライブを使用したこれらのサーバへのライブ MoH オーディオ フィードを可能にする固定 MoH オーディオ ソース連携がサポートされなくなっています。
Cisco MCS 物理サーバ上で稼働する既存の Cisco IM and Presence 導入をリリース 12. x にアップグレードするには、仮想化環境への移行が必要です。この移行を促進するには Cisco Prime Collaboration Deployment を使用します。