| 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
- Code-specific proof: record exact method, object type/state, selected profile, role, and any more specific earlier event.
- Correlation key: client instance identity.
- Protocol or object snapshot: Initialize and Shutdown call order.
- Last completed transition: thread/apartment and event sink.
- Expected output: outstanding session/profile count.
Protocol and object state
| RTC area | RTC client lifecycle |
|---|---|
| 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 |
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.
Verification workflow
- Start from
0x80EE0082, then find the method/event pair that first exposed it. - To verify this, 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.
Do not confuse it with
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 |
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.
Example: 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
- 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.