RTSP Packet Routing by MAC-Bridge Client Matching for VOD

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Modems in mac-bridge mode struggle to process Real-Time-Streaming-Protocol (RTSP) packets correctly when the Media Access Control (MAC) addresses of client devices are included on the mac-bridge client list, leading to failures in video-on-demand services.

Innovation Solution

A list of mac-bridge clients is maintained with MAC addresses and masks, allowing the system to determine whether to process RTSP packets using network services software or the ALG module based on MAC address matches, ensuring continuous video-on-demand services.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If traditional video streaming protocols (HTTP, RTMP, HLS) are used, then video delivery is simple to implement, but they lack real-time control capabilities and cannot dynamically adjust to network conditions

Engineering Contradiction:
Improvereal-time control capabilityVSAvoidprotocol processing complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The patent introduces an intermediary component that translates between traditional streaming protocols (HTTP, RTMP, HLS) and the RTSP protocol. This mediator enables real-time control capabilities by converting standard protocol requests into RTSP commands, allowing dynamic adjustment of playback, pause, and seeking operations without requiring the entire system to adopt complex RTSP natively.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The protocol processing is segmented into separate translation layers. Each protocol (HTTP, RTMP, HLS) has its own translation module that converts to RTSP, allowing independent optimization and maintenance of each protocol handler while sharing the common RTSP execution engine, thus managing complexity through modular segmentation.

Inventive Principle:
Principle #1Segmentation

2Adaptability or versatility

If video content is delivered without protocol conversion, then delivery speed is fast, but the system cannot integrate with existing video platforms using standard protocols

Engineering Contradiction:
Improveplatform integration capabilityVSAvoidprotocol conversion time
Core Design Contradiction:
Adaptability or versatilityVSLoss of time

Solution Approach 1:

The system performs preliminary protocol translation by pre-converting video content metadata and stream information into RTSP format during content ingestion. This preliminary action allows the playback system to operate natively with RTSP commands while maintaining compatibility with standard protocols, reducing conversion time during actual playback operations.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The patent creates protocol translation copies or proxies that interface with standard video platforms. These proxy components copy the functionality of standard protocol handlers while adding RTSP translation capabilities, enabling the system to speak both languages simultaneously without sacrificing integration capability or incurring significant time penalties.

Inventive Principle:
Principle #26Copying

3Adaptability or versatility

If the system processes multiple video formats and protocols simultaneously, then compatibility is improved, but processing overhead and system complexity increase

Engineering Contradiction:
Improveprotocol compatibilityVSAvoidprocessing system complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent merges multiple protocol translation functions into a unified RTSP translation engine. Instead of maintaining separate complex processing systems for each protocol, the system combines HTTP, RTMP, and HLS translation capabilities into a single modular framework that shares common processing logic, data structures, and execution pathways, thereby reducing overall system complexity while maintaining multi-protocol compatibility.

Inventive Principle:
Principle #5Merging (Combining)

Data Source

PatentEP4197185B1Processing real-time-streaming-protocol (RTSP) packets to enhance video-on-demand services
Publication Date: 2026.05.06 ARRIS ENTERPRISES LLC
  • EP4197185B1 patent drawingFigure 1
  • EP4197185B1 patent drawingFigure 2
  • EP4197185B1 patent drawingFigure 3

AI summary

An electronic device for processing real-time-streaming-protocol (RTSP) packets in a network to provide enhanced video-on-demand (VOD) services is provided. The electronic device includes a user interface, a non-transitory memory configured to store instructions including an application layer gateway (ALG) module and network service software, and a hardware processor. The hardware processor is configured to execute the instructions to store a list of mac-bridge clients that includes a MAC address and a MAC mask corresponding to each mac-bridge client, and determine whether at least one of the source and destination MAC address of a received RTSP packet is on the list. When at least one of the source and destination MAC address is on the list, the RTSP packet is processed using the network service software and a next RTSP packet is received; otherwise, the received RTSP packet is processed using the ALG module.