| 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 relevant 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 should show that you preserve Proxy-Authenticate scheme/realm, selected proxy, route set, and credential source without secrets; the diagnostic distinction is that Proxy Authentication Required is hop-oriented; 401 challenges the destination user agent or registrar.
A safe diagnostic sequence
- 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.
- Start a fresh operation 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.
Evidence that separates the cause
- Code-specific proof: preserve Proxy-Authenticate scheme/realm, selected proxy, route set, and credential source without secrets.
- Identity and target: Call-ID/CSeq/tags.
- State at production: status-specific headers.
- Timing and ordering: retry or alternate-target decision.
Protocol and object state
| RTC area | SIP final response |
|---|---|
| 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
Comparison point: 401 Uses WWW-Authenticate and applies to end-server authentication.
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 |
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; it should also settle or cancel its previous operation before callers begin a replacement.
Example: An outbound enterprise proxy challenges an INVITE before forwarding it toward the public SIP domain.
Actions that do not address this condition
- 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.
Technical references
Looking for a different code? Search another status or error code.