Cisco Cisco TelePresence Video Communication Server Expressway 관리 매뉴얼
67
D14049.08
November 2010
November 2010
Grey Headline (continued)
CISCO TELEPRESENCE
VIDEO COMMUNICATION SERVER
ADMINISTRATOR GUIDE
Zones
Overview
To neighbor with another system (such as another VCS or
gatekeeper), create a connection over a firewall to a traversal
server or traversal client, or discover endpoints via an ENUM or
DNS lookup, you must configure a zone on the local VCS.
When adding a new zone you must specify its Type. The zone
type indicates the nature of the connection and determines
which configuration options are available. For traversal server
zones, traversal client zones and neighbor zones this includes
providing information about the neighbor system such as its IP
address and ports.
The Zones page lists all the zones that have been configured on
the VCS, and lets you add, edit or delete zones.
To go to the Zones page:
gatekeeper), create a connection over a firewall to a traversal
server or traversal client, or discover endpoints via an ENUM or
DNS lookup, you must configure a zone on the local VCS.
When adding a new zone you must specify its Type. The zone
type indicates the nature of the connection and determines
which configuration options are available. For traversal server
zones, traversal client zones and neighbor zones this includes
providing information about the neighbor system such as its IP
address and ports.
The Zones page lists all the zones that have been configured on
the VCS, and lets you add, edit or delete zones.
To go to the Zones page:
•
VCS configuration > Zones.
Click on the zone you want to configure (or click New to create a
new zone, or click Delete to remove a zone).
To add a new zone using the CLI:
new zone, or click Delete to remove a zone).
To add a new zone using the CLI:
To configure existing zones using the CLI:
The following sections describe the various zone configuration
settings that can be applied.
settings that can be applied.
Zone configuration
TLS certificate verification of neighbor systems
When a SIP TLS connection is established between a VCS and a
neighbor system, the VCS can be configured to check the X.509
certificate of the neighbor system to verify its identity. You do
this by configuring the zone’s TLS verify mode setting.
If TLS verification is enabled, the neighbor system's FQDN or
IP address, as specified in the Peer address field of the zone’s
configuration, is used to verify against the certificate holder’s
name contained within the X.509 certificate presented by that
system. (The name has to be contained in either the Subject
Common Name or the Subject Alternative Name attributes of the
certificate.) The certificate itself must also be valid and signed
by a trusted certificate authority.
Note that for traversal server zones, the FQDN or IP address of
the connecting traversal client is not configured, so the required
certificate holder’s name is specified separately.
If the neighbor system is another VCS, or it is a traversal client /
traversal server relationship, the two systems can be configured
to authenticate each other’s certificates. This is known as
mutual authentication and in this case each VCS acts both as
client and as a server and therefore you must ensure that each
VCS’s certificate is valid both as a client and as a server.
See the
neighbor system, the VCS can be configured to check the X.509
certificate of the neighbor system to verify its identity. You do
this by configuring the zone’s TLS verify mode setting.
If TLS verification is enabled, the neighbor system's FQDN or
IP address, as specified in the Peer address field of the zone’s
configuration, is used to verify against the certificate holder’s
name contained within the X.509 certificate presented by that
system. (The name has to be contained in either the Subject
Common Name or the Subject Alternative Name attributes of the
certificate.) The certificate itself must also be valid and signed
by a trusted certificate authority.
Note that for traversal server zones, the FQDN or IP address of
the connecting traversal client is not configured, so the required
certificate holder’s name is specified separately.
If the neighbor system is another VCS, or it is a traversal client /
traversal server relationship, the two systems can be configured
to authenticate each other’s certificates. This is known as
mutual authentication and in this case each VCS acts both as
client and as a server and therefore you must ensure that each
VCS’s certificate is valid both as a client and as a server.
See the
section for more information on
certificate verification and for instructions on uploading the
VCS’s server certificate and uploading a list of trusted certificate
authorities.
VCS’s server certificate and uploading a list of trusted certificate
authorities.
Connections to neighbor systems over TCP and TLS
Connections between the VCS and neighbor systems must be
configured to use the same SIP transport type, that is they must
both be configured to use TLS or both be configured to use TCP.
configured to use the same SIP transport type, that is they must
both be configured to use TLS or both be configured to use TCP.
!
In software versions prior to X5.1 a connection could be
established if one system was configured to use TLS and
the other used TCP.
established if one system was configured to use TLS and
the other used TCP.
Note that any connection failures due to transport type
mismatches are recorded in the Event Log.
mismatches are recorded in the Event Log.
SIP authentication trust
If a VCS is configured to use
it will
authenticate incoming SIP registration and INVITE requests. If
the VCS then forwards the request on to a neighbor zone such
as another VCS, that receiving system will also authenticate the
request. In this scenario the message has to be authenticated
at every hop.
To simplify this so that a device’s credentials only have to be
authenticated once (at the first hop), and to reduce the number
of SIP messages in your network, you can configure neighbor
zones to use the Authentication trust mode setting.
Setting a zone’s Authentication trust mode to On means that if
the VCS receives an authenticated SIP request from that zone it
will trust that authentication and not challenge it again.
If Authentication trust mode is Off the VCS will always challenge
the request even if it has already been authenticated by the
sending zone.
the VCS then forwards the request on to a neighbor zone such
as another VCS, that receiving system will also authenticate the
request. In this scenario the message has to be authenticated
at every hop.
To simplify this so that a device’s credentials only have to be
authenticated once (at the first hop), and to reduce the number
of SIP messages in your network, you can configure neighbor
zones to use the Authentication trust mode setting.
Setting a zone’s Authentication trust mode to On means that if
the VCS receives an authenticated SIP request from that zone it
will trust that authentication and not challenge it again.
If Authentication trust mode is Off the VCS will always challenge
the request even if it has already been authenticated by the
sending zone.
Authentication trust only applies when device
authentication is enabled.
authentication is enabled.
Note that authenticated SIP requests are identified by the
presence of a P-Asserted-Identity field in the SIP message
header as defined by
presence of a P-Asserted-Identity field in the SIP message
header as defined by
.
!
You are recommended to enable authentication trust
only if the neighbor zone is part of a network of trusted
SIP servers.
only if the neighbor zone is part of a network of trusted
SIP servers.