Réplica de sesiones de SIP

Puede configurar un dominio de réplica para sesiones SIP si desea que la réplica de sesiones y la información de estado de diálogo que se producen durante el proceso típico de SIP (Session Initiation Protocol). El contenedor SIP normalmente utiliza el servicio de réplica de datos (DRS) para duplicar toda la información de estado. DRS no proporciona ninguna forma de confirmar cuando finaliza el duplicado de datos, por lo que la única forma que puede cuantificarse es que una parte de la información de estado está en la cola para la réplica. En este tema, las referencias a la réplica de datos sólo significa que los datos se han colocado en la cola para su réplica.

Acerca de esta tarea

El contenedor SIP duplica diversos tipos de información. Estos datos se incluyen en dos categorías generales:
  • La información de estado de contenedor SIP interna asociada al diálogo.
  • La información de estado de aplicación asociada a los diversos objetos de sesión.

Cada categoría incluye varios tipos de datos que se describen más adelante en este tema. Cada objeto de datos se trata de forma independiente. Por lo que un cambio en un objeto de sesión de aplicación que cause una réplica, no da como resultado la réplica de información de estado interna.

Réplica de información de estado interna

La información de estado interna puede definirse como cualquier cosa relacionada con el estado de un diálogo manejador por el contenedor. Incluye información como cseq, estado de diálogo (inicial, anticipado, confirmado, terminado), caducidad de sesión, parte remota, local, etc. La información de estado interna sólo se duplica debido a la existencia de un diálogo. Por consiguiente, no se duplicará ningún dato interno relacionado con SIP hasta que se establezca el diálogo con el que está asociado. Los tipos de solicitudes SIP que pueden originar la creación de un diálogo son:
  • INVITE
  • SUBSCRIBE
  • REFER
La réplica del estado interno ocurre en momentos bien definidos y previsibles en el flujo de llamadas. Por ejemplo, un diálogo sólo se establece en el contenedor cuando se recibe o se envía una respuesta 2xx o una respuesta 1xx con una etiqueta “Para” debido a uno de los tipos de métodos indicados anteriormente. Los sucesos que pueden desencadenar una réplica del estado interno son:
  • Creación de un nuevo diálogo SIP
  • Caducidad de una sesión debido a que se ha excedido el tiempo de espera de sesión
  • El envío de una respuesta final a un UAC
  • Creación de un URI codificado
  • Manejo de cualquier mensaje que provoque un cambio del estado de diálogo interno

Es importante tener en cuenta que el estado de transacción no se duplica en la versión del contenedor SIP de WebSphere Application Server 6.1, sólo el estado de diálogo. Al no duplicar el estado de transacción se reduce la carga en todos los servidores del dominio de réplica, pero puede causar problemas en las anomalías que ocurren en medio de una transacción (por ejemplo, la pérdida de algunos mensajes SIP relacionados con el diálogo).

Una diferencia importante entre un B2BUA y una aplicación de proxy es el número de objetos de sesión creados y duplicados. En los dos casos sólo se crea una sola sesión de aplicación, pero para el B2BUA, se crean dos objetos de sesión, uno para el tramo de entrada y uno para el tramo de salida. Para una aplicación de proxy, sólo se crea un objeto de sesión.

Duplicación de información de estado de aplicación

La información de estado de aplicación se trata de forma distinta de la información de estado de diálogo interna porque no depende de la existencia de un diálogo que se va a duplicar. El estado de aplicación hace referencia a cualquier dato que la aplicación mantenga utilizando construcciones de datos JSR 116. Esto incluye:
  • javax.servlet.sip.SipApplicationSession
  • javax.servlet.sip.SipSession
  • javax.servlet.sip.ServletTimer
  • Cualquier atributo establecido en SipSession o SipApplicationSession
La réplica del estado interno ocurre en momentos bien definidos y previsibles del flujo de llamadas, mientras que la réplica del estado de aplicación es menos previsible porque en general depende de cuándo una aplicación cree, invalide o modifique los datos de sesión y los temporizadores a través de las API de JSR 116. Esto puede deberse al proceso de un mensaje de entrada o a la caducidad de un temporizador SIP. Las causas de la réplica de datos de sesión relacionados con la aplicación son las siguientes:
  • Creación de un objeto de sesión de aplicación
  • Creación de un objeto de sesión SIP
  • Creación de un temporizador de sesión SIP
  • Modificación de un objeto de sesión a través de setAttribute o removeAttribute
  • Anulación de un objeto de sesión SIP
  • Caducidad de un temporizador de sesión
  • El código de la aplicación que envía una solicitud 1.

La réplica puede producirse para solicitudes que no establecen un diálogo si una aplicación llama a request.getApplicationSession(true) y si se llama a addTimer() y/o a addAttribute() en el objeto de sesión de aplicación que resulta. Esto es necesario para que poder llamar al escucha cuando caduque el temporizador.

