Subject: Re: Cisco SG16: Signals Operation

From: Tom-PT Taylor <[email-masked]>
Date: Wed, 2 Feb 2000 20:17:45 -0500

I have every sympathy with your first point -- I couldn't resist the
temptation to propose a new definition of BR.  The fact is, the way things
currently stand, we could abolish the signal type parameter and it would
make no difference to the operation of the protocol.  I suppose we would
have to define an "infinite" duration to simulate on/off as currently
defined, but even that might not be necessary.

Speaking as chair, I suppose I have to say that the null hypothesis is that
we stick with our current text.  We have two other alternatives:

(a) New distinctive definitions for BR, TO, OO, with the understanding that
the definition of a given signal indicates its default type, but that type
can always be overridden by the type parameter.
 - BR duration is assumed to be known to the MG without explicit MGC input.
BR signals can be stopped by detection of events without the KeepActive
parameter or by replacement of the current signal descriptor with one not
containing the indicated signal.
 - TO duration is given explicitly by the duration parameter.  A default may
be provisioned or defined in the package.  TO signals can be stopped by
detection of events without the KeepActive parameter or by replacement of
the current signal descriptor with one not containing the indicated signal.
 - OO signals remain active until a signal descriptor with explicit turn-off
syntax comes into effect (Chip's proposal).

(b) Abolish signal type.

If I see a sudden rush to agreement on something other than the existing
text I'll feed it into Geneva.  Otherwise things stay put and we can try
again for H.248v2 -- the protocol works as is.

Comments to the other points follow them.

> -----Original Message-----
> From: Chip Sharp [SMTP:[email-masked]]
> Sent: Tuesday, January 25, 2000 7:59 PM
> To:   [email-masked]
> Subject:      Cisco SG16: Signals Operation
>
> Section:        7.1.10, fourth paragraph, first bullet.
> Category:       Technical, Open Issue
> Issue:          The draft text defines on/off signals "the signal lasts
> until it is
> turned off", however this definition is not clear. Specifically, it is not
> clear if an on/off signal is turned off by not being included in a
> subsequent SignalsDescriptor or if it is turned off by some explicit
> action. In the latter case, syntax is missing leading one to believe that
> the former definition is intended. The former definition on the other hand
> is somewhat problematic and overlaps the definition of time-out signals
> with an indefinite duration. Consider for instance a "visual message
> waiting indicator" defined as an on/off signal. Unless the signal is
> included in all subsequent SignalsDescritpors, the indicator will be
> turned
> off. The on/off signal type would be more useful (and not a duplicate of
> timeout) if this was not the case.
> Also, it should be noted, that the more general topic of signal types and
> the details of their operation has been the subject of much debate on the
> IETF Megaco mailing list since the white contribution was developed, and
> that at time of writing, no resolution had been found.
>
> Proposal:       It is recommended that the definition of on/off is
> clarified in
> accordance with the above and the missing syntax added.
>
> v13 Status:     OPEN. No substantial change has been made.
>
> Section:        7.1.10, fourth paragraph, second bullet
> Category:       Technical
> Issue:          The draft text defines timeout signals as "the signal
> lasts until
> it is turned off or a specific period of time elapses", however there is
> no
> mechanism specified for informing the MGC when that specific period of
> time
> has elapsed and thus the signal has ended. The MGC may therefore be unable
> to determine if a given signal is playing in an MG or not. An example
> where
> this is needed is outpulsing with MF Feature Group D trunks where multiple
> digit strings (address and caller id) need to be outpulsed. MGC needs to
> know when outpulsing of the first string of digits has occurred before
> requesting out-pulsing of the next string.). Another example is a signal
> activated through an external event such as user input (by use of an
> embedded signals descriptor).
>
> Proposal:       It is strongly recommended that a mechanism for notifying
> the MGC
> upon timeout signal completion is added, e.g. in the form of an event
> ("operation complete"). Furthermore, it should be considered to add
> another
> event that would allow the MGC to be informed if generation of the signal
> fails for some reason (e.g. "operation failure"). It should be noted, that
> this may happen in the middle of the signals defined duration.
>
> v13 Status:     OPEN. No substantial change has been made.
>
        [[TomT]]
        v14 adds the notifyCompletion parameter for every signal and text on
how completions are notified in section 7.2.7.  For failures we have that
generic failure event in E.1, but no text on how to apply it or what request
ID to use for it.

> Section:                12.1.4
> Category:       Technical, Open Issue
> Issue:          The draft text mentions SignalType CN (Continue), however
> this
> SignalType is not defined in Section 7.1.10 on Signals Descriptor.
> Also, it should be noted, that the more general topic of signal types and
> the details of their operation has been the subject of much debate on the
> IETF Megaco mailing list since the white contribution was developed, and
> that at time of writing, no resolution had been found.
> Proposal:       It is proposed that SignalType CN is removed from the
> text.
>
> v13 Status:     OPEN. No text changed.
>
        [[TomT]]
        Done.

> Section:        12.1.4
> Category:       Technical, Open Issue
> Issue:          The draft text specifies that "Signals that would be
> played with
> SignalType BR should have a default duration"
> Again, it should be noted, that the more general topic of signal types and
> the details of their operation has been the subject of much debate on the
> IETF Megaco mailing list since the white contribution was developed, and
> that at time of writing, no resolution had been found.
> Proposal:       It is proposed that similar text is added as for signals
> of
> SignalType TO.
>
> v13 Status:     OPEN. No text changed.
        [[TomT]]
        See initial comments to this message.

> Support NetAid!  http://www.netaid.org
> --------------------------------------------------
> Chip Sharp                 Consulting Engineering
> Cisco Systems              Telco Bio-region
> Reality - Love it or Leave it.
> --------------------------------------------------

---

From: Chip Sharp <[email-masked]>
Date: Fri, 4 Feb 2000 00:04:42 -0500

