rfc2127.txt
来自「RFC 的详细文档！」· 文本 代码 · 共 1,729 行 · 第 1/5 页
TXT
1,729 行
of favorable tariffs for Speech as opposed to Data.
On the incoming side, the equipment is usually configured to ignore
the Bearer Capability and either answer all Speech calls as 56 kbit/s
data or to use one Directory Number for real speech and another for
data.
3.4.9. Attaching incoming calls to router ports
In ISDN, there are several ways to identify an incoming call and to
attach a router port to this call.
o The call can be identified and attached to a router port using
the ISDN Calling Address, that is, the peer ISDN address. Since
the peer address is defined in a Dial Control MIB configuration
entry for this peer, this would be the most natural way to
attach an incoming call to a router port.
In this configuration, only a single isdnSignalingTable entry is
required for each physical ISDN interface. Unfortunately, the
ISDN Calling Address is not available in all countries and/or
switch protocols. Therefore, other means for attaching incoming
calls to router ports must be provided.
Roeck Standards Track [Page 19]
RFC 2127 ISDN MIB March 1997
o The call can also be identified and attached to a router port
using the ISDN Called Address. In this case, a distinct ISDN
address or subaddress must be specified for each of the router
ports. This can be accomplished in the ISDN MIB by creating a
isdnSignalingTable entry for each of the router ports, and by
connecting Dial Control MIB peer entries to the thereby created
interface using the dialCtlPeerCfgLowerIf object of
dialCtlPeerCfgTable.
If this type of router port identification is used in an
implementation, it is up to the implementor to decide if there
should be distinct TEI values assigned for each of the
isdnSignalingTable entries. For this reason, the
isdnEndpointTable permits specifying the same TEI value in
multiple entries. It is recommended to use dynamic TEI
assignment whenever possible.
The implementor should be aware that this type of configuration
requires a lot of configuration work for the customer, since an
entry in isdnSignalingTable must be created for each of the
router ports.
o Incoming calls can also be identified and attached to router
ports using a higher layer functionality, such as PPP
authentication. Defining this functionality is outside the
scope of this document.
3.4.10. Usage of isdnMibDirectoryGroup and isdnDirectoryTable
In some switch protocol or PBX implementations, the Called Number
Information Element on incoming calls can differ from the Calling
Number on outgoing calls. Sometimes, the Called Number can be
different for incoming Local Calls, Long Distance Calls and
International Calls. For Hunt Groups, the Called Number can be any
of the numbers in the Hunt Group.
The isdnDirectoryTable can be used to specify all these numbers.
Entries in the isdnDirectoryTable are always connected to specific
isdnSignalingTable entries. No ifEntry is created for
isdnDirectoryTable entries. Therefore, the isdnDirectoryTable can
not be used to attach incoming calls to router ports. For router
port identification, isdnSignalingTable entries should be created
instead.
Roeck Standards Track [Page 20]
RFC 2127 ISDN MIB March 1997
4. Definitions
ISDN-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY,
NOTIFICATION-TYPE,
OBJECT-TYPE,
Counter32,
Gauge32,
Integer32
FROM SNMPv2-SMI
DisplayString,
TruthValue,
TimeStamp,
RowStatus,
TestAndIncr,
TEXTUAL-CONVENTION
FROM SNMPv2-TC
MODULE-COMPLIANCE,
OBJECT-GROUP,
NOTIFICATION-GROUP
FROM SNMPv2-CONF
ifIndex,
InterfaceIndex
FROM IF-MIB
IANAifType
FROM IANAifType-MIB
transmission
FROM RFC1213-MIB;
isdnMib MODULE-IDENTITY
LAST-UPDATED "9609231642Z" -- Sep 23, 1996
ORGANIZATION "IETF ISDN MIB 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 the
management of ISDN interfaces."
::= { transmission 20 }
-- The ISDN hardware interface (BRI or PRI) is represented
Roeck Standards Track [Page 21]
RFC 2127 ISDN MIB March 1997
-- by a media specific ifEntry.
--
-- For basic rate lines, the media specifics for the physical interface
-- is defined in the physical interface group of the ISDN MIB.
-- The ifType for physical basic rate interfaces is isdns(75)
-- or isdnu(76), whichever is appropriate.
--
-- For primary rate, the media specifics are defined in the Trunk
-- MIB and the ifType has a value of ds1(18).
-- Each signaling channel is represented by an entry
-- in the isdnSignalingTable.
-- The signaling channel has an ifType value of isdn(63).
-- Each B channel is also represented as an entry
-- in the ifTable. The B channels have an ifType value
-- of ds0(81).
-- This model is used while defining objects and tables
-- for management.
-- The ISDN MIB allows sub-layers. For example, the data transfer
-- over a B channel may take place with PPP encapsulation. While the
-- ISDN MIB describes the D and B channels, a media specific MIB
-- for PPP can be used on a layered basis. This is as per
-- the interfaces MIB.
-- Textual conventions
IsdnSignalingProtocol ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"This data type is used as the syntax of the
isdnSignalingProtocol object in the
definition of ISDN-MIB's isdnSignalingTable.
The definition of this textual convention with the
addition of newly assigned values is published
periodically by the IANA, in either the Assigned
Numbers RFC, or some derivative of it specific to
Internet Network Management number assignments. (The
latest arrangements can be obtained by contacting the
IANA.)
Requests for new values should be made to IANA via
email (iana@iana.org)."
SYNTAX INTEGER {
other(1), -- none of the following
dss1(2), -- ITU DSS1 (formerly CCITT) Q.931
etsi(3), -- Europe / ETSI ETS300-102
-- plus supplementary services
Roeck Standards Track [Page 22]
RFC 2127 ISDN MIB March 1997
-- (ETSI 300-xxx)
-- note that NET3, NET5 define
-- test procedures for ETS300-102
-- and have been replaced by
-- I-CTR 3 and I-CTR 4.
dass2(4), -- U.K. / DASS2 (PRI)
ess4(5), -- U.S.A. / AT&T 4ESS
ess5(6), -- U.S.A. / AT&T 5ESS
dms100(7), -- U.S.A. / Northern Telecom DMS100
dms250(8), -- U.S.A. / Northern Telecom DMS250
ni1(9), -- U.S.A. / National ISDN 1 (BRI)
ni2(10), -- U.S.A. / National ISDN 2 (BRI, PRI)
ni3(11), -- U.S.A. / next one
vn2(12), -- France / VN2
vn3(13), -- France / VN3
vn4(14), -- France / VN4 (ETSI with changes)
vn6(15), -- France / VN6 (ETSI with changes)
-- delta document CSE P 10-21 A
-- test document CSE P 10-20 A
kdd(16), -- Japan / KDD
ins64(17), -- Japan / NTT INS64
ins1500(18), -- Japan / NTT INS1500
itr6(19), -- Germany/ 1TR6 (BRI, PRI)
cornet(20), -- Germany/ Siemens HiCom CORNET
ts013(21), -- Australia / TS013
-- (formerly TPH 1962, BRI)
ts014(22), -- Australia / TS014
-- (formerly TPH 1856, PRI)
qsig(23), -- Q.SIG
swissnet2(24), -- SwissNet-2
swissnet3(25) -- SwissNet-3
}
-- Isdn Mib objects definitions
isdnMibObjects OBJECT IDENTIFIER ::= { isdnMib 1 }
-- ISDN physical interface group
-- This group describes physical basic rate interfaces.
isdnBasicRateGroup OBJECT IDENTIFIER ::= { isdnMibObjects 1 }
isdnBasicRateTable OBJECT-TYPE
SYNTAX SEQUENCE OF IsdnBasicRateEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
Roeck Standards Track [Page 23]
RFC 2127 ISDN MIB March 1997
"Table containing configuration and operational
parameters for all physical Basic Rate
interfaces on this managed device."
::= { isdnBasicRateGroup 1 }
isdnBasicRateEntry OBJECT-TYPE
SYNTAX IsdnBasicRateEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the ISDN Basic Rate Table."
INDEX { ifIndex }
::= { isdnBasicRateTable 1 }
IsdnBasicRateEntry ::= SEQUENCE {
isdnBasicRateIfType INTEGER,
isdnBasicRateLineTopology INTEGER,
isdnBasicRateIfMode INTEGER,
isdnBasicRateSignalMode INTEGER
}
isdnBasicRateIfType OBJECT-TYPE
SYNTAX INTEGER {
isdns(75),
isdnu(76)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The physical interface type. For 'S/T' interfaces,
also called 'Four-wire Basic Access Interface',
the value of this object is isdns(75).
For 'U' interfaces, also called 'Two-wire Basic
Access Interface', the value of this object is
isdnu(76)."
::= { isdnBasicRateEntry 1 }
isdnBasicRateLineTopology OBJECT-TYPE
SYNTAX INTEGER {
pointToPoint(1),
pointToMultipoint(2)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The line topology to be used for this interface.
Note that setting isdnBasicRateIfType to isdns(75)
does not necessarily mean a line topology of
Roeck Standards Track [Page 24]
RFC 2127 ISDN MIB March 1997
point-to-multipoint."
::= { isdnBasicRateEntry 2 }
isdnBasicRateIfMode OBJECT-TYPE
SYNTAX INTEGER {
te(1),
nt(2)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The physical interface mode. For TE mode, the value
of this object is te(1). For NT mode, the value
of this object is nt(2)."
::= { isdnBasicRateEntry 3 }
isdnBasicRateSignalMode OBJECT-TYPE
SYNTAX INTEGER {
active(1),
inactive(2)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The signaling channel operational mode for this interface.
If active(1) there is a signaling channel on this
interface. If inactive(2) a signaling channel is
not available."
::= { isdnBasicRateEntry 4 }
-- The B channel (bearer channel) group
-- Note that disconnects can explicitely be handled using the
-- ifStack table. If a connection is to be disconnected,
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?