Always negotiate datachannels

[fippo]

extending JSEP rules to negotiate datachannels before createDataChannel and negotiate them as the first m-line in the SDP.

const pc = new RTCPeerConnection({alwaysNegotiateDataChannels: true});
pc.addTransceiver('audio');
await offer = pc.createOffer();
// assert that the first m= line is m=application

JSEP issue: rtcweb-wg/jsep#1039

Fixes #241

---

Preview | Diff

[jan-ivar]

@docfaraday what can we expect wrt rtcweb-wg/jsep#1039 here? What's next steps?

[jan-ivar]

Can we add a note somewhere to clarify this changes the m-line order? As presented, this effect and its benefit wrt BUNDLE seems important to include as a reason why someone may want to use this API

[fippo]

Added, don't forget to squash (or I can squash)

[docfaraday]

If we're going to note the "bundle-tag rejection trap avoidance" benefit, we might also want to mention that this benefit only applies with bundlePolicy=="max-bundle" (for "max-compat" the problem does not exist in the first place, and for "balanced" it won't help).

[fippo]

for balanced it would help since (surprise!) if you reject the bundle-tagged m-line you can still not move to the next per https://datatracker.ietf.org/doc/html/rfc8843#section-7.3.3 ?

(and it looks like Firefox and Chrome disagree what max-compat means... Firefox does not bundle, Chrome bundles)

[docfaraday]

I'm not sure I understand. If it is in a group all by itself, (which is what "balanced" says to do, sort of, it's worded poorly), rejecting it destroys that transport, but since nothing else is in there it's fine. On the other side, if you have multiple m=audio, those will share a transport, but rejecting that bundle tag still messes things up; it's not the first m-section overall, but it still can destroy a transport and bring down everything bundled with it.

[fippo]

https://jsfiddle.net/fippo/5y6ag2Lw/1/-- I don't see separate bundle groups with balanced? (nor do I see the second audio m-line marked as bundle-only)

Either way, do we agree this is cheap and solves a (max-bundle) headache without overpromising?

[docfaraday]

This is strikingly similar to the offerToReceiveX options on createOffer. Hypothetically, if we followed those as an example, we would get something pretty similar to what this proposal does. I think we would need to do some extra work to ensure that the m=application section was up top though. One potential benefit would be to allow this to be used after the initial negotiation; there's no way to ensure that this m=application is up top, but it still would allow the creation of one without forcing the offerer to create a channel. Something to consider.

[fippo]

offerTo* is dubbed "legacy" (ignoring that a significant percentage of Chrome usage does this) and (more importantly) does not work with setLocalDescription()

[fippo]

https://w3c.github.io/webrtc-pc/#webidl-862292147 also needs a slight tweak, changing

20. If channel is the first RTCDataChannel created on connection and no m=section exists for data, update the negotiation-needed flag for connection.

I think the condition for that can be expressed using [[SctpTransport]] not being null.

Expected behavior:
Creating with alwaysNegotiateDataChannels should not fire ONN immediately.
Creating with alwaysNegotiateDataChannels and creating a data channel should fire ONN.
Creating with alwaysNegotiateDataChannels and adding a audio transceiver should result in two m-lines but fire ONN as result of adding audio. Calling createDataChannel way after that should not fire ONN.

Drive-by:

• Step 19 should check if transport is not null before checkings its connected state?
• Step 20 should check if this is the first datachannel on the transport, not the connection or alternatively if a transport needs to be created? SCTP getting rejected and recreated might be rare but...

[youennf]

@fippo, are you planning to update the PR according your latest comment?

[fippo]

@youennf this requires a PR against webrtc-pc

[alvestrand]

we have multiple places in webrtc-extensions that contain what's effectively instructions to edit webrtc-pc when it gets merged.

[fippo]

Done. [[SctpTransport]] is missing an export in the dfn on line 1311. Should I file issues for the drive-by questions?