| Previous | Next |
| RTC_E_PLATFORM_NOT_SUPPORTED | RTC_E_NOT_ALLOWED |
RTC_E_SIP_PEER_PARTICIPANT_IN_MULTIPARTY_SESSION
What RTC_E_SIP_PEER_PARTICIPANT_IN_MULTIPARTY_SESSION means in RTC
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 boundary is that participant role compatibility is different from merely exceeding a count limit.
Minimum incident record
- Code-specific proof: record session type, participant role, conference focus/gateway, and existing roster.
- Owning object: participant URI and count.
- Wire evidence: Call-ID/dialog identifiers.
- Lifecycle state: pending operation instance.
Protocol and object state
| RTC area | RTC session and participant state |
|---|---|
| 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 |
Adding the first participant starts an idle RTC session; later participant operations are constrained by the chosen session type. An outstanding INVITE, join, hold, or REFER operation owns part of the session state until its completion event arrives.
Correct application response
Recovery should be narrow: use the conference/focus mechanism required by the session type or create a separate peer session; while handling this result, do not let a higher layer simultaneously recreate the same session, registration, listener, or profile.
Example: 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. - Prove the condition by ensuring the trace can record session type, participant role, conference focus/gateway, and existing roster.
- Apply one controlled change: 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.
Nearby failure modes
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 |
Actions that do not address this condition
- Do not create a second session until the first operation outcome is reconciled.
- Do not issue overlapping topology changes from independent callbacks.
Technical references
Looking for a different code? Search another status or error code.