119
D14049.07
March 2010
Grey Headline
(continued)
TANDBERG
VIDEO COMMUNICATION SERVER
ADMINISTRATOR GUIDE
Introduction
Overview and
status
System
configuration
VCS
configuration
Zones and
neighbors
Clustering and
peers
Call
processing
Bandwidth
control
Firewall
traversal
Appendices
Applications
Maintenance
Subzones
The Local Zone is made up of subzones. Subzones are used to
control the bandwidth used by various parts of your network, and
to control registrations.
Three special subzones — the Default Subzone, the Traversal
Subzone and the Cluster Subzone (only applies if the VCS is in a
cluster) — are automatically created and cannot be deleted.
Additional subzones can also be manually configured.
When an endpoint registers with the VCS it is allocated to an
appropriate subzone, determined by subzone membership rules
based on endpoint IP address ranges or alias pattern matches.
See the
Configuring subzones and membership rules
section for
more information.
Subzone registration policy
In addition to using
Allow and Deny Lists
to control whether
an endpoint can register with the VCS, you can also configure
each manually created subzone and the Default Subzone as to
whether it will accept registrations assigned to it via the subzone
membership rules.
This provides additional flexibility when defining your registration
policy. For example you can:
•
Deny registrations based on IP address subnet. You can do
this by creating a subzone with associated membership rules
based on an IP address subnet range, and then setting that
subzone to deny registrations.
•
Configure the Default Subzone to deny registrations. This
would cause any registration requests that do not match any
of the subzone membership rules, and hence fall into the
Default Subzone, to be denied.
Note that registration requests have to fulfill any Allow/Deny
List policy rules before any subzone membership and subzone
registration policy rules are applied.
When an endpoint registers with the VCS, its IP address and
alias is checked against the subzone membership rules and it is
assigned to the appropriate subzone. If no subzones have been
created, or the endpoint’s IP address or alias do not match any
of the subzone membership rules, it is assigned to the Default
Subzone (providing the Default Subzone's
Registration policy
is
set to
Allow
).
The use of a Default Subzone on its own (without any other
manually configured subzones) is suitable only if you have
uniform bandwidth available between all your endpoints.
However, it is possible for a Local Zone to contain two or more
different networks with different bandwidth limitations. In this
situation, you should configure separate subzones for each
different part of the network.
Use the
Default Subzone
page (
VCS configuration > Local Zone
> Default Subzone
) to place bandwidth restrictions on calls
involving endpoints in the Default Subzone, and to specify the
Default Subzone's registration policy.
The VCS is shipped with the Default Subzone and Traversal
Subzone (and
Default Zone
) already created, and with links
between the three. You can delete or amend these default links
if you need to model restrictions of your network.
If any of these links have been deleted, they can be
automatically restored by using:
•
xCommand DefaultLinksAdd
To restore these links from the web interface, you must recreate
them manually. See the
Creating and editing links
section for
instructions on how to do this.
The Traversal Subzone is a conceptual subzone. No endpoints
can be registered to the Traversal Subzone; its sole purpose is
to control the bandwidth used by traversal calls.
All traversal calls are deemed to pass through the Traversal
Subzone, so by applying bandwidth limitations to the Traversal
Subzone you can control how much processing of media the VCS
will perform at any one time. These limitations can be applied on
a total concurrent usage basis, and on a per-call basis.
Traversal calls
A traversal call is a call passing through the VCS that includes
both the signaling (information about the call) and media (voice
and video). The only other type of call is a non-traversal call,
where the signaling passes through the VCS but the media goes
directly between the endpoints (or between an endpoint and
another VCS, or between two VCSs, in the call route).
The following types of calls require the VCS to take the media:
•
firewall traversal calls, where the local VCS is either the
traversal client or traversal server
•
calls that are gatewayed (interworked) between H.323 and
SIP on the local VCS
•
calls that are gatewayed (interworked) between IPv4 and IPv6
on the local VCS
•
for VCSs with Dual Network Interfaces enabled, calls that are
inbound from one LAN port and outbound on the other
•
a SIP to SIP call when one of the participants is behind a NAT
(unless both endpoints are using
ICE
for NAT traversal)
All such calls require a traversal call license each time they pass
through the Traversal Subzone.
A call is “traversal” or “non-traversal” from the point of
view of the VCS through which it is being routed at the
time. A call between two endpoints may pass through a
series of VCSs. Some of these systems may just take the
signaling, in which case the call will be a non-traversal call for
that VCS. Other systems in the route may need to take the
media as well, and so the call will count as a traversal call on
that particular VCS.
About subzones
About the Traversal Subzone
About the Default Subzone
Default links between subzones
