Twilio-video.js: recordingStarted is not firing!

[alielkhateeb]

Hi, my room Sid is RM38b18e8058d6bb3d93004b0ea76ea418
I don't know why although room.isRecording is true, but the event recordingStarted never fires.

This is my code:

room.on('recordingStarted', () => {
    console.log('Recording Started...');
    roomRecordingStarted = true;
});

I notice in the Twilio console logs, that the room duration is 24 seconds, but the recordings for this room are 17 seconds only, so I would expect 7 seconds after room is joined this event should be fired but it doesn't.

What could I be doing wrong?!

Thanks!

[alielkhateeb]

@markandrus Sorry for spamming you but this is a bit urgent. And I actually have no clue if there is a channel for urgent issues or a slack or so. Thank you!

[manjeshbhargav]

Hi @alielkhateeb ,

Thank you for your question. "recordingStarted" will not be fired if room.isRecording is already true right after you joined the Room. So what you're experiencing is expected behavior.

Thanks,

Manjesh Malavalli
JSDK Team

[alielkhateeb]

Thanks for the response @manjeshbhargav

But this is imo wrong behavior I consider it a bug, as per the room Sid I shared above the room duration is approximately 7 seconds more than the audio and video recordings' durations, if room.isRecording is true as soon as I joined the room then why do I have this 7 seconds missing in my recording files?

How will I know when did the recording actually started?

Thanks

[markandrus]

Hi @alielkhateeb,

I looked at the Server-side logs for your Room. I see that the singular Participant in your Room connected, and then, 3 s later, we detected an ICE failure. ~1.5 s later, we see ICE reconnected. Since the ICE connection is responsible for delivering your audio and video to the Server, during this approximately 4.5 s the Server is not receiving any media, therefore it is not increasing the length of the recording. There may be some delay before detecting the ICE failure, so the 4.5 s may be less than the actual amount of time that ICE was disconnected. @igracia, can you please let me know if my analysis is correct?

Thanks,
Mark

[alielkhateeb]

Hi @markandrus,

Thanks for checking, so is this a bug? I am doing a video interview app and I am using the recordings so that candidates can answer a question, so I don't want to miss any seconds in the beginning of a recording (answer). I'll wait for @igracia to confirm and would you please let me know if there is anything I can do from my side? cause all the rooms I create go through the ICE failure (I guess) cause all of them have these few missing seconds in the beginning.

Let me know how can I help.

Regards,
Ali

[alielkhateeb]

@markandrus
So I understand from the thumbs up that he confirms the analysis, so what should I do from my side to avoid this ICE failure, if there is anything to do from my side?

[igracia]

Hi @alielkhateeb,

@markandrus analysis is correct. The fact that you see your local video in your screen doesn't mean that the video is actually getting to the server, and thus recordings might be shorter than what you expect. I'd recommend making some tests with two clients, client1 and client2. If client1 sends video to client2, and provided that client2s negotiation goes well, you should see in the recording from client1 what client2 was showing. does that make sense? I'm not sure there's anything you can do to prevent ICE failures, as those depend on network conditions.

About recordings, the recording-started callback is quite accurate, so you might use that to know when your recording has started recording data. If you don't receive that event, it means that the media is not flowing to the server.

P.S. Sorry, forgot to hit "Comment"

[markandrus]

Thanks, @igracia.

About recordings, the recording-started callback is quite accurate, so you might use that to know when your recording has started recording data. If you don't receive that event, it means that the media is not flowing to the server.

To be clear, there is a recording-started Status Callback issued by the REST API. This is distinct from the recordingStarted event in twilio-video.js. Actually, recordingStarted shouldn't fire at all in twilio-video.js. It's only meant to signal changes to recording state in the Room (which is not yet implemented server-side); therefore, a Room will either have isRecording set to true or false at connect-time and never change.

@alielkhateeb

so what should I do from my side to avoid this ICE failure, if there is anything to do from my side?

Unfortunately, there is not much you can do if one of your users changes networks and temporarily loses connectivity except, unless you are willing to take recordings client-side on the device themselves and push those up later.

I will close this issue for now, but feel free to re-open it.