Subject: Re: Signals

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

Say 1 second, and I'd rather it be .5 seconds.
 
It is VERY bad to have a long uninterruptible signal.  In fact, I would say
it
is unacceptable to have either a non-interruptible signal, or a long (in
computer
time signal) that has no event when it's finished.
 
The KeepActive prevents normally occurring events from stopping brief
signals.
Abnormal events SHOULD stop brief signals.  Repeating the BR signal keeps it
going if loading a new SignalsDescriptor.  That is ALL we need.
 
Let's cite an example.  Brief signal playing when on-hook occurs.
 
So I say BR stops unless Keep Active keeps it going.  BR without an event
must be
limited to some REALLY short time.  If it's longer, use TO.
 
While I'm at it, someone suggested that TO with duration=0 should defined as

play until it's finished and Notify when complete.  Now THAT would be
useful.

Brian

-----Original Message-----
From: Tom-PT Taylor [mailto:[email-masked]]
Sent: Thursday, October 28, 1999 4:52 PM
To: [email-masked]
Subject: Re: Signals

I believe the definition of BR has to be that the duration of the signal is
preprovisioned and the signal is non-interruptible once its playout begins. 
We could add a recommendation that BR signals not exceed, say, 5 seconds in
length. 

        -----Original Message----- 
From:   John Segers [SMTP:[email-masked]] 
Sent:   Thursday, October 28, 1999 1:40 PM 
To:     [email-masked] 
Subject:        Signals 

        People, 

        Based on the discussion, I have drafted the following text.  After 
sending it to Brian R., I realized I'd forgotten to include StreamID as 
an optional parameters, but that doesn't change the idea. 

        I left the text for "brief" unchanged; I'm willing to make brief 
uninterruptable. 

        Comments? 

        John 
-- 
John Segers                                  email: [email-masked] 
Lucent Technologies                                        Room HE 306 
Dept. Forward Looking Work                      phone: +31 35 687 4724 
P.O. Box 18, 1270 AA  Huizen                      fax: +31 35 687 5954 <<
Message: Signals >>

---

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

Brian Rosen wrote:

<snip>

I definitely agree that the mechanism for "play to completion and
Notify" is useful (I would go further and suggest required), but,
although using the duration=0  with TO does work,  it feels like a
kludge (albeit not a terrible one). I still think though that this
should be treated as a different signal type as I had suggested on an
earlier thread. Or perhaps Peter Blatherwick's suggestion, that this
type of mechanism be handled as part of the packages, such as IVR, that
require it, would really be the best approach.

Michael

>  While I'm at it, someone suggested that TO with duration=0 should
> defined asplay until it's finished and Notify when complete.  Now THAT
> would be useful. Brian