WebRTC in azienda: telefonare dal browser senza installare nulla

WebRTC è l'insieme di API e protocolli che permette a un browser di stabilire una sessione audio e video in tempo reale senza plugin né software aggiuntivo. È supportato nativamente da tutti i browser moderni e sta dietro a buona parte delle piattaforme di videoconferenza che usi ogni giorno. Per un'azienda con un centralino SIP, è anche il modo più rapido per dare un interno a chi non ha un telefono fisso.

I tre pezzi che lo compongono

WebRTC non è un protocollo singolo ma uno stack, e capirne le parti aiuta a diagnosticare i problemi.

Acquisizione e codifica. Le API getUserMedia accedono a microfono e webcam previo consenso esplicito dell'utente. L'audio viene codificato tipicamente in Opus, che si adatta alla banda disponibile e integra correzione d'errore; il video in VP8, VP9, AV1 o H.264 a seconda della negoziazione.

Trasporto. I flussi viaggiano su SRTP, cifrato obbligatoriamente: WebRTC non ammette media in chiaro, e le chiavi vengono negoziate tramite DTLS. Non esiste modo di disattivare la cifratura, il che risolve d'ufficio una categoria di problemi di sicurezza tipici del VoIP tradizionale.

Attraversamento NAT. Qui sta la complessità reale. Due browser dietro NAT non possono parlarsi direttamente senza aiuto, e WebRTC usa il framework ICE per risolvere:

• Un server STUN dice al client qual è il suo indirizzo pubblico visto dall'esterno
• Se il NAT è troppo restrittivo, un server TURN fa da relay, inoltrando i pacchetti per conto delle parti
• ICE raccoglie tutti i candidati possibili, li testa e sceglie il percorso funzionante con priorità più alta

STUN è leggero e serve solo in fase di setup. TURN invece trasporta l'intero flusso media, quindi consuma banda e va dimensionato: è la voce di costo che spesso viene sottovalutata.

Il pezzo che WebRTC non fornisce

WebRTC definisce come i due capi si scambiano media, ma non definisce come si trovano. Il signaling — chi chiama chi, chi risponde, chi riaggancia — è lasciato deliberatamente all'implementatore.

In ambito aziendale la scelta naturale è riusare SIP, che il centralino già parla. Il collegamento avviene tramite SIP over WebSocket, standardizzato nella RFC 7118: il browser apre una connessione WebSocket sicura verso il centralino e ci fa passare dentro i messaggi SIP.

Lo schema completo diventa quindi:

• Browser e centralino si scambiano SIP su WebSocket cifrato per stabilire la chiamata
• I media viaggiano separatamente su SRTP, con ICE che trova il percorso
• Il centralino, se necessario, transcodifica verso il trunk o verso interni che non parlano WebRTC

Le librerie più usate lato browser sono JsSIP e SIP.js, entrambe mature e ben documentate. Molti centralini offrono già un client web pronto, costruito su una di queste.

Supporto sui centralini più diffusi

Su Asterisk la configurazione minima richiede un trasporto WSS con certificato valido, l'abilitazione di DTLS sull'endpoint e la dichiarazione dei server ICE. Il certificato deve essere riconosciuto da una CA pubblica: i browser rifiutano i self-signed sulle connessioni WebSocket sicure, ed è l'errore più frequente nelle prime installazioni.

Quando conviene e quando no

Ha senso in diversi scenari concreti:

• Operatori temporanei o stagionali: dai un interno senza distribuire hardware né installare software su macchine che non gestisci
• Smart working su dispositivi personali: nessun client da installare, nessun permesso di amministratore richiesto
• Postazioni condivise: l'utente fa login sul browser e ha il suo interno, senza provisioning del telefono
• Click-to-call sul sito: un visitatore avvia una chiamata verso il centralino direttamente dalla pagina, senza comporre un numero
• Ambienti bloccati: dove la policy IT vieta l'installazione di software, il browser è già approvato

Conviene meno quando:

• L'utente sta al telefono molte ore al giorno: un telefono fisico con cornetta e tasti dedicati resta più ergonomico
• Servono funzioni avanzate di gestione chiamate — tasti BLF fisici, trasferimenti rapidi, cuffie con controlli integrati
• La postazione ha connettività instabile: il browser è meno tollerante di un telefono IP alle interruzioni
• Chiudere per errore la scheda significa perdere la chiamata, e succede

Problemi ricorrenti e cause

• Nessun audio in un senso: quasi sempre TURN mancante o irraggiungibile. Il signaling passa, i media no
• La chiamata non parte: certificato WSS non valido, oppure WebSocket bloccato da un proxy aziendale
• Microfono non disponibile: il browser richiede un contesto sicuro. Su HTTP semplice getUserMedia non funziona, salvo su localhost
• Audio degradato solo per alcuni utenti: percorso ICE che ricade su TURN con relay geograficamente lontano
• Funziona in ufficio, non da casa: NAT simmetrico lato utente, che rende obbligatorio il relay

Lo strumento diagnostico migliore è la pagina interna dei browser basati su Chromium, raggiungibile digitando webrtc-internals nella barra degli indirizzi: mostra candidati ICE, codec negoziati, jitter e pacchetti persi in tempo reale.

In sintesi

WebRTC non sostituisce il telefono IP per chi lo usa intensamente, ma copre benissimo tutto ciò che sta intorno: postazioni temporanee, lavoro da remoto, dispositivi non gestiti, integrazione nel sito.

Il requisito da non sottovalutare è l'infrastruttura STUN e TURN: senza un relay dimensionato correttamente e vicino agli utenti, l'esperienza è incostante in modi difficili da spiegare. Velix fornisce connettività e servizi voce con centralini che integrano il client web, e la parte di attraversamento NAT gestita lato rete.