ASN.1 Changes in H.225.0v3

[Paul E. Jones]

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 at SMITHMICRO.COM>
To: <ITU-SG16 at 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 at mailbag.intel.com
>

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