At 08:17 PM 2/2/00 -0500, Tom-PT Taylor wrote:
>Speaking as chair, I suppose I have to say that the null hypothesis is 
>that we stick with our current text.  We have two other alternatives:
>
>(a) New distinctive definitions for BR, TO, OO, with the understanding 
>that the definition of a given signal indicates its default type, but that 
>type can always be overridden by the type parameter.
>
>  - BR duration is assumed to be known to the MG without explicit MGC 
> input.  BR signals can be stopped by detection of events without the 
> KeepActive parameter or by replacement of the current signal descriptor 
> with one not containing the indicated signal.
I would suggest they cannot be interrupted by events. If not, there's 
little reason for having them as well as TO signals.
>
>
>  - TO duration is given explicitly by the duration parameter.  A default 
> may be provisioned or defined in the package.  TO signals can be stopped 
> by detection of events without the KeepActive parameter or by replacement 
> of the current signal descriptor with one not containing the indicated signal.
>
>  - OO signals remain active until a signal descriptor with explicit 
> turn-off syntax comes into effect (Chip's proposal).
Sounds good.
>again for H.248v2 -- the protocol works as is.
I doubt it. This is such a fundamental property of the protocol that it is 
highly unlikely you would be able it in v2, not least considering the 
backwards compatibility restricion on package extensions. I would suggest 
doing it right the first time around.

Issue update and additions follow below.
>-----Original Message-----  From:  Chip Sharp 
>[SMTP:[email-masked]]  Sent:  Tuesday, January 25, 2000 7:59 
>PM  To:    [email-masked]  Subject:      Cisco SG16: 
>Signals Operation

Section:         7.1.1, second paragraph, last paragraph
Category:     Technical
Issue no.:     14.2
Issue:          The draft text specifies that “Finally, there is an 
optional “notifyCompletion” that allows a MGC to request being notified of 
completion of the signal. The value of thi sparameter is a 
RequestIdentifier, allowing the MGC to correlate the Notify with the 
corresponding signal” and furthermore that “If the MGC requested 
notification of completion for a signal, a Notify command SHALL be sent by 
the MG upon completion of that signal. A Notify triggered by completion of 
a signal SHALL NOT affect the state of the eventbuffer or any active events 
descriptor”. There is already a mechanism in the protocol that supports 
this functionality, namely events. By using the event mechanism instead, 
the duplication of functionality is avoided, and event ordering between 
“events” and completed signals become trivial – currently they are an 
unsolved issue. Furthermore, it is unclear how this behavior interacts with 
the EventBuffer mechanism. For example, if an event has been notified, 
“EventBuffer” is on, and the signal now completes, it seems inconsistent to 
issue another Notify specific to the signal.
Proposal:     It is strongly suggested, that “notifyCompletion” is replaced 
by having the completion of the signal generating an event (e.g. “signal 
complete”) instead (notification of which may or may not have been 
requested). Furthermore, to account for signal failure, there should be a 
“signal failure” event as well.
Status:

>    Section:        7.1.10, fourth paragraph, first 
> bullet.  Category:       Technical, Open Issue  Issue:          The draft 
> text defines on/off signals "the signal lasts until it is  turned off", 
> however this definition is not clear. Specifically, it is not  clear if 
> an on/off signal is turned off by not being included in a  subsequent 
> SignalsDescriptor or if it is turned off by some explicit  action. In the 
> latter case, syntax is missing leading one to believe that  the former 
> definition is intended. The former definition on the other hand  is 
> somewhat problematic and overlaps the definition of time-out 
> signals  with an indefinite duration. Consider for instance a "visual 
> message  waiting indicator" defined as an on/off signal. Unless the 
> signal is  included in all subsequent SignalsDescritpors, the indicator 
> will be turned  off. The on/off signal type would be more useful (and not 
> a duplicate of  timeout) if this was not the case.  Also, it should be 
> noted, that the more general topic of signal types and  the details of 
> their operation has been the subject of much debate on the  IETF Megaco 
> mailing list since the white contribution was developed, and  that at 
> time of writing, no resolution had been found.
>
>clarified in  accordance with the above and the missing syntax added.
>
>

v14: OPEN. No relevant text changed.
>
>
>Section:        7.1.10, fourth paragraph, second 
>bullet  Category:       Technical  Issue:          The draft text defines 
>timeout signals as "the signal lasts until  it is turned off or a specific 
>period of time elapses", however there is no  mechanism specified for 
>informing the MGC when that specific period of time  has elapsed and thus 
>the signal has ended. The MGC may therefore be unable  to determine if a 
>given signal is playing in an MG or not. An example where  this is needed 
>is outpulsing with MF Feature Group D trunks where multiple  digit strings 
>(address and caller id) need to be outpulsed. MGC needs to  know when 
>outpulsing of the first string of digits has occurred before  requesting 
>out-pulsing of the next string.). Another example is a signal  activated 
>through an external event such as user input (by use of an  embedded 
>signals descriptor).
>
>the MGC  upon timeout signal completion is added, e.g. in the form of an 
>event  ("operation complete"). Furthermore, it should be considered to add 
>another  event that would allow the MGC to be informed if generation of 
>the signal  fails for some reason (e.g. "operation failure"). It should be 
>noted, that  this may happen in the middle of the signals defined duration.
>
>[[TomT]]  v14 adds the notifyCompletion parameter for every signal and 
>text on how completions are notified in section 7.2.7.  For failures we 
>have that generic failure event in E.1, but no text on how to apply it or 
>what request ID to use for it.

v14:    DISAGREE (see issue 14.2). A mechanism has been added.

Section:         7.1.17
Category:     Technical
Issue no.:     14.3
Issue:          The draft text specifies that “If a Notify is sent as a 
result of a signal completion, the ObservedEventsDescriptor contains the 
name of the signal that completed and the time at which it completed”. Cf. 
issue 14.2, this behavior is undesirable and should be replaced with an 
event instead thereby eliminating the need for specifying this special case.
Proposal: Assuming the proposed resolution to issue 14.2 is accepted, it is 
proposed that the above sentence is deleted.
Status:

