| Previous | Next |
| RTC_E_NO_BUDDY | RTC_E_NO_REALM |
RTC_E_NO_WATCHER
Operational meaning: RTC_E_NO_WATCHER
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 the requested watcher is absent from the current watcher collection.
This result is represented as 0x80EE0055 in the RTC interface facility 0xEE; record the symbolic name alongside the unsigned hexadecimal value; a decimal exception alone is poor evidence for RTC protocol diagnosis.
To establish this result, refresh watcher information and compare URI, subscription dialog, and ACL record; this matters because no watcher does not imply no ACL rule; authorization can remain for a future subscription.
Signals worth preserving
The evidence set should begin at the first failing or completing RTC operation; reconnect and teardown events are secondary unless they caused the original result.
- Code-specific proof: refresh watcher information and compare URI, subscription dialog, and ACL record.
- Correlation key: group ID and membership.
- Protocol or object snapshot: subscription dialog and expiration.
- Last completed transition: ACL decision and
NOTIFYversion. - Expected output: presence profile and account.
Protocol and object state
| RTC area | presence subscription and contact-list |
|---|---|
| Condition to prove | the requested watcher is absent from the current watcher collection |
| Objects to correlate | presence profile, buddy, watcher, group, ACL, SUBSCRIBE/NOTIFY state, presence document |
| Safe corrective direction | treat removal as idempotent or wait for a new watcher event before changing watcher-specific 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.
Verification workflow
- Collect enough evidence to refresh watcher information and compare URI, subscription dialog, and ACL record.
- Test the competing explanation explicitly, because no watcher does not imply no ACL rule; authorization can remain for a future subscription.
- Apply the targeted fix — treat removal as idempotent or wait for a new watcher event before changing watcher-specific state — and validate both protocol completion and object cleanup.
Do not confuse it with
RTC_E_TOO_MANY_GROUPS | the presence list has reached the group-count limit enforced by RTC or the server |
|---|---|
RTC_E_DUPLICATE_WATCHER | the watcher is already present in the watcher/authorization collection |
RTC_E_PRESENCE_NOT_ENABLED | a presence operation was requested before presence was enabled for an appropriate profile |
Recovery and control flow
The appropriate response to it is not a blanket reconnect. Instead, treat removal as idempotent or wait for a new watcher event before changing watcher-specific state, while preserving ownership of cleanup and any bounded retry.
Example: A revoke command arrives after the watcher subscription already ended.
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.
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.