Subject: Minutes Of Second Packages Conference Call

From: Tom-PT Taylor <[email-masked]>
Date: Fri, 8 Oct 1999 21:27:54 -0400

A second conference call on packages was held for two hours beginning at
10:00 am EDT, Thursday, Oct. 7.  Participants included Tom Taylor, Brian
Rosen, Mike Kallas, Nancy Greene, Peter Blatherwick, Abdallah Rayhan,
Jastinder Jawanda, Roy Spitzer, Michael Brown, John Voelker, John Segers,
Zacharias Bilalis, and Christian Groves.  I may have missed some.

The framework for the discussion was a review of the proposed package
documentation format, version 3, provided to participants in the call by
Mike Kallas.  As you will see, this served as a launch-pad for a number of
discussion points.

1.  Stream dependence of events and signals.

Brian Rosen noted the frequent appearance of the streamId parameter to
events and signals in the draft package document.  He suggested that events
and signals appear within the stream descriptor so that this will no loger
be necessary.  (This proposal has also appeared on the list.)  It was noted
that events like line off-hook are not associated with a stream.  John
Voelker pointed out that we have the concept of a control stream.  It was
agreed that such events/signals would be associated with stream 0, which
would be a control stream by default.  Documentation of events and signals
in general must make clear the media type(s) to which they relate.  As for
audio (stream 1 by default), explicit enclosure of control stream events and
signals within a stream descriptor is unnecessary if there is no ambiguity.

***Action: the list should review this conclusion for validity.  Besides
line and trunk supervision events/signals, it will affect the treatment of a
number of the events and signals in the business set related packages.

2.  "Short Name"

The current package documentation proposal uses the expression "Short Name"
for the package.  This should be called "pkgdName" to be consistent with the
ABNF.

3.  ROOT vs. Termination-Related Packages

There was considerable discussion about the distinction between packages
which relate to the MG as a unit, versus packages which relate to the
terminations which it supports.  It was agreed that there is also a need to
define packages which relate to classes of terminations (e.g. RTP
terminations).  The scope of a given package: relating to the MG, relating
to a class of terminations, or relating to instances of terminations -- must
be made clear in the documentation.

4.   Method For Defining Characteristics Of Classes Of Terminations

There: I've used that word "class" again.  In any event, we need to define
the applicable properties, events, signals, and statistics for terminations
over specific transports: RTP, ATM with subtypes by AAL, digital circuit,
etc.  Tom Taylor proposed to the conference to use a list of pkgdName rather
than a network type within LocalControl to accomplish this.  A list is
needed to support designation, for example, of ATM in the first instance and
AAL5 as a further refinement.  It was agreed that this proposal should be
spelled out to the list for comment.
***Action: Tom Taylor to provide complete description of proposed solution
to the list.

5.   Naming Scope For Tones Defined By defTone Descriptor

It was agreed that the naming scope of tones defined by the defTone
descriptor would follow the same rules as the naming scope for digit maps.
Defaults for individual terminations, groups of terminations, or classes of
termination would be defined by assigning definitions in the NULL context.
The definition for a given name on a given termination can be overridden by
assigning a new definition within another context.  Upon reversion to the
NULL context, the termination reacquires the default definition.

My notes say that some issues may remain on what syntax is needed to audit
default values, but I didn't capture them.  Could another participant
provide details?

6.  Extensions Of Packages

This point was a reprise of the discussion on support particularly of
tone-related events and signals, where new packages extend previous ones by
adding to the list of values permissible for a given property or parameter.
It was agreed that extensions would be strictly deltas rather than supersets
absorbing the packages being extended, to avoid overlapping package
definitions where the same base package was augmented by different
extensions.  The documentation for an extension package must name the
package it extends.  If P1 is the base package, P1 extends P1, and P3
extends P2, then:
(a) the documentation of P3 indicates that it extends P2;
(b) If an MG indicates that it supports P3, it must also support P1 and P2.

The problem now is how to refer to the events and signals being requested.
(1) To take a specific example: would playTone where the tones to be played
are a string of DTMF digits be referred to as gaudio/playTone(list of
tones), DTMFP/playTone(list of tones), or gaudio/DTMFP/playTone(list of
tones)?
(2) Moreover, in that list of tones, must the tones themselves be qualified
by package name?  This would be new to our syntax.
(3) When asking for detection, what syntax would be used to request
detection of tones belonging to a given package?

The tentative answer to (1) and (2) seems to be to use the base package name
for the event or signal: gaudio/playTone, in this case.  The tone names
themselves are required to be unamabiguous -- they all share the same name
space, despite being defined in different packages.

One suggested answer to (3) is that the event name in the eventDescriptor
might be qualified with the name of the package defining the class of tone
to be detected.  For example, if the occurence of any DTMF tone is to be
detected, the event designation would be DTMF/toneDetect(); if FAX tones are
wanted, the event designation would be FAX/toneDetect().  This requires
further discussion.  The alternative is to indicate the candidate set of
tones by listing them all as parameters of gaudio/detectTone(), or, if any
tone in a given package is to be detected, giving the package name as a
parameter.  We should take into account that tones named by defTone
descriptors must of course be specified individually, since they do not
belong to any package.

7.  Documentation Of Properties

Documentation guidelines should ensure that the following are documented for
each termination property in a package:
 -- whether it is stream-dependent or applies to the termination as a whole
 -- the type and permitted range of the property's values
 -- whether it is a read-only property of the termination (available through
audit only) or read/write.

8.  Documentation Of Events

The current guidelines provide for separate documentation of syntax for
events as they appear in a descriptor and the syntax of the resulting
notifications.  There was a counter-proposal to use a single table, marking
each parameter to indicate whether it appears in the event descriptor, the
notification, or both, but the decision was to leave the format up to the
package editors.

9.  Disposition Of "Rerequest"

It was decided that, because it causes side effects, the "rerequest"
parameter shown in the current draft of the packages should instead be a
property co-located with the other properties affecting event and signal
processing.

Tom Taylor
Advisor -- IPConnect Standards
E-mail: [email-masked] (internally, Tom-PT Taylor)
Phone and FAX: +1 613 736 0961

---

From: Tom-PT Taylor <[email-masked]>
Date: Mon, 11 Oct 1999 21:16:01 -0500

Second try.  Didn't make it the first time, for some reason.  Maybe my
computer was jet-lagged.

> -----Original Message-----
> From: Taylor, Tom-PT [CAR:B904-I:EXCH]
> Sent: Friday, October 08, 1999 9:20 PM
> To:   'Megaco'
> Subject:      Minutes Of Second Packages Conference Call
>
> events and signals in the draft package document.  He suggested that
> events and signals appear within the stream descriptor so that this will
> no loger be necessary.  (This proposal has also appeared on the list.)  It
> was noted that events like line off-hook are not associated with a stream.
> John Voelker pointed out that we have the concept of a control stream.  It
> was agreed that such events/signals would be associated with stream 0,
> which would be a control stream by default.  Documentation of events and
> signals in general must make clear the media type(s) to which they relate.
> As for audio (stream 1 by default), explicit enclosure of control stream
> events and signals within a stream descriptor is unnecessary if there is
> no ambiguity.
>
> line and trunk supervision events/signals, it will affect the treatment of
> a number of the events and signals in the business set related packages.
>
> 2.  "Short Name"
>
> The current package documentation proposal uses the expression "Short
> Name" for the package.  This should be called "pkgdName" to be consistent
> with the ABNF.
>
> terminations which it supports.  It was agreed that there is also a need
> to define packages which relate to classes of terminations (e.g. RTP
> to a class of terminations, or relating to instances of terminations --
> must be made clear in the documentation.
>
> the applicable properties, events, signals, and statistics for
> terminations over specific transports: RTP, ATM with subtypes by AAL,
> digital circuit, etc.  Tom Taylor proposed to the conference to use a list
> of pkgdName rather than a network type within LocalControl to accomplish
> this.  A list is needed to support designation, for example, of ATM in the
> first instance and AAL5 as a further refinement.  It was agreed that this
> proposal should be spelled out to the list for comment.
> Defaults for individual terminations, groups of terminations, or classes
> of termination would be defined by assigning definitions in the NULL
> context.  The definition for a given name on a given termination can be
> overridden by assigning a new definition within another context.  Upon
> reversion to the NULL context, the termination reacquires the default
> definition.
>
> tone-related events and signals, where new packages extend previous ones
> by adding to the list of values permissible for a given property or
> parameter.  It was agreed that extensions would be strictly deltas rather
> than supersets absorbing the packages being extended, to avoid overlapping
> package definitions where the same base package was augmented by different
> (1) To take a specific example: would playTone where the tones to be
> played are a string of DTMF digits be referred to as gaudio/playTone(list
> of tones), DTMFP/playTone(list of tones), or gaudio/DTMFP/playTone(list of
> tones)?
> (2) Moreover, in that list of tones, must the tones themselves be
> qualified by package name?  This would be new to our syntax.
> The tentative answer to (1) and (2) seems to be to use the base package
> name for the event or signal: gaudio/playTone, in this case.  The tone
> names themselves are required to be unamabiguous -- they all share the
> same name space, despite being defined in different packages.
>
> detected, the event designation would be DTMF/toneDetect(); if FAX tones
> are wanted, the event designation would be FAX/toneDetect().  This
> requires further discussion.  The alternative is to indicate the candidate
> set of tones by listing them all as parameters of gaudio/detectTone(), or,
> if any tone in a given package is to be detected, giving the package name
> as a parameter.  We should take into account that tones named by defTone
> Documentation guidelines should ensure that the following are documented
> for each termination property in a package:
>  -- whether it is a read-only property of the termination (available
> through audit only) or read/write.
>
> notifications.  There was a counter-proposal to use a single table,
> marking each parameter to indicate whether it appears in the event
> descriptor, the notification, or both, but the decision was to leave the
> format up to the package editors.
>