What does HRESULT 0x80EE0070 (RTC_E_REFER_NOT_ACCEPTED) mean?

RTC_E_REFER_NOT_ACCEPTED

Where the state changes: RTC_E_REFER_NOT_ACCEPTED

This result should be investigated at the point where RTC handles starting, accepting, rejecting, or completing a REFER operation and its associated event subscription, and the condition to prove for this HRESULT is the remote party did not accept responsibility for the REFER operation.

This result is represented as 0x80EE0070 in the RTC interface facility 0xEE; record the symbolic name alongside the unsigned hexadecimal value; a decimal exception alone is poor evidence for RTC protocol diagnosis.

To establish this result, record REFER final response, Refer-To target, dialog state, and whether a refer subscription was created; this matters because rejection of REFER is not failure of the referred target itself because that request was never accepted.

Telemetry and packet evidence

• Code-specific proof: record REFER final response, Refer-To target, dialog state, and whether a refer subscription was created.
• Addressing context: NOTIFY status body.
• RTC callback state: referred-session identity and final state.
• Transaction boundary: original dialog and REFER CSeq.
• Media or profile detail: Refer-To target.

Step-by-step isolation

1. Record it and 0x80EE0070 at the first RTC method or event that returns it.
2. Prove the condition by ensuring the trace can record REFER final response, Refer-To target, dialog state, and whether a refer subscription was created.
3. Apply one controlled change: keep the original call state and offer an alternate transfer method only when supported; then verify the result return value and resulting RTC state.

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.

Recovery

Resolve it at its producing layer: keep the original call state and offer an alternate transfer method only when supported; after it, a separate UI or watchdog retry must wait until that layer reports a final state.

Example: A peer rejects blind transfer while the original call remains connected.

Comparison with adjacent codes

Actions that do not address this condition

• Do not issue a second REFER while the first operation is still pending.
• Do not tear down the original session solely because the REFER request was accepted.

Technical references

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