Compartir vía

Planear el enrutamiento directo

  • Artículo
  • Se aplica a:
    Microsoft Teams

Enrutamiento directo le permite conectar un controlador de borde de sesión (SBC) compatible proporcionado por el cliente a Microsoft Teams Phone. Con esta funcionalidad, puede configurar la conectividad de red telefónica conmutada (RTC) local con Teams, como se muestra en el siguiente diagrama:

Diagrama que muestra la configuración de la conectividad con RTC local.

Planear la implementación de enrutamiento directo es clave para una implementación correcta. En este artículo se describen los requisitos de infraestructura y licencias, y se proporciona información sobre la conectividad SBC. Asegúrese de leer este artículo antes de iniciar la configuración, que se describe en Configurar enrutamiento directo.

Con enrutamiento directo, puede conectar su SBC a casi cualquier tronco de telefonía o interconexión con equipos RTC de terceros. Enrutamiento directo le permite:

  • Use prácticamente cualquier tronco RTC con Teams Phone.

  • Configure la interoperabilidad entre equipos de telefonía propiedad del cliente, como una central de telefonía privada (PBX) de terceros, dispositivos analógicos y Teams.

Microsoft también ofrece soluciones de voz todo en la nube, como Microsoft Calling Plan. Sin embargo, el enrutamiento directo podría ser mejor para su organización si:

  • El plan de llamadas de Microsoft no está disponible en tu país o región.

  • Su organización requiere conexión a dispositivos analógicos de terceros, centros de llamadas, etc.

  • Su organización tiene un contrato existente con un operador RTC.

Para obtener más información sobre las soluciones de voz, consulte Planear la solución de voz de Teams.

Con enrutamiento directo, cuando los usuarios participan en una reunión programada, el número de acceso telefónico es proporcionado por el servicio de Audioconferencia de Microsoft, que requiere una licencia adecuada. Al llamar, audioconferencia realiza la llamada mediante las funcionalidades de llamada en línea, que requieren una licencia adecuada. Si un usuario no tiene una licencia de Audioconferencia de Microsoft, la llamada se enruta a través del enrutamiento directo. Para obtener más información, vea Enrutamiento directo con audioconferencia.

Direct Routing también es compatible con los usuarios que tienen otra licencia para Microsoft Calling Plan. Para obtener más información, consulte Enrutamiento directo con plan de llamadas y conexión del operador.

Requisitos de infraestructura

Los requisitos de infraestructura para los SBCs, los dominios y otros requisitos de conectividad de red admitidos para implementar el enrutamiento directo se enumeran en la tabla siguiente:

Requisito de infraestructura Necesita lo siguiente
Controlador de borde de sesión (SBC) Un SBC compatible. Para obtener más información, consulte SBCs compatibles.
Troncos de telefonía conectados al SBC Uno o más troncos de telefonía conectados al SBC. En un extremo, el SBC se conecta a Teams Phone a través del enrutamiento directo. El SBC también puede conectarse a entidades de telefonía de terceros, como PBX, adaptadores de telefonía analógica, etc. Funcionará cualquier opción de conectividad RTC conectada a la SBC. (Para la configuración de los troncos RTC al SBC, refiera a los proveedores de SBC o proveedores troncales.)
Organización de Microsoft 365 Una organización de Microsoft 365 que usa para hospedar a los usuarios de Microsoft Teams, así como la configuración y la conexión con el SBC.
Registrador de usuarios El usuario debe estar alojado en Microsoft 365.
Si su empresa tiene un entorno local de Skype para empresas con conectividad híbrida a Microsoft 365, no puede habilitar la voz en Teams para un usuario alojado en local.

Para comprobar el registrador de un usuario, use el siguiente cmdlet de PowerShell de Teams:
Get-CsOnlineUser -Identity <user> | fl HostingProvider

El resultado del cmdlet debería mostrar:
HostingProvider : sipfed.online.lync.com
Dominios Uno o más dominios agregados a sus organizaciones de Microsoft 365 u Office 365.

No puede usar el dominio predeterminado, *.onmicrosoft.com, que se crea automáticamente para su inquilino.

Para ver los dominios, puede usar el siguiente cmdlet de PowerShell de Teams:
Get-CsTenant | fl Domains