Section:         7.2.8 (Notify), last three paragraphs
Category:     Technical
Issue no.:      14.5
Issue:          The draft text specifies that “…, or as a result of 
completion of a signal for which the MGC requested notification of 
completion”, and “…or the triggering SignalsDescriptor”, as finally “A 
Notify triggered by completion of a signal, contains the corresponding 
signal name in the ObservedEventsDescriptor”. However, as argued in issue 
14.2, this behavior is a special case that is inconsistent with the general 
event handling mechanism, incl. Notifications. If signal completion was not 
designed as a special case (which there is no reason to), this special case 
handling would not be necessary.
Proposal: Assuming the proposed solution to issue 14.2 is accepted, it is 
proposed to remove all of the above text segments.
Status:

>
>
>Section:                12.1.4  Category:       Technical, Open 
>Issue  Issue:          The draft text mentions SignalType CN (Continue), 
>however this  SignalType is not defined in Section 7.1.10 on Signals 
>Descriptor.  Also, it should be noted, that the more general topic of 
>signal types and  the details of their operation has been the subject of 
>much debate on the  IETF Megaco mailing list since the white contribution 
>was developed, and  that at time of writing, no resolution had been 
>found.  Proposal:       It is proposed that SignalType CN is removed from 
>the text.
>
>[[TomT]]  Done.
v14. CLOSED. SignalType CN has been removed.
>    Section:        12.1.4  Category:       Technical, Open 
> Issue  Issue:          The draft text specifies that "Signals that would 
> be played with  SignalType BR should have a default duration"  Again, it 
> should be noted, that the more general topic of signal types and  the 
> details of their operation has been the subject of much debate on 
> the  IETF Megaco mailing list since the white contribution was developed, 
> and  that at time of writing, no resolution had been 
> found.  Proposal:       It is proposed that similar text is added as for 
> signals of  SignalType TO.
>
>v13 Status:     OPEN. No text changed.  [[TomT]]  See initial comments to 
>this message.
v14: OPEN. No text changed.

---

From: Tom-PT Taylor <[email-masked]>
Date: Fri, 4 Feb 2000 06:36:18 -0600

Resend.

