IVR Delay?

[num025]

I'm experiencing around an 8-second delay when a call is being transfered back to the PABX from an IVR. Is there a workaround for this? I've tried verifying by inserting an announcement immediately after the converse-on step, but still the 8-second delay is there during the transition.

 

[nickd87]

Check how fast your IVR is pulsing the DTMF tones. Also, try making it send a # at the end of the digits it's returning. That might speed things up.

 

[num025]

Thanks for that! I'll tell these to the IVR guys.

 

[num025]

Nope, nothing was changed after introducing a # sign. So, is this really just an IVR problem?

 

[num025]

By the way, the IVR is connected to some DS1 cards being controlled by S8730 servers

 

[BIS]

Is the IVR sending back the Converse Data Return Code?

 

[num025]

If you mean the feature-access code (along with other numbers) then yes.

 

[nickd87]

This might seem obvious but check that you are collecting the correct number of digits after your converse step. If you are waiting for more than your IVR is returning, the pabx will wait for the interdigit timeout to expire before continuing with vector processing.

 

[num025]

Thanks for that! The collect step after the converse-on line is set at 5 digits, which should be right for the VDN extension length that is programmed.

 

[nickd87]

Hmm... so you're collecting 5 digits and your IVR is dialling the CDRC then five digits? Is your collect step directly after the converse step?

Can you post a trace of the call going through the IVR? Are you using CAS or QSIG?

 

[num025]

Yes, the IVR is dialing the FAC (3 digits) plus 5 digits, where the "collect 5" step is immediately after the converse-on line.

I don't have access to the IVR since there is a different BP handling it, but anyway here is the trace from the vector with the converse-on step:

list trace vector 13

                                LIST TRACE

time      vec st data

17:33:48    0  0 ENTERING TRACE cid 4854
17:33:48   13  1 vdn e64003 bsr appl   0 strategy 1st-found override y
17:33:48   13  1 wait 0 secs hearing ringback
17:33:48   13  2 converse-on skill 13 pri m passing vdn and ani
17:33:48   13  2 Local Agent Preference=n
17:33:48   13  2 Agent Login ID: 54063  Logged in at station: 63063
17:34:51   13  2 LEAVING VECTOR PROCESSING cid 4854
17:34:51   13  2 TRACE COMPLETE cid 4854

Here is the vector in detail:

01 wait-time    0   secs hearing ringback
02 converse-on  skill 13   pri m passing vdn    and ani
03 collect      5    digits after announcement none     for none
04 route-to     digits with coverage y
05 stop
06

We're using CAS signaling for the IVR connectivity.

 

[nickd87]

That's interesting... I'm not seeing the collect step (step 3) being executed in the trace. Did you leave the trace running until the IVR attempted to pass back the digits?

 

[num025]

Yes, I left it running until it goes to another vdn where it queues to a live agent and terminated by itself.

 

[num025]

The client is pointing at the converse-on step as the source of the delay, which for me is odd since the delay is only happening when the IVR is returning back the data. Any other suggestions?

 

[nickd87]

Well that's technically true as you stay at the converse-on step until the IVR passes back control. That's what I'm _not_ seeing in the trace above... it never seems to come back to the PABX, so I think it's entirely possible that your delay is somewhere in the IVR and the IVR is actually transferring the call to another VDN or something.

Otherwise, you'd see the collect step being executed in the trace, after the converse-on step. Something funky is going on.