AT&T transfere conecta o portal da Voz de cliente (CVP) e o Intelligent Contact Management (o ICM)

Introdução

Este original descreve um problema encontrado ao usar o CVP que o fluxo de chamadas detalhado com transferência conecta a característica de AT&T (DTMF *8).

Pré-requisitos

Requisitos

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

• Versão 8.5 CVP
• Gerente de contato inteligente (ICM)
• AT&T transfere conecta serviços

Componentes Utilizados

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

• ICM 8.5
• CVP 8.5
• Versão 151-3.T4 do CUBO
• AT&T transfere conecta

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.

Sintomas

Você coloca um atendimento e o atendimento é distribuído ao Cisco Unified Contact Center Enterprise (UCCE) através do CVP, o atendimento é transferido de volta a um número externo na rede de AT&T (transferência conecta o serviço). Quando o problema acontece você ouve estas alertas de AT&T:

Espere por favor

Nós somos pesarosos que seu atendimento não pode ser terminado. Tente por favor seu atendimento outra vez

Causa/descrição do problema

Em um fluxo de chamadas detalhado CVP, um atendimento é recebido no CVP, CVP recebe a etiqueta DTM *8 seguida em 500 milissegundos (MS) pausou e o número 1800. O CVP envia o DTMF ao Cisco Unified Border Element (CUBO) e o gateway para fora pulsa os dígitos à rede de AT&T. Contudo, o atendimento não é transferido e o cliente ouve-se nós somos pesarosos que seu atendimento não pode ser terminado. Tente por favor seu atendimento outra vez.

Etapa 1. O chamador coloca um atendimento do telefone comutado público Networ (PSTN).

Etapa 2. O gateway de ingresso (IGW) recebe o atendimento do PSTN, CUBA neste caso é o gateway de ingresso.

Etapa 3. O IGW envia um mensagem INVITE do SORVO ao CVP através de um servidor proxy server SIP.

Etapa 4. O CVP envia um pedido de chamada novo ao ICM.

Etapa 5. O ICM executa o script de roteamento e envia uma etiqueta do Voice Response Unit (VRU) ao CVP.

Etapa 6. O CVP envia um mensagem INVITE do SORVO através do servidor proxy server SIP ao gateway da Voz XML (VXML GW).

Etapa 7. O VXML GW executa o script da tira de bota e envia um pedido do HTTP ao CVP.

Etapa 8. O CVP envia uma instrução do pedido ao ICM.

Etapa 9. O ICM cancela o pé VRU e envia a etiqueta DTMF ao CVP. O CVP termina o pé VRU com o VXML GW.

Etapa 10. O CVP envia o DTMF a IGW (CUBO).

Etapa 11. O IGW (CUBO) pulsa para fora o DTMF à rede de AT&T.

Etapa 12. A rede de AT&T envia a rede DTMF **7 não recebeu nem não pode reconhecer o número discado. Para bons cenários de caso o CVP envia DTMF **6 e cliente ouve-se por favor para guardar depois que espere por favor.

Verificar

Etapa 1. Configuração CVP.

No arquivo sip.properties sob o dobrador da configuração a característica SIP.ExternalTransferWait precisa de ser adicionada e ajustado a 1000 (1 segundo). Após este reinício o server do atendimento CVP.

Etapa 2. Log de servidor do atendimento CVP.

Recolha traços CVP com o com.dynamicsoft.DsLibs.DsUALibs seleto ajustado ao nível de debug.

Do CVP os logs confirmam que o CVP envia mensagens de informação do SORVO ao gateway de ingresso (CUBO) para cada DTMF:

Por exemplo “*” o tom enviou a IGW (CUBO) do CVP.

