| Previous | Next |
| RTC_E_SECURITY_LEVEL_NOT_SUPPORTED_BY_PARTICIPANT | RTC_E_DUPLICATE_WATCHER |
RTC_E_DUPLICATE_BUDDY
What RTC_E_DUPLICATE_BUDDY means in RTC
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
- 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 state: group ID and membership.
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 buddy URI is already represented in the active presence list |
| Safe corrective direction | reuse or update the existing buddy and make add operations idempotent |
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.
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.
Example: A roaming replay tries to add a contact already committed by the server.
How to prove the condition
- Confirm the distinction that duplicate buddy does not mean duplicate display name; identity is based on the RTC contact object/URI.
- Start a fresh operation after you reuse or update the existing buddy and make add operations idempotent, and compare its final state with the failing run.
Nearby failure modes
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 |
Actions that do not address this condition
- 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.
Technical references
Looking for a different code? Search another status or error code.