この製品のドキュメントセットは、偏向のない言語を使用するように配慮されています。このドキュメントセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブ ランゲージの取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
サービス プロバイダーは、プロファイルを使用して、RC ユニット以外で、電話機を事前プロビジョニングします。 事前プロビジョニング プロファイルには、電話機を再同期するための制限されたパラメータを含めることができます。 プロファイルには、リモート サーバーで提供されるすべてのパラメータを含めることもできます。 デフォルトでは、電話機は電源投入時に、プロファイルで設定された間隔で再同期します。 ユーザーが顧客宅内の電話機に接続すると、デバイスは更新されたプロファイルとすべてのファームウェア アップデートをダウンロードします。
この事前プロビジョニング、導入、およびリモート プロビジョニングのプロセスには、さまざまな方法があります。
この章の例では、1 台以上のサーバーが使用可能であることが必要です。 以下のサーバーをローカル PC にインストールして実行できます。
TFTP（UDP ポート 69）
syslog（UDP ポート 514）
HTTP（TCP ポート 80）
HTTPS（TCP ポート 443）
サーバーの構成をトラブルシューティングする場合は、サーバーのタイプごとに、クライアントを別のサーバー マシンにインストールすると便利です。 この方法により、電話機との通信に関係なく、適切なサーバー動作になります。
また、次のソフトウェア ツールをインストールすることをお勧めします。
設定プロファイルを生成するために、オープン ソースの gzip 圧縮ユーティリティをインストールします。
プロファイルの暗号化および HTTPS 操作用に、オープン ソースの OpenSSL ソフトウェア パッケージをインストールします。
HTTPS を使用してダイナミック プロファイルの生成とワンステップのリモート プロビジョニングをテストするには、CGI スクリプトをサポートするスクリプト言語をお勧めします。 オープン ソースの Perl 言語ツールは、このようなスクリプト言語の一例です。
プロビジョニング サーバーと電話機の間の安全な交換を確認するには、イーサネット パケット スニファ（無料でダウンロード可能な Ethereal/Wireshark など）をインストールします。 電話機とプロビジョニング サーバー間の相互通信のイーサネット パケット トレースをキャプチャします。 これを行うには、ポート ミラーリング対応のスイッチに接続されている PC でパケット スニファを実行します。 HTTPS トランザクションの場合は、ssldump ユーティリティを使用できます。
すべての電話機は、最初にプロビジョニングされるまで Cisco EDOS RC サーバーに接続します。
RC 配信モデルでは、顧客はすでに Cisco EDOS RC サーバーの特定のサービス プロバイダーに関連付けられている電話機を購入します。 インターネット電話サービス プロバイダー（ITSP）は、プロビジョニング サーバーを設定および保持し、それらのプロビジョニング サーバーの情報を Cisco EDOS RC サーバーに登録します。
インターネットに接続して電話機の電源を投入すると、プロビジョニングされていない電話機の [カスタマイズ状態（Customization State）] は [オープン（Open）] になります。 電話機は最初にローカル DHCP サーバーにプロビジョニング サーバー情報を照会し、電話機のカスタマイズ状態を設定します。 DHCP クエリが成功すると、[カスタマイズ状態（Customization State）] は、[中止（Aborted）] となり、DHCP が必要なプロビジョニング サーバー情報を提供するため RC は試行されません。
電話機を初めてネットワークに接続する場合、または初期設定へのリセット後にネットワークに接続する場合に、セットアップされている DHCP オプションがないと、電話機はゼロ タッチ プロビジョニングのためにデバイス アクティベーション サーバーに接続します。 新しい電話機は、プロビジョニングに "webapps.cisco.com" の代わりに "activate.cisco.com" を使用します。 11.2(1) より前のファームウェアを搭載している電話機は、引き続き webapps.cisco.com を使用します。 ファイアウォールで両方のドメイン名を許可することが推奨されます。
DHCP サーバーがプロビジョニングに失敗した場合、電話機は Cisco EDOS RC サーバーに照会して、その MAC アドレスとモデルを指定し、[カスタマイズ状態（Customization State）] は [保留中（Pending）] に設定されます。 Cisco EDOS サーバーは、プロビジョニング サーバーの URL を含む、関連付けられたサービス プロバイダーのプロビジョニング サーバー情報で応答し、電話機の [カスタマイズ状態（Customization State）] は、[カスタム保留中（Custom Pending）] に設定されます。 電話機は、resync URL コマンドを実行してサービス プロバイダーの設定を取得し、成功すると、[カスタマイズ状態（Customization State）] は、[取得済み（Acquired）]になります。 ローカル DHCP サーバーまたは EDOS サーバーに対するクエリでプロビジョニングが失敗した場合、電話機は DHCP および EDOS でオンボードを再試行します。
Cisco EDOS RC サーバーに、電話機に関連付けられているサービス プロバイダーがない場合、電話機の [カスタマイズ状態（Customization State）] は [利用不可（Unavailable）]になります。 電話機を手動で設定するか、電話機のサービス プロバイダーの場合は Cisco EDOS サーバーに関連付けを追加できます。
電話機が LCD または Web 設定ユーティリティでプロビジョニングされた場合、[カスタマイズ状態（Customization State）] が [取得済み（Acquired）]になる前に、[カスタマイズ状態（Customization State）] は [中止（Aborted）] に設定され、電話機が初期設定にリセットされない限り、Cisco EDOS サーバーは照会されません。
電話機がプロビジョニングされている場合、電話機が初期設定にリセットされない限り、Cisco EDOS RC サーバーは使用できません。
シスコの工場出荷時のデフォルト設定により、電話機は TFTP サーバーのプロファイルと自動的に再同期を試みます。 LAN 上で管理される DHCP サーバーは、プロファイルに関する情報と、デバイスへの事前プロビジョニング用に設定された TFTP サーバーに関する情報を提供します。 サービス プロバイダーは、新しい電話機をそれぞれ LAN に接続します。 電話機はローカルの TFTP サーバーと自動的に再同期して、内部の状態を導入準備に初期化します。 この事前プロビジョニング プロファイルには通常、リモート プロビジョニング サーバーの URL が含まれます。 プロビジョニング サーバーは、デバイスが導入されて顧客ネットワークに接続された後、デバイスの更新を継続します。
電話機が顧客に出荷される前に、事前プロビジョニング済みデバイスのバー コードをスキャンしてその MAC アドレスまたはシリアル番号を記録できます。 この情報は、電話機が再同期するプロファイルを作成するために使用できます。
顧客は電話機を受け取ると、ブロードバンド リンクにそれを接続します。 電源を投入すると、電話機は事前プロビジョニングで設定された URL を使ってプロビジョニング サーバーに接続します。 これで電話機は、必要に応じてプロファイルやファームウェアを再同期して更新できます。
このセクションでは、さまざまなサーバーやシナリオを使用して電話機をプロビジョニングする際の設定要件を説明します。 このドキュメントおよびテスト目的において、プロビジョニング サーバーはローカル PC にインストールされ、実行されます。 また、一般的に利用できるソフトウェア ツールは、電話機のプロビジョニングに役立ちます。
電話機は、プロビジョニングの再同期とファームウェア アップグレード両方の操作で TFTP をサポートします。 デバイスをリモートで導入する場合、HTTPS が推奨されますが、HTTP や TFTP も使用できます。 次に、ファイル暗号化をプロビジョニングしてセキュリティを強化します。NAT やルータ保護機能があれば、信頼性が高まります。 TFTP は、プロビジョニングされていない多数のデバイスを社内で事前にプロビジョニングする場合に役立ちます。
電話機は、DHCP オプション 66 を使用して DHCP サーバーから直接 TFTP サーバーの IP アドレスを取得することができます。その TFTP サーバーのファイルパスを使用して Profile_Rule を設定している場合、デバイスは TFTP サーバーからそのプロファイルをダウンロードします。 ダウンロードは、デバイスが LAN に接続されているときに、電源投入時に実行されます。
工場出荷時のデフォルト設定で提供される Profile_Rule は ata$PSN.cfg です。この $PSN は製品シリアル番号を表します。
たとえば、ATA192-MPP の場合、ファイル名は ata192.cfg です。
工場出荷時のプロファイルを使用するデバイスの場合、電源投入時に、DHCP オプション 66 で指定したローカル TFTP サーバー上のこのファイルと再同期します。 ファイルパスは、TFTP サーバーの仮想ルート ディレクトリへの相対パスです。
電話機はネットワーク アドレス変換（NAT）と互換性があり、ルータ経由でインターネットにアクセスします。 セキュリティを強化するため、ルータは、Symmetric NAT（インターネットから、保護されたネットワークに入ることを許可されるパケットを厳格に制限するパケットフィルタリング方針）の実装により、不正な着信パケットのブロックを試みる可能性があります。 このため、TFTP を使用するリモート プロビジョニングはお勧めできません。
サービスのダイナミックな外部（パブリック）IP アドレス
STUN サーバー ソフトウェアを実行しているコンピュータ
Asymmetric NAT 機能を備えたエッジ デバイス
電話機は、リモート インターネット サイトの Web ページを要求するブラウザのように動作します。 これにより、顧客のルータに Symmetric NAT や他の保護機能が実装されている場合でも、プロビジョニング サーバーと通信するための信頼性の高い手段が提供されます。 リモートの導入では、特に導入するユニットが社内のファイアウォールや NAT が有効なルータの背後で接続されている場合は、TFTP よりも HTTP や HTTPS の方が信頼性が高くなります。 HTTP と HTTPS は次の要求タイプの説明では同じ意味に使用されます。
基本の HTTP ベースのプロビジョニングは、HTTP GET メソッドに依存して設定プロファイルを取得します。 通常、導入されている電話機ごとに 1 つの設定ファイルが作成され、これらのファイルは HTTP サーバー ディレクトリ内に保存されます。 サーバーは GET 要求を受け取ると、GET 要求ヘッダーで指定されるファイルを単純に返します。
カスタマー データベースを照会してプロファイルをすぐに作成することで、静的プロファイルよりも、設定プロファイルを動的に生成できます。
電話機は、再同期を要求するときに、HTTP POST メソッドを使用して再同期設定データを要求できます。 デバイスを設定して、特定のステータスと識別情報を HTTP POST 要求の本文に含めてサーバーに送信できます。 サーバーはこの情報を使用して必要な応答設定ファイルを生成したり、状態情報を保存して後から分析やトラッキングを実行したりできます。
GET および POST 要求の両方の一部として、電話機は要求ヘッダーの User-Agent フィールドに基本識別情報を自動的に含めます。 この情報で、デバイスの製造者、製品名、現在のファームウェア バージョン、および製品シリアル番号を伝えます。
User-Agent: Cisco/ATA192-MPP-11-1-0MPP-16(FCH2118DGQP)
ユーザーエージェントは設定可能であり、設定されていない場合、電話機はこの値を使用します (デフォルト)。
電話機が HTTP を使用して設定プロファイルと再同期するように設定されている場合は、秘密情報を保護するために HTTPS を使用するか、プロファイルを暗号化することをお勧めします。 HTTP を使用してダウンロードするプロファイルは、暗号化することで、設定ファイルに含まれている秘密情報が漏洩される危険性を防ぐことができます。 この再同期モードでは、プロビジョニング サーバーの処理負荷が HTTPS を使用する場合に比べて少なくなります。
電話機は、プロファイルの復号に CBC モードの 256 ビット AES をサポートしています。
 （注） |
