Troubleshooting de partida IVR-baseado do discador

Introdução

Este original descreve o discador de partida IVR-baseado e inclui uma configuração de gateway do SORVO da amostra, análises do log do gateway do SORVO e do motor do Cisco Unified Contact Center Express (UCCX), e as limitações do discador de partida IVR-baseado.

Em UCCX 8.5, um novo tipo de discador de partida foi introduzido: a resposta de voz interativa (IVR) - Discador de partida baseado. Ao contrário do discador de partida de uma estreia mais velha, nenhum agente é usado para fazer a chamada externa. UCCX conecta diretamente a um gateway do Session Initiation Protocol (SIP) na empresa do cliente para discar os contatos de partida. Quando o gateway detecta uma Voz ou uma secretária eletrônica viva, o atendimento está reorientado a um disparador UCCX limitado a um grupo de controle da chamada externa. Terminado uma vez na porta de partida da integração de telefonia e computador (CTI), o aplicativo associado com o disparador é executado como o normal.

Informação da característica

Em versões UCCX mais cedo de 8.5, somente o discador de partida da estreia existiram. Este discador usou o controle de chamada de terceiros através do Java Telephony Application Programming Interface (JTAPI) /CTI para instruir o telefone do agente para fazer o atendimento. O atendimento foi feito depois que um agente aceitou uma reserva de partida. A interação entre o cliente e servidor para reservas de partida era realizada através do CTI.

Use com certeza casos (tais como lembretes da nomeação e aplicativos de IVR do autosserviço), a estreia que o discador de partida não era um bom ajuste. Para fazer um atendimento a um número no DialingList, um agente foi amarrado acima de quando o atendimento foi colocado. Isso significou que o agente esteve ocupado para cada chamada externa, mesmo se o número comutado público da rede de telefonia (PSTN) era inválido, ocupado ou conduzido a uma secretária eletrônica. Este nível alto da utilização do agente era um inconveniente principal do discador de partida da estreia para estes casos do uso.

Fluxo IVR-baseado da chamada externa

Para os mesmos exemplos do uso (lembretes da nomeação e aplicativos de IVR do autosserviço) no discador de partida IVR-baseado, um agente pôde nunca ser envolvido no fluxo de chamadas. Este é o fluxo de chamadas para o discador de partida IVR-Basear:

1. O discador de partida IVR determina o número de contatos discar (como definido no algoritmo) e os usos SORVEM para colocar chamadas externas através do gateway de voz.
2. O gateway de voz detecta o contato NON-vivo com suas capacidades da análise do andamento da chamada (CPA) e envia o estado do contato NON-vivo ao discador. O discador atualiza a informação de status do contato na base de dados de configuração.
3. O gateway de voz detecta o contato vivo com suas capacidades CPA e envia o estado do contato vivo ao discador. O discador atualiza a informação de status do contato na base de dados de configuração e igualmente envia um SORVO refere à mensagem o gateway do SORVO, que, por sua vez, transfere o atendimento ao ponto de rota configurado CTI no gerente das comunicações unificadas de Cisco (CUCM).
4. O CUCM transfere o atendimento a uma porta IVR no server de Cisco UCCX.
5. O subsistema IVR associa o atendimento com o aplicativo de IVR associado com a campanha. O motor começa a execução do aplicativo e uma sessão IVR ocorre entre o aplicativo de IVR para a campanha em UCCX e o contato do cliente.

Tipos IVR-baseados do discador

Há dois tipos de discadores de partida IVR-Basear, com caráter de previsão e progressivo. Desde que UCCX transfere somente um atendimento a uma porta IVR para executar um script quando uma Voz viva (ou a secretária eletrônica configurável) são detectadas, é razoável supor que não cada contato de partida exige uma porta. A fim equilibrar a possibilidade que uma porta CTI está precisada contra a probabilidade que o Ring No Answer (RNA), situações ocupadas e do número inválido existe, os discadores com caráter de previsão e progressivos alteram o número de chamadas externas que são feitas em um momento contra o número de portas CTI de partida configuradas.

Um discador de partida IVR-baseado com caráter de previsão tem estas características:

• O número de linha para cada porta pode ser ajustado, com base na taxa de chamada do abandono.
• Nenhuma intervenção manual é precisada.
• O objetivo é discar bastante linhas para manter as portas IVR ocupadas mas para não exceder a máxima configurada da taxa de chamada do abandono.

Um discador de partida IVR-baseado progressivo tem estas características:

• Você pode especificar um número fixo de linhas que são discadas sempre para cada porta de partida disponível IVR.
• O número de linha pode ser atualizado em um outro dia.
• Se há três linhas para cada porta e o número dedicado de portas para de partida é três, a seguir nove atendimentos (3x3) estão discados.
• Uma chamada abandonada ocorre quando um cliente responde ao telefone, mas nenhuma porta está disponível para alertar o cliente.
• Você pode definir configurações padrão.

Componentes do discador com UCCX

Toda a funcionalidade e subsistemas internos são abstraídos para esclarecer este discador de partida IVR-baseado novo. Os componentes de sistema no discador novo, como a tabela do motor e do DialingList, são os mesmos que no discador de partida da estreia, com os Ramais (como mais valores do callStatus e do callResult) adicionados.

Informação dos recursos de gateway

A fim apoiar a detecção de Voz viva, a secretária eletrônica e os toms de informação especiais (SE SENTE), o gateway devem apoiar a característica CPA. Use o Cisco Feature Navigator a fim determinar as versões do ^{® do} Cisco IOS do gateway que discador do SORVO do apoio e CPA; use “busca a busca pela característica” para da “o apoio utilidade para o discador do SORVO e a análise do andamento da chamada.”

Como o CPA trabalha?

Há três funções principal no CPA:

• Detecção da secretária eletrônica (AMD)
• Fax/detecção de modem
• Secretária eletrônica que termina a detecção de tom

Há uns algoritmos complexos executados para fazer estas distinções, mas, de um ponto funcional do suporte:

• Uma resposta viva do partido é esperada ser uma saudação curto, então um período de silêncio.
  Exemplo: “Olá!” + silêncio
  Exemplo: “Olá!, residência de Johnson” + silêncio
• Uma secretária eletrônica é esperada ser uma saudação mais longa, então nenhum silêncio.
  Exemplo: “Você alcançou a residência do Miller, deixa por favor uma mensagem após o sinal acústico”
• Uma secretária eletrônica que termina o tom detecta é esperada ser detecção da secretária eletrônica, a seguir do silêncio, então um tom de terminação.
• Um fax detecta é reconhecimento do tom do fax.

A capacidade para fazer estas distinções pôde ser difícil, assim que você pôde precisar de ajustar parâmetros de temporização a fim aperfeiçoar a configuração.

Um outro fator a considerar é que os fornecedores do celular puderam lhes ter vários graus de atraso entre a apresentação de um atendimento, lugar da pilha, e apresentação do atendimento à pilha própria.

Isto é um exemplo do cálculo envolvido:

1. UCCX envia um SORVO convida ao gateway (o T1)
2. O gateway envia uma instalação de chamada ISDN ao provedor de serviços e no fornecedor da pilha (o T2)
3. O celular soa e começa seu temporizador da sem resposta (o T3)
4. O temporizador da pilha RNA expira e para a frente ao correio de voz (o T4)

Se você supõe que o temporizador RNA para a pilha é 15 segundos, a quantidade real de tempo onde tomaria para um atendimento a uma pilha para enviar ao correio de voz é (T1 + T2 + T3 + 15). O T1 + o T2 + o T3 poderiam ser significativamente mais altos do que a quantidade de tempo que toma para apresentar um atendimento a uma linha terrestre ou ao outro dispositivo da NON-pilha.

Assim, quando você define o limite de toque da sem resposta para uma campanha, o período de tempo precisa de ser por muito tempo bastante alcançar o sistema de correio de voz para celulares; este seria o comportamento desejado, por exemplo, para uma campanha pretendida deixar uma mensagem.

Note: O CPA é uma funcionalidade do gateway; ao contrário do Cisco Unified Contact Center Enterprise (UCCE), o CPA não pode ser girado de ligar/desligar em UCCX. Quando o CPA puder ser desligado no gateway, Cisco não recomenda este. Para mais informação, refira a vista geral de Analyis do andamento da chamada.

A seleção de códigos do Gateway de IOS é além do alcance deste original. O código do gateway deve apoiar o CPA e SORVER o discador para usar o discador de partida IVR-baseado. O Cisco Feature Navigator pode ajudá-lo a encontrar as versões do IOS que cumprem requisitos de recurso. Assegure-se de sempre que sua versão do IOS esteja compatível com todos os componentes que interagem com este gateway.

Troubleshooting

Note: Use a Command Lookup Tool ( somente clientes registrados) para obter mais informações sobre os comandos usados nesta seção.

A fim pesquisar defeitos um IVR de partida, determine se o gateway, o CUCM ou o UCCX são culpados. O Troubleshooting é mais fácil uma vez que você isola o problema a um componente específico. É útil recolher esta informação dos componentes de sistema

Para o gateway, execute estes comandos:

1. show tech
2. debugar mensagens de ccsip
3. debug voip ccapi inout
4. debugar o q931 de ISDN (ou similar debugar para capturar a sinalização do lado PSTN)
5. debugar o hpi todos do voip (para pesquisar defeitos o CPA)
6. debugar o vtsp todos do voip (para pesquisar defeitos o CPA)

Para UCCX, reveja arquivos de registro e configuração:

1. Arquivos de registro MIVR com eliminação de erros SS_OB e XDebug1 - XDebug3 permitido
2. Arquivos de registro do JTAPI (para pesquisar defeitos a falha de chamada consultada)
3. Configuração de gateway do SORVO do AppAdmin UCCX

Para o CUCM, configurações da revisão:

1. CallManager detalhado
2. CTIManager detalhado
3. A configuração de tronco do SORVO que aponta ao gateway usou-se para o IVR de partida

Análise de dados

O gateway do SORVO deve conter a configuração necessária para distribuir não somente pedidos de chamada de UCCX ao PSTN, mas para segurar igualmente transferência daqueles atendimentos ao disparador UCCX designado para de partida. Esta configuração de gateway do SORVO deve ter:

1. Dial peer de entrada para combinar pedidos entrantes do SORVO de UCCX.
2. Dial peer de saída (VoIP ou [POTS] velho do serviço de telefonia da planície) para distribuir atendimentos ao PSTN.
3. Dial peer de saída (VoIP) para distribuir o atendimento (consultado) reorientado ao conjunto CUCM que é integrado com UCCX.

O server CUCM deve ser configurado para receber pedidos de chamada de entrada do SORVO do gateway do SORVO (os atendimentos consultados) e para distribuir em conformidade os pedidos ao disparador UCCX e às portas CTI do grupo de Controle de chamadas UCCX.

Configuração de gateway do SORVO da amostra

Este é um exemplo de uma configuração de gateway do SORVO com notações. A conectividade de PSTN neste exemplo é a interface de taxa primária de ISDN (PRI).

Note: Outros tipos de conectividade de PSTN da multiplexação de divisão de tempo (TDM) são apoiados, mas o Cisco Unified Border Element (CUBO) não é apoiado. Veja o Bug da Cisco ID CSCui62525 e CSCuf44826 para obter mais informações sobre do apoio do CUBO. As conexões múltiplas ao TDM PSTN são apoiadas para distribuir classes diferentes de atendimentos (local, longa distância, internacionais) aos troncos ou aos fornecedores diferentes.

RyanIVRRouter#show run
Building configuration...

Controlador T1 configurado para ISDN PRI

!
controller T1 0/0/0
 cablelength long 0db
 pri-group timeslots 1-24
!

Interface serial configurada para ISDN PRI

!
interface Serial0/0/0:23
 no ip address
 encapsulation hdlc
 isdn switch-type primary-ni
 isdn incoming-voice voice
 no cdp enable
!

Porta de voz para distribuir chamadas externas ao PSTN

!
voice-port 0/0/0:23
!

Voip dial peer de entrada

Pedidos de chamada entrantes deste SORVO das correspondências de dial peer de UCCX. Se um voip dial peer de entrada não é configurado, o dial peer padrão (dial-peer 0) está combinado. É melhor prática definir e combinar um voip dial peer de entrada. Este dial-peer notifica o gateway do relé do codec, do protocolo e do Dual-Tone Multifrequency (DTMF) a ser usado no pé de entrada do SORVO de UCCX.

Este as correspondências de dial peer todas SORVO de entrada convidam com um Digital Number Identification Service (DNIS) esse começo com 717 e aquele é os dígitos 10 por muito tempo. Neste exemplo, todos os contatos discados por UCCX estão no código de área 717 e têm dígitos dos números de telefone 10 por muito tempo.

!
dial-peer voice 100 voip
 description -- Outbound Calls From UCCX -- 
 session protocol sipv2
 incoming called-number 717.......
 dtmf-relay rtp-nte
 codec g711ulaw
!

POTS dial peer

Este dial-peer distribui atendimentos ao PSTN sobre o PRI configurado previamente. É o dial peer de saída para os pedidos de chamada que vêm de UCCX e o dial peer de saída para o VoIP dial-peer 100 acima. Este dial-peer igualmente serve como um dial peer de entrada para os atendimentos que vêm do PSTN para propósitos de teste. No fluxo de chamadas de partida do discador UCCX, este dial-peer não é combinado como um dial peer de entrada.

!
dial-peer voice 10 pots
 description -- POTS Dial Peer To/From PSTN Simulator --
 destination-pattern 717.......
 incoming called-number .
 direct-inward-dial
 port 0/0/0:23
 forward-digits all
!

Voip dial peer de saída

Este dial-peer serve como o dial peer de saída necessário pelo gateway do SORVO distribuir atendimentos ao conjunto CUCM destinado para o disparador UCCX. Este dial-peer é usado pelo gateway para distribuir REFER enviado por UCCX quando vivo exprime (ou secretária eletrônica se a configuração existe) é detectado. Este dial-peer define o protocolo, o relé DMTF, o codec e o endereço IP de Um ou Mais Servidores Cisco ICM NT do nó CUCM onde o gateway do SORVO deve distribuir o atendimento reorientado. Para fins da Redundância e do Balanceamento de carga, os dial peer múltiplos deste tipo puderam existir. Poderiam ser divididos às solicitações de rota aos Nós múltiplos CUCM no conjunto ou ser fornecida distribuir reorienta com certeza disparadores aos Nós diferentes CUCM.

Neste exemplo, os disparadores UCCX para campanhas de partida IVR-Basear são 2001 e 2002.

!
dial-peer voice 102 voip
 description -- Redirect Calls to UCCX 90 --
 destination-pattern 200[1-2]
 session protocol sipv2
 session target ipv4:14.10.166.15
 incoming called-number 200[1-2]
 dtmf-relay rtp-nte
 codec g711ulaw
!

A amostra IVR-baseou a análise de traço da chamada externa

Esta é uma análise detalhada de um log da Mensagem do exemplo entre o gateway do SORVO, UCCX e o PSTN.

