Subject: RE: [Megaco] Query about local control descriptor properties

From: "Wayne Cutler" <[email-masked]>
Date: Thu, 24 Jan 2002 11:43:34 +0000

Some thoughts (in line) on the following:-

>(2) What does it mean if a package-defined property is no longer specified
>in a modified descriptor?  The answer again could be reversion to default,
>or it could mean that the property is absent, or it could mean that the
>property is present but its value is undefined.  Let's look at the
>implications of these three alternatives.

>(a) If a package-defined property is dropped from LocalControl, it takes
on
>the default value specified by the package or provisioned in the MG.  The
>implicit assumption is that the termination continues to support the
>package.  The question in my mind is how long package support continues.
It
>seems to me that, while some packages may be supported for the entire life
>of a termination, others may apply only during a single call and will have
>unexpected effects if they persist beyond that call.  What do other people
>think about this?

I think that Packages are attributes of a termination and so package
support
should continue as long as the termination is present/exists. For example,
if an ephemeral
termination is destroyed, then there is no longer Package support against
that
termination. MGs don't want to know about "calls" and should not IMO make
assumptions
about lifetimes of Packages. To be safe, it seems best to have the MGC be
explicit in
terms of what it wants an MG to do and the MG just gets on with it. I think
that this means
that the MG may end up holding data/attributes that aren't doing any good -
but is also doing
no harm (e.g.  tdm/ec is left at OFF at the end of a call, and would be
switched back on by the
MGC for the next call/connection).

>(b) The dropped property is no longer present on the termination.  To
>support this interpretation we would need to say for every property that
the
>MG tracks its presence/absence as well as its value if present.  This
>approach says nothing about whether we assume that the package continues
to
>be supported on the termination.

Properties are to do with storing data against a termination. So, I'm
confused by the property no longer being "present". Rather, isn't it a case
that the a given property is always present
for an existing termination but may currently hold a null/default value?

>(c) The dropped property is present but its value is undefined.  I find
this
>unappealing.  Like (a), it implies continued support of the parent
package,
>but doesn't have the advantage of a consistent story for physical
>terminations passing to and from the NULL context.

What about an option d) that would regard an absent Property as meaning
"leave the existing value unchanged"?

As a related question, I note that section 7.1.7 (Local Control Desc.)of
the spec.
says that:-

"A new setting of the LocalControl Descriptor completely replaces the
previous setting of that descriptor in the MG.  Thus to retain information
from
the previous setting the MGC must include that information in the new
setting".

Similar statements are made for the Events & Signals Descriptors.

In the case where an MG supports a number of packages, this text is saying
that an MGC
wishing to change data/attributes in one Package in a given Descriptor is
forced to repeat any previous data against any other Packages. This is
perverse. So, can this text be qualified to say that the new Descriptor
replaces only data relating to Packages present in the new/latest message?

Regards,
Wayne.

------------
This e-mail and any attachments are confidential.  If you are not the intended recipient, please notify us immediately by reply e-mail and then delete this message from your system. Do not copy this e-mail or any attachments, use the contents for any purpose, or disclose the contents to any other person: to do so could be a breach of confidence.

_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

---

From: "Chuong N. Nguyen" <[email-masked]>
Date: Tue, 29 Jan 2002 08:39:48 -0600

I agreed w/Wayne on option d which is how it was before v1 came out.

Then we got into these Reserve parameters discussion and changes
but I didn't think the statement should apply to Property parameters.

--
  Alcatel USA, Inc             Internet: [email-masked]
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****

---

From: "Chuong N. Nguyen" <[email-masked]>
Date: Tue, 29 Jan 2002 08:39:48 -0600