Subject: [Megaco] Question on Annex G, signal type On/Off

From: Dan Elbert <[email-masked]>
Date: Thu, 07 Mar 2002 12:40:50 +0200

Hi

In Annex G (user interface packages) the type of the signals in the packages
is not defined.
By looking at what the signals want to do, these seem to be "on/off"
signals, but I'm not clear what the meaning of "on/off" is in a signal like
SetIndicator in the Indicator package, where the signal has a state which
can take many values (on,off,blink,...).
Perhaps it means "off" is return to default state ?
Another possibility is to consider this signals as "brief", in this case we
apply them to set them on and then we apply them again to change the state.
This works but seems like "cheating" in the meaning of "brief".
The type will affect the behaviour when an empty SignalDescriptor is used,
on/off signals should be turned off but brief signals not (because they are
assume to play only a short time).
Your thoughts ?

Thanks
Dan Elbert
RADVISION

_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

---

From: "Tom-PT Taylor"<[email-masked]>
Date: Mon, 11 Mar 2002 09:26:05 -0500

Partly I'd say it depends on whether the signals concerned are meant to be
terminated by event occurrences.  If not, then the proper classification is
BR.

-----Original Message-----
From: Dan Elbert [mailto:[email-masked]]
Sent: Thursday, March 07, 2002 5:41 AM
To: 'Blatherwick, Peter'; megaco
Subject: [Megaco] Question on Annex G, signal type On/Off

Hi

Thanks
Dan Elbert
RADVISION

---

From: "Tom-PT Taylor"<[email-masked]>
Date: Mon, 11 Mar 2002 09:26:05 -0500

-----Original Message-----
From: Dan Elbert [mailto:[email-masked]]
Sent: Thursday, March 07, 2002 5:41 AM
To: 'Blatherwick, Peter'; megaco
Subject: [Megaco] Question on Annex G, signal type On/Off

Hi

Thanks
Dan Elbert
RADVISION

---

From: Dan Elbert <[email-masked]>
Date: Tue, 12 Mar 2002 08:56:28 +0200

No, I guess they are not terminated when events are detected (is not even
clear what "terminated" means). So BR is appropieted. But I find it
confusing because "brief" is defined as 
 
   *  brief - the signal duration is so short that it will stop on its  own
unless a new signal is applied that causes it to stop;   no timeout value is
needed.<?xml:namespace prefix = o ns =
"urn:schemas-microsoft-com:office:office" />

In  this case we are talking about something that doesn't "stop". It
actually looks more as a property than as a signal. Maybe we need to expand
the definition of brief.

Dan

