Subject: Re: Signals

From: Peter Blatherwick <[email-masked]>
Date: Fri, 29 Oct 1999 10:19:50 -0500

See further comments below...

> -----Original Message-----
> From: Brian Rosen [SMTP:[email-masked]]
> Sent: 28 Oct, 1999 17:51
> To:   Blatherwick, Peter [CAR:AT14:EXCH]; 'John Segers'; Brian Rosen;
> Taylor, Tom-PT [CAR:B904-I:EXCH]
> Cc:   [email-masked]
> Subject:      RE: Signals
> 
...

>               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. 
> 
Comment above was about Signals, not Events.  Agree with events part.  

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?  

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

-- Peter Blatherwick