Subject: RE: [Megaco] Descriptor processing on Termination OOS

From: Raphael Tryster <[email-masked]>
Date: Thu, 10 Jun 2004 19:48:52 +0200

OK, so perhaps VMWI is a bad example for Megaco (it's type OO in MGCP).  But
there must be other OO signals that we wouldn't want to Move to a context
because they may take part in calls while the signal is on.  The sense I am
getting is that OO signals are a feature that Megaco claims to support but
subverts its operation.

Raphael Tryster

	-----Original Message-----
	From:	Kevin Boyle [SMTP:[email-masked]]
	Sent:	Thursday, 10 June 2004 18:44
	To:	Raphael Tryster; 'Christian Groves'
	Cc:	[email-masked]; [email-masked]; Tom-PT Taylor;
[email-masked]
	Subject:	RE: [Megaco] Descriptor processing on Termination
OOS

	VMWI, generally speaking, is a CLASS data message that fires and
forgets.  The switch even refreshes it from time to time.  So, one solution
is to use andisp to send data without alerting to light the lamp.
	 
	Kevin

	  _____  
	
		From: Raphael Tryster [mailto:[email-masked]] 
		Sent: Thursday, June 10, 2004 2:04 AM
		To: 'Christian Groves'
		Cc: Boyle, Kevin [NCRTP:3Z40:EXCH]; [email-masked];
[email-masked]; Taylor, Tom-PT [CAR:5N00:EXCH]; [email-masked]
		Subject: RE: [Megaco] Descriptor processing on Termination
OOS

		Because this termination may wish to be part of many other
contexts while the signal persists, i.e. I can make many calls while the
light on my phone is on, before checking my voice mail.

		Raphael Tryster 

		-----Original Message----- 
		From:   Christian Groves
[SMTP:[email-masked]] 
		Sent:   Thursday, 10 June 2004 2:19 
		To:     Raphael Tryster 
		Cc:     'Kevin Boyle'; [email-masked]; [email-masked];
Tom-PT Taylor; [email-masked] 
		Subject:        Re: [Megaco] Descriptor processing on
Termination OOS 

		If you want VMWI to persist why don't you MOV a termination
to its own context? 

		Christian 

		Raphael Tryster wrote: 

		> So there would be a discontinuity in the signal.  Is that
what real MGCs 
		> do? 
		> 
		> Raphael Tryster 
		> 
		> 
		>       -----Original Message----- 
		>       From:   Christian Groves
[SMTP:[email-masked]] 
		>       Sent:   Monday, 7 June 2004 2:10 
		>       To:     Raphael Tryster 
		>       Cc:     'Kevin Boyle'; [email-masked];
[email-masked]; 
		>       Tom-PT Taylor; [email-masked] 
		>       Subject:        Re: [Megaco] Descriptor processing
on Termination OOS 
		> 
		>       Hello Raphael, 
		> 
		>       A signal's descriptor cannot be sent in a subtract
command. It 
		>       would have to be 
		>       modified in the NULL context. 
		> 
		>       Regards, Christian 
		> 
		>       Raphael Tryster wrote: 
		> 
		>        > Hello Christian, 
		>        > 
		>        > I gather from your reply that in my first
question, 6.2.4 
		>       overrides 
		>        > 7.1.11, and in my second question, it is the
MGC's 
		>       responsibility to 
		>        > avoid inconsistencies.  Does the former mean that
even off/on 
		>       signals 
		>        > terminate on subtraction from a context?
Therefore, if the MGC 
		>       wants 
		>        > something like VMWI to persist, it has to
re-issue it on every 
		>       subtract? 
		>        > 
		>        > Raphael Tryster 
		>        > 
		>        > 
		>        >       -----Original Message----- 
		>        >       From:   Christian Groves 
		>       [SMTP:[email-masked]] 
		>        >       Sent:   Friday, 28 May 2004 7:09 
		>        >       To:     Raphael Tryster 
		>        >       Cc:     'Kevin Boyle'; [email-masked];
[email-masked]; 
		>        >       Tom-PT Taylor; [email-masked] 
		>        >       Subject:        Re: [Megaco] Descriptor
processing on 
		>       Termination OOS 
		>        > 
		>        >       Hello Raphael, 
		>        > 
		>        >       Please see my comments below. 
		>        > 
		>        >       Regards, Christian 
		>        > 
		>        >       Raphael Tryster wrote: 
		>        > 
		>        >        > Two questions related to the discussion
below: 
		>        >        > 
		>        >        > Firstly, the quote below from H.248.1
6.2.4 seems to 
		>       contradict 
		>        >       section 
		>        >        > 7.1.11, which states: 
		>        >        > 
		>        >        > "Production of a Signal on a Termination
is stopped by 
		>        >       application of a 
		>        >        > new SignalsDescriptor, or detection of
an Event on the 
		>        >       Termination". 
		>        >        > 
		>        >        > What about returning to the null
context?  According 
		>       to 6.2.4, the 
		>        >        > signal should stop, whereas according to
7.1.11, it 
		>       should not 
		>        >       stop. 
		>        >        > Unless the resetting of descriptors to
default values 
		>       when 
		>        >       returning to 
		>        >        > the null context is considered to be a
case of 
		>       application of a 
		>        >       new 
		>        >        > SignalsDescriptor?  But then what do we
do about 
		>       on/off type 
		>        >       signals, 
		>        >        > e.g. visual message waiting indicator?
Surely they 
		>       are meant 
		>        >       to survive 
		>        >        > subtraction from a context? 
		>        > 
		>        >       [CHG] I would assume that by returning a
termination to 
		>       the NULL 
		>        >       context via a 
		>        >       subtract results in a signal being stopped.
6.2.4 says, 
		>       "If not 
		>        >       provisioned 
		>        >       otherwise, the properties in all
descriptors except 
		>        >       TerminationState and 
		>        >       LocalControl default to empty/"no value"
when a 
		>       Termination is 
		>        >       first created or 
		>        >       returned to the null Context. The default
contents of the 
		>       two 
		>        >       exceptions are 
		>        >       described in 7.1.5 and 7.1.7." 7.1.11 talks
about 
		>       replacement 
		>        >       SignalDescriptor 
		>        >       which is effectively what happens when you
return to the 
		>       NULL 
		>        >       context. The 
		>        >       current descriptors are replaced by the
provisioned 
		>       descriptors. 
		>        >       Also 7.1.11 is 
		>        >       not mentioned as an exception. 
		>        > 
		>        >        > 
		>        >        > My second question concerns the
requirement that the 
		>       MG maintain 
		>        >        > terminations in contexts until the MGC
explicitly 
		>       subtracts them. 
		>        >        > Consider a distributed MG, in which the
part that 
		>       talks to the 
		>        >       MGC does 
		>        >        > not completely control the part that
allocates 
		>       resources such 
		>        >       as IP 
		>        >        > address and UDP port for local
descriptors.  Suppose some 
		>        >       administrative 
		>        >        > action or fault causes these resources
to become 
		>       physically 
		>        >       unavailable 
		>        >        > to the termination with which they were
associated. 
		>       The MG 
		>        >       informs the 
		>        >        > MGC (or fails to do so if the MGC didn't
request the 
		>       event), 
		>        >       but for 
		>        >        > some reason the MGC does not issue a
Subtract.  The 
		>       front end 
		>        >       of the MG 
		>        >        > has no problem complying with Megaco
rules: it will 
		>       accept any 
		>        >       commands 
		>        >        > it can on that context, and send a
proper rejection if 
		>       the 
		>        >       cleanup that 
		>        >        > has taken place in the back end makes it
impossible to 
		>       comply 
		>        >       with a 
		>        >        > request.  However, if the MGC audits the
local 
		>       descriptor, the 
		>        >       MG front 
		>        >        > end will send an IP address and UDP port
that the back 
		>       end may 
		>        >       already 
		>        >        > be reusing for another call.  The MGC
can then 
		>       presumably do 
		>        >       bad things 
		>        >        > with this outdated information.  Which
of the 
		>       following are 
		>        >       legitimate 
		>        >        > solutions to this problem? 
		>        >        > 
		>        >        >    1. The MGC is at fault for ignoring
indications 
		>       from the MG 
		>        >       that 
		>        >        >       something went wrong. 
		>        >        > 
		>        >        >    2. The MG is at fault for being
schizophrenic.  It 
		>       must 
		>        >       prevent reuse 
		>        >        >       of all resources associated with
the context 
		>       until it 
		>        >       receives 
		>        >        >       Subtract. 
		>        >        > 
		>        >        >    3. The MG can sidestep the problem.
It is only 
		>       required to 
		>        >       keep the 
		>        >        >       termination in the context, but it
can clear the 
		>       local 
		>        >        >       descriptor.  (And what if the MGC
doesn't audit but 
		>        >       relies on its 
		>        >        >       memory?) 
		>        >        > 
		>        >        >    4. There is no problem.  The MGC
cannot do anything 
		>       bad with 
		>        >       the 
		>        >        >       information. 
		>        > 
		>        >       [CHG] I would suggest that if the MG has
experienced a 
		>       problem 
		>        >       with the 
		>        >       termination that it send a generic cause
event indicating 
		>       failure. 
		>        >       It the MGC 
		>        >       doesn't request this event then the
designers must 
		>       understand the 
		>        >       consequences. 
		>        >       Also if there is a more terminal failure a
servicechange 
		>       could be 
		>        >       sent. 
		>        >        > Raphael Tryster 
	
_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

---

From: Christian Groves <[email-masked]>
Date: Tue, 15 Jun 2004 12:28:08 +1000

Hello Raphael,

It sounds to me that you are looking for a mechanism to maintain continuity of 
signals, events etc when Subtracting a termination back to the NULL context. The 
behaviour of properties, signals and events etc is to revert to default (unless 
otherwise provisioned) when going back to the NULL context. A mechanism to 
override this behaviour would be needed. I could see it taking the form a the 
capability of carrying local/remote/localcontrol/signals and events descriptors 
in Subtract in H.248.1v3. I'd still like to see some concrete examples before 
going down this route.

Regards, Christian

Raphael Tryster wrote:

> OK, so perhaps VMWI is a bad example for Megaco (it's type OO in MGCP).  
> But there must be other OO signals that we wouldn't want to Move to a 
> context because they may take part in calls while the signal is on.  The 
> sense I am getting is that OO signals are a feature that Megaco claims 
> to support but subverts its operation.
> 
> Raphael Tryster
> 
>       Subject:        RE: [Megaco] Descriptor processing on Termination OOS
> 
>       forgets.  The switch even refreshes it from time to time.  So, one
>       solution is to use andisp to send data without alerting to light
>       the lamp.
> 
>        
>       Kevin
> 
> 
>         _____  
> 
>             Subject: RE: [Megaco] Descriptor processing on Termination OOS
> 
>             contexts while the signal persists, i.e. I can make many
>             calls while the light on my phone is on, before checking my
>             voice mail.
> 
>             Raphael Tryster
> 
> 
>             From:   Christian Groves [SMTP:[email-masked]]
>              >        > 7.1.11, and in my second question, it is the MGC's
>              >       responsibility to
>              >        > avoid inconsistencies.  Does the former mean
>             that even off/on
>              >       signals
>              >        >        > "Production of a Signal on a
>             Termination is stopped by
>              >        >       application of a
>              >        >        > signal should stop, whereas according
>             to 7.1.11, it
>              >       should not
>              >        >       stop.
>              >        >       subtract results in a signal being
>             stopped. 6.2.4 says,
>              >       "If not
>              >        >       provisioned
>              >        >       described in 7.1.5 and 7.1.7." 7.1.11
>             talks about
>              >       replacement
>              >        >       SignalDescriptor
>              >        >        > MGC (or fails to do so if the MGC
>             didn't request the
>              >       event),
>              >        >       but for
>              >        >        > has taken place in the back end makes
>             it impossible to
>              >       comply
>              >        >       with a
>              >        >        > request.  However, if the MGC audits
>             the local
>              >       descriptor, the
>              >        >       MG front
>              >        >        > end will send an IP address and UDP
>             port that the back
>              >       end may
>              >        >       already
>              >        >        >       termination in the context, but
>             it can clear the
>              >       local