What does HRESULT 0x80EE000B (RTC_E_SDP_NO_MEDIA) mean?

Status / error code:		Category:

Constant name:
Source:		Operating System:
Description: No media is available for the session

Previous	Next
RTC_E_SDP_CONNECTION_ADDR	RTC_E_SIP_TIMEOUT

RTC_E_SDP_NO_MEDIA

Operational meaning: `RTC_E_SDP_NO_MEDIA`

This result should be investigated at the point where RTC handles parsing, constructing, or reconciling SIP signaling and the SDP offer/answer carried by it, and the condition to prove for this HRESULT is the SDP contains no enabled media description usable for the requested RTC session.

This result is represented as 0x80EE000B in the RTC interface facility 0xEE; for this HRESULT, record the symbolic name alongside the unsigned hexadecimal value; a decimal exception alone is poor evidence for RTC protocol diagnosis.

A defensible diagnosis of this result requires you to enumerate m= lines, zero ports, directions, and the session type expected by the caller; in the case, an SDP document can parse successfully while offering no active media.

Signals worth preserving

The evidence set for this HRESULT should begin at the first failing or completing RTC boundary; for this HRESULT, reconnect and teardown events are secondary unless they caused the original result.

Code-specific proof for this HRESULT: enumerate m= lines, zero ports, directions, and the session type expected by the caller.
Correlation key for this HRESULT: each m= line and codec mapping.
Protocol or object snapshot for this HRESULT: message direction and transport.
Last completed transition for this HRESULT: start-line plus header names.
Expected output for this HRESULT: Content-Type and Content-Length.

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.

Protocol and object boundary

RTC area	`SIP` message and `SDP` negotiation boundary
Condition to prove	the `SDP` contains no enabled media description usable for the requested RTC session
Objects to correlate	`SIP` start-line and headers, message body framing, `SDP` session and media sections, offer/answer generation
Safe corrective direction	offer at least one supported media line or use a nonmedia session type

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.

Verification workflow

Start from 0x80EE000B and it, then find the method/event pair that first exposed it.
check whether the failure was local before transmission, produced during RTC state validation, or mapped from a remote response.
the proof step is to enumerate m= lines, zero ports, directions, and the session type expected by the caller.
keep the analysis at the right boundary: an SDP document can parse successfully while offering no active media.
after you offer at least one supported media line or use a nonmedia session type, repeat the smallest reproducer rather than restarting the entire application environment.

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.

Do not confuse it with

The practical separator for this HRESULT is this: it is tied to the condition “the SDP contains no enabled media description usable for the requested RTC session”; preserve that producing boundary before choosing recovery; for this HRESULT, compare that boundary with these related RTC values.

`RTC_E_SDP_CONNECTION_ADDR`	an SDP media description has no usable connection address at session or media level
`RTC_E_SDP_FAILED_TO_BUILD`	the RTC stack could not serialize the current media/session state into an SDP offer or answer
`RTC_E_SIP_STREAM_NOT_PRESENT`	code attempted to stop or remove a stream that is not active in the current session generation

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

Recovery and control flow

The appropriate response to it is not a blanket reconnect. Instead, offer at least one supported media line or use a nonmedia session type, while preserving ownership of cleanup and any bounded retry.

Before retrying it, classify the previous operation as definitely failed, definitely completed, or remotely uncertain; for this HRESULT, that distinction prevents duplicate dialogs, bindings, transfers, or roaming mutations.

Example for this HRESULT: A re-INVITE sets all media ports to zero and code then tries to start an audio call.

Actions that do not address this condition

An investigation should not 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.
Do not translate it into a broad “connection failed” label before preserving the RTC symbol and producing phase.

Verification after a fix

Keep two tests: one that intentionally produces “the SDP contains no enabled media description usable for the requested RTC session”, and one that applies the narrow correction; for this HRESULT, check the callback sequence, 0x80EE000B, final session/profile state, and absence of leaked listeners, dialogs, streams, or registrations.

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.