設定ファイルには、次のコンポーネントを含めることができます。

• 要素タグ

• 属性

• パラメータ

• 書式設定機能

• XML コメント

サポートされている圧縮方法は、gzip 圧縮アルゴリズム（RFC1951）です。gzip ユーティリティと、同じアルゴリズム（zlib）を実装する圧縮ライブラリは、インターネット サイトから入手できます。

圧縮を識別するため、Cisco IP Phone は、gzip 互換のヘッダーを含めるための圧縮ファイルを要求します。元のオープン プロファイルで gzip ユーティリティを呼び出すと、ヘッダーが生成されます。Cisco IP Phone は、ダウンロードされたファイル ヘッダーを検査し、ファイル形式を確認します。

たとえば、profile.xml が有効なプロファイルの場合、profile.xml.gz も受け入れられます。次のコマンドのいずれも、このプロファイル タイプを生成できます。

• >gzip profile.xml

  元のファイルを圧縮ファイルと置き換えます。

• >cat profile.xml | gzip > profile.xml.gz

  元のファイルを残したまま、新しい圧縮ファイルを作成します。

圧縮のチュートリアルについては、「プロファイルの gzip 圧縮を開く」のセクションを参照してください。

対称キー暗号化は、ファイルが圧縮されているかどうかにかかわりなく、オープン設定プロファイルの暗号化に使用できます。サポートされる暗号化アルゴリズムは、暗号ブロック連鎖モードで適用される、256 ビット キーを使用する米国の暗号化標準（AES）です。

（注）	圧縮および暗号化されたオープン形式プロファイルを Cisco IP Phone が認識できるようにするため、圧縮を暗号化に先行させる必要があります。「OpenSSL を使用したプロファイル暗号化」セクションは、暗号化に関するチュートリアルを提供しています。

OpenSSL 暗号化ツールは、さまざまなインターネット サイトからダウンロード可能で、暗号化を実行できます。256 ビット AES 暗号化のサポートには、AES コードを有効にするため、ツールの再コンパイルが必要になる場合があります。ファームウェアは、バージョン openssl-0.9.7c でテスト済みです。

暗号化ファイルについては、プロファイルは、次のコマンドによって生成されたものと同じ形式をもつファイルを要求します。

# example encryption key = SecretPhrase1234

openssl enc –e –aes-256-cbc –k SecretPhrase1234 –in profile.xml –out profile.cfg

# analogous invocation for a compressed xml file

openssl enc –e –aes-256-cbc –k SecretPhrase1234 –in profile.xml.gz –out profile.cfg

小文字の -k は、秘密キーに先行します。秘密キーは、いずれかのプレーン テキストの文字列で、ランダムな 64 ビット salt の生成に使用されます。-k 引数で指定された秘密を使用して、暗号化ツールは、ランダムな 128 ビット初期ベクトルと実際の 256 ビット暗号キーを生成します。

この形式の暗号化を設定プロファイルで使用する場合、ファイルを復号できるように、秘密キーの値を電話に知らせる必要があります。この値は、プロファイル URL で修飾子として指定されます。構文は次のとおりで、明示的な URL を使用します。

[--key “SecretPhrase1234”] http://prov.telco.com/path/profile.cfg

この値は、Profile_Rule パラメータのいずれかを使用してプログラムされます。このキーは、先立ってユニットに事前プロビジョニングしておく必要があります。秘密キーのブートストラップは、HTTPS を使用することで安全に実現できます。

対称キー暗号化によるオフラインでの設定プロファイルの事前暗号化により、再同期プロファイルに HTTP を使用することが可能になります。プロビジョニング サーバは、Cisco IP Phone 導入後の最初のプロビジョニングを処理するために HTTPS を使用します。この機能は、大規模導入時の HTTPS サーバの負荷を軽減します。

最終的なファイル名は特定の形式を必要としませんが、通常、.cfg 拡張子で終わるファイル名は設定プロファイルを示します。

オプションの引数である key、uid、および pwd が、角カッコで集合的に囲まれて、Profile_Rule* パラメータに入力した URL の前に付く場合があります。

汎用パラメータ GPP_*（[管理者ログイン（Admin Login）] > [詳細設定（advanced）] > [音声（Voice）] > [プロビジョニング（Provisioning）]）は、特定のプロビジョニング サーバ ソリューションと連携するように Cisco IP Phone を設定するときに、自由文字列のレジスタとして使用されます。GPP_* パラメータは、デフォルトでは空です。これらは、次を含むさまざまな値に設定できます。

• 暗号化キー

• URL

• マルチステージ プロビジョニング ステータス情報

• Post 要求テンプレート

• パラメータ名エイリアス マップ

• 最終的に完全なパラメータ値に組み込まれる部分文字列値。

GPP_* パラメータは、他のプロビジョニング パラメータ内でのマクロ展開に利用できます。この目的のため、GPP_A から GPP_P の内容を識別するには、単一の小文字マクロ名（A から P）があれば十分です。また、2 文字の大文字のマクロ名 SA から SD は、次の URL オプションの引数として使用される特殊なケースとして、GPP_SA から GPP_SD を識別します。

