Announcement before the Phone ringing - CUCM 12.5

[Abdull_Cisco]

Dears,

I need your support to find out if there is a way where I can paly an announcement before the phone ringing in CUCM 12.5 saying that " call is recorded for quality purposes"

I have found one way using unity which I need to make two extensions in the same phone where the first one is permanently forwarded to unity and the second is receiving forwarded calls from unity after greeting is played..

Is there a way not using unity or using it without the need of two extortion on the same phone. 

Thanks 

[Roger Kallberg]

Usually this kind of announcement for recordings would be handled by the system that does the recording.

[Abdull_Cisco]

Yes it should be done from the recording system but unfortunately the recording system I use does not provide this service. I am trying to find a way I can do it from the CUCM

[Roger Kallberg]

AFAIK there is no way to do this natively in CM.

[b.winter]

As @Roger Kallberg said, either do it on the recording system or as you mentioned, use CUC for it. Using CUC is also the way I would do it, since it's the easier way.

There would also be an option in CUCM.

Short version: Upload the file as an MoH file and use it as queuing MoH in the hunt pilot settings. This hunt pilot has a hunt list assigned, that has no line group members. With the routing option in the hunt pilot, you can then forward the call to the destination you want.

But I wouldn't do this solution.

[Abdull_Cisco]

Thank you all for your reply. As mentioned CUC is the available option we can use specially if the extension is not a part of hunt list. However, it would be a bit messy in my case as I need to make two extension per device to play the recording message as I mentioned above. 

[Elliot Dierksen]

I assume this is strictly for calls from the outside. Is that the case? I did something like this for a customer a long time ago. The CSS of the inbound gateway contained only an 'XXXX' pattern that was forwarded to a CCX application that played a disclaimer message. The CSS of the CTI ports was able to call the native DN of the phones, and it transferred the call to the original destination after the disclaimer was played.

[Abdull_Cisco]

Thank you for your reply. In fact, it is for both outside and inside calls. The extensions are from different sections and I cannot put them in a group using a hunt group or even use CCX Applications..  

[Elliot Dierksen]

OK, why not? It appears that CUCM doesn't do this natively, so you don't have any options besides some more creative ones. Do you not have CCX or are you ruling that out for some reason?

[Abdull_Cisco]

Thank you for your reply..

In fact, I have UCCX but I cannot use as theses extensions are not for call center agents as well as they are not in one group. 

[Elliot Dierksen]

Yes, you can use UCCX because what I was describing doesn't make those people agents. It just front ends an application that plays a message and then transfers the calls. The key is who the partitions can calling search spaces are set up. The way I describe this does assume that you do not have voicemail on these extensions because the way this is set up would break MWI. That can resolved by changing the CSS for the Unity SIP trunk/voicemail ports.

In this set up, regular phones are in the INTERNAL partition. Recorded phones are in the RECORDED partition. The forwarding would be done in the REDIRECT partition. A call is placed to extension '1234'. '1234' is a translation pattern in INTERNAL that doesn't change the called party, but has a CSS that looks only at the REDIRECT partition. There is a CTI route point that has a single DN in the REDIRECT partition of 'XXXX' that is call forward all to the DN of the CTI route point with the application that plays the prompt (non-interruptible play prompt step). The CSS of the CTI ports has to include the RECORDED partition. After playing the message, the application which has played the prompt looks at the values from the Get Call Contact Info to see the original called party. It does a Call Redirect step to that original called party and that users phone rings. If that extension has voicemail, the Unity CSS needs to include the RECORDED partition first. That would mean calls transferred from Unity would bypass the message, so I would say you shouldn't have voicemail for those extensions.

[Nithin Eluvathingal]

What recording software you use ?  If you are using Imagicle, it can play this announcement.

2.12.0.0

[PTS]

Site engineers can checkout below 3rd party solution for this kind of requirements ( Play out Call Recording Warning / Announcements )
MARS Agent Greeting :
https://developer.cisco.com/ecosystem/cpp/solutions/181073/
https://www.youtube.com/watch?v=DBFV8m-IfjE

Play out a call recording announcement. If the call is being recorded by any call recording application then the "Recording announcement" played out by Parsec's application will be present in the call recording file.

For more details you can write to info@parsec-tech.com

[Maren Mahoney]

If this applies to a small number of extensions, you could set up a hunt pilot with native call queuing (with the announcement set to "Play announcement before routing to Hunt Member"), and the single extension in the line group and a long ring no-answer timer. Set the "When no hunt members answer" to go to voicemail. If the underlying hunt pilot number is the same digit string as the extension, Unity Connection will use the dialed string (which is the same for the hunt and for the dn) to find a voicemail box.

This is obviously not extensible to more than a few numbers.

Maren

[JasonCallTelemetry]

There is Cisco native way to policy inject greetings without changing any callflow at all. Callmanager even comes with a factory greeting "your call may be monitored or recorded" greeting to play under Media Resources, Announcements, that you can request to play before a call connects.

The feature is through the CURRI API, and I wrote a compatible CURRI API server (Calltelemetry.com), that is free for basic policy and greeting injection. Let's cover what CURRI is, and how it works.

CURRI is the API behind the "External Call Control Profile" option found on extensions, translations, and route patterns. 

The CURRI server is a http server that will accept these web hook requests from CUCM and return your preferred call policy instructions (like a greeting injection, block/permit). And If the CURRI server is not available for some reason, the call just passes through. Injecting in this does not change callflow like hunt pilots/uccx/unity, and if it fails, the call just proceeds normally as a fallback. No media comes from CURRI either, it comes from CUCM's Media Resource Announcements.

If you’re into making your own web app, here’s the API Documentation with full examples.

https://developer.cisco.com/site/curri/documents/latest-version/

If you’d like to try the Call Telemetry CURRI server, it is completely free for policies and greeting injection, with more features available in paid versions.

I also made a youtube video showing the entire setup of a greeting injection of "you call may be monitored or recorded" in just 3 minutes.

https://youtu.be/NR7Gcqo78M4

-Jason