| Previous | Next |
| RTC_E_SDP_PARSE_FAILED | RTC_E_SDP_MULTICAST |
RTC_E_SDP_UPDATE_FAILED
Where the state changes: RTC_E_SDP_UPDATE_FAILED
The operational meaning of this result is tied to parsing, constructing, or reconciling SIP signaling and the SDP offer/answer carried by it: a new SDP description is incompatible with the prior negotiated offer/answer state.
Log this result as 0x80EE0008 in the RTC interface facility 0xEE, not only as a signed decimal; the facility distinguishes local RTC validation from a response status mapped by the stack.
Before changing configuration, compare o= session version, media-line order, direction, addresses, codecs, and the pending offer owner; the RTC codes surrounding this result are not equivalent because a standalone-valid SDP can still be an invalid update to an established session.
Protocol and object state
| RTC area | SIP message and SDP negotiation |
|---|---|
| Condition to prove | a new SDP description is incompatible with the prior negotiated offer/answer state |
| Objects to correlate | SIP start-line and headers, message body framing, SDP session and media sections, offer/answer generation |
| Safe corrective direction | serialize offer/answer changes and build the update from the current negotiated description |
Interpreting this result requires both of these facts: SIP transaction state and media negotiation are separate: a syntactically valid SIP request can still contain absent or unacceptable SDP; also, the result branch assumes that An SDP update must be checked against the previous offer/answer state, not merely parsed as a standalone text document.
Comparison with adjacent codes
RTC_E_SIP_STREAM_NOT_PRESENT | code attempted to stop or remove a stream that is not active in the current session generation |
|---|---|
RTC_E_SIP_HEADER_NOT_PRESENT | an RTC operation requires a SIP header that is absent from the parsed message |
RTC_E_SDP_PARSE_FAILED | the message body is labeled or treated as SDP but violates the SDP grammar or field requirements |
Telemetry and packet evidence
- Code-specific proof: compare o= session version, media-line order, direction, addresses, codecs, and the pending offer owner.
- Addressing context: start-line plus header names.
- RTC callback state: Content-Type and Content-Length.
- Transaction boundary:
SDPo= version and c= address. - Media or profile detail: each m= line and codec mapping.
Step-by-step isolation
- Start from
0x80EE0008, then find the method/event pair that first exposed it. - Keep the analysis at the right boundary: a standalone-valid
SDPcan still be an invalid update to an established session. - After you serialize offer/answer changes and build the update from the current negotiated description, repeat the smallest reproducer rather than restarting the entire application environment.
Actions that do not address this condition
- Do not log credentials or an unredacted SDP body from production calls.
- Do not repair malformed signaling by silently deleting unknown headers or media sections.
Recovery
Resolve it at its producing layer: serialize offer/answer changes and build the update from the current negotiated description; after it, a separate UI or watchdog retry must wait until that layer reports a final state.
Example: Two components issue overlapping re-INVITE changes and the later answer corresponds to the wrong offer.
Technical references
Looking for a different code? Search another status or error code.