On Sat, 23 Aug 2003, Dean Anderson wrote:
H.323 and ASN.1 eventually surpass ...
Ummm, based on my own direct experience with ASN.1 since the mid 1980's
(X.400, SNMP, CMIP...), I disagree.
It has been my experience that ASN.1, no matter which encoding rules are
used, has proven to be a failure and lingering interoperability and
For example, the flaws in ASN.1 parsers in SNMP engines have proven to be
a decades+ old vulnerability for the net.
We'd be much better off with XML, Scheme expressions, or Python pickles
than with ASN.1 both for expressing data structures in documents and for
encoding data structures into binary for carriage in packets.
If one wants compression, then it is better to apply it to the entire
packet, or the byte stream - the results will almost always be much, much
better then the item by item packing done by ASN.1's encoding rules. (I
was always amused that using BER, ASN.1 integers were frequently bigger
than simply 32-bit binary, particularly when carrying unsigned numbers,
which are rather common in networking protocols.)
(In addition, with the 60 octet minimum packet size imposed by many data
links, compression of typically small packets - such as those containing
SDP information - often doesn't result in much of a gain anyway.)
As far as SIP vs H.323 goes - apart from the market fact that it is
getting increasingly more difficult to find new products that support
H.323 - I find H.323 to be qualitiatively worse, as measured in units of
elegance, than SIP. I too am sorry that SIP has gotten more complex as it
has experienced actual implementation pressures. However, H.323 started
out as a mish mosh - a large dollup of ISDN, a dab of SDP, a chunk of
RTP/RTCP - and it remains a mish mosh.