| Previous | Next |
| RTC_E_PLATFORM_NOT_SUPPORTED | RTC_E_NOT_ALLOWED |
RTC_E_SIP_PEER_PARTICIPANT_IN_MULTIPARTY_SESSION
Protocol boundary: RTC_E_SIP_PEER_PARTICIPANT_IN_MULTIPARTY_SESSION
The legacy RTC Client API reports this result while working with creating a session, adding or removing participants, and serializing operations that alter call topology; the precise meaning of it is a peer-style participant cannot be inserted into the selected multiparty session topology, not merely that a call or registration failed.
The numeric form of this result is 0x80EE0081 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.
The quickest way to localize this result is to record session type, participant role, conference focus/gateway, and existing roster; the important the boundary is that participant role compatibility is different from merely exceeding a count limit.
Minimum incident record
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 for this HRESULT: record session type, participant role, conference focus/gateway, and existing roster.
- Owning object for this HRESULT: participant URI and count.
- Wire evidence for this HRESULT: Call-ID/dialog identifiers.
- Lifecycle generation for this HRESULT: pending operation generation.
A useful it trace does not require communication content or secrets; in the result record, keep structural metadata and correlation identifiers while removing passwords, authorization material, complete numbers, and private presence data.
Protocol and object boundary
| RTC area | RTC session and participant state boundary |
|---|---|
| Objects to correlate | IRTCSession, session type/state, participant URI, dialog, pending INVITE or join operation |
| Condition to prove | a peer-style participant cannot be inserted into the selected multiparty session topology |
| Safe corrective direction | use the conference/focus mechanism required by the session type or create a separate peer session |
The surrounding protocol rule for this HRESULT is that Adding the first participant starts an idle RTC session; later participant operations are constrained by the chosen session type; in addition, the path requires that An outstanding INVITE, join, hold, or REFER operation owns part of the session state until its completion event arrives.
Correct application response
Recovery from it should be narrow: use the conference/focus mechanism required by the session type or create a separate peer session; while handling it, do not let a higher layer simultaneously recreate the same session, registration, listener, or profile.
Do not turn it into an immediate unconditional retry; for this HRESULT, first determine whether the peer could have accepted the prior request and whether RTC still owns a live transaction.
Example for this HRESULT: A direct peer participant is added to a server-controlled multiparty conference object.
How to prove the condition
- Record it and
0x80EE0081at the first RTC method or event that returns it. - Place it in its exact phase: parsing, discovery, transport, authentication, profile validation, dialog control, media, roaming, registration, redirection, or final response handling.
- Identify the client, profile, session, participant, presence object, terminal, or port manager that owns this it occurrence.
- prove the condition by ensuring the trace can record session type, participant role, conference focus/gateway, and existing roster.
- Apply one controlled change for this HRESULT: use the conference/focus mechanism required by the session type or create a separate peer session; then verify the result return value and resulting RTC state.
A SIP capture without RTC callback state cannot show which local object accepted or rejected the transition; for this HRESULT, an HRESULT-only log has the opposite weakness: it cannot show whether the result was generated before transmission or mapped from the peer.
Nearby failure modes
Use the following contrast when classifying it: it is tied to the condition “a peer-style participant cannot be inserted into the selected multiparty session topology”; preserve that producing boundary before choosing recovery; for this HRESULT, similar subsystem names do not imply identical recovery.
RTC_E_SIP_CALL_CONNECTION_NOT_ESTABLISHED | the call has not reached the connected dialog/session state required by the requested operation |
|---|---|
RTC_E_OPERATION_WITH_TOO_MANY_PARTICIPANTS | the requested operation exceeds the participant count supported by the session type or method |
RTC_E_INVALID_SESSION_STATE | the session exists but its current state does not permit the requested operation |
Keeping it separate from these neighbors improves both user messaging and automated retry policy.
Actions that do not address this condition
- With it, do not create a second session until the first operation outcome is reconciled.
- Another non-solution for this HRESULT is to do not issue overlapping topology changes from independent callbacks.
- Do not discard the result facility and state boundary when converting the result into application telemetry.
Verification after a fix
A useful it regression does more than expect an exception; the result test constructs “a peer-style participant cannot be inserted into the selected multiparty session topology”, checks the exact HRESULT at the producing RTC boundary, and verifies state ownership before and after the targeted correction.
Technical references
- Create a Session and Make a Call — API or protocol rules used to interpret it.
- Microsoft RTC return constants — authoritative context for the boundary.
- SIP dialog and transaction rules — definitions relevant when reproducing it.
Looking for a different code? Search another status or error code.