Converse On Data Return Code (Pauses needed?)

[Stinney]

I was under the impression that when an IVR is dialing the Converse-on Data Return Code, it needed to have a pause after the code before it dials the rest of the string.

In our environment the system would be dialing 257 - then a 6 digit extension.

However, if we insert a pause (in the IVR it's a comma), then it fails, if we don't put in a pause, it works.

I just want to make sure we're not setting ourselves up for any failure by not having a pause.

Thanks.

- Stinney

Quoting only proves you know how to cut and paste.

 

[uzumaki]

Sorry to ask, but usually how does this converse-on work. Is it similar to adjunct routing? Basically what I understand on adjunct routing, "your giving the full control on the 3rd party equipment to do call routing". What about this converse-on step?

 

[BIS]

Stinney,

In sys feat:
Converse First Data Delay: 0 Second Data Delay: 0
Converse Signaling Tone (msec): 100 Pause (msec): 50

 

[Stinney]

Thanks BIS. If I'm reading this and Avaya documentation correctly, if the First Data Delay is set to 0 then I don't need a delay (provided I'm only sending one piece of data back, which I am).

uzumaki, with converse-on, the vector is still in control of the call, it will not allow the call to be transferred and the call must return to the vector for processing. If the 3rd party simply hangs up and the caller is still on the line, the vector will continue to the next step in the vector. You can set the vector up to collect digits from the 3rd party through a collect step in the vector if the application can send DTMF back. It has to be able to perform a switch-hook flash and then dial a converse data return code first, then the "data" to pass back using DTMF.

Adjunct routing uses the CTI link to establish a data connection, where converse-on uses skills. Usually you set up the application taking the call, usually an IVR, with DS1FD extensions connected to a DS1 board. Then you assign these extensions to AAS Agent logins. The call is then converse-on routed to the skill assigned to these agent logins.

So basically, you are creating automated call agents on the IVR that are part of a skill group. The converse-on sends the call to the queue and waits to get back information from the "agent" using the collect step. Based on the "data" returned, the vector could then route the call to live agents, play an announcement, give other menu options, transfer the call somewhere else, etc. It all depends on how you want to handle the call, but instead of being handled by the IVR, it's handled by the PBX/Vector.



- Stinney

Quoting only proves you know how to cut and paste.