Solucionar problemas de falha de validação de capacidade de gateway de CCB (CVP Courtesy Callback)

Introdução

Este documento descreve como solucionar um problema de CCB do Customer Voice Portal (CVP) quando o chamador não recebe uma oferta de CCB porque a capacidade do gateway de tronco foi excedida.

Pré-requisitos

Requisitos

A Cisco recomenda que você tenha conhecimento destes tópicos:

• CVP
• Retorno de chamada de cortesia do Cisco CVP

Componentes Utilizados

As informações neste documento são baseadas nestas versões de software:

• Servidor CVP 10.5
• Unified Contact Center Enterprise (UCCE) 10.5

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 sua rede estiver ativa, certifique-se de que entende o impacto potencial de qualquer comando.

Informações de Apoio

Antes de solucionar o problema de capacidade do gateway, é importante entender o processo de validação de tronco no CCB. Basicamente, o processo primeiro determina o número de chamadas da tabela Callback_current com EventTypeID em (21,22,23);   Pendente, Em andamento, Provisório para gateways e locais específicos.

Segundo, na mesma tabela Callback_current, determine o número de chamadas concluídas com a causa conectada:   EventTypeID = 24 (Concluído) e CauseID = 27 (Conectado).

Finalmente, o processo adiciona esses dois valores e os compara com o número de troncos configurados no serviço Survivability.tcl.

Se o resultado for maior que o limite de troncos configurado, o processo retornará uma falha (retorno 1); caso contrário, retornará ok (retorno 0).

Resumindo, a fórmula para validar os troncos usados para CCB é:

Troncos CCB < (Tabela Callback_current com EventTypeID em (21,22,23); Pendente, Em andamento, Provisório para gateways específicos) + Tabela Callback_current de EventTypeID = 24 (Concluído) e CauseID = 27 (Conectado)

Se o valor de Troncos CCB for menor, a validação falhará.

Sintomas

Uma chamada recebida não recebe uma oferta CCB. A chamada vai diretamente para a fila, independentemente do tempo de espera estimado (EWT)

Troubleshooting

Etapa 1. Colete logs de atividade do aplicativo CallbackEntry do servidor Voice Extensible Markup Language (VXML).

Etapa 2. Procure nos logs de atividades qualquer chamada em que a validação não seja nenhuma:

Validate_02,data,result,none

O que significa que a validação não foi aprovada. Obtenha o GUID para esta chamada.  Filtre a chamada pela atividade callid e procure um callid como este exemplo:

start,parameter,callid=BBBBAAAACCCCDDDDEEEEFFFFAAAABBBB

Etapa 3. Coletar logs de relatório do CVP para o Servidor de Relatórios. Localize o mesmo callid nos logs de relatórios do CVP.

ValidateHandler:ValidateHandler.exec: ValidateHandler GUID=BBBBAAAACCCCDDDDEEEEFFFFAAAABBBB results:none validation status bitmask=0x00000103  

Etapa 4. Converta o número da máscara de bit em binário. Use uma calculadora para programadores: 0001 00000011

Etapa 5. Verifique a máscara de bits do guia de relatórios do CVP para tabelas CCB. Você deve ver que a validação falha devido a "EXCEED_CAPACITY_GW".

Etapa 6. Reduza o problema a uma fila específica. Verifique o servlet CCB a partir do servidor de relatórios CVP para determinar se há alguma fila específica onde o CCB não é oferecido. Abra um navegador da Web e digite.

http://{Endereço IP do Servidor de Relatórios}:8000/cvp/CallbackServlet?method=Diag

Este é um exemplo de uma fila em que o CCB é oferecido:

Este é um exemplo de uma fila em que o CCB não é oferecido

Passo 7.  Verifique se a(s) fila(s) é(são) servida(s) por um gateway específico. Verifique a configuração do gateway (parâmetros do aplicativo Survivability).

application
 service new-call flash:bootstrap.vxml
 !
 service survivability flash:survivability.tcl
  paramspace callfeature med-inact-det enable
  param ccb id:10.201.198.21;loc:CALO;trunks:512

Etapa 8. Se a configuração estiver correta, verifique as informações armazenadas no banco de dados do Servidor de Relatórios (Informix) para determinar o número de chamadas nesse gateway e local específicos. Você pode verificar pelo ID do CCB (10.201.198.21 neste caso) ou localização (CALO neste exemplo).

Etapa 9. No servidor de relatórios, acesse o banco de dados Informix.

Abra um prompt do CMD e digite: dbacces

Navegue até conexão > conectar

Selecionar instância cvp

digite username cvp_dbadmin

digitar senha

selecione banco de dados callback@cvp

