RTC_E_SIP_ADDITIONAL_PARTY_IN_TWO_PARTY

Status / error code:		Category:

Constant name:
Source:		Operating System:
Description: Adding additional parties to two party session failed

Previous	Next
RTC_E_SIP_CALL_CONNECTION_NOT_ESTABLISHED	RTC_E_SIP_PARTY_ALREADY_IN_SESSION

RTC_E_SIP_ADDITIONAL_PARTY_IN_TWO_PARTY_SESSION

Where the state changes: `RTC_E_SIP_ADDITIONAL_PARTY_IN_TWO_PARTY_SESSION`

The useful interpretation of this result is narrower than “SIP error”; within creating a session, adding or removing participants, and serializing operations that alter call topology, it means code attempted to add another participant to a session constrained to two parties.

The stored value is 0x80EE005E in the RTC interface facility 0xEE; keep both forms in telemetry so COM error wrapping does not erase whether RTC produced an interface result, mapped a SIP response, or surfaced a PINT outcome.

Collect enough state to record session type, current participant, requested URI, and whether conference service is available; the result evidence should demonstrate why the failure is topology-specific, not a universal participant-count quota.

Telemetry and packet evidence

Before automatic recovery runs, record one client, profile, or session instance and the exact signaling, presence, or media transition in progress.

Code-specific proof: record session type, current participant, requested URI, and whether conference service is available.
Addressing context: completion event and final response.
RTC callback state: session type and state.
Transaction boundary: participant URI and count.
Media or profile detail: Call-ID/dialog identifiers.

Protocol and object state

RTC area	RTC session and participant state
Condition to prove	code attempted to add another participant to a session constrained to two parties
Objects to correlate	`IRTCSession`, session type/state, participant URI, dialog, pending `INVITE` or join operation
Safe corrective direction	create a multiparty/conference session or decline the addition

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.

Actions that do not address this condition

Do not issue overlapping topology changes from independent callbacks.
Do not create a second session until the first operation outcome is reconciled.

Step-by-step isolation

Start from 0x80EE005E and this result, then find the method/event pair that first exposed it.
To verify this, record session type, current participant, requested URI, and whether conference service is available.
Keep the analysis at the right boundary: the failure is topology-specific, not a universal participant-count quota.
After you create a multiparty/conference session or decline the addition, repeat the smallest reproducer rather than restarting the entire application environment.

Recovery

Resolve it at its producing layer: create a multiparty/conference session or decline the addition; after it, a separate UI or watchdog retry must wait until that layer reports a final state.

Example: A call-transfer feature mistakenly uses AddParticipant on a two-party session to create a conference.

Comparison with adjacent codes

`RTC_E_OPERATION_WITH_TOO_MANY_PARTICIPANTS`	the requested operation exceeds the participant count supported by the session type or method
`RTC_E_SIP_UNHOLD_OPERATION_PENDING`	an unhold/resume transaction is already pending for the RTC session
`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.