Autoprovisioning telefoni VoIP: come funziona e come configurarlo

Configurare a mano venti telefoni IP significa venti volte la stessa sequenza: collegare il telefono, leggere l'IP dal display, aprire l'interfaccia web, inserire credenziali SIP, impostare il fuso orario, il codec, i tasti BLF. L'autoprovisioning riduce tutto a un'operazione sola: accendere il telefono e collegarlo alla rete.

Il principio: il telefono si va a prendere la configurazione

Un telefono SIP appena uscito dalla scatola, o dopo un reset di fabbrica, all'avvio esegue una sequenza fissa:

• richiede un indirizzo IP via DHCP
• legge le opzioni DHCP aggiuntive alla ricerca di un URL di provisioning
• scarica da quell'URL un file di configurazione che lo riguarda
• applica i parametri e si riavvia già registrato al centralino

Tutto il lavoro sta nel predisporre il secondo e il terzo passaggio. Il resto lo fa il firmware.

DHCP option 66 e le alternative

L'option 66 (tftp-server-name) è il metodo più diffuso per comunicare al telefono dove andare a cercare la configurazione. Nonostante il nome storico leghi l'opzione al TFTP, quasi tutti i produttori accettano un URL completo con schema esplicito:

http://provisioning.esempio.it/cfg/
https://provisioning.esempio.it/cfg/

Su un router MikroTik la si imposta come opzione DHCP personalizzata:

# codice 66, valore come stringa (0x73 = tipo string)
/ip dhcp-server option
add code=66 name=provisioning value="s'http://192.168.10.5/cfg/'"

/ip dhcp-server option sets
add name=telefoni options=provisioning

# associa il set alla rete DHCP dei telefoni
/ip dhcp-server network
set [find address=192.168.10.0/24] dhcp-option-set=telefoni

Le alternative all'option 66 sono tre, e conviene conoscerle perché non tutti i modelli si comportano allo stesso modo:

• Option 43 / option 160-161: alcuni vendor usano codici proprietari. Yealink legge l'option 66 ma anche la 43; Grandstream preferisce la 66; Snom usa la 66 e la 67.
• Redirection service del produttore: il telefono contatta un server del vendor (RPS, ZTP, Redirection & Provisioning Service) che, in base al MAC, risponde con l'URL del tuo server. Utile quando il telefono viene spedito direttamente al cliente e non passa mai dalla tua rete.
• DNS SRV o record A dedicato: alcuni firmware cercano un host predefinito nel dominio ricevuto via DHCP.

Se i telefoni stanno su una VLAN voce dedicata — scelta consigliata — l'option va configurata sullo scope DHCP di quella VLAN, non su quello dei dati.

Il file di configurazione MAC-based

Il modello più usato prevede due livelli di file:

• un file comune, valido per tutti i terminali dello stesso modello (fuso orario, server NTP, lingua, codec abilitati, firmware target)
• un file per singolo dispositivo, il cui nome contiene il MAC address, che contiene solo ciò che cambia da telefono a telefono (utente SIP, password, display name, tasti programmabili)

I nomi variano per produttore: y000000000000.cfg e .cfg per Yealink, cfg.xml per Grandstream, .htm per Snom. Il MAC va scritto in minuscolo e senza separatori nella maggior parte dei casi.

Un frammento tipico di file per singolo interno:

account.1.enable = 1
account.1.label = Reception
account.1.display_name = Reception
account.1.auth_name = 201
account.1.user_name = 201
account.1.password = <password_generata>
account.1.sip_server_host = pbx.esempio.it
account.1.sip_server_port = 5061
account.1.transport = 2          # 2 = TLS
account.1.srtp_encryption = 1    # SRTP obbligatorio

Nella pratica questi file non si scrivono a mano: FreePBX con il modulo Endpoint Manager, 3CX e Yeastar generano i template automaticamente a partire dall'interno creato sul centralino. Il compito dell'installatore si riduce a inserire il MAC nel campo del dispositivo e verificare che l'URL di provisioning sia raggiungibile.

Sicurezza: il punto più trascurato

Un server di provisioning in HTTP semplice espone le credenziali SIP di tutta l'azienda a chiunque conosca — o indovini — un MAC address. I MAC non sono segreti: sono stampati sull'etichetta e visibili in chiaro nel traffico della LAN.

Le contromisure minime:

• HTTPS con certificato valido, non autofirmato: molti firmware recenti rifiutano certificati non verificabili
• autenticazione HTTP (basic o digest) sul percorso di provisioning, con credenziali distinte da quelle SIP
• provisioning raggiungibile solo dalla VLAN voce o da IP noti, mai esposto su internet senza filtri
• rotazione delle password SIP dopo la messa in servizio, o generazione casuale per interno
• finestra temporale: alcuni sistemi rendono disponibile il file solo per un intervallo limitato dopo la creazione dell'interno

Se i telefoni sono in sedi remote e il provisioning deve passare da internet, la soluzione pulita è farlo transitare in un tunnel: VPN site-to-site verso la sede del centralino, oppure un servizio di redirection del produttore che punta a un endpoint HTTPS autenticato.

Aggiornamenti e resync

Il provisioning non serve solo alla prima installazione. Configurando un intervallo di auto-resync (tipicamente ogni 24 ore, in orario notturno) i telefoni ricontrollano il file e applicano le modifiche senza intervento. Cambiare il server SIP di tutta la flotta diventa una modifica al file comune.

Per applicare una modifica subito, senza aspettare il resync, i centralini inviano un messaggio SIP NOTIFY con evento check-sync: il telefono riscarica la configurazione e si riavvia. Va verificato che l'opzione sia abilitata sul terminale, altrimenti il NOTIFY viene ignorato.

Un'ultima accortezza: gestire anche il firmware dal file di provisioning, indicando versione e URL del pacchetto. Una flotta con firmware disallineati produce comportamenti diversi a parità di configurazione, ed è la causa più frequente di problemi che sembrano inspiegabili.