Subject: Re: Can MGC modify term in NULL Context ?

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 11 Sep 2000 17:17:26 -0400

There is text that says:
   When a provisioned Termination is Subtracted from a context, its
   property values shall revert to:
   * the default value, if specified for the property and not
     overridden by provisioning,
   * otherwise, the provisioned value.

So if it was provisioned, that is the value it reverts to.

Of course I think this is a small problem because it is
unpredictable.  The MGC does not know if the MG has provisioned
some value.  It has no way to find out, short of looking at the
value after cold start and seeing if it is different from the
package defined value.  If different, it could assume provisioning overrode
the package defined default.  If it was the same,
it doesn't really know, but the effect is roughly the same,
so long as the MG causes a ServiceChange if in fact it
is provisioned, and the provisioned value changed while there
was an active control association.

This means there is no point in having a package defined
default value -- the MGC must always audit, so that it can
figure out what value the property will revert to when the
termination is Subtracted.

As a practical matter:
        Default values defined in packages are (as of that
                change "last spring") meaningless
        All values must be audited upon startup
        All changes in provisioning when an active control
                association exists must be followed by
                a ServiceChange command from MG to MGC

Now, the REAL hard problem is failover of the MGC.  The
new MGC takes over an MG which could have terminations that
are in a context.  It has no idea what values they will assume
when the termination is subtracted.  Therefore, as a
practical matter, it must issue a Modify in Null Context in
the same transaction as the Subtract to set them to a value
it is comfortable with.  We better hope there are no
parameters that will "glitch" doing this, as it is not
possible to have the change be atomic.

In general, given the revert-to-default-or-provisioned rule,
I expect every Subtract will need to do this unless the MGC
knows that the default-or-provisioned value is what it wants
the value to be.  So, the rule is that you audit and save
that value.  When you Subtract, you compare the saved
value to what you want it to be.  If those are the same,
no Modify is needed.  If they differ, you put the Modify
as the next command following the Subtract in the Transaction.
If you are the failed over MGC, you always use the Modify
In this case you can never actually discover the provisioned
value unless you can safely "test" it by putting it a Context,
Subtracting it, and THEN auditing.

Not pretty, but at least it works (except for the glitch
possibility).  I liked the other way.

Brian

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, September 11, 2000 2:30 AM
> To: Rosen, Brian
> Subject: Re: Can MGC modify term in NULL Context ?
>
>
>
>
> Hi,
>
> >> Now we have defined "default" to be what the package definition
> >>says it should be.
>
> Does 'default' refer to values as defined in packages...or do
> they refer to the
> values as provisioned on the termination ( by lets say an
> operator sitting on
> MG). For eg. when Tom mentioned that the correct way to deal
> with the Echo
> Cancellation problem was to set the provisioned value to
> 'off' for that
> termination, isnt it obvious that a termination would revert
> back to this
> 'provisioned' value after subtarct rather than the default
> 'on' as mentioned in
> the package?
>
> Or does this provisioned value becomes default for it?
>
> Thanx and regards,
> Sandy G
>
>
>
>
> "Rosen, Brian" <[email-masked]> on 09/09/2000 02:26:22 AM
>
> Please respond to "Rosen, Brian" <[email-masked]>
>
> To:   [email-masked]
> cc:    (bcc: Sandeep Gautam/HSS)
>
> Subject:  Re: Can MGC modify term in NULL Context ?
>
>
>
>
>
> Now we have defined "default" to be what the package definition
> says it should be.
>
> Let's take, for example, tdmc/ec.  Suppose the MGC wanted to
> "permanently"
> disable echo cancel on a termination.  It sets
> tdmc/ec off in null context, and it stays off, unless the MGC
> turns it on for a particular call.
>
> I don't believe we ever changed that behavior, so somehow we
> screwed up the words.  Here is what the text used to say:
>
> "When a Termination is created, properties get their default
> values, unless
> the controller specifically sets a different value.  The
> default value of a
> property of a physical Termination can be changed by setting it to a
> different value when the Termination is in the null Context.
> Every time
> such a Termination returns to the null Context, the values of
> its properties
> are reset to this default value"
>
> Brian
>
> > -----Original Message-----
> > From: Tom-PT Taylor [mailto:[email-masked]]
> > Sent: Friday, September 08, 2000 3:35 PM
> > To: [email-masked]
> > Subject: Re: Can MGC modify term in NULL Context ?
> >
> >
> > Sorry, I have to contradict you on the second item.  See
> the last few
> > sentences of section 7.2.3.
> >
> > > -----Original Message-----
> > > From: Rosen, Brian [mailto:[email-masked]]
> > > Sent: Friday, September 08, 2000 2:36 PM
> > > To: [email-masked]
> > > Subject: Re: Can MGC modify term in NULL Context ?
> > >
> > >
> > > > The question is that does the MG allow the MGC to change
> > the package
> > > > property values associated with a termination in NULL context ??
> > > For a physical termination, yes, absolutely
> > >
> > > >
> > > > And, if the answer is yes does this change the default values of
> > > > the package properties associated with the termination.
> > > > OR, does it only modify the properties temporarily for
> now. If the
> > > > termination is subsequently added and subtracted to and from
> > > > a context,
> > > > respectively the property values change to the default values
> > > > before MGC modified them in NULL context.
> > > It changes the current value, and the termination returns to
> > > this value when it is subtracted.  You can think of this as
> > > changing the default value, although it's volatile.
> > >
> > > Brian
> > >
> >
>
>
>
>
>
>

---

From: Paul Hollis <[email-masked]>
Date: Tue, 12 Sep 2000 09:34:13 +1100

G'day,

I must admit I liked it the way it used to be, when the MGC was allowed to
modify the default value while it was in the NULL context. This way the MGC was
in control. Now the MGC doesn't know, unless it does audits, or explicitly sets
the value while doing ADDs. It seems there is no point in having default values
any more.

Regards Paul.