RTP over TCP HOLB Prevention via Packet Segmentation
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Real-time communications using Real-Time Transport Protocol (RTP) over Transmission Control Protocol (TCP) suffer from Head Of Line Blocking (HOLB), which delays packet delivery and complicates packet identification due to packet retransmissions, especially when UDP traffic is blocked by firewalls or NAT devices.
Innovation Solution
Implementing a TCP packet processing module that extracts and outputs RTP packet data irrespective of preceding packet receipt, using pattern matching to identify RTP packets even when packet length information is missing, and employing multiple TCP interface modules to manage RTP and non-RTP packet streams differently.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If TCP is used to communicate RTP packets to traverse firewalls, then firewall compatibility is improved, but head of line blocking occurs causing delayed packet delivery
Solution Approach 1:
The patent segments the TCP packet processing into multiple independent threads: a receiving thread that processes incoming TCP packets independently, and an application thread that handles RTP packet delivery. This segmentation allows the receiving thread to continue processing subsequent packets without being blocked by missing packets, thereby reducing head of line blocking while maintaining TCP's firewall compatibility.
Solution Approach 2:
The patent implements preliminary actions by pre-establishing multiple thread contexts and buffering mechanisms before packet processing begins. The receiving thread is pre-configured to handle packet reassembly and the application thread is ready to process RTP packets as soon as they are reassembled, eliminating the need to wait for missing packets before starting processing.
2Reliability
If TCP packet retransmission mechanism is used, then packet delivery reliability is improved, but head of line blocking occurs affecting multiple subsequent packets
Solution Approach 1:
The patent divides the packet processing function into separate threads: the receiving thread handles TCP packet reception and reassembly independently, while the application thread handles RTP packet processing. This allows the receiving thread to continue reassembling packets from received segments without waiting for retransmitted packets, maintaining throughput while ensuring reliability through complete reassembly before application delivery.
Solution Approach 2:
The patent introduces an intermediary buffering mechanism between the TCP receiving thread and the RTP application thread. This buffer allows the receiving thread to store reassembled RTP packets and signal their availability, enabling the application thread to process packets as soon as they are complete without being blocked by the TCP retransmission timing, thus maintaining both reliability and productivity.
3Reliability
If RTP packets are split across multiple TCP packets, then TCP's reliable delivery is utilized, but packet identification becomes difficult when length field is lost
Solution Approach 1:
The patent implements feedback mechanisms where the receiving thread continuously monitors the reassembly status of RTP packets from TCP segments. When complete RTP packets are reassembled, the system feedbacks their availability to the application thread. This feedback loop enables dynamic packet boundary identification based on actual reassembly completion rather than relying solely on potentially lost length fields.
Solution Approach 2:
The patent introduces an intermediary reassembly buffer between the TCP segment reception and RTP packet identification. This buffer stores incoming TCP packet data and allows the receiving thread to reassemble complete RTP packets by combining multiple TCP segments. The intermediary buffer enables reliable packet boundary identification based on actual reassembly rather than relying on the length field that may be lost in TCP transmission.
Data Source
AI summary
Methods and apparatus for processing and using TCP packets to communicate RTP packets are described. Head of line blocking is avoided by operating a TCP packet processing module to output RTP packet data to an application irrespective of whether or not a preceding TCP packet was received. Since output of packet data to an application using RTP packets is not delayed when there is a missing TCP packet, head of line blocking is avoided. RTP packet data is subjected to pattern matching in order to identify and process RTP packets in the case where RTP header information such as packet length information is missing due to the failure to receive a TCP packet. The methods are particularly well suited for the communication of audio and/or video by devices operating behind firewalls which block UDP or other types of packets other than TCP packets.