Cisco Cisco TelePresence Video Communication Server Expressway 관리 매뉴얼

다운로드
페이지 498
Device authentication
Cisco VCS Administrator Guide (X7.2)
Page 109 of 498
Hierarchical dial plans and authentication policy
Hierarchical dial plan (directory VCS) deployments and device authentication
When introducing authentication into video networks which have a hierarchical dial plan with a directory
VCS, authentication problems can occur if:
n
any VCS in the network uses a different authentication database from any other VCS in the network, and
n
credential checking is enabled on the Default Zone of any VCS (as is needed, for example, when using
TMS Provisioning Extension mode), and
n
the directory VCS or any other VCS in a signaling path can optimize itself out of the call routing path
In such deployments, each VCS must be configured with a neighbor zone between itself and every other
VCS in the network. Each zone must be configured with an Authentication policy of Do not check
credentials
. (No search rules are required for these neighbor zones; the zones purely provide a mechanism
for trusting messages between VCSs.)
This is required because, otherwise, some messages such as SIP RE-INVITES, which are sent directly
between VCSs (due to optimal call routing), will be categorized as coming from the Default Zone. The VCS
will then attempt to authenticate the message and this may fail as it may not have the necessary credentials
in its authentication database. This means that the message will be rejected and the call may be dropped.
However, if the node VCSs have a neighbor zone relationship then the message will be identified as coming
through that neighbor zone, the VCS will not perform any credential checking (as the neighbor zone is set to
Do not check credentials) and the message will be accepted.
Deployments with multiple regional / subnetwork directory VCSs
If your deployment is segmented into multiple regional subnetworks, each with their own directory VCS, it is
not feasible (or recommended) to set up neighbor zones between each and every VCS across the entire
network.
In this scenario you should configure each subnetwork as described above – i.e. set up neighbor zones
between each of the VCSs managed by the same directory VCS – and then configure the neighbor zones
between each directory VCS so that they stay in the call signaling path on calls crossing subnetworks
between those directory VCSs. To do this:
1. On the directory VCS, go to the
Zones
page (
VCS configuration > Zones > Zones
) and then click on the
relevant zone to the other directory VCS.
2. On the
Edit zones
page, scroll down to the Advanced section and set Zone profile to Custom.
3. Set Call signaling routed mode to Always.
4. Click Save.
5. Repeat this for the equivalent zone definition on the “other” directory VCS, and then repeat the entire
process for any other zone configurations between any other directory VCSs.
Note: do not modify the directory VCS’s primary Call signaling routed mode setting on the
Calls
page.
This means that the each directory VCS will stay in the call signaling path for calls that go between
subnetworks. Each directory VCS will still be able to optimize itself out of the call signaling path for calls
entirely within each subnetwork.
You must also ensure that you have sufficient non-traversal and traversal licenses on each directory VCS to
handle those calls going between each subnetwork.