Problèmes liés à l’optimisation des médias locaux pour le routage direct

• S’applique à:

  Microsoft Teams

Vous constaterez peut-être que l’optimisation des médias locaux (LMO) pour le routage direct ne fonctionne pas comme prévu. Par instance, Microsoft Teams n’envoie pas les X-Ms-UserLocation en-têtes et X-Ms-MediaPath , ou l’en-tête X-Ms-UserLocation contient un emplacement incorrect ou les appels échouent.

Cet article fournit des solutions que vous pouvez essayer de résoudre ces problèmes.

Les en-têtes X-Ms-UserLocation et X-Ms-MediaPath ne sont pas envoyés

Les X-Ms-UserLocation en-têtes et X-Ms-MediaPath sont requis pour LMO. L’une des raisons les plus courantes pour lesquelles ces en-têtes ne sont pas envoyés est que la passerelle n’est pas configurée correctement pour LMO.

Pour case activée la configuration de la passerelle, exécutez l’applet de commande Get-CsOnlinePSTNGateway suivante :

Get-CSOnlinePSTNGateway | Select Identity, Fqdn, Enabled, MediaBypass, GatewaySiteId, ProxySbc, BypassMode

Pour activer LMO, assurez-vous que toutes les propriétés sélectionnées dans cette applet de commande sont définies. Cela est particulièrement important pour BypassMode. Voici un exemple de sortie de cette applet de commande :

Identity        : VNsbc.contoso.com 
Fqdn            : VNsbc.contoso.com 
Enabled         : True 
MediaBypass     : True 
GatewaySiteId   : Vietnam 
ProxySbc        : proxysbc.contoso.com 
BypassMode      : Always 

Identity        : proxysbc.contoso.com 
Fqdn            : proxysbc.contoso.com 
Enabled         : True 
MediaBypass     : True 
GatewaySiteId   : Singapore 
ProxySbc        :  
BypassMode      : Always 

Note: Les valeurs affichées ici peuvent être différentes de celles que vous voyez.

Emplacement incorrect envoyé dans l’en-tête X-Ms-UserLocation

Si les informations d’emplacement réseau dans l’en-tête X-Ms-UserLocation sont spécifiées comme externes, mais que vous vous attendez à voir une valeur interne, cela signifie que l’adresse IP publique du client Teams ne correspond à aucune entrée dans la liste des adresses IP approuvées.

Pour résoudre ce problème, identifiez l’adresse IP publique du client utilisée par Teams, puis ajoutez-la à la liste.

1. Ouvrez les fichiers journaux Microsoft Teams.

2. Recherchez l’adresse IP publique répertoriée pour le client dans le fichier journal de diagnostics MSTeams [Date]__[Heure]_calling.txt fichier. Voici un exemple de ce fichier :

   

3. Exécutez l’applet de commande Get-CsTenantTrustedIPAddress pour obtenir la liste des adresses IP approuvées :

   Get-CsTenantTrustedIPAddress
   

   La sortie que vous voyez doit ressembler à ce qui suit :

   Identity      : 192.168.0.0 
   RemoteMachine : WU22A00TAD02.lync2A001.local
   MaskBits      : 24
   Description   : Private IP subnet
   IPAddress     : 192.168.0.0 
   Element       : <TrustedIPAddress IPAddress="192.168.0.0" MaskBits="24" 
   Description="Private IP subnet" 
   xmlns="urn:schema:Microsoft.Rtc.Management.Settings.TenantNetworkConfiguration.2017" />
   

   Notez que l’adresse IP du client identifiée à l’étape 2 est manquante dans cette liste.

4. Exécutez l’applet de commande New-CsTenantTrustedIPAddress pour ajouter l’adresse IP manquante à la liste :

   New-CsTenantTrustedIPAddress -IPAddress 123.456.123.0 -MaskBits 29 -Description "Seattle site trusted IP"
   

   La sortie de l’applet de commande doit ressembler à l’exemple suivant :

   

   Vous pouvez voir que l’adresse IP du client a été ajoutée à la liste des adresses IP approuvées.

5. Redémarrez le client Teams afin que l’adresse IP nouvellement ajoutée puisse être reconnue immédiatement. Sinon, la mise à jour de la liste peut prendre jusqu’à 30 minutes.

   Après le redémarrage, Teams trouvera une correspondance pour l’adresse IP du client dans la liste des adresses IP approuvées, comme indiqué dans l’exemple suivant :

   

Échec des appels entrants ou accès à la messagerie vocale si LMO et LBR sont activés

L’une des raisons les plus probables pour lesquelles ce problème se produit est que les en-têtes ou les informations de routage ne sont pas configurés correctement sur le contrôleur de bordure de session (SBC) à partir duquel l’appel est reçu.

Vérifiez que les en-têtes de message SIP (Session Initiation Protocol) envoyés à partir du SBC contiennent les informations suivantes et mettez-les à jour s’ils sont incorrects :

• L’URI SIP contient le nom de domaine complet (FQDN) du SBC régional.
• L’en-tête Contact contient le nom de domaine complet du SBC régional.
• Le Record-Route contient le nom de domaine complet du SBC proxy.

Si un SBC proxy n’est pas défini pour le SBC régional, seul le Record-Route est vérifié. Si le Record-Route est manquant, l’en-tête Contact est coché.

Si les en-têtes sont correctement configurés, le problème peut être dû à un routage mal configuré sur le SBC.

Vérifiez que le routage Location-Based (LBR) est activé pour le SBC. Le GatewaySiteLbrEnabled paramètre doit être défini sur True.

En outre, le SBC doit être affecté au même site que le client qui lance l’appel.

Note: Le SBC proxy n’a pas besoin d’être activé pour LBR.

Pour déterminer si l’affectation SBC est correcte, identifiez le site utilisateur inscrit dans les journaux du client Teams et comparez-le avec les informations d’affectation du SBC :

1. Ouvrez les fichiers journaux Microsoft Teams.

2. Identifiez les informations du site utilisateur répertoriées dans le fichier journal de diagnostics MSTeams [Date]__[Heure]_calling.txt fichier. Voici un exemple de ce fichier :

   

3. Exécutez l’applet de commande Get-CsOnlinePSTNGateway pour case activée la configuration du SBC. La sortie que vous voyez doit ressembler à l’exemple suivant :

   

4. Dans la sortie de l’étape 2, la valeur du networksiteId paramètre répertorié dans les informations du site utilisateur est « Vietnam ». Toutefois, dans la sortie de l’étape 3, la valeur du paramètre équivalent GatewaySiteId répertorié dans la configuration du SBC est « India ». Il s’agit d’une incompatibilité. Pour mettre à jour la configuration du SBC, exécutez l’applet de commande Set-CsOnlinePSTNGateway , comme suit :

   Set-CSOnlinePSTNGateway -Identity "VNsbc.contoso.com" -GatewaySiteID "Vietnam"
   

   Ensuite, exécutez l’applet Get-CsOnlinePSTNGateway de commande pour vérifier la configuration mise à jour du SBC. La sortie doit maintenant afficher la valeur correcte pour le GatewaySiteId paramètre .

   

Encore besoin d’aide ? Accédez à Microsoft Community.