key、uid、および pwd

これらのパラメータは、プロビジョニングとアップグレードのルールで変数として使用できます。$GPP_A など、変数名の前に ‘$’ の文字を付けることにより参照されます。

Provision_Enable および Upgrade_Enable パラメータは、プロファイルの再同期とファームウェア アップグレードの操作すべてを制御します。これらのパラメータは、再同期とアップグレードをそれぞれ個別に制御します。これらのパラメータは、管理 Web サーバによって発行される URL コマンドの再同期とアップグレードも制御します。両方のパラメータは、デフォルトでは [はい（Yes）] に設定されています。

Resync_From_SIP パラメータは、再同期操作を要求します。SIP NOTIFY イベントは、サービス プロバイダーのプロキシ サーバから Cisco IP Phone へ送信されます。有効にすると、プロキシが再同期を要求できるようになります。これを実行するため、プロキシは、Event: resync ヘッダーを含む SIP NOTIFY メッセージをデバイスに送信します。

デバイスは、401 応答（使用したクレデンシャルを理由に認証を拒否）でその要求にチャレンジします。デバイスは、プロキシからの再同期要求を引き受ける前に、認証済みの後続要求を求めます。Event: reboot_now および Event: restart_now ヘッダーは、それぞれコールド再起動とウォーム再起動を実行し、これらもチャレンジを受けます。

残り 2 つのイネーブルは、Resync_On_Reset と Resync_After_Upgrade_Attempt です。これらのパラメータは、電源投入ソフトウェアの再起動と各アップグレード試行の後に、デバイスが再同期操作を実行したかどうかを判定します。

Resync_On_Reset を有効にすると、デバイスは、リセットが実行される前のブートアップ シーケンスに先立って、ランダム遅延を発生させます。この遅延は、Resync_Random_Delay（秒単位）が指定する値を上限とするランダムな時間です。同時に起動する電話のプールの場合、この遅延が、各ユニットからの再同期要求の開始時刻を分散させます。この機能は、地域の停電時に、大規模な宅内導入で役立つ場合があります。

Cisco IP Phone は、特定の間隔で、または特定の時間に再同期することを可能にします。

次のプロビジョニング パラメータを使用して、定期的な再同期のスケジュールを設定することが可能で、再同期およびアップグレードが失敗した場合の再試行間隔も指定できます。

• Resync_Periodic

• Resync_Error_Retry_Delay

• Upgrade_Error_Retry_Delay

各パラメータは、単一の遅延値（秒単位）を受け入れます。新しく展開された構文は、連続的な遅延要素のカンマ区切りリストを許容します。シーケンスの最後の要素は、暗黙的に際限なく繰り返されます。次に例を示します。

Resync_Periodic=7200
Resync_Error_Retry_Delay=1800,3600,7200,14400

前の例では、Cisco IP Phone が 2 時間ごとに定期的に再同期されます。再同期障害が発生すると、デバイスは、30 分、1 時間、2 時間、4 時間の間隔で再試行します。正常に再同期されるまで、デバイスは、4 時間間隔で試行し続けます。

次の例のとおり、必要に応じて、プラス記号を使用して、ランダムな追加の遅延を付加する別の数値を指定することもできます。

Resync_Periodic=3600+600
Resync_Error_Retry_Delay=1800+300,3600+600,7200+900

前の例で、デバイスは、1 時間（プラス最大 10 分の追加のランダム遅延）ごとに定期的に再同期されます。再同期障害が発生すると、デバイスは、次の間隔で再試行します。30 分（プラス 最大 5 分）。1 時間（プラス 最大 10 分）、2 時間（プラス最大 15 分）。正常に再同期されるまで、デバイスは、2 時間間隔（プラス最大 15 分）で試行し続けます。

別の例を示します。

Upgrade_Error_Retry_Delay  =  1800,3600,7200,14400+3600

この例では、リモート アップグレードに失敗した場合、デバイスは、30 分後にアップグレードを再試行し、次に 1 時間後、次は 2 時間後に再試行します。それでもアップグレードに失敗する場合、デバイスは、アップグレードが成功するまで、4 時間から 5 時間ごとに再試行します。

Cisco IP Phone は、複数のリモート設定プロファイルパラメータ（Profile_Rule*）を提供します。そのため、各再同期操作は、異なるサーバが管理する複数のファイルを取得できます。

最も簡単なシナリオでは、デバイスは、関係するすべての内部パラメータを更新する、中央サーバの単一のプロファイルに対して定期的に再同期されます。そうでない場合、プロファイルを異なるファイルの間で分割することができます。1 つのファイルは、導入時の Cisco IP Phone すべてに対して共通のファイルになります。他とは異なる固有のファイルが各アカウントに提供されます。暗号キーと証明書情報は、別のサーバに保存されている、さらに別のプロファイルから取得することも可能です。

再同期操作の時間になると、Cisco IP Phone は、4 つの Profile_Rule* パラメータを順に評価します。

1. Profile_Rule

2. Profile_Rule_B

3. Profile_Rule_C

4. Profile_Rule_D

