Si las llamadas de Webex a su empresa no están sonando en el lado empresarial, revise los puntos de esta lista de verificación para verificar su configuración.

Antes de revisar estas sugerencias de solución de problemas, consulte https://status.webex.com para obtener la información más reciente sobre cualquier interrupción de la nube. Desde esa página de estado, también puede suscribirse a las notificaciones.

Verifique estos puntos de solución de problemas relacionados con la conexión TLS mutua y los certificados:

• Instale el paquete de certificados raíz de la nube de Webex en Expressway-E.

• Configure un puerto TLS mutuo dedicado en Expressway-E.

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

• Abra el número de puerto TLS mutuo en su firewall: 5062, que puede no estar abierto de forma predeterminada.

• Determine qué opción de certificado raíz está utilizando en Webex Cloud: la opción se utiliza para verificar el certificado TLS SIP de Expressway-E.

  • Tienda predeterminada: ¿su certificado Expressway-E está firmado por una de las autoridades públicas? Si no está seguro, utilice la opción de tienda personalizada.

  • Tienda personalizada: ¿su certificado Expressway-E o su firmante está instalado 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 > Híbrido > Llamada híbrida > Configuración. Compruebe estos puntos que están relacionados con su destino SIP que estableció durante el proceso de implementación:

• El valor apunta a su puerto TLS mutuo dedicado 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 usó un SRV, asegúrese de que tenga el formato _sips. _tcp. < dominio que puso como destino SIP >.

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

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

• Para las llamadas que van desde Webex hacia la empresa, verifique el historial de búsqueda y los registros de red en Expressway-E. Este paso le ayuda a aislar el problema a la nube o a la empresa.

• Si reutiliza una zona B2B y reglas de búsqueda existentes, considere crear zonas dedicadas y reglas de búsqueda en su lugar. Esta configuración evita la interferencia con la configuración de zona existente para B2B/MRA, evita los bucles de enrutamiento y facilita la resolución de problemas.

• Verifique el historial de búsqueda y los registros de red en Expressway-E. Verifique que el SIP INVITE de la nube llegue a Expressway-E y coincida con la zona DNS que configuró para la nube.

  • Si el SIP INVITE no llega ni coincide con la zona DNS configurada, siga la ruta de la llamada hacia el Administrador de Comunicaciones Unificadas. Este paso le ayuda a encontrar dónde falla o se pierde la llamada.

  • Vea la lista de verificación de solución de problemas de TLS mutua.

• Compruebe el encabezado de la ruta. Verifique que contenga el valor del nombre de dominio completo (FQDN) del clúster configurado en la configuración empresarial de Unified Communications Manager y en las reglas de búsqueda de Expressway. Vea este ejemplo de encabezado de ruta y FQDN del clúster resaltado:

  • Ruta: <sip: [Obfuscated]; transport=tls; lr>, <sip:myucmcluster.example.com; lr>

    • En este ejemplo, el FQDN del clúster de inicio es myucmcluster.example.com.

• Los correos electrónicos en 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.

• Los URI 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 soportan los siguientes códecs:

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

  • Vídeo—H.264

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

• En el clúster principal de Unified Communications Manager de los usuarios afectados, elija Sistema > Parámetros de empresa; en Configuración de dominio en todo el clúster, compruebe la configuración del nombre de dominio completo (FQDN) del clúster. El valor FQDN que utilizó debe seguir estas pautas:

  Pauta FQDN	Descripción y ejemplo
  Múltiples clústeres	La entrada debe ser única para cada clúster con llamadas híbridas, por ejemplo, cluster1.example.comcluster2.example.com, y así sucesivamente.
  Sin comodín	No utilice entradas con caracteres comodín, como *.example.com o 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 un comodín. Vea este ejemplo de tres entradas FQDN de izquierda a derecha (la primera es para llamadas híbridas): cluster1.example.com *.example.com example*.com
  Diferente de Expressway-E	Debe ser diferente del sistema Expressway-E, DNS y nombre de dominio. De lo contrario, Expressway-E borda el encabezado de la ruta.
  Nueva entrada para llamadas híbridas	Si su entrada de FQDN actual Unified CM no cumple los requisitos enumerados anteriormente, puede agregar un nuevo elemento al comienzo de la configuración de FQDN del clúster para llamadas híbridas. Por ejemplo, si su configuración de FQDN existente Cisco Unified Communications Manager es *.example.com *.example.org, agregue una entrada única que no sea comodín al principio del campo: "cluster1.example.com *.example.com *.example.org”