Cómo funciona la conmutación por fallas de servicios telefónicos para Jabber versión 14 sobre MRA

Introducción

Este documento describe cómo funciona la conmutación por fallo para los servicios telefónicos en Jabber cuando se registra a través de Mobile and Remote Access (MRA) con la adición de Utilidades transversales de sesión para NAT (STUN) mantiene los activos en la versión 14 y posteriores.

Prerequisites

Requirements

Cisco recomienda que tenga conocimiento sobre estos temas:

• Cisco Unified Communications Manager (CUCM).
• Núcleo de Cisco Expressway.
• Perímetro de Cisco Expressway.
• Cisco Jabber para Windows.
• Cisco Jabber para MAC.
• Cisco Jabber para Android.
• Cisco Jabber para iOS.

Componentes Utilizados

La información que contiene este documento se basa en las siguientes versiones de software y hardware.

• Expressway Versión X14.0.
• CUCM 14.0.
• Cisco Jabber Versión 14.0.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.

Antecedentes

Para las versiones anteriores a x14.0, la solución MRA no admite conmutación por fallas automática para los servicios telefónicos en clientes de software como Jabber. Con la introducción de STUN keep-alive, esto ahora se admite siempre que los componentes involucrados cumplan los criterios requeridos, esto permite a jabber registrarse en un servidor secundario si la ruta principal o el servidor en sí se ponen en peligro o no son accesibles.

Configuración

La única configuración necesaria es habilitar STUN Keep Alives en los servidores de expressway. Esta función está activada de forma predeterminada y sólo se debe configurar si se ha desactivado previamente.

Paso 1. Abra la interfaz web de Expressway-C.

Paso 2. Vaya a Configuration > Unified Communications > Configuration > Advanced.

Paso 3. Abra la interfaz de línea de comandos (CLI) de Expressway-C.

Paso 4. Ejecute el siguiente comando: xconfiguration SIP Advanced StunKeepAliveForRegisteredPathEnabled: encendido.

Nota: La configuración debe coincidir entre los servidores de núcleo y de borde para evitar problemas de descodificación.

Resolución de problemas

Para garantizar la eficacia de la función, es necesario analizar la señalización de registro.

Recopilar registros de diagnóstico

Paso 1. En la interfaz web de servidores de expressway, navegue hasta Mantenimiento > Diagnóstico > Registro de diagnóstico.

Paso 2. Marque la casilla de Tomar tcpdump mientras se registra.

Paso 3. Seleccione Start new log en los servidores Core y Edge.

Paso 4. Inicie sesión en su cuenta en el cliente Jabber con su nombre de usuario y contraseña estándar y espere a que se registren los servicios telefónicos.

Paso 5. Seleccione Detener el registro en los servidores de núcleo y perímetro

Paso 6. En todos los servidores de Expressway, seleccione Recopilar registro y Descargar registro después de que se cargue.

Nota: En el caso de un clúster, se debe repetir el paso 6 en los pares secundarios.

Registro

Un cliente Jabber en la versión 14 y posteriores incluye la etiqueta x-cisco-mra-ha=AR_SK en el mensaje de registro como se ve a continuación en el encabezado de contacto o en el encabezado admitido, esto indica que se soportan las señales de mantenimiento STUN.

 SIPMSG:
 |REGISTER sip:cmpub01.rvalverd.local SIP/2.0
 Via: SIP/2.0/TLS 172.16.84.136:58980;branch=z9hG4bK00003665
 Call-ID: 00505696-779a0005-00001bba-00007938@172.16.84.136
 CSeq: 104 REGISTER
 Contact: 
     
     
       ;+sip.instance=" 
      
        ";+u.sip!devicename.ccm.cisco.com="CSFMRA01";+u.sip!model.ccm.cisco.com="503";video;x-cisco-mra-ha=AR_SK;x-cisco-reg-id=1 From: 
       
         ;tag=00505696779a000700006827-00006484 
        
       
     

El mensaje 200 OK debe contener esto también en el encabezado Soportado para indicar que el servidor lo soporta.

 SIPMSG:
 |SIP/2.0 200 OK
 Via: SIP/2.0/TLS 172.16.84.136:58980;branch=z9hG4bK00007e98;received=10.88.246.8;rport=58980;ingress-zone=CollaborationEdgeZone
 Call-ID: 00505696-779a0005-00001bba-00007938@172.16.84.136
 CSeq: 105 REGISTER
 Contact: 
     
     
       ;+sip.instance=" 
      
        ";+u.sip!devicename.ccm.cisco.com="CSFMRA01";+u.sip!model.ccm.cisco.com="503";video;x-cisco-mra-ha=AR_SK;x-cisco-reg-id=1;+u.sip!userid.ccm.cisco.com="mra01";x-cisco-newreg From: 
       
         ;tag=00505696779a000700006827-00006484 To: 
        
          ;tag=385623253 Server: Cisco-CUCM12.5 Expires: 120 Date: Thu, 24 Jun 2021 19:09:09 GMT Supported: X-cisco-srtp-fallback,X-cisco-sis-9.2.0,X-cisco-supports-AR_SK Session-ID: 9b8c276600255000a0000e5dc13f0000;remote=c31f584200255000a00000ddda3c0000 
         
        
       
     

Después de esto, jabber entonces envía un paquete STUN keep alive cada 30 segundos a los servidores de expressway para verificar la disponibilidad de la trayectoria. El tiempo de espera para STUN keep alive es de 3 segundos y si no se recibe respuesta, el jabber considera que el nodo de borde está inactivo y realiza una conmutación por fallas de registro a través de un servidor de borde diferente.

Nota: El cliente MRA no intenta una conmutación por fallas de registro mientras está en una llamada activa. En su lugar, la conmutación por fallas se pone en cola hasta que finaliza la llamada. Si esto sucede, la conmutación por fallas ocurre incluso si el servidor desconectado se recupera.