Most offer/answer bugs are not syntax problems. They are state and sequencing problems.

Question

If WebRTC negotiation fails, what order should I debug SDP offer/answer state?

Quick answer

If negotiation fails, verify this order:

  1. offer created after tracks are attached,
  2. local description set before signaling send,
  3. remote description applied before remote candidates,
  4. renegotiation events serialized.

High-yield checks

  1. Confirm you are not sending stale offers during concurrent updates.
  2. Log SDP direction attributes for each media section.
  3. Verify both sides apply the same codec expectations.
  4. Correlate negotiation timestamps with ICE state transitions.

Failure pattern

Teams often chase ICE first when the root issue is an invalid negotiation sequence. Fix signaling order first, then revisit transport.

Negotiation timeline template

Capture this per session:

t0: tracks attached
t1: createOffer
t2: setLocalDescription
t3: offer sent
t4: remote offer received
t5: setRemoteDescription
t6: createAnswer
t7: setLocalDescription(answer)
t8: answer sent
t9+: ICE states (checking/connected/failed)

If timestamps are out of order, fix signaling sequence before touching ICE config.

10-minute action step

  1. Capture one failing and one successful session log from your signaling layer.
  2. Trace offer/answer, ICE, and candidate events in strict timestamp order.
  3. Mark the first divergence point and tie it to one concrete fix.
  4. Re-test with the same network path and verify behavior is deterministic.

Success signal

You can identify exactly where negotiation broke and prove the same class of failure no longer reproduces.