Subject: Re: Signals

From: Brian Rosen <[email-masked]>
Date: Fri, 29 Oct 1999 14:15:52 -0400

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. 

Comment above was about Signals, not Events.  Agree with events part.   

I would say that if there is an embedded signals descriptor, and it repeated
a signal that was in the original signals descriptor, that it was
interpreted with the new semantics of replaced Signals Descriptor, which
would mean that it continued.

Please confirm understanding re embedded SignalsDescriptor overriding
existing SignalsDescriptor as per first level rules, and only if there is an
embedded SignalsDescriptor does this overriding occur.  Otherwise, existing
Signals carry on.   Correct?   

Hmmm, I'm confused.

    Signals Playing Now    Action    Embedded Signals    Result
        SigA                       Notify           none                  
SigA stops
        SigA                       Notify           SigA                  
SigA continues
        SigA                     Keep Active    none                   SigA
continues
        SigA                     Keep Active    SigA                   SigA
continues
        SigA                        Notify         
SigB                   SigA stops, SigB starts
        SigA                     KeepActive     SigB                   SigA
stops, SigB starts
        SigA                        Notify          SigA, SigB          SigA
continues, SigB starts
        SigA                     KeepActive     SigA, SigB          SigA
continues, SigB starts 

                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. 

Agreed then.  "Immediate" signals are not affected by arrival of a new
SignalsDescriptor unless it contains some explicit action (explicitly clears
display, etc).   

Agreed 

 Brian