| Previous | Next |
| RTC_E_STATUS_CLIENT_NOT_ACCEPTABLE | RTC_E_STATUS_CLIENT_REQUEST_TIMEOUT |
RTC_E_STATUS_CLIENT_PROXY_AUTHENTICATION_REQUIRED
What the RTC value marks: RTC_E_STATUS_CLIENT_PROXY_AUTHENTICATION_REQUIRED
Diagnosis begins inside a peer, proxy, registrar, or gateway returning a specific SIP response to the RTC transaction, where the decisive condition for this HRESULT is an intermediary proxy requires authentication before forwarding the request.
The numeric form of this result is 0x80EF0197 in the RTC SIP-status facility carrying status 407; an exception translator handling it should preserve this value before converting it into application-facing call or presence states.
Evidence for this HRESULT should show that you preserve Proxy-Authenticate scheme/realm, selected proxy, route set, and credential source without secrets; the diagnostic distinction for this HRESULT is that Proxy Authentication Required is hop-oriented; 401 challenges the destination user agent or registrar.
A safe diagnostic sequence
- At the source of this result, preserve the HRESULT, method or callback, timestamp, thread/task correlation, and object generation.
- reconstruct the immediately preceding RTC transition instead of beginning with the later disconnect or UI notification.
- use protocol and object evidence to preserve Proxy-Authenticate scheme/realm, selected proxy, route set, and credential source without secrets.
- confirm the distinction that Proxy Authentication Required is hop-oriented; 401 challenges the destination user agent or registrar.
- create a fresh operation generation after you authenticate to the exact proxy and rebuild the request with Proxy-Authorization under the RTC profile rules, and compare its final state with the failing run.
Correlate wire data and RTC events for this HRESULT; for this HRESULT, either source alone can misclassify local validation as remote rejection, or a remote status as a local media or profile failure.
Evidence that separates the cause
Do not wait for a generic failure notification to log this result; preserve the API call or event producing it together with the RTC object and transaction state visible at that moment.
- Code-specific proof for this HRESULT: preserve Proxy-Authenticate scheme/realm, selected proxy, route set, and credential source without secrets.
- Identity and target for this HRESULT: Call-ID/CSeq/tags.
- State at production for this HRESULT: status-specific headers.
- Timing and ordering for this HRESULT: retry or alternate-target decision.
Sanitize the result evidence before storage: secrets and user content should disappear, while framing, domains, sizes, hashes, timing, and object-state changes remain available for reproduction.
Protocol and object boundary
| RTC area | SIP final response boundary |
|---|---|
| Objects to correlate | SIP request method, client transaction, response status, dialog identifiers and method-specific headers |
| Condition to prove | an intermediary proxy requires authentication before forwarding the request |
| Safe corrective direction | authenticate to the exact proxy and rebuild the request with Proxy-Authorization under the RTC profile rules |
Interpreting this result requires both of these facts: The facility code preserves the SIP status number; diagnosis should start with the method and responding hop rather than treating every value as a local COM failure; also, the result branch assumes that Some responses invite a modified request or authenticated retry, while others are terminal for the current target or even global for the addressed user.
Related RTC results
It should not be grouped with every value from the same facility. 401 uses WWW-Authenticate and applies to end-server authentication; the result table shows nearby alternatives.
RTC_E_STATUS_CLIENT_BAD_REQUEST | the receiving SIP element could not understand the request because its syntax or framing was invalid |
|---|---|
RTC_E_STATUS_CLIENT_BAD_EXTENSION | the server requires removal of a SIP extension it does not understand |
RTC_E_STATUS_CLIENT_TEMPORARILY_NOT_AVAILABLE | the addressed user or endpoint is temporarily unavailable at all currently known contacts |
Telemetry for this HRESULT should retain these distinctions even when several outcomes share HRESULT severity.
How to handle the result
The owning RTC component should authenticate to the exact proxy and rebuild the request with Proxy-Authorization under the RTC profile rules; for this HRESULT, it should also settle or cancel its previous operation before callers begin a replacement.
A retry after it is safe only after the prior transaction’s outcome is reconciled; after it, reissuing state-changing requests while the peer result is unknown can create contradictory RTC state.
Example for this HRESULT: An outbound enterprise proxy challenges an INVITE before forwarding it toward the public SIP domain.
Actions that do not address this condition
- The following shortcut is unsafe for this HRESULT: do not retry every 4xx or 5xx response with the identical request.
- Do not show a reason phrase as trusted server identity or authorization evidence.
- A wrapper handling it should retain the original HRESULT instead of replacing it with an undifferentiated call failure.
Verification after a fix
A useful it regression does more than expect an exception; the result test constructs “an intermediary proxy requires authentication before forwarding the request”, checks the exact HRESULT at the producing RTC boundary, and verifies state ownership before and after the targeted correction.
Technical references
- Microsoft RTC return constants — definitions relevant when reproducing it.
- SIP response semantics — API or protocol rules used to interpret it.
Looking for a different code? Search another status or error code.