Configuration of Periphonics IVR on Avaya Platform

[Ariadne]

I was given the task of figuring out how to setup a Periphonics IVR (currently in use on a Nortel system) on the Avaya S8700 Version 2.1 software.

In the Nortel system, I keep hearing that the channels? are setup as Agents and that I need to do the same. Does anyone have experience with this?!

 

[4merAvaya]

Is the Periphonics using analog ports or a T-1 connection to the Nortel?

Kevin

 

[DAVIDPAYNE]

More then like that is correct. If you are using a converse-on statment to send the calls to the IVR then you will need to setup the DS-1 card as rob-bit, you will then assign station to each channel, and auto login agent to each of those channels.

 

[Ariadne]

I was told that they are attached to analog ports.

 

[4merAvaya]

Each channel (analog port) would be connected to an analog port in the Definity. The analog ports would be members of an ACD hunt group. There would be a lead number to access the hunt group. The hunt group can be configured to distribute traffic uniformly over all members or to always start with the first member. You will also need an DID analog line for the dial-up modem to maintain the Periphonics.

Kevin

 

[TelcoMarseille]

hello,

did you have documentation to how to configure Periphonics IVR with AVAYA S8700?

because we have a Nortel IVR VPS/IS 9000E IVR and we don't know how to configure it with all the Avaya stuff.


Nic

 

[sjw3140]

Hi,

Do you need to pass calls out to an agent from the VPS ? And does the Agent need to know what port on the VPS they came through on ?

Regards

Steve.

 

[rbordeaux]

Hi all, I hope you still check this thread as it has been a while since it has been posted. Could you tell me how you did the Avaya-Periphonics IVR integration? If you used trunks or just defined an DS1 with each port as an extension? I am interested in being able to send the UCID/DNIS/CLI to the IVR.

 

[nohuhu]

rbordeaux,

first, to deploy ivr (never mind what vendor's) in a call center environment, it is best to use converse-on command in a vector. to do this, you should first set up a physical connection between the ivr and the pbx, using analog lines or ds1 analog emulation with ds1fd type stations. then you should create a hunt group with type ucd-mia, assign it as an auto-available split and put these stations into hunt group. then you can use this split in the vector with converse-on command. you can pass up to two parameters to your ivr with dtmf codes, these can be either fixed digit string or "ani" (incoming call ani), "vdn" (active vdn number), "digits" (any digit string collected with collect digits command), "qpos" (queue position in a nonconverse split/skill), "wait" (expected wait time for a nonconverse split/skill) or A to Z are vector variables if you have them. to pass any additional data including ucid you need to use cti integration. i'm not sure whether periphonics understand asai/cvlan/tsapi, you should clarify it with nortel guys.

 

[rbordeaux]

Thanks dwalin, the configurtion you mention is working at the moment and I was thinking of trying another approach. Setting up an ISDN trunk between the two systems, my idea is set up a normal ISDN trunk and send the calls in the vector to an extension that when looked in the ars table will look for a route pattern asociated with the created trunk. The dnis/cli will be sent by default on the isdn fiels, the ucid maybe will go on the uuinfo field (not sure, I remember several years ago in another company being able to set that field with the pressed digits). Maybe my idea is complete wrong, but if I can and my boss gives me enough time to play with it I will try to configure. I am currently using CTI but to be honest I don't like it as if the network fails the tserver goes down or something else I loose the dnis and cli.

 

[nohuhu]

rbordeaux,

first, you can't set up your ivr as an isdn trunk. appealing idea, i must admit, but you just can't. because you can't set definity to route your calls to an isdn trunk without losing control of 'em. to not lose control, you should queue them to an ivr split, and to have that split you should make that your ivr ports appear as a physical extensions, not a trunk. and that leads us to the approved scheme of ds1fd stations (or analog ones, doesn't matter), auto available split or a skill with auto available agents. sorry, that's life.
as for increasing robustness of the cti link, you can do that with cm3 and application enablement services, using duplicated links and high availability servers.