Cisco Cisco Unified Customer Voice Portal 10.5(1)
4-7
Cisco Customer Voice Portal (CVP) Release 3.0(0) Product Description
Chapter 4 VoIP Routing
Inbound Routing
Note
The current version of the Gatekeeper only allows the GKTMP interface to be “on” or “off.” That
is, the Gatekeeper will either query a GKTMP server like the NAM for all calls, or none of the
calls. This means that if GKTMP is desired for conditional routing into the CVP
(recommended), it must also be used on all CVP lookups to the Gatekeeper for call transfers.
However, this latter lookup is superfluous if the NAM/ICM is the GKTMP server, as the NAM
has already made the routing decision by the time the CVP does a Gatekeeper lookup. In this
case, the NAM would need to be configured to perform the equivalent of a “null” lookup for the
CVP’s GKTMP queries.
is, the Gatekeeper will either query a GKTMP server like the NAM for all calls, or none of the
calls. This means that if GKTMP is desired for conditional routing into the CVP
(recommended), it must also be used on all CVP lookups to the Gatekeeper for call transfers.
However, this latter lookup is superfluous if the NAM/ICM is the GKTMP server, as the NAM
has already made the routing decision by the time the CVP does a Gatekeeper lookup. In this
case, the NAM would need to be configured to perform the equivalent of a “null” lookup for the
CVP’s GKTMP queries.
Gateway Configuration
If a Gatekeeper is present in an inbound routing configuration, you can minimize Gateway configuration.
It is recommended that the Gateways be configured to always query the Gatekeeper for routing
information. This may be done by specifying a wildcard dial-peer.
It is recommended that the Gateways be configured to always query the Gatekeeper for routing
information. This may be done by specifying a wildcard dial-peer.
Note
For detailed instructions on how to configure wildcard dial-peers on Gateways, see the Cisco Customer
Voice Portal (CVP) Configuration and Administration Guide.
Voice Portal (CVP) Configuration and Administration Guide.
Gateways not in the CVP zone must be configured to query their own zone Gatekeeper for routing
information. The originating Gatekeeper will discover the CVP Zone Gatekeeper through an H.323
Location Request (LRQ) message. The CVP Zone Gatekeeper will determine proper routing, which will
be returned to the originating Gateway (by way of the originating Gatekeeper).
information. The originating Gatekeeper will discover the CVP Zone Gatekeeper through an H.323
Location Request (LRQ) message. The CVP Zone Gatekeeper will determine proper routing, which will
be returned to the originating Gateway (by way of the originating Gatekeeper).
Nearest CVP Node Option
For performance reasons, it may be desirable to route inbound calls to the CVP node nearest to the
originating Gateway. Aside from using the GKTMP interface, this can be accomplished by setting up
separate H.323 Zones for the different CVP nodes.
originating Gateway. Aside from using the GKTMP interface, this can be accomplished by setting up
separate H.323 Zones for the different CVP nodes.
Note
While H.323 requires each zone to be controlled by a single (logical) Gatekeeper, there is nothing to
prevent multiple zones from being controlled by the same Gatekeeper. However, CVP Version 3.0 does
not support multiple logical Gatekeepers on the same physical Gatekeeper machine. For CVP 3.0,
multiple Gatekeepers must be implemented on separate Gatekeeper machines.
prevent multiple zones from being controlled by the same Gatekeeper. However, CVP Version 3.0 does
not support multiple logical Gatekeepers on the same physical Gatekeeper machine. For CVP 3.0,
multiple Gatekeepers must be implemented on separate Gatekeeper machines.
Gatekeeper Example
shows CVP nodes and Gateways placed in three different H.323 zones:
•
CVP_Node1 and Gateway Huey are assigned to Zone 1, which is controlled by GK1.
•
CVP_Node2 and Gateway Dewey are assigned to Zone 2, which is controlled by GK2.
•
CVP_Node3 and Gateway Louie are assigned to Zone 3, which is controlled by GK3.