各評価の結果、リモート プロビジョニング サーバからプロファイルが取得され、いくつかの内部パラメータのアップデートが発生する可能性があります。評価が失敗すると、再同期シーケンスは中断され、Resync_Error_Retry_Delay パラメータ（秒単位）によって指定された開始時間から再試行されます。すべての評価が成功すると、デバイスは、Resync_Periodic パラメータで指定された秒数の間待機した後、次の再同期を実行します。

各 Profile_Rule* パラメータの内容は、一連の選択肢で構成されます。それらの選択肢は、|（パイプ）文字で区切られます。各選択肢は、条件式、割り当て式、プロファイルの URL、および関連 URL のオプションで構成されています。これらすべてのコンポーネントは、各選択肢内のオプションです。次に示すのは、オプションの有効な組み合わせと、それらが存在する場合に従わなければならない表示順序です。

[ conditional-expr ] [ assignment-expr ] [[ options ] URL ]

各 Profile_Rule* パラメータ内で、最後の 1 つを除くすべての選択肢は、条件式を示す必要があります。この式は、次のように評価され処理されます。

1. 条件は、true と評価されるものが見つかるまで（または条件式を含まない 1 つの選択肢が見つかるまで）、左から右に評価されます。

2. いずれかの割り当て式を伴う場合には、それも評価されます。

3. 選択肢の一部として URL が指定される場合、指定された URL にあるプロファイルのダウンロードが試行されます。システムは、内部パラメータの更新を状況に応じて試行します。

すべての選択肢が条件式を含むものの、いずれも true と評価されない場合（またはプロファイル ルール全体が空の場合）、Profile_Rule* パラメータの全体がスキップされます。シーケンス内の次のプロファイル ルール パラメータが評価されます。

http://remote.server.com/cisco/$MA.cfg

($PRVTMR ge 600)? http://p.tel.com/has-reg.cfg
| [--post a] http://p.tel.com/lost-reg?

(“$CCERT” eq “Installed”)? https://p.tel.com/config?
| https://p.tel.com/config?cisco$MAU

(“$A” ne “Provisioned”)? (Line_Enable_1_ = “No”;)! https://p.tel.com/init-prov
| https://p.tel.com/configs

[--alias b] https://p.tel.com/account/$PN$MA.xml

アップグレード ルールは、必要に応じて新しい負荷に対して、その負荷がかかる場所からアクティブ化するようにデバイスに通知します。デバイスに負荷がすでにかかっている場合、その負荷を取得しようとしません。したがって、負荷の場所の有効性は、必要な負荷が非アクティブなパーティションにある場合は問題になりません。

Upgrade_Rule はファームウェアの負荷を指定します。これは、現在の負荷とは異なり、条件式または Upgrade_Enable が No に設定されていない限り、ダウンロードされ、適用されます。

Cisco IP Phone は、Upgrade_Rule という 1 つの設定可能リモート アップグレード パラメータを提供します。このパラメータは、プロファイル ルール パラメータと類似した構文を受け入れます。URL オプションは、アップグレードではサポートされませんが、条件式と割り当て式は使用できます。条件式を使用すると、| 文字で区切られた複数の選択肢をパラメータに含めることができます。各選択肢の構文は次のとおりです。

[ conditional-expr ] [ assignment-expr ] URL

Profile_Rule* パラメータの場合、Upgrade_Rule パラメータは、条件式の要件が満たされるか、選択肢が条件式を含まなくなるまで、各選択肢を評価します。付属の割り当て式が指定されている場合、それも評価されます。次に、指定された URL に対するアップグレードが試行されます。

Upgrade_Rule が条件式を含まない URL を含む場合、デバイスは、URL の指定するファームウェア イメージに対してアップグレードを実行します。マクロ展開とルールの評価の後、デバイスは、ルールが変更されるか、scheme + server + port + filepath の有効な組み合わせが変更されるまで、アップグレードを再試行しません。

ファームウェア アップグレードを試行する際、デバイスは、手順の最初に音声を無効にし、手順の最後にリブートします。デバイスは、すべての音声回線が現在非アクティブになっている場合に限って、Upgrade_Rule の内容によって引き起こされるアップグレードを自動的に開始します。

http://p.tel.com/firmware/sip7832.11-0-1MPP-BN (BN==Build Number).loads

この例では、Upgrade_Rule は、指定された URL に保存されたイメージに対してファームウェアをアップグレードします。

(“$F” ne “beta-customer”)? http://p.tel.com/firmware/sip7832.11-0-1MPP-BN (BN==Build Number).loads
| http://p.tel.com/firmware/sip7832.11-0-1MPP-BN (BN==Build Number).loads

この例では、汎用パラメータ GPP_F の内容に基づいて、2 つのイメージのいずれかをロードするようユニットに指示します。

デバイスは、便利なカスタマイズ オプションとなり得る、ファームウェア リビジョン番号に関するダウングレード制限を設定できます。有効なファームウェア リビジョン番号が Downgrade_Rev_Limit パラメータで設定されると、デバイスは、指定された制限よりも前のファームウェア バージョンに対するアップグレードの試行を拒否します。