| Previous | Next |
| RTC_E_SIP_REFER_OPERATION_PENDING | RTC_E_SIP_PEER_PARTICIPANT_IN_MULTIPARTY_SESSION |
RTC_E_PLATFORM_NOT_SUPPORTED
What the RTC value marks: RTC_E_PLATFORM_NOT_SUPPORTED
The useful interpretation of this result is narrower than “SIP error”; within initialization, shutdown, platform support, and global client-object configuration, it means the installed Windows/RTC platform does not implement the requested API capability.
The stored Value is 0x80EE0080 in the RTC interface facility 0xEE; for this HRESULT, keep both forms in telemetry so COM error wrapping does not erase whether RTC produced an interface result, mapped a SIP response, or surfaced a PINT outcome.
Start the result investigation by having the trace record OS edition/build, RTC DLL version, interface queried, and feature path; for this HRESULT, do not skip the distinction that platform capability is persistent for that installation and should not be retried like a transient server problem.
A safe diagnostic sequence
- Locate the earliest this result producer and verify that no wrapper replaced a more specific lower-layer value.
- map that producer to the active RTC object and to one SIP, SDP, PINT, presence, media, or profile transition.
- collect enough evidence to record OS edition/build, RTC DLL version, interface queried, and feature path.
- test the competing explanation explicitly, because platform capability is persistent for that installation and should not be retried like a transient server problem.
- perform the narrow correction — use a supported fallback or migrate the feature to a supported communications stack — and validate both protocol completion and object cleanup.
A SIP capture without RTC callback state cannot show which local object accepted or rejected the transition; for this HRESULT, an HRESULT-only log has the opposite weakness: it cannot show whether the result was generated before transmission or mapped from the peer.
Evidence that separates the cause
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: record OS edition/build, RTC DLL version, interface queried, and feature path.
- Identity and target for this HRESULT: thread/apartment and event sink.
- State at production for this HRESULT: outstanding session/profile count.
- Timing and ordering for this HRESULT: OS and rtcdll.dll version.
When recording this result, redact credentials, full telephone numbers, private contact lists, and message bodies; for this HRESULT, retain permitted URI domains, header names, byte counts, hashes, transaction identifiers, timestamps, and state transitions.
Protocol and object boundary
| RTC area | RTC client lifecycle boundary |
|---|---|
| Objects to correlate | IRTCClient instance, initialization generation, shutdown state, event sink, platform capability |
| Condition to prove | the installed Windows/RTC platform does not implement the requested API capability |
| Safe corrective direction | use a supported fallback or migrate the feature to a supported communications stack |
Two RTC rules frame it: first, RTC Client API objects are stateful COM objects; child sessions and profiles belong to the client generation that created them; second, for this HRESULT, A shutdown transition invalidates pending operations even if application code still holds interface pointers.
Related RTC results
It should not be grouped with every value from the same facility. It is tied to the condition “the installed Windows/RTC platform does not implement the requested API capability”; preserve that producing boundary before choosing recovery; the result table shows nearby alternatives.
RTC_E_CLIENT_ALREADY_INITIALIZED | code attempted to initialize an RTC client instance that is already active |
|---|---|
RTC_E_NOT_ALLOWED | the RTC API contract rejects the action for the current object, role, or configuration |
RTC_E_CLIENT_ALREADY_SHUT_DOWN | the RTC client instance has completed shutdown and cannot service the requested operation |
Facility equality is not semantic equality; route each contrasted value through its own recovery branch.
How to handle the result
Recovery from it should be narrow: use a supported fallback or migrate the feature to a supported communications stack; while handling it, do not let a higher layer simultaneously recreate the same session, registration, listener, or profile.
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: An application calls a later RTC interface on a platform that only exposes an earlier API version.
Actions that do not address this condition
- The following shortcut is unsafe for this HRESULT: do not reuse child objects after shutdown or reinitialization.
- Another non-solution for this HRESULT is to do not hide lifecycle bugs by repeatedly constructing new clients inside a retry loop.
- A wrapper handling it should retain the original HRESULT instead of replacing it with an undifferentiated call failure.
Verification after a fix
Keep two tests: one that intentionally produces “the installed Windows/RTC platform does not implement the requested API capability”, and one that applies the narrow correction; for this HRESULT, check the callback sequence, 0x80EE0080, final session/profile state, and absence of leaked listeners, dialogs, streams, or registrations.
Technical references
- About the RTC Client API — definitions relevant when reproducing it.
- Microsoft RTC return constants — API or protocol rules used to interpret it.
Looking for a different code? Search another status or error code.