Subject: RE: [ipcdn] IETF NCS Sig MIB Tone Table

From: "Eugene Nechamkin" <[email-masked]>
Date: Tue, 11 Jan 2005 18:07:01 -0800

We believe the tone generation capabilities are getting overly
complicated for the added benefit they are providing. Operators need to
be able to easily fill these out and we may be getting into a situation
where we create more problems than solutions.
 
In addition, we believe the interpretation of E.180 below in the
examples may not be correct. (In the Japan case, f1 is not modulated by
f2, it is modulated by 16Hz).
 
This needs to be reconsidered further to find an alternative which
provides the necessary functionality in a less complicated way. As the
solution does not seem to be obvious, some time for further dicussions
is needed to come up with the reasonable approach. 
 
Eugene.

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Beacham Gordon-CGB005
Sent: Wednesday, January 05, 2005 8:23 AM
To: [email-masked]'; [email-masked]'
Subject: [ipcdn] IETF NCS Sig MIB Tone Table

ITU-T supplement 2 (E.180) identifies several tone definitions that
cannot be currently satisfied by the IETF NCS Sig MIB tone table
definition. It is important for the IETF NCS Sig MIB to support E.180
tone definitions for:

	1.	embedded tone cadences (i.e., Romania number
unobtainable tone, etc) [2 examples shown below] 
	2.	amplitude modulation (i.e., Japan call waiting tone) [1
example shown below]

	To address these issues, the following changes are recommended:
	PktcSigDevToneEntry ::= SEQUENCE { 

	    pktcSigDevToneType                      INTEGER, 

	    pktcSigDevToneDbLevel                   TenthdBm, 

	    pktcSigDevToneFreqType                  INTEGER, 

	    pktcSigDevToneNumFrequencies            Unsigned32, 

	    pktcSigDevToneFirstFrequency            Unsigned32, 

	    pktcSigDevToneFirstToneSecondaryFrequency Unsigned32, 

	    pktcSigDevToneFirstToneSecondaryMode      Unsigned32, 

	    pktcSigDevToneFirstToneSecondaryAttribute Unsigned32, 

	    pktcSigDevToneSecondFrequency           Unsigned32, 

	    pktcSigDevToneSecondToneSecondaryFrequency Unsigned32, 

	    pktcSigDevToneSecondToneSecondaryMode      Unsigned32, 

	    pktcSigDevToneSecondToneSecondaryAttribute Unsigned32, 

	    pktcSigDevToneThirdFrequency            Unsigned32, 

	    pktcSigDevToneThirdToneSecondaryFrequency Unsigned32, 

	    pktcSigDevToneThirdToneSecondaryMode      Unsigned32, 

	    pktcSigDevToneThirdToneSecondaryAttribute Unsigned32, 

	    pktcSigDevToneFourthFrequency           Unsigned32, 

	    pktcSigDevToneFourthToneSecondaryFrequency Unsigned32, 

	    pktcSigDevToneFourthToneSecondaryMode      Unsigned32, 

	    pktcSigDevToneFourthToneSecondaryAttribute Unsigned32, 

	    pktcSigDevToneFifthFrequency            Unsigned32, 

	    pktcSigDevToneFifthToneSecondaryFrequency Unsigned32, 

	    pktcSigDevToneFifthToneSecondaryMode      Unsigned32, 

	    pktcSigDevToneFifthToneSecondaryAttribute Unsigned32, 

	    pktcSigDevToneNumOnOffTimes             Unsigned32, 

	    pktcSigDevToneFirstToneOn               Unsigned32, 

	    pktcSigDevToneFirstToneOff              Unsigned32, 

	    pktcSigDevToneFirstToneRepeatCount      Unsigned32, 

	    pktcSigDevToneSecondToneOn              Unsigned32, 

	    pktcSigDevToneSecondToneOff             Unsigned32, 

	    pktcSigDevToneSecondToneRepeatCount     Unsigned32, 

	    pktcSigDevToneThirdToneOn               Unsigned32, 

	    pktcSigDevToneThirdToneOff              Unsigned32, 

	    pktcSigDevToneThirdToneRepeatCount      Unsigned32, 

	    pktcSigDevToneFourthToneOn              Unsigned32, 

	    pktcSigDevToneFourthToneOff             Unsigned32, 

	    pktcSigDevToneFourthToneRepeatCount     Unsigned32, 

	    pktcSigDevToneFifthToneOn               Unsigned32, 

	    pktcSigDevToneFifthToneOff              Unsigned32, 

	    pktcSigDevToneFifthToneRepeatCount      Unsigned32, 

	    pktcSigDevToneWholeToneRepeatCount      Unsigned32, 

	    pktcSigDevToneSteady                    TruthValue 

	    } 

	pktcSigDevToneFirstToneSecondaryFrequency

	     SYNTAX     Unsigned32 (0..4000)

	     MAX-ACCESS read-write

	     STATUS     current

	     DESCRIPTION

	     "The secondary frequency used to amplitude modulate or

	      which is summed with the pktcSigDevToneFirstFrequency

	      depending on the setting of

	      pktcSigDevToneFirstToneSecondaryMode."

	     ::={pktcSigDevToneEntry x}

	A similar object definition is required for:

	pktcSigDevToneSecondToneSecondaryFrequency

	pktcSigDevToneThirdToneSecondaryFrequency

	pktcSigDevToneFourthToneSecondaryFrequency

	pktcSigDevToneFifthToneSecondaryFrequency

	pktcSigDevToneFirstToneSecondaryMode

	    SYNTAX       INTEGER { 

	            noModNoSum (1),

	            primaryModulatedBySecondary (2), 

	            primarySummedWithSecondary (3) 

	    } 

	MAX-ACCESS read-write

	     STATUS     current

	     DESCRIPTION

	     "When pktcSigDevToneFirstToneSecondaryMode is set to

	      primaryModulatedBySecondary, the

	      pktcSigDevToneFirstToneSecondaryFrequency is

	      used to amplitude modulate the

	      pktcSigDevToneFirstFrequency.

	      When pktcSigDevToneFirstToneSecondaryMode is set to

	      primarySummedWithSecondary, the

	      pktcSigDevToneFirstToneSecondaryFrequency is summed

	      with the pktcSigDevToneFirstFrequency without any

	      modulation. When pktcSigDevToneFirstToneSecondaryMode

	      is set to noModNoSum, the

	      pktcSigDevToneFirstToneSecondaryFrequency MUST NOT be

	      used."

	      DEFVAL { 1 }

	     ::={pktcSigDevToneEntry x}

	pktcSigDevToneFirstToneSecondaryAttribute

	     SYNTAX     Unsigned32 (0..100)

	     MAX-ACCESS read-write

	     STATUS     current

	     DESCRIPTION

	     "The percentage of amplitude modulation applied to the

	      pktcSigDevToneFirstToneSecondaryFrequency. This

	      object is only used if

	      pktcSigDevToneFirstToneSecondaryMode is

	      primaryModulatedBySecondary. An attempt to set this object
