| Previous | Next |
| RTC_E_SIP_NO_STREAM | RTC_E_SIP_HEADER_NOT_PRESENT |
RTC_E_SIP_PARSE_FAILED
What the RTC value marks: RTC_E_SIP_PARSE_FAILED
This HRESULT is emitted for a defined RTC state rather than an unspecified communications problem; for it, that state is the RTC SIP parser could not construct a valid message from the received or generated bytes.
This result is represented as 0x80EE0004 in the RTC interface facility 0xEE; for it, record the symbolic name alongside the unsigned hexadecimal value; a decimal exception alone is poor evidence for RTC protocol diagnosis.
To establish this result, preserve a redacted byte range around the parse offset, transport framing, and Content-Length; for it, this matters because general SIP parse failure is broader than a missing required header or incomplete receive buffer.
Protocol and object boundary
| RTC area | SIP message and SDP negotiation boundary |
|---|---|
| Objects to correlate | SIP start-line and headers, message body framing, SDP session and media sections, offer/answer generation |
| Condition to prove | the RTC SIP parser could not construct a valid message from the received or generated bytes |
| Safe corrective direction | correct framing or syntax at the producer and replay only a sanitized fixture in tests |
SIP transaction state and media negotiation are separate: a syntactically valid SIP request can still contain absent or unacceptable SDP; the second rule relevant to this result is that An SDP update must be checked against the previous offer/answer state, not merely parsed as a standalone text document.
Evidence that separates the cause
The evidence set for it should begin at the first failing or completing RTC boundary; for it, reconnect and teardown events are secondary unless they caused the original result.
- Code-specific proof for it: preserve a redacted byte range around the parse offset, transport framing, and Content-Length.
- Identity and target for it: Content-Type and Content-Length.
- State at production for it:
SDPo= version and c= address. - Timing and ordering for it: each m= line and codec mapping.
Sanitize the result evidence before storage: secrets and user content should disappear, while framing, domains, sizes, hashes, timing, and object-state changes remain available for reproduction.
Related RTC results
The practical separator for it is this: this result is tied to the condition “the RTC SIP parser could not construct a valid message from the received or generated bytes”; preserve that producing boundary before choosing recovery; for it, compare that boundary with these related RTC values.
RTC_E_SIP_NEED_MORE_DATA | the receive buffer contains only part of a complete SIP message |
|---|---|
RTC_E_SIP_STREAM_PRESENT | code attempted to start a media stream already represented in the current RTC session state |
RTC_E_SDP_PARSE_FAILED | the message body is labeled or treated as SDP but violates the SDP grammar or field requirements |
Telemetry for it should retain these distinctions even when several outcomes share HRESULT severity.
A safe diagnostic sequence
- 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 preserve a redacted byte range around the parse offset, transport framing, and Content-Length.
- confirm the distinction that general
SIPparse failure is broader than a missing required header or incomplete receive buffer. - create a fresh operation generation after you correct framing or syntax at the producer and replay only a sanitized fixture in tests, and compare its final state with the failing run.
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.
How to handle the result
The appropriate response to it is not a blanket reconnect. Instead, correct framing or syntax at the producer and replay only a sanitized fixture in tests, while preserving ownership of cleanup and any bounded retry.
Do not turn it into an immediate unconditional retry; for it, first determine whether the peer could have accepted the prior request and whether RTC still owns a live transaction.
Example for it: A TCP receiver combines two SIP messages incorrectly and the second start-line appears inside the first body.
Actions that do not address this condition
- A it investigation should not do not log credentials or an unredacted SDP body from production calls.
- It is not corrected when operators do not repair malformed signaling by silently deleting unknown headers or media sections.
- Keep it intact through exception and UI layers; a generic parameter or network message is insufficient for diagnosis.
Verification after a fix
A useful it regression does more than expect an exception; the result test constructs “the RTC SIP parser could not construct a valid message from the received or generated bytes”, 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 — 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.