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

From: "Kevin Boyle" <[email-masked]>
Date: Fri, 4 Oct 2002 14:16:22 -0400

As Tom quoted, "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." (Emphasis mine)

So, I do not believe that further indication of a particular descriptor
failing is required if the command failed from the outset. (That is to say,
you don't need to send a signal failure if the add command carrying the
signals descriptor failed anyway).

Kevin

-----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
_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

---

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

Hello Kevin

Thanks for the reply.
But, what if the ADD command had both event descriptor
and signal descriptor. How does the MGC come to know
what caused the failure of the command and what are
the events active on the termination and whether the
new signals were played or not.

regards
-shri
 --- Kevin Boyle <[email-masked]> wrote: >
As Tom quoted, "If a command fails, the MG shall AS
> FAR AS POSSIBLE restore
> --- Tom-PT Taylor <[email-masked]> wrote:
> >

---

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

Hello Kevin

Thanks for the reply.

regards
-shri