Nouveautés du routage direct

Cet article décrit les nouveautés du routage direct. Consultez régulièrement les mises à jour.

Test des extensions EKU de certificats SBC

Le 5 mars 2024 (à partir de 9 h UTC), Microsoft effectuera un test de son infrastructure de 24 heures. Pendant ce temps, les certificats des contrôleurs de frontière de session (SBC) doivent inclure à la fois l’authentification cliente et serveur pour leurs extensions d’utilisation étendue de clé (EKU). Nous vous demandons de bien vouloir vous assurer que l’extension EKU de votre certificat inclut l’authentification du serveur et l’authentification du client pour éviter toute dégradation du service.

Si votre extension de référence EKU de certificat SBC n’inclut pas à la fois l’authentification du serveur et du client, vos SBC ne pourront pas se connecter à l’infrastructure Microsoft.

Notez que le basculement final pour demander l’authentification serveur et client pour la référence EKU sera effectué le 19 mars 2024.

Pour plus d’informations, consultez Certificat approuvé public pour le SBC.

Changement de certificat SIP vers l’autorité de certification MSPKI dans les clouds DoD et GCCH

Microsoft 365 met à jour les services qui alimentent la messagerie, les réunions, la téléphonie, la voix et la vidéo pour utiliser des certificats TLS provenant d’un autre ensemble d’autorités de certification racines. Les points de terminaison affectés incluent les points de terminaison SIP de routage direct Microsoft Teams utilisés pour le trafic RTC dans les déploiements Office 365 Secteur Public - GCC High (GCCH) et DoD. La transition vers les certificats émis par la nouvelle autorité de certification pour les points de terminaison SIP commence en mai 2024. Cela signifie que des mesures doivent être prises avant fin avril 2024.

La nouvelle autorité de certification racine « DigiCert Global Root G2 » est largement approuvée par les systèmes d’exploitation, notamment Windows, macOS, Android et iOS, et par les navigateurs tels que Microsoft Edge, Chrome, Safari et Firefox. Toutefois, il est probable que votre SBC dispose d’un magasin de certificats racine configuré manuellement. Si c’est le cas, le MAGASIN DE VOTRE AUTORITÉ de certification SBC doit être mis à jour pour inclure la nouvelle autorité de certification afin d’éviter l’impact sur le service. Les contrôleurs SBC qui n’ont pas la nouvelle autorité de certification racine dans leur liste d’autorités de certification acceptables reçoivent des erreurs de validation de certificat, ce qui peut avoir un impact sur la disponibilité ou la fonction du service. L’ancienne et la nouvelle autorité de certification DOIVENT être approuvées par le SBC . Ne supprimez pas l’ancienne autorité de certification. Reportez-vous à la documentation du fournisseur SBC pour savoir comment mettre à jour la liste des certificats acceptés sur votre SBC. L’ancien et le nouveau certificat racine doivent être approuvés par le SBC. Aujourd’hui, les certificats TLS utilisés par les interfaces SIP Microsoft s’enchaînent à l’autorité de certification racine suivante :

Nom commun de l’autorité de certification : DigiCert Global Root CA Thumbprint (SHA1) : a8985d3a65e5e5c4b2d7d66d40c6dd2fb19c5436 L’ancien certificat d’autorité de certification peut être téléchargé directement à partir de DigiCert : http://cacerts.digicert.com/DigiCertGlobalRootCA.crt

Les nouveaux certificats TLS utilisés par les interfaces SIP Microsoft vont désormais être chaînés à l’autorité de certification racine suivante : Nom commun de l’autorité de certification : DigiCert Global Root G2 Thumbprint (SHA1) : df3c24f9bfd666761b268073fe06d1cc8d4f82a4 Le nouveau certificat d’autorité de certification peut être téléchargé directement à partir de DigiCert : https://cacerts.digicert.com/DigiCertGlobalRootG2.crt

