The connecting time required at the start-up of a video conference (the time until a video image is displayed after choosing a contact) is substantially shortened. We can provide visual communication without making you wait.
Ricoh is working hard to provide all customers with comfortable visual communication (VC) through the RICOH Unified Communication System (RICOH UCS), our video conference system. This article introduces a "quick connecting technology" to immediately start the video conference system. It substantially shortens the time between the contact response (when the confirm button is pressed) to your request for conference until the video image of the contact is actually displayed on your screen, ready to start the conference.
In many traditional cloud-type video conference systems, because it takes more than five seconds from the time you attempt to connect to the contact until the voice and video image of the contact is actually heard or seen, we had to wait for the conference to start. Delays in or lack of a reaction by the contact during the wait might cause anxiety and stress. We may wonder if the system is working normally, if the network environment is good, or if the contact side is standing by over the network.
Fig. 1 Conventional video conference system
To overcome these problems, Ricoh shortened the connecting time when starting the video conference (time until a video image is displayed after choosing a contact) to 2.7 seconds(*1) , at the fastest. This was made possible by the "high-speed conference start processing technology by massive parallelization" and the "SFU (Selective Forwarding Unit) system." The RICOH UCS conference can be started in three easy steps after switching on power (*2): power up, select the parties you want to connect from address list, and confirm. Nevertheless, to speed things up, we focused on shortening the connecting time until the conference can actually start to make the video conference system easy to use, stress-free and quickly available like a telephone system.
Fig. 2 With RICOH UCS
RICOH UCS is not only used for video conference systems; it is also employed to provide face-to-face services such as the "RICOH multilingual interpreter service" (face-to-face interpreting service available anytime, from anywhere, connected from an exclusive application to an interpreter), and as a virtual reception service (remote reception system to guide visitors). This technology even enables us to provide face-to-face services without keeping visitors waiting.
Generally, a cloud-type video conference system comprises multiple conference servers deployed on the cloud service so as to be ready to deliver service stably, even when something goes wrong in a conference server or the network.
On starting a video conference, the system-side dynamically selects the optimal server from multiple conference servers based on server load and network latency, in response to the request transmitted from the terminal, and then performs initialization to start the conference. On the other hand, the terminal-side assigns devices to be used in the conference, initializes resources such as CPU and memory, and initializes various software modules.
Although in many cases the processes at the system-side (cloud service side) and the terminal-side are performed sequentially – one process finishes then another process starts –, with RICOH UCS, simultaneous parallel processing at the system-side and the terminal-side using a unique technology substantially shortens the time to when a conference actually begins.
Fig.3 Selection of the optimal server at the system-side
Multi-based video conference systems routed through a server have a method using an MCU (Multipoint Control Unit), and a method using an SFU (Selective Forwarding Unit).
At the MCU, the server-side synthesizes the images to be displayed at the terminal-side. Therefore, the server-side decodes the images sent from each terminal, synthesize the images, and then recodes them for transmission to each terminal. This takes time.
Fig.4 MCU system
In the SFU, on the other hand, the server only executes routing of the images to be transmitted. The server transmits the image sent from each terminal as is to the terminal requiring the image. At the server-side, as it does not decode, synthesize, or recode the images, there is less latency compared with the MCU system.
Fig.5 SFU system
RICOH UCS employs the SFU system, thereby shortening the time until the video images of the contacts (participating bases) are displayed on your screen. It achieves a real-time conference system with little video latency.