Probleme mit der Optimierung lokaler Medien für Direct Routing

• Gilt für::

  Microsoft Teams

Möglicherweise stellen Sie fest, dass die lokale Medienoptimierung (Local Media Optimization, LMO) für Direct Routing nicht wie erwartet funktioniert. Für instance sendet X-Ms-UserLocation Microsoft Teams die Header und X-Ms-MediaPath nicht, oder der X-Ms-UserLocation Header enthält den falschen Speicherort, oder Aufrufe schlagen fehl.

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

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

Die X-Ms-UserLocation Header und X-Ms-MediaPath 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 zum Überprüfen der Gatewaykonfiguration das folgende Cmdlet Get-CsOnlinePSTNGateway aus:

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

Damit LMO aktiviert wird, stellen Sie sicher, dass alle eigenschaften, die in diesem Cmdlet ausgewählt sind, festgelegt sind. Dies ist besonders wichtig für BypassMode. Hier sehen Sie 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 angezeigten Werten.

Falscher Speicherort im X-Ms-UserLocation-Header gesendet

Wenn die Netzwerkadresseninformationen im X-Ms-UserLocation Header als extern angegeben sind, Sie jedoch den Wert intern 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 öffentliche IP-Adresse, die für den Client im MSTeams-Diagnoseprotokoll [Datum]__[Uhrzeit]_calling.txt Datei aufgeführt ist. Hier sehen Sie ein Beispiel für diese Datei:

   

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

   Get-CsTenantTrustedIPAddress
   

   Die angezeigte Ausgabe sollte in 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 in etwa wie im folgenden Beispiel aussehen:

   

   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 wird.

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

   

Eingehende Anrufe schlagen fehl oder gehen in die Voicemail, wenn sowohl LMO als auch LBR aktiviert sind

Einer der wahrscheinlichsten Gründe für dieses Problem ist, dass entweder die Header oder die Routinginformationen auf dem Session Border Controller (SBC), von dem der Aufruf 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.
• Der Contact-Header 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 der Kontaktheader aktiviert.

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 werden.

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

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

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

1. Öffnen Sie Microsoft Teams-Protokolldateien.

2. Identifizieren Sie die Benutzerwebsiteinformationen, die in der MsTeams-Diagnoseprotokolldatei [Datum]__[Uhrzeit]_calling.txt-Datei aufgeführt sind. Hier sehen Sie ein Beispiel für diese Datei:

   

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

   

4. In der Ausgabe von Schritt 2 lautet der Wert des Parameters, der networksiteId in den Informationen zur Benutzerwebsite aufgeführt ist, "Vietnam". In der Ausgabe von Schritt 3 lautet der Wert des entsprechenden GatewaySiteId Parameters, der in der Konfiguration des SBC aufgeführt ist, jedoch "India". 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.

   

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