CISCO-WAN-MGC-REDUN-MIB: View SNMP OID List / Download MIB

The MIB module for Media Gateways (MGs) to allow multiple Media Gateway Controllers (MGCs) to be configured and managed on the Gateway. MGCs can be group together as part of the same MGC redundancy group. Terms used: CA: Call Agent GW: Gateway MGC: Media Gateway Controller MGCP: Media Gateway Control Protocol NTFY: Notify message (MGCP standard message) RSIP: Restart In Progress (MGCP standard message) RSVP: Resource Reservation Setup Protocol SGCP: Simple Gateway Control Protocol SRCP: Simple Resource Coordination Protocol

Multiple Media Gateway Controllers can be grouped together as part of the same MGC redundancy group. This configuration supports the notion of redundant Media Gateway Controllers. This table keeps track of the MGCs in a redundancy group. It is used to create MGC redundancy groups. MGCs can also be removed from a group.

Each row in the table is identified by an mgcRedundancyGrpNum and mgcNumber. Before adding an entry into this table the MGC has to be added in mgcTable defined in CISCO-WAN-MG-MIB. A single mgcRedundancyGrp can have multiple MGCs.

This is the MGC group number. A group can contain more than 1 MGC. So for a group containing more than 1 MGC, there will be more than 1 row of this table that will have a common group number.

Allows to configure the preference on a MGCs. The GW use this object in the selection of an MGC when there are multiple MGCs in the same MGC redundancy group. This object can be modified at any time while the mgcRedundancyGrpRowStatus is 'active'. It has to be unique among various MGCs of a same MGC redundancy group. The lower the number the higher the preference, for example 1 will have higher preference than 2.

This object is used to denote the status of MGC within an MGC Redundancy group. 'mgcActive' - Indicates the MGC is active or controlling the GW. 'mgcInactive' - Indicates the MGC is in standby state. Enumeration: 'mgcActive': 1, 'mgcInactive': 2.

