Problemy z optymalizacją multimediów lokalnych na potrzeby routingu bezpośredniego

Może się okazać, że optymalizacja multimediów lokalnych (LMO) dla routingu bezpośredniego nie działa zgodnie z oczekiwaniami. Na przykład usługa Microsoft Teams nie wysyła X-Ms-UserLocation nagłówków i X-Ms-MediaPath lub X-Ms-UserLocation nagłówek zawiera nieprawidłową lokalizację lub wywołania nie powiodły się.

Ten artykuł zawiera pewne rozwiązania, które można rozwiązać.

Nagłówki X-Ms-UserLocation i X-Ms-MediaPath nie są wysyłane

Nagłówki X-Ms-UserLocation i X-Ms-MediaPath są wymagane dla LMO. Jednym z najczęstszych powodów, dla których te nagłówki nie są wysyłane, jest to, że brama nie jest poprawnie skonfigurowana dla usługi LMO.

Aby sprawdzić konfigurację bramy, uruchom następujące polecenie cmdlet Get-CsOnlinePSTNGateway :

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

Aby umożliwić obsługę LMO, upewnij się, że ustawiono wszystkie właściwości wybrane w tym poleceniu cmdlet. Jest to szczególnie ważne w przypadku programu BypassMode. Oto przykład danych wyjściowych z tego polecenia 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 

Uwaga: Wyświetlane tutaj wartości mogą różnić się od wyświetlanych.

Nieprawidłowa lokalizacja wysłana w nagłówku X-Ms-UserLocation

Jeśli informacje o lokalizacji sieciowej w nagłówku X-Ms-UserLocation są określone jako zewnętrzne, ale oczekujesz, że zobaczysz wartość wewnętrzną, oznacza to, że publiczny adres IP klienta usługi Teams nie jest zgodny z żadnym wpisem na liście zaufanych adresów IP.

Aby rozwiązać ten problem, zidentyfikuj publiczny adres IP klienta używany przez usługę Teams, a następnie dodaj go do listy.

1. Otwórz pliki dziennika usługi Microsoft Teams.

2. Znajdź publiczny adres IP wymieniony dla klienta w pliku _calling.txtdziennika diagnostyki MSTeams [Date]__[Time] . Oto przykład tego pliku:

   

3. Uruchom polecenie cmdlet Get-CsTenantTrustedIPAddress , aby uzyskać listę zaufanych adresów IP:

   Get-CsTenantTrustedIPAddress
   

   Wyświetlone dane wyjściowe powinny wyglądać podobnie do następujących:

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

   Zwróć uwagę, że na tej liście brakuje adresu IP klienta zidentyfikowanego w kroku 2.

4. Uruchom polecenie cmdlet New-CsTenantTrustedIPAddress , aby dodać brakujący adres IP do listy:

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

   Dane wyjściowe polecenia cmdlet powinny przypominać następujący przykład:

   

   Widać, że adres IP klienta został dodany do listy zaufanych adresów IP.

5. Uruchom ponownie klienta usługi Teams, aby można było natychmiast rozpoznać nowo dodany adres IP. W przeciwnym razie aktualizacja listy może potrwać do 30 minut.

   Po ponownym uruchomieniu usługa Teams znajdzie dopasowanie dla adresu IP klienta na liście zaufanych adresów IP, jak pokazano w poniższym przykładzie:

   

Połączenia przychodzące kończą się niepowodzeniem lub przejdź do poczty głosowej, jeśli włączono zarówno LMO, jak i LBR

Jedną z najbardziej prawdopodobnych przyczyn tego problemu jest to, że nagłówki lub informacje o routingu nie są poprawnie skonfigurowane na kontrolerze obramowania sesji (SBC), z którego jest odbierane wywołanie.

Sprawdź, czy nagłówki komunikatów protokołu SIP (Session Initiation Protocol) wysyłane z protokołu SBC zawierają następujące informacje i zaktualizuj je, jeśli są one nieprawidłowe:

• Identyfikator URI SIP zawiera w pełni kwalifikowaną nazwę domeny (FQDN) regionalnego protokołu SBC.
• Nagłówek Kontakt zawiera nazwę FQDN regionalnego protokołu SBC.
• Record-Route zawiera nazwę FQDN serwera proxy SBC.

Jeśli serwer proxy SBC nie jest zdefiniowany dla regionalnego protokołu SBC, sprawdzana jest tylko Record-Route. Jeśli brakuje Record-Route, zostanie zaznaczony nagłówek Kontakt.

Jeśli nagłówki są poprawnie skonfigurowane, problem może być spowodowany nieprawidłowo skonfigurowanym routingiem na serwerze SBC.

Upewnij się, że usługa SBC ma włączoną funkcję routingu Location-Based (LBR). Parametr GatewaySiteLbrEnabled musi być ustawiony na wartość True.

Ponadto protokół SBC musi być przypisany do tej samej lokacji co klient inicjujący wywołanie.

Uwaga: Nie trzeba włączać protokołu SBC serwera proxy dla modułu RÓWNOWAŻENIA OBCIĄŻENIA.

Aby ustalić, czy przypisanie SBC jest poprawne, zidentyfikuj witrynę użytkownika zarejestrowaną w dziennikach klienta usługi Teams i porównaj ją z informacjami o przypisaniu dla protokołu SBC:

1. Otwórz pliki dziennika usługi Microsoft Teams.

2. Zidentyfikuj informacje o witrynie użytkownika wymienione w pliku _calling.txtdziennika diagnostyki MSTeams [Date]__[Time] . Oto przykład tego pliku:

   

3. Uruchom polecenie cmdlet Get-CsOnlinePSTNGateway , aby sprawdzić konfigurację protokołu SBC. Wyświetlone dane wyjściowe powinny wyglądać podobnie do następującego przykładu:

   

4. W danych wyjściowych z kroku 2 wartość parametru networksiteId wymienionego w informacjach o witrynie użytkownika to "Wietnam". Jednak w danych wyjściowych z kroku 3 wartość równoważnego GatewaySiteId parametru wymienionego w konfiguracji SBC to "Indie". Jest to niezgodność. Aby zaktualizować konfigurację protokołu SBC, uruchom polecenie cmdlet Set-CsOnlinePSTNGateway w następujący sposób:

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

   Następnie uruchom Get-CsOnlinePSTNGateway polecenie cmdlet, aby zweryfikować zaktualizowaną konfigurację protokołu SBC. Dane wyjściowe powinny teraz pokazywać poprawną wartość parametru GatewaySiteId .

   

Nadal potrzebujesz pomocy? Przejdź do witryny Microsoft Community.