Para obtener más información sobre los dominios y las organizaciones de Microsoft 365 u Office 365, vea Preguntas más frecuentes sobre dominios.
Dirección IP pública para la SBC Una dirección IP pública que se puede usar para conectarse al SBC. En función del tipo de SBC, el SBC puede usar NAT.
Nombre de dominio completo (FQDN) para el SBC Un FQDN para el SBC, donde la parte del dominio del FQDN es uno de los dominios registrados en su organización de Microsoft 365 u Office 365. Para obtener más información, consulte Nombres de dominio SBC.
Entrada DNS pública para la SBC Una entrada DNS pública que asigna el FQDN de SBC a la dirección IP pública.
Certificado de confianza público para el SBC Un certificado para que el SBC se use para todas las comunicaciones con enrutamiento directo. Para obtener más información, vea Certificado de confianza público para el SBC.
Puntos de conexión para enrutamiento directo Los puntos de conexión para enrutamiento directo son los tres FQDN siguientes:

sip.pstnhub.microsoft.com – FQDN global, debe intentarse primero.
sip2.pstnhub.microsoft.com – FQDN secundario, se asigna geográficamente a la región de segunda prioridad.
sip3.pstnhub.microsoft.com – FQDN terciario, se asigna geográficamente a la tercera región de prioridad.

Para obtener información sobre los requisitos de configuración, consulte Señalización SIP: FQDN.
Direcciones IP y puertos de firewall para medios de enrutamiento directo El SBC se comunica a los siguientes servicios en la nube:

- Proxy SIP, que controla la señalización
- Procesador multimedia, que controla los medios, excepto cuando la omisión de medios está activada

Estos dos servicios tienen direcciones IP independientes en Microsoft Cloud, que se describen más adelante en este documento.

Para obtener más información, consulte la sección de Microsoft Teams en Direcciones URL e intervalos de direcciones IP.
Perfil de transporte multimedia TCP/RTP/SAVP
UDP/RTP/SAVP

Concesión de licencias y otros requisitos

Direct Routing usuarios deben tener las siguientes licencias asignadas en Microsoft 365:

  • Teams Phone
  • Microsoft Teams

Para obtener información sobre cuándo se requiere una licencia de Audioconferencia, vea Enrutamiento directo con Audioconferencia.

Direct Routing también admite usuarios con licencia para Microsoft Calling Plan. Para obtener más información, consulte Enrutamiento directo con plan de llamadas y conexión del operador.

Para obtener más información sobre las licencias, consulte Licencias de Microsoft Teams y Licencias complementarias de Microsoft Teams.

Nota: El enrutamiento directo no se admite en el modo islas.

Enrutamiento directo con Audioconferencia

En esta sección se describen los requisitos y consideraciones al usar enrutamiento directo y audioconferencia.

  • Para los usuarios de GCC High y DoD G5, Microsoft recomienda deshabilitar el componente Audioconferencia incluido en G5 hasta que configure el enrutamiento directo y haya agregado números de Audioconferencia al inquilino de su organización.

  • Para los usuarios de GCC High y DoD G3, Microsoft recomienda no asignar el complemento de licencia de Audioconferencia hasta que configure Enrutamiento directo y haya agregado números de Audioconferencia al inquilino de su organización.

Para obtener más información, consulte Audioconferencia con enrutamiento directo para GCC High y DoD.

Escalación de llamadas no planeada y licencia de Audioconferencia

Un usuario de Teams puede iniciar una llamada de Teams a RTC o de Teams a Teams uno a uno y agregar a un participante de RTC. La ruta de acceso que tome la llamada depende de si el usuario que escala la llamada tiene asignada o no una licencia de Audioconferencia de Microsoft:

  • Si el usuario de Teams que escala la llamada tiene asignada una licencia de Audioconferencia de Microsoft, el aumento se produce a través del servicio De audioconferencia de Microsoft. El participante remoto de RTC al que se invita a la llamada existente recibe una notificación sobre la llamada entrante y ve el número del puente de Microsoft asignado al usuario de Teams que inició la escalación.

  • Si el usuario de Teams que escala la llamada no tiene asignada la licencia de Audioconferencia de Microsoft, el escalado se produce a través de un controlador de borde de sesión conectado a la interfaz enrutamiento directo. El participante remoto de RTC al que se invita a la llamada recibe una notificación sobre la llamada entrante y ve el número del usuario de Teams que inició la escalación. El SBC específico usado para la escalada se define mediante la directiva de enrutamiento del usuario.

Debe asegurarse de lo siguiente:

  • CsOnlineVoiceRoutingPolicy está asignado al usuario.

  • Permitir llamadas privadas está habilitado en el nivel de inquilino de Microsoft Teams.

