Calls are transferred from the network (or PBX) to the NMS board, the time before pickup is 3-4 seconds. <br> <br>I have monitored the trunk using the "showsg95" utility (part of the NMS drivers) and I see the first receive signalling happen almost instantaneouls, but the answer takes the 3-4 seconds. <br> <br>In the standard Teleflow apps I have changed the @ANSWER_PAUSE to 500ms (but this does not affect what I see from the showsg95 utility. <br> <br>How can we "speed up" the transfer?

One point I forgot -- we are using D4-AMI signalling.

How many DNIS digits is the PBX providing? <br> <br>Standard TeleFlow is set to wait for 4 digits from the network. If it gets 3 digits or less, it will wait for the timeout period, which is approximately 3 seconds before it proceeds. <br> <br>The "Connection Delay (ms)" setting on the Wait for Call step starts after the timeout, and so your system is waiting an additional 500 ms before it leaves the Wait For Call step and processes the rest of your application.

I am told by the switch administrators it is providing 4 digits on DNIS information. <br> <br>Assuming there is 4 digits of DNIS information provided from the switch how long should it take Teleflow to 'answer?' <br> <br>Is it the 500ms in the Wait for Call step plus the @ANSWER_PAUSE variable? <br> <br>Is there a way for me to force Teleflow not to look for DNIS information - to avoid any delays?

You can check the DNIS length by looking at your TeleFlow application logs. The Wait For Call step allows you to trap the DNIS string into a TeleFlow variable. The variable will either contain the total digits sent from the switch, or it will contain the maximum set in TeleFlow (which SHOULD be 4, but more on this later). Any digits beyond the maximum will show up in your application as Touch-Tone input. So, check your TeleFlow log and you should be able to figure out exactly how many digits your switch is providing. <br> <br>It should take exactly as long to process the DNIS digits as it takes the switch to send them. Typically, this is very fast and not noticeable to the caller. <br> <br>The 500ms wait (in Wait For Call) that I was referring to was the setting in your @ANSWER_PAUSE variable, not an additional pause. That is a user variable, not a system variable, and so I made my response generic for the benefit of others who may be reading this thread. You could safely set this value to 0, and only increase it if you notice that the initial greeting your application plays seems to be cut-off at the beginning. <br> <br>Now, to the BIG question in your post, can you set the number of digits expected? The answer is not currently, but hopeful soon. I have been lobbying for this for a long, long time. In your case, I recall some service work we did to set the internal digits setting higher or lower to try and fix this issue - or one like it. Sorry, my memory is fuzzy on this. However, I do know that the hard-code to 4 digits was done specifically to handle your customers (that I remember because we have so few D4 AMI Wink start customers). It is possible, that at this particular site you have one of the older builds with a higher digit count. Also in the log, at the Wait For Call step, you should see output that tells you how many digits TeleFlow is expecting. <br> <br>You should be running TeleFlow Server build # 2006.0613 or newer, which is expecting exactly 4 digits. Also, you will have to get to the newest version in order for us to be able to provide you with a real fix for this issue.