In the "real" world you probably have tools that you have grown accustom to using. I have a set that I discuss in a UC Toolkit series hosted on the NetCraftsmen site. Unfortunately, you won't have access to 3rd party tools and will need to make do with the inherent capabilities of the UC applications in the blueprint.
There are a variety of ways to address the need. I have played around with a few options and I figured I would share my approach. Just in case someone else may find it useful.
The first order of business is to identify the instances where you may be required to create a recording:
UCCX IVR Prompts
I think the best approach is to leverage UCCX to record prompts that you will use for UCCX scripts. You can do this easily by adding a new script to the script repository. This script only needs to have two steps (I use three):
To use the Recording Step, create a variable of type Document. We aren't going to use this variable per se. It is only needed to ensure the interpreter doesn't error out when encountering the Recording Step during script execution. Using this "bare bones" script, we are sort of taking a shortcut.
In a production recording script, you would have a prompt guiding the user, a way to review the prompt, possibly a way to re-record the prompt, and some post processing of the prompt. We don't need all of that warm and fuzzy stuff to get a usable audio file. We just need to take advantage of the fact that when the Recording Step is encountered in a CRS script, a temporary audio file is stored locally on the UCCX server.
The folder that stores the temporary file is on the UCCX server. The full path will be: "C:\Program Files\wfavvid\Temp\".
Uploading Prompts
Sometimes you will find two files created by your script in the temp folder. Pick the larger of the two, rename, and then upload to your prompt repository using the application administration web portal (http://<ccxserverIP>/appadmin).
Once you upload the prompt to the repository, you can access it from other scripts as you would any other user prompt.
Some pointers:
BACD IVR Prompts
The Cisco Unified Basic Automatic Call Distribution (BACD) is exactly what its name implies: a basic (very basic) ACD tool. The application scripts that provide the BACD functionality come built into the IOS. You can also load the TCL scripts from flash memory. What you will have when you sit for the lab is anyone's guess. Be prepared for both.
Whether you are running the embedded TCL scripts or loading them from flash, the prompts must be in flash. When you look at the files in flash (e.g. show flash | i .au) you should see a healthy set of files that are associated with the various prompts that are presented by the BACD application. A good listing of what to expect is provided here.
Recording the Prompts
Unlike UCCX, the BACD implementation has no way of recording prompts. That is not a problem because the method described for UCCX will create a file that is compatible with the prompt formats used by the BACD application. So, you can use the same method described for UCCX to record prompts for BACD.
Uploading Prompts
The next logical question is: how do I get the file to the BACD host?
Well, you have choices. You can go by way of CUCM (TFTP) or you may be able to use FTP. The latter would assume that an FTP server is provided to you in the lab. I can't really guarantee one will be there for you or that you would have the ability to upload files from UCCX to the FTP server. So, let's go the TFTP path, even though it is the least efficient of the two options. The steps:
Considerations
You have limited flexibility when naming the audio prompt you are using with BACD. Remember, it is basic - real basic. You should read through this Cisco document now. As described in the link provided, the name of prompt files should always start with a field which indicates the language. For the IE lab, that will likely be "en_".
Further, If the prompt name is (or can be) specified by a parameter variable (e.g. param welcome-prompt or param drop-through-prompt) then you can use any file name (as long as it starts with the proper language designator). All other prompts must use the exact name as defined in the link referenced above.
The prompt that is created by our UCCX script ends in .wav. So, how do we convert it to the .au format? Easy, rename the file and change the extension from .wav to .au. IOW, there is no need to convert the file encoding.
If you have loaded your BACD scripts (under application service) and you have re-recorded named prompts, then you will need to refresh the prompt. If the prompt in question is the welcome prompt or the drop through prompt, then you could simply TFTP the file with a different name and then modify the parameter pointing to the recorded file accordingly. If you have to change one of the other prompts then you can try the audio-prompt load command, for example:
SiteC-RTR#audio-prompt load flash:/bacdprompts/en_bacd_welcome.au
If the above doesn't replace the default prompt with your re-recorded prompt then you may need to reload the router.
Unity Connection Greetings
- UCCX IVR prompts
- BACD IVR prompts
- Unity Connection subscriber, call handler, or directory handler greetings
- Unity Express subscriber or attendant greeting
When I first started to look at the options, I went through a couple of CCIE-V forums to see what methods other folks were using. There appears to be a mix. Some people say they use UCCX to create prompts and others go the path of using Unity Connection. I suppose it comes down to what you are most comfortable with. The methods I prefer are outlined below. Again, this is just what works for me.
UCCX IVR Prompts
- Accept Step. Under Contact palette in CRS editor
- Recording Step. Under Media palette in CRS editor
- Terminate Step (optional). Under Contact palette in CRS editor
To use the Recording Step, create a variable of type Document. We aren't going to use this variable per se. It is only needed to ensure the interpreter doesn't error out when encountering the Recording Step during script execution. Using this "bare bones" script, we are sort of taking a shortcut.
In a production recording script, you would have a prompt guiding the user, a way to review the prompt, possibly a way to re-record the prompt, and some post processing of the prompt. We don't need all of that warm and fuzzy stuff to get a usable audio file. We just need to take advantage of the fact that when the Recording Step is encountered in a CRS script, a temporary audio file is stored locally on the UCCX server.
The folder that stores the temporary file is on the UCCX server. The full path will be: "C:\Program Files\wfavvid\Temp\".
Uploading Prompts
Sometimes you will find two files created by your script in the temp folder. Pick the larger of the two, rename, and then upload to your prompt repository using the application administration web portal (http://<ccxserverIP>/appadmin).
Once you upload the prompt to the repository, you can access it from other scripts as you would any other user prompt.
Some pointers:
- Create a custom application in UCCX to load your recording script. Associate a trigger that doesn't conflict with the dial plan the proctors have imposed on your lab.
- For optimal audio quality, use a phone that is associated with a Region that is permitted to use G.711 when communicating to the Region assigned to the UCCX telephony group.
- The default timeout for the recording step is 10 seconds. If you need to record a prompt longer than 10 seconds then modify accordingly.
BACD IVR Prompts
The Cisco Unified Basic Automatic Call Distribution (BACD) is exactly what its name implies: a basic (very basic) ACD tool. The application scripts that provide the BACD functionality come built into the IOS. You can also load the TCL scripts from flash memory. What you will have when you sit for the lab is anyone's guess. Be prepared for both.
Whether you are running the embedded TCL scripts or loading them from flash, the prompts must be in flash. When you look at the files in flash (e.g. show flash | i .au) you should see a healthy set of files that are associated with the various prompts that are presented by the BACD application. A good listing of what to expect is provided here.
Recording the Prompts
Unlike UCCX, the BACD implementation has no way of recording prompts. That is not a problem because the method described for UCCX will create a file that is compatible with the prompt formats used by the BACD application. So, you can use the same method described for UCCX to record prompts for BACD.
Uploading Prompts
The next logical question is: how do I get the file to the BACD host?
Well, you have choices. You can go by way of CUCM (TFTP) or you may be able to use FTP. The latter would assume that an FTP server is provided to you in the lab. I can't really guarantee one will be there for you or that you would have the ability to upload files from UCCX to the FTP server. So, let's go the TFTP path, even though it is the least efficient of the two options. The steps:
- Create the recording using the recording application you created on UCCX (see previous section)
- Rename the .wav file (see considerations below)
- Load web browser on the UCCX server, browse to the CMPlatform portal on the CUCM publisher (https://cucmIPAddress:8443/cmplatform), and upload the new audio file to the TFTP repository
- Go to UCM serviceability page on CUCM and restart the TFTP service
- On the CME host, copy the audio file to the local flash (e.g. copy tftp://10.3.120.10/en_bacd_options_menu.au flash:/bacdprompts/)
- If the prompt you are changing is something other than the welcome prompt or the drop through prompt, then you will need to reload the prompt (see the Considerations below).
You have limited flexibility when naming the audio prompt you are using with BACD. Remember, it is basic - real basic. You should read through this Cisco document now. As described in the link provided, the name of prompt files should always start with a field which indicates the language. For the IE lab, that will likely be "en_".
Further, If the prompt name is (or can be) specified by a parameter variable (e.g. param welcome-prompt or param drop-through-prompt) then you can use any file name (as long as it starts with the proper language designator). All other prompts must use the exact name as defined in the link referenced above.
The prompt that is created by our UCCX script ends in .wav. So, how do we convert it to the .au format? Easy, rename the file and change the extension from .wav to .au. IOW, there is no need to convert the file encoding.
If you have loaded your BACD scripts (under application service) and you have re-recorded named prompts, then you will need to refresh the prompt. If the prompt in question is the welcome prompt or the drop through prompt, then you could simply TFTP the file with a different name and then modify the parameter pointing to the recorded file accordingly. If you have to change one of the other prompts then you can try the audio-prompt load command, for example:
SiteC-RTR#audio-prompt load flash:/bacdprompts/en_bacd_welcome.au
If the above doesn't replace the default prompt with your re-recorded prompt then you may need to reload the router.
Unity Connection Greetings
There are a couple of options that can be used to create recording in Unity Connection. One option is to use the Media Master plugin that is available from the web browser. An alternative option is to use the TUI. There are a couple of variations on how you would use the TUI, based on what you are trying to do.
Personally, I am not going to bother with the Media Master approach for the lab. I have never been a fan. I also have no idea if the browser on the candidate workstation has the appropriate plugins. I suppose you could fall back to using UCCX if you prefer this method. I don't, so I am going to focus on the TUI.
For call handler greetings, I use the Greetings Administrator (CUGA). To use CUGA, you basically have two ingredients. First, you need to pick a subscriber to be the owner of the call handler.
Second, you need to provide a method to access the CUGA conversation. There are a variety of approaches:
Step 4. Create a user (or use an existing user) that has permissions to record prompts.
Personally, I am not going to bother with the Media Master approach for the lab. I have never been a fan. I also have no idea if the browser on the candidate workstation has the appropriate plugins. I suppose you could fall back to using UCCX if you prefer this method. I don't, so I am going to focus on the TUI.
For call handler greetings, I use the Greetings Administrator (CUGA). To use CUGA, you basically have two ingredients. First, you need to pick a subscriber to be the owner of the call handler.
Second, you need to provide a method to access the CUGA conversation. There are a variety of approaches:
- Custom Keypad Mapping on a subscriber mailbox
- Go to Tools > Custom Keypad Mapping > Pick a mapping to edit
- Pick a keypad mapping that you likely won't need in the lab (like Option 6 "List Meetings" or Option 7 "External Email") and change it to Greeting Administrator
- Apply the Custom Keypad Mapping to one of the mailbox users by editing the Phone Menu options for the user
- Now you can dial into voice mail from the subscriber phone, log in, and choose the option you assigned to the CUGA conversation
- A caller input option on the Opening Greeting
- Similar to the custom keypad mapping
- Edit the Opening Greeting call handler caller input options and add an option that loads the Greetings Administrator conversation
- If you call into voicemail from a directory number with a mailbox on the system, simply enter "#" at the login prompt to get to the Opening Greeting. Then enter the CUGA option
- If you call into voicemail from a directory number without a mailbox then you are sent to the Opening Greeting by default
- Routing Rules
- Create a Direct or Forward routing rule that looks for an appropriate trigger (ANI, DNIS, or RDNIS) and directs the caller to the Greetings Administrator conversation
- If using Direct routing rules, use a translation pattern in CUCM to transform the calling party number to match the routing rule
- If using Forward routing rules, use a dummy CTI route point to CFA to Unity Connection. Assign a directory number on the CTI that matches the routing rule
Unity Express Greetings
Like Unity Connection, Cisco Unity Express (CUE) has a prompt management application. Of course, it isn't what I would call "robust" but, nevertheless, it does exist. You can provision this application from the GUI or from the CLI. .
It is worth noting that you can upload prompts to CUE and you can access the CUE admin GUI from UCCX. So, using UCCX to create the recording and uploading it to CUE is an option.
Going Native...
It is worth noting that you can upload prompts to CUE and you can access the CUE admin GUI from UCCX. So, using UCCX to create the recording and uploading it to CUE is an option.
Going Native...
My walk through is focused on the CLI approach. The GUI may be more preferred by some/most.
Step 1. Telnet to the router hosting the CUE AIM or network module. Easy enough.
Step 2. Session to your CUE AIM or network module. In my lab, I am using an AIM slot so I session to the CUE as follows: ser ser 0/1 sess
Step 3. Configure the trigger. We are going to configure a SIP trigger (4699) that will launch the prompt management application (which is a pre-built application that you can see in the running config).
SC-CUE# conf t Enter configuration commands, one per line. End with CNTL/Z. SC-CUE(config)# ccn trigger sip phonenumber 4699 Adding new trigger SC-CUE(config-trigger)# application "promptmgmt" SC-CUE(config-trigger)# enable SC-CUE(config-trigger)# maxsessions 1 SC-CUE(config-trigger)# end trigger
SC-CUE(config)# username myrecuser create SC-CUE(config)# username myrecuser phonenumber 4698 SC-CUE(config)# groupname promptmgrs create SC-CUE(config)# groupname promptmgrs member myrecuser SC-CUE(config)# groupname promptmgrs privilege ManagePromptsStep 5. Configure credentials for the prompt recording user (if creating a custom user).
SC-CUE(config)# exi SC-CUE# username myrecuser pass cisco SC-CUE# username myrecuser pin 12345
Step 6. Now, call the prompt management application trigger (4699 in our example) and record your prompt.
Step 7. After the prompt is recorded, you can see the prompt name by using the show ccn prompts command. You can also see prompts from the GUI (System > Prompts).
Step 8. We aren't done yet (isn't this fun?!?). We need to specify that we should use the new prompt instead of an existing one. For instance, let's say we want to change the prompt for the auto attendant application. The following would do the trick.
Step 7. After the prompt is recorded, you can see the prompt name by using the show ccn prompts command. You can also see prompts from the GUI (System > Prompts).
Step 8. We aren't done yet (isn't this fun?!?). We need to specify that we should use the new prompt instead of an existing one. For instance, let's say we want to change the prompt for the auto attendant application. The following would do the trick.
SC-CUE#show ccn prompts ----- SNIP ------------ Name: UserPrompt_10112012021339.wav Language: en_US Last Modified Date: Thu Oct 11 02:13:39 BST 2012 Length in Bytes: 39738 SC-CUE#conf t SC-CUE(config)#ccn application autoattendant aa SC-CUE(config-application)#parameter "welcomePrompt" "UserPrompt_10112012021339.wav"
Note that the example provided is for a CUE system that is integrated with CME. If you were building a trigger for a CUCM integration then you will need a JTAPI trigger. If enabling a trigger for CUCM and SRST mode then you need both a SIP and a JTAPI trigger. The following is an example of an auto attendant config for a CUE system that is integrated with CUCM with an option to run the attendant in SRST mode.
ccn trigger jtapi phonenumber 4610 application "autoattendant" enabled maxsessions 6 end trigger ! ccn trigger sip phonenumber 4610 application "autoattendant" enabled maxsessions 6 end trigger ! ccn application autoattendant aa description "autoattendant" enabled maxsessions 6 script "aa.aef" parameter "busClosedPrompt" "AABusinessClosed.wav" parameter "holidayPrompt" "AAHolidayPrompt.wav" parameter "welcomePrompt" "cue-autoattendant.wav" parameter "disconnectAfterMenu" "false" parameter "dialByFirstName" "false" parameter "allowExternalTransfers" "false" parameter "MaxRetry" "3" parameter "dialByExtnAnytime" "false" parameter "busOpenPrompt" "AABusinessOpen.wav" parameter "businessSchedule" "systemschedule" parameter "dialByExtnAnytimeInputLength" "4" parameter "operExtn" "0" end application
By now, you are probably thinking that going the path of the GUI would be easier. You would probably be right. You can do all of this via the GUI (with or without involving UCCX). You can provision the prompt management application, configure a group with the appropriate permissions, dial into CUE and create the prompt, and then select the prompt to use from the CUE admin GUI.
I am not going to walk through the GUI version of the method described above. Instead, I am going to jump to using UCCX.
Going UCCX...
As noted, you can also upload prompt files from the CUE GUI. You can do this from System > Prompts or from within an application config page (e.g. Voice Mail > Auto Attendant). This means that you can use the method described for creating prompts in UCCX and upload these prompts to CUE.
To upload prompts created in UCCX, do the following:
Step 1. Create the recording script in UCCX and use it as already described.
Step 2. Rename the recorded file to something you can easily recognize. The name doesn't matter to CUE.
Step 3. From the UCCX host, open a web session to your CUE host. You can upload prompts by going to System > Prompts (shown). You can also upload directly from an application edit page (see the next step).
Step 4. Associate the new recording to the application (e.g. Auto Attendant). Go to Voice Mail > Auto Attendant. If you have already uploaded the prompt, you can choose the prompt from the drop down options. You can also choose "Upload" to upload prompts here (i.e. skipping Step 3). Just note that after you upload, you will then need to select the prompt from the drop down list. At least, that has been my experience.
Considerations for CUE
Probably the most noteworthy consideration is that if you are using CUE integrated with CUCM then you will need to plan accordingly. Whenever I have tried to add something like Auto Attendant to a CUE-CME integration after the provisioning wizard, I had to reload CUE to get the CTI to register correctly. Actually, when doing a dry run for this blog I provisioned the auto attendant and CUE just reloaded on me. I am not a fan and I may be doing something wrong. At any rate, plan accordingly.
Thanks for reading. If you have time, post a comment!
To upload prompts created in UCCX, do the following:
Step 1. Create the recording script in UCCX and use it as already described.
Step 2. Rename the recorded file to something you can easily recognize. The name doesn't matter to CUE.
Step 3. From the UCCX host, open a web session to your CUE host. You can upload prompts by going to System > Prompts (shown). You can also upload directly from an application edit page (see the next step).
Step 4. Associate the new recording to the application (e.g. Auto Attendant). Go to Voice Mail > Auto Attendant. If you have already uploaded the prompt, you can choose the prompt from the drop down options. You can also choose "Upload" to upload prompts here (i.e. skipping Step 3). Just note that after you upload, you will then need to select the prompt from the drop down list. At least, that has been my experience.
Considerations for CUE
Probably the most noteworthy consideration is that if you are using CUE integrated with CUCM then you will need to plan accordingly. Whenever I have tried to add something like Auto Attendant to a CUE-CME integration after the provisioning wizard, I had to reload CUE to get the CTI to register correctly. Actually, when doing a dry run for this blog I provisioned the auto attendant and CUE just reloaded on me. I am not a fan and I may be doing something wrong. At any rate, plan accordingly.
Thanks for reading. If you have time, post a comment!
I had always created a second (String) variable named "filename" and marked it as parameter. Then I used a "write document" step under the successful path of the recording step.
ReplyDeleteSo it was easy for me to define a filename and storage path directly in the application managent on the uccx. For example I used C:\.wav. It was easier to me navigate to the root directory of C for uploading the prompts intead through all the sub directorys of the uccx program folder.