| Previous | Next |
| RTC_E_MEDIA_VIDEO_DEVICE_NOT_AVAILABLE | RTC_E_MEDIA_AEC |
RTC_E_START_STREAM
Where the state changes: RTC_E_START_STREAM
In the RTC Client API, this result separates one failure or completion path from its neighbors because it denotes RTC could not move a negotiated stream into the started state.
At the HRESULT layer, this result appears as 0x80EE0023 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.
To establish this result, collect terminal, format, codec, controller state, port mapping, and lower-level device error; for this HRESULT, this matters because this is a start-transition failure after stream definition, broader than one specific missing device.
Telemetry and packet evidence
Capture the first result before retry, reconnect, profile re-enable, or teardown changes the evidence; associate this result with one RTC object generation and one transaction or media transition.
- Code-specific proof for this HRESULT: collect terminal, format, codec, controller state, port mapping, and lower-level device error.
- Addressing context for this HRESULT: stream direction and negotiated codec.
- RTC callback state for this HRESULT: device removal or format-change event.
- Transaction boundary for this HRESULT: session and media type.
- Media or profile detail for this HRESULT: terminal/device identifier.
For privacy-safe analysis of it, preserve protocol structure rather than payload content; for this HRESULT, authentication values, complete addresses, buddy lists, and bodies should be redacted or hashed under policy.
Protocol and object boundary
| RTC area | RTC media controller and terminal boundary |
|---|---|
| Condition to prove | RTC could not move a negotiated stream into the started state |
| Objects to correlate | RTC session, media type, terminal/device, stream direction, controller state, acoustic echo cancellation |
| Safe corrective direction | repair the first failing media dependency and repeat one controlled start transition |
Interpreting it requires both of these facts: Signaling success does not guarantee that a capture or render device exists or that a media stream can start; also, the result branch assumes that AddStream, RemoveStream, hold, and terminal selection change the media state machine and can race with callbacks from the previous operation.
Actions that do not address this condition
- The following shortcut is unsafe for this HRESULT: do not recreate the entire SIP session before determining whether only a local terminal failed.
- also do not assume the default Windows device is the terminal selected by the RTC object.
- Keep it intact through exception and UI layers; a generic parameter or network message is insufficient for diagnosis.
Step-by-step isolation
- Record it and
0x80EE0023at the first RTC method or event that returns it. - Identify the client, profile, session, participant, presence object, terminal, or port manager that owns this it occurrence.
- Place it in its exact phase: parsing, discovery, transport, authentication, profile validation, dialog control, media, roaming, registration, redirection, or final response handling.
- prove the condition by ensuring the trace can collect terminal, format, codec, controller state, port mapping, and lower-level device error.
- Apply one controlled change for this HRESULT: repair the first failing media dependency and repeat one controlled start transition; then verify the result return value and resulting RTC state.
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.
Remediation boundary
The owning RTC component should repair the first failing media dependency and repeat one controlled start transition; for this HRESULT, it should also settle or cancel its previous operation before callers begin a replacement.
Do not turn it into an immediate unconditional retry; for this HRESULT, first determine whether the peer could have accepted the prior request and whether RTC still owns a live transaction.
Example for this HRESULT: Audio SDP is accepted, but the selected terminal cannot initialize the negotiated format.
Comparison with adjacent codes
It should not be grouped with every value from the same facility. It is tied to the condition “RTC could not move a negotiated stream into the started state”; preserve that producing boundary before choosing recovery; the result table shows nearby alternatives.
RTC_E_MEDIA_DISABLED | the requested media operation requires media that has been disabled for the client or session |
|---|---|
RTC_E_MEDIA_ENABLED | code attempted an enable transition for media that is already enabled |
RTC_E_MEDIA_NEED_TERMINAL | the media stream has no terminal/device bound for the requested direction |
The comparison prevents it from being flattened into a subsystem-wide error bucket with unsafe generic remediation.
Verification after a fix
Verify the result fix with a minimal deterministic case that reaches “RTC could not move a negotiated stream into the started state”; the failing the case must assert the HRESULT and post-failure state; the passing case should alter one input and confirm both protocol outcome and cleanup.
Technical references
- About the RTC Client API — definitions relevant when reproducing it.
- Creating an RTC session — API or protocol rules used to interpret it.
- Microsoft RTC return constants — authoritative context for the boundary.
- SDP offer/answer — definitions relevant when reproducing it.
Looking for a different code? Search another status or error code.