| Previous | Next |
| RTC_E_SIP_TLS_FAIL | RTC_E_SIP_INVITEE_PARTY_TIMEOUT |
RTC_E_NOT_PRESENCE_PROFILE
Protocol boundary: RTC_E_NOT_PRESENCE_PROFILE
Read this result as an RTC state-machine result: at this point in enabling presence, maintaining buddies/watchers/groups, and processing server-roamed presence state, the selected profile is not provisioned for the presence operation.
Log this result as 0x80EE006A in the RTC interface facility 0xEE, not only as a signed decimal; the facility distinguishes local RTC validation from a response status mapped by the stack.
Before changing configuration, compare profile role/capabilities, enabled presence profile, server, and requested presence method; the RTC codes surrounding this result are not equivalent because a valid call profile can still be unsuitable for presence.
Protocol and object boundary
| RTC area | presence subscription and contact-list boundary |
|---|---|
| Objects to correlate | presence profile, buddy, watcher, group, ACL, SUBSCRIBE/NOTIFY state, presence document |
| Condition to prove | the selected profile is not provisioned for the presence operation |
| Safe corrective direction | select or create a presence-capable profile before enabling subscriptions or roaming |
At the boundary, Presence data is subscription state rather than call state; buddy existence, watcher authorization, and current availability are separate concepts; separately, this result must be read with the rule that When presence roaming is enabled, the server can act as the presence agent and becomes authoritative for list and subscription updates.
How to prove the condition
- Locate the earliest producer of this result 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 compare profile role/capabilities, enabled presence profile, server, and requested presence method.
- Test the competing explanation explicitly, because a valid call profile can still be unsuitable for presence.
- Perform the narrow correction — select or create a presence-capable profile before enabling subscriptions or roaming — and validate both protocol completion and object cleanup.
Use RTC event state to interpret the protocol trace, and use the trace to verify what left or reached the host; this two-sided correlation identifies the producing layer.
Nearby failure modes
It should not be grouped with every value from the same facility. It is tied to the condition “the selected profile is not provisioned for the presence operation”; preserve that producing boundary before choosing recovery; the result table shows nearby alternatives.
RTC_E_NOT_EXIST | the specific RTC object requested by the operation no longer exists |
|---|---|
RTC_E_NO_WATCHER | the requested watcher is absent from the current watcher collection |
RTC_E_TOO_MANY_GROUPS | the presence list has reached the group-count limit enforced by RTC or the server |
Keeping it separate from these neighbors improves both user messaging and automated retry policy.
Minimum incident record
The earliest callback or return site is the most valuable; later it cleanup can replace the original state, so correlate the code with the object generation that produced it.
- Code-specific proof: compare profile role/capabilities, enabled presence profile, server, and requested presence method.
- Owning object: buddy/watcher URI.
- Wire evidence: group ID and membership.
- Lifecycle generation: subscription dialog and expiration.
Sanitize the result evidence before storage: secrets and user content should disappear, while framing, domains, sizes, hashes, timing, and object-state changes remain available for reproduction.
Correct application response
The owning RTC component should select or create a presence-capable profile before enabling subscriptions or roaming; it should also settle or cancel its previous operation before callers begin a replacement.
A retry after it is safe only after the prior transaction’s outcome is reconciled; after it, reissuing state-changing requests while the peer result is unknown can create contradictory RTC state.
Example: An application uses a PSTN call profile when adding a buddy.
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.
- Keep it intact through exception and UI layers; a generic parameter or network message is insufficient for diagnosis.
Verification after a fix
Keep two tests: one that intentionally produces “the selected profile is not provisioned for the presence operation”, and one that applies the narrow correction; check the callback sequence, 0x80EE006A, final session/profile state, and absence of leaked listeners, dialogs, streams, or registrations.
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.