Subject: Return Values in Base Packages

From: [email-masked]
Date: Wed, 6 Oct 1999 19:47:05 +0530

Tom,

  I had a few queries relating to the Base packages as below:

Query 1

             Kindly elaborate on the use of the "Return Value" field in the
subsections of Sec 3.1.2.1. on Event Configuration. Is it something that the MG
will return back to the MGC after it has registered the Event configuration ? If
yes then how is this
 value returned to the MGC ?

Query 2

 Why are both the Generic Audio package and the DTMF package including the DTMF
tone set ?

Query 3

Sec 12.1 of the MEGACO draft version 0.4 that describes the Guidelines for
defining packages does not mention
 that "Event Configuration" needs to be specified when defining packages. The
Base Package contains a section
  on "Event Configuration" and a section on "Observed Events". Maybe, the
protocol text should be consistent with
  what is contained in the Base package definition.

Query 4

Can you elaborate as to how the property ID will be used in the TerminationState
Decriptor or the LocalControlDescriptor ? Probably, if you cite an example
things will be clearer to me.

Regards,

Vikas Bajaj
Gateway Development Team
Hughes Software Systems Ltd.

---

From: Brian Rosen <[email-masked]>
Date: Wed, 6 Oct 1999 21:37:06 -0400

Addressed to Tom, but it raised an issue that I wanted to bring up
on the list anyway

>  value returned to the MGC ?
We agreed that there is no such "return value" and the way to
get information from a termination was a property.  Errors are
returned as failure of the command using the normal error procedure.

>  Why are both the Generic Audio package and the DTMF package
I believe this will be reworked to have non-intersecting packages.

>   what is contained in the Base package definition.
Here we have a disagreement between me and the authors of the
basic package document.

Generally, there is indeed an issue where the parameters needed to
establish an event may not be the parameters returned from the event.
The authors of the draft sought to change the definition of events such
that the parameters used on the EventDescriptor were not the same as
the parameters returned in a Notify.  The former were called "Event
Configuration", and the latter "Observed Events".

I do not believe that creating entirely separate definitions is
appropriate.  I suggested that instead, parameters be designated
IN, OUT, or BOTH, where IN was used only in EventDescriptors, OUT was
used only in Notify, and BOTH was used in both.  Note that the syntax
of both EventDescriptors and Notify use keyword=value notation,
so that we do not have any order dependent parameters, and "omitting"
a parameter would not confuse a parser.

I solicit the list's opinion on this issue.

> Descriptor or the LocalControlDescriptor ? Probably, if you
> cite an example
If I understand the question, you want to know how properties defined
on a termination in a package work.

Suppose we had a termination that required a state variable.  For example,
suppose we had a termination with a softkey.  It might have a property
called "displayContent".  In this example, the softkey display is not
stream dependent, and therefore it is defined in terminationState.
You could have a command:
....Media{TerminationState{...,displayContent="VoiceMail")...
If the property was stream dependent, it would be defined in
localControl, but the syntax would be similar.

Does this answer the question?