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

From: "Kevin Boyle" <[email-masked]>
Date: Mon, 7 Oct 2002 12:42:06 -0400

Further, we have many descriptive error codes that can indicate the command
failure due to a particular descriptor.  If you feel that you need an error
code for a particular scenario, then there are procedures in place to
register new error codes.

Kevin

-----Original Message-----
From: Anil Jangam [mailto:[email-masked]] 
Sent: Monday, October 07, 2002 6:15 AM
To: [email-masked]
Subject: Re: [Megaco] State of the termination after failure of a command.

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.

> 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
>
>  --- Tom-PT Taylor <[email-masked]> wrote:
> > 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
> > >
>
> ______________________________________________________________________
> __
> 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
>

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

---

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

Hello Kevin

I am in full agreement to your proposal for error
codes. But, the exercise and the results should be
part of the protocol definition I assume.

Regards,
-shri

 --- Kevin Boyle <[email-masked]> wrote: >
Further, we have many descriptive error codes that
> can indicate the command
> wrote:
> > > > additional error codes which define the
> real-time 
=== message truncated === 

________________________________________________________________________

---

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

Hello Kevin

Regards,
-shri