| Previous | Next |
| RTC_E_STATUS_CLIENT_BUSY_HERE | RTC_E_STATUS_NOT_ACCEPTABLE_HERE |
RTC_E_STATUS_REQUEST_TERMINATED
What the RTC value marks: RTC_E_STATUS_REQUEST_TERMINATED
The useful interpretation of this result is narrower than “SIP error”; within a peer, proxy, registrar, or gateway returning a specific SIP response to the RTC transaction, it means the original request was terminated before normal completion, commonly after CANCEL.
The stored Value is 0x80EF01E7 in the RTC SIP-status facility carrying status 487; for this HRESULT, 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 correlate the INVITE and CANCEL branches, CSeq values, race with final responses, and local cancel action; the result evidence should demonstrate why Request Terminated is the final response for the cancelled request; it is not itself a transport failure.
A safe diagnostic sequence
- At the source of this result, preserve the HRESULT, method or callback, timestamp, thread/task correlation, and object generation.
- reconstruct the immediately preceding RTC transition instead of beginning with the later disconnect or UI notification.
- use protocol and object evidence to correlate the
INVITEandCANCELbranches, CSeq values, race with final responses, and local cancel action. - confirm the distinction that Request Terminated is the final response for the cancelled request; it is not itself a transport failure.
- create a fresh operation generation after you complete transaction cleanup once, preserve any crossed final response, and keep user cancellation distinct from peer rejection, and compare its final state with the failing run.
Use RTC event state to interpret the protocol trace for this HRESULT, and use the trace to verify what left or reached the host; for this HRESULT, this two-sided correlation identifies the producing layer.
Evidence that separates the cause
Build the incident record before automatic recovery runs; the result record must identify one client/profile/session generation and the exact signaling, presence, or media transition in progress.
- Code-specific proof for this HRESULT: correlate the
INVITEandCANCELbranches, CSeq values, race with final responses, and local cancel action. - Identity and target for this HRESULT: request method and Request-URI.
- State at production for this HRESULT: responding Via hop.
- Timing and ordering for this HRESULT: Call-ID/CSeq/tags.
A useful this result trace does not require communication content or secrets; in the result record, keep structural metadata and correlation identifiers while removing passwords, authorization material, complete numbers, and private presence data.
Protocol and object boundary
| RTC area | SIP final response boundary |
|---|---|
| Objects to correlate | SIP request method, client transaction, response status, dialog identifiers and method-specific headers |
| Condition to prove | the original request was terminated before normal completion, commonly after CANCEL |
| Safe corrective direction | complete transaction cleanup once, preserve any crossed final response, and keep user cancellation distinct from peer rejection |
Interpreting this result requires both of these facts: The facility code preserves the SIP status number; diagnosis should start with the method and responding hop rather than treating every value as a local COM failure; also, the result branch assumes that Some responses invite a modified request or authenticated retry, while others are terminal for the current target or even global for the addressed user.
Related RTC results
For this HRESULT, 481 means the referenced transaction cannot be found, while 487 completes a known terminated request; for this HRESULT, the neighboring results below require different control-flow decisions.
RTC_E_STATUS_SERVER_VERSION_NOT_SUPPORTED | the server does not support the SIP protocol version in the request |
|---|---|
RTC_E_STATUS_NOT_ACCEPTABLE_HERE | the target cannot accept the session description or other negotiated session parameters for this resource |
RTC_E_STATUS_GLOBAL_DOES_NOT_EXIST_ANYWHERE | the authoritative server states that the addressed user does not exist anywhere it can resolve |
Keeping it separate from these neighbors improves both user messaging and automated retry policy.
How to handle the result
The owning RTC component should complete transaction cleanup once, preserve any crossed final response, and keep user cancellation distinct from peer rejection; for this HRESULT, it should also settle or cancel its previous operation before callers begin a replacement.
A retry after it is safe only after the prior transaction’s outcome is reconciled; after it, reissuing state-changing requests while the peer result is unknown can create contradictory RTC state.
Example for this HRESULT: The user cancels an outgoing call before answer; the INVITE transaction ends with 487.
Actions that do not address this condition
- The following shortcut is unsafe for this HRESULT: do not retry every 4xx or 5xx response with the identical request.
- Another non-solution for this HRESULT is to do not show a reason phrase as trusted server identity or authorization evidence.
- Do not discard the result facility and state boundary when converting the result into application telemetry.
Verification after a fix
A useful it regression does more than expect an exception; the result test constructs “the original request was terminated before normal completion, commonly after CANCEL”, 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 — definitions relevant when reproducing it.
- SIP response semantics — API or protocol rules used to interpret it.
Looking for a different code? Search another status or error code.