RE: 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.html), 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?


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:
 

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 3450ms OFF
not repeated, not continuous



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 :( )


Let me know if there is something amiss.

regards
Sumanth