Subject: [ipcdn] RE: Publication of PacketCable IETF MIBs - Signaling MIB draft 02

From: Beacham Gordon-CGB005 <[email-masked]>
Date: Fri, 26 Sep 2003 08:55:10 -0700

Eugene, 
My comments on the Sig MIB suggested changes: 
1. I can change the description in pktcSigEndPntCapabilityIndex to refer to the proper table. That is replace "pktcSigCapablityTable" with "pktcSigEndPntConfigTable" in the pktcSigEndPntCapabilityIndex object and "pktcSigEndPntTable" with "pktcSigEndPntConfigTable" in the pktcSigEndPntConfigStatus object.
If we want to delete the table and associated objects I'd like to see additional input from the IPCDN reflector.
2. I agree this object is missing and needs to be added. I would instead recommend the syntax be: 500 to 800 to match the T3 range specified in 300 659-1. 
3. I agree these objects can be added. However, it is not clear to me that an operator would actually use different signaling methods on the SAME line. Just to be clear these additional VMWI objects are for on-hook data transmission not associated with ringing as specified in 300 659-1 section 6.2. 
4. Agree at present. Motorola has not found a scenario where more than 2 freqs are modulated. 
5. Agree with making these objects read-only. 
Gordon 
	-----Original Message-----
	From: Eugene Nechamkin [mailto:[email-masked]]
	Sent: Monday, September 22, 2003 7:28 PM
	To: Beacham Gordon-CGB005; Jean-Francois Mule; Wim De Ketelaere; Woundy, Richard; Sumanth Channabasappa; Satish Kumar at Texas Instruments
	Subject: RE: Publication of PacketCable IETF MIBs - Signaling MIB draft 02
	
	Gordon, 
	The following are comments to draft-02 candidate: 
	1. pktcSigEndPntCapabilityIndex MIB Object has a refernce to the "pktcSigCapablityTable" in description whereas the "pktcSigCapablityTable" does not exist in the SIG MIB. I think the "pktcSigEndPntConfigTable" should be eliminated . 
	2. The following object seems to be required and is currently missing: 
	pktcSigDevCIDFskAfterRPAS 
	SYNTAX Unsigned32 (0..1000) 
	UNITS "Milliseconds" 
	MAX-ACCESS read-write 
	STATUS current 
	DESCRIPTION 
	" This object is used for ETSI systems only. This object 
	specifies the delay between the end of the Ring Pulse Alert 
	Signal (RP-AS) and the start of the transmission of the 
	FSK containing the Caller ID information. This object is 
	only used when pktcSigDevCIDMode is rpAsETS. 
	pktcSigDevCIDMode pktcSigDevCIDFskAfterDTAS 
	duringringingETS 0 ms (not used) 
	dtAsETS 0 ms (not used)
	rpAsETS 650 ms 
	lrAsETS 0 ms (not used)" 
	REFERENCE 
	" Refer to the ETS 300 659-1 Specification." 
	::= { pktcSigPulseSignalEntry ??? } 
	3. "pktcSigDevCIDMode" MIB Object currently refers only to on-hook caller-ID. We do not not have the corresponding object to select the off-hook caller-id method. Proposal is to use a set of the new objects for off-hook params: 
	pktcSigDevVmwiMode OBJECT-TYPE 
	SYNTAX INTEGER {
	dtAsETS(1),
	rpAsETS(2),
	lrAsETS(3)
	}
	MAX-ACCESS read-write
	STATUS current 
	DESCRIPTION 
	" This object is used for ETSI systems only. For visual message
	waiting indicator (VMWI), pktcSigDevVmwiMode selects the alerting signal method. 
	For the dtAsETS, rpAsETS, and lrAsETS
	methods, the FSK containing the VMWI information is
	sent after an alerting signal. For the dtAsETS
	method, the FSK is sent after the Dual Tone Alert Signal.
	For the rpAsETS method, the FSK is sent after a Ring
	Pulse. For the lrAsETS method, the Line Reversal occurs
	first, then the Dual Tone Alert Signal, and finally the
	FSK is sent."
	DEFVAL { dtAsETS } 
	::= {pktcSigDevConfigObjects ??? } 
	pktcSigDevVmwiFskAfterDTAS OBJECT-TYPE 
	SYNTAX Unsigned32 (0..500) 
	UNITS "Milliseconds" 
	MAX-ACCESS read-write 
	STATUS current 
	DESCRIPTION 
	" This object is used for ETSI systems only. This object 
	specifies the delay between the end of the Dual Tone Alert 
	Signal (DT-AS) and the start of the transmission of the 
	FSK containing the VMWI information. This object is 
	only used when pktcSigDevVMWIMode is dtAsETS or lrAsETS. 
	pktcSigDevVMWIMode pktcSigDevVMWIFskAfterDTAS 
	dtAsETS 50 ms 
	rpAsETS 0 ms (not used) 
	lrAsETS 50 ms" 
	REFERENCE 
	" Refer to the ETS 300 659-1 Specification." 
	DEFVAL { 50 } 
	::= {pktcSigDevConfigObjects ?? } 
	pktcSigDevVmwiFskAfterRPAS OBJECT-TYPE 
	SYNTAX Unsigned32 (0..800) 
	UNITS "Milliseconds" 
	MAX-ACCESS read-write 
	STATUS current 
	DESCRIPTION 
	" This object is used for ETSI systems only. This object 
	specifies the delay between the end of the Ring Pulse Alert 
	Signal (RP-AS) and the start of the transmission of the 
	FSK containing the VMWI information. This object is 
	only used when pktcSigDevVMWIMode is rpAsETS. 
	pktcSigDevVMWIMode pktcSigDevVMWIFskAfterDTAS 
	dtAsETS 0 ms (not used)
	rpAsETS 650 ms 
	lrAsETS 0 ms (not used)" 
	REFERENCE 
	" Refer to the ETS 300 659-1 Specification." 
	DEFVAL { 50 } 
	::= {pktcSigDevConfigObjects ??? } 
	pktcSigDevVmwiDTASAfterLR OBJECT-TYPE 
	SYNTAX Unsigned32 (0..655) 
	UNITS "Milliseconds" 
	MAX-ACCESS read-write 
	STATUS current 
	DESCRIPTION 
	" This object is used for ETSI systems only. This object 
	specifies the delay between the end of the Line Reversal 
	and the start of the Dual Tone Alert Signal (DT-AS) for VMWI. This 
	object is only used when pktcSigDevVMWIMode is lrAsETS. 
	pktcSigDevVMWIMode pktcSigDevVMWIFskAfterLR 
	dtAsETS 0 ms (not used) 
	rpAsETS 0 ms (not used) 
	lrAsETS 250 ms" 
	REFERENCE 
	" Refer to the ETS 300 659-1 Specification." 
	DEFVAL { 250 } 
	::= {pktcSigDevConfigObjects ??? } 
	4. Clarification oin on "pktcSigDevToneFreqType" description for "allFrequenciesModulated" mode is required: 
	It seems that it makes sense to have only two frequencies and also an implementor needs to know which frequency modulates which. The clarifying propasal looks as follows: 
	allFrequenciesModulated indicates all frequencies
	specified by pktcSigDevToneNumFrequencies are modulated to
	form a single tone. The tone is then applied in sequence
	using the number of on/off times specified in
	pktcSigDevToneNumOnOffTimes. 
	For this tone type pktcSigDevToneNumFrequencies MUST be equal 2, 
	and the frequency in pktcSigDevToneFirstFrequency modulates the 
	frequency in pktcSigDevToneSecondFrequency."
	5. The following objects should be made "read-only" and configurable only from the MTA CFG File (because of the reasons similar to pktcSigPowerRingFrequency MIB Object): 
	pktcNcsEndPntConfigMinHookFlash, 
	pktcNcsEndPntConfigMaxHookFlash, 
	pktcNcsEndPntConfigPulseDialInterDigitTime, 
	pktcNcsEndPntConfigPulseDialMinMakeTime, 
	pktcNcsEndPntConfigPulseDialMaxMakeTime, 
	pktcNcsEndPntConfigPulseDialMinBreakTime, 
	and pktcNcsEndPntConfigPulseDialMaxBreakTime 
	Thanks, 
	Eugene.

Gordon Beacham
Digital Core Gateways, BCS
Motorola, Inc.
858-404-2335
[email-masked]

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

---

From: Beacham Gordon-CGB005 <[email-masked]>
Date: Tue, 30 Sep 2003 07:57:22 -0700

fyi,
 
Additional changes proposed to the Signaling MIB. These will be incorporated into the draft-02 version.
 
Gordon
-----Original Message-----
From: Eugene Nechamkin [mailto:[email-masked]]
Sent: Monday, September 29, 2003 2:43 PM
To: Beacham Gordon-CGB005
Cc: Jean-Francois Mule; Wim De Ketelaere; Woundy, Richard; Sumanth Channabasappa; Satish Kumar at Texas Instruments
Subject: Publication of PacketCable IETF MIBs - Signaling MIB draft 02

Gordon,
 
After looking at the NCS Signaling MIB (draft-2) some more, here are additional comments (mods are in red):
 
1. For pktcNcsEndPntConfigMinHookFlash object, the DESCRIPTION clause should say:
 
" This is the minimum time a line needs to be on hook for a valid hook flash. The vaule of this object MUST be greater than the value of the pktcNcsEndPntConfigPulseDialMaxBreakTime."
 
2. ETSI EG 201 188, section 8.1 indicates that an onhook event should be detected if the loop is open for greater than 500ms. This seems to contradict pktcNcsEndPntConfigMaxHookFlash which has a range of 20-1800ms and a default value of 1000ms. I think we need to make the range to be compliant with the requirement, i.e.
 
   pktcNcsEndPntConfigMaxHookFlash    OBJECT-TYPE
       SYNTAX       Unsigned32 (20..500)

3. As "pktcSigDevToneTable" contains delay between audiable tones and repetition counters for callWaiting1..4 which belong to the tone profile generation, and there also independent objects controlling delays and repetition counters outside of this table (pktcNcsEndPntConfigCallWaitingDelay, and pktcNcsEndPntConfigCallWaitingMaxRep), I think, to redulce the potential for ambigous understanding,  the following clarification in DESCRITION clause of the "pktcSigDevToneTable" would help:
 
   pktcSigDevToneTable    OBJECT-TYPE
       SYNTAX       SEQUENCE OF PktcSigDevToneEntry
       MAX-ACCESS   not-accessible
       STATUS       current
       DESCRIPTION
           " The Tone Table defines the various tone operations.
             Any definition of the tone in this table, should not 
            contain the delay between tones or the tone repeat count, 
            but instead just the definition of the audible tone itself.
            The delay between tones or the repeat count is controlled 
            by the MIB Objects pktcNcsEndPntConfigCallWaitingDelay,
            and pktcNcsEndPntConfigCallWaitingMaxRep.
            Objects in this table do not persist across an MTA
             reboot. "

Eugene.