The AddLive Platform is composed of several high-level components that are depicted in the figure below. A complete description of each component and the interactions between them will be covered within this section.
1. The API Bindings
The AddLive API bindings provide access to the features provided by the service. AddLive offers:
- JavaScript bindings for web application developers,
- Objective-C bindings for iOS developers,
- Java bindings for Android developers,
- C bindings for native desktop (Win and Mac) developers.
The API bindings provide unified access to the underlying AddLive Service Container and AddLive Service and ensures that the AddLive API is consistent across all supported platforms. There might be some slight API differences (mostly when it comes to rendering video feeds), but all the methods, their parameters and results are the same.
2. The AddLive Service Container
The AddLive Service Container allows the browser plugin to auto-update. This means that only one install of the plugin is ever required on each machine.
3. The AddLive WebRTC Service
The AddLive Service is a major part of the AddLive Platform. It is the component where many of the features offered by the Platform are implemented.
It interacts with the user’s Operating System and with multimedia devices (microphone, camera, speakers). It also uses the networking stack to communicate with the AddLive Streaming Server. The communication between Service and Streaming Server is performed using 2 links:
3.1 Management Protocol
The management protocol uses TCP/IP for data transmission, and so is considered a reliable transport mechanism. Additionally, for security purposes it uses the SSL sockets with TLS v1.0. The main use case for this link is presence tracking and reliable messaging between peers.
3.2 Media Protocol
The media protocol is responsible for transmission of user’s media data (voice, video) between peers. Internally, it uses multiple transport mechanisms with a failover mechanism. The RTP/UDP in P2P protocol is the most efficient and is used when there are only 2 participants connected to given media scope, and UDP communication is permitted. The second most efficient transport mechanism used by the media link is RTP/UDP with the AddLive Streaming Server as a relay server. If UDP is not permitted, the media link will fall back to RTP streaming over HTTPS. This method will add latency, which forces the service to use a lower quality video stream, but it will work for any connection on which UDP communication is blocked.
Additionally, the media link is secured using the SRTP protocol. Keys used by the SRTP are generated upon media scope creation and then exchanged using already secured management link.
4. AddLive WebRTC Streaming Server
The AddLive WebRTC Streaming Server has three main functions:
4.1 Signalling
The Server is responsible for the initialization of media streams by negotiating the connection between the peers, and for the authentication of each participant.
4.2 NAT and Firewall Traversal
Many users operate behind NATS and firewalls. The server allows these users to communicate by traversing these devices. This includes relaying UDP media through the Server, and if UDP is not available, the system will fall back to HTTPS communications.
4.3 Multiparty Relay
In order to efficiently allow for multiparty communications (more than two users in session), a server is required to relay all the audio and video streams. This server constantly monitors the video downlink capabilities of each user (in terms of loss, delay, jitter) and dynamically controls which video layer is sent to each participant.