Enrutamiento directo con planes de llamadas y conexión del operador

Direct Routing también admite usuarios con licencia para Plan de llamadas de Microsoft o que tienen asignado un número de teléfono Operator Connect. Los usuarios habilitados Teams Phone con plan de llamadas o Operador Connect pueden enrutar algunas llamadas mediante la interfaz Enrutamiento directo.

La combinación de plan de llamadas o conexión de operador y conectividad de enrutamiento directo para el mismo usuario es opcional, pero podría ser útil. Por ejemplo, cuando al usuario se le asigna un plan de llamadas de Microsoft o un número De conexión de operador, pero quiere enrutar algunas llamadas con el SBC.

Uno de los escenarios más comunes es las llamadas a PBX de terceros. Con esta configuración, las llamadas a los teléfonos conectados al PBX de terceros se enrutan mediante enrutamiento directo y, por lo tanto, permanecen dentro de la red empresarial, no atraviesan la RTC. Mientras tanto, todas las demás llamadas se enrutan a la RTC en función del método de conectividad RTC asignado por los usuarios: Plan de llamadas de Microsoft u Operador Connect.

Para obtener más información sobre las licencias de Teams Phone, consulte Licencias complementarias de Microsoft Teams.

Puntos finales admitidos

Puede usar lo siguiente como punto final:

Nombres de dominio SBC

El nombre de dominio SBC debe ser de uno de los nombres registrados en Dominios del inquilino.

En la tabla siguiente se muestran ejemplos de nombres DNS registrados para el inquilino, si el nombre se puede usar como FQDN para el SBC y ejemplos de nombres FQDN válidos. Tenga en cuenta que no puede usar el espacio empresarial *.onmicrosoft.com para el nombre FQDN del SBC.

Nombre DNS Puede usarse para FQDN de SBC Ejemplos de nombres FQDN
contoso.com Sí Nombres válidos:
sbc1.contoso.com
ssbcs15.contoso.com
europe.contoso.com
contoso.onmicrosoft.com No No se admite el uso de dominios *.onmicrosoft.com para nombres SBC

Suponga que desea usar un nuevo nombre de dominio. Por ejemplo, el inquilino tiene contoso.com como un nombre de dominio registrado en el inquilino y desea usar sbc1.sip.contoso.com.

Antes de poder emparejar un SBC con el nombre sbc1.sip.contoso.com, debe registrar el nombre de dominio sip.contoso.com en Dominios del espacio empresarial. Si intenta emparejar un SBC con sbc1.sip.contoso.com antes de registrar el nombre de dominio, recibirá el siguiente error: "No se puede usar el dominio "sbc1.sip.contoso.com" ya que no se configuró para este inquilino".

Después de agregar el nombre de dominio, debe crear un usuario con UPN user@sip.contoso.com y asignar una licencia de Teams. El aprovisionamiento completo del nombre de dominio puede tardar hasta 24 horas después de agregarlo a Dominios del inquilino, crear un usuario con un nombre nuevo y asignar una licencia al usuario.

Es posible que una empresa tenga varios espacios de direcciones SIP en un inquilino. Por ejemplo, una compañía podría tener contoso.com como un espacio de direcciones SIP y fabrikam.com como el segundo espacio de direcciones SIP. Algunos usuarios tienen dirección user@contoso.com y otros tienen dirección user@fabrikam.com.

El SBC solo necesita un FQDN y puede atender a los usuarios desde cualquier espacio de direcciones en el espacio empresarial emparejado. Por ejemplo, un SBC con el nombre sbc1.contoso.com puede recibir y enviar el tráfico RTC para los usuarios con direcciones user@contoso.com y siempre que user@fabrikam.com estos espacios de direcciones SIP estén registrados en el mismo espacio empresarial.

Nota

El FQDN de SBC en el enrutamiento directo de Azure Communication Services debe ser diferente del FQDN de SBC en el enrutamiento directo de Teams.

Certificado de confianza público para el SBC

Microsoft recomienda solicitar el certificado para el SBC generando una solicitud de firma de certificación (CSR). Para obtener instrucciones específicas sobre cómo generar un CSR para un SBC, consulte las instrucciones de interconexión o la documentación proporcionada por sus proveedores de SBC.

Nota

La mayoría de las entidades emisoras de certificados (CA) requieren que el tamaño de la clave privada sea al menos 2048. Tenga esto en cuenta al generar el CSR.

El certificado debe tener el FQDN de SBC como el nombre común (CN) o el campo de nombre alternativo del asunto (SAN).

Como alternativa, enrutamiento directo admite un carácter comodín en el CN y/o SAN, y el carácter comodín debe ajustarse a RFC HTTP Over TLS estándar.

Un ejemplo sería el uso de *.contoso.com, que coincidiría con el sbc.contoso.com FQDN de SBC, pero no coincidiría con sbc.test.contoso.com.

La interfaz SIP de enrutamiento directo solo confiará en los certificados firmados por entidades emisoras de certificados (CA) que forman parte del Programa de certificados raíz de confianza de Microsoft. Asegúrese de que una CA que forma parte del programa firme su certificado SBC. Asegúrese también de que la extensión de uso extendido de claves (EKU) del certificado incluye autenticación de servidor y autenticación de cliente.

Para obtener más información, consulte Requisitos del programa: programa raíz de confianza de Microsoft y lista de certificados de CA incluidos.

Nota

A finales de agosto de 2023, Microsoft 365 actualizará sus servicios para usar certificados TLS emitidos por la nueva CA "DigiCert Global Root G2". Para evitar errores que puedan afectar a su servicio, debe actualizar el almacén raíz de certificados de su SBC para que incluya la nueva CA raíz. Para obtener más información, vea Cambio de entidad de certificación DE CERTIFICADO SIP a MSPKI.

Para el enrutamiento directo en entornos de GCCH y DoD de Office 365, una de las siguientes entidades emisoras de certificados raíz debe generar el certificado:

  • DigiCert Global Root CA
  • DigiCert High Assurance EV Root CA

Nota

Si se habilita la compatibilidad de Mutual TLS (MTLS) para la conexión de Teams en el SBC, debe instalar la raíz cybertrust de Baltimore y los certificados de DigiCert Global Root G2 en el almacén raíz de confianza de SBC del contexto tls de Teams. (Esto se debe a que los certificados de servicio de Microsoft usan uno de estos dos certificados raíz). Para descargar estos certificados raíz, consulte Cadenas de cifrado de Microsoft 365. Para obtener más información, vea Cambios de certificados de Office TLS.

Para comprobar que la conexión MTLS proviene de la infraestructura de Teams, el SBC debe configurarse para implementar las siguientes comprobaciones en el certificado del lado servidor de Teams:

  • Compruebe que la cadena de emisión de certificados proviene de uno de los siguientes CA raíz:

  • Compruebe que el certificado "Nombre alternativo del asunto" incluye "sip.pstnhub.microsoft.com".

Señalización SIP: FQDN, puertos, mecanismo de conmutación por error

Direct Routing se ofrece en los siguientes entornos:

  • Microsoft 365 u Office 365
  • Office 365 GCC
  • Office 365 GCC High
  • Office 365 DoD

Para obtener más información sobre entornos gubernamentales, como GCC, GCC High y DoD, vea Entornos de Office 365 y de la administración pública de EE. UU.

En las secciones siguientes se describe información sobre FQDN, puertos y mecanismos de conmutación por error.

Señalización SIP: FQDN

En las siguientes secciones se describen los puntos de conexión fqdn para varios entornos de nube de Microsoft.

Entornos GCC de Microsoft 365, Office 365 y Office 365

En estos entornos, los puntos de conexión para enrutamiento directo son los tres FQDN siguientes:

  • sip.pstnhub.microsoft.com , FQDN global, debe probarse primero. Cuando el SBC envía una solicitud para resolver este nombre, los servidores DNS de Microsoft Azure devuelven una dirección IP que apunta al centro de datos de Azure principal asignado al SBC. La asignación se basa en métricas de rendimiento de los centros de datos y la proximidad geográfica al SBC. La dirección IP devuelta corresponde al FQDN principal.

  • sip2.pstnhub.microsoft.com ( FQDN secundario ) se asigna geográficamente a la región de segunda prioridad.

  • sip3.pstnhub.microsoft.com ( FQDN terciario ) se asigna geográficamente a la tercera región de prioridad.

La colocación de estos tres FQDN en orden es necesaria para:

  • Ofrezca una experiencia óptima (menos cargada y más cercana al centro de datos SBC asignado consultando el primer FQDN).

  • Proporcionar conmutación por error cuando se establece la conexión desde un SBC a un centro de datos que está experimentando un problema temporal. Para obtener más información, consulte Mecanismo de conmutación por error.

