| Previous | Next |
| RTC_E_INVALID_ACL_LIST | RTC_E_DUPLICATE_GROUP |
RTC_E_NO_GROUP
Operational meaning: RTC_E_NO_GROUP
This result belongs to the presence subscription and contact-list boundary area of RTC and identifies the requested presence group identifier does not exist in current authoritative state.
This result carries 0x80EE0051 in the RTC interface facility 0xEE; store the result value at the first RTC callback or method boundary, before retry logic replaces it with a broader timeout or connection message.
Start the result investigation by having the trace record group ID/name, list version, pending delete, and caller’s cached mapping; do not skip the distinction that missing group differs from an empty group and from a missing buddy.
Signals worth preserving
Before automatic recovery runs, record one client, profile, or session instance and the exact signaling, presence, or media transition in progress.
- Code-specific proof: record group ID/name, list version, pending delete, and caller’s cached mapping.
- Correlation key: subscription dialog and expiration.
- Protocol or object snapshot: ACL decision and
NOTIFYversion. - Last completed transition: presence profile and account.
- Expected output: buddy/watcher URI.
Protocol and object state
| RTC area | presence subscription and contact-list |
|---|---|
| Condition to prove | the requested presence group identifier does not exist in current authoritative state |
| Objects to correlate | presence profile, buddy, watcher, group, ACL, SUBSCRIBE/NOTIFY state, presence document |
| Safe corrective direction | refresh groups and choose an existing target or create the group before membership changes |
Interpreting this result requires both of these facts: Presence data is subscription state rather than call state; buddy existence, watcher authorization, and current availability are separate concepts; also, the result branch assumes that When presence roaming is enabled, the server can act as the presence agent and becomes authoritative for list and subscription updates.
Verification workflow
- Start from
0x80EE0051, then find the method/event pair that first exposed it. - To verify this, record group ID/name, list version, pending delete, and caller’s cached mapping.
- Keep the analysis at the right boundary: missing group differs from an empty group and from a missing buddy.
- After you refresh groups and choose an existing target or create the group before membership changes, repeat the smallest reproducer rather than restarting the entire application environment.
Do not confuse it with
RTC_E_NO_BUDDY | the requested buddy object is absent from current presence state |
|---|---|
RTC_E_DUPLICATE_WATCHER | the watcher is already present in the watcher/authorization collection |
RTC_E_INVALID_BUDDY_LIST | the buddy-list data violates RTC list structure or identity rules |
Recovery and control flow
The appropriate response to it is not a blanket reconnect. Instead, refresh groups and choose an existing target or create the group before membership changes, while preserving ownership of cleanup and any bounded retry.
Example: A stale client moves a buddy into a group deleted from another endpoint.
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.