Recording Rules

Overview

There are two ways a Participant's video and audio tracks can be recorded in the cloud:

• Set the record_participants_on_connect flag when creating the Room. When this flag is set, recording of the participant's video and audio tracks starts when the participant connects to the Room. With this approach all participants' video and audio tracks are recorded by default.
• Use Recording Rules. The Recording Rules can be provided when the Room is created via the REST API or the rules can be set at any time during the lifetime of the Room via the Recording Rules resource.

The Recording Rules can be used to specify which participants and tracks should be recorded or not and they provide a fine grained approach for creating Recordings. For example, rules can be defined to simply start or stop recording or they can be defined so that only one participant in a Group Room is recorded. In addition, rules can specify if just the audio tracks should be recorded or both audio and video ones.

The Recording Rules API is only available in Group Rooms.

Contents

• The RecordingRules Resource
  • Resource URI
  • Get a Room's Recording Rules (HTTP GET)
  • Modify a Room's Recording Rules (HTTP POST)
• Understanding Recording Rules
  • Specifying Recording Rules
  • Recording Rules Semantics
• Examples

The RecordingRules Resource

The RecordingRules resource is a subresource of a Room instance resource. It represents the state of the recording rules for the specified Room.

Resource URI

For the sake of simplicity, we define the RecordingRules Resource URI as:

RECORDING_RULES_URI = https://video.twilio.com/v1/Rooms/{RoomNameOrSid}/RecordingRules

One list of rules can be specified using the Recording Rules URI per Room. It can be updated anytime during the life of the Room to include/exclude video/audio Tracks.

Get a Room's Recording Rules (HTTP GET)

Returns the current state of the recording rules of the specified Room.

Modify a Room's Recording Rules (HTTP POST)

Updates the recording rules of the specified Room. The following parameters are supported:

For a deeper understanding on how recording rules work, see the Understanding Recording Rules section below.

Other HTTP Methods

This resource does not support PUT or DELETE.

Understanding Recording Rules

Recording rules can be set at any time during the life of the Room. If the record_participants_on_connect flag is set to true during the Room creation then a default rule to record all video and audio tracks will be automatically set.

Specifying Recording Rules

A recording rule instance has the following JSON structure:

{"type": rule_type, filter_name: filter_value, filter_name: filter_value, ...}

Where:

Based on this, recording rules are specified as a JSON array containing up to 20 rules. For example:

Rules = [
  {"type": "include", "all": true},                              //rule_1
  {"type": "exclude", "kind": "video"},                          //rule_2
  {"type": "include", "publisher": "Bob", "track": "screen"},    //rule_3
  {"type": "include", "track": "MTXXXXXXXXXXXXXXXXXXXXXXXXXXX"}, //rule_4
  ...
  rule_20
]

Remember that valid recording rules comply with the following:

• The maximum number of rules that can be specified is 20.
• An empty set of rules (i.e. []) is not allowed.
• A rule containing the "all" filter must have a value of true. Notice that this means false is not allowed.
• A rule having an “all” filter cannot have any other filters.
• A rule must contain a "type" field.
• If the "kind" filter is used, its value must be either audio or video.
• A rule cannot contain duplicated filters (e.g. specify two different kinds or publishers)

When invalid rules are specified, the current active rules will not be updated and the POST will be answered with an HTTP 400 error response like the following:

{
  "code": 53120,
  "message": "Invalid Recording Rule(s)",
  "more_info": "https://www.twilio.com/docs/errors/53120",
  "status": 400
}

For example, the following requests are invalid:

//Invalid because it's using an empty set
Rules = []

//Invalid because it uses false as value of "all"
Rules = [
  {"type":"include", "all": false}
]

//Invalid because it specifies a non supported kind
Rules = [
  {"type": "include", "all": true},
  {"type": "exclude", "kind": "video"}
]

//Invalid because it repeats the "kind" filter twice
Rules = [
  {"type": "include", "kind": "audio", "kind": "video"},
]

//Invalid because an "all" filter is not compatible with any other filter
Rules = [
  {"type": "include", "all": "true", "kind": "audio"},
]

Recording Rules Semantics

RecordingRules are enforced by Twilio using three main principles:

1. Recording Rules semantics are based on Algebra of Sets.
2. Recording Rules are stateless.
3. Recording Rules are enforced declaratively.

1. Recording Rules Semantics are based on Algebra of Sets

We define the Set of Recording Tracks (SetRT) as the set of tracks a given Room should be recording at any time. The SetRT is computed by Twilio using Algebra of Sets based on the following algorithm:

• The SetRT is initialized to the empty set unless the record_participants_on_connect flag is set on Room creation.
• The subscribe rules are applied to the SetRT using Algebra of Sets in the order provided such that:
• For any include rule we perform the union of the SetRT with the set of tracks matching the rule filters.
• For any exclude rule we perform the set difference of the SetRT with the set of tracks matching by the rule filters.
• All the tracks remaining in SetRT after all the rules have been evaluated are the ones recorded.

If the record_participants_on_connect is set on Room creation then the SetRT is initialized to:

{"type": "include", "all": true}

Let’s illustrate this using an example. Imagine a Group Room with three participants named: Alice, Bob and Carl, who publish the tracks specified in the following table:

Notice that, for the sake of simplicity, we have assumed the following conventions:

• Track SIDs have the prefix MT followed by the participant initial and by a letter identifying the track nature (_A for audio, _C for webcam, and _S for screenshare).
• Track names are specified under their corresponding SIDs.

Example: Start Recording all Participants

To record the audio and video tracks of all participants in a Room, POST the following to the Room's RecordingRules resource:

Rules = [
  {"type": "include", "all": true}
]

Recording will start for all Participants connected to the Room. Any new Participants who join will also be recorded.

Example: Stop Recording all Participants

To stop the recording of all video and audio tracks of all participants in a Room, POST the following to the Room's RecordingRules resource:

Rules = [
  {"type": "exclude", "all": true}
]

This will stop the Recordings for all tracks. Note that Recordings can be started again some time later by reposting with the "include", "all" rule. New Recording SIDs will be created each time a track Recording is started.

Example: Only Record the audio tracks of all Participants

To restrict the recording to just the audio tracks of all participants in a Room, POST the following to the Room's RecordingRules resource:

Rules = [
  {"type": "include", "kind": "audio"}
]

Video tracks of participants will not be recorded.

Example: Record the video and audio of the one Participant and the audio tracks of all other Participants

In this scenario we want to record the video and audio of Alice while also recording the audio tracks of the other participants. To achieve this, POST the following to the Room's RecordingRules resource:

Rules = [
    {"type": "include", "publisher": "Alice"},
    {"type": "include", "kind": "audio"}
]

The video and audio tracks of Alice will be recorded and there will be an audio track Recording for any other Participant who joins the Room.

2. Recording Rules are stateless

The Recording Rules API is stateless. This means that it has no memory of rules. Every time a developer POSTs a set of new recording rules, the previous rules are fully erased and replaced with new rules, which are then enforced using the algorithm described in the section above.

3. Recording Rules are enforced declaratively

When developers POST recording rules to Twilio, those rules are enforced in a dynamic way. That means that the algorithm does not only execute at POST time, but it is executed every time there is change in the Room’s available tracks. Hence, once the rules have been POSTed, Twilio guarantees that they are enforced at any time without requiring further developer intervention.

Examples