A inicial CONVIDA de UCCX instrui o gateway para fazer um atendimento ao número PSTN. O CONVITE contém a identidade da chamada, que pode ser usada para seguir todas as mensagens associadas com este atendimento, e o protocolo session description (SDP) (parâmetros dos media).

Mais importante, o CONVITE inclui os parâmetros que o gateway deve se usar para terminar o CPA. Estes parâmetros são configurados nas páginas appadmin UCCX, mas não usados por UCCX. Um pouco, são enviados no CONVITE ao gateway e usados pelo gateway para configurar os processadores do sinal digital (DSP) para o CPA para este atendimento. Em consequência, estes parâmetros são enviados ao gateway no por chamada e podem ser mudados a qualquer hora do AppAdmin.

UCCX envia estes atributos de configuração CPA ao gateway para cada atendimento:

Os valores configurável são apresentados no AppAdmin na página da configuração de gateway do SORVO.

Received: 
INVITE sip:7175551212@14.10.153.56:5060;transport=udp SIP/2.0
...
Call-ID: 134401919546410@14.10.166.16
...
Content-Type: multipart/mixed;boundary=unique_boundary

--unique_boundary
Content-Type: application/sdp
Content-Disposition: session;handling=required

v=0
o=Cisco-UCCX 1608 1 IN IP4 14.10.166.16
s=SIP Call
c=IN IP4 0.0.0.0
t=0 0
m=audio 12345 RTP/AVP 0 
a=rtpmap:0 PCMU/8000
a=ptime:20
--unique_boundary
Content-Type: application/x-cisco-cpa
Content-Disposition: signal;handling=optional

Events=FT,Asm,AsmT,Sit
CPAMinSilencePeriod=375
CPAAnalysisPeriod=2500
CPAMaxTimeAnalysis=3000
CPAMinValidSpeechTime=112
CPAMaxTermToneAnalysis=15000
--unique_boundary--

Enquanto o atendimento está processando com o dial peers do gateway, UCCX é enviado a uma mensagem '100 Trying.

Sent: 
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 14.10.166.16:5065;branch=z9hG4bKEsF4FAHPTVliP0ozE1BcOQ~~17
From: <sip:9195551212@14.10.166.16>;tag=dsa994554a
To: <sip:7175551212@14.10.153.56>
Date: Fri, 03 Aug 2012 18:38:46 GMT
Call-ID: 134401919546410@14.10.166.16
CSeq: 100 INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-12.x
Content-Length: 0

Quando a chamada externa combina um dial peer de saída, está enviada ao PSTN usando o protocolo configurado TDM. Neste caso, um PRI é usado:

Aug  3 18:38:46.559: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8  callref = 0x008D 
	Bearer Capability i = 0x8090A2 
		Standard = CCITT 
		Transfer Capability = Speech  
		Transfer Mode = Circuit 
		Transfer Rate = 64 kbit/s 
	Channel ID i = 0xA98397 
		Exclusive, Channel 23 
	Calling Party Number i = 0x2180, '9195551212' 
		Plan:ISDN, Type:National
 	Called Party Number i = 0xA1, '7175551212' 
		Plan:ISDN, Type:National

Os andamentos da chamada e a sinalização são trocados entre o PSTN e o gateway. O gateway é notificado que o telefone PSTN está soando com a mensagem de ALERTA.

Aug  3 18:38:46.595: ISDN Se0/0/0:23 Q931: RX <- CALL_PROC pd = 8  callref = 0x808D 
	Channel ID i = 0xA98397 
		Exclusive, Channel 23

Aug  3 18:38:46.603: ISDN Se0/0/0:23 Q931: RX <- ALERTING pd = 8  callref = 0x808D 
    Progress Ind i = 0x8188 - In-band info or appropriate now available

O gateway envia um progresso de 183 sessões de volta a UCCX para notificar UCCX que o telefone PSTN está soando. Isto inclui o SDP para a negociação de mídia dos toms de chamada de volta.

Sent: 
SIP/2.0 183 Session Progress
...
Call-ID: 134401919546410@14.10.166.16
...
--uniqueBoundary
Content-Type: application/sdp
Content-Disposition: session;handling=required

v=0
o=CiscoSystemsSIP-GW-UserAgent 7343 9805 IN IP4 14.10.153.56
s=SIP Call
c=IN IP4 14.10.153.56
t=0 0
m=audio 32330 RTP/AVP 0 101 19
c=IN IP4 14.10.153.56
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=rtpmap:19 CN/8000
a=ptime:20
...
--uniqueBoundary
Content-Type: application/x-cisco-cpa
Content-Disposition: signal;handling=optional

event=enabled
--uniqueBoundary--

O atendimento é conectado no pé TDM como o telefone PSTN respondeu ao atendimento. O gateway envia uma confirmação no CONNECT_ACK.

Aug  3 18:38:49.207: ISDN Se0/0/0:23 Q931: RX <- CONNECT pd = 8  callref = 0x808D

Aug  3 18:38:49.211: ISDN Se0/0/0:23 Q931: TX -> CONNECT_ACK pd = 8  callref = 0x008D

O gateway notifica UCCX que o atendimento está conectado com uma APROVAÇÃO 200. UCCX ACK isto, segundo as exigências do SORVO RFC. A APROVAÇÃO 200 igualmente contém o SDP para a negociação de mídia, mas não é usada por UCCX.

Sent: 
SIP/2.0 200 OK
...
Call-ID: 134401919546410@14.10.166.16
...
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 271

v=0
o=CiscoSystemsSIP-GW-UserAgent 7343 9805 IN IP4 14.10.153.56
s=SIP Call
c=IN IP4 14.10.153.56
t=0 0
m=audio 32330 RTP/AVP 0 101 19
c=IN IP4 14.10.153.56
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=rtpmap:19 CN/8000
a=ptime:20

Received: 
ACK sip:7175551212@14.10.153.56:5060 SIP/2.0
...
Call-ID: 134401919546410@14.10.166.16
...

O gateway detecta o andamento da chamada com CPA e notifica UCCX do andamento da chamada com uma série de mensagens de atualização. UCCS ACK isto, segundo as exigências do SORVO RFC.

Neste exemplo de uma atualização do SORVO, o evento “é detectado” e o estado é “CpaS”.

• CpaS indica que o CPA começou.
• Quando uma secretária eletrônica é detectada, o estado é “ASM.”
• Quando o tom da secretária eletrônica é qualificado, o estado é “AsmT.”

Esta tabela alista os códigos de status x-Cisco-CPA usados nos mensagens de atualização do SORVO:

Sent: 
UPDATE sip:9195551212@14.10.166.16:5065;transport=udp SIP/2.0
...
Call-ID: 134401919546410@14.10.166.16
...
Content-Type: application/x-cisco-cpa
Content-Disposition: signal;handling=optional
Content-Length: 26

event=detected
status=CpaS

Received: 
SIP/2.0 200 Ok
...
Call-ID: 134401919546410@14.10.166.16
...

UCCX envia uma notificação ao gateway para reorientar o atendimento ao disparador atribuído a esta campanha de partida. O gateway ACK isto.

Received: 
REFER sip:7175551212@14.10.153.56:5060 SIP/2.0
...
Call-ID: 134401919546410@14.10.166.16
...
Refer-To: <sip:2001@14.10.153.56>
...

Sent: 
SIP/2.0 202 Accepted
...
Call-ID: 134401919546410@14.10.166.16
...

O gateway deve distribuir este atendimento ao destino novo como todo o processamento de chamada normal com o dial peers no gateway.

Aug  3 18:39:07.275: //60/7120520F060E/CCAPI/ccCallSetupRequest:
   Destination=, Calling IE Present=FALSE, Mode=0,
   Outgoing Dial-peer=102, Params=0x31BDB494, Progress Indication=NULL(0)

O atendimento é distribuído pelo gateway baseado na configuração no dial peer de saída combinado para o destino contido dentro CONSULTAR.

Sent: 
INVITE sip:2001@14.10.166.15:5060 SIP/2.0
...
Call-ID: 5789DBCB-DCD111E1-8081ADFE-F735B3DC@14.10.153.56
...
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 270

v=0
o=CiscoSystemsSIP-GW-UserAgent 5187 301 IN IP4 14.10.153.56
s=SIP Call
c=IN IP4 14.10.153.56
t=0 0
m=audio 25002 RTP/AVP 0 101 19
c=IN IP4 14.10.153.56
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=rtpmap:19 CN/8000
a=ptime:20

Análise do log da amostra MIVR

Estes snippet de um log MIVR fornecem uma vista geral do atendimento de uma perspectiva UCCX. Permita estes níveis de debug de capturar a informação correta:

• SS_OB - Debug,XD1,XD2,XD3
• SS_RM - Debug,XDebug1
• CFG_MGR - Debug,XDebug1 (se a edição é com discar registros da lista)
  

135533948: Aug 20 21:34:54.631 EDT %MIVR-CFG_MGR-7-UNK:ConfigManagerImpl-getAll():CIR
[0]=ConfigImportRecord[schema=DialingListConfig#2,time=2012-08-20 21:34:42.0,
recordId=239,implClass=class com.cisco.crs.outbound.DialingListConfig,desc=,
values=[239, 2, 1662760, NAME, TEST777, 9785551212, , , 343, true, -1, true, -1, true, , 
2012-08-20 21:34:42.0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, null, null, null, null],evalues=null]
//Import the record from the dialing list. In this case, the recordID=239


135533949: Aug 20 21:34:54.632 EDT %MIVR-CFG_MGR-7-UNK:ConfigManagerImpl-getAll():con
figObjs[0]=DialingListConfig[schema=DialingListConfig#2,time=2012-08-20 21:34:42.0,
recordId=239,desc=,recordID=0,dialingListID=239,campaignID=2,accountNumber=1662760,
firstName=NAME,lastName=TEST777,phone01=9785551212,phone02=,phone03=,gmtZonePhone01=343,
dstPhone01=true,gmtZonePhone02=-1,dstPhone02=true,gmtZonePhone03=-1,dstPhone03=true,
callbackNumber=,callbackDateTime=2012-08-20 21:34:42.0,callStatus=1,callResult=0,
callResult01=0,callResult02=0,callResult03=0,lastNumberDialed=0,callsMadeToPhone01=0,
callsMadeToPhone02=0,callsMadeToPhone03=0,numMissedCallback=0,isRetries=false]
//RecordID=239; campaignID=2

Note: Desde que pôde haver umas campanhas múltiplas ao mesmo tempo, é importante pagar a atenção ao campaignID e ao recordID.

B-7-UNK:CMgrUtil: getPhoneNumber: callStatus=2callResult=0lastNumDialed=0

135534103: Aug 20 21:34:55.424 EDT %MIVR-SS_OB-7-UNK:CMgrUtil: getPhoneNumber: 
   callStatus=2callResult=0lastNumDialed=0
135534104: Aug 20 21:34:55.424 EDT %MIVR-SS_OB-7-UNK:CMgrUtil: getUnformattedPhoneNumber: 
   dlcID:239
135534105: Aug 20 21:34:55.425 EDT %MIVR-SS_OB-7-UNK:CMgrUtil: getFormattedPhoneNumber: 
   phoneNum=9785551212
135534106: Aug 20 21:34:55.425 EDT %MIVR-SS_OB-7-UNK:CMgrUtil: getFormattedPhoneNumber: 
   intPrefix= localAreaCode = 416 lenAreaCode = 3 include lac = true dialingPrefix = 9 
   longDistPrefix = 91
135534107: Aug 20 21:34:55.425 EDT %MIVR-SS_OB-7-UNK:CMgrUtil.getFormattedPhoneNumber(): 
   domestic number
135534108: Aug 20 21:34:55.425 EDT %MIVR-SS_OB-7-UNK:CMgrUtil.getFormattedPhoneNumber(): 
   long distance number
135534109: Aug 20 21:34:55.425 EDT %MIVR-SS_OB-7-UNK:numToDial=9919785551212
135534110: Aug 20 21:34:55.425 EDT %MIVR-SS_OB-7-UNK:CMgrUtil: getUnformattedPhoneNumber: 
   dlcID:239
135534111: Aug 20 21:34:55.425 EDT %MIVR-SS_OB-7-UNK:CMgrUtil.getTimeZoneId - 
   phoneNum=9785551212
135534112: Aug 20 21:34:55.425 EDT %MIVR-SS_OB-7-UNK:CMgrUtil: getGmtOffset: 
   DST observed=true
135534113: Aug 20 21:34:55.425 EDT %MIVR-SS_OB-7-UNK:CMgrUtil.getTimeZoneId - 
   phoneNum=9785551212

//Based on the Campaign config, the phone number is modified accordingly. In a failed call 
scenario, you might want to verify what the number is after the formatting is done. Look 
for 'MIVR-SS_OB-7-UNK:numToDial=' which gives you the actual number to be dialed.

135534128: Aug 20 21:34:55.425 EDT %MIVR-SS_OB-7-UNK:OutboundIVRContactsRequestor: 
Contacts returned from CampaignMgr for campaignID:2 are [OutboundContactInfo: dlc:239 
(phoneNumber:9919785551212 unformattedPhoneNumber:9785551212 timezone -240 
callStartTime 0 answeringMachine false ) ]
//phoneNumber:9919785551212; unformattedPhoneNumber:9785551212. 

Estão aqui os phoneNumbers formatados e sem formatação:

135534131: Aug 20 21:34:55.425 EDT %MIVR-SS_OB-7-UNK:IVRDialer:findValidContact() - 
processing contact in queue OutboundContactInfo: dlc:239 (phoneNumber:9919785551212 
unformattedPhoneNumber:9785551212 timezone -240 callStartTime 0 answeringMachine false )

O SORVO que sinaliza começos:

SIP-9919785551212  INVITE sip:9919785551212@10.10.10.7:5060;transport=udp SIP/2.0

SIP-9919785551212  SIP/2.0 100 Trying

SIP-9919785551212  SIP/2.0 183 Session Progress

SIP-9919785551212  SIP/2.0 200 OK

Verifique a manipulação destas mensagens no gateway com a Mensagem do gateway explicada previamente.

135534720: Aug 20 21:34:58.809 EDT %MIVR-SS_OB-7-UNK:ProcessAccepted: DialerSipCall-68, 
State=CONTACTING, fromDN=8005553434, toDN=9919785551212, 
callId=134551289542668@10.10.10.5 sending
 
SIP-9919785551212  ACK sip:9919785551212@10.10.10.7:5060 SIP/2.0

135534722: Aug 20 21:34:58.810 EDT %MIVR-SS_OB-7-UNK:OnConnectionCompleted DialerSipCall-68,
State=ACTIVE, fromDN=8005553434, toDN=9919785551212, callId=134551289542668@10.10.10.5 
notify 
com.cisco.wf.subsystems.outbound.SIPAdapterCallListenerImpl@1b91fa4.onConnectionCompleted()
//The initial SIP signalling is completed

135534723: Aug 20 21:34:58.810 EDT %MIVR-SS_OB-7-UNK:SIPAdapterCallListenerImpl.
onConnectionCompleted post OutboundPlaceGWCallRespMsg: GWCall:  dlcID: 239, csqID: -1, 
contactNumToDial:9919785551212false, dialerType:IVR_DIALER, DialerSipCall-68, State=ACTIVE, 
fromDN=8005553434, toDN=9919785551212, callId=134551289542668@10.10.10.5, status=OK
//The outbound subsystem posts the 'Place call' request to the gateway

