Subject: Can MGC modify term in NULL Context ?

From: Kapil Nayar <[email-masked]>
Date: Fri, 8 Sep 2000 22:57:38 +0530

Hi Tom,

6.1 Contexts....para2 mentions
Terminations in the null Context can have their parameters examined
or modified, and may have events detected on them.

6.2.1 Termination Dynamics...mentions
An MGC can only release/modify terminations
and the resources that the termination represents which it has
previously seized via, e.g., the Add command.

The question is that does the MG allow the MGC to change the package
property values associated with a termination in NULL context ??

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.

Kapil Nayar
Hughes Software Systems Ltd.

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 8 Sep 2000 14:35:36 -0400

> property values associated with a termination in NULL context ??
For a physical termination, yes, absolutely

> 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: Tom-PT Taylor <[email-masked]>
Date: Fri, 8 Sep 2000 14:34:45 -0500

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

---

From: Tom-PT Taylor <[email-masked]>
Date: Fri, 8 Sep 2000 15:28:03 -0400

You raise a couple of different issues.  My comments below.

> From: Kapil Nayar [mailto:[email-masked]]
> Sent: Friday, September 08, 2000 1:28 PM
> Subject: Can MGC modify term in NULL Context ?
>
>
> Hi Tom,
>

[PTT] We seem to have a contradiction here.  I think 6.1 identifies the
intent more accurately than what the 6.2.1 quotation seems to imply.  So I'd
say the answer to your question is "yes".  For what it's worth, we show that
sort of operation in Appendix A.

> before MGC modified them in NULL context.

[PTT] We came to the decision that the MGC only temporarily modifies the
properties -- subsequent addition and subtraction restores the defaults.

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 8 Sep 2000 16:56:22 -0400

Wow, looks like we have some ambiguous wording to deal with.
For as long ago as Minneapolis, changing values in Null would
"stick" (that is, those values were the ones the property
went back to on subtract).  This was because the expected
behavior is that the MGC sets the properties to what it wants
them to be once (after registration), and they get back to
these (default) values when 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

> From: Tom-PT Taylor [mailto:[email-masked]]
> Sent: Friday, September 08, 2000 3:35 PM

---

From: Tom-PT Taylor <[email-masked]>
Date: Fri, 8 Sep 2000 22:38:50 -0400

The decision to change the behaviour was made last spring -- it wasn't an
accident.  I can look up the thread if I have to, but the reasoning is that
very often you don't want to restore the status quo ante, particularly where
events and signals are involved.  How we have it now makes MG behaviour much
more predictable.

For your echo cancellor example the sensible solution would be to provision
the default property settings for the trunk when you provision the trunk
itself.

> Sent: Friday, September 08, 2000 4:56 PM

---

From: Tom-PT Taylor <[email-masked]>
Date: Tue, 12 Sep 2000 10:12:07 -0500

My first remark is that one of the first things a programmer learns is to
initialize all variables.  In this context, that means that if you want the
termination to have certain values after it is returned to the NULL context,
set them right away rather than going through any painful process of audit
and reset.

My second point is that there isn't much point grumbling over package
defaults being reset.  At least 90% of the time our packages say "as
provisioned" in any event.

The fact is that provisioned values are going to save the MGC time on
niggling little things like whether this particular trunk circuit should
have a two-wire or four-wire continuity test.  This means it can concentrate
on stuff that varies per-call.

> Sent: Monday, September 11, 2000 5:17 PM
> 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
>
>
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: Monday, September 11, 2000 2:30 AM
> > To: Rosen, Brian
> > Hi,
> > 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]>
> >
> > cc:    (bcc: Sandeep Gautam/HSS)
> >

---

From: Kapil Nayar <[email-masked]>
Date: Wed, 13 Sep 2000 10:40:13 +0530

Hi Tom, Brian

Some confusion is ensuing from the replies......

Do we have a consensus about the following:
1.   Default values are values specified in the packages.
2.   Provisioned values are values configured at MG end.

AND
that we have two options do decide from

Option 1
MGC when modifies termination properties in the NULL context, changes the
default/ provisioned values.
These changes would be made to the package properties associated with the
termination only.
If yes the following questions still remain unanswered:
Do we allow provisioning of the termination properties after MGC modifies them
in the NULL context.?
If yes then how does MGC know about this asynchronous change ? This is because
if MGC doesn't know about the change there is no sanctity of the changes made by
the MGC. (One solution presented was that provisioning should be followed by a
service change)

