Openvocs audio architecture is based on multicast network transmission and routing of audio streams. Each multicast IP:Port combination represents a dedicated Voiceloop. Assignment of Voiceloop to IP:Port combinations is done within the core service of openvocs, ov_mc_vocs.
Client to backend audio architecture is based on WebRTC media transmission. WebRTC is a media standard integratet in todays webbrowser environments and specified and described in detail at https://webrtc.org/ Using WebRTC for client termination implies to be compliant to the WebRTC standard within the backend. WebRTC uses a DTLS based secure communication channel to transmit precoordinated media streams. In case of openvocs the precoordinated media type is: Opus encoded audio.
ov_mc_ice_proxy is used to terminate WebRTC connections as connection endpoint within the openvocs system. Each Client Endpoint will have a dedicated ov_mc_ice_proxy endpoint counterpart, as the communication between client and backend is unidirectional.
ov_mc_mixer is used to connect to several multicast audio streams in parallel and to mix the audio of all of the connections it is currently connected to. This way the media stream for some client Endpoint is build. The mixed media is transportet to the ov_mc_ice_proxy connecting the client endpoint, secured using SRTP and transported as WebRTC media stream back to the client.
A decicated ov_mc_mixer instance and the logical endpoint within ov_mc_ice_proxy form a user session for the client endpoint. Every audio aspect of the connection is handled within that session.
Forwarding audio to some multicast stream is done via the ov_mc_ice_proxy instance. Media within the backend is per definition Opus encoded audio.
Switching a Voiceloop – what will happen?
Once a session for some endpoint is set, which means the WebRTC media connection handling is done as well as a mixer is assigned to the client endpoint, a user may switch on a loop for monitoring.
A switch loop message will be sent from client to ov_mc_vocs. ov_mc_vocs will check if the user of the client is allowed to monitor the loop. Once access is granted an internal message will be send to the ov_mc_mixer of the user session to actually switch on the loop. Audio will be mixed to the users receiving stream and forwarded to the ov_mv_ice_proxy for encrytion and routing back to the client.
Switching a loop to talk will be nearly the same, but after access control checking the message will be forwarded to the ov_mc_ice_proxy instead of the ov_mc_mixer, as incoming audio forward and routing is done within the ov_mc_ice_proxy service.