Pour plus d’informations, reportez-vous aux instructions https://docs.microsoft.com/en-us/microsoft-365/compliance/encryption-office-365-tls-certificates-changes?view=o365-worldwide techniques de la page Pour tester et confirmer la configuration de votre certificat SBC avant la modification, Microsoft a préparé un point de terminaison de test qui peut être utilisé pour vérifier que les appliances SBC approuvent les certificats émis à partir de la nouvelle autorité de certification racine (DigiCert Global Root G2). Si votre SBC peut établir une connexion TLS à ce point de terminaison, votre connectivité aux services Teams ne doit pas être affectée par la modification. Ces points de terminaison doivent être utilisés uniquement pour les messages ping SIP OPTIONS et non pour le trafic vocal. Ils ne sont pas des points de terminaison de production et ne sont pas soutenus par une configuration redondante. Cela signifie qu’ils subiront des temps d’arrêt qui dureront plusieurs heures( attendez-vous à une disponibilité d’environ 95 %.

Nom de domaine complet du point de terminaison de test pour GCCH : port x.sip.pstnhub.infra.gov.teams.microsoft.us : 5061

Nom de domaine complet du point de terminaison de test pour DoD : port x.sip.pstnhub.infra.dod.teams.microsoft.us : 5061

Basculement final du certificat SIP vers la nouvelle autorité de certification MSPKI

Après deux tests les 5 et 19 septembre, Microsoft effectuera le basculement final vers la nouvelle autorité de certification le 3 octobre, à partir de 10 h UTC. Tous les points de terminaison SIP Microsoft sont basculés progressivement pour utiliser des certificats où la chaîne de certificats se cumule à l’autorité de certification « DigiCert Global Root G2 ».

Si vos contrôleurs de frontière de session (SBC) ne sont pas correctement configurés avec la nouvelle autorité de certification, vos appels entrants et sortants de routage direct échouent après le commutateur. Contactez directement votre fournisseur SBC pour obtenir des conseils supplémentaires sur la configuration de SBC.

L’exigence de modification et le test ont été communiqués aux clients du routage direct via les publications du centre de messages ainsi que les incidents d’intégrité du service dans le portail Microsoft Administration (MC540239, TM614271, MC663640, TM674073, MC674729).

Changement de test supplémentaire du certificat SIP vers l’autorité de certification MSPKI

Le 19 septembre (à partir de 16 h UTC), Microsoft effectuera un test de 24 heures où tous les points de terminaison SIP Microsoft seront basculés pour utiliser des certificats où la chaîne de certificats se cumulera vers l’autorité de certification « DigiCert Global Root G2 ». Une nouvelle autorité de certification doit être ajoutée à votre configuration SBC et l’ancienne autorité de certification Baltimore doit être conservée . ne remplacez pas l’ancienne autorité de certification. Si votre SBC n’approuve pas cette autorité de certification, vous ne pourrez pas vous connecter aux points de terminaison SIP Teams pendant le test. Le basculement final vers la nouvelle autorité de certification sera effectué le 3 octobre.

Si vous souhaitez tester et confirmer votre configuration de certificat SBC avant la modification, Microsoft a préparé un point de terminaison de test que vous pouvez utiliser pour vérifier que les appliances SBC approuvent les certificats émis à partir de la nouvelle autorité de certification racine (DigiCert Global Root G2). Ce point de terminaison doit être utilisé uniquement pour les messages ping SIP OPTIONS et non pour le trafic vocal. Si votre SBC peut établir une connexion TLS à ce point de terminaison, votre connectivité aux services Teams ne doit pas être affectée par la modification.

Nom de domaine complet du point de terminaison de test : sip.mspki.pstnhub.microsoft.com

Port : 5061

Test de modification du certificat SIP vers l’autorité de certification MSPKI

Le 5 septembre (à partir de 9 h UTC), Microsoft effectuera un test de 24 heures où tous les points de terminaison SIP Microsoft seront basculés pour utiliser des certificats où la chaîne de certificats se cumulera à l’autorité de certification « DigiCert Global Root G2 ». Si votre SBC n’approuve pas cette autorité de certification, vous ne pourrez peut-être pas vous connecter aux points de terminaison SIP Teams.

