Novità per il routing diretto

  • Articolo
  • Si applica a:
    Microsoft Teams

Questo articolo descrive le novità di Direct Routing. Ricontrollare spesso per verificare la disponibilità di aggiornamenti.

Test delle estensioni EKU dei certificati SBC

Il 5 marzo 2024 (a partire dalle 9:00 UTC), Microsoft effettuerà un test di 24 ore dell'infrastruttura. Durante questo periodo, i certificati dei controller di bordo della sessione sono necessari per includere sia l'autenticazione client che l'autenticazione server per le estensioni Extended Key Usage (EKU). Ti chiediamo gentilmente di assicurarti che l'estensione EKU del tuo certificato includa l'autenticazione server e l'autenticazione client per evitare un peggioramento delle prestazioni del servizio.

Se l'estensione di EKU del certificato SBCs non include sia Autenticazione server che Autenticazione client, gli SBC non saranno in grado di connettersi all'infrastruttura Microsoft.

Tenere presente che il passaggio finale per richiedere l'autenticazione server e client per EKU verrà eseguito il 19 marzo 2024.

Per altre informazioni, vedere Certificato attendibile pubblico per il certificato SBC.

Modifica del certificato SIP per l'autorità di certificazione MSPKI nei cloud DoD e GCCH

Microsoft 365 sta aggiornando i servizi che alimentano messaggistica, riunioni, telefonia, voce e video per usare certificati TLS da un diverso set di autorità di certificazione radice. Gli endpoint interessati includono endpoint SIP per il routing diretto di Microsoft Teams usati per il traffico PSTN nelle distribuzioni Office 365 Government - GCC High (GCCH) e DoD. La transizione ai certificati emessi dalla nuova CA per gli endpoint SIP inizia a maggio 2024. Ciò significa che occorre intraprendere un'azione prima della fine di aprile 2024.

La nuova ROOT CA "DigiCert Global Root G2" è ampiamente attendibile da sistemi operativi come Windows, macOS, Android e iOS e da browser come Microsoft Edge, Chrome, Safari e Firefox. Tuttavia, è probabile che il certificato SBC disponga di un archivio radice del certificato configurato manualmente. IN TAL CASO, L'ARCHIVIO CA SBC DEVE ESSERE AGGIORNATO PER INCLUDERE LA NUOVA AUTORITÀ DI CERTIFICAZIONE PER EVITARE L'IMPATTO DEL SERVIZIO. Gli SBC che non hanno la nuova CA radice nell'elenco di CA accettabili ricevono errori di convalida del certificato, che possono influire sulla disponibilità o sulla funzione del servizio. Sia la CA precedente che quella nuova DEVONO essere considerate attendibili da SBC: non rimuovere la VECCHIA CA. Fare riferimento alla documentazione del fornitore di SBC per informazioni su come aggiornare l'elenco dei certificati accettati nel certificato SBC. Entrambi i certificati radice precedenti e nuovi devono essere considerati attendibili da SBC. Oggi, i certificati TLS utilizzati dalle interfacce SIP Microsoft concatenare fino alla CA radice seguente:

Nome comune della CA: DigiCert Global Root CA Thumbprint (SHA1): a8985d3a65e5e5c4b2d7d66d40c6dd2fb19c5436 Il vecchio certificato CA può essere scaricato direttamente da DigiCert: http://cacerts.digicert.com/DigiCertGlobalRootCA.crt

I nuovi certificati TLS utilizzati dalle interfacce SIP Microsoft ora concateneranno alla CA radice seguente: Nome comune della CA: DigiCert Global Root G2 Thumbprint (SHA1): df3c24f9bfd666761b268073fe06d1cc8d4f82a4 Il nuovo certificato CA può essere scaricato direttamente da DigiCert: https://cacerts.digicert.com/DigiCertGlobalRootG2.crt

