Disabling Ringback for SIP Dialer
During transfer to agent - This workaround is only applicable CUCM 8.5 and above.
History
I ran into a problem when deploying the UCCE 8.5 SIP Dialer ( Outbound Option ) in which during the customer hand-off to the agent generated a ringback (single ring tone) to the customer. Obviously this was not a desirable behavior as I like many others would instantly hang up if i answered the phone and heard it ringing ( personally not a fan of receiving robo dialer calls). As the Dialer functionality is a critical component of our contact center I needed to get this matter resolved.
Now any of you out there that have already deployed the SCCP (Skinny) Dialer are aware turning the ring back off is a simple 2 part task outlined on page 100 in the icm85otb.pdf (www.cisco.com/en/US/docs/voice_ip_comm/cust_contact/contact_center/outbound_option/outboundopti
on8_5/installation/guide/icm85otb.pdf). What you didn't know, and what the document did not tell you is that if you are deploying the SIP Dialer the activity outlined in that document simply will not work.
The Problem
SIP Dialer communicates directly with the outbound PSTN Voice Gateway (VG) , now in my network I have Cisco Unified Proxy Server (CUSP) in place to act a a central SIP Director and Load Distributor. Because the SIP Dialer sends an invite directly to the VG and the VG performs Call Progress Analysis (CPA) via local DSP's it does not quite understand that the SIP Dialer is a unique application server, the VG is a simple device and adheres to standards. Thus being the case when the SIP Dialer sends a Update or Re-Invite to hand the call off to your Agent via a different SIP call leg, it is going to treat the call just like any other sip call. After the VG sends the invite to your Cisco Communications Manager it is going to immediately send a 180 (Ringing) because the RFC standard mandates it to do so. So in this scenario the VG will receive the 180 and signal a ringback to the ISDN network translating into a RingBack tone.
No amount of disabling Annuciators or changing H225 User options will resolve this. However if you read further I will reveal the secret and an advanced but simple workaround.
The Solution
Not to waste any more of your time as I'm sure your ripping your hair out by now like I was. Your going to have to create a new SIP Trunk, why you ask, well I'm sure you do not want to disable the ring back for your normal ingress voice calls right ? Than would not present a pleasant customer experience (ie. Inbound call being delivered to an agent that may have stepped away would result in silence to the customer until the call RONA's).
Step 1 - Create a new SIP Security Profile
Since I wanted to completely isolate this traffic I created a separate SIP Security Profile and Spun up port 5062 (as 5060 and 5061 are designated for other voice applications) now I'm not entirely sure that this fix will work without it because I imagine its going to be hard for Communications manager to distinguish between two trunks if the packet is being sent to the same port (5060 Default) who knows you might even get an error message when attempting to build the new trunk using the same port as another trunk to the same destination.
Navigate to
Communications Manager GUI->System-> Security-> SIP Trunk Security Profile -> [Add New] or [Copy]
Step 2 - Create SIP Normalization Script
Normalization Script, What you say? Yeah I thought that too put TAC explained its purpose and its actually pretty powerful and cool at the same time. This is where the magic happens, we convert the outbound 180 "Ringing" message into a 183 "Session Progress" message ! Exciting I know, well if we never send the 180 to the VG then the VG will not generate the RingBack, hack job? Yes! But it will work !
Navigate to
Communications Manager GUI -> Devices -> Device Settings -> SIP Normalization Scripts -> [Create New]
Here is the text of the script that needs to be pasted into the " Content " of the Normalization Script ( to avoid typo's )
M = {}
function M.outbound_180_INVITE(msg)
msg:setResponseCode(183, "Session in Progress")
end
return M
Step 3 - Create Your New SIP Trunk
This should come easy to most of you by now, but if it does not do not worry, just copy your existing trunk and change the name ( i know there is no copy button!). When I say copy your existing trunk I mean reference the existing trunk when creating this one.
Now I use sip proxy and I think that UCM may squak (it shouldnt, but i didnt test it) if you create a second trunk with the same destinations and ports so I created a new network on my CUSP's listening on port .... you guessed it ' 5062 ' .
Next your going to need to modify the SIP Security Profile Field to reference the New SIP Trunk Security Profile you created.
Mine->
and reference your Normalization Script
Done! that was not to bad right ?
Well as I told you in the beginning I use SIP Proxies and I already have a key & route for my Agent Phones defined I can change that because as I told you I don't want my regular calls coming out of CVP Queues to not have a ringback to so I worked a little magic on my Voice Gateway. I translate the outgoing call for the SIP Dialer Agent Hand-off leg and prefixed 9006 to it ( dont worry I'll share the code ) before I send it to the SIP Proxy. This allows me to select a different route for these call transfers from SIP Dialer. And on my SIP trunk I set the significant digit field to 5 which matches my agent phone extension in the dialplan. This effectively strips off the key I crated and routes the call to the appropriate Agent Phone.
Translation rule on my VG's
voice translation-rule 10
rule 1 /3/ /90063/
^all my agent extensions start with a 3 which gets a key prepended to the # (ie 31234 = 900631234)
Translation Profile
voice translation-profile noRingBack
translate called 10
Agent Hand-Off Dial Peer
dial-peer voice 103 voip
description SIP-DIALER Agent Hand-off
translation-profile outgoing noRingBack <--- Adding the 9006 key here
destination-pattern 3....
signaling forward none
session protocol sipv2
session target ipv4:172.xxx.xxx.xxx <---- Sending to SIP Proxy (CUSP) here
voice-class codec 1
no vad
All done, I hope this document proves to be helpful, I wish it was out there when I started my SIP Dialer Build. . . . FYI TAC has a Documentation Bug open for Outbound Option to include this information.
UPDATE:
The Documentation bug ID is CSCtx43964
