The SDP Offer/Answer Rules That Bite During WebRTC Renegotiation

WebRTC developers often overlook the significance of the SDP blob, as it seamlessly works during the initial negotiation, exchanging media streams, and handling various formats without concern. However, the true complexities arise during the renegotiation process, such as adding tracks, initiating screen sharing, or performing ICE restarts. When renegotiation occurs, errors occur, leading to a message that appears to be directed at someone else.

There are a few critical rules to be aware of, which are often hidden until you violate them. Media sections, each starting with an m= line, are positional, and their order is permanent. Once a session is established, the nth media section should always match the nth media section from the initial negotiation. They cannot be reordered or removed from the middle. Media sections in the answer must have the same order as the offer being answered.

Transceivers are represented as a collection of objects, which can be manipulated in various ways. However, media sections have unique semantics: adding is permissible (they always add at the end of the list), while everything else is illegal. The position of media sections is determined by the order of transceiver creation. The `getTransceivers()` method returns the list of transceivers in their creation order, which subsequently determines the order of media sections in the SDP. Any nondeterministic creation of transceivers results in nondeterministic SDP.

A common mistake is the order of `addTrack()` calls, which should not depend on surrounding logic but happen due to iterating over a collection of tracks, racing to acquire devices asynchronously, or conditional statements. This nondeterministic order can be frozen in the SDP after the first negotiation.

There are two important behaviors to be aware of. First, `addTransceiver()` always adds a new transceiver, whereas `addTrack()` might reuse an existing one with a free media section. Second, when a transceiver stops, it remains in `getTransceivers()` while stopping is negotiated, and only afterward is removed from the set of transceivers, while the media section becomes free for another transceiver.

The `setLocalDescription()` method, called between `createOffer()` and `setLocalDescription(offer)`, closes the potential race window. It implicitly creates the correct description based on the current signaling state, eliminating the period when an obsolete description is held and conditional logic is required to decide if it is an offer or an answer. This approach eliminates one class of bugs - modification of the SDP description between creation and use.

When troubleshooting renegotiation issues, `InvalidAccessError` and `OperationError` provide valuable insights. InvalidAccessError is thrown when the description fails to pass semantics validation, requires RTCP multiplexing, or attempts to renegotiate RIDs, which is not allowed. All other cases result in an `OperationError`. InvalidAccessError indicates incompatibility with the established session, while OperationError signifies something failed outside the scope of the session.

The protocol does not prevent simultaneous offers from both parties. It occurs when both react to a change in the situation.