Response to "H.323 vs. SIP Telephony"

From: Paul Long [mailto:plong@packetizer.com]
Sent: Friday, September 14, 2001 6:17 PM
To: jiri@iptel.org
Cc: paulej@packetizer.com Subject: H.323 vs. SIP Telephony

Jiri,

Henry Sinnreich suggested that I look at your H.323 vs. SIP comparison. It's interesting, to say the least. :-)

In reference to our Packetizer comparison, we welcome you to address any of the issues we raise, either by emailing us directly or by posting to the associated mailing list for all to see. There are probably both "H.323 people" and "SIP people" subscribed there, so you should get a fair hearing. I would like to know what bugs we have confused with features and what assertions are technically incorrect, and please be specific. We have made corrections to the comparison in the past and will continue to do so based on the feedback we receive.

Here are a few other comments I have about your introductory text:

– You cite the old title of the H.323 Recommendation. It was replaced as early as 1997 in H.323v2 drafts with "Packet-based multimedia communications systems." Please update your page accordingly. Where are you getting your information from?

– Your describe how successful SIP is but say nothing about H.323. Compare vendor support for these two protocols (http://www.pulver.com/sip/products.html and https://www.packetizer.com/voip/h323/products.html). For example, that's 26 SIP UA vendors versus 35 H.323 terminal vendors, and 19 SIP gateway vendors versus 33 H.323 gateway vendors. How about billions of H.323 call minutes (http://cconvergence.com/article/CTM20010824S0009) versus, I don't know, maybe 0 SIP call minutes per month? [A service provider] was bragging at the SIP SUMMIT in Austin, Texas this week that they now have an all-SIP network with 150 phones. Woohoo! :-]

– Concerning our supposed bias, I work for a company that has development efforts under way for SIP, H.248, H.323, and MGCP. Our first product is a reference design for an inexpensive SIP phone. We are shipping eval units, potential licensees are very excited about it, and we hope to make lots of money from it. Paul Jones is indeed chair of the ITU-T H.323 group, but he is involved business-wise with other protocols, too. So we do not have a financial interest in which protocol is deemed superior or which products or services succeed in the marketplace, unlike most SIP proponents. Our motivation is simply to counter the massive amount of misinformation out there regarding H.323 vis-a-vis SIP. I think you'll find that people who are not tied to a single protocol are much less excited about SIP than those who are. As an example, please read this article written by the CTO of RADVISION, a supplier of technology for a variety of protocols, including SIP and H.323: http://www.tmcnet.com/it/0801/0801radv.htm

Now I would like to address the specific entries in your comparison:

Encoding - (sigh)... :-) How about this, written by Jonathan Rosenberg in the abstract of his SIP-compression I-D: "With the planned usage of these protocols in wireless handsets as part of 2.5G and 3G wireless, the large size of these [SIP] messages is problematic, primarily for latency reasons." IOW, text is too big, and binary isn't too hard.

Use in 3gpp - I have never heard anyone say that 3gpp will kill H.323. Apparently you have, but I'll bet that it was a SIP person that said it, correct? And besides, why is "many expect..." included in a technical comparison of these two protocols, anyway? We do not include vague allusions in our comparison and neither should you.

Call setup delay - You are correct that call setup _can_ take a very long time in H.323, but the same is also true with SIP under certain circumstances. Current H.323 implementations typically do not use the original, "super-size" :-) call-setup dialog that SIP people so enjoy mentioning, although all implementations must support it in order to remain backward compatible. Therefore, your statement that the mere _support_ for compatibility with previous versions may increase call setup is not correct. Please at least clarifying this issue, e.g., "Note: Although most H.323 endpoints now support a relatively short call-setup delay, some older implementations do not, in which case a call may take up to 7 RTT to setup. SIP call setup can also take longer than the minimum stated here." Do you disagree with this statement?

Complexity - Are you saying that a typical SIP entity _just_ uses its core HTTP-like protocol? No other protocols, huh? What about DNS? What about SDP? If SIP UAs typically use DNS to resolve destination aliases and SDP to express capabilities, you should mention them, otherwise, it's not a fair comparison.

Extensibility - You're right. It kinda bugs me, too, that things can only be extended in certain places in H.323 and that protocol analyzers aren't typically aware of these extensions. But I think SIP's text encoding is seducing vendors into unilaterally augmenting SIP to the point that interoperablity suffers. Because of this, I think of SIP as more of a technology than an interoperable protocol. Henning even talked recently of the need for SIP-to-SIP signaling gateways. D'oh!

Architecture - "monolithic" is a disparaging term that SIP people always use to describe H.323. I like to think of it as "unified." :-) In the Implications column, you should also state that modular designs are sometimes problematic because there is no overall architecture or standard for how these components shall be used together.

Instant Messaging - I'm not sure what your point is here. If you are saying that SIP can be used to implement instant messaging, the same can be said for H.323, although I'm not sure why anyone would want to. I mean, if Microsoft wants to use SIP for file sharing, I suppose someone could use H.323 for IM.

Loop detection - Can't you be little more informative than just saying "imperfect" for H.323? I mean, how much more judgemental can a description be? Please take a look at our own comparison of this feature. At least we state things objectively, which indicates that SIP may be superior to H.323 for loop detection. Our comparison is not afraid to show SIP being superior in some regards, whereas your comparison only shows SIP in a good light. That's unfair.

Addressing - Hmmm... Seems like you're saying something bad about H.323 here, but I can't figure out what it is. :-) What ever it is, stop it! :-)

Transport Protocol - You're right, I'll add this info to our comparison. I'll double check first with people who might be better informed, but I believe that most H.323 implementations still use TCP for call signaling.

Web-integration - How can a SIP user send an email to an unreachable callee? The SIP URL used to contact the callee is not necessarilly the callee's email address. Is that what you're relying on? RFC2543 only says that "In many cases, a user's SIP URL can be guessed from their email address." Moreover, a callee's SIP URL may not even contain anything remotely resembling an email address, e.g., sip:+14085550000@218.208.223.124. How are you going to send an email to this callee? Plus, H.323 has the same ability with it's email alias type. Think of something else for this entry in your comparison, because both protocols can equally send an email (or not) to an unreachable callee.

Inter-domain call routing - First, DNS only provides address resolution whereas H.225.0 Annex G supports address resolution, access authorization, and call usage reporting. Moreover, H.323 gatekeepers and Annex-G border elements can use DNS, and even H.323 endpoints can use DNS to resolve destination addresses. Therefore, I would say that these protocols are at least comparable in this regard. Please update your comparison accordingly.

Paul Long
Packetizer, Inc.