Per ulteriori dettagli, fai riferimento alle indicazioni https://docs.microsoft.com/en-us/microsoft-365/compliance/encryption-office-365-tls-certificates-changes?view=o365-worldwide tecniche in Per testare e confermare la configurazione dei certificati SBC prima della modifica, Microsoft ha preparato un endpoint di test che può essere usato per verificare che gli accessori SBC consideri attendibili i certificati emessi dalla nuova CA radice (DigiCert Global Root G2). Se sbc è in grado di stabilire una connessione TLS a questo endpoint, la connettività ai servizi di Teams non dovrebbe essere interessata dalla modifica. Questi endpoint devono essere usati solo per il ping di OPZIONI SIP ai messaggi e non per il traffico vocale. Non sono endpoint di produzione e non sono supportati da una configurazione ridondante. Ciò significa che riscontreranno tempi di inattività che durano diverse ore. Si prevede una disponibilità di circa il 95%.

FQDN endpoint di test per GCCH: porta x.sip.pstnhub.infra.gov.teams.microsoft.us: 5061

FQDN endpoint di test per DoD: porta x.sip.pstnhub.infra.dod.teams.microsoft.us: 5061

Passaggio finale del certificato SIP alla nuova autorità di certificazione MSPKI

A seguito di due test effettuati il 5 e il 19 settembre, Microsoft eseguirà il passaggio finale alla nuova Autorità di certificazione (CA) il 3 ottobre, a partire dalle 10 UTC. Tutti gli endpoint SIP Microsoft vengono gradualmente aggiornati per usare i certificati in cui la catena di certificati esegue il roll up all'autorità di certificazione (CA) "DigiCert Global Root G2".

Se i controller dei confini della sessione non sono configurati correttamente con la nuova Autorità di certificazione(CA), le chiamate in ingresso e in uscita per il routing diretto non riusciranno dopo l'aggiornamento. Contattare direttamente il fornitore di SBC per altre indicazioni sulla configurazione di SBC.

I requisiti e i test relativi alle modifiche sono stati comunicati ai clienti di Direct Routing tramite post del Centro messaggi e interventi di integrità dei servizi nel portale di Microsoft Amministrazione (MC540239, TM614271, MC663640, TM674073 MC674729).

Il certificato SIP per l'autorità di certificazione MSPKI modifica ulteriori test

Il 19 settembre (a partire dalle 16 UTC), Microsoft eseguirà un test di 24 ore in cui tutti gli endpoint SIP Microsoft verranno aggiornati per usare i certificati in cui la catena di certificati verrà rollup fino all'autorità di certificazione (CA) "DigiCert Global Root G2". È necessario aggiungere una nuova autorità di certificazione (CA) nella configurazione SBC e conservare la vecchia CA di Baltimora; non sostituire la vecchia AUTORITÀ di certificazione. Se il proprio SBC non considera attendibile questa CA, non sarà possibile connettersi agli endpoint SIP di Teams durante il test. Il passaggio finale alla nuova Autorità di certificazione (CA) verrà eseguito il 3 ottobre.

Se si desidera testare e verificare la configurazione del certificato SBCs prima della modifica, Microsoft ha preparato un endpoint di test che è possibile usare per verificare che gli accessori SBC abbiano i certificati attendibili emessi dalla nuova CA radice (DigiCert Global Root G2). Questo endpoint deve essere usato solo per il ping di OPZIONI SIP ai messaggi e non per il traffico vocale. Se sbc è in grado di stabilire una connessione TLS a questo endpoint, la connettività ai servizi di Teams non dovrebbe essere interessata dalla modifica.

FQDN endpoint di test: sip.mspki.pstnhub.microsoft.com

Porta: 5061

Test di modifica del certificato SIP per l'autorità di certificazione MSPKI

Il 5 settembre (a partire dalle 9:00 UTC), Microsoft eseguirà un test di 24 ore in cui tutti gli endpoint SIP Microsoft verranno aggiornati per usare i certificati in cui la catena di certificati verrà distribuita all'autorità di certificazione (CA) "DigiCert Global Root G2". Se il proprio SBC non considera attendibile questa CA, potrebbe non essere possibile connettersi agli endpoint SIP di Teams.

