Server-Assisted Live Stream Failover for Stale Manifest Detection

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing live streaming systems fail to effectively detect and handle stale manifests caused by persistent issues, leading to clients missing parts of the stream or losing access due to premature or late failover between sources.

Innovation Solution

Implementing a server-assisted failover system that detects stale manifests based on a configurable staleness quotient, redirecting clients from a stale source to a redundant source by converting stale messages into error messages, ensuring seamless playback by buffering segments ahead of the current position.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If the client continuously retries requesting from the same source in response to a stale message, then the client maintains connection to the source, but the client misses stream content and loses access due to persistent issues

Engineering Contradiction:
Improvestream playback continuityVSAvoidstream content loss
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The system monitors the response status codes from the source and detects stale messages (304 Not Modified) versus error messages (4xx/5xx). Based on this feedback, the system intelligently determines whether to continue retrying the same source or to failover to a redundant source, preventing both premature failover and excessive stream loss

Inventive Principle:
Principle #23Feedback

Solution Approach 2:

The system acts as an intermediary between the client and the source, intercepting stale messages and converting them into error messages that trigger failover. This intermediary function allows the system to manage the failover logic centrally rather than requiring the client to make complex decisions

Inventive Principle:
Principle #24Intermediary (Mediator)

2Reliability

If the system implements automatic failover detection, then the system can switch to redundant sources timely, but the system may trigger premature failover due to temporary issues

Engineering Contradiction:
Improvestream playback continuityVSAvoidfailover detection system
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The system changes the interpretation of the response status code parameter from a simple cache validation indicator to a failover trigger condition. By reinterpreting stale messages (304) as potential failure indicators in the context of live streaming, the system enables timely failover without requiring complex additional monitoring infrastructure

Inventive Principle:
Principle #35Parameter changes

3Reliability

If the client requests updated manifests frequently, then the client can detect stale manifests sooner, but the client increases network traffic and processing overhead

Engineering Contradiction:
Improvestale manifest detectionVSAvoidnetwork traffic overhead
Core Design Contradiction:
ReliabilityVSLoss of energy

Solution Approach 1:

The system uses the existing manifest update mechanism served by the source to detect staleness. Instead of requiring the client to proactively poll or implement complex detection logic, the source itself provides the staleness information through the response status code, making the detection process energy-efficient and scalable

Inventive Principle:
Principle #25Self-service

Data Source

PatentUS10972515B2Server assisted live stream failover
Publication Date: 2021.04.06 EDGIO INC
  • US10972515B2 patent drawing
  • US10972515B2 patent drawing
  • US10972515B2 patent drawing

AI summary

Server assisted live stream failover involves detecting a manifest of a stream provided by a first source exceeding a staleness quotient before the stream ends, and initiating or triggering failover of the stream from the first source to a second source in response to detecting the stale manifest. A server initiates the failover on behalf of a client, wherein the client requests objects (i.e., manifests and segments) of the stream, the server distributes those objects from at least the first source to the client, and the server detects that a particular requested object has become stale past a staleness quotient. The server indirectly redirects a client from a first source to a second source by passing a message with a 4xx or 5xx code to the client in place of a message with a 3xx code provided by the first source.