| Previous | Next |
| RTC_E_ROAMING_OPERATION_INTERRUPTED | RTC_E_INVALID_BUDDY_LIST |
RTC_E_ROAMING_FAILED
What the RTC value marks: RTC_E_ROAMING_FAILED
This result should be investigated at the point where RTC handles synchronizing profile, buddy, watcher, group, or ACL data with the server while preserving update ordering, and the condition to prove for this HRESULT is the server-side roaming transaction completed as a failure.
This result is represented as 0x80EE004E in the RTC interface facility 0xEE; record the symbolic name alongside the unsigned hexadecimal value; a decimal exception alone is poor evidence for RTC protocol diagnosis.
A defensible diagnosis of this result requires you to capture roaming type, server response, version/precondition data, and affected list object; in the case, this is a known failure outcome, unlike the uncertain result of an interruption.
Protocol and object state
| RTC area | RTC roaming synchronization |
|---|---|
| Objects to correlate | roaming event, server version, local cache, operation instance, list document and completion state |
| Condition to prove | the server-side roaming transaction completed as a failure |
| Safe corrective direction | correct the rejected data or state conflict, refresh, and issue a new operation |
An interrupted roaming operation has an uncertain outcome: the server may have committed data even when the client did not receive completion. A failed synchronization must be reconciled with fresh server state before replaying list mutations.
Evidence that separates the cause
Capture the first result before retry, reconnect, profile re-enable, or teardown changes the evidence; associate it with one RTC object instance and one transaction or media transition.
- Code-specific proof: capture roaming type, server response, version/precondition data, and affected list object.
- Identity and target: last acknowledged mutation.
- State at production: fresh enumeration after failure.
- Timing and ordering: roaming data type.
A safe diagnostic sequence
- Use protocol and object evidence to capture roaming type, server response, version/precondition data, and affected list object.
- Confirm the distinction that this is a known failure outcome, unlike the uncertain result of an interruption.
- Start a fresh operation after you correct the rejected data or state conflict, refresh, and issue a new operation, and compare its final state with the failing run.
How to handle the result
The owning RTC component should correct the rejected data or state conflict, refresh, and issue a new operation; it should also settle or cancel its previous operation before callers begin a replacement.
A retry is safe only after the prior transaction’s outcome is reconciled; reissuing state-changing requests while the peer result is unknown can create contradictory RTC state.
Example: A buddy-list update is rejected because it references a group that no longer exists.
Actions that do not address this condition
- With it, do not delete the local cache before preserving versions and pending operations.
- Do not blindly replay non-idempotent list changes after a disconnect.
Related RTC results
Use “the server-side roaming transaction completed as a failure” as the discriminator when comparing the related RTC results below.
RTC_E_ROAMING_OPERATION_INTERRUPTED | a roaming operation ended without a trustworthy commit outcome |
|---|---|
RTC_E_ROAMING_ENABLED | roaming is already enabled for the selected profile or data type |
RTC_E_MALFORMED_XML | RTC received or generated XML that cannot be parsed for the roaming or presence operation |
Verification after a fix
Verify the fix with a minimal deterministic case that reaches “the server-side roaming transaction completed as a failure”; the failing case must assert the HRESULT and post-failure state; the passing case should alter one input and confirm both protocol outcome and cleanup.
Technical references
- Client Presence Roaming — API or protocol rules used to interpret it.
- Microsoft RTC return constants — authoritative context for this result.
- SIP presence event package — definitions relevant when reproducing it.
Looking for a different code? Search another status or error code.