CISCO-VISM-DSX0-MIB :: ds0CasGlarePolicy

MIB Reference — IPNetwork Monitor · Updated September 14, 2026

All MIBsCISCO-VISM-DSX0-MIBds0CasGlarePolicy

ds0CasGlarePolicy

Module: CISCO-VISM-DSX0-MIB

OID (symbolic): CISCO-VISM-DSX0-MIB::ds0CasGlarePolicy

OID (numeric): 1.3.6.1.4.1.351.110.4.7.1.1.30

Node type: OBJECT-TYPE

Type: INTEGER

Access: read-write

Description: This object specifies how a bidirectional endpoint should resolve glare. This object will be used only if dsx0VismDirectionality of the endpoint is 'bidirectional'. When glare is detected, if this object is set to controlling, VISM will wait for the connected PBX to assert on-hook. When the connected PBX goes on-hook, VISM proceeds to dial the numbers out waits for answer.

If this object is set to releasing(2), VISM indicates the glare situation to the Call Agent (as specified by the control protocol), prepares to collect digits from the PBX and asserts on hook. The incoming call should go through. If the CAS protocol assigned to the endpoint cannot detect glare or if it cannot resolve glare according to the policy provisioned via this object, this object will not be used.

This object cannot be configured if the signaling type for the DS1 line to which this ds0 belongs is non-CAS.

For a CAS line, this object can only be configured after associating this ds0 with an endpoint. This means that if no endpoint was added for this Ds0, any configuration set attempt will be rejected, but any get will be allowed.

What is ds0CasGlarePolicy?

This read-write INTEGER specifies how a bidirectional endpoint resolves a glare condition: controlling (VISM waits for the PBX to go on-hook before proceeding) or releasing. This policy matters only when the endpoint's directionality is bidirectional and both sides attempt to originate a call simultaneously, so an admin picks the policy that matches how they want simultaneous-call collisions resolved. For example, on a busy bidirectional trunk where glare is common, an admin might choose controlling to have VISM defer to the PBX rather than releasing the call attempt outright.

Examples

Walk all instances (SNMPv2c):

snmpwalk -v2c -c public <target> 1.3.6.1.4.1.351.110.4.7.1.1.30
snmpwalk -v2c -c public <target> CISCO-VISM-DSX0-MIB::ds0CasGlarePolicy

Get a specific instance (index 1):

snmpget -v2c -c public <target> 1.3.6.1.4.1.351.110.4.7.1.1.30.1
snmpget -v2c -c public <target> CISCO-VISM-DSX0-MIB::ds0CasGlarePolicy.1

Set instance 1 (SNMPv2c):

snmpset -v2c -c private <target> 1.3.6.1.4.1.351.110.4.7.1.1.30.1 i <value>

Start monitoring Cisco VISM (Voice Interworking Service Module) card, MGX platform (legacy) with a free 30-day trial of IPNetwork Monitor. Create custom SNMP monitor using the CISCO-VISM-DSX0-MIB::ds0CasGlarePolicy OID value, configure state conditions and alerts, and monitor any Cisco VISM (Voice Interworking Service Module) card, MGX platform (legacy) from a single console.

OID Breakdown

Upper-level ancestors (10 from the standard OID tree / other modules)
Numeric OIDNameModule
1isoLANART-AGENT
1.3orgAirPair-MIB
1.3.6dodAirPair-MIB
1.3.6.1internetAirPair-MIB
1.3.6.1.4privateAirPair-MIB
1.3.6.1.4.1enterprisesAirPair-MIB
1.3.6.1.4.1.351stratacomCISCOWAN-SMI
1.3.6.1.4.1.351.110basisBASIS-MIB
1.3.6.1.4.1.351.110.4basisLinesBASIS-MIB
1.3.6.1.4.1.351.110.4.7dsx0VismBASIS-MIB
Numeric OIDNameModule
1.3.6.1.4.1.351.110.4.7.1dsx0VismCnfTableCISCO-VISM-DSX0-MIB
1.3.6.1.4.1.351.110.4.7.1.1dsx0VismCnfEntryCISCO-VISM-DSX0-MIB
1.3.6.1.4.1.351.110.4.7.1.1.30ds0CasGlarePolicyCISCO-VISM-DSX0-MIB