Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Integration of Definity with generic (vendor independent) IVR platform
IVR
First we should understand that any IVR platform, including Avaya IR and older Conversant, are, for all that matters, standalone devices. There is no "hidden proprietary link" that allows us to plug IVR into Definity and provide all call center functionality with some magic trick. All IVR platforms are equal from the Definity point of view and use all the same methods of integration.
Have said this, I should mention that there is only two methods at all, first is an extension emulation and the second is trunking between devices. Second I did mention only for full picture presentation, it is very limited in means of call processing and should be avoided when possible. Since all call processing is done via standard vector mechanism, using trunks prevents us from doing many useful things, because all we can do with a trunk group is to route a call into it using route-to command. If this command succeeds, we lose all control over this call, it is removed from all split/skill queues and processing is done only on the IVR side. Of course, an IVR can return us control after processing is done (by routing this call back into the trunk) but it does us no good: system will treat is as a new call with all statistics started anew, not minding locking up at least two trunks between the Definity and IVR (unless there's a Q.Sig used between both systems and I don't know any IVR that could do that much of Q.Sig to support path replacement). Overall, trunking between Definity and IVR is no good and should be avoided.
Now to the preferred method. To have all call center functionality applied to the IVR we should present it as a group of extensions acting as a live agents. First, the physical part.
Physical connection could be any of three: analog stations, analog station emulation over DS1 or IP stations.
Analog stations I won't describe here, it is all understood. Allocate some analog extensions off TN793 board or alike, plug 'em into IVR, define 'em as VRU (or 2500 if you don't have VRU codes) type stations, all done.
DS1 stations are more interesting. Though these are pretty standard OPX (Off-Premises Extensions) stations, there are almost no documentation on how to setup the DS1 board. Hence I will provide working settings for E1 and some example for T1 (since I'm not in U.S. and do not know T1 closely).
DS1 circuit pack settings for E1:
[tt]
DS1 CIRCUIT PACK
Location: 01A01 Name: Conversant
Bit Rate: 2.048 Line Coding: hdb3
Signaling Mode: CAS
Interconnect: pbx Country Protocol: 1
Interface Companding: alaw CRC? y
Idle Code: 01010100
Slip Detection? y Near-end CSU Type: other
[/tt]
As you can see, the quick resume is: set it to standard E1 (2048 bit rate, HDB3 line coding), assign it CAS signaling with interconnect to PBX and country protocol may vary depending on IVR platform. These settings I have used with Avaya IR, for other devices you may have to change them.
DS1 circuit pack settings for T1:
[tt]
DS1 CIRCUIT PACK
Location: 01A01 Name: Conversant
Bit Rate: 1.544 Line Coding: ami-zcs
Signaling Mode: CAS
Interconnect: pbx Country Protocol: 1
Interface Companding: mulaw CRC? y
Idle Code: 01010100
Slip Detection? y Near-end CSU Type: other
[/tt]
Again, I'm not completely sure about these settings so reader should suppose these are more like guidelines. Depending on the IVR, line coding may be either b8zs or ami-zcs, b8zs is preferred if it is available. All other settings are the same as for E1 (except companding, of course) because we don't want much, just an off-premises analog station emulation.
After setting up DS1 board, we should create several (the exact number depends on available channels in IVR) stations with type VRUFD (if you have VRU tones) or DS1FD. Assign these stations B-channel numbers in your DS1 as port numbers and check if they're up. They should if there's a physical connection between IVR and Definity, since this type of stations do not have any signaling other than basic call offer.
VoIP integration is done with H.323 type stations, there's not much to say about it, other than this kind of integration requires CTI for passing any kind of information to IVR. It is strange but there is VRU station type for analog and DS1 but none for VoIP, and generic H.323 does not allow passing any DTMF digits to extension (it's an extension, after all).
Finished with physical part, we should go to the logical. The main idea, I repeat, is to present the IVR ports as live agents, with small exception: Definity knows these are not live agents but IVR and if converse-on command is used it treat them so.
To use our pack of stations, we should create a hunt group. It can be either split or skill, it does not matter really because we shouldn't bother with overloading IVR ports, using them fairly and so on. If you want to track your IVR ports in CMS like agents, you should use skill and assign every IVR port an agent-login id. If not, we can go on with simple split.
Typical IVR hunt group settings are these (first page):
Group Name: whatever you like
Group Extension: whatever fits your dial plan
Group Type: ucd-mia
ACD: yes
Vector: yes
Second page:
AAS: yes
Measured: depends on reporting system used
Controlling Adjunct: depends on CTI integration.
As you can see, the main two settings that you should set to yes are ACD and AAS (Auto Available Split). Vector also should be set to yes if you plan to use this split with converse-on command in vectors -- and in most cases you do, otherwise why bother?
Now put your physical extension numbers in this hunt group and voila, you have your IVR interface. At this point you may as well try to place some calls to this group's extension and check from the IVR side whether it receives call setups or not. It wouldn't hurt to assign these lines some kind of test application either.
With auto available agents, the picture becomes more complicated, but not too much. A skill cannot be auto available and it can't have any fixed members. So we should create agent-loginids for IVR channels just like any other agents, then don't forget to set AAS field on the first page to yes and fill the appeared Port Extension field with the physical extension number. Typically one would make sure the agent login-ids and physical extension numbers are sequenced, just to avoid unneeded complications. Assign these agents the skill number of our IVR skill and voila. The work on setting up our IVR connection is done.
Have said this, I should mention that there is only two methods at all, first is an extension emulation and the second is trunking between devices. Second I did mention only for full picture presentation, it is very limited in means of call processing and should be avoided when possible. Since all call processing is done via standard vector mechanism, using trunks prevents us from doing many useful things, because all we can do with a trunk group is to route a call into it using route-to command. If this command succeeds, we lose all control over this call, it is removed from all split/skill queues and processing is done only on the IVR side. Of course, an IVR can return us control after processing is done (by routing this call back into the trunk) but it does us no good: system will treat is as a new call with all statistics started anew, not minding locking up at least two trunks between the Definity and IVR (unless there's a Q.Sig used between both systems and I don't know any IVR that could do that much of Q.Sig to support path replacement). Overall, trunking between Definity and IVR is no good and should be avoided.
Now to the preferred method. To have all call center functionality applied to the IVR we should present it as a group of extensions acting as a live agents. First, the physical part.
Physical connection could be any of three: analog stations, analog station emulation over DS1 or IP stations.
Analog stations I won't describe here, it is all understood. Allocate some analog extensions off TN793 board or alike, plug 'em into IVR, define 'em as VRU (or 2500 if you don't have VRU codes) type stations, all done.
DS1 stations are more interesting. Though these are pretty standard OPX (Off-Premises Extensions) stations, there are almost no documentation on how to setup the DS1 board. Hence I will provide working settings for E1 and some example for T1 (since I'm not in U.S. and do not know T1 closely).
DS1 circuit pack settings for E1:
[tt]
DS1 CIRCUIT PACK
Location: 01A01 Name: Conversant
Bit Rate: 2.048 Line Coding: hdb3
Signaling Mode: CAS
Interconnect: pbx Country Protocol: 1
Interface Companding: alaw CRC? y
Idle Code: 01010100
Slip Detection? y Near-end CSU Type: other
[/tt]
As you can see, the quick resume is: set it to standard E1 (2048 bit rate, HDB3 line coding), assign it CAS signaling with interconnect to PBX and country protocol may vary depending on IVR platform. These settings I have used with Avaya IR, for other devices you may have to change them.
DS1 circuit pack settings for T1:
[tt]
DS1 CIRCUIT PACK
Location: 01A01 Name: Conversant
Bit Rate: 1.544 Line Coding: ami-zcs
Signaling Mode: CAS
Interconnect: pbx Country Protocol: 1
Interface Companding: mulaw CRC? y
Idle Code: 01010100
Slip Detection? y Near-end CSU Type: other
[/tt]
Again, I'm not completely sure about these settings so reader should suppose these are more like guidelines. Depending on the IVR, line coding may be either b8zs or ami-zcs, b8zs is preferred if it is available. All other settings are the same as for E1 (except companding, of course) because we don't want much, just an off-premises analog station emulation.
After setting up DS1 board, we should create several (the exact number depends on available channels in IVR) stations with type VRUFD (if you have VRU tones) or DS1FD. Assign these stations B-channel numbers in your DS1 as port numbers and check if they're up. They should if there's a physical connection between IVR and Definity, since this type of stations do not have any signaling other than basic call offer.
VoIP integration is done with H.323 type stations, there's not much to say about it, other than this kind of integration requires CTI for passing any kind of information to IVR. It is strange but there is VRU station type for analog and DS1 but none for VoIP, and generic H.323 does not allow passing any DTMF digits to extension (it's an extension, after all).
Finished with physical part, we should go to the logical. The main idea, I repeat, is to present the IVR ports as live agents, with small exception: Definity knows these are not live agents but IVR and if converse-on command is used it treat them so.
To use our pack of stations, we should create a hunt group. It can be either split or skill, it does not matter really because we shouldn't bother with overloading IVR ports, using them fairly and so on. If you want to track your IVR ports in CMS like agents, you should use skill and assign every IVR port an agent-login id. If not, we can go on with simple split.
Typical IVR hunt group settings are these (first page):
Group Name: whatever you like
Group Extension: whatever fits your dial plan
Group Type: ucd-mia
ACD: yes
Vector: yes
Second page:
AAS: yes
Measured: depends on reporting system used
Controlling Adjunct: depends on CTI integration.
As you can see, the main two settings that you should set to yes are ACD and AAS (Auto Available Split). Vector also should be set to yes if you plan to use this split with converse-on command in vectors -- and in most cases you do, otherwise why bother?
Now put your physical extension numbers in this hunt group and voila, you have your IVR interface. At this point you may as well try to place some calls to this group's extension and check from the IVR side whether it receives call setups or not. It wouldn't hurt to assign these lines some kind of test application either.With auto available agents, the picture becomes more complicated, but not too much. A skill cannot be auto available and it can't have any fixed members. So we should create agent-loginids for IVR channels just like any other agents, then don't forget to set AAS field on the first page to yes and fill the appeared Port Extension field with the physical extension number. Typically one would make sure the agent login-ids and physical extension numbers are sequenced, just to avoid unneeded complications. Assign these agents the skill number of our IVR skill and voila. The work on setting up our IVR connection is done.