What does HRESULT 0x80EE0005 (RTC_E_SIP_HEADER_NOT_PRESENT) mean?

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; the facility distinguishes local RTC validation from a response status mapped by the stack.

The first useful check 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

• Code-specific proof: identify the method/status and exact required header, then inspect whether a proxy removed or failed to generate it.
• Addressing context: start-line plus header names.
• RTC callback state: Content-Type and Content-Length.
• Transaction boundary: SDP o= version and c= address.
• Media or profile detail: each m= line and codec mapping.

Protocol and object state

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

• 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.

Step-by-step isolation

1. Confirm the distinction that the message can be syntactically parseable while still lacking a header required by that transaction or extension.
2. Start a fresh operation 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.

Recovery

The owning RTC component should fix message generation or intermediary policy and reject the message without inventing a header value; it should also settle or cancel its previous operation before callers begin a replacement.

Example: A transfer flow receives a REFER without the Refer-To header needed to identify the target.

Comparison with adjacent codes

Technical references

• Microsoft RTC return constants.
• SIP message and transaction rules.
• SDP syntax.
• SDP offer/answer.