117
D14049.05
February 2009
Grey Headline
(continued)
TANDBERG
VIDEO COMMUNICATIONS SERVER
ADMINISTRATOR GUIDE
Introduction
Getting started
Overview and
status
System
configuration
VCS
configuration
Zones and
neighbors
Call
processing
Bandwidth
control
Firewall
traversal
Appendices
Applications
Maintenance
Call configuration
Overview
It is possible for the VCS to receive a call that is destined for it
but which does not specify an alias. This could be for one of the
following reasons:
the caller has dialed the IP address of the VCS directly
•
the caller has dialed a domain name belonging to the VCS
•
(either one of its configured SIP domains, or any domain that
has an SRV record that points at the IP address of the VCS),
without giving an alias as a prefix.
Normally such calls would be disconnected. However, the VCS
allows you to specify an alias to which all such calls should be
routed. This alias is known as the
fallback alias
.
To configure the
Fallback alias
from the web interface, go to the
Calls
page (
VCS configuration > Calls
).
To configure this setting from the CLI:
xConfiguration Call Services Fallback Alia
•
s
If no fallback alias is configured, calls that do not specify
an alias will be disconnected.
Some endpoints do not allow users to enter an alias and
an IP address to which the call should be placed.
Example usage
You may wish to configure your fallback alias to be that of
your receptionist, so that all calls that do not specify an alias
will still be answered personally and can then be redirected
appropriately.
For example, Example Inc. has the domain of
example.com
. The
endpoint at reception has the alias
.
They configure their VCS with a fallback alias of
reception@
example.com
. This means that any calls made directly to
example.com
(i.e. without being prefixed by an alias), are
forwarded to
, where the receptionist
answers the call and directs it appropriately.
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
What are traversal
calls?
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 Mod
•
e
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 licence (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 once the call has been set up. The VCS will not
consume a call licence 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 lookup and locate endpoints and it does
not have any endpoints registered directly to it.
Fallback alias
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 Mod
•
e
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
