cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
7448
Views
8
Helpful
20
Replies

Outbound dialer IVR Progressive Campaign on UCCX (10.5) with CUBE (Cisco2951) SIP trunk provider

Maxim Generalov
Level 1
Level 1

Hello guru of voice technology.

The company use SIP trunk for outbound calls (over CUBE).

Using UCCX we need to make dialing (IVR based) to customer over CUBE. 

On picture "case.png" you can see the topology of sip dialing.

Step by step:

1. I make IVR Progressive Campaign, run Capmaing.

2. I can see Signaling Legs from UCCX to CUBE and from CUBE to ISP. That's OK.

3. Mobile phone is ringing, I answered the phone call and listen to the silence.

4. On the CUBE command "show cube call all" display the root problem: RTP source IP for leg CUBE UCCX is incorrect!

For some reason, CUBE take incorrect IP for media leg.Strictly speaking this is a problem.

Picture "wireshark_error": dispay the field "Contact information" with incorrect IP address, for some reason CUBE chooses white IP address of router.

Picture "sh_cube_call_all" display detaled information for connection, you can see Signalling is OK, media is FAIL.

Where is some

best practice for using this scenario?

I've read cisco documentation and found: "Cisco support this 

scenario only CUBE with E1 connection PSTN

", but may be now it's possiable?

I needn't CPA function from CUBE, just ringing.

2 Accepted Solutions

Accepted Solutions

It's a second question.

While UCCX do not respond with ACK to CUBE nothing happens. After that CUBE should send UPDATES with CPA status to UCCX, next UCCX should send REFER message and CUBE will redirect client call to CUCM.

 

Main issue UCCX receives SIP messages from CUBE but do not process/reply them. Capture file contain all SIP messages betrween cube and uccx. MIVR trace file contain only initial INVITE message for outbound call.

Can you change Transport Protocol to TCP in UCCX SIP Gateway Configuration ? Then collect MIVR traces and debug ccsip mess once again.

 

View solution in original post

We figured out that rtp-nte didn't work for CPA. Which another dtmf-relay methods ITSP supports?

View solution in original post

20 Replies 20

Hi there.

Can you post cube config and collect debugs for call: debug ccsip messages and debug voip ccapi inout ?

 

Hello, Valery

Here are files you ask.

This CUBE permanently using as voice gate to ISP MTS and BeeLine and all is OK. Why UCCX can not do exactly the same (of course with CPA function)?

Can you try to assign interfaces for outgoing dial-peers toward CUCM/UCCX and ITSP

dial-peer voice 250 voip
 voice-class sip bind control source-interface GigabitEthernet0/1.1405
 voice-class sip bind media source-interface GigabitEthernet0/1.1405

dial-peer voice 1060 voip
 voice-class sip bind control source-interface GigabitEthernet0/0.200
 voice-class sip bind media source-interface GigabitEthernet0/0.200

And rerun debugs.

I've already tried do this - nothing changes.

CUBE do not use commands like "bind media or control", CUBE itself chooses the correct interface.

May be try to change IOS?

Now, it's c2951-universalk9-mz.SPA.154-3.M2.bin

Ok, in debugs 183 Session Progress INVITE message from CUBE to UCCX i see that CPA (ip2ip) is disabled. And UCCX is ignoring this messages.

