Transports

A transport is how a client reaches Janus. Janus speaks one JSON protocol (the Janus API) and one for operators (the Admin API). Each transport carries those same JSON messages over a different channel. Pick the one that fits who is calling: a browser, a server-side script, a message bus.

Each transport has its own config file in the configs folder, named janus.transport.<name>.jcfg, and each is off until its file turns it on. Janus does not start if no transport carries the Janus API: it stops with No Janus API transport is available. The key tables are in the transport files reference.

Which transport for which job

You are...	Use	Why
A browser app (janus.js or your own)	HTTP or WebSockets	Browsers can only speak these two. WebSockets pushes events on the same socket; HTTP polls for them.
A backend that wraps Janus for its own clients	WebSockets	One long-lived connection, no polling, any language has a client.
A script or curl on the same machine	HTTP	curl http://localhost:8088/janus/info works with nothing installed.
A local process that wants no network port	Unix sockets	Access is a file permission, not a firewall rule.
An IoT or event-driven system that already runs a broker	MQTT	Janus subscribes to one topic and publishes on another.
A service platform built on a message queue	RabbitMQ	Requests and replies are queued; the broker handles delivery and reconnection.
A C or embedded application that uses nanomsg	nanomsg	One peer, one socket, no broker.

The transports run side by side. A session belongs to the transport that created it: its events come back on that transport only (see Events and sessions).

What each transport carries

	HTTP	WebSockets	Unix sockets	MQTT	RabbitMQ	nanomsg
Janus API	yes, POST on base_path	yes, subprotocol janus-protocol	yes, general.path	yes, subscribe_topic and publish_topic	yes, to_janus and from_janus	yes, general.address
Admin API	yes, own port and admin_base_path	yes, own port, subprotocol janus-admin-protocol	yes, admin.admin_path	yes, own topics	yes, own queues	yes, admin.admin_address
Events pushed to the client	no: the client long-polls with GET	yes, as frames on the same socket	yes, as messages	yes, on the publish topic	yes, on the outgoing queue	yes, on the same socket
Secure variant	HTTPS	wss	no	ssl:// URL	ssl_enabled	no
Janus is the	server	server	server	client of a broker	client of a broker	binds, or connects
One message is	one HTTP body	one text frame	one datagram or packet	one MQTT message	one AMQP message	one SP message
Run against the binary here	yes	yes	datagram socket, on macOS	yes, mosquitto 2.1	yes, RabbitMQ 3.13	yes, a hand-written SP peer
Janus Bench	yes	yes	no	no	no	no

"Events" in this table means the asynchronous messages a client receives for its own sessions: plugin events, webrtcup, media, hangup, timeout. They are not the event handler events, which go to a third system whatever transport you use. Every transport also has a general.events switch that controls whether it reports its own connections to event handlers (a transport event).

What is the same on every transport

• The JSON messages, their fields and the error codes. A request that works on one transport works on another once you add the transport's routing: HTTP puts the session and handle ids in the URL path, all the others put them in the JSON body as session_id and handle_id.
• json in the transport file chooses how Janus writes replies: indented, plain or compact. The default is compact. HTTP, WebSockets, Unix sockets, MQTT, RabbitMQ and nanomsg all read it.
• The Admin API needs admin_secret in each request (set in janus.jcfg), except info and ping. The core checks it, so it holds on every transport. I checked the missing-secret case over HTTP, WebSockets and Unix sockets; MQTT, RabbitMQ and nanomsg were exercised with the secret only.
• api_secret and token authentication work through the core, so they apply to every transport.
• A request that is not valid JSON gets error 454 as a reply.

Events and sessions

When you create a session on a transport, Janus remembers which transport it was. Everything the plugins push for that session goes back the same way. Close a WebSocket and the sessions it created end, unless reclaim_session_timeout in janus.jcfg keeps them for a while so that a new connection can send claim. Over HTTP there is no connection to close: a session ends when you destroy it or when session_timeout passes with no request and no long poll.

Known gaps

These apply to the transports as a group. The pages list the rest.

• gap info does not list janus.transport.nanomsg although the nanomsg transport runs (checked: transports has http and websockets only). The C server lists it. The source registers the other five transports in that list.
• gap The Admin request query_transport, which asks one transport for its own numbers (HTTP connection counts, for example), answers error 490 Not supported in this build: query_transport. This is the same gap the Bench reports.
• gap session created events that go to event handlers carry a transport object in the C server. Here only sessions that were created over HTTP do. Sessions created over WebSockets, Unix sockets and nanomsg have {"name": "created"} alone. See event types.
• gap The id in a transport event should stay the same for the life of a connection. For WebSockets, the connected and disconnected events of one connection carry different ids.