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

From: "Tom-PT Taylor" <[email-masked]>
Date: Thu, 3 Oct 2002 09:52:13 -0400

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

---

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?

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

---

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.

to Null context or if MOVE command fails move back the termination to the
old context. 

Any comments?

rgds
-shri
--- Tom-PT Taylor <[email-masked]> wrote: >
The relevant passage in section 8 does happen to be
> in the paragraph which
> > Visit us at http://www.mahindrabt.com

________________________________________________________________________

---

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:
> > > 1st validate the command against any invalid or unsupported 
> > > parameters and 2nd process the validated command.
> > > any state change. And, it seems logical to define restoration of 
> > > state for database extensive
> > operations
> > > additional error codes which define the real-time failures at the 
> > > descriptor level when a command
> > fails.
> > > e.g.
> > > > 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
> > > > > 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
> > > > > it to the state that existed before the
> > command
> > > > was executed

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 8 Oct 2002 09:55:59 -0400

As a first point: if signal playout was triggered by a command which then
failed, the MG must stop signal playout as part of the process of restoring
the previous state.  Thus there is no need to audit to see if a signal is
still playing.  Of course, any playout of the signal which has occurred will
mislead the far end, but the far end should be able to cope with error
situations.

As a second point, section 7.2 (first para) contains the statement:
 "The descriptors SHALL be processed in the order in which they 
   appear."

This means that the error code returned can give an indication of what was
processed already when the command failed.  In practice, I would expect this
to be a hint rather than something totally reliable (there is likely to be
ambiguity), but the requirement is there.

Finally, there is an IANA process for registration of new error codes.  If
you see the need of one, document it in an RFC and register it.

