WebRTC: Upgrading to Chrome 23

This post attempts to document some of the issues that I encountered with the upgrade to Chrome 23.  I hope it might be useful to other WebRTC developers faced with similar issues.

Peer Connection00 is dead!  Long live RTCPeerConnection
Up until a couple of days ago we have been using the PeerConnection00 API to provide WebRTC on Drum.  This worked fine until 7th November when Google pushed out the new version (23) of Chrome stable.  This version deprecates the PeerConnection00 API which leaves the (subtly different) RTCPeerConnection API as mandatory for WebRTC.
The RTCPeerConnection API had been available for quite a while on the development release of Chrome (Canary) and we had taken the opportunity to get acquainted with it at Drum.  In fact we had developed a new version of Drum that would use the new API.  But, since we didn’t want to upset the apple cart we had held off from deploying it to the live system.  I had rather expected that there would some fanfare about the new release on the Chrome dev-list which would give us some notice that the change was about to happen.  Unfortunately, no timely reminder was forthcoming so we had little time to integrate with the new API on the live systems.  But, that’s the joy of working on the cutting edge!
The first thing we noticed was that the offer SDP now includes both an audio and video session even though the media constraints specify an audio connection only.  Applications which assume that the media constraints will be honoured as is, will need to be hardened to cope with that. Looking at Canary it looks like this has been fixed so I won’t trouble the Chrome team with a bug report.
We realise that it may take a while for all Chrome users to upgrade to the latest version 23.  For this reason we will support PeerConnection00 and RTCPeerConnection in the browser.  This should allow for a seamless upgrade path for Chrome users.  We achieved this by adding a thin shim around the PeerConnection access within the browser code.
The biggest head scratcher that we faced was an early-2009 MacBook that produced RTP which the server complained about.  According to the server the SRTP authentication failed.  All other laptop/OS combinations worked just fine.  If anyone has any ideas on why this one fails please leave a comment below before the MacBook goes in the dustbin!
More worryingly is that at the moment we don’t hear any audio on the current Chrome Canary.  We see the RTP being delivered but there is no sign of it being played.  It’s working fine on Chrome stable so I assume its something to do with the adoption of the RFC5245 for ICE (even though we currently set the option for backwards compatibility until the server complies).  I have raised this as an issue.
In conclusion, this API change has identified a few issues with our use of WebRTC but it was a piece of cake compared with the change from ROAP to JSEP.  Hopefully, now the WebRTC standard is converging further updates will be a lot easier!!
What is your experience?   Have you had similar issues with Chrome 23?
Dr Richard Screene is a Senior WebRTC Developer at Drum.  Richard has over 20 years experience of development for communication protocols.  He is currently responsible for integrating the Drum web and audio conferencing products using WebRTC.
Richard has experience in development of software for circuit switched protocols and recent projects have involved LTE and SIP. With an in-depth knowledge of  C/C++, Java, Javascript and shell scripting,  Richard earned a PhD degree in Electronic Engineering from Manchester Metropolitan University.  Richard also holds a master’s degrees in Computer Communication & Networks from Leeds Metropolitan University and a bachelor’s degree in Computer Science from the University of Leeds.

Leave a Reply

%d bloggers like this: