Problèmes avec l’optimisation des médias locaux pour le routage direct

Il se peut que vous trouviez que l’optimisation des médias locaux (LMO) pour le routage direct ne fonctionne pas comme prévu. Par exemple, Microsoft Teams’envoie pas les en-têtes  X-Ms-UserLocation   et les  X-Ms-MediaPath   en-têtes, si l’en-tête contient un emplacement erroné ou que les  X-Ms-UserLocation   appels échouent.

Cet article fournit certaines résolutions que vous pouvez essayer de résoudre.

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

Les X-Ms-UserLocation X-Ms-MediaPath en-têtes et les en-têtes 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 vérifier la configuration de la passerelle, exécutez l’cmdlet 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 cmdlet sont définies. Ceci est particulièrement important pour BypassMode . Voici un exemple de sortie de cette cmdlet :

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 

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

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

Si les informations d’emplacement réseau dans l’en-tête sont spécifiées comme externes, mais que vous prévoyez de 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 de X-Ms-UserLocation confiance. ****

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

  1. Ouvrez Microsoft Teams journaux.

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

    Capture d’écran de l’adresse IP publique dans le fichier txt.

  3. Exécutez l’cmdlet Get-CsTenantTrustedIPAddress pour obtenir la liste des adresses IP de confiance :

    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’cmdlet 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 la cmdlet doit ressembler à l’exemple suivant :

    Capture d’écran de l’ajout d’une adresse IP manquante.

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

  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 trouve une correspondance pour l’adresse IP du client dans la liste des adresses IP de confiance, comme illustré dans l’exemple suivant :

    Capture d’écran de l’adresse IP de correspondance.

Les appels entrants échouent ou sont dirigés vers la messagerie vocale si LMO et LBR sont activés

L’une des raisons les plus probables de ce problème est que les en-têtes ou les informations de routage ne sont pas configurés correctement sur le contrôleur SBC (Session Border Controller) à 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 FQDN du SBC régional.
  • Le Record-Route contient le FQDN du SBC proxy.

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

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

Assurez-vous que le SBC a activé Location-Based routage de l’utilisateur( LBR). Le GatewaySiteLbrEnabled paramètre doit être définie sur True.

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

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

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

  1. Ouvrez Microsoft Teams journaux.

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

    Capture d’écran du fichier txt avec les informations du site.

  3. Exécutez l’cmdlet Get-CsOnlinePSTNGateway pour vérifier la configuration du SBC. La sortie que vous voyez doit ressembler à l’exemple suivant :

    Capture d’écran de la vérification de la configuration du SBC.

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

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

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

    Capture d’écran de la mise à jour de GatewaySiteId.

Vous avez encore besoin d’aide ? Go to Microsoft Community.