What does HRESULT 0x80EE0071 (RTC_E_REFER_NOT_ALLOWED) mean?

RTC_E_REFER_NOT_ALLOWED

What RTC_E_REFER_NOT_ALLOWED means in RTC

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 RTC session type, state, or policy does not permit REFER for this call.

This result is represented as 0x80EE0071 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 session type/state, participant role, policy, and any pending call-control operation; this matters because not allowed is a local/session contract result, not a peer’s REFER rejection.

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.

How to prove the condition

1. Record it and 0x80EE0071 at the first RTC method or event that returns it.
2. Prove the condition by ensuring the trace can record session type/state, participant role, policy, and any pending call-control operation.
3. Apply one controlled change: wait for a permitted state or use a supported transfer/conference workflow; then verify the result return value and resulting RTC state.

Minimum incident record

• Code-specific proof: record session type/state, participant role, policy, and any pending call-control operation.
• Owning object: referred-session identity and final state.
• Wire evidence: original dialog and REFER CSeq.
• Lifecycle state: Refer-To target.

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.

Correct application response

The appropriate response to it is not a blanket reconnect. Instead, wait for a permitted state or use a supported transfer/conference workflow, while preserving ownership of cleanup and any bounded retry.

Example: An application requests transfer on a session type that does not support REFER.

Nearby failure modes

Technical references

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