AudioCodes Mediant 2000, Руководство пользователя

Страница: 384 / 418

SIP User's Manual 384 Document #: LTRT-68808
Mediant 2000
The NTP client follows a simple process in managing system time: the NTP client requests
an NTP update, receives an NTP response, and then updates the local system clock based
on a configured NTP server within the network.
The client requests a time update from a specified NTP server at a specified update
interval. In most situations, this update interval is every 24 hours based on when the system
was restarted. The NTP server identity (as an IP address) and the update interval are user-
defined using either the Web interface (refer to ''Configuring the Application Settings'' on
page
57 ), the
ini
file (NTPServerIP and NTPUpdateInterval respectively), or an SNMP MIB
object (refer to the
Product Reference Manual
).
When the client receives a response to its request from the identified NTP server, it must be
interpreted based on time zone or location offset that the system is to a standard point of
reference called the Universal Time Coordinate (UTC). The time offset that the NTP client
uses is configurable using the Web interface (refer to ''Configuring the Application Settings''
on page
57 ), the
ini
file (NTPServerUTCOffset), or via an SNMP MIB object (refer to the
Product Reference Manual
).
If required, the clock update is performed by the client as the final step of the update
process. The update is performed in such a way as to be transparent to the end users. For
instance, the response of the server may indicate that the clock is running too fast on the
client. The client slowly robs bits from the clock counter to update the clock to the correct
time. If the clock is running too slow, then in an effort to catch the clock up, bits are added
to the counter, causing the clock to update quicker and catch up to the correct time. The
advantage of this method is that it does not introduce any disparity in the system time that
is noticeable to an end user or that could corrupt call timeouts and timestamps.
8.8 IP QoS via Differentiated Services (DiffServ)
DiffServ is an architecture providing different types or levels of service for IP traffic. DiffServ
(according to RFC 2474) offers the capability to prioritize certain traffic types depending on
their priority, thereby, accomplishing a higher-level QoS at the expense of other traffic
types. By prioritizing packets, DiffServ routers can minimize transmission delays for time-
sensitive packets such as VoIP packets.
The device can be configured to set a different DiffServ value to IP packets according to
their class-of-service: Network, Premium Media, Premium Control, Gold, and Bronze. The
DiffServ parameters are described in ''Networking Parameters'' on page
260 .
For the mapping of an application to its class-of-service, refer to ''IEEE 802.1p/Q (VLANs
and Priority)'' on page
385 .
8.9 VLANS and Multiple IPs
8.9.1 Multiple IPs
Media, Control, and Management (OAMP) traffic in the device can be assigned one of the
following IP addressing schemes:
„
Single IP address for all traffic
(i.e., for Media, Control, and OAMP).
„
Separate IP address for each of the three traffic types:
The different traffic types
are separated into three dedicated networks. Instead of a single IP address, the device
is assigned three IP addresses and subnet masks, each relating to a different traffic
type. This architecture enables you to integrate the device into a three-network
environment that is focused on security and segregation. Each entity in the device
(e.g., Web and RTP) is mapped to a single traffic type (according to the table in ''IEEE
802.1p/Q (VLANs and Priority)'' on page
385 ) in which it operates.