Introducción
Este documento describe cómo configurar enableDelayQuickReinvite para evitar que Application Server (AS) envíe una reinvitación demasiado rápido después de un ACK.
Prerequisites
- Conocimiento básico del protocolo de inicio de sesión (SIP)
- Conocimiento básico de AS
- Conocimiento básico de BroadWorks bwcli
Requirements
- Poder utilizar el AS bwcli y un usuario administrador
- Poder revisar los AS XSLogs
Componentes Utilizados
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.
Antecedentes
En algunos escenarios de llamadas, el AS necesita iniciar una reconexión, y para hacerlo, envía una re-INVITE a ambos extremos. Los casos típicos donde esto puede suceder son llamadas a "Call Centers", "Hunt Groups" o que involucran "Click to Dial" o "Call Recording" y, en general, varios casos donde el AS necesita activar una reconexión después de que se ha establecido una sesión.
Cuando el AS necesita enviar re-INVITE después de que el ACK fue enviado en el mismo diálogo, el AS normalmente envía el re-INVITE en el mismo momento que el ACK, y esto puede hacer que el dispositivo remoto reciba el ACK y re-INVITE fuera de servicio.
Cuando esto sucede, el dispositivo que recibe el re-INVITE antes del ACK pendiente puede rechazar el re-INVITE, normalmente con un código de error 500 (pero esto puede variar, según la implementación del dispositivo remoto).
Configurar
Hay dos parámetros utilizados para configurar esta función, y ambos se encuentran en el bwcli en AS_CLI/Interface/SIP>.
- enableDelayQuickReInvite es el interruptor principal para activar o desactivar la función. Los valores aceptados son true y false
- delayQuickReInviteMilliseconds es el valor en milisegundos (ms) del retraso agregado después del ACK. El rango de valores es de 100 ms a 10000ms.
Para configurar esta función, abra AS bwcli, inicie sesión como usuario administrador y luego navegue hasta AS_CLI/Interface/SIP>:
AS_CLI> cd /Interface/SIP
AS_CLI/Interface/SIP>
Primero ejecute un comando get para verificar los valores actuales de ambos parámetros. De forma predeterminada, enableDelayQuickReInvite está deshabilitado (false) y el valor predeterminado de delayQuickReInviteMilliseconds es 1000 (1000 ms o 1 segundo).
Parte del resultado del comando get se omite para mejorar la legibilidad.
AS_CLI/Interface/SIP> get
...
enableDelayQuickReInvite = false
delayQuickReInviteMilliseconds = 1000
...
A continuación, configure el parámetro delayQuickReInviteMilliseconds. Puede aceptar el valor predeterminado o utilizar el más adecuado para su entorno. La recomendación es utilizar el valor más bajo posible, por lo que es recomendable comenzar con el valor de 100ms, y aumentarlo por si no es suficiente para permitir que se solucione el problema.
AS_CLI/Interface/SIP> set delayQuickReInviteMilliseconds 100
...Done
Una vez configurado el valor de delayQuickReInviteMilliseconds, puede habilitar enableDelayQuickReInvite.
AS_CLI/Interface/SIP> set enableDelayQuickReInvite true
...Done
Verificación
Una vez finalizada la configuración, ejecute nuevamente el escenario de llamadas para asegurarse de que el AS agregue el retraso entre el ACK y el re-INVITE. Por ejemplo, si el AS se ha configurado para agregar 100 ms, puede esperar que la demora sea de al menos 100 ms, pero podría ser unos pocos ms más alta.
Normalmente, 100 ms son suficientes para evitar que el ACK y el re-INVITE se reciban fuera de servicio, pero el valor podría ser mayor, en función del entorno de red y las entidades SIP involucradas en la ruta de señalización.
Troubleshoot
Si el dispositivo sigue respondiendo con un código de error 500, y el ACK y el re-INVITE se han entregado en el orden correcto, se necesita una investigación adicional en el dispositivo.
Utilice los XSLogs en el AS para verificar que el AS agregó el retraso según lo configurado, y utilice una captura de paquetes o los registros del dispositivo para asegurarse de que el retraso fue suficiente para que los mensajes se entregaran en el orden correcto.
Tenga en cuenta que esto sólo funciona cuando el AS envía un RE-INVITE justo después de enviar un ACK, pero no funciona en caso de que el AS reciba un ACK y eso hace que el AS envíe un RE-INVITE.
Comentarios