Che cosa significa “rete pronta” per Teams
Teams non è un’applicazione pesante in termini di byte trasferiti: è un’applicazione intollerante al ritardo. Il media in tempo reale — audio, video, screen sharing — degrada per packet loss, jitter e latenza molto prima che per mancanza di banda. I valori di riferimento pubblicati da Microsoft per il percorso fra client e servizio sono packet loss sotto l’1%, jitter sotto 30 ms e round-trip time sotto 100 ms; una sede che li rispetta funziona anche con un link modesto, una sede che li viola resta problematica anche con banda abbondante.
Da qui la distinzione che regge tutto il dominio: “quanta banda mi servirà?” è una domanda di capacity planning, “quanto è buono il percorso?” è una domanda di misura. Sono domande diverse e hanno strumenti diversi. È esattamente lì che l’esame costruisce le sue trappole.
Tre strumenti, tre domande
Network planner, nel Microsoft Teams admin center, è uno strumento di stima a priori. Si descrivono i siti, il numero di utenti e le persona (office worker, remote worker, Teams room), e lo strumento calcola la banda richiesta sui link WAN e Internet. Non misura nulla e non tocca la rete: si usa prima che il traffico esista, per dimensionare un rollout o una nuova sede.
Il Microsoft Teams Network Assessment Tool è un eseguibile da installare su una macchina dentro la sede. Fa due cose: un connectivity check verso gli endpoint del servizio e un quality check che genera una chiamata sintetica e registra loss, jitter e latenza in un CSV. È l’unico dei tre pensato per girare a lungo — giorni, non minuti — così da costruire una baseline e intercettare il degrado nelle ore di picco.
Il Microsoft 365 network connectivity test tool è una pagina web eseguita dalla postazione dell’utente: restituisce una fotografia della connettività di quella sede in quel momento, indicando quale front door Microsoft viene usato, se l’uscita è locale o fa hairpin verso un data center centrale, se proxy e DNS interferiscono. Se si esegue il test autenticati, i risultati possono alimentare le network insights nel Microsoft 365 admin center. È ideale per un triage rapido per-sede, ma resta uno snapshot, non una baseline.
Porte, protocolli e uscita locale
Signaling e traffico applicativo viaggiano su TCP 443. Il media in tempo reale vuole invece UDP verso le porte 3478-3481 (STUN/TURN verso i relay Microsoft). Se UDP è bloccato, il client ripiega su TCP 443: la chiamata si stabilisce comunque, ma la qualità peggiora perché le ritrasmissioni TCP accumulano ritardo. Il sintomo classico “si sente, ma è robotico” indica quasi sempre UDP filtrato, non banda insufficiente.
Il principio di progettazione è il local egress: gli endpoint della categoria Optimize — un elenco ristretto che concentra la gran parte del traffico real-time — devono uscire dal punto di rete più vicino all’utente, in modo diretto, senza proxy, senza SSL inspection e fuori dal tunnel VPN (split tunnel). Gli endpoint Allow sono necessari e possono passare da un proxy, purché non ispezionati; i Default seguono il percorso ordinario. Anche il DNS va risolto localmente: risolverlo in una sede centrale porta il client su un front door lontano e aggiunge latenza gratuita.
Banda e QoS
Il network planner dice quanta banda serve; la rete deve poi proteggerla. Il QoS si implementa con la marcatura DSCP (audio EF, video AF41, sharing AF21), che i client Teams applicano in base ai range di porte sorgente configurati e che gli apparati di rete devono rispettare in modo coerente end-to-end. Ha senso solo dove la congestione è governabile, cioè sui link aziendali: su Internet pubblico il DSCP viene ignorato. In molte sedi il collo di bottiglia reale non è la WAN ma il Wi-Fi — densità degli access point, roaming, uso della banda 5 GHz.
Trappole tipiche d’esame
- Stimare la banda per una sede che aprirà fra tre mesi → network planner: non c’è traffico da misurare, serve una stima da utenti e persona. Proporre l’assessment tool qui è la risposta sbagliata più frequente.
- Raccogliere loss, jitter e latenza per una settimana su una filiale → Microsoft Teams Network Assessment Tool: è l’unico che produce una baseline temporale con dati di qualità del media.
- Verificare in pochi minuti se una sede esce in locale o passa da un proxy → Microsoft 365 network connectivity test tool: snapshot dal browser dell’utente, non sostituisce l’assessment.
- Un singolo utente lamenta una chiamata andata male ieri → call analytics, non strumenti di rete: il dettaglio per utente e per chiamata sta lì; per tendenze e problemi sistemici si usa il Call Quality Dashboard.
- Le chiamate partono ma l’audio è robotico → sbloccare UDP 3478-3481: il fallback su TCP 443 maschera il problema facendo credere che “la rete funziona”.
- Proxy con SSL inspection o VPN full tunnel per i remote worker → bypass degli endpoint Optimize: l’ispezione e l’hairpin sul concentratore VPN sono cause tipiche di qualità scadente a banda invariata.