| 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; 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 boundary is that rejection indicates identity/account change and should not be handled as a short transport outage.
Protocol and object state
| RTC area | SIP registration state |
|---|---|
| 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 |
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.
Evidence that separates the cause
- Code-specific proof: record user URI, registrar, final response/reason, provisioning version, and account state.
- Identity and target: Contact and requested expiration.
- State at production: final response and reason data.
- Timing and ordering: profile enabled/disabled transition.
Related RTC results
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 |
A safe diagnostic sequence
- 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.
- Apply the targeted fix — stop retrying, refresh account provisioning, and require user/admin correction — and validate both protocol completion and object cleanup.
How to handle the result
The owning RTC component should stop retrying, refresh account provisioning, and require user/admin correction; it should also settle or cancel its previous operation before callers begin a replacement.
Example: An account is disabled and the client’s REGISTER is rejected on every refresh.
Actions that do not address this condition
- 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.
Technical references
Looking for a different code? Search another status or error code.