186576 2018-06-12 15:15:02 -0700 Changing offer constraints does not update subsequent offers. 2018-06-12 19:32:28 -0700 1 1 1 Unclassified WebKit WebRTC Safari 11 Mac macOS 10.13 NEW P2 Normal --- 1 thomasmullendesign webkit-unassigned youennf oldest_to_newest 1432494 0 thomasmullendesign 2018-06-12 15:15:02 -0700 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 1432560 1 youennf 2018-06-12 19:32:28 -0700 Hi Thomas, offerToReceiveAudio is not supported in WebKit. adapter.js supports it by using transceivers. I guess it might be a limitation of the shim and of WebKit support of transceivers which is not fully compliant with the spec.