Filter
Top Products
D 14049.01
07.2007
85
TANDBERG VIDEO COMMUNICATION SERVER
ADMINISTRATOR GUIDE
Text goes here
Introduction
Getting
Started
System
Overview
System
Configuration
H.323 & SIP
Configuration
Registration
Control
Zones and
Neighbors
Call
Processing
Firewall
Traversal
Bandwidth
Control
Maintenance
Appendices
TANDBERG
ADMINISTRATOR GUIDE
TANDBERG VIDEO COMMUNICATION SERVER
ADMINISTRATOR GUIDE
Call
Processing
Types of DNS Records Required
The ability of the VCS to receive incoming calls made via URI
dialing relies on the presence of DNS records for each domain
the VCS is hosting.
These records can be of various types including:
A records, which provide the IPv4 address of the VCS
AAAA records, which provide the IPv6 address of the VCS
Service (SRV) records, which specify the FQDN of the VCS
and the port on it to be queried for a particular protocol and
transport type.
As a preference, SRV records should be used, and you should
provide an SRV record for each combination of domain hosted
and protocol and transport type enabled on the VCS.
•
•
•
URI Dialing for Incoming Calls
URI Dialing
Configuring H.323 SRV Records
Annex O of H.323 [15] defines the procedures for using DNS to locate
gatekeepers and endpoints and for resolving H.323 URL aliases. It also defines
parameters for use with the H.323 URL.
The VCS supports two types of SRV record as defined by this Annex. These are
Location and Call, with _ Service set to _ h323ls and _ h323cs respectively.
If you wish the VCS to be contactable via H.323 URI dialing, you should provide
at least a Location SRV record, as it provides the most flexibility and the
simplest configuration.
Location SRV Records
For each domain hosted by the VCS, you should configure a Location SRV record
as follows:
_ Service is _ h323ls
_ Proto is _ udp
Port is the port number that has been configured via VCS Configuration >
Protocols > H.323 as the Registration UDP port.
Call SRV Records
Call SRV records (and A/AAAA records) are intended primarily for use by
endpoints which cannot participate in a location transaction, exchanging LRQ
and LCF. The configuration of a Call SRV record should be as follows:
_ Service is _ h323cs
_ Proto is _ tcp
Port is the port number that has been configured via VCS Configuration >
Protocols > H.323 as the Call signaling TCP port.
•
•
•
•
•
•
SRV Record Format
The format of SRV records is defined by RFC 2782 [3] as:
_ Service. _ Proto.Name TTL Class SRV Priority Weight Port Target
For the VCS, these will be as follows:
_ Service and _ Proto will be different for H.323 and SIP, and will depend on the protocol and transport type being used.
Name is the domain in the URI that the VCS is hosting (e.g. example.com)
Port is the port on the VCS that has been configured to listen for that particular service and protocol combination
Target is the FQDN of the VCS.
•
•
•
•
Configuring SIP SRV Records
RFC 3263 [16] describes the DNS procedures
used to resolve a SIP URI into the IP address,
port, and transport protocol of the next hop to
contact.
If you wish the VCS to be contactable via
SIP URI dialing, you should configure an SRV
record for each SIP transport protocol enabled
on the VCS (i.e. UDP, TCP or TLS) as follows:
_ Service is _ sip
_ Proto is one of _ udp, _ tcp, or _ tls
Port is the port number that has been
configured via VCS Configuration > Protocols
> SIP as the port for that particular
transport protocol.
•
•
•
Process
When an incoming call has been placed using URI dialing, the
VCS will have been located by the calling system via one of the
DNS record lookups described above. It will receive the request
containing the dialled URI in the form user@xample.com. The
VCS will then check its local registrations and FindMe names
and if any are an exact match, the call will be routed to the
appropriate device(s).
In order for locally registered endpoints to be reached
using URI dialing, they must register using a full URI.
This applies to both SIP and H.323 endpoints. If
endpoints do not register using a full URI, they will be
discoverable only by the VCS to which they are registered, and
any neighbor VCSs.
Several mechanisms could have been used to locate the
VCS. You may wish to enable calls placed to
user@VCS_IP_address to be routed to an existing
registration for user@example.com. In this case you would
configure a Local Zone Transform that would strip the
IP address of the VCS from the incoming URI and replace it with
the domain name of example.com.