| Previous | Next |
| RTC_E_SIP_PEER_PARTICIPANT_IN_MULTIPARTY_SESSION | RTC_E_REGISTRATION_DEACTIVATED |
RTC_E_NOT_ALLOWED
Operational meaning: RTC_E_NOT_ALLOWED
This result belongs to the RTC client lifecycle boundary area of RTC and identifies the RTC API contract rejects the action for the current object, role, or configuration.
This result carries 0x80EE0082 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 exact method, object type/state, selected profile, role, and any more specific earlier event; the result evidence should demonstrate why this generic prohibition must be narrowed by the producing API; it is not sufficient evidence of access-control failure.
Signals worth preserving
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 exact method, object type/state, selected profile, role, and any more specific earlier event.
- Correlation key for this HRESULT: client instance identity.
- Protocol or object snapshot for this HRESULT: Initialize and Shutdown call order.
- Last completed transition for this HRESULT: thread/apartment and event sink.
- Expected output for this HRESULT: outstanding session/profile count.
For privacy-safe analysis of this result, 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 client lifecycle boundary |
|---|---|
| Condition to prove | the RTC API contract rejects the action for the current object, role, or configuration |
| Objects to correlate | IRTCClient instance, initialization generation, shutdown state, event sink, platform capability |
| Safe corrective direction | follow the method’s state and role preconditions instead of broad permission changes |
At the boundary, RTC Client API objects are stateful COM objects; child sessions and profiles belong to the client generation that created them; separately, it must be read with the rule that A shutdown transition invalidates pending operations even if application code still holds interface pointers.
Verification workflow
- Start from
0x80EE0082and 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 record exact method, object type/state, selected profile, role, and any more specific earlier event.
- keep the analysis at the right boundary: this generic prohibition must be narrowed by the producing API; it is not sufficient evidence of access-control failure.
- after you follow the method’s state and role preconditions instead of broad permission changes, repeat the smallest reproducer rather than restarting the entire application environment.
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.
Do not confuse it with
It is tied to the condition “the RTC API contract rejects the action for the current object, role, or configuration”; preserve that producing boundary before choosing recovery; for this HRESULT, the neighboring results below require different control-flow decisions.
RTC_E_CLIENT_ALREADY_INITIALIZED | code attempted to initialize an RTC client instance that is already active |
|---|---|
RTC_E_MAX_PENDING_OPERATIONS | the RTC client reached its cap on concurrent asynchronous operations |
RTC_E_CLIENT_NOT_INITIALIZED | an RTC method was called before the client completed initialization |
Facility equality is not semantic equality; route each contrasted value through its own recovery branch.
Recovery and control flow
Resolve it at its producing layer: follow the method’s state and role preconditions instead of broad permission changes; after it, a separate UI or watchdog retry must wait until that layer reports a final state.
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: A call-control method is invoked on an object that does not own that side of the session.
Actions that do not address this condition
- An investigation should not do not reuse child objects after shutdown or reinitialization.
- Do not hide lifecycle bugs by repeatedly constructing new clients inside a retry loop.
- Keep it intact through exception and UI layers; a generic parameter or network message is insufficient for diagnosis.
Verification after a fix
A regression test for this HRESULT should reproduce “the RTC API contract rejects the action for the current object, role, or configuration” with the smallest profile, message, session, presence, media, or PINT fixture; for this HRESULT, assert 0x80EE0082, the responsible method/event, and the object state after the result; then, for this HRESULT, change only the decisive precondition and verify that the corrected run leaves no stale transaction or RTC object.
Technical references
- About the RTC Client API — authoritative context for the boundary.
- Microsoft RTC return constants — definitions relevant when reproducing it.
Looking for a different code? Search another status or error code.