| Previous | Next |
| RTC_E_SIP_AUTH_TIME_SKEW | RTC_E_MEDIA_DISABLED |
RTC_E_INVALID_REGISTRATION_STATE
What the RTC value marks: RTC_E_INVALID_REGISTRATION_STATE
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 requested registration operation is illegal for the profile’s current registration state.
Log this result as 0x80EE006D 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.
Before changing configuration, record enabled profile, registration state, pending REGISTER, last response, and requested transition; the RTC codes surrounding this result are not equivalent because this is local state sequencing, not necessarily server rejection.
A safe diagnostic sequence
- At the source of this result, preserve the HRESULT, method or callback, timestamp, thread/task correlation, and object generation.
- Reconstruct the immediately preceding RTC transition instead of beginning with the later disconnect or UI notification.
- Use protocol and object evidence to record enabled profile, registration state, pending
REGISTER, last response, and requested transition. - Confirm the distinction that this is local state sequencing, not necessarily server rejection.
- Create a fresh operation generation after you wait for the current
REGISTERoperation or perform the documented enable/disable sequence, 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; an HRESULT-only log has the opposite weakness: it cannot show whether the result was generated before transmission or mapped from the peer.
Evidence that separates the cause
Do not wait for a generic failure notification to log it; preserve the API call or event producing it together with the RTC object and transaction state visible at that moment.
- Code-specific proof: record enabled profile, registration state, pending
REGISTER, last response, and requested transition. - Identity and target:
REGISTERCall-ID and CSeq. - State at production: Contact and requested expiration.
- Timing and ordering: final response and reason data.
When recording it, redact credentials, full telephone numbers, private contact lists, and message bodies; retain permitted URI domains, header names, byte counts, hashes, transaction identifiers, timestamps, and state transitions.
Protocol and object boundary
| RTC area | SIP registration state boundary |
|---|---|
| Objects to correlate | REGISTER client transaction, Contact binding, registrar, expiration, account and profile state |
| Condition to prove | the requested registration operation is illegal for the profile’s current registration state |
| Safe corrective direction | wait for the current REGISTER operation or perform the documented enable/disable sequence |
At the boundary, A registration result applies to a user binding and registrar, not automatically to existing dialogs or local media devices; separately, it must be read with the rule that Deactivation, rejection, and unregistration describe different server decisions and should produce different user messaging and retry policy.
Related RTC results
It is tied to the condition “the requested registration operation is illegal for the profile’s current registration state”; preserve that producing boundary before choosing recovery; the neighboring results below require different control-flow decisions.
RTC_E_REGISTRATION_UNREGISTERED | the server removed this registration because the same user registered elsewhere or another binding policy took precedence |
|---|---|
RTC_E_REGISTRATION_DEACTIVATED | the registrar deactivated the binding because the user is being moved or reprovisioned |
RTC_E_REGISTRATION_REJECTED | the registrar rejected registration because the account or SIP identity is no longer accepted |
Facility equality is not semantic equality; route each contrasted value through its own recovery branch.
How to handle the result
The corrective direction is to wait for the current REGISTER operation or perform the documented enable/disable sequence; for this HRESULT, cancellation, cleanup, and retry should remain with the component that owns the failed transition.
Before retrying it, classify the previous operation as definitely failed, definitely completed, or remotely uncertain; that distinction prevents duplicate dialogs, bindings, transfers, or roaming mutations.
Example: Code tries to unregister while initial registration is still pending.
Actions that do not address this condition
- The following shortcut is unsafe: 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.
- Keep it intact through exception and UI layers; a generic parameter or network message is insufficient for diagnosis.
Verification after a fix
A useful regression test does more than expect an exception; the test constructs “the requested registration operation is illegal for the profile’s current registration state”, 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 — 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.