Udostępnij za pośrednictwem


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:

    Zrzut ekranu przedstawiający publiczny adres IP w pliku txt.

  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:

    Zrzut ekranu przedstawiający dodawanie brakującego adresu IP.

    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:

    Zrzut ekranu przedstawiający dopasowany adres IP.

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:

    Zrzut ekranu przedstawiający plik txt z informacjami o witrynie.

  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:

    Zrzut ekranu przedstawiający sprawdzanie konfiguracji S B C.

  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 .

    Zrzut ekranu przedstawiający aktualizowanie witryny bramy I d.

Nadal potrzebujesz pomocy? Przejdź do witryny Microsoft Community.