Bug 186576
| Summary: | Changing offer constraints does not update subsequent offers. | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Thomas Mullen <thomasmullendesign> |
| Component: | WebRTC | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW | ||
| Severity: | Normal | CC: | youennf |
| Priority: | P2 | ||
| Version: | Safari 11 | ||
| Hardware: | Mac | ||
| OS: | macOS 10.13 | ||
Thomas Mullen
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
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
youenn fablet
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.