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

What `RTC_E_SDP_PARSE_FAILED` means in RTC

This HRESULT is emitted for a defined RTC state rather than an unspecified communications problem; 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; 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

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

Protocol and object state

RTC area	`SIP` message and `SDP` negotiation
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

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

Correct application response

To correct this, fix the SDP producer and retain the original offer/answer transaction state.

Example: 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, then find the method/event pair that first exposed it.
To verify this, validate line endings, mandatory v/o/s/t fields, media lines, attributes, and payload mappings.
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.

Nearby failure modes

`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

Actions that do not address this condition

Do not repair malformed signaling by silently deleting unknown headers or media sections.
Do not log credentials or an unredacted SDP body from production calls.

Technical references

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