Transferência AT&T Conecte o Customer Voice Portal (CVP) e o Intelligent Contact Management (ICM)

Introdução

Este documento descreve um problema encontrado ao usar o fluxo de chamadas abrangente CVP com o recurso de conexão de transferência de AT&T ( DTMF *8).

Pré-requisitos

Requisitos

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

• CVP versão 8.5
• Gerenciador Inteligente de Contatos (ICM)
• Serviços de conexão de transferência AT&T

Componentes Utilizados

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

• ICM 8.5
• CVP 8,5
• CUBE versão 151-3.T4
• Conexão de transferência AT&T

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

Se você efetuar uma chamada e ela for roteada para o Cisco Unified Contact Center Enterprise (UCCE) via CVP, a chamada será transferida de volta para um número externo na rede AT&T (serviço de conexões de transferência). Quando o problema ocorrer, você ouvirá os seguintes avisos da AT&T:

Aguarde

Sua chamada não pode ser concluída. Tente a chamada novamente

Descrição da Causa/Problema

Em um fluxo de chamada abrangente de CVP, uma chamada é recebida no CVP, o CVP recebe o rótulo DTM *8 seguido por 500 milissegundos (MS) em pausa e 1800 números. O CVP envia o DTMF para o Cisco Unified Border Element (CUBE) e o gateway envia os dígitos para a rede AT&T. No entanto, a chamada não será transferida e o cliente ouvirá Lamentamos que sua chamada não possa ser completada. Tente ligar novamente.

Etapa 1. O chamador faz uma chamada a partir da PSTN (Public Switched Telephone Network).

Etapa 2. O Gateway de Entrada (IGW) recebe a chamada do PSTN, nesse caso, o CUBE é o gateway de Entrada.

Etapa 3. O IGW envia uma mensagem SIP INVITE ao CVP por meio de um servidor proxy SIP.

Etapa 4. O CVP envia uma solicitação de Nova Chamada ao ICM.

Etapa 5. O ICM executa o script de roteamento e envia um rótulo VRU (Voice Response Unit) ao CVP.

Etapa 6. O CVP envia uma mensagem SIP INVITE através do servidor proxy SIP para o Voice XML Gateway (VXML GW).

Etapa 7. O VXML GW executa o script de bootstrap e envia uma solicitação HTTP ao CVP.

Etapa 8. O CVP envia uma Instrução de Solicitação ao ICM.

Etapa 9. O ICM cancela o trecho da URV e envia o rótulo DTMF ao CVP. O CVP encerra o segmento da URV com o GW VXML.

Etapa 10. O CVP envia o DTMF ao IGW (CUBE).

Etapa 11. A saída IGW (CUBE) envia o DTMF para a rede AT&T.

Etapa 12. A rede AT&T envia DTMF **7. A rede não recebeu ou não pode reconhecer o número discado. Para casos bons, o CVP envia DTMF **6 e o cliente ouve aguarde depois de Aguarde.

Verificar

Etapa 1. Configuração do CVP.

No arquivo sip.properties na pasta de configuração, o recurso SIP.ExternalTransferWait precisa ser adicionado e definido como 1000 (1 segundo). Depois disso, reinicie o servidor de chamadas do CVP.

Etapa 2. Registros do servidor de chamadas do CVP.

Colete rastreamentos CVP com Select com.dynamicsoft.DsLibs.DsUALibs definido para o nível Debug.

A partir dos registros do CVP, confirme se o CVP envia mensagens de informação SIP ao gateway de entrada (CUBE) para cada DTMF:

Por exemplo, o tom "*" enviado ao IGW (CUBE) 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. Coletar registros de gateway de entrada (CUBE).

debug ccsip message

debug voip rtp session name event

O relé DTMF negociado no trecho PSTN (AT&T) é RTP-NTE usando o tipo de payload 100.
O relé DTMF negociado no segmento CVP é sip-info e rtp-nte usando payload tipo 101.

A partir dos registros, pode-se ver que o gateway de entrada (CUBE) recebe todos os dígitos do CVP usando a mensagem de informações SIP e envia-a para o PSTN (AT&T)

Por exemplo, CUBE enviando dígito 7 para a 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. Colete a captura de pacotes no gateway e confirme os requisitos da AT&T.

Requisitos:

Tempo limite entre dígitos = 3 segundos

Para a sinalização DTMF para a rede, o VRU da Parte Redirecionadora (CVP neste caso e CUBE) deve enviar tons DTMF com pelo menos 80 ms de duração de dígitos e 80 ms de silêncio entre dígitos.

Uma pausa de pelo menos 350 ms deve ser aplicada entre o *T e o número de redirecionamento ou código SD. (Os limites inferior e superior são 300 ms - 11 seg.)

Análise de captura de pacotes

Nas boas chamadas, depois que o CUBE envia o último dígito para a AT&T, a AT&T envia o DTMF "* 6" em torno de 500 MS

Tempo entre os dígitos enviados para AT&T = 200 MS

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

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

Chamada incorreta:

A AT&T envia o DTMF **7, 6 segundos depois, depois de receber o último dígito

Tempo entre os dígitos enviados para AT&T = 200 MS

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

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

Não há diferença entre as chamadas boas e ruins na captura de pacotes.

Resolução

Como os DTMFs enviados à AT&T para chamadas boas e ruins têm as mesmas propriedades e temporizadores, mas em alguns cenários os DTMF não são reconhecidos, os testes são feitos adicionando pausas antes de um grupo específico de dígitos e a combinação que resolve o problema é :DTMF*8,,,,1,,,8YY,,,NXX,,,XXXX,,,". Isso é alterado no script do ICM.