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

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.

	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.

---

From: Terry L Anderson <[email-masked]>
Date: Mon, 21 Oct 2002 08:07:52 -0400

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.  

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.

Raphael Tryster wrote:

> 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:
>
>             (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
>
>
>       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
>       This means that the error code returned can give an indication
>       of what was
>       to be a hint rather than something totally reliable (there is
>       likely to be

-- 

------------------------------------------------------------
Terry L Anderson          mailto:[email-masked]
Tel:+1 908 766 4463
http://www.gti.net/tla

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

---

From: Terry L Anderson <[email-masked]>
Date: Mon, 21 Oct 2002 08:07:52 -0400

--

---

From: "Anil Jangam" <[email-masked]>
Date: Mon, 21 Oct 2002 19:34:57 +0530

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.

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.

/anil.

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

  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:

      Events = 2223 { 

                  }, 

                  } 
          } 
  } 

  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. 

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

---

From: "Anil Jangam" <[email-masked]>
Date: Mon, 21 Oct 2002 19:34:57 +0530

/anil.

  ----- Original Message ----- 
  From: Raphael Tryster 
  To: Tom-PT Taylor ; 'Anil Jangam' ; [email-masked] 
  Cc: SHRI KUMAR ; Kevin Boyle 
  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

---

From: "Anil Jangam" <[email-masked]>
Date: Mon, 21 Oct 2002 20:00:40 +0530

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.

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

> notify in any other appropriate way (if events are set) about any sort
[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???

/anil.

---

From: "Anil Jangam" <[email-masked]>
Date: Mon, 21 Oct 2002 20:00:40 +0530

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.