Subject: Re: Washington Issue 5 - Signals

From: Brian Rosen <[email-masked]>
Date: Thu, 18 Nov 1999 10:02:16 -0500

My comments with [BR]

> -----Original Message-----
> From: Christian Groves [mailto:[email-masked]]
> Sent: Thursday, November 18, 1999 6:39 AM
> To: Brian Rosen
> Cc: ietf_megaco
> Subject: Re: Washington Issue 5 - Signals
>
>
> G'Day Brian,
>
> Please see my comments marked [CHG]
>
> Cheers, Christian
>
> Brian Rosen wrote:
> >
> > > I definitely think that Brief signals should be able to
> be stopped by
> > > sending another signal. Having only an event is not
> sufficient. Ie.
> > > announcements: you should be able to interrupt one. There
> should be no
> > > special rule for brief signals.
> > The problem arises only if you take Brief signals as any
> > length you want them to be.  Announcements make terrible
> Brief Signals
> > because they aren't brief.  They should be TO,
> > with or without the completion event.  I actually argue
> there should be at
> > least a guideline.  Brief means less than 1/2 second, or
> maybe less!!
> >
> > You are stuck between two goals:
> >         Allowing a Brief signal to not require complex
> >                 handling by the MGC - it sends it, and then
> >                 it need not take any special precautions to
> >                 make sure it plays out, an in particular, only
> >                 one message to do it
> >         Allowing a variety of responses to longer messages,
> >                 ones that actually do need to be interrupted.
> >                 For these, you are willing to have multiple
> >                 messages and/or completion events.
> > 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).

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

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.

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?

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

> >
> > > I would suggest coming back to a higher level for the
> > > replacement rules.
> > > ie. the signal descriptor. I think having multiple descriptor
> > > each with
> > > an ID would solve this.
> > >
> > > ie.
> > > Each group of related signals would be under a single signal
> > > descriptor
> > > ID.
> > > SD(x)=S1,s2,s3     would play s1 then s2 then s3
> >
> > > Each group of unrelated signals would be under different signals
> > > descriptor ID.
> > > SD(y)=s4
> > > SD(z)=s5  would play s4 and s5 at the same timout.
> > >
> > > To stop signal/s the appropriate SD(ID) would be given.
> > >
> > > Type of signal rule is the same as your list proposal.
> ie. ON in the
> > > middle of SD doesn't make sense. No special rules are
> needed depending
> > > on type of signal. The repeating of signals isn't a problem.
>
> > Interesting, but not enough methinks.  If I send SD=1{BR1} and
> > then want to have BR2 play, I would send SD=1{BR1,BR2}, right?
>
> [CHG] Depends on what you want:
>          o BR1 and then BR2 at the same time then Yes
>          o BR1 finishes then BR2 starts then No.
>            I've mentioned nothing in my proposal about queueing.
>            I didn't think people wanted to support it.
>            You would wait for a signalcomplete event. Before sending
>            the next. Alternatively the embedded event descriptor.
[BR] This means you always need completion events, IMO.
I think that is a bad idea.

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

> > Brian

---

From: Christian Groves <[email-masked]>
Date: Fri, 19 Nov 1999 12:59:44 +0100

G'Day Brian,

Please see [CHG]

Cheers, Christian

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

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

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

> 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

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

> I think that is a bad idea.
[CHG]
See above comment on NEXT.

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