VDN Return Destination (VRD) allows calls to be placed back in vector processing after all parties, except the originator, drop the call. The originator can optionally be an internal call or connection as well as an external trunk. Internal calls include any type of calls that can be placed to, covered to, or transferred to a VDN that is not treated as an incoming trunk call.
The Return Destination field on page 2 of the Vector Directory Number screen allows you to enter a VDN extension as a return destination. The VDN which has this field administered is called the VDN with this feature active. The return destination VDN (the one specified in the field) is referred to as the Return Destination. Return destination is applied on the VDN that is treated as active for a call when the call left vector processing.
Every call that is processed through a VDN with this feature active is routed back to the assigned VDN when all parties on the call, except the originator, drop. For this feature, the originator is the party that originated the call at the time the call entered the VDN with this feature active.
Note:
VRD does not apply to DCS and attendant handled calls.
The VDN to which the call is placed to (when the originator is the only remaining party) is determined by the return destination. The VDN can be the original VDN or a different one.
The VRD status comes from the active VDN for the call when it finally reaches the destination. Once the call has been through vector processing, the VRD status cannot be changed by subsequent vector processing. The VRD status is that it either does not have a VRD that applies (not the right origin or the active VDN assignment is blank) or that it has a VRD (an assigned VDN) that applies. If an internal call is released prior to the caller dropping, the assigned VRD extension and Call Origin value on the active Vector Directory Number screen determines VRD eligibility. An internal call is eligible for VRD if there is a VRD destination assigned and the Call Origin field on the Vector Directory Number screen is set to internal or both. VRD internal calls include:
Station or Voice Response Unit (VRU)/Interactive Voice Response (IVR)/Voice Portal (VP) adjunct to a VDN
An agent call to a VDN
Agent/station/line port transfer of a previously ineligible call to a VDN
Coverage or forwarding of a previously ineligible call to a VDN
ASAI 3rd Party Makecalls to a VDN
ASAI Merge connections, including Single Step Conference (SSC) to a VDN
Note:
An attendant call to a VDN or a call handled by an attendant is not eligible for VRD. If the call with a VRD reaches the PBX attendant, the VRD status will be canceled.
VDN Override applies to internal calls during the initial vector processing (not after leaving vector processing) if the call is routed to another VDN via a route-to command or adjunct route in the same manner as external calls. In this case the call origin criteria is also overridden so if for example an internal call to VDN A has call origin set to internal and override set to y, routing to VDN B, which has origin set to external, will remove the VRD. If VDN B does not have a VRD defined, the VRD will be also removed from the call since it overrides the assignment to VDN A. This feature keeps the call active after the original call has terminated. One typical use of VRD is for returning the caller, after being handled by an agent, to a VDN that is assigned to vector that routes to a VRU that surveys the caller. Another example of an application using VRD is to give the caller an opportunity to signal the need for sequence dialing (by entering a #). There are two ways this can happen:
When the destination drops on its own (after having answered), the call goes to the return destination which has a collect digits vector step. This step tries to collect the # sign entered by the caller.
When the call is not answered, the caller enters the # to request sequence calling ( the ASAI-Requested Digit Collection feature collects the # sign). This # is reported to the adjunct. The adjunct requests the third_party_drop (or third_party_end_call) for the destination, and at that point the call goes to the return destination.
The VRD and ASAI-Requested Digit Collection features can be used independently, with the following rules:
If there is no ASAI request to collect digits, but a return destination is provided: when all parties, except the originator, drop, the switch routes the call with only one party active (the caller) to the return destination. At this point, the call enters vector processing for the VDN specified by the return destination.
The caller keeps returning to the same return destination indefinitely until either the caller hangs up or a busy or disconnect vector step is executed. Once a call leaves vector processing for the first time, the return destination is not changed.
If a request is made to collect digits but there is no return destination provided, the switch collects and passes the digits to an adjunct, which takes an action. However, if the adjunct drops one party on the call, the switch will drop the other party as well and clear the call (it cannot retain a call with only one party, if there is no return destination for further processing).
