| 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 result marks a specific boundary in 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; treating it as a generic RTC failure loses the state needed to choose a safe next action.
For correlation, retain 0x80EE000E in the RTC interface facility 0xEE together with this result; for this HRESULT, 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 the boundary is that SIP permits only controlled offer/answer sequencing; this is not a reason to create a second dialog automatically.
Protocol and object boundary
| RTC area | SIP message and SDP negotiation boundary |
|---|---|
| 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 |
The surrounding protocol rule for this HRESULT is that SIP transaction state and media negotiation are separate: a syntactically valid SIP request can still contain absent or unacceptable SDP; in addition, the path requires that 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
Correlate this result at source: the method or callback, the owning object generation, and the active protocol transition; for this HRESULT, this keeps later retries from obscuring causality.
- Code-specific proof for this HRESULT: track
INVITECSeq, branch, completion event, and any re-INVITEor hold request queued behind it. - Identity and target for this HRESULT:
SDPo= version and c= address. - State at production for this HRESULT: each m= line and codec mapping.
- Timing and ordering for this HRESULT: message direction and transport.
Sanitize the result evidence before storage: secrets and user content should disappear, while framing, domains, sizes, hashes, timing, and object-state changes remain available for reproduction.
A safe diagnostic sequence
- At the source of it, preserve the HRESULT, method or callback, timestamp, thread/task correlation, and object generation.
- use protocol and object evidence to track
INVITECSeq, branch, completion event, and any re-INVITEor hold request queued behind it. - reconstruct the immediately preceding RTC transition instead of beginning with the later disconnect or UI notification.
- confirm the distinction that
SIPpermits only controlled offer/answer sequencing; this is not a reason to create a second dialog automatically. - create a fresh operation generation 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.
A SIP capture without RTC callback state cannot show which local object accepted or rejected the transition; for this HRESULT, an HRESULT-only log has the opposite weakness: it cannot show whether the result was generated before transmission or mapped from the peer.
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.
Distinguish local rejection from an operation that may already have reached the server; for this HRESULT, use transaction identifiers and final events before replaying any non-idempotent action.
Example for this HRESULT: Hold and codec-change callbacks both attempt re-INVITE before the first transaction finishes.
Actions that do not address this condition
- With it, do not repair malformed signaling by silently deleting unknown headers or media sections.
- also do not log credentials or an unredacted SDP body from production calls.
- Do not discard the result facility and state boundary when converting the result into application telemetry.
Related RTC results
The practical separator for this HRESULT is this: it is tied to the condition “another INVITE or re-INVITE transaction still owns the dialog’s offer/answer state”; preserve that producing boundary before choosing recovery; for this HRESULT, compare that boundary with these related RTC values.
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 |
Keeping it separate from these neighbors improves both user messaging and automated retry policy.
Verification after a fix
A useful it regression does more than expect an exception; the result test constructs “another INVITE or re-INVITE transaction still owns the dialog’s offer/answer state”, checks the exact HRESULT at the producing RTC boundary, and verifies state ownership before and after the targeted correction.
Technical references
- Microsoft RTC return constants — API or protocol rules used to interpret it.
- SIP message and transaction rules — authoritative context for the boundary.
- SDP syntax — definitions relevant when reproducing it.
- SDP offer/answer — API or protocol rules used to interpret it.
Looking for a different code? Search another status or error code.