What does HRESULT 0x80EE007F (RTC_E_SIP_REFER_OPERATION_PENDING) mean?

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, 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. Test the competing explanation explicitly, because pending transfer is temporary serialization, not peer rejection or missing REFER state.
2. Apply the targeted fix — wait for completion/cancellation and then re-evaluate whether another transfer is still needed — and validate both protocol completion and object cleanup.

Protocol and object state

REFER acceptance means the recipient accepted responsibility for attempting the referenced action; it does not prove that the transferred call succeeded. The operation has its own lifetime and completion notifications, which can outlive the original call-control method invocation.

Signals worth preserving

• Code-specific proof: record existing REFER CSeq, target, subscription state, and final NOTIFY status.
• Correlation key: NOTIFY status body.
• Protocol or object snapshot: referred-session identity and final state.
• Last completed transition: original dialog and REFER CSeq.
• Expected output: Refer-To target.

Recovery and control flow

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

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

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 confuse it with

Technical references

• Receiving an RTC session transfer.
• Microsoft RTC return constants.
• SIP REFER method.