This is a simple application that implements two different features: it allows you to record a message you send with WebRTC in the format defined in recorded.c (MJR recording) and subsequently replay this recording (or other previously recorded) through WebRTC as well. For more information on how Janus implements recordings natively and the MJR format, refer to the Recordings documentation.

This application aims at showing how easy recording frames sent by a peer is, and how this recording can be re-used directly, without necessarily involving a post-processing process (e.g., through the tool we provide in janus-pp-rec.c). Notice that only audio and video can be recorded and replayed in this plugin: if you're interested in recording data channel messages (which Janus and the .mjr format do support), you should use a different plugin instead.

The configuration process is quite easy: just choose where the recordings should be saved. The same folder will also be used to list the available recordings that can be replayed.

Note

The application creates a special file in INI format with .nfo extension for each recording that is saved. This is necessary to map a specific audio .mjr file to a different video .mjr one, as they always get saved in different files. If you want to replay recordings you took in a different application (e.g., the streaming or videoroom plugins) just copy the related files in the folder you configured this plugin to use and create a .nfo file in the same folder to create a mapping, e.g.:

         [12345678]
         name = My videoroom recording
         date = 2014-10-14 17:11:26
         audio = videoroom-audio.mjr
         video = videoroom-video.mjr

Data channel recordings are supported via a data attribute as well.

Record&Play API

The Record&Play API supports several requests, some of which are synchronous and some asynchronous. There are some situations, though, (invalid JSON, invalid request) which will always result in a synchronous error response even for asynchronous requests.

list and update are synchronous requests, which means you'll get a response directly within the context of the transaction. list lists all the available recordings, while update forces the plugin to scan the folder of recordings again in case some were added manually and not indexed in the meanwhile.

The record , play , start and stop requests instead are all asynchronous, which means you'll get a notification about their success or failure in an event. record asks the plugin to start recording a session; play asks the plugin to prepare the playout of one of the previously recorded sessions; start starts the actual playout, and stop stops whatever the session was for, i.e., recording or replaying.

The list request has to be formatted as follows:

{
        "request" : "list"
}

A successful request will result in an array of recordings:

{
        "recordplay" : "list",
        "list": [       // Array of recording objects
                {                       // Recording #1
                        "id": <numeric ID>,
                        "name": "<Name of the recording>",
                        "date": "<Date of the recording>",
                        "audio": "<Audio rec file, if any; optional>",
                        "video": "<Video rec file, if any; optional>",
                        "data": "<Data rec file, if any; optional>",
                        "audio_codec": "<Audio codec, if any; optional>",
                        "video_codec": "<Video codec, if any; optional>"
                },
                <other recordings>
        ]
}

An error instead (and the same applies to all other requests, so this won't be repeated) would provide both an error code and a more verbose description of the cause of the issue:

{
        "recordplay" : "event",
        "error_code" : <numeric ID, check Macros below>,
        "error" : "<error description as a string>"
}

The update request instead has to be formatted as follows:

{
        "request" : "update"
}

which will always result in an immediate ack ( ok ):

{
        "recordplay" : "ok",
}

Coming to the asynchronous requests, record has to be attached to a JSEP offer (failure to do so will result in an error) and has to be formatted as follows:

{
        "request" : "record",
        "id" : <unique numeric ID for the recording; optional, will be chosen by the server if missing>
        "name" : "<Pretty name for the recording>",
        "filename" : "<Base path/name for the file (media type and extension added by the plugin); optional>",
        "audiocodec" : "<name of the audio codec we prefer for the recording; optional>",
        "videocodec" : "<name of the video codec we prefer for the recording; optional>",
        "videoprofile" : "<in case the video codec supports, profile to use (e.g., "2" for VP9, or "42e01f" for H.264); optional>",
        "opusred" : <true|false, whether RED should be negotiated for audio, if offered; optional (default=false)>,
        "textdata" : "<in case data channels have to be recorded, whether the data will be text (default) or binary; optional>"
}

A successful management of this request will result in a recording event which will include the unique ID of the recording and a JSEP answer to complete the setup of the associated PeerConnection to record:

{
        "recordplay" : "event",
        "result": {
                "status" : "recording",
                "id" : <unique numeric ID>
        }
}

A stop request can interrupt the recording process and tear the associated PeerConnection down:

{
        "request" : "stop",
}

This will result in a stopped status:

{
        "recordplay" : "event",
        "result": {
                "status" : "stopped",
                "id" : <unique numeric ID of the interrupted recording>
        }
}

For what concerns the playout, instead, the process is slightly different: you first choose a recording to replay, using play , and then start its playout using a start request. Just as before, a stop request will interrupt the playout and tear the PeerConnection down. It's very important to point out that no JSEP offer must be sent for replaying a recording: in this case, it will always be the plugin to generate a JSON offer (in response to a play request), which means you'll then have to provide a JSEP answer within the context of the following start request which will close the circle.

A play request has to be formatted as follows:

{
        "request" : "play",
        "id" : <unique numeric ID of the recording to replay>
}

This will result in a preparing status notification which will be attached to the JSEP offer originated by the plugin in order to match the media available in the recording:

{
        "recordplay" : "event",
        "result": {
                "status" : "preparing",
                "id" : <unique numeric ID of the recording>
        }
}

A start request, which as anticipated must be attached to the JSEP answer to the previous offer sent by the plugin, has to be formatted as follows:

{
        "request" : "start",
}

This will result in a playing status notification:

{
        "recordplay" : "event",
        "result": {
                "status" : "playing"
        }
}

Just as before, a stop request can interrupt the playout process at any time, and tear the associated PeerConnection down:

{
        "request" : "stop",
}

This will result in a stopped status:

{
        "recordplay" : "event",
        "result": {
                "status" : "stopped"
        }
}

If the plugin detects a loss of the associated PeerConnection, whether as a result of a stop request or because the 10 seconds passed, a done result notification is triggered to inform the application the recording/playout session is over:

{
        "recordplay" : "event",
        "result": "done"
}