PKTC-IETF-SIG-MIB Table View

This table describes the MTA-supported codec types.  An MTA
MUST populate this table with all possible combinations of
codecs it supports for simultaneous operation.  For example,
an MTA with two endpoints may be designed with a particular
Digital Signal Processing (DSP) and memory architecture that
allows it to support the following fixed combinations of
codecs for simultaneous operation:
          
Codec Type     Maximum Number of Simultaneous Codecs
PCMA                             3
          
PCMA                             2
PCMU                             1
          
PCMA                             1
          
PCMU                             2
          
PCMU                             3
          
PCMA                             1
G729                             1
          
G729                             2
          
PCMU                             1
G729                             1
          
Based on this example, the entries in the codec table
would be:
          
  pktcSigDev        pktcSigDev        pktcSigDev
CodecComboIndex     CodecType          CodecMax
       1               pcma                3
       2               pcma                2
       2               pcmu                1
       3               pcma                1
       3               pcmu                2
       4               pcmu                3
       5               pcma                1
       5               g729                1
       6               g729                2
       7               pcmu                1
       7               g729                1
          
An operator querying this table is able to determine all
possible codec combinations the MTA is capable of
simultaneously supporting.
          
This table MUST NOT include non-voice codecs.

This table describes the signaling types supported by this
MTA.

The Pulse signal table defines the pulse signal operation.
There are nine types of international pulse signals,
with each signal having a set of provisionable parameters.
The values of the MIB objects in this table take effect
only if these parameters are not defined via signaling, in
which case, the latter determines the values of the
parameters.  The MIB objects in this table do not persist
across MTA reboots.

Cadence rings are defined by the telco governing
body for each country.  The MTA must be able to support
various ranges of cadence patterns and cadence periods.
The MTA will be able to support country-specific
provisioning of the cadence and idle period.  Each
cadence pattern will be assigned a unique value ranging
from 0-127 (inclusive) corresponding to the value of x,
where x is the value sent in the cadence ringing (cr)
signal cr(x), requested per the appropriate NCS
message, and defined in the E package.  The MTA will derive
the cadence periods from the ring cadence table entry, as
provisioned by the customer.  The MTA is allowed to provide
appropriate default values for each of the ring cadences.
This table only needs to be supported when the MTA
implements the E package.

The Tone Table defines the composition of tones and
various tone operations.
          
The definition of the tones callWaiting1 through
callWaiting4 in this table MUST only contain the
audible tone itself; the delay between tones or the value
of the tone repeat count are not applicable for the call
waiting tones.
The delay between tones or the repeat count is controlled
by the objects pktcSigEndPntConfigCallWaitingDelay and
pktcSigEndPntConfigCallWaitingMaxRep.  If the
pktcSigDevToneType is set to either of the values
callWaiting1, callWaiting2, callWaiting3, or callWaiting4,
then the value of the pktcSigDevToneWholeToneRepeatCount
object indicates that the particular frequency group is
applicable, as a repeatable part of the tone, based on the
value of the MIB object
pktcSigDevToneWholeToneRepeatCount.
          
The MTA MUST make sure that, after the provisioning
cycle, the table is fully populated (i.e., for each
possible index, an entry MUST be defined) using
reasonable defaults for each row that was not defined
by the provisioning information delivered via MTA
Configuration.
          
The frequency composition of each tone is defined by the
pktcSigDevMultiFreqToneTable.  For each tone type defined
in pktcSigDevToneTable, the MTA MUST populate at least
one entry in the pktcSigDevMultiFreqToneTable.
          
For each particular value of pktcSigDevToneType, the
pktcSigDevToneTable table can define non-repeating and
repeating groups of the frequencies defined by the
pktcSigDevMultiFreqToneTable, such that each group is
represented by the set of the consecutive rows
(frequency group) in the pktcSigDevMultiFreqToneTable.
          
Objects in this table do not persist across MTA reboots.
For tones with multiple frequencies refer to the MIB table
pktcSigDevMultiFreqToneTable.

This MIB table defines the characteristics of tones
with multiple frequencies.  The constraints imposed
on the tones by the MIB table pktcSigDevToneTable
need to be considered for MIB objects in this table
as well.
          
The MTA MUST populate the corresponding row(s)
of the pktcSigDevMultiFreqToneTable for each tone
defined in the pktcSigDevToneTable.
          
The contents of the table may be provisioned via
MTA configuration.

This table describes the information pertaining to each
endpoint of the MTA.  All entries in this table represent
the provisioned endpoints provisioned with the information
required by the MTA to maintain the NCS protocol
communication with the CMS.  Each endpoint can be assigned
to its own CMS.  If the specific endpoint does not have
the corresponding CMS information in this table, the
endpoint is considered as not provisioned with voice
services.  Objects in this table do not persist across
MTA reboots.