Using generic IVR via converse-on command in vectors

Having our connection set up, now we can use it.
Using IVR is simple: you can either place a call to IVR hunt group's extension, queue call to this hunt group or use it via converse-on command in vectors.
Placing a call is trivial enough: a member of hunt group is chosen using default mechanism (depending on group type it can be ucd-mia, ucd-loa, ead-mia or ead-loa), a call is offered to this member which is an IVR port, the other side (IVR) get call alerting, answer this call and process it. Simple.
Queueing a call is almost the same: you can queue a call up to three splits/skills simultaneously, and in this case Definity will never be aware that IVR hunt group is an IVR and not a group of live agents. Default processing applies, nothing interesting.
The interesting part begins when we use converse-on command. Suppose that we have an example vector:
[tt]
01 queue-to split/skill x pri h
02 queue-to split/skill y pri h
03 wait-time 20 seconds hearing music
04 converse-on split/skill z pri l passing none and none
05 collect n digits
06 goto vector 1 if digits = 1
07 goto vector 2 if digits = 2
08 stop
[/tt]
Let's go over all commands to understand what every one of them does.
First two commands place a call in queue for two splits/skills: x and y with high priority. This way we can queue a call up to three splits/skill simultaneously. All right and proper.
Third command is used to avoid using IVR if a call's expected waiting time is too low. If you have expected-wait-time or predicted-wait-time algorithms (Call Center Elite and Advocate packages, respectively) you can route a call using these numbers to avoid IVR interaction, but here I won't explain doing it for the sake of simplicity. Just suppose that if our split/skill load is low enough for a call to be offered for an agent in less than 20 seconds, we will bypass IVR.
Note that this timeout is very important: since we consider IVR as a pack of analog stations (VoIP is a different matter and works much faster) we lose considerable time on call offering and answering on the IVR side. Depending on the amount of data we want to pass to our IVR, the call setup may take as much as 5 seconds or even more, but no less than 2 seconds. It may appear irrelevant but is not, since the main purpose of a call center is not in serving calls but in serving them effectively. Offering a call that IVR would not have time to answer means locking up our precious IVR ports meaninglessly. Also we should consider the length of IVR's first greeting message and set this wait-time timeout to be not less than this length plus IVR call setup time, otherwise a caller would hear silence (when IVR call is set up), then part of the phrase, then immediately a ringback tone being connected to an agent. It is wrong condition and should be avoided.
Now we're getting closer to the main part: converse-on command. This command works tricky way: effectively it places a call into IVR hunt group's queue (if it is enabled for this hunt group, and it may be) but does not count towards overall queue limit of three. So we can place a call into three queues for live agents and into fourth one to IVR hunt group. The second difference from ordinary queue-to command is that when a call is answered from IVR side, Definity will not drop it from all other queues and consider answered. Instead Definity will hold this call's place in all other queues, meanwhile opening a one-way connection to IVR port and, after passing any data we want it to pass, make this connection two-way to allow a caller to listen to whatever IVR has to play. Note that during passing digits a caller will hear dead air so it's in our interest to pass as few data as possible in DTMF form. After the two-way connection is established, Definity will keep track of this call's queue status with other splits/skills and if an agent in one of them becomes available and valid for this call, the IVR connection is dropped immediately and call is routed to an agent, providing ringback to a caller.
Note also that we can use the same priority levels with converse-on as with ordinary queue-to. This mechanism allows us to differentiate calls in case of IVR resource shortage.
Passing data to IVR is easy enough: the data is either static or dynamic. Static data we administer in the vector in the form of digit string (up to 6 digits, and they should have some meaning to IVR, of course), dynamic data is chosen from several pre-defined variables:
[ul]
[li]ani -- incoming call's ANI or CLID (depending on incoming trunk and so on)[/li]
[li]vdn -- effective VDN number (that is, the last VDN this call traversed over with VDN Override turned off)[/li]
[li]digits -- a digit string collected with previous collect digits command (could be ced/cdpd or Look-Ahead Digits)[/li]
[li]qpos -- this call's queue position in nonconverse split. Do not use this value if you queue a call to more than one split, because in this case qpos value would be completely meaningless.[/li]
[li]wait -- this call's expected wait time in nonconverse split. The same as qpos for multisplit calls.[/li]
[/ul]
Also, starting with CM 2.1.1, we could use Vector Variables and pass them to IVR, in this case setting "passing" field to variable name (A-Z).
And, of course, we can pass "none" and this means exactly that: none data. Note that "none" is always the last, i.e. if we pass something in first field we can set the second to "none", but if we set first to "none" we can't change second. Passing none and none is allowed, of course.
All data is passed in form of DTMF digits, without any padding or leading zeroes, finished with # sign, i.e. if we're passing qpos and wait, the resulting digit string that is outpulsed to IVR may look like "12#360#". There's just one exception: when passing none, there are no digits outpulsed, not even # sign. Passing none and none, thus, results in no digits at all.
Passing any kind of additional data, including call offer date/time, UCID, UUI (before CM3) and so on requires CTI integration. It's another matter altogether, I won't discuss it here.
Now we get to Converse Data Return feature. It's a meaning for returning data from IVR to Definity if IVR application is done before a call is delivered to an agent. To use this feature, we should first define the Converse Data Return Code on the feature-access-code screen. Since this code is an ordinary FAC, it should fit into your dial plan as usual. To activate this feature from the IVR side, the application should send analog flash (short line disconnect) signal into the established line, then, after getting the dial tone, it should dial Converse Data Return FAC followed by the digit string. The string may consist of several substrings separated by # sign, in this case it will be treated as several strings.
Collecting this string or strings is done by ordinary collect digits command that immediately follows the converse-on command (you see it in our example on the line 5), though if it follows converse-on it appears in special form and does not allow to specify any announcement for playing before digit collection. Note that during passing Converse Data Return digits, a caller will hear dead air, just like with passing incoming digits.
After IVR is done with sending back digits, it should hang up and thus our IVR call processing is done. We may route a call based on the digits collected, or return it to the wait-time step or do whatever we want, it does not matter for us now since it does not involve IVR any more.