[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[ipcdn] [PKT-SIG-MIB] Draft 08 (Summary Of Changes)
Folks,
Reference: draft-ietf-ipcdn-pktc-signaling-08.txt
Please find enclosed a summary of the comments and the proposed
resolutions that were incorporated into the recently submitted D08
submission.
regards
Sumanth
Comments and resolutions that were incorporated into D08
-------------------------------------------------------
COMMENT SET #1/7:
----------------------------------------------------------------------
- [Randy: Oct 29, 2004] - *CLOSED*
http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01428.html
Email Subject: Re: [ipcdn] Submission: IETF NCS Signaling MIB
draft 7 (Update)
Issue: Clarification regarding 'pktcNcsEndPntConfigPartialDialTO' and
' pktcNcsEndPntConfigCriticalDialTO'.
RESOLUTION: Looks like the 'maximum' was unintended. Good catch!
Thanks Randy!
Changed MIB Objects as follows:
pktcNcsEndPntConfigPartialDialTO OBJECT-TYPE
<...>
DESCRIPTION
"This object contains the value of the partial dial
^^^^^ (rephrased "maximum value") ^^^^
time out."
<...>
::= { pktcNcsEndPntConfigEntry 3 }
pktcNcsEndPntConfigCriticalDialTO OBJECT-TYPE
<...>
DESCRIPTION
"This object contains the value of the critical
^^^^^ (rephrased "maximum value") ^^^^
dial time out."
<...>
::= { pktcNcsEndPntConfigEntry 4 }
STATUS: *UPDATED*
----------------------------------------------------------------------
COMMENT SET #2/7:
----------------------------------------------------------------------
+ [Satish: Nov 16, 2004] - *CLOSED*
http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01439.html
Email Subject: pktcRingCadence explanation changed from
sig-draft-5 to sig-draft-7
Issue: Suggestion to revert to the earlier description of
'PktcRingCadence' w.r.t repeatability.
RESOLUTION:
- [Sumanth, Nov 17, 2004]
http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01440.html
- [Gordon, Nov 17, 2004]
http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01441.html
ACTION: Comment Accepted.
PktcRingCadence ::= TEXTUAL-CONVENTION
<...>
DESCRIPTION
<...>
The third of the reserved octets indicates 'repeatability'
and MUST be either 0x80 or 0x00 - the former value
indicating 'non-repeatability' and the latter indicating
^^^(used to be 'repeatability')^^^
'repeatability'.
^^^(used to be 'non-repeatability')^^^
<...>
STATUS: *UPDATED*
----------------------------------------------------------------------
COMMENT SET #3/7:
----------------------------------------------------------------------
- [Eugene: Dec 8, 2004] - *SEE INDIVIDUAL RESOLUTIONS*
http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01453.html
Email Subject: Comments on draft-ietf-ipcdn-pktc-signaling-07.txt
Issues: Numerous
RESOLUTION:
#1 *Accepted*: pktcCodecType ->
Change Description to reflect LCO instead of LCD.
PktcCodecType ::= TEXTUAL-CONVENTION
<...>
DESCRIPTION
<...>
The literal codec name is the second column of the table
with codec RTP Map Parameters. Literal Codec Name Column
contains the codec name used in the local connection
options(LCO) of the NCS messages create connection
^^(Used to be 'Local connection descriptor(LCD))^^^
<...>
STATUS: *UPDATED*
#2-I *No Change*:
Only the bits mentioned within the length depicted by the length
field (first two octets) hold good for the cadence, the rest do
not affect the cadence and the hence, the note prevents someone
from encoding more octets than as required by the length field.
STATUS: *No Action*
#2-II *Already addressed*: See COMMENT SET #2/7
STATUS: *No Action*
#3: *Pending WG Consensus*
Propose to change 'pktcNcsEndPntConfigTSMax' as shown below:
pktcNcsEndPntConfigTSMax
<...>
DESCRIPTION
" This MIB object is used as part of an NCS
retransmission algorithm. Prior to any retransmission,
the MTA must check to make sure that the time elapsed
since the sending of the initial datagram does not exceed
the value specified by this MIB Object. If more than
Tsmax time has elapsed, then the retransmissions MUST
cease.
Refer to the MIB Object pktcNcsEndPntConfigThist for
Information on when the endpoint becomes disconnected."
<...>
STATUS: *UPDATED*
#4: *Pending WG Consensus*
Propose to change the description of 'pktcNcsEndPntConfigTdinit'
as shown below:
pktcNcsEndPntConfigTdinit
<...>
"This MIB object represents the 'disconnected' initial
waiting delay within the context of an MTA's 'disconnected
procedure'. The 'disconnected procedure' is initiated when
an endpoint becomes 'disconnected' while attempting to
communicate with a Call Agent.
The 'disconnected timer' associated with the 'disconnected
Procedure' is initialized to a random value, uniformly
distributed between zero and the value contained in this
MIB Object.
For more information on the usage of this timer, please
refer to the PacketCable NCS Specification."
<...>
STATUS: *UPDATED*
#5: *Pending WG Consensus*
Propose to change 'pktcNcsEndPntConfigTdmin' as shown below:
pktcNcsEndPntConfigTdmin
<...>
DESCRIPTION
"This MIB object represents the 'disconnected' minimum
waiting delay within the context of an MTA's 'disconnected
procedure', specifically when local user activity is
detected.
The 'disconnected procedure' is initiated when
an endpoint becomes 'disconnected' while attempting to
communicate with a Call Agent.
For more information on the usage of this timer, please
refer to the PacketCable NCS Specification."
<...>
STATUS: *UPDATED*
#6 *Pending Approval*
Change the description of the following MIB Objects as shown below:
pktcNcsEndPntConfigMinHookFlash
<...>
DESCRIPTION
"This is the minimum time a line needs to be on hook for a
valid hook flash. The value of this object MUST be
greater than the value of
pktcNcsEndPntConfigPulseDialMaxBreakTime. The value of
pktcNcsEndPntConfigMinHookFlash MUST be less than
pktcNcsEndPntConfigMaxHookFlash. This object MUST only be
set via the configuration file during the provisioning
process.
Furthermore, given the possibility for the 'pulse dial'
and 'hook flash' to overlap, the value of this object MUST
be greater than the value contained by the MIB Object
pktcNcsEndPntConfigPulseDialMaxMakeTime."
<...>
STATUS: *UPDATED*
pktcNcsEndPntConfigPulseDialMaxMakeTime
<...>
DESCRIPTION
" This is the maximum make pulse width for the dial pulse.
The value of pktcNcsEndPntConfigPulseDialMaxMakeTime MUST
be greater than pktcNcsEndPntConfigPulseDialMinMakeTime.
This object MUST only be set via the configuration file
during the provisioning process.
Furthermore, given the possibility for the 'pulse dial'
and 'hook flash' to overlap, the value of this object MUST
be less than the value contained by the MIB Object
pktcNcsEndPntConfigMinHookFlash."
<...>
STATUS: *UPDATED*
#7 *No Change*
'Alerting Signal', 'Special Dial', 'Special Info', 'release',
'congestion' & userDefined 1-4 are defined as part of the
following ETSI document:
TS 101 909-4 v1.4.1 (2004-05) (Thanks to Gordon Beacham &
Phillip Freyman for the information)
STATUS: *NO ACTION*
#8 *Pending WG Consensus*
Change the 'default value' of:
pktcSigDevCIDMode from 'dtAsETS' to ' rpAsETS'
pktcSigDevCIDMode OBJECT-TYPE
<...>
DEFVAL { rpAsETS }
STATUS: *UPDATED*
-----------------------------------------------------------------------
COMMENT SET #4/7:
----------------------------------------------------------------------
+ [Gordon: Jan 06, 2005] - *PROPOSAL ACCEPTED BY GORDON*
http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01460.html
Email Subject: IETF NCS Sig MIB Tone Table
Issue: Suggest introduction of a new MIB table pktcSigDevToneEntry
RESOLUTION:
- [Randy: Jan 06 2005]
http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01466.html
- [Eugene: Jan 12, 2005]
http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01493.html
- [Gordon: Jan 17, 2005]
http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01517.html
Suggestion:
- Move 'pktcSigDevToneType' out of 'pktcSigDevToneTable' and define it
as a MIB Object within 'pktcSigDevConfigObjects'
- Move 'pktcSigDevToneNumFrequencies' out of 'pktcSigDevToneTable' and
define it as a MIB Object within 'pktcSigDevConfigObjects'
pktcSigDevToneNumFrequencies OBJECT-TYPE
SYNTAX INTEGER(5..16)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This MIB Object specifies the number of frequencies
supported by the PacketCable MTA for each tone type."
::={ pktcSigDevConfigObjects 33}
Replace the current definition of 'PktcSigDevToneEntry' with the
following common elements (across all tone types):
PktcSigDevToneEntry ::= SEQUENCE {
pktcSigDevToneDbLevel TenthdBm,
pktcSigDevToneWholeToneRepeatCount Unsigned32,
pktcSigDevToneSteady TruthValue
}
The above will be indexed by 'pktcSigDevToneType' as done today.
Introduce a table to handle the multiple frequencies for each tone type,
as defined below:
PktcSigDevMultiFreqToneEntry ::= SEQUENCE {
pktcSigDevToneFrequencyNumber Unsigned32 ,
pktcSigDevToneFreqPriCompValue Unsigned32,
pktcSigDevToneFreqSecCompValue Unsigned32,
pktcSigDevToneFreqSecCompMode INTEGER,
pktcSigDevToneFreqSecCompPrtg Integer32,
pktcSigDevToneFreqOnDuration Unsigned32,
pktcSigDevToneFreqOffDuration Unsigned32,
pktcSigDevToneFreqRepeatCount Unsigned32
}
The above would be indexed by both 'pktcSigDevToneType' and
'pktcSigDevToneFrequencyNumber'.
The entire table is reproduced below:
pktcSigDevMultiFreqToneTable OBJECT-TYPE
SYNTAX SEQUENCE OF PktcSigDevMultiFreqToneEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
" 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."
REFERENCE
"NCS Specification, TS 101 909-4 Specification"
::= { pktcSigDevConfigObjects 35 }
pktcSigDevMultiFreqToneEntry OBJECT-TYPE
SYNTAX PktcSigDevMultiFreqToneEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
" The different tone types with multiple frequencies
that can be provisioned based on country specific needs."
INDEX { pktcSigDevToneType, pktcSigDevToneFrequencyNumber }
::= { pktcSigDevMultiFreqToneTable 1 }
PktcSigDevMultiFreqToneEntry ::= SEQUENCE {
pktcSigDevToneFrequencyNumber Unsigned32 ,
pktcSigDevToneFreqPriCompValue Unsigned32,
pktcSigDevToneFreqSecCompValue Unsigned32,
pktcSigDevToneFreqSecCompMode INTEGER,
pktcSigDevToneFreqSecCompPrtg Integer32,
pktcSigDevToneFreqOnDuration Unsigned32,
pktcSigDevToneFreqOffDuration Unsigned32,
pktcSigDevToneFreqRepeatCount Unsigned32
}
pktcSigDevToneFrequencyNumber OBJECT-TYPE
SYNTAX Unsigned32(5..16)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This MIB Object represents the frequency reference
of a multi-frequency tone. It is to be noted that
the maximum number of frequencies for a
multi-frequency tone is limited by the MIB Object
pktcSigDevToneNumFrequencies."
::={ pktcSigDevMultiFreqToneEntry 1}
pktcSigDevToneFreqPriCompValue OBJECT-TYPE
SYNTAX Unsigned32(0..4000)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This MIB Object represents the value of the primary
component frequency specific to the frequency reference
of a tone type."
::={ pktcSigDevMultiFreqToneEntry 2}
pktcSigDevToneFreqSecCompValue OBJECT-TYPE
SYNTAX Unsigned32(0..4000)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This MIB Object represents the value of the secondary
component frequency specific to the frequency reference
of a tone type."
::={ pktcSigDevMultiFreqToneEntry 3}
pktcSigDevToneFreqSecCompMode OBJECT-TYPE
SYNTAX INTEGER {
ignoreSecondary (1),
primaryModulatedBySecondary (2),
primarySummedWithSecondary (3)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This MIB Object indicates the way the primary
and secondary frequency components indicated
by the MIB Objects 'pktcSigDevToneFreqPriCompValue'
and 'pktcSigDevToneFreqSecCompValue' are to be used.
A value of primaryModulatedBySecondary(2) indicates
that the primary must be used to amplitude modulate
the secondary. The percentage of amplitude modulation
to be applied to the secondary is defined by the MIB
Object 'pktcSigDevToneFreqSecCompPrtg'.
A value of primarySummedWithSecondary(3) indicates
that the primary must be summed with the secondary,
without any modulation
A value of ignoreSecondary(1) indicates that the
secondary must not be used."
::={ pktcSigDevMultiFreqToneEntry 4}
pktcSigDevToneFreqSecCompPrtg OBJECT-TYPE
SYNTAX Integer32(0..100)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This MIB Object represents the percentage of amplitude
modulation applied to the secondary frequency component
when the MIB Object 'pktcSigDevToneFreqSecCompMode' is
set to a value of 'primaryModulatedBySecondary(2)'.
In all other cases this MIB Object has no meaning."
::={ pktcSigDevMultiFreqToneEntry 5}
pktcSigDevToneFreqOnDuration OBJECT-TYPE
SYNTAX Unsigned32(0..5000)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This MIB Object represents the duration for which the
frequency reference corresponding to the tone type
is turned on."
::={ pktcSigDevMultiFreqToneEntry 6}
pktcSigDevToneFreqOffDuration OBJECT-TYPE
SYNTAX Unsigned32(0..5000)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This MIB Object represents the duration for which the
frequency reference corresponding to the tone type
is turned off."
::={ pktcSigDevMultiFreqToneEntry 7}
pktcSigDevToneFreqRepeatCount OBJECT-TYPE
SYNTAX Unsigned32(0..5000)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This MIB Object indicates the number of times
to repeat the cadence cycle represented by the
on/off durations (refer to the MIB Objects
pktcSigDevToneFreqOnDuration and
pktcSigDevToneFreqOffDuration).
Setting this object may result in a tone duration
longer or shorter than the overall signal duration
specified by the time out (TO) object for the
corresponding tone type. If the value of this MIB
Object indicates a longer duration than the
specified by the TO, the latter overrules the former
and the desired tone duration will be truncated according
to the TO.
However, if the repeat count results in a shorter
tone duration than the signal duration specified by
the TO, the tone duration defined by the repeat count
takes precedence over the TO and will end the signal
event. In this case, the TO represents a time not to
be exceeded for the signal. It is recommended to
ensure proper telephony signaling that the TO
duration setting should always be longer than the
desired repeat count time duration. A value of zero
means the tone sequence is to be played once but not
repeated."
::={ pktcSigDevMultiFreqToneEntry 8}
STATUS: *TBD*
-----------------------------------------------------------------------
COMMENT SET #5/7:
----------------------------------------------------------------------
+ [Eugene: Jan 19, 2005] - *Pending Approval*
http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01519.html
Email Subject: pktcSigDevToneWholeToneRepeatCount description
in draft-07 of the Signaling MIB
Issue: Comments related to 'pktcSigDevToneTable' and
'pktcSigDevToneWholeToneRepeatCount'
RESOLUTION:
- [Randy: Jan 19, 2005]
http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01520.html
- [David: Jan 20, 2005]
http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01521.html
- [Randy: Jan 20,2005]
http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01522.html
- [Eugene: Jan 20, 2005]
http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01523.html
- [Randy: Jan 20, 2005]
http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01524.html
- [David: Jan 21, 2005]
http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01531.html
Suggestion:
*Remove* the following statement from the definition of:
'pktcSigDevToneTable'
"If the pktcSigDevToneType is callWaiting1-4, the
pktcSigDevToneWholeToneRepeatCount does not apply
and MUST be ignored on SNMP get/set operations."
*Add* the following to the description of the MIB Object '
pktcSigDevToneWholeToneRepeatCount':
"If the pktcSigDevToneType is set to either of the values
callWaiting1, callWaiting2, callWaiting3 or callWaiting4,
then the value of the pktcSigDevToneWholeToneRepeatCount
object has no effect on the tone."
STATUS: *UPDATED*
-----------------------------------------------------------------------
COMMENT SET #6/7:
----------------------------------------------------------------------
+ [David: Jan 21, 2005] - *Pending Approval*
http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01530.html
Subject: pktcSigDevCodecTable request for clarification
Issue: Suggestions related to pktcSigDevCodecTable
RESOLUTION:
- [Jean-Francois: Jan 21, 2005]
http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01535.html
- [David: Jan 24, 2005]
http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01543.html
- [Jean-Francois: Jan 25, 2005]
http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01554.html
- [David: Jan 25, 2005]
http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01555.html
Suggestion:
Include the following statement to the description of the MIB Table '
pktcSigDevCodecTable'
"....This table MUST NOT include non-voice codecs...."
On a related note, CODEC Types 'other' and 'unknown' are defined as:
other a defined codec not in the enumeration
unknown a codec not defined in PacketCable
Assuming 'other' is a possible new CODEC defined by PacketCable, but not
in the enumeration and 'unknown' is a CODEC not defined at all by
PacketCable - is it ok to keep both?
STATUS: *UPDATED*
-----------------------------------------------------------------------
COMMENT SET #6/7:
----------------------------------------------------------------------
+ [David: Jan 21, 2005] - *Pending Approval*
http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01530.html
Subject: Add new MIBs for dynamic gain plan negotiation and
clarify the MIB Object 'pktcSigDevToneDbLevel'.
Issue: Suggest adding 'pktcNcsEndPntConfigTxGain' and
'pktcNcsEndPntConfigRxGain' as new MIB Objects,
part of the table 'pktcNcsEndPntConfigEntry'.
RESOLUTION:
- [Phil: Feb 15, 2005]
http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01591.html
- [Rich: Feb 15, 2005]
http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01592.html
- [Phil: Feb 17, 2005]
?? [This email was not found in the archives, but is reproduced
at the end of this email] -- Attachment 1
Suggestion:
Add the following MIB Objects:
pktcNcsEndPntConfigTxGain OBJECT-TYPE
SYNTAX Integer32
UNITS "dB"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This MIB Object represents the per line transmitter (A/D)
gain. A positive number reflects a signal gain, a negative
number reflects a signal loss. This MIB Object may provision
the gain or it may be used to document a non-provisionable
gain between the telco (POTS) a-b (T/R) terminals and the
analog codec maximum PCM coding limit (PCM maximum coding
limit). Based on the default G.711 Vocoder maximum of 3.14
or 3.17 dBm the -4 dB gain default provides Vocoder coding
protection against TE maximum signals while also providing
an initial loss to minimize analog signal echo. "
DEFVAL { -4 }
::= { pktcNcsEndPntConfigEntry 39 }
pktcNcsEndPntConfigRxGain OBJECT-TYPE
SYNTAX Integer32
UNITS "dB"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This MIB Object represents the per line receiver (D/A)
gain. A positive number reflects a signal gain, a negative
number reflects a signal loss. This MIB Object may provision
the gain or it may be used to document a non-provisionable
gain for use with the pktcSigDevToneDbLevel Object to set
the desired level at the a-b (T/R) terminals.
The default values are based on the deployed markets. Some
recommendations are made as follows:
- Based on the default G.711 Vocoder maximum of 3.14 or 3.17
dBm a default value of '-4 dB' provides a maximum analog
signal level at the a-b (T/R) termination point
- Based on [ETSI TS 101 909-4], which provides guidance of
11 dB loss (-11 dB gain), a default value of '-11 dB' is
recommended."
::= { pktcNcsEndPntConfigEntry 40 }
Change the description of 'pktcSigDevToneDbLevel' to the following:
pktcSigDevToneDbLevel OBJECT-TYPE
SYNTAX TenthdBm (-250..-30)
UNITS "dBm"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This MIB Object contains the decibel level for each
analog signal (tone) that is locally generated
versus in band supervisory tones) and sourced to
the a-b terminals (TE connection point). Each tone
in itself may consist of multiple frequencies as
defined by the MIB table
'pktcSigDevMultiFreqToneTable'.
This MIB Object MUST reflect the desired level at
the Telco (POTS) a-b (T/R) terminals including the
affect of the pktcNcsEndPntConfigRxGain setting on
the delivered tone.
The wide range of levels for this Object is required
to provide signal generator levels across the wide
range of gains - but does not imply the entire range
is to be achievable given the range of negative
values of gain (positive loss). This MIB Object must
be set for each tone so as to generate the combined
frequency level at the a-b (T/R) terminals."
STATUS: *UPDATED*
-----------------------------------------------------------------------
Changes not part of the comment set include:
- Editorial changes - date/compilation date etc.
- Patent disclosure as per the email from Jean-Francois
[http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01593.html] led
to the check for compliance with Section 5 of RFC 3668
http://www.ietf.org/rfc/rfc3668.txt]. Accordingly, the section formerly
titled 'Intellectual Property' is now named 'Disclaimer of validity' and
the contents updated.
- Added PacketCable 1.5 to reflect the Jan, 2005 release
Attachment:
----------
From: Freyman Phillip-FPF300 [phillipfreyman at motorola.com]
Sent: Thu 2/17/2005 11:07 PM
To: Richard Woundy @ Comcast
cc: Sumanth Channabasappa; 'ipcdn at ietf.org'
RE: [ipcdn] IETF NCS Sig MIB Gain (loss) plan and tone Levels
thanks Rich for the comments...you raise the question of future
migration and use of the proposal.
the Tx and Rx levels vary based on locale (N.A. vs Euro vs Asia vs
national standards), by providing MIB variables, this enable common
designs to be applicable across national boundaries (but within an
operators business area). In this case it may be desireable to set the
loss plans for one operator or even for one user (down to a single line
number) without any need to adapt the loss in the future.
In fact, it has been seen that some TE (CPE) devices detect the MTA loop
current and based on the loop current they adjust their internal analog
gain/loss. Essentially relating low local loop current/voltage to high
analog signal loss. So if the MTA is configured to provide a minimum
loop current (good to minimize power consumption), CPE devices may
actually add gain to compensate for the historical analog loop signal
loss (bad for MTAs configured with high analog levels (small loss plans)
per current PacketCable guidance).
Should it become desireable to support an adaptable loss plan (per
connection type or service type within a connection) then this change
would fall under the signalling protocol "solution". It would seem
logical that these adaptations would only be in effect for the duration
of the connections or might even change within a single connection
(start of call in voice mode with one loss, respond to a fax mode with a
second loss and at the end of the fax to adapt back to the voice mode
loss). This adaptive loss would only be applicable during a single
session since any change in loss would be related to a specific far end
(short to long analog POTS loop variability) of that connection. After
the connection is terminated then the loss plan should revert to the
SigMIB settings in preparation for the next call which may be within the
VoIP network or may again be routed to another analog POTS loop.
So there are three rationals for the MIB loss plan flexibility with two
potential results...
a "one time" setting based on local operator/user needs (local standards
or loop current) and ...
a future potential need for adaptive loss plan adjustments related to a
specific far end connection requirement.
hope this explains the concept in more detail and the relationship
between the MIB values verses a future protocol defined value.
Phil
_______________________________________________
IPCDN mailing list
IPCDN at ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn