ASN.1 Changes in H.225.0v3

[Paul E. Jones]

Folks,

While talking with people recently about some features in H.323 version 3, I
discovered that a couple of fields in H.225.0v3 contained an error.
Specifically:

 o "useAnnexECallSignalling" in RCF was supposed to be OPTIONAL
 o "useAnnexECallSignalling" in ACF was supposed to be OPTIONAL
 o "supportsAnnexECallSignalling" in LCF was supposed to be OPTIONAL

The field descriptions in the H.225.0 document correctly describe the fields
as if they were OPTIONAL, which followed the agreed text from TD-23 in the
Monterey meeting.

In order to correct these errors, I brought a contribution to the Osaka
meeting proposing to make these three fields OPTIONAL by making a correction
to the Implementers Guide.  Participants at the meeting were in agreement to
make these corrections, especially since H.225.0v3 has not been published
yet.

However, since a change such as this will break backward compatibility
anyway, the attendees decided to go beyond simply making these 3 small
editorial corrections.  Instead, a proposal was made to replace these fields
with new fields that have an expanded scope.  It will now be possible to
provide "AlternateTransportAddresses" for various transports: Annex E, SCTP,
or something else (currently, only Annex E is defined).  In addition, the
Gatekeeper, knowing what is supported, may specify which transport an
endpoint shall use.

I did not object to this proposed change because it looks reasonable and,
given that H.225.0v3 is so new, I did not expect it to have a serious
impact.  However, I have been made aware that a few vendors have or are in
the process of implementing H.323v3.  This means that we must solidify this
ASN.1 change.  The participants in Osaka agreed to the proposed changes
(attached as a Word document).  I believe they are reasonable, but we cannot
wait until November, which is when the official vote will be made by the
various world governments, to approve those fields: by that time, H.225.0v3
will be published and will have been in a Decided state for 14 months!

So, I want to hear people's comments: are all of the vendors comfortable
with these changes?  I do not believe that any vendor would be put in an
uncomfortable position today, so I want to get agreement that we will accept
these ASN.1 changes now.  I do not want to see a contribution in the
November meeting proposing to change these structures in any way-- hopefully
what we agreed to in Osaka is acceptable to everybody and we will have no
objections.  If there are objections, I want to hear them now.  It will be
too late in November, based on what I have been hearing from various
companies.

Please give your comments to me and/or post them publicly here.

Best Regards,
Paul E. Jones
Editor, H.323 and the H.323 Implementers Guide


-------------- next part --------------
A non-text attachment was scrubbed...
Name: asn1_error.zip
Type: application/x-zip-compressed
Size: 21333 bytes
Desc: not available
URL: <https://lists.packetizer.com/pipermail/sg16-avd/attachments/20000602/2231e006/attachment-0003.bin>