> From: Taylor, Tom-PT [CAR:B904:EXCH]
> Sent: Friday, February 04, 2000 2:37 AM
> To:   'Chip Sharp'; [email-masked]
> Subject:      RE: Cisco SG16: Signals Operation
>
> No action on the first one -- we would just go round in circles.  I don't
> think it's as fundamental a point as you suggest -- the status quo works,
> because signal typing is just a convenience.
>
> On the second point I'd like to see a little more discussion.  We're
> talking about "notifyCompletion" for signals.  There are two parts to the
> current mechanism: arming by a signal parameter rather than an event
> descriptor entry, and reporting by special means specified in the protocol
> rather than by means of an ordinary event.  Opinions are divided on both
> parts of the mechanism.  The main concern I have over use of the pure
> event mechanism is on the arming side: asking for completion of a
> sequential signal list is likely to be very awkward.  I also wonder how
> sensible it is to have the potential outcome that the completion of a
> signal stops all signals.
>
> I still think that the "cause" event in E.1.2 can be used to report
> signalling failure, but I still ask myself where the requestID comes from
> for error reports.  The designers of the "cause" event must have something
> to say about that.
>
> From: Chip Sharp [SMTP:[email-masked]]
> Sent: Friday, February 04, 2000 12:05 AM
> To:   Taylor, Tom-PT [CAR:B904:EXCH]; [email-masked]
> Subject:      RE: Cisco SG16: Signals Operation
>
> Issue:          The draft text specifies that "Finally, there is an
> optional "notifyCompletion" that allows a MGC to request being notified of
>
> corresponding signal" and furthermore that "If the MGC requested
> descriptor". There is already a mechanism in the protocol that supports
> "events" and completed signals become trivial - currently they are an
> "EventBuffer" is on, and the signal now completes, it seems inconsistent
> to
> Proposal:     It is strongly suggested, that "notifyCompletion" is
> replaced
> by having the completion of the signal generating an event (e.g. "signal
> complete") instead (notification of which may or may not have been
> "signal failure" event as well.
> Status:
>
>
> Issue:          The draft text specifies that "If a Notify is sent as a
> name of the signal that completed and the time at which it completed". Cf.
>
> Issue:          The draft text specifies that "..., or as a result of
> completion", and "...or the triggering SignalsDescriptor", as finally "A
> signal name in the ObservedEventsDescriptor". However, as argued in issue

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 4 Feb 2000 14:17:13 -0500

Comments below

> From: Chip Sharp [mailto:[email-masked]]
> To: [email-masked]
> Subject: Re: Cisco SG16: Signals Operation
>
>
It's okay with me

> > turn-off syntax comes into effect (Chip's proposal).
What is the syntax?  Would a parameter do, or do we have to actually have a
keyword?  Is there a default?  I propose that we
have keywords. Signals{VMButton{ON}}
this makes:
sigParameter       = sigStream / sigSignalType / sigDuration /
                sigOnOFF / sigOther / NotifyCompletion
(last element is in debate at the moment)
sigOnOff           = OnToken / OffToken

What happens with signal lists?

> "EventBuffer" is on, and the signal now completes, it seems
> inconsistent to
> Proposal:     It is strongly suggested, that
> "notifyCompletion" is replaced
I have argued this precise point, and believe that there should only
be ONE way to get an event armed and triggered.  I agree that it
should be an event.  I specifically proposed that a signal complete
event be defined that has a parameter which is the list of signals
that it applies to, but it occurs to me that a compromise is to
leave the parameter in Signals Descriptor as being a "this is one
of the signals that the signal complete event applies to", and then
the signals complete event has no input parameter, but has an output
parameter that specifies which signal completed.

> v14:    DISAGREE (see issue 14.2). A mechanism has been added.
I'd say that the mechanism proposed, or the V14 mechanism does
address the completion part.  The error part is V2; should it be
an event, or just an error?  How should the error be reported?

> proposed that the above sentence is deleted.
Since I agree that the mechanism should be an event, I agree
with this

> proposed to remove all of the above text segments.
Ditto

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 4 Feb 2000 15:30:06 -0500

Nice summary.

1. Duration of BR is defined in the package (which could state
"provisioned").  All signals have default signal type and duration
parameters, so that is the mechanism I would propose to use to override it.
If people object to replacement SIgnals terminating BR signals, we are back
to the old queuing problem, so PLEASE don't ask for it.

2. Agreed on TO

3. Signal lists with on/off are defined to be of type on/off.  So the
question is, how do you turn off the signal list?  If the list can have On
or Off keywords, then it is "consistent", but what happens when you say that
the OO signal in the list is OFF when the list itself is On?

4. I'd advocate leaving KeepActive default to false always

5. Signal failures should be treated like any asynchronous failure, and
reported with the general failure event.

Brian

-----Original Message-----
From: Tom-PT Taylor [mailto:[email-masked]]
Sent: Friday, February 04, 2000 3:05 PM
To: [email-masked]
Subject: Re: Cisco SG16: Signals Operation

Digging through the accumulated mass of indented text and comments, I think
I see two parties agreeing on the following points.  Unfortunately
experience tells me that as soon as we introduce a third party the
agreements will vanish, but I'll record them here just in case a miracle
happens.

1) BR signals have the following characteristics: duration is assumed to be
known to the MG without explicit MGC input.  Brian wants the ability to
override duration, and I have no quarrel with that -- the only question is
the exact mechanism.  The second characteristic is that a BR signal is not
terminated by the detection of an event.  (But BR signals are still
terminated by replacement of the Signals descriptor??  Any objections here?)

2) TO signals seem to be fairly well understood.

