Subject: Re: Support of Values in Packages

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 28 Aug 2000 13:22:19 -0400

I'll chime in late here with the opinion that in some really unusual
cases, it may make sense to have some values that the MG doesn't implement.
The codec list is one, and anything that recognized a preexisting IANA list
might be another.

I think that, by default, if you implement the package, you implement all of
it.
I think that if there was a need, you could state, in the definition of the
package, that implementation of some values can be optional.  I'd make the
language be pretty limiting, recommending that it's a bad idea,...
Of course an AuditCapability of that descriptor should return the values
implemented.

Brian

> -----Original Message-----
> From: John Segers [mailto:[email-masked]]
> Sent: Sunday, August 27, 2000 8:15 PM
> To: [email-masked]
> Subject: Re: Support of Values in Packages
>
>
> Flemming,
>
> Flemming Andreasen wrote:
>
> > OK, I understood it differently. All you want, is the
> ability to define a package,
> > and in that package you then specify that which values are
> optional and which are
> > mandatory ?
>
> Allowing this would certainly give a lot more flexibility and
> I believe
> that something like this could be allowed in package definitions.
>
> If we do allow this, then, we should consider adding some
> text somewhere
> (implementor's guide probably).  This to prevent people from
> claiming to
> support the DTMF detection package, and only detect digits 0-8: the
> package doesn't say that support for 9 is mandatory.  I am not certain
> whether one statement could cover all existing packages or
> that we would
> have to address them separately.
>
> > > I also agree
> > > that there's a need for clarification on what auditing
> Signals means.
> > >
> > > Could you elaborate on how we would be deflating the
> package concept by
> > > clarifying the Values are optional?
> >
> > My main concern is having MG A and MG B both support
> package P and yet my MGC
> > doesn't know what they actually implement. So far, it would
> simply be defined by
> > whatever is defined in package P and interoperability
> becomes very simple. We now
> > add an extra dimension to the package concept. As long as
> the package, not the MG,
> > defines what can be optional that's probably fine. It does
> leave open the issue of
> > finding out which of the optional values are actually
> supported. Ideally, you
> > would like to be able to figure that out ahead of time
> rather than by trial and
> > error.
>
> I agree that documenting the status (mandatory/optional) of values in
> packages is better than leaving it up to the MG and that
> trial and error
> is far from ideal.  At the risk of upsetting Brian, but at
> the same time
> increasing the chances of getting him to think about this
> issue, might I
> suggest that provisioning could be used?
>
> Cheers,
>
> John
>
>
> --
> John Segers                                  email: [email-masked]
> Lucent Technologies                                        Room HE 306
> Dept. Forward Looking Work                      phone: +31 35 687 4724
> P.O. Box 18, 1270 AA  Huizen                      fax: +31 35 687 5954
>

---

From: Christian Groves <[email-masked]>
Date: Tue, 29 Aug 2000 15:13:44 +1100

G'Day Brian, all,

I could have sworn that we had discussed this back in Red Bank last year
when discussing inheritance of packages etc and I've been under the
assumption that optional values was the way we went. I also thought that
it was in the protocol. It seems that this wasn't documented anywhere
and shows that it should have been documented either way somewhere. I
think somehow the statement has been lost because there's nothing
written anywhere on what you have to implement in a package.

It seems that we are all in agreement that you must support
properties/signal/event/statistics so I propose that we add text to the
implementor's guide to this effect.

Values: it still seems that we have some differing opinions.

I don't think the case has to be so unsual for you not to implement a
value of a property in your media gateway. Anything that describes the
use of resources may be different from MG to MG. Even the same
vendors/operators MGs are provisioned with different equipment which
would represent a different value but the same property. I don't see the
need to have a different package in this case and they should still be
compliant with the protocol. I think the case of supporting ALL values
would be the odd case in all but the simplest of packages. I'd still
like that the values are optional unless specified to be mandatory. I'm
not convinced mandatory support of all values is workable in the real
world.

Cheers, Christian

---

From: chennu <[email-masked]>
Date: Tue, 29 Aug 2000 18:01:42 +0530

Hi all,

Extending the same discussion I have a doubt. I will first give my current
understanding
on how an MGC knows about a MG.
*  First AuditCapability command is sent to know the list of terminations
supported by the MG.
*  Then AuditValue command is sent to know which packages are supported by each
termination.
    With this we will come to know about all parameters in signals & events , and
properties
    supported by the termination.
*  Then AuditCapability command is sent to know what are the Media
properties(defined in Annex C)
     and values supported by each property. Also the possible values of parameters
in
     signals & events and properties supported by the termination.
As Christian said , I think, AuditCapability is done to know only the supported
values in parameters
of the signals & events and properties rather than the all the possible values. I
am not sure whether this
should be allowed with all the parameters in the signals & events and properties.
But if possible some
text can be added to make some of the values optional.

Please correct me if my understanding is wrong.

Thanks,
Chennu.

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 29 Aug 2000 11:19:29 -0400

Christian Groves wrote:

> like that the values are optional unless specified to be mandatory.

I'd prefer it the other way around, not least considering that it would consistent
with the current protocol text.

-- Flemming

BTW: Am I the only one all of a sudden getting a lot of messages with
"owner-megaco" as the sender even though it's clearly not ?

> I'm

<snip>
--
Flemming Andreasen
Cisco Systems