"EXT Paul Long" plong@smithmicro.com writes:
B decodes the Foo, removes ICV and encodes the packet again. In the resulting encoding, the length of extension bitfield is 3, and the ICV that B regenerates is different that A generated and sent to B. B is not able to interwork with systems using earlier version of the ASN.1 spec.
Why not? This is precisely what the H.225.0 and H.245 protocolIdentifier is for--to indicate which version of the Recommendation the endpoint supports. An endpoint must know what protocol versions the remote terminal supports. For example, if an H.225.0v3 endpoint communicates with a v2 endpoint, it knows that the v2 endpoint will not recognize any of the extensions added since v2 and shall not therefore depend on any v3 behavior on the part of the v2 endpoint. Likewise, the v2 endpoint must be able to treat all v2 and subsequent endpoints as a v2 endpoint.
The whole point of ASN.1 extensions is that a version-N device can encode a PDU using version-N encoding rules and send it to a device using the version encoding rules of a previous version and the recipient can still decode the packet. However, due to the way ICV is calculated, a version-N device needs separate ASN.1 PER encoding/decoding functions for all previous version.
...
There are also problems because the way some ASN.1 compilers behave. Using our previous example, when A receives Foo with the importantExtension field from B, A has somehow to include the value when it is re-encoding Foo in order to calculate the ICV.
I can't think of a situation where a terminal would ever have to re-encode. Are you referring to a GK or GW?
All recipients must re-encode the PDU when checking ICV.
Pekka Pessi