| 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; 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
- Confirm the distinction that Request Terminated is the final response for the cancelled request; it is not itself a transport failure.
- Start a fresh operation 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.
Evidence that separates the cause
Before automatic recovery runs, record one client, profile, or session instance and the exact signaling, presence, or media transition in progress.
- Code-specific proof: correlate the
INVITEandCANCELbranches, CSeq values, race with final responses, and local cancel action. - Identity and target: request method and Request-URI.
- State at production: responding Via hop.
- Timing and ordering: Call-ID/CSeq/tags.
Protocol and object state
| RTC area | SIP final response |
|---|---|
| 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; 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 |
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; it should also settle or cancel its previous operation before callers begin a replacement.
Example: The user cancels an outgoing call before answer; the INVITE transaction ends with 487.
Actions that do not address this condition
- Do not retry every 4xx or 5xx response with the identical request.
- Do not show a reason phrase as trusted server identity or authorization evidence.
Technical references
Looking for a different code? Search another status or error code.