How configuration works

The server reads a folder of small files, one per component, in libconfig syntax. The files are the same ones the C server reads, so an existing config folder works unchanged (see coming from the C server).

Where the files are

conf/
  janus.jcfg                          core: logging, folders, auth, ICE, DTLS, media
  janus.transport.http.jcfg           one file per transport you want
  janus.transport.websockets.jcfg
  janus.plugin.videoroom.jcfg         one file per plugin that has settings
  janus.plugin.streaming.jcfg
  janus.eventhandler.sampleevh.jcfg   one file per event handler
  janus.logger.jsonlog.jcfg           the JSON file logger

Point the server at the folder with --configs-folder=path (default ./conf), or at one core file with --config=filename. For every component the server looks for <name>.jcfg first and then the legacy <name>.cfg in INI syntax. janus-cfgconv converts the old files; see Tools.

Component	File	Reference
Core	janus.jcfg	janus.jcfg
Transports	janus.transport.<name>.jcfg	Transport files
Plugins	janus.plugin.<name>.jcfg	Plugin files
Event handlers	janus.eventhandler.<name>.jcfg	Event handler files
Logger	janus.logger.jsonlog.jcfg	Logger file

Syntax

A file is a set of groups. A group is name: { key = value ... }. Values are strings in double quotes, numbers, true or false, lists in parentheses ( ) and arrays in square brackets [ ]. These all work, checked by starting the server on a file that uses each of them:

// a comment
/* a block comment */
general: {
	debug_level = 6;          # a semicolon after a value is optional
	server_name = "my-janus"  # so is leaving it out, as the samples do
}
@include "extra.jcfg"         # pull in another file from the same folder

Lists of objects, as the Streaming plugin uses for multi-stream mountpoints, look like this:

multistream-test: {
	type = "rtp"
	id = 123
	media = (
		{ type = "audio", mid = "a", port = 5102, pt = 111, codec = "opus" },
		{ type = "video", mid = "v1", port = 5104, pt = 100, codec = "vp8" }
	)
}

What wins when a setting appears twice

Command-line options override the core file, and the core file overrides built-in defaults. A few settings can also change while the server runs through the Admin API (set_log_level, set_session_timeout, set_min_nack_queue, set_no_media_timer, set_slowlink_threshold, accept_new_sessions), but those changes are not written back to disk.

Turning things off

janus.jcfg has a group for each kind of component with a disable key. The value is a comma-separated list of library names, the way the C server names them:

plugins: {
	disable = "libjanus_voicemail.so,libjanus_sip.so"
}
transports: {
	disable = "libjanus_mqtt.so"
}
events: {
	broadcast = true                     # event handlers load only when this is true (or -e)
	disable = "libjanus_gelfevh.so"
}

Plugins here are compiled into the binary, so plugins.disable only decides whether a compiled-in plugin registers. Names that match no plugin are ignored.

Keys the port does not read

A key that the Rust source never mentions is accepted and ignored. The reference tables mark each key as read or not found in the Rust source so you can see which settings do something.