Información y comunicación

A key piece of functionality defined in the WebRTC specification is the

RTCDataChannel interface, an API for a bi-directional data channel for

use over a Peer Connection. To create the RTCDataChannel, the aptly- named RTCPeerConnection.createDataChannel() method is provided. In addition to an application-settable label, the method also takes an optional dataChannelDict configuration object. The different properties of this object allow for control of two primary characteristics: reliability of the channel and whether ordering matters. In an ideal world, there would be no cost to having reliable, ordered delivery. In practice, however, perfect reliability would require infinite retransmissions, and ordered delivery would require an infinite buffer to collect out-of-order messages. The two attributes maxRetransmitTime and maxRetransmits are used to limit the reliability. The first allows the application to specify the maximum amount of time, in milliseconds, that the browser will continue retransmitting. The second allows the application to specify the maximum total number of retransmission attempts. Only one may be specified (without causing an error). The Boolean ordered attribute allows the application to specify, as you might have guessed, whether or not the data channel is to deliver the messages in order. The configuration object also allows for the application to set an id (or have it chosen automatically by the browser) and to specify that negotiation of new data channels will be handled by the browser (the default for

negotiated) rather than by the application.

The progress of the creation of a new RTCDataChannel is tracked by its readyState property, with values of connecting (the data channel is being established), open (the data channel is ready to be used), closing (the data channel is being shut down), and closed (the data channel has been shut down or was never established in the first place). Clearly there is a close() method on RTCDataChannel, as well as handlers that can be set for onopen, onclose, and onerror.

Once established, the data channel behaves similarly to a WebSocket, with a send() method for sending data and an ability to set an onmessage handler for incoming messages. Some of the details of data channels are still being finalized, but the general structure is fairly stable now. Future editions of the book will likely be able to include sample code.

5.3.1.3 DTMF API

Audio communication channels, when connected to today’s phone networks, need to be able to convey DTMF (Dual Tone Multi-

Frequency) tones. In particular, a JavaScript application sending audio into a SIP infrastructure will need a way to generate DTMF tones, since the audio may come from a generic microphone or other device without a DTMF keypad. However, it is during the negotiation of media for a Peer Connection that an ability to also send RFC 4733 DTMF packets is arranged. The specification thus provides an interface on

RTCPeerConnection to associate DTMF capability with a designated MediaStreamTrack for that RTCPeerConnection. This section adds a

method createDTMFSender() to the RTCPeerConnection interface that takes a MediaStreamTrack as argument. Thereafter, DTMF tones can be sent on that MediaStreamTrack over the Peer Connection via the

insertDTMF() method on the new RTCDTMFSender object. Note that

DTMF is inserted only on an RTCDTMFSender and not on the original

MediaStreamTrack itself.

5.3.1.4 Statistics API

The WebRTC specification defines an API for collecting statistics from the tracks being transported over a Peer Connection. This can be important for determining how many packets are getting through, for example. The API works as follows: getStats() takes a

MediaStreamTrack as input, along with a callback to be executed when

the statistics are available. The callback is given an RTCStatsReport containing RTCStats objects. Statistics are grouped into these objects by type, but all types contain id, type, and timestamp properties. Currently the only defined types are inbound-rtp and outbound-rtp, both of which are instances of the RTCRTPStreamStats subclass that additionally provides remoteId and ssrc properties. The outbound-rtp object type is represented by subclass RTCOutboundRTPStreamStats, which provides

packetsSent and bytesSent properties. The inbound-rtp object type is,

unsurprisingly, represented by the subclass RTCInboundRTPStreamStats that provides analogous packetsReceived and packetsSent properties. Together, these properties can be used to track both how much data is being sent on the track and how much is being received. Note that the

remoteId property can be used directly as a key into the RTCStatsReport

to pull out the report for the remote end of the current track. Regardless of type, objects in the report can easily be processed using a for loop to access each one.

5.3.1.5 Identity API

the other APIs in that the underlying use of a web Identity Provider is not supposed to require any action on the part of the web application, assuming that the browser has already been configured with a claimed identity and an identity provider. In theory, all the application needs to do is to set the onidentityresult handler that will be called whenever an identity has been verified since on one end the browser can automatically generate a signature for the configured identity and on the other end the browser can automatically pull up the Identity Provider’s verification JavaScript to verify the signature. In practice, however, the IETF draft (see Section 10.4) describing the underlying protocol requirements suggests that the signature itself needs to be transported using the signaling channel. Since the signaling channel is only used by the application JavaScript code directly, the application code would at least need to be involved in this step. In short, the specification is still vague in several respects. However the signing process is initiated, the signature conveyed, and the signature verified, the Identity API does provide a way for the application code to override the browser’s configured identity and Identity Provider – the setIdentityProvider() method on the Peer Connection. The API also provides the

getIdentityAssertion() method for applications that wish to start the

identity checking process in advance of the offer/answer exchange (when it would occur automatically on its own). This may improve the user interface responsiveness if the time to verify an identity is long due to user login time needs.