3) OO signals have the following characteristics: they remain on until
interrupted by detection of an event, or receipt of a Signals descriptor
with explicit Off syntax.  Brian's keyword syntax is probably acceptable.
Brian has a query about signal lists.  Is there something about this
proposal that doesn't work given our current signal list text?

4) Brian's proposals for completion events probably work for Chip and they
work for me.  To summarize: the current notifyCompletion parameter remains
but its significance changes: it is a selector (Boolean, default FALSE) and
does not actually arm reporting.  There is a signal completion event which
reports on the completion of any signal so flagged, with the identity of the
signal as a reporting parameter.  QUESTION: should KeepActive default to
TRUE for this event?  In any case, the signal completion event is invoked in
the usual way, through an events descriptor.

Open issue: signal failures.  The need for reports of such failures is real
-- they do happen from time to time.  They happen autonomously, which means
we either have to have an error method (ServiceChange ?) or an event to
report them.  The key issue is whether you would need to know about ANY
failure or only those of selected signals.

        -----Original Message-----
From:   Rosen, Brian [SMTP:[email-masked]]
Sent:   Friday, February 04, 2000 2:17 PM
To:     [email-masked]
Subject:        Re: Cisco SG16: Signals Operation

        Comments below

> From: Chip Sharp [ mailto:[email-masked] <mailto:[email-masked]> ]
It's okay with me

Ditto

> Support NetAid!  http://www.netaid.org <http://www.netaid.org>

---

From: Bob Lukas <[email-masked]>
Date: Fri, 4 Feb 2000 13:42:54 -0800

This would mean that indicators, such as visual message waiting, or other
LEDs (e.g. line key indicator, on-hold indicator, etc), should not be OO
signals, because they would get turned off by the next event. Perhaps a
package should implement these as properties that are set to the desired
state value, rather than signals?

This is different than the proposals in draft-ietf-megaco-ipphone-01.txt and
draft-ietf-megaco-basicpkg-00.txt. There it seems that indicators are trying
to use the signal syntax to set property values.

---

From: Tom-PT Taylor <[email-masked]>
Date: Fri, 4 Feb 2000 16:52:04 -0500

Your point about properties has been made before.  The IPPhone crowd haven't
been too happy with it, but it does make sense.  Let's see how this thread
spins out.

> From: Bob Lukas [SMTP:[email-masked]]
> Sent: Friday, February 04, 2000 4:43 PM
> This is different than the proposals in draft-ietf-megaco-ipphone-01.txt
> and draft-ietf-megaco-basicpkg-00.txt. There it seems that indicators are
> trying to use the signal syntax to set property values.
>
>       3) OO signals have the following characteristics: they remain on
> until interrupted by detection of an event, or receipt of a Signals
> descriptor with explicit Off syntax.  Brian's keyword syntax is probably
> acceptable.  Brian has a query about signal lists.  Is there something
> about this proposal that doesn't work given our current signal list text?
>
>
>

---

From: Chip Sharp <[email-masked]>
Date: Thu, 10 Feb 2000 02:53:58 -0500

I believe the first description of BR, OO and TO is a good summary and is
how it should stay.
The only practical problem is how to interrupt a DTMF digit being
transmitted if the MG receives the signal descriptor.  It will probably
have ended before the MG can send the command to the DSP to stop.  There
will have to be some leeway on this one.
This will be our position here in SG16 in Geneva.

Signal list handling is something I'll have to defer to others.

Chip

At 05:28 PM 2/4/00 -0600, Tom-PT Taylor wrote:

