Subject: Re: Cisco SG16: Signals Operation

From: Tom-PT Taylor <[email-masked]>
Date: Fri, 4 Feb 2000 17:28:13 -0600

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

---

From: Michael Brown <[email-masked]>
Date: Sun, 6 Feb 2000 12:52:38 -0500

Overall, we're still on the right track since we haven't taken the
approach of throwing everything away and starting over, but I do have
problems with some of the proposed changes. My feeling is that they take
us back to the situation we had before the IETF meeting in Washington
where I felt these issues were reasonably well resolved.

The biggest general issue I have is that the definitions for signal type
cross the boundary into dictating implementation detail. Take the case
of  a BR signal. Happily, we have not come back around to trying to
define some time limit for a BR signal (although I think continuing with
the proposal will eventually lead us there again), so for now BR is a
subjective statement. Let's say I want to play a signal of a relatively
short tone (a couple of seconds) with a provisioned (in the MG) length,
but I want it to be interruptable. By these definitions, this would have
to be treated as a TO which means that the MGC would have to specify
duration (or we have the special rule of duration=0 means to play the
signal til the MG stops it) which I don't think should be required.

There are other example of how these definitions require a specific
implementation of common signals, such as dial tone.

Basically, I suppose I continue to feel that the default for all signals
should be interruptable and that  Keepactive be used to override that
behavior.

Unfortunately, I don't have time to respond with my objections more
fully at this moment as I'm leaving shortly for the ITU meeting. When I
arrive in Geneva, I will follow up with my other concerns and examples.

Michael

"Taylor, Tom-PT (P.T.) [EXCHANGE:CAR:B904]" 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.
>
>   BR has a timer but is not interrupted by events.  It is interrupted
> by signal descriptor replacement.
>   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
>
>  -- 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.
>
>      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
>                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:
>
>
>                     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.
>
>                     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
>                     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.
>
>                     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.
>

---

From: Paul Hollis <[email-masked]>
Date: Mon, 7 Feb 2000 11:12:59 +0100

Hi,

I tend to agree with Michael. I think that signals should be treated
uniformly, and not differently depending upon how they were initiated.
Use the Keepactive if you dont want it to be interupted.

Regards Paul.

Michael Brown wrote:

> problems with some of the proposed changes. My feeling is that they
> take us back to the situation we had before the IETF meeting in
> Washington where I felt these issues were reasonably well resolved.
>
> The biggest general issue I have is that the definitions for signal
> type cross the boundary into dictating implementation detail. Take the
> case of  a BR signal. Happily, we have not come back around to trying
> to define some time limit for a BR signal (although I think continuing
> with the proposal will eventually lead us there again), so for now BR
> is a subjective statement. Let's say I want to play a signal of a
> relatively short tone (a couple of seconds) with a provisioned (in the
> MG) length, but I want it to be interruptable. By these definitions,
> this would have to be treated as a TO which means that the MGC would
> have to specify duration (or we have the special rule of duration=0
> means to play the signal til the MG stops it) which I don't think
> should be required.
>
> Basically, I suppose I continue to feel that the default for all
> signals should be interruptable and that  Keepactive be used to
> override that behavior.
>
> fully at this moment as I'm leaving shortly for the ITU meeting. When
> I arrive in Geneva, I will follow up with my other concerns and
> examples.
>
> Michael
>
>
>
>> 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.
>>
>>   BR has a timer but is not interrupted by events.  It is
>> interrupted by signal descriptor replacement.
>>  -- 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
>>
>>      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:
>>           use an embedded signals to do it.Also note that by saying
>>           BR doesn't stop for events, you twist the solution tofirst
>>                From: Flemming Andreasen
>>                [<mailto:[email-masked]>]
>>                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:
>>
>>
>>                     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?)
>>
>>                     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?
>>
>>                     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,
>>                     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.
>>
--

oooooooooooooooooooooooooooooooooooooooooooooo
  Paul Hollis
  Ericsson Eurolab Deutschland GmbH
  Ericsson Allee 1
  D-52134 Herzogenrath
  Germany
  Phone: +49 2407 575 8092
  email: [email-masked]