Controls the creation and deletion of a table entry. An entry may be created using the 'createAndGo' option. When the row is successfully created, the RowStatus would be set to 'active' by the agent. An entry may be deleted by setting the RowStatus to 'destroy'. Other options such as `createAndWait', 'notInService', 'notReady' are not supported. mgcRedundancyGrpNum, mgcNumber and mgcRedundancyGrpPref are the mandatory parameters while creating an entry.

This table contains the parameters of the MGC redundancy groups like the association state and priority of the group within the GW. An entry in this table is implicitly created when the first MGC is added for an MGC redundancy group. The objects are set to their default values. When the last MGC from an MGC redundancy group is removed, the corresponding entry from this table is implicitly removed.

Represents an individual entry in the mgcRedundancyGrpParamTable.

This object 'true(1) will enable sending state change notifications to the MGC. 'false(2)' will disable sending state change notifications to MGC, for example, if MGCP/SGCP is the protocol used, then RSIPs are sent to the MGC if this object is set to 'true(1)'.

Represents the state of the communication between the GW and the MGC (call agent) group. The possible values are: 'commOk': This indicates that the communication between the gateway and the media gateway controller is ok. 'commLoss': This indicates that the communication between the GW and the MGC is lost. This object is set to 'commLoss' if no response is receive from any MGC in this group to a GW initiated message. If the GW is able to successfully send a message to the MGC or if a message is received from the MGC, the value of this object is set to 'commOk' else it will remain in the 'commLoss' state. Enumeration: 'commOk': 1, 'commLoss': 2.

This field determines the priority amongst the MGC redundancy groups within the GW. A MGC group with a priority of 0 means that the MGC group is not interested in receiving GW initiated messages. A group with a priority value of 1 has the highest preference. A higher value indicates a lower preference. Multiple MGC redundancy groups can have the same priority.

This table contains information about which protocols are being used in a particular association between the gateway and the MGC redundancy groups. Because there may be a number of different protocols in use for a particular control association between the gateway and an MGC group, this information is kept in a separate table rather than being included in mgcRedundancyGrpTable. In effect, it constitutes a relationship between mgcRedundancyGrpTable and mgSupportedProtocolTable defined in CISCO-WAN-MG-MIB. This table restricts all MGCs within a MGC redundancy group to have the same set of protocols defined.

Represents an individual table entry in mgcRedundancyGrpProtocolTable. When active, it is expected that mgcRedundancyGrpNum and mgProtocolNumber contain valid values that maintain referential integrity into mgcRedundancyGrpTable and mgSupportedProtocolTable respectively. The attempt to create a row that would violate referential integrity shall be rejected.

Controls the creation and deletion of a table entry. An entry may be created using the 'createAndGo' option. When the row is successfully created, the mgcRedundancyGrpProtocolRowStatus would be set to 'active' by the agent. An entry can be modified at any time while the mgcRedundancyGrpProtocolRowStatus is 'active'. An entry may be deleted by setting the mgcRedundancyGrpProtocolRowStatus to 'destroy'.

This object determines how the persistent events will be notified. Persistent events are events that call agent wants to be notified without explicitly requesting for it. A set of events can be provisioned on the Gateway as persistent events. Every event will have an action associated with it, which will determine, whether to be notified, ignored, accumulated etc.. MGC will specify the action when requesting the GW to notify the event. For persistent events the Action will be Notify. Call agent can change this by explicitly requesting the event associating an action with it. During the period where the Gateway has received a notification acknowledgement, and waiting for the next Request Notification, events could be observed. The Quarantine procedure determines what should be done with these events. This object is used to supercede the quarantine procedure, by enforcing loop, process as the quarantine procedure only for persistent events. During the period the Gateway has sent a Notification, and waiting for the acknowledgement all events including the persistent events will 'quarantinePersistEvts' - Quarantine Persistent events as in the case of non persistent events as determined by quarantine method. 'notQuarantinePersistEvts' - Don't quarantine Persistent events, and notify them. During the period the Gateway has sent a Notify and waiting for the acknowledgement, every event including persistent event will be quarantined. This value does not supercede that behaviour. This applies only during the period, where a Notify is acknowledged and waiting for the next RQNT where the quarantine method is 'step,process' or 'step,discard'. This object has no relevance when the protocol is SRCP. Enumeration: 'notQuarantinePersistEvts': 2, 'quarantinePersistEvts': 1.

This object determines the quarantine policy when MGC doesn't explicitly specify one. When a Request Notification is received from the MGC, the Gateway on observing the first event that qualifies to be notified will generate a Notify message with the list of observed events including the event which triggered the Notify. After the MGC acknowledges the Notify, if further events are observed and an event which qualifies to be notified, the Gateway may notify the event, or quarantine it until the next Request Notification, based on the quarantine policy set by the MGC. When the MGC doesn't explicitly specify the quarantine policy, the protocol defines the default behaviour. The default behaviour varies with different versions of the protocol. This object allows the user to configure the default quarantine policy per protocol per redundancy group. The default value for this object will be set based on the protocol. 'stepProcess' - Process the events in the quarantine list, and after one Notify quarantine events until next Request Notification 'stepDiscard' - Discard the events in the quarantine list, and after one Notify quarantine events until next Request Notification 'loopProcess' - Process the events in the quarantine list, and notify observed events as and when need arises 'loopDiscard' - Discard the events in the quarantine list, and notify observed events as and when need arises The default value for MGCP 1.0 will be stepProcess and stepDiscard for the rest. This object has no relevance when the protocol is SRCP. Enumeration: 'loopProcess': 3, 'loopDiscard': 4, 'stepProcess': 1, 'stepDiscard': 2.

This object enables the user to provision the way signaled events from CA are handled by the gateway. This is configurable on a per MGC redundancy group, per protocol basis. If the protocol is MGCP 1.0 the default of this object is 'deleteOnlyNegatedEvent', else it is set to 'deleteEventNotPresent'. If this object is set to 'deleteOnlyNegatedEvent', then the signal currently active on a endpoint/connection can be turned OFF only by parameterizing it with a (-) for eg: S: T/co1(-) will turn off co1 event on an endpoint. And can be turned ON by just providing the signal name or by parameterizing the signal name with a (+) for eg: S:T/co1(+), L/hd will turn on co1 and hd events on the endpoint. If this object is set to 'deleteEventNotPresent', then the signal/s can be turned OFF by providing empty S: list. The signal can be turned ON by simply providing the signal name. for eg: S: will turn OFF all active signals on the endpoint S: T/co1 will turn ON co1 signal. The configuration of this object only applies to on/off signals and not for brief or timeout signals. MGCP 0.1 specification says if an empty signaled list is provided it is meant to turn off all the currently turned on signaled events. However in MGCP 1.0 specification, it says that unless specifically requested by the CA to turn off (signal is parameterized by a (-)) the signal cannot be turned off, in other words an empty signal list does imply that the currently active signals should be turned off. Although the behavior of the gateway is specified in the specs, some MGC may not follow the MGCP 1.0 spec. Hence this MIB serves as an interop knob. This object has no relevance when the protocol is SRCP. Enumeration: 'deleteOnlyNegatedEvent': 2, 'deleteEventNotPresent': 1.

This object enables or disables sending provisional response to the CA when processing a request received from the CA. The provisional response to the CA indicates that the GW is processing the request and will send a final response once the processing is complete. For example, if a CRCX request from the CA using MGCP protocol, requires that resources be reserved along the bearer path using RSVP, GW would send a provisional response if this parameter was set to true. It would then wait for the RSVP procedure to complete before sending the final response. On the other hand, if the value of this parameter was set to false, the final response will be sent out without waiting for the RSVP procedure to complete. When the RSVP procedure does complete, a NTFY will be sent from the GW indicating if the RSVP procedure was successful or not. The GW will receive provisional responses from the CA. These messages will be parsed and ignored regardless of this object. If the protocol supported by the CA is MGCP1.0, the default value for this object is 'sendProvisionalResponse'. In all other cases, it is 'notSendProvisionalResponse'. This object has no relevance when the protocol is SRCP. Enumeration: 'notSendProvisionalResponse': 2, 'sendProvisionalResponse': 1.

Every command from the MGC could contain Response Acknowledgement attribute. This attribute consists a list of transaction IDs which are acknowledged by the Call agent. The gateway on receiving this can free up the resources attached to this transaction ID. When this attribute is present in the Gateway response, it should contain an empty list of transaction ID. This attribute in the response from the Gateway is to invite a response acknowledgement message from the MGC for this response. This will be present in the final response sent by the gateway only when a provisional response had been sent prior to this final response for the same transaction. This object determines whether the Gateway should include response acknowledgement in the final response. This object does not determine the capability of the Gateway to receive response acknowledgement attribute as part of MGC commands. 'sendResponseAckAttr' - Gateway will include response acknowledgement attribute as part of final response when a provisional response had been sent earlier. 'notSendResponseAckAttr' - Gateway will not include response acknowledgement attribute as part of final response when a provisional response had been sent earlier. The default value will be 'sendResponseAckAttr' for MGCP 1.0 protocol and 'notSendResponseAckAttr' for every other protocol. This object has no relevance when the protocol is SRCP. Enumeration: 'notSendResponseAckAttr': 2, 'sendResponseAckAttr': 1.

This attribute describes whether disconnected procedure is enabled/disabled per protocol per MGC group configured. The endpoint becomes disconnected when a gateway initiated commands are sent to the MGC and has not received any response from the MGC. The disconnected endpoint initiates the disconnected procedure by sending Restart in Progress command with restart method RM:disconnected to the MGC. When the object is set to 'doDisconnectProcedure', then the endpoint will start the disconnected procedure and sends 'Restart In Progress' command with the restart method RM:disconnected to the MGC. By default, the object is set to 'doDisconnectProcedure' for MGCP 1.0 and 'notDoDisconnectProcedure' for all other protocols. This object has no relevance when the protocol is SRCP. Enumeration: 'doDisconnectProcedure': 1, 'notDoDisconnectProcedure': 2.

This attribute describes whether notification of RSIP cancel graceful is enabled/disabled per protocol per MGC group configured. The Restart in Progress command with the restart method of cancel graceful indicates that the gateway is canceling a previously issued 'graceful' restart in progress command. The endpoints are still in service. When the object is set to 'sendCancelGraceful', the gateway will send the Restart in Progress command with the restart method of cancel graceful indicating that it is canceling the previously sent 'graceful' Restart in Progress command. By default, the object is set to 'sendCancelGraceful' for MGCP 1.0 and 'notSendCancelGraceful' for all other protocols. This object has no relevance when the protocol is SRCP. Enumeration: 'notSendCancelGraceful': 2, 'sendCancelGraceful': 1.

The compliance statement for the SNMP entities which implement MGC-REDUN-MIB.

This group contains objects that apply to the redundant media gateway controller group.

This group contains objects that describe the parameters of an MGC redundancy group.

This group contains the protocols configured for an MGC redundancy group.