| Previous | Next |
| RTC_E_MEDIA_ENABLED | RTC_E_REFER_NOT_ALLOWED |
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; 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 REFER final response, Refer-To target, dialog state, and whether a refer subscription was created; for this HRESULT, this matters because rejection of REFER is not failure of the referred target itself because that request was never accepted.
Telemetry and packet evidence
Capture the first result before retry, reconnect, profile re-enable, or teardown changes the evidence; associate this result with one RTC object generation and one transaction or media transition.
- Code-specific proof for this HRESULT: record
REFERfinal response, Refer-To target, dialog state, and whether a refer subscription was created. - Addressing context for this HRESULT:
NOTIFYstatus body. - RTC callback state for this HRESULT: referred-session identity and final state.
- Transaction boundary for this HRESULT: original dialog and
REFERCSeq. - Media or profile detail for this HRESULT: Refer-To target.
A useful it trace does not require communication content or secrets; in the result record, keep structural metadata and correlation identifiers while removing passwords, authorization material, complete numbers, and private presence data.
Step-by-step isolation
- Record it and
0x80EE0070at the first RTC method or event that returns it. - Place it in its exact phase: parsing, discovery, transport, authentication, profile validation, dialog control, media, roaming, registration, redirection, or final response handling.
- Identify the client, profile, session, participant, presence object, terminal, or port manager that owns this it occurrence.
- prove the condition by ensuring the trace can record
REFERfinal response, Refer-To target, dialog state, and whether a refer subscription was created. - Apply one controlled change for this HRESULT: keep the original call state and offer an alternate transfer method only when supported; 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.
Protocol and object boundary
| RTC area | SIP REFER and call-transfer boundary |
|---|---|
| Condition to prove | the remote party did not accept responsibility for the REFER operation |
| Objects to correlate | RTC session, REFER request, Refer-To URI, refer subscription, NOTIFY outcome and referred session |
| Safe corrective direction | keep the original call state and offer an alternate transfer method only when supported |
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 it control-flow rule is that The operation has its own lifetime and completion notifications, which can outlive the original call-control method invocation.
Remediation boundary
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.
Distinguish local rejection from an operation that may already have reached the server; for this HRESULT, use transaction identifiers and final events before replaying any non-idempotent action.
Example for this HRESULT: A peer rejects blind transfer while the original call remains connected.
Comparison with adjacent codes
The practical separator for this HRESULT is this: it is tied to the condition “the remote party did not accept responsibility for the REFER operation”; preserve that producing boundary before choosing recovery; for this HRESULT, compare that boundary with these related RTC values.
RTC_E_REFER_NOT_EXIST | the REFER operation or refer session being queried has already ended or was never created |
|---|---|
RTC_E_SIP_REFER_OPERATION_PENDING | another REFER operation still owns the session’s transfer state |
RTC_E_REFER_NOT_ALLOWED | RTC session type, state, or policy does not permit REFER for this call |
Telemetry for this HRESULT should retain these distinctions even when several outcomes share HRESULT severity.
Actions that do not address this condition
- With it, 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.
- Keep it intact through exception and UI layers; a generic parameter or network message is insufficient for diagnosis.
Verification after a fix
Verify the result fix with a minimal deterministic case that reaches “the remote party did not accept responsibility for the REFER operation”; the failing the case must assert the HRESULT and post-failure state; the passing case should alter one input and confirm both protocol outcome and cleanup.
Technical references
- Receiving an RTC session transfer — API or protocol rules used to interpret it.
- Microsoft RTC return constants — authoritative context for the boundary.
- SIP REFER method — definitions relevant when reproducing it.
Looking for a different code? Search another status or error code.