Subject: Re: What does AuditCapability of Packages mean?

From: "Derks, Frank" <[email-masked]>
Date: Wed, 6 Oct 1999 10:00:30 +0200

Hi Brian,

since you are already working on the new version, I will pass my findings in
the V10 version of the MEGACP document (draft-ietf-megaco-protocol-04.txt),
until now, on.

- Add "DS0" and "DS1" to the abbreviations section. These are used in 7.1.1

- The second paragraph in 6 ("Connection model") states that "a Termination
sources and/or sinks" one or more media streams". This contradicts 6.2,
which states "a Termination is a logical entity on a MG that sources and/or
sinks" media and/or _control_ streams".

- The second and third paragraphs of 6.2 ("Terminations") and the fourth
paragraph of 6.2.4 ("Termination Properties and Descriptors") lead me to
believe that, until a termination is added to a context, it does not "exist"
and can therefore not be "operated on" until it is added to a context. Is
this the intention? The text is not too explicit about this.

- Section 6.2.4 is titled "Termination Properties and Descriptors". It is,
however, not clear about _what_ such a property is and, from this section,
it would even seem that a property and a descriptor are roughly equivalent.
Probably, the intention is that a property is described by its descriptor.
Words to this effect would make this clearer.

-The sixth paragraph of 6.2.4 would seem to indicate an action that is
entirely "local" to the MG. Is this the case? If so, words to that affect,
would make things clearer.

- The paragraph right after the Descriptor table in 6.2.4, implies (at least
in my reading) that a Termination is "part of" the Media: "within the Media
descriptor there is the Termination State descriptor....". If the
"Termination State descriptor" is alway only associated with the media, then
I can understand its presence in the "Media Descriptor", but it still seems
a bit illogical.

- The first paragraph of section 6.2.5, second sentence, says "A package
(MG)...". Is the intention here that the referred to package is the "MG"
package?

- Sections 7 and 7.2. None of the commands have a ContextID as a parameter.
How does one add a Termination to a specific context?

- Section 7, 4th item in the command list and section 7.2.4. It is not
defined what "atomic" means. Some clarifying text would be in place.

- In sections 7.1.1 and 7.1.2, the wordings "command responder" and "command
initiator" are used. Is this wording because of the fact that all but one
case (the Notify command) the initiator is the MGC?

- The second paragraph in section 7.1.2 starts with "Properties may..". The
three numbered items below that sentence, however,  talk about parameters.
It would seem that again the word "property" is used quite loosely and in
this case its relation to "parameter" is not very clear.

- Sections 7.1.3, 7.1.4, 7.1.5, 7.1.6, 7.1.8, 7.1.9, 7.1.10, 7.1.11, 7.1.13,
7.1.14, 7.1.15 and 7.1.16, don't really specify what the Descriptor looks
like. Is this intentional or is this work that still has to be done? The
specifications in the sections that do have it, seem to be incomplete.

- The second paragraph in section 7.1.8 list "delete" as one of the allowed
values for the mode parameter. This is rather a strange "mode".

- In section 7.1.10 it is stated that the RequestIdentifier is used to
correlate the request with reported events. Why would I want to correlate
the Request, rather than the Termination, with such events?

- The table in section 7.1.10 only has "Action" as a suffix in
"NotifyAction". This is not consistent with the other two actions.

- In the fourth paragraph of section 7.1.10, "Embedded" is spelled with an
uppercase "E". This may lead people to believe that there are both and
"Embedded Signals Descriptor" and a "Signals Descriptor", this is probably
not the intention.

- In section 7.1.11, three types of signals are specified (on/off, timeout,
brief), it would seem that these are not the signals themselves, but the
behaviour of the signals. I.e. properties of signals. What is the intention?

Unfortunately I have not had the time to read through the remainder of the
document, but I will try to do so and let you know what I come up with.

Regards,

Frank

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]]
Sent: 05 October 1999 21:08
To: [email-masked]
Subject: What does AuditCapability of Packages mean?

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: Brian Rosen <[email-masked]>
Date: Wed, 6 Oct 1999 18:59:13 -0400

> 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.
In theory, you can have any number of named digitmaps, and each termination
can have a (potentially) unique unnamed digitmap, but the MG may have
limited storage which limits what you can actually do.

However, AuditCapability could return a list of all named digitMaps.

> 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.
An admittedly arbitrary decision.  I don't really care.

>
> 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 ?
The primary use is mid call statistics, which carriers have required.
Additionally it can be used to get statistics on a Move.

>
> 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.
John and I can work on it, suggested wording would be welcome.

> 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.
I'll look it over again.

> 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."
V11 will show the value as optional.

> 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.
It is.  It returns the current values, not capabilities.  I'll add words.

> 5. How to audit context properties - topology descriptor etc?
That will have to be handled in Red Bank. Suggestions welcome.

Brian