Subject: [Fwd: Re: Support of Values in Packages]

From: Christian Groves <[email-masked]>
Date: Sat, 26 Aug 2000 02:28:58 +1000

-------- Original Message --------
Subject: Re: Support of Values in Packages
Date: Fri, 25 Aug 2000 13:34:09 +0530
From: chennu <[email-masked]>
Reply-To: [email-masked]
Organization: Chiplogic India (P) Ltd.
To: Christian Groves <[email-masked]>
References: <[email-masked]>

Hi Christian and All,

I also have the same understanding . I agree to your proposal of adding
the
text to the implementors guide.

--chennu.

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