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

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

---

From: Christian Groves <[email-masked]>
Date: Wed, 17 Dec 2003 10:04:39 +1100

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:

> 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.
> 
> [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.
> 
> [KJBII] What about them?  Modifies are allowed on OOS terminations.  The 
> MGC could very well send a modify to empty the descriptors.
> 
> 
> 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.
> 
> 
> So given this, IMO we don't have to make any assumption about the 
> descriptor state once its taken OOS.
> 
>  >
>  > Regards
>  > Venkat
>  >
>  >
>  >
>  >
>  >

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

---

From: Christian Groves <[email-masked]>
Date: Wed, 17 Dec 2003 10:04:39 +1100

Hello,

Regards, Christian