W3C home > Mailing lists > Public > public-webrtc@w3.org > June 2017

[webrtc-pc] offerToReceive* legacy behaviour spec does not match the behaviour of legacy implementations

From: Philipp Hancke via GitHub <sysbot+gh@w3.org>
Date: Tue, 13 Jun 2017 13:27:41 +0000
To: public-webrtc@w3.org
Message-ID: <issues.opened-235553745-1497360459-sysbot+gh@w3.org>
fippo has just created a new issue for https://github.com/w3c/webrtc-pc:

== offerToReceive* legacy behaviour spec does not match the behaviour of legacy implementations ==
Run this snippet in Chrome or Firefox:
```
var pc = new RTCPeerConnection();
pc.createOffer({offerToReceiveAudio: true})
.then((offer) => {
  console.log('offer 1', offer.sdp)
  return pc.createOffer({offerToReceiveVideo: true})
 })
 .then((offer) => {
  console.log('offer 2', offer.sdp)
 });
```
The first offer will have an audio m-line. The second offer will have a video m-line.

Now according to the [specification of the legacy offerToReceive*](http://w3c.github.io/webrtc-pc/#configuration-data-extensions) this is not valid since offerToReceive internally creates a transceiver. In the addStream-model createOffer was stateless -- I think the same applies to addTrack.
This is quite a surprising side effect, looks like we managed to specify legacy behaviour that does not match the behaviour of legacy clients.

I do not think the spec should be changed but there should at least be a note explaining this.
I actually like the new behaviour more than having to remember what arguments I used previously.

Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1383 using your GitHub account
Received on Tuesday, 13 June 2017 13:27:47 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:51 UTC