Subject: [Megaco] Signal Descriptor Doubts

From: mukta vasudeva <[email-masked]>
Date: Mon, 6 Jan 2003 14:00:07 +0000 (GMT)

hi ,

Hope everyone had a good Christmas and will have a wonderfull new year ahead.

I have some doubts related to Signal Descriptor handling.

1. 

  RFC Section 7.1.11 states that

“Production of a Signal on a Termination is stopped by application of 

   a new Signals Descriptor, or detection of an Event on the Termination .”

Also,

“A new Signals Descriptor replaces any existing Signals Descriptor.”

Q: The MG maintains the current signal descriptor until a 

new descriptor is not sent by the MGC. But, after the termination 

finishes the  playout of the signal or an event is detected and the

 signals are stopped, the signal descriptor remains the current one

 with MG until new one is received as according to the rules we cannot remove it until new signal descriptor is received.

 But my doubt is why should we maintain this descriptor since it has already become deactivated(either by finishing playout or event stopped it) and MGC cannot instruct MG to use it further ??.

Thanks ,

regards ,

Mukta Vasudeva

Catch all the cricket action. Download Yahoo! Score tracker

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Mon, 6 Jan 2003 09:29:32 -0500

This is more or less the same question Alan Chou raised a week ago.  It's
not something I ever thought about, but here is the situation as I see it:
  -- the Signals Descriptor remains unchanged, even if the signal(s) it
describes have been terminated
  -- the MG is required to maintain the knowledge of which signals have been
terminated and which have not
  -- we have no way in general to indicate on audit which signals have
completed and which have not.  This was probably a mistake in design.

-----Original Message-----
From: mukta vasudeva [mailto:[email-masked]] 
Sent: Monday, January 06, 2003 9:00 AM
To: [email-masked]
Subject: [Megaco] Signal Descriptor Doubts

hi ,
Hope everyone had a good Christmas and will have a wonderfull new year
ahead.
I have some doubts related to Signal Descriptor handling.
1. 
  RFC Section 7.1.11 states that
"Production of a Signal on a Termination is stopped by application of 
   a new Signals Descriptor, or detection of an Event on the Termination ."
 
Also,
"A new Signals Descriptor replaces any existing Signals Descriptor."
 
Q: The MG maintains the current signal descriptor until a 
new descriptor is not sent by the MGC. But, after the termination 
finishes the  playout of the signal or an event is detected and the
 signals are stopped, the signal descriptor remains the current one
 with MG until new one is received as according to the rules we cannot
remove it until new signal descriptor is received.
 But my doubt is why should we maintain this descriptor since it has already
become deactivated(either by finishing playout or event stopped it) and MGC
cannot instruct MG to use it further ??.

Thanks ,
regards ,
Mukta Vasudeva

 Catch all the cricket action. Download Yahoo! Score tracker
_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

---

From: Raphael Tryster <[email-masked]>
Date: Tue, 14 Jan 2003 08:41:29 +0200

Kevin Boyle, answering my question a year ago, saw it differently.

Raphael Tryster

[The next sentence is Kevin's reply.]

This has been discussed in the past, and the latter alternative (that is,
the current value of the descriptor) was agreed to be the proper response,
if my memory serves.
Kevin
-----Original Message-----
From:	Raphael Tryster [mailto:[email-masked]]
<mailto:[mailto:[email-masked]]> 
Sent:	Wednesday, February 13, 2002 8:29 AM
To:	[email-masked] <mailto:[email-masked]> 
Subject:	[Megaco] Auditing a signals descriptor

Does the value of a signals descriptor change over time as the signals are
played by the MG?  The practical significance is that when an MG receives an
AuditValue command asking for the signals descriptor, should it return the
last value of the signals descriptor as sent by the MGC, or the set of
currently playing and future signals, which may be empty if all the signals
have completed?
If this is still an open question, I would vote for the latter alternative,
because: 
Perhaps this is related to the case of auditing a descriptor that had
over-or under-specified parameters.  I expect that in this case the MG would
return just the values it has chosen, and not the entire original
descriptor.
Raphael Tryster 

	-----Original Message-----
	From:	Christian Groves [SMTP:[email-masked]]
	Sent:	Tuesday, 14 January, 2003 2:14 AM
	To:	Tom-PT Taylor
	Cc:	'mukta vasudeva'; 'Alan Chou'; [email-masked]
	Subject:	Re: [Megaco] Signal Descriptor Doubts

	G'Day Tom,

	I pretty much see it as you have described. I don't think there is a
big
	overhead in keeping the signal descriptor. You certainly need to be
able to keep
	it for the period of time whilst the signal is playing. So whilst it
not optimal
	I don't think its an error either.

	Regards, Christian

---

From: Raphael Tryster <[email-masked]>
Date: Tue, 14 Jan 2003 08:41:29 +0200

Raphael Tryster

	-----Original Message-----
	From:	Christian Groves [SMTP:[email-masked]]
	Sent:	Tuesday, 14 January, 2003 2:14 AM
	To:	Tom-PT Taylor
	Cc:	'mukta vasudeva'; 'Alan Chou'; [email-masked]
	Subject:	Re: [Megaco] Signal Descriptor Doubts

	G'Day Tom,

	Regards, Christian

---

From: "Kevin Boyle" <[email-masked]>
Date: Tue, 14 Jan 2003 14:26:55 -0500

So, I hunted back through the archives to ensure that my memory was in tune
with the reality of what was decided.  The first discussion I saw in about
this my archives of the list occurred from late June through mid-July 2000.
The outcome of the discussion was that the MG should return what is
currently "playing" and what is remaining to be "played".
 
Now, that being said, I personally do not have strong feelings one way or
the other on this.  If implementation experience has shown that it is better
to return the previously set descriptor, rather than the "current"
descriptor, then perhaps we should change.  This would also depend on how
many implementations are working in this fashion already.
 
Kevin

-----Original Message-----
From: Raphael Tryster [mailto:[email-masked]] 
Sent: Tuesday, January 14, 2003 1:41 AM
To: Christian Groves; Taylor, Tom-PT [CAR:5N00:EXCH]
Cc: 'mukta vasudeva'; 'Alan Chou'; [email-masked]; Boyle, Kevin
[NCRTP:3R90:EXCH]
Subject: RE: [Megaco] Signal Descriptor Doubts

Raphael Tryster 

Kevin 
-----Original Message----- 
From:   Raphael Tryster  <mailto:[mailto:[email-masked]]>
[mailto:[email-masked]] 
Sent:   Wednesday, February 13, 2002 8:29 AM 
To:      <mailto:[email-masked]> [email-masked] 
Subject:        [Megaco] Auditing a signals descriptor 

Raphael Tryster 

	BM__MailData-----Original Message----- 

	G'Day Tom, 

	I pretty much see it as you have described. I don't think there is a
big 
overhead in keeping the signal descriptor. You certainly need to be able to
keep 
it for the period of time whilst the signal is playing. So whilst it not
optimal 
I don't think its an error either. 

	Regards, Christian 

> From: mukta vasudeva [mailto:[email-masked]
<mailto:[email-masked]> ] 
>    a new Signals Descriptor, or detection of an Event on the Termination
.." 
>  Catch all the cricket action. Download Yahoo! Score tracker 
<https://www1.ietf.org/mailman/listinfo/megaco>  

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

---

From: Raphael Tryster <[email-masked]>
Date: Thu, 16 Jan 2003 12:25:39 +0200

G'Day Christian,

You seem to be agreeing that a signal that has finished playing should not
be returned in reply to an audit.  Are you going further and saying that a
signal that has not yet started playing should also not be returned?  Or do
you agree that the term "active" can be stretched, as Kevin says, to mean
"what is currently playing and what is remaining to be "played"?  In other
words, not dead yet?  I think this is useful.

Raphael Tryster

	-----Original Message-----
	From:	Christian Groves [SMTP:[email-masked]]
	Sent:	Thursday, 16 January, 2003 6:34 AM
	To:	Kevin Boyle
	Cc:	Raphael Tryster; Tom-PT Taylor; 'mukta vasudeva'; 'Alan
Chou'; [email-masked]

	G'Day Kevin and Raphael,

	In v2 the specification already has text on what should happen:-
	7.2.5	AuditValue
	...
	o	To audit a signal the relevant signal list ID and/or signal
ID are provided.
	Only if the signal is active the values of all the signal parameters
are
	returned including: the keepactive indication, signal type,
duration, signal
	completion indication and package defined properties.

	Regards, Christian

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Thu, 16 Jan 2003 08:51:30 -0500

Assuming Lockstep operation:

Event DETECTION is done on the basis of the EventBufferDescriptor.  That
puts detected events into a queue, along with the time each was detected.

When a new Events Descriptor is activated, successive events in the queue
are processed until one generates a notification (i.e. is RECOGNIZED).  The
processed events are removed from the queue, so I'm not sure what you mean
about them being kept around for the whole call.

> From: Alan Chou [mailto:[email-masked]] 
> Sent: Thursday, January 16, 2003 1:46 AM
> To: 'Christian Groves'; Boyle, Kevin [NCRTP:3Z40:EXCH]
> Cc: 'Raphael Tryster'; Taylor, Tom-PT [CAR:5N00:EXCH]; 'mukta 
> vasudeva'; [email-masked]
> 　　Hi all，
> 　　 Shall MG maintain the active state for the event, 
> according the section 7.1.9 Events Descriptor:
> 　　When the MG receives a command with a new EventsDescriptor, one or
> 　　   more events may have been buffered in the EventBuffer in 
> the MG. The
> 　　   value of EventBufferControl then determines how the MG 
> treats such
> 　　   buffered events.
> 　　
> 　　   Case 1
> 　　
> 　　   If EventBufferControl equals LockStep and the MG receives a new
> 　　   EventsDescriptor it will check the FIFO EventBuffer and take the
> 　　   following actions:
> 　　
> 　　   1. If the EventBuffer is empty, the MG waits for 
> detection of events
> 　　      based on the new EventsDescriptor.
> 　　
> 　　   2. If the EventBuffer is non-empty, the MG processes the 
> FIFO queue
> 　　      starting with the first event:
> 　　
> 　　      a) If the event in the queue is in the events listed 
> in the new
> 　　         EventsDescriptor, the MG acts on the event and removes the
> 　　         event from the EventBuffer.  The time stamp of the 
> Notify shall
> 　　         be the time the event was actually detected.  The 
> MG then waits for
> 　　         a new EventsDescriptor. .....
> 　　according the above, shall we think that the new event 
> description should active only one time detection ?  If MG 
> detect the event which was defined in event description, 
> shall MG set the event to inactive, treat the subsequent 
> detection for this event as invalid detection.
> 　　It will affect the implementation for event detect, since 
> MG will use the separate resource for some event detection, 
> if does'nt maintain the active state, MG will keep the 
> resource along with the call in the whole time, that's not a good way.
> 　　Alan Chou
> 　　
> --------------------------------------------------------------
> ----------
> 　　Huawei Technologies Co, Ltd.
> 　　3rd floor Luneng Building, No. 1 Shangdi 6th Street,
> 　　Haidian district,  Beijing, China 100085
> 　　Fax      : +86 (0)10 82882937
> 　　Phone  : +86 (0)10 82882599
> 　　E-mail  : [email-masked]
> 　　Web    : http://www.huawei.com
> 　　
> --------------------------------------------------------------
> ----------
> 　　
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Christian Groves
> Sent: Thursday, January 16, 2003 12:34 PM
> To: Kevin Boyle
> 　　o	To audit a signal the relevant signal list ID and/or signal ID
> are provided.
> 　　Only if the signal is active the values of all the signal 
> parameters are

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Thu, 16 Jan 2003 08:51:30 -0500

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Thu, 16 Jan 2003 08:58:40 -0500

