[Webkit-unassigned] [Bug 190960] New: [WebRTC] Setting remote answer fails in first m-line was rejected

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=190960

            Bug ID: 190960
           Summary: [WebRTC] Setting remote answer fails in first m-line
                    was rejected
           Product: WebKit
           Version: Safari Technology Preview
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebRTC
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: lminiero at gmail.com
                CC: youennf at gmail.com

Created attachment 353183

  --> https://bugs.webkit.org/attachment.cgi?id=353183&action=review

SDP offer and answer (failure)

The scenario is the following:

1. Safari STP (with VP8 disabled) sends an audio/video offer to an SFU;
2. the SFU is configured to only accept opus/vp8, and so accepts the audio m-line and rejects the video m-line;
3. eventually, the PeerConnection is supposed to be audio only.

This works in some cases, and doesn't in others. Specifically, it looks like it's failing when Safari puts the m-line video before the audio m-line. This is something our SFU supports correctly (the answer has the m-lines in the same order), but the setRemoteDescription in Safari fails with the following error:

    Failed to set remote answer sdp: The m= section:1 should be rejected.

Apparently, the WebRTC stack seems to think that, since the first m-line (video, mid=0) was rejected, the second m-line (audio, mid=1) should be rejected as well. It works as expected if the rejected video m-line comes after the first audio m-line instead. Not sure if this bug was already there or if it's a regression, as I'm not a regular Safari/MacOS user: not exactly sure why Safari randomly switches the m-line order either, as we always add tracks in the same order in JavaScript.

I'm attaching an example of SDP offer and answer that resulted in that issue. In case there's anything else I can provide that can be of use, please let me know.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20181026/a0277742/attachment.html>