| Previous | Next |
| RTC_E_INVALID_BUDDY_LIST | RTC_E_NO_GROUP |
RTC_E_INVALID_ACL_LIST
Where the state changes: RTC_E_INVALID_ACL_LIST
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 presence access-control list is structurally or semantically invalid, not merely that a call or registration failed.
The numeric form of this result is 0x80EE0050 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 validate watcher identities, allow/deny entries, duplicates, and list version; the diagnostic distinction is that ACL validation concerns authorization rules, not whether the watcher currently exists online.
Protocol and object state
| RTC area | presence subscription and contact-list |
|---|---|
| Condition to prove | the presence access-control list is structurally or semantically invalid |
| Objects to correlate | presence profile, buddy, watcher, group, ACL, SUBSCRIBE/NOTIFY state, presence document |
| Safe corrective direction | rebuild the invalid rule set from current server objects and least-privilege policy |
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.
Comparison with adjacent codes
RTC_E_DUPLICATE_WATCHER | the watcher is already present in the watcher/authorization collection |
|---|---|
RTC_E_NOT_EXIST | the specific RTC object requested by the operation no longer exists |
RTC_E_NO_GROUP | the requested presence group identifier does not exist in current authoritative state |
Telemetry and packet evidence
- Code-specific proof: validate watcher identities, allow/deny entries, duplicates, and list version.
- Addressing context: group ID and membership.
- RTC callback state: subscription dialog and expiration.
- Transaction boundary: ACL decision and
NOTIFYversion. - Media or profile detail: presence profile and account.
Step-by-step isolation
- Collect enough evidence to validate watcher identities, allow/deny entries, duplicates, and list version.
- Test the competing explanation explicitly, because ACL validation concerns authorization rules, not whether the watcher currently exists online.
- Apply the targeted fix — rebuild the invalid rule set from current server objects and least-privilege policy — and validate both protocol completion and object cleanup.
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.
Recovery
Resolve it at its producing layer: rebuild the invalid rule set from current server objects and least-privilege policy; after it, a separate UI or watchdog retry must wait until that layer reports a final state.
Example: A sync merge creates contradictory allow and block entries for one watcher.
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.