| Previous | Next |
| RTC_E_STATUS_CLIENT_TEMPORARILY_NOT_AVAILABLE | RTC_E_STATUS_CLIENT_LOOP_DETECTED |
RTC_E_STATUS_CLIENT_TRANSACTION_DOES_NOT_EXIST
Protocol boundary: RTC_E_STATUS_CLIENT_TRANSACTION_DOES_NOT_EXIST
This result marks a specific boundary in a peer, proxy, registrar, or gateway returning a specific SIP response to the RTC transaction: the recipient cannot match the request to an existing dialog or server/client transaction; treating it as a generic RTC failure loses the state needed to choose a safe next action.
For correlation, retain 0x80EF01E1 in the RTC SIP-status facility carrying status 481 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 compare Call-ID, local/remote tags, CSeq method/number, branch parameter, and dialog lifetime; the important the boundary is that this is identity/state loss, not a network timeout or ordinary call rejection.
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 recipient cannot match the request to an existing dialog or server/client transaction |
| Safe corrective direction | stop using the stale dialog, reconcile teardown, and establish a new dialog only when the operation still makes sense |
At the boundary, 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; separately, this result must be read with the rule 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.
How to prove the condition
- Start from
0x80EF01E1and it, then find the method/event pair that first exposed it. - check whether the failure was local before transmission, produced during RTC state validation, or mapped from a remote response.
- the proof step is to compare Call-ID, local/remote tags, CSeq method/number, branch parameter, and dialog lifetime.
- keep the analysis at the right boundary: this is identity/state loss, not a network timeout or ordinary call rejection.
- after you stop using the stale dialog, reconcile teardown, and establish a new dialog only when the operation still makes sense, repeat the smallest reproducer rather than restarting the entire application environment.
The result diagnosis is strongest when object state and protocol trace share timestamps and transaction identifiers; when diagnosing it, avoid treating packet capture and HRESULT logging as substitutes for one another.
Minimum incident record
The earliest callback or return site is the most valuable; later it cleanup can replace the original state, so correlate the code with the object generation that produced it.
- Code-specific proof for this HRESULT: compare Call-ID, local/remote tags, CSeq method/number, branch parameter, and dialog lifetime.
- Owning object for this HRESULT: responding Via hop.
- Wire evidence for this HRESULT: Call-ID/CSeq/tags.
- Lifecycle generation for this HRESULT: status-specific headers.
A useful it 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.
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.
- Do not show a reason phrase as trusted server identity or authorization evidence.
- Keep it intact through exception and UI layers; a generic parameter or network message is insufficient for diagnosis.
Correct application response
Recovery from it should be narrow: stop using the stale dialog, reconcile teardown, and establish a new dialog only when the operation still makes sense; while handling it, do not let a higher layer simultaneously recreate the same session, registration, listener, or profile.
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: A BYE generated from cached dialog tags reaches a server after that dialog has already been destroyed.
Nearby failure modes
It should not be grouped with every value from the same facility. 487 says a known request was terminated; 481 says the referenced dialog or transaction is unknown; the result table shows nearby alternatives.
RTC_E_STATUS_CLIENT_LOOP_DETECTED | a proxy detected that request routing has looped back through the same path |
|---|---|
RTC_E_STATUS_CLIENT_REQUEST_TIMEOUT | the server could not produce a response within its transaction timing window |
RTC_E_STATUS_CLIENT_REQUEST_ENTITY_TOO_LARGE | the request body exceeds the size the server is willing or able to process |
Telemetry for this HRESULT should retain these distinctions even when several outcomes share HRESULT severity.
Verification after a fix
A regression test for this HRESULT should reproduce “the recipient cannot match the request to an existing dialog or server/client transaction” with the smallest profile, message, session, presence, media, or PINT fixture; for this HRESULT, assert 0x80EF01E1, the responsible method/event, and the object state after the result; then, for this HRESULT, change only the decisive precondition and verify that the corrected run leaves no stale transaction or RTC object.
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.