Probleme mit der Optimierung lokaler Medien für direct Routing

Sie können feststellen, dass die Lokale Medienoptimierung (Local Media Optimization, LMO) für Direct Routing nicht wie erwartet funktioniert. Beispielsweise sendet Microsoft Teams die  X-Ms-UserLocation    X-Ms-MediaPath   Kopfzeilen nicht, oder die  X-Ms-UserLocation   Kopfzeile enthält die falsche Position, oder Aufrufe schlagen fehl.

Dieser Artikel enthält einige Lösungen, die Sie versuchen können, diese Probleme zu beheben.

X-Ms-UserLocation- und X-Ms-MediaPath-Header werden nicht gesendet

Die X-Ms-UserLocation X-Ms-MediaPath Kopfzeilen und die Kopfzeilen sind für LMO erforderlich. Einer der häufigsten Gründe, warum diese Header nicht gesendet werden, ist, dass das Gateway nicht ordnungsgemäß für LMO konfiguriert ist.

Führen Sie das folgende Get-CsOnlinePSTNGateway-Cmdlet aus, um die Gatewaykonfiguration zu überprüfen:

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

Damit LMO aktiviert wird, stellen Sie sicher, dass alle in diesem Cmdlet ausgewählten Eigenschaften festgelegt sind. Dies ist besonders wichtig für BypassMode . Hier ist ein Beispiel für die Ausgabe dieses Cmdlets:

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 

Hinweis: Die hier angezeigten Werte unterscheiden sich möglicherweise von den hier angezeigten Werten.

Falscher Speicherort im X-Ms-UserLocation-Header

Wenn die Netzwerkspeicherortinformationen im X-Ms-UserLocation Header als extern angegeben sind, Sie jedoch einen internen Wert erwarten, bedeutet dies, dass die öffentliche IP-Adresse des Teams Clients keinem Eintrag in der Liste der vertrauenswürdigen IP-Adressen entspricht.

Um dieses Problem zu beheben, identifizieren Sie die öffentliche IP-Adresse des Clients, die von Teams verwendet wird, und fügen Sie sie dann der Liste hinzu.

  1. Öffnen Sie Microsoft Teams Protokolldateien.

  2. Suchen Sie die für den Client aufgelistete öffentliche IP-Adresse in der Datei "MSTeams Diagnostics Log [Date]__[Time]_calling.txt".   Hier ist ein Beispiel für diese Datei:

    Screenshot, der die öffentliche IP-Adresse in der TXT-Datei zeigt.

  3. Führen Sie das Cmdlet "Get-CsTenantTrustedIPAddress" aus, um die Liste der vertrauenswürdigen IP-Adressen abzurufen:

    Get-CsTenantTrustedIPAddress
    

    Die angezeigte Ausgabe sollte etwa wie folgt aussehen:

    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" />
    

    Beachten Sie, dass die in Schritt 2 identifizierte IP-Adresse des Clients in dieser Liste fehlt.

  4. Führen Sie das Cmdlet "New-CsTenantTrustedIPAddress" aus, um der Liste die fehlende IP-Adresse hinzuzufügen:

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

    Die Ausgabe des Cmdlets sollte dem folgenden Beispiel ähneln:

    Screenshot, der das Hinzufügen einer fehlenden IP-Adresse zeigt.

    Sie können sehen, dass die IP-Adresse des Clients jetzt der Liste der vertrauenswürdigen IP-Adressen hinzugefügt wurde.

  5. Starten Sie den Teams Client neu, damit die neu hinzugefügte IP-Adresse sofort erkannt werden kann. Andernfalls kann es bis zu 30 Minuten dauern, bis die Liste aktualisiert wurde.

    Nach dem Neustart finden Teams eine Übereinstimmung für die IP-Adresse des Clients in der Liste der vertrauenswürdigen IP-Adressen, wie im folgenden Beispiel gezeigt:

    Screenshot der übereinstimmende IP-Adresse.

Eingehende Anrufe schlagen fehl oder gehen zu Voicemail, wenn LMO und LBR aktiviert sind

Einer der wahrscheinlichsten Gründe für dieses Problem ist, dass die Kopfzeilen oder die Routinginformationen auf dem Session Border Controller (SBC), von dem der Anruf empfangen wird, nicht ordnungsgemäß konfiguriert sind.

Überprüfen Sie, ob die vom SBC gesendeten SIP-Nachrichtenheader (Session Initiation Protocol) die folgenden Informationen enthalten, und aktualisieren Sie sie, wenn sie falsch sind:

  • Der SIP-URI enthält den vollqualifizierten Domänennamen (Fully Qualified Domain Name, FQDN) des regionalen SBC.
  • Die Kopfzeile "Kontakt" enthält den FQDN des regionalen SBC.
  • Die Record-Route enthält den FQDN des Proxy-SBC.

Wenn kein Proxy-SBC für den regionalen SBC definiert ist, wird nur die Record-Route überprüft. Wenn die Record-Route fehlt, wird die Kopfzeile des Kontakts überprüft.

Wenn die Header ordnungsgemäß konfiguriert sind, kann das Problem durch ein falsch konfiguriertes Routing auf dem SBC verursacht werden.

Stellen Sie sicher, dass für den SBC Location-Based Routing (LBR) aktiviert ist. Der GatewaySiteLbrEnabled Parameter muss auf True festgelegt sein.

Außerdem muss der SBC demselben Standort wie der Client zugewiesen werden, der den Anruf initiiert.

Hinweis: Der Proxy-SBC muss nicht für LBR aktiviert sein.

Um festzustellen, ob die SBC-Zuweisung korrekt ist, identifizieren Sie die Benutzerwebsite, die in den Teams Clientprotokollen registriert ist, und vergleichen Sie sie mit den Zuordnungsinformationen für den SBC:

  1. Öffnen Sie Microsoft Teams Protokolldateien.

  2. Identifizieren Sie die Benutzerwebsiteinformationen, die im MSTeams-Diagnoseprotokoll [Date]__[Time]_calling.txt-Datei aufgeführt   sind. Hier ist ein Beispiel für diese Datei:

    Screenshot der TXT-Datei mit den Websiteinformationen.

  3. Führen Sie das Cmdlet "Get-CsOnlinePSTNGateway" aus, um die Konfiguration des SBC zu überprüfen. Die angezeigte Ausgabe sollte dem folgenden Beispiel ähneln:

    Screenshot, der die Überprüfung der S B C-Konfiguration zeigt.

  4. In der Ausgabe aus Schritt 2 lautet der Wert des Parameters, der networksiteId in den Benutzerwebsiteinformationen aufgeführt ist, "Vietnam". In der Ausgabe aus Schritt 3 lautet der Wert des entsprechenden Parameters, der GatewaySiteId in der SBC-Konfiguration aufgeführt ist, jedoch "Indien". Dies ist ein Konflikt. Führen Sie das Cmdlet "Set-CsOnlinePSTNGateway" wie folgt aus, um die Konfiguration des SBC zu aktualisieren:

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

    Führen Sie als Nächstes das Get-CsOnlinePSTNGateway Cmdlet aus, um die aktualisierte Konfiguration des SBC zu überprüfen. Die Ausgabe sollte nun den richtigen Wert für den GatewaySiteId Parameter anzeigen.

    Screenshot der Aktualisierung von Gateway site I d.

Benötigen Sie weitere Hilfe? Wechseln Sie zu Microsoft Community.