Contents

Introdução

Pré-requisitos

Requisitos

Componentes Utilizados

Informações de Apoio

Configurar

Verificar

Troubleshooting

Introdução

Este documento descreve como configurar enableDelayQuickReinvite para evitar que o Servidor de Aplicativos (AS) envie um re-INVITE muito rapidamente após um ACK.

Pré-requisitos

- Conhecimento do protocolo básico de início de sessão (SIP)

- Conhecimento básico de AS

- Conhecimento básico da BroadWorks bwcli

Requisitos

- Ser capaz de usar o AS bwcli e um usuário administrador

- Ser capaz de revisar os AS XSLogs

Componentes Utilizados

- Cisco BW AS

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.

Informações de Apoio

Em alguns cenários de chamada, o AS precisa iniciar uma reconexão e, para fazer isso, ele envia um re-INVITE para ambas as extremidades. Casos típicos onde isso pode acontecer são chamadas para "Call Centers", "Hunt Groups" ou que envolvem "Click to Dial" ou "Call Recording" e, em geral, vários casos onde o AS precisa disparar uma reconexão depois que uma sessão foi estabelecida.

Quando o AS precisa enviar re-INVITE após o ACK ter sido enviado no mesmo diálogo, o AS normalmente envia re-INVITE no mesmo momento que o ACK, e isso pode fazer com que o ACK e re-INVITE sejam recebidos fora de ordem pelo dispositivo remoto.

Quando isso acontece, o dispositivo que recebe o re-INVITE antes do ACK pendente pode rejeitar o re-INVITE, normalmente com um código de erro 500 (mas isso pode variar, com base na implementação do dispositivo remoto).

Configurar

Há dois parâmetros usados para configurar esse recurso, ambos localizados no bwcli em AS_CLI/Interface/SIP>.

- enableDelayQuickReInvite é o switch principal para ligar ou desligar o recurso. Os valores aceitos são verdadeiro e falso

- delayQuickReInviteMilliseconds é o valor em milissegundos (ms) do atraso adicionado após o ACK. O intervalo de valores é 100ms a 10000ms.

Para configurar esse recurso, abra o AS bwcli, efetue login como um usuário Admin e navegue até AS_CLI/Interface/SIP>:

AS_CLI> cd /Interface/SIP

AS_CLI/Interface/SIP>

Primeiro execute um comando get para verificar os valores atuais de ambos os parâmetros. Por padrão, enableDelayQuickReInvite está desabilitado (falso) e o valor padrão de delayQuickReInviteMilliseconds é 1000 (1000ms ou 1 segundo).

Parte da saída do comando get é omitida para melhorar a legibilidade.

AS_CLI/Interface/SIP> get

...

enableDelayQuickReInvite = false

delayQuickReInviteMilliseconds = 1000

...

Em seguida, configure o parâmetro delayQuickReInviteMilliseconds. Você pode aceitar o valor padrão ou usar o mais adequado ao seu ambiente. A recomendação é usar o menor valor possível, portanto, é recomendável começar com o valor de 100 ms e aumentá-lo apenas no caso de não ser suficiente para permitir que o problema seja resolvido.

AS_CLI/Interface/SIP> set delayQuickReInviteMilliseconds 100

...Done

Depois que o valor de delayQuickReInviteMilliseconds tiver sido configurado, você poderá habilitar enableDelayQuickReInvite.

AS_CLI/Interface/SIP> set enableDelayQuickReInvite true

...Done

Verificar

Uma vez concluída a configuração, execute o cenário de chamada novamente, para certificar-se de que o AS adiciona o atraso entre o ACK e o re-INVITE. Por exemplo, se o AS foi configurado para adicionar 100 ms, você pode esperar que o atraso seja de pelo menos 100 ms, mas pode ser alguns ms maior.

Normalmente, 100 ms são suficientes para impedir que o ACK e o CONVITE novamente sejam recebidos fora de ordem, mas o valor pode ser maior, com base no ambiente de rede e nas entidades SIP envolvidas no caminho de sinalização.

Troubleshooting

Se o dispositivo ainda responder com um código de erro 500 e o ACK e o CONVITE novamente tiverem sido entregues na ordem correta, será necessária uma investigação adicional no dispositivo.

Use os XSLogs no AS para verificar se o AS adicionou o atraso conforme configurado e use uma captura de pacote ou os logs de dispositivo para garantir que o atraso foi suficiente para que as mensagens sejam entregues na ordem correta.

Note que isto só funciona quando o AS envia um re-INVITE logo após ter enviado um ACK, mas não funciona no caso de o AS receber um ACK e que faz com que o AS envie um re-INVITE.