RE: Question on tone table definition in IETF SIG draft-8

Sumanth,

Comments inline as well.

> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]]On Behalf Of
> Sumanth Channabasappa
> Sent: woensdag 22 juni 2005 23:33
> To: Satish Kumar at Texas Instruments; [email protected]
> Cc: Sanchez, Mauricio
> Subject: RE: [ipcdn] Question on tone table definition in IETF SIG
> draft-8
> 
> 
> Satish, 
> 
> 
> Comments inline:
> 
> Q1. According to NCS spec, "ROH Tone is generated by combining four
> tones at frequencies of 1400 Hertz, 2060 Hertz, 2450 Hertz and 2600
> Hertz at a cadence of 0.1 second on, 0.1 second off, repeating." But
> in the latest IETF signaling draft(ver 8),
> pktcSigDevMultiFreqToneTable contains provision to store only two
> frequency components.What would happen in the case that more than
> two frequencies are required, like in the case of off-hook warning
> notifications, where four frequencies are used??
> 
> [sumanth] Essentially, as pointed out by David (
> http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01625.h tml),
> the cause for the change was Randy's original comment
> (http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01466.
> html) and subsequent offline discussions with Gordon.
> 
> However, it is to be noted that multiple frequencies can be
> supported as 'pktcSigDevMultiFreqToneTable' is indexed using two
> indices ('pktcSigDevToneType' and 'pktcSigDevToneFrequencyNumber').
> 
> The MIB Objects 'pktcSigDevToneFreqPriCompValue' and
> 'pktcSigDevToneFreqSecCompValue' are 'components' of a single
> frequency as opposed to 'frequencies' themselves.
> 
> 
>   In summary,
>   'pktcSigDevToneEntry' is indexed by 'pktcSigDevToneType'.
>   'pktcSigDevMultiFreqToneTable' is indexed by 
> 'pktcSigDevToneType' and
> 'pktcSigDevToneFrequencyNumber'
> 
>    Thus, for each tone (represented by 'pktcSigDevToneType') 
> one could 
>    have multiple frequencies (represented by
> 'pktcSigDevToneFrequencyNumber') 
>    and each frequency in turn could have dual components (one if the
> secondary is unused;
>    represented using 'pktcSigDevToneFreqPriCompValue' and
> 'pktcSigDevToneFreqSecCompValue')
> 
>    See example later in this email.
> 
> Does that help?

I'm afraid not. As I tried to explain in
http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01625.html, my
interpretation is the following:

<quote>
In the new pktcSigDevMultiFreqToneTable, there can
indeed be multiple frequencies, but at distinct times! For
having two frequencies active at the same time, you
need to use 

  ...
  pktcSigDevToneFreqPriCompValue Unsigned32,
  pktcSigDevToneFreqSecCompValue Unsigned32,
  ...
</quote>

The reasoning behind this interpretation is that for the PriComp and
SecComp, you can specify how the two frequencies should be combined
(one of the options is to sum up the waves). But for multiple entries
in the pktcSigDevMultiFreqToneTable, there is nothing in the MIB that
indicates that some entries have to be played simultaneously or, in
contrast, successively.  Given the option to play the two frequency
*components* of an entry simultaneously, the logical thing to expect
--although a clarification would not do any harm-- is that the entries
are all played in succession.

This means that only two frequencies can actually be played
*simultaneously* (through PriComp and SecComp), and this is not
suffcient for the ROH Tone.

This observation probably led to Shivakumar's proposal to introduce
grouping of frequencies (see
http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01627.html).


> 
> 2. Could it be possible to have an example of complex signals 
> that were
> used to define the requirements from this draft, in form of the MIB
> elements (e.g. Japanese signal with the different element 
> definitions or
> complex repetition signals) for testing purposes?
> 
> [sumanth] 
> 
> 
> Gordon had provided an example earlier, which is reproduced 
> as follows:
>  
> 

Gordon, is that:


> 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

*followed by*

> Second tone: 50ms  ON then 450ms  OFF

*followed by*

> Third tone : 50ms  ON then 3450ms OFF

*followed by*

> Fourth tone: 50ms  ON then 450ms  OFF

*followed by*

> Fifth tone : 50ms  ON then 3450ms OFF
> not repeated, not continuous

Since that would indeed be what is represented by Sumanth's example
below. Which raises again the question on what to do if you need four
frequencies at the same time...


> pktcSigDevToneFrequencyNumber    001  002 003  004 005
> 
> pktcSigDevToneFreqPriCompValue   400  400 400  400 400
> 
> pktcSigDevToneFreqSecCompValue   016  000 016  000 016
> 
> pktcSigDevToneFreqSecCompMode    001  003 001  003 001
> 
> pktcSigDevToneFreqSecCompPrtg    090  000 090  000 090
> 
> pktcSigDevToneFreqOnDuration     500  050 050  050 050
> 
> pktcSigDevToneFreqOffDuration    400  450 3450 450 3450
> 
> pktcSigDevToneFreqRepeatCount    000  000 0000 000 0000
> 
> 
>  
> Thus, for this tone type, the table 'pktcSigDevToneEntry' would have
> entries indexed by:
> X,1
> X,2
> X,3
> X,4
> X,5
> 
> Where X is the tone type being referenced.
>  
> 
> 3. pktcSigDevToneFrequencyNumber is the index to
> pktcSigDevMultiFreqToneTable and its value ranges from 5-16. 
> Why should
> the index value start from 5??? 
> [sumanth] 
> 
> As you may recall, we initially had:
> 
> >     pktcSigDevToneFirstFrequency            Unsigned32,
> >     pktcSigDevToneSecondFrequency           Unsigned32,
> >     pktcSigDevToneThirdFrequency            Unsigned32,
> >     pktcSigDevToneFourthFrequency           Unsigned32,
> >     pktcSigDevToneFifthFrequency            Unsigned32,
> 
> Thus, to be compatible with the previous definitions, the lower limit
> was set to 5 (I don't recall any other reason, apologies :( )

As I understand it, the pktcSigDevToneFrequencyNumber is the *actual*
number of frequencies in the tone, so it should start from 1. The
*maximum* number of frequencies is represented by
pktcSigDevToneNumFrequencies (which should probably be read-only
instead of read-write, in that case).


Regards,

David

_____________________________________________________  
David De Reu
tComLabs
Stapelplein 70 - 9000 Ghent - Belgium
Tel: +32 9 269 22 91 - Fax: +32 9 329 31 74
www.tComLabs.com
_____________________________________________________