What does HRESULT 0x80EE0007 (RTC_E_SDP_PARSE_FAILED) mean?

Status / error code:		Category:

Constant name:
Source:	Operating System:
Description: Parsing SDP failed

Previous	Next
RTC_E_SDP_NOT_PRESENT	RTC_E_SDP_UPDATE_FAILED

RTC_E_SDP_PARSE_FAILED

Protocol boundary: `RTC_E_SDP_PARSE_FAILED`

This HRESULT is emitted for a defined RTC state rather than an unspecified communications problem; for this HRESULT, that state is the message body is labeled or treated as SDP but violates the SDP grammar or field requirements.

At the HRESULT layer, this result appears as 0x80EE0007 in the RTC interface facility 0xEE; for this HRESULT, preserving the facility and symbol prevents it from being grouped incorrectly with unrelated networking or media errors.

A defensible diagnosis of this result requires you to validate line endings, mandatory v/o/s/t fields, media lines, attributes, and payload mappings; in the case, this differs from RTC_E_SIP_PARSE_FAILED because SIP framing succeeded and the body parser failed.

Minimum incident record

Build the incident record before automatic recovery runs; the result record must identify one client/profile/session generation and the exact signaling, presence, or media transition in progress.

Code-specific proof for this HRESULT: validate line endings, mandatory v/o/s/t fields, media lines, attributes, and payload mappings.
Owning object for this HRESULT: start-line plus header names.
Wire evidence for this HRESULT: Content-Type and Content-Length.
Lifecycle generation for this HRESULT: SDP o= version and c= address.

A useful this result trace does not require communication content or secrets; in the result record, keep structural metadata and correlation identifiers while removing passwords, authorization material, complete numbers, and private presence data.

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 message body is labeled or treated as `SDP` but violates the `SDP` grammar or field requirements
Safe corrective direction	fix the `SDP` producer and retain the original offer/answer transaction state

At the boundary, SIP transaction state and media negotiation are separate: a syntactically valid SIP request can still contain absent or unacceptable SDP; separately, this result must be read with the rule that An SDP update must be checked against the previous offer/answer state, not merely parsed as a standalone text document.

Correct application response

The corrective direction for this HRESULT is to fix the SDP producer and retain the original offer/answer transaction state; for this HRESULT, cancellation, cleanup, and retry should remain with the component that owns the failed transition.

A retry after it is safe only after the prior transaction’s outcome is reconciled; after it, reissuing state-changing requests while the peer result is unknown can create contradictory RTC state.

Example for this HRESULT: A gateway emits an m= line with a nonnumeric port and the RTC SDP parser rejects the body.

How to prove the condition

Start from 0x80EE0007 and it, then find the method/event pair that first exposed it.
the proof step is to validate line endings, mandatory v/o/s/t fields, media lines, attributes, and payload mappings.
check whether the failure was local before transmission, produced during RTC state validation, or mapped from a remote response.
keep the analysis at the right boundary: this differs from RTC_E_SIP_PARSE_FAILED because SIP framing succeeded and the body parser failed.
after you fix the SDP producer and retain the original offer/answer transaction state, repeat the smallest reproducer rather than restarting the entire application environment.

Correlate wire data and RTC events for this HRESULT; for this HRESULT, either source alone can misclassify local validation as remote rejection, or a remote status as a local media or profile failure.

Nearby failure modes

It is tied to the condition “the message body is labeled or treated as SDP but violates the SDP grammar or field requirements”; preserve that producing boundary before choosing recovery; for this HRESULT, the neighboring results below require different control-flow decisions.

`RTC_E_SIP_INVITE_TRANSACTION_PENDING`	another INVITE or re-INVITE transaction still owns the dialog’s offer/answer state
`RTC_E_SIP_PARSE_FAILED`	the RTC SIP parser could not construct a valid message from the received or generated bytes
`RTC_E_SDP_NOT_PRESENT`	the signaling path expected an SDP offer or answer but the SIP message contains no usable SDP body

Telemetry for this HRESULT should retain these distinctions even when several outcomes share HRESULT severity.

Actions that do not address this condition

With it, do not repair malformed signaling by silently deleting unknown headers or media sections.
also do not log credentials or an unredacted SDP body from production calls.
Do not translate it into a broad “connection failed” label before preserving the RTC symbol and producing phase.

Verification after a fix

A regression test for this HRESULT should reproduce “the message body is labeled or treated as SDP but violates the SDP grammar or field requirements” with the smallest profile, message, session, presence, media, or PINT fixture; for this HRESULT, assert 0x80EE0007, 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 — API or protocol rules used to interpret it.
SIP message and transaction rules — authoritative context for the boundary.
SDP syntax — definitions relevant when reproducing it.
SDP offer/answer — API or protocol rules used to interpret it.

Looking for a different code? Search another status or error code.