Hey Guys, I was able to setup ad run a demo. It was gr8!!. I have a couple of questions lingering in my mind though. I would like to understand how communication happens btwn all these servers. All my questions is based on below diagram
Are video streams ALWAYS pass thru openviduserver through Kurento as below?
[Client-A–>OpenviduServer–>Kurento]
Then, what does Client-A communicate with its direct connection to Kurento [in Diagram]?
Also, if mediaMode=ROUTED means video travels always via server then, P2P never happens even if STUN finds that the clients are capable of it?
As i understand “TURN” server is the one that actually relays traffic of video streams between clients. If video is transmitted btwn clients using “TURN” then what is the role of “Kurento” here? Sorry, this question may be because i didn’t understand well on Kurento and TURN [Bare with me please]. I guess Kurento is somehow using TURN for this video transmitting? my be i am wrong.
The diagram in help documents always shows how a client is connected to the server. But i never found one on how end-end communication happens from client-A to client-B? Is this something you can add in the documents and also connect the dots in the above diagram?
Streams always go from client to Kurento, and from Kurento to client (except situation 2.) So, for a stream being send by Client A and received by Client B:
Client A -> Kurento -> Client B
OpenVidu Server only acts as signaling server (sending negotiation messages between clients and Kurento to establish the WebRTC connection) and as logic server (calls Kurento API in order to properly establish the Media Pipeline according to what the developer requires from OpenVidu Server API). No P2P connections directly between clients right now, but is something contemplated in our roadmap.
TURN server only comes into play when some client is behind a NAT (a complex network such a corporate network). Then, TURN acts as a relay server, allowing Kurento to send the WebRTC stream to the client through it.
As already answered, direct connection between clients never occur. All of the media streams pass right now through Kurento.
Thank you so much. I get it now. Have one more question though.
Is it possible to run the openvidu server [signaling and REST] in two different ports? Reason - i want the session/token creation to be triggered from within my own app server and not expose that [REST] to the outside world [even though BASIC AUTH] is there.
OpenVidu Server exposes only one port to the public. And this port is used for both REST API and websocket endpoint for clients. So unfortunately what you want is not possible right now. Nonetheless the SECRET should be enough protection.
i’m trying to understand some webrtc and openvidu concepts. I haven’t figure out yet how the connection is established using SDP and ICE candidates but i would like to make two questions:
When we run the docker image like the tutorials say so, how many servers do they run? Is the OpenVidu Server a real server? Because on OpenVidu Docs
(the image is not there for some reason!), the OpenVidu Server is written as openvidu-server and it is described as an “application”.
What happens in webrtc terms when we use session.connect(token) between the peer and the openvidu server?
The docker image contains two services: OpenVidu Server (implemented in Java) and Kurento Media Server (implemented in C/C++). These services are included in the same docker container only for convenience while development. In production those services are deployed in two different containers.
Nothing. Session connect is just a WebSocket connection between browser and server. WebRTC protocol is used when you publish your camera (or screen share) or subscribe to a remote Stream.
