| 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; for this HRESULT, the facility distinguishes local RTC validation from a response status mapped by the stack.
The first useful check for this HRESULT 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
The earliest callback or return site is the most valuable; later this result cleanup can replace the original state, so correlate the code with the object generation that produced it.
- Code-specific proof for this HRESULT: capture contact binding, endpoint identity, registrar event, and multi-point sign-in policy.
- Correlation key for this HRESULT: Contact and requested expiration.
- Protocol or object snapshot for this HRESULT: final response and reason data.
- Last completed transition for this HRESULT: profile enabled/disabled transition.
- Expected output for this HRESULT: user URI and registrar.
When recording this result, redact credentials, full telephone numbers, private contact lists, and message bodies; for this HRESULT, retain permitted URI domains, header names, byte counts, hashes, transaction identifiers, timestamps, and state transitions.
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.
Before retrying it, classify the previous operation as definitely failed, definitely completed, or remotely uncertain; for this HRESULT, that distinction prevents duplicate dialogs, bindings, transfers, or roaming mutations.
Example for this HRESULT: A second device signs in and the registrar logs out the first under single-point presence policy.
Protocol and object boundary
| RTC area | SIP registration state boundary |
|---|---|
| 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; the second rule relevant to it is that Deactivation, rejection, and unregistration describe different server decisions and should produce different user messaging and retry policy.
Verification workflow
- At the source of it, preserve the HRESULT, method or callback, timestamp, thread/task correlation, and object generation.
- use protocol and object evidence to capture contact binding, endpoint identity, registrar event, and multi-point sign-in policy.
- reconstruct the immediately preceding RTC transition instead of beginning with the later disconnect or UI notification.
- confirm the distinction that server-driven unregistration differs from account deletion and may be normal under single-endpoint policy.
- create a fresh operation generation 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.
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.
Actions that do not address this condition
- With it, do not discard the old binding state before recording why it ended.
- Another non-solution for this HRESULT is to do not loop on REGISTER when the server indicates an account or identity change.
- A wrapper handling it should retain the original HRESULT instead of replacing it with an undifferentiated call failure.
Do not confuse it with
The practical separator for this HRESULT is this: it is tied to the condition “the server removed this registration because the same user registered elsewhere or another binding policy took precedence”; preserve that producing boundary before choosing recovery; for this HRESULT, compare that boundary with these related RTC values.
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 |
Facility equality is not semantic equality; route each contrasted value through its own recovery branch.
Verification after a fix
A useful it regression does more than expect an exception; the result test constructs “the server removed this registration because the same user registered elsewhere or another binding policy took precedence”, checks the exact HRESULT at the producing RTC boundary, and verifies state ownership before and after the targeted correction.
Technical references
- Microsoft RTC return constants — API or protocol rules used to interpret it.
- IRTCClientProvisioning::CreateProfile — authoritative context for the boundary.
- SIP registration rules — definitions relevant when reproducing it.
Looking for a different code? Search another status or error code.