O conjunto de documentação deste produto faz o possível para usar uma linguagem imparcial. Para os fins deste conjunto de documentação, a imparcialidade é definida como uma linguagem que não implica em discriminação baseada em idade, deficiência, gênero, identidade racial, identidade étnica, orientação sexual, status socioeconômico e interseccionalidade. Pode haver exceções na documentação devido à linguagem codificada nas interfaces de usuário do software do produto, linguagem usada com base na documentação de RFP ou linguagem usada por um produto de terceiros referenciado. Saiba mais sobre como a Cisco está usando a linguagem inclusiva.
A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização. Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional. A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.
Este original descreve como pesquisar defeitos um problema portal da Voz de cliente (CVP) CCB quando o chamador não obtém uma oferta CCB porque a capacidade do gateway do tronco excedeu.
A Cisco recomenda que você tenha conhecimento destes tópicos:
As informações neste documento são baseadas nestas versões de software:
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.
Antes que o problema de potencialidade do gateway esteja pesquisado defeitos, é importante compreender o processo de validação do tronco no CCB. Basicamente, o processo determina primeiramente o número de atendimentos da tabela de Callback_current com EventTypeID dentro (21,22,23); Pendente, Inprogress, provisórios para gateways específicos e lugar.
Em segundo, da mesma tabela de Callback_current, determine, o número de atendimentos terminados com a causa conectada: EventTypeID = 24 (terminado), e CauseID = 27 (conectado).
Finalmente o processo adiciona estes dois valores e compara-os com o número de troncos configurados sob o serviço Survivability.tcl.
Se o resultado está sobre o ponto inicial dos troncos configurado, o processo envia para trás uma falha (retorno 1), se não envia para trás a aprovação (retorno 0).
Em resumo, a fórmula para validar os troncos usados para o CCB é:
Troncos CCB < (tabela de Callback_current com EventTypeID dentro (21,22,23); Pendente, Inprogress, provisórios para gateways específicos) + tabela de Callback_current de EventTypeID = 24 (terminado), e CauseID = 27 (conectado)
Se o valor dos troncos CCB é mais baixo a validação falha.
Uma chamada recebida não obtém a oferta CCB. O atendimento vai diretamente enfileirar de qualquer maneira o tempo de espera calculado (EWT)
Etapa 1. Recolha logs de atividade do aplicativo de CallbackEntry do server do linguagem de marcação extensível da Voz (VXML).
Etapa 2. Procure dentro dos logs de atividade por todo o atendimento onde a validação não é nenhuma:
Validate_02,data,result,none
Qual significa que a validação não passou. Obtenha o GUID para este atendimento. Filtre o atendimento pelo callid da atividade e procure um callid como este exemplo:
start,parameter,callid=BBBBAAAACCCCDDDDEEEEFFFFAAAABBBB
Etapa 3. Recolha logs do relatório CVP para o server do relatório. Encontre o mesmo callid nos logs do relatório CVP.
ValidateHandler:ValidateHandler.exec: ValidateHandler GUID=BBBBAAAACCCCDDDDEEEEFFFFAAAABBBB results:none validation status bitmask=0x00000103
Etapa 4. Converta o número do bitmask ao binário. Use uma calculadora do programador: 0001 00000011
Etapa 5. Verifique o bitmask do guia de relatório CVP para ver se há tabelas CCB. Você deve ver que a validação falha devido a “EXCEED_CAPACITY_GW”.
Note: ICM_NO_SHCEDULED_ALLOWED e o bit APROVADO são ajustados sempre
Etapa 6. Reduza a edição para baixo a uma fila específica. Verifique o CCB Servelet do server do relatório CVP a fim determinar se há alguma fila específica onde o CCB não está oferecido. Abra um navegador da Web e datilografe-o.
http:// {IP de servidor Address}:8000/cvp/CallbackServlet?method=Diag do relatório
Este é um exemplo de uma fila onde o CCB seja oferecido:
Este é um exemplo de uma fila onde o CCB não seja oferecido
Etapa 7. Verifique se as filas são servidas por um gateway específico. Verifique a configuração de gateway (parâmetros de aplicativo do 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 está correta, verifique a informação armazenada na base de dados do servidor do relatório (Informix) para determinar o número de chama estes gateway e lugar específicos. Você pode verificar pela identificação CCB (10.201.198.21 neste caso) ou pelo locattion (CALO neste exemplo).
Etapa 9. No server do relatório, alcance o base de dados Informix.
Abra uma alerta do CMD e datilografe-a: dbacces
Navegue à conexão > conectam
Selecione o exemplo do cvp
datilografe o cvp_dbadmin username
datilografe a senha
selecione o base de dados de callback@cvp
retire e navegue aos idiomas de consulta
Etapa 10. Execute a pergunta:
Selecione a contagem (*) de callback_current onde o == “CALO” do lugar;
Etapa 11. Se o valor é o mesmo ou mais altamente do que o valor do tronco configurado no gateway para os lugar, esta é a razão pela qual o validatidation falha, desde que os números máximos de troncos permitidos foram alcançados na tabela de Callback_Current.
Note: Como provido no guia de relatório CVP, a tabela da rechamada é uma vista de duas tabelas: Callback_Current e Callback_Historical. As duas tabelas são idênticas. Cada 30 minutos, os dados para atendimentos terminados são puxados de Callback_Pending e movidos para Callback_Historical.
Etapa 12. Se o valor do tronco pelo lugar alcançou seus limites na tabela de Callback_Current e não há nenhuma rechamada na fila que este indica que há um problema em mover os registros da rechamada de Callback_Current para a tabela de Callback_Historical.
Etapa 13. Assegure-se de que CVPCallbackArchive esteja sendo executado sob as tarefas da programação (server do relatório CVP). Navegue ao iniciar > programas > acessórios - > ferramentas de sistema - > tarefa programada.
.
Etapa 14. Se esta tarefa CVPCallbackArchive termina assegure-se de que o código de saída esteja (0x0).
Etapa 15. Se etapa 13 e 14 é muito bem, mas ainda nenhuns dados na tabela de Callback_Historical, você precisará de determinar porque a informação não é adicionada no base de dados. Verifique a integridade da informação armazenada na corrente e na tabela de histórico. Execute esta pergunta na janela CMD dos dbaccess do informix:
Select count (*) from callback_current where surrogateid in (select surrogateid from callback_historical);
Etapa 16. Se a contagem é 1 ou mais alta, significa que o chave principal na tabela atual já existe na tabela de histórico e a informação não está adicionada no base de dados. Na maioria destas encenações, uma race condition faz com que os registros duplicados participem na tabela callback_current.
O GUID ao mapeamento do surrogateid acontece na tabela da fila. Nas situações aonde o atendimento se move da espera da rechamada para o script da fila da rechamada, parece haver um indicador onde o trabalho do arquivo mova os registros da corrente para a história e o aplicativo incorpore um novo registro à tabela atual com o mesmo surrogateid. Esta edição é relacionada a este CDETS CSCuq86400
Etapa 1. Alcance o base de dados Informix. Abra uma alerta do CMD e datilografe-a: dbacces
Etapa 2. Navegue à conexão > conectam o exemplo seleto do cvp. Datilografe o cvp_dbadmin username e datilografe a senha
Etapa 3. Selecione a saída do base de dados de callback@cvp e navegue aos idiomas de consulta
Etapa 4. Execute estes comandos:
supressão de callback_current onde surrogateid dentro (surrogateid seleto de callback_historical);
Se há um erro da tabela provisória faça:
deixe cair o T1 da tabela;
Etapa 5. Execute o procedimento sp que move a informação de atual para a tabela histórica da rechamada dos dbaccess do indicador do idioma de consulta.
EXECUTE o sp_arch_callback() do PROCEDIMENTO;
Etapa 6. Certifique-se de não haja tantos como registros na tabela atual como antes.
Selecione a contagem (*) de callback_current onde o == “CALO” do lugar;
Etapa 1. Navegue a Cisco \ CVP \ informix_frag e abra sp_arch_callback.sql em um editor de texto.
Etapa 2. Uncomment esta linha no início do arquivo: --sp_arch_callback do procedimento da gota; (remova -- no começo da linha).
Etapa 3. Adicionar esta linha: supressão de callback_current onde surrogated dentro (surrogateid seleto de callback_historical); em seguida
crie a linha do sp_arch_callback() do procedimento.
Etapa 4. Salvar o arquivo.
Etapa 5. Este é um exemplo em como o primeiro parte do arquivo deve olhar como.
{********************************************************************************* 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);
Etapa 1. Abra uma alerta do CMD e execute o comando: dbschema
dbschema - rechamada d - sp_arch_callback f
Note: Se você tem uma edição da autorização ao executar o comando do dbschema, o início de uma sessão como o cvp_dbadmin no server do relatório e a tentativa mais uma vez.
Etapa 2. Da saída, assegure-se de que a supressão do comando esteja executada.