Re: Descriptor processing on Termination OOS
Christian Groves <christian.groves <at> ericsson.com>
2004-06-07 00:10:21 GMT
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:christian.groves <at> ericsson.com]
> Sent: Friday, 28 May 2004 7:09
> To: Raphael Tryster
> Cc: 'Kevin Boyle'; bvswamy <at> hss.hns.com; anilj <at> cisco.com;
> Tom-PT Taylor; megaco <at> ietf.org
> 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
> >
> >
> > -----Original Message-----
> > From: Kevin Boyle [SMTP:kboyle <at> nortelnetworks.com]
> > Sent: Wednesday, 17 December 2003 18:19
> > To: Christian Groves; bvswamy <at> hss.hns.com;
> anilj <at> cisco.com
> > Cc: megaco_maillist <at> hss.hns.com; Tom-PT Taylor;
> megaco <at> ietf.org
> > 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
> >
> > -----Original Message-----
> > From: Christian Groves [
> mailto:Christian.Groves <at> ericsson.com]
> > Sent: Tuesday, December 16, 2003 6:05 PM
> > To: Boyle, Kevin [NCRTP:3Z40:EXCH]; bvswamy <at> hss.hns.com;
> > anilj <at> cisco.com
> > Cc: megaco_maillist <at> hss.hns.com; Taylor, Tom-PT
> [CAR:5N00:EXCH];
> > megaco <at> ietf.org
> > Subject: Re: [Megaco] Descriptor processing on
> Termination OOS
> >
> > 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
> > >
> > > -----Original Message-----
> > > From: bvswamy <at> hss.hns.com [ mailto:bvswamy <at> hss.hns.com]
> > > Sent: Tuesday, December 16, 2003 9:03 AM
> > > To: anilj <at> cisco.com
> > > Cc: megaco_maillist <at> hss.hns.com; Taylor, Tom-PT
> [CAR:5N00:EXCH];
> > > megaco <at> ietf.org
> > > Subject: RE: [Megaco] Descriptor processing on
> Termination OOS
> > >
> > >
> > >
> > >
> > >
> > > Hi
> > > Please find my comments embedded.[BVS].
> > > Regards
> > > Venkat
> > >
> > >
> > >
> > >
> > >
> > > "Anil Jangam \(anilj\)" <anilj <at> cisco.com> <at> ietf.org on
> 12/16/2003
> > > 01:33:27 PM
> > >
> > > Please respond to <anilj <at> cisco.com>
> > >
> > > Sent by: megaco-admin <at> ietf.org
> > >
> > >
> > > To: megaco_maillist <at> HSS, "'Tom Taylor'"
> > <taylor <at> nortelnetworks.com>
> > > cc: <megaco <at> ietf.org>
> > >
> > > Subject: RE: [Megaco] Descriptor processing on
> Termination OOS
> > >
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: megaco-admin <at> ietf.org [
> mailto:megaco-admin <at> ietf.org] On
> > > Behalf > Of megaco_maillist <at> hss.hns.com > Sent:
> Tuesday, December
> > > 16, 2003 11:53 AM > To: Tom Taylor > Cc:
> megaco <at> ietf.org >
> > 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 <taylor <at> nortelnetworks.com> <at> ietf.org on
> 12/01/2003 >
> > > 11:52:03 PM >
> > > > Sent by: megaco-admin <at> ietf.org
> > > >
> > > >
> > > > To: Sampath Komanduri <sampathk <at> cisco.com>
> > > > cc: megaco <at> ietf.org
> > > >
> > > > Subject: Re: [Megaco] Descriptor processing on
> > Termination OOS
> > > >
> > > >
> > > > The descriptors (aside from TerminationState)
> remain unchanged
> > > until > either the MGC changes them or the MG
> undergoes a cold
> > restart.
> > > >
> > > > Sampath Komanduri wrote:
> > > >
> > >
> >
>
RSS Feed