Consideraciones sobre la configuración de la réplica y migración tras error SIP

Un clúster SIP que requiere réplica y migración tras error puede estar formado por muchos dominios de réplica y cada uno contiene un conjunto de contenedores SIP. No hay ningún límite establecido en el número de contenedores en un clúster. Por razones de rendimiento, cada dominio de réplica sólo debe contener dos contenedores.

Se debe establecer el dominio de réplica en Todo el dominio, lo que significa que el estado se duplica a todos los contenedores en el dominio de réplica. La modalidad de réplica debe ser ambos, cliente y servidor.

La sesión distribuida para un contenedor necesita establecerse en réplica de memoria a memoria. Todas las aplicaciones que requieren réplica de sesión deben incluir el código <distributable/> en los archivos web.xml y sip.xml. Tanto SIP como HTTP utilizarán la misma topología de réplica

[z/OS]Asegúrese de que el sistema esté configurado de forma que:
  • El sistema incluye al menos 2 controladores y cada controlador tiene al menos 2 servants para fines de migración tras error y recuperación.
  • La carga de trabajo total, que incluye las llamadas de operación normal, llamadas a la migración tras error y llamadas de recuperación, nunca debe superar la velocidad de llamada máxima.
    Para lograr el número máximo de llamadas por segundo, se necesitan los valores de configuración siguientes:
    • Se ejecuta en un sistema z/OS Versión 1 Release 10 con FICON de alta disponibilidad para System z (zHPF) habilitado para E/S rápido. Un DASD DS8000 también debe estar ejecutándose en este sistema.
    • Las definiciones de corriente de registro y de tamaño de conjunto de datos intermedio utilizadas cuando se crean las secuencias de registro debe ser igual o superior a 256 Megabytes (LS_SIZE(64000) STG_SIZE(64000)).

    Puede determinar la tasa máxima de llamada aumentando progresivamente las tasas de llamada a lo largo de un período de tiempo y el rendimiento de supervisión hasta que se consigan tasas de tiempo de espera tolerables.

  • La cantidad total de datos propagados sobre todas las llamadas activas no exceden los 2 GB.
  • Todos los nodos están en la Versión 7.0.0.7 o un nivel posterior antes de habilitar el trabajo de SIP o CEA (Communications Enabled Applications) en z/OS.
  • Otros servicios que requieren persistencia de datos como, por ejemplo, transacciones y compensaciones, se configuran para utilizar el registro de archivos HFS si tiene previsto utilizar el sistema para trabajo relacionado con SIP o CEA. Después de configurar el sistema para trabajo relacionado con SIP o CEA, otros servicios que requieren persistencia de datos no pueden utilizar corrientes de registro.
[z/OS]También debe suprimir y volver a crear la corriente de registro para un servidor si se produce alguna de las situaciones siguientes:
  • Todos los controladores que están dentro de un clúster fallan al mismo tiempo. En esta situación, algunos de los datos que son necesarios para realizar la recuperación se pierden debido a los diversos errores simultáneos.
  • Se produce una anomalía durante el proceso de recuperación. En esta situación, la corriente de registro asociada con las sesiones de error contiene datos incompletos.
Topología de réplica de sesión SIP
  • Cada miembro duplica todos los datos de estado para cada igual en su dominio de réplica.
  • Lo ideal es que cada dominio de réplica contuviera dos servidores.
  • Cuando se produce una anomalía, el coordinador de grupo principal indica a los miembros que quedan del grupo principal qué sesión duplicada activar. Estas sesiones duplicada pasan así a formar parte de las sesiones activas.

Siga los siguientes pasos para configurar un dominio de réplica para sesiones SIP.

Procedimiento

  1. En la consola de administración, pulse Entorno > Dominios de réplica > Nuevo.
  2. Pulse Número de duplicaciones y, a continuación, seleccione Todo el dominio.
  3. En la sección Valores del contenedor, pulse Gestión de sesiones.
  4. En la sección Propiedades adicionales, pulse Valores de entorno distribuido y pulse Réplica de memoria a memoria.
  5. Establezca Modalidad de duplicación en Ambos, cliente y servidor.
  6. Guarde los cambios.

Resultados

La réplica de memoria a memoria queda duplicada para sesiones de SIP.

1 Causa la duplicación de SipSession y SipApplicationSession para sincronizar la "indicación horaria de último acceso" con los contenedores de iguales en el clúster. Esto facilita la integridad de llamadas futuras a SipSession.getLastAccessedTime() y SipApplicationSession.getLastAccessedTime()

Icon that indicates the type of topic Task topic



Timestamp icon Last updated: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tsip_sessionrep
File name: tsip_sessionrep.html