Subject: Support of Values in Packages

From: Christian Groves <[email-masked]>
Date: Fri, 25 Aug 2000 07:37:30 +1000

G'Day all,

There has been some confusion at the SG16 on what is supported in
Packages.

The understanding that I had was that: If you support a package you must
support all the signals, properties, events and statistics. However you
do not have to support all the values associated with the properties and
parameters.

Tom mentioned that a thread discussed on the list contravened this.

The reasoning that I have for not having to support all the values is
the following:
o Proliferation of packages. Eg: if a package has a list of tones, and I
must support all the values, if I only want to support a subset of these
values then I need a new package. Therefore you may get the case of a
package "Package Call Progress Tones E.7" where an MG doesn't support
Payphone Recognition Tone because it doesn't have payphones connected to
it. To be compliant with H.248 I can't extend the package because I want
to remove the payphone tone. So a new Package needs to be defined
containing exactly the same information but without the payphone tone.
Now my MG won't support the standard Call Progress Tone package but will
support the XXX_companies_Call_Progress_Tone package. This would lead to
a proliferation of packages.

o Multiple GW support - One MG may not implement all the values of a
property. For something like a list of codecs, a group of resources
associated with the value may be placed in different MG GWs. ie. GSM
codecs in MG1, PCM codecs in MG2. So whilst the MGs support the same
package properties, they can't support a subset of values then you'd
need to define a different package for each MG configuration. Again
leading to a proliferation of packages.

o The MGC knows the PackageID, that all Properties, Signals, Events,
Statistics are supported. In H.248 we have the AuditCapability and
AuditValue commands to find out what actual values of properties are
supported.

So if people agree that not all values in a package need to be supported
I propose to add some text to the implementor's guide:
Section 12.1 after 2nd Paragraph
"A MG SHALL support all Property, Signals & parameters, Events &
parameters and Statistics. A MG MAY support a subset of property and
parameter values defined in the package unless specified in a package."

Cheers, Christian

---

From: Flemming Andreasen <[email-masked]>
Date: Fri, 25 Aug 2000 09:42:06 -0400

Christian Groves wrote:

> support all the signals, properties, events and statistics.

Agreed.

> However you

I guess the term "values" is somewhat prone to interpretation, but I would
tend to disagree if we refer to a list of well-defined values, as e.g. a
list of tone ids in E.7.

> it.

However, in this parcticular example, the tones are both signals and tone
ids, so the effect would be the same. While I'm not particularly fond of the
tonegen package, it does nevertheless illustrate an important point, namely
that the distinction between signals, and parameters to signals (and similar
for other constructs) is somewhat arbitrary. The package really gives you
two things:
1. A name space
2. A convenient grouping of some set of "properties"

If we don't know exaclty what those "properties" are, then we've lost a very
important aspect of packages.

> To be compliant with H.248 I can't extend the package because I want

I agree, but we have to ask ourselves what the idea about packages is.
Simplicity and flexibility are often at odds with each other and in this
case stress the importance of defining packages very carefully.

If I no longer know exactly what is supported in a package, how do I go
about using that package ?

> leading to a proliferation of packages.

Back to defining what "values" mean. Obviously, if we define a "codec"
property in a package, we can't expect support for every possible codec in
the world.

Maybe there's a distinction between supporting values for events, signals,
statistics, and properties ?

> AuditValue commands to find out what actual values of properties are

Not sure how you would do that with event and signal parameters though (come
to think of it, I'm not sure how you, in practice, do that for a lot of
parameters; "The appropriate descriptors, *with the possible values for the
Termination* are returned from AuditCapabilities", Section 7.2.6). On the
other, we could have a new property that looked similar, so it's not clear
it wouldn't apply there either.

> parameter values defined in the package unless specified in a package."

I don't want to deflate the package concept to the extent this would seem to
allow, but I agree there's an issue here. Further discussion is needed
before we make any change.

-- Flemming

--
Flemming Andreasen
Cisco Systems

---

From: Christian Groves <[email-masked]>
Date: Sat, 26 Aug 2000 05:12:48 +1000

G'Day Flemming,

At least we agree there's an ambiguity here. I do agree with you about
the Tone Packages where Properties and signals are blurred and the here
you would support all the values. That's why in my clarification I
mentioned that a package may mandate support of all values. I also agree
that there's a need for clarification on what auditing Signals means.

Could you elaborate on how we would be deflating the package concept by
clarifying the Values are optional?

How I saw it handled was that if a Package Defined Prop = val1, val2,
val3 and a MG supported P =v1, v3 the if the MGC tried to set prop =
val2 then it would receive unsupported property in reply. I didn't see
this would cause people major problems.

Cheers, Christian

---

From: Flemming Andreasen <[email-masked]>
Date: Fri, 25 Aug 2000 18:54:35 -0400

Christian Groves wrote:

> mentioned that a package may mandate support of all values.

OK, I understood it differently. All you want, is the ability to define a package,
and in that package you then specify that which values are optional and which are
mandatory ?

> I also agree

My main concern is having MG A and MG B both support package P and yet my MGC
doesn't know what they actually implement. So far, it would simply be defined by
whatever is defined in package P and interoperability becomes very simple. We now
add an extra dimension to the package concept. As long as the package, not the MG,
defines what can be optional that's probably fine. It does leave open the issue of
finding out which of the optional values are actually supported. Ideally, you
would like to be able to figure that out ahead of time rather than by trial and
error.

> this would cause people major problems.

I would much prefer being able to figure that out ahead of time (but realize that
may be easier said than done in the general case)

-- Flemming

--
Flemming Andreasen
Cisco Systems

---

From: John Segers <[email-masked]>
Date: Mon, 28 Aug 2000 02:14:33 +0200

Flemming,

> and in that package you then specify that which values are optional and which are

Allowing this would certainly give a lot more flexibility and I believe
that something like this could be allowed in package definitions.

If we do allow this, then, we should consider adding some text somewhere
(implementor's guide probably).  This to prevent people from claiming to
support the DTMF detection package, and only detect digits 0-8: the
package doesn't say that support for 9 is mandatory.  I am not certain
whether one statement could cover all existing packages or that we would
have to address them separately.

> would like to be able to figure that out ahead of time rather than by trial and

I agree that documenting the status (mandatory/optional) of values in
packages is better than leaving it up to the MG and that trial and error
is far from ideal.  At the risk of upsetting Brian, but at the same time
increasing the chances of getting him to think about this issue, might I
suggest that provisioning could be used?

Cheers,

John

--
John Segers                                  email: [email-masked]
Lucent Technologies                                        Room HE 306
Dept. Forward Looking Work                      phone: +31 35 687 4724
P.O. Box 18, 1270 AA  Huizen                      fax: +31 35 687 5954

---

From: Kevin Boyle <[email-masked]>
Date: Tue, 29 Aug 2000 10:51:19 -0400

I am resending this, since it apparently floated off into the ether,
never to be seen again.  I apologize for any duplication that may
occur.

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

Hello,

A general question here:

What, exactly, is meant by "support" of a signal?  Does this
mean that a gateway will absolutely know what the physical parameters of
the signal are, and will play it?  Or does it mean something a little
less than that, for instance, that the gateway will gracefully accept the
signal in question, not necessarily doing anything about it?

Generally speaking, signals, and tones in particular, have very
precise definitions as to when and how they should be used.  So, if
there are no phones in need of a particular signal off of a gateway, in
theory, that signal would never be requested by the MGC.  However,
if it was, by the package definition, the MG would be required to support
it.  Is it incorrect, then, for the MG to successfully acknowledge
the signal application command, and then throw the signal away?  Maybe
the signal could be datafilled to be/do nothing in the MG, in which case
ignoring the signal would be a correct application of the signal to the
line.

MGCs have a little different issue with the meaning of "support".
Just because a MGC supports the ability to generate a particular signal
to a MG, does not necessarily mean that MGC will ever do so.  In this
case, "support" becomes a pretty meaningless term.  If a signal is
never going to be generated, then what does support really mean?
That the MGC can generate the signal through manual intervention?

The same argument about signal support in MGCs also applies to events
as well.  If we will never ask for a particular event, what does support
of that event mean?  For MGs, the same is not true.  A MG must
be able to report a supported event when it is requested in the Events
descriptor.  So support of events from a MG standpoint is fairly straightforward.
Since properties and statistics are acted upon in both directions, support
is also a straightforward concept for these as well.

I, too, agree that there is an issue regarding values, as highlighted
by the codec example.  In the same vein, there needs to be a better
definition of what support means, especially in regards to signals and
events.  I propose, as a starting point for discussion, that "support"
of signals in the MG means that the MG will accept the signal, and acknowledge
it without error, at the very minimum.  Any problem with MGs choosing
to ignore important signals will be rectified by the MG's inability to
produce quality telephone service without those signals.  "Support"
in the MGC is a little tougher issue, since support of a signal or event
is invisible until such time as the signal or event is requested.

Any comments/ideas/statements to correct my misconceptions? ;)

Regards,

Kevin Boyle

CS2K Line Services

Nortel Networks

Agreed.

> parameters.

I guess the term "values" is somewhat prone to interpretation, but
I would

tend to disagree if we refer to a list of well-defined values,
as e.g. a

list of tone ids in E.7.

> it.

However, in this parcticular example, the tones are both signals
and tone

ids, so the effect would be the same. While I'm not particularly
fond of the

tonegen package, it does nevertheless illustrate an important point,
namely

that the distinction between signals, and parameters to signals
(and similar

for other constructs) is somewhat arbitrary. The package really
gives you

two things:

1. A name space

If we don't know exaclty what those "properties" are, then we've
lost a very

> a proliferation of packages.

I agree, but we have to ask ourselves what the idea about packages
is.

Simplicity and flexibility are often at odds with each other and
in this

If I no longer know exactly what is supported in a package, how
do I go

property in a package, we can't expect support for every possible
codec in

the world.

Maybe there's a distinction between supporting values for events,
signals,

> supported.

Not sure how you would do that with event and signal parameters
though (come

to think of it, I'm not sure how you, in practice, do that for
a lot of

parameters; "The appropriate descriptors, *with the possible values
for the

Termination* are returned from AuditCapabilities", Section 7.2.6).
On the

other, we could have a new property that looked similar, so it's
not clear

> parameter values defined in the package unless specified in a
package."

I don't want to deflate the package concept to the extent this would
seem to

allow, but I agree there's an issue here. Further discussion is
needed

-- Flemming

--

Flemming Andreasen

Cisco Systems

---

From: Kevin Boyle <[email-masked]>
Date: Fri, 25 Aug 2000 14:01:01 -0400

Hello,

A general question here:

Regards,

Kevin Boyle

CS2K Line Services

Nortel Networks

Agreed.

list of tone ids in E.7.

two things:

1. A name space

the world.

-- Flemming

--

Flemming Andreasen

Cisco Systems