| Previous | Next |
| RTC_E_STATUS_CLIENT_BAD_REQUEST | RTC_E_STATUS_CLIENT_PAYMENT_REQUIRED |
RTC_E_STATUS_CLIENT_UNAUTHORIZED
Where the state changes: RTC_E_STATUS_CLIENT_UNAUTHORIZED
The operational meaning of this result is tied to a peer, proxy, registrar, or gateway returning a specific SIP response to the RTC transaction: the user agent server or registrar requires end-server authentication.
Log this result as 0x80EF0191 in the RTC SIP-status facility carrying status 401, not only as a signed decimal; for this HRESULT, the facility distinguishes local RTC validation from a response status mapped by the stack.
Before changing configuration for this HRESULT, preserve the WWW-Authenticate scheme, realm, nonce metadata, and challenged method without logging credentials; the RTC codes surrounding this result are not equivalent because 401 challenges the target-server relationship; 407 is issued by a proxy and uses Proxy-Authenticate.
Protocol and object boundary
| RTC area | SIP final response boundary |
|---|---|
| Condition to prove | the user agent server or registrar requires end-server authentication |
| Objects to correlate | SIP request method, client transaction, response status, dialog identifiers and method-specific headers |
| Safe corrective direction | select an allowed credential for the exact realm, increment CSeq as required, and retry through the authentication state machine |
At the boundary, 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; separately, this result must be read with the rule 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.
Comparison with adjacent codes
It should not be grouped with every value from the same facility. 407 challenges proxy traversal rather than the destination server; the result table shows nearby alternatives.
RTC_E_STATUS_NOT_ACCEPTABLE_HERE | the target cannot accept the session description or other negotiated session parameters for this resource |
|---|---|
RTC_E_STATUS_SERVER_BAD_GATEWAY | the responding gateway or proxy received an invalid response from an upstream server |
RTC_E_STATUS_CLIENT_ADDRESS_INCOMPLETE | the Request-URI lacks information required to identify or route the destination |
Keeping it separate from these neighbors improves both user messaging and automated retry policy.
Telemetry and packet evidence
The earliest callback or return site is the most valuable; later it cleanup can replace the original state, so correlate the code with the object generation that produced it.
- Code-specific proof for this HRESULT: preserve the WWW-Authenticate scheme, realm, nonce metadata, and challenged method without logging credentials.
- Addressing context for this HRESULT: status-specific headers.
- RTC callback state for this HRESULT: retry or alternate-target decision.
- Transaction boundary for this HRESULT: request method and Request-URI.
- Media or profile detail for this HRESULT: responding Via hop.
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.
Step-by-step isolation
- Locate the earliest it producer and verify that no wrapper replaced a more specific lower-layer value.
- map that producer to the active RTC object and to one SIP, SDP, PINT, presence, media, or profile transition.
- collect enough evidence to preserve the WWW-Authenticate scheme, realm, nonce metadata, and challenged method without logging credentials.
- test the competing explanation explicitly, because 401 challenges the target-server relationship; 407 is issued by a proxy and uses Proxy-Authenticate.
- perform the narrow correction — select an allowed credential for the exact realm, increment CSeq as required, and retry through the authentication state machine — and validate both protocol completion and object cleanup.
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.
Actions that do not address this condition
- An investigation should not 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.
- Do not discard the result facility and state boundary when converting the result into application telemetry.
Remediation boundary
The corrective direction for this HRESULT is to select an allowed credential for the exact realm, increment CSeq as required, and retry through the authentication state machine; for this HRESULT, cancellation, cleanup, and retry should remain with the component that owns the failed transition.
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: A registrar challenges REGISTER with Digest; the client locates credentials for that realm and resends the request.
Verification after a fix
A regression test for this HRESULT should reproduce “the user agent server or registrar requires end-server authentication” with the smallest profile, message, session, presence, media, or PINT fixture; for this HRESULT, assert 0x80EF0191, the responsible method/event, and the object state after the result; then, for this HRESULT, change only the decisive precondition and verify that the corrected run leaves no stale transaction or RTC object.
Technical references
- Microsoft RTC return constants — authoritative context for the boundary.
- SIP response semantics — definitions relevant when reproducing it.
Looking for a different code? Search another status or error code.