| Previous | Next |
| RTC_E_START_STREAM | RTC_E_CLIENT_NOT_INITIALIZED |
RTC_E_MEDIA_AEC
Protocol boundary: RTC_E_MEDIA_AEC
This result belongs to the RTC media controller and terminal boundary area of RTC and identifies RTC failed to enable acoustic echo cancellation for the audio path.
This result carries 0x80EE0024 in the RTC interface facility 0xEE; store the result value at the first RTC callback or method boundary, before retry logic replaces it with a broader timeout or connection message.
Collect enough state to record capture/render pairing, device formats, audio topology, and whether AEC was mandatory; the result evidence should demonstrate why AEC failure is an audio-processing capability issue and need not mean basic audio cannot run.
Protocol and object boundary
| RTC area | RTC media controller and terminal boundary |
|---|---|
| Objects to correlate | RTC session, media type, terminal/device, stream direction, controller state, acoustic echo cancellation |
| Condition to prove | RTC failed to enable acoustic echo cancellation for the audio path |
| Safe corrective direction | fall back only when product policy permits, or choose an AEC-compatible device path |
The surrounding protocol rule for this HRESULT is that Signaling success does not guarantee that a capture or render device exists or that a media stream can start; in addition, the path requires that AddStream, RemoveStream, hold, and terminal selection change the media state machine and can race with callbacks from the previous operation.
How to prove the condition
- At the source of this result, preserve the HRESULT, method or callback, timestamp, thread/task correlation, and object generation.
- reconstruct the immediately preceding RTC transition instead of beginning with the later disconnect or UI notification.
- use protocol and object evidence to record capture/render pairing, device formats, audio topology, and whether AEC was mandatory.
- confirm the distinction that AEC failure is an audio-processing capability issue and need not mean basic audio cannot run.
- create a fresh operation generation after you fall back only when product policy permits, or choose an AEC-compatible device path, and compare its final state with the failing run.
The result diagnosis is strongest when object state and protocol trace share timestamps and transaction identifiers; when diagnosing this result, avoid treating packet capture and HRESULT logging as substitutes for one another.
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: record capture/render pairing, device formats, audio topology, and whether AEC was mandatory.
- Owning object for this HRESULT: stream direction and negotiated codec.
- Wire evidence for this HRESULT: device removal or format-change event.
- Lifecycle generation for this HRESULT: session and media type.
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.
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.
- Another non-solution for this HRESULT is to do not assume the default Windows device is the terminal selected by the RTC object.
- Do not discard the result facility and state boundary when converting the result into application telemetry.
Correct application response
The owning RTC component should fall back only when product policy permits, or choose an AEC-compatible device path; for this HRESULT, it should also settle or cancel its previous operation before callers begin a replacement.
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 split capture/render device combination does not support the RTC echo-cancellation topology.
Nearby failure modes
The practical separator for this HRESULT is this: it is tied to the condition “RTC failed to enable acoustic echo cancellation for the audio path”; preserve that producing boundary before choosing recovery; for this HRESULT, compare that boundary with these related RTC values.
RTC_E_MEDIA_SESSION_NOT_EXIST | the requested media-session object no longer exists for the RTC signaling session |
|---|---|
RTC_E_MEDIA_SESSION_IN_HOLD | the media session is currently held and cannot perform the requested active-media operation |
RTC_E_NO_DEVICE | no preferred or compatible media device is available for the requested RTC media type |
Telemetry for this HRESULT should retain these distinctions even when several outcomes share HRESULT severity.
Verification after a fix
Verify the result fix with a minimal deterministic case that reaches “RTC failed to enable acoustic echo cancellation for the audio path”; 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.