[ipcdn] [PKT-SIG-MIB] Draft 08 (Summary Of Changes)
"Sumanth Channabasappa" <sumanth@cablelabs.com> Mon, 21 February 2005 05:30 UTC
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23152 for <ipcdn-archive@ietf.org>; Mon, 21 Feb 2005 00:30:52 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D36W0-0005if-T7 for ipcdn-archive@ietf.org; Mon, 21 Feb 2005 00:53:53 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D364G-00071R-1E; Mon, 21 Feb 2005 00:25:12 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D35qs-0002Fj-K0 for ipcdn@megatron.ietf.org; Mon, 21 Feb 2005 00:11:23 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21356 for <ipcdn@ietf.org>; Mon, 21 Feb 2005 00:11:14 -0500 (EST)
Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D36D0-00058q-8Q for ipcdn@ietf.org; Mon, 21 Feb 2005 00:34:15 -0500
Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id j1L5AhDU026901 for <ipcdn@ietf.org>; Sun, 20 Feb 2005 22:10:43 -0700 (MST)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Sun, 20 Feb 2005 22:10:43 -0700
Message-ID: <CD6CE349CFD30D40BF5E13B3E0D848047E6B41@srvxchg.cablelabs.com>
Thread-Topic: [PKT-SIG-MIB] Draft 08 (Summary Of Changes)
Thread-Index: AcS4BwAcFjCPHdLkSGC/E2+ckCFo7ACPG54gF2NcadA=
From: Sumanth Channabasappa <sumanth@cablelabs.com>
To: ipcdn@ietf.org
X-Approved: ondar
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1de2149c0c23c6675e98c918b359cf3
Content-Transfer-Encoding: quoted-printable
Subject: [ipcdn] [PKT-SIG-MIB] Draft 08 (Summary Of Changes)
X-BeenThere: ipcdn@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP over Cable Data Network <ipcdn.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>, <mailto:ipcdn-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipcdn@ietf.org>
List-Help: <mailto:ipcdn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>, <mailto:ipcdn-request@ietf.org?subject=subscribe>
Sender: ipcdn-bounces@ietf.org
Errors-To: ipcdn-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ad122f56a92d6ccd133117ee8a4b1ff3
Content-Transfer-Encoding: quoted-printable
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@motorola.com] Sent: Thu 2/17/2005 11:07 PM To: Richard Woundy @ Comcast cc: Sumanth Channabasappa; 'ipcdn@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@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn
- [ipcdn] [PKT-SIG-MIB] Draft 08 (Summary Of Change… Sumanth Channabasappa