I know of no clean way.
You might be able to achieve this using a "converse-on" step and the Vector Disconnect Timer value in 'cha sys feat'.
You could use a "converse-on" step to queue the call to the skill you want to limit the inbound duration for. The call will drop once the Vector...
Looks like a random system is connecting to your switch erroneously and effectively sending it garbage at the login prompt, causing your login violation notifications at the attendant.
However, the data there "cstatu", "clist" and "cdispl" looks curiously like the beginning of commands in SAT...
You are right to say that a delay is normal. The delay is simply caused by the IGAR call being set up in the PSTN. However, 6 seconds sounds like something else is going wrong.
What types of trunks are you using? Check your events log; are there any denial events relating to IGAR? Do a 'list...
Hi all
I am hoping to find a CMS report or BCMS command on the switch that will show me the maximum number of concurrent trunks in use during certain time frames.
What I am trying to do is find out how many trunks were in use between different day parts. For example, between 11am - 4pm and 9pm...
Hi there
I am wanting to write an application that can change Variables in Vectors (VIV) on a Communication Manager 3.1.5 system. I have looked at DevConnect et al and all of the examples seem to deal with call control and things like that.
I don't want to have an application that can answer...
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...
You have at least 2 options:
1. If all of your agents are in Aux, your EWT will be infinite. So you could do a "goto step x if expected-wait for skill X > 9999" and go from there.
2. If all of your agents are in Aux, there are no available agents, so you could make that your goto conditional...
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?
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?
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.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.