Subject: Packages Conference Call Minutes

From: Tom-PT Taylor <[email-masked]>
Date: Tue, 5 Oct 1999 06:36:02 -0500

This records the results of a conference call held for two and a half hours
Monday beginning at 11:00 am EDT.  Those present on the call (and welcome to
add comments if I have missed or mis-stated something) were
Tom Taylor, John Segers, Peter Blatherwick, Jastinder Jawanda, Michael
Brown, Ashok Khuntia, Bilalis Zacharias, Nancy Greene, Brian Rosen, Neta
Zmora et al, Christian Groves, Mike Kallas, Glen Freundlich, and Roy
Spitzer.

1. Basic package versus other packages.

Packages have equal status whether they are documented in the basic package
document or in other documents.  The process for these other documents will
be discussed at the November meeting.  IMHO we must distinguish between
private packages (only the package name is registered with IANA) and public
packages (the complete package specification is a matter of permanent public
record).

The basic package document will be published as an IETF Informational RFC at
the same time as the basic protocol document (as agreed in Oslo).  The ITU
will probably publish it as an annex to H.248.

We agreed that the guiding principle for basic package specification was to
avoid controversy.  The basic packages form a starter kit to make the
protocol work.  The argument made by the drafting team is that this starter
kit should include capabilities for business as well as residential
gateways.

2. Auditing media (and other) capabilities of the MG

The current draft of the basic packages document lacks the packages needed
to indicate the media capabilities of the MG.  It is clear that there is
some relationship between those capabilities and the types of termination
(DS-0, ATM of various flavours, RTP, FR, ...) supported, but our current
syntax allows properties to be attached only to ROOT and individual
terminations.  It would be good to minimize the amount of information which
must be passed during the starting up audit -- retrieval of media
capabilities by individual termination is probably overkill.  It is unclear
whether we have the correct syntax to support description of simultaneous
and mutually exclusive sets of capabilities in the way Christian Huitema's
draft showed necessary.

***Action: Tom Taylor to provide a clear problem statement.
***Action: Brian Rosen to provide a proposed syntactic solution.

3. Basic policy on package definition

There was agreement with reservations that packages should be defined such
that their implementation in an MG is all-or-nothing.  If a package needed
to be extended, it would be done by defining a new package containing the
incremental items required.  The reservation was due to a concern that this
may lead to such a degree of fragmentation that the package list retrieved
on audit would be of unwieldy length.  We will act on the basis of the
agreed policy for the moment.

4. Handling of tones and other extensible lists of parameter values

Tones in particular are problematic, in that not all MGs (or even MGCs)
should implement every tone.  It was also recognized that an MG may have a
requirement to be able to play a tone, but no need to detect it, or vice
versa.

To start with, it was agreed that a small set of basic events and signals
would be defined to play and detect tones.  The identity of the tone to be
played or detected would appear as a parameter of the event or signal.

We discussed methods of organizing tones within packages to meet the
requirements.  One possibility is to define packages whose content would
consist solely of a list of tone names to be played out or detected.  Mike
Kallas asked for the chance for his drafting team to come up with a
solution.

***Action: Mike Kallas and Zacharias Bilalis to publish a proposed solution
to the list by the end of Wednesday.
***Action: Tom Taylor to organize a follow-up conference call to begin
Thursday at 10:00 am EDT (4:00 pm German time, 8:00 am MDT, 9:00 am CDT).

