Cisco Enterprise phones (TFTP)

Cisco desk phones ship in two very different firmware families. Multiplatform (MPP) firmware speaks standard SIP and provisions over HTTPS like every other phone Exovo supports. Enterprise firmware — what a phone runs when it came from a Cisco Unified Communications Manager (CUCM) deployment — instead fetches CUCM-style XML config files from a TFTP server. Converting an Enterprise phone to MPP is a licensed Cisco migration, so many organizations prefer to keep their existing sets on the Enterprise load. Exovo supports that directly: an opt-in TFTP server serves Exovo-generated CUCM-style configs to the phones, with a companion HTTP config service on port 6970 (the Enterprise load requires both).

Supported models: Cisco 8811, 8841, 8845, 8851, 8861 and 8865 on Enterprise SIP firmware.

How it works

When enabled, Exovo generates the full CUCM-style file set for every phone assigned a Cisco 8800 Series (Enterprise) template — across every tenant on a multi-tenant system:

• SEP<MAC>.cnf.xml — the per-phone device config (extension, credentials, server address)
• XMLDefault.cnf.xml — the factory-default fallback that tells out-of-box phones which firmware load to run
• dialplan-t<tenant>.xml — the dial template (911 immediate, # to send, 5-second interdigit timeout), one per tenant
• SK-exovo-t<tenant>.xml — the softkey layout, one per tenant
• directory-t<tenant>-*.xml — the XML directory behind the phone's Directories key: the tenant's extensions and company contacts, with a menu per network path (LAN, SBC, VPN)

Files regenerate automatically when phones, extensions or contacts change (and hourly as a backstop); the phone-system container serves the tree read-only on UDP 69 and TCP 6970.

Setup

1. Enable the server — Admin → Connectivity → TFTP, switch on Enable TFTP server, save, then restart the core container (Admin → Services).
2. Add the phones — Admin → Devices → Add, enter the MAC address and choose the Cisco 8800 Series (Enterprise) template, assign the extension. Use Rebuild files now on the TFTP page to generate immediately.
3. Point the phones at Exovo — set DHCP option 150 (or 66) on the phone VLAN to the Exovo server's LAN IP, or set the TFTP server manually in the phone's network settings (Alternate TFTP).
4. Reset phone security settings — a phone that ever registered to a CUCM holds a signed trust list (ITL/CTL) and silently ignores configs from any other server. On the phone: Settings → Admin Settings → Reset Settings → Security settings. This is the single most common reason a phone "won't take" its config.

Firmware and media

The TFTP page's Firmware & media section accepts uploads the phones fetch alongside their configs. All of these come from your own Cisco firmware bundle or CUCM TFTP export — Exovo does not distribute Cisco-copyrighted files:

• Firmware (.loads + .sbn) — upload the full contents of a cmterm-88xx Enterprise SIP load. Do this before rolling out a mixed-firmware fleet: every generated config declares the firmware version it was built against, so a phone on an older load fetches and installs the new firmware automatically on first boot, then provisions — zero touch. Without the files, older phones log a load-fetch error and keep their current firmware, which may not parse the config correctly. Phones behind an SBC or on the VPN upgrade the same way.
• Ringtones (Ringlist-wb.xml + .rwb files) — optional; phones fall back to built-in rings without them.
• Wallpapers (List.xml + PNG image/thumbnail pairs, uploaded to Desktops/800x480x24) — optional.
• Locale packs — optional, and not needed for English-US: English strings and US tones are built into the firmware (the phone briefly requests locale files at boot and quietly falls back — those log entries are harmless). For other languages, download the Unified Communications Manager Endpoints Locale Installer (po-locale-<lang>-…cop.sgn) from Cisco's software center — it is a separate download from phone firmware. The .cop.sgn is a signed tar: strip the signature, extract, and upload the files found under usr/local/cm/tftp/<language_country>/ to the matching locale destination above.

Remote sites (behind an Exovo SBC)

Enterprise 8800s at a remote site work through the on-site Exovo SBC:

1. Set the phone's provisioning mode to SBC on its Devices entry (like any SBC-provisioned phone). Its config then routes SIP through the SBC as the outbound proxy.
2. Point the site's DHCP option 150 at the SBC's LAN IP — the SBC answers TFTP itself, fetching every file live through its encrypted tunnel from this system's TFTP tree. Nothing is mirrored on the SBC, so configs are always current, and no extra ports open anywhere. The SBC only ever serves the files belonging to its own tenant.

Remote phones without an SBC (Cisco phone VPN)

Enterprise firmware includes Cisco's built-in AnyConnect VPN client, and Exovo terminates it directly — a single remote phone reaches the system with no on-site hardware, the same way Yealink phones use their built-in OpenVPN client.

Server side, once: on Admin → Connectivity → VPN, OpenConnect VPN tab, switch on Enable Cisco phone VPN and save — the first enable needs one core container restart. Exovo generates a pinned server certificate and admits every Cisco Enterprise phone listed on the Devices page (the page shows each phone's VPN address). Set the phone's provisioning mode to VPN on its Devices entry. Firewall: forward TCP 8443 and UDP 443 to the Exovo server (UDP 443 carries the phone's DTLS media path; without it calls still work over TLS with slightly higher latency).

Phone-side procedure:

1. Factory-reset the phone (all settings) if it ever belonged to a CUCM.
2. Put it where it can reach the system's config: on the Exovo (or SBC) LAN.
3. Set Alternate TFTP: On with that server's address. The phone fetches its config and provisions — including its VPN settings.
4. Change Alternate TFTP to the Exovo Cisco VPN address shown on the VPN page (the in-tunnel gateway, e.g. 10.90.0.1 — each tenant has its own). The phone reboots itself, brings the tunnel up, and registers. Leave Alternate TFTP set to that address permanently. Do not turn it off: the phone needs its config service reachable to start up, and through the tunnel it always is.

That's the whole procedure, and from then on it is zero-touch. At every boot the phone checks whether its TFTP server is reachable directly — it isn't from a home network, so the phone connects the VPN first, exactly as CUCM phones do, and registers through it. Bring it into the office and it works there too. Configs, directory and firmware upgrades all ride the tunnel.

The connection is built to stay up unattended: phones talk SIP over TCP so a dropped connection is noticed and re-established within seconds, Exovo answers the phone's DNS inside the tunnel, and each phone keeps exactly one VPN session (a reconnect replaces the old session instantly). A watchdog can additionally restart a phone that stops responding, but in normal operation it has nothing to do.

Authentication mode (VPN page, OpenConnect VPN tab): Certificate is the recommended mode — phones authenticate with their factory-installed Cisco identity certificate, so nobody ever enters credentials, including after reboots and power loss. Only phones added on the Devices page are admitted (a valid Cisco certificate alone is not enough). Password prompts the user again after every reboot or power loss — usable, but noticeably worse. If password phones are already deployed, switch to Both first, wait for every phone to re-fetch its config (they then present certificates), and finish on Certificate. One caveat: factory certificates expire ten years after the phone's manufacture date — very old phones may need a locally significant certificate instead; contact support if a phone is refused with a certificate error.

Certificate rotation is deliberately two-step: Stage next certificate publishes the new certificate's hash to every phone config first; Promote only after every off-site phone has re-fetched a config (they then trust both). Promoting early strands off-site phones until they next visit the LAN.

Security

TFTP is unauthenticated and the config files contain SIP credentials. The server is off by default, and when on, ports 69 and 6970 must only ever be reachable from the site LAN (on the system side) or the remote site's LAN (on the SBC side) — never forward them through a firewall. Between sites the files travel exclusively inside the SBC's mTLS tunnel, and VPN phones fetch them through their own tunnel.