1753018 - Allow a=bundle-only in answers

Status: NEW

(Core :: WebRTC: Signaling, defect, P3)

Description

[windicted]

Steps to reproduce:

If we add multiple transceivers of the same kind to a RTCPeerConnection object, then Firefox generates an offer SDP where the second and the subsequent media sections have zero ports and include 'bundle-only' attributes. This complies with the RFC8843, but Firefox fails to comply with the RFC when it processes an answer SDP which also contains media sections with zero ports and 'bundle-only' attributes: the browsers stops any transceiver if the corresponding media section in the answer SDP contains zero port and bundle-only attribute, whereas it should not.

Here is a short code snippet which you can use to reproduce the issue (you can copy-past it to the browser's console):

let pc1 = new RTCPeerConnection();
let t1 = pc1.addTransceiver("audio", { direction: "sendonly" });
let t2 = pc1.addTransceiver("audio", { direction: "sendonly" });
let offer = await pc1.createOffer();
await pc1.setLocalDescription(offer);
console.log("Offer SDP:\n" + offer.sdp);

// Here we emulate answerer which complies with RFC8843: we include an SDP 'bundle-only'
// attribute in, and assign a zero port value to, every non answerer-tagged bundled "m="
// section within the BUNDLE group. In our case this is the second 'm=audio' section.
let pc2 = new RTCPeerConnection();
pc2.setRemoteDescription(offer);
let answer = await pc2.createAnswer();
answer.sdp = answer.sdp.replace('}\r\nm=audio 9', '}\r\nm=audio 0') + 'a=bundle-only\r\n';

await pc1.setRemoteDescription(answer);
console.log("Answer SDP:\n" + answer.sdp);
console.log("Transceiver t1 is stopped: " + t1.stopped);
console.log("Transceiver t2 is stopped: " + t2.stopped);

After running the snippet you will see that the 't2' transceiver is stopped, whereas according to RFC8843 it should not.

Actual results:

Firefox stopped a transceiver if the corresponding media section in the answer SDP was assigned zero port and included bundle-only attribute.

Expected results:

Firefox should have either complied with RFC8843 (section 7.3 to be more specific) and should not have stopped a transceiver, or it should not have assigned zero port to, and included 'bundle-only' attribute in, any media section in its offer SDP.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::WebRTC: Signaling' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[Byron Campen [:bwc]]

Hmm, it seems that in version 41, the bundle spec changed to allow a=bundle-only in answers. We'll need to update our code to match at some point.

https://www.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-mmusic-sdp-bundle-negotiation-41.txt

Comment 3

[Byron Campen [:bwc]]

Also, the bundle spec switched from forbidding a=bundle-only in answers to requiring a=bundle-only in answers. In order to be fully compliant, we're going to need to do this in multiple stages:

1. Start accepting a=bundle-only in answers.
2. Once the acceptance of a=bundle-only is on all supported branches, and we determine that it is also accepted on all supported versions of Chrome/Edge/Safari, we can switch over to emitting a=bundle-only in answers. We may want to add a non-standard config to RTCPeerConnection for turning this new behavior off, for services that do not support a=bundle-only in answers.

Comment 4

[andysem]

I would like to note that using port 0 with bundle-only is a breaking change for clients that don't support it and expect port 0 to be an indication of a rejected media section. This actually affected our MCU software that supported an early bundle RFC draft but not bundle-only with port 0.

I'm not saying Firefox should not support RFC8843 - it should. However, the bundle-only part of the spec is not backwards compatible, and perhaps that part should not be used by Firefox by default. That is, the offers generated by Firefox should probably avoid using bundle-only with port 0, but Firefox should support this when the SDP (offer or answer) is being set to PeerConnection.

Also, one other thing I'd like to point out is attribute handling for attributes with IDENTICAL and TRANSPORT muxing categories. https://datatracker.ietf.org/doc/html/rfc8843#section-7.1.3 requires that such attributes are not included in bundle-only sections of an initial offer or any bundled sections except the tagged one in the subsequent offers and answers. Even if such attributes do not apply to the tagged section transport (e.g. "a=rtcp-mux" in a data channel media section). Firefox 96 does not follow that part either. I realize that changing SDP handling to follow that part of the spec would be another breaking change, so I would like to ask what the plan is wrt. this.

Comment 5

[Byron Campen [:bwc]]

(In reply to andysem from comment #4)

I would like to note that using port 0 with bundle-only is a breaking change for clients that don't support it and expect port 0 to be an indication of a rejected media section. This actually affected our MCU software that supported an early bundle RFC draft but not bundle-only with port 0.

I'm not saying Firefox should not support RFC8843 - it should. However, the bundle-only part of the spec is not backwards compatible, and perhaps that part should not be used by Firefox by default. That is, the offers generated by Firefox should probably avoid using bundle-only with port 0, but Firefox should support this when the SDP (offer or answer) is being set to PeerConnection.

Ultimately, the default behavior needs to match the spec. I think it makes sense to have a transition period where a=bundle-only in created answers can be disabled (eg; with RTCConfiguration, or maybe answer options).

Also, one other thing I'd like to point out is attribute handling for attributes with IDENTICAL and TRANSPORT muxing categories. https://datatracker.ietf.org/doc/html/rfc8843#section-7.1.3 requires that such attributes are not included in bundle-only sections of an initial offer or any bundled sections except the tagged one in the subsequent offers and answers. Even if such attributes do not apply to the tagged section transport (e.g. "a=rtcp-mux" in a data channel media section). Firefox 96 does not follow that part either. I realize that changing SDP handling to follow that part of the spec would be another breaking change, so I would like to ask what the plan is wrt. this.

I would have to analyze this. I've filed bug 1753049.