Twilio-video.js: Request: Add max duration option to API created rooms

[carterbryden]

It would be very helpful if we could set a maximum duration for rooms created with the API, similar to max participants. After that max duration is reached, it disconnects any connected participants and refuses any further connections for that room. In order for participants to reconnect again, that room would have to be recreated or updated via the API.

This would let us easily set a guaranteed upper limit on potential costs that could otherwise be racked up by users simply leaving a video session on and forgetting about it, which wastes Twilio's resources for no real purpose.

[rfbrazier]

Hey @carterbryden, thanks for the feedback.

Some questions / thoughts on how this might work:

• As you know, Rooms can be given a UniqueName which is then used as an address for the Room. Supporting the feature you've outlined might require that you never re-use the same value as a Room's UniqueName (or just rely on Twilio's Room SID as the canonical address). Any concerns?
• Right now we allow you to create Rooms from the client (when Client-side Room Creation is enabled in the Console), or create them via the REST API. Would it work for you if this feature required that you disable client-side Room creation, and exclusively use the REST API?
• How would you want to be notified when a user attempts to connect to a Room that no longer exists? Just an error raised client-side, or a webhook status callback as well?
• Since it looks like your primary goal is to limit costs generated by idle/inactive users, would it be better if Twilio instead raises an event to your app any time a Participant is idle and alone in a Room for a given period of time, and then ejects the user if your app does not respond to indicate the user should remain connected?

Looking forward to your feedback. Thanks!

[carterbryden]

Hi @rfbrazier, that's a fantastic response and I appreciate the serious thought put into it.

• I think being unable to reuse room names might actually be a much bigger problem for some dev use cases than having to build their own duration management features. I had assumed that the SIDs were all unique and never re-used, so that room names could be reused (and would only refer to the current or last active SID/Room). If I could only set max duration by SID, would that allow for room name re-use? I guess I'm just not really sure how having a configurable max duration and a reusable room name are related, since we have SIDs.

• If you were to go ahead with it, I think requiring that the client side creation be disabled makes a lot of sense, since I wouldn't want client side to be able to set their own duration.

• A webhook would be handy for some people I bet, though I likely wouldn't be using it in my case. Just an error client-side would be sufficient for me. I could see how people might want to track that though.

• Kicking after idle time without an app response seems like a decent alternative that I hadn't thought of. This would work best if it was an option on room creation (REST API) for how long to let them idle, with a default of letting them idle forever (or some very long length). I'm assuming this event would be through webhooks and then there would be a server side response? If so, including the current duration in that event would be handy so that we don't have to calculate it ourselves. Also it would have to give a reasonable amount of time for the app to respond in that case.

• The only concern I have with the idle kick method would be if more than one participant left their connection open. I think that's likely a very small number of cases, but also the most potentially wasteful/expensive. My particular use case is that a user is paying to have a video session with another user for a maximum of X minutes, which is why a max duration would be useful to me. That way if they've paid for 60 minutes, I can give them something like 90 minutes max duration for a bit of extra room and then not have to worry that they'll go over under any circumstances.

Thanks for the consideration!

[rfbrazier]

Great feedback, @carterbryden. We will take this into account as we evolve our Room model. We have been discussing long-lived Rooms internally this week, so this feedback comes at a good time.

Will let you know when we have more information on this feature request.

[mhagmajer]

+1

I think that preventing abuse of the video features is a valid conern. Idle participant events would be a great solution so would putting a limit on room duration.

[vladimirmoushkov]

Any development regarding the rooms expiration?

[jishindev]

Hey @rfbrazier,

Has this request been considered yet? What updates do we have on this? Would be great to have a max duration parameter that we can set to each room through the REST api for our use case.

[kshitijrao]

Hey , has this enhancement being implemented yet ?or can u add this feature in the twilio dashboard itself?

[innerverse]

Hi @kshitijrao

This feature is on our backlog, but currently we do not have it on our roadmap. As a solution, you can use the REST API to set the Room status completed at your own time limit.

Thank you,
Seth
Twilio Video Team

[SebaLG]

Have being implemented yet? Or are there any kind of tips to do on your own?