Comments on H.225v4 and H.323v4

Pete Cordell pete at TECH-KNOW-WARE.COM
Thu Jul 6 07:47:19 EDT 2000

Rich, Karl,

The problem with calling the construct in question a parameter is that it
also contains parameters.  When the text explaining it goes on about the
parameter and the parameter, you don't know what variant of parameter is
being discussed.

Also, it does not convey the intention of the construct.  If a feature
requires multiple parameters to communicate, they would all be contained in
a single construct.  GenericParameter may give people the impression that
multiple 'genericParameter' constructs would be used for this.  Hence the
naming is mis-leading.

The concept (which I'm sure Paul* must know a lot better than I do - we're
merely the bozos that conceived and wrote it) is that the features are
negotiated, and then the features are used.   The package - as was - is what
the features use to actually communicate.

If calling it  genericFeature is not acceptable then call it
genericFeatureData, or featureData.  Calling it genericParameter is just too
confusing, and it does not convey the intention of contribution.  The term
genericParameter should not be used.


*I can't see where Paul said the comment that this refers to BTW

Pete Cordell
pete at
+44 1473 635863

----- Original Message -----
From: Rich Bowen <rkbowen at CISCO.COM>
To: <ITU-SG16 at>
Sent: 05 July 2000 19:16
Subject: Re: Comments on H.225v4 and H.323v4

> Morgan,
> >
> > Rich/Paul,
> > I have the following comments on H.225v4 and H.323v4.
> >
> > H.225 /p168: neededfeatures has been moved from conferenceGoal to
> > in the Setup message.
> > I understand from Pete that inclusion of neededFeatures in the
> > conferenceGoal has caused problems for Cisco gateways.  Moving
> > neededFeatures out of the conferenceGoal however, means that feature
> > negotiation can never be used with versions other than H.323v4. If we
> > not going to use the conference Goal, (and the use of conferenceGoal is
> > preferred option!), It would be better to leave out the term
> > altogether and use desiredFeatures.
> >
> This topic was discussed on the list a couple of weeks ago.  To
> summarize, adding the field to the conferenceGoal was controversial.
> (It is not correct that this would be a problem for Cisco gateways.)
> Adding it to the Setup-UUIE is a possible alternative that had fewer
> objections, so I left it there as a placeholder with the understanding
> that if the issue is not resolved by November, it can be removed at that
> time.  I personally don't have a strong opinion about the placement or
> presence of this field.
> > H.323 /p75: The change of name from 'package' to 'parameter' is
> > inappropriate.
> > If the name has to be changed from 'package', it should be changed to
> > genericFeature.
> >
> > H.225 /ANNEX H: There should be a global change of terminology from
> > genericParameter to generic Feature.
> >
> I agree with Paul's comment, that the term "feature" encompasses more
> than the intended purpose of this field.  There were two objectives
> stated in TD-50/Osaka: tunneling opaque data and negotiating features.
> The field in question achieves the tunneling of opaque data.  Any name
> that reflects that purpose would be fine with me.
> - Rich
> > Regards,
> >
> > Morgan Potter
> >
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > For help on this mail list, send "HELP ITU-SG16" in a message to
> > listserv at
> --
> --------------------------------------------------------------------
> Richard K. Bowen                     Cisco Systems, Inc.
> VoIP Session Protocols               Research Triangle Park, NC, USA
> --------------------------------------------------------------------
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv at

For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at

More information about the sg16-avd mailing list