| Previous | Next |
| RTC_E_PRESENCE_ENABLED | RTC_E_SIP_TLS_INCOMPATIBLE_ENCRYPTION |
RTC_E_ROAMING_ENABLED
What RTC_E_ROAMING_ENABLED means in RTC
When RTC returns this result, the relevant contract is synchronizing profile, buddy, watcher, group, or ACL data with the server while preserving update ordering, and it says that roaming is already enabled for the selected profile or data type.
The stored value is 0x80EE0063 in the RTC interface facility 0xEE; 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.
Collect enough state to identify profile, roaming flags, current event state, and second enable request owner; the result evidence should demonstrate why active roaming does not imply the current synchronization has finished successfully.
Minimum incident record
The evidence set should begin at the first failing or completing RTC operation; reconnect and teardown events are secondary unless they caused the original result.
- Code-specific proof: identify profile, roaming flags, current event state, and second enable request owner.
- Owning object: fresh enumeration after failure.
- Wire evidence: roaming data type.
- Lifecycle state: operation and event ID.
When recording this result, 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 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 | roaming is already enabled for the selected profile or data type |
| Safe corrective direction | reuse the enabled channel and wait for or inspect its roaming events |
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.
Correct application response
The appropriate response to this result is not a blanket reconnect. Instead, reuse the enabled channel and wait for or inspect its roaming events, while preserving ownership of cleanup and any bounded retry.
Do not turn this result into an immediate unconditional retry; first determine whether the peer could have accepted the prior request and whether RTC still owns a live transaction.
Example: A profile-refresh path repeats EnableProfileEx while the original roaming session remains active.
How to prove the condition
- Start from
0x80EE0063, then find the method/event pair that first exposed it. - the proof step is to identify profile, roaming flags, current event state, and second enable request owner.
- Check whether the failure was local before transmission, produced during RTC state validation, or mapped from a remote response.
- Keep the analysis at the right boundary: active roaming does not imply the current synchronization has finished successfully.
- After you reuse the enabled channel and wait for or inspect its roaming events, repeat the smallest reproducer rather than restarting the entire application environment.
Nearby failure modes
Use “roaming is already enabled for the selected profile or data type” 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_MALFORMED_XML | RTC received or generated XML that cannot be parsed for the roaming or presence operation |
RTC_E_ROAMING_FAILED | the server-side roaming transaction completed as a failure |
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.
Verification after a fix
A regression test should reproduce “roaming is already enabled for the selected profile or data type” with the smallest profile, message, session, presence, media, or PINT fixture; assert 0x80EE0063, the responsible method/event, and the object state after the result; then change only the decisive precondition and verify that the corrected run leaves no stale transaction or RTC object.
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.