The phone provides multiple remote configuration profile parameters (Profile_Rule*). Thus, each resync operation can retrieve
multiple files that different servers manage.
In the simplest scenario, the device resyncs periodically to a single profile on a central server, which updates all pertinent
internal parameters. Alternatively, the profile can be split between different files. One file is common for all the phones
in a deployment. A separate, unique file is provided for each account. Encryption keys and certificate information can be
supplied by still another profile, stored on a separate server.
Whenever a resync operation is due, the phone evaluates the four Profile_Rule* parameters in sequence:
Each evaluation can result in a profile retrieval from a remote provisioning server, with a possible update of some number
of internal parameters. If an evaluation fails, the resync sequence is interrupted, and is retried again from the beginning
specified by the Resync_Error_Retry_Delay parameter (seconds). If all evaluations succeed, the device waits for the second
specified by the Resync_Periodic parameter and then performs another resync.
The contents of each Profile_Rule* parameter consist of a set of alternatives. The alternatives are separated by the | (pipe)
character. Each alternative consists of a conditional expression, an assignment expression, a profile URL, and any associated
URL options. All these components are optional within each alternative. The following are the valid combinations, and the
order in which they must appear, if present:
[ conditional-expr ] [ assignment-expr ] [[ options ] URL ]
Within each Profile_Rule* parameter, all alternatives except the last one must provide a conditional expression. This expression
is evaluated and is processed as follows:
Conditions are evaluated from left to right, until one is found that evaluates as true (or until one alternative is found
with no conditional expression).
Any accompanying assignment expression is evaluated, if present.
If a URL is specified as part of that alternative, an attempt is made to download the profile that is located at the specified
URL. The system attempts to update the internal parameters accordingly.
If all alternatives have conditional expressions and none evaluates to true (or if the whole profile rule is empty), the entire
Profile_Rule* parameter is skipped. The next profile rule parameter in the sequence is evaluated.
This example resyncs unconditionally to the profile at the specified URL, and performs an HTTP GET request to the remote provisioning
In this example, the device resyncs to two different URLs, depending on the registration state of Line 1. In case of lost
registration, the device performs an HTTP POST to a CGI script. The device sends the contents of the macro expanded GPP_A,
which may provide additional information on the device state:
($PRVTMR ge 600)? http://p.tel.com/has-reg.cfg
| [--post a] http://p.tel.com/lost-reg?
In this example, the device resyncs to the same server. The device provides additional information if a certificate is not
installed in the unit (for legacy pre-2.0 units):
(“$CCERT” eq “Installed”)? https://p.tel.com/config?
In this example, Line 1 is disabled until GPP_A is set equal to Provisioned through the first URL. Afterwards, it resyncs
to the second URL:
(“$A” ne “Provisioned”)? (Line_Enable_1_ = “No”;)! https://p.tel.com/init-prov
In this example, the profile that the server returns is assumed to contain XML element tags. These tags must be remapped to
proper parameter names by the aliases map stored in GPP_B:
[--alias b] https://p.tel.com/account/$PN$MA.xml
A resync is typically considered unsuccessful if a requested profile is not received from the server. The Resync_Fails_On_FNF
parameter can override this default behavior. If Resync_Fails_On_FNF is set to No, the device accepts a file-not-found response
from the server as a successful resync. The default value for Resync_Fails_On_FNF is Yes.