Evolution - face it!

SIP/IP vs PSTN/H323 as concepts in the arena, again. It was flying on twitter a new SIP vs H323 head to head comparison (I assume it is new, there is no publishing date on the page, but they claim it is at least actual).

Just reading the start of the comparison, I had big doubts. They claim that people who did such comparisons in the past were unknowledgeable, students or similar, misleading with their articles. But in this case there isn't even an author (nor list of authors), so we know that those doing it now are proper specialists. For me is more that clear that they have no understanding of SIP and its intended role for real time communications (RTC) over IP networks.

I guess they are telecom people, based on their way of thinking and the reasons they wrote in the article, no matter it is venders or operators. So, first guys, sleep well, SIP is not a replacement protocol to upgrade PSTN network. H323 could have been designed for that, definitely not SIP.

Personally I will refrain from doing technical comments on H323. Simply I don't care about, it is not for the new wave of communication demands. Instead I will punctually tell how wrong the concepts about SIP are in this article. If I was one of the authors, first I would remove the paragraphs from the start of the article, it has ridiculous content: "this is, frankly, the best comparison of H.323 and SIP available anywhere", "comparing apples to apples", ...?!?! Or at least add the authors name so the others can check them and be sure they have right expertise with SIP.

Rarely I could see so much misunderstanding of SIP while claiming to know it. Now, point by point comments about the sections in the comparison article (note: you have to read the article with SIP vs H323 comparison more or less in parallel with the next comments for proper understanding):

Philosophy

First, yes, SIP is for establishing real time communication sessions, an audio call being just a possibility. And that's how it should be. Remember, SIP is not to upgrade PSTN protocol. It is for being able to cope with new communication demands.

Here is your biggest failure guys. SIP has very less to do with the session content. That is advertised in SDP (Session Description Protocol). So, being it audio, video or 3D holograms sessions, SIP does not need to be changed at all.

To rephrase, SIP is to establish the communication session, not to understand the content of the session. That's PSTN where the operator wanted to control the content and have the intelligence on the network, so all pieces around had to understand everything. Lately, we, the end consumers, don't like anymore dummy endpoints, but smartphones. And if these phones are able of transmitting something completely new, then I don't like after spending lot of $$$ on my device to have the operator limiting me. SIP is for that. Operator can charge on minutes, bandwidth, but not on content type -- that's my business. Do you like to be charged differently for a flight because you ate caviar than someone else that ate hot dog? Do you want to be forced to tell to the flight operator what you have eaten?

Now I hope the philosophy is clear: we talk about the "free as in speech" to do with what I own.

Complexity

Can you point the document (RFC) where SIP was extended for video or application sharing? How did you come up with these? Guys, google first...

SIP is really a simple protocol. Even the initial model for instant messaging and presence is very simple and works perfectly with all implementations (it is the end-to-end model, architecture used pretty much the same in Skype or XMPP/Gtalk). Then we got the mobile/telecom operators pushing for so called SIMPLE extensions which is indeed complex. That it is not SIP core, but newer extensions.

Reliability

I haven't understood a term from what it is claimed the H323 does there. But SIP has lot of mechanisms to deal with failure routing, from using DSN SRV (yes, cool down, this is fine, we are over IP networks here, where DNS is the heart) to doing serial forking. Ultimately, if it is the case, the user agent had to do any re-INVITE, perfectly ok because it is the one that knows about the content of the session.

Message Definition

Having university studies in both compilers and network communications, I can put just a smiley here: :-). Really guys, it is where you could get with it? I can start an endless debate here.

Message Encoding

Folks, take a deep breath and give me a break with bandwidth consumption by SIP signaling. The SIP compression concept you pointed were the most useless ever I met, however, pushed by vendors hoping to sell new boxes for few more millions of bucks to their money-milking operators.

Have you computed what is the percentage of the SIP packets in a 5 minutes call with GSM, G729 or G711 audio codecs? How much one could gain compressing less than 10KB? If you search through all SIP related RFCs you can get wrong and complex specifications, does not mean they have to be implemented or they will be ever. First, RFC stands for Request For Comments. People with ideas can write new specs, others can review and approve to become a RFC number, then it is the period to see if it worth a penny or not.

The large number of RFCs related to SIP gets to the conclusion that the protocol is very flexible, easy to extend and many were able to do that, period.

Just to freak you out, Twitter messages are maximum 140 characters long. What does it take to send a Twitter message? An HTTP request with very big JSON body. A HTTP request has more or less same amount (and structure) of SIP message. Then the body for Twitter is far more bigger than SDP for a SIP audio call initiation. Now, does anyone care about compression of Twitter packets? Does any of the users with smart phones twitting over mobile networks complained about? Guys, look around, we are in 2011.

Extensibility - Vendor Specific

I assume you heard that (the risk you claim for SIP) from the cousin of a friend of your wife/husband's colleague from high school meeting first time after graduation at the 30 years reunion. If not, then some links/examples would be good.

Extensibility - Standard

Evolution has some risks, not everything can be backward compatible. But the next phrase I quote from your article blew my mind:

"In addition, several extensions are "mandatory" in some implementations, which cause interoperability problems."

No more comments here.

Scalability - Load Balancing

SIP does not provide any in-protocol standard load balancing "specifications", it is in essence IP based protocol and there are lot of load balancing meanings here, like DNS based ones. Reporting usage can be done very easy by operators/vendors through replies and custom headers.

I am doing SIP load balancing solutions for so many years, never found anything missing in the protocol in this aspect. Lack of vision to apply a protocol is not a weak of the protocol.

Scalability - Call Signaling

Is this again about bandwidth of signaling packets?!?!? Com'on...

Scalability - Statelessness

I'm core developer for 10 years of a SIP Server and didn't know it has to be stateful for TCP. How is that, can you elaborate? We can do it stateless at SIP Express Router (SER) / Kamailio from the first day of TCP support, it's simply working. You say it is actually wrong? Is there any RFC requiring the server to be stateful? Please give the details.

Scalability - Address Resolution

3 is for sure the number making SIP bad. There are either 3 "full messages" or "as many as 30". Pointless what you mention at this section. How did you measure the "processing requirements"? Can you give the sample H323 and SIP packets used in measurements and how you made them? I would like to run the SIP packets through SER/Kamailio to see if the match the "processing" demands.

Come with numbers guys and proper arguments, otherwise is bullshit bingo article.

Addressing

First, about myself, when I'd see no digit-based numbers/IDs in in SIP, I will keep partying one week long. That means SIP got to the level to be used properly.

The part with "unofficial" convention is the best of the article, really, keep it up folks!

Billing

Wow, can't believe it. They are trusting the end device to report proper billing information. Great folks, why don't you start such a business over Internet? How long will take to update an open source softphone to report the call duration the user wants to? Wake up, Internet is open, it is not PSTN and you cannot control customer's devices anymore.

Call Setup

You tried hard guys. You admit H323 may require more elaborate call establishment for complex scenarios, but no example given. You show how is done in a similar case with SIP. Conclusion: it is possible with SIP, not sure it is with H323.

Capability Negotiation

Is it me and potentially my imperfect English, but the H323 side and SIP side have different kind of topic. I see no direct relation between what you say in one side and then compare against in the other.

PSTN Interworking

H323 borrows? I thought H323 is PSTN over IP, sorry if I got it wrong so far. I hope SIP will never become like this, we don't need PSTN over IP and that is the problem now with SIP. Many try to turn it in PSTNoIP protocol. I just pray they will fail.

Services

Yet again a section with random statements. I haven't heard of any new and cool service provider recently via "well suited" H323 protocol. And, fyi, XML, SOAP and CPL are pretty much standards.

Video and Data Conferencing

As mentioned above, you have no clue folks about the purpose of SIP. Does the pilot has any clue of what you ate before boarding the plane? How can he fly the plane then?

Codecs

SIP does not support any codec itself, and never will do. Keep reading the specs guys and understand the purpose of SIP.

Nowadays we call them smartphones those devices that need to create and understand the content of a session that is established via SIP.

Firewall/NAT support

You refer to 5 documents for H323 and 4 for SIP. So we are doing better in SIP then.

Loop Detection

Max-Forward cannot be used at all for loop detection in SIP.

Since H323 can fork, how it will deal with the case in the presentation linked in the SIP side?

If you mean that a gatekeeper is call stateful server, then SIP server can be the same and detect looped calls very easy. If you refer to call stateful H323 server and stateless SIP server, then tell me how is it with H323 stateless server.

Conferencing Entity

What's that in the SIP side: "no, ... conference bridge may provide ... " while in H323 is "yes, a MC is required...". Have you ever heard of SIP audio conferences through SIP with Asterisk, FreeSwitch & co?!?!

Open-source projects

I bet it was hard to choose the one of the SIP open source projects to list, but I am glad you have one for H323. How many H323 open source softphones are out there? What about server applications? Plenty I guess based on your observations here, just stupid Google does not find them.

Conclusions

The biggest fear I have is turning SIP in a protocol to bring PSTN in IP networks. Hopefully it will not happen, although standardization bodies are overwhelmed by guys with old telecom mentality and concepts.

As for the H323 vs SIP article it is written without any understanding of SIP. If the authors want to do a real comparison, bring two guys, one having proper expertise in H323 and the other in SIP, put the problems on the table and let them give the solutions.

The way that article is written shows only frustration and inability to understand and see the demands in the new waves of IP communications, nothing else.

SIP has to be interoperable and integrate easy and seamless with email, web, twitter and what so ever IP based communication service, not with PSTN. It must replace PSTN-type of communications, not just help to upgrade PSTN physical infrastructure.

We need evolution in telecommunications, SIP is the chance for that! But has to be done right. If not, SIP may disappear, however at that time the telco and mobile operators will be already replaced completely in our lives.