Oct 26 06:14:41.125: //1554064/6EB065FD6898/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP 10.10.10.5:5065;branch=z9hG4bK21KEeVGECzewNG12V3eI+g~~37
From: <sip:1061@10.10.10.5>;tag=ds555c6713
To: <sip:89134789003@10.10.10.1>;tag=9FBF70A8-946
Date: Mon, 26 Oct 2015 06:14:41 GMT
Call-ID: 144584007756138@10.10.10.5
CSeq: 100 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Remote-Party-ID: <sip:89134789003@10.10.10.1>;party=called;screen=no;privacy=off
Contact: <sip:89134789003@10.10.10.1:5060>
Supported: sdp-anat
Server: Cisco-SIPGateway/IOS-15.4.3.M2
Content-Type: multipart/mixed;boundary=uniqueBoundary
Mime-Version: 1.0
Content-Length: 435
--uniqueBoundary
Content-Type: application/sdp
Content-Disposition: session;handling=required
v=0
o=CiscoSystemsSIP-GW-UserAgent 4046 263 IN IP4 10.10.10.1
s=SIP Call
c=IN IP4 109.174.92.138
t=0 0
m=audio 17044 RTP/AVP 0
c=IN IP4 109.174.92.138
a=rtpmap:0 PCMU/8000
a=ptime:20
--uniqueBoundary
Content-Type: application/x-cisco-cpa
Content-Disposition: signal;handling=optional
event=disabled
--uniqueBoundary--

CPA Overview doc says that it should be enabled. Now you need to configure CPA over IP-to-IP, please refer to http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube_proto/configuration/15-mt/cube-proto-15-mt-book/voi-cube-cpa.html document. You are good to go with current 15.4 IOS.

Hello, Valery

I've configured CUBE for IP2IP media

voice service voip

 cpa timing live-person 2501
 cpa timing term-tone 15500
 cpa threshold active-signal 18db

dspfarm profile 2 transcode  
 codec g711ulaw
 call-progress-analysis
 maximum sessions 16
 associate application CUBE

 

In CLI, in ringing time, I see CUBE ASSOCIATED profile active session:

 Number of Resources Active : 1

 

Now, in logs I can see status of CPA "event=enabled"

--uniqueBoundary
Content-Type: application/x-cisco-cpa
Content-Disposition: signal;handling=optional

event=enabled
--uniqueBoundary--

But selecting IP adress for media stream stil not correct

The problem in something else.

CPA - disable: just disable voice diagnostics B side. (may be)

After 183 Session Progress message CUBE sends multiple 200 OK with SDP to UCCX but UCCX does not respond to any of them.

We need to know why UCCX does not reply with ACK message. Need to collect MIVR traces from UCCX for outbound call. Turn on next debug options:

SS_OB - Debug,XD1,XD2,XD3
SS_RM - Debug,XDebug1

Hello, Valery

Here is MIVR file with selected debug options you asked.

In MIVR (and CUBE) traces we see that UCCX sends initial INVITE to CUBE.

Then CUBE sends several 100 Trying messages, 183 Session Progress and 200 OK w/ SDP toward UCCX. The problem is UCCX do not receive any of this SIP messages from CUBE it can be seen in mivr trace. After 30 seconds outbound call on uccx is terminated with call result 17.

Do you have any firewalls/routers in network between uccx and cube that may prevent traffic between this systems?

 

Please collect network capture from UCCX, MIVR trace and debug ccsip messages from cube for new call.

How to collect network capture - https://supportforums.cisco.com/document/44376/packet-capture-cucm-appliance-model

Hello Valery,

I've collected files and attached it.

I don't understand why CUBE select RTP source ip address 109.174.X.X instead of 10.10.10.1 may be this is the root of the problem?

It's a second question.

While UCCX do not respond with ACK to CUBE nothing happens. After that CUBE should send UPDATES with CPA status to UCCX, next UCCX should send REFER message and CUBE will redirect client call to CUCM.

 

Main issue UCCX receives SIP messages from CUBE but do not process/reply them. Capture file contain all SIP messages betrween cube and uccx. MIVR trace file contain only initial INVITE message for outbound call.

Can you change Transport Protocol to TCP in UCCX SIP Gateway Configuration ? Then collect MIVR traces and debug ccsip mess once again.

 

Hello Valery

Once again made a call and collected logs. Nothing changes.

Much better, now UCCX receives all messages from CUBE and responds with ACK. But CUBE do net send UPDATES with cpa status to UCCX.

