Subject: [Megaco] about signallist

From: [email-masked]
Date: Thu, 9 Oct 2003 16:10:05 +0800

Hi all,
        signal descriptor is defined to support parameter "signallist". i 
think that SIGNALLIST is different from other parameters such as 
signalrequest. the process of signallist may last for a long period. My 
question is when to reply MGC? reply immediately or after all sigals in 
signallist are played? if reply immediately, while failure occurs in 
process, how can MG report the failure to MGC? use servicechange? use 
notify? or any other good method?

        thanks!

**********************************************
                 Rui Suying
    SoftSwitch Software Design Department
             Nanjing R&D Center 
                 ZTE Co. China
    Mobile: 13851939625 (China only) 
**********************************************

---

From: Raphael Tryster <[email-masked]>
Date: Thu, 9 Oct 2003 10:35:32 +0200

You may find a discussion in this list from a year ago to be helpful.  I am
copying my question and two of the replies here.  If you like, look in the
archive to find the rest of the thread.

Raphael Tryster

From:	Raphael Tryster [mailto:[email-masked]]
<mailto:[mailto:[email-masked]]>  
Sent:	Monday, October 21, 2002 7:47 AM
To:	Taylor, Tom-PT [CAR:B602:EXCH]; 'Anil Jangam'; [email-masked]
<mailto:[email-masked]> 
Cc:	SHRI KUMAR; Boyle, Kevin [NCRTP:3R90:EXCH]
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:
MEGACO/1 [172.16.1.70]:2944 
Transaction = 30645 { 
		Context = - { 
Modify = [email-masked] <mailto:[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 

From:	Terry L Anderson [SMTP:[email-masked]]
Sent:	Monday, 21 October 2002 14:08
To:	Raphael Tryster
Cc:	Tom-PT Taylor; 'Anil Jangam'; [email-masked]; SHRI KUMAR; Kevin
Boyle
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.  

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.

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

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:	[email-masked] [SMTP:[email-masked]]
	Sent:	Thursday, 9 October 2003 10:10
	To:	[email-masked]
	Subject:	[Megaco] about signallist

	Hi all, 
	        signal descriptor is defined to support parameter
"signallist". i think that SIGNALLIST is different from other parameters
such as signalrequest. the process of signallist may last for a long period.
My question is when to reply MGC? reply immediately or after all sigals in
signallist are played? if reply immediately, while failure occurs in
process, how can MG report the failure to MGC? use servicechange? use
notify? or any other good method? 
	
	        thanks!

---

From: Raphael Tryster <[email-masked]>
Date: Thu, 9 Oct 2003 10:35:32 +0200

Raphael Tryster

	-----Original Message-----
	From:	[email-masked] [SMTP:[email-masked]]
	Sent:	Thursday, 9 October 2003 10:10
	To:	[email-masked]
	Subject:	[Megaco] about signallist

	Hi all, 
	
	        thanks!

---

From: [email-masked]
Date: Thu, 9 Oct 2003 14:33:16 +0530

Hi Rui,
Signal List may play for a long time, so MG should not wait for completion
of all signals in the Signal List before replying to the MGC. Mg should
send reply immediately. If some intermediate signal in the list fails to
play, then MG can inform MGC about this by sending Notify command for
Signal Completion g/sc event with Signal List id, Signal id of the signal
which has terminated and Termination Method as "NC".

Thanks
Ashish.

[email-masked]@ietf.org on 10/09/2003 01:40:05 PM

Sent by:    [email-masked]

To:    [email-masked]
cc:

Hi all,

        thanks!

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

---

From: [email-masked]
Date: Thu, 9 Oct 2003 14:33:16 +0530

Hi Rui,

Thanks
Ashish.

To:    [email-masked]
cc:

Hi all,

        thanks!