Hi, In trying to use an option of the OSS ASN.1 Compiler that makes it possible to move from V1 to V2 of a protocol without any name changes occurring in the generated .h file, the ASN.1 compiler reported a bunch of unexpected changes in H.245 V2 relative to H.245 V1. Upon investigation I found that its complaints were due to a) changes in the names of identifiers in H.245 V2 compared to those in V1, and much more seriously, b) changes in the H.245 V2 messages compared to V1 that results in V2 not being a valid extension of V1 - meaning that any implementation that conforms to H.245 V2 is guaranteed to be non-interoperable with implementations that conform to H.245 V1. I don't follow H.245 closely, so I don't know if it was intentional that these two versions are incompatible with each other. If this was the intent then please ignore this email. Some of the changes in H.245 V2 that result in name changes in the compiler-generated .h file (unless a directive is used to tell the compiler to use the V1 name) are: - All occurrences of the identifier q723 have been changed to q7231 - In T84Profile the identifier jbig200x200Progr has been changed to jbig200x200Prog ("r" at the end has been removed). - In AudioMode the identifier g-dsvd has been changed to g729AnnexA - In H263VidoeCapability the identifier bppmaxKb has been changed to bppMaxKb ("m" changed to "M"). - In DataProtocolCapability the identifier the identifier hdlcFrameTunnellingwSAR has been changed to hdlcFrameTunnelingwSAR ("ll" changed to "l"). - In RequestMultiplexEntry the identifier multiplexTableEntryNumberentryNumbers has been changed to entryNumbers. - In RequestMultiplexEntryAck the identifier multiplexTableEntryNumberentryNumbers has been changed to entryNumbers. - In RequestMultiplexEntryRelease the identifier multiplexTableEntryNumberentryNumbers has been changed to entryNumbers. The above is probably only a partial list of the changes that are merely minor annoyances for anyone who uses an ASN.1 compiler. Much more significant are the following which render H.245 V2 inoperable with H.245 V1 implementations: - In OpenLogicalChannelAck the CHOICE alternative v75Parameters was removed in H.245 V2. This affects the bits on the wire and guarantees that a V1 and V2 applications cannot interoperate if they attempt to exchange an OpenLogicalChannelAck message unless they happen to omit the reverseLogicalChannelParameters or multiplexParameters fields. If multiplexParameters is present they will fail to interoperate. - The type of AudioCapability.g729AnnexA changed from being a SEQUENCE to being an INTEGER. This changes the bits on the wire because a field that was previously mandatory is now no longer being encoded. - In H.245 V2 the V76HDLCParameters has the field crcLength as mandatory, while in H.245 V1 it is OPTIONAL. This affects the bits on the wire so V1 and V2 cannot exchange the V76HDLCParameters type. - In IndicationMessage the second CHOICE alternative has changed from FunctionNotSupported in V1 to FunctionNotUnderstood in V2. This affects the bits on the wire so that V1 and V2 cannot exchange the second CHOICE alternative of this message, for FunctionNotSupported and FunctionNotUnderstood are syntactically different types. - In H.245 V1 NonStandardParameter was extensible, while in V2 it is not. This affects the bits on the wire and makes it impossible for NonStandardParameter to be exchanged between V1 and V2 implementations. - In H.245 V1 NonStandardIdentifier was extensible, while in V2 it is not. This affects the bits on the wire and makes it impossible for NonStandardParameter to be exchanged between V1 and V2 implementations. - In H.245 V1 the DataProtocolCapability components segmentationAndReassembly and hdlcFrameTunnellingwSAR were in the extension root, but in H.245 V2 they have been made extension additions. This affects the bits on the wire for all possible encodings of DataProtocolCapability so it cannot be exchanged between V1 and V2 implementations. - V76LogicalChannelParameters has been changed from a CHOICE to a SEQUENCE. This affects the bits on the wire so V76LogicalChannelParameters cannot be exchanged between V1 and V2 implementations. - In UserInputIndication the component alphanumeric has changed types from IA5String to GeneralString. This is undoubtedly a mistake, IMHO. Aside from the fact that it affects the bits on the wire due to the default permitted alphabet being altered, GeneralString is a far more difficult type to work with because the characters in it are of varying width. That is, one character can occupy 1 byte, and the next 3 bytes, then next 4 bytes, the next 2 bytes, and so on. It is due to the difficulty in writing programs to process such character string types why BMPString was introduced into ASN.1. What was the rationale for going from IA5String to GeneralString? I am likely to have missed other changes that make V1 and V2 incompatible, for I was not trying to be thorough once I realized that there were more than just one or two such errors. It occurs to me that maybe the idea is that protocolIdentifier is to be used to determine the set of messages that can be exchanged, so the problems with bits on the wire mappings reported above are not important. However, if this is the case and bits on the wire compatibility is not important then why bother adding types after the extension marks ("..."), given that such types require a few more bits to encode than if they appeared before the extension mark? -------------------------------------------------------------------------- Bancroft Scott Toll Free :1-888-OSS-ASN1 Open Systems Solutions, Inc. International:1-609-987-9073 baos@oss.com Tech Support :1-732-249-5107 http://www.oss.com Fax :1-732-249-4636