saia e navegue até Idiomas de Consulta

Etapa 10. Executar a consulta:

Selecione count(*) de callback_current onde o local == "CALO";

Etapa 11. Se o valor for igual ou superior ao valor de tronco configurado no gateway para o(s) local(is), essa é a razão pela qual a validação falha, uma vez que o número máximo de troncos permitidos foi atingido na tabela Callback_Current.

Note:  Conforme mencionado no guia de relatórios do CVP, a tabela de retorno de chamada é uma exibição de duas tabelas: Callback_Current e Callback_Historical. As duas tabelas são idênticas. A cada 30 minutos, os dados das chamadas concluídas são extraídos de Callback_Pending e movidos para Callback_Historical.

Etapa 12. Se o valor de tronco por local tiver atingido seus limites na tabela Callback_Current e não houver retornos de chamada na fila, isso indica que há um problema na movimentação dos registros de retorno de chamada de Callback_Current para a tabela Callback_Historical.

Etapa 13. Verifique se CVPCallbackArchive está em execução em Agendar Tarefas (Servidor de Relatórios do CVP). Navegue até Iniciar -> Programas -> Acessórios -> Ferramentas do sistema -> Tarefa agendada.

.

Etapa 14. Se esta tarefa CVPCallbackArchive for concluída, verifique se o código de saída é (0x0).

Etapa 15. Se as etapas 13 e 14 estiverem corretas, mas ainda não houver dados na tabela Callback_Historical, você precisará determinar por que as informações não foram adicionadas ao banco de dados. Verificar a integridade das informações armazenadas nas tabelas atual e histórica.  Execute esta consulta na janela informix dbaccess CMD:

Select  count (*) from callback_current where surrogateid in (select surrogateid from callback_historical);

Etapa 16.  Se a contagem for 1 ou superior, significa que a chave primária na tabela atual já existe na tabela histórica e as informações não são adicionadas ao banco de dados. Na maioria desses cenários, uma condição de corrida faz com que registros duplicados entrem na tabela callback_current.

O GUID para mapeamento de ID de substituição acontece na tabela de filas. Em situações em que a chamada é movida do script de espera de retorno de chamada para o script de fila de retorno de chamada, parece haver uma janela em que o trabalho de arquivamento move os registros do atual para o histórico e o aplicativo insere um novo registro na tabela atual com a mesma ID de substituto.  Esse problema está relacionado a este CDETS CSCuq86400

Solução

Etapa 1. Acessar o banco de dados Informix. Abra um prompt do CMD e digite: dbacces

Etapa 2. Navegue até connection > connect e selecione a instância cvp. Digite o nome de usuário cvp_dbadmin e a senha

Etapa 3. Selecione callback@cvp database exit e navegue até Query Languages

Etapa 4. Executar estes comandos:

excluir de callback_current onde surrogateid está em (selecione surrogateid de callback_historical);

Se houver um erro temporário na tabela, faça o seguinte:

descartar tabela t1;

Etapa 5. Execute o procedimento sp que move as informações da tabela de retorno de chamada Atual para a tabela de retorno de chamada histórica a partir da janela de linguagem de consulta dbaccess.

EXECUTE PROCEDURE sp_arch_callback();

Etapa 6. Verifique se não há tantos registros na tabela atual quanto antes.

Selecione count(*) de callback_current onde o local == "CALO";

Solução permanente

Etapa 1. Navegue até Cisco\CVP\informix_frag e abra sp_arch_callback.sql em um editor de texto.

Etapa 2. Descomente esta linha no início do arquivo: —procedimento drop sp_arch_callback;   (remover — no início da linha).

Etapa 3. Adicione esta linha: deletar de callback_current onde se encontra o substituto em (selecione surrogateid de callback_historical) ; após

crie a linha de procedimento sp_arch_callback().

Etapa 4. Salve o arquivo.

Etapa 5. Este é um exemplo de como deve ser a primeira parte do arquivo.

{*********************************************************************************
Stored procedure to move completed calls out of the active table into the
historical table.
*********************************************************************************}
drop procedure sp_arch_callback;
create procedure sp_arch_callback()

DEFINE p_ageoff INTEGER;

-- delete any duplicates found in current table.

 

delete from callback_current where surrogateid in (select surrogateid from callback_historical);

 

 

Testar solução final

Etapa 1.  Abra um prompt do CMD e execute o comando: dbschema 

dbschema -d callback -f sp_arch_callback

Observação: se você tiver um problema de autorização ao executar o comando dbschema, efetue login como cvp_dbadmin no servidor de relatório e tente mais uma vez.

Etapa 2. Na saída, certifique-se de que o comando Delete from seja executado.