[ipcdn] Changes to draft-ietf-ipcdn-pktc-signaling-11
"Sumanth Channabasappa" <sumanth@CableLabs.com> Fri, 16 June 2006 15:36 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrGMm-0005Ws-LA; Fri, 16 Jun 2006 11:36:12 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrGMk-0005Va-Iv for ipcdn@ietf.org; Fri, 16 Jun 2006 11:36:10 -0400
Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrGMk-0007Fy-45 for ipcdn@ietf.org; Fri, 16 Jun 2006 11:36:10 -0400
Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.6/8.13.6) with ESMTP id k5GFa832029830 for <ipcdn@ietf.org>; Fri, 16 Jun 2006 09:36:09 -0600 (MDT)
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: Fri, 16 Jun 2006 09:36:08 -0600
Message-ID: <CD6CE349CFD30D40BF5E13B3E0D8480401844B97@srvxchg.cablelabs.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Changes to draft-ietf-ipcdn-pktc-signaling-11
Thread-Index: AcaP68+fwbfnjLoQQ7qQONaSPjyJBgBZbMrwAAIdfLA=
From: Sumanth Channabasappa <sumanth@CableLabs.com>
To: ipcdn@ietf.org
X-Approved: ondar
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a8041eca2a724d631b098c15e9048ce9
Subject: [ipcdn] Changes to draft-ietf-ipcdn-pktc-signaling-11
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>
Errors-To: ipcdn-bounces@ietf.org
Folks, Find enclosed the changes incorporated into "draft-ietf-ipcdn-pktc-signaling" (http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-signaling-11. txt). regards Sumanth Change #1/3: New MIB Object ----------- > Rationale: Excerpts from the email sent by Phillip Freyman to the IPCDN reflector (dated 3/29) <!-- Addition of a new MIB Object pktcSigDevrpAsDtsDuration - this international object sets the duration of the ring pulse alerting signal prior to CID signaling. Variations in national standards cause CID failure if RP-AS is not defined by local requirements. --> <!-- Reason A situation has been raised in Belgium where the local telephony requirements exceed the ETSI EN 300 369-1 definition for RP-AS In the ETSI document RP-AS is defined as 200 ms to 300 ms in duration. In the Belgium Belgacom document the RP-AS is implied as being 340 ms and in field experience this as been verified. Some CPE devices do not respond if the RP-AS is less than 340 ms. It does not appear that the maximum ETSI value of RP-AS is adequate and it does not appear that placing CID during the normal ring cadence is acceptable. We therefore have two standards which do not overlap and therefore we must define a new SigMIB object to define the RP-AS duration from the ETSI 200 ms min to something in excess of the Belgacom nominal value of 340 ms. --> > Proposed addition pktcSigDevrpAsDtsDuration OBJECT-TYPE SYNTAX Unsigned32 (0|200..500) UNITS "Milliseconds" MAX-ACCESS read-write STATUS current DESCRIPTION " This object specifies the duration of the rpASDTS ring pulse prior to the start of the transmission of the FSK or DTMF containing the Caller ID information. It is only used when 'pktcSigDevCidMode' is set to a value of 'rpAsETS'. The following table defines the default values for this MIB Object, depending on the signal type (pktcSigDevCidMode) and MUST be followed: Value of 'pktcSigDevCidMode' Default value duringringingETS 0 (not used) dtAsETS 0 (not used) rpAsETS 250 lrAsETS 0 (not used) lrETS 0 (not used) An attempt to set this object while the value of pktcSigDevCidMode is not 'rpAsETS' will result in an 'inconsistent value' error." REFERENCE "ETSI-EN-300-659-1 Specification and Belgacom BGC_D_48_9811_30_09_EDOC version 3.3" DEFVAL { 250 } ::= {pktcSigDevConfigObjects 41 } Change #2/3: Modifications to existing MIB Objects ----------- > Rationale: Comments from Randy Presuhn (3/30, 3/31), Richard Woundy (3/30, 3/31) and Phillip Freyman (3/31) and offline discussions between authors and primary contributors <!-- Discussion summary Randy requested clarification on the processing of MIB Objects that are 'not used' in certain scenarios. Further clarifications and discussions revealed that there was a need to clarify 'not used' and its affect on GET/GETBULK and SET requests. The authors discussed this issue (offline as well) and decided to clarify this by: - Defining a 'default value' to indicate 'not used' scenarios - Mandating an 'inconsistent value' error in case a SET was performed on a MIB Object that is 'not used' due to certain constraints --> > Changes were affected to: pktcSigPulseSignalRepeatCount pktcSigDevCidAfterRing pktcSigDevCidAfterDTAS pktcSigDevCidAfterRPAS pktcSigDevRingAfterCID pktcSigDevCidDTASAfterLR pktcSigDevVmwiAfterDTAS pktcSigDevVmwiAfterRPAS pktcSigDevVmwiDTASAfterLR pktcSigDevCidDelayAfterLR pktcSigDevVmwiDelayAfterLR pktcSigDevrpAsDtsDuration Note: - A default value of '0' was chosen in all cases (or a range of 0-0 in the first mentioned object) - A clarification was provided to indicate when a MIB Object is used E.g. pktcSigDevCidAfterRing <snip> It is only used when pktcSigDevCidMode is set to a value of 'duringRingingETS' <snip> - A normative requirement was added to follow table descriptions for default values. E.g. pktcSigDevCidAfterRing <snip> The following table defines the default values for this MIB Object, depending on the signal type (pktcSigDevCidMode) and MUST be followed: Value of 'pktcSigDevCidMode' Default value duringringingETS 550 ms dtAsETS 0 (not used) rpAsETS 0 (not used) lrAsETS 0 (not used) lrETS 0 (not used) <snip> Change #3/3: Editorial and other changes ----------- - Added the new MIB OBject to the MIB group 'pktcInternationalGroup' - Corrected the incorrect reference to 'pktcSigDevCidMode' in pktcSigDevVmwiDelayAfterLR - correct reference 'pktcSigDevVmwiDelayAfterLR' - Updated the draft details (date etc) - other minor editorials Changes as per Rich Woundy's comments (thanks!) ---------------------------------------------- - Updated references for pktcSigDevCidDtmfStartCode, pktcSigDevCidDtmfEndCode, pktcSigDevVmwiDtmfStartCode, and pktcSigDevVmwiDtmfEndCode from "[ETSI-EN.*]" to "ETSI-EN.* specification" - Removed 'NOT RECOMMENDED' from list of keywords - Updated RFC 3291 to RFC 4001 (and removed note regarding " <draft-ietf-ops-rfc3291bis-01.txt") Changes not incorporated: ------------------------- idnits indicates the following 'experimental warnings' that were ignored (since they are referenced): - Unused Reference: 'ETSI-TS-101-909-4' is defined on line 3317, but not referenced' [ETSI-TS-101-909-4] ETSI TS 101 909-4:"Access and Terminals (AT);' - Unused Reference: 'ETSI-EN-300-324-1' is defined on line 3336, but not referenced '[ETSI-EN-300-324-1] ETSI EN 300 324-1 V2.1.1 (2000-04):"V Interfaces' _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn
- [ipcdn] Changes to draft-ietf-ipcdn-pktc-signalin… Sumanth Channabasappa