Sorry, you need to enable JavaScript to visit this website.

Feedback

Your feedback is important to keep improving our website and offer you a more reliable experience.

CPClient

The CPClient is a middleware component that provides support for wireless provisioning of application and connection settings and exposes d-Bus APIs. It implements the OMA Client Provisioning (CP) protocol controlling application and connection settings. It works with Provman, which directly modifies application and connection settings.

The CPClient currently supports the provisioning of the following settings:

SIM Specific Settings

Provman regards some settings as SIM specific. This is necessary as certain middleware components, particularly telephony components such as oFono, maintain separate groups of settings for each SIM card that has been inserted into the device. They do this because telephony settings provisioned for one SIM card may not work when another SIM card is in use, particularly if the new SIM card is issued by a different network operator. The CPClient and Provman are aware of this peculiarity and cooperate with the underlying middleware to ensure that settings provisioned for operator A are not used when operator B's SIM card is present in the device.

When the CPClient processes an OMA CP document it initiates a device management session with Provman to whom it passes the set of key/value pairs that it has extracted from the document. An example of this process can be seen in Browser Bookmarks. When initiating a device management session, the CPClient also passes Provman the IMSI number that was used to authenticate the WAP Push message. If no IMSI number was required to authenticate the message, an empty string is passed to Provman in its place. This indicates to Provman that any SIM specific settings provisioned during the management session should be associated with the IMSI number of the first modem discovered in the device. Provman uses this IMSI number to bind any SIM specific settings to the appropriate SIM card.

Overwriting Settings

When a device management client is asked to provision an account or a group of settings that already exist it is faced with a dilemma. Should it overwrite the existing settings with the new settings received over the air, or should it simply discard the new settings and continue to use the old? The OMA CP specifications recommend the latter. However, this is often not very useful as it prevents existing account settings from being updated over the air via OMA CP. To update an account you would need to provision an entirely new account with a different account identifier and with the updated settings. The user will now have two versions of the same account present on the device. The updated account which works and the old account which presumably does not. This is a little confusing.

For this reason the CPClient supports an overwrite mode in addition to a standard mode that implements the OMA CP recommended behaviour. The integrator must select the mode that he wants to use during the compilation phase. By default the CPClient overwrites existing accounts with new accounts received over the air. However, this behaviour can be disabled by passing the --enable-overwrite="no" option to the configure script.

When overwrite mode is used, all settings from an existing account are deleted before the updated account is provisioned. Settings from the old and new versions of the account are never mixed. Overwrite mode also deletes existing versions of Internet access points and bookmarks before provisioning the new versions, received over the air.

The manner in which the CPClient identifies whether a particular group of settings already exist or not depends on what is being provisioned. For OMADS, OMADM and Email accounts the PROVIDER-ID is used to match new settings to old ones. If no PROVIDER-ID is specified the NAME parameter is used. The NAPID is used for matching access points and the NAME parameter is used for browser bookmarks.

For example, let us suppose that a device is provisioned with an Internet access point whose NAPID is set to cooloperator, just after it leaves the factory. One year later the cool operator has changed the password required to access its 3G network. It sends the device a new OMA CP message containing a NAPDEF definition for the updated access point. The NAPID of the new NAPDEF is the same as the old, i.e., cool operator. If the CPClient is compiled to user overwrite mode, the old access point will be completely deleted, before the new access point is provisioned. Once the process is finished the user is left with a single access point with the updated settings, which is probably want they want. If overwrite mode is disabled, the contents of the updated settings inside the new NAPDEF will be ignored and the old settings will remain untouched.

Overwrite mode is always used for MMS regardless of the compile options passed to configure. As only one instance of these settings can exist, preventing overwrite of these settings would mean that they could never be updated, which sort of defeats the purpose of over the air provisioning.

Unsupported OMA CP Characteristics

The following OMA CP characteristics are not supported.

  • ACCESS
  • BOOTSTRAP
  • CLIENTIDENTITY
  • VALIDITY
  • VENDORCONFIG
Project: