IVR 기반 아웃바운드 다이얼러 문제 해결

다운로드 옵션

PDF (356.1 KB)
다양한 디바이스에서 Adobe Reader로 보기
ePub (259.0 KB)
iPhone, iPad, Android, Sony Reader 또는 Windows Phone의 다양한 앱에서 보기
Mobi (Kindle) (177.9 KB)
Kindle 디바이스에서 보기 또는 다양한 디바이스의 Kindle 앱에서 보기

업데이트:2013년 9월 24일

문서 ID:116084

편견 없는 언어

본 제품에 대한 문서 세트는 편견 없는 언어를 사용하기 위해 노력합니다. 본 설명서 세트의 목적상, 편견 없는 언어는 나이, 장애, 성별, 인종 정체성, 민족 정체성, 성적 지향성, 사회 경제적 지위 및 교차성에 기초한 차별을 의미하지 않는 언어로 정의됩니다. 제품 소프트웨어의 사용자 인터페이스에서 하드코딩된 언어, RFP 설명서에 기초한 언어 또는 참조된 서드파티 제품에서 사용하는 언어로 인해 설명서에 예외가 있을 수 있습니다. 시스코에서 어떤 방식으로 포용적인 언어를 사용하고 있는지 자세히 알아보세요.

이 번역에 관하여

Cisco는 전 세계 사용자에게 다양한 언어로 지원 콘텐츠를 제공하기 위해 기계 번역 기술과 수작업 번역을 병행하여 이 문서를 번역했습니다. 아무리 품질이 높은 기계 번역이라도 전문 번역가의 번역 결과물만큼 정확하지는 않습니다. Cisco Systems, Inc.는 이 같은 번역에 대해 어떠한 책임도 지지 않으며 항상 원본 영문 문서(링크 제공됨)를 참조할 것을 권장합니다.

소개

이 문서에서는 IVR 기반 아웃바운드 다이얼러에 대해 설명하고 샘플 SIP 게이트웨이 구성, SIP 게이트웨이 및 Cisco UCCX(Unified Contact Center Express) 엔진의 로그 분석, IVR 기반 아웃바운드 다이얼러의 제한 사항을 다룹니다.

UCCX 8.5에서는 새로운 유형의 아웃바운드 다이얼러가 도입되었습니다.IVR(Interactive Voice Response) 기반 아웃바운드 다이얼러.이전 미리보기 아웃바운드 다이얼러와 달리 아웃바운드 통화를 수행하는 데 사용되는 에이전트는 없습니다.UCCX는 고객 엔터프라이즈의 SIP(Session Initiation Protocol) 게이트웨이에 직접 연결하여 아웃바운드 연락처에 전화를 겁니다.게이트웨이가 라이브 음성 또는 자동 응답기를 탐지하면 통화가 아웃바운드 통화 제어 그룹에 바인딩된 UCCX 트리거로 리디렉션됩니다.아웃바운드 CTI(computer telephony integration) 포트에서 종료되면 트리거와 연결된 애플리케이션이 정상적으로 실행됩니다.

기능 정보

8.5 이전 UCCX 버전에서는 Preview Outbound Dialer만 있었습니다.이 다이얼러는 JTAPI(Java Telephony Application Programming Interface)/CTI를 통해 서드파티 통화 제어를 사용하여 상담원의 전화기에 전화를 걸도록 지시했습니다.상담원이 아웃바운드 예약을 수락한 후에 통화가 이루어졌습니다.아웃바운드 예약에 대한 클라이언트와 서버 간의 상호 작용은 CTI를 통해 이루어졌습니다.

특정 활용 사례(예: 약속 미리 알림 및 셀프 서비스 IVR 애플리케이션)의 경우 아웃바운드 미리 보기 다이얼러가 적합하지 않았습니다.DialingList의 번호로 전화를 걸려면 통화를 하는 동안 상담원이 묶여 있었습니다.즉, PSTN(Public Switched Telephony Network) 번호가 유효하지 않거나 통화 중이거나 자동 응답기로 이어졌더라도 각 발신 통화에 대해 상담원이 사용되었습니다.이러한 높은 수준의 상담원 활용은 이러한 활용 사례에서 Preview Outbound Dialer의 주요 단점이었습니다.

IVR 기반 아웃바운드 통화 흐름

IVR 기반 아웃바운드 다이얼러에서 동일한 사용 사례(약속 미리 알림 및 셀프 서비스 IVR 애플리케이션)의 경우 상담원이 통화 흐름에 관여하지 않을 수 있습니다.IVR 기반 아웃바운드 다이얼러의 통화 흐름입니다.

