We've Moved! Please visit our new and improved forum over at our new portal: https://portal.plumvoice.com/hc/en-us/community/topics

How do I loop audio messages for the fetchaudio property?

Questions and answers about IVR programming for Plum DEV

Moderators: admin, support

Post Reply
shoeman
Posts: 12
Joined: Fri Oct 17, 2003 2:46 pm

How do I loop audio messages for the fetchaudio property?

Post by shoeman »

I need to play a "Please wait" audio message while a url is hit on the back end of our Plum IVR system. Here is the code snippet

Code: Select all

<subdialog srcexpr="ivrJsp" name="validateRx" namelist="rxNumber choppedCardHolderNumber">
<audio expr="waitValidation">Please wait while we verify your refill request.</audio>
			<filled>
                           <if cond="validateRx.phoneNumber == 'empty'">
                          <prompt><audio expr="rxInvalidPrompt">The prescription number you entered is either not valid or has no refills left.  Please hold for a customer service representative.</audio></prompt>
                     <goto next="#trySavRxQueueTransfer"/>
                        <else/>
                        <assign name="customerPhoneNumber" expr="validateRx.customerPhoneNumber"/>  
                        <log> Validation successful for rxNumber. <value expr="document.rxNumber"/></log>
                        </if>
			</filled>
		</subdialog>
The above code just plays one "wait" message but sometimes there can be a 20 second delay or so and our clients would like a "still waiting" message played every 5 seconds or so. Any idea how to do this?

support
Posts: 3632
Joined: Mon Jun 02, 2003 3:47 pm
Location: Boston, MA
Contact:

Looping audio messages may be on future IVR platforms

Post by support »

Currently there is no way to programmatically loop audio messages for fetchaudio.

The only option currently available is to use a fetch audio file reference that is much longer than the amount of time you expect the operation to take. For example, if the submit operation will typically take 10-30 seconds, make your audio file 1 minute long, to lessen the chances that the entire file will be played.

This approach is somewhat of a double edged sword in that it carries both advantages and drawbacks:

a drawback: you must edit the audio file by hand which can be time consuming, and the file will take up significantly more space since you arent looping the message.

an advantage: the audio message can be tailored to include additional information or content.

future versions of the plum IVR platform may include a looping capability but it is not yet a consideration.

sincerely,

Plum Support
Last edited by support on Fri Jan 15, 2010 6:43 pm, edited 2 times in total.

shoeman
Posts: 12
Joined: Fri Oct 17, 2003 2:46 pm

more clarification needed

Post by shoeman »

I have a few questions:

1) Are you proposing making a long audio file with the same message repeated several times inside the file with breaks in between?

2) Why must the file be much longer than the proposed wait time for the submit to return? Is this just to insure that it covers all of the wait time?

3) Will the complete audio file play ever time? Or will the audio file stop playing once the submit return, i.e, once the filled portion of the code is ready to execute?

support
Posts: 3632
Joined: Mon Jun 02, 2003 3:47 pm
Location: Boston, MA
Contact:

IVR platform clarifications

Post by support »

To clarify your IVR questions:

1) Yes, that is what we are proposing. Since there is no way to loop a fetchaudio reference, you would have to create the audio file by hand (ie inserting "please wait while your data is posted" or whatever message you want every 5 seconds)

2) The file does not necessarily have to be longer than the estimated amount of time required to successfully complete the IVR submit; it's merely a recommendation to decrease the likelihood of a user being presented with silence.

3) This is a good question, since we are not sure of the exact behavior. The behavior you describe is probably the most common sense mode of operation, but it has not been verified. You might try constructing a small vxml sample that tests this premise.

Post Reply