WebRTC Book First Edition Updates

Corrections

Section 6.3.7, p. 96

"approach such as XHD" should read "approach such as XHR"

Section 2.1, p. 14, Figure 2.1

"Attach media or data" should read "Attach media or add data"

Section 2.2, p. 23

"The details of the messaging between the elements of Figure 2.10 is shown in Figure 2.11." should read "The details of the messaging between the elements of Figure 2.8 is shown in Figure 2.9."

Omissions

Section 2.3, p. 23

"You should in particular be aware of the following: no HTML code is shown, although the outputs (display, speakers, etc.) are assumed to have been set up; the media constraints shown have not been defined, although constraints similar to them are under discussion; and finally, real code would have error handling, but this has none."
should read
"You should in particular be aware of the following: no HTML code is shown, although the outputs (display, speakers, etc.) are assumed to have been set up; proper handling of the asynchronous returns (callbacks) would require either careful handler sequencing code or use of a library providing support for promises or futures; the media constraints shown have not been defined, although constraints similar to them are under discussion; and finally, real code would have error handling, but this has none."

The following index belongs at the end of the book:

Index

New Developments

Internet draft draft-ietf-codec-opus has just been published as RFC 6716 "Definition of the Opus Audio Codec". This updates pages 97, 102, and 104, and Table 6.2.

The audio parts of draft-cbran-rtcweb-codecs have been adopted as a Working Group item by the RTCWEB Working Group and have been published as draft-ietf-rctweb-audio. This updates page 97 and would add a new row to Table 6.1.

The WebRTC specification now contains a new statistics reporting capability on RTCPeerConnection. The new getStats() method uses a callback to return a new RTCStatsElement structure for the given MediaStreamTrack. This structure contains, for both the local and remote ends of the track, an RTCStatsResult object whose getValue method can be used to query the value of any statistic for that track. Although a variety of IETF protocols have standardized network statistics that can be reported, the WebRTC specification does not have yet have a registry defining the set that must be supported for WebRTC. This subject will be discussed more fully in the next edition.

The WebRTC specification now contains a new identity verification capability on RTCPeerConnection. Although DTLS, SRTP, and other protocols already in use in WebRTC can ensure that data is secured from the local brawser to the remote brawser, they do not guarantee that the individual user at the remote end is the one the local end expects. To address this, the specification now provides a mechanism for verifying the remote party is the expected one. It does this via an Identity Provider, a known site with a protocol for allowing a named user to log in or otherwise verify the user's identity. The Identity Provider can be set in the browser itself or via RTCPeerConnection.setIdentityProvider(). If either is set, an identity will be requested whenever createOffer() or createAnswer() is called. However, the process of obtaining an assertion can be started before any SDP is generated by calling RTCPeerConnection.getIdentityAssertion(). Once verified, the identity will be saved in RTCPeerConnection.peerIdentity and a negotiationneeded event will be fired.