IP Library Granted Patent US 7,496,086
Granted Patent B2
US 7,496,086 · App. 10/136,840 · Granted Feb 24, 2009

Techniques for jitter buffer delay management

View Patent ↗
Loading inventors, assignments & file history…
Monitor This Case
Get email alerts when status or documents change.
Order Certified Copies
Most orders are placed with the USPTO same day — all within 24 business hours.
Order via The Patent Place →
Pre-filled with this patent's details
Quick Facts
Patent No.
US 7,496,086
App. No.
10/136,840
Granted
Feb 24, 2009
Kind
B2
Abstract

Techniques are provided to allow a jitter buffer to automatically reach a quiescent number of packets in the jitter buffer, based on current network conditions. Generally, no explicit jitter buffer delay is assumed, and a current packet is repeat played if no new packets are available in the jitter buffer. If there are too many packets in the jitter buffer, a newly received packet is discarded. When a packet is replayed, the delay associated with a jitter buffer is effectively increased. This is not an explicit jitter buffer delay, but, instead, there is an implicit delay associated with the jitter buffer. When a packet is discarded, the delay associated with a jitter buffer is effectively decreased. Again, this is an implicit jitter buffer delay. By repeat playing packets and discarding packets when the jitter buffer is full, an appropriate level of packets may be determined and maintained in the jitter buffer.

Claims (41)

1. A method for jitter buffer delay management, the method comprising the steps of:

receiving a received packet;

when there are no packets in a buffer, performing the following steps:

playing the received packet, the step of playing performed without waiting an explicit delay;

determining, after the received packet is played, if there are any new packets in the buffer;

replaying only a portion of the received packet when there are no new packets in the buffer, the step of replaying thereby increasing an implicit delay; and

when there is at least one packet in the buffer and a number of packets in the buffer is below a predetermined value, performing the following steps:

placing the received packet in the buffer;

determining if the received packet should be played before a current packet; and

discarding the received packet when the received packet should be played before a current packet.

2. The method of claim 1 , further comprising a step of discarding a received packet by never placing the received packet in the buffer.

3. The method of claim 1 , wherein the steps of determining if there are any new packets in the buffer and replaying can be performed multiple times, and wherein the step of when there are no packets in a buffer, performing the following steps, further comprises the steps of determining if the received packet has been played a predetermined number of times, and not replaying the received packet when the received packet has been played a number of times.

4. The method of claim 1 , wherein the step of determining if the received packet should be played before a current packet further comprises the steps of determining timestamps for each of the received packet and current packet and using the timestamps to determine if the received packet should be played before a current packet by determining which packet of the received and current packets was created first.

5. The method of claim 1 , wherein the step of determining if the received packet should be played before a current packet further comprises the steps of determining sequence numbers for each of the received packet and current packet and using the sequence numbers to determine if the received packet should be played before a current packet by determining which packet of the received and current packets was created first.

6. The method of claim 1 , wherein the step of when there is at least one packet in the buffer and a number of packets in the buffer is below a predetermined value. placing the received packet in the buffer further comprises the steps of:

determining if a current packet has been played less than a predetermined number of times;

determining sequences for the received packet and the current packet;

determining if the number of packets in the buffer is less than a second predetermined value;

replaying a current packet when the current packet has been played less than the predetermined number of times, the current packet should be played before the received packet according to the sequences, and the number of packets in the buffer is less than the second predetermined value; and

playing the received packet when the current packet should be played before the received packet according to the sequences and either the current packet has been played more than the predetermined number of times or the number of packets in the buffer is less than the second predetermined value.

7. A method for jitter buffer delay management, the method comprising the steps of:

determining a number of packets currently in a buffer;

selecting, based on the settings for a buffer limit value, a replay value, a repeat play value, and the number of packets currently in the buffer, one of the steps of (i) playing a packet from the buffer, (ii) replaying a previously played packet from the buffer, (iii) discarding a packet from the buffer, (iv) selecting another packet from the buffer, and (v) waiting for another packet to be put in the buffer; wherein the replay value indicates a maximum number of times a particular packet is allowed to be replayed and wherein the repeat play value indicates a maximum number of packets currently in said buffer above which replaying of packets is disallowed; and

performing the selected step of steps (i) through (v).

8. The method of claim 7 , further comprising the steps of:

setting the buffer limit value the buffer limit value indicating a maximum number of packets allowed in a buffer;

setting the replay value, the replay value indicating a maximum number of times a particular packet is allowed to be replayed; and