아웃바운드 IVR 다이얼러는 알고리즘에 정의된 대로 다이얼할 연결 수를 결정하고 SIP를 사용하여 음성 게이트웨이를 통해 아웃바운드 전화를 겁니다.
음성 게이트웨이는 CPA(Call Progress Analysis) 기능을 통해 비실시간 연결을 탐지하고 비라이브 연락처의 상태를 다이얼러로 전송합니다.다이얼러는 구성 데이터베이스의 연락처 상태 정보를 업데이트합니다.
음성 게이트웨이는 CPA 기능으로 실시간 연결을 탐지하고 라이브 연락처의 상태를 다이얼러로 전송합니다.다이얼러는 컨피그레이션 데이터베이스의 연락처 상태 정보를 업데이트하고 SIP 게이트웨이로 SIP 참조 메시지를 보냅니다. 그러면 CUCM(Cisco Unified Communications Manager)에서 구성된 CTI 경로 포인트로 통화를 전송합니다.
CUCM은 통화를 Cisco UCCX 서버의 IVR 포트로 전송합니다.
IVR 하위 시스템은 통화를 캠페인과 연결된 IVR 애플리케이션과 연결합니다.엔진은 애플리케이션 실행을 시작하고 UCCX의 캠페인에 대한 IVR 애플리케이션과 고객 연락처 간에 IVR 세션이 실행됩니다.

IVR 기반 다이얼러 유형

IVR 기반 아웃바운드 다이얼러의 두 가지 유형은 예측 가능성과 진행성입니다.UCCX는 라이브 음성(또는 구성 가능한 자동 응답기)이 탐지될 때 스크립트를 실행하기 위해 통화를 IVR 포트로 전송하므로 모든 아웃바운드 연락처에 포트가 필요하지 않다고 가정하는 것이 합리적입니다.CTI 포트가 RNA(Ring No Answer), 통화 중 및 잘못된 번호 상황이 존재할 확률과 균형을 맞추려면 예측 및 진행형 다이얼러는 구성된 아웃바운드 CTI 포트 수에 따라 한 번에 걸려오는 아웃바운드 통화 수를 수정합니다.

예측 IVR 기반 아웃바운드 다이얼러는 다음과 같은 기능을 제공합니다.

각 포트의 회선 수는 취소 통화 속도에 따라 조정할 수 있습니다.
수동 개입이 필요하지 않습니다.
목표는 IVR 포트를 계속 사용할 수 있도록 충분한 회선을 다이얼하는 것이지만 구성된 최대 취소 통화 속도를 초과하지 않는 것입니다.

프로그레시브 IVR 기반 아웃바운드 다이얼러의 기능은 다음과 같습니다.

사용 가능한 각 아웃바운드 IVR 포트에 대해 항상 전화를 거는 고정 회선 수를 지정할 수 있습니다.
행 수는 나중에 업데이트할 수 있습니다.
각 포트에 3개의 회선이 있고 아웃바운드에 대한 전용 포트 수가 3개이면 9개의 통화(3x3)로 전화를 겁니다.
고객이 전화기에 응답할 때 취소된 통화가 발생하지만 고객에게 메시지를 표시하는 데 사용할 수 있는 포트가 없습니다.
기본 설정을 정의할 수 있습니다.

UCCX를 사용하는 다이얼러 구성 요소

모든 기능 및 내부 하위 시스템이 이 새로운 IVR 기반 아웃바운드 다이얼러를 고려하도록 추상화됩니다.Engine 및 DialingList 테이블과 같은 새 다이얼러의 시스템 구성 요소는 Preview Outbound Dialer와 동일하며 내선 번호(예: callStatus 및 callResult 값)가 추가되었습니다.

게이트웨이 기능 정보

라이브 음성, 자동 응답기 및 SIT(특수 정보 신호음)의 탐지를 지원하려면 게이트웨이가 CPA 기능을 지원해야 합니다.Cisco Feature Navigator를 사용하여 SIP 다이얼러 및 CPA를 지원하는 게이트웨이 Cisco IOS^® 버전을 확인합니다.'기능별 검색' 검색을 사용하여 'SIP 다이얼러의 서비스 가용성 지원 및 통화 진행 분석'을 수행합니다.

CPA는 어떻게 작동합니까?

CPA에는 세 가지 주요 기능이 있습니다.

