Requisitos de infraestructura de enrutamiento directo de Azure
En este artículo se proporcionan detalles sobre la infraestructura, las licencias y la conectividad del controlador de borde de sesión (SBC) que es conveniente tener en cuenta al planear la implementación del enrutamiento directo de Azure.
Requisitos de infraestructura
En la tabla siguiente se enumeran los requisitos de infraestructura de los SBC admitidos, los dominios y otros requisitos de conectividad de red para implementar el enrutamiento directo de Azure:
| Requisito de infraestructura | Necesita lo siguiente |
|---|---|
| Controlador de borde de sesión (SBC) | Un SBC compatible. Para más información, consulte SBC compatibles. |
| Troncos de telefonía conectados al SBC | Uno o varios troncos de telefonía conectados al SBC. En un extremo, el SBC se conecta a Azure Communication Services mediante enrutamiento directo. El SBC también puede conectarse a entidades de telefonía de terceros, como PBX o adaptadores de telefonía analógicos. Funciona cualquier opción de conectividad de red de telefonía conmutada pública (RTC) conectada a SBC. (Para conocer la configuración de los troncos de RTC en el SBC, consulte a los proveedores de SBC o los proveedores de troncos). |
| Suscripción de Azure | Una suscripción de Azure que se usa para crear un recurso de Communication Services, así como la configuración y la conexión al SBC. |
| Token de acceso de Communication Services | Para realizar llamadas, se necesita un token de acceso válido con el ámbito voip. Consulte Tokens de acceso |
| Dirección IP pública del SBC | Una dirección IP pública que se puede usar para conectarse al SBC. En función de su tipo, el SBC puede usar NAT. |
| Nombre de dominio completo (FQDN) del SBC | Para obtener más información, consulte Certificados SBC y nombres de dominio. |
| Entrada DNS pública para el SBC | Una entrada DNS pública que asigna el nombre de dominio completo del SBC a la dirección IP pública. |
| Certificado de confianza público para el SBC | Un certificado para el SBC que se va a usar en todas las comunicaciones con enrutamiento directo de Azure. Para obtener más información, consulte Certificados SBC y nombres de dominio. |
| Direcciones IP y puertos del firewall para los elementos multimedia y la señalización de SIP | El SBC se comunica con los siguientes servicios en la nube: Proxy SIP, que controla la señalización Procesador de multimedia, que controla los elementos multimedia Estos dos servicios tienen direcciones IP independientes en Microsoft Cloud, que se describen más adelante en este documento. |
Certificados SBC y nombres de dominio
Microsoft recomienda que para solicitar el certificado para el SBC se genere una solicitud de firma de certificación (CSR). Para obtener instrucciones concretas sobre la generación de una CSR para un SBC, consulte las instrucciones de interconexión o la documentación proporcionada por los proveedores del SBC.
Nota:
La mayoría de las entidades de certificación (CA) requieren que el tamaño de la clave privada sea al menos 2048. Tenga esto en cuenta al generar la solicitud de firma de certificación.
El certificado debe tener el nombre de dominio completo del SBC como nombre común (CN) o en el campo de nombre alternativo del firmante (SAN). El certificado debe emitirse directamente desde una entidad de certificación, no desde un proveedor intermedio.
Como alternativa, el enrutamiento directo de Communication Services admite un carácter comodín en el CN o el SAN, y el carácter comodín debe ajustarse al estándar HTTP de RFC sobre TLS.
Los clientes que ya usan Office 365 y tienen un dominio registrado en el Centro de administración de Microsoft 365, pueden usar el nombre de dominio completo de SBC del mismo dominio.
Un ejemplo sería usar *.contoso.com, que coincidiría con el nombre de dominio completo del SBC sbc.contoso.com, pero no con sbc.test.contoso.com.
Nota:
El nombre de dominio completo de SBC en el enrutamiento directo de Azure Communication Services debe ser diferente del nombre de dominio completo del enrutamiento directo de Teams.
Communication Services solo confía en certificados firmados por entidades de certificación que forman parte del programa de certificados raíz de confianza de Microsoft. Asegúrese de que el certificado SBC esté firmado por una entidad de certificación que forme parte del programa y de que la extensión de uso mejorado de clave (EKU) de su certificado incluya la autenticación de servidor. Más información:
Requisitos del programa: Programa de certificados raíz de confianza de Microsoft
Lista de certificados de entidad de certificación incluidos
Importante
El enrutamiento directo de Azure Communication Services solo admite TLS 1.2. Para evitar cualquier impacto en el servicio, asegúrese de que los SBC estén configurados para admitir TLS 1.2 y puedan conectarse mediante uno de los siguientes conjuntos de cifrado para la señalización de SIP:
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, es decir, ECDHE-RSA-AES256-GCM-SHA384 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, es decir, ECDHE-RSA-AES128-GCM-SHA256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, es decir, ECDHE-RSA-AES256-SHA384 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, es decir, ECDHE-RSA-AES128-SHA256
En el caso de los elementos multimedia SRTP, solo se admite AES_CM_128_HMAC_SHA1_80.
El emparejamiento de SBC funciona en el nivel de recursos de Communication Services. Esto significa que puede emparejar varios SBC con un único recurso de Communication Services. Aun así, no se puede emparejar un único SBC con más de un recurso de Communication Services. Los nombres de dominio completo únicos del SBC son necesarios para realizar el emparejamiento en recursos diferentes.
Si la compatibilidad mutua con TLS (MTLS) está habilitada para la conexión de enrutamiento directo en el SBC, debe instalar el certificado Baltimore CyberTrust Root y los certificados DigiCert Global Root G2 en el almacén raíz de confianza de SBC del contexto de TLS de enrutamiento directo (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 Office 365. Para obtener más información, consulte Cambios en los certificados TLS de Office.
Señalización de SIP: FQDN
Los puntos de conexión para el enrutamiento directo de Communication Services son los tres nombres de dominio completo siguientes:
- sip.pstnhub.microsoft.com: nombre de dominio completo global (es el primero que se debe probar). 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 recursos de Azure principal asignado al SBC. La asignación se basa en las métricas de rendimiento de los centros de trabajo y en la proximidad geográfica al SBC. La dirección IP devuelta corresponde al nombre de dominio completo principal.
- sip2.pstnhub.microsoft.com: FQDN secundario (se asigna geográficamente a la segunda región de prioridad).
- sip3.pstnhub.microsoft.com: FQDN terciario (se asigna geográficamente a la tercera región de prioridad).
Estos tres nombres de dominio completos en orden son necesarios para:
- Proporcionar una experiencia óptima (menos cargada y más cercana al centro de datos del SBC asignado mediante la consulta del primer nombre de dominio completo).
- Proporcionar conmutación por error cuando se establece la conexión desde un SBC a un centro de datos en el que surge un problema temporal. Para más información, consulte el apartado Mecanismo de conmutación por error.
Los nombres de dominio completos (sip.pstnhub.microsoft.com, sip2.pstnhub.microsoft.com y sip3.pstnhub.microsoft.com) se resolverán en una de las siguientes direcciones IP:
52.112.0.0/14 (IP addresses from 52.112.0.0 to 52.115.255.255)52.120.0.0/14 (IP addresses from 52.120.0.0 to 52.123.255.255)
Abra los puertos del firewall para estos intervalos de direcciones IP, con el fin de permitir tanto que entre tráfico a estas direcciones, como que salga de ellas para la señalización.
Señalización de SIP: Puertos
Use los siguientes puertos para el enrutamiento directo de Azure Communication Services:
| Tráfico | De | En | Puerto de origen | Puerto de destino |
|---|---|---|---|---|
| SIP/TLS | Proxy SIP | SBC | 1024–65535 | Definido en el SBC |
| SIP/TLS | SBC | Proxy SIP | Definido en el SBC | 5061 |
Mecanismo de conmutación por error para la señalización de SIP
El SBC realiza una consulta de DNS para resolver sip.pstnhub.microsoft.com. Para seleccionar el centro de datos principal se tienen en cuenta la ubicación del SBC y de las métricas de rendimiento del centro de recursos. Si surge algún problema en el centro de datos principal, el SBC prueba sip2.pstnhub.microsoft.com, que se resuelve en el segundo centro de datos asignado y, en el caso excepcional de que no estén disponibles los centros de datos de ambas, el SBC reintenta el último nombre de dominio completo (sip3.pstnhub.microsoft.com), que proporciona la IP del centro de datos terciario.
Tráfico de elementos multimedia: Intervalos de puertos y de IP
El tráfico de elementos multimedia no solo fluye hacia un servicio independiente denominado procesador de multimedia, sino también desde este. Los intervalos de direcciones IP para el tráfico multimedia son los mismos que para la señalización:
52.112.0.0/14 (IP addresses from 52.112.0.0 to 52.115.255.255)52.120.0.0/14 (IP addresses from 52.120.0.0 to 52.123.255.255)
Intervalos de puertos
En la tabla siguiente se muestran los intervalos de puertos de los procesadores de multimedia:
| Tráfico | De | En | Puerto de origen | Puerto de destino |
|---|---|---|---|---|
| UDP/SRTP | Procesador de multimedia | SBC | 49152–53247 | Definido en el SBC |
| UDP/SRTP | SBC | Procesador de multimedia | Definido en el SBC | 49152–53247 |
Nota:
Microsoft recomienda al menos dos puertos por llamada simultánea en el SBC.
Tráfico multimedia: Geografía de procesadores de multimedia
Los procesadores de multimedia se colocan en los mismos centros de datos que los servidores proxy SIP:
- NOAM (Centro y Sur de EE. UU., dos en los centros de datos de Oeste de EE. UU. y Este de EE. UU.)
- Europa (Oeste de Europa, Norte de Europa, Suecia, Centro de Francia)
- Asia (centro de datos de Singapur)
- Japón (centros de recursos de Este y Oeste de Japón)
- Australia (centros de datos de Este y Sudeste de Australia)
- LATAM (Sur de Brasil)
- África (Norte de Sudáfrica)
Tráfico de elementos multimedia: Códecs
Segmento entre la aplicación de SDK de ACS y el procesador de multimedia en la nube.
La interfaz de enrutamiento directo de Azure en el segmento entre el controlador de borde de sesión y el procesador multimedia en la nube puede usar los siguientes códecs:
- SILK, G.711, G.722, G.729
Puede forzar que se use el códec específico en el controlador de límites de sesión excluyendo los códecs no deseados de la oferta.
Segmento entre la aplicación del SDK de llamada de Communication Services y el procesador de multimedia en la nube
En el segmento entre el procesador de multimedia en la nube y la aplicación del SDK de llamada de Communication Services, se usa G.722. Se está trabajando para agregar más códecs en esta sección.
Controlador de límites de sesión admitidos (SBC)
Pasos siguientes
Documentación conceptual
- Concepto de telefonía
- Tipos de número de teléfono en Azure Communication Services
- Emparejamiento del controlador de límite de sesión y configuración del enrutamiento de voz
- Introducción a Call Automation
- Precios