>OK, let's sum up, not that I'm confident that this will fly yet.  I'd like
>to see the reaction of a couple of other vocal parties -- say Michael
>Brown and Christian Groves.
>
>We have three signal types with distinct roles:
>   BR has a timer but is not interrupted by events.  It is interrupted by
> signal descriptor replacement.
>   TO is the most interruptible: timer, events, signal descriptors.
>   OO is the most persistent: interrupted by signal descriptors with
> explicit "Off" syntax only.
>I assume we allow over-riding of default signal type in any given instance
>of playout.
>
>The list is an interesting problem.  I think I have an answer to turning
>an OO list off, but now we also have to define behaviour in response to
>events.  We might consider the following rules:
>
>  -- the type of the list is set explicitly -- every signal on the list
> with the possible exception of the last one must be either BR or TO, in
> order to have an assigned duration
>
>  -- if the last event is OO, the list must be OO and vice versa
>  -- the type of the list, not the type of the signals making it up,
> determines the conditions under which playout of the list ceases
>
>  -- the list times out if it is not OO and all of the signals on it have
> played out, each in turn to its full duration.
>-----Original Message-----  From:   Flemming Andreasen
>[SMTP:[email-masked]]  Sent:   Friday, February 04, 2000 5:38
>PM  To:     [email-masked]  Subject:        Re: Cisco
>SG16: Signals Operation
>
>Maybe, but according to Brian's first "no-op" rule, it must be broken in
>order to get fixed :-)
>
>Regarding dial-tone, I don't see the issue. What you have is three
>different signal types and three different semantics. Each has it's own
>time and place. In the case of dial-tone, TimeOut happens to be the one,
>not Brief.
>
>-- Flemming
>
>"Rosen, Brian" wrote:
>  Let's see:    Events stop signals except:        When KeepActive is
> set        If the signal is BR        If the signal is OONet result -
> events stop signals only when TO and not KeepActive.Maybe we should have
> a "StopSignal", rather than a KeepActiveMaybe it happens so seldom that
> we use an embedded signals to do it.Also note that by saying BR doesn't
> stop for events, you twist the solution tofirst digit stops dialtone to a
> new level.Brian
>-----Original Message----- From: Flemming Andreasen [
><<mailto:[email-masked]>mailto:[email-masked]>]
>Sent: Friday, February 04, 2000 4:55 PM To:
>[email-masked] Subject: Re: Cisco SG16: Signals
>Operation   Hi Tom
>
>OO signals should not be interrupted by an event, only the explicit "Off"
>syntax should have this effect (otherwise we are back to TO signals with
>indefinite duration, and semantically there's good use for something that
>stays active until explicitly told otherwise, e.g. consider message
>waiting indicator)
>
>Regards
>
>         Flemming
>
>Tom-PT Taylor wrote:
>
>
>Digging through the accumulated mass of indented text and comments, I
>think I see two parties agreeing on the following points.  Unfortunately
>1) BR signals have the following characteristics: duration is assumed to
>be known to the MG without explicit MGC input.  Brian wants the ability to
>with explicit Off syntax.  Brian's keyword syntax is probably
>but its significance changes: it is a selector (Boolean, default FALSE)
>and does not actually arm reporting.  There is a signal completion event
>which reports on the completion of any signal so flagged, with the
>identity of the signal as a reporting parameter.  QUESTION: should
>KeepActive default to TRUE for this event?  In any case, the signal
>completion event is invoked in the usual way, through an events descriptor.
>
>Open issue: signal failures.  The need for reports of such failures is
>real -- they do happen from time to time.  They happen autonomously, which
>means we either have to have an error method (ServiceChange ?) or an event
>to report them.  The key issue is whether you would need to know about ANY

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 10 Feb 2000 17:42:18 -0500

FWIW, I've always maintained that signals make noise.  Things that
don't aren't signals, they are properties.  I've flopped around a
bit on power ring.  It makes noise, but it's not in-band.  I think
it's a TO signal.  I think MWI is a property.

The IPPhone guys hate that; they want buttons to be events and
indicators to be signals.  I think it's perfectly reasonable to
have a state change on a property cause an event.  That makes
buttons properties with state, change of state causing an event.
Hook should be the same - it's a property you can read, state
change causes an event.

I always am outnumbered in this.

Brian

> From: Christian Groves [mailto:[email-masked]]
> Sent: Thursday, February 10, 2000 5:16 PM
> G'Day Flemming,
> I see OO events as being more for tones or situations where the MG is
> continuously supplying a current (sorry for bringing HW into things).
> ie. ring tone continuously supplies a ringing current. For a VisualMWI
> indicator what you are doing is instantaneous. ie. a function call to
> move pixels on a screen. You don't keep calling the function
> to keep it
> on the display. You call another function to remove the visual
> indication. I think this is more suited to BR.
>
> As you say this is a matter of taste. I believe this is a clean
> distinction.
>
> Given the following matrix I believe you need to be able to for signal
> behaviour. To me these are valid operations.
>                         Interupt     Non-interrupt
> Play once                  1               2
> Play for a time            3               4
> Play until turned off      5               6
>
> If you tie replacement behaviour to signal type you only get
> 3 options.
> I believe if  BR, TO, OO the number of time you play a signal
> and add a
> KEEPACTIVE parameter then you can acheive all this.
> KEEPACTIVE is needed
> anyway to get over the signal double playing problem. Having this type
> of semantics also allows us to add other keywords in CS2,3 etc for
> things like queue, replace........
>
> Are we coming any closer to understanding each other?
>
> Cheers, Christian
>
> Flemming Andreasen wrote:
> >
> > That could be another way of doing it. The drawbacks I see
> is that whenever you want to have this
> > behavior, you now have to define two signals; one for "on",
> and one for "off". Defining the
> > on/off type with one indication for "on" and another for
> "off" solves the problem once and for
> > all. Conceptually, I think it's cleaner, but that is
> inarguably a matter of taste. Do you see any
> > problems with it ?
> >
> > -- Flemming
> >
> > Christian Groves wrote:
> >
> > > G'Day Flemming,
> > >
> > > Why can't you define vmwi-on and wmwi-off property? This
> solves your
> > > problem. These could be both signal type 'brief' (ie.
> once). vmwi-on
> > > turns on your indicator. It stays on no matter what you
> do. You then
> > > issue vmwi-off it turns the indicator off.
> > >
> > > I think this solves your problem???
> > >
> > > Cheers, Christian
> > >
> > > Flemming Andreasen wrote:
> > > >
> > > > Christian Groves wrote:
> > > >
> > > > > To me it makes no sense to draw distinction between
> the types of signals
> > > > > and replacement behaviour.
> > > > >
> > > > > With the following rules, what behaviour can't you handle?
> > > > >
> > > > > o You can explicitely define the replacement
> behaviour using the
> > > > >   KEEPACTIVE flag. ie. If on, Signals are not stopped
> by events
> > > >
> > > > The problem here is, that KeepActive is an event
> parameter, not a signal parameter. Thus,
> > > > let's say I send down an EventsDescriptor looking for
> off-hook, and a SignalsDescriptor
> > > > applying ringing (TO), and vmwi (OO). I don't want my
> vmwi to be stopped by off-hook, but I
> > > > do want ringing to be stopped. How do I do that with
> the KeepActive flag ?
> > > >
> > > > >
> > > > > o Signals can be of a transition type "on->off" or
> something with
> > > > >   duration "plays for x seconds". This does not have
> to be part of the
> > > > >   protocol. Its a characteristic of the tone/message
> to be played.
> > > >
> > > > It sounds like we are in agreement, so I might be
> misunderstanding. The protocol defines
> > > > certain basic characteristics of different types of
> signals. Specifically those types are
> > > > BR, TO, and OO.
> > > >
> > > > >
> > > > > o Using BR,TO,OO controls the number of times that it
> is "played"
> > > >
> > > > That doesn't achieve all of what we want.
> > > >
> > > > >
> > > > >
> > > > > Cheers, Christian
> > > > >
> > > >
> > > > -- Flemming
> > > >
> > > > << stuff deleted >>
> >
> > --
> > ---------------------------------------
> > Flemming Andreasen
> > Cisco Systems
> > ---------------------------------------
>