I should have looked before making my original reply.  Anyway, I would agree
with the interpretation that the aufdit reports all events currently being
played or not yet played.  I think that's what we intended, and, more to the
point, that seems to be the most useful.

-----Original Message-----
From: Raphael Tryster [mailto:[email-masked]] 
Sent: Thursday, January 16, 2003 5:26 AM
To: Christian Groves; Boyle, Kevin [NCRTP:3Z40:EXCH]
Cc: Raphael Tryster; Taylor, Tom-PT [CAR:5N00:EXCH]; 'mukta vasudeva'; 'Alan
Chou'; [email-masked]

G'Day Christian, 

-----Original Message----- 
From:   Christian Groves [SMTP:[email-masked]] 
Sent:   Thursday, 16 January, 2003 6:34 AM 
To:     Kevin Boyle 
Cc:     Raphael Tryster; Tom-PT Taylor; 'mukta vasudeva'; 'Alan Chou';
[email-masked] 

G'Day Kevin and Raphael, 

In v2 the specification already has text on what should happen:- 
7.2.5   AuditValue 
... 
o       To audit a signal the relevant signal list ID and/or signal ID are
provided. 
Only if the signal is active the values of all the signal parameters are 
returned including: the keepactive indication, signal type, duration, signal

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Thu, 16 Jan 2003 08:58:40 -0500

-----Original Message-----
From: Raphael Tryster [mailto:[email-masked]] 
Sent: Thursday, January 16, 2003 5:26 AM
To: Christian Groves; Boyle, Kevin [NCRTP:3Z40:EXCH]
Cc: Raphael Tryster; Taylor, Tom-PT [CAR:5N00:EXCH]; 'mukta vasudeva'; 'Alan
Chou'; [email-masked]

G'Day Christian, 

-----Original Message----- 
From:   Christian Groves [SMTP:[email-masked]] 
Sent:   Thursday, 16 January, 2003 6:34 AM 
To:     Kevin Boyle 
Cc:     Raphael Tryster; Tom-PT Taylor; 'mukta vasudeva'; 'Alan Chou';
[email-masked] 

G'Day Kevin and Raphael,