What is the Persistent Room feature?


Persistent rooms (also known as meetings) are rooms that only exist for a given period of time, after which they are destroyed. This is different from default rooms where the rooms are dynamically created and are session based. 


The scheduling of persistent rooms can be done via the SDK methods or direct REST API calls. Any given key can support either dynamic or persistent rooms but not both. This option can be changed at any time but changing it from persistent to dynamic will deactivate any currently schedule room contexts.


If a user tries to enter a room that is not scheduled or has expired, the "Meeting Records not found" error message is displayed.


How do I setup the Persistent Room feature?


1. Configure the Application Key persistent flag

This will configure all the Rooms tied to the Application Key as Persistent.




2. Create scheduled sessions for specific rooms

You can create a scheduled session by doing a REST call by POST to the Meeting Resources API.

(See Create Meeting Resources API doc)


On your application's UI, this will generally refer to to creating a scheduled video/audio call meeting. 


3. Retrieve scheduled sessions

You can retrieve the all the created scheduled sessions by doing a REST call by GET to the Meeting Resources API.

There are two types of REST calls that allows you to retrieve scheduled sessions for a specific room or scheduled sessions for all rooms in an Application Key.

(See Retrieve (for specific Room) Meeting Resources API doc)

(See Retrieve (for all Rooms) Meeting Resources API doc)


On your application's UI, this will generally be used to obtain and display a list of scheduled video/audio call meetings as calendar or list.


4. Delete scheduled sessions (optional)

You can delete created schedules session by doing a REST call by DELETE to the Meeting Resources API.

(See Delete Meeting Resources API doc)


On your application's UI, this will generally be used to a cancel (or delete) the meeting item.


5. Starting the scheduled session call

You can start the scheduled Room session by authenticating the connection via credentials format as found in the guide here.


You will need to provide the duration, startDateTime stamp and the generated credentials based off the Application Key secret, duration and startDateTime stamp.



What are the scenarios for scheduled Room session


a. Joining the Room without any scheduled sessions going on
The systemAction event triggers an action of SYSTEM_ACTION.REJECT and reason of SYSTEM_ACTION_REASON.EXPIRED.

b. While in a scheduled Room session, and session is expiring
The systemAction event triggers an action of SYSTEM_ACTION.WARNING and reason of SYSTEM_ACTION_REASON.ROOM_CLOSING.

c. While in a scheduled Room session, and session has expired
The systemAction event triggers an action of SYSTEM_ACTION.REJECT and reason of SYSTEM_ACTION_REASON.ROOM_CLOSED.



What is the difference between scheduled and non-scheduled Room sessions?

Connection started from scheduled Room sessions checks if there is any records that matches the given duration, startDateTime and credentials in the database (that is created with the Meeting Resources API). If there is not any, it will not start the connection.


Whereas connection started from non-scheduled Room sessions does not require checking of the duration, startDateTime and credentials but starts the connection immediately based off the given configuration (whether the authentication is credentials format or CORS format).


(See all of the Meeting Resources API doc)