| Previous | Next |
| RTC_E_REGISTRATION_DEACTIVATED | RTC_E_REGISTRATION_UNREGISTERED |
RTC_E_REGISTRATION_REJECTED
What the RTC value marks: RTC_E_REGISTRATION_REJECTED
The legacy RTC Client API reports this result while working with enabling a profile, registering the user URI, refreshing bindings, and interpreting server-driven account changes; the precise meaning of it is the registrar rejected registration because the account or SIP identity is no longer accepted, not merely that a call or registration failed.
For correlation, retain 0x80EE0084 in the RTC interface facility 0xEE together with this result; for this HRESULT, generic HRESULT text can otherwise hide the protocol family and the exact RTC branch.
The quickest way to localize this result is to record user URI, registrar, final response/reason, provisioning version, and account state; the important the boundary is that rejection indicates identity/account change and should not be handled as a short transport outage.
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 registrar rejected registration because the account or SIP identity is no longer accepted |
| Safe corrective direction | stop retrying, refresh account provisioning, and require user/admin correction |
The surrounding protocol rule for this HRESULT is that A registration result applies to a user binding and registrar, not automatically to existing dialogs or local media devices; in addition, the path requires that Deactivation, rejection, and unregistration describe different server decisions and should produce different user messaging and retry policy.
Evidence that separates the cause
Do not wait for a generic failure notification to log this result; preserve the API call or event producing it together with the RTC object and transaction state visible at that moment.
- Code-specific proof for this HRESULT: record user URI, registrar, final response/reason, provisioning version, and account state.
- Identity and target for this HRESULT: Contact and requested expiration.
- State at production for this HRESULT: final response and reason data.
- Timing and ordering for this HRESULT: profile enabled/disabled transition.
Sanitize the result evidence before storage: secrets and user content should disappear, while framing, domains, sizes, hashes, timing, and object-state changes remain available for reproduction.
Related RTC results
Use the following contrast when classifying it: it is tied to the condition “the registrar rejected registration because the account or SIP identity is no longer accepted”; preserve that producing boundary before choosing recovery; for this HRESULT, similar subsystem names do not imply identical recovery.
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_INVALID_REGISTRATION_STATE | the requested registration operation is illegal for the profile’s current registration state |
Keeping it separate from these neighbors improves both user messaging and automated retry policy.
A safe diagnostic sequence
- 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 record user URI, registrar, final response/reason, provisioning version, and account state.
- test the competing explanation explicitly, because rejection indicates identity/account change and should not be handled as a short transport outage.
- perform the narrow correction — stop retrying, refresh account provisioning, and require user/admin correction — 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.
How to handle the result
The owning RTC component should stop retrying, refresh account provisioning, and require user/admin correction; for this HRESULT, it should also settle or cancel its previous operation before callers begin a replacement.
Distinguish local rejection from an operation that may already have reached the server; for this HRESULT, use transaction identifiers and final events before replaying any non-idempotent action.
Example for this HRESULT: An account is disabled and the client’s REGISTER is rejected on every refresh.
Actions that do not address this condition
- An investigation should not do not loop on REGISTER when the server indicates an account or identity change.
- also do not discard the old binding state before recording why it ended.
- Do not discard the result facility and state boundary when converting the result into application telemetry.
Verification after a fix
A regression test for this HRESULT should reproduce “the registrar rejected registration because the account or SIP identity is no longer accepted” with the smallest profile, message, session, presence, media, or PINT fixture; for this HRESULT, assert 0x80EE0084, 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 — authoritative context for the boundary.
- IRTCClientProvisioning::CreateProfile — definitions relevant when reproducing it.
- SIP registration rules — API or protocol rules used to interpret it.
Looking for a different code? Search another status or error code.