目錄

簡介

功能資訊

基於IVR的出站呼叫流

基於IVR的撥號器型別

採用UCCX的撥號器元件

網關功能資訊

疑難排解

資料分析

SIP網關配置示例

基於IVR的出站呼叫跟蹤分析示例

MIVR日誌分析示例

常見問題

網關不向UCCX傳送CPA

檢測到Live Voice後，呼叫沒有重定向到UCCX

未撥打電話重試次數

連線到IVR指令碼時，DTMF不起作用

相關資訊

簡介

本文檔介紹基於IVR的撥出撥號程式，並包括SIP網關配置示例、來自SIP網關和Cisco Unified Contact Center Express(UCCX)引擎的日誌分析以及基於IVR的撥出撥號程式的限制。

在UCCX 8.5中，引入了新型撥出撥號程式：基於互動式語音響應(IVR)的出站撥號程式。與早期的「預覽出站撥號程式」不同，不使用任何座席進行出站呼叫。UCCX直接連線到客戶企業中的會話發起協定(SIP)網關以撥打出站聯絡人。當網關檢測到即時語音或應答機時，呼叫被重定向到繫結到出站呼叫控制組的UCCX觸發器。一旦在出站電腦電話整合(CTI)埠上終止，與該觸發器相關聯的應用程式將正常執行。

功能資訊

在低於8.5的UCCX版本中，僅存在預覽出站撥號程式。該撥號器通過Java電話應用程式設計介面(JTAPI)/CTI使用第三方呼叫控制來指示座席的電話進行呼叫。呼叫是在座席接受去話保留之後發出的。客戶端與伺服器之間通過CTI完成出站預留的互動。

對於某些使用案例（例如約會提醒和自助服務IVR應用），預覽撥出撥號器不是很好的選擇。要對DialingList中的某個號碼進行呼叫，在撥打電話時已鎖定座席。這意味著座席會佔用每個出站呼叫，即使公共交換電話網路(PSTN)號碼無效、忙或導致應答機也是如此。對於這些使用案例，這種較高的代理利用率是預覽出站撥號程式的主要缺陷。

基於IVR的出站呼叫流

對於基於IVR的撥出撥號程式中的相同使用案例（約會提醒和自助服務IVR應用），座席可能永遠不會參與呼叫流程。這是基於IVR的出站撥號程式的呼叫流：

1. 撥出IVR撥號器確定要撥號的聯絡人數（如演算法中所定義），並使用SIP通過語音網關發出撥出呼叫。

2. 語音網關檢測具有其呼叫進度分析(CPA)能力的非即時聯絡人，並將非即時聯絡的狀態傳送到撥號器。撥號器會更新配置資料庫中的聯絡狀態資訊。

3. 語音網關檢測具有其CPA能力的即時聯絡人，並將即時聯絡的狀態傳送到撥號器。撥號程式更新配置資料庫中的聯絡狀態資訊，並向SIP網關傳送SIP參考消息，SIP網關又將呼叫轉接至思科統一通訊管理器(CUCM)上配置的CTI路由點。

4. CUCM將來電轉駁到Cisco UCCX伺服器上的IVR埠。

5. IVR子系統將呼叫與與該活動相關聯的IVR應用相關聯。引擎開始執行應用程式，並且IVR會話在UCCX上的行銷活動的IVR應用程式和客戶聯絡人之間進行。

基於IVR的撥號器型別

有兩種基於IVR的出站撥號程式，預測撥號程式和累進撥號程式。由於UCCX在檢測到即時語音（或可配置的應答機）時只將來電轉駁到IVR埠以執行指令碼，因此有理由假定並非每個出站聯絡人都需要一個埠。為了權衡需要CTI埠的可能性與存在無應答(RNA)、繁忙和無效號碼情況的概率，預測和累進撥號器會根據配置的出站CTI埠數量修改一次發出的出站呼叫數量。

基於預測IVR的出站撥號程式具有以下功能：

- 每個埠的線路數可根據放棄呼叫速率進行調整。

- 無需手動干預。

- 目標是撥打足夠多的線路，以使IVR埠保持忙碌狀態，但不會超過配置的最大放棄呼叫速率。

基於IVR的漸進式撥出撥號程式具有以下功能：

