v148 · WebRTC · Web APIs

WebRTC Datachannel: Always negotiate data channels

The new alwaysNegotiateDataChannels option for RTCPeerConnection tells the browser to include data channel negotiation in every SDP offer and answer — eliminating a class of race conditions where one peer creates a channel before the other is ready to receive it.

concepts

  1. Negotiation Modes Comparison

    Side-by-side code and SDP excerpt comparison showing how alwaysNegotiateDataChannels pre-includes the m=application line in the offer, compared to the on-demand approach that can trigger a costly renegotiation.

  2. Connection Timeline Walkthrough

    Animated step-through of the SDP offer/answer exchange and data channel creation, contrasting the old timing-sensitive flow with the new always-negotiated flow that is safe regardless of when createDataChannel() is called.

  3. File Transfer Demo

    P2P file transfer over a loopback RTCPeerConnection with alwaysNegotiateDataChannels: true. A toggle runs the timing-sensitive default path — disable it to watch a late channel require renegotiation instead of opening immediately.

  4. Data Channel Setup Wizard

    A 5-step wizard that runs a real RTCPeerConnection loopback in-page, showing step states (active/done/error). Live SDP offer display highlights the m=application section. A 3-tab negotiation modes panel explains in-band (Chrome 148 always-on), out-of-band, and pre-negotiated data channels.

  5. SDP Inspector

    Parse and syntax-highlight SDP offer/answer text to find and explain the m=application section. Generates real offers from RTCPeerConnection with and without a prior createDataChannel() call so you can compare the SDP difference live. Paste any SDP to get a field breakdown: SCTP port, max message size, BUNDLE group, and whether data channels were pre-negotiated.

why it shipped

WebRTC data channels are negotiated as part of the SDP offer/answer exchange. Traditionally, the m=application section only appears in the SDP if createDataChannel() has been called before the offer is generated. If the remote peer calls createDataChannel() first but the local offer is sent before that call completes, the resulting SDP has no data channel section — and a full renegotiation must occur, adding latency and complexity. alwaysNegotiateDataChannels: true pre-includes the m=application section in every offer unconditionally, so data channels can be created at any point without triggering renegotiation.

references

implementation reference

Need the exact API surface, compatibility boundaries, errors, lifecycle, and source links? Read the matching gendn reference ↗