setting the repeat play value, the repeat play value indicating a packet level above which replaying of packets is disallowed.

9. The method of claim 8 , further comprising the steps of:

receiving a received packet;

determining whether the received packet should be placed into the buffer; and

discarding the received packet when it is determined that the received packet should not be placed into the buffer.

10. The method of claim 9 , wherein:

the step of determining whether the received packet should be placed into the buffer comprises the step of determining whether the number of packets in the buffer is equal to the buffer limit value; and

the step of discarding the received packet when it is determined that the received packet should not be placed into a buffer comprises the step of discarding the received packet when it is determined that the number of packets in the buffer is equal to the buffer limit value.

11. The method of claim 8 , wherein:

step (i) is selected when there is at least one packet in the buffer, one of the at least one packets has not been previously played, and the one packet is next in a sequence;

step (ii) is selected either when the buffer is empty and a number of times a current packet has been played is less than the replay value or a number of packets in the buffer is less than the repeat play value and a next packet in the sequence is not in the buffer;

step (iii) is selected when the number of packets in the buffer is equal to the buffer limit value or when a received packet occurs earlier in the sequence than a current packet;

step (iv) is selected when there is at least one packet in the buffer and when a received packet occurs earlier in the sequence than a current packet; and

step (v) is selected when the buffer is empty and a previously played packet has been played a number of times equal to the replay value.

Assignments (12)
PATENT SECURITY AGREEMENT Recorded Aug 6, 2024
From: RPX CORPORATION; RPX CLEARINGHOUSE LLC
To: BARINGS FINANCE LLC, AS COLLATERAL AGENT
Reel/Frame 068328/0674 →
RELEASE OF LIEN ON PATENTS Recorded Aug 5, 2024
From: BARINGS FINANCE LLC
To: RPX CORPORATION
Reel/Frame 068328/0278 →
PATENT SECURITY AGREEMENT Recorded Apr 22, 2023
From: RPX CORPORATION
To: BARINGS FINANCE LLC, AS COLLATERAL AGENT
Reel/Frame 063429/0001 →
ASSIGNMENT OF ASSIGNOR'S INTEREST Recorded Dec 28, 2021
From: PROVENANCE ASSET GROUP LLC
To: RPX CORPORATION
Reel/Frame 059352/0001 →
RELEASE OF SECURITY INTEREST Recorded Nov 30, 2021
From: NOKIA US HOLDINGS INC.
To: PROVENANCE ASSET GROUP HOLDINGS LLC; PROVENANCE ASSET GROUP LLC
Reel/Frame 058363/0723 →
RELEASE OF SECURITY INTEREST Recorded Nov 30, 2021
From: CORTLAND CAPITAL MARKETS SERVICES LLC
To: PROVENANCE ASSET GROUP HOLDINGS LLC; PROVENANCE ASSET GROUP LLC
Reel/Frame 058983/0104 →
ASSIGNMENT AND ASSUMPTION AGREEMENT Recorded Feb 14, 2019
From: NOKIA USA INC.
To: NOKIA US HOLDINGS INC.
Reel/Frame 048370/0682 →
ASSIGNMENT OF ASSIGNOR'S INTEREST Recorded Sep 13, 2017
From: NOKIA TECHNOLOGIES OY; NOKIA SOLUTIONS AND NETWORKS BV; ALCATEL LUCENT SAS
To: PROVENANCE ASSET GROUP LLC
Reel/Frame 043877/0001 →
SECURITY INTEREST Recorded Sep 13, 2017
From: PROVENANCE ASSET GROUP HOLDINGS, LLC; PROVENANCE ASSET GROUP LLC
To: NOKIA USA INC.
Reel/Frame 043879/0001 →
SECURITY INTEREST Recorded Sep 13, 2017
From: PROVENANCE ASSET GROUP HOLDINGS, LLC; PROVENANCE ASSET GROUP, LLC
To: CORTLAND CAPITAL MARKET SERVICES, LLC
Reel/Frame 043967/0001 →
MERGER Recorded Dec 31, 2008
From: LUCENT TECHNOLOGIES INC.
To: ALCATEL-LUCENT USA INC.
Reel/Frame 022044/0300 →
ASSIGNMENT OF ASSIGNOR'S INTEREST Recorded Jul 2, 2002
From: ECKBERG, ADRIAN EMMANUEL
To: LUCENT TECHNOLOGIES INC.
Reel/Frame 013064/0868 →