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
Regards, Rich
For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com--
Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Pager:800.759.8352 pin 1704572 1704572@skytel.com Lucent Technologies/ Voice Over IP Access Networks/ Applications Grp Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com