| mgcRedundancyGrpNum |
.1.3.6.1.4.1.351.150.22.1.1.1.1 |
|
This is the MGC group number. A group can contain
more than 1 MGC. So for a group containing more
than 1 MGC, there will be more than 1 row of this
table that will have a common group number.
|
| mgcRedundancyGrpPref |
.1.3.6.1.4.1.351.150.22.1.1.1.2 |
|
Allows to configure the preference on a MGCs. The GW
use this object in the selection of an MGC when there
are multiple MGCs in the same MGC redundancy group.
This object can be modified at any time while
the mgcRedundancyGrpRowStatus is 'active'. It has
to be unique among various MGCs of a same MGC
redundancy group.
The lower the number the higher the preference,
for example 1 will have higher preference than 2.
|
| mgcRedundancyGrpActState |
.1.3.6.1.4.1.351.150.22.1.1.1.3 |
|
This object is used to denote the status of MGC
within an MGC Redundancy group.
'mgcActive' - Indicates the MGC is active or
controlling the GW.
'mgcInactive' - Indicates the MGC is in standby
state.
|
| mgcRedundancyGrpRowStatus |
.1.3.6.1.4.1.351.150.22.1.1.1.4 |
|
Controls the creation and deletion of a table entry.
An entry may be created using the 'createAndGo' option.
When the row is successfully created, the RowStatus would
be set to 'active' by the agent. An entry may be deleted
by setting the RowStatus to 'destroy'. Other options such as
`createAndWait', 'notInService', 'notReady' are not
supported.
mgcRedundancyGrpNum, mgcNumber and mgcRedundancyGrpPref
are the mandatory parameters while creating an entry.
|
| mgcRedundancyGrpStateChangeNtfy |
.1.3.6.1.4.1.351.150.22.1.2.1.1 |
|
This object 'true(1) will enable sending state
change notifications to the MGC.
'false(2)' will disable sending state
change notifications to MGC, for example,
if MGCP/SGCP is the protocol used, then RSIPs
are sent to the MGC if this object is
set to 'true(1)'.
|
| mgcRedundancyGrpCommState |
.1.3.6.1.4.1.351.150.22.1.2.1.2 |
|
Represents the state of the communication between
the GW and the MGC (call agent) group.
The possible values are:
'commOk': This indicates that the communication
between the gateway and the media
gateway controller is ok.
'commLoss': This indicates that the communication
between the GW and the MGC is lost.
This object is set to 'commLoss' if
no response is receive from any
MGC in this group to a GW
initiated message.
If the GW is able to successfully send a message
to the MGC or if a message is received
from the MGC, the value of this object
is set to 'commOk' else it will remain in the
'commLoss' state.
|
| mgcRedundancyGrpPriority |
.1.3.6.1.4.1.351.150.22.1.2.1.3 |
|
This field determines the priority amongst the
MGC redundancy groups within the GW.
A MGC group with a priority of 0 means that the
MGC group is not interested in receiving GW initiated
messages. A group with a priority value of 1 has the
highest preference. A higher value indicates a
lower preference. Multiple MGC redundancy groups
can have the same priority.
|
| mgcRedundancyGrpProtocolRowStatus |
.1.3.6.1.4.1.351.150.22.1.3.1.1 |
|
Controls the creation and deletion of a table entry.
An entry may be created using the 'createAndGo' option.
When the row is successfully created, the
mgcRedundancyGrpProtocolRowStatus would be set to 'active'
by the agent. An entry can be modified at any time
while the mgcRedundancyGrpProtocolRowStatus is 'active'.
An entry may be deleted by setting the
mgcRedundancyGrpProtocolRowStatus to 'destroy'.
|
| mgcRedGrpProtPersistEvtPolicy |
.1.3.6.1.4.1.351.150.22.1.3.1.2 |
|
This object determines how the persistent events
will be notified.
Persistent events are events that call
agent wants to be notified without explicitly
requesting for it. A set of events can be
provisioned on the Gateway as persistent
events.
Every event will have an action associated
with it, which will determine, whether to
be notified, ignored, accumulated etc..
MGC will specify the action when
requesting the GW to notify the event.
For persistent events the Action will be
Notify. Call agent can change this by
explicitly requesting the event associating
an action with it.
During the period where the Gateway has
received a notification acknowledgement,
and waiting for the next Request Notification,
events could be observed. The Quarantine
procedure determines what should be done with
these events.
This object is used to supercede the quarantine
procedure, by enforcing loop, process as the
quarantine procedure only for persistent events.
During the period the Gateway has sent a
Notification, and waiting for the acknowledgement
all events including the persistent events will
'quarantinePersistEvts' - Quarantine Persistent
events as in the case of non persistent
events as determined by quarantine method.
'notQuarantinePersistEvts' - Don't quarantine
Persistent events, and notify them.
During the period the Gateway has sent a Notify
and waiting for the acknowledgement, every
event including persistent event will be
quarantined. This value does not supercede
that behaviour. This applies only during
the period, where a Notify is acknowledged
and waiting for the next RQNT where the
quarantine method is 'step,process' or
'step,discard'.
This object has no relevance when the protocol
is SRCP.
|
| mgcRedGrpProtQuarantinePolicy |
.1.3.6.1.4.1.351.150.22.1.3.1.3 |
|
This object determines the quarantine policy
when MGC doesn't explicitly specify
one.
When a Request Notification is received
from the MGC, the Gateway on observing
the first event that qualifies to be notified
will generate a Notify message with the list
of observed events including the event which
triggered the Notify.
After the MGC acknowledges the Notify,
if further events are observed and an event
which qualifies to be notified, the Gateway
may notify the event, or quarantine it until
the next Request Notification, based on the
quarantine policy set by the MGC.
When the MGC doesn't explicitly
specify the quarantine policy, the protocol
defines the default behaviour. The default
behaviour varies with different versions of
the protocol.
This object allows the user to configure
the default quarantine policy per protocol
per redundancy group. The default value
for this object will be set based on the
protocol.
'stepProcess' - Process the events in the
quarantine list, and after one Notify
quarantine events until next Request
Notification
'stepDiscard' - Discard the events in the
quarantine list, and after one Notify
quarantine events until next Request
Notification
'loopProcess' - Process the events in the
quarantine list, and notify observed
events as and when need arises
'loopDiscard' - Discard the events in the
quarantine list, and notify observed
events as and when need arises
The default value for MGCP 1.0 will be
stepProcess and stepDiscard for the rest.
This object has no relevance when the protocol
is SRCP.
|
| mgcRedGrpProtSigEvtOnOffPolicy |
.1.3.6.1.4.1.351.150.22.1.3.1.4 |
|
This object enables the user to provision the
way signaled events from CA are handled
by the gateway. This is configurable on
a per MGC redundancy group, per protocol basis.
If the protocol is MGCP 1.0 the default of this
object is 'deleteOnlyNegatedEvent', else it is set
to 'deleteEventNotPresent'.
If this object is set to 'deleteOnlyNegatedEvent',
then the signal currently active on a
endpoint/connection can be turned OFF only by
parameterizing it with a (-)
for eg: S: T/co1(-)
will turn off co1 event on an endpoint.
And can be turned ON by just
providing the signal name or by parameterizing
the signal name with a (+)
for eg: S:T/co1(+), L/hd
will turn on co1 and hd events on the endpoint.
If this object is set to 'deleteEventNotPresent',
then the signal/s can be turned OFF by
providing empty S: list.
The signal can be turned ON by simply
providing the signal name.
for eg: S:
will turn OFF all active signals on the endpoint
S: T/co1
will turn ON co1 signal.
The configuration of this object only applies to
on/off signals and not for brief or timeout signals.
MGCP 0.1 specification says if an empty signaled
list is provided it is meant to turn off all the
currently turned on signaled events. However
in MGCP 1.0 specification, it says that unless
specifically requested by the CA to turn off
(signal is parameterized by a (-)) the signal
cannot be turned off, in other words an
empty signal list does imply that the currently
active signals should be turned off.
Although the behavior of the gateway is
specified in the specs, some MGC
may not follow the MGCP 1.0 spec. Hence
this MIB serves as an interop knob.
This object has no relevance when the protocol
is SRCP.
|
| mgcRedGrpProtProvisionalResponse |
.1.3.6.1.4.1.351.150.22.1.3.1.5 |
|
This object enables or disables sending provisional
response to the CA when processing a request received
from the CA. The provisional response to the CA
indicates that the GW is processing the request and
will send a final response once the processing is
complete.
For example, if a CRCX request from the CA using MGCP
protocol, requires that resources be reserved along the
bearer path using RSVP, GW would send a provisional
response if this parameter was set to true. It would
then wait for the RSVP procedure to complete before
sending the final response. On the other hand, if the
value of this parameter was set to false, the final
response will be sent out without waiting for the
RSVP procedure to complete. When the RSVP procedure
does complete, a NTFY will be sent from the GW
indicating if the RSVP procedure was successful or not.
The GW will receive provisional responses from the CA.
These messages will be parsed and ignored regardless
of this object.
If the protocol supported by the CA is MGCP1.0, the
default value for this object is 'sendProvisionalResponse'.
In all other cases, it is 'notSendProvisionalResponse'.
This object has no relevance when the protocol
is SRCP.
|
| mgcRedGrpProtResponseAckAttr |
.1.3.6.1.4.1.351.150.22.1.3.1.6 |
|
Every command from the MGC could
contain Response Acknowledgement attribute.
This attribute consists a list of transaction
IDs which are acknowledged by the Call agent.
The gateway on receiving this can free up the
resources attached to this transaction ID.
When this attribute is present in the Gateway
response, it should contain an empty list of
transaction ID. This attribute in the response
from the Gateway is to invite a response
acknowledgement message from the MGC
for this response. This will be present in the
final response sent by the gateway only when a
provisional response had been sent prior to
this final response for the same transaction.
This object determines whether the Gateway
should include response acknowledgement in
the final response. This object does not
determine the capability of the Gateway to
receive response acknowledgement attribute
as part of MGC commands.
'sendResponseAckAttr' - Gateway will include response
acknowledgement attribute as part of
final response when a provisional response
had been sent earlier.
'notSendResponseAckAttr' - Gateway will not include
response acknowledgement attribute as part of
final response when a provisional response had
been sent earlier.
The default value will be 'sendResponseAckAttr' for
MGCP 1.0 protocol and 'notSendResponseAckAttr' for
every other protocol.
This object has no relevance when the protocol
is SRCP.
|
| mgcRedGrpProtDisconnectProcedure |
.1.3.6.1.4.1.351.150.22.1.3.1.7 |
|
This attribute describes whether disconnected procedure
is enabled/disabled per protocol per MGC group
configured.
The endpoint becomes disconnected when a gateway initiated
commands are sent to the MGC and has not received any
response from the MGC. The disconnected endpoint
initiates the disconnected procedure by sending
Restart in Progress command with restart method
RM:disconnected to the MGC.
When the object is set to 'doDisconnectProcedure', then the
endpoint will start the disconnected procedure and sends
'Restart In Progress' command with the restart method
RM:disconnected to the MGC.
By default, the object is set to 'doDisconnectProcedure'
for MGCP 1.0 and 'notDoDisconnectProcedure' for all
other protocols.
This object has no relevance when the protocol
is SRCP.
|
| mgcRedGrpProtCancelGraceful |
.1.3.6.1.4.1.351.150.22.1.3.1.8 |
|
This attribute describes whether notification of RSIP
cancel graceful is enabled/disabled per protocol
per MGC group configured.
The Restart in Progress command with the restart method
of cancel graceful indicates that the gateway is canceling
a previously issued 'graceful' restart in progress command.
The endpoints are still in service.
When the object is set to 'sendCancelGraceful', the gateway
will send the Restart in Progress command with the restart
method of cancel graceful indicating that it is canceling the
previously sent 'graceful' Restart in Progress command.
By default, the object is set to 'sendCancelGraceful' for
MGCP 1.0 and 'notSendCancelGraceful' for all other protocols.
This object has no relevance when the protocol
is SRCP.
|
