Subject: Re: Signal lists

From: Tom-PT Taylor <[email-masked]>
Date: Wed, 25 Oct 2000 12:07:29 -0500

I think you have identified an error in the design of the signal list
mechanism.  Obviously it's hard to imagine continuing or discontinuing
playout of the list based on which particular signal was playing at the time
an event occurred.  I think we need an item in the Implementor's Guide which
says that the MGC must either set the KeepActive on ALL signals in a signal
list or on none of them.  Any mixture is an error.

While we're at it, I noticed while reviewing section 7.1.10 that the signal
list is supposed to include a signal type parameter.  Reading on from that
point, one sees that such a parameter (which is not supported in the ABNF)
would be redundant.  The offending statement in section 7.1.10 should be
corrected.

As far as I'm concerned, it is also unnecessary (and I believe you are not
suggesting) that the list itself have a NotifyCompletion flag.  The flags on
the individual events within the list are sufficient.  And the answer to
your final question is "Yes, right.".

> -----Original Message-----
> From: Flemming Andreasen [mailto:[email-masked]]
> Sent: Friday, October 20, 2000 12:03 PM
> To: [email-masked]
> Subject: Signal lists
>
>
> Greetings
>
> A couple of questions on signal lists:
>
> - What does it mean for individual signals in a signal list
> to have the
> KeepActive flag set and how come the signal list itself doesn't have
> such a flag (keeping in mind that "A signal list is treated
> as a single
> signal of the specified type when played out.") ?
>
> - In the definition of Signal Completion (E.1.2) it says "Possible
> values: a list of signals and/or sequential signal lists which have
> terminated.". Does that mean that completion of a signal list itself
> generates a "signal completion" event ?
>
> - A related question for clarification. If a signal in the signal list
> has the "notifyCompletion" flag set, I assume the event will be
> generated when that particular signal finished, right ?
>
>
> Thanks
>
>         Flemming
>
>
> --
> Flemming Andreasen
> Cisco Systems
>

---

From: Christian Groves <[email-masked]>
Date: Fri, 27 Oct 2000 18:00:03 +1100

G'Day Tom and Flemming,

Please see my comments below.

Specific addition to implementors' guide at the bottom of the email.

Cheers, Christian

> list or on none of them.  Any mixture is an error.

[CHG] I guess you can view this is several ways. The KeepActive on ALL
signals certainly makes sense when you don't want any interruption. But
is it erroneous to specify Keepactive on different signals? Certainly
weird behaviour but you may want the initial part of a message to play
irrespective of what event happens and you don't care about the rest of
the signal. I would say that the Keepactive pertains to a moment in time
in the playback of a message.
ie. Signal list  = (s1ka, s2, s3, s4ka)
If you receive an event when S1KA is playing the whole list plays.
If you receive an event when S2 is playing the whole list stops.

> would be redundant.  The offending statement in section 7.1.10 should be

[CHG] OK.

> your final question is "Yes, right.".

[CHG] There is a problem here. A signal may appear in several signal
lists. If you have a notify completion based purely on signal ID and you
have the same signal in several lists you don't know what list
completed. Therefore we probably need to add a SignalList ID parameter
to the package E.1.2.
ie.
Signal List ID
ParameterID:  SLID (0x0003)
Indicates to which signal list a signal belongs
Type: integer
Possible values: Any integer

> > generates a "signal completion" event ?
[CHG] No the signal generates the "Signal completion" event. If you put
the notify completion on the last signal in the list

> > generated when that particular signal finished, right ?
[CHG] Yep
> >         Flemming

8.17 Signal Lists

Description:    There are several inconsistency in the way the signal has
been documented they are:
Section 7.1.11 states that Signal Lists have type. This is incorrect.
Section E.1.2 Doesn't not allow for the specification of which list
instance of a signal contained in several lists should generate a notify
completion.
Reference:      From: Flemming Andreasen [mailto:[email-masked]]
Sent: Friday, October 20, 2000 12:03 PM
To: [email-masked]
Subject: Signal lists
 [Begin Correction]
Section 7.1.11 Signal Descriptor

A sequential signal list consists of a signal list identifier and, a
sequence of signals to be played sequentially, and a signal type.  Only
the trailing element of the sequence of signals in a sequential signal
list may be an on/off signal.  If the trailing element of the sequence
is an on/off signal, the signal type of the sequential signal list shall
be on/off as well.  If the sequence of signals in a sequential signal
list contains signals of type timeout and the trailing element is not of
type on/off, the type of the sequential signal list SHALL be set to
timeout.  The duration of a sequential signal list with type timeout is
the sum of the durations of the signals it contains.  If the sequence of
signals in a sequential signal list contains only signals of type brief,
the type of the sequential signal list SHALL be set to brief.  A signal
list is treated as a single signal of the specified type when played
out.
[End Correction]
[Begin Correction]
Section E.1.2 Events
…

Termination Method
ParameterID:  Meth (0x0002)
Indicates the means by which the signal terminated.
Type: enumeration
Possible values:
"TO" (0x0001) Duration expired
"EV" (0x0002) Interrupted by event
"SD" (0x0003) Halted by new Signals Descriptor
"NC" (0x0004) Not completed, other cause

 Signal List ID
ParameterID:  SLID (0x0003)
Indicates to which signal list a signal belongs
Type: integer
Possible values: Any integer
[End Correction]