| Previous | Next |
| RTC_E_CLIENT_ALREADY_SHUT_DOWN | RTC_E_INVALID_SESSION_TYPE |
RTC_E_PRESENCE_NOT_ENABLED
Operational meaning: RTC_E_PRESENCE_NOT_ENABLED
This result should be investigated at the point where RTC handles enabling presence, maintaining buddies/watchers/groups, and processing server-roamed presence state, and the condition to prove for this HRESULT is a presence operation was requested before presence was enabled for an appropriate profile.
This result is represented as 0x80EE0028 in the RTC interface facility 0xEE; for this HRESULT, record the symbolic name alongside the unsigned hexadecimal value; a decimal exception alone is poor evidence for RTC protocol diagnosis.
To establish this result, record enabled profiles, presence profile selection, registration state, and event ordering; for this HRESULT, this matters because profile enabled for calls does not necessarily mean presence is active.
Signals worth preserving
Capture the first result before retry, reconnect, profile re-enable, or teardown changes the evidence; associate this result with one RTC object generation and one transaction or media transition.
- Code-specific proof for this HRESULT: record enabled profiles, presence profile selection, registration state, and event ordering.
- Correlation key for this HRESULT: buddy/watcher URI.
- Protocol or object snapshot for this HRESULT: group ID and membership.
- Last completed transition for this HRESULT: subscription dialog and expiration.
- Expected output for this HRESULT: ACL decision and
NOTIFYversion.
A useful it trace does not require communication content or secrets; in the result record, keep structural metadata and correlation identifiers while removing passwords, authorization material, complete numbers, and private presence data.
Protocol and object boundary
| RTC area | presence subscription and contact-list boundary |
|---|---|
| Condition to prove | a presence operation was requested before presence was enabled for an appropriate profile |
| Objects to correlate | presence profile, buddy, watcher, group, ACL, SUBSCRIBE/NOTIFY state, presence document |
| Safe corrective direction | enable presence through the documented provisioning flow before manipulating subscriptions or lists |
The API and protocol context for this HRESULT is not optional: Presence data is subscription state rather than call state; buddy existence, watcher authorization, and current availability are separate concepts; the related it control-flow rule is that When presence roaming is enabled, the server can act as the presence agent and becomes authoritative for list and subscription updates.
Verification workflow
- Locate the earliest it producer and verify that no wrapper replaced a more specific lower-layer value.
- map that producer to the active RTC object and to one SIP, SDP, PINT, presence, media, or profile transition.
- collect enough evidence to record enabled profiles, presence profile selection, registration state, and event ordering.
- test the competing explanation explicitly, because profile enabled for calls does not necessarily mean presence is active.
- perform the narrow correction — enable presence through the documented provisioning flow before manipulating subscriptions or lists — and validate both protocol completion and object cleanup.
Correlate wire data and RTC events for this HRESULT; for this HRESULT, either source alone can misclassify local validation as remote rejection, or a remote status as a local media or profile failure.
Do not confuse it with
The practical separator for this HRESULT is this: it is tied to the condition “a presence operation was requested before presence was enabled for an appropriate profile”; preserve that producing boundary before choosing recovery; for this HRESULT, compare that boundary with these related RTC values.
RTC_E_NO_BUDDY | the requested buddy object is absent from current presence state |
|---|---|
RTC_E_INVALID_ACL_LIST | the presence access-control list is structurally or semantically invalid |
RTC_E_PRESENCE_ENABLED | code attempted an enable-only presence transition when presence is already active |
Telemetry for this HRESULT should retain these distinctions even when several outcomes share HRESULT severity.
Recovery and control flow
Recovery from it should be narrow: enable presence through the documented provisioning flow before manipulating subscriptions or lists; while handling it, 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; for this HRESULT, use transaction identifiers and final events before replaying any non-idempotent action.
Example for this HRESULT: An application adds a buddy immediately after sign-in but before the presence-enabled event.
Actions that do not address this condition
- An investigation should not 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 result facility and state boundary when converting the result into application telemetry.
Verification after a fix
A regression test for this HRESULT should reproduce “a presence operation was requested before presence was enabled for an appropriate profile” with the smallest profile, message, session, presence, media, or PINT fixture; for this HRESULT, assert 0x80EE0028, the responsible method/event, and the object state after the result; then, for this HRESULT, change only the decisive precondition and verify that the corrected run leaves no stale transaction or RTC object.
Technical references
- Client Presence Roaming — authoritative context for the boundary.
- Microsoft RTC return constants — definitions relevant when reproducing it.
- SIP presence event package — API or protocol rules used to interpret it.
- Watcher information — authoritative context for the boundary.
Looking for a different code? Search another status or error code.