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

From: Raphael Tryster <[email-masked]>
Date: Sun, 6 Jun 2004 15:43:37 +0200

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

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:

> 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
> 
> 
>       From:   Christian Groves [SMTP:[email-masked]]
>       Subject:        Re: [Megaco] Descriptor processing on Termination OOS
> 
>       Hello Raphael,
> 
>        > Firstly, the quote below from H.248.1 6.2.4 seems to contradict
>       section
>        > 7.1.11, which states:
>        >
>        > 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. 
>        > 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
>       [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
>       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
>        > 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
>        > 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
>        > 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
>        >    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.
>        >
>        >    3. The MG can sidestep the problem.  It is only required to
>       keep the
>        >       termination in the context, but it can clear the local
>        >    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
>        >
>        >
>        >       From:   Kevin Boyle [SMTP:[email-masked]]
>        >       Sent:   Wednesday, 17 December 2003 18:19
>        >       To:     Christian Groves; [email-masked];
>       [email-masked]
>        >       Cc:     [email-masked]; Tom-PT Taylor;
>       [email-masked]
>        >       Subject:        RE: [Megaco] Descriptor processing on
>       Termination OOS
>        >
>        >       Right.  I just wanted to ensure that everyone understands
>       that the
>        >       reset of the descriptors is a result of the SUBTRACT, and
>       not a
>        >       result of the SERVICECHANGE.
>        >
>        >       Subtle, but important, difference.
>        >
>        >       Kevin
>        >
>        >       From: Christian Groves [
>       mailto:[email-masked]]
>        >       Sent: Tuesday, December 16, 2003 6:05 PM
>        >       To: Boyle, Kevin [NCRTP:3Z40:EXCH]; [email-masked];
>        >       [email-masked]
>        >       Cc: [email-masked]; Taylor, Tom-PT
>       [CAR:5N00:EXCH];
>        >       [email-masked]
>        >       Hello,
>        >       OOS Service by its nature must be reported by a
>       ServiceChange,
>        >       this can be through Forced which states: At a minimum, the
>        >       Termination shall be subtracted from the Context.
>       Graceful is
>        >       similar that the MGC is expected to "clean up" the
>       termination
>        >       ultimately by subtracting the termination.
>        >
>        >       So for ephemeral terminations there's no discussion as
>       they'll
>        >       disappear the MGC won't be able to do anything to them. For
>        >       physical terminations the following rule applies:
>        >
>        >       H.248.1 6.2.4 Termination properties and descriptors ....
>        >       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.
>        >
>        >       ...
>        >
>        >       This text is very clear when a termination goes back to
>       the NULL
>        >       context which for TDM terminations is the result of going
>       "out of
>        >       service" the descriptors ARE changed.
>        >
>        >       I can remember that this behaviour caused quite a bit of
>        >       discussion at the time (I think Tom drafted the text) and
>       it was
>        >       felt that this was the best behaviour because it left
>       terminations
>        >       in a known state both for the MG and MGC.
>        >
>        >       Regards, Christian
>        >
>        >       Kevin Boyle wrote:
>        >
>        >        > Comments inline [KJBII]
>        >        >
>        >        > Kevin
>        >        >
>        >        > From: [email-masked] [ mailto:[email-masked]]
>        >        > Sent: Tuesday, December 16, 2003 9:03 AM
>        >        > To: [email-masked]
>        >        > Cc: [email-masked]; Taylor, Tom-PT
>       [CAR:5N00:EXCH];
>        >        > [email-masked]
>        >        > Subject: RE: [Megaco] Descriptor processing on
>       Termination OOS
>        >        >
>        >        >
>        >        >
>        >        >
>        >        >
>        >        > Hi
>        >        >       Please find my comments embedded.[BVS].
>        >        > Regards
>        >        > Venkat
>        >        >
>        >        >
>        >        >
>        >        >
>        >        >
>        >        > "Anil Jangam \(anilj\)" <[email-masked]>@ietf.org on
>       12/16/2003
>        >        > 01:33:27 PM
>        >        >
>        >        > Please respond to <[email-masked]>
>        >        >
>        >        > Sent by:    [email-masked]
>        >        >
>        >        >
>        >        > To:    megaco_maillist@HSS, "'Tom Taylor'"
>        >       <[email-masked]>
>        >        > cc:    <[email-masked]>
>        >        >
>        >        > Subject:    RE: [Megaco] Descriptor processing on
>       Termination OOS
>        >        >
>        >        >
>        >        >
>        >        >
>        >        >  > From: [email-masked] [
>       mailto:[email-masked]] On
>        >        > Behalf  > Of [email-masked]  > Sent:
>       Tuesday, December
>        >        > 16, 2003 11:53 AM  > To: Tom Taylor  > Cc:
>       [email-masked]  >
>        >       Subject:
>        >        > Re: [Megaco] Descriptor processing on Termination OOS 
>        >  >  >
>        >        >  >
>        >        > >  > Hi
>        >        >  >       In my opinion keeping the descriptors alive and
>        >       enabled for a
>        >        >  > termination which is in Out of Service state does
>       not seems
>        >       to be a
>        >        > > valid behaviour of MG. For example if the card
>       containing the  >
>        >        > termination is jacked out of the chasis then
>       definately at the  >
>        >        > hardware level all the events and signals get
>       disabled.  There
>        >       would
>        >        > > be a major disconnect wrt descriptors state if MGC
>       does not audit
>        >        > the  > termination since if  MGC were to audit the
>       termination then
>        >        >  > MG would be returning empty   descriptors in this
>       particular
>        >        >  > case.  Now  in
>        >        >  > this condition if the card is jacked-in and
>       termination is
>        >       made  >
>        >        > in-service then the exact state of original
>       descriptors no more
>        >       holds
>        >        > > good and mgc needs to apply the descriptors again.
>        >        >  >
>        >        >  >       Hence for a termination which is in
>       Out-of-Service
>        >       state MGC can
>        >        >  > fairly assume that all descriptors are no more
>       valid and
>        >       whenever
>        >        > the  > termination comes up will reapply the descriptors
>        >       afresh. This
>        >        > > assumption holds true whether or not termination is
>       involved
>        >       in a  >
>        >        > call.
>        >        >
>        >        > First thing, there is no provision for the MG to
>       change the
>        >       state of
>        >        > the descriptor by its own. If we see the commands that
>       can
>        >       change the
>        >        > descriptor state, these are commands which MGC initiate.
>        >        >
>        >        > [BVS] I agree with you from the protocol perspective.
>       But, if you
>        >        > analyse the actual scenario, service change (to
>       out-of-service)
>        >       for a
>        >        > termination would mean disabling operations such as
>       signals/
>        >       events/
>        >        > streams. Further, this would mean that MG does take
>       some action
>        >       on its
>        >        > own when it generates a Service Change (or MGC sends a
>       service
>        >       change)
>        >        > on the termination.
>        >        >
>        >        > If MG returns the descriptors in Audit response it
>       would mean
>        >        > incorrect representation of facts to MGC.
>        >        >
>        >        > [KJBII] The MG may not take action on its own, whether
>       we are
>        >       talking
>        >        > about a hardware failure or some other occurrence. 
>       The text is
>        >        > explicit: the MG may not reset those descriptors.  If
>       the MGC
>        >       wanted
>        >        > to audit, it may very well be to collect diagnostic
>       data.  If
>        >       the MG
>        >        > wipes them out, then that data is lost.
>        >        >
>        >        > In the SVC with SVCMethod = forced, its mentioned that
>       MGC is
>        >       going to
>        >        > clean up the context, in which case it is to subtract the
>        >       termination
>        >        > from the cotext. At this point MGC can reset the
>       descriptor
>        >       state to
>        >        > the default if necessary. Same logic can be applied
>       when the
>        >       SVCMethod
>        >        > is graceful.
>        >        >
>        >        > [BVS] Cleaning up the context using subtract is OK for
>        >       terminations in
>        >        > a valid context. But, what about the terminations
>       which are
>        >       already in
>        >        > the null context.
>        >        >
>        >        > [KJBII] What about them?  Modifies are allowed on OOS
>        >       terminations.
>        >        > The MGC could very well send a modify to empty the
>       descriptors.
>        >        >
>        >        >
>        >        > In the call flows as well, when the termination is
>       coming back into
>        >        > the service, normally a Modify is sent to MG
>       initializing the term.
>        >        >
>        >        >
>        >        > [BVS] Based upon our experience in the interop events,
>       this
>        >       MODIFY is
>        >        > applicable to only certain call scenarios (e.g. POTS
>       call) and
>        >       not for
>        >        > other scenarios (like Trunkling).
>        >        >
>        >        > Moreover, it is not used for clean up operations (like
>       empty Signal
>        >        > descriptor, empty media descriptor etc.), but for the
>       call
>        >       setup (like
>        >        > event descriptor with OffHook).
>        >        >
>        >        > [KJBII]  MGCs that do not reset the state of the
>       descriptors upon
>        >        > return to service will be subject to its own
>       problems.  It
>        >       seems to me
>        >        > that the MGC would want to make sure the descriptors
>       are in a
>        >        > particular state by explicitly making them that way. 
>       Further,
>        >       I know
>        >        > of several implementations that send empty descriptors
>       in Modify
>        >        > commands.  Any assumption that they are not used for
>       normal call
>        >        > processing operations is deficient.
>        >        >
>        >        >
>        >        > So given this, IMO we don't have to make any
>       assumption about the
>        >        > descriptor state once its taken OOS.
>        >        >
>        >        >  >
>        >        >  > Regards
>        >        >  > Venkat
>        >        >  >
>        >        >  >
>        >        >  >
>        >        >  >
>        >        >  >
>        >        >  > Tom Taylor <[email-masked]>@ietf.org on
>       12/01/2003  >
>        >        > 11:52:03 PM  >
>        >        >  > Sent by:    [email-masked]
>        >        >  >
>        >        >  >
>        >        >  > To:    Sampath Komanduri <[email-masked]>
>        >        >  > cc:    [email-masked]
>        >        >  >
>        >        >  > The descriptors (aside from TerminationState)
>       remain unchanged
>        >        > until  > either the MGC changes them or the MG
>       undergoes a cold
>        >       restart.
>        >        >  >
>        >        >  > Sampath Komanduri wrote:
>        >        >  >
>        >        >
>        >
>

---

From: Raphael Tryster <[email-masked]>
Date: Thu, 10 Jun 2004 08:03:33 +0200

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?
	>       Sent:   Monday, 7 June 2004 2:10
	>       To:     Raphael Tryster
Termination OOS
	> 
	>       Hello Raphael,
	> 
	>       A signal's descriptor cannot be sent in a subtract command.
It
	>       would have to be
	>        > 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?
	>       contradict
	>        >        > 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
	>        >        > e.g. visual message waiting indicator?  Surely
they
	>       are meant
	>        >       [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
	>       two
	>       NULL
	>        >        > My second question concerns the requirement that
the
	>       MG maintain
	>        >        > Consider a distributed MG, in which the part
that
	>       talks to the
	>       physically
	>        >        > to the termination with which they were
associated. 
	>       The MG
	>       event),
	>        >        > 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
	>       comply
	>        >        > end will send an IP address and UDP port that
the back
	>       end may
	>        >        >    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
	>       required to
	>        >        >    4. There is no problem.  The MGC cannot do
anything
	>       bad with
	>       problem
	>       failure.
	>       could be

---

From: "Kevin Boyle" <[email-masked]>
Date: Thu, 10 Jun 2004 12:43:44 -0400

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

Raphael Tryster 

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

	Christian 

real MGCs 
OOS

---

From: Raphael Tryster <[email-masked]>
Date: Thu, 17 Jun 2004 18:51:11 +0200

Hello Christian,

	Looking at the OO type signals in MGCP, I can't see any others that
one would want to persist past subtraction from a context.  So I'll just
accept the idea that the OO signal in MGCP has no exact equivalent in
Megaco, and that OO and TO signals in Megaco are the same in that both stop
on an event or subtract or new signals descriptor, the only difference being
that TO signals also stop on timeout.

	Raphael Tryster

		-----Original Message-----
		From:	Christian Groves
		Sent:	Tuesday, 15 June 2004 4:28

		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
		> 
		>       Sent:   Thursday, 10 June 2004 18:44
		>       To:     Raphael Tryster; 'Christian Groves'
		>       Cc:     [email-masked]; [email-masked]; Tom-PT
Taylor;
		>       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.

		Clipped the rest of the thread because it's too long.
_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco