Novità per il routing diretto

• Si applica a:

  Microsoft Teams

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

Aggiornamento metrico Network Effectiveness Ratio (NER)

Per migliorare l'esperienza con la visibilità dei possibili problemi che influiscono sull'affidabilità del routing diretto, stiamo aggiornando la formula per calcolare la metrica Network Effectiveness Ratio (NER). A partire dall'11 novembre 2024, si potrebbe notare un leggero cambiamento nel NER segnalato per i trunk in Teams Amministrazione Center (TAC). Se si nota un calo del valore NER, è possibile identificare la causa di un errore di chiamata esaminando specifici codici di risposta. Per un elenco degli errori più comuni e delle azioni suggerite per risolverli, vedere Codici di risposta Microsoft e SIP.

È disponibile la nuova versione Survivable Branch Appliance (v2024.8.15.1)

Il nuovo Survivable Branch Appliance (SBA) per la versione Direct Routing è disponibile a partire dal 23 settembre 2024. La versione più recente supporta le funzionalità seguenti:

• Effettuare chiamate PSTN tramite SBA/SBC locale con elementi multimediali che attraversano il server SBC.
• Ricezione di chiamate PSTN tramite SBA/SBC locale con elementi multimediali che attraversano il server SBC.
• Sospendere e riprendere le chiamate PSTN.
• Trasferimento cieco.
• Inoltro di chiamata a un singolo numero di telefono o a un utente di Teams.
• Inoltro di chiamata senza risposta a un singolo numero di telefono o a un utente di Teams.
• Reindirizzamento della chiamata PSTN in arrivo a un numero di coda di chiamata o operatore automatico a un agente locale.
• Reindirizzamento della chiamata PSTN in arrivo a un numero della coda di chiamata o dell'operatore automatico a un numero alternativo coda di chiamata o operatore automatico.
• Fallback VoIP. Se non è possibile avviare una chiamata VoIP e la parte ricevente ha un numero PSTN, viene tentata una chiamata PSTN.
• Chiamate VoIP tra utenti locali. Se entrambi gli utenti sono registrati dietro la stessa SBA, è possibile avviare una chiamata VoIP invece di chiamata PSTN e l'SBA supporta la chiamata. Per ottenere la versione più recente, contattare il fornitore di SBC. Per l'elenco dei fornitori SBC supportati, fare riferimento alla configurazione del controller dei confini della sessione. Per ulteriori informazioni su Survivable Branch Appliance (SBA), vedi Survivable Branch Appliance (SBA) for Direct Routing.

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 SBC non include sia Autenticazione server che Autenticazione client, gli SBC non si connetteranno all'infrastruttura Microsoft.

Si noti 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 ca precedente. 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 altre informazioni, vedere le indicazioni tecniche in Dettagli autorità di certificazione di Azure. Per 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 certificati di attendibilità degli accessori SBC 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. Collaborare direttamente con il fornitore di SBC per ulteriori 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).

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

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

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

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 introduce 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

Articoli correlati

• Direct Routing - Protocollo SIP