Here we go again. The Internet Engineering Task Force (IETF) is scheduled to discuss WebRTC Mandatory to Implement (MTI) codecs again this week at IETF 91. We have been here a few times before – the community failed to reach a consensus on this issue last year. Will this time be any different? What does this all mean for the industry and transcoding vendors like Dialogic?
Let’s recap where we were on this debate a year ago:
For more details see my post from last year on this.
It was obvious that that consensus would not be reached in the March 2014 IETF meeting, so this topic was tabled until now. It was hoped movement in the market would help push consensus in one direction.
Here we are, a year later. Has anything changed?
It turns out a lot - here is the run-down of where we are since last year:
I have no idea. This is a good one for the sportsbook in Las Vegas. Both sides have made progress. I give a slight edge to H.264 with Microsoft working on WebRTC in Internet Explorer and Nokia’s patent trolls still lurking, but a slight edge doesn’t cut it when you need consensus. My guess is that there will continue to be no MTI, but we’ll have to listen to the debate. There is room for creative solutions, like only forcing browser vendors to do both but not mobile app developers.
Unfortunately, that is wishful thinking.
No one has ever liked to transcode. Transcoding is inefficient. It adds cost. Transcoding is a failure on vendors and standards to come up with a better way.
However, despite all of this, transcoding has been a fact of life in the PSTN and VoIP worlds for decades. Try as you might, you will always find older device in the network that does not support the codec you want. There will always be a new codec that you want to support, but that is not supported everywhere. That’s just how networks always end up – new technologies – including codecs - are always introduced faster than the old ones are removed. Implementations become fragmented and then someone figures out a way to bridge them. Do your best to limit transcoding, but in most cases you will not be able to avoid it forever.
WebRTC certainly shouldn’t aspire to start out this way, but sadly this history is likely to repeat itself in WebRTC eventually.
Like many vendors, transcoding is one of the things we do. In fact, software transcoding in our PowerMedia XMS it is one of the things we really well, but is not the only thing we do or the thing we prefer to do. It’s simply not tenable to build a product only does the one thing everyone hates doing. To make our customers who have to transcode hate it less we have been making it easier to do and cost less.
We hope consensus is reached in the WebRTC Video MTI codec discussion to help accelerate market adoption. Even though our transcoding feature set could potentially benefit from a lack of video MTI, the whole market would suffer from a more limited adoption of WebRTC. Speaking as a commercial vendor, we all stand to gain by growing the WebRTC rather than trying to divide it. There are plenty of other higher-value features to sell beyond transcoding.
Let’s all root for progress to be made at IETF 91 in Hawaii. Perhaps there should be a rule that no one can go to the beach until consensus is reached. That would be sure to force some progress.
I will speaking about this topic and other media-related issues during the WebRTC Expo in San Francisco in the next weeks. I am also at the TADSummit in Istanbul this week. Contact me here if you would like to talk at either of these shows.