Mitel Deutschland GmbH 68635RFP36U-01 ユーザーズマニュアル

 

 

 

276 

To manage a larger RFP network, an SNMP agent is provided for each RFP. This will give alarm 
information and allow an SNMP management system (such as “HP Open View”) to manage this network. 
The SNMP agents can be configured in the 

SNMP menu of the OM Web service (see section 5.4.6).  

All SNMP agents are configured by the OMM. Additional parameters that are valid for the individual RFP 
(e.g. “sysLocation” and “sysName”) are generated. The “sysLocation” parameter corresponds to the 
location configured via the OMM web interface. The “sysName” parameter is generated using the MAC 
address and the RFP device type (e.g. RFP 43 WLAN). The RFP uptime can be requested by reading 
the “sysUpTime” parameter. This value indicates how long the RFP application software is running. It 
does not indicate the uptime of the operating system which does not correspond to the operational RFP 
state. 

The SNMP agent responds to SNMPv1-read and SNMPv2c-read requests for the standard MIB-II 
objects. The Management Information Base (MIB-II) contains 11 object groups. The agent receives both 
SNMPv1 and SNMPv2c traps. It sends a “coldStart” trap when it first starts up. It also sends an 
enterprise-specific trap “nsNotifyShutdown” when it stops. When the SNMP agent receives an SNMP 
request using an unknown community name, it sends an “authenticationFailure” trap. The SNMP agent 
also generates an enterprise-specific trap “nsNotifyRestart” (rather than the standard “coldStart” or 
“warmStart” traps) after being reconfigured. 

 

 

 

This section provides an overview about the supported redundancy concepts with SIP-DECT to realize a 
high availability solution together with IPBX redundancy mechanism. 

The focus of this section is IPBX redundancy. For information regarding OMM redundancy, see section 
7.15. 

To allow IPBX systems to spread the registration and call traffic over different servers the OMM supports 
301 (Moved Permanently) or 302 (Moved Temporarily) responses for registrations. 

When a 301 or 302 response is received, the OMM follows the redirect and registers the concerning user 
to the given address. If more than one contact address are given in the 301/302 response, the OMM 
tries to contact the registrars successively until the registration succeeds. 

If the redirected register succeeds and if the configured proxy and registrar are identical, all subsequent 
INVITE requests are sent to the redirected server. In the other case all subsequent INVITE requests will 
be sent to the (outbound) proxy or secondary/tertiary (outbound) proxy.