RTC_E_SIP_INVITE_TRANSACTION_PENDING: meaning and diagnosis

Status / error code:		Category:

Constant name:
Source:	Operating System:
Description: Currently processing another INVITE transaction

Previous	Next
RTC_E_SDP_FAILED_TO_BUILD	RTC_E_SIP_AUTH_HEADER_SENT

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

RTC area	`SIP` message and `SDP` negotiation
Objects to correlate	`SIP` start-line and headers, message body framing, `SDP` session and media sections, offer/answer generation
Condition to prove	another `INVITE` or re-`INVITE` transaction still owns the dialog’s offer/answer state
Safe corrective direction	wait for completion or cancellation and then apply the next session change to current 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

Use protocol and object evidence to track INVITE CSeq, branch, completion event, and any re-INVITE or hold request queued behind it.
Confirm the distinction that SIP permits only controlled offer/answer sequencing; this is not a reason to create a second dialog automatically.
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

`RTC_E_SDP_MULTICAST`	the SDP describes a multicast connection that the RTC Client API path does not support
`RTC_E_SDP_CONNECTION_ADDR`	an SDP media description has no usable connection address at session or media level
`RTC_E_SIP_CODECS_DO_NOT_MATCH`	the local offer and remote answer have no common codec for an active media line

Technical references

Looking for a different code? Search another status or error code.