- Inicio
- /
- Artículo
Este artículo está dirigido a los administradores de red, especialmente a los administradores de seguridad de firewall y proxy que desean usar Webex Calling dentro de su organización.
Para conocer la información de referencia del puerto para los requisitos de acceso y firewall, consulte Información de referencia de puertos para Cisco Webex Calling.
Requisitos para los puntos finales
Webex CallingBorde
Para realizar un registro o una llamada SIP, complete estos pasos:
-
Descubra la dirección de host de un punto final SIP para nodos Edge activos.
-
Complete cualquier condición previa relacionada con la configuración del usuario y del dispositivo.
-
Asegúrese de que el punto final tenga conectividad de red pública para iniciar el descubrimiento de servicios.
-
Complete las condiciones previas para arrancar el punto final con una configuración de aprovisionamiento específica de región o centro de datos. Esta configuración ayuda a obtener el sufijo de nombre de dominio relevante para la detección de servicios.
IPv4 frente a IPv6
Los dispositivos pueden funcionar en modo de una sola versión o de doble pila. Es la configuración la que determina los cambios en el protocolo preferido y estos cambios no son parte del descubrimiento de servicios.
-
Modo de pila única: permite solo un protocolo IP (por ejemplo, IPv4) e ignora las otras direcciones de protocolo.
-
Modo de doble pila: selecciona una versión IP preferida a través de la configuración.
El cliente considera que la prioridad para todas las direcciones preferidas es menor (es decir, preferida) que todas las direcciones IP. Si se prefiere IPv4, todas las direcciones IPv4 se intentan antes de intentar una dirección IPv6. Si todas las direcciones fallan, el ciclo comienza de nuevo con la dirección de protocolo preferida de prioridad más baja.
Un cliente móvil que se registre al recibir una notificación push puede decidir optimizar el modo basado en registros anteriores.
Resolución de la dirección del host desde la DNS SRV dirección
En el archivo de configuración de punto final obtenido del aprovisionamiento, el indicador de dominio especifica el nombre de dominio para descubrir el servicio de borde de acceso. Un ejemplo del nombre de dominio es:
wxc.edge.bcld.webex.com
A partir del ejemplo, el punto final que realiza una DNS SRV búsqueda para este dominio puede producir una respuesta similar a la siguiente:
# nslookup -type=srv _sips._tcp. wxc.edge.bcld.webex.com
_sips._tcp.wxc.edge.bcld.webex.com SRV 5 100 5061 sip-edge1.us-dc1.bcld.webex.com.
_sips._tcp.wxc.edge.bcld.webex.com SRV 10 105 5061 sip-edge2.us-dc1. bcld.webex.com.
En este caso, el registro SRV apunta a 3 registros A.
sip-edge1.us-dc1.bcld.webex.com
sip-edge2.us-dc1.bcld.webex.com
En el ejemplo, se anuncia que todos los hosts se pongan en contacto con el puerto 5061 con diferente peso y prioridad.
Considere estos requisitos para los puntos finales.
-
Un punto final debe usar
_sips._tcp(combinación de servicio y protocolo) como prefijo para realizar una DNS SRV búsqueda para obtener la dirección de host para iniciar la comunicación basada en TLS. -
Un punto final debe realizar una DNS SRV búsqueda de las condiciones explicadas en la Resolución de la dirección del host de la sección DNS SRV Dirección.
-
Un punto final debe respetar el host, el puerto, el peso y la prioridad como se anuncia para cada una de las direcciones del host. Además, debe crear una afinidad de host a puerto al crear una conexión de socket durante el registro SIP.
-
Específico para el uso del DNS SRV registro, los criterios de selección de hosts basados en la prioridad y el peso se explican en RFC 2782.
Requisitos para SIP y medios
|
Requisito |
Descripción |
|---|---|
|
Certificado de confianza requerido para el cifrado de clave pública |
Consulte el artículo para saber sobre la autoridad de firma de certificados de Webex y la CA raíz requerida en los dispositivos |
|
Versión TLS soportada para SIP seguro |
TLS 1.2 y TLS 1.3 |
|
Cifrados TLS soportados para SIP seguro |
TLS_AES_256_GCM_SHA384 TLS_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 |
|
Claves SRTP compatibles para medios seguros |
AES_CM_128_HMAC_SHA1_80 |
Requisitos para SIP seguro con MTLs (TLS mutuo)
Los requisitos se explican en detalle aquí.
Se requiere un certificado firmado para una autorización y autenticación exitosas de las llamadas desde el tronco. El certificado debe cumplir con los siguientes requisitos:
-
El certificado debe estar firmado por una CA mencionada en ¿Qué autoridades de certificados raíz son compatibles para llamadas a plataformas Cisco Webex de audio y video?
-
Cargue el paquete de confianza mencionado en ¿Qué autoridades de certificación raíz son compatibles con las llamadas a plataformas Cisco Webex de audio y video? a la CUBE.
-
El certificado debe ser válido siempre:
-
Los certificados firmados siempre deben tener un vencimiento válido.
-
Los certificados raíz o intermedios deben tener una caducidad válida y no deben ser revocados.
-
Se admiten certificados que contengan únicamente el uso extendido de claves (EKU) de autenticación del servidor. Webex Callingno valida ni hace cumplir la presencia de la EKU de autenticación del cliente durante el establecimiento del protocolo de enlace TLS.
Algunos controladores fronterizos de sesión (SBC) de terceros pueden imponer una validación estricta de EKU y podrían rechazar certificados que no incluyen EKU de autenticación de cliente. En tales casos, asegúrese de que el SBC esté configurado para aceptar certificados con solo EKU de autenticación de servidor o para deshabilitar la validación estricta de EKU (si es compatible).
-
Los certificados deben contener el nombre de dominio completo (FQDN) como nombre común o nombre alternativo del asunto en el certificado con el FQDN seleccionado en el centro de control. Por ejemplo:
-
Un tronco configurado desde el centro de control de su organización con london.lgw.cisco.com:5061 como FQDN debe contener london.lgw.cisco.com en el certificado CN o SAN.
-
Un tronco configurado desde el centro de control de su organización con london.lgw.cisco.com era el SRV que debe contener london.lgw.cisco.com en el certificado CN o SAN. Los registros en los que se resuelve la dirección SRV (registro CNAME/A/dirección IP) son opcionales en SAN.
-
-
Puede compartir certificados con más de una puerta de enlace local, sin embargo, asegúrese de que se cumplan los requisitos de FQDN.
-
Fuera de alcance
Este artículo no incluye la siguiente información relacionada con la seguridad de la red:
-
Requisitos de F5 para CA y Ciphers
-
Una API basada en HTTP para descargar reglas de firewall para Webex.
-
API para un paquete de confianza
-
Requisito de firewall y desactivación de ALG