RE: Proposed changes to draft-ipcdn-pktc-signaling-08

The next available tonenumber may be different for various manufacturers
or software images. It's an additional overhead for the operator to
first find out the next tone number and accordingly generate config
files for those entries.

Shiva.

-----Original Message-----
From: Eugene Nechamkin [mailto:[email protected]] 
Sent: Tuesday, July 26, 2005 12:59 PM
To: T, Shivakumar; Sumanth Channabasappa; [email protected]
Subject: RE: [ipcdn] Proposed changes to draft-ipcdn-pktc-signaling-08


In case when pktcSigDevMultiFreqToneTable is indexed by one index
(pktcSigDevToneNumber), particular values of the indexes and their
assignments to the particular ToneTypes do not matter. The only
condition for
indexes is to be unique for each row in the
pktcSigDevMultiFreqToneTable.
This way the table does not have any restrictions on the number of rows
with
the same value of the "ToneType". 

In the example below, if additional entry of ToneType=2 is required it
should
be introduced with the unique index value of pktcSigDevToneNumber=11.

Eugene.



-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf
Of T,
Shivakumar
Sent: Monday, July 25, 2005 10:43 PM
To: Sumanth Channabasappa; [email protected]
Subject: RE: [ipcdn] Proposed changes to draft-ipcdn-pktc-signaling-08

Having a single index would really make things easier if a tonenumber
can
uniquely identify a tone type.
Let's assume the following default entries are present in multifreq tone
table:

ToneNumber ToneType
-------------------
    1         1
    2         1
    3         2
    4         3        
    5         3
    6         3
    7         4
    8         4
    9         5  
   10         5
-------------------

Now tone type 2 has only one entry in the above table. In order to have
say 2
entries for tone type 2, should we add an entry in the config file with
index
4 or index 11. In either case the tonenumber can get changed for other
tone
types.
One solution is to reserve the tonenumbers for a particular tone type.
Since the tonenumber can range from 1-8, tonenumber 1-8 can be for
tonetype
1, tonenumber 9-16 can be for tonetype 2 and so on. With this even the
tonetype can be removed from the multifreq tone table.

Shiva

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf
Of
Sumanth Channabasappa
Sent: Monday, July 25, 2005 7:53 PM
To: [email protected]
Subject: [ipcdn] Proposed changes to draft-ipcdn-pktc-signaling-08

Proposed changes to draft-ipcdn-pktc-signaling-08:
-------------------------------------------------
(ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-signaling-08.t
xt)


OPEN ISSUE (Need inputs):
---- ----- 
+ Definition of the MIB Object 'pktcSigDevToneSteady'. This seems to
allow for dual interpretation.

 
Strongly recommended changes (based on feedback received in the IPCDN
WG):
-------- ----------- -------    

Recommendation #1 (Reason: Technical):
-------------------------------------
+ pktcSigDevMultiFreqToneTable


- Extend the MultiFrequency table to support 4, instead of 2 frequencies
today (First, Second, Third, Fourth instead of Pri and Sec). i.e. 

  - pktcSigDevToneFirstFreqValue            

  - pktcSigDevToneSecondFreqValue                    

  - pktcSigDevToneThirdFreqValue            

  - pktcSigDevToneFourthFreqValue

 
- Re-enumerate 'pktcSigDevToneNumber' to 1..8 (Reason: There is no need
for
anything more than 8 tones per tone type)

- Make all the entries in this table to be 'read-only' (Reason: Will not
require updating during run-time)

- Update the DESCRIPTIONs appropriately (Reason: Addition of 4
frequencies
changes the Modulation/Summation schemes)

 
 

Recommendation #2:
-----------------

+ Deletion of MIB Objects

    - Delete the MIB Objects 'pktcNcsEndPntConfigTxGain' and
'pktcNcsEndPntConfigRxGain' (Reason: Proposal withdrawn)

    - Delete the MIB Object 'pktcSigDevToneNumFrequencies' (Reason:
Redundant)

 



Editorial/Semantic Changes:

---------------------- ----------

- Rename 'pktcSigDevToneFrequencyNumber' as 'pktcSigDevToneNumber'
(Reason: Semantics)

- Move the MIB Object 'pktcSigDevToneType' to the Tone Table (Reason:
MIB author guidelines)

 

Additional suggested changes:
----------  -------- --------
- 'pktcSigDevMultiFreqToneTable' could be indexed using only one MIB
Object,
easing implementation.


Define FreqToneTable as being indexed only by pktcSigDevToneNumber
(unique
index for each entry)

 
   pktcSigDevMultiFreqToneEntry    OBJECT-TYPE  
       ...............

       INDEX {pktcSigDevToneNumber}  
       ::= { pktcSigDevMultiFreqToneTable 1 }  

 

   PktcSigDevMultiFreqToneEntry ::= SEQUENCE {

         pktcSigDevToneNumber                    Unsigned32,
         pktcSigDevFreqToneType                  ToneType
.
.
.
   }

   pktcSigDevToneNumber OBJECT-TYPE  
       SYNTAX       Unsigned32(1..168) 
       MAX-ACCESS   not-accessible
       STATUS       current  
       DESCRIPTION  
          "This MIB Object is a unique number identifying each entry in
..."


regards
Sumanth

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

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