電話機は、HTTP Version 1.0 と HTTP Version 1.1 をサポートし、HTTP Version 1.1 がネゴシエート トランスポート プロトコルの場合にはチャンク エンコードをサポートします。 |
A：成功。この場合、[定期再同期（Resync Periodic）] 値および [再同期ランダム遅延（Resync Random Delay）] 値により以降の要求が決定します。
B：ファイルが見つからない、またはプロファイルの破損による失敗。 [再同期エラー再試行遅延（Resync Error Retry Delay）] 値により以降の要求が決定します。
C：不正な URL または IP アドレスによる接続エラーが発生したことによるその他の失敗。 [再同期エラー再試行遅延（Resync Error Retry Delay）] 値により以降の要求が決定します。
|
HTTP ステータス コード |
説明 |
電話機の動作 |
|---|---|---|
|
301 Moved Permanently |
この要求と以降の要求は新しい場所に送信する必要があります。 |
新しい場所で要求をすぐに再試行します。 |
|
302 Found |
一時的な移動です。 |
新しい場所で要求をすぐに再試行します。 |
|
3xx |
他の 3 xx 応答は処理されません。 |
C |
|
400 Bad Request |
シンタックスが無効なため、要求を処理できません。 |
C |
|
401 Unauthorized |
基本またはダイジェストのアクセス認証チャレンジ。 |
認証情報を使用して要求をすぐに再試行します。 最大 2 回再試行できます。 失敗した場合、電話機の動作は C です。 |
|
403 Forbidden |
サーバーが応答を拒否しています。 |
C |
|
404 Not Found |
要求されたリソースが見つかりません。 以降のクライアントからの要求は許可されます。 |
B |
|
407 プロキシ認証が必要 |
基本またはダイジェストのアクセス認証チャレンジ。 |
認証情報を使用して要求をすぐに再試行します。 最大 2 回再試行できます。 失敗した場合、電話機の動作は C です。 |
|
4xx |
他のクライアント エラー ステータス コードは処理されません。 |
C |
|
500 内部サーバー エラー |
一般的なエラー メッセージ。 |
電話機の動作は C です。 |
|
501 実装されない |
サーバーが要求方法を認識しないか、要求を実行する機能がありません。 |
電話機の動作は C です。 |
|
502 不正なゲートウェイ |
サーバーはゲートウェイまたはプロキシとして動作し、アップストリーム サーバーから無効な応答を受信しています。 |
電話機の動作は C です。 |
|
503 サービスは利用不可です |
サーバーは現在使用できません（メンテナンスのため過負荷状態またはダウンしています）。 これは一時的な状態です。 |
電話機の動作は C です。 |
|
504 Gateway Timeout |
サーバーはゲートウェイまたはプロキシとして動作し、アップストリーム サーバーから適切なタイミングで応答を受信しません。 |
C |
|
5xx |
その他のサーバー エラー |
C |
電話機は、リモートに導入されたユニットを管理する際のセキュリティを強化するために、プロビジョニング用に HTTPS をサポートします。 各電話機は、Sipura CA サーバー ルート証明書に加えて、固有の SLL クライアント証明書（および関連付けられた秘密キー）を保持します。 ルート証明書を使って、電話機は認証されたプロビジョニング サーバーを認識し、認証されていないサーバーを拒否できます。 一方、クライアント証明書を使うと、プロビジョニング サーバーは要求を発行した個々のデバイスを識別できます。
HTTPS を使用して導入を管理するサービス プロバイダーでは、HTTPS を使用した電話機の再同期先となるプロビジョニング サーバーごとにサーバー証明書を生成する必要があります。 サーバー証明書はシスコ サーバーの CA ルート キーで署名される必要があります。導入済みのすべてのユニットはすべての証明書を保持します。 署名されたサーバー証明書を取得するには、サービス プロバイダーが証明書署名要求をシスコに送信します。シスコはプロビジョニング サーバーへのインストール用にサーバー証明書に署名して返送します。
プロビジョニング サーバー証明書には、共通名（CN）フィールドと、対象内でサーバーを実行しているホストの FQDN を含める必要があります。 オプションで、ホストの FQDN に続く情報をスラッシュ（/）文字で区切って含めることができます。 次の例は、電話機で有効として受け入れられる CN エントリです。
CN=sprov.callme.com
CN=pv.telco.net/mailto:admin@telco.net
CN=prof.voice.com/info@voice.com
電話機では、サーバー証明書の検証に加えて、サーバー証明書で指定されたサーバー名の DNS ルックアップに対してサーバー IP アドレスをテストします。
OpenSSL ユーティリティで、証明書署名要求を生成できます。 次の例は、1024 ビットの RSA 公開キーと秘密キーのペアおよび証明書署名要求を生成する openssl コマンドを示しています。
openssl req –new –out provserver.csr
このコマンドでは、privkey.pem と対応する証明書署名要求 provserver.csr にサーバーの秘密キーが生成されます。 サービス プロバイダーは、privkey.pem 秘密キーを維持し、署名のために provserver.csr をシスコに提出します。 provserver.csr ファイルを受信すると、シスコは署名付きサーバー証明書 provserver.crt を生成します。
|
ステップ 1 |
https://software.cisco.com/software/cda/home に移動し、CCO クレデンシャルでログインします。
|
||
|
ステップ 2 |
[証明書の管理（Certificate Management）]を選択します。 [CSRの署名（Sign CSR）]タブで、前の手順の CSR を署名用にアップロードします。 |
||
|
ステップ 3 |
[製品の選択（Select Product）] ドロップダウン リスト ボックスから [SPA1xxファームウェア1.3.3以降（SPA1xx firmware 1.3.3 and newer）]、[SPA232Dファームウェア1.3.3以降（SPA232D firmware 1.3.3 and newer）]、[SPA5xxファームウェア7.5.6以降（SPA5xx firmware 7.5.6 and 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）]をクリックします。 署名付きサーバー証明書は、前に指定した電子メール アドレスに送信されるか、ダウンロードされます。 |
シスコは、サービス プロバイダーにマルチプラットフォーム フォンのクライアント ルート証明書も提供しています。 このルート証明書により、各電話機で保持されるクライアント証明書が本物であることが証明されます。 マルチプラットフォーム フォンは、Verisign、Cybertrust などで提供される証明書のように、サードパーティの署名付き証明書もサポートします。
各デバイスが HTTPS セッション中に提供する固有のクライアント証明書では、その件名フィールドに識別情報が埋め込まれています。 この情報は、HTTPS サーバーを介して、安全な要求を処理するために起動される CGI スクリプトで使用できます。
電話機が個別の証明書を保持するかどうかを判断するには、$CCERT プロビジョニング マクロ変数を使用します。 変数の値は、固有のクライアント証明書の有無に従って、Installed または Not Installed のいずれかに展開されます。 一般的な証明書の場合は、User-Agent フィールドの HTTP 要求ヘッダーからユニットのシリアル番号を取得できます。
HTTPS サーバーを設定して、接続しているクライアントに SSL 証明書を要求することができます。 これを有効にすると、サーバーは、シスコが提供するマルチプラットフォーム フォンのクライアント ルート証明書を使用してクライアント証明書を検証できます。 その後、サーバーは、以降の処理のために証明書情報を CGI に提供できます。
証明書の保存場所はさまざまです。 たとえば、Apache をインストールした場合には、プロビジョニング サーバーの署名付き証明書、関連付けられた秘密キー、マルチプラットフォーム フォン 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 サーバーの資料を参照してください。
シスコのクライアント証明書ルート認証局が、独自の証明書にそれぞれ署名します。 関連するルート証明書が作成され、クライアント認証の目的でサービス プロバイダーがそれを利用できるようになります。
プロビジョニング サーバーは、IP アドレスまたは完全修飾ドメイン名（FQDN）で指定できます。 FQDN を使用すると、冗長なプロビジョニング サーバーの導入が容易になります。 プロビジョニング サーバーが FQDN によって識別される場合、電話機は DNS を介して FQDN を IP アドレスに解決しようとします。 プロビジョニングでは DNS A レコードのみサポートされます。DNS SRV のアドレス解決はプロビジョニングには使用できません。 電話機は、サーバーが応答するまで A レコードの処理を続行します。 A レコードの応答にサーバーが関連付けられていない場合、電話機は syslog サーバーにエラーを記録します。
ATA は、最大 10 件の DNS A レコードを DNS SRV レコードに関連付けることができます。
<Syslog Server> パラメータを使用して syslog サーバーを電話機に設定している場合、再同期およびアップグレード操作のメッセージが syslog サーバーに送信されます。 メッセージはリモート ファイル要求の開始時（設定プロファイルまたはファームウェアのロード）、および操作の完了時（成功または失敗を示す）に生成できます。
ログに記録されたメッセージは次のパラメータで設定され、実際の syslog メッセージにマクロ展開されます。
Log_Resync_Request_Msg
Log_Resync_Success_Msg
Log_Resync_Failure_Msg
フィードバック