Los FQDN sip.pstnhub.microsoft.com, sip2.pstnhub.microsoft.com y sip3.pstnhub.microsoft.com se resuelven en las direcciones IP de las siguientes subredes:

  • 52.112.0.0/14
  • 52.122.0.0/15

Debe abrir puertos para todos estos intervalos de direcciones IP en el firewall para permitir el tráfico entrante y saliente hacia y desde las direcciones para la señalización.

Nota: El tráfico SIP entrante a los SBCs desde los puntos de conexión sip de Teams puede originarse desde cualquier IP en estas subredes, no solo de ips que resuelven de los FQDN mencionados previamente. Para obtener más información sobre cómo configurar el emparejamiento SIP, consulte la documentación de SBC.

Entorno de DD de GCC de Office

En el entorno del DoD GCC de Office, el punto de conexión para enrutamiento directo es el siguiente FQDN:

sip.pstnhub.dod.teams.microsoft.us : FQDN global. Como el entorno de DoD de Office 365 solo existe en los centros de datos de Ee. UU., no hay FQDN secundarios y terciarios.

El fqdn sip.pstnhub.dod.teams.microsoft.us se resuelve en una dirección IP desde la siguiente subred: 52.127.64.0/21

Para permitir el tráfico entrante y saliente hacia y desde las direcciones para la señalización, debe abrir puertos para todas estas direcciones IP en el firewall.

Entorno de Office 365 GCC High

En el entorno de Office 365 GCC High, el punto de conexión para enrutamiento directo es el siguiente FQDN:

sip.pstnhub.gov.teams.microsoft.us : FQDN global. Como el entorno GCC High existe solo en los centros de datos de EE. UU., no hay FQDN secundarios y terciarios.

El fqdn sip.pstnhub.gov.teams.microsoft.us se resuelve en una dirección IP desde la siguiente subred: 52.127.88.0/21

Para permitir el tráfico entrante y saliente hacia y desde las direcciones para la señalización, debe abrir puertos para todas estas direcciones IP en el firewall.

Señalización SIP: Puertos

Debe usar los puertos siguientes para entornos de Microsoft 365 u Office 365 en los que se ofrece enrutamiento directo:

Tráfico De Hasta Puerto de origen Puerto de destino
SIP/TLS SIP Proxy SBC 1024 – 65535 Definido en el SBC (para Office 365 GCC High/DoD solo debe usarse el puerto 5061)
SIP/TLS SBC SIP Proxy Definido en el SBC 5061

Señalización SIP: Mecanismo de conmutación por error

Para resolver sip.pstnhub.microsoft.com, el SBC realiza una consulta DNS. Según la ubicación de SBC y las métricas de rendimiento del centro de datos, se selecciona el centro de datos principal.

Si el centro de datos principal experimenta un problema, el SBC intenta sip2.pstnhub.microsoft.com, que se resuelve en el segundo centro de datos asignado. En el caso poco frecuente de que los centros de datos de dos regiones no estén disponibles, el SBC vuelve a escribir el último FQDN (sip3.pstnhub.microsoft.com), que proporciona la IP del centro de datos terciario.

En la tabla siguiente se resumen las relaciones entre los centros de datos primario, secundario y terciario:

Si el centro de datos principal es EMEA NOAM ASIA
El centro de datos secundario (sip2.pstnhub.microsoft.com) NOS UE NOS
El centro de datos terciario (sip3.pstnhub.microsoft.com) ASIA ASIA UE

Tráfico multimedia: intervalos de puertos, procesadores multimedia, CÓDECS

Tráfico multimedia: intervalos de puertos

Si desea implementar enrutamiento directo sin omisión de medios, se aplicarán los siguientes requisitos. Para conocer los requisitos de firewall para la omisión de medios, consulte Planear la omisión de medios con enrutamiento directo.

El tráfico multimedia fluye hacia y desde un servicio independiente en Microsoft Cloud. Los intervalos de direcciones IP para el tráfico multimedia son los siguientes.

Nota

Los intervalos IP presentados en este documento son específicos del enrutamiento directo y pueden diferir de los recomendados para el cliente de Teams.

Entornos GCC de Microsoft 365, Office 365 y Office 365

En los entornos de Microsoft 365, Office 365 y Office 365 GCC, los intervalos de direcciones IP son:

  • 52.112.0.0/14 (direcciones IP de 52.112.0.0 a 52.115.255.255)
  • 52.120.0.0/14 (direcciones IP de 52.120.0.0 a 52.123.255.255)

