Signaling Over Data Streams
Overview
What is happening
As of 1.13.0, LiveSwitch adds internal data channels used for some internal signaling required for video stream bandwidth adaptation.
What you will see
If a data stream is not part of the connection, it is added with all the required data channels. If a data stream is present in a connection, the existing data stream is used and added to required data channels to the connection as necessary. Internal data channels are restricted via a specific data channel label that starts with fm/. Any application layer data channel with labels following this pattern is rejected.
Backwards compatibility
Pre-1.13 clients connecting to the Media Servers with versions 1.13.0 and above will still connect and use existing signaling procedures for signaling (that is without DataStreams). Clients with versions >= 1.13.0 are also compatible with the pre-1.13 Media Servers. Clients insert data streams with internal data channels but existing signaling procedures are used for internal media stream quality signaling.
Required action
None. This change is transparent for you.
- If you do not use data streams, you can safely ignore this change. You should see data streams being added to your connections though.
- If you use data streams, new channels are added to your connections. Make sure that you do not use data channels with labels matching the pattern
fm/*(where * is one or more characters).
Billing changes
You are not charged for signaling media stream quality over data channels.
Internal Signaling
In pre-1.13 LiveSwitch, most of the metadata information about connections is sent via Gateways. This includes offers and answers, some stream quality information, channel joining and leaving, etc. Some metadata information about media streams is sent in-band (inside of the connection) via RTCP protocol. Some metadata information about data streams is also sent in-band via SCTP protocol.
As of 1.13, LiveSwitch sends some of the connection quality information via data streams instead of the usual signaling delivered over Gateways. This unloads gateway signaling and allows for a more robust connection establishment.
Data Streams and Backward Compatibility
The table below provides the summary of outcomes depending on the versions of clients and servers, as well as whether the application layer has data streams present.
| Server Version | ||||
| Client Version | Is Data Stream present in the Client application? | Are audio/video streams present in the Client Application? | <.1.13.0 | >=1.13.0 |
| >=1.13.0 | Yes | Yes | No data channels are added, data stream remains as is, signaling continues via Gateways | The internal data channel is added to the data stream, some media stream quality signaling occurs via the internal data channel |
| No | No data channels are added, data stream remains as is, | |||
| No | Yes | A data stream will be added to the connection but it will not be used for any signaling. Signalling continues via Gateways | A data stream is added to the connection. The internal data channel is added to the data stream, some media stream quality signaling occurs via the internal data channel | |
| No | Not applicable | |||
| <.1.13.0 | Yes | Yes | No internal data channels are added to the data stream, signaling continues via Gateways. | |
| No | ||||
| No | Yes | No data streams are added to the connection, signaling continues via Gateways. | ||
| No | Not applicable | |||
API Considerations
DataStream.Channels property returns data channels that belong to the stream. The functionality of this property does not change between 1.12 and 1.13. In 1.13, this property does not expose any internal data channels. It only exposes the data channels created by the application code.
As of 1.13.0, DataChannel.IsInternal indicates whether the data channel is internal.
As of 1.13.0, creating a data channel with a label that starts with "fm/" generates an exception.
Web browsers report statistics and provide WebRTC APIs independent of LiveSwitch. These stats and APIs may show internal data channels. Usage of the WebRTC APIs provided by browsers (bypassing the LiveSwitch API) is discouraged.