" /> Avaya-related GVP/CTI problem - Genesys CTI User Forum

Author Topic: Avaya-related GVP/CTI problem  (Read 5424 times)

Offline MarcRobinson

  • Jr. Member
  • **
  • Posts: 62
  • Karma: 0
Avaya-related GVP/CTI problem
« on: December 26, 2007, 03:00:03 PM »
Advertisement
If there's anyone out there who's an Avaya 8720 expert, maybe you can help me. Here's my problem:

We have two call centers. Some 800-number calls go to one, and some to the other, depending on where a call originated. We're upgrading the PBX at one call center from a G3 to an 8720; the other call center already has an 8720. We have one T-Server and one GVP talking to the new PBX that will be going in service soon; we're testing with this, while continuing to run the G3 (and a T-Server and GVP with it) for production. When we test the new 8720, because it is not hooked up to AT&T yet, we have to place calls via the remote PBX (at the other call center). These test calls get backhauled via a trunk group to the new PBX. When the call comes into the new PBX, it gets answered by the GVP, but the application then hands the call back to the PBX, to be transferred to the floor (i.e., to a customer service agent).

The reason appears to be that the application can't handle the weird DNIS string passed from the remote PBX. Instead of the proper 4-digit number, the value passed is "IVR Test800 255". So the GVP shrugs its shoulders and hands the call back to the PBX.

In anticipation of an obvious question, I do have the "Default DNIS" set, and that value is in the DNIS map for the application -- though come to think of it, I'm not sure this is much good, since the string's so weird that the VPM might give up anyway.

I'm sure there's a setting in the remote 8720 that controls the DNIS string, but we haven't been able to find anyone in Avaya yet who can help us. Has anyone out there had a similar problem, and if so, what's the solution?

Thanks.

IanDS

  • Guest
Re: Avaya-related GVP/CTI problem
« Reply #1 on: January 04, 2008, 11:27:41 AM »
HI, What type of trunks (ETSI ISDN, QSIG, analogue)do you have between the two Pabx's and signalling?

Can you attach the logs of the two tsevers as well as the trunk group, signalling group and DS1 board settings.
You may also want to do a list trace xxx xxx  in th switch to check whats happenning in the switch.

I would say the DNIS you are seeing is the CCT name of the DS1 extension connecting to GVP.




Offline Chattguy

  • Newbie
  • *
  • Posts: 9
  • Karma: 0
Re: Avaya-related GVP/CTI problem
« Reply #2 on: January 04, 2008, 08:15:06 PM »
You may be able to verify that by using remote access DN and then entering the  4 digit DNIS.  We use the remote access for testing our remote sites and the URS logs will show the DNIS of the number you enter after the barrier code.

Offline Daimonas

  • Full Member
  • ***
  • Posts: 106
  • Karma: 2
  • There's a fish in every bowl.
Re: Avaya-related GVP/CTI problem
« Reply #3 on: January 04, 2008, 08:44:27 PM »
This DNIS is very common when transferring a call between switches and there is not much you can do on the Avaya side to avoid it. I am sure there is a way but I never bothered to figure it out......

Your solution would be to attach the DNIS as user-data to the call and setup external routing between GVP and your switches. Therefore, when the switch transfers the call to GVP using external route point, the user-data will be preserved. You would then need to configure GVP to get the DNIS based off the user-data.

Alternatively, you could pass the DNIS to GVP using the script feature in Router. All this does is attaches user-data key called "Script" with the value specified as the key. GVP doesn't care what this value is; you just need to define where it gets it from.

You may need to setup a default script for GVP, so it handles these types of calls and routes it to the correct script based on the user-data.
« Last Edit: January 04, 2008, 08:46:41 PM by Daimonas »

Offline MarcRobinson

  • Jr. Member
  • **
  • Posts: 62
  • Karma: 0
Re: Avaya-related GVP/CTI problem
« Reply #4 on: January 17, 2008, 08:55:10 PM »
Sorry for the delay, but I was out sick for quite a while, and had to get caught up when I got back to work. We found a way to get it to send the 4-digit VDN instead of the weird string, and I wish I could tell you what it was, but I can't because I didn't understand the explanation the telecom people gave me. One thing we did for a while was to rename the VDN -- we made the name identical to the actual 4-digit VDN value. This was a temporary workaround. It may have been something to do with event notification for adjuncts, or maybe we pointed the calls to use a pre-existing VDN that we already knew worked. That's all I know, really. Thanks for the assistance; sorry it took so long to get back to here.

vlg711

  • Guest
Re: Avaya-related GVP/CTI problem
« Reply #5 on: January 23, 2008, 12:49:40 AM »
What type of trunks connect the two PBXs? I'm assuming ISDN is it also a  DCS network?

vlg711

  • Guest
Re: Avaya-related GVP/CTI problem
« Reply #6 on: January 23, 2008, 12:51:41 AM »
One more question.. Is the GVP standalone or are you also using the framework?

Offline MarcRobinson

  • Jr. Member
  • **
  • Posts: 62
  • Karma: 0
Re: Avaya-related GVP/CTI problem
« Reply #7 on: January 23, 2008, 02:13:05 PM »
Somehow I caused this post, which I solved a long time ago, to reappear.

Please ignore it -- do not reply. The problem is solved.