Re: Pretty clear ... SIP
Dean Anderson writes: > > 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. ::snort::
RE: ASN.1 (Re: Pretty clear ... SIP)
Good points, esp. the references to 2234. May I also point out that many SIP stacks use automatically generated parsers from the ABNF description. These have many, but not all, of the advantages claimed by ASN.1. It was a goal of the RFC3261 work to make the ABNF grammar complete enough to use a parser generator. Strict compliance to 2234 is helpful in this regard. The proof is in the pudding. Our experience with interoperability testing is quite good, and contrary to statements on this thread, most current systems interoperate with very old SIP devices. This is more true of old SIP phones than it is of old proxy servers. If you use a time line based comparison (age of spec vs interoperability results), I think you would find SIP beats the pants off of H.323, which in the first several years was dismal, but of late is pretty good. Also note that SIP is quite compressible, c.f. RFC3320, and the wireless folks, currently one of the applications most concerned with the number of bits on the wire, seem quite content with compressed SIP, and are not beating the doors down for ASN.1 encoding. This version of the ASN.1 debate at least is focusing on PER. The last one I remember was the Megaco debate, which was BER based. They lost that one; the work showed BER encoded ASN.1 was both longer and slower than text encoded. With Megaco, you have directly comparable messages. Brian > -Original Message- > From: Harald Tveit Alvestrand [mailto:[EMAIL PROTECTED] > Sent: Tuesday, August 26, 2003 2:50 AM > To: Karl Auerbach > Cc: IETF > Subject: ASN.1 (Re: Pretty clear ... SIP) > > > Aah an ASN.1 firefight! > It's been a LONG time since we've had one of those, but they > used to be a > regularly scheduled event on this list. > > I used to have opinions on this debate - for a trip down > memory lane, check > out the "canonical X.400 vs SMTP debate" on my website (sorry, typing > offline at the moment - google will find it). > > One note, however: > > --On 25. august 2003 15:16 -0400 Dean Anderson <[EMAIL PROTECTED]> wrote: > > >> 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. > > > > ASN.1 is not automatically extensible. You have to specify > where the > > protocol can be extended. If you don't use extensions, it should be > > possible to have an ASN.1 runtime that omits the code to > handle them. (One > > of many possible runtime optimatizations that are possible > but rarely seen > > in practice, except with hand-coded encoders/decoders) > > One warning to those with long memories and strong opinions: > > The way one does extensibility in ASN.1 has changed greatly > since the first > (1984) versions of ASN.1. Lots of the hard opinions people > have here are > based on ASN.1(1984) experience, which was what SNMP originally used. > > I have had people tell me that the post-1988 versions of > ASN.1 are really > nice in this department, but haven't used ASN.1 seriously since > approximately 1992 (when PER was just being stabilized). > So I'm not qualified to say whether they are right or not. > > Aside on complexity: The definition of ABNF, the "formal" > language used to > define the SIP syntax, RFC 2234, is 14 pages long, and has > been blasted by > several people as being a too complex tool for proper > protocol description. > > I haven't checked the pagecount of the ITU recommendations > defining ASN.1 > recently, but the last time I had one in hand (X.208/88), I'd > estimate it > as at least 10 times that number of pages. > > Harald > > > > > > > > > ___ > This message was passed through > [EMAIL PROTECTED], which is a sublist of > [EMAIL PROTECTED] Not all messages are passed. Decisions on what > to pass are made solely by Raffaele D'Albenzio. >
ASN.1 (Re: Pretty clear ... SIP)
Aah an ASN.1 firefight! It's been a LONG time since we've had one of those, but they used to be a regularly scheduled event on this list. I used to have opinions on this debate - for a trip down memory lane, check out the "canonical X.400 vs SMTP debate" on my website (sorry, typing offline at the moment - google will find it). One note, however: --On 25. august 2003 15:16 -0400 Dean Anderson <[EMAIL PROTECTED]> wrote: 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. ASN.1 is not automatically extensible. You have to specify where the protocol can be extended. If you don't use extensions, it should be possible to have an ASN.1 runtime that omits the code to handle them. (One of many possible runtime optimatizations that are possible but rarely seen in practice, except with hand-coded encoders/decoders) One warning to those with long memories and strong opinions: The way one does extensibility in ASN.1 has changed greatly since the first (1984) versions of ASN.1. Lots of the hard opinions people have here are based on ASN.1(1984) experience, which was what SNMP originally used. I have had people tell me that the post-1988 versions of ASN.1 are really nice in this department, but haven't used ASN.1 seriously since approximately 1992 (when PER was just being stabilized). So I'm not qualified to say whether they are right or not. Aside on complexity: The definition of ABNF, the "formal" language used to define the SIP syntax, RFC 2234, is 14 pages long, and has been blasted by several people as being a too complex tool for proper protocol description. I haven't checked the pagecount of the ITU recommendations defining ASN.1 recently, but the last time I had one in hand (X.208/88), I'd estimate it as at least 10 times that number of pages. Harald
Re: Pretty clear ... SIP
On Sun, 24 Aug 2003, Karl Auerbach wrote: > > > > 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. Karl brings up many good points here. > 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. A compiler-generated code is going to be more uniform than hand-generated code. Once you have cleared the compiler output, you can have greater confidence that its output will be free of security vulnerabilities. > (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.) I agree that the inefficiencies of compilers have to be improved. And I think they can be improved. However, I note that the size of SIP libraries are also becoming quite large. To some extent, the comparision is due to the greater functionality that is built into the H323 library. I think that the SIP group underestimated the value of this functionality early on, and were forced to add it later. Certainly, one of the effects of the SIP effort has been to validate the utility of this functionality. > 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. Agree. > 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. I respond only that things must be made as simple as possible, and no simpler. > 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. ASN.1 is not automatically extensible. You have to specify where the protocol can be extended. If you don't use extensions, it should be possible to have an ASN.1 runtime that omits the code to handle them. (One of many possible runtime optimatizations that are possible but rarely seen in practice, except with hand-coded encoders/decoders) > 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. I think it depends on what kind of overhead it adds to the specification and the implementations. In an ASN.1, it adds very little, and is of little concern to the application programmer. However, ASN.
Re: Pretty clear ... SIP
At 19:03 -0700 8/23/03, 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 denial-of-service disaster. For example, the flaws in ASN.1 parsers in SNMP engines have proven to be a decades+ old vulnerability for the net. To be fair, the flaws were in an implementation that one person developed and many used. The same sort of problem with a vulnerability being widespread has occurred in other contexts, w/o regard to the encoding scheme. So, this really is a red herring in this argument. 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. Certainly XML is not going to yield a smaller encoding, so your reasons for preferring it have to be based on value judgements in other dimensions. steve
RE: Pretty clear ... SIP
So here's the nightmare scenario: X.693 (XER - XML Encoding Rules for ASN.1). You get the "best" of ASN.1 and XML -- undecipherable ASCII text with lots of angle brackets :-) > -Original Message- > From: Karl Auerbach [mailto:[EMAIL PROTECTED] > Sent: Sun, August 24, 2003 9:12 PM > To: Dean Anderson > Cc: IETF > Subject: Re: Pretty clear ... SIP > > > > > > 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. [snip]
Re: Pretty clear ... SIP
> > 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.
Re: Pretty clear ... SIP
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 > denial-of-service disaster. > > 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 that. 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 unaligned PER. > 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 > H.323 - 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. --Dean
Re: Pretty clear ... SIP
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 Linux kernel on this same > box was quite a bit less than 1MB.) I knew you could. No doubt we > could have gotten a smaller implementation if we'd been willing to > throw serious money at it, but H.323 wasn't even the main point of the quick-n-dirty = bloat is a universal. I've seen rfc822 parsers that were nearly as large for example. As far as that goes, moving bloat around within a layer doesn't seem to matter much in the end, and ASN.1 parser bloat is just as bad as XML or 822 or [...] parser bloat. The question of where compression should occur is a good one. The usual suspects are the application or the data-link layers, but I'm not sure there are overwhelmingly compelling arguments for either, or that equally compelling arguments couldn't be made for transport or network layer compression for that matter. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Pretty clear ... SIP
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 ASN.1, but rather of > trusting > humans to do a compiler's job. > 2) Dean was specifically writing about PER, which can be *much* more compact > than BER would ever hope to be. PER can potentially result in a more compact > encoding than applying compression to a single packet. Look at the spec to > see > why. 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 Linux kernel on this same box was quite a bit less than 1MB.) I knew you could. No doubt we could have gotten a smaller implementation if we'd been willing to throw serious money at it, but H.323 wasn't even the main point of the box, it was just an extra feature that Marketing hung on the side because it made a cute demo. YMMV, but based on that experience I'd have a hard time believing that ASN.1 PER is worth the trouble.
Re: Pretty clear ... SIP
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 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 > denial-of-service disaster. > > For example, the flaws in ASN.1 parsers in SNMP engines have proven to be > a decades+ old vulnerability for the net. ... 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 ASN.1, but rather of trusting humans to do a compiler's job. 2) Dean was specifically writing about PER, which can be *much* more compact than BER would ever hope to be. PER can potentially result in a more compact encoding than applying compression to a single packet. Look at the spec to see why. Randy
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 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 denial-of-service disaster. 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. --karl--
Re: Pretty clear ... SIP
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 volumes. H.323 is PER encoded, which frequently results in about 50% compression over uncompressed data. Smaller packets have lower latency, and take less time to transmit. Advances in processor speed over IO speed has made compression almost a zero cost feature. 3) Standardization is _way_ better with H.323. The IETF process relies on the standard-writers to do the implementations, which we then hope are well documented in the standard. They aren't always so well documented. So long as the group of implementers is small, this isn't a problem. But in large groups, it doesn't work very well. Such an iterative process of implementation/documentation/implementation is slower than complete specification -> implementation except when the group of implementers and documenters are small, so that undocumented or vague parts can be passed informally amoung the implementers. For example, consider that the DNS groups have been struggling for years with ambiguities in RFC 1035. Things still aren't fully specified, and there is a great deal of difference and incompatibility between Bind 9 implementation and other DNS implementations. It doesn't seem that these ambiguities will be resolved soon. 4) H.323 has free infrastructure: There are free ASN.1 compilers (I'm even am about to release one). There are free implementation of H.323 protocol stacks, and free h.323 software. 5) H.323 moved through 4 major well defined enhancements far faster than SIP. 6) SIP started out saying that it could do the job simpler and easier than H.323. So far, this hasn't proven to be the case. SIP is now just as complicated as H.323. The reason for the complication is driven mostly by the PSTN, and the features that you find on phones and PBX's. These features haven't changed, so the complexity is still the same. However, this is not to say the SIP effort was wasted. Not in the least. There has been a tremendous amount of productive feedback and cross pollenation between the two groups. There is nothing like competiton to make one think pragmatically. SIP significantly influenced the attention to performance in H.323 after version 1, and resulted in features like FastStart and other procedures to reduce the startup traffic. There are probably other examples of productive feedback between the two. H.323 and ASN.1 eventually surpass a text based protocol because they are better specified and can be implemented by compiler, securely, and compatibily. A compiler handles more of the compatibility between different implementations. Text based protocols are by definition vague. Handwritten parsers offer more opportunities for bugs, incompatibilities, and security problems. ASN.1 has other advantages that I won't go into here. The most pointed past disadvantage of ASN.1 was that it was complicated and expensive, because there were no free compilers, and decoders were also hard to come by. That has all changed. Etherreal and other free packet analyzers have H.323 modules, and can now easily incorporate other ASN.1 based protocols. Recent enhancements to ASN.1 allows for specification of encoder rules so protocols like IP or Q.931 can be specified and implemented by compiler. There is really no reason for the IETF not to consider using ASN.1 for protocol specification, and in fact, it does in the GSSAPI. --Dean On Thu, 21 Aug 2003, Dan Kolis wrote: > Since SIP is IETF not ITU its only reasonable to have internet believers > lean towards it. > > H.323 ? Ahhh no thanks. > > No serious look at these can even consider H.323 etc and its derivitives as > useful in the general case. The only reason they were used is the absence of > a better alternative. > > Try to hook your Sony Playstation up through H.323 > > When would that move through committee? Spring of 2010 ?? > > Oh. Another reason for IETF to believe in it is that its basically a free > comm technology. H.323 wants to drag in the old timers and their costs > structures... dependance of geography, etc so there is a credible reason by > most criterea. > > Regs, > Dan > > >
Re: Pretty clear ... SIP
The difference between internet telephony and voice chat. This is fairly critical actually. It doesn't matter if you're talking about H323 or SIP although obviously there is a bias in each one towards one or the other. The commonly used VoIP name does NOT do enough to differentiate, we need to be talking about IP telephony and voice chat as two DIFFERENT beasts since they have substantially different expectations of availability! People expect a telephony system to be available even if the power goes down, virtually all the time, how many nines of availability? Lots. More than the internet actually. In fact, they would basically expect IPtel systems to keep working even if the internet goes down. They reach for the IP phone, a physical object on their desk, most likely. This is not really "internet" stuff this is the adaptation of internet protocol to telephony fields where internet availability doesn't cut it. On the other hand, voice chat is also VoIP but the expectation are completely different. People basically expect it will operate through the computer. It will only work if the internet connection is working. Power failure ? goodbye. This is not a telephone replacement. It's a supplement. It's going to be dirt cheap and have all the other goodness that typically characterizes internet technology. simon On Thursday, August 21, 2003, at 02:35 PM, Dan Kolis wrote: Since SIP is IETF not ITU its only reasonable to have internet believers lean towards it. H.323 ? Ahhh no thanks. No serious look at these can even consider H.323 etc and its derivitives as useful in the general case. The only reason they were used is the absence of a better alternative. Try to hook your Sony Playstation up through H.323 When would that move through committee? Spring of 2010 ?? Oh. Another reason for IETF to believe in it is that its basically a free comm technology. H.323 wants to drag in the old timers and their costs structures... dependance of geography, etc so there is a credible reason by most criterea. Regs, Dan -- anti-spam: do not post this address publicly www.simonwoodside.com -- 99% Devil, 1% Angel