135534724: Aug 20 21:34:58.810 EDT %MIVR-SS_OB-7-UNK:OutboundDialerProcessor:Processing msg: 
OutboundPlaceGWCallRespMsg: GWCall:  dlcID: 239, csqID: -1, 
contactNumToDial:9919785551212false, dialerType:IVR_DIALER, DialerSipCall-68, State=ACTIVE, 
fromDN=8005553434, toDN=9919785551212, callId=134551289542668@10.10.10.5, 
status=OK135534725: Aug 20 21:34:58.810 EDT 
%MIVR-SS_OB-7-UNK:IVRDialer:ProcessOutboundPlaceGWCallRespMsg: 
OutboundPlaceGWCallRespMsg: GWCall:  dlcID: 239, csqID: -1, 
contactNumToDial:9919785551212false, dialerType:IVR_DIALER, 
DialerSipCall-68, State=ACTIVE, fromDN=8005553434, toDN=9919785551212, 
callId=134551289542668@10.10.10.5, status=OK
//The OutboundPlaceCall request is processed by the Outbound Dialer, then by the IVR 
Dialer processes
135534728: Aug 20 21:34:58.810 EDT %MIVR-SS_OB-7-UNK:CampaignStatistics:
incrementAttemptedCalls() for phoneNumber=9919785551212 to 1
135534729: Aug 20 21:34:58.810 EDT %MIVR-SS_OB-7-UNK:HalfHourCampaignData:
incrementAttemptedCalls() by 1. Total attempted calls = 1
//Since this is the first time the record is dialled out, the total attempted calls = 1

O gateway envia um mensagem de atualização do SORVO junto com a mensagem CPA. O software CPA é executado no gateway e analisa o Real-Time Transport Protocol (RTP) do número chamado. Isto ajuda a diferenciar-se entre a Voz e a secretária eletrônica na extremidade do número chamado. Você pode identificar um mensagem de atualização do SORVO CPA por seu tipo de conteúdo de “application/x-cisco-cpa”.

SIP-9919785551212  UPDATE sip:8005553434@10.10.10.5:5060;transport=udp SIP/2.0
SIP-9919785551212  Via: SIP/2.0/UDP 10.10.10.7:5060;branch=z9hG4bK2362542
SIP-9919785551212  Max-Forwards: 69
SIP-9919785551212  To: <sip:8005553434@10.10.10.5>;tag=dsaf56bbcc
SIP-9919785551212  From: <sip:9919785551212@10.10.10.7>;tag=3D33950C-948
SIP-9919785551212  Call-ID: 134551289542668@10.10.10.5
SIP-9919785551212  CSeq: 102 UPDATE
SIP-9919785551212  Content-Length: 26
SIP-9919785551212  Date: Tue, 21 Aug 2012 01:34:58 GMT
SIP-9919785551212  User-Agent: Cisco-SIPGateway/IOS-15.2.4.M1
SIP-9919785551212  Supported: timer,resource-priority,replaces,sdp-anat
SIP-9919785551212  Timestamp: 1345512899
SIP-9919785551212  Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
    NOTIFY, INFO, REGISTER
SIP-9919785551212  Contact: <sip:9919785551212@10.10.10.7:5060>
SIP-9919785551212  Min-SE: 1800
SIP-9919785551212  Content-Type: application/x-cisco-cpa
SIP-9919785551212  Content-Disposition: signal;handling=optional
SIP-9919785551212  
SIP-9919785551212  event=detected
SIP-9919785551212  status=CpaS

SIP-9919785551212  UPDATE sip:8005553434@10.10.10.5:5060;transport=udp SIP/2.0
SIP-9919785551212  Via: SIP/2.0/UDP 10.10.10.7:5060;branch=z9hG4bK23714F6
SIP-9919785551212  Max-Forwards: 69
SIP-9919785551212  To: <sip:8005553434@10.10.10.5>;tag=dsaf56bbcc
SIP-9919785551212  From: <sip:9919785551212@10.10.10.7>;tag=3D33950C-948
SIP-9919785551212  Call-ID: 134551289542668@10.10.10.5
SIP-9919785551212  CSeq: 103 UPDATE
SIP-9919785551212  Content-Length: 163
SIP-9919785551212  Date: Tue, 21 Aug 2012 01:34:58 GMT
SIP-9919785551212  User-Agent: Cisco-SIPGateway/IOS-15.2.4.M1
SIP-9919785551212  Supported: timer,resource-priority,replaces,sdp-anat
SIP-9919785551212  Timestamp: 1345512902
SIP-9919785551212  Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
    NOTIFY, INFO, REGISTER
