W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > April 2020

[webrtc-pc] Calling SRD twice isn't web compatible (#2512)

From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
Date: Tue, 14 Apr 2020 20:26:04 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issues.opened-599837550-1586895963-sysbot+gh@w3.org>
jan-ivar has just created a new issue for https://github.com/w3c/webrtc-pc:

== Calling SRD twice isn't web compatible ==
Calling SRD twice (ditto SLD) may be well-defined in webrtc-pc, but it's not in JSEP.

![state diagram](https://w3c.github.io/webrtc-pc/images/peerstates.svg)

Firefox does something akin to a silent mini-rollback in-between, whereas Chrome does not, instead [failing](https://jsfiddle.net/jib1/xtk7np5m/) all offers different┬╣ from the first:
```js
InvalidAccessError: Failed to execute 'setRemoteDescription' on 'RTCPeerConnection':
Failed to set remote offer sdp: The order of m-lines in subsequent offer doesn't match
order from previous offer/answer.
```
In Firefox these succeed┬▓ instead. But its aggressive mini-rollbacks produce different transceiver objects even with identical offers, which doesn't seem great either. 

Who's right? Who won? You decide!

<sub>1) Turns out Chrome [allows m-lines to grow](https://jsfiddle.net/jib1/pk84hex9/), but not shrink. Also [media kinds cannot change](https://jsfiddle.net/jib1/fye9wcp1/).</sub>
<sub>2) We're fixing [some disappearing transceivers](https://bugzil.la/1630029) in Firefox atm, but that shouldn't distract from the different interpretations.</sub>

Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2512 using your GitHub account
Received on Tuesday, 14 April 2020 20:26:07 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 6 May 2023 21:19:50 UTC