We have recording setup based on the openvidu-recording-java example. We would like the recordings to be named in some identifiable way instead of the recording ID. I see that name can be passed. Perhaps I am missing how to do this using the recording-java example?
You need to pass the sessionID manually before joining session as recording ID is the same as sessionID.
Syed,
I see that there is an option to pass “name” which becomes the .zip name for the recording, but I can’t see where to implement that based on the existing openvidu-recording-java example.
Just to provide further detail. When using the openvidu-recording-java example, the user is prompted for a session/room name, for example, “RoomA”, and enters this before entering the conference. During a conference the user records the session. Following the conference within the recording section of inspector, the conference is referenced by the unique session/recording ID, an alphanumeric string similar to “fdt457gsk23md3” and no reference to the user entered string “RoomA”. This makes locating a conference on a busy system with a high record rate extremely difficult. I see in the API that there is a Recording “Name” variable which is used instead of the alphanumeric string. I was hoping to change to use UserString_RecordingID, so in my above example RoomA_fdt457gsk23md3 as this would be the recording identifiable and also unique.
Any feedback or suggestions?
Let me recap:
First of all, the entites provided and managed by services such as OpenVidu or any other API-based service you can think of, will always be defined by a unique identifier. This uuid is usually generated internally by the platform and is available for the user to launch operations against that particular entity.
Okey, now we have established what is the nature of a unique identifier. Now, you are saying that you struggle to make sense of the recording entities accumulated in OpenVidu Server. Let’s make this next point clear: developers are responsible for managing the recording entities and their association with any other OpenVidu entity. What this means is that whenever a Recording is started or stopped, the appropriate events are perfectly and unequivocally associated to their Session. They bring all of the necessary information to properly identify that unique recording. Take a look to server-side event RecordingStatusChanged: sessionId property is telling you that the recording changing its status belongs to that specific session.
That being said, we could have just decided to build the recording identifier with a completely random string, and that would have been perfectly fine, as long as the recording entity dispatched by server events is associated to a specific sessionId. In short, we could have decided that the sessions would be identified by an id like this: j83ufiahjpwj2d89tufjapefq and recordings with an id like this: pkmaff02nfkos0jf2f and that would be fully funcitonal and technically correct.
But to make developers life a little bit easier, we decided to build the recording IDs from their session IDs. So: any recording will get an id equal to the id of its session. If the session was previously recorded (so there are multiple recordings for the same session id), a “-1”, “-2”, “-3”… suffix will be appended at the end of the session id. Besides, you can pass parameter “name” when starting a recording, so the final generated file will be named after that property making it even easier to identify.
You are mistaking the application’s server side room identifier with the real OpenVidu session identifier in the openvidu-recording-java tutorial. The session ID is not “RoomA”, that’s the string the server app is associating to session fdt457gsk23md3. That IS the real session ID. And that’s why the recording is given that ID. So yes, the recording is fully associated to the session. but you must manage the information the correct way. OpenVidu also gives the possibility of forcing the id of a session when initializing it (using parameter customSessionId), so you can technically force “RoomA” as the session id if you want. The recording woud then also be given “RoomA” id.
I agree with this and understand this 100%.
However, when a conference is required to be recorded it is usually done so due to a requirement - compliance, regulatory or whatever.
Users of the application do not (usually) see the underlying sessionID, or any of the OpenVidu parameters. The way it should be.
-
A user will simply say. I am Joe Blogs, I created a room called JoesRoom.
-
Then a person has the task of finding the recording.
The problem with the existing example is there is not enough data to match the above two points together.
This is where the recording “name” parameter would come in. My thought, to ensure uniqueness of the recording, was to populate “name” with _. I have tried this with the Java example but it doesn’t work. Very likely I am doing something incorrectly.
However, I don’t see a standard reason why this couldn’t be done in the example anyway.
The purpose of a recording is that it ties to an event. If you can’t tie it to that event, a conference, then the recording isn’t much good.
John
I still don’t see the problem. You must ensure in your backend or in your database, that the user is able to retrieve any recording he may want passing the “JoesRoom” parameter. The recording metadata has the necessary sessionId telling which session was JoesRoom.