Mailing List Archive: Cisco: VOIP

Re: UCCX 7.0 acript with call redirect get please try again after entering menu option 1

Index | Next | Previous | View Threaded

mikeeo at msn

Jul 9, 2012, 3:45 PM

Post #1 of 6 (512 views)
Permalink

Re: UCCX 7.0 acript with call redirect get please try again after entering menu option 1

Sounds like a CTI CSS issue. I've run into problems where the CTI route
point can't see the dialed number do to a partition/CSS issue.

From: cisco-voip-bounces [at] puck
[mailto:cisco-voip-bounces [at] puck] On Behalf Of Jason Aarons (AM)
Sent: Monday, July 09, 2012 6:29 PM
To: cisco-voip (cisco-voip [at] puck)
Subject: [cisco-voip] UCCX 7.0 acript with call redirect get please try
again after entering menu option 1

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.

tycoononway1987 at gmail

Jul 9, 2012, 3:50 PM

Post #2 of 6 (479 views)
Permalink

Re: UCCX 7.0 acript with call redirect get please try again after entering menu option 1 [In reply to]

Han!!

The script looks and pretty simple. I hope i'm looking at the correct call
below?

So you're calling the trigger from 4001 and redirecting to 4001? Have you
tried calling the trigger from another number?

Line 29: 641111: Jul 09 14:18:55.344 PDT
%MIVR-ICD_CTI-7-UNK:EventHandler: posting {BEGIN_CALL_EVENT: Socket:Socket:
null monitoredDeviceDN:null, connectionCallID: 16782596, callType: 1,
connDeviceID: 2403, *ani: 4001*, dnis: 2410, dialedNumber: 2410,
callerEnteredDigits: null, callVar_1: null, callVar_2: null, callVar_3:
null, callVar_4: null, callVar_5: null, callVar_6: null, callVar_7: null,
callVar_8: null, callVar_9: null, callVar_10: null, wrapupData: null } to
outboundQ

What is the max calls and busy trigger setting on extension 4001?

- Gurpreet

On Mon, Jul 9, 2012 at 6:29 PM, Jason Aarons (AM) <
jason.aarons [at] dimensiondata> 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
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>

jason.aarons at dimensiondata

Jul 9, 2012, 4:24 PM

Post #3 of 6 (475 views)
Permalink

Re: UCCX 7.0 acript with call redirect get please try again after entering menu option 1 [In reply to]