while the value of

	          pktcSigDevToneFirstToneSecondaryMode

	is not primaryModulatedBySecondary will result in

	          an inconsistentValue error."

	     ::={pktcSigDevToneEntry x}

	A similar object definition is required for:

	pktcSigDevToneSecondToneSecondaryAttribute

	pktcSigDevToneThirdToneSecondaryAttribute

	pktcSigDevToneFourthToneSecondaryAttribute

	pktcSigDevToneFifthToneSecondaryAttribute

	pktcSigDevToneFirstToneRepeatCount     

	     SYNTAX     Unsigned32 (0..5000)

	     MAX-ACCESS read-write

	     STATUS     current

	     DESCRIPTION

	     "The repeat count which indicates the number of times

	      to repeat the pktcSigDevToneFirstToneOn and

	      pktcSigDevToneFirstToneOff cadence cycle. Setting

	      this object may result in a tone duration longer or

	      shorter than the overall signal duration specified by

	      the time out (TO) object for a particular signal. If

	      the repeat count results in a longer tone duration

	      than the signal duration specified by the TO, the

	      tone duration defined by the TO object for a

	      particular signal always represents the overall

	      signal duration for a tone. In this case, the tone

	      duration repeat count will not be fully exercised and

	      the desired tone duration will be truncated per the

	      TO setting. If the repeat count results in a shorter

	      tone duration than the signal duration specified by

	      the TO, the tone duration defined by the repeat count

	      takes precedence over the TO and will end the signal

	      event. In this case, the TO represents a time not to

	      be exceeded for the signal. It is recommended to

	      ensure proper telephony signaling that the TO

	      duration setting should always be longer than the

	      desired repeat count time duration. A value of zero

	      means the tone sequence is to be played once but not

	      repeated."

	     ::={pktcSigDevToneEntry x}

	A similar object definition is required for:

	pktcSigDevToneSecondToneRepeatCount     

	pktcSigDevToneThirdToneRepeatCount      

	pktcSigDevToneFourthToneRepeatCount     

	pktcSigDevToneFifthToneRepeatCount 

	The following objects should be deleted. They are no longer
