| Previous | Next |
| RTC_E_SIP_TLS_FAIL | RTC_E_SIP_INVITEE_PARTY_TIMEOUT |
RTC_E_NOT_PRESENCE_PROFILE
What RTC_E_NOT_PRESENCE_PROFILE means in RTC
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 state
| RTC area | presence subscription and contact-list |
|---|---|
| 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 |
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.
How to prove the condition
- 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.
- Apply the targeted fix — select or create a presence-capable profile before enabling subscriptions or roaming — and validate both protocol completion and object cleanup.
Nearby failure modes
Use “the selected profile is not provisioned for the presence operation” as the discriminator when comparing the related RTC results below.
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 |
Minimum incident record
- 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 state: subscription dialog and expiration.
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 is safe only after the prior transaction’s outcome is reconciled; 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.
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 targeted fix; 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 this result.
- 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 this result.
Looking for a different code? Search another status or error code.