What does HRESULT 0x80EE000E (RTC_E_SIP_INVITE_TRANSACTION_PENDING) mean?

RTC_E_SIP_INVITE_TRANSACTION_PENDING

What the RTC value marks: RTC_E_SIP_INVITE_TRANSACTION_PENDING

This code belongs to parsing, constructing, or reconciling SIP signaling and the SDP offer/answer carried by it: another INVITE or re-INVITE transaction still owns the dialog’s offer/answer state.

For correlation, retain 0x80EE000E in the RTC interface facility 0xEE together with this result; generic HRESULT text can otherwise hide the protocol family and the exact RTC branch.

The quickest way to localize this result is to track INVITE CSeq, branch, completion event, and any re-INVITE or hold request queued behind it; the important boundary is that SIP permits only controlled offer/answer sequencing; this is not a reason to create a second dialog automatically.

Protocol and object state

SIP transaction state and media negotiation are separate: a syntactically valid SIP request can still contain absent or unacceptable SDP. An SDP update must be checked against the previous offer/answer state, not merely parsed as a standalone text document.

Evidence that separates the cause

• Code-specific proof: track INVITE CSeq, branch, completion event, and any re-INVITE or hold request queued behind it.
• Identity and target: SDP o= version and c= address.
• State at production: each m= line and codec mapping.
• Timing and ordering: message direction and transport.

A safe diagnostic sequence

1. Use protocol and object evidence to track INVITE CSeq, branch, completion event, and any re-INVITE or hold request queued behind it.
2. Confirm the distinction that SIP permits only controlled offer/answer sequencing; this is not a reason to create a second dialog automatically.
3. Start a fresh operation after you wait for completion or cancellation and then apply the next session change to current state, and compare its final state with the failing run.

How to handle the result

The appropriate response to it is not a blanket reconnect. Instead, wait for completion or cancellation and then apply the next session change to current state, while preserving ownership of cleanup and any bounded retry.

Example: Hold and codec-change callbacks both attempt re-INVITE before the first transaction finishes.

Actions that do not address this condition

• Do not repair malformed signaling by silently deleting unknown headers or media sections.
• Do not log credentials or an unredacted SDP body from production calls.

Related RTC results

Technical references

• Microsoft RTC return constants.
• SIP message and transaction rules.
• SDP syntax.
• SDP offer/answer.