> > 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 > > denial-of-service disaster. I think the nugget of our discussion is the old, and probably unanswerable, question of what is the proper balance between present function and future (unforeseen) extension. Back in the 1970's I met a very smart system designer. He drew a distinction between "intricate" and "complicated". A fine watch with many moving parts could be intricate as being a well engineered solution to a specific problem, while a Rube Goldberg timepiece could be complicated and not well engineered. The difference being the fact that unnecessary elements are elided from an intricate solution unless there is a specific articulated reason to leave them in. ASN.1 (along with other general purpose encoders such as XML) carry a heavy burden of machinery that is present whether it is needed or used or not. Your point about ASN.1/PER having some security benefits because the cleartext is less predictable is interesting - and I sense that it is quite valid. However I would suggest that there is a much greater risk that comes from putting the heavy and complex machinery of ASN.1/*ER engines into deployed implemtations - and that is that most implementations of products are very poorly tested against any but the most mainstream of traffic flows. A complicated engine such as ASN.1/*ER is full of nooks and crannies where undetected flaws could exist. A simple encoding, well suited to the particular job at hand, is less likely to contain untested code paths, whether those paths be generated by compiler or by hand. (By-the-way, I don't accept the assertion that compiler generated ASN.1/*ER engines are going to be better than hand tooled ones - most of the latter that I've seen (some of which I've written) use libraries for all the heavy lifting - fix a bug in the library and relink and you're done, just like with a compiler. And I agree with Rob A. that in many embedded devices, we still can't ignore memory and processing inefficiencies.) The net is slowly evolving an edge layer of devices that are best described as sealed appliances - these are small devices that will tend to never experience an update to the factory installed code image. It is far more important to get these right before they are shipped than to have the ability to extend their capabilities in the field. I do not believe that complicated representations such as ASN.1/*ER reflect a good balance between engineering needs for the present and expansibility for the future - thus I put ASN.1 and *ER into the "complicated" rather than the "intricate" category. It is certainly true that net telephony and conferencing need extensibility - but I would suggest that the hooks for extensibility ought to be concisely defined and placed in specific parts of the protocol structures (such as the SDP part of today's call establishment protocols). I see no need to burden the entire protocol representation under a mutable layer of complexity such as ASN.1 when there is no reason that can be articulated to require such mutability. By way of analogy: IPv6 addresses could have been of variable size, like NSAPs. But so far I don't think that enough reasons have been put forth to justify moving away from a relatively solid and fixed-size format to a variable address format. Good engineering includes a kinda sixth sense of knowing when to stop adding features. > And of course, the protocol specifier is free to specify one of 4 variants > of PER.... When I see phrases like "4 variants" I hear "one normal way and three routes for attack". Which reminds of of why the Internet isn't running ISO/OSI today. (Although I was surprised to learn recently that the ICAO is presently mandating voice over CLNP for some new ground-air and air-air systems for commercial airplanes.) ISO/OSI had lots of good ideas. But it could never focus or prune. It built a top heavy, over-optioned Vasa[*] that tipped over and sank before it could ever be deployed. [* - The Vasa was a 17th century Swedish warship that was so larded with options that it tipped over and sank on its first trip across the harbor.] I really want VOIP and conferencing to work, not sink. > > 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 - > > Few products? Every Microsoft OS ships with an h323 client called > netmeeting. Netmeeting dates from around 1997. Most of my hard VOIP phones are either SCCP (let's not talk about that ;-) and/or SIP. I haven't heard much "buzz" about new H.323 work. > 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. You are not alone in your concerns about security. I too am concerned about spoofing of SIP messages but I haven't gotten my hands dirty enough with SIP at that level to know whether I'm just being paranoid or whether there is really some substance to my concern. However, I don't see how an ASN.1 compiler adds or subtracts anything from the tap-ability, legal or not, of a VOIP conversation. What am I not seeing? (Let's not go off into the infinite set of painful issues surrounding things like CALEA.) --karl--