[breadcrumb]
The Problem - Call Forwarding DNIS to Toll Free Numbers
Recently we were presented with a new challenge while deploying a Call Center based on the CISCO UCCX Version 11.5 feature set. Generally, we employ DNIS as a strategy for defining the CSQ service parameters. The more specific you can make the inbound number, the less you will need to "prompt and collect" digits from your caller. A call to a specific DNIS number can separate the English callers from the other language options, or route "customer service" differently than routing "technical support". DNIS is always a preferred routing strategy. Using DNIS we can design a single call routing script that can pull in the CSQ name; offer up the proper audio menu's; provide unique queue handling options and customize the caller experience all based on the dialed number. In this centralized scheduling application for a large national medical practice, patients would call a local number in their community. This number was then forwarded by the carrier to a toll free number that rang into the centralized CISCO cluster and UCCX call center. The issue was setting up the dial peers to address the number the caller dialed, not the toll free number. These numbers terminated on a SIP trunk that was serviced by a CISCO CUBE and the number presented was the 10 digits of the toll free number. The DNIS number, or the number that the caller originally dialed may or may not be buried in the TO field of the incoming SIP headers.Solution - Step 1 Debug Captures of inbound SIP messages
We need to setup "debug ccsip messages" and "debug voice ccapi inout" and make some test calls. We need to understand how the carrier is handling the forwarded number. In the log output below we can see the INVITE is the 877 toll free number. The number that the caller dialed is the 9323646969 number and we can see that it is in the TO filed of the sip message headers. We will need to write a dial-peer,voice class uri, translation rule and profile that extracts the TO field and routes on that number rather than the original INVITE. It is the "voice class uri" that is most magical in this solution. (Note that we got luck here and the carrier was handling the call forwarded number in a manner that was appropriate to our goals. This however is not always the case)!
Solution Step 2 "Voice Class URI"
In this example, the caller is dialing 93236453XX which is being call forwarded to the toll free 877 number and shows up in the sip headers in the TO field. The solution here is to create a "voice class uri" rule. In the snippet below we can see "voice class uri 102 sip" with a "user-id of 9323645323" as an example. We are going to ultimately want to translate this to a four digit extension number 5323 and this is done with the traditional translation rules. In this example "voice translation rule 102" does this conversion. Note however that the translation rule refers to a match on the 877 toll free number, not the 9323645323 number. This is where the magic of "voice class uri", the ability to do dial-peer matching based on the uri. The Voice Class uri is structured such that it has a unique TAG and then a matching expression or host IP address. The the snippet below we can see two attemtps to setup up a uri filter based on the last digits in the TO field of the SIP header. Tag 102 looks to match 5323 and tag 103 looks to match 5324: