Subject: Re: Washington Issue 5 - Signals

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 22 Nov 1999 18:00:34 -0500

1) Meaning of BRief.  I don't like "arbitrary" upper limit duration.  Its,
well, arbitrary, and may not suite a lot of applications no matter how we
choose the value.  Announcements are an example, where 1/2 sec is WAY too
short.  User interface with tone feedback resolution of 1/2 sec would be WAY
too long.  I would prefer to think of this as "Play Once", or as a Signal
with a determined duration, defined elsewhere.  Its also not enforceable by
the protocol, so meaningless other than as a guideline.  This signal types
should also be stoppable (see next).  I don't believe we need both BRief and
Play Once -- don't see any real need or non-arbitrary difference.  I think
we're being confused by the terminology here, and making our life more
complicated as a result.

If you don't allow queuing, then there is no difference between BR and ONCE.
Having an arbitrary limit gives you guidance for how to design MGCs.  Use TO
or ONCE (if we support ONCE) if you are over the limit, BR if your signal is
under the limit.  TO or ONCE needs a completion event to guarantee
sequential signals, BR doesn't.  The longer the signal, the less you care
about the extra message because you can't have as many of them.  BR with
queuing is an optimization, a commonly occurring optimization.

2) Stopping a BR.  I see no reason NOT to be able to stop a BRief Signal.
Actually I think its easier to allow them to be stopped, since this does not
make a special case.  Just like any other, BR can be stopped by running off
end of its defined duration, ii) timeout parameter given in command, iii)
explicit stop command (package defined where necessary), iv) implicit stop
due to over-riding Signal or Event.  Am I missing something here?  (Other
than "that's how it works in MGCP" -- not a valid argument in my books.)

It doesn't matter if you stop a BR signal if it is BRief.  You can, but you
don't have to.  Making it not stopped by a new signal descriptor is all that
you really need.

3) Completion events.  These are definitely required.  Should be package
defined, since completion may mean different things in different cases.
Completion Events could be generated by end of a Play Once, or timeout of a
TimeOut Signal.

Disagree.  99% of the time, it means the same thing, Play Once finished, or
TimeOut happened.  You can always define one in a package, but you shouldn't
have to.

4) Signal over-riding.  I continue to think we need some explicit (rather
than implicit) control of exactly what gets overridden by what.  I see two
reasons: 1)  there may be timing windows where it is unclear to the MGC if a
signal has completed or not, so re-sending a signal you wish to complete may
actually result in its being played a second time instead (Christian's
scenario).  2) there will be a LOT of redundancy for some applications, most
notably user interface, to simply leave on things that have been previously
turned on.  (Why say the same thing twice?  Why say the same thing twice?)
I would like to follow up on Christian and Steve's suggestion of using a
SDid for this.  It seems to be pretty darn close.  Actually, I must admit
I'm a little confused on where we stand on this one.

