© 2003 - 2005 Sipura Technology, Inc
Proprietary (See Copyright Notice on Page 2)
31
The SPA can be configured to upgrade to a specific version, possibly staging through intermediate
releases, if necessary. This process can be automated for a pool of devices through configuration
profile parameters.
Alternatively, an individual SPA can be directed to perform an upgrade to a specific firmware load via
its built-in web server interface (this mechanism is discussed in section 3.4.4.1 of this document).
Firmware upgrades are attempted only when the SPA is idle, since they trigger a software reboot.
3.1.4. Upgrade
Parameters
Firmware upgrades are controlled by the following parameters (which operate in a manner similar to
but independent of the provisioning parameters).
•
Upgrade_Enable
•
Upgrade_Error_Retry_Delay
•
Upgrade_Rule
•
Log_Upgrade_Request_Msg
•
Log_Upgrade_Success_Msg
•
Log_Upgrade_Failure_Msg
Upgrade Enable:
ParName: Upgrade_Enable
Default: Enable
The firmware file must be requested by the SPA and cannot be pushed from an upgrade server
(although a service provider can effectively push a new firmware load by triggering the request
operation remotely via the CFG file). The functionality is controlled by the Upgrade_Enable
parameter. The parameter enables the functionality encompassed by the remaining upgrade
parameters.
In addition, Upgrade_Enable also gates the ability to issue an explicit upgrade command from the
web interface (discussed in section 3.4.4.1 of this document).
Upgrade Error Retry Delay:
ParName: Upgrade_Error_Retry_Delay
Default: 3600
If an upgrade attempt fails, the SPA will retry with a delay indicated by the
Upgrade_Error_Retry_Delay parameter, specified in seconds. If the value is zero, the SPA treats
upgrade failures as though they were successful, and will not retry to upgrade unless some event
triggers a reboot.
Upgrade Rule: