| Previous | Next |
| RTC_E_ROAMING_FAILED | RTC_E_INVALID_ACL_LIST |
RTC_E_INVALID_BUDDY_LIST
What RTC_E_INVALID_BUDDY_LIST means in RTC
The operational meaning of this result is tied to enabling presence, maintaining buddies/watchers/groups, and processing server-roamed presence state: the buddy-list data violates RTC list structure or identity rules.
Log this result as 0x80EE004F in the RTC interface facility 0xEE, not only as a signed decimal; the facility distinguishes local RTC validation from a response status mapped by the stack.
Before changing configuration, validate buddy IDs/URIs, group references, duplicates, XML shape, and server version; the RTC codes surrounding this result are not equivalent because the document can be well-formed XML yet semantically invalid as a buddy list.
Minimum incident record
- Code-specific proof: validate buddy IDs/URIs, group references, duplicates,
XMLshape, and server version. - Owning object: subscription dialog and expiration.
- Wire evidence: ACL decision and
NOTIFYversion. - Lifecycle state: presence profile and account.
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-list data violates RTC list structure or identity rules |
| Safe corrective direction | repair only the invalid entries and preserve authoritative identifiers |
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
Resolve it at its producing layer: repair only the invalid entries and preserve authoritative identifiers; after it, a separate UI or watchdog retry must wait until that layer reports a final state.
Example: A roaming list contains two records with one server ID and a group reference to a deleted group.
How to prove the condition
- Start from
0x80EE004F, then find the method/event pair that first exposed it. - To verify this, validate buddy IDs/URIs, group references, duplicates,
XMLshape, and server version. - Keep the analysis at the right boundary: the document can be well-formed
XMLyet semantically invalid as a buddy list. - After you repair only the invalid entries and preserve authoritative identifiers, repeat the smallest reproducer rather than restarting the entire application environment.
Nearby failure modes
RTC_E_NO_GROUP | the requested presence group identifier does not exist in current authoritative state |
|---|---|
RTC_E_NOT_EXIST | the specific RTC object requested by the operation no longer exists |
RTC_E_DUPLICATE_WATCHER | the watcher is already present in the watcher/authorization collection |
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
- Client Presence Roaming.
- Microsoft RTC return constants.
- SIP presence event package.
- Watcher information.
Looking for a different code? Search another status or error code.