oooooooooooooooooooooooooooooooooooooooooooooo

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 7 Feb 2000 10:33:53 -0500

Michael Brown wrote:

> type cross the boundary into dictating implementation detail.

Not really. All signal types do is define certain semantics for
different types. As long as you implement those semantics, you may do it
in which ever way you choose, just like the rest of the protocol. The
only thing that should be debated, is whether those three different
semantics make sense. I believe they do, although I would have liked a
slight change in the BR semantics (basically the whole queuing
discussion, but there are other ways to achieve that and it can probably
be deferred to v2)..

> Take the case of  a BR signal. Happily, we have not come back around
> to trying to define some time limit for a BR signal (although I think
> continuing with the proposal will eventually lead us there again), so
> for now BR is a subjective statement. Let's say I want to play a
> signal of a relatively short tone (a couple of seconds) with a
> provisioned (in the MG) length, but I want it to be interruptable. By
> these definitions, this would have to be treated as a TO which means
> that the MGC would have to specify duration (or we have the special
> rule of duration=0 means to play the signal til the MG stops it) which
> I don't think should be required.

Actually, I would think "duration=0" means play until interrupted.
Omitting a duration means use the default (provisioned) value. If the
default is not what you would like, then there seems to be no way around
having to specify the exact duration desired, regardless of what
solution you have. I don't see much of an issue here.

> signals should be interruptable and that  Keepactive be used to

TO+KeepActive comes close to BR, but they are not identical. The main
distinction is that KeepActive is an event parameter, where as signal
type is a property of a signal. Whether that's enough of a difference to
warrant inclusion or not is a matter of taste I guess. Personally, I
think it is, and I certainly don't see it doing any harm.

OO signals on the other hand are an entirely different class of signals
and there really is a need for this kind of semantic behavior, i.e.
something that stays on without being interrupted by events and new
SignalsDescriptor. While you can come close to mimicing this by suitable
use of KeepActive and continued inclusion in every single subsequent
SignalsDescriptors until you want it turned off, I think this is overly
cumbersome and too prone to error. Semantically, again, it's not
identical though since signal type is a "property" of a signal where as
KeepActive is a parameter to an event. Consequently, I feel rather
strongly about keeping OO the way Tom specified it.

Regards

            Flemming

---------------------------------------
Flemming Andreasen
Cisco Systems
---------------------------------------

---

From: Christian Groves <[email-masked]>
Date: Tue, 8 Feb 2000 15:29:53 +0100

G'Day all,

I'd like to confer with Michael. All signals should be able to be
interrupted. I think the behaviour of the signal types should be
uniform. The distinction between: BR, TO, OO should be how many times
the signal is played. ie.
- BR play once what ever length it is.
- TO play and repeat for a certain amount of time. ie.  ringtone -> play
ring pattern multiple times.
- OO play and repeat until turned off.

A previous email sent by Tom gives an outline on what I believe the
replacement rules should be.

Cheers, Christian

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 8 Feb 2000 10:53:03 -0500

Can you explain how you plan on supporting say "visual message waiting
indicator" if OO signals are interrupted ?

-- Flemming

---

From: Michael Brown <[email-masked]>
Date: Tue, 8 Feb 2000 17:19:00 -0500

Yes, actually this was a discussion that was held in Washington. VMWI is what
we were calling an instantaneous OO signal. That is, the MGC sends down the
signal to turn the light on. The CPE is messaged and the light comes on. In
PSTN, the switch does not continuously send the command to keep the light on.
If I send another signal descriptor without VMWI included no message is sent
to the CPE about VMWI and the light stays on. It isn't until the MGC send a
message to turn it off, that the light then goes off. Just by the way, there
really is no reason why VMWI has to be an OO signal ... making it a BR signal
would work just as well.

As an aside, if VMWI is a truly a non interruptable OO signal, how would the
user go offhook?

Another aside is if a user hangs up during a non interruptable BR signal where
the BR signal is not set up to report completion (most common case), what
happens to the onhook event? If not reported, the line would hang in off hook
state until either the MGC determined there was a problem or until the user
went off hook and onhook again.