Se si desidera testare e verificare la configurazione del certificato SBCs prima della modifica, Microsoft ha preparato un endpoint di test che può essere usato per verificare che i dispositivi SBC attendibili certificati emessi dalla nuova CA radice (DigiCert Global Root G2). Questo endpoint deve essere usato solo per il ping di OPZIONI SIP ai messaggi e non per il traffico vocale. Se sbc è in grado di stabilire una connessione TLS a questo endpoint, la connettività ai servizi di Teams non dovrebbe essere interessata dalla modifica.

FQDN endpoint di test: sip.mspki.pstnhub.microsoft.com

Porta: 5061

Modifica del certificato SIP per l'autorità di certificazione MSPKI

Microsoft 365 sta aggiornando i servizi che alimentano messaggistica, riunioni, telefonia, voce e video per usare certificati TLS da un diverso set di autorità di certificazione radice. Questa modifica viene apportata perché l'autorità di certificazione radice corrente scade a maggio 2025. Gli endpoint interessati includono tutti gli endpoint SIP Microsoft usati per il traffico PSTN che utilizza la connettività TLS. La transizione ai certificati emessi dalla nuova CA inizia alla fine di agosto.

La nuova ROOT CA "DigiCert Global Root G2" è ampiamente attendibile da sistemi operativi come Windows, macOS, Android e iOS e da browser come Microsoft Edge, Chrome, Safari e Firefox. Tuttavia, è probabile che il certificato SBC disponga di un archivio radice del certificato configurato manualmente e che debba essere aggiornato. Gli SBC che non hanno la nuova CA radice nell'elenco di CA accettabili ricevono errori di convalida del certificato, che possono influire sulla disponibilità o sulla funzione del servizio. Fare riferimento alla documentazione del fornitore di SBC per informazioni su come aggiornare l'elenco dei certificati accettati nel certificato SBC.

Oggi, i certificati TLS utilizzati dalle interfacce SIP Microsoft concatenare fino alla CA radice seguente:

Nome comune della CA: Baltimore CyberTrust Root Thumbprint (SHA1): d4de20d05e66fc53fe1a50882c78db2852cae474

I nuovi certificati TLS utilizzati dalle interfacce SIP Microsoft verranno ora concatenare alla CA radice seguente:

Nome comune della CA: DigiCert Global Root G2 Thumbprint (SHA1): df3c24f9bfd666761b268073fe06d1cc8d4f82a4

Il nuovo certificato CA può essere scaricato direttamente da DigiCert: DigiCert Global Root G2.

Per altre informazioni, vedere Modifiche al certificato TLS di Office.

Nuovi endpoint SIP routing diretto

Microsoft introdurrà nuovi IP di segnalazione agli endpoint SIP routing diretto di Teams. Per assicurarsi che questa modifica non influirà sulla disponibilità del servizio, verificare che il controller dei confini della sessione e il firewall siano configurati per l'uso delle subnet consigliate 52.112.0.0/14 e 52.122.0.0/15 per le regole di classificazione e ACL. Per altre informazioni, vedere Ambienti Microsoft 365, Office 365 e Office 365 GCC.

Logica di abbassare di livello trunk in base alle opzioni SIP

Viene introdotta una nuova funzionalità basata su Opzioni SIP per l'integrità del trunk. Se abilitata nella configurazione del gateway (vedere Set-CsOnlinePSTNGateway cmdlet e il parametro SendSipOptions), la logica di routing per le chiamate in uscita abbassa di livello i trunk che non inviano periodicamente le opzioni SIP (il periodo previsto è un'opzione SIP inviata da SBC al minuto) al back-end Microsoft. Questi trunk abbassati di livello vengono inseriti alla fine dell'elenco dei trunk disponibili per la chiamata in uscita e vengono provati per ultimi, riducendo potenzialmente il tempo di configurazione delle chiamate.