SIP-9919785551212  Contact: <sip:9919785551212@10.10.10.7:5060>
SIP-9919785551212  Min-SE: 1800
SIP-9919785551212  Content-Type: application/x-cisco-cpa
SIP-9919785551212  Content-Disposition: signal;handling=optional
SIP-9919785551212  
SIP-9919785551212  event=detected
SIP-9919785551212  status=LV
SIP-9919785551212  pickupT=320
SIP-9919785551212  maxActGlitchT=0
SIP-9919785551212  numActGlitch=0
SIP-9919785551212  valSpeechT=20
SIP-9919785551212  maxPSSGlitchT=0
SIP-9919785551212  numPSSGlitch=0
SIP-9919785551212  silenceP=0
SIP-9919785551212  termToneDetT=0
SIP-9919785551212  noiseTH=1000
SIP-9919785551212  actTh=32000

//This shows that Low Volume is detected. Now, based on the Campaign setting 'Handle Low 
Volume as Voice,' this call is handled accordingly

135535726: Aug 20 21:35:02.036 EDT %MIVR-SS_OB-7-UNK:OnCPAStatus DialerSipCall-68, 
State=ACTIVE, fromDN=8005553434, toDN=9919785551212, callId=134551289542668@10.10.10.5 
notify com.cisco.wf.subsystems.outbound.SIPAdapterCallListenerImpl@1b91fa4.onCPAStatus
(status=LowVolume)
135535727: Aug 20 21:35:02.036 EDT %MIVR-SS_OB-7-UNK:SIPAdapterCallListenerImpl.onCPAStatus 
post OutboundUpdateGWCallStatusMsg: GWCall:  dlcID: 239, csqID: -1, 
contactNumToDial:9919785551212false, dialerType:IVR_DIALER, DialerSipCall-68, State=ACTIVE, 
fromDN=8005553434, toDN=9919785551212, callId=134551289542668@10.10.10.5, status=LowVolume
135535728: Aug 20 21:35:02.036 EDT %MIVR-SS_OB-7-UNK:OutboundDialerProcessor:Processing msg: 
OutboundUpdateGWCallStatusMsg: GWCall:  dlcID: 239, csqID: -1, 
contactNumToDial:9919785551212false, dialerType:IVR_DIALER, DialerSipCall-68, State=ACTIVE, 
fromDN=8005553434, toDN=9919785551212, callId=134551289542668@10.10.10.5, status=LowVolume
135535729: Aug 20 21:35:02.036 EDT %MIVR-SS_OB-7-UNK:IVRDialer:
ProcessOutboundUpdateGWCallStatusMsg: OutboundUpdateGWCallStatusMsg: GWCall:  dlcID: 239, 
csqID: -1, contactNumToDial:9919785551212false, dialerType:IVR_DIALER, DialerSipCall-68, 
State=ACTIVE, fromDN=8005553434, toDN=9919785551212, callId=134551289542668@10.10.10.5, 
status=LowVolume
135535730: Aug 20 21:35:02.036 EDT %MIVR-SS_OB-7-UNK:IVRDialer:
ProcessOutboundUpdateGWCallStatusMsg(): Low Volume detected
135535731: Aug 20 21:35:02.036 EDT %MIVR-SS_OB-7-UNK:IVRDialer:
ProcessOutboundUpdateGWCallStatusMsg(): Handle Low Volume as Voice is true
135535732: Aug 20 21:35:02.036 EDT %MIVR-SS_OB-7-UNK:IVRDialer:
ProcessOutboundUpdateGWCallStatusMsg(): PostingOutboundIVRUpdateContactMsg with 
callstatus = 3(Closed), callresult = 1(Low Volume) for dlcID = 239

Problemas comuns

Nenhum CPA é enviado do gateway a UCCX

Depois que o atendimento é conectado com o chamador de PSTN, nenhuma mensagem está enviada para trás a UCCX pelo gateway para indicar que o CPA esteve terminado e que um atendimento resultou (vivem a Voz, ocupados, secretária eletrônica, e assim por diante). Certifique-se da Versão do IOS nos suportes de gateway CPA. Investigue o gateway para verificar que o CPA se está operando corretamente.

O atendimento não é reorientado a UCCX depois que vivo exprime detectado

Verifique que o gateway tem um dial-peer que combina o número discado do disparador UCCX (DN) atribuído à campanha. Verifique que um atendimento do gateway pode distribuir a esse ponto de rota CTI/disparador em CUCM.

O Retries não é discado

Similar às rechamadas no discador de partida da estreia, se os atendimentos que recebem o RNA ou ocupado não são experimentados de novo, verifique que estes registros estão marcados corretamente como a nova tentativa na tabela de DialingList. Verifique dos logs MIVR que a tentativa de chamada está sendo feita no tempo especificado da rechamada ou da nova tentativa.

O DTMF não trabalha quando conectado ao script IVR

Verifique que o DTMF está negociado corretamente entre CUCM e o gateway e que o dial peers Nomeado está combinado (o dial-peer 0 não contém a configuração do relé DMTF). UCCX apoia somente o DTMF fora da banda através do JTAPI, assim que alguns tipos de gateway e fluxos de chamadas puderam exigir um Media Termination Point (MTP) ser invocado para terminar o DTMF que colabora. Investigue o gateway para verificar que o gateway e os CUCM estão processando corretamente pedidos e negociação DTMF.

Informações Relacionadas

• Suporte Técnico e Documentação - Cisco Systems