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

• 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.

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.

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

Comparison with adjacent codes

Technical references

• Client Presence Roaming.
• Microsoft RTC return constants.
• SIP presence event package.
• Watcher information.