What does HRESULT 0x80EE0062 (RTC_E_PRESENCE_ENABLED) mean?

RTC_E_PRESENCE_ENABLED

Where the state changes: RTC_E_PRESENCE_ENABLED

The useful interpretation of this result is narrower than “SIP error”; within enabling presence, maintaining buddies/watchers/groups, and processing server-roamed presence state, it means code attempted an enable-only presence transition when presence is already active.

The stored value is 0x80EE0062 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 record enabled profile, presence generation, subscriptions, and duplicate caller; the result evidence should demonstrate why already enabled is a lifecycle/idempotency result, not confirmation that every buddy subscription is healthy.

Telemetry and packet evidence

Capture the first result before retry, reconnect, profile re-enable, or teardown changes the evidence; associate this result with one RTC object instance and one transaction or media transition.

• Code-specific proof: record enabled profile, presence generation, subscriptions, and duplicate caller.
• Addressing context: subscription dialog and expiration.
• RTC callback state: ACL decision and NOTIFY version.
• Transaction boundary: presence profile and account.
• Media or profile detail: buddy/watcher URI.

Protocol and object state

Presence data is subscription state rather than call state; buddy existence, watcher authorization, and current availability are separate concepts. When presence roaming is enabled, the server can act as the presence agent and becomes authoritative for list and subscription updates.

Actions that do not address this condition

• Do not expose a private buddy list or watcher identity in general logs.
• Do not overwrite the server list with a stale local snapshot after an uncertain roaming result.
• Do not discard the HRESULT facility or state information when converting the result into application telemetry.

Step-by-step isolation

1. Use protocol and object evidence to record enabled profile, presence generation, subscriptions, and duplicate caller.
2. Confirm the distinction that already enabled is a lifecycle/idempotency result, not confirmation that every buddy subscription is healthy.
3. Start a fresh operation after you reuse the active presence context and repair individual subscriptions separately, and compare its final state with the failing run.

Recovery

Recovery should be narrow: reuse the active presence context and repair individual subscriptions separately; while handling this result, do not let a higher layer simultaneously recreate the same session, registration, listener, or profile.

Distinguish local rejection from an operation that may already have reached the server; use transaction identifiers and final events before replaying any non-idempotent action.

Example: Two sign-in completion handlers both call EnablePresence.

Comparison with adjacent codes

Use “code attempted an enable-only presence transition when presence is already active” as the discriminator when comparing the related RTC results below.

Verification after a fix

Verify the fix with a minimal deterministic case that reaches “code attempted an enable-only presence transition when presence is already active”; 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.
• Microsoft RTC return constants.
• SIP presence event package.
• Watcher information.

Looking for a different code? Search another status or error code.