User`s manual
Table Of Contents
- Mediant 2000 & TP-1610 & TP-260/UNI SIP User’s Manual Version 5.0
- Table of Contents
- List of Figures
- List of Tables
- Notices
- 1. Overview
- 2. Physical Description
- 3. Installation
- 4. Getting Started
- 5. Web Management
- Computer Requirements
- Protection and Security Mechanisms
- Accessing the Embedded Web Server
- Getting Acquainted with the Web Interface
- Protocol Management
- Advanced Configuration
- Status & Diagnostic
- Software Update Menu
- Maintenance
- Logging Off the Embedded Web Server
- 6. Gateway's ini File Configuration
- Secured ini File
- Modifying an ini File
- The ini File Content
- The ini File Structure
- The ini File Example
- Networking Parameters
- System Parameters
- Web and Telnet Parameters
- Security Parameters
- RADIUS Parameters
- SNMP Parameters
- SIP Configuration Parameters
- Voice Mail Parameters
- ISDN and CAS Interworking-Related Parameters
- Number Manipulation and Routing Parameters
- E1/T1 Configuration Parameters
- Channel Parameters
- Configuration Files Parameters
- 7. Using BootP / DHCP
- 8. Telephony Capabilities
- Working with Supplementary Services
- Configuring the DTMF Transport Types
- Fax & Modem Transport Modes
- Event Notification using X-Detect Header
- ThroughPacket™
- Dynamic Jitter Buffer Operation
- Configuring the Gateway’s Alternative Routing (based on Conn
- Call Detail Report
- Supported RADIUS Attributes
- Trunk to Trunk Routing Example
- Proxy or Registrar Registration Example
- SIP Call Flow Example
- SIP Authentication Example
- 9. Networking Capabilities
- 10. Advanced PSTN Configuration
- 11. Advanced System Capabilities
- 12. Special Applications
- 13. Security
- 14. Diagnostics
- 15. SNMP-Based Management
- SNMP Standards and Objects
- Carrier Grade Alarm System
- Cold Start Trap
- Third-Party Performance Monitoring Measurements
- TrunkPack-VoP Series Supported MIBs
- Traps
- SNMP Interface Details
- SNMP Manager Backward Compatibility
- Dual Module Interface
- SNMP NAT Traversal
- SNMP Administrative State Control
- AudioCodes’ Element Management System
- 16. Configuration Files
- Appendix A. Selected Technical Specifications
- Appendix B. Supplied SIP Software Kit
- Appendix C. SIP Compliance Tables
- Appendix D. The BootP/TFTP Configuration Utility
- Appendix E. RTP/RTCP Payload Types and Port Allocation
- Appendix F. RTP Control Protocol Extended Reports (RTCP-XR)
- Appendix G. Accessory Programs and Tools
- Appendix H. Release Reason Mapping
- Appendix I. SNMP Traps
- Appendix J. Installation and Configuration of Apache HTTP Server
- Appendix K. Regulatory Information

SIP User's Manual 9. Networking Capabilities
Version 5.0 229 October 2006
9 Networking Capabilities
9.1 Ethernet Interface Configuration
Using the parameter ‘EthernetPhyConfiguration‘, users can control the Ethernet connection
mode.
Either the manual modes (10 Base-T Half-Duplex, 10 Base-T Full-Duplex, 100 Base-TX
Half-Duplex, 100 Base-TX Full-Duplex) or Auto-Negotiate mode can be used.
Auto-Negotiation falls back to Half-Duplex mode when the opposite port is not Auto-
Negotiate, but the speed (10 Base-T, 100 Base-TX) in this mode is always configured
correctly. Note that configuring the gateway to Auto-Negotiate mode while the opposite port
is set manually to Full-Duplex (either 10 Base-T or 100 Base-TX) is invalid (as it causes the
gateway to fall back to Half-Duplex mode while the opposite port is Full-Duplex). It is also
invalid to set the gateway to one of the manual modes while the opposite port is either
Auto-Negotiate or not exactly matching (both in speed and in duplex mode). Users are
encouraged to always prefer Full-Duplex connections to Half-Duplex ones and 100 Base-
TX to 10 Base-T (due to the larger bandwidth). It is strongly recommended to use the same
mode in both link partners. Any mismatch configuration can yield unexpected functioning of
the Ethernet connection.
Note that when remote configuration is performed, the gateway should be in the correct
Ethernet setting prior to the time this parameter takes effect. When, for example, the
gateway is configured using BootP/TFTP, the gateway must perform many Ethernet-based
transactions prior to reading the ini file containing this gateway configuration parameter.
To work around this problem, the gateway always uses the last Ethernet setup mode
configured. This way, if users want to configure the gateway to work in a new network
environment in which the current Ethernet setting of the gateway is invalid, they should first
modify this parameter in the current network so that the new setting holds next time
gateway is restarted. After reconfiguration has completed, connect the gateway to the new
network and restart it. As a result, the remote configuration process that takes place in the
new network uses a valid Ethernet configuration.
9.2 Ethernet Interface Redundancy
The Mediant 2000 supports the following redundancy scheme:
At the beginning of the start-up procedure, the gateway tests whether the ‘Primary’
Ethernet interface is connected by checking the existence of the Ethernet link carrier. If it is
connected, the start-up procedure commences as usual. If not, the start-up application tries
the ‘Secondary’ Ethernet interface. If this interface is connected, the whole start-up
procedure is performed using it. If both interfaces are out of order, the start-up procedure
commences using the parameters, tables, and software residing in the gateway’s non-
volatile memory. Note that Ethernet switchover occurs only once during the start-up
procedure (at its beginning). If the Ethernet interface fails after the selection is made, the
gateway does not switch over to the second port.
After start-up has completed and the operational software is running, the gateway
continues to use the Ethernet port used for program load. The gateway switches over from
one Ethernet port to the other one every time an Ethernet link carrier loss is detected on
the active Ethernet port, and if the Ethernet link of the other port is operational. Switchover
takes place only once per link loss (that is, the ‘secondary’ interface stays the active one
even if the ‘primary’ interface has returned to life).
After start-up, the gateway generates a gratuitous ARP message each time a switchover
occurs.