applicable in lieu of the above changes.

	pktcSigDevToneFreqType    OBJECT-TYPE 

	    SYNTAX      INTEGER { 

	                allFrequencies (1), 

	                singleFrequencySequence (2), 

	                dualFrequencySequence (3), 

	                allFrequenciesModulated (4) 

	    } 

	    MAX-ACCESS   read-write 

	    STATUS       current 

	    DESCRIPTION 

	        "This object describes how the frequencies are applied. 

	         allFrequencies indicates all frequencies specifed by

	         pktcSigDevToneNumFrequencies are mixed to form a single

	         tone. The tone is then applied in sequence using the

	         number of on/off times specified in

	         pktcSigDevToneNumOnOffTimes. SingleFrequecySequence

	         indicates all frequencies specified by

	         pktcSigDevToneNumFrequencies are applied in sequence

	         using the corresponding frequency number on/off time

	         (e.g., pktcSigDevToneFirstFrequency uses

	         pktcSigDevToneFirstToneOn and
pktcSigDevToneFirstToneOff,

	         pktcSigDevToneSecondFrequency uses

	         pktcSigDevToneSecondToneOn and

	         pktcSigDevToneSecondToneOff). For this tone type

	         pktcSigDevToneNumFrequencies MUST equal

	         pktcSigDevToneNumOnOffTimes. DualFrequencySequence

	         indicates two pairs of frequencies are added to form
two

	         sequenced tones. The first and second frequency are
added

	         to form tone one and are applied using

	         pktcSigDevToneFirstToneOn and
pktcSigDevToneFirstToneOff.

	         The third and forth frequency are added to form tone
two

	         and are applied using pktcSigDevToneSecondToneOn and

	         pktcSigDevToneSecondToneOff. For this tone type

	         pktcSigDevToneNumFrequencies MUST equal 4 and

	         pktcSigDevToneNumOnOffTimes MUST equal 2.

	         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
allFrequenciesModulated,

	         the pktcSigDevToneNumFrequencies MUST equal 2, and the

	         frequency in pktcSigDevToneFirstFrequency modulates the

	         frequency in pktcSigDevToneSecondFrequency."

	    REFERENCE 

	        "ITU-T E.180" 

	    DEFVAL { allFrequencies } 

	    ::={ pktcSigDevToneEntry 3 } 

	pktcSigDevToneNumFrequencies    OBJECT-TYPE 

	Example 1 - Modulated/Unmodulated Tone:

	Japan call waiting tone with the following definition per ITU-T
E.180:

	f1 mod f2, where f1=400 Hz AM modulated by 16 Hz, f2=400 Hz not
AM modulated

	cadence:

	first tone: 500ms ON then 0 to 400ms OFF

	second tone: 50ms ON then 450ms OFF

	third tone: 50ms ON then 3450ms OFF

	fourth tone: 50ms ON then 450ms OFF

	fifth tone: 50ms ON then 3450 ms OFF

	not repeated, not continuous

	Example 2 - Embedded Cadence:

	This example of an embedded cadence is based on an operator
variation of a national standard. A similar example of an embedded
cadence can be found in ITU-T supplement 2 (E.180) for Romania.

	Frequency: 425Hz

	Cadence:

	- 1) ton:1000msec, toff: 40msec

	- 2) 9 sec repeat of (ton: 40mesc, toff: 40msec)

	- 3) ton: continuous

	Example 3 - Embedded Cadence:

	This example of an embedded cadence is based on an operator
