I have an interesting situation with the Advanced Audio Server packages (H.248 Annex M.1), and I wanted to check out my proposed solution with the list.
The "basic" package currently consists of three functions: play, play and collect digits, and play and collect a recording. It also includes an extensive description of a syntax for specifying individual announcements, including variable elements. This syntax appears to the Megaco/H.248 grammar as a parameter VALUE in quotedString form.
One "advanced" package defined in the current draft Annex doesn't change any of the functions, but extends the announcement-specifying syntax. Using past practice as a guide, the package was modelled as an extension of the basic one. However, note that the new functionality is actually hidden below the level that would normally distinguish an extension -- no new signals or events are added, and no new parameters are added. (That last wouldn't be legal in any event.)
However, this approach doesn't really work. The first sign of trouble was when I thought to split up the play, play-and-collect, and play-and-record functions, both to clarify the functional definitions and because it would provide more flexibility for product implementation. How would I introduce the "advanced" syntax for each function? Do I need to define an "advanced" package for each, so that the two packages become six?
It becomes worse now that more than one advanced syntax feature has been proposed. I now need a package for the basic announcement syntax, one for that plus feature A, one for that plus feature B, and a fourth one for all three features together. You get the idea: an exponential explosion, multiplied by the number of functions if we decide to split them.
I have an answer to this, but I thought it might be a good idea to legitimize it. It could even lead to a v2 formalization of the process if accepted (with no change in what goes out over the wire!). My proposal is this:
1) We define the announcement specification syntax itself in a package of its own. Note that this package will have none of the usual content -- no properties, signals, events, or statistics.
2) We define each additional feature of the announcement specification syntax in another package which is an extension of the basic syntax package.
3) Within the functional packages (play, play-and-collect, etc.) we say first that the package USES the syntax of the basic syntax package and secondly that if any extension of the basic syntax package is supported the functional package also USES that extension. An implication is that if a device supports an advanced syntactical feature (e.g. sets) for one function it MUST support that feature for all of the functions it implements.
Comments? Is this a legitimate use of packaging? Should we add the USES relationship to our section 12 package description requirements in v2?
Please copy follow-ups to the Megaco list, now at megaco@ietf.org.
Tom Taylor taylor@nortelnetworks.com Ph. +1 613 736 0961 (ESN 396 1490)
G'Day Tom,
I do support multiple packages for the play, playcol, playrec functionality. I don't know that we need to introduce a new USES concept for this. We shall produce an H.248 Annex M.4 for this. It can contain any headings we like. We can update the annex at any time we like. Also remember that the syntax is a property value and we can support what property values we like. ie. a subset of the total. We audit to find out what values are supported. Packages may also extend the values defined in other packages.
So what I propose is a structure: H.248 Annex K 1. Summary 2. References 3. Definitions 4. Introduction 5. Syntax 5.1 Basic 5.2 Extended 1 5.3 Extended 2 6. Package 1 Value: See Syntax Basic 5.1 7. Package 2 Extends: 1 Value: See Syntax 5.1 + Syntax Extended 5.3 etc..
(ie. we audit to find out what values are supported). Perhaps we can define a functional extension with a name. We can then introduce a property "Syntax Extensions". This way the MGC can find out exactly which extension it needs to support.
Does this help any?
Christian
Tom-PT Taylor wrote:
I have an interesting situation with the Advanced Audio Server packages (H.248 Annex M.1), and I wanted to check out my proposed solution with the list.
The "basic" package currently consists of three functions: play, play and collect digits, and play and collect a recording. It also includes an extensive description of a syntax for specifying individual announcements, including variable elements. This syntax appears to the Megaco/H.248 grammar as a parameter VALUE in quotedString form.
One "advanced" package defined in the current draft Annex doesn't change any of the functions, but extends the announcement-specifying syntax. Using past practice as a guide, the package was modelled as an extension of the basic one. However, note that the new functionality is actually hidden below the level that would normally distinguish an extension -- no new signals or events are added, and no new parameters are added. (That last wouldn't be legal in any event.)
However, this approach doesn't really work. The first sign of trouble was when I thought to split up the play, play-and-collect, and play-and-record functions, both to clarify the functional definitions and because it would provide more flexibility for product implementation. How would I introduce the "advanced" syntax for each function? Do I need to define an "advanced" package for each, so that the two packages become six?
It becomes worse now that more than one advanced syntax feature has been proposed. I now need a package for the basic announcement syntax, one for that plus feature A, one for that plus feature B, and a fourth one for all three features together. You get the idea: an exponential explosion, multiplied by the number of functions if we decide to split them.
I have an answer to this, but I thought it might be a good idea to legitimize it. It could even lead to a v2 formalization of the process if accepted (with no change in what goes out over the wire!). My proposal is this:
- We define the announcement specification syntax itself in a package of
its own. Note that this package will have none of the usual content -- no properties, signals, events, or statistics.
- We define each additional feature of the announcement specification
syntax in another package which is an extension of the basic syntax package.
- Within the functional packages (play, play-and-collect, etc.) we say
first that the package USES the syntax of the basic syntax package and secondly that if any extension of the basic syntax package is supported the functional package also USES that extension. An implication is that if a device supports an advanced syntactical feature (e.g. sets) for one function it MUST support that feature for all of the functions it implements.
Comments? Is this a legitimate use of packaging? Should we add the USES relationship to our section 12 package description requirements in v2?
Please copy follow-ups to the Megaco list, now at megaco@ietf.org.
Tom Taylor taylor@nortelnetworks.com Ph. +1 613 736 0961 (ESN 396 1490)
Megaco mailing list Megaco@ietf.org http://www.ietf.org/mailman/listinfo/megaco
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
participants (2)
-
Christian Groves -
Tom-PT Taylor