Due file XML statici. Esistono per un caso solo: quando n8n non risponde.
Il centralino d’agenzia vive su n8n (automazioni/n8n/centralino/ nel repo agenzia). Se quel servizio è giù, lento o irraggiungibile, Telnyx abbandona la richiesta e chiama il voice_fallback_url dell’applicazione TeXML, che punta qui.
| File | Cosa fa |
|---|---|
fallback.xml |
annuncia che non possiamo rispondere e registra un messaggio |
chiudi.xml |
saluta e chiude, ed è l’action del <Record> |
Un <Record> senza action fa ri-richiedere al fornitore il documento corrente: l’annuncio ripartirebbe da capo, all’infinito, finché il chiamante non riaggancia. Il secondo file esiste per chiudere la chiamata in modo esplicito, senza dipendere da un comportamento che la documentazione Telnyx non dichiara.
La rete di sicurezza non può vivere sulla macchina che deve proteggere. n8n gira su una VPS: un file di riserva ospitato lì cadrebbe insieme a ciò che dovrebbe coprire.
Il fallback non fa squillare nessuno, registra e basta. Questo repo è pubblico, e qualunque cosa scritta qui dentro è leggibile da chiunque: i cellulari dei soci restano nelle Data Table di n8n, che è il loro posto.
Il prezzo è che, durante un disservizio, il telefono non suona. La chiamata però non si perde, e quella è la proprietà che conta.
La registrazione resta su Telnyx: la notifica la manda n8n, che in quel momento è giù. Quando n8n torna su, vanno controllate le registrazioni orfane.
GitHub Pages serve solo file: a una richiesta POST risponde 405 Not Allowed, misurato. Per questo l’action del <Record> è in GET, e per questo l’applicazione TeXML deve avere voice_method a get: il fallback eredita il metodo dell’URL principale, e con post non verrebbe mai servito.
Un commit su main. GitHub Pages ripubblica da solo in un minuto. Dopo ogni modifica, riascoltare il messaggio chiamando il numero con n8n spento: è l’unico modo di sapere se funziona.