An SFU (selective forwarding unit) is capable of receiving multiple media streams and then decides which of these media streams should be sent to which participants. In the SFU architecture, every participant sends their media stream to a centralized selective forwarding unit (SFU) and receives streams from all other participants via the same SFU.
The purpose of this protocol extension is to provide a generic specification of how an XMPP client can communicate in-band with an SFU via simple IQ stanzas
This document addresses the following requirements:
Enable an XMPP client to maintain a session with a SFU from an existing XMPP connection without switching protocols or transport. The XMPP server will act as a proxy and maintain the required connection to the SFU. Typically, the SFU will bind to localhost and accept websocket connections from the XMPP server. This removes the need to expose the SFU directly to clients.
Provide an SFU direct access protocol to enable a XMPP client send the required content/payload directly to the SFU without any need to marshall that data to or from XML. Typically, this would be JSON content with embedded SDP for the media sessions. The server does not need to inspect the contents or impose itself into the media flow in order to route the stanza sucessfully to the SFU.
Enable a third-party remote control signalling protocol like XEP-0327: Rayo
Enable chaining SFUs together using XMPP Federation in trusted environments in order to create clusters of SFUs able to support large-scale real-time multi-party communication. An example would be the use of XEP-0289: Federated MUC for Constrained Environments
As this is a generic specification, the protocol will depend on the SFU implmentation. Most SFUs use a symmetric, asynchronous protocol. In client-server usage, some messages are only sent in the client to server or in the server to client direction.
The namespace should be in the form "urn:xmpp:sfu:xxxxx:0" where xxxxx is the name of the SFU implementation. This will enable the XMPP server to validate the JSON if needed and the client to discover the expected SFU implementation.
A sample protocol flow of a message from the XMPP client to the Galene SFU is shown below.
The XMPP server will maintain of SFU client connections and automatically create each one on the first message recieved from a client.
To close a connection, a client will send an empty <c2s> element.
A sample protocol flow of a message from the Galene SFU to the XMPP client is shown below.
A sample protocol flow to initate a voice/video conversation between two users using Rayo for signalling and an SFU for media session management.
All call signalling between caller and callee will be handled by Rayo protocol and all media session communication between the caller and the SFU as well as the callee and the SFU will be in-band XMPP using this protocol.
The <json> element MUST NOT be empty, as the empty string is not valid JSON. The data MUST be encoded as UTF-8 (though officially unspecified, this is the de facto encoding for JSON today.
Implementations SHOULD validate JSON they receive and intend to use, and be prepared to handle invalid data appropriately (such as by responding to the sender with the applicable XMPP error reply for the stanza type.
As the <json> element alone provides no context to the recipient about the kind of data it contains, only the format, it SHOULD always be encapsulated within the <c2s> or <s2c> element that provides a context and SHOULD NOT be added as a direct child of a stanza.
JSON is a very common format for data interchange today, and has many popular implementations available in browsers and standalone libraries that can be assumed relatively well-tested. However an implementation receiving JSON data from an untrusted entity should take precautions and MUST NOT attempt to use invalid JSON data it receives in any way, nor must it accept data in any encoding other than UTF-8 to avoid potential encoding mismatch attacks
This document requires no interaction with IANA.
The Registrar shall include the following information in its registries.
The XMPP Registrar includes "urn:xmpp:sfu:galene:0" in its registry of protocol namespaces.