자동 응답기 감지(AMD)
팩스/모뎀 감지
자동 응답기 종료 신호음 감지

이러한 차이를 만들기 위해 복잡한 알고리즘이 구현되지만 기능적 기준점에서 구현됩니다.

라이브 파티 답변은 짧은 인사, 그리고 침묵의 기간이 될 것으로 예상됩니다.
예:"Hello" + 침묵
예:"안녕하세요, 존슨 거주지" + 침묵
자동 응답기는 더 긴 인사말이 될 것으로 기대되며, 그 다음에는 침묵이 없을 것입니다.
예:"밀러댁에 도착하셨으니, 삐 소리가 난 후에 메시지를 남겨주세요."
자동 응답기 종료 신호음이 감지되면 자동 응답기를 감지한 다음 침묵이 감지되고 종료 신호음이 감지됩니다.
팩스 탐지기는 팩스 신호음을 인식합니다.

이러한 구별을 만드는 기능은 어려울 수 있으므로 컨피그레이션을 최적화하기 위해 시간 매개변수를 조정해야 할 수 있습니다.

고려해야할 또 다른 요소는 휴대폰 제공자들이 그들에게 전화를 하는 것, 세포의 위치, 그리고 그 자체로 통화를 표시하는 것 사이에 다양한 정도의 지연이 있을 수 있다는 것입니다.

다음은 관련된 계산의 예입니다.

UCCX가 게이트웨이에 SIP 초대 전송(T1)
게이트웨이가 ISDN 통화 설정을 통신 사업자 및 셀 공급자(T2)로 보냅니다.
휴대폰이 울리고 응답 없음 타이머(T3)를 시작합니다.
셀 RNA 타이머가 만료되어 음성 메일로 전달(T4)

셀에 대한 RNA 타이머가 15초라고 가정할 경우, 셀에서 음성 메일로 착신 전환하는 데 걸리는 실제 시간은 (T1 + T2 + T3 + 15)입니다.T1 + T2 + T3은 일반 회선 또는 기타 비셀 장치에 통화를 표시하는 데 걸리는 시간보다 훨씬 더 높을 수 있습니다.

따라서 캠페인에 대한 응답 없음 전화 걸기 제한을 정의할 때, 휴대폰 음성 메일 시스템에 도달하려면 기간이 충분히 길어야 합니다.예를 들어, 메시지를 남기려는 캠페인에서 원하는 동작입니다.

참고:CPA는 게이트웨이의 기능입니다.Cisco UCCE(Unified Contact Center Enterprise)와 달리 UCCX에서는 CPA를 켜거나 끌 수 없습니다.게이트웨이에서 CPA를 끌 수 있지만, Cisco에서는 이를 권장하지 않습니다.자세한 내용은 통화 진행 분석 개요를 참조하십시오.

IOS 게이트웨이 코드 선택은 이 문서의 범위를 벗어납니다.게이트웨이 코드는 IVR 기반 아웃바운드 다이얼러를 사용하려면 CPA 및 SIP 다이얼러를 지원해야 합니다.Cisco Feature Navigator를 사용하면 기능 요구 사항을 충족하는 IOS 릴리스를 찾을 수 있습니다.항상 IOS 릴리스가 이 게이트웨이와 상호 작용하는 모든 구성 요소와 호환되는지 확인하십시오.

문제 해결

참고:이 섹션에 사용된 명령에 대한 자세한 내용을 보려면 Command Lookup Tool(등록된 고객만 해당)을 사용합니다.

아웃바운드 IVR의 문제를 해결하려면 게이트웨이, CUCM 또는 UCCX에 결함이 있는지 확인합니다.문제를 특정 구성 요소로 분리하면 문제 해결이 더 쉬워집니다.시스템 구성 요소에서 이 정보를 수집하는 것이 좋습니다.

게이트웨이의 경우 다음 명령을 실행합니다.

기술
ccsip 메시지 디버그
디버그 voip ccapi inout
debug isdn q931(또는 PSTN 측 신호 캡처를 위한 유사 디버그)
모두 voip hpi 디버깅(CPA 문제 해결)
vtsp all 디버그(CPA 문제 해결)

UCCX의 경우 로그 파일 및 컨피그레이션을 검토합니다.

SS_OB 디버깅 및 XDebug1 - XDebug3이 활성화된 MIVR 로그 파일
JTAPI 로그 파일(REFERed 호출 실패 문제 해결)
UCCX AppAdmin의 SIP 게이트웨이 구성

