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

> 1. 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??

Indeed an interesting observation.

As I recall, one of the design guidelines for these new MIB
objects was to get rid of

  ...
  pktcSigDevToneFirstFrequency   Unsigned32,
  pktcSigDevToneSecondFrequency  Unsigned32,
  pktcSigDevToneThirdFrequency   Unsigned32,
  pktcSigDevToneFourthFrequency  Unsigned32,
  pktcSigDevToneFifthFrequency   Unsigned32,
  ...

and the likes in the original PktcSigDevToneEntry (see
http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01466.html).

This is probably why for the pktcSigDevToneFrequencyNumber
object there can now be between 5 and 16 frequencies. There
has, however, also been a semantic change: in the original
table, all frequencies could be present at the same time,
which was fine for the off-hook warning tone mentioned
above. 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,
  ...

but now indeed only *two* frequencies can be used (instead
of four, or the proposed five in the original tone table).

What's worse, the original issue with enumerating
frequencies in the First/Second/.../Fifth-style, is now
again introduced, albeit with only Pri/Sec this time. This
means that it makes little sense to introduce a
Third/Fourth/FifthCompValue.

An alternative would be to allow the playback of multiple
entries (frequencies) in the pktcSigDevMultiFreqToneTable at
the same time, which would be equivalent to summing up the
waves, and hence which would render the
primarySummedWithSecondary(3) setting for
pktcSigDevToneFreqSecCompMode useless.


> 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?

This question may indicate that the current structure of the
MIBs is rather complex. We have to make a trade-off here: do
we want a MIB structure that is useable, but that may fail
to accurately mimic some tones, or do we want a very general
MIB structure that allows to define every complex tone you
may ever encounter, but which comes at the obvious cost of
increased complexity? Thereby the danger may also arise that
the structure is going to be too complex to use it in
practice... in which case we may as well have no tone table
at all.


> 3. pktcSigDevToneFrequencyNumber is the index to
> pktcSigDevMultiFreqToneTable and its value ranges from
> 5-16.  Why should the index value start from 5???

Probably a typo? A tone consisting of only one frequency
should of course still be possible, so the authors probably
meant 1 as lower bound.


My 2 cents.

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
_____________________________________________________