| Previous | Next |
| RTC_E_REFER_NOT_ALLOWED | RTC_E_SIP_HOLD_OPERATION_PENDING |
RTC_E_REFER_NOT_EXIST
Operational meaning: RTC_E_REFER_NOT_EXIST
This result is useful only when preserved with its producing phase; in starting, accepting, rejecting, or completing a REFER operation and its associated event subscription, it denotes the REFER operation or refer session being queried has already ended or was never created.
The machine-readable identity of this result is 0x80EE0072 in the RTC interface facility 0xEE; the result identity matters because RTC uses separate facilities for API conditions, SIP final responses, and PINT service statuses.
Before changing configuration for this HRESULT, record operation ID, dialog, last NOTIFY, completion event, and object generation; the RTC codes surrounding this result are not equivalent because missing REFER state differs from remote rejection of an existing request.
Signals worth preserving
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: record operation ID, dialog, last
NOTIFY, completion event, and object generation. - Correlation key for this HRESULT: refer subscription state.
- Protocol or object snapshot for this HRESULT:
NOTIFYstatus body. - Last completed transition for this HRESULT: referred-session identity and final state.
- Expected output for this HRESULT: original dialog and
REFERCSeq.
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.
Protocol and object boundary
| RTC area | SIP REFER and call-transfer boundary |
|---|---|
| Condition to prove | the REFER operation or refer session being queried has already ended or was never created |
| Objects to correlate | RTC session, REFER request, Refer-To URI, refer subscription, NOTIFY outcome and referred session |
| Safe corrective direction | make cleanup idempotent and do not reuse stale transfer objects |
Interpreting it requires both of these facts: REFER acceptance means the recipient accepted responsibility for attempting the referenced action; it does not prove that the transferred call succeeded; also, the result branch assumes that The operation has its own lifetime and completion notifications, which can outlive the original call-control method invocation.
Verification workflow
- Record it and
0x80EE0072at the first RTC method or event that returns it. - Identify the client, profile, session, participant, presence object, terminal, or port manager that owns this it occurrence.
- Place it in its exact phase: parsing, discovery, transport, authentication, profile validation, dialog control, media, roaming, registration, redirection, or final response handling.
- prove the condition by ensuring the trace can record operation ID, dialog, last
NOTIFY, completion event, and object generation. - Apply one controlled change for this HRESULT: make cleanup idempotent and do not reuse stale transfer objects; then verify the result return value and resulting RTC state.
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.
Do not confuse it with
It is tied to the condition “the REFER operation or refer session being queried has already ended or was never created”; preserve that producing boundary before choosing recovery; for this HRESULT, the neighboring results below require different control-flow decisions.
RTC_E_REFER_NOT_ACCEPTED | the remote party did not accept responsibility for the REFER operation |
|---|---|
RTC_E_REFER_NOT_ALLOWED | RTC session type, state, or policy does not permit REFER for this call |
RTC_E_SIP_REFER_OPERATION_PENDING | another REFER operation still owns the session’s transfer state |
Keeping it separate from these neighbors improves both user messaging and automated retry policy.
Recovery and control flow
Recovery from it should be narrow: make cleanup idempotent and do not reuse stale transfer objects; while handling it, do not let a higher layer simultaneously recreate the same session, registration, listener, or profile.
Do not turn it into an immediate unconditional retry; for this HRESULT, first determine whether the peer could have accepted the prior request and whether RTC still owns a live transaction.
Example for this HRESULT: A late timer tries to cancel a transfer after its final NOTIFY completed.
Actions that do not address this condition
- An investigation should not do not tear down the original session solely because the REFER request was accepted.
- Another non-solution for this HRESULT is to do not issue a second REFER while the first operation is still pending.
- 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 REFER operation or refer session being queried has already ended or was never created”, checks the exact HRESULT at the producing RTC boundary, and verifies state ownership before and after the targeted correction.
Technical references
- Receiving an RTC session transfer — authoritative context for the boundary.
- Microsoft RTC return constants — definitions relevant when reproducing it.
- SIP REFER method — API or protocol rules used to interpret it.
Looking for a different code? Search another status or error code.