この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
サービス プロバイダーはプロファイルを使用して、RC ユニット以外に Cisco IP Phone のプロビジョニングを行います。プロビジョニング プロファイルには、Cisco IP Phone を再同期するためのパラメータをある程度含めることができます。プロファイルには、リモート サーバから提供されるすべてのパラメータが記載できます。デフォルトでは、電源投入時と、プロファイルで設定された間隔で、Cisco IP Phone が再同期を行います。ユーザが顧客の環境で Cisco IP Phone に接続すると、デバイスは更新されたプロファイルとすべてのファームウェアのアップデートをダウンロードします。
本章の例では、1 台以上のサーバが必要です。以下のサーバをローカル PC にインストールして実行できます。
サーバの構成でのトラブルシューティングを容易にするために、サーバのタイプごとに、クライアントを別のサーバ マシンにインストールしてください。このプラクティスでは、Cisco IP Phone との相互通信とは無関係に、サーバの動作を適切に設定します。
また、次のソフトウェア ツールをインストールすることをお勧めします。
プロファイルの暗号化および HTTPS 動作を使用する場合には、オープン ソースの OpenSSL ソフトウェア パッケージをインストールします。
HTTPS を使用して、ダイナミック プロファイル生成とワンステップ リモート プロビジョニングをテストする場合には、CGI スクリプトをサポートするスクリプト言語のインストールを推奨します。そのようなスクリプト言語には、オープン ソースの Perl 言語ツールなどがあります。
プロビジョニング サーバと Cisco IP Phone 間の安全なデータ交換を確認する場合には、イーサネット パケット スニファ(無料でダウンロード可能な Ethereal/Wireshark など)をインストールします。Cisco IP Phone とプロビジョニング サーバ間の相互通信におけるイーサネット パケット トレースを採取します。このためには、ポートのミラーリングが有効になっているスイッチに接続している PC で、パケット スニファを実行します。HTTPS トランザクションの場合には、ssldump ユーティリティが使用できます。
すべての 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-7832-3PCC などの電話機のモデル名が入ります。たとえば、CP-7832-3PCC の場合、ファイル名は CP-7832-3PCC.cfg になります。プロファイルが工場出荷時設定のままのデバイスは、電源投入後、DHCP オプション 66 で指定されたローカル TFTP サーバにあるこのファイルと再同期します(ファイルパスは、TFTP サーバ仮想ルート ディレクトリへの相対パスです)。
Cisco IP Phone は、ネットワーク アドレス変換(NAT)と互換性があり、ルータ経由でインターネットにアクセスします。セキュリティを強化するため、ルータは、Symmetric NAT(インターネットから、保護されたネットワークに入ることを許可されるパケットを厳格に制限するパケット フィルタリング方針)の実装により、不正な受信パケットのブロックを試みる可能性があります。したがって、TFTP を使用したリモート プロビジョニングは推奨しません。
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 フィールドに基本識別情報を自動的に入力します。この情報には、デバイスの製造者、製品名、現行のファームウェア バージョン、および製品シリアル番号が含まれています。
User-Agent: Cisco-CP-7832-3PCC/11.0.1 (00562b043615)
Cisco IP Phone が HTTP を使用して設定プロファイルと再同期するよう設定されている場合、機密情報を保護するために HTTPS を使用するか、プロファイルを暗号化することを推奨します。Cisco IP Phone では、プロファイルの暗号化に CBC モードの 256 ビット AES をサポートしています。HTTP を使用して Cisco IP Phone によりダウンロードされるプロファイルを暗号化すれば、設定プロファイル内の機密情報が漏えいする危険性が回避されます。この再同期モードでは、プロビジョニング サーバの処理負荷が HTTPS を使用するよりも少なくなります。
(注) | Cisco IP Conference Phone 7832 Multiplatform Phone は、HTTP Version 1.0、HTTP 1.1 をサポートします。また、HTTP Version 1.1 がネゴシエート トランスポート プロトコルの場合にはチャンク エンコードをサポートします。 |
HTTP ステータス コード |
説明 |
電話機の動作 |
---|---|---|
301 Moved Permanently |
このリクエストおよび以降のリクエストは、新しい場所に向けて送信する必要があります。 |
新しい場所を使用してリクエストをすぐに再試行します。 |
302 Found |
一時的に移動されています。 |
新しい場所を使用してリクエストをすぐに再試行します。 |
3xx |
その他の 3xx 応答は処理されません。 |
C |
400 Bad Request |
シンタックスが無効なため、要求を処理できません。 |
C |
401 Unauthorized |
基本またはダイジェストのアクセス認証チャレンジ。 |
認証情報を使用してリクエストをすぐに再試行します。最大 2 回試行します。これが失敗すると、電話機の動作は C です。 |
403 Forbidden |
サーバが応答を拒否しました。 |
C |
404 Not Found |
リクエストされたリソースが見つかりません。これに続くクライアントからのリクエストは問題なく処理されます。 |
B |
407 Proxy Authentication Required |
基本またはダイジェストのアクセス認証チャレンジ。 |
認証情報を使用してリクエストをすぐに再試行します。最大 2 回試行します。これが失敗すると、電話機の動作は C です。 |
4xx |
その他のクライアント エラー ステータス コードは処理されません。 |
C |
500 Internal Server Error |
一般的なエラー メッセージ。 |
Cisco IP Phone の動作は C です。 |
501 Not Implemented |
サーバがリクエスト方法を認識しない、またはリクエストを実行する機能がありません。 |
Cisco IP Phone の動作は C です。 |
502 Bad Gateway |
サーバがゲートウェイまたはプロキシとして動作している場合に、アップストリーム サーバから無効な応答を受信しました。 |
Cisco IP Phone の動作は C です。 |
503 Service Unavailable |
サーバは現在使用できません(過負荷状態またはメンテナンスのためダウンしています)。これは一時的なステートです。 |
Cisco IP Phone の動作は C です。 |
504 Gateway Timeout |
サーバがゲートウェイまたはプロキシとして動作している場合に、アップストリーム サーバから適切なタイミングで応答を受信しませんでした。 |
C |
5xx |
その他のサーバ エラー |
C |
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 エントリの例です。
CN=sprov.callme.com CN=pv.telco.net/mailto:admin@telco.net CN=prof.voice.com/info@voice.com
サーバ証明書の確認に加えて、Cisco IP Phone は、サーバ証明書で指定されたサーバ名の DNS ルックアップにより、サーバ IP アドレスをテストします。
OpenSSL ユーティリティは証明書署名要求を生成できます。次の例は、1024 ビット RSA の公開キー/秘密キーのペアおよび証明書署名要求を生成する openssl コマンドを示しています。
openssl req –new –out provserver.csr
このコマンドにより、サーバの秘密キーが privkey.pem に、対応する証明書署名要求が provserver.csr にそれぞれ生成されます。サービス プロバイダーは、privkey.pem を秘密にして、provserver.csr を署名のために Cisco に提出します。シスコは provserver.csr ファイルを受信すると、署名されたサーバ証明書として provserver.crt を生成します。
署名済みサーバ証明書を取得するには、次のようにします。
ステップ 1 | 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)]、[SPA5xx ファームウェア 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 | 署名済み証明書を受け取るには、次のいずれかのオプションを選択します。 |
ステップ 8 | [送信(Submit)] をクリックします。 次に、署名済みサーバ証明書は、以前に指定された電子メール アドレスに電子メールで送信されるか、ダウンロードされます。 |
Cisco はまた、サービス プロバイダーに Sipura CA クライアント ルート証明書も提供します。このルート証明書により、それぞれの Cisco IP Phone が保持するクライアント証明書が本物であることが保証されます。Cisco IP Conference Phone 7832 マルチプラットフォーム電話機は、Verisign、Cybertrust などが提供するサードパーティの署名済み証明書もサポートします。
OU=CP-7832-3PCC, L=88012BA01234, S=000e08abcdef
ファームウェア 2.0.x より前に製造されたユニットには、個別の SSL クライアント証明書が含まれていません。これらのユニットが 2.0.x ツリーのファームウェア リリースにアップグレードされると、HTTPS を使用しているセキュア サーバに接続できるようになりますが、サーバがユニットにクライアント証明書を要求した場合には、ユニットは一般的なクライアント証明書だけを提供できます。この一般的な証明書には、識別子フィールドに次の情報が含まれます。
OU=cisco.com, L=ciscogeneric, S=ciscogeneric
Cisco IP Phone が個別の証明書を保持するかどうかを決定するには、$CCERT プロビジョニング マクロ変数を使用します。変数の値は、固有のクライアント証明書の有無に従って、インストールまたはインストールなしのいずれかに展開されます。一般的な証明書の場合、HTTP リクエスト ヘッダーの User-Agent フィールドからユニットのシリアル番号が取得できます。
HTTPS サーバを設定して、接続しているクライアントから SSL 証明書をリクエストすることができます。これを有効にすると、サーバは Cisco が提供する Sipura CA クライアント ルート証明書を使用して、クライアント証明書を確認できます。その後、サーバは、以降のプロビジョニングで CGI に証明書情報を提供できます。
証明書を保存する場所はさまざまです。たとえば、Apache をインストールした場合には、プロビジョニング サーバにより署名された証明書や、関連付けられた秘密キー、Sipura CA クライアント ルート証明書の保存場所のファイル パスは以下のようになります。
# Server Certificate: SSLCertificateFile /etc/httpd/conf/provserver.crt # Server Private Key: SSLCertificateKeyFile /etc/httpd/conf/provserver.key # Certificate Authority (CA): SSLCACertificateFile /etc/httpd/conf/spacroot.crt
個別の情報については、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 サーバに送信されます。メッセージは、リモート ファイル リクエスト(設定プロファイルまたはファームウェアのロード)の開始時および操作の終了時に生成できます(成功または失敗を示します)。