264788: 10.1.1.1: Nov 25 2013 12:28:25.362 -0800: %CVP_8_5_SIP-7-CALL:  {Thrd=pool-1-thread-197-SIP-61173} 409D1D04-4D6B11E3-8E94E199-7280FCFD: Starting an external transfer with label: DTMF*8,,,,,18YYNXXXXXX
2059160: 10.1.1.1: Nov 25 2013 12:28:25.362 -0800: %_Connection-7-com.dynamicsoft.DsLibs.DsUALibs.DsSipLlApi.Connection:  Sending Message (NB): INFO sip:5123809981@10.1.2.2:5060 SIP/2.0
Via: SIP/2.0/TCP 10.1.1.1:5060;branch=z9hG4bKa74MS0n9A4oRWinVIAjXSA~~47394
Max-Forwards: 70
To: <sip:5123809981@10.1.2.2>;tag=658DC428-11DA
From: <sip:5008007435000@10.1.1.11>;tag=dsefb53fdb
Call-ID: 409D1D04-4D6B11E3-8E94E199-7280FCFD@10.1.2.2
CSeq: 1 INFO
Content-Length: 26
Contact: <sip:10.1.1.1:5060;transport=udp>
Content-Type: application/dtmf-relay
Signal=*    
Duration=100

Etapa 3. Recolha logs do gateway de ingresso (CUBO).

debugar o mensagem de ccsip

debugar o evento do nome de sessão do rtp do voip

O relé DMTF negociado no PSTN (o pé AT&T) é RTP-NTE usando o tipo de payload 100.
O relé DMTF negociado no pé CVP é sorvo-informação e RTP-NTE usando o tipo de payload 101.

Dos logs, pode-se ver que o gateway de ingresso (CUBO) recebe todos os dígitos do CVP usando o mensagem de informação do SORVO e envia-se o ao PSTN (AT&T)

Por exemplo CUBE a emissão do dígito 7 à rede PSTN/AT&T

289591: Nov 15 22:20:52.244:          s=DSP d=VoIP payload 0x64 ssrc 0x149A460E sequence 0xBD4 timestamp 0x2B700
289592: Nov 15 22:20:52.244:          Pt:100    Evt:7       Pkt:0A 00 00  <Snd>>>
289593: Nov 15 22:20:52.244:          s=DSP d=VoIP payload 0x64 ssrc 0x149A460E sequence 0xBD5 timestamp 0x2B700
289594: Nov 15 22:20:52.244:          Pt:100    Evt:7       Pkt:0A 00 00  <Snd>>>
289595: Nov 15 22:20:52.244:          s=DSP d=VoIP payload 0x64 ssrc 0x149A460E sequence 0xBD6 timestamp 0x2B700

Etapa 4. Recolha a captura de pacote de informação no gateway e confirme as exigências de AT&T.

Requisitos:

Tempo entre dígitos para fora = 3 segundos

Para a sinalização DTMF à rede, o VRU do partido de reorientação (CVP neste caso e CUBO) deve enviar toms DMTF com pelo menos o 80ms da duração de dígito e o 80ms do silêncio entre dígitos.

Uma pausa pelo menos de 350ms deve ser aplicada entre o *T e o número da reorientação ou o código SD. (O mais baixos e os limite superiores são 300ms - 11sec.)

Análise da captura de pacote de informação

Nos bons atendimentos, depois que o CUBO envia o dígito último a AT&T, AT&T envia o DTMF “* 6" ao redor 500 MS

O tempo entre dígitos enviou a AT&T = 200 MS

O tempo de DTMF *8 é enviado e o primeiro dígito = 400 MS

Duração do evento – Comprimento de dígito = 100 MS

Atendimento ruim:

AT&T envia o DTMF **7, 6 segundos depois em seguida que recebe o dígito último

O tempo entre dígitos enviou a AT&T = 200 MS

O tempo de DTMF *8 é enviado e o primeiro dígito = 400 MS

Duração do evento – Comprimento de dígito = 100 MS

Não há nenhuma diferença entre atendimentos os bons e do mau na captura de pacote de informação.

Resolução

Desde que os DTMF enviados a AT&T para os bons e atendimentos ruins têm as mesmos propriedades e temporizadores, mas em algumas encenações o DTMF não é reconhecido, os testes estão feitos que adicionam pausas antes que o grupo específico de dígitos e da combinação que resolve o problema esteja: . Isto é mudado no script ICM.