FF115 RTCRtpReceiver.jitterBufferTarget supported

files/en-us/mozilla/firefox/releases/115/index.md

@@ -43,6 +43,8 @@ This article provides information about the changes in Firefox 115 that affect d
 - The [`URLSearchParams.has()`](/en-US/docs/Web/API/URLSearchParams/has) and [`URLSearchParams.delete()`](/en-US/docs/Web/API/URLSearchParams/delete) methods now support the optional `value` argument.
   This allows matching a search parameter on both the `name` and `value`, making it possible to work with query strings that contain multiple search parameters that have the same name.
   ([Firefox bug 1831587](https://bugzil.la/1831587)).
+- The [`RTCRtpReceiver.jitterBufferTarget`](/en-US/docs/Web/API/RTCRtpReceiver/jitterBufferTarget) attribute is now supported, allowing a WebRTC application to influence the tradeoff between playout delay and the risk of running out of audio or video frames due to network jitter.
+  ([Firefox bug 1592988](https://bugzil.la/1592988)).
 
 #### Removals
 

files/en-us/web/api/rtcrtpreceiver/index.md

@@ -11,6 +11,8 @@ The **`RTCRtpReceiver`** interface of the [WebRTC API](/en-US/docs/Web/API/WebRT
 
 ## Instance properties
 
+- {{domxref("RTCRtpReceiver.jitterBufferTarget")}}
+  - : A {{domxref("DOMHighResTimeStamp")}} that indicates an application's preferred hold time for media in the jitter buffer, allowing it influence the tradeoff between playout delay and the risk of running out of audio or video frames due to network jitter.
 - {{domxref("RTCRtpReceiver.track")}} {{ReadOnlyInline}}
   - : Returns the {{domxref("MediaStreamTrack")}} associated with the current `RTCRtpReceiver` instance.
 - {{domxref("RTCRtpReceiver.transport")}} {{ReadOnlyInline}}

files/en-us/web/api/rtcrtpreceiver/jitterbuffertarget/index.md

@@ -0,0 +1,44 @@
+---
+title: "RTCRtpReceiver: jitterBufferTarget property"
+short-title: jitterBufferTarget
+slug: Web/API/RTCRtpReceiver/jitterBufferTarget
+page-type: web-api-instance-property
+browser-compat: api.RTCRtpReceiver.jitterBufferTarget
+---
+
+{{APIRef("WebRTC API")}}
+
+The **`jitterBufferTarget`** property of the {{domxref("RTCRtpReceiver")}} interface is a {{domxref("DOMHighResTimeStamp")}} that indicates the application's preferred duration, in milliseconds, for which the jitter buffer should hold media before playing it out.
+
+The application can use it to influence the tradeoff between playout delay and the risk of running out of audio or video frames due to network jitter.
+
+## Value
+
+A {{domxref("DOMHighResTimeStamp")}} that indicates the current jitter buffer target hold time, in milliseconds.
+
+The value can be set to a positive value of no greater than 4000 milliseconds.
+
+## Exceptions
+
+- {{jsxref("RangeError")}}
+  - : Thrown if the target is set to a negative value or a value that is greater than 4000 milliseconds.
+
+## Description
+
+The value of the attribute influences the amount of buffering done by the user agent, which in turn affects retransmissions and packet loss recovery.
+
+Note that the attribute "influences" the jitter buffer target of the user agent, but does not directly set it.
+The actual user agent jitter buffer target will vary between maximum and minimum allowed values that reflects a target range that the user agent can provide based on network conditions and memory constraints, and can change at any time.
+The value returned by `jitterBufferTarget` is not affected by the actual target of the user agent.
+
+The change in average delay can be gradually observed over time by measuring the delta [`RTCInboundRtpStreamStats.jitterBufferDelay`](/en-US/docs/Web/API/RTCInboundRtpStreamStats) divided by the delta [`RTCInboundRtpStreamStats.jitterBufferEmittedCount`](/en-US/docs/Web/API/RTCInboundRtpStreamStats).
+
+If `RTCRtpReceiver` audio and video tracks are synchronized, then the larger of the two receivers `jitterBufferTarget` should be used for both receivers.
+
+## Specifications
+
+{{Specifications}}
+
+## Browser compatibility
+
+{{Compat}}