Subject: RE: [Megaco] State of the termination after failure of a command.

From: "Tom-PT Taylor" <[email-masked]>
Date: Fri, 4 Oct 2002 11:49:34 -0400

Your basic point is independent of implementation (i.e. exactly when and in
what order your three phases are executed).  I think you are saying that
aside from the error descriptor identifying why the command failed, you
would like to see additional information identifying the side effects (if
any) of the attempted execution.  What would the MGC do with this
information?

> -----Original Message-----
> From: SHRI KUMAR [mailto:[email-masked]] 
> Sent: Friday, October 04, 2002 1:58 AM
> To: Taylor, Tom-PT [CAR:B602:EXCH]; 'Anil Jangam'; [email-masked]
> Subject: RE: [Megaco] State of the termination after failure 
> of a command.
> 
> 
> Hello Tom
> 
> I have a different opinion on "restoring the state in
> a stateless protocol".
> When a command is processed, 2 types of operations may
> be done by the MG - 
> 1st validate the command against any invalid or
> unsupported parameters and 
> 2nd process the validated command. 
> Processing the validated command further contains 2
> types of operation components - database operations
> and real-time operations.
> The descriptor processing as defined in the protocol -
> signal application, event detection, media - are not
> just database operations. In all probability these
> will result in real-time operations - new signal desc 
> processing results in stopping active signals and starting 
> new signals, new event desc processing results in stopping 
> detection of active events/ emptying event buffers/ start 
> detection of new events.
> 
> Typically, validation operations would not result in
> any state change. And, it seems logical to define
> restoration of state for database extensive operations
> like, if ADD command fails move back the termination
> to Null context or if MOVE command fails move back the 
> termination to the old context. 
> 
> However, it is not legible to define the restoration
> or back rolling of real-time states, like if one of
> the new signals failed stop all new signals and replay
> old signals. I think it is more appropriate to have
> additional error codes which define the real-time
> failures at the descriptor level when a command fails.
> e.g.
> ADD command failure should result in the termination
> back into Null Context. But, failure of any associated
> signal application should be indicated as an error
> code.
> 
> Any comments?
> 
> rgds
> -shri
> --- Tom-PT Taylor <[email-masked]> wrote: >
> The relevant passage in section 8 does happen to be
> > in the paragraph which
> > starts out talking about commands marked optional,
> > but we intended it to
> > apply in all cases:
> > 
> > "If a command fails, the MG shall as far as possible
> > restore the state that
> > existed prior to the attempted execution of the
> > command before continuing
> > with command processing."
> > 
> > Maybe this should be in a separate paragraph in
> > future editions to make the
> > intent clear.
> > 
> > > -----Original Message-----
> > > From: Anil Jangam [mailto:[email-masked]]
> > > Sent: Thursday, October 03, 2002 8:22 AM
> > > To: [email-masked]
> > > Subject: [Megaco] State of the termination after
> > failure of a command.
> > > 
> > > 
> > > Hi list,
> > > 
> > > What shold be the state of the Termination in MG
> > when a
> > > command execution failes due to some reason. Its
> > clearly
> > > defined in case of OPTIONAL commands, that MG
> > shall restore
> > > it to the state that existed before the command
> > was executed
> > > on the Termination. But in case of NON-OPTINAL
> > commands, is
> > > it recommanded to restore the state of a
> > termination, in case
> > > of command failure?? or is it implied to do so??
> > > 
> > > regds,
> > > /anil.
> > > 
> > >
> >
> *********************************************************
> > > Disclaimer
> > > 
> > > This message (including any attachments) contains
> > > confidential information intended for a specific 
> > > individual and purpose, and is protected by law. 
> > > If you are not the intended recipient, you should 
> > > delete this message and are hereby notified that 
> > > any disclosure, copying, or distribution of this
> > > message, or the taking of any action based on it, 
> > > is strictly prohibited.
> > > 
> > >
> >
> *********************************************************
> > > Visit us at http://www.mahindrabt.com
> > > 
> > > 
> > > _______________________________________________
> > > Megaco mailing list
> > > [email-masked] https://www1.ietf.org/mailman/listinfo/megaco
> > > 
> > _______________________________________________
> > Megaco mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/megaco
> 
> ______________________________________________________________
> __________
> Missed your favourite TV serial last night? Try the new, Yahoo! TV.
>        visit http://in.tv.yahoo.com
> 
_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

---

From: SHRI KUMAR <[email-masked]>
Date: Mon, 7 Oct 2002 05:26:46 +0100 (BST)

Hello Tom

Thanks for the reply.
From the MGC point of view, what should be the normal
behavior if a command fails. This is important because
the protocol:
1. Allows multiple operations - signals, events etc.
in the same command.
2. Doesnot make it mandatory for any explicit
restoration of state for events, signals.
3. Does not allow substantial information in the
command reply (failure case) for the MGC to know the
exact state of the termination after failure occured.

I may be wrong but are the following - possible
scenarios for an MGC in case of failed command:
- Audit the MG to obtain the current state of the
termination.
- Clear any call that it was trying to MODIFY, by
sending SUBTRACT.
- Restart the termination to restore the original
state of all descriptors.
- Try sending another MODIFY whereby it deletes all
active descriptors (state clearing by sending an empty
event desc/ empty signal desc/ empty media desc etc.)
and explicitly activates only the required descriptor
(e.g. non-empty signal descriptor and all other empty
descriptors).
The bottomline is that termination at MG may be in a
state which is inconsistent with that at MGC. MGC is
the master and therefore it needs to either clear the
state or be aware of what is going on at the MG. 

Please clarify?
Regards
-shri
 
> >        visit http://in.tv.yahoo.com

________________________________________________________________________

---

From: SHRI KUMAR <[email-masked]>
Date: Mon, 7 Oct 2002 05:26:46 +0100 (BST)

Hello Tom

Thanks for the reply.

Please clarify?
Regards
-shri

---

From: "Anil Jangam" <[email-masked]>
Date: Mon, 07 Oct 2002 15:33:09 +0530

Hi Team & Shri,

I think it is clear now taht there is no way to find out during execution of
which descriptor the command failed (assuming a command contains more than
one descriptor)?. This is sufficient to say that whichever descriptor fails,
we have to restore the state of the termination (even if the certain
descriptor execution was successful).
This is again by virtue of the fact that all the descriptor(s) in the
command are relative to the given commad and probably to each other (correct
me if wrong). Hence failure of any descriptor irrespective of the execution
state of other descriptors in that command is to be treated as failure of
the whole command and NOT  that descriptor alone. This shall effectively
restore the state of the termination -- Tom's very first answer to this
thread.

/anil.

----- Original Message -----
From: "SHRI KUMAR" <[email-masked]>
To: "Tom-PT Taylor" <[email-masked]>; "'Anil Jangam'"
<[email-masked]>; <[email-masked]>
Sent: Monday, October 07, 2002 10:19 AM
Subject: RE: [Megaco] State of the termination after failure of a command.

---

From: "Anil Jangam" <[email-masked]>
Date: Mon, 07 Oct 2002 15:33:09 +0530

Hi Team & Shri,

/anil.

---

From: SHRI KUMAR <[email-masked]>
Date: Tue, 8 Oct 2002 05:34:00 +0100 (BST)

Hello Anil

Please see my responses embedded.

Regards
-shri
 --- Anil Jangam <[email-masked]> wrote: > Hi
Team & Shri,
> one descriptor)?. 
{shri} I am wondering how did you get a clarity on
that? If we introduce error codes to indicate
descriptor level failures (which I think we already
have for a few cases), we can surely find out which
descriptor caused the command failure.
> This is sufficient to say that
> whichever descriptor fails,
{shri} Well, we need to explicitly define what
restoration of a termination state means. It could
mean if ADD fails, restore the termination back to
Null context, if MOVE fails restore the termination
back to original context. I am in agreement on this
restoration of state. But, as already indicated it is
illegible to talk of restoring real-time operations,
like stop the new signals which were successfully
played out.

> the whole command and NOT  that descriptor alone.
{shri} I agree with your statement. Now, on similar
terms if you assess multiple commands in an action,
the commands are relative to each other. But, when a
command fails, the protocol allows reporting success
for all commands already executed and failure for the
current failed command. MEGACO does not expect
restoration of the context state to that before the
execution of the action. This same treatment should be
metted out to the descriptors in a command.
 
> This shall effectively
> > > Your basic point is independent of
> implementation
> > > (i.e. exactly when and in
> > > what order your three phases are executed).  I
> think
> > > you are saying that
> > > aside from the error descriptor identifying why
> the
> > > command failed, you
> > > would like to see additional information
> identifying
> > > the side effects (if
> > > any) of the attempted execution.  What would the
> MGC
> > > do with this
> > > information?
> > >
> > > > To: Taylor, Tom-PT [CAR:B602:EXCH]; 'Anil
> Jangam';
> > > [email-masked]
> > > > I have a different opinion on "restoring the
> state
> > > in
> > > > a stateless protocol".
> > > > When a command is processed, 2 types of
> operations
> > > may
> > > > be done by the MG -
> > > > Processing the validated command further
> contains
> > > 2
> > > > signal application, event detection, media -
> are
> > > not
> > > > will result in real-time operations - new
> signal
> > > desc
> > > > processing results in stopping active signals
> and
> > > starting
> > > > new signals, new event desc processing results
> in
> > > stopping
> > > > Typically, validation operations would not
> result
> > > in
> > > > to Null context or if MOVE command fails move
> back
> > > the
> > > > or back rolling of real-time states, like if
> one
> > > of
> > > > the new signals failed stop all new signals
> and
> > > replay
> > > > failures at the descriptor level when a
> command
> > > fails.
> > > > e.g.
=== message truncated ===

---

From: SHRI KUMAR <[email-masked]>
Date: Tue, 8 Oct 2002 05:34:00 +0100 (BST)

Hello Anil

Regards
-shri

---

From: "Anil Jangam" <[email-masked]>
Date: Tue, 08 Oct 2002 13:45:01 +0530

pl. see inline comments headed with <anil>.

regds,
/anil.

----- Original Message -----
From: "SHRI KUMAR" <[email-masked]>
To: "Anil Jangam" <[email-masked]>; <[email-masked]>
Sent: Tuesday, October 08, 2002 10:14 AM
Subject: Re: [Megaco] State of the termination after failure of a command.

> descriptor caused the command failure.

<anil> May be the statment "there is no way" is not correct in this context,
but have to see how the error reporting will be flexible enough to report
various descriptor failure cases. As Kevin have mentioned we shall
investigate futher to add more related error codes.

> like stop the new signals which were successfully
<anil> IMO, there shall not be a special treatment to the real-time
operations under failure conditions. In any case, all the operations
(including real-time and non real-time) shall be terminated and be restored
to the previous state of the given termination. Then only we can say that
the state of the Termination is restored fully. This shall further ensure
consistency of the termination state between both MG and MGC.

> metted out to the descriptors in a command.
<anil> If you see the megaco protocol structure, then command is the basic
construct/unit of it, whereas descriptors are used to realise the command.
You will see that each command has different set of descriptors used in it.
So when any descriptor fails, then its the failure of the command as whole.
What you are exploring is to relate the various commands in the action (and
hence the same treatment), is not correct. A failure of a command can not be
treated as failure of an action. Hence there is no need to restore the state
of a context.

Tom and Kevin, may I request some more clarification on this from your end?

---

From: "Anil Jangam" <[email-masked]>
Date: Tue, 08 Oct 2002 13:45:01 +0530

regds,
/anil.