Cisco Cisco Customer Voice Portal Downloads
4-11
Cisco Customer Voice Portal (CVP) Release 3.0(0) Product Description
Chapter 4 VoIP Routing
Call Transfers and Outbound Routing
The CVP’s assigned Gatekeeper must know whether it “owns” the destination endpoint, or whether it
belongs to another Gatekeeper. If the endpoint is:
belongs to another Gatekeeper. If the endpoint is:
•
In the CVP Gatekeeper’s zone, then the CVP Gatekeeper can determine it directly.
•
In a different zone, the CVP Gatekeeper must determine which Gatekeeper does own it.
An efficient way to do this is by using Gatekeeper zone commands. For example, suppose that the CVP
Gatekeeper (GK-A) controls Zone A, which supports numbers in the 408 area code; while GK-B controls
Zone B, which supports the 617 area code. Instead of having GK-A send out queries to determine which
Gatekeeper owns 617 numbers, GK-A can be configured using a zone prefix command so that it
“knows” that GK-B owns them. This means that, whenever the CVP requests destination information for
a 617 number, the GK-A can immediately communicate with GK-B to determine the correct endpoint.
Gatekeeper (GK-A) controls Zone A, which supports numbers in the 408 area code; while GK-B controls
Zone B, which supports the 617 area code. Instead of having GK-A send out queries to determine which
Gatekeeper owns 617 numbers, GK-A can be configured using a zone prefix command so that it
“knows” that GK-B owns them. This means that, whenever the CVP requests destination information for
a 617 number, the GK-A can immediately communicate with GK-B to determine the correct endpoint.
Note
For more information on Gatekeeper IOS commands, see the Cisco IOS documentation. For detailed
examples of how to configure Gatekeepers for use with the CVP, see the Cisco Customer Voice Portal
(CVP) Configuration and Administration Guide.
examples of how to configure Gatekeepers for use with the CVP, see the Cisco Customer Voice Portal
(CVP) Configuration and Administration Guide.
Gateway Configuration and Behavior, IP Transfer Mode
A Voice Gateway can provide access to a Time-Division Multiplexing (TDM) switching network; or it
can be connected to an ACD, PBX, or to one or more phones.
can be connected to an ACD, PBX, or to one or more phones.
In IP transfer mode, once the Gatekeeper has determined the destination endpoint name during ARQ
processing, the Gatekeeper must then find the endpoint’s IP Address. The Gateways provide this
information when they register with their Gatekeeper.
processing, the Gatekeeper must then find the endpoint’s IP Address. The Gateways provide this
information when they register with their Gatekeeper.
As discussed in the
one way to manage the mapping of the transfer information to destination endpoints is by having the
Gateways pass a list of their supported E164 numbers when they register with their Gatekeeper. This is
done using the register e164 command for each dial-peer destination pattern that the Gateway should
register with the Gatekeeper. Only fully-qualified destination patterns (that is, completely defined
numbers with no wild cards) may be registered in this manner, and different Gateways may not register
with the same numbers.
Gateways pass a list of their supported E164 numbers when they register with their Gatekeeper. This is
done using the register e164 command for each dial-peer destination pattern that the Gateway should
register with the Gatekeeper. Only fully-qualified destination patterns (that is, completely defined
numbers with no wild cards) may be registered in this manner, and different Gateways may not register
with the same numbers.
Gateways should be configured to notify their Gatekeeper (through H.323 RAI message) if they are
unable to accept additional calls. This will prevent the Gatekeeper from selecting those Gateways as
destination endpoints for CVP IP mode call transfers.
unable to accept additional calls. This will prevent the Gatekeeper from selecting those Gateways as
destination endpoints for CVP IP mode call transfers.
It is expected that Gateways will provide access to call center ACDs in many CVP implementations. Care
must therefore be taken to configure the Gateway dial-peers to conform with ACD dial-plan
requirements. A discussion of how this may be accomplished is given in the Examples section.
must therefore be taken to configure the Gateway dial-peers to conform with ACD dial-plan
requirements. A discussion of how this may be accomplished is given in the Examples section.
Codecs
When the call is being transferred, the CVP Voice Browser negotiates the codec between the ingress
Gateway and egress Gateway (or CallManager) for the rtp packetized voice connection. Note that the
Voice Browser merely proxies the codec capability set between the ingress and egress gateways. If the
desired transfer codec is G.729, for example, then the terminating Gateway must be configured with
G.729 as its default (highest preference) codec.
Gateway and egress Gateway (or CallManager) for the rtp packetized voice connection. Note that the
Voice Browser merely proxies the codec capability set between the ingress and egress gateways. If the
desired transfer codec is G.729, for example, then the terminating Gateway must be configured with
G.729 as its default (highest preference) codec.