Subject: [Megaco] Query about local control descriptor properties

From: [email-masked]
Date: Tue, 22 Jan 2002 19:13:40 +0530

Hi Tom & list,

RFC 3015 Section 7.1.7 LocalControl Descriptor mentions:

"If the MGC wishes to delete some information from the existing descriptor, it
merely resends the
   descriptor (in a Modify command) with the unwanted information stripped out."

Does the "unwanted information" refer to the properties which the MGC no more
requires to be set on the termination......

Please reply back...

Thanks,
Kapil Nayar

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

---

From: [email-masked]
Date: Wed, 23 Jan 2002 19:34:17 +0530

Hi Christian

Does it boil down to that MGC wants the excluded properties to be "reset" (made
NULL or switched OFF).
Example:
gain control is a provisioned value, and assuming this value is provisioned at
MG to be 20.
MGC explicitly mentions the value to be (tdmc/gain =40) in a local control
descriptor.
MG sets it to 40.
MGC deletes the property (tdmc/gain) from the local control descriptor.
MG sets it to 0.
Is this correct ?

Thanks,
-Kapil Nayar

Christian Groves <[email-masked]> on 01/23/2002 06:09:27 AM

To:   megaco ietf <[email-masked]>
cc:    (bcc: Kapil Nayar/HSS)

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

Hello Kapil,

Yes that applies the properties which the MGC doesn't want anymore.

Regards, Christian

---

From: [email-masked]
Date: Wed, 23 Jan 2002 19:34:17 +0530

Hi Christian

Thanks,
-Kapil Nayar

Hello Kapil,

Regards, Christian

---

From: "Tom-PT Taylor"<[email-masked]>
Date: Wed, 23 Jan 2002 16:23:59 -0500

The answer to your question is yes, (and I didn't receive Christian's
similar answer) but I am a bit worried about whether it is clear how this
works.  

(1) What it does it mean if ReserveValue is unspecified in a modified
descriptor?  I would think it means that ReserveValue reverts to default
(i.e. false).

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

(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.

(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.

So: anyone else want to tackle this?  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, January 22, 2002 8:44 AM
To: [email-masked]'
Subject: [Megaco] Query about local control descriptor properties

Hi Tom & list,

"If the MGC wishes to delete some information from the existing descriptor,
it
merely resends the
   descriptor (in a Modify command) with the unwanted information stripped
out."

Does the "unwanted information" refer to the properties which the MGC no
more
requires to be set on the termination......

Please reply back...

Thanks,
Kapil Nayar

---

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

Some thoughts (in line) on the following:-

>unexpected effects if they persist beyond that call.  What do other people

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).

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

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

---

From: "Tom-PT Taylor"<[email-masked]>
Date: Tue, 29 Jan 2002 11:00:40 -0500

This seems like a practical solution for LocalControl, but if we accept it,
we have to change the text of the Recommendation, meaning that it only holds
for H.248v2.  I'll note that we have a real problem of interoperability
here.  My previous note on the interpretation of this clause presented three
alternatives, and I got E-mails (one private) in support of all three of
them.  

I don't quite see Wayne's point on the Signals and Events descriptors.  In
both cases, the semantics of the situation require the repetition of all of
the signals/events you want to keep.  You also need at least the KeepActive
parameter where it applies to signals.  Are you saying, Wayne, that once an
event or signal is specified, then if it is retained in replacement
descriptors it is unnecessary to respecify all the parameters that went
along with it the first time?  I could live with that as an IG
clarification.  Other views?

-----Original Message-----
From: Chuong N. Nguyen [mailto:[email-masked]]
Sent: Tuesday, January 29, 2002 9:40 AM
To: [email-masked]'
Subject: Re: [Megaco] Query about local control descriptor properties

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. 
  
Wayne Cutler wrote: 
  
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
-- 
  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: "Wayne Cutler" <[email-masked]>
Date: Wed, 30 Jan 2002 08:52:38 +0000

Tom Taylor wrote:-
>clarification.  Other views?

On second thoughts, I think you're right and the MGC would require to
always explicitly change/repeat Events & Signals. So, my comment applies
only to Properties. Having raised the comment against Properties, I then
incorrectly applied it to Events/Signals
to common the rules up across the different descriptors.

Wayne.

------------

---

From: "Wayne Cutler" <[email-masked]>
Date: Wed, 30 Jan 2002 08:52:38 +0000

Tom Taylor wrote:-

Wayne.

------------