CUCM의 경우 컨피그레이션을 검토합니다.

자세한 통화 관리자
자세한 CTIM관리자
아웃바운드 IVR에 사용되는 게이트웨이를 가리키는 SIP 트렁크 컨피그레이션

데이터 분석

SIP 게이트웨이는 UCCX에서 PSTN으로 통화 요청을 라우팅하는 것은 물론, 아웃바운드로 지정된 UCCX 트리거로 이러한 통화 전송을 처리하는 데 필요한 컨피그레이션을 포함해야 합니다.이 SIP 게이트웨이 구성에는 다음이 있어야 합니다.

UCCX의 수신 SIP 요청과 일치시키기 위한 인바운드 다이얼 피어
PSTN으로 통화를 라우팅하기 위한 아웃바운드 다이얼 피어(VoIP 또는 일반 전화 서비스[POTS])입니다.
UCCX와 통합된 CUCM 클러스터에 리디렉션된(참조) 통화를 라우팅하는 아웃바운드 다이얼 피어(VoIP)

CUCM 서버는 SIP 게이트웨이로부터 인바운드 SIP 통화 요청을 수신하고(REFERed 통화) 이에 따라 요청을 UCCX 트리거 및 UCCX 통화 제어 그룹 CTI 포트로 라우팅하도록 구성해야 합니다.

샘플 SIP 게이트웨이 구성

다음은 표기법이 포함된 SIP 게이트웨이 구성의 예입니다.이 예에서 PSTN 연결은 ISDN PRI(Primary Rate Interface)입니다.

참고:다른 유형의 TDM(Time Division Multiplexing) PSTN 연결이 지원되지만 Cisco CUBE(Unified Border Element)는 지원되지 않습니다.CUBE 지원에 대한 자세한 내용은 Cisco 버그 ID CSCui62525 및 CSCuf44826을 참조하십시오.TDM PSTN에 대한 다중 연결은 서로 다른 트렁크 또는 제공자에게 서로 다른 통화 클래스(로컬, 장거리, 국제)를 라우팅하는 데 지원됩니다.

RyanIVRRouter#show run
Building configuration...

ISDN PRI용으로 구성된 T1 컨트롤러

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

ISDN PRI용으로 구성된 직렬 인터페이스

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

PSTN에 아웃바운드 통화를 라우팅하기 위한 음성 포트

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

인바운드 VoIP 다이얼 피어

이 다이얼 피어는 UCCX의 수신 SIP 통화 요청과 일치합니다.인바운드 VoIP 다이얼 피어가 구성되지 않은 경우 기본 다이얼 피어(다이얼 피어 0)가 일치합니다.인바운드 VoIP 다이얼 피어를 정의하고 확인하는 것이 좋습니다.이 다이얼 피어는 UCCX의 인바운드 SIP 레그에 사용할 코덱의 게이트웨이, 프로토콜 및 DTMF(Dual-Tone Multifrequency) 릴레이를 알립니다.

이 다이얼 피어는 717로 시작하고 길이가 10자리인 DNIS(Digital Number Identification Service)를 사용하여 모든 인바운드 SIP INVITE와 일치합니다.이 예에서는 UCCX에서 전화를 건 모든 연락처가 717 지역 번호로 되어 있고 전화 번호가 10자리 깁니다.

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

POTS 다이얼 피어

이 다이얼 피어는 이전에 구성된 PRI를 통해 PSTN으로 통화를 라우팅합니다.UCCX에서 걸려오는 통화 요청에 대한 발신 다이얼 피어와 위의 VoIP 다이얼 피어 100에 대한 아웃바운드 다이얼 피어입니다.이 다이얼 피어는 테스트 목적으로 PSTN에서 오는 통화에 대한 인바운드 다이얼 피어의 역할도 합니다.UCCX 아웃바운드 다이얼러 통화 흐름에서 이 다이얼 피어가 인바운드 다이얼 피어로 일치하지 않습니다.

!
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 다이얼 피어

이 다이얼 피어는 UCCX 트리거를 위한 CUCM 클러스터로 통화를 라우팅하기 위해 SIP 게이트웨이에 필요한 아웃바운드 다이얼 피어의 역할을 합니다.이 다이얼 피어는 라이브 음성(또는 컨피그레이션이 있는 경우 자동 응답기)이 탐지될 때 게이트웨이가 UCCX에서 보낸 REFER를 라우팅하는 데 사용됩니다.이 다이얼 피어는 SIP 게이트웨이가 리디렉션된 통화를 라우팅해야 하는 CUCM 노드의 프로토콜, DTMF 릴레이, 코덱과 IP 주소를 정의합니다.이중화 및 로드 밸런싱을 위해 이 유형의 여러 다이얼 피어가 존재할 수 있습니다.클러스터의 여러 CUCM 노드에 요청을 라우팅하기 위해 분할하거나 특정 트리거에 대한 리디렉션을 다른 CUCM 노드로 라우팅하도록 프로비저닝할 수 있습니다.

이 예에서 IVR 기반 아웃바운드 캠페인에 대한 UCCX 트리거는 2001과 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
!

샘플 IVR 기반 아웃바운드 통화 추적 분석

SIP 게이트웨이, UCCX 및 PSTN 간의 메시징 로그 예제에 대한 자세한 분석입니다.

UCCX의 초기 INVITE는 게이트웨이에 PSTN 번호로 전화를 걸도록 지시합니다.INVITE에는 이 통화에 연결된 모든 메시지를 추적하는 데 사용할 수 있는 통화 ID와 SDP(세션 설명 프로토콜)(미디어 매개변수)가 포함되어 있습니다.

INVITE에는 게이트웨이가 CPA를 완료하는 데 사용해야 하는 매개변수가 포함됩니다.이러한 매개변수는 UCCX AppAdmin 페이지에서 구성되지만 UCCX에서는 사용되지 않습니다.대신 INVITE에서 게이트웨이로 전송되고 게이트웨이가 이 통화에 대해 CPA용 DSP(디지털 신호 프로세서)를 구성하는 데 사용합니다.따라서 이러한 매개 변수는 통화별로 게이트웨이로 전송되며 AppAdmin에서 언제든지 변경할 수 있습니다.

UCCX는 다음과 같은 CPA 컨피그레이션 특성을 각 통화에 대해 게이트웨이로 전송합니다.

매개 변수 이름	매개 변수 값	제안된 값
최소 침묵 기간(100 - 1000)*	밀리초	375
분석 기간(1000 - 10000)*	밀리초	2500
최대 시간 분석(1000 - 10000)*	밀리초	3000
최소 유효한 음성 시간(50 - 500)*	밀리초	112
최대 용어 톤 분석(1000 - 60000)*	밀리초	15000

구성 가능한 값은 SIP Gateway Configuration 페이지의 AppAdmin에 표시됩니다.

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--

통화가 게이트웨이의 다이얼 피어를 통해 처리되면 UCCX는 '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

아웃바운드 통화가 아웃바운드 다이얼 피어와 일치하면 구성된 TDM 프로토콜을 사용하여 PSTN으로 전송됩니다.이 경우 PRI가 사용됩니다.

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

통화가 진행되며 PSTN과 게이트웨이 간에 시그널링이 교환됩니다.게이트웨이에 PSTN 전화기가 ALERTING 메시지와 함께 울린다는 알림이 전송됩니다.

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

게이트웨이가 UCCX에 183 Session Progress(세션 진행률)를 다시 전송하여 PSTN 전화기가 울리고 있음을 UCCX에 알립니다.여기에는 벨소리 간 미디어 협상을 위한 SDP가 포함됩니다.

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--

PSTN 전화기가 통화에 응답할 때 통화가 TDM 레그에 연결됩니다.게이트웨이가 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

게이트웨이는 통화가 200으로 연결되었음을 UCCX에 알립니다.UCCX ACK는 SIP RFC에 필요한 대로 이 기능을 수행합니다.200 OK에는 미디어 협상을 위한 SDP도 포함되지만 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
...

게이트웨이는 CPA와의 통화 진행률을 탐지하고 일련의 UPDATE 메시지를 통해 UCCX에 통화 진행률을 알립니다.UCS ACK는 SIP RFC에 필요한 대로 이를 수행합니다.

이 SIP 업데이트 예에서는 이벤트가 'Detected'이고 상태는 'CpaS'입니다.

CpaS는 CPA가 시작되었음을 나타냅니다.
자동 응답기가 탐지되면 상태는 'Asm'입니다.
자동 응답기 신호음이 검증되면 상태는 'AsmT'입니다.

다음 표에는 SIP 업데이트 메시지에 사용되는 x-cisco-cpa 상태 코드가 나열되어 있습니다.

