Coming from the C server

This server is a drop-in replacement for janus-gateway by design. The C server at commit bc0de3b3 is the specification; when behaviour is in doubt, the C server wins.

What stays the same

Janus API and Admin API	Same requests, same replies, same error codes and reasons. Replies recorded from the C server are replayed against this one in CI (90 scenarios).
Config files	The same .jcfg and legacy .cfg files, the same keys, the same sample defaults.
Command line	The same 44 options with the same names.
Plugin messages and events	The same JSON for requests, responses and events of every plugin.
Recordings	Byte-compatible .mjr files; the tools read and write them.
Event handler payloads	The same JSON the six event handlers send.
Client libraries	janus.js and the demo pages talk to it as they do to the C server.
Log output	The start-up banner and log lines follow the C server's wording and order, so existing log parsers keep working.

What is different

• No loadable plugins. Plugins, transports and event handlers are compiled into the binary and chosen with Cargo features (see Build and run). A third-party C plugin cannot be loaded; port it to the Rust Plugin trait. The plugins_folder and transports_folder settings are still checked, as in C: if you set one, the folder must exist (it can be empty), or the server stops. Nothing is loaded from it.
• Admin debug switches. set_locking_debug and set_refcount_debug are accepted and do nothing.
• C-library-specific settings are accepted and ignored, with a warning where the C server would have acted on them: libnice debug flags, BoringSSL or libsrtp choices, and the like. The reference tables show which keys the port reads.
• Scripting. The Lua plugin runs Lua 5.3 through a vendored VM, so scripts that stay on the documented Janus script API work. The JavaScript plugin runs on Boa instead of Duktape, so scripts that depend on Duktape internals may need changes.
• Some admin requests are missing: query_transport and query_logger answer error 490 today. See the Admin walkthrough and status.
• TLS goes through a pure-Rust provider (ADR-0009). Until you have checked it fits your needs, terminating TLS at a reverse proxy is the conservative choice.
• Media gaps. Some plugin media paths are not complete: see the "Known gaps" section of each plugin page and the honest Bench results.

What is better for you

• A documented config reference, API transcripts, a test console and a headless end-to-end run, none of which the C repo has.
• A memory-safe implementation of everything that parses untrusted bytes: SDP, RTP, RTCP, STUN, SCTP, SIP, JSON and config.

Migrating

1. Build with the plugin features you use.
2. Copy your config folder as it is and start with --configs-folder.
3. Run the same smoke checks you run against C: info, then your own client.
4. Run Janus Bench against it for a pass/fail view of every plugin, and read the failures that concern you.
5. Watch the log for not loaded plugins and for warnings about ignored keys.