Folks,
It has been a while since a "serious" error has
been identified in an H.323-related spec, but one was just recently discovered
in H.245v9. I want to poll the people on the H.323 Implementers List and
the SG16 mailing list to see what kind of impact we might have if we change this
definition.
The problem relates to the "FECData"
CHOICE:
It is roughly defined like this:
FECData ::= CHOICE
{
rfc2733
{
... stuff
...
}
}
The problem is that there is no extension marker at
the end of the "rfc2793" SEQUENCE, though it was intended that one be
inserted. If you look at every other related definition (FECCapability
and FECMode), you will see that they do contain an extension
marker.
We essentially have these ways to resolve this
issue:
- Change the FECData definition to contain an
extension marker
- Rename the "FECData" structure and references to
something like "FECDataDeprecated" and add a new field called "FECData" and a
new structure to go with it. This would mean no other text would have to
change in H.323 or H.245 and no implementations would be impacted
significantly: applications would be binary compatible, though two system
implementing FEC might not open FEC protected channels correctly (one side
thinking FEC is used and the other side not, for example).
- Create all new data structures and deprecate all
current FEC data structures related to the "FECData" CHOICE
We've had these kinds of problems in the past and
simply corrected them via the H.323-Series Implementers Guide. However, it
is always good to understand who, if anybody, will be impacted by such
changes. Can you please provide me with information so that we can make an
informed decision?
Thanks,
Paul E. Jones
Rapporteur, ITU-T Q2/16