> Sent: Tuesday, October 08, 2002 4:27 AM
> To: [email-masked]
> Cc: Taylor, Tom-PT [CAR:B602:EXCH]; SHRI KUMAR; Boyle, Kevin 
> [NCRTP:3R90:EXCH]
> Importance: High
> pl. see inline comments headed with <anil>.
> 
> regds,
> /anil.
> 
> To: "Anil Jangam" <[email-masked]>; <[email-masked]>
> Sent: Tuesday, October 08, 2002 10:14 AM
> > 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.
> 
> <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.
> 
> > > This is sufficient to say that
> > > whichever descriptor fails,
> > > descriptor execution was successful).
> > {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.
> >
> <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.
> 
> > > 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.
> > {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.
> >
> <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?
> 
> > > This shall effectively
> > > restore the state of the termination -- Tom's very
> > > first answer to this
> > > thread.
> > >
> > > /anil.
> > >
> > > > > 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: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 8 Oct 2002 09:55:59 -0400

---

From: Raphael Tryster <[email-masked]>
Date: Mon, 21 Oct 2002 13:47:06 +0200

The recent part of this thread refers to a signal being stopped because some
other descriptor in the command failed.  I would like to turn the question
around, and ask, what happens to the rest of the command if the signal
descriptor fails?  Let me ask this in a general and a specific way:

General:  Are there some descriptors whose failure has no impact on the
success or failure of the command in which they appear?
Specific:  Does failure to play a signal cause the command in which the
signal descriptor appears to fail?

I would like to argue that the answers are, respectively, yes and no, and
that failure to play a signal should not fail the containing command.  I am
talking about a hardware or resource failure, not a parsing or logical error
in specifying the signals descriptor.  Consider the following command:

MEGACO/1 [172.16.1.70]:2944
Transaction = 30645 {
	Context = - {
		Modify = [email-masked] {
		Events = 2223 { 
			al/on, dd/ce {DigitMap=Dialplan0}            
               	}, 
		Signals {SL = 1 { cg/dt, cg/bt } },
             DigitMap= Dialplan0{ 
		(0| 00|[1-7]xxx|8xxxxxxx|Fxxxxxxx|Exx|91xxxxxxxxxx|9011x.)}

		}
	}
}

cg/dt is a timeout signal, following which cg/bt shall be played.  I am sure
nobody suggests that the reply to transaction 30645 should be withheld until
the MG verifies that it is able to start playing cg/bt.  Thus, the success
of the command is independent of the success of the second signal.  Now,
logically, why should the first signal be treated any differently from the
others?  Therefore, I would expect the success of the command to be
independent of the success of all signals.

Perhaps for this reason, Megaco allows the MGC to request NotifyCompletion
if it wants to be certain that the signal succeeded.  Otherwise, a signal
descriptor is by definition successful.

Comments please?

Raphael Tryster

	-----Original Message-----
	From:	Tom-PT Taylor [SMTP:[email-masked]]
	Sent:	Tuesday, 08 October, 2002 3:56 PM
	To:	'Anil Jangam'; [email-masked]
	Cc:	SHRI KUMAR; Kevin Boyle
	Subject:	RE: [Megaco] State of the termination after failure
of a command.

	As a first point: if signal playout was triggered by a command which
then
	failed, the MG must stop signal playout as part of the process of
restoring
	the previous state.  Thus there is no need to audit to see if a
signal is
	still playing.  Of course, any playout of the signal which has
occurred will
	mislead the far end, but the far end should be able to cope with
error
	situations.

	This means that the error code returned can give an indication of
what was
	processed already when the command failed.  In practice, I would
expect this
	to be a hint rather than something totally reliable (there is likely
to be
	ambiguity), but the requirement is there.

	Finally, there is an IANA process for registration of new error
codes.  If
	you see the need of one, document it in an RFC and register it.

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Mon, 21 Oct 2002 09:02:59 -0400

It's really a matter of timing: if the attempt to dispatch the signal fails
immediately, then the command has failed.  This leaves a certain amount of
discretion to the implementor.  I address this issue a bit in distinguishing
failures from error events in the Advanced Media Server packages.

There is some relevant text in section 8.2.2 that leans toward your view:
  "A SignalsDescriptor is considered to have been processed when it has 
   been established that the descriptor is syntactically valid, the 
   requested signals are supported and they have been queued to be 
   applied."

-----Original Message----- 
From:   Tom-PT Taylor [SMTP:[email-masked]] 
Sent:   Tuesday, 08 October, 2002 3:56 PM 
To:     'Anil Jangam'; [email-masked] 
Cc:     SHRI KUMAR; Kevin Boyle 
Subject:        RE: [Megaco] State of the termination after failure of a
command.

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Mon, 21 Oct 2002 09:02:59 -0400

-----Original Message----- 
From:   Tom-PT Taylor [SMTP:[email-masked]] 
Sent:   Tuesday, 08 October, 2002 3:56 PM 
To:     'Anil Jangam'; [email-masked] 
Cc:     SHRI KUMAR; Kevin Boyle 
Subject:        RE: [Megaco] State of the termination after failure of a
command.

---

From: "Kevin Boyle" <[email-masked]>
Date: Mon, 21 Oct 2002 10:32:15 -0400

Comments inline. [KJBII]
 
Kevin

-----Original Message-----
From: Anil Jangam [mailto:[email-masked]] 
Sent: Monday, October 21, 2002 10:17 AM
To: Raphael Tryster; Taylor, Tom-PT [CAR:B602:EXCH]; [email-masked]
Cc: SHRI KUMAR; Boyle, Kevin [NCRTP:3R90:EXCH]
Subject: Re: [Megaco] State of the termination after failure of a command.

I feel this more a matter of implementation than a protocol
specification/statement. What is mentioned in the standard is that you
should not start executing the descriptor unless an untill its validated.
The success or failure of the executing them is something depends on the
hardware resource you are using. If the hardware does not support given
signals or events, then you can imidiately raise an exception saying
unsupported parameter.
[KJBII] Agreed. 
 
On the other hand, if your hardware supports the given signal and you start
playing it, and somewhere in the middle or at the end, it returns an error,
then it should be treated as a failure of the execution of the command. In
this case, the state of the termination shall be restored to the previous
state. Thus you can not seperate out the execution of the descriptors from
the execution of the commands. After all commands are made up of the
descriptors only.
[KJBII] As Tom quoted, "A SignalsDescriptor is considered to have been
processed when it has been established that the descriptor is syntactically
valid, the requested signals are supported and they have been queued to be
applied."  Therefore, your assertion is invalid.  Clearly, the success of
the command is NOT relative to the success of signal playout, only the
CAPABILITY of playout of the signal.  It also seems you are making
assumptions about restoration of state.  The spec says that the state shall
be restored "as far as possible".  This means MGCs can not make any
assumptions about the state of the termination if a command fails.
 
/anil.

----- Original Message ----- 
From: Raphael  <mailto:[email-masked]> Tryster 
To: Tom-PT Taylor <mailto:[email-masked]>  ; 'Anil
<mailto:[email-masked]> Jangam' ; [email-masked]
<mailto:[email-masked]>  
Cc: SHRI KUMAR <mailto:[email-masked]>  ; Kevin Boyle
<mailto:[email-masked]>  
Sent: Monday, October 21, 2002 5:28 PM
Subject: RE: [Megaco] State of the termination after failure of a command.

	Events = 2223 { 

                }, 

                } 
        } 
} 

Comments please? 

Raphael Tryster 

	BM__MailData-----Original Message-----

---

From: "Kevin Boyle" <[email-masked]>
Date: Mon, 21 Oct 2002 10:32:15 -0400

Comments inline. [KJBII]
 
Kevin

