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

From: Raphael Tryster <[email-masked]>
Date: Mon, 7 Jun 2004 07:53:12 +0200

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: Thu, 10 Jun 2004 10:19:21 +1000

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

Christian

Raphael Tryster wrote:

>       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
>        > 7.1.11, and in my second question, it is the MGC's
>       responsibility to
>        >        > What about returning to the null context?  According
>       to 6.2.4, the
>        >        > SignalsDescriptor?  But then what do we do about
>       on/off type
>        >       signals,
>        >        > e.g. visual message waiting indicator?  Surely they
>       are meant
>        >       to survive
>        >       [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
>        >       LocalControl default to empty/"no value" when a
>       Termination is
>        >       first created or
>        >        > My second question concerns the requirement that the
>       MG maintain
>        >        > 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
>        >        > to the termination with which they were associated. 
>       The MG
>        >       informs the
>        >        > some reason the MGC does not issue a Subtract.  The
>       front end
>        >       of the MG
>        >        > be reusing for another call.  The MGC can then
>       presumably do
>        >       bad things
>        >        > with this outdated information.  Which of the
>       following are
>        >       legitimate
>        >        >    1. The MGC is at fault for ignoring indications
>       from the MG
>        >       that
>        >        >       something went wrong.
>        >        >
>        >        >       of all resources associated with the context
>       until it
>        >       receives
>        >        >       Subtract.
>        >        >