Entorno de DoD de Office 365

En el entorno de DoD de Office 365, los intervalos de direcciones IP son:

  • 52.127.64.0/21

Entorno de Office 365 GCC High

En el entorno de Office 365 GCC High, los intervalos de direcciones IP son:

  • 52.127.88.0/21

Todos los entornos

Los intervalos de puertos de los procesadores multimedia se muestran en la tabla siguiente:

Tráfico De Hasta Puerto de origen Puerto de destino
UDP/SRTP Procesador multimedia SBC 3478-3481 y 49152 – 53247 Definido en el SBC
UDP/SRTP SBC Procesador multimedia Definido en el SBC 3478-3481 y 49152 – 53247

Nota

Microsoft recomienda al menos dos puertos por llamada simultánea en el SBC.

Tráfico multimedia: procesadores geography

El tráfico multimedia fluye a través de componentes denominados procesadores multimedia. Los procesadores multimedia se colocan en los mismos centros de datos que los servidores proxy SIP de la siguiente manera:

  • NOAM (US South Central, dos en los centros de datos oeste y este de EE. UU.)
  • Europa (centro de datos del Sur del Reino Unido, Francia Central, Amsterdam y Dublín)
  • Asia (centro de datos de Singapur)
  • Japón (centros de datos de JP East y West)
  • Australia (centros de datos au east y southeast)
  • LATINOAMÉRICA (Brasil Sur)

Tráfico multimedia: códecs

En las siguientes secciones se describen los códecs para el tráfico multimedia.

Leg between SBC and Cloud Media Processor or Microsoft Teams client

Se aplica tanto a casos de omisión multimedia como a casos que no son de omisión.

La interfaz De enrutamiento directo de la pierna entre el controlador de borde de sesión y el procesador de medios en la nube (sin omisión multimedia) o entre el cliente de Teams y el SBC (si la omisión multimedia está habilitada) puede usar los siguientes códecs:

  • Omisión no multimedia (procesador de medios de SBC a nube): SILK, G.711, G.722, G.729
  • Omisión de medios (SBC al cliente de Teams): SILK, G.711, G.722, G.729

Puede forzar el uso del códec específico en el controlador de borde de sesión excluyendo los códecs no deseados de la oferta.

Pierna entre el cliente de Microsoft Teams y el procesador multimedia en la nube

Solo se aplica al caso de omisión no multimedia. Con la omisión de medios, los elementos multimedia fluyen directamente entre el cliente de Teams y el SBC.

En el tramo entre el procesador de medios en la nube y el cliente de Teams, se usa SILK o G.722. La elección del códec en esta pierna se basa en algoritmos de Microsoft, que tienen en cuenta varios parámetros.

Nota

No se admite la re-identificación de medios. Durante una llamada, si la nueva invitación de SIP para SBC de enrutamiento directo (oferta) contiene una nueva dirección IP multimedia, puerto o transporte, los medios no se envían desde el concentrador RTC al nuevo destino. Por RFC 3264 8.3.1, la compatibilidad con el nuevo destino de medios es opcional (no es necesario).

Controladores de borde de sesión compatibles (SBCs)

Microsoft solo admite SBCs certificados para emparejarse con Direct Routing. Dado que Enterprise Voice es fundamental para las empresas, Microsoft ejecuta pruebas intensivas con los SBC seleccionados y trabaja con los proveedores de SBC para garantizar que los dos sistemas sean compatibles.

Los dispositivos validados aparecen como Certificados para el enrutamiento directo de Teams. Los dispositivos certificados están garantizados para funcionar en todos los escenarios.

Para obtener más información sobre los SBCs compatibles, consulte Controladores de borde de sesión certificados para enrutamiento directo.

Límites de soporte técnico

Microsoft solo admite Teams Phone con enrutamiento directo cuando se usa con dispositivos certificados. Si hay problemas, primero debe ponerse en contacto con el servicio de atención al cliente de su proveedor de SBC. Si es necesario, el proveedor de SBC escala el problema a Microsoft a través de canales internos. Microsoft se reserva el derecho de rechazar los casos de soporte técnico en los que un dispositivo no certificado esté conectado a Teams Phone a través del enrutamiento directo. Si Microsoft determina que el problema de enrutamiento directo de un cliente está relacionado con el dispositivo SBC de un proveedor, el cliente debe volver a contratar al proveedor de SBC para obtener soporte técnico.

Vea también