| Previous | Next |
| RTC_E_SIP_ADDITIONAL_PARTY_IN_TWO_PARTY_SESSION | RTC_E_SIP_OTHER_PARTY_JOIN_IN_PROGRESS |
RTC_E_SIP_PARTY_ALREADY_IN_SESSION
Operational meaning: RTC_E_SIP_PARTY_ALREADY_IN_SESSION
Read this result as an RTC state-machine result: at this point in creating a session, adding or removing participants, and serializing operations that alter call topology, the participant identity is already attached to the current RTC session.
Log this result as 0x80EE005F 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.
The first useful check is to compare normalized URI, participant object, dialog leg, and pending join operation. The result must be separated from nearby conditions because duplicate participant is not the same as another device belonging to the same user unless RTC normalizes them to one party.
Signals worth preserving
- Code-specific proof: compare normalized URI, participant object, dialog leg, and pending join operation.
- Correlation key: completion event and final response.
- Protocol or object snapshot: session type and state.
- Last completed transition: participant URI and count.
- Expected output: Call-ID/dialog identifiers.
Recovery and control flow
The owning RTC component should reuse the existing participant and make join requests idempotent; it should also settle or cancel its previous operation before callers begin a replacement.
Example: Two UI actions add the same SIP URI before the first completion event is processed.
Protocol and object state
| RTC area | RTC session and participant state |
|---|---|
| Condition to prove | the participant identity is already attached to the current RTC session |
| Objects to correlate | IRTCSession, session type/state, participant URI, dialog, pending INVITE or join operation |
| Safe corrective direction | reuse the existing participant and make join requests idempotent |
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.
Verification workflow
- Collect enough evidence to compare normalized URI, participant object, dialog leg, and pending join operation.
- Test the competing explanation explicitly, because duplicate participant is not the same as another device belonging to the same user unless RTC normalizes them to one party.
- Apply the targeted fix — reuse the existing participant and make join requests idempotent — and validate both protocol completion and object cleanup.
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.
Do not confuse it with
RTC_E_SIP_PEER_PARTICIPANT_IN_MULTIPARTY_SESSION | a peer-style participant cannot be inserted into the selected multiparty session topology |
|---|---|
RTC_E_SIP_OTHER_PARTY_JOIN_IN_PROGRESS | a join operation for another participant is already changing session topology |
RTC_E_INVALID_SESSION_STATE | the session exists but its current state does not permit the requested operation |
Technical references
Looking for a different code? Search another status or error code.