Minutes from Multimedia MIB audio call o

George Kajos 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.

                                        Pekka Pessi

More information about the sg16-avd mailing list