variation of a national standard.

	Frequency: 425Hz

	Cadence:

	- 1) ton: 160msec, toff: 40msec

	- 2) 7* (ton: 40msec, toff: 40msec)

	- 3) ton: 160msec, toff 40msec

	- 4) 7* (ton: 40msec, toff: 40msec)

	- 5) ton: 160msec, toff 40msec

	- 6) 7* (ton: 40msec, toff: 40msec)

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

---

From: "Eugene Nechamkin" <[email-masked]>
Date: Tue, 11 Jan 2005 18:34:50 -0800

Resending my previous message as it bounced off of the reflector
("Message body is too big: 86122 bytes with a limit of 70 KB" which is
obviously not the case for my message).

From: Eugene Nechamkin 
Sent: Tuesday, January 11, 2005 6:07 PM
To: 'Beacham Gordon-CGB005'; [email-masked]'
Cc: [email-masked]'
Subject: RE: [ipcdn] IETF NCS Sig MIB Tone Table

 

Eugene.

	    } 

	     MAX-ACCESS read-write

	     STATUS     current

	     DESCRIPTION

	    SYNTAX       INTEGER { 

	            noModNoSum (1),

	    } 

	MAX-ACCESS read-write

	     STATUS     current

	     DESCRIPTION

	      used."

	      DEFVAL { 1 }

	     MAX-ACCESS read-write

	     STATUS     current

	     DESCRIPTION

	      object is only used if

	     MAX-ACCESS read-write

	     STATUS     current

	     DESCRIPTION

	      repeated."

	    SYNTAX      INTEGER { 

	                allFrequencies (1), 

	    } 

	    MAX-ACCESS   read-write 

	    STATUS       current 

	    DESCRIPTION 

	    REFERENCE 

	        "ITU-T E.180" 

	

	cadence:

	Frequency: 425Hz

	Cadence:

	- 3) ton: continuous

	Frequency: 425Hz

	Cadence:

---

From: Beacham Gordon-CGB005 <[email-masked]>
Date: Mon, 17 Jan 2005 09:22:10 -0800

Motorola agrees the alternative tone table structure suggested by Randy Presuhn is a satsifactory solution for simplifying the existing tone table definition. It also provides the flexibility for accomodating the missing functionality in this international MIB for handling embedded cadences and amplitude modulation for the international customers using the IETF signaling MIB.

The comment on Japan does not make sense to me. It should be noted the amplitude modulation example proposed for Japan was generalized as there may be other operators that require the flexibility for amplitude modulated tones.

Gordon

*	To: "Beacham Gordon-CGB005" < <mailto:[email-masked]> Gordon.Beacham at motorola.com>,  <mailto:[email-masked]> sumanth at cablelabs.com 
*	Subject: RE: [ipcdn] IETF NCS Sig MIB Tone Table 

*	From: "Eugene Nechamkin" < <mailto:[email-masked]> enechamkin at broadcom.com> 

*	Date: Tue, 11 Jan 2005 18:07:01 -0800 

*	Cc:  <mailto:[email-masked]> ipcdn at ietf.org 
 
We believe the tone generation capabilities are getting overly complicated for the added benefit they are providing. Operators need to be able to easily fill these out and we may be getting into a situation where we create more problems than solutions.
 
In addition, we believe the interpretation of E.180 below in the examples may not be correct. (In the Japan case, f1 is not modulated by f2, it is modulated by 16Hz).
 
This needs to be reconsidered further to find an alternative which provides the necessary functionality in a less complicated way. As the solution does not seem to be obvious, some time for further dicussions is needed to come up with the reasonable approach. 
 
Eugene.

  _____  

From: ipcdn-bounces at ietf.org [mailto:ipcdn-bounces at ietf.org] On Behalf Of Beacham Gordon-CGB005
Sent: Wednesday, January 05, 2005 8:23 AM
To: 'ipcdn at ietf.org'; 'sumanth at cablelabs.com'
Subject: [ipcdn] IETF NCS Sig MIB Tone Table

<<<snip>>>