Subject: [ipcdn] Re: IETF IPCDN Signaling MIB - Draft 3 - Last Call for Comments

From: "David De Reu" <[email-masked]>
Date: Mon, 19 Jan 2004 16:53:32 +0100

Dear all,

Below I have listed some items for discussion based upon trouble points
we found with draft-02. I think it would be beneficial if we could get
these sorted out before draft-03, because it would greatly reduce the
number of ambiguities, thus making it more clear for an MTA vendor how
to implement the MIB.

(1) pktcSigServiceClassName(US|DS|Mask) objects

   There is still a problem with the pktcSigServiceClassName(US|DS|Mask)
   objects (and indirectly with the related pktcSigNcsServiceFlowState
   object). Although the MIBs currently reflect the PacketCable PROV
   spec text, the proposed system for setting up a signaling service
   flow will *NOT* work with a PacketCable/IPCablecom compliant CMTS.
   This is because the CMTS must reject all DSx messaging initiated by
   the CM if there is no valid authorization block. There is no such
   block in this case (there even is no gate on the CMTS). Note that
   this does not mean that PacketCable takes a step backward compared to
   (Euro-)DOCSIS. In plain (Euro-)DOCSIS it is the case that a CM is not
   allowed to initiate DSx messaging, since it is not allowed to expose
   an interface to the outside world to do this. For an embedded MTA in
   PacketCable, this interface is present and the DSx messaging *can* be
   initiated by the CM, but the CMTS will accept it only if the
   appropriate authorization can take place (using the authorization
   block).

   Operationally, the practical solution is quite simple. You can add
   the necessary MIB objects in the CM config file (specifying the
   service flow parameters directly, or alternatively using a Service
   Class Name (SCN)). In that case, the CM will set up the service flow
   during its registration, without the need for DSx messaging.

   Solution: It is of course not up to the SIG MIB to provide a solution
   to this problem. However, if the pktcSigServiceClassName(US|DS|Mask)
   objects *are* included in the MIB, then you have a set of objects of
   which you know on forehand that they are useless. So the question
   seems to me: do we want to include these objects in the MIB? We could
   also leave them out now, and wait for a correctly functioning
   mechanism to be defined in the PacketCable/IPCablecom specs.
   Alternatively, if the objects remain in the MIB, then we have to ask
   ourselves what will be required from an MTA: we will require that the
   MTA does the DSA nevertheless, knowing that it will not succeed
   anyway?

(2) pktcSigDevRtCadence is superfluous

   The pktcSigDevRtCadence object is not needed, and introduces an
   ambiguity in the MIB. First of all, this object is intended to
   specify the "ring cadence rt", but "rt" is not really a ring cadence:
   it is the ringback tone. The "rt" signal does not cause ringing
   voltage to be applied to the analog line, but causes a *tone* to be
   played to the calling party. Indeed, the ringback tone is included in
   the pktcSigDevToneTable. Like for every tone, the MTA will consult
   this table to determine the properties of the ringback tone, and
   hence the pktcSigDevRtCadence object will not be used anyway.

   Solution: we suggest the removal of the pktcSigDevRtCadence object.

(3) pktcSigDevStandardRingCadence and pktcSigDevRingSplashCadence

   There needs to be clarification on the difference between these
   objects and the pktcSigDevRgCadence and pktcSigDevRsCadence. Agreed
   that the latter is for North American systems, and the former is for
   international systems, but it must unambiguously be clear to an MTA
   vendor when to use which object.

   Is it correct to state that an MTA for the international market would
   have to implement both alternatives according to the module
   compliance statement, but it would only use the international pair of
   objects? If this is the case, then why require that the North
   American pair of objects has to be implemented?

(4) pktcSigPulseSignalTable, pktcDevRingCadenceTable and E-package

   Regardless of any changes to the table definitions, we suggest to
   make it clear that they only need to be implemented when the ETSI
   E-package is supported. Without support for the E-package, these
   tables have no use.

   By the way, can the operator currently determine by MIBs which
   NCS packages the MTA supports (and in particular, if the MTA supports
   the E-package)?

(5) Mapping NCS signal requests (tones, rings) to MIB objects

   How will an MTA vendor currently know unambiguously when to use
   which tone or ring cadence definition for a given NCS signal request?

(6) pktcSigDevSilenceSuppression: per codec is better

   It was argued before that on one hand VAD is independent of the
   codec, but on the other hand in practice different VAD
   implementations may be needed for different codecs, and hence the
   presence of such a VAD implementation depends on the codec (so that
   for instance VAD would be supported for G.729 but not for G.711).

   As far as I can see, it is indeed logical to let VAD support depend
   on the codec, since the exact algorithm used for VAD may be different
   for different codecs. This is apparently also the viewpoint taken in
   the PacketCable NCS specification [PKT-SP-EC-MGCP-I08-030728, p.35],
   where we read in the context of an MTA's capabilities (that can be
   queried by an AUEP command): "If there is a need to specify that some
   parameters, such as e.g., silence suppression, are only compatible
   with some codecs, then the gateway will return several capability
   sets". Note that only the CMS can normally send an AUEP that queries
   the MTA for its capabilities, and not the SNMP manager. Therefore,
   the same functionality must also be provided by the MIB.

   In contrast with the NCS spec, the PacketCable PROV spec considers
   VAD independent from the codec (MTA capabilities TLV 5.12). This may
   be a reason to also do it this way in the MIB, but according to the
   arguments above this is not the best thing to do. Therefore we feel
   it is better to adopt a more correct MIB definition instead, i.e.
   letting the support of VAD depend on the codec.

Thanks,

David

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

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

---

From: "David De Reu" <[email-masked]>
Date: Fri, 30 Jan 2004 17:20:02 +0100

Dear all,

I have received feedback on most of the discussion items I raised.
Please find a summary below..

> (1) pktcSigServiceClassName(US|DS|Mask) objects
-------------------------------------------------
  Status: closed.

  The problem is recognized, and is indeed not to be addressed in the
  MIB. There has been a suggestion to do the following:

  (1) See if the PacketCable DQoS team can provide input on how they are
      going to solve this issue in the future. If this input arrives in
      time, the MIB can maybe be changed accordingly.

  (2) If there is no clear solution within a week or two, the objects
      will be removed from the MIB since
      
      a) They are probably not used yet, which is also due to (b)
      
      b) The objects can not be used (will not work) with a qualified
         CMTS.

> (2) pktcSigDevRtCadence is superfluous
----------------------------------------
  Status: closed.

  All feedback indicated agreement.

> (5) Mapping NCS signal requests (tones, rings) to MIB objects
--------------------------------------------------------------------

  I will start a separate e-mail thread regarding the issue of
  clarifying the difference between "US" and "international" objects.

> (6) pktcSigDevSilenceSuppression: per codec is better
-------------------------------------------------------

  This issue was about the fact that it is not clear whether silence
  suppression is regarded as a per-codec feature, or as a device feature
  in the PacketCable specs.

  However, based on the provisioning spec that considers VAD to be codec
  independent, the MIB can also be codec independent.

Thanks,

David

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