RFC 2128
Dial Control Management Information Base using SMIv2
RFC 2128: Dial Control Management Information Base using SMIv2 💖
okay bestie, this one is the Dial Control MIB, which is an SNMP thing for managing dial-up and ISDN circuits 📞✨ here's the title block so you know who's behind it:
- RFC number: 2128
- Title: Dial Control Management Information Base using SMIv2
- Authors: G. Roeck, Editor (cisco Systems)
- Category: Standards Track
- Date: March 1997
- Obsoletes / Updates: the header doesn't list anything it obsoletes or updates
It's from the Network Working Group, so it's an official IETF standards track doc 🦋
Status of this Memo
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. 🎀
Abstract
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Basically it describes managed objects used for managing demand access circuits, including ISDN 📞
This document specifies a MIB module in a manner that is compliant to the SNMPv2 SMI. The set of objects is consistent with the SNMP framework and existing SNMP standards. Very on-brand, very consistent, very slay 💅
This document is a product of the ISDN MIB working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at isdn-mib@cisco.com and/or the author. So if you have thoughts, send them there 💌
Table of Contents
1 The SNMPv2 Network Management Framework ...................... 2
1.1 Object Definitions ......................................... 2
2 Overview ..................................................... 2
2.1 Structure of MIB ........................................... 2
2.2 Relationship to the Interfaces MIB ......................... 3
2.2.1 Layering Model and Virtual Circuits ...................... 3
2.2.2 ifTestTable .............................................. 4
2.2.3 ifRcvAddressTable ........................................ 4
2.2.3.1 ifEntry for a single peer .............................. 5
2.3 Multilink and backup line support .......................... 5
2.4 Support for generic peers .................................. 5
3 Definitions .................................................. 6
3.1 Dial Control MIB ........................................... 6
4 Acknowledgments .............................................. 32
5 References ................................................... 33
6 Security Considerations ...................................... 33
7 Author's Address ............................................. 341. The SNMPv2 Network Management Framework ✨
The SNMPv2 Network Management Framework is made up of three major pieces. They are:
- the SMI, described in RFC 1902 [1] - the mechanisms used for describing and naming objects for the purpose of management.
- the MIB-II, STD 17, RFC 1213 [2] - the core set of managed objects for the Internet suite of protocols.
- the protocol, STD 15, RFC 1157 [3] and/or RFC 1905 [4], - the protocol for accessing managed objects.
The Framework also lets people define new objects for experimenting and evaluating stuff 🧪
1.1. Object Definitions
Managed objects live in a virtual information store called the Management Information Base, or MIB 🗂️ Objects in the MIB are defined using the subset of Abstract Syntax Notation One (ASN.1) defined in the SMI. Each object type gets named by an OBJECT IDENTIFIER, which is an administratively assigned name. The object type together with an object instance is what uniquely identifies one specific instantiation of the object. For human convenience, people often use a textual string, called the descriptor, to refer to the object type 🙈
2. Overview 🌸
2.1. Structure of MIB
Managing demand access circuits needs these groups of information:
- General configuration information.
- Information to describe peer configuration and peer statistics. In this respect, peer configuration means information on how to connect to peers on outgoing calls, how to identify peers on incoming calls, and other call related configuration information.
- Information to store active call information.
- Information to retain call history.
So the MIB is structured into four groups:
- The
dialCtlConfigurationgroup is used to specify general configuration information. - The
dialCtlPeergroup is used to describe peer configuration and peer statistics. - The
callActivegroup is used to store active call information. - The
callHistorygroup is used to store call history information. These calls could be circuit switched or they could be virtual circuits. History of each and every call is stored, of successful calls as well as unsuccessful and rejected calls. An entry will be created when a call is cleared. every. single. call. gets logged. no ghosting allowed 📒
2.2. Relationship to the Interfaces MIB
This section explains how this MIB connects to the Interfaces MIB [8]. A few areas of overlap get covered in the subsections below. If you're the implementor, check out the Interfaces MIB document to get the general intent behind these areas 🧠
2.2.1. Layering Model and Virtual Circuits
On an occasional access channel, there are a bunch of peer systems that are allowed to call or be called. They all need to be treated as active from a routing viewpoint, even though most of them have no call in progress at any given time 💤
On dialup interfaces it gets messier, because calls to a given peer float from channel to channel. You can't definitively say "I call this peer on that interface." So there needs to be a mapping algorithm between the low-level interfaces and the various logical interfaces that support the peers. This is solved by creating a logical interface (ifEntry) for each peer, and a logical interface (ifEntry) for each low-level interface. These are then correlated using the ifStackTable 🔗
The low-level interfaces are either physical interfaces, e.g. modem interfaces, or logical interfaces, e.g. ISDN B channels, which in turn are layered on top of physical ISDN interfaces.
Here's the model, using ISDN as the example:
+-------------------------------------------------------+
| Network Layer Protocol |
+------+ +-------+ +-------+ +-------+ +-------+ +------+
| | | | | | | | | | <== appears active
+-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+
| PPP | | PPP | | F/R | | PPP | | F/R |
| for | | for | | for | | for | | for | ifEntry with
|Peer1| |Peer2| |switch |Peer3| |switch shadow PeerEntry
| | | | | A | | | | B |
+-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+
| | | | <== some actually are
+--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+
| B | | B | | B | | B | | B |
|channel| |channel| |channel| |channel| |channel|
+--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+
| | | | | | | | | |
+------+ +-------+ +-------+ +-------+ +-------+ +------+
| Basic/Primary Rate Interface |
+-------------------------------------------------------+
Mapping of IP interfaces to Called Peers to B ChannelsIfEntries are maintained for each peer. 🎀
In this model, each peer is required to have an associated encapsulation layer interface. That interface can be of any kind, e.g. PPP or LAPB. To specify the network address for a given peer, you'd usually add a routing/forwarding table entry that points to the encapsulation layer interface through which that peer can be reached 🗺️
2.2.2. ifTestTable
The ifTestTable usage is defined in the MIBs that define the encapsulation below the network layer. For example, if PPP encapsulation is being used, the ifTestTable is defined by PPP.
2.2.3. ifRcvAddressTable
The ifRcvAddressTable usage is defined in the MIBs that define the encapsulation below the network layer. For example, if PPP encapsulation is being used, the ifRcvAddressTable is defined by PPP.
2.2.3.1. ifEntry for a single peer
IfEntries are defined in the MIBs that define the encapsulation below the network layer. For example, if PPP encapsulation is being used, the ifEntry is defined by PPP.
ifEntries will never be created by the Dial Control MIB. The Dial Control MIB always depends on some other ifIndex from some set of ifTypes. That means that to create an entry in the Dial Control MIB, the base ifEntry must already have been created through some other mechanism 🚫
The Dial Control entry has its own RowStatus, which lets the Dial Control supplementary information come and go, but doesn't otherwise disturb the ifIndex it's attached to. If in a given implementation the two are tightly bound, deleting the ifEntry may have the side effect of deleting the Dial Control entry 💥
2.3. Multilink and backup line support
To support multilink and backup procedures, there may be several entries for a single peer in the dialCtlPeerCfgTable.
A single peer is identified using the dialCtlPeerCfgId object of the dialCtlPeerCfgTable. There may be several entries in dialCtlPeerCfgTable with the same value of dialCtlPeerCfgId, but different ifIndex values. Each of those entries then describes a possible connection to the same peer. Those entries can be used to handle multilink as well as backup procedures, e.g. by bundling the attached ifEntries using PPP multilink 🧩
2.4. Support for generic peers
Generic peers can be supported, for example, by permitting wild-card characters (e.g., '?' or '') in dialCtlPeerCfgAnswerAddress. A number to be accepted could then be defined as partly (e.g., '1234') or entirely generic (e.g., '*') 🃏
A detailed specification of that functionality is outside the scope of this document.
🚨 Heads up, this is serious: the implementor should be aware that supporting generic peers may cause a security hole. The user would not know where a call is from, which could potentially allow unauthorized access. Don't skip this one, bestie 🙅♀️
3. Definitions 📜
3.1. Dial Control MIB
DIAL-CONTROL-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY,
NOTIFICATION-TYPE,
OBJECT-TYPE,
Unsigned32
FROM SNMPv2-SMI
TEXTUAL-CONVENTION,
DisplayString,
TimeStamp,
RowStatus
FROM SNMPv2-TC
MODULE-COMPLIANCE,
OBJECT-GROUP,
NOTIFICATION-GROUP
FROM SNMPv2-CONF
IANAifType
FROM IANAifType-MIB
ifOperStatus,
ifIndex,
InterfaceIndex,
InterfaceIndexOrZero
FROM IF-MIB
transmission
FROM RFC1213-MIB;
dialControlMib MODULE-IDENTITY
LAST-UPDATED "9609231544Z" -- Sep 23, 1996
ORGANIZATION "IETF ISDN Working Group"
CONTACT-INFO
" Guenter Roeck
Postal: cisco Systems
170 West Tasman Drive
San Jose, CA 95134
U.S.A.
Phone: +1 408 527 3143
E-mail: groeck@cisco.com"
DESCRIPTION
"The MIB module to describe peer information for
demand access and possibly other kinds of interfaces."
::= { transmission 21 }Part 2 picks up right where this MIB module leaves off 🦋
Okay bestie, we're picking up right where the last part left off, and the MIB is about to get spicy 💅 Here's the textual convention for counters that never wrap 🦋
AbsoluteCounter32 ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Represents a Counter32-like value that starts at zero,
does not decrease, and does not wrap. This may be used
only in situations where wrapping is not possible or
extremely unlikely. Should such a counter overflow,
it locks at the maxium value of 4,294,967,295.
The primary use of this type of counter is situations
where a counter value is to be recorded as history
and is thus no longer subject to reading for changing
values."
SYNTAX Unsigned32Next up is the object tree, starting with the general configuration group 🎀
-- Dial Control Mib objects definitions
dialControlMibObjects OBJECT IDENTIFIER ::= { dialControlMib 1 }
-- General configuration group
dialCtlConfiguration OBJECT IDENTIFIER ::= { dialControlMibObjects 1 }
-- general configuration data/parameters
dialCtlAcceptMode OBJECT-TYPE
SYNTAX INTEGER {
acceptNone(1),
acceptAll(2),
acceptKnown(3)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The security level for acceptance of incoming calls.
acceptNone(1) - incoming calls will not be accepted
acceptAll(2) - incoming calls will be accepted,
even if there is no matching entry
in the dialCtlPeerCfgTable
acceptKnown(3) - incoming calls will be accepted only
if there is a matching entry in the
dialCtlPeerCfgTable
"
::= { dialCtlConfiguration 1 }
dialCtlTrapEnable OBJECT-TYPE
SYNTAX INTEGER {
enabled(1),
disabled(2)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object indicates whether dialCtlPeerCallInformation
and dialCtlPeerCallSetup traps should be generated for
all peers. If the value of this object is enabled(1),
traps will be generated for all peers. If the value
of this object is disabled(2), traps will be generated
only for peers having dialCtlPeerCfgTrapEnable set
to enabled(1)."
DEFVAL { disabled }
::= { dialCtlConfiguration 2 }Now the peer group, which is where the real fun is 🌸 Starting with the peer configuration table and its entries 🧚
-- Peer group
dialCtlPeer OBJECT IDENTIFIER ::= { dialControlMibObjects 2 }
-- peer configuration table
dialCtlPeerCfgTable OBJECT-TYPE
SYNTAX SEQUENCE OF DialCtlPeerCfgEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The list of peers from which the managed device
will accept calls or to which it will place them."
::= { dialCtlPeer 1 }
dialCtlPeerCfgEntry OBJECT-TYPE
SYNTAX DialCtlPeerCfgEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Configuration data for a single Peer. This entry is
effectively permanent, and contains information
to identify the peer, how to connect to the peer,
how to identify the peer and its permissions.
The value of dialCtlPeerCfgOriginateAddress must be
specified before a new row in this table can become
active(1). Any writeable parameters in an existing entry
can be modified while the entry is active. The modification
will take effect when the peer in question will be
called the next time.
An entry in this table can only be created if the
associated ifEntry already exists."
INDEX { dialCtlPeerCfgId, ifIndex }
::= { dialCtlPeerCfgTable 1 }
DialCtlPeerCfgEntry ::= SEQUENCE {
dialCtlPeerCfgId INTEGER,
dialCtlPeerCfgIfType IANAifType,
dialCtlPeerCfgLowerIf InterfaceIndexOrZero,
dialCtlPeerCfgOriginateAddress DisplayString,
dialCtlPeerCfgAnswerAddress DisplayString,
dialCtlPeerCfgSubAddress DisplayString,
dialCtlPeerCfgClosedUserGroup DisplayString,
dialCtlPeerCfgSpeed INTEGER,
dialCtlPeerCfgInfoType INTEGER,
dialCtlPeerCfgPermission INTEGER,
dialCtlPeerCfgInactivityTimer INTEGER,
dialCtlPeerCfgMinDuration INTEGER,
dialCtlPeerCfgMaxDuration INTEGER,
dialCtlPeerCfgCarrierDelay INTEGER,
dialCtlPeerCfgCallRetries INTEGER,
dialCtlPeerCfgRetryDelay INTEGER,
dialCtlPeerCfgFailureDelay INTEGER,
dialCtlPeerCfgTrapEnable INTEGER,
dialCtlPeerCfgStatus RowStatus
}
dialCtlPeerCfgId OBJECT-TYPE
SYNTAX INTEGER (1..2147483647)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This object identifies a single peer. There may
be several entries in this table for one peer,
defining different ways of reaching this peer.
Thus, there may be several entries in this table
with the same value of dialCtlPeerCfgId.
Multiple entries for one peer may be used to support
multilink as well as backup lines.
A single peer will be identified by a unique value
of this object. Several entries for one peer MUST
have the same value of dialCtlPeerCfgId, but different
ifEntries and thus different values of ifIndex."
::= { dialCtlPeerCfgEntry 1 }
dialCtlPeerCfgIfType OBJECT-TYPE
SYNTAX IANAifType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The interface type to be used for calling this peer.
In case of ISDN, the value of isdn(63) is to be used."
DEFVAL { other }
::= { dialCtlPeerCfgEntry 2 }
dialCtlPeerCfgLowerIf OBJECT-TYPE
SYNTAX InterfaceIndexOrZero
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"ifIndex value of an interface the peer will have to be
called on. For example, on an ISDN interface, this can be
the ifIndex value of a D channel or the ifIndex value of a
B channel, whatever is appropriate for a given peer.
As an example, for Basic Rate leased lines it will be
necessary to specify a B channel ifIndex, while for
semi-permanent connections the D channel ifIndex has
to be specified.
If the interface can be dynamically assigned, this object
has a value of zero."
DEFVAL { 0 }
::= { dialCtlPeerCfgEntry 3 }
dialCtlPeerCfgOriginateAddress OBJECT-TYPE
SYNTAX DisplayString
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Call Address at which the peer will be called.
Think of this as the set of characters following 'ATDT '
or the 'phone number' included in a D channel call request.
The structure of this information will be switch type
specific. If there is no address information required
for reaching the peer, i.e., for leased lines,
this object will be a zero length string."
::= { dialCtlPeerCfgEntry 4 }
dialCtlPeerCfgAnswerAddress OBJECT-TYPE
SYNTAX DisplayString
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Calling Party Number information element, as for example
passed in an ISDN SETUP message by a PBX or switch,
for incoming calls.
This address can be used to identify the peer.
If this address is either unknown or identical
to dialCtlPeerCfgOriginateAddress, this object will be
a zero length string."
DEFVAL { "" }
::= { dialCtlPeerCfgEntry 5 }
dialCtlPeerCfgSubAddress OBJECT-TYPE
SYNTAX DisplayString
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Subaddress at which the peer will be called.
If the subaddress is undefined for the given media or
unused, this is a zero length string."
DEFVAL { "" }
::= { dialCtlPeerCfgEntry 6 }
dialCtlPeerCfgClosedUserGroup OBJECT-TYPE
SYNTAX DisplayString
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Closed User Group at which the peer will be called.
If the Closed User Group is undefined for the given media
or unused, this is a zero length string."
REFERENCE
"Q.931, chapter 4.6.1."
DEFVAL { "" }
::= { dialCtlPeerCfgEntry 7 }
dialCtlPeerCfgSpeed OBJECT-TYPE
SYNTAX INTEGER (0..2147483647)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The desired information transfer speed in bits/second
when calling this peer.
The detailed media specific information, e.g. information
type and information transfer rate for ISDN circuits,
has to be extracted from this object.
If the transfer speed to be used is unknown or the default
speed for this type of interfaces, the value of this object
may be zero."
DEFVAL { 0 }
::= { dialCtlPeerCfgEntry 8 }
dialCtlPeerCfgInfoType OBJECT-TYPE
SYNTAX INTEGER {
other(1),
speech(2),
unrestrictedDigital(3), -- 64k/s data
unrestrictedDigital56(4), -- with 56k rate adaption
restrictedDigital(5),
audio31(6), -- 3.1 kHz audio
audio7(7), -- 7 kHz audio
video(8),
packetSwitched(9),
fax(10)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The Information Transfer Capability to be used when
calling this peer.
speech(2) refers to a non-data connection, whereas
audio31(6) and audio7(7) refer to data mode
connections."
DEFVAL { other }
::= { dialCtlPeerCfgEntry 9 }
dialCtlPeerCfgPermission OBJECT-TYPE
SYNTAX INTEGER {
originate(1),
answer(2),
both(3), -- both originate & answer
callback(4),
none(5)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Applicable permissions. callback(4) either rejects the
call and then calls back, or uses the 'Reverse charging'
information element if it is available.
Note that callback(4) is supposed to control charging, not
security, and applies to callback prior to accepting a
call. Callback for security reasons can be handled using
PPP callback."
DEFVAL { both }
::= { dialCtlPeerCfgEntry 10 }Okay bestie, so the inactivity timer is next and it's giving "use it or lose it" 💅 If the connection stops carrying useful stuff for as many seconds as this object says, it gets auto-disconnected. "Useful" here means forwarded packets (routing info counts too!), and encapsulator maintenance frames don't count 🙈 Setting it to zero means it never gets auto-hung-up, which basically makes it a dedicated circuit 🦋
dialCtlPeerCfgInactivityTimer OBJECT-TYPE
SYNTAX INTEGER (0..2147483647)
UNITS "seconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The connection will be automatically disconnected
if no longer carrying useful data for a time
period, in seconds, specified in this object.
Useful data in this context refers to forwarding
packets, including routing information; it
excludes the encapsulator maintenance frames.
A value of zero means the connection will not be
automatically taken down due to inactivity,
which implies that it is a dedicated circuit."
DEFVAL { 0 }
::= { dialCtlPeerCfgEntry 11 }Next up is the minimum call duration 🎀 This one is all about money, bestie. Lots of countries charge by the unit of time, so this object lets you line up the call length with those billing units as closely as you can 💖 It's measured in seconds, from the moment the call connects until it disconnects.
dialCtlPeerCfgMinDuration OBJECT-TYPE
SYNTAX INTEGER (0..2147483647)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Minimum duration of a call in seconds, starting from the
time the call is connected until the call is disconnected.
This is to accomplish the fact that in most countries
charging applies to units of time, which should be matched
as closely as possible."
DEFVAL { 0 }
::= { dialCtlPeerCfgEntry 12 }Now the maximum call duration, which is the ceiling on how long one call can last. Zero is the "no limit" vibe ✨
dialCtlPeerCfgMaxDuration OBJECT-TYPE
SYNTAX INTEGER (0..2147483647)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Maximum call duration in seconds. Zero means 'unlimited'."
DEFVAL { 0 }
::= { dialCtlPeerCfgEntry 13 }The carrier delay is the call timeout, in seconds. If you leave it at zero, the timeout that's defined for the specific media kicks in instead 🌸
dialCtlPeerCfgCarrierDelay OBJECT-TYPE
SYNTAX INTEGER (0..2147483647)
UNITS "seconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The call timeout time in seconds. The default value
of zero means that the call timeout as specified for
the media in question will apply."
DEFVAL { 0 }
::= { dialCtlPeerCfgEntry 14 }Call retries are about how many times you can keep ringing a peer that isn't picking up 📞 Zero means no cap. The whole point is to stop you from endlessly calling an address that's unreachable or keeps saying no. And ngl, some countries actually regulate how many retries are allowed, so this one matters irl 😭
dialCtlPeerCfgCallRetries OBJECT-TYPE
SYNTAX INTEGER (0..2147483647)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The number of calls to a non-responding address
that may be made. A retry count of zero means
there is no bound. The intent is to bound
the number of successive calls to an address
which is inaccessible, or which refuses those calls.
Some countries regulate the number of call retries
to a given peer that can be made."
DEFVAL { 0 }
::= { dialCtlPeerCfgEntry 15 }The retry delay is the wait between retries when a peer can't be reached. Zero means you can retry right away, no pause, no chill 🏃♀️
dialCtlPeerCfgRetryDelay OBJECT-TYPE
SYNTAX INTEGER (0..2147483647)
UNITS "seconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The time in seconds between call retries if a peer
cannot be reached.
A value of zero means that call retries may be done
without any delay."
DEFVAL { 0 }
::= { dialCtlPeerCfgEntry 16 }The failure delay kicks in after a peer has been spotted as unreachable, which means after the retry count runs out 🥺 It's the wait before you're allowed to try calling again. Zero means that peer is basically blocked from future calls after those retries are used up. Harsh, but that's the rule 💀
dialCtlPeerCfgFailureDelay OBJECT-TYPE
SYNTAX INTEGER (0..2147483647)
UNITS "seconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The time in seconds after which call attempts are
to be placed again after a peer has been noticed
to be unreachable, i.e. after dialCtlPeerCfgCallRetries
unsuccessful call attempts.
A value of zero means that a peer will not be called
again after dialCtlPeerCfgCallRetries unsuccessful call
attempts."
DEFVAL { 0 }
::= { dialCtlPeerCfgEntry 17 }The trap enable object is a simple on/off switch 🔔 It decides whether the call information and call setup traps get sent out for this peer. It defaults to disabled, so you have to opt in.
dialCtlPeerCfgTrapEnable OBJECT-TYPE
SYNTAX INTEGER {
enabled(1),
disabled(2)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object indicates whether dialCtlPeerCallInformation
and dialCtlPeerCallSetup traps should be generated for
this peer."
DEFVAL { disabled }
::= { dialCtlPeerCfgEntry 18 }And the status object is the row-status control for each row in this table, so it's how you create or delete an entry 🦋
dialCtlPeerCfgStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Status of one row in this table."
::= { dialCtlPeerCfgEntry 19 }
-- Peer statistics tableNow we get to the peer statistics table 📊 This one has one entry for every entry in the peer config table, so they always line up, iykyk 🫶 Each stats entry is augmenting the config entry, and it's basically permanent. It keeps info about the last call attempt plus a bunch of running stats.
dialCtlPeerStatsTable OBJECT-TYPE
SYNTAX SEQUENCE OF DialCtlPeerStatsEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Statistics information for each peer entry.
There will be one entry in this table for each entry
in the dialCtlPeerCfgTable."
::= { dialCtlPeer 2 }
dialCtlPeerStatsEntry OBJECT-TYPE
SYNTAX DialCtlPeerStatsEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Statistics information for a single Peer. This entry
is effectively permanent, and contains information
describing the last call attempt as well as supplying
statistical information."
AUGMENTS { dialCtlPeerCfgEntry }
::= { dialCtlPeerStatsTable 1 }
DialCtlPeerStatsEntry ::=
SEQUENCE {
dialCtlPeerStatsConnectTime AbsoluteCounter32,
dialCtlPeerStatsChargedUnits AbsoluteCounter32,
dialCtlPeerStatsSuccessCalls AbsoluteCounter32,
dialCtlPeerStatsFailCalls AbsoluteCounter32,
dialCtlPeerStatsAcceptCalls AbsoluteCounter32,
dialCtlPeerStatsRefuseCalls AbsoluteCounter32,
dialCtlPeerStatsLastDisconnectCause OCTET STRING,
dialCtlPeerStatsLastDisconnectText DisplayString,
dialCtlPeerStatsLastSetupTime TimeStamp
}Connect time is the running total of how long you've been connected to this peer since the system started. It counts outgoing calls plus incoming calls, so it's the full tea ☕
dialCtlPeerStatsConnectTime OBJECT-TYPE
SYNTAX AbsoluteCounter32
UNITS "seconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Accumulated connect time to the peer since system startup.
This is the total connect time, i.e. the connect time
for outgoing calls plus the time for incoming calls."
::= { dialCtlPeerStatsEntry 1 }Charged units count the billing units that apply to this peer since startup. The catch is that only the units on your local interface count, meaning originated calls, or calls with reverse charging active 💸
dialCtlPeerStatsChargedUnits OBJECT-TYPE
SYNTAX AbsoluteCounter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of charging units applying to this
peer since system startup.
Only the charging units applying to the local interface,
i.e. for originated calls or for calls with 'Reverse
charging' being active, will be counted here."
::= { dialCtlPeerStatsEntry 2 }Success calls is the number of completed calls to this peer ✅
dialCtlPeerStatsSuccessCalls OBJECT-TYPE
SYNTAX AbsoluteCounter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Number of completed calls to this peer."
::= { dialCtlPeerStatsEntry 3 }Fail calls counts the failed call attempts to this peer since startup 😤
dialCtlPeerStatsFailCalls OBJECT-TYPE
SYNTAX AbsoluteCounter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Number of failed call attempts to this peer since system
startup."
::= { dialCtlPeerStatsEntry 4 }Accept calls tracks calls coming in from this peer that got accepted, and refuse calls tracks the ones that got turned away 📥📤
dialCtlPeerStatsAcceptCalls OBJECT-TYPE
SYNTAX AbsoluteCounter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Number of calls from this peer accepted since system
startup."
::= { dialCtlPeerStatsEntry 5 }
dialCtlPeerStatsRefuseCalls OBJECT-TYPE
SYNTAX AbsoluteCounter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Number of calls from this peer refused since system
startup."
::= { dialCtlPeerStatsEntry 6 }The last disconnect cause is the encoded network cause value for the most recent call. It gets updated whenever a call starts or clears, and what the value looks like depends on the interface type, the protocol, and the protocol version. The references listed below have the possible values, so go check them out if you're a nerd like me 🤓
dialCtlPeerStatsLastDisconnectCause OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (0..4))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The encoded network cause value associated with the last
call.
This object will be updated whenever a call is started
or cleared.
The value of this object will depend on the interface type
as well as on the protocol and protocol version being
used on this interface. Some references for possible cause
values are given below."
REFERENCE
"- Bellcore SR-NWT-001953, Generic Guidelines for
ISDN Terminal Equipment On Basic Access Interfaces,
chapter 5.2.5.8.
- Bellcore SR-NWT-002343, ISDN Primary Rate Interface
Generic Guidelines for Customer Premises Equipment,
chapter 8.2.5.8.
- ITU-T Q.931, Appendix I.
- ITU-T X.25, CAUSE and DIAGNOSTIC field values.
- German Telekom FTZ 1TR6, chapter 3.2.3.4.4.4."
::= { dialCtlPeerStatsEntry 7 }The last disconnect text is the human-readable version of that reason, in ASCII 📝 It exists because a management station can't possibly store every cause value for every kind of interface. So it's your backup plan, only to be used if the station can't decode the cause value. It also gets updated whenever a call starts or clears.
dialCtlPeerStatsLastDisconnectText OBJECT-TYPE
SYNTAX DisplayString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"ASCII text describing the reason for the last call
termination.
This object exists because it would be impossible for
a management station to store all possible cause values
for all types of interfaces. It should be used only if
a management station is unable to decode the value of
dialCtlPeerStatsLastDisconnectCause.
This object will be updated whenever a call is started
or cleared."
::= { dialCtlPeerStatsEntry 8 }Last setup time is the sysUpTime snapshot of when the most recent call to this peer started. For ISDN, it's the moment the setup message was sent to or received from the network ⏰ Same as the others, it updates whenever a call starts or clears.
dialCtlPeerStatsLastSetupTime OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime when the last call to this peer
was started.
For ISDN media, this will be the time when the setup
message was received from or sent to the network.
This object will be updated whenever a call is started
or cleared."
::= { dialCtlPeerStatsEntry 9 }
--
-- the active call group
--
callActive OBJECT IDENTIFIER ::= { dialControlMibObjects 3 }
-- callActiveTable
-- Table to store active call information.
-- These calls could be circuit switched or they could
-- be virtual circuits.
-- An entry will be created when a call is started and deleted
-- when a call is cleared.Last up for this part is the active call group 📞✨ The active call table holds info about calls in progress, whether they're circuit switched or virtual circuits. A new entry shows up when a call starts and gets deleted when it clears, so it's always a live snapshot.
callActiveTable OBJECT-TYPE
SYNTAX SEQUENCE OF CallActiveEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A table containing information about active
calls to a specific destination."
::= { callActive 1 }
callActiveEntry OBJECT-TYPE
SYNTAX CallActiveEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The information regarding a single active Connection.
An entry in this table will be created when a call is
started. An entry in this table will be deleted when
an active call clears."
INDEX { callActiveSetupTime, callActiveIndex }
::= { callActiveTable 1 }okay bestie, picking up right where we left off 🎀 the callActive entry is giving main character energy, so let's keep going ✨
CallActiveEntry ::=
SEQUENCE {
callActiveSetupTime TimeStamp,
callActiveIndex INTEGER,
callActivePeerAddress DisplayString,
callActivePeerSubAddress DisplayString,
callActivePeerId INTEGER,
callActivePeerIfIndex INTEGER,
callActiveLogicalIfIndex InterfaceIndexOrZero,
callActiveConnectTime TimeStamp,
callActiveCallState INTEGER,
callActiveCallOrigin INTEGER,
callActiveChargedUnits AbsoluteCounter32,
callActiveInfoType INTEGER,
callActiveTransmitPackets AbsoluteCounter32,
callActiveTransmitBytes AbsoluteCounter32,
callActiveReceivePackets AbsoluteCounter32,
callActiveReceiveBytes AbsoluteCounter32
}
callActiveSetupTime OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The value of sysUpTime when the call associated to this
entry was started. This will be useful for an NMS to
retrieve all calls after a specific time. Also, this object
can be useful in finding large delays between the time the
call was started and the time the call was connected.
For ISDN media, this will be the time when the setup
message was received from or sent to the network."
::= { callActiveEntry 1 }
callActiveIndex OBJECT-TYPE
SYNTAX INTEGER (1..'7fffffff'h)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Small index variable to distinguish calls that start in
the same hundredth of a second."
::= { callActiveEntry 2 }
callActivePeerAddress OBJECT-TYPE
SYNTAX DisplayString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number this call is connected to. If the number is
not available, then it will have a length of zero."
::= { callActiveEntry 3 }
callActivePeerSubAddress OBJECT-TYPE
SYNTAX DisplayString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The subaddress this call is connected to. If the subaddress
is undefined or not available, this will be a zero length
string."
::= { callActiveEntry 4 }
callActivePeerId OBJECT-TYPE
SYNTAX INTEGER (0..2147483647)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is the Id value of the peer table entry
to which this call was made. If a peer table entry
for this call does not exist or is unknown, the value
of this object will be zero."
::= { callActiveEntry 5 }
callActivePeerIfIndex OBJECT-TYPE
SYNTAX INTEGER (0..2147483647)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is the ifIndex value of the peer table entry
to which this call was made. If a peer table entry
for this call does not exist or is unknown, the value
of this object will be zero."
::= { callActiveEntry 6 }
callActiveLogicalIfIndex OBJECT-TYPE
SYNTAX InterfaceIndexOrZero
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is the ifIndex value of the logical interface through
which this call was made. For ISDN media, this would be
the ifIndex of the B channel which was used for this call.
If the ifIndex value is unknown, the value of this object
will be zero."
::= { callActiveEntry 7 }
callActiveConnectTime OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime when the call was connected.
If the call is not connected, this object will have a
value of zero."
::= { callActiveEntry 8 }
callActiveCallState OBJECT-TYPE
SYNTAX INTEGER {
unknown(1),
connecting(2),
connected(3),
active(4)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The current call state.
unknown(1) - The call state is unknown.
connecting(2) - A connection attempt (outgoing call)
is being made.
connected(3) - An incoming call is in the process
of validation.
active(4) - The call is active.
"
::= { callActiveEntry 9 }
callActiveCallOrigin OBJECT-TYPE
SYNTAX INTEGER {
originate(1),
answer(2),
callback(3)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The call origin."
::= { callActiveEntry 10 }
callActiveChargedUnits OBJECT-TYPE
SYNTAX AbsoluteCounter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of charged units for this connection.
For incoming calls or if charging information is
not supplied by the switch, the value of this object
will be zero."
::= { callActiveEntry 11 }
callActiveInfoType OBJECT-TYPE
SYNTAX INTEGER {
other(1), -- e.g. for non-isdn media
speech(2),
unrestrictedDigital(3), -- 64k/s data
unrestrictedDigital56(4), -- with 56k rate adaption
restrictedDigital(5),
audio31(6), -- 3.1 kHz audio
audio7(7), -- 7 kHz audio
video(8),
packetSwitched(9),
fax(10)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The information type for this call."
::= { callActiveEntry 12 }
callActiveTransmitPackets OBJECT-TYPE
SYNTAX AbsoluteCounter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of packets which were transmitted for this
call."
::= { callActiveEntry 13 }
callActiveTransmitBytes OBJECT-TYPE
SYNTAX AbsoluteCounter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of bytes which were transmitted for this
call."
::= { callActiveEntry 14 }
callActiveReceivePackets OBJECT-TYPE
SYNTAX AbsoluteCounter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of packets which were received for this
call."
::= { callActiveEntry 15 }
callActiveReceiveBytes OBJECT-TYPE
SYNTAX AbsoluteCounter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of bytes which were received for this call."
::= { callActiveEntry 16 }and now we're entering the call history group, which is the "past calls" era of this whole MIB 🕰️🧚
--
-- the call history group
--
callHistory OBJECT IDENTIFIER ::= { dialControlMibObjects 4 }
callHistoryTableMaxLength OBJECT-TYPE
SYNTAX INTEGER (0..2147483647)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The upper limit on the number of entries that the
callHistoryTable may contain. A value of 0
will prevent any history from being retained. When
this table is full, the oldest entry will be deleted
and the new one will be created."
::= { callHistory 1 }
callHistoryRetainTimer OBJECT-TYPE
SYNTAX INTEGER (0..2147483647)
UNITS "minutes"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The minimum amount of time that an callHistoryEntry
will be maintained before being deleted. A value of
0 will prevent any history from being retained in the
callHistoryTable, but will neither prevent callCompletion
traps being generated nor affect other tables."
::= { callHistory 2 }
-- callHistoryTable
-- Table to store the past call information. The Destination number
-- and the call connect and disconnect time, the disconnection cause
-- are stored. These calls could be circuit switched or they could
-- be virtual circuits. History of each and every call is stored,
-- of successful calls as well as of unsuccessful and rejected calls.
-- An entry will be created when a call is cleared.
callHistoryTable OBJECT-TYPE
SYNTAX SEQUENCE OF CallHistoryEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A table containing information about specific
calls to a specific destination."
::= { callHistory 3 }
callHistoryEntry OBJECT-TYPE
SYNTAX CallHistoryEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The information regarding a single Connection."
INDEX { callActiveSetupTime, callActiveIndex }
::= { callHistoryTable 1 }
CallHistoryEntry ::=
SEQUENCE {
callHistoryPeerAddress DisplayString,
callHistoryPeerSubAddress DisplayString,
callHistoryPeerId INTEGER,
callHistoryPeerIfIndex INTEGER,
callHistoryLogicalIfIndex InterfaceIndex,
callHistoryDisconnectCause OCTET STRING,
callHistoryDisconnectText DisplayString,
callHistoryConnectTime TimeStamp,
callHistoryDisconnectTime TimeStamp,
callHistoryCallOrigin INTEGER,
callHistoryChargedUnits AbsoluteCounter32,
callHistoryInfoType INTEGER,
callHistoryTransmitPackets AbsoluteCounter32,
callHistoryTransmitBytes AbsoluteCounter32,
callHistoryReceivePackets AbsoluteCounter32,
callHistoryReceiveBytes AbsoluteCounter32
}
callHistoryPeerAddress OBJECT-TYPE
SYNTAX DisplayString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number this call was connected to. If the number is
not available, then it will have a length of zero."
::= { callHistoryEntry 1 }
callHistoryPeerSubAddress OBJECT-TYPE
SYNTAX DisplayString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The subaddress this call was connected to. If the subaddress
is undefined or not available, this will be a zero length
string."
::= { callHistoryEntry 2 }
callHistoryPeerId OBJECT-TYPE
SYNTAX INTEGER (0..2147483647)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is the Id value of the peer table entry
to which this call was made. If a peer table entry
for this call does not exist, the value of this object
will be zero."
::= { callHistoryEntry 3 }okay so the call history table keeps going, and this is where it gets juicy 💅 each entry has all these fields for the peer, the logical interface, the disconnect cause, the times, the origin, the charged units, the info type, and the traffic counters 📞🦋
callHistoryPeerIfIndex OBJECT-TYPE
SYNTAX INTEGER (0..2147483647)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is the ifIndex value of the peer table entry
to which this call was made. If a peer table entry
for this call does not exist, the value of this object
will be zero."
::= { callHistoryEntry 4 }
callHistoryLogicalIfIndex OBJECT-TYPE
SYNTAX InterfaceIndex
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This is the ifIndex value of the logical interface through
which this call was made. For ISDN media, this would be
the ifIndex of the B channel which was used for this call."
::= { callHistoryEntry 5 }
callHistoryDisconnectCause OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (0..4))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The encoded network cause value associated with this call.
The value of this object will depend on the interface type
as well as on the protocol and protocol version being
used on this interface. Some references for possible cause
values are given below."
REFERENCE
"- Bellcore SR-NWT-001953, Generic Guidelines for
ISDN Terminal Equipment On Basic Access Interfaces,
chapter 5.2.5.8.
- Bellcore SR-NWT-002343, ISDN Primary Rate Interface
Generic Guidelines for Customer Premises Equipment,
chapter 8.2.5.8.
- ITU-T Q.931, Appendix I.
- ITU-T X.25, CAUSE and DIAGNOSTIC field values.
- German Telekom FTZ 1TR6, chapter 3.2.3.4.4.4."
::= { callHistoryEntry 6 }
callHistoryDisconnectText OBJECT-TYPE
SYNTAX DisplayString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"ASCII text describing the reason for call termination.
This object exists because it would be impossible for
a management station to store all possible cause values
for all types of interfaces. It should be used only if
a management station is unable to decode the value of
dialCtlPeerStatsLastDisconnectCause."
::= { callHistoryEntry 7 }
callHistoryConnectTime OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime when the call was connected."
::= { callHistoryEntry 8 }
callHistoryDisconnectTime OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime when the call was disconnected."
::= { callHistoryEntry 9 }
callHistoryCallOrigin OBJECT-TYPE
SYNTAX INTEGER {
originate(1),
answer(2),
callback(3)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The call origin."
::= { callHistoryEntry 10 }
callHistoryChargedUnits OBJECT-TYPE
SYNTAX AbsoluteCounter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of charged units for this connection.
For incoming calls or if charging information is
not supplied by the switch, the value of this object
will be zero."
::= { callHistoryEntry 11 }
callHistoryInfoType OBJECT-TYPE
SYNTAX INTEGER {
other(1), -- e.g. for non-isdn media
speech(2),
unrestrictedDigital(3), -- 64k/s data
unrestrictedDigital56(4), -- with 56k rate adaption
restrictedDigital(5),
audio31(6), -- 3.1 kHz audio
audio7(7), -- 7 kHz audio
video(8),
packetSwitched(9),
fax(10)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The information type for this call."
::= { callHistoryEntry 12 }
callHistoryTransmitPackets OBJECT-TYPE
SYNTAX AbsoluteCounter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of packets which were transmitted while this
call was active."
::= { callHistoryEntry 13 }
callHistoryTransmitBytes OBJECT-TYPE
SYNTAX AbsoluteCounter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of bytes which were transmitted while this
call was active."
::= { callHistoryEntry 14 }
callHistoryReceivePackets OBJECT-TYPE
SYNTAX AbsoluteCounter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of packets which were received while this
call was active."
::= { callHistoryEntry 15 }
callHistoryReceiveBytes OBJECT-TYPE
SYNTAX AbsoluteCounter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of bytes which were received while this
call was active."
::= { callHistoryEntry 16 }now for the traps 🔔 these are the notifications that tell the manager what's going on with connections 🌸
-- Traps related to Connection management
dialControlMibTrapPrefix OBJECT IDENTIFIER ::= { dialControlMib 2 }
dialControlMibTraps OBJECT IDENTIFIER ::= { dialControlMibTrapPrefix 0 }
dialCtlPeerCallInformation NOTIFICATION-TYPE
OBJECTS {
callHistoryPeerId,
callHistoryPeerIfIndex,
callHistoryLogicalIfIndex,
ifOperStatus,
callHistoryPeerAddress,
callHistoryPeerSubAddress,
callHistoryDisconnectCause,
callHistoryConnectTime,
callHistoryDisconnectTime,
callHistoryInfoType,
callHistoryCallOrigin
}
STATUS current
DESCRIPTION
"This trap/inform is sent to the manager whenever
a successful call clears, or a failed call attempt
is determined to have ultimately failed. In the
event that call retry is active, then this is after
all retry attempts have failed. However, only one such
trap is sent in between successful call attempts;
subsequent call attempts result in no trap.
ifOperStatus will return the operational status of the
virtual interface associated with the peer to whom
this call was made to."
::= { dialControlMibTraps 1 }
dialCtlPeerCallSetup NOTIFICATION-TYPE
OBJECTS {
callActivePeerId,
callActivePeerIfIndex,
callActiveLogicalIfIndex,
ifOperStatus,
callActivePeerAddress,
callActivePeerSubAddress,
callActiveInfoType,
callActiveCallOrigin
}
STATUS current
DESCRIPTION
"This trap/inform is sent to the manager whenever
a call setup message is received or sent.
ifOperStatus will return the operational status of the
virtual interface associated with the peer to whom
this call was made to."
::= { dialControlMibTraps 2 }last bit for this part: the conformance stuff, which is basically how implementations say "yep, I've got these groups" 🎀✨
-- conformance information
dialControlMibConformance OBJECT IDENTIFIER ::=
{ dialControlMib 3 }
dialControlMibCompliances OBJECT IDENTIFIER ::=
{ dialControlMibConformance 1 }
dialControlMibGroups OBJECT IDENTIFIER ::=
{ dialControlMibConformance 2 }
-- compliance statements
dialControlMibCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for entities which
implement the DIAL CONTROL MIB"
MODULE -- this module
MANDATORY-GROUPS
{ dialControlGroup, callActiveGroup, callHistoryGroup,
callNotificationsGroup }
::= { dialControlMibCompliances 1 }
-- units of conformance
dialControlGroup OBJECT-GROUP
OBJECTS {
dialCtlAcceptMode,
dialCtlTrapEnable,
dialCtlPeerCfgIfType,
dialCtlPeerCfgLowerIf,
dialCtlPeerCfgOriginateAddress,
dialCtlPeerCfgAnswerAddress,
dialCtlPeerCfgSubAddress,
dialCtlPeerCfgClosedUserGroup,
dialCtlPeerCfgSpeed,
dialCtlPeerCfgInfoType,
dialCtlPeerCfgPermission,
dialCtlPeerCfgInactivityTimer,
dialCtlPeerCfgMinDuration,
dialCtlPeerCfgMaxDuration,
dialCtlPeerCfgCarrierDelay,
dialCtlPeerCfgCallRetries,
dialCtlPeerCfgRetryDelay,
dialCtlPeerCfgFailureDelay,
dialCtlPeerCfgTrapEnable,
dialCtlPeerCfgStatus,
dialCtlPeerStatsConnectTime,
dialCtlPeerStatsChargedUnits,
dialCtlPeerStatsSuccessCalls,
dialCtlPeerStatsFailCalls,
dialCtlPeerStatsAcceptCalls,
dialCtlPeerStatsRefuseCalls,
dialCtlPeerStatsLastDisconnectCause,
dialCtlPeerStatsLastDisconnectText,
dialCtlPeerStatsLastSetupTime
}
STATUS current
DESCRIPTION
"A collection of objects providing the DIAL CONTROL
capability."
::= { dialControlMibGroups 1 }
callActiveGroup OBJECT-GROUP
OBJECTS {
callActivePeerAddress,
callActivePeerSubAddress,
callActivePeerId,
callActivePeerIfIndex,
callActiveLogicalIfIndex,
callActiveConnectTime,
callActiveCallState,
callActiveCallOrigin,
callActiveChargedUnits,
callActiveInfoType,
callActiveTransmitPackets,
callActiveTransmitBytes,
callActiveReceivePackets,
callActiveReceiveBytes
}
STATUS current
DESCRIPTION
"A collection of objects providing the active call
capability."
::= { dialControlMibGroups 2 }
callHistoryGroup OBJECT-GROUP
OBJECTS {
callHistoryTableMaxLength,
callHistoryRetainTimer,
callHistoryPeerAddress,
callHistoryPeerSubAddress,
callHistoryPeerId,
callHistoryPeerIfIndex,
callHistoryLogicalIfIndex,
callHistoryDisconnectCause,
callHistoryDisconnectText,
callHistoryConnectTime,
callHistoryDisconnectTime,
callHistoryCallOrigin,
callHistoryChargedUnits,
callHistoryInfoType,
callHistoryTransmitPackets,
callHistoryTransmitBytes,
callHistoryReceivePackets,
callHistoryReceiveBytes
}
STATUS current
DESCRIPTION
"A collection of objects providing the Call History
capability."
::= { dialControlMibGroups 3 }
callNotificationsGroup NOTIFICATION-GROUP
NOTIFICATIONS { dialCtlPeerCallInformation, dialCtlPeerCallSetup }
STATUS current
DESCRIPTION
"The notifications which a Dial Control MIB entity is
required to implement."
::= { dialControlMibGroups 4 }
END4. Acknowledgments ✨
This doc was made by the ISDN MIB Working Group, and they gave a huge shoutout to these legends 🫶💖
Ed Alcoff
Fred Baker
Bibek A. Das
Ken Grigg
Jeffrey T. Johnson
Glenn Kime
Oliver Korfmacher
Kedar Madineni
Bill Miskovetz
David M. Piscitello
Lisa A. Phifer
Randy Roberts
Hascall H. Sharp
Hongchi Shih
Robert Snyder
Bob Stewart
Ron Stoughton
James Watt5. References 📚
Okay, here's the reading list the doc is built on. Every single one of these is cited, so bookmark them 🔖💅
[1] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1902, January 1996.
[2] McCloghrie, K., and M. Rose, Editors, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, Hughes LAN Systems, Performance Systems International, March 1991.
[3] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "A Simple Network Management Protocol (SNMP)", STD 15, RFC 1157, SNMP Research, Performance Systems International, MIT Lab for Computer Science, May 1990.
[4] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996.
[5] ITU-T Recommendation "Digital subscriber Signalling System No. 1 (DSS 1) - ISDN user-network interface layer 3 specification for basic call control", Rec. Q.931(I.451), March 1993.
[6] ITU-T Recommendation "Generic procedures for the control of ISDN supplementary services ISDN user-network interface layer 3 specification", Rec. Q.932(I.452).
[7] ITU-T Recommendation "Digital subscriber Signalling System No. 1 (DSS 1) - Signalling specification for frame-mode basic call control", Rec. Q.933.
[8] McCloghrie, K. and F. Kastenholz, "Evolution of the Interfaces Group of MIB-II", RFC 1573, Hughes LAN Systems, FTP Software, January 1994.
6. Security Considerations 🔐⚠️
Okay, this part is serious, bestie, so listen up 🙈 The info in this MIB can be used by upper protocol layers for security purposes, so it matters a lot.
🚨 Supporting generic peers, the thing described in section 3.4, can open up a security hole. The user wouldn't know where a call is coming from, and that could let unauthorized people in if there's no other authentication scheme, like PPP authentication, in place. Don't skip the auth step, periodt 💀
7. Author's Address 💌
The author is Guenter Roeck, who's at cisco Systems, and here's where you can find them 🧚
Guenter Roeck
cisco Systems
170 West Tasman Drive
San Jose, CA 95134
U.S.A.
Phone: +1 408 527 3143
EMail: groeck@cisco.com📦 where this page comes from
- ietf: rfc2128 1997-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms