Provisioning is simply a way of automatically distributing settings to one or multiple devices/phones. Most offen a http-server is involved where each phone can request it's settings from.

You can also simulate provsioning on a single phone by uploading the settings-file via backup&restore on the phones website. I.e the very same file the phone would normally http-get from an http-server.

How the phone does try to aquire provisioned settings is itself a setting-section within the phone's configuration.

To achieve a successful Provisioning, the phone needs

  • a correctly configured and available Network
  • a valid time - It relies on NTP to acquire one

After activation, the provisioning-service checks the preconditions. Then it checks the following fixed sequence of sources:

  1. concurrently:

The service sends a request to the first found URL. After a successful download it checks, whether the file is a Reference File. This may lead to subsequent downloads. Every URL can contain special markers, that are replaced with device information.

The service uses the files in the specified sequence. The restore mechanism applies the files to the configuration. This process doesn't restart the device.

A provisioning can be initiated by various events.

  • manually: within the phones settings-menu under provisioning
  • at system boot: If configured, the provisioning service reacts on every system boot.
  • at a specific time: configured via the provisioning-settings.
  • via check sync: A SIP notify message can start a provisioning.

A device uses the DHCP options 66, 67 and 43 to determine an URL. It combines the options 66 and 67. The following example configuration of an isc-dhcp-server:

host d200 {
 hardware ethernet 00:09:52:00:00:0E;
 filename "prov.py?mac=<MACADR>";
 option tftp-server-name "http://prov.server.com";

is combined to http://prov.server.com/prov.py?mac=<MACADR>. Missing / are inserted between the options.

Option 	Length 	Text 	 
66 	11 	http://foo      block to transmit
67 	12 	<HWTYP>.bak     block to transmit

The DHCP option 43 can contain the encoded information from option 66 and 67. The test is hexadecimal encoded and separated by :.

Option 	Length 	Text 	 
42: 	0b: 	68:74:74:70:3a:2f:2f:66:6f:6f:00 	encoded
43: 	0c: 	3c:48:57:54:59:50:3e:2e:62:61:6b:00 	encoded

Results in the complete option 43 content:


The Redirect Service is an Auerswald/FonTevo Service, which assigns an URL to a device. It replies the assigned URL, when the configured device sends a request.

Registered partners can register their devices here.

The multicast subscribe mechanism sends a SIP multicast subscribe message and listens for sip notify responses. Contains on of the responses an URL, it is used by the provisioning service.

This mechanism should only be used in trustworthy networks. The device can't apply any security measures to ensure the authenticity and validity of the notify origin.

A reference file allows the user to provide more than one configuration file.

It is a XML document, that follows a defined format.

<?xml version="1.0" encoding="UTF-8" ?>
<referencedSettings xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

The phone interprets the URL elements mentioned above. It takes into account from which server the reference file was acquired. The phone applies the following rules to a document downloaded from http://prov.server.com/prov/references.xml:

  1. http://prov.server.com/prov/first_file.xml Is the first letter no '/', the target file will be acquired from the same directory on the server.
  2. http://prov.server.com/second_file.xml Is the first letter a '/', only the host of the original request is used.
  3. http://another.server.com/third_file.xml Is the URL element a complete and valid URL, it is used.

The provisioning service replaces the following markers:

  • <SERIAL> or {serial} to the devices serial number.
  • <HWTYP> or {type} to D100, D200.
  • <MACADR> or {mac} to the devices MAC address ( uppercase, without : )

Given the following URL:


the phone applies its data