Qualsiasi trunk abilitato per tale funzionalità che non invia almeno un'opzione SIP entro cinque minuti a nessuno dei proxy SIP microsoft locali (NOAM, EMEA, APAC, OCEA) viene considerato abbassato di livello. Se un trunk invia Opzioni SIP solo a un sottoinsieme di proxy SIP locali Microsoft, queste route vengono provate per prime e le altre vengono abbassate di livello.

Nota

Qualsiasi SBC (configurato nel tenant del cliente o del gestore con SendSipOptions impostato su true) che non invia OPZIONI SIP verrà abbassato di livello. I clienti che non vogliono questo comportamento devono impostare SendSipOptionssu false nella configurazione SBC. Lo stesso vale per i trunk del vettore in cui la configurazione SBC è nel gestore o nel tenant del cliente. In questi casi, quando SendSipOptions è impostato su true, SBC invia OPZIONI SIP.

Supporto SIP

Il 1° giugno 2022 Microsoft rimuoverà il supporto per sip-all.pstnhub.microsoft.com e gli FQDN sip-all.pstnhub.gov.teams.microsoft.us dalla configurazione del routing diretto.

Se non vengono eseguite azioni prima del 1° giugno, gli utenti non saranno in grado di effettuare o ricevere chiamate tramite routing diretto.

Per evitare l'impatto del servizio:

  • Usare le subnet consigliate: (52.112.0.0/14 e 52.120.0.0/14) per qualsiasi regola di classificazione o ACL.
  • Interrompere l'uso dell'FQDN sip-all quando si configurano i controlli bordo della sessione per il routing diretto.

Per altre informazioni, vedere Pianificare il routing diretto.

Nota

Gli intervalli IP presentati in questo documento sono specifici per direct routing e possono essere diversi da quelli consigliati per il client teams.

Certificati TLS

Microsoft 365 sta aggiornando Teams e altri servizi per utilizzare un diverso set di autorità di certificazione radice.

Per altre informazioni e un elenco completo dei servizi interessati, vedere Modifiche ai certificati TLS ai servizi Microsoft 365, incluso Microsoft Teams.

Autorità di certificazione

A partire dal 1° febbraio 2022, l'interfaccia SIP direct routing considererà attendibili solo i certificati firmati da autorità di certificazione (CA) che fanno parte del programma Microsoft Trusted Root Certificate Program. Esegui i passaggi seguenti per evitare l'impatto del servizio:

  • Verificare che il certificato SBC sia firmato da una CA che fa parte del programma Microsoft Trusted Root Certificate.
  • Verificare che l'estensione Utilizzo chiave estesa (EKU) del certificato includa "Autenticazione server".

Per altre informazioni sul programma Microsoft Trusted Root Certificate, vedere Requisiti del programma - Microsoft Trusted Root Program.

Per un elenco di CA attendibili, vedere Elenco di certificati CA inclusi da Microsoft.

Sostituire le intestazioni

A partire da aprile 2022, Direct Routing rifiuta le richieste SIP con l'opzione Sostituisci intestazioni definita. Non ci sono modifiche ai flussi in cui Microsoft invia l'intestazione Sostituisci al session border controller (SBC).

Controllare le configurazioni SBC e assicurarsi di non usare le intestazioni Sostituisci nelle richieste SIP.

TLS1.0 e 1.1

Per fornire la crittografia migliore della categoria ai clienti, Microsoft prevede di deprecare le versioni TLS (Transport Layer Security) 1.0 e 1.1. Il 3 aprile 2022 Microsoft forza l'uso di TLS1.2 per l'interfaccia SIP routing diretto.

Per evitare qualsiasi impatto sul servizio, assicurarsi che gli SBC siano configurati per supportare TLS1.2 e possano connettersi usando uno dei pacchetti di crittografia seguenti:

  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 ad esempio ECDHE-RSA-AES256-GCM-SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ad esempio ECDHE-RSA-AES128-GCM-SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 ad esempio ECDHE-RSA-AES256-SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 ad esempio ECDHE-RSA-AES128-SHA256