Does OpenVidu support p2p VideoCall.
Do you have any idea about bandwidth sizing?
OpenVidu does not support P2P videoconferences. Media is always routed through a Media Server.
I m working on healthcare TELECONSULTATION platform, i would like to have an API for VIDEO conf between Doctor and patient.
OpenVidu does not support this use case?
I need help about sizing/pricing.
There is a way around this problem. OpenVidu officially doesn’t support P2P but we can still make it work. Here goes the idea:
NOTE: This is applicable only when you want to develop your own application using OpenVidu.
- DeviceA creates and joins a room using the application server SDK and the joinRoom RPC method.
- DeviceB joins in the same room using the joinRoom RPC method.
Now the idea is to NOT use the other RPC methods like publishVideo, receiveVideoFrom, etc for establishing peer connection between the clients and the server.
Instead, We will be making use of the sendMessage RPC method and server event to exchange offer, answer, and ice-candidates information directly between DeviceA and DeviceB.
-
As soon as DeviceB joins the room, DeviceA will receive the participantJoined server event with the DeviceB’s connection ID. We need the remote connection id as we will be using it with the sendMessage RPC method.
-
So once participantJoined is received at DeviceA, DeviceA creates the offer SDP and sends it to DeviceB using the sendMessage RPC method by mentioning DeviceB’s connection ID.
-
Once DeviceB receives the offer SDP from DeviceA, DeviceB creates the answer SDP and sends it back to DeviceA via the same sendMessage RPC method.
-
Same goes for sharing ICE candidates. Use the same sendMessage RPC method to share ICE candidate data across the 2 devices.
-
Once the best possible candidate pair is found, the peer connection will establish between the 2 peers in a P2P manner (depending on the candidates though srflx, host, relay, etc).
With this approach, P2P is possible. It’s an overall idea that actually worked for me where I wanted to have exactly 2 participants only. Anyways with this approach, you can even make MESH architecture work to support multiple participants and WebRTC data channels as well which is not supported yet by OpenVidu.
That’s actually really clever, so you are using OpenVidu basically to exchange information via websocket, taking control of the users via OpenVidu API and using the TURN deployed for connectivity between peers.
Just curious, why would you prefer that instead of controlling the network mesh using your own service?