Response to "SIP Rules!"

From: Paul E. Jones [mailto:paulej@packetizer.com]
Sent: Monday, May 29, 2000 1:46 AM
To: rick@computertelephony.com; dsheridan@cmp.com; jjainschigg@cmp.com;
emuraskin@cmp.com; bmichael@cmp.com
Subject: Cover Story: SIP Rules!

Folks,

I have heard a lot of negative comments made about H.323 (http://www.packetizer.com/voip/h323/) at VON (http://www.von.com) and other forums. Often times, those comments come from a very small handful of individuals who are associated with a startup company that is trying to get into the VoIP market. Some of those I have talked to play this game to build a level of excitement around SIP (http://www.cs.columbia.edu/~hgs/sip/) in order to keep the VoIP market unsettled long enough for them to get established. Many of them have just recently shipped products, while others have nothing of substance to show. There are a few people out there who, for whatever reason, feel that SIP is the right approach, just as there are those who take a similar position with respect to H.323.

I have heard many claims that H.323 is complicated and that the protocol specifications are too vast. To an extent, those claims are true. However, H.323 is not the culmination of unnecessary complexity. Rather, it represents a level of protocol maturity.

Some people begin their comparison of SIP and H.323 at the level of message encoding: binary versus ASCII. There are some who believe that ASCII is the right way to go, because it's "easy". The assertion is that it's easy to write the code to encode and it is easy to identify encoding errors, since everything is clearly visible as text. This argument makes sense when one is developing a single protocol like SIP. However, as soon as one decides to implement the next, different ASCII-based protocol, all of the "low-level" work must often be done from scratch again. That is one of the main reasons why protocols such as H.323 use ASN.1-- to prevent having to do this work over and over again for every new protocol. While ASN.1 PER encoding is not nearly as trivial as ASCII encoding, the work only has to be done once and the tools to do that are available commercially. An additional benefit of H.323 comes as new features are added to the protocol. Again, the software developer is spared from having to change the code at the lower layers that performs the encoding and decoding of messages.

Once we get passed encoding, I often hear arguments that H.323 is complex because it requires support for multipoint audio/video conferencing. H.323 supports multipoint data conferencing with the use of the T.120-series of protocols, which some say lends to the increased complexity. People look at the size of H.323, H.225.0, and H.245 alone as enough reason to declare that the protocol is too complex. People then look at supplementary services based on the H.450-series protocols, which they believe does nothing but continue to add to the complexity of the protocol.

The truth is that any mature system has a certain level of complexity that is necessary in order to provide the services that service providers need in order to meet customer demands. There are many things in H.323 that are completely optional to implement, such as decentralized multipoint conferencing, data conferencing, and all supplementary services. All of those and many other features exist as options because people need them. So on the surface, H.323 appears more complex than it is when one only needs minimal functionality.

The interesting thing to note is that, while SIP is simpler in some ways, the same complexity found in H.323 is creeping into SIP. If one examines the architectural models of the SIP implementations and network designs of various vendors and service providers, one will see a common theme: there is a convergence toward the H.323 architecture. Yes, there are differences, but I often see more similarities than differences. Just examining the Internet Draft documents submitted for the last IETF (http://www.ietf.org/) meeting, one can see that people feel that many things are missing from the SIP protocol-- things that are found in H.323. As those features are necessarily incorporated, the protocol will become more complex.

Another misconception I often hear is that SIP can take advantage of the Internet in ways that H.323 cannot-- that simply is not the case. The article " SIP Rules! (http://commweb.com/features/comptel/2k0522.sip.html)" in the May 2000 issue of Computer (http://www.computertelephony.com) Telephony certainly tried to make this point. There were comments that were in error or exaggerated. I thought this was an interesting statement: "Yes, H.323 works. But there's something fundamentally wrong-headed about it." Other references were made to "telecom-heads" as being at fault for the design of the protocol. I will readily admit to anyone: I am not a "telecom-head." Many of the folks working on H.323 have a background in traditional phone systems, but they also understand the Internet and Internet technologies. As an example, H.323 adopted RTP as a means of carrying media even before RFC 1889 was published. Yes, H.323 has some aspects inherited from the POTS world, but H.323 is designed for a packet-based network and has the full potential to take advantage of that environment. Long before SIP existed as an RFC, H.323 possessed the ability to redirect callers to a web page-- a "powerful feature" of SIP I recently saw touted at VON. Of course, that's only a very simple example.

I often say that the real complexity of any system actually lies above the protocol layer. The application often contains much more complexity than the protocol under it. This is true for both SIP and H.323 equipment. One can build a simple H.323 or SIP device, just as one can build complex devices. Almost without exception, the complexity in any IP telephony system usually has very little to do with the protocol used for signaling. Now, I know that some may disagree with that statement, but as third-party call control and various supplementary services are added to the SIP protocol and as SIP proxies are connected to other network elements to provide services, such as address resolution, authorization, billing, etc., I believe that those people will share the same opinion.

On the whole, I believe that there is a big misconception about H.323 in the SIP community. At a recent IETF meeting, a comment was made that the SIP folks know more about H.323 than the H.323 folks know about SIP. As editor of H.323 and one who has also implemented SIP, I don't believe that to be the case. Each protocol has its strengths and weaknesses, but I often hear more uninformed bias than anything else. I believe this recent article in Computer Telephony is the pinnacle of articles containing gross misconceptions and disparaging remarks about H.323. H.323 is a strong protocol and is widely deployed throughout the world. You will never hear me make such negative comments about SIP: I respect the protocol and the engineers who have worked to create it. It is unfortunate that some advocates for SIP can be so disrespectful of technologies not created in their own circles and that some startup companies feel compelled to use "protocol bashing" as a technique for bolstering support for their young company. Worse, I am disappointed that a magazine like Computer Telephony would condone such antics.

Best Regards,
Paul E. Jones
Editor, Recommendation H.323

PS: SIP stands for "Session Initiation Protocol" and not "Session Interface Protocol", as was stated in the article.