Cisco Cisco Customer Voice Portal Downloads

The CVP must then use that method when it sends the H.245 userInputIndication message to initiate the 
call transfer. If the CVP does not indicate a compatible method of H.245 relay during the capabilities 
exchange with the Gateway, the Gateway reverts to its default mode of no H.245 relay.

When the ACD is connected to the VoIP network, the CVP can be treated as a network control point—a 
place for the ACD to access advanced network features. The CVP is an excellent vehicle for 
implementing those features because of its voice processing ability and position in the network. Invoking 
such a feature requires that the CVP stay involved with a call even after it has been transferred to another 
VoIP endpoint. Staying involved with the ACD endpoint means using H.323 to redirect the audio stream 
to a new endpoint, previously the Voice Browser and now the ACD, while the signaling control path is 
unchanged. The control path still terminates at the CVP, but CVP switches the audio path. This is called 
the IP transfer mode of operation because the CVP is creating an outgoing call leg.

In IP transfer mode, the NAM/ICM:

Determines the type of transfer and the destination for the initial call transfer to be performed by the 
CVP. 

Passes this information to the CVP through the ICM/IVR message. 

Specifies transfer information in the Label field of the CONNECT message. 

The CVP will perform a lookup in its assigned Gatekeeper to determine the IP Address of a destination 
endpoint to which it should transfer the call. These steps are discussed in greater detail in the following 
sections.

In IP transfer mode, the CVP must obtain the IP Address of the VoIP destination endpoint to which it 
will transfer the call. This requires the CVP to perform an H.323 RAS lookup to its assigned Gatekeeper. 
Specifically, the CVP Voice Browser sends the Gatekeeper an ARQ (Admission Request) message, 
passing the contents of the CONNECT Label. After the Gatekeeper returns an ACF (Admission 
Confirmation) message, the CVP Voice Browser attempts to transfer the call to the destination endpoint. 
As part of the call setup, the CVP passes the transfer information to the destination endpoint.

If the destination endpoint does not respond correctly to the call setup, the CVP shall successively try to 
transfer the call to the alternate endpoints. 

The CVP shall not perform additional lookups in the Gatekeeper if it cannot successfully transfer the 
call to the destination endpoint or one of its alternates (as the Gatekeeper cannot provide any additional 
routing information). Instead, the CVP can provide treatment under NAM/ICM script control (such as 
play a message and hang up).

The Gatekeeper’s primary responsibility in outbound routing is to determine the IP Address of the VoIP 
destination endpoint, based on the transfer information the CVP sends it in the ARQ (Admission 
Request) message. 

Unlike inbound calls to the CVP, the Gatekeeper is not expected to use the GKTMP interface to query a 
separate server (such as the NAM) for call routing information on transfers from the CVP. (The reason 
for this is that the NAM has already determined the transfer destination by this point in time, so another 
lookup from the Gatekeeper is unnecessary.)