| Previous | Next |
| RTC_E_STATUS_CLIENT_TEMPORARILY_NOT_AVAILABLE | RTC_E_STATUS_CLIENT_LOOP_DETECTED |
RTC_E_STATUS_CLIENT_TRANSACTION_DOES_NOT_EXIST
What RTC_E_STATUS_CLIENT_TRANSACTION_DOES_NOT_EXIST means in RTC
This code belongs to 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; 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 boundary is that this is identity/state loss, not a network timeout or ordinary call rejection.
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 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 |
How to prove the condition
- Start from
0x80EF01E1, then find the method/event pair that first exposed it. - To verify this, 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.
Minimum incident record
- Code-specific proof: compare Call-ID, local/remote tags, CSeq method/number, branch parameter, and dialog lifetime.
- Owning object: responding Via hop.
- Wire evidence: Call-ID/CSeq/tags.
- Lifecycle state: status-specific headers.
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.
Correct application response
Recovery should be narrow: stop using the stale dialog, reconcile teardown, and establish a new dialog only when the operation still makes sense; while handling this result, do not let a higher layer simultaneously recreate the same session, registration, listener, or profile.
Example: A BYE generated from cached dialog tags reaches a server after that dialog has already been destroyed.
Nearby failure modes
Comparison point: 487 Says a known request was terminated; 481 says the referenced dialog or transaction is unknown.
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 |
Technical references
Looking for a different code? Search another status or error code.