SRTP Stream Acquisition for WebRTC Audio Quality Assessment

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Determining the network segment causing data traffic disturbances during WebRTC audio media calls is challenging due to impaired transmission, as existing methods fail to accurately identify the affected segments and reasons for the disturbance.

Innovation Solution

The solution involves acquiring means and methods to filter and decrypt SRTP streams from WebRTC traffic, extracting and decoding degraded audio signals to assess audio quality, using tools like parsing, decryption, and audio decoding to identify disturbances by simulating jitter buffer behavior and outputting decoded audio samples for quality assessment.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Measurement precision

If SRTP stream filtering and decryption is performed to identify network segment disturbances, then measurement precision of network quality assessment is improved, but device complexity increases due to multiple processing components

Engineering Contradiction:
Improvenetwork quality assessment precisionVSAvoidprocessing system complexity
Core Design Contradiction:
Measurement precisionVSDevice complexity

Solution Approach 1:

The system divides the network transmission path into multiple segments and applies filtering and decryption operations at specific interception points within each segment. This segmentation allows precise identification of disturbance locations while managing complexity by processing only relevant portions of the traffic flow at each node.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent introduces intermediary components (filtering means and decryption means) positioned at network interception points between endpoints. These intermediaries process the SRTP stream without requiring direct access to endpoint security credentials, thereby reducing overall system complexity while maintaining measurement precision.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Reliability

If audio stream capture and processing is performed at network interception points, then reliability of quality assessment is improved, but loss of time increases due to multiple processing steps

Engineering Contradiction:
Improvequality assessment reliabilityVSAvoidprocessing time
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The system performs preliminary filtering of the SRTP stream at network interception points before decryption and full processing. This preliminary action identifies and isolates relevant audio packets early in the processing chain, ensuring reliable quality assessment while reducing overall processing time by avoiding unnecessary operations on non-audio traffic.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The patent implements optimized processing paths that skip unnecessary decryption and processing steps for packets that do not require full analysis. By rushing through the processing pipeline for clearly identifiable audio packets and applying full processing only when needed, the system maintains reliability while minimizing time loss.

Inventive Principle:
Principle #21Skipping (Rushing through)

Data Source

PatentEP3544253B1Acquisition of files from an SRTP-stream
Publication Date: 2020.05.20 DEUTSCHE TELEKOM AG
  • EP3544253B1 patent drawingFigure 1
  • EP3544253B1 patent drawingFigure 2
  • EP3544253B1 patent drawingFigure 3

AI summary

The invention refers to acquiring means, a system and a method for acquiring files containing degraded audio signals from a Secure Real-Time Transport Protocol, SRTP, -stream, the files being acquired for an objective audio quality assessment method, wherein traffic with the SRTP stream is transmitted during a successfully established Web Real-Time Communication, WebRTC, audio media call between at least two WebRTC endpoints (la, 1b) and transmitted by at least one network element different from the WebRTC endpoints (la, lb) via a WebRTC audio media transmission path.