Bug 286358 – Sender priority settings set when adding tracks to an RTC Peer Connection are ignored

• Component: WebRTC
• Status: NEW

The JS API in Safari supports setting `parameters.encodings.priority` via `RTCRtpSender.setParameters()` (see https://developer.mozilla.org/en-US/docs/Web/API/RTCRtpSender/setParameters#browser_compatibility). However, the RTP packets that are actually sent by Safari always contain a default priority header, regardless of what priority is being set via JS.

To reproduce:
- Establish a WebRTC Peer connection between 2 peers
- Create a Media Stream, for example by getting access to user media with `getUserMedia()`
- For each track of the media stream, add it to the peer connection and update its parameter encodings by setting priority to 'high':

  stream.getTracks().forEach((track) => {
    let sender = this._connection.addTrack(track, stream);
    const params = sender.getParameters();
      params.encodings = params.encodings.map((e) => {
        if (e.priority) {
          e.priority = 'high';
        }
        if (e.networkPriority) {
          e.networkPriority = 'high';
        }
        return e;
      });
      sender.setParameters(params);
  });

- Capture the packets using Wireshark and inspect the packet headers.

Expected behaviour
The packet header under IPv4 > Differentiated Services Field should be set to "Expedited Forwarding (46)".

Actual behaviour
The packet header is set to "Default (0)".

Related issue:
https://bugs.webkit.org/show_bug.cgi?id=277605

For more context on the use of the priority encodings and the effects of the bug, see:
https://github.com/versatica/JsSIP/pull/893

[Radar WebKit Bug Importer]

<rdar://problem/143820797>