Object Real-Time Communications (ORTC) provides a powerful API for the development of WebRTC based applications. ORTC does not utilize Session Description Protocol (SDP) in the API, nor does it mandate support for the Offer/Answer state machine (though an application is free to choose SDP and Offer/Answer as an on-the-wire signalling mechanism). Instead, ORTC uses “sender”, “receiver” and “transport” objects which have “capabilities” describing what they are capable of doing, as well as “parameters” which define what they are configured to do. “Tracks” are encoded by senders and sent over transports, then decoded by receivers while “data channels” are sent over transports directly.

In applications utilizing the ORTC API, the relationship between the application and the objects, as well as between the objects themselves is shown below. Horizontal or slanted arrows denote the flow of media or data, whereas vertical arrows denote interactions via methods and events.

 

General Philosophy

The ORTC API allows a single transport to be used to send or receive media and data. The media can be sent or received on-the-fly without necessity of a round trip (re)negotiating to agree on the set of media encoding / decoding details with the remote side each time a change in media occurs. ORTC allows a simpler method of transmitting only the necessary RTP encoding / decoding information on an as needed.

Unlike WebRTC 1.0 API, the ORTC does not mandate a baked-in full SDP round trip offer/answer signalling to offer media and accept the media for each MediaStreamTrack change.

This allows the ORTC API to be compatible with alternative signalling models such as a real-time media capability exchange model. In this model, both sides announce their media encoding and decoding capabilities to the opposite side without the need for mutual agreement of how the media must be encoded. MediaStreamTracks can be attached and detached on-the-fly with only minimal encoding information being exchanged (or alternatively using the RTCRtpListener which could remove the need to signal entirely).

Main Objects

The ORTC API allows local media tracks from capture sources to be rendered as remote media tracks on the remote side. A pipeline of objects is configured to dictate how the media is encoded and decoded and transmitted over the wire to the remote side.

The sender side creates an RTCRtpSender describing the RTP encoding of the audio or video MediaStreamTrack. The RTCRtpSender is attached to an RTCDtlsTransport. The RTCDtlsTransport is responsible for establishing a secure DTLS session with the receiver and encrypting the media on the wire. The RTCDtlsTransport is attached to an RTCIceTransport. The RTCIceTransport‘s role is to discover and establish the best network path with the receiver side.

The receiver side creates an RTCRtpReceiver describing how the remote side has encoded the audio and video MediaStreamTrack. The RTCRtpReceiver emits a MediaStreamTrack which can be attached to a render surface for video or an audio play-out device for audio. The RTCRtpReceiver is attached to a RTCDtlsTransport. The receiver’s RTCDtlsTransport is responsible for establishing the sender side of the secure connection and decrypting the media coming from the wire. The RTCDtlsTransport is attached to an RTCIceTransport. The RTCIceTransport’s role is to assist the remote side in discovering and establishing the best network path with the sender side.

Related Objects

A few other objects play a role for both the sender and receiver.

The RTCIceGatherer is responsible for discovering all the possible network points that might be for the remote side. The RTCIceGatherer is also responsible for setting up relay connections via TURN in the event no direct network path is possible to the remote side.

The RTCIceTransportController object is responsible for freezing and unfreezing the testing of RTCIceTransport network paths in the event multiple RTCIceTransports exist between the same two connecting peers. This allows the testing of network paths to be optimized by testing on set of RTCIceTransports and reusing the results for other transports. TheRTCIceTransportController is also responsible for grouping RTCIceTransports for the sake of bandwidth estimation.

The RTCDtmfSender encodes legacy DTMF touch tones over an audio RTCRtpSender.

The RTCRtpListener is an object that can recognize unhandled RTP media coming from a remote sender. This allows the receiver to dynamically create RTCRtpReceivers without necessarily having had the remote side signal the details of the the RTP encoding in advance as long as the receiving side is able to pre-determine enough information for the sake of decoding the media.

Data Transport Objects

The API allows the developer to create RTCDataChannel objects on either side. The RTCDataChannel objects allows arbitrary text or binary data to be transmitted to the remote side.

The RTCDataChannel is attached to an RTCSctpTransport object that is in-turn connected to a RTCDtlsTransport. This allows both media and data to be transported over the same RTCIceTransport.