On Sat, 23 Aug 2003, Karl Auerbach wrote:
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.
This isn't quite fair. Most of these vulnerabilities were hand-encoded, as
are some X.509 (BER) certificate decoders. Hand-coded ASN.1 suffers from
the same issues as other hand-coded encoders. This is not a flaw in ASN.1.
At least ASN.1 offers a path out. Ad-hoc text-based protocols won't do
In the few cases where the compilers were are fault, the compilers were
fixed, and applications fixed by relinking. There are test suites for
compilers that try to crack the generated decoders. This offers a degree
of assurance that can't be found in any ad-hoc protocol.
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.
XML has its advantages. But mostly, I've found that the biggest advantage
with XML is the ability for hierarchical queries and for hierarchical
storage. Beats the heck out of LDAP. But this isn't entirely unique to
XML. LDAP is meant to store a specific type of hierarchical information.
XML is general purpose. But it is also hugely inefficient.
Another problem with text based protocols, is that when they are
encrypted, they are still ascii. You know that there is going to be a 0
bit every 8 bits, and you generally know the alignment of the plaintext in
the cryptotext. I note that book that described the DES cracker machine
would brute force every key until it found ascii text. Unaligned PER
doesn't suffer this problem. Even if it has large amounts of ascii, there
is no way to determine what the alignment of the plaintext is, without
having the actual decrypted packet. A cracker machine would have a much
more difficult time detecting probable successes. Further, if you define
the alphabet to be used in the protocol, most regular text is constrained
enough so that it can be sent using 7 bits (and no padding 0's) with
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.)
When you add in the Tag and length, thats true. But then RADIUS protocol
also uses Tag/Length/Value encoding, although it doesn't call it BER. It
has the same drawback.
And of course, the protocol specifier is free to specify one of 4 variants
of PER. This does not change the semantics of the protocol, and doesn't
affect the specification of the protocol, which can be done roughly
independent of the choice of encoding. Though, of course, you have to
specify the encoding to be used in a sentence, somewhere in the semantics
of the specification.
(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.)
Well, there are typically 20 to 40 bytes of header on such links. On low
bandwidth links, there typically aren't any minimums. And on ATM, a little
compression can make a big difference.
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
Few products? Every Microsoft OS ships with an h323 client called
netmeeting. Now, its h323 compatibility has been criticized (like just
about every other 'standard' feature of Microsoft), but I haven't found
any shortage of H323 products out there.
I find H.323 to be qualitiatively worse, as measured in units of
elegance, than SIP.
I find just the opposite. Now I have to worry about the security of SIP
phones, and that they might be used for evesdropping. H323 and and
trusted ASN.1 compilers can go a long way past SIP for ensuring
trustability of such devices.
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.
Multiple tools make up a toolkit. H323 uses the right tool for the right
job--something that SIP really missed out on.