| 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; 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
Capture the first result before retry, reconnect, profile re-enable, or teardown changes the evidence; associate this result with one RTC object instance and one transaction or media transition.
- Code-specific proof: record
REFERfinal response, Refer-To target, dialog state, and whether a refer subscription was created. - Addressing context:
NOTIFYstatus body. - RTC callback state: referred-session identity and final state.
- Transaction boundary: original dialog and
REFERCSeq. - Media or profile detail: Refer-To target.
Step-by-step isolation
- Record it and
0x80EE0070at the first RTC method or event that returns it. - Place the result 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 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: keep the original call state and offer an alternate transfer method only when supported; 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.
Protocol and object state
| RTC area | SIP REFER and call-transfer |
|---|---|
| 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 |
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.
Distinguish local rejection from an operation that may already have reached the server; use transaction identifiers and final events before replaying any non-idempotent action.
Example: A peer rejects blind transfer while the original call remains connected.
Comparison with adjacent codes
Use “the remote party did not accept responsibility for the REFER operation” as the discriminator when comparing the related RTC results below.
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 |
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.
Verification after a fix
Verify the fix with a minimal deterministic case that reaches “the remote party did not accept responsibility for the REFER operation”; the failing 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 this result.
- SIP REFER method — definitions relevant when reproducing it.
Looking for a different code? Search another status or error code.