El conjunto de documentos para este producto aspira al uso de un lenguaje no discriminatorio. A los fines de esta documentación, "no discriminatorio" se refiere al lenguaje que no implica discriminación por motivos de edad, discapacidad, género, identidad de raza, identidad étnica, orientación sexual, nivel socioeconómico e interseccionalidad. Puede haber excepciones en la documentación debido al lenguaje que se encuentra ya en las interfaces de usuario del software del producto, el lenguaje utilizado en función de la documentación de la RFP o el lenguaje utilizado por un producto de terceros al que se hace referencia. Obtenga más información sobre cómo Cisco utiliza el lenguaje inclusivo.
Cisco ha traducido este documento combinando la traducción automática y los recursos humanos a fin de ofrecer a nuestros usuarios en todo el mundo contenido en su propio idioma. Tenga en cuenta que incluso la mejor traducción automática podría no ser tan precisa como la proporcionada por un traductor profesional. Cisco Systems, Inc. no asume ninguna responsabilidad por la precisión de estas traducciones y recomienda remitirse siempre al documento original escrito en inglés (insertar vínculo URL).
En este documento se describen los pasos para configurar y solucionar problemas en WebRTC de Cisco Meeting Server (CMS) mediante Expressway.
Cisco recomienda que tenga conocimiento sobre estos temas:
Requisitos previos de configuración:
Precaución: cuando el puerto TCP 443 está habilitado, Expressway ya no puede responder en el puerto TCP 3478.
Nota: el par de Expressway que se utiliza para los servicios Jabber Guest no se puede utilizar para los servicios de proxy CMS WebRTC.
Nota: Si va a actualizar a la versión 3.0 o posterior desde versiones anteriores, consulte la Guía para una actualización sin problemas de Cisco Meeting Server 2.9 a 3.0 (y versiones posteriores)
Este documento no se limita a versiones específicas de software y hardware; sin embargo, deben cumplirse los requisitos mínimos de versión de software.
La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.
La compatibilidad con proxy de WebRTC se ha agregado a Expressway desde la versión X8.9.2, que permite a los usuarios externos navegar a un puente web de Cisco Meeting Server.
Clientes externos y los invitados pueden administrar o unirse a espacios sin la necesidad de cualquier software que no sea un explorador compatible. Haga clic aquí para obtener una lista de los exploradores compatibles.
A partir del 5 de febrero de 2021, estos son los navegadores compatibles con CMS 3.1.1:
Esta imagen proporciona un ejemplo del flujo de conexiones de Web Proxy para CMS WebRTC: (de la guía de configuración de Uso de puertos IP exp).
Nota: al ejecutar X12.5.2 o una versión anterior, debe configurar su firewall externo para permitir la reflexión NAT para la dirección IP pública y Expressway-E (los firewalls suelen desconfiar de los paquetes que tienen la misma dirección IP de origen y de destino). A partir de X12.5.3, esto ya no es necesario para un Expressway independiente.
a. Vaya a Configuración > Unified Communication > Cisco Meeting Server.
b. Habilite el proxy web de Meeting Server.
c. Introduzca la URL de unión en el campo URI de cliente de cuenta de invitado.
d. Haga clic en Guardar.
e. Agregue la URL de unión a CMS en el certificado de servidor de Expressway-E como un nombre alternativo del sujeto (SAN). Consulte la Guía de implementación de creación y uso de certificados de Cisco VCS.
a. Navegue hasta Configuración > Transversal > ACTIVAR.
b. Habilite TURN services, de off a on.
c. Elija Configure TURN client credentials on local database y agregue las credenciales (nombre de usuario y contraseña).
Nota: Si tiene un clúster de Expressway-Es y todos se van a utilizar como servidores TURN, asegúrese de habilitarlo en todos los nodos. Debe configurar dos instancias turnServer independientes a través de la API y señalarlas a cada uno de los servidores de Expressway-E en el clúster (según el proceso de configuración que se muestra en el paso 4, que muestra el proceso para un servidor de Expressway-E; la configuración del segundo turnServer sería similar, solo usando las direcciones IP respectivas y las credenciales de activación para el otro servidor de Expressway-E).
Nota: Puede utilizar un equilibrador de carga de red delante de las autopistas para el tráfico TCP/HTTPS, pero los medios de activación deben pasar del cliente al servidor de activación de IP pública. Los medios de activación no deben pasar a través del equilibrador de carga de red
Este paso es necesario ya que las conexiones webrtc entran en TCP 443, pero Exp 12.7 introdujo una nueva Interfaz de administración dedicada (DMI) que se puede utilizar para 443.
a. Vaya a Sistema > Administración.
b. En Configuración del servidor Web, cambie el puerto del administrador Web a 445 en las opciones desplegables y, a continuación, haga clic en Guardar.
c. Repita los pasos 3a a 3b en todos los Expressway-E utilizados para los servicios de proxy WebRTC.
Nota: Cisco recomienda cambiar el puerto de administración porque los clientes WebRTC utilizan 443. Si el navegador WebRTC intenta 80 de puerto de acceso, el Expressway-E redirige la conexión a 443.
En CMS 2.9.x en adelante, utilice el menú Configuration —> API para agregar servidores de turno:
d. Repita el paso 4c para cada servidor de Expressway-E que se vaya a usar para TURN
Esta imagen proporciona un ejemplo de los pasos de configuración:
Utilize esta sección para confirmar que su configuración funcione correctamente.
a. Vaya a Configuración > Unified Communication > Cisco Meeting Server. Debe ver la dirección IP del WB:
b. Vaya a Configuración > Unified Communication > Lista de permitidos HTTP > Reglas añadidas automáticamente. Compruebe que se ha agregado a las reglas:
Meeting Server web bridges https 443 Prefix / GET, POST, PUT, HEAD, DELETE Meeting Server web bridges wss 443 Prefix / GET, POST, PUT, HEAD, DELETE
Nota: no se espera encontrar el WB en los nodos Detectados porque las reglas son simplemente para permitir el proxy del tráfico HTTPS al WB, y no necesariamente para la comunicación unificada.
c. Compruebe que el túnel de Secure Shell (SSH) para el FQDN de WB se ha generado en Expressway-C para Expressway-E y que está activo. Vaya a Estado > Unified Communications > Unified Communications SSH tunnels status. Debe ver el FQDN del WB y el destino debe ser Expressway-E.
En el menú CMS API, busque los servidores de turno, y haga clic en cada uno. Dentro de cada objeto, hay un enlace para verificar el estado:
La salida muestra información que incluye el tiempo de ida y vuelta (RTT) en milisegundos (Ms) había asociado el servidor de activación. Esta información es importante para la selección de CB de que use el servidor de Active mejor.
En el momento en que se realiza una llamada en directo con el uso del cliente WebRTC, puede ver el estado de activación de retransmisión de medios en Expressway. Navegue hasta Estado > Uso de retransmisión de activación, luego elija ver.
Herramientas útiles:
En este escenario, el cliente RTC puede resolver el ID de llamada en jalero.space, pero cuando ingresa su nombre y selecciona Unirse a llamada, el cliente muestra Conectando, como se muestra en esta imagen:
Después de unos 30 segundos, se redirige a la página WB inicial.
Para resolver problemas, complete estos pasos:
Navegue hasta Registros > Registros de eventos en CMS WebAdmin.
En las trazas Wireshark, verá que el cliente envía asignar solicitud con las credenciales configuradas, en el servidor de Expressway-E activar en el puerto 3478:
1329 2017-04-15 10:26:42.108282 10.55.157.229 10.48.36.248 STUN 186
Allocate Request UDP user: expturncreds realm: TANDBERG with nonce
El servidor responde con asignar Error:
1363 2017-04-15 10:26:42.214119 10.48.36.248 10.55.157.229 STUN 254
Allocate Error Response user: expturncreds with nonce realm: TANDBERG UDP error-code: 431
(*Unknown error code*) Integrity Check Failure
or
3965 2017-04-15 10:34:54.277477 10.48.36.248 10.55.157.229 STUN 218
Allocate Error Response user: expturncreds with nonce realm: TANDBERG UDP error-code: 401
(Unauthorized) Unauthorized
En los registros de CMS, se muestra este mensaje de registro:
2017-04-15 10:34:56.536 Warning call 7: ICE failure 4 (unauthorized - check credentials)
Solución:
Verifique las credenciales de activación configuradas en el CMS y asegúrese de que coincidan con la que está configurada en la base de datos de autenticación local de Expressway-E.
En la Callbridge estado > General página, se muestra:
2017-04-15 12:09:06.647 Web bridge connection to "webbridge.alero.aca" failed (DNS failure) 2017-04-15 12:10:11.634 Warning web bridge link 2: name resolution for "webbridge.alero.aca" failed 2017-04-15 11:55:50.835 Info failed to establish connection to web bridge link 2 (unknown error)
Solución:
Solución:
Navegue hasta Mantenimiento > Diagnóstico > Registro de diagnóstico y asegúrese de que Tomar tcpdump durante el registro esté marcado, como se muestra en esta imagen, antes de seleccionar Iniciar nuevo registro:
Nota: asegúrese de que la captura de Wireshark en el dispositivo del cliente y el registro en Expressway-E se inician antes de reproducir la llamada que falla. Cuando se ha reproducido la llamada de un fallo, detenga y descargar el inicio de sesión en el Expressway-E y la captura en el cliente.
En este escenario, el cliente RTC puede resolver el ID de llamada en jalero.space, pero cuando ingresa su nombre y selecciona Unirse a llamada, la advertencia No se puede conectar - vuelva a intentarlo más tarde se muestra inmediatamente:
Solución:
Asegúrese de que CMS, en la red interna, consigue solucionar siempre la _xmpp cliente registro SRV para el dominio CB.
Revisión | Fecha de publicación | Comentarios |
---|---|---|
2.0 |
21-Jun-2023 |
Actualización de PII, SEO, texto alternativo, traducción automática, requisitos de estilo, ortografía y formato. |
1.0 |
20-Oct-2017 |
Versión inicial |