alternateGk mechanism?

Johan Gerhardsson (ETX) Johan.Gerhardsson at ETX.ERICSSON.SE
Thu Jul 27 11:46:40 EDT 2000

Terry L Anderson wrote:
> Rich Bowen wrote:
> > Terry,
> >
> > Just one comment -
> >
> > Terry L Anderson wrote:
> > > I checked our changes in the white draft of H.225.0v4 and removed all
> > > our ASN.1 that has already been incorporated.  I now show only changes
> > > that are still needed.  I have not yet done the similar check with
> > > H.323v4.
> > >
> >
> > I think we should consider whether to keep these fields in H.225.0 v4
> > since Annex R is not yet determined.  We might want to keep the door
> > open for further refinement of these fields before Annex R is
> > decided.  Maybe we should add these in H.225.0 v5, or we could add
> > them between H.323 versions via the new genericData fields.
> The discussion in Osaka was to add them but not be specific about their use
> ("for further study") which is what you added in the "white". Are you now
> questioning that?

What I'm thinking is that after "further study" we may decide that one
or more of these fields are unnecessary or have the incorrect
structure.  The former useAnnexECallSignalling field is a recent
painful reminder that these things happen.

> The problem is one of timing.  Annex R is planned for determination in
> November but would depend on these fields.  Annex R's decision would occur
> much before H.225.0v5.  So the intent was to include in v4 those fields we
> know we need and have the two current Annex R procedures (Method A and
> Method B) stable for determination in November.  We would have some
> flexibility in describing their usage in the Annex but could not add more
> fields until v5.
> I am reluctant to use "genericData" unless we view that as permanent.
> Otherwise we end up having to exchange Annex R version numbers to decide
> where to put data, etc.

I'm not aware of any proposal to remove generic features.  Another
advantage of using generic data is that systems that don't need the
robustness features (e.g. simple endpoints) would not have to compile
the ASN.1 for them.  This exemplifies one of the primary motivations
for generic features -- H.225.0 becomes modular so that you only have
to include the fundamental signalling structures plus whatever
particular features your system needs.  Perhaps you could even define
the two robustness options as independent generic features if there
are likely to be systems that would use one option and not the other.


> > Regards,
> > Rich
> >
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > For help on this mail list, send "HELP ITU-SG16" in a message to
> > listserv at
> --
> ------------------------------------------------------------
> Terry L Anderson              mailto:tla at
> Tel:908.582.7013   Fax:908.582.6729
> Pager:800.759.8352 pin 1704572   1704572 at
> Lucent Technologies/ Voice Over IP Access Networks/ Applications Grp
> Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974
> (Lucent internal)

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

More information about the sg16-avd mailing list