Subject: RE: [ipcdn] SigMIB Draft 10

From: "Woundy, Richard" <[email-masked]>
Date: Thu, 30 Mar 2006 12:00:29 -0500

Phillip,
 
Pardon my ignorance with this question. What is the difference between
the proposed object below ('pktcSigDevrpAsDtsDuration') and the
'pktcSigDevCidAfterRPAS' in the current -10 draft?
 
I am not so much opposed to this change, I just want to understand the
rationale better.
 
And since our WG only has two work items left, I would like to finish
this document and get it published.
 
-- Rich

-----Original Message-----
From: Freyman Phillip-FPF300 [mailto:[email-masked]] 
Sent: Tuesday, March 28, 2006 4:53 PM
To: [email-masked]
Subject: [ipcdn] SigMIB Draft 10

Colleagues,

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.

In the following text draft, I have defined a new object (#41) with a
range of 200-500 ms.

Page 7 Add:

   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.

Page 44 Add:

   pktcSigDevrpAsDtsDuration     OBJECT-TYPE 

       SYNTAX       Unsigned32 (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 rpAsETS. The  

             following table defines the default values for this object

             depending on the signal type: 

             pktcSigDevCidMode     Default 

             duringringingETS      not used 

             dtAsETS               not used 

             rpAsETS               250 

             lrAsETS               not used 

             lrETS                 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 } 

Page 60 Add last line

   pktcInternationalGroup    OBJECT-GROUP  

       OBJECTS {  

       pktcNcsEndPntConfigMinHookFlash,  

       pktcNcsEndPntConfigMaxHookFlash,  

       pktcNcsEndPntConfigPulseDialInterdigitTime,  

       pktcNcsEndPntConfigPulseDialMinMakeTime,  

       pktcNcsEndPntConfigPulseDialMaxMakeTime,  

       pktcNcsEndPntConfigPulseDialMinBreakTime,  

       pktcNcsEndPntConfigPulseDialMaxBreakTime, 

       pktcSigDevRingCadence,  

       pktcSigDevCidSigProtocol,  

       pktcSigDevCidDelayAfterLR, 

       pktcSigDevCidDtmfStartCode, 

       pktcSigDevCidDtmfEndCode, 

       pktcSigDevVmwiSigProtocol, 

       pktcSigDevVmwiDelayAfterLR, 

       pktcSigDevVmwiDtmfStartCode, 

       pktcSigDevVmwiDtmfEndCode, 

       pktcSigDevrpAsDtsDuration,

I understand it may delay Draft 10 but I think it is necessary.

Regards,

Phillip Freyman
Distinguished Member of the Technical Staff
Science Advisory Board Associate
Motorola, Inc.
Connected Home Solutions IPS
IP System Engineering
21440 West Lake Cook Road
Deer Park, IL 60010

_______________________________________________
IPCDN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipcdn

---

From: "Freyman Phillip-FPF300" <[email-masked]>
Date: Thu, 30 Mar 2006 11:16:50 -0600

Richard,
 
thanks for the comment
 
Per the current Draft:
 
   pktcSigDevCidAfterRPAS - this international object sets the delay 

   between the ring pulse alert signal and the transmission of caller 

   id information. 

where as

   requirements.

rpAsDtsDuration is how long the RP-AS is applied
 
CidAfterRPAS is the delay (pause) between the RP-AS and the CID
 
Hopefully this explains the differences?
 
Phil

________________________________

From: Woundy, Richard [mailto:[email-masked]] 
Sent: Thursday, March 30, 2006 11:00 AM
To: Freyman Phillip-FPF300; [email-masked]
Subject: RE: [ipcdn] SigMIB Draft 10

Phillip,

 
 
-- Rich

	-----Original Message-----
	From: Freyman Phillip-FPF300
[mailto:[email-masked]] 
	Sent: Tuesday, March 28, 2006 4:53 PM
	To: [email-masked]
	Subject: [ipcdn] SigMIB Draft 10

	Colleagues,

	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.

	In the following text draft, I have defined a new object (#41)
with a range of 200-500 ms.

	Page 7 Add:

	   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.

	Page 44 Add:

	       UNITS        "Milliseconds" 

	       MAX-ACCESS   read-write 

	       STATUS       current 

	       DESCRIPTION 

	           " This object specifies the duration of the rpASDTS
ring pulse prior

	             FSK or DTMF containing the Caller ID information.
It is  

	             following table defines the default values for this
object  

	             dtAsETS               not used 

	             rpAsETS               250 

	             lrAsETS               not used 

	             lrETS                 not used 

	       REFERENCE  

	       DEFVAL { 250 } 

	Page 60 Add last line

	       OBJECTS {  

	       pktcSigDevRingCadence,  

	Regards,

	Phillip Freyman

---

From: "Woundy, Richard" <[email-masked]>
Date: Thu, 30 Mar 2006 17:32:22 -0500

Thanks, that makes sense to me.
 
I tend to agree with the direction of Randy Presuhn's comments (copied
below).
 
>What is meant by "not used" in the proposed DESCRIPTION clause?
Specifically, what happens when processing a get(next/bulk) request and
pktcSigDevCidMode is not rpAsETS?
 
Maybe what is implied is "The value of this object is ignored unless
pktcSigDevCidMode is rpAsETS."? I agree that the wording could be
clearer.
 
>Also, what is the motivation for requiring inconsistent value errors
for all set requests when pktcSigDevCidMode is not rpAsETS? If the value
is ignored under those circumstances, it would seem simpler to accept it
as long as it is within the SYNTAX range.
 
I tend to agree. If the value of the object is ignored when
"pktcSigDevCidMode is not rpAsETS", then it should be safe to set the
value of the object. Then this object value could be pre-populated (e.g.
in a config file), and pktcSigDevCidMode could be set to rpAsETS (e.g.
SNMP Set) independently. Although I think this makes sense in theory, I
don't know of a particular use case in practice.
 
Looking at the rest of the -10 draft, there are a *lot* of instances
where 'inconsistent value errors' are returned, just like this proposal:
 
pktcSigDevCidAfterRing: "An attempt to set this object while the value
of pktcSigDevCidMode is not duringringingETS will result in an
'inconsistent value' error."
 
pktcSigDevCidAfterDTAS: "An attempt to set this object while the value
of pktcSigDevCidMode is not dtAsETS or lrAsETS will result in an
'inconsistent value' error."
 
pktcSigDevCidAfterRPAS: "An attempt to set this object while the value
of pktcSigDevCidMode is not rpAsETS will result in an 'inconsistent
value' error."
 
And so forth. Does someone remember why this is specified in this
manner?
 
-- Rich

-----Original Message-----
From: Freyman Phillip-FPF300 [mailto:[email-masked]] 
Sent: Thursday, March 30, 2006 12:17 PM
To: Woundy, Richard; [email-masked]
Subject: RE: [ipcdn] SigMIB Draft 10

Richard,
 
thanks for the comment
 
Per the current Draft:

   id information. 

where as

   requirements.

 
 
Phil

  _____  

Phillip,

 
 
-- Rich

-----Original Message-----
From: Freyman Phillip-FPF300 [mailto:[email-masked]] 
Sent: Tuesday, March 28, 2006 4:53 PM
To: [email-masked]
Subject: [ipcdn] SigMIB Draft 10

Colleagues,

Page 7 Add:

   requirements.

Page 44 Add:

       UNITS        "Milliseconds" 

       MAX-ACCESS   read-write 

       STATUS       current 

       DESCRIPTION 

             dtAsETS               not used 

             rpAsETS               250 

             lrAsETS               not used 

             lrETS                 not used 

       REFERENCE  

       DEFVAL { 250 } 

Page 60 Add last line

       OBJECTS {  

       pktcSigDevRingCadence,  

Regards,

Phillip Freyman