My opinion is that if we want a particular signal to be truly noninterruptable
(which I would contend that we really don't ever want to do), we would send a
null events descriptor... if we don't want to see events, then don't ask for
them. If we want to see some events, but we want the signal to continue, then
use Keepactive.

Michael

PS. I realize that I have not been contributing to the Keepactive discussion,
but will do so right now.

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 8 Feb 2000 17:58:03 -0500

Hi Michael

Comments below

> really is no reason why VMWI has to be an OO signal ... making it a BR signal

I think we are looking at this signal at two different levels. I look at it as an
abstract higher level indicator that with two states; on and off. It seems you
view it as a lower level signaling mechanism where the entire FSK mechanism (I
presume) is what you expect. Some (older) phones may indeed expect this, however
some newer (IP phones) may not. I would prefer a higher level abstraction, but
neither is right or wrong. However, if you do want something like what I'm looking
for, I don't think a BR signal would be appropriate.

> As an aside, if VMWI is a truly a non interruptable OO signal, how would the

I see your point, but I think the question arises because of the different
abstraction levels we each have in mind here. In my case, if I had an analog phone
connected where I need the on-hook FSK transmission, then I would expect my MG to
simply shield those details from me. Thus, if the user goes off-hook during FSK
signaling or if he was already off-hook, I would have the MG take care of that,
and simply turn on the indicator when he went on-hook again.

> went off hook and onhook again.

I'm not sure I follow here. Events happen regardless of signal semantics. What we
are looking at is whether a given event affects a given signal or not.

> them. If we want to see some events, but we want the signal to continue, then

Again, I think that for the OO part of this discussion it's because we had
different levels of abstraction in mind. I still firmly believe that OO signals
should not be interrupted in as much as all they really do is (conceptually) set a
state to either "on" or "off". Interrupting them would imply setting the state to
"off" to me, and I definitely don't want that. BR signals are a whole other story.
I think there are arguments for not letting them be interrupted as well, but
that's a discussion with a lot of implications, which I'm fine with deferring
until v2.

Regards

            Flemming

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 8 Feb 2000 18:10:08 -0500

I should probably clarify the following:

When referring to BR signals below and saying that I'm fine with deferring discussion
about interrupting them or not until v2, I was referring to interrupting them by
SignalsDescriptor only. I still believe they should not be interrupted by events.

-- Flemming

---

From: Chip Sharp <[email-masked]>
Date: Wed, 9 Feb 2000 02:53:54 -0500

I'd like to make sure everyone agrees what the word "interrupted" means.

It is my view that a signal being interrupted means that the signal stops.
It has nothing to do with whether or not an event is reported.  For
example, if the MGC sends a command to an MG to turn on VMWI (On/Off) and
the MG has an Events Descriptor requesting notification of offhook, then if
the user goes off-hook, the off-hook event is notified to the MGC and the
VMWI signal stays on.  If the MGC wants to turn it off, it sends an
explicit command.

Chip

At 06:10 PM 2/8/00 -0500, Flemming Andreasen wrote:
> Take the
> [SMTP:[email-masked]]

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

---

From: Christian Groves <[email-masked]>
Date: Wed, 9 Feb 2000 19:08:10 +0100

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
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.
o Using BR,TO,OO controls the number of times that it is "played"

Cheers, Christian

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 9 Feb 2000 13:35:41 -0500

>   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 ?

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

-- Flemming

<< stuff deleted >>

---

From: Christian Groves <[email-masked]>
Date: Thu, 10 Feb 2000 19:23:18 +0100

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

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 10 Feb 2000 15:19:56 -0500

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

---

From: Christian Groves <[email-masked]>
Date: Thu, 10 Feb 2000 23:15:47 +0100

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

---

From: Flemming Andreasen <[email-masked]>
Date: Fri, 11 Feb 2000 09:06:17 -0500

> continuously supplying a current (sorry for bringing HW into things).

No problem :-)

> As you say this is a matter of taste. I believe this is a clean

At first, that seemed OK to me, under the assumption that semantically your two BR signals would be
equivalent to my one OO. Looking a little closer at it, I'm not sure they are after all (see below)..

> Play until turned off      5               6

