Cisco SPA2102-AU Provisioning Guide - Page 41
General Purpose Parameters, Enables, GPP_A through GPP_P. Also - administration guide
View all Cisco SPA2102-AU manuals
Add to My Manuals
Save this manual to your list of manuals |
Page 41 highlights
Chapter 2 Creating Provisioning Scripts Using Provisioning Parameters General Purpose Parameters The general purpose parameters GPP_* are used as free string registers when configuring the SPA to interact with a particular provisioning server solution. The GPP_* parameters are empty by default. They can be configured to contain diverse values, including the following: • Encryption keys • URLs • Multistage provisioning status information • Post request templates • Parameter name alias maps • Partial string values, eventually combined into complete parameter values. The GPP_* parameters are available for macro expansion within other provisioning parameters. For this purpose, single-letter upper-case macro names (A through P) are sufficient to identify the contents of GPP_A through GPP_P. Also, the two-letter upper-case macro names SA through SD identify GPP_SA through GPP_SD as a special case when used as arguments of the key URL option. For example, if GPP_A contains the string ABC, and GPP_B contains 123, the expression $A$B macro expands into ABC123. Enables All profile resync and firmware upgrade operations are controlled by the Provision_Enable and Upgrade_Enable parameters. These parameters control resyncs and upgrades independently of each other. These parameters also control resync and upgrade URL commands issued through the SPA administration web server. Both of these parameters are set to yes by default. In addition, the Resync_From_SIP parameter controls requests for resync operations via a SIP NOTIFY event sent from the service provider proxy server to the SPA. If enabled, the proxy can request a resync by sending a SIP NOTIFY message containing the Event: resync header to the SPA. The SPA challenges the request with a 401 response, and expects an authenticated subsequent request before honoring the resync request from the proxy. The Event: reboot_now and Event: restart_now headers perform cold and warm restarts, respectively, are also challenged. The two remaining enables are Resync_On_Reset and Resync_After_Upgrade_Attempt. These determine if the SPA performs a resync operation after power-up software reboots and after each upgrade attempt. When enabling Resync_On_Reset, the SPA introduces a random delay following the boot-up sequence before actually performing the reset. The delay is a random time up to the value specified in Resync_Random_Delay (in seconds). In a pool of SPA units, all of which are simultaneously powered up, this introduces a spread in the times at which each unit initiates a resync request to the provisioning server. This feature can be useful in a large residential deployment, in the case of a regional power failures. Version 3.0 Linksys SPA Provisioning Guide 2-15