| Previous | Next |
| RTC_E_NOT_ALLOWED | RTC_E_REGISTRATION_REJECTED |
RTC_E_REGISTRATION_DEACTIVATED
Where the state changes: RTC_E_REGISTRATION_DEACTIVATED
The useful interpretation of this result is narrower than “SIP error”; within enabling a profile, registering the user URI, refreshing bindings, and interpreting server-driven account changes, it means the registrar deactivated the binding because the user is being moved or reprovisioned.
The stored value is 0x80EE0083 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 capture final REGISTER-related event, new server/profile hints, binding expiration, and migration context; do not skip the distinction that deactivation can be an administrative move rather than account rejection.
Telemetry and packet evidence
Before automatic recovery runs, record one client, profile, or session instance and the exact signaling, presence, or media transition in progress.
- Code-specific proof: capture final
REGISTER-related event, new server/profile hints, binding expiration, and migration context. - Addressing context: final response and reason data.
- RTC callback state: profile enabled/disabled transition.
- Transaction boundary: user URI and registrar.
- Media or profile detail:
REGISTERCall-ID and CSeq.
Protocol and object state
| RTC area | SIP registration state |
|---|---|
| Condition to prove | the registrar deactivated the binding because the user is being moved or reprovisioned |
| Objects to correlate | REGISTER client transaction, Contact binding, registrar, expiration, account and profile state |
| Safe corrective direction | stop refreshing the old binding and obtain current provisioning before registering again |
Interpreting this result requires both of these facts: A registration result applies to a user binding and registrar, not automatically to existing dialogs or local media devices; also, the result branch assumes that Deactivation, rejection, and unregistration describe different server decisions and should produce different user messaging and retry policy.
Actions that do not address this condition
- Do not loop on REGISTER when the server indicates an account or identity change.
- Do not discard the old binding state before recording why it ended.
Step-by-step isolation
- Test the competing explanation explicitly, because deactivation can be an administrative move rather than account rejection.
- Apply the targeted fix — stop refreshing the old binding and obtain current provisioning before registering again — and validate both protocol completion and object cleanup.
Recovery
The appropriate response to it is not a blanket reconnect. Instead, stop refreshing the old binding and obtain current provisioning before registering again, while preserving ownership of cleanup and any bounded retry.
Example: A user account is migrated to another registrar and the old server deactivates registration.
Comparison with adjacent codes
RTC_E_INVALID_REGISTRATION_STATE | the requested registration operation is illegal for the profile’s current registration state |
|---|---|
RTC_E_REGISTRATION_REJECTED | the registrar rejected registration because the account or SIP identity is no longer accepted |
RTC_E_REGISTRATION_UNREGISTERED | the server removed this registration because the same user registered elsewhere or another binding policy took precedence |
Technical references
Looking for a different code? Search another status or error code.