-----Original Message----- 
From: Dan Elbert [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Thursday, March 07, 2002 5:41 AM 
To: 'Blatherwick, Peter'; megaco 
Subject: [Megaco] Question on Annex G, signal type On/Off 

Hi 

is not defined. 

Thanks 
Dan Elbert 
RADVISION 

_______________________________________________ 
Megaco mailing list 
[email-masked] 
https://www1.ietf.org/mailman/listinfo/megaco
<https://www1.ietf.org/mailman/listinfo/megaco>

---

From: Dan Elbert <[email-masked]>
Date: Tue, 12 Mar 2002 08:56:28 +0200

Dan

-----Original Message----- 

Hi 

is not defined. 

Thanks 
Dan Elbert 
RADVISION

---

From: "Tom-PT Taylor"<[email-masked]>
Date: Tue, 12 Mar 2002 08:18:08 -0500

This is the fuzzy area of signal definition.  There are other examples in
new Annex M.1, such as the signal which specifies an announcement which
overrides another announcement.

-----Original Message-----
From: Dan Elbert [mailto:[email-masked]]
Sent: Tuesday, March 12, 2002 1:56 AM
To: Taylor, Tom-PT [CAR:B800:EXCH]; Dan Elbert; 'Blatherwick, Peter'; megaco
Subject: RE: [Megaco] Question on Annex G, signal type On/Off

needed.

-----Original Message----- 
From: Dan Elbert [mailto:[email-masked]] 
Sent: Thursday, March 07, 2002 5:41 AM 
To: 'Blatherwick, Peter'; megaco 
Subject: [Megaco] Question on Annex G, signal type On/Off 

Hi 

is not defined.

---

From: "Tom-PT Taylor"<[email-masked]>
Date: Tue, 12 Mar 2002 08:18:08 -0500

-----Original Message----- 
From: Dan Elbert [mailto:[email-masked]] 
Sent: Thursday, March 07, 2002 5:41 AM 
To: 'Blatherwick, Peter'; megaco 
Subject: [Megaco] Question on Annex G, signal type On/Off 

Hi 

is not defined.

---

From: "Blatherwick, Peter" <[email-masked]>
Date: Tue, 12 Mar 2002 13:55:26 -0500

Original intent of the signals in Annex G is on/off behaviour wrt state of the user interface element in question. i.e. you turn on an indicator, update a display, whatever, it just stays on.  To turn it off, you would set state to off using the signal again.  Similarly, set state to blinking, it blinks until told some other state in a subsequent signal.  Setting without state parameter passed defaults to off.  
 
I believe this corresponds to on/off behaviour in practice.  Unclear to me if technically they should be classified as "brief" under Megaco -- also unclear it matters.   At one point, I thought we had description of different usage of signals that truly have lasting state and should therefore not be stopped by events.  Darned if I can find it now (admittedly on a very brief scan).    
 
Sorry for the delay ... missed it going by the first time.  
 
-- Peter
 
-----Original Message-----
From: Dan Elbert [mailto:[email-masked]]
Sent: March 12, 2002 01:56
To: 'Tom-PT Taylor'; Dan Elbert; 'Blatherwick, Peter'; megaco
Subject: RE: [Megaco] Question on Annex G, signal type On/Off

No, I guess they are not terminated when events are detected (is not even clear what "terminated" means). So BR is appropieted. But I find it confusing because "brief" is defined as 
 
   *  brief - the signal duration is so short that it will stop on its  own unless a new signal is applied that causes it to stop;   no timeout value is needed.

In  this case we are talking about something that doesn't "stop". It actually looks more as a property than as a signal. Maybe we need to expand the definition of brief.

Dan

-----Original Message-----
From: Tom-PT Taylor [mailto:[email-masked]]
Sent: Monday, March 11, 2002 4:26 PM
To: 'Dan Elbert'; 'Blatherwick, Peter'; megaco
Subject: RE: [Megaco] Question on Annex G, signal type On/Off

Partly I'd say it depends on whether the signals concerned are meant to be terminated by event occurrences.  If not, then the proper classification is BR.

-----Original Message----- 
From: Dan Elbert [ mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Thursday, March 07, 2002 5:41 AM 
To: 'Blatherwick, Peter'; megaco 
Subject: [Megaco] Question on Annex G, signal type On/Off 

Hi 

Thanks 
Dan Elbert 
RADVISION 

_______________________________________________ 
Megaco mailing list 
[email-masked] 
https://www1.ietf.org/mailman/listinfo/megaco <https://www1.ietf.org/mailman/listinfo/megaco>

---

From: "Blatherwick, Peter" <[email-masked]>
Date: Tue, 12 Mar 2002 13:55:26 -0500

-- Peter
 
-----Original Message-----
From: Dan Elbert [mailto:[email-masked]]
Sent: March 12, 2002 01:56
To: 'Tom-PT Taylor'; Dan Elbert; 'Blatherwick, Peter'; megaco
Subject: RE: [Megaco] Question on Annex G, signal type On/Off

Dan

-----Original Message----- 
From: Dan Elbert [ mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Thursday, March 07, 2002 5:41 AM 
To: 'Blatherwick, Peter'; megaco 
Subject: [Megaco] Question on Annex G, signal type On/Off 

Hi 

Thanks 
Dan Elbert 
RADVISION

---

From: "Kevin Boyle"<[email-masked]>
Date: Tue, 12 Mar 2002 14:07:24 -0500

If you don't want a signal stopped due to event processing, set the
KeepActive parm on the signal.  If you don't want a particular event to stop
signals, then set KeepActive on the event. Otherwise, ALL signal types are
halted by event processing.

Kevin

-----Original Message-----
From: Blatherwick, Peter [mailto:[email-masked]]
Sent: Tuesday, March 12, 2002 1:55 PM
To: 'Dan Elbert'; Taylor, Tom-PT [CAR:B800:EXCH]; megaco
Subject: RE: [Megaco] Question on Annex G, signal type On/Off

Original intent of the signals in Annex G is on/off behaviour wrt state of
the user interface element in question. i.e. you turn on an indicator,
update a display, whatever, it just stays on.  To turn it off, you would set
state to off using the signal again.  Similarly, set state to blinking, it
blinks until told some other state in a subsequent signal.  Setting without
state parameter passed defaults to off.  
 
I believe this corresponds to on/off behaviour in practice.  Unclear to me
if technically they should be classified as "brief" under Megaco -- also
unclear it matters.   At one point, I thought we had description of
different usage of signals that truly have lasting state and should
therefore not be stopped by events.  Darned if I can find it now (admittedly
on a very brief scan).    

-- Peter
 
-----Original Message-----
From: Dan Elbert [mailto:[email-masked]]
Sent: March 12, 2002 01:56
To: 'Tom-PT Taylor'; Dan Elbert; 'Blatherwick, Peter'; megaco
Subject: RE: [Megaco] Question on Annex G, signal type On/Off

Dan

-----Original Message----- 

Hi 

is not defined. 

Thanks 
Dan Elbert 
RADVISION

---

From: "Kevin Boyle"<[email-masked]>
Date: Tue, 12 Mar 2002 14:07:24 -0500

Kevin

-----Original Message-----
From: Blatherwick, Peter [mailto:[email-masked]]
Sent: Tuesday, March 12, 2002 1:55 PM
To: 'Dan Elbert'; Taylor, Tom-PT [CAR:B800:EXCH]; megaco
Subject: RE: [Megaco] Question on Annex G, signal type On/Off

 
 
-- Peter
 
-----Original Message-----
From: Dan Elbert [mailto:[email-masked]]
Sent: March 12, 2002 01:56
To: 'Tom-PT Taylor'; Dan Elbert; 'Blatherwick, Peter'; megaco
Subject: RE: [Megaco] Question on Annex G, signal type On/Off

Dan

-----Original Message----- 

Hi 

is not defined. 

Thanks 
Dan Elbert 
RADVISION

---

From: "Tom-PT Taylor"<[email-masked]>
Date: Tue, 12 Mar 2002 14:14:34 -0500

Slight correction here: the KeepActive on signals controls what happens to a
signal when the Signals descriptor is replaced.

-----Original Message-----
From: Boyle, Kevin [NCRTP:3Z30:EXCH] 
Sent: Tuesday, March 12, 2002 2:07 PM
To: Blatherwick, Peter; 'Dan Elbert'; Taylor, Tom-PT [CAR:B800:EXCH];
megaco

Kevin

-----Original Message-----
From: Blatherwick, Peter [mailto:[email-masked]]
Sent: Tuesday, March 12, 2002 1:55 PM
To: 'Dan Elbert'; Taylor, Tom-PT [CAR:B800:EXCH]; megaco
Subject: RE: [Megaco] Question on Annex G, signal type On/Off

 
 
-- Peter
 
-----Original Message-----
From: Dan Elbert [mailto:[email-masked]]
Sent: March 12, 2002 01:56
To: 'Tom-PT Taylor'; Dan Elbert; 'Blatherwick, Peter'; megaco
Subject: RE: [Megaco] Question on Annex G, signal type On/Off

Dan

-----Original Message----- 

Hi 

is not defined. 

Thanks 
Dan Elbert 
RADVISION

---

From: "Tom-PT Taylor"<[email-masked]>
Date: Tue, 12 Mar 2002 14:14:34 -0500

-----Original Message-----
From: Boyle, Kevin [NCRTP:3Z30:EXCH] 
Sent: Tuesday, March 12, 2002 2:07 PM
To: Blatherwick, Peter; 'Dan Elbert'; Taylor, Tom-PT [CAR:B800:EXCH];
megaco

Kevin

-----Original Message-----
From: Blatherwick, Peter [mailto:[email-masked]]
Sent: Tuesday, March 12, 2002 1:55 PM
To: 'Dan Elbert'; Taylor, Tom-PT [CAR:B800:EXCH]; megaco
Subject: RE: [Megaco] Question on Annex G, signal type On/Off

 
 
-- Peter
 
-----Original Message-----
From: Dan Elbert [mailto:[email-masked]]
Sent: March 12, 2002 01:56
To: 'Tom-PT Taylor'; Dan Elbert; 'Blatherwick, Peter'; megaco
Subject: RE: [Megaco] Question on Annex G, signal type On/Off

Dan

-----Original Message----- 

Hi 

is not defined. 

Thanks 
Dan Elbert 
RADVISION

---

From: "Kevin Boyle"<[email-masked]>
Date: Tue, 12 Mar 2002 14:26:55 -0500

Yes, that's right.  About ten seconds after I sent the message I realized my
mistake.  Thanks for pointing it out.

There is no way to specify in the grammar that a particular signal is immune
to event processing.  To achieve that same effect, all events would have to
be sent with the KeepActive flag.  This has the side effect of making ALL
signals immune to the processing for the event in question.  So, there is no
way to make a particular signal behave differently than other concurrent
signals with regard to event processing.

In the caspackage draft, however, certain signals are explicitly defined as
being immune to event processing.  This is one way to get around the
problem.  Another would be to alter the definition of OnOff -- however, this
may have side effects on existing packages that are undesirable.  I do not
believe that we want to alter the interruptability of Brief; there are many
brief signals defined that we want to be able to stop upon detection of an
event, such as a call wait tone upon detection of a flash.

Kevin

-----Original Message-----
From: Taylor, Tom-PT [CAR:B800:EXCH] 
Sent: Tuesday, March 12, 2002 2:15 PM
To: Boyle, Kevin [NCRTP:3Z30:EXCH]; 'Blatherwick, Peter'; 'Dan Elbert';
'megaco'

-----Original Message-----
From: Boyle, Kevin [NCRTP:3Z30:EXCH] 
Sent: Tuesday, March 12, 2002 2:07 PM
To: Blatherwick, Peter; 'Dan Elbert'; Taylor, Tom-PT [CAR:B800:EXCH];
megaco

Kevin

-----Original Message-----
From: Blatherwick, Peter [mailto:[email-masked]]
Sent: Tuesday, March 12, 2002 1:55 PM
To: 'Dan Elbert'; Taylor, Tom-PT [CAR:B800:EXCH]; megaco
Subject: RE: [Megaco] Question on Annex G, signal type On/Off

 
 
-- Peter
 
-----Original Message-----
From: Dan Elbert [mailto:[email-masked]]
Sent: March 12, 2002 01:56
To: 'Tom-PT Taylor'; Dan Elbert; 'Blatherwick, Peter'; megaco
Subject: RE: [Megaco] Question on Annex G, signal type On/Off

Dan

-----Original Message----- 

Hi 

is not defined. 

Thanks 
Dan Elbert 
RADVISION

---

From: "Kevin Boyle"<[email-masked]>
Date: Tue, 12 Mar 2002 14:26:55 -0500

Kevin

-----Original Message-----
From: Taylor, Tom-PT [CAR:B800:EXCH] 
Sent: Tuesday, March 12, 2002 2:15 PM
To: Boyle, Kevin [NCRTP:3Z30:EXCH]; 'Blatherwick, Peter'; 'Dan Elbert';
'megaco'

-----Original Message-----
From: Boyle, Kevin [NCRTP:3Z30:EXCH] 
Sent: Tuesday, March 12, 2002 2:07 PM
To: Blatherwick, Peter; 'Dan Elbert'; Taylor, Tom-PT [CAR:B800:EXCH];
megaco

Kevin

-----Original Message-----
From: Blatherwick, Peter [mailto:[email-masked]]
Sent: Tuesday, March 12, 2002 1:55 PM
To: 'Dan Elbert'; Taylor, Tom-PT [CAR:B800:EXCH]; megaco
Subject: RE: [Megaco] Question on Annex G, signal type On/Off

 
 
-- Peter
 
-----Original Message-----
From: Dan Elbert [mailto:[email-masked]]
Sent: March 12, 2002 01:56
To: 'Tom-PT Taylor'; Dan Elbert; 'Blatherwick, Peter'; megaco
Subject: RE: [Megaco] Question on Annex G, signal type On/Off

Dan

-----Original Message----- 

Hi 

is not defined. 

Thanks 
Dan Elbert 
RADVISION

---

From: "Blatherwick, Peter" <[email-masked]>
Date: Tue, 12 Mar 2002 16:56:09 -0500

Point for Annex G and similarly behaving signals is they have persistent state implied by what they do.  They are "brief" in the sense that they cause state transition in 0 time, however state is persistent after that.  Does not make sense for example to clear a display because some event happenned, nor clear an indicator..  
 
Kevin's point below I think argues in favour of treating these signals as brief.  Seems kind of odd though, I admit.  
 
-- Peter
 
-----Original Message-----
From: Tom-PT Taylor [mailto:[email-masked]]
Sent: March 12, 2002 14:15
To: Kevin Boyle; 'Blatherwick, Peter'; 'Dan Elbert'; 'megaco'
Subject: RE: [Megaco] Question on Annex G, signal type On/Off

Slight correction here: the KeepActive on signals controls what happens to a signal when the Signals descriptor is replaced.

-----Original Message----- 
From: Boyle, Kevin [NCRTP:3Z30:EXCH] 
Sent: Tuesday, March 12, 2002 2:07 PM 
To: Blatherwick, Peter; 'Dan Elbert'; Taylor, Tom-PT [CAR:B800:EXCH]; 
megaco 

If you don't want a signal stopped due to event processing, set the KeepActive parm on the signal.  If you don't want a particular event to stop signals, then set KeepActive on the event. Otherwise, ALL signal types are halted by event processing.

Kevin 

-----Original Message----- 
From: Blatherwick, Peter [ mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Tuesday, March 12, 2002 1:55 PM 
To: 'Dan Elbert'; Taylor, Tom-PT [CAR:B800:EXCH]; megaco 
Subject: RE: [Megaco] Question on Annex G, signal type On/Off 

  
-- Peter 
  
-----Original Message----- 
From: Dan Elbert [ mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: March 12, 2002 01:56 
To: 'Tom-PT Taylor'; Dan Elbert; 'Blatherwick, Peter'; megaco 
Subject: RE: [Megaco] Question on Annex G, signal type On/Off 

Dan 

-----Original Message----- 
From: Dan Elbert [ mailto:[email-masked] <mailto:[email-masked]>  < mailto:[email-masked] <mailto:[email-masked]> > ] 
Sent: Thursday, March 07, 2002 5:41 AM 
To: 'Blatherwick, Peter'; megaco 
Subject: [Megaco] Question on Annex G, signal type On/Off 

Hi 

Thanks 
Dan Elbert 
RADVISION 

_______________________________________________ 
Megaco mailing list 
[email-masked] 
https://www1.ietf.org/mailman/listinfo/megaco <https://www1.ietf.org/mailman/listinfo/megaco>  < https://www1.ietf.org/mailman/listinfo/megaco <https://www1.ietf.org/mailman/listinfo/megaco> >

---

From: "Blatherwick, Peter" <[email-masked]>
Date: Tue, 12 Mar 2002 16:56:09 -0500

-- Peter

-----Original Message----- 
From: Boyle, Kevin [NCRTP:3Z30:EXCH] 
Sent: Tuesday, March 12, 2002 2:07 PM 
To: Blatherwick, Peter; 'Dan Elbert'; Taylor, Tom-PT [CAR:B800:EXCH]; 
megaco 

Kevin 

-----Original Message----- 
From: Blatherwick, Peter [ mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Tuesday, March 12, 2002 1:55 PM 
To: 'Dan Elbert'; Taylor, Tom-PT [CAR:B800:EXCH]; megaco 
Subject: RE: [Megaco] Question on Annex G, signal type On/Off 

  
-- Peter 
  
-----Original Message----- 
From: Dan Elbert [ mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: March 12, 2002 01:56 
To: 'Tom-PT Taylor'; Dan Elbert; 'Blatherwick, Peter'; megaco 
Subject: RE: [Megaco] Question on Annex G, signal type On/Off 

Dan 

-----Original Message----- 
From: Dan Elbert [ mailto:[email-masked] <mailto:[email-masked]>  < mailto:[email-masked] <mailto:[email-masked]> > ] 
Sent: Thursday, March 07, 2002 5:41 AM 
To: 'Blatherwick, Peter'; megaco 
Subject: [Megaco] Question on Annex G, signal type On/Off 

Hi 

Thanks 
Dan Elbert 
RADVISION

---

From: "Kevin Boyle"<[email-masked]>
Date: Wed, 13 Mar 2002 11:08:25 -0500

Brief tones are interrupted by event processing.  Nowhere are brief tones
granted immunity from this behavior.  Making the signals brief will not
protect them from being halted.

Kevin

-----Original Message-----
From: Blatherwick, Peter [mailto:[email-masked]]
Sent: Tuesday, March 12, 2002 4:56 PM
To: Taylor, Tom-PT [CAR:B800:EXCH]; Boyle, Kevin [NCRTP:3Z30:EXCH];
Blatherwick, Peter; 'Dan Elbert'; 'megaco'
Subject: RE: [Megaco] Question on Annex G, signal type On/Off

Point for Annex G and similarly behaving signals is they have persistent
state implied by what they do.  They are "brief" in the sense that they
cause state transition in 0 time, however state is persistent after that.
Does not make sense for example to clear a display because some event
happenned, nor clear an indicator..  
 
Kevin's point below I think argues in favour of treating these signals as
brief.  Seems kind of odd though, I admit.  
 
-- Peter

-----Original Message----- 
From: Boyle, Kevin [NCRTP:3Z30:EXCH] 
Sent: Tuesday, March 12, 2002 2:07 PM 
To: Blatherwick, Peter; 'Dan Elbert'; Taylor, Tom-PT [CAR:B800:EXCH]; 
megaco 

Kevin 

-----Original Message----- 
From: Blatherwick, Peter [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Tuesday, March 12, 2002 1:55 PM 
To: 'Dan Elbert'; Taylor, Tom-PT [CAR:B800:EXCH]; megaco 
Subject: RE: [Megaco] Question on Annex G, signal type On/Off 

  
-- Peter 
  
-----Original Message----- 

Dan 

-----Original Message----- 
From: Tom-PT Taylor [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Monday, March 11, 2002 4:26 PM 
To: 'Dan Elbert'; 'Blatherwick, Peter'; megaco 
Subject: RE: [Megaco] Question on Annex G, signal type On/Off 

-----Original Message----- 
From: Dan Elbert [ mailto:[email-masked]
<mailto:[email-masked]>  < mailto:[email-masked]
<mailto:[email-masked]> > ] 
Sent: Thursday, March 07, 2002 5:41 AM 
To: 'Blatherwick, Peter'; megaco 
Subject: [Megaco] Question on Annex G, signal type On/Off 

Hi 

is not defined. 

Thanks 
Dan Elbert 
RADVISION 

_______________________________________________ 
Megaco mailing list 
[email-masked] 
https://www1.ietf.org/mailman/listinfo/megaco
<https://www1.ietf.org/mailman/listinfo/megaco>  <
https://www1.ietf.org/mailman/listinfo/megaco
<https://www1.ietf.org/mailman/listinfo/megaco> >

---

From: "Kevin Boyle"<[email-masked]>
Date: Wed, 13 Mar 2002 11:08:25 -0500

Kevin

-----Original Message-----
From: Blatherwick, Peter [mailto:[email-masked]]
Sent: Tuesday, March 12, 2002 4:56 PM
To: Taylor, Tom-PT [CAR:B800:EXCH]; Boyle, Kevin [NCRTP:3Z30:EXCH];

 
-- Peter

-----Original Message----- 
From: Boyle, Kevin [NCRTP:3Z30:EXCH] 
Sent: Tuesday, March 12, 2002 2:07 PM 
To: Blatherwick, Peter; 'Dan Elbert'; Taylor, Tom-PT [CAR:B800:EXCH]; 
megaco 

Kevin 

-----Original Message----- 

  
-- Peter 
  
-----Original Message----- 

Dan 

-----Original Message----- 

Hi 

is not defined. 

Thanks 
Dan Elbert 
RADVISION

---

From: Raphael Tryster <[email-masked]>
Date: Thu, 14 Mar 2002 08:37:11 +0200

I am puzzled by the concept of interrupting a brief signal.  You can only
interrupt a signal if you know that it is still playing.  To know this, you
need to define an occurrence that will tell you it has finished on its own.
I can only think of two types of occurrences that could do this:

1.	Timeout.  If so, Kevin's case is easy to understand, but then it's
not really a brief signal, is it?  If some signal has a standard duration of
100 milliseconds, why not make that explicit and call it a TO signal?

2.	Signal end = signal start.  This is what I thought BR meant.  Maybe
its duration is >0 in hardware, but the software doesn't have to worry about
that.  This means that in a signal list containing a BR signal, the software
should be able to send the signal after the BR to the hardware without any
delay.  If this is the definition, then I don't understand Kevin's case.  An
event cannot interrupt a BR signal because, logically, it has already
stopped.

Raphael Tryster

	-----Original Message-----
	From:	Kevin Boyle [SMTP:[email-masked]]
	Sent:	Wednesday, 13 March, 2002 6:08 PM
	To:	Blatherwick, Peter; Tom-PT Taylor; 'Dan Elbert'; 'megaco'
	Subject:	RE: [Megaco] Question on Annex G, signal type On/Off

	Brief tones are interrupted by event processing.  Nowhere are brief
tones
	granted immunity from this behavior.  Making the signals brief will
not
	protect them from being halted.

	Kevin

	-----Original Message-----
	From: Blatherwick, Peter [mailto:[email-masked]]
	Sent: Tuesday, March 12, 2002 4:56 PM
	To: Taylor, Tom-PT [CAR:B800:EXCH]; Boyle, Kevin [NCRTP:3Z30:EXCH];
	Blatherwick, Peter; 'Dan Elbert'; 'megaco'
	Subject: RE: [Megaco] Question on Annex G, signal type On/Off

	Point for Annex G and similarly behaving signals is they have
persistent
	state implied by what they do.  They are "brief" in the sense that
they
	cause state transition in 0 time, however state is persistent after
that.
	Does not make sense for example to clear a display because some
event
	happenned, nor clear an indicator..  
	 
	Kevin's point below I think argues in favour of treating these
signals as
	brief.  Seems kind of odd though, I admit.  
	 
	-- Peter
	 
	-----Original Message-----
	From: Tom-PT Taylor [mailto:[email-masked]]
	Sent: March 12, 2002 14:15
	To: Kevin Boyle; 'Blatherwick, Peter'; 'Dan Elbert'; 'megaco'
	Subject: RE: [Megaco] Question on Annex G, signal type On/Off

	Slight correction here: the KeepActive on signals controls what
happens to a
	signal when the Signals descriptor is replaced.

	-----Original Message----- 
	From: Boyle, Kevin [NCRTP:3Z30:EXCH] 
	Sent: Tuesday, March 12, 2002 2:07 PM 
	To: Blatherwick, Peter; 'Dan Elbert'; Taylor, Tom-PT
[CAR:B800:EXCH]; 
	megaco 

	If you don't want a signal stopped due to event processing, set the
	KeepActive parm on the signal.  If you don't want a particular event
to stop
	signals, then set KeepActive on the event. Otherwise, ALL signal
types are
	halted by event processing.

	Kevin 

	-----Original Message----- 
	From: Blatherwick, Peter [ mailto:[email-masked]
	<mailto:[email-masked]> ] 
	Sent: Tuesday, March 12, 2002 1:55 PM 
	To: 'Dan Elbert'; Taylor, Tom-PT [CAR:B800:EXCH]; megaco 
	Subject: RE: [Megaco] Question on Annex G, signal type On/Off 

	Original intent of the signals in Annex G is on/off behaviour wrt
state of
	the user interface element in question. i.e. you turn on an
indicator,
	update a display, whatever, it just stays on.  To turn it off, you
would set
	state to off using the signal again.  Similarly, set state to
blinking, it
	blinks until told some other state in a subsequent signal.  Setting
without
	state parameter passed defaults to off.  

	I believe this corresponds to on/off behaviour in practice.  Unclear
to me
	if technically they should be classified as "brief" under Megaco --
also
	unclear it matters.   At one point, I thought we had description of
	different usage of signals that truly have lasting state and should
	therefore not be stopped by events.  Darned if I can find it now
(admittedly
	on a very brief scan).    

	-- Peter 
	  
	-----Original Message----- 
	From: Dan Elbert [ mailto:[email-masked]
	<mailto:[email-masked]> ] 
	Sent: March 12, 2002 01:56 
	To: 'Tom-PT Taylor'; Dan Elbert; 'Blatherwick, Peter'; megaco 
	Subject: RE: [Megaco] Question on Annex G, signal type On/Off 

	No, I guess they are not terminated when events are detected (is not
even
	clear what "terminated" means). So BR is appropieted. But I find it
	confusing because "brief" is defined as 

	   *  brief - the signal duration is so short that it will stop on
its  own
	unless a new signal is applied that causes it to stop;   no timeout
value is
	needed.

	In  this case we are talking about something that doesn't "stop". It
	actually looks more as a property than as a signal. Maybe we need to
expand
	the definition of brief.

	Dan 

	-----Original Message----- 
	From: Tom-PT Taylor [ mailto:[email-masked]
	<mailto:[email-masked]> ] 
	Sent: Monday, March 11, 2002 4:26 PM 
	To: 'Dan Elbert'; 'Blatherwick, Peter'; megaco 
	Subject: RE: [Megaco] Question on Annex G, signal type On/Off 

	Partly I'd say it depends on whether the signals concerned are meant
to be
	terminated by event occurrences.  If not, then the proper
classification is
	BR.

	-----Original Message----- 
	From: Dan Elbert [ mailto:[email-masked]
	<mailto:[email-masked]>  < mailto:[email-masked]
	<mailto:[email-masked]> > ] 
	Sent: Thursday, March 07, 2002 5:41 AM 
	To: 'Blatherwick, Peter'; megaco 
	Subject: [Megaco] Question on Annex G, signal type On/Off 

	Hi 

	In Annex G (user interface packages) the type of the signals in the
packages

	is not defined. 

	signals, but I'm not clear what the meaning of "on/off" is in a
signal like 
	SetIndicator in the Indicator package, where the signal has a state
which 
	can take many values (on,off,blink,...). 
	Perhaps it means "off" is return to default state ? 
	Another possibility is to consider this signals as "brief", in this
case we 
	apply them to set them on and then we apply them again to change the
state. 
	This works but seems like "cheating" in the meaning of "brief". 
	The type will affect the behaviour when an empty SignalDescriptor is
used, 
	on/off signals should be turned off but brief signals not (because
they are 
	assume to play only a short time). 
	Your thoughts ? 

	Thanks 
	Dan Elbert 
	RADVISION

---

From: Raphael Tryster <[email-masked]>
Date: Thu, 14 Mar 2002 08:37:11 +0200

Raphael Tryster

	-----Original Message-----
	From:	Kevin Boyle [SMTP:[email-masked]]
	Sent:	Wednesday, 13 March, 2002 6:08 PM
	To:	Blatherwick, Peter; Tom-PT Taylor; 'Dan Elbert'; 'megaco'
	Subject:	RE: [Megaco] Question on Annex G, signal type On/Off

	Kevin

	-----Original Message-----
	From: Blatherwick, Peter [mailto:[email-masked]]
	Sent: Tuesday, March 12, 2002 4:56 PM
	To: Taylor, Tom-PT [CAR:B800:EXCH]; Boyle, Kevin [NCRTP:3Z30:EXCH];
	Blatherwick, Peter; 'Dan Elbert'; 'megaco'
	Subject: RE: [Megaco] Question on Annex G, signal type On/Off

	 
	-- Peter

	-----Original Message----- 
	From: Boyle, Kevin [NCRTP:3Z30:EXCH] 
	Sent: Tuesday, March 12, 2002 2:07 PM 
	To: Blatherwick, Peter; 'Dan Elbert'; Taylor, Tom-PT
[CAR:B800:EXCH]; 
	megaco 

	Kevin 

	-----Original Message----- 
	From: Blatherwick, Peter [ mailto:[email-masked]
	<mailto:[email-masked]> ] 
	Sent: Tuesday, March 12, 2002 1:55 PM 
	To: 'Dan Elbert'; Taylor, Tom-PT [CAR:B800:EXCH]; megaco 
	Subject: RE: [Megaco] Question on Annex G, signal type On/Off 

	  
	-- Peter 
	  
	-----Original Message----- 
	From: Dan Elbert [ mailto:[email-masked]
	<mailto:[email-masked]> ] 
	Sent: March 12, 2002 01:56 
	To: 'Tom-PT Taylor'; Dan Elbert; 'Blatherwick, Peter'; megaco 
	Subject: RE: [Megaco] Question on Annex G, signal type On/Off 

	Dan 

	-----Original Message----- 
	From: Dan Elbert [ mailto:[email-masked]
	<mailto:[email-masked]>  < mailto:[email-masked]
	<mailto:[email-masked]> > ] 
	Sent: Thursday, March 07, 2002 5:41 AM 
	To: 'Blatherwick, Peter'; megaco 
	Subject: [Megaco] Question on Annex G, signal type On/Off 

	Hi 

	is not defined. 

	Thanks 
	Dan Elbert 
	RADVISION

---

From: "Kevin Boyle"<[email-masked]>
Date: Thu, 14 Mar 2002 02:28:17 -0500

This brings us to the basic problem with dividing signals into types: they
are all closely related!  An onoff signal is a timeout signal with an
infinite duration.  A brief signal is a timeout signal with a (relatively)
short duration.  The distinction amongst the three types is mostly
artificial.

However, for argument's sake, let's look at the second option proposed here.
If the definition of a brief signal is that the signal end is logically at
the same time as the signal start.  If this is the case, how does
NotifyCompletion work for brief signals?  Is the completion event returned
the instant the descriptor is processed?  What if the "brief" signal has a
duration of 2 seconds?  For example, the andisp/data signal is defined as
brief, and it can last a significant amount of time -- potentially several
seconds.  Because only the MG can determine how long the signal will be
(which is related to the amount of data to be transmitted to the CPE),
NotifyCompletion may be a very useful for determining when more data may be
sent by the MGC.  However, if the NC is returned instantly, the MGC will end
up interrupting the previous data transmission when it sends the next batch!
I do not believe that we can make the arbitrary statement that brief signals
have a logical end that is the same as the logical start of the signal -- it
will lead to problems similar to that I have outlined here.

So, that leaves us one choice: a brief is just like any other signal, has a
logical duration greater than zero, and is therefore interruptible by event
processing.  If we have to define one signal type as immune, I think it
would be better to make OnOff the special type.  The whole point of the
OnOff type is that the signal lasts until it is explicitly removed.  Then,
we can make lamp-type signals OnOff to make them immune to event processing,
and they will stay lit until the MGC explicitly clears the signal.  Making
brief signals immune will make signals like the data transmission immune to
event processing, which is exactly the opposite of the behavior defined by
Telcordia and ETSI with regard to data transmission features.  Other brief
signals will experience similar problems.

Kevin

-----Original Message-----
From: Raphael Tryster [mailto:[email-masked]]
Sent: Thursday, March 14, 2002 1:37 AM
To: Boyle, Kevin [NCRTP:3Z30:EXCH]; Blatherwick, Peter; Taylor, Tom-PT
[CAR:B800:EXCH]; 'Dan Elbert'; 'megaco'
Subject: RE: [Megaco] Question on Annex G, signal type On/Off

I am puzzled by the concept of interrupting a brief signal.  You can only
interrupt a signal if you know that it is still playing.  To know this, you
need to define an occurrence that will tell you it has finished on its own.
I can only think of two types of occurrences that could do this:
Timeout.  If so, Kevin's case is easy to understand, but then it's not
really a brief signal, is it?  If some signal has a standard duration of 100
milliseconds, why not make that explicit and call it a TO signal? 

Signal end = signal start.  This is what I thought BR meant.  Maybe its
duration is >0 in hardware, but the software doesn't have to worry about
that.  This means that in a signal list containing a BR signal, the software
should be able to send the signal after the BR to the hardware without any
delay.  If this is the definition, then I don't understand Kevin's case.  An
event cannot interrupt a BR signal because, logically, it has already
stopped. 

Raphael Tryster 

-----Original Message----- 
From: Blatherwick, Peter [mailto:[email-masked]] 
Sent: Tuesday, March 12, 2002 4:56 PM 
To: Taylor, Tom-PT [CAR:B800:EXCH]; Boyle, Kevin [NCRTP:3Z30:EXCH]; 

  
-- Peter 

-----Original Message----- 
From: Boyle, Kevin [NCRTP:3Z30:EXCH] 
Sent: Tuesday, March 12, 2002 2:07 PM 
To: Blatherwick, Peter; 'Dan Elbert'; Taylor, Tom-PT [CAR:B800:EXCH]; 
megaco 

-----Original Message----- 

on a very brief scan).    

-- Peter 
  
-----Original Message----- 

needed. 

-----Original Message----- 

Hi 

is not defined.

---

From: "Kevin Boyle"<[email-masked]>
Date: Thu, 14 Mar 2002 02:28:17 -0500

Kevin

-----Original Message-----
From: Raphael Tryster [mailto:[email-masked]]
Sent: Thursday, March 14, 2002 1:37 AM
To: Boyle, Kevin [NCRTP:3Z30:EXCH]; Blatherwick, Peter; Taylor, Tom-PT

Raphael Tryster 

-----Original Message----- 
From: Blatherwick, Peter [mailto:[email-masked]] 
Sent: Tuesday, March 12, 2002 4:56 PM 
To: Taylor, Tom-PT [CAR:B800:EXCH]; Boyle, Kevin [NCRTP:3Z30:EXCH]; 

  
-- Peter 

-----Original Message----- 
From: Boyle, Kevin [NCRTP:3Z30:EXCH] 
Sent: Tuesday, March 12, 2002 2:07 PM 
To: Blatherwick, Peter; 'Dan Elbert'; Taylor, Tom-PT [CAR:B800:EXCH]; 
megaco 

-----Original Message----- 

on a very brief scan).    

-- Peter 
  
-----Original Message----- 

needed. 

-----Original Message----- 

Hi 

is not defined.

---

From: Dan Elbert <[email-masked]>
Date: Thu, 14 Mar 2002 10:22:16 +0200

Well, this can considered an implementation issue, if the signal is very
brief there is no chance to interrupt it.
Furthermore what Peter is saying is that the signal is actually the
transition from state to state and not the state itself.
I would like some clarifications in Annex G, and maybe even in the Megaco
IG.

Dan

-----Original Message-----
From: Kevin Boyle [mailto:[email-masked]]
Sent: Wednesday, March 13, 2002 6:08 PM
To: Blatherwick, Peter; Tom-PT Taylor; 'Dan Elbert'; 'megaco'
Subject: RE: [Megaco] Question on Annex G, signal type On/Off

Kevin

-----Original Message-----
From: Blatherwick, Peter [mailto:[email-masked]]
Sent: Tuesday, March 12, 2002 4:56 PM
To: Taylor, Tom-PT [CAR:B800:EXCH]; Boyle, Kevin [NCRTP:3Z30:EXCH];

 
-- Peter

-----Original Message----- 
From: Boyle, Kevin [NCRTP:3Z30:EXCH] 
Sent: Tuesday, March 12, 2002 2:07 PM 
To: Blatherwick, Peter; 'Dan Elbert'; Taylor, Tom-PT [CAR:B800:EXCH]; 
megaco 

Kevin 

-----Original Message----- 

  
-- Peter 
  
-----Original Message----- 

Dan 

-----Original Message----- 

Hi 

is not defined. 

Thanks 
Dan Elbert 
RADVISION

---

From: Dan Elbert <[email-masked]>
Date: Thu, 14 Mar 2002 10:22:16 +0200

Dan

-----Original Message-----
From: Kevin Boyle [mailto:[email-masked]]
Sent: Wednesday, March 13, 2002 6:08 PM
To: Blatherwick, Peter; Tom-PT Taylor; 'Dan Elbert'; 'megaco'
Subject: RE: [Megaco] Question on Annex G, signal type On/Off

Kevin

-----Original Message-----
From: Blatherwick, Peter [mailto:[email-masked]]
Sent: Tuesday, March 12, 2002 4:56 PM
To: Taylor, Tom-PT [CAR:B800:EXCH]; Boyle, Kevin [NCRTP:3Z30:EXCH];

 
-- Peter

-----Original Message----- 
From: Boyle, Kevin [NCRTP:3Z30:EXCH] 
Sent: Tuesday, March 12, 2002 2:07 PM 
To: Blatherwick, Peter; 'Dan Elbert'; Taylor, Tom-PT [CAR:B800:EXCH]; 
megaco 

Kevin 

-----Original Message----- 

  
-- Peter 
  
-----Original Message----- 

Dan 

-----Original Message----- 

Hi 

is not defined. 

Thanks 
Dan Elbert 
RADVISION

---

From: "Kevin Boyle"<[email-masked]>
Date: Thu, 14 Mar 2002 03:40:21 -0500

I will admit that having the signal be the state transition is a subtle
point that I missed.  I had always figured that the lamp was the signal,
similar to a tone.

I don't necessarily have a problem with this interpretation, but, as you
have suggested, it does need to be very clearly stated that this is the
intent of the signals in Annex G.

Kevin

-----Original Message-----
From: Dan Elbert [mailto:[email-masked]]
Sent: Thursday, March 14, 2002 3:22 AM
To: Boyle, Kevin [NCRTP:3Z30:EXCH]; Blatherwick, Peter; Taylor, Tom-PT
[CAR:B800:EXCH]; 'megaco'
Subject: RE: [Megaco] Question on Annex G, signal type On/Off

Dan

-----Original Message-----
From: Kevin Boyle [mailto:[email-masked]]
Sent: Wednesday, March 13, 2002 6:08 PM
To: Blatherwick, Peter; Tom-PT Taylor; 'Dan Elbert'; 'megaco'
Subject: RE: [Megaco] Question on Annex G, signal type On/Off

Kevin

-----Original Message-----
From: Blatherwick, Peter [mailto:[email-masked]]
Sent: Tuesday, March 12, 2002 4:56 PM
To: Taylor, Tom-PT [CAR:B800:EXCH]; Boyle, Kevin [NCRTP:3Z30:EXCH];

 
-- Peter

-----Original Message----- 
From: Boyle, Kevin [NCRTP:3Z30:EXCH] 
Sent: Tuesday, March 12, 2002 2:07 PM 
To: Blatherwick, Peter; 'Dan Elbert'; Taylor, Tom-PT [CAR:B800:EXCH]; 
megaco 

Kevin 

-----Original Message----- 

  
-- Peter 
  
-----Original Message----- 

Dan 

-----Original Message----- 

Hi 

is not defined. 

Thanks 
Dan Elbert 
RADVISION

---

From: "Kevin Boyle"<[email-masked]>
Date: Thu, 14 Mar 2002 03:40:21 -0500

Kevin

-----Original Message-----
From: Dan Elbert [mailto:[email-masked]]
Sent: Thursday, March 14, 2002 3:22 AM
To: Boyle, Kevin [NCRTP:3Z30:EXCH]; Blatherwick, Peter; Taylor, Tom-PT

Dan

-----Original Message-----
From: Kevin Boyle [mailto:[email-masked]]
Sent: Wednesday, March 13, 2002 6:08 PM
To: Blatherwick, Peter; Tom-PT Taylor; 'Dan Elbert'; 'megaco'
Subject: RE: [Megaco] Question on Annex G, signal type On/Off

Kevin

-----Original Message-----
From: Blatherwick, Peter [mailto:[email-masked]]
Sent: Tuesday, March 12, 2002 4:56 PM
To: Taylor, Tom-PT [CAR:B800:EXCH]; Boyle, Kevin [NCRTP:3Z30:EXCH];

 
-- Peter

-----Original Message----- 
From: Boyle, Kevin [NCRTP:3Z30:EXCH] 
Sent: Tuesday, March 12, 2002 2:07 PM 
To: Blatherwick, Peter; 'Dan Elbert'; Taylor, Tom-PT [CAR:B800:EXCH]; 
megaco 

Kevin 

-----Original Message----- 

  
-- Peter 
  
-----Original Message----- 

Dan 

-----Original Message----- 

Hi 

is not defined. 

Thanks 
Dan Elbert 
RADVISION

---

From: Raphael Tryster <[email-masked]>
Date: Thu, 14 Mar 2002 10:51:03 +0200

[Note: I truncated the start of this thread because the list
processor said it's getting too long.]

	Kevin,

	I am afraid your reply adds to my confusion, because it appears that
Megaco has been developing in a direction opposite to the one you are
proposing.  If we consider MGCP as an ancestor of Megaco, you will see what
I mean.

	Regarding on/off signals, RFC2705 says:

	The formal definition is that the generation of all "Time Out"
signals shall stop as soon as one of the requested events is detected,
unless the "Keep signals active" action is associated to the specified
event.

	It specifically says that TO signals stop on an event, leading one
to suspect that OO signals do not stop.  RFC2705bis-02 makes this explicit:

	On/off (OO):  Once applied, these signals last until they are turned
off. This can only happen as the result of a reboot or a new SignalRequests
where the signal is explicitly turned off (see later). Signals of type OO
are defined to be idempotent, thus multiple requests to turn a given OO
signal on (or off) are perfectly valid and MUST NOT result in any errors. An
On/Off signal could be a visual message waiting indicator (VMWI). Once
turned on, it MUST NOT be turned off until explicitly instructed to by the
Call Agent, or as a result of an endpoint restart, i.e. these signals will
not turn off as a result the arrival of a requested event.

	So far, so good: MGCP agrees with you.  But then comes RFC 3015,
which says:

	A new SignalsDescriptor replaces any existing SignalsDescriptor. Any
signals applied to the Termination not in the replacement descriptor shall
be stopped.

	That's it, no qualification that this doesn't apply to OO signals.
I would conclude from this that in Megaco, an OO signal is implicitly turned
off by a new SignalsDescriptor.  And the occurrence of an event causes
replacement of the SignalsDescriptor.

	Now, how has the concept of brief signals developed?  RFC2705 is
uncertain, but inclines to your point of view.  Here is what it says about
auditing signals:

	SignalRequests: A list of the; Time-Out signals that are currently
active, On/Off signals that are currently "on" for the endpoint (with or
without parameter), and any pending Brief signals. Time-Out signals that
have timed-out, and currently playing Brief signals are not included.

	Note that the concept of "currently playing Brief signals" is
meaningful only if they have a finite duration.  The uncertainty comes in
another paragraph:

	Brief (BR) The duration of these signals is so short, that they stop
on their own. If an event occurs the signal will not stop, however if a new
SignalRequests is applied, the signal will stop.  (Note: this point should
be debated.  One could make a case that events such as strings of DTMF
digits should in fact be allowed to complete.)

	RFC3015 exhibits similar uncertainty, as shown in the following two
extracts:

	brief - the signal duration is so short that it will stop on its own
unless a new signal is applied that causes it to stop; no timeout value is
needed.

	Signals that would be played with SignalType BR or TO should have a
default duration.  The package has to define the default duration and
signalType.

	But then H248v2 comes down firmly on the other side of the debate:

	A default duration is meaningless for BR.

	All of which leaves me in quite a quandary as to how my software
should behave.

	Raphael Tryster

		-----Original Message-----
		From:	Kevin Boyle [SMTP:[email-masked]]
		Sent:	Thursday, 14 March, 2002 9:28 AM
		To:	Raphael Tryster; Blatherwick, Peter; Tom-PT Taylor;
'Dan Elbert'; 'megaco'
		Subject:	RE: [Megaco] Question on Annex G, signal
type On/Off

		This brings us to the basic problem with dividing signals
into types: they
		are all closely related!  An onoff signal is a timeout
signal with an
		infinite duration.  A brief signal is a timeout signal with
a (relatively)
		short duration.  The distinction amongst the three types is
mostly
		artificial.

		However, for argument's sake, let's look at the second
option proposed here.
		If the definition of a brief signal is that the signal end
is logically at
		the same time as the signal start.  If this is the case, how
does
		NotifyCompletion work for brief signals?  Is the completion
event returned
		the instant the descriptor is processed?  What if the
"brief" signal has a
		duration of 2 seconds?  For example, the andisp/data signal
is defined as
		brief, and it can last a significant amount of time --
potentially several
		seconds.  Because only the MG can determine how long the
signal will be
		(which is related to the amount of data to be transmitted to
the CPE),
		NotifyCompletion may be a very useful for determining when
more data may be
		sent by the MGC.  However, if the NC is returned instantly,
the MGC will end
		up interrupting the previous data transmission when it sends
the next batch!
		I do not believe that we can make the arbitrary statement
that brief signals
		have a logical end that is the same as the logical start of
the signal -- it
		will lead to problems similar to that I have outlined here.

		So, that leaves us one choice: a brief is just like any
other signal, has a
		logical duration greater than zero, and is therefore
interruptible by event
		processing.  If we have to define one signal type as immune,
I think it
		would be better to make OnOff the special type.  The whole
point of the
		OnOff type is that the signal lasts until it is explicitly
removed.  Then,
		we can make lamp-type signals OnOff to make them immune to
event processing,
		and they will stay lit until the MGC explicitly clears the
signal.  Making
		brief signals immune will make signals like the data
transmission immune to
		event processing, which is exactly the opposite of the
behavior defined by
		Telcordia and ETSI with regard to data transmission
features.  Other brief
		signals will experience similar problems.

		Kevin

		-----Original Message-----
		From: Raphael Tryster [mailto:[email-masked]]
		Sent: Thursday, March 14, 2002 1:37 AM
		To: Boyle, Kevin [NCRTP:3Z30:EXCH]; Blatherwick, Peter;
Taylor, Tom-PT
		[CAR:B800:EXCH]; 'Dan Elbert'; 'megaco'
		Subject: RE: [Megaco] Question on Annex G, signal type
On/Off

		I am puzzled by the concept of interrupting a brief signal.
You can only
		interrupt a signal if you know that it is still playing.  To
know this, you
		need to define an occurrence that will tell you it has
finished on its own.
		I can only think of two types of occurrences that could do
this:
		Timeout.  If so, Kevin's case is easy to understand, but
then it's not
		really a brief signal, is it?  If some signal has a standard
duration of 100
		milliseconds, why not make that explicit and call it a TO
signal? 

		Signal end = signal start.  This is what I thought BR meant.
Maybe its
		duration is >0 in hardware, but the software doesn't have to
worry about
		that.  This means that in a signal list containing a BR
signal, the software
		should be able to send the signal after the BR to the
hardware without any
		delay.  If this is the definition, then I don't understand
Kevin's case.  An
		event cannot interrupt a BR signal because, logically, it
has already
		stopped. 

		Raphael Tryster 

		-----Original Message----- 
		From:   Kevin Boyle [SMTP:[email-masked]] 
		Sent:   Wednesday, 13 March, 2002 6:08 PM 
		To:     Blatherwick, Peter; Tom-PT Taylor; 'Dan Elbert';
'megaco' 
		Subject:        RE: [Megaco] Question on Annex G, signal
type On/Off 
		Brief tones are interrupted by event processing.  Nowhere
are brief tones 
		granted immunity from this behavior.  Making the signals
brief will not 
		protect them from being halted. 
		Kevin

---

From: Raphael Tryster <[email-masked]>
Date: Thu, 14 Mar 2002 10:51:03 +0200

Kevin,

	Raphael Tryster

		-----Original Message-----
		From:	Kevin Boyle [SMTP:[email-masked]]
		Sent:	Thursday, 14 March, 2002 9:28 AM
		To:	Raphael Tryster; Blatherwick, Peter; Tom-PT Taylor;
'Dan Elbert'; 'megaco'

		Kevin

		-----Original Message-----
		From: Raphael Tryster [mailto:[email-masked]]
		Sent: Thursday, March 14, 2002 1:37 AM
		To: Boyle, Kevin [NCRTP:3Z30:EXCH]; Blatherwick, Peter;
Taylor, Tom-PT

		Raphael Tryster 

		-----Original Message----- 
		From:   Kevin Boyle [SMTP:[email-masked]] 
		Sent:   Wednesday, 13 March, 2002 6:08 PM 
		To:     Blatherwick, Peter; Tom-PT Taylor; 'Dan Elbert';
'megaco'

---

From: Raphael Tryster <[email-masked]>
Date: Thu, 14 Mar 2002 10:45:09 +0200

Kevin,

I am afraid your reply adds to my confusion, because it appears that Megaco
has been developing in a direction opposite to the one you are proposing.
If we consider MGCP as an ancestor of Megaco, you will see what I mean.

The formal definition is that the generation of all "Time Out" signals shall
stop as soon as one of the requested events is detected, unless the "Keep
signals active" action is associated to the specified event.

It specifically says that TO signals stop on an event, leading one to
suspect that OO signals do not stop.  RFC2705bis-02 makes this explicit:

On/off (OO):  Once applied, these signals last until they are turned off.
This can only happen as the result of a reboot or a new SignalRequests where
the signal is explicitly turned off (see later). Signals of type OO are
defined to be idempotent, thus multiple requests to turn a given OO signal
on (or off) are perfectly valid and MUST NOT result in any errors. An On/Off
signal could be a visual message waiting indicator (VMWI). Once turned on,
it MUST NOT be turned off until explicitly instructed to by the Call Agent,
or as a result of an endpoint restart, i.e. these signals will not turn off
as a result the arrival of a requested event.

So far, so good: MGCP agrees with you.  But then comes RFC 3015, which says:

A new SignalsDescriptor replaces any existing SignalsDescriptor. Any signals
applied to the Termination not in the replacement descriptor shall be
stopped.

That's it, no qualification that this doesn't apply to OO signals.  I would
conclude from this that in Megaco, an OO signal is implicitly turned off by
a new SignalsDescriptor.  And the occurrence of an event causes replacement
of the SignalsDescriptor.

Now, how has the concept of brief signals developed?  RFC2705 is uncertain,
but inclines to your point of view.  Here is what it says about auditing
signals:

SignalRequests: A list of the; Time-Out signals that are currently active,
On/Off signals that are currently "on" for the endpoint (with or without
parameter), and any pending Brief signals. Time-Out signals that have
timed-out, and currently playing Brief signals are not included.

Note that the concept of "currently playing Brief signals" is meaningful
only if they have a finite duration.  The uncertainty comes in another
paragraph:

Brief (BR) The duration of these signals is so short, that they stop on
their own. If an event occurs the signal will not stop, however if a new
SignalRequests is applied, the signal will stop.  (Note: this point should
be debated.  One could make a case that events such as strings of DTMF
digits should in fact be allowed to complete.)

brief - the signal duration is so short that it will stop on its own unless
a new signal is applied that causes it to stop; no timeout value is needed.

Signals that would be played with SignalType BR or TO should have a default
duration.  The package has to define the default duration and signalType.

All of which leaves me in quite a quandary as to how my software should
behave.

Raphael Tryster

	-----Original Message-----
	From:	Kevin Boyle [SMTP:[email-masked]]
	Sent:	Thursday, 14 March, 2002 9:28 AM
	To:	Raphael Tryster; Blatherwick, Peter; Tom-PT Taylor; 'Dan
Elbert'; 'megaco'

	This brings us to the basic problem with dividing signals into
types: they
	are all closely related!  An onoff signal is a timeout signal with
an
	infinite duration.  A brief signal is a timeout signal with a
(relatively)
	short duration.  The distinction amongst the three types is mostly
	artificial.

	However, for argument's sake, let's look at the second option
proposed here.
	If the definition of a brief signal is that the signal end is
logically at
	the same time as the signal start.  If this is the case, how does
	NotifyCompletion work for brief signals?  Is the completion event
returned
	the instant the descriptor is processed?  What if the "brief" signal
has a
	duration of 2 seconds?  For example, the andisp/data signal is
defined as
	brief, and it can last a significant amount of time -- potentially
several
	seconds.  Because only the MG can determine how long the signal will
be
	(which is related to the amount of data to be transmitted to the
CPE),
	NotifyCompletion may be a very useful for determining when more data
may be
	sent by the MGC.  However, if the NC is returned instantly, the MGC
will end
	up interrupting the previous data transmission when it sends the
next batch!
	I do not believe that we can make the arbitrary statement that brief
signals
	have a logical end that is the same as the logical start of the
signal -- it
	will lead to problems similar to that I have outlined here.

	So, that leaves us one choice: a brief is just like any other
signal, has a
	logical duration greater than zero, and is therefore interruptible
by event
	processing.  If we have to define one signal type as immune, I think
it
	would be better to make OnOff the special type.  The whole point of
the
	OnOff type is that the signal lasts until it is explicitly removed.
Then,
	we can make lamp-type signals OnOff to make them immune to event
processing,
	and they will stay lit until the MGC explicitly clears the signal.
Making
	brief signals immune will make signals like the data transmission
immune to
	event processing, which is exactly the opposite of the behavior
defined by
	Telcordia and ETSI with regard to data transmission features.  Other
brief
	signals will experience similar problems.

	Kevin

	-----Original Message-----
	From: Raphael Tryster [mailto:[email-masked]]
	Sent: Thursday, March 14, 2002 1:37 AM
	To: Boyle, Kevin [NCRTP:3Z30:EXCH]; Blatherwick, Peter; Taylor,
Tom-PT

	I am puzzled by the concept of interrupting a brief signal.  You can
only
	interrupt a signal if you know that it is still playing.  To know
this, you
	need to define an occurrence that will tell you it has finished on
its own.
	I can only think of two types of occurrences that could do this:
	Timeout.  If so, Kevin's case is easy to understand, but then it's
not
	really a brief signal, is it?  If some signal has a standard
duration of 100
	milliseconds, why not make that explicit and call it a TO signal? 

	Signal end = signal start.  This is what I thought BR meant.  Maybe
its
	duration is >0 in hardware, but the software doesn't have to worry
about
	that.  This means that in a signal list containing a BR signal, the
software
	should be able to send the signal after the BR to the hardware
without any
	delay.  If this is the definition, then I don't understand Kevin's
case.  An
	event cannot interrupt a BR signal because, logically, it has
already
	stopped. 

	Raphael Tryster 

	-----Original Message----- 
	From: Blatherwick, Peter [mailto:[email-masked]] 
	Sent: Tuesday, March 12, 2002 4:56 PM 
	To: Taylor, Tom-PT [CAR:B800:EXCH]; Boyle, Kevin [NCRTP:3Z30:EXCH]; 
	Blatherwick, Peter; 'Dan Elbert'; 'megaco' 
	Subject: RE: [Megaco] Question on Annex G, signal type On/Off 

	  
	-- Peter 

	-----Original Message----- 
	From: Boyle, Kevin [NCRTP:3Z30:EXCH] 
	Sent: Tuesday, March 12, 2002 2:07 PM 
	To: Blatherwick, Peter; 'Dan Elbert'; Taylor, Tom-PT
[CAR:B800:EXCH]; 
	megaco 

	-----Original Message----- 
	From: Blatherwick, Peter [ mailto:[email-masked] 
	<mailto:[email-masked]> ] 
	Sent: Tuesday, March 12, 2002 1:55 PM 
	To: 'Dan Elbert'; Taylor, Tom-PT [CAR:B800:EXCH]; megaco 
	Subject: RE: [Megaco] Question on Annex G, signal type On/Off 

	on a very brief scan).    

	-- Peter 
	  
	-----Original Message----- 
	From: Dan Elbert [ mailto:[email-masked] 
	<mailto:[email-masked]> ] 
	Sent: March 12, 2002 01:56 
	To: 'Tom-PT Taylor'; Dan Elbert; 'Blatherwick, Peter'; megaco 
	Subject: RE: [Megaco] Question on Annex G, signal type On/Off 

	needed. 

	-----Original Message----- 
	From: Dan Elbert [ mailto:[email-masked] 
	<mailto:[email-masked]>  < mailto:[email-masked] 
	<mailto:[email-masked]> > ] 
	Sent: Thursday, March 07, 2002 5:41 AM 
	To: 'Blatherwick, Peter'; megaco 
	Subject: [Megaco] Question on Annex G, signal type On/Off 

	Hi 

	is not defined.

---

From: Raphael Tryster <[email-masked]>
Date: Thu, 14 Mar 2002 10:45:09 +0200

Kevin,

Raphael Tryster

	-----Original Message-----
	From:	Kevin Boyle [SMTP:[email-masked]]
	Sent:	Thursday, 14 March, 2002 9:28 AM
	To:	Raphael Tryster; Blatherwick, Peter; Tom-PT Taylor; 'Dan
Elbert'; 'megaco'

	Kevin

	-----Original Message-----
	From: Raphael Tryster [mailto:[email-masked]]
	Sent: Thursday, March 14, 2002 1:37 AM
	To: Boyle, Kevin [NCRTP:3Z30:EXCH]; Blatherwick, Peter; Taylor,
Tom-PT

	Raphael Tryster 

	-----Original Message----- 
	From: Blatherwick, Peter [mailto:[email-masked]] 
	Sent: Tuesday, March 12, 2002 4:56 PM 
	To: Taylor, Tom-PT [CAR:B800:EXCH]; Boyle, Kevin [NCRTP:3Z30:EXCH]; 
	Blatherwick, Peter; 'Dan Elbert'; 'megaco' 
	Subject: RE: [Megaco] Question on Annex G, signal type On/Off 

	  
	-- Peter 

	-----Original Message----- 
	From: Boyle, Kevin [NCRTP:3Z30:EXCH] 
	Sent: Tuesday, March 12, 2002 2:07 PM 
	To: Blatherwick, Peter; 'Dan Elbert'; Taylor, Tom-PT
[CAR:B800:EXCH]; 
	megaco 

	-----Original Message----- 
	From: Blatherwick, Peter [ mailto:[email-masked] 
	<mailto:[email-masked]> ] 
	Sent: Tuesday, March 12, 2002 1:55 PM 
	To: 'Dan Elbert'; Taylor, Tom-PT [CAR:B800:EXCH]; megaco 
	Subject: RE: [Megaco] Question on Annex G, signal type On/Off 

	on a very brief scan).    

	-- Peter 
	  
	-----Original Message----- 
	From: Dan Elbert [ mailto:[email-masked] 
	<mailto:[email-masked]> ] 
	Sent: March 12, 2002 01:56 
	To: 'Tom-PT Taylor'; Dan Elbert; 'Blatherwick, Peter'; megaco 
	Subject: RE: [Megaco] Question on Annex G, signal type On/Off 

	needed. 

	-----Original Message----- 
	From: Dan Elbert [ mailto:[email-masked] 
	<mailto:[email-masked]>  < mailto:[email-masked] 
	<mailto:[email-masked]> > ] 
	Sent: Thursday, March 07, 2002 5:41 AM 
	To: 'Blatherwick, Peter'; megaco 
	Subject: [Megaco] Question on Annex G, signal type On/Off 

	Hi 

	is not defined.

---

From: "Tom-PT Taylor"<[email-masked]>
Date: Thu, 14 Mar 2002 09:38:41 -0500

Your conclusion that BR signals are interruptible while they are playing out
is correct.  And indeed, the announcement playouts in new Annex M.1 can be
BR and last for minutes -- they fall within the definition of BR because
they are self-limiting (by the number of cycles requested).  On the other
hand, some signals do terminate as soon as the descriptor is processed.  I'd
say the Annex G signals might be of this type if they are considered to set
a device state rather than maintain that state while they last.

It is up to the package documentation to indicate when a signal of BR type
is considered to have completed.  I'll note that in the Annex G case, if the
signal is typed as BR and completes as soon as the device state is set, a
new signal has to be applied to clean up device state when the call is
ended.  If, on the other hand, the signal is considered to be OO, it is
possible to have automatic cleanup on recognition of events for which the
KeepActive flag is not set.

One other point: this discussion is strongly conditioned by the slight
change to BR definition we made in Geneva (after consulting the list).
There is a real difference between BR and other signals now, and it is not
always possible to override the default signal type in any meaningful way.

-----Original Message-----
From: Boyle, Kevin [NCRTP:3Z30:EXCH] 
Sent: Thursday, March 14, 2002 2:28 AM
To: Raphael Tryster; Blatherwick, Peter; Taylor, Tom-PT [CAR:B800:EXCH];
'Dan Elbert'; 'megaco'

Kevin

-----Original Message-----
From: Raphael Tryster [mailto:[email-masked]]
Sent: Thursday, March 14, 2002 1:37 AM
To: Boyle, Kevin [NCRTP:3Z30:EXCH]; Blatherwick, Peter; Taylor, Tom-PT

Raphael Tryster 

-----Original Message----- 
From: Blatherwick, Peter [mailto:[email-masked]] 
Sent: Tuesday, March 12, 2002 4:56 PM 
To: Taylor, Tom-PT [CAR:B800:EXCH]; Boyle, Kevin [NCRTP:3Z30:EXCH]; 

  
-- Peter 

-----Original Message----- 
From: Boyle, Kevin [NCRTP:3Z30:EXCH] 
Sent: Tuesday, March 12, 2002 2:07 PM 
To: Blatherwick, Peter; 'Dan Elbert'; Taylor, Tom-PT [CAR:B800:EXCH]; 
megaco 

-----Original Message----- 

on a very brief scan).    

-- Peter 
  
-----Original Message----- 

needed. 

-----Original Message----- 

Hi 

is not defined.

---

From: "Tom-PT Taylor"<[email-masked]>
Date: Thu, 14 Mar 2002 09:38:41 -0500

-----Original Message-----
From: Boyle, Kevin [NCRTP:3Z30:EXCH] 
Sent: Thursday, March 14, 2002 2:28 AM
To: Raphael Tryster; Blatherwick, Peter; Taylor, Tom-PT [CAR:B800:EXCH];
'Dan Elbert'; 'megaco'

Kevin

-----Original Message-----
From: Raphael Tryster [mailto:[email-masked]]
Sent: Thursday, March 14, 2002 1:37 AM
To: Boyle, Kevin [NCRTP:3Z30:EXCH]; Blatherwick, Peter; Taylor, Tom-PT

Raphael Tryster 

-----Original Message----- 
From: Blatherwick, Peter [mailto:[email-masked]] 
Sent: Tuesday, March 12, 2002 4:56 PM 
To: Taylor, Tom-PT [CAR:B800:EXCH]; Boyle, Kevin [NCRTP:3Z30:EXCH]; 

  
-- Peter 

-----Original Message----- 
From: Boyle, Kevin [NCRTP:3Z30:EXCH] 
Sent: Tuesday, March 12, 2002 2:07 PM 
To: Blatherwick, Peter; 'Dan Elbert'; Taylor, Tom-PT [CAR:B800:EXCH]; 
megaco 

-----Original Message----- 

on a very brief scan).    

-- Peter 
  
-----Original Message----- 

needed. 

-----Original Message----- 

Hi 

is not defined.