Script Goes Silent!?

[TBarrnes]

I have a script that sometimes plays through the wait loop ok and other times just goes silent. Some times I'll hear my vm_vs 3 times and other times it won't even play it once without going silent and the call just sitting in "no man's land". I did about 30 test calls while watching the Call Pilot Channel Monitor to make sure that the voice ports aren't getting all used up and that doesn't seem to be an issue. Would there be any other reason why the script would behave differently each time? I've pasted the script below.



QUEUE TO SKILLSET Test_Sk
WAIT 2

GIVE MUSIC moh_gv

GIVE RAN ran_1

SECTION wait_two_loop

WAIT 10



WAIT 5

OPEN VOICE SESSION
PLAY PROMPT VOICE SEGMENT vm_vs
COLLECT 1 DIGITS INTO vm_choice_cv INTER DIGIT TIMER 2
END VOICE SESSION

WHERE vm_choice_cv EQUALS
VALUE 1: ROUTE CALL 3333
DEFAULT: EXECUTE wait_two_loop
END WHERE

 

[DancingDave]

I'd look closely at Call Pilot. Perhaps one of the channels is faulty.

Have you tried a systematic test out of hours so you can see if the fault occurs on particular channels?

DD

 

[dulfo666]

Also put a wait statement after the GIVE MUSIC

 

[nortelinsd]

I agree with dulfo666 put a wait in between the Give statements.

QUEUE TO SKILLSET Test_Sk
WAIT 2

GIVE MUSIC moh_gv

WAIT 2

GIVE RAN ran_1

If a tree hugger falls in the woods...who cares?

 

[TheWorkingMan]

Change the Give music and Ran around. Also change the two wait values to one.

QUEUE to Skillset blah_blah
WAIT 2

GIVE RAN ran_we_really_care
GIVE MUSIC really_boring

SECTION never_leave

WAIT 16

See what you think!
TWM

 

[Milesprower]

This could be a resource issue. Does the RAN always play, does music always play? If there is contention for either, you will hear silence.

I agree with suggestion to put music after the RAN.

Break this into two test scripts: the first up to the RAN, the second just playing the voice segment. See if the fault can be localized to one or the other test script.

The suggestion above concerning bad access port(s) is a good one. Run the IVR Port Statistics report to make sure all ports are answering calls equally. (You can also look at the IVR real time display to see if the call treatment is failing). If one port shows little or no activity, then turn you attention to replacing the card it is on.

Finally, if you want to bullet-proof your script, look into the Event Handler advanced script command. It will allow you to recover from some call treatment failures and also can be used for troubleshooting.