Teams Direct Routing: collegare un SIP trunk a Microsoft Teams

Microsoft Teams è ormai il punto di raccolta della comunicazione aziendale, ma di default non sa telefonare verso la rete pubblica. Per chiamare e ricevere su numerazione geografica servono tre strade possibili: Calling Plan di Microsoft, Operator Connect, o Direct Routing. Quest'ultima è l'unica che permette di usare un SIP trunk di un operatore qualsiasi mantenendo il controllo sull'instradamento.

Come funziona Direct Routing

L'architettura è semplice: fra Teams e il SIP trunk dell'operatore si interpone un SBC (Session Border Controller) certificato da Microsoft. Il flusso è:

PSTN <--> SIP trunk operatore <--> SBC certificato <--> Microsoft Phone System <--> client Teams

L'SBC parla SIP verso l'operatore e SIP-TLS/SRTP verso Microsoft. Fa da traduttore fra due mondi che usano lo stesso protocollo ma con dialetti e requisiti di sicurezza diversi.

Microsoft mantiene una lista di SBC certificati: Ribbon, AudioCodes, Oracle, Cisco CUBE, e — nel mondo open — la certificazione riguarda anche alcune distribuzioni basate su Asterisk o FreeSWITCH tramite vendor terzi. Un SBC non in lista può tecnicamente funzionare, ma non è supportato in caso di problemi.

Requisiti prima di iniziare

Lato Microsoft:

• Licenza Teams Phone (ex Phone System) per ogni utente abilitato alle chiamate PSTN
• Un dominio verificato nel tenant, diverso da onmicrosoft.com
• Utenti con EnterpriseVoice abilitato e HostedVoiceMail attivo

Lato SBC:

• FQDN pubblico che appartenga a un dominio verificato nel tenant
• Certificato pubblico valido (non self-signed) con SAN corrispondente all'FQDN
• IP pubblico raggiungibile, porta SIP-TLS aperta (di default 5061)
• Supporto SRTP obbligatorio: Microsoft non accetta RTP in chiaro

Lato rete:

• Whitelist degli IP dei SIP proxy Microsoft (sip.pstnhub.microsoft.com e i due datacenter di backup)
• Range media Microsoft aperti in UDP
• Nessun SIP ALG attivo sul firewall: è la causa numero uno dei problemi di segnalazione

Configurazione passo per passo

1. Registra l'SBC nel tenant. Da PowerShell con il modulo Microsoft Teams:

New-CsOnlinePSTNGateway -Fqdn sbc.esempio.it `
  -SipSignalingPort 5061 `
  -MaxConcurrentSessions 30 `
  -Enabled $true `
  -MediaBypass $false

2. Crea la voice routing policy. Serve definire quali numeri escono da quale gateway:

New-CsOnlineVoiceRoute -Identity "Italia" `
  -NumberPattern "^\+39" `
  -OnlinePstnGatewayList sbc.esempio.it

New-CsOnlineVoiceRoutingPolicy -Identity "Nazionale" `
  -OnlinePstnUsages "Italia"

3. Assegna la policy agli utenti e imposta il numero:

Set-CsPhoneNumberAssignment -Identity utente@esempio.it `
  -PhoneNumber +39095XXXXXXX -PhoneNumberType DirectRouting

Grant-CsOnlineVoiceRoutingPolicy -Identity utente@esempio.it `
  -PolicyName "Nazionale"

4. Configura l'SBC con due peer distinti: uno verso Microsoft (TLS 5061, SRTP, manipolazione header per il formato E.164) e uno verso il SIP trunk dell'operatore (tipicamente UDP 5060 o TLS, con registrazione o autenticazione IP-based).

5. Testa in ordine: chiamata uscente, chiamata entrante, trasferimento, e infine i servizi di emergenza. Le chiamate al 112 richiedono attenzione specifica: Teams non conosce la posizione fisica del chiamante, quindi il numero presentato deve corrispondere a un indirizzo registrato correttamente presso l'operatore.

Media Bypass: quando attivarlo

Con Media Bypass disattivato, il flusso audio passa dai datacenter Microsoft anche se chiamante e SBC sono nella stessa rete. Attivandolo, il client Teams parla RTP direttamente con l'SBC quando la topologia lo consente, riducendo latenza e carico.

Va attivato solo se:

• L'SBC è raggiungibile dai client interni
• I client hanno visibilità diretta verso l'IP media dell'SBC
• La rete non ha NAT simmetrico problematico fra client e SBC

In configurazioni con utenti prevalentemente remoti il beneficio è limitato e la complessità di troubleshooting aumenta.

Direct Routing vs le alternative

Direct Routing conviene quando l'azienda ha già un SIP trunk in essere, ha esigenze di instradamento particolari (multi-sede, least cost routing, integrazione con un centralino legacy), oppure vuole mantenere l'operatore che le fornisce la connettività.

Problemi ricorrenti

• 503 Service Unavailable da Microsoft: quasi sempre certificato non valido, scaduto o con SAN sbagliato.
• Audio unidirezionale: SRTP non negoziato correttamente o media path bloccato dal firewall.
• Chiamate entranti che non arrivano: numero non in formato E.164 sull'SBC, oppure PhoneNumberType impostato erroneamente su CallingPlan.
• Chiamate che cadono a 30 secondi: mancata gestione del SIP re-INVITE o timer di sessione non allineati fra i due peer.

Il tempo di messa in opera realistico per una PMI con un trunk già attivo è di una giornata lavorativa, di cui buona parte spesa in test e taratura delle manipolazioni di header. La parte che va pianificata con più anticipo è il certificato: senza un FQDN su dominio verificato e un certificato pubblico corretto, nulla del resto funziona.