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
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.