Wolfgang Bandow wolfgang.bandow at DETEWE.DE
Mon Jun 5 09:23:49 EDT 2000


I don't have a particular axe to grind, but would suggest that if the change is
desired it might be improved by a small tweak:
Where you have
        useSpecifiedTransport           UseSpecifiedTransport OPTIONAL
replace it with
        useSpecifiedTransport           SEQUENCE OF SpecifiedTransport OPTIONAL

Then define SpecifiedTransport as you've defined UseSpecifiedTransport.
This (with suitable text) would allow a gatekeeper to specify transports in a
priority order: any transport not mentioned should not be used if the SEQUENCE
OF is present at all (interestingly this would mean there would actually be a
difference for a change between, on the one hand, the SEQUENCE OF being present
but empty and, on the other hand, the SEQUENCE OF being absent!).
I appreciate that this is going to be a pretty short SEQUENCE OF at the moment,
but we might as well be prepared for someone wanting to define 38 new different
transport types in the future!


"Paul E. Jones" wrote:
> 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
>   -------------------------------------------------------------------------------
>                      Name: asn1_error.zip
>    asn1_error.zip    Type: Zip Compressed Data (application/x-zip-compressed)
>                  Encoding: base64

Dr Chris Purvis -- Development Manager
ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road
Winkfield Row, Berkshire.  RG42 6LY  ENGLAND
Phone: +44 1344 899 007
Fax:   +44 1344 899 001

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

More information about the sg16-avd mailing list