| Previous | Next |
| RTC_E_REGISTRATION_REJECTED | RTC_E_STATUS_REDIRECT_MULTIPLE_CHOICES |
RTC_E_REGISTRATION_UNREGISTERED
Operational meaning: RTC_E_REGISTRATION_UNREGISTERED
Read this result as an RTC state-machine result: at this point in enabling a profile, registering the user URI, refreshing bindings, and interpreting server-driven account changes, the server removed this registration because the same user registered elsewhere or another binding policy took precedence.
Log this result as 0x80EE0085 in the RTC interface facility 0xEE, not only as a signed decimal; the facility distinguishes local RTC validation from a response status mapped by the stack.
The first useful check is to capture contact binding, endpoint identity, registrar event, and multi-point sign-in policy. The result must be separated from nearby conditions because server-driven unregistration differs from account deletion and may be normal under single-endpoint policy.
Signals worth preserving
- Code-specific proof: capture contact binding, endpoint identity, registrar event, and multi-point sign-in policy.
- Correlation key: Contact and requested expiration.
- Protocol or object snapshot: final response and reason data.
- Last completed transition: profile enabled/disabled transition.
- Expected output: user URI and registrar.
Recovery and control flow
The appropriate response to it is not a blanket reconnect. Instead, inform the user, stop refresh for the old binding, and sign in again only deliberately, while preserving ownership of cleanup and any bounded retry.
Example: A second device signs in and the registrar logs out the first under single-point presence policy.
Protocol and object state
| RTC area | SIP registration state |
|---|---|
| Condition to prove | the server removed this registration because the same user registered elsewhere or another binding policy took precedence |
| Objects to correlate | REGISTER client transaction, Contact binding, registrar, expiration, account and profile state |
| Safe corrective direction | inform the user, stop refresh for the old binding, and sign in again only deliberately |
A registration result applies to a user binding and registrar, not automatically to existing dialogs or local media devices. Deactivation, rejection, and unregistration describe different server decisions and should produce different user messaging and retry policy.
Verification workflow
- Confirm the distinction that server-driven unregistration differs from account deletion and may be normal under single-endpoint policy.
- Start a fresh operation after you inform the user, stop refresh for the old binding, and sign in again only deliberately, and compare its final state with the failing run.
Actions that do not address this condition
- Do not discard the old binding state before recording why it ended.
- Do not loop on REGISTER when the server indicates an account or identity change.
Do not confuse it with
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_DEACTIVATED | the registrar deactivated the binding because the user is being moved or reprovisioned |
Technical references
Looking for a different code? Search another status or error code.