Caller Input during Post Greeting Recording (Unity Connection)?

[stephan.steiner]

Hi

Is there any way to get caller input to work during a post greeting recording? It appears that caller input is only active during a greeting (both in user and call handler)

Cheers

Stephan

[lindborg]

no, by design - you can see the release notes for when the feature was added (8.x) for a fuller run down on what the feature is targeted at: http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/connection/8x/release/notes/802cucrn.html#wp648707

since it's meant for legal warnings (i.e. what not to leave in a message such as trading details and confidential info) the post greeting recording can't be skipped or interrupted - which means no user input options. 

[stephan.steiner]

Jeff

Nice to see you here as well :)

So that basically means if you need a greeting (or anything that is allows user input) that is the same for a large number of users, there's no way other than simply upload the same greeting a gazillion times thus giving up manageability :( It's sad that Unity is that complex, yet can't manage something that simple.

How'd you go about doing this: The greeting should be "Hi, <user's recorded Name> is not available. You can press 0 to get the Operator, or leave a message after the beep". The message needs to be localized (according to the Mailbox language), and it needs to be a studio recording (the customer provides this). Is there really no way to stitch a pre Name and post Name greeting together?

[lindborg]

So let me make sure I have this.

1. The system greeting which is pretty similar what you want isn’t going to cut it?  This has the user’s recorded voice name and is studio recorded and is localized automatically based on the user’s mailbox language setting.  It doesn’t mention the 0 out option however.
2. You want to have some custom greeting play for each user (presumably the “Hi, <users name> is not available>”) followed by a shared customized greeting that gets tacked onto the end?  How, exactly, were you going to do this with the post greeting recording (assuming it would allow caller inputs during its playback)?  Walk me through this… how were you going to get it to say exactly what you have here using that construction?  There is no way… not with the user’s voice name in there – you would have to have a short prefix greeting for each user followed by the shared post greeting recording.  Still end up with something custom somewhere.

As falling off a chair simple and obvious as you think this option should be (I’ve been in the VM business for about 24 years now – I know of no systems with an off the shelf capability you describe here so I assuming we’re all a tad slow) I don’t see how to produce what you want here without some seriously customized greeting construction capability tuned specifically for this case (i.e. a customer that wants a automatically constructed system greeting that is different than the one provided already but made with prerecorded component(s) they provide instead).  That system greeting is actually a full conversation – not just a canned recording – it’s pretty sophisticated (i.e. falling back on TTS for names if a recording isn’t found, using extensions if you indicate voicing names is not OK and the like).

Best I can suggest is to use the system greeting construction which gets you most of what they want (recorded voice name and localization included) – if they need a higher degree of customization and control and don’t want users recording their own greetings you will need to do your own – not exactly sure how you’re going to do that with user’s voice names embedded in them easily without getting pretty sophisticated with a fetch and merge operation though…

[stephan.steiner]

1) I realize it's almost standard - yet, no, the customer wanted their own recorded message (they already have that from their previous voicemail system).

2) This is how we got it to sound just right for the customer, except that we couldn't press 0 anymore. Standard system greeting with user recorded name in the mailbox (I believe they're using the standard system greeting - at least that's how the mailbox itself is configured). Then instead of deposit the message, the call goes to a call handler (so one call handler per mailbox), which plays no greetings, but plays the shared post greeting recording. Then there's the beep and you can record the message which gets deposited into the proper mailbox. That all works except that no input is accepted during the post recording greeting. I can also fully provision this scenario using the CUPI API.

As for the rest - you may have guessed that I'm coming at this from a programming angle. And from that angle, and looking what voicemail systems I know of do in terms of greetings, a system that combines prerecorded and self-recorded parts seems the obvious solution. After all, the standard greeting is done similarly.. you have some TTS, then a recorded name, then another TTS part. So it can already combine. I'd imagine that the little computers we all carry in our pockets have enough power to do something like this.

And, being a programmer, things run DRY so that's what I have such a hard time accepting I need to do something that goes completely against that principle - and I know I'm going to regret it even today. One day somebody will have the idea "oh let's change those greetings, we have an expensive provisioning system so it's just two clicks, right".. and I'm going to look at them wide eyes and tell them, no, every mailbox carries their own wave file (or actually, call handler in this case - we're going with the solution I described above, just that I add the WAV greeting instead of the post greeting recording).

Anyway, the last few paragraphs are just musing - there's nothing that will change and things unfortunately are as they are. Maybe when Unity Connection was designed, stitching multiple WAV files together was too computationally complex, who knows.

[lindborg]

So…. Why the need for the separate call handler in the first place?  Users have a post greeting recording (users have a call handler called a “primary call handler” behind them already) so you can just use that and then take the message – the need for a separate call handler seems unnecessarily complex… I’ll see your DRY and raise you a KISS.

I’ll ignore the passive aggressive “maybe it was too complex” silliness – I laugh. 

All you want is the ability to have an option to enable user input during a post greeting recording (meaning by definition it can be interrupted).  It’ll have to be configurable since the folks that asked for that absolutely don’t want that to be the default.  Doable, but work – work costs money and takes resources from other revenue generating efforts.  So it’ll need to go on the backlog and get prioritized along with everything else – as such the best I can suggest is to put in a feature request with your account team and they’ll get it on the PO’s list.

There might be a way to do this via ODBC reusing the stream file reference ID for a standard greeting – it most definitely can’t be done via REST, however.

[stephan.steiner]

Hmmm.. that is an interesting idea and would get rid of a lot of code I've written (what a pain it was..). But, I think I'd then still have to do a lot of mods on that callhandler as it's not exposed in the admin GUI (or is it and I'm just not seeing it)? There's some caller input mapping that needs to be defined at least. Or is there a way to include that in the user template? I expect that my customer will want to mess with the call handler in some way (they usually come up with ideas that you didn't foresee... like input during post recording, or change the default greeting while keeping the recorded name).

All will be for naught if I can't get my records to be played back though.. despite conversion using your .NET lib, the default recordings keep playing.

[lindborg]

tested and I can use an existing recording stream (either a regular recorded greeting or a post greeting recording - either works) and copy that
stream file reference to as many greetings across as many users or handlers as I like - I just created 5 handlers that have an alternate greeting
enabled that all play the same post greeting recording.  The bad news is if you rerecord the recording it generates a new stream file id (it doesn't
replace the existing one, rather it creates a new one and the old one gets cleaned up over night).  Update your recording and you have to update your handler's greetings stream file reference to match.

used ODBC and csp_greetingstreamfilecreate (or modify if it's already got one)- pass in the objectID of the handler, greeting type, language and the streamfile ID from above rinse, lather repeat for all your secondary call handlers - plays back as a normal stream (allowing user input) and is identical across all call handlers/users.

Still skeptical on your path - the prompt wording does not match what you said you wanted.  If they're using the system generated greeting for users it'll sound like this:

"sorry, Jeff Lindborg, is not available.  Record your message at the tone, when you are finished hang up or press # for more options."

not seeing what you tack onto the end there to produce what your first post said you wanted.