この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
サービス プロバイダーはプロファイルを使用して、RC ユニット以外に Cisco IP Phone のプロビジョニングを行います。プロビジョニング プロファイルには、Cisco IP Phone を再同期するためのパラメータをある程度含めることができます。プロファイルには、リモート サーバから提供されるすべてのパラメータが記載できます。デフォルトでは、電源投入時と、プロファイルで設定された間隔で、Cisco IP Phone が再同期を行います。ユーザが顧客の環境で Cisco IP Phone に接続すると、デバイスは更新されたプロファイルとすべてのファームウェアのアップデートをダウンロードします。
本章の例では、1 台以上のサーバが必要です。以下のサーバをローカル PC にインストールして実行できます。
サーバの構成でのトラブルシューティングを容易にするために、サーバのタイプごとに、クライアントを別のサーバ マシンにインストールしてください。このプラクティスでは、Cisco IP Phone との相互通信とは無関係に、サーバの動作を適切に設定します。
Cisco は、以下のソフトウェア ツールもインストールすることを推奨します。
すべての Cisco IP Phone は初回のプロビジョニングが行われるまでは Cisco EDOS RC サーバとコンタクトします。
RC 配信モデルでは、Cisco EDOS RC サーバで特定のサービス プロバイダーにすでに関連付けられている Cisco IP Phone を顧客が購入します。インターネット テレフォニー サービス プロバイダー(ITSP)は、プロビジョニング サーバを設定および保守し、Cisco EDOS RC サーバにプロビジョニング サーバ情報を登録します。
インターネットに接続した状態で Cisco IP Phone の電源が投入されると、プロビジョニングされていない Cisco IP Phone のカスタマイズ状態は [オープン(Open)] になります。電話機はまず、ローカル DHCP サーバにプロビジョニング サーバ情報を照会し、Cisco IP Phone のカスタマイズ状態を設定します。DHCP クエリが成功した場合は、必要なプロビジョニング サーバ情報を提供する DHCP により [カスタマイズ状態(Customization State)] が [中断されました(Aborted)] に設定され、RC は試行されません。
DHCP サーバがプロビジョニング サーバ情報を提供しない場合、Cisco IP Phone は Cisco EDOS RC サーバに照会して MAC アドレスとモデルを指定し、[カスタマイズ状態(Customization State)] を [保留中(Pending)] に設定します。Cisco EDOS サーバは、プロビジョニング サーバの URL などの関連付けられたサービス プロバイダーのプロビジョニング サーバ情報で応答し、Cisco IP Phone の [カスタマイズ状態(Customization State)] を [カスタマイズ保留中(Custom Pending)] に設定します。次に、Cisco IP Phone は resync URL コマンドを実行してサービス プロバイダーの設定を取得し、それに成功した場合は [カスタマイズ状態(Customization State)] を [取得済み(Acquired)] に設定します。
Cisco EDOS RC サーバに Cisco IP Phone に関連付けられているサービス プロバイダーがない場合、Cisco IP Phone のカスタマイズの状態は [利用不可(Unavailable)] に設定されます。電話機は手動で設定するか、または電話機のサービス プロバイダーの場合は Cisco EDOS サーバに関連付けを追加できます。
[カスタマイズ状態(Customization State)] が [取得済み(Acquired)] になる前に電話機を LCD または Web ユーティリティのいずれかを使用してプロビジョニングした場合、[カスタマイズ状態(Customization State)] が [中断されました(Aborted)] に設定されるため、電話機が初期設定にリセットされていない限り Cisco EDOS サーバは照会されません。
電話機がいったんプロビジョニングされると、その電話機が初期設定にリセットされていない限り Cisco EDOS RC サーバは利用されません。
Cisco の工場出荷時のデフォルト設定により、Cisco IP Phone は自動的に、TFTP サーバのプロファイルとの再同期を試みます。LAN 上で管理されている DHCP サーバは、プロファイルに関する情報と、デバイスへのプロビジョニング用に設定された TFTP サーバに関する情報を提供します。サービス プロバイダーは、新しいCisco IP Phone をそれぞれ LAN に接続します。Cisco IP Phone は自動的にローカル TFTP サーバと再同期して、自身を導入準備状態に初期化します。このプロビジョニング プロファイルには通常、リモート プロビジョニング サーバの URL が含まれています。プロビジョニング サーバは、デバイスが導入されて顧客のネットワークに接続された後に、デバイスの更新を継続して行います。
Cisco IP Phone が顧客に出荷される前に、プロビジョニング済みデバイスのバーコードがスキャンされ、その MAC アドレスとシリアル番号が記録されます。この情報は、Cisco IP Phone が再同期するプロファイルを作成するのに使用できます。
顧客はCisco IP Phone を受け取ると、それをブロードバンド リンクに接続します。電源投入後、Cisco IP Phone はプロビジョニング中に設定された URL を使用して、プロビジョニング サーバに接続します。このようにして、Cisco IP Phone は必要に応じてプロファイルと再同期し、ファームウェアを更新します。
ここでは、さまざまなサーバやシナリオを使用する場合の、Cisco IP Phone のプロビジョニングの設定要件について説明します。このドキュメントの目的およびテスト上の都合から、プロビジョニング サーバはローカル PC にインストールして実行します。また、Cisco IP Phone のプロビジョニングには、一般的に利用可能なソフトウェア ツールも有用です。
Cisco IP Phone は、プロビジョニングの再同期およびファームウェア アップグレード動作の両方で TFTP をサポートします。デバイスをリモートから導入する場合は HTTPS を推奨しますが、HTTP および TFTP も使用できます。次に、プロビジョニング ファイルを暗号化してセキュリティを高める必要があります。NAT およびルータを保護するメカニズムがあれば、これにより、信頼性が極めて高くなります。TFTP は、社内にあるプロビジョニングされていない大量のデバイスをプロビジョニングするのに有用です。
Cisco IP Phone は、DHCP オプション 66 を使用して、DHCP サーバから直接 TFTP サーバの IP アドレスを取得できます。Profile_Rule にその TFTP サーバのファイルパスが設定されている場合、デバイスは TFTP サーバから自身のプロファイルをダウンロードします。ダウンロードは、デバイスが LAN に接続されている場合に電源投入時に行われます。
工場出荷時のデフォルト設定で提供される Profile_Rule は $PN.cfg です。 $PN には、CP-7841-3PCC などの電話機のモデル名が入ります。たとえば、CP-8841-3PCC の場合、ファイル名は CP-8841-3PCC.cfg になります。プロファイルが工場出荷時設定のままのデバイスは、電源投入後、DHCP オプション 66 で指定されたローカル TFTP サーバにあるこのファイルと再同期します(ファイルパスは、TFTP サーバ仮想ルート ディレクトリへの相対パスです)。
Cisco IP Phone は、ネットワーク アドレス変換(NAT)と互換性があり、ルータ経由でインターネットにアクセスします。セキュリティを強化するため、ルータは、Symmetric NAT(インターネットから、保護されたネットワークに入ることを許可されるパケットを厳格に制限するパケット フィルタリング方針)の実装により、不正な受信パケットのブロックを試みる可能性があります。したがって、TFTP を使用したリモート プロビジョニングは推奨しません。
Voice over IP は、NAT トラバーサルのフォームの一部が提供されている場合にのみ、NAT で使用できます。Simple Traversal of UDP through NAT(STUN)を設定します。このオプションでは以下が必要です。
Cisco IP Phone は、リモート インターネット サイトの Web ページを要求するブラウザのように動作します。これにより、顧客のルータに Symmetric NAT や他の保護機能が実装されている場合でも、プロビジョニング サーバと通信するための信頼性の高い手段が提供されます。リモートの導入では、特に、導入されるユニットが社内のファイアウォールまたは NAT 機能が有効なルータの背後に接続される場合に、TFTP よりも HTTP および HTTPS を使用した方が信頼性が高くなります。次の要件タイプの説明では、HTTP と HTTPS はほとんど同じ意味で使用されます。
基本的な HTTP ベースのプロビジョニングでは、HTTP GET メソッドを使用して設定プロファイルを取得します。通常、導入されるCisco IP Phone ごとに設定ファイルが 1 つ作成され、それらのファイルは HTTP サーバのディレクトリに保存されます。サーバが GET リクエストを受信すると、GET リクエスト ヘッダーで指定されたファイルを単純に返します。
カスタマー データベースの照会や転送中のプロファイルの生成を行うことで、スタティック プロファイルよりも、設定プロファイルのほうが動的に生成される可能性があります。
Cisco IP Phone が再同期を要求する場合は、HTTP POST メソッドを使用して再同期設定データを要求できます。デバイスを設定して、特定ステータスと識別情報を HTTP POST リクエストの本文内にまとめてサーバに送信することができます。サーバはこの情報を使用して、必要な応答設定プロファイルを生成したり、後で分析やトラッキングに使用するためにステータス情報を保存したりします。
GET および POST のリクエストの一部として、Cisco IP Phone はリクエスト ヘッダーの User-Agent フィールドに基本識別情報を自動的に入力します。この情報には、デバイスの製造者、製品名、現行のファームウェア バージョン、および製品シリアル番号が含まれています。
次は、CP-8841-3PCC の場合の User-Agent リクエスト フィールドの例です。
Cisco IP Phone が HTTP を使用して設定プロファイルと再同期するよう設定されている場合、機密情報を保護するために HTTPS を使用するか、プロファイルを暗号化することを推奨します。Cisco IP Phone では、プロファイルの暗号化に CBC モードの 256 ビット AES をサポートしています。HTTP を使用してCisco IP Phone によりダウンロードされるプロファイルを暗号化すれば、設定プロファイル内の機密情報が漏えいする危険性が回避されます。この再同期モードでは、プロビジョニング サーバの処理負荷が HTTPS を使用するよりも少なくなります。
(注) Cisco IP Phone 7800 シリーズ、および 8800 シリーズ Multiplatform Phone は、HTTP Version 1.0、HTTP Version1.1 をサポートします。また、HTTP Version 1.1 がネゴシエート トランスポート プロトコルの場合にはチャンク エンコードをサポートします。
この電話機では、リモート プロビジョニング(再同期)に HTTP 応答を使用することができます。現在の電話機は、次の 3 つの方法に分類されます。
導入済みのユニットのリモート管理におけるセキュリティを強化するため、Cisco IP Phone ではプロビジョニング時に HTTPS をサポートしています。各Cisco IP Phone は、Sipura CA サーバ ルート証明書のほかに固有の SLL クライアント証明書(および関連付けられている秘密キー)を保持します。サーバ ルート証明書を使用して、Cisco IP Phone は、承認されたプロビジョニング サーバを認識し、非承認サーバを拒否することができます。一方、クライアント証明書により、プロビジョニング サーバはリクエストを発行する個々のデバイスを特定できます。
HTTPS を使用して導入を管理するサービス プロバイダーでは、HTTPS を使用してCisco IP Phone が再同期するプロビジョニング サーバごとに、サーバ証明書を生成する必要があります。サーバ証明書は、Cisco サーバ CA ルート キーにより署名され、導入済みのすべてのユニットがその証明書を保持する必要があります。署名済みサーバ証明書を取得するために、サービス プロバイダーは証明書署名要求を Cisco に送信する必要があります。Cisco は、プロビジョニング サーバでのインストール用にサーバ証明書に署名して返送します。
プロビジョニング サーバ証明書には、共通名(CN)フィールド、および対象内でサーバを実行しているホストの FQDN が含まれている必要があります。またオプションで、スラッシュ(/)文字で区切られた情報がホストの FQDN の後に含まれている場合があります。次は、Cisco IP Phone により有効として受け入れられる CN エントリの例です。
サーバ証明書の確認に加えて、Cisco IP Phone は、サーバ証明書で指定されたサーバ名の DNS ルックアップにより、サーバ IP アドレスをテストします。
OpenSSL ユーティリティは証明書署名要求を生成できます。次の例は、1024 ビット RSA の公開キー/秘密キーのペアおよび証明書署名要求を生成する openssl コマンドを示しています。
このコマンドにより、サーバの秘密キーが privkey.pem に、対応する証明書署名要求が provserver.csr にそれぞれ生成されます。サービス プロバイダーは、 privkey.pem を秘密にして、 provserver.csr を署名のために Cisco に提出します。シスコは provserver.csr ファイルを受信すると、署名されたサーバ証明書として provserver.crt を生成します。
手順 1 URL https://webapps.cisco.com/software/edos/home へ移動し、CCO クレデンシャルでログインします。
手順 2 [証明書の管理(Certificate Management)] を選択します。
[CSR の署名(Sign CSR)] タブで、署名を取得するために前のステップの CSR をアップロードします。
手順 3 [製品を選択(Select Product)] ドロップダウン リスト ボックスから、[SPA1xx ファームウェア 1.3.3(SPA1xx firmware 1.3.3)]、[SPA232D ファームウェア 1.3.3 以降(newer/SPA232D firmware 1.3.3)]、[PA5xx ファームウェア 7.5.6 以降(newer/SPA5xx firmware 7.5.6)]、および [CP-78xx-3PCC/CP-88xx-3PCC 以降(newer/CP-78xx-3PCC/CP-88xx-3PCC)] を選択します。
手順 4 [CSR ファイル(CSR File)] ファイルで、[参照(Browse)] をクリックし、署名する CSR を選択します。
手順 5 [サインイン期間(Sign in Duration)] ドロップダウン リスト ボックスから、適切な期間(1 年など)を選択します。
手順 6 [証明書の署名要求(Sign Certificate Request)] をクリックします。
手順 7 署名済み証明書を受け取るには、次のいずれかのオプションを選択します。
次に、署名済みサーバ証明書は、以前に指定された電子メール アドレスに電子メールで送信されるか、ダウンロードされます。
Cisco はまた、サービス プロバイダーに Sipura CA クライアント ルート証明書も提供します。このルート証明書により、それぞれのCisco IP Phone が保持するクライアント証明書が本物であることが保証されます。Cisco IP Phone 7800 シリーズ、および 8800 シリーズ Multiplatform Phone は、Verisign、Cybertrust などが提供するサードパーティの署名済み証明書もサポートします。
HTTPS セッション中に各デバイスが提供する固有のクライアント証明書には、該当するフィールドに識別情報が埋め込まれています。この情報は、HTTPS サーバを介して、安全性の高いリクエストを処理するために起動される CGI スクリプトで使用できます。特に、証明書の件名は、ユニットの製品名(OU 要素)、MAC アドレス(S 要素)、シリアル番号(L 要素)を示します。次の例は、Cisco IP Phone 8841 Multiplatform Phone の場合に、クライアント証明書の件名フィールドに表示される次の各要素を示しています。
ファームウェア 2.0.x より前に製造されたユニットには、個別の SSL クライアント証明書が含まれていません。これらのユニットが 2.0.x ツリーのファームウェア リリースにアップグレードされると、HTTPS を使用しているセキュア サーバに接続できるようになりますが、サーバがユニットにクライアント証明書を要求した場合には、ユニットは一般的なクライアント証明書だけを提供できます。この一般的な証明書には、識別子フィールドに次の情報が含まれます。
Cisco IP Phone が個別の証明書を保持するかどうかを決定するには、$CCERT プロビジョニング マクロ変数を使用します。変数の値は、固有のクライアント証明書の有無に従って、インストールまたはインストールなしのいずれかに展開されます。一般的な証明書の場合、HTTP リクエスト ヘッダーの User-Agent フィールドからユニットのシリアル番号が取得できます。
HTTPS サーバを設定して、接続しているクライアントから SSL 証明書をリクエストすることができます。これを有効にすると、サーバは Cisco が提供する Sipura CA クライアント ルート証明書を使用して、クライアント証明書を確認できます。その後、サーバは、以降のプロビジョニングで CGI に証明書情報を提供できます。
証明書を保存する場所はさまざまです。たとえば、Apache をインストールした場合には、プロビジョニング サーバにより署名された証明書や、関連付けられた秘密キー、Sipura CA クライアント ルート証明書の保存場所のファイル パスは以下のようになります。
個別の情報については、HTTPS サーバのドキュメントを参照してください。
Cisco クライアント証明書ルート認証局が、固有の各証明書に署名します。対応するルート証明書が、クライアント認証の目的でサービス プロバイダーにより使用できるようになります。
IP アドレスまたは完全修飾ドメイン名(FQDN)にプロビジョニング サーバを指定することができます。FQDN を使用すると、冗長プロビジョニング サーバの導入が容易になります。プロビジョニング サーバが FQDN により識別される場合、Cisco IP Phone は DNS を介して FQDN から IP アドレスを解決します。プロビジョニングでは DNS A レコードのみサポートされます。DNS SRV のアドレス解決はプロビジョニングでは使用できません。Cisco IP Phone はサーバが応答するまで A レコードの処理を続けます。A レコードに関連付けられているサーバが応答しない場合、Cisco IP Phone は syslog サーバにエラーを記録します。
<Syslog Server> パラメータを使用して Cisco IP Phone に syslog サーバが設定されている場合、再同期およびアップグレード操作のメッセージが syslog サーバに送信されます。メッセージは、リモート ファイル リクエスト(設定プロファイルまたはファームウェアのロード)の開始時および操作の終了時に生成できます(成功または失敗を示します)。