A new version of Chrome is out, and with it changes in the WebRTC stack. We dug through the commit logs for Chrome 26, and found the following list of WebRTC bug fixes, enhancements, and updates that we thought were relevant to the OpenTok community:

Highlights

• A lot of audio bugs in WebRTC were fixed dealing with crashes and non-standard audio bitrates
• Chrome on Android can now be WebRTC-enabled by enabling a flag
• Improvements to the connectivity stack in WebRTC
• Ability to set media constraints for audio

Full list

• Avoids crash in WebRTC audio clients for unsupported capture sample rates.
• Avoids crash in WebRTC audio clients for 96kHz render rate on Mac OSX.
• Enable webrtc build on android.
• Set WebMediaPlayerMS network state to loading instead of loaded
  • This indirectly fixes the problem where WebRTC audio is muted upon refresh. The HTMLMediaElement will try to cache fully Loaded videos when the element is destructed. This will signal to the HTMLMediaElement that the player was destroyed when loading, so it needs to recreate WebMediaPlayerMS upon destruction of the media tag.
• Allowing multiple MediaPlayers to connect to WebRtcAudioDeviceImpl by sharing one WebRtcAudioRenderer.
  •  The audio is gone when new PeerConnection is connecting to a media stream. What is happening is that the stream will pause the existing MediaPlayer and create new MediaPlayers to associated to it. But since we only allow one WebRtcAudioRenderer to connect to WebRtcAudioDeviceImpl, the new MediaPlayers audio won’t be able to associate to stream.

About six months ago, Microsoft released an alternative proposal to the W3C WebRTC 1.0 Working Draft[2], dubbed CU-RTC-Web[1]. Like all W3C groups, the WebRTC Working Group enlists membership from a majority of the industry, including names like Nokia, Cisco, Google, and Mozilla. The most important question raised by the Microsoft proposal is how the Working Group would react to criticism of its draft proposal, and whether Microsoft would accept the published APIs of the Working Group, even if CU-RTC-Web is not adopted. So what exactly does this mean for the development community?

The Microsoft draft outlines a low-level API that allows developers more direct access to the underlying network and media delivery components. It exposes objects representing network sockets and gives explicit application control over the media transport[3]. In contrast, the WebRTC API abstracts these details with a text-based interface that passes encoded strings between the two participants in the call. With the WebRTC draft, developers are responsible for passing the strings between communicating browsers, but not explicitly configuring media transport for a video chat.