| 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; for this HRESULT, the facility distinguishes local RTC validation from a response status mapped by the stack.
Before changing configuration for this HRESULT, 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 boundary
| RTC area | SIP message and SDP negotiation boundary |
|---|---|
| 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
It is tied to the condition “a new SDP description is incompatible with the prior negotiated offer/answer state”; preserve that producing boundary before choosing recovery; for this HRESULT, the neighboring results below require different control-flow decisions.
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 |
The comparison prevents it from being flattened into a subsystem-wide error bucket with unsafe generic remediation.
Telemetry and packet evidence
Correlate it at source: the method or callback, the owning object generation, and the active protocol transition; for this HRESULT, this keeps later retries from obscuring causality.
- Code-specific proof for this HRESULT: compare o= session version, media-line order, direction, addresses, codecs, and the pending offer owner.
- Addressing context for this HRESULT: start-line plus header names.
- RTC callback state for this HRESULT: Content-Type and Content-Length.
- Transaction boundary for this HRESULT:
SDPo= version and c= address. - Media or profile detail for this HRESULT: each m= line and codec mapping.
When recording it, redact credentials, full telephone numbers, private contact lists, and message bodies; for this HRESULT, retain permitted URI domains, header names, byte counts, hashes, transaction identifiers, timestamps, and state transitions.
Step-by-step isolation
- Start from
0x80EE0008and it, then find the method/event pair that first exposed it. - check whether the failure was local before transmission, produced during RTC state validation, or mapped from a remote response.
- the proof step is to compare o= session version, media-line order, direction, addresses, codecs, and the pending offer owner.
- 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.
The result diagnosis is strongest when object state and protocol trace share timestamps and transaction identifiers; when diagnosing it, avoid treating packet capture and HRESULT logging as substitutes for one another.
Actions that do not address this condition
- An investigation should not 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.
- Do not discard the result facility and state boundary when converting the result into application telemetry.
Remediation boundary
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.
Distinguish local rejection from an operation that may already have reached the server; for this HRESULT, use transaction identifiers and final events before replaying any non-idempotent action.
Example for this HRESULT: Two components issue overlapping re-INVITE changes and the later answer corresponds to the wrong offer.
Verification after a fix
A regression test for this HRESULT should reproduce “a new SDP description is incompatible with the prior negotiated offer/answer state” with the smallest profile, message, session, presence, media, or PINT fixture; for this HRESULT, assert 0x80EE0008, the responsible method/event, and the object state after the result; then, for this HRESULT, change only the decisive precondition and verify that the corrected run leaves no stale transaction or RTC object.
Technical references
- Microsoft RTC return constants — authoritative context for the boundary.
- SIP message and transaction rules — definitions relevant when reproducing it.
- SDP syntax — API or protocol rules used to interpret it.
- SDP offer/answer — authoritative context for the boundary.
Looking for a different code? Search another status or error code.