이름	정의
FT	팩스/모뎀 신호음.
asm	응답 머신.
asmT	응답 머신 종료 신호음.
LS	인간 연설 살아
SitIC	SIT 톤 IC - 가로채기 - 비어 있는 번호 또는 AIS 등
SitNC	SIT 신호음 NC - 회로, 긴급 또는 트렁크 차단 없음
SitVC	SIT 톤 VC - 빈 코드
SitRO	SIT 신호음 RO - 다시 알림
MT	기타 SIT 신호음
CPAs	CPA 시작
LV	낮은 볼륨 또는 무정지 무선 통화

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는 이 아웃바운드 캠페인에 할당된 트리거에 통화를 리디렉션하도록 게이트웨이에 알림을 보냅니다.게이트웨이 ACK가 이를 나타냅니다.

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
...

게이트웨이는 이 통화를 게이트웨이의 다이얼 피어를 통해 일반 통화 처리로 새 대상에 라우팅해야 합니다.

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)

통화는 REFER에 포함된 대상에 대해 일치하는 아웃바운드 다이얼 피어의 컨피그레이션을 기반으로 게이트웨이에 의해 라우팅됩니다.

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

샘플 MIVR 로그 분석

MIVR 로그의 이러한 코드 조각은 UCCX 관점에서 통화의 개요를 제공합니다.올바른 정보를 캡처하려면 다음 디버그 레벨을 활성화합니다.

SS_OB - 디버그,XD1,XD2,XD3
SS_RM - 디버그,XDebug1
CFG_MGR - Debug,XDebug1(다이얼링 목록 레코드와 관련된 문제인 경우)

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

참고:여러 캠페인이 동시에 있을 수 있으므로 campaignID 및 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.

다음은 포맷되고 포맷되지 않은 전화번호입니다.

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 )

SIP 신호 처리가 시작됩니다.

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

앞서 설명한 게이트웨이 메시징을 사용하여 게이트웨이에서 이러한 메시지의 처리를 확인합니다.

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&colon;
incrementAttemptedCalls() by 1. Total attempted calls = 1
//Since this is the first time the record is dialled out, the total attempted calls = 1

게이트웨이는 CPA 메시지와 함께 SIP UPDATE 메시지를 보냅니다.CPA 소프트웨어는 게이트웨이에서 실행되며 수신자의 RTP(Real-Time Transport Protocol)를 분석합니다.이렇게 하면 발신자 끝의 음성 및 자동 응답기를 구분할 수 있습니다.'application/x-cisco-cpa'의 Content-Type으로 CPA SIP UPDATE 메시지를 식별할 수 있습니다.

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

일반적인 문제

게이트웨이에서 UCCX로 전송되는 CPA 없음

통화가 PSTN 발신자와 연결된 후에는 게이트웨이가 UCCX로 메시지를 다시 전송하지 않으므로 CPA가 완료되었으며 통화가 발생했음을 나타냅니다(라이브 음성, 통화 중, 자동 응답기 등). 게이트웨이의 IOS 버전이 CPA를 지원하는지 확인합니다.게이트웨이를 조사하여 CPA가 제대로 작동하는지 확인합니다.

라이브 음성 감지 후 통화가 UCCX로 리디렉션되지 않음

게이트웨이에 캠페인에 할당된 UCCX 트리거 DN(dialed number)과 일치하는 다이얼 피어가 있는지 확인합니다.게이트웨이의 통화가 CUCM의 해당 CTI 경로 포인트/트리거에 라우팅될 수 있는지 확인합니다.

재시도가 전화를 걸지 않음

미리 보기 아웃바운드 다이얼러의 콜백과 비슷하게 RNA를 받거나 통화 중인 통화를 다시 시도하지 않는 경우 이러한 레코드가 DialingList 테이블에서 재시도로 올바르게 표시되는지 확인합니다.MIVR 로그에서 지정된 콜백 또는 재시도 시간에 통화를 시도하고 있는지 확인합니다.

IVR 스크립트에 연결된 경우 DTMF가 작동하지 않음

DTMF가 CUCM과 게이트웨이 간에 올바르게 협상되고 명명된 다이얼 피어가 일치하는지 확인합니다(다이얼 피어 0은 DTMF 릴레이 컨피그레이션을 포함하지 않음).UCCX는 JTAPI를 통해 대역외 DTMF만 지원하므로, 일부 게이트웨이 유형 및 통화 흐름에서는 DTMF 인터워킹 완료를 위해 MTP(Media Termination Point)를 호출해야 할 수 있습니다.게이트웨이를 조사하여 게이트웨이와 CUCM이 DTMF 요청 및 협상을 올바르게 처리하고 있는지 확인합니다.