RTCPeerConnection is the main object in WebRTC for sending media and data peer-to-peer. The API is constantly evolving and a recent trend has been to add accessors to more “low-level” information, such as ICE and DTLS transport information. A major update is the RTCRtpSender/Receiver objects, that let the script have more control over how a MediaStreamTrack is sent, and even replace the track with an other – without negotiation.
Another big API update is the move to a promise based API for the asynchronous function calls. Don’t worry, the callback-based API is still supported, but it is considered legacy, and you should really use the promise-based API.
The RTCPeerConnection implementation in WebKit was much in need of an update. That is why we are happy to announce that we have upstreamed a polished RTCPeerConnection API to the WebKit repository. It does not have all of the latest features, but it is in good shape with some of the new additions/changes listed below:
- Overloaded calls that support both the new promise API as well as the old callback-based one
- The new promise-based operations queue
- RTCPeerConnection.addTrack() that replaces addStream()
- RTCRtpSender/Receiver objects
- The new “current” and “pending” local- and remoteDescription attributes
In addition to the updated RTCPeerConnection API, we have also upstreamed the PeerConnectionBackend interface. It is a WebCore (which in turn is the library handling layout and rendering in WebKit) interface that lets WebKit ports use different WebRTC backends more easily. So OpenWebRTC could run alongside Google’s webrtc.org backend for example.
This is the first step in the process to upstream a runnable WebRTC solution to the WebKitGTK+ port powered by OpenWebRTC. Other ports will also be able to reuse a lot of functionality if they wish.
More information will be posted here as we progress.
