Problemas com a Otimização de Mídia Local para Roteamento Direto

Artigo
03/18/2023
Aplica-se a:

Microsoft Teams

Você pode descobrir que a LMO (Otimização de Mídia Local) para Roteamento Direto não funciona conforme o esperado. Por exemplo, o Microsoft Teams não envia X-Ms-UserLocationX-Ms-MediaPathX-Ms-UserLocation os cabeçalhos ou o cabeçalho contém o local errado ou as chamadas falham.

Este artigo fornece algumas resoluções que você pode tentar corrigir esses problemas.

Os cabeçalhos X-Ms-UserLocation e X-Ms-MediaPath não são enviados

Os X-Ms-UserLocation cabeçalhos X-Ms-MediaPath e os cabeçalhos são necessários para o LMO. Um dos motivos mais comuns pelos quais esses cabeçalhos não são enviados é que o gateway não está configurado corretamente para LMO.

Para verificar a configuração do gateway, execute o seguinte cmdlet Get-CsOnlinePSTNGateway :

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

Para que o LMO seja habilitado, verifique se todas as propriedades selecionadas neste cmdlet estão definidas. Isso é especialmente importante para BypassMode. Aqui está um exemplo da saída deste 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

Nota: Os valores exibidos aqui podem ser diferentes do que você vê.

Local incorreto enviado no cabeçalho X-Ms-UserLocation

X-Ms-UserLocation Se as informações de local de rede no cabeçalho são especificadas como externas, mas você espera ver um valor interno, isso significa que o endereço IP público do cliente teams não corresponde a nenhuma entrada na lista de endereços IP confiáveis.

Para corrigir esse problema, identifique o endereço IP público do cliente usado pelo Teams e, em seguida, adicione-o à lista.

Abra arquivos de log do Microsoft Teams.
Localize o endereço IP público listado para o cliente no log de diagnóstico do MSTeams [Date]__[Time]_calling.txt arquivo. Aqui está um exemplo deste arquivo:

Execute o cmdlet Get-CsTenantTrustedIPAddress para obter a lista de endereços IP confiáveis:

Get-CsTenantTrustedIPAddress

A saída que você vê deve ser semelhante à seguinte:

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

Observe que o endereço IP do cliente identificado na etapa 2 está ausente nesta lista.

Execute o cmdlet New-CsTenantTrustedIPAddress para adicionar o endereço IP ausente à lista:
```
New-CsTenantTrustedIPAddress -IPAddress 123.456.123.0 -MaskBits 29 -Description "Seattle site trusted IP"
```
A saída do cmdlet deve ser semelhante ao exemplo a seguir:

Você pode ver que o endereço IP do cliente agora foi adicionado à lista de endereços IP confiáveis.
Reinicie o cliente do Teams para que o endereço IP recém-adicionado possa ser reconhecido imediatamente. Caso contrário, a lista pode levar até 30 minutos para ser atualizada.

Após a reinicialização, o Teams encontrará uma correspondência para o endereço IP do cliente na lista de endereços IP confiáveis, conforme mostrado no exemplo a seguir:

As chamadas de entrada falharão ou acessarão a caixa postal se LMO e LBR forem habilitados

Um dos motivos mais prováveis para esse problema ocorrer é que os cabeçalhos ou as informações de roteamento não estão configurados corretamente no Controlador de Borda de Sessão (SBC) do qual a chamada é recebida.

Verifique se os cabeçalhos de mensagem SIP (Protocolo de Iniciação de Sessão) enviados do SBC contêm as seguintes informações e atualize-os se estiverem incorretos:

O URI SIP contém o FQDN (Nome de Domínio Totalmente Qualificado) do SBC regional.
O cabeçalho Contato contém o FQDN do SBC regional.
O Record-Route contém o FQDN do SBC do proxy.

Se um SBC de proxy não estiver definido para o SBC regional, somente o Record-Route será verificado. Se a Record-Route estiver ausente, o cabeçalho Contato será verificado.

Se os cabeçalhos forem configurados corretamente, o problema poderá ser causado por um roteamento configurado incorretamente no SBC.

Certifique-se de que o SBC tenha Location-Based LBR (roteamento automático) habilitado. O GatewaySiteLbrEnabled parâmetro deve ser definido como True.

Além disso, o SBC deve ser atribuído ao mesmo site que o cliente que está iniciando a chamada.

Nota: O SBC do proxy não precisa ser habilitado para LBR.

Para determinar se a atribuição SBC está correta, identifique o site do usuário registrado nos logs de cliente do Teams e compare-o com as informações de atribuição do SBC:

Abra arquivos de log do Microsoft Teams.
Identifique as informações do site do usuário listadas no log de diagnóstico do MSTeams [Data]__[Hora]_calling.txt arquivo. Aqui está um exemplo deste arquivo:
Execute o cmdlet Get-CsOnlinePSTNGateway para verificar a configuração do SBC. A saída que você vê deve ser semelhante ao exemplo a seguir:
Na saída da etapa 2, networksiteId o valor do parâmetro listado nas informações do site do usuário é "Vietnã". No entanto, na saída da etapa 3, GatewaySiteId o valor do parâmetro equivalente listado na configuração do SBC é "Índia". Isso é uma incompatibilidade. Para atualizar a configuração do SBC, execute o cmdlet Set-CsOnlinePSTNGateway , da seguinte maneira:
```
Set-CSOnlinePSTNGateway -Identity "VNsbc.contoso.com" -GatewaySiteID "Vietnam"
```
Em seguida, execute o Get-CsOnlinePSTNGateway cmdlet para verificar a configuração atualizada do SBC. A saída agora deve mostrar o valor correto para o GatewaySiteId parâmetro.

Ainda precisa de ajuda? Acesse a Microsoft Community.