CU-RTC-WEB

 Posted by on January 23, 2013 at 17:25  applications, internet, telepresence, video calling  Add comments
Jan 232013
 

Microsoft threw a rock into the RTC waters last week, demoing a CU-RTC-WEB call between Chrome (on a Mac) and IE10 (on Windows), albeit almost certainly using some plugin glue. Microsoft likely threw the rock mainly for media purposes and indeed Microsoft got the ripples they were looking for. Which is better – CU-RTC-WEB or WebRTC – became the central question. Before we get lost trying to answer the wrong question – and I do think CU-RTC-WEB versus WebRTC is the wrong question – let’s take a look at the bigger picture.

CU-RTC-WEB and WebRTC are both change agents, not strict opponents

WebRTC is not fighting CU-RTC-WEB in a war for communications world supremacy. CU-RTC-WEB and WebRTC are change agents – critical and powerful change agents on the leading edge of the paradigm shift to weaving real-time communications into the fabric of applications, services and processes and applications (read Martin Geddes and his hypervoice concepts for more on integrated communications). Meanwhile, Flash, plug-ins and various proprietary implementations won’t just disappear into the night, and new RTC protocols and methods will develop. RTC will become more heterogeneous, including CU-RTC-WEB and WebRTC, because the backbone of RTC is really the Internet, not any single protocol, and Internet = many milkshakes.

Many milkshakes rather than one ring

The Internet enables decentralized architectures, powerful distribution models and rapid innovation. This results in a near infinite variety of milkshakes, meaning we will pick our CU-RTC-WEB milkshake when it is the best milkshake to hire (watch this Clayton Christensen video if you are not familiar with hiring milkshakes). And we’ll do the same with Web-RTC shakes. Some developers will choose both and some services will abstract apps and users from the differences.

No one ring (or RTC protocol) to rule them all. In this Internet-era of diversification, does it really seem likely there will be a single dominant method to send real-time voice and video from our cameras and microphones to our browsers and apps? One protocol that enables us to voice-enable and video-enable our apps? One ring to rule them all? It might be nice, but it is very unlikely to happen – this is just like the replacement of the PSTN in that respect.

CU-RTC-WEB versus WebRTC

There are important differences between WebRTC and CU-RTC-WEB, and it is important to understand the business drivers behind each. Even while on the same side of the greater war or paradigm shift, there is heavy competition between the approaches. Read this post from Eric Rescorla for a nice comparison of the two protocols.

I am not expert enough in either protocol to go too deep, but I will comment on the SDP aspect. After what seems like 150 years of dealing with SIP SDP issues, I can safely say that both the Web-RTC/ JSEP / PeerConnection approach and the CU-RTC-WEB approach will encounter problems in SDP land, at least for use cases that require interoperability. IMO, for use cases that can take advantage, the better solution (and this applies to CU-RTC-WEB, WebRTC, SIP and H.323) is to stop treating each communications session as if it was the-first-ever-call and stop doing the full SDP offer-answer dance every time (example: true real-time video).

The crystal ball

Ok, no crystal ball here, but three events we should look towards:

1. Enterprise Connect 2013. Not likely, but if Microsoft demoed some voice and video sessions between Skype, Lync, Xbox, third-party browser-based CU-RTC-WEB apps and a mobile app or two at EC 2013…they would steal the show, and maybe change the ballgame. Could last week’s little demo just been an opening act for a much greater performance at EC 2013?

2. The March 2013 IETF meeting. WebRTC video codecs are expected to be settled. If both H.264 and VP8 are deemed as required, then Microsoft, Google and Apple are all likely happy (or happy enough), and there becomes much greater probability of harmonization between WebRTC and CU-RTC-WEB, or at the very least more viable gateway solutions. If only one is required, then the divide between WebRTC and CU-RTC-WEB will increase. On the other hand, most app developers would prefer a single mandated video codec, and arguably that would be the right decision, so keep your eye on the IETF in the next couple of months.

3. The next move from the big islands. Islands such as SalesForce.com, LinkedIn, Facebook, Twitter, WebEx, Amazon, a large gaming company, Yahoo or Flickr and a mobile app leader (leaving out Google properties and Microsoft properties since their direction is clear). One or more of these islands will move aggressively to voice enable or video enable their apps (some have already started). If they choose WebRTC or CU-RTC-WEB, then they will cause countless third party developers to do the same. Decoupled federation and identity between some of those islands? Maybe.

Summary

CU-RTC-WEB versus WebRTC? Wrong question. The two protocols are actually very close. If there were business drivers for them to merge or interoperate, or there were not strong business forces to keep them apart, then they would be one protocol. And, while that might be nice, it is extremely unlikely due to those business forces and the Internet ecosystem that we live in. The good news however is they will both help drive the overall future of communications – an Internet-enabled fabric of interwoven real-time communications, applications, services and processes. I also think the next 3-12 months will be very interesting, and perhaps we will be pleasantly surprised in a couple of areas. What do you think?