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

From: [email-masked]
Date: Tue, 16 Dec 2003 11:53:15 +0530

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.

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:

> Hi all,
> Could someone pls. answer my question?
>
> Thanks,
> Sampath
>
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Sampath Komanduri
> Sent: Monday, November 24, 2003 5:46 PM
> To: [email-masked]
> Subject: [Megaco] Descriptor processing on Termination OOS
>
>
> Hi,
> What should be the descriptors state when a termination is service
> changed to state OOS?
> Is it ok to remove all the descriptors that are currently applied on the
> termination or
> should MG keep the information of descriptors so that they can be
> re-applied if the termination comes to in-service state again.
>
> Thanks,
> Sampath
>
>
> _______________________________________________
> Megaco mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/megaco
>
>
> _______________________________________________
> Megaco mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/megaco
>

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

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

---

From: [email-masked]
Date: Tue, 16 Dec 2003 19:33:23 +0530

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

To:    megaco_maillist@HSS, "'Tom Taylor'" <[email-masked]>
cc:    <[email-masked]>

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

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of [email-masked]
> Sent: Tuesday, December 16, 2003 11:53 AM
> To: Tom Taylor
> Cc: [email-masked]
>       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
> 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.

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.

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

So given this, IMO we don't have to make any assumption about the
descriptor state once its taken OOS.

> The descriptors (aside from TerminationState) remain
> unchanged until either the MGC changes them or the MG
> undergoes a cold restart.
>
> Sampath Komanduri wrote:
>
> > Hi all,
> > From: [email-masked] [mailto:[email-masked]]
> On Behalf
> > Of Sampath Komanduri
> > changed to state OOS? Is it ok to remove all the
> descriptors that are
> > currently applied on the termination or

---

From: [email-masked]
Date: Tue, 16 Dec 2003 19:33:23 +0530

Hi

---

From: "Kevin Boyle" <[email-masked]>
Date: Tue, 16 Dec 2003 12:19:38 -0500

Comments inline [KJBII]

Kevin 

-----Original Message-----
From: [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]

Hi

"Anil Jangam \(anilj\)" <[email-masked]>@ietf.org on 12/16/2003 01:33:27 PM

> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of [email-masked]
> 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
> 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.
>
> 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.

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

---

From: "Kevin Boyle" <[email-masked]>
Date: Wed, 17 Dec 2003 11:19:17 -0500

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

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:

> 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
> > valid behaviour of MG. For example if the card containing the  > 
> termination is jacked out of the chasis then definately at the  > 
> > be a major disconnect wrt descriptors state if MGC does not audit 
> the  > termination since if  MGC were to audit the termination then
>  > this condition if the card is jacked-in and termination is made  > 
>  > 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 
> [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.
> 
> 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.
> 
> 
> applicable to only certain call scenarios (e.g. POTS call) and not for 
> other scenarios (like Trunkling).
> 
> 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.
> 
> 
>  > Tom Taylor <[email-masked]>@ietf.org on 12/01/2003  > 
> 11:52:03 PM  >
>  > The descriptors (aside from TerminationState) remain unchanged 
> until  > either the MGC changes them or the MG undergoes a cold restart.
>  >
>  > Sampath Komanduri wrote:
>  >
>

---

From: "Kevin Boyle" <[email-masked]>
Date: Wed, 17 Dec 2003 11:19:17 -0500

Kevin 

-----Original Message-----
From: Christian Groves [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]

Hello,

Regards, Christian