Based on your comment below, I take it the interrupt part means whether the signal is interrupted by a
SignalsDescriptor. I think that still leaves the "interrupted by event" part open. Let's say I define a
vmvi_on and and a vmwi_off signal (of type BR, i.e.play once) which effectively sends out the FSK
sequence needed to turn the light on or off. Now, as was noted by somebody earlier, you only send this
sequence if the phone is on-hook. So when I apply this signal, it's possible that it either succeeds or
fails because of hook-state. Somehow, I need to know what the outcome was, if I use the two BR signals.
If I instead took a higher level view where I effectively tell the MG that "I just want this light
turned on" (or off), and let the underlying implementation of that signal do what is has to do to
achieve that (i.e. transmit the FSK sequence or wait/try again when the phone goes on-hook), I don't
have that problem. This does seem simpler to me.

As far as "Play for a time" and "Play until turned off" is concerned, I agree that distinction makes
sense. The way I would propose solving that, is by a TO signal in both cases. The former states a
specific period of time, e.g. 30 seconds, while the latter specifies "indefinitely".

I guess what I'm advocating, is actually adding another row to your matrix:
                            Interrupt        Non-interrupt
Set Indicator             7                      8

where the indicator can be either "on" or "off". Item 7 means that you supply the signal in a new
SignalsDescritpor with the opposite of its current value, i.e. if it was "on" you set to "off", and
vice versa. Item 8 would be supplying a new SignalsDescriptor where the signal is either omitted or is
set to its current value.

> Are we coming any closer to understanding each other?

I'm not sure we are there yet, but I think we are getting closer.

-- Flemming

---

From: Christian Groves <[email-masked]>
Date: Fri, 11 Feb 2000 19:05:04 +0100

G'Day Flemming,

Please see my comments below [CHG].

Cheers,Christian

Flemming Andreasen wrote:
> fails because of hook-state.
[CHG] I think this is the wrong assumption. I hope you program your
application to only send a signal when the phone is off-hook. Sending a
signal when off hook is an application error. These types of things are
function interactions and not hardware dependencies.

> Somehow, I need to know what the outcome was, if I use the two BR signals.
[CHG] I don't see why????

> have that problem. This does seem simpler to me.
[CHG] This is a lot more complicated for the MG. Wait/try again implies
state. A certain period of time. This is really putting application
logic in the MG. I thought this would be managed by the MGC being the
server. The wait/try again states sound like some sort of scripting
should be involved. I'm not advocating scripting now.

> specific period of time, e.g. 30 seconds, while the latter specifies "indefinitely".
[CHG] OK

> set to its current value.
[CHG] OK I think we can handle this with the existing matrix.
      7. You can do this with BR with two values (on/off).
         You have one signalID also.
      8. I think you can also do this with BR with two values.
         If omitted it will have no affect. Light stays on or off.
         If the same is included the light will stay the same.

So hopefully we're really close now.

Cheers, Christian
..SNIP..

---

From: Flemming Andreasen <[email-masked]>
Date: Fri, 11 Feb 2000 13:39:07 -0500

> function interactions and not hardware dependencies.

The existence of non-zero propagation delay and glare in general means that you cannot have any such
guarantees.

> [CHG] I don't see why????

Because it might fail, e.g. if the phone was off-hook (either because the Notify crossed paths with this
signal or because of glare).

> should be involved. I'm not advocating scripting now.

Well the MG is not stateless in the first place - it's call stateless. There's tons of logic needed to
implement the protocol in the first place and all the various signals (irrespective of type) imply some kind
of logic which is not application specific. Neither are the types for that matter (regardless of which
definition we use).

>          You have one signalID also.

Good point about the on/off parameter - I'll buy that (of course I would argue that's what OO gives you is a
formalized way of specifying this - probably not a big deal). That leaves us with just one signal, however
you still need to find out if it failed.

>          If the same is included the light will stay the same.

I think so to, but the potential failure is still problematic (in the absence of a completion report, we
would have to include the signal with "keepactive" in subsequent descriptors as well actually)

> So hopefully we're really close now.

We are close, but not quite there. The completion/failure seems to be sticking issue. I can't see how you can
get by without it.

-- Flemming