Nouveautés du routage direct

• S’applique à:

  Microsoft Teams

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

Mise à jour de la métrique NER (Network Effectiveness Ratio)

Pour améliorer l’expérience avec la visibilité des problèmes possibles affectant la fiabilité de votre routage direct, nous mettons à jour la formule pour calculer la métrique pour le ratio d’efficacité du réseau (NER). À partir du 11 novembre 2024, vous remarquerez peut-être une légère modification de la NER signalée pour vos jonctions dans le Centre Administration Teams (TAC). Si vous remarquez une baisse de la valeur NER, vous pouvez identifier la cause d’un échec d’appel en examinant des codes de réponse spécifiques. Pour obtenir la liste des erreurs les plus courantes et des actions suggérées pour les résoudre, consultez Codes de réponse Microsoft et SIP.

La nouvelle version de Survivable Branch Appliance (v2024.8.15.1) est disponible

La nouvelle version de Survivable Branch Appliance (SBA) pour le routage direct est disponible à partir du 23 septembre 2024. La dernière version prend en charge les fonctionnalités suivantes :

• Effectuer des appels RTC via l’authentification SBA/SBC locale avec un média transitant par le SBC.
• Réception d’appels RTC via l’authentification SBA/SBC locale avec le média transitant par le SBC.
• Conservation et reprise des appels RTC.
• Transfert à l’aveugle.
• Transfert d’appel vers un seul numéro de téléphone ou un utilisateur Teams.
• Transfert d’appel sans réponse vers un seul numéro de téléphone ou un utilisateur Teams.
• Redirection de l’appel RTC entrant vers une file d’attente d’appels ou un numéro de standard automatique vers un agent local.
• Rediriger l’appel RTC entrant vers une file d’attente d’appels ou un numéro de standard automatique vers une autre file d’attente d’appels ou un numéro de standard automatique.
• VoIP de secours. Si un appel VoIP ne peut pas être lancé et que la partie réceptrice a un numéro RTC, un appel RTC est tenté.
• Appels VoIP entre utilisateurs locaux. Si les deux utilisateurs sont inscrits derrière la même SBA, un appel VoIP peut être lancé au lieu d’un appel RTC, et l’authentification unique prend en charge l’appel. Pour obtenir la dernière version, contactez votre fournisseur SBC. Pour obtenir la liste des fournisseurs SBC pris en charge, consultez Configuration du contrôleur de bordure de session. Pour en savoir plus sur Survivable Branch Appliance (SBA), consultez Survivable Branch Appliance (SBA) pour le routage direct.

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 l’extension EKU de certificat de votre SBC n’inclut pas l’authentification du serveur et du client, vos SBC ne se connectent pas à 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 conseils techniques de la page Détails de l’autorité de certification Azure. 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 certificat SIP vers l’autorité de certification MSPKI, test supplémentaire

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

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

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 introduit de nouvelles adresses IP de signalisation pour 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

Articles connexes

• Routage direct - Protocole SIP