What does HRESULT 0x80EE007F (RTC_E_SIP_REFER_OPERATION_PENDING) mean?

Previous	Next
RTC_E_UDP_NOT_SUPPORTED	RTC_E_PLATFORM_NOT_SUPPORTED

RTC_E_SIP_REFER_OPERATION_PENDING

Operational meaning: RTC_E_SIP_REFER_OPERATION_PENDING

The operational meaning of this result is tied to starting, accepting, rejecting, or completing a REFER operation and its associated event subscription: another REFER operation still owns the session’s transfer state.

The machine-readable identity of this result is 0x80EE007F 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 existing REFER CSeq, target, subscription state, and final NOTIFY status; the RTC codes surrounding this result are not equivalent because pending transfer is temporary serialization, not peer rejection or missing REFER state.

Verification workflow

1. Locate the earliest this result producer and verify that no wrapper replaced a more specific lower-layer value.
2. map that producer to the active RTC object and to one SIP, SDP, PINT, presence, media, or profile transition.
3. collect enough evidence to record existing REFER CSeq, target, subscription state, and final NOTIFY status.
4. test the competing explanation explicitly, because pending transfer is temporary serialization, not peer rejection or missing REFER state.
5. perform the narrow correction — wait for completion/cancellation and then re-evaluate whether another transfer is still needed — and validate both protocol completion and object cleanup.

Use RTC event state to interpret the protocol trace for this HRESULT, and use the trace to verify what left or reached the host; for this HRESULT, this two-sided correlation identifies the producing layer.

Protocol and object boundary

RTC area	SIP REFER and call-transfer boundary
Condition to prove	another REFER operation still owns the session’s transfer state
Objects to correlate	RTC session, REFER request, Refer-To URI, refer subscription, NOTIFY outcome and referred session
Safe corrective direction	wait for completion/cancellation and then re-evaluate whether another transfer is still needed

The surrounding protocol rule for this HRESULT is that REFER acceptance means the recipient accepted responsibility for attempting the referenced action; it does not prove that the transferred call succeeded; in addition, the path requires that The operation has its own lifetime and completion notifications, which can outlive the original call-control method invocation.

Signals worth preserving

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: record existing REFER CSeq, target, subscription state, and final NOTIFY status.
• Correlation key for this HRESULT: NOTIFY status body.
• Protocol or object snapshot for this HRESULT: referred-session identity and final state.
• Last completed transition for this HRESULT: original dialog and REFER CSeq.
• Expected output for this HRESULT: Refer-To target.

When recording it, redact credentials, full telephone numbers, private contact lists, and message bodies; for this HRESULT, retain permitted URI domains, header names, byte counts, hashes, transaction identifiers, timestamps, and state transitions.

Recovery and control flow

Recovery from it should be narrow: wait for completion/cancellation and then re-evaluate whether another transfer is still needed; while handling it, do not let a higher layer simultaneously recreate the same session, registration, listener, or profile.

Distinguish local rejection from an operation that may already have reached the server; for this HRESULT, use transaction identifiers and final events before replaying any non-idempotent action.

Example for this HRESULT: A user starts a second transfer while the first REFER subscription is active.

Actions that do not address this condition

• The following shortcut is unsafe for this HRESULT: do not tear down the original session solely because the REFER request was accepted.
• also do not issue a second REFER while the first operation is still pending.
• Keep it intact through exception and UI layers; a generic parameter or network message is insufficient for diagnosis.

Do not confuse it with

Use the following contrast when classifying it: it is tied to the condition “another REFER operation still owns the session’s transfer state”; preserve that producing boundary before choosing recovery; for this HRESULT, similar subsystem names do not imply identical recovery.

RTC_E_REFER_NOT_ALLOWED	RTC session type, state, or policy does not permit REFER for this call
RTC_E_REFER_NOT_EXIST	the REFER operation or refer session being queried has already ended or was never created
RTC_E_REFER_NOT_ACCEPTED	the remote party did not accept responsibility for the REFER operation

Facility equality is not semantic equality; route each contrasted value through its own recovery branch.

Verification after a fix

Keep two tests: one that intentionally produces “another REFER operation still owns the session’s transfer state”, and one that applies the narrow correction; for this HRESULT, check the callback sequence, 0x80EE007F, final session/profile state, and absence of leaked listeners, dialogs, streams, or registrations.

Technical references

• Receiving an RTC session transfer — definitions relevant when reproducing it.
• Microsoft RTC return constants — API or protocol rules used to interpret it.
• SIP REFER method — authoritative context for the boundary.

---

Looking for a different code? Search another status or error code.