Filter
Top Products
68
D14049.04
JULY 2008
Grey Headline (continued)
TANDBERG VIDEO COMMUNICATIONS SERVER
ADMINISTRATOR GUIDE
Introduction Getting Started
Overview and
Status
System
Conguration
VCS
Conguration
Zones and
Neighbors
Call
Processing
Bandwidth
Control
Firewall
Traversal
Appendices
Applications Maintenance
SIP
SIP protocols and ports
The VCS supports SIP over UDP, TCP and TLS transport protocols. You can congure whether or not
incoming calls using each protocol are supported, and if so, the ports on which the VCS will listen
for such calls. You can also specify the range of ports the VCS will use once calls are established.
This range must be sufcient to support all required concurrent calls.
At least one of the UDP, TCP or TLS transport protocols must be set to a Mode of On in
order for SIP functionality to be supported.
Using the VCS as a SIP Proxy Server
When SIP mode has been enabled the VCS may act as a SIP Proxy Server. The role of a Proxy
Server is to forward requests (such as REGISTER and INVITE) from endpoints or other Proxy
Servers. These requests are forwarded on to other Proxy Servers or to the destination endpoint.
Whether or not the VCS acts as a SIP Proxy Server, and its exact behavior when proxying requests,
is determined by the SIP Registration Proxy Mode setting. In addition, this also depends on the
presence of Route Set information in the request header and whether or not the Proxy Server from
which the request was received is a Neighbor of the VCS.
A Route Set can specify the path that must be taken when requests are being proxied between
an endpoint and its Registrar. For example, when a REGISTER request is proxied by a VCS, the
VCS adds a Path header component to the request which signals that the VCS must be included
on any call to that endpoint. The information is usually required in situations where rewalls exist
and the media must follow a specied path in order to successfully traverse the rewall. For more
information about the path header eld, see RFC 3327 [10].
When the VCS proxies a request that contains existing Route Set information, it will forward it
directly to the URI specied in the path. Any call policy congured on the VCS will therefore be
bypassed. This may present a security risk if the information in the Route Set cannot be trusted.
For this reason, you can congure the VCS with three different behaviors when proxying requests,
as follows:
If the
•
SIP Registration Proxy Mode setting is Off, the VCS will not proxy any requests that have
an existing Route Set. Requests that do not have an existing Route Set will still be proxied in
accordance with existing call policy (e.g. zone searches and transforms). This setting provides
the highest level of security.
If the setting is
•
Proxy to Known Only, the VCS will proxy requests with an existing Route Set only
if the request was received from a Neighbor zone (including Traversal Client and Traversal Server
zones). Requests that do not have an existing Route Set will be proxied in accordance with
existing call policy.
If the setting is
•
Proxy to any, the VCS will proxy all requests. Those with existing Route Sets will
be proxied to the specied URI; those without will be proxied in accordance with existing call
policy.
The SIP Registration Proxy Mode setting only applies to dialog-forming requests, e.g. INVITE
and SUBSCRIBE. Responses, such as NOTIFY, are always proxied regardless of this
setting.
SIP Overview
Using the VCS as a SIP Presence Server
The VCS supports the SIP-based SIMPLE protocol. It can act as a:
Presence Server
•
Presence User Agent
•
for any of the SIP Domain(s) for which it is authoritative.
For full information on how to use the VCS as a SIP Presence server, see the Presence section.