Search This Blog

Thursday, December 29, 2005

Teenage years are never easy

Whoa Corporate Rat! I still cannot seem to resist a good ol' geek talk! One more of the year, OK?

It is just plain hard-work when you are trying to join a communications club that is several decades old with multiple generations of engineers developing distinct applications and services.

What is happening in the VOIP world is nothing new. Standardization is inherently complex. It becomes doubly more complex when you consider voice communication is of vital interest to multiple societies. It becomes triply more complex when the infrastructure being replaced is the most used and the most stable in the world!

Discussing your arguments:

1. Text based Protocol: Yes, SIP could have been XML based but THANK GOD it is not ASN.1.

2. Refusal to standardize services: I don't know why the IETF should do this? Do you really think we could get two carriers to agree that Call Forwarding RNA should terminate in an intercept or ring forever? Or that Music On Hold is an "expected" feature in business applications all over the world?

I think the push for standardizing services has more to do with carriers being apprehensive that they will be locked into a proprietary solution. Industry groups like the SIP Forum are the right place to standardize services for their customers. OMA is another good example.

3. The Royal Routing mess: This is a legitimate argument. I am not too worried about Record-Route headers (HTTP has them too BTW). The SBCs, acting as giant B2BUAs in the sky, have made things a bit simple :-D.

I think the SIP community needs to solve the hard problems (which I consider are routing issues): Lifeline services and lawful intercept.

4. Bloat Bloat Bloat: If you examine carefully, most of the complexities have to do with trying to model the PSTN in SIP. The industry secret is: You don't need intelligence in the network for Alice to find and talk to Bob and you don't need all this bloat for Alice to buy phone service with a handful of cool features... all you need to know is your outbound proxy and your service proxy. IMS architects, please listen!

5. This is not what SIP is meant for: Most of the original SIP "zealots" are healthy, wealthy, and Directors at rather successful companies... let's leave it at that :-)

6. Forking: LOL! It's Forked ;-) !

7. E2E Architecture: I will let RFC 1958 speak for me. I rather like the fact the I didn't have to wait on the SBC Yahoo! CallCenter for two hours since I got IP connectivity: Hosted email, music downloads, video on demand, chat, online bill pay, the phone companies still have BIG BIG plans for all of this... since 1955!

Skype is a remarkably successful and proven business model. It is always very easy to build a good proprietary solution. Going back to the email world example, Lotus did this rather successfully with cc:Mail. But, we don't even discuss SMTP interoperability today... SIP will get there. The page that the SIP folks can take from Skype is:

1. Make configuration dead simple! Sorry, SIP endpoints suck at this!
2. Solve the NAT/Firewall issues. Good progress here!

BTW, Vonage has 1 million paying subscribers and they solved the same two issues that Skype did. And they are standards based (MGCP right?).

8. Backward Compatibility: Most of us have moved forward to 3261. Most carriers will not accept SIP solutions that are "ancient".

In Conclusion

What blows my mind is that the technology is ready for a Google, Microsoft, or Y! to become the voice communications provider to the whole world! Just like email!

Isn't that just incredible? It's time one of them offer free phone service to the PSTN as well!


  1. Sunil:

    First, I must say I love the title "Teenage Years are never easy" - you need to get into marketing, my friend :-)

    Now onto the rest of your comments:

    I'll use the comment system, so that I don't start a new article:

    You say:
    "Text based Protocol: Yes, SIP could have been XML based but THANK GOD it is not ASN.1."

    My response: Spoken like a true application developer :-) You folks have no respect for optimization ! XML based SIP ? So 15000 bytes to complete a call handshake ? A protocol, if meant to be implemented end-end should be designed end-end. Sorry, XML does not cut it - try to sell that solution to handsets, for example.

    You say:
    "...Call Forwarding RNA should terminate in an intercept or ring forever? Or that Music On Hold is an "expected" feature in business applications all over the world?..."

    Don't confuse presentation with service execution. We are talking call flow here. The set of messages, for example, that MUST happen if you do an attended transfer. How the transfer is _presented_ to the user (jingle bells, belly dancing or another mechanism) is a UI issue. At least then, you will have a _US_ seimens UA capable of talking to a _US_ vonage phone easily. Country variants will always exists - just like they did in PSTN. That does not imply a lack of need for a manadated minimal profile. ITU does that - so what's so special about IETF ?

    You say: "If you examine carefully, most of the complexities have to do with trying to model the PSTN in SIP."

    No - absolutely not. SIP's bloat comes in implementing its primitives not the services on top.

    You say: :E2E Architecture: I will let RFC 1958 speak for...."

    Yes, well RFC 1958 talks about the advtanges of an Internet model. I am talking about the network that SIP is being deployed today, which is not end-end by nature. So not sure I see what 1958 explains for the non end-end networks.

    You say: "...Skype is a remarkably successful and proven business model"

    That's like saying the US economy is a remarkable and proven business model. You don't prove a business model by making one year of profits. You prove a business model by making 5-10 years of continuous profits and riding at top of a disruptive world.(and in the case of world economy, a sustainable economy over 100 years is a proven model) If Skype still existed as a standalone (not bought out by ebay) it would be interesting to see how it could put up against the planned Y! voice service at such a cheaper rate.

  2. Sukumar RaghavanMay 21, 2007 at 4:36 AM

    I guess the link to OMA is supposed to point to