Subject: questions about processing Commands

From: "Griffeth, Nancy D (Nancy)" <[email-masked]>
Date: Mon, 11 Dec 2000 19:05:27 -0500

Question 1 has to do with the order of processing descriptors:

In Section 7.2:
        The descriptors SHALL be processed in the order in which they
appear.

This may pose an insurmountable problem in processing an AuditDescriptor.
If, for example, an AuditDescriptor is the first
descriptor in a command, then the gateway returns the original values of the
requested descriptors.  If there are under-
or over-specified parameters in later descriptors, the gateway also chooses
values and returns a descriptor containing its choices.  This may require
two descriptors of the same kind in a command reply; I believe this is
prohibited.

To prevent this problem, I suggest processing the AuditDescriptor last,
regardless of where it appears
in a command.  That's the only position that prevents the problem when the
AuditDescriptor mentions descriptors that
appear in the command.  This would provide the gateway controller with the
values of the descriptors at the time the
command reply was created, which is intuitive.  If the MGC needs the
original values of the descriptors, it can send an
AuditValues command first.

There's a problem with this: use of this rule would prevent using the
AuditDescriptor in a Move to get mid-call statistics.
However, the order of processing the statistics piece of an AuditDescriptor
is dictated in Section 7.2.4 - the gateway
returns the statistics just prior to the move, regardless of the order of
the AuditDescriptor in the command.  Since this is a
primary purpose of the statistics option of the AuditDescriptor, I don't
imagine anyone would want to change it.  Also,
it doesn't create the above-mentioned problem.

So, how about auditing all descriptors except statistics last, and in a Move
command, audit the statistics just prior to
the move?

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

Question 2 has to do with what should be returned in the CommandReply when
parameters are over- or under-specified.

In Section 7.1.1 of the gateway control protocol standard document, it says:
        Whenever a parameter is underspecified or overspecified, the
descriptor containing the value chosen by the responder is included as
output from the command.
This can be read in two ways when there is a single property group (or SDP
entry):
1) The gateway should only return the values that it chose, omitting any
value supplied unambiguously
by the gateway controller; or
2) The gateway should return the entire descriptor, with the selected values
filled in to replace under- or over-specified
parameters.
Which is it?  The former is more efficient, but the latter is more
consistent with handling of multiple property groups
(or multiple SDP entries).
It's clear that if there are multiple property groups or SDP entries, option
1) would be ambiguous.  The spec is unambiguous that option 2 is the choice.

-----------------------------------------
Question 3 also addresses processing multiple property groups or SDP
entries, and under- or over-specified parameters:
The specification says:
        If ReserveGroup is true, the MG reserves the resources required to
support any of the requested property group alternatives that it can
currently support.  If ReserveValue is true, the MG reserves the resources
required to support any of the requested property value alternatives that it
can currently support.
Does "support" here refer only to the availability of resources, or to the
packages and properties supported?  If the latter,
does this mean that the messages "440 - unsupported or unknown package" and
"445 - no such property in this package"
would never be seen when reserveGroup and reserveValue are true?

Thanks for your time,

Nancy Griffeth