Si vous souhaitez tester et confirmer la configuration de votre certificat SBC avant la modification, Microsoft a préparé un point de terminaison de test qui peut être utilisé pour vérifier que les appliances SBC approuvent les certificats émis à partir de la nouvelle autorité de certification racine (DigiCert Global Root G2). Ce point de terminaison doit être utilisé uniquement pour les messages ping SIP OPTIONS et non pour le trafic vocal. Si votre SBC peut établir une connexion TLS à ce point de terminaison, votre connectivité aux services Teams ne doit pas être affectée par la modification.

Nom de domaine complet du point de terminaison de test : sip.mspki.pstnhub.microsoft.com

Port : 5061

Changement du certificat SIP vers l’autorité de certification MSPKI

Microsoft 365 met à jour les services qui alimentent la messagerie, les réunions, la téléphonie, la voix et la vidéo pour utiliser des certificats TLS provenant d’un autre ensemble d’autorités de certification racines. Cette modification est effectuée, car l’autorité de certification racine actuelle expire en mai 2025. Les points de terminaison affectés incluent tous les points de terminaison SIP Microsoft utilisés pour le trafic RTC qui utilisent la connectivité TLS. La transition vers les certificats émis par la nouvelle autorité de certification commence à la fin du mois d’août.

La nouvelle autorité de certification racine « DigiCert Global Root G2 » est largement approuvée par les systèmes d’exploitation, notamment Windows, macOS, Android et iOS, et par les navigateurs tels que Microsoft Edge, Chrome, Safari et Firefox. Toutefois, il est probable que votre SBC dispose d’un magasin racine de certificats configuré manuellement et qu’il doit être mis à jour. Les contrôleurs SBC qui n’ont pas la nouvelle autorité de certification racine dans leur liste d’autorités de certification acceptables reçoivent des erreurs de validation de certificat, ce qui peut avoir un impact sur la disponibilité ou la fonction du service. Reportez-vous à la documentation de votre fournisseur SBC pour savoir comment mettre à jour la liste des certificats acceptés sur votre SBC.

Aujourd’hui, les certificats TLS utilisés par les interfaces SIP Microsoft s’enchaînent à l’autorité de certification racine suivante :

Nom commun de l’autorité de certification : Baltimore CyberTrust Root Thumbprint (SHA1) : d4de20d05e66fc53fe1a50882c78db2852cae474

Les nouveaux certificats TLS utilisés par les interfaces SIP Microsoft sont désormais liés à l’autorité de certification racine suivante :

Nom commun de l’autorité de certification : DigiCert Global Root G2 Thumbprint (SHA1) : df3c24f9bfd666761b268073fe06d1cc8d4f82a4

Le nouveau certificat d’autorité de certification peut être téléchargé directement à partir de DigiCert : DigiCert Global Root G2.

Pour plus d’informations, consultez Modifications des certificats TLS Office

Nouveaux points de terminaison SIP de routage direct

Microsoft va introduire de nouvelles adresses IP de signalisation vers les points de terminaison SIP de routage direct Teams. Pour vous assurer que cette modification n’affecte pas la disponibilité de votre service, assurez-vous que votre contrôleur de bordure de session et votre pare-feu sont configurés pour utiliser les sous-réseaux recommandés 52.112.0.0/14 et 52.122.0.0/15 pour la classification et les règles de liste de contrôle d’accès. Pour plus d’informations, consultez Microsoft 365, Office 365 et Office 365 environnements GCC.

Logique de rétrogradation de jonction basée sur les options SIP

Une nouvelle fonctionnalité basée sur les options SIP est introduite pour l’intégrité de la jonction. Lorsqu’elle est activée dans la configuration de la passerelle (voir Set-CsOnlinePSTNGateway applet de commande et paramètre SendSipOptions), la logique de routage des appels sortants rétrograde les jonctions qui n’envoient pas régulièrement les options SIP (la période attendue est une option SIP envoyée par le SBC par minute) vers le serveur principal Microsoft. Ces jonctions rétrogradées sont placées à la fin de la liste des jonctions disponibles pour l’appel sortant et sont essayées en dernier, ce qui peut réduire le temps de configuration de l’appel.

