The voice interface extended table defines the parameters related to the configuration of voice interfaces (DS0 group of DS1).
This table extends the ccasVoiceCfgTable.
Each table entry describes an instance of a voice interface configuration (DS0 group of DS1) in a media gateway.
InterfaceIndexA unique value, greater than zero, for each interface or interface sub-layer in the managed system. It is recommended that values are assigned contiguously starting from 1. The value for each interface sub-layer must remain constant at least from one re-initialization of the entity's network management system to the next re-initialization. (1..2147483647) · Integer32 · hint d
A unique value, greater than zero, for each interface. It is recommended that values are assigned contiguously starting from 1. The value for each interface sub-layer must remain constant at least from one re-initialization of the entity's network management system to the next re- initialization.
An arbitrary index that uniquely identifies a DS0 group in a T1/E1.
ccasIfExtVoiceCfgLifNumber
1.3.6.1.4.1.9.9.314.1.1.1.1.1
Unsigned32 (0..255)
This object specifies the LIF (Logical InterFace) number associated with this voice interface.
If this object is set to 0, this interface does not have an associated LIF.
ccasIfExtVoiceCfgCcntrlProfile
1.3.6.1.4.1.9.9.314.1.1.1.1.2
CCallControlProfileIndexOrZeroThis textual convention is an extension of the CCallControlProfileIndex convention. The latter defines a greater than zero value used to identify a call control profile in a media gateway. This extension permits the additional value of zero. The value of '0' means the default call control profile of the media gateway. (0..65535) · Unsigned32
This object specifies the index of call control profile that is used by this DS0 group. If the value of ccasGrpCfgServiceType is 'mgcp(6)', this is the index of cxeCallCtrlProfileTable. If the value of ccasGrpCfgServiceType is 'h248(9)', this is the index of cmedxPropertyProfileTable.
The value of 0 means the DS0 group is not associated any Profile. The DS0 group is using the default Call Control parameters defined in the media gateway.
ccasIfExtVoiceCfgVadEnabled
1.3.6.1.4.1.9.9.314.1.1.1.1.3
TruthValue1 = true2 = falseRepresents a boolean value. · Integer32
The object specifies VAD (Voice Activity Detection) is enabled for the compression DSPs of this interface.
The value of this object is 'false' if the voice interface associated DS0 group uses null signaling. (The value of ccasGrpCfgType in ccasGrpCfgTable for the DS0 group is set to nullSignaling(16)).
ccasIfExtVoiceCfgContinuityTone1
1.3.6.1.4.1.9.9.314.1.1.1.1.4
Unsigned32 (1..4000) · Hz
The object specifies the first frequency tone to be sent between the terminating and the originating gateways in the continuity test.
ccasIfExtVoiceCfgContinuityTone2
1.3.6.1.4.1.9.9.314.1.1.1.1.5
Unsigned32 (1..4000) · Hz
The object specifies the second frequency tone to be sent between the terminating and the originating gateways in the continuity test.
This object specifies the modem pass-through mode:
(1) passThruDisabled: Modem pass-through is disabled
(2) passThruCisco: Cisco Proprietary PV (Protocol
Violation) modem protocol used in modem pass-through.
(3) passThruNse: Name Signaling Events(NSE) used in
modem pass-through.
(4) passThruNseAal2: Name Signaling Events(NSE) over AAL2
used in modem pass-through.
(5) passThruCa: Gateway modem pass-through is based
on Call Agent(CA) Control. (This is a special way used by SGCP)
(6) passThruTypeE: FRF.11 Payload Type E packet used in
modem pass-through.
(7) system: System level modem pass-through
configuration is used for the dial-peer.
(8) passThruNseCa: Name Signaling Events(NSE) over IP
modem pass-through controlled by gateway in MGCP 1.0
This object specifies the CODEC type to use for modem upspeed. Upspeed is to change the transmission rate of the voice interface to a higher rate of CODEC type.
ccasIfExtVoiceCfgT38MaxFaxTxRate
1.3.6.1.4.1.9.9.314.1.1.1.1.8
CvcFaxTransmitRate1 = none2 = voiceRate3 = fax24004 = fax48005 = fax72006 = fax96007 = fax144008 = fax12000This object specifies the default transmit rate of FAX for the VoIP, VoATM or VOFR peer. If the value of this object is 'none', then the Fax relay feature is disabled ; otherwise the Fax relay feature is enabled.
none - Fax relay is disabled.
voiceRate - the fastest possible fax rate not exceed the configured voice rate.
fax2400 - 2400 bps FAX transmit rate.
fax4800 - 4800 bps FAX transmit rate.
fax7200 - 7200 bps FAX transmit rate.
fax9600 - 9600 bps FAX transmit rate.
fax14400 - 14400 bps FAX transmit rate.
fax12000 - 12000 bps FAX transmit rate. · Integer32
This object specifies the maximum FAX relay transmission rate.
ccasIfExtVoiceCfgT38HsPktPeriod
1.3.6.1.4.1.9.9.314.1.1.1.1.9
CiscoCodecPacketPeriod1 = pktPeriod5000us2 = pktPeriod5500us3 = pktPeriod5785us4 = pktPeriod10000us5 = pktPeriod15000us6 = pktPeriod20000us7 = pktPeriod25000us8 = pktPeriod30000us9 = pktPeriod35000us10 = pktPeriod40000us11 = pktPeriod45000us12 = pktPeriod50000us13 = pktPeriod55000us14 = pktPeriod60000us15 = pktPeriod65000us16 = pktPeriod70000us17 = pktPeriod75000us18 = pktPeriod80000us19 = pktPeriod85000us20 = pktPeriod90000usThis type defines the packetization period for a particular CODEC in microseconds.
The packetization period represents the time for the gateway to collect the data from TDM side before it sends out the packet. · Integer32 · microseconds
This object specifies the period of time for primary high speed (HS) data packet.
ccasIfExtVoiceCfgT38HsRedundancy
1.3.6.1.4.1.9.9.314.1.1.1.1.10
Unsigned32 (0..2) · FAX packets
The object specifies the number of redundant FAX packets for Internet FAX protocol (IFP) packet transmission. The value of '0' indicates that no redundant Internet FAX packets will be transmitted during the T.38 FAX relay connection. Reference: ITU-T T.38 Procedures for real-time Group 3 facsimile communicating over IP networks
ccasIfExtVoiceCfgRepetition
1.3.6.1.4.1.9.9.314.1.1.1.1.11
ConfigIteratorThis object type is a control object type which applies to writable objects in the same SNMP PDU related to the same table containing those objects. It controls an operation which repeatedly applies the specified configuration data to more than one rows in a table. The operation starts from the row specified by the index of the instance and repeats for the number of rows as the value of the object.
ConfigIterator object needs to be accompanied by one set of writable objects which are of the same instance to apply to.
For example, a SNMP PDU contains { objectA.10 = 1, objectB.10 = 'E1', objectC.10 = 44, objectRepetition.10 = 100 }
The SYNTAX of objectRepetition is ConfigIterator. This will apply value 1 to objectA, value 'E1' to objectB, value 44 to objectC in the table starting from row 10 repeatedly for 100 rows.
The iteration is based on the number of rows, not based on the value of the index. For sparse tables, the index 10, 20, 30, 110, and 120 counts for 5 rows, the operation will go beyond index 100 in the previous SNMP PDU example.
The iteration will stop prematurely when it comes to the following situations: (1) When the number of the rows in the table is less than the designated row indicated by the ConfigIterator object. (2) When it encounters the first error in any row, the operation won't continue to next row.
The operation of ConfigIterator object applies only to the writable objects having the same index as the ConfigIterator object in one SNMP PDU.
For example, a SNMP PDU contains { objectD.5 = 38, objectE.6 = 'T1', objectF.5 = 'false', objectIterator.5 = 10 }
The SYNTAX of objectIterator is ConfigIterator. This will apply value 38 to objectD, value 'false' to objectF in the table starting from row 5 repeatedly for 10 rows. Since the object objectE.6 has different index (6) from the index of objectIterator, the repetition won't be applied to it. However the value of objectE in the row 6 will be set to 'T1' according to regular SNMP SET orperation.
If there is row overlapping of the iteration in a SNMP PDU, it will be operated as they are in two different SNMP PDUs.
For example, a SNMP PDU contains { objectD.5 = 38, objectD.6 = 40, objectE.6 = 'T1', objectF.5 = 'false', objectIterator.5 = 10 objectIterator.6 = 10 }
This will apply value 38 to objectD, value 'false' to objectF starting from row 5 repeatedly for 10 rows, and apply value 40 to objectD, value 'T1' to objectE starting from row 6 repeatedly for 10 rows. The final value of objectD.6 can be 38 or 40, it depends on the SNMP stack of the system starts SNMP SET for the row 5 before the row 6 or the other way around.
The object defined as ConfigIterator will be set to value 1 after the iteration operation is kick-off regardless the system has completed the operation to the designated rows or not. Therefore retrieving the value of this object is meaningless. It acts as the one time operation for bulk configuration.
The object defined as ConfigIterator has no meaning by itself, it has to be combined with one or more than one writable objects from the same table and within the same SNMP PDU for the repetition operation.
For example, a SNMP PDU contains { objectG.2 = 49, objectH.2 = 'AE'h objectIterator.4 = 20 }
The SYNTAX of objectIterator is ConfigIterator. Since there are no objects having the same index as the index of objectIterator in the PDU, the result of this SNMP operation will set value 49 to objectG and value 0xAE to objectH of the row 2 only as regular SNMP SET operation.
The index of the instance indicates the starting row for the iteration. The order of the iteration depends, for instance, on: (1) physical hardware position, or (2) logical index.
It depends on the characters of the table which contains the ConfigIterator object.
Iteration can be done through some or all the components of the index for a table. The description of the iterator object in that table should describe which part of the index the iteration is applied to.
The operation for this object type is based on the best effort. When the agent receives a SNMP PDU containing this data type, the return status of the SNMP request reflects only the result of the SET operation has applied to the starting row. It may return a SNMP response with SUCCESS status regardless the number of rows for the data actually been deployed later on. Therefore it is possible the data might not be completely deployed to the number of rows designated by the ConfigIterator and the operation stops prematurely due to an error it first encounters after n rows (n < the value of ConfigIterator object).
Usually the error report mechanism for this type of operation is accomplished by combining this type of object with the other two objects in the same table:
(1) An OwnerString object (2) An object indicates the result of the operation.
When issuing this bulk configuration request, the SNMP manager should provide its identifier in (1) object. After issuing the request, it should check the value of (1) object if it is the same with it own name. If they are the same, then the value of the object presents in (2) is the result from the previous operation from this manager. Otherwise, another SNMP manager might issue the bulk configuration to the same table before the previous bulk operation has been completed. These two objects will represent the last bulk operation in the table. (1..4294967295) · Unsigned32
This object is used to repeatedly apply the writable objects of ccasIfExtVoiceCfgTable specified in the same SNMP PDU starting from the row specifies by the index of the instance for the number of rows specified in this object.
The order of operation is iterated through the logical order of the DS0 group. Whether the iteration will be applied across the physical boundary or not is depended on the system implementation.
ccasIfExtVoiceCfgBulkCfgOwner
1.3.6.1.4.1.9.9.314.1.1.1.1.12
OwnerStringThis data type is used to model an administratively assigned name of the owner of a resource. Implementations must accept values composed of well-formed NVT ASCII sequences. In addition, implementations should accept values composed of well-formed UTF-8 sequences.
It is suggested that this name contain one or more of the following: IP address, management station name, network manager's name, location, or phone number. In some cases the agent itself will be the owner of an entry. In these cases, this string shall be set to a string starting with 'monitor'.
SNMP access control is articulated entirely in terms of the contents of MIB views; access to a particular SNMP object instance depends only upon its presence or absence in a particular MIB view and never upon its value or the value of related object instances. Thus, objects of this type afford resolution of resource contention only among cooperating managers; they realize no access control function with respect to uncooperative parties. SIZE (0..127) · OCTET STRING
This object is used for error checking of the operation specified in ccasIfExtVoiceCfgRepetition.
The value of this object is set by the SNMP manager with its own identifier at the same time as issuing the bulk operation by setting ccasIfExtVoiceCfgRepetition. Later on, the SNMP manager should check the value of this object, if it is the same with the SNMP manager name, then the value of ccasIfExtVoiceCfgBulkCfgResult indicates the result of the bulk operation initiated by this SNMP manager.
ccasIfExtVoiceCfgBulkCfgResult
1.3.6.1.4.1.9.9.314.1.1.1.1.13
BulkConfigResultThis textual convention defines the format of the displayable textual result from the bulk configuration operation specified as ConfigIterator type.
The format should be:
'COMPLETION= error occured>/,
ERROR=/: '
For example: 'COMPLETION=22/100,ERROR=38/44:Invalid Ds1 line coding for the line type' SIZE (0..255) · OCTET STRING
This object is used for error checking of the operation specified in ccasIfExtVoiceCfgRepetition.
This object indicates the result of the bulk configuration initiated by the SNMP manager specified in the value of ccasIfExtVoiceCfgBulkCfgOwner.
ccasIfExtVoiceCfgVadTimer
1.3.6.1.4.1.9.9.314.1.1.1.1.14
Integer32 (250..65535) · milliseconds
This object specifies the hangover time for VAD.
Once the voice inactivity is detected, gateway will wait for this duration before activating silence suppression.
ccasIfExtVoiceCfgICSEnable
1.3.6.1.4.1.9.9.314.1.1.1.1.15
TruthValue1 = true2 = falseRepresents a boolean value. · Integer32
This object specifies whether the Idle Channel suppression (ICS) is enabled for an AAL2 connection.
ccasIfExtVoiceCfgICSIntTimer
1.3.6.1.4.1.9.9.314.1.1.1.1.16
Integer32 (0..65535) · milliseconds
This object specifies a timeout value for ICS integration timer. This timer is started once channel idle is detected. When the timer is expired, the gateway will stop transmitting bearer data to network. Instead, the CAS keep-alive packets will be sent.
ccasIfExtVoiceCfgTonePlan
1.3.6.1.4.1.9.9.314.1.1.1.1.17
CVoiceTonePlanIndexOrZeroThis textual convention uniquely identifies the voice tone plan to be used in a voice DS0 group.
The value of 0 means the default tone plan specified in the media gateway (the value of cMediaGwCcCfgDefaultTonePlanId) to be used.
A value greater than 0 means the tone plan specified by the index of the cvtcTonePlanTable to be used (same as cvtcTonePlanId). (0..65535) · Unsigned32
This object specifies which tone plan the DS0 group is using for playing the tones.
ccasIfExtVoiceCfgGwyLinkId
1.3.6.1.4.1.9.9.314.1.1.1.1.18
Integer32 (0..2147483647)
This object specifies the H.248 media gateway link that this DS0 group belongs to. This object is applicable only if the value of ccasGrpCfgServiceType is 'h248(9)'.
ccasIfExtVoiceCfgH248PkgIds
1.3.6.1.4.1.9.9.314.1.1.1.1.19
CH248PackagesThis textual convention defines all possible packages in H.248 protocol. · BITS
This object specifies the H.248 packages supported in this DS0 group. This object is applicable only if the value of ccasGrpCfgServiceType is 'h248(9)'.
ccasIfExtVoiceCfgEventMappingIdx
1.3.6.1.4.1.9.9.314.1.1.1.1.20
Unsigned32 (1..65535)
This object specifies the action of the voice band data signal events handling in this DS0 group. The real-time detected voice band data events are categorized by VoiceBandDataEventType defined in CISCO-VOICEBAND-DATA-PROFILE-MIB. The value of this object is cvbdpEventMappingIndex in cvbdpEventMappingTable. The event handling action is specified by the entry of cvbdpEventMappingTable indexed by the combination of the value of ccasIfExtVoiceCfgGatewayIndex, the value of this object and real-time voice band data event specified by VoiceBandDataEventType.
ccasIfExtVoiceCfgGatewayIndex
1.3.6.1.4.1.9.9.314.1.1.1.1.21
Unsigned32 (1..2147483647)
This object specifies the media gateway index that this DS0 group belong to. The value of this object is cmgwIndex in cMediaGwTable.
ccasIfExtVoiceCfgCasProfile
1.3.6.1.4.1.9.9.314.1.1.1.1.22
Unsigned32 (0..65535)
This object specifies the index of CAS profile that is used by this DS0 group. The value of this object is ccasProfileIndex in ccasIfExtProfileTable. This object is applicable only when the DS0 group is in a DS1 line whose signal mode is configured for CAS signaling, which means the dsx1SignalMode of the DS1 line is set to 'robbedBit(2)' for T1, or 'bitOriented(3)' for E1. If the DS1 is not configured for CAS and if the CAS profile index, ccasIfExtDs0GrpCasProfile is specified, the set operation will be rejected, and if it were not specified, it will default to a value 0. When the DS1 line is configured for CAS signaling, all the DS0 channels (ccasGrpCfgDs0Channels) in the DS1 line must be in one and only one DS0 group. If the DS1 is configured for CAS and if the CAS profile index, ccasIfExtDs0GrpCasProfile is not specified, the default CAS profile is 1.
ccasIfExtVoiceCfgCasVariant
1.3.6.1.4.1.9.9.314.1.1.1.1.23
Unsigned32 (0..65535)
This object specifies the index of CAS variant that is used by this DS0 group. The value of this object is the same as the value of ccasVariantIndex in ccasIfExtVariantTable.
This object is applicable only when the DS0 group is in a DS1 line whose signal mode is configured for CAS signaling, which means the dsx1SignalMode of the DS1 line is set to 'robbedBit(2)' for T1, or 'bitOriented(3)' for E1. When the DS1 line is configured for CAS signaling, all the DS0 channels (ccasGrpCfgDs0Channels) in the DS1 line must be in one and only one DS0 group.
It is a mandatory object when DS1 is configured for CAS. If the DS1 is not configured for CAS and ccasIfExtDs0GrpCasVariant is specified, the set operation will be rejected, and it has a default value 0 when it is not specified.
ccasIfExtVoiceCfgDs0ChannelsFail
1.3.6.1.4.1.9.9.314.1.1.1.1.24
OCTET STRING SIZE (4)
This object contains the bit map of the failure DS0 channels in the DS0 group. The MSB (most significant bit) is DS0 channel number 1. For T1, only higher 24 bits are used to specify the the CAS channels for the CAS group. A 1-bit indicates the failure channel in group and a 0-bit indicates it isn't.
ccasIfExtVoiceCfgNoiseRegType
1.3.6.1.4.1.9.9.314.1.1.1.1.25
INTEGER1 = none2 = simple3 = g711A2 · Integer32
This object specifies the type of comfort noise generation:
(1) none: No comfort noise generation (2) simple: Cisco Proprietary comfort noise generation (3) g711A2: ITU G.711 Appendix II compliant
This object is applicable only if 'ccasVoiceCfgNoiseRegEnable' is set to 'true'. When Voice Activation Detection(VAD) is enabled by setting 'ccasIfExtVoiceCfgVadEnabled' to 'true', 'ccasVoiceCfgNoiseRegEnable' indicates whether or not the background comfort noise should be played to fill the silence gaps. If 'ccasVoiceCfgNoiseRegEnable' is set to 'false', this object contains value 'none(1)'. Reference: 1. A comfort noise payload definition for ITU-T G.711 use in packet-based multimedia communication systems, ITU-T G.711 Appendix 2, Februrary, 2000. 2. CISCO-CAS-IF-MIB, ccasVoiceCfgNoiseRegEnable
The voice interface extended table defines the parameters related to the configuration of voice interfaces (DS0 group of DS1).
This table extends the ccasVoiceCfgTable.
Each table entry describes an instance of a voice interface configuration (DS0 group of DS1) in a media gateway.
InterfaceIndexA unique value, greater than zero, for each interface or interface sub-layer in the managed system. It is recommended that values are assigned contiguously starting from 1. The value for each interface sub-layer must remain constant at least from one re-initialization of the entity's network management system to the next re-initialization. (1..2147483647) · Integer32 · hint d
A unique value, greater than zero, for each interface. It is recommended that values are assigned contiguously starting from 1. The value for each interface sub-layer must remain constant at least from one re-initialization of the entity's network management system to the next re- initialization.
An arbitrary index that uniquely identifies a DS0 group in a T1/E1.
ccasIfExtDs0GrpRepetition
1.3.6.1.4.1.9.9.314.1.1.3.1.1
ConfigIteratorThis object type is a control object type which applies to writable objects in the same SNMP PDU related to the same table containing those objects. It controls an operation which repeatedly applies the specified configuration data to more than one rows in a table. The operation starts from the row specified by the index of the instance and repeats for the number of rows as the value of the object.
ConfigIterator object needs to be accompanied by one set of writable objects which are of the same instance to apply to.
For example, a SNMP PDU contains { objectA.10 = 1, objectB.10 = 'E1', objectC.10 = 44, objectRepetition.10 = 100 }
The SYNTAX of objectRepetition is ConfigIterator. This will apply value 1 to objectA, value 'E1' to objectB, value 44 to objectC in the table starting from row 10 repeatedly for 100 rows.
The iteration is based on the number of rows, not based on the value of the index. For sparse tables, the index 10, 20, 30, 110, and 120 counts for 5 rows, the operation will go beyond index 100 in the previous SNMP PDU example.
The iteration will stop prematurely when it comes to the following situations: (1) When the number of the rows in the table is less than the designated row indicated by the ConfigIterator object. (2) When it encounters the first error in any row, the operation won't continue to next row.
The operation of ConfigIterator object applies only to the writable objects having the same index as the ConfigIterator object in one SNMP PDU.
For example, a SNMP PDU contains { objectD.5 = 38, objectE.6 = 'T1', objectF.5 = 'false', objectIterator.5 = 10 }
The SYNTAX of objectIterator is ConfigIterator. This will apply value 38 to objectD, value 'false' to objectF in the table starting from row 5 repeatedly for 10 rows. Since the object objectE.6 has different index (6) from the index of objectIterator, the repetition won't be applied to it. However the value of objectE in the row 6 will be set to 'T1' according to regular SNMP SET orperation.
If there is row overlapping of the iteration in a SNMP PDU, it will be operated as they are in two different SNMP PDUs.
For example, a SNMP PDU contains { objectD.5 = 38, objectD.6 = 40, objectE.6 = 'T1', objectF.5 = 'false', objectIterator.5 = 10 objectIterator.6 = 10 }
This will apply value 38 to objectD, value 'false' to objectF starting from row 5 repeatedly for 10 rows, and apply value 40 to objectD, value 'T1' to objectE starting from row 6 repeatedly for 10 rows. The final value of objectD.6 can be 38 or 40, it depends on the SNMP stack of the system starts SNMP SET for the row 5 before the row 6 or the other way around.
The object defined as ConfigIterator will be set to value 1 after the iteration operation is kick-off regardless the system has completed the operation to the designated rows or not. Therefore retrieving the value of this object is meaningless. It acts as the one time operation for bulk configuration.
The object defined as ConfigIterator has no meaning by itself, it has to be combined with one or more than one writable objects from the same table and within the same SNMP PDU for the repetition operation.
For example, a SNMP PDU contains { objectG.2 = 49, objectH.2 = 'AE'h objectIterator.4 = 20 }
The SYNTAX of objectIterator is ConfigIterator. Since there are no objects having the same index as the index of objectIterator in the PDU, the result of this SNMP operation will set value 49 to objectG and value 0xAE to objectH of the row 2 only as regular SNMP SET operation.
The index of the instance indicates the starting row for the iteration. The order of the iteration depends, for instance, on: (1) physical hardware position, or (2) logical index.
It depends on the characters of the table which contains the ConfigIterator object.
Iteration can be done through some or all the components of the index for a table. The description of the iterator object in that table should describe which part of the index the iteration is applied to.
The operation for this object type is based on the best effort. When the agent receives a SNMP PDU containing this data type, the return status of the SNMP request reflects only the result of the SET operation has applied to the starting row. It may return a SNMP response with SUCCESS status regardless the number of rows for the data actually been deployed later on. Therefore it is possible the data might not be completely deployed to the number of rows designated by the ConfigIterator and the operation stops prematurely due to an error it first encounters after n rows (n < the value of ConfigIterator object).
Usually the error report mechanism for this type of operation is accomplished by combining this type of object with the other two objects in the same table:
(1) An OwnerString object (2) An object indicates the result of the operation.
When issuing this bulk configuration request, the SNMP manager should provide its identifier in (1) object. After issuing the request, it should check the value of (1) object if it is the same with it own name. If they are the same, then the value of the object presents in (2) is the result from the previous operation from this manager. Otherwise, another SNMP manager might issue the bulk configuration to the same table before the previous bulk operation has been completed. These two objects will represent the last bulk operation in the table. (1..4294967295) · Unsigned32
This object is used to repeatedly apply the writable objects of ccasIfExtDs0GrpCfgTable specified in the same SNMP PDU starting from the row specifies by the index of the instance for the number of rows specified in this object.
The repetition operation works differently for different DS0 channel bitmap configuration. When the DS0 channel bitmap is configured to contain a single DS0 channel, the order of operation is iterated through the value of DS0 group and the logical order of DS0 channel; When the DS0 channel bitmap is configured to contain more than one DS0 channels, the order of operation is iterated through logical order of DS1 channel, and all the iteration operations use the same DS0 channel bitmap configuration.
The repetition iteration will stop once the value of iterated value reaches its maximum limit. In the case of a single DS0 channel configuration, the repetition will stop when either the value of the DS0 group or the DS0 channel has reached its maximum. For multiple DS0 channel configuration, the repetition will stop once the value of DS1 reaches its maximum.
ccasIfExtDs0GrpRepeatOwner
1.3.6.1.4.1.9.9.314.1.1.3.1.2
OwnerStringThis data type is used to model an administratively assigned name of the owner of a resource. Implementations must accept values composed of well-formed NVT ASCII sequences. In addition, implementations should accept values composed of well-formed UTF-8 sequences.
It is suggested that this name contain one or more of the following: IP address, management station name, network manager's name, location, or phone number. In some cases the agent itself will be the owner of an entry. In these cases, this string shall be set to a string starting with 'monitor'.
SNMP access control is articulated entirely in terms of the contents of MIB views; access to a particular SNMP object instance depends only upon its presence or absence in a particular MIB view and never upon its value or the value of related object instances. Thus, objects of this type afford resolution of resource contention only among cooperating managers; they realize no access control function with respect to uncooperative parties. SIZE (0..127) · OCTET STRING
This object is used for error checking of the operation specified in ccasIfExtDs0GrpRepetition.
The value of this object is set by the SNMP manager with its own identifier at the same time as issuing the bulk operation by setting ccasIfExtDs0GrpRepetition. Later on, the SNMP manager should check the value of this object, if it is the same as the SNMP manager name, then the value of ccasIfExtDs0GrpRepeatResult indicates the result of the bulk operation initiated by this SNMP manager.
ccasIfExtDs0GrpRepeatResult
1.3.6.1.4.1.9.9.314.1.1.3.1.3
BulkConfigResultThis textual convention defines the format of the displayable textual result from the bulk configuration operation specified as ConfigIterator type.
The format should be:
'COMPLETION= error occured>/,
ERROR=/: '
For example: 'COMPLETION=22/100,ERROR=38/44:Invalid Ds1 line coding for the line type' SIZE (0..255) · OCTET STRING
This object is used for error checking of the operation specified in ccasIfExtDs0GrpRepetition.
This object indicates the result of the repetition initiated by the SNMP manager specified in the value of ccasIfExtDs0GrpRepeatOwner.
ccasIfExtProfileTable
1.3.6.1.4.1.9.9.314.1.2.1
Index: cmgwIndex · ccasProfileIndex
This table specifies a list of CAS profiles. Each CAS profile consists of the configurable CAS attributes related to: . Line signal timers table, ccasIfExtLineSignalTimerTable. . Register signals table, ccasIfExtRegisterSignalTable. . Register signal timers table, ccasIfExtRegSignalTimerTable. . General configurations table, ccasIfExtGeneralConfigTable.
A CAS profile can be applied to a DS0 group of the DS1 line with CAS signaling. A DS1 line is configured for CAS signaling when its dsx1SignalMode is set to 'robbedBit(2)' for T1 or 'bitOriented(3)' for E1.
An index that uniquely identifies an entry in the cMediaGwTable.
ccasProfileIndex
1.3.6.1.4.1.9.9.314.1.2.1.1.1
Unsigned32 (1..65535)
This object uniquely identifies the CAS profile. The value of 1 specifies the default CAS profile in the media gateway.
ccasProfileLineSigTimer
1.3.6.1.4.1.9.9.314.1.2.1.1.2
Unsigned32 (1..65535)
This object specifies the attributes of CAS line signaling timers indicated by ccasLSTIndex in ccasIfExtLineSignalTimerTable.
ccasProfileRegisterSignal
1.3.6.1.4.1.9.9.314.1.2.1.1.3
Unsigned32 (1..65535)
This object specifies the attributes of CAS register signals indicated by ccasRSIndex in ccasIfExtRegisterSignalTable.
ccasProfileRegSigTimer
1.3.6.1.4.1.9.9.314.1.2.1.1.4
Unsigned32 (1..65535)
This object specifies the attributes of CAS register signaling timers indicated by ccasRSTIndex in ccasIfExtRegSignalTimerTable.
ccasProfileGeneralCfg
1.3.6.1.4.1.9.9.314.1.2.1.1.5
Unsigned32 (1..65535)
This object specifies the general CAS attributes indicated by ccasGCnfIndex in ccasIfExtGeneralConfigTable.
ccasProfileRowStatus
1.3.6.1.4.1.9.9.314.1.2.1.1.6
RowStatus1 = active2 = notInService3 = notReady4 = createAndGo5 = createAndWait6 = destroyThe RowStatus textual convention is used to manage the creation and deletion of conceptual rows, and is used as the value of the SYNTAX clause for the status column of a conceptual row (as described in Section 7.7.1 of [2].)
The status column has six defined values:
- `active', which indicates that the conceptual row is available for use by the managed device;
- `notInService', which indicates that the conceptual row exists in the agent, but is unavailable for use by the managed device (see NOTE below); 'notInService' has no implication regarding the internal consistency of the row, availability of resources, or consistency with the current state of the managed device;
- `notReady', which indicates that the conceptual row exists in the agent, but is missing information necessary in order to be available for use by the managed device (i.e., one or more required columns in the conceptual row have not been instanciated);
- `createAndGo', which is supplied by a management station wishing to create a new instance of a conceptual row and to have its status automatically set to active, making it available for use by the managed device;
- `createAndWait', which is supplied by a management station wishing to create a new instance of a conceptual row (but not make it available for use by the managed device); and, - `destroy', which is supplied by a management station wishing to delete all of the instances associated with an existing conceptual row.
Whereas five of the six values (all except `notReady') may be specified in a management protocol set operation, only three values will be returned in response to a management
protocol retrieval operation: `notReady', `notInService' or
`active'. That is, when queried, an existing conceptual row
has only three states: it is either available for use by
the managed device (the status column has value `active'); it is not available for use by the managed device, though the agent has sufficient information to attempt to make it so (the status column has value `notInService'); or, it is not available for use by the managed device, and an attempt to make it so would fail because the agent has insufficient information (the state column has value `notReady').
NOTE WELL
This textual convention may be used for a MIB table, irrespective of whether the values of that table's conceptual rows are able to be modified while it is active, or whether its conceptual rows must be taken out of service in order to be modified. That is, it is the responsibility of the DESCRIPTION clause of the status column to specify whether the status column must not be `active' in order for the value of some other column of the same conceptual row to be modified. If such a specification is made, affected columns may be changed by an SNMP set PDU if the RowStatus would not be equal to `active' either immediately before or after processing the PDU. In other words, if the PDU also contained a varbind that would change the RowStatus value, the column in question may be changed if the RowStatus was not equal to `active' as the PDU was received, or if the varbind sets the status to a value other than 'active'.
Also note that whenever any elements of a row exist, the RowStatus column must also exist.
To summarize the effect of having a conceptual row with a status column having a SYNTAX clause value of RowStatus, consider the following state diagram:
STATE +--------------+-----------+-------------+-------------
| A | B | C | D
| |status col.|status column|
|status column | is | is |status column
ACTION |does not exist| notReady | notInService| is active
--------------+--------------+-----------+-------------+-------------
set status |noError ->D|inconsist- |inconsistent-|inconsistent-
column to | or | entValue| Value| Value
createAndGo |inconsistent- | | |
| Value| | |
--------------+--------------+-----------+-------------+-------------
set status |noError see 1|inconsist- |inconsistent-|inconsistent-
column to | or | entValue| Value| Value
createAndWait |wrongValue | | |
--------------+--------------+-----------+-------------+-------------
set status |inconsistent- |inconsist- |noError |noError
column to | Value| entValue| |
active | | | |
| | or | |
| | | |
| |see 2 ->D|see 8 ->D| ->D
--------------+--------------+-----------+-------------+-------------
set status |inconsistent- |inconsist- |noError |noError ->C
column to | Value| entValue| |
notInService | | | |
| | or | | or
| | | |
| |see 3 ->C| ->C|see 6
--------------+--------------+-----------+-------------+-------------
set status |noError |noError |noError |noError ->A
column to | | | | or
destroy | ->A| ->A| ->A|see 7
--------------+--------------+-----------+-------------+-------------
set any other |see 4 |noError |noError |see 5
column to some| | | |
value | | see 1| ->C| ->D
--------------+--------------+-----------+-------------+-------------
(1) goto B or C, depending on information available to the agent.
(2) if other variable bindings included in the same PDU, provide values for all columns which are missing but required, and all columns have acceptable values, then return noError and goto D.
(3) if other variable bindings included in the same PDU, provide legal values for all columns which are missing but required, then return noError and goto C.
(4) at the discretion of the agent, the return value may be either:
inconsistentName: because the agent does not choose to
create such an instance when the corresponding RowStatus instance does not exist, or
inconsistentValue: if the supplied value is
inconsistent with the state of some other MIB object's value, or
noError: because the agent chooses to create the instance.
If noError is returned, then the instance of the status column must also be created, and the new state is B or C, depending on the information available to the agent. If inconsistentName or inconsistentValue is returned, the row remains in state A.
(5) depending on the MIB definition for the column/table, either noError or inconsistentValue may be returned.
(6) the return value can indicate one of the following errors:
wrongValue: because the agent does not support notInService (e.g., an agent which does not support createAndWait), or
inconsistentValue: because the agent is unable to take the row out of service at this time, perhaps because it is in use and cannot be de-activated.
(7) the return value can indicate the following error:
inconsistentValue: because the agent is unable to remove the row at this time, perhaps because it is in use and cannot be de-activated.
(8) the transition to D can fail, e.g., if the values of the conceptual row are inconsistent, then the error code would be inconsistentValue.
NOTE: Other processing of (this and other varbinds of) the set request may result in a response other than noError being returned, e.g., wrongValue, noCreation, etc.
Conceptual Row Creation
There are four potential interactions when creating a
conceptual row: selecting an instance-identifier which is
not in use; creating the conceptual row; initializing any objects for which the agent does not supply a default; and, making the conceptual row available for use by the managed device.
Interaction 1: Selecting an Instance-Identifier
The algorithm used to select an instance-identifier varies for each conceptual row. In some cases, the instance- identifier is semantically significant, e.g., the destination address of a route, and a management station selects the instance-identifier according to the semantics.
In other cases, the instance-identifier is used solely to distinguish conceptual rows, and a management station without specific knowledge of the conceptual row might examine the instances present in order to determine an unused instance-identifier. (This approach may be used, but it is often highly sub-optimal; however, it is also a questionable practice for a naive management station to attempt conceptual row creation.)
Alternately, the MIB module which defines the conceptual row might provide one or more objects which provide assistance in determining an unused instance-identifier. For example, if the conceptual row is indexed by an integer-value, then an object having an integer-valued SYNTAX clause might be defined for such a purpose, allowing a management station to issue a management protocol retrieval operation. In order to avoid unnecessary collisions between competing management stations, `adjacent' retrievals of this object should be different.
Finally, the management station could select a pseudo-random number to use as the index. In the event that this index
was already in use and an inconsistentValue was returned in response to the management protocol set operation, the management station should simply select a new pseudo-random number and retry the operation.
A MIB designer should choose between the two latter algorithms based on the size of the table (and therefore the efficiency of each algorithm). For tables in which a large number of entries are expected, it is recommended that a MIB object be defined that returns an acceptable index for creation. For tables with small numbers of entries, it is recommended that the latter pseudo-random index mechanism be used.
Interaction 2: Creating the Conceptual Row
Once an unused instance-identifier has been selected, the management station determines if it wishes to create and activate the conceptual row in one transaction or in a negotiated set of interactions.
Interaction 2a: Creating and Activating the Conceptual Row
The management station must first determine the column requirements, i.e., it must determine those columns for which it must or must not provide values. Depending on the complexity of the table and the management station's knowledge of the agent's capabilities, this determination can be made locally by the management station. Alternately, the management station issues a management protocol get operation to examine all columns in the conceptual row that it wishes to create. In response, for each column, there are three possible outcomes:
- a value is returned, indicating that some other management station has already created this conceptual row. We return to interaction 1.
- the exception `noSuchInstance' is returned, indicating that the agent implements the object-type associated with this column, and that this column in at least one conceptual row would be accessible in the MIB view used by the retrieval were it to exist. For those columns to which the agent provides read-create access, the `noSuchInstance' exception tells the management station that it should supply a value for this column when the conceptual row is to be created.
- the exception `noSuchObject' is returned, indicating that the agent does not implement the object-type associated with this column or that there is no conceptual row for which this column would be accessible in the MIB view used by the retrieval. As such, the management station can not issue any management protocol set operations to create an instance of this column.
Once the column requirements have been determined, a management protocol set operation is accordingly issued. This operation also sets the new instance of the status column to `createAndGo'.
When the agent processes the set operation, it verifies that it has sufficient information to make the conceptual row available for use by the managed device. The information
available to the agent is provided by two sources: the
management protocol set operation which creates the conceptual row, and, implementation-specific defaults supplied by the agent (note that an agent must provide implementation-specific defaults for at least those objects which it implements as read-only). If there is sufficient information available, then the conceptual row is created, a `noError' response is returned, the status column is set to `active', and no further interactions are necessary (i.e., interactions 3 and 4 are skipped). If there is insufficient information, then the conceptual row is not created, and the set operation fails with an error of `inconsistentValue'. On this error, the management station can issue a management protocol retrieval operation to determine if this was because it failed to specify a value for a required column, or, because the selected instance of the status column already existed. In the latter case, we return to interaction 1. In the former case, the management station can re-issue the set operation with the additional information, or begin interaction 2 again using `createAndWait' in order to negotiate creation of the conceptual row.
NOTE WELL
Regardless of the method used to determine the column requirements, it is possible that the management station might deem a column necessary when, in fact, the agent will not allow that particular columnar instance to be created or written. In this case, the management protocol set operation will fail with an error such as `noCreation' or `notWritable'. In this case, the management station decides whether it needs to be able to set a value for that particular columnar instance. If not, the management station re-issues the management protocol set operation, but without setting a value for that particular columnar instance; otherwise, the management station aborts the row creation algorithm.
Interaction 2b: Negotiating the Creation of the Conceptual Row
The management station issues a management protocol set operation which sets the desired instance of the status column to `createAndWait'. If the agent is unwilling to process a request of this sort, the set operation fails with an error of `wrongValue'. (As a consequence, such an agent must be prepared to accept a single management protocol set operation, i.e., interaction 2a above, containing all of the
columns indicated by its column requirements.) Otherwise,
the conceptual row is created, a `noError' response is returned, and the status column is immediately set to either `notInService' or `notReady', depending on whether it has sufficient information to (attempt to) make the conceptual row available for use by the managed device. If there is sufficient information available, then the status column is set to `notInService'; otherwise, if there is insufficient information, then the status column is set to `notReady'. Regardless, we proceed to interaction 3.
Interaction 3: Initializing non-defaulted Objects
The management station must now determine the column requirements. It issues a management protocol get operation to examine all columns in the created conceptual row. In the response, for each column, there are three possible outcomes:
- a value is returned, indicating that the agent implements the object-type associated with this column and had sufficient information to provide a value. For those columns to which the agent provides read-create access (and for which the agent allows their values to be changed after their creation), a value return tells the management station that it may issue additional management protocol set operations, if it desires, in order to change the value associated with this column.
- the exception `noSuchInstance' is returned, indicating that the agent implements the object-type associated with this column, and that this column in at least one conceptual row would be accessible in the MIB view used by the retrieval were it to exist. However, the agent does not have sufficient information to provide a value, and until a value is provided, the conceptual row may not be made available for use by the managed device. For those columns to which the agent provides read-create access, the `noSuchInstance' exception tells the management station that it must issue additional management protocol set operations, in order to provide a value associated with this column.
- the exception `noSuchObject' is returned, indicating that the agent does not implement the object-type associated with this column or that there is no conceptual row for which this column would be accessible in the MIB view used by the retrieval. As such, the management station can not issue any management protocol set operations to create an instance of this column.
If the value associated with the status column is `notReady', then the management station must first deal with all `noSuchInstance' columns, if any. Having done so, the value of the status column becomes `notInService', and we proceed to interaction 4.
Interaction 4: Making the Conceptual Row Available
Once the management station is satisfied with the values associated with the columns of the conceptual row, it issues a management protocol set operation to set the status column to `active'. If the agent has sufficient information to make the conceptual row available for use by the managed device, the management protocol set operation succeeds (a `noError' response is returned). Otherwise, the management protocol set operation fails with an error of `inconsistentValue'.
NOTE WELL
A conceptual row having a status column with value `notInService' or `notReady' is unavailable to the managed device. As such, it is possible for the managed device to create its own instances during the time between the management protocol set operation which sets the status column to `createAndWait' and the management protocol set operation which sets the status column to `active'. In this case, when the management protocol set operation is issued to set the status column to `active', the values held in the agent supersede those used by the managed device.
If the management station is prevented from setting the status column to `active' (e.g., due to management station or network failure) the conceptual row will be left in the `notInService' or `notReady' state, consuming resources indefinitely. The agent must detect conceptual rows that have been in either state for an abnormally long period of time and remove them. It is the responsibility of the DESCRIPTION clause of the status column to indicate what an abnormally long period of time would be. This period of time should be long enough to allow for human response time (including `think time') between the creation of the conceptual row and the setting of the status to `active'. In the absence of such information in the DESCRIPTION clause, it is suggested that this period be approximately 5 minutes in length. This removal action applies not only to newly-created rows, but also to previously active rows which are set to, and left in, the notInService state for a prolonged period exceeding that which is considered normal for such a conceptual row.
Conceptual Row Suspension
When a conceptual row is `active', the management station may issue a management protocol set operation which sets the instance of the status column to `notInService'. If the agent is unwilling to do so, the set operation fails with an error of `wrongValue' or `inconsistentValue'. Otherwise, the conceptual row is taken out of service, and a `noError' response is returned. It is the responsibility of the DESCRIPTION clause of the status column to indicate under what circumstances the status column should be taken out of service (e.g., in order for the value of some other column of the same conceptual row to be modified).
Conceptual Row Deletion
For deletion of conceptual rows, a management protocol set operation is issued which sets the instance of the status column to `destroy'. This request may be made regardless of the current value of the status column (e.g., it is possible to delete conceptual rows which are either `notReady',
`notInService' or `active'.) If the operation succeeds,
then all instances associated with the conceptual row are immediately removed. · Integer32
When the entry is created, all the associated entries indexed by the following objects must be existing: ccasProfileLineSigTimer, ccasProfileRegisterSignal, ccasProfileRegSigTimer, ccasProfileGeneralCfg.
The entry of the default CAS profile indexed by 1 is created by the system automatically, it cannot be added, deleted, or modified.
ccasIfExtVariantTable
1.3.6.1.4.1.9.9.314.1.2.2
Index: cmgwIndex · ccasVariantIndex
This table specifies a list of CAS signaling protocols such as R2 CAS, Feature Group D Oprerator Services ( FGD OS). Each CAS variant is downloaded to and parsed by the media gateway. A CAS variant can be applied to a DS0 group of the DS1 line with CAS signaling. A DS1 line is configured for CAS signaling when its dsx1SignalMode is set to 'robbedBit(2)' for T1 or 'bitOriented(3)' for E1.
An index that uniquely identifies an entry in the cMediaGwTable.
ccasVariantIndex
1.3.6.1.4.1.9.9.314.1.2.2.1.1
Unsigned32 (1..65535)
An arbitrary value which uniquely identifies the CAS variant in the media gateway.
ccasVariantFile
1.3.6.1.4.1.9.9.314.1.2.2.1.2
SnmpAdminStringAn octet string containing administrative information, preferably in human-readable form.
To facilitate internationalization, this information is represented using the ISO/IEC IS 10646-1 character set, encoded as an octet string using the UTF-8 transformation format described in [RFC2279].
Since additional code points are added by amendments to the 10646 standard from time to time, implementations must be prepared to encounter any code point from 0x00000000 to 0x7fffffff. Byte sequences that do not correspond to the valid UTF-8 encoding of a code point or are outside this range are prohibited.
The use of control codes should be avoided.
When it is necessary to represent a newline, the control code sequence CR LF should be used.
The use of leading or trailing white space should be avoided.
For code points not directly supported by user interface hardware or software, an alternative means of entry and display, such as hexadecimal, may be provided.
For information encoded in 7-bit US-ASCII, the UTF-8 encoding is identical to the US-ASCII encoding.
UTF-8 may require multiple bytes to represent a single character / code point; thus the length of this object in octets may be different from the number of characters encoded. Similarly, size constraints refer to the number of encoded octets, not the number of characters represented by an encoding.
Note that when this TC is used for an object that is used or envisioned to be used as an index, then a SIZE restriction MUST be specified so that the number of sub-identifiers for any object instance does not exceed the limit of 128, as defined by [RFC3416].
Note that the size of an SnmpAdminString object is measured in octets, not characters. SIZE (1..64) · OCTET STRING · hint 255t
This object specifies the valid file name with extension '.o' stored on the media gateway's hard disk. The CAS variant file can be transferred to the media gateway via FTP text file transfer mechanism.
ccasVariantSource
1.3.6.1.4.1.9.9.314.1.2.2.1.3
INTEGER1 = internal2 = external · Integer32
This object specifies the source from where the CAS variant file must be fetched. . internal: Value indicates that the file is built into the firmware. . external: Value indicates that the file is to be downloaded from the media gateway.
ccasVariantNumberCount
1.3.6.1.4.1.9.9.314.1.2.2.1.4
Gauge32
This object indicates the number of DS0 groups of the DS1 line which are used for the CAS variant.
This object indicates the configuration status of the CAS variant. . initInProgress: The state machine is being initialized. . initSuccessfully: The state machine was initialized properly. . initFailed: The intialization failed.
ccasVariantRowStatus
1.3.6.1.4.1.9.9.314.1.2.2.1.6
RowStatus1 = active2 = notInService3 = notReady4 = createAndGo5 = createAndWait6 = destroyThe RowStatus textual convention is used to manage the creation and deletion of conceptual rows, and is used as the value of the SYNTAX clause for the status column of a conceptual row (as described in Section 7.7.1 of [2].)
The status column has six defined values:
- `active', which indicates that the conceptual row is available for use by the managed device;
- `notInService', which indicates that the conceptual row exists in the agent, but is unavailable for use by the managed device (see NOTE below); 'notInService' has no implication regarding the internal consistency of the row, availability of resources, or consistency with the current state of the managed device;
- `notReady', which indicates that the conceptual row exists in the agent, but is missing information necessary in order to be available for use by the managed device (i.e., one or more required columns in the conceptual row have not been instanciated);
- `createAndGo', which is supplied by a management station wishing to create a new instance of a conceptual row and to have its status automatically set to active, making it available for use by the managed device;
- `createAndWait', which is supplied by a management station wishing to create a new instance of a conceptual row (but not make it available for use by the managed device); and, - `destroy', which is supplied by a management station wishing to delete all of the instances associated with an existing conceptual row.
Whereas five of the six values (all except `notReady') may be specified in a management protocol set operation, only three values will be returned in response to a management
protocol retrieval operation: `notReady', `notInService' or
`active'. That is, when queried, an existing conceptual row
has only three states: it is either available for use by
the managed device (the status column has value `active'); it is not available for use by the managed device, though the agent has sufficient information to attempt to make it so (the status column has value `notInService'); or, it is not available for use by the managed device, and an attempt to make it so would fail because the agent has insufficient information (the state column has value `notReady').
NOTE WELL
This textual convention may be used for a MIB table, irrespective of whether the values of that table's conceptual rows are able to be modified while it is active, or whether its conceptual rows must be taken out of service in order to be modified. That is, it is the responsibility of the DESCRIPTION clause of the status column to specify whether the status column must not be `active' in order for the value of some other column of the same conceptual row to be modified. If such a specification is made, affected columns may be changed by an SNMP set PDU if the RowStatus would not be equal to `active' either immediately before or after processing the PDU. In other words, if the PDU also contained a varbind that would change the RowStatus value, the column in question may be changed if the RowStatus was not equal to `active' as the PDU was received, or if the varbind sets the status to a value other than 'active'.
Also note that whenever any elements of a row exist, the RowStatus column must also exist.
To summarize the effect of having a conceptual row with a status column having a SYNTAX clause value of RowStatus, consider the following state diagram:
STATE +--------------+-----------+-------------+-------------
| A | B | C | D
| |status col.|status column|
|status column | is | is |status column
ACTION |does not exist| notReady | notInService| is active
--------------+--------------+-----------+-------------+-------------
set status |noError ->D|inconsist- |inconsistent-|inconsistent-
column to | or | entValue| Value| Value
createAndGo |inconsistent- | | |
| Value| | |
--------------+--------------+-----------+-------------+-------------
set status |noError see 1|inconsist- |inconsistent-|inconsistent-
column to | or | entValue| Value| Value
createAndWait |wrongValue | | |
--------------+--------------+-----------+-------------+-------------
set status |inconsistent- |inconsist- |noError |noError
column to | Value| entValue| |
active | | | |
| | or | |
| | | |
| |see 2 ->D|see 8 ->D| ->D
--------------+--------------+-----------+-------------+-------------
set status |inconsistent- |inconsist- |noError |noError ->C
column to | Value| entValue| |
notInService | | | |
| | or | | or
| | | |
| |see 3 ->C| ->C|see 6
--------------+--------------+-----------+-------------+-------------
set status |noError |noError |noError |noError ->A
column to | | | | or
destroy | ->A| ->A| ->A|see 7
--------------+--------------+-----------+-------------+-------------
set any other |see 4 |noError |noError |see 5
column to some| | | |
value | | see 1| ->C| ->D
--------------+--------------+-----------+-------------+-------------
(1) goto B or C, depending on information available to the agent.
(2) if other variable bindings included in the same PDU, provide values for all columns which are missing but required, and all columns have acceptable values, then return noError and goto D.
(3) if other variable bindings included in the same PDU, provide legal values for all columns which are missing but required, then return noError and goto C.
(4) at the discretion of the agent, the return value may be either:
inconsistentName: because the agent does not choose to
create such an instance when the corresponding RowStatus instance does not exist, or
inconsistentValue: if the supplied value is
inconsistent with the state of some other MIB object's value, or
noError: because the agent chooses to create the instance.
If noError is returned, then the instance of the status column must also be created, and the new state is B or C, depending on the information available to the agent. If inconsistentName or inconsistentValue is returned, the row remains in state A.
(5) depending on the MIB definition for the column/table, either noError or inconsistentValue may be returned.
(6) the return value can indicate one of the following errors:
wrongValue: because the agent does not support notInService (e.g., an agent which does not support createAndWait), or
inconsistentValue: because the agent is unable to take the row out of service at this time, perhaps because it is in use and cannot be de-activated.
(7) the return value can indicate the following error:
inconsistentValue: because the agent is unable to remove the row at this time, perhaps because it is in use and cannot be de-activated.
(8) the transition to D can fail, e.g., if the values of the conceptual row are inconsistent, then the error code would be inconsistentValue.
NOTE: Other processing of (this and other varbinds of) the set request may result in a response other than noError being returned, e.g., wrongValue, noCreation, etc.
Conceptual Row Creation
There are four potential interactions when creating a
conceptual row: selecting an instance-identifier which is
not in use; creating the conceptual row; initializing any objects for which the agent does not supply a default; and, making the conceptual row available for use by the managed device.
Interaction 1: Selecting an Instance-Identifier
The algorithm used to select an instance-identifier varies for each conceptual row. In some cases, the instance- identifier is semantically significant, e.g., the destination address of a route, and a management station selects the instance-identifier according to the semantics.
In other cases, the instance-identifier is used solely to distinguish conceptual rows, and a management station without specific knowledge of the conceptual row might examine the instances present in order to determine an unused instance-identifier. (This approach may be used, but it is often highly sub-optimal; however, it is also a questionable practice for a naive management station to attempt conceptual row creation.)
Alternately, the MIB module which defines the conceptual row might provide one or more objects which provide assistance in determining an unused instance-identifier. For example, if the conceptual row is indexed by an integer-value, then an object having an integer-valued SYNTAX clause might be defined for such a purpose, allowing a management station to issue a management protocol retrieval operation. In order to avoid unnecessary collisions between competing management stations, `adjacent' retrievals of this object should be different.
Finally, the management station could select a pseudo-random number to use as the index. In the event that this index
was already in use and an inconsistentValue was returned in response to the management protocol set operation, the management station should simply select a new pseudo-random number and retry the operation.
A MIB designer should choose between the two latter algorithms based on the size of the table (and therefore the efficiency of each algorithm). For tables in which a large number of entries are expected, it is recommended that a MIB object be defined that returns an acceptable index for creation. For tables with small numbers of entries, it is recommended that the latter pseudo-random index mechanism be used.
Interaction 2: Creating the Conceptual Row
Once an unused instance-identifier has been selected, the management station determines if it wishes to create and activate the conceptual row in one transaction or in a negotiated set of interactions.
Interaction 2a: Creating and Activating the Conceptual Row
The management station must first determine the column requirements, i.e., it must determine those columns for which it must or must not provide values. Depending on the complexity of the table and the management station's knowledge of the agent's capabilities, this determination can be made locally by the management station. Alternately, the management station issues a management protocol get operation to examine all columns in the conceptual row that it wishes to create. In response, for each column, there are three possible outcomes:
- a value is returned, indicating that some other management station has already created this conceptual row. We return to interaction 1.
- the exception `noSuchInstance' is returned, indicating that the agent implements the object-type associated with this column, and that this column in at least one conceptual row would be accessible in the MIB view used by the retrieval were it to exist. For those columns to which the agent provides read-create access, the `noSuchInstance' exception tells the management station that it should supply a value for this column when the conceptual row is to be created.
- the exception `noSuchObject' is returned, indicating that the agent does not implement the object-type associated with this column or that there is no conceptual row for which this column would be accessible in the MIB view used by the retrieval. As such, the management station can not issue any management protocol set operations to create an instance of this column.
Once the column requirements have been determined, a management protocol set operation is accordingly issued. This operation also sets the new instance of the status column to `createAndGo'.
When the agent processes the set operation, it verifies that it has sufficient information to make the conceptual row available for use by the managed device. The information
available to the agent is provided by two sources: the
management protocol set operation which creates the conceptual row, and, implementation-specific defaults supplied by the agent (note that an agent must provide implementation-specific defaults for at least those objects which it implements as read-only). If there is sufficient information available, then the conceptual row is created, a `noError' response is returned, the status column is set to `active', and no further interactions are necessary (i.e., interactions 3 and 4 are skipped). If there is insufficient information, then the conceptual row is not created, and the set operation fails with an error of `inconsistentValue'. On this error, the management station can issue a management protocol retrieval operation to determine if this was because it failed to specify a value for a required column, or, because the selected instance of the status column already existed. In the latter case, we return to interaction 1. In the former case, the management station can re-issue the set operation with the additional information, or begin interaction 2 again using `createAndWait' in order to negotiate creation of the conceptual row.
NOTE WELL
Regardless of the method used to determine the column requirements, it is possible that the management station might deem a column necessary when, in fact, the agent will not allow that particular columnar instance to be created or written. In this case, the management protocol set operation will fail with an error such as `noCreation' or `notWritable'. In this case, the management station decides whether it needs to be able to set a value for that particular columnar instance. If not, the management station re-issues the management protocol set operation, but without setting a value for that particular columnar instance; otherwise, the management station aborts the row creation algorithm.
Interaction 2b: Negotiating the Creation of the Conceptual Row
The management station issues a management protocol set operation which sets the desired instance of the status column to `createAndWait'. If the agent is unwilling to process a request of this sort, the set operation fails with an error of `wrongValue'. (As a consequence, such an agent must be prepared to accept a single management protocol set operation, i.e., interaction 2a above, containing all of the
columns indicated by its column requirements.) Otherwise,
the conceptual row is created, a `noError' response is returned, and the status column is immediately set to either `notInService' or `notReady', depending on whether it has sufficient information to (attempt to) make the conceptual row available for use by the managed device. If there is sufficient information available, then the status column is set to `notInService'; otherwise, if there is insufficient information, then the status column is set to `notReady'. Regardless, we proceed to interaction 3.
Interaction 3: Initializing non-defaulted Objects
The management station must now determine the column requirements. It issues a management protocol get operation to examine all columns in the created conceptual row. In the response, for each column, there are three possible outcomes:
- a value is returned, indicating that the agent implements the object-type associated with this column and had sufficient information to provide a value. For those columns to which the agent provides read-create access (and for which the agent allows their values to be changed after their creation), a value return tells the management station that it may issue additional management protocol set operations, if it desires, in order to change the value associated with this column.
- the exception `noSuchInstance' is returned, indicating that the agent implements the object-type associated with this column, and that this column in at least one conceptual row would be accessible in the MIB view used by the retrieval were it to exist. However, the agent does not have sufficient information to provide a value, and until a value is provided, the conceptual row may not be made available for use by the managed device. For those columns to which the agent provides read-create access, the `noSuchInstance' exception tells the management station that it must issue additional management protocol set operations, in order to provide a value associated with this column.
- the exception `noSuchObject' is returned, indicating that the agent does not implement the object-type associated with this column or that there is no conceptual row for which this column would be accessible in the MIB view used by the retrieval. As such, the management station can not issue any management protocol set operations to create an instance of this column.
If the value associated with the status column is `notReady', then the management station must first deal with all `noSuchInstance' columns, if any. Having done so, the value of the status column becomes `notInService', and we proceed to interaction 4.
Interaction 4: Making the Conceptual Row Available
Once the management station is satisfied with the values associated with the columns of the conceptual row, it issues a management protocol set operation to set the status column to `active'. If the agent has sufficient information to make the conceptual row available for use by the managed device, the management protocol set operation succeeds (a `noError' response is returned). Otherwise, the management protocol set operation fails with an error of `inconsistentValue'.
NOTE WELL
A conceptual row having a status column with value `notInService' or `notReady' is unavailable to the managed device. As such, it is possible for the managed device to create its own instances during the time between the management protocol set operation which sets the status column to `createAndWait' and the management protocol set operation which sets the status column to `active'. In this case, when the management protocol set operation is issued to set the status column to `active', the values held in the agent supersede those used by the managed device.
If the management station is prevented from setting the status column to `active' (e.g., due to management station or network failure) the conceptual row will be left in the `notInService' or `notReady' state, consuming resources indefinitely. The agent must detect conceptual rows that have been in either state for an abnormally long period of time and remove them. It is the responsibility of the DESCRIPTION clause of the status column to indicate what an abnormally long period of time would be. This period of time should be long enough to allow for human response time (including `think time') between the creation of the conceptual row and the setting of the status to `active'. In the absence of such information in the DESCRIPTION clause, it is suggested that this period be approximately 5 minutes in length. This removal action applies not only to newly-created rows, but also to previously active rows which are set to, and left in, the notInService state for a prolonged period exceeding that which is considered normal for such a conceptual row.
Conceptual Row Suspension
When a conceptual row is `active', the management station may issue a management protocol set operation which sets the instance of the status column to `notInService'. If the agent is unwilling to do so, the set operation fails with an error of `wrongValue' or `inconsistentValue'. Otherwise, the conceptual row is taken out of service, and a `noError' response is returned. It is the responsibility of the DESCRIPTION clause of the status column to indicate under what circumstances the status column should be taken out of service (e.g., in order for the value of some other column of the same conceptual row to be modified).
Conceptual Row Deletion
For deletion of conceptual rows, a management protocol set operation is issued which sets the instance of the status column to `destroy'. This request may be made regardless of the current value of the status column (e.g., it is possible to delete conceptual rows which are either `notReady',
`notInService' or `active'.) If the operation succeeds,
then all instances associated with the conceptual row are immediately removed. · Integer32
When the entry is created, the ccasVariantFile object is mandatory. The entry can be added or deleted, but not modified by the manager.
This table defines the parameters related to the incoming line signals for CAS variant. The appropriate signal definitions from this table will be downloaded to the media gateway. The media gateway will use the information provided in this table to match the incoming bit pattern to a particular signal.
An index that uniquely identifies an entry in the cMediaGwTable.
ccasILSSignalNameIndex
1.3.6.1.4.1.9.9.314.1.3.1.1.2
Unsigned32 (1..65535)
This object specifies the Signal Name index for the various CAS line signals. This object along with the cmgwIndex and ccasVariantIndex identify an unique entry in this table.
ccasILSSignalName
1.3.6.1.4.1.9.9.314.1.3.1.1.3
SnmpAdminStringAn octet string containing administrative information, preferably in human-readable form.
To facilitate internationalization, this information is represented using the ISO/IEC IS 10646-1 character set, encoded as an octet string using the UTF-8 transformation format described in [RFC2279].
Since additional code points are added by amendments to the 10646 standard from time to time, implementations must be prepared to encounter any code point from 0x00000000 to 0x7fffffff. Byte sequences that do not correspond to the valid UTF-8 encoding of a code point or are outside this range are prohibited.
The use of control codes should be avoided.
When it is necessary to represent a newline, the control code sequence CR LF should be used.
The use of leading or trailing white space should be avoided.
For code points not directly supported by user interface hardware or software, an alternative means of entry and display, such as hexadecimal, may be provided.
For information encoded in 7-bit US-ASCII, the UTF-8 encoding is identical to the US-ASCII encoding.
UTF-8 may require multiple bytes to represent a single character / code point; thus the length of this object in octets may be different from the number of characters encoded. Similarly, size constraints refer to the number of encoded octets, not the number of characters represented by an encoding.
Note that when this TC is used for an object that is used or envisioned to be used as an index, then a SIZE restriction MUST be specified so that the number of sub-identifiers for any object instance does not exceed the limit of 128, as defined by [RFC3416].
Note that the size of an SnmpAdminString object is measured in octets, not characters. SIZE (1..64) · OCTET STRING · hint 255t
This object indicates CAS signal name corresponding to the ccasILSSignalNameIndex. The media gateway uses ccasILSRxPattern along with following objects: ccasILSMatchedRxPattern ccasILSMatchedTxPattern ccasILSMinMakeTime ccasILSMaxMakeTime ccasILSMinBreakTime ccasILSMaxBreakTime to determine a ccasILSSignalName.
ccasILSRxPattern
1.3.6.1.4.1.9.9.314.1.3.1.1.4
CASLineSignalThis textual convention defines line signals indicating the ABCD bits of CAS signaling, which represent the states of lines. Each of A, B, C or D represents by two bit value :
b(bit)1 | b0 | value
------------------------
0 | 0 | 0
0 | 1 | 1
1 | 0 | 2 ( don't care )
1 | 1 | 3 ( don't care )
The ABCD line signals are occupied in one byte, and in order:
. A : bit 7, and 6
. B : bit 5, and 4
. C : bit 3, and 2
. D : bit 1, and 0
A | B | C | D
----------------------------------------- | b1 | b0 | b1 | b0 | b1 | b0 | b1 | b0 | -----------------------------------------
MSB 7 LSB 0 SIZE (1) · OCTET STRING
This object indicates the ABCD bit pattern of the signal being received on the DS0.
ccasILSMatchedRxPattern
1.3.6.1.4.1.9.9.314.1.3.1.1.5
CASLineSignalThis textual convention defines line signals indicating the ABCD bits of CAS signaling, which represent the states of lines. Each of A, B, C or D represents by two bit value :
b(bit)1 | b0 | value
------------------------
0 | 0 | 0
0 | 1 | 1
1 | 0 | 2 ( don't care )
1 | 1 | 3 ( don't care )
The ABCD line signals are occupied in one byte, and in order:
. A : bit 7, and 6
. B : bit 5, and 4
. C : bit 3, and 2
. D : bit 1, and 0
A | B | C | D
----------------------------------------- | b1 | b0 | b1 | b0 | b1 | b0 | b1 | b0 | -----------------------------------------
MSB 7 LSB 0 SIZE (1) · OCTET STRING
This object indicates the previous matched ABCD bit pattern that was received on the DS0.
ccasILSMatchedTxPattern
1.3.6.1.4.1.9.9.314.1.3.1.1.6
CASLineSignalThis textual convention defines line signals indicating the ABCD bits of CAS signaling, which represent the states of lines. Each of A, B, C or D represents by two bit value :
b(bit)1 | b0 | value
------------------------
0 | 0 | 0
0 | 1 | 1
1 | 0 | 2 ( don't care )
1 | 1 | 3 ( don't care )
The ABCD line signals are occupied in one byte, and in order:
. A : bit 7, and 6
. B : bit 5, and 4
. C : bit 3, and 2
. D : bit 1, and 0
A | B | C | D
----------------------------------------- | b1 | b0 | b1 | b0 | b1 | b0 | b1 | b0 | -----------------------------------------
MSB 7 LSB 0 SIZE (1) · OCTET STRING
This object indicates the current ABCD bit pattern being transmitted on the DS0.
ccasILSMinMakeTime
1.3.6.1.4.1.9.9.314.1.3.1.1.7
Unsigned32 (2..4294967295) · milliseconds
This object specifies the minimum time for which the received pattern (ccasILSRxPattern) must persist to be considered a valid state change or transition. If the state change lasts for less than this time, it does not match the signal name.
ccasILSMaxMakeTime
1.3.6.1.4.1.9.9.314.1.3.1.1.8
Unsigned32 · milliseconds
This object specifies the maximum time for which the Rx pattern (ccasILSRxPattern) must persist to be considered a valid state change or transition. The value of 0 indicates there is no maximum make time for this signal. The value of ccasILSMaxMakeTime must be greater and equal ccasILSMinMakeTime. If the value is non-zero and the state change lasts for more than the maximum value specified, it does not match the signal name.
ccasILSMinBreakTime
1.3.6.1.4.1.9.9.314.1.3.1.1.9
Unsigned32 · milliseconds
This object specifies the minimum time for which the ABCD bit pattern being received on the line, and should go back to its original signal pattern after the make pattern has been asserted. The value of 0 indicates there is no minimum break time for this signal. If the value is non-zero and the state change lasts for less than the minimum break time specified, it does not match the signal name.
ccasILSMaxBreakTime
1.3.6.1.4.1.9.9.314.1.3.1.1.10
Unsigned32 · milliseconds
This object specifies the maximum time for which the ABCD bit pattern being received on the line, and go back to its original signal pattern after the make pattern has been asserted. The value of 0 indicates there is no maximum break time for this signal. The value of ccasILSMaxBreakTime must be greater than and equal ccasILSMinMakeTime. If the value is non-zero and the state change lasts longer than the maximum break time specified, it does not match the signal name.
An index that uniquely identifies an entry in the cMediaGwTable.
ccasOLSSignalNameIndex
1.3.6.1.4.1.9.9.314.1.3.2.1.1
Unsigned32 (1..65535)
This object specifies the Signal Name index for the various CAS Line signals. This object along with the ccasVariantIndex identify a unique entry in this table.
ccasOLSCasSignalName
1.3.6.1.4.1.9.9.314.1.3.2.1.2
SnmpAdminStringAn octet string containing administrative information, preferably in human-readable form.
To facilitate internationalization, this information is represented using the ISO/IEC IS 10646-1 character set, encoded as an octet string using the UTF-8 transformation format described in [RFC2279].
Since additional code points are added by amendments to the 10646 standard from time to time, implementations must be prepared to encounter any code point from 0x00000000 to 0x7fffffff. Byte sequences that do not correspond to the valid UTF-8 encoding of a code point or are outside this range are prohibited.
The use of control codes should be avoided.
When it is necessary to represent a newline, the control code sequence CR LF should be used.
The use of leading or trailing white space should be avoided.
For code points not directly supported by user interface hardware or software, an alternative means of entry and display, such as hexadecimal, may be provided.
For information encoded in 7-bit US-ASCII, the UTF-8 encoding is identical to the US-ASCII encoding.
UTF-8 may require multiple bytes to represent a single character / code point; thus the length of this object in octets may be different from the number of characters encoded. Similarly, size constraints refer to the number of encoded octets, not the number of characters represented by an encoding.
Note that when this TC is used for an object that is used or envisioned to be used as an index, then a SIZE restriction MUST be specified so that the number of sub-identifiers for any object instance does not exceed the limit of 128, as defined by [RFC3416].
Note that the size of an SnmpAdminString object is measured in octets, not characters. SIZE (1..64) · OCTET STRING · hint 255t
This object indicates outgoing CAS signal name.
ccasOLSTxPattern
1.3.6.1.4.1.9.9.314.1.3.2.1.3
CASLineSignalThis textual convention defines line signals indicating the ABCD bits of CAS signaling, which represent the states of lines. Each of A, B, C or D represents by two bit value :
b(bit)1 | b0 | value
------------------------
0 | 0 | 0
0 | 1 | 1
1 | 0 | 2 ( don't care )
1 | 1 | 3 ( don't care )
The ABCD line signals are occupied in one byte, and in order:
. A : bit 7, and 6
. B : bit 5, and 4
. C : bit 3, and 2
. D : bit 1, and 0
A | B | C | D
----------------------------------------- | b1 | b0 | b1 | b0 | b1 | b0 | b1 | b0 | -----------------------------------------
MSB 7 LSB 0 SIZE (1) · OCTET STRING
This object indicates the ABCD transmit bit pattern.
ccasOLSMakeTime
1.3.6.1.4.1.9.9.314.1.3.2.1.4
Unsigned32 · milliseconds
This object specifies the time value for which the Tx Pattern being transmitted.
ccasOLSBreakTime
1.3.6.1.4.1.9.9.314.1.3.2.1.5
Unsigned32 · milliseconds
This object specifies the time value for which the pattern being transmitted will switch to the original pattern before the Tx pattern was asserted on the line. The value of 0 indicates there is no break time for this signal.
ccasIfExtLineSignalTimerTable
1.3.6.1.4.1.9.9.314.1.3.3
Index: cmgwIndex · ccasLSTIndex
This table defines all timers related to the CAS Line signals.
An index that uniquely identifies an entry in the cMediaGwTable.
ccasLSTIndex
1.3.6.1.4.1.9.9.314.1.3.3.1.1
Unsigned32 (1..65535)
An arbitrary index that uniquely identifies a entry in the ccasIfExtLineSignalTimerTable. The index 1 is reserved for the default entry.
ccasLSTIdleGuardTimer
1.3.6.1.4.1.9.9.314.1.3.3.1.2
Unsigned32 · milliseconds
This object specifies the maximum amount of time MG will wait for receipt of the idle signal on the line. For T1 interfaces idle signal corresponds to on-hook pattern on line. For E1 interfaces idle signal corresponds to idle pattern on line. The value of 0 indicates the timer will not be started and MG would wait forever. Reference: Bellcore Publication: TR-NPL-000258 - Compatibility Information for Feature Group D Switched Access Service
ccasLSTClearFwdTimer
1.3.6.1.4.1.9.9.314.1.3.3.1.3
Unsigned32 · milliseconds
This object specifies the value of the timer that the GW will start at the request of the controlling application such as MGC for receipt of the clear forward signal on the line. This object is applied to R2 CAS. Reference: ITU-T Recommandation Q.118 Abnormal conditions, section 3.
ccasLSTClearBwdTimer
1.3.6.1.4.1.9.9.314.1.3.3.1.4
Unsigned32 · milliseconds
This object specifies the value of the timer that the GW will start at the request of the controlling application such as MGC for receipt of the clear backward signal. This object is applied to R2 CAS. Reference: ITU-T Recommandation Q.118 Abnormal conditions, section 3.
ccasLSTReleaseGuardTimer
1.3.6.1.4.1.9.9.314.1.3.3.1.5
Unsigned32 · millliseconds
This object specifies the delay between reception of the clear forward signal and the sending of the idle signal. Upon reception of the clear forward signal, GW starts the release guard timer. Upon expiry of this timer, the idle signal is generated. This timer is required to prevent seizing of the channel immediately. This object is applied to R2 CAS. Reference: Bellcore Publication: TR-NPL-000258 Compatibility Information for Feature Group D Switched Access Service.
ccasLSTCASGlareTimer
1.3.6.1.4.1.9.9.314.1.3.3.1.6
Unsigned32 · milliseconds
This object specifies the maximum amount of time MG will wait for other end to back out when glare occurs on a DS0 line. Change in incoming off-hook signal to on-hook signal with-in this time frame indicates that other end has backed down. Reference: H248.25 basic cas package and MS packages
ccasLSTAnswerMeterDelayTimer
1.3.6.1.4.1.9.9.314.1.3.3.1.7
Unsigned32 · milliseconds
The object specifies the delay between generation of the answer signal and the generation of the meter signal. The GW will start this timer after having sent the line answer signal.
ccasLSTCASDebounceTimer
1.3.6.1.4.1.9.9.314.1.3.3.1.8
Unsigned32 (1..4294967295) · milliseconds
This object specifies the amount of time for which the line signal should persist to be valid. The value of ccasLSTCASDebounceTimer must be less than or equal the value of following objects: ccasILSMinMakeTime, ccasILSMaxMakeTime, ccasILSMinBreakTime, ccasILSMaxBreakTime in ccasIfExtIncomingLineSignalTable.
ccasLSTSeizeAckRspTimer
1.3.6.1.4.1.9.9.314.1.3.3.1.9
Unsigned32 · milliseconds
This object specifies the maximum amount of time MG will wait for reception of seize ack signal. Seize Ack signal is expected in response of seize signal. This object is applied for both R2 CAS and non R2 CAS. Reference: TIA-689-A: PBX and KTS Support of Enhanced 911 Emergency Calling Service, section 5.2.3.3
ccasLSTDelayBetRegAnsAndLineAns
1.3.6.1.4.1.9.9.314.1.3.3.1.10
Unsigned32 (0..65535) · seconds
This object specifies the timer that will be started after register signaling completes successfully, within which the answer line signal should be received. This applies to outgoing R2 registers. The value of 0 indicates the timer will not be started and MG would wait forever. Reference: ITU-T Q.118 Abnormal Conditions Special Release Arrangements, section 1.
ccasLSTSeizeAckToDigitTimer
1.3.6.1.4.1.9.9.314.1.3.3.1.11
Unsigned32 (0..65535) · seconds
This object specifies the amount of time that the GW should wait for the reception address digits after sending seize ack signal. The value of 0 indicates the timer will not be started and MG would wait forever. Reference: ITU-T Q.476 Abnormal Release of Outgoing and Incoming R2 Register, section 5.5.2.1
ccasLSTRowStatus
1.3.6.1.4.1.9.9.314.1.3.3.1.12
RowStatus1 = active2 = notInService3 = notReady4 = createAndGo5 = createAndWait6 = destroyThe RowStatus textual convention is used to manage the creation and deletion of conceptual rows, and is used as the value of the SYNTAX clause for the status column of a conceptual row (as described in Section 7.7.1 of [2].)
The status column has six defined values:
- `active', which indicates that the conceptual row is available for use by the managed device;
- `notInService', which indicates that the conceptual row exists in the agent, but is unavailable for use by the managed device (see NOTE below); 'notInService' has no implication regarding the internal consistency of the row, availability of resources, or consistency with the current state of the managed device;
- `notReady', which indicates that the conceptual row exists in the agent, but is missing information necessary in order to be available for use by the managed device (i.e., one or more required columns in the conceptual row have not been instanciated);
- `createAndGo', which is supplied by a management station wishing to create a new instance of a conceptual row and to have its status automatically set to active, making it available for use by the managed device;
- `createAndWait', which is supplied by a management station wishing to create a new instance of a conceptual row (but not make it available for use by the managed device); and, - `destroy', which is supplied by a management station wishing to delete all of the instances associated with an existing conceptual row.
Whereas five of the six values (all except `notReady') may be specified in a management protocol set operation, only three values will be returned in response to a management
protocol retrieval operation: `notReady', `notInService' or
`active'. That is, when queried, an existing conceptual row
has only three states: it is either available for use by
the managed device (the status column has value `active'); it is not available for use by the managed device, though the agent has sufficient information to attempt to make it so (the status column has value `notInService'); or, it is not available for use by the managed device, and an attempt to make it so would fail because the agent has insufficient information (the state column has value `notReady').
NOTE WELL
This textual convention may be used for a MIB table, irrespective of whether the values of that table's conceptual rows are able to be modified while it is active, or whether its conceptual rows must be taken out of service in order to be modified. That is, it is the responsibility of the DESCRIPTION clause of the status column to specify whether the status column must not be `active' in order for the value of some other column of the same conceptual row to be modified. If such a specification is made, affected columns may be changed by an SNMP set PDU if the RowStatus would not be equal to `active' either immediately before or after processing the PDU. In other words, if the PDU also contained a varbind that would change the RowStatus value, the column in question may be changed if the RowStatus was not equal to `active' as the PDU was received, or if the varbind sets the status to a value other than 'active'.
Also note that whenever any elements of a row exist, the RowStatus column must also exist.
To summarize the effect of having a conceptual row with a status column having a SYNTAX clause value of RowStatus, consider the following state diagram:
STATE +--------------+-----------+-------------+-------------
| A | B | C | D
| |status col.|status column|
|status column | is | is |status column
ACTION |does not exist| notReady | notInService| is active
--------------+--------------+-----------+-------------+-------------
set status |noError ->D|inconsist- |inconsistent-|inconsistent-
column to | or | entValue| Value| Value
createAndGo |inconsistent- | | |
| Value| | |
--------------+--------------+-----------+-------------+-------------
set status |noError see 1|inconsist- |inconsistent-|inconsistent-
column to | or | entValue| Value| Value
createAndWait |wrongValue | | |
--------------+--------------+-----------+-------------+-------------
set status |inconsistent- |inconsist- |noError |noError
column to | Value| entValue| |
active | | | |
| | or | |
| | | |
| |see 2 ->D|see 8 ->D| ->D
--------------+--------------+-----------+-------------+-------------
set status |inconsistent- |inconsist- |noError |noError ->C
column to | Value| entValue| |
notInService | | | |
| | or | | or
| | | |
| |see 3 ->C| ->C|see 6
--------------+--------------+-----------+-------------+-------------
set status |noError |noError |noError |noError ->A
column to | | | | or
destroy | ->A| ->A| ->A|see 7
--------------+--------------+-----------+-------------+-------------
set any other |see 4 |noError |noError |see 5
column to some| | | |
value | | see 1| ->C| ->D
--------------+--------------+-----------+-------------+-------------
(1) goto B or C, depending on information available to the agent.
(2) if other variable bindings included in the same PDU, provide values for all columns which are missing but required, and all columns have acceptable values, then return noError and goto D.
(3) if other variable bindings included in the same PDU, provide legal values for all columns which are missing but required, then return noError and goto C.
(4) at the discretion of the agent, the return value may be either:
inconsistentName: because the agent does not choose to
create such an instance when the corresponding RowStatus instance does not exist, or
inconsistentValue: if the supplied value is
inconsistent with the state of some other MIB object's value, or
noError: because the agent chooses to create the instance.
If noError is returned, then the instance of the status column must also be created, and the new state is B or C, depending on the information available to the agent. If inconsistentName or inconsistentValue is returned, the row remains in state A.
(5) depending on the MIB definition for the column/table, either noError or inconsistentValue may be returned.
(6) the return value can indicate one of the following errors:
wrongValue: because the agent does not support notInService (e.g., an agent which does not support createAndWait), or
inconsistentValue: because the agent is unable to take the row out of service at this time, perhaps because it is in use and cannot be de-activated.
(7) the return value can indicate the following error:
inconsistentValue: because the agent is unable to remove the row at this time, perhaps because it is in use and cannot be de-activated.
(8) the transition to D can fail, e.g., if the values of the conceptual row are inconsistent, then the error code would be inconsistentValue.
NOTE: Other processing of (this and other varbinds of) the set request may result in a response other than noError being returned, e.g., wrongValue, noCreation, etc.
Conceptual Row Creation
There are four potential interactions when creating a
conceptual row: selecting an instance-identifier which is
not in use; creating the conceptual row; initializing any objects for which the agent does not supply a default; and, making the conceptual row available for use by the managed device.
Interaction 1: Selecting an Instance-Identifier
The algorithm used to select an instance-identifier varies for each conceptual row. In some cases, the instance- identifier is semantically significant, e.g., the destination address of a route, and a management station selects the instance-identifier according to the semantics.
In other cases, the instance-identifier is used solely to distinguish conceptual rows, and a management station without specific knowledge of the conceptual row might examine the instances present in order to determine an unused instance-identifier. (This approach may be used, but it is often highly sub-optimal; however, it is also a questionable practice for a naive management station to attempt conceptual row creation.)
Alternately, the MIB module which defines the conceptual row might provide one or more objects which provide assistance in determining an unused instance-identifier. For example, if the conceptual row is indexed by an integer-value, then an object having an integer-valued SYNTAX clause might be defined for such a purpose, allowing a management station to issue a management protocol retrieval operation. In order to avoid unnecessary collisions between competing management stations, `adjacent' retrievals of this object should be different.
Finally, the management station could select a pseudo-random number to use as the index. In the event that this index
was already in use and an inconsistentValue was returned in response to the management protocol set operation, the management station should simply select a new pseudo-random number and retry the operation.
A MIB designer should choose between the two latter algorithms based on the size of the table (and therefore the efficiency of each algorithm). For tables in which a large number of entries are expected, it is recommended that a MIB object be defined that returns an acceptable index for creation. For tables with small numbers of entries, it is recommended that the latter pseudo-random index mechanism be used.
Interaction 2: Creating the Conceptual Row
Once an unused instance-identifier has been selected, the management station determines if it wishes to create and activate the conceptual row in one transaction or in a negotiated set of interactions.
Interaction 2a: Creating and Activating the Conceptual Row
The management station must first determine the column requirements, i.e., it must determine those columns for which it must or must not provide values. Depending on the complexity of the table and the management station's knowledge of the agent's capabilities, this determination can be made locally by the management station. Alternately, the management station issues a management protocol get operation to examine all columns in the conceptual row that it wishes to create. In response, for each column, there are three possible outcomes:
- a value is returned, indicating that some other management station has already created this conceptual row. We return to interaction 1.
- the exception `noSuchInstance' is returned, indicating that the agent implements the object-type associated with this column, and that this column in at least one conceptual row would be accessible in the MIB view used by the retrieval were it to exist. For those columns to which the agent provides read-create access, the `noSuchInstance' exception tells the management station that it should supply a value for this column when the conceptual row is to be created.
- the exception `noSuchObject' is returned, indicating that the agent does not implement the object-type associated with this column or that there is no conceptual row for which this column would be accessible in the MIB view used by the retrieval. As such, the management station can not issue any management protocol set operations to create an instance of this column.
Once the column requirements have been determined, a management protocol set operation is accordingly issued. This operation also sets the new instance of the status column to `createAndGo'.
When the agent processes the set operation, it verifies that it has sufficient information to make the conceptual row available for use by the managed device. The information
available to the agent is provided by two sources: the
management protocol set operation which creates the conceptual row, and, implementation-specific defaults supplied by the agent (note that an agent must provide implementation-specific defaults for at least those objects which it implements as read-only). If there is sufficient information available, then the conceptual row is created, a `noError' response is returned, the status column is set to `active', and no further interactions are necessary (i.e., interactions 3 and 4 are skipped). If there is insufficient information, then the conceptual row is not created, and the set operation fails with an error of `inconsistentValue'. On this error, the management station can issue a management protocol retrieval operation to determine if this was because it failed to specify a value for a required column, or, because the selected instance of the status column already existed. In the latter case, we return to interaction 1. In the former case, the management station can re-issue the set operation with the additional information, or begin interaction 2 again using `createAndWait' in order to negotiate creation of the conceptual row.
NOTE WELL
Regardless of the method used to determine the column requirements, it is possible that the management station might deem a column necessary when, in fact, the agent will not allow that particular columnar instance to be created or written. In this case, the management protocol set operation will fail with an error such as `noCreation' or `notWritable'. In this case, the management station decides whether it needs to be able to set a value for that particular columnar instance. If not, the management station re-issues the management protocol set operation, but without setting a value for that particular columnar instance; otherwise, the management station aborts the row creation algorithm.
Interaction 2b: Negotiating the Creation of the Conceptual Row
The management station issues a management protocol set operation which sets the desired instance of the status column to `createAndWait'. If the agent is unwilling to process a request of this sort, the set operation fails with an error of `wrongValue'. (As a consequence, such an agent must be prepared to accept a single management protocol set operation, i.e., interaction 2a above, containing all of the
columns indicated by its column requirements.) Otherwise,
the conceptual row is created, a `noError' response is returned, and the status column is immediately set to either `notInService' or `notReady', depending on whether it has sufficient information to (attempt to) make the conceptual row available for use by the managed device. If there is sufficient information available, then the status column is set to `notInService'; otherwise, if there is insufficient information, then the status column is set to `notReady'. Regardless, we proceed to interaction 3.
Interaction 3: Initializing non-defaulted Objects
The management station must now determine the column requirements. It issues a management protocol get operation to examine all columns in the created conceptual row. In the response, for each column, there are three possible outcomes:
- a value is returned, indicating that the agent implements the object-type associated with this column and had sufficient information to provide a value. For those columns to which the agent provides read-create access (and for which the agent allows their values to be changed after their creation), a value return tells the management station that it may issue additional management protocol set operations, if it desires, in order to change the value associated with this column.
- the exception `noSuchInstance' is returned, indicating that the agent implements the object-type associated with this column, and that this column in at least one conceptual row would be accessible in the MIB view used by the retrieval were it to exist. However, the agent does not have sufficient information to provide a value, and until a value is provided, the conceptual row may not be made available for use by the managed device. For those columns to which the agent provides read-create access, the `noSuchInstance' exception tells the management station that it must issue additional management protocol set operations, in order to provide a value associated with this column.
- the exception `noSuchObject' is returned, indicating that the agent does not implement the object-type associated with this column or that there is no conceptual row for which this column would be accessible in the MIB view used by the retrieval. As such, the management station can not issue any management protocol set operations to create an instance of this column.
If the value associated with the status column is `notReady', then the management station must first deal with all `noSuchInstance' columns, if any. Having done so, the value of the status column becomes `notInService', and we proceed to interaction 4.
Interaction 4: Making the Conceptual Row Available
Once the management station is satisfied with the values associated with the columns of the conceptual row, it issues a management protocol set operation to set the status column to `active'. If the agent has sufficient information to make the conceptual row available for use by the managed device, the management protocol set operation succeeds (a `noError' response is returned). Otherwise, the management protocol set operation fails with an error of `inconsistentValue'.
NOTE WELL
A conceptual row having a status column with value `notInService' or `notReady' is unavailable to the managed device. As such, it is possible for the managed device to create its own instances during the time between the management protocol set operation which sets the status column to `createAndWait' and the management protocol set operation which sets the status column to `active'. In this case, when the management protocol set operation is issued to set the status column to `active', the values held in the agent supersede those used by the managed device.
If the management station is prevented from setting the status column to `active' (e.g., due to management station or network failure) the conceptual row will be left in the `notInService' or `notReady' state, consuming resources indefinitely. The agent must detect conceptual rows that have been in either state for an abnormally long period of time and remove them. It is the responsibility of the DESCRIPTION clause of the status column to indicate what an abnormally long period of time would be. This period of time should be long enough to allow for human response time (including `think time') between the creation of the conceptual row and the setting of the status to `active'. In the absence of such information in the DESCRIPTION clause, it is suggested that this period be approximately 5 minutes in length. This removal action applies not only to newly-created rows, but also to previously active rows which are set to, and left in, the notInService state for a prolonged period exceeding that which is considered normal for such a conceptual row.
Conceptual Row Suspension
When a conceptual row is `active', the management station may issue a management protocol set operation which sets the instance of the status column to `notInService'. If the agent is unwilling to do so, the set operation fails with an error of `wrongValue' or `inconsistentValue'. Otherwise, the conceptual row is taken out of service, and a `noError' response is returned. It is the responsibility of the DESCRIPTION clause of the status column to indicate under what circumstances the status column should be taken out of service (e.g., in order for the value of some other column of the same conceptual row to be modified).
Conceptual Row Deletion
For deletion of conceptual rows, a management protocol set operation is issued which sets the instance of the status column to `destroy'. This request may be made regardless of the current value of the status column (e.g., it is possible to delete conceptual rows which are either `notReady',
`notInService' or `active'.) If the operation succeeds,
then all instances associated with the conceptual row are immediately removed. · Integer32
This object is used for adding, deleting, and modifying the entries from the ccasIfExtLineSignalTimerTable. A default entry with index value 1 is created at initialization, and it cannot be modified or deleted.
ccasIfExtRegisterSignalTable
1.3.6.1.4.1.9.9.314.1.4.1
Index: cmgwIndex · ccasRSIndex
This table defines the signal to action definitions for the Register signals for R2 variant.
This object specifies the country where the meaning for the signal definition/action applies. This parameter is mandatory when creating an entry. When the R2 country (ITU or other) is specified, the default values for the rest of the MIB objects are populated based on this.
ccasRSSubRegion
1.3.6.1.4.1.9.9.314.1.4.1.1.3
SnmpAdminStringAn octet string containing administrative information, preferably in human-readable form.
To facilitate internationalization, this information is represented using the ISO/IEC IS 10646-1 character set, encoded as an octet string using the UTF-8 transformation format described in [RFC2279].
Since additional code points are added by amendments to the 10646 standard from time to time, implementations must be prepared to encounter any code point from 0x00000000 to 0x7fffffff. Byte sequences that do not correspond to the valid UTF-8 encoding of a code point or are outside this range are prohibited.
The use of control codes should be avoided.
When it is necessary to represent a newline, the control code sequence CR LF should be used.
The use of leading or trailing white space should be avoided.
For code points not directly supported by user interface hardware or software, an alternative means of entry and display, such as hexadecimal, may be provided.
For information encoded in 7-bit US-ASCII, the UTF-8 encoding is identical to the US-ASCII encoding.
UTF-8 may require multiple bytes to represent a single character / code point; thus the length of this object in octets may be different from the number of characters encoded. Similarly, size constraints refer to the number of encoded octets, not the number of characters represented by an encoding.
Note that when this TC is used for an object that is used or envisioned to be used as an index, then a SIZE restriction MUST be specified so that the number of sub-identifiers for any object instance does not exceed the limit of 128, as defined by [RFC3416].
Note that the size of an SnmpAdminString object is measured in octets, not characters. SIZE (0..64) · OCTET STRING · hint 255t
This object is used to describe a variation within a particular country.
ccasBwdRSNextDigitANI
1.3.6.1.4.1.9.9.314.1.4.1.1.4
CASBackwardSignal1 = notApplicable2 = a13 = a24 = a35 = a46 = a57 = a68 = a79 = a810 = a911 = a1012 = a1113 = a1214 = a1315 = a1416 = a1517 = b118 = b219 = b320 = b421 = b522 = b623 = b724 = b825 = b926 = b1027 = b1128 = b1229 = b1330 = b1431 = b1532 = c133 = c234 = c335 = c436 = c537 = c638 = c739 = c840 = c941 = c1042 = c1143 = c1244 = c1345 = c1446 = c15This textual convention defines all possible Group A, B and C Backward Signal in Signaling System R2. The group-A tones are generally used to query the call setup related information from the outgoing register. The group B signals convey information about the subscriber's line and equipment status. Some countries use the Group-C tones to differentiate between ANI and DNIS related operations with the help to Group-III related tones.Reference: ITU-T recommendation Q.441 · Integer32
This object specifies a backward signal requesting transmission of the next ANI digit (n + 1) after reception of digit n. The default value is country specific. Reference: ITU-T Q440 - Specifications of signaling system R2 Interregister Signaling. Section 4.2.4.1 Backward signals.
ccasBwdRSNextDigitDNIS
1.3.6.1.4.1.9.9.314.1.4.1.1.5
CASBackwardSignal1 = notApplicable2 = a13 = a24 = a35 = a46 = a57 = a68 = a79 = a810 = a911 = a1012 = a1113 = a1214 = a1315 = a1416 = a1517 = b118 = b219 = b320 = b421 = b522 = b623 = b724 = b825 = b926 = b1027 = b1128 = b1229 = b1330 = b1431 = b1532 = c133 = c234 = c335 = c436 = c537 = c638 = c739 = c840 = c941 = c1042 = c1143 = c1244 = c1345 = c1446 = c15This textual convention defines all possible Group A, B and C Backward Signal in Signaling System R2. The group-A tones are generally used to query the call setup related information from the outgoing register. The group B signals convey information about the subscriber's line and equipment status. Some countries use the Group-C tones to differentiate between ANI and DNIS related operations with the help to Group-III related tones.Reference: ITU-T recommendation Q.441 · Integer32
This object specifies a backward signal requesting transmission of the next DNIS digit (n + 1) after reception of digit n. The default value is country specific. Reference: ITU-T Q440 - Specifications of signaling system R2 Interregister Signaling. Section 4.2.4.1 Backward signals.
ccasBwdRSPrevDigit
1.3.6.1.4.1.9.9.314.1.4.1.1.6
CASBackwardSignal1 = notApplicable2 = a13 = a24 = a35 = a46 = a57 = a68 = a79 = a810 = a911 = a1012 = a1113 = a1214 = a1315 = a1416 = a1517 = b118 = b219 = b320 = b421 = b522 = b623 = b724 = b825 = b926 = b1027 = b1128 = b1229 = b1330 = b1431 = b1532 = c133 = c234 = c335 = c436 = c537 = c638 = c739 = c840 = c941 = c1042 = c1143 = c1244 = c1345 = c1446 = c15This textual convention defines all possible Group A, B and C Backward Signal in Signaling System R2. The group-A tones are generally used to query the call setup related information from the outgoing register. The group B signals convey information about the subscriber's line and equipment status. Some countries use the Group-C tones to differentiate between ANI and DNIS related operations with the help to Group-III related tones.Reference: ITU-T recommendation Q.441 · Integer32
This object specifies a backward signal requesting transmission of the previous ANI or DNIS digit (n - 1) after reception of digit n. The default value is country specific. Reference: ITU-T Q440 - Specifications of signaling system R2 Interregister Signaling. Section 4.2.4.1 Backward signals.
ccasBwdRSXtoGroupBSignals
1.3.6.1.4.1.9.9.314.1.4.1.1.7
CASBackwardSignal1 = notApplicable2 = a13 = a24 = a35 = a46 = a57 = a68 = a79 = a810 = a911 = a1012 = a1113 = a1214 = a1315 = a1416 = a1517 = b118 = b219 = b320 = b421 = b522 = b623 = b724 = b825 = b926 = b1027 = b1128 = b1229 = b1330 = b1431 = b1532 = c133 = c234 = c335 = c436 = c537 = c638 = c739 = c840 = c941 = c1042 = c1143 = c1244 = c1345 = c1446 = c15This textual convention defines all possible Group A, B and C Backward Signal in Signaling System R2. The group-A tones are generally used to query the call setup related information from the outgoing register. The group B signals convey information about the subscriber's line and equipment status. Some countries use the Group-C tones to differentiate between ANI and DNIS related operations with the help to Group-III related tones.Reference: ITU-T recommendation Q.441 · Integer32
This object specifies a backward signal indicating that the incoming R2 register at the incoming end needs no additional address digit and is about to go over to transmission of a Group B signal conveying information about the condition of the equipment at the incoming exchange or the condition of the called subscribers line. The default value is country specific. Reference: ITU-T Q440 - Specifications of signaling system R2 Interregister Signaling. Section 4.2.4.1 Backward signals.
ccasBwdRSCongestion
1.3.6.1.4.1.9.9.314.1.4.1.1.8
CASBackwardSignal1 = notApplicable2 = a13 = a24 = a35 = a46 = a57 = a68 = a79 = a810 = a911 = a1012 = a1113 = a1214 = a1315 = a1416 = a1517 = b118 = b219 = b320 = b421 = b522 = b623 = b724 = b825 = b926 = b1027 = b1128 = b1229 = b1330 = b1431 = b1532 = c133 = c234 = c335 = c436 = c537 = c638 = c739 = c840 = c941 = c1042 = c1143 = c1244 = c1345 = c1446 = c15This textual convention defines all possible Group A, B and C Backward Signal in Signaling System R2. The group-A tones are generally used to query the call setup related information from the outgoing register. The group B signals convey information about the subscriber's line and equipment status. Some countries use the Group-C tones to differentiate between ANI and DNIS related operations with the help to Group-III related tones.Reference: ITU-T recommendation Q.441 · Integer32
This object specifies a backward signal indicating that: . Congestion of national links. . Congestion in selection stages of terminal international or national exchanges. . Occurrence of time-out or abnormal release of a System R2 register produced for any reason. The default value is country specific. Reference: ITU-T Q440 - Specifications of signaling system R2 Interregister Signaling. Section 4.2.4.1 Backward signals.
ccasBwdRSCallingPartyCategory
1.3.6.1.4.1.9.9.314.1.4.1.1.9
CASBackwardSignal1 = notApplicable2 = a13 = a24 = a35 = a46 = a57 = a68 = a79 = a810 = a911 = a1012 = a1113 = a1214 = a1315 = a1416 = a1517 = b118 = b219 = b320 = b421 = b522 = b623 = b724 = b825 = b926 = b1027 = b1128 = b1229 = b1330 = b1431 = b1532 = c133 = c234 = c335 = c436 = c537 = c638 = c739 = c840 = c941 = c1042 = c1143 = c1244 = c1345 = c1446 = c15This textual convention defines all possible Group A, B and C Backward Signal in Signaling System R2. The group-A tones are generally used to query the call setup related information from the outgoing register. The group B signals convey information about the subscriber's line and equipment status. Some countries use the Group-C tones to differentiate between ANI and DNIS related operations with the help to Group-III related tones.Reference: ITU-T recommendation Q.441 · Integer32
This object specifies a backward signal requesting for a calling party category information or a Group II signal. The default value is country specific. Reference: ITU-T Q440 - Specifications of signaling system R2 Interregister Signaling. Section 4.2.4.1 Backward signals.
ccasBwdRSAddrCompleteGroupA
1.3.6.1.4.1.9.9.314.1.4.1.1.10
CASBackwardSignal1 = notApplicable2 = a13 = a24 = a35 = a46 = a57 = a68 = a79 = a810 = a911 = a1012 = a1113 = a1214 = a1315 = a1416 = a1517 = b118 = b219 = b320 = b421 = b522 = b623 = b724 = b825 = b926 = b1027 = b1128 = b1229 = b1330 = b1431 = b1532 = c133 = c234 = c335 = c436 = c537 = c638 = c739 = c840 = c941 = c1042 = c1143 = c1244 = c1345 = c1446 = c15This textual convention defines all possible Group A, B and C Backward Signal in Signaling System R2. The group-A tones are generally used to query the call setup related information from the outgoing register. The group B signals convey information about the subscriber's line and equipment status. Some countries use the Group-C tones to differentiate between ANI and DNIS related operations with the help to Group-III related tones.Reference: ITU-T recommendation Q.441 · Integer32
This object specifies a backward signal indicating that the R2 register at the incoming end needs no additional digit, but will not send Group B signals. The call has to be charged on answer. The default value is country specific. Reference: ITU-T Q440 - Specifications of signaling system R2 Interregister Signaling. Section 4.2.4.1 Backward signals.
ccasBwdRSPrevNminus2Digit
1.3.6.1.4.1.9.9.314.1.4.1.1.11
CASBackwardSignal1 = notApplicable2 = a13 = a24 = a35 = a46 = a57 = a68 = a79 = a810 = a911 = a1012 = a1113 = a1214 = a1315 = a1416 = a1517 = b118 = b219 = b320 = b421 = b522 = b623 = b724 = b825 = b926 = b1027 = b1128 = b1229 = b1330 = b1431 = b1532 = c133 = c234 = c335 = c436 = c537 = c638 = c739 = c840 = c941 = c1042 = c1143 = c1244 = c1345 = c1446 = c15This textual convention defines all possible Group A, B and C Backward Signal in Signaling System R2. The group-A tones are generally used to query the call setup related information from the outgoing register. The group B signals convey information about the subscriber's line and equipment status. Some countries use the Group-C tones to differentiate between ANI and DNIS related operations with the help to Group-III related tones.Reference: ITU-T recommendation Q.441 · Integer32
This object specifies a backward signal requesting the sending of the ANI or DNIS digit (n - 2) after reception of digit n. The default value is country specific. Reference: ITU-T Q440 - Specifications of signaling system R2 Interregister Signaling. Section 4.2.4.1 Backward signals.
ccasBwdRSPrevNminus3Digit
1.3.6.1.4.1.9.9.314.1.4.1.1.12
CASBackwardSignal1 = notApplicable2 = a13 = a24 = a35 = a46 = a57 = a68 = a79 = a810 = a911 = a1012 = a1113 = a1214 = a1315 = a1416 = a1517 = b118 = b219 = b320 = b421 = b522 = b623 = b724 = b825 = b926 = b1027 = b1128 = b1229 = b1330 = b1431 = b1532 = c133 = c234 = c335 = c436 = c537 = c638 = c739 = c840 = c941 = c1042 = c1143 = c1244 = c1345 = c1446 = c15This textual convention defines all possible Group A, B and C Backward Signal in Signaling System R2. The group-A tones are generally used to query the call setup related information from the outgoing register. The group B signals convey information about the subscriber's line and equipment status. Some countries use the Group-C tones to differentiate between ANI and DNIS related operations with the help to Group-III related tones.Reference: ITU-T recommendation Q.441 · Integer32
This object specifies a backward signal requesting the
sending of the ANI or DNIS digit (n - 3) after reception
of digit n. The default value is country specific. Reference: ITU-T Q440 - Specifications of signaling system R2 Interregister Signaling. Section 4.2.4.1 Backward signals.
ccasBwdRSCountryCode
1.3.6.1.4.1.9.9.314.1.4.1.1.13
CASBackwardSignal1 = notApplicable2 = a13 = a24 = a35 = a46 = a57 = a68 = a79 = a810 = a911 = a1012 = a1113 = a1214 = a1315 = a1416 = a1517 = b118 = b219 = b320 = b421 = b522 = b623 = b724 = b825 = b926 = b1027 = b1128 = b1229 = b1330 = b1431 = b1532 = c133 = c234 = c335 = c436 = c537 = c638 = c739 = c840 = c941 = c1042 = c1143 = c1244 = c1345 = c1446 = c15This textual convention defines all possible Group A, B and C Backward Signal in Signaling System R2. The group-A tones are generally used to query the call setup related information from the outgoing register. The group B signals convey information about the subscriber's line and equipment status. Some countries use the Group-C tones to differentiate between ANI and DNIS related operations with the help to Group-III related tones.Reference: ITU-T recommendation Q.441 · Integer32
This object specifies a backward signal requesting the country code indicator. The default value is country specific. Reference: ITU-T Q440 - Specifications of signaling system R2 Interregister Signaling. Section 4.2.4.1 Backward signals.
ccasBwdRSLangDiscr
1.3.6.1.4.1.9.9.314.1.4.1.1.14
CASBackwardSignal1 = notApplicable2 = a13 = a24 = a35 = a46 = a57 = a68 = a79 = a810 = a911 = a1012 = a1113 = a1214 = a1315 = a1416 = a1517 = b118 = b219 = b320 = b421 = b522 = b623 = b724 = b825 = b926 = b1027 = b1128 = b1229 = b1330 = b1431 = b1532 = c133 = c234 = c335 = c436 = c537 = c638 = c739 = c840 = c941 = c1042 = c1143 = c1244 = c1345 = c1446 = c15This textual convention defines all possible Group A, B and C Backward Signal in Signaling System R2. The group-A tones are generally used to query the call setup related information from the outgoing register. The group B signals convey information about the subscriber's line and equipment status. Some countries use the Group-C tones to differentiate between ANI and DNIS related operations with the help to Group-III related tones.Reference: ITU-T recommendation Q.441 · Integer32
This object specifies a backward signal requesting the language digit or the discriminating digit. . Operator assistance: requesting a language digit. . Automatic call: requesting a discriminating digit. The default value is country specific. Reference: ITU-T Q440 - Specifications of signaling system R2 Interregister Signaling. Section 4.2.4.1 Backward signals.
ccasBwdRSNatureOfCircuit
1.3.6.1.4.1.9.9.314.1.4.1.1.15
CASBackwardSignal1 = notApplicable2 = a13 = a24 = a35 = a46 = a57 = a68 = a79 = a810 = a911 = a1012 = a1113 = a1214 = a1315 = a1416 = a1517 = b118 = b219 = b320 = b421 = b522 = b623 = b724 = b825 = b926 = b1027 = b1128 = b1229 = b1330 = b1431 = b1532 = c133 = c234 = c335 = c436 = c537 = c638 = c739 = c840 = c941 = c1042 = c1143 = c1244 = c1345 = c1446 = c15This textual convention defines all possible Group A, B and C Backward Signal in Signaling System R2. The group-A tones are generally used to query the call setup related information from the outgoing register. The group B signals convey information about the subscriber's line and equipment status. Some countries use the Group-C tones to differentiate between ANI and DNIS related operations with the help to Group-III related tones.Reference: ITU-T recommendation Q.441 · Integer32
This object specifies a backward signal requesting information regarding the nature of the circuits involved in the connection so far, i.e. satellite link or not. The default value is country specific. Reference: ITU-T Q440 - Specifications of signaling system R2 Interregister Signaling. Section 4.2.4.1 Backward signals.
ccasBwdRSInfoEchoSuppressor
1.3.6.1.4.1.9.9.314.1.4.1.1.16
CASBackwardSignal1 = notApplicable2 = a13 = a24 = a35 = a46 = a57 = a68 = a79 = a810 = a911 = a1012 = a1113 = a1214 = a1315 = a1416 = a1517 = b118 = b219 = b320 = b421 = b522 = b623 = b724 = b825 = b926 = b1027 = b1128 = b1229 = b1330 = b1431 = b1532 = c133 = c234 = c335 = c436 = c537 = c638 = c739 = c840 = c941 = c1042 = c1143 = c1244 = c1345 = c1446 = c15This textual convention defines all possible Group A, B and C Backward Signal in Signaling System R2. The group-A tones are generally used to query the call setup related information from the outgoing register. The group B signals convey information about the subscriber's line and equipment status. Some countries use the Group-C tones to differentiate between ANI and DNIS related operations with the help to Group-III related tones.Reference: ITU-T recommendation Q.441 · Integer32
This object specifies a backward signal requesting information regarding the nature of echo suppressor being used in the connection. The default value is country specific. Reference: ITU-T Q440 - Specifications of signaling system R2 Interregister Signaling. Section 4.2.4.1 Backward signals.
ccasBwdRSInternationalCongst
1.3.6.1.4.1.9.9.314.1.4.1.1.17
CASBackwardSignal1 = notApplicable2 = a13 = a24 = a35 = a46 = a57 = a68 = a79 = a810 = a911 = a1012 = a1113 = a1214 = a1315 = a1416 = a1517 = b118 = b219 = b320 = b421 = b522 = b623 = b724 = b825 = b926 = b1027 = b1128 = b1229 = b1330 = b1431 = b1532 = c133 = c234 = c335 = c436 = c537 = c638 = c739 = c840 = c941 = c1042 = c1143 = c1244 = c1345 = c1446 = c15This textual convention defines all possible Group A, B and C Backward Signal in Signaling System R2. The group-A tones are generally used to query the call setup related information from the outgoing register. The group B signals convey information about the subscriber's line and equipment status. Some countries use the Group-C tones to differentiate between ANI and DNIS related operations with the help to Group-III related tones.Reference: ITU-T recommendation Q.441 · Integer32
This object specifies a backward signal indicating: . Congestion on international links. . Congestion in selection stages at an international transit exchange or at a terminal international exchange and/or its outgoing links. . Occurrence of time-out or abnormal release of a System R2 register produced for any reason. The default value is country specific. Reference: ITU-T Q440 - Specifications of signaling system R2 Interregister Signaling. Section 4.2.4.1 Backward signals.
ccasBwdRSXtoGroupC
1.3.6.1.4.1.9.9.314.1.4.1.1.18
CASBackwardSignal1 = notApplicable2 = a13 = a24 = a35 = a46 = a57 = a68 = a79 = a810 = a911 = a1012 = a1113 = a1214 = a1315 = a1416 = a1517 = b118 = b219 = b320 = b421 = b522 = b623 = b724 = b825 = b926 = b1027 = b1128 = b1229 = b1330 = b1431 = b1532 = c133 = c234 = c335 = c436 = c537 = c638 = c739 = c840 = c941 = c1042 = c1143 = c1244 = c1345 = c1446 = c15This textual convention defines all possible Group A, B and C Backward Signal in Signaling System R2. The group-A tones are generally used to query the call setup related information from the outgoing register. The group B signals convey information about the subscriber's line and equipment status. Some countries use the Group-C tones to differentiate between ANI and DNIS related operations with the help to Group-III related tones.Reference: ITU-T recommendation Q.441 · Integer32
This object specifies a backward signal requesting switch to reception of group C signals. The default value is country specific.
ccasBwdRSRepeatLastDigit
1.3.6.1.4.1.9.9.314.1.4.1.1.19
CASBackwardSignal1 = notApplicable2 = a13 = a24 = a35 = a46 = a57 = a68 = a79 = a810 = a911 = a1012 = a1113 = a1214 = a1315 = a1416 = a1517 = b118 = b219 = b320 = b421 = b522 = b623 = b724 = b825 = b926 = b1027 = b1128 = b1229 = b1330 = b1431 = b1532 = c133 = c234 = c335 = c436 = c537 = c638 = c739 = c840 = c941 = c1042 = c1143 = c1244 = c1345 = c1446 = c15This textual convention defines all possible Group A, B and C Backward Signal in Signaling System R2. The group-A tones are generally used to query the call setup related information from the outgoing register. The group B signals convey information about the subscriber's line and equipment status. Some countries use the Group-C tones to differentiate between ANI and DNIS related operations with the help to Group-III related tones.Reference: ITU-T recommendation Q.441 · Integer32
This object specifies a backward signal requesting resending of the last digit just sent out. The default value is country specific.
ccasBwdRSRepeatCalledDigit
1.3.6.1.4.1.9.9.314.1.4.1.1.20
CASBackwardSignal1 = notApplicable2 = a13 = a24 = a35 = a46 = a57 = a68 = a79 = a810 = a911 = a1012 = a1113 = a1214 = a1315 = a1416 = a1517 = b118 = b219 = b320 = b421 = b522 = b623 = b724 = b825 = b926 = b1027 = b1128 = b1229 = b1330 = b1431 = b1532 = c133 = c234 = c335 = c436 = c537 = c638 = c739 = c840 = c941 = c1042 = c1143 = c1244 = c1345 = c1446 = c15This textual convention defines all possible Group A, B and C Backward Signal in Signaling System R2. The group-A tones are generally used to query the call setup related information from the outgoing register. The group B signals convey information about the subscriber's line and equipment status. Some countries use the Group-C tones to differentiate between ANI and DNIS related operations with the help to Group-III related tones.Reference: ITU-T recommendation Q.441 · Integer32
This object specifies a backward signal requesting for out pulsing of the called digits or DNIS from beginning. The default value is country specific.
ccasBwdRSPlaySITTone
1.3.6.1.4.1.9.9.314.1.4.1.1.21
CASBackwardSignal1 = notApplicable2 = a13 = a24 = a35 = a46 = a57 = a68 = a79 = a810 = a911 = a1012 = a1113 = a1214 = a1315 = a1416 = a1517 = b118 = b219 = b320 = b421 = b522 = b623 = b724 = b825 = b926 = b1027 = b1128 = b1229 = b1330 = b1431 = b1532 = c133 = c234 = c335 = c436 = c537 = c638 = c739 = c840 = c941 = c1042 = c1143 = c1244 = c1345 = c1446 = c15This textual convention defines all possible Group A, B and C Backward Signal in Signaling System R2. The group-A tones are generally used to query the call setup related information from the outgoing register. The group B signals convey information about the subscriber's line and equipment status. Some countries use the Group-C tones to differentiate between ANI and DNIS related operations with the help to Group-III related tones.Reference: ITU-T recommendation Q.441 · Integer32
This object specifies a backward signal indicating that SIT tone should be played towards the calling party. The default value is country specific.
ccasBwdRSSubscriberLineBusy
1.3.6.1.4.1.9.9.314.1.4.1.1.22
CASBackwardSignal1 = notApplicable2 = a13 = a24 = a35 = a46 = a57 = a68 = a79 = a810 = a911 = a1012 = a1113 = a1214 = a1315 = a1416 = a1517 = b118 = b219 = b320 = b421 = b522 = b623 = b724 = b825 = b926 = b1027 = b1128 = b1229 = b1330 = b1431 = b1532 = c133 = c234 = c335 = c436 = c537 = c638 = c739 = c840 = c941 = c1042 = c1143 = c1244 = c1345 = c1446 = c15This textual convention defines all possible Group A, B and C Backward Signal in Signaling System R2. The group-A tones are generally used to query the call setup related information from the outgoing register. The group B signals convey information about the subscriber's line and equipment status. Some countries use the Group-C tones to differentiate between ANI and DNIS related operations with the help to Group-III related tones.Reference: ITU-T recommendation Q.441 · Integer32
This object specifies a backward signal indicating that the line or lines connecting the called subscriber to the exchange are busy or engaged. The default value is country specific. Reference: ITU-T Q440 - Specifications of signaling system R2 Interregister Signaling. Section 4.2.4.2 Backward signals.
ccasBwdRSNetworkCongstInGroupB
1.3.6.1.4.1.9.9.314.1.4.1.1.23
CASBackwardSignal1 = notApplicable2 = a13 = a24 = a35 = a46 = a57 = a68 = a79 = a810 = a911 = a1012 = a1113 = a1214 = a1315 = a1416 = a1517 = b118 = b219 = b320 = b421 = b522 = b623 = b724 = b825 = b926 = b1027 = b1128 = b1229 = b1330 = b1431 = b1532 = c133 = c234 = c335 = c436 = c537 = c638 = c739 = c840 = c941 = c1042 = c1143 = c1244 = c1345 = c1446 = c15This textual convention defines all possible Group A, B and C Backward Signal in Signaling System R2. The group-A tones are generally used to query the call setup related information from the outgoing register. The group B signals convey information about the subscriber's line and equipment status. Some countries use the Group-C tones to differentiate between ANI and DNIS related operations with the help to Group-III related tones.Reference: ITU-T recommendation Q.441 · Integer32
This object specifies a backward signal indicating that congestion condition has occured after the changeover to Group B signals. The default value is country specific. Reference: ITU-T Q440 - Specifications of signaling system R2 Interregister Signaling. Section 4.2.4.2 Backward signals.
ccasBwdRSInvalidDialedNumber
1.3.6.1.4.1.9.9.314.1.4.1.1.24
CASBackwardSignal1 = notApplicable2 = a13 = a24 = a35 = a46 = a57 = a68 = a79 = a810 = a911 = a1012 = a1113 = a1214 = a1315 = a1416 = a1517 = b118 = b219 = b320 = b421 = b522 = b623 = b724 = b825 = b926 = b1027 = b1128 = b1229 = b1330 = b1431 = b1532 = c133 = c234 = c335 = c436 = c537 = c638 = c739 = c840 = c941 = c1042 = c1143 = c1244 = c1345 = c1446 = c15This textual convention defines all possible Group A, B and C Backward Signal in Signaling System R2. The group-A tones are generally used to query the call setup related information from the outgoing register. The group B signals convey information about the subscriber's line and equipment status. Some countries use the Group-C tones to differentiate between ANI and DNIS related operations with the help to Group-III related tones.Reference: ITU-T recommendation Q.441 · Integer32
This object specifies a backward signal indicating that the dialed or called number is invalid or not in use (e.g. an unused country code, an unused trunk code or subscriber number that has not been allocated). The default value is country specific. Reference: ITU-T Q440 - Specifications of signaling system R2 Interregister Signaling. Section 4.2.4.2 Backward signals.
ccasBwdRSSubLineFreeWithCharge
1.3.6.1.4.1.9.9.314.1.4.1.1.25
CASBackwardSignal1 = notApplicable2 = a13 = a24 = a35 = a46 = a57 = a68 = a79 = a810 = a911 = a1012 = a1113 = a1214 = a1315 = a1416 = a1517 = b118 = b219 = b320 = b421 = b522 = b623 = b724 = b825 = b926 = b1027 = b1128 = b1229 = b1330 = b1431 = b1532 = c133 = c234 = c335 = c436 = c537 = c638 = c739 = c840 = c941 = c1042 = c1143 = c1244 = c1345 = c1446 = c15This textual convention defines all possible Group A, B and C Backward Signal in Signaling System R2. The group-A tones are generally used to query the call setup related information from the outgoing register. The group B signals convey information about the subscriber's line and equipment status. Some countries use the Group-C tones to differentiate between ANI and DNIS related operations with the help to Group-III related tones.Reference: ITU-T recommendation Q.441 · Integer32
This object specifies a backward signal indicating that the called party's line is free and that the call has to be charged on answer. The default value is country specific. Reference: ITU-T Q440 - Specifications of signaling system R2 Interregister Signaling. Section 4.2.4.2 Backward signals.
ccasBwdRSSubLineFreeWithNoCharge
1.3.6.1.4.1.9.9.314.1.4.1.1.26
CASBackwardSignal1 = notApplicable2 = a13 = a24 = a35 = a46 = a57 = a68 = a79 = a810 = a911 = a1012 = a1113 = a1214 = a1315 = a1416 = a1517 = b118 = b219 = b320 = b421 = b522 = b623 = b724 = b825 = b926 = b1027 = b1128 = b1229 = b1330 = b1431 = b1532 = c133 = c234 = c335 = c436 = c537 = c638 = c739 = c840 = c941 = c1042 = c1143 = c1244 = c1345 = c1446 = c15This textual convention defines all possible Group A, B and C Backward Signal in Signaling System R2. The group-A tones are generally used to query the call setup related information from the outgoing register. The group B signals convey information about the subscriber's line and equipment status. Some countries use the Group-C tones to differentiate between ANI and DNIS related operations with the help to Group-III related tones.Reference: ITU-T recommendation Q.441 · Integer32
This object specifies a backward signal indicating that the called party line is free but is not to be charged on answer. The default value is country specific. Reference: ITU-T Q440 - Specifications of signaling system R2 Interregister Signaling. Section 4.2.4.2 Backward signals.
ccasBwdRSSubLineOutOfOrder
1.3.6.1.4.1.9.9.314.1.4.1.1.27
CASBackwardSignal1 = notApplicable2 = a13 = a24 = a35 = a46 = a57 = a68 = a79 = a810 = a911 = a1012 = a1113 = a1214 = a1315 = a1416 = a1517 = b118 = b219 = b320 = b421 = b522 = b623 = b724 = b825 = b926 = b1027 = b1128 = b1229 = b1330 = b1431 = b1532 = c133 = c234 = c335 = c436 = c537 = c638 = c739 = c840 = c941 = c1042 = c1143 = c1244 = c1345 = c1446 = c15This textual convention defines all possible Group A, B and C Backward Signal in Signaling System R2. The group-A tones are generally used to query the call setup related information from the outgoing register. The group B signals convey information about the subscriber's line and equipment status. Some countries use the Group-C tones to differentiate between ANI and DNIS related operations with the help to Group-III related tones.Reference: ITU-T recommendation Q.441 · Integer32
This object specifies a backward signal indicating that the called party line is out of service or faulty. The default value is country specific. Reference: ITU-T Q440 - Specifications of signaling system R2 Interregister Signaling. Section 4.2.4.2 Backward signals.
ccasBwdRSAnnouncement
1.3.6.1.4.1.9.9.314.1.4.1.1.28
CASBackwardSignal1 = notApplicable2 = a13 = a24 = a35 = a46 = a57 = a68 = a79 = a810 = a911 = a1012 = a1113 = a1214 = a1315 = a1416 = a1517 = b118 = b219 = b320 = b421 = b522 = b623 = b724 = b825 = b926 = b1027 = b1128 = b1229 = b1330 = b1431 = b1532 = c133 = c234 = c335 = c436 = c537 = c638 = c739 = c840 = c941 = c1042 = c1143 = c1244 = c1345 = c1446 = c15This textual convention defines all possible Group A, B and C Backward Signal in Signaling System R2. The group-A tones are generally used to query the call setup related information from the outgoing register. The group B signals convey information about the subscriber's line and equipment status. Some countries use the Group-C tones to differentiate between ANI and DNIS related operations with the help to Group-III related tones.Reference: ITU-T recommendation Q.441 · Integer32
This object specifies a backward signal indicating that an announcement follows this indication. The default value is country specific.
ccasBwdRSXtoGrpASendNextDNIS
1.3.6.1.4.1.9.9.314.1.4.1.1.29
CASBackwardSignal1 = notApplicable2 = a13 = a24 = a35 = a46 = a57 = a68 = a79 = a810 = a911 = a1012 = a1113 = a1214 = a1315 = a1416 = a1517 = b118 = b219 = b320 = b421 = b522 = b623 = b724 = b825 = b926 = b1027 = b1128 = b1229 = b1330 = b1431 = b1532 = c133 = c234 = c335 = c436 = c537 = c638 = c739 = c840 = c941 = c1042 = c1143 = c1244 = c1345 = c1446 = c15This textual convention defines all possible Group A, B and C Backward Signal in Signaling System R2. The group-A tones are generally used to query the call setup related information from the outgoing register. The group B signals convey information about the subscriber's line and equipment status. Some countries use the Group-C tones to differentiate between ANI and DNIS related operations with the help to Group-III related tones.Reference: ITU-T recommendation Q.441 · Integer32
This object specifies a backward signal requesting the other exchange to switch to reception of group A and send the next DNIS digit. The default value is country specific.
ccasBwdRSXtoGrpASendDNISFrmBeg
1.3.6.1.4.1.9.9.314.1.4.1.1.30
CASBackwardSignal1 = notApplicable2 = a13 = a24 = a35 = a46 = a57 = a68 = a79 = a810 = a911 = a1012 = a1113 = a1214 = a1315 = a1416 = a1517 = b118 = b219 = b320 = b421 = b522 = b623 = b724 = b825 = b926 = b1027 = b1128 = b1229 = b1330 = b1431 = b1532 = c133 = c234 = c335 = c436 = c537 = c638 = c739 = c840 = c941 = c1042 = c1143 = c1244 = c1345 = c1446 = c15This textual convention defines all possible Group A, B and C Backward Signal in Signaling System R2. The group-A tones are generally used to query the call setup related information from the outgoing register. The group B signals convey information about the subscriber's line and equipment status. Some countries use the Group-C tones to differentiate between ANI and DNIS related operations with the help to Group-III related tones.Reference: ITU-T recommendation Q.441 · Integer32
This object specifies a backward signal requesting the other exchange to switch to reception of group A and send the DNIS digits from the beginning. The default value is country specific.
ccasBwdRSXtoGrpAResendLastDNIS
1.3.6.1.4.1.9.9.314.1.4.1.1.31
CASBackwardSignal1 = notApplicable2 = a13 = a24 = a35 = a46 = a57 = a68 = a79 = a810 = a911 = a1012 = a1113 = a1214 = a1315 = a1416 = a1517 = b118 = b219 = b320 = b421 = b522 = b623 = b724 = b825 = b926 = b1027 = b1128 = b1229 = b1330 = b1431 = b1532 = c133 = c234 = c335 = c436 = c537 = c638 = c739 = c840 = c941 = c1042 = c1143 = c1244 = c1345 = c1446 = c15This textual convention defines all possible Group A, B and C Backward Signal in Signaling System R2. The group-A tones are generally used to query the call setup related information from the outgoing register. The group B signals convey information about the subscriber's line and equipment status. Some countries use the Group-C tones to differentiate between ANI and DNIS related operations with the help to Group-III related tones.Reference: ITU-T recommendation Q.441 · Integer32
This object specifies a backward signal requesting the other exchange to switch to reception of group A and resend the last DNIS digit sent out. The default value is country specific.
ccasBwdRSSSendCatSwGrpB
1.3.6.1.4.1.9.9.314.1.4.1.1.32
CASBackwardSignal1 = notApplicable2 = a13 = a24 = a35 = a46 = a57 = a68 = a79 = a810 = a911 = a1012 = a1113 = a1214 = a1315 = a1416 = a1517 = b118 = b219 = b320 = b421 = b522 = b623 = b724 = b825 = b926 = b1027 = b1128 = b1229 = b1330 = b1431 = b1532 = c133 = c234 = c335 = c436 = c537 = c638 = c739 = c840 = c941 = c1042 = c1143 = c1244 = c1345 = c1446 = c15This textual convention defines all possible Group A, B and C Backward Signal in Signaling System R2. The group-A tones are generally used to query the call setup related information from the outgoing register. The group B signals convey information about the subscriber's line and equipment status. Some countries use the Group-C tones to differentiate between ANI and DNIS related operations with the help to Group-III related tones.Reference: ITU-T recommendation Q.441 · Integer32
This object specifies a backward signal requesting the end receiving this signal to send the subscriber category information and switch to grp B from group C. The default value is country specific.
ccasBwdRSSGrpCCong
1.3.6.1.4.1.9.9.314.1.4.1.1.33
CASBackwardSignal1 = notApplicable2 = a13 = a24 = a35 = a46 = a57 = a68 = a79 = a810 = a911 = a1012 = a1113 = a1214 = a1315 = a1416 = a1517 = b118 = b219 = b320 = b421 = b522 = b623 = b724 = b825 = b926 = b1027 = b1128 = b1229 = b1330 = b1431 = b1532 = c133 = c234 = c335 = c436 = c537 = c638 = c739 = c840 = c941 = c1042 = c1143 = c1244 = c1345 = c1446 = c15This textual convention defines all possible Group A, B and C Backward Signal in Signaling System R2. The group-A tones are generally used to query the call setup related information from the outgoing register. The group B signals convey information about the subscriber's line and equipment status. Some countries use the Group-C tones to differentiate between ANI and DNIS related operations with the help to Group-III related tones.Reference: ITU-T recommendation Q.441 · Integer32
This object specifies a backward signal indicating that congestion occurred in the network when in group C signaling state. The default value is country specific.
ccasFwdRSANIDigitAvailable
1.3.6.1.4.1.9.9.314.1.4.1.1.34
CASForwardSignal1 = notApplicable2 = i13 = i24 = i35 = i46 = i57 = i68 = i79 = i810 = i911 = i1012 = i1113 = i1214 = i1315 = i1416 = i1517 = ii118 = ii219 = ii320 = ii421 = ii522 = ii623 = ii724 = ii825 = ii926 = ii1027 = ii1128 = ii1229 = ii1330 = ii1431 = ii1532 = iiI133 = iiI234 = iii335 = iii436 = iii537 = iii638 = iii739 = iii840 = iii941 = iii1042 = iii1143 = iii1244 = iii1345 = iii1446 = iii15This textual convention defines all possible Group I, II, and III Forward Signals in Signaling System R2. The Forward Group I signals represent the called numbers, calling party number and equipment requirements for the call. The Forward Group II signals are calling party's category signal sent by outgoing R2 registers or by outgoing international R2 registers in reply to the backward signals, and give whether national or international working applies. The Forward Group III are distinguished between DNIS and ANI digits.Reference: ITU-T recommendation Q.441 · Integer32
This object specifies a forward signal indicating that ANI digits are available. This is used in country variants like India to indicate that the ANI digits are available when the backward signal requesting for ANI digits is received, before pulsing out the actual ANI digits. The default value is country specific.
ccasFwdRSANIDigitNotAvailable
1.3.6.1.4.1.9.9.314.1.4.1.1.35
CASForwardSignal1 = notApplicable2 = i13 = i24 = i35 = i46 = i57 = i68 = i79 = i810 = i911 = i1012 = i1113 = i1214 = i1315 = i1416 = i1517 = ii118 = ii219 = ii320 = ii421 = ii522 = ii623 = ii724 = ii825 = ii926 = ii1027 = ii1128 = ii1229 = ii1330 = ii1431 = ii1532 = iiI133 = iiI234 = iii335 = iii436 = iii537 = iii638 = iii739 = iii840 = iii941 = iii1042 = iii1143 = iii1244 = iii1345 = iii1446 = iii15This textual convention defines all possible Group I, II, and III Forward Signals in Signaling System R2. The Forward Group I signals represent the called numbers, calling party number and equipment requirements for the call. The Forward Group II signals are calling party's category signal sent by outgoing R2 registers or by outgoing international R2 registers in reply to the backward signals, and give whether national or international working applies. The Forward Group III are distinguished between DNIS and ANI digits.Reference: ITU-T recommendation Q.441 · Integer32
This object specifies a forward signal indicating that there are no ANI digits available for out pulsing. The default value is country specific.
ccasFwdRSEndANICallingPartyNotRev
1.3.6.1.4.1.9.9.314.1.4.1.1.36
CASForwardSignal1 = notApplicable2 = i13 = i24 = i35 = i46 = i57 = i68 = i79 = i810 = i911 = i1012 = i1113 = i1214 = i1315 = i1416 = i1517 = ii118 = ii219 = ii320 = ii421 = ii522 = ii623 = ii724 = ii825 = ii926 = ii1027 = ii1128 = ii1229 = ii1330 = ii1431 = ii1532 = iiI133 = iiI234 = iii335 = iii436 = iii537 = iii638 = iii739 = iii840 = iii941 = iii1042 = iii1143 = iii1244 = iii1345 = iii1446 = iii15This textual convention defines all possible Group I, II, and III Forward Signals in Signaling System R2. The Forward Group I signals represent the called numbers, calling party number and equipment requirements for the call. The Forward Group II signals are calling party's category signal sent by outgoing R2 registers or by outgoing international R2 registers in reply to the backward signals, and give whether national or international working applies. The Forward Group III are distinguished between DNIS and ANI digits.Reference: ITU-T recommendation Q.441 · Integer32
This object specifies a forward signal indicating that there are no more ANI digits to out pulse and the calling party can not be revealed to the called party. The default value is country specific.
ccasFwdRSEndANICallingPartyRev
1.3.6.1.4.1.9.9.314.1.4.1.1.37
CASForwardSignal1 = notApplicable2 = i13 = i24 = i35 = i46 = i57 = i68 = i79 = i810 = i911 = i1012 = i1113 = i1214 = i1315 = i1416 = i1517 = ii118 = ii219 = ii320 = ii421 = ii522 = ii623 = ii724 = ii825 = ii926 = ii1027 = ii1128 = ii1229 = ii1330 = ii1431 = ii1532 = iiI133 = iiI234 = iii335 = iii436 = iii537 = iii638 = iii739 = iii840 = iii941 = iii1042 = iii1143 = iii1244 = iii1345 = iii1446 = iii15This textual convention defines all possible Group I, II, and III Forward Signals in Signaling System R2. The Forward Group I signals represent the called numbers, calling party number and equipment requirements for the call. The Forward Group II signals are calling party's category signal sent by outgoing R2 registers or by outgoing international R2 registers in reply to the backward signals, and give whether national or international working applies. The Forward Group III are distinguished between DNIS and ANI digits.Reference: ITU-T recommendation Q.441 · Integer32
This object specifies a forward signal indicating that there are no more ANI digits to out pulse and the calling party can be revealed to the called party. The default value is country specific.
ccasFwdRSEndOfDNISDigit
1.3.6.1.4.1.9.9.314.1.4.1.1.38
CASForwardSignal1 = notApplicable2 = i13 = i24 = i35 = i46 = i57 = i68 = i79 = i810 = i911 = i1012 = i1113 = i1214 = i1315 = i1416 = i1517 = ii118 = ii219 = ii320 = ii421 = ii522 = ii623 = ii724 = ii825 = ii926 = ii1027 = ii1128 = ii1229 = ii1330 = ii1431 = ii1532 = iiI133 = iiI234 = iii335 = iii436 = iii537 = iii638 = iii739 = iii840 = iii941 = iii1042 = iii1143 = iii1244 = iii1345 = iii1446 = iii15This textual convention defines all possible Group I, II, and III Forward Signals in Signaling System R2. The Forward Group I signals represent the called numbers, calling party number and equipment requirements for the call. The Forward Group II signals are calling party's category signal sent by outgoing R2 registers or by outgoing international R2 registers in reply to the backward signals, and give whether national or international working applies. The Forward Group III are distinguished between DNIS and ANI digits.Reference: ITU-T recommendation Q.441 · Integer32
This object specifies a forward signal indicating the end of DNIS digits. The default value is country specific.
ccasFwdRSNoCategoryAvailble
1.3.6.1.4.1.9.9.314.1.4.1.1.39
CASForwardSignal1 = notApplicable2 = i13 = i24 = i35 = i46 = i57 = i68 = i79 = i810 = i911 = i1012 = i1113 = i1214 = i1315 = i1416 = i1517 = ii118 = ii219 = ii320 = ii421 = ii522 = ii623 = ii724 = ii825 = ii926 = ii1027 = ii1128 = ii1229 = ii1330 = ii1431 = ii1532 = iiI133 = iiI234 = iii335 = iii436 = iii537 = iii638 = iii739 = iii840 = iii941 = iii1042 = iii1143 = iii1244 = iii1345 = iii1446 = iii15This textual convention defines all possible Group I, II, and III Forward Signals in Signaling System R2. The Forward Group I signals represent the called numbers, calling party number and equipment requirements for the call. The Forward Group II signals are calling party's category signal sent by outgoing R2 registers or by outgoing international R2 registers in reply to the backward signals, and give whether national or international working applies. The Forward Group III are distinguished between DNIS and ANI digits.Reference: ITU-T recommendation Q.441 · Integer32
This object specifies a forward signal indicating that there is no calling party category (information) available to be sent out. The default value is country specific.
ccasFwdRSCCEchoSuppressor
1.3.6.1.4.1.9.9.314.1.4.1.1.40
CASForwardSignal1 = notApplicable2 = i13 = i24 = i35 = i46 = i57 = i68 = i79 = i810 = i911 = i1012 = i1113 = i1214 = i1315 = i1416 = i1517 = ii118 = ii219 = ii320 = ii421 = ii522 = ii623 = ii724 = ii825 = ii926 = ii1027 = ii1128 = ii1229 = ii1330 = ii1431 = ii1532 = iiI133 = iiI234 = iii335 = iii436 = iii537 = iii638 = iii739 = iii840 = iii941 = iii1042 = iii1143 = iii1244 = iii1345 = iii1446 = iii15This textual convention defines all possible Group I, II, and III Forward Signals in Signaling System R2. The Forward Group I signals represent the called numbers, calling party number and equipment requirements for the call. The Forward Group II signals are calling party's category signal sent by outgoing R2 registers or by outgoing international R2 registers in reply to the backward signals, and give whether national or international working applies. The Forward Group III are distinguished between DNIS and ANI digits.Reference: ITU-T recommendation Q.441 · Integer32
This object specifies a forward signal. When it is used as the first forward signal and it indicates that: . A country code will follow on an international link. . The call requires echo suppressors. The default value is country specific. Reference: ITU-T Q440 - Specifications of signaling system R2 Interregister Signaling. Section 4.2.3.1 Forward signals.
ccasFwdRSCCNoEchoSuppressor
1.3.6.1.4.1.9.9.314.1.4.1.1.41
CASForwardSignal1 = notApplicable2 = i13 = i24 = i35 = i46 = i57 = i68 = i79 = i810 = i911 = i1012 = i1113 = i1214 = i1315 = i1416 = i1517 = ii118 = ii219 = ii320 = ii421 = ii522 = ii623 = ii724 = ii825 = ii926 = ii1027 = ii1128 = ii1229 = ii1330 = ii1431 = ii1532 = iiI133 = iiI234 = iii335 = iii436 = iii537 = iii638 = iii739 = iii840 = iii941 = iii1042 = iii1143 = iii1244 = iii1345 = iii1446 = iii15This textual convention defines all possible Group I, II, and III Forward Signals in Signaling System R2. The Forward Group I signals represent the called numbers, calling party number and equipment requirements for the call. The Forward Group II signals are calling party's category signal sent by outgoing R2 registers or by outgoing international R2 registers in reply to the backward signals, and give whether national or international working applies. The Forward Group III are distinguished between DNIS and ANI digits.Reference: ITU-T recommendation Q.441 · Integer32
This object specifies a forward signal. When it is used as the first forward signal and it indicates that: . A country code will follow on an international link. . The call may not require any echo suppressor. The default value is country specific. Reference: ITU-T Q440 - Specifications of signaling system R2 Interregister Signaling. Section 4.2.3.1 Forward signals.
ccasFwdRSCCInsertEchoSuppressor
1.3.6.1.4.1.9.9.314.1.4.1.1.42
CASForwardSignal1 = notApplicable2 = i13 = i24 = i35 = i46 = i57 = i68 = i79 = i810 = i911 = i1012 = i1113 = i1214 = i1315 = i1416 = i1517 = ii118 = ii219 = ii320 = ii421 = ii522 = ii623 = ii724 = ii825 = ii926 = ii1027 = ii1128 = ii1229 = ii1330 = ii1431 = ii1532 = iiI133 = iiI234 = iii335 = iii436 = iii537 = iii638 = iii739 = iii840 = iii941 = iii1042 = iii1143 = iii1244 = iii1345 = iii1446 = iii15This textual convention defines all possible Group I, II, and III Forward Signals in Signaling System R2. The Forward Group I signals represent the called numbers, calling party number and equipment requirements for the call. The Forward Group II signals are calling party's category signal sent by outgoing R2 registers or by outgoing international R2 registers in reply to the backward signals, and give whether national or international working applies. The Forward Group III are distinguished between DNIS and ANI digits.Reference: ITU-T recommendation Q.441 · Integer32
This object specifies a forward signal. When it is used as the first forward signal and it indicates that: . A country code will follow on an international link. . The outgoing half echo suppressor has to be inserted. The default value is country specific. Reference: ITU-T Q440 - Specifications of signaling system R2 Interregister Signaling. Section 4.2.3.1 Forward signals.
ccasFwdRSIncHalfEchoRequired
1.3.6.1.4.1.9.9.314.1.4.1.1.43
CASForwardSignal1 = notApplicable2 = i13 = i24 = i35 = i46 = i57 = i68 = i79 = i810 = i911 = i1012 = i1113 = i1214 = i1315 = i1416 = i1517 = ii118 = ii219 = ii320 = ii421 = ii522 = ii623 = ii724 = ii825 = ii926 = ii1027 = ii1128 = ii1229 = ii1330 = ii1431 = ii1532 = iiI133 = iiI234 = iii335 = iii436 = iii537 = iii638 = iii739 = iii840 = iii941 = iii1042 = iii1143 = iii1244 = iii1345 = iii1446 = iii15This textual convention defines all possible Group I, II, and III Forward Signals in Signaling System R2. The Forward Group I signals represent the called numbers, calling party number and equipment requirements for the call. The Forward Group II signals are calling party's category signal sent by outgoing R2 registers or by outgoing international R2 registers in reply to the backward signals, and give whether national or international working applies. The Forward Group III are distinguished between DNIS and ANI digits.Reference: ITU-T recommendation Q.441 · Integer32
This object specifies a forward signal indicating that: . The outgoing half echo suppressor has been inserted. . The incoming half echo suppressor is required. The default value is country specific. Reference: ITU-T Q440 - Specifications of signaling system R2 Interregister Signaling. Section 4.2.3.1 Forward signals.
ccasFwdRSTestCall
1.3.6.1.4.1.9.9.314.1.4.1.1.44
CASForwardSignal1 = notApplicable2 = i13 = i24 = i35 = i46 = i57 = i68 = i79 = i810 = i911 = i1012 = i1113 = i1214 = i1315 = i1416 = i1517 = ii118 = ii219 = ii320 = ii421 = ii522 = ii623 = ii724 = ii825 = ii926 = ii1027 = ii1128 = ii1229 = ii1330 = ii1431 = ii1532 = iiI133 = iiI234 = iii335 = iii436 = iii537 = iii638 = iii739 = iii840 = iii941 = iii1042 = iii1143 = iii1244 = iii1345 = iii1446 = iii15This textual convention defines all possible Group I, II, and III Forward Signals in Signaling System R2. The Forward Group I signals represent the called numbers, calling party number and equipment requirements for the call. The Forward Group II signals are calling party's category signal sent by outgoing R2 registers or by outgoing international R2 registers in reply to the backward signals, and give whether national or international working applies. The Forward Group III are distinguished between DNIS and ANI digits.Reference: ITU-T recommendation Q.441 · Integer32
This object specifies a forward signal. When it is used as the first forward signal and indicates that the call is being originated by test equipment. The default value is country specific. Reference: ITU-T Q440 - Specifications of signaling system R2 Interregister Signaling. Section 4.2.3.1 Forward signals.
ccasFwdRSSatelLinkIncluded
1.3.6.1.4.1.9.9.314.1.4.1.1.45
CASForwardSignal1 = notApplicable2 = i13 = i24 = i35 = i46 = i57 = i68 = i79 = i810 = i911 = i1012 = i1113 = i1214 = i1315 = i1416 = i1517 = ii118 = ii219 = ii320 = ii421 = ii522 = ii623 = ii724 = ii825 = ii926 = ii1027 = ii1128 = ii1229 = ii1330 = ii1431 = ii1532 = iiI133 = iiI234 = iii335 = iii436 = iii537 = iii638 = iii739 = iii840 = iii941 = iii1042 = iii1143 = iii1244 = iii1345 = iii1446 = iii15This textual convention defines all possible Group I, II, and III Forward Signals in Signaling System R2. The Forward Group I signals represent the called numbers, calling party number and equipment requirements for the call. The Forward Group II signals are calling party's category signal sent by outgoing R2 registers or by outgoing international R2 registers in reply to the backward signals, and give whether national or international working applies. The Forward Group III are distinguished between DNIS and ANI digits.Reference: ITU-T recommendation Q.441 · Integer32
This object specifies a forward signal indicating that a satellite link is included in the connection. This signal is sent in response to backward signal requesting for nature of circuit. The default value is country specific. Reference: ITU-T Q440 - Specifications of signaling system R2 Interregister Signaling. Section 4.2.3.1 Forward signals.
ccasFwdRSSatelLinkNotIncluded
1.3.6.1.4.1.9.9.314.1.4.1.1.46
CASForwardSignal1 = notApplicable2 = i13 = i24 = i35 = i46 = i57 = i68 = i79 = i810 = i911 = i1012 = i1113 = i1214 = i1315 = i1416 = i1517 = ii118 = ii219 = ii320 = ii421 = ii522 = ii623 = ii724 = ii825 = ii926 = ii1027 = ii1128 = ii1229 = ii1330 = ii1431 = ii1532 = iiI133 = iiI234 = iii335 = iii436 = iii537 = iii638 = iii739 = iii840 = iii941 = iii1042 = iii1143 = iii1244 = iii1345 = iii1446 = iii15This textual convention defines all possible Group I, II, and III Forward Signals in Signaling System R2. The Forward Group I signals represent the called numbers, calling party number and equipment requirements for the call. The Forward Group II signals are calling party's category signal sent by outgoing R2 registers or by outgoing international R2 registers in reply to the backward signals, and give whether national or international working applies. The Forward Group III are distinguished between DNIS and ANI digits.Reference: ITU-T recommendation Q.441 · Integer32
This object specifies a forward signal indicating that no satellite link is included in the connection. This signal is sent in response to backward signal requesting for nature of circuit. The default value is country specific. Reference: ITU-T Q440 - Specifications of signaling system R2 Interregister Signaling. Section 4.2.3.1 Forward signals.
ccasFwdRSDiscriminatorDigit
1.3.6.1.4.1.9.9.314.1.4.1.1.47
CASForwardSignal1 = notApplicable2 = i13 = i24 = i35 = i46 = i57 = i68 = i79 = i810 = i911 = i1012 = i1113 = i1214 = i1315 = i1416 = i1517 = ii118 = ii219 = ii320 = ii421 = ii522 = ii623 = ii724 = ii825 = ii926 = ii1027 = ii1128 = ii1229 = ii1330 = ii1431 = ii1532 = iiI133 = iiI234 = iii335 = iii436 = iii537 = iii638 = iii739 = iii840 = iii941 = iii1042 = iii1143 = iii1244 = iii1345 = iii1446 = iii15This textual convention defines all possible Group I, II, and III Forward Signals in Signaling System R2. The Forward Group I signals represent the called numbers, calling party number and equipment requirements for the call. The Forward Group II signals are calling party's category signal sent by outgoing R2 registers or by outgoing international R2 registers in reply to the backward signals, and give whether national or international working applies. The Forward Group III are distinguished between DNIS and ANI digits.Reference: ITU-T recommendation Q.441 · Integer32
This object specifies a forward signal indicating the digit that separates or distinguishes different information blocks in the forward signals being generated or received. The default value is country specific. Reference: ITU-T Q440 - Specifications of signaling system R2 Interregister Signaling. Section 4.2.3.1 Forward signals.
ccasFwdRSOtherLanguage
1.3.6.1.4.1.9.9.314.1.4.1.1.48
CASForwardSignal1 = notApplicable2 = i13 = i24 = i35 = i46 = i57 = i68 = i79 = i810 = i911 = i1012 = i1113 = i1214 = i1315 = i1416 = i1517 = ii118 = ii219 = ii320 = ii421 = ii522 = ii623 = ii724 = ii825 = ii926 = ii1027 = ii1128 = ii1229 = ii1330 = ii1431 = ii1532 = iiI133 = iiI234 = iii335 = iii436 = iii537 = iii638 = iii739 = iii840 = iii941 = iii1042 = iii1143 = iii1244 = iii1345 = iii1446 = iii15This textual convention defines all possible Group I, II, and III Forward Signals in Signaling System R2. The Forward Group I signals represent the called numbers, calling party number and equipment requirements for the call. The Forward Group II signals are calling party's category signal sent by outgoing R2 registers or by outgoing international R2 registers in reply to the backward signals, and give whether national or international working applies. The Forward Group III are distinguished between DNIS and ANI digits.Reference: ITU-T recommendation Q.441 · Integer32
This object specifies a forward signal indicating that the language to be used for an operator assisted call. The default value is country specific. Reference: ITU-T Q440 - Specifications of signaling system R2 Interregister Signaling. Section 4.2.3.1 Forward signals.
ccasFwdRSOtherLanguage1
1.3.6.1.4.1.9.9.314.1.4.1.1.49
CASForwardSignal1 = notApplicable2 = i13 = i24 = i35 = i46 = i57 = i68 = i79 = i810 = i911 = i1012 = i1113 = i1214 = i1315 = i1416 = i1517 = ii118 = ii219 = ii320 = ii421 = ii522 = ii623 = ii724 = ii825 = ii926 = ii1027 = ii1128 = ii1229 = ii1330 = ii1431 = ii1532 = iiI133 = iiI234 = iii335 = iii436 = iii537 = iii638 = iii739 = iii840 = iii941 = iii1042 = iii1143 = iii1244 = iii1345 = iii1446 = iii15This textual convention defines all possible Group I, II, and III Forward Signals in Signaling System R2. The Forward Group I signals represent the called numbers, calling party number and equipment requirements for the call. The Forward Group II signals are calling party's category signal sent by outgoing R2 registers or by outgoing international R2 registers in reply to the backward signals, and give whether national or international working applies. The Forward Group III are distinguished between DNIS and ANI digits.Reference: ITU-T recommendation Q.441 · Integer32
This object specifies a forward signal indicating that the language to be used for an operator assisted call. The default value is country specific. Reference: ITU-T Q440 - Specifications of signaling system R2 Interregister Signaling. Section 4.2.3.1 Forward signals.
ccasFwdRSOtherLanguage2
1.3.6.1.4.1.9.9.314.1.4.1.1.50
CASForwardSignal1 = notApplicable2 = i13 = i24 = i35 = i46 = i57 = i68 = i79 = i810 = i911 = i1012 = i1113 = i1214 = i1315 = i1416 = i1517 = ii118 = ii219 = ii320 = ii421 = ii522 = ii623 = ii724 = ii825 = ii926 = ii1027 = ii1128 = ii1229 = ii1330 = ii1431 = ii1532 = iiI133 = iiI234 = iii335 = iii436 = iii537 = iii638 = iii739 = iii840 = iii941 = iii1042 = iii1143 = iii1244 = iii1345 = iii1446 = iii15This textual convention defines all possible Group I, II, and III Forward Signals in Signaling System R2. The Forward Group I signals represent the called numbers, calling party number and equipment requirements for the call. The Forward Group II signals are calling party's category signal sent by outgoing R2 registers or by outgoing international R2 registers in reply to the backward signals, and give whether national or international working applies. The Forward Group III are distinguished between DNIS and ANI digits.Reference: ITU-T recommendation Q.441 · Integer32
This object specifies a forward signal indicating that the language to be used for an operator assisted call. The default value is country specific. Reference: ITU-T Q440 - Specifications of signaling system R2 Interregister Signaling. Section 4.2.3.1 Forward signals.
ccasFwdRSRequestNotAccepted
1.3.6.1.4.1.9.9.314.1.4.1.1.51
CASForwardSignal1 = notApplicable2 = i13 = i24 = i35 = i46 = i57 = i68 = i79 = i810 = i911 = i1012 = i1113 = i1214 = i1315 = i1416 = i1517 = ii118 = ii219 = ii320 = ii421 = ii522 = ii623 = ii724 = ii825 = ii926 = ii1027 = ii1128 = ii1229 = ii1330 = ii1431 = ii1532 = iiI133 = iiI234 = iii335 = iii436 = iii537 = iii638 = iii739 = iii840 = iii941 = iii1042 = iii1143 = iii1244 = iii1345 = iii1446 = iii15This textual convention defines all possible Group I, II, and III Forward Signals in Signaling System R2. The Forward Group I signals represent the called numbers, calling party number and equipment requirements for the call. The Forward Group II signals are calling party's category signal sent by outgoing R2 registers or by outgoing international R2 registers in reply to the backward signals, and give whether national or international working applies. The Forward Group III are distinguished between DNIS and ANI digits.Reference: ITU-T recommendation Q.441 · Integer32
This object specifies a forward signal indicating that the receiving backward signal could not be processed or defined. The default value is country specific. Reference: ITU-T Q440 - Specifications of signaling system R2 Interregister Signaling. Section 4.2.3.1 Forward signals.
ccasFwdRSSubWithoutPriorNational
1.3.6.1.4.1.9.9.314.1.4.1.1.52
CASForwardSignal1 = notApplicable2 = i13 = i24 = i35 = i46 = i57 = i68 = i79 = i810 = i911 = i1012 = i1113 = i1214 = i1315 = i1416 = i1517 = ii118 = ii219 = ii320 = ii421 = ii522 = ii623 = ii724 = ii825 = ii926 = ii1027 = ii1128 = ii1229 = ii1330 = ii1431 = ii1532 = iiI133 = iiI234 = iii335 = iii436 = iii537 = iii638 = iii739 = iii840 = iii941 = iii1042 = iii1143 = iii1244 = iii1345 = iii1446 = iii15This textual convention defines all possible Group I, II, and III Forward Signals in Signaling System R2. The Forward Group I signals represent the called numbers, calling party number and equipment requirements for the call. The Forward Group II signals are calling party's category signal sent by outgoing R2 registers or by outgoing international R2 registers in reply to the backward signals, and give whether national or international working applies. The Forward Group III are distinguished between DNIS and ANI digits.Reference: ITU-T recommendation Q.441 · Integer32
This object specifies a forward signal indicating that the call is set up from a subscriber's line and is non-priority. The default value is country specific. Reference: ITU-T Q440 - Specifications of signaling system R2 Interregister Signaling. Section 4.2.3.2 Forward signals.
ccasFwdRSSubPriorNational
1.3.6.1.4.1.9.9.314.1.4.1.1.53
CASForwardSignal1 = notApplicable2 = i13 = i24 = i35 = i46 = i57 = i68 = i79 = i810 = i911 = i1012 = i1113 = i1214 = i1315 = i1416 = i1517 = ii118 = ii219 = ii320 = ii421 = ii522 = ii623 = ii724 = ii825 = ii926 = ii1027 = ii1128 = ii1229 = ii1330 = ii1431 = ii1532 = iiI133 = iiI234 = iii335 = iii436 = iii537 = iii638 = iii739 = iii840 = iii941 = iii1042 = iii1143 = iii1244 = iii1345 = iii1446 = iii15This textual convention defines all possible Group I, II, and III Forward Signals in Signaling System R2. The Forward Group I signals represent the called numbers, calling party number and equipment requirements for the call. The Forward Group II signals are calling party's category signal sent by outgoing R2 registers or by outgoing international R2 registers in reply to the backward signals, and give whether national or international working applies. The Forward Group III are distinguished between DNIS and ANI digits.Reference: ITU-T recommendation Q.441 · Integer32
This object specifies a forward signal indicating that the call is set up from a subscriber's line to which priority treatment of calls has been accorded. This signal is specified to national trunks only. The default value is country specific. Reference: ITU-T Q440 - Specifications of signaling system R2 Interregister Signaling. Section 4.2.3.2 Forward signals.
ccasFwdRSSubPriorInternational
1.3.6.1.4.1.9.9.314.1.4.1.1.54
CASForwardSignal1 = notApplicable2 = i13 = i24 = i35 = i46 = i57 = i68 = i79 = i810 = i911 = i1012 = i1113 = i1214 = i1315 = i1416 = i1517 = ii118 = ii219 = ii320 = ii421 = ii522 = ii623 = ii724 = ii825 = ii926 = ii1027 = ii1128 = ii1229 = ii1330 = ii1431 = ii1532 = iiI133 = iiI234 = iii335 = iii436 = iii537 = iii638 = iii739 = iii840 = iii941 = iii1042 = iii1143 = iii1244 = iii1345 = iii1446 = iii15This textual convention defines all possible Group I, II, and III Forward Signals in Signaling System R2. The Forward Group I signals represent the called numbers, calling party number and equipment requirements for the call. The Forward Group II signals are calling party's category signal sent by outgoing R2 registers or by outgoing international R2 registers in reply to the backward signals, and give whether national or international working applies. The Forward Group III are distinguished between DNIS and ANI digits.Reference: ITU-T recommendation Q.441 · Integer32
This object specifies a forward signal indicating that the call is set up from a subscriber's line to which priority treatment of calls has been accorded. This signal is specified to international trunks only. The default value is country specific. Reference: ITU-T Q440 - Specifications of signaling system R2 Interregister Signaling. Section 4.2.3.2 Forward signals.
ccasFwdRSMaintenanceEquipment
1.3.6.1.4.1.9.9.314.1.4.1.1.55
CASForwardSignal1 = notApplicable2 = i13 = i24 = i35 = i46 = i57 = i68 = i79 = i810 = i911 = i1012 = i1113 = i1214 = i1315 = i1416 = i1517 = ii118 = ii219 = ii320 = ii421 = ii522 = ii623 = ii724 = ii825 = ii926 = ii1027 = ii1128 = ii1229 = ii1330 = ii1431 = ii1532 = iiI133 = iiI234 = iii335 = iii436 = iii537 = iii638 = iii739 = iii840 = iii941 = iii1042 = iii1143 = iii1244 = iii1345 = iii1446 = iii15This textual convention defines all possible Group I, II, and III Forward Signals in Signaling System R2. The Forward Group I signals represent the called numbers, calling party number and equipment requirements for the call. The Forward Group II signals are calling party's category signal sent by outgoing R2 registers or by outgoing international R2 registers in reply to the backward signals, and give whether national or international working applies. The Forward Group III are distinguished between DNIS and ANI digits.Reference: ITU-T recommendation Q.441 · Integer32
This object specifies a forward signal indicating that the call comes from maintenance equipment. The default value is country specific. Reference: ITU-T Q440 - Specifications of signaling system R2 Interregister Signaling. Section 4.2.3.2 Forward signals.
ccasFwdRSOperatorCall
1.3.6.1.4.1.9.9.314.1.4.1.1.56
CASForwardSignal1 = notApplicable2 = i13 = i24 = i35 = i46 = i57 = i68 = i79 = i810 = i911 = i1012 = i1113 = i1214 = i1315 = i1416 = i1517 = ii118 = ii219 = ii320 = ii421 = ii522 = ii623 = ii724 = ii825 = ii926 = ii1027 = ii1128 = ii1229 = ii1330 = ii1431 = ii1532 = iiI133 = iiI234 = iii335 = iii436 = iii537 = iii638 = iii739 = iii840 = iii941 = iii1042 = iii1143 = iii1244 = iii1345 = iii1446 = iii15This textual convention defines all possible Group I, II, and III Forward Signals in Signaling System R2. The Forward Group I signals represent the called numbers, calling party number and equipment requirements for the call. The Forward Group II signals are calling party's category signal sent by outgoing R2 registers or by outgoing international R2 registers in reply to the backward signals, and give whether national or international working applies. The Forward Group III are distinguished between DNIS and ANI digits.Reference: ITU-T recommendation Q.441 · Integer32
This object specifies a forward signal indicating that the call is setup from an operator. The default value is country specific. Reference: ITU-T Q440 - Specifications of signaling system R2 Interregister Signaling. Section 4.2.3.2 Forward signals.
ccasFwdRSDataTransNational
1.3.6.1.4.1.9.9.314.1.4.1.1.57
CASForwardSignal1 = notApplicable2 = i13 = i24 = i35 = i46 = i57 = i68 = i79 = i810 = i911 = i1012 = i1113 = i1214 = i1315 = i1416 = i1517 = ii118 = ii219 = ii320 = ii421 = ii522 = ii623 = ii724 = ii825 = ii926 = ii1027 = ii1128 = ii1229 = ii1330 = ii1431 = ii1532 = iiI133 = iiI234 = iii335 = iii436 = iii537 = iii638 = iii739 = iii840 = iii941 = iii1042 = iii1143 = iii1244 = iii1345 = iii1446 = iii15This textual convention defines all possible Group I, II, and III Forward Signals in Signaling System R2. The Forward Group I signals represent the called numbers, calling party number and equipment requirements for the call. The Forward Group II signals are calling party's category signal sent by outgoing R2 registers or by outgoing international R2 registers in reply to the backward signals, and give whether national or international working applies. The Forward Group III are distinguished between DNIS and ANI digits.Reference: ITU-T recommendation Q.441 · Integer32
This object specifies a forward signal indicating that the call is being used for national data transmission. The default value is country specific.
ccasFwdRSDataTransInternational
1.3.6.1.4.1.9.9.314.1.4.1.1.58
CASForwardSignal1 = notApplicable2 = i13 = i24 = i35 = i46 = i57 = i68 = i79 = i810 = i911 = i1012 = i1113 = i1214 = i1315 = i1416 = i1517 = ii118 = ii219 = ii320 = ii421 = ii522 = ii623 = ii724 = ii825 = ii926 = ii1027 = ii1128 = ii1229 = ii1330 = ii1431 = ii1532 = iiI133 = iiI234 = iii335 = iii436 = iii537 = iii638 = iii739 = iii840 = iii941 = iii1042 = iii1143 = iii1244 = iii1345 = iii1446 = iii15This textual convention defines all possible Group I, II, and III Forward Signals in Signaling System R2. The Forward Group I signals represent the called numbers, calling party number and equipment requirements for the call. The Forward Group II signals are calling party's category signal sent by outgoing R2 registers or by outgoing international R2 registers in reply to the backward signals, and give whether national or international working applies. The Forward Group III are distinguished between DNIS and ANI digits.Reference: ITU-T recommendation Q.441 · Integer32
This object specifies a forward signal indicating that the call is being used for international data transmission. The default value is country specific. Reference: ITU-T Q440 - Specifications of signaling system R2 Interregister Signaling. Section 4.2.3.2 Forward signals.
ccasFwdRSOperNoFwdTransFacility
1.3.6.1.4.1.9.9.314.1.4.1.1.59
CASForwardSignal1 = notApplicable2 = i13 = i24 = i35 = i46 = i57 = i68 = i79 = i810 = i911 = i1012 = i1113 = i1214 = i1315 = i1416 = i1517 = ii118 = ii219 = ii320 = ii421 = ii522 = ii623 = ii724 = ii825 = ii926 = ii1027 = ii1128 = ii1229 = ii1330 = ii1431 = ii1532 = iiI133 = iiI234 = iii335 = iii436 = iii537 = iii638 = iii739 = iii840 = iii941 = iii1042 = iii1143 = iii1244 = iii1345 = iii1446 = iii15This textual convention defines all possible Group I, II, and III Forward Signals in Signaling System R2. The Forward Group I signals represent the called numbers, calling party number and equipment requirements for the call. The Forward Group II signals are calling party's category signal sent by outgoing R2 registers or by outgoing international R2 registers in reply to the backward signals, and give whether national or international working applies. The Forward Group III are distinguished between DNIS and ANI digits.Reference: ITU-T recommendation Q.441 · Integer32
This object specifies a forward signal indicating the call is being set up from a subscriber's line, operator's position or from maintenance equipment and no forward transfer signal will be used. The default value is country specific. Reference: ITU-T Q440 - Specifications of signaling system R2 Interregister Signaling. Section 4.2.3.2 Forward signals.
ccasFwdRSOperFwdTransFacility
1.3.6.1.4.1.9.9.314.1.4.1.1.60
CASForwardSignal1 = notApplicable2 = i13 = i24 = i35 = i46 = i57 = i68 = i79 = i810 = i911 = i1012 = i1113 = i1214 = i1315 = i1416 = i1517 = ii118 = ii219 = ii320 = ii421 = ii522 = ii623 = ii724 = ii825 = ii926 = ii1027 = ii1128 = ii1229 = ii1330 = ii1431 = ii1532 = iiI133 = iiI234 = iii335 = iii436 = iii537 = iii638 = iii739 = iii840 = iii941 = iii1042 = iii1143 = iii1244 = iii1345 = iii1446 = iii15This textual convention defines all possible Group I, II, and III Forward Signals in Signaling System R2. The Forward Group I signals represent the called numbers, calling party number and equipment requirements for the call. The Forward Group II signals are calling party's category signal sent by outgoing R2 registers or by outgoing international R2 registers in reply to the backward signals, and give whether national or international working applies. The Forward Group III are distinguished between DNIS and ANI digits.Reference: ITU-T recommendation Q.441 · Integer32
This object specifies a forward signal indicating the call is set up from an operator's position with possibility of recourse to the forward transfer facility. The default value is country specific. Reference: ITU-T Q440 - Specifications of signaling system R2 Interregister Signaling. Section 4.2.3.2 Forward signals.
ccasFwdRSSubsrcWithMeter
1.3.6.1.4.1.9.9.314.1.4.1.1.61
CASForwardSignal1 = notApplicable2 = i13 = i24 = i35 = i46 = i57 = i68 = i79 = i810 = i911 = i1012 = i1113 = i1214 = i1315 = i1416 = i1517 = ii118 = ii219 = ii320 = ii421 = ii522 = ii623 = ii724 = ii825 = ii926 = ii1027 = ii1128 = ii1229 = ii1330 = ii1431 = ii1532 = iiI133 = iiI234 = iii335 = iii436 = iii537 = iii638 = iii739 = iii840 = iii941 = iii1042 = iii1143 = iii1244 = iii1345 = iii1446 = iii15This textual convention defines all possible Group I, II, and III Forward Signals in Signaling System R2. The Forward Group I signals represent the called numbers, calling party number and equipment requirements for the call. The Forward Group II signals are calling party's category signal sent by outgoing R2 registers or by outgoing international R2 registers in reply to the backward signals, and give whether national or international working applies. The Forward Group III are distinguished between DNIS and ANI digits.Reference: ITU-T recommendation Q.441 · Integer32
This object specifies a forward signal indicating the subscribers have a meter. The default value is country specific.
ccasFwdRSSubsrcWithIDD
1.3.6.1.4.1.9.9.314.1.4.1.1.62
CASForwardSignal1 = notApplicable2 = i13 = i24 = i35 = i46 = i57 = i68 = i79 = i810 = i911 = i1012 = i1113 = i1214 = i1315 = i1416 = i1517 = ii118 = ii219 = ii320 = ii421 = ii522 = ii623 = ii724 = ii825 = ii926 = ii1027 = ii1128 = ii1229 = ii1330 = ii1431 = ii1532 = iiI133 = iiI234 = iii335 = iii436 = iii537 = iii638 = iii739 = iii840 = iii941 = iii1042 = iii1143 = iii1244 = iii1345 = iii1446 = iii15This textual convention defines all possible Group I, II, and III Forward Signals in Signaling System R2. The Forward Group I signals represent the called numbers, calling party number and equipment requirements for the call. The Forward Group II signals are calling party's category signal sent by outgoing R2 registers or by outgoing international R2 registers in reply to the backward signals, and give whether national or international working applies. The Forward Group III are distinguished between DNIS and ANI digits.Reference: ITU-T recommendation Q.441 · Integer32
This object specifies a forward signal indicating the subscribers have an International Direct Dial facility. The default value is country specific.
This object is used to interpret the meaning of the first ANI digit for both receiving and transmitting when sent and received. .firstANIDigit: First ANI digit. .aniAvailableOrNot: Indication as to whether ANI is available or not. .subscriberCategory: Subscriber category. The default value is country specific.
ccasRSGetValueFromValidIndex
1.3.6.1.4.1.9.9.314.1.4.1.1.64
Unsigned32 (1..400)
This object specifies the entry index from which values for the objects not specified in the set operation will be copied over from. If both the country index and this object are specified, this object takes precedence. If this object is not specified for an entry, it defaults to the entry index.
ccasRSSeqInfCollect
1.3.6.1.4.1.9.9.314.1.4.1.1.65
SnmpAdminStringAn octet string containing administrative information, preferably in human-readable form.
To facilitate internationalization, this information is represented using the ISO/IEC IS 10646-1 character set, encoded as an octet string using the UTF-8 transformation format described in [RFC2279].
Since additional code points are added by amendments to the 10646 standard from time to time, implementations must be prepared to encounter any code point from 0x00000000 to 0x7fffffff. Byte sequences that do not correspond to the valid UTF-8 encoding of a code point or are outside this range are prohibited.
The use of control codes should be avoided.
When it is necessary to represent a newline, the control code sequence CR LF should be used.
The use of leading or trailing white space should be avoided.
For code points not directly supported by user interface hardware or software, an alternative means of entry and display, such as hexadecimal, may be provided.
For information encoded in 7-bit US-ASCII, the UTF-8 encoding is identical to the US-ASCII encoding.
UTF-8 may require multiple bytes to represent a single character / code point; thus the length of this object in octets may be different from the number of characters encoded. Similarly, size constraints refer to the number of encoded octets, not the number of characters represented by an encoding.
Note that when this TC is used for an object that is used or envisioned to be used as an index, then a SIZE restriction MUST be specified so that the number of sub-identifiers for any object instance does not exceed the limit of 128, as defined by [RFC3416].
Note that the size of an SnmpAdminString object is measured in octets, not characters. SIZE (1..255) · OCTET STRING · hint 255t
This object determines the sequence in which information will be gathered by the incoming register.
Only a set of predefined characters can be used in the octet string notation of the sequence. The special character and the alphabet strings allowed are listed below:
'/' - Separator between different elements of information that should be collected. - Indicates how many digits of the following information element should be collected before switching to collecting the next information element. Number always precedes one of the information elements such as D or A. If no number is specified, all of the digits for that information element are collected before fetching digits for next info element.
di - DNIS/Destination number/dialed number/called number.
si - ANIS/Source number/calling number.
sc - Subscriber Category.
cc - Country Code.
es - Echo Suppression Information.
noc - Nature of Circuit.
disc - Discriminator Digit. The default value is country specific.
This object specifies the information element that will take precedence when being sent out as the first forward register signal for an outgoing call. This can be either the first DNIS digit, indication that country code follows or the language/discriminator digit. When all the above information is available at the GW, this object determines which one will be sent out first for each option, list is from most preferred to least preferred. .dniscclangdisc: First DNIS, country code indication, language/discriminator. .dnislangdisccc: First DNIS, language/discriminator, country code indication. .cclangdiscdnis: Country code indication, language/ discriminator, first DNIS. .ccdnislangdisc: Country code indication, first DNIS, language/discriminator. .langdiscccdnis: Language/discriminator, country code indication, first DNIS. .langdiscdniscc: Language/discriminator, first DNIS, country code indication. The default value is country specific.
ccasRSRowStatus
1.3.6.1.4.1.9.9.314.1.4.1.1.67
RowStatus1 = active2 = notInService3 = notReady4 = createAndGo5 = createAndWait6 = destroyThe RowStatus textual convention is used to manage the creation and deletion of conceptual rows, and is used as the value of the SYNTAX clause for the status column of a conceptual row (as described in Section 7.7.1 of [2].)
The status column has six defined values:
- `active', which indicates that the conceptual row is available for use by the managed device;
- `notInService', which indicates that the conceptual row exists in the agent, but is unavailable for use by the managed device (see NOTE below); 'notInService' has no implication regarding the internal consistency of the row, availability of resources, or consistency with the current state of the managed device;
- `notReady', which indicates that the conceptual row exists in the agent, but is missing information necessary in order to be available for use by the managed device (i.e., one or more required columns in the conceptual row have not been instanciated);
- `createAndGo', which is supplied by a management station wishing to create a new instance of a conceptual row and to have its status automatically set to active, making it available for use by the managed device;
- `createAndWait', which is supplied by a management station wishing to create a new instance of a conceptual row (but not make it available for use by the managed device); and, - `destroy', which is supplied by a management station wishing to delete all of the instances associated with an existing conceptual row.
Whereas five of the six values (all except `notReady') may be specified in a management protocol set operation, only three values will be returned in response to a management
protocol retrieval operation: `notReady', `notInService' or
`active'. That is, when queried, an existing conceptual row
has only three states: it is either available for use by
the managed device (the status column has value `active'); it is not available for use by the managed device, though the agent has sufficient information to attempt to make it so (the status column has value `notInService'); or, it is not available for use by the managed device, and an attempt to make it so would fail because the agent has insufficient information (the state column has value `notReady').
NOTE WELL
This textual convention may be used for a MIB table, irrespective of whether the values of that table's conceptual rows are able to be modified while it is active, or whether its conceptual rows must be taken out of service in order to be modified. That is, it is the responsibility of the DESCRIPTION clause of the status column to specify whether the status column must not be `active' in order for the value of some other column of the same conceptual row to be modified. If such a specification is made, affected columns may be changed by an SNMP set PDU if the RowStatus would not be equal to `active' either immediately before or after processing the PDU. In other words, if the PDU also contained a varbind that would change the RowStatus value, the column in question may be changed if the RowStatus was not equal to `active' as the PDU was received, or if the varbind sets the status to a value other than 'active'.
Also note that whenever any elements of a row exist, the RowStatus column must also exist.
To summarize the effect of having a conceptual row with a status column having a SYNTAX clause value of RowStatus, consider the following state diagram:
STATE +--------------+-----------+-------------+-------------
| A | B | C | D
| |status col.|status column|
|status column | is | is |status column
ACTION |does not exist| notReady | notInService| is active
--------------+--------------+-----------+-------------+-------------
set status |noError ->D|inconsist- |inconsistent-|inconsistent-
column to | or | entValue| Value| Value
createAndGo |inconsistent- | | |
| Value| | |
--------------+--------------+-----------+-------------+-------------
set status |noError see 1|inconsist- |inconsistent-|inconsistent-
column to | or | entValue| Value| Value
createAndWait |wrongValue | | |
--------------+--------------+-----------+-------------+-------------
set status |inconsistent- |inconsist- |noError |noError
column to | Value| entValue| |
active | | | |
| | or | |
| | | |
| |see 2 ->D|see 8 ->D| ->D
--------------+--------------+-----------+-------------+-------------
set status |inconsistent- |inconsist- |noError |noError ->C
column to | Value| entValue| |
notInService | | | |
| | or | | or
| | | |
| |see 3 ->C| ->C|see 6
--------------+--------------+-----------+-------------+-------------
set status |noError |noError |noError |noError ->A
column to | | | | or
destroy | ->A| ->A| ->A|see 7
--------------+--------------+-----------+-------------+-------------
set any other |see 4 |noError |noError |see 5
column to some| | | |
value | | see 1| ->C| ->D
--------------+--------------+-----------+-------------+-------------
(1) goto B or C, depending on information available to the agent.
(2) if other variable bindings included in the same PDU, provide values for all columns which are missing but required, and all columns have acceptable values, then return noError and goto D.
(3) if other variable bindings included in the same PDU, provide legal values for all columns which are missing but required, then return noError and goto C.
(4) at the discretion of the agent, the return value may be either:
inconsistentName: because the agent does not choose to
create such an instance when the corresponding RowStatus instance does not exist, or
inconsistentValue: if the supplied value is
inconsistent with the state of some other MIB object's value, or
noError: because the agent chooses to create the instance.
If noError is returned, then the instance of the status column must also be created, and the new state is B or C, depending on the information available to the agent. If inconsistentName or inconsistentValue is returned, the row remains in state A.
(5) depending on the MIB definition for the column/table, either noError or inconsistentValue may be returned.
(6) the return value can indicate one of the following errors:
wrongValue: because the agent does not support notInService (e.g., an agent which does not support createAndWait), or
inconsistentValue: because the agent is unable to take the row out of service at this time, perhaps because it is in use and cannot be de-activated.
(7) the return value can indicate the following error:
inconsistentValue: because the agent is unable to remove the row at this time, perhaps because it is in use and cannot be de-activated.
(8) the transition to D can fail, e.g., if the values of the conceptual row are inconsistent, then the error code would be inconsistentValue.
NOTE: Other processing of (this and other varbinds of) the set request may result in a response other than noError being returned, e.g., wrongValue, noCreation, etc.
Conceptual Row Creation
There are four potential interactions when creating a
conceptual row: selecting an instance-identifier which is
not in use; creating the conceptual row; initializing any objects for which the agent does not supply a default; and, making the conceptual row available for use by the managed device.
Interaction 1: Selecting an Instance-Identifier
The algorithm used to select an instance-identifier varies for each conceptual row. In some cases, the instance- identifier is semantically significant, e.g., the destination address of a route, and a management station selects the instance-identifier according to the semantics.
In other cases, the instance-identifier is used solely to distinguish conceptual rows, and a management station without specific knowledge of the conceptual row might examine the instances present in order to determine an unused instance-identifier. (This approach may be used, but it is often highly sub-optimal; however, it is also a questionable practice for a naive management station to attempt conceptual row creation.)
Alternately, the MIB module which defines the conceptual row might provide one or more objects which provide assistance in determining an unused instance-identifier. For example, if the conceptual row is indexed by an integer-value, then an object having an integer-valued SYNTAX clause might be defined for such a purpose, allowing a management station to issue a management protocol retrieval operation. In order to avoid unnecessary collisions between competing management stations, `adjacent' retrievals of this object should be different.
Finally, the management station could select a pseudo-random number to use as the index. In the event that this index
was already in use and an inconsistentValue was returned in response to the management protocol set operation, the management station should simply select a new pseudo-random number and retry the operation.
A MIB designer should choose between the two latter algorithms based on the size of the table (and therefore the efficiency of each algorithm). For tables in which a large number of entries are expected, it is recommended that a MIB object be defined that returns an acceptable index for creation. For tables with small numbers of entries, it is recommended that the latter pseudo-random index mechanism be used.
Interaction 2: Creating the Conceptual Row
Once an unused instance-identifier has been selected, the management station determines if it wishes to create and activate the conceptual row in one transaction or in a negotiated set of interactions.
Interaction 2a: Creating and Activating the Conceptual Row
The management station must first determine the column requirements, i.e., it must determine those columns for which it must or must not provide values. Depending on the complexity of the table and the management station's knowledge of the agent's capabilities, this determination can be made locally by the management station. Alternately, the management station issues a management protocol get operation to examine all columns in the conceptual row that it wishes to create. In response, for each column, there are three possible outcomes:
- a value is returned, indicating that some other management station has already created this conceptual row. We return to interaction 1.
- the exception `noSuchInstance' is returned, indicating that the agent implements the object-type associated with this column, and that this column in at least one conceptual row would be accessible in the MIB view used by the retrieval were it to exist. For those columns to which the agent provides read-create access, the `noSuchInstance' exception tells the management station that it should supply a value for this column when the conceptual row is to be created.
- the exception `noSuchObject' is returned, indicating that the agent does not implement the object-type associated with this column or that there is no conceptual row for which this column would be accessible in the MIB view used by the retrieval. As such, the management station can not issue any management protocol set operations to create an instance of this column.
Once the column requirements have been determined, a management protocol set operation is accordingly issued. This operation also sets the new instance of the status column to `createAndGo'.
When the agent processes the set operation, it verifies that it has sufficient information to make the conceptual row available for use by the managed device. The information
available to the agent is provided by two sources: the
management protocol set operation which creates the conceptual row, and, implementation-specific defaults supplied by the agent (note that an agent must provide implementation-specific defaults for at least those objects which it implements as read-only). If there is sufficient information available, then the conceptual row is created, a `noError' response is returned, the status column is set to `active', and no further interactions are necessary (i.e., interactions 3 and 4 are skipped). If there is insufficient information, then the conceptual row is not created, and the set operation fails with an error of `inconsistentValue'. On this error, the management station can issue a management protocol retrieval operation to determine if this was because it failed to specify a value for a required column, or, because the selected instance of the status column already existed. In the latter case, we return to interaction 1. In the former case, the management station can re-issue the set operation with the additional information, or begin interaction 2 again using `createAndWait' in order to negotiate creation of the conceptual row.
NOTE WELL
Regardless of the method used to determine the column requirements, it is possible that the management station might deem a column necessary when, in fact, the agent will not allow that particular columnar instance to be created or written. In this case, the management protocol set operation will fail with an error such as `noCreation' or `notWritable'. In this case, the management station decides whether it needs to be able to set a value for that particular columnar instance. If not, the management station re-issues the management protocol set operation, but without setting a value for that particular columnar instance; otherwise, the management station aborts the row creation algorithm.
Interaction 2b: Negotiating the Creation of the Conceptual Row
The management station issues a management protocol set operation which sets the desired instance of the status column to `createAndWait'. If the agent is unwilling to process a request of this sort, the set operation fails with an error of `wrongValue'. (As a consequence, such an agent must be prepared to accept a single management protocol set operation, i.e., interaction 2a above, containing all of the
columns indicated by its column requirements.) Otherwise,
the conceptual row is created, a `noError' response is returned, and the status column is immediately set to either `notInService' or `notReady', depending on whether it has sufficient information to (attempt to) make the conceptual row available for use by the managed device. If there is sufficient information available, then the status column is set to `notInService'; otherwise, if there is insufficient information, then the status column is set to `notReady'. Regardless, we proceed to interaction 3.
Interaction 3: Initializing non-defaulted Objects
The management station must now determine the column requirements. It issues a management protocol get operation to examine all columns in the created conceptual row. In the response, for each column, there are three possible outcomes:
- a value is returned, indicating that the agent implements the object-type associated with this column and had sufficient information to provide a value. For those columns to which the agent provides read-create access (and for which the agent allows their values to be changed after their creation), a value return tells the management station that it may issue additional management protocol set operations, if it desires, in order to change the value associated with this column.
- the exception `noSuchInstance' is returned, indicating that the agent implements the object-type associated with this column, and that this column in at least one conceptual row would be accessible in the MIB view used by the retrieval were it to exist. However, the agent does not have sufficient information to provide a value, and until a value is provided, the conceptual row may not be made available for use by the managed device. For those columns to which the agent provides read-create access, the `noSuchInstance' exception tells the management station that it must issue additional management protocol set operations, in order to provide a value associated with this column.
- the exception `noSuchObject' is returned, indicating that the agent does not implement the object-type associated with this column or that there is no conceptual row for which this column would be accessible in the MIB view used by the retrieval. As such, the management station can not issue any management protocol set operations to create an instance of this column.
If the value associated with the status column is `notReady', then the management station must first deal with all `noSuchInstance' columns, if any. Having done so, the value of the status column becomes `notInService', and we proceed to interaction 4.
Interaction 4: Making the Conceptual Row Available
Once the management station is satisfied with the values associated with the columns of the conceptual row, it issues a management protocol set operation to set the status column to `active'. If the agent has sufficient information to make the conceptual row available for use by the managed device, the management protocol set operation succeeds (a `noError' response is returned). Otherwise, the management protocol set operation fails with an error of `inconsistentValue'.
NOTE WELL
A conceptual row having a status column with value `notInService' or `notReady' is unavailable to the managed device. As such, it is possible for the managed device to create its own instances during the time between the management protocol set operation which sets the status column to `createAndWait' and the management protocol set operation which sets the status column to `active'. In this case, when the management protocol set operation is issued to set the status column to `active', the values held in the agent supersede those used by the managed device.
If the management station is prevented from setting the status column to `active' (e.g., due to management station or network failure) the conceptual row will be left in the `notInService' or `notReady' state, consuming resources indefinitely. The agent must detect conceptual rows that have been in either state for an abnormally long period of time and remove them. It is the responsibility of the DESCRIPTION clause of the status column to indicate what an abnormally long period of time would be. This period of time should be long enough to allow for human response time (including `think time') between the creation of the conceptual row and the setting of the status to `active'. In the absence of such information in the DESCRIPTION clause, it is suggested that this period be approximately 5 minutes in length. This removal action applies not only to newly-created rows, but also to previously active rows which are set to, and left in, the notInService state for a prolonged period exceeding that which is considered normal for such a conceptual row.
Conceptual Row Suspension
When a conceptual row is `active', the management station may issue a management protocol set operation which sets the instance of the status column to `notInService'. If the agent is unwilling to do so, the set operation fails with an error of `wrongValue' or `inconsistentValue'. Otherwise, the conceptual row is taken out of service, and a `noError' response is returned. It is the responsibility of the DESCRIPTION clause of the status column to indicate under what circumstances the status column should be taken out of service (e.g., in order for the value of some other column of the same conceptual row to be modified).
Conceptual Row Deletion
For deletion of conceptual rows, a management protocol set operation is issued which sets the instance of the status column to `destroy'. This request may be made regardless of the current value of the status column (e.g., it is possible to delete conceptual rows which are either `notReady',
`notInService' or `active'.) If the operation succeeds,
then all instances associated with the conceptual row are immediately removed. · Integer32
This object is used for adding, modifying, and deleting the entries from the ccasRegisterSignalTable. A default entry with index value 1 is created at initialization, and it cannot be modified or deleted.
ccasIfExtRegSignalTimerTable
1.3.6.1.4.1.9.9.314.1.5.2
Index: cmgwIndex · ccasRSTIndex
This table defines the timers related to the CAS register signals.
An index that uniquely identifies an entry in the cMediaGwTable.
ccasRSTIndex
1.3.6.1.4.1.9.9.314.1.5.2.1.1
Unsigned32 (1..65535)
An arbitrary index that uniquely identifies a entry in the ccasIfExtRegSignalTimerTable. The index of 1 is reserved for the default entry.
ccasRSTAnswerSigTimer
1.3.6.1.4.1.9.9.314.1.5.2.1.2
Unsigned32 (0..65535) · seconds
This object specifies the timer that is started after having sent out the last forward digit within which the backward register answer signal should be received.
Normally it would be same as the compelled forward tone on timer, ccasRSTCompelledFwdToneOnTimer, but in some country variants, this could be different.
ccasRSTCompelledFwdToneOnTimer
1.3.6.1.4.1.9.9.314.1.5.2.1.3
Unsigned32 (0..65535) · seconds
This object specifies the period for which the forward digit tone stays on, waiting for a reception of the backward signal in compelled signaling. This timer is started after the forward signal digit is turned on. Reference: ITU Q.476 Abnormal Release of Outgoing and Incoming R2 Register, section 5.5.1.1
ccasRSTCompelledFwdToneOffTimer
1.3.6.1.4.1.9.9.314.1.5.2.1.4
Unsigned32 (0..65535) · seconds
This object specifies the period for which the forward signal digit is turned off in compelled signaling. This timer is started after the backward signal is received and after the forward signal digit is turned off on the outgoing interface. Reference: ITU Q.476 Abnormal Release of Outgoing and Incoming R2 Register, section 5.5.1.2
ccasRSTCompelledBwdToneOnTimer
1.3.6.1.4.1.9.9.314.1.5.2.1.5
Unsigned32 (0..65535) · seconds
This object specifies the period for which the backward signal stays on waiting for the forward digit signal to go off in compelled signaling. This timer is started after the backward signal is sent in response to the forward signal digit.
ccasRSTOutFwdPulseOnTimer
1.3.6.1.4.1.9.9.314.1.5.2.1.6
Unsigned32 (0..65535) · milliseconds
This object specifies the timer is started after the forward digit tone is sent out. Tone is turned off after the timer expires. This object applies to outgoing R2 registers where the forward signals are sent as pulses for non-compelled signaling.
ccasRSTOutFwdPulseOffTimer
1.3.6.1.4.1.9.9.314.1.5.2.1.7
Unsigned32 (0..65535) · milliseconds
This object specifies the interval between two forward pulse tones. This object applies to outgoing R2 registers where the forward signals are sent as pulses for non-compelled signaling.
ccasRSTIncFwdPulseOnTimer
1.3.6.1.4.1.9.9.314.1.5.2.1.8
Unsigned32 (0..65535) · milliseconds
This object specifies the period for which the forward digit pulse can be on. The timer is started after the forward digit signal is received, and stays on until the forward digit being received is turned off. This object applies to incoming R2 registers where the forward signals are received as pulses for non-compelled signaling.
ccasRSTBwdPulseOnTimer
1.3.6.1.4.1.9.9.314.1.5.2.1.9
Unsigned32 (0..65535) · milliseconds
This value specifies the period for which the backward pulse is on before it is turned off. This object applies to incoming R2 registers where the forward signals are received either continuously or as a pulse but the backward signals are sent as a pulse in semi-compelled or non-compelled signaling mode respectively.
It also applies to compelled signaling where certain backward signals are sent as pulses. Reference: ITU-T Q.442 Requirements Relating to Transmission Coditions, section 4.3
ccasRSTIncomingRegSigDuration
1.3.6.1.4.1.9.9.314.1.5.2.1.10
Unsigned32 (0..65535) · seconds
This object specifies the duration within which the register signaling should complete for an incoming call. This timer is started as soon as the first forward register signal is received.
ccasRSTOutgoingRegSigDuration
1.3.6.1.4.1.9.9.314.1.5.2.1.11
Unsigned32 (0..65535) · seconds
This object specifies the duration within which the register signaling should complete for an outgoing call. This timer is started when the first forward register signal is sent out.
ccasRSTCalledPartyInterDigTimer
1.3.6.1.4.1.9.9.314.1.5.2.1.12
Unsigned32 (0..65535) · seconds
This object specifies the interdigit timer for the collection of called party number (DNIS) for R2 signaling when there is no digit map associated with the digits being gathered. This timer is started after receiving each called digit, and expiry of this timer indicates that there are no more called party digits to receive. Reference: ITU-T Q.476 Abnormal Release of Outgoing and Incoming R2 Register, section 5.5.2
ccasRSTRowStatus
1.3.6.1.4.1.9.9.314.1.5.2.1.13
RowStatus1 = active2 = notInService3 = notReady4 = createAndGo5 = createAndWait6 = destroyThe RowStatus textual convention is used to manage the creation and deletion of conceptual rows, and is used as the value of the SYNTAX clause for the status column of a conceptual row (as described in Section 7.7.1 of [2].)
The status column has six defined values:
- `active', which indicates that the conceptual row is available for use by the managed device;
- `notInService', which indicates that the conceptual row exists in the agent, but is unavailable for use by the managed device (see NOTE below); 'notInService' has no implication regarding the internal consistency of the row, availability of resources, or consistency with the current state of the managed device;
- `notReady', which indicates that the conceptual row exists in the agent, but is missing information necessary in order to be available for use by the managed device (i.e., one or more required columns in the conceptual row have not been instanciated);
- `createAndGo', which is supplied by a management station wishing to create a new instance of a conceptual row and to have its status automatically set to active, making it available for use by the managed device;
- `createAndWait', which is supplied by a management station wishing to create a new instance of a conceptual row (but not make it available for use by the managed device); and, - `destroy', which is supplied by a management station wishing to delete all of the instances associated with an existing conceptual row.
Whereas five of the six values (all except `notReady') may be specified in a management protocol set operation, only three values will be returned in response to a management
protocol retrieval operation: `notReady', `notInService' or
`active'. That is, when queried, an existing conceptual row
has only three states: it is either available for use by
the managed device (the status column has value `active'); it is not available for use by the managed device, though the agent has sufficient information to attempt to make it so (the status column has value `notInService'); or, it is not available for use by the managed device, and an attempt to make it so would fail because the agent has insufficient information (the state column has value `notReady').
NOTE WELL
This textual convention may be used for a MIB table, irrespective of whether the values of that table's conceptual rows are able to be modified while it is active, or whether its conceptual rows must be taken out of service in order to be modified. That is, it is the responsibility of the DESCRIPTION clause of the status column to specify whether the status column must not be `active' in order for the value of some other column of the same conceptual row to be modified. If such a specification is made, affected columns may be changed by an SNMP set PDU if the RowStatus would not be equal to `active' either immediately before or after processing the PDU. In other words, if the PDU also contained a varbind that would change the RowStatus value, the column in question may be changed if the RowStatus was not equal to `active' as the PDU was received, or if the varbind sets the status to a value other than 'active'.
Also note that whenever any elements of a row exist, the RowStatus column must also exist.
To summarize the effect of having a conceptual row with a status column having a SYNTAX clause value of RowStatus, consider the following state diagram:
STATE +--------------+-----------+-------------+-------------
| A | B | C | D
| |status col.|status column|
|status column | is | is |status column
ACTION |does not exist| notReady | notInService| is active
--------------+--------------+-----------+-------------+-------------
set status |noError ->D|inconsist- |inconsistent-|inconsistent-
column to | or | entValue| Value| Value
createAndGo |inconsistent- | | |
| Value| | |
--------------+--------------+-----------+-------------+-------------
set status |noError see 1|inconsist- |inconsistent-|inconsistent-
column to | or | entValue| Value| Value
createAndWait |wrongValue | | |
--------------+--------------+-----------+-------------+-------------
set status |inconsistent- |inconsist- |noError |noError
column to | Value| entValue| |
active | | | |
| | or | |
| | | |
| |see 2 ->D|see 8 ->D| ->D
--------------+--------------+-----------+-------------+-------------
set status |inconsistent- |inconsist- |noError |noError ->C
column to | Value| entValue| |
notInService | | | |
| | or | | or
| | | |
| |see 3 ->C| ->C|see 6
--------------+--------------+-----------+-------------+-------------
set status |noError |noError |noError |noError ->A
column to | | | | or
destroy | ->A| ->A| ->A|see 7
--------------+--------------+-----------+-------------+-------------
set any other |see 4 |noError |noError |see 5
column to some| | | |
value | | see 1| ->C| ->D
--------------+--------------+-----------+-------------+-------------
(1) goto B or C, depending on information available to the agent.
(2) if other variable bindings included in the same PDU, provide values for all columns which are missing but required, and all columns have acceptable values, then return noError and goto D.
(3) if other variable bindings included in the same PDU, provide legal values for all columns which are missing but required, then return noError and goto C.
(4) at the discretion of the agent, the return value may be either:
inconsistentName: because the agent does not choose to
create such an instance when the corresponding RowStatus instance does not exist, or
inconsistentValue: if the supplied value is
inconsistent with the state of some other MIB object's value, or
noError: because the agent chooses to create the instance.
If noError is returned, then the instance of the status column must also be created, and the new state is B or C, depending on the information available to the agent. If inconsistentName or inconsistentValue is returned, the row remains in state A.
(5) depending on the MIB definition for the column/table, either noError or inconsistentValue may be returned.
(6) the return value can indicate one of the following errors:
wrongValue: because the agent does not support notInService (e.g., an agent which does not support createAndWait), or
inconsistentValue: because the agent is unable to take the row out of service at this time, perhaps because it is in use and cannot be de-activated.
(7) the return value can indicate the following error:
inconsistentValue: because the agent is unable to remove the row at this time, perhaps because it is in use and cannot be de-activated.
(8) the transition to D can fail, e.g., if the values of the conceptual row are inconsistent, then the error code would be inconsistentValue.
NOTE: Other processing of (this and other varbinds of) the set request may result in a response other than noError being returned, e.g., wrongValue, noCreation, etc.
Conceptual Row Creation
There are four potential interactions when creating a
conceptual row: selecting an instance-identifier which is
not in use; creating the conceptual row; initializing any objects for which the agent does not supply a default; and, making the conceptual row available for use by the managed device.
Interaction 1: Selecting an Instance-Identifier
The algorithm used to select an instance-identifier varies for each conceptual row. In some cases, the instance- identifier is semantically significant, e.g., the destination address of a route, and a management station selects the instance-identifier according to the semantics.
In other cases, the instance-identifier is used solely to distinguish conceptual rows, and a management station without specific knowledge of the conceptual row might examine the instances present in order to determine an unused instance-identifier. (This approach may be used, but it is often highly sub-optimal; however, it is also a questionable practice for a naive management station to attempt conceptual row creation.)
Alternately, the MIB module which defines the conceptual row might provide one or more objects which provide assistance in determining an unused instance-identifier. For example, if the conceptual row is indexed by an integer-value, then an object having an integer-valued SYNTAX clause might be defined for such a purpose, allowing a management station to issue a management protocol retrieval operation. In order to avoid unnecessary collisions between competing management stations, `adjacent' retrievals of this object should be different.
Finally, the management station could select a pseudo-random number to use as the index. In the event that this index
was already in use and an inconsistentValue was returned in response to the management protocol set operation, the management station should simply select a new pseudo-random number and retry the operation.
A MIB designer should choose between the two latter algorithms based on the size of the table (and therefore the efficiency of each algorithm). For tables in which a large number of entries are expected, it is recommended that a MIB object be defined that returns an acceptable index for creation. For tables with small numbers of entries, it is recommended that the latter pseudo-random index mechanism be used.
Interaction 2: Creating the Conceptual Row
Once an unused instance-identifier has been selected, the management station determines if it wishes to create and activate the conceptual row in one transaction or in a negotiated set of interactions.
Interaction 2a: Creating and Activating the Conceptual Row
The management station must first determine the column requirements, i.e., it must determine those columns for which it must or must not provide values. Depending on the complexity of the table and the management station's knowledge of the agent's capabilities, this determination can be made locally by the management station. Alternately, the management station issues a management protocol get operation to examine all columns in the conceptual row that it wishes to create. In response, for each column, there are three possible outcomes:
- a value is returned, indicating that some other management station has already created this conceptual row. We return to interaction 1.
- the exception `noSuchInstance' is returned, indicating that the agent implements the object-type associated with this column, and that this column in at least one conceptual row would be accessible in the MIB view used by the retrieval were it to exist. For those columns to which the agent provides read-create access, the `noSuchInstance' exception tells the management station that it should supply a value for this column when the conceptual row is to be created.
- the exception `noSuchObject' is returned, indicating that the agent does not implement the object-type associated with this column or that there is no conceptual row for which this column would be accessible in the MIB view used by the retrieval. As such, the management station can not issue any management protocol set operations to create an instance of this column.
Once the column requirements have been determined, a management protocol set operation is accordingly issued. This operation also sets the new instance of the status column to `createAndGo'.
When the agent processes the set operation, it verifies that it has sufficient information to make the conceptual row available for use by the managed device. The information
available to the agent is provided by two sources: the
management protocol set operation which creates the conceptual row, and, implementation-specific defaults supplied by the agent (note that an agent must provide implementation-specific defaults for at least those objects which it implements as read-only). If there is sufficient information available, then the conceptual row is created, a `noError' response is returned, the status column is set to `active', and no further interactions are necessary (i.e., interactions 3 and 4 are skipped). If there is insufficient information, then the conceptual row is not created, and the set operation fails with an error of `inconsistentValue'. On this error, the management station can issue a management protocol retrieval operation to determine if this was because it failed to specify a value for a required column, or, because the selected instance of the status column already existed. In the latter case, we return to interaction 1. In the former case, the management station can re-issue the set operation with the additional information, or begin interaction 2 again using `createAndWait' in order to negotiate creation of the conceptual row.
NOTE WELL
Regardless of the method used to determine the column requirements, it is possible that the management station might deem a column necessary when, in fact, the agent will not allow that particular columnar instance to be created or written. In this case, the management protocol set operation will fail with an error such as `noCreation' or `notWritable'. In this case, the management station decides whether it needs to be able to set a value for that particular columnar instance. If not, the management station re-issues the management protocol set operation, but without setting a value for that particular columnar instance; otherwise, the management station aborts the row creation algorithm.
Interaction 2b: Negotiating the Creation of the Conceptual Row
The management station issues a management protocol set operation which sets the desired instance of the status column to `createAndWait'. If the agent is unwilling to process a request of this sort, the set operation fails with an error of `wrongValue'. (As a consequence, such an agent must be prepared to accept a single management protocol set operation, i.e., interaction 2a above, containing all of the
columns indicated by its column requirements.) Otherwise,
the conceptual row is created, a `noError' response is returned, and the status column is immediately set to either `notInService' or `notReady', depending on whether it has sufficient information to (attempt to) make the conceptual row available for use by the managed device. If there is sufficient information available, then the status column is set to `notInService'; otherwise, if there is insufficient information, then the status column is set to `notReady'. Regardless, we proceed to interaction 3.
Interaction 3: Initializing non-defaulted Objects
The management station must now determine the column requirements. It issues a management protocol get operation to examine all columns in the created conceptual row. In the response, for each column, there are three possible outcomes:
- a value is returned, indicating that the agent implements the object-type associated with this column and had sufficient information to provide a value. For those columns to which the agent provides read-create access (and for which the agent allows their values to be changed after their creation), a value return tells the management station that it may issue additional management protocol set operations, if it desires, in order to change the value associated with this column.
- the exception `noSuchInstance' is returned, indicating that the agent implements the object-type associated with this column, and that this column in at least one conceptual row would be accessible in the MIB view used by the retrieval were it to exist. However, the agent does not have sufficient information to provide a value, and until a value is provided, the conceptual row may not be made available for use by the managed device. For those columns to which the agent provides read-create access, the `noSuchInstance' exception tells the management station that it must issue additional management protocol set operations, in order to provide a value associated with this column.
- the exception `noSuchObject' is returned, indicating that the agent does not implement the object-type associated with this column or that there is no conceptual row for which this column would be accessible in the MIB view used by the retrieval. As such, the management station can not issue any management protocol set operations to create an instance of this column.
If the value associated with the status column is `notReady', then the management station must first deal with all `noSuchInstance' columns, if any. Having done so, the value of the status column becomes `notInService', and we proceed to interaction 4.
Interaction 4: Making the Conceptual Row Available
Once the management station is satisfied with the values associated with the columns of the conceptual row, it issues a management protocol set operation to set the status column to `active'. If the agent has sufficient information to make the conceptual row available for use by the managed device, the management protocol set operation succeeds (a `noError' response is returned). Otherwise, the management protocol set operation fails with an error of `inconsistentValue'.
NOTE WELL
A conceptual row having a status column with value `notInService' or `notReady' is unavailable to the managed device. As such, it is possible for the managed device to create its own instances during the time between the management protocol set operation which sets the status column to `createAndWait' and the management protocol set operation which sets the status column to `active'. In this case, when the management protocol set operation is issued to set the status column to `active', the values held in the agent supersede those used by the managed device.
If the management station is prevented from setting the status column to `active' (e.g., due to management station or network failure) the conceptual row will be left in the `notInService' or `notReady' state, consuming resources indefinitely. The agent must detect conceptual rows that have been in either state for an abnormally long period of time and remove them. It is the responsibility of the DESCRIPTION clause of the status column to indicate what an abnormally long period of time would be. This period of time should be long enough to allow for human response time (including `think time') between the creation of the conceptual row and the setting of the status to `active'. In the absence of such information in the DESCRIPTION clause, it is suggested that this period be approximately 5 minutes in length. This removal action applies not only to newly-created rows, but also to previously active rows which are set to, and left in, the notInService state for a prolonged period exceeding that which is considered normal for such a conceptual row.
Conceptual Row Suspension
When a conceptual row is `active', the management station may issue a management protocol set operation which sets the instance of the status column to `notInService'. If the agent is unwilling to do so, the set operation fails with an error of `wrongValue' or `inconsistentValue'. Otherwise, the conceptual row is taken out of service, and a `noError' response is returned. It is the responsibility of the DESCRIPTION clause of the status column to indicate under what circumstances the status column should be taken out of service (e.g., in order for the value of some other column of the same conceptual row to be modified).
Conceptual Row Deletion
For deletion of conceptual rows, a management protocol set operation is issued which sets the instance of the status column to `destroy'. This request may be made regardless of the current value of the status column (e.g., it is possible to delete conceptual rows which are either `notReady',
`notInService' or `active'.) If the operation succeeds,
then all instances associated with the conceptual row are immediately removed. · Integer32
This object is used for adding, deleting and modifying the entries from the ccasIfExtRegSignalTimerTable. A default entry with index value 1 is created at initialization, and it can not be modified or deleted.
ccasIfExtGeneralConfigTable
1.3.6.1.4.1.9.9.314.1.6.1
Index: cmgwIndex · ccasGCnfIndex
This table defines the general parameters related to CAS variant.
This object specifies a glare policy. It is used only if CAS DS0 directionality of the endpoint is bidirectional, and is applicable for non R2 variants. . rptSzOnGlareTmrExp (1): When glare is detected, the GW will wait for the timeout value specified in the glare timer object or until incoming call attempt is removed by the other exchange/switch. If the far end does not back off due to wrong configuration, and the GW times out, it reports the seize event to the controlling application. . rptSzOnGlareDet (2): When glare is detected, the GW will signal the seizure event to the controlling application. . rptRelOnGlareTmrExpAndGoOnHook (3): When glare is detected, the GW will wait for the timeout value specified in the glare timer object OR until incoming call attempt is removed by the other exchange/switch. If the far end does not back off, due to wrong configuration, and the GW times out, it reports the release event and goes onhook, upon detection of on hook from the far end the GW will send the rlc event to the controlling application. . goOnHookOnGlareDet (4): When glare is detected, the GW will go on hook and let the far end switch continue.
ccasGCnfParmSource
1.3.6.1.4.1.9.9.314.1.6.1.1.3
INTEGER1 = casVariantFile2 = mib · Integer32
This object indicates whether GW should read the CAS related timer parameters from the CAS Variant file downloaded for that endpoint or to read from the MIB. This gives the flexibility of configuring different CAS related timer values for different endpoints associated with the same CAS variant.
ccasGCnfRegSigMode
1.3.6.1.4.1.9.9.314.1.6.1.1.4
CASRegisterSignal1 = compelled2 = noncompelled3 = semicompelledThis textual convention defines Register Signaling.
Signals (tones) sent from the calling party to the called party are called forward register signals. Signals (tones) sent from the called party to the calling party are backward register signals.
Incoming registers (for incoming calls), receive forward register signals and return backward register signals. . In compelled register signaling, the backward signal sent out of the incoming register in response to a forward register signal stays on until the forward register signal sent from the other end (outgoing register) is turned off. Compelled signaling should not be used over satellite links due to latency. . In non-compelled and semi-compelled register signaling, the backward signals sent from the incoming register towards the other end (outgoing register) are pulses and not continuous.
Outgoing registers (for outgoing calls) : send forward register signals and receive backward register signals. . In compelled and semi-compelled register signaling, when a forward signal is sent, the tones stay on until the other end responds with the backward signal that signals the calling party to turn off the forward tone. The next forward tone is sent only after the backward tone has been turned off from the other end (incoming register). Compelled signaling should not be used for satellite links. . In non-compelled signaling, the calling party sends the forward signals as pulses. That is, they are on for a short duration. · Integer32
This object specifies the register signaling mode for a R2 registers. Reference: ITU-T recommendation Q.440 Interregister Signaling.
ccasGCnfLineSigType
1.3.6.1.4.1.9.9.314.1.6.1.1.5
INTEGER1 = digital2 = analog3 = pulse · Integer32
This object specifies the line signaling type that will be used for the R2 line signaling. . digital (1): The digital line signaling is typically used for PCM systems. Only A and B bits are used to indicate line signaling states, while C and D bits may be optionally used. . analog (2): The analog line signaling is typically used for carrier systems. Only A bit is used to represent tone-on and tone-off indication to signal the line signaling states, while the B, C, and D bit are fixed. . pulse (3): The Pulse type line signaling is typically used for satellite links. It uses tones sent as pulses to indicate line signaling states. Reference: ITU-T recommendation Q.421, Q.411, ITU-T Supplement 7
ccasGCnfRingBackType
1.3.6.1.4.1.9.9.314.1.6.1.1.6
INTEGER1 = wink2 = winkAndTone · Integer32
This object specifies the ring back signal type of FGD protocol. . wink (1): A pulse which is a timed transition from on hook to off hook and back to on hook. . wink and tone (2): A pulse which is a timed transition from on hook to off hook and back to on hook, and followed
by a tone with a frequency of 700Hz & 1700 Hz. Reference: Bellcore Publication: TR-NPL-000258 Compatibility Information for Feature Group D Switched Access Service, appendix 6
ccasGCnfIncCallHiFreqPower
1.3.6.1.4.1.9.9.314.1.6.1.1.7
Integer32 (-1000..1000) · dBm
This object specifies the power of the high frequency signal component for incoming call. Reference: TIA-689-A: PBX and KTS Support of Enhanced 911 Emergency Calling Service, section 5.2.3.10.1
ccasGCnfIncCallLoFreqPower
1.3.6.1.4.1.9.9.314.1.6.1.1.8
Integer32 (-1000..1000) · dBm
This object specifies the power of the low frequency signal component for incoming call. Reference: TIA-689-A: PBX and KTS Support of Enhanced 911 Emergency Calling Service, section 5.2.3.10.1
ccasGCnfIncCallNegTwist
1.3.6.1.4.1.9.9.314.1.6.1.1.9
Integer32 (-1000..1000) · dBm
This object specifies a negative power twist when the power level of the low frequency component is set to relatively higher than the high frequency component for incoming call. Reference: TIA-689-A: PBX and KTS Support of Enhanced 911 Emergency Calling Service, section 5.2.3.10.1
ccasGCnfIncCallPosTwist
1.3.6.1.4.1.9.9.314.1.6.1.1.10
Integer32 (-1000..1000) · dBm
This object specifies a positive power twist when the power level of the high frequency component is set to relatively higher than the low frequency component for incoming call. Reference: TIA-689-A: PBX and KTS Support of Enhanced 911 Emergency Calling Service, section 5.2.3.10.1
ccasGCnfIncCallBreakThreshold
1.3.6.1.4.1.9.9.314.1.6.1.1.11
Integer32 (-1000..1000) · dBm
This object specifies a power level which is used for detection of on hook to off hook transition for incoming call. Reference: TIA-689-A: PBX and KTS Support of Enhanced 911 Emergency Calling Service, section 5.2.3.10.1
ccasGCnfOutCallLoFreqPower
1.3.6.1.4.1.9.9.314.1.6.1.1.12
Integer32 (-1000..1000) · dBm
This object specifies the power level of the low frequency component for outgoing call. The power level of the high frequency component of outgoing call is relative above or below the value specified in object ccasGCnfOutCallPowerTwist. If the value of ccasGCnfOutCallPowerTwist is 0, the power level of the high frequency component as well as the low frequency component is specified by this object. Reference: Q.23, Q.24, EIA/TIA-464
ccasGCnfOutCallPowerTwist
1.3.6.1.4.1.9.9.314.1.6.1.1.13
Integer32 (-1000..1000) · dBm
This object specifies the relative power level of the high frequency component for outgoing call. When this object is set to 0, the power level of both frequency components is set to the same level. When this object is set to a positive value, the power level of the high frequency component is set to relatively higher specified in this object than the low frequency component, ccasGCnfOutCallLoFreqPower. For example if ccasGCnfOutCallLoFreqPower is set to -12 dBm and this object is set to 5, the power level of the high frequency component becomes -7 dBm. When this object is set to a negative value, the power level of the high frequency component is set to relatively lower specified in this object than the low frequency component. For example if ccasGCnfOutCallLoFreqPower is set to -12 dBm and this object is set to -10, the power level of the high frequency component becomes -22 dBm. Reference: Q.23, Q.24, EIA/TIA-464
ccasGCnfOutCadenceOntime
1.3.6.1.4.1.9.9.314.1.6.1.1.14
Unsigned32 (0..65535) · milliseconds
This object specifies the duration during which the digit tone is generated for outgoing call.
ccasGCnfOutCadenceOfftime
1.3.6.1.4.1.9.9.314.1.6.1.1.15
Unsigned32 (0..65535) · milliseconds
This object specifies the silence between digit tones for outgoing call.
ccasGCnfCountryCode
1.3.6.1.4.1.9.9.314.1.6.1.1.16
SnmpAdminStringAn octet string containing administrative information, preferably in human-readable form.
To facilitate internationalization, this information is represented using the ISO/IEC IS 10646-1 character set, encoded as an octet string using the UTF-8 transformation format described in [RFC2279].
Since additional code points are added by amendments to the 10646 standard from time to time, implementations must be prepared to encounter any code point from 0x00000000 to 0x7fffffff. Byte sequences that do not correspond to the valid UTF-8 encoding of a code point or are outside this range are prohibited.
The use of control codes should be avoided.
When it is necessary to represent a newline, the control code sequence CR LF should be used.
The use of leading or trailing white space should be avoided.
For code points not directly supported by user interface hardware or software, an alternative means of entry and display, such as hexadecimal, may be provided.
For information encoded in 7-bit US-ASCII, the UTF-8 encoding is identical to the US-ASCII encoding.
UTF-8 may require multiple bytes to represent a single character / code point; thus the length of this object in octets may be different from the number of characters encoded. Similarly, size constraints refer to the number of encoded octets, not the number of characters represented by an encoding.
Note that when this TC is used for an object that is used or envisioned to be used as an index, then a SIZE restriction MUST be specified so that the number of sub-identifiers for any object instance does not exceed the limit of 128, as defined by [RFC3416].
Note that the size of an SnmpAdminString object is measured in octets, not characters. SIZE (1..8) · OCTET STRING · hint 255t
This object specifies the subscriber category types: . (1) subscriber without priority . (2) subscriber with priority . (3) maintenance equipment . (4) operator call . (5) data national transmission . (6) subscriber or operator without forward transfer . (7) operator with forward transfer . (8) data international transmission
ccasGCnfNatureOfCircuit
1.3.6.1.4.1.9.9.314.1.6.1.1.19
INTEGER1 = notIncluded2 = included · Integer32
This object specifies if there is any satellite link in the path: . (1) Satellite link is not included. . (2) Satellite link is included.
This object specifies the Compelled Signaling type: . enbloc (1): The called number is forwarded in a block. . overlap (2): The called numder is forwarded one at a time. . endtoend (3): The signaling between register over two or more links in tandem without regeneration in intermediate exchanges.
ccasGCnfTxDigitOrder
1.3.6.1.4.1.9.9.314.1.6.1.1.21
INTEGER1 = aniDnis2 = dnisAni · Integer32
This object specifies the transmit digit order in which ANI and DNIs will be dialled out when the controlling application gives both the the calling party number and the called party number to the CAS module for dialing out in a single request.
ccasGCnfDigitDetectMode
1.3.6.1.4.1.9.9.314.1.6.1.1.22
INTEGER1 = dtmf2 = mf3 = dp · Integer32
This objects specifies the digit detect mode that the GW should be opened with for reception of digits. . dtmf (1): Dual tone multifrequency . mf (2): Multifrequency . dp (3): Dial pulse This object applies to non R2 interfaces.
ccasGCnfMeteringRepIntThresh
1.3.6.1.4.1.9.9.314.1.6.1.1.23
Unsigned32 (0..65535) · milliseconds
This object specifies the duration between two consecutive metering pulses, if it changes more than value specified in this parameter then an event will be triggered to MGC.
ccasGCnfStartTimer
1.3.6.1.4.1.9.9.314.1.6.1.1.24
Unsigned32 (0..10000) · seconds
This object specifies the amount of time that the GW must wait for receiving digits after generating the seize ACK or start dial indication for an incoming call. The value of 0 indicates the timer will not be started and GW would wait forever.
ccasGCnfLongTimer
1.3.6.1.4.1.9.9.314.1.6.1.1.25
Unsigned32 (0..10000) · seconds
This object specifies the period between receiving digits. The timer is not started until the first digit is received. The GW starts this timer during digit collection when at least one or more digits is required for a digit string to match any allowed pattern in the digit map. The timer is restarted after every new digit is received. This continues until the digit string matches at least one pattern in the digit map. The value of 0 indicates the timer will not be started and GW would wait forever.
ccasGCnfShortTimer
1.3.6.1.4.1.9.9.314.1.6.1.1.26
Unsigned32 (0..10000) · seconds
This object specifies the period between receiving digits. The GW starts this timer during digit collection when the digit string that it has collected matches at least one pattern in the digit map, but reception of another digit could change the match to a different pattern. In this case, GW waits to confirm that no more digits are received while this timer is running before reporting the match to the MGC. The value of 0 indicates the timer will not be started and GW would report immediately.
ccasGCnfLongDurationTimer
1.3.6.1.4.1.9.9.314.1.6.1.1.27
Unsigned32 (100..9900) · milliseconds
This object specifies long duration event when placed in front of a digit. It indicates that that position is satisfied only if the duration of the event exceeds the long-duration threshold.
ccasGCnfMGCTimer
1.3.6.1.4.1.9.9.314.1.6.1.1.28
Unsigned32 (0..100000) · milliseconds
This object specifies the timer in the GW waiting for the MGC to provide the rest of the information for CAS signaling. During overlap CAS signaling, for an outgoing call, the MGC might specify a part of the digits to be signaled out of the GW while it is waiting to collect the rest of the information that also needs to be signaled. In this case, if the GW has finished signaling all the available digits, it can start this timer to wait for the MGC to specify the rest of the information. The backward signal from the far end can also request for information that the MGC has not yet specified to the GW. In this case also, this timer is started to wait for the MGC to provide the information needed by the GW. Reference: H.248 International CAS Compelled Register Signaling Packages (icasc), section 6.1.2
ccasGCnfDigitType
1.3.6.1.4.1.9.9.314.1.6.1.1.29
INTEGER1 = dtmf2 = mf3 = dp · Integer32
This object specifies the digit type to pulsed from the GW such as: .dtmf - Dual tone multifrequency. .mf - Multifrequency. .dp - Dial pulse. This parameter can be overridden by MGC. In the event that the MGC does not specify the digit type, the value of this object is used.
This object specifies the direction in which CAS calls will be accepted on this endpoint. .bidirectional - Accepts both incoming and outgoing calls. .incoming - Accepts incoming calls only. .outgoing - Accepts outgoing calls only.
ccasGCnfPulseReceiveTimeout
1.3.6.1.4.1.9.9.314.1.6.1.1.31
Unsigned32 (0..100000) · seconds
This object specifies the time that the MG should wait for the receipt of pulse (on hook pulse or off hook pulse). The value of 0 indicates the timer will not be started and MG would wait forever. Reference: H.248.25 Basis CAS Packages RBS (Robbed Bit Signal) Packet, section 9.2.1
ccasGCnfInitialDelay
1.3.6.1.4.1.9.9.314.1.6.1.1.32
Unsigned32 (0..10000) · milliseconds
This object specifies the initial delay that must be applied on an outgoing trunk before the digits are pulse out. The value of 0 indicates the timer, ccasGCnfInitialDelay will start immediately. Reference: H.248.25 Basis CAS Packages section 8.3.1
ccasGCnfMaxNumCallParty
1.3.6.1.4.1.9.9.314.1.6.1.1.33
Unsigned32 (0..65535)
This object specifies the maximum number of calling party digits to collect for reporting to the MGC. The MGC can overridden this value, and a value of 0 indicates that there is no limit and all numbers till end of calling party signaling must be accumulated.
ccasGCnfRowStatus
1.3.6.1.4.1.9.9.314.1.6.1.1.34
RowStatus1 = active2 = notInService3 = notReady4 = createAndGo5 = createAndWait6 = destroyThe RowStatus textual convention is used to manage the creation and deletion of conceptual rows, and is used as the value of the SYNTAX clause for the status column of a conceptual row (as described in Section 7.7.1 of [2].)
The status column has six defined values:
- `active', which indicates that the conceptual row is available for use by the managed device;
- `notInService', which indicates that the conceptual row exists in the agent, but is unavailable for use by the managed device (see NOTE below); 'notInService' has no implication regarding the internal consistency of the row, availability of resources, or consistency with the current state of the managed device;
- `notReady', which indicates that the conceptual row exists in the agent, but is missing information necessary in order to be available for use by the managed device (i.e., one or more required columns in the conceptual row have not been instanciated);
- `createAndGo', which is supplied by a management station wishing to create a new instance of a conceptual row and to have its status automatically set to active, making it available for use by the managed device;
- `createAndWait', which is supplied by a management station wishing to create a new instance of a conceptual row (but not make it available for use by the managed device); and, - `destroy', which is supplied by a management station wishing to delete all of the instances associated with an existing conceptual row.
Whereas five of the six values (all except `notReady') may be specified in a management protocol set operation, only three values will be returned in response to a management
protocol retrieval operation: `notReady', `notInService' or
`active'. That is, when queried, an existing conceptual row
has only three states: it is either available for use by
the managed device (the status column has value `active'); it is not available for use by the managed device, though the agent has sufficient information to attempt to make it so (the status column has value `notInService'); or, it is not available for use by the managed device, and an attempt to make it so would fail because the agent has insufficient information (the state column has value `notReady').
NOTE WELL
This textual convention may be used for a MIB table, irrespective of whether the values of that table's conceptual rows are able to be modified while it is active, or whether its conceptual rows must be taken out of service in order to be modified. That is, it is the responsibility of the DESCRIPTION clause of the status column to specify whether the status column must not be `active' in order for the value of some other column of the same conceptual row to be modified. If such a specification is made, affected columns may be changed by an SNMP set PDU if the RowStatus would not be equal to `active' either immediately before or after processing the PDU. In other words, if the PDU also contained a varbind that would change the RowStatus value, the column in question may be changed if the RowStatus was not equal to `active' as the PDU was received, or if the varbind sets the status to a value other than 'active'.
Also note that whenever any elements of a row exist, the RowStatus column must also exist.
To summarize the effect of having a conceptual row with a status column having a SYNTAX clause value of RowStatus, consider the following state diagram:
STATE +--------------+-----------+-------------+-------------
| A | B | C | D
| |status col.|status column|
|status column | is | is |status column
ACTION |does not exist| notReady | notInService| is active
--------------+--------------+-----------+-------------+-------------
set status |noError ->D|inconsist- |inconsistent-|inconsistent-
column to | or | entValue| Value| Value
createAndGo |inconsistent- | | |
| Value| | |
--------------+--------------+-----------+-------------+-------------
set status |noError see 1|inconsist- |inconsistent-|inconsistent-
column to | or | entValue| Value| Value
createAndWait |wrongValue | | |
--------------+--------------+-----------+-------------+-------------
set status |inconsistent- |inconsist- |noError |noError
column to | Value| entValue| |
active | | | |
| | or | |
| | | |
| |see 2 ->D|see 8 ->D| ->D
--------------+--------------+-----------+-------------+-------------
set status |inconsistent- |inconsist- |noError |noError ->C
column to | Value| entValue| |
notInService | | | |
| | or | | or
| | | |
| |see 3 ->C| ->C|see 6
--------------+--------------+-----------+-------------+-------------
set status |noError |noError |noError |noError ->A
column to | | | | or
destroy | ->A| ->A| ->A|see 7
--------------+--------------+-----------+-------------+-------------
set any other |see 4 |noError |noError |see 5
column to some| | | |
value | | see 1| ->C| ->D
--------------+--------------+-----------+-------------+-------------
(1) goto B or C, depending on information available to the agent.
(2) if other variable bindings included in the same PDU, provide values for all columns which are missing but required, and all columns have acceptable values, then return noError and goto D.
(3) if other variable bindings included in the same PDU, provide legal values for all columns which are missing but required, then return noError and goto C.
(4) at the discretion of the agent, the return value may be either:
inconsistentName: because the agent does not choose to
create such an instance when the corresponding RowStatus instance does not exist, or
inconsistentValue: if the supplied value is
inconsistent with the state of some other MIB object's value, or
noError: because the agent chooses to create the instance.
If noError is returned, then the instance of the status column must also be created, and the new state is B or C, depending on the information available to the agent. If inconsistentName or inconsistentValue is returned, the row remains in state A.
(5) depending on the MIB definition for the column/table, either noError or inconsistentValue may be returned.
(6) the return value can indicate one of the following errors:
wrongValue: because the agent does not support notInService (e.g., an agent which does not support createAndWait), or
inconsistentValue: because the agent is unable to take the row out of service at this time, perhaps because it is in use and cannot be de-activated.
(7) the return value can indicate the following error:
inconsistentValue: because the agent is unable to remove the row at this time, perhaps because it is in use and cannot be de-activated.
(8) the transition to D can fail, e.g., if the values of the conceptual row are inconsistent, then the error code would be inconsistentValue.
NOTE: Other processing of (this and other varbinds of) the set request may result in a response other than noError being returned, e.g., wrongValue, noCreation, etc.
Conceptual Row Creation
There are four potential interactions when creating a
conceptual row: selecting an instance-identifier which is
not in use; creating the conceptual row; initializing any objects for which the agent does not supply a default; and, making the conceptual row available for use by the managed device.
Interaction 1: Selecting an Instance-Identifier
The algorithm used to select an instance-identifier varies for each conceptual row. In some cases, the instance- identifier is semantically significant, e.g., the destination address of a route, and a management station selects the instance-identifier according to the semantics.
In other cases, the instance-identifier is used solely to distinguish conceptual rows, and a management station without specific knowledge of the conceptual row might examine the instances present in order to determine an unused instance-identifier. (This approach may be used, but it is often highly sub-optimal; however, it is also a questionable practice for a naive management station to attempt conceptual row creation.)
Alternately, the MIB module which defines the conceptual row might provide one or more objects which provide assistance in determining an unused instance-identifier. For example, if the conceptual row is indexed by an integer-value, then an object having an integer-valued SYNTAX clause might be defined for such a purpose, allowing a management station to issue a management protocol retrieval operation. In order to avoid unnecessary collisions between competing management stations, `adjacent' retrievals of this object should be different.
Finally, the management station could select a pseudo-random number to use as the index. In the event that this index
was already in use and an inconsistentValue was returned in response to the management protocol set operation, the management station should simply select a new pseudo-random number and retry the operation.
A MIB designer should choose between the two latter algorithms based on the size of the table (and therefore the efficiency of each algorithm). For tables in which a large number of entries are expected, it is recommended that a MIB object be defined that returns an acceptable index for creation. For tables with small numbers of entries, it is recommended that the latter pseudo-random index mechanism be used.
Interaction 2: Creating the Conceptual Row
Once an unused instance-identifier has been selected, the management station determines if it wishes to create and activate the conceptual row in one transaction or in a negotiated set of interactions.
Interaction 2a: Creating and Activating the Conceptual Row
The management station must first determine the column requirements, i.e., it must determine those columns for which it must or must not provide values. Depending on the complexity of the table and the management station's knowledge of the agent's capabilities, this determination can be made locally by the management station. Alternately, the management station issues a management protocol get operation to examine all columns in the conceptual row that it wishes to create. In response, for each column, there are three possible outcomes:
- a value is returned, indicating that some other management station has already created this conceptual row. We return to interaction 1.
- the exception `noSuchInstance' is returned, indicating that the agent implements the object-type associated with this column, and that this column in at least one conceptual row would be accessible in the MIB view used by the retrieval were it to exist. For those columns to which the agent provides read-create access, the `noSuchInstance' exception tells the management station that it should supply a value for this column when the conceptual row is to be created.
- the exception `noSuchObject' is returned, indicating that the agent does not implement the object-type associated with this column or that there is no conceptual row for which this column would be accessible in the MIB view used by the retrieval. As such, the management station can not issue any management protocol set operations to create an instance of this column.
Once the column requirements have been determined, a management protocol set operation is accordingly issued. This operation also sets the new instance of the status column to `createAndGo'.
When the agent processes the set operation, it verifies that it has sufficient information to make the conceptual row available for use by the managed device. The information
available to the agent is provided by two sources: the
management protocol set operation which creates the conceptual row, and, implementation-specific defaults supplied by the agent (note that an agent must provide implementation-specific defaults for at least those objects which it implements as read-only). If there is sufficient information available, then the conceptual row is created, a `noError' response is returned, the status column is set to `active', and no further interactions are necessary (i.e., interactions 3 and 4 are skipped). If there is insufficient information, then the conceptual row is not created, and the set operation fails with an error of `inconsistentValue'. On this error, the management station can issue a management protocol retrieval operation to determine if this was because it failed to specify a value for a required column, or, because the selected instance of the status column already existed. In the latter case, we return to interaction 1. In the former case, the management station can re-issue the set operation with the additional information, or begin interaction 2 again using `createAndWait' in order to negotiate creation of the conceptual row.
NOTE WELL
Regardless of the method used to determine the column requirements, it is possible that the management station might deem a column necessary when, in fact, the agent will not allow that particular columnar instance to be created or written. In this case, the management protocol set operation will fail with an error such as `noCreation' or `notWritable'. In this case, the management station decides whether it needs to be able to set a value for that particular columnar instance. If not, the management station re-issues the management protocol set operation, but without setting a value for that particular columnar instance; otherwise, the management station aborts the row creation algorithm.
Interaction 2b: Negotiating the Creation of the Conceptual Row
The management station issues a management protocol set operation which sets the desired instance of the status column to `createAndWait'. If the agent is unwilling to process a request of this sort, the set operation fails with an error of `wrongValue'. (As a consequence, such an agent must be prepared to accept a single management protocol set operation, i.e., interaction 2a above, containing all of the
columns indicated by its column requirements.) Otherwise,
the conceptual row is created, a `noError' response is returned, and the status column is immediately set to either `notInService' or `notReady', depending on whether it has sufficient information to (attempt to) make the conceptual row available for use by the managed device. If there is sufficient information available, then the status column is set to `notInService'; otherwise, if there is insufficient information, then the status column is set to `notReady'. Regardless, we proceed to interaction 3.
Interaction 3: Initializing non-defaulted Objects
The management station must now determine the column requirements. It issues a management protocol get operation to examine all columns in the created conceptual row. In the response, for each column, there are three possible outcomes:
- a value is returned, indicating that the agent implements the object-type associated with this column and had sufficient information to provide a value. For those columns to which the agent provides read-create access (and for which the agent allows their values to be changed after their creation), a value return tells the management station that it may issue additional management protocol set operations, if it desires, in order to change the value associated with this column.
- the exception `noSuchInstance' is returned, indicating that the agent implements the object-type associated with this column, and that this column in at least one conceptual row would be accessible in the MIB view used by the retrieval were it to exist. However, the agent does not have sufficient information to provide a value, and until a value is provided, the conceptual row may not be made available for use by the managed device. For those columns to which the agent provides read-create access, the `noSuchInstance' exception tells the management station that it must issue additional management protocol set operations, in order to provide a value associated with this column.
- the exception `noSuchObject' is returned, indicating that the agent does not implement the object-type associated with this column or that there is no conceptual row for which this column would be accessible in the MIB view used by the retrieval. As such, the management station can not issue any management protocol set operations to create an instance of this column.
If the value associated with the status column is `notReady', then the management station must first deal with all `noSuchInstance' columns, if any. Having done so, the value of the status column becomes `notInService', and we proceed to interaction 4.
Interaction 4: Making the Conceptual Row Available
Once the management station is satisfied with the values associated with the columns of the conceptual row, it issues a management protocol set operation to set the status column to `active'. If the agent has sufficient information to make the conceptual row available for use by the managed device, the management protocol set operation succeeds (a `noError' response is returned). Otherwise, the management protocol set operation fails with an error of `inconsistentValue'.
NOTE WELL
A conceptual row having a status column with value `notInService' or `notReady' is unavailable to the managed device. As such, it is possible for the managed device to create its own instances during the time between the management protocol set operation which sets the status column to `createAndWait' and the management protocol set operation which sets the status column to `active'. In this case, when the management protocol set operation is issued to set the status column to `active', the values held in the agent supersede those used by the managed device.
If the management station is prevented from setting the status column to `active' (e.g., due to management station or network failure) the conceptual row will be left in the `notInService' or `notReady' state, consuming resources indefinitely. The agent must detect conceptual rows that have been in either state for an abnormally long period of time and remove them. It is the responsibility of the DESCRIPTION clause of the status column to indicate what an abnormally long period of time would be. This period of time should be long enough to allow for human response time (including `think time') between the creation of the conceptual row and the setting of the status to `active'. In the absence of such information in the DESCRIPTION clause, it is suggested that this period be approximately 5 minutes in length. This removal action applies not only to newly-created rows, but also to previously active rows which are set to, and left in, the notInService state for a prolonged period exceeding that which is considered normal for such a conceptual row.
Conceptual Row Suspension
When a conceptual row is `active', the management station may issue a management protocol set operation which sets the instance of the status column to `notInService'. If the agent is unwilling to do so, the set operation fails with an error of `wrongValue' or `inconsistentValue'. Otherwise, the conceptual row is taken out of service, and a `noError' response is returned. It is the responsibility of the DESCRIPTION clause of the status column to indicate under what circumstances the status column should be taken out of service (e.g., in order for the value of some other column of the same conceptual row to be modified).
Conceptual Row Deletion
For deletion of conceptual rows, a management protocol set operation is issued which sets the instance of the status column to `destroy'. This request may be made regardless of the current value of the status column (e.g., it is possible to delete conceptual rows which are either `notReady',
`notInService' or `active'.) If the operation succeeds,
then all instances associated with the conceptual row are immediately removed. · Integer32
This object is used for adding, modifying, deleting the entries from the ccasExtIfGeneralConfigTable. A default entry with index value 1 is created at initialization, and it can not be modified or deleted.