Subject: Re: Signals

From: Brian Rosen <[email-masked]>
Date: Thu, 28 Oct 1999 17:51:22 -0400

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.  

 Yep and see my last message!  

        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.   

No, it stops on any event that is not KeepActive.  Events you don't want to
keep going, use Notify.  Events you want to keep going use Keep Active. 
Simple, easy, and sufficient. 

        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?   

Sure.  If a BR signal finished between the time you played it and you sent a
new one we don't rewind the media stream :).  If it's over in a millisecond,
the issue doesn't arise.

---

From: Michael Brown <[email-masked]>
Date: Thu, 28 Oct 1999 19:38:04 -0400

Definitely agree with the following definition, and was glad to see that
it doesn't include any specification of the maximum time for a BR
signal. Basically, it is a subjective decision on the implementation as
to what "brief" really is. I also don't think that the protocol should
mandate that a non-interruptable signal or a "long" brief signal with no
events is not allowed. I agree that it would appear to be a stupid thing
to do, but again is a decision that is up to the implementation.

Michael

Brian Rosen wrote:

>
>
>      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.
>
>
>