Toute jonction activée pour cette fonctionnalité qui n’envoie pas au moins une option SIP dans les cinq minutes à l’un des proxys SIP régionaux Microsoft (NOAM, EMEA, APAC, OCEA) est considérée comme rétrogradée. Si une jonction envoie des options SIP uniquement à un sous-ensemble de proxys SIP régionaux Microsoft, ces itinéraires sont d’abord essayés et le reste est rétrogradé.

Remarque

Tout SBC (configuré sous le client ou le locataire de l’opérateur avec SendSipOptions défini sur true) qui n’envoie pas LES OPTIONS SIP est rétrogradé. Les clients qui ne souhaitent pas ce comportement doivent définir SendSipOptions sur false dans leur configuration SBC. Il en va de même pour les jonctions de transporteur où la configuration SBC se trouve sous le transporteur ou le locataire client. Dans ce cas, lorsque SendSipOptions est défini sur true, le SBC envoie SIP OPTIONS.

Prise en charge SIP

Le 1er juin 2022, Microsoft supprimera la prise en charge des noms de domaine complets sip-all.pstnhub.microsoft.com et sip-all.pstnhub.gov.teams.microsoft.us de la configuration du routage direct.

Si aucune action n’est effectuée avant le 1er juin, les utilisateurs ne pourront pas passer ou recevoir des appels via le routage direct.

Pour éviter l’impact sur le service :

  • Utilisez les sous-réseaux recommandés : (52.112.0.0/14 et 52.120.0.0/14) pour toutes les règles de classification ou de liste de contrôle d’accès.
  • Arrêtez l’utilisation du nom de domaine complet sip-all lors de la configuration des contrôles de bordure de session pour le routage direct.

Pour plus d’informations, consultez Planifier le routage direct.

Remarque

Les plages d’adresses IP présentées dans ce document sont spécifiques au routage direct et peuvent différer de celles recommandées pour le client Teams.

Certificats TLS

Microsoft 365 met à jour Teams et d’autres services pour utiliser un autre ensemble d’autorités de certification racines.

Pour plus d’informations et pour obtenir la liste complète des services affectés, consultez Modifications apportées aux certificats TLS des services Microsoft 365, y compris Microsoft Teams.

Autorités de certification

À compter du 1er février 2022, l’interface SIP de routage direct approuvera uniquement les certificats signés par les autorités de certification qui font partie du programme de certificats racines de confiance Microsoft. Effectuez les étapes suivantes pour éviter l’impact sur le service :

  • Vérifiez que votre certificat SBC est signé par une autorité de certification qui fait partie du programme de certificat racine approuvé Microsoft.
  • Vérifiez que l’extension Utilisation étendue de la clé (EKU) de votre certificat inclut « Authentification du serveur ».

Pour plus d’informations sur le programme de certificat racine approuvé Microsoft, consultez Configuration requise du programme - Programme racine approuvé Microsoft.

Pour obtenir la liste des autorités de certification approuvées, consultez Liste des certificats d’autorité de certification incluses par Microsoft.

Remplacer les en-têtes

À compter d’avril 2022, le routage direct rejette les demandes SIP pour lesquelles les en-têtes Replaces sont définis. Aucune modification n’est apportée aux flux dans lesquels Microsoft envoie l’en-tête Replaces au contrôleur de bordure de session (SBC).

Vérifiez vos configurations SBC et assurez-vous que vous n’utilisez pas d’en-têtes De remplacement dans les requêtes SIP.

TLS1.0 et 1.1

Pour fournir le meilleur chiffrement de sa catégorie à nos clients, Microsoft prévoit de déprécier les versions TLS (Transport Layer Security) 1.0 et 1.1. Le 3 avril 2022, Microsoft forcera l’utilisation de TLS1.2 pour l’interface SIP de routage direct.

Pour éviter tout impact sur le service, assurez-vous que vos SBC sont configurés pour prendre en charge TLS1.2 et qu’ils peuvent se connecter à l’aide de l’une des suites de chiffrement suivantes :

  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 par exemple ECDHE-RSA-AES256-GCM-SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 par exemple ECDHE-RSA-AES128-GCM-SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 par exemple ECDHE-RSA-AES256-SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 par exemple ECDHE-RSA-AES128-SHA256