| 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; 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; 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
- 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.
- Apply the targeted fix — use a supported fallback or migrate the feature to a supported communications stack — and validate both protocol completion and object cleanup.
Evidence that separates the cause
- Code-specific proof: record OS edition/build, RTC DLL version, interface queried, and feature path.
- Identity and target: thread/apartment and event sink.
- State at production: outstanding session/profile count.
- Timing and ordering: OS and rtcdll.dll version.
Protocol and object state
| RTC area | RTC client lifecycle |
|---|---|
| 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 |
RTC Client API objects are stateful COM objects; child sessions and profiles belong to the client instance that created them. A shutdown transition invalidates pending operations even if application code still holds interface pointers.
Related RTC results
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 |
How to handle the result
Recovery should be narrow: use a supported fallback or migrate the feature to a supported communications stack; while handling this result, do not let a higher layer simultaneously recreate the same session, registration, listener, or profile.
Example: An application calls a later RTC interface on a platform that only exposes an earlier API version.
Actions that do not address this condition
- Do not reuse child objects after shutdown or reinitialization.
- Do not hide lifecycle bugs by repeatedly constructing new clients inside a retry loop.
Technical references
Looking for a different code? Search another status or error code.