Replace system prompts (CUC)

Unanswered Question
Oct 7th, 2009
User Badges:

How can I replace the system prompts in CUC with my own recordings? A trusted source tells me you can mount the CUC disk in a UNIX/LINUX environment and see the entire file system. (Note, I have not confirmed this, yet.) My source contends that with a bit of searching I should be able to find and replace any system prompt. I suspect there is an easier way, hopefully using the media master in some little known application.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
lindborg Wed, 10/07/2009 - 13:14
User Badges:
  • Cisco Employee,

Editing system prompts on Connection 2.x and later requires root access which is only given for TAC supported purposes - editing prompts for Unity and Unity Connection is not, never has and likely never will be supported.


There are no handy tools for this and pulling a stunt like mounting the disk will certainly put your system out of TAC support compliance! I wouldn't go there.


ncraven Wed, 10/07/2009 - 13:22
User Badges:

Allowing changes to system prompts seems inoffensive enough. I'm sure when you designed Unity you found good reason to restrict this. I'd be interested in your reasoning.

lindborg Wed, 10/07/2009 - 13:47
User Badges:
  • Cisco Employee,

Couple things - no major voice messaging system I've worked with in the last 20 years or so allows for editing of system prompts (greetings and voice names, yes, system prompts constructing phrases, no). Connection and Unity's custom key map for subscriber conversations is by far the most flexible piece of logic that approaches this in the field today.


I've answered this question numerous times out here - lots of folks assume they can harmlessly just hack and slash system prompts without breaking anything - in some cases you can - atomic prompts (i.e. completely self contained and conversation specific) are safe to edit. However many prompts are used in multiple phrases and changing/removing them can, and does, have unintended consequences. Which prompts those are often are language dependant (language "tokens" used to construct a phrase change in order, number and complexity from language to language).


anyway - here's a link to a recent answer:


http://forums.cisco.com/eforum/servlet/NetProf?page=netprof&forum=Unified%20Communications%20and%20Video&topic=Unified%20Communications%20Applications&topicID=.ee835d2&CommCmd=MB%3Fcmd%3Dpass_through%26location%3Doutline%40%5E1%40%40.2cd4091d/7#selected_message


But the short version is systems become unsupportable if customers can randomly change system conversation prompts. Most major voice messaging systems have this same restriction in place for largely the same reasons.

ncraven Wed, 10/07/2009 - 14:31
User Badges:

Thanks. Perhaps my answer lies in the choice of language.

dmotloch Tue, 10/13/2009 - 17:51
User Badges:

If we could get the "wait while I transfer your call" not to play EVER (no matter what) we'd never have to hack this.


I know on all users you can turn this off (check box), but Unity Connection 7.1 seems to ignore this on call handlers. So, for example if my call handler transfers to an extension I can't have the system do this without the "wait while I transfer your call" prompt being played. See attached examples.


HELP or we have to HACK.



Attachment: 
lindborg Tue, 10/13/2009 - 22:17
User Badges:
  • Cisco Employee,

The option to turn off the "wait while I transfer your call" is on the transfer rules for the call handler - if it's enabled and the rule is set to transfer (instead of going to the greeting) the checkbox for disabling the prompt is active - and works just fine. I just tested 7.1(3) and 8.0 EFT systems I have here...


(you don't have to threaten to hack your system to get help... but I'm curious to see how far you get hacking your system - anything's possible but I suspect the assumptions about what you can do mounting the file system are optimistic at best - tip: do NOT just delete prompts - the conversation will crash if you yank prompts phrase servers are expecting)

dmotloch Wed, 10/14/2009 - 03:24
User Badges:

Thanks for the reply Jeff -- I'll take a look at this and try it.


I didn't mean to threaten to hack for help!! :) And we haven't tried hacking due to the threat of no support!!! :)


We go live at the end of the month with nearly 7000 mailboxes. It's exciting stuff.

dmotloch Wed, 10/14/2009 - 14:57
User Badges:

