| 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; for this HRESULT, 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; for this HRESULT, do not skip the distinction that deactivation can be an administrative move rather than account rejection.
Telemetry and packet evidence
Build the incident record before automatic recovery runs; the result record must identify one client/profile/session generation and the exact signaling, presence, or media transition in progress.
- Code-specific proof for this HRESULT: capture final
REGISTER-related event, new server/profile hints, binding expiration, and migration context. - Addressing context for this HRESULT: final response and reason data.
- RTC callback state for this HRESULT: profile enabled/disabled transition.
- Transaction boundary for this HRESULT: user URI and registrar.
- Media or profile detail for this HRESULT:
REGISTERCall-ID and CSeq.
A useful this result trace does not require communication content or secrets; in the result record, keep structural metadata and correlation identifiers while removing passwords, authorization material, complete numbers, and private presence data.
Protocol and object boundary
| RTC area | SIP registration state boundary |
|---|---|
| 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
- The following shortcut is unsafe for this HRESULT: do not loop on REGISTER when the server indicates an account or identity change.
- Another non-solution for this HRESULT is to do not discard the old binding state before recording why it ended.
- Do not translate this result into a broad “connection failed” label before preserving the RTC symbol and producing phase.
Step-by-step isolation
- Locate the earliest it producer and verify that no wrapper replaced a more specific lower-layer value.
- map that producer to the active RTC object and to one SIP, SDP, PINT, presence, media, or profile transition.
- collect enough evidence to capture final
REGISTER-related event, new server/profile hints, binding expiration, and migration context. - test the competing explanation explicitly, because deactivation can be an administrative move rather than account rejection.
- perform the narrow correction — stop refreshing the old binding and obtain current provisioning before registering again — and validate both protocol completion and object cleanup.
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.
Remediation boundary
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.
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 user account is migrated to another registrar and the old server deactivates registration.
Comparison with adjacent codes
It is tied to the condition “the registrar deactivated the binding because the user is being moved or reprovisioned”; preserve that producing boundary before choosing recovery; for this HRESULT, the neighboring results below require different control-flow decisions.
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 |
Keeping it separate from these neighbors improves both user messaging and automated retry policy.
Verification after a fix
A regression test for this HRESULT should reproduce “the registrar deactivated the binding because the user is being moved or reprovisioned” with the smallest profile, message, session, presence, media, or PINT fixture; for this HRESULT, assert 0x80EE0083, 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
- Microsoft RTC return constants — definitions relevant when reproducing it.
- IRTCClientProvisioning::CreateProfile — API or protocol rules used to interpret it.
- SIP registration rules — authoritative context for the boundary.
Looking for a different code? Search another status or error code.