The CTI Route Point had a <none> CSS and the 4001 was in <none>. Once I set a a dummy CSS on the CTI Route Point (it shouldn't have needed) the 4001 phone rang. I then put the CTI Route Point CSS back to none, working.

Go figure. I'm guessing CCM database needed a kick.

I guess it's why we don't see much7.0(1) anymore.....

From: Mike [mailto:mikeeo [at] msn]
Sent: Monday, July 09, 2012 6:45 PM
To: Jason Aarons (AM); 'cisco-voip'
Subject: RE: [cisco-voip] UCCX 7.0 acript with call redirect get please try again after entering menu option 1

Sounds like a CTI CSS issue. I've run into problems where the CTI route point can't see the dialed number do to a partition/CSS issue.

From: cisco-voip-bounces [at] puck [mailto:cisco-voip-bounces [at] puck] On Behalf Of Jason Aarons (AM)
Sent: Monday, July 09, 2012 6:29 PM
To: cisco-voip (cisco-voip [at] puck)
Subject: [cisco-voip] UCCX 7.0 acript with call redirect get please try again after entering menu option 1

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.

itevomcid

tycoononway1987 at gmail

Jul 9, 2012, 5:03 PM

Post #4 of 6 (469 views)
Permalink

Re: UCCX 7.0 acript with call redirect get please try again after entering menu option 1 [In reply to]

Hi Jason,

Good to know.

But it's the CTI Port's CSS needed to redirect the Call to the extension
4001. Once the call is answered in CCX, it's connected on the CTI Port and
since you're able to hear the prompts, the call was connected but the CTI
port was not able to redirect the call somehow.

You'd only need a CSS on CTI Route Point to blind transfer the call to the
CTI port. Must be glitch in the system.

Glad it's working for you.

- Gurpreet

On Mon, Jul 9, 2012 at 7:24 PM, Jason Aarons (AM) <
jason.aarons [at] dimensiondata> wrote:

> The CTI Route Point had a <none> CSS and the 4001 was in <none>. Once I
> set a a dummy CSS on the CTI Route Point (it shouldn’t have needed) the
> 4001 phone rang. I then put the CTI Route Point CSS back to none, working.
> ****
>
> ** **
>
> Go figure. I’m guessing CCM database needed a kick.****
>
> ** **
>
> I guess it’s why we don’t see much7.0(1) anymore…..****
>
> ** **
>
> *From:* Mike [mailto:mikeeo [at] msn]
> *Sent:* Monday, July 09, 2012 6:45 PM
> *To:* Jason Aarons (AM); 'cisco-voip'
> *Subject:* RE: [cisco-voip] UCCX 7.0 acript with call redirect get please
> try again after entering menu option 1****
>
> ** **
>
> ** **
>
> Sounds like a CTI CSS issue. I’ve run into problems where the CTI route
> point can’t see the dialed number do to a partition/CSS issue.****
>
> ** **
>
> *From:* cisco-voip-bounces [at] puck [mailto:
> cisco-voip-bounces [at] puck] *On Behalf Of *Jason Aarons (AM)
> *Sent:* Monday, July 09, 2012 6:29 PM
> *To:* cisco-voip (cisco-voip [at] puck)
> *Subject:* [cisco-voip] UCCX 7.0 acript with call redirect get please try
> again after entering menu option 1****
>
> ** **
>
> 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.****
>
>
>
> itevomcid ****
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip [at] puck
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>

avholloway+cisco-voip at gmail

Jul 9, 2012, 8:03 PM

Post #5 of 6 (476 views)
Permalink

Re: UCCX 7.0 acript with call redirect get please try again after entering menu option 1 [In reply to]

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> 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
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>

jason.aarons at dimensiondata

Jul 10, 2012, 7:41 AM

Post #6 of 6 (477 views)
Permalink

Re: UCCX 7.0 acript with call redirect get please try again after entering menu option 1 [In reply to]

It broke again, real culprit seems to be a Translation Pattern conflict with 4xxx. Will revisit again later today.

Sent from my Android phone using TouchDown (www.nitrodesk.com)

-----Original Message-----
From: Gurpreet Singh Kukreja [tycoononway1987 [at] gmail]
Received: Monday, 09 Jul 2012, 8:03pm
To: Jason Aarons (AM) [jason.aarons [at] us]
CC: Mike [mikeeo [at] msn]; cisco-voip [cisco-voip [at] puck]
Subject: Re: [cisco-voip] UCCX 7.0 acript with call redirect get please try again after entering menu option 1

Hi Jason,

Good to know.

But it's the CTI Port's CSS needed to redirect the Call to the extension 4001. Once the call is answered in CCX, it's connected on the CTI Port and since you're able to hear the prompts, the call was connected but the CTI port was not able to redirect the call somehow.

You'd only need a CSS on CTI Route Point to blind transfer the call to the CTI port. Must be glitch in the system.

Glad it's working for you.

- Gurpreet

On Mon, Jul 9, 2012 at 7:24 PM, Jason Aarons (AM) <jason.aarons [at] dimensiondata<mailto:jason.aarons [at] dimensiondata>> wrote:
The CTI Route Point had a <none> CSS and the 4001 was in <none>. Once I set a a dummy CSS on the CTI Route Point (it shouldn’t have needed) the 4001 phone rang. I then put the CTI Route Point CSS back to none, working.

Go figure. I’m guessing CCM database needed a kick.

I guess it’s why we don’t see much7.0(1) anymore…..

From: Mike [mailto:mikeeo [at] msn<mailto:mikeeo [at] msn>]
Sent: Monday, July 09, 2012 6:45 PM
To: Jason Aarons (AM); 'cisco-voip'
Subject: RE: [cisco-voip] UCCX 7.0 acript with call redirect get please try again after entering menu option 1

Sounds like a CTI CSS issue. I’ve run into problems where the CTI route point can’t see the dialed number do to a partition/CSS issue.

From: cisco-voip-bounces [at] puck<mailto:cisco-voip-bounces [at] puck> [mailto:cisco-voip-bounces [at] puck<mailto:cisco-voip-bounces [at] puck>] On Behalf Of Jason Aarons (AM)
Sent: Monday, July 09, 2012 6:29 PM
To: cisco-voip (cisco-voip [at] puck<mailto:cisco-voip [at] puck>)
Subject: [cisco-voip] UCCX 7.0 acript with call redirect get please try again after entering menu option 1

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.

itevomcid

_______________________________________________
cisco-voip mailing list
cisco-voip [at] puck<mailto:cisco-voip [at] puck>
https://puck.nether.net/mailman/listinfo/cisco-voip

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads