Planear el enrutamiento directo

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:

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:

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:

• Cualquier cliente de Teams.

• Teléfonos de área común. No necesita una licencia de Plan de llamadas al configurar un teléfono de área común con enrutamiento directo. Para obtener más información, consulte Configurar teléfonos de área comunes para Microsoft Teams.

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.

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.

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.

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.

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

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:

  • Baltimore CyberTrust Root
  • DigiCert Global Root G2

• 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:

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:

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.

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 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.

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

• Configurar el enrutamiento directo
• Sesión de vídeo: Enrutamiento directo en Microsoft Teams.