rfc2127.txt
来自「<VC++网络游戏建摸与实现>源代码」· 文本 代码 · 共 1,780 行 · 第 1/5 页
TXT
1,780 行
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 19974. DefinitionsISDN-MIB DEFINITIONS ::= BEGINIMPORTS 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 representedRoeck 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 conventionsIsdnSignalingProtocol ::= 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 servicesRoeck 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 definitionsisdnMibObjects 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 DESCRIPTIONRoeck 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 ofRoeck 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,-- the according ifStack entry has to be removed.-- More specifically, the ifStackTable entry which binds the high-layer-- ifTable entry (and related dialCtlNbrCfgTable entry) to the-- B channel ifTable entry (and related isdnBearerTable entry)-- during an active call has to be removed.isdnBearerGroup OBJECT IDENTIFIER ::= { isdnMibObjects 2 }isdnBearerTable OBJECT-TYPE SYNTAX SEQUENCE OF IsdnBearerEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table defines port specific operational, statisticsRoeck Standards Track [Page 25]RFC 2127 ISDN MIB March 1997 and active call data for ISDN B channels. Each entry in this table describes one B (bearer) channel." ::= { isdnBearerGroup 1 }isdnBearerEntry OBJECT-TYPE SYNTAX IsdnBearerEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Operational and statistics information relating to one port. A port is a single B channel." INDEX { ifIndex } ::= { isdnBearerTable 1 }IsdnBearerEntry ::= SEQUENCE { isdnBearerChannelType INTEGER, isdnBearerOperStatus INTEGER,
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?