Subject: Re: Signal lists

From: Tom-PT Taylor <[email-masked]>
Date: Fri, 27 Oct 2000 08:39:36 -0400

Hi:

> -----Original Message-----
> From: Christian Groves [mailto:[email-masked]]
> Sent: Friday, October 27, 2000 3:00 AM
> To: [email-masked]
> Subject: Re: Signal lists
>
>
> G'Day Tom and Flemming,
>
> Please see my comments below.
>
> Specific addition to implementors' guide at the bottom of the email.
>
> Cheers, Christian
>
> Tom-PT Taylor wrote:
> >
> > 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.
>
> [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.

[PTT] I had second thoughts myself.  Guess this is a case where we accept
that the MGC knows what it is doing.

>
> >
> > 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.
>
> [CHG] OK.
>
> >
> > 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.".
>
> [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.

[PTT] Good catch.  What is the value if the signal does not belong to a
signal list, or do we simply say that the parameter MUST NOT be returned in
that case?

> ie.
> Signal List ID
> ParameterID:  SLID (0x0003)
> Indicates to which signal list a signal belongs
> Type: integer
> Possible values: Any integer
>
> >
> > > -----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 ?
> [CHG] No the signal generates the "Signal completion" event.
> If you put
> the notify completion on the last signal in the list
>
> > >
> > > - 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 ?
> [CHG] Yep
> > >
> > >
> > > Thanks
> > >
> > >         Flemming
> > >
> > >
> > > --
> > > Flemming Andreasen
> > > Cisco Systems
> > >
>
> 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]
>

---

From: Christian Groves <[email-masked]>
Date: Mon, 30 Oct 2000 11:23:39 +1100

G'Day Tom,

..snip..
> [PTT] Good catch.  What is the value if the signal does not belong to
> a signal list, or do we simply say that the parameter MUST NOT be
> returned in that case?
>
[CHG] I'll add a note to the effect that the SignalList ID not be
returned in the case where the signal doesn't belong to the list.