Subject: Megaco Events and Signals

From: Tom-PT Taylor <[email-masked]>
Date: Mon, 25 Oct 1999 15:30:15 -0500

Events and signals, particularly the latter, were a point of major
contention all last week in Redbank.  H.248 as approved is probably still
not everything we could wish for in those two areas.  We have a narrow
window of opportunity between now and Wednesday night where we can clean up
points of difficulty without having to go through the formal ITU
contribution process -- Brian Rosen and John Segers can simply take up the
corrections into the H.248 draft they submit to the ITU for translation and
ballot.  We really need the current text relating to events and signals from
the current protocol document to carry this discussion forward.  Perhaps
Brian or John can supply the required extract.

What I'm going to record here are a few considerations and issues that came
up during discussion.  I've seen a much more sophisticated list of questions
from Nancy Greene which she may pass on, but this note is just to get things
started.

Issue 1: relationship to streams.
=======================
We made a last-minute decision before Redbank to put event and signal
descriptors into the stream descriptor.  This turns out to present several
points of difficulty:

(a) Some actions which have been proposed as signals and some events do not
relate easily to streams or media types:
(i)    We still have to settle whether something like a display update
should be conveyed by means of a signal or a property change; the basic
distinction between signal and property has still to be defined
(ii)   Stuff like line off-hook/on-hook has to be artificially relegated to
a control stream.
(iii)  We have to say that signals and events operate regardless of the
stream mode (send, receive, ...).

(b) Interaction between streams is complicated.
(i)   There is a potential requirement to support multimedia announcement
playout where audio, video, and text captioning must be coordinated.  That
can't be done with our current syntax.
(ii)   In general, there is a need to be able to support embedded signal
descriptors relating to a different stream than the one on which an event is
being detected, or vice versa.

My straw-man proposal is to put event and signal descriptors back into
TerminationState and add streamId as an explicit parameter of events and
signals which need it.  I invite proposals on the distinction between
signals and properties.

Issue 2: Sequences of signals
======================
We got into an endless argument over whether and how to specify playout of
sequences of events.  Here are some of the questions which came up:

(a) We heard requirements for several different types of signal sequence
behaviour:
   -- second signal interrupts and replaces first one
   -- second signal follows first one sequentially after the first one has
completed
   -- second signal is played out simultaneously with the first one (which
may have started earlier).

There are several ways to achieve these behavioural distinctions:
(i)   provide limited behavioural support in the protocol and require the
MGC to fill in the rest through additional messages
(ii)  provide full protocol support for selection of the desired behaviour
(iii) design the behaviour into the definition of individual signals.

There was a strong voice for limiting the amount of intelligence required in
the MG.  Accordingly, the current solution is a mixture of (i) and (iii).
Is this what the Working Group at large is comfortable with?

(b) If the MG is expected to remember and play out a series of signals in
sequence, not only the duration of each signal but also the duration of the
interval between signals has to be provided.

It's time this note got out to the list.  If I remember other points I'll
send them along in another note.

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

---

From: "John A. Voelker" <[email-masked]>
Date: Tue, 26 Oct 1999 10:08:53 -0500

Tom,

Just taking a cut at this, but how about the following for the three signal
sequencing disciplines you mentioned.  Only in the second case would we
distinguish smart vs. dumb MGs:

(1) second signal interrupts and replaces first one -
MGC must explicitly stop the first signal. And with a subsequent command,
initiate the second signal.

(2) second signal follows first one sequentially after the first one has
completed -
A command to apply a signal would have an "optional" parameter that means the
signal is to be applied after the prior signal (how referenced?) has completed.
A dumb GW would reply with the error message "Huh". Then the MGC would need to
itself estimate when the prior signal was completed; and, after that estimated
time period, resend an order to the MG to apply the second signal.  Presumably,
the MGC would subsequently not try to use that optional parameter with that GW.
Instead it would always rely on its own time estimate as to when the first
signal has completed before ordering the application of the second signal.  The
designation "optional" to describe the above parameter needs clarification:  It
is optional in the sense that a MG is not required to support it; however a MG
that does not understand a parameter of that type must not attempt to execute
the corresponding command and must return an error message to the MGC.

(3) second signal is played out simultaneously with the first one (which may
have started earlier) -
Default behavior

An analog to the mechanism applied to case (2) could also be used for (1) if we
think this case happens sufficiently often to justify an optimization supported
by smart MGs.

John Voelker

---

From: Al Varney <[email-masked]>
Date: Tue, 26 Oct 1999 22:18:36 -0500

Without much reflection (no time for that, eh?), I've tried to imagine
the PSTN equivalents for each of the 3 "disciplines".  One general rule
is to avoid "mixing" individual audio signals to a PSTN user (brief
overlap is OK).  For example, mixing BUSY TONE with AUDIBLE RING or an
announcement can confound people and confuse equipment such as modems and
FAX transmitters.  In some cases (SIT, operator tones, in-band signaling),
mixing two signals means neither serves its purpose.

   Thus the DEFAULT behavior of (3 - mix signals) is probably seldom desired,
assuming we are talking about audible tones/announcements.  The current
PSTN routinely cuts off a signal in mid-utterance when starting some new
signal.

   On the other hand, the need for multiple signals following each other in
a fixed sequence would likely be known by the MGC at the time the first
signal command was issued, so it could indicate the "pairing" of such
signals (ad infinitum) by sending them in a single command, with some
sort of option.  Alternatively, MGC could have the end of the first
signal be an event triggering an imbedded new signal -- or is this not
possible?

   The third (1 - stop other signal) discipline would seem to be the most
typical one used in the PSTN today.  What would be nice is a method
for the MGC to say "stop all other AUDIO signals and send this signal
NOW".  Since there may be non-audio signals (is reverse-battery an
example?) that should not be stopped, a "stop ALL signals" indication
is probably not useful.

 Summary:
   If the sequenced signal case can be handled via imbedded event/signal
mechanisms, then I think you just need a "mix audio signals" signal added
to the list of signals.  Send it in the same command with other signal(s)
and they will be mixed with any current signal(s).  And then the simple
case of commanding a signal (without "mix") always IMPLIES that other
audio signals will be stopped.

   I admit I haven't considered the impact on complex packages such as
IVR applications....

Al Varney - Lucent Technologies  +1 630 224-7493    [email-masked]