1481335 - If two RTCPeerConnections both call createDataChannel, two m=application sections are added instead of one

Status: RESOLVED WORKSFORME

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

Description

[mroberts]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36

Steps to reproduce:

Please run this JSFiddle: https://jsfiddle.net/nrbpywds/

You'll see two RTCPeerConnections do 3 rounds of negotiation. In the second round, `pc2` calls `createDataChannel` before offering; and, in the third round, `pc1` calls `createDataChannel` before offering.


Actual results:

The two RTCPeerConnections negotiate two `m=application` sections.

FWIW, it seems this behavior has been unchanged in Firefox since at least 55. I observe this behavior through the latest Nightly.


Expected results:

The two RTCPeerConnections negotiate a single `m=application` section.

I think this is expected, based on my reading of JSEP:

> 4.1.5.  createDataChannel
>
>    ...
>
>    All data channels on a given PeerConnection share the same SCTP/DTLS
>    association and therefore the same m= section, so subsequent creation
>    of data channels does not have any impact on the JSEP state.
>
>    ...
>

Comment 1

[Nils Ohlmeier [:drno]]

Thanks for reporting it. I was not aware of this. I also think it is not a big deal as the general assumption is that both sides should be aware that a data channel exists already and thus not call createDataChannel again. But it is still a bug on our end.

Comment 2

[Byron Campen [:bwc]]

The patches from bug 1496245 seem to fix this.