| Previous | Next |
| RTC_E_NO_GROUP | RTC_E_TOO_MANY_GROUPS |
RTC_E_DUPLICATE_GROUP
What RTC_E_DUPLICATE_GROUP means in RTC
The useful interpretation of this result is narrower than “SIP error”; within enabling presence, maintaining buddies/watchers/groups, and processing server-roamed presence state, it means a group with the same authoritative identity already exists.
The stored value is 0x80EE0052 in the RTC interface facility 0xEE; keep both forms in telemetry so COM error wrapping does not erase whether RTC produced an interface result, mapped a SIP response, or surfaced a PINT outcome.
Start the result investigation by having the trace compare server IDs, normalized names, pending create operations, and roaming versions; do not skip the distinction that duplicate identity is not merely two groups sharing a display label when server IDs differ.
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 | a group with the same authoritative identity already exists |
| Safe corrective direction | reuse the existing group or resolve the pending-create race |
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 server IDs, normalized names, pending create operations, and roaming versions.
- Test the competing explanation explicitly, because duplicate identity is not merely two groups sharing a display label when server IDs differ.
- Apply the targeted fix — reuse the existing group or resolve the pending-create race — and validate both protocol completion and object cleanup.
Nearby failure modes
RTC_E_NO_BUDDY | the requested buddy object is absent from current presence state |
|---|---|
RTC_E_INVALID_ACL_LIST | the presence access-control list is structurally or semantically invalid |
RTC_E_PRESENCE_NOT_ENABLED | a presence operation was requested before presence was enabled for an appropriate profile |
Minimum incident record
Capture the first result before retry, reconnect, profile re-enable, or teardown changes the evidence; associate it with one RTC object instance and one transaction or media transition.
- Code-specific proof: compare server IDs, normalized names, pending create operations, and roaming versions.
- 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 reuse the existing group or resolve the pending-create race; it should also settle or cancel its previous operation before callers begin a replacement.
Example: Two devices create the same group while offline and later synchronize.
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.