Perché Edge Audio esiste

In una riunione Webex “standard” i partecipanti che entrano via telefono usano i numeri di accesso PSTN forniti da Cisco (Cisco Audio) o da un provider CCA. Ogni minuto di chiamata è a pagamento e, per un’azienda con migliaia di riunioni al mese, i costi PSTN diventano significativi. Edge Audio ribalta il modello: invece di far transitare l’audio dalla telefonia pubblica di Cisco, instrada le chiamate di join audio attraverso l’infrastruttura SIP on-prem dell’azienda — tipicamente un CUBE (Cisco Unified Border Element) o un Expressway — sfruttando i trunk SIP e i gateway PSTN che l’azienda già possiede.

Il risultato: le chiamate restano sulla rete aziendale il più a lungo possibile e “escono” verso il PSTN solo dove conviene (o non escono affatto per gli utenti on-net), riducendo la spesa per i minuti telefonici e migliorando la qualità.

Come funziona il routing

Edge Audio opera in due direzioni:

  • Dial-in: il partecipante chiama un numero di accesso; la chiamata viene consegnata al CUBE aziendale, che la inoltra via SIP verso il cloud Webex.
  • Call-back: Webex richiama il partecipante instradando la chiamata attraverso il SIP trunk aziendale verso il PSTN locale.

La configurazione avviene in Control Hub, dove si definiscono i numeri di accesso, i pattern di routing e i certificati. La segnalazione tra on-prem e cloud è SIP-TLS con mutua autenticazione (mTLS) e i media viaggiano cifrati (SRTP).

Requisiti critici: certificato pubblico e reverse DNS

Sono i due requisiti che l’esame ama trasformare in scenari-trappola.

Requisito Cosa serve Perché
Certificato CA pubblico Certificato server sul CUBE/Expressway firmato da una CA pubblica presente nella trust list di Webex Webex non si fida di certificati self-signed o firmati da CA private/interne; senza fiducia il TLS mutuo fallisce
Reverse DNS (record PTR) Un record PTR che risolve l’IP pubblico del edge verso l’FQDN corrispondente Webex esegue un controllo di reverse lookup sull’IP sorgente della chiamata: se il PTR manca o non corrisponde, la validazione fallisce

In pratica il CN/SAN del certificato, l’FQDN pubblico e il record PTR devono essere coerenti. Il forward DNS (A record) e il reverse DNS (PTR) devono “chiudere il cerchio”: l’FQDN risolve all’IP e l’IP risolve all’FQDN.

Webex Edge Connect: il trasporto dedicato

Edge Audio può usare Internet, ma per garantire qualità e SLA si abbina spesso a Webex Edge Connect: un peering dedicato (Layer 3) verso il cloud Webex, tipicamente realizzato tramite un exchange come Equinix Cloud Exchange o una connessione diretta gestita.

Caratteristiche chiave:

  • BGP per lo scambio delle rotte tra l’edge aziendale e Webex.
  • Percorso privato, che bypassa l’Internet pubblico → QoS end-to-end, latenza e jitter prevedibili.
  • Ideale per audio, video e content sharing ad alto volume verso Webex Meetings.

Edge Connect è il “tubo” affidabile; Edge Audio è il “servizio” che ci scorre dentro. Non sono la stessa cosa: si può avere Edge Audio senza Edge Connect (via Internet) e Edge Connect può trasportare anche altro traffico Webex.

Posizionamento nell’ecosistema Hybrid

Edge Audio e Edge Connect fanno parte della famiglia dei Webex Hybrid / Edge Services, tutti orchestrati da Control Hub. Vanno distinti da servizi con nomi simili:

  • Video Mesh → media locale per ridurre il backhaul video, non riguarda l’audio PSTN.
  • Hybrid Calling / Call Service → integrazione della chiamata Webex con il call control on-prem.
  • Edge Audio → riduzione dei costi PSTN del join audio delle riunioni.

Trappole tipiche d’esame

  • Scenario: Edge Audio configurato ma l’attivazione fallisce con errore di certificato → Risposta giusta: il CUBE/Expressway usa un certificato self-signed o firmato da CA privata; serve un certificato firmato da una CA pubblica riconosciuta da Webex.
  • Scenario: TLS funziona ma le chiamate Edge Audio non vengono instradate/validate → Risposta giusta: manca il record PTR (reverse DNS) per l’IP pubblico dell’edge, oppure il PTR non corrisponde all’FQDN del certificato.
  • Scenario: si vuole garantire QoS e SLA per il traffico Webex evitando l’Internet pubblico → Risposta giusta: implementare Webex Edge Connect (peering dedicato con BGP), non semplicemente aprire porte firewall verso Internet.
  • Scenario: forward DNS (A record) presente ma validazione ancora KO → Risposta giusta: verificare che forward e reverse siano coerenti (l’FQDN risolve all’IP e l’IP risolve all’FQDN); il solo A record non basta.
  • Scenario: domanda che confonde Edge Audio con Video Mesh → Risposta giusta: Edge Audio ottimizza i costi PSTN dell’audio, Video Mesh gestisce i media video localmente; sono servizi distinti in Control Hub.