Version 6.2 619 February 2011
SIP User's Manual 9. VoIP Networking Capabilities
♦ Inbound media re-latch during a silence period: If a silence compression
RTP packet is received, latching new RTP streams is disabled until a silence
timeout expires. Currently, RTP packets with payload types 13 and 19 are
considered silence compression packets. Each new silence compression
RTP packet resets the timeout’s timer.
♦ Fax relay: No RTP re-latch is allowed if a T.38 fax relay session is underway.
It is re-allowed after the T.38 session ends and timeout.
The reason for the above cases is to avoid re-latch on another RTP stream due
to “missing” activity on the currently active one, if no activity is expected. If a
switch from a non-original RTP stream to the original one occurs, both special
cases are ignored and the original stream is accepted immediately.
If an inbound media stream latch occurs, the outbound media stream latch (redirecting
outgoing media packets) is also (optionally) performed, according to the DisableNAT
parameter (see First Incoming Packet Mechanism on page 617).
9.3 Multiple Routers Support
Multiple routers support is designed to assist the device when it operates in a multiple
routers network. The device learns the network topology by responding to Internet Control
Message Protocol (ICMP) redirections and caches them as routing rules (with expiration
time).
When a set of routers operating within the same subnet serve as devices to that network
and intercommunicate using a dynamic routing protocol, the routers can determine the
shortest path to a certain destination and signal the remote host the existence of the better
route. Using multiple router support, the device can utilize these router messages to
change its next hop and establish the best path.
Note: Multiple Routers support is an integral feature that doesn’t require
configuration.
9.4 Simple Network Time Protocol Support
The Simple Network Time Protocol (SNTP) client functionality generates requests and
reacts to the resulting responses using the NTP version 3 protocol definitions (according to
RFC 1305). Through these requests and responses, the NTP client synchronizes the
system time to a time source within the network, thereby eliminating any potential issues
should the local system clock 'drift' during operation. By synchronizing time to a network
time source, traffic handling, maintenance, and debugging become simplified for the
network administrator.
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 the ini file parameters NTPServerIP and NTPUpdateInterval
respectively), or an SNMP MIB object (refer to the Product Reference Manual).
To Next Page
Loading...
