Digium phones can either retrieve their configuration directly from a DPMA or Switchvox system via SIP MESSAGE, or by being directed to an HTTP, HTTPs, FTP or FTPS host via DHCP Option 66. TFTP is not supported.
Here is an example Avahi services definition file that will point a phone to DPMA and/or Switchvox:
Note that serviceType may be defined as either switchvox or asterisk.
Here is a typical DHCP daemon configuration specifying Option 66:
A custom Avahi services definition file can be used to also, in addition to mass deploying firmware, point a Digium phone to a DPMA system. To accomplish this, use a service element definition like:
XML Firmware Management
Within the XML configuration file, the phone receives configuration information, including information about firmware files to load. Firmware is managed using a <firmwares> configuration element, such as:
Digium phones, beginning with firmwares 1_5_0 (D80) and 2_3_0 (other models), validate the SSL for any cURL operations. This includes configuration file retrieval, for non-DPMA/Switchvox phones, as well as for retrieval, inside of DPMA/Switchvox environments, of firmware, ringtones, contacts files, blf items files, applications, etc. And, beginning with firmware 2_7_0 (non-D80), phones also validate SSL for 802.1X authentication. SSL Validation can be manually disabled from the phone's UI - or later disabled via an XML config parameter. But, this can present some chicken-and-egg challenges.
From a factory default state, Digium phones root CA bundle is the only means by which it can validate SSL. The root CA bundle is typically kept current with the Mozilla PEM bundle at the time of the firmware's building. So, for an initial validation, the phone, if it is directed to an HTTPs location, can only validate against a publicly signed server. The phones are capable of being fed additional root CA PEM payloads, which may be privately signed CAs, from within the phone's XML config file inside of the certs element. The phone will, on boot, combine any root CA payloads from its config file with the baked in Mozilla bundle to create the bundle that it uses for all SSL validation. Thus, phones, once they've been given an initial config file, can validate non-publicly signed SSL connections.
The problem is further complicated by time. Digium phones do not have a built in battery. Thus, from a factory default state, the phone has been programmed to set its clock to its firmware build date. The phone, if it's able to get on a network, will then attempt to set its clock using NTP. Beginning with firmware 2_7_0 (non-D80), phones are able to respond to DHCP Option 42 for NTP servers, and will utilize servers retrieved there in lieu of the phone's built-in server definitions: 0.digium.pool.ntp.org and 1.digium.pool.ntp.org. Once time has been retrieved, the phone will set its clock and continue the boot process. Subsequently, whenever the phone is rebooted, it will save off its current time and will, on on the next boot, use that time in lieu of the firmware's build-time. This provides a more accurate clock in the future for validating SSL.