Menu

Expand
Rate this page:

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

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.

Resource Properties in REST API format
room_sid
sid<RM> Not PII

The SID of the Room resource for the Recording Rules

rules
recording_rule[] Not PII

A collection of Recording Rules that describe how to include or exclude matching tracks for recording

date_created
date_time<iso8601> Not PII

The date and time in GMT when the resource was created specified in ISO 8601 format.

date_updated
date_time<iso8601> Not PII

The date and time in GMT when the resource was last updated specified in ISO 8601 format.

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:

Parameters in REST API format
room_sid
Path
post sid_like<RM> Not PII

The SID of the Room resource where the recording rules to update apply.

rules
Optional
post object Not PII

A JSON-encoded array of recording rules.

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:

Field Description
rule_type An identifier specifying the type of rule. It must be one of the following:
  • include: includes the tracks that match the filters into the Recordings.
  • exclude: excludes the tracks that match the filters from the Recordings.
filter_name and
filter_value
The filter_name must be one of the following:
  • all: the filter affects all tracks. Accepts only one value: true (matches all tracks)
  • kind: matches tracks of a given type. Accepts video and audio as values.
  • publisher: matches all tracks published by the Participant with the identity (case sensitive) or SID specified as value
  • track: matches tracks with the name (case sensitive) or SID specified as value.
A rule containing multiple filters matches the set of tracks that comply with all of them. In other words, filters combine in a rule through a logical AND.

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:

Alice (PTA) Bob (PTB) Carl (PTC)
Audio Track MTA_A
alice-audio
MTB_A
bob-audio
MTC_A
carl-audio
Video Track (cam) MTA_C
alice-cam
MTB_C
bob-cam
MTC_C
carl-cam
Video Track (screen) MTA_S
screen
MTB_S
screen

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

        
        
        
              
              
              
                    
                    
                    
                    Rate this page:

                    Need some help?

                    We all do sometimes; code is hard. Get help now from our support team, or lean on the wisdom of the crowd by visiting Twilio's Community Forums or browsing the Twilio tag on Stack Overflow.

                          
                          
                          

                          Thank you for your feedback!

                          We are always striving to improve our documentation quality, and your feedback is valuable to us. How could this documentation serve you better?

                          Sending your feedback...
                          🎉 Thank you for your feedback!
                          Something went wrong. Please try again.

                          Thanks for your feedback!

                          Refer us and get $10 in 3 simple steps!

                          Step 1

                          Get link

                          Get a free personal referral link here

                          Step 2

                          Give $10

                          Your user signs up and upgrade using link

                          Step 3

                          Get $10

                          1,250 free SMSes
                          OR 1,000 free voice mins
                          OR 12,000 chats
                          OR more