Subject: MEGACO: Generic Package parameter SigID

From: Troy Cauble <[email-masked]>
Date: Tue, 28 Nov 2000 11:54:43 -0500

Hello, hello again,

In section E.1.2 (Events for the Generic package),
under the "Signal Completion" event, "Signal Identity"
parameter...

Firstly, I find it objectionable that this parameter defines
encoding syntax.  Shouldn't that be defined in section 12 with
the allowed types and referenced by type in the package elements?
Can a package element really define it's own syntax?
As someone writing a stack with a extensible package mechanism,
I can say that this would be a major pain in the butt.

Secondly, and I may be reading too much into things again,
but this SEEMS to IMPLY that ANY signal may be returned,
without being an extension of this package.

Only because the Call Progress Tones Generator Package
EXTENDS the Tone Generator Package, the former's values
can be used with the latter's signals.

But all of the Call Progress Tones and any others can
be used with "Signal Completion" without extending the
Generic package?!?!?

-troy

---

From: "Tulpule, Naren" <[email-masked]>
Date: Tue, 28 Nov 2000 10:59:47 -0800

Hi Troy, list,
  please see comments below.

-- Naren.
These views and opinions are mine alone, not those of Intel    (yet ;-)
Narendra C. Tulpule SMTS, Trillium (an Intel company)
Ph: +1-310-442-9222              Fax: +1-310-442-1162
12100 Wilshire Bl #1800         Los Angeles, CA 90025

-----Original Message-----
From: Troy Cauble [mailto:[email-masked]]

Section 12.1.2 and 12.2 specify data types for Properties
and Parameters.  The specifications include:

        "Enumeration: One of a list of possible unique values. (See 12.3)"
        "Sub-list:  A list of several values from a list."

Section 12.3, "Lists" states:
        Possible values for parameters include enumerations.
        Enumerations may be defined in a list.

Questions:
        Does this imply that "Sub-list" means "list of enums"?
        That is, can a package define Properties or Parameters
        whose values are lists of strings or lists of integers?

[[ NAREN ]] I think so. A parmValue can contain a list of enums, each of
which is a VALUE. It'd serve no purpose IMHO to have VALUE itself as a
list-of-enums (and then parmValue can be a list-of-lists).
One such parameter is tl for tonedet/etd whose value (parmValue) is a list
of toneIDs.

[[ NAREN ]] Glad I am not the only guy who thinks so. It _is_ a pain in the
neck. We could have had an sc event parameter in each package (or its
related package) which has that signal, so e.g. for al/ri signal, we could
have an al/ri event with parameter sc taking no values. (Insert better
example here :-)
Plus the syntax is too complicated for g/sc.

[[ NAREN ]] Yes - essentially everytime you add a package you add a possible
parameter to g/sc! can anyone give a practical example where g/sc will be
_needed_? if "end tone detected" (etd) could take method (Meth) as a
parameter we don't need g/sc for toneIDs.