Subject: RE: [Megaco] Descriptor processing on Termination OOS

From: Raphael Tryster <[email-masked]>
Date: Sun, 9 May 2004 11:28:43 +0200

Two questions related to the discussion below:

Firstly, the quote below from H.248.1 6.2.4 seems to contradict section
7.1.11, which states:

"Production of a Signal on a Termination is stopped by application of a new
SignalsDescriptor, or detection of an Event on the Termination".

What about returning to the null context?  According to 6.2.4, the signal
should stop, whereas according to 7.1.11, it should not stop.  Unless the
resetting of descriptors to default values when returning to the null
context is considered to be a case of application of a new
SignalsDescriptor?  But then what do we do about on/off type signals, e.g.
visual message waiting indicator?  Surely they are meant to survive
subtraction from a context?

My second question concerns the requirement that the MG maintain
terminations in contexts until the MGC explicitly subtracts them.  Consider
a distributed MG, in which the part that talks to the MGC does not
completely control the part that allocates resources such as IP address and
UDP port for local descriptors.  Suppose some administrative action or fault
causes these resources to become physically unavailable to the termination
with which they were associated.  The MG informs the MGC (or fails to do so
if the MGC didn't request the event), but for some reason the MGC does not
issue a Subtract.  The front end of the MG has no problem complying with
Megaco rules: it will accept any commands it can on that context, and send a
proper rejection if the cleanup that has taken place in the back end makes
it impossible to comply with a request.  However, if the MGC audits the
local descriptor, the MG front end will send an IP address and UDP port that
the back end may already be reusing for another call.  The MGC can then
presumably do bad things with this outdated information.  Which of the
following are legitimate solutions to this problem?

a)	The MGC is at fault for ignoring indications from the MG that
something went wrong.

b)	The MG is at fault for being schizophrenic.  It must prevent reuse
of all resources associated with the context until it receives Subtract.

c)	The MG can sidestep the problem.  It is only required to keep the
termination in the context, but it can clear the local descriptor.  (And
what if the MGC doesn't audit but relies on its memory?)

d)	There is no problem.  The MGC cannot do anything bad with the
information.

Raphael Tryster

	-----Original Message-----
	From:	Kevin Boyle [SMTP:[email-masked]]
	Sent:	Wednesday, 17 December 2003 18:19
	To:	Christian Groves; [email-masked]; [email-masked]
	Cc:	[email-masked]; Tom-PT Taylor; [email-masked]
	Subject:	RE: [Megaco] Descriptor processing on Termination
OOS

	Right.  I just wanted to ensure that everyone understands that the
reset of the descriptors is a result of the SUBTRACT, and not a result of
the SERVICECHANGE.

	Subtle, but important, difference. 

	Kevin 

	-----Original Message----- 
	From: Christian Groves [ mailto:[email-masked]
<mailto:[email-masked]> ] 
	Sent: Tuesday, December 16, 2003 6:05 PM 
	To: Boyle, Kevin [NCRTP:3Z40:EXCH]; [email-masked];
[email-masked] 
	Cc: [email-masked]; Taylor, Tom-PT [CAR:5N00:EXCH];
[email-masked] 
	Subject: Re: [Megaco] Descriptor processing on Termination OOS 

	Hello, 

	OOS Service by its nature must be reported by a ServiceChange, this
can be through Forced which states: At a minimum, the Termination shall be
subtracted from the Context. Graceful is similar that the MGC is expected to
"clean up" the termination ultimately by subtracting the termination.

	So for ephemeral terminations there's no discussion as they'll
disappear the MGC won't be able to do anything to them. For physical
terminations the following rule applies:

	H.248.1 6.2.4 Termination properties and descriptors .... 
	If not provisioned otherwise, the properties in all descriptors
except TerminationState and LocalControl default to empty/"no value" when a
Termination is first created or returned to the null Context.

	... 

	This text is very clear when a termination goes back to the NULL
context which for TDM terminations is the result of going "out of service"
the descriptors ARE changed.

	I can remember that this behaviour caused quite a bit of discussion
at the time (I think Tom drafted the text) and it was felt that this was the
best behaviour because it left terminations in a known state both for the MG
and MGC.

	Regards, Christian 

	Kevin Boyle wrote: 

	> Comments inline [KJBII] 
	> 
	> Kevin 
	> 
	> -----Original Message----- 
	> From: [email-masked] [ mailto:[email-masked]
<mailto:[email-masked]> ] 
	> Sent: Tuesday, December 16, 2003 9:03 AM 
	> To: [email-masked] 
	> Cc: [email-masked]; Taylor, Tom-PT [CAR:5N00:EXCH]; 
	> [email-masked] 
	> Subject: RE: [Megaco] Descriptor processing on Termination OOS 
	> 
	> 
	> 
	> 
	> 
	> Hi 
	>       Please find my comments embedded.[BVS]. 
	> Regards 
	> Venkat 
	> 
	> 
	> 
	> 
	> 
	> "Anil Jangam \(anilj\)" <[email-masked]>@ietf.org on 12/16/2003 
	> 01:33:27 PM 
	> 
	> Please respond to <[email-masked]> 
	> 
	> Sent by:    [email-masked] 
	> 
	> 
	> To:    megaco_maillist@HSS, "'Tom Taylor'"
