| 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, 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; this keeps later retries from obscuring causality.
- Code-specific proof: record operation ID, dialog, last
NOTIFY, completion event, and object generation. - Correlation key: refer subscription state.
- Protocol or object snapshot:
NOTIFYstatus body. - Last completed transition: referred-session identity and final state.
- Expected output: original dialog and
REFERCSeq.
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 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: 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; 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; 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 |
Recovery and control flow
Recovery should be narrow: make cleanup idempotent and do not reuse stale transfer objects; while handling this result, do not let a higher layer simultaneously recreate the same session, registration, listener, or profile.
Do not turn this result into an immediate unconditional retry; first determine whether the peer could have accepted the prior request and whether RTC still owns a live transaction.
Example: A late timer tries to cancel a transfer after its final NOTIFY completed.
Actions that do not address this condition
- Do not tear down the original session solely because the REFER request was accepted.
- 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 regression test should construct “the REFER operation or refer session being queried has already ended or was never created”, assert the exact HRESULT at the producing RTC boundary, and verify state ownership before and after the 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.