| Previous | Next |
| RTC_E_SIP_PARSE_FAILED | RTC_E_SDP_NOT_PRESENT |
RTC_E_SIP_HEADER_NOT_PRESENT
Where the state changes: RTC_E_SIP_HEADER_NOT_PRESENT
Read this result as an RTC state-machine result: at this point in parsing, constructing, or reconciling SIP signaling and the SDP offer/answer carried by it, an RTC operation requires a SIP header that is absent from the parsed message.
Log this result as 0x80EE0005 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.
The first useful check for this HRESULT is to identify the method/status and exact required header, then inspect whether a proxy removed or failed to generate it; The result must be separated from nearby conditions because the message can be syntactically parseable while still lacking a header required by that transaction or extension.
Telemetry and packet evidence
Correlate this result 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: identify the method/status and exact required header, then inspect whether a proxy removed or failed to generate it.
- 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.
For privacy-safe analysis of this result, preserve protocol structure rather than payload content; for this HRESULT, authentication values, complete addresses, buddy lists, and bodies should be redacted or hashed under policy.
Protocol and object boundary
| RTC area | SIP message and SDP negotiation boundary |
|---|---|
| Condition to prove | an RTC operation requires a SIP header that is absent from the parsed message |
| Objects to correlate | SIP start-line and headers, message body framing, SDP session and media sections, offer/answer generation |
| Safe corrective direction | fix message generation or intermediary policy and reject the message without inventing a header value |
Interpreting it 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.
Actions that do not address this condition
- The following shortcut is unsafe for this HRESULT: do not log credentials or an unredacted SDP body from production calls.
- Another non-solution for this HRESULT is to do not repair malformed signaling by silently deleting unknown headers or media sections.
- Do not translate it into a broad “connection failed” label before preserving the RTC symbol and producing phase.
Step-by-step isolation
- At the source of it, preserve the HRESULT, method or callback, timestamp, thread/task correlation, and object generation.
- reconstruct the immediately preceding RTC transition instead of beginning with the later disconnect or UI notification.
- use protocol and object evidence to identify the method/status and exact required header, then inspect whether a proxy removed or failed to generate it.
- confirm the distinction that the message can be syntactically parseable while still lacking a header required by that transaction or extension.
- create a fresh operation generation after you fix message generation or intermediary policy and reject the message without inventing a header value, and compare its final state with the failing run.
A SIP capture without RTC callback state cannot show which local object accepted or rejected the transition; for this HRESULT, an HRESULT-only log has the opposite weakness: it cannot show whether the result was generated before transmission or mapped from the peer.
Remediation boundary
The owning RTC component should fix message generation or intermediary policy and reject the message without inventing a header value; for this HRESULT, it should also settle or cancel its previous operation before callers begin a replacement.
Do not turn it into an immediate unconditional retry; for this HRESULT, first determine whether the peer could have accepted the prior request and whether RTC still owns a live transaction.
Example for this HRESULT: A transfer flow receives a REFER without the Refer-To header needed to identify the target.
Comparison with adjacent codes
It is tied to the condition “an RTC operation requires a SIP header that is absent from the parsed message”; preserve that producing boundary before choosing recovery; for this HRESULT, the neighboring results below require different control-flow decisions.
RTC_E_SIP_UDP_SIZE_EXCEEDED | the serialized SIP datagram exceeds the size accepted by the RTC UDP transport path |
|---|---|
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_SDP_UPDATE_FAILED | a new SDP description is incompatible with the prior negotiated offer/answer state |
Facility equality is not semantic equality; route each contrasted value through its own recovery branch.
Verification after a fix
A useful it regression does more than expect an exception; the result test constructs “an RTC operation requires a SIP header that is absent from the parsed message”, checks the exact HRESULT at the producing RTC boundary, and verifies state ownership before and after the targeted correction.
Technical references
- Microsoft RTC return constants — definitions relevant when reproducing it.
- SIP message and transaction rules — API or protocol rules used to interpret it.
- SDP syntax — authoritative context for the boundary.
- SDP offer/answer — definitions relevant when reproducing it.
Looking for a different code? Search another status or error code.