Back to the Future: SIP and Web APIs
Posted by Jiri Kuthan on Tue, Feb 09, 2010 @ 03:52 PM
It may be of interest to readers of this blog that recently a thought-provoking Internet Draft was published by Henry Sinnreich et al: SIP APIs for Communications on the Web - draft-sinnreich-sip-web-apis-00. In a nutshell, the Internet Draft exhibits critique of SIP and suggests a consequent usage of HTTP technology for VoIP used along with other Internet applications.
The question begs, whether the critique is justified and whether the shortcomings mentioned introduce sufficient pain to make one-self busy with abandoning SIP. I think the critique is largely fair; I'm less sure that there is a time window in which the level of pain can cause such a change.
The critique cites several reasons: standards' complexity, insufficient consideration of NAT traversal and difficulties to link to web apps - to name the most significant ones. The complexity statement can be easily confirmed by looking at the VoIP RFC Watch site maintained by Nils Ohlmeier or by checking the SIP WG RFC dependency graph. And, NAT traversal has proven itself to be a large problem resulting in the formation of new network element type - the session border controller (SBC). Non-voice apps are indeed still letting us wait for them.
The real question to me is whether these difficulties will create enough motivation to change from SIP to Web technology. The window of opportunity seems closed: complexity can be somewhat lowered; like it or not, we have SBCs for NAT traversal; and web-apps can be built with or without SIP.
Still, isn't the number of these workarounds a good enough reason to give the HTTP legacy a try? I have recently found out that remote sharing of "smart boards" (i.e. whiteboards with direct output to PCs) works over web port 80 via a third party to facilitate NAT and firewall traversal. Most video apps are using HTTP (even though typically one-way), and the number of emails exchanged via HTTP certainty creates a fair traffic share. To me it looks like we're already giving HTTP a try...