2.2.11. Network monitoring (experimental)

Note

Currently, network monitoring is in an experimental stage and for illustration purposes only. The API is subject to change and should not be used in production applications.

2.2.11.1. Overview

A key factor in the performance and quality of media feeds is how the underlying network itself is behaving and performing. There are a number of factors that affect performance, and numerous techniques to measure them.

The SDK already supports the concept of “adaptive streaming” (see the Adaptive Streaming for more details) for media server sessions. We are now developing a broader monitoring system that will allow the application to get feedback of network conditions, to report (e.g. in user-facing UI) or respond to them (e.g. by adjusting feed quality). Network monitoring will eventually supplant the existing adaptive streaming as a general purpose monitoring and quality adjustment system.

2.2.11.2. Usage

Similar to the current FeedQualityMonitor, the new NetworkQualityMonitor class is created by the application, which decides which feeds to assign to it to assess the network.

auto monitor = PxMedia::experimental::NetworkQualityMonitor::create(pxContext);

The monitor takes any feed type, but at this stage only WebRTC feeds are used as they are able to report details about their stats and performance.

monitor->registerFeed(feed);

Feeds are created by the usual methods as discussed in Media feeds and sessions and related documentation.

Finally, you need to start the monitor with a collection interval. This interval determines how often the monitor collates and checks ongoing stats for the feeds it is monitoring.

// e.g. some constant for the collection interval
constexpr auto MONITOR_COLLECTION_INTERVAL = std::chrono::milliseconds(2'500);

// ...Then start the monitor when ready
monitor->start(MONITOR_COLLECTION_INTERVAL);

Note that feeds may be dynamically added and removed (using unregisterFeed()) whilst the monitor is running.

About the collection process

As mentioned above, the monitor collects stats over a given period of time, the collection interval. The monitor actually spreads stats collection for the registered feed over the collection interval, to gain a broader picture of performance rather than instantaneous.

Note: if a feed is removed or added during collection, the monitor will complete its current collection cycle, and the changes to the feed list will be reflected in the next collection cycle.

Network performance reporting

At this stage, network performance is only logged to the console. In the future, we will add callback mechanisms to allow applications to receive updates and react to them.

The current process examines all feeds and reports:

  1. An aggregated performance assessment based on recent network behaviour.

  2. A further assessment based on the most under-performing feed, to give an indication of the worst case performance.

Performance is categorised into four levels:

  • GOOD: Network is not impacting performance, and there is headroom/capacity to spare.

  • STABLE: Network performance is stable, but no significant headroom.

  • POOR: Poor performance, feeds are likely compromised.

  • SEVERE: Severe performance issues, feeds will be significantly compromised.

2.2.11.3. Future plans

The network monitor system is undergoing active development. In the future, we plan to add more features and capabilities, including:

  • Callback mechanisms to allow applications to receive network performance updates and react to them or report them in real time.

  • More control over the assessment process, allowing applications to tune how stats are translated into performance assessments.

  • Support for non-WebRTC feeds, especially peer streaming feeds that use the local network.

  • Automatic registration of feeds from media server and peer sessions, allowing applications to default to monitoring all feeds without needing to manually register them.

  • Supporting adaptive streaming as a general mechanism, allowing feeds beyond WebRTC feeds to adjust their quality based on network conditions feedback.

  • Provide other mechanisms to report on network performance outside of introspecting feed behaviour.