Subject: Signal Sequences

From: Tom-PT Taylor <[email-masked]>
Date: Wed, 27 Oct 1999 13:13:55 -0400

A number of us have been discussing signals and events behind the scenes.
We do have agreement on several points, most importantly that event and
signal descriptors will be moved back into TerminationState and acquire
StreamId parameters when necessary to apply them to specific media streams.
A little detail on that remains to be settled.

This note is about two proposals on the table for allowing the specification
of a series of signals to be played in sequence.  Both of these proposals
involve a change to the base protocol.  We are agreed on the following:

If multiple signals are presented in the same SignalsDescriptor, they are
played simultaneously.  This allows for stuff like simultaneous audio,
video, and text captions in announcements, or simultaneous update of
displays and indicators.  It may allow for simultaneous application of ADSI
and ringing -- that has to be discussed a bit further.

We have a disagreement on the following proposal:

Baseline proposal: if one SignalsDescriptor is replaced by another on the
same termination, the replacement has the following effects:
  -- signals which were in the first SD but are not in the second one are
stopped
  -- signals which were not in the first SD but are in the second one are
started
  -- signals which are in both SDs are continued
  -- to restart a signal requires that it be stopped, then started,
presumably through two Modify commands applied to the same termination
within the same transaction.

Just to make this proposal absolutely clear: two signals are identical for
the purposes of the above SD comparison if they are identical at the lexical
level (same package name, same signal name, same parameter values).

The disagreeing parties would like to see explicit stop/start/continue
syntax, presumably through an extra parameter on every signal.
*** Comments?

Now on to the main point of disagreement.  There are two proposals for
providing sequence syntax.

Proposal A: the base protocol supports a method playList() which may appear
within any SignalsDescriptor.  The main argument to playList is a sequence
of signals, possibly associated with embedded events.

Proposal B: there is a syntactic entity which I'll call a
SequenceDescriptor.  It may appear within any SignalsDescriptor and looks
just like a SignalsDescriptor does now.  That is, it contains a sequence of
signals, possibly associated with embedded events.  The only difference is
in the semantics: sequential rather than parallel execution.

With both proposals there may be other parameters such as a
stop/start/continue indicator and an indicator calling for the MGC to be
notified when the sequence has finished playing.  If there is a requirement
for multiple sequences to execute in parallel, either proposal supports an
additional sequenceID parameter to allow replacement SignalsDescriptors to
refer to active sequences with an economy of syntax.  Under both proposals
there is work to be done on details regarding what type (BR, TO, probably
not OO) of signals can be in the sequence and whether embedded events apply
to individual events or to the sequence as a whole.  (I see potential
requirements for both.)  In both proposals, the impact on the MG can be
limited by allowing a ROOT configuration parameter indicating the maximum
allowed length of a sequence.

*** So, which approach does the list prefer?

One final point of debate needs to be mentioned: whether there is a
requirement to add dynamically to an already-active sequence of events.  One
school of thought says that we should allow this just in case.  In my own
explorations I have not yet been able to identify the need for this
capability.  In general, when a sequence is involved, the whole sequence is
known in advance.
*** Comments?

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, 27 Oct 1999 23:27:03 +0200

G'Day all,

Attached (PDF) is a file explaining the rational/thinking process behind
Proposal B.

Enjoy!
Christian