Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Delay in vector Route-To command for an 800#

Status
Not open for further replies.

dudecrush

IS-IT--Management
Joined
Apr 2, 2007
Messages
468
Location
US
Got a question,

I have a VDN which points to a simple vector with 2 lines: a route-to command that forwards the call off-net to an 800#, and a stop command. Simple enough.

I received a complaint today of a delay in the transfer of a call through this VDN / Vector. When I tested by transfering a call to the VDN, it seemed like it took about 5-8 seconds for the call to finally ring on the 800#. When I direct-dialed the 800#, it seemed to go through without delay.

I tested by running a list trace VDN and Vector from the emulator, and the call routed through both of them in around a second.

Given that: 1) Both VDN/Vector transfer and dialing direct use the same ARS routing. 2) The traces indicate queue flow-through in a second, my conclusion is that this is a CO / Carrier routing problem. However - I can't account for why dialing the number direct has no delay. Thus I can't trust my conclusion.

Has anyone experienced this? What could be accounting for the off-net delay through the vector but not via direct dial?

 

Try ending the number to route-to with a #

If that doesn't work can you post the vector?

- Stinney

Quoting only proves you know how to cut and paste.
 
Stinney,

I put the #-sign at the end of my number, but it didn't seem to shorten anything. There was a wait-time command of 0 seconds on the first line which I also removed, but that didn't shorten it up either. This is the way the vector reads right now:

1 route-to number 91888xxxxxxx with cov n if unconditionally

2 stop

 
To any reader of this post, I was finally able to resolve this problem. After delays in dealing with our LEC, I finally got them to test the circuit between our CO and the location I was calling. Their tests indicated a normal route time of 1-3 seconds. The problem was ocurring on the far-end. I finally called and spoke with the IT manager at the business location in question. Turns out their telephony equipment had a 3-4 second delay after it picked up the call before the auto-attendant kicked in.

To compensate, I put a "Please wait - slight delay" message in the queue prior to transfer, so callers won't hang up and call back again.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top