Too much mechanism for too little gain, I think.  Also a pretty big change
late in the game.  With the current proposal, you always avoid timing
windows by using the completion event.  You don't use the replacement SD
rules to control TO or ONCE (although we shouldn't prohibit it), because the
timing problems are too tough to deal with.  So don't.  Get the event, and
then send something new.  Replacement for On Off is the only thing that
makes any real sense.

How about we get rid of the replacement rule in favor of an explicit off?
How about SignalType=ON or SignalType=OFF.

We could also get rid of ONCE by simply saying if the TO time was not
mentioned, you got ONCE behavior (i.e. default TO was one cycle).  Then we
are back to BR, TO and OO.  BR queues, TO has a completion event and OO is
explicitly stopped.

I think the signal list thing still works.

More to come, I'm sure,
Peter Blatherwick

        -----Original Message-----
From:   Rosen, Brian [SMTP:[email-masked]]
Sent:   19 Nov, 1999 09:26
To:     [email-masked]
Subject:        Re: Washington Issue 5 - Signals

        Edited a bit for BRevity!!

        > > > > If you use BR for really short signals, and TO when you have

> > > > a longer one, you meet both goals.
> > >
> > > [CHG] The definition of the length of brief is purely
> subjective. It
> > > depends on the actual signal itself, processing times in the
> > > MGC and MG,
> > > transport delays. How do we decide what it is?
> > [BR] Actually, I propose that it be made arbitrary - if you
> > are below the arbitrary limit, use BR.  If you are above it,
> > or want it to be interruptible, use TO (or ONCE).
>
> [CHG] Arbitrary??? How do we make sure the MG and MGC agree. Then I
> guess this is another root property of the MG giving a maximum BRIEF
> period? But doesn't the value have to relate to deciding
> factors in both
> the MG and MGC.
[BR] I mean arbitrary.  The protocol defines it, say 1/2 second.
Measured from application of signal at the MG.

        > >
> > > >
> > > > If you are stuck on Brief means one cycle, I'd be okay with
> > > > having a fourth type - ONCE, which was play one cycle,
> > > > which was interruptible, and otherwise followed the normal
> > > > rules.  That is equivalent to TO with the timer equal to one
> > > > cycle.
> > >
> > > [CHG] I'm happy to rename 'brief' to 'once' if that helps
> > > understanding.
> > > I don't think we should have a special signal that can't be
> > > interrupted.
> > [BR] It's not so much that it's non-interruptible, it's one
> > message without concern for stepping on it.
>
> [CHG]
> I've missed something here. Isn't the case that's a message
> WITH concern
> for stepping on it? ie. you can't stop it. Stepping on a previous
> signal???
[BR] Boy, we are confused.
If it's really short, there is no concern about stopping it -
just let it finish.  If it's not short, then there is concern
about stopping it.

        That's my point.  If it's short, don't worry about interrupting it,
but you
have to worry about sequencing (asynchronous decision to follow one signal
with another).
BR = short, no need to stop it, let the MG do the right thing
for sequential

        ONCE = not short, must interrupt it, use completion event
to control sequential signal play (or list of signals).

        I'm not actually adamant that a BR is not interruptable if
an event not marked KeepActive occurs.  I think it's a "don't
care" situation.  It's so short that the actual occurance of
the event could have come before, during or after the signal,
and the response of the MG could be the same without the user
caring or the MG (or MGC) becoming confused.

        > > That is the most common case that matters to this discussion
> > (the most common case is really that every signal is completely
> > disjoint from every other one).  You send a BR signal.  Some
> > time later, you want to send another one - how do you know if
> > you can do that?  Either you had to ask for a completion event,
> > or you have to do some timing things that are messy.
>
> [CHG]
> Both your and my model have this issue. You introduced the signal
> completion event, which I thought was very valid. Your model
> introduced
> a special meaning to brief.
Sure - BR handles it with the rule and one message, ONCE, TO and
OO handle it with the event and two messages.

        > >
> > With your proposal, if you wanted to send a BR which played
> > after the previous BR, other than use a completion event (which
> > you didn't know you needed when you sent the first one, so
> > you would have to always use it), how do you do it?
>
> [CHG]
>
> In your model if you wanted to do this you'd send a new SD containing
> the current signal S1(BR) and the new signal S2(BR). ie.
> SD=S1(BR),S2(BR). You run the risk here of playing S1 twice
> because you
> don't know when S1(BR) will end. You solve this by making a
> rule to say
> that you can never interrupt 'brief' so you don't have to
> repeat S1. You
> then don't have the doubleplay problem. I don't like the fact in
> principle there's a signal you can never expicitly stop and
> that 'brief'
> is an arbitary period.
>
> So then we need to have queueing in the media gateway because you may
> send S2 when S1 is still playing. It doesn't say so explicitely in the
> protocol but you still need it in the GW.
>
> I think we are both wanting to solve the same problem but have a
> different solution in mind.
>
> OK as queuing is supported in the MG. Then I will extend my model with
> an explicit flag called 'next' for the signal descriptor.
> Adding a flag
> doesn't mean will now have to do queuing you have to support
> it anyway.
>
> In my model if you have :  SD(x)=S1(BR)        brief is arbitary
> If you do                  SD(x)=(S2(BR)),next
>                                then S2 will play after S1 no
>                                signal complete event is needed
> If you do
> SD(x)=(S1(BR),S2(BR)),next
>
> then S1 will play again then S2
> If you do                  SD(x)=S2(BR)
>                                then S1 will stop playing and S2
>                                will start.
>
> The 'next' flag is equally applicable to and consistent for:
>     BR         play once
>     Timeout    repeat for certain amount of time.
>     ON/OFF     repeat until off
Works, but mine is a whole lot less change to the existing words,
protocol, ABNF and ASN.1, with not a lot of functionality
difference.

        > >
> > > >
> > > > > Another problem is the rules for continue, replace and stop.
> > > > > What happens if you have a brief signal (S1) and want to
> > > add another
> > > > > signal (S2) to the signal descriptor(SD). S1 has just
> > > > > finished when you
> > > > > send an ADD or MODIFY with SD=S1,S2 (you haven't received the
> > > > > SignalComplete event yet) because you want S1 to continue
> > > > > playing. What
> > > > > will happen is that you order S1 again and S2. You've
> > > played S1 twice
> > > > > which is an error.
> > >
> > > > With BR as defined, you simply send S2.
> > > >
> > > > The case you want is where you have a TO, you want to complete
> > > > it and play another one when it finishes.  If you didn't
> > > > ask for the completion event, you are hosed, because if you
> > > > mention the original TO in the replacement SD, if it
> > > arrives after the MG
> > > > has completed playing it, it will play
> > > > twice, if it has not, it will keep going.
> > > >
> > > > Moral - use the completion event, or just delay the TO value
> > > > before sending a new signal.
> > >
> > > [CHG] Yes completion events are valid. The scenario I
> > > presented is when
> > > you play a second signal (s2) at the same time, no queuing is
> > > involved.
> > > There's no dependance on S1 but according to your
> proposal you have to
> > > specify S1 if you want to keep it playing. A completion
> event wouldn't
> > > be helpful as it pertains to S1 which has no dependencies on S2.
> > [BR] We are talking about BR.  I don't think, if BR is really
> > brief, that there is ever a case where you want one BR to play
> > simultaneously with another BR unless it occurred at the time
> > you decided to play the first one.  That is one reason I want
> > BR to be short - so I never have the case where I start
> playing it, and then
> > decide I have to play another one on top of it.
>
> [CHG]
> I not sure. Its a big IF. ie. A breif Signal S1 playing audio may be
> 500ms long, A brief Signal S2 moving a cursor on a screen is
> instanteous. Should you queue behind the S1 signal.
[BR] YES!!!!!  The occurance of the situation that causes S2
is arbitrarily close to the situation that causes S1, it doesn't matter when

S2 happens if BR is 1/2 sec.

        > >
> > > > Presumably if I modify SD=1, if the MG has finished BR1
> > > > it will play BR2 right away, if it hasn't finished it
> will finish
> > > > it and play BR2 after it, right?
> > >
> > > [CHG] Yes. I assume you want to play SD=1{BR2}. A single
> > > SignalDescriptor instance will contain signals that have
> > > dependencies to
> > > each other. SignalDescriptors have no dependencies between them.
> > >
> > > >
> > > > Okay, how do I EVER know when I can send SD=2{BR2}?  Do I have
> > > > to keep modifying SD=1 forever?  If I have to track time,
> > > > your solution doesn't help - I just use time as the mechanism
> > > > to control sequential signals.
> > >
> > > [CHG] OK. You've made a considerable leap in using SD=2{BR2}.
> > >       You can send SD=2(BR2) when ever you like because its not
> > > dependant on SD=1.
> > [BR] Really covered above, if I want to force sequential
> > on really brief things, I would have to use completion events.
> > Which means two message round trips.  My BR avoids the second.
> [CHG]
> I don't understand your reply to this. This is not sequential its
> independent, SD=2 a new signal descriptor. You don't wait for
> completion
> events in this case. BR has nothing to do with it.
[BR] Sounding like a repeated BR :) -
If you want sequential without BR, use completion events
If you want sequential with BR, the special rule fixes it
If you want simultaneous without BR, use a new SD with
multiple signals
If you want simultaneous with BR, don't try, treat as sequential
(assuming here that the situation for S2 actually occurs
after you have the S1 command sent)

        It occurs to me that we have a potentially ambiguous situation
with TO and the replacement rule.  What if you have played S1
as a TO a while ago, no other signals have been sent, and you
want to play S1 again?  SD is set to S1, you send a new
SD with S1, the replacement rule says this should be interpretted as
continue, but it's over.

        If you say, it's over, start again, then what happens if I send
Signals{x/S1{st=TO, dur=1000, x/S2{st=BR}
just before it times out?  just after it times out?

        See -- if the rule is if it's timed out start it again,
if the S2 comes in just after the timeout, it would start S1
again, yet we clearly meant just play S2 if S1 has timed out.

        So the MG has to track this, and may have to do something
ugly like send a null SD and then the one it wants.  Your NEXT
would fix this.

        I'm going to keep thinking!!

        Brian
> > > > Brian

---

From: Christian Groves <[email-masked]>
Date: Tue, 23 Nov 1999 13:06:27 +0100

G'Day all,

Please see my response [CHG]

Cheers, christian
PS: Sorry about the formatting netscape didn't seem to want to do reply
all with inline text.

[PB]
1) Meaning of BRief.  I don't like "arbitrary" upper limit duration.
Its, well, arbitrary, and may not suite a lot of applications no matter
how we choose the value.  Announcements are an example, where 1/2 sec is
WAY too short.  User interface with tone feedback resolution of 1/2 sec
would be WAY too long.  I would prefer to think of this as "Play Once",
or as a Signal with a determined duration, defined elsewhere.  Its also
not enforceable by the protocol, so meaningless other than as a
guideline.  This signal types should also be stoppable (see next).  I
don't believe we need both BRief and Play Once -- don't see any real
need or non-arbitrary difference.  I think we're being confused by the
terminology here, and making our life more complicated as a result.
[BP]
[BR]
If you don't allow queuing, then there is no difference between BR and
ONCE.  Having an arbitrary limit gives you guidance for how to design
MGCs.  Use TO or ONCE (if we support ONCE) if you are over the limit, BR
if your signal is under the limit.  TO or ONCE needs a completion event
to guarantee sequential signals, BR doesn't.  The longer the signal, the
less you care about the extra message because you can't have as many of
them.  BR with queuing is an optimization, a commonly occurring
optimization.
[RB]

[CHG]
We always support queuing of some sort in the MG. I question the
validity of the MGC having to send either brief or timeout depending on
an arbitrary time limit... TO or ONCE do not need extra signals if you
follow my method of a NEXT indicator. ONCE with NEXT is the same as
BRIEF. It would be good to have the same functionality for TO because
the MGC already knows the amount of time it asked the MG to play the
message for.

[BP]
2) Stopping a BR.  I see no reason NOT to be able to stop a BRief
Signal.  Actually I think its easier to allow them to be stopped, since
this does not make a special case.  Just like any other, BR can be
stopped by running off end of its defined duration, ii) timeout
parameter given in command, iii) explicit stop command (package defined
where necessary), iv) implicit stop due to over-riding Signal or Event.
Am I missing something here?  (Other than "that's how it works in MGCP"
-- not a valid argument in my books.)
[PB]
[BR]
It doesn't matter if you stop a BR signal if it is BRief.  You can, but
you don't have to.  Making it not stopped by a new signal descriptor is
all that you really need.
[RB]

[CHG]
I've missed something - hasn't it always been said that BRIEF cannot be
interrupted? Pete wants to be able to explicitely stop it.

[PB]
3) Completion events.  These are definitely required.  Should be package
defined, since completion may mean different things in different cases.
Completion Events could be generated by end of a Play Once, or timeout
of a TimeOut Signal.
[BP]
[BR]
Disagree.  99% of the time, it means the same thing, Play Once finished,
or TimeOut happened.  You can always define one in a package, but you
shouldn't have to.
[RB]

[CHG] So Brian do you propose adding a completion indication to the main
protcol if its not defined in a package?

[PB]
4) Signal over-riding.  I continue to think we need some explicit
(rather than implicit) control of exactly what gets overridden by what.
I see two reasons: 1)  there may be timing windows where it is unclear
to the MGC if a signal has completed or not, so re-sending a signal you
wish to complete may actually result in its being played a second time
instead (Christian's scenario).  2) there will be a LOT of redundancy
for some applications, most notably user interface, to simply leave on
things that have been previously turned on.  (Why say the same thing
twice?  Why say the same thing twice?)  I would like to follow up on
Christian and Steve's suggestion of using a SDid for this.  It seems to
be pretty darn close.  Actually, I must admit I'm a little confused on
where we stand on this one.
[BP]

[BR]
Too much mechanism for too little gain, I think.  Also a pretty big
change late in the game.  With the current proposal, you always avoid
timing windows by using the completion event.  You don't use the
replacement SD rules to control TO or ONCE (although we shouldn't
prohibit it), because the timing problems are too tough to deal with.
So don't.  Get the event, and then send something new.  Replacement for
On Off is the only thing that makes any real sense.

How about we get rid of the replacement rule in favor of an explicit
off?  How about SignalType=ON or SignalType=OFF.

We could also get rid of ONCE by simply saying if the TO time was not
mentioned, you got ONCE behavior (i.e. default TO was one cycle). Then
we are back to BR, TO and OO.  BR queues, TO has a completion event and
OO is explicitly stopped.

[RB]

[CHG]
I think we've fiddled with redefining things enough. We've been
discussing patches since before RedBank and all have some sort of
problem. What has been proposed with SD(x) and NEXT  seems to work for
all cases. You don't need to always need to use the completion event.
You can get BR using ONCE with NEXT. I don't think the ABNF/ASN changes
are an issue. We've made other changes so this is not a precedence.

More to come, I'm sure,
Peter Blatherwick