Discard unexpected RTP packets?

[Paul Long]

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 at oss.com                                  Tech Support :1-732-249-5107
http://www.oss.com                            Fax          :1-732-249-4636