Minhas chamadas de vídeo para reuniões habilitadas para dispositivos de vídeo estão soltando após 15 minutos (ou após algum tempo específico)

Minhas chamadas de vídeo para reuniões habilitadas para dispositivos de vídeo estão soltando após 15 minutos (ou após algum tempo específico).

As conexões de chamada de vídeo Cisco Webex reuniões habilitadas para dispositivos de vídeo estão desconectando-se após 15 minutos.

As chamadas SIP estão soltando após um intervalo de tempo definido.

Conexões para reuniões habilitadas para dispositivos de vídeo estão desconectando após 15 minutos.

As chamadas de vídeo caem após 15 minutos.

 

Causa: Quando as chamadas de vídeo são desconectadas em exatamente 15 minutos, o problema comum é o tempo expirado TCP configurado na rede (firewall/roteadores) é menor do que o temporizador de expiração da sessão SIP. Por padrão no CallManager, o temporizador de expiração da sessão SIP é definido como 1800 segundos.

Solução:

Para verificar isso:

  1. Abra Cisco Unified Communications Manager (CM).
  1. Clique em Parâmetros > de Serviço do Sistema.
  2. Em Selecionar servidor e serviço, na caixa de lista suspensa de serviço, selecione Cisco Call Manager (Ativo):
Imagem adicionada pelo usuário
  1. Procure o temporizador de expiração da sessãoSIP:
Imagem adicionada pelo usuário

Todos os dispositivos registrados no CUCM usam este temporizador. Quando o dispositivo está em uma chamada com outro dispositivo remoto, uma das partes tem que atualizar a sessão e enviar uma nova solicitação ou ATUALIZAÇÃO. Esta atualização tem que ser enviada antes da metade do temporizador de expiração da sessão ( 1800/2 = 900 segundos = 15 minutos). Se não houver uma mensagem de atualização recebida, a chamada é desconectada.

Verifique o temporizador de sessão no CONVITE inicial. Uma atualização (CONVIDAR/ATUALIZAR) deve ser recebida antes deste tempo expirar:
Imagem adicionada pelo usuário

Com base na negociação inicial do Cliente agente de usuário /Servidor de Agente de Usuário (UAC/UAS), um dos dispositivos atualiza a sessão ao enviar um Novo CONVITE. Se o atualizador for UAC, o iniciador da chamada terá a responsabilidade de atualizar a sessão. Se o atualizador for UAS, o servidor terá que atualizar a sessão. Colete os registros de depuração SIP de ambos os terminais e marque esses itens:

Exemplo: Chamada feita de Parte A para CUCM para Parte B. Se o atualizador for UAC na Parte A e UAS na Parte B:

1.     A parte A tem que enviar a re-CONVIDAR/ATUALIZAR para o CUCM.
2.     O CUCM tem que enviar uma re-CONVIDAR/ATUALIZAR para a Parte B.
3.     O parte B recebe a re-CONVIDAR e responde a essa mensagem com 200 OK.
4.     O CUCM tem que enviar 200 OK para a parte A.

Se um dispositivo enviar a mensagem de novo CONVITE para o CUCM, o CUCM enviará um novo CONVITE para a outra parte. No entanto, se isso não for recebido pelo lado remoto, isso pode acontecer por causa de alguns dispositivos de rede entre eles. É altamente possível que a re-CONVIDAR/resposta não chegar a um dos lados devido à inspeção SIP ou às configurações de rede.
Se os dispositivos não iniciarem a re-CONVIDAR, pode ser um problema com o dispositivo. Envolva o Centro de Assistência Técnica (TAC) da Cisco para investigar mais.
 
Na lista de coisas a tentar [se isso ainda não foi] na área de configuração avançada da zona que vai para Webex:
adote o modo de filtro SIP UDP/IX para em [não o padrão]:
Imagem adicionada pelo usuárioE verifique os temporizadores de sessão SIP no VCS-e também.

 
Nosso padrão é de 1800s [15 minutos], o que é padrão e você deseja certificar-se de que o temporizador TCP no seu Firewall também corresponde aqui, mas você pode bater um pouco isso para ver se ele também tem um efeito no seu VCS.

Isso está em Configuração > Protocolos > SIP:Observe
Imagem adicionada pelo usuário

que o intervalo de atualização da sessão (segundos) está definido como o valor padrão. Você pode tentar 3600. Mas a raiz real do problema aqui é quando o FW pensa que uma sessão não está mais em uso [caso 1], quando o VCS realmente acha que está ok e que a sessão ainda está em atividade, mas não recebe um FIN/fechar naquela sessão/porta e tenta rea usá-la e a chamada de confirmação. [caso 2] é o FW que fecha corretamente a conexão e envia um FIN/fechar e o VCS registra uma queda/limpeza de chamada normal e a chamada também está descrente. Modificar o temporizador de sessão aqui controla quando o VCS desistirá de uma sessão depois de não ter recebido quaisquer ACKs para qualquer tentativa de comunicação relacionada ao status da chamada.
 
Isso pode nos ajudar a apontar o problema um pouco melhor. Também é possível que precisamos baixar este valor, dependendo da configuração FW para este temporizador.

Este artigo foi útil?