/// CUBE sends 200OK with SDP
Oct 27 09:14:38.113: //1570712/13FED6771DC5/SIP/Msg/ccsipDisplayMsg:
Sent: 
SIP/2.0 200 OK
Via: SIP/2.0/TCP 10.10.10.5:5065;branch=z9hG4bK21KEeVGECzewNG12V3eI+g~~55
From: <sip:1061@10.10.10.5>;tag=ds4ec74d2
To: <sip:89134789003@10.10.10.1>;tag=A58A6394-C4A
Date: Tue, 27 Oct 2015 09:14:29 GMT
Call-ID: 144593726948552@10.10.10.5
CSeq: 100 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Remote-Party-ID: <sip:89134789003@10.10.10.1>;party=called;screen=no;privacy=off
Contact: <sip:89134789003@10.10.10.1:5060;transport=tcp>
Supported: replaces
Supported: sdp-anat
Server: Cisco-SIPGateway/IOS-15.4.3.M2
Supported: timer
Content-Type: multipart/mixed;boundary=uniqueBoundary
Mime-Version: 1.0
Content-Length: 435
--uniqueBoundary
Content-Type: application/sdp
Content-Disposition: session;handling=required
v=0
o=CiscoSystemsSIP-GW-UserAgent 8652 7310 IN IP4 10.10.10.1
s=SIP Call
c=IN IP4 109.174.92.138
t=0 0
m=audio 18452 RTP/AVP 0
c=IN IP4 109.174.92.138
a=rtpmap:0 PCMU/8000
a=ptime:20
--uniqueBoundary
Content-Type: application/x-cisco-cpa
Content-Disposition: signal;handling=optional
event=enabled
--uniqueBoundary--  

///UCCX reply with ACK (this was missed when uccx sip dialer protocol was UDP)
Oct 27 09:14:38.125: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received: 
ACK sip:89134789003@10.10.10.1:5060;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 10.10.10.5:5065;branch=z9hG4bK21KEeVGECzewNG12V3eI+g~~56
Max-Forwards: 70
To: <sip:89134789003@10.10.10.1>;tag=A58A6394-C4A
From: <sip:1061@10.10.10.5>;tag=ds4ec74d2
Call-ID: 144593726948552@10.10.10.5
CSeq: 100 ACK
Content-Length: 0
Contact: <sip:1061@10.10.10.5:5065;transport=tcp>

///UCCX sends BYE because CUBE do not send any UPDATE with CPA to UCCX after 10 sec
Oct 27 09:14:48.133: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received: 
BYE sip:89134789003@10.10.10.1:5060;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 10.10.10.5:5065;branch=z9hG4bK21KEeVGECzewNG12V3eI+g~~57
Max-Forwards: 70
To: <sip:89134789003@10.10.10.1>;tag=A58A6394-C4A
From: <sip:1061@10.10.10.5>;tag=ds4ec74d2
Call-ID: 144593726948552@10.10.10.5
CSeq: 101 BYE
Content-Length: 0
Allow: INVITE, BYE, CANCEL, ACK, UPDATE, NOTIFY
Cisco-Guid: 335468151-1604883961-499464893-860919836
User-Agent: Cisco-UCCX/8.5

 

There's a bug: Call Progress Analysis (CPA) will fail to run and detect live voice or SIT tones during a Unified Contact Center Express (UCCX) IVR-based Outbound Dialer Call.

https://tools.cisco.com/bugsearch/bug/CSCui62525

 

Please try to disable dtmf-relay rtp-nte on ITSP dial-peer?

dial-peer voice 250 voip
default dtmf-relay

 

Then collect debug ccsip mess from CUBE.

 

 

Hello Valery,

Very much better, I disable dtmf-relay on dial-peer and now call in progress (I can hear IVR)! But dtmf now does not work (which naturally).

There is delay between hand-off and sound. Looking at the console can conclude: delay is the time for changing IP media source from 192.174.X.X to 10.10.10.1. If Ip correct from the start point then delay will be smaller.