114
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
Call configuration
Overview
Calls are made up of two components - signaling and media.
For traversal calls, the VCS will always handle both the media and the signaling.
For non-traversal calls, the VCS will not handle the media, and may or may not need to handle the
signaling. You can nominate whether or not the VCS will handle the signaling when it is not required
to from the
Call routed mode
setting.
For a definition of a traversal call, see the
What are traversal calls?
section.
To configure the
Call routed mode
from the web interface, go to the
Calls
page (
VCS configuration
> Calls
).
To configure this setting from the CLI:
•
xConfiguration Call Routed Mode
The options for this setting are:
Always
The VCS will always handle the call signaling. The call will consume either a traversal call license (if
it is a traversal call) or a local (non-traversal) call license (if it is not a traversal call) on the VCS.
Optimal
The VCS will handle the call signaling when the call is one of:
•
a traversal call
•
an H.323 call that has been modified by Call Policy or FindMe such that it resolves to more than
one alias, or has a "no answer" or "busy" device configured
•
one of the endpoints in the call is locally registered.
In all other cases the VCS will remove itself from the call signaling path after the call has been set
up. The VCS will not consume a call license for any such calls, and the call signaling path will be
simplified. This setting is useful in a
hierarchical dial plan
, when used on the directory VCS. In such
deployments the directory VCS is used to look up and locate endpoints and it does not have any
endpoints registered directly to it.
Call routed mode
Overview
Your dial plan or that of networks to which you are neighbored may be configured in such a way that
there are potential signaling loops. An example of this is a
structured dial plan
, where all systems
are neighbored together in a mesh. In such a configuration, if the
hop counts
are set too high, a
single search request may be sent repeatedly around the network until the hop count reaches 0,
consuming resources unnecessarily.
The VCS can be configured to detect search loops within your network and terminate such
searches. This is done using the
Call loop detection mode
setting.
To configure the
Call loop detection mode
using the web interface, go to the
Calls
page (
VCS
configuration > Calls
).
To configure this setting using the CLI:
•
xConfiguration Call Loop Detection Mode
The options for this setting are:
On
The VCS will fail any branch of a search that contains a loop, recording it as a level 2 "loop
detected" event.
Two searches will be considered to be a loop if they:
•
have same call tag
•
are for the same destination alias
•
use the same protocol, and
•
originate from the same zone.
Using this setting will allow you to save on network resources and fail call branches early where
loops have been detected.
Off
The VCS will not detect and fail search loops. We recommend that you use this setting only in
advanced deployments.
The loop detection feature was introduced in VCS version X4. It is only supported in
deployments where all VCSs are running on X4 software or later.
Call loop detection mode
