[cisco-voip] UCCX 7.0 acript with call redirect get please try again after entering menu option 1

[Anthony Holloway]

I see that you said your issue is now resolved, however I wanted to offer
some thoughts I had after reading over your post.

You stated that the response back from the IVR was "Please try again"
however you have nothing but End steps under your branches of the Redirect
step.  This tells me that the "please try again" came from something other
than the failed transfer, otherwise the End step, which is present under
all branches, would have resulted in the famous "I'm sorry, we are
currently experiencing system problems..."

My best guess is that the Menu was, at some point, lacking the association
of the label 1 to the actual input 1.  This happens to me all the time when
I'm creating menus.  I get busy typing in the labels, and forget to click
the button associated to the input value.  Especially, just like you did, I
type the value into the label.

>From the MIVR logs, I can see that you press 1 on your phone three times in
the first call, and not once does the transfer event even attempt to
happen.  Additionally, I can see a lot of DTMF 1's coming through on a
subsequent call.

Output truncated
....
641750: Jul 09 14:27:21.369 PDT %MIVR-SS_TEL-7-UNK:CallID:202
MediaId:5383/1 Task:15000000069 Digit received: 1
641751: Jul 09 14:27:22.775 PDT %MIVR-SS_TEL-7-UNK:CallID:202
MediaId:5383/1 Task:15000000069 Digit received: 1
641752: Jul 09 14:27:24.197 PDT %MIVR-SS_TEL-7-UNK:CallID:202
MediaId:5383/1 Task:15000000069 Digit received: 1
641753: Jul 09 14:27:25.431 PDT %MIVR-SS_TEL-7-UNK:CallID:202
MediaId:5383/1 Task:15000000069 Digit received: 1
641754: Jul 09 14:27:26.384 PDT %MIVR-SS_TEL-7-UNK:CallID:202
MediaId:5383/1 Task:15000000069 Digit received: 1
641755: Jul 09 14:27:27.322 PDT %MIVR-SS_TEL-7-UNK:CallID:202
MediaId:5383/1 Task:15000000069 Digit received: 1
641756: Jul 09 14:27:28.400 PDT %MIVR-SS_TEL-7-UNK:CallID:202
MediaId:5383/1 Task:15000000069 Digit received: 1
641757: Jul 09 14:27:29.478 PDT %MIVR-SS_TEL-7-UNK:CallID:202
MediaId:5383/1 Task:15000000069 Digit received: 1
641758: Jul 09 14:27:30.353 PDT %MIVR-SS_TEL-7-UNK:CallID:202
MediaId:5383/1 Task:15000000069 Digit received: 1
641759: Jul 09 14:27:31.196 PDT %MIVR-SS_TEL-7-UNK:CallID:202
MediaId:5383/1 Task:15000000069 Digit received: 1
641760: Jul 09 14:27:31.837 PDT %MIVR-SS_TEL-7-UNK:CallID:202
MediaId:5383/1 Task:15000000069 Digit received: 1
641761: Jul 09 14:27:32.353 PDT %MIVR-SS_TEL-7-UNK:CallID:202
MediaId:5383/1 Task:15000000069 Digit received: 1
641762: Jul 09 14:27:32.821 PDT %MIVR-SS_TEL-7-UNK:CallID:202
MediaId:5383/1 Task:15000000069 Digit received: 1
641763: Jul 09 14:27:33.259 PDT %MIVR-SS_TEL-7-UNK:CallID:202
MediaId:5383/1 Task:15000000069 Digit received: 1
641764: Jul 09 14:27:33.571 PDT %MIVR-SS_TEL-7-UNK:CallID:202
MediaId:5383/1 Task:15000000069 Digit received: 1
641765: Jul 09 14:27:33.837 PDT %MIVR-SS_TEL-7-UNK:CallID:202
MediaId:5383/1 Task:15000000069 Digit received: 1
641766: Jul 09 14:27:34.055 PDT %MIVR-SS_TEL-7-UNK:CallID:202
MediaId:5383/1 Task:15000000069 Digit received: 1
641767: Jul 09 14:27:34.290 PDT %MIVR-SS_TEL-7-UNK:CallID:202
MediaId:5383/1 Task:15000000069 Digit received: 1
641768: Jul 09 14:27:34.555 PDT %MIVR-SS_TEL-7-UNK:CallID:202
MediaId:5383/1 Task:15000000069 Digit received: 1
641769: Jul 09 14:27:34.821 PDT %MIVR-SS_TEL-7-UNK:CallID:202
MediaId:5383/1 Task:15000000069 Digit received: 1
641770: Jul 09 14:27:35.149 PDT %MIVR-SS_TEL-7-UNK:CallID:202
MediaId:5383/1 Task:15000000069 Digit received: 1
641771: Jul 09 14:27:35.493 PDT %MIVR-SS_TEL-7-UNK:CallID:202
MediaId:5383/1 Task:15000000069 Digit received: 1
641772: Jul 09 14:27:35.883 PDT %MIVR-SS_TEL-7-UNK:CallID:202
MediaId:5383/1 Task:15000000069 Digit received: 1
641773: Jul 09 14:27:36.227 PDT %MIVR-SS_TEL-7-UNK:CallID:202
MediaId:5383/1 Task:15000000069 Digit received: 1
641774: Jul 09 14:27:36.540 PDT %MIVR-SS_TEL-7-UNK:CallID:202
MediaId:5383/1 Task:15000000069 Digit received: 1
...

This further proves my theory that the problem was with your Menu step, and
missing the mapping.  Otherwise, the call would have hit the Redirect step
and failed at the transfer, and no more 1's could have been sent.

Also, we should all get into the habit of turning on the MIVR ENG Debugging
trace level, as this puts each step of the script right into the log file.
 With this turned on, you would have clearly seen that the Redirect step
was never being executed.

If you have an older copy of this script, you can check the properties on
the menu, but if not, then I guess this one will be attributed to FM.

Happy scripting Jason!

-Anthony

On Mon, Jul 9, 2012 at 5:29 PM, Jason Aarons (AM) <
jason.aarons at dimensiondata.com> wrote:

> Attached screen shot and MIVR log file, I’m not spotting the problem. Does
> it even try to transfer to 1 based on MIVR log?****
>
> ** **
>
> Dialed CTI Route Point 2410, hear my prompt in the menu, select option 1,
> call redirect to 4001 and hear “Please try again”.  The 7965 is 4001 in the
> none partition, so it should not be a CSS issue.  The CTI Port has access
> to Transcoder as 4001 is across WAN/G729, and UCCX is G.711 ulaw.  I can
> manually dial 4001.****
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20120709/d3617d5d/attachment.html>