| Previous | Next |
| RTC_E_DUPLICATE_GROUP | RTC_E_NO_BUDDY |
RTC_E_TOO_MANY_GROUPS
Operational meaning: RTC_E_TOO_MANY_GROUPS
This result is useful only when preserved with its producing phase; in enabling presence, maintaining buddies/watchers/groups, and processing server-roamed presence state, it denotes the presence list has reached the group-count limit enforced by RTC or the server.
The machine-readable identity of this result is 0x80EE0053 in the RTC interface facility 0xEE; the result identity matters because RTC uses separate facilities for API conditions, SIP final responses, and PINT service statuses.
The first useful check is to record current count, server limit, hidden/default groups, and pending creates. The result must be separated from nearby conditions because this is a collection quota rather than a duplicate or malformed-group error.
Signals worth preserving
Do not wait for a generic failure notification to log this result; preserve the API call or event producing it together with the RTC object and transaction state visible at that moment.
- Code-specific proof: record current count, server limit, hidden/default groups, and pending creates.
- 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 presence list has reached the group-count limit enforced by RTC or the server |
| Objects to correlate | presence profile, buddy, watcher, group, ACL, SUBSCRIBE/NOTIFY state, presence document |
| Safe corrective direction | merge or remove unused groups before creating another, preserving buddy membership |
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 record current count, server limit, hidden/default groups, and pending creates.
- Test the competing explanation explicitly, because this is a collection quota rather than a duplicate or malformed-group error.
- Apply the targeted fix — merge or remove unused groups before creating another, preserving buddy membership — and validate both protocol completion and object cleanup.
Do not confuse it with
RTC_E_INVALID_BUDDY_LIST | the buddy-list data violates RTC list structure or identity rules |
|---|---|
RTC_E_DUPLICATE_BUDDY | the buddy URI is already represented in the active presence list |
RTC_E_NO_GROUP | the requested presence group identifier does not exist in current authoritative state |
Recovery and control flow
Recovery should be narrow: merge or remove unused groups before creating another, preserving buddy membership; while handling this result, do not let a higher layer simultaneously recreate the same session, registration, listener, or profile.
Example: An importer creates one group per contact until the server limit is reached.
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.