summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2128.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2128.txt')
-rw-r--r--doc/rfc/rfc2128.txt1907
1 files changed, 1907 insertions, 0 deletions
diff --git a/doc/rfc/rfc2128.txt b/doc/rfc/rfc2128.txt
new file mode 100644
index 0000000..f1a733e
--- /dev/null
+++ b/doc/rfc/rfc2128.txt
@@ -0,0 +1,1907 @@
+
+
+
+
+
+
+Network Working Group G. Roeck, Editor
+Request for Comments: 2128 cisco Systems
+Category: Standards Track March 1997
+
+
+ Dial Control Management Information Base using SMIv2
+
+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.
+ In particular, 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.
+
+ 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.
+
+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
+
+
+
+Roeck Standards Track [Page 1]
+
+RFC 2128 Dial Control MIB March 1997
+
+
+ 6 Security Considerations ...................................... 33
+ 7 Author's Address ............................................. 34
+
+1. The SNMPv2 Network Management Framework
+
+ The SNMPv2 Network Management Framework presently consists of three
+ major components. They are:
+
+ o the SMI, described in RFC 1902 [1] - the mechanisms used for
+ describing and naming objects for the purpose of management.
+
+ o the MIB-II, STD 17, RFC 1213 [2] - the core set of managed
+ objects for the Internet suite of protocols.
+
+ o the protocol, STD 15, RFC 1157 [3] and/or RFC 1905 [4], -
+ the protocol for accessing managed objects.
+
+ The Framework permits new objects to be defined for the purpose of
+ experimentation and evaluation.
+
+1.1. Object Definitions
+
+ Managed objects are accessed via a virtual information store, termed
+ 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. In particular, each object type is named by an
+ OBJECT IDENTIFIER, an administratively assigned name. The object
+ type together with an object instance serves to uniquely identify a
+ specific instantiation of the object. For human convenience, we
+ often use a textual string, termed the descriptor, to refer to the
+ object type.
+
+2. Overview
+
+2.1. Structure of MIB
+
+ Managing demand access circuits requires the following groups of
+ information:
+
+ o General configuration information.
+
+ o 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.
+
+ o Information to store active call information.
+
+
+
+Roeck Standards Track [Page 2]
+
+RFC 2128 Dial Control MIB March 1997
+
+
+ o Information to retain call history.
+
+ The MIB, therefore, is structured into four groups.
+
+ o The dialCtlConfiguration group is used to specify general
+ configuration information.
+
+ o The dialCtlPeer group is used to describe peer configuration
+ and peer statistics.
+
+ o The callActive group is used to store active call information.
+
+ o The callHistory group 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.
+
+2.2. Relationship to the Interfaces MIB
+
+ This section clarifies the relationship of this MIB to the Interfaces
+ MIB [8]. Several areas of correlation are addressed in the following
+ subsections. The implementor is referred to the Interfaces MIB
+ document in order to understand the general intent of these areas.
+
+2.2.1. Layering Model and Virtual Circuits
+
+ On an occasional access channel, there are a number of peer systems
+ that are permitted to call or be called, all of which need to be
+ treated as active from a routing viewpoint, but most of which have no
+ call in progress at any given time.
+
+ On dialup interfaces, this is further complicated by the fact that
+ calls to a given peer float from channel to channel. One cannot
+ definitively say "I call this peer on that interface." It is
+ necessary, therefore, to provide a mapping algorithm between the
+ low-level interfaces, and the various logical interfaces supporting
+ 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 then
+ in turn are layered on top of physical ISDN interfaces.
+
+
+
+
+
+
+
+Roeck Standards Track [Page 3]
+
+RFC 2128 Dial Control MIB March 1997
+
+
+ The model, therefore, looks something like this, taking ISDN as an
+ 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 Channels
+
+ IfEntries are maintained for each peer.
+
+ In this model, each peer is required to have an associated
+ encapsulation layer interface. This interface can be of any kind,
+ e.g. PPP or LAPB.
+
+ In order to specify the network address for a given peer, one would
+ then usually add a routing/forwarding table entry, pointing to the
+ encapsulation layer interface through which this peer can be reached.
+
+2.2.2. ifTestTable
+
+ The ifTestTable usage is defined in the MIBs defining 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 defining the
+ encapsulation below the network layer. For example, if PPP
+ encapsulation is being used, the ifRcvAddressTable is defined by PPP.
+
+
+
+
+
+Roeck Standards Track [Page 4]
+
+RFC 2128 Dial Control MIB March 1997
+
+
+2.2.3.1. ifEntry for a single peer
+
+ IfEntries are defined in the MIBs defining 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 of some set of
+ ifTypes. That is, 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 does have its own RowStatus, permitting the
+ Dial Control supplementary information to come and go, but not
+ otherwise disturbing the ifIndex to which it is attached. 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
+
+ In order 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 will then describe a
+ possible connection to the same peer. Such entries can then 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 for example be supported 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 such a functionality is outside the scope
+ of this document.
+
+ However, 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.
+
+
+
+
+
+
+
+Roeck Standards Track [Page 5]
+
+RFC 2128 Dial Control MIB March 1997
+
+
+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 }
+
+AbsoluteCounter32 ::= TEXTUAL-CONVENTION
+
+
+
+Roeck Standards Track [Page 6]
+
+RFC 2128 Dial Control MIB March 1997
+
+
+ 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 Unsigned32
+
+-- 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)
+
+
+
+Roeck Standards Track [Page 7]
+
+RFC 2128 Dial Control MIB March 1997
+
+
+ }
+ 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 }
+
+
+-- 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 }
+
+
+
+Roeck Standards Track [Page 8]
+
+RFC 2128 Dial Control MIB March 1997
+
+
+ ::= { 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.
+
+
+
+Roeck Standards Track [Page 9]
+
+RFC 2128 Dial Control MIB March 1997
+
+
+ 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
+
+
+
+Roeck Standards Track [Page 10]
+
+RFC 2128 Dial Control MIB March 1997
+
+
+ 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),
+
+
+
+Roeck Standards Track [Page 11]
+
+RFC 2128 Dial Control MIB March 1997
+
+
+ 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 }
+
+dialCtlPeerCfgInactivityTimer OBJECT-TYPE
+ SYNTAX INTEGER (0..2147483647)
+ UNITS "seconds"
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+
+
+
+Roeck Standards Track [Page 12]
+
+RFC 2128 Dial Control MIB March 1997
+
+
+ "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 }
+
+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 }
+
+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 }
+
+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 }
+
+dialCtlPeerCfgCallRetries OBJECT-TYPE
+ SYNTAX INTEGER (0..2147483647)
+
+
+
+Roeck Standards Track [Page 13]
+
+RFC 2128 Dial Control MIB March 1997
+
+
+ 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 }
+
+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 }
+
+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 }
+
+dialCtlPeerCfgTrapEnable OBJECT-TYPE
+ SYNTAX INTEGER {
+ enabled(1),
+ disabled(2)
+ }
+
+
+
+Roeck Standards Track [Page 14]
+
+RFC 2128 Dial Control MIB March 1997
+
+
+ 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 }
+
+dialCtlPeerCfgStatus OBJECT-TYPE
+ SYNTAX RowStatus
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "Status of one row in this table."
+ ::= { dialCtlPeerCfgEntry 19 }
+
+-- Peer statistics table
+
+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,
+
+
+
+Roeck Standards Track [Page 15]
+
+RFC 2128 Dial Control MIB March 1997
+
+
+ dialCtlPeerStatsRefuseCalls AbsoluteCounter32,
+ dialCtlPeerStatsLastDisconnectCause OCTET STRING,
+ dialCtlPeerStatsLastDisconnectText DisplayString,
+ dialCtlPeerStatsLastSetupTime TimeStamp
+ }
+
+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 }
+
+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 }
+
+dialCtlPeerStatsSuccessCalls OBJECT-TYPE
+ SYNTAX AbsoluteCounter32
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "Number of completed calls to this peer."
+ ::= { dialCtlPeerStatsEntry 3 }
+
+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 }
+
+dialCtlPeerStatsAcceptCalls OBJECT-TYPE
+ SYNTAX AbsoluteCounter32
+
+
+
+Roeck Standards Track [Page 16]
+
+RFC 2128 Dial Control MIB March 1997
+
+
+ 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 }
+
+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 }
+
+dialCtlPeerStatsLastDisconnectText OBJECT-TYPE
+ SYNTAX DisplayString
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "ASCII text describing the reason for the last call
+ termination.
+
+
+
+Roeck Standards Track [Page 17]
+
+RFC 2128 Dial Control MIB March 1997
+
+
+ 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 }
+
+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.
+
+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
+
+
+
+Roeck Standards Track [Page 18]
+
+RFC 2128 Dial Control MIB March 1997
+
+
+ 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 }
+
+
+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
+
+
+
+Roeck Standards Track [Page 19]
+
+RFC 2128 Dial Control MIB March 1997
+
+
+ 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
+
+
+
+Roeck Standards Track [Page 20]
+
+RFC 2128 Dial Control MIB March 1997
+
+
+ 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
+
+
+
+Roeck Standards Track [Page 21]
+
+RFC 2128 Dial Control MIB March 1997
+
+
+ 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
+
+
+
+Roeck Standards Track [Page 22]
+
+RFC 2128 Dial Control MIB March 1997
+
+
+ "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 }
+
+--
+-- 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
+
+
+
+Roeck Standards Track [Page 23]
+
+RFC 2128 Dial Control MIB March 1997
+
+
+ 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,
+
+
+
+Roeck Standards Track [Page 24]
+
+RFC 2128 Dial Control MIB March 1997
+
+
+ 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 }
+
+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
+
+
+
+Roeck Standards Track [Page 25]
+
+RFC 2128 Dial Control MIB March 1997
+
+
+ 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
+
+
+
+Roeck Standards Track [Page 26]
+
+RFC 2128 Dial Control MIB March 1997
+
+
+ "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
+
+
+
+Roeck Standards Track [Page 27]
+
+RFC 2128 Dial Control MIB March 1997
+
+
+ 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 }
+
+-- Traps related to Connection management
+
+dialControlMibTrapPrefix OBJECT IDENTIFIER ::= { dialControlMib 2 }
+dialControlMibTraps OBJECT IDENTIFIER ::= { dialControlMibTrapPrefix 0 }
+
+dialCtlPeerCallInformation NOTIFICATION-TYPE
+ OBJECTS {
+
+
+
+Roeck Standards Track [Page 28]
+
+RFC 2128 Dial Control MIB March 1997
+
+
+ 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 }
+
+-- conformance information
+
+
+
+
+Roeck Standards Track [Page 29]
+
+RFC 2128 Dial Control MIB March 1997
+
+
+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,
+
+
+
+Roeck Standards Track [Page 30]
+
+RFC 2128 Dial Control MIB March 1997
+
+
+ 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,
+
+
+
+Roeck Standards Track [Page 31]
+
+RFC 2128 Dial Control MIB March 1997
+
+
+ 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 }
+
+
+END
+
+4. Acknowledgments
+
+ This document was produced by the ISDN MIB Working Group. Special
+ thanks is due to the following persons:
+
+ 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 Watt
+
+
+
+Roeck Standards Track [Page 32]
+
+RFC 2128 Dial Control MIB March 1997
+
+
+5. References
+
+[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
+
+ Information in this MIB may be used by upper protocol layers for
+ security purpose.
+
+ The implementor should be aware that supporting generic peers as
+ described in section 3.4 may cause a security hole. The user would
+ not know where a call is from, which could potentially allow
+ unauthorized access if there is no other authentication scheme, e.g.
+ PPP authentication, available.
+
+
+
+
+Roeck Standards Track [Page 33]
+
+RFC 2128 Dial Control MIB March 1997
+
+
+7. Author's Address
+
+ Guenter Roeck
+ cisco Systems
+ 170 West Tasman Drive
+ San Jose, CA 95134
+ U.S.A.
+
+ Phone: +1 408 527 3143
+ EMail: groeck@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Roeck Standards Track [Page 34]
+