Subject: Re: Support of Values in Packages

From: Tom-PT Taylor <[email-masked]>
Date: Wed, 6 Sep 2000 09:12:28 -0400

No, what I meant was that the type of "Announcement ID" would be arbitrary
string, and the meaning of specific strings would be understood between the
MG and MGC through provisioning.

> -----Original Message-----
> From: Christian Groves [mailto:[email-masked]]
> Sent: Wednesday, September 06, 2000 1:19 AM
> To: [email-masked]
> Subject: Re: Support of Values in Packages
>
>
> 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
>
> Tom-PT Taylor wrote:
> >
> > 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: Thu, 7 Sep 2000 13:18:14 +1100

G'Day Tom,

I'm still having trouble with this. Do me this is just leading to
optionality of what values you support. By specifying arbitrary string
you are basically saying  I support different set of values for the
property and you have to audit to find out why unless we use evil
provisioning.

So back to examples of where sub-sets of values can be possible:
o codecs,
o announcements,
o H.248 Annex F has lots of examples ie. f7.1.2 Communication Mode will
all MGs support every mode?
o H.248 Annex E.12.2 rtp payload types - the way its defined here allows
for multiple subsets.
o H.248 Annex G Function Key Package "l001 - l999 (0x0015-0x03fb)       Set of
line keys" I gather different MG will support a different number of keys
in this range.

I think I provided exceptions to the rule and in many cases when we
define packages the values supported will be variable. So I still think
we need to add some text to the implementors guide regarding this.

Cheers, Christian