I'm downloading 7.1(3) from CCO now to try -- 7.1(2) doesn't work as expected. Keep in mind we are adding a System Call Handler, then under Caller Input for say the 1 key, under action, transfer to alternate contact and then enter a valid DN -- no way to ask Unity to not be so rude with "Wait while we transfer your call" prompt. ;)


Derek.

lindborg Wed, 10/14/2009 - 17:32
User Badges:
  • Cisco Employee,

you mean you're using the caller system transfer conversation (i.e. free dialing)?


If so, it's easier to just check the option to allow this on the greeting - the user can "free dial" and if they match an extension it uses it, if not it'll do a transfer for it just like the system transfer without having to go into the separate number collection conversation. This can be enabled on a per greeting basis (i.e. allowed during the day but not at night for instance). It uses the same system transfer restriction table check of course...


Right off hand I don't think the system transfer conversation has a way to disable the transfer notification prompt, but I can check.

dmotloch Wed, 10/14/2009 - 18:58
User Badges:

I don't follow what you are trying to explain to me.


It's a number you dial (call handler) the standard greeting says "press 1 for this, press 2 for that and 3 for that."


Then under caller actions 1 is set to transfer to an extension (non-voicemail), so is 2 and 3.


I don't get the "free-dialing"? Let me know if I should send screen caps.


thanks!

lindborg Thu, 10/15/2009 - 13:45
User Badges:
  • Cisco Employee,

here's the link to the admin guide section on system transfers (both caller and user) that should probably do a better job than myself of explaining this:


http://www.cisco.com/en/US/docs/voice_ip_comm/connection/7x/administration/guide/7xcucsag115.html


If you have the 1 key mapped to a call handler set to dial a hard coded dial string (i.e. 5551234) than that's a different deal. Make sure the transfer rule on _that_ call handler has the option to turn the "please wait while I transfer your call" prompt disabled. This does work on all the versions I tested...

dmotloch Fri, 10/16/2009 - 07:15
User Badges:

I've tested this out.... and along the way I haven't explained it so you'd get what I mean.


If you create a call handler, and under caller input option 1 you select "Call Action" and in the drop down yhou select "Transfer to Alternate Contact Number" and in the Extension box you enter the extension (the extension is not a voice mail user, just a phone). There is no option to stop the "Wait while I transfer your call" from playing.


The work around is to create a call handler for the extension and deselect the option.


When migrating from Nortel's Meridian Mail we have MANY phone menus (press 1 for this guy, press 2 for this girl, etc.) -- so we have to create a LOT of call handlers to do the migration without "wait while i transfer yoru call"....


UNLESS: Cisco simply adds a check box on the caller action page when you select "Transfer to Alternate Contact number".....that would make live easier and a large account much happier.


Obviously the logic is there already, we just need the option to use it.


Derek.

lindborg Fri, 10/16/2009 - 12:38
User Badges:
  • Cisco Employee,

ah, I got you now. Well "simply" is in the eye of the beholder of course. I know it sure seems trivial and we're dragging our heels to be difficult but that's not the case. Both the alternate contact number and system transfers go through a different path than the call handler transfers (tons of logic for the supervised transfer with call screening/holding/interrupt logic with the visual clients is involved with the PHTransfer conversation used for call handlers - that has nothing at all to do with the other transfer paths). So it's not just a case of slapping a checkbox on the page and driving into the sunset. But of course isn't that always the way?


That said it's doable but not as part of an ES. The conversation team added it to the list for the 8.x follow on - it'll likely be a system wide setting for the subscriber/call system transfer conversation and show up on the user input page for the alternate contact number. DB changes, setup/upgrade scripts, conversation and admin folks will have work to do of course... it wont show up in a 7.x ES I can be nearly certain.


or you can talk TAC into getting root access to your box and replacing the prompt with a blank one for the time being ala Windows based system setups. That type of thing is above my pay grade (I can't generate root passwords for production systems either!)

dmotloch Sun, 10/18/2009 - 07:53
User Badges:

Thanks lindborg - the work around of replacing the prompt with a blank one will get us by until a release that will support removing this.


Actions

This Discussion