| Previous | Next |
| RTC_E_SECURITY_LEVEL_NOT_SUPPORTED_BY_PARTICIPANT | RTC_E_DUPLICATE_WATCHER |
RTC_E_DUPLICATE_BUDDY
Protocol boundary: RTC_E_DUPLICATE_BUDDY
The legacy RTC Client API reports this result while working with enabling presence, maintaining buddies/watchers/groups, and processing server-roamed presence state; the precise meaning of it is the buddy URI is already represented in the active presence list, not merely that a call or registration failed.
The numeric form of this result is 0x80EE004A in the RTC interface facility 0xEE; an exception translator handling it should preserve this value before converting it into application-facing call or presence states.
Evidence should show that you normalize the URI and compare server/local IDs, groups, and pending add operations; the diagnostic distinction is that duplicate buddy does not mean duplicate display name; identity is based on the RTC contact object/URI.
Minimum incident record
The earliest callback or return site is the most valuable; later cleanup can replace the original state, so correlate the code with the object generation that produced it.
- Code-specific proof: normalize the URI and compare server/local IDs, groups, and pending add operations.
- Owning object: presence profile and account.
- Wire evidence: buddy/watcher URI.
- Lifecycle generation: group ID and membership.
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.
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 buddy URI is already represented in the active presence list |
| Safe corrective direction | reuse or update the existing buddy and make add operations idempotent |
Two RTC rules frame this result: first, Presence data is subscription state rather than call state; buddy existence, watcher authorization, and current availability are separate concepts; second, for this HRESULT, When presence roaming is enabled, the server can act as the presence agent and becomes authoritative for list and subscription updates.
Correct application response
The owning RTC component should reuse or update the existing buddy and make add operations idempotent; 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: A roaming replay tries to add a contact already committed by the server.
How to prove the condition
- At the source of it, preserve the HRESULT, method or callback, timestamp, thread/task correlation, and object generation.
- Use protocol and object evidence to normalize the URI and compare server/local IDs, groups, and pending add operations.
- Reconstruct the immediately preceding RTC transition instead of beginning with the later disconnect or UI notification.
- Confirm the distinction that duplicate buddy does not mean duplicate display name; identity is based on the RTC contact object/URI.
- Create a fresh operation generation after you reuse or update the existing buddy and make add operations idempotent, and compare its final state with the failing run.
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 is tied to the condition “the buddy URI is already represented in the active presence list”; preserve that producing boundary before choosing recovery; the neighboring results below require different control-flow decisions.
RTC_E_NO_WATCHER | the requested watcher is absent from the current watcher collection |
|---|---|
RTC_E_DUPLICATE_GROUP | a group with the same authoritative identity already exists |
RTC_E_PRESENCE_NOT_ENABLED | a presence operation was requested before presence was enabled for an appropriate profile |
Telemetry should retain these distinctions even when several outcomes share HRESULT severity.
Actions that do not address this condition
- With it, do not overwrite the server list with a stale local snapshot after an uncertain roaming result.
- Do not expose a private buddy list or watcher identity in general logs.
- Do not translate it into a broad “connection failed” label before preserving the RTC symbol and producing phase.
Verification after a fix
Verify the fix with a minimal deterministic case that reaches “the buddy URI is already represented in the active presence list”; the failing case must assert the HRESULT and post-failure state; the passing case should alter one input and confirm both protocol outcome and cleanup.
Technical references
- Client Presence Roaming — API or protocol rules used to interpret it.
- Microsoft RTC return constants — authoritative context for the boundary.
- SIP presence event package — definitions relevant when reproducing it.
- Watcher information — API or protocol rules used to interpret it.
Looking for a different code? Search another status or error code.