It was noted that this requirement may apply to other events and signals
besides tones.  (I believe I had an example I considered a few days ago, but
I've forgotten what it was.)
***Action: The list is asked to indicate whether this is so.

5. Event aliasing

Tom Taylor pointed out that for FAX service, calling (CNG) and called (CED)
tone events should be reported separately.  Roy Spitzer raised the objection
that the CED tone is identical to modem answer signal.  We realized that
this problem of event aliasing is more general, and requires a solution.
The problem statement is this: a given physical event may correspond to more
than one event as defined in one or more package specifications.  The MGC
has some control over event reporting, in that it can state which events the
MG should watch for.  If despite this the MGC supplies an event descriptor
which sets up the event aliasing situation which of the following
alternatives should we specify:

(a) the MG should report the first applicable event it finds in the event
descriptor;

(b) the MG reports all of the applicable events;

(c) we should add to the syntax so that the MGC can control which of (a) or
(b) applies in a given situation;

(d) none of the above -- some other solution.

***Action: the list to indicate a preference.

6. Actions other than events and signals

Draft 00 of the basic packages contains several methods which are neither
events nor signals -- for example, the defTone action.  defTone (which
allows the MGC to provision a named toned description in the MG, possibly
temporarily over-riding the MG default description in real time) was
accepted in principle.  However, since it is neither an event nor a signal
itself, the proper solution is to add it as a new property type, with
associated descriptor.  (It was agreed in principle that tone descriptions
and digit maps should have the same syntactic solution, but it is probably
too late to change the exceptional syntactic treatment accorded to digit
maps.  I make this remark to test the waters for a change, if the list cares
to comment.)

***Action: Mike Kallas and Bilalis Zacharias to modify the basic package to
make the following into properties/descriptors:
 - generic audio/define tone
 - Function key/assign function key name
 - Indicator/set name
 - Softkey/set name

7. Complex events

Tom Taylor had proposed the creation of complex events comprising a sequence
of events and signals with carefully pre-defined behaviour.  It was noted
that this was a variation on the theme of scripting -- the feeling of the
group seemed to be that it should not be done.  There is still the problem
of ensuring that dial tone ends when the first digit is received.  In
effect, this is a new class of behaviour added to the set {BR, OO, TO} which
we have already defined.  Nancy pointed out that the protocol document
already states that a signal stops being applied as soon as an event is
detected [in an embedded descriptor? in an event descriptor in the same
command? Have to check.].

***Action: list to verify that existing behavioural specification is
sufficient to meet requirements.

8. Missing packages

The basic packages draft currently lacks a package for analogue line
supervision, containing the on-hook, off-hook, and hookflash events and the
physical ringing signal.
***Action: Tom Taylor to draft the package specification.

Tom Taylor also noted that a V.18 package is in preparation to allow for
text conversation for the disabled.

9. Directionality

After considerable discussion it was agreed that the following
interpretations of terms dealing with direction are to be applied:

terminationMode=send implies that the stream passes through the termination
toward the exterior of the MG

terminationMode=receive implies that the stream passes through the
termination toward the centre of the context (and thence to all other
terminations, except as modified by a topology descriptor)

Signals applied on a termination pass toward the exterior of the MG.  There
is a requirement under some circumstances to pass the same signals to all
other terminations.  The fallback position is that this is done by applying
the same signal to every termination in the context where it is required.
***Action: list to consider whether additional syntax is preferable to
indicate two-way propagation of the signal.

Events at a termination are detected on the termination itself (e.g.
supervision events) or on streams incoming from the exterior of the MG
(received streams).

***Action: Brian and John to update the basic protocol document to reflect
this terminology.

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

---

From: Christian Groves <[email-masked]>
Date: Wed, 6 Oct 1999 00:06:06 +1000

G'Day Tom,

Please see my comments below [CHG]

Cheers, Christian

> packages (the complete package specification is a matter of permanent public

[CHG] I would guess that as part of a package registration process for a
package that comes from a standards body is that it could have a certain
prefix ie. ITU, ETSI, TIA etc and that when a Package name is registered
it then has to point to a certain Technical recommendation or name.

> agreed policy for the moment.

[CHG] Can you please clarify the agreement? I can see that when you
implement a PAckage that you should implement all the properties but
should you have to implement all the values of the property in the
package. The example given was codec properties. I'm not sure that we
agreed.

> ***Action: the list to indicate a preference.

[CHG] I like alternative B

> toward the exterior of the MG

[CHG] Does the latest ABNF support terminatinMode = send, receive,
send/rec ?? It seems to be missing and should be added.