<[email-masked]> 
	> cc:    <[email-masked]> 
	> 
	> Subject:    RE: [Megaco] Descriptor processing on Termination OOS 
	> 
	> 
	> 
	> 
	>  > -----Original Message----- 
	>  > From: [email-masked] [ mailto:[email-masked]
<mailto:[email-masked]> ] On 
	> Behalf  > Of [email-masked]  > Sent: Tuesday,
December 
	> 16, 2003 11:53 AM  > To: Tom Taylor  > Cc: [email-masked]  >
Subject: 
	> Re: [Megaco] Descriptor processing on Termination OOS  >  >  >  >
>  
	> >  > Hi 
	>  >       In my opinion keeping the descriptors alive and enabled
for a 
	>  > termination which is in Out of Service state does not seems to
be a  
	> > valid behaviour of MG. For example if the card containing the  >

	> termination is jacked out of the chasis then definately at the  > 
	> hardware level all the events and signals get disabled.  There
would  
	> > be a major disconnect wrt descriptors state if MGC does not
audit 
	> the  > termination since if  MGC were to audit the termination
then 
	>  > MG would be returning empty   descriptors in this particular 
	>  > case.  Now  in 
	>  > this condition if the card is jacked-in and termination is made
> 
	> in-service then the exact state of original descriptors no more
holds  
	> > good and mgc needs to apply the descriptors again. 
	>  > 
	>  >       Hence for a termination which is in Out-of-Service state
MGC can 
	>  > fairly assume that all descriptors are no more valid and
whenever 
	> the  > termination comes up will reapply the descriptors afresh.
This  
	> > assumption holds true whether or not termination is involved in
a  > 
	> call. 
	> 
	> First thing, there is no provision for the MG to change the state
of 
	> the descriptor by its own. If we see the commands that can change
the 
	> descriptor state, these are commands which MGC initiate. 
	> 
	> [BVS] I agree with you from the protocol perspective. But, if you 
	> analyse the actual scenario, service change (to out-of-service)
for a 
	> termination would mean disabling operations such as signals/
events/ 
	> streams. Further, this would mean that MG does take some action on
its 
	> own when it generates a Service Change (or MGC sends a service
change) 
	> on the termination. 
	> 
	> If MG returns the descriptors in Audit response it would mean 
	> incorrect representation of facts to MGC. 
	> 
	> [KJBII] The MG may not take action on its own, whether we are
talking 
	> about a hardware failure or some other occurrence.  The text is 
	> explicit: the MG may not reset those descriptors.  If the MGC
wanted 
	> to audit, it may very well be to collect diagnostic data.  If the
MG 
	> wipes them out, then that data is lost. 
	> 
	> In the SVC with SVCMethod = forced, its mentioned that MGC is
going to 
	> clean up the context, in which case it is to subtract the
termination 
	> from the cotext. At this point MGC can reset the descriptor state
to 
	> the default if necessary. Same logic can be applied when the
SVCMethod 
	> is graceful. 
	> 
	> [BVS] Cleaning up the context using subtract is OK for
terminations in 
	> a valid context. But, what about the terminations which are
already in 
	> the null context. 
	> 
	> [KJBII] What about them?  Modifies are allowed on OOS
terminations.  
	> The MGC could very well send a modify to empty the descriptors. 
	> 
	> 
	> In the call flows as well, when the termination is coming back
into 
	> the service, normally a Modify is sent to MG initializing the
term. 
	> 
	> 
	> [BVS] Based upon our experience in the interop events, this MODIFY
is 
	> applicable to only certain call scenarios (e.g. POTS call) and not
for 
	> other scenarios (like Trunkling). 
	> 
	> Moreover, it is not used for clean up operations (like empty
Signal 
	> descriptor, empty media descriptor etc.), but for the call setup
(like 
	> event descriptor with OffHook). 
	> 
	> [KJBII]  MGCs that do not reset the state of the descriptors upon 
	> return to service will be subject to its own problems.  It seems
to me 
	> that the MGC would want to make sure the descriptors are in a 
	> particular state by explicitly making them that way.  Further, I
know 
	> of several implementations that send empty descriptors in Modify 
	> commands.  Any assumption that they are not used for normal call 
	> processing operations is deficient. 
	> 
	> 
	> So given this, IMO we don't have to make any assumption about the 
	> descriptor state once its taken OOS. 
	> 
	>  > 
	>  > Regards 
	>  > Venkat 
	>  > 
	>  > 
	>  > 
	>  > 
	>  > 
	>  > Tom Taylor <[email-masked]>@ietf.org on 12/01/2003
> 
	> 11:52:03 PM  > 
	>  > Sent by:    [email-masked] 
	>  > 
	>  > 
	>  > To:    Sampath Komanduri <[email-masked]> 
	>  > cc:    [email-masked] 
	>  > 
	>  > Subject:    Re: [Megaco] Descriptor processing on Termination
OOS 
	>  > 
	>  > 
	>  > The descriptors (aside from TerminationState) remain unchanged 
	> until  > either the MGC changes them or the MG undergoes a cold
restart. 
	>  > Sampath Komanduri wrote: