Calling SRD twice isn't web compatible

[jan-ivar]

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

Firefox does something akin to a silent mini-rollback in-between, whereas Chrome does not, instead failing all offers different¹ from the first:

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!

_{1) Turns out Chrome allows m-lines to grow, but not shrink. Also media kinds cannot change.
2) We're fixing some disappearing transceivers in Firefox atm, but that shouldn't distract from the different interpretations.}

[jan-ivar]

Last I heard of a real-world use case for offer trumping was the "pushy SFU" use case.

[jan-ivar]

It was mentioned to me that a simple workaround for the pushy SFU case is as described in that slide: queue requests, basically visit "stable" in-between. So failure here may not matter much. OTOH it might inform how it should work.

[fippo]

yeah, i've typically done a "if there is a cycle pending, put the operation into a queue, take stuff from the queue on next signalingstatechange to stable".
What this avoids is the following flow:

• SRD (1)
• SRD (2)
• createAnswer (1)
• createAnswer (2)
• SLD (1)
• SLD (2, 💥 can't call SLD twice)

[jan-ivar]

Good point that SLD will throw InvalidModificationError if called with anything other than [[LastCreatedAnswer]] or [[LastCreatedOffer]]. The diagram is only for InvalidStateError.

I think this suggests Chrome's behavior is sufficient.

[jan-ivar]

I think the remaining question then is whether Chrome's behavior is worth specifying. Or simpler:

1. undefined behavior
2. throw InvalidAccessError if SRD called twice
3. throw InvalidAccessError if called with something not identical to the last description
4. throw InvalidAccessError if called with fewer m-lines or different kind
5. throw InvalidAccessError like Chrome does, which may be the same as 4 or not?

[alvestrand]

Chrome's behavior is probably "Run the check for subsequent offers, and if those checks pass, accept it". That might be relatively easy to specify.