Option 2
MGC when modifies termination properties in the NULL context, changes the
default/ provisioned values only temporarily. When the termination returns to
the NULL context, default/ provisioned values are restored.
If yes the following questions still remain unanswered:
Do we assume that MGC would audit the properties whenever it establishes an
association with a MG and store a copy of the default/ provisioned values. And,
explicitly send modify for termination properties whenever it needs to change
the termination property values.
Do we allow provisioning of the termination properties at run-time?
If yes then how does MGC know about this asynchronous change ? This is because
if MGC doesn't know about the change there is no sanctity of the audited values
stored by MGC. (One solution presented was that provisioning should be followed
by a service change)

Option 1 seems to be more appropriate, but the unanswered questions need to be
appropriately addressed. We would like to have others views on this.

-Kapil Nayar

Tom-PT Taylor <[email-masked]> on 09/12/2000 08:42:07 PM

Please respond to Tom-PT Taylor <[email-masked]>

To:   [email-masked]
cc:    (bcc: Kapil Nayar/HSS)

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 13 Sep 2000 10:25:25 -0400

This seems to be a case of a change being made in Geneva without a
discussion.  Shame on me for not noticing.

See my responses below marked by [br]

> Sent: Wednesday, September 13, 2000 7:13 AM
> Resonses marked by [PTT].
>
> > Sent: Wednesday, September 13, 2000 1:10 AM
> [PTT] In the packages, and sometimes in the main protocol document.
>
> [PTT] Right.
> [PTT] No. We got rid of that in Geneva (I guess, based on
> Brian's detective
> work).  I may be fuzzy about exactly when, but I can tell you
> why: you could
> get nonsensical results.  In particular, events and signals
> set up in the
> NULL context BEFORE connecting the call would probably make
> no sense at all
> once the connection is dissolved.
[br] the principal followed since the beginning of time here is that
the MGC is in control.  Provisioning is a crutch we use when we don't
have a good answer (my usual quote is "provisioning is evil").  It's
possibly useful in some circumstances BUT, the MGC should be able to
control the gateway where the protocol specifies it should, and provisioning
should NOT override what the MGC wants the gateway to do.  Specifically,
the provisioned value should EVER override the state the MGC wants
the property to be set to.

In this particular issue, you worry about the state of the termination
just before it is added to a context, and specifically, if the MGC wants
it to be in that state just after it is subtracted.  I say, that is up
to the MGC:
        If it wants the state to be the same, then it leaves it in that
                state, and does the add
        If it wants the state to be different, then it changes it just
                before it Adds it, or just after it subtracts it
In no case is it "correct" for it to go to a state not decided by the MGC.

This behavior might affect the "model" you use.  Specifically, depending
on what you want to have happen, this would affect when you create a
context.
Some models have lots of state changes in Null context.  Others create a
context as soon as activity is detected, and make state changes in that
context.  There is no "right" way here, but the behavior discussed on this
thread affects how an MGC may wish to do things.

It's perfectly reasonable to go to some provisioned state upon boot.
That is the only time provisioning should affect an MGC settable parameter.
If the MGC doesn't change it, great.  If it does, the provisioned value is,
at that point, not an interesting value -- the MGC is in control.

> > Do we allow provisioning of the termination properties after
[br]Provisioning is like that.  You can change provisioning while there is
an active control association.

> > the MGC. (One solution presented was that provisioning should
[br]I think the MG should issue a ServiceChange on the affected
terminations,
telling the MGC about them.  I'll refine that slightly in that if the change

doesn't matter to the MGC, the MG need not do it (in particular, if an Audit

wouldn't show any change).

> [PTT] That's how the document reads now.
>
> [PTT] That's a workable strategy.
[br]Well, it's workable only if there are no "glitch" conditions.
If there is a property where a temporary change is significant,
than the MGC cannot control the property (since there is no way
to perform the modify atomically with the subtract).

Of course I think it's the wrong thing to do - provisioning should not
override what the MGC wants the state to be.  I covered this in a prior
message - to retain control, the MGC has to do a modify on every
subtract.

Of course this does not deal with the problem of failover.  This is the
part that is not workable.  The MGC doesn't know what the state will be
if it takes over an MG with post-boot state.

> [PTT] I think the service change would be a good idea.  We
> should look at
> putting this into the Implementor's Guide if it doesn't
> contradict anything
> already in the spec.
[br] I agree

> > Hughes Software Systems Ltd.
[br] I'm not sure what to do at this point.  The change was made without
appropriate discussion, but it is done.  I guess first, I'd like to hear
other opinions on whether they like things the way the documents state,
or the way they were before this change.