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: http://www.packetizer.com/iptel/h245/h245_asn.html#MULTIMEDIA-SYSTEM-CONTROL...
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: 1.. Change the FECData definition to contain an extension marker 2.. 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). 3.. 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
// www.packetizer.com