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. Identify the client, profile, session, participant, presence object, terminal, or port manager that owns this occurrence.
3. Place the result in its exact phase: parsing, discovery, transport, authentication, profile validation, dialog control, media, roaming, registration, redirection, or final response handling.
4. Prove the condition by ensuring the trace can record session type/state, participant role, policy, and any pending call-control operation.
5. 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.

Diagnosis is strongest when object state and protocol trace share timestamps and transaction identifiers; avoid treating packet capture and HRESULT logging as substitutes for one another.

Minimum incident record

Capture the first result before retry, reconnect, profile re-enable, or teardown changes the evidence; associate it with one RTC object instance and one transaction or media transition.

• 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.
• Also 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

Use “RTC session type, state, or policy does not permit REFER for this call” as the discriminator when comparing the related RTC results below.

Verification after a fix

A regression test should construct “RTC session type, state, or policy does not permit REFER for this call”, 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 — definitions relevant when reproducing it.
• Microsoft RTC return constants — API or protocol rules used to interpret it.
• SIP REFER method — authoritative context for this result.

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