| Previous | Next |
| RTC_E_SIP_PARTY_ALREADY_IN_SESSION | RTC_E_INVALID_OBJECT_STATE |
RTC_E_SIP_OTHER_PARTY_JOIN_IN_PROGRESS
What RTC_E_SIP_OTHER_PARTY_JOIN_IN_PROGRESS means in RTC
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 a join operation for another participant is already changing session topology.
The stored value is 0x80EE0060 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.
Start the result investigation by having the trace record the in-flight participant, operation ID, session state, and completion event owner; do not skip the distinction that this serializes topology updates and is not a permanent participant limit.
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 join operation for another participant is already changing session topology |
| Safe corrective direction | queue the new join until the current one completes and revalidate state |
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.
How to prove the condition
- Record this result and
0x80EE0060at the first RTC method or event that returns it. - Prove the condition by ensuring the trace can record the in-flight participant, operation ID, session state, and completion event owner.
- Apply one controlled change: queue the new join until the current one completes and revalidate state; 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_SIP_HOLD_OPERATION_PENDING | a hold transaction is already pending for the RTC session |
RTC_E_OPERATION_WITH_TOO_MANY_PARTICIPANTS | the requested operation exceeds the participant count supported by the session type or method |
Minimum incident record
Capture the first result before retry, reconnect, profile re-enable, or teardown changes the evidence; associate it with one RTC object instance and one transaction or media transition.
- Code-specific proof: record the in-flight participant, operation ID, session state, and completion event owner.
- Owning object: pending operation instance.
- Wire evidence: completion event and final response.
- Lifecycle state: session type and state.
Correct application response
Recovery should be narrow: queue the new join until the current one completes and revalidate state; while handling this result, do not let a higher layer simultaneously recreate the same session, registration, listener, or profile.
Example: A conference roster update attempts parallel joins on a legacy RTC session.
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.
Technical references
Looking for a different code? Search another status or error code.