What are the cases of corrupted video recording?

[Wrufesh]

I have setup two openvidu servers on two different machines with same operating system. One is on public IP and another is inside VPN.

I am able to make a call using both setup. But with openvidu-server on VPN I am getting corrupted video whereas on another I am getting proper recorded video.

Also another difference I can see is with proper recording i am getting recording .info file and with corrupted I am not getting any .info file.

I am using openvidu-server v2.0.0.

[micaelgallego]

It seems there are more differences between two machines, not only the network connectivity.

Can you describe exactly what setup you have in both machines?

Un saludo.

Micael Gallego ElasTest Project Technical Coordinator - http://elastest.io Profesor en la Escuela Técnica Superior de Ingeniería Informática URJC

On Tue, May 15, 2018 at 11:52 AM, Rupesh Singh notifications@github.com wrote:

I have setup two openvidu servers on two different machines with same operating system. One is on public IP and another is inside VPN.

I am able to make a call using both setup. But with openvidu-server on VPN I am getting corrupted video whereas on another I am getting proper recorded video.

Also another difference I can see is with proper recording i am getting recording .info file and with corrupted I am not getting any .info file.

I am using openvidu-server v2.0.0.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/OpenVidu/openvidu/issues/50, or mute the thread https://github.com/notifications/unsubscribe-auth/ABBdKDEs4Hq-rNyaYkU0byfrIjCYL6Yiks5tyqVdgaJpZM4T_PBU .

[Wrufesh]

Both are Ubuntu 16.04 (xenial). And has followed Openvidu Deployment over Ubuntu section of documentation. And has used docker in both machines to run openvidu server.

Please let me know if I am missing some other detail of setup.

[micaelgallego]

Can you share the logs of openvide-sever container ni the failing machine?

Un saludo.

Micael Gallego ElasTest Project Technical Coordinator - http://elastest.io Profesor en la Escuela Técnica Superior de Ingeniería Informática URJC

On Tue, May 15, 2018 at 12:00 PM, Rupesh Singh notifications@github.com wrote:

Both are Ubuntu 16.04 (xenial). And has followed Openvidu Deployment over Ubuntu section of documentation. And has used docker in both machines to run openvidu server.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/OpenVidu/openvidu/issues/50#issuecomment-389112838, or mute the thread https://github.com/notifications/unsubscribe-auth/ABBdKBJYxiI_HbuI3JSwN4MI-Z6VUUGNks5tyqdFgaJpZM4T_PBU .

[Wrufesh]

Container Logs Here is the log of container.

[Wrufesh]

Also recording docker container persists ( when doing sudo docker ps ) even though all participants have left the session.

[micaelgallego]

That is the cause of the problem.. OpenVidu recording container is still recording...

Lets investigate the logs looking for the cause of the problem.

Un saludo.

Micael Gallego ElasTest Project Technical Coordinator - http://elastest.io Profesor en la Escuela Técnica Superior de Ingeniería Informática URJC

On Tue, May 15, 2018 at 1:00 PM, Rupesh Singh notifications@github.com wrote:

Also recording docker container persists when doing sudo docker ps even though all participants have left the session.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/OpenVidu/openvidu/issues/50#issuecomment-389127253, or mute the thread https://github.com/notifications/unsubscribe-auth/ABBdKG6J-vVqnNF9NASBgTPNFPMhUsOJks5tyrUwgaJpZM4T_PBU .

[Wrufesh]

I found this in one issue:

If openvidu-recording container is succesfully started but it is not properly disposed, this usually means that the property openvidu.publicurl with which you started your OpenVidu Server (in this case, the openvidu-server-kms container) and the URL that you are using in OpenVidu.initSession method in your Javascript code are not the same.

My setup seems alright compared to above statement. Also my app server and openvidu-server are in same machine so in order to connect to openvidu-server from app-server i have used "localhost:4443".

const OPENVIDU_URL = 'localhost:4443';
const OPENVIDU_SECRET = "MY_SECRET";
const OV = new OpenVidu(OPENVIDU_URL, OPENVIDU_SECRET);

Also my openvidu-server is on VPN. Thus ethernet (eth0) has a private IP and I think PUBLIC IP is achieved by port forwading. I suspect this may be the problem.

[Wrufesh]

Please give me some hint on how the recording container is not disposed properly? How can I debug this issue? What should I see for in log? Or please point me the code on openvidu server repo responsible for auto recording the session. @micaelgallego @pabloFuente

[Wrufesh]

I think I have found the cause. My server public IP doesnot support hairpinning. That is it cannot request to it public IP.

Thus I assume when openvidu-server needs to stop recording the openvidu-server request to its public IP to stop the recording but as it cannot request to its public IP the recording is never stopped.

I tried to host openvidu-server over 0.0.0.0:4443. Doing this: The token is generated with 0.0.0.0:4443 and then i replaced 0.0.0.0:4443 with my public IP. Doing so and trying to connect from browser it says unauthorized.

If I am true what can be the possible solution? Please :)

[pabloFuente]

Hi Wrufesh,

The URL that the recording container will use to connect to your recorded Session is built right here in OpenVidu Server code: https://github.com/OpenVidu/openvidu/blob/master/openvidu-server/src/main/java/io/openvidu/server/recording/ComposedRecordingService.java#L472

As you can see, it is generated using variable OpenViduServer.publicUrl, which is obtained during OpenVidu Server launching after configuration property openvidu.publicurl (this property can be set in the launching command. All available configuration properties are listed here).

We made the decission of using this parameter to connect the recorder client to OpenVidu Sessions to avoid internal issues specific to each server. But in theory it would be perfectly possible to connect the recorder client through localhost (or the proper IP through which the Docker container can access its host), as it is always launched in the same machine hosting OpenVidu Server.

We can study the possiblity of adding a new configuration paramenter to allow developers set the IP through which the recorder client inside the Docker container will connect to the sessions.

[Wrufesh]

Thank you for your answer @pabloFuente. Does it mean my assumption of the problem is correct? That is server with no hairpinning (pinging its own public IP) support will fail to dispose recording container.

[pabloFuente]

I can't confirm that assumption 100%, but it is the most plausible. Not only it will fail to stop the recording container, but if you stop it manually to avoid any corruption of the video file (you can manually do that by using the API REST), you will see that no video stream has really been recorded (probably you will get a non-corrupted but completely blank video). To sum up, the recorder client cannot connect to the session if the openvidu.publicurl IP is not valid inside the Docker container, and therefore no video at all will be received by the recorder.

And it fails to stop because for this particular type of applications (frontend-only), OpenVidu Server only automatically stops the Docker container when the recorder client is the only one remaining in the session as a participant. But there isn't really a recorder participant in the session at any time, because it cannot connect to it through the public IP.