-----Original Message-----
From: Anil Jangam [mailto:[email-masked]] 
Sent: Monday, October 21, 2002 10:17 AM
To: Raphael Tryster; Taylor, Tom-PT [CAR:B602:EXCH]; [email-masked]
Cc: SHRI KUMAR; Boyle, Kevin [NCRTP:3R90:EXCH]
Subject: Re: [Megaco] State of the termination after failure of a command.

 
/anil.

----- Original Message ----- 
From: Raphael  <mailto:[email-masked]> Tryster 
To: Tom-PT Taylor <mailto:[email-masked]>  ; 'Anil

	Events = 2223 { 

                }, 

                } 
        } 
} 

Comments please? 

Raphael Tryster

---

From: "Kevin Boyle" <[email-masked]>
Date: Mon, 21 Oct 2002 11:12:07 -0400

More comments inline. [KJBII]

Kevin

-----Original Message-----
From: Anil Jangam [mailto:[email-masked]] 
Sent: Monday, October 21, 2002 10:43 AM
To: Terry L Anderson; Raphael Tryster
Cc: Taylor, Tom-PT [CAR:B602:EXCH]; [email-masked]; SHRI KUMAR; Boyle,
Kevin [NCRTP:3R90:EXCH]

Hi Terry,

see inline... headed with [anil].

/anil.

----- Original Message -----
From: "Terry L Anderson" <[email-masked]>
To: "Raphael Tryster" <[email-masked]>
Cc: "Tom-PT Taylor" <[email-masked]>; "'Anil Jangam'"
<[email-masked]>; <[email-masked]>; "SHRI KUMAR"
<[email-masked]>; "Kevin Boyle" <[email-masked]>
Sent: Monday, October 21, 2002 5:59 PM
Subject: Re: [Megaco] State of the termination after failure of a command.

> I am not sure that we would want to make a narrow exception to the 
> general principle just for signals.  I think if any descriptor "fails" 
> then the command fails.  But that being said we DO have to be careful 
> of what is considered a failure.  There are certainly things that can 
> fail about a signal well after the signal has begun playing that I 
> would not consider a error of the descriptor, just as failure of the 
> network is not an error in the Local/Remote descriptors.
>
[anil] I disagree to your approach. I think detecting something that has
failed (say network failure) and doing nothing is of no use. What standard
says about restoring the state of the Termination is the corrective mesures
to be taken in case of the failure conditions. What is you have mentioned
about accepting the descriptor (in other words validating the descriptor) is
just a preventive measure. We have to take some actions when something goes
wrong.
[KJBII] Actually, you don't.  It is the prerogative of the MGC to clean up
after errors as it sees fit.  The MG should "as far as possible" restore the
previous state, and then wait for the MGC to act.  Autonomous cleanup by the
MG will most certainly lead to state mismatches between the MG and MGC.

> In the specific case you raise, I would expect that the MG should 
> "reserve resources" for all signals when it accepts the descriptor.  
> If it has no ability to play cg/bt because it is not implemented or 
> some other resource limit as known at the time the descriptor is 
> received, then I would expect it to return an error failing the entire 
> command.  On the other hand, if (as far as it knows when the 
> descriptor is
> received) it can play them, it should return success immediately and
> notify in any other appropriate way (if events are set) about any sort
> of later failure.
>
[anil] I agree that once the validation (i.e. preventive measure) is done,
you ask for the notification reporting the status of the execution. Say in
the end, the execution of the signal has failed, then we can not leave it as
it is. Take an example of call hold scenario. If you (the controlling leg)
have toggled from one party to other, you would normally remove the hold
tone on held party/termination and play hold tone on the active
party/termination. Now you move from one context to another. Mean time the
removal of the hold tone on the held party has failed, and still you try to
talk to it, then what you (MG) would do???? In this case, can't we call the
above failure condition as failure of the descriptor, and would try to
restore (i.e. corrective measure) the state to the previous state???
[KJBII] You would hook the two parties up, and continue with the service.
If the MGC asked for notification of signal completion for held tone, then
the MG will send that notification to the MGC.  Otherwise, the MG should not
take ANY action on it's own, without explicit direction from the MGC.

/anil.

---

From: "Kevin Boyle" <[email-masked]>
Date: Mon, 21 Oct 2002 11:12:07 -0400

Kevin

-----Original Message-----
From: Anil Jangam [mailto:[email-masked]] 
Sent: Monday, October 21, 2002 10:43 AM
To: Terry L Anderson; Raphael Tryster
Cc: Taylor, Tom-PT [CAR:B602:EXCH]; [email-masked]; SHRI KUMAR; Boyle,
Kevin [NCRTP:3R90:EXCH]

Hi Terry,

/anil.

----- Original Message -----
From: "Terry L Anderson" <[email-masked]>
To: "Raphael Tryster" <[email-masked]>
Cc: "Tom-PT Taylor" <[email-masked]>; "'Anil Jangam'"

/anil.