- 您可以為每個可用的出站IVR埠指定始終撥打的固定行數。

- 可以在以後更新行數。

- 如果每個埠有三條線路，並且用於出站的專用埠數為三，則撥打九個呼叫(3x3)。

- 如果客戶接聽電話，但沒有埠提示客戶，則會發生已放棄呼叫。

- 可以定義預設設定。

採用UCCX的撥號器元件

所有功能和內部子系統都經過抽象化，以便適應這種新的基於IVR的出站撥號器。新撥號程式中的系統元件（如Engine和DialingList表）與預覽出站撥號程式中的系統元件相同，並且新增了分機（如更多callStatus和callResult值）。

網關功能資訊

為了支援即時語音、應答機和特殊資訊音(SIT)檢測，網關必須支援CPA功能。使用Cisco Feature Navigator確定支援SIP撥號器和CPA的網關Cisco IOS®版本；使用「Search by Feature」搜尋「SIP dialer and Call Progress Analysis的可維護性支援」。

CPA如何運作？

CPA有三種主要功能：

- 答錄機檢測(AMD)

- 傳真/數據機檢測

- 應答機終止音檢測

實現這些區分的演算法非常複雜，但從功能的角度來看：

- 派對上的即時回應應該是短暫的問候，然後是靜默期。

範例：「Hello」 +靜默

範例：「Hello， Johnson residence」 +靜默

- 一台答錄機應該只是一個持續的問候，而不是寂靜。

範例：「您已經到達米勒的住所，請在嗶聲後留言」

- 應答機終止音檢測是應答機的檢測，然後是靜音，最後是終止音。

- 傳真檢測是傳真音的識別。

進行這些區分的能力可能很難，因此可能需要調整計時引數以最佳化配置。

需要考慮的另一個因素是，手機提供商在向其呈現呼叫、蜂窩位置以及向其本身呈現呼叫之間可能存在不同程度的延遲。

以下是相關計算的範例：

1. UCCX向網關(T1)傳送SIP邀請

2. 網關將ISDN呼叫設定傳送到服務提供商和小區提供商(T2)

3. 手機振鈴並開始無應答計時器(T3)

4. 細胞RNA計時器到期並轉發到語音郵件(T4)

如果假定信元的RNA計時器是15秒，那麼對信元的呼叫轉發到語音郵件所需的實際時間是(T1 + T2 + T3 + 15)。T1 + T2 + T3可以顯著高於向固定電話或其他非蜂窩裝置呈現呼叫所需的時間。

因此，在為市場活動定義無應答振鈴限制時，該時間段需要足夠長，才能到達行動電話的語音郵件系統；例如，對於打算留下資訊的活動而言，這是理想的行為。

附註：CPA是網關的功能；與Cisco Unified Contact Center Enterprise(UCCE)不同，CPA不能在UCCX上開啟或關閉。雖然可以在網關上關閉CPA，但思科不建議這樣做。有關詳細資訊，請參閱呼叫進度分析概述。

IOS閘道碼的選取不在本檔案的範圍之內。網關代碼必須支援CPA和SIP撥號程式才能使用基於IVR的出站撥號程式。Cisco Feature Navigator可幫助您找到滿足功能要求的IOS版本。請務必確保您的IOS版本與與此網關互動的所有元件相容。

疑難排解

附註：使用命令查詢工具(僅供已註冊客戶使用)可獲取本節中使用的命令的更多資訊。

為了對出站IVR進行故障排除，請確定網關、CUCM或UCCX是否有故障。將問題隔離到特定元件後，故障排除會更加容易。從系統元件收集此資訊非常有用

對於網關，運行以下命令：

1. show tech

2. debug ccsip messages

3. debug voip ccapi inout

4. debug isdn q931(或類似調試以捕獲PSTN端信令)

5. debug voip hpi all(排除CPA故障)

6. debug voip vtsp all(排除CPA故障)

對於UCCX，請檢視日誌檔案和配置：

1. MIVR日誌檔案，SS_OB調試和XDebug1 — 啟用XDebug3

2. JTAPI日誌檔案（用於排除引用呼叫故障）

3. 來自UCCX AppAdmin的SIP網關配置

對於CUCM，請檢視配置：

1. 詳細的CallManager

2. 詳細的CTIManager

3. 指向用於出站IVR的網關的SIP中繼配置

資料分析

SIP網關必須包含必要的配置，以便從UCCX將呼叫請求路由到PSTN，而且還要處理這些呼叫到指定用於出站的UCCX觸發器的傳輸。此SIP網關配置必須具有：

1. 入站撥號對等體匹配來自UCCX的傳入SIP請求。

2. 出站撥號對等體（VoIP或普通舊式電話服務[POTS]）將呼叫路由到PSTN。

3. 出站撥號對等體(VoIP)，用於將重定向（參考）呼叫路由到與UCCX整合的CUCM集群。

必須將CUCM伺服器配置為接收來自SIP網關的入站SIP呼叫請求（REFER呼叫），並將請求相應地路由到UCCX觸發器和UCCX呼叫控制組CTI埠。

SIP網關配置示例

以下是包含符號的SIP網關配置示例。在此範例中，PSTN連線是ISDN主要速率介面(PRI)。

附註：支援其他型別的時分多工(TDM)PSTN連線，但不支援思科統一邊界元素(CUBE)。如需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)中繼。

此撥號對等體匹配所有入站SIP INVITE與數字號碼識別服務(DNIS)匹配，該服務以717開頭，長度為10位數。在本示例中，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撥號對等體

此撥號對等體充當SIP網關所需的出站撥號對等體，以將呼叫路由到發往UCCX觸發器的CUCM集群。當檢測到即時語音（或應答機，如果存在配置）時，網關使用此撥號對等體來路由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網關配置頁面的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嘗試」消息。

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

網關將183會話進度傳送回UCCX，通知UCCX的PSTN電話正在振鈴。其中包括用於回鈴音的媒體協商的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

網關通知UCCX呼叫已連線200 OK。根據SIP RFC的要求，UCCX可確認這一點。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按照SIP RFC的要求進行確認。

在此示例SIP更新中，事件為「Detected」，狀態為「CpaS」。

- 註冊會計師表明註冊會計師已經開始。

- 檢測到應答機時，狀態為「Asm」。

- 答錄機提示音合格時，狀態為「AsmT」。

下表列出了SIP更新消息中使用的x-cisco-cpa狀態代碼：

名稱

定義

FT

傳真/數據機音。

Asm

答錄機。

AsmT

應答機終止音。

LS

活生生的講話。

SitIC

坐姿IC — 攔截 — 空置編號或AIS等。

SitNC

SIT tone NC — 無電路、緊急或中繼阻塞

SitVC

SIT tone VC — 空代碼

SitRO

SIT tone RO — 重新訂購公告

SitMT

其他SIT音調

註冊會計師

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向網關傳送通知，將呼叫重定向到分配給此出站活動的觸發器。網關會對此進行確認。

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 — 調試，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

網關傳送一個SIP UPDATE消息以及CPA消息。CPA軟體在網關上運行，並從被叫方分析即時傳輸協定(RTP)。這有助於區分被叫端語音和應答機。您可以通過內容型別「application/x-cisco-cpa」標識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是否正常運行。

檢測到Live Voice後，呼叫沒有重定向到UCCX

驗證網關是否具有與分配給活動的UCCX觸發器撥號號碼(DN)匹配的撥號對等體。驗證來自網關的呼叫是否可以路由到CUCM中的CTI路由點/觸發器。

未撥打電話重試次數

與預覽出站撥號程式中的回撥類似，如果接收RNA或忙碌的呼叫未重試，請確認這些記錄在DialingList表中已正確標籤為Retry。從MIVR日誌中驗證是否在指定的回叫或重試時間進行呼叫嘗試。

連線到IVR指令碼時，DTMF不起作用

驗證CUCM和網關之間是否正確協商了DTMF，以及命名的撥號對等體是否匹配（撥號對等體0不包含DTMF中繼配置）。UCCX僅支援通過JTAPI的帶外DTMF，因此某些網關型別和呼叫流程可能需要呼叫媒體終端點(MTP)來完成DTMF互通。檢查網關以驗證網關和CUCM是否正確處理DTMF請求和協商。

相關資訊

- 技術支援與文件 - Cisco Systems