[Webkit-unassigned] [Bug 186576] New: Changing offer constraints does not update subsequent offers.

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Jun 12 15:15:02 PDT 2018


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

            Bug ID: 186576
           Summary: Changing offer constraints does not update subsequent
                    offers.
           Product: WebKit
           Version: Safari 11
          Hardware: Macintosh
                OS: macOS 10.13
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebRTC
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: thomasmullendesign at gmail.com
                CC: youennf at gmail.com

Creating an offer with a set of constraints, connecting, and then creating a new offer for renegotiation with a different set of constraints does not change the offer as expected.

What did you expect to happen:
Creating a second offer with different constraints would result in an offer that reflects those constraints.

What happened:
Safari created an offer with the same constraints as the first offer.

Steps to reproduce:
1. Create an offer with a set of constraints (testing was done with offerToReceiveAudio: false).
2. Renegotiate by creating a new offer with a different set of constraints (testing was done with offerToReceiveAudio: true).
3. Notice that the new offer will now have m-lines describing the change in constraints in Chrome and Firefox, but the Safari offer will be the same.

Why is this a problem:
It is impossible to renegotiate with different constraints. Note that changing the offer through addTrack, addTransceiver, etc still works. Only offerConstraints does not behave correctly. 

For example: If a peer initially does not offer to receive audio, it can never receive audio even after constraints are changed.

Working example to reproduce: https://codepen.io/RationalCoding/pen/LryvwB

-- 
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/20180612/bd5e178a/attachment.html>


More information about the webkit-unassigned mailing list