Subject: What does AuditCapability of Packages mean?

From: Brian Rosen <[email-masked]>
Date: Tue, 5 Oct 1999 15:08:26 -0400

Megacogans:

I am working on V11, which we expect out at the end of this week.  Very few
substantive changes will be made, most of the changes will be editorial.  I
was asked to clarify what was returned from AuditValue and AuditCapability.
I propose the following wording:

For AuditValue -

The appropriate descriptors, with the current values for
the Termination, are returned from AuditValue.  ObservedEvents returns a
list of events in the EventBuffer
PackagesDescriptor returns a list of packages realized by
the Termination.  DigitMapDescriptor returns the name or
value of the current DigitMap for the Termination.
Statistics returns the current values of all statistics
being kept on the Termination.

For AuditCapability --

The EventsDescriptor returns the list of possible events on
the Termination.  The SignalsDescriptor returns the list of
possible signals which could be applied to the Termination.
StatisticsDescriptor returns the names of the statistics
being kept on the termination.  ObservedEventsDescriptor
returns the names of active events on the termination.
DigitMap and Packages are not legal in AuditCapability.

If someone can think of anything useful auditCapability of DigitMap or
Packages, speak up!

Brian

---

From: Harpreet Singh Anand <[email-masked]>
Date: Wed, 6 Oct 1999 16:19:08 +0530

Hello Brian,

Regarding Audit Value , Audit Capability:

1. Can we have multiple digit maps defined for a termination ? Basically, we can
define multiple digit maps and have only one  (the last specified one) as the
active digit map. If this is possible, then the Audit Capability of Digit map
can return all the digit maps that are defined for that termination id.

2. Shouldn't Packages descriptor be valid for AuditCapability and invalid for
AuditValue ? As packages tell about the capability of the termination rather
than any dynamic value.

3. What is the point of returning statistics name in the StatisticsDescriptor
(in case of AuditCapabilty) ? In what way can this information be used by MGC ?

In addition, I am pointing a couple of issues in V10 which can get addressed in
V11:

1. Handling of Buffered Events is not clearly specified in the V10. Sometimes
back you had started a thread on this topic but the discussions in that thread
has not been incorporated in the draft.

2. Transport layer issues: Annex E (Transport layer using UDP) has a lot of
stuff which is legacy from MGCP, things like failover handling, triple handshake
(do we have a descriptor corresponding to Response Acknowledgement) etc. These
need to be defined / changed for MEGACOP.

3. A couple of days back I had pointed the following problem in the ABNF
specifications of DigitMapDescriptor -
"In the description of DigitMapDescriptor (sec 7.1.14), it has been mentioned
that a digitMap can be deleted by specifying an empty value for a name that is
already defined. However, the ABNF specification does not allow specifying a
null / empty value."

4. The reply to the AuditDescriptor in  Add/ Move / Modify / Subtract commands
returns AuditValue ( and not Audit Capability). This needs to be clarified /
explained in the draft.

5. How to audit context properties - topology descriptor etc?

Regards,
Harpreet

_________________________________
Harpreet Singh Anand
Ficon Technology
E-mail :  mailto:[email-masked]
Web    :  http://www.ficon-tech.com

---

From: Michael Thomas <[email-masked]>
Date: Wed, 6 Oct 1999 17:10:16 -0700

Brian,

As you might guess, I'm in favor that
AuditCapability only being able to return the
Packages realized by the termination; a package is
surely a capability rather than a value. Also: if
we take the pragma that a termination MUST realize
the entire package it returns in the
AuditCapability, I see no reason at all to have a
SignalsDescriptor in AuditCapability. This is
especially relevant when you consider that a
termination may realize many similar packages for
backward compatibility, etc. The amount of cruft
that a SignalDescriptor would return would be
onerous to the MGC, and in fact redundant since
packages already neatly name that signal
capability set.

On the digit map for capabilities, the only thing
that I can think that might be useful is that the
MGC could determine how many digitmaps it could
load into the MG. That sounds sort of marginal
though.

                Mike
--