UCCX Outbound dialer to CUBE SIP Gateway with dial-peer translation rules

[Sean Lynch]

I am having difficulty trying to figure out how to get UCCX Outbound Campaigns working with a CUBE as the SIP Gateway:

My initial attempt to get this working was not a problem until I reviewed the Outbound reports in CUIC. Call Result column in the Outbound IVR CCDR Report shows the following error code for every call--including calls that were successfully delivered and answered by the intended recipient:

17—Call failed because of gateway issues

I opened a service request with the Cisco TAC to obtain assistance only to find the following...

(The following two comments were from two separate email exchanges between the Cisco TAC and myself):

- Unified CCX does not support the translation or modification of the phone number that is used to dial out the outbound calls. This is due to the voice translation rules that are configured in the gateway. Inconsistent behavior is observed in the Answering Machine Treatment also when the translation rules are configured. You can use either of the below two supported methods to modify a dialed number in the gateway:
• To remove the initial digits of the phone number use forward-digits or digit-strip in the dial peer configuration.
• To add a prefix to the phone number use prefix in the dial peer configuration.

- There seems to be no way to pass the zeros and account number on the CUBE as this will alter the TO header, hence, UCCX will detect this is different number than the dialed one and it will not write the outbound call record in the CCX Database. You have to send the original phone number from the beginning in UCCX.+

It appears that my use of Voice Translation Rules and Profiles to remove the "9" or any other prefixed digits to the called-number is unsupported.

My question is, for all of you CUBE SIP Trunk with UCCX Outbound IVR application users: what are you using for your ingress and egress dial-peers to do digit manipulation? I can't use a .T for digit matching because that is what we are using for ingress / DID calls from the ITSP.

Please help me create a new strategy to get this working...

Sincerely,

Sean

[Roger Kallberg]

Would it be possible to format the list of numbers to call to in the outbound dialer so that they start with something that can be specifically matched in the gateway in the egress direction, sort of like a route prefix? If so you could create a specific dial peer, or multiple if needed, that is used for the outbound call and on it use one of the supported digit strip commands to remove what you explicitly match with the destination pattern, the match would be the route prefix previously mentioned.

[Sean Lynch · Accepted solution]

Roger,

Thanks for the reply.  However, the problem really resides in the way we were using digit matching for WAN to LAN (ingress/egress) dial-peers, and then in the reverse--LAN to WAN (ingress/egress) dial-peers.  I was trying to re-use what was already there.  (For outbound calls, select 9 from a station, and "seize" an outside trunk traditionally--right?).  Well, This is problematic with the UCCX campaign dialer on CUBE, because UCCX does not allow for any digit manipulation using Translation Rules / Profiles--it can't report back to CUIC for call status/outcome.  Which is which is fine for telephony.  Can't do this with UCCX OB. 

The solution (which I did discover) was to use a non-digit matching technique by leveraging URI-based dialing features, which I found in the cube-book.  That accompanied with creating dial-peer groups, and -voila!- No digit matching necessary.  Put the customer numbers in the campaign flat file as a normal 10-digit telephone number, ingress dial-peer is associated with a defined voice class uri / IP address of the UCCX server(s), the egress dial-peer points to the dpg (dial peer group) using the same 9T egress dial-peer for the ITSP (however, the 9T isn't even used for digit matching!!)... and it just goes.  Nice?

...doin' a happy dance cause I figured it out.

Sincerely,

Sean

[Roger Kallberg]

Glad you got it to work Sean.

My suggestion was to use one of the discard digit functions on the dial peer that TAC wrote in their reply.

”• To remove the initial digits of the phone number use forward-digits or digit-strip in the dial peer configuration.”

If you for example put the numbers to call in your outbound campaign with a prefix, example start with *890, and then you have a outgoing dial peer that have a destination pattern that matches “*890” and have “digit-strip” set it would consume the explicitly matched digits. Possibly I wasn’t able to make this clear in my original reply.

[Sean Lynch]

Roger,

"No | digit strip" and "forward-digits all|#" are POTS dial-peer commands.  CUBE is voip only dial-peers with SIP trunks.  Those commands do not exist/work.

Remember, by default VOIP dial-peers forward all digits for matching destination patterns.  POTS dial-peers strip matching digits and forward only the wild  card digits to the destination... This is where the need for "no digit-strip", "forward-digits all" or "forward-digits 10" worked for us previously on PRI based voice gateways (SIP Gateway for outbound dialer).

The use of Translation Rules/Profiles is prevalent/best practice (?) in VOIP dial-peers. And, thus, problematic on CUBE for Outbound if you wanted to use 9T for digit matching; which we use for telephony egress dial-peers to the ITSP--I wanted to re-use the same with the Outbound dialer..  

Thanks for the reply,

Sean 

[Roger Kallberg]

Got it. Thanks for the information. What tripped me up was the reply’s from TAC, it doesn’t mention that neither of these DDI isn’t applicable for a VoIP dial peer and I did wrongfully assume that the answer alluded to how you could do what you ask for and did not even think about that those are POTS only commands. My bad in doing so.

[Sean Lynch]

Yup, I shook my head when I saw the TAC response as well.  They didn't provide a solution.  The useful information they provided was that Translation Rules and Profiles are unusable due to: "- There seems to be no way to pass the zeros and account number on the CUBE as this will alter the TO header, hence, UCCX will detect this is different number than the dialed one and it will not write the outbound call record in the CCX Database. You have to send the original phone number from the beginning in UCCX.+"  which was why I thought I was stuck.  

Thanks again for the replies...

Sincerely,

Sean

[stobar1101]

Hi @Sean Lynch 

I think I am facing the same problem, I understand that your solution was to create a dial-peer as follows:

voice class uri 100 sip
host ipv4:10.10.30.6 UCCX 1
ipv4 host:10.10.40.6 UCCX 2

dial-peer voice 100 voip
description dialer ** Incoming_Agent_Based_Predictive **
session protocol sipv2
incoming uri via 100
dtmf-relay rtp-nte
codec g711ulaw
no vad

and the dial peer, which points to the PSTN always remains with the 9, or do I need to create a dial peer that points to the PSTN without the 9?