Subject: Re: Support of Values in Packages

From: Tom-PT Taylor <[email-masked]>
Date: Mon, 4 Sep 2000 20:58:54 -0500

There is a simple answer to the announcement dilemma, which is that I'm not
sure announcement names need to be standardized.  I can think of only about
five standard announcements in North American practice (as codified by
Bellcore).  Everything else would be a matter of provisioning for local use.

I would say tones are the best example of something many-valued that we'll
have.

> -----Original Message-----
> From: Christian Groves [mailto:[email-masked]]
> Sent: Sunday, September 03, 2000 8:00 PM
> To: Taylor, Tom-PT [NORSE:B901:EXCH]
> Cc: [email-masked]
> Subject: Re: Support of Values in Packages
>
>
> G'Day Tom,
>
> If you think Codecs are a "Red-Herring" how about
> Announcements? If you
> have an MGC-MG that is operating as an anouncement server
> which support
> 100 announcements. You may want to place certain announcement
> resources
> across different MGs. Now you could have one package called the
> Nortel-Announcement-Package or you could have the:
> Nortel-Announcement-Package-1to20-for-AT&T
> Nortel-Announcement-Package-1to30-for-MCI
> Nortel-Announcement-Package-31-100-for-MCI
> etc.etc.etc.
>
> If you have a strict rule that to be compliant to H.248 that you must
> support all values of proporties and parameters by default
> you can start
> generating alot of packages when you don't need to and the
> package space
> is going to fill with really useless packages. Someting like
> No. Packages for One Function = No. Vendors * No. of MG
> configurations *
> No. Customers
>
> Codecs are just one example of things that aren't linked, I
> believe you
> only need one case to disprove the rule.
>
> Cheers, Christian
>
> Tom-PT Taylor wrote:
> >
> > 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:
> >
> > > 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.
> >
> > Agreed.
> >
> > > However you
> > > do not have to support all the values associated with the
> properties and
> > > 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.
> >
> > >
> > >
> > > 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.
> >
> > 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
> > > 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.
> >
> > 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 ?
> >
> > >
> > >
> > > 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.
> >
> > 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 ?
> >
> > >
> > >
> > > 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.
> >
> > 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.
> >
> > >
> > >
> > > 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."
> >
> > 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
> >
> > >
> > >
> > > Cheers, Christian
> >
> > --
> > Flemming Andreasen
> > Cisco Systems
>
>
>

---

From: Christian Groves <[email-masked]>
Date: Wed, 6 Sep 2000 16:18:42 +1100

G'Day Tom,

So am I correct in understanding that if we add values to what is
specified in a package that we don't need to extend the package? That's
what your comment below seems to imply.

I thought defaults were only provisioned, not additional values. ie in
Tone Package "Extensions to this package would add possible values for
tone id".

So I believe you still have this dilemma.

Cheers, Christian