Subject: Re: Signals

From: Peter Blatherwick <[email-masked]>
Date: Thu, 28 Oct 1999 16:42:54 -0500

Some quick clarifications.  See below

> -----Original Message-----
> From: John Segers [SMTP:[email-masked]]
> Sent: 28 Oct, 1999 13:18
> To:   Brian Rosen
> Subject:      Signals
> 
> Brian, Tom,
> 
> Here's some draft text for the signals descriptor section.  It does
> basically what you proposed, but is slightly more general.  Let me know
> what you think.
...
>  There are three types of signals:
        · on/off - the signal lasts until it is turned off,
        · timeout - the signal lasts until it is turned off or a specific
period
        of time elapses,
        · brief - the signal duration is so short that it will stop on its
own
        unless a new signal is applied that causes it to stop; no timeout
value
        is needed.

I definitely prefer the definition of brief as here (its interruptible, but
has defined duration so will stop on its own).  This allows the MGC to make
up its own mind if it wants to stomp a signal in progress.  After all, the
MGC is the master.  "Atomic" definition (can't stop it once started, as
suggested by Tom) does not allow this.  Would need to supply play_finished
and similar events in the relevant packages, to allow MGC to know when
signals complete, but we can do that easily and its probably a good idea
regardless.  

...
> Production of a Signal on a Termination is stopped by application of a
> new SignalsDescriptor, or detection of an Event on the Termination (see
> Section 7.1.9).
> 
Event only stops signals if there is an embedded SignalsDescriptor, and if
there is one then the rules for SignalsDescriptor (next paragraph) get
applied.  Correct?  If correct, I suggest some careful wording to clarify.  

> A new SignalsDescriptor replaces any existing SignalsDescriptor.  Any
> signals applied to the Termination not in the replacement descriptor
> shall be stopped, and new signals are applied.  Signals present in both
> the existing and replacement descriptor, with the same parameters in
> both, shall be continued.  If the replacement descriptor contains a
> sequential signal list with the same identifier as the existing
> descriptor, then
> · the sequence of signals in the sequential signal list in the
> replacement descriptor shall be empty, and
> · the playing of the signals in the sequential signal list in the
> existing descriptor shall not be interrupted.
> 
My understanding, based on discussion, is:  The signal replacement rule is
applicable to signals that have duration, such as playing of tones and
announcements.  Many signals are "immediate" and have no duration, such as
going on/off hook, turning on/off indicators, updating display.  The latter
class of signals would NOT be wiped out (ie display not cleared, indicators
not turned off) by a new SignalsDescriptor.  Correct?  

Hopefully this is correct.  If these are not correct I believe we still have
either a very bulky signals updating mechanism, requiring a LOT of
unnecessary information carried to make minor updates or diddle a user
interface, or we have a mechanism which does not easily allow for user
interface at all.   

Will implementation of sequential signal list be optional to implement?  I
hope so, as this adds a burden to "dumb" MGs which is likely not needed for
a large portion of applications.  

I admit I was not able to follow the debate in real time over the last
couple of days, so I hope I didn't miss something going by.  

-- Peter Blatherwick