Subject: Re: Support of Values in Packages

From: Christian Groves <[email-masked]>
Date: Mon, 4 Sep 2000 11:00:01 +1100

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: Mon, 4 Sep 2000 11:00:41 +1100

G'Day Kevin,

Interesting discussion. Please see my reply below marked CHG.

Cheers, Christian

Kevin Boyle wrote:
>
> 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?

[CHG] I would agree with your first interpretation of what support
means. The MG must be able to play that signal. However I believe that
in some instances you may not want to support the values of the
parameters associated with it. Eg. I support signal PlayAnnouncement
which has an announcement number parameter. I have a package defined
with announcement parameter values 1,2,3,4,5-100. In MG1 I cover 1-49
and in MG2 I cover 50-100. I would assume that its OK for MG1 to report
back Unsupported Value if you asked it to play 99.

>
> 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.
[CHG] In the case of a Tone with no parameters I believe the MG must
play the signal. In the case where parameters are involved (ie. in the
case I give above) I think that the signal is refused as an error. It
obviously is because the MGC asked the wrong MG to play the signal.
I think that you can put functionality between several MGs and to me its
wrong to define packages based on resource splitting needing several
packages for one function.

>
> 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?
[CHG] I agree with you. Its ultimately the Application that determines
what will be generated.

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

[CHG] I think that in the case of both signal and events, parameters
must
come into play in the definition of what you support.