The Openvocs core architecture is composed of a frontend facing core and a backend core. The frontend facing core includes 3 components.
- a webserver
- a signaling server
- a media proxy
A client connects via HTTP to the webserver and downloads a HTML5 based software client. This software client connects to the core systems signaling server via websockets and to the media proxy via a WebRTC connections. Websockets are used for signaling information like state changes within a Voiceloop (e.g. Switch on or off a Voiceloop or change the volume of some Voiceloop). WebRTC connections are used for media distribution between the client and the backend.
The components Webserver, signaling server and media proxy build the frontend connector of the core system and are primarily used for Media Setup and Media Channel (Voiceloop) selection.
The inner core system of openvocs is pretty simple too. We use Media Mixing Microservices, which are controlled by the frontend via signaling messages. Media distribution within the backend is done by Multicast. Each Voiceloop has a dedicated Multicast IP. A Mixing Service will collect all Voiceloops a user has selected and mix a stream of all of the Voiceloops. The stream is forwarded to the media Proxy, which forwards the mixed stream via WebRTC back to the client. The incoming client voice stream at the media proxy will be forwarded to the Multicast Groups of the Voiceloops selected for Talk. Each client connection uses a dedicated media proxy session and mixing service.
Each openvocs system is composed of a 3 LAN infrastructure. The outer LAN or WAN is where clients are located. This LAN segment is seen as unfriendly and all messages are encrypted by default. The inner LAN of openvocs is used for command and control actions and must be seperated by the client LAN. Within the command and control LAN services will be connected and assigned within specific client sessions. The 3rd LAN infrastructure is the multicast audio LAN for transmission of audio channels.
At the border between WAN and LAN are the ov_mc_vocs instance, as well as the ov_mv_ice_proxy instances. ov_mv_ice_proxy services are Session Borders for WebRTC connections. They control the media flow within the system. Each ov_client instance will be connected to one ov_mc_ice_proxy service and form a dedicated endpoint within the instance. These endpoint is the transmission node of media streams.
Next to multiple ov_mc_ice_proxy services the system used a ov_mc_mixer microservice architecture for media mixing. These mixers are idle by default, but may be assigend within a user session to serve a dedicated client endpoint mit media mixes.
The last service within the core system is the ov_mc_vad service, a service responsible for voice activity detection and information.