Introduction

WebRTC developers often ignore SDP details until renegotiation breaks things. Adding tracks, starting a screen share, or performing an ICE restart can trigger cryptic errors. Understanding the hidden rules behind the scenes prevents hours of debugging.

What Happened

SDP session descriptions consist of media sections, each starting with an m= line. Once a session is established, the nth media section in any answer must always match the nth section from the initial negotiation. These sections cannot be reordered or removed from the middle—the order is permanent after the first negotiation. This positional semantics often confuses developers because the API seems flexible with transceivers, but media sections have strict semantics: their position is their identity.

Why This Matters

These rules exist because WebRTC's offer/answer model is a shared, sequential state machine. Media sections are identified by position, not index. When renegotiation adds streams, mismatched ordering triggers an error about mismatched m-line order in the answer. Recognizing this prevents costly downtime and ensures smooth track additions, screen shares, and ICE restarts.

Key Takeaways

  • Media section order is permanent once a session is established.
  • Transceiver creation order dictates the final SDP layout; nondeterministic iteration or conditional adds lock in unpredictable ordering frozen after the first negotiation.
  • Explicitly add tracks in the intended order; avoid async iteration or conditional adds that encode nondeterminism right into the session.
  • Use the mid field to correlate transceivers across peers, not array indices.
  • Call setLocalDescription() without parameters to let the browser generate the correct description state-aware, eliminating race windows.
  • Distinguish InvalidAccessError (SDP incompatibility) from OperationError (runtime failure) to debug faster.
  • For simultaneous offers, use the rollback pattern: set local description type to rollback and establish a polite/impolite negotiation pattern.

Conclusion

WebRTC renegotiation doesn't have to be a minefield. By respecting the positional nature of media sections, controlling transceiver creation order, and leveraging the browser's implicit description generation, developers can avoid common pitfalls and keep real-time connections stable. Master these SDP rules, and future renegotiations become predictable rather than painful.