TANDBERG D14049.04 Network Card User Manual


  Open as PDF
of 276
 
122
D14049.04
JULY 2008
Grey Headline (continued)
TANDBERG VIDEO COMMUNICATIONS SERVER
ADMINISTRATOR GUIDE
Introduction Getting Started
Overview and
Status
System
Conguration
VCS
Conguration
Zones and
Neighbors
Call
Processing
Bandwidth
Control
Firewall
Traversal
Appendices
Applications Maintenance
URI Dialing
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.
NAPTR records
•
, which specify SRV record and transport
preferences for a SIP domain.
You should provide an SRV or NAPTR record for each
combination of domain hosted and protocol and transport type
enabled on the VCS.
URI Dialing for Incoming Calls
Conguring H.323 SRV Records
Annex O of H.323 [15] denes the procedures for using DNS to locate
gatekeepers and endpoints and for resolving H.323 URL aliases. It also denes
parameters for use with the H.323 URL.
The VCS supports two types of SRV record as dened 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 exibility and the simplest
conguration.
Location SRV Records
For each domain hosted by the VCS, you should congure a Location SRV record
as follows:
_ Service
•
is _ h323ls
_ Proto
•
is _ udp
Port
•
is the port number that has been congured via VCS Conguration >
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
conguration of a Call SRV record should be as follows:
_ Service
•
is _ h323cs
_ Proto
•
is _ tcp
Port
•
is the port number that has been congured via VCS Conguration >
Protocols > H.323 as the Call signaling TCP port.
SRV Record Format
The format of SRV records is dened 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 congured to listen for that particular service and protocol combination
Target
•
is the FQDN of the VCS.
Conguring 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 congure an SRV record
for each SIP transport protocol enabled on the
VCS (i.e. UDP, TCP or TLS) as follows:
Valid combinations of
•
_ Service and
_ Proto are:
_ sips. _ tcp
•
_ sip. _ tcp
•
_ sip. _ udp
•
Port
•
is the port number that has been
congured via VCS Conguration > 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. The VCS
will receive the request containing the dialed URI in the
form user@example.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).
 previous next