RE: pktcSigDevStandardRingCadence and pktcSigDevRingSplas hCadence are redundant

Hi Gordon,


I asked you the difference between those two MIB-object a long time ago,
and you pointed out
that a different object was needed for Europe because of the difference
in total time and needed
granularity.

If the total duration difference needs to be supported, it needs to be
supported without the need 
for the E-package. 

As it is important that basic calls can be supported without an MTA that
support the E-package, 
and you clarified that for Europe a longer cadence is needed. Based on
that it seems the normal
way to go to have the two extra MIB-objects.
By that a CMS can support both European and US market without any
changes on the CMS !

Please note that for now the E-package is still optional, as far as I
know no CMS
supports it !



A solution would be to have the definition adjusted for the MIB so it
supports both US and European requirements:

the duration of the cadence can be adjusted by having leading zeroes.
The total number of bits needs to be increased to support a longer
maximum length, and more granularity (50 ms).

This would mean that the pktcSigDevRgCadence and RsCadence and r0 to r7
take the definition of the 
for now European-only cadence. This allow the needed flexibility while
having only one mib-object to specify the cadences.
This can be done by adjusting the textual convention (PktcRingCadence)


This would mean that an MTA can have exactly the same mapping from NCS
to MIB for the L-package, independent of the region in which it will be
used,
and independent from possible E-package support.


Thanks,
  Best regards,
    Wim







-----Original Message-----
From: Beacham Gordon-CGB005 [mailto:[email protected]] 
Sent: 27 February 2004 23:46
To: 'Eugene Nechamkin'; Beacham Gordon-CGB005; Wim De Ketelaere;
[email protected]
Subject: RE: [ipcdn] pktcSigDevStandardRingCadence and
pktcSigDevRingSplas hCadence are redundant



Exactly. This is precisely what the pktcSigDevRingCadenceTable object is
defined to handle (international ring cadences to 13.2s) using the V5.x
"cr(x)" mechanism noted in the object description. For example, an
international operator could define cr5 for standard ring and cr9 for
ring splash, etc for up to 128 international cadences.

V5.x defined 128 possible ring cadences for international ring messages
without concern for what those cadences are named. The 101 909-4 spec
does not name these cadences either and the name should not be a concern
for the MIB definitions.

Gordon

-----Original Message-----
From: Eugene Nechamkin [mailto:[email protected]]
Sent: Friday, February 27, 2004 2:13 PM
To: Beacham Gordon-CGB005; Wim De Ketelaere; [email protected]
Subject: RE: [ipcdn] pktcSigDevStandardRingCadence and
pktcSigDevRingSplas hCadence are redundant


It's might also be worth noting that the "pktcSigDevRgCadence" and
"pktcSigDevRsCadence" on one hand, and "pktcSigDevStandardRingCadence"
and "pktcSigDevRingSplashCadence" - on the other have different
requirement for the Cadence timing granularity, hence the
"pktcSigDevRgCadence" and "pktcSigDevRsCadence" could not have been used
to represent Euro-PC Cadence resolution requirement reflected in
"pktcSigDevStandardRingCadence" and "pktcSigDevRingSplashCadence".

Eugene.

-----Original Message-----
From: [email protected] [mailto:[email protected]]On Behalf Of
Beacham Gordon-CGB005
Sent: Friday, February 27, 2004 1:59 PM
To: 'Wim De Ketelaere'; Eugene Nechamkin; [email protected]
Subject: RE: [ipcdn] pktcSigDevStandardRingCadence and
pktcSigDevRingSplas hCadence are redundant



Interesting. Thanks for pointing that out. However, I don't follow why
the mapping has been made that way in the "Clarification of L Package
for Euro-PacketCable Document v6.0 (2004/1/20)."

The objects referenced in 2.19 and 2.21 for the L package rg and rs
cadences are in the international group with a max cadence of 13.2s. The
other distinctive ring cadences in the above document map to core L
package objects r0..r7 with a max cadence of 6.0s. The cadence mapping
seems to be inconsistent. I would have expected the 2.19 and 2.21
cadence for rg/rs to be mapped to the pktcSigDevRgCadence and
pktcSigDevRsCadence core L package objects. International cadences would
then be handled via the E package extensions and associated object
(pktcSigDevRingCadenceTable).

Wim,

Can you comment/clarify why the rg/rs cadences are mapped to objects in
the international group instead of the pktcSigDevRgCadence and
pktcSigDevRsCadence objects? Thanks.

Gordon

-----Original Message-----
From: Eugene Nechamkin [mailto:[email protected]]
Sent: Wednesday, February 25, 2004 5:21 PM
To: Beacham Gordon-CGB005; [email protected]
Subject: RE: [ipcdn] pktcSigDevStandardRingCadence and
pktcSigDevRingSplashCadence are redundant


> The pktcSigDevStandardRingCadence and pktcSigDevRingSplashCadence
> objects are redundant. 
I am not sure I can completely agree with this statement (if I
understand it correctly). Both of these objects are required for
Euro-L-package, because of the way the RG and RS signalls are currently
defined:

For Euro-L-Package: 
   - RG -> pktcSigDevStandardRingCadence
   - RS -> pktcSigDevRingSplashCadence

The "pktcSigDevRingCadenceTable" contains the cadence values for the
E-package. Having in mind that E-package is optional, and L-package is
mandatory, I am not sure I understand how pktcSigDevStandardRingCadence
and pktcSigDevRingSplashCadence can be "merged" into the
"pktcSigDevRingCadenceTable".

Or, are you suggesting that "pktcSigDevRingCadenceTable" should contain
the RG and RS cadencies for Euro-L-Package along with the values for
E-package? If yes, I think the proper mapping of the table indexes to
the corresponding signal should be somehow defined, and corresponding
modifications of the Euro-L-Package should also be put in place. 

Though from the MIB optimization stand point of view the proposed
modification might make sense, however, from the currently imlemented
and intended funtionality prospective it looks unnecessary (please
correct me if my understanding of your proposal deviates from what you
had in mind).


Eugene Nechamkin,
Broadcom Corp.,
ph: (604) 233-8500


-----Original Message-----
From: [email protected] [mailto:[email protected]]On Behalf Of
Beacham Gordon-CGB005
Sent: Wednesday, February 25, 2004 11:01 AM
To: [email protected]
Subject: [ipcdn] pktcSigDevStandardRingCadence and
pktcSigDevRingSplashCadence are redundant



The pktcSigDevStandardRingCadence and pktcSigDevRingSplashCadence
objects are redundant. These objects are recommended to be deleted from
the NCS Signaling MIB. The use of separate pktcSigDevStandardRingCadence
and pktcSigDevRingSplashCadence objects is a carryover from the L line
package and they are not needed in the E line package. Instead, normal
ring and ring splash cadences can be defined using the
pktcSigDevRingCadenceTable object.

Gordon Beacham
Digital Core Gateways, BCS
Motorola, Inc.
858-404-2335
[email protected]


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


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