| Previous | Next |
| RTC_E_REFER_NOT_ACCEPTED | RTC_E_REFER_NOT_EXIST |
RTC_E_REFER_NOT_ALLOWED
Protocol boundary: RTC_E_REFER_NOT_ALLOWED
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; for this HRESULT, 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; for this HRESULT, this matters because not allowed is a local/session contract result, not a peer’s REFER rejection.
Protocol and object boundary
| RTC area | SIP REFER and call-transfer boundary |
|---|---|
| Objects to correlate | RTC session, REFER request, Refer-To URI, refer subscription, NOTIFY outcome and referred session |
| Condition to prove | RTC session type, state, or policy does not permit REFER for this call |
| Safe corrective direction | wait for a permitted state or use a supported transfer/conference workflow |
The API and protocol context for this HRESULT is not optional: REFER acceptance means the recipient accepted responsibility for attempting the referenced action; it does not prove that the transferred call succeeded; the related this result control-flow rule is that The operation has its own lifetime and completion notifications, which can outlive the original call-control method invocation.
How to prove the condition
- Record it and
0x80EE0071at the first RTC method or event that returns it. - Identify the client, profile, session, participant, presence object, terminal, or port manager that owns this it occurrence.
- Place it in its exact phase: parsing, discovery, transport, authentication, profile validation, dialog control, media, roaming, registration, redirection, or final response handling.
- prove the condition by ensuring the trace can record session type/state, participant role, policy, and any pending call-control operation.
- Apply one controlled change for this HRESULT: wait for a permitted state or use a supported transfer/conference workflow; then verify the result return value and resulting RTC state.
The result diagnosis is strongest when object state and protocol trace share timestamps and transaction identifiers; when diagnosing it, 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 generation and one transaction or media transition.
- Code-specific proof for this HRESULT: record session type/state, participant role, policy, and any pending call-control operation.
- Owning object for this HRESULT: referred-session identity and final state.
- Wire evidence for this HRESULT: original dialog and
REFERCSeq. - Lifecycle generation for this HRESULT: Refer-To target.
For privacy-safe analysis of it, preserve protocol structure rather than payload content; for this HRESULT, authentication values, complete addresses, buddy lists, and bodies should be redacted or hashed under policy.
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.
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.
Before retrying it, classify the previous operation as definitely failed, definitely completed, or remotely uncertain; for this HRESULT, that distinction prevents duplicate dialogs, bindings, transfers, or roaming mutations.
Example for this HRESULT: An application requests transfer on a session type that does not support REFER.
Nearby failure modes
The practical separator for this HRESULT is this: it is tied to the condition “RTC session type, state, or policy does not permit REFER for this call”; preserve that producing boundary before choosing recovery; for this HRESULT, compare that boundary with these related RTC values.
RTC_E_SIP_REFER_OPERATION_PENDING | another REFER operation still owns the session’s transfer state |
|---|---|
RTC_E_REFER_NOT_ACCEPTED | the remote party did not accept responsibility for the REFER operation |
RTC_E_REFER_NOT_EXIST | the REFER operation or refer session being queried has already ended or was never created |
The comparison prevents it from being flattened into a subsystem-wide error bucket with unsafe generic remediation.
Verification after a fix
A useful it regression does more than expect an exception; the result test constructs “RTC session type, state, or policy does not permit REFER for this call”, checks the exact HRESULT at the producing RTC boundary, and verifies state ownership before and after the targeted 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 the boundary.
Looking for a different code? Search another status or error code.