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 X-MX-Mozilla-Status: 0009ined in the package unless specified in a package."

Cheers, Christian

---

From: Tom-PT Taylor <[email-masked]>
Date: Wed, 30 Aug 2000 07:55:15 -0400

You make a valid point about "support" making fewer demands on the MGC than
on the MG in many cases.

Just to frame the terms of discussion, I would suggest that we use support
in the strict sense that the recipient is capable of carrying out the
semantic intent, not just process the syntax.

The key issues are predictability of MG behaviour vs. package fragmentation.
The codec example is (so far) a red herring, since I don't recall a codec
property in any of our packages.  Our solution to open-ended lists to this
point has been package extensions (cf toneids).  The hope is that each such
extension can cluster a reasonable number of items which one might expect to
be supported in the same device.  Something like codecs would certainly dash
that hope, since there is in general no linkage between the support of one
codec and the support of another.  We may just have to live with this, in
the sense that we end up registering lots of packages.  The numbering space
for package registration is pretty broad.

-----Original Message-----
From: Boyle, Kevin [NCRTP:3Z70:EXCH]
Sent: Friday, August 25, 2000 2:01 PM
To: [email-masked]
Subject: Re: Support of Values in Packages

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

Flemming Andreasen wrote:

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.

> parameters and Statistics. A MG MAY support a subset of property and
> 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