Problemas con optimización de medios locales para enrutamiento directo

Es posible que encuentre que optimización de medios locales (LMO) para enrutamiento directo no funciona como se esperaba. Por ejemplo, Microsoft Teams no envía los encabezados y, o el encabezado contiene la ubicación incorrecta, o  X-Ms-UserLocation    X-Ms-MediaPath   las  X-Ms-UserLocation   llamadas fallan.

En este artículo se proporcionan algunas resoluciones que puede intentar solucionar estos problemas.

Los encabezados X-Ms-UserLocation y X-Ms-MediaPath no se envían

Los X-Ms-UserLocation X-Ms-MediaPath encabezados y son necesarios para LMO. Una de las razones más comunes por las que estos encabezados no se envían es que la puerta de enlace no está configurada correctamente para LMO.

Para comprobar la configuración de la puerta de enlace, ejecute el siguiente cmdlet Get-CsOnlinePSTNGateway:

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

Para que LMO esté habilitado, asegúrese de que todas las propiedades seleccionadas en este cmdlet están establecidas. Esto es especialmente importante para BypassMode . Este es un ejemplo de los resultados de este 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: Los valores que se muestran aquí pueden ser diferentes de lo que se ve.

Ubicación incorrecta enviada en el encabezado X-Ms-UserLocation

Si la información de ubicación de red en el encabezado se especifica como externa , pero espera ver un valor de interno , esto significa que la dirección IP pública del cliente de Teams no coincide con ninguna entrada de la lista de direcciones IP de X-Ms-UserLocation confianza. ****

Para solucionar este problema, identifique la dirección IP pública del cliente que usa Teams y, a continuación, agrégrela a la lista.

  1. Abra Microsoft Teams archivos de registro.

  2. Busque la dirección IP pública que aparece para el cliente en el registro de diagnóstico de MSTeams [Date]__[Time]_calling.txt   archivo. Este es un ejemplo de este archivo:

    Captura de pantalla de la dirección IP pública en el archivo txt.

  3. Ejecute el cmdlet Get-CsTenantTrustedIPAddress para obtener la lista de direcciones IP de confianza:

    Get-CsTenantTrustedIPAddress
    

    El resultado que vea debe ser similar al siguiente:

    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 falta la dirección IP del cliente identificada en el paso 2 de esta lista.

  4. Ejecute el cmdlet New-CsTenantTrustedIPAddress para agregar la dirección IP que falta a la lista:

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

    El resultado del cmdlet debe ser similar al siguiente ejemplo:

    Captura de pantalla de agregar la dirección IP que falta.

    Puede ver que la dirección IP del cliente ahora se ha agregado a la lista de direcciones IP de confianza.

  5. Reinicie el Teams para que la dirección IP recién agregada pueda reconocerse inmediatamente. De lo contrario, la lista puede tardar hasta 30 minutos en actualizarse.

    Después del reinicio, Teams buscará una coincidencia para la dirección IP del cliente en la lista de direcciones IP de confianza, como se muestra en el ejemplo siguiente:

    Captura de pantalla de la dirección IP coincidente.

Las llamadas entrantes fallan o van al correo de voz si LMO y LBR están habilitados

Uno de los motivos más probables por los que se produce este problema es que los encabezados o la información de enrutamiento no están configurados correctamente en el controlador de borde de sesión (SBC) desde el que se recibe la llamada.

Compruebe que los encabezados de mensaje del Protocolo de inicio de sesión (SIP) enviados desde el SBC contienen la siguiente información y actualíctenlos si son incorrectos:

  • El URI de SIP contiene el nombre de dominio completo (FQDN) del SBC regional.
  • El encabezado Contact contiene el FQDN del SBC regional.
  • El Record-Route contiene el FQDN del SBC proxy.

Si no se define un SBC proxy para el SBC regional, solo se comprueba Record-Route servidor. Si falta Record-Route, se comprueba el encabezado Contact.

Si los encabezados están configurados correctamente, el problema puede deberse a un enrutamiento mal configurado en el SBC.

Asegúrese de que el SBC tiene Location-Based enrutamiento (LBR) habilitado. El GatewaySiteLbrEnabled parámetro debe establecerse en True.

Además, el SBC debe asignarse al mismo sitio que el cliente que inicia la llamada.

Nota: El SBC proxy no tiene que estar habilitado para LBR.

Para determinar si la asignación de SBC es correcta, identifique el sitio de usuario registrado en los registros de cliente de Teams y compárelo con la información de asignación del SBC:

  1. Abra Microsoft Teams archivos de registro.

  2. Identifique la información del sitio de usuario que aparece en el archivo MSTeams Diagnostics Log [Date]__[Time]_calling.txt.   Este es un ejemplo de este archivo:

    Captura de pantalla del archivo txt con la información del sitio.

  3. Ejecute el cmdlet Get-CsOnlinePSTNGateway para comprobar la configuración del SBC. El resultado que vea debe ser similar al siguiente ejemplo:

    Captura de pantalla de comprobación de la configuración de SBC.

  4. En el resultado del paso 2, el valor del parámetro que aparece en la información del sitio networksiteId de usuario es "Vietnam". Sin embargo, en el resultado del paso 3, el valor del parámetro equivalente que aparece en la configuración del GatewaySiteId SBC es "India". Esto es un error de coincidencia. Para actualizar la configuración del SBC, ejecute el cmdlet Set-CsOnlinePSTNGateway, de la siguiente manera:

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

    A continuación, ejecute Get-CsOnlinePSTNGateway el cmdlet para comprobar la configuración actualizada del SBC. Ahora, el resultado debe mostrar el valor correcto para el GatewaySiteId parámetro.

    Captura de pantalla de actualización de GatewaySiteId.

¿Aún necesita ayuda? Vaya a Microsoft Community.