[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