Minutes from Multimedia MIB audio call o
gkajos at VIDEOSERVER.COM
Fri Jun 26 17:44:00 EDT 1998
"EXT Paul Long" <plong at 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.
More information about the sg16-avd