| Previous | Next |
| RTC_E_DUPLICATE_BUDDY | RTC_E_MALFORMED_XML |
RTC_E_DUPLICATE_WATCHER
Operational meaning: RTC_E_DUPLICATE_WATCHER
This HRESULT is emitted for a defined RTC state rather than an unspecified communications problem; that state is the watcher is already present in the watcher/authorization collection.
This result is represented as 0x80EE004B 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, compare watcher URI, subscription dialog, ACL state, and pending events; this matters because watchers are subscribers observing presence, not buddies being observed by the user.
Verification workflow
- Start from
0x80EE004Band this result, then find the method/event pair that first exposed it. - Check whether the failure was local before transmission, produced during RTC state validation, or mapped from a remote response.
- the proof step is to compare watcher URI, subscription dialog, ACL state, and pending events.
- Keep the analysis at the right boundary: watchers are subscribers observing presence, not buddies being observed by the user.
- After you update authorization on the existing watcher rather than creating another record, repeat the smallest reproducer rather than restarting the entire application environment.
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.
Protocol and object boundary
| RTC area | presence subscription and contact-list boundary |
|---|---|
| Condition to prove | the watcher is already present in the watcher/authorization collection |
| Objects to correlate | presence profile, buddy, watcher, group, ACL, SUBSCRIBE/NOTIFY state, presence document |
| Safe corrective direction | update authorization on the existing watcher rather than creating another record |
The surrounding protocol rule is that Presence data is subscription state rather than call state; buddy existence, watcher authorization, and current availability are separate concepts; in addition, the path requires that When presence roaming is enabled, the server can act as the presence agent and becomes authoritative for list and subscription updates.
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: compare watcher URI, subscription dialog, ACL state, and pending events.
- Correlation key: ACL decision and
NOTIFYversion. - Protocol or object snapshot: presence profile and account.
- Last completed transition: buddy/watcher URI.
- Expected output: group ID and membership.
A useful trace does not require communication content or secrets; in the diagnostic record, keep structural metadata and correlation identifiers while removing passwords, authorization material, complete numbers, and private presence data.
Recovery and control flow
Resolve it at its producing layer: update authorization on the existing watcher rather than creating another record; after it, a separate UI or watchdog retry must wait until that layer reports a final state.
Distinguish local rejection from an operation that may already have reached the server; use transaction identifiers and final events before replaying any non-idempotent action.
Example: Two NOTIFY-related callbacks attempt to insert the same watcher.
Actions that do not address this condition
- The following shortcut is unsafe: do not expose a private buddy list or watcher identity in general logs.
- Also 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.
Do not confuse it with
Use the following contrast when classifying it: it is tied to the condition “the watcher is already present in the watcher/authorization collection”; preserve that producing boundary before choosing recovery; similar subsystem names do not imply identical recovery.
RTC_E_PRESENCE_ENABLED | code attempted an enable-only presence transition when presence is already active |
|---|---|
RTC_E_DUPLICATE_BUDDY | the buddy URI is already represented in the active presence list |
RTC_E_INVALID_ACL_LIST | the presence access-control list is structurally or semantically invalid |
Keeping it separate from these neighbors improves both user messaging and automated retry policy.
Verification after a fix
Keep two tests: one that intentionally produces “the watcher is already present in the watcher/authorization collection”, and one that applies the narrow correction; check the callback sequence, 0x80EE004B, final session/profile state, and absence of leaked listeners, dialogs, streams, or registrations.
Technical references
- Client Presence Roaming — definitions relevant when reproducing it.
- Microsoft RTC return constants — API or protocol rules used to interpret it.
- SIP presence event package — authoritative context for the boundary.
- Watcher information — definitions relevant when reproducing it.
Looking for a different code? Search another status or error code.