| 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
0x80EE000Band 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
SDPdocument 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.