Err, I think there are some things missing:
1) H.323 closely matches PSTN protocols and capabilities. Its
interoperability with ISDN and SS7 are far more natural.
2) H.323 is more efficiently coded using ASN.1. One might not think that
this matters, but in fact it matters a great deal in large
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
Hi -
From: Karl Auerbach [EMAIL PROTECTED]
To: IETF [EMAIL PROTECTED]
Sent: Saturday, August 23, 2003 7:03 PM
Subject: Re: Pretty clear ... SIP
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
At Sat, 23 Aug 2003 21:31:19 -0700, Randy Presuhn wrote:
In fairness,
1) SNMP's (ab)use of ASN.1 pretty much precludes the use of ASN.1 compiler
technology. All the implementations I know of used hand-coded encoders and
decoders. The vulnerabilities aren't a result of
on 8/24/2003 1:53 AM Rob Austein wrote:
I've used ASN.1 compiler technology for a project that included an
H.323-related frob, and ended up wishing I hadn't. Can you say more
than 2MB just for the ASN.1 PER encoder/decoder on a box with an 8MB
flash chip? (For comparision, the embedded
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
In the ongoing saga about topology reality vs. application perception of
stability, it occurs to me we are not working on the right problem. In short
we have established a sacred invariant in the application / transport
interface, and the demands on either side of that interface are the root of
