Si las llamadas de Webex a su empresa no suenan en el lado empresarial, re recorrido los puntos de esta lista de verificación y revise su configuración.

Antes de leer estas sugerencias para la solución de problemas, consulte para conocer la información más reciente sobre cualquier caída de la nube.https://status.webex.com En esa página de estado, también puede suscribirse a las notificaciones.

Consulte estos puntos para la solución de problemas relacionados con la conexión de TLS mutuo y los certificados:

• Instale el paquete de paquetes certificado raíz nube de Webex en el Expressway-E.

• Configure un puerto TLS mutuo exclusivo en el Expressway-E.

• Configure una zona DNZ para la nube en el Expressway-E.

• Abra el número de puerto TLS mutuo en su firewall (5062); es posible que no esté abierto por defecto.

• Determine certificado raíz opción que está usando en la nube de Webex: la opción se utiliza para verificar el certificado SIP TLS de su Expressway-E.

  • Almacén predeterminado: El certificado de su Expressway-E, ¿está firmado por una de las autoridades públicas? Si no está seguro, utilice la opción del almacén personalizado.

  • Almacén personalizado: El certificado de su Expressway-E o su firmante, ¿están instalados en la nube? ¿El certificado contiene nombres de host Expressway-E verificados?

Desde la vista del cliente en https://admin.webex.com, vaya a Servicios > Servicio > Llamada híbrida > Configuración . Compruebe estos puntos relacionados con su destino SIP que definió en el proceso de implementación:

• El valor apunta al puerto TLS mutuo exclusivo de su Expressway-E.

• Intente conectarse a la dirección IP:puerto. (Varias direcciones si configuró un SRV).

• Si configuró una dirección IP o un nombre de host, especifique el puerto TLS mutuo.

• Si utilizó un SRV, asegúrese de que tenga el formato _sips._tcp.<dominio que introdujo como destino SIP>.

• Si no quiere configurar un SRV, puede introducir dirección IP:puerto o nombre de host:puerto como destino SIP de su organización.

• Si fallan las llamadas de Expressway-E a la nube y está utilizando el método manual de administración de certificados, asegúrese de seguir los pasos que se indican en Actualización de certificado de la CA raíz de Webex y cargar el certificado IdenTrust en sus dispositivos Expressway lo antes posible.

• Para llamadas que se enruta desde Webex hacia la empresa, revise el historial de búsqueda y los registros de red en el Expressway-E. Este paso le ayudará a determinar si el problema está en la nube o en la empresa.

• Si vuelve a utilizar una zona B2B y reglas de búsqueda existentes, considere la posibilidad de crear zonas y reglas de búsqueda exclusivas. Esta configuración evita interferencias con los ajustes de zonas existentes para B2B/MRA, evita bucles de enrutamiento y facilita la solución de problemas.

• Revise el historial de búsqueda y los registros de red en el Expressway-E. Verifique que la INVITACIÓN SIP proveniente de la nube llegue al Expressway-E y coincida con la zona DMZ que configuró para la nube.

  • Si la INVITACIÓN SIP no llega o no coincide con la zona DNS configurada, siga la ruta de la llamada hacia Unified Communications Manager. Este paso le ayuda a encontrar el punto en el que falla o se pierde la llamada.

  • Consulte la lista de verificación para la solución de problemas en el TLS mutuo.

• Compruebe el encabezado de la ruta. Verifique que contenga el valor del Nombre de dominio completamente calificado (Fully Qualified Domain Name, FQDN) del grupo que está configurado en los ajustes empresariales de Unified Communications Manager en las reglas de búsqueda de Expressway. Mire este ejemplo de encabezado de ruta y FQDN de grupo resaltado:

  • Ruta: ,

    • En este ejemplo, el FQDN del grupo de inicio es myucmcluster.example.com.

• Los correos electrónicos de Unified Communications Manager deben coincidir exactamente con el correo electrónico (sincronizado desde Active Directory o desde cualquier otra fuente) en la nube de Webex.

• Las URL de directorio deben coincidir con cualquier dominio que haya verificado en su organización.

• Compruebe la configuración de su códec.

  Los servicios de Webex admiten los siguientes códecs:

  • Audio: G.711, G.722, AAC-LD

  • Vídeo: H.264

  Admitimos G.729 para entrar a una reunión de Webex, una reunión de sala personal o una reunión de la aplicación de Webex desde un dispositivo SIP. No admitimos G.729 para marcar de 1:1 desde la aplicación de Webex a un dispositivo o puente SIP.

• En el grupo de inicio de Unified Communications Manager de los usuarios afectados, elija Sistema > Parámetros empresariales; en Configuración de dominios a nivel de grupos, compruebe el ajuste del Nombre de dominio completamente calificado (FQDN) del grupo. El valor de FQDN que utilice debe seguir estas pautas:

  Pauta para el FQDN	Descripción y ejemplo
  Varios grupos	La entrada debe ser única para cada grupo con llamadas híbridas, por ejemplo, cluster1.example.com, cluster2.example.com, etc.
  No se admiten comodines	No utilice entradas con comodines, como *.example.com ejemplo*.com.
  Primera entrada de FQDN para llamadas híbridas	En una lista de varias entradas, la nube de Webex utiliza la primera entrada a la izquierda para llamadas híbridas, y esa primera entrada no debe contener comodines. Vea este ejemplo de tres FQDN entradas de izquierda a derecha (la primera es para Llamadas híbridas): grupo1.ejemplo.com *.ejemplo.com ejemplo*.com
  Diferente de Expressway-E	Debe ser diferente del nombre del sistema Expressway, DNS y de dominio. De lo contrario, Expressway-E retira el encabezado de ruta.
  Entrada nueva para llamadas híbridas	Si la entrada de su FQDN actual en Unified CM no cumple con los requisitos enumerados anteriormente, puede Agregar un nuevo elemento al comienzo del FQDN de grupo para las llamadas híbridas. Por ejemplo, si su ajuste de FQDN existente en Cisco Unified Communications Manager es *.ejemplo.com *.ejemplo.org, agregue una entrada única sin comodines al comienzo del campo: "grupo1.ejemplo.com *.ejemplo.com *.ejemplo.org"