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

From: "Eugene Nechamkin" <[email-masked]>
Date: Fri, 26 Sep 2003 16:24:38 -0700

Gordon,

1. Agreed on your proposal. More importantly though to get the intention of the "pktcSigEndPntConfigTable" clarified. It's still an outstanding issue.

2. Agreed.

3. Yes, this is 300 659-1, section 6.2. The ETSI spec actually states "It is a network operator option as to which method is being used; nevertheless, it shall be the same method as used for data transmission associated with ringing (see subclause 6.1.2), in case a network operator uses a prior to ringing method for it." So, it's possible that a network operator could choose to use "data transmission during ringing" for data transmission associated with ringing. This option doesn't exist for VMWI. Therefore, it's necessary to have separate "pktcSigDevCIDMode" and "pktcSigDevVMWIMode" MIB objects.

Eugene.

-----Original Message-----
From: Beacham Gordon-CGB005 [mailto:[email-masked]]
Sent: Friday, September 26, 2003 1:59 PM
To: 'Ipcdn (E-mail)'
Subject: [ipcdn] RE: RE: Publication of PacketCable IETF MIBs -
Signaling MIB draf t 02

My appologies. Correction on item 1 as follows: replace pktcSigCapablityTable with pktcSigCapabilityTable in the pktcSigEndPntCapabilityIndex object only.

Gordon

>  -----Original Message-----
> From: 	Beacham Gordon-CGB005  
> Sent:	Friday, September 26, 2003 8:55 AM
> To:	Ipcdn (E-mail)
> Subject:	RE: Publication of PacketCable IETF MIBs - Signaling MIB draft 02
> 
> 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

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