Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

IVR Not Using Label

We have an IVR application that was updated. There is an option where the ICM sends back a label to the IVR to transfer connect the call to a vendor's toll free number. On the IVR prompting leg that was changed by the programmers the label only works about 2 out of 10 calls now. On the IVR prompting leg they didnt touch the same exact ICM label works 100% of the time like it has for the last 5 years. So is there any way I can prove that the IVR isnt dialing the digits I am passing? I called AT&T and they think the IVR is doing an extra "*" before the *8800XXXXXX the ICM passes but the IVR programmer says it isnt. Any ideas appreciated...have a great week!!!

5 REPLIES
Anonymous
N/A

Re: IVR Not Using Label

The Normal label is a character string that encodes the instructions for routing the call. It contains either a directory number to which the Cisco IP IVR system should route the call or the name of a .wav file representing an announcement. If you configure the Cisco IP IVR system to send an announcement, the Cisco IP IVR system plays the .wav file, pauses for 2 seconds, and repeats the .wav file followed by the two second pause three additional times. Then it pauses 8 seconds and plays a fast busy signal until the caller hangs up.

New Member

Re: IVR Not Using Label

You mentioned the IVR application was "updated"...was it an upgrade? If so, double check the Calling Search Space of all 10 IVR ports to make sure they are correct. It could be that two of them are correct and the other eight are wrong. You might want to make sure the CTI Port group ID in the IVR matches the Peripheral ID of the Trunk Group in ICM.

If you have access the voice gateway that the IVR would pass calls across, you can do a debug to see what digits are being passed to AT&T.

>term mon

>debug isdn q931

are the commands in the voice gateway. Be sure to do "u all" when you are done debugging...it's not good to leave debugging on.

New Member

Re: IVR Not Using Label

You mentioned the IVR application was "updated"...was it an upgrade? If so, double check the Calling Search Space of all 10 IVR ports to make sure they are correct. It could be that two of them are correct and the other eight are wrong. You might want to make sure the CTI Port group ID in the IVR matches the Peripheral ID of the Trunk Group in ICM.

If you have access the voice gateway that the IVR would pass calls across, you can do a debug to see what digits are being passed to AT&T.

>term mon

>debug isdn q931

are the commands in the voice gateway. Be sure to do "u all" when you are done debugging...it's not good to leave debugging on.

New Member

Re: IVR Not Using Label

The IVR is an Intervoice brand IVR. Two things I found out:

1. AT&T wants 350 milliseconds between the *8 and the 800XXXXXXX. We have never done tht so I dont think that is the issue but AT&T wants us in compliance.

2. When the call comes in on an AT&T PACR term on their ARN platform we get failures trying to pass the call back to their network for transfer. When the call comes in on an AT&T PACR term witout ARN it works fine. So whatever our IVR programmers touched when they put in new options it messed up the communication with the ARN platform at AT&T that does transfer connects. The labels coming back from ICM are fine.

So that is where I stand now. For the PACR Term than does most of our transfer connects I replaced it with a non ARN Pacr Term and we are going OK now. I still need to get to the bottom of issue now. Thanks

New Member

Re: IVR Not Using Label

Took me 5 weeks but this issue has been deciphered...FINALLY!! The ICM tells the IVR to transfer connect the call to another site by signaling AT&T with a *8 followed by the toll free number at the remote location. The IVR gurus did an upgrade the end of October and all of a sudden the signals to AT&T started failing on some of our options. The IVR guys swore they didnt change anything but with the help of an AT&T tech I finally uncovered it last week. Before the transfer on some prompts the IVR says "this call may be monitored for quality purposes". Somewhere in that message AT&T is hearing a "*" so when AT&T hears a signal of **8 instead of *8 the call doesnt go anywhere. I had the IVR guy remove that message and bang everything worked. The newer AT&T transfer conect platform which they call ATP didnt have a problem with this but the older ARN platform picked up the extra "*" and the transfers never happened. So even though the IVR was getting the right ICM label and dialing the correct keystokes the message playing before the transfer was killing the signal.

186
Views
0
Helpful
5
Replies