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
Paul,
Yes, I have a problem with this. I thought you said that the three fields would be made OPTIONAL and new fields would be added after them. However, you syntax shows that you would _replace_ these fields. That would cause a decode error in our and I assume other H.323v3 vendor's products. Making them OPTIONAL and then adding other extension additions after them is risky enough, but replacing them is not just risky but deadly.
Paul Long Smith Micro Software, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
Paul,
Yes, it definitely breaks backward compatibility: that was clearly stated. However, it was also an editorial error. If we can determine whether or not anybody has shipped a V3 product to date-- and there are several companies with V3 at the moment-- we can make an informed decision. I have contacted every company that I know that has a V3 product.
As a general rule, it is bad to change the ASN.1 in such a manner. However, these changes were proposed by me as Editor of the Implementers Guide because the ASN.1 truly was in error. We could resolve this by changing the H.225.0 text, rather than the ASN.1. The main reason for having the fields defined as OPTIONAL was to provide a means of allowing an H.323v3 or higher endpoint to use Annex E when talking with an H.323v2 device that also supports Annex E. However, it has since been pointed out that: 1) There are no Annex E implementations to worry about 2) Even if there were, TCP would still work, so they're not broken
However, now that we've started down this path, I believe that folks agree that there is benefit in this approach: 1) It allows us to provide a call signaling address for Annex E, rather than necessitating the use of the registered port number 2517 2) It allows us to add additional transport support in the future in a backward compatible way and without adding new fields to these messages.
So, I would like every company to carefully consider this issue. We must have closure on this within one week, since we must finish the Implementers Guide and H.225.0v4 documents soon-- and we do not need issues like this to become a problem. Also, those people building H.323v3 devices need to have a high comfort level that we will not be changing the ASN.1 further-- I do not want any company to have to wait until November (when the next Implementers Guide is approved) to feel comfortable that their equipment is not going to be broken.
Paul
----- Original Message ----- From: "Paul Long" Plong@SMITHMICRO.COM To: ITU-SG16@mailbag.cps.intel.com Sent: Friday, June 02, 2000 3:44 PM Subject: Re: ASN.1 Changes in H.225.0v3
Paul,
Yes, I have a problem with this. I thought you said that the three fields would be made OPTIONAL and new fields would be added after them. However, you syntax shows that you would _replace_ these fields. That would cause a decode error in our and I assume other H.323v3 vendor's products. Making them OPTIONAL and then adding other extension additions after them is
risky
enough, but replacing them is not just risky but deadly.
Paul Long Smith Micro Software, Inc.
For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
Paul,
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!
Regards, Chris
"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.zipasn1_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@mailbag